On Thu, Mar 17, 2022 at 12:27 AM James Ralston <[email protected]> wrote:
>
> On Wed, Mar 16, 2022 at 6:04 AM Alexey Tikhonov <[email protected]> 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 [email protected]
>
> 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?
No, IIRC, in the case of 'sssd_kcm' there is no need to have 'monitor'
('sssd') running.
There was a caveat that 'monitor' parses sssd.conf at startup and
converts it to ldb representation. IIRC, it was "fixed" but Justin
should know better.
> E.g., does the monitor watch for ticket cleanups/renewals for tickets
> added via kinit (versus by sssd as part of the authentication
> process)?
No, 'monitor' doesn't perform those tasks.
'sssd_kcm' does ticket renewal and, IIRC, if you enable this feature,
the process will be "long-running" (not socket activated anymore).
But again, Justin can comment better here.
>
> > 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?
Currently backend (per domain) processes ('sssd_be') can't be socket
activated. Only services.
The reason is, as you mentioned, that they have to perform periodic
background tasks.
>
> 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 -- [email protected]
> To unsubscribe send an email to [email protected]
> 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/[email protected]
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
