sssd-devel November 2016

sssd-devel@lists.fedorahosted.org

22 participants
75 discussions

Watchdog in the monitor process
by Jakub Hrozek 07 Nov '16

07 Nov '16

Hi, Currently the watchdog is enabled for all sssd processes, including the main sssd process. I admit I only realised that now that I was looking into one user report where upgrading the sssd database during package update took so long that the watchdog eventually killed the sssd process..oops.. So we can either relax the watchdog during operations that we know might take a very long time (like upgrading huge cache files) or remove it altogether. I’m leaning towards the second option and just don’t setup the watchdog at all. Does anyone see a reason to keep the watchdog for the monitor? I think the watchdog in the current form makes sense only for “worker” processes where the monitor listens for SIGCHLD signals and restarts the services. I think for the monitor process it would make more sense to leverage some systemd functionality rather than kill itself :-)

3 2

[sssd PR#60][opened] Document ad_access_filter search for nested groups
by fidencio 03 Nov '16

03 Nov '16

URL: https://github.com/SSSD/sssd/pull/60 Author: taupehat Title: #60: Document ad_access_filter search for nested groups Action: opened PR body: """ Short doc fix and example to demonstrate how to ensure ad_access_filter includes nested group membership. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/60/head:pr60 git checkout pr60

1 23

[sssd PR#49][opened] Try to match multiple results from an AD initgroups request against domain's search bases, too
by fidencio 03 Nov '16

03 Nov '16

URL: https://github.com/SSSD/sssd/pull/49 Author: jhrozek Title: #49: Try to match multiple results from an AD initgroups request against domain's search bases, too Action: opened PR body: """ This is a proposed way of solving https://fedorahosted.org/sssd/ticket/3199. It is not complete, because there is no integration test, the commit message sucks and in general I'm not sure about the approach. But the problem is that if a search for a user returns multiple results (which is the case with nested child domains and GC in use), then we only try to match against a candidate base DN derived from the domains's name. This works in case the domain name is the same as the AD forest name, but not otherwise. Thefore, the patch tries to also take a look at the domain's search base and match against that as a fallback. My questions are: - is this a good idea at all? - should we loop across all search bases? - shouldn't we revert the order and first try to match the search base and only then the domain name? """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/49/head:pr49 git checkout pr49

1 25

[sssd PR#62][opened] PAM: add pam_response_filter option
by fidencio 02 Nov '16

02 Nov '16

URL: https://github.com/SSSD/sssd/pull/62 Author: sumit-bose Title: #62: PAM: add pam_response_filter option Action: opened PR body: """ Currently the main use-case for this new option is to not set the KRB5CCNAME environment varible for services like 'sudo-i'. Resolves https://fedorahosted.org/sssd/ticket/2296 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/62/head:pr62 git checkout pr62

1 20

Should we use VMs or containers for (some) tests?
by Jakub Hrozek 01 Nov '16

01 Nov '16

Hi, I'm currently working on integration tests for the 'files' provider and during this work I started to feel we are pushing the boundaries around our test infrastructure already quite a bit. When SSSD talks over network to a server, then we're more or less okay, but for some parts of SSSD, like the files provider, we have to mock a lot of pieces and the end result is that we are testing something that resembles the target system, but probably has its own bugs. Additionally, we can't run some tests at all (anything against IPA) and I suspect we'll be running into this sort of a problem even more in the future. So I'm interested in hearing what are other's thoughts on exploring how to run some of our tests in a privileged environment, either in a VM or in a container? Our current tests have the big advantage of being able to provision a test locally in a screen session, but maybe something similar would be possible by e.g. running a screen in a container and attaching to its tty.. And for "simple" tests like LDAP provider we could keep the current infrastructure around.

4 11

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel November 2016