Hi, all, I get the warning given in the title and ldap stops even after reporting to start successfully. The error is fixed by doing a chown for the affected files. It was mysteriously changed to root. I change it back to ldap and it works again. However, I want to know what has caused this to happen. Anyone can help? I am in the course of changing a slurpd-based replication to a syncrepl-based replication. I suspect that is relevant. In the old and working master config: rootdn: root binddn for replication(slurpd) directive: replicator In the old and working slave config: rootdn: replicator
In the new master config: rootdn: root
In the new slave config: rootdn: replicator binddn for replication(syncrepl) directive: replicator What has caused the db.00X file to be owned by root? The new configs once start without error. But I find the replication is not doing its job when I check on the slave the data of a user account I changed on the master side. So I go back to the old config. And then the var/lib/ldap/__db.004 is not owned by "ldap" comes up and ldap wont start on the slave. Maybe the syncrepl has been working partially, just in a different name and causes the problem?Maybe it is not working at all as I dont know what to put about ssl/tls in the slave config file. In the master, I have commented out the tls cert/key lines and access to the server by the client are done with the ldaps:// port. But I dont know what to do with the slapd.conf of the slave file. Does it have to get the ssl lines commented out in order to get allowed to access the master. Any help would be greatly appreciated.
--On Wednesday, November 26, 2014 3:36 AM +0000 wailok tam wailoktam@yahoo.com wrote:
Hi, all, I get the warning given in the title and ldap stops even after reporting to start successfully.
The error is fixed by doing a chown for the affected files. It was mysteriously changed to root. I change it back to ldap and it works again. However, I want to know what has caused this to happen. Anyone can help?
This often happens when someone has a cron job running via root. In any case, slapd itself will not change the ownership of those files unless you start it as root instead of your ldap user.
--Quanah
--
Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
thanks. I sort this one out.
From: Quanah Gibson-Mount quanah@zimbra.com To: wailok tam wailoktam@yahoo.com; openldap-technical@openldap.org Sent: Wednesday, November 26, 2014 3:48 PM Subject: Re: getting warning:var/lib/ldap/__db.004 is not owned by "ldap" and ldap wont start
--On Wednesday, November 26, 2014 3:36 AM +0000 wailok tam
wailoktam@yahoo.com wrote:
Hi, all, I get the warning given in the title and ldap stops even after reporting to start successfully.
The error is fixed by doing a chown for the affected files. It was mysteriously changed to root. I change it back to ldap and it works again. However, I want to know what has caused this to happen. Anyone can help?
This often happens when someone has a cron job running via root. In any case, slapd itself will not change the ownership of those files unless you start it as root instead of your ldap user.
--Quanah
--
Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org