-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/06/2010 07:37 AM, Patrik Martinsson wrote:
Hmm, ok. Couple of questions though,
> You do not understand right, actually. We only do a full enumeration the
> first time, and then every twenty-four hours after that.
Ok first time ever, or every time sssd starts ?
The first time SSSD starts.
Reason I'm asking is because I experiencing that when i boot my
computer and sssd starts i cannot login, until sssd is finished. (Or does this have to do
with the RFC2307 you mentioned)
That's probably due to the initial enumeration, yes. Although the
initgroups bug isn't likely to be helping either.
> What you're seeing every five minutes (as described by Jakub
in the
> other reply) is that the LDAP provider will send a request asking for
> the DELTA since the last enumeration run. So if anything has changed,
> we'll retrieve it and update what's in cache. This is not a full
> enumeration.
Is this ok doing without performance impact on the computer ? (With AD at around 1500
users)
And, related to my first question, while sssd is doing this, is it possible that I will
experience long wait for logins ?
It should have minimal wait time, since the query to LDAP includes the
lastModifiedTime > <last_time>, so we'll only get back entries that have
changed
I'm sorry if my questions are a bit to much, but I'm just
trying to figure this stuff out.
Maybe we don't even need sssd, maybe we should have nslcd and nss/ldap like before ?
But i figured sssd would be the new framework for handling authentication and identities,
so i better got it working....
No, please do set it up and test it. Any bugs you find will help us make
a better product.
On 08/06/2010 01:10 PM, Stephen Gallagher wrote:
On 08/06/2010 06:00 AM, Patrik Martinsson wrote:
>>> Ah ok, cool i hear you.
>>>
>>> I reccon we need to have the enumeration option, it's really handy to
>>> lookup users that way, we have done it for so along time (And god forbid
>>> to change things, right ;)).
>>> I found the option enum_cache_timeout, which defaults to 120 seconds,
>>> which means if i understand it right that it will refresh the enum_cache
>>> (thus enumrate the ad) every
>>> 120 seconds, which seems to be overkill in my opinion.
>>>
You do not understand right, actually. We only do a full enumeration the
first time, and then every twenty-four hours after that.
What you're seeing every five minutes (as described by Jakub in the
other reply) is that the LDAP provider will send a request asking for
the DELTA since the last enumeration run. So if anything has changed,
we'll retrieve it and update what's in cache. This is not a full
enumeration.
>>> Hmm, this is a bit tricky to have it the way i want i guess,
>>> #1, I want sssd to cache user info to be able to login offline.
>>> #2, Although when I do a getent passwd I would like a fresh list from
>>> the AD, (like nss/ldap did it)
>>> #3, However when a user login I do not want to wait for sssd to
>>> enumarate the AD (taking alot of time)
>>>
>>>
We don't enumerate on login, however we have a known bug in our
RFC2307bis processing right now that can cause initgroups to take a long
time for users who are members of groups containing large numbers of
members. I am working on this.
>>> I'm thinking of following setup/scenario.
>>> #1, I set enum_cache option to 999999 or whatever so sssd only
>>> enumerates at start, because it does that right ? Then i would have a
>>> fresh sssd cache at start.
>>>
Do not do this. This is not the same as the cache refresh time (see
Jakub's reply)
>>> #2, Then some user gets added to the AD.
>>> #3, I try to find that user, getent passwd | grep email (couse i just
>>> know his name, not the username) and i wont find that user, since
>>> sssd-cache thats being returned doesnt contain that user.
>>>
See my explanation above about the enumerations being a delta, not a
full enumeration
>>> I guess i need to figure out some other way of working maybe.
>>>
>>> /Patrik
>>>
>>>
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
- --
Stephen Gallagher
RHCE 804006346421761
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora -
http://enigmail.mozdev.org/
iEYEARECAAYFAkxb9r8ACgkQeiVVYja6o6MNfwCcCOIEne9bIhkKmwQHRZspNHVP
rtYAoJoX4itaS1I604bfqBGpxbVZtJ5u
=xzYa
-----END PGP SIGNATURE-----