On Tue, Feb 7, 2017 at 12:20 PM, Pavel Březina <pbrezina(a)redhat.com> wrote:
On 02/05/2017 11:24 PM, Fabiano Fidêncio wrote:
>
> I've spent some amount of time trying to properly deal with this issue
> and I really need the opinion/suggestion of more experienced
> developers.
Hi, I'm not sure I understand it correctly so let us clarify it.
> Basically, as explained in #3300 this situation can happen is two
> scenarios were the admin is mixing up socket-activated and explicitly
> configured services:
> - Scenario 1:
> - nss responder is explicitly activated;
This means services = nss in sssd.conf, right?
Yes, services = nss
> - nss responder's socket is enabled;
systemctl enable sssd-nss.socket?
Yes, systemctl enable sssd-nss.socket
> - boot the system
> - both nss processes will be up
Why?
As far as I have debugged what happens is:
- monitor will start NSS responder because it's part of services line;
- sssd-nss.socket will be up as, considering how the git master code
is, it's part of sockets.target;
- if any request goes to the nss socket, it will bring
sssd-nss.service up and as the first was started by the monitor,
systemd has no idea about a nss responder already running;
> - Scenario 2
> - any responder is explicitly activated
> - systemctl enable sssd-@responder@.service
In scenario 1 we are talking about socket, here about service. Is this
correct or a typo?
That's a typo, but in the enable part. Consider the admin has pam
responder in the services line ...
- ssssd starts -> pam responder is running
- admin does: systemctl start sssd-pam.service
You will end up with two pam responders running at the same time.
Why we end up running it twice?
I hope I answered that above ...
> So, what I've thought so far, for each of the scenarios, is:
> - Scenario 1:
> Implement a way to either bypass the monitor in case the responder's
> socket it up or do not start the process through systemd in case one
> instance of the process is already being ran by the monitor. The main
> question here is how to do this without adding more logic to the
> monitor (Lukáš made his opinion quite clear that we should not be
> adding more logic to the monitor and I agree with him ... but maybe
> this case is an exception?) and also decide which of the approaches
> would be the less hackish one.
> Personally I'd go for always leaving the responder's startup to
> systemd, if possible. The main problem with this approach is that
> checking whether a the unit is loaded or not is done through sd-bus
> APIs, which may be to new for some enterprise distros (including
> CentOS here ...) /o\
>
> - Scenario 2:
> Here I do believe we could force the services to not be started
> manually as systemd already provides "RefuseManualStart=" option.
>
>
> I'm really looking forward to hearing your opinion on what would be
> the best approach to take, new ideas and so on.
>
>
> Best Regards,
> --
> Fabiano Fidêncio
So, the path I've taken is:
- If possible, always leave the service to be started up by systemd.
IOW, we check whether the sssd-@responder@.socket is enabled. In case
it is, just do not start the service through the monitor and let it be
socket-activated when neede.
- Refuse manual startup of the responders (and let they be
automatically started up through socket-activation).
Does that make sense?
Best Regards,
--
Fabiano Fidêncio