******************************************************************************** * * * Minkowsky Administration guide * * * ******************************************************************************** Contents 1) The structure of Minkowsky 2) Software requirements 3) Installation of Minkowsky 3.1) Instalation using the installer scripts 4) Configuration files 4.1) The file /etc/minkowsky 4.2) Definition of Users and Groups in DATA_PATH/users and DATA_PATH/groups 4.3) Definition of Rooms and Locations in DATA_PATH/rooms 4.4) Definition of (public) holidays in DATA_PATH/holidays 4.5) Definition of Mail templates for Reminders. 4.6) The Permission String 4.7) Users preferences 4.7.1) Removing User passwords 5) Files and directory in DATA_PATH 6) Multithreading 7) Adminko 8) Signals 9) Automatic Backup 10) Know Bugs. 11) Future plans 1) The structure of Minkowsky Minkowsky is a client-server-application. Its has a central server on which all the data of the appointments, tasks, addresses etc. are stored. The clients request a subset of this data and display them on the screen. All the data in Minkowsky are assigned to one or more users. It is possible to restrict other users access on this data. To allow Minkowsky to distinguish different users Minkowsky has its own user management (see 4.2) The communication between server and client is done via a tcp socket on port 41999 (default). After creating a new user his/her password is empty. She/He must set it on her own in the User Preferences dialog of the client application. 2) Software requirements Server: - Perl 5 with installed NET-Module - gdb and screen for running the server in debugging mode. Client: Tcl/Tk >= 8.0 Tix >= 8.0 3) Installation of Minkowsky There are two ways of installing Minkowsky: - installing the rpm-packages - running the installer scripts of the source distribution rpm packages will not always be in sync with the source distribution especially on x86 platforms (My preferred platform in LinuxPPC ;-) ) rpm-packages will install everything in /opt/minkowsky, apart from the configuration file /etc/minkowsky and the servers database in /var/minkowsky. With the installer script you may choose were to put the program. 3.1) Instalation using the installer scripts There are individual packages for the server application, the client application and the client documentation of each language. In all of the tarballs you find a instalation script named installer_en.sh The server instalation script knows two options: -d for developmental purposes. This creates a configuration file in $HOME/minkowsky and shifts the port for this version two 42001. Therefore a developmental server can run in parallel to the productive. -drc Add the parameter 'SERVER_DEBUG' to /etc/minkowsky. With this parameter set the server starts gdb session which in turn turn is started in a screen session. Therefore in case of problems the server can be examined in the debugger without being restarted. Both of the installer scripts ask for certain parameters such as where to put the server's database, where to put the binaries etc. This parameters are needed are partly needed on runtime and will be put into /etc/minkowsky. Server and client can share a common /etc/minkowsky-file. There must be a /etc/minkowsky-file on every machine running the server or a client. 4) Configuration files There are five configuration files used by Minkowsky: - /etc/minkowsky - DATA_PATH/users - DATA_PATH/groups - DATA_PATH/rooms - DATA_PATH/holidays With DATA_PATH in the path of the server database as found in /etc/minkowsky. Additionally you can define the templates for the Mails send by Minkowsky in DATA_PATH/templates. If none defined the precompiled defaults are taken, which are currently always in German (translated templates are welcome to be added into the servers code) 4.1) The file /etc/minkowsky All of Minkowsky's configuration files have to be read line wise with parameter per line. Each lines begins with the Name of the parameter. After a whitespace (space or tab) the value follows until the end of the line. If client and server share on /etc/minkowsky file they ignore each other parameters. This are the parameters defined for the server: SERVER_BIN_PATH On this path the server binaries are located. DATA_PATH on this path the server's database is located. This includes the data for the appointments, task etc. and the user management data. TERMIN_DATA_PATH old name of the parameter DATA_PATH. Still supported. COMPANY A string to be included into Mails send by Minkowsky. Its meant to contain the name of your company, organization or what ever. Its included in the default mail templates to indicated where this mail comes from (especially useful with mails send to external participants of appointments). You may use it or not in your own mail templates. MYSELF A string to be included into Mails send by Minkowsky. This string is meant to contain the name of this application. Hence its default value is "Minkowsky Space/Time Management". If you dislike it you may change it. In the default mail templates its added to mails together with 'COMPANY'. You may use it or not in your own mail templates. REPLY_ADDRESS A e-mail address to which replies on Mails send by Minkowsky should go to. This e-mail address is added to the mails Reply-TO-Field. DEVELSERVER If this parameter is present the server will run in developmental mode. This parameter is boolean in a way. True if present and false if not present. NOTIFY_EVERY Determines how often modification-notification mails should be send (for modification-notification mails see the parameter 'GETNOTIFY4 in DATA_PATH/users). The value interpreted is in seconds. CHECKPRESENCE Minkowsky may display which users are currently present on the location. However Minkowsky can't determine this on its own. This parameter determines if Minkowsky should display the presence status and where to find the data about presence of users. If the parameter is not given in /etc/minkowsky presence status will not be display. If the parameter is not given in /etc/minkowsky the value is the name of the file containing the presence status data. This file must contain a list a Minkowsky-usernames, one per line. All users listed there are assumed to be present. VERBOSE The usual verbose flag. This parameter is boolean again. True if present, false if not. NOTE: verbose active together with a server in debugging mode will allow the administrator to see all transfered data. Hence there is not much confidential any more. SERVER_LANGUAGE defines the language to be used by the server, e.g. for reminder mails etc. This must be a two letter code. Currently only two languages are supported: en = English de = German. If SERVER_LANGUAGE is undefined in /etc/minkowsky the Minkowsky server will use the language defined in the environment variable LANG. If still undefined Minkowsky will use English. Note: The does not apply to the error message send by the server. They will always be in English. Note 2: As of version 0.5.0-0 the translation of the is still incomplete. Hence even if English is defined it will be mixed English/German. Especially texts of reminder mails will be German by default (See 4.5 on how to define your own mail templates). Notification mail text are translate, however. SERVER_DEBUG This flag is used by the init script. If set the server starts in debugging mode using screen and gdb otherise it starts as simple process. SENDERTHREADS Number of Sender threads. For details see section 6 about Multithreading. LOGINTHREADS Number of process login threads. For details see section 6 about Multithreading. BACKUP_PATH Path on which the Backup of Minkowsky data should be written. If this Path is set in /etc/minkowsky backup facility is enabled. For details see section 9 below. PERMANENT_BACKUP_AT Once a day the backup is written to directory named according to the day but not the hour. This happen by default at 0:00:15. You may change this this with this parameter. The number given here is interpreted as hour (in 24 hour system) on which the "permantent" backup is written. Number larger than 23 will disable the "permantent" backup. For further details see section 9 below. This are the parameters defined for the client: MINKO_PATH Path on with the client application look for the tcl-scripts (on MINKO_PATH/client) and the online documentation (on MINKO_PATH/html) MINKO_SERVER Name or IP of the Minkowsky server. MINKO_AUTO_MRR Boolean parameter again. Determines if the the Minkowsky-Remote-Reminder will be installed in the users autostart folder or not. Currently only supported for KDE1 and KDE2 (Hints for Gnome or other window managers are welcome). A running Minkowsky-Remote-Reminder will enable you to receive Reminder in a dialog window rather than by e-mail. To run this app even without the client being started the Minkowsky-Remote-Reminder have to be added to the window managers autostart mechanism. ENABLE_SYNC This flag is only of temprary use. As long as the PDA- syncronisation module is in alpha state, this module must be enabled explicitly, either with this flag in /etc/minkowsky to enable it on all clients or with the commandline option -enableSync for each client speparately. Please note thissyncronisation module may crash your server, since it not well tested, yet. 4.2) Definition of Users and Groups in DATA_PATH/users and DATA_PATH/groups To access Minkowsky each user needs an account in Minkowsky's user management. This accounts are defined in the file DATA_PATH/users. Furthermore users can be grouped into groups defined in DATA_PATH/groups. Both files DATA_PATH/users and DATA_PATH/groups are constructed the usual Minkowsky way: parameter per line starting with the name of the parameter followed by the parameters value(s) after whitespace(s). Parameters belonging to one users or group are groups into a block. Each block ends when the next block begins or the file ends. Each block begins with a particular parameter line. the line of the parameter 'ID'. This is the only parameter with a different syntax (see below). Some parameter are available in both DATA_PATH/users and DATA_PATH/groups other in only one of them. See the parameters description below. Comments in DATA_PATH/users and DATA_PATH/groups are easy. All lines starting not with a defined parameter name are ignored, and may be used as comment/remark This are the parameters defined for DATA_PATH/users and/or DATA_PATH/groups ID SYNTAX: ID='uid' 'username' With this parameter a new user or group block starts. It defines the user- or group-ID (uid or gid) and assigns a username or group name to it. uids may range from 0 to 9999999. The uid=0 is a special case (as on UNIX systems ;-) ). The User with uid=0 is the 'Minkowsky Administrator0' no matter how the account is named. If no user with uid=0 is defined the server itself defines one internally named 'admin / Minkowsky Administrator' The username might not contain any whitespace. gids may range from 0 to 19999999. The gid=0 is again a special case (as on UNIX systems ;-) ). Administrators of the group with gid=0 are 'Minkowsky Administrators' no matter how the group is named. If no group with gid=0 is defined the server itself defines one internally named all / All' The group name might not contain any whitespace. EXAMPLE: ID=1 goetz ID=1 Alle AVAILABILITY: DATA_PATH/users and DATA_PATH/groups FULL SYNTAX: FULL 'full user name' Defines the long or full user or group name. This is the preferably display name in the client. However to log in you need the username from the ID parameter EXAMPLE: FULL Rüdiger Goetz AVAILABILITY: DATA_PATH/users and DATA_PATH/groups MAIL SYNTAX: MAIL 'mail-address' Defines the e-mail address to which reminder mails etc. should be send. EXAMPLE: MAIL goetz MAIL me@r-goetz.de AVAILABILITY: DATA_PATH/users SMTP SYNTAX: SMTP 'smtp-server' If mail to the above given e-ail address can't be delivered through the local MTA (e.g. sendmail or exim, ....) you specify here a SMTP server to use instead. EXAMPLE: SMTP stmp.provider.net AVAILABILITY: DATA_PATH/users MAIL2, MAIL3, MAIL4 SYNTAX: MAIL2 'mail-address' MAIL3 'mail-address' MAIL4 'mail-address' You may define up to 4 e-mail addresses per user. With the parameters MAIL2 to MAIL4 the additional three will be defined. EXAMPLE: MAIL2: user@gmx.de AVAILABILITY: DATA_PATH/users SMTP2, SMTP3, SMTP4 SYNTAX: SMTP2 'smtp-server' SMTP3 'smtp-server' SMTP4 'smtp-server' Like the SMTP-Parameter defines a SMTP server to deliver e-mail to the address given in in MAIL parameter, you can define SMTP servers for the mail address MAIL2, MAIL3, MAIL4 in SMTP2, SMTP3, SMTP4, respectively. EXAMPLE: SMTP2 stmp.provider.net AVAILABILITY: DATA_PATH/users GETNOTIFY4 SYNTAX: GETNOTIFY4 'list of users' Minkowsky may inform users about changes in other users calendar. The parameter GETNOTIFY4 defines the list of users the on which Minkowsky will listen for the user defined by the last ID-parameter. See the example below. However, if one gets an e-mail on every single change it might fill up your mailbox. Therefore Minkowsky collects this information for some time and send this delayed. The parameter NOTIFY_EVERY in /etc/minkowsky defines at which times this information is send So, what is this good for? For example this might be useful if a secretary is about to maintain the bosses calendar and another user creates a appointment to which the boss should attend. Than the secretary will receive an e-mail (at most delayed by the time defined by NOTIFY_EVERY) that there is a change in this bosses calender and what kind of change this is. EXAMPLE: ID=33 mueller FULL Fritz Mueller GETNOTIFY4 meyer schulze ID=34 schulze Here the user mueller will be informed about changes in the calendars of the users meyer and schulze. AVAILABILITY: DATA_PATH/users GROUPS SYNTAX: GROUPS 'list of groups' Defines in which groups the user is member. All groups defined here must exist in DATA_PATH/groups AVAILABILITY: DATA_PATH/users DONTLIST SYNTAX: DONTLIST Defines to list not the particular user or group in the clients lists of users or groups. This parameter should be used for user or groups which left your company or organization. So, you not delete them from the users or groups list but mark them. Hence they still are listed in old appointments which they attended in their time at your company, but are not listed to be invited to new appointments any more. This parameter is boolean and has no further value. AVAILABILITY: DATA_PATH/users and DATA_PATH/groups COLOR SYNTAX: COLOR 'color1' 'color2' Defines the colors identifying a user in the calendar. Users have a two color code,one upper and one lower color. It might be a good idea to assign have a common color2 with a department or a subgroup of your organization and use color1 to distinguish users within the department or subgroup. If no color defined both colors are assumed to be black. EXAMPLE COLOR #FF0000 #0000FF AVAILABILITY: DATA_PATH/users COLOR SYNTAX: COLOR 'color' Defines the color identifying a group in the calendar. Like users groups have a color code in Minkowsky's calendar view. However there symbol in somewhat larger and unicolour. EXAMPLE COLOR #FF0000 AVAILABILITY: DATA_PATH/groups PERM SYNTAX: PERM 'perm-admin' 'perm-member' 'perm-others' Defines the access permission to appointments in the calendar. perm-admin are the permission for the groups administrators if the appointments is assigned to this group. perm-member are the permission on watching a groups calendar if you are a group member. perm-others are the permission on watching a groups calendar if you are not a group member. The values of perm-admin, perm-member and perm-others are given in form of the permission strings as defined in the clients online documentation or on http://r-goetz.de/minkowsky/en/docu/rechte.html#kal See there also on how permissions are determined in the calendar Note: Both German and English permission strings are allowed. EXAMPLE: PERM zütkzütkd zütk---k- zü------- AVAILABILITY: DATA_PATH/groups ADMIN SYNTAX: ADMIN 'list of users' Defines which users are administrators of this group. EXAMPLE: ADMIN mueller meyer AVAILABILITY: DATA_PATH/groups PRIMARY SYNTAX: PRIMARY Again a boolean option. Defines that this group is the primary group to set as default group on creation of new appointments. There can only be one primary group. If more than one primary groups are defined the last in the list is taken. If no primary group define the predefined group 0 (All/Alle) is used. EXAMPLE: ADMIN mueller meyer AVAILABILITY: DATA_PATH/groups 4.3) Definition of Rooms and Locations in DATA_PATH/rooms Rooms and other locations at which appointment may situated are defined in DATA_PATH/rooms. This file has the same syntax as DATA_PATH/users and DATA_PATH/groups. It only differs in the set of parameters available. Note: By definition all locations are called 'rooms' internally in Minkowsky. ID SYNTAX: ID='rid' 'roomname' With this parameter a new room block starts. It defines the room-ID (rid) and assigns a room name to it. rids may range from 0 to 39999999. There is no special meaning of the room with rid=0. The room name might not contain any whitespace. EXAMPLE: ID=1 ConferenceRoom PERM SYNTAX: PERM 'permission-String' Similar to the PERM parameter in DATA_PATH/groups. This parameter defines the access permissions on the rooms calendar. (However if a users has access permission from other source, e.g. his is invited to a appointment or is administrator, this might be overruled.) EXAMPLE: PERM zütk---k - DETAILS SYNTAX: DETAILS 'text' Here you can give a detailed description about the room. Currently only read by the Minkowsky server, but not used any further. It may show it in future expansion of the Minkowsky client. 4.4) Definition of (public) holidays in DATA_PATH/holidays Minkowsky has no own algorithm to determine on which days holidays will be. Therefore you have to tell this to Minkowsky. This is done in the file DATA_PATH/holidays. The client will highlight this holidays. As usual this file has a line wise structure. Each line defines the holidays within a one month in one year. The syntax of line is the following: 'year' 'mon' 'list of holidays' 'year' may range from 0 to infinity (O.k> not really must fit into a 32bit signed integer). 'mon' may range from 1 to 12 (fro January to December, as you probably already guessed) 'list of holidays' is string with an even number of whitespace separate values. The first value in each pair in the day of month with the month defined by 'mon' and 'year'. The second value is the name of the holiday. If the name contains whitespace it must be enclosed in braces ('{' and '}'). EXAMPLE: 2001 12 24 {Heilig Abend} 25 Weihnachten 26 Weihnachten 31 Sylvester (Please excuse the use of German holidays here) 4.5) Definition of Mail templates for Reminders. The content of reminder mails (and other mails) send by the Minkowsky server is generate from templates. (One exception are the Notification mail mentioned above). This templates must be stored in DATA_PATH/templates/. There are predefined and hard coded templates which the server will use if here doesn't find any templates in DATA_PATH/templates/. You may define only some templates and leave others on there predefined default. Note: As of version 0.5.0-0 of the server there are no English templates predefined. Hence unless defined in DATA_PATH/templates/ the German templates will be used. Translation or suggestions for English templates are welcome. There are two template files for each type of mail send by the server, one for the subject line of the mail and one for the text of the mail. The subject file must have the extension .subject, the text file .text. The base name of the template files define for which mail type they should be used. (Please excuse that this names are German) The following mail template files will be used: EinladungIntern.text for invitation mails to internal participants EinladungIntern.subject EinladungExtern.text for invitation mails to external participants EinladungExtern.subject (those invited from the address book) ErinnerungIntern.text for reminder mails to internal participants ErinnerungIntern.subject ErinnerungExtern.text for reminder mails to external participants ErinnerungExtern.subject (those invited from the address book) ErinnerungToDO.text for reminders mails on running tasks ErinnerungToDO.subject MahnungToDO.text for reminders mails on delayed task MahnungToDO.subject ShiftDateIntern.text for notes about shifts on a particular instance of ShiftDateIntern.subject repeated appointment, send to internal participants ShiftDateExtern.text for notes about shifts on a particular instance of ShiftDateExtern.subject repeated appointment, send to external participants SuspendDateIntern.text for notes about canceling particular instance of SuspendDateIntern.subject repeated appointment, send to internal participants SuspendDateExtern.text for notes about canceling particular instance of SuspendDateExtern.subject repeated appointment, send to external participants Obviously this template must contain placeholders for the data of the appoint meant or task. The following are defined: %I Name of the initiators %A Content of the COMPANY parameter from /etc/minkowsky %M Content of the MYSELF parameter from /etc/minkowsky %T Name or title of the appointment or task %D Details or description text of the appointment or task %S End date and time of the appointment or target date of the task %H Date of the day on which the mail is send. %% The '%'-letter itself %?T Conditional text: The template text between $?T and the next %] will only be copied to the mail if length of the name or title of the appointment or task is not of zero length. Please note you can't nest conditionals here. %] End of the .conditional (text). Only valid on appointments: %E List of the invited participants %l with SERVER_LANGUAGE="de" this is replaced by the text 'läd' if the number of inviting participants (including the initiator) is 1. Otherwise it is replaced by the text 'laden'. with SERVER_LANGUAGE="en" this replaced by the text 'invites' or 'invite' depending on the of inviting participants like in the German version. %B The start date and time of the appointment %R the location (room) in which the appointment took place. Only in shifts of appointments %N Contents of the details field of the shift dialog. %?N Conditional text: Like %?T, but depends on the size of the Contents of the details field of the shift dialog. 4.6 The Permission String The permission string is used in PERM parameter of DATA_PATH/groups and DATA_PATH/rooms and in the Minkowsky client. The permission strings allows a fine graduation of permission. You grant permission in four different areas of an appointment: * Time / Location: [short l or z] This includes all settings about the date, repeating and the location of the appointment. Appointments are visible to a user if read access on Time / Location is granted to him. * Texts: [short t or ü] This includes the title and text about appointment details. * Participants: [short p or t] This includes the list of participants and all settings made there. Also included is the privacy status and the priority. * Comments: [short c or k] Includes reading and adding comments. Note: There are two sets of short symbols: ltpc and zütk (one derived from English the other from German). In the configuration files only there position is relevant (see below). However, for reading convenience you should stick to one set. Note 2: To access reminder settings a user need permission on Time / Location and Participants. On each of the four areas read or write (or both) access may be granted. Additionally the permission to delete might be granted (short symbol d in either set). This give a total of nine grants, which will be represented by a nine character long string: ltpcltpcd or zütkzütkd The first 4 characters in permission string stands for the read permissions. The second 4 characters in permission string stands for the write permissions and the last character for the delete permission. A denied denied permission is symbolized by a '-'. A granted permission is symbolized by any other character preferable by the one given about. In each group of four characters the first stands for the 'Time / Location'-permission the second stands for the 'Texts'-permission the third stands for the 'Participants'-permission and the forth stands for the 'Comments'-permission Note: The client application will display this string in a somewhat extended form: r=ltpc w=ltpcd or r=zütk w=zütkd This form is _not_ valid for use in the PERM parameter of DATA_PATH/groups or DATA_PATH/rooms !. Example: The strings lt-c-t-c- and zü-k-ü-k- both grant read and write permission for 'Texts' and 'Comments' and read permission on 'Time / Location', but no access on 'Participants' and no delete access. The string qr-h-v-w- will do the same. However it will be even worse readable than the the normal permission string. 4.7 Users preferences For each user Minkowsky maintains a file of user preferences on the server side in DATA_PATH/prefs/uid.prefs where uid is replaced by the users ID as defined in DATA_PATH/users. This file has the usual line wise structure. However, this file can be totally maintained through the Minkowsky client application. However there might is one exception: 4.7.1) Removing User passwords If a user lost his/her password it can be removed by deleting the line starting with 'PWD' in the users preferences file. 5) Files and directory in DATA_PATH On DATA_PATH Minkowsky stores all its data and all its configuration apart from /etc.minkowsky: 1) The appointment etc data is found in: dates The data of the appointments dates.shift The data of changes on particular instances of repeated appointments comments/*.txt One file for each appointment to store the comments on this appointment todos The data of the task (or todos) projs The data of the projects address The data of the addresses of the address book notiz/*.txt The data of the memo pad (Notizbuch) of each address. 2) General configuration files these are users groups rooms holidays templates/* for detailed description see chapter 4 of this guide 3) Users data There are two kinds of users specific data in Minkowsky, each stored in its own subdirectory: prefs Here the users preferences are stored. See Section 4.7 for details. userData In this folder users modifications on particular appointments are stored (e.g. the ignore status) 6) Multithreading. Starting with Version 0.5.2.0 the server of Minkowsky is multithreaded. When Minkowsky starts a couple of thread are spawned. These are: * one listener thread * a couple of sender threads (16 by default) * one login listener thread * a couple process login threads (8 by default) * one process thread (to be precise this thread is not spwaned, but it is the main thread after spawning the other threads) The number of sender threads and process login threads might be changed in /etc/minkowsky with the SENDERTHREADS and LOGINTHREADS varibales. The login listener thread checks the socket for clients connecting. If a client connects the control is passed to the next free process login thread which processes the login request. Therefore the login listener is back listing within a short period of time and hence several logins can be processed in parrallel (limited by the number of process login threads). The listener thread listens on the sockets of already connected client for there request. Certain special request are processed directly by the listener. All other are put into a process queue and send back a task id (or ticket) to the client. The client may now request the result of a certain task. In this case the listener passes the request on to the next free sender thread. If the task is completly processed, the result is send to the client and the task is closed. If not s 'pending' signal is send to the client and the client will request the result later again. Besides requesting reults of tasks the listener thread ansers 'exit' request and 'serverUp?" requests directly. The process thread in turn waits for task put into the process queue. If there are any tasks in the queue the process thread processes the first writes back the result into the queue and marks the task as completed. Afterwards it continues with the next task (if any). Between to two client-task the process thread check for the internally scheduled task, such as sending reminders, amcking backup and so on. 7) Adminko Adminko is a GUI-Tool to manage the configuration files described in chapter 4 (expect for the user preferences). Please note that currently adminko can't mange DATA_PATH/holidays and DATA_PATH/templates. However, this is planed for future releases. 8) Signals Minkowsky traps three signals: SIGTERM SIGINT : This two signals will initiate a clean shutdown of the Minkowsky server. All data will be synced to disk before terminating. SIGUSR1 : This will cause Minkowsky to reread data. This includes both the data managed by Minkowsky (appointments etc.) as well as configuration data in the configuration files. Note: Due to bugs this signal handling was disabled. Please restart the sever instead. 9) Automatic Backup Starting with version 0.5.2.0 Minkowsky includes a backup module. This module is enabled if a BACKUP_PATH is defined in /etc/minkowsky. The backup is done once a hour on HH:00:15 (or so). The backup writes a complte copy of DATA_PATH to BACKUP_PATH/HH with HH replaced by the current hour. Obviously this backups are overwritte the next day. Once a day (default: 00:00:15) the backup is written to another directory which is not overwritte the other day (hence it is "permanent" if you like). This directory is named by the current date BACKUP_PATH/yyyy-mm-dd (yyyy-mm-dd beeing the ISO form of a date). You may change hour on which this "permanent" Backup is written with the PERMANENT_BACKUP_AT variable in /etc/minkowsky. The Backup is done by the shell script DATA_PATH/backupMinkowsky.sh. You may replace this script with your own script. Minkowsky passes to arguments to this script, the source path and the destination path. The script is expected to create directory of the destination path as neccessary and copy the whole contents of the source path to the destination path. 10) Know Bugs. - In rare cases Mails send by Minkowsky contain corrupted data. Reason for that is still unknown. - Appointments and Task containing users no longer listed in DATA_PATH/users, may cause a crash of the server. The same applies to groups and rooms no longer listed. This bug should be fixed at most places by now. However, I am not absolutely sure if I found any place this bug was present. Apart from this bug it seems to be advisable to keep any user, group or room listed to keep the information on older appointments etc. complete. - There might be some parts of the code where translations are incomplete, especially in the server code. - Don't use braces in any text you enter into Minkowsky. Although there is code in the client to suppress using braces in entry-widget and replace them in text(-area)-widgets there might be still some places missing this new code. 11) Future plans - Complete translation - PDA synchronization - several small things - ???