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