[Date Prev][Date Next]
Re: Issue when injecting a new AttributeTypes in OpenLdap
On 4/12/11 11:27 AM, 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.
Yeah, sorry, I was a bit rough and fuzzy in my first mail...
It's not easy... But definitively feasible. Too sad I don't code in C
any more :-)
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.
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.
RFC 4512 says explicitely (chap 4.2) :
"Servers MAY allow subschema modification. Procedures for subschema
modification are discussed in Section 14.5 of [X.501]." (btw, it's 15.5,
In X/500, such modification is to be supported, but it might have been
considered as a rigid constraint in LDAP.
However, Studio does not care if OpenLDAP support or not such a feature.
It will provide a way to update OpenLDAP schema whatever the way we have
to do it, it's just painful that we can't do it in a more standard (ie
Not to mention that someone who want to address this very problem (ie,
updating the schema) programmatically is actually totally on his own...
But this is not an OpenLDAP problem, it's really a lack in LDAP