I.19 Divers

Sauvegarde d'un conteneur

Lors de l'exécution de l'utilitaire ndsbackup pour sauvegarder un conteneur renfermant un grand nombre d'objets (de l'ordre d'un million), il se peut que vous deviez attendre un certain temps pour obtenir la liste des objets du conteneur et démarrer leur sauvegarde individuelle.

Connexions eDirectory répétées

Des connexions eDirectory répétées peuvent consumer la mémoire disponible. Pour résoudre ce problème, désactivez l'attribut Login Update (Mise à jour de la connexion) à l'aide d'iMonitor.

Activation des statistiques Event System

Les statistiques relatives à l'heure sont conservées pour chaque événement généré et sont consommées dans eDirectory. Ces informations sont utiles pour la résolution des problèmes de consommation d'événements. Ces statistiques ne sont pas nécessaires au fonctionnement normal de l'annuaire ; elles sont par conséquent désactivées pour des raisons de performances. Les statistiques des événements peuvent être activées lors de l'exécution à l'aide des paramètres de configuration avancés d'iMonitor.

Pour afficher les statistiques des événements, définissez le paramètre ENABLE_EVENT_STATISTICSe t redémarrez le serveur. Il s'agit d'un paramètre de configuration permanente.

Suivi des problèmes de mémoire endommagée sous Linux

Sur les plates-formes Linux, eDirectory utilise Google malloc (libtcmalloc) en tant qu'allocateur de mémoire par défaut.

Pour suivre les problèmes de mémoire endommagée, définissez la variable d'environnement MALLOC_CHECK_ dans le script de démarrage ndsd. Le script de démarrage recherche cette variable. Si elle est définie, la variable système malloc par défaut est utilisée ; dans le cas contraire, la variable libtcmalloc est chargée.

Paramètres MALLOC_CHECK dans ndsd

  • Si le paramètre MALLOC_CHECK_ est défini sur 0, toute détection de segment de mémoire altéré est ignorée en mode silencieux.

  • Si le paramètre MALLOC_CHECK_ est défini sur 2, la commande d'abandon est appelée immédiatement.

    Cela permet d'identifier la cause réelle de l'altération de la mémoire dès les premières phases du processus (cette altération est plus compliquée à identifier dans les phases ultérieures).

Connexion TCP non terminée après une déconnexion anormale

Il arrive parfois que le serveur OES Linux ne parvienne pas à détecter un hôte client qui s'est terminé brusquement en raison d'une défaillance du poste de travail ou d'une panne de courant. Toutefois, la connexion reste active pendant le timeout par défaut (environ 12 à 15 minutes) avant la désactivation de la connexion. Si vous avez défini les connexions simultanées sur 1, il est recommandé de mettre fin à la connexion manuellement ou de patienter pendant toute la durée du timeout avant d'établir une nouvelle connexion. Cette situation se produit lorsque le processus Watchdog ne parvient pas à terminer la connexion correctement. Par conséquent, si les connexions simultanées sont définies sur 1 et que la connexion n'est pas arrêtée par le processus Watchdog, les utilisateurs ne peuvent pas se connecter. Le noyau Linux fournit trois paramètres qui permettent de modifier le mode de fonctionnement des sondes keepalive du côté serveur. Utilisez ces paramètres pour mettre en œuvre une solution de contournement au niveau TCP.

Ces paramètres sont disponibles dans le répertoire /proc/sys/net/ipv4/.

  • tcp_keepalive_time : détermine la fréquence d'envoi des paquets TCP keepalive afin de maintenir la connexion si elle n'est pas utilisée actuellement. Cette valeur n'est utilisée que lorsque le paramètre keepalive est activé.

    Le paramètre tcp_keepalive_time utilise une valeur d'entier en secondes. La valeur par défaut est de 7 200 secondes, soit 2 heures. Ce processus convient à la plupart des hôtes et ne nécessite pas de nombreuses ressources réseau. Si vous définissez ce paramètre sur une valeur faible, il utilise des ressources réseau pour un trafic inutile.

  • tcp_keepalive_probes : détermine la fréquence d'envoi des sondes TCP keepalive avant qu'une connexion soit considérée comme étant interrompue.

    Le paramètre tcp_keepalive_probes utilise une valeur d'entier inférieure à 50 (recommandation), en fonction des valeurs tcp_keepalive_time et tcp_keepalive_interval. La valeur par défaut consiste à définir 9 sondes avant que l'application soit informée de l'interruption de la connexion.

  • tcp_keepalive_intvl : détermine la durée de réponse pour chaque sonde keepalive. Cette valeur est importante pour calculer la durée qui doit s'écouler avant que la sonde keepalive considère la connexion comme terminée.

    Le paramètre tcp_keepalive_intvl utilise une valeur d'entier, la valeur par défaut étant de 75 secondes. Par conséquent, le processus global incluant 9 sondes de 75 secondes prend environ 11 minutes. Les valeurs par défaut des variables tcp_keepalive_probes et tcp_keepalive_intvl permettent d'évaluer la durée par défaut avant que la connexion soit considérée comme ayant abouti à un timeout en raison des sondes keepalive.

Modifiez ces trois paramètres de manière à ce qu'ils résolvent le problème sans pour autant générer de grandes quantités de trafic supplémentaire. Par exemple, vous pouvez effectuer la modification suivante (avec une durée de détection de 3 minutes) :

  • tcp_keepalive_time set -120

  • tcp_keepalive_probes - 3

  • tcp_keepalive_intvl - 20

REMARQUE :Soyez prudent lorsque vous modifiez les valeurs de ces paramètres et évitez de choisir des connexions déjà valides.

Les paramètres prennent effet dès que les fichiers sont modifiés. Vous devez redémarrer tous les services. Toutefois, les paramètres ne sont valides que pour la session en cours. Une fois que le serveur est redémarré, les paramètres reprennent leur valeur par défaut.

Pour que le paramétrage soit permanent (même après un redémarrage), effectuez les opérations suivantes :

Ajoutez les entrées suivantes dans /etc/sysctl.conf.

  • net.ipv4.tcp_keepalive_time=120

  • net.ipv4.tcp_keepalive_probes=3

  • net.ipv4.tcp_keepalive_intvl=20

Nous vous recommandons d'utiliser ces paramètres que si tous les clients et serveurs sont connectés par l'intermédiaire d'un réseau local.

L'erreur NDS, échec du système (-632) se produit lors d'une recherche ldapsearch d'objets Utilisateur

Importez les objets Utilisateur avec le mot de passe simple, puis activez le mot de passe universel du conteneur dans lequel les objets Utilisateur sont importés. Arrêtez le serveur DS et définissez l'environnement comme suit : NDSD_TRY_NMASLOGIN_FIRST=tree. Redémarrez ensuite le serveur DS. Lorsque vous effectuez une recherche ldapsearch des objets Utilisateur importés avec le mot de passe simple, l'erreur suivante s'affiche :

ldap_bind: Unknown error,  additional info: NDS error: system failure (-632)

Pour la résoudre, définissez la connexion par mot de passe simple comme séquence de connexion par défaut pour le conteneur dans lequel les objets Utilisateur sont importés avant de rechercher ces derniers via ldapsearch.

Lorsque LDAP demande à NMAS de connecter un utilisateur, NMAS utilise la séquence de connexion par défaut. Si vous ne spécifiez pas de séquence de connexion par défaut pour ces utilisateurs, NMAS utilisera la séquence NDS. Si ces utilisateurs n'ont pas reçu de mot de passe NDS lorsque vous les avez importés, la séquence NDS ne fonctionnera pas. Si vous activez le mot de passe universel et que l'utilisateur se connecte avec le mot de passe simple, ce dernier sera synchronisé avec le mot de passe NDS et le mot de passe universel.

Désactivation de SecretStore on Linux

Un administrateur eDirectory peut désactiver SecretStore sous Linux à l'aide des processus suivants :

  1. Accédez au répertoire nds-modules, puis renommez ou déplacez les modules SecretStore suivants :

    • libsss.so
    • libssncp.so
    • libssldp.so
  2. Redémarrez le serveur.

Désactivation de SecretStore sous Windows

Un administrateur eDirectory peut désactiver SecretStore sous Windows à l'aide des processus suivants :

  1. Accédez au répertoire novell\nds, puis renommez ou déplacez les modules SecretStore suivants :

    • lsss.dll
    • sss.dlm
    • ssncp.dlm
    • ssldp.dlm
  2. Redémarrez le serveur.

Emplacement du fichier de configuration dsbk

Le fichier dsbk.conf est situé dans le répertoire /etc et non à l'emplacement réservé à l'instance spécifique d'eDirectory.

Échec d'ouverture du fichier de consignation des erreurs par ldif2dib lorsque le chemin du répertoire de la DIB est personnalisé

Ldif2dib ne parvient pas à ouvrir le fichier de consignation par défaut ldif2dib.log lorsque le répertoire dib a été déplacé vers un emplacement personnalisé.

Pour éviter ce problème, indiquez explicitement l'emplacement du fichier de consignation à l'aide du paramètre -b.

Échec de démarrage de ndsd après un crash système

Dans certains cas, les services eDirectory (ndsd) ne redémarrent pas après un crash système ou une panne d'alimentation. Pour redémarrer eDirectory, procédez comme suit :

  1. Supprimez le fichier/var/opt/novell/eDirectory/data/ndsd.pid.

  2. Entrez la commande /etc/init.d/ndsd start.

N'exécutez pas DSTrace avec toutes les balises activées sur les ordinateurs Linux

Lorsque toutes les balises sont activées, veillez à ne pas exécuter DSTrace sur les éléments suivants :

  • Un système chargé en mode journal : il à tendance à augmenter la mémoire ndsd.

  • Des serveurs en mode en ligne : il bloque ndsd.

Non-compatibilité RFC de LDAP pour les requêtes de recherche anonymes

Si un client effectue une opération de recherche non authentifiée alors que les liaisons anonymes sont désactivées, le serveur LDAP répond avec le résultat de liaison indiquant une authentification inappropriée (operationsError), au lieu du résultat de la recherche.

Dépannage des ports à l'aide des instances personnalisées d'eDirectory 9.0

Dans eDirectory 9.0, si vous configurez une nouvelle instance dans un emplacement personnalisé alors que le serveur d'instance par défaut est arrêté, elle utilise les ports de l'instance par défaut. L'instance par défaut ne répond pas, car ses ports sont affectés à l'instance dans l'emplacement personnalisé.

Suivez la procédure présentée à la section Dépannage des ports à l'aide des instances personnalisées d'eDirectory 8.8 avant de redémarrer l'hôte.

Redémarrage de l'hôte

Seule l'instance par défaut créée à l'aide des fichiers binaires d'instance par défaut se lance au redémarrage.

Vous pouvez définir les chemins et utiliser ndsmanage pour exécuter les autres instances.

ndsd n'écoute pas sur l'adresse de boucle d'un port NCP donné

En présence de plusieurs instances d'eDirectory, la seconde instance et les suivantes essaient d'écouter sur le port par défaut 524 au lieu du port NCP™ de l'adresse de boucle.

Pour résoudre ce problème, définissez le paramètre n4u.server.tcp-port de la seconde instance sur le port sur lequel elle est censée écouter. Le paramètre n4u.server.tcp-port se trouve dans le fichier nds.conf.

IMPORTANT :toutes les instances d'eDirectory doivent être opérationnelles avant de procéder à la mise à niveau vers eDirectory 9.0.

OID de transaction LDAP

Dans le cadre de la prise en charge des transactions LDAP, les attributs supportedGroupingTypes et transactionGroupingType sont identiques (2.16.840.1.113719.1.27.103.7).

Erreurs -5871 et -5875 dans la trace LDAP

Les erreurs -5871 et -5875 dans la trace LDAP sont généralement provoquées par le fait que la fermeture du client LDAP est forcée, sans annulation de la liaison. Par conséquent, ces erreurs ne sont pas préoccupantes et peuvent être ignorées. Pour plus d'informations sur ces erreurs, reportez-au site Web des codes d'erreur NetIQ.

NDSCons génère une erreur -625 si une arborescence est renommée

Si vous renommez l'arborescence sur le serveur primaire et arrêtez l'hôte DHost sur le serveur secondaire, l'utilitaire NDSCons génère sur le serveur secondaire un message d'erreur -625 indiquant un échec du transport, tandis que l'hôte DHost continue à fonctionner sur le serveur primaire et le serveur secondaire. L'erreur se produit car NDSCons s'exécutait sur le serveur secondaire lorsque l'arborescence a été renommée sur le serveur primaire. NDSCons fonctionne correctement si vous le fermez, puis le redémarrez.

L'écoute sur plusieurs cartes réseau ralentit les performances ldapsearch

Pour éviter ce problème :

Désactivez dans le fichier de configuration les cartes réseau qui ralentissent les performances ldapsearch.

ou

Activez l'évaluation du renvoi avancé (ARC) à l'aide de la commande set NDSTRACE =!ARC1 dans DSTrace.

Impossible de limiter le nombre d'utilisateurs simultanés sur les plates-formes Linux

Vous ne pouvez pas limiter le nombre de connexions simultanées sur les plates-formes Linux. Pour revenir au comportement antérieur (vérification stricte sur la base du port), définissez le paramètre suivant dans le fichier nds.conf.

n4u.server.mask-port-number=0

Échec de l'arrêt de ndsd lié au protocole SLP

Si aucun agent Annuaire SLP n'est configuré sur votre réseau, la recherche de services qui utilisent le protocole SLP peut prendre plus de temps. Lors de l'arrêt d'eDirectory, ndsd essaie d'effectuer des opérations à l'aide du protocole SLP. Ces tentatives peuvent être plus longues que le délai normal autorisé par le script d'initialisation, ce qui entraîne un arrêt forcé.

Pour résoudre ce problème :

  1. Créez un fichier vide avec le nom hosts.nds dans le répertoire de configuration. Le répertoire de configuration d'un serveur peut être obtenu en exécutant la commande suivante : ndsconfig get n4u.server.confdir

  2. Définissez une variable d'environnement NDS_USESLP sur 0 en spécifiant les informations suivantes : export NDS_USESLP=0 in /opt/novell/eDirectory/sbin/pre_ndsd_start

  3. Redémarrez eDirectory.

Redémarrage du module NLDAP sous Windows

Après avoir arrêté NLDAP, vous devez redémarrer le serveur pour charger ce processus.

SecretStore sur LDAP

La fonctionnalité SecretStore de NetIQ ne fonctionne pas sur LDAP. Pour résoudre ce problème, vous devez rafraîchir LDAP via iManager.

Impossible de modifier la phrase secrète après le déverrouillage de SecretStore

SecretStore se verrouille si vous tentez de récupérer un mot de passe oublié en vous connectant avec les références de l'utilisateur et une phrase secrète erronée. Vous pouvez déverrouiller SecretStore à l'aide de droits d'administrateur, et le client NetIQ SecureLogin vous permet de vous connecter sans phrase secrète. Si vous tentez de modifier la phrase secrète, la connexion échoue et génère une erreur.

Réinitialisation des références de l'utilisateur lors de leur modification via SecretStore

Lorsque vous essayez d'enregistrer les nouvelles références dans SecretStore à l'aide du plug-in iManager, une colonne de références vierge s'affiche car iManager n'est pas parvenu à enregistrer les modifications.

Vous ne pouvez modifier les références à l'aide du plug-in iManager de SecretStore que si vous êtes connecté en tant qu'utilisateur et non en tant qu'administrateur.

La création d'un ensemble de références différent avec le même nom d'utilisateur remplace l'ensemble de références précédent

Lorsque vous enregistrez un autre ensemble de références, SecretStore ne parvient pas à conserver le premier ensemble et seul le dernier ensemble de références est visible.

Vous ne pouvez modifier les références à l'aide du plug-in iManager de SecretStore que si vous êtes connecté en tant qu'utilisateur et non en tant qu'administrateur.

Le serveur HTTP utilise le certificat SSL CertificateIP même après son expiration

Si vous effectuez la mise à niveau vers eDirectory 9.0 à partir d'une version antérieure, le serveur HTTP continue d'utiliser le certificat SSL CertificateIP même après son expiration. Cela est dû au fait qu'eDirectory 8.8 SP8 ne conserve pas le certificat SSL CertificateIP et n'en réémet pas même si le certificat SSL CertificateIP arrive à expiration ou est supprimé.

Par conséquent, si le certificat SSL CertificateIP arrive à expiration ou est supprimé, vous devez en créer un manuellement à l'aide du plug-in iManager ou utiliser à la place le certificat SSL CertificateDNS.

eDirectory contient deux fichiers binaires ldapsearch différents

Il existe deux ensembles d'outils LDAP (ldapadd, ldapconfig, ldapdelete, ldapmodify, ldapmodrdn et ldapsearch) sur un système SLES (ainsi que le RPM openldap2-client) équipé d'eDirectory : l'un dans le dossier /usr/bin, installé par le système d'exploitation SLES, et l'autre dans le dossier /opt/novell/eDirectory/bin, installé par eDirectory.

Bien que les fonctionnalités de base des deux ensembles d'outils LDAP soient identiques, chacun de ces ensembles ajoute ses propres fonctionnalités. Selon les paramètres de chemin d'accès dans la variable d'environnement PATH, l'ensemble d'outils en cours d'utilisation peut être différent et donc les fonctionnalités disponibles peuvent également varier.