[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Replication issues with delta-syncrepl, MMR and memberOf overlay on 2.4.47
Hi Mark,
--On Thursday, June 06, 2019 1:12 PM +0100 Mark Cairney
<Mark.Cairney@ed.ac.uk> wrote:
I.e., the only way you can ensure slapo-memberof will be "ok" in an
replicated environment (syncrepl or delta-syncrepl) is if you can
guarantee a REFRESH will never occur.
I think this was done in part to mitigate the behaviour in that ITS.
If memberOf isn't compatible with syncrepl then does that mean you can't
have replication and use the memberOf overlay? This would pose a problem
for many medium-large installations surely?
Looking back through the mailing list archive I do note a discussion of
the whys and wherefores in September 2018.
Right, the primary issue is that if a server goes into REFRESH mode, the
order in which the entries are sent back may not allow the slapo-memberOf
overlay to rebuild the groups correctly.
The man page suggests using the dynlist overlay instead but given my
limited understanding I don't see how that would work given the most
common use case of the memberOf overlay is to get the group memberships
when the user object is queried e.g.
ldapsearch "uid=mcairney" "*" memberof
I gave some examples in
<https://www.openldap.org/its/index.cgi/?findid=8613>. But none of it is
pretty.
In general though it does seem like replication and attributes
maintained locally via overlays (memberOf, ppolicy etc) are an absolute
minefield!
Yes, it is. Unfortunately, Microsoft has never defined how memberOf should
work in a replicated environment, and the RFC for ppolicy doesn't either.
At least with ppolicy, one can configure back-ldap/slapo-chain to forward
from the updates from a replica back to a provider so they get replicated
out.
As I've noted a number of times on the list, overlay instantiation order
is important for operation interception/processing. The syncprov
overlay should be the first instantiated overlay, followed by accesslog,
in a delta-syncrepl setup. In the above, this is clearly not the case.
I thought I'd seen this mentioned but wasn't 100% sure. I've now
re-ordered my overlays as follows:
Great!
I would additionally note that the syncprov overlay is missing a
sessionlog setting, where the default is likely much smaller than
required for mitigating ITS#8125.
...and I've set olcSpSessionlog to be 500 (I'm not sure what the default
is- 100?) Hopefully that's sufficient to avoid ITS#8125
It needs to be a value larger than the total number of entries in your
database.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>