sssd-devel December 2016

sssd-devel@lists.fedorahosted.org

15 participants
53 discussions

[sssd PR#27][opened] Minor code changes
by fidencio 02 Dec '16

02 Dec '16

URL: https://github.com/SSSD/sssd/pull/27 Author: mzidek-rh Title: #27: Minor code changes Action: opened PR body: """ Some small changes in the code. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/27/head:pr27 git checkout pr27

1 8

Design document - Socket-activatable responders
by Fabiano Fidêncio 02 Dec '16

02 Dec '16

The design page is done [0] and it's based on this discussion [1] we had on this very same mailing list. A pull-request with the implementation is already opened [2]. [0]: https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders [1]: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.… [2]: https://github.com/SSSD/sssd/pull/84 The full text of c&p here: = Socket Activatable Responders = Related ticket(s): * https://fedorahosted.org/sssd/ticket/2243 * https://fedorahosted.org/sssd/ticket/3129 === Problem statement === SSSD has some responders which don't have to be running all the time, but could be socket-activated instead in platforms where it's supported. That's the case, for instance, for the IFP, ssh and sudo responders. Making these responders socket-activated would provide a better use experience, as these services could be started on-demand when a client needs them and exist after a period of inactivity. Currently the admin has to explicitly list all the services that might potentially be needed in the `services` section and the processes have to be running all the time. === Use cases === ==== sssctl ==== As more and more features that had been added depending on the IFP responder, we should make sure that the responder is activated on demand and the admins doesn't have to activate it manually. ==== KCM ==== The KCM responder is only seldom needed, when libkrb5 needs to access the credentials store. At the same time, the KCM responder must be running if the Kerberos credentials cache defaults to `KCM`. Socket-activating the responder would solve both of these cases. ==== autofs ==== The autofs responder is typically only needed when a share is about to be mounted. === Overview of the solution === The solution agreed on the mailing list is to add a new unit for each one of the responders. Once a responder is started, it will communicate to the monitor in order to let the monitor know that it's up and the monitor will do the registration of the responder, which basically consists in marking the service as started, increasing the services' counter, getting the responder's configuratiom, adding the responder to the service's list. A configurable idle timeout will be implemented in each responder, as part of this task, in order to exit the responder in case it's not used for a few minutes. === Implementation details === In order to achieve our goal we will need a small modification in responders' common code in order to make it ready for socket-activation, add some systemd units for each of the responders and finally small changes in the monitor code in order to manage the new activated service. The change in the responders' common code is quite trivial, just chnage the sss_process_init code to call activate_unix_sockets() istead of set_unix_socket(). Something like: {{{ - ret = set_unix_socket(rctx, conn_setup); + ret = activate_unix_sockets(rctx, conn_setup); }}} The units that have to be added for each responder must look like: sssd-@responder@.service.in: {{{ [Unit] Description=SSSD @responder@ Service responder Documentation=man:sssd.conf(5) Requires=sssd.service PartOf=sssd.service After=sssd.service [Install] Also=sssd-@responder@.socket [Service] ExecStart=@libexecdir@/sssd/sssd_@responder@ --uid 0 --gid 0 --debug-to-files }}} sssd-@responder@.socket.in: {{{ [Unit] Description=SSSD @responder@ Service responder socket Documentation=man:sssd.conf(5) [Socket] ListenStream=@pipepath@/@responder@ [Install] WantedBy=sockets.target }}} Some responders may have more than one socket, which is the case of PAM, so another unit will be needed. sssd-@responder@-priv.socket.in: {{{ [Unit] Description=SSSD @responder@ Service responder private socket Documentation=man:sssd.conf(5) [Socket] ListenStream=@pipepath@/private/@responder@ [Install] WantedBy=sockets.target }}} Last but not least, the IFP responder doesn't have a socket. It's going to be D-Bus activated and some small changes will be required on its D-Bus service unit. {{{ -Exec=@libexecdir@/sssd/sss_signal +Exec=@libexecdir@/sssd/sssd_@responder@ }}} And, finally, the code in the monitor side will have to have some adjustments in order to properly deal with an empty list of services and, also, to register the service when it's started. As just the responders' will be socket-activated for now, the service type will have to exposed and passed through sbus when calling the RegistrationService method and the monitor will have to properly do the registration of the service when RegistrationService's callback is triggered. As mentioned before, the "registration" that has to be done from the monitor's side is: * 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. === Configuration changes === After this design is implemented, the "services" line in sssd.conf will become optional for platforms where systemd is present. Note that in order to keep backward compatibility, if the "services" line is present, the services will behave exactly as they did before these changes. === How To Test === The easiest way to test is removing the "services" line from sssd.conf and try to use SSSD normally. Using sssctl tool without having the ifp responder set in the "services" line is another way to test. === How To Debug === The easiest way to debug this new feature is taking a look on the responders' common initialization code and in the monitors' client registration code. Is worth to mention that disabling the systemd's services/sockets will prevent the responders' services to be started. === Authors === Fabiano Fidêncio <fidencio(a)redhat.com> Best Regards, -- Fabiano Fidêncio

8 31

[sssd PR#101][opened] SIFP: Fix warning format-security
by fidencio 01 Dec '16

01 Dec '16

URL: https://github.com/SSSD/sssd/pull/101 Author: lslebodn Title: #101: SIFP: Fix warning format-security Action: opened PR body: """ dbus-1.11.8 added attributes for format string check to few functions in public header files. And therefore there is a warning. src/lib/sifp/sss_sifp_utils.c: In function ‘sss_sifp_set_io_error’: src/lib/sifp/sss_sifp_utils.c:44:5: error: format not a string literal and no format arguments [-Werror=format-security] dbus_set_error(ctx->io_error, error->name, error->message); ^~~~~~~~~~~~~~ """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/101/head:pr101 git checkout pr101

1 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel December 2016