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@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(a)highergear.com
> uid: sbody
> adding new entry uid=sbody,ou=people,o=thgg,dc=hg,dc=com
>
> [root@ldap1 bin]#
>
> Searching for entry on consumer:
>
> [root@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(a)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@ldap1 bin]#
>
> Search for entry on Master 1:
>
> [root@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@ldap1-mw1 bin]#
>
> Search for entry on Master 2:
>
> [root@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@ldap2-mw1 bin]#
>
> -------------------------------------------------------
>
> Example 2:
>
> Create an entry on Master 1:
>
> [root@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(a)highergear.com
>
> adding new entry uid=semployee,ou=people,o=thgg,dc=hg,dc=com
>
> [root@ldap1-mw1 bin]#
>
> Search for entry on Master 1:
> [root@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(a)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@ldap1-mw1 bin]#
>
> Search for Entry on Master 2:
> [root@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(a)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@ldap2-mw1 bin]#
>
> Search for entry on consumer:
> [root@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(a)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@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@ldap1-mw1 bin]$ ./ldapsearch -b dc=hg,dc=com -D cn=Manager
>>>>> -w - -h localhost -p 1389 uid=nbody
>>>>> Enter bind password:
>>>>> [root@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@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(a)highergear.com
>>>>>>> adding new entry uid=nbody,ou=people,o=thgg,dc=hg,dc=com
>>>>>>>
>>>>>>> [root@ldap1 bin]#
>>>>>>>
>>>>>>> Then I searched for that user on the consumer's command
line:
>>>>>>> [root@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(a)highergear.com
>>>>>>> userPassword: {SSHA}<erased>
>>>>>>> [root@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(a)redhat.com
>>>>>>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>>>>>
------------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Fedora-directory-users mailing list
>>>>>>>>>> Fedora-directory-users(a)redhat.com
>>>>>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Fedora-directory-users mailing list
>>>>>>>>> Fedora-directory-users(a)redhat.com
>>>>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>>>
------------------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Fedora-directory-users mailing list
>>>>>>>> Fedora-directory-users(a)redhat.com
>>>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Fedora-directory-users mailing list
>>>>>>> Fedora-directory-users(a)redhat.com
>>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>
------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Fedora-directory-users mailing list
>>>>>> Fedora-directory-users(a)redhat.com
>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>
>>>>>
>>>>> --
>>>>> Fedora-directory-users mailing list
>>>>> Fedora-directory-users(a)redhat.com
>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> --
>>>> Fedora-directory-users mailing list
>>>> Fedora-directory-users(a)redhat.com
>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>
>>>
>>> --
>>> Fedora-directory-users mailing list
>>> Fedora-directory-users(a)redhat.com
>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>> ------------------------------------------------------------------------
>>
>>
>> --
>> Fedora-directory-users mailing list
>> Fedora-directory-users(a)redhat.com
>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users(a)redhat.com
>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
------------------------------------------------------------------------
--
Fedora-directory-users mailing list
Fedora-directory-users(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-users