On Tue, Jun 7, 2022 at 10:42 AM Gregory Carter <[email protected]> wrote: > > I went with OpenLDAP. I had AD running for integration with Windows users > using PowerBroker, but found it hard to justify shutting my linux users down > when I had to work on a Microsoft product, or vice versa for that matter. > Far fewer issues really even though I am running two different systems > (OpenLDAP/Active Directory) the problem time went away trying to get both of > them to work. I spend far less time managing two separate systems now than > trying to get them both to work together. > > 1.16 is pretty old for something with as much churn as sssd. I would try to > stay within at least a year of the current version if you are concerned about > support issues. > > I normally get around that sort of thing with the bosses by doing extensive > testing in the lab before I roll out something not found in my RHEL 7 package > list. (i.e. sssd 1.16>)
Agreed, I will be looking at the feasibility of using a more current client. > Diplomacy I found was the best option. :-) > > PS: https://bugzilla.redhat.com/show_bug.cgi?id=1984591 Thanks for the bug report which has "id sssd" taking 7.3 seconds to complete and then increasing to ~90 seconds post software update. The pre-update time of 7 seconds seems slow to me. Is that the initial, first time response? e.g. once "id sssd" is cached, additional "id sssd" operations are near instantaneous, with perhaps a background process keeping the cache up to date? Or do sssd customers expect id $account and ls -l large_directory_contents to take a few seconds after some inactivity of a few hours? I'm hoping that a combination of a streamlined, well organized AD or equivalent ldap backend, along with a well configured sssd cache will give my customers who are used to NIS performance a similar experience with an sssd client. > > On Tue, Jun 7, 2022 at 8:41 AM Mark Christian <[email protected]> wrote: >> >> 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 > > _______________________________________________ > 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 _______________________________________________ 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
