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. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
