[389-users] ChainOnUpdate

[Jim Finn]

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 (Master) and
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 attempts to modify be1.foo.com -> Allowed

Change made by client.foo.com to be1.foo.com is replicated to 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 attempts to modify 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 attempts to modify be1.foo.com -> Allowed

Change made by client.foo.com to be1.foo.com is replicated to 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 attempts to modify be2.foo.com -> Allowed

Change made by 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 to 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/

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20120305/ef4349c0/attachment.html>