On Wed, Feb 8, 2017 at 12:29 PM, Lukas Slebodnik <lsleb...@redhat.com> wrote:
> On (08/02/17 12:24), Fabiano Fidêncio wrote:
>>On Wed, Feb 8, 2017 at 12:10 PM, Lukas Slebodnik <lsleb...@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@lists.fedorahosted.org
> To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
_______________________________________________
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

Reply via email to