Chain on Update Problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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://lists.fedoraproject.org/pipermail/389-users/attachments/20060901/071e904e/attachment.bin 


[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux