[SSSD] Bus-activating the IFP responder by default

Jan Pazdziora jpazdziora at redhat.com
Thu Jul 3 13:43:55 UTC 2014


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.

-- 
Jan Pazdziora | adelton at #ipa*, #brno
Principal Software Engineer, Identity Management Engineering, Red Hat



More information about the sssd-devel mailing list