| StorageTek Tape Analytics Guide d'installation et de configuration Version 2.0 E53327-01 |
|
 Précédent |
 Suivant |
| StorageTek Tape Analytics Guide d'installation et de configuration Version 2.0 E53327-01 |
|
Précédent |
Suivant |
Ce chapitre explique comment mettre à niveau STA 1.0.x à 2.0. Ce processus est différent de la mise à niveau de STA 1.0.x vers une autre version 1.0.x. La mise à niveau est possible uniquement à partir des trois versions antérieures de STA 1.0 publiées : 1.0.0.99, 1.0.1.133 et 1.0.2.24. Après la mise à niveau, STA traitera de nouvelles données en fonction du schéma et des règles d'analyse de la nouvelle version (les données d'historique ne sont pas à nouveau traitées).
|
Remarque: Si vous effectuez une mise à niveau du microprogramme de la bibliothèque en même que celle de STA, vous serez peut-être amené à effectuer une mise à jour de l'ID du moteur de la bibliothèque et de la configuration SNMP. Reportez-vous à la section ”Gestion des connexions de bibliothèque SNMP” du Guide d'administration STA. |
Vérifiez les conditions requises pour l'installation de STA 2.0 : reportez-vous pour cela au Guide des conditions requises pour l'installation de STA.
Déplacez les sauvegardes de la base de données vers un serveur à part : les sauvegardes de base de données créées à l'aide du service de sauvegarde STA ne seront plus valides après la mise à niveau.
Enregistrez les paramètres STA 1.0.x : les références WebLogic et MySQL, les numéros de port, les attributs de client SNMP et les modèles publics commençant par "STA-" ne sontpas conservés. Utilisez "Mise à niveau de la feuille de travail" pour enregistrer les paramètres STA 1.0.x. Pour l'utilisation des mêmes noms d'utilisateur du compteBas de page 1 et des attributs client SNMP dans STA 2.0, Tâche 1 fournit des instructions pour obtenir cette information. Pour conserver les modèles publics enregistrés commençant par "STA-", sauvegardez-les avec des nouveaux noms avant la mise à niveauBas de page 2 .
Assurez-vous que STA 1.0.x est configuré et fonctionne correctement : dans le tableau Monitored Libraries, assurez-vous que chaque bibliothèque a récemment réussi à communiquer avec le serveur STA.
Téléchargement du logiciel : STA 2.0 comprend deux importants fichiers ZIP de package de médias. Il est recommandé de télécharger les fichiers dès maintenant sur une plate-forme à part tout en effectuant les premières tâches de mise à niveau (reportez-vous à la section "Téléchargement de STA").
|
Mise en garde: Reportez-vous à la section "Avant la mise à niveau" pour voir quelles références et quels paramètres STA 1.0.x ne sont pas conservés. |
Tableau 9-1 Informations nécessaires à l'installation de STA 2.0
| Informations requises | Valeurs STA 1.0.x | Valeurs STA 2.0Bas de page 1 |
|---|---|---|
|
Nom d'utilisateur de connexion à la console d'administration de WebLogic |
||
|
Mot de passe de connexion à la console d'administration de WebLogic |
||
|
Nom d'utilisateur de connexion de l'interface utilisateur graphique de STA |
||
|
Mot de passe de connexion de l'interface utilisateur graphique de STA |
||
|
Mot de passe du compte root de base de données STABas de page 2 |
||
|
Nom d'utilisateur du compte d'application de la base de données STA |
||
|
Mot de passe du compte d'application de la base de données STA |
||
|
Nom d'utilisateur du compte de rapports de la base de données STA |
||
|
Mot de passe du compte de rapports de la base de données STA |
||
|
Nom d'utilisateur du compte DBA de la base de données STA |
||
|
Mot de passe du compte DBA de la base de données STARéférence de bas de page 2 |
||
|
Port de connexion à la console d'administration de WebLogic, HTTP (7001 par défaut) |
||
|
Port de connexion à la console d'administration de WebLogic, HTTPS (7002 par défaut) |
||
|
Port de serveur de connexion/staUi géré de l'interface utilisateur graphique STA, HTTP (7021 par défaut) |
||
|
Port de serveur de connexion/staUi géré de l'interface utilisateur graphique STA, HTTPS (7022 par défaut) |
||
|
Serveur staEngine géré, HTTP (par défaut = 7023) |
N/A |
|
|
Serveur staEngine géré, HTTPS (par défaut = 7024) |
N/A |
|
|
Serveur staAdapter géré, HTTP (par défaut = 7025) |
N/A |
|
|
Serveur staAdapter géré, HTTPS (par défaut = 7026) |
N/A |
|
|
Nom de domaine d'entreprise (par exemple, us.oracle.com) |
Note de bas de page 1 Vous pouvez utiliser des valeurs STA 1.0.x existantes pour STA 2.0 ou choisir de nouvelles valeurs.
Note de bas de page 2 La root de base de données ou le mot de passe du compte DBA est requis pour Tâche 2, "Vidage de la base de données STA 1.0.x".
Tableau 9-2 Informations nécessaires à la configuration de STA 2.0 après son installationBas de page 1
| Informations requises | Valeurs STA 1.0.x | Valeurs STA 2.0 |
|---|---|---|
|
Nom d'utilisateur SNMP v3 |
||
|
Mot de passe d'autorisation SNMP v3 (Autorisation) |
||
|
Mot de passe de chiffrement de confidentialité SNMP v3 (Confidentialité) |
||
|
Communauté d'utilisateurs |
||
|
Communauté de déroutements |
||
|
Nom(s) d'utilisateur et mot(s) de passe WebLogic supplémentaires |
Note de bas de page 1 Les valeurs SNMP doivent correspondre aux spécifications de la bibliothèque.
Vous pouvez effectuer une mise à niveau de STA 1.0.x vers 2.0 à l'aide d'une de ces deux méthodes :
Single server method (Figure 9-1) : STA 1.0.x est hors ligne (il ne contrôle pas les bibliothèques) pendant que le serveur est reconfiguré pour STA 2.0, ce qui augmente le temps d'indisponibilité. Effectuez toutes les tâches dans un ordre numérique.
Two server method (Figure 9-2) : STA 1.0.x est en ligne (il contrôle les bibliothèques) sur un serveur pendant qu'un serveur à part est configuré pour STA 2.0, ce qui permet de réduire le temps d'indisponibilité. Avec cette méthode, les tâches ne sont pas effectuées dans un ordre numérique. Vous devez effectuer les tâches dans l'ordre affiché. Tâche 7 est omis.
Figure 9-1 Présentation de la tâche de mise à niveau du serveur unique
Figure 9-2 Présentation de la tâche de mise à niveau des deux serveurs
Single server method (Figure 9-1) : effectuez toutes les tâches dans un ordre numérique :
Tâche 1, Tâche 2, Tâche 3, Tâche 4, Tâche 5, Tâche 6, Tâche 7, Tâche 8, Tâche 9, Tâche 10
Two server method (Figure 9-2) : les tâches ne sont pas effectuées dans un ordre numérique. Vous devez effectuer les tâches dans l'ordre suivant, en omettant Tâche 7 :
Tâche 1, Tâche 4, Tâche 5, Tâche 6, Tâche 2, Tâche 3, Tâche 8, Tâche 9, Tâche 10
|
Mise en garde: Seul un administrateur Linux ou STA peut effectuer la mise à niveau. Si vous ne suivez pas précisément les étapes dans l'ordre spécifié, vous pouvez perdre vos données. |
Cette procédure permet d'obtenir les noms d'utilisateur STA 1.0.x WebLogic, les noms d'utilisateur de base de données MySQL et les attributs client SNMP. Pour plus d'informations, reportez-vous à la section"Avant la mise à niveau".
|
Remarque: Les mots de passe associés avec les noms d'utilisateur WebLogic, MySQL et SNMP ne sont pas ne sont pas extraits. |
Pour obtenir une liste d'utilisateurs de WebLogic :
Allez à l'écran de connexion de la console WebLogic à l'aide du numéro de port HTTP (7001 par défaut) ou HTTPS (7002 par défaut) que vous avez sélectionné pendant l'installation de STA.
http(s)://NomDeVotreHôte:NuméroDuPort/console/
Connectez-vous à l'aide du nom d'utilisateur et du mot de passe de la console d'administration de WebLogic.
Sous Domain Structure (à gauche de l'écran), cliquez sur Security Realms.
Sous Realms, sélectionnez myrealm (sélectionnez le nom et non la case à cocher).
Sélectionnez l'onglet Users and Groups.
La liste d'utilisateurs de STA apparaît dans le tableau Users.
Pour obtenir une liste des utilisateurs de la base de données MySQL :
Dans une session de terminal, connectez-vous au serveur STA 1.0.x.
Exécutez la commande suivante et saisissez votre mot de passe MySQL d'utilisateur root lorsque vous y êtes invité :
# mysql -uroot -p -e "select distinct(user) from user order by user ;" mysql Enter password: root-password
Enregistrez la liste des noms d'utilisateur de base de données STA qui s'affiche. Par exemple :
+--------+ | user | +--------+ | root | | staapp | | stadba | | starpt | +--------+
Pour afficher les attributs client SNMP :
Allez à l'écran de connexion de l'interface utilisateur graphique de STA à l'aide du numéro de port HTTP (7021 par défaut) ou HTTPS (7022 par défaut). "STA" doit être saisi en majuscules.
http(s)://NomDeVotreHôte:NuméroDuPort/STA/
Connectez-vous à l'aide du nom d'utilisateur et du mot de passe de connexion de l'interface utilisateur graphique de STA.
Dans le menu de navigation, sélectionnez Settings > SNMP Connections.
Les chaînes SNMP Username, User Community et Trap Community sont affichées dans le tableau Client Attributes.
Ouvrez une session de terminal sur le serveur STA 1.0.x.
Exécutez la commande suivante pour arrêter tous les services STA :
# STA stop
Lancez le service MySQL à l'aide de la commande suivante :
# service mysql start
Videz la base de données sur un fichier unique à l'aide de la commande suivante :
# /usr/bin/mysqldump -uroot -p --opt --routines --events --flush-logs --single-transaction --complete-insert --comments --dump-date --add-drop-database --databases stadb -v > /desired_path_for_dumpfile/dump_file_name.sql Enter password: mysql_root_password
|
Remarque: -v (facultatif, pour la sortie détaillée) renverra la progression de la commande. Cependant, cela peut considérablement ralentir le processus de vidage pour les bases de données importantes. |
Exemple 9-1 Vidage de la base de données STA 1.0.x
Dans cet exemple, la base de données STA 1.0.x est vidée dans le dossier root sur le serveur STA avec 20130711_dump.sql comme nom de fichier.
# /usr/bin/mysqldump -uroot -p --opt --routines --events --flush-logs --single-transaction --complete-insert --comments --dump-date --add-drop-database --databases stadb -v > /root/20130711_dump.sql
Enter password: mysql_root_password
...
-- Retrieving view structure for table v_library_complex_io...
...
-- Retrieving view structure for table v_library_summary_averages...
-- It's base table, skipped
...
-- Retrieving table structure for table v_mdv_status_codes...-- It's a view, create dummy table for view
...
-- Disconnecting from localhost...
Pour réduire la taille du fichier de vidage d'environ 50 %, compressez le fichier en gzip.
# cd /path_to_dump_file/ # gzip dump_file_name.sql
Dans cette tâche, le fichier de vidage compressé de la base de données STA 1.0.x est transféré sur un serveur de sauvegarde en dehors de la plate-forme (méthode de serveur unique) ou sur le nouveau serveur STA 2.0 (méthode des deux serveurs).
|
Mise en garde: Si vous suivez la méthode de mise à niveau de serveur unique, vous devez sauvegarder la base de données STA sur un autre serveur. Ne sauvegardez pas la base de données sur un système de fichiers sur le serveur STA existant, car l'installation de Linux 6.x dans Tâche 4 détruira toutes les données du serveur. |
Effectuez une somme de contrôle avant de transférer le fichier sur le serveur de sauvegarde.
# cksum dump_file_name.sql.gz
Le résultat inclut une valeur de somme de contrôle et un calcul d'octets. Enregistrez la valeur de somme de contrôle — vous l'utiliserez pour vérifier l'intégrité du fichier après le transfert du fichier vers le serveur de sauvegarde.
Transférez le fichier vers le serveur cible à l'aide d'un utilitaire de transfert comme SCP. L'option -p conserve les valeurs timestamp.
# scp -p dump_file_name.sql.gz target_host:/path/
Exemple 9-2 Transférez la base de données STA 1.0.x vers le serveur de sauvegarde (méthode de serveur unique)
Dans cet exemple, le fichier de vidage compressé de la base de données 20130711_dump.sql.gz est transféré à l'aide de SCP vers le dossier /root/dump sur l'hôte backup1 de sauvegarde.
# cd /root # scp -p 20130711_dump.sql.gz backup1:/root/dump
Exemple 9-3 Transfert de la base de données STA 1.0.x vers le nouveau serveur STA 2.0 (méthode des deux serveurs)
Dans cet exemple, le fichier de vidage compressé de la base de données 20130711_dump.sql.gz est transféré à l'aide de SCP vers le dossier /root sur l'hôte sta_new STA 2.0.
# cd /root # scp -p 20130711_dump.sql.gz sta_new:/root
Sur le serveur cible, effectuez une somme de contrôle du fichier transféré. Vérifiez que la valeur de somme de contrôle correspond.
# cd /path_to_dump_file/ # cksum dump_file_name.sql.gz
|
Mise en garde: Si vous suivez la méthode de serveur unique, vérifiez que la base de données STA a été sauvegardée sur un autre serveur. Toutes les données du serveur STA seront détruites dans cette tâche. |
La mise à niveau de Linux 5.x vers Linux 6.x est considérable, la mise à niveau sur place n'est donc pas prise en charge par Linux — vous ne pouvez pas mettre à niveau le SE tout en conservant les systèmes de fichiers existants de Linux 5.x. Linux 6.x est installé sur le serveur STA 1.0.x.
Pour installer et configurer Linux 6.x, reportez-vous à la section Chapitre 1, "Installation de Linux."
Installez STA 2.0 selon le chapitre Chapitre 2, "Installation de STA."
Connectez-vous à l'interface utilisateur STA pour vous assurer que STA fonctionne correctement avant d'effectuer les tâches de mise à niveau restantes (reportez-vous à la section "Connectez-vous à l'interface utilisateur STA.").
Ouvrez une session de terminal sur le serveur STA.
Exécutez la commande suivante pour arrêter tous les services STA 2.0 :
# STA stop all
(Facultatif) Si le serveur STA 1.0.x est configuré pour communiquer avec les bibliothèques SNMP v2c, vous serez amené à activer le mode v2c sur le serveur STA 2.0. Suivez cette procédure dans Annexe B, "Activation du mode v2c SNMP pour STA," mais omettez les dernières étapes pour arrêter et redémarrer STA — c'est inutile car vous avez déjà arrêté STA et vous le redémarrerez plus loin dans le processus de mise à niveau.
Si la mise à niveau échoue, vous utiliserez un fichier de vidage de sauvegarde pour récupérer STA dans un état dans lequel vous pouvez le configurer afin qu'il s'exécute comme s'il venait d'être installé sans aucune donnée.
Lancez le service MySQL à l'aide de la commande suivante :
# STA start mysql
Exécutez la commande suivante pour créer le fichier de sauvegarde :
# /usr/bin/mysqldump -uroot -p --opt --routines --events --flush-logs --single-transaction --complete-insert --comments --dump-date --add-drop-database --databases stadb -v > /dbbackup/STA_FRESH_INSTALL_BACKUP.sql Enter password: mysql_root_password
Le résultat obtenu est semblable au résultat suivant :
... -- Retrieving view structure for table v_mdv_request_states... -- Retrieving view structure for table version_info... ... -- Disconnecting from localhost...
|
Remarque: Si vous voyez le message "Can’t connect to local MySQL server", alors le serveur MySQL n'est pas en cours d'exécution. Assurez-vous d'avoir lancé MySQL (Etape 1). |
Méthode de serveur unique : vous pouvez utilisez SCP pour transférer la copie sauvegardée de la base de données STA 1.0.x vers le serveur STA 2.0. L'option -p conserve les valeurs timestamp.
Exécutez la commande suivante :
# scp -p backup_host:/path_to_dump_file/dump_file_name.sql.gz /local_path
Exemple 9-4 Transfert de la base de données STA 1.0.x vers le serveur STA 2.0
Dans cet exemple, le fichier de vidage compressé de la base de données 20130711_dump.sql.gz est transféré à l'aide de SCP depuis /root/dump sur l'hôte backup1 vers le dossier /root sur le serveur STA 2.0.
# scp -p backup1:/root/dump/20130711_dump.sql.gz /root
Effectuez une somme de contrôle du fichier transféré. Vérifiez que la valeur de somme de contrôle correspond à la valeur que vous avez reçu dans Tâche 2.
# cd /path_to_dump_file/ # cksum dump_file_name.sql.gz
Dans cette tâche, la base de données STA 1.0.x n'est pas compressée et elle est rétablie sur le serveur STA.
Décompressez le fichier de sauvegarde.
# gunzip dump_file_name.sql.gz
(Facultatif) Effectuez les étapes suivantes pour purger la base de données STA de données obsolètes (par exemple, des enregistrements SNMP qui ont déjà été traités ou des enregistrements d'analyse vides). Cette action est fortement recommandée et réduira considérablement la taille de la base de données et les durées de chargement des bases de données de plus d'1 Go. Les étapes restantes de cette tâche supposent qu'une purge a été effectuée. Un enregistrement permanent de l'activité de la commande purgerecs est sauvegardé dans la base de données STA.
|
Remarque: Dans STA 2.0, la purge de la base de données a lieu automatiquement au moment de l'exécution. Les enregistrements SNMP traités sont régulièrement purgés de la base de données par MySQL Event Scheduler pour limiter la croissance de la base de données. |
Passez au répertoire des mises à jour de STA :
# cd /Oracle/StorageTek_Tape_Analytics/db/updates
Exécutez la commande suivante :
# ./purgerecs /path_to_dump_file/dump_file_name.sql /path_to_dump_file/purged_dump_file_name.sql
|
Remarque: Pour obtenir de l'aide avec la commandepurgerecs, tapez ce qui suit :
# ./purgerecs -h
|
Exemple 9-5 Purger les données obsolètes de la base de données STA 1.0.x
Dans cet exemple, le fichier de vidage MySQL non compressé 20130711_dump.sql sous /root est purgé à l'aide de l'utilitaire purgerecs, avec les données en sortie dirigées vers un nouveau fichier appelé 20130711_dump_purged.sql sous /root. Un point de progression apparaîtra pour tous les 200 enregistrements traités.
# cd /Oracle/StorageTek_Tape_Analytics/db/updates
# ./purgerecs /root/20130711_dump.sql /root/20130711_dump_purged.sql
................................................
STA v1.0.2, Schema 33.02
Processed 11,689 lines from '20130711_dump.sql':
------------------------------------------------
snmp_storage_cells........1,614,255
snmp_media................110,205
...
media_summaries...........254
transform_logs............0
================================================
Records Processed:........13,143,283
Records Purged:...........2,857,623
Records Remaining:........10,285,660
Elapsed Time:.............00:00:11
(Facultatif) Utilisez ensuite la commande suivante pour déterminer la taille du fichier de base de données et estimer la durée du processus de chargement. Le processus de chargement prend jusqu'à cinq minutes par giga-octet de taille d'instantané de base de données non compressée à exécuter.
# ls -s -h purged_dump_file_name.sql
Chargement de la base de données STA 1.0.x.
# mysql -uroot -p -e "SET SESSION SQL_LOG_BIN=0; SOURCE /path_to_dump_file/dump_file_name;" Password: mysql_root_password
Si la commande aboutit, vous reviendrez à l'invite de commande une fois que le processus se termine. A moins de spécifier l'option -v (détaillée) (non recommandé), vous ne verrez aucune sortie de commande lors de l'exécution du processus.
Explication de la commande :
-p : demande le mot de passe root MySQL établi pendant l'installation STA 2.0.
-v : sortie détaillée (facultatif). Cela ralentira considérablement le processus de chargement.
-e: exécutez les déclarations en citation suivantes
SET SESSION SQL_LOG_BIN=0; : coupe les connexions binaires inutiles, ce qui permet d'accélérer le chargement.
SOURCE /path_to_dump_file/: charge le fichier de vidage dans la base de données.
Le processus de chargement prend environ deux minutes par giga-octet de taille d'instantané de base de données non compressée à exécuter, en fonction de la version STA 1.0.x à mettre à niveau.
Effectuez une mise à niveau de la base de données STA 1.0.x vers le nouveau schéma STA 2.0 à l'aide des commandes suivantes :
# cd /Oracle/StorageTek_Tape_Analytics/db/updates # ./upgradedb.sh DB Root Password: mysql_root_password
|
Remarque: Pour des raisons de sécurité, le mot de passe ne s'affiche pas en retour. Pour obtenir de l'aide avec la commandeupgradedb.sh, tapez ce qui suit :
# ./upgradedb.sh -h
|
Exemple de sortie :
+-------------------------------------------------------------+ | STA DATABASE UPGRADE | | Upgrading DB schema from 49.00r0 to 50.00r0 | | Started: 2014-01-14 01:21:47 | +-------------------------------------------------------------+ STA database contains approximately 4,301 records. installed version 49.00 is a valid upgrade candidate, proceeding... ...allow approximately two minutes per 1GB of file size...
Lorsque le processus se termine, vous verrez un message d'accueil similaire au message suivant :
+-------------------------------------------------------------+ | Started.................2014-01-14 01:21:47 | | Finished................2014-01-14 01:21:54 | | Elapsed Time............00:00:07 | | Starting Version........49.00r0 | | Final Schema Version....50.00r0 | | Schema Release Date.....2014-01-08 15:16:17 | | Records (approximate)...4,282 | +-------------------------------------------------------------+
|
Remarque: Si la mise à niveau échoue, essayez de compléter Tâche 8, étape 4 à Tâche 9. Si la mise à niveau échoue de nouveau, il est possible que la base de données se trouve dans un état inconnu ou endommagé. Dans ce cas, il est recommandé de restaurer la base de données à son état original d'installation, comme suit :
|
Lancez tous les services STA à l'aide de la commande suivante.
# STA start all
|
Mise en garde: Ne démarrez pas STA avant que le processus de mise à niveau de la base de données soit entièrement terminé à l'étape 1 de cette tâche. |
(Facultatif) Si la mise à niveau aboutit, supprimez le fichier STA_FRESH_INSTALL_BACKUP.sql pour libérer de l'espace de disque sur le volume /dbbackup.
Continuez en fonction de la méthode de mise à niveau :
Méthode de serveur unique : si vous avez modifié l'adresse IP du serveur STA pendant le processus de mise à niveau, ajoutez à nouveau chaque liste de destinataire de déroutement de bibliothèque pour refléter la nouvelle adresse IP du serveur STA. Pour rajouter les destinataires de déroutement, reportez-vous à la section "Tâches de gestion de la bibliothèque SNMP" du Guide d'administration de STA.
Méthode à deux serveurs : ajoutez le serveur STA 2.0 comme nouveau destinataire de déroutement à la configuration SNMP de chaque bibliothèque. Reportez-vous à la section "Création d'un destinataire de déroutement SNMP v3" ou "Créez un destinataire de déroutement SNMP v2c".
|
Remarque: STA 2.0 prend en charge deux nouveaux niveaux de déroutement : 13 (déroutement de test) et 14 (déroutement d'intégrité). Si ces niveaux n'ont pas encore été spécifiés sur la liste de destinataire de déroutement de chaque bibliothèque contrôlée, vous devrez de nouveau ajouter la liste de destinataire de déroutement en incluant les niveaux 13 et 14. |
Connectez-vous à STA, comme décrit dans la section "Connectez-vous à l'interface utilisateur STA.".
Saisissez de nouveau les attributs client SNMP, comme décrit dans la section "Configurez les paramètres client SNMP pour STA".
Effectuez une mise à jour des détails de connexion pour chaque bibliothèque contrôlée.
Dans le menu de navigation, sélectionnez Setup & Administration > Configuration > SNMP Connections.
Dans la section Monitored Libraries, sélectionnez un nom de bibliothèque puis cliquez sur le bouton Edit.
Sélectionnez l'adresse IP du serveur STA 2.0 dans le menu déroulant STA IP Address.
Cliquez sur Save.
Répétez ces étapes pour chaque bibliothèque contrôlée de la liste.
Pour assurer des communications correctes, testez la connexion de chaque bibliothèque configurée, comme décrit dans la section "Test de la connexion SNMP vers la bibliothèque.".
Avant de tester une connexion, notez les horodotages de Last Successful Connection et Last Connection Attempt. Une fois que vous avez effectué le test, vous pouvez comparer les horodotages pour vous assurer que le test fournit des informations actuelles.
Obtenez les dernières données de chaque bibliothèque, comme décrit dans la section "Obtenir les dernières données de configuration de la bibliothèque".
Suivez les procédures dans "Configuration des utilisateurs et de la messagerie" pour modifier ou créer des utilisateurs STA et configurer (et tester) les propriétés d'e-mail.
Si des utilisateurs supplémentaires de STA (à l'exception des utilisateurs Admin Console Login et STA GUI Login par défaut) ont été enregistrés dans Tâche 1, vous pouvez créer les mêmes utilisateurs maintenant et leur attribuer des rôles, le cas échéant.
|
Remarque: Même si la plupart des paramètres de notification par e-mail sont conservés lors de la mise à niveau de STA, vous devrez de nouveau activer la communication et saisir le mot de passe de votre compte de messagerie. |
Configurez (ou reconfigurez) les composants STA restants, comme indiqué dans les chapitres suivants :
Si vous avez suivi la méthode à deux serveurs, vous pouvez désormais mettre le serveur STA 1.0.x hors service.
Vous pouvez également supprimer le serveur STA 1.0.x comme destinataire de déroutement de la configuration SNMP de chaque bibliothèque. Pour supprimer les destinataires de déroutement, reportez-vous à la section "Tâches de gestion de la bibliothèque SNMP" du Guide d'administration de STA.
Légende de note de bas de page
Note de bas de page 1: Dans STA 2.0, des utilisateurs d'application supplémentaires sont créés dans l'interface utilisateur de STA et non pas dans WebLogic.
|
 Copyright © 2012, 2014, Oracle et/ou ses sociétés affiliés. Tous droits réservés. Informations légales |
|