Question: What is happening that I can turn a multimaster replica into a "shadow context"?
(I'm more or less fine with the behaviour since I don't mind stopping the multimaster slapd's to do a password change, but I'm concerned that I may have missed some underlying problem in my setup.)
I've found that issuing a particular set of changes to one or both cn=config multimaster replicas means that I cannot issue any more changes to cn=config until I restart slapd.
The ldif I paste into my ldapmodify session is this (changed the hostname and credentials from the real ones):
dn: olcDatabase={0}config,cn=config changetype: modify replace: olcSyncrepl olcSyncrepl: {0}rid=1 provider=ldap://ldap-supplier-lab-01.company.com binddn="cn=config" bindmethod=simple credentials=newpw searchbase="cn=config" type=refreshAndPersist retry="5 5 30 +" timeout=5 olcSyncrepl: {1}rid=2 provider=ldap://ldap-supplier-lab-02.company.com binddn="cn=config" bindmethod=simple credentials=newpw searchbase="cn=config" type=refreshAndPersist retry="5 5 30 +" timeout=5 - replace: olcRootPW olcRootPW: newpw
I get this output:
modifying entry "olcDatabase={0}config,cn=config"
Then I observe the following behaviour:
I can ldapsearch with the new password and get the expected result (ldif output of the cn=config database).
When I ldapmodify with the new password I get this output:
modifying entry "olcDatabase={0}config,cn=config" ldap_modify: Server is unwilling to perform (53) additional info: shadow context; no update referral
After I restart slapd I get the expected behaviours with both ldapsearch (get ldif output) and ldapmodify (can change cn=config).
Further, I've diffed the ldif output of directories before and after this change, and I do not see any difference apart from the attributes that I've changed.
On 2011-11-02 16:51, Christopher Wood wrote:
modifying entry "olcDatabase={0}config,cn=config" ldap_modify: Server is unwilling to perform (53) additional info: shadow context; no update referral
As far as I remember, the above error msg is the one slapd issues, if you want to modify a slave (as opposed to the master). You may need to check wheather your change modifies something in this respect.
suomi
On Wed, Nov 02, 2011 at 05:39:30PM +0100, anax wrote:
On 2011-11-02 16:51, Christopher Wood wrote:
modifying entry "olcDatabase={0}config,cn=config" ldap_modify: Server is unwilling to perform (53) additional info: shadow context; no update referral
As far as I remember, the above error msg is the one slapd issues, if you want to modify a slave (as opposed to the master). You may need to check wheather your change modifies something in this respect.
suomi
Unfortunately that's the point of my question. How did I manage to change these replicas to slaves?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/02/2011 05:59 PM, Christopher Wood wrote:
On Wed, Nov 02, 2011 at 05:39:30PM +0100, anax wrote:
On 2011-11-02 16:51, Christopher Wood wrote:
modifying entry "olcDatabase={0}config,cn=config" ldap_modify: Server is unwilling to perform (53) additional info: shadow context; no update referral
As far as I remember, the above error msg is the one slapd issues, if you want to modify a slave (as opposed to the master). You may need to check wheather your change modifies something in this respect.
Unfortunately that's the point of my question. How did I manage to change these replicas to slaves?
A syncrepl consumer (database, where olcSyncRepl attribute is set) is a slave (read only) unless olcMirrorMode is set.
- -- Ondrej Kuznik
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
On Thu, Nov 03, 2011 at 08:04:29AM +0100, Ondrej Kuznik wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/02/2011 05:59 PM, Christopher Wood wrote:
On Wed, Nov 02, 2011 at 05:39:30PM +0100, anax wrote:
On 2011-11-02 16:51, Christopher Wood wrote:
modifying entry "olcDatabase={0}config,cn=config" ldap_modify: Server is unwilling to perform (53) additional info: shadow context; no update referral
As far as I remember, the above error msg is the one slapd issues, if you want to modify a slave (as opposed to the master). You may need to check wheather your change modifies something in this respect.
Unfortunately that's the point of my question. How did I manage to change these replicas to slaves?
A syncrepl consumer (database, where olcSyncRepl attribute is set) is a slave (read only) unless olcMirrorMode is set.
I think something else is going on. I've had something similar before but changing another database's replication config:
http://www.openldap.org/lists/openldap-technical/201109/msg00004.html
I mis-remembered that the previous situation left "olcMirrorMode: FALSE". Actually in both scenarios, after changing olcSyncrepl and then checking by ldapsearch, I see "olcMirrorMode: TRUE". The behaviour is as if it was "olcMirrorMode: FALSE".
So I am running into the same issue (implicit change to olcMirrorMode), but the olcMirrorMode change isn't reflected in the actual cn=config database. The fix is the same in both cases: explicitly set "olcMirrorMode: TRUE" in the modification which changes olcSyncrepl.
The olcMirrorMode not obviously changing sounds wrong, so I filed this:
http://www.openldap.org/its/index.cgi/Incoming?id=7077;selectid=7077
Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6yPPAACgkQ9GWxeeH+cXviJQCgoQ+gb0k8+m0zM6suyOySvK+v zQ4AnA/6MhtTrYLo+83O1MOL2I4jLcw0 =yWaD -----END PGP SIGNATURE-----
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
openldap-technical@openldap.org
-
anax -
Christopher Wood -
Ondrej Kuznik