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

Re: proxycache with error 'no objectClass attribute'



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.

OpenLDAP: 2.2.18 Berkeley DB: 4.2.52


> > 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!).

Here it is. http://www.openldap.org/doc/admin22/proxycache.html

> 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.

I have tried to remove all maps , but the error was still the same.
Doesn't it need to use index in in LDAP backend? I follow this guideline and it has index. So I copy it :-)
http://www.openldap.org/doc/admin22/proxycache.html


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.


Yes, first search was cached, but second and later queries the server returned err=32 (no such object)


_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! http://search.msn.com/