FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Directory

 
 
LinkBack Thread Tools
 
Old 03-05-2012, 09:55 PM
Jim Finn
 
Default ChainOnUpdate

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=dc3Dfoo2Cdc3Dcom,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=dc3Dfoo2Cdc3Dcom,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 list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 03-05-2012, 10:32 PM
Rich Megginson
 
Default ChainOnUpdate

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=dc3Dfoo2Cdc3Dcom,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=dc3Dfoo2Cdc3Dcom,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 list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users





--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 03-05-2012, 11:47 PM
Jim Finn
 
Default ChainOnUpdate

(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: snsn: 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: snsn: 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@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=dc3Dfoo2Cdc3Dcom,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=dc3Dfoo2Cdc3Dcom,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 list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users







--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 

Thread Tools




All times are GMT. The time now is 09:38 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org