This can be caused by replication dn having an expired password. On Tue, Apr 3, 2012 at 4:55 PM, Herb Burnswell <herbert.burnsw...@gmail.com>wrote:
> > ---------- Forwarded message ---------- > From: Rich Megginson <rmegg...@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@lists.fedoraproject.org> > Cc: Herb Burnswell <herbert.burnsw...@gmail.com> > > > On 04/02/2012 05:48 PM, Herb Burnswell wrote: > > > > ---------- Forwarded message ---------- > From: Rich Megginson <rmegg...@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@lists.fedoraproject.org> > Cc: Herb Burnswell <herbert.burnsw...@gmail.com> > > > On 04/02/2012 04:13 PM, Herb Burnswell wrote: > > > > On Fri, Mar 23, 2012 at 10:53 AM, Rich Megginson <rmegg...@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-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.stor...@gmail.com> >>> To: "General discussion list for the 389 Directory server project." >>> <389-users@lists.fedoraproject.org> >>> Subject: Re: [389-users] Repair replication >>> Message-ID: >>> < >>> cancf8olyket99sb_ou4u3cer8u89ugwzhgubthekcf9hwnk...@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.burnsw...@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@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 >> 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 > > > > > > -- > 389 users mailing list > 389-users@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users >
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
