sssd-devel February 2017

sssd-devel@lists.fedorahosted.org

10 participants
61 discussions

Does anyone use id_provider=local ?
by Jakub Hrozek 11 Feb '17

11 Feb '17

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.

2 1

[sssd PR#145][opened] Fix storing a sudoRule attriubute in a case-insensitive domain when the attriubute values differ only by case
by jhrozek 10 Feb '17

10 Feb '17

URL: https://github.com/SSSD/sssd/pull/145 Author: jhrozek Title: #145: Fix storing a sudoRule attriubute in a case-insensitive domain when the attriubute values differ only by case Action: opened PR body: """ I guess because different versions of sssd placed different constraints on the case-sensitiveness of sudo rules, some users run a setup where a sudoRule's sudoUser attribute only differs by case. This kind of a setup breaks with the current sssd code. The attached patch uses the previously introduced function sysdb_attrs_add_lower_case_string() to work around the issue and only store the resulting attribute once. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/145/head:pr145 git checkout pr145

3 11

[sssd PR#144][opened] SSSD does not start if using only the local provider and services line is empty
by fidencio 10 Feb '17

10 Feb '17

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

5 33

SSSD not reregister DDNS when interface goes up down
by Joakim Tjernlund 10 Feb '17

10 Feb '17

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

1 0

Watchdog, time shifts and scheduled events
by Victor Tapia 10 Feb '17

10 Feb '17

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)

2 4

[sssd PR#150][opened] ssh: go to dp first when looking up host
by pbrezina 08 Feb '17

08 Feb '17

URL: https://github.com/SSSD/sssd/pull/150 Author: pbrezina Title: #150: ssh: go to dp first when looking up host Action: opened PR body: """ There were three downstream test failures caused by not updating known_host files properly. Original code went to data provider prior to cache lookup but the changes I made went to cache first following our standard pattern. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/150/head:pr150 git checkout pr150

2 5

[sssd PR#151][opened] BUILD: Fix linking of test_sdap_initgr
by lslebodn 08 Feb '17

08 Feb '17

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

3 7

[sssd PR#149][opened] Fix subdomain discovery if sssd.conf domain name is different from joined domain name
by jhrozek 08 Feb '17

08 Feb '17

URL: https://github.com/SSSD/sssd/pull/149 Author: jhrozek Title: #149: Fix subdomain discovery if sssd.conf domain name is different from joined domain name Action: opened PR body: """ Please see the commit message for problem description and a way to reproduce the issue. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/149/head:pr149 git checkout pr149

2 8

Avoid running two instances of the same service (#3300)
by Fabiano Fidêncio 08 Feb '17

08 Feb '17

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

3 14

[sssd PR#85][opened] SYSDB: Removing of sysdb_try_to_find_expected_dn()
by fidencio 08 Feb '17

08 Feb '17

URL: https://github.com/SSSD/sssd/pull/85 Author: celestian Title: #85: SYSDB: Removing of sysdb_try_to_find_expected_dn() Action: opened PR body: """ Currently in order to match multiple LDAP search results we use two different functions - we have sysdb_try_to_find_expected_dn() but also sdap_object_in_domain(). This patch removes sysdb_try_to_find_expected_dn() and add new sdap_search_initgr_user_in_batch() based on sdap_object_in_domain(). This function covers necessary logic. Resolves: https://fedorahosted.org/sssd/ticket/3230 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/85/head:pr85 git checkout pr85

3 24

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel February 2017