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 04:11 PM, Herb Burnswell wrote:
On Tue, Apr 10, 2012 at 1:03 PM, Rich
Megginson <rmeggins@xxxxxxxxxx>
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
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.
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>