James B Newby wrote:
> Yes. I can add or modify entries on the consumer with update chaining
> set up, but those changes do not propagate to the master. If I search
> on the master for the entry created on the consumer :
>
> [root at ldap1-mw1 bin]$ ./ldapsearch -b dc=hg,dc=com -D cn=Manager -w -
> -h localhost -p 1389 uid=nbody
> Enter bind password:
> [root at ldap1-mw1 bin]$
>
> It's not there. As I said in an earlier message, I've followed the
> instructions in the Chain on Update HOWTO, but I can't get it to
> work. I've reviewed the Administrator Guide as well as searching the
> Internet for an answer but no luck.
So, is this is a read only consumer? If so, you should not be able to
write to it. That's what is confusing me. If this is a read-only
consumer, you should get an err=10 back from a write operation if
chaining is not set up.
>
> Richard Megginson wrote:
>> 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
>> ------------------------------------------------------------------------
>>
>> --
>> 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/20060905/093f3649/attachment.bin
