James B Newby wrote: > I found the MOD line in the consumer's access log. I saw no entry in > the master's access log regarding that entry. It seems as if the > request doesn't make it to the master. I can telnet into the ldap > port on the master from the consumer. > > I installed Fedora Directory Server from > fedora-ds-1.0.2-1.FC4.i386.opt.rpm on all machines. All three > machines are Intel/CentOS 4.3. > > -James > > In the consumer's access log: > [01/Sep/2006:17:41:34 -0500] conn=1 op=8 SRCH > base="uid=jhines,ou=people,o=thgg,dc=hg,dc=com" scope=0 > filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs="nsRole > nsRoleDN objectClass nsAccountLock" > [01/Sep/2006:17:41:34 -0500] conn=1 op=8 RESULT err=0 tag=101 > nentries=1 etime=0 > [01/Sep/2006:17:41:34 -0500] conn=1 op=9 SRCH base="" scope=0 > filter="(objectClass=*)" attrs="nsslapd-suffix nsBackendSuffix" > [01/Sep/2006:17:41:34 -0500] conn=1 op=9 RESULT err=0 tag=101 > nentries=1 etime=0 > [01/Sep/2006:17:41:34 -0500] conn=0 op=14 SRCH base="cn=ldbm database, > cn=plugins, cn=config" scope=2 > filter="(objectClass=nsBackendInstance)" attrs="nsslapd-suffix > nsBackendSuffix" > [01/Sep/2006:17:41:34 -0500] conn=0 op=14 RESULT err=0 tag=101 > nentries=2 etime=0 > [01/Sep/2006:17:41:34 -0500] conn=0 op=15 SRCH base="" scope=0 > filter="(objectClass=*)" attrs="nsBackendSuffix" > [01/Sep/2006:17:41:34 -0500] conn=0 op=15 RESULT err=0 tag=101 > nentries=1 etime=0 > [01/Sep/2006:17:41:34 -0500] conn=0 op=16 SRCH base="cn=MCC uid=jhines > ou=people o=thgg dc=hg dc=com, cn=chainbe1, cn=ldbm database, > cn=plugins, cn=config" scope=0 > filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs="dn" > [01/Sep/2006:17:41:34 -0500] conn=0 op=16 RESULT err=32 tag=101 > nentries=0 etime=0 > [01/Sep/2006:17:41:35 -0500] conn=1 op=10 SRCH > base="uid=jhines,ou=people,o=thgg,dc=hg,dc=com" scope=0 > filter="(|(objectClass=*)(objectClass=ldapsubentry))" > attrs="numSubordinates nscpEntryDN subschemaSubentry > nsYIMStatusGraphic modifiersName parentid nsICQStatusGraphic > nsAIMStatusText passwordExpirationTime nsBackendSuffix hasSubordinates > nsRole nsRoleDN accountUnlockTime passwordExpWarned nsYIMStatusText > copiedFrom nsSizeLimit ldapSchemas nsAIMStatusGraphic dncomp > nsTimeLimit passwordHistory retryCountResetTime > passwordAllowChangeTime aci entryid nsIdleTimeout entrydn copyingFrom > nsAccountLock nsds5ReplConflict modifyTimestamp passwordGraceUserTime > passwordRetryCount nsUniqueId nsSchemaCSN creatorsName nsICQStatusText > pwdpolicysubentry ldapSyntaxes createTimestamp nsLookThroughLimit *" > [01/Sep/2006:17:41:35 -0500] conn=1 op=10 RESULT err=0 tag=101 > nentries=1 etime=0 > [01/Sep/2006:17:41:35 -0500] conn=1 op=11 SRCH > base="uid=jhines,ou=people,o=thgg,dc=hg,dc=com" scope=0 > filter="(objectClass=*)" attrs="*" > [01/Sep/2006:17:41:35 -0500] conn=1 op=11 RESULT err=0 tag=101 > nentries=1 etime=0 > [01/Sep/2006:17:41:36 -0500] conn=1 op=12 SRCH > base="uid=jhines,ou=people,o=thgg,dc=hg,dc=com" scope=0 > filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL > [01/Sep/2006:17:41:36 -0500] conn=1 op=12 RESULT err=0 tag=101 > nentries=1 etime=0 > [01/Sep/2006:17:41:41 -0500] conn=1 op=14 MOD > dn="uid=jhines,ou=people,o=thgg,dc=hg,dc=com" > [01/Sep/2006:17:41:41 -0500] conn=1 op=14 RESULT err=0 tag=103 > nentries=0 etime=0 > [01/Sep/2006:17:41:41 -0500] conn=0 op=18 SRCH > base="uid=jhines,ou=people,o=thgg,dc=hg,dc=com" scope=0 > filter="(|(objectClass=*)(objectClass=ldapsubentry))" > attrs="objectClass numSubordinates ref aci" > [01/Sep/2006:17:41:41 -0500] conn=0 op=18 SORT cn givenName o ou sn (1) > [01/Sep/2006:17:41:41 -0500] conn=0 op=18 RESULT err=0 tag=101 > nentries=1 etime=0 notes=U Weird. It looks as though you added the entry to the local server, and were able to search for it right away. e.g. you search for uid=jhines, and the server replies with err=0 and nentries=1. Can you try the same search from the ldapsearch command line? > > > Richard Megginson wrote: >> James B Newby wrote: >>> Hello all, >>> >>> I'm having a problem with my consumer's chain on update. I have a >>> setup with two masters and one consumer. Multi-master replication >>> is working properly. Changes made on either master propagate to the >>> other master and to the consumer. >>> >>> Before setting up chaining, changes made on the consumer from the >>> directory console would be denied. After setting up chaining per >>> the wiki entry: >>> http://directory.fedora.redhat.com/wiki/Howto:ChainOnUpdate , >>> changes could be made on the consumer through the directory console, >>> but would not propagate to the master. >> How are you testing/verifying the change doesn't get through? Note >> that if you make the change in the console, the console will not >> automatically refresh. I would first check the access log on the >> consumer to find the ADD or MOD request, then see if that request >> made it to a master, then see if the master rejected it and why. >>> >>> I saw an e-mail with a similar problem in the December 2005 archive, >>> but didn't see any info in the replies that would help me. I've >>> tried setting this up from scratch a couple times, but without >>> success. The responses to ILoveJython's email in December suggested >>> that certain entries be pasted in, so I've included them below. >>> >>> The following acl is included in dc=hg,dc=com: >>> (targetattr = "*")(version 3.0; acl "Proxied authorization for >>> database links";allow (proxy) (userdn = "ldap:///cn=Replication >>> Manager, cn=config");) >>> Since multi-master replication is set up, this entry is present on >>> all three servers. >>> >>> Any help would be appreciated! Thanks! >>> >>> -James >>> >>> dn: cn="dc=hg,dc=com",cn=mapping tree, cn=config >>> objectClass: top >>> objectClass: extensibleObject >>> objectClass: nsMappingTree >>> nsslapd-state: backend >>> cn: "dc=hg,dc=com" >>> cn: dc=hg,dc=com >>> nsslapd-backend: userRoot >>> nsslapd-backend: chainbe1 >>> nsslapd-referral: ldap://ldap1.mw1.highergear.com:1389/dc=hg,dc=com >>> nsslapd-referral: ldap://ldap2.mw1.highergear.com:1389/dc=hg,dc=com >>> nsslapd-distribution-plugin: /opt/fedora-ds/lib/replication-plugin.so >>> nsslapd-distribution-funct: repl_chain_on_update >>> >>> dn: cn=replica,cn="dc=hg,dc=com",cn=mapping tree, cn=config >>> objectClass: nsDS5Replica >>> objectClass: top >>> nsDS5ReplicaRoot: dc=hg,dc=com >>> nsDS5ReplicaType: 2 >>> nsDS5Flags: 0 >>> nsds5ReplicaPurgeDelay: 604800 >>> nsDS5ReplicaBindDN: cn=Replication Manager,cn=config >>> cn: replica >>> nsDS5ReplicaId: 65535 >>> nsState:: //8AAIcx9kQAAAAAAAAAAAEAAAA= >>> nsDS5ReplicaName: ddc65803-1dd111b2-80e6a7e3-5afe0000 >>> nsDS5ReplicaReferral: ldap://ldap1.mw1.highergear.com:1389/dc=hg,dc=com >>> nsDS5ReplicaReferral: ldap://ldap2.mw1.highergear.com:1389/dc=hg,dc=com >>> nsds5ReplicaChangeCount: 0 >>> nsds5replicareapactive: 0 >>> >>> dn: cn=config,cn=chaining database,cn=plugins,cn=config >>> cn: config >>> objectClass: top >>> objectClass: extensibleObject >>> nstransmittedcontrols: 2.16.840.1.113730.3.4.2 >>> nstransmittedcontrols: 2.16.840.1.113730.3.4.9 >>> nstransmittedcontrols: 1.2.840.113556.1.4.473 >>> nstransmittedcontrols: 1.3.6.1.4.1.1466.29539.12 >>> nspossiblechainingcomponents: cn=resource >>> limits,cn=components,cn=config >>> nspossiblechainingcomponents: cn=certificate-based >>> authentication,cn=component >>> s,cn=config >>> nspossiblechainingcomponents: cn=ACL Plugin,cn=plugins,cn=config >>> nspossiblechainingcomponents: cn=old plugin,cn=plugins,cn=config >>> nspossiblechainingcomponents: cn=referential integrity >>> postoperation,cn=plugin >>> s,cn=config >>> nspossiblechainingcomponents: cn=attribute >>> uniqueness,cn=plugins,cn=config >>> dn: cn=chainbe1, cn=chaining database, cn=plugins, cn=config >>> objectClass: top >>> objectClass: extensibleObject >>> objectClass: nsBackendInstance >>> cn: chainbe1 >>> nsslapd-suffix: dc=hg,dc=com >>> nsfarmserverurl: ldap://ldap1.mw1.highergear.com:1389 >>> ldap2.mw1.highergear.com >>> :1389/ >>> nsmultiplexorbinddn: cn=Replication Manager, cn=config >>> nsmultiplexorcredentials: {DES}<PASSWORD ERASED> >>> nsbindconnectionslimit: 3 >>> nsoperationconnectionslimit: 20 >>> nsabandonedsearchcheckinterval: 1 >>> nsconcurrentbindlimit: 10 >>> nsconcurrentoperationslimit: 2 >>> nsproxiedauthorization: on >>> nsconnectionlife: 0 >>> nsbindtimeout: 15 >>> nsreferralonscopedsearch: off >>> nschecklocalaci: on >>> nsbindretrylimit: 3 >>> nsslapd-sizelimit: 2000 >>> nsslapd-timelimit: 3600 >>> nshoplimit: 10 >>> nsmaxresponsedelay: 60 >>> nsmaxtestresponsedelay: 15 >>> >>> -- >>> Fedora-directory-users mailing list >>> Fedora-directory-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> ------------------------------------------------------------------------ >> >> -- >> Fedora-directory-users mailing list >> Fedora-directory-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20060901/f16997dc/attachment.bin
