[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: LDAP slurp problem

You right, I've noticied that replication between master and slave is done
correctly except that every time I made a change something is written into
replica/slave1*:389.rej file too.
For example, If I make a modify on loginShell attribute on master, the is done
on slave and the following entries are appended to replica/slave1*.rej file:

ERROR: No such object
replica: slave1:389
time: 1106307458.0
dn: uid=nobody, ou=People, dc=domain1,dc=it
changetype: modify
replace: loginShell
loginShell: /bin/tcsh
replace: modifiersName
modifiersName: cn=Manager,dc=domain1,dc=it
replace: modifyTimestamp
modifyTimestamp: 20050121113737Z

My systems are both RH9, one for master and one for slave with the same kind of
In particular:
#> rpm -q openldap

do you have any suggestion to avoid this overhead?

> Since you never stated what version of the software you're using, I cannot
> claim my statement is definitely correct, but you should still have a
> (minor) problem: your slurpd is propagating updates twice, and for each
> database half of them are being attempted with the update identity of the
> otehr database, so they fail and return a referral (or fail if you didn't
> provide an updateref).  This is what I observe with 2.2.20, it might
> differ with older releases (e.g. 2.1 or even 2.0, but I have no chance to
> try them).  You can clearly see this by running slurpd and/or the slave
> with -d 256.  I call this a minor problem because you're getting the
> expected result, only with a lot of unnecessary overhead.
> p.
> -- 
> Pierangelo Masarati
> mailto:pierangelo.masarati@sys-net.it

6X velocizzare la tua navigazione a 56k? 6X Web Accelerator di Libero!
Scaricalo su INTERNET GRATIS 6X http://www.libero.it