On Wed, Feb 8, 2017 at 12:29 PM, Lukas Slebodnik <lslebodn(a)redhat.com> wrote:
On (08/02/17 12:24), Fabiano Fidêncio wrote:
>On Wed, Feb 8, 2017 at 12:10 PM, Lukas Slebodnik <lslebodn(a)redhat.com> wrote:
>> On (05/02/17 23:24), 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.
>>>
>>>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;
>>> - nss responder's socket is enabled;
>>> - boot the system
>>> - both nss processes will be up
>>>
>> This is pure misconfuguration and I do not think a reason why we shoudl solve
>> it.
>
>Do you prefer to not deal with a misconfiguration scneraio (that may
>not be caused by the admins themselves, but by the packager ...) even
>if we can do that?
>Interesting, at least.
>
Yes, I do not want to deal with misconfiguration.
We might passively detect it and refuse such state.
e.g. Fail if unix sockets are already created(by systemd) and monitor
wants to start responders.
>>
>>>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
>> What is a goal here?
>
>The goal here is be bulletproof against wrong configurations/admins
>trying to do something they're not supposed to.
>But, as far as I understand from your previous comment, it's not of
>your (and thus the project) interest to be robust on these cases.
>
I am not against to be robust. I am against magical workarounding
such misconfuguration.
I do not understand why do you think using systemd when we can using
systemd is a magical workaroud.
>
> LS
> _______________________________________________
> sssd-devel mailing list -- sssd-devel(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-devel-leave(a)lists.fedorahosted.org