[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Replication issues with delta-syncrepl, MMR and memberOf overlay on 2.4.47
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>
>
>
--
/****************************
Mark Cairney
ITI Enterprise Services
Information Services
University of Edinburgh
Tel: 0131 650 6565
Email: Mark.Cairney@ed.ac.uk
PGP: 0x435A9621
*******************************/
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.