8:51 a.m.
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.
9:39 a.m.
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
9:59 a.m.
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?
12:04 a.m.
-----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
-----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.
7:42 a.m.
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.
3943
days inactive
3944
days old
openldap-technical@openldap.org
4 comments
3 participants
participants (3)
-
anax -
Christopher Wood -
Ondrej Kuznik