<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 04/10/2012 01:53 PM, Herb Burnswell wrote:
<blockquote
cite="mid:CAOuzmw7mE8fW5B4+6WYaUPZ_vMiZa7DpFNw-UZmCWy0bx-_3Qg@mail.gmail.com"
type="cite">Rich thank you for your clarification and continued
responses. <br>
<br>
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. <br>
<br>
I am still receiving the same permission denied (using simple
authentication) error as before (replacing private info):<br>
<br>
[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.<br>
<br>
This occurs when I run an "initialize consumer" from the directory
server console (and per the server's automated attempts).<br>
<br>
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:<br>
<br>
Master A:<br>
<br>
dn: cn=config<br>
cn: config<br>
objectClass: top<br>
objectClass: extensibleObject<br>
objectClass: nsslapdConfig<br>
nsslapd-accesslog-logging-enabled: on<br>
nsslapd-accesslog-maxlogsperdir: 10<br>
nsslapd-accesslog-mode: 600<br>
nsslapd-accesslog-maxlogsize: 100<br>
nsslapd-accesslog-logrotationtime: 1<br>
nsslapd-accesslog-logrotationtimeunit: day<br>
nsslapd-accesslog-logrotationsync-enabled: off<br>
nsslapd-accesslog-logrotationsynchour: 0<br>
nsslapd-accesslog-logrotationsyncmin: 0<br>
nsslapd-accesslog:
/opt/fedora-ds/slapd-<masterA>/logs/access<br>
nsslapd-enquote-sup-oc: off<br>
nsslapd-localhost: <fqdn masterA><br>
nsslapd-schemacheck: off<br>
nsslapd-rewrite-rfc1274: off<br>
nsslapd-return-exact-case: on<br>
nsslapd-ssl-check-hostname: on<br>
nsslapd-port: 389<br>
nsslapd-localuser: nobody<br>
nsslapd-errorlog-logging-enabled: on<br>
nsslapd-errorlog-mode: 600<br>
nsslapd-errorlog-maxlogsperdir: 2<br>
nsslapd-errorlog-maxlogsize: 100<br>
nsslapd-errorlog-logrotationtime: 1<br>
nsslapd-errorlog-logrotationtimeunit: week<br>
nsslapd-errorlog-logrotationsync-enabled: off<br>
nsslapd-errorlog-logrotationsynchour: 0<br>
nsslapd-errorlog-logrotationsyncmin: 0<br>
nsslapd-errorlog: /opt/fedora-ds/slapd-<masterA>/logs/errors<br>
nsslapd-auditlog: /opt/fedora-ds/slapd-<masterA>/logs/audit<br>
nsslapd-auditlog-mode: 600<br>
nsslapd-auditlog-maxlogsize: 100<br>
nsslapd-auditlog-logrotationtime: 1<br>
nsslapd-auditlog-logrotationtimeunit: day<br>
nsslapd-rootdn: cn=Directory Manager<br>
nsslapd-maxdescriptors: 8192<br>
nsslapd-max-filter-nest-level: 40<br>
aci: (targetattr="*")(version 3.0; acl "Configuration
Administrators Group"; a<br>
llow (all) groupdn="<a class="moz-txt-link-freetext" href="ldap:///cn=Configuration">ldap:///cn=Configuration</a> Administrators,
ou=Groups, ou=T<br>
opologyManagement, o=NetscapeRoot";)<br>
aci: (targetattr="*")(version 3.0; acl "Configuration
Administrator"; allow (a<br>
ll) userdn="<a class="moz-txt-link-freetext" href="ldap:///uid=admin,ou=Administrators">ldap:///uid=admin,ou=Administrators</a>,
ou=TopologyManagement, o=Ne<br>
tscapeRoot";)<br>
aci: (targetattr = "*")(version 3.0; acl "Local Directory
Administrators Group<br>
"; allow (all) groupdn=<a class="moz-txt-link-rfc2396E" href="ldap:///cn=DirectoryAdministrators,o=my_suffix">"ldap:///cn=Directory Administrators,
o=my_suffix"</a>;)<br>
aci: (targetattr = "*")(version 3.0; acl "SIE Group"; allow
(all)groupdn = "ld<br>
ap:///cn=slapd-<masterA>, cn=Fedora Directory Server,
cn=Server Group, cn=<masterA>, ou=<domain>,
o=NetscapeRoot";)<br>
modifiersName: cn=directory manager<br>
modifyTimestamp: 20111027035111Z<br>
passwordLockout: on<br>
nsslapd-security: off<br>
passwordLockoutDuration: 1800<br>
passwordMaxFailure: 5<br>
nsslapd-pwpolicy-local: on<br>
passwordCheckSyntax: on<br>
passwordInHistory: 8<br>
passwordExp: on<br>
passwordHistory: on<br>
passwordMinLength: 8<br>
passwordMinAge: 0<br>
passwordWarning: 1209600<br>
passwordMaxAge: 5184000<br>
nsslapd-errorlog-level: 8192<br>
nsslapd-rootpw: {SSHA}UINj4WIl7oboQnwW+ckND0Z+O3frZyF0mFcCnQ==<br>
numSubordinates: 10<br>
<br>
dn: cn=replication,cn=config<br>
objectClass: top<br>
objectClass: extensibleObject<br>
cn: replication<br>
userPassword: {SSHA}bUA40pCdakQByXFXz/D6jjR77abNvf4cjncNRg==<br>
modifiersName: cn=server,cn=plugins,cn=config<br>
modifyTimestamp: 20120405190704Z<br>
passwordGraceUserTime: 0<br>
passwordExpirationTime: 20380119031407z<br>
passwordHistory:
20111027042723Z{SSHA}sfrwJMbFEF+VmXtXYmSz+65wvVMffrtR/M11WQ==<br>
passwordHistory:
20120403171726Z{SSHA}PbA88Gnvp6SVs0KHdYo7y/fPG+C2HwzUk5DbwA==<br>
passwordHistory:
20120405190704Z{SSHA}Ycxkxwe5otvoR5y/IdD8pKNBySEJTXWqjNN4Mw==<br>
passwordRetryCount: 0<br>
<br>
dn: cn=replica,cn="o=my_suffix",cn=mapping tree, cn=config<br>
objectClass: nsDS5Replica<br>
objectClass: top<br>
nsDS5ReplicaRoot: o=my_suffix<br>
nsDS5ReplicaType: 3<br>
nsDS5Flags: 1<br>
nsDS5ReplicaId: 06<br>
nsds5ReplicaPurgeDelay: 604800<br>
nsDS5ReplicaBindDN: cn=replication,cn=config<br>
nsDS5ReplicaReferral: <a class="moz-txt-link-freetext" href="ldap://">ldap://</a><masterB>:389/o=my_suffix<br>
cn: replica<br>
creatorsName: cn=directory manager<br>
modifiersName: cn=Multimaster Replication
Plugin,cn=plugins,cn=config<br>
createTimestamp: 20050927210406Z<br>
modifyTimestamp: 20120410182234Z<br>
nsState:: BgAAAFR6hE8AAAAAsQIAAAEAAAA=<br>
nsDS5ReplicaName: 1da9fe82-1dd211b2-80bc8f56-47cc0000<br>
numSubordinates: 3<br>
<br>
dn: cn=<my_suffix>_to_<consumerC>, cn=replica,
cn="o=<my_suffix>", cn=mapping tree,<br>
cn=config<br>
objectClass: top<br>
objectClass: nsDS5ReplicationAgreement<br>
description: Replicate to consumerC<br>
cn: <my_suffix>_to_<consumerC><br>
nsDS5ReplicaRoot: o=<my_suffix><br>
nsDS5ReplicaHost: <fqdn consumerC><br>
nsDS5ReplicaPort: 389<br>
nsDS5ReplicaBindDN: cn=replication,cn=config<br>
nsDS5ReplicaCredentials: <plain text password for some
reason><br>
</blockquote>
<br>
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<br>
<a class="moz-txt-link-freetext" href="http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Creating_the_Supplier_Bind_DN_Entry.html">http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Creating_the_Supplier_Bind_DN_Entry.html</a><br>
<br>
Another problem is that the password is plain text. It should be
encrypted. How are you setting this password?<br>
<br>
<blockquote
cite="mid:CAOuzmw7mE8fW5B4+6WYaUPZ_vMiZa7DpFNw-UZmCWy0bx-_3Qg@mail.gmail.com"
type="cite">nsDS5ReplicaBindMethod: SIMPLE<br>
creatorsName: cn=directory manager<br>
modifiersName: cn=Multimaster Replication
Plugin,cn=plugins,cn=config<br>
createTimestamp: 20120403204406Z<br>
modifyTimestamp: 20120406001957Z<br>
<br>
Consumer C:<br>
<br>
dn: cn=config<br>
cn: config<br>
objectClass: top<br>
objectClass: extensibleObject<br>
objectClass: nsslapdConfig<br>
nsslapd-accesslog-logging-enabled: on<br>
nsslapd-accesslog-maxlogsperdir: 10<br>
nsslapd-accesslog-mode: 600<br>
nsslapd-accesslog-maxlogsize: 100<br>
nsslapd-accesslog-logrotationtime: 1<br>
nsslapd-accesslog-logrotationtimeunit: day<br>
nsslapd-accesslog-logrotationsync-enabled: off<br>
nsslapd-accesslog-logrotationsynchour: 0<br>
nsslapd-accesslog-logrotationsyncmin: 0<br>
nsslapd-accesslog:
/opt/fedora-ds/slapd-<consumerC>/logs/access<br>
nsslapd-enquote-sup-oc: off<br>
nsslapd-localhost: <fqdn consumerC><br>
nsslapd-schemacheck: off<br>
nsslapd-rewrite-rfc1274: off<br>
nsslapd-return-exact-case: on<br>
nsslapd-ssl-check-hostname: on<br>
nsslapd-port: 389<br>
nsslapd-localuser: nobody<br>
nsslapd-errorlog-logging-enabled: on<br>
nsslapd-errorlog-mode: 600<br>
nsslapd-errorlog-maxlogsperdir: 2<br>
nsslapd-errorlog-maxlogsize: 100<br>
nsslapd-errorlog-logrotationtime: 1<br>
nsslapd-errorlog-logrotationtimeunit: week<br>
nsslapd-errorlog-logrotationsync-enabled: off<br>
nsslapd-errorlog-logrotationsynchour: 0<br>
nsslapd-errorlog-logrotationsyncmin: 0<br>
nsslapd-errorlog:
/opt/fedora-ds/slapd-<consumerC>/logs/errors<br>
nsslapd-auditlog:
/opt/fedora-ds/slapd-<consumerC>/logs/audit<br>
nsslapd-auditlog-mode: 600<br>
nsslapd-auditlog-maxlogsize: 100<br>
nsslapd-auditlog-logrotationtime: 1<br>
nsslapd-auditlog-logrotationtimeunit: day<br>
nsslapd-rootdn: cn=Directory Manager<br>
nsslapd-maxdescriptors: 8192<br>
nsslapd-max-filter-nest-level: 40<br>
aci: (targetattr="*")(version 3.0; acl "Configuration
Administrators Group"; a<br>
llow (all) groupdn="<a class="moz-txt-link-freetext" href="ldap:///cn=Configuration">ldap:///cn=Configuration</a> Administrators,
ou=Groups, ou=T<br>
opologyManagement, o=NetscapeRoot";)<br>
aci: (targetattr="*")(version 3.0; acl "Configuration
Administrator"; allow (a<br>
ll) userdn="<a class="moz-txt-link-freetext" href="ldap:///uid=admin,ou=Administrators">ldap:///uid=admin,ou=Administrators</a>,
ou=TopologyManagement, o=Ne<br>
tscapeRoot";)<br>
aci: (targetattr = "*")(version 3.0; acl "Local Directory
Administrators Group<br>
"; allow (all) groupdn="<a class="moz-txt-link-freetext" href="ldap:///cn=Directory">ldap:///cn=Directory</a> Administrators,
o=<my_suffix>";)<br>
aci: (targetattr = "*")(version 3.0; acl "SIE Group"; allow
(all)groupdn = "ld<br>
ap:///cn=slapd-<consumerC>, cn=Fedora Directory Server,
cn=Server Group, cn=<fqdn consumerC>, ou=<domain>,
o=NetscapeRoot";)<br>
modifiersName: cn=directory manager<br>
modifyTimestamp: 20120403181804Z<br>
passwordCheckSyntax: on<br>
nsslapd-pwpolicy-local: on<br>
passwordInHistory: 8<br>
passwordExp: on<br>
passwordHistory: on<br>
passwordMinLength: 8<br>
passwordWarning: 1209600<br>
passwordMaxAge: 5184000<br>
passwordLockout: off<br>
passwordLockoutDuration: 900<br>
passwordMaxFailure: 5<br>
nsslapd-errorlog-level: 4096<br>
nsslapd-readonly: off<br>
nsslapd-rootpw: {SSHA}sBIvb4v30kzTCmSiBwpsXc+89nEavcFIDcQBHg==<br>
numSubordinates: 10<br>
<br>
dn: cn=replication,cn=config<br>
objectClass: top<br>
objectClass: extensibleObject<br>
cn: replication<br>
userPassword: {SSHA}Wj00Ba9zK24JpnQgHSYXiUiJC5lUDetm2kmSxQ==<br>
modifiersName: cn=server,cn=plugins,cn=config<br>
modifyTimestamp: 20120405185217Z<br>
passwordRetryCount: 0<br>
passwordGraceUserTime: 0<br>
passwordExpirationTime: 20380119031407z<br>
passwordExpWarned:<br>
retryCountResetTime: 20111019034434Z<br>
accountUnlockTime: 20111019033421Z<br>
passwordHistory:
20111026073128Z{SSHA}F8zw64sH3WOY1wZ83j7zVa893o5tvJOdicI8uw==<br>
passwordHistory:
20111027033502Z{SSHA}rhywp2y/uYfea+zB7F86l0mJqY9QWTNdGhl2KA==<br>
passwordHistory:
20120330230435Z{SSHA}eCyc4cacqk7vSCiEZFEO8gxkRLCQjxEUGy3qYw==<br>
passwordHistory:
20120403163555Z{SSHA}1zgdAL8GqLy/H+3wKlgPGFgxmWbieH2Eau5Ujg==<br>
passwordHistory:
20120403171110Z{SSHA}f0eJOaXQFg6gX366EntWi6C1upkMRyOEIQN34A==<br>
passwordHistory:
20120403221137Z{SSHA}Ycxkxwe5otvoR5y/IdD8pKNBySEJTXWqjNN4Mw==<br>
passwordHistory: 20120405185217ZotvoR5y/IdD8pKSAEvsaassWqjNAEFw==<br>
<br>
dn: cn=replica,cn="o=<my_suffix>",cn=mapping tree, cn=config<br>
objectClass: nsDS5Replica<br>
objectClass: top<br>
nsDS5ReplicaRoot: o=<my_suffix><br>
nsDS5ReplicaType: 2<br>
nsDS5Flags: 0<br>
nsds5ReplicaPurgeDelay: 604800<br>
nsDS5ReplicaBindDN: cn=replication,cn=config<br>
cn: replica<br>
creatorsName: cn=directory manager<br>
modifiersName: cn=directory manager<br>
createTimestamp: 20111027042446Z<br>
modifyTimestamp: 20120405233320Z<br>
nsDS5ReplicaId: 65535<br>
nsState:: //8AAI78eU8AAAAAAAAAAAMAAAA=<br>
nsDS5ReplicaName: 7733e202-1dd211b2-80a1ed8a-0e2a0000<br>
nsDS5ReplicaReferral:
<a class="moz-txt-link-freetext" href="ldap://">ldap://</a><masterA>:389/o=<my_suffix><br>
<br>
dn: cn="o=<my_suffix>",cn=mapping tree, cn=config<br>
objectClass: top<br>
objectClass: extensibleObject<br>
objectClass: nsMappingTree<br>
nsslapd-state: referral on update<br>
cn: "o=<my_suffix>"<br>
cn: o=<my_suffix><br>
nsslapd-backend: <my_suffix><br>
creatorsName: cn=directory manager<br>
modifiersName: cn=server,cn=plugins,cn=config<br>
createTimestamp: 20080215020326Z<br>
modifyTimestamp: 20120330190524Z<br>
nsslapd-referral: <a class="moz-txt-link-freetext" href="ldap://">ldap://</a><masterA>:389/o=<my_suffix><br>
numSubordinates: 1<br>
<br>
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? <br>
<br>
As always, any guidance is greatly appreciated.<br>
<br>
Thanks in advance,<br>
<br>
Herb<br>
<br>
<br>
<br>
<div class="gmail_quote">On Thu, Apr 5, 2012 at 10:58 AM, Rich
Megginson <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:rmeggins@redhat.com">rmeggins@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div class="im"> On 04/05/2012 11:43 AM, Herb Burnswell
wrote:
<blockquote type="cite"><br>
<br>
<div class="gmail_quote">On Thu, Apr 5, 2012 at 10:31
AM, Rich Megginson <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:rmeggins@redhat.com" target="_blank">rmeggins@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div> On 04/05/2012 11:31 AM, Herb Burnswell
wrote:
<blockquote type="cite">Rich,<br>
<br>
I found a thread that you helped someone with
a while back and it seems to be the exact
problem that I am facing: <br>
<br>
<a moz-do-not-send="true"
href="http://www.linux-archive.org/general-discussion-list-389-directory-server-project-389-users-lists-fedoraproject-org/336807-replication-error-acquiring-replica-permission-denied-error-code-3-a.html"
target="_blank">http://www.linux-archive.org/general-discussion-list-389-directory-server-project-389-users-lists-fedoraproject-org/336807-replication-error-acquiring-replica-permission-denied-error-code-3-a.html</a><br>
<br>
You mention:<br>
<br>
Did you add cn=replication manager,cn=config
to the consumer's replica <br>
config entry, to the list of supplier DNs that
are allowed to update <br>
that replica?<br>
<br>
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?<br>
</blockquote>
</div>
I think they moved the docs around. Use the 9.0
doc anyway.<br>
<a moz-do-not-send="true"
href="http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication.html"
target="_blank">http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication.html</a><br>
<br>
specifically<br>
<a moz-do-not-send="true"
href="http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Configuring_Single_Master_Replication.html#Configuring_Single_Master_Replication-Configuring_the_Read_Only_Replica_on_the_Consumer_Server"
target="_blank">http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Configuring_Single_Master_Replication.html#Configuring_Single_Master_Replication-Configuring_the_Read_Only_Replica_on_the_Consumer_Server</a><br>
or<br>
<a moz-do-not-send="true"
href="http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Configuring_Multi_Master_Replication.html#Multi_Master_Replication-Configuring_the_Read_Only_Replicas_on_the_Consumer_Servers"
target="_blank">http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Configuring_Multi_Master_Replication.html#Multi_Master_Replication-Configuring_the_Read_Only_Replicas_on_the_Consumer_Servers</a>
<div>
<div><br>
</div>
</div>
</div>
</blockquote>
<div><br>
Thank you, I'll read the documentation. Can you
clarify what you mean when you say:<br>
<br>
"consumer's replica config entry"</div>
</div>
</blockquote>
</div>
the cn=replica,cn=YOUR SUFFIX,cn=mapping tree,cn=config
entry on the consumer
<div class="im"><br>
<blockquote type="cite">
<div class="gmail_quote">
<div>and "the list of supplier DNs that are allowed to
update <br>
that replica"<br>
</div>
</div>
</blockquote>
</div>
<a moz-do-not-send="true"
href="http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#Replication_Attributes_under_cnreplica_cnsuffixName_cnmapping_tree_cnconfig-nsDS5ReplicaBindDN"
target="_blank">http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#Replication_Attributes_under_cnreplica_cnsuffixName_cnmapping_tree_cnconfig-nsDS5ReplicaBindDN</a>
<div class="im">
<br>
<blockquote type="cite">
<div class="gmail_quote">
<div><br>
Are these set in a specific file(s) that should be
edited?<br>
</div>
</div>
</blockquote>
</div>
The dse.ldif file - but don't edit that file directly unless
necessary - use the console or ldapmodify/ldapsearch
<div>
<div class="h5"><br>
<blockquote type="cite">
<div class="gmail_quote">
<div><br>
Thanks,<br>
<br>
Herb<br>
</div>
<blockquote class="gmail_quote" style="margin:0pt
0pt 0pt 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>
<div>
<blockquote type="cite"> <br>
Thanks,<br>
<br>
Herb<br>
<br>
<br>
<div class="gmail_quote">On Tue, Apr 3,
2012 at 2:55 PM, Herb Burnswell <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:herbert.burnswell@gmail.com"
target="_blank">herbert.burnswell@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex"><br>
<div class="gmail_quote">
<div class="gmail_quote">
<div>
<div>
<div>---------- Forwarded
message ----------<br>
From: <b
class="gmail_sendername">Rich
Megginson</b> <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:rmeggins@redhat.com"
target="_blank">rmeggins@redhat.com</a>></span><br>
</div>
<div>
<div> Date: Mon, Apr 2, 2012
at 7:37 PM<br>
Subject: Re: [389-users]
Fwd: Repair replication<br>
To: "General discussion
list for the 389 Directory
server project." <<a
moz-do-not-send="true"
href="mailto:389-users@lists.fedoraproject.org"
target="_blank">389-users@lists.fedoraproject.org</a>><br>
Cc: Herb Burnswell <<a
moz-do-not-send="true"
href="mailto:herbert.burnswell@gmail.com"
target="_blank">herbert.burnswell@gmail.com</a>><br>
<br>
<br>
</div>
</div>
</div>
</div>
<div bgcolor="#FFFFFF"
text="#000000">
<div>
<div>
<div>
<div>
<div>
<div> On 04/02/2012
05:48 PM, Herb
Burnswell wrote:
<blockquote
type="cite"><br>
<br>
<div
class="gmail_quote">----------
Forwarded
message
----------<br>
From: <b
class="gmail_sendername">Rich
Megginson</b>
<span dir="ltr"><<a
moz-do-not-send="true" href="mailto:rmeggins@redhat.com" target="_blank">rmeggins@redhat.com</a>></span><br>
Date: Mon, Apr
2, 2012 at 3:23
PM<br>
Subject: Re:
[389-users]
Repair
replication<br>
To: "General
discussion list
for the 389
Directory server
project." <<a
moz-do-not-send="true" href="mailto:389-users@lists.fedoraproject.org"
target="_blank">389-users@lists.fedoraproject.org</a>><br>
Cc: Herb
Burnswell <<a
moz-do-not-send="true" href="mailto:herbert.burnswell@gmail.com"
target="_blank">herbert.burnswell@gmail.com</a>><br>
<br>
<br>
<div
bgcolor="#FFFFFF"
text="#000000">
<div> On
04/02/2012
04:13 PM, Herb
Burnswell
wrote:
<blockquote
type="cite"><br>
<br>
<div
class="gmail_quote">On
Fri, Mar 23,
2012 at 10:53
AM, Rich
Megginson <span
dir="ltr"><<a
moz-do-not-send="true" href="mailto:rmeggins@redhat.com" target="_blank">rmeggins@redhat.com</a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0
0 0
.8ex;border-left:1px
#ccc
solid;padding-left:1ex">
<div
bgcolor="#FFFFFF"
text="#000000">
<div> On
03/23/2012
11:09 AM, Herb
Burnswell
wrote:
<blockquote
type="cite">Thanks
for the reply
David.<br>
<br>
>> 1.
How can I find
out which
system(s)
is/are master,
consumer, hub,
etc?<br>
>>>>You
should be able
to determine
the role of
the Directory
Server for
each<br>
>>>>system
by logging
into the LDAP
console under<br>
>>>>"Configuration->Replication".
The role is
either "Single
Master", "Hub"
or<br>
>>>>"Dedicated
Consumer".<br>
<br>
>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.<br>
<br>
>> 2.
How do I
confirm that
the systems
have the
correct
credentials
for<br>
>replication?
(I am
receiving:
"Unable to
acquire
replica:
Permission<br>
>denied.")<br>
>a. How
can I change
the bind dn
"cn=replication,cn=config"
credentials<br>
>on each
system to
ensure
replication
will work?<br>
>>>>You
can do that on
the console as
well. Just
navigate down
the directory<br>
>>>>tree
and manually
reset the
password for
the
replication
user account.<br>
>>>>There's
a possibility
that your
replication
user account's
password
expired.<br>
<br>
>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.<br>
</blockquote>
</div>
>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.<br>
<br>
>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.
<div>
<div><br>
</div>
</div>
</div>
</blockquote>
<div>Rich -
Thank you for
the response.
I was diverted
to another
urgent issue
but have come
back to this
replication
fix. <br>
<br>
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. <br>
</div>
</div>
</blockquote>
<br>
</div>
>What
exactly did
you do?<br>
>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.
<div>
<div><br>
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 <a
moz-do-not-send="true"
href="http://8.10.5.1" target="_blank">8.10.5.1</a>: <a
moz-do-not-send="true"
href="http://www.centos.org/docs/5/html/CDS/ag/8.0/Managing_Replication-Initializing_Consumers.html"
target="_blank">http://www.centos.org/docs/5/html/CDS/ag/8.0/Managing_Replication-Initializing_Consumers.html</a>.
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.. </div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
>I think doing the
restore is resetting the
password. After doing
the bak2db, change the
>passwords.<br>
<br>
</div>
</div>
Well, I'm kind of at a loss
here. I've reset the
passwords on A and C after
doing the bak2db. Same
error:
<div><br>
<br>
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.<br>
<br>
</div>
Next, I removed and re-added
the replication agreement on
Master A to Consumer C, same
error above.<br>
<br>
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?<br>
<br>
</div>
</div>
I'm also seeing this error in
the logs on consumer C:<br>
<br>
NSMMReplicationPlugin - conn=2
op=9 replica="o=myTree": Unable
to acquire replica: error:
permission denied
<div>
<div> <br>
<div>
<div><br>
<div>
<div><br>
<blockquote
type="cite">
<div
class="gmail_quote">
<div
bgcolor="#FFFFFF"
text="#000000">
<div>
<div>
<blockquote
type="cite">
<div
class="gmail_quote">
<div> <br>
>I followed
section
8.10.5.1 on
initializing
the consumer
replica from
backup files
and it
>worked
with the
following: <br>
<br>
>[02/Apr/2012:11:58:03
-0700] - Add
Attribute
readonly Value
off <br>
>[02/Apr/2012:11:58:03
-0700] - Add
Attribute
nsslapd-directory
Value
/new/path/from/master/server<br>
>[02/Apr/2012:11:58:04
-0700] - Del
Attribute
nsslapd-directory
Value
/old/path/from/consumer<br>
>[02/Apr/2012:11:58:04
-0700] -
WARNING!!:
current
Instance
Config is
different from
backed up
configuration;
The backup is
restored.<br>
<br>
>First, do
I need to
reset these
attributes
back to
'readonly' and
the original
nsslapd-directory?
<br>
<br>
>Second, I
am now
receiving the
following
error from the
master A: <br>
>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. <br>
<br>
>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? <br>
<br>
>As always,
any guidance
that can be
provided is
greatly
appreciated. <br>
<br>
TIA, <br>
<br>
Herb <br>
</div>
<blockquote
class="gmail_quote"
style="margin:0pt
0pt 0pt
0.8ex;border-left:1px
solid
rgb(204,204,204);padding-left:1ex">
<div
bgcolor="#FFFFFF"
text="#000000">
<div>
<div>
<blockquote
type="cite"> <br>
>> 3. I
assume that
upon repairing
replication
(apparently it
has not been<br>
working for
several years)
the systems
will all
replicate to
the most<br>
recent
information.
Correct?<br>
>>>>I
think that's
the tricky
part. Make
sure you
backup your
directory on
all<br>
>>>>the
LDAP first so
you have
something to
roll back. I
*believe* the
last<br>
>>>>step
when setting
up replication
is
initializing
the directory
and that<br>
>>>>will
wipe out
directory on
the other
LDAP. Someone
on the list
might be<br>
>>>>able
to provide a
better on this
but I am just
giving you a
heads up that<br>
>>>>this
can be a
complicated
process.<br>
<br>
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.<br>
<br>
Thanks in
advance,<br>
<br>
Herb<br>
<br>
<br>
<div
class="gmail_quote">
<blockquote
class="gmail_quote"
style="margin:0
0 0
.8ex;border-left:1px
#ccc
solid;padding-left:1ex">
------------------------------<br>
<br>
Message: 2<br>
Date: Thu, 22
Mar 2012
10:40:34 -0400<br>
From: Chun Tat
David Chu <<a
moz-do-not-send="true" href="mailto:beyonddc.storage@gmail.com"
target="_blank">beyonddc.storage@gmail.com</a>><br>
To: "General
discussion
list for the
389 Directory
server
project."<br>
<<a
moz-do-not-send="true" href="mailto:389-users@lists.fedoraproject.org"
target="_blank">389-users@lists.fedoraproject.org</a>><br>
Subject: Re:
[389-users]
Repair
replication<br>
Message-ID:<br>
<<a
moz-do-not-send="true"
href="mailto:CANCf8oLYKet99sB_ou4U3CER8U89UgwZhGUBTHekcF9HWNKL9g@mail.gmail.com"
target="_blank">CANCf8oLYKet99sB_ou4U3CER8U89UgwZhGUBTHekcF9HWNKL9g@mail.gmail.com</a>><br>
Content-Type:
text/plain;
charset="iso-8859-1"<br>
<br>
Hey Herb,<br>
<br>
You should
refer to the
Red Hat
Directory
Server
administration
guide for<br>
detail about
setting up
replication
which you can
locate in
here.<br>
<a
moz-do-not-send="true"
href="http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/"
target="_blank">http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/</a><br>
<br>
>> 1.
How can I find
out which
system(s)
is/are master,
consumer, hub,
etc?<br>
You should be
able to
determine the
role of the
Directory
Server for
each<br>
system by
logging into
the LDAP
console under<br>
"Configuration->Replication".
The role is
either "Single
Master", "Hub"
or<br>
"Dedicated
Consumer".<br>
<br>
>> 2.
How do I
confirm that
the systems
have the
correct
credentials
for<br>
replication?
(I am
receiving:
"Unable to
acquire
replica:
Permission<br>
denied.")<br>
a. How can
I change the
bind dn
"cn=replication,cn=config"
credentials<br>
on each system
to ensure
replication
will work?<br>
You can do
that on the
console as
well. Just
navigate down
the directory<br>
tree and
manually reset
the password
for the
replication
user account.<br>
There's a
possibility
that your
replication
user account's
password
expired.<br>
<br>
>> 3. I
assume that
upon repairing
replication
(apparently it
has not been<br>
working for
several years)
the systems
will all
replicate to
the most<br>
recent
information.
Correct?<br>
I think that's
the tricky
part. Make
sure you
backup your
directory on
all<br>
the LDAP first
so you have
something to
roll back. I
*believe* the
last<br>
step when
setting up
replication is
initializing
the directory
and that<br>
will wipe out
directory on
the other
LDAP. Someone
on the list
might be<br>
able to
provide a
better on this
but I am just
giving you a
heads up that<br>
this can be a
complicated
process.<br>
<br>
Good luck<br>
<br>
- David<br>
<br>
2012/3/21 Herb
Burnswell <<a
moz-do-not-send="true" href="mailto:herbert.burnswell@gmail.com"
target="_blank">herbert.burnswell@gmail.com</a>><br>
<br>
> Hi All,<br>
><br>
> I'm new
to LDAP
administration
and have been
tasked with
fixing the
system<br>
>
replication of
4 Linux
systems
running Fedora
Directory
Services. I
am<br>
> very
comfortable
working with
Linux/Unix but
am not
experienced
with LDAP.<br>
> I've been
reading the
communications
from this user
group and
reading as<br>
> much as I
can from
documentation.
I believe
this
environment is
not too<br>
> complex
but I am
looking for
some guidance,
any assistance
is greatly<br>
>
appreciated.<br>
><br>
> Info:<br>
><br>
> OS:
Fedora Core 4<br>
> LDAP:
Fedora
Directory
Server v 7.1<br>
><br>
> First, I
know that both
the systems
and FDS
versions are
ancient.<br>
> However,
at this point
I need to get
the
replication
working prior
to<br>
> putting
together a
migration
plan. I have
access to the
Directory
Manager<br>
> console
and am
comfortable
running
command line
commands as
well. Either<br>
> way is
fine.<br>
><br>
>
Questions:<br>
><br>
> 1. How
can I find out
which
system(s)
is/are master,
consumer, hub,
etc?<br>
><br>
> 2. How do
I confirm that
the systems
have the
correct
credentials
for<br>
>
replication?
(I am
receiving:
"Unable to
acquire
replica:
Permission<br>
> denied.")<br>
> a.
How can I
change the
bind dn
"cn=replication,cn=config"
credentials<br>
> on each
system to
ensure
replication
will work?<br>
><br>
> 3. I
assume that
upon repairing
replication
(apparently it
has not been<br>
> working
for several
years) the
systems will
all replicate
to the most<br>
> recent
information.
Correct?<br>
><br>
> Again,
any guidance
is greatly
appreciated.<br>
><br>
> Thanks in
advance,<br>
><br>
> Herb<br>
><br>
> --<br>
> 389 users
mailing list<br>
> <a
moz-do-not-send="true"
href="mailto:389-users@lists.fedoraproject.org" target="_blank">389-users@lists.fedoraproject.org</a><br>
> <a
moz-do-not-send="true"
href="https://admin.fedoraproject.org/mailman/listinfo/389-users"
target="_blank">https://admin.fedoraproject.org/mailman/listinfo/389-users</a><br>
><br>
--------------
next part
--------------<br>
An HTML
attachment was
scrubbed...<br>
URL: <<a
moz-do-not-send="true"
href="http://lists.fedoraproject.org/pipermail/389-users/attachments/20120322/edfe5e8f/attachment-0001.html"
target="_blank">http://lists.fedoraproject.org/pipermail/389-users/attachments/20120322/edfe5e8f/attachment-0001.html</a>><br>
<br>
</blockquote>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>--
389 users mailing list
<a moz-do-not-send="true" href="mailto:389-users@lists.fedoraproject.org" target="_blank">389-users@lists.fedoraproject.org</a>
<a moz-do-not-send="true" href="https://admin.fedoraproject.org/mailman/listinfo/389-users" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/389-users</a></pre>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br>
<fieldset></fieldset>
<br>
<pre>--
389 users mailing list
<a moz-do-not-send="true" href="mailto:389-users@lists.fedoraproject.org" target="_blank">389-users@lists.fedoraproject.org</a>
<a moz-do-not-send="true" href="https://admin.fedoraproject.org/mailman/listinfo/389-users" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/389-users</a></pre>
</blockquote>
<br>
</div>
</div>
</div>
</div>
<br>
<br>
<fieldset></fieldset>
<br>
<pre>--
389 users mailing list
<a moz-do-not-send="true" href="mailto:389-users@lists.fedoraproject.org" target="_blank">389-users@lists.fedoraproject.org</a>
<a moz-do-not-send="true" href="https://admin.fedoraproject.org/mailman/listinfo/389-users" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/389-users</a></pre>
</blockquote>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
<br>
</blockquote>
</div>
<br>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
<br>
</body>
</html>