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.
Okay, in order to actually start solving the issue I'd like to propose
the follow steps:
1) Create a new service, still explicitly enabled in sssd.conf, that
would take care of the managing the SSSD configuration.
2) Get rid of the code dealing with the SSSD configuration from the
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) socket-activated/bus-activated.
5) Make the IFP responder also bus-activated/socket-activated.
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.
So, do we have to care about systems that don't have systemd support?
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 :-\)?
Thanks in advance,