On Mon, 3 Nov 2014 15:41:43 +0100
Jakub Hrozek <jhrozek(a)redhat.com> wrote:
On Mon, Nov 03, 2014 at 08:53:06AM -0500, Simo Sorce wrote:
> 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 ?
Many getgrouplist() or initgroups() calls in a quick succession. One
user is GlusterFS -- I'm not quite sure what the reason is there,
maybe Vijay can elaborate.
The other use-case is slapi-nis that calls getgrouplist() -- Alexander
would explain better here, I only know that slapi-nis uses
getgrouplist() during memberUID processing, but I'm fuzzy on the
details.
>
> > 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 ?
Mostly the cache. In particular, with the GlusterFS case, there was a
huge filesystem directory that triggered 4000+ getgrouplist() calls,
one per a file. Even though the getgrouplist() calls were for fewer
than 10 users, we would hit LDB every time and that produced quite a
load on the SSSD.
>
> > 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.
Hm, I see, then we have the same information duplicated in two caches,
just from a different angle. However, for cases where precision really
matters (access control), we don't use these caches anyway.
Could we mitigate this problem by invalidating the memcache when group
membership changes at all during a backend operation? I think changes
to LDAP object are so rare, that invalidating the memcache (which is
quite shortlived anyway) would be worth it.
Probably sufficient, what is the expected lifetime of the initgroups
memcache ?
> Do we need to insure all groups are resolvable in the groups
cache ?
I don't think so, if the group is not in the groups cache, then we
just hit the responder.
ok
> Or is it ok if gids returned by the getgrouplist are not
immediately
> available in the groups cache ?
> What about the user ?
I *think* the user could also be left out. If the application also
needs user data, it simply calls getpwnam -- like id(1) does.
getgrouplist is a different interface with different outputs.
fine then.
Note that one option could be to extend the user's cache, to have a
list of gids on the tail of the user's data, I am too stuffed of
medications though to think clearly if that is a good idea or a
colossal idiocy :-)
Simo.
--
Simo Sorce * Red Hat, Inc * New York