[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: slurpd not replicating to slave at root
- To: Buchan Milne <bgmilne@staff.telkomsa.net>
- Subject: Re: slurpd not replicating to slave at root
- From: Steven Wong <slqwong@yahoo.com>
- Date: Thu, 17 Aug 2006 09:21:42 -0700 (PDT)
- Cc: openLDAP software <openldap-software@OpenLDAP.org>
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=qJRgr93/NhXr1gFVE8xcrDqi9nfU5go1KElkFlccJ0I89002Fv61pAAsV7sua1GTlaVOK06ExtTKs2ewfBWBzvKOUG6MONCRC8y8D/D5D3twxKu8E9nS11iL+PCEgOjhXR0xHQ8Wg+4wxlGB1ijcP0i0mmc2ct7/5EmyCb8xc2s= ;
- In-reply-to: <200608170908.08356.bgmilne@staff.telkomsa.net>
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
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
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)