error during slapd configuration: chown: cannot access `olcDbDirectory\nolcDbDirectory'

Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find.

Relevant error:

Setting up slapd (2.4.18-0ubuntu1) ...
  Backing up /etc/ldap/slapd.d/ in /var/backups/slapd-2.4.15-1ubuntu3... done.
  Enabling LDAPv2 support... chown: cannot access `olcDbDirectory\nolcDbDirectory': No such file or directory
dpkg: error processing slapd (--configure)

I was wondering if you you were still having this problem.

Thanks
chuck

Was this an upgrade from an existing system?

Yes, I have upgraded from Ubuntu 9.04. Still I am unable to start my LDAP.

 --
With Best Regards,
Md. Afzalur Rashid
      System Developer , sun certified professional
Escenic AS
13-15 Sommerrogt, Solli,
Oslo 0255, Norway

Norway cell:+4740464178
Bangladesh cell: +8801614099336,
+8803772005311,+008801730330054
skype: afzalur.rashid
yahoo:<email address hidden>
gmail:<email address hidden>
escenic mail: <email address hidden>

Do not count your age by years ,count it by Friends

________________________________
From: Mathias Gug <email address hidden>
To: <email address hidden>
Sent: Fri, November 13, 2009 9:44:47 PM
Subject: [Bug 450645] Re: Problem install slapd

Was this an upgrade from an existing system?

--
Problem install slapd
https://bugs.launchpad.net/bugs/450645
You received this bug notification because you are a direct subscriber
of the bug.

Status in “openldap” package in Ubuntu: Incomplete

Bug description:
Release of Ubuntu:
Description: Ubuntu karmic (development branch)
Release: 9.10

The version of packages:
slapd:
  Installed: 2.4.18-0ubuntu1
  Candidate: 2.4.18-0ubuntu1
  Version table:
*** 2.4.18-0ubuntu1 0
        500 http://no.archive.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status

nouveau-kernel-source:
  Installed: 0.0.15+git20090823-0ubuntu1
  Candidate: 0.0.15+git20090823-0ubuntu1
  Version table:
*** 0.0.15+git20090823-0ubuntu1 0
        500 http://no.archive.ubuntu.com karmic/universe Packages
        100 /var/lib/dpkg/status
xserver-xorg-video-nouveau:
  Installed: 1:0.0.10~git+20090823+569a17a-0ubuntu1
  Candidate: 1:0.0.10~git+20090823+569a17a-0ubuntu1
  Version table:
*** 1:0.0.10~git+20090823+569a17a-0ubuntu1 0
        500 http://no.archive.ubuntu.com karmic/universe Packages
        100 /var/lib/dpkg/status
slapd-dbg:
  Installed: 2.4.18-0ubuntu1
  Candidate: 2.4.18-0ubuntu1
  Version table:
*** 2.4.18-0ubuntu1 0
        500 http://no.archive.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status

root@afzal-laptop:/home/afzal# apt-get install slapd
Reading package lists... Done
Building dependency tree
Reading state information... Done
slapd is already the newest version.
The following packages were automatically installed and are no longer required:
  menu-xdg libcups2-dev desktop-base kdebase-plasma planner libattr1-dev
  libboost-regex1.34.1 libboost-test1.35.0 libboost-regex1.35.0 gthumb
  python-beagle gnome-games-extra-data libboost-wave1.35.0 hal-cups-utils
  libdmraid1.0.0.rc15 python-renderpm libsmbclient-dev libboost-wave1.38.0
  libkeyutils-dev libjasper-dev libdiscid0 cheese mplayer-skins python-plasma
  antlr gnome-network-admin libaudclient1 hardinfo libpcre3-dev
  libboost-program-options1.35.0 gthumb-data gparted ttf-kannada-fonts
  gnome-themes-more w3c-dtd-xhtml libgalago1.0-cil gnome-office haskell-utils
  libjaxp1.3-java-gcj libwebkit-1.0-1 kde-core python-dbus-dbg
  epiphany-extensions gnome-themes libantlr-java libtonezone1 libass1
  libboost-thread1.35.0 liblogkit-java python-sip4-dev swfdec-gnome
  python-reportlab-accel gnumeric-common libmaildir4 python-gdl libsoup2.2-8
  gnumeric-doc kplayer-data libboost-serialization1.35.0 libboost-th...

I've just had the same experience.

I ran slapd in heavy trace mode and it seemed to be complaining about and olcAccess attribute - I resolved thiss down to

root@NetSrv01:/etc/ldap/slapd.d/cn=config# cat /etc/ldap/slapd.d/cn\=config/olcDatabase\=\{0\}config.ldif | grep \{
dn: olcDatabase={0}config
olcDatabase: {0}config
olcAccess: {0}to * by * none
olcAccess: to * by dn.exact=cn=localroot,cn=config manage by * break

---

I think it isn't happy with access rules with no number, so to add the number, I edited the confilg file entry to the following :-

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

I can then sucessfully start slapd.

Jay, I don't believe your problem is actually the same as the one described in this bug report (which involves a "chown: cannot access `olcDbDirectory\nolcDbDirectory': No such file or directory" error message).

Instead, I think your particular problem is described in bug #526230 ....

Md. Afzalur Rashid,

If you are still having this problem, please post the output of the following commands:

  $ sudo sh -c "ls -l /etc/ldap/slapd.d/cn=config/olcDatabase*"

  $ sudo sh -c "grep olcSuffix: /etc/ldap/slapd.d/cn=config/olcDatabase*"
and
  $ sudo sh -c "grep olcDbDirectory: /etc/ldap/slapd.d/cn=config/olcDatabase*"

(I'm guessing that the "chown" error is triggered when the install script is unable to extract the olcDbDirectory line(s) from the olcDatabase file(s), for some reason.)

Setting to incomplete pending the answer on comment 8

I have the same problem:

root@nasgul:/etc/ldap/slapd.d# ls -l /etc/ldap/slapd.d/cn\=config/olcDatabase*
-rw-r----- 1 openldap openldap 1738 2010-05-03 18:44 /etc/ldap/slapd.d/cn=config/olcDatabase={0}config.ldif
-rw-r----- 1 openldap openldap 1719 2010-05-03 18:44 /etc/ldap/slapd.d/cn=config/olcDatabase={-1}frontend.ldif
-rw-r----- 1 openldap openldap 1059 2009-09-16 16:45 /etc/ldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif
-rw-r----- 1 openldap openldap 1079 2009-09-16 16:35 /etc/ldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif~

root@nasgul:/etc/ldap/slapd.d# grep olcSuffix: /etc/ldap/slapd.d/cn\=config/olcDatabase*
/etc/ldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif:olcSuffix: dc=nasgul,dc=local
/etc/ldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif~:olcSuffix: dc=nasgul,dc=local

root@nasgul:/etc/ldap/slapd.d# grep olcDbDirectory: /etc/ldap/slapd.d/cn\=config/olcDatabase*
/etc/ldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif:olcDbDirectory: /var/lib/ldap
/etc/ldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif~:olcDbDirectory: /var/lib/ldap

Yep, in your case, the problem is the existence of the "olcDatabase={1}hdb.ldif~" backup file.

(The postinst script currently assumes that only one file will contain the string "olcSuffix: dc=nasgul,dc=local", but here both the .ldif and .ldif~ file contain it.)

If you don't care much about keeping that backup file, you could delete it (or at least move it out of the slapd.d/cn=config directory), then run "dpkg --configure slapd" to try running the slapd configuration step again.

If you do want to keep the backup file, a workaround would be to rename it with a name that doesn't start with "olcDatabase" (e.g. "saved_olcDatabase={1}hdb.ldif~" or whatever).

Mathias (or other OpenLDAP developers):

Any reason the "grep" commands in the get_suffix and get_directory fuctions shouldn't use "olcDatabase*.ldif" for the list of files to search (instead of "olcDatabase*", as they currently do)?

I have the same problem on one of our servers. I don't have backup files in the config area:

root@leopard:/etc/ldap/slapd.d# grep olcDbDirectory: /etc/ldap/slapd.d/cn\=config/olcDatabase*
/etc/ldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif:olcDbDirectory: /var/lib/ldap
/etc/ldap/slapd.d/cn=config/olcDatabase={2}monitor.ldif:olcDbDirectory: /var/lib/ldap
/etc/ldap/slapd.d/cn=config/olcDatabase={3}ldap.ldif:olcDbDirectory: /var/lib/ldap
root@leopard:/etc/ldap/slapd.d# grep olcSuffix: /etc/ldap/slapd.d/cn\=config/olcDatabase*
/etc/ldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif:olcSuffix: dc=cpd,dc=co,dc=uk
/etc/ldap/slapd.d/cn=config/olcDatabase={3}ldap.ldif:olcSuffix: dc=cpd,dc=co,dc=uk
root@leopard:/etc/ldap/slapd.d# ls -l /etc/ldap/slapd.d/cn\=config/olcDatabase*
-rw-r----- 1 openldap openldap 2216 2010-06-24 10:29 /etc/ldap/slapd.d/cn=config/olcDatabase={0}config.ldif
-rw-r----- 1 openldap openldap 2142 2010-06-24 10:29 /etc/ldap/slapd.d/cn=config/olcDatabase={-1}frontend.ldif
-rw-r----- 1 openldap openldap 1913 2010-06-24 10:29 /etc/ldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif
-rw-r----- 1 openldap openldap 533 2010-03-24 01:13 /etc/ldap/slapd.d/cn=config/olcDatabase={2}monitor.ldif
-rw-r----- 1 openldap openldap 1375 2010-03-24 01:15 /etc/ldap/slapd.d/cn=config/olcDatabase={3}ldap.ldif

/etc/ldap/slapd.d/cn=config/olcDatabase={1}hdb:
total 4
-rw-r--r-- 1 openldap openldap 191 2010-03-18 06:05 olcOverlay=syncprov.ldif
root@leopard:/etc/ldap/slapd.d# apt-get install -f
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  python-xapian libntfs-3g54 libfont-freetype-perl
Use 'apt-get autoremove' to remove them.
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.21-0ubuntu5) ...
  Backing up /etc/ldap/slapd.d/ in /var/backups/slapd-2.4.21-0ubuntu2... done.
chown: cannot access `olcDbDirectory\nolcDbDirectory': No such file or directory
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)

For what it's worth, I just had this error when trying to upgrade to to the recent Lucid slapd upgrade:

==============================================================
Preparing to replace slapd 2.4.21-0ubuntu5 (using .../slapd_2.4.21-0ubuntu5.3_amd64.deb) ...
Stopping OpenLDAP: slapd.
Unpacking replacement slapd ...
[...]
Setting up slapd (2.4.21-0ubuntu5.3) ...
  Backing up /etc/ldap/slapd.d/ in /var/backups/slapd-2.4.21-0ubuntu5... done.
chown: cannot access `olcDbDirectory\nolcDbDirectory': No such file or directory
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)
A package failed to install. Trying to recover:
Setting up slapd (2.4.21-0ubuntu5.3) ...
  Backing up /etc/ldap/slapd.d/ in /var/backups/slapd-2.4.21-0ubuntu5... done.
chown: cannot access `olcDbDirectory\nolcDbDirectory': No such file or directory
dpkg: error processing slapd (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 slapd
Press return to continue.
==============================================================

In my case the trigger for this error was the "olcDatabase={1}hdb.ldif~" file that I had created manually a few months ago as part of my testing before posting my earlier comments on this bug.

Still, I was able to get the upgrade to complete successfully by tweaking the postinst script to limit the "grep" calls to files whose names actually end in ".ldif", and I wonder if there is any reason not to apply that patch (or something similar) to the package?

Ross,

In your case, I believe the error is triggered because you have two different olcDatabase files that include the same oldSuffix line:
/etc/ldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif:olcSuffix: dc=cpd,dc=co,dc=uk
/etc/ldap/slapd.d/cn=config/olcDatabase={3}ldap.ldif:olcSuffix: dc=cpd,dc=co,dc=uk

(As I mentioned earlier, the postinst script currently assumes that only one file will contain the string "olcSuffix: SUFFIX".)

Unfortunately, the patch that I just submitted wouldn't make any difference in your case (since the names of both of those files do end in ".ldif")...

Thanks, Nathan.

FWIW, working from your patch, I added /dev/null as an argument to the grep, and had the 'cut' take the third field (as the first is now the filename), threw in a 'head -1' (hackishly, as I know that's the only one I need to update) and have now successfully completed the postinst.

In my case, I modified the lines to the following (sorry, not in patch format):

grep -h olcSuffix ${SLAPD_CONF}/cn\=config/olcDatabase* /dev/null | head -1 | cut -d: -f 3

grep "olcDbDirectory:" `grep -l "olcSuffix: $1" ${SLAPD_CONF}/cn\=config/olcDatabase*.ldif` /dev/null | head -1 | cut -d: -f 3 | sed 's/^ *//g'

I didn't explain clearly in my earlier comments that it's only the olcDbDirectory grep that actually causes the "chown" error here. I added the ".ldif" extension to the grep in the get_suffix function only to keep the two consistent (figuring that if it's true we only care about files that end in ".ldif" then we should be restricting our searches to such file in both places).

However, the two "grep"s are actually different enough that making your changes to the first one won't do what you want.... In particular, the "-h" option given there means that the filenames are never printed; adding "/dev/null" doesn't change anything, and changing the "cut" command to use the third field just means that the pipeline always returns an empty list of suffixes. In your particular case, though, it ends up working out fine, since the result is that the postinst script completes without an error... but that is because it doesn't try to update the permissions on any of the database directories, rather than because it is now successfully determining the path of the directory that needs to be updated....

It certainly seems like a good idea, though, to make the get_directory function a bit more robust. But I'm not sure off hand if it makes more sense to just pick the first directory that is found for a given suffix, or to try to return all of those directories. (That is, by making the "grep" pipeline a bit smarter, it seems like one could just return a list of all the database directories, and run the "chown" on that list.)

(In your case, does the olcDatabase={3}ldap.ldif file really describe an active backend that has both the same suffix and database directory as the one described in the olcDatabase={1}hdb.ldif file?)

Bug,

I'd like to add you to my professional network on LinkedIn.

- Afzalur

Afzalur Rashid
General Manager at Bit Mascot
Bangladesh

Confirm that you know Afzalur Rashid:
https://www.linkedin.com/e/-29eamg-gscqcc4m-23/isd/4142981962/R1um16G5/?hs=false&tok=3T-I8tioaczQU1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-29eamg-gscqcc4m-23/TER1nQpPVCK4t1_PYtyWhvnPen_Q1LQ3WyY7xp7/goo/450645%40bugs%2Elaunchpad%2Enet/20061/I1429795656_1/?hs=false&tok=0RgF630UWczQU1

(c) 2011 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

LinkedIn
------------

Bug,

I'd like to add you to my professional network on LinkedIn.

- Afzalur

Afzalur Rashid
CTO at ITA, Inc. Japan
Bangladesh

Confirm that you know Afzalur Rashid:
https://www.linkedin.com/e/-29eamg-h95ftbqx-3w/isd/4142981962/R1um16G5/?hs=false&tok=0oypA10pAaT5s1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-29eamg-h95ftbqx-3w/TER1nQpPVCK4t1_PYtyWhvnPen_Q1LQ3WyY7xp7/goo/450645%40bugs%2Elaunchpad%2Enet/20061/I3149847956_1/?hs=false&tok=3ip-EcFb4aT5s1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

In quantal and later, the grep invocation was adjusted to only check *.ldif:

http://anonscm.debian.org/cgit/pkg-openldap/openldap.git/commit/debian/slapd.scripts-common?id=c8d1f619c8e151704508b671a7c801d9863e183e

Therefore, setting to Fix Released.

There may be other causes that result in a similar error message; if you encounter such a case, please file a new bug.