thr3ads.net - Fedora directory users - [Fedora-directory-users] Chain on Update Problem [Sep 2006]

If this information is useful, please help other people find it:
Share via:

James B Newby

2006-Sep-01 21:01 UTC

[Fedora-directory-users] Chain on Update Problem

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.

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:: //8AAIcx9kQAAAAAAAAAAAEAAAAnsDS5ReplicaName:
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

Richard Megginson

2006-Sep-01 21:39 UTC

head link

Re: [Fedora-directory-users] Chain on Update Problem

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@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

James B Newby

2006-Sep-01 22:54 UTC

head link

Re: [Fedora-directory-users] Chain on Update Problem

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


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@redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> ------------------------------------------------------------------------
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

Richard Megginson

2006-Sep-01 23:01 UTC

head link

Re: [Fedora-directory-users] Chain on Update Problem

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=UWeird.  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@redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>
------------------------------------------------------------------------
>>
>> -- 
>> Fedora-directory-users mailing list
>> Fedora-directory-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>   
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

James B Newby

2006-Sep-01 23:24 UTC

head link

Re: [Fedora-directory-users] Chain on Update Problem

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@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@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

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

-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@redhat.com
>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>
------------------------------------------------------------------------
>>>
>>>
>>> -- 
>>> Fedora-directory-users mailing list
>>> Fedora-directory-users@redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>   
>>
>> -- 
>> Fedora-directory-users mailing list
>> Fedora-directory-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> ------------------------------------------------------------------------
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

Richard Megginson

2006-Sep-02 03:24 UTC

head link

Re: [Fedora-directory-users] Chain on Update Problem

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@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@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@redhat.com
>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>
------------------------------------------------------------------------
>>>>
>>>>
>>>> -- 
>>>> Fedora-directory-users mailing list
>>>> Fedora-directory-users@redhat.com
>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>   
>>>
>>> -- 
>>> Fedora-directory-users mailing list
>>> Fedora-directory-users@redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>
------------------------------------------------------------------------
>>
>> -- 
>> Fedora-directory-users mailing list
>> Fedora-directory-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>   
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

James B Newby

2006-Sep-03 20:46 UTC

head link

Re: [Fedora-directory-users] Chain on Update Problem

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.

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@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@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@redhat.com
>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>
------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> -- 
>>>>> Fedora-directory-users mailing list
>>>>> Fedora-directory-users@redhat.com
>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>   
>>>>
>>>> -- 
>>>> Fedora-directory-users mailing list
>>>> Fedora-directory-users@redhat.com
>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>
------------------------------------------------------------------------
>>>
>>>
>>> -- 
>>> Fedora-directory-users mailing list
>>> Fedora-directory-users@redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>   
>>
>> -- 
>> Fedora-directory-users mailing list
>> Fedora-directory-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> ------------------------------------------------------------------------
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

Richard Megginson

2006-Sep-05 14:53 UTC

head link

Re: [Fedora-directory-users] Chain on Update Problem

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@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@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@redhat.com
>>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>
------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Fedora-directory-users mailing list
>>>>>> Fedora-directory-users@redhat.com
>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>   
>>>>>
>>>>> -- 
>>>>> Fedora-directory-users mailing list
>>>>> Fedora-directory-users@redhat.com
>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>
------------------------------------------------------------------------
>>>>
>>>>
>>>> -- 
>>>> Fedora-directory-users mailing list
>>>> Fedora-directory-users@redhat.com
>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>   
>>>
>>> -- 
>>> Fedora-directory-users mailing list
>>> Fedora-directory-users@redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>
------------------------------------------------------------------------
>>
>> -- 
>> Fedora-directory-users mailing list
>> Fedora-directory-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>   
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

James B Newby

2006-Sep-05 15:41 UTC

head link

Re: [Fedora-directory-users] Chain on Update Problem

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.

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@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@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@redhat.com
>>>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>>
------------------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>> -- 
>>>>>>> Fedora-directory-users mailing list
>>>>>>> Fedora-directory-users@redhat.com
>>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>>   
>>>>>>
>>>>>> -- 
>>>>>> Fedora-directory-users mailing list
>>>>>> Fedora-directory-users@redhat.com
>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>
------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> -- 
>>>>> Fedora-directory-users mailing list
>>>>> Fedora-directory-users@redhat.com
>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>   
>>>>
>>>> -- 
>>>> Fedora-directory-users mailing list
>>>> Fedora-directory-users@redhat.com
>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>
------------------------------------------------------------------------
>>>
>>>
>>> -- 
>>> Fedora-directory-users mailing list
>>> Fedora-directory-users@redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>   
>>
>> -- 
>> Fedora-directory-users mailing list
>> Fedora-directory-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> ------------------------------------------------------------------------
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

Richard Megginson

2006-Sep-05 16:21 UTC

head link

Re: [Fedora-directory-users] Chain on Update Problem

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@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@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@redhat.com
>>>>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>>>
------------------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Fedora-directory-users mailing list
>>>>>>>> Fedora-directory-users@redhat.com
>>>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>>>   
>>>>>>>
>>>>>>> -- 
>>>>>>> Fedora-directory-users mailing list
>>>>>>> Fedora-directory-users@redhat.com
>>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>
------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Fedora-directory-users mailing list
>>>>>> Fedora-directory-users@redhat.com
>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>   
>>>>>
>>>>> -- 
>>>>> Fedora-directory-users mailing list
>>>>> Fedora-directory-users@redhat.com
>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>
------------------------------------------------------------------------
>>>>
>>>>
>>>> -- 
>>>> Fedora-directory-users mailing list
>>>> Fedora-directory-users@redhat.com
>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>   
>>>
>>> -- 
>>> Fedora-directory-users mailing list
>>> Fedora-directory-users@redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>
------------------------------------------------------------------------
>>
>> -- 
>> Fedora-directory-users mailing list
>> Fedora-directory-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>   
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

James B Newby

2006-Sep-05 23:34 UTC

head link

Re: [Fedora-directory-users] Chain on Update Problem

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@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@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
[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@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@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@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@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@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@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@redhat.com
>>>>>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>>>>
------------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> Fedora-directory-users mailing list
>>>>>>>>> Fedora-directory-users@redhat.com
>>>>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>>>>   
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Fedora-directory-users mailing list
>>>>>>>> Fedora-directory-users@redhat.com
>>>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>>
------------------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>> -- 
>>>>>>> Fedora-directory-users mailing list
>>>>>>> Fedora-directory-users@redhat.com
>>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>>   
>>>>>>
>>>>>> -- 
>>>>>> Fedora-directory-users mailing list
>>>>>> Fedora-directory-users@redhat.com
>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>
------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> -- 
>>>>> Fedora-directory-users mailing list
>>>>> Fedora-directory-users@redhat.com
>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>   
>>>>
>>>> -- 
>>>> Fedora-directory-users mailing list
>>>> Fedora-directory-users@redhat.com
>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>
------------------------------------------------------------------------
>>>
>>>
>>> -- 
>>> Fedora-directory-users mailing list
>>> Fedora-directory-users@redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>   
>>
>> -- 
>> Fedora-directory-users mailing list
>> Fedora-directory-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> ------------------------------------------------------------------------
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

Nathan Kinder

2006-Sep-05 23:42 UTC

head link

Re: [Fedora-directory-users] Chain on Update Problem

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.

-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@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@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
> [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@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@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@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@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@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@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@redhat.com
>>>>>>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>>>>>
------------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>>> Fedora-directory-users mailing list
>>>>>>>>>> Fedora-directory-users@redhat.com
>>>>>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>>>>>   
>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> Fedora-directory-users mailing list
>>>>>>>>> Fedora-directory-users@redhat.com
>>>>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>>>
------------------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Fedora-directory-users mailing list
>>>>>>>> Fedora-directory-users@redhat.com
>>>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>>>   
>>>>>>>
>>>>>>> -- 
>>>>>>> Fedora-directory-users mailing list
>>>>>>> Fedora-directory-users@redhat.com
>>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>
------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Fedora-directory-users mailing list
>>>>>> Fedora-directory-users@redhat.com
>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>   
>>>>>
>>>>> -- 
>>>>> Fedora-directory-users mailing list
>>>>> Fedora-directory-users@redhat.com
>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>
------------------------------------------------------------------------
>>>>
>>>>
>>>> -- 
>>>> Fedora-directory-users mailing list
>>>> Fedora-directory-users@redhat.com
>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>   
>>>
>>> -- 
>>> Fedora-directory-users mailing list
>>> Fedora-directory-users@redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>
------------------------------------------------------------------------
>>
>> -- 
>> Fedora-directory-users mailing list
>> Fedora-directory-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>   
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

Richard Megginson

2006-Sep-06 00:26 UTC

head link

Re: [Fedora-directory-users] Chain on Update Problem

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@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@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@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-5afe0000So 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@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@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@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@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@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@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@redhat.com
>>>>>>>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>>>>>>
------------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -- 
>>>>>>>>>>> Fedora-directory-users mailing list
>>>>>>>>>>> Fedora-directory-users@redhat.com
>>>>>>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>>>>>>   
>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>>> Fedora-directory-users mailing list
>>>>>>>>>> Fedora-directory-users@redhat.com
>>>>>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>>>>
------------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> Fedora-directory-users mailing list
>>>>>>>>> Fedora-directory-users@redhat.com
>>>>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>>>>   
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Fedora-directory-users mailing list
>>>>>>>> Fedora-directory-users@redhat.com
>>>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>>
------------------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>> -- 
>>>>>>> Fedora-directory-users mailing list
>>>>>>> Fedora-directory-users@redhat.com
>>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>>   
>>>>>>
>>>>>> -- 
>>>>>> Fedora-directory-users mailing list
>>>>>> Fedora-directory-users@redhat.com
>>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>
------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> -- 
>>>>> Fedora-directory-users mailing list
>>>>> Fedora-directory-users@redhat.com
>>>>>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>   
>>>>
>>>> -- 
>>>> Fedora-directory-users mailing list
>>>> Fedora-directory-users@redhat.com
>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>
------------------------------------------------------------------------
>>>
>>>
>>> -- 
>>> Fedora-directory-users mailing list
>>> Fedora-directory-users@redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>   
>>
>> -- 
>> Fedora-directory-users mailing list
>> Fedora-directory-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
> ------------------------------------------------------------------------
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

Fedora directory users - Sep 2006 - Chain on Update Problem

[Fedora-directory-users] Chain on Update Problem

Re: [Fedora-directory-users] Chain on Update Problem

Re: [Fedora-directory-users] Chain on Update Problem

Re: [Fedora-directory-users] Chain on Update Problem

Re: [Fedora-directory-users] Chain on Update Problem

Re: [Fedora-directory-users] Chain on Update Problem

Re: [Fedora-directory-users] Chain on Update Problem

Re: [Fedora-directory-users] Chain on Update Problem

Re: [Fedora-directory-users] Chain on Update Problem

Re: [Fedora-directory-users] Chain on Update Problem

Re: [Fedora-directory-users] Chain on Update Problem

Re: [Fedora-directory-users] Chain on Update Problem

Re: [Fedora-directory-users] Chain on Update Problem