Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Duplicate sssd_pac process when using IPA backend #5013

Closed
sssd-bot opened this issue May 2, 2020 · 3 comments
Closed

Duplicate sssd_pac process when using IPA backend #5013

sssd-bot opened this issue May 2, 2020 · 3 comments
Labels
Closed: Fixed Issue was closed as fixed. Future milestone Future work

Comments

@sssd-bot
Copy link

sssd-bot commented May 2, 2020

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/4045

  • Created at 2019-07-15 18:29:46 by yrro
  • Assigned to nobody

sssd-pac.socket uses the usual mechanism for preventing it from starting while services = pac is present in sssd.conf:

ExecStartPre=/usr/libexec/sssd/sssd_check_socket_activated_responders -r pac

However, in the case that sssd is configured to use a backend using the IPA provider and services is not set, or is set but does not contain pac, then the add_implicit_services function will add the pac to the service list at run time. This is not detected by sssd_check_socket_activated_reponders and you end up with two instances of sssd_pac running, one spawned by sssd and the other by systemd.

Quick and dirty fix: modify sssd_check_socket_activated_responders to use the same logic as sssd, that is, fail if any domain section in sssd.conf has id_provider = ipa.

Comments

Comment from pbrezina at 2020-03-13 14:36:07

Metadata Update from @pbrezina:

  • Issue tagged with: Future milestone
@alexey-tikhonov
Copy link
Member

There is now implicit_pac_responder sssd.conf option that allows to, at least, disable monitor's activated implicit pac responder if socket activated responder is preferred.

Ideally sssd_check_socket_activated_responders should get smarter, of course.

@alexey-tikhonov
Copy link
Member

alexey-tikhonov commented Aug 29, 2023 •
edited
Loading

Ideally sssd_check_socket_activated_responders should get smarter, of course.

Btw, ad85fc3 by @fidencio could resolve this :)
+ d85afcc

alexey-tikhonov added a commit to alexey-tikhonov/sssd that referenced this issue Sep 18, 2024
@alexey-tikhonov
SYSTEMD: replace 'sssd_check_socket_activated_responders'
d9037b6 
with shell one-liner

All sockets already have
```
After=sssd.service
BindsTo=sssd.service
```
 - this ensures SSSD was started and running before socket
activation. It's much easier to simply check if corresponding
responder is already running than to parse sssd.conf or
config.ldb

Resolves: SSSD#5013
alexey-tikhonov added a commit to alexey-tikhonov/sssd that referenced this issue Sep 18, 2024
@alexey-tikhonov
SYSTEMD: replace 'sssd_check_socket_activated_responders'
ed27c92 
with shell one-liner

All sockets already have
```
After=sssd.service
BindsTo=sssd.service
```
 - this ensures SSSD was started and running before socket
activation. It's much easier to simply check if corresponding
responder is already running than to parse sssd.conf or
config.ldb

Resolves: SSSD#4333
Resolves: SSSD#5013
@alexey-tikhonov alexey-tikhonov mentioned this issue Sep 18, 2024
Closed
alexey-tikhonov added a commit to alexey-tikhonov/sssd that referenced this issue Sep 19, 2024
@alexey-tikhonov
SYSTEMD: replace 'sssd_check_socket_activated_responders'
024c9b8 
with shell one-liner

All sockets already have
```
After=sssd.service
BindsTo=sssd.service
```
 - this ensures SSSD was started and running before socket
activation. It's much easier to simply check if corresponding
responder is already running than to parse sssd.conf or
config.ldb

Resolves: SSSD#4333
Resolves: SSSD#5013
alexey-tikhonov added a commit to alexey-tikhonov/sssd that referenced this issue Sep 19, 2024
@alexey-tikhonov
SYSTEMD: replace 'sssd_check_socket_activated_responders'
679d308 
with shell one-liner

All sockets already have
```
After=sssd.service
BindsTo=sssd.service
```
 - this ensures SSSD was started and running before socket
activation. It's much easier to simply check if corresponding
responder is already running than to parse sssd.conf or
config.ldb

Resolves: SSSD#4333
Resolves: SSSD#5013
alexey-tikhonov added a commit to alexey-tikhonov/sssd that referenced this issue Sep 20, 2024
@alexey-tikhonov
SYSTEMD: replace 'sssd_check_socket_activated_responders'
fd6530e 
with a schell script.

All sockets already have
```
After=sssd.service
BindsTo=sssd.service
```
 - this ensures SSSD was started and running before socket
activation.

New 'ExecStartPre' condition checks if a responder with the
same name is running and, if so, if it runs in the same
mnt namespace. The latter is to ignore processes run in
a container on the same host.

Resolves: SSSD#4333
Resolves: SSSD#5013
alexey-tikhonov added a commit to alexey-tikhonov/sssd that referenced this issue Sep 20, 2024
@alexey-tikhonov
SYSTEMD: replace 'sssd_check_socket_activated_responders'
cceb66a 
with a schell script.

All sockets already have
```
After=sssd.service
BindsTo=sssd.service
```
 - this ensures SSSD was started and running before socket
activation.

New 'ExecStartPre' condition checks if a responder with the
same name is running and, if so, if it runs in the same
mnt namespace. The latter is to ignore processes run in
a container on the same host.

Resolves: SSSD#4333
Resolves: SSSD#5013
alexey-tikhonov added a commit to alexey-tikhonov/sssd that referenced this issue Oct 9, 2024
@alexey-tikhonov
socket_activated_responders: check confdb
16604ca 
(instead of sssd.conf) using new helper to take into
account implictly configured services.

Resolves: SSSD#5013
@alexey-tikhonov alexey-tikhonov mentioned this issue Oct 9, 2024
Closed
alexey-tikhonov added a commit to alexey-tikhonov/sssd that referenced this issue Oct 9, 2024
@alexey-tikhonov
socket_activated_responders: check confdb
e9715b1 
(instead of sssd.conf) using new helper to take into
account implictly configured services.

Resolves: SSSD#5013
alexey-tikhonov added a commit to alexey-tikhonov/sssd that referenced this issue Oct 10, 2024
@alexey-tikhonov
socket_activated_responders: check confdb
cb8932e 
(instead of sssd.conf) using new helper to take into
account implictly configured services.

Resolves: SSSD#5013
alexey-tikhonov added a commit to alexey-tikhonov/sssd that referenced this issue Oct 11, 2024
@alexey-tikhonov
socket_activated_responders: check confdb
c1a1edc 
(instead of sssd.conf) using new helper to take into
account implictly configured services.

Resolves: SSSD#5013
@alexey-tikhonov
Copy link
Member

Pushed PR: #7638

  • master
    • 9bb7b92 - CONFDB: mistype fix
    • dbf4763 - CONFDB: don't hard fail in add_implicit_services()
    • 272ee81 - TESTS:INTG: 'implicit files domain' not supported
    • 32e7616 - socket_activated_responders: log to syslog instead of stdout
    • 59c48f7 - socket_activated_responders: check confdb
    • 28bb146 - IFP: use new helper to retrieve services list
    • 7f0f5a6 - CONFDB: introduce helper to read a full list of configured services,
    • c9026bf - Move 'nscd' helper functions out of 'utils'

@alexey-tikhonov alexey-tikhonov added the Closed: Fixed Issue was closed as fixed. label Oct 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Closed: Fixed Issue was closed as fixed. Future milestone Future work
Projects
None yet
Milestone
No milestone
3 participants
@andreboscatto @alexey-tikhonov @sssd-bot