On Wednesday 29 September 2010 23:30:49 Rich Megginson wrote:
> Jacek Nykis wrote:
> > On Wednesday 29 September 2010 14:04:38 Gerrard Geldenhuis wrote:
> >> Hi
> >> I have setup chaining but it is not working at all and I am not sure how
> >> to debug it further.
> >>
> >> I am using:
> >> 389-admin-1.1.11-0.6.rc2.el5
> >> 389-admin-console-1.1.5-1.el5
> >> 389-admin-console-doc-1.1.5-1.el5
> >> 389-adminutil-1.1.8-4.el5
> >> 389-console-1.1.4-1.el5
> >> 389-ds-1.2.1-1.el5
> >> 389-ds-base-1.2.6-0.11.rc7.el5
> >> 389-ds-console-1.2.3-1.el5
> >> 389-ds-console-doc-1.2.3-1.el5
> >> 389-dsgw-1.1.5-1.el5
> >>
> >> The setup is 4 servers, two multimasters and two consumers. Client can
> >> only speak to the consumers and thus referrals won't work.
> >>
> >>
> >> I have used the following ldif to setup chaining:
> >>
> >> dn: cn=chainingBackend,cn=chaining database,cn=plugins,cn=config
> >> changetype: add
> >> objectClass: top
> >> objectClass: extensibleObject
> >> objectClass: nsBackendInstance
> >> cn: chainingBackend
> >> nsslapd-suffix: dc=mycompany
> >> nsmultiplexorbinddn: cn=replication manager,cn=config
> >> nsusestarttls: on
> >> nsfarmserverurl: ldaps://masterfqdn1:636 masterfqdn2:636/
> >> nsmultiplexorcredentials: {SSHA}blah
> >> nsbindconnectionslimit: 5
> >> nsconcurrentoperationslimit: 5
> >> nsconnectionlife: 130
> >> nsbindtimeout: 3
> >> nsbindretrylimit: 3
> >> nsmaxresponsedelay: 3
> >> nsmaxtestresponsedelay: 5
> >>
> >> dn: cn=dc\3dmycompany,cn=mapping tree,cn=config
> >> changetype: modify
> >> add: nsslapd-backend
> >> nsslapd-backend: chainingBackend
> >> -
> >> replace: nsslapd-state
> >> nsslapd-state: backend
> >> -
> >> replace: nsslapd-distribution-plugin
> >> nsslapd-distribution-plugin:
> >> /usr/lib64/dirsrv/plugins/libreplication-plugin.so -
> >> replace: nsslapd-distribution-funct
> >> nsslapd-distribution-funct: repl_chain_on_update
> >>
> >>
> >> dn: cn=config,cn=chaining database,cn=plugins,cn=config
> >> changetype: modify
> >> add: nsTransmittedControls
> >> nsTransmittedControls: 2.16.840.1.113730.3.4.12
> >>
> >> The ACI has been created to allow the Replication Manager user proxy
> >> access.
> >>
> >> When I run the following on the client:
> >>
> >> dn: uid=john,ou=people,dc=mycompany
> >> changetype: modify
> >> add: mobile
> >> mobile: 1234
> >>
> >> The entry gets added but only locally, it thus seems to be completely
> >> ignoring the chaining I have setup. I see the following in the consumer
> >> log after creation:
> >>
> >> [29/Sep/2010:13:00:11 +0000] start_tls - Received extended operation
> >> request with OID 1.3.6.1.4.1.1466.20037 [29/Sep/2010:13:00:11 +0000]
> >> start_tls - Start TLS extended operation request confirmed.
> >> [29/Sep/2010:13:00:11 +0000] start_tls - Start TLS request
> >> accepted.Server willing to negotiate SSL. [29/Sep/2010:13:00:11 +0000]
> >> start_tls - Starting SSL Handshake.
> >> [29/Sep/2010:13:00:11 +0000] NS7bitAttr - MODIFY begin
> >> [29/Sep/2010:13:00:11 +0000] NSMMReplicationPlugin - Purged state
> >> information from entry uid=rytis,ou=People,dc=betfair up to CSN
> >> 4c99ec08000000010000 [29/Sep/2010:13:00:12 +0000] roles-plugin - -->
> >> roles_post_op
> >> [29/Sep/2010:13:00:12 +0000] roles-plugin - -->
> >> roles_cache_change_notify [29/Sep/2010:13:00:12 +0000] roles-plugin -
> >> <-- roles_cache_change_notify: not a role entry [29/Sep/2010:13:00:12
> >> +0000] roles-plugin - <-- roles_post_op
> >>
> >>
> >> There is some other replay failure errors which I am not sure is
> >> related. Having done the the test twice I did not see the replay errors
> >> again in the master log. I am going to simplify my test environment as
> >> I currently have 4 servers which all are verbal about replication and I
> >> multimaster netscapedb which adds to the complications.
> >>
> >> I have enabled Replication and Plug-ins for the error log, is there any
> >> other recommended logs that I should enable that can assist me in
> >> debugging chaining issues.
> >
> > Hi,
> > I am working with Gerrard on this issue. I took some packet captures and
> > it would seem that chaining in fact picks up updates but it does not
> > handle them properly.
> >
> > Our design is:
> > Client ----> Slave ----> Master
> >
> > We chain all updates on slave to master and client only has access to
> > slave. We also have replication from master to slave.
> >
> > When I try to make an update here is what happens between client and
> > slave: bindRequest(1) "uid=xxxx,ou=People,dc=xxxx" simple
> > bindResponse(1) success
> > modifyRequest(2) "uid=xxx,ou=people,dc=xxx"
> > modifyResponse(2) operationsError
> > unbindRequest(3)
> >
> > At the same time between slave and master:
> > searchRequest(1) "<ROOT>" baseObject
> > searchResEntry(1) "<ROOT>" | searchResDone(1) success [1 result]
> > unbindRequest(2)
> >
> > This does not look correct (no modification request at all goes to
> > master).
>
> Right, because it is rejected on the slave due to operationsError
Thank you for your answer.
I enabled verbose logging but I am unable to find out what is causing
"operationsError".
Log below suggests that chainingBackend is being selected just before
modification starts but I am not sure if it is actually used:
[29/Sep/2010:22:41:54 +0000] - new connection on 66
[29/Sep/2010:22:41:54 +0000] - activity on 66r
[29/Sep/2010:22:41:54 +0000] - read activity on 66
[29/Sep/2010:22:41:54 +0000] - conn 184 activity level = 0
[29/Sep/2010:22:41:54 +0000] - listener got signaled
[29/Sep/2010:22:41:54 +0000] - mapping tree selected backend : userRoot
[29/Sep/2010:22:41:54 +0000] - mapping tree selected backend : userRoot
[29/Sep/2010:22:41:54 +0000] - mapping tree release backend : userRoot
[29/Sep/2010:22:41:54 +0000] - mapping tree selected backend : userRoot
[29/Sep/2010:22:41:54 +0000] - mapping tree release backend : userRoot
[29/Sep/2010:22:41:54 +0000] - mapping tree selected backend : userRoot
[29/Sep/2010:22:41:54 +0000] - mapping tree release backend : userRoot
[29/Sep/2010:22:41:54 +0000] - activity on 66r
[29/Sep/2010:22:41:54 +0000] - read activity on 66
[29/Sep/2010:22:41:54 +0000] - do_modify: dn (uid=xxx,ou=people,dc=xxx)
[29/Sep/2010:22:41:54 +0000] - listener got signaled
[29/Sep/2010:22:41:54 +0000] - modifications:
[29/Sep/2010:22:41:54 +0000] - replace: mobile
[29/Sep/2010:22:41:54 +0000] - mapping tree selected backend : chainingBackend
[29/Sep/2010:22:41:54 +0000] - mapping tree selected backend : userRoot
[29/Sep/2010:22:41:54 +0000] - mapping tree release backend : userRoot
[29/Sep/2010:22:41:54 +0000] NS7bitAttr - MODIFY begin
[29/Sep/2010:22:41:54 +0000] - mapping tree selected backend : userRoot
[29/Sep/2010:22:41:54 +0000] - mapping tree release backend : userRoot
[29/Sep/2010:22:41:54 +0000] - activity on 66r
[29/Sep/2010:22:41:54 +0000] - read activity on 66
[29/Sep/2010:22:41:54 +0000] roles-plugin - --> roles_post_op
[29/Sep/2010:22:41:54 +0000] roles-plugin - --> roles_cache_change_notify
[29/Sep/2010:22:41:54 +0000] roles-plugin - <-- roles_post_op
>
> > Does anybody know what the problem could be or where to look for it?
> >
> >> Best Regards
> >>
> >> ________________________________________________________________________
> >> In order to protect our email recipients, Betfair Group use SkyScan from
> >> MessageLabs to scan all Incoming and Outgoing mail for viruses.
> >>
> >> ________________________________________________________________________
> >> --
> >> 389 users mailing list
> >> 389-users@xxxxxxxxxxxxxxxxxxxxxxx
> >> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
> --
> 389 users mailing list
> 389-users@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/389-users
--
Jacek Nykis
________________________________________________________________________
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.
________________________________________________________________________
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
