Bug 799008 - Improve behavior of LDAP paging control with servers with paging limits
Improve behavior of LDAP paging control with servers with paging limits
Status: CLOSED DEFERRED
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd (Show other bugs)
7.0
Unspecified Unspecified
medium Severity high
: rc
: ---
Assigned To: SSSD Maintainers
Kaushik Banerjee
:
Depends On:
Blocks: 1113520 1133060 1205796
  Show dependency treegraph
 
Reported: 2012-03-01 09:43 EST by Stephen Gallagher
Modified: 2015-07-09 06:12 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-04-24 07:22:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stephen Gallagher 2012-03-01 09:43:32 EST
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/sssd/ticket/1207

This ticket has been split from ticket #1202 to address the more complicated parts of this fix.

We added support for the Simple Paged Search in ticket #658 and SSSD 1.5.8. When we did so, we chose to default to always requesting paged searches for all requests. However, it turns out that RFC 2696 does not mandate that the LDAP server supports more than one paging search at a time on the same connection. Some LDAP servers (notably 389 DS 1.2.9 and older) allow only a single paged search to be in progress on a request at one time. This results in receiving an error from LDAP that the server refuses to perform the operation. Once ticket #1201 is fixed, this will result in offline operation (right now it's misbehaving as if it received zero results). We need to avoid both of these events.

RFC 2696 does specify that if the result size being returned is smaller than the requested page size that the paging control '''should''' be ignored. This would mitigate the problem, but it appears that 389 DS also chooses to not ignore the control in this case.

In general, we need to find ways to minimize our usage of the paging control where available. I propose the following changes:

1. Add a boolean option to {{{ldap_generic_search_send()}}} to specify whether to use the paging control (when available). -- done in Ticket #1202
1. Do not request the paging control when we expect a single-valued return from the request.
1. Always request the paging control for enumeration requests. -- done in Ticket #1202
1. Serialize paging requests by maintaining a queue of lookups requiring paging and allow only one to operate at a time.{{{[1]}}}
1. If it can be reasonably determined that replies will never exceed 500 entries, also omit the paging control{{{[2]}}}

{{{[1]}}}: This will likely introduce apparent performance issues when performing initgroups() requests, since they will no longer be able to run in parallel. We must always assume that the user may belong to many groups.

{{{[2]}}}: I'm not 100% sure about this one. It's possible for a server to manually set its page size smaller than 500, though I doubt very many would do so. On the other hand, I can't come up with any ideas offhand for lookups of greater than a single entry that could not therefore result in a potentially-infinite set of results. So this may be a moot point.
Comment 1 Jenny Galipeau 2012-06-22 09:35:34 EDT
Please add details on exactly what was done to "improve" paging behavior
Comment 2 RHEL Product and Program Management 2012-07-10 02:13:22 EDT
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 3 RHEL Product and Program Management 2012-07-10 22:04:30 EDT
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.
Comment 6 Jakub Hrozek 2014-07-02 11:08:08 EDT
The upstream ticket is targetting 1.13, so I'm reproposing the BZ to RHEL-7.2
Comment 8 Martin Kosek 2015-04-24 07:22:38 EDT
Thank you taking your time and submitting this request for Red Hat Enterprise Linux. Unfortunately, this bug was not given a priority and was deferred both in the upstream project and in Red Hat Enterprise Linux.

Given that we are unable to fulfill this request in following Red Hat Enterprise Linux releases, I am closing the Bugzilla as DEFERRED. To request that Red Hat re-considers the decision, please re-open the Bugzilla via appropriate support channels and provide additional business and/or technical details about its importance to you.

Note that you can still track this request or even contribute patches in the referred upstream Trac ticket.

Note You need to log in before you can comment on or make changes to this bug.