Good day
I have recently added a syncprov configuration and consumer node to our OpenLDAP setup. On our master we use the overlays "memberOf" and "autogroup".
Now a specific error occurs on the consumer node, where "group1" has objectClass "groupOfURLs":
Oct 29 16:39:18 user slapd[26309]: autogroup_modify_entry attempted to modify group's <cn=group1,ou=groups,dc=example,dc=net> member attribute Oct 29 16:39:18 user slapd[26309]: send_ldap_result: conn=-1 op=0 p=3 Oct 29 16:39:18 user slapd[26309]: send_ldap_result: err=19 matched="" text="attempt to modify dynamic group member attribute" Oct 29 16:39:18 user slapd[26309]: syncrepl_null_callback : error code 0x13 Oct 29 16:39:18 user slapd[26309]: syncrepl_entry: rid=001 be_modify cn=group1,ou=groups,dc=example,dc=net (19) Oct 29 16:39:18 user slapd[26309]: syncrepl_entry: rid=001 be_modify failed (19) Oct 29 16:39:18 user slapd[26309]: do_syncrepl: rid=001 rc 19 quitting
Can anyone point me in the right direction here? Is autogroup simply incompatible with such a syncprov setup?
Best regards, Martin
--On Tuesday, October 29, 2019 5:50 PM +0100 Martin Pittamitz martin@pittamitz.at wrote:
Good day
I have recently added a syncprov configuration and consumer node to our OpenLDAP setup. On our master we use the overlays "memberOf" and "autogroup".
Hi Martin,
As documented, memberOf is not compatible with syncrepl based replication. Additionally, based on what I've read of the autogroup overlay, I would say the following:
autogroup is not usable in an MMR environment.
autogroup is probably only usable in a replicated environment where there is a single provider and it is only configured on the provider (i.e., not configured on the consumers at all) and without memberOf. I'm not sure how it behaves with delta-syncrepl (i.e., what operations it logs in the change database). It may or may not be compatible for that configuration.
Hope that helps!
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 29/10/2019 22:33, Quanah Gibson-Mount wrote:
autogroup is probably only usable in a replicated environment where there is a single provider and it is only configured on the provider (i.e., not configured on the consumers at all) and without memberOf. I'm not sure how it behaves with delta-syncrepl (i.e., what operations it logs in the change database). It may or may not be compatible for that configuration.
Hello Quanah
thank you for the quick and informative reply. My thinking was already going in that direction.
I would need a way disable those overlays on the consumer, still keeping the necessary ObjectClasses and such, and in that case memberOf and autogroup would just work on the provider and their "results" are replicated to the consumer. Sadly, my understanding of OpenLDAP is lacking in that regard.
I am wondering how other people solve these cases. The requirement brought up to me was to have an external, replicated "clone" of the LDAP service to be used if the WAN were down on location. No (active) changes would be made on the consumer.
Any possibilities or suggestions?
Best regards Martin
On 31/10/2019 21:25, Martin Pittamitz wrote:
On 29/10/2019 22:33, Quanah Gibson-Mount wrote:
autogroup is probably only usable in a replicated environment where there is a single provider and it is only configured on the provider (i.e., not configured on the consumers at all) and without memberOf. I'm not sure how it behaves with delta-syncrepl (i.e., what operations it logs in the change database). It may or may not be compatible for that configuration.
I would need a way disable those overlays on the consumer, still keeping the necessary ObjectClasses and such, and in that case memberOf and autogroup would just work on the provider and their "results" are replicated to the consumer. Sadly, my understanding of OpenLDAP is lacking in that regard.
Removing autogroup and memberof overlays from the the consumer seems to have solved the problem. I will be looking out for eventual issues.
Regards Martin
openldap-technical@openldap.org
-
Martin Pittamitz -
Quanah Gibson-Mount