[389-users] Repair replication
Rich Megginson
rmeggins at redhat.com
Tue Apr 10 23:18:07 UTC 2012
On 04/10/2012 04:11 PM, Herb Burnswell wrote:
>
>
> On Tue, Apr 10, 2012 at 1:03 PM, Rich Megginson <rmeggins at redhat.com
> <mailto:rmeggins at 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/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?
>
>
> 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 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/2042c375/attachment.html>
More information about the 389-users
mailing list