This is a tracking bug for Change: Kerberos KCM credential cache by default For more details, see: https://fedoraproject.org//wiki/Changes/KerberosKCMCache Default to a new Kerberos credential cache type called KCM which is better suited for containerized environments and provides a better user experience in the general case as well.
On 2017-Feb-28, we have reached the Fedora 26 Change Checkpoint: Completion deadline (testable). At this point, all accepted changes should be substantially complete, and testable. Additionally, if a change is to be enabled by default, it must be enabled at Change Completion deadline as well. Change tracking bug should be set to the MODIFIED state to indicate it achieved completeness. Incomplete and non testable Changes will be reported to FESCo for 2017-Mar-03 meeting.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
May I ask for status update on this Change, as requested in Comment #1 ?
(In reply to Jan Kurik from comment #3) > May I ask for status update on this Change, as requested in Comment #1 ? Not done, move to F-27 please.
The Change is deferred to F27: https://pagure.io/fesco/issue/1688#comment-430734
August 1 status update: * [DONE] the sssd code has been developed and packaged in Fedora: https://koji.fedoraproject.org/koji/buildinfo?buildID=921704 * [IN PROGRESS] The sssd-kcm and sssd-secrets services are being proposed to be added to the default presets: https://pagure.io/fedora-release/pull-request/111 * [IN PROGRESS] The sssd-kcm package is being proposed for addition to the @core group so that the KCM credential cache is there by default: https://pagure.io/fesco/issue/1753 Since the two remaining issues are more or less on the process side of things and not on the coding side, I hope this feature can still be accepted for F-27.
On 2017-Aug-01, we have reached the Fedora 27 Change Checkpoint: Completion deadline (testable). At this point, all accepted changes should be substantially complete, and testable. Additionally, if a change is to be enabled by default, it must be enabled at Change Completion deadline as well. Change tracking bug should be set to the MODIFIED state to indicate it achieved completeness. Incomplete and non testable Changes will be reported to FESCo for 2017-Aug-11 meeting. Please set this bug to the MODIFIED state to indicate it is already in the testable state, or provide an update describing the current state of implementation for this Change. Thank you, Jan
(In reply to Jan Kurik from comment #7) > On 2017-Aug-01, we have reached the Fedora 27 Change Checkpoint: Completion > deadline (testable). > > At this point, all accepted changes should be substantially complete, and > testable. Additionally, if a change is to be enabled by default, it must be > enabled at Change Completion deadline as well. > > Change tracking bug should be set to the MODIFIED state to indicate it > achieved completeness. > > Incomplete and non testable Changes will be reported to FESCo for > 2017-Aug-11 meeting. > > Please set this bug to the MODIFIED state to indicate it is already in the > testable state, or provide an update describing the current state of > implementation for this Change. > Testable and it's been like this for several weeks, but I'm afraid the issues I filed about enabling the feature by default have stalled for quite some time now. Please see comment #6. I would really appreciate if FESCO looked at https://pagure.io/fedora-release/pull-request/111 and https://pagure.io/fesco/issue/1753 because if those are accepted, then the change will be also enabled by default.
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'.
Since both https://pagure.io/fedora-release/pull-request/111 and https://pagure.io/fedora-comps/pull-request/154 were merged, I'm marking this change as MODIFIED with the appropriate SSSD version in the FixedIn field.
On 2017-Sep-05 we reached the "Change Checkpoint: 100% Code Complete Deadline" milestone for Fedora 27 release. At this point all the Changes not at least in "ON_QA" state should be brought to FESCo for review. Please update the state of this bug to "ON_QA" if it is already 100% completed. Please let me know in case you have any trouble with the implementation and the Change needs any help or review. Thanks, Jan
The change is done. We track some known bugs upstream (there are some known crashes under high load that we could not reliably reproduce), but the functionality is there.
I'm noticing something interesting in openQA FreeIPA testing which *may* be related to this change. One of the tests we run does 'kinit' as a couple of users (test3 and test4), then runs 'kdestroy -A' before running a browser and opening the FreeIPA web UI. The intent of this is that the FreeIPA web UI should open to the login page, it shouldn't start up already logged-in as test3 or test4. In the past this worked fine, but in Fedora 27, *sometimes*, when the browser opens, it opens to the logged-in user, not to the login page - *even though* we just ran 'kdestroy -A'. https://openqa.fedoraproject.org/tests/163139#step/freeipa_password_change/10 is an example of this happening, for instance. I'm pretty sure this is new; I don't recall ever seeing this happen in Fedora 26. Could it be that kdestroy is somehow not fully reliable with the new default cache?
(In reply to Adam Williamson from comment #13) > I'm noticing something interesting in openQA FreeIPA testing which *may* be > related to this change. > > One of the tests we run does 'kinit' as a couple of users (test3 and test4), > then runs 'kdestroy -A' before running a browser and opening the FreeIPA web > UI. The intent of this is that the FreeIPA web UI should open to the login > page, it shouldn't start up already logged-in as test3 or test4. > > In the past this worked fine, but in Fedora 27, *sometimes*, when the > browser opens, it opens to the logged-in user, not to the login page - *even > though* we just ran 'kdestroy -A'. > https://openqa.fedoraproject.org/tests/163139#step/freeipa_password_change/ > 10 is an example of this happening, for instance. > > I'm pretty sure this is new; I don't recall ever seeing this happen in > Fedora 26. Could it be that kdestroy is somehow not fully reliable with the > new default cache? How many users do you test with? I've seen kdestroy -A acting up with KCM with 3 or more TGTs, but so far I haven't gotten to the bottom of this and I suspect a bug in the libkrb5 library rather than sssd-kcm because I've been able to reproduce the same issue with another KCM server implementation (from Heimdal) as well.
OK, I see you've already found https://pagure.io/SSSD/sssd/issue/3413 -- that's the ticket I had in mind. If this hits Fedora, feel free to file a Fedora bug (if you do it, you'll be able to link against any trackers and set the priority right, I don't know how urgent the bug is since it breaks your tests..)
There are four user accounts created in total for the test (test1, test2, test3, test4).
Somehow the need to support KCM caches in GNOME [1] slipped through the cracks. Filed bug 1508945 to track it. [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VFE2M4GF2BZ4DBJGXF5UMM3RSWSHFBVP/
How bad is it that this *doesn't* work yet, for F27 release purposes?
(In reply to Adam Williamson from comment #18) > How bad is it that this *doesn't* work yet, for F27 release purposes? I tested this a bit yesterday. All the oddities that I had experienced so far seems to be unrelated to KCM caches. For example, I think the KCM caches are more vulnerable to online updates because I have seen kinit and friends stop working after a "dnf update" unless the system was rebooted, but the Worstation discourages online updates anyway. Then there is https://bugzilla.gnome.org/show_bug.cgi?id=789187 which I think is also unrelated. I spoke with Jakub a bit yesterday, and it will take some time to realize the potential advantages of KCM for GNOME (like not having to poll due to lack of any notification API) because those bits are not in place. So, all in all, we are safe here. Phew, that was close!
https://github.com/SSSD/sssd/pull/437 was also merged upstream recently and should make its way into Fedora quite soon. This should help with some upgrade issues.
It would be good to have it built as an update and submitted for F27 quickly, I guess - if it can be in the 0-day update push, then everyone upgrading to F27 should get it straight away.
(In reply to Adam Williamson from comment #21) > It would be good to have it built as an update and submitted for F27 > quickly, I guess - if it can be in the 0-day update push, then everyone > upgrading to F27 should get it straight away. https://koji.fedoraproject.org/koji/buildinfo?buildID=994683 seems to be in updates-testing and updates-pending already
Ah. The update is not marked as fixing this bug, though. Should it be?
(In reply to Adam Williamson from comment #23) > Ah. The update is not marked as fixing this bug, though. Should it be? I think it should, but I'd also defer the question to the Fedora maintainer.
I already added comment to bodhi update.
I just filed this bug https://bugzilla.redhat.com/show_bug.cgi?id=1645624, effectively requesting to revert this change. There have been performance issues related to this change even for systems with no kerberos accounts due to how GNOME Online Accounts interacts with kcm. sssd upstream has not dealt with the lack of cache changes notifications so that GOA can stop polling to stay in sync. I'm posting this here to draw attention to this and also because I'm not sure whether once closed it's better to bring this up in a new bug or continue the discussion here.