Les utilisateurs ajoutés en utilisant es-config -u <nomutilisateur> et es-config -l <nomutilisateur> -M <nommodule> -z catégorieutilisateursnmp sont automatiquement supprimés au redémarrage de l'agent. Ce problème se produit pour les modules tels que Lecteur de noyau simple et Statistiques agent.
Solution : Ajoutez les utilisateurs manuellement en ajoutant l'entrée tranche:objet=valeur_obj au fichier nommodule.dat présent dans le répertoire /var/opt/SUNWsymon/cfg.
Lorsque les services de Sun Management Center tentent de s'activer après le redémarrage du système, ils se heurtent au service cryptosvc et au démon kcfd qui les obligent à consigner des erreurs dans /var/adm/messages.
Il est possible que les messages d'erreur suivants s'affichent :
Oct 3 18:16:09 atqa32 lomv: 10/3/2005 23:16:9 GMT LOM time reference |
Oct 3 18:16:13 atqa32 kcfd[106]: kcfd: elfsign_hash_mem_resident failed to hash for /usr/lib/security/pkcs11_softtoken.so: sign or verify of ELF object failed |
Oct 3 18:16:13 atqa32 kcfd[106]: kcfd: elfsign_hash_mem_resident failed to hash for /usr/lib/security/pkcs11_softtoken.so: sign or verify of ELF object failed |
Oct 3 18:16:13 atqa32 esd[1949]: libpkcs11: /usr/lib/security/pkcs11_softtoken.so signature verification failed. See cryptoadm(1M). Skipping this plug-in. |
Oct 3 18:16:13 atqa32 esd[1949]: libpkcs11: /usr/lib/security/pkcs11_softtoken.so signature verification failed. See cryptoadm(1M). Skipping this plug-in. |
Oct 3 18:16:13 atqa32 cfgserver[1949]: syslog Oct 03 18:16:13 cfgserver Unable to get pkcs session. Can not initialize snmp engine |
Oct 3 18:16:13 atqa32 cfgserver[1949]: syslog Oct 03 18:16:13 cfgserver *** terminating execution *** |
Solution : Après le redémarrage du système, arrêtez tous les services de Sun Management Center en utilisant es-stop -A. Lorsque le système redémarre, tous les services sont activés sans erreurs.
Sur les systèmes Solaris 10, les services de Sun Management Center sont arrêtés pendant l'initialisation.
Il est possible que les messages d'erreur suivants s'affichent :
Oct 12 09:19:59 atqa33 metadata[6245]: [ID 985908 daemon.alert] syslog |
Oct 12 09:19:59 metadata {received software termination signal} |
Oct 12 09:19:59 atqa33 metadata[6245]: [ID 122441 daemon.alert] syslog |
Oct 12 09:19:59 metadata *** terminating execution *** |
Oct 12 09:19:59 atqa33 event[27957]: [ID 652029 daemon.alert] syslog |
Oct 12 09:19:59 event {received software termination signal} |
Oct 12 09:19:59 atqa33 event[27957]: [ID 721961 daemon.alert] syslog |
Oct 12 09:19:59 event *** terminating execution *** |
Oct 12 09:19:59 atqa33 agent[28990]: [ID 651061 daemon.alert] syslog |
Oct 12 09:19:59 agent {received software termination signal} |
Oct 12 09:19:59 atqa33 agent[28990]: [ID 891934 daemon.alert] syslog |
Oct 12 09:19:59 agent *** terminating execution *** |
Solution : Avant de redémarrer le système, arrêtez les services en utilisant es-stop -A. Dans ce cas, aucun message d'erreur n'est consigné dans le fichier syslog.
La base de données de Sun Management Center peut contenir des entrées d'hôte en double lorsque l'un des scénarios suivants se produit :
L'adresse IP est changée après l'installation.
Le nom de l'hôte est changé après l'installation.
Le nom de l'hôte a plusieurs alias d'hôte.
Solution :
Suivez les recommandations ci-après pour éviter les entrées en double :
N'utilisez pas d'objets composites.
N'utilisez pas la détection de la plage d'adresses IP ou du sous-réseau.
Assurez-vous que le nom de l'hôte est disponible dans le fichier /var/opt/SUNWsymon/cfg/domain-config.x sur la machine agent avant de l'ajouter à la topologie.
Si vous supprimez le groupe esadm des ACL de l'agent puis ajoutez des utilisateurs individuels à l'ACL de l'agent, l'utilisateur n'est pas automatiquement ajouté à l'ACL du module Server Support. Étant donné qu'il n'est pas mis à jour avec l'utilisateur, le module Server Support ne permet pas l'activation ou la désactivation de Performance Reporting Manager. Le message suivant s'affiche :
Unable to enable/disable PRM data collection on an agent with new user |
Solution : Ajoutez le groupe esadm à l'ACL de l'agent puis ajoutez les utilisateurs individuels au groupe esadm.
L'interface graphique Gérer les travaux indique Failed (échec) pour une opération de mise à jour d'agent réussie. Lorsqu'une opération de mise à jour d'agent est effectuée en utilisant l'IG (interface graphique) Gérer les travaux, l'opération est indiquée comme ayant réussi ou échoué à deux niveaux différents.
État récapitulatif : Si l'opération concernait plusieurs hôtes et a échoué sur ne serait-ce qu'un de ces hôtes, le statut de l'ensemble du Travail est indiqué comme étant Failed.
État individuel : En cliquant sur le bouton Afficher les journaux, vous pouvez visualiser le statut de l'opération sur un hôte individuel.
Le statut individuel est basé sur les informations de statut rapportées par l'hôte au serveur par le biais de la communication SNMP dans le sens agent-vers-serveur. Le statut risque d'être inexact dans les conditions suivantes :
La mise à niveau a réussi mais le port SNMP de l'agent a été modifié suite à la mise à niveau de l'agent dans le cadre de laquelle le logiciel a été réinstallé et les paramètres reconfigurés.
La mise à niveau a réussi mais la demande SNMP a dépassé à cause de différents facteurs le délai imparti et le statut n'a pas été rapporté avec succès.
La mise à jour a réussi mais le processus a pris plus que le délai de 30 minutes fixé par le serveur pour chaque hôte individuel. Résultat, le thread serveur qui attendait la mise à jour du statut s'est terminé avant que le rapport de statut n'ait été commencé côté agent.
Solution : Utilisez l'onglet Afficher les journaux de la fenêtre Détails de l'hôte pour voir InstallServer.log sur l'hôte serveur. Les détails de l'opération sont disponibles dans le fichier /var/opt/SUNWsymon/install/agent-update.log de chaque hôte cible sur lequel l'opération est effectuée.
Solution 1 : Procédez comme indiqué ci-dessous.
Minimisez l'écran de connexion et restaurez-le.
Tapez l'entrée dans le champ contenant le curseur actif.
Positionnez le curseur dans le champ suivant.
Minimisez l'écran de connexion et restaurez-le.
Tapez l'entrée dans ce champ.
Solution 2 : Utilisez JDK 1.4 ou des versions compatibles.
Ces messages d'erreur s'affichent uniquement pour la valeur Headspread du module État de santé.
Il est possible que les messages d'erreur suivants s'affichent :
error Oct 14 15:20:49 agent setNodeValue failed: cmd=setNodeValue 0 1 bob39266, error=setNodeValueLeafScalar: Failed to set new value |
error Oct 14 15:20:49 agent ClassMIBNode:setNodeValue 0 1 bob39266 - . iso.org.dod.internet.private.enterprises.sun.prod.sunsymon.agent.modules. healthMonitor.RAM.memory.handspread |
error Oct 14 15:20:49 agent ClassMIBNode:setNodeValue 0 1 bob39266 - setNodeValueLeafScalar: Failed to set new value warning Oct 14 15:21:32 agent could not get value of RAM.memory.handspread in rule rhltm005 for node ram-rule in module health-monitor |
Solution : Ignorez ces messages d'erreur.
Seuls les packages en langue anglaise sont présents dans l'image de l'agent créée par la commande es-makeagent. Par conséquent, toute installation effectuée à partir d'une telle image ne prendra pas en charge la localisation.
Solution : Utilisez es-inst ou mise à jour agent.
Lorsqu'un agent de zone est utilisé en tant qu'agent de base, le module Propagation de la configuration des modules (MCP) ne fonctionne pas avec les agents de zone. La propagation des données de configuration de MCP à un agent de zone échoue également.
Il est possible que les messages d'erreur suivants s'affichent :
Les messages d'erreur suivants sont enregistrés dans taskreq.log lorsque la propagation MCP avec l'agent de zone en tant que base échoue.
Http error : HTTP/1.1 404 File not found: /var/opt/SUNWsymon/mcp/procmon-zoneagentbase/index.xml |
Les messages d'erreur suivants sont enregistrés dans taskreq.log lorsque la propagation MCP vers l'agent de zone échoue.
Operation mcp has failed on target:hostname:1161 Exception was thrown: /usr/bin/nawk: can't open file /var/opt/SUNWsymon/cfg/base-modules-d.dat.MCP |
Solution : Éditez le fichier /var/opt/SUNWsymon/zone-scripts-d.dat de l'agent de zone de façon à inclure les noms de scripts es-mcp-get et es-mcp-put.
Les services de Sun Management Center ne redémarrent pas et le script es-config n'est pas abandonné.
Solution : Au lieu d'utiliser es-config, éditez les fichiers javaserver.properties et javaconsole.properties pour configurer la plage des ports de pare-feu entre le serveur et la console.
Mettez à jour les lignes suivantes dans le fichier /var/opt/SUNWsymon/cfg/javaserver.properties avec les informations relatives aux ports minimum et maximum.
sunmc.server.console.firewall.MinPort=2000 |
sunmc.server.console.firewall.MaxPort=6000 |
Mettez à jour les lignes suivantes dans le fichier /var/opt/SUNWsymon/cfg/javaconsole.properties avec les informations relatives aux ports minimum et maximum.
sunmc.server.console.firewall.MinPort=45000 |
sunmc.server.console.firewall.MaxPort=48000 |
Lorsque vous créez une tâche pour le regroupement/MCP, le module Service Management Framework (SMF) n'est pas disponible pour la sélection.
Solution : Si le serveur est un système Solaris 10, effectuez les étapes suivantes :
Copiez les fichiers suivants sur le serveur.
# cp /opt/SUNWsymon/modules/cfg/smf-* /opt/SUNWsymon/mdr/modules/cfg/
Si le serveur n'est pas un système Solaris 10, copiez ces fichiers d'un système Solaris 10 (agent/serveur).
Redémarrez les services de Sun Management Center.
/opt/SUNWsymon/sbin/es-stop -A
/opt/SUNWsymon/sbin/es-start -A
Tapez les lignes suivantes pour assurer qu'une désinstallation se déroule sans problème.
# installf SUNWessmn /opt/SUNWsymon/mdr/modules/cfg/smf-d.prc
# installf SUNWessmn /opt/SUNWsymon/mdr/modules/cfg/smf-d.x
# installf SUNWessmn /opt/SUNWsymon/mdr/modules/cfg/smf-m.x
# installf SUNWessmn /opt/SUNWsymon/mdr/modules/cfg/smf-models-d.x
Démarrez la console et allez à Outils -> Découvrir des objets. Cliquez sur le bouton Ajouter une requête et indiquez la plage d'adresses IP dans les champs des adresses IP de début et de fin. Cochez les deux ports, par exemple 1161/ 1161(port de l'agent). Sélectionnez l'onglet des filtres puis le critère de filtrages, ici “Types de plates-formes” et cochez le bouton “Inclure” pour inclure les objets et lancer la requête. Lorsque la requête réussit, aucun hôte n'a été ajouté. Cela signifie que les hôtes ne sont pas identifiés comme des types de plates-formes donnés dans le nuage de détection. Lorsque le bouton “Exclure” est coché et la plage d'adresses IP indiquée, il inclut les objets dans le nuage de détection.
Solution : Aucune.