[Kolab-devel] Draft instructions for server upgrade 2.0 to 2.1

[ITSEF Admin]

On Thursday 12 October 2006 18:34, Bernhard Herzog wrote:
[...]
> Upgrade Kolab Server from 2.0.x to 2.1
> ======================================
[...]

Some initial remarks: I'm in the process of doing a migration from server A 
with Kolab 2.0.4 to server B with Kolab 2.1 while at the same time changing 
the domain from OLD_DOMAIN to NEW_DOMAIN. Hence, your upgrade instructions 
don't apply 100%, but I think I can use parts of it and therfore, some of my 
observations might be of interest.

For transferring the accounts, I used a slightly different approach:
- Get kolab-2.0.ldif as described on server A
- Edit the file to replace all occurrences of OLD_DOMAIN with NEW_DOMAIN 
(including dc etc.)
- Convert it to 2.1 format as described into kolab-2.1.ldif
- Install 2.1 on server B - including "kolab_bootstrap -b"
- Get LDAP info of server B with slapcat into kolab-2.1-default.ldif
- Compare kolab-2.1-default.ldif and kolab-2.1.ldif and remove every instance 
in kolab-2.1.ldif that is already present in kolab-2.1-default.ldif
- Run /kolab/sbin/slapadd -l ~/kolab-2.1.ldif

That went fine up to the point where it tried to add an entry for a person 
with an ë (e-'umlaut') in her name. The entry started like this (mangled to 
protect the innocent...):
dn:: Y249SGV......==
I assume, this is some kind of base64 or suchlike? In any case, this resulted 
in an error message from slapcat:
slapadd: line 303: database (dc=NEW,dc=DOMAIN) not configured to hold "cn=NAMë 
SURNAME,dc=OLD,dc=DOMAIN".
The reason for this seems simple (now that I look at it...): As the dn/cn was 
encoded, I missed it when replacing the domain, thus causing slapcat to balk. 
I don't exactly know how to work around this right now, but maybe somebody 
else who wants to do something similar is now warned about this catch with 
this mail... :-}

Cheerio,

Thomas

P.S.: Initially, I tried this with the complete kolab-2.1.ldif, as you 
described:
[...]
>    rm /kolab/var/openldap/openldap-data/*
>    /kolab/sbin/slapadd -l ~/kolab-2.1.ldif
[...]
But somehow, this resulted in LDAP problems (some errors about "invalid 
credentials" kept popping up) - might be due to the same problem as above....