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.
How do we prevent systemd to start a responder in case the responder
has been already started by the monitor?
How do you cope with this "mixed" scenario?
>
>>>
>>>>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.
>
> LS
> _______________________________________________
> sssd-devel mailing list -- sssd-devel(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-devel-leave(a)lists.fedorahosted.org