On 06/06/2019 16:30, Quanah Gibson-Mount wrote:
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.
Ahh OK it looks like you're editing the "memberof" attribute in the user (without the overlay) which is then used by the dynlist overlay to generate group memberships on the fly.
Clever but I don't think we could switch over to this approach anytime soon as the majority of our groups are automatically maintained by an external application called "Grouper". It could potentially be configured to do something along these lines but it wouldn't be straightforward!
Something to think about/experiment with though....
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.
Thanks- I've now set it 2000000 based on our present entry count of ~1.25M. We've got 64GB RAM on these boxes so hopefully with a 30GB max DB size set we should have enough.
Many thanks,
Mark
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com