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
