I'm wondering what configuration options I should be tweaking to improve id to name resolution when running commands such as ls -l, and id? My sssd version is 1.16.*, and the sssd configuration consists of: [sssd] domains = DOM1.COM ... [nss] entry_cache_timeout=5400 refresh_expired_interval=4050 ... [domain/DOM1.COM] id_provider = ad auth_provider = ad ad_enabled_domains = dom1.com, dom2.com, dom3.com, dom4.com ldap_referrals = false ldap_id_mapping = false ldap_access_order = expire ldap_account_expire_policy = ad ldap_force_upper_case_realm = true ldap_group_nesting_level = 0 ldap_use_tokengroups = false ... [domain/DOM1.COM/DOM2.COM] ... [domain/DOM1.COM/DOM3.COM] ... [domain/DOM1.COM/DOM4.COM] ...
ldap_user_search_base/ ldap_group_search_base are used to limit which OUs to query. But at this moment I'm not able to use the filter option for these parameters to possibly help performance. Some accounts have as many as 250 groups. enumerating group membership via "id -G $account" happens quickly enough. Initial name to id mapping is a bit slow (id $account), but I can tolerate that. I was hoping that the refresh_expired_interval setting would keep the entry cache from "losing" the id to name mappings, but it seems that after some period of time, running something like ls -l on a directory full of hundreds of different group owned dirs takes longer than I would like. What sssd.conf options should I be considering to keep the id to name cache from expiring? What other options or strategies might I consider to prepopulate the sssd cache? I'm trying to migrate off a NIS environment, where name to id mapping is near instantaneous and I'm hoping sssd might perform as well. I'm also investigating re-architecting AD, placing all groups/accounts in one Domain or perhaps ditching AD in favor of freeIPA or equivalent. I must accommodate 50K+ accounts, thousands of groups and ideally get the same performance that NIS has historically offered. _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
