Does anyone use id_provider=local ?
by Jakub Hrozek
Hi,
are there any SSSD users who actively use a configuration with:
id_provider=local ?
If so, what is your use-case?
We're considering deprecating and eventually removing this provider
upstream. The replacemant for id_provider=local would be id_provider=files:
https://fedorahosted.org/sssd/wiki/DesignDocs/FilesProvider
which is already under review and later extension of the SSSD's D-Bus
interface to allow manipulating custom user attributes.
My current plan for deprecating the local provider is to only build the
provider and the tools around it if a configure-time flag is provided.
This flag would be disabled by default. Then, if noone complains,
eventually just remove the code.
7 years, 2 months
[sssd PR#144][opened] SSSD does not start if using only the local provider and services line is empty
by fidencio
URL: https://github.com/SSSD/sssd/pull/144
Author: fidencio
Title: #144: SSSD does not start if using only the local provider and services line is empty
Action: opened
PR body:
"""
SSSD has to notify systemd whenever its startup is finished. Currently it has been done only when a service (and here I mean either provider or responder) has been started up.
However, when dealing with socket-activation we have the case where no responders have been set up and, consequently, the sd_notify() code won't ever be triggered by the responders.
Combining the above described scenario with the user setting up only the LOCAL provider, which also won't trigger the sd_notify() code, SSSD can end up hitting a systemd timeout during initialization.
This patch set solve the described issue.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/144/head:pr144
git checkout pr144
7 years, 2 months
SSSD not reregister DDNS when interface goes up down
by Joakim Tjernlund
Starting up with eth0 plugged I gest DNS registered. But if I pull eth0
and enable WiFi I get a new IP but the old IP is still in DNS.
Restarting sssd register the new WiFi IP.
Bug or feature ?
Jocke
7 years, 2 months
Watchdog, time shifts and scheduled events
by Victor Tapia
Hi list,
I've been testing a scenario with a time shift of an hour to the past,
and even though the watchdog detects the shift and restarts, the
scheduled events are still stuck until the time passes.
Would it make sense to use the same resetOffline/SIGUSR2 mechanism used
for networking status changes to reschedule those events after the
watchdog reset[1]?
Kind regards,
Victor
[1]
diff --git i/src/util/util_watchdog.c w/src/util/util_watchdog.c
index 0df85b7..f981516 100644
--- i/src/util/util_watchdog.c
+++ w/src/util/util_watchdog.c
@@ -158,6 +158,9 @@ static void watchdog_fd_read_handler(struct
tevent_context *ev,
"[%d]: %s\n", ret, sss_strerror(ret));
orderly_shutdown(1);
}
+ if (getpid() == getpgrp()) {
+ kill(-getpgrp(), SIGUSR2);
+ }
}
int setup_watchdog(struct tevent_context *ev, int interval)
7 years, 2 months
[sssd PR#151][opened] BUILD: Fix linking of test_sdap_initgr
by lslebodn
URL: https://github.com/SSSD/sssd/pull/151
Author: lslebodn
Title: #151: BUILD: Fix linking of test_sdap_initgr
Action: opened
PR body:
"""
There was a linking fialure on debian:
/usr/bin/ld: src/tests/cmocka/test_sdap_initgr-test_sdap_initgr.o:
undefined reference to symbol 'hash_iterate@(a)DHASH_0.4.3'
//usr/lib64/libdhash.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
This patch adds some missing libraries and remove unnecessary libraries.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/151/head:pr151
git checkout pr151
7 years, 2 months
Avoid running two instances of the same service (#3300)
by 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
7 years, 2 months
