Nathan Kinder wrote:
> Try using a different bind DN for chaining than your "cn=Replication
> Manger, cn=config" user. It could be that replication is getting
> confused when chaining updates are being performed by that user since
> it will assume that updates by that user were sent via a replication
> agreement. I would create a chaining specific user such as
> "cn=Chaining Manager, cn=config" and configure chaining to use that user.
I don't think that's the problem. Chain on Update is supposed to work
with the repl manager DN - in fact it's much easier that way since that
user already exists on all of the replicas.
>
> -NGK
>
> James B Newby wrote:
>> Example 1:
>>
>> Adding an entry to the consumer:
>>
>> [root at ldap1 bin]# ./ldapmodify -a -D cn=Manager -w - -h localhost -p
>> 1389
>> Enter bind password:
>> dn: uid=sbody,ou=people,o=thgg,dc=hg,dc=com
>> objectClass: hgperson
>> telephonenumber: 555-555-5555
>> sn: Body
>> cn: Some Body
>> givenName: Some
>> mail: sbody at highergear.com
>> uid: sbody
>> adding new entry uid=sbody,ou=people,o=thgg,dc=hg,dc=com
>>
>> [root at ldap1 bin]#
>>
>> Searching for entry on consumer:
>>
>> [root at ldap1 bin]# ./ldapsearch -b dc=hg,dc=com -D cn=Manager -w - -h
>> localhost -p 1389 uid=sbody nscpEntryWsi nsUniqueID
>> Enter bind password:
>> version: 1
>> dn: uid=sbody,ou=people,o=thgg,dc=hg,dc=com
>> nscpEntryWsi: dn: uid=sbody,ou=people,o=thgg,dc=hg,dc=com
>> nscpEntryWsi: objectClass: hgperson
>> nscpEntryWsi: objectClass: inetOrgPerson
>> nscpEntryWsi: objectClass: organizationalPerson
>> nscpEntryWsi: objectClass: person
>> nscpEntryWsi: objectClass: top
>> nscpEntryWsi: telephoneNumber: 555-555-5555
>> nscpEntryWsi: sn: Body
>> nscpEntryWsi: cn: Some Body
>> nscpEntryWsi: givenName: Some
>> nscpEntryWsi: mail: sbody at highergear.com
>> nscpEntryWsi: uid: sbody
>> nscpEntryWsi: creatorsName: cn=manager
>> nscpEntryWsi: modifiersName: cn=manager
>> nscpEntryWsi: createTimestamp: 20060905232428Z
>> nscpEntryWsi: modifyTimestamp: 20060905232428Z
>> nscpEntryWsi: nsUniqueId: 8e72a281-1dd211b2-8091a7e3-5afe0000
>> nscpEntryWsi: parentid: 11
>> nscpEntryWsi: entryid: 19720
>> nscpEntryWsi: entrydn: uid=sbody,ou=people,o=thgg,dc=hg,dc=com
>> nsUniqueID: 8e72a281-1dd211b2-8091a7e3-5afe0000
So the entry is being added to the consumer. The consumer must not have
been configured properly to be a replication consumer for this suffix.
If if were, and if it had been initialized from a master, you would not
be able to do this.
>> [root at ldap1 bin]#
>>
>> Search for entry on Master 1:
>>
>> [root at ldap1-mw1 bin]# ./ldapsearch -b dc=hg,dc=com -D cn=Manager -w -
>> -h localhost -p 1389 uid=sbody nscpEntryWsi nsUniqueID
>> Enter bind password:
>> [root at ldap1-mw1 bin]#
>>
>> Search for entry on Master 2:
>>
>> [root at ldap2-mw1 bin]# ./ldapsearch -b dc=hg,dc=com -D cn=Manager -w -
>> -h localhost -p 1389 uid=sbody nscpEntryWsi nsUniqueID
>> Enter bind password:
>> [root at ldap2-mw1 bin]#
>>
>> -------------------------------------------------------
>>
>> Example 2:
>>
>> Create an entry on Master 1:
>>
>> [root at ldap1-mw1 bin]# ./ldapmodify -a -D cn=Manager -w - -h localhost
>> -p 1389
>> Enter bind password:
>> dn: uid=semployee,ou=people,o=thgg,dc=hg,dc=com
>> telephoneNumber: 800-555-5555
>> userPassword: <PASSWORD_ERASED>
>> cn: Some Employee
>> sn: Employee
>> objectClass: hgperson
>> givenName: Some
>> uid: semployee
>> mail: semployee at highergear.com
>>
>> adding new entry uid=semployee,ou=people,o=thgg,dc=hg,dc=com
>>
>> [root at ldap1-mw1 bin]#
>>
>> Search for entry on Master 1:
>> [root at ldap1-mw1 bin]# ./ldapsearch -b dc=hg,dc=com -D cn=Manager -w -
>> -h localhost -p 1389 uid=semployee nscpEntryWsi nsUniqueID
>> Enter bind password:
>> version: 1
>> dn: uid=semployee,ou=people,o=thgg,dc=hg,dc=com
>> nscpEntryWsi: dn: uid=semployee,ou=people,o=thgg,dc=hg,dc=com
>> nscpEntryWsi: telephoneNumber;vucsn-44fe0619000000010000: 800-555-5555
>> nscpEntryWsi: cn;vucsn-44fe0619000000010000: Some Employee
>> nscpEntryWsi: sn;vucsn-44fe0619000000010000: Employee
>> nscpEntryWsi: objectClass;vucsn-44fe0619000000010000: hgperson
>> nscpEntryWsi: objectClass;vucsn-44fe0619000000010000: inetOrgPerson
>> nscpEntryWsi: objectClass;vucsn-44fe0619000000010000:
>> organizationalPerson
>> nscpEntryWsi: objectClass;vucsn-44fe0619000000010000: person
>> nscpEntryWsi: objectClass;vucsn-44fe0619000000010000: top
>> nscpEntryWsi: givenName;vucsn-44fe0619000000010000: Some
>> nscpEntryWsi:
>> uid;vucsn-44fe0619000000010000;mdcsn-44fe0619000000010000: sempl
>> oyee
>> nscpEntryWsi: mail;vucsn-44fe0619000000010000: semployee at highergear.com
>> nscpEntryWsi: userPassword;vucsn-44fe0619000000010000:
>> {SSHA}<PASSWORD_ERASED>
>> nscpEntryWsi: creatorsName;vucsn-44fe0619000000010000: cn=manager
>> nscpEntryWsi: modifiersName;vucsn-44fe0619000000010000: cn=manager
>> nscpEntryWsi: createTimestamp;vucsn-44fe0619000000010000:
>> 20060905231943Z
>> nscpEntryWsi: modifyTimestamp;vucsn-44fe0619000000010000:
>> 20060905231943Z
>> nscpEntryWsi: nsUniqueId: fd033081-1dd111b2-80cef01a-e8560000
>> nscpEntryWsi: parentid: 11
>> nscpEntryWsi: entryid: 19718
>> nscpEntryWsi: entrydn: uid=semployee,ou=people,o=thgg,dc=hg,dc=com
>> nsUniqueID: fd033081-1dd111b2-80cef01a-e8560000
>> [root at ldap1-mw1 bin]#
>>
>> Search for Entry on Master 2:
>> [root at ldap2-mw1 bin]# ./ldapsearch -b dc=hg,dc=com -D cn=Manager -w -
>> -h localhost -p 1389 uid=semployee nscpEntryWsi nsUniqueID
>> Enter bind password:
>> version: 1
>> dn: uid=semployee,ou=people,o=thgg,dc=hg,dc=com
>> nscpEntryWsi: dn: uid=semployee,ou=people,o=thgg,dc=hg,dc=com
>> nscpEntryWsi: telephoneNumber;vucsn-44fe0619000000010000: 800-555-5555
>> nscpEntryWsi: cn;vucsn-44fe0619000000010000: Some Employee
>> nscpEntryWsi: sn;vucsn-44fe0619000000010000: Employee
>> nscpEntryWsi: objectClass;vucsn-44fe0619000000010000: hgperson
>> nscpEntryWsi: objectClass;vucsn-44fe0619000000010000: inetOrgPerson
>> nscpEntryWsi: objectClass;vucsn-44fe0619000000010000:
>> organizationalPerson
>> nscpEntryWsi: objectClass;vucsn-44fe0619000000010000: person
>> nscpEntryWsi: objectClass;vucsn-44fe0619000000010000: top
>> nscpEntryWsi: givenName;vucsn-44fe0619000000010000: Some
>> nscpEntryWsi:
>> uid;vucsn-44fe0619000000010000;mdcsn-44fe0619000000010000: sempl
>> oyee
>> nscpEntryWsi: mail;vucsn-44fe0619000000010000: semployee at highergear.com
>> nscpEntryWsi: userPassword;vucsn-44fe0619000000010000:
>> {SSHA}<PASSWORD_ERASED>
>> nscpEntryWsi: creatorsName;vucsn-44fe0619000000010000: cn=manager
>> nscpEntryWsi: modifiersName;vucsn-44fe0619000000010000: cn=manager
>> nscpEntryWsi: createTimestamp;vucsn-44fe0619000000010000:
>> 20060905231943Z
>> nscpEntryWsi: modifyTimestamp;vucsn-44fe0619000000010000:
>> 20060905231943Z
>> nscpEntryWsi: nsUniqueId: fd033081-1dd111b2-80cef01a-e8560000
>> nscpEntryWsi: parentid: 11
>> nscpEntryWsi: entryid: 19718
>> nscpEntryWsi: entrydn: uid=semployee,ou=people,o=thgg,dc=hg,dc=com
>> nsUniqueID: fd033081-1dd111b2-80cef01a-e8560000
>> [root at ldap2-mw1 bin]#
>>
>> Search for entry on consumer:
>> [root at ldap1 bin]# ./ldapsearch -b dc=hg,dc=com -D cn=Manager -w - -h
>> localhost -p 1389 uid=semployee nscpEntryWsi nsUniqueID
>> Enter bind password:
>> version: 1
>> dn: uid=semployee,ou=people,o=thgg,dc=hg,dc=com
>> nscpEntryWsi: dn: uid=semployee,ou=people,o=thgg,dc=hg,dc=com
>> nscpEntryWsi: telephoneNumber;vucsn-44fe0619000000010000: 800-555-5555
>> nscpEntryWsi: cn;vucsn-44fe0619000000010000: Some Employee
>> nscpEntryWsi: sn;vucsn-44fe0619000000010000: Employee
>> nscpEntryWsi: objectClass;vucsn-44fe0619000000010000: hgperson
>> nscpEntryWsi: objectClass;vucsn-44fe0619000000010000: inetOrgPerson
>> nscpEntryWsi: objectClass;vucsn-44fe0619000000010000:
>> organizationalPerson
>> nscpEntryWsi: objectClass;vucsn-44fe0619000000010000: person
>> nscpEntryWsi: objectClass;vucsn-44fe0619000000010000: top
>> nscpEntryWsi: givenName;vucsn-44fe0619000000010000: Some
>> nscpEntryWsi:
>> uid;vucsn-44fe0619000000010000;mdcsn-44fe0619000000010000: sempl
>> oyee
>> nscpEntryWsi: mail;vucsn-44fe0619000000010000: semployee at highergear.com
>> nscpEntryWsi: userPassword;vucsn-44fe0619000000010000:
>> {SSHA}<PASSWORD_ERASED>
>> nscpEntryWsi: creatorsName;vucsn-44fe0619000000010000: cn=manager
>> nscpEntryWsi: modifiersName;vucsn-44fe0619000000010000: cn=manager
>> nscpEntryWsi: createTimestamp;vucsn-44fe0619000000010000:
>> 20060905231943Z
>> nscpEntryWsi: modifyTimestamp;vucsn-44fe0619000000010000:
>> 20060905231943Z
>> nscpEntryWsi: nsUniqueId: fd033081-1dd111b2-80cef01a-e8560000
>> nscpEntryWsi: parentid: 11
>> nscpEntryWsi: entryid: 19719
>> nscpEntryWsi: entrydn: uid=semployee,ou=people,o=thgg,dc=hg,dc=com
>> nsUniqueID: fd033081-1dd111b2-80cef01a-e8560000
>> [root at ldap1 bin]#
>>
>>
>>
>>
>> Richard Megginson wrote:
>>> James B Newby wrote:
>>>> Yes, it is a read-only consumer, set up as per instructions in the
>>>> administration guide.
>>>> My multi-master replication scheme works fine. When chaining is
>>>> not set up, write operations to the read-only consumer fail. When
>>>> chaining is set up, writes can be made to the read-only consumer
>>>> but they do not propagate to the master.
>>> But the entry is successfully added and can be successfully
>>> searched. So it must exist on a master somewhere? Try this - do a
>>> search for the entry after adding it - in addition to the usual
>>> attributes, request the replication state information - ask for the
>>> attribute nscpEntryWsi, and also the nsUniqueID attribute. With
>>> this information, we can determine on which master (replica ID) the
>>> entry was added on and at what time.
>>>>
>>>> Are there any other queries I should make to the server in order to
>>>> give you more information?
>>>>
>>>> Richard Megginson wrote:
>>>>> 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
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> --
>>>>> 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/9e1c8dca/attachment.bin
