[Limacute-commit] r134 - trunk/RPM/PKG
limacute at projects.linpro.no
limacute at projects.linpro.no
Mon Apr 23 23:28:06 CEST 2007
Author: limacute
Date: 2007-04-23 23:28:05 +0200 (Mon, 23 Apr 2007)
New Revision: 134
Modified:
trunk/RPM/PKG/1st.README
trunk/RPM/PKG/UPGRADING.20-21
Log:
Readme from rc2.
Modified: trunk/RPM/PKG/1st.README
===================================================================
--- trunk/RPM/PKG/1st.README 2007-04-23 21:21:23 UTC (rev 133)
+++ trunk/RPM/PKG/1st.README 2007-04-23 21:28:05 UTC (rev 134)
@@ -1,28 +1,20 @@
Kolab2 Server Install and Upgrade Information
=============================================
-For more information on Kolab, see http://www.kolab.org
+For more information about Kolab, see http://kolab.org/
+
Quick install instructions
--------------------------
-For a fresh install /kolab needs to be an empty directory with enough space.
-You can use a symlink, but do _not_ use an NFS mounted drive.
+For a fresh install /kolab needs to be an empty directory with at least 1GB of
+free disk space. You can use a symlink, but do _not_ use an NFS mounted drive.
Make sure that the following names are not in /etc/passwd or /etc/groups,
as openpkg will want to create them: "kolab" "kolab-r" "kolab-n"
-Check the www.openpkg.org documentation for your platform.
-E.g. some platforms need gettext installed
-or the locale set to C during installation, like:
- LC_ALL=C
- LC_MESSAGES=C
- LANG=C
- SUPPORTED=C
- export LC_ALL LC_MESSAGES LANG SUPPORTED
+Check http://www.openpkg.org/documentation/ for additional documentation
+for the OpenPKG packaging system.
-Make sure the locale you want to set is supported by your c-library.
-Otherwise the webadmin interface might only be in English.
-
To install the Kolab2 server, you need to download the files from the
directory containing this file (1st.README) to some local directory,
then as root, chdir into that local directory and run
@@ -58,24 +50,24 @@
# ./obmtool kolab
obmtool will usually automatically determine which packages need to be
-built. If you have made changes to the configuration files in
-/kolab/etc/kolab/templates/ and the new release has a new kolabd package
-you may need to transfer your changes from the backups created by rpm
-(the *.rpmsave) files to the new template files. Then regenerate the
-configuration with
+built. If you have made changes to configuration files or an updated
+package includes configuration files which are usually regenerated from
+files in /kolab/etc/kolab/templates/ the old configuration file will be
+saved with the extension .rpmsave. For files generated from templates
+you just have to remove the rpmsave file, because services will refuse
+to start if there still is an rpmsave file, e.g.:
-# /kolab/sbin/kolabconf
+# rm /kolab/etc/clamav/*.conf.rpmsave
+For other changed files (e.g. the template files themselves) you may
+want to transfer your changes from the .rpmsave backup to the new files.
-You may want to check the permissions of your files in /kolab/etc/kolab/
-after installing or upgrading, as there have been problems with this in
-the past. Especially kolab.conf and copies shall only be readable to
-the owner (usually "kolab"). The installation and configuration scripts
-should make sure that the permissions are correct but there's a chance
-that the permissions can still go wrong, especially if you upgrade from
-pre Beta1 releases.
+Then regenerate the configuration and restart Kolab with:
+# /kolab/sbin/kolabconf
+# /kolab/bin/openpkg rc all restart
+
Upgrading from earlier versions
-------------------------------
@@ -99,8 +91,8 @@
http://kolab.org/cgi-bin/viewcvs-kolab.cgi/*checkout*/doc/raw-howtos/kolab_2.0_to_2.1_upgrade_instructions.txt
Please read carefully all the following update instructions in this
-file, while some of the information might be redundant there are
-additional notes which are essential for an successful update.
+file, while some of the information will be redundant there might
+be additional notes which are essential for an successful update.
Upgrade from pre-2.1-snapshot-20051130
@@ -264,4 +256,72 @@
or set the value to 1.
-$Id: README.1st,v 1.43 2007/01/17 13:41:27 thomas Exp $
+Upgrade from 2.1-beta-4
+-----------------------
+
+Nothing special has to be done for this upgrade.
+
+
+Upgrade from 2.1-rc-1
+---------------------
+
+The database backend for the free/busy cache was changed to solve licensing
+issues between php4+ and gdbm. See kolab/issue1607 for details.
+
+The old cache file has to be deleted manually:
+
+ rm /kolab/var/kolab/www/freebusy/cache/pfbcache.db
+
+Then updating the free/busy cache has to be triggered for all calendar
+folders of all accounts:
+- Users need to create or update an appointment in their folders.
+- Resources can be invited to a new appointment or send them an update
+ to an existing appointment.
+
+Alternatively you can trigger each folder with an https request:
+https://[server]/freebusy/trigger/[email]/[path_to_calendar_folder].pfb,
+e.g. https://kolab.example.com/freebusy/trigger/user@example.com/Calendar.pfb
+(you need to authenticate with the user's credentials)
+
+
+Known problems and workarounds
+------------------------------
+
+ - Your system (C library) has to support all languages you want to have
+ available in the web admin interface and fbview. For most languages you
+ have to use the non-UTF-8 and non-euro locales, i.e. de_DE, fr_FR,
+ it_IT, nl_NL instead of e.g. de_DE at euro. For fbview some languages need
+ a UTF-8 locale, e.g. ja_JP.UTF-8 for Japanese.
+ See kolab/issue881 and kolab/issue1585 for details.
+
+ - Under some circumstance the Kolab server may not create or delete
+ users or update the configuration after changes have been made in
+ the web interface. This happens most often immediately after the
+ bootstrap. In that case restart the kolabd:
+
+ /kolab/bin/openpkg rc kolabd restart
+
+ If user accounts are still not created or deleted, you can try removing
+ the file /kolab/var/kolab/mailbox-uidcache.db and restarting kolabd.
+
+ See kolab/issue1068 (Mailboxes are not created until kolabd restart)
+ and kolab/issue1098 (Changes in the service tab are not accepted after
+ bootstrap) for details.
+
+ - If modifying or deleting of address book entries doesn't work,
+ restarting openldap can help, see kolab/issue854 for details.
+
+ - There is a report that the manager can only see users in the primary
+ domain, see kolab/issue1485. We can't reproduce this problem, please
+ tell us if you can.
+
+ - Calendar folders for group/resource accounts can't be created for
+ domains which were added after bootstrap, i.e. via the web admin
+ interface. See kolab/issue1313 for details.
+
+ - When deleting domains via the web admin interface, the corresponding
+ LDAP data and IMAP spool stay on the server and have to be deleted
+ manually. See kolab/issue1571 and kolab/issue1576 for details.
+
+
+$Id: README.1st,v 1.54 2007/04/20 10:24:31 thomas Exp $
Modified: trunk/RPM/PKG/UPGRADING.20-21
===================================================================
--- trunk/RPM/PKG/UPGRADING.20-21 2007-04-23 21:21:23 UTC (rev 133)
+++ trunk/RPM/PKG/UPGRADING.20-21 2007-04-23 21:28:05 UTC (rev 134)
@@ -1,37 +1,40 @@
Upgrade Kolab Server from 2.0.x to 2.1
======================================
-Preliminary instructions for the upgrade of a Kolab Server from version
-2.0.x to Kolab Server 2.1.
+Instructions for upgrading Kolab Server 2.0.4 to 2.1.0
-NOTE: This is an early version of the upgrade instructions. It is not
-very well tested and may not cover all problems that may occur during
-the upgrade. Before attempting the upgrade, make sure you have a
+NOTE: Before attempting the upgrade, make sure you have a
current and working backup of your data.
Preparation for the Upgrade
---------------------------
-1. Backup the old installation.
+1. Stop the Kolab Server and related cronjobs:
+ Comment out all OpenPKG entries in /etc/crontab, then run:
-2. Stop the Kolab Server
+ # /kolab/bin/openpkg rc all stop
- /kolab/bin/openpkg rc all stop
+2. Backup the old installation:
-3. Extract ldap data
+ You could use rsync on the running server and then rsync again
+ to transfer only changed files to keep the downtime short.
-Copy the contents of the openldap database (use a different output
-filename if you want):
+3. Extract ldap data:
- /kolab/sbin/slapcat > ~/kolab-2.0.ldif
+ Copy the contents of the openldap database, use a different output
+ filename if you want. You should make sure that no other users can
+ read the sensitive data contained in the ldif file, e.g. with umask:
+ # umask 077
+ # /kolab/sbin/slapcat > ~/kolab-2.0.ldif
+
4. Prepare for berkeley db update
- cd /kolab/var/imapd/db
- /kolab/bin/db_recover
- rm /kolab/var/imapd/db/*
+ # cd /kolab/var/imapd/db
+ # /kolab/bin/db_recover
+ # rm /kolab/var/imapd/db/*
Installation
@@ -57,7 +60,7 @@
renamed. There might be more files with the .rpmsave ending in
/kolab/etc, you can find them for example using the find command:
-find /kolab/etc -name '*.rpmsave'
+ # find /kolab/etc -name '*.rpmsave'
Any files found must be checked and moved out of the way, in most
cases they can just be deleted.
@@ -80,6 +83,30 @@
https://intevation.de/roundup/kolab/issue1089
+The default database format for /kolab/var/imapd/annotations.db and
+/kolab/var/imapd/mailboxes.db has changed from skiplist to berkeley db.
+
+If you want to keep the old format, comment out or remove the lines
+"annotation_db: berkeley" and "mboxlist_db: berkeley" in the file
+"/kolab/etc/kolab/templates/imapd.conf.template" and make sure the file
+"/kolab/etc/imapd/imapd.conf" reflects this, too.
+
+To convert the databases to berkeley db format, execute as root:
+
+ # su - kolab-r
+ $ cd /kolab/var/imapd/
+ $ mv annotations.db annotations.db-skiplist
+ $ cvt_cyrusdb /kolab/var/imapd/annotations.db-skiplist skiplist \
+ /kolab/var/imapd/annotations.db berkeley
+ $ mv mailboxes.db mailboxes.db-skiplist
+ $ cvt_cyrusdb /kolab/var/imapd/mailboxes.db-skiplist skiplist \
+ /kolab/var/imapd/mailboxes.db berkeley
+ $ exit
+
+See http://wiki.kolab.org/index.php/Kolab2_IMAPD_annotations.db_Problems
+for details about this topic.
+
+
3. LDAP
You need to make two small changes to the configuration file
@@ -105,15 +132,17 @@
http://kolab.org/cgi-bin/viewcvs-kolab.cgi/*checkout*/utils/admin/convert-ldif-21.py
-The script works on the ldif data that was exported with slapcat earlier:
+The script works on the ldif data that was exported with slapcat earlier,
+it requires python-ldap:
- python convert-ldif-21.py ~/kolab-2.0.ldif ~/kolab-2.1.ldif
+ # umask 077
+ # python convert-ldif-21.py ~/kolab-2.0.ldif ~/kolab-2.1.ldif
-Then restore the openldap data using the output from upgrade-ldap.py:
+Then restore the openldap data using the output from convert-ldif-21.py:
- rm /kolab/var/openldap/openldap-data/*
- /kolab/sbin/slapadd -l ~/kolab-2.1.ldif
+ # rm /kolab/var/openldap/openldap-data/*
+ # /kolab/sbin/slapadd -l ~/kolab-2.1.ldif
This will issue some warnings which can be safely ignored.
@@ -122,11 +151,11 @@
Now start the openldap server and run kolabconf
- /kolab/bin/openpkg rc openldap start
- /kolab/sbin/kolabconf
+ # /kolab/bin/openpkg rc openldap start
+ # /kolab/sbin/kolabconf
-Kolabconf will might complain about be some files ending .rpmnew under
+Kolabconf might complain about be some files ending .rpmnew under
/kolab/etc. Check those files and move them out of the way. It's
likely that you can simply remove them.
@@ -136,9 +165,41 @@
Now you should be able to start the server again:
- /kolab/bin/openpkg rc all start
+ # /kolab/bin/openpkg rc all start
+Resource Accounts
+-----------------
+
+With server version 2.1 the way in which the kolab resource manager
+accesses the calender folders of resources has changed. To make old
+resource accounts work after the upgrade, you have to grant access to
+the resources imap folders to the so called calender user.
+
+First you have to identify the existing resource accounts, this can be
+done using the convert-ldif-21.py script, which was introduced in the
+section on converting the LDAP data.
+
+ # python convert-ldif-21.py --list-resources ~/kolab-2.0.ldif
+
+lists the UIDs (normally the email addresses) of all resource accounts.
+
+Now you have to add ACLs to the mailboxes of the resources, which
+allow the calendar user to access them. Per default the calendar user
+is calendar at YOUR_DOMAIN:
+
+Connect with cyradm to the Kolab imap server as user manager:
+
+ # /kolab/bin/cyradm -u manager localhost
+
+Then use the `setaclmailbox' command (sam) to set the necessary
+permissions. You can generate a list of commands which should do the
+right thing on most standard installations with:
+
+ # python convert-ldif-21.py --list-resources ~/kolab-2.0.ldif | \
+ sed 's-\(.*\)\(@.*\)-sam */\1*\2 calendar\2 all-'
+
+
Final Steps
-----------
@@ -151,11 +212,29 @@
2. Kolab 2.1 doesn't need some of the OpenPKG packages which were
installed for 2.0, these can be removed:
- /kolab/bin/openpkg rpm -e dcron vim pth
+ # /kolab/bin/openpkg rpm -e dcron vim pth
Especially the dcron package should be removed in any case,
otherwise deprecated cronjobs will be run and generate mails with
error messages to the kolab administrator.
+3. Activate the entries for OpenPKG in /etc/crontab again.
-$Id: kolab_2.0_to_2.1_upgrade_instructions.txt,v 1.4 2006/11/15 17:37:40 thomas Exp $
+4. The database backend for the free/busy cache was changed to solve licensing
+ issues between php4+ and gdbm. See kolab/issue1607 for details.
+ The old cache file has to be deleted manually:
+
+ # rm /kolab/var/kolab/www/freebusy/cache/pfbcache.db
+
+ Then updating the free/busy cache has to be triggered for all calendar
+ folders of all accounts:
+ - Users need to create or update an appointment in their folders.
+ - Resources can be invited to a new appointment or send them an update
+ to an existing appointment.
+
+ Alternatively you can trigger each folder with an https request:
+ https://[server]/freebusy/trigger/[email]/[path_to_calendar_folder].pfb,
+ e.g. https://kolab.example.com/freebusy/trigger/user@example.com/Calendar.pfb
+ (you need to authenticate with the user's credentials)
+
+$Id: kolab_2.0_to_2.1_upgrade_instructions.txt,v 1.12 2007/04/20 15:01:05 thomas Exp $
More information about the Limacute-commit
mailing list