Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
The LDAP queries performed with scope=sub can be complex and overload the LDAP server.
For example, SUDO rules LDAP queries performed with scope=sub over a large basedn, could cause an unneeded load.
As a reference of the scope, the customer used:
https://ldapwiki.com/wiki/LDAP%20Search%20Scopes
As changing the sssd scope attribute of the LDAP queries would be disruptive for the running sssd configurations, as the results would change, we would suggest at least to document the fact that for best performance sssd should be set with a smaller scope (eg scope=one).
The customer would recommend considering the switch to scope=one in RHEL9 (or anyway starting with upstream).
Version-Release number of selected component (if applicable):
Any
How reproducible:
Check the documentation
Steps to Reproduce:
1.
2.
3.
Actual results:
The documentation does not report that scope=sub could introduce a performance issue
Expected results:
The documentation must report that scope=sub could introduce a performance issue
Additional info:
Hi,
imo it is highly dependent on the server-side implementation if scope=one has a better performance than scope=sub. Most important for the server-side performance are proper indices and if those are available there shouldn't a difference between the scopes assuming that the searched objects are all in the same container. With respect to the documentation we can mention that indices should be used to improve performance, emphasizing the scope might be misleading.
In general SSSD already allows to set the scope with the search base, e.g. for sudo rules see ldap_sudo_search_base in man sssd-ldap for details. So I see no reason to change the default scope.
HTH
bye,
Sumit
# man sssd-sudo | awk /'TUNING THE PERFORMANCE'/,/'SEE ALSO'/
TUNING THE PERFORMANCE
SSSD uses different kinds of mechanisms with more or less complex LDAP filters to keep the cached sudo rules up to date. The default configuration is set to values that should satisfy most of our
users, but the following paragraps contains few tips on how to fine tune the configuration to your requirements.
1. Index LDAP attributes. Make sure that following LDAP attributes are indexed: objectClass, cn, entryUSN or modifyTimestamp.
2. Set ldap_sudo_search_base. Set the search base to the container that holds the sudo rules to limit the scope of the lookup.
3. Set full and smart refresh interval. If your sudo rules do not change often and you do not require quick update of cached rules on your clients, you may consider increasing the
ldap_sudo_full_refresh_interval and ldap_sudo_smart_refresh_interval. You may also consider disabling the smart refresh by setting ldap_sudo_smart_refresh_interval = 0.
4. If you have large number of clients, you may consider increasing the value of ldap_sudo_random_offset to distribute the load on the server better.
SEE ALSO
[root@auto-hv-01-guest01 ~]# rpm -q sssd
sssd-2.5.0-1.el8.x86_64
[root@vm-idm-023 ~]# man sssd-sudo | awk /'TUNING THE PERFORMANCE'/,/'SEE ALSO'/
TUNING THE PERFORMANCE
SSSD uses different kinds of mechanisms with more or less complex LDAP filters to keep the cached sudo rules up to date. The default configuration is set to values
that should satisfy most of our users, but the following paragraps contains few tips on how to fine tune the configuration to your requirements.
1. Index LDAP attributes. Make sure that following LDAP attributes are indexed: objectClass, cn, entryUSN or modifyTimestamp.
2. Set ldap_sudo_search_base. Set the search base to the container that holds the sudo rules to limit the scope of the lookup.
3. Set full and smart refresh interval. If your sudo rules do not change often and you do not require quick update of cached rules on your clients, you may
consider increasing the ldap_sudo_full_refresh_interval and ldap_sudo_smart_refresh_interval. You may also consider disabling the smart refresh by setting
ldap_sudo_smart_refresh_interval = 0.
4. If you have large number of clients, you may consider increasing the value of ldap_sudo_random_offset to distribute the load on the server better.
SEE ALSO
[root@vm-idm-023 ~]# rpm -q sssd
sssd-2.5.0-1.el8.x86_64
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (sssd bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2021:4435