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

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, 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.