LDIF kann LDAP-Aktualisierungsoperationen darstellen, weshalb Sie mit LDIF das Schema ändern können.
Zum Hinzufügen einer Klasse fügen Sie einfach einen Attributwert hinzu, welcher der Spezifikation für NDSObjectClassDescription für das Attribut objectClasses von subschemaSubentry entspricht.
NDSObjectClassDescription = "(" whsp numericoid whsp [ "NAME" qdescrs ] [ "DESC" qdstring ] [ "OBSOLETE" whsp ] [ "SUP" oids ] [ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ] [ "MUST" oids ] [ "MAY" oids ] [ "X-NDS_NOT_CONTAINER" qdstrings ] [ "X-NDS_NONREMOVABLE" qdstrings ] [ "X-NDS_CONTAINMENT" qdstrings ] [ "X-NDS_NAMING" qdstrings ] [ "X-NDS_NAME" qdstrings ] whsp ")"
Die folgende LDIF-Beispieldatei fügt die Objektklasse person zum Schema hinzu:
1 version: 1 2 dn: cn=schema 3 changetype: add 4 objectClasses: ( 2.5.6.6 NAME ’person’ DESC ’Standard 5 ObjectClass’ SUP ndsLoginProperties STRUCTURAL MUST 6 (cn $ sn) MAY (description $ seeAlso $ telephoneNum 7 ber $ fullName $ givenName $ initials $ uid $ userPa 8 ssword) X-NDS_NAMING (’cn’ ’uid’) X-NDS_CONTAINMENT 9 (’organization’ ’organizationalUnit’ ’domain’) X-NDS 10 _NAME ’Person’ X-NDS_NOT_CONTAINER ’1’ X-NDS_NONREMO 11 VABLE ’1’) 12
Obligatorische Attribute werden im MUST-Abschnitt der Objektklassenbeschreibung aufgeführt. Bei der Objektklasse „person“ lauten die obligatorischen Attribute cn und sn.
Optionale Attribute werden im MAY-Abschnitt der Objektklassenbeschreibung aufgeführt. Die optionalen Attribute der Objektklasse person sind description, seeAlso, telephoneNumber, fullName, givenName, initials, uid und userPassword.
HINWEIS:Das Attribut userPassword darf nicht als optionales Attribut (im Abschnitt MAY) verwendet werden. Bei der Operation tritt ein Fehler auf, wenn Sie versuchen, das Attribut als obligatorisches Attribut (MUST) in der neuen objectClass mit diesem LDIF-Format zur Erweiterung des Schemas zu verwenden.
Die Objektklassen, welche die zu definierende Objektklasse enthalten können, werden im Abschnitt X-NDS_CONTAINMENT der Objektklassenbeschreibung aufgeführt. Die Objektklasse person kann in den Objektklassen organization, organizationalUnit und domain enthalten sein.
Zum Hinzufügen eines Attributs fügen Sie einfach einen Attributwert hinzu, welcher der Spezifikation für NDSAttributeTypeDescription für das Attribut „attributes“ von subschemaSubentry entspricht.
NDSAttributeTypeDescription = "(" whsp numericoid whsp ; AttributeType identifier [ "NAME" qdescrs ] ; name used in AttributeType [ "DESC" qdstring ] ; description [ "OBSOLETE" whsp ] [ "SUP" woid ] ; derived from this other AttributeType [ "EQUALITY" woid] ; Matching Rule name [ "ORDERING" woid] ; Matching Rule name [ "SUBSTR" woid ] ; Matching Rule name [ "SYNTAX" whsp noidlen whsp ] ; Syntax OID [ "SINGLE-VALUE" whsp ] ; default multi-valued [ "COLLECTIVE" whsp ] ; default not collective [ "NO-USER-MODIFICATION" whsp ] ; default user modifiable [ "USAGE" whsp AttributeUsage ] ; default userApplications [ "X-NDS_PUBLIC_READ" qdstrings ] ; default not public read (’0’) [ "X-NDS_SERVER_READ" qdstrings ] ; default not server read (’0’) [ "X-NDS_NEVER_SYNC" qdstrings ] ; default not never sync (’0’) [ "X-NDS_NOT_SCHED_SYNC_IMMEDIATE" qdstrings ] ; default sched sync immediate (’0’) [ "X-NDS_SCHED_SYNC_NEVER" qdstrings ] ; default schedule sync (’0’) [ "X-NDS_LOWER_BOUND" qdstrings ] ; default no lower bound(’0’) ;(upper is specified in SYNTAX) [ "X-NDS_NAME_VALUE_ACCESS" qdstrings ] ; default not name value access (’0’) [ "X-NDS_NAME" qdstrings ] ; legacy NDS name whsp ")"
Die folgende LDIF-Beispieldatei fügt den Attributtyp title zum Schema hinzu:
1 version: 1 2 dn: cn=schema 3 changetype: add 4 attributeTypes: ( 2.5.4.12 NAME ’title’ DESC ’Standa 5 rd Attribute’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{ 6 64} X-NDS_NAME ’Title’ X-NDS_NOT_SCHED_SYNC_IMMEDIA 7 TE ’1’ X-NDS_LOWER_BOUND ’1’) 8
Attribute werden standardmäßig als mehrwertige Attribute voreingestellt, außer sie werden ausdrücklich als einwertig definiert. Im folgenden Beispiel wird in der LDIF-Datei der Titel als einwertig definiert, indem das Schlüsselwort SINGLE-VALUE nach dem Abschnitt SYNTAX hinzugefügt wird:
1 version: 1 2 dn: cn=schema 3 changetype: add 4 attributeTypes: ( 2.5.4.12 NAME ’title’ DESC ’Standa 5 rd Attribute’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{ 6 64} SINGLE-VALUE X-NDS_NAME ’Title’ X-NDS_NOT_SCHED 7 _SYNC_IMMEDIATE ’1’ X-NDS_LOWER_BOUND ’1’) 8
Das Hinzufügen neuer Schema-Elemente ist im Allgemeinen akzeptabel, aber das Ändern oder Erweitern vorhandener Schema-Elemente ist normalerweise gefährlich. Jedes Schema-Element wird eindeutig durch eine OID identifiziert. Wenn Sie deshalb ein Standardschema-Element erweitern, erstellen Sie im Prinzip eine zweite Definition für das Element, obwohl das Element weiterhin die ursprüngliche OID verwendet. Dies kann zu Inkompatibilitätsproblemen führen.
Es gibt Situationen, in denen Schema-Elemente geändert werden sollten. Beispielsweise müssen Sie neue Schema-Elemente erweitern oder ändern, wenn Sie sie während der Entwicklung verfeinern. Anstatt neue Attribute direkt zu einer Klasse hinzuzufügen, sollten Sie im Allgemeinen Zusatzklassen nur in folgenden Fällen verwenden:
Neue Attribute zu einer vorhandenen Objektklasse hinzufügen.
Für eine vorhandene Objektklasse eine Unterklasse erstellen.
Die folgende LDIF-Beispieldatei erstellt zwei neue Attribute und eine Zusatzklasse mit diesen neuen Attributen. Sie fügt dann einen inetOrgPerson-Eintrag mit der Objektklasse auxiliary und mit Werten für das Zusatzklassenattribut auxiliary hinzu.
version: 1 # Add an attribute to track a bear’s hair. The attribute is # multi-valued, uses a case ignore string syntax, # and has public read rights # Values may include: long hair, short, curly, straight, # none, black, and brown # X-NDS_PUBLIC_READ ’1’ The 1 allows public read, # 0 denies public read dn: cn=schema changetype: modify add: attributeTypes attributeTypes: ( 2.16.840.1.113719.1.186.4.10 NAME ’bearHair’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-NDS_PUBLIC_READ ’1’ ) # add an attribute to store a bear’s picture dn: cn=schema changetype: modify add: attributeTypes attributeTypes: ( 2.16.840.1.113719.1.186.4.11 NAME ’bearPicture’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 SINGLE-VALUE ) # create an Auxiliary class for the bearfeatures dn: cn=schema changetype: modify add: objectclasses objectclasses: (2.16.840.1.113719.1.186.6.101 NAME ’bearFeatures’ MAY (bearHair $ bearPicture) AUXILIARY) # now create a user named bobby dn: cn=bobby,o=bearcave changetype: add cn: bobby sn: bear givenName: bobby bearHair: Short bearHair: Brown bearHair: Curly bearPicture:< file:///c:/tmp/alien.jpg objectClass: top objectClass: person objectClass: inetOrgPerson objectClass: bearFeatures # now create a person named john that will later be changed # into a bear when bearFeatures is added to its objectClass # list dn: cn=john,o=bearcave changetype: add cn: John sn: bear givenName: john objectClass: top objectClass: person objectClass: inetOrgPerson # now morph john into a bear by adding bearFeatures dn: cn=john,o=bearcave changetype: modify add: objectClass objectClass: bearFeatures - add: bearHair bearHair: long bearHair: black #bearPicture:< file:///c:/tmp/john.jpg> - # to morph john back to a person, simply delete the # objectClass bearFeatures dn: cn=john,o=bearcave changetype: modify delete: objectClass objectClass: bearFeatures
Beim Entfernen von Zusatzklassen ist es nicht erforderlich, alle mit der Klasse auxiliary verknüpften Werte zu löschen, wenn Sie die Klasse auxiliary aus der Objektklassenliste entfernen. eDirectory führt dies automatisch aus.
Wenn die Klasse auxiliary über Attribute der Kategorie MUST verfügte, müssen diese Attribute alle im gleichen Änderungsvorgang angegeben werden, mit dem die Klasse auxiliary zur Objektklassenliste hinzugefügt wird. Andernfalls tritt ein Fehler bei der Änderung auf.
Die XML-Verarbeitung eines LDIF-Datensatzes (LDIF-Format oder vom LDAP-Server generierte Datensätze) kann nur erfolgreich ausgeführt werden, wenn alle einzelnen Datensätze alle in der XML-Datei angegebenen XML-Regeln erfüllen.