Fields changed

rhbz: => 741210

I think it is reasonable to expect the user to run the command to clean the caches when fundamental configuration is changed.

The local case is harder, but then if you really want to change the range you should also really check and remove/change users that fall off the range.

The reason why I am not so hot in enforcing the range in the responder is that we will not really be able to do that when we will have the read-only mmap cache shared with the clients. We would have to have code that regularly scans and remove out of range entries to maintain similar behaviour, which is costly and not sure really in scope.

Another way though is to store the range into the cache in the base entry and check if it matches the current configuration at startup. And if it doesn't either autoremoves all the caches or at least removes the offending entries.

This means the change of ranges must have effect only if you restart SSSD though.

HTH

The above comment sounds reasonable and would turn this ticket into a documentation issue.

Expire the cache if configuration changes.

milestone: NEEDS_TRIAGE => SSSD Deferred

Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=741210

Fields changed

rhbz: 741210 => [https://bugzilla.redhat.com/show_bug.cgi?id=741210 741210]

Fields changed

blockedby: =>
blocking: =>
feature_milestone: =>
resolution: => wontfix
status: new => closed

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

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2091

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.