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...
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.
It's not easy... But definitively feasible. Too sad I don't code in C any more :-)
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, NOT 14.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 X500) way...
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 specifications !