sssd.git/src/monitor, branch master

CONFDB: Allow configuring [application] sections as non-POSIX domains

2017-03-30T12:09:10+00:00

Related to:
https://pagure.io/SSSD/sssd/issue/3310

Allows to add a new section:
    [application/$name]

This section internally (on the confdb level) expands to:
    [domain/$name]
    domain_type = application

The reasons to add this new section is two-fold. One, to make the
configuration of application domains more explicit and two, to make it
possible to share configuration between two domains, one POSIX and one
non-POSIX by application domain's inherit_from option:
    [application/$name]
    inherit_from = posix_domain_name

Reviewed-by: Sumit Bose 
Reviewed-by: Pavel Březina

MONITOR: Enable an implicit files domain if one is not configured

2017-02-27T18:14:15+00:00

If SSSD is compiled with --enable-files-domain, the loading of the
domains changes such that:
    * if no domain with id_provider=files exists in the config file, an
      implicit SSSD files domain is added
    * this domain is always first in the list

The administrator is free to create a files domain in the config file
himself and either place it at the end of the list or not enable it at
all.

Resolves:
https://pagure.io/SSSD/sssd/issue/3112

Reviewed-by: Pavel Březina

MONITOR: Don't return an error in case we fail to register a service

2017-02-22T13:03:22+00:00

This behaviour was mistakenly changed by the {dbus,socket}-activation
series and, as it's now, I've noticed the monitor may end up in some
weird state due to this change, where it doesn't stop properly and leave
some defuncts children processes.

Let's change it back to what it was before and avoid possible
regressions (even if no regression where hit yet).

Signed-off-by: Fabiano Fidêncio 

Reviewed-by: Pavel Březina

MONITOR: Use the common inotify code to watch resolv.conf

2017-02-15T13:53:58+00:00

The monitor code used its own inotify callbacks to watch for changes to
resolv.conf. Instead of keeping this duplicated code around, let's use
the shared inotify module that also powers the files provider.

Reviewed-by: Pavel Březina

MONITOR: Remove checks for sssd.conf changes

2017-02-15T13:53:54+00:00

This feature was if-ed out for many years and since it's quite unlikely
we will re-enable the feature in the foreseeable future, let's just
remove this code.

Reviewed-by: Pavel Březina

MONITOR: Don't timeout if using local provider + socket-activated responders

2017-02-10T15:47:47+00:00

When using only the local provider with socket-activated services SSSD
ends up never notifying systemd its startup has been done, as notifying
systemd is done *only* when a service (provider or responder) is started
up, leading SSSD's startup to fail due to a timeout.

So, in order to avoid this situation, let's just notify the startup
earlier in case we have *only* socket-activated services and the *only*
provider set up is the LOCAL one.

Resolves:
https://fedorahosted.org/sssd/ticket/3299

Signed-off-by: Fabiano Fidêncio 

Reviewed-by: Pavel Březina

MONITOR: Wrap up sending sd_notify "ready" into a new function

2017-02-10T15:47:35+00:00

This new function will be used later on in this series as we also will
need to notify systemd that we're up in at least one more scenario (for
now).

Related:
https://fedorahosted.org/sssd/ticket/3299

Signed-off-by: Fabiano Fidêncio 

Reviewed-by: Pavel Březina

SERVER: Set the process group during server_setup()

2017-01-25T11:33:12+00:00

By calling setpgid() in server_setup() we are able to kill the process
in the watchdog by simply doing kill(-getpid(), SIGTERM).

However, in order to have it working properly the SELinux policy for
SSSD has to be updated and unless SSSD is ran with SELinux on permissive
mode, each of the responders and the monitor will trigger a similar
message:

    Jan 09 14:31:50 client1.ipa.example audit[11630]: AVC avc:  denied
    { setpgid } for  pid=11630 comm="sssd_pac"
    scontext=system_u:system_r:sssd_t:s0
    tcontext=system_u:system_r:sssd_t:s0 tclass=process permissive=0

It's important to say that till SELinux policy is fixed, we might end up
leaking some processes.

Related:
https://fedorahosted.org/sssd/ticket/3266

Signed-off-by: Fabiano Fidêncio 
Reviewed-by: Lukáš Slebodník

MONITOR: Fix warning with undefined macro HAVE_SYSTEMD

2017-01-24T08:54:36+00:00

Reviewed-by: Fabiano Fidêncio

RESPONDER: Shutdown {dbus,socket}-activated responders in case they're idle

2017-01-23T17:46:37+00:00

This commit introduces a new option for the responders called
responder_idle_timeout, which specifies the number of seconds that the
responder process can be up without being used. The default value is
300 seconds (5 minutes) and can be configured per responder, being 60
seconds the minimum acceptable value.

Is important to note that setting "responder_idle_timeout = 0" disables
the responder timeout, which makes sense for the responders that always
will be running.

The shutdown timeout is activated per responder in case the responder
has been {dbus,socket}-activated. In case of any commnunication with the
responder the timeout is reset thereby ensuring we won't shutdown a
responder that is not idle.

Setting the responder's last request time is done slightly differently
for socket-activated and dbus-activated responders. In both cases it's
updated in any internal communication in sbus_message_handler(), but
for the socket-activated responders it's also updated when the
responder's socket is used.

Currently it works properly with all responders but the secrets one,
which has a different logic and must be treated separately in case some
change is required there.

Is worth to mention that this commit does not affect the responders
explicitly configured in the "services" line of sssd.conf.

Related:
https://fedorahosted.org/sssd/ticket/3245

Signed-off-by: Fabiano Fidêncio 
Reviewed-by: Pavel Březina 
Reviewed-by: Jakub Hrozek 
Reviewed-by: Lukáš Slebodník