On Mon, 3 Nov 2014 13:57:08 +0100
Jakub Hrozek <jhrozek(a)redhat.com> wrote:
Hi,
we had short discussion on $SUBJECT with Simo on IRC already, but
there are multiple people involved from multiple timezones, so I
think a mailing list thread would be better trackable.
Can we add another memory cache file to SSSD, that would track
initgroups/getgrouplist results for the NSS responder? I realize
initgroups is a bit different operation than getpw{uid,nam} and
getgr{gid,nam} but what if the new memcache was only used by the NSS
responder and at the same time invalidated when initgroups is
initiated by the PAM responder to ensure the memcache is up-to-date?
Can you describe the use case before jumping into a proposed solution ?
I already know about two projects that would benefit from faster
initgroups operation - GlusterFS uses getgrouplist() quite a lot with
some setups and also in the IPA server mode, the SSSD running on the
server becomes a bit of a bottlenec for some operations.
Is the problem related to accessing the main ldb cache, or the fact we
also go out and contact the IdM server ?
Are there any technical reasons against a new memcache file that
would
cache initgroups?
The main reason would be potential inconsistency between this cache and
the users and groups caches, but I do not think that would be really a
big deal if there is a pretty good reason for the cache.
Do we need to insure all groups are resolvable in the groups cache ?
Or is it ok if gids returned by the getgrouplist are not immediately
available in the groups cache ?
What about the user ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York