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

Re: Issue when injecting a new AttributeTypes in OpenLdap



Hallvard B Furuseth wrote:
Emmanuel LÃcharny writes:
On 4/12/11 10:08 AM, Hallvard B Furuseth wrote:

Ok, get it. It would be cool (tm) that OpenLDAP accepts direct
modifications of the schema through LDAP requests.

Eh?  You can, that's why cn=config exists.  Just set up some DN to
have write access to it.  Normally a rootdn for database config.

No, you can't if you want to use the syntax for
AttributeType/OvjecClass. You have to use a specific LDIF format, and
this is the key we were discussing with some peeps : how to modify
schema for existing Ldap server in a portable way (more specifically, it
would be useful in Apache Directory Studio).

Well, that's not what you said.  Anyway, yes it would be friendly if
OpenLDAP used the same attribute types for reading and writing schema,
without an 'olc' prefix for writing.  I presume there's a good reason it
doesn't, and I don't know how hard that would be to change.

We use a custom attributeType since ours has an ORDERED-VALUES flag in the schema definition. The generic attributeType does not, and we obviously wouldn't change the generic one to add that flag.

But beyond that, server administration is not part of the LDAP standard.
There's no portable way to administer LDAP servers.  If Apache Directory
Studio thinks there is, that's a limitation of that application, not of
any server implementation.

Of course, using a LDIF format with olcXXX AT is working, but it's non
standard.

As I said, it would be very cool if OpenLDAP were allowing the schema
modification through direct LDAP modify request on cn=subschema... (of
course, ths has many implication : saving the data into cn=schema, make
the server switch the schema internally without restarting it, etc, etc...)

That happens if you just modify the correct schema entry.
But a modify request against cn=subschema lacks information about how to
administer the schema change - i.e. which cn=schema child to put it in.

Not a piece of cake !

As Hallvard said, OpenLDAP already supports dynamic schema changes, and changes take effect immediately without any restart required. And, as noted, throwing all dynamic changes into a single cn=subschema subentry (or 99user.ldif as some other servers do) is messy. I prefer to keep things well organized, with related schema elements all in their own entry. This makes schema development and management a lot easier and understandable, particularly when you're wondering what schema element came from where.

The original LDAP designers obviously didn't understand schema to begin with, let alone the issues of designing and maintaining them. (Just ces and cis? Ridiculous...)

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/