Re: [389-users] Repair replication

[Herb Burnswell]

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.

> > 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&gt;
> To: "General discussion list for the 389 Directory server project."
>        <389-users(a)lists.fedoraproject.org&gt;
> 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&gt;
>
> > 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...
> >
>
>

Repair replication

[Rich Megginson]

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.
>  >> 3. I assume that upon repairing replication (apparently it has not been
>  working for several years) the systems will all replicate to the most
>  recent information.  Correct?
>  >>>>I think that's the tricky part.  Make sure you backup your 
>  directory on all
>  >>>>the LDAP first so you have something to roll back.  I *believe* 
>  the last
>  >>>>step when setting up replication is initializing the directory and 
>  that
>  >>>>will wipe out directory on the other LDAP.  Someone on the list 
>  might  be
>  >>>>able to provide a better on this but I am just giving you a heads 
>  up that
>  >>>>this can be a complicated process.
>
>  Given the fact that system B has not been running for some time, 
>  ideally it would simply replicate to the current data on system A.  
>  After replication is reestablished the systems are set up to "Always 
>  keep directories in sync".  If anyone can confirm the behavior that 
>  will occur upon replication on these two systems it would be greatly 
>  appreciated.
>
>  Thanks in advance,
>
>  Herb
>
>
>      ------------------------------
>
>      Message: 2
>      Date: Thu, 22 Mar 2012 10:40:34 -0400
>      From: Chun Tat David Chu <beyonddc.storage(a)gmail.com
>      <mailto:[e-mail]>>
>      To: "General discussion list for the 389 Directory server project."
>      <389-users(a)lists.fedoraproject.org
>      <mailto:[e-mail]>>
>      Subject: Re: [389-users] Repair replication
>      Message-ID:
>      <CANCf8oLYKet99sB_ou4U3CER8U89UgwZhGUBTHekcF9HWNKL9g(a)mail.gmail.com
> <mailto:[e-mail]>>
>      Content-Type: text/plain; charset="iso-8859-1"
>
>      Hey Herb,
>
>      You should refer to the Red Hat Directory Server administration
>      guide for
>      detail about setting up replication which you can locate in here.
>      http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/
>
>      >> 1. How can I find out which system(s) is/are master, consumer,
>      hub, etc?
>      You should be able to determine the role of the Directory Server
>      for each
>      system by logging into the LDAP console under
>      "Configuration->Replication".  The role is either "Single
> Master",
>      "Hub" or
>      "Dedicated Consumer".
>
>      >> 2. How do I confirm that the systems have the correct
>      credentials for
>      replication? (I am receiving: "Unable to acquire replica: Permission
>      denied.")
>         a. How can I change the bind dn "cn=replication,cn=config"
>      credentials
>      on each system to ensure replication will work?
>      You can do that on the console as well.  Just navigate down the
>      directory
>      tree and manually reset the password for the replication user account.
>      There's a possibility that your replication user account's
>      password expired.
>
>      >> 3. I assume that upon repairing replication (apparently it has
>      not been
>      working for several years) the systems will all replicate to the most
>      recent information.  Correct?
>      I think that's the tricky part.  Make sure you backup your
>      directory on all
>      the LDAP first so you have something to roll back.  I *believe*
>      the last
>      step when setting up replication is initializing the directory and
>      that
>      will wipe out directory on the other LDAP.  Someone on the list
>      might  be
>      able to provide a better on this but I am just giving you a heads
>      up that
>      this can be a complicated process.
>
>      Good luck
>
>      - David
>
>      2012/3/21 Herb Burnswell <herbert.burnswell(a)gmail.com
>      <mailto:[e-mail]>>
>
>      > Hi All,
>      >
>      > I'm new to LDAP administration and have been tasked with fixing
>      the system
>      > replication of 4 Linux systems running Fedora Directory
>      Services.  I am
>      > very comfortable working with Linux/Unix but am not experienced
>      with LDAP.
>      > I've been reading the communications from this user group and
>      reading as
>      > much as I can from documentation.  I believe this environment is
>      not too
>      > complex but I am looking for some guidance, any assistance is
>      greatly
>      > appreciated.
>      >
>      > Info:
>      >
>      > OS: Fedora Core 4
>      > LDAP: Fedora Directory Server v 7.1
>      >
>      > First, I know that both the systems and FDS versions are ancient.
>      > However, at this point I need to get the replication working
>      prior to
>      > putting together a migration plan.  I have access to the
>      Directory Manager
>      > console and am comfortable running command line commands as
>      well.  Either
>      > way is fine.
>      >
>      > Questions:
>      >
>      > 1. How can I find out which system(s) is/are master, consumer,
>      hub, etc?
>      >
>      > 2. How do I confirm that the systems have the correct
>      credentials for
>      > replication? (I am receiving: "Unable to acquire replica: Permission
>      > denied.")
>      >     a. How can I change the bind dn "cn=replication,cn=config"
>      credentials
>      > on each system to ensure replication will work?
>      >
>      > 3. I assume that upon repairing replication (apparently it has
>      not been
>      > working for several years) the systems will all replicate to the
>      most
>      > recent information.  Correct?
>      >
>      > Again, any guidance is greatly appreciated.
>      >
>      > Thanks in advance,
>      >
>      > Herb
>      >
>      > --
>      > 389 users mailing list
>      > 389-users(a)lists.fedoraproject.org
>      <mailto:[e-mail]>
>      > https://admin.fedoraproject.org/mailman/listinfo/389-users
>      >
>      -------------- next part --------------
>      An HTML attachment was scrubbed...
>      URL:
>     
> <http://lists.fedoraproject.org/pipermail/389-users/attachments/20120322/e...
>
>
>
>  --
>  389 users mailing list
>  389-users(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/389-users

Repair replication

[Herb Burnswell]

On Fri, Mar 23, 2012 at 10:53 AM, Rich Megginson <rmeggins(a)redhat.com&gt;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.

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&gt;
> > To: "General discussion list for the 389 Directory server project."
> >        <389-users(a)lists.fedoraproject.org&gt;
> > Subject: Re: [389-users] Repair replication
> > Message-ID:
> >        <
> > CANCf8oLYKet99sB_ou4U3CER8U89UgwZhGUBTHekcF9HWNKL9g(a)mail.gmail.com&gt;
> > 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&gt;
> >
> > > 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
> [e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>

Repair replication

[Rich Megginson]

On 04/02/2012 04:13 PM, Herb Burnswell wrote:
>  On Fri, Mar 23, 2012 at 10:53 AM, Rich Megginson <rmeggins(a)redhat.com 
>  <mailto:[e-mail]>> 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.

>  I followed section 8.10.5.1 on initializing the consumer replica from 
>  backup files and it worked with the following:
>
>  [02/Apr/2012:11:58:03 -0700] - Add Attribute readonly Value off
>  [02/Apr/2012:11:58:03 -0700] - Add Attribute nsslapd-directory Value 
>  /new/path/from/master/server
>  [02/Apr/2012:11:58:04 -0700] - Del Attribute nsslapd-directory Value 
>  /old/path/from/consumer
>  [02/Apr/2012:11:58:04 -0700] - WARNING!!: current Instance Config is 
>  different from backed up configuration; The backup is restored.
>
>  First, do I need to reset these attributes back to 'readonly' and the 
>  original nsslapd-directory?
>
>  Second, I am now receiving the following error from the master A:
>  Unable to acquire replica: permission denied. The bind dn 
>  "cn=replication,cn=config" does not have permission to supply 
>  replication updates to the replica. Will retry later.
>
>  On another note, I see plain text passwords in the error logs on A for 
>  the consumers but passwd = {SSHA}0bgDq2f1IM/2nNOOIHUh8lXfkG13XUOHTYD== 
>  for B, the other master. Is there specific reason for this?
>
>  As always, any guidance that can be provided is greatly appreciated.
>
>  TIA,
>
>  Herb
>
> >
> >     >> 3. I assume that upon repairing replication (apparently it has
> >     not been
> >     working for several years) the systems will all replicate to the most
> >     recent information.  Correct?
> >     >>>>I think that's the tricky part.  Make sure you backup your
> >     directory on all
> >     >>>>the LDAP first so you have something to roll back.  I
> >     *believe* the last
> >     >>>>step when setting up replication is initializing the
> >     directory and that
> >     >>>>will wipe out directory on the other LDAP.  Someone on the
> >     list might  be
> >     >>>>able to provide a better on this but I am just giving you a
> >     heads up that
> >     >>>>this can be a complicated process.
> >
> >     Given the fact that system B has not been running for some time,
> >     ideally it would simply replicate to the current data on system
> >     A.  After replication is reestablished the systems are set up to
> >     "Always keep directories in sync".  If anyone can confirm the
> >     behavior that will occur upon replication on these two systems it
> >     would be greatly appreciated.
> >
> >     Thanks in advance,
> >
> >     Herb
> >
> >
> >         ------------------------------
> >
> >         Message: 2
> >         Date: Thu, 22 Mar 2012 10:40:34 -0400
> >         From: Chun Tat David Chu <beyonddc.storage(a)gmail.com
> >         <mailto:[e-mail]>>
> >         To: "General discussion list for the 389 Directory server
> >         project."
> >         <389-users(a)lists.fedoraproject.org
> >         <mailto:[e-mail]>>
> >         Subject: Re: [389-users] Repair replication
> >         Message-ID:
> >         <CANCf8oLYKet99sB_ou4U3CER8U89UgwZhGUBTHekcF9HWNKL9g(a)mail.gmail.com
> >        
> <mailto:[e-mail]>>
> >         Content-Type: text/plain; charset="iso-8859-1"
> >
> >         Hey Herb,
> >
> >         You should refer to the Red Hat Directory Server
> >         administration guide for
> >         detail about setting up replication which you can locate in here.
> >         http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/
> >
> >         >> 1. How can I find out which system(s) is/are master,
> >         consumer, hub, etc?
> >         You should be able to determine the role of the Directory
> >         Server for each
> >         system by logging into the LDAP console under
> >         "Configuration->Replication".  The role is either "Single
> >         Master", "Hub" or
> >         "Dedicated Consumer".
> >
> >         >> 2. How do I confirm that the systems have the correct
> >         credentials for
> >         replication? (I am receiving: "Unable to acquire replica:
> >         Permission
> >         denied.")
> >            a. How can I change the bind dn "cn=replication,cn=config"
> >         credentials
> >         on each system to ensure replication will work?
> >         You can do that on the console as well.  Just navigate down
> >         the directory
> >         tree and manually reset the password for the replication user
> >         account.
> >         There's a possibility that your replication user account's
> >         password expired.
> >
> >         >> 3. I assume that upon repairing replication (apparently it
> >         has not been
> >         working for several years) the systems will all replicate to
> >         the most
> >         recent information.  Correct?
> >         I think that's the tricky part.  Make sure you backup your
> >         directory on all
> >         the LDAP first so you have something to roll back.  I
> >         *believe* the last
> >         step when setting up replication is initializing the
> >         directory and that
> >         will wipe out directory on the other LDAP.  Someone on the
> >         list might  be
> >         able to provide a better on this but I am just giving you a
> >         heads up that
> >         this can be a complicated process.
> >
> >         Good luck
> >
> >         - David
> >
> >         2012/3/21 Herb Burnswell <herbert.burnswell(a)gmail.com
> >         <mailto:[e-mail]>>
> >
> >         > Hi All,
> >         >
> >         > I'm new to LDAP administration and have been tasked with
> >         fixing the system
> >         > replication of 4 Linux systems running Fedora Directory
> >         Services.  I am
> >         > very comfortable working with Linux/Unix but am not
> >         experienced with LDAP.
> >         > I've been reading the communications from this user group
> >         and reading as
> >         > much as I can from documentation.  I believe this
> >         environment is not too
> >         > complex but I am looking for some guidance, any assistance
> >         is greatly
> >         > appreciated.
> >         >
> >         > Info:
> >         >
> >         > OS: Fedora Core 4
> >         > LDAP: Fedora Directory Server v 7.1
> >         >
> >         > First, I know that both the systems and FDS versions are
> >         ancient.
> >         > However, at this point I need to get the replication
> >         working prior to
> >         > putting together a migration plan.  I have access to the
> >         Directory Manager
> >         > console and am comfortable running command line commands as
> >         well.  Either
> >         > way is fine.
> >         >
> >         > Questions:
> >         >
> >         > 1. How can I find out which system(s) is/are master,
> >         consumer, hub, etc?
> >         >
> >         > 2. How do I confirm that the systems have the correct
> >         credentials for
> >         > replication? (I am receiving: "Unable to acquire replica:
> >         Permission
> >         > denied.")
> >         >     a. How can I change the bind dn
> >         "cn=replication,cn=config" credentials
> >         > on each system to ensure replication will work?
> >         >
> >         > 3. I assume that upon repairing replication (apparently it
> >         has not been
> >         > working for several years) the systems will all replicate
> >         to the most
> >         > recent information.  Correct?
> >         >
> >         > Again, any guidance is greatly appreciated.
> >         >
> >         > Thanks in advance,
> >         >
> >         > Herb
> >         >
> >         > --
> >         > 389 users mailing list
> >         > 389-users(a)lists.fedoraproject.org
> >         <mailto:[e-mail]>
> >         > https://admin.fedoraproject.org/mailman/listinfo/389-users
> >         >
> >         -------------- next part --------------
> >         An HTML attachment was scrubbed...
> >         URL:
> >        
> <http://lists.fedoraproject.org/pipermail/389-users/attachments/20120322/e...
> >
> >
> >
> >     --
> >     389 users mailing list
> >     389-users(a)lists.fedoraproject.org 
> <mailto:[e-mail]>
> >     https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
>
>  --
>  389 users mailing list
>  389-users(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/389-users

Fwd: Repair replication

[Herb Burnswell]

---------- Forwarded message ----------
From: Rich Megginson <rmeggins(a)redhat.com&gt;
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&gt;
Cc: Herb Burnswell <herbert.burnswell(a)gmail.com&gt;


 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&gt;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 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&gt;
> > To: "General discussion list for the 389 Directory server project."
> >        <389-users(a)lists.fedoraproject.org&gt;
> > Subject: Re: [389-users] Repair replication
> > Message-ID:
> >        <
> > CANCf8oLYKet99sB_ou4U3CER8U89UgwZhGUBTHekcF9HWNKL9g(a)mail.gmail.com&gt;
> > 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&gt;
> >
> > > 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
> [e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>  

--
389 users mailing
[e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users

Fwd: Repair replication

[Rich Megginson]

On 04/02/2012 05:48 PM, Herb Burnswell wrote:
>  ---------- Forwarded message ----------
>  From: *Rich Megginson* <rmeggins(a)redhat.com <mailto:[e-mail]>>
>  Date: Mon, Apr 2, 2012 at 3:23 PM
>  Subject: Re: [389-users] Repair replication
>  To: "General discussion list for the 389 Directory server project." 
>  <389-users(a)lists.fedoraproject.org 
>  <mailto:[e-mail]>>
>  Cc: Herb Burnswell <herbert.burnswell(a)gmail.com 
>  <mailto:[e-mail]>>
>
>
>  On 04/02/2012 04:13 PM, Herb Burnswell wrote:
> >
> >
> > On Fri, Mar 23, 2012 at 10:53 AM, Rich Megginson <rmeggins(a)redhat.com 
> > <mailto:[e-mail]>> wrote:
> >
> >     On 03/23/2012 11:09 AM, Herb Burnswell wrote:
> >>     Thanks for the reply David.
> >>
> >>     >> 1. How can I find out which system(s) is/are master,
> >>     consumer, hub, etc?
> >>     >>>>You should be able to determine the role of the Directory
> >>     Server for each
> >>     >>>>system by logging into the LDAP console under
> >>     >>>>"Configuration->Replication".  The role is
> either "Single
> >>     Master", "Hub" or
> >>     >>>>"Dedicated Consumer".
> >>
> >>     >I was able to determine that we have two "Multiple Master"
> >>     systems.  Let's call >them 'A' and 'B'.  System A has
> been the
> >>     only system running for what appears to >be several years (it is
> >>     being backed up nightly).  System B has been off for some >time
> >>     but is running now.
> >>
> >>     >> 2. How do I confirm that the systems have the correct
> >>     credentials for
> >>     >replication? (I am receiving: "Unable to acquire replica:
> >>     Permission
> >>     >denied.")
> >>     >a. How can I change the bind dn "cn=replication,cn=config"
> >>     credentials
> >>     >on each system to ensure replication will work?
> >>     >>>>You can do that on the console as well.  Just navigate down
> >>     the directory
> >>     >>>>tree and manually reset the password for the replication
> >>     user account.
> >>     >>>>There's a possibility that your replication user
> account's
> >>     password expired.
> >>
> >>     >I can navigate to the screen to reset the password for the
> >>     replication user account.  I >have not reset the passwords yet
> >>     as I am reading documentation to confirm that >system B will
> >>     simply update it's data to system A's upon resuming replication.
> >     >When you change the password of the replication user on B,
> >     you'll also have to update >those credentials in the replication
> >     agreement on A for the agreement from A to B.
> >
> >     >Note that if replication has been down for years, you will have
> >     to perform a manual >replica initialization procedure -
> >     replication will not automatically "catch up" if it has >been
> >     down that long.
> >
> > Rich - Thank you for the response. I was diverted to another urgent 
> > issue but have come back to this replication fix.
> >
> > I've confirmed that there are two Dedicated Consumer's (C and D) to 
> > go along with the two Dual Master's (A and B). I want to replicate to 
> > one of the dedicated consumers, C, prior to syncing the dual master 
> > B. I changed the passwords for dn:cn=replication,cn=config on A via 
> > the Directory Manager console, and via ldapmodify on C. I am 
> > confident that the passwords are the same on both systems.
>
>  >What exactly did you do?
>  >Note that you'll have to update the password in 
>  cn=replication,cn=config on the >consumer (C) and update the 
>  replication agreement on A for the replication agreement >between A 
>  and C.
>
>  Thanks for the reply Rich.  Yes, I updated the password on A and C.  I 
>  apologize as I left out the link in my below reference to section 
>  8.10.5.1 <http://8.10.5.1>;: 
>
> http://www.centos.org/docs/5/html/CDS/ag/8.0/Managing_Replication-Initial....
>  
>  I used bak2db with backup files from A.  After which, I see: "Unable 
>  to acquire replica: permission denied. The bind dn 
>  "cn=replication,cn=config" does not have permission to supply 
>  replication updates to the replica. Will retry later." on system A's 
>  error logs.. 
I think doing the restore is resetting the password.  After doing the

bak2db, change the passwords.
> >
> > >I followed section 8.10.5.1 on initializing the consumer replica 
> > from backup files and it >worked with the following:
> >
> > >[02/Apr/2012:11:58:03 -0700] - Add Attribute readonly Value off
> > >[02/Apr/2012:11:58:03 -0700] - Add Attribute nsslapd-directory Value 
> > /new/path/from/master/server
> > >[02/Apr/2012:11:58:04 -0700] - Del Attribute nsslapd-directory Value 
> > /old/path/from/consumer
> > >[02/Apr/2012:11:58:04 -0700] - WARNING!!: current Instance Config is 
> > different from backed up configuration; The backup is restored.
> >
> > >First, do I need to reset these attributes back to 'readonly' and 
> > the original nsslapd-directory?
> >
> > >Second, I am now receiving the following error from the master A:
> > >Unable to acquire replica: permission denied. The bind dn 
> > "cn=replication,cn=config" >does not have permission to supply 
> > replication updates to the replica. Will retry later.
> >
> > >On another note, I see plain text passwords in the error logs on A 
> > for the consumers >but passwd = 
> > {SSHA}0bgDq2f1IM/2nNOOIHUh8lXfkG13XUOHTYD== for B, the other >master. 
> > Is there specific reason for this?
> >
> > >As always, any guidance that can be provided is greatly appreciated.
> >
> > TIA,
> >
> > Herb
> >
> >>
> >>     >> 3. I assume that upon repairing replication (apparently it
> >>     has not been
> >>     working for several years) the systems will all replicate to the
> >>     most
> >>     recent information.  Correct?
> >>     >>>>I think that's the tricky part.  Make sure you backup
> your
> >>     directory on all
> >>     >>>>the LDAP first so you have something to roll back.  I
> >>     *believe* the last
> >>     >>>>step when setting up replication is initializing the
> >>     directory and that
> >>     >>>>will wipe out directory on the other LDAP.  Someone on the
> >>     list might  be
> >>     >>>>able to provide a better on this but I am just giving you a
> >>     heads up that
> >>     >>>>this can be a complicated process.
> >>
> >>     Given the fact that system B has not been running for some time,
> >>     ideally it would simply replicate to the current data on system
> >>     A.  After replication is reestablished the systems are set up to
> >>     "Always keep directories in sync".  If anyone can confirm the
> >>     behavior that will occur upon replication on these two systems
> >>     it would be greatly appreciated.
> >>
> >>     Thanks in advance,
> >>
> >>     Herb
> >>
> >>
> >>         ------------------------------
> >>
> >>         Message: 2
> >>         Date: Thu, 22 Mar 2012 10:40:34 -0400
> >>         From: Chun Tat David Chu <beyonddc.storage(a)gmail.com
> >>         <mailto:[e-mail]>>
> >>         To: "General discussion list for the 389 Directory server
> >>         project."
> >>         <389-users(a)lists.fedoraproject.org
> >>         <mailto:[e-mail]>>
> >>         Subject: Re: [389-users] Repair replication
> >>         Message-ID:
> >>         <CANCf8oLYKet99sB_ou4U3CER8U89UgwZhGUBTHekcF9HWNKL9g(a)mail.gmail.com
> >>        
> <mailto:[e-mail]>>
> >>         Content-Type: text/plain; charset="iso-8859-1"
> >>
> >>         Hey Herb,
> >>
> >>         You should refer to the Red Hat Directory Server
> >>         administration guide for
> >>         detail about setting up replication which you can locate in
> >>         here.
> >>         http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/
> >>
> >>         >> 1. How can I find out which system(s) is/are master,
> >>         consumer, hub, etc?
> >>         You should be able to determine the role of the Directory
> >>         Server for each
> >>         system by logging into the LDAP console under
> >>         "Configuration->Replication".  The role is either
> "Single
> >>         Master", "Hub" or
> >>         "Dedicated Consumer".
> >>
> >>         >> 2. How do I confirm that the systems have the correct
> >>         credentials for
> >>         replication? (I am receiving: "Unable to acquire replica:
> >>         Permission
> >>         denied.")
> >>            a. How can I change the bind dn
> >>         "cn=replication,cn=config" credentials
> >>         on each system to ensure replication will work?
> >>         You can do that on the console as well.  Just navigate down
> >>         the directory
> >>         tree and manually reset the password for the replication
> >>         user account.
> >>         There's a possibility that your replication user account's
> >>         password expired.
> >>
> >>         >> 3. I assume that upon repairing replication (apparently
> >>         it has not been
> >>         working for several years) the systems will all replicate to
> >>         the most
> >>         recent information.  Correct?
> >>         I think that's the tricky part.  Make sure you backup your
> >>         directory on all
> >>         the LDAP first so you have something to roll back.  I
> >>         *believe* the last
> >>         step when setting up replication is initializing the
> >>         directory and that
> >>         will wipe out directory on the other LDAP.  Someone on the
> >>         list might  be
> >>         able to provide a better on this but I am just giving you a
> >>         heads up that
> >>         this can be a complicated process.
> >>
> >>         Good luck
> >>
> >>         - David
> >>
> >>         2012/3/21 Herb Burnswell <herbert.burnswell(a)gmail.com
> >>         <mailto:[e-mail]>>
> >>
> >>         > Hi All,
> >>         >
> >>         > I'm new to LDAP administration and have been tasked with
> >>         fixing the system
> >>         > replication of 4 Linux systems running Fedora Directory
> >>         Services.  I am
> >>         > very comfortable working with Linux/Unix but am not
> >>         experienced with LDAP.
> >>         > I've been reading the communications from this user group
> >>         and reading as
> >>         > much as I can from documentation.  I believe this
> >>         environment is not too
> >>         > complex but I am looking for some guidance, any assistance
> >>         is greatly
> >>         > appreciated.
> >>         >
> >>         > Info:
> >>         >
> >>         > OS: Fedora Core 4
> >>         > LDAP: Fedora Directory Server v 7.1
> >>         >
> >>         > First, I know that both the systems and FDS versions are
> >>         ancient.
> >>         > However, at this point I need to get the replication
> >>         working prior to
> >>         > putting together a migration plan.  I have access to the
> >>         Directory Manager
> >>         > console and am comfortable running command line commands
> >>         as well.  Either
> >>         > way is fine.
> >>         >
> >>         > Questions:
> >>         >
> >>         > 1. How can I find out which system(s) is/are master,
> >>         consumer, hub, etc?
> >>         >
> >>         > 2. How do I confirm that the systems have the correct
> >>         credentials for
> >>         > replication? (I am receiving: "Unable to acquire replica:
> >>         Permission
> >>         > denied.")
> >>         >     a. How can I change the bind dn
> >>         "cn=replication,cn=config" credentials
> >>         > on each system to ensure replication will work?
> >>         >
> >>         > 3. I assume that upon repairing replication (apparently it
> >>         has not been
> >>         > working for several years) the systems will all replicate
> >>         to the most
> >>         > recent information.  Correct?
> >>         >
> >>         > Again, any guidance is greatly appreciated.
> >>         >
> >>         > Thanks in advance,
> >>         >
> >>         > Herb
> >>         >
> >>         > --
> >>         > 389 users mailing list
> >>         > 389-users(a)lists.fedoraproject.org
> >>         <mailto:[e-mail]>
> >>         > https://admin.fedoraproject.org/mailman/listinfo/389-users
> >>         >
> >>         -------------- next part --------------
> >>         An HTML attachment was scrubbed...
> >>         URL:
> >>        
> <http://lists.fedoraproject.org/pipermail/389-users/attachments/20120322/e...
> >>
> >>
> >>
> >>     --
> >>     389 users mailing list
> >>     389-users(a)lists.fedoraproject.org 
> <mailto:[e-mail]>
> >>     https://admin.fedoraproject.org/mailman/listinfo/389-users
> >
> >
> >
> >
> > --
> > 389 users mailing list
> > 389-users(a)lists.fedoraproject.org  <mailto:[e-mail]>
> > https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
>
>  --
>  389 users mailing list
>  389-users(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/389-users

Fwd: Fwd: Repair replication

[Herb Burnswell]

---------- Forwarded message ----------
From: Rich Megginson <rmeggins(a)redhat.com&gt;
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&gt;
Cc: Herb Burnswell <herbert.burnswell(a)gmail.com&gt;


 On 04/02/2012 05:48 PM, Herb Burnswell wrote:



---------- Forwarded message ----------
From: Rich Megginson <rmeggins(a)redhat.com&gt;
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&gt;
Cc: Herb Burnswell <herbert.burnswell(a)gmail.com&gt;


 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&gt;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 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&gt;
> > To: "General discussion list for the 389 Directory server project."
> >        <389-users(a)lists.fedoraproject.org&gt;
> > Subject: Re: [389-users] Repair replication
> > Message-ID:
> >        <
> > CANCf8oLYKet99sB_ou4U3CER8U89UgwZhGUBTHekcF9HWNKL9g(a)mail.gmail.com&gt;
> > 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&gt;
> >
> > > 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
> [e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>  

--
389 users mailing
[e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users





--
389 users mailing
[e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users

Repair replication

[Herb Burnswell]

---------- Forwarded message ----------
From: Rich Megginson <rmeggins(a)redhat.com&gt;
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&gt;
Cc: Herb Burnswell <herbert.burnswell(a)gmail.com&gt;


 On 04/02/2012 05:48 PM, Herb Burnswell wrote:



---------- Forwarded message ----------
From: Rich Megginson <rmeggins(a)redhat.com&gt;
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&gt;
Cc: Herb Burnswell <herbert.burnswell(a)gmail.com&gt;


 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&gt;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&gt;
> > To: "General discussion list for the 389 Directory server project."
> >        <389-users(a)lists.fedoraproject.org&gt;
> > Subject: Re: [389-users] Repair replication
> > Message-ID:
> >        <
> > CANCf8oLYKet99sB_ou4U3CER8U89UgwZhGUBTHekcF9HWNKL9g(a)mail.gmail.com&gt;
> > 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&gt;
> >
> > > 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
> [e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>  

--
389 users mailing
[e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users





--
389 users mailing
[e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users

Repair replication

[Jim Finn]

This can be caused by replication dn having an expired password.

On Tue, Apr 3, 2012 at 4:55 PM, Herb Burnswell
<herbert.burnswell(a)gmail.com&gt;wrote:

>  ---------- Forwarded message ----------
>  From: Rich Megginson <rmeggins(a)redhat.com&gt;
>   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&gt;
>  Cc: Herb Burnswell <herbert.burnswell(a)gmail.com&gt;
>
>
>   On 04/02/2012 05:48 PM, Herb Burnswell wrote:
>
>
>
>  ---------- Forwarded message ----------
>  From: Rich Megginson <rmeggins(a)redhat.com&gt;
>  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&gt;
>  Cc: Herb Burnswell <herbert.burnswell(a)gmail.com&gt;
>
>
>   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&gt;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&gt;
> >> To: "General discussion list for the 389 Directory server project."
> >>        <389-users(a)lists.fedoraproject.org&gt;
> >> Subject: Re: [389-users] Repair replication
> >> Message-ID:
> >>        <
> >> CANCf8oLYKet99sB_ou4U3CER8U89UgwZhGUBTHekcF9HWNKL9g(a)mail.gmail.com&gt;
> >> 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&gt;
> >>
> >> > 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
> [e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users
> >
> >
> >
>
>
>  --
>  389 users mailing
> [e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
>
>
>  --
>  389 users mailing
> [e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
>
>
>  --
>  389 users mailing list
>  389-users(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/389-users
>

Repair replication

[Herb Burnswell]

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?

Thanks,

Herb


On Tue, Apr 3, 2012 at 2:55 PM, Herb Burnswell
<herbert.burnswell(a)gmail.com&gt;wrote:

>  ---------- Forwarded message ----------
>  From: Rich Megginson <rmeggins(a)redhat.com&gt;
>   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&gt;
>  Cc: Herb Burnswell <herbert.burnswell(a)gmail.com&gt;
>
>
>   On 04/02/2012 05:48 PM, Herb Burnswell wrote:
>
>
>
>  ---------- Forwarded message ----------
>  From: Rich Megginson <rmeggins(a)redhat.com&gt;
>  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&gt;
>  Cc: Herb Burnswell <herbert.burnswell(a)gmail.com&gt;
>
>
>   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&gt;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&gt;
> >> To: "General discussion list for the 389 Directory server project."
> >>        <389-users(a)lists.fedoraproject.org&gt;
> >> Subject: Re: [389-users] Repair replication
> >> Message-ID:
> >>        <
> >> CANCf8oLYKet99sB_ou4U3CER8U89UgwZhGUBTHekcF9HWNKL9g(a)mail.gmail.com&gt;
> >> 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&gt;
> >>
> >> > 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
> [e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users
> >
> >
> >
>
>
>  --
>  389 users mailing
> [e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
>
>
>  --
>  389 users mailing
> [e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
>
>

Repair replication

[Rich Megginson]

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...
>  Thanks,
>
>  Herb
>
>
>  On Tue, Apr 3, 2012 at 2:55 PM, Herb Burnswell 
>  <herbert.burnswell(a)gmail.com <mailto:[e-mail]>> wrote:
>
>
>      ---------- Forwarded message ----------
>      From: *Rich Megginson* <rmeggins(a)redhat.com
>      <mailto:[e-mail]>>
>      Date: Mon, Apr 2, 2012 at 7:37 PM
>      Subject: Re: [389-users] Fwd: Repair replication
>      To: "General discussion list for the 389 Directory server
>      project." <389-users(a)lists.fedoraproject.org
>      <mailto:[e-mail]>>
>      Cc: Herb Burnswell <herbert.burnswell(a)gmail.com
>      <mailto:[e-mail]>>
>
>
>      On 04/02/2012 05:48 PM, Herb Burnswell wrote:
> >
> >
> >     ---------- Forwarded message ----------
> >     From: *Rich Megginson* <rmeggins(a)redhat.com
> >     <mailto:[e-mail]>>
> >     Date: Mon, Apr 2, 2012 at 3:23 PM
> >     Subject: Re: [389-users] Repair replication
> >     To: "General discussion list for the 389 Directory server
> >     project." <389-users(a)lists.fedoraproject.org
> >     <mailto:[e-mail]>>
> >     Cc: Herb Burnswell <herbert.burnswell(a)gmail.com
> >     <mailto:[e-mail]>>
> >
> >
> >     On 04/02/2012 04:13 PM, Herb Burnswell wrote:
> >>
> >>
> >>     On Fri, Mar 23, 2012 at 10:53 AM, Rich Megginson
> >>     <rmeggins(a)redhat.com <mailto:[e-mail]>> wrote:
> >>
> >>         On 03/23/2012 11:09 AM, Herb Burnswell wrote:
> >>>         Thanks for the reply David.
> >>>
> >>>         >> 1. How can I find out which system(s) is/are master,
> >>>         consumer, hub, etc?
> >>>         >>>>You should be able to determine the role of the
> >>>         Directory Server for each
> >>>         >>>>system by logging into the LDAP console under
> >>>         >>>>"Configuration->Replication".  The role
> is either
> >>>         "Single Master", "Hub" or
> >>>         >>>>"Dedicated Consumer".
> >>>
> >>>         >I was able to determine that we have two "Multiple
> Master"
> >>>         systems.  Let's call >them 'A' and 'B'. 
> System A has been
> >>>         the only system running for what appears to >be several
> >>>         years (it is being backed up nightly).  System B has been
> >>>         off for some >time but is running now.
> >>>
> >>>         >> 2. How do I confirm that the systems have the correct
> >>>         credentials for
> >>>         >replication? (I am receiving: "Unable to acquire replica:
> >>>         Permission
> >>>         >denied.")
> >>>         >a. How can I change the bind dn
> "cn=replication,cn=config"
> >>>         credentials
> >>>         >on each system to ensure replication will work?
> >>>         >>>>You can do that on the console as well.  Just
> navigate
> >>>         down the directory
> >>>         >>>>tree and manually reset the password for the
> >>>         replication user account.
> >>>         >>>>There's a possibility that your replication user
> >>>         account's password expired.
> >>>
> >>>         >I can navigate to the screen to reset the password for the
> >>>         replication user account.  I >have not reset the passwords
> >>>         yet as I am reading documentation to confirm that >system B
> >>>         will simply update it's data to system A's upon resuming
> >>>         replication.
> >>         >When you change the password of the replication user on B,
> >>         you'll also have to update >those credentials in the
> >>         replication agreement on A for the agreement from A to B.
> >>
> >>         >Note that if replication has been down for years, you will
> >>         have to perform a manual >replica initialization procedure -
> >>         replication will not automatically "catch up" if it has
> >>         >been down that long.
> >>
> >>     Rich - Thank you for the response. I was diverted to another
> >>     urgent issue but have come back to this replication fix.
> >>
> >>     I've confirmed that there are two Dedicated Consumer's (C and D)
> >>     to go along with the two Dual Master's (A and B). I want to
> >>     replicate to one of the dedicated consumers, C, prior to syncing
> >>     the dual master B. I changed the passwords for
> >>     dn:cn=replication,cn=config on A via the Directory Manager
> >>     console, and via ldapmodify on C. I am confident that the
> >>     passwords are the same on both systems.
> >
> >     >What exactly did you do?
> >     >Note that you'll have to update the password in
> >     cn=replication,cn=config on the >consumer (C) and update the
> >     replication agreement on A for the replication agreement >between
> >     A and C.
> >
> >     Thanks for the reply Rich.  Yes, I updated the password on A and
> >     C.  I apologize as I left out the link in my below reference to
> >     section 8.10.5.1 <http://8.10.5.1>;:
> >    
> http://www.centos.org/docs/5/html/CDS/ag/8.0/Managing_Replication-Initial....
>
> >     I used bak2db with backup files from A.  After which, I see:
> >     "Unable to acquire replica: permission denied. The bind dn
> >     "cn=replication,cn=config" does not have permission to supply
> >     replication updates to the replica. Will retry later." on system
> >     A's error logs..
>      >I think doing the restore is resetting the password.  After doing
>      the bak2db, change the >passwords.
>
>      Well, I'm kind of at a loss here.  I've reset the passwords on A
>      and C after doing the bak2db.  Same error:
>
>
>      Unable to acquire replica: permission denied. The bind dn
>      "cn=replication,cn=config" does not have permission to supply
>      replication updates to the replica. Will retry later.
>
>      Next, I removed and re-added the replication agreement on Master A
>      to Consumer C, same error above.
>
>      Is there any way that I can output the settings/password
>      information for cn=replication,cn=config on both A and C via the
>      command line to compare?  I have read that there needs to be a
>      'person' entry on the consumer for cn=replication,cn=config that
>      is used for the replication of the data.  Is there a way I can
>      confirm this configuration to ensure it is set up correctly?
>
>      I'm also seeing this error in the logs on consumer C:
>
>       NSMMReplicationPlugin - conn=2 op=9 replica="o=myTree": Unable to
>      acquire replica: error: permission denied
>
>
>
> >>
> >>     >I followed section 8.10.5.1 on initializing the consumer
> >>     replica from backup files and it >worked with the following:
> >>
> >>     >[02/Apr/2012:11:58:03 -0700] - Add Attribute readonly Value off
> >>     >[02/Apr/2012:11:58:03 -0700] - Add Attribute nsslapd-directory
> >>     Value /new/path/from/master/server
> >>     >[02/Apr/2012:11:58:04 -0700] - Del Attribute nsslapd-directory
> >>     Value /old/path/from/consumer
> >>     >[02/Apr/2012:11:58:04 -0700] - WARNING!!: current Instance
> >>     Config is different from backed up configuration; The backup is
> >>     restored.
> >>
> >>     >First, do I need to reset these attributes back to 'readonly'
> >>     and the original nsslapd-directory?
> >>
> >>     >Second, I am now receiving the following error from the master A:
> >>     >Unable to acquire replica: permission denied. The bind dn
> >>     "cn=replication,cn=config" >does not have permission to supply
> >>     replication updates to the replica. Will retry later.
> >>
> >>     >On another note, I see plain text passwords in the error logs
> >>     on A for the consumers >but passwd =
> >>     {SSHA}0bgDq2f1IM/2nNOOIHUh8lXfkG13XUOHTYD== for B, the other
> >>     >master. Is there specific reason for this?
> >>
> >>     >As always, any guidance that can be provided is greatly
> >>     appreciated.
> >>
> >>     TIA,
> >>
> >>     Herb
> >>
> >>>
> >>>         >> 3. I assume that upon repairing replication (apparently
> >>>         it has not been
> >>>         working for several years) the systems will all replicate
> >>>         to the most
> >>>         recent information.  Correct?
> >>>         >>>>I think that's the tricky part.  Make sure you
> backup
> >>>         your directory on all
> >>>         >>>>the LDAP first so you have something to roll back. 
> I
> >>>         *believe* the last
> >>>         >>>>step when setting up replication is initializing the
> >>>         directory and that
> >>>         >>>>will wipe out directory on the other LDAP.  Someone
> on
> >>>         the list might  be
> >>>         >>>>able to provide a better on this but I am just
> giving
> >>>         you a heads up that
> >>>         >>>>this can be a complicated process.
> >>>
> >>>         Given the fact that system B has not been running for some
> >>>         time, ideally it would simply replicate to the current data
> >>>         on system A.  After replication is reestablished the
> >>>         systems are set up to "Always keep directories in sync". 
> >>>         If anyone can confirm the behavior that will occur upon
> >>>         replication on these two systems it would be greatly
> >>>         appreciated.
> >>>
> >>>         Thanks in advance,
> >>>
> >>>         Herb
> >>>
> >>>
> >>>             ------------------------------
> >>>
> >>>             Message: 2
> >>>             Date: Thu, 22 Mar 2012 10:40:34 -0400
> >>>             From: Chun Tat David Chu <beyonddc.storage(a)gmail.com
> >>>             <mailto:[e-mail]>>
> >>>             To: "General discussion list for the 389 Directory
> >>>             server project."
> >>>             <389-users(a)lists.fedoraproject.org
> >>>             <mailto:[e-mail]>>
> >>>             Subject: Re: [389-users] Repair replication
> >>>             Message-ID:
> >>>            
> <CANCf8oLYKet99sB_ou4U3CER8U89UgwZhGUBTHekcF9HWNKL9g(a)mail.gmail.com
> >>>            
> <mailto:[e-mail]>>
> >>>             Content-Type: text/plain; charset="iso-8859-1"
> >>>
> >>>             Hey Herb,
> >>>
> >>>             You should refer to the Red Hat Directory Server
> >>>             administration guide for
> >>>             detail about setting up replication which you can
> >>>             locate in here.
> >>>             http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/
> >>>
> >>>             >> 1. How can I find out which system(s) is/are master,
> >>>             consumer, hub, etc?
> >>>             You should be able to determine the role of the
> >>>             Directory Server for each
> >>>             system by logging into the LDAP console under
> >>>             "Configuration->Replication".  The role is either
> >>>             "Single Master", "Hub" or
> >>>             "Dedicated Consumer".
> >>>
> >>>             >> 2. How do I confirm that the systems have the
> >>>             correct credentials for
> >>>             replication? (I am receiving: "Unable to acquire
> >>>             replica: Permission
> >>>             denied.")
> >>>                a. How can I change the bind dn
> >>>             "cn=replication,cn=config" credentials
> >>>             on each system to ensure replication will work?
> >>>             You can do that on the console as well.  Just navigate
> >>>             down the directory
> >>>             tree and manually reset the password for the
> >>>             replication user account.
> >>>             There's a possibility that your replication user
> >>>             account's password expired.
> >>>
> >>>             >> 3. I assume that upon repairing replication
> >>>             (apparently it has not been
> >>>             working for several years) the systems will all
> >>>             replicate to the most
> >>>             recent information.  Correct?
> >>>             I think that's the tricky part.  Make sure you backup
> >>>             your directory on all
> >>>             the LDAP first so you have something to roll back.  I
> >>>             *believe* the last
> >>>             step when setting up replication is initializing the
> >>>             directory and that
> >>>             will wipe out directory on the other LDAP.  Someone on
> >>>             the list might  be
> >>>             able to provide a better on this but I am just giving
> >>>             you a heads up that
> >>>             this can be a complicated process.
> >>>
> >>>             Good luck
> >>>
> >>>             - David
> >>>
> >>>             2012/3/21 Herb Burnswell <herbert.burnswell(a)gmail.com
> >>>             <mailto:[e-mail]>>
> >>>
> >>>             > Hi All,
> >>>             >
> >>>             > I'm new to LDAP administration and have been tasked
> >>>             with fixing the system
> >>>             > replication of 4 Linux systems running Fedora
> >>>             Directory Services.  I am
> >>>             > very comfortable working with Linux/Unix but am not
> >>>             experienced with LDAP.
> >>>             > I've been reading the communications from this user
> >>>             group and reading as
> >>>             > much as I can from documentation.  I believe this
> >>>             environment is not too
> >>>             > complex but I am looking for some guidance, any
> >>>             assistance is greatly
> >>>             > appreciated.
> >>>             >
> >>>             > Info:
> >>>             >
> >>>             > OS: Fedora Core 4
> >>>             > LDAP: Fedora Directory Server v 7.1
> >>>             >
> >>>             > First, I know that both the systems and FDS versions
> >>>             are ancient.
> >>>             > However, at this point I need to get the replication
> >>>             working prior to
> >>>             > putting together a migration plan.  I have access to
> >>>             the Directory Manager
> >>>             > console and am comfortable running command line
> >>>             commands as well.  Either
> >>>             > way is fine.
> >>>             >
> >>>             > Questions:
> >>>             >
> >>>             > 1. How can I find out which system(s) is/are master,
> >>>             consumer, hub, etc?
> >>>             >
> >>>             > 2. How do I confirm that the systems have the correct
> >>>             credentials for
> >>>             > replication? (I am receiving: "Unable to acquire
> >>>             replica: Permission
> >>>             > denied.")
> >>>             >     a. How can I change the bind dn
> >>>             "cn=replication,cn=config" credentials
> >>>             > on each system to ensure replication will work?
> >>>             >
> >>>             > 3. I assume that upon repairing replication
> >>>             (apparently it has not been
> >>>             > working for several years) the systems will all
> >>>             replicate to the most
> >>>             > recent information.  Correct?
> >>>             >
> >>>             > Again, any guidance is greatly appreciated.
> >>>             >
> >>>             > Thanks in advance,
> >>>             >
> >>>             > Herb
> >>>             >
> >>>             > --
> >>>             > 389 users mailing list
> >>>             > 389-users(a)lists.fedoraproject.org
> >>>             <mailto:[e-mail]>
> >>>             >
> >>>             https://admin.fedoraproject.org/mailman/listinfo/389-users
> >>>             >
> >>>             -------------- next part --------------
> >>>             An HTML attachment was scrubbed...
> >>>             URL:
> >>>            
> <http://lists.fedoraproject.org/pipermail/389-users/attachments/20120322/e...
> >>>
> >>>
> >>>
> >>>         --
> >>>         389 users mailing list
> >>>         389-users(a)lists.fedoraproject.org 
> <mailto:[e-mail]>
> >>>         https://admin.fedoraproject.org/mailman/listinfo/389-users
> >>
> >>
> >>
> >>
> >>     --
> >>     389 users mailing list
> >>     389-users(a)lists.fedoraproject.org 
> <mailto:[e-mail]>
> >>     https://admin.fedoraproject.org/mailman/listinfo/389-users
> >
> >
> >
> >
> >     --
> >     389 users mailing list
> >     389-users(a)lists.fedoraproject.org 
> <mailto:[e-mail]>
> >     https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
>

Repair replication

[Herb Burnswell]

On Thu, Apr 5, 2012 at 10:31 AM, Rich Megginson <rmeggins(a)redhat.com&gt; 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" and "the list of supplier DNs that
are
allowed to update
that replica"

Are these set in a specific file(s) that should be edited?

Thanks,

Herb

>  Thanks,
>
>  Herb
>
>
>  On Tue, Apr 3, 2012 at 2:55 PM, Herb Burnswell <
>  herbert.burnswell(a)gmail.com&gt; wrote:
>
> >
> >   ---------- Forwarded message ----------
> > From: Rich Megginson <rmeggins(a)redhat.com&gt;
> >   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&gt;
> > Cc: Herb Burnswell <herbert.burnswell(a)gmail.com&gt;
> >
> >
> >       On 04/02/2012 05:48 PM, Herb Burnswell wrote:
> >
> >
> >
> > ---------- Forwarded message ----------
> > From: Rich Megginson <rmeggins(a)redhat.com&gt;
> > 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&gt;
> > Cc: Herb Burnswell <herbert.burnswell(a)gmail.com&gt;
> >
> >
> >  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&gt;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&gt;
> >>> To: "General discussion list for the 389 Directory server
> project."
> >>>        <389-users(a)lists.fedoraproject.org&gt;
> >>> Subject: Re: [389-users] Repair replication
> >>> Message-ID:
> >>>        <
> >>> CANCf8oLYKet99sB_ou4U3CER8U89UgwZhGUBTHekcF9HWNKL9g(a)mail.gmail.com&gt;
> >>> 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&gt;
> >>>
> >>> > 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
> [e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users
> >>
> >>
> >>
> >
> >
> > --
> > 389 users mailing
> [e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users
> >
> >
> >
> >
> >
> > --
> > 389 users mailing
> [e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users
> >
> >
> >
> >
> >
>
>

Repair replication

[Rich Megginson]

On 04/05/2012 11:43 AM, Herb Burnswell wrote:
>  On Thu, Apr 5, 2012 at 10:31 AM, Rich Megginson <rmeggins(a)redhat.com 
>  <mailto:[e-mail]>> wrote:
>
>      On 04/05/2012 11:31 AM, Herb Burnswell wrote:
> >     Rich,
> >
> >     I found a thread that you helped someone with a while back and it
> >     seems to be the exact problem that I am facing:
> >
> >    
> http://www.linux-archive.org/general-discussion-list-389-directory-server...
> >
> >     You mention:
> >
> >     Did you add cn=replication manager,cn=config to the consumer's
> >     replica
> >     config entry, to the list of supplier DNs that are allowed to update
> >     that replica?
> >
> >     Is this config entry in the dse.ldif file?  The link that the
> >     person used as a guide doesn't seem to be working now.  Can you
> >     point me to how configure this correctly in the appropriate files?
>      I think they moved the docs around.  Use the 9.0 doc anyway.
>     
> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Admin...
>
>      specifically
>     
> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Admin...
>      or
>     
> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Admin...
>
>
>
>  Thank you, I'll read the documentation.  Can you clarify what you mean 
>  when you say:
>
>  "consumer's replica config entry" 
the cn=replica,cn=YOUR
SUFFIX,cn=mapping tree,cn=config entry on the 
consumer
>  and "the list of supplier DNs that are allowed to update
>  that replica"
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Confi...
>  Are these set in a specific file(s) that should be edited? 
The dse.ldif file - but
don't edit that file directly unless necessary - 
use the console or ldapmodify/ldapsearch
>  Thanks,
>
>  Herb
>
> >
> >     Thanks,
> >
> >     Herb
> >
> >
> >     On Tue, Apr 3, 2012 at 2:55 PM, Herb Burnswell
> >     <herbert.burnswell(a)gmail.com
> >     <mailto:[e-mail]>> wrote:
> >
> >
> >         ---------- Forwarded message ----------
> >         From: *Rich Megginson* <rmeggins(a)redhat.com
> >         <mailto:[e-mail]>>
> >         Date: Mon, Apr 2, 2012 at 7:37 PM
> >         Subject: Re: [389-users] Fwd: Repair replication
> >         To: "General discussion list for the 389 Directory server
> >         project." <389-users(a)lists.fedoraproject.org
> >         <mailto:[e-mail]>>
> >         Cc: Herb Burnswell <herbert.burnswell(a)gmail.com
> >         <mailto:[e-mail]>>
> >
> >
> >         On 04/02/2012 05:48 PM, Herb Burnswell wrote:
> >>
> >>
> >>         ---------- Forwarded message ----------
> >>         From: *Rich Megginson* <rmeggins(a)redhat.com
> >>         <mailto:[e-mail]>>
> >>         Date: Mon, Apr 2, 2012 at 3:23 PM
> >>         Subject: Re: [389-users] Repair replication
> >>         To: "General discussion list for the 389 Directory server
> >>         project." <389-users(a)lists.fedoraproject.org
> >>         <mailto:[e-mail]>>
> >>         Cc: Herb Burnswell <herbert.burnswell(a)gmail.com
> >>         <mailto:[e-mail]>>
> >>
> >>
> >>         On 04/02/2012 04:13 PM, Herb Burnswell wrote:
> >>>
> >>>
> >>>         On Fri, Mar 23, 2012 at 10:53 AM, Rich Megginson
> >>>         <rmeggins(a)redhat.com <mailto:[e-mail]>>
> wrote:
> >>>
> >>>             On 03/23/2012 11:09 AM, Herb Burnswell wrote:
> >>>>             Thanks for the reply David.
> >>>>
> >>>>             >> 1. How can I find out which system(s) is/are
> >>>>             master, consumer, hub, etc?
> >>>>             >>>>You should be able to determine the role of
> the
> >>>>             Directory Server for each
> >>>>             >>>>system by logging into the LDAP console
> under
> >>>>             >>>>"Configuration->Replication". 
> The role is either
> >>>>             "Single Master", "Hub" or
> >>>>             >>>>"Dedicated Consumer".
> >>>>
> >>>>             >I was able to determine that we have two "Multiple
> >>>>             Master" systems.  Let's call >them 'A'
> and 'B'. 
> >>>>             System A has been the only system running for what
> >>>>             appears to >be several years (it is being backed up
> >>>>             nightly).  System B has been off for some >time but is
> >>>>             running now.
> >>>>
> >>>>             >> 2. How do I confirm that the systems have the
> >>>>             correct credentials for
> >>>>             >replication? (I am receiving: "Unable to acquire
> >>>>             replica: Permission
> >>>>             >denied.")
> >>>>             >a. How can I change the bind dn
> >>>>             "cn=replication,cn=config" credentials
> >>>>             >on each system to ensure replication will work?
> >>>>             >>>>You can do that on the console as well. 
> Just
> >>>>             navigate down the directory
> >>>>             >>>>tree and manually reset the password for the
> >>>>             replication user account.
> >>>>             >>>>There's a possibility that your
> replication user
> >>>>             account's password expired.
> >>>>
> >>>>             >I can navigate to the screen to reset the password
> >>>>             for the replication user account.  I >have not reset
> >>>>             the passwords yet as I am reading documentation to
> >>>>             confirm that >system B will simply update it's data
> to
> >>>>             system A's upon resuming replication.
> >>>             >When you change the password of the replication user
> >>>             on B, you'll also have to update >those credentials in
> >>>             the replication agreement on A for the agreement from A
> >>>             to B.
> >>>
> >>>             >Note that if replication has been down for years, you
> >>>             will have to perform a manual >replica initialization
> >>>             procedure - replication will not automatically "catch
> >>>             up" if it has >been down that long.
> >>>
> >>>         Rich - Thank you for the response. I was diverted to
> >>>         another urgent issue but have come back to this replication
> >>>         fix.
> >>>
> >>>         I've confirmed that there are two Dedicated Consumer's (C
> >>>         and D) to go along with the two Dual Master's (A and B). I
> >>>         want to replicate to one of the dedicated consumers, C,
> >>>         prior to syncing the dual master B. I changed the passwords
> >>>         for dn:cn=replication,cn=config on A via the Directory
> >>>         Manager console, and via ldapmodify on C. I am confident
> >>>         that the passwords are the same on both systems.
> >>
> >>         >What exactly did you do?
> >>         >Note that you'll have to update the password in
> >>         cn=replication,cn=config on the >consumer (C) and update the
> >>         replication agreement on A for the replication agreement
> >>         >between A and C.
> >>
> >>         Thanks for the reply Rich.  Yes, I updated the password on A
> >>         and C.  I apologize as I left out the link in my below
> >>         reference to section 8.10.5.1 <http://8.10.5.1>;:
> >>        
> http://www.centos.org/docs/5/html/CDS/ag/8.0/Managing_Replication-Initial....
>
> >>         I used bak2db with backup files from A.  After which, I see:
> >>         "Unable to acquire replica: permission denied. The bind dn
> >>         "cn=replication,cn=config" does not have permission to
> >>         supply replication updates to the replica. Will retry
> >>         later." on system A's error logs..
> >         >I think doing the restore is resetting the password.  After
> >         doing the bak2db, change the >passwords.
> >
> >         Well, I'm kind of at a loss here.  I've reset the passwords
> >         on A and C after doing the bak2db.  Same error:
> >
> >
> >         Unable to acquire replica: permission denied. The bind dn
> >         "cn=replication,cn=config" does not have permission to supply
> >         replication updates to the replica. Will retry later.
> >
> >         Next, I removed and re-added the replication agreement on
> >         Master A to Consumer C, same error above.
> >
> >         Is there any way that I can output the settings/password
> >         information for cn=replication,cn=config on both A and C via
> >         the command line to compare?  I have read that there needs to
> >         be a 'person' entry on the consumer for
> >         cn=replication,cn=config that is used for the replication of
> >         the data.  Is there a way I can confirm this configuration to
> >         ensure it is set up correctly?
> >
> >         I'm also seeing this error in the logs on consumer C:
> >
> >          NSMMReplicationPlugin - conn=2 op=9 replica="o=myTree":
> >         Unable to acquire replica: error: permission denied
> >
> >
> >
> >>>
> >>>         >I followed section 8.10.5.1 on initializing the consumer
> >>>         replica from backup files and it >worked with the following:
> >>>
> >>>         >[02/Apr/2012:11:58:03 -0700] - Add Attribute readonly
> >>>         Value off
> >>>         >[02/Apr/2012:11:58:03 -0700] - Add Attribute
> >>>         nsslapd-directory Value /new/path/from/master/server
> >>>         >[02/Apr/2012:11:58:04 -0700] - Del Attribute
> >>>         nsslapd-directory Value /old/path/from/consumer
> >>>         >[02/Apr/2012:11:58:04 -0700] - WARNING!!: current Instance
> >>>         Config is different from backed up configuration; The
> >>>         backup is restored.
> >>>
> >>>         >First, do I need to reset these attributes back to
> >>>         'readonly' and the original nsslapd-directory?
> >>>
> >>>         >Second, I am now receiving the following error from the
> >>>         master A:
> >>>         >Unable to acquire replica: permission denied. The bind dn
> >>>         "cn=replication,cn=config" >does not have permission to
> >>>         supply replication updates to the replica. Will retry later.
> >>>
> >>>         >On another note, I see plain text passwords in the error
> >>>         logs on A for the consumers >but passwd =
> >>>         {SSHA}0bgDq2f1IM/2nNOOIHUh8lXfkG13XUOHTYD== for B, the
> >>>         other >master. Is there specific reason for this?
> >>>
> >>>         >As always, any guidance that can be provided is greatly
> >>>         appreciated.
> >>>
> >>>         TIA,
> >>>
> >>>         Herb
> >>>
> >>>>
> >>>>             >> 3. I assume that upon repairing replication
> >>>>             (apparently it has not been
> >>>>             working for several years) the systems will all
> >>>>             replicate to the most
> >>>>             recent information.  Correct?
> >>>>             >>>>I think that's the tricky part.  Make
> sure you
> >>>>             backup your directory on all
> >>>>             >>>>the LDAP first so you have something to roll
> back.
> >>>>              I *believe* the last
> >>>>             >>>>step when setting up replication is
> initializing
> >>>>             the directory and that
> >>>>             >>>>will wipe out directory on the other LDAP.
> >>>>              Someone on the list might  be
> >>>>             >>>>able to provide a better on this but I am
> just
> >>>>             giving you a heads up that
> >>>>             >>>>this can be a complicated process.
> >>>>
> >>>>             Given the fact that system B has not been running for
> >>>>             some time, ideally it would simply replicate to the
> >>>>             current data on system A.  After replication is
> >>>>             reestablished the systems are set up to "Always keep
> >>>>             directories in sync".  If anyone can confirm the
> >>>>             behavior that will occur upon replication on these two
> >>>>             systems it would be greatly appreciated.
> >>>>
> >>>>             Thanks in advance,
> >>>>
> >>>>             Herb
> >>>>
> >>>>
> >>>>                 ------------------------------
> >>>>
> >>>>                 Message: 2
> >>>>                 Date: Thu, 22 Mar 2012 10:40:34 -0400
> >>>>                 From: Chun Tat David Chu
> >>>>                 <beyonddc.storage(a)gmail.com
> >>>>                 <mailto:[e-mail]>>
> >>>>                 To: "General discussion list for the 389 Directory
> >>>>                 server project."
> >>>>                 <389-users(a)lists.fedoraproject.org
> >>>>                 <mailto:[e-mail]>>
> >>>>                 Subject: Re: [389-users] Repair replication
> >>>>                 Message-ID:
> >>>>                
> <CANCf8oLYKet99sB_ou4U3CER8U89UgwZhGUBTHekcF9HWNKL9g(a)mail.gmail.com
> >>>>                
> <mailto:[e-mail]>>
> >>>>                 Content-Type: text/plain; charset="iso-8859-1"
> >>>>
> >>>>                 Hey Herb,
> >>>>
> >>>>                 You should refer to the Red Hat Directory Server
> >>>>                 administration guide for
> >>>>                 detail about setting up replication which you can
> >>>>                 locate in here.
> >>>>                
> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/
> >>>>
> >>>>                 >> 1. How can I find out which system(s) is/are
> >>>>                 master, consumer, hub, etc?
> >>>>                 You should be able to determine the role of the
> >>>>                 Directory Server for each
> >>>>                 system by logging into the LDAP console under
> >>>>                 "Configuration->Replication".  The role is
> either
> >>>>                 "Single Master", "Hub" or
> >>>>                 "Dedicated Consumer".
> >>>>
> >>>>                 >> 2. How do I confirm that the systems have the
> >>>>                 correct credentials for
> >>>>                 replication? (I am receiving: "Unable to acquire
> >>>>                 replica: Permission
> >>>>                 denied.")
> >>>>                    a. How can I change the bind dn
> >>>>                 "cn=replication,cn=config" credentials
> >>>>                 on each system to ensure replication will work?
> >>>>                 You can do that on the console as well.  Just
> >>>>                 navigate down the directory
> >>>>                 tree and manually reset the password for the
> >>>>                 replication user account.
> >>>>                 There's a possibility that your replication user
> >>>>                 account's password expired.
> >>>>
> >>>>                 >> 3. I assume that upon repairing replication
> >>>>                 (apparently it has not been
> >>>>                 working for several years) the systems will all
> >>>>                 replicate to the most
> >>>>                 recent information.  Correct?
> >>>>                 I think that's the tricky part.  Make sure you
> >>>>                 backup your directory on all
> >>>>                 the LDAP first so you have something to roll back.
> >>>>                  I *believe* the last
> >>>>                 step when setting up replication is initializing
> >>>>                 the directory and that
> >>>>                 will wipe out directory on the other LDAP.
> >>>>                  Someone on the list might  be
> >>>>                 able to provide a better on this but I am just
> >>>>                 giving you a heads up that
> >>>>                 this can be a complicated process.
> >>>>
> >>>>                 Good luck
> >>>>
> >>>>                 - David
> >>>>
> >>>>                 2012/3/21 Herb Burnswell
> >>>>                 <herbert.burnswell(a)gmail.com
> >>>>                 <mailto:[e-mail]>>
> >>>>
> >>>>                 > Hi All,
> >>>>                 >
> >>>>                 > I'm new to LDAP administration and have been
> >>>>                 tasked with fixing the system
> >>>>                 > replication of 4 Linux systems running Fedora
> >>>>                 Directory Services.  I am
> >>>>                 > very comfortable working with Linux/Unix but am
> >>>>                 not experienced with LDAP.
> >>>>                 > I've been reading the communications from this
> >>>>                 user group and reading as
> >>>>                 > much as I can from documentation.  I believe
> >>>>                 this environment is not too
> >>>>                 > complex but I am looking for some guidance, any
> >>>>                 assistance is greatly
> >>>>                 > appreciated.
> >>>>                 >
> >>>>                 > Info:
> >>>>                 >
> >>>>                 > OS: Fedora Core 4
> >>>>                 > LDAP: Fedora Directory Server v 7.1
> >>>>                 >
> >>>>                 > First, I know that both the systems and FDS
> >>>>                 versions are ancient.
> >>>>                 > However, at this point I need to get the
> >>>>                 replication working prior to
> >>>>                 > putting together a migration plan.  I have
> >>>>                 access to the Directory Manager
> >>>>                 > console and am comfortable running command line
> >>>>                 commands as well.  Either
> >>>>                 > way is fine.
> >>>>                 >
> >>>>                 > Questions:
> >>>>                 >
> >>>>                 > 1. How can I find out which system(s) is/are
> >>>>                 master, consumer, hub, etc?
> >>>>                 >
> >>>>                 > 2. How do I confirm that the systems have the
> >>>>                 correct credentials for
> >>>>                 > replication? (I am receiving: "Unable to
> acquire
> >>>>                 replica: Permission
> >>>>                 > denied.")
> >>>>                 >     a. How can I change the bind dn
> >>>>                 "cn=replication,cn=config" credentials
> >>>>                 > on each system to ensure replication will work?
> >>>>                 >
> >>>>                 > 3. I assume that upon repairing replication
> >>>>                 (apparently it has not been
> >>>>                 > working for several years) the systems will all
> >>>>                 replicate to the most
> >>>>                 > recent information.  Correct?
> >>>>                 >
> >>>>                 > Again, any guidance is greatly appreciated.
> >>>>                 >
> >>>>                 > Thanks in advance,
> >>>>                 >
> >>>>                 > Herb
> >>>>                 >
> >>>>                 > --
> >>>>                 > 389 users mailing list
> >>>>                 > 389-users(a)lists.fedoraproject.org
> >>>>                 <mailto:[e-mail]>
> >>>>                 >
> >>>>                
> https://admin.fedoraproject.org/mailman/listinfo/389-users
> >>>>                 >
> >>>>                 -------------- next part --------------
> >>>>                 An HTML attachment was scrubbed...
> >>>>                 URL:
> >>>>                
> <http://lists.fedoraproject.org/pipermail/389-users/attachments/20120322/e...
> >>>>
> >>>>
> >>>>
> >>>>             --
> >>>>             389 users mailing list
> >>>>             389-users(a)lists.fedoraproject.org 
> <mailto:[e-mail]>
> >>>>             https://admin.fedoraproject.org/mailman/listinfo/389-users
> >>>
> >>>
> >>>
> >>>
> >>>         --
> >>>         389 users mailing list
> >>>         389-users(a)lists.fedoraproject.org 
> <mailto:[e-mail]>
> >>>         https://admin.fedoraproject.org/mailman/listinfo/389-users
> >>
> >>
> >>
> >>
> >>         --
> >>         389 users mailing list
> >>         389-users(a)lists.fedoraproject.org 
> <mailto:[e-mail]>
> >>         https://admin.fedoraproject.org/mailman/listinfo/389-users
> >
> >
> >
> >
>
>

Repair replication

[Herb Burnswell]

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>
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&gt; 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&gt;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&gt; wrote:
> >
> >>
> >>   ---------- Forwarded message ----------
> >> From: Rich Megginson <rmeggins(a)redhat.com&gt;
> >>   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&gt;
> >> Cc: Herb Burnswell <herbert.burnswell(a)gmail.com&gt;
> >>
> >>
> >>       On 04/02/2012 05:48 PM, Herb Burnswell wrote:
> >>
> >>
> >>
> >> ---------- Forwarded message ----------
> >> From: Rich Megginson <rmeggins(a)redhat.com&gt;
> >> 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&gt;
> >> Cc: Herb Burnswell <herbert.burnswell(a)gmail.com&gt;
> >>
> >>
> >>  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&gt;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&gt;
> >>>> To: "General discussion list for the 389 Directory server
> project."
> >>>>        <389-users(a)lists.fedoraproject.org&gt;
> >>>> Subject: Re: [389-users] Repair replication
> >>>> Message-ID:
> >>>>        <
> >>>> CANCf8oLYKet99sB_ou4U3CER8U89UgwZhGUBTHekcF9HWNKL9g(a)mail.gmail.com&gt;
> >>>> 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&gt;
> >>>>
> >>>> > 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
> [e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >> 389 users mailing
> [e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users
> >>
> >>
> >>
> >>
> >>
> >> --
> >> 389 users mailing
> [e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users
> >>
> >>
> >>
> >>
> >>
> >
> >
>
>

Repair replication

[Rich Megginson]

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?

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

Repair replication

[Herb Burnswell]

On Tue, Apr 10, 2012 at 1:03 PM, Rich Megginson <rmeggins(a)redhat.com&gt; 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?

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&gt;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&gt;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&gt; wrote:
> >>
> >>>
> >>>   ---------- Forwarded message ----------
> >>> From: Rich Megginson <rmeggins(a)redhat.com&gt;
> >>>   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&gt;
> >>> Cc: Herb Burnswell <herbert.burnswell(a)gmail.com&gt;
> >>>
> >>>
> >>>       On 04/02/2012 05:48 PM, Herb Burnswell wrote:
> >>>
> >>>
> >>>
> >>> ---------- Forwarded message ----------
> >>> From: Rich Megginson <rmeggins(a)redhat.com&gt;
> >>> 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&gt;
> >>> Cc: Herb Burnswell <herbert.burnswell(a)gmail.com&gt;
> >>>
> >>>
> >>>  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&gt;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&gt;
> >>>>> To: "General discussion list for the 389 Directory server
> project."
> >>>>>        <389-users(a)lists.fedoraproject.org&gt;
> >>>>> Subject: Re: [389-users] Repair replication
> >>>>> Message-ID:
> >>>>>        <
> >>>>>
> CANCf8oLYKet99sB_ou4U3CER8U89UgwZhGUBTHekcF9HWNKL9g(a)mail.gmail.com&gt;
> >>>>> 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&gt;
> >>>>>
> >>>>> > 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
> [e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> 389 users mailing
> [e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> 389 users mailing
> [e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
>
>

Repair replication

[Rich Megginson]

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 
>  <mailto:[e-mail]>> 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 <mailto:[e-mail]>> wrote:
> >
> >         On 04/05/2012 11:43 AM, Herb Burnswell wrote:
> >>
> >>
> >>         On Thu, Apr 5, 2012 at 10:31 AM, Rich Megginson
> >>         <rmeggins(a)redhat.com <mailto:[e-mail]>> wrote:
> >>
> >>             On 04/05/2012 11:31 AM, Herb Burnswell wrote:
> >>>             Rich,
> >>>
> >>>             I found a thread that you helped someone with a while
> >>>             back and it seems to be the exact problem that I am
> >>>             facing:
> >>>
> >>>            
> http://www.linux-archive.org/general-discussion-list-389-directory-server...
> >>>
> >>>             You mention:
> >>>
> >>>             Did you add cn=replication manager,cn=config to the
> >>>             consumer's replica
> >>>             config entry, to the list of supplier DNs that are
> >>>             allowed to update
> >>>             that replica?
> >>>
> >>>             Is this config entry in the dse.ldif file?  The link
> >>>             that the person used as a guide doesn't seem to be
> >>>             working now.  Can you point me to how configure this
> >>>             correctly in the appropriate files?
> >>             I think they moved the docs around.  Use the 9.0 doc anyway.
> >>            
> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Admin...
> >>
> >>             specifically
> >>            
> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Admin...
> >>             or
> >>            
> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Admin...
> >>
> >>
> >>
> >>         Thank you, I'll read the documentation.  Can you clarify
> >>         what you mean when you say:
> >>
> >>         "consumer's replica config entry"
> >         the cn=replica,cn=YOUR SUFFIX,cn=mapping tree,cn=config entry
> >         on the consumer
> >
> >>         and "the list of supplier DNs that are allowed to update
> >>         that replica"
> >        
> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Confi...
> >
> >
> >>
> >>         Are these set in a specific file(s) that should be edited?
> >         The dse.ldif file - but don't edit that file directly unless
> >         necessary - use the console or ldapmodify/ldapsearch
> >
> >>
> >>         Thanks,
> >>
> >>         Herb
> >>
> >>>
> >>>             Thanks,
> >>>
> >>>             Herb
> >>>
> >>>
> >>>             On Tue, Apr 3, 2012 at 2:55 PM, Herb Burnswell
> >>>             <herbert.burnswell(a)gmail.com
> >>>             <mailto:[e-mail]>> wrote:
> >>>
> >>>
> >>>                 ---------- Forwarded message ----------
> >>>                 From: *Rich Megginson* <rmeggins(a)redhat.com
> >>>                 <mailto:[e-mail]>>
> >>>                 Date: Mon, Apr 2, 2012 at 7:37 PM
> >>>                 Subject: Re: [389-users] Fwd: Repair replication
> >>>                 To: "General discussion list for the 389 Directory
> >>>                 server project." <389-users(a)lists.fedoraproject.org
> >>>                 <mailto:[e-mail]>>
> >>>                 Cc: Herb Burnswell <herbert.burnswell(a)gmail.com
> >>>                 <mailto:[e-mail]>>
> >>>
> >>>
> >>>                 On 04/02/2012 05:48 PM, Herb Burnswell wrote:
> >>>>
> >>>>
> >>>>                 ---------- Forwarded message ----------
> >>>>                 From: *Rich Megginson* <rmeggins(a)redhat.com
> >>>>                 <mailto:[e-mail]>>
> >>>>                 Date: Mon, Apr 2, 2012 at 3:23 PM
> >>>>                 Subject: Re: [389-users] Repair replication
> >>>>                 To: "General discussion list for the 389 Directory
> >>>>                 server project."
> >>>>                 <389-users(a)lists.fedoraproject.org
> >>>>                 <mailto:[e-mail]>>
> >>>>                 Cc: Herb Burnswell <herbert.burnswell(a)gmail.com
> >>>>                 <mailto:[e-mail]>>
> >>>>
> >>>>
> >>>>                 On 04/02/2012 04:13 PM, Herb Burnswell wrote:
> >>>>>
> >>>>>
> >>>>>                 On Fri, Mar 23, 2012 at 10:53 AM, Rich Megginson
> >>>>>                 <rmeggins(a)redhat.com
> >>>>>                 <mailto:[e-mail]>> wrote:
> >>>>>
> >>>>>                     On 03/23/2012 11:09 AM, Herb Burnswell wrote:
> >>>>>>                     Thanks for the reply David.
> >>>>>>
> >>>>>>                     >> 1. How can I find out which
> system(s)
> >>>>>>                     is/are master, consumer, hub, etc?
> >>>>>>                     >>>>You should be able to
> determine the role
> >>>>>>                     of the Directory Server for each
> >>>>>>                     >>>>system by logging into the
> LDAP console
> >>>>>>                     under
> >>>>>>                    
> >>>>"Configuration->Replication".  The role
> >>>>>>                     is either "Single Master",
> "Hub" or
> >>>>>>                     >>>>"Dedicated
> Consumer".
> >>>>>>
> >>>>>>                     >I was able to determine that we have two
> >>>>>>                     "Multiple Master" systems. 
> Let's call >them
> >>>>>>                     'A' and 'B'.  System A has
> been the only
> >>>>>>                     system running for what appears to >be
> >>>>>>                     several years (it is being backed up
> >>>>>>                     nightly).  System B has been off for some
> >>>>>>                     >time but is running now.
> >>>>>>
> >>>>>>                     >> 2. How do I confirm that the systems
> have
> >>>>>>                     the correct credentials for
> >>>>>>                     >replication? (I am receiving:
> "Unable to
> >>>>>>                     acquire replica: Permission
> >>>>>>                     >denied.")
> >>>>>>                     >a. How can I change the bind dn
> >>>>>>                     "cn=replication,cn=config"
> credentials
> >>>>>>                     >on each system to ensure replication will
> work?
> >>>>>>                     >>>>You can do that on the
> console as well.
> >>>>>>                      Just navigate down the directory
> >>>>>>                     >>>>tree and manually reset the
> password for
> >>>>>>                     the replication user account.
> >>>>>>                     >>>>There's a possibility
> that your
> >>>>>>                     replication user account's password
> expired.
> >>>>>>
> >>>>>>                     >I can navigate to the screen to reset
> the
> >>>>>>                     password for the replication user account. 
> >>>>>>                     I >have not reset the passwords yet as I
> am
> >>>>>>                     reading documentation to confirm that
> >>>>>>                     >system B will simply update it's data
> to
> >>>>>>                     system A's upon resuming replication.
> >>>>>                     >When you change the password of the
> >>>>>                     replication user on B, you'll also have to
> >>>>>                     update >those credentials in the replication
> >>>>>                     agreement on A for the agreement from A to B.
> >>>>>
> >>>>>                     >Note that if replication has been down for
> >>>>>                     years, you will have to perform a manual
> >>>>>                     >replica initialization procedure -
> >>>>>                     replication will not automatically "catch
> up"
> >>>>>                     if it has >been down that long.
> >>>>>
> >>>>>                 Rich - Thank you for the response. I was diverted
> >>>>>                 to another urgent issue but have come back to
> >>>>>                 this replication fix.
> >>>>>
> >>>>>                 I've confirmed that there are two Dedicated
> >>>>>                 Consumer's (C and D) to go along with the two
> >>>>>                 Dual Master's (A and B). I want to replicate to
> >>>>>                 one of the dedicated consumers, C, prior to
> >>>>>                 syncing the dual master B. I changed the
> >>>>>                 passwords for dn:cn=replication,cn=config on A
> >>>>>                 via the Directory Manager console, and via
> >>>>>                 ldapmodify on C. I am confident that the
> >>>>>                 passwords are the same on both systems.
> >>>>
> >>>>                 >What exactly did you do?
> >>>>                 >Note that you'll have to update the password in
> >>>>                 cn=replication,cn=config on the >consumer (C) and
> >>>>                 update the replication agreement on A for the
> >>>>                 replication agreement >between A and C.
> >>>>
> >>>>                 Thanks for the reply Rich.  Yes, I updated the
> >>>>                 password on A and C.  I apologize as I left out
> >>>>                 the link in my below reference to section 8.10.5.1
> >>>>                 <http://8.10.5.1>;:
> >>>>                
> http://www.centos.org/docs/5/html/CDS/ag/8.0/Managing_Replication-Initial....
>
> >>>>                 I used bak2db with backup files from A.  After
> >>>>                 which, I see: "Unable to acquire replica:
> >>>>                 permission denied. The bind dn
> >>>>                 "cn=replication,cn=config" does not have
> >>>>                 permission to supply replication updates to the
> >>>>                 replica. Will retry later." on system A's error
> >>>>                 logs..
> >>>                 >I think doing the restore is resetting the
> >>>                 password.  After doing the bak2db, change the
> >>>                 >passwords.
> >>>
> >>>                 Well, I'm kind of at a loss here.  I've reset the
> >>>                 passwords on A and C after doing the bak2db.  Same
> >>>                 error:
> >>>
> >>>
> >>>                 Unable to acquire replica: permission denied. The
> >>>                 bind dn "cn=replication,cn=config" does not have
> >>>                 permission to supply replication updates to the
> >>>                 replica. Will retry later.
> >>>
> >>>                 Next, I removed and re-added the replication
> >>>                 agreement on Master A to Consumer C, same error above.
> >>>
> >>>                 Is there any way that I can output the
> >>>                 settings/password information for
> >>>                 cn=replication,cn=config on both A and C via the
> >>>                 command line to compare?  I have read that there
> >>>                 needs to be a 'person' entry on the consumer for
> >>>                 cn=replication,cn=config that is used for the
> >>>                 replication of the data.  Is there a way I can
> >>>                 confirm this configuration to ensure it is set up
> >>>                 correctly?
> >>>
> >>>                 I'm also seeing this error in the logs on consumer C:
> >>>
> >>>                  NSMMReplicationPlugin - conn=2 op=9
> >>>                 replica="o=myTree": Unable to acquire replica:
> >>>                 error: permission denied
> >>>
> >>>
> >>>
> >>>>>
> >>>>>                 >I followed section 8.10.5.1 on initializing the
> >>>>>                 consumer replica from backup files and it >worked
> >>>>>                 with the following:
> >>>>>
> >>>>>                 >[02/Apr/2012:11:58:03 -0700] - Add Attribute
> >>>>>                 readonly Value off
> >>>>>                 >[02/Apr/2012:11:58:03 -0700] - Add Attribute
> >>>>>                 nsslapd-directory Value /new/path/from/master/server
> >>>>>                 >[02/Apr/2012:11:58:04 -0700] - Del Attribute
> >>>>>                 nsslapd-directory Value /old/path/from/consumer
> >>>>>                 >[02/Apr/2012:11:58:04 -0700] - WARNING!!:
> >>>>>                 current Instance Config is different from backed
> >>>>>                 up configuration; The backup is restored.
> >>>>>
> >>>>>                 >First, do I need to reset these attributes back
> >>>>>                 to 'readonly' and the original
> nsslapd-directory?
> >>>>>
> >>>>>                 >Second, I am now receiving the following error
> >>>>>                 from the master A:
> >>>>>                 >Unable to acquire replica: permission denied.
> >>>>>                 The bind dn "cn=replication,cn=config"
> >does not
> >>>>>                 have permission to supply replication updates to
> >>>>>                 the replica. Will retry later.
> >>>>>
> >>>>>                 >On another note, I see plain text passwords in
> >>>>>                 the error logs on A for the consumers >but passwd
> >>>>>                 = {SSHA}0bgDq2f1IM/2nNOOIHUh8lXfkG13XUOHTYD== for
> >>>>>                 B, the other >master. Is there specific reason
> >>>>>                 for this?
> >>>>>
> >>>>>                 >As always, any guidance that can be provided is
> >>>>>                 greatly appreciated.
> >>>>>
> >>>>>                 TIA,
> >>>>>
> >>>>>                 Herb
> >>>>>
> >>>>>>
> >>>>>>                     >> 3. I assume that upon repairing
> >>>>>>                     replication (apparently it has not been
> >>>>>>                     working for several years) the systems will
> >>>>>>                     all replicate to the most
> >>>>>>                     recent information.  Correct?
> >>>>>>                     >>>>I think that's the tricky
> part.  Make
> >>>>>>                     sure you backup your directory on all
> >>>>>>                     >>>>the LDAP first so you have
> something to
> >>>>>>                     roll back.  I *believe* the last
> >>>>>>                     >>>>step when setting up
> replication is
> >>>>>>                     initializing the directory and that
> >>>>>>                     >>>>will wipe out directory on
> the other
> >>>>>>                     LDAP.  Someone on the list might  be
> >>>>>>                     >>>>able to provide a better on
> this but I
> >>>>>>                     am just giving you a heads up that
> >>>>>>                     >>>>this can be a complicated
> process.
> >>>>>>
> >>>>>>                     Given the fact that system B has not been
> >>>>>>                     running for some time, ideally it would
> >>>>>>                     simply replicate to the current data on
> >>>>>>                     system A.  After replication is
> >>>>>>                     reestablished the systems are set up to
> >>>>>>                     "Always keep directories in sync". 
> If
> >>>>>>                     anyone can confirm the behavior that will
> >>>>>>                     occur upon replication on these two systems
> >>>>>>                     it would be greatly appreciated.
> >>>>>>
> >>>>>>                     Thanks in advance,
> >>>>>>
> >>>>>>                     Herb
> >>>>>>
> >>>>>>
> >>>>>>                         ------------------------------
> >>>>>>
> >>>>>>                         Message: 2
> >>>>>>                         Date: Thu, 22 Mar 2012 10:40:34 -0400
> >>>>>>                         From: Chun Tat David Chu
> >>>>>>                         <beyonddc.storage(a)gmail.com
> >>>>>>                        
> <mailto:[e-mail]>>
> >>>>>>                         To: "General discussion list for the
> 389
> >>>>>>                         Directory server project."
> >>>>>>                         <389-users(a)lists.fedoraproject.org
> >>>>>>                        
> <mailto:[e-mail]>>
> >>>>>>                         Subject: Re: [389-users] Repair
> replication
> >>>>>>                         Message-ID:
> >>>>>>                        
> <CANCf8oLYKet99sB_ou4U3CER8U89UgwZhGUBTHekcF9HWNKL9g(a)mail.gmail.com
> >>>>>>                        
> <mailto:[e-mail]>>
> >>>>>>                         Content-Type: text/plain;
> >>>>>>                         charset="iso-8859-1"
> >>>>>>
> >>>>>>                         Hey Herb,
> >>>>>>
> >>>>>>                         You should refer to the Red Hat
> >>>>>>                         Directory Server administration guide
> for
> >>>>>>                         detail about setting up replication
> >>>>>>                         which you can locate in here.
> >>>>>>                        
> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/
> >>>>>>
> >>>>>>                         >> 1. How can I find out which
> system(s)
> >>>>>>                         is/are master, consumer, hub, etc?
> >>>>>>                         You should be able to determine the role
> >>>>>>                         of the Directory Server for each
> >>>>>>                         system by logging into the LDAP console
> >>>>>>                         under
> >>>>>>                        
> "Configuration->Replication".  The role
> >>>>>>                         is either "Single Master",
> "Hub" or
> >>>>>>                         "Dedicated Consumer".
> >>>>>>
> >>>>>>                         >> 2. How do I confirm that the
> systems
> >>>>>>                         have the correct credentials for
> >>>>>>                         replication? (I am receiving:
> "Unable to
> >>>>>>                         acquire replica: Permission
> >>>>>>                         denied.")
> >>>>>>                            a. How can I change the bind dn
> >>>>>>                         "cn=replication,cn=config"
> credentials
> >>>>>>                         on each system to ensure replication
> >>>>>>                         will work?
> >>>>>>                         You can do that on the console as well.
> >>>>>>                          Just navigate down the directory
> >>>>>>                         tree and manually reset the password for
> >>>>>>                         the replication user account.
> >>>>>>                         There's a possibility that your
> >>>>>>                         replication user account's password
> expired.
> >>>>>>
> >>>>>>                         >> 3. I assume that upon repairing
> >>>>>>                         replication (apparently it has not been
> >>>>>>                         working for several years) the systems
> >>>>>>                         will all replicate to the most
> >>>>>>                         recent information.  Correct?
> >>>>>>                         I think that's the tricky part. 
> Make
> >>>>>>                         sure you backup your directory on all
> >>>>>>                         the LDAP first so you have something to
> >>>>>>                         roll back.  I *believe* the last
> >>>>>>                         step when setting up replication is
> >>>>>>                         initializing the directory and that
> >>>>>>                         will wipe out directory on the other
> >>>>>>                         LDAP.  Someone on the list might  be
> >>>>>>                         able to provide a better on this but I
> >>>>>>                         am just giving you a heads up that
> >>>>>>                         this can be a complicated process.
> >>>>>>
> >>>>>>                         Good luck
> >>>>>>
> >>>>>>                         - David
> >>>>>>
> >>>>>>                         2012/3/21 Herb Burnswell
> >>>>>>                         <herbert.burnswell(a)gmail.com
> >>>>>>                        
> <mailto:[e-mail]>>
> >>>>>>
> >>>>>>                         > Hi All,
> >>>>>>                         >
> >>>>>>                         > I'm new to LDAP administration
> and
> >>>>>>                         have been tasked with fixing the system
> >>>>>>                         > replication of 4 Linux systems
> running
> >>>>>>                         Fedora Directory Services.  I am
> >>>>>>                         > very comfortable working with
> >>>>>>                         Linux/Unix but am not experienced with
> LDAP.
> >>>>>>                         > I've been reading the
> communications
> >>>>>>                         from this user group and reading as
> >>>>>>                         > much as I can from documentation. 
> I
> >>>>>>                         believe this environment is not too
> >>>>>>                         > complex but I am looking for some
> >>>>>>                         guidance, any assistance is greatly
> >>>>>>                         > appreciated.
> >>>>>>                         >
> >>>>>>                         > Info:
> >>>>>>                         >
> >>>>>>                         > OS: Fedora Core 4
> >>>>>>                         > LDAP: Fedora Directory Server v 7.1
> >>>>>>                         >
> >>>>>>                         > First, I know that both the systems
> >>>>>>                         and FDS versions are ancient.
> >>>>>>                         > However, at this point I need to
> get
> >>>>>>                         the replication working prior to
> >>>>>>                         > putting together a migration plan. 
> I
> >>>>>>                         have access to the Directory Manager
> >>>>>>                         > console and am comfortable running
> >>>>>>                         command line commands as well.  Either
> >>>>>>                         > way is fine.
> >>>>>>                         >
> >>>>>>                         > Questions:
> >>>>>>                         >
> >>>>>>                         > 1. How can I find out which
> system(s)
> >>>>>>                         is/are master, consumer, hub, etc?
> >>>>>>                         >
> >>>>>>                         > 2. How do I confirm that the
> systems
> >>>>>>                         have the correct credentials for
> >>>>>>                         > replication? (I am receiving:
> "Unable
> >>>>>>                         to acquire replica: Permission
> >>>>>>                         > denied.")
> >>>>>>                         >     a. How can I change the bind dn
> >>>>>>                         "cn=replication,cn=config"
> credentials
> >>>>>>                         > on each system to ensure
> replication
> >>>>>>                         will work?
> >>>>>>                         >
> >>>>>>                         > 3. I assume that upon repairing
> >>>>>>                         replication (apparently it has not been
> >>>>>>                         > working for several years) the
> systems
> >>>>>>                         will all replicate to the most
> >>>>>>                         > recent information.  Correct?
> >>>>>>                         >
> >>>>>>                         > Again, any guidance is greatly
> >>>>>>                         appreciated.
> >>>>>>                         >
> >>>>>>                         > Thanks in advance,
> >>>>>>                         >
> >>>>>>                         > Herb
> >>>>>>                         >
> >>>>>>                         > --
> >>>>>>                         > 389 users mailing list
> >>>>>>                         > 389-users(a)lists.fedoraproject.org
> >>>>>>                        
> <mailto:[e-mail]>
> >>>>>>                         >
> >>>>>>                        
> https://admin.fedoraproject.org/mailman/listinfo/389-users
> >>>>>>                         >
> >>>>>>                         -------------- next part --------------
> >>>>>>                         An HTML attachment was scrubbed...
> >>>>>>                         URL:
> >>>>>>                        
> <http://lists.fedoraproject.org/pipermail/389-users/attachments/20120322/e...
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>                     --
> >>>>>>                     389 users mailing list
> >>>>>>                     389-users(a)lists.fedoraproject.org 
> <mailto:[e-mail]>
> >>>>>>                    
> https://admin.fedoraproject.org/mailman/listinfo/389-users
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>                 --
> >>>>>                 389 users mailing list
> >>>>>                 389-users(a)lists.fedoraproject.org 
> <mailto:[e-mail]>
> >>>>>                
> https://admin.fedoraproject.org/mailman/listinfo/389-users
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>                 --
> >>>>                 389 users mailing list
> >>>>                 389-users(a)lists.fedoraproject.org 
> <mailto:[e-mail]>
> >>>>                
> https://admin.fedoraproject.org/mailman/listinfo/389-users
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
>
>

Repair replication

[Herb Burnswell]

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&gt; 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&gt;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&gt;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&gt;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&gt; wrote:
> >>>
> >>>>
> >>>>   ---------- Forwarded message ----------
> >>>> From: Rich Megginson <rmeggins(a)redhat.com&gt;
> >>>>   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&gt;
> >>>> Cc: Herb Burnswell <herbert.burnswell(a)gmail.com&gt;
> >>>>
> >>>>
> >>>>       On 04/02/2012 05:48 PM, Herb Burnswell wrote:
> >>>>
> >>>>
> >>>>
> >>>> ---------- Forwarded message ----------
> >>>> From: Rich Megginson <rmeggins(a)redhat.com&gt;
> >>>> 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&gt;
> >>>> Cc: Herb Burnswell <herbert.burnswell(a)gmail.com&gt;
> >>>>
> >>>>
> >>>>  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&gt;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&gt;
> >>>>>> To: "General discussion list for the 389 Directory server
> project."
> >>>>>>        <389-users(a)lists.fedoraproject.org&gt;
> >>>>>> Subject: Re: [389-users] Repair replication
> >>>>>> Message-ID:
> >>>>>>        <
> >>>>>>
> CANCf8oLYKet99sB_ou4U3CER8U89UgwZhGUBTHekcF9HWNKL9g(a)mail.gmail.com&gt;
> >>>>>> 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&gt;
> >>>>>>
> >>>>>> > 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
> [e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> 389 users mailing
> [e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> 389 users mailing
> [e-mail]://admin.fedoraproject.org/mailman/listinfo/389-users
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
> >
>
>

Repair replication

[Herb Burnswell]

Hi All,

I wanted to update this issue as I've made some progress but replication is
still not working as it should.  I've removed the previous communication as
it was getting very long and I began to receive 'message too large'
responses from the list server.  The history of this post can be read in
the archives:
http://lists.fedoraproject.org/pipermail/389-users/2012-April/thread.html.

So, I've tried to simplify my efforts by removing the consumer replication
agreements for now to focus on getting the multi-master replication working
first.  To briefly review, I inherited two multi-master systems (A & B) and
A has been the only system running for many years.

To get replication working I've done the following:

1.  Initialize master B data from a nightly backup from master A as:

     ./bak2db bak/directory -n <my_suffix>

     - I see this in the error log:

[20/Apr/2012:10:30:31 -0700] -   Add Attribute readonly Value off

[20/Apr/2012:10:30:31 -0700] -   Add Attribute nsslapd-directory Value
/data/LDAP/slapd-<master A server name>/db/<my_suffix>
[20/Apr/2012:10:30:31 -0700] -   Del Attribute nsslapd-directory Value
/data/LDAP/slapd-<master B server name>/db/<my_suffix>

[20/Apr/2012:10:30:31 -0700] - WARNING!!: current Instance Config is
different from backed up configuration; The backup is restored.
[20/Apr/2012:10:30:31 -0700] - dblayer_restore: Removing staging area
/opt/fedora-ds/slapd-<master B server name>/db/../fribak.

*Is there any problem regarding the lines above that change the
'**nsslapd-directory"
attribute from it's original correct master B path to the path of
master A**as part of the initialization?  Or is this reset to the
correct path for
master B?*  *If I need to reset some attributes, how can I view the current
nsslapd-directory attribute from the command line with ldapsearch?*

2. Start slapd deamon on master B.

     From error log:

[20/Apr/2012:10:30:40 -0700] - Fedora-Directory/7.1 B2005.146.2010 starting
up
[20/Apr/2012:10:30:40 -0700] NSMMReplicationPlugin -
replica_check_for_data_reload: Warning: data for replica o=<my_suffix> was
reloaded and it no longer matches the data in the changelog (replica data >
changelog). Recreating the changelog file. This could affect replication
with replica's consumers in which case the consumers should be
reinitialized.

3. Create replication agreements between master A and B on both systems.
4. Run an initialization from the DS console on master B to master A.

Here is what I see from the logs:

error log on master B:

[20/Apr/2012:10:30:40 -0700] - slapd started.  Listening on All Interfaces
port 389 for LDAP requests
[20/Apr/2012:10:31:05 -0700] NSMMReplicationPlugin - Beginning total update
of replica "agmt="cn=<my_suffix>_to_<master_A>"
(<master_A>:389)".
[20/Apr/2012:10:31:11 -0700] NSMMReplicationPlugin - Finished total update
of replica "agmt="cn=<my_suffix>_to_<master_A>"
(<master_A>:389)". Sent
1718 entries.

*The above appears to have sent 1718 entries to master A.  And "replication
status' on master B says "incremental update succeeded".

*error log on master A:

[20/Apr/2012:10:30:40 -0700] NSMMReplicationPlugin - conn=1578 op=3
repl="o=my_suffix": Begin incremental protocol
[20/Apr/2012:10:30:40 -0700] NSMMReplicationPlugin - conn=1578 op=3
repl="o=my_suffix": Acquired replica
[20/Apr/2012:10:30:40 -0700] NSMMReplicationPlugin - conn=1578 op=3
repl="o=my_suffix": StartNSDS50ReplicationRequest: response=0 rc=0
[20/Apr/2012:10:30:40 -0700] NSMMReplicationPlugin - conn=1578 op=5
repl="o=my_suffix": Released replica
[20/Apr/2012:10:31:03 -0700] NSMMReplicationPlugin - conn=1579 op=3
repl="o=my_suffix": Begin total protocol
[20/Apr/2012:10:31:03 -0700] NSMMReplicationPlugin - conn=1579 op=3
repl="o=my_suffix": Acquired replica
[20/Apr/2012:10:31:03 -0700] NSMMReplicationPlugin -
multimaster_be_state_change: replica o=my_suffix is going offline;
disabling replication
[20/Apr/2012:10:31:04 -0700] NSMMReplicationPlugin -
agmt="cn=my_suffix_to_master_B" (master_B:389): State: backoff -> backoff
[20/Apr/2012:10:31:04 -0700] NSMMReplicationPlugin -
agmt="cn=my_suffix_to_master_B" (master_B:389): State: backoff -> backoff
[20/Apr/2012:10:31:04 -0700] NSMMReplicationPlugin -
agmt="cn=my_suffix_to_master_B" (master_B:389): No linger to cancel on the
connection
[20/Apr/2012:10:31:04 -0700] NSMMReplicationPlugin -
agmt="cn=my_suffix_to_master_B" (master_B:389): Disconnected from the
consumer
[20/Apr/2012:10:31:05 -0700] NSMMReplicationPlugin -
agmt="cn=my_suffix_to_master_B" (master_B:389): repl5_inc_stop: protocol
stopped after 0 seconds
[20/Apr/2012:10:31:05 -0700] NSMMReplicationPlugin - conn=0 op=0
repl="o=my_suffix": Replica in use locking_purl=conn=1579 id=3
[20/Apr/2012:10:31:05 -0700] NSMMReplicationPlugin -
replica_disable_replication: replica o=my_suffix is acquired
[20/Apr/2012:10:31:05 -0700] - WARNING: Import is running with
nsslapd-db-private-import-mem on; No other process is allowed to access the
database
[20/Apr/2012:10:31:05 -0700] NSMMReplicationPlugin - conn=1579 op=3
repl="o=my_suffix": StartNSDS50ReplicationRequest: response=0 rc=0
[20/Apr/2012:10:31:09 -0700] - import my_suffix: Workers finished; cleaning
up...
[20/Apr/2012:10:31:09 -0700] - import my_suffix: Workers cleaned up.
[20/Apr/2012:10:31:09 -0700] - import my_suffix: Indexing complete.
Post-processing...
[20/Apr/2012:10:31:09 -0700] - import my_suffix: Flushing caches...
[20/Apr/2012:10:31:09 -0700] - import my_suffix: Closing files...
[20/Apr/2012:10:31:10 -0700] - import my_suffix: Import complete.
Processed 1718 entries in 5 seconds. (343.60 entries/sec)

*The above log info looks as if it did 'acquire' replication from master B
and processed 1718 entries.*

[20/Apr/2012:10:31:10 -0700] NSMMReplicationPlugin -
multimaster_be_state_change: replica o=my_suffix is coming online; enabling
replication
[20/Apr/2012:10:31:10 -0700] NSMMReplicationPlugin -
_replica_configure_ruv: No ruv tombstone found for replica o=my_suffix.
Created a new one
[20/Apr/2012:10:31:10 -0700] NSMMReplicationPlugin - replica_reload_ruv:
Warning: new data for replica o=my_suffix does not match the data in the
changelog.
 Recreating the changelog file. This could affect replication with
replica's  consumers in which case the consumers should be reinitialized.
[20/Apr/2012:10:31:11 -0700] NSMMReplicationPlugin - conn=0 op=0
repl="o=my_suffix": Released replica
[20/Apr/2012:10:31:11 -0700] NSMMReplicationPlugin -
replica_enable_replication: replica o=my_suffix is relinquished
[20/Apr/2012:10:31:11 -0700] NSMMReplicationPlugin -
agmt="cn=my_suffix_to_master_B" (master_B:389): No linger to cancel on the
connection
[20/Apr/2012:10:31:11 -0700] NSMMReplicationPlugin -
agmt="cn=my_suffix_to_master_B" (master_B:389): Disconnected from the
consumer
[20/Apr/2012:10:31:11 -0700] NSMMReplicationPlugin -
agmt="cn=my_suffix_to_master_B" (master_B:389): State: start ->
ready_to_acquire_replica
[20/Apr/2012:10:31:11 -0700] NSMMReplicationPlugin - changelog program -
cl5DeleteDBSync: file for replica at (o=my_suffix) not found
[20/Apr/2012:10:31:11 -0700] NSMMReplicationPlugin -
agmt="cn=my_suffix_to_master_B" (master_B:389): State:
ready_to_acquire_replica -> wait_for_changes
[20/Apr/2012:10:31:11 -0700] NSMMReplicationPlugin - changelog program -
_cl5NewDBFile: semaphore
/opt/fedora-ds/slapd-<master_A>/changelogdb/1da9fe82-1dd211b2-80bc8f56-47cc0000.sema
[20/Apr/2012:10:31:11 -0700] NSMMReplicationPlugin - changelog program -
_cl5NewDBFile: maxConcurrentWrites=2
[20/Apr/2012:10:31:11 -0700] NSMMReplicationPlugin - changelog program -
_cl5GetEntryCount: 0 changes for replica 1da9fe82-1dd211b2-80bc8f56-47cc0000
[20/Apr/2012:10:31:11 -0700] NSMMReplicationPlugin - conn=1579 op=1722
repl="o=my_suffix": Replica not in use

*The above is the last of logs referring to this replication.  Is there
anything odd?

*The replication agreements are set to 'always keep directories in sync'
and since this manual initialization from the console the logs go back to
(every 5 min or so):

master A error log:

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.

master B error log:

Unable to acquire replica: error: permission denied

*It seems as if the attempt to sync between master A & B is always from A
to B.  Is this normal, could this have anything to do with the
**'**nsslapd-directory"
attribute?

*As always any help is greatly appreciated.

Thanks in advance,

Herb

Repair replication

[Russell Beall]

On Apr 20, 2012, at 3:24 PM, Herb Burnswell wrote:

>  4. Run an initialization from the DS console on master B to master A.
I'm still pretty new to 389, but when learning about setting up replication agreements
I remember specifically that initialization is done only one way.  The replication
agreements are set up both ways if you are doing multi-master, but there is a specific
sequence to the initializations.  

This probably won't solve your authorization problem on the replication manager
account, but this might be a piece of your puzzle.

I was able to enable replication on a 600K-entry directory by following the documentation
steps.  I had to make a special configuration to handle very large entries, but other than
that, replication has been working fine for me.

Regards,
Russ.

==============================
Russell Beall
Programmer Analyst IV
Enterprise Identity Management
University of Southern California
beall(a)usc.edu
==============================

Repair replication

[Mark Reynolds]

Hi Herb,/

/While working on a different replication issue I accidentally 
reproduced your issue.  My issue was a typo in the password in the repl 
agreement.  I know you said you passwords were the same, but maybe there 
is still a mismatch.  Also, if the root dn specified in the agreement 
doesn 't match what is setup in the consumer config you'll get the same 
error.  So it's either the password, or the bind dn.

So I would like you to try two more things:

[1]   Make sure the repl bind dn's are set correctly on all the server's 
agreements/config:   nsDS5ReplicaBindDN

-  I saw in your last email that you still had "cn=replication, 
cn=config" as your bind dn.  It should be "cn=replication 
manager,cn=config" - assuming you did create this account.
-  Please make sure the bind dn is set correctly for every 
agreement/replica, and then try to reinit.  Just grep for 
"nsDS5ReplicaBindDN" from the dse.ldif on every server.  The edits must 
be done while the server is stopped or else you will lose your changes.

[2]  If [1] doesn't work.  Then stop all the servers, and in the 
dse.ldif, set all the passwords in plain text for the replication 
manager, and the agreements.  This needs to be done across the board.  
Start the servers, and reinit.

-  If this works, you can go back in a reset the password with 
ldapmodify to encrypt the passwords.

Hope this helps,
Mark
/


/
On 04/20/2012 03:24 PM, Herb Burnswell wrote:
>  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.

Repair replication

[Herb Burnswell]

Russ and Mark thank you for your suggestions.

I finally managed to get replication working...  After simplifying to just
working on the dual masters A & B and still seeing the same error, a dug
more into something that Rich said previously.

He mentioned that the password (nsDS5ReplicaCredentials) listed in the
replication agreement should be hashed and my master A system was printing
it in plain text in the dse.ldif file.  I compared the dse.ldif files from
master A & B and found a typo on A:

dn: cn=DES,cn=Password Storage Schemes,cn=plugins,cn=config
objectClass: top
objectClass: nsSlapdPlugin
objectClass: extensibleObject
cn: DES
nsslapd-pluginPath: /opt/fedora-ds/lib/des-plugin.so
nsslapd-pluginInitfunc: des_init
nsslapd-pluginType: reverpwdstoragescheme
nsslapd-pluginEnabled: on
nsslapd-pluginarg0: nsmultiplexorcredentials

nsslapd-pluginarg1: nsds5eeplicaCredentials
                                     ^^^^
nsslapd-pluginId: des-storage-scheme
nsslapd-pluginVersion: 7.1
nsslapd-pluginVendor: Fedora Project
nsslapd-pluginDescription: DES storage scheme plugin


So, steps were:

- stop server master A
- replace typo 'e' with correct 'R' = nsds5ReplicaCredentials
- restart server master A
- reset replication agreement credentials with ldapmodify (password now
hashed in dse.ldif)

Replication began to work in about 5 minutes.

Rich and all, thanks for your help I definitely learned quite a bit.
Hopefully this will help someone who runs into replication issue in the
future.

Thanks,

Herb

On Mon, Apr 23, 2012 at 7:21 AM, Mark Reynolds <mareynol(a)redhat.com&gt; wrote:

>   Hi Herb,*
>
>  *While working on a different replication issue I accidentally reproduced
>  your issue.  My issue was a typo in the password in the repl agreement.  I
>  know you said you passwords were the same, but maybe there is still a
>  mismatch.  Also, if the root dn specified in the agreement doesn 't match
>  what is setup in the consumer config you'll get the same error.  So it's
>  either the password, or the bind dn.
>
>  So I would like you to try two more things:
>
>  [1]   Make sure the repl bind dn's are set correctly on all the server's
>  agreements/config:   nsDS5ReplicaBindDN
>
>  -  I saw in your last email that you still had "cn=replication, cn=config"
>  as your bind dn.  It should be "cn=replication manager,cn=config" -
>  assuming you did create this account.
>  -  Please make sure the bind dn is set correctly for every
>  agreement/replica, and then try to reinit.  Just grep for
>  "nsDS5ReplicaBindDN" from the dse.ldif on every server.  The edits must be
>  done while the server is stopped or else you will lose your changes.
>
>  [2]  If [1] doesn't work.  Then stop all the servers, and in the dse.ldif,
>  set all the passwords in plain text for the replication manager, and the
>  agreements.  This needs to be done across the board.  Start the servers,
>  and reinit.
>
>  -  If this works, you can go back in a reset the password with ldapmodify
>  to encrypt the passwords.
>
>  Hope this helps,
>  Mark
>
>  *
>
>
>  *
>  On 04/20/2012 03:24 PM, Herb Burnswell wrote:
>
>
>  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.
>
>

Repair replication

[Mark Reynolds]

Glad you got it working Herb!

Looks like we need to improve some replication logging.

Cheers,
Mark

On 04/23/2012 01:06 PM, Herb Burnswell wrote:
>  Russ and Mark thank you for your suggestions.
>
>  I finally managed to get replication working...  After simplifying to 
>  just working on the dual masters A & B and still seeing the same 
>  error, a dug more into something that Rich said previously.
>
>  He mentioned that the password (nsDS5ReplicaCredentials) listed in the 
>  replication agreement should be hashed and my master A system was 
>  printing it in plain text in the dse.ldif file.  I compared the 
>  dse.ldif files from master A & B and found a typo on A:
>
>  dn: cn=DES,cn=Password Storage Schemes,cn=plugins,cn=config
>  objectClass: top
>  objectClass: nsSlapdPlugin
>  objectClass: extensibleObject
>  cn: DES
>  nsslapd-pluginPath: /opt/fedora-ds/lib/des-plugin.so
>  nsslapd-pluginInitfunc: des_init
>  nsslapd-pluginType: reverpwdstoragescheme
>  nsslapd-pluginEnabled: on
>  nsslapd-pluginarg0: nsmultiplexorcredentials
>
>  nsslapd-pluginarg1: nsds5eeplicaCredentials
>                                       ^^^^
>  nsslapd-pluginId: des-storage-scheme
>  nsslapd-pluginVersion: 7.1
>  nsslapd-pluginVendor: Fedora Project
>  nsslapd-pluginDescription: DES storage scheme plugin
>
>
>  So, steps were:
>
>  - stop server master A
>  - replace typo 'e' with correct 'R' = nsds5ReplicaCredentials
>  - restart server master A
>  - reset replication agreement credentials with ldapmodify (password 
>  now hashed in dse.ldif)
>
>  Replication began to work in about 5 minutes.
>
>  Rich and all, thanks for your help I definitely learned quite a bit.  
>  Hopefully this will help someone who runs into replication issue in 
>  the future.
>
>  Thanks,
>
>  Herb
>
>  On Mon, Apr 23, 2012 at 7:21 AM, Mark Reynolds <mareynol(a)redhat.com 
>  <mailto:[e-mail]>> wrote:
>
>      Hi Herb,/
>
>      /While working on a different replication issue I accidentally
>      reproduced your issue.  My issue was a typo in the password in the
>      repl agreement.  I know you said you passwords were the same, but
>      maybe there is still a mismatch.  Also, if the root dn specified
>      in the agreement doesn 't match what is setup in the consumer
>      config you'll get the same error.  So it's either the password, or
>      the bind dn.
>
>      So I would like you to try two more things:
>
>      [1]   Make sure the repl bind dn's are set correctly on all the
>      server's agreements/config:   nsDS5ReplicaBindDN
>
>      -  I saw in your last email that you still had "cn=replication,
>      cn=config" as your bind dn.  It should be "cn=replication
>      manager,cn=config" - assuming you did create this account.
>      -  Please make sure the bind dn is set correctly for every
>      agreement/replica, and then try to reinit.  Just grep for
>      "nsDS5ReplicaBindDN" from the dse.ldif on every server.  The edits
>      must be done while the server is stopped or else you will lose
>      your changes.
>
>      [2]  If [1] doesn't work.  Then stop all the servers, and in the
>      dse.ldif, set all the passwords in plain text for the replication
>      manager, and the agreements.  This needs to be done across the
>      board.  Start the servers, and reinit.
>
>      -  If this works, you can go back in a reset the password with
>      ldapmodify to encrypt the passwords.
>
>      Hope this helps,
>      Mark
>
>      /
>
>
>      /
>      On 04/20/2012 03:24 PM, Herb Burnswell wrote:
> >
> >     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.
>
>