Cette section répertorie les problèmes connus découverts lors de la sortie de Directory Proxy Server 6.3.
Pour une opération join-data-view associant une vue de données LDAP et une vue de données JDBC, si vous ajoutez, remplacez ou modifiez un attribut dont la valeur est trop longue pour pouvoir être enregistrée dans la base de données, cette valeur est tronquée et les problèmes suivants sont générés pour la source de données :
Dans mySQL, la ligne de la base de données à laquelle l'attribut appartient apparaît deux fois.
Dans DB2, certaines tables de base de données ne sont plus disponibles jusqu'à ce que Directory Proxy Server soit redémarré.
Lorsqu'une nouvelle source de données est ajoutée à un nouveau pool de sources de données, le serveur doit être redémarré.
Pour une vue regroupant à la fois LDAP et JDBC, avec un UID dans la règle de regroupement et un attribut supplémentaire dans la vue JDBC, une opération ldapsearch pour cet attribut retourne toutes les entrées du serveur.
Directory Proxy Server ne modifie pas le DN d'une opération ADD lorsque celle-ci suit une référence dans laquelle le basedn diffè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'ADD directement sur les instances de Directory Server permet à l'ADD de fonctionner.
Si vous effectuez un grand nombre de recherches avec Directory Server Enterprise Edition, Directory Proxy Server est fortement sollicité, ce qui peut entraîner la génération d'erreurs ArrayIndexOutOfBounds et NegativeArraySize.
Directory Proxy Server risque de se bloquer lorsqu'il est utilisé avec Java 1.6 en mode 64–bit. Pour éviter ce problème, utilisez Java 1.5. Pour plus d'informations, voir Dépendance logicielle requise.
Lorsque vous effectuez des modifications à l'aide de l'outil modrate sur une vue de regroupement comprenant à la fois LDAP et JDBC, des exceptions de pointeur nul se produisent si vous utilisez plusieurs threads. Les erreurs ressemblent aux suivantes :
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) |
Si la propriété de configuration 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 commande dpconf et l'option -–secure-port. La connexion via Start TLS (par défaut) ou une connexion claire (option-–unsecured) sont toujours possibles.
L'écriture de transformations virtuelles ne fonctionne pas avec le modèle de transformation remove-attr-value.
L'écriture de transformations virtuelles ne fonctionne pas comme souhaité lorsqu'une entrée est modifiée.
L'opération de modification de DN n'est pas prise en charge pour les vues de données LDIF, JDBC, associées 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 spécifiant des sous-types pour l'attribut cible, comme (targetattr = "locality;lang-fr-ca").
Directory Proxy Server ne peut pas reprendre la connexion source de données JDBC restaurée après un échec de connexion de source de données. Directory Proxy Server peut reprendre la connexion uniquement après le redémarrage de l'instance Directory Proxy Server.
Directory Proxy Server doit être redémarré lorsque la configuration du mode d'authentification est modifiée.
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.
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.
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 des valeurs sous forme de chaînes. Ainsi, lorsque vous triez des nombres dans Directory Service Control Center, ils sont triés comme s'il s'agissait de chaînes.
Un tri croissant de 0, 20 et 100 donne la liste 0, 100, 20. Un tri décroissant de 0, 20 et 100 donne la liste 20, 100, 0.
La création dans DSCC d'une instance de Directory Proxy Server, dont le chemin comprend des caractères multi-octets, en vue de démarrer ou d'exécuter d'autres tâches standard, risque d'échouer.
Certains de ces problèmes peuvent être résolus à l'aide du jeu de caractères utilisé pour créer l'instance. Pour définir le jeu de caractères, utilisez les 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 ces problèmes, n'utilisez que des caractères ASCII dans les chemins d'instances.
Après la configuration d'alertes, vous devez redémarrer Directory Proxy Server pour que la modification soit prise en compte.
Dans Directory Proxy Server, la limite de pas de référence ne fonctionne pas.
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.
Lors de l'utilisation de vues de données associées, Directory Proxy Server ne prend pas en compte les algorithmes de distribution de données des vues constituant l'association.
Pour résoudre ce problème, configurez une distribution de données au niveau de la vue de données associée lorsque vous combinez des associations et une distribution de données.
Dans 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 automatiquement détectée. Si vous créez un serveur JDBC avant de créer une vue de données JDBC, celle-ci est ignorée jusqu'au prochain redémarrage de l'ordinateur. Après la configuration d'une source de données JDBC, vous devez donc redémarrer Directory Proxy Server pour que la modification soit prise en compte.
Pour les classes d'objets JDBC, si une classe, A, utilise une table en tant que table secondaire, et si une autre classe, B, utilise cette même table en tant que table principale uniquement, les requêtes sur B ne fonctionnent pas. Directory Proxy Server ne parvient pas à ignorer la propriété filter-join-rule lorsqu'elle est utilisée dans une table principale.
Après l'installation et la création d'une instance de serveur sous Windows, les droits d'accès aux fichiers du dossier d'installation et de l'instance de serveur autorisent l'accès à tous les utilisateurs.
Pour résoudre ce problème, modifiez les droits d'accès dans les dossiers d'installation et d'instance de serveur.
Dans Windows, l'initialisation de DSCC ne peut être réalisée que par un administrateur
Il a été constaté que Access Manager, lors de l'accès à Directory Server via Directory Proxy Server, rencontre des problèmes liés à des recherches persistantes après un redémarrage de Directory Server.
Pour résoudre ce problème, redémarrez Access Manager ou Directory Proxy Server après avoir redémarré Directory Server.
Pour affiner davantage, vous pouvez augmenter le nombre de tentatives et le délai d'attente entre les tentatives d'Access Manager pour rétablir des connexions de recherche persistante. Vous pouvez augmenter ces paramètres en modifiant les propriétés suivantes du fichier AMConfig.properties.
Augmentez com.iplanet.am.event.connection.num.retries, qui représente le nombre de tentatives. Le nombre de tentatives par défaut est de 3.
Augmentez com.iplanet.am.event.connection.delay.between.retries, qui représente la durée en millisecondes entre chaque tentative. La valeur par défaut est de 3 000 millisecondes.
Si vous effectuez une recherche dans la vue de données JDBC configurée avec la base de données DB2 et qu'il y a un grand nombre de réponses à votre recherche, une erreur risque de se produire au bout de 1 344 entrées.
Pour contourner cette limite, augmentez le nom de grands packages en définissant une valeur du mot-clé de configuration CLI/ODBC CLIPkg supérieure à 30. Le résultat de la recherche sera alors limité à 11 712 entrées.
Pour plus d'informations, consultez la DB2 documentation.
Lors de la création d'un certificat autosigné à l'aide de Directory Service Control Center, n'utilisez pas de caractères multioctets dans les noms de certificats.
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'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 renvoyé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.
Contrairement aux versions précédentes, tel qu'indiqué dans la page de manuel allowed-ldap-controls(5dpconf), Directory Proxy Server n'autorise pas le contrôle du tri côté serveur par défaut.
Vous pouvez activer la prise en charge de Directory Proxy Server du contrôle du tri côté serveur en ajoutant server-side-sorting à la liste de contrôles LDAP autorisés et spécifiés dans 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 |
Notez que vous devez répéter les paramètres existants. Sinon, seul le contrôle du 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ées MYNAME.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 JDBCimpliquant trop de relations (N:N) entre les tables de la base de données JDBC.
Les instances Directory Proxy Server avec un DN multioctets créées à l'aide de DSCC, ne démarrent pas sous Linux.
Lorsque vous utilisez une Service Management 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.
Pour résoudre ce problème, vous pouvez, si la commande dsadm enable service n'a pas déjà été appelée, ajouter à /opt/SUNWdsee/ds6/install/tmpl_smf.manifest les lignes portant le signe + suivantes :
... restart_on="none" type="service"> <service_fmri value="svc:/network/initial:default"/> </dependency> + <dependency name="nameservice" grouping="require_all" \ + restart_on="none" type="service"> + <service_fmri value="svc:/milestone/name-services"/> + </dependency> <exec_method type="method" name="start" exec="%%%INSTALL_PATH%%%/bin/dsadm start --exec %{sunds/path}"... |
Lorsque vous utilisez un utilitaire de gestion des services (SMF, Service Management Facility) dans Solaris 10 pour activer une instance de serveur, l'instance ne démarre pas toujours lorsque vous redémarrez le système.
Pour résoudre ce problème, vous pouvez, si la commande dsadm enable service n'a pas déjà été appelée, ajouter à /opt/SUNWdsee/ds6/install/tmpl_smf.manifest les lignes portant le signe + suivantes :
... restart_on="none" type="service"> <service_fmri value="svc:/network/initial:default"/> </dependency> + <dependency name="nameservice" grouping="require_all" \ + restart_on="none" type="service"> + <service_fmri value="svc:/milestone/name-services"/> + </dependency> <exec_method type="method" name="start" exec="%%%INSTALL_PATH%%%/bin/dsadm start --exec %{sunds/path}"... |
Si la commande dsadm enable service a déjà été appelée, procédez comme suit :
Créez un fichier contenant les données suivantes :
select dps addpg nameservice dependency setprop nameservice/grouping = astring: require_all setprop nameservice/restart_on = astring: none setprop nameservice/type = astring: service setprop nameservice/entities = fmri: "svc:/milestone/name-services" |
Exécutez la commande suivante sur le fichier :
svccfg -f file |
Si certaines instances sont en maintenance, exécutez les commandes suivantes :
svcadm clear svc:/application/sun/dps:dps-{instancepath} |
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 des entrées doubles sont présentes dans la table RDBMS et correspondent à un modèle de DN trouvé dans la classe d'objet JDBC, alors les noeuds doubles de sous-arborescence (non terminal) sont renvoyés par Directory Proxy Server lorsque la recherche est réalisée en fonction de la vue de données JDBC. Par exemple, s'il y a un modèle DN ou dans une classe d'objet JDBC et qu'il existe des entrées doubles (par exemple, sales) dans la colonne RDBMS mappée pour l'attribut JDBC ou, alors les résultats de recherche peuvent contenir des noeuds doubles tels que ou=sales.
Pour éviter ce problème, procédez comme suit :
Créez une vue RDBMS en prenant les valeurs dans la table contenant la colonne mappée pour l'attribut ou JDBC, de telles sorte qu'il n'y ait pas d'entrée double.
Remplacez le nom de la table RDBMS par le nom de vue RDBMS dans la classe d'objet JDBC avec le modèle de DN ou. Cette approche a une limite : étant donné que les vues RDBMS sont en lecture seule, aucune valeur pour l'attribut JDBC ou ne peut être ajoutée via Directory Proxy Server.
Dans DSCC, dans les options More View (plus d'informations) d'une instance, la date qui s'affiche sous les onglets des journaux d'accès, d'erreur et d'audit n'est pas localisée.
Dans DSCC, configuré à l'aide de Tomcat server, les titres des fenêtres contextuelles de l'aide et de la version affichent des 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, invitant à confirmer l'arrêt ou l'annulation de l'enregistrement des serveurs, contiennent des guillemets doubles en français.