One of the plans for better desktop integration is to slowly take over local accounts by creating a new provider that uses system files (passwd, shadow, group, etc...) and augments them with additional information maintained in sssd's long term cache.
Part of this plan calls for changing how nsswitch is configured so that the sss nsswitch module comes first. This is useful for a variety of reasons, including that we can cache in the fast cache user's from passwd/group too and do not pay the penalty of going through the slower nss_files provider for each request.
However this comes with a gotcha when sssd is stopped, as the cache will not be updated. This is particularly important at bootup time when sssd is not started yet but some daemons already exist and start consulting user entries. In order to avoid issues I think we should make it possible for nss_sss to understand whether it can actually trust caches or not.
One idea is to mark "system" users/groups in the cache, and have nss_sss ignore them if they are in the cache but it is not possible to connect to sssd. This should be pretty lightweight as it just tries to connect to the sssd socket but does not need to make any communication on it except for the first request and getting a "echo" or "version" packet (just to check sssd_nss is actually alive).
If connection to sssd_nss fails then nss_sss will not return the system user and the query will naturally fall back to use nss_files instead.
We may want to use some very strict timeout on the socket for this specific case, to avoid stalling the boot process, it's not a bid deal, the process falls back to using nss_files so we are always correct in any case.
Simo.
On Fri, Jul 11, 2014 at 06:20:13AM -0400, Simo Sorce wrote:
One of the plans for better desktop integration is to slowly take over local accounts by creating a new provider that uses system files (passwd, shadow, group, etc...) and augments them with additional information maintained in sssd's long term cache.
Part of this plan calls for changing how nsswitch is configured so that the sss nsswitch module comes first. This is useful for a variety of reasons, including that we can cache in the fast cache user's from passwd/group too and do not pay the penalty of going through the slower nss_files provider for each request.
However this comes with a gotcha when sssd is stopped, as the cache will not be updated. This is particularly important at bootup time when sssd is not started yet but some daemons already exist and start consulting user entries. In order to avoid issues I think we should make it possible for nss_sss to understand whether it can actually trust caches or not.
One idea is to mark "system" users/groups in the cache,
How do you distinguish the system users? Based on ID limits or some other property (such as, no shadow entry)? Reading the fedora-devel thread again, I think the systemd proposal includes going away from the MIN_ID/MAX_ID limits in /etc/login.defs, so I guess we'll have to implement a compile-time option
and have nss_sss ignore them if they are in the cache but it is not possible to connect to sssd. This should be pretty lightweight as it just tries to connect to the sssd socket but does not need to make any communication on it except for the first request and getting a "echo" or "version" packet (just to check sssd_nss is actually alive).
If connection to sssd_nss fails then nss_sss will not return the system user and the query will naturally fall back to use nss_files instead.
We may want to use some very strict timeout on the socket for this specific case, to avoid stalling the boot process, it's not a bid deal, the process falls back to using nss_files so we are always correct in any case.
Simo.
-- Simo Sorce * Red Hat, Inc * New York
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Fri, 2014-07-11 at 17:20 +0200, Jakub Hrozek wrote:
On Fri, Jul 11, 2014 at 06:20:13AM -0400, Simo Sorce wrote:
One of the plans for better desktop integration is to slowly take over local accounts by creating a new provider that uses system files (passwd, shadow, group, etc...) and augments them with additional information maintained in sssd's long term cache.
Part of this plan calls for changing how nsswitch is configured so that the sss nsswitch module comes first. This is useful for a variety of reasons, including that we can cache in the fast cache user's from passwd/group too and do not pay the penalty of going through the slower nss_files provider for each request.
However this comes with a gotcha when sssd is stopped, as the cache will not be updated. This is particularly important at bootup time when sssd is not started yet but some daemons already exist and start consulting user entries. In order to avoid issues I think we should make it possible for nss_sss to understand whether it can actually trust caches or not.
One idea is to mark "system" users/groups in the cache,
How do you distinguish the system users? Based on ID limits or some other property (such as, no shadow entry)? Reading the fedora-devel thread again, I think the systemd proposal includes going away from the MIN_ID/MAX_ID limits in /etc/login.defs, so I guess we'll have to implement a compile-time option
Systemd would be wrong.
My plan is indeed to use login.defs if available and fallback to a hardcoded compile-time default if not.
Simo.
sssd-devel@lists.fedorahosted.org
-
Jakub Hrozek -
Simo Sorce