[389-users] Repair replication
Rich Megginson
rmeggins at redhat.com
Tue Apr 10 20:03:52 UTC 2012
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/Administration_Guide/Creating_the_Supplier_Bind_DN_Entry.html
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 at redhat.com
> <mailto:rmeggins at 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 at redhat.com <mailto:rmeggins at 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-project-389-users-lists-fedoraproject-org/336807-replication-error-acquiring-replica-permission-denied-error-code-3-a.html
>>>
>>> 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/Administration_Guide/Managing_Replication.html
>>
>> specifically
>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Configuring_Single_Master_Replication.html#Configuring_Single_Master_Replication-Configuring_the_Read_Only_Replica_on_the_Consumer_Server
>> or
>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Configuring_Multi_Master_Replication.html#Multi_Master_Replication-Configuring_the_Read_Only_Replicas_on_the_Consumer_Servers
>>
>>
>>
>> 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/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#Replication_Attributes_under_cnreplica_cnsuffixName_cnmapping_tree_cnconfig-nsDS5ReplicaBindDN
>
>
>>
>> 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 at gmail.com
>>> <mailto:herbert.burnswell at gmail.com>> wrote:
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: *Rich Megginson* <rmeggins at redhat.com
>>> <mailto:rmeggins at 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 at lists.fedoraproject.org
>>> <mailto:389-users at lists.fedoraproject.org>>
>>> Cc: Herb Burnswell <herbert.burnswell at gmail.com
>>> <mailto:herbert.burnswell at gmail.com>>
>>>
>>>
>>> On 04/02/2012 05:48 PM, Herb Burnswell wrote:
>>>>
>>>>
>>>> ---------- Forwarded message ----------
>>>> From: *Rich Megginson* <rmeggins at redhat.com
>>>> <mailto:rmeggins at 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 at lists.fedoraproject.org
>>>> <mailto:389-users at lists.fedoraproject.org>>
>>>> Cc: Herb Burnswell <herbert.burnswell at gmail.com
>>>> <mailto:herbert.burnswell at gmail.com>>
>>>>
>>>>
>>>> On 04/02/2012 04:13 PM, Herb Burnswell wrote:
>>>>>
>>>>>
>>>>> On Fri, Mar 23, 2012 at 10:53 AM, Rich Megginson
>>>>> <rmeggins at redhat.com <mailto:rmeggins at 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-Initializing_Consumers.html.
>>>> 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 at gmail.com
>>>>>> <mailto:beyonddc.storage at gmail.com>>
>>>>>> To: "General discussion list for the 389
>>>>>> Directory server project."
>>>>>> <389-users at lists.fedoraproject.org
>>>>>> <mailto:389-users at lists.fedoraproject.org>>
>>>>>> Subject: Re: [389-users] Repair replication
>>>>>> Message-ID:
>>>>>> <CANCf8oLYKet99sB_ou4U3CER8U89UgwZhGUBTHekcF9HWNKL9g at mail.gmail.com
>>>>>> <mailto:CANCf8oLYKet99sB_ou4U3CER8U89UgwZhGUBTHekcF9HWNKL9g at 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 at gmail.com
>>>>>> <mailto:herbert.burnswell at 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 at lists.fedoraproject.org
>>>>>> <mailto:389-users at 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/edfe5e8f/attachment-0001.html>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 389 users mailing list
>>>>>> 389-users at lists.fedoraproject.org <mailto:389-users at lists.fedoraproject.org>
>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 389 users mailing list
>>>>> 389-users at lists.fedoraproject.org <mailto:389-users at lists.fedoraproject.org>
>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 389 users mailing list
>>>> 389-users at lists.fedoraproject.org <mailto:389-users at 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/20120410/9c65bc8a/attachment.html>
More information about the 389-users
mailing list