2009/2/9 Quanah Gibson-Mount quanah@zimbra.com:
I'm not sure why you feel it is necessary to set the server read-only before you run slapcat anyway.
It was purely in relation to point 18.1.2 in this doc...
http://www.openldap.org/doc/admin24/maintenance.html
To quote...
"Slapcat can be run while slapd is active. However, one runs the risk of an inconsistent database- not from the point of slapd, but from the point of the applications using LDAP. For example, if a provisioning application performed tasks that consisted of several LDAP operations, and the slapcat took place concurrently with those operations, then there might be inconsistencies in the LDAP database from the point of view of that provisioning application and applications that depended on it. One must, therefore, be convinced something like that won't happen. One way to do that would be to put the database in read-only mode while performing the slapcat."
--On Monday, February 09, 2009 5:40 PM +0000 Andrew Hall whippyhubbles@googlemail.com wrote:
2009/2/9 Quanah Gibson-Mount quanah@zimbra.com:
I'm not sure why you feel it is necessary to set the server read-only before you run slapcat anyway.
It was purely in relation to point 18.1.2 in this doc...
http://www.openldap.org/doc/admin24/maintenance.html
To quote...
"Slapcat can be run while slapd is active. However, one runs the risk of an inconsistent database- not from the point of slapd, but from the point of the applications using LDAP. For example, if a provisioning application performed tasks that consisted of several LDAP operations, and the slapcat took place concurrently with those operations, then there might be inconsistencies in the LDAP database from the point of view of that provisioning application and applications that depended on it. One must, therefore, be convinced something like that won't happen. One way to do that would be to put the database in read-only mode while performing the slapcat."
Right, and this only becomes an issue if you later restore from that slapcat, and you have no way to deal with this in your provisioning system. And at that point, you're fairly screwed anyway, because if you can't handle going from point A -> point B in your provisioning system, you'll never get your LDAP servers consistent with it anyway.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org