Re: syncRepl fails to replicate new trees (ITS#2948)

[quanah@stanford.edu]

--On Friday, February 06, 2004 11:18 PM -0500 Jong <jongchoi@OpenLDAP.org> 
wrote:

> 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 ?

Yes


> 2) does the binddn have appropriate access privileges for the extension
> subtree ?

Yes.  From the master's ACL file:

access to *
        by group.base="cn=ldapreplica,cn=applications,dc=stanford,dc=edu" 
sasl_ssf=56 read
        by * break


which is why other updates work.

ldap-dev0:/usr/local/etc/openldap# ldapsearch -LLL -Q -h ldap-dev0 
cn=ldapreplica
dn: cn=ldapReplica,cn=Applications,dc=stanford,dc=edu
objectClass: groupOfNames
cn: ldapReplica
member: cn=ldap-dev1,cn=ldap,cn=operational,dc=stanford,dc=edu
member: cn=ldap-dev2,cn=ldap,cn=operational,dc=stanford,dc=edu
member: cn=ldap-dev3,cn=ldap,cn=operational,dc=stanford,dc=edu


> 3) is the provider database a glued or is the new extension
> located in the same database as the searchbase ?

It is located in the same database as the searchbase.  I do not have any 
glued databases.

>From the provider:

database        hdb
shm_key         5
suffix          "dc=stanford,dc=edu"
rootdn          "cn=Manager,dc=stanford,dc=edu"

directory       /db

# Checkpoint
checkpoint 1024 5

# Indices to maintain
index   default         eq
index   cn
index   dc
index   objectClass
index   krb5PrincipalName
index   suGeneralID
index   suRegID
index   uid


--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITSS/TSS/Computing Systems
ITSS/TSS/Infrastructure Operations
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html