On Thu, Jul 22, 2010 at 11:59 AM, Simo Sorce <span dir="ltr"><<a href="mailto:ssorce@redhat.com">ssorce@redhat.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On Thu, 22 Jul 2010 11:10:25 -0400<br>
<div class="im">Scott Duckworth <<a href="mailto:sduckwo@clemson.edu">sduckwo@clemson.edu</a>> wrote:<br>
<br>
</div><div class="im">> I removed all files from /var/lib/sss/db/ and restarted sssd.  Same<br>
> behavior.  nscd is disabled, so I don't think it's caching at any<br>
> level.<br>
><br>
> Here is what I ran:<br>
><br>
> [root@duck2 ~]# getent passwd sduckwo<br>
> sduckwo:*:45265:10000:Scott Duckworth:/home/sduckwo:/bin/bash<br>
> [root@duck2 ~]# groups sduckwo<br>
> sduckwo : cuuser<br>
> [root@duck2 ~]# getent group coes_socunix<br>
> coes_socunix:*:120105:sduckwo<br>
<br></div></blockquote><div><br>I should add to this, that what I expected to see is this (from one of the RHEL boxes using nss_ldap):<br><br>[root@potter commands]# groups sduckwo<br>sduckwo : cuuser coes_dpa coes_socunix coes_web_cs coes_web_fx<br>
<br>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.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
</div>When enumeration is disabled this is the normal behavior.<br>
You will see only users/groups that have been fetched. Generally at<br>
login time because of the initgroups call.<br>
Ie a users will always have correct memmberships, but groups may not<br>
should all user members they truly have in the ldap server.<br>
<br>
If you require perfect representation you will have to turn on<br>
enumeration. This will eventually show up all the memberships although<br>
on the first startup it may take a while to show all groups, until they<br>
have all been downloaded and cached.<br>
Changes to group memberships may also take some time to show as<br>
enumerations are scheduled periodically and results cached.<br></blockquote><div><br>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.<br>
<br>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.<br>
<br>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.<br><br>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?<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Of cours when a user logs in its information (including its group<br>
membership) is refreshed and validated, so at login time the membership<br>
is correctly updated for that user across all its groups.<br></blockquote><div><br>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.<br>
<br>Thanks,<br><br>Scott Duckworth<br></div></div>