Hi all, I was wondering about the following thing (after just reading the long cn=config thread), programs may distribute .schema files only, in which case as already pointed out you should: 1. Request in a friendly manner that they provide an ldif if possible 2. convert it yourself using slaptest and add it using ldapadd/modiy etc.
The question I had is like this, a project may update/change it's schema and if they ship only .schema files or .ldif that assume that the schema is not loaded yet (ie. that do the initial add and not modify operations, what you would also get from a .schema conversion) then you are it would seem to me a bit stuck because you either: - have to unload the old schemas (using ldapmodify) which leaves you with invalid entries in your DIT while their schema is missing or - you have to manually figure out what the differences are between the currently loaded schema and the new version of the schema (diff may be helpful there) and the manually create an ldif that does all the necessary modify operations.
So I was wondering if there is any way to generate a "diff-ldif" (for lack of a better name) automatically to update the schema based either on provided ldifs or provided .schema files (after conversion).
Obviously the other way is to ask the project in a friendly way that they provide said "diff-ldifs" as well as regular ldifs.
Maybe I am completely wrong but so far this is what I understood from all the manuals etc.
Thanks for all your great work, Eli
2011/7/6 E.S. Rosenberg esr+openldap@g.jct.ac.il:
Hi all, I was wondering about the following thing (after just reading the long cn=config thread), programs may distribute .schema files only, in which case as already pointed out you should:
- Request in a friendly manner that they provide an ldif if possible
- convert it yourself using slaptest and add it using ldapadd/modiy etc.
The question I had is like this, a project may update/change it's schema and if they ship only .schema files or .ldif that assume that the schema is not loaded yet (ie. that do the initial add and not modify operations, what you would also get from a .schema conversion) then you are it would seem to me a bit stuck because you either:
- have to unload the old schemas (using ldapmodify) which leaves you
with invalid entries in your DIT while their schema is missing or
- you have to manually figure out what the differences are between the
currently loaded schema and the new version of the schema (diff may be helpful there) and the manually create an ldif that does all the necessary modify operations.
So I was wondering if there is any way to generate a "diff-ldif" (for lack of a better name) automatically to update the schema based either on provided ldifs or provided .schema files (after conversion).
Obviously the other way is to ask the project in a friendly way that they provide said "diff-ldifs" as well as regular ldifs.
Maybe I am completely wrong but so far this is what I understood from all the manuals etc.
Hi,
I think that application providers should manage schema diff themselves, like they would do with sql schema : * a complete schema for those installing the software for the first time on the system * an update schema to migrate the schema from the previous version to the current version
On my side, the problem I see is that LDIF schema for OpenLDAP is OpenLDAP specific (because of the olc* attributes names) and cannot be imported in other LDAP servers like OpenDJ or ApacheDS. So application providers will have to ship LDIF schema for OpenLDAP and LDIF schema for other servers. Can't we find a solution to have a standard LDIF schema import/update?
Clément.
Clément OUDOT wrote:
On my side, the problem I see is that LDIF schema for OpenLDAP is OpenLDAP specific (because of the olc* attributes names) and cannot be imported in other LDAP servers like OpenDJ or ApacheDS. So application providers will have to ship LDIF schema for OpenLDAP and LDIF schema for other servers. Can't we find a solution to have a standard LDIF schema import/update?
".schema" files are also specific to OpenLDAP so the problem hasn't changed.
I'm not sure there's really any standard LDIF format for schema imports. Other servers support modifications to the subschema subentry but IMO that's a terrible way to import new schema because it's all lumped into one spot and precludes any kind of organization.
We could extend back-config to accept the regular attributeTypes and objectClasses attributes, but you would still have the difference that OpenLDAP schema all reside in their own respective entries, as opposed to all being lumped into a single entry.
openldap-technical@openldap.org
-
Clément OUDOT -
E.S. Rosenberg -
Howard Chu