[SSSD] [PATCHES] sss_userdel and sss_groupdel should invalidate mmap cache

Simo Sorce simo at redhat.com
Wed Nov 21 15:41:42 UTC 2012


On Wed, 2012-11-21 at 15:56 +0100, Michal Židek wrote:
> On 11/21/2012 02:31 PM, Simo Sorce wrote:
> > On Tue, 2012-11-20 at 14:29 +0100, Michal Židek wrote:
> >> On 11/20/2012 02:22 PM, Michal Židek wrote:
> >>> Patch 1: sss_cache refactor. See patch description for more details.
> >>> Patch 2: Remove mmap cache properly in sss_userdel and sss_groupdel
> >
> > It looks a bit excessive to remove the whole cache when you change 1
> > user, would be probably better to fix this by a slightly more complex
> > construct.
> >
> > After you delete the data from the ldb cache you could query sssd_nss
> > for the user name. And make sure that sssd_nss also searches the mc
> > cache and remove the entry if it is found there on user lookup failure
> > (we can later on use this feature to implement negative caching at the
> > mc layer).
> >
> > Simo.
> >
> 
> Hmm... we would still need to handle the situation when sssd_nss is not 
> running. I guess removing the entire mmap cache here is just fine.

What's the point of adding or deleting users if sssd is not running ?
If you want to simply wipe the cache we have a specific tool for that.

> But, to the case when sssd_nss is running. Does sss_nss_make_request() 
> only ldb requests? Or first mc then ldb?

Only ldb, you need to add a mc request as an additional check, if the
ldb search tunrs out empty.
BAsically in the place where we do the negative caching now you'd add a
call to a helper function to check and invalidate the mc cache for the
specific user as well.

> I am looking at the client code 
> now and it looks like this function is called when mc lookup did not 
> succeeded... so my guess is, that it only requests for ldb data. If so, 
> then this would be the function to use here.
> 
> It would be like:
> ... in the tool's code ...
> sss_nss_make_request(SSS_NSS_GETPWNAM, ...);
> 
> ... somewhere inside sssd_nss code ...
> if (no_results_in_ldb) {
>      invalidate rec in mc
> }

Exactly.

> Since the invalidation takes place inside sssd_nss process, no new 
> synchronization between processes should be needed (the barriers are 
> already there). But this would only work if sss_nss_make_request 
> communicates with ldb only (which I think it does).
> 
> Was this your suggestion?

Yes, precisely.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list