Hi,
I run a 3-way multi master system and I'm replicating both configuration and payload database.
When I modify something related to the syncrepl sections, I am unable to make changes on my data. I have an error message like the following: err=53, Server is unwilling to perform : shadow context; no update referral
Do you have any clue about how to prevent it without having to reboot the slapd daemons ?
Thank you for your answers.
Hi,
Le 02/09/2013 10:11, Yann Bordenave a écrit :
Hi,
I run a 3-way multi master system and I'm replicating both configuration and payload database.
When I modify something related to the syncrepl sections,
What do you mean by "syncrepl sections" ? You talk about olcSyncrepl attribute ?
I am unable to make changes on my data. I have an error message like the following: err=53, Server is unwilling to perform : shadow context; no update referral
Do you have any clue about how to prevent it without having to reboot the slapd daemons ?
it seems you are not in a 3-way MMR topology. If I am not wrong, something is missing in your configuration. Your server says your are in a shadow-master configuration (where the olcUpdateRef attribute is missing). May I suggest you some docs :
http://www.openldap.org/doc/admin24/replication.html https://github.com/benegon/openldap/blob/master/tests/scripts/test050-syncre...
Regards,
Pascal Fautrero CRDP Versailles
On 09/02, Pascal Fautrero wrote:
Hi,
Le 02/09/2013 10:11, Yann Bordenave a écrit :
Hi,
I run a 3-way multi master system and I'm replicating both configuration and payload database.
When I modify something related to the syncrepl sections,
What do you mean by "syncrepl sections" ? You talk about olcSyncrepl attribute ?
Exactly, I missed the terminology.
I am unable to make changes on my data. I have an error message like the following: err=53, Server is unwilling to perform : shadow context; no update referral
Do you have any clue about how to prevent it without having to reboot the slapd daemons ?
it seems you are not in a 3-way MMR topology. If I am not wrong, something is missing in your configuration. Your server says your are in a shadow-master configuration (where the olcUpdateRef attribute is missing). May I suggest you some docs :
http://www.openldap.org/doc/admin24/replication.html https://github.com/benegon/openldap/blob/master/tests/scripts/test050-syncre...
Actually, I followed this documentation step by step to setup the multimaster system with my three nodes. I forgot to say that everything is working, as long as I don't touch one of the olcSyncrepl attribute. Here is an extract of the configuration:
http://paste.meo.wf/paste/J4WsvLGK#EyzL7TLF
Indeed, this extract is replicated on all the servers. I tried to give only the relevant parts of the configuration. Am I missing something ?
I encounter the shadow context error only when I change one of the olcSyncRepl attribute and I got it on every server, not only the one where I make these changes. I hope that these precisions will help in the investigations.
Regards,
Regards,
Le 02/09/2013 13:57, Yann Bordenave a écrit :
http://www.openldap.org/doc/admin24/replication.html https://github.com/benegon/openldap/blob/master/tests/scripts/test050-syncre...
Actually, I followed this documentation step by step to setup the multimaster system with my three nodes. I forgot to say that everything is working, as long as I don't touch one of the olcSyncrepl attribute. Here is an extract of the configuration:
http://paste.meo.wf/paste/J4WsvLGK#EyzL7TLF
Indeed, this extract is replicated on all the servers. I tried to give only the relevant parts of the configuration. Am I missing something ?
I encounter the shadow context error only when I change one of the olcSyncRepl attribute and I got it on every server, not only the one where I make these changes.
Well, your configuration seems to be the good one (but if I were you, I wouldn't use cn=admin,dc=example,dc=org to syncrepl your database {1}bdb.) - Did you try to modify other attributes in cn=config (by tcp, not ldapi) ? It works ? - Can we see ACLs used on {0}config ? (by default, cn=admin,cn=config is not allowed to modify anything in TCP) - Did you try with mdb instead of bdb ? - What is your openldap version ?
I hope that these precisions will help in the investigations.
Regards,
Regards,
On 09/02, Pascal Fautrero wrote:
Le 02/09/2013 13:57, Yann Bordenave a écrit :
http://www.openldap.org/doc/admin24/replication.html https://github.com/benegon/openldap/blob/master/tests/scripts/test050-syncre...
Actually, I followed this documentation step by step to setup the multimaster system with my three nodes. I forgot to say that everything is working, as long as I don't touch one of the olcSyncrepl attribute. Here is an extract of the configuration:
http://paste.meo.wf/paste/J4WsvLGK#EyzL7TLF
Indeed, this extract is replicated on all the servers. I tried to give only the relevant parts of the configuration. Am I missing something ?
I encounter the shadow context error only when I change one of the olcSyncRepl attribute and I got it on every server, not only the one where I make these changes.
Well, your configuration seems to be the good one (but if I were you, I wouldn't use cn=admin,dc=example,dc=org to syncrepl your database {1}bdb.)
It is just for testing purposes, this is not going to be use as-is in production, but thanks for pointing it out.
- Did you try to modify other attributes in cn=config (by tcp, not
ldapi) ? It works ?
Yes it works without problem, I'm using Luma to bind to cn=config with the dn cn=admin,cn=config and I can modify everything. I tried with ldapvi too, no problem encountered.
- Can we see ACLs used on {0}config ? (by default,
cn=admin,cn=config is not allowed to modify anything in TCP)
Seems odd, I didn't add any ACL on {0}config, I'm using the rootdn account to test.
- Did you try with mdb instead of bdb ?
Not at all. I will try too.
- What is your openldap version ?
You're pointing out something interesting: I have 2 servers with 2.4.23 from debian oldstable and one with 2.4.31 from stable. I will unify the versions to see if my issue comes from that difference.
I hope that these precisions will help in the investigations.
Regards,
Regards,
On 09/02, Yann Bordenave wrote:
On 09/02, Pascal Fautrero wrote:
Le 02/09/2013 13:57, Yann Bordenave a écrit :
http://www.openldap.org/doc/admin24/replication.html https://github.com/benegon/openldap/blob/master/tests/scripts/test050-syncre...
Actually, I followed this documentation step by step to setup the multimaster system with my three nodes. I forgot to say that everything is working, as long as I don't touch one of the olcSyncrepl attribute. Here is an extract of the configuration:
http://paste.meo.wf/paste/J4WsvLGK#EyzL7TLF
Indeed, this extract is replicated on all the servers. I tried to give only the relevant parts of the configuration. Am I missing something ?
I encounter the shadow context error only when I change one of the olcSyncRepl attribute and I got it on every server, not only the one where I make these changes.
Well, your configuration seems to be the good one (but if I were you, I wouldn't use cn=admin,dc=example,dc=org to syncrepl your database {1}bdb.)
It is just for testing purposes, this is not going to be use as-is in production, but thanks for pointing it out.
- Did you try to modify other attributes in cn=config (by tcp, not
ldapi) ? It works ?
Yes it works without problem, I'm using Luma to bind to cn=config with the dn cn=admin,cn=config and I can modify everything. I tried with ldapvi too, no problem encountered.
- Can we see ACLs used on {0}config ? (by default,
cn=admin,cn=config is not allowed to modify anything in TCP)
Seems odd, I didn't add any ACL on {0}config, I'm using the rootdn account to test.
- Did you try with mdb instead of bdb ?
Not at all. I will try too.
- What is your openldap version ?
You're pointing out something interesting: I have 2 servers with 2.4.23 from debian oldstable and one with 2.4.31 from stable. I will unify the versions to see if my issue comes from that difference.
Ok, obviously, when I updated the two old servers, the problem did not occur anymore.
Thank you for your help.
openldap-technical@openldap.org