Description of problem: "slapadd" creates LDAP database files with incorrect permissions Version-Release number of selected component (if applicable): openldap-servers-2.0.27-11 How reproducible: Immediately Steps to Reproduce: 1. After OpenLDAP packages installed and slapd.conf file configured, create LDIF file. 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. Actual results: Expected results: Additional info:
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 happened. Greets and standby for further help Andy
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: http://www.redhat.com/security/updates/errata/ 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.