Description of problem:
"slapadd" creates LDAP database files with incorrect permissions
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. After OpenLDAP packages installed and slapd.conf file configured, create LDIF
2. Issue "slapadd -v -l <LDIF file>"
3. Note that files created in <LDAPDIR> (created by above slapadd command) are
owned by root - the LDAP server cannot read them. After chown'ing the files to
ldap:ldap, the server can read them and returns results as expected.
This is not a bug. Run slapadd as user ldap.
If I could use the "ldap" user, that would work. In RHEL 3, you
cannot "su" to the ldap user, so this is in fact a bug. Whether it's
a bug with the ldap user ID not being available or with the
openldap-servers package not setting the correct permissions, I'll
leave to RH Engineering.
I see your point.
Well, workarounds are sudo -u ldap slapadd (which works regardless of
the user's shell) or chown when done.
The problem with the ownership happens with FC3 and FC4 out of sudden. If you
try to copy the db4 ldap databases to a second machine, to make it run as a
replica and you start ldap, the __db** files will be owned by root:root, which
makes slapd stop. After a chown ldap:ldap it works - major problem: if ldap gets
choked due to e.g. power failure and you have to delete the __db* files, you
always need to reassign correct ownership.
Second thing - after running yum update today on a fc3 machine, which ran as
ldap /samba dc well for months, the system has been killed in the same way.
Updated from 2.2.13 to 2.2.29.
If you setup an ldap server fresh from scratch, the ownership is well done
(ldap:ldap) - but with a running version it sucks.
There must be a problem with the init script, because until 2.2.13, this never
Greets and standby for further help
addition: my comment maybe a bit offtopic (cause it does not rely on slapadd
alone) - sorry for any troubles :-)
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.