Dépannage des fichiers LDIF
L'utilitaire d'importation, de conversion et 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 d'importation, de conversion et 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 et 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.
Présentation de LDIF
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 sur 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.
Format de fichier LDIF
L'utilitaire d'importation, de conversion et d'exportation Novell requiert des fichiers au format LDIF 1. Voici les règles de base applicables à un fichier LDIF 1 :
- La première ligne (autre qu'un commentaire) doit correspondre à la version : 1.
- Une série d'un ou de plusieurs enregistrements suit la version.
- Chaque enregistrement se compose de champs (un champ par ligne).
- Les lignes sont séparées par un saut de ligne ou par une paire retour chariot/saut de ligne.
- Les enregistrements sont séparés par au moins une ligne vide.
- Il existe deux types d'enregistrements LDIF : les enregistrements de contenu et les enregistrements de changement. Un fichier LDIF peut comporter un nombre illimité d'enregistrements, mais ceux-ci doivent tous être du même type. Vous ne pouvez pas combiner des enregistrements de contenu et des enregistrements de changement dans le même fichier LDIF.
- Toute ligne commençant par le signe dièse (#) est un commentaire et est par conséquent ignorée lors du traitement du fichier LDIF.
Enregistrements de contenu LDIF
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 :
Spécificateur de version |
La première ligne d'un fichier LDIF comporte la version. Vous pouvez ajouter ou non des espaces entre les deux points et le numéro de version, dont la valeur actuelle est 1. Si la ligne de version est manquante, toute application traitant le fichier LDIF peut supposer que le fichier est de version 0. Il est aussi possible que le fichier LDIF soit rejeté comme étant syntaxiquement incorrect. Les utilitaires Novell traitant les fichiers LDIF considèrent qu'il s'agit d'une version de fichier 0 si la ligne de version est absente. |
Spécificateur de nom distinctif |
La première ligne de chaque enregistrement de contenu (lignes 2, 6, 11 et 16 dans l'exemple précédent) spécifie le nom distinctif de l'entrée qu'il représente. Le spécificateur de DN doit revêtir l'une des deux formes suivantes : - dn : nom_distinctif_UTF-8_protégé
- dn:: nom_distinctif_codé_Base64
|
Séparateurs de lignes |
Le séparateur de ligne peut être un saut de ligne ou une paire retour chariot/saut de ligne. Cela permet de résoudre une incompatibilité commune entre fichiers texte Linux et Solaris, qui utilisent un saut de ligne comme séparateur de ligne, et fichiers texte MS-DOS* et Windows, qui utilisent une paire retour chariot/saut de ligne comme séparateur de ligne. |
Séparateurs d'enregistrements |
Les lignes vierges (lignes 5, 10, 15 et 26 dans l'exemple précédent) sont utilisées comme séparateurs d'enregistrements. Chaque enregistrement d'un fichier LDIF, y compris le dernier, doit se terminer par un séparateur d'enregistrement (une ou plusieurs lignes vierges). Si certaines mises en oeuvre acceptent un fichier LDIF sans séparateur d'enregistrement final, ce dernier est impératif pour la spécification LDIF. |
Spécificateur de valeur d'attribut |
Toutes les autres lignes d'un enregistrement de contenu sont des spécificateurs de valeurs. Les spécificateurs de valeurs doivent revêtir l'une des trois formes suivantes : - Description de l'attribut : valeur
- Description de l'attribut : valeur_codée_Base64
- Description de l'attribut : < URL
|
Enregistrements de changement LDIF
Les enregistrements de changement LDIF comportent les modifications à apporter à un annuaire. Toutes les opérations de mise à jour LDAP (ajout, suppression, modification et modification du nom distinctif) 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 :
changetype: add |
Mot-clé indiquant que l'enregistrement de changement spécifie une opération LDAP d'ajout. |
changetype: delete |
Mot-clé indiquant que l'enregistrement de changement spécifie une opération LDAP de suppression. |
changetype: moddn |
Mot-clé indiquant que l'enregistrement de changement spécifie une opération LDAP de modification du DN si le processeur LDIF est lié au serveur LDAP en tant que client version 3 ou une opération de modification du RDN si le processeur LDIF est lié au serveur LDAP en tant que client version 2. |
changetype: modrdn |
Synonyme du type de changement moddn. |
changetype: modify |
Mot-clé indiquant que l'enregistrement de changement spécifie une opération LDAP de modification. |
Changement de type add
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
Changement de type delete
É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 sont 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
Changement de type modify
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 :
add: type d'attribut |
Mot-clé indiquant que les spécificateurs de valeur d'attribut suivants qui correspondent au type d'attribut doivent être ajoutés à l'entrée. |
delete: type d'attribut |
Mot-clé indiquant que les valeurs qui correspondent au type d'attribut doivent être supprimées. Si des spécificateurs de valeur d'attribut suivent le champ delete, les valeurs correspondantes sont supprimées. Si aucun spécificateur de valeur d'attribut ne suit le champ delete, toutes les valeurs sont supprimées. Si aucune valeur n'est associée à l'attribut, cette opération échoue, mais l'effet voulu est quand même obtenu, étant donné que l'attribut n'est associé à aucune valeur à supprimer. |
replace: type d'attribut |
Mot-clé indiquant que les valeurs qui correspondent au type d'attribut doivent être remplacées. Tous les spécificateurs de valeur d'attribut qui suivent le champ replace deviennent les nouvelles valeurs de ce type d'attribut. Si aucun spécificateur de valeur d'attribut ne suit le champ replace, le jeu de valeurs actuel est remplacé par un jeu de valeurs vide (ce qui entraîne le retrait de l'attribut). À la différence du spécificateur de modification delete, si aucune valeur n'est associée à l'attribut, le remplacement réussira tout de même. Au final, le résultat est le même dans les deux cas. |
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
Changement de type modify DN
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.
newrdn (obligatoire) |
Indique le nouveau nom de l'entrée qui sera assignée lors du traitement de cet enregistrement. Le spécificateur " new RDN " doit revêtir l'une des deux formes suivantes : - newrdn: nom_distinctif_relatif_UTF-8_protégé
- newrdn:: nom_distinctif_relatif_codé_Base64
Le spécificateur " new RDN " est obligatoire dans tous les enregistrements LDIF comportant un changement de type modify DN. |
deleteoldrdn (obligatoire) |
Le spécificateur " delete old RDN " indique si l'ancien RDN doit être remplacé par la valeur newrdn ou s'il doit être conservé. Il revêt l'une des deux formes suivantes : |
newsuperior (facultatif) |
Le spécificateur " new superior " indique le nom du nouveau parent qui sera assigné à l'entrée lors du traitement de l'enregistrement modify DN. Le spécificateur " new superior " doit revêtir l'une des deux formes suivantes : - newsuperior: nom_distinctif_UTF-8_protégé
- newsuperior:: nom_distinctif_codé_Base64
Le spécificateur " new superior " est facultatif dans les enregistrements LDIF qui comportent un changement de type modify DN. Il est uniquement indiqué si vous souhaitez modifier le niveau de répertoire de l'entrée. |
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.
Retour à la ligne dans les fichiers LDIF
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. Ses concerts font un tabac
14 et ses fans l'adorent.
15
Représentation des mots de passe codés dans les fichiers LDIF
Un mot de passe codé est représenté sous la forme de données au format base64 dans le fichier LDIF. Le nom d'attribut userpassword doit être suivi du nom du codage utilisé pour le hachage du mot de passe. Ce nom doit être précédé et suivi d'accolades "{ }", comme l'illustrent les exemples suivants :
Exemple 1
Pour les mots de passe codés SHA :
1 version: 1 2 dn: cn=Peter Michaels, ou=Artistes, l=San Francisco, c=États-Unis 3 sn: Michaels 4 userpassword: {SHA}xcbdh46ngh37jsd0naSFDedjAS30dm5 objectclass: inetOrgPerson
Exemple 2
Pour les mots de passe codés SSHA :
1 version: 1 2 dn: cn=Peter Michaels, ou=Artistes, l=San Francisco, c=États-Unis 3 sn: Michaels 4 userpassword: {SSHA}sGs948DFGkakdfkasdDF34DF4dS3skl5DFS5 objectclass: inetOrgPerson
Exemple 3
Pour les mots de passe codés Digest MD5 :
1 version: 1 2 dn: cn=Peter Michaels, ou=Artistes, l=San Francisco, c=États-Unis 3 sn: Michaels 4 userpassword: {MD5}a45lkSDF234SDFG62dsfsf2DG2QEvgdmnk4305 objectclass: inetOrgPerson
Débogage des fichiers LDIF
En cas de problème avec un fichier LDIF, tenez compte des points suivants :
Activation des références en aval
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 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 et iManager. 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.
Identification des entrées de 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. Dans ConsoleOne et iManager, les entrées associées à une classe d'objet Inconnu sont représentées par une icône jaune ronde 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 d'entrée pour vérifier qu'il s'agit bien d'entrées de référence en aval.
Changement des entrées de référence en aval en objets normaux
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 remplace l'entrée de référence en aval existante par l'objet dont vous avez demandé la création.
Utilisation de l'Assistant d'importation, de conversion et d'exportation Novell eDirectory
Pour activer les références en aval lors d'une importation LDIF :
-
Dans Novell iManager, cliquez sur le bouton Rôles et tâches 
.
-
Cliquez sur Maintenance de eDirectory > Assistant Importation/Conversion/Exportation.
-
Cliquez sur Importer les données depuis un fichier du disque, puis sur Suivant.
-
Sélectionnez LDIF comme type de fichier à importer.
-
Entrez le nom du fichier qui contient les données à importer, sélectionnez les options appropriées, puis cliquez sur Suivant.
-
Spécifiez le serveur LDAP dans lequel importer les données.
-
Ajoutez les options appropriées, décrites dans le tableau ci-dessous :
Nom DNS/Adresse IP du serveur |
Nom DNS ou adresse IP du serveur LDAP cible |
Port |
Numéro de port (nombre entier) du serveur LDAP cible |
Fichier DER |
Nom du fichier DER qui contient une clé de serveur utilisée pour l'authentification SSL |
Méthode de login |
Login authentifié ou login anonyme (pour l'entrée spécifiée dans le champ DN utilisateur) |
DN utilisateur |
Nom distinctif de l'entrée à utiliser lors de la liaison à l'opération de liaison définie sur le serveur |
Mot de passe |
Attribut de mot de passe de l'entrée spécifiée dans le champ DN utilisateur |
-
Dans Paramètres avancés, cliquez sur Autoriser les références en aval.
-
Cliquez sur Suivant puis sur Terminer.
Pour activer les références en aval lors d'une migration de données entre serveurs :
-
Dans Novell iManager, cliquez sur le bouton Rôles et tâches .
-
Cliquez sur Maintenance de eDirectory > Assistant Importation/Conversion/Exportation.
-
Cliquez sur Migrer les données entre les serveurs, puis sur Suivant.
-
Sélectionnez le serveur LDAP comportant les entrées à migrer.
-
Ajoutez les options appropriées, décrites dans le tableau ci-dessous :
Nom DNS/Adresse IP du serveur |
Nom DNS ou adresse IP du serveur LDAP source |
Port |
Numéro de port (nombre entier) du serveur LDAP source |
Fichier DER |
Nom du fichier DER qui contient une clé de serveur utilisée pour l'authentification SSL |
Méthode de login |
Login authentifié ou login anonyme (pour l'entrée spécifiée dans le champ DN utilisateur) |
DN utilisateur |
Nom distinctif de l'entrée à utiliser lors de la liaison à l'opération de liaison définie sur le serveur |
Mot de passe |
Attribut de mot de passe de l'entrée spécifiée dans le champ DN utilisateur |
-
Dans Paramètres avancés, cliquez sur Autoriser les références en aval.
-
Cliquez sur Suivant.
-
Spécifiez les critères de recherche (décrits ci-dessous) relatifs aux entrées à migrer :
DN de base |
Nom distinctif de base pour la requête de recherche Si vous ne renseignez pas ce champ, la valeur par défaut utilisée est " " (chaîne vide). |
Étendue |
Étendue de la requête de recherche |
Filtre |
Filtre de recherche conforme à la norme RFC 2254 La valeur par défaut est objectclass=*. |
Attributs |
Attributs qui doivent vous être renvoyés pour chaque entrée de la recherche |
-
Cliquez sur Suivant.
-
Spécifiez le serveur LDAP vers lequel les données doivent migrer.
-
Cliquez sur Suivant puis sur Terminer.
REMARQUE : vérifiez que le schéma est cohérent dans tous les services LDAP.
Utilisation de l'interface de ligne de commande de l'utilitaire d'importation, de conversion et d'exportation Novell
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.
Contrôle de la syntaxe des fichiers 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.
Utilisation de l'Assistant d'importation, de conversion et d'exportation Novell eDirectory
-
Dans Novell iManager, cliquez sur le bouton Rôles et tâches .
-
Cliquez sur Maintenance de eDirectory > Assistant Importation/Conversion/Exportation.
-
Cliquez sur Importer les données depuis un fichier du disque, puis sur Suivant.
-
Sélectionnez LDIF comme type de fichier à importer.
-
Entrez le nom du fichier qui contient les données à importer et sélectionnez les options appropriées.
-
Dans Paramètres avancés, cliquez sur Afficher les opérations sans les exécuter, puis sur Suivant.
-
Spécifiez le serveur LDAP dans lequel importer les données.
-
Ajoutez les options appropriées, décrites dans le tableau ci-dessous :
Nom DNS/Adresse IP du serveur |
Nom DNS ou adresse IP du serveur LDAP cible |
Port |
Numéro de port (nombre entier) du serveur LDAP cible |
Fichier DER |
Nom du fichier DER qui contient une clé de serveur utilisée pour l'authentification SSL |
Méthode de login |
Login authentifié ou login anonyme (pour l'entrée spécifiée dans le champ DN utilisateur) |
DN utilisateur |
Nom distinctif de l'entrée à utiliser lors de la liaison à l'opération de liaison définie sur le serveur |
Mot de passe |
Attribut de mot de passe de l'entrée spécifiée dans le champ DN utilisateur |
-
Cliquez sur Suivant puis sur Terminer.
Utilisation de l'interface de ligne de commande de l'utilitaire d'importation, de conversion et d'exportation Novell
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.
Utilisation du fichier d'erreurs LDIF
L'utilitaire d'importation, de conversion et 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 l'appliquer à nouveau au serveur pour terminer une importation ou une migration de données contenant des enregistrements erronés.
Utilisation de l'Assistant d'importation/d'exportation Novell eDirectory
Cette caractéristique est disponible uniquement dans ConsoleOne.
-
Dans 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 d'un 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.
Utilisation de l'interface de ligne de commande de l'utilitaire d'importation, de conversion et d'exportation Novell
Utilisez l'option générale -l pour configurer des options de journal d'erreurs dans l'utilitaire de ligne de commande.
Pour plus d'informations, reportez-vous à Options générales.
Utilisation des indicateurs de débogage SDK LDAP
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.
0x0001 |
Effectue le suivi des appels de fonction LDAP. |
0x0002 |
Imprime des informations sur les paquets. |
0x0004 |
Imprime des informations sur les paquets. |
0x0008 |
Imprime des informations sur les connexions. |
0x0010 |
Imprime des informations sur le codage et le décodage BER. |
0x0020 |
Imprime des informations sur les filtres de recherche. |
0x0040 |
Imprime des informations sur la configuration. |
0x0080 |
Imprime des informations sur l'ACL. |
0x0100 |
Imprime des informations sur les statistiques. |
0x0200 |
Imprime des informations supplémentaires sur les statistiques. |
0x0400 |
Imprime des informations sur le shell. |
0x0800 |
Imprime des informations sur les l'analyse syntaxique. |
0xFFFF (-1 Decimal) |
Active toutes les options de débogage. |
Pour activer cette fonction, utilisez l'option -e pour les gestionnaires source et cible LDAP. Le nombre 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.
Utilisation de LDIF pour étendre le schéma
LDIF pouvant représenter des opérations de mise à jour LDAP, vous pouvez l'utiliser pour modifier le schéma.
Ajout d'une nouvelle classe d'objet
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
Attributs obligatoires
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.
Attributs facultatifs
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.
REMARQUE : l'attribut userPassword ne peut pas être utilisé comme attribut facultatif (MAY). Vous obtenez un échec si vous essayez de l'utiliser comme attribut obligatoire (MUST) dans la nouvelle classe d'objet en utilisant ce format LDIF pour étendre le schéma.
Règles d'endiguement
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.
Ajout d'un nouvel attribut
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
Valeur unique et valeurs multiples
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
Ajout d'un attribut facultatif à une classe d'objet existante
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
Ajout ou suppression de classes auxiliaires
L'exemple de fichier LDIF suivant crée deux nouveaux attributs, crée une classe auxiliaire avec ces attributs et ajoute une entrée inetOrgPerson dont la classe auxiliaire est une classe d'objet et qui possède 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.
Problèmes connus lors de l'analyse XML
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.