On 08/31/2016 01:40 PM, Fabiano Fidêncio wrote:
Taking a look on https://fedorahosted.org/sssd/ticket/2395
there are a few ways to achieve what's proposed by Simo and I'd like
to discuss one of those before start implementing it.
As far as I understand the bug, SSSD cannot be run as a non-root user
because of IFP responder, which needs to be run as root in order to
write to sssd.conf file. Simo's suggestion was to create a new
service, which should be socket-activated, to handle this writing to
sssd.conf part and Jakub's suggested to completely get rid of this
part. However, Dmitri pointed out that we must have some service
playing with sssd.conf as it's the way that cockpit and ansible can
remotely manage the SSSD configuration.
Well... we do have the SSSDConfigAPI, which is a python API. That's going to
cover the Ansible case, I should think. That said, it would be *really* nice if
we could have a public API that tools like Cockpit or realmd could use (or even
the mythical authconfig rewrite we keep hearing about).
With OpenLMI officially deceased, I don't believe that the code we have
available currently is actually consumed by anyone, so I'm slightly in favor of
just killing it off entirely and implementing the new service if and when we
have a specific use-case that would make it valuable.
Okay, in order to actually start solving the issue I'd like to
the follow steps:
1) Create a new service, still explicitly enabled in sssd.conf, that
would take care of the managing the SSSD configuration.
Not possible; such a service would need to be capable of generating the initial
configuration if none exists yet. So having explicit enablement in sssd.conf
would be a circular dependency.
2) Get rid of the code dealing with the SSSD configuration from the
*Grabs the flamethrower*
3) Get rid of the OpenLMI specific code from the IFP responder
Till this point the problem wasn't solved at all, but those seem to be
the logical steps in order to make our own lives easier for working in
the next two steps.
4) Make the new service (created in 1)
This seems less like another step and more like a design requirement for the
config service, but yes.
5) Make the IFP responder also bus-activated/socket-activated.
This is definitely something we want to accomplish, but it seems somewhat out of
place in the current discussion.
So, does it sound like a reasonable way to approach the problem?
If yes, I'd like to ask a few questions, mainly about items 4 and 5,
as it eems that in order to achieve what we want,
have to be solved together,
which seems to be a not so small task.
I don't think these need to be solved together at all. It can be iterative (we
can use the IFP responder as a proof-of-concept).
So, do we have to care about systems that don't have systemd
IOW, do we have to keep the current code and also add
socket-activation? If yes, would it be explicitly enabled/disabled on
configure time? Maybe a lame question, but what are the advantages of
the socket-activation over the bus-activation approach (I still didn't
look at any of those :-\)?
At least in the case of IFP, I think it makes sense to just do things via D-BUS
activation. It will be compatible with any D-BUS system, not just systemd platforms.
I think there's a conversation to be had about dropping support for non-systemd
platforms and aligning the responders in general (ticket 2243) with systemd
socket activation for power-consumption reasons, but I think that's a separate
and much larger change than this one needs to be.