[Fedora-directory-users] Chain on Update Problem

Fri Sep 1 23:01:08 UTC 2006

James B Newby wrote:
> I found the MOD line in the consumer's access log.  I saw no entry in 
> the master's access log regarding that entry.  It seems as if the 
> request doesn't make it to the master.  I can telnet into the ldap 
> port on the master from the consumer.
>
> I installed Fedora Directory Server from 
> fedora-ds-1.0.2-1.FC4.i386.opt.rpm on all machines.  All three 
> machines are Intel/CentOS 4.3.
>
> -James
>
> In the consumer's access log:
> [01/Sep/2006:17:41:34 -0500] conn=1 op=8 SRCH 
> base="uid=jhines,ou=people,o=thgg,dc=hg,dc=com" scope=0 
> filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs="nsRole 
> nsRoleDN objectClass nsAccountLock"
> [01/Sep/2006:17:41:34 -0500] conn=1 op=8 RESULT err=0 tag=101 
> nentries=1 etime=0
> [01/Sep/2006:17:41:34 -0500] conn=1 op=9 SRCH base="" scope=0 
> filter="(objectClass=*)" attrs="nsslapd-suffix nsBackendSuffix"
> [01/Sep/2006:17:41:34 -0500] conn=1 op=9 RESULT err=0 tag=101 
> nentries=1 etime=0
> [01/Sep/2006:17:41:34 -0500] conn=0 op=14 SRCH base="cn=ldbm database, 
> cn=plugins, cn=config" scope=2 
> filter="(objectClass=nsBackendInstance)" attrs="nsslapd-suffix 
> nsBackendSuffix"
> [01/Sep/2006:17:41:34 -0500] conn=0 op=14 RESULT err=0 tag=101 
> nentries=2 etime=0
> [01/Sep/2006:17:41:34 -0500] conn=0 op=15 SRCH base="" scope=0 
> filter="(objectClass=*)" attrs="nsBackendSuffix"
> [01/Sep/2006:17:41:34 -0500] conn=0 op=15 RESULT err=0 tag=101 
> nentries=1 etime=0
> [01/Sep/2006:17:41:34 -0500] conn=0 op=16 SRCH base="cn=MCC uid=jhines 
> ou=people o=thgg dc=hg dc=com, cn=chainbe1, cn=ldbm database, 
> cn=plugins, cn=config" scope=0 
> filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs="dn"
> [01/Sep/2006:17:41:34 -0500] conn=0 op=16 RESULT err=32 tag=101 
> nentries=0 etime=0
> [01/Sep/2006:17:41:35 -0500] conn=1 op=10 SRCH 
> base="uid=jhines,ou=people,o=thgg,dc=hg,dc=com" scope=0 
> filter="(|(objectClass=*)(objectClass=ldapsubentry))" 
> attrs="numSubordinates nscpEntryDN subschemaSubentry 
> nsYIMStatusGraphic modifiersName parentid nsICQStatusGraphic 
> nsAIMStatusText passwordExpirationTime nsBackendSuffix hasSubordinates 
> nsRole nsRoleDN accountUnlockTime passwordExpWarned nsYIMStatusText 
> copiedFrom nsSizeLimit ldapSchemas nsAIMStatusGraphic dncomp 
> nsTimeLimit passwordHistory retryCountResetTime 
> passwordAllowChangeTime aci entryid nsIdleTimeout entrydn copyingFrom 
> nsAccountLock nsds5ReplConflict modifyTimestamp passwordGraceUserTime 
> passwordRetryCount nsUniqueId nsSchemaCSN creatorsName nsICQStatusText 
> pwdpolicysubentry ldapSyntaxes createTimestamp nsLookThroughLimit *"
> [01/Sep/2006:17:41:35 -0500] conn=1 op=10 RESULT err=0 tag=101 
> nentries=1 etime=0
> [01/Sep/2006:17:41:35 -0500] conn=1 op=11 SRCH 
> base="uid=jhines,ou=people,o=thgg,dc=hg,dc=com" scope=0 
> filter="(objectClass=*)" attrs="*"
> [01/Sep/2006:17:41:35 -0500] conn=1 op=11 RESULT err=0 tag=101 
> nentries=1 etime=0
> [01/Sep/2006:17:41:36 -0500] conn=1 op=12 SRCH 
> base="uid=jhines,ou=people,o=thgg,dc=hg,dc=com" scope=0 
> filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
> [01/Sep/2006:17:41:36 -0500] conn=1 op=12 RESULT err=0 tag=101 
> nentries=1 etime=0
> [01/Sep/2006:17:41:41 -0500] conn=1 op=14 MOD 
> dn="uid=jhines,ou=people,o=thgg,dc=hg,dc=com"
> [01/Sep/2006:17:41:41 -0500] conn=1 op=14 RESULT err=0 tag=103 
> nentries=0 etime=0
> [01/Sep/2006:17:41:41 -0500] conn=0 op=18 SRCH 
> base="uid=jhines,ou=people,o=thgg,dc=hg,dc=com" scope=0 
> filter="(|(objectClass=*)(objectClass=ldapsubentry))" 
> attrs="objectClass numSubordinates ref aci"
> [01/Sep/2006:17:41:41 -0500] conn=0 op=18 SORT cn givenName o ou sn (1)
> [01/Sep/2006:17:41:41 -0500] conn=0 op=18 RESULT err=0 tag=101 
> nentries=1 etime=0 notes=U
Weird.  It looks as though you added the entry to the local server, and 
were able to search for it right away.  e.g. you search for uid=jhines, 
and the server replies with err=0 and nentries=1.  Can you try the same 
search from the ldapsearch command line?
>
>
> Richard Megginson wrote:
>> James B Newby wrote:
>>> Hello all,
>>>
>>> I'm having a problem with my consumer's chain on update.  I have a 
>>> setup with two masters and one consumer.  Multi-master replication 
>>> is working properly.  Changes made on either master propagate to the 
>>> other master and to the consumer.
>>>
>>> Before setting up chaining, changes made on the consumer from the 
>>> directory console would be denied.  After setting up chaining per 
>>> the wiki entry:
>>> http://directory.fedora.redhat.com/wiki/Howto:ChainOnUpdate ,
>>> changes could be made on the consumer through the directory console, 
>>> but would not propagate to the master.
>> How are you testing/verifying the change doesn't get through?  Note 
>> that if you make the change in the console, the console will not 
>> automatically refresh.  I would first check the access log on the 
>> consumer to find the ADD or MOD request, then see if that request 
>> made it to a master, then see if the master rejected it and why.
>>>
>>> I saw an e-mail with a similar problem in the December 2005 archive, 
>>> but didn't see any info in the replies that would help me.  I've 
>>> tried setting this up from scratch a couple times, but without 
>>> success.  The responses to ILoveJython's email in December suggested 
>>> that certain entries be pasted in, so I've included them below.
>>>
>>> The following acl is included in dc=hg,dc=com:
>>> (targetattr = "*")(version 3.0; acl "Proxied authorization for 
>>> database links";allow (proxy) (userdn = "ldap:///cn=Replication 
>>> Manager, cn=config");)
>>> Since multi-master replication is set up, this entry is present on 
>>> all three servers.
>>>
>>> Any help would be appreciated!  Thanks!
>>>
>>> -James
>>>
>>> dn: cn="dc=hg,dc=com",cn=mapping tree, cn=config
>>> objectClass: top
>>> objectClass: extensibleObject
>>> objectClass: nsMappingTree
>>> nsslapd-state: backend
>>> cn: "dc=hg,dc=com"
>>> cn: dc=hg,dc=com
>>> nsslapd-backend: userRoot
>>> nsslapd-backend: chainbe1
>>> nsslapd-referral: ldap://ldap1.mw1.highergear.com:1389/dc=hg,dc=com
>>> nsslapd-referral: ldap://ldap2.mw1.highergear.com:1389/dc=hg,dc=com
>>> nsslapd-distribution-plugin: /opt/fedora-ds/lib/replication-plugin.so
>>> nsslapd-distribution-funct: repl_chain_on_update
>>>
>>> dn: cn=replica,cn="dc=hg,dc=com",cn=mapping tree, cn=config
>>> objectClass: nsDS5Replica
>>> objectClass: top
>>> nsDS5ReplicaRoot: dc=hg,dc=com
>>> nsDS5ReplicaType: 2
>>> nsDS5Flags: 0
>>> nsds5ReplicaPurgeDelay: 604800
>>> nsDS5ReplicaBindDN: cn=Replication Manager,cn=config
>>> cn: replica
>>> nsDS5ReplicaId: 65535
>>> nsState:: //8AAIcx9kQAAAAAAAAAAAEAAAA=
>>> nsDS5ReplicaName: ddc65803-1dd111b2-80e6a7e3-5afe0000
>>> nsDS5ReplicaReferral: ldap://ldap1.mw1.highergear.com:1389/dc=hg,dc=com
>>> nsDS5ReplicaReferral: ldap://ldap2.mw1.highergear.com:1389/dc=hg,dc=com
>>> nsds5ReplicaChangeCount: 0
>>> nsds5replicareapactive: 0
>>>
>>> dn: cn=config,cn=chaining database,cn=plugins,cn=config
>>> cn: config
>>> objectClass: top
>>> objectClass: extensibleObject
>>> 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=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
>>> dn: cn=chainbe1, cn=chaining database, cn=plugins, cn=config
>>> objectClass: top
>>> objectClass: extensibleObject
>>> objectClass: nsBackendInstance
>>> cn: chainbe1
>>> nsslapd-suffix: dc=hg,dc=com
>>> nsfarmserverurl: ldap://ldap1.mw1.highergear.com:1389 
>>> ldap2.mw1.highergear.com
>>> :1389/
>>> nsmultiplexorbinddn: cn=Replication Manager, cn=config
>>> nsmultiplexorcredentials: {DES}<PASSWORD ERASED>
>>> nsbindconnectionslimit: 3
>>> nsoperationconnectionslimit: 20
>>> nsabandonedsearchcheckinterval: 1
>>> nsconcurrentbindlimit: 10
>>> nsconcurrentoperationslimit: 2
>>> nsproxiedauthorization: on
>>> nsconnectionlife: 0
>>> nsbindtimeout: 15
>>> nsreferralonscopedsearch: off
>>> nschecklocalaci: on
>>> nsbindretrylimit: 3
>>> nsslapd-sizelimit: 2000
>>> nsslapd-timelimit: 3600
>>> nshoplimit: 10
>>> nsmaxresponsedelay: 60
>>> nsmaxtestresponsedelay: 15
>>>
>>> -- 
>>> Fedora-directory-users mailing list
>>> Fedora-directory-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>> ------------------------------------------------------------------------
>>
>> -- 
>> Fedora-directory-users mailing list
>> Fedora-directory-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>   
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3178 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-users/attachments/20060901/f16997dc/attachment.bin>