Thanks for your help Rich. Yes, I am at a complete loss as well. I've
followed everything I've read to a T and still no luck. I like to think
I'm not a complete idiot but I may have to re-think that...
Oh well, I'm thinking I may have to go to a script to backup db's on one
master, send the files to the 'other master' and consumers and bak2db them
once received.. Not good.
Thanks again..
On Tue, Apr 10, 2012 at 4:18 PM, Rich Megginson <rmeggins(a)redhat.com> wrote:
On 04/10/2012 04:11 PM, Herb Burnswell wrote:
On Tue, Apr 10, 2012 at 1:03 PM, Rich Megginson <rmeggins(a)redhat.com>wrote:
> On 04/10/2012 01:53 PM, Herb Burnswell wrote:
>
> 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
>
>
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Admin...
>
> Another problem is that the password is plain text. It should be
> encrypted. How are you setting this password?
>
Ok, I have created a new Supplier Bind DN as: cn=replication
manager,cn=config on consumer C as directed in the documentation. I then
edited the replication agreement on master A (via the directory server
console) to use the new Bind DN credentials. The initialization still
failed with:
Unable to acquire replica: permission denied. The bind dn "cn=replication
manager,cn=config" does not have permission to supply replication updates
to the replica. Will retry later.
I then looked at the dse.ldif file on master A and the replication
agreement from master A to consumer C config was edited with the new
password credential but was still in plain text.
I then deleted the replication agreement from master A to consumer C via
the directory server console on master A and created a new one with the
appropriate credentials. The initialization still failed with the same
error and in the dse.ldif file the password is still written in plain text.
Do you know why this is printing the password in plain text instead of
encrypted?
I don't know. I'm at a loss to explain what's happening.
thanks
Herb
>
>
> 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>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>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> wrote:
>>>
>>>>
>>>> ---------- Forwarded message ----------
>>>> From: Rich Megginson <rmeggins(a)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>
>>>> Cc: Herb Burnswell <herbert.burnswell(a)gmail.com>
>>>>
>>>>
>>>> On 04/02/2012 05:48 PM, Herb Burnswell wrote:
>>>>
>>>>
>>>>
>>>> ---------- Forwarded message ----------
>>>> From: Rich Megginson <rmeggins(a)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>
>>>> Cc: Herb Burnswell <herbert.burnswell(a)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>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://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>
>>>>>> To: "General discussion list for the 389 Directory server
project."
>>>>>> <389-users(a)lists.fedoraproject.org>
>>>>>> Subject: Re: [389-users] Repair replication
>>>>>> Message-ID:
>>>>>> <
>>>>>>
CANCf8oLYKet99sB_ou4U3CER8U89UgwZhGUBTHekcF9HWNKL9g(a)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>
>>>>>>
>>>>>> > 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
>>>>>> >
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
list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> 389 users mailing
list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 389 users mailing
list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>