Cette annexe récapitule les outils, les conseils et les techniques permettant de procéder au dépannage des problèmes dans ACSLS. Les ressources de dépannage incluent des fichiers journaux, des points d'observation clés et d'analyses de diagnostics.
Le journal des événements ACSLS est la première étape permettant de recueillir des informations utiles quand vous rencontrez des problèmes avec vos opérations de bibliothèque. Ce journal contient des informations sur les événements de bibliothèque, les changements d'état et les erreurs. Tous les sous-composants dans ACSLS signalent les événements à acsss_event.log en envoyant des messages à un processus appelé le journaliseur des événements. Le journal des événements standard, qui est créé automatiquement lors de l'installation d'ACSLS, se trouve dans le fichier $ACS_HOME/log/acsss_event.log, où $ACS_HOME correspond généralement à /export/home/ACSSS/.
Les événements consignés incluent :
Evénements significatifs
Les événements significatifs sont des événements normaux qui peuvent vous aider à gérer la bibliothèque. Par exemple, les événements sont consignés lors de l'initiation ou de la fin d'un audit, de la modification de l'état d'un périphérique ou de l'ouverture ou de la fermeture d'un CAP.
Erreurs de bibliothèque
Les erreurs de bibliothèque sont des événements pour lesquels des erreurs logicielles et matérielles fatales et non fatales sont consignées. En voici quelques exemples : défaillances du LSM ; problèmes liés aux cartouches ; erreurs de base de données ; défaillances du processus et défaillances des communications de bibliothèque.
Chaque message du journal des événements inclut un horodatage, le nom du composant signalant le message, ainsi qu'une description de l'événement. Pour obtenir une explication complète de chaque message, consultez le manuel des messages ACSLS.
Une fenêtre de la console ACSLS affiche la fin du journal des événements. Vous pouvez générer un affichage similaire à partir d'une fenêtre du shell.
En tant qu'utilisateur acsss, exécutez la commande suivante :
acs_tail $ACS_HOME/log/acsss_event.log
Pour afficher l'intégralité du journal des événements, utilisez un éditeur de texte, comme vi, qui permet de parcourir le journal, de rechercher des erreurs spécifiques ou de suivre des séquences d'événements spécifiques.
ACSLS continue à envoyer des messages au journal acsss_event.log.
Lorsque ce fichier atteint la taille limite (500 Ko par défaut), il est renommé event0.log et enregistré dans le répertoire des journaux. Un nouveau fichier journal acsss_event.log prend donc la suite.
Lorsque le journal acsss_event.log atteint de nouveau la taille limite, le fichier event0.log est renommé event1.log, puis le journal acsss_event.log est renommé event0.log.
Ce processus est répété pour tous les fichiers journaux dont la conservation a été configurée.
Par défaut, neuf fichiers journaux des événements sont conservés dans le répertoire de journaux. Pour chaque seuil suivant, le fichier le plus ancien est supprimé et tous les fichiers restants sont renommés séquentiellement.
Vous pouvez configurer la taille maximale du journal acsss_event.log, ainsi que le nombre de fichiers journaux à conserver à l'aide de acsss_config, Option 2. Reportez-vous à Définition des variables de réglage du CSI.
L'outil de diagnostic, greplog, vous permet de rechercher des mots-clés dans tous les fichiers journaux des événements. D'une utilisation très similaire à l'utilitaire grep UNIX, greplog renvoie l'intégralité du message de journal associé à l'expression de mots-clés donnée. Vous pouvez ainsi voir l'horodatage du message, le numéro du message et le texte fonctionnel relatif à chaque message contenant cette expression.
-i indique à greplog d'ignorer la casse de l'expression du modèle de recherche.
-v indique à greplog de filtrer tous les messages contenant l'expression et d'afficher toutes les entrées dans le fichier journal. Les entrées correspondant à l'expression du modèle de recherche constituent des exceptions.
Modèle de recherche : il s'agit des critères de rechercher à utiliser.
file_1 file_2 ... file_n
L'outil greplog accepte plusieurs paramètres de fichier et expressions de caractères génériques dans la liste des fichiers.
Pour afficher toutes les occurrences au sein d'une séquence d'événements, utilisez le numéro de séquence.
greplog 1392 acsss_event.log
Pour rechercher tous les messages sur le volume CART89 dans le journal des événements :
greplog CART89 acsss_event.log
Pour rechercher tous les messages sur les montages de bandes dans toutes les copies archivées du journal des événements :
greplog -i mount event*.log
Le journal acsss_event.log contient tous les messages portant sur tous les aspects des processus en cours d'exécution sur ACSLS. Cependant, des fichiers supplémentaires présents dans le répertoire des journaux contiennent des informations d'état sur les utilitaires externes, comme les utilitaires d'installation et de sauvegarde et de restauration.
acsss.pid : stocke l'ID de processus du acsss_daemon en cours d'exécution.
acsss_config.log : contient un récapitulatif de chaque configuration de bibliothèque.
acsss_config_event.log : contient des messages d'événement qui ont été transmis par la routine acsss_config.
bdb_event.log : contient des messages d'événement qui ont été transmis par l'utilitaire de sauvegarde de base de données, bdb.acsss.
cron_event.log : contient des messages qui ont été transmis par les utilitaires cron. Pour afficher la planification des utilitaires Cron, exécutez la commande crontab -l.
acsls_start.log : contient des messages de démarrage et d'arrêt impliquant le service acsls.
di_trace.log : contient les informations de trace relatives à l'interface de base de données.
ejectingLogs : répertoire contenant des informations récapitulatives des opérations ejecting.sh des dix derniers jours.
install.log : contient des messages d'événement transmis pendant l'exécution du script d'installation, install.sh.
ipc_trace.log : contient les informations de trace relatives aux communications interprocessus ACSLS.
rdb_event.log : contient des messages d'événement transmis par l'utilitaire de restauration de base de données, rdb.acsss.
timed_bkup.sh.log : contient des messages d'événement liés à l'utilitaire de sauvegarde de base de données automatique.
Selon le traçage spécifique que vous avez activé sur votre système, le répertoire de journaux peut contenir des journaux de traçage supplémentaires. Ces journaux peuvent être les suivants :
acsss_stats.log : le traçage des statistiques de volume est activé par acsss_config.
acsss_trace.log : le traçage client-serveur est activé à la demande du personnel du support logiciel.
acslh.log : le traçage de la LMU hôte est activé à la demande du personnel du support logiciel.
scsilh.log, mchangerX.log, scsipkt.log : tous ces journaux contiennent les traces des communications SCSI vers une bibliothèque connectée via SCSI. Ils sont activés à la demande du support logiciel.
Les journaux de traces qui sont activés à la demande du support logiciel peuvent croître très rapidement. Ces journaux doivent être contrôlés et gérés afin de limiter les problèmes de saturation de disque.
L'utilitaire monitor.sh sert à effectuer des services d'archivage et de gestion des journaux automatiques. La syntaxe est la suivante :
monitor.sh <nom du journal>
Lorsque cet utilitaire est activé pour contrôler un journal spécifique, il permet à ce journal d'atteindre une taille d'1 Mo (par défaut), puis de le compresser à l'aide de gzip, et place le fichier journal compressé dont le nom est un horodatage dans le sous-répertoire ACSSS/log/log_archives. Cette opération se poursuit si le traçage reste activé.
Certains journaux sont gérés par les composants Java d'ACSLS, notamment l'interface graphique d'ACSLS et les composants logiciels de la bibliothèque logique. Ces journaux se trouvent dans le répertoire $ACS_HOME/log/sslm .
Les procédures d'installation de WebLogic sont consignées dans weblogic.log. Les opérations de l'interface graphique d'ACSLS et de WebLogic sont consignées dans AcslsDomain.log et AdminServer.log.
Une piste d'audit de l'activité des utilisateurs dans l'interface graphique Web se trouve dans guiAccess.log.
Les transactions entre les composants Java et les composants d'ACSLS existants sont consignées dans surrogate_trace.0.log.
Les paquets IPC entre les composants client Java et le serveur ACSLS sont tracés dans acslm_ipc_trace.0.log.
Les erreurs rencontrées par l'interface graphique d'ACSLS sont consignées dans gui_trace.0.log.
La communication de bas niveau entre SMCE et le client SCSI (Fibre Channel) est consignée dans smce_trace.0.log.
Ces journaux se trouvent dans le répertoire $ACS_HOME/log/sslm.
De nombreux utilitaires permettent de vérifier l'état des différents aspects d'ACSLS.
psacs : fournit un récapitulatif de tous les processus en cours d'exécution sur ACSLS. C'est le meilleur moyen pour savoir si ACSLS est en cours d'exécution ou non. Une sortie standard ne doit pas afficher moins de douze processus différents, qui sont tous des enfants d'un processus parent commun.
acsss status : vérifie si le service de base de données acsdb est en cours d'exécution
Pour afficher la version et le niveau de maintenance d'ACSLS :
Examinez acsss_event.log.
Examinez acsls_start.log.
Examinez la fin du fichier acsss_event.log pour consulter les messages expliquant le problème.
Reportez-vous au manuel des messages ACSLS pour obtenir une explication des messages et savoir ce que vous pouvez faire pour les résoudre.
Affichez l'état des services ACSLS avec acsss l-status.
Utilisez acsss l-status pour afficher un récapitulatif des états des services ACSLS. Pour chaque service, les points d'entrée logfile vers les données de journaux peuvent contenir des messages détaillés expliquant la condition qui empêchait ACSLS de démarrer.
ACSLS expire pendant le démarrage
Sur Solaris, pour afficher le délai d'expiration calculé du démarrage d'ACSLS en fonction de votre configuration, utilisez acsss timeout.
ACSLS fournit des utilitaires afin de vérifier la conformité de la connexion physique à la bibliothèque. L'outil sélectionné est déterminé par le contexte de votre activité.
Cet utilitaire teste la connexion à chaque bibliothèque qui a été configurée sur StorageTek ACSLS. Il s'agit également de l'utilitaire le plus facile à utiliser et le plus complet. Le test se déroule de façon imperceptible et n'a aucun impact sur les opérations de bibliothèque normales. Puisque testports utilise la base de données StorageTek ACSLS pour déterminer le nom du port de bibliothèque et le type de bibliothèque, la bibliothèque doit déjà avoir été configurée sur StorageTek ACSLS pour que testports fonctionne.
Pour les bibliothèques TCP/IP, testports vérifie la connexion et si la bibliothèque est en ligne et utilisée par StorageTek ACSLS.
Pour les bibliothèques connectées via SCSI et à connexion série, l''acs' et le 'port' doivent être hors ligne pour que testports puisse ouvrir la connexion au test.
Pour exécuter cet utilitaire, la syntaxe de la commande est :
testports
Le niveau de compatibilité ou le niveau du microcode de la bibliothèque s'affiche.
Cet utilitaire soumet un paquet à une bibliothèque connectée au réseau.
Pour tester la connexion de la bibliothèque, incluez son nom d'hôte ou son adresse IP dans la ligne de commande :
testlmutcp <adresse_ip> ou
testlmutcp <nom d'hôte>
Pour tester la connexion quand la bibliothèque est en ligne sur ACSLS, spécifiez un numéro de socket non utilisé compris entre 50002 et 50016. Par exemple :
testlmutcp <adresse_ip>:50002
Une réponse réussie inclut le niveau de compatibilité de la bibliothèque attachée.
Cet utilitaire permet de tester la connectivité entre ACSLS et les bibliothèques à connexion série StorageTek existantes. Pour exécuter cet utilitaire, soumettez le chemin devlink au noeud du périphérique du port série :
testlmu /dev/term/0
La bibliothèque doit être hors ligne sur ACSLS afin que testlmu puisse ouvrir la connexion série.
Cet utilitaire permet de vérifier la communication entre ACSLS et une bibliothèque à connexion série lorsque la bibliothèque est en ligne sur ACSLS. Une réponse réussie inclut le niveau de compatibilité de la bibliothèque.
Cet utilitaire teste la connexion entre le serveur ACSLS et une bibliothèque connectée via SCSI ou Fibre Channel. Pour exécuter cet utilitaire, soumettez le chemin devlink au périphérique mchanger. La syntaxe est la suivante :
probescsi.sh /dev/mchangerX
où X correspond à l'instance mchanger spécifique de la bibliothèque testée.
La bibliothèque doit être hors ligne sur ACSLS afin que probescsi puisse ouvrir la connexion SCSI. Une réponse réussie inclut le niveau du microcode de la bibliothèque attachée.
Cet utilitaire détecte toutes les bibliothèques connectées via Fibre Channel qui sont accessibles depuis le serveur ACSLS. La syntaxe est la suivante :
probeFibre.sh
Une réponse réussie affiche le numéro de modèle de chaque bibliothèque connectée via Fibre Channel ainsi que sa cible, les ID de LUN et le nom de port mondial (WWPN).
Avec l'option -v, vous pouvez également afficher le numéro de modèle de la carte HBA.
probeFibre.sh -v
Cet utilitaire révèle les détails relatifs à chaque périphérique mchanger pour lequel un lien mchanger a été créé.
showDevs.sh
Affiche un modèle de bibliothèque, le niveau de révision et la capacité de chaque bibliothèque mchanger attachée.
showDevs.sh -w
Cette option inclut également le nom de port mondial de chaque bibliothèque.
showDevs.sh -s
Cette option inclut également le numéro de série de chaque bibliothèque.
Les applications client communiquent avec ACSLS sur TCP/IP à l'aide du protocole RPC (remote procedure call). Si un système client ne peut pas communiquer avec ACSLS, vous pouvez utiliser rpcinfo pour tester l'accessibilité d'ACSLS depuis la machine client.
Depuis le serveur ACSLS, vérifiez qu'ACSLS est en cours d'exécution.
psacs
Depuis le serveur ACSLS, vérifiez que le démon RPC est en cours d'exécution.
ps -ef | grep rpc
Depuis le serveur ACSLS, vérifiez que le numéro de programme 300031 est enregistré pour TCP et IDP.
rpcinfo | grep 300031
Ce numéro de programme confirme qu'ACSLS est en cours d'exécution et a été enregistré avec RPC.
Depuis la machine client, ou une machine UNIX du réseau, utilisez rpcinfo pour échanger un paquet avec le numéro de programme 300031 sur le serveur ACSLS.
Spécifiez l'adresse IP du serveur ACSLS, ainsi que le numéro du programme.
rpcinfo -t <adresse ip> 300031
Si l'échange de communication a réussi, l'utilitaire rpcinfo affiche le message suivant :
program 300031 version 1 ready and waiting
program 300031 version 2 ready and waiting
Cela confirme qu'ACSLS est disponible pour les connexions client sur le réseau.
Un CAP dans une bibliothèque Fibre Channel qui est connecté par le biais d'un lecteur passerelle peut être verrouillé lorsqu'une autre instance ACSLS reprend la gestion de la bibliothèque. Pour plus d'informations et connaître les solutions à ce problème, reportez-vous à Le CAP (fente) ne s'ouvre pas lors d'une éjection dans l'annexe de la bibliothèque SL150.
Au cours de l'appel de service, le support technique Oracle peut vous demande d'envoyer l'intégralité des journaux de diagnostic et d'autres informations relatives au diagnostic pour analyse. Toutes ces données peuvent être collectées à l'aide d'une seule commande :
get_diags
Lorsque cet utilitaire a collecté toutes les informations, il vous invite à envoyer les données par e-mail ou à les rendre disponibles pour un transfert manuel.
Si vous décidez d'envoyer par e-mail les données directement à partir de la machine ACSLS, assurez-vous que la communication par e-mail est possible entre votre machine ACSLS et Internet. Votre entreprise dispose peut-être d'un pare-feu qui empêche l'envoi d'e-mail directement à partir de la machine cible. Dans ce cas, envoyez-vous les informations par-email au sein du réseau de l'entreprise puis transmettez les données de diagnostic à Oracle.
Vous pouvez également choisir de transférer les informations manuellement. L'utilitaire get_diags vous indique où trouver les packages tar en attente pour le transfert. Généralement, le chemin d'accès à la zone de stockage des données de diagnostic est /export/backup/diag/acsss.
SELinux est activé par défaut dans Oracle Linux. Au-delà du contrôle d'accès de niveau Unix standard, SELinux applique l'accès aux ressources système selon le rôle d'utilisateur et le domaine de contexte immédiat. Lorsque l'application de SELinux est activée, la capacité d'ACSLS à accéder à sa propre base de données PostgreSQL peut être entravée sans une stratégie spéciale qui établit le rôle et le contexte pour un tel accès.
Trois modules de stratégie SELinux sont chargés dans le noyau lorsque vous installez ACSLS : allowPostgr, acsdb et acsdb1. Ces modules fournissent les définitions et les exceptions à l'application nécessaires pour permettre à ACSLS d'accéder à sa propre base de données et aux autres ressources système lorsque l'application de SELinux est active. Une fois ces modules installés, vous pouvez effectuer toutes les opérations ACSLS normales, y compris des opérations sur la base de données telles que bdb.acsss, rdb.acsss, db_export.sh et db_import.sh, sans avoir à désactiver l'application de SELinux.
Afin de procéder plus rapidement aux mises à niveau logicielles, les modules de stratégie SELinux qui ont été chargés par ACSLS ne sont pas supprimés automatiquement lors de la désinstallation du package ACSLS. Pour les supprimer manuellement, obtenez une liste des modules ACSLS :
# semodule -l | grep acsdb
# semodule -l | grep allowPostgr
Retirez chaque module de la façon suivante :
# semodule -r <nom du module>
Après l'installation d'ACSLS, si vous rencontrez des problèmes d'accès où le système répond par un message indiquant 'autorisation refusée' alors que les paramètres d'autorisation des fichiers semblent valides, SELinux peut être à la source du refus de l'accès.
Pour vérifier si l'application de SELinux est activée, exécutez la commande : sestatus
# sestatus SELinux status: enabled Current mode: enforcing
Vous pouvez désactiver temporairement l'application de SELinux à l'aide de la commande : setenforce:
# setenforce Permissive
Avec l'application de SELinux en mode permissif (permissive), vous pouvez maintenant vérifier si l'accès à la ressource défaillante peut être restauré. Si la ressource nécessaire est accessible à l'utilisateur autorisé en mode permissif (permissive) mais pas en mode appliqué (enforcing), cela indique qu'une mise à jour de la stratégie SELinux est nécessaire.
Pour désactiver la sécurité SELinux de façon permanente (entre les initialisations) :
Modifiez le fichier : /etc/selinux/config
Modifiez : SELINUX=enforcing sur SELINUX=permissive
Pour réactiver l'application de SELinux, l'utilisateur root doit disposer du rôle sysadm_r.
# newrole -r sysadm_r # setenforce enforcing
Après avoir vérifié que SELinux était la cause de la restriction apparente, vous pouvez afficher les règles actuelles qui interdisent l'accès à la ressource requise en examinant le journal d'audit SELinux.
# vi /var/log/audit/audit.log
Le journal audit.log fournit un récapitulatif pour chaque tentative d'accès qui aboutit ou non à l'application de SE. Vous devez examiner les événements qui ont échoué. Pour ACSLS, examinez plus spécialement les événements relatifs aux utilisateurs acsss et acsdb.
Vous pouvez afficher les attributs de contexte SELinux associés à un fichier ou un répertoire donné :
# ls -Z <file name>
Vous pouvez afficher les attributs de contexte d'un processus donné ou ceux de votre shell actuel à l'aide de la commande : secon. Il est possible de modifier les attributs de contexte d'un fichier ou d'un répertoire à l'aide de la commande chcon. Consultez les pages de manuel pour ces opérations.
Il est possible de créer un module de stratégie pour répondre aux opérations avortées identifiées dans le journal audit.log.
# cd /var/log/audit # audit2allow -a -M <ModuleName>
Cela permet d'évaluer les défaillances consignées par SELinux et de créer un fichier de module de stratégie <NomModule>.pp. Ce fichier peut être chargé dans le noyau Linux afin d'autoriser les opérations qui ont été bloquées.
# semodule -i <ModuleName>.pp
Puisque audit2allow crée une stratégie qui active toutes les restrictions identifiées dans le journal audit.log, il est recommandé de s'assurer que ce journal contient uniquement les opérations que vous souhaitez spécifiquement autoriser. Vous pouvez enregistrer le fichier audit.log initial et en créer un nouveau.
# mv audit.log audit1.log # touch audit.log
Poursuivez les opérations que vous souhaitez capturer avant de créer un module de stratégie pour elles.
Pour plus d'informations sur SELinux, consultez la page de manuel :
# man selinux
L'utilitaire checkGui.sh vérifie les facteurs communs afin d'évaluer le fonctionnement de l'interface graphique. Si l'interface graphique ne fonctionne pas, cet utilitaire peut conduire aux utilisateurs aux causes probables du problème.
Cet utilitaire vérifie les points suivants :
Est-ce que WebLogic est activé sur le système ?
Existe-t-il des processus obsolètes ou fantômes qui pourraient bloquer l'opération WebLogic ?
L'application SlimGUI a-t-elle été déployée ?
WebLogic et l'interface graphique peuvent-ils répondre à une demande HTTP envoyée à l'hôte local ?
Le service WebLogic peut-il répondre à une demande HTTP envoyée à l'adresse Internet de l'hôte ?
Le service de pare-feu est-il activé sur le serveur ? Si c'est le cas, une stratégie permet-elle d'accepter les demandes entrantes vers les ports WebLogic 7001 et 7002 ?
Sur les systèmes Linux, le pare-feu appelé iptables peut être activé par défaut. Vous pouvez désactiver iptables complètement ou vous pouvez ajouter une stratégie afin d'accepter le trafic entrant vers les ports 7001 et 7002.
Pour activer ces ports (en tant que root), modifiez le fichier /etc/sysconfig/iptables. Ajoutez les deux lignes suivantes :
-A INPUT -p tco --dport 7001 -j ACCEPT -A INPUT -p tco --dport 7002 -j ACCEPT
Assurez-vous de ne pas insérer ces règles après une autre règle qui crée des correspondances avec les paquets entrants avant leur examen. Par exemple, ne les ajoutez pas à la fin d'une chaîne iptables après une règle REJECT all.
Si vous utilisez la commande iptables pour ajouter ces règles :
Répertoriez (iptables -L) ou imprimez (iptables -S) le tableau.
Ajoutez les règles.
Le fait d'ajouter les règles (iptables –A) à la fin d'une chaîne risque de ne pas produire le résultat souhaité, car les règles antérieures peuvent empêcher les nouvelles règles de créer des correspondance avec les entrées.
Insérez plutôt la règle (iptables -I) à l'aide de rulenum.
Répertoriez (iptables -L) ou imprimez (iptables -S) le tableau après la modification et assurez-vous que les règles existantes n'empêchent pas l'examen des nouvelles règles pour les ports 7001 et 7002.
On peut ainsi s'assurer que les nouvelles règles peuvent créer des correspondances avec un paquet entrant.
L'utilitaire checkGui.sh vérifie l'existence des règles pour ACCEPTER les entrées sur les ports 7001 et 7002. Il ne vérifie pas que ces règles se situent dans la chaîne iptables appropriée ou que les nouvelles règles seront traitées. En d'autres termes, l'utilitaire checkGui.sh ne vérifie pas qu'il n'existe pas de règles antérieures qui empêcheraient l'examen des nouvelles règles.
Redémarrez iptables :
service iptables restart
Le service équivalent sur Solaris est ipfilter, qui n'est généralement pas activé par défaut.
Le tableau suivant fournit des conseils de dépannage de l'interface graphique.
Tableau J-1 Conseils de dépannage de l'interface graphique
| Problème | Solution |
|---|---|
|
J'ai inséré https://<nom d'hôte> dans le navigateur, mais la page de réponse indique qu'il n'est pas possible de se connecter. |
L'URL correcte est https://hostname.domain:7002/SlimGUI/faces/Slim.jsp |
|
La page de l'interface graphique d'ACSLS est incomplète. Certaines trames sont incomplètes ou des sections entières sont manquantes. |
Cliquez sur le bouton d'actualisation de votre navigateur. |
|
Java WebLogic rejette un ID utilisateur et un mot de passe qui sont valides. Je ne parviens pas à me connecter. |
Consultez votre administrateur ACSLS local. Si vous êtes l'administrateur, servez-vous de l'utilitaire userAdmin.sh pour répertorier des utilisateurs, ajouter un utilisateur ou modifier un mot de passe utilisateur. Si les utilisateurs ont toujours des difficultés pour se connecter, vérifiez que votre système dispose de suffisamment de mémoire, puis redémarrez l'interface graphique ACSLS avec l'option-5 de userAdmin.sh. Vous pouvez également redémarrer WebLogic à l'aide des commandes svcadm disable weblogic et svcadm enable weblogic. |
|
Une trace de pile d'erreur java s'affiche dans une ou plusieurs fenêtres de l'interface graphique. |
Appuyez sur le bouton d'actualisation de votre navigateur. Si le problème persiste, utilisez Si les services ne sont pas en cours d'exécution, affichez-les avec Si les services ACSLS sont en cours d'exécution, redémarrez l'interface graphique à l'aide de userAdmin.sh. Vous pouvez également redémarrer WebLogic à l'aide des commandes svcadm disable weblogic et svcadm enable weblogic. Si vous ne disposez pas d'un accès en tant qu'utilisateur |
|
Sélection manquante pour "Logical Libraries” dans la trame de l'arborescence d'index. |
Vous devez d'abord créer une bibliothèque logique. Sélectionnez : Configuration and Administration ->Logical Library Configuration ->Create Logical Library. |
|
Aucun volume n'est répertorié dans la page Volumes sous Tape Library Operations ou Tape Libraries & Drives. |
Cela indique qu'aucun audit initial n'a été effectué pour la bibliothèque. Sélectionnez : Tape Library Operations ->Audit |
|
Aucun volume n'est répertorié dans la page Volumes sous Logical Libraries. |
Cela indique que les volumes n'ont pas encore été affectés à la bibliothèque logique. Sélectionnez : Logical Library Configuration ->Assign Volumes. |
|
Le temps de réponse de l'interface graphique est long. |
Augmentez la valeur de Alert Update Interval sous le bouton Preferences dans le cadre masthead de l'interface graphique. |
|
Je dois ajouter des utilisateurs de l'interface graphique, modifier les mots de passe des utilisateurs de l'interface graphique ou définir le mot de passe |
Reportez-vous à userAdmin.sh. Cet utilitaire permet d'ajouter des utilisateurs, de modifier les mots de passe des utilisateurs et indique comment réinitialiser le mot de passe |
|
Le navigateur nécessite un certificat de sécurité. |
Reportez-vous à Configuration d'un certificat numérique auto-affecté pour HTTPS |