Hello again,
I was wondering about "recommending" settings about sssd. We have an AD with around 1500 users. Before sssd was introduced we used nss/ldap to query user-data from AD. However i figured it would be nice to get sssd working and started to configure that instead, got it working mostly as i want (posted some issuers earlier on the mailing-list).
Question though, With earlier setup it was possible to do, 'getent passwd' and get a list of all users, right. With the new setup, i only get the users in the passwd file when doing 'getent passwd', however if i do 'getent passwd username', i get the info i want. Then i tried with the setting, enumerate=true for current domain, and that seemed to fix the getent problem as it would return all the users, however that really of slow, having sssd running in debug-mode it produces thousands of lines with,
(Fri Aug 6 11:00:34 2010) [sssd[be[SMHI]]] [ldb] (9): tevent: Added timed event "ltdb_timeout": 0x4257310 (Fri Aug 6 11:00:34 2010) [sssd[be[SMHI]]] [ldb] (9): tevent: Destroying timer event 0x2ac70f0 "ltdb_timeout" (Fri Aug 6 11:00:34 2010) [sssd[be[SMHI]]] [ldb] (9): tevent: Ending timer event 0x425c200 "ltdb_callback"
Then it finishes kind of, then after a couple of minutes its doing the same thing again.
So basically, what I'm wondering is, cant i have getent passwd returning all my users without having enumerate = true in the config ?
Here's my config,
[sssd] config_file_version = 2 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam domains = foo
[nss] filter_groups = root filter_users = root reconnection_retries = 3
[pam] reconnection_retries = 3
[domain/foo] description = LDAP domain with AD server enumerate = true/false min_id = 0
id_provider = ldap auth_provider = krb5
krb5_kdcip = 123 krb5_realm = foo krb5_changepw_principle = kadmin/changepw krb5_ccachedir = /tmp krb5_ccname_template = FILE:%d/krb5cc_%U_XXXXXX krb5_auth_timeout = 15 krb5_keytab = /etc/krb5.keytab krb5_validate = true
ldap_sasl_mech = gssapi ldap_krb5_keytab = /etc/krb5.keytab
ldap_uri = ldap://foo ldap_schema = rfc2307bis ldap_search_base = DC=xx,DC=xxxx,DC=xx ldap_user_search_scope = sub ldap_user_search_base = ou=People,dc=xx,dc=xxxx,dc=xx ldap_group_search_base = ou=Groups,dc=xx,dc=smhi,dc=xx
ldap_user_object_class = person ldap_user_name = cn ldap_user_uid_number = uidNumber ldap_user_gid_number = gidNumber ldap_user_home_directory = msSFUHomeDirectory ldap_user_shell = loginShell ldap_user_principal = userPrincipalName ldap_user_gecos = mail
ldap_group_object_class = Group ldap_group_name = cn ldap_group_gid_number = msSFU30GidNumber ldap_force_upper_case_realm = True
ldap_tls_reqcert = demand ldap_tls_cacert = /etc/openldap/cacerts/CADOUBLE.cer ldap_tls_cacertdir = /etc/openldap/cacerts
Best regards, Patrik Martinsson, Sweden.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/06/2010 11:18 AM, Patrik Martinsson wrote:
So basically, what I'm wondering is, cant i have getent passwd returning all my users without having enumerate = true in the config ?
No, if you run "getent passwd" (without any specific user) you are doing an enumeration and for that to work, you need to have the "enumerate" parameter set to "true". As a side note, if you'd like to enumerate only users served via SSSD, you can run "getent passwd -s sss" (asking only for users from the nss_sss module).
Enumeration is not advised in large directories, but please note that only the first enumeration would be slow as SSSD needs to pull the users from the server. After that, if would return the entries from cache.
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.
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)
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. #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.
I guess i need to figure out some other way of working maybe.
/Patrik
On 08/06/2010 11:30 AM, Jakub Hrozek wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/06/2010 11:18 AM, Patrik Martinsson wrote:
So basically, what I'm wondering is, cant i have getent passwd returning all my users without having enumerate = true in the config ?
No, if you run "getent passwd" (without any specific user) you are doing an enumeration and for that to work, you need to have the "enumerate" parameter set to "true". As a side note, if you'd like to enumerate only users served via SSSD, you can run "getent passwd -s sss" (asking only for users from the nss_sss module).
Enumeration is not advised in large directories, but please note that only the first enumeration would be slow as SSSD needs to pull the users from the server. After that, if would return the entries from cache. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkxb1j8ACgkQHsardTLnvCXpQQCePCJSITrhp8oXVDIAxKU/O/nd jl8Ani1WSjSzborNyk30Yx2uN6uQGKBE =BfCS -----END PGP SIGNATURE----- _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/06/2010 12:00 PM, 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.
Actually, there seems to be a bug in our documentation. There are two parameters that affect enumeration:
enum_cache_timeout - how long will entries in cache be valid. That is, if you do two enumerations within the enum_cache_timeout interval, the second one will go from cache.
ldap_enumeration_refresh_timeout - This parameter is missing from the sssd-ldap manual page. I will send a patch that adds it. It affects how often the LDAP provider schedules enumerations. The default value is 300 (seconds, so 5 minutes).
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.
Keep in mind you also need to set cache_credentials to true for offline logins to work.
#2, Although when I do a getent passwd I would like a fresh list from the AD, (like nss/ldap did it)
If you need to fetch the enumeration data always from the directory, but prevent automatic enumeration updates from running in background until told, then I would set a very low enum_cache_timeout and reasonably high ldap_enumeration_refresh_timeout.
#3, However when a user login I do not want to wait for sssd to enumarate the AD (taking alot of time)
When a user logs in, there is no enumeration done. Perhaps initgroups (which might pull a reasonable amount of data), but no enumeration.
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. #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.
I guess i need to figure out some other way of working maybe.
/Patrik
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/06/2010 12:49 PM, Jakub Hrozek wrote:
ldap_enumeration_refresh_timeout - This parameter is missing from the sssd-ldap manual page.
This (and general revision of sssd-ldap manual page) is now https://fedorahosted.org/sssd/ticket/601
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
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 ? 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)
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 ?
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....
/Patrik
On 08/06/2010 01:10 PM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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
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/
iEYEARECAAYFAkxb7Y8ACgkQeiVVYja6o6OqvgCgk6PsOOi2c7O20rPp5SHqmGnk k1gAoIc6J4WJgNQUjtbZLGKvR1dxwHTz =MCfl -----END PGP SIGNATURE----- _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
-----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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
sssd-devel mailing list sssd-devel@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/
sssd-devel@lists.fedorahosted.org