Watchdog in the monitor process
by Jakub Hrozek
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 :-)
7 years, 1 month
[sssd PR#49][opened] Try to match multiple results from an AD initgroups request against domain's search bases, too
by fidencio
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
7 years, 1 month
Should we use VMs or containers for (some) tests?
by Jakub Hrozek
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.
7 years, 1 month