Ce chapitre contient d'importantes informations, propres au produit, disponibles à la sortie de Directory Proxy Server.
Ce chapitre comprend les sections suivantes :
Cette section répertorie les bogues corrigés dans Directory Proxy Server version 6.3.1.
Si une source JDBC n'est pas disponible, la recherche échoue lorsque vous utilisez une vue de type JOIN (LDAP + JDBC), même si le système ne requiert aucune donnée provenant de cette source JDBC.
L'exécution de ldapsearch sur cn=monitor renvoie l'entrée de nœud terminal avant l'entrée parent, condition qui peut provoquer l'échec de certains outils.
Les modifications apportées via une vue de jointure de LDAP et JDBC peuvent déclencher une exception de pointeur NULL.
Si aucun attribut secondaire n'est nécessaire, les requêtes portant sur des sources de données secondaires ne doivent avoir aucun impact sur les performances.
Les tentatives d'application de deux modifications dans le cadre d'une même transaction LDAP peuvent n'avoir qu'un succès partiel si un attribut est absent.
Lorsque vous utilisez une vue de jointure de LDAP et JDBC, l'attribut objectclass ne peut pas être stocké dans la vue secondaire.
Lorsque vous effectuez une recherche via une vue de jointure, cette recherche doit être menée en premier sur la vue secondaire, dans le cas où aucun attribut issu de la vue principale ne figure dans le filtre de recherche (et ce, même si plusieurs entrées sont renvoyées depuis la vue secondaire).
Une charge de recherche trop élevée peut provoquer une exception de pointeur NULL.
Lors d'une recherche avec une vue de jointure de LDAP et JDBC, il est impossible de renvoyer une entrée si l'utilisateur de liaison n'a pas de droit d'accès sur les attributs secondaires requis.
Une recherche à forte charge peut déclencher des exceptions ArrayIndexOutOfBounds ou NegativeArraySizeException
L'ajout d'une entrée via une vue de jointure échoue si l'attribut uid contient des majuscules.
Lorsque vous ajoutez une entrée via une vue de jointure de LDAP et JDBC, cette entrée est ajoutée à la vue JDBC même si aucun attribut JDBC secondaire n'est inclus dans la requête d'ajout.
Lorsque vous ajoutez ou remplacez un attribut via une vue de jointure de LDAP et JDBC, la valeur est tronquée si elle est trop longue pour la base de données SQL.
Lorsque vous ajoutez une entrée via une vue de jointure de LDAP et JDBC, la taille de colonne n'est pas vérifiée avant la mise à jour ou l'ajout d'une valeur de chaîne (varchar ) provoquant une erreur de base de données.
Les tests à fort taux de recherches provoquent des erreurs inattendues, en raison d'une condition de compétitivité dans FailoverLoadBalancingAlgorithm.
Les recherches persistantes sur SSL ne renvoient pas de données.
La stratégie de gestion de la mémoire dans DPS provoque la déconnexion des connexions existantes au moment du déclenchement de GC (si la mémoire est faible).
Lorsque vous ajoutez une entrée, les valeurs de DN ne sont pas toujours converties en minuscules.
Lorsque vous supprimez un attribut partagé (qui existe dans deux sources de données) via une vue de jointure de LDAP et JDBC, une erreur est renvoyée si l'attribut n'existe pas dans l'une des deux vues.
La JVM peut s'arrêter brutalement en mode 64 bits avec JDK 1.6 si la charge de recherche est trop importante.
Lorsque la source JDBC traite ses valeurs de colonne avec respect de la casse (en DB2, notamment), la tentative de suppression d'une valeur d'attribut JDBC peut échouer.
Les sockets peuvent être bloqués à l'état CLOSE_WAIT, ce qui empêche le serveur de répondre.
Si les connexions au serveur sont trop souvent ouvertes et fermées, le serveur peut cesser de répondre après un moment, jusqu'à ce que vous le redémarriez.
Sous Linux AMD64, le serveur ne peut pas démarrer en mode 32 bits.
En cas de charge importante, le serveur peut connaître des problèmes de délai d'attente, qui obligent à retenter les opérations portant sur le serveur d'annuaire.
Lorsque vous utilisez une base mappée virtuellement dans un filtre de recherche, aucun résultat n'est renvoyé dans certaines circonstances.
Avec une vue de jointure, les modifications destinées à la vue de données secondaires peuvent être incorrectement routées vers la vue de données principale.
Si vous ne configurez pas de règle de jointure lorsque vous définissez une vue de jointure incluant une vue JDBC, une exception StringIndexOutOfBoundsException peut se produire.
Certains filtres de recherche spécifiques peuvent provoquer la génération d'erreurs de décodage par le serveur.
Lorsque vous utilisez une vue de jointure contenant une vue JDBC, toute tentative de suppression d'un attribut dans une entrée qui existe uniquement dans le service d'annuaire échoue.
La commande dpadm -V ne détecte pas la version de la JVM.
Le serveur peut laisser les connexions au serveur d'annuaire à l'état CLOSE_WAIT, ce qui empêche le serveur d'annuaire de répondre.
Un filtre de recherche contenant un attribut qui n'est pas de type chaîne (virgule flottante ou date, par exemple) risque de ne pas pouvoir extraire les résultats depuis la vue JDBC.
Les threads de travail internes peuvent être interbloqués, ce qui empêche le serveur de répondre.
Des pics de forte consommation de l'UC peuvent se produire sur le serveur, ce qui empêche tous les services de la machine de répondre.
Des améliorations ont été apportées à la gestion des connexions liées, afin de réduire le temps d'attente de fermeture.
ldapsearch peut renvoyer une valeur d'attribut vide pour une entrée issue du moteur de traitement JDBC MySQL, Derby ou DB2. Avec un moteur de traitement JDBC ORACLE, aucune valeur d'attribut vide n'est renvoyée.
Cette section répertorie les problèmes et restrictions connus au moment de la publication de Directory Server Enterprise Edition 6.3.1.
Le patch Sun Directory Proxy Server 6.3.1 Mise à jour 1 numéro 141958–01 est conçu pour être appliqué par-dessus Directory Server Enterprise Edition 6.3.1 pour corriger les problèmes du composant Directory Proxy Server. Pour en savoir plus, reportez-vous à Directory Proxy Server 6.3.1 Mise à jour 1.
Cette section répertorie les restrictions du produit.
Les modifications des droits d’accès aux fichiers pour les fichiers de produit Directory Server Enterprise Edition installés peuvent dans certains cas empêcher le logiciel de fonctionner correctement. Modifiez uniquement les droits d’accès aux fichiers lorsque vous suivez les instructions de la documentation produit, ou les instructions du support Sun.
Pour contourner cette restriction, installez les produits et créez des instances de serveur en tant qu’utilisateur disposant des droits d’accès utilisateur et groupe appropriés.
Lors de la création d'un certificat de serveur autosigné, veillez à spécifier une validité suffisamment longue pour ne pas avoir à remplacer le certificat.
Pour assurer l'atomicité, n'utilisez pas la vue de données conjointe pour les opérations d'écriture. Si vous effectuez des opérations d'écriture sur une vue de données conjointe, utilisez un système externe pour éviter les incohérences ou les détecter. Vous pouvez contrôler les incohérences en contrôlant le journal des erreurs de Directory Proxy Server.
Cette section répertorie les problèmes connus découverts lors de la sortie de Directory Proxy Server 6.3.1.
L'opération de modification de DN n'est pas prise en charge pour les vues de données LDIF, JDBC, conjointe et de contrôle d'accès.
Actuellement, la commande getEffectiveRight est prise en charge uniquement pour les vues de données LDAP ; elle ne prend pas encore en compte les ACI en local sur le proxy.
Directory Proxy Server peut rejeter les ACI qui spécifient des sous-types de l'attribut cible, par exemple (targetattr = "locality;lang-fr-ca")..
Directory Proxy Server ne peut pas reprendre la connexion à la source de données JDBC restaurée après l'échec de cette connexion. Directory Proxy Server ne peut reprendre la connexion que si vous redémarrez l'instance Directory Proxy Server.
Vous devez redémarrer Directory Proxy Server lorsque la configuration du mode d'authentification change.
Après la génération d'une requête de certificat CA, le certificat s'affiche comme certificat autosigné lorsque vous actualisez.
Si le port SSL utilisé par Directory Proxy Server est incorrect, Directory Proxy Server peut fermer toutes les connexions après une recherche sécurisée sur ce port.
Directory Proxy Server ne parvient pas à compter correctement le nombre de connexions directes lorsqu'il est configuré pour utiliser l'authentification basée sur les informations d'authentification de l'application cliente plutôt que sur une autorisation du proxy.
Il est possible de spécifier la propriété base-dn lors de la création d'une vue de données, mais il est impossible de définir la propriété base-dn sur "", la DSE racine, une fois la vue de données créée.
Directory Service Control Center trie les valeurs sous forme de chaînes. Par conséquent, lorsque vous triez les numéros de Directory Service Control Center, ceux-ci sont triés comme s’ils étaient des chaînes.
Un tri par ordre croissant de 0, 20 et 100 résultats dans la liste 0, 100, 20. Un tri par ordre décroissant de 0, 20 et 100 résultats dans la liste 20, 100, 0.
Après la configuration d'alertes, vous devez redémarrer Directory Proxy Server pour que la modification soit prise en compte.
Directory Proxy Server ne parvient pas à renommer une entrée se déplaçant vers une autre vue de données lorsqu'une distribution de données numériques ou lexicographiques est configurée.
Lorsque vous utilisez des vues de données de jointure, Directory Proxy Server n'intègre pas les algorithmes de distribution de données dans les vues qui composent la jointure.
Pour contourner le problème, configurez la distribution de données au niveau de la vue de données de jointure lorsque vous utilisez à la fois les jointures et la distribution de données.
Dans Directory Proxy Server, la limite de saut de référence ne fonctionne pas.
Sous Windows, le résultat des commandes dsadm et dpadm , ainsi que les messages d'aide, ne sont pas localisés en chinois simplifié et en chinois traditionnel.
La création d'entrées de source de données JDBC n'est pas détectée de façon dynamique. Si vous créez un serveur JDBC avant de créer une vue de données JDBC, cette vue est ignorée jusqu'au redémarrage suivant du serveur. Par conséquent, après la configuration d'une source de données JDBC, vous devez redémarrer Directory Proxy Server pour que la modification soit détectée.
Pour les classes d'objet JDBC, si la classe A utilise une table comme table secondaire et que la classe B utilise la même table uniquement comme table principale, les requêtes portant sur B ne fonctionnent pas. Directory Proxy Server n'ignore pas la propriété filter-join-rule lorsqu'elle est utilisée dans une table principale.
Après installation et après création de l’instance de serveur sur les systèmes Windows, les droits d’accès aux fichiers d’installation et d’instance de serveur permettent l’accès à tous les utilisateurs.
Pour résoudre ce problème, modifiez les droits sur les installations et les dossiers d’instance de serveur.
Sous Windows, l'initialisation de DSCC ne peut être réalisée que par un utilisateur administrateur.
Lors de l'accès à Directory Server via Directory Proxy Server, il a été constaté que Access Manager connaît des problèmes de mise en cache liés aux recherches persistantes après le redémarrage de Directory Server.
Pour contourner le problème, redémarrez Access Manager ou Directory Proxy Server après le redémarrage de Directory Server.
Pour un réglage plus précis, vous pouvez augmenter le nombre des tentatives réalisées par Access Manager pour rétablir les connexions de recherche persistantes, ainsi que l'intervalle entre ces tentatives. Vous augmentez ces valeurs en modifiant les propriétés suivantes dans le fichier AMConfig.properties.
Augmentez la valeur de com.iplanet.am.event.connection.num.retries, qui représente le nombre de tentatives. La valeur par défaut est de 3 tentatives.
Augmentez la valeur de com.iplanet.am.event.connection.delay.between.retries, qui représente le délai en millisecondes entre deux tentatives. La valeur par défaut est de 3 000 millisecondes.
Si vous exécutez une recherche à l'aide d'une vue de données JDBC configurée avec une base de données DB2 et si cette recherche doit renvoyer un grand nombre d'entrées, une erreur peut se produire après le renvoi des 1 344 premières entrées.
Pour éviter cette restriction, augmentez le nombre de packages de grande taille en réglant la valeur du mot-clé de configuration CLI/ODBC CLIPkg sur une valeur inférieure ou égale à 30. Même alors, le nombre de résultats de recherche reste limité à 11 712 entrées.
Pour en savoir plus, reportez-vous à la documentation DB2.
Lorsque vous créez un certificat autosigné avec Directory Service Control Center, n'utilisez aucun caractère multioctet dans le nom de ce certificat.
Les contrôles LDAP par défaut autorisés via Directory Proxy Server ne sont pas affichés par Directory Service Control Center.
Directory Service Control Center supprime les virgules lorsque vous modifiez le DN d'une sous-arborescence exclue existante ou d'une autre base de recherche.
Après la première activation ou désactivation d'un accès LDAP non sécurisé, vous devez redémarrer Directory Proxy Server pour que la modification soit prise en compte.
Les paramètres de limite de durée et de taille fonctionnent avec des sources de données LDAP uniquement.
Après l'exécution de la commande dpadm set-flags cert-pwd-store=off, Directory Proxy Server ne peut pas être redémarré via Directory Service Control Center.
Il arrive que la commande dpadm start échoue lorsqu'elle est utilisée avec une instance de serveur associant des caractères ASCII et multi-octets.
Lors de la définition de la propriété data-view-routing-custom-list sur un gestionnaire de connexions existant, une erreur est retournée avec des noms de vue de données contenant des caractères à éviter, comme des virgules.
Pour résoudre ce problème, ne donnez pas de noms contenant de tels caractères aux vues de données. Par exemple, n'utilisez pas de noms de vues de données contenant des DN.
À la différence des versions précédentes et comme l'indique la page de manuel allowed-ldap-controls(5dpconf), Directory Proxy Server n'autorise pas par défaut le contrôle de tri côté serveur.
Pour activer la prise en charge du contrôle de tri côté serveur dans Directory Proxy Server, ajoutez server-side-sorting à la liste des contrôles LDAP autorisés, spécifiée par la propriété allowed-ldap-controls.
$ dpconf set-server-prop \ allowed-ldap-controls:auth-request \ allowed-ldap-controls:chaining-loop-detection \ allowed-ldap-controls:manage-dsa \ allowed-ldap-controls:persistent-search \ allowed-ldap-controls:proxy-auth-v1 \ allowed-ldap-controls:proxy-auth-v2 \ allowed-ldap-controls:real-attributes-only \ allowed-ldap-controls:server-side-sorting |
Attention, vous devez répéter les paramètres existants. Sinon, seul le contrôle de tri côté serveur est autorisé.
Lors de l'utilisation de la fonctionnalité d'attribution d'un nouveau nom au DN de Directory Proxy Server, notez que des composants de DN répétés sont renommés par un seul composant de remplacement.
Supposons, par exemple, que vous souhaitez renommer des DN se terminant par o=myCompany.com pour qu'ils se terminent par dc=com. Pour les entrées dont le DN répète le composant d'origine, comme uid=userid,ou=people,o=myCompany.com,o=myCompany.com, le DN renommé obtenu est uid=userid,ou=people,dc=com et non uid=userid,ou=people,o=myCompany.com,dc=com.
La configuration de la connexion JDBC pour accéder à Oracle 9 via Directory Proxy Server n'est pas exactement la même que celle décrite dans la documentation.
Examinez la configuration suivante, avec un serveur Oracle 9 écoutant sur l'hôte myhost, port 1537, et l'identificateur du système (SID, system identifier)MYINST pour l'instance. L'instance comprend une base de donnéesMYNAME.MYTABLE.
Pour configurer l'accès à MYTABLE, vous devez généralement définir les propriétés suivantes.
Sur la source de données JDBC, définissez db-name:MYINST.
Sur la source de données JDBC, définissez db-url:jdbc:oracle:thin:myhost:1537: .
Dans la table JDBC, définissez sql-table:MYNAME.MYTABLE
Si ces paramètres ne fonctionnent pas, configurez l'accès à MYTABLE avec les paramètres suivants.
Sur la source de données JDBC, définissez db-name:(CONNECT_DATA=(SERVICE_NAME=MYINST)))
Sur la source de données JDBC, définissez db-url:jdbc:oracle:thin:@(DESCRIPTION= (ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=myhost)(PORT=1537)))
Dans la table JDBC, définissez sql-table:MYNAME.MYTABLE
Directory Proxy Server ne peut pas écrire les attributs JDBC impliquant une relation multivoque (N:N) entre les tables de la base de données JDBC.
Les instances Directory Proxy Server comportant un DN avec des caractères multioctets et créées avec DSCC ne démarrent pas sous Linux.
Lorsque vous utilisez une ServiceManagement Facility (SMF) dans Solaris 10 pour activer une instance de serveur, l'instance ne démarre pas toujours lorsque vous réinitialisez le système et peut retourner l'erreur suivante :
svcadm: Instance "svc:/instance_path" is in maintenance state. |
Pour résoudre ce problème, utilisez un utilisateur local pour créer les serveurs Directory Server et Directory Proxy Server.
Si le chemin d'une instance Directory Proxy Server contient des caractères multioctets, la création de cette instance peut échouer dans DSCC, ou bien elle ne pourra pas démarrer ni réaliser d'autres tâches standard.
Vous pouvez résoudre certains de ces problèmes en utilisant le jeu de caractères qui a servi à créer l'instance. Définissez le jeu de caractères à l'aide des commandes suivantes :
# cacaoadm list-params | grep java-flags java-flags=-Xms4M -Xmx64M # cacaoadm stop # cacaoadm set-param java-flags="-Xms4M -Xmx64M -Dfile.encoding=utf-8" # cacaoadm start |
Pour éviter ce type de problème, utilisez uniquement des caractères ASCII dans le chemin de l'instance.
Sous HP-UX, si vous accédez à DSCC depuis différentes sessions de navigateur dans différentes langues, DSCC affichera peut-être certaines chaînes dans une autre langue que celle définie pour le navigateur.
La console ne récupère pas le statut d'arrière-plan de l'instance Directory Proxy Server si un ordinateur possède plusieurs noms d'hôte.
Si la table SGBDR contient des entrées en double correspondant à un motif de DN figurant dans la classe d'objet JDBC, des nœuds de sous-arborescence (non-terminal) sont renvoyés par Directory Proxy Server lors de la recherche dans la vue de données JDBC. Par exemple, si le motif de DN ou figure dans une classe d'objet JDBC et qu'il existe des entrées en double (sales, par exemple) dans la colonne de SGBDR mappée sur l'attribut JDBC ou, les résultats de recherche contiennent des nœuds en double comme ou=sales.
Pour résoudre le problème, procédez comme suit :
Créez une vue de SGBDR à partir des valeurs de la table qui contiennent la colonne mappée sur l'attribut JDBC ou de manière à ce qu'il n'existe aucune entrée en double.
Remplacez le nom de la table de SGBDR par le nom de la vue de SGBDR figurant dans la classe d'objet JDBC avec le motif de DN ou. La restriction de cette approche est la suivante : comme les vues de SGBDR sont en lecture seule, aucune valeur ne peut être ajoutée à Directory Proxy Server pour l'attribut JDBC ou.
DPS construit des requêtes DB.
Dans DSCC, dans les options More View (Plus d'informations) d'une instance, la date qui s'affiche sous les onglets Journaux d'accès, Journaux d'erreur et Journaux d'audit n'est pas localisée.
Dans DSCC 6.0, useTCPNoDelay est défini sur false par défaut lors de la création d'une source de données avec DSCC, alors que la valeur par défaut de use-tcp-no-delay est définie sur true lors de la création d'une instance via la commande d'administration dpconf create-ldap-data-source.
Dans DSCC, configurés à l'aide de Tomcat server, les titres des fenêtres contextuelles Aide et Version affichent les chaînes multi-octets tronquées.
La chaîne owner dans le résultat de la commande dpadm show-cert dps-instance-path n'est pas traduite en chinois simplifié et en chinois traditionnel.
Les fenêtres contextuelles qui demandent la confirmation de l'arrêt ou de l'annulation de l'enregistrement des serveurs affichent des apostrophes en double en français.
Lorsque vous effectuez des modifications avec l'outil modrate sur une vue de jointure (incluant à la fois LDAP et JDBC), des exceptions de pointeur NULL se produisent si vous utilisez plusieurs threads. Les erreurs constatées sont semblables à la suivante :
java.lang.NullPointerException com.sun.directory.proxy.server.JoinDataView. processModifyRequest(JoinDataView.java:916) com.sun.directory.proxy.server.JoinDataViewOpContext.processModifyRequest (JoinDataViewOpContext.java:243) com.sun.directory.proxy.server.ModifyOperation. processOperation(ModifyOperation.java:502 com.sun.directory.proxy.server .WorkerThread.runThread(WorkerThread.java:150) com.sun.directory.proxy.util.DistributionThread.run (DistributionThread.java:225) |
Lorsque vous ajoutez une nouvelle source de données à un pool, vous devez redémarrer le serveur.
Si la propriété de configuration de Directory Proxy Server allow-bind-operations est définie sur false, il est impossible de se connecter sur un port SSL avec l'argument de ligne commandedpconf et l'option -–secure-port. La connexion via Start TLS (par défaut) ou la connexion claire (l'option-–unsecured) est toujours possible.
Directory Proxy Server ne modifie pas le DN d'une opération ADD lorsque celle-ci suit une référence dans laquelle le basedndiffère de celui de l'ordinateur d'origine. Si vous tentez d'effectuer une opération ADD sur une instance Directory Proxy Server comportant une instance Directory Server paramétrée pour suivre les références, et non pour simplement les transférer, l'opération ADD est rejetée sur le serveur de référence en raison d'un basedn incorrect.
L'utilisation de la commande ldapmodify pour exécuter l'opération ADD directement sur les instances de Directory Server permet à l'opération ADD de fonctionner.
L'écriture des transformations virtuelles ne fonctionne pas pour le modèle de transformation remove-attr-value.
L'écriture des transformations virtuelles ne fonctionne pas comme prévu lorsqu'une entrée est modifiée.
Aucun avertissement n'apparaît lorsque vous définissez un mot de passe trop court pour la base de données de certificats. Directory Service Control Center accepte le mot de passe, même s'il est trop court. L'émission de la commande dpadm avec les sous-commandes cert peut entraîner un blocage des commandes.
Si vous tentez d'ajouter une valeur d'attribut avec le type (SQL TYPE) smalldatetime, cela déclenche l'exception suivante :
ldap_modify: Operations error ldap_modify: additional info: java.lang.Exception: java.lang.Exception: com.microsoft.sqlserver.jdbc.SQLServerException: Conversion failed when converting datetime from character string. |
Les sections suivantes présentent Directory Proxy Server 6.3.1 Mise à jour 1 :
Notes d'installation de Directory Proxy Server 6.3.1 Mise à jour 1
Problèmes connus et restrictions de Directory Proxy Server 6.3.1 Mise à jour 1
Ce patch corrige des problèmes uniquement dans le composant Directory Proxy Server du produit Directory Server Enterprise Edition. Il est conçu pour être appliqué par-dessus Directory Server Enterprise Edition 6.3.1. Le composant Directory Server de Directory Server Enterprise Edition 6.3.1 reste inchangé.
Vous ne pouvez pas appliquer cette mise à jour aux versions de Directory Server Enterprise Edition antérieures à 6.3.1. Pour consulter les consignes de mise à niveau vers la version 6.3.1, reportez-vous au Tableau 2–1, « Chemins de mise à niveau vers Directory Server Enterprise Edition 6.3.1 ».
Cette section contient les rubriques suivantes :
Cette mise à jour est une version mineure principalement conçue pour corriger les bogues décrits à la section Bogues résolus dans Directory Server 6.3.1 Mise à jour 1.
Directory Proxy Server 6.3.1 Mise à jour 1 introduit aussi un nouveau comportement pour les opérations de recherche persistante. Si une application client est très lente lors de la lecture des résultats de recherche persistante depuis le serveur d'annuaire proxy, la file d'attente de réponse du serveur proxy est surchargée. Dans ce cas, le serveur peut fermer la connexion en affichant sur le client la notification suivante :
LDAP_NOTICE_OF_DISCONNECTION [ 1.3.6.1.4.1.1466.20036 ] |
Un message d'informations semblable au suivant est également journalisé :
[11/Aug/2009:18:13:51 +0200] - DISCONNECT - INFO - conn=19 \ reason="admin limit exceeded" \ msg="client didn't read any data during 160 milliseconds." |
Les améliorations suivantes ont été apportées à Directory Proxy Server 6.3.1 Mise à jour 1 :
Il est possible de définir un chemin pour JAVA_HOME et de lui donner la priorité sur la valeur de la variable JAVA_HOME définie dans l'environnement, comme dans l'exemple suivant :
$ dpadm set-flags instance-path jvm-path=/usr/jdk/latest/ |
La commande dpadm permet de modifier la valeur umask. Au redémarrage suivant de l'instance DPS, les permissions du fichier de configuration sont modifiées en fonction de la nouvelle valeur umask. Les permissions du fichier journal sont également définies de la même manière lors de la rotation suivante des fichiers. Voici un exemple de syntaxe standard :
$ dpadm set-flags instance-path umask=22 |
L'administrateur est maintenant autorisé à définir plusieurs transformations virtuelles pour la même combinaison MODEL, ACTION, ATTR_NAME.
Directory Proxy Server 6.3.1 Mise à jour 1 offre également de nouvelles propriétés et des mises à jour de propriétés existantes, précisées dans la liste suivante. Les nouvelles propriétés sont marquées « Nouveau ». Les propriétés dont la spécification a changé depuis DSEE 6.3.1 sont marquées « Mise à jour ».
Dynamique (aucun redémarrage nécessaire)
Niveau : connection-handler
Type : Booléen
Valeur par défaut : false
Description : Indique si le gestionnaire de connexion doit fermer la connexion client lorsqu'aucune source de données n'est disponible.
Dynamique (aucun redémarrage nécessaire)
Niveau : connection-handler
Type : Booléen
Valeur par défaut : false
Description : Indique qu'il n'est pas toujours nécessaire d'utiliser l'identité du client entrant lors de la liaison à un serveur LDAP distant.
Documentation : Cette propriété est un indicateur qui signale qu'il n'est pas toujours nécessaire d'utiliser l'identité du client entrant lors de la liaison à un serveur LDAP distant.
Dynamique (aucun redémarrage nécessaire)
Niveau : jdbc-data-source
Type : Énumération
Le moteur de traitement SGBDR est de type MySQL.
Le moteur de traitement SGBDR est de type Apache Derby/Java DB.
Le moteur de traitement SGBDR est de type DB2.
Le moteur de traitement SGBDR est de type Oracle.
Le moteur de traitement SGBDR est de type Microsoft SQL Server.
Le moteur de traitement SGBDR n'est pas défini. Lorsque cela est possible, Directory Proxy Server détermine le nom du fournisseur à partir de la valeur db-url définie dans jdbc-data-source.
Valeur par défaut : generic
Description : Nom du fournisseur de la source de données JDBC
Documentation : Cette propriété spécifie le nom du fournisseur de la source de données JDBC. Elle doit être définie si vous utilisez un pilote JDBC tiers autre que celui fourni par le fournisseur de la base de données pour vous connecter au moteur de traitement SGBDR. Les données servent à construire des instructions SQL propres au fournisseur (si possible) afin d'améliorer les performances.
Dynamique (aucun redémarrage nécessaire)
Niveau : jdbc-data-view, join-data-view, ldap-data-view et ldif-data-view
Nouveau type : Long
Ancien type (DPS 6.0 à 6.3.1) : Entier
Les autres attributs restent inchangés.
Dynamique (aucun redémarrage nécessaire)
Niveau : jdbc-data-view, join-data-view, ldap-data-view et ldif-data-view
Nouveau type : Long
Ancien type (DPS 6.0 à 6.3.1) : Entier
Les autres attributs restent inchangés.
Statique (redémarrage nécessaire)
Niveau : ldap-data-source
Type : Durée en secondes (minimum : 1)
Valeur par défaut : Héritée (valeur de monitoring-interval)
Description : Intervalle auquel le contrôleur de disponibilité interroge les connexions ayant échoué pour détecter leur récupération
Documentation : Cette propriété définit l'intervalle d'interrogation. Si une connexion est reconnue comme hors service, le contrôleur de disponibilité l'interroge selon l'intervalle fixé afin de détecter sa récupération. Si vous ne spécifiez aucune valeur, celle définie pour la propriété monitoring-interval est utilisée.
Statique (redémarrage nécessaire)
Niveau : ldap-data-source
Type : Entier (minimum : 1)
Valeur par défaut : 3
Description : Nombre de tentatives à effectuer avant que la connexion ne soit marquée comme hors service
Documentation : Cette propriété indique combien de fois le contrôleur de disponibilité interroge la connexion une fois qu'il l'a détectée comme étant hors service. La connexion est ainsi plus rapidement marquée comme en service. Si la connexion échoue toujours après le nombre de tentatives indiqué, la valeur de la propriété down-monitor-interval est utilisée comme intervalle d'interrogation.
Dynamique (aucun redémarrage nécessaire)
Niveau : ldap-data-source
Type : Booléen
Valeur par défaut : true
Description : Spécifie si SO_KEEPALIVE est activé pour les connexions entre le serveur et la source de données
Documentation : Cette propriété est un indicateur qui précise si SO_KEEPALIVE doit ou non être activé pour les connexions entre le serveur et la source de données.
Dynamique (aucun redémarrage nécessaire)
Niveau : ldap-listener et ldaps-listener
Type : Booléen
Valeur par défaut : true
Description : Spécifie si SO_KEEPALIVE est activé pour les connexions entre les clients et le listener
Documentation : Cette propriété est un indicateur qui précise si SO_KEEPALIVE doit ou non être activé pour les connexions entre les clients et le listener.
Dynamique (aucun redémarrage nécessaire)
Niveau : Serveur
Type : Booléen
Valeur par défaut : true
Nouvelle description : Indique si le serveur accepte les opérations non authentifiées
Ancienne description (DPS 6.0 à DPS 6.3.1) : Indique si le serveur accepte les opérations effectuées par des clients anonymes
Nouvelle documentation : Cette propriété est un indicateur qui précise si Directory Proxy Server accepte ou non les opérations non authentifiées. Le mode utilisé pour traiter l'opération de liaison est spécifié par allow-unauthenticated-operations-mode.
Ancienne documentation (DPS 6.0 à DPS 6.3.1) : Cette propriété est un indicateur qui précise si Directory Proxy Server autorise ou non les clients anonymes à réaliser des opérations.
Dynamique (aucun redémarrage nécessaire)
Niveau : Serveur
Type : Énumération
Si aucun mot de passe n'est spécifié, seules les connexions anonymes sont autorisées.
Si aucun mot de passe n'est spécifié, seules les connexions où un DN est défini sont autorisées.
Si aucun mot de passe n'est spécifié, les connexions anonymes et celles où un DN est défini sont autorisées.
Valeur par défaut : anonymous-and-dn-identified
Description : Mode de traitement des opérations de connexion sans saisie de mot de passe
Documentation : Cette propriété indique comment Directory Proxy Server traite les opérations pour lesquelles aucun mot de passe de liaison n'est saisie lorsque la propriété allow-unauthenticated-operations est configurée sur true (vrai).
Statique (redémarrage nécessaire)
Niveau : Serveur
Type : Durée en millisecondes
Nouvelle valeur par défaut : 250
Ancienne valeur par défaut (DPS 6.0 à 6.3.1) : 500
Nouvelle documentation : Cette propriété définit l'intervalle qui sépare deux appels système consécutifs qui lisent l'heure dans le système d'exploitation. Pour en savoir plus sur les opérations qui durent moins de 250 millisecondes, réduisez la valeur time-resolution ou modifiez la valeur de la propriété time-resolution-mode. Si vous indiquez 0 milliseconde, le proxy se comporte comme si la valeur de la propriété time-resolution-mode était configurée sur system-milli. Cette propriété est ignorée lorsque la valeur de la propriété time-resolution-mode est configurée sur system-milli ou system-micro.
Ancienne documentation (DPS 6.0 à 6.3.1) : Cette propriété définit l'intervalle qui sépare deux appels système consécutifs qui lisent l'heure dans le système d'exploitation. Pour en savoir plus sur les opérations qui durent moins de 500 millisecondes, réduisez la valeur time-resolution. Si vous utilisez 0 milliseconde, le proxy exécute systématiquement un appel système pour connaître l'heure actuelle. Sinon, l'heure est mise en cache et récupérée uniquement à la fréquence définie par time-resolution. Cette heure est affichée dans les journaux.
La description reste inchangée.
Statique (redémarrage nécessaire)
Niveau : Serveur
Type : Énumération
Utiliser un thread qui exécuter un appel système toutes les time-resolution millisecondes
Utiliser un appel système qui récupère l'heure en millisecondes
Utiliser un appel système qui récupère l'heure en microsecondes
Valeur par défaut : custom-resolution
Description : Mode utilisé pour récupérer l'heure système
Documentation : Cette propriété spécifie le mode utilisé pour récupérer l'heure depuis le système d'exploitation.
Directory Proxy Server 6.3.1 Mise à jour 1 est disponible pour toutes les plates-formes prises en charge par Directory Server Enterprise Edition 6.3.1. Pour en savoir plus, reportez-vous à Matériel requis et à Systèmes d'exploitation requis .
Cette section répertorie les bogues corrigés dans Directory Proxy Server 6.3.1 Mise à jour 1.
Directory Proxy Server construit des requêtes de base de données non admises.
La configuration de connectionIdleTimeOutInSec pour le listener LDAP peut désactiver DSCC.
Une opération de recherche peut renvoyer des entrées contenant des attributs absents de viewable-attr.
La propriété max-client-connections n'est pas appliquée si aucune opération n'est effectuée sur la connexion.
Le contrôle de la mémoire est désactivé par défaut.
L'algorithme de distribution numérique doit utiliser long au lieu d'int pour la définition de limites numériques.
La limite de taille par défaut de Directory Proxy Server pour les propriétés de ressource utilise un entier incorrect pour indiquer une valeur illimitée.
Les transformations de DN échouent.
La configuration d'add-attr-value peut conduire les transformations de DN à produire une sortie incorrecte.
Le DN de liaison (bindDN) doit être mappé lors de la liaison à un serveur LDAP. (Utilisez la règle de mappage de DN du DV de bindDN).
Il est impossible d'ajouter une nouvelle transformation virtuelle avec les mêmes valeurs « MODEL, ACTION, ATTR_NAME ».
Si vous définissez la propriété requires-bind-password sur un serveur d'annuaire back-end, elle n'est pas appliquée.
Le mappage de DN virtuel échoue lorsqu'il dépend d'un attribut virtuel.
Le DN de liaison est rejeté en cas d'échec de la transformation, même s'il fait partie de la vue.
Mappage de DN incorrect pour la direction « depuis le serveur ».
Directory Proxy Server 6.3 transforme les majuscules/minuscules des noms d'attribut.
Un client a demandé à Directory Proxy Server de définir des permissions de groupe pour les fichiers de configuration et les journaux (umask 117, chmod 660).
La commande dpadm start crée un vidage core dump lorsque vous utilisez l'argument Java MaxTenuringThreshold.
Avec un mappage de DN, impossible de supprimer les entrées renommées.
La commande dpadm ne génère pas de fichier DPS.pid.
Le schéma de configuration de Directory Proxy Server n'est pas cohérent avec la fonction SystemMonitorThread.java.
Le serveur et la console sont incohérents pour le paramètre searchMode.
Directory Proxy Server échoue si vous le configurez pour utiliser l'authentification par proxy.
Autoriser la configuration de JAVA HOME avec dpadm set-flags.
Impossible d'utiliser le mappage de DN avec rootDSE.
Directory Proxy Server nécessite une transformation de DN virtuel avec les attributs de nom à plusieurs valeurs.
La granularité d'heure en microsecondes doit être fournie pour la durée d'exécution (valeurs etime).
La commande splitldif ignore les transformations virtuelles.
Avec une charge de traitement importante, les sockets peuvent rester à l'état d'attente Fermé.
L'option SO_KEEPALIVE n'est pas définie dans Directory Proxy Server 6.3 (à savoir, setKeepAlive() != True) lors de la création d'un socket.
La solution indiquée pour CR 6513526 peut créer des régressions en raison de valeurs NULL dans les objets ConfigAttribute.
La propriété acceptBacklog est ignorée pour les listeners basés sur un canal.
Les pulsations d'inactivité ne sont pas envoyées à une fréquence suffisante, en raison de la dernière activité réalisée sur une connexion back-end.
Les pulsations d'inactivité ne sont pas envoyées pour les connexions d'arrière-plan liées.
Les vérifications du serveur d'arrière-plan peuvent ne pas être effectuées assez souvent à cause de la dernière activité du serveur.
La fonction ldapsearch peut générer une sortie incohérente si vous l'exécutez sur les entrées de contrôle.
Vous devez exécuter une vérification de disponibilité pour vous assurer que le serveur d'arrière-plan est arrêté, avant de couper toutes les connexions.
En présence d'une requête d'abandon, une connexion peut être bloquée.
Une plus grande précision est nécessaire dans la pulsation d'arrière-plan.
Il se produit une fuite de descripteur de fichier dans le socket de serveur.
Une exception de pointeur NULL se produit lorsque vous effectuez une recherche sur cn=monitor, si un pool de basculement est défini sans source.
Directory Proxy Server continue à ouvrir des connexions au serveur d'annuaire après l'échec d'une tentative de liaison.
Les clients de recherche persistante peuvent ne pas recevoir les notifications de modification des entrées.
Deux connexions peuvent partager un même identificateur.
Les recherches persistantes ne sont pas nettoyées après déconnexion du client.
L'intervalle de surveillance proactive doit être défini sur 1 seconde lorsqu'une source de données est détectée comme étant hors service.
Directory Proxy Server associe différentes opérations client avec la même connexion d'arrière-plan.
Les connexions d'arrière-plan ne sont pas fermées mais réutilisées si leur durée d'inactivité dépasse inactivity-timeout, ce qui provoque une fuite de connexion.
La gestion interne du pool de connexions et le traitement des vérifications de l'état de santé doivent être DEBUG.
Deux liaisons de type Long simultanées affectent la même connexion d'arrière-plan à deux connexions clients.
La configuration d'une valeur jvm-path incorrecte provoque un blocage du redémarrage, sans avertissement.
Directory Proxy Server renvoie un code d'erreur incorrect lorsqu'aucun serveur d'arrière-plan n'est disponible.
Une option doit être fournie pour fermer la connexion client en cas d'erreur « impossible de récupérer la connexion d'arrière-plan ».
L'affinité client ne doit pas être activée lorsque useAffinity=false et que la valeur affinityPolicy est définie de façon explicite.
Directory Proxy Server ne peut pas démarrer si l'un des hôtes de source de données est inaccessible.
La commande dpconf doit prendre en charge les nouveaux attributs apparus avec Directory Proxy Server 6.3.1 Mise à jour 1.
La commande dpconf doit prendre en charge le mappage de DN de liaison.
Des fonctions de versionnage plus simples doivent être fournies pour la gestion des propriétés Directory Proxy Server.
La fonction dpconf doit prendre en charge monitorRetryCount.
L'affinité client ignore l'indicateur Lecture seule de la source de données.
L'implémentation des correctifs de CR 6714425 et 6714448 doit être terminée.
Une expression de jointure en minuscules peut provoquer un échec des requêtes SQL.
Les performances de Directory Proxy Server 6.3.1 sont fortement réduites si plus de 100 clients exécutent des recherches persistantes.
En cas de boucle du thread de recherche persistante, Directory Proxy Server ne peut plus gérer les recherche persistantes.
Les performances de recherche persistantes sont très médiocres.
Si vous créez 20 recherches persistantes et que vous les arrêtes, la fonction de recherche persistante échoue.
Directory Proxy Server renvoie l'exception StringIndexOutOfBoundsException dans certaines situations de mappage d'attribut et de transformation virtuelle.
Les règles de transformation et de mappage ne fonctionnent pas comme prévu.
Des threads peuvent être libérés de façon prématurée, ce qui génère une exception ASN.1.
Directory Proxy Server renvoie une erreur incorrecte lorsque le moteur de traitement est hors service.
Une exception de pointeur NULL inattendue peut être générée.
Dans certaines situations, le plan de stockage du mot de passe peut être ignoré par la vue de données JDBC.
Directory Proxy Server peut renvoyer des résultats identique lorsque des utilisateurs différents créent une liaison sur une connexion client.
Dans certaines situations, Directory Proxy Server peut ne pas démarrer si vous utilisez JDBC.
Une exception ASN1 inattendue peut se produire et ne pas être gérée.
Cette section contient les rubriques suivantes :
Directory Proxy Server 6.3.1 Mise à jour 1 est un patch qui s'applique aux installations Directory Server Enterprise Edition 6.3.1 existantes. Si vous utilisez une version de Directory Server Enterprise Edition antérieure à 6.3.1, vous devez d'abord mettre votre système à niveau vers la version 6.3.1 comme le décrit le Chapitre 2Remarques sur l’installation, avant d'appliquer le patch Directory Proxy Server 6.3.1 Mise à jour 1.
Vous pouvez télécharger le patch Directory Proxy Server 6.3.1 Mise à jour 1 à l'adresse http://www.sun.com/software/products/directory_srvr_ee/get.jsp.
Directory Proxy Server 6.3.1 Mise à jour 1 est un patch unique applicable à toutes les plates-formes DSEE :
Solaris SPARC
Solaris 9 x86
Solaris 10 x86 et AMD x64
Red Hat Linux
SuSe Linux
HP-UX
Windows
Vous trouverez pour chaque plate-forme les distributions suivantes :
Distribution par packages natifs (sauf pour HP-UX)
Distribution zip
Le patch Directory Proxy Server 6.3.1 Mise à jour 1 numéro 141958-01 est disponible dans SunSolve et s'applique aux deux types d'installation suivants :
Packages natifs Directory Server Enterprise Edition 6.3.1 installés avec le programme d'installation Java ES
Installations zip de Directory Server Enterprise Edition 6.3.1
Cette section explique comment installer Directory Proxy Server 6.3.1 Mise à jour 1.
Sauvegardez le répertoire d'installation de Directory Server Enterprise Edition avant d'appliquer le patch Directory Proxy Server 6.3.1 Mise à jour 1, car vous ne pourrez pas ultérieurement restaurer votre configuration Directory Proxy Server précédente. Cela s'applique aussi bien aux installations zip qu'aux installations par packages natifs.
Téléchargez le patch 141958-01 depuis Sunsolve dans le répertoire de votre choix (downloaded-patch-path).
Arrêtez les instances de Directory Proxy Server associées à l'installation à laquelle vous prévoyez d'appliquer le patch.
Sous Windows, ouvrez une fenêtre d'invite de commande. Sous UNIX, ouvrez une fenêtre de terminal.
Accédez au répertoire où réside le logiciel d'installation correspondant à la plate-forme et à la distribution (zip ou native) à mettre à jour :
Voici un exemple de commande standard pour cette opération :
$ cd downloaded-patch-path/SunOS_x64/zip/delivery |
Le tableau suivant indique l'emplacement du logiciel d'installation dans le répertoire downloaded-patch-path.
Système d’exploitation |
Répertoire de la distribution zip |
Répertoire des packages natifs |
---|---|---|
Solaris SPARC |
SunOS/zip/delivery |
SunOS/native/delivery |
Solaris 9 x86 |
SunOS_x86/zip/delivery |
SunOS_x86/native/delivery |
Solaris 10 x86 et AMD x64 |
SunOS_x64/zip/delivery |
SunOS_x64/native/delivery |
Red Hat Linux |
Linux/zip/delivery |
Linux/native/delivery |
SuSE Linux |
Linux/zip/delivery |
Linux/native/delivery |
HP-UX |
Hpux/zip/delivery |
N/D |
Windows |
Windows/zip/delivery |
Windows/native/delivery |
Sous UNIX, lancez le script d'installation.
Exécutez la commande suivante :
$ Install dsee631-install-path |
où dsee631-install-path est le chemin du répertoire où Directory Server Enterprise Edition 6.3.1 est installé.
Les messages suivants s'affichent :
-------------------------------------------------------------------- IMPORTANT : Make sure all the DPS instances associated with the Directory Proxy Server installation being patched are shutdown prior to apply the Directory Proxy Server 6.3.1 Update 1 Patch -------------------------------------------------------------------- Do you want to proceed with the installation (y/Y to proceed, n/N to abort) [n] ? |
Entrez y pour yes (Oui). Le programme d'installation applique le patch à l'installation Directory Server Enterprise Edition 6.3.1 spécifiée.
Sous Windows, exécutez la commande suivante dans la fenêtre d'invite de commande :
Install.exe |
Un assistant s'ouvre et vous demande d'accéder au répertoire d'installation correct pour l'installation du patch Directory Proxy Server 6.3.1 Mise à jour 1, et de sélectionner ce répertoire. Pour appliquer le patch à une installation zip 6.3.1, sélectionnez le répertoire où vous avez installé Directory Server Enterprise Edition 6.3.1. Pour appliquer le patch à une installation par packages natifs, sélectionnez C:\Program Files\Sun\JavaES5\DSEE.
L'assistant applique le patch à Directory Server Enterprise Edition 6.3.1.
Vérifiez que l'installation a réussi en exécutant les deux commandes suivantes et en vérifiant que la réponse est identique à celle indiquée ici :
$ dpadm -V [dpadm] dpadm : 6.3.1.1 B2009.1106.0156 ZIP [DPS] Sun Microsystems, Inc. Sun-Java(tm)-System-Directory-Proxy-Server/6.3.1.1 B2009.1106.0259 $ dpconf -V [dpconf] clip.jar : 6.3.1 B2008.1121.0155 dpcfg.jar : 6.3.1.1 B2009.1106.0155 dpcfgcli.jar : 6.3.1.1 B2009.1106.0155 common.jar : 6.3.1 B2008.1121.0155 common_cfg.jar : 6.3.1 B2008.1121.0155 |
Cette étape est obligatoire si l'installation Directory Server Enterprise Edition 6.3.1 que vous patchez inclut le correctif pour CR 6722222.
Si le correctif pour CR 6722222 (Mapper bindDN lors de la liaison à un serveur LDAP (avec la règle de mappage de DN du DV de bindDN)) a été appliqué, exécutez la commande suivante sur toutes les instances pour chacun des gestionnaires de connexion :
$ dpconf set-connection-handler-prop -p port -h host connection handler \ data-view-use-internal-client-identity:true |
Cette propriété est un indicateur qui signale qu'il n'est pas toujours nécessaire d'utiliser l'identité du client entrant lors de la liaison à un serveur LDAP distant. Après l'application de CR 6722222, vous pouvez configurer le comportement par défaut à l'aide d'une propriété de gestionnaire de connexion comme le montre l'exemple.
Redémarrez toutes les instances de serveur proxy.
Cette section répertorie les problèmes connus et restrictions découverts lors de la sortie de Directory Proxy Server 6.3.1 Mise à jour 1.
Les problèmes connus et restrictions de Directory Proxy Server 6.3.1 s'appliquent toujours, même après l'application du patch pour Directory Proxy Server 6.3.1 Mise à jour 1. Pour en savoir plus sur ces problèmes, reportez-vous à Problèmes connus et restrictions de Directory Proxy Server.
Cette section répertorie les restrictions connues découvertes lors de la sortie de Directory Proxy Server 6.3.1 Mise à jour 1.
Comme le décrit la section JDBC Object Classes du Sun Java System Directory Server Enterprise Edition 6.3 Reference, le processus de définition de tables JDBC utilise des tables principales et secondaires. Directory Proxy Server n'autorise pas l'utilisation d'une table secondaire comme table principale d'une autre table. Autrement dit, Directory Proxy Server ne prend en charge qu'un seul niveau de règle de jointure.
Cette section répertorie les problèmes connus découverts lors de la sortie de Directory Proxy Server 6.3.1 Mise à jour 1.
Dans la version 6.3, si une entrée comporte plus de deux classes d'objet, l'ajout d'une entrée via une vue de jointure (LDAP et JDBC) échoue en raison du correctif de CR 6636463. Pour ajouter ce type d'entrée, vous devez définir ces classes d'objet en tant que super-classe dans l'entrée de configuration jdbc-object-class à l'aide de la commande ldapmodify suivante, car dpconf set-jdbc-object-class-prop ne peut ajouter qu'une seule super-classe.
Cet exemple permet d'ajouter l'entrée suivante :
dn: uid=test,ou=people,o=join sn: User cn: Test User objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson uid: test userpassword: password givenname: Test mail: test@example.com telephonenumber: 8888-8888 roomnumber: 8000
La vue JDBC est définie comme indiqué dans l'exemple suivant, qui fonctionnait avant la version 6.3.
dn: cn=person,cn=example-view,cn=data views,cn=config secondaryTable: country1 secondaryTable: phone1 primaryTable: employee1 objectClass: top objectClass: configEntry objectClass: jdbcObjectClassMapping dnPattern: uid cn: person superclass: top
Comme objectClass:organizationalPerson et objectClass:inetOrgPerson existent toutes les deux dans l'entrée que vous ajoutez, vous devez définir ces deux classes d'objet comme super-classes, en exécutant la commande ldapmodify suivante.
$ ldapmodify -p dpsPort -D "cn=Proxy manager" -w password dn: cn=person,cn=example-view,cn=data views,cn=config changetype: modify add: superClass superClass: inetOrgPerson - add: superClass superClass: organizationalPerson |
Une fois cette commande ldapmodify exécutée, jdbc-object-class est défini comme le montre l'exemple suivant.
dn: cn=person,cn=example-view,cn=data views,cn=config secondaryTable: country1 secondaryTable: phone1 primaryTable: employee1 objectClass: top objectClass: configEntry objectClass: jdbcObjectClassMapping dnPattern: uid cn: person superclass: top superclass: inetOrgPerson Added superclass: organizationalPerson Added
Bien que le paramètre par défaut de la propriété log-level-data-sources-detailed soit documenté comme étant none, la valeur par défaut réelle est all. Toutefois, si vous définissez log-level-data-sources-detailed sur une valeur autre que none, cela a un impact sur les performances du serveur et provoque une croissance rapide du fichier access. Par conséquent, la valeur de log-level-data-sources-detailed est automatiquement configurée sur none lorsque vous créez une instance de serveur DPS. Il est recommandé de ne pas utiliser d'autre valeur pour ce paramètre.
En raison d'un problème décrit dans la Note de vulnérabilité VU#836068, MD5 vulnérable aux attaques par collision, Directory Proxy Server doit éviter d'utiliser l'algorithme MD5 dans les certificats signés.
Procédez comme suit pour déterminer l'algorithme de signature d'un certificat.
Exécutez la commande suivante pour afficher la liste des certificats définis dans une instance Directory Proxy Server spécifique :
$ dpadm list-certs instance-path |
Exécutez les commandes suivantes sur chacun des certificats définis afin de déterminer si ce certificat a été signé avec l'algorithme MD5 :
$ dpadm show-cert -F ascii -o cert-output-file \ dps-instance-path cert-alias $ dsadm add-cert ds-instance-path cert-alias \ cert-output-file $ dsadm show-cert ds-instance-path cert-alias |
L'exemple suivant montre la sortie typique de la commande dsadm show-cert pour un certificat à signature MD5 :
Certificate: Data: ... Signature Algorithm: PKCS #1 MD5 With RSA Encryption ... |
Exécutez la commande suivante pour supprimer les certificats à signature MD5 de la base de données :
$ dsadm remove-cert instance-path cert-alias |
Procédez comme suit pour mettre à niveau le mot de passe de la base de données de certificats. (La commande dpadm génère un mot de passe par défaut pour la base de données de certificats lorsque vous créez une instance de serveur d'annuaire.)
Arrêtez l'instance de Directory Proxy Server.
Exécutez la commande suivante :
$ dpadm set-flags instance-path cert-pwd-prompt=on |
Un message vous invite à saisir un mot de passe.
Entrez un mot de passe comptant au moins huit caractères.
Redémarrez l'instance Directory Proxy Server et saisissez le jeton interne (logiciel) lorsque vous y êtes invité.
Remplacez tous les certificats utilisant la fonction MD5 par des certificats utilisant l'algorithme de signature SHA-1. Appliquez l'une des procédures suivantes, selon que votre installation utilise un certificat autosigné ou un certificat acquis auprès d'une autorité de certification.
Procédez comme suit pour générer et stocker un certificat autosigné :
Exécutez la commande suivante :
$ dpadm add-selfsign-cert --sigalg SHA1withRSA \ dps-instance-path cert-alias |
L'algorithme de signature par défaut est MD5withRSA.
L'invite suivante s'affiche :
[Password or Pin for "NSS Certificate DB"] |
Entrez le nouveau mot de passe de la base de données des certificats.
Procédez comme suit pour générer et stocker un certificat acquis auprès d'une autorité de certification (CA) :
Exécutez la commande suivante pour émettre une demande de certificat serveur signé par l'autorité de certification :
$ dpadm request-cert --sigalg SHA1withRSA instance-path cert-alias |
Vérifiez que votre autorité de certification n'utilise plus l'algorithme de signature MD5, puis envoyez-lui la demande de certificat (cela peut se faire en interne dans votre société ou en externe, selon vos règles d'entreprise) afin de recevoir un certificat serveur signé par l'autorité de certification, comme le décrit la section To Request a CA-Signed Server Certificate du Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide.
Lorsque l'autorité de certification vous envoie le nouveau certificat, exécutez la commande suivante pour ajouter ce certificat à la base de données des certificats :
$ dpadm add-cert instance-path cert-alias |
Cette étape est décrite à la section Creating, Requesting and Installing Certificates for Directory Proxy Server du Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide.
Si le certificat de l'autorité de certification de confiance n'est pas encore stocké dans la base de données des certificats, exécutez la commande suivante pour l'ajouter :
$ dpadm add-cert --ca instance-path trusted-cert-alias |
Cette étape est décrite à la section Creating, Requesting and Installing Certificates for Directory Proxy Server du Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide.
Exécutez les commandes suivantes pour vérifier que le système utilise le nouveau certificat.
$ dpadm show-cert -F ascii -o cert-output-file \ dps-instance-path cert-alias $ dsadm add-cert ds-instance-path cert-alias \ cert-output-file $ dsadm show-cert ds-instance-path cert-alias |
Avec un moteur de traitement Microsoft SQL Server, lorsque vous utilisez des champs smalldate, seule la version longue des dates est prise en charge. Sinon, une erreur de conversion se produit, comme le montre l'exemple suivant.
ldap_modify: Operations error ldap_modify: additional info: java.lang.Exception: \ com.microsoft.sqlserver.jdbc.SQLServerException: \ Conversion failed when converting datetime from character string. |
La version longue d'une date est au format AAAA -MM-JJ HH:MM.