James B Newby wrote:
> Yes, it is a read-only consumer, set up as per instructions in the
> administration guide.
> My multi-master replication scheme works fine. When chaining is not
> set up, write operations to the read-only consumer fail. When
> chaining is set up, writes can be made to the read-only consumer but
> they do not propagate to the master.
But the entry is successfully added and can be successfully searched.
So it must exist on a master somewhere? Try this - do a search for the
entry after adding it - in addition to the usual attributes, request the
replication state information - ask for the attribute nscpEntryWsi, and
also the nsUniqueID attribute. With this information, we can determine
on which master (replica ID) the entry was added on and at what time.
>
> Are there any other queries I should make to the server in order to
> give you more information?
>
> Richard Megginson wrote:
>> James B Newby wrote:
>>> Yes. I can add or modify entries on the consumer with update
>>> chaining set up, but those changes do not propagate to the master.
>>> If I search on the master for the entry created on the consumer :
>>>
>>> [root at ldap1-mw1 bin]$ ./ldapsearch -b dc=hg,dc=com -D cn=Manager -w
>>> - -h localhost -p 1389 uid=nbody
>>> Enter bind password:
>>> [root at ldap1-mw1 bin]$
>>>
>>> It's not there. As I said in an earlier message, I've followed the
>>> instructions in the Chain on Update HOWTO, but I can't get it to
>>> work. I've reviewed the Administrator Guide as well as searching
>>> the Internet for an answer but no luck.
>> So, is this is a read only consumer? If so, you should not be able
>> to write to it. That's what is confusing me. If this is a read-only
>> consumer, you should get an err=10 back from a write operation if
>> chaining is not set up.
>>>
>>> Richard Megginson wrote:
>>>> James B Newby wrote:
>>>>> Well actually the entry was already there; I just made a small
>>>>> change to one of the attributes on the consumer through the
>>>>> directory console.
>>>>>
>>>>> I added a new entry on the consumer from the command line:
>>>>>
>>>>> [root at ldap1 bin]# ./ldapmodify -a -D cn=Manager -w - -h localhost
>>>>> -p 1389
>>>>> Enter bind password:
>>>>> dn: uid=nbody,ou=people,o=thgg,dc=hg,dc=com
>>>>> telephoneNumber: 800-555-5555
>>>>> userPassword: <erased>
>>>>> cn: No Body
>>>>> sn: Body
>>>>> objectClass: hgperson
>>>>> objectClass: inetorgperson
>>>>> objectClass: organizationalPerson
>>>>> objectClass: person
>>>>> objectClass: top
>>>>> givenName: No
>>>>> uid: nbody
>>>>> mail: nbody at highergear.com
>>>>> adding new entry uid=nbody,ou=people,o=thgg,dc=hg,dc=com
>>>>>
>>>>> [root at ldap1 bin]#
>>>>>
>>>>> Then I searched for that user on the consumer's command line:
>>>>> [root at ldap1 bin]# ./ldapsearch -b "dc=hg,dc=com" -D cn=Manager -w
>>>>> - -h localhost -p 1389 uid=nbody
>>>>> Enter bind password:
>>>>> version: 1
>>>>> dn: uid=nbody,ou=people,o=thgg,dc=hg,dc=com
>>>>> telephoneNumber: 800-555-5555
>>>>> cn: No Body
>>>>> sn: Body
>>>>> objectClass: hgperson
>>>>> objectClass: inetorgperson
>>>>> objectClass: organizationalPerson
>>>>> objectClass: person
>>>>> objectClass: top
>>>>> givenName: No
>>>>> uid: nbody
>>>>> mail: nbody at highergear.com
>>>>> userPassword: {SSHA}<erased>
>>>>> [root at ldap1 bin]#
>>>>>
>>>>> Here is what resulted in the access log of the consumer:
>>>>> [01/Sep/2006:18:18:12 -0500] conn=4 fd=66 slot=66 connection from
>>>>> 127.0.0.1 to 127.0.0.1
>>>>> [01/Sep/2006:18:18:12 -0500] conn=4 op=0 BIND dn="cn=Manager"
>>>>> method=128 version=3
>>>>> [01/Sep/2006:18:18:12 -0500] conn=4 op=0 RESULT err=0 tag=97
>>>>> nentries=0 etime=0 dn="cn=manager"
>>>>> [01/Sep/2006:18:18:18 -0500] conn=4 op=1 ADD
>>>>> dn="uid=nbody,ou=people,o=thgg,dc=hg,dc=com"
>>>>> [01/Sep/2006:18:18:18 -0500] conn=4 op=1 RESULT err=0 tag=105
>>>>> nentries=0 etime=0
>>>>> [01/Sep/2006:18:18:21 -0500] conn=4 op=3 UNBIND
>>>>> [01/Sep/2006:18:18:21 -0500] conn=4 op=3 fd=66 closed - U1
>>>>> [01/Sep/2006:18:18:47 -0500] conn=5 fd=66 slot=66 connection from
>>>>> 127.0.0.1 to 127.0.0.1
>>>>> [01/Sep/2006:18:18:47 -0500] conn=5 op=0 BIND dn="cn=Manager"
>>>>> method=128 version=3
>>>>> [01/Sep/2006:18:18:47 -0500] conn=5 op=0 RESULT err=0 tag=97
>>>>> nentries=0 etime=0 dn="cn=manager"
>>>>> [01/Sep/2006:18:18:47 -0500] conn=5 op=1 SRCH base="dc=hg,dc=com"
>>>>> scope=2 filter="(uid=nbody)" attrs=ALL
>>>>> [01/Sep/2006:18:18:47 -0500] conn=5 op=1 RESULT err=0 tag=101
>>>>> nentries=1 etime=0
>>>>> [01/Sep/2006:18:18:47 -0500] conn=5 op=2 UNBIND
>>>>> [01/Sep/2006:18:18:47 -0500] conn=5 op=2 fd=66 closed - U1
>>>> So it appears to be working?
>>>>>
>>>>> I then searched for that new entry in the Directory Console and
>>>>> the following log entries resulted:
>>>>> [01/Sep/2006:18:19:58 -0500] conn=0 op=28 SRCH
>>>>> base="ou=people,o=thgg,dc=hg,dc=com" scope=1
>>>>> filter="(|(objectClass=*)(objectClass=ldapsubentry))"
>>>>> attrs="objectClass numSubordinates ref aci"
>>>>> [01/Sep/2006:18:19:58 -0500] conn=0 op=28 SORT cn givenName o ou
>>>>> sn (196)
>>>>> [01/Sep/2006:18:19:58 -0500] conn=0 op=28 RESULT err=0 tag=101
>>>>> nentries=196 etime=0 notes=U
>>>>> [01/Sep/2006:18:20:04 -0500] conn=1 op=23 SRCH
>>>>> base="uid=nbody,ou=people,o=thgg,dc=hg,dc=com" scope=0
>>>>> filter="(|(objectClass=*)(objectClass=ldapsubentry))"
>>>>> attrs="nsRole nsRoleDN objectClass nsAccountLock"
>>>>> [01/Sep/2006:18:20:04 -0500] conn=1 op=23 RESULT err=0 tag=101
>>>>> nentries=1 etime=0
>>>>> [01/Sep/2006:18:20:04 -0500] conn=1 op=24 SRCH base="" scope=0
>>>>> filter="(objectClass=*)" attrs="nsslapd-suffix nsBackendSuffix"
>>>>> [01/Sep/2006:18:20:04 -0500] conn=1 op=24 RESULT err=0 tag=101
>>>>> nentries=1 etime=0
>>>>> [01/Sep/2006:18:20:04 -0500] conn=0 op=30 SRCH base="cn=ldbm
>>>>> database, cn=plugins, cn=config" scope=2
>>>>> filter="(objectClass=nsBackendInstance)" attrs="nsslapd-suffix
>>>>> nsBackendSuffix"
>>>>> [01/Sep/2006:18:20:04 -0500] conn=0 op=30 RESULT err=0 tag=101
>>>>> nentries=2 etime=0
>>>>> [01/Sep/2006:18:20:04 -0500] conn=0 op=31 SRCH base="" scope=0
>>>>> filter="(objectClass=*)" attrs="nsBackendSuffix"
>>>>> [01/Sep/2006:18:20:04 -0500] conn=0 op=31 RESULT err=0 tag=101
>>>>> nentries=1 etime=0
>>>>> [01/Sep/2006:18:20:04 -0500] conn=0 op=32 SRCH base="cn=MCC
>>>>> uid=nbody ou=people o=thgg dc=hg dc=com, cn=chainbe1, cn=ldbm
>>>>> database, cn=plugins, cn=config" scope=0
>>>>> filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs="dn"
>>>>> [01/Sep/2006:18:20:04 -0500] conn=0 op=32 RESULT err=32 tag=101
>>>>> nentries=0 etime=0
>>>>> [01/Sep/2006:18:20:05 -0500] conn=1 op=26 SRCH
>>>>> base="uid=nbody,ou=people,o=thgg,dc=hg,dc=com" scope=0
>>>>> filter="(|(objectClass=*)(objectClass=ldapsubentry))"
>>>>> attrs="numSubordinates nscpEntryDN subschemaSubentry
>>>>> nsYIMStatusGraphic modifiersName parentid nsICQStatusGraphic
>>>>> nsAIMStatusText passwordExpirationTime nsBackendSuffix
>>>>> hasSubordinates nsRole nsRoleDN accountUnlockTime
>>>>> passwordExpWarned nsYIMStatusText copiedFrom nsSizeLimit
>>>>> ldapSchemas nsAIMStatusGraphic dncomp nsTimeLimit passwordHistory
>>>>> retryCountResetTime passwordAllowChangeTime aci entryid
>>>>> nsIdleTimeout entrydn copyingFrom nsAccountLock nsds5ReplConflict
>>>>> modifyTimestamp passwordGraceUserTime passwordRetryCount
>>>>> nsUniqueId nsSchemaCSN creatorsName nsICQStatusText
>>>>> pwdpolicysubentry ldapSyntaxes createTimestamp nsLookThroughLimit *"
>>>>> [01/Sep/2006:18:20:05 -0500] conn=1 op=26 RESULT err=0 tag=101
>>>>> nentries=1 etime=0
>>>>> [01/Sep/2006:18:20:05 -0500] conn=1 op=27 SRCH
>>>>> base="uid=nbody,ou=people,o=thgg,dc=hg,dc=com" scope=0
>>>>> filter="(objectClass=*)" attrs="*"
>>>>> [01/Sep/2006:18:20:05 -0500] conn=1 op=27 RESULT err=0 tag=101
>>>>> nentries=1 etime=0
>>>>> [01/Sep/2006:18:20:05 -0500] conn=1 op=28 SRCH
>>>>> base="uid=nbody,ou=people,o=thgg,dc=hg,dc=com" scope=0
>>>>> filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
>>>> This appears to be working also?
>>>>>
>>>>> -James
>>>>>
>>>>> Richard Megginson wrote:
>>>>>> James B Newby wrote:
>>>>>>> I found the MOD line in the consumer's access log. I saw no
>>>>>>> entry in the master's access log regarding that entry. It seems
>>>>>>> as if the request doesn't make it to the master. I can telnet
>>>>>>> into the ldap port on the master from the consumer.
>>>>>>>
>>>>>>> I installed Fedora Directory Server from
>>>>>>> fedora-ds-1.0.2-1.FC4.i386.opt.rpm on all machines. All three
>>>>>>> machines are Intel/CentOS 4.3.
>>>>>>>
>>>>>>> -James
>>>>>>>
>>>>>>> In the consumer's access log:
>>>>>>> [01/Sep/2006:17:41:34 -0500] conn=1 op=8 SRCH
>>>>>>> base="uid=jhines,ou=people,o=thgg,dc=hg,dc=com" scope=0
>>>>>>> filter="(|(objectClass=*)(objectClass=ldapsubentry))"
>>>>>>> attrs="nsRole nsRoleDN objectClass nsAccountLock"
>>>>>>> [01/Sep/2006:17:41:34 -0500] conn=1 op=8 RESULT err=0 tag=101
>>>>>>> nentries=1 etime=0
>>>>>>> [01/Sep/2006:17:41:34 -0500] conn=1 op=9 SRCH base="" scope=0
>>>>>>> filter="(objectClass=*)" attrs="nsslapd-suffix nsBackendSuffix"
>>>>>>> [01/Sep/2006:17:41:34 -0500] conn=1 op=9 RESULT err=0 tag=101
>>>>>>> nentries=1 etime=0
>>>>>>> [01/Sep/2006:17:41:34 -0500] conn=0 op=14 SRCH base="cn=ldbm
>>>>>>> database, cn=plugins, cn=config" scope=2
>>>>>>> filter="(objectClass=nsBackendInstance)" attrs="nsslapd-suffix
>>>>>>> nsBackendSuffix"
>>>>>>> [01/Sep/2006:17:41:34 -0500] conn=0 op=14 RESULT err=0 tag=101
>>>>>>> nentries=2 etime=0
>>>>>>> [01/Sep/2006:17:41:34 -0500] conn=0 op=15 SRCH base="" scope=0
>>>>>>> filter="(objectClass=*)" attrs="nsBackendSuffix"
>>>>>>> [01/Sep/2006:17:41:34 -0500] conn=0 op=15 RESULT err=0 tag=101
>>>>>>> nentries=1 etime=0
>>>>>>> [01/Sep/2006:17:41:34 -0500] conn=0 op=16 SRCH base="cn=MCC
>>>>>>> uid=jhines ou=people o=thgg dc=hg dc=com, cn=chainbe1, cn=ldbm
>>>>>>> database, cn=plugins, cn=config" scope=0
>>>>>>> filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs="dn"
>>>>>>> [01/Sep/2006:17:41:34 -0500] conn=0 op=16 RESULT err=32 tag=101
>>>>>>> nentries=0 etime=0
>>>>>>> [01/Sep/2006:17:41:35 -0500] conn=1 op=10 SRCH
>>>>>>> base="uid=jhines,ou=people,o=thgg,dc=hg,dc=com" scope=0
>>>>>>> filter="(|(objectClass=*)(objectClass=ldapsubentry))"
>>>>>>> attrs="numSubordinates nscpEntryDN subschemaSubentry
>>>>>>> nsYIMStatusGraphic modifiersName parentid nsICQStatusGraphic
>>>>>>> nsAIMStatusText passwordExpirationTime nsBackendSuffix
>>>>>>> hasSubordinates nsRole nsRoleDN accountUnlockTime
>>>>>>> passwordExpWarned nsYIMStatusText copiedFrom nsSizeLimit
>>>>>>> ldapSchemas nsAIMStatusGraphic dncomp nsTimeLimit
>>>>>>> passwordHistory retryCountResetTime passwordAllowChangeTime aci
>>>>>>> entryid nsIdleTimeout entrydn copyingFrom nsAccountLock
>>>>>>> nsds5ReplConflict modifyTimestamp passwordGraceUserTime
>>>>>>> passwordRetryCount nsUniqueId nsSchemaCSN creatorsName
>>>>>>> nsICQStatusText pwdpolicysubentry ldapSyntaxes createTimestamp
>>>>>>> nsLookThroughLimit *"
>>>>>>> [01/Sep/2006:17:41:35 -0500] conn=1 op=10 RESULT err=0 tag=101
>>>>>>> nentries=1 etime=0
>>>>>>> [01/Sep/2006:17:41:35 -0500] conn=1 op=11 SRCH
>>>>>>> base="uid=jhines,ou=people,o=thgg,dc=hg,dc=com" scope=0
>>>>>>> filter="(objectClass=*)" attrs="*"
>>>>>>> [01/Sep/2006:17:41:35 -0500] conn=1 op=11 RESULT err=0 tag=101
>>>>>>> nentries=1 etime=0
>>>>>>> [01/Sep/2006:17:41:36 -0500] conn=1 op=12 SRCH
>>>>>>> base="uid=jhines,ou=people,o=thgg,dc=hg,dc=com" scope=0
>>>>>>> filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
>>>>>>> [01/Sep/2006:17:41:36 -0500] conn=1 op=12 RESULT err=0 tag=101
>>>>>>> nentries=1 etime=0
>>>>>>> [01/Sep/2006:17:41:41 -0500] conn=1 op=14 MOD
>>>>>>> dn="uid=jhines,ou=people,o=thgg,dc=hg,dc=com"
>>>>>>> [01/Sep/2006:17:41:41 -0500] conn=1 op=14 RESULT err=0 tag=103
>>>>>>> nentries=0 etime=0
>>>>>>> [01/Sep/2006:17:41:41 -0500] conn=0 op=18 SRCH
>>>>>>> base="uid=jhines,ou=people,o=thgg,dc=hg,dc=com" scope=0
>>>>>>> filter="(|(objectClass=*)(objectClass=ldapsubentry))"
>>>>>>> attrs="objectClass numSubordinates ref aci"
>>>>>>> [01/Sep/2006:17:41:41 -0500] conn=0 op=18 SORT cn givenName o ou
>>>>>>> sn (1)
>>>>>>> [01/Sep/2006:17:41:41 -0500] conn=0 op=18 RESULT err=0 tag=101
>>>>>>> nentries=1 etime=0 notes=U
>>>>>> Weird. It looks as though you added the entry to the local
>>>>>> server, and were able to search for it right away. e.g. you
>>>>>> search for uid=jhines, and the server replies with err=0 and
>>>>>> nentries=1. Can you try the same search from the ldapsearch
>>>>>> command line?
>>>>>>>
>>>>>>>
>>>>>>> Richard Megginson wrote:
>>>>>>>> James B Newby wrote:
>>>>>>>>> Hello all,
>>>>>>>>>
>>>>>>>>> I'm having a problem with my consumer's chain on update. I
>>>>>>>>> have a setup with two masters and one consumer. Multi-master
>>>>>>>>> replication is working properly. Changes made on either
>>>>>>>>> master propagate to the other master and to the consumer.
>>>>>>>>>
>>>>>>>>> Before setting up chaining, changes made on the consumer from
>>>>>>>>> the directory console would be denied. After setting up
>>>>>>>>> chaining per the wiki entry:
>>>>>>>>> http://directory.fedora.redhat.com/wiki/Howto:ChainOnUpdate ,
>>>>>>>>> changes could be made on the consumer through the directory
>>>>>>>>> console, but would not propagate to the master.
>>>>>>>> How are you testing/verifying the change doesn't get through?
>>>>>>>> Note that if you make the change in the console, the console
>>>>>>>> will not automatically refresh. I would first check the access
>>>>>>>> log on the consumer to find the ADD or MOD request, then see if
>>>>>>>> that request made it to a master, then see if the master
>>>>>>>> rejected it and why.
>>>>>>>>>
>>>>>>>>> I saw an e-mail with a similar problem in the December 2005
>>>>>>>>> archive, but didn't see any info in the replies that would
>>>>>>>>> help me. I've tried setting this up from scratch a couple
>>>>>>>>> times, but without success. The responses to ILoveJython's
>>>>>>>>> email in December suggested that certain entries be pasted in,
>>>>>>>>> so I've included them below.
>>>>>>>>>
>>>>>>>>> The following acl is included in dc=hg,dc=com:
>>>>>>>>> (targetattr = "*")(version 3.0; acl "Proxied authorization for
>>>>>>>>> database links";allow (proxy) (userdn =
>>>>>>>>> "ldap:///cn=Replication Manager, cn=config");)
>>>>>>>>> Since multi-master replication is set up, this entry is
>>>>>>>>> present on all three servers.
>>>>>>>>>
>>>>>>>>> Any help would be appreciated! Thanks!
>>>>>>>>>
>>>>>>>>> -James
>>>>>>>>>
>>>>>>>>> dn: cn="dc=hg,dc=com",cn=mapping tree, cn=config
>>>>>>>>> objectClass: top
>>>>>>>>> objectClass: extensibleObject
>>>>>>>>> objectClass: nsMappingTree
>>>>>>>>> nsslapd-state: backend
>>>>>>>>> cn: "dc=hg,dc=com"
>>>>>>>>> cn: dc=hg,dc=com
>>>>>>>>> nsslapd-backend: userRoot
>>>>>>>>> nsslapd-backend: chainbe1
>>>>>>>>> nsslapd-referral:
>>>>>>>>> ldap://ldap1.mw1.highergear.com:1389/dc=hg,dc=com
>>>>>>>>> nsslapd-referral:
>>>>>>>>> ldap://ldap2.mw1.highergear.com:1389/dc=hg,dc=com
>>>>>>>>> nsslapd-distribution-plugin:
>>>>>>>>> /opt/fedora-ds/lib/replication-plugin.so
>>>>>>>>> nsslapd-distribution-funct: repl_chain_on_update
>>>>>>>>>
>>>>>>>>> dn: cn=replica,cn="dc=hg,dc=com",cn=mapping tree, cn=config
>>>>>>>>> objectClass: nsDS5Replica
>>>>>>>>> objectClass: top
>>>>>>>>> nsDS5ReplicaRoot: dc=hg,dc=com
>>>>>>>>> nsDS5ReplicaType: 2
>>>>>>>>> nsDS5Flags: 0
>>>>>>>>> nsds5ReplicaPurgeDelay: 604800
>>>>>>>>> nsDS5ReplicaBindDN: cn=Replication Manager,cn=config
>>>>>>>>> cn: replica
>>>>>>>>> nsDS5ReplicaId: 65535
>>>>>>>>> nsState:: //8AAIcx9kQAAAAAAAAAAAEAAAA=
>>>>>>>>> nsDS5ReplicaName: ddc65803-1dd111b2-80e6a7e3-5afe0000
>>>>>>>>> nsDS5ReplicaReferral:
>>>>>>>>> ldap://ldap1.mw1.highergear.com:1389/dc=hg,dc=com
>>>>>>>>> nsDS5ReplicaReferral:
>>>>>>>>> ldap://ldap2.mw1.highergear.com:1389/dc=hg,dc=com
>>>>>>>>> nsds5ReplicaChangeCount: 0
>>>>>>>>> nsds5replicareapactive: 0
>>>>>>>>>
>>>>>>>>> dn: cn=config,cn=chaining database,cn=plugins,cn=config
>>>>>>>>> cn: config
>>>>>>>>> objectClass: top
>>>>>>>>> objectClass: extensibleObject
>>>>>>>>> nstransmittedcontrols: 2.16.840.1.113730.3.4.2
>>>>>>>>> nstransmittedcontrols: 2.16.840.1.113730.3.4.9
>>>>>>>>> nstransmittedcontrols: 1.2.840.113556.1.4.473
>>>>>>>>> nstransmittedcontrols: 1.3.6.1.4.1.1466.29539.12
>>>>>>>>> nspossiblechainingcomponents: cn=resource
>>>>>>>>> limits,cn=components,cn=config
>>>>>>>>> nspossiblechainingcomponents: cn=certificate-based
>>>>>>>>> authentication,cn=component
>>>>>>>>> s,cn=config
>>>>>>>>> nspossiblechainingcomponents: cn=ACL Plugin,cn=plugins,cn=config
>>>>>>>>> nspossiblechainingcomponents: cn=old plugin,cn=plugins,cn=config
>>>>>>>>> nspossiblechainingcomponents: cn=referential integrity
>>>>>>>>> postoperation,cn=plugin
>>>>>>>>> s,cn=config
>>>>>>>>> nspossiblechainingcomponents: cn=attribute
>>>>>>>>> uniqueness,cn=plugins,cn=config
>>>>>>>>> dn: cn=chainbe1, cn=chaining database, cn=plugins, cn=config
>>>>>>>>> objectClass: top
>>>>>>>>> objectClass: extensibleObject
>>>>>>>>> objectClass: nsBackendInstance
>>>>>>>>> cn: chainbe1
>>>>>>>>> nsslapd-suffix: dc=hg,dc=com
>>>>>>>>> nsfarmserverurl: ldap://ldap1.mw1.highergear.com:1389
>>>>>>>>> ldap2.mw1.highergear.com
>>>>>>>>> :1389/
>>>>>>>>> nsmultiplexorbinddn: cn=Replication Manager, cn=config
>>>>>>>>> nsmultiplexorcredentials: {DES}<PASSWORD ERASED>
>>>>>>>>> nsbindconnectionslimit: 3
>>>>>>>>> nsoperationconnectionslimit: 20
>>>>>>>>> nsabandonedsearchcheckinterval: 1
>>>>>>>>> nsconcurrentbindlimit: 10
>>>>>>>>> nsconcurrentoperationslimit: 2
>>>>>>>>> nsproxiedauthorization: on
>>>>>>>>> nsconnectionlife: 0
>>>>>>>>> nsbindtimeout: 15
>>>>>>>>> nsreferralonscopedsearch: off
>>>>>>>>> nschecklocalaci: on
>>>>>>>>> nsbindretrylimit: 3
>>>>>>>>> nsslapd-sizelimit: 2000
>>>>>>>>> nsslapd-timelimit: 3600
>>>>>>>>> nshoplimit: 10
>>>>>>>>> nsmaxresponsedelay: 60
>>>>>>>>> nsmaxtestresponsedelay: 15
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Fedora-directory-users mailing list
>>>>>>>>> Fedora-directory-users at redhat.com
>>>>>>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Fedora-directory-users mailing list
>>>>>>>> Fedora-directory-users at redhat.com
>>>>>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Fedora-directory-users mailing list
>>>>>>> Fedora-directory-users at redhat.com
>>>>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Fedora-directory-users mailing list
>>>>>> Fedora-directory-users at redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>>>
>>>>>
>>>>> --
>>>>> Fedora-directory-users mailing list
>>>>> Fedora-directory-users at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> --
>>>> Fedora-directory-users mailing list
>>>> Fedora-directory-users at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>
>>>
>>> --
>>> Fedora-directory-users mailing list
>>> Fedora-directory-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>> ------------------------------------------------------------------------
>>
>> --
>> Fedora-directory-users mailing list
>> Fedora-directory-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3178 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20060905/5ae126dc/attachment.bin
