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

Re: replication problem



On Friday 07 March 2008 10:28:53 Julien Garnier wrote:
> Buchan Milne a Ãcrit :
> > On Thursday 06 March 2008 16:44:21 Julien Garnier wrote:
> >> I just reinstall all my slave server and resynchronize all the database
> >> and it's the same :
> >> It's OK when I search the master server but doesn't work for the slave
> >> server.
> >>
> >> What I've done is :
> >> reinstall linux
> >> install openldap from aptitude (slapd 2.3.30 (Mar  9 2007 05:43:02))
> >> copy paste my config file to /etc/ldap/slapd.conf
> >> starting server
> >>
> >> and nothing else.
> >> search on base doesn't retrn any results :
> >
> > Does cn=sync-dr13,ou=people,dc=compagnie,dc=com have unlimited
> > (size/time) access to your provider? Have you tested manually (e.g.
> > with 'ldapsearch -x -H ldap://master:389 -b ou=People,dc=compagnie,dc=com
> > -D cn=sync-dr13,ou=people,dc=compagnie,dc=com -w
> > secret "(cnrsDelegation=DR13*)"') that you can receive all the entries?
> > Or, have you confirmed from the logs on the consumer that the provider
> > search did not return a result=4?
>
> I think there is no problem with master server search is good with
> cn=sync and as anonymous:

Since by default only rootdn has unlimited access, and since you did not 
include your provider's slapd.conf (or any evidence that you have ensured 
that the consumer's binddn has unlimited access), and since you did not 
include the result code in your output, and since you did not state how many 
entries you have (as the default sizelimit is 500) I would still suspect 
this.

But, if you are sure this is not the issue, you'll have to look for another 
cause (even though the consumer not being able to retrieve all the entries is 
the most likely cause of the contextCSN not being updated on an initial 
sync).

Regards,
Buchan