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

Re: slapd-meta

>>>>>> "Pierangelo" == Pierangelo Masarati <ando@sys-net.it> writes:
>     Pierangelo> It may well be that the qmail* tool returns "no such
>     Pierangelo> object" because that is the return code that comes
>     Pierangelo> from back-meta; back-meta used to have some
>     Pierangelo> return-code issues when something strange occurred
>     Pierangelo> when processing different targets.  It should be cured
>     Pierangelo> now, but you may have found another.
> This is OpenLDAP 2.2.14. I'll try .17.

AFAIR there's a couple of useful fixes in proxy caching in 2.2.17 with
respect to 2.2.14.

>     Pierangelo> From your
>     Pierangelo> slapd.conf, you seem to be using just one target.
>     Pierangelo> Then, why don't you use back-ldap, which should be
>     Pierangelo> much more robust?
> 'One target'? I have NO idea what I'm doing here, I'm just wining it
> and hope that something work :)

I guess you realized it means proxying one single remote server.  In my
opinion, the only plus with respect to (a pool of glued) back-ldap that
back-meta still has is the capability to spawn multiple requests
simulteaneously (but I have a couple of ideas to do something similar in
back-glue) and the possibility to glue remote servers with OVERLAPPING
naming contexts.  The rest can be done otherwise (see test029 in HEAD),
thus minimizing code duplication and maintenance effort (at least from a
developer's viewpoint)

> It just dawned on me what you meant with 'one target'. I will DEFINITELY
> be using more targets, but I thought I'd start with one for now :)
> I'm using back-meta because (apparently, see other tread a month or so
> back) it's not possible to do GSSAPI authentications with back-ldap.

I don't think it possible with back-meta either, but I haven't
investigated the topic that much (sorry).

> Also, from my understanding of the man page(s), back-ldap don't do
> FS caching, only memory... ?

The manpages you're referring may be outdated.  Now proxy caching has been
moved from back-meta (with hardcoded back-ldbm local storage) to an
overlay that allows to use it for any backend (although it's meaningful
only for proxy-like backends, e.g. back-ldap, back-meta, back-sql and
back-<script> in general).

> Also, I see some (very vague) future
> improvements which back-ldap probably won't be able to fill..

?!? :)

>     Pierangelo> For the cache problem, you don't
>     Pierangelo> have any proxyAttrset referred to by the proxyTemplate
>     Pierangelo> "(&(cn=)(objectClass=))" that contains the attribute
>     Pierangelo> "ldapbasedn" yourclient appears to be looking for.  If
>     Pierangelo> you read the slapo-pcache(5) document, you'll see that
>     Pierangelo> only EXACT filters and attribute sets are cached and
>     Pierangelo> then answered.
> Eh... My understanding of the manual was that you specify which attributes
> to cache/index, number that in the proxyAttrset option THEN you
> specify a proxyTemplate with this number...
> proxyAttrset            3 locals rcptHosts ldapBaseDN ldapObjectClass
> ldapRebind ldapUid ldapGid
> [...]
> proxyTemplate           (&(cn=)(objectClass=)) 3 43200

The above proxyAttrset contains a list of attributeTypes, while the logs
you sent contained only "ldapBaseDN" (lowercased; that's why I din't note
it) in the requested attrs list.  In any case, as far as I can tell the
requested attrs list must EXACTLY match the list in the proxyAttrset; a
request for a subset (like the one you seem to be issuing) doesn't match.
that's why you get a NON ANSWERABLE/NON CACHEABLE response.


Pierangelo Masarati

    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497