On Thu, 22 Jul 2010 15:30:23 -0400 Scott Duckworth <sduc...@clemson.edu> wrote:
> On Thu, Jul 22, 2010 at 11:59 AM, Simo Sorce <sso...@redhat.com> > wrote: > > > On Thu, 22 Jul 2010 11:10:25 -0400 > > Scott Duckworth <sduc...@clemson.edu> wrote: > > > > > I removed all files from /var/lib/sss/db/ and restarted sssd. > > > Same behavior. nscd is disabled, so I don't think it's caching > > > at any level. > > > > > > Here is what I ran: > > > > > > [r...@duck2 ~]# getent passwd sduckwo > > > sduckwo:*:45265:10000:Scott Duckworth:/home/sduckwo:/bin/bash > > > [r...@duck2 ~]# groups sduckwo > > > sduckwo : cuuser > > > [r...@duck2 ~]# getent group coes_socunix > > > coes_socunix:*:120105:sduckwo > > > > > I should add to this, that what I expected to see is this (from one > of the RHEL boxes using nss_ldap): > > [r...@potter commands]# groups sduckwo > sduckwo : cuuser coes_dpa coes_socunix coes_web_cs coes_web_fx If you log in as sduckwo you should just see that. The same if you do "id sduckwo" > In other words, I don't so much care that all members of the group are > represented, but rather that all groups of which a user is a member > are represented. > > When enumeration is disabled this is the normal behavior. > > You will see only users/groups that have been fetched. Generally at > > login time because of the initgroups call. > > Ie a users will always have correct memmberships, but groups may not > > should all user members they truly have in the ldap server. > > > > If you require perfect representation you will have to turn on > > enumeration. This will eventually show up all the memberships > > although on the first startup it may take a while to show all > > groups, until they have all been downloaded and cached. > > Changes to group memberships may also take some time to show as > > enumerations are scheduled periodically and results cached. > > > > There are almost 120,000 users in our directory, and we currently > have ~200 Linux systems that might use SSSD, soon scaling to >500 > systems. I imagine that even 500 systems is only a medium-scale > installation compared to some sites. > > Client-side, it's taking 100% of one core (Core i7) at least 45 > minutes (so far) to do the enumeration (the first time around I had > logging enabled and it got up to ~13000 users in ~10 minutes, but > decided to disable logging to reduce processing). Meanwhile, all > other NSS queries using SSSD are blocking and timing out after a few > minutes, apparently waiting on the enumeration to finish. > > I'm not sure what's happening server-side, but I can just see the > directory administrators breathing down our neck if we unleashed > 200-500 systems to enumerate every user at the same time. We completely discourage enableing enumeration in bi sites, that's why it is disabled by default. > Even with caching in effect, I respectfully question this design > decision. What was wrong with the design of nss_ldap and > pam-nss-ldapd to query the directory for group membership for a > single user upon login, then cache it locally? This is exactly what we do. Although we currently are trying to do a little too much on initgroups and trying to save all user members for groups we retrieved. We are going to change initgroups to not request group members for the groups we are interested in. > Of cours when a user logs in its information (including its group > > membership) is refreshed and validated, so at login time the > > membership is correctly updated for that user across all its groups. > > > > This seems to contradict your statement above, and also the behavior > I'm seeing. It's not picking up secondary group memberships unless > they've already been cached, either through an explicit getent or, > presumably (if it ever finishes), via enumeration. Your configuration showed that enumeration is disabled (as it should be), have you changed that ? If you are witnessing long dealys on login then you are hitting the initgroups problem we are going to fix shortly. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
