Description of problem: openldap under kernel-xen-* does not start as service ("service opneldap start") Version-Release number of selected component (if applicable): ... kernel-xen-2.6.17-1.2586.fc6.i686.rpm kernel-xen-2.6.17-1.2597.fc6.i686.rpm How reproducible: install openldap (openldap-XY-XZ-2.3.27-2.i386.rpm) in domU (using bdb format) copy DB_CONFIG file into /var/lib/ldap directory check proper permissions for ldap user (ldap.ldap) in /var/lib/ldap (O.K.) service ldap start works (initializing directory) adding entries to ldap db (smbldap-tools) works, too restarting ldap service fails: Checking configuration files for slapd: usage; slaptest [-v].... [FAILED] stale lock files may be present in /var/lib/ldap [WARNING] wheras: slapd -d 10 #works slapd -u root -d 10 #works slapd -u ldap -d 10 #fails starting ldap as root with "slapd -dX" creates files in /var/run/openldap/ (owner:ldap.ldap) slapd.pid, slapd.args (owner root:root) Might be again a problem with the ldap initscript as previously reported in a fc5 bugzilla entry but the suggested initscript patch (touching files and modifying acl) does not work here. Steps to Reproduce: 1. 2. 3. Actual results: service ldap in domU does not work Expected results: service ldap in domU should work Additional info:
correction: starting "slapd -u ldap" works after having set all files' permissions to ldap user in /var/lib/ldap/ directory. (Some of the db files had been owned by root!) But starting ldap as service still does not work!!!
If the smbldap-tools use slapadd to add data to the directory, they need to be run as ldap, rather than as root, since slapadd doesn't set-uid itself to the ldap user before creating/modifying the files in /var/lib/ldap. This is a design problem with slapadd, and I'm not sure what the correct solution to it is. There were also problems with /etc/init.d/ldap running other commands that could modify /var/lib/ldap as root. I think I got them corrected for fc6test2 though. Where did the smbldap-tools that you ran come from? What kind of data did you feed them? Can you reproduce the problem in a non-xen context?
There is the following line in /etc/init.d/ldap: if ! action $"Checking configuration files for $prog: " /sbin/runuser -m -s "$slaptest" -- "$user" "$slaptestflags"; then if I replace this line with: if ! action $"Checking configuration files for $prog: " /sbin/runuser -m -s "$slaptest" -- "$user" $slaptestflags; then then slapd starts okay. NOTE THE LACK OF QUOTES AROUND $slaptestflags -- this is the only change. So, it seems that if slaptestflags is undefined, then the empty argument of "" causes a failure in slaptest's argument parsing.
Sorry for the late reply. First, the suggested solution(s) from W.M.Petullo (changing the init scripts) does not work for me (the same error messages occur)! Second, I`ve tried to run the "idealx" scripts as user ldap (had to change the passwd file with it´s ldap user entry from .../sbin/nologin to .../sbin/bash) to achive a "su ldap" during the script. The ldap service still fails. The only difference, as fas as I can see, is that now all ldap files are owned by ldap. The smbldap-tools (smbldap-tools-0.9.2-1a.noarch.rpm) are provided from www.idealx.org. The package includes some small tools (perl-scripts and some binaries) to identify the samba SID and populate the server with preconfigured ldap groups. In the past, I used an automated install script for FC4/FC2 (included samba/ldap parts) installations without having experienced any problems. That script has always been running as user root. #openldap-2.3.27-2 #openldap-clients-2.3.27-2 #openldap-servers-2.3.27-2 NOT WORKING: 2.6.17-1.2614.fc6xen total 69629 drwx------ 2 ldap ldap 1024 Sep 6 14:56 . drwxr-xr-x 12 root root 1024 Sep 6 14:57 .. -rw-r--r-- 1 ldap ldap 2048 Sep 6 16:27 alock -rw------- 1 ldap ldap 20480 Sep 6 15:49 cn.bdb -rw------- 1 ldap ldap 24576 Sep 6 14:55 __db.001 -rw------- 1 ldap ldap 80019456 Sep 6 14:55 __db.002 -rw------- 1 ldap ldap 187506688 Sep 6 14:55 __db.003 -rw------- 1 ldap ldap 2359296 Sep 6 14:55 __db.004 -rw------- 1 ldap ldap 352256 Sep 6 14:55 __db.005 -rw------- 1 ldap ldap 24576 Sep 6 14:55 __db.006 -rwx------ 1 ldap ldap 211 Sep 6 14:55 DB_CONFIG -rw------- 1 ldap ldap 20480 Sep 6 15:49 displayName.bdb -rw------- 1 ldap ldap 16384 Sep 6 15:49 dn2id.bdb -rw------- 1 ldap ldap 8192 Sep 6 15:49 gidNumber.bdb -rw------- 1 ldap ldap 8192 Sep 6 15:15 givenName.bdb -rw------- 1 ldap ldap 65536 Sep 6 15:49 id2entry.bdb -rw------- 1 ldap ldap 10485760 Sep 6 15:49 log.0000000001 -rw------- 1 ldap ldap 8192 Sep 6 15:15 memberUid.bdb -rw------- 1 ldap ldap 8192 Sep 6 15:49 objectClass.bdb -rw------- 1 ldap ldap 8192 Sep 6 15:15 sambaDomainName.bdb -rw------- 1 ldap ldap 8192 Sep 6 15:15 sambaPrimaryGroupSID.bdb -rw------- 1 ldap ldap 8192 Sep 6 15:49 sambaSID.bdb -rw------- 1 ldap ldap 8192 Sep 6 15:49 sn.bdb -rw------- 1 ldap ldap 8192 Sep 6 15:49 uid.bdb -rw------- 1 ldap ldap 8192 Sep 6 15:49 uidNumber.bdb -rw-r--r-- 1 ldap ldap 0 Sep 6 08:57 upgrade.ldif WORKING: 2.6.17-1.2614.fc6 total 69614 drwx------ 2 ldap ldap 1024 Sep 6 16:00 . drwxr-xr-x 15 root root 1024 Sep 6 15:57 .. -rw-r--r-- 1 ldap ldap 2048 Sep 6 16:04 alock -rw------- 1 ldap ldap 20480 Sep 6 16:04 cn.bdb -rw------- 1 ldap ldap 24576 Sep 6 15:59 __db.001 -rw------- 1 ldap ldap 80019456 Sep 6 15:59 __db.002 -rw------- 1 ldap ldap 187506688 Sep 6 15:59 __db.003 -rw------- 1 ldap ldap 2359296 Sep 6 15:59 __db.004 -rw------- 1 ldap ldap 352256 Sep 6 15:59 __db.005 -rw------- 1 ldap ldap 24576 Sep 6 15:59 __db.006 -rwx------ 1 ldap ldap 211 Sep 6 15:59 DB_CONFIG -rw------- 1 ldap ldap 20480 Sep 6 16:04 displayName.bdb -rw------- 1 ldap ldap 8192 Sep 6 16:04 dn2id.bdb -rw------- 1 ldap ldap 8192 Sep 6 16:04 gidNumber.bdb -rw------- 1 ldap ldap 8192 Sep 6 16:04 givenName.bdb -rw------- 1 ldap ldap 65536 Sep 6 16:04 id2entry.bdb -rw------- 1 ldap ldap 10485760 Sep 6 16:07 log.0000000001 -rw------- 1 ldap ldap 8192 Sep 6 16:04 memberUid.bdb -rw------- 1 ldap ldap 8192 Sep 6 16:04 objectClass.bdb -rw------- 1 ldap ldap 8192 Sep 6 16:04 sambaDomainName.bdb -rw------- 1 ldap ldap 8192 Sep 6 16:04 sambaPrimaryGroupSID.bdb -rw------- 1 ldap ldap 8192 Sep 6 16:04 sambaSID.bdb -rw------- 1 ldap ldap 8192 Sep 6 16:04 sn.bdb -rw------- 1 ldap ldap 8192 Sep 6 16:04 uid.bdb -rw------- 1 ldap ldap 8192 Sep 6 16:04 uidNumber.bdb -rw-r--r-- 1 ldap ldap 0 Sep 6 07:47 upgrade.ldif So, I can assure you that the reported problem (service ldap fails) only exists in a FC6t2 xen environment. I`ve also tested this with a non xen-kernel, - there the ldap service runs as expected. As far as both ldap directories are concerned I can't see any difference. The xen and the non-xen system are based on identical packages choice. Both FC6t2 "systems" have been updated via yum to the latest packages (03.09.2006)
additional info: sorry, I have to admit that even in a non-xen-kernel context the ldap service fails after having added entries to ldap directory. I have reinstalled ldap/samba on a fresh system and I couldn´t figure out why the ldap service yesterday suddenly worked once. Now, I´m really confused about openldap in fc6t2. Maybe there´s something wrong with the "bdb" ldap backend format. Since FC2/FC4 I always used "ldbm" format. Maybe something else has changed since fc6 and its openldap related config files (slapd.conf, ldap.conf, nsswitch, authconfig...)? I also get these error messages, but ldap user login to the samba pdc works without problems. nscd: nss_ldap: failed to bind to LDAP server ldap://127.0.0.1/: Can't contact LDAP server nscd: nss_ldap: could not search LDAP server - Server is unavailable I guess, it will be better to wait for the final version of FC6 (Maybe I`ll give fc6t3 just another try). So meanwhile this bug can be closed and confirmed as no bug. Regards Wolfgang
updated openldap package (openldap-2.3.27-3 from 22.09.2006) seems to have fixed the problem (released after FC6-TEST3)!
Fedora Core 5 and Fedora Core 6 are, as we're sure you've noticed, no longer test releases. We're cleaning up the bug database and making sure important bug reports filed against these test releases don't get lost. It would be helpful if you could test this issue with a released version of Fedora or with the latest development / test release. Thanks for your help and for your patience. [This is a bulk message for all open FC5/FC6 test release bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
Asreported by #6, current release of openldap fixes the issue.