On Wed, Dec 5, 2012 at 3:11 PM, Jakub Hrozek <jhro...@redhat.com> wrote:
> On Wed, Dec 05, 2012 at 02:20:40PM +0100, Natxo Asenjo wrote:
>> why would I want sssd to cache group/hostgroup/netgroup membership?
>> Is the performance hit so huge on the ldap servers?
>> I ask this because Windows admins are used to apply membership of
>> groups to objects and the changes in a single site domain (or even in
>> a multisite domain with fast wan links) are replicated very fast, it
>> is nearly instantanous. So for those admins, having to wait x minutes
>> for the sssd cache to expire is, to put it mildly, strange.
>> What are the consequences of disabling the cache with an entry like this:
>> entry_cache_timeout = 0
>> in sssd.conf?
>> Thanks in advance for your input.
> Feel free to tune down the cache timeout, it should just work. Speed
> benefits depend on your configuration, I guess. With large group
> memberships, the speed benefit of caching is quite visible.
> However, is it really that necessary to see the group memberships
> updated with "id" for instance? One reason is that during login, the SSS
> never just consults the cache, but always performs e.g. fetches the
> group list for the initgroups operation for the server to make sure that
> access control mechanisms have the latest group memberships available.
is this the case too for hostgroups? I am bootstrapping an
infrastructure with ipa and cfengine and I am seeing that it caches
the hostgroups/netgroups information, so when I join a host to the ipa
realm, I need to empty the netgroup cache or it will take 90 minutes
to apply configs from cfengine based on netgroup info.
> So while lookups that only go through the Name Service Switch, such as
> getent or id might display outdated information for some limited period
> of time, authentication should never allow or deny access based on
> obsolete cached data.
well, this is apparently the case for me. I use the netgroup database
from nss, so it is caching.
Freeipa-users mailing list