Bug 204593 - service ldap fails after having added entries to ldap
service ldap fails after having added entries to ldap
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: openldap (Show other bugs)
6
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jan Safranek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-30 05:47 EDT by WSchleicher
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version: 2.3.27-3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-23 10:58:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description WSchleicher 2006-08-30 05:47:47 EDT
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:
Comment 1 WSchleicher 2006-09-01 01:09:14 EDT
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!!!
Comment 2 Jay Fenlason 2006-09-01 14:56:52 EDT
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? 
 
 
Comment 3 W. Michael Petullo 2006-09-05 18:55:57 EDT
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.
Comment 4 WSchleicher 2006-09-06 10:55:10 EDT
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)
Comment 5 WSchleicher 2006-09-07 06:39:26 EDT
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
Comment 6 WSchleicher 2006-09-27 04:52:29 EDT
updated openldap package (openldap-2.3.27-3 from 22.09.2006) seems to have fixed
the problem (released after FC6-TEST3)!
Comment 7 Matthew Miller 2007-04-06 13:51:40 EDT
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.]
Comment 8 Jan Safranek 2007-04-23 10:58:56 EDT
Asreported by #6, current release of openldap fixes the issue.

Note You need to log in before you can comment on or make changes to this bug.