(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
and modify the following
dn..
dn: uid=jim,dc=foo,dc=com
changetype: modify
replace: sn
sn: changed on be1
I could then search
(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
and modifies ..
changetype: modify
replace: sn
sn: changed on be2
I would then search
(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> 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
list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users