Hi,
On Thu, Jun 22, 2023 at 7:52 PM Spike White <[email protected]> wrote: > Alexey, > > Thanks for the suggestion. > > This is a commercial application. Cloudera's hadoop implementation. No > idea if they use getgrouplist() under the hood. I can ask our Cloudera > tech engineer, but I doubt he knows either. > > sssd-ad seems to work pretty well on these servers, except for these > occasional hiccups. It's over 150 nodes in this hadoop cluster, with only > these occasional hiccups. Been AD integrated for >1 yr and app team happy > (except for one annoying occasional cross-domain caching issue.) > > In particular, sssd finds its AD site so it's binding to AD DCs local to > this datacenter. (I checked that first thing.) > > These sporadic hiccups I discuss earlier seem limited to local users only, > looking up their group memberships. > > Would the /etc/nsswitch.conf file syntax be: > > initgroups: files [SUCCESS=return] systemd sss > > It seems this would apply for all accounts that were members of local > groups and not just these specific accounts. (Not sure that's a problem > for this particular app team, but I've seen AD accounts added in /etc/group > as members of local groups.) > > To me, "filter_users" in sssd.conf where I specify the specific accounts > would be safer. > Then filtering sounds as a way to go. If you are courageous you can also try to read SSSD logs to figure out the reason for those "sporadic hiccups". Latest version, around sssd-2.8+, should make it easier to track a specific lookup across a set of logs. > > Spike > > On Thu, Jun 22, 2023 at 10:44 AM Alexey Tikhonov <[email protected]> > wrote: > >> Hi, >> >> On Thu, Jun 22, 2023 at 4:47 PM Spike White <[email protected]> >> wrote: >> >>> All, >>> >>> Successful sssd consumer here. >>> >>> Have an app team running Hadoop. They're getting these performance >>> errors in their app. >>> >>> This is from their app logs. >>> >>> ddlflhdm201.us.company.com >>> WARN June 15, 2023 10:08 AM Groups Potential performance problem: >>> getGroups(user=hbase) took 58022 milliseconds >>> >> >> Does it use `getgrouplist()` under the hood? >> >> >>> ddlflhdm304.us.company.com >>> WARN June 15, 2023 8:38 AM Groups Potential performance problem: >>> getGroups(user=mapred) took 39962 milliseconds >>> ddlplhdm505.us.company.com >>> WARN June 16, 2023 5:37 AM Groups Potential performance problem: >>> getGroups(user=hdfs) took 62437 milliseconds. >>> ddlplhdm305.us.company.com >>> WARN June 15, 2023 9:36 PM Groups Potential performance problem: >>> getGroups(user=hdfs) took 58017 milliseconds >>> >>> ddlplhdm505.us.company.com >>> WARN June 10, 2023 8:01 AM Groups Potential performance problem: >>> getGroups(user=yarn) took 58017 milliseconds. >>> >>> >>> Interestingly, all these users are local users created by the Hadoop >>> package installation. (hbase, mapred, hdfs, yarn are all local users). >>> >>> >>> These local users are members only of local groups. So theoretically >>> the search for group memberships should be lightning quick as the groups >>> are found only in /etc/group. >>> >>> >>> But since my /etc/nsswitch.conf looks like this: >>> >>> >>> passwd: files systemd sss >>> >>> group: files systemd sss >>> >>> netgroup: files sss >>> >>> automount: files sss >>> >>> services: files >>> >>> shadow: files sss >>> >>> hosts: files dns myhostname >>> >> >> You might consider specifying 'initgroups' explicitly and using something >> like '[SUCCESS=return]' between databases to avoid going to sss altogether >> (but see below) >> >>> >>> >>> It not only searches local files for group membership, it searches AD as >>> well. And doesn't find it, as there is no such AD user or uid. >>> Eventually timing out. >>> >>> >>> In /var/log/messages we see this around the same time frame as >>> >>> >>> Jun 15 10:08:09 ddlflhdm201 sssd[be[amer.company.com]]: GSSAPI Error: >>> An invalid name was supplied (Success) >>> >> >> Is sssd-ad properly configured at this host? >> Initgroups lookup for unknown users should be fast. >> >> >> >>> >>> Is there a way to restrict these particular local app accounts from >>> having their group memberships looked up in AD? >>> >>> I.e., my [nss] section looks like this today: >>> >>> [nss] >>> #debug_level = 9 >>> filter_groups = root >>> filter_users = root >>> #override_homedir = /home/%u >>> >>> Can I do this? >>> >>> [nss] >>> filter_users = root, hbase, mapred, hdfs, yarn >>> >>> And would I want to set filter_users_in_groups = false? >>> >>> Spike White >>> >>> >>> _______________________________________________ >>> sssd-users mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> Fedora Code of Conduct: >>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >>> List Archives: >>> https://lists.fedorahosted.org/archives/list/[email protected] >>> Do not reply to spam, report it: >>> https://pagure.io/fedora-infrastructure/new_issue >>> >> _______________________________________________ >> sssd-users mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedorahosted.org/archives/list/[email protected] >> Do not reply to spam, report it: >> https://pagure.io/fedora-infrastructure/new_issue >> > _______________________________________________ > sssd-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/[email protected] > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue >
_______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
