Rich thank you for your clarification and continued responses.
I have continued to read documentation and try different things to get
this replication working between my two multi-master's (A and B) and
the two consumers (C and D). System A is the only system that is
current and reading/writing information. I am attempting to get
replication working from the master A to consumer C as a first step.
I am still receiving the same permission denied (using simple
authentication) error as before (replacing private info):
[10/Apr/2012:11:51:20 -0700] NSMMReplicationPlugin -
agmt="cn=<my_suffix>_to_ConsumerC" (<consumerC>:389): Unable to
acquire replica: permission denied. The bind dn
"cn=replication,cn=config" does not have permission to supply
replication updates to the replica. Will retry later.
This occurs when I run an "initialize consumer" from the directory
server console (and per the server's automated attempts).
I've been resetting passwords, recreating replication agreements, and
confirming the correct setup from the consoles on both master A and
consumer C. I'm not editing the dse.ldif file directly. Here are the
configurations per the dse.ldif files:
Master A:
dn: cn=config
cn: config
objectClass: top
objectClass: extensibleObject
objectClass: nsslapdConfig
nsslapd-accesslog-logging-enabled: on
nsslapd-accesslog-maxlogsperdir: 10
nsslapd-accesslog-mode: 600
nsslapd-accesslog-maxlogsize: 100
nsslapd-accesslog-logrotationtime: 1
nsslapd-accesslog-logrotationtimeunit: day
nsslapd-accesslog-logrotationsync-enabled: off
nsslapd-accesslog-logrotationsynchour: 0
nsslapd-accesslog-logrotationsyncmin: 0
nsslapd-accesslog: /opt/fedora-ds/slapd-<masterA>/logs/access
nsslapd-enquote-sup-oc: off
nsslapd-localhost: <fqdn masterA>
nsslapd-schemacheck: off
nsslapd-rewrite-rfc1274: off
nsslapd-return-exact-case: on
nsslapd-ssl-check-hostname: on
nsslapd-port: 389
nsslapd-localuser: nobody
nsslapd-errorlog-logging-enabled: on
nsslapd-errorlog-mode: 600
nsslapd-errorlog-maxlogsperdir: 2
nsslapd-errorlog-maxlogsize: 100
nsslapd-errorlog-logrotationtime: 1
nsslapd-errorlog-logrotationtimeunit: week
nsslapd-errorlog-logrotationsync-enabled: off
nsslapd-errorlog-logrotationsynchour: 0
nsslapd-errorlog-logrotationsyncmin: 0
nsslapd-errorlog: /opt/fedora-ds/slapd-<masterA>/logs/errors
nsslapd-auditlog: /opt/fedora-ds/slapd-<masterA>/logs/audit
nsslapd-auditlog-mode: 600
nsslapd-auditlog-maxlogsize: 100
nsslapd-auditlog-logrotationtime: 1
nsslapd-auditlog-logrotationtimeunit: day
nsslapd-rootdn: cn=Directory Manager
nsslapd-maxdescriptors: 8192
nsslapd-max-filter-nest-level: 40
aci: (targetattr="*")(version 3.0; acl "Configuration Administrators
Group"; a
llow (all) groupdn="ldap:///cn=Configuration Administrators,
ou=Groups, ou=T
opologyManagement, o=NetscapeRoot";)
aci: (targetattr="*")(version 3.0; acl "Configuration Administrator";
allow (a
ll) userdn="ldap:///uid=admin,ou=Administrators,
ou=TopologyManagement, o=Ne
tscapeRoot";)
aci: (targetattr = "*")(version 3.0; acl "Local Directory
Administrators Group
"; allow (all) groupdn="ldap:///cn=Directory Administrators,
o=my_suffix";)
aci: (targetattr = "*")(version 3.0; acl "SIE Group"; allow
(all)groupdn = "ld
ap:///cn=slapd-<masterA>, cn=Fedora Directory Server, cn=Server
Group, cn=<masterA>, ou=<domain>, o=NetscapeRoot";)
modifiersName: cn=directory manager
modifyTimestamp: 20111027035111Z
passwordLockout: on
nsslapd-security: off
passwordLockoutDuration: 1800
passwordMaxFailure: 5
nsslapd-pwpolicy-local: on
passwordCheckSyntax: on
passwordInHistory: 8
passwordExp: on
passwordHistory: on
passwordMinLength: 8
passwordMinAge: 0
passwordWarning: 1209600
passwordMaxAge: 5184000
nsslapd-errorlog-level: 8192
nsslapd-rootpw: {SSHA}UINj4WIl7oboQnwW+ckND0Z+O3frZyF0mFcCnQ==
numSubordinates: 10
dn: cn=replication,cn=config
objectClass: top
objectClass: extensibleObject
cn: replication
userPassword: {SSHA}bUA40pCdakQByXFXz/D6jjR77abNvf4cjncNRg==
modifiersName: cn=server,cn=plugins,cn=config
modifyTimestamp: 20120405190704Z
passwordGraceUserTime: 0
passwordExpirationTime: 20380119031407z
passwordHistory:
20111027042723Z{SSHA}sfrwJMbFEF+VmXtXYmSz+65wvVMffrtR/M11WQ==
passwordHistory:
20120403171726Z{SSHA}PbA88Gnvp6SVs0KHdYo7y/fPG+C2HwzUk5DbwA==
passwordHistory:
20120405190704Z{SSHA}Ycxkxwe5otvoR5y/IdD8pKNBySEJTXWqjNN4Mw==
passwordRetryCount: 0
dn: cn=replica,cn="o=my_suffix",cn=mapping tree, cn=config
objectClass: nsDS5Replica
objectClass: top
nsDS5ReplicaRoot: o=my_suffix
nsDS5ReplicaType: 3
nsDS5Flags: 1
nsDS5ReplicaId: 06
nsds5ReplicaPurgeDelay: 604800
nsDS5ReplicaBindDN: cn=replication,cn=config
nsDS5ReplicaReferral: ldap://<masterB>:389/o=my_suffix
cn: replica
creatorsName: cn=directory manager
modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config
createTimestamp: 20050927210406Z
modifyTimestamp: 20120410182234Z
nsState:: BgAAAFR6hE8AAAAAsQIAAAEAAAA=
nsDS5ReplicaName: 1da9fe82-1dd211b2-80bc8f56-47cc0000
numSubordinates: 3
dn: cn=<my_suffix>_to_<consumerC>, cn=replica,
cn="o=<my_suffix>",
cn=mapping tree,
cn=config
objectClass: top
objectClass: nsDS5ReplicationAgreement
description: Replicate to consumerC
cn: <my_suffix>_to_<consumerC>
nsDS5ReplicaRoot: o=<my_suffix>
nsDS5ReplicaHost: <fqdn consumerC>
nsDS5ReplicaPort: 389
nsDS5ReplicaBindDN: cn=replication,cn=config
nsDS5ReplicaCredentials: <plain text password for some reason>
Don't use cn=replication,cn=config as your replica Bind DN (aka Supplier
Bind DN). That entry is used internally for other purposes. Instead,
create a new entry as per
Another problem is that the password is plain text. It should be
encrypted. How are you setting this password?
nsDS5ReplicaBindMethod: SIMPLE
creatorsName: cn=directory manager
modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config
createTimestamp: 20120403204406Z
modifyTimestamp: 20120406001957Z
Consumer C:
dn: cn=config
cn: config
objectClass: top
objectClass: extensibleObject
objectClass: nsslapdConfig
nsslapd-accesslog-logging-enabled: on
nsslapd-accesslog-maxlogsperdir: 10
nsslapd-accesslog-mode: 600
nsslapd-accesslog-maxlogsize: 100
nsslapd-accesslog-logrotationtime: 1
nsslapd-accesslog-logrotationtimeunit: day
nsslapd-accesslog-logrotationsync-enabled: off
nsslapd-accesslog-logrotationsynchour: 0
nsslapd-accesslog-logrotationsyncmin: 0
nsslapd-accesslog: /opt/fedora-ds/slapd-<consumerC>/logs/access
nsslapd-enquote-sup-oc: off
nsslapd-localhost: <fqdn consumerC>
nsslapd-schemacheck: off
nsslapd-rewrite-rfc1274: off
nsslapd-return-exact-case: on
nsslapd-ssl-check-hostname: on
nsslapd-port: 389
nsslapd-localuser: nobody
nsslapd-errorlog-logging-enabled: on
nsslapd-errorlog-mode: 600
nsslapd-errorlog-maxlogsperdir: 2
nsslapd-errorlog-maxlogsize: 100
nsslapd-errorlog-logrotationtime: 1
nsslapd-errorlog-logrotationtimeunit: week
nsslapd-errorlog-logrotationsync-enabled: off
nsslapd-errorlog-logrotationsynchour: 0
nsslapd-errorlog-logrotationsyncmin: 0
nsslapd-errorlog: /opt/fedora-ds/slapd-<consumerC>/logs/errors
nsslapd-auditlog: /opt/fedora-ds/slapd-<consumerC>/logs/audit
nsslapd-auditlog-mode: 600
nsslapd-auditlog-maxlogsize: 100
nsslapd-auditlog-logrotationtime: 1
nsslapd-auditlog-logrotationtimeunit: day
nsslapd-rootdn: cn=Directory Manager
nsslapd-maxdescriptors: 8192
nsslapd-max-filter-nest-level: 40
aci: (targetattr="*")(version 3.0; acl "Configuration Administrators
Group"; a
llow (all) groupdn="ldap:///cn=Configuration Administrators,
ou=Groups, ou=T
opologyManagement, o=NetscapeRoot";)
aci: (targetattr="*")(version 3.0; acl "Configuration Administrator";
allow (a
ll) userdn="ldap:///uid=admin,ou=Administrators,
ou=TopologyManagement, o=Ne
tscapeRoot";)
aci: (targetattr = "*")(version 3.0; acl "Local Directory
Administrators Group
"; allow (all) groupdn="ldap:///cn=Directory Administrators,
o=<my_suffix>";)
aci: (targetattr = "*")(version 3.0; acl "SIE Group"; allow
(all)groupdn = "ld
ap:///cn=slapd-<consumerC>, cn=Fedora Directory Server, cn=Server
Group, cn=<fqdn consumerC>, ou=<domain>, o=NetscapeRoot";)
modifiersName: cn=directory manager
modifyTimestamp: 20120403181804Z
passwordCheckSyntax: on
nsslapd-pwpolicy-local: on
passwordInHistory: 8
passwordExp: on
passwordHistory: on
passwordMinLength: 8
passwordWarning: 1209600
passwordMaxAge: 5184000
passwordLockout: off
passwordLockoutDuration: 900
passwordMaxFailure: 5
nsslapd-errorlog-level: 4096
nsslapd-readonly: off
nsslapd-rootpw: {SSHA}sBIvb4v30kzTCmSiBwpsXc+89nEavcFIDcQBHg==
numSubordinates: 10
dn: cn=replication,cn=config
objectClass: top
objectClass: extensibleObject
cn: replication
userPassword: {SSHA}Wj00Ba9zK24JpnQgHSYXiUiJC5lUDetm2kmSxQ==
modifiersName: cn=server,cn=plugins,cn=config
modifyTimestamp: 20120405185217Z
passwordRetryCount: 0
passwordGraceUserTime: 0
passwordExpirationTime: 20380119031407z
passwordExpWarned:
retryCountResetTime: 20111019034434Z
accountUnlockTime: 20111019033421Z
passwordHistory:
20111026073128Z{SSHA}F8zw64sH3WOY1wZ83j7zVa893o5tvJOdicI8uw==
passwordHistory:
20111027033502Z{SSHA}rhywp2y/uYfea+zB7F86l0mJqY9QWTNdGhl2KA==
passwordHistory:
20120330230435Z{SSHA}eCyc4cacqk7vSCiEZFEO8gxkRLCQjxEUGy3qYw==
passwordHistory:
20120403163555Z{SSHA}1zgdAL8GqLy/H+3wKlgPGFgxmWbieH2Eau5Ujg==
passwordHistory:
20120403171110Z{SSHA}f0eJOaXQFg6gX366EntWi6C1upkMRyOEIQN34A==
passwordHistory:
20120403221137Z{SSHA}Ycxkxwe5otvoR5y/IdD8pKNBySEJTXWqjNN4Mw==
passwordHistory: 20120405185217ZotvoR5y/IdD8pKSAEvsaassWqjNAEFw==
dn: cn=replica,cn="o=<my_suffix>",cn=mapping tree, cn=config
objectClass: nsDS5Replica
objectClass: top
nsDS5ReplicaRoot: o=<my_suffix>
nsDS5ReplicaType: 2
nsDS5Flags: 0
nsds5ReplicaPurgeDelay: 604800
nsDS5ReplicaBindDN: cn=replication,cn=config
cn: replica
creatorsName: cn=directory manager
modifiersName: cn=directory manager
createTimestamp: 20111027042446Z
modifyTimestamp: 20120405233320Z
nsDS5ReplicaId: 65535
nsState:: //8AAI78eU8AAAAAAAAAAAMAAAA=
nsDS5ReplicaName: 7733e202-1dd211b2-80a1ed8a-0e2a0000
nsDS5ReplicaReferral: ldap://<masterA>:389/o=<my_suffix>
dn: cn="o=<my_suffix>",cn=mapping tree, cn=config
objectClass: top
objectClass: extensibleObject
objectClass: nsMappingTree
nsslapd-state: referral on update
cn: "o=<my_suffix>"
cn: o=<my_suffix>
nsslapd-backend: <my_suffix>
creatorsName: cn=directory manager
modifiersName: cn=server,cn=plugins,cn=config
createTimestamp: 20080215020326Z
modifyTimestamp: 20120330190524Z
nsslapd-referral: ldap://<masterA>:389/o=<my_suffix>
numSubordinates: 1
Is there anything here that would indicate why I'm receiving a
permission denied? Is there a better, more verbose setting for error
logging? Is there more configuration data that would be helpful to
diagnose?
As always, any guidance is greatly appreciated.
Thanks in advance,
Herb
On Thu, Apr 5, 2012 at 10:58 AM, Rich Megginson <rmeggins(a)redhat.com
<mailto:rmeggins@redhat.com>> wrote:
On 04/05/2012 11:43 AM, Herb Burnswell wrote:
>
>
> On Thu, Apr 5, 2012 at 10:31 AM, Rich Megginson
> <rmeggins(a)redhat.com <mailto:rmeggins@redhat.com>> wrote:
>
> On 04/05/2012 11:31 AM, Herb Burnswell wrote:
>> Rich,
>>
>> I found a thread that you helped someone with a while back
>> and it seems to be the exact problem that I am facing:
>>
>>
http://www.linux-archive.org/general-discussion-list-389-directory-server...
>>
>> You mention:
>>
>> Did you add cn=replication manager,cn=config to the
>> consumer's replica
>> config entry, to the list of supplier DNs that are allowed
>> to update
>> that replica?
>>
>> Is this config entry in the dse.ldif file? The link that
>> the person used as a guide doesn't seem to be working now.
>> Can you point me to how configure this correctly in the
>> appropriate files?
> I think they moved the docs around. Use the 9.0 doc anyway.
>
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Admin...
>
> specifically
>
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Admin...
> or
>
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Admin...
>
>
>
> Thank you, I'll read the documentation. Can you clarify what you
> mean when you say:
>
> "consumer's replica config entry"
the cn=replica,cn=YOUR SUFFIX,cn=mapping tree,cn=config entry on
the consumer
> and "the list of supplier DNs that are allowed to update
> that replica"
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Confi...
>
> Are these set in a specific file(s) that should be edited?
The dse.ldif file - but don't edit that file directly unless
necessary - use the console or ldapmodify/ldapsearch
>
> Thanks,
>
> Herb
>
>>
>> Thanks,
>>
>> Herb
>>
>>
>> On Tue, Apr 3, 2012 at 2:55 PM, Herb Burnswell
>> <herbert.burnswell(a)gmail.com
>> <mailto:herbert.burnswell@gmail.com>> wrote:
>>
>>
>> ---------- Forwarded message ----------
>> From: *Rich Megginson* <rmeggins(a)redhat.com
>> <mailto:rmeggins@redhat.com>>
>> Date: Mon, Apr 2, 2012 at 7:37 PM
>> Subject: Re: [389-users] Fwd: Repair replication
>> To: "General discussion list for the 389 Directory
>> server project." <389-users(a)lists.fedoraproject.org
>> <mailto:389-users@lists.fedoraproject.org>>
>> Cc: Herb Burnswell <herbert.burnswell(a)gmail.com
>> <mailto:herbert.burnswell@gmail.com>>
>>
>>
>> On 04/02/2012 05:48 PM, Herb Burnswell wrote:
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: *Rich Megginson* <rmeggins(a)redhat.com
>>> <mailto:rmeggins@redhat.com>>
>>> Date: Mon, Apr 2, 2012 at 3:23 PM
>>> Subject: Re: [389-users] Repair replication
>>> To: "General discussion list for the 389 Directory
>>> server project." <389-users(a)lists.fedoraproject.org
>>> <mailto:389-users@lists.fedoraproject.org>>
>>> Cc: Herb Burnswell <herbert.burnswell(a)gmail.com
>>> <mailto:herbert.burnswell@gmail.com>>
>>>
>>>
>>> On 04/02/2012 04:13 PM, Herb Burnswell wrote:
>>>>
>>>>
>>>> On Fri, Mar 23, 2012 at 10:53 AM, Rich Megginson
>>>> <rmeggins(a)redhat.com
<mailto:rmeggins@redhat.com>> wrote:
>>>>
>>>> On 03/23/2012 11:09 AM, Herb Burnswell wrote:
>>>>> Thanks for the reply David.
>>>>>
>>>>> >> 1. How can I find out which system(s)
is/are
>>>>> master, consumer, hub, etc?
>>>>> >>>>You should be able to determine the
role of
>>>>> the Directory Server for each
>>>>> >>>>system by logging into the LDAP
console under
>>>>>
>>>>"Configuration->Replication". The role is
>>>>> either "Single Master", "Hub" or
>>>>> >>>>"Dedicated Consumer".
>>>>>
>>>>> >I was able to determine that we have two
>>>>> "Multiple Master" systems. Let's call
>them 'A'
>>>>> and 'B'. System A has been the only system
>>>>> running for what appears to >be several years (it
>>>>> is being backed up nightly). System B has been
>>>>> off for some >time but is running now.
>>>>>
>>>>> >> 2. How do I confirm that the systems have
the
>>>>> correct credentials for
>>>>> >replication? (I am receiving: "Unable to
acquire
>>>>> replica: Permission
>>>>> >denied.")
>>>>> >a. How can I change the bind dn
>>>>> "cn=replication,cn=config" credentials
>>>>> >on each system to ensure replication will work?
>>>>> >>>>You can do that on the console as
well. Just
>>>>> navigate down the directory
>>>>> >>>>tree and manually reset the password
for the
>>>>> replication user account.
>>>>> >>>>There's a possibility that your
replication
>>>>> user account's password expired.
>>>>>
>>>>> >I can navigate to the screen to reset the
>>>>> password for the replication user account. I
>>>>> >have not reset the passwords yet as I am reading
>>>>> documentation to confirm that >system B will
>>>>> simply update it's data to system A's upon
>>>>> resuming replication.
>>>> >When you change the password of the replication
>>>> user on B, you'll also have to update >those
>>>> credentials in the replication agreement on A for
>>>> the agreement from A to B.
>>>>
>>>> >Note that if replication has been down for years,
>>>> you will have to perform a manual >replica
>>>> initialization procedure - replication will not
>>>> automatically "catch up" if it has >been
down that
>>>> long.
>>>>
>>>> Rich - Thank you for the response. I was diverted to
>>>> another urgent issue but have come back to this
>>>> replication fix.
>>>>
>>>> I've confirmed that there are two Dedicated
Consumer's
>>>> (C and D) to go along with the two Dual Master's (A
>>>> and B). I want to replicate to one of the dedicated
>>>> consumers, C, prior to syncing the dual master B. I
>>>> changed the passwords for dn:cn=replication,cn=config
>>>> on A via the Directory Manager console, and via
>>>> ldapmodify on C. I am confident that the passwords are
>>>> the same on both systems.
>>>
>>> >What exactly did you do?
>>> >Note that you'll have to update the password in
>>> cn=replication,cn=config on the >consumer (C) and
>>> update the replication agreement on A for the
>>> replication agreement >between A and C.
>>>
>>> Thanks for the reply Rich. Yes, I updated the password
>>> on A and C. I apologize as I left out the link in my
>>> below reference to section 8.10.5.1 <
http://8.10.5.1>:
>>>
http://www.centos.org/docs/5/html/CDS/ag/8.0/Managing_Replication-Initial....
>>> I used bak2db with backup files from A. After which, I
>>> see: "Unable to acquire replica: permission denied. The
>>> bind dn "cn=replication,cn=config" does not have
>>> permission to supply replication updates to the
>>> replica. Will retry later." on system A's error logs..
>> >I think doing the restore is resetting the password.
>> After doing the bak2db, change the >passwords.
>>
>> Well, I'm kind of at a loss here. I've reset the
>> passwords on A and C after doing the bak2db. Same error:
>>
>>
>> Unable to acquire replica: permission denied. The bind
>> dn "cn=replication,cn=config" does not have permission
>> to supply replication updates to the replica. Will retry
>> later.
>>
>> Next, I removed and re-added the replication agreement
>> on Master A to Consumer C, same error above.
>>
>> Is there any way that I can output the settings/password
>> information for cn=replication,cn=config on both A and C
>> via the command line to compare? I have read that there
>> needs to be a 'person' entry on the consumer for
>> cn=replication,cn=config that is used for the
>> replication of the data. Is there a way I can confirm
>> this configuration to ensure it is set up correctly?
>>
>> I'm also seeing this error in the logs on consumer C:
>>
>> NSMMReplicationPlugin - conn=2 op=9 replica="o=myTree":
>> Unable to acquire replica: error: permission denied
>>
>>
>>
>>>>
>>>> >I followed section 8.10.5.1 on initializing the
>>>> consumer replica from backup files and it >worked with
>>>> the following:
>>>>
>>>> >[02/Apr/2012:11:58:03 -0700] - Add Attribute readonly
>>>> Value off
>>>> >[02/Apr/2012:11:58:03 -0700] - Add Attribute
>>>> nsslapd-directory Value /new/path/from/master/server
>>>> >[02/Apr/2012:11:58:04 -0700] - Del Attribute
>>>> nsslapd-directory Value /old/path/from/consumer
>>>> >[02/Apr/2012:11:58:04 -0700] - WARNING!!: current
>>>> Instance Config is different from backed up
>>>> configuration; The backup is restored.
>>>>
>>>> >First, do I need to reset these attributes back to
>>>> 'readonly' and the original nsslapd-directory?
>>>>
>>>> >Second, I am now receiving the following error from
>>>> the master A:
>>>> >Unable to acquire replica: permission denied. The
>>>> bind dn "cn=replication,cn=config" >does not
have
>>>> permission to supply replication updates to the
>>>> replica. Will retry later.
>>>>
>>>> >On another note, I see plain text passwords in the
>>>> error logs on A for the consumers >but passwd =
>>>> {SSHA}0bgDq2f1IM/2nNOOIHUh8lXfkG13XUOHTYD== for B, the
>>>> other >master. Is there specific reason for this?
>>>>
>>>> >As always, any guidance that can be provided is
>>>> greatly appreciated.
>>>>
>>>> TIA,
>>>>
>>>> Herb
>>>>
>>>>>
>>>>> >> 3. I assume that upon repairing replication
>>>>> (apparently it has not been
>>>>> working for several years) the systems will all
>>>>> replicate to the most
>>>>> recent information. Correct?
>>>>> >>>>I think that's the tricky part.
Make sure
>>>>> you backup your directory on all
>>>>> >>>>the LDAP first so you have something
to roll
>>>>> back. I *believe* the last
>>>>> >>>>step when setting up replication is
>>>>> initializing the directory and that
>>>>> >>>>will wipe out directory on the other
LDAP.
>>>>> Someone on the list might be
>>>>> >>>>able to provide a better on this but
I am
>>>>> just giving you a heads up that
>>>>> >>>>this can be a complicated process.
>>>>>
>>>>> Given the fact that system B has not been running
>>>>> for some time, ideally it would simply replicate
>>>>> to the current data on system A. After
>>>>> replication is reestablished the systems are set
>>>>> up to "Always keep directories in sync".
If
>>>>> anyone can confirm the behavior that will occur
>>>>> upon replication on these two systems it would be
>>>>> greatly appreciated.
>>>>>
>>>>> Thanks in advance,
>>>>>
>>>>> Herb
>>>>>
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> Message: 2
>>>>> Date: Thu, 22 Mar 2012 10:40:34 -0400
>>>>> From: Chun Tat David Chu
>>>>> <beyonddc.storage(a)gmail.com
>>>>> <mailto:beyonddc.storage@gmail.com>>
>>>>> To: "General discussion list for the 389
>>>>> Directory server project."
>>>>> <389-users(a)lists.fedoraproject.org
>>>>>
<mailto:389-users@lists.fedoraproject.org>>
>>>>> Subject: Re: [389-users] Repair replication
>>>>> Message-ID:
>>>>>
<CANCf8oLYKet99sB_ou4U3CER8U89UgwZhGUBTHekcF9HWNKL9g(a)mail.gmail.com
>>>>>
<mailto:CANCf8oLYKet99sB_ou4U3CER8U89UgwZhGUBTHekcF9HWNKL9g@mail.gmail.com>>
>>>>> Content-Type: text/plain;
charset="iso-8859-1"
>>>>>
>>>>> Hey Herb,
>>>>>
>>>>> You should refer to the Red Hat Directory
>>>>> Server administration guide for
>>>>> detail about setting up replication which you
>>>>> can locate in here.
>>>>>
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/
>>>>>
>>>>> >> 1. How can I find out which system(s)
>>>>> is/are master, consumer, hub, etc?
>>>>> You should be able to determine the role of
>>>>> the Directory Server for each
>>>>> system by logging into the LDAP console under
>>>>> "Configuration->Replication". The
role is
>>>>> either "Single Master", "Hub"
or
>>>>> "Dedicated Consumer".
>>>>>
>>>>> >> 2. How do I confirm that the systems
have
>>>>> the correct credentials for
>>>>> replication? (I am receiving: "Unable to
>>>>> acquire replica: Permission
>>>>> denied.")
>>>>> a. How can I change the bind dn
>>>>> "cn=replication,cn=config" credentials
>>>>> on each system to ensure replication will work?
>>>>> You can do that on the console as well. Just
>>>>> navigate down the directory
>>>>> tree and manually reset the password for the
>>>>> replication user account.
>>>>> There's a possibility that your replication
>>>>> user account's password expired.
>>>>>
>>>>> >> 3. I assume that upon repairing
>>>>> replication (apparently it has not been
>>>>> working for several years) the systems will
>>>>> all replicate to the most
>>>>> recent information. Correct?
>>>>> I think that's the tricky part. Make sure
>>>>> you backup your directory on all
>>>>> the LDAP first so you have something to roll
>>>>> back. I *believe* the last
>>>>> step when setting up replication is
>>>>> initializing the directory and that
>>>>> will wipe out directory on the other LDAP.
>>>>> Someone on the list might be
>>>>> able to provide a better on this but I am
>>>>> just giving you a heads up that
>>>>> this can be a complicated process.
>>>>>
>>>>> Good luck
>>>>>
>>>>> - David
>>>>>
>>>>> 2012/3/21 Herb Burnswell
>>>>> <herbert.burnswell(a)gmail.com
>>>>> <mailto:herbert.burnswell@gmail.com>>
>>>>>
>>>>> > Hi All,
>>>>> >
>>>>> > I'm new to LDAP administration and have
>>>>> been tasked with fixing the system
>>>>> > replication of 4 Linux systems running
>>>>> Fedora Directory Services. I am
>>>>> > very comfortable working with Linux/Unix
>>>>> but am not experienced with LDAP.
>>>>> > I've been reading the communications
from
>>>>> this user group and reading as
>>>>> > much as I can from documentation. I
>>>>> believe this environment is not too
>>>>> > complex but I am looking for some guidance,
>>>>> any assistance is greatly
>>>>> > appreciated.
>>>>> >
>>>>> > Info:
>>>>> >
>>>>> > OS: Fedora Core 4
>>>>> > LDAP: Fedora Directory Server v 7.1
>>>>> >
>>>>> > First, I know that both the systems and FDS
>>>>> versions are ancient.
>>>>> > However, at this point I need to get the
>>>>> replication working prior to
>>>>> > putting together a migration plan. I have
>>>>> access to the Directory Manager
>>>>> > console and am comfortable running command
>>>>> line commands as well. Either
>>>>> > way is fine.
>>>>> >
>>>>> > Questions:
>>>>> >
>>>>> > 1. How can I find out which system(s)
>>>>> is/are master, consumer, hub, etc?
>>>>> >
>>>>> > 2. How do I confirm that the systems have
>>>>> the correct credentials for
>>>>> > replication? (I am receiving: "Unable
to
>>>>> acquire replica: Permission
>>>>> > denied.")
>>>>> > a. How can I change the bind dn
>>>>> "cn=replication,cn=config" credentials
>>>>> > on each system to ensure replication will
work?
>>>>> >
>>>>> > 3. I assume that upon repairing replication
>>>>> (apparently it has not been
>>>>> > working for several years) the systems will
>>>>> all replicate to the most
>>>>> > recent information. Correct?
>>>>> >
>>>>> > Again, any guidance is greatly appreciated.
>>>>> >
>>>>> > Thanks in advance,
>>>>> >
>>>>> > Herb
>>>>> >
>>>>> > --
>>>>> > 389 users mailing list
>>>>> > 389-users(a)lists.fedoraproject.org
>>>>> <mailto:389-users@lists.fedoraproject.org>
>>>>> >
>>>>>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>> >
>>>>> -------------- next part --------------
>>>>> An HTML attachment was scrubbed...
>>>>> URL:
>>>>>
<
http://lists.fedoraproject.org/pipermail/389-users/attachments/20120322/e...
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 389 users mailing list
>>>>> 389-users(a)lists.fedoraproject.org
<mailto:389-users@lists.fedoraproject.org>
>>>>>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 389 users mailing list
>>>> 389-users(a)lists.fedoraproject.org
<mailto:389-users@lists.fedoraproject.org>
>>>>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>
>>>
>>>
>>>
>>> --
>>> 389 users mailing list
>>> 389-users(a)lists.fedoraproject.org
<mailto:389-users@lists.fedoraproject.org>
>>>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>>
>>
>>
>>
>
>