L'utilitaire d'importation/de conversion/d'exportation Novell permet d'importer et d'exporter facilement des fichiers LDIF dans eDirectory ou à partir de ce dernier. Pour plus d'informations, reportez-vous à Utilitaire Importation/Conversion/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 d'annuaire ou des opérations de modification pouvant être réalisées sur un annuaire. LDIF est totalement indépendant du format de stockage utilisé dans le cadre d'une mise en oeuvre d'annuaire spécifique. Il sert généralement à exporter des informations d'annuaire à partir de serveurs LDAP et à 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 annuaire 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 requiert des fichiers au format LDIF 1. Voici les règles de base applicables à 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=Artistes, 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 . Composants d'un 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 . 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 ), à cette différence près que 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 combiner 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 sert à 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, la 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 existante. Les modifications revêtent l'une des trois formes suivantes :
Tableau . Éléments du spécificateur de modification
L'exemple suivant illustre un changement de type modify 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 (-) sert à marquer la fin des indications de valeur d'attribut pour chaque spécificateur de modification.
Le fichier LDIF exemple suivant comprend une combinaison 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 . Champs de changement de type modify DN
L'exemple suivant illustre un changement de type modify DN qui montre 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 qui montre 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 qui montre 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 détecte un espace en début de ligne, il concatène 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
En cas de problème avec un fichier LDIF, tenez compte des points suivants :
Il peut exister des fichiers LDIF dans lesquels un enregistrement permettant d'ajouter une entrée se trouve avant l'enregistrement permettant d'ajouter ses parents. Dans ce cas, 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 des 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). Dans ce cas, la référence en aval apparaît en tant qu'objet Inconnu dans ConsoleOne. Vous pouvez 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 ni à 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 qui existe déjà en tant que référence en aval, il change 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, cliquez sur Assistant > Importation/Exportation NDS.
Cliquez sur Importer le fichier LDIF > Suivant.
Entrez le nom du fichier LDIF qui contient les données à importer et 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 activer les références en aval lors d'une migration de données entre serveurs :
Sous ConsoleOne, cliquez sur 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.
Sous ConsoleOne, cliquez sur Assistant > Importation/Exportation NDS.
Cliquez sur Importer le fichier LDIF > Suivant.
Entrez le nom du fichier LDIF qui contient les données à importer et 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 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, cliquez sur 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.
Vous pouvez utiliser ce fichier pour consulter ou corriger des erreurs. Vous pouvez également restaurer une version modifiée (corrigée) de ce fichier dans l'annuaire.
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 . 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 d'informations, 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=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 listé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'objets 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'objets 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=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. 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=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 directement de nouveaux attributs à une classe, vous utilisez généralement des classes auxiliaires uniquement pour :
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 la classe auxiliaire comme classe d'objet et fournit des valeurs pour les attributs de la classe auxiliaire.
version: 1
#Ajoute un attribut afin de rechercher le pelage d'un ours. Cet attribut est
# à valeurs multiples, emploie une syntaxe dans laquelle la casse est ignorée
# et possède des droits de lecture (Public)
# Ses valeurs peuvent être les suivantes : poil long, court, bouclé, raide,
# néant, noir et brun
# X-NDS_PUBLIC_READ '1' Le chiffre 1 autorise la lecture publique,
# 0 interdit la lecture publique
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' )
# ajoute un attribut pour stocker l'image d'un ours
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 )
# crée une classe auxiliaire pour les caractéristiques de l'ours
dn: cn=schema
changetype: modify
add: objectclasses
objectclasses: (2.16.840.1.113719.1.186.6.101 NAME
'bearFeatures' MAY (bearHair $ bearPicture) AUXILIARY)
# crée un utilisateur nommé 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
# crée maintenant une personne nommée john qui deviendra un
# ours lorsque bearFeatures sera ajoutée à son objectClass
# liste
dn: cn=john,o=bearcave
changetype: add
cn: John
sn: bear
givenName: john
objectClass: top
objectClass: person
objectClass: inetOrgPerson
# transforme john en ours en ajoutant bearFeatures
dn: cn=john,o=bearcave
changetype: modify
add: objectClass
objectClass: bearFeatures
-
add: bearHair
bearHair: long
bearHair: black
#bearPicture:< file:///c:/tmp/john.jpg>
-
# pour retransformer john en personne, il suffit de supprimer
# 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 s'en charge 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 les classes auxiliaires à la liste objectClass, faute de quoi la modification échouera.
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.