Hi,
at the moment the services (aka responders) that SSSD starts must be listed explicitly in the 'services' line in the [sssd] section of sssd.conf. For services like PAM, NSS or even sudo, this is not too problematic, just inconvenient and we have plans to socket-activate the responders: https://fedorahosted.org/sssd/ticket/2243
I could swear we also had an option to get rid of the 'services' option completely but I only found a ticket to get rid of the 'domains': https://fedorahosted.org/sssd/ticket/2230
For the ifp service, we could do something similar as planned for domains and take advantage of the bus-activation. Patches that bus-activate the ifp responder are alrady on review: https://lists.fedorahosted.org/pipermail/sssd-devel/2014-July/020471.html But these patches only deal with the case where messagebus was started before sssd.
We could take advantage of the socket-activation even sooner than we get to implementing #2243. The proposal was: - if 'services' are not specified, use the default list (nss, pam). If a request arrived to the system bus, socket-activate ifp - if 'services' were specified, treat that as a canonical list and don't activate the ifp responder
But my opinion is that we have already quite a lot of work for 1.12 and we should implement bus-activating the ifp responder together with the socket activation in 1.13. But if any of the projects that use or plan to use our DBus API would see adding the 'ifp' to the list of services as problematic, we should reconsider #2242 for inclusion in 1.12.x
On a related note, the dbus responder is currently packaged in its own subpackage that is not dragged in when the user yum installs the 'sssd' meta-package. That's because the sssd-dbus subpackage has some additional dependencies admins might not like to have installed by default. From the point of view of users of our DBus service, is this expected and/or acceptable? Or would it be more expected to have the whole lot after installing the 'sssd' package?
Thoughts?
On Thu, 2014-07-03 at 12:38 +0200, Jakub Hrozek wrote:
Hi,
at the moment the services (aka responders) that SSSD starts must be listed explicitly in the 'services' line in the [sssd] section of sssd.conf. For services like PAM, NSS or even sudo, this is not too problematic, just inconvenient and we have plans to socket-activate the responders: https://fedorahosted.org/sssd/ticket/2243
I could swear we also had an option to get rid of the 'services' option completely but I only found a ticket to get rid of the 'domains': https://fedorahosted.org/sssd/ticket/2230
For the ifp service, we could do something similar as planned for domains and take advantage of the bus-activation. Patches that bus-activate the ifp responder are alrady on review: https://lists.fedorahosted.org/pipermail/sssd-devel/2014-July/020471.html But these patches only deal with the case where messagebus was started before sssd.
We could take advantage of the socket-activation even sooner than we get to implementing #2243. The proposal was: - if 'services' are not specified, use the default list (nss, pam). If a request arrived to the system bus, socket-activate ifp - if 'services' were specified, treat that as a canonical list and don't activate the ifp responder
But my opinion is that we have already quite a lot of work for 1.12 and we should implement bus-activating the ifp responder together with the socket activation in 1.13. But if any of the projects that use or plan to use our DBus API would see adding the 'ifp' to the list of services as problematic, we should reconsider #2242 for inclusion in 1.12.x
On a related note, the dbus responder is currently packaged in its own subpackage that is not dragged in when the user yum installs the 'sssd' meta-package. That's because the sssd-dbus subpackage has some additional dependencies admins might not like to have installed by default. From the point of view of users of our DBus service, is this expected and/or acceptable? Or would it be more expected to have the whole lot after installing the 'sssd' package?
Thoughts?
My thoughts are that we should defer to 1.13, and do the bus-activation work once and right for all services. I do agree we need a way to be also able to filter out services. If someone does *not* want ifp it shouldn't be started so I am totally in agreement on doing bus-activation if services is absent. If it is not absent treat the list as authoritative and final.
The ifp subpackage, imo, should not be installed by default and, at most be a dependency for apps that use it. The monitor can check for existence of the binary and not (socket)activate it if not present and not explicitly listed in services. If explicitly listed a critical error should be logged at startup.
Simo.
On Thu, Jul 03, 2014 at 07:44:25AM -0400, Simo Sorce wrote:
On Thu, 2014-07-03 at 12:38 +0200, Jakub Hrozek wrote:
Hi,
at the moment the services (aka responders) that SSSD starts must be listed explicitly in the 'services' line in the [sssd] section of sssd.conf. For services like PAM, NSS or even sudo, this is not too problematic, just inconvenient and we have plans to socket-activate the responders: https://fedorahosted.org/sssd/ticket/2243
I could swear we also had an option to get rid of the 'services' option completely but I only found a ticket to get rid of the 'domains': https://fedorahosted.org/sssd/ticket/2230
For the ifp service, we could do something similar as planned for domains and take advantage of the bus-activation. Patches that bus-activate the ifp responder are alrady on review: https://lists.fedorahosted.org/pipermail/sssd-devel/2014-July/020471.html But these patches only deal with the case where messagebus was started before sssd.
We could take advantage of the socket-activation even sooner than we get to implementing #2243. The proposal was: - if 'services' are not specified, use the default list (nss, pam). If a request arrived to the system bus, socket-activate ifp - if 'services' were specified, treat that as a canonical list and don't activate the ifp responder
But my opinion is that we have already quite a lot of work for 1.12 and we should implement bus-activating the ifp responder together with the socket activation in 1.13. But if any of the projects that use or plan to use our DBus API would see adding the 'ifp' to the list of services as problematic, we should reconsider #2242 for inclusion in 1.12.x
On a related note, the dbus responder is currently packaged in its own subpackage that is not dragged in when the user yum installs the 'sssd' meta-package. That's because the sssd-dbus subpackage has some additional dependencies admins might not like to have installed by default. From the point of view of users of our DBus service, is this expected and/or acceptable? Or would it be more expected to have the whole lot after installing the 'sssd' package?
Thoughts?
My thoughts are that we should defer to 1.13, and do the bus-activation work once and right for all services.
That's exactly what I think, thanks.
I do agree we need a way to be also able to filter out services. If someone does *not* want ifp it shouldn't be started so I am totally in agreement on doing bus-activation if services is absent. If it is not absent treat the list as authoritative and final.
Ack
The ifp subpackage, imo, should not be installed by default and, at most be a dependency for apps that use it. The monitor can check for existence of the binary and not (socket)activate it if not present and not explicitly listed in services. If explicitly listed a critical error should be logged at startup.
Also ack.
btw the reason we have the 'sssd' meta package at all is mostly to provide a clean upgrade path from the old packaging schema where everything but the tools was in the sssd package towards the current schema with package-per-provider.
On Thu, Jul 03, 2014 at 12:38:02PM +0200, Jakub Hrozek wrote:
We could take advantage of the socket-activation even sooner than we get to implementing #2243. The proposal was: - if 'services' are not specified, use the default list (nss, pam). If a request arrived to the system bus, socket-activate ifp - if 'services' were specified, treat that as a canonical list and don't activate the ifp responder
Agreed.
But my opinion is that we have already quite a lot of work for 1.12 and we should implement bus-activating the ifp responder together with the socket activation in 1.13. But if any of the projects that use or plan to use our DBus API would see adding the 'ifp' to the list of services as problematic, we should reconsider #2242 for inclusion in 1.12.x
On a related note, the dbus responder is currently packaged in its own subpackage that is not dragged in when the user yum installs the 'sssd' meta-package. That's because the sssd-dbus subpackage has some additional dependencies admins might not like to have installed by default. From the point of view of users of our DBus service, is this expected and/or acceptable? Or would it be more expected to have the whole lot after installing the 'sssd' package?
Users of sssd-dbus are typically applications and they can pull in the package via rpm dependencies if they need to. I wouldn't put it under sssd just yet -- maybe few years down the road it will become so widely used that it will be natural to have it in the list. I don't think we are there yet.
sssd-devel@lists.fedorahosted.org
-
Jakub Hrozek -
Jan Pazdziora -
Simo Sorce