When upgrading the distro from lenny to sid I have faced the following
problem: after update the directory /var/lib/ldap was empty and it was
reported that slapd configuration failed. I think, it should be reported
in more verbose way, because in my case LDAP is the source of
authentication for the users.

=== console output ===
Setting up slapd (2.4.17-1) ...
  Backing up /etc/ldap/slapd.conf in /var/backups/slapd-2.4.11-1... done.
  Moving old database directories to /var/backups:
  Loading from /var/backups/slapd-2.4.11-1:
  - directory cn=centurion... failed.

Loading the database from the LDIF dump failed with the following
error while running slapadd:
    slapadd: line 1: database #1 (cn=centurion) not configured to hold
"dc=nodomain"; no database configured for that naming context
=== end ===

That happens because slapcat produces two dummy entries in the beginning
of dump output, which do not belong to "cn=centurion" context.

These two entries have to be filtered during the dumping, e.g.:

slapcat -a '(entryDN:dnSubtreeMatch:=cn=centurion)'

The post installation script should also ignore the warnings, which
slapd produces while parsing the configuration file.

The /etc/ldap/slapd.conf file is attached.

With best wishes,
Dmitry

Hi Dmitry,

Why does it produce these dummy entries?  It sounds to me like you took the
default database created at package install and changed the database suffix
without first removing the files belonging to the existing database.  That's
bound to cause problems; we could filter the slapcat output as you describe,
but I'm not confident that this filter will always DTRT, and I think it's a
rather low-priority fix to make given that your database shouldn't have
entries not rooted at the suffix anyway.

Cheers,

Hi Steve,

Thanks for your comments.
before filling in the new data. After the update I had to recover LDAP
database from backup LDIFF, which didn't contain the "erroneous" data
referring "dc=nodomain". My fault. But I couldn't avoid this trap, as I
didn't know the databases contains some extra entries describing some
other domain. So what I can suggest (and maybe you come with better
solution) is:

- Installation does not add any entries to slapd database by default,
leaving it empty. Maybe document something in README.Debian... hopefully
someone reads it.
or
- Update script checks the data for consistency after/during a dump. It
should fail the package update, asking the administrator to fix the
database before doing the actual update. Otherwise update will fail at
later stage, leaving the database empty which is a catastrophe.

I had another case of this same problem on Squeeze upgrade.  It was
quite confusing to me, as I am not experienced with LDAP and only had it
installed for another application.  I changed the root DN after the
initial install, because the other application required it.  I had no
idea that this would put my database in a conflicting state.

It would be really nice to help the user with this issue.  I agree with
the suggestions from Dmitri.  But even simpler than that, you could
point to some troubleshooting documentation when the reload fails, with
clear instructions on how to resolve the problem:

    Open up the .ldif backup in a text editor.  Modify the DN of the
    first two entries to match the current rootdn.

Or maybe just delete these first two entries?  I'm not sure what they're
for.

Andrew