----- "Scott Sanders" lists@jssjr.com wrote:

Hello OpenLDAP fans,

In the future I would like to know how to repair replication issues in a less blunt manner. Any suggestions or comments would be appreciated.

Thanks,

You could try resetting the cookie, but honestly, the replication depends on things being correctly set up. Personally, I would have used slapcat on the master to export the db (or another slave) and then used slapadd -q to reload the database, which is substantially faster than having it replicate the entire DB...

--Quanah

Scott Sanders wrote:

Hello OpenLDAP fans,

I have a situation which came to my attention inadvertantly after creating a new replication slave for my directory. The directory holds a number of posix user accounts, and some of these entries with the posixAccount object class also have a sambaSamAccount object class. I use delta-syncrepl for my slaves, because of how quickly I can set them up at new locations. However, after creating this slave and setting up auth through PAM on a linux machine to use the new slave I found I was unable to log in, but other users could. After checking the contents of ou=people on the slave, it seems no entries referencing any samba attributes or samba object classes were replicated. As it turns out, I had forgotten to include samba.schema in my slave slapd.conf.

Now, I set out to fix this on my own. Restarting the server after adding the schema definition did not populate the samba entries on the slave. I was instructed to try modifying one of the missing entries by the wonderful users in #ldap, in hopes it would trigger syncrepl to send the missing entry to the slave. This also had no effect. After 30 minutes of frusteration I simply wiped out the openldap-data directory on the slave and restarted LDAP. This did work. However, it recreated the whole database on the slave, which could have taken a long time if my directory was larger.

In the future I would like to know how to repair replication issues in a less blunt manner. Any suggestions or comments would be appreciated.

I don't think there are too many alternatives. As the name says, delta syncrepl takes advantage of having deltas, i.e. incremental modifications, stored somewhere on the producer. Since the difference between your producer and your consumer are not related to modifications on the producer, there's little but a full refresh that could be done. The full refresh implies that all entries are collected by the consumer, so I don't see any difference (in terms of bandwidth) between a full refresh and restarting from scratch. There'd be a small difference in that some entries might not need to be modified.

p.

Ing. Pierangelo Masarati OpenLDAP Core Team

SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------