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?
On Fri,
Mar 23, 2012 at 10:53 AM, Rich
Megginson <rmeggins@xxxxxxxxxx>
wrote:
On 03/23/2012 11:09
AM, Herb Burnswell wrote:
Thanks
for the reply David.
>> 1. How can I
find out which system(s)
is/are master, consumer,
hub, etc?
>>>>You
should be able to
determine the role of
the Directory Server for
each
>>>>system
by logging into the LDAP
console under
>>>>"Configuration->Replication".
The role is either
"Single Master", "Hub"
or
>>>>"Dedicated
Consumer".
>I was able to
determine that we have
two "Multiple Master"
systems. Let's call
>them 'A' and 'B'.
System A has been the
only system running for
what appears to >be
several years (it is
being backed up
nightly). System B has
been off for some
>time but is running
now.
>> 2. How do I
confirm that the systems
have the correct
credentials for
>replication? (I am
receiving: "Unable to
acquire replica:
Permission
>denied.")
>a. How can I
change the bind dn
"cn=replication,cn=config"
credentials
>on each system to
ensure replication will
work?
>>>>You can
do that on the console
as well. Just navigate
down the directory
>>>>tree and
manually reset the
password for the
replication user
account.
>>>>There's
a possibility that your
replication user
account's password
expired.
>I can navigate to
the screen to reset the
password for the
replication user
account. I >have not
reset the passwords yet
as I am reading
documentation to confirm
that >system B will
simply update it's data
to system A's upon
resuming replication.
>When you change the
password of the replication
user on B, you'll also have
to update >those
credentials in the
replication agreement on A
for the agreement from A to
B.
>Note that if replication
has been down for years, you
will have to perform a
manual >replica
initialization procedure -
replication will not
automatically "catch up" if
it has >been down that
long.
Rich - Thank you for the
response. I was diverted to
another urgent issue but have
come back to this replication
fix.
I've confirmed that there are
two Dedicated Consumer's (C
and D) to go along with the
two Dual Master's (A and B). I
want to replicate to one of
the dedicated consumers, C,
prior to syncing the dual
master B. I changed the
passwords for
dn:cn=replication,cn=config on
A via the Directory Manager
console, and via ldapmodify on
C. I am confident that the
passwords are the same on both
systems.
>What exactly did you do?
>Note that you'll have to update
the password in
cn=replication,cn=config on the
>consumer (C) and update the
replication agreement on A for the
replication agreement >between A
and C.
Thanks for the reply Rich. Yes, I
updated the password on A and C.
I apologize as I left out the link
in my below reference to section 8.10.5.1: http://www.centos.org/docs/5/html/CDS/ag/8.0/Managing_Replication-Initializing_Consumers.html.
I used bak2db with backup files
from A. After which, I see:
"Unable to acquire replica:
permission denied. The bind dn
"cn=replication,cn=config" does
not have permission to supply
replication updates to the
replica. Will retry later." on
system A's error logs..
>I think doing the restore is resetting the
password. After doing the bak2db, change the
>passwords.
Well, I'm kind of at a loss here. I've reset the
passwords on A and C after doing the bak2db. Same
error:
Unable to acquire replica: permission denied. The
bind dn "cn=replication,cn=config" does not have
permission to supply replication updates to the
replica. Will retry later.
Next, I removed and re-added the replication
agreement on Master A to Consumer C, same error
above.
Is there any way that I can output the
settings/password information for
cn=replication,cn=config on both A and C via the
command line to compare? I have read that there
needs to be a 'person' entry on the consumer for
cn=replication,cn=config that is used for the
replication of the data. Is there a way I can
confirm this configuration to ensure it is set up
correctly?
I'm also seeing this error in the logs on consumer C:
>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.
>> 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.
> 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@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
--------------
next part
--------------
An HTML
attachment was
scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20120322/edfe5e8f/attachment-0001.html>
