Bug 1421604 - Kerberos KCM credential cache by default
Summary: Kerberos KCM credential cache by default
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Changes Tracking   
(Show other bugs)
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jakub Hrozek
QA Contact:
URL:
Whiteboard: ChangeAcceptedF26, SystemWideChange, ...
Keywords:
Depends On: 1475999
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-13 09:00 UTC by Jan Kurik
Modified: 2018-11-02 16:58 UTC (History)
7 users (show)

Fixed In Version: sssd-1.15.3-2.fc27
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-11-14 08:57:43 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Jan Kurik 2017-02-13 09:00:45 UTC
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.

Comment 1 Jan Kurik 2017-02-28 10:08:31 UTC
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.

Comment 2 Fedora End Of Life 2017-02-28 11:16:10 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Comment 3 Jan Kurik 2017-03-01 09:51:37 UTC
May I ask for status update on this Change, as requested in Comment #1 ?

Comment 4 Jakub Hrozek 2017-03-01 10:05:27 UTC
(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.

Comment 5 Jan Kurik 2017-03-17 05:41:28 UTC
The Change is deferred to F27: https://pagure.io/fesco/issue/1688#comment-430734

Comment 6 Jakub Hrozek 2017-08-01 08:03:08 UTC
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.

Comment 7 Jan Kurik 2017-08-10 06:18:05 UTC
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

Comment 8 Jakub Hrozek 2017-08-10 08:13:45 UTC
(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.

Comment 9 Jan Kurik 2017-08-15 07:42:21 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

Comment 10 Jakub Hrozek 2017-08-17 16:03:24 UTC
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.

Comment 11 Jan Kurik 2017-09-06 13:38:24 UTC
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

Comment 12 Jakub Hrozek 2017-09-06 18:26:15 UTC
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.

Comment 13 Adam Williamson 2017-10-30 21:08:43 UTC
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?

Comment 14 Jakub Hrozek 2017-10-31 08:03:52 UTC
(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.

Comment 15 Jakub Hrozek 2017-10-31 08:38:06 UTC
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..)

Comment 16 Adam Williamson 2017-10-31 17:27:18 UTC
There are four user accounts created in total for the test (test1, test2, test3, test4).

Comment 17 Debarshi Ray 2017-11-02 14:38:37 UTC
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/

Comment 18 Adam Williamson 2017-11-02 15:17:29 UTC
How bad is it that this *doesn't* work yet, for F27 release purposes?

Comment 19 Debarshi Ray 2017-11-03 10:56:09 UTC
(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!

Comment 20 Jakub Hrozek 2017-11-05 09:37:28 UTC
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.

Comment 21 Adam Williamson 2017-11-07 18:14:14 UTC
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.

Comment 22 Jakub Hrozek 2017-11-07 19:54:26 UTC
(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

Comment 23 Adam Williamson 2017-11-07 20:11:40 UTC
Ah. The update is not marked as fixing this bug, though. Should it be?

Comment 24 Jakub Hrozek 2017-11-07 21:16:12 UTC
(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.

Comment 25 Lukas Slebodnik 2017-11-08 10:58:55 UTC
I already added comment to bodhi update.

Comment 26 Alberto Ruiz 2018-11-02 16:58:13 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.