I've a sandbox environment with 2 CentOS 6.2 servers running the genuine openldap-servers rpms, that is OpenLDAP 2.4.23 . I've setup a multi-master replication between the servers, so that both my data DIT (dc=....,dc=.... ) and the cn=config should be replicated.
Actually, the replication of data works fine, as expected in either way, but the replication of the configuration tree fails: each time I update the configuration on the second node, I get this error in my LDAP client (Apache Directory Studio):
could not put entry file in place
I've tried to run the second master in debug (-d -1) mode, and it seems like there's a write access error when the slapd daemon (on the 2nd master) tries to update/modify/replace the /etc/openldap/slapd.d/cn=config.ldif file:
<= acl_access_allowed: granted to database root ldif_write_entry: could not put entry file for "cn=config" in place: Permission denied send_ldap_result: conn=-1 op=0 p=3 send_ldap_result: err=80 matched="" text="internal error (could not put entry file in place)" send_ldap_result: conn=-1 op=0 p=3 send_ldap_result: err=80 matched="" text="internal error (could not put entry file in place)" null_callback : error code 0x50 slap_graduate_commit_csn: removing 0x7fd19412f090 20120510163105.003156Z#000000#001#000000 syncrepl_updateCookie: rid=001 be_modify failed (80) ldap_msgfree
The OpenLDAP error log shows the following error:
May 10 19:12:39 sashimi slapd[24866]: slapd starting May 10 19:12:40 sashimi slapd[24866]: ldif_write_entry: cannot create file for "olcDatabase={0}config,cn=config": Permission denied May 10 19:12:40 sashimi slapd[24866]: null_callback : error code 0x50 May 10 19:12:40 sashimi slapd[24866]: syncrepl_entry: rid=001 be_modify failed (80) May 10 19:12:40 sashimi slapd[24866]: do_syncrepl: rid=001 rc -1 quitting May 10 19:12:50 sashimi slapd[24866]: ldif_write_entry: could not put entry file for "cn=config" in place: Permission denied May 10 19:12:50 sashimi slapd[24866]: null_callback : error code 0x50 May 10 19:12:50 sashimi slapd[24866]: syncrepl_updateCookie: rid=001 be_modify failed (80) May 10 19:13:00 sashimi slapd[24866]: ldif_write_entry: could not put entry file for "cn=config" in place: Permission denied May 10 19:13:00 sashimi slapd[24866]: null_callback : error code 0x50 May 10 19:13:00 sashimi slapd[24866]: syncrepl_updateCookie: rid=001 be_modify failed (80) May 10 19:13:10 sashimi slapd[24866]: ldif_write_entry: could not put entry file for "cn=config" in place: Permission denied May 10 19:13:10 sashimi slapd[24866]: null_callback : error code 0x50 May 10 19:13:10 sashimi slapd[24866]: syncrepl_updateCookie: rid=001 be_modify failed (80)
Of course, I don't have any right access problems at the file system level, I don't have any file system ACLs, I don't use SELinux and I've checked that I can update or create any file under /etc/openldap/slapd.d, when logged in as the ldap user (who's the account used to run slapd).
So, this error looks like a bug to me. Already fixed ?
To setup the replication of both data and configuration, I've copied the full /etc/openldap directory from one server to the other, with the same file system rights. I've just changed the server certificate files since I use TLS to replicate both the data and the configuration. So, I don't have any TLS problem since the data tree replication works fine.
Here's my replication configuration for the cn=config database: dn: olcDatabase={0}config,cn=config ... .... olcSyncRepl: rid=001 provider=ldap://......:389 binddn="cn=config" bindmethod=simple credentials="......" searchbase="cn=config" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 starttls=yes tls_cacert=/etc/openldap/conf/cacert.pem olcSyncRepl: rid=002 provider=ldap://.....:389 binddn="cn=config" bindmethod=simple credentials="....... " searchbase="cn=config" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 starttls=yes tls_cacert=/etc/openldap/conf/cacert.pem olcMirrorMode: TRUE
I actually use the same setup than for the data replication, excepted that I have rid=003 and rid=004 of course for data replication, and the BIND DN and passwords are different too.
--On Thursday, May 10, 2012 7:21 PM +0200 Cyril Grosjean cgrosjean@janua.fr wrote:
I've a sandbox environment with 2 CentOS 6.2 servers running the genuine openldap-servers rpms, that is OpenLDAP 2.4.23 . I've setup a multi-master replication between the servers, so that both my data DIT (dc=....,dc=.... ) and the cn=config should be replicated.
Sounds to me like the files in the cn=config tree are owned by a user other than the user openldap is running as. I suggest you check the directory/file permissions on that server.
And if you want to have working MMR, I suggest you upgrade to OpenLDAP 2.4.31.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
On 10/05/2012 2:21 PM, Cyril Grosjean wrote:
May 10 19:12:40 sashimi slapd[24866]: ldif_write_entry: cannot create file for "olcDatabase={0}config,cn=config": Permission denied
To add to Quanah's reply, it'd be interesting to see the results of an strace of the slapd process. Using the above as an example, you could try (as root):
strace -vv -s 1500 -e trace=file -f -o /tmp/slapd.strace -p 24866
Try to modify the config (olcLogLevel on cn=config, for example) and then ^C strace, and then grep for cn=config.ldif. I suspect you might find some EACCES or EPERM errors on the open() calls for that file.
On both masters, I get exactly the same result (command ran as root of course):
ls -lZd /etc/openldap/slapd.d /etc/openldap/slapd.d/cn=config.ldif
drwx------. ldap ldap system_u:object_r:slapd_db_t:s0 /etc/openldap/slapd.d -rw-------. ldap ldap unconfined_u:object_r:etc_t:s0 /etc/openldap/slapd.d/cn=config.ldif
getfacl /etc/openldap/slapd.d /etc/openldap/slapd.d/cn=config.ldif getfacl: Removing leading '/' from absolute path names # file: etc/openldap/slapd.d # owner: ldap # group: ldap user::rwx group::--- other::---
# file: etc/openldap/slapd.d/cn=config.ldif # owner: ldap # group: ldap user::rw- group::--- other::---
Maybe the problem would also appear on the 1st master if I had tried to configure it after the second one. I mean the problem may not be due to a specific machine but rather to the configuration order ..
2012/5/10 Brandon Hume hume-ol@bofh.ca
On 10/05/2012 2:21 PM, Cyril Grosjean wrote:
May 10 19:12:40 sashimi slapd[24866]: ldif_write_entry: cannot create file for "olcDatabase={0}config,cn=**config": Permission denied
To add to Quanah's reply, it'd be interesting to see the results of an strace of the slapd process. Using the above as an example, you could try (as root):
strace -vv -s 1500 -e trace=file -f -o /tmp/slapd.strace -p 24866
Try to modify the config (olcLogLevel on cn=config, for example) and then ^C strace, and then grep for cn=config.ldif. I suspect you might find some EACCES or EPERM errors on the open() calls for that file.
On Friday, 11 May 2012 14:32:07 Cyril Grosjean wrote:
On both masters, I get exactly the same result (command ran as root of course):
ls -lZd /etc/openldap/slapd.d /etc/openldap/slapd.d/cn=config.ldif
drwx------. ldap ldap system_u:object_r:slapd_db_t:s0 /etc/openldap/slapd.d -rw-------. ldap ldap unconfined_u:object_r:etc_t:s0 /etc/openldap/slapd.d/cn=config.ldif
Note carefully the SELinux context difference between the directory (which is probably correct) and the file (which probably isn't).
sealert would probably show you SELinux violations attempting to access/write to cn=config.ldif.
Regards, Buchan
openldap-technical@openldap.org