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>
