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

Re: (ITS#4786) back-sql searching with dn attribute selected causes object class violation



Pierangelo Masarati wrote:
> I'll note that unless you defined it yourself, "dn" is not a valid 
> attribute name.  I suspect your back-sql meta-data generates an entry 
> that doesn't pass schema checking, otherwise I don't see a chance for 
> that error to be reported.

Pierangelo,

the objects are inetOrgPerson objects, the full object looks like this

# robb@example.org, sql.example.org
dn: uid=robb@example.org,dc=sql,dc=example,dc=org
objectClass: inetOrgPerson
cn: Robert Brooks
uid: robb@example.org
mail: robb@example.org

I believe the only required attribute for such an object is cn. A 
similar search against a non back-sql part for the tree (see below) does 
not show an error
ldapsearch -x -b "ou=people,dc=example,dc=org" "cn=Robert Brooks" dn cn 
objectclass

# robb, people, example.org
dn: uid=robb,ou=people,dc=example,dc=org
cn: Robert Brooks
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount

Unfortunately seems some software doesn't understand it doesn't need to 
request dn explicitly hence I noticed this.

 > In any case, since the behavior you report is very data and meta-data
 > dependent, you don't provide enough info for debugging, and at a very
 > first glance this is not indicative of a software bug.

Let me know what you'd like, I thought this one may well reproduce on 
any back-sql, so didn't spray the ITS with extraneous information.

Regards,

Rob

-- 
Robert Brooks,           Network Manager,          Cable & Wireless UK
<robb@wtg.cw.com>                                   http://wtg.cw.com/
Tel: +44 (0)20 7339 8600                      Fax: +44 (0)20 7339 8601
-              "What was your username again?" - BOFH                -