[Fedora-directory-users] Chain on Update Problem
Richard Megginson
rmeggins at redhat.com
Sat Sep 2 03:24:50 UTC 2006
James B Newby wrote:
> Well actually the entry was already there; I just made a small change
> to one of the attributes on the consumer through the directory console.
>
> I added a new entry on the consumer from the command line:
>
> [root at ldap1 bin]# ./ldapmodify -a -D cn=Manager -w - -h localhost -p 1389
> Enter bind password:
> dn: uid=nbody,ou=people,o=thgg,dc=hg,dc=com
> telephoneNumber: 800-555-5555
> userPassword: <erased>
> cn: No Body
> sn: Body
> objectClass: hgperson
> objectClass: inetorgperson
> objectClass: organizationalPerson
> objectClass: person
> objectClass: top
> givenName: No
> uid: nbody
> mail: nbody at highergear.com
> adding new entry uid=nbody,ou=people,o=thgg,dc=hg,dc=com
>
> [root at ldap1 bin]#
>
> Then I searched for that user on the consumer's command line:
> [root at ldap1 bin]# ./ldapsearch -b "dc=hg,dc=com" -D cn=Manager -w - -h
> localhost -p 1389 uid=nbody
> Enter bind password:
> version: 1
> dn: uid=nbody,ou=people,o=thgg,dc=hg,dc=com
> telephoneNumber: 800-555-5555
> cn: No Body
> sn: Body
> objectClass: hgperson
> objectClass: inetorgperson
> objectClass: organizationalPerson
> objectClass: person
> objectClass: top
> givenName: No
> uid: nbody
> mail: nbody at highergear.com
> userPassword: {SSHA}<erased>
> [root at ldap1 bin]#
>
> Here is what resulted in the access log of the consumer:
> [01/Sep/2006:18:18:12 -0500] conn=4 fd=66 slot=66 connection from
> 127.0.0.1 to 127.0.0.1
> [01/Sep/2006:18:18:12 -0500] conn=4 op=0 BIND dn="cn=Manager"
> method=128 version=3
> [01/Sep/2006:18:18:12 -0500] conn=4 op=0 RESULT err=0 tag=97
> nentries=0 etime=0 dn="cn=manager"
> [01/Sep/2006:18:18:18 -0500] conn=4 op=1 ADD
> dn="uid=nbody,ou=people,o=thgg,dc=hg,dc=com"
> [01/Sep/2006:18:18:18 -0500] conn=4 op=1 RESULT err=0 tag=105
> nentries=0 etime=0
> [01/Sep/2006:18:18:21 -0500] conn=4 op=3 UNBIND
> [01/Sep/2006:18:18:21 -0500] conn=4 op=3 fd=66 closed - U1
> [01/Sep/2006:18:18:47 -0500] conn=5 fd=66 slot=66 connection from
> 127.0.0.1 to 127.0.0.1
> [01/Sep/2006:18:18:47 -0500] conn=5 op=0 BIND dn="cn=Manager"
> method=128 version=3
> [01/Sep/2006:18:18:47 -0500] conn=5 op=0 RESULT err=0 tag=97
> nentries=0 etime=0 dn="cn=manager"
> [01/Sep/2006:18:18:47 -0500] conn=5 op=1 SRCH base="dc=hg,dc=com"
> scope=2 filter="(uid=nbody)" attrs=ALL
> [01/Sep/2006:18:18:47 -0500] conn=5 op=1 RESULT err=0 tag=101
> nentries=1 etime=0
> [01/Sep/2006:18:18:47 -0500] conn=5 op=2 UNBIND
> [01/Sep/2006:18:18:47 -0500] conn=5 op=2 fd=66 closed - U1
So it appears to be working?
>
> I then searched for that new entry in the Directory Console and the
> following log entries resulted:
> [01/Sep/2006:18:19:58 -0500] conn=0 op=28 SRCH
> base="ou=people,o=thgg,dc=hg,dc=com" scope=1
> filter="(|(objectClass=*)(objectClass=ldapsubentry))"
> attrs="objectClass numSubordinates ref aci"
> [01/Sep/2006:18:19:58 -0500] conn=0 op=28 SORT cn givenName o ou sn (196)
> [01/Sep/2006:18:19:58 -0500] conn=0 op=28 RESULT err=0 tag=101
> nentries=196 etime=0 notes=U
> [01/Sep/2006:18:20:04 -0500] conn=1 op=23 SRCH
> base="uid=nbody,ou=people,o=thgg,dc=hg,dc=com" scope=0
> filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs="nsRole
> nsRoleDN objectClass nsAccountLock"
> [01/Sep/2006:18:20:04 -0500] conn=1 op=23 RESULT err=0 tag=101
> nentries=1 etime=0
> [01/Sep/2006:18:20:04 -0500] conn=1 op=24 SRCH base="" scope=0
> filter="(objectClass=*)" attrs="nsslapd-suffix nsBackendSuffix"
> [01/Sep/2006:18:20:04 -0500] conn=1 op=24 RESULT err=0 tag=101
> nentries=1 etime=0
> [01/Sep/2006:18:20:04 -0500] conn=0 op=30 SRCH base="cn=ldbm database,
> cn=plugins, cn=config" scope=2
> filter="(objectClass=nsBackendInstance)" attrs="nsslapd-suffix
> nsBackendSuffix"
> [01/Sep/2006:18:20:04 -0500] conn=0 op=30 RESULT err=0 tag=101
> nentries=2 etime=0
> [01/Sep/2006:18:20:04 -0500] conn=0 op=31 SRCH base="" scope=0
> filter="(objectClass=*)" attrs="nsBackendSuffix"
> [01/Sep/2006:18:20:04 -0500] conn=0 op=31 RESULT err=0 tag=101
> nentries=1 etime=0
> [01/Sep/2006:18:20:04 -0500] conn=0 op=32 SRCH base="cn=MCC uid=nbody
> 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:18:20:04 -0500] conn=0 op=32 RESULT err=32 tag=101
> nentries=0 etime=0
> [01/Sep/2006:18:20:05 -0500] conn=1 op=26 SRCH
> base="uid=nbody,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:18:20:05 -0500] conn=1 op=26 RESULT err=0 tag=101
> nentries=1 etime=0
> [01/Sep/2006:18:20:05 -0500] conn=1 op=27 SRCH
> base="uid=nbody,ou=people,o=thgg,dc=hg,dc=com" scope=0
> filter="(objectClass=*)" attrs="*"
> [01/Sep/2006:18:20:05 -0500] conn=1 op=27 RESULT err=0 tag=101
> nentries=1 etime=0
> [01/Sep/2006:18:20:05 -0500] conn=1 op=28 SRCH
> base="uid=nbody,ou=people,o=thgg,dc=hg,dc=com" scope=0
> filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
This appears to be working also?
>
> -James
>
> Richard Megginson wrote:
>> 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
>> ------------------------------------------------------------------------
>>
>> --
>> 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/071e904e/attachment.bin>
More information about the Fedora-directory-users
mailing list