[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