#50278 Ticket 50077 - Do not automatically turn automember postop modifies on
Closed by spichugi. Opened by mreynolds.
mreynolds/389-ds-base ticket50077  into  master

Download 50278.patch

Description:

Although we have set the new postop processing on by default in the template-dse.ldif, we do not want to enable it by default for upgrades (only new installs).

So if the attribute is not set, it is assumed "off".

https://pagure.io/389-ds-base/issue/50077

Okay, so in a new install how is this default to on? template-dse.ldif?

Okay, so in a new install how is this default to on? template-dse.ldif?

Correct

I'm not normally a fan of this because I think template-dse.ldif shouldn't be shipping our defaults - they should be part of the server, but here we have the odd case of not wanting to enable on upgrade ...

However, the issue will be in an MMR env, if we have original masters A and B, then we add a new master C, C now has this feature turned on, and A/B don't. I can see this catching some people out in the same way that this patch tries to avoid.

I want this feature on by default, because it's a great idea, so i'd actually rather see it enable by default, because then in that upgrade scenario, everything "works as expected" because the upgrade of A/B, causes the new behaviour, even without the addition of C, and the admin needs to explicitly ask for the "wrong thing" (without unmembering) to occur.

None of it is ideal. The problem is that FreeIPA does not expect it to work that way. Some of their tools fail for common IPA operations because of this change, and its not trivial to change IPA's CLI tools or processes

So for upgrades they don't want a change in behavior, but for fresh installs it's okay. These upgrade scenarios are always a pitfall we have to deal with. Maybe it should just be off by default for now (even though now its working as it was really intended)?

Okay, how about we merge this (so ack, yay!), then we add into the plugin healthcheck that if setting is "off" we give a warning about possible security risk of moved/non-matching users that they may still have group access that shouldn't be allowed?

rebased onto d318d060f49b67ed1b10f22b52f98e038afa356a

Pull-Request has been merged by mreynolds

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/3337

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.

Pull-Request has been closed by spichugi

Metadata