Your top-posting has made this reply less readable than it would have been if you had not top-posted ... On Thursday 17 August 2006 18:21, Steven Wong wrote: > Hi Buchan, > Here is the ACL's from one of the slaves > > access to dn.regex=".*,dc=pro-unlimited,dc=com" > attrs=userPassword > by self write > by dn="uid=replicator,ou=ldapbods,ou=people,dc=pro-unlimited,dc=com" > write by dn="uid=sysadmin,ou=ldapbods,ou=people,dc=pro-unlimited,dc=com" > write by * auth Don't use dn.regex when you could use dn.subtree to do exactly the same thing more efficiently. > access to dn.regex=".*,dc=pro-unlimited,dc=com" > attrs=shadowLastChange > by self write > by dn="uid=replicator,ou=ldapbods,ou=people,dc=pro-unlimited,dc=com" > write by dn="uid=sysadmin,ou=ldapbods,ou=people,dc=pro-unlimited,dc=com" > write by * read > > access to dn.regex=".*,dc=pro-unlimited,dc=com" > by dn="uid=proxyuser,ou=ldapbods,ou=people,dc=pro-unlimited,dc=com" read > by dn="uid=replicator,ou=ldapbods,ou=people,dc=pro-unlimited,dc=com" > write by dn="uid=sysadmin,ou=ldapbods,ou=people,dc=pro-unlimited,dc=com" > write by * read > Right, so you have no ACL which allows the replicadn to write to the "children" virtual attribute of the parent entry, dc=pro-unlimited,dc=com (as the error correctly indicates). You may want to changing your catch-all to be just 'access to *' instead of 'access to dn.regex=".*,dc=pro-unlimited,dc=com"', which would fix your problem. Regards, Buchan > > Thanks, > Steven > > ----- Original Message ---- > From: Buchan Milne <bgmilne@staff.telkomsa.net> > To: Steven Wong <slqwong@yahoo.com> > Cc: openLDAP software <openldap-software@OpenLDAP.org> > Sent: Thursday, August 17, 2006 12:07:57 AM > Subject: Re: slurpd not replicating to slave at root > > On Wednesday 16 August 2006 19:18, Steven Wong wrote: > > I was wondering if this is correct or if I have my access or config > > wrong. > > > > It seems that only "cn=manager,dc=pro-unlimited,dc=com", which is the > > rootdn can create a new child at the root level ( ie. > > ou=netgroup,dc=pro-unlimited,dc=com ) and my replica uses > > binddn="uid=replicator,ou=ldapbods,ou=people,dc=pro-unlimited,dc=com" > > > > [root@snort01 openldap]# ldapadd -x -D > > "uid=sysadmin,ou=ldapbods,ou=people,dc=pro-unlimited,dc=com" -w <passwd> > > -a -f /tmp/netg adding new entry "ou=netgroup,dc=pro-unlimited,dc=com" > > ldap_add: Insufficient access > > additional info: no write access to parent > > > > ldif_record() = 50 > > [root@snort01 openldap]# ldapadd -x -D > > "uid=replicator,ou=ldapbods,ou=people,dc=pro-unlimited,dc=com" -w > > <passwd> -a -f /tmp/netg adding new entry > > "ou=netgroup,dc=pro-unlimited,dc=com" ldap_add: Insufficient access > > additional info: no write access to parent > > > > ldif_record() = 50 > > > > If I were to use uid=replicator/sysadmin to add things under > > ou=hosts/people, I am able to add them fine. > > > > Does that mean, my only choice to get around this, such that sync can > > happen, even at the top level, is to use the rootdn as the binddn? > > No, it is preferable *not* to use the rootdn as replicadn, and it is > entirely possible to have it replicate any change in the directory, if your > ACLs allow it. > > > If there are any info needed, please let me know. > > A list of your ACLs would help. > > Regards, > Buchan -- Buchan Milne ISP Systems Specialist B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592)
Attachment:
pgpR069WcBJHr.pgp
Description: PGP signature