Re: getting at the schema for an object

[Ben Martin <monkeyiq@users.sourceforge.net>]

On Mon, 2002-12-30 at 02:44, Tony Earnshaw wrote:
> søn, 2002-12-29 kl. 12:39 skrev Ben Martin:
> 
> > After looking at the sources for gq and the list archives I am still a
> > little lost as to how given a DN to get the schema for that object.
> 
> I'm a little puzzled about what you mean, even after having read the
> rest a couple of times.

I give a overview of my main goal below in case (hum, because) my LDAP
knowledge is limited in many ways. 

> 
> Supposing I want to get all the object classes for
> dn="cn=tonye,ou=people,ou=groups,dc=billy,dc=demon,dc=nl" and from these
> deduce the schemas (because there are a number of relevant schemas
> involved):
> 
> ldapsearch -x -H ldaps://localhost/ '(&(uid=tonye)(objectClass=*))' |
> grep objectClass
> 
> 1027 [root:billy.demon.nl] /root # ldapsearch -x -H ldaps://localhost/
> '(&(uid=tonye)(objectClass=*))
> # filter: (&(uid=tonye)(objectClass=*))
> objectClass: top
> objectClass: person
> objectClass: organizationalPerson
> objectClass: inetOrgPerson
> objectClass: evolutionPerson
> objectClass: posixAccount
> objectClass: shadowAccount
> objectClass: calEntry

I get the objectclass attributes for the object here too.
ldapsearch -x -h localhost  "(&(cn=ben)(objectClass=*))" -b
"dc=my-domain, dc=com"|grep ject
# filter: (&(cn=ben)(objectClass=*))
objectClass: person
objectClass: organizationalPerson

Its the deducing of the schemas from these that I have a problem with

int ec = 0;
const char* es = "";
const int flags = LDAP_SCHEMA_ALLOW_ALL;
// get the first value for the attribute objectclass for the current DN
string objectclass = getValue( "objectClass" );
// objectclass == person

LDAPObjectClass* oc = ldap_str2objectclass( objectclass.c_str(),
                                            &ec, &es, flags );
after 
ec == LDAP_SCHERR_NOLEFTPAREN
es == objectclass.c_str()

which is my main problem, what do you feed in as objectclass 
"person" etc fail. And if its the long bracketed line where can this
value be found from a existing DN?

> grep each objectclass in the schema directory will surely return the
> relevant schemas? Apart from those "built in" [1]

This is the main part I'm having a problem with. I think I should have
explained what I am doing: making a plugin for libferris to be able to
mount LDAP as a filesystem. The schema issue comes in when a new
"object" is created, as to make new objects the objectClass mandates
that some attributes must be given a value at inception. This is all
fine because to make new objects in libferris you first get an XSD file
describing what objects can be created at this level and the attributes
that effect that object. The main thing I need is to convert the
required and optional attributes for the objectClasses that can be
created at a level into XSD. 

I was thinking that once I can get at the schema and poke around what
attributes are required / optional for an objectclass then at least for
version 1 I could create XSD for each objectclass and its attribute
requirements (which would be big and slow). I was wanting to have the
lookup for objectclass to attributes be quick so that later when I
restrict the objectclasses that can be made at a certen level (assuming
that an objectclass can restrict what children can be made under it)
then the XSD file will be fastish to create.

I already have command line and GTK2 clients using this XSD to allow
users to do extended mkdir operations:
http://witme.sourceforge.net/ferriscreate.paper2001/

> 
> > I'm using the C API to do this.
> 
> Possibly. I'm using the command line. In as much as I can (in theory, I
> don't in practice, apart from cal.schema and bits of
> evolutionPerson.schema) define my own schemas, what other way would
> there be? I've stuffed all sorts of Horde basic stuff into
> evolutionPerson.schema, so what does/do the schema(s) have to do with
> objectClasses? let alone other attributes?

libferris being a generic VFS should support any schemas that folks use
with their LDAP server. I don't want to assume anything about the schema
apart from the ability to ask openldap about the objectclasses and
attributes that are req/optional for each.

> 
> *[1] Granted GQ doesn't let one see what schemas give rise to what
> attributes. But, then some attributes are "built in" to 2.1.8 slapd and
> 3 other 2.1.8 Openldap utils, irrespective of schemas.
> 
> Best,
> 
> Tony
> 
> Puzzled
-- 
Ben Martin <monkeyiq@users.sourceforge.net>