For recent versions of sssd, the monitor (the sssd.service) won’t even start unless at least one domain is configured.
As sssd.conf(5) notes, all sssd services can be socket-activated when needed. There is no need to list any services in the "services" parameter in [sssd].
So, this leads to a question: if all configured services are configured via systemd to start via socket activation… then what is the monitor actually monitoring? In this configuration, what does it actually do? And is there any reason to even run the monitor at all?
If the answer is, “the monitor performs necessary housekeeping functions so it should be running even if all services are socket-activated,” then shouldn’t it be the case that the monitor should run even if no domains are configured?
Hi,
On Wed, Mar 16, 2022 at 5:17 AM James Ralston ralston@pobox.com wrote:
For recent versions of sssd, the monitor (the sssd.service) won’t even start unless at least one domain is configured.
As sssd.conf(5) notes, all sssd services can be socket-activated when needed. There is no need to list any services in the "services" parameter in [sssd].
So, this leads to a question: if all configured services are configured via systemd to start via socket activation… then what is the monitor actually monitoring? In this configuration, what does it actually do? And is there any reason to even run the monitor at all?
If the answer is, “the monitor performs necessary housekeeping functions so it should be running even if all services are socket-activated,” then shouldn’t it be the case that the monitor should run even if no domains are configured?
How would you use SSSD without any domain configured?
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.
On Wed, Mar 16, 2022 at 6:04 AM Alexey Tikhonov atikhono@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.
On Thu, Mar 17, 2022 at 12:27 AM James Ralston ralston@pobox.com wrote:
On Wed, Mar 16, 2022 at 6:04 AM Alexey Tikhonov atikhono@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 = filesBut 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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Fri, Mar 18, 2022 at 5:10 AM Alexey Tikhonov atikhono@redhat.com wrote:
On Thu, Mar 17, 2022 at 12:27 AM James Ralston ralston@pobox.com wrote:
On Wed, Mar 16, 2022 at 6:04 AM Alexey Tikhonov atikhono@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 = filesBut 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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
sssd-users@lists.fedorahosted.org
-
Alexey Tikhonov -
James Ralston -
Justin Stephenson