[CentOS] Please help -- centos 5.8: does the slapcat still breaks ldap data integrity?

Tue Nov 13 19:51:13 UTC 2012
Johnny Hughes <johnny at centos.org>

On 11/13/2012 01:38 PM, Craig White wrote:
> On Nov 13, 2012, at 11:56 AM, Gelen James wrote:
>
>>>> Hi all,
>>>>   I've a small project to backup and restore openldap servers online on centos 5.8. Basically I don't have the luxury to shutdown the ldap server, then backup whole /var/lib/ldap/, but have to backup online with slapcat or similar command line tool.
>>>>
>>>> The major concern of using slapcat is the warning below, which was excerpt from link http://www.centos.org/docs/5/html/5.1/Deployment_Guide/s1-ldap-daemonsutils.html
>>>>
>>>> You must stop slapd by issuing the /sbin/service ldap stop command before using slapadd, slapcat or slapindex. Otherwise, the integrity of the LDAP directory is at risk.
>>>> Does the limitation of slapcat -- stop ldap first -- still exist? Please shed a light onto this. Thanks.
>>> ----
>>> depends on what you are using for backend. If you are still using ldbm (you definitely shouldn't at this point), then yes, it must be stopped before doing the slapcat. If you are using > bdb or hdb, no… it's not necessary to stop the service first.
>>>
>>> Craig
>> Thanks for confirmation, I'm using the default config/backend with minor changes, so it seems bdb. The following are the types of the files under /var/lib/ldap.
>>
>> alock:           data
>> cn.bdb:          Berkeley DB (Btree, version 9, native byte-order)
>> __db.001:        Applesoft BASIC program data
>> __db.002:        data
>> __db.003:        data
>> __db.004:        data
>> __db.005:        data
>> __db.006:        data
>> DB_CONFIG:       ASCII English text
>> dn2id.bdb:       Berkeley DB (Btree, version 9, native byte-order)
>> gidNumber.bdb:   Berkeley DB (Btree, version 9, native byte-order)
>> givenName.bdb:   Berkeley DB (Btree, version 9, native byte-order)
>> id2entry.bdb:    Berkeley DB (Btree, version 9, native byte-order)
>> log.0000000001:  Berkeley DB (Log, version 11, native byte-order)
>> loginShell.bdb:  Berkeley DB (Btree, version 9, native byte-order)
>> mail.bdb:        Berkeley DB (Btree, version 9, native byte-order)
>> objectClass.bdb: Berkeley DB (Btree, version 9, native byte-order)
>> ou.bdb:          Berkeley DB (Btree, version 9, native byte-order)
>> sn.bdb:          Berkeley DB (Btree, version 9, native byte-order)
>> uid.bdb:         Berkeley DB (Btree, version 9, native byte-order)
>> uidNumber.bdb:   Berkeley DB (Btree, version 9, native byte-order)
> ----
> from the primary developer of OpenLDAP software…
>
> http://www.openldap.org/lists/openldap-software/200611/msg00048.html
>
> Craig

For the record, I used slapcat on a regular basis for 7 years using bdb
while slapd was running and I never had one problem with data loss.  You
are indeed using bdb.

I would routinely slapcat > slapcat.out and then import that into other
servers whenever we had something happen that caused the replica ldap
servers to become non synced with the master ldap server.

All I did was delete all the files except DB_CONFIG and then use slapadd
to import the file (and change the owner of all files to ldap:ldap after
the import).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos/attachments/20121113/3a6472ca/attachment-0005.sig>