Enabling these services is needed to complete https://fedoraproject.org/wiki/Changes/KerberosKCMCache As of sssd-1.15.3 the KCM service is testable (there are known issues, though) and as per the change process, should be enabled by default in order for the change to be considered complete. * Does the service require post-rpm-installation configuration in order to be useful (for example, does it need manual edits to a configuration file)? In order to be useful, yes, the libkrb5 configuration needs to specify that KCM should be the default ccache type. In order to achieve this, the sssd-kcm package already ships an example krb5.conf snippet. Currently the snippet is located under /usr/share - our plan is to, if this request to enable the sssd-kcm.socket is accepted, install the snippet into /etc/krb5.conf.d instead. Then, just having the sssd-kcm package in itself would enable the functionality. * Does the service listen on a network socket for connections originating on a separate physical or virtual machine? No, this is a UNIX local socket (AF_UNIX) * Is the service non-persistent (i.e. run once at startup and exit)? No, it is persistent. (the service exits on idle, though and is started on the next request). * What is the exact name (or names) of the systemd unit files to be enabled? sssd-secrets.socket sssd-kcm.socket (sssd-secrets acts as a storage for sssd-kcm) * Is this request for all Fedora deliverables or only for some Editions (list them)? IMO all. The next question then would be whether to include sssd-kcm in the default comps group, but that should be handled separately.
Well, of course I goofed up one sentence. This: """ our plan is to, if this request to enable the sssd-kcm.socket is accepted, """ should read: """ our plan is to, if this request *is accepted*, to enable the sssd-kcm.socket is accepted, """ where's the edit button? :)
(In reply to Jakub Hrozek from comment #0) > Enabling these services is needed to complete > https://fedoraproject.org/wiki/Changes/KerberosKCMCache > > As of sssd-1.15.3 the KCM service is testable (there are known issues, > though) and as per the change process, should be enabled by default in order > for the change to be considered complete. > > * Does the service require post-rpm-installation configuration in order to > be useful (for example, does it need manual edits to a configuration file)? > > In order to be useful, yes, the libkrb5 configuration needs to specify that > KCM should be the default ccache type. In order to achieve this, the > sssd-kcm package already ships an example krb5.conf snippet. Currently the > snippet is located under /usr/share - our plan is to, if this request to > enable the sssd-kcm.socket is accepted, install the snippet into > /etc/krb5.conf.d instead. Then, just having the sssd-kcm package in itself > would enable the functionality. > I think this is a little unclear (or perhaps the original question is unclear). Changes made by RPM installation are fine. The question is mainly about whether attempting to start the service will succeed if no other actions are taken besides installation of the package providing the unit file. So, specifically for this case, assuming a clean install of Fedora 26 today, can I: 1) `dnf install sssd-kcm` 2) reboot and have the service succeed (or auto-terminate without error) on boot if we add this to presets? Or will the user need to make manual changes after installing the package?
BTW: If kcm socket does not work then klist say it cannot connect. sh$ klist -l klist: Connection refused while listing ccache collection We might extend krb5-message in fedora to say: sh$ klist -l klist: Connection refused while listing ccache collection You might want to start sssd-kcm.socket or remove sssd-kcm package if you do not want to use KCM ccache. Or some better more informative message. Because even though sssd-kcm.socket will be enabled in distribution via preset files there still a possibility that somebody can accidentally disable sssd-kcm.socket
I'm sorry for the late reply, I was AFK on Friday. (In reply to Stephen Gallagher from comment #2) > (In reply to Jakub Hrozek from comment #0) > > Enabling these services is needed to complete > > https://fedoraproject.org/wiki/Changes/KerberosKCMCache > > > > As of sssd-1.15.3 the KCM service is testable (there are known issues, > > though) and as per the change process, should be enabled by default in order > > for the change to be considered complete. > > > > * Does the service require post-rpm-installation configuration in order to > > be useful (for example, does it need manual edits to a configuration file)? > > > > In order to be useful, yes, the libkrb5 configuration needs to specify that > > KCM should be the default ccache type. In order to achieve this, the > > sssd-kcm package already ships an example krb5.conf snippet. Currently the > > snippet is located under /usr/share - our plan is to, if this request to > > enable the sssd-kcm.socket is accepted, install the snippet into > > /etc/krb5.conf.d instead. Then, just having the sssd-kcm package in itself > > would enable the functionality. > > > > I think this is a little unclear (or perhaps the original question is > unclear). Changes made by RPM installation are fine. The question is mainly > about whether attempting to start the service will succeed if no other > actions are taken besides installation of the package providing the unit > file. > The service startup /should/ work fine. I will retest this tomorrow (Mon Jul-31) to be sure, though. What I was trying to say above (admittedly, in a convoluted way) was that in order for the service to not only start, but also be useful by libkrb5, we need both the service running and the krb5.conf.d snippet. I guess the reason why I tried to be overly verbose is that we need to install the krb5.conf.d snippet that changes the default ccache type to KCM: for the KCM-by-default to actually happen. But, if the snippet is there and libkrb5 tries to use the KCM: ccache BUT the KCM deamon is not running, then kinit would just return connection refused (as comment #3 says). > So, specifically for this case, assuming a clean install of Fedora 26 today, > can I: > 1) `dnf install sssd-kcm` > 2) reboot > and have the service succeed (or auto-terminate without error) on boot if we > add this to presets? Or will the user need to make manual changes after > installing the package? If you just do the above, the service will run, but not be useful (simply because there is nothing that would talk to the socket).
(In reply to Jakub Hrozek from comment #4) > (In reply to Stephen Gallagher from comment #2) > > So, specifically for this case, assuming a clean install of Fedora 26 today, > > can I: > > 1) `dnf install sssd-kcm` > > 2) reboot > > and have the service succeed (or auto-terminate without error) on boot if we > > add this to presets? Or will the user need to make manual changes after > > installing the package? > > If you just do the above, the service will run, but not be useful (simply > because there is nothing that would talk to the socket). So, if the service isn't useful without additional changes, this is not eligible for auto-starting. Have you considered making the service start contingent upon the presence of the krb5.conf.d snippet? You can modify the sssd-kcm.socket unit file to include: ``` ConditionPathExists = /etc/krb5.conf.d/kcm_default_ccache ``` Then the service will autostart if the file is present and will gracefully skip if the file is not present.
(In reply to Stephen Gallagher from comment #5) > (In reply to Jakub Hrozek from comment #4) > > (In reply to Stephen Gallagher from comment #2) > > > So, specifically for this case, assuming a clean install of Fedora 26 today, > > > can I: > > > 1) `dnf install sssd-kcm` > > > 2) reboot > > > and have the service succeed (or auto-terminate without error) on boot if we > > > add this to presets? Or will the user need to make manual changes after > > > installing the package? > > > > If you just do the above, the service will run, but not be useful (simply > > because there is nothing that would talk to the socket). > > So, if the service isn't useful without additional changes, this is not > eligible for auto-starting. /etc/krb5.conf.d/kcm_default_ccache will be part of sssd-kcm. So it will not require additional changes. If sssd-kcm will be installed then default ccache will be KCM: and if it will not be installed then default value will be KEYRING: (due to default in /etc/krb5.conf > Have you considered making the service start > contingent upon the presence of the krb5.conf.d snippet? You can modify the > sssd-kcm.socket unit file to include: In theory, sb can accidentally remove /etc/krb5.conf.d/kcm_default_ccache. But in this case, running sssd-kcm will be unused due to default ccace KEYRING: System will be still functional. > ``` > ConditionPathExists = /etc/krb5.conf.d/kcm_default_ccache > ``` > > Then the service will autostart if the file is present and will gracefully > skip if the file is not present. The only problem would be in case that file /etc/krb5.conf.d/kcm_default_ccache exists (installed as part of package sssd-kcm) but service is not running. And that's the reason why we need to configure with systemd preset.
OK, so you misled me with comment #4 where you told me it was possible for the system to start the sssd-kcm.socket and never use it (which would be wasteful). However, the reality is that the same package that provides the sssd-kcm.socket file also provides the necessary krb5.conf.d snippet for use with it. So, assuming we approve this request, the only way that this service could be running and not being used would be after a manual edit (removing or altering the krb5.conf.d snippet installed alongside the sssd-kcm.socket file). In that case, I think this meets the requirements for default enablement. Please confirm that I have described that accurately and I'll submit a PR for the presets.
(In reply to Stephen Gallagher from comment #7) > OK, so you misled me with comment #4 where you told me it was possible for > the system to start the sssd-kcm.socket and never use it (which would be > wasteful). > > However, the reality is that the same package that provides the > sssd-kcm.socket file also provides the necessary krb5.conf.d snippet for use > with it. Yes, it does, but right now the snippet is not installed to the location where likrb5 reads the snippets from (/etc/krb5.conf.d) but into /usr/share only. If this request is approved, we'll change the location so that the file is installed into /etc/krb5.conf.d > So, assuming we approve this request, the only way that this > service could be running and not being used would be after a manual edit > (removing or altering the krb5.conf.d snippet installed alongside the > sssd-kcm.socket file). > Correct. > In that case, I think this meets the requirements for default enablement. > Please confirm that I have described that accurately and I'll submit a PR > for the presets.
PR submitted: https://pagure.io/fedora-release/pull-request/111
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'.
Long ago fixed.