On Mon, May 15, 2017 at 05:57:50PM +0200, Tomasz Kłoczko wrote: > On 15 May 2017 at 17:35, Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > > Tomasz, your tone is needlessly hostile. If you have a question, ask it. If you want to make a suggestion, make it. But casting aspersions on people doing work is unacceptable. > > Just please read my question straight. What I've wrote it is very > simple technical question as glibc NSS code *ALWAYS* is trying to > communicate with nscd ov. socket before calling any routine from any > nss_<map> modules even if nscd is not running. > In this context implementing in sssd any caching infrastructure is > more like idiotic than well justified (technically) move. > Did anyone tested what happens in the system authenticated ov (for > example) LDAP where ncsd and sssd are running on the same system? This has been strongly discouraged for years as Stephen said and sssd would warn you loudly to syslog if it was running together with nscd and nscd was caching the maps that sssd handles as well (so, caching hosts would be fine for example) > As I > was in the past few years shadow-utils source code maintainer I know > that after each modifications files used by NSS (like passwd, shadow, > group, passwd, group, sgroup, networks and few other in /etc) is > necessary to communicate with nscd to do do cache clean. > I would be not surprised if in case enabled caching by sssd and modify > for example /etc/passwd nothing from shadow-utils will be trying to > communicate with sssd to clear its passwd map cache. Right, in this case we try to detect the inconsistency in SSSD and fall back to nss_files (which is still in nsswitch, just not on the first place anymore) by just flushing the caches when SSSD detects the files have changed. But you are right that in order to be on the safe side, we also need to invalidate the sssd caches from shadow-utils. And we have a sssd ticket to track this (admittedly we should have a bugzilla as well, I took a note to file one) _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
