Migrating from Open Xchange 5 to Debian Kolab
From Kolab Wiki
This document describes how to migrate from Open Xchange (OX) 5 on Suse to Kolab on Debian
Please note that this is an advanced topic. You should have a decent knowledge about Debian and SuSE
Contents |
Basics
We use quite some scripting to migrate most data automatically. However some patches to kolab are needed in order to be able to support some of the features known from OX. The most severe change is a way to allow kolab to work with posixAccounts and posixGroups (that is handling of unix system users). As this process is experimental, I reconnomend to run both systems in parallel, in order to get things right on the kolab side before doing the switch. Your old OX installation is virtually unaffected by the migration.
Preparations
Obviously you need to get a running kolab system first. I used Debian - natively packages. Aditionally some common tools like rsync are needed. The scripts will complain if they are missing. So please
- install kolab on debian testing
- install php-auth-sasl The debian package seems to miss this depend
- install kolab-webfrontend from debian experimental
- install php5-recode (calendar import asks for it later)
- install sun-java6-jre, my migration tool needs this. You can safely remove it afterwards. Note that this is in debian non-free
- install php5-idn for international domain names
- install ldap-account-manager. We need it as we will break kolabs account handling
After setup visit https://yourFQDN/horde3/test.php to check if the webinterface is ok.
Patches
We need to apply a bunch of patches against kolab. Download media:OX-Kolab-patches.zip. They do some changes to the user handling: Users are stored in ldap under ou=people as posixAccounts. under each user we store the users private addressbook under ou=addr. Therefore every tool dealing with the users needs to look only at ou=people with scope one, in order not to get confused with the addressbooks. Kolab normally has the mail attribute set unique. This obviously conflicts with the private addressbooks (some people may have the same account in their addressbooks). Therefore we remove that constraint. The public addressbook is stored beneath cn=external. Several tools get confused when they search for a mail adress and get multiple results, therefore we need to set a few filters.
Here is an explanation of each patch:
- horde3-Kolab-Posix.patch This makes the kolabmailboxfilter aware that users are posixAccounts. IMPORTANT. Otherwise mails are dropped.
- imapd.group.template.patch The debian package has the permissions for the imap group file wrong
- kolabAdminAclselect.patch Not 100% nesseccary: Kolabadmin only allows ACLs like read/write/post, this patch enables arbitray ones
- kolabAdminAdressbook.patch This makes the kolab web admin aware of the position of the global addressbook
- kolabAdminSFPosix.patch This makes the kolab web admin aware of posixGroups and accounts for shared folders
- ldap-account-manager-search-scope-one.patch This lets the ldap-account-manager ignore users addressbooks
- libkolab-perl-Kolab.Conf.pm.patch This adds the posixGroups to the imap group file
- saslauthd.conf.patch This adds a filter for saslauthd to look only for posixAccounts. (gets confused otherwise)
- php-Kolab-Fiter-Content-eregi.patch Not 100% nesseccary: Fixes some deprecreations that otherwise spam your logs (backport)
- php-Resource-eregi-fromroot.patch Not 100% nesseccary: Fixes some deprecreations that otherwise spam your logs (backport)
- slapd.conf.template Sorry, no patch, forgot to store the original. Quite some modifications here: Adding nis schema and mozilla schmea, removing the uniq constraint for mail, setting the ACLs for the addressbooks and disabling public unauthenticated ldap access, as we need to have other servers connecting to ours, adding a few indexes for posix stuff,
Manual config changes
Use ApacheDirectoryStudio (or any other decent ldap tool) to add the posixAccount object class to manager and nobody ldap entries (imap logins fail otherwise). Turba needs to be configured to use the ldap addressbooks. You can use my one, but set bind_password and bind_dn correctly. media:turba2.zip
Migration preparation
Download the media:migration_tools.zip and set the relevant variables in migrateEnv. You will want to enable password less (i.e. public key) logins from root@kolab to root@OX.
- Stop kolabd: /etc/init.d/kolabd stop
- First migrate cyrus, step one is the Mailbox Database, use migrateMBoxList
- Run migrateLDAP. This should transfrom the ldap data to the new format: It is quickly hacked to gether but should work quite straight forward. The code is kept as simple as possible, so if things don't work out feel free to modify it (I'll welcome patches, of course). If things don't work out, I can reconnomend ApacheDirectoryStudio to find out why. It does a dry run import first.
- Rsync users home dirs using migratehomes
- Next step is syncing all emails. This might take loooong. You can repeat that if you are still experimenting and the OX system is live. Use migratemails for this.
- Reconstruct emails, fixing cyrus.header files beforehand. Use migrateMailsReconstruct
- Now we need to get all folders to lower case. This breaks consecutive rsyncs, sorry. Use migrateRenameMails.
- Next is to get the mail dir hashing right, Use migrateMoveMails
- Calendar migration is not that nice. Log into the OX box and start the export tool there to export all calendar files. You need to configure it, setting baseDN and hostname variables in the top. It changes the user password for the few seconds of export for each user. The password is restored afterwards. It will then mail the users their calendar, so they can import them in horde afterwards.
- Start kolabd: /etc/init.d/kolabd start
If things don't work out, you can use clearLDAP to set the ldap database back to its original values, and clearCyrusHeader to get the unconverted Cyrus header files back. Please note that due to the different directory structure of the email spool, consecutive rsync don't work after that point. For testing purposes, I suggest to change the find path in the script and test only a few users first.
MISC
I'm quite sure that I missed a few issues here. Feel free to contact me via email (alexg@moduleworks.com) if things don't work out, or ask at the mailing lists (but explain that you are trying to do this here). The document and knowledge stroage is currently not migrated. We did this manually.
Usage
You can use the kolab admin frontend at https://yourFQDN/admin/ to handle global adressbook and shared folders. Users CANNOT be modified there. Use the ldap-account-manager at https://yourFQDN/lam/. It needs a bit of setup first, but this is quite straight forward. Just make sure that the local part of the email adress always matches the uid. Otherwise things will go really wrong. I was unable to get the ldap-account-manager-daemon running. If you do, please drop me an email. Currently I create home dirs manually. Clients need to be configured not to use the imap adressbook but the ldap one. This is different for every client but quite fine.
Bugs
Please see https://issues.kolab.org/issue4373. Bugs 4374 and 4368 are fixed in the most recent versions.
