On Wed, Mar 16, 2022 at 6:04 AM Alexey Tikhonov <atikh...@redhat.com> wrote:
> How would you use SSSD without any domain configured?
I have a host on which I kinit against principals in Kerberos realms
for which the host is not joined and has no other sssd services
running, and I use KCM as the Kerberos credentials cache:
$ sudo dnf install sssd-kcm
$ sudo systemctl enable sssd-kcm.socket
$ kinit someuser@SOME.DOMAIN
I assumed that if I had any sssd services configured for socket
activation, that I should run the monitor. But attempting to do so
with no domains configured yields:
[sssd] [confdb_expand_app_domains] (0x0010): No domains configured, fatal error!
[sssd] [get_monitor_config] (0x0010): Failed to expand application domains
[sssd] [get_monitor_config] (0x0010): No domains configured.
[sssd] [main] (0x0010): SSSD couldn't load the configuration database.
I suppose I could work around this by enabling the files domain using
a minimal sssd.conf configuration; e.g.:
[sssd]
config_file_version = 2
debug_level = 0x0070
domains = files
[domain/files]
id_provider = files
But this is dumb. In this scenario, literally the only reason I am
configuring the files domain is because I am required to configure
*some* domain in order to run the monitor.
But again, per my original question: is it even necessary to run the
monitor at all?
More specifically: for my particular use case of sssd on this host
(KCM only, and kinit only), does running the monitor serve any
purpose?
E.g., does the monitor watch for ticket cleanups/renewals for tickets
added via kinit (versus by sssd as part of the authentication
process)?
> To answer your question: there was (is) an idea to get rid of the
> monitor altogether (and to rely on systemd instead). But currently
> the monitor performs some tasks, like watching changes in network
> interfaces, that needs to be moved to other modules.
How would one perform those tasks if there is no long-running process,
though?
For example, say that KCM can be configured to renew any renewable
tickets in the credential cache, regardless of the mechanism by which
they entered the credential cache. (This may be true for recent sssd
versions; I don’t know.) To do this, there needs to be some sort of
periodic process that is either started or wakes up, examines the
credentials in the cache, and renews any that need to be renewed
(e.g. ones that have less than half of their validity time remaining).
But if KCM is configured for socket activation, instead of running all
the time as one of the monitor’s configured "services" settings, then
unless someone manually pokes at the credentials cache and caused
systemd to activate KCM, there won’t be anything to wake up and check
for credentials that should be renewed.
Overall, the sssd documentation is excellent. But it would be nice if
the documentation explicitly mentioned in what use cases the monitor
should be used. E.g., update the sssd(8) man page with something like
this:
The main sssd service is called the monitor. Its main purpose is
to start the services specified by the “services” option in
sssd.conf, and to perform other service-dependent housekeeping
tasks.
On systemd systems, all sssd sub-services can be configured for
socket-based activation. In this configuration, the “services”
option in sssd.conf can be omitted, in which case the monitor does
not manage any sssd sub-services.
However, because the monitor also performs some housekeeping
tasks, the monitor should still be configured to run, even if no
services are configured, if any of the following conditions is
true:
* The <foo> service is configured for socket activation.
* The <bar> service is configured for socket activation.
* …
If none of the above conditions is true, and all configured sssd
services are launched via systemd socket activation, then there is
no need to run the sssd monitor.
So to summarize, the fact that I can run the KCM service without
configuring any domain (which is a prerequisite for running the
monitor) strongly suggests that there is no need to run the monitor in
that use case. But 1) I’m not convinced this is true, and 2) the
documentation really should explicitly state in which cases it is or
is not necessary to run the monitor.
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
