LDIF pouvant représenter des opérations de mise à jour LDAP, vous pouvez l'utiliser pour modifier le schéma.
Pour ajouter une classe, il suffit d'ajouter une valeur d'attribut correspondant à la spécification de NDSObjectClassDescription à l'attribut objectClasses de subschemaSubentry.
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 ")"
L'exemple de fichier LDIF suivant ajoute la classe d'objet person (personne) au schéma :
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
Les attributs obligatoires sont listés dans la section MUST de la description de la classe d'objet. Pour la classe d'objet Personne, les attributs obligatoires sont cn et sn.
Les attributs facultatifs sont répertoriés dans la section MAY de la description de la classe d'objet. Les attributs facultatifs de la classe d'objet Personne sont : description, seeAlso, telephoneNumber, fullName, givenName, initials, uid et userPassword.
REMARQUE :l'attribut userPassword ne peut pas être utilisé comme attribut facultatif (MAY). Si vous essayez de l'employer comme attribut obligatoire (MUST) dans la nouvelle classe d'objet en utilisant ce format LDIF pour étendre le schéma, l'opération échoue.
Les classes d'objet qui peuvent contenir la classe d'objet définie sont indiquées dans la section X-NDS_CONTAINMENT de la description de la classe d'objet. La classe d'objet person peut être contenue dans les classes d'objets organization (organisation), organizationalUnit (unité organisationnelle) et domain (domaine).
Pour ajouter un attribut, il suffit d'ajouter une valeur d'attribut qui correspond à la spécification de NDSAttributeTypeDescription sur l'attribut attributes de subschemaSubentry.
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 ")"
L'exemple de fichier LDIF suivant ajoute le type d'attribut title au schéma :
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
Par défaut, un attribut est à valeurs multiples sauf s'il est explicitement défini comme étant à valeur unique. Dans l'exemple de fichier LDIF suivant, title est un attribut à valeur unique, car le mot-clé SINGLE-VALUE est ajouté à la suite de la section SYNTAX :
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
Bien que l'ajout de nouveaux éléments de schéma soit une pratique courante, la modification ou l'extension d'éléments de schéma existants est généralement une opération dangereuse. Étant donné que chaque élément de schéma est identifié de façon unique par un OID, lors d'une extension d'un élément de schéma standard, vous créez en fait une seconde définition pour l'élément, bien que celui-ci utilise toujours l'OID d'origine. Ceci peut engendrer des problèmes d'incompatibilité.
Il est parfois approprié de modifier des éléments du schéma. Vous pouvez par exemple avoir besoin d'étendre ou de modifier de nouveaux éléments de schéma à mesure que vous les définissez au cours du développement. Plutôt que d'ajouter de nouveaux attributs à une classe, vous devriez utiliser généralement des classes auxiliaires uniquement pour effectuer les opérations suivantes :
Ajouter de nouveaux attributs à une classe d'objet existante.
Diviser une classe d'objet existante en sous‑classes.
L'exemple de fichier LDIF suivant crée deux nouveaux attributs, une classe auxiliaire à partir de ceux-ci, puis ajoute une entrée inetOrgPerson ayant comme classe d'objet la classe auxiliaire et fournit des valeurs pour les attributs de la classe auxiliaire.
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
Lorsque vous supprimez une classe auxiliaire de la liste objectClass, il n'est pas nécessaire de supprimer toutes les valeurs qui y sont associées. eDirectory effectue cette opération automatiquement.
Si la classe auxiliaire possédait des attributs MUST, ils doivent tous être spécifiés dans l'opération de modification qui ajoute la classe auxiliaire à la liste objectClass. Dans le cas contraire, la modification échoue.
Le traitement XML de tout enregistrement LDIF (format LDIF ou enregistrements générés à partir du serveur LDAP) échoue si des enregistrements ne satisfont pas à toutes les règles XML définies dans le fichier XML.