I installed Fedora, and it installed sssd-kcm by default for some reason. I have zero use for it. When I look for any packages that are dependent on it, it returns nothing. a) why is it installed then? b) what installs it and how to check for what installs it?
Thanks!
1 Like
It is listed as a mandatory package in the core group, so every Fedora Linux installation will always pull that package in (even Fedora Minimal).
$ dnf group info core
Last metadata expiration check: 0:00:17 ago on Fri Oct 25 14:50:18 2024.
Group: Core
Description: Smallest possible installation
Mandatory Packages:
audit
basesystem
bash
coreutils
curl
dhcp-client
dnf
e2fsprogs
filesystem
glibc
hostname
iproute
iputils
kbd
less
man-db
ncurses
openssh-clients
openssh-server
parted
policycoreutils
procps-ng
rootfiles
rpm
rpmfusion-free-release
rpmfusion-nonfree-release
selinux-policy-targeted
setup
shadow-utils
sssd-common
sssd-kcm
sudo
systemd
util-linux
vim-minimal
yum
I think some very light-weight containers need it to handle Kerberos authentication from the host/hypervisor. So, essentially, what depends on it is something that isn’t necessarily installed on the system. Containers are a little odd in that they share the kernel and some memory space with their host and, in this situation, that creates a dependency chain that isn’t fully visible to the package manager. If you don’t know what sssd-kcm is though, you probably don’t need it. 
FWIW, here is some documentation: KCM server for SSSD — SSSD documentation
Use case two from the above documentation was the one I was thinking of:
- An Administrator wants to initialize and ccache centrally and then have the ccache available in all relevant containerized applications, so that applications do not have deal with Kerberos authentication or have access to keytab separately
Ah, thank you so much.
Wouldn’t it make sense to include it with the “Containers” group then?
I don’t see a containers group.
$ dnf group list
Last metadata expiration check: 0:49:24 ago on Fri Oct 25 14:50:18 2024.
Available Environment Groups:
Fedora Custom Operating System
Minimal Install
Fedora Server Edition
Fedora Workstation
Fedora Cloud Server
KDE Plasma Workspaces
Xfce Desktop
Phosh Desktop
LXDE Desktop
LXQt Desktop
Cinnamon Desktop
MATE Desktop
Sugar Desktop Environment
Deepin Desktop
Budgie Desktop
Development and Creative Workstation
Web Server
Infrastructure Server
Basic Desktop
i3 desktop
Installed Environment Groups:
Sway Desktop
Installed Groups:
Administration Tools
Fonts
Hardware Support
Available Groups:
3D Printing
Audio Production
Authoring and Publishing
Budgie
Budgie Desktop Applications
C Development Tools and Libraries
Cloud Infrastructure
Cloud Management Tools
Compiz
Container Management
D Development Tools and Libraries
Design Suite
Desktop accessibility
Development Tools
Domain Membership
Editors
Educational Software
Electronic Lab
Engineering and Scientific
FreeIPA Server
Headless Management
KDE Frameworks 6 Software Development
LibreOffice
MATE Applications
Milkymist
Network Servers
Neuron Modelling Simulators
Office/Productivity
Python Classroom
Python Science
Robotics
RPM Development Tools
Security Lab
Sway Window Manager (supplemental packages)
Text-based Internet
VideoLAN Client
Window Managers
GNOME Desktop Environment
Graphical Internet
KDE (K Desktop Environment)
Games and Entertainment
Sound and Video
System Tools
But yeah, some intermediary group that builds on core just for containers might make sense. (I’m not sure that sssd-kcm is exclusively used by containers though. There might be other applications.)
This.
dnf group list hidden
Then you will see it.
But what has sssd module to do with Containers?
1 Like
The “Container Manager” group would be for the host. sssd-kcm would be most useful in the containers. I don’t think Fedora Linux actually has installation groups for “containers” like it does for the different DEs. I’m not even sure what those would look like. There is quite a broad spectrum of use cases for containers. It might be cool to be able to build/install them with something like dnf --installroot=/var/lib/machines/vpn group install "systemd-nspawn vpn container".
Ok, this literally is extremely bizarre. It just doesn’t feel like there is a prerogative to include sssd-kcm in a default Fedora install, period. It sounds like the only use case is if you intend to authenticate any containers over the network, which is almost never a scenario for a default Fedora install. Liek, it’s bloat? Because it was consuming CPU cycles doing nothing before I deleteded it.
Yeah, you probably have a good point there. It is probably included so things will work “out of the box” on CoreOS and the like. You could add exclude=sssd-kcm to /etc/dnf/dnf.conf if you want to keep it off your system (remove it first or use rpm -e sssd-kcm).
1 Like
Wait, so it’s gonna try to get installed again after you delete it when you do dnf update? How is that? Nothing depends on it.
It is explained in the documentation I linked earlier (KCM server for SSSD — SSSD documentation). I was thinking it was communicating with other containers via the kernel keyring (some memory that is shared between the containers and the host system), but it looks like it actually uses bind-mounted socket files for KCM. (I’m not sure, I’m only vaguely familiar with it myself.)
I don’t think dnf update will do it, but it might when you upgrade to a new release because it is listed in the “core” group (or if you use dnf distro-sync).
Thanks for your take. I do in fact do my own customized installation via scripting. I can’t do kickstart because a) don’t like it for several reasons (although am 100% for customization tools), b) kickstart just cannot do some things I need.
It’s so easy to solve this sssd-kcm issue via a custom install. But I keep running into this issue with Fedora’s groups. They are a bit clunky…and cause this sort of issues. I think there are improvements that can be done…maybe kind of merge the idea of flavors to groups or something to that tune.
All this is minor of course to more advanced users, so many thanks anyway!
1 Like
So… is it a good idea to ask the appropriate group(s) to remove the package from default installation?
FWIW, here is the original PR that added it: PR#277: Add sssd-kcm to default installations - fedora-comps - Pagure.io
You might want to peruse that first.
Edit: Ah! Chasing links leads to the original change request that explains why it is enabled: Changes/KerberosKCMCache - Fedora Project Wiki
1 Like
Thank you so much. I read through this. It is completely unclear what the benefit of this to Fedora would be at all. It talks about benefit to Kerberos/network container stuff (which makes 100% sense), but not to Fedora in general with its use cases. I’m surprised that got voted in, really interesting.
It looks like there was some hesitation:
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.
This is what I’m saying. Zero word why Kerberos stuff is justified to be on by default.
I think it is not supposed to actually run unless it is configured. The “only” cost should be a few hundred kilobytes of files on disk:
$ rpm -ql sssd-kcm
/etc/krb5.conf.d/kcm_default_ccache
/usr/lib/.build-id
/usr/lib/.build-id/80
/usr/lib/.build-id/80/9652bc1b514599e513cccbace98b33bb225846
/usr/lib/systemd/system/sssd-kcm.service
/usr/lib/systemd/system/sssd-kcm.socket
/usr/libexec/sssd/sssd_kcm
/usr/share/man/man8/sssd-kcm.8.gz
/usr/share/man/ru/man8/sssd-kcm.8.gz
/usr/share/man/sv/man8/sssd-kcm.8.gz
/usr/share/man/uk/man8/sssd-kcm.8.gz
/usr/share/sssd-kcm
/usr/share/sssd-kcm/kcm_default_ccache
If you see it consuming CPU cycles when it is not configured to actually do anything, I think that qualifies as a bug.
1 Like
I dunno. Whatever works for you. Bash scripting is, obviously, the most flexible of the existing tools.
I didn’t even find Kickstart documentation to be good enough to even learn of all its capabilities. And you just have to do it a certain way, blah blah. I can’t run it from a running system too?
After reading this thread i noticed it was running (active) on my system (Workstation F40), i’ve since uninstalled it.
(it indeed had used cpu cycles, although not many)