L'utilitaire d'importation/de conversion/d'exportation Novell permet d'importer facilement des fichiers LDIF dans eDirectory et d'exporter des fichiers LDIF depuis eDirectory. Pour plus d'informations, reportez-vous à Utilitaire d'importation/de conversion/d'exportation Novell.
Pour qu'une importation LDIF se déroule convenablement, vous devez commencer avec un fichier LDIF que l'utilitaire d'importation/de conversion/d'exportation Novell peut lire et traiter. Cette section décrit le format et la syntaxe des fichiers LDIF, et propose des exemples de fichiers LDIF corrects.
LDIF est un format de fichier très répandu qui décrit des informations de répertoire ou des opérations de modification pouvant être réalisées sur un répertoire. LDIF est totalement indépendant du format de stockage utilisé au sein d'une implémentation de répertoire spécifique, et est typiquement utilisé pour exporter des informations de répertoire depuis des serveurs LDAP et pour importer des données vers des serveurs LDAP.
D'une façon générale, la génération de LDIF est simple. Elle vous permet d'utiliser des outils, tels que awk ou perl, pour déplacer des données d'un format propriétaire dans un répertoire LDAP. Vous pouvez également écrire des scripts permettant de générer des données de test au format LDIF.
L'utilitaire d'importation/de conversion/d'exportation Novell nécessite des fichiers formatés LDIF 1.Vous trouverez ci-après les règles de base relatives à un fichier LDIF 1 :
Un enregistrement de contenu LDIF représente le contenu de l'ensemble d'une entrée. L'exemple de fichier LDIF ci-après comprend quatre enregistrements de contenu :
1 version: 1
2 dn: c=États-Unis
3 objectClass: top
4 objectClass: country
5
6 dn: l=San Francisco, c=États-Unis
7 objectClass: top
8 objectClass: locality
9 st: San Francisco
10
11 dn: ou=Artistes, l=San Francisco, c=États-Unis
12 objectClass: top
13 objectClass: organizationalUnit
14 telephoneNumber: +1 415 555 0000
15
16 dn: cn=Peter Michaels, ou=Artists, l=San Francisco, c=États-Unis
17 sn: Michaels
18 givenname: Peter
19 objectClass: top
20 objectClass: person
21 objectClass: organizationalPerson
22 objectClass: iNetOrgPerson
23 telephonenumber: +1 415 555 0001
24 mail: Peter.Michaels@aaa.com
25 userpassword: Peter123
26
Ce fichier LDIF comprend les parties suivantes :
Tableau 135. Composants du fichier LDIF
Les enregistrements de changement LDIF comportent les modifications à apporter à un répertoire. Toutes les opérations de mise à jour LDAP (add, delete, modify et modify DN) peuvent être représentées dans un enregistrement de changement LDIF.
Les enregistrements de changement LDIF utilisent pour le spécificateur de nom distinctif, le spécificateur de valeur d'attribut et le séparateur d'enregistrement le même format que les enregistrements de contenu LDIF. (Pour plus d'informations, reportez-vous à Enregistrements de contenu LDIF.) La présence d'un champ changetype est ce qui différencie un enregistrement de changement LDIF d'un enregistrement de contenu LDIF. Le champ changetype identifie l'opération spécifiée par l'enregistrement de changement.
Le champ changetype peut revêtir l'une des cinq formes suivantes :
Tableau 136. Formes du champ changetype
Un enregistrement de changement de type add se présente comme un enregistrement de changement de contenu (reportez-vous à Enregistrements de contenu LDIF), à ceci près que le champ changetype: add est ajouté immédiatement avant tout champ de valeur d'attribut.
Tous les enregistrements doivent être de même type. Vous ne pouvez pas mélanger des enregistrements de contenu et des enregistrements de changement.
1 version: 1
2 dn: c=États-Unis
3 changetype: add
4 objectClass: top
5 objectClass: country
6
7 dn: l=San Francisco, c=États-Unis
8 changetype: add
9 objectClass: top
10 objectClass: locality
11 st: San Francisco
12
14 dn: ou=Artistes, l=San Francisco, c=États-Unis
15 changetype: add
16 objectClass: top
17 objectClass: organizationalUnit
18 telephoneNumber: +1 415 555 0000
19
20 dn: cn=Peter Michaels, ou=Artistes, l=San Francisco, c=États-Unis
21 changetype: add
22 sn: Michaels
23 givenname: Peter
24 objectClass: top
25 objectClass: person
26 objectClass: organizationalPerson
27 objectClass: iNetOrgPerson
28 telephonenumber: +1 415 555 0001
29 mail: Peter.Michaels@aaa.com
30 userpassword: Peter123
31
Étant donné qu'un enregistrement de changement de type delete indique la suppression d'une entrée, les seuls champs nécessaires à ce type d'enregistrement sont le spécificateur de nom distinctif et le changement de type delete.
L'exemple de fichier LDIF suivant est utilisé pour supprimer les quatre entrées créées par le fichier LDIF présenté dans Changement de type add.
IMPORTANT : Pour supprimer des entrées précédemment ajoutées, inversez l'ordre des entrées. Si vous n'effectuez pas cette opération, l'opération de suppression échoue, étant donné que les entrées de conteneur ne seront pas vides.
1 version: 1
2 dn: cn=Peter Michaels, ou=Artistes, l=San Francisco, c=États-Unis
3 changetype: delete
4
5 dn: ou=Artistes, l=San Francisco, c=États-Unis
8 changetype: delete
9
10 dn: l=San Francisco, c=États-Unis
11 changetype: delete
12
13 dn: c=États-Unis
14 changetype: delete
15
Le changement de type modify permet de spécifier l'ajout, la suppression et le remplacement de valeurs d'attribut pour une entrée déjà existante. Les modifications revêtent l'une des trois formes suivantes :
Tableau 137. Éléments du spécificateur de modification
L'exemple suivant illustre un changement de type modification qui permet d'ajouter un numéro de téléphone supplémentaire à l'entrée cn=Peter Michaels.
1 version: 1
2 dn: cn=Peter Michaels, ou=Artistes, l=San Francisco, c=États-Unis
3 changetype: modify
4 # Ajouter le numéro de téléphone à cn=Peter Michaels
4 add: telephonenumber
5 telephonenumber: +1 415 555 0002
6
De même que vous pouvez combiner un mélange de modifications dans une requête de modification LDAP unique, vous pouvez spécifier plusieurs modifications dans un enregistrement LDIF unique. Une ligne contenant uniquement le caractère tiret (-) est utilisée pour marquer la fin des indications de valeur d'attribut pour chaque spécificateur de modification.
Le fichier LDIF exemple suivant comprend un mélange de modifications :
1 version: 1
2
3 # Ligne vide indiquant qu'un ou plusieurs
4 # séparateurs de ligne entre l'identificateur de version
5 # et le premier enregistrement sont autorisés.
6
7 dn: cn=Peter Michaels, ou=Artistes, l=San Francisco, c=États-Unis
8 changetype: modify
9 # Ajouter une valeur de numéro de téléphone.
10 add: telephonenumber
11 telephonenumber: +1 415 555 0002
12 -
13 # Supprimer l'intégralité de l'attribut fascimiletelephonenumber.
14 delete: facsimileTelephoneNumber
15 -
16 # Remplacer la description existante (le cas échéant)
17 # par deux nouvelles valeurs.
18 replace: description
19 description: guitariste
20 description: soliste
21 -
22 # Supprimer une valeur spécifique de l'attribut du numéro de
23 # téléphone.
24 delete: telephonenumber
25 telephonenumber: +1 415 555 0001
26 -
27 # Remplacer l'attribut title existant par un
28 # ensemble de valeurs vides,
29 # supprimant l'attribut title.
30 replace: title
31 -
32
Le changement de type modify DN permet de renommer une entrée, de la déplacer, ou d'effectuer les deux opérations. Ce type de changement se compose de deux champs obligatoires et d'un champ facultatif.
Tableau 138. Champs Changement de type modify DN
L'exemple suivant illustre un changement de type modify DN indiquant comment renommer une entrée :
1 version: 1
2
3 # Renommer ou=Artistes en ou=Artistes côte ouest et conserver
4 # l'ancienne valeur RDN.
5 dn: ou=Artistes,l=San Francisco,c=États-Unis
6 changetype: moddn
7 newrdn: ou=Artistes côte ouest
8 deleteoldrdn: 1
9
L'exemple suivant illustre un changement de type modify DN indiquant comment déplacer une entrée :
1 version: 1
2
3 # Déplacer cn=Peter Michaels depuis
4 # ou=Artistes,l=San Francisco,c=États-Unis vers
5 # ou=Promotion,l=New York,c=États-Unis et supprimer l'ancienne valeur RDN.
5 dn: cn=Peter Michaels,ou=Artistes,l=San Francisco,c=États-Unis
6 changetype: moddn
7 newrdn: cn=Peter Michaels
8 deleteoldrdn: 1
9 newsuperior: ou=Promotion,l=New York,c=États-Unis
10
L'exemple suivant illustre un changement de type modify DN indiquant comment déplacer une entrée et la renommer en même temps :
1 version: 1
2
3 # Déplacer ou=Promotion depuis l=New York,c=États-Unis vers
4 # l=San Francisco,c=États-Unis et le renommer en
5 # ou=Promotion nationale.
5 dn: ou=Promotion,l=New York,c=États-Unis
6 changetype: moddn
7 newrdn: ou=Promotion nationale
8 deleteoldrdn: 1
9 newsuperior: l=San Francisco,c=États-Unis
10
IMPORTANT : L'opération de modification RDN de LDAP 2 ne prend pas en charge le déplacement des entrées. Si vous tentez de déplacer une entrée en utilisant la syntaxe LDIF newsuperior avec un client LDAP 2, la requête échoue.
Pour retourner à la ligne dans un fichier LDIF, il suffit d'insérer un séparateur de ligne (saut de ligne ou paire retour chariot/saut de ligne) suivi d'un espace à l'emplacement auquel vous souhaitez retourner à la ligne. Lorsque l'analyseur syntaxique LDIF rencontre un espace en début de ligne, il sait concaténer le reste des données de la ligne avec les données de la ligne précédente. Il supprime alors l'espace en tête.
Vous ne devez pas retourner à la ligne au milieu d'un caractère multi-octets UTF-8.
L'exemple de fichier LDIF suivant illustre une ligne avec retour à la ligne (voir lignes 13 et 14) :
1 version: 1
2 dn: cn=Peter Michaels, ou=Artistes, l=San Francisco, c=États-Unis
3 sn: Michaels
4 givenname: Peter
5 objectClass: top
6 objectClass: person
7 objectClass: organizationalPerson
8 objectClass: iNetOrgPerson
9 telephonenumber: +1 415 555 0001
10 mail: Peter.Michaels@aaa.com
11 userpassword: Peter123
12 description: Peter est un des musiciens les plus populaires
13 utilisant notre label. Il aime beaucoup la scène
14 et ses fans l'adorent.
15
Si vous rencontrez des problèmes avec un fichier LDIF, tenez compte des points suivants :
Il peut arriver de rencontrer des fichiers LDIF dans lesquels un enregistrement permettant d'ajouter une entrée se trouve avant l'enregistrement permettant d'ajouter ses parents. Le cas échéant, une erreur est générée car le parent de la nouvelle entrée n'existe pas au moment où le serveur LDAP tente d'ajouter l'entrée.
Pour résoudre ce problème, il suffit d'activer l'utilisation de références en aval. Lorsque vous activez la création de références en aval et qu'une entrée va être créée alors que son parent n'existe pas encore, une marque de réservation appelée référence en aval est créée pour le parent de l'entrée afin de permettre la création de l'entrée. Si une opération ultérieure crée le parent, la référence en aval se transforme alors en entrée normale.
Il est possible qu'il reste une ou plusieurs références en aval une fois l'importation LDIF terminée (si le fichier LDIF n'a par exemple jamais créé de parent pour cette entrée). Le cas échéant, la référence en aval apparaît en tant qu'objet Inconnu dans ConsoleOneTM. Vous pouvez certes effectuer une recherche sur une entrée de référence en aval, mais vous ne pouvez pas lire les attributs (à l'exception de l'attribut objectClass) depuis l'entrée de référence en aval car elle n'est associée à aucun attribut et à aucune valeur d'attribut. Cependant, toutes les opérations LDAP fonctionnent normalement sur les entrées d'objet situées sous la référence en aval.
Les entrées de référence en aval sont associées à une classe d'objet Inconnu et ont également un indicateur d'entrée EF_REFERENCE NDS interne. Sous ConsoleOne, les entrées associées à une classe d'objet Inconnu sont représentées par une icône jaune circulaire au centre de laquelle se trouve un point d'interrogation. Vous pouvez utiliser LDAP pour rechercher des objets dont la classe d'objet est Inconnu, bien qu'il n'existe actuellement aucun moyen d'accéder via LDAP aux paramètres de l'indicateur pour vérifier qu'il s'agit bien d'entrées de référence en aval.
Vous pouvez changer une entrée de référence en aval en un objet normal en créant ce dernier (à l'aide, par exemple, d'un fichier LDIF ou d'une requête client LDAP). Lorsque vous demandez à eDirectory de créer une entrée existant déjà en tant que référence en aval, le eDirectory transforme l'entrée de référence en aval existante en l'objet dont vous avez demandé la création.
Pour activer les références en aval lors d'une importation LDIF :
Sous ConsoleOne, sélectionnez Assistant > Importation/Exportation NDS.
Cliquez sur Importer le fichier LDIF > Suivant.
Entrez le nom du fichier LDIF qui contient les données à importer, puis cliquez sur Suivant.
Sélectionnez le serveur LDAP vers lequel importer les données.
Cliquez sur Avancé > Autoriser les références en aval > Fermer.
Cliquez sur Suivant > Terminer pour lancer l'importation LDIF.
Pour activer les références en aval lors d'une migration de données entre serveurs :
Sous ConsoleOne, sélectionnez Assistant > Importation/Exportation NDS.
Cliquez sur Migrer les données entre les serveurs LDAP > Suivant.
Sélectionnez le serveur LDAP contenant les entrées que vous souhaitez migrer, puis cliquez sur Suivant.
Indiquez les critères de recherche correspondant aux entrées à migrer, puis cliquez sur Suivant.
Sélectionnez le serveur LDAP vers lequel migrer les données.
Cliquez sur Avancé > Autoriser les références en aval > Fermer.
Cliquez sur Suivant > Terminer.
Pour activer les références en aval dans l'interface de ligne de commande, utilisez l'option -F du gestionnaire cible LDAP.
Pour plus d'informations, reportez-vous à Options du gestionnaire cible LDIF.
Vous pouvez vérifier la syntaxe d'un fichier LDIF avant de traiter les enregistrements qu'il contient en utilisant l'option du gestionnaire source LDIF Afficher les opérations sans les exécuter.
Le gestionnaire source LDIF vérifie systématiquement la syntaxe des enregistrements d'un fichier LDIF lorsqu'il les traite. Utilisez cette option pour désactiver le traitement des enregistrements et vérifier la syntaxe.
Pour vérifier la syntaxe lors d'une importation LDIF :
Sous ConsoleOne, sélectionnez Assistant > Importation/Exportation NDS.
Cliquez sur Importer le fichier LDIF > Suivant.
Entrez le nom du fichier LDIF qui contient les données à importer, puis cliquez sur Avancé.
Cliquez sur Afficher les opérations sans les exécuter > Fermer > Suivant.
Sélectionnez le serveur LDAP vers lequel importer les données.
Cliquez sur Suivant > Terminer pour lancer l'importation LDIF.
Pour vérifier la syntaxe d'un fichier LDIF dans l'interface de ligne de commande, utilisez l'option -n du gestionnaire source LDIF.
Pour plus d'informations, reportez-vous à Options du gestionnaire source LDIF.
L'utilitaire d'importation/de conversion/d'exportation Novell crée automatiquement un fichier LDIF qui recense tous les enregistrements dont le traitement par le gestionnaire cible a échoué. Vous pouvez éditer le fichier d'erreurs LDIF généré par l'utilitaire, corriger les erreurs et le ré-appliquer au serveur pour terminer une importation ou une migration de données contenant des enregistrements erronés.
Sous ConsoleOne, sélectionnez Assistant > Importation/Exportation NDS.
Cliquez sur la tâche que vous souhaitez exécuter.
Cliquez sur Avancé.
Dans le champ Fichier journal, indiquez le nom du fichier dans lequel les messages de sortie (y compris les messages d'erreur) seront consignés.
Dans le champ Fichier cible LDIF pour les enregistrements non valides, indiquez le nom du fichier dans lequel les entrées qui échouent apparaissent au format LDIF.
Ce fichier peut permettre d'examiner ou de corriger des erreurs. Vous pouvez également ré-appliquer une version modifiée (corrigée) de ce fichier au répertoire.
Cliquez sur Fermer.
Suivez les instructions en ligne pour terminer la tâche sélectionnée.
Utilisez l'option générale -l pour configurer des options de journal d'erreurs dans l'interface de ligne de commande.
Pour plus d'informations, reportez-vous à Options générales.
Pour comprendre certains problèmes LDIF, vous devez connaître le fonctionnement du client LDAP SDK. Vous pouvez définir les indicateurs de débogage suivants pour le gestionnaire source LDAP, le gestionnaire cible LDAP, ou les deux.
Tableau 139. Indicateurs de débogage SDK LDAP
Pour activer cette fonction, utilisez l'option -e pour les gestionnaires source et cible LDAP. La valeur de l'entier correspondant à l'option -e est un masque binaire qui active différents types d'informations de débogage dans le SDK LDAP.
Pour plus de précisions, reportez-vous à Options du gestionnaire source LDAP et Options du gestionnaire cible LDAP.
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 qui correspond à la spécification de NDSObjectClassDescription sur 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 Personne au schéma :
1 version: 1
2 dn: cn=schéma
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 répertorié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.
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 Personne peut être endiguée par les classes d'objet Organisation, Unité organisationnelle et 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=schéma
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. L'exemple de fichier LDIF suivant rend l'attribut à valeur unique en ajoutant le mot-clé SINGLE-VALUE à la suite de la section SYNTAX :
1 version: 1
2 dn: cn=schéma
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 directement de nouveaux attributs à une classe, vous utilisez généralement uniquement des classes auxiliaires pour :
Le fichier exemple LDIF suivant crée deux nouveaux attributs et crée une classe auxiliaire avec ces nouveaux attributs. Il ajoute ensuite une entrée inetOrgPerson comportant la classe auxiliaire définie en tant que classe d'objet de l'entrée et des valeurs pour les attributs de la classe auxiliaire.
version: 1
# Ajoute un attribut pour rechercher les poils d'un ours. Cet attribut est
# à valeurs multiples, utilise une syntaxe Chaîne sans distinction de la casse
# et possède des droits de Lire (Public)
# Ses valeurs peuvent inclure : longs, courts, bouclés, raides,
# aucun, noirs et bruns
# X-NDS_PUBLIC_READ '1' 1 pour octroyer les droits de Lire (Public),
# 0 pour les refuser
dn: cn=schéma
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' )
# ajoute un attribut pour stocker l'image d'un ours
dn: cn=schéma
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 )
# crée une classe auxiliaire pour les caractéristiques de l'ours
dn: cn=schéma
changetype: modify
add: objectclasses
objectclasses: (2.16.840.1.113719.1.186.6.101 NAME
'bearFeatures' MAY (bearHair $ bearPicture) AUXILIARY)
# crée à présent un utilisateur appelé booboo
dn: cn=booboo,o=jellystone
changetype: add
cn: booboo
sn: bear
givenName: booboo
bearHair: Short
bearHair: Brown
bearHair: Curly
bearPicture:< file:///c:/tmp/alien.jpg
objectClass: top
objectClass: person
objectClass: inetOrgPerson
objectClass: bearFeatures
# crée maintenant une personne nommée yogi qui sera ensuite changée
# en bear lorsque bearFeatures sera ajouté à son objectClass
# liste
dn: cn=yogi,o=jellystone
changetype: add
cn: yogi
sn: bear
givenName: yogi
objectClass: top
objectClass: person
objectClass: inetOrgPerson
# transforme yogi en ours en ajoutant bearFeatures
dn: cn=yogi,o=jellystone
changetype: modify
add: objectClass
objectClass: bearFeatures
-
add: bearHair
bearHair: long
bearHair: black
#bearPicture:< file:///c:/tmp/yogi.jpg>
-
# pour retransformer yogi en une personne, il suffit de supprimer
# objectClass bearFeatures
dn: cn=yogi,o=jellystone
changetype: modify
delete: objectClass
objectClass: bearFeatures
Il n'est pas nécessaire de supprimer toutes les valeurs associées à la classe auxiliaire lorsque vous supprimez cette classe de la liste objectClass. eDirectory le fait automatiquement.
Si la classe auxiliaire comporte des attributs MUST, ils doivent tous être spécifiés dans la même opération modify qui ajoute la classe auxiliaire dans la liste objectClass, faute de quoi la modification échouera.