Re: [389-users] ChainOnUpdate

[Jim Finn]

(resending w/ reply to all, 389-users)

I was using  "cn=directory manager" when attempting to make the updates.
 Using a user's credentials to do a MOD seemed to produced the desired
result.  Thanks!

As an aside, should it not be viewed as problematic that the database on a
consumer could be directly modified by "cn=directory manager" and those
changes are not reflected on the Master (or other masters, hubs, or
consumers, for that matter) ?

Hypothetically speaking...
"cn=directory manager" could bind to be1.foo.com and modify the following
dn..
dn: uid=jim,dc=foo,dc=com
changetype: modify
replace: sn
sn: changed on be1

I could then search be1.foo.com (Master) and be2.foo.com (consumer)
and find the value for "sn" on "uid=jim,dc=foo,dc=com" is
"changed on be1"
on both servers

The above makes sense.

Now, If i were to  make the same change to be2...
"cn=directory manager" binds to be2.foo.com and modifies ..
changetype: modify
replace: sn
sn: changed on be2

I would then search be1.foo.com (Master) and find sn to have a value of
"changed on be1"
a search of be2.foo.com (Consumer) would show sn has a value of "changed on
be2"

It seems this could have a detrimental effect on the integrity of the
environment.

Thoughts?


Thanks again for your help!


On Mon, Mar 5, 2012 at 5:32 PM, Rich Megginson <rmeggins(a)redhat.com&gt; wrote:

>   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 (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
>
>  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 **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
>
>
>
>
>  --
>  389 users mailing
> [e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>