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