Re: proxycache with error 'no objectClass attribute'

["Pierangelo Masarati" <ando@sys-net.it>]

> Hi:
>     I follow "http://www.openldap.org/doc/admin22/proxycache.html";, but
> there is something wrong. When the result is cached, an error shows "no
> objectClass attribute". But If I use ldapsearch to the original LDAP
> server,
> objectClass attribute is there. What's wrong with my setting?

What version of the OpenLDAP software are you using?  The question is not
trivial nor pedantic, because there was some cleanup and fixing in
proxycache recently.

>
>     BTW, the online document about 15.2.4 Example should be
> uri             ldap://ldap.example.com instead of
> uri             ldap://ldap.example.com/dc=example%2cdc=com ?

It is not clear (to me) what doc you refer to; that's not a problem,
anyway.  In fact, back-ldap doesn't use the DN portion of the URL, but
it's not an error to leave it in place.  I suggest you file an ITS to have
that doc corrected (provided you clearly specify what document!).

>
> ldap01% ldapsearch -h ldapserver -s sub -b "o=myorg" "cn=h0131"
> # extended LDIF
> #
> # LDAPv3
> # base <o=myorg> with scope sub
> # filter: cn=h0131
> # requesting: ALL
> #
>
> # h0131, members, myorg
> dn: cn=h0131,ou=members,o=myorg
> cn: h0131
> objectClass: hostinguser
> accountStatus: 1
> mail: h0131@mail.myorg.org
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
>
> slapd.conf about ldap backend:
>
> database       ldap
> suffix         "o=myorg"
> uri            "ldap://ldapserver:389";
> lastmod  off
> map attribute mail *
> map attribute cn *
> map attribute *

This directive __REMOVES__ all remaining attributes; only "mail" and "cn"
are preserved.  As such, the proxy doesn't see the returned entries'
"objectClass".  Unless this is __EXACTLY__ what you mean (but then,
please, don't index "objectClass" at the proxy side!) you may safely
remove __ALL__ the "map" directives.  Alternatively, I think you need to
allow at least "objectClass" to be returned, because the underlying
back-bdb of the proxy cache needs it.

In any case, I see from the logs that the original query evaluates to
CACHEABLE and is actually cached (mayb it fails because "objectClass" is
missing? Subsequent queries evaluate to ANSWERABLE, so I guess they get
answered, unless the caching actually failed.

>
> overlay proxycache
> proxyCache         bdb 100000 1 1000 100
> proxyAttrset       0 mail cn
> proxyTemplate      (cn=) 0 3600
> proxyTemplate      (&(cn=)(accountstatus=)) 0 3600
> cachesize          20
> directory       /var/db/openldap-data
> index objectClass eq
> index mail,cn eq

If the fact that "objectClass" __MUST__ be present in the cached entries
is true, despite here its absence seems to be related to a
misconfiguration, I think this should be noted in the documentation.  Feel
free to file an ITS for docs updating (I mainly mean slapo-pcache(5)) if
you solve your problem by noting that the objectClass attribute __MUST__
be present in the results.  Note that this might well be local storage
dependent, i.e. be required by BDB rather than by pcache itself.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


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