Re: [SSSD] Bus-activating the IFP responder by default
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