On Fri, Mar 18, 2022 at 5:10 AM Alexey Tikhonov <atikhono(a)redhat.com> wrote:
On Thu, Mar 17, 2022 at 12:27 AM James Ralston <ralston(a)pobox.com> wrote:
>
> On Wed, Mar 16, 2022 at 6:04 AM Alexey Tikhonov <atikhono(a)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(a)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?
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.
In your described case, you should be able to start sssd-kcm and use
it without any sssd.conf configured.
> 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.
If KCM renewal is configured then the idle timeout is disabled to
allow for renewals to occur. Perhaps this can be more clearly stated
in documentation.
>
> > 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 -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)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.fedorahoste...
> Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure