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.