[389-users] ChainOnUpdate

Rich Megginson rmeggins at redhat.com
Mon Mar 5 23:32:53 UTC 2012


On 03/05/2012 03:55 PM, Jim Finn wrote:
>
> Note: I have searched through years past in 389-users and have found a 
> few others experiencing the same problem, yet I could not find any 
> resolution.
>
>
> I am attempting to setup chain on update per 
> http://directory.fedoraproject.org/wiki/Howto:ChainOnUpdate
>
>
> The packages installed are:
>
> 389-admin-console-1.1.8-1.el6.noarch
>
> 389-ds-1.2.2-1.el6.noarch
>
> 389-ds-base-1.2.9.14-1.el6_2.2.x86_64
>
> 389-console-1.1.7-1.el6.noarch
>
> 389-admin-console-doc-1.1.8-1.el6.noarch
>
> 389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64
>
> 389-dsgw-1.1.7-2.el6.x86_64
>
> 389-ds-console-1.2.6-1.el6.noarch
>
> 389-ds-console-doc-1.2.6-1.el6.noarch
>
> 389-adminutil-1.1.14-2.el6.x86_64
>
> 389-admin-1.1.25-1.el6.x86_64
>
>
> The justification for use of chain_on_update is that our clients are 
> “dumb” and unable to follow referrals.
>
>
> As a POC, I am testing with two servers: be1.foo.com 
> <http://be1.foo.com> (Master) and be2.foo.com <http://be2.foo.com> 
> (Consumer)
>
>
> Prior to following the instructions in the Howto:ChainOnUpdate (linked 
> above) the environment operated as follows:
>
>
> Scenario A)
>
> Client.foo.com <http://Client.foo.com> attempts to modify be1.foo.com 
> <http://be1.foo.com> -> Allowed
>
> Change made by client.foo.com <http://client.foo.com> to be1.foo.com 
> <http://be1.foo.com> is replicated to be2.foo.com <http://be2.foo.com>
>
> Ldapsearch of both searvers shows the item was properly replicated, 
> value is the same on be1 and be2
>
> -----
>
> Scenario B)
>
> Client.foo.com <http://Client.foo.com> attempts to modify be2.foo.com 
> <http://be2.foo.com> -> Not allowed, given referral
>
>
> Upon following the instructions in the aforementioned howto the 
> environment operates as follows:
>
>
> Scenario A)
>
> Client.foo.com <http://Client.foo.com> attempts to modify be1.foo.com 
> <http://be1.foo.com> -> Allowed
>
> Change made by client.foo.com <http://client.foo.com> to be1.foo.com 
> <http://be1.foo.com> is replicated to be2.foo.com <http://be2.foo.com>
>
> Ldapsearch of both searvers shows the item was properly replicated, 
> value is the same on be1 and be2
>
> -----
>
> Scenario B)
>
> Client.foo.com <http://Client.foo.com> attempts to modify be2.foo.com 
> <http://be2.foo.com> -> Allowed
>
What credentials did you use?  Note that cn=directory manager is not 
chained because the directory manager credentials are local to each server.
>
> Change made by client.foo.com <http://client.foo.com> **SHOULD** have 
> been handled by the chaining backend and modified on be1
>
> Ldapsearch of both servers shows the item was modified on be2 but not 
> be1 (be1 still has the old value)
>
>
> It seems the writes from client.foo.com <http://client.foo.com> to 
> be2.foo.com <http://be2.foo.com> are being committed to be local 
> database (userRoot) instead of being handled by the chaining backend 
> (chainbe1).
>
>
> As the howto suggests, I am using the replication manager for the 
> proxy auth.  I have confirmed the credentials on all servers.
>
>
> dn: cn=dc\3Dfoo\2Cdc\3Dcom,cn=mapping tree,cn=config
>
> objectClass: top
>
> objectClass: extensibleObject
>
> objectClass: nsMappingTree
>
> cn: "dc=foo,dc=com"
>
> nsslapd-state: backend
>
> nsslapd-backend: userRoot
>
> nsslapd-backend: chainbe1
>
> nsslapd-distribution-plugin: libreplication-plugin.so
>
> nsslapd-distribution-funct: repl_chain_on_update
>
>
> dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
>
> objectClass: top
>
> objectClass: extensibleObject
>
> objectClass: nsBackendInstance
>
> cn: userRoot
>
> numSubordinates: 7
>
> nsslapd-suffix: dc=foo,dc=com
>
> nsslapd-cachesize: -1
>
> nsslapd-cachememsize: 10485760
>
> nsslapd-readonly: off
>
> nsslapd-require-index: off
>
> nsslapd-directory: /var/lib/dirsrv/slapd-be2/db/userRoot
>
> nsslapd-dncachememsize: 10485760
>
>
> dn: cn=replica,cn=dc\3Dfoo\2Cdc\3Dcom,cn=mapping tree,cn=config
>
> objectClass: nsDS5Replica
>
> objectClass: top
>
> nsDS5ReplicaRoot: dc=foo,dc=com
>
> nsDS5ReplicaType: 2
>
> nsDS5Flags: 0
>
> nsds5ReplicaPurgeDelay: 604800
>
> nsDS5ReplicaBindDN: cn=replication manager,cn=replication,cn=config
>
> cn: replica
>
> nsDS5ReplicaId: 6553
>
> nsDS5ReplicaName: ((REDACTED FOR EMAIL THREAD))
>
>
> dn: cn=chainbe1,cn=chaining database,cn=plugins,cn=config
>
> objectClass: top
>
> objectClass: extensibleObject
>
> objectClass: nsBackendInstance
>
> cn: chainbe1
>
> nsslapd-suffix: "dc=foo,dc=com"
>
> nsfarmserverurl: ldap://be1.foo.com/ <http://be1.foo.com/>
>
> nsmultiplexorbinddn: cn=replication manager,cn=replication,cn=config
>
> nschecklocalaci: off
>
> nsusestarttls: on
>
> nsbindmethod:
>
> nsmultiplexorcredentials: {DES}((REDACTED FOR EMAIL THREAD))
>
>
> dn: cn=config,cn=chaining database,cn=plugins,cn=config
>
> objectClass: top
>
> objectClass: extensibleObject
>
> cn: config
>
> nstransmittedcontrols: 2.16.840.1.113730.3.4.2
>
> nstransmittedcontrols: 2.16.840.1.113730.3.4.9
>
> nstransmittedcontrols: 1.2.840.113556.1.4.473
>
> nstransmittedcontrols: 1.3.6.1.4.1.1466.29539.12
>
> nspossiblechainingcomponents: cn=resource limits,cn=components,cn=config
>
> nspossiblechainingcomponents: cn=certificate-based 
> authentication,cn=component
>
> s,cn=config
>
> nspossiblechainingcomponents: cn=password policy,cn=components,cn=config
>
> nspossiblechainingcomponents: cn=sasl,cn=components,cn=config
>
> nspossiblechainingcomponents: cn=roles,cn=components,cn=config
>
> nspossiblechainingcomponents: cn=ACL Plugin,cn=plugins,cn=config
>
> nspossiblechainingcomponents: cn=old plugin,cn=plugins,cn=config
>
> nspossiblechainingcomponents: cn=referential integrity 
> postoperation,cn=plugin
>
> s,cn=config
>
> nspossiblechainingcomponents: cn=attribute uniqueness,cn=plugins,cn=config
>
>
>
> Any help in getting ChainOnUpdate to work with my 389 servers would be 
> greatly appreciated.
>
>
> Thanks in advance!
>
>
> Jim Finn
>
>
>
>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20120305/31f7c56a/attachment.html>


More information about the 389-users mailing list