[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: syncRepl fails to replicate new trees (ITS#2948)
>
> Sure, but I'll reiterate -- Adds of new entries in existing trees, and
> changes to existing trees, replicate just fine.
>
> In thinking about it, I think this is really the same as ITS#2928
>
>
> syncrepl rid=0
> provider=ldap://ldap-devmaster.stanford.edu:389
> updatedn="cn=Manager,dc=stanford,dc=edu"
>
> binddn="cn=ldap-dev1,cn=ldap,cn=operational,dc=stanford,dc=edu"
> bindmethod=sasl
> saslmech=gssapi
> searchbase="dc=stanford,dc=edu"
> authcId=ldap/ldap-dev1.stanford.edu@stanford.edu
> realm=stanford.edu
> schemachecking=on
> type=refreshAndPersist
>
Three additional questions:
1) is the above binddn ("cn=ldap-dev1,cn=ldap,cn=operational,dc=stanford,dc=edu")
one of the three objects created under the extension
("cn=ldap,cn=operational,dc=stanford,dc=edu")
as described in the ITS#2948 ?
2) does the binddn have appropriate access privileges for the extension subtree ?
3) is the provider database a glued or is the new extension located in the same database
as the searchbase ?
- Jong