[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#4411) ldapsearch hangs with proxyCache



daveh@ci.com.au wrote:
> Full_Name: Dave Horsfall
> Version: 2.3.19
> OS: FreeBSD 4.10-STABLE
> URL: ftp://ftp.openldap.org/incoming/dave-horsfall-060217.tar.gz
> Submission from: (NULL) (192.65.182.30)
>
>
> OpenLDAP 2.3.19 + syncprov.c from HEAD, BDB db42-4.2.52_3, FreeBSD 4.10.
>
> Refer to ftp://ftp.openldap.org/incoming/dave-horsfall-060217.tar.gz,
> containing "slapd.conf" (obvious) and "gdb.slapd" (a back-trace of SLAPD).
>
> Result of search with proxycache commented out:
>
> # extended LDIF
> #
> # LDAPv3
> # base <dc=AdminView> with scope subtree
> # filter: (&(objectclass=ciapplication)(ciapp=orck))
> # requesting: ciAppType 
> #
>
> # orck, au.cordoors.dev
> dn: ciApp=orck,dc=au,dc=cordoors,dc=dev
> ciAppType: MER
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
>
> I'm willing to accept that I'm a total idiot, and that the proxycache is
> woefully misconfigured...
>   

It turns out this is actually a misconfigured back-meta. Since you 
searched with a base dc=AdminView all of the resulting entries should 
have their DNs rewritten to reside under that base. You need to 
configure the searchResult rewriteContext as shown in slapd-meta(5).

I wonder if we should add an assert to back-meta to prevent it from 
returning entries with mismatched DNs...

-- 
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  OpenLDAP Core Team            http://www.openldap.org/project/