[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
installation.
In particular:
#> rpm -q openldap
openldap-2.0.27-8
do you have any suggestion to avoid this overhead?
Mario
> 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