8:50 a.m.
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
2:33 p.m.
--On Tuesday, October 29, 2019 5:50 PM +0100 Martin Pittamitz
<martin(a)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>
1:25 p.m.
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
2:21 p.m.
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
1310
days inactive
1316
days old
openldap-technical@openldap.org
3 comments
2 participants
participants (2)
-
Martin Pittamitz -
Quanah Gibson-Mount