sssd.git/src/monitor, branch certificate_mapping

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

SBUS: Add destructor data to sbus_connection

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

This additions has a very specific reason: unregister a service when
it's shutdown.

So far, we never had to do this kind of operation because the services
were started during SSSD's startup when finished when SSSD finished.

Now, with the socket-activation in place the game will be a little bit
different as the services will have an idle timeout and will be able
shut themselves down. In order to do it properly the monitor will need
to "unregister" the service and there's no way to do that without adding
this destructor data to the sbus_connection structure and introducing a
new function to access it from the monitor (where we're going to
set the destructor function to the sbus_connection for the
socket-activated services).

So far it's not being used anywhere as every function taking it as
parameter is just receiving NULL, but it will be used in the follow up
commits, by the monitor.

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

SBUS: Add a time_t pointer to the sbus_connection

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

The idea of this commit is to provide a way to update the time of the
last request coming from/going to the responders through sbus.

For now it's not used anywhere as all the functions that will pass their
time_t to the sbus_connection are currently passing NULL. It will be
used by follow-up patches.

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

MONITOR: Don't expose monitor_common_send_id()

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

As this function is only called by sss_monitor_init(), which is part of
monitor_sbus.c file (same file where monitor_common_send_id() is
declared), there is no reason to expose the function.

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

MONITOR: Deal with socket-activated responders

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

As part of the effort of making all responders socket-activatable, let's
make the monitor able to deal with this situation.

When a responder is socket-activated the monitor has to:
- Mark the service as started;
- Increase the services' counter;
- Get the responders' configuration;
- Set the service's restart number;
- Add the service to the services' list.

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

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

MONITOR: Deal with no services set up

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

When SSSD deals with socket-activation properly, the services' line in
the SSSD's config file may not be present anymore in case the admin
doesn't want any service to be explicitelly activavte during SSSD's
startup. Taking this into consideration, let's make SSSD ready to deal
with an empty list of services in platforms were systemd is present.

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

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