Avoid running two instances of the same service (#3300)

[Fabiano Fidêncio]

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

- Scenario 2
  - any responder is explicitly activated
  - systemctl enable sssd-@responder@.service

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

[Fabiano Fidêncio]

On Sun, Feb 5, 2017 at 11:24 PM, Fabiano Fidêncio <fidencio(a)redhat.com&gt; 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
>
>  - Scenario 2
>    - any responder is explicitly activated
>    - systemctl enable sssd-@responder@.service
>
>  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. 
This discussion can be done on https://github.com/SSSD/sssd/pull/146

Best Regards,
--
Fabiano Fidêncio

[Pavel Březina]

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?

>    - nss responder's socket is enabled; 
systemctl enable sssd-nss.socket?

>    - boot the system
>    - both nss processes will be up 
Why?

>  - 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?

Why we end up running it twice?

>  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

[Fabiano Fidêncio]

On Tue, Feb 7, 2017 at 12:20 PM, Pavel Březina <pbrezina(a)redhat.com&gt; 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

[Pavel Březina]

On 02/07/2017 12:31 PM, Fabiano Fidêncio wrote:
>  On Tue, Feb 7, 2017 at 12:20 PM, Pavel Březina
> <pbrezina(a)redhat.com&gt; 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? 
Yes, thank you for explanation. Is it possible to use sd_notify() in 
responders to tell systemd that the service is running?

[Fabiano Fidêncio]

On Tue, Feb 7, 2017 at 12:58 PM, Pavel Březina <pbrezina(a)redhat.com&gt; wrote:
>  On 02/07/2017 12:31 PM, Fabiano Fidêncio wrote:
> >
> > On Tue, Feb 7, 2017 at 12:20 PM, Pavel Březina <pbrezina(a)redhat.com&gt;
> > 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?
>
>
>  Yes, thank you for explanation. Is it possible to use sd_notify() in
>  responders to tell systemd that the service is running? 
I've checked that and as far I as understand it wouldn't work as the
service has not been started by systemd.
Thus I've taken the approach to prefer systemd to monitor whenever
it's possible.

>
>
> _______________________________________________
> sssd-devel mailing list -- sssd-devel(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-devel-leave(a)lists.fedorahosted.org

[Pavel Březina]

On 02/07/2017 01:03 PM, Fabiano Fidêncio wrote:
>  On Tue, Feb 7, 2017 at 12:58 PM, Pavel Březina
> <pbrezina(a)redhat.com&gt; wrote:
> > On 02/07/2017 12:31 PM, Fabiano Fidêncio wrote:
> >>
> >> On Tue, Feb 7, 2017 at 12:20 PM, Pavel Březina <pbrezina(a)redhat.com&gt;
> >> 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?
> >
> >
> > Yes, thank you for explanation. Is it possible to use sd_notify() in
> > responders to tell systemd that the service is running?
>
>  I've checked that and as far I as understand it wouldn't work as the
>  service has not been started by systemd. 
sd_notify talks through $NOTIFY_SOCKET env variable. Can you ask systemd 
guys if this can be somehow set/created manually by the service? If it 
can be done, this would be definitely the easiest way to do it.

Or maybe sd_pid_notify will work if there will be a pid file present?

Also how would systemd react if sssd responder shutdown if a process 
already exists? The idea is that during the registration phase will 
monitor send error that responder is already started and the new process 
would exit.

>  Thus I've taken the approach to prefer systemd to monitor
> whenever
>  it's possible.

[Lukas Slebodnik]

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.

> 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? Why do we want to bypass monitor?

LS

[Fabiano Fidêncio]

On Wed, Feb 8, 2017 at 12:10 PM, Lukas Slebodnik <lslebodn(a)redhat.com&gt; 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.

> >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.

>  Why do we want to bypass monitor? 
I want to leave the responsibility to start a service to systemd
whenever it's possible.
Why? To avoid having two services of the same responder running.

Those patches are not strict needed unless we care at least a little
about robustness of SSSD.

Best Regards,

[Lukas Slebodnik]

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&gt; 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.

LS

[Fabiano Fidêncio]

On Wed, Feb 8, 2017 at 12:29 PM, Lukas Slebodnik <lslebodn(a)redhat.com&gt; 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&gt; 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

[Lukas Slebodnik]

On (08/02/17 12:33), Fabiano Fidêncio wrote:
> On Wed, Feb 8, 2017 at 12:29 PM, Lukas Slebodnik
> <lslebodn(a)redhat.com&gt; 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&gt;
> 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?
>  
Systemd sockets are created earlier in the boot phase.
So this situation will not happen at boot.

And if sssd is already started I wonder how systemd can create
sockets which are already owned by other process.

LS

[Fabiano Fidêncio]

On Wed, Feb 8, 2017 at 1:14 PM, Lukas Slebodnik <lslebodn(a)redhat.com&gt; wrote:
>  On (08/02/17 12:33), Fabiano Fidêncio wrote:
> >On Wed, Feb 8, 2017 at 12:29 PM, Lukas Slebodnik <lslebodn(a)redhat.com&gt; 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&gt;
> 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?
> >
>  Systemd sockets are created earlier in the boot phase. 
They are because systemd automatically adds any socket to be started
during sockets.target start up, but they shouldn't according to our
design page.
According to the design page the sockets would be started when SSSD is started.

May be the case the design done is wrong? Of course.
So, let's get back to the design page as the first thing and solve the
problems we have there.

> So this situation will not happen at boot.
>
> And if sssd is already started I wonder how systemd can create
> sockets which are already owned by other process.
>
> LS
> _______________________________________________
> sssd-devel mailing list -- sssd-devel(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-devel-leave(a)lists.fedorahosted.org

[Fabiano Fidêncio]

On Wed, Feb 8, 2017 at 12:29 PM, Lukas Slebodnik <lslebodn(a)redhat.com&gt; 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&gt; 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

[Lukas Slebodnik]

On (08/02/17 12:37), Fabiano Fidêncio wrote:
> On Wed, Feb 8, 2017 at 12:29 PM, Lukas Slebodnik
> <lslebodn(a)redhat.com&gt; 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&gt;
> 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.
>  
Pulling info from systemd and checking state of services/sockets
is a magical workaround.

LS