Re: (ITS#8163) Broken handling of deprecated attributes

[michael@stroeder.com]

On 2015-06-03 11:20, Pierre Schweitzer wrote:
> This is not a question, but really a bug report about a broken 
> behavior.

Again:
I can confirm that requesting an attribute which does not exist in the
subschema does not affect whether an entry is returned.

> I quote them again: "Potentially, OpenLDAP should have a bug raised to
> make it impossible to get into a situation where error 65 is returned 
> on
> a query, as it likely does not conform to the RFC."

Again: This statement is right and AFACIS OpenLDAP always worked 
correctly.

> Here is the log extract you're asking for (I just filtered out the base 
> DN):
> Jun  3 09:17:30 rose-java slapd[6776]: conn=1516 op=1 SRCH base="XXXX"
> scope=2 deref=0 filter="(&(objectClass=inetOrgPerson)(uid=heis 
> spiter))"
> Jun  3 09:17:30 rose-java slapd[6776]: conn=1516 op=1 SRCH
> attr=javaRemoteLocation
> Jun  3 09:17:30 rose-java slapd[6776]: conn=1516 op=1 SEARCH RESULT
> tag=101 err=65 nentries=0 text=

Up to now there's absolutely no evidence in the information you provided 
that this is a bug.

How did you make sure that an entry should be returned for exactly this
search with the bound identity and your configuration?

I suspect a configuration or data error on your side. Many things can be 
wrong.
Without seeing your config, data and the bound identity nobody can
track this down for you.

Ciao, Michael.