always reread the master map from LDAP #2634
Assignees
Labels
Comments
sgoveas
pushed a commit
to sgoveas/sssd
that referenced
this issue
May 11, 2020
…nction Related: https://pagure.io/SSSD/sssd/issue/4012 Because the initgroups request can, especially in the case of IPA provider with trusts, contain several sub-requests that run some provider-specific initgroups internally and then run post-processing AND because at the same time concurrent requests in the responder need to be sure that the initgrExpireTimestamp is only increased when the initgroups request is really done, we only set the initgrExpireTimestamp in the DP when the request finishes. This means, the background refresh task needs to also set the initgrExpireTimestamp attribute on its own as well. This patch so far splits the helper function into a reusable one so it can later be used by the background refresh. For examples of the bugs caused by the initgrTimestamp being set before the whole multi-step operation finishes, please see tickets SSSD#3744 or SSSD#2634. Reviewed-by: Sumit Bose <sbose@redhat.com>
sgoveas
pushed a commit
to sgoveas/sssd
that referenced
this issue
May 11, 2020
…sh request Related: https://pagure.io/SSSD/sssd/issue/4012 Calls sysdb_set_initgr_expire_timestamp() after each successfull refresh of initgroups data to make sure the initgrExpireTimestamp attribute is increased. If you're wondering why the timestamp is not set by the initgroups operation itself, see tickets SSSD#3744 or SSSD#2634 for examples of bugs caused by setting the initgrExpireTimestamp too soon. Reviewed-by: Sumit Bose <sbose@redhat.com>
scabrero
pushed a commit
to scabrero/sssd
that referenced
this issue
Nov 16, 2020
…nction Related: https://pagure.io/SSSD/sssd/issue/4012 Because the initgroups request can, especially in the case of IPA provider with trusts, contain several sub-requests that run some provider-specific initgroups internally and then run post-processing AND because at the same time concurrent requests in the responder need to be sure that the initgrExpireTimestamp is only increased when the initgroups request is really done, we only set the initgrExpireTimestamp in the DP when the request finishes. This means, the background refresh task needs to also set the initgrExpireTimestamp attribute on its own as well. This patch so far splits the helper function into a reusable one so it can later be used by the background refresh. For examples of the bugs caused by the initgrTimestamp being set before the whole multi-step operation finishes, please see tickets SSSD#3744 or SSSD#2634. Reviewed-by: Sumit Bose <sbose@redhat.com> (cherry picked from commit 7a08d1d) Reviewed-by: Sumit Bose <sbose@redhat.com>
scabrero
pushed a commit
to scabrero/sssd
that referenced
this issue
Nov 16, 2020
…sh request Related: https://pagure.io/SSSD/sssd/issue/4012 Calls sysdb_set_initgr_expire_timestamp() after each successfull refresh of initgroups data to make sure the initgrExpireTimestamp attribute is increased. If you're wondering why the timestamp is not set by the initgroups operation itself, see tickets SSSD#3744 or SSSD#2634 for examples of bugs caused by setting the initgrExpireTimestamp too soon. Reviewed-by: Sumit Bose <sbose@redhat.com> (cherry picked from commit cdc44a0) Reviewed-by: Sumit Bose <sbose@redhat.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/1592
The auto.master map is only read on autofs daemon startup. It might make sense to always read it from LDAP if online to make sure the contents of the master map are up2date when autofs is restarted.
Comments
Comment from jhrozek at 2012-10-25 12:31:52
I discussed the enhancement with the autofs maintainer and here is the proposal:
The automounter only reads the master map on startup or when it receives SIGHUP (which is an explicit way of telling the automounter to re-read its configuration). That means it's quite a rare event, at the same time modifications to the master map are quite rare. In both cases the admin expects the changes to the map to propagate to the automounter deamon.
In SSSD, we should implement the same behaviour the automounter implements internally, which is:
design: =>
design_review: => 0
fedora_test_page: =>
Comment from dpal at 2012-10-25 15:25:31
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.9.3
type: enhancement => defect
Comment from dpal at 2012-10-25 15:31:58
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=870045
rhbz: => [https://bugzilla.redhat.com/show_bug.cgi?id=870045 870045]
Comment from jhrozek at 2012-11-06 12:13:42
Not critical for 1.9.3
_comment0: Not critical for 1.9.4 => 1352200480568757
milestone: SSSD 1.9.3 => SSSD 1.9.4
Comment from dpal at 2012-11-15 21:10:15
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=876531 (Red Hat Enterprise Linux 6)
rhbz: [https://bugzilla.redhat.com/show_bug.cgi?id=870045 870045] => [https://bugzilla.redhat.com/show_bug.cgi?id=870045 870045], [https://bugzilla.redhat.com/show_bug.cgi?id=876531 876531]
Comment from jhrozek at 2012-12-15 18:40:59
Fields changed
owner: somebody => jhrozek
patch: 0 => 1
status: new => assigned
Comment from jhrozek at 2012-12-18 17:32:22
resolution: => fixed
status: assigned => closed
Comment from jhrozek at 2017-02-24 14:58:37
Metadata Update from @jhrozek:
The text was updated successfully, but these errors were encountered: