[Freeipa-users] SSS problems with eDirectory

[Scott Duckworth]

On Thu, Jul 22, 2010 at 11:59 AM, Simo Sorce <ssorce at redhat.com> wrote:

> On Thu, 22 Jul 2010 11:10:25 -0400
> Scott Duckworth <sduckwo at 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:
> >
> > [root at duck2 ~]# getent passwd sduckwo
> > sduckwo:*:45265:10000:Scott Duckworth:/home/sduckwo:/bin/bash
> > [root at duck2 ~]# groups sduckwo
> > sduckwo : cuuser
> > [root at 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):

[root at potter commands]# groups sduckwo
sduckwo : cuuser coes_dpa coes_socunix coes_web_cs coes_web_fx

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.

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?

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.

Thanks,

Scott Duckworth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20100722/e110dc4d/attachment.htm>