Re: (ITS#8724) slapo-pcache truncates remote results

[adam@brainfood.com]

I just cloned the source, and found where it removes the paging control.

==
/* NOTE: this is a quick workaround to let pcache minimally interact
 * with pagedResults.  A more articulated solutions would be to
 * perform the remote query without control and cache all results,
 * performing the pagedResults search only within the client
 * and the proxy.  This requires pcache to understand pagedResults. */
static int
pcache_chk_controls(
        Operation       *op,
        SlapReply       *rs )
==

Well, then since you are confirming the bug, I would say this ticket
should *not* be closed.

I might just have to patch this to make it work. The client software
I'm actually working with is nextcloud, and it is *very* *very* *very*
ldap chatty.  And with 2900+ objectclass=group, and 3300
objectclass=person, it runs super dog slow.  Their suggestion is to
install a local ldap instance configured as a caching proxy, which has
led us to here.

I've already fixed several issues in nextcloud locally(the first one I
ran into was $limit=400 hard-coded in the group search function).

This kind of paged result handling needs to be dealt the same way an
http proxy would deal with partial content caches.






On Wed, Sep 6, 2017 at 4:22 PM, Quanah Gibson-Mount <quanah@symas.com> wrote:
> Hi Adam,
>
> I would note that pcache is not back-ldap, so their behavior is not the
> same.
>
> slapo-pcache strips out the paged results control, and has since 2005
> (ec532ce88590c5454025cbc030d9df65d2df634f).  So in the 12 years since then,
> you're the first to have an issue with the behavior.  If you'd like to see a
> change in relation to this, patches welcome.
>
> --Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>