Reply-to: "General discussion list for the 389 Directory server project." <389-users@xxxxxxxxxxxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120307 Thunderbird/10.0.3
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
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@xxxxxxxxxx>
wrote:
On 04/05/2012 11:43 AM, Herb Burnswell
wrote:
On Thu, Apr 5, 2012 at 10:31
AM, Rich Megginson <rmeggins@xxxxxxxxxx>
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:
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>
