Troubleshooting LDAP problems upgrading from 1.3 to 1.4

There have been a few last minute changes in the LDAP directory configuration in the last releases of the 1.3 development series. These changes have made providing an easy upgrade path from 1.3.X to 1.4 quite complicated.

While we would have loved to make the 1.3.X to 1.4 migration completely smooth, we had to focus in the 1.2 to 1.4 migration, and here were different problems involved depending on the 1.3 version from where you were migrating.

This document has been written to provide some guidance in the troubleshooting process of a 1.3 to 1.4 upgrade. If you run into problems not described here or need further help, don't hesitate to post a message in our forum,  http://forum.zentyal.com

After taking the usual precautions (backup, perform in a testing machine rather than in the production machine), upgrade to the latest 1.4 version.

At this point, we can already warn you, it won't work out of the box. Probably your slapd will be stopped and the installation will return some kind of error.

You can check if the slapd package was correctly configured by running:

dpkg -l | grep slapd

If there was a configuration error you'll see something like:

iF    slapd                     2.4.21......

For more diagnostics, and only if slapd is not running (check with ps aux | grep slapd), run:

sudo /usr/sbin/slapd -d 256 -h "ldap:/// ldapi:///" -g openldap -u openldap -F /etc/ldap/slapd.d/

Probably you'll get an error like:

@(#) $OpenLDAP: slapd 2.4.18 (Jan  8 2010 10:48:43) $
        buildd@plutonium:/build/buildd/openldap-2.4.18/debian/build/servers/slapd
config error processing olcDatabase={0}config,cn=config: ordered_value_sort failed on attr olcAccess

slapd stopped.
connections_destroy: nothing to destroy.

This is caused by a problem with the ACLs, you can make sure of it by running:

sudo cat /etc/ldap/slapd.d/cn\=config/olcDatabase={0}config.ldif

The output should look like:

dn: olcDatabase={0}config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootDN: cn=admin,cn=config
olcRootPW:: e2NyeXB0fUFlL1VuLjgzYldNMms=
olcAccess: to * by dn.exact=cn=localroot,cn=config manage by * break
structuralObjectClass: olcDatabaseConfig
entryUUID: 3f2721da-4935-102e-834d-8702370b30f5
creatorsName: cn=config
createTimestamp: 20091009153624Z
olcAccess: {0}to * by dn="cn=ebox,dc=vibrobloc,dc=locale" write

The problem is the two olcAccess lines, you need to edit that file with your favorite editor and put the two olcAccess lines together making them look like:

olcAccess: {0}to * by dn.exact=cn=localroot,cn=config manage by * break
olcAccess: {1}to * by dn="cn=ebox,dc=vibrobloc,dc=locale" write

Then delete the slapd.postinst file (or it'll mess up the file again):

sudo rm /var/lib/dpkg/info/slapd.postinst

and run:

sudo dpkg --configure -a

After this, the slapd daemon should begin working, and there is only one more thing to fix. In /etc/ldap/slapd.d/cn\=config/olcDatabase\=\{-1\}frontend.ldif , you should have a single olcAccess line like:

olcAccess: {0}to * by dn.exact=cn=localroot,cn=config manage by * break

You need to add two more lines:

olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to dn.base="cn=subschema" by * read

There have been two problems related with the master/slave LDAP schemas. The normal scenario is that you have the old master/slave schemas but the new code needs new ones. You can update them manually following

There have been some changes in the master and slaves schemas, and you have to update them manually. The process for that is the following. First of all, run:

hardy2% sudo ls /etc/ldap/slapd.d/cn\=config/cn\=schema
cn={0}core.ldif		  cn={4}passwords.ldif	cn={8}eboxmail.ldif
cn={1}cosine.ldif	  cn={5}master.ldif	cn={9}eboxfetchmail.ldif
cn={2}nis.ldif		  cn={6}slaves.ldif
cn={3}inetorgperson.ldif  cn={7}authldap.ldif

The output should be similar to that one.

Then you should run (changing the numbers appropriately according to the result of the previous command):

sudo /etc/init.d/slapd stop
sudo cp /usr/share/ebox-usersandgroups/master.ldif /etc/ldap/slapd.d/cn\=config/cn\=schema/cn\=\{5\}master.ldif
sudo cp /usr/share/ebox-usersandgroups/slaves.ldif /etc/ldap/slapd.d/cn\=config/cn\=schema/cn\=\{6\}slaves.ldif

These files still need some small adjustments, you'll have to edit both of them:

/etc/ldap/slapd.d/cn\=config/cn\=schema/cn\=\{5\}master.ldif
/etc/ldap/slapd.d/cn\=config/cn\=schema/cn\=\{6\}slaves.ldif

And change the first line of them from, respectively:

dn: cn=master,cn=schema,cn=config
dn: cn=slaves,cn=schema,cn=config

to

dn: cn={5}master
dn: cn={6}slaves

again using the appropriate numbers.

And now you can restart slapd:

sudo /etc/init.d/slapd start

and the 'users' module:

sudo /etc/init.d/ebox users restart

And all the modules that depend on it, e.g., mail or samba:

sudo /etc/init.d/ebox mail restart

If you actually have configured slave machines, you'll need to do the following, replacing 'dc=hardy2' with your actual base DN:

#install ldapvi
sudo apt-get install ldapvi
ldapvi -D 'cn=ebox,dc=hardy2' --bind simple -w $(sudo cat /var/lib/ebox/conf/ebox-ldap.passwd) -b 'dc=hardy2'

That will open a vi (or other) editor session with the contents of your LDAP. Look for the slave entries, that will look like this:

7 hostname=hardy1,ou=slaves,dc=hardy2
objectClass: slaveHost
hostname: hardy1

Add a new line right after hostname so it looks like:

7 hostname=hardy1,ou=slaves,dc=hardy2
objectClass: slaveHost
hostname: hardy1
port: 443

Then exit saving changes.

An extra problem, that I don't know how happened but has been reported by a user is missing master and slave schemas. If that is your case, you'll get an error like this:

/etc/init.d/ebox users restart
 * Restarting eBox module: users
   ...fail!
Unknown error at EBox::UsersAndGroups::_loadCertificates objectClass: value #0 invalid per syntax

You can fix this by running:

sudo ldapadd -H 'ldapi://' -Y EXTERNAL -c

It will wait for your input and then you can paste:

include: file:///usr/share/ebox-usersandgroups/master.ldif
include: file:///usr/share/ebox-usersandgroups/slaves.ldif

Then restart users again as shown above.