slapd failed to install/upgrade: database (dc=xxx,dc=xxx,dc=xx) not configured to hold "dc=nodomain"

Francisco,

thanks for taking the time to report this. To help track down the source of the problem it will help if you can attach the logs from your upgrade. These can be found in /var/log/dist-upgrade.

thanks,
Richard

I have attached all files in the directory /var/log/dist-upgrade

thanks Francisco

Complete set of logs supplied, setting status to confimed.

Hi! I have the same problem here while trying to release-upgrade to hardy from dapper (see also Bug #218311). I just found out what the problem is:

There were two entries in my LDAP database related to a dc=nodomain. I do not know where they came from. These entries keep slapadd from re-inserting the dumped database after the upgrade. I fixed it by removing them:

1. stop your slapd
2. slapcat your DB to a file.
3. make a backup of that file, and your LDAP DB under /var/lib/ldap, just in case...
4. edit that file with a text editor, remove both entries under dc=nodomain
5. remove everything under /var/lib/ldap
6. re-insert your DB with slapadd
7. start slapd.

Now these entries are gone, and the upgrade to the new slapd version starts again.

As the upgrade to the new slapd version went through, I can no longer log in when ldap is enabled in nsswitch.conf, but this would be a problem with libnss-ldap. Concerning this bug here, the postinst script should somehow remove the invalid entries from the ldap database before reinsertion, or (I don't know if it's possible to have more than one basedn in one bdb) rewrite the dump to make it work.

If you want me to test potentially fixed packages, I still have the virtual machine snapshot before the upgrade.

Ciao

Martin

Hello,

I justed tested upgrading from Dapper to Hardy once with slapd installed but not configured, and once with the LDAP db populated and the system configured to use it for authentication. Both upgrades worked without issue.

I didn't test from Feisty to Gutsy, just FYI :-).

Preparation of replacing slapd 2.3.35-1ubuntu0.2 (using .../slapd_2.4.7-6ubuntu3_i386.deb) ...
Stopping OpenLDAP: slapd.
   Dumping to / var/backups/slapd-2.3.35-1ubuntu0.2:
   -- Directory dc = example, dc = com ... bdb_db_open: only one allowed suffix
backend_startup_one: bi_db_open failed! (-1)
slap_startup failed
failed.
dpkg: error processing / var/cache/apt/archives/slapd_2.4.7-6ubuntu3_i386.deb (- unpack):
  the sub-processes pre-installation script has returned an error Release 1 state
   Backing up / etc / ldap / slapd.conf in / var/backups/slapd-2.4.7-6ubuntu3 ... done.
Starting OpenLDAP: slapd.
Mistakes have been encountered during the execution:
  / var/cache/apt/archives/slapd_2.4.7-6ubuntu3_i386.deb
E: Sub-process / usr / bin / dpkg returned an error code (1)

While updating from Gutsy Gibbon 7.10 to Hardy Heron 8.04
I got a number of error messages saying that it could not update/install slapd.

--------
Could not install /var/cache/apt/archives/slapd_2.4.7-6ubuntu3_i386.deb

The upgrade will continue but the '/var/cache/apt/archives/slapd_2.4.7-6ubuntu3_i386.deb' package may be in a not working state. Please consider submitting a bugreport about it.

subprocess pre-installation script returned error exit status 1

-------------
Could not install 'slapd'

The upgrade will continue but the 'slapd' package may be in a not
working state. Please consider submitting a bugreport about it.

package slapd is already installed and configured

---------------
Sorry, the package 'slapd'. failed to install or upgrade.
Please report the error.

--------------------

Perhaps not too surprising as I had installed slapd from source tar file in order to get a newer version
which fixed bug in perl-backend.

Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately we can't fix it without more information.

Could you attach the content of the file /etc/ldap/slapd.conf (with relevant private information such as passwords and rootdn obfuscated)?

I've also hit this on upgrade. It seems like the situation might be slightly complex.
My ldap config does not use the slapd.conf method, but cn=config.

/etc/ldap/ldap.conf contains:

    BASE dc=company, dc=com
    URL ldap://localhost/

Running dpkg --configure gives:

    sudo dpkg --configure slapd
    Setting up slapd (2.4.15-1ubuntu3) ...
      Backing up /etc/ldap/slapd.d/ in /var/backups/slapd-2.4.11-0ubuntu6.1... done.
      Moving old database directories to /var/backups:
      Loading from /var/backups/slapd-2.4.11-0ubuntu6.1:
      - directory dc=company,dc=com... failed.

    Loading the database from the LDIF dump failed with the following
    error while running slapadd:
        slapadd: line 1: database (dc=company,dc=com) not configured to hold "dc=nodomain"
        slapadd: line 1: database (dc=company,dc=com) not configured to hold "dc=nodomain"
    dpkg: error processing slapd (--configure):
     subprocess post-installation script returned error exit status 1
    Errors were encountered while processing:
     slapd

The contents of the /var/backups/slapd-2.4.11-0ubuntu6.1 directory:

    100 -rw-r--r-- 1 root root 94218 2009-05-22 14:10 dc=company,dc=com.ldif
      4 drwxr-x--- 3 openldap openldap 4096 2009-05-22 15:13 slapd.d

Look at the .ldif mentioned there, it contains the following two entries:

    dn: dc=nodomain
    objectClass: top
    objectClass: dcObject
    objectClass: organization
    o: nodomain
    dc: nodomain
    structuralObjectClass: organization
    entryUUID: cc19087c-404b-102d-96c3-01fea4f68a30
    creatorsName:
    createTimestamp: 20081106124011Z
    entryCSN: 20081106124011.789553Z#000000#000#000000
    modifiersName:
    modifyTimestamp: 20081106124011Z

    dn: cn=admin,dc=nodomain
    objectClass: simpleSecurityObject
    objectClass: organizationalRole
    cn: admin
    description: LDAP administrator
    userPassword:: <PASSWORDHASHHERE>
    structuralObjectClass: organizationalRole
    entryUUID: cc19c4b0-404b-102d-96c4-01fea4f68a30
    creatorsName:
    createTimestamp: 20081106124011Z
    entryCSN: 20081106124011.794497Z#000000#000#000000
    modifiersName:
    modifyTimestamp: 20081106124011Z

But _also_ sections like these with the correct dc=company,dc=com.

My wild guess is that /var/lib/dpkg/info/slapd.postinst is at fault, specifically

set_defaults_for_unseen_entries() with it's:

    DOMAIN=`hostname -d 2>/dev/null` || true
    if [ -z "$DOMAIN" ]; then DOMAIN='nodomain'; fi

Wouter van Heyst

Removing the two stray dc=nodomain entries from the .ldif, and rerunning dpkg --configure slapd, everything now completes. I'll sacrifice another machine to see if I can catch where the nodomain entries are coming from in the first place.

We'd like to figure out what's causing this bug for you, but we haven't heard back from you in a while. Could you please provide the requested information? Thanks!

What information is it that you want?

How did you create the initial configuration?

If there are nodomain entries, it means that the domainame of the system wasn't setup correclty when slapd was *first* installed.

How did you add the dc=company,dc=com sub-tree? Is it a different database definition?

Could you attach the content of /etc/ldap/slapd.d/ (with the password removed)?

We'd like to figure out what's causing this bug for you, but we haven't heard back from you in a while. Could you please provide the requested information? Thanks!

Hello,
Sorry for not responding quickly!
I no longer use the directory server with OpenLDAP or slapd or ldap.
If later, I take this program, I will come to you to report any problems.
In case it is absolutely necessary to test this program for its operation, asks me;
I take the time needed for testing, but not until mid December.
Thank you for your response and your help.
Best regards

slave install:
    apt-get install slapd
    /etc/init.d/slapd stop
    pushd /etc/ldap/
    rm -rf schema/ slap.d/*
    rsync -avP server:/etc/ldap/{schema,slave-slapd.conf} .
    slaptest -f slave-slapd.conf -F slapd.d
    chown -R openldap:openldap slapd.d
    /etc/init.d/slapd start

Now, the slave-slapd.conf is set up to sync the dc=company,dc=com tree.

    syncrepl rid=1234
            provider=ldap://server:389/
            type=refreshAndPersist
            searchbase="dc=company,dc=com"
            bindmethod=simple
            binddn="cn=slapd-sync,ou=System users,dc=company,dc=com"
            credentials=password
            retry="60 10 300 +"

slave-slapd.conf doesn't contain any mention of 'nodomain', nor does
grep find it (currently, if it ever was there) in server:/etc/ldap/slapd.d/*

Can I join this problem?

I've upgraded from Edgy to Karmic - this is a development machine so I'm not too worried failure, however everything seemed to work okay which was pretty amazing as I came through a number of EOL supported releases.

Anyways, the point of doing this upgrade was to test my my application with OpenLDAP, however my LDAP system won't now run.

PS I did have the LDAP server working on Edgy before this started...

Through the upgrade I was getting errors about SLAPD regarding <schemacheck> and <checkpoint> not being valid directives... so I commented them out. And tried to continue. Then I was getting errors about the database can't be opened so I tried to remove the package and then --reinstall and now I'm getting a version error:

root@rimu:~# sudo apt-get install slapd ldap-utils
Reading package lists... Done
Building dependency tree
Reading state information... Done
slapd is already the newest version.
ldap-utils is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0B of additional disk space will be used.
Setting up slapd (2.4.18-0ubuntu1) ...
  Backing up /etc/ldap/slapd.conf in /var/backups/slapd-2.2.26-5ubuntu3.3... done.
failed.

Migrating slapd.conf file (/etc/ldap/slapd.conf) to slapd.d failed with the following error while running slaptest:
    bdb(dc=myfocus,dc=com): Program version 4.7 doesn't match environment version 0.33
    bdb_db_open: database "dc=myfocus,dc=com" cannot be opened, err -30971. Restore from backup!
    backend_startup_one (type=bdb, suffix="dc=myfocus,dc=com"): bi_db_open failed! (-30971)
    slap_startup failed (test would succeed using the -u switch)
dpkg: error processing slapd (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 slapd
E: Sub-process /usr/bin/dpkg returned an error code (1)

I just want to get OpenLDAP working again. How can I now get to a fresh install of this package??? Any attempt to remove or install now results in this same error!

HHHEEELLLPPP I'm absolutely stuck with no where to go.... well, maybe with the exception of some other Linux version...

PS I'll upload my slapd.conf as well. Let me know if you need anything else.

Cheers
Murray

Murray,
While they both do involve a failure of the configuration process for the slapd package during an upgrade, I think the original bug report and your problem have separate root causes.

In particular, the problem discussed in the original bug report relates to problems caused by invalid records that somehow crept into the LDAP database (but which were in that database before the package upgrade was started).

In your case, though, there's no problem with the data in the LDAP database; instead you are getting errors caused by the fact that between Edgy and Karmic the openldap packages switched from v4.2 to v4.7 of the Berkeley Database libraries, and so the newly-install tools are refusing to work with the existing database files. (The DB-library version change is mentioned in the Debian changelog entry for openldap v2.4.15-1 .)

Anyway, I am running into this same problem when attempting to upgrade from Hardy directly to Lucid. Since that's an LTS-to-LTS upgrade, I believe it's supposed to be a supported upgrade path, and so I opened a bug report on that particular issue, bug #536958. Your situation (Edgy -> Karmic) is a little different, but if a workaround or fix is found for that bug perhaps it will apply to your sitation as well....

Nathan