Centre de documentation de WebSphere Remote Server

Transcription

WebSphere WebSphere® Remote
Server
®
Version 7.1.1
Centre de documentation d'IBM
WebSphere Remote Server
version 7.1.1
򔻐򗗠򙳰
novembre 2010
LE PRESENT DOCUMENT EST LIVRE EN L'ETAT SANS AUCUNE GARANTIE EXPLICITE OU IMPLICITE. IBM
DECLINE NOTAMMENT TOUTE RESPONSABILITE RELATIVE A CES INFORMATIONS EN CAS DE
CONTREFACON AINSI QU'EN CAS DE DEFAUT D'APTITUDE A L'EXECUTION D'UN TRAVAIL DONNE.
Ce document est mis à jour périodiquement. Chaque nouvelle édition inclut les mises à jour. Les informations qui y
sont fournies sont susceptibles d'être modifiées avant que les produits décrits ne deviennent eux-mêmes
disponibles. En outre, il peut contenir des informations ou des références concernant certains produits, logiciels ou
services non annoncés dans ce pays. Cela ne signifie cependant pas qu'ils y seront annoncés.
Pour plus de détails, pour toute demande d'ordre technique, ou pour obtenir des exemplaires de documents IBM,
référez-vous aux documents d'annonce disponibles dans votre pays, ou adressez-vous à votre partenaire
commercial.
Vous pouvez également consulter les serveurs Internet suivants :
v http://www.fr.ibm.com (serveur IBM en France)
v http://www.can.ibm.com (serveur IBM au Canada)
v http://www.ibm.com (serveur IBM aux Etats-Unis)
Compagnie IBM France
Direction Qualité
17, avenue de l'Europe
92275 Bois-Colombes Cedex
© Copyright IBM France 2010. Tous droits réservés
© Copyright IBM Corporation 2004, 2010.
Table des matières
Chapitre 1. Présentation du produit . . . 1
Nouveautés de cette édition . . . .
Versions de WebSphere Remote Server.
Programme d'installation de WebSphere
Server . . . . . . . . . . .
Accélérateurs de gestion de systèmes .
Processeurs intégrés au magasin . . .
Serveur d'entreprise . . . . . . .
Composants supplémentaires . . . .
. . .
. . .
Remote
. . .
. . .
. . .
. . .
. . .
.
.
. 2
. 2
.
.
.
.
.
.
.
.
.
.
4
5
6
6
6
Chapitre 2. Installation et déploiement. . 9
Configurations matérielle et logicielle requises . .
Configuration matérielle . . . . . . . .
Configuration logicielle . . . . . . . .
Installation du produit. . . . . . . . . .
Installation d'IBM WebSphere Remote Server .
Installation de l'environnement de
développement . . . . . . . . . . .
Installation de WebSphere Remote Server à
distance . . . . . . . . . . . . .
Zones de saisie de l'assistant de déploiement .
Installation en mode silencieux . . . . . .
Vérification de l'installation . . . . . . . .
Fichiers journaux d'installation . . . . . .
Vérification de WebSphere Application Server .
Vérification de WebSphere MQ . . . . . .
Vérification d'IBM HTTP Server . . . . .
Vérification de DB2 Workgroup Server Edition
Vérification d'Informix Growth Edition . . .
Vérification de WebSphere sMash . . . . .
Installation et déploiement des agents IBM Tivoli
Monitoring . . . . . . . . . . . . .
Installation des fichiers de prise en charge de
l'agent . . . . . . . . . . . . . .
Déploiement d'agents de surveillance Tivoli
Monitoring . . . . . . . . . . . .
Désinstallation . . . . . . . . . . . .
. 9
. 10
. 11
. 12
. 12
. 15
.
.
.
.
.
.
.
.
18
20
29
30
30
31
31
32
32
. 32
. 34
. 34
. 35
. 36
. 51
Chapitre 3. Mise à jour et migration . . 55
Stratégie de mise à jour . . . . . . . . .
Groupes de correctifs et correctifs temporaires de
WebSphere Remote Server . . . . . . . .
Tivoli Provisioning Manager-Remote Management
Agent Bridge . . . . . . . . . . . . .
Prérequis d'installation . . . . . . . .
Configuration de l'installation de TPM-RMA .
Distribution de logiciel pour TPM RMA . . .
Remote Management Agent Bridge version 2.6 .
Migration . . . . . . . . . . . . . .
Migration vers la version 7.1.1 . . . . . .
. 55
© Copyright IBM Corp. 2004, 2010
.
.
.
.
.
.
71
74
75
80
80
80
82
83
88
88
Chapitre 5. Extension . . . . . . . . 95
Extension de la solution . . . . . . . . .
WebSphere sMash . . . . . . . . . . .
Génération de la solution exemple. . . . . .
Génération du modèle . . . . . . . . .
Préparation de la solution exemple pour une
installation en mode silencieux . . . . .
Modification de la solution exemple . . . .
Extension de WebSphere Remote Server via un
modèle d'application WebSphere . . . . . .
Description du modèle . . . . . . . .
Utilisation de la solution exemple
PlantsByWebSphere . . . . . . . . .
Développement de votre propre solution . .
Création d'une application . . . . . . . .
Préparation du déploiement à distance via Tivoli
Provisioning Manager . . . . . . . . .
Contrôle des applications WebSphere Remote
Server et ISP . . . . . . . . . . . .
Extension de la gestion des mots de passe pour
gérer les applications utilisateur . . . . . .
.
.
.
.
95
97
97
97
. 100
. 100
. 101
. 102
. 109
. 110
. 116
. 119
. 121
. 125
. 55
Chapitre 6. Identification, résolution
des incidents et assistance . . . . . 129
.
.
.
.
.
.
.
Installation et utilisation d'IBM Support Assistant
129
Collecteur de journal . . . . . . . . . . . 130
Utilisation du flux de travaux du collecteur de
journaux . . . . . . . . . . . . . . 130
Astuces pour l'identification et la résolution des
incidents . . . . . . . . . . . . . . . 131
58
58
59
60
60
63
64
Chapitre 4. Gestion . . . . . . . . . 67
Contrôle de WebSphere Remote Server .
Surveillance d'événements . . . . .
Utilisation de JMX Event Listener . . . . . .
Activation du fournisseur de données WebSphere
Remote Server . . . . . . . . . . . .
Configuration du fournisseur de données
WebSphere Remote Server pour la surveillance
d'événements . . . . . . . . . . . . .
Contrôleur de messages WebSphere MQ Message
Controller . . . . . . . . . . . . . . .
Installation du contrôleur de messages
WebSphere MQ Message Controller . . . . .
Configuration du contrôleur de messages
WebSphere MQ Message Controller . . . . .
Autres approches de Message Controller . . .
Gestion des mots de passe à l'aide des flux de
travaux Tivoli Provisioning Manager . . . . . .
Installation et activation d'IBM Tivoli License
Compliance Manager . . . . . . . . . . .
Remarques relatives à la sécurité . . . . . . .
. 67
. 71
Chapitre 7. Informations de référence
139
Informations générales sur le produit .
Livres blancs . . . . . . . . .
Remarques et marques . . . . . .
. 139
. 140
. 140
.
.
.
.
.
.
.
.
.
iii
iv
Centre de documentation de WebSphere Remote Server version 7.1.1
Chapitre 1. Présentation du produit
IBM® WebSphere Remote Server est une plateforme d'architecture orientée services
(SOA) de référence pour les environnements répartis gérés à distance, qui a été
conçue pour intégrer et prendre en charge les périphériques et applications de
magasin existants et à venir.
En tant que composant principal d'IBM Retail Integration Framework, WebSphere
Remote Server fournit la base de l'innovation dans les environnements de magasin,
dans lesquels existe une forte demande de technologies de libre-service et de
contact avec la clientèle en vue de renouveler totalement l'expérience du
consommateur. WebSphere Remote Server fournit une plateforme pour concevoir,
assembler, déployer et gérer ces solutions de future génération, prenant en charge
les normes de l'industrie et protégeant les solutions existantes. Les utilisateurs
bénéficient ainsi d'une véritable plateforme prête à l'emploi, exploitant les
technologies middleware J2EE.
WebSphere Remote Server, ensemble de produits middleware IBM, doit être
installé sur un serveur de magasin. Ce serveur est appelé le processeur intégré au
magasin (ISP).
La figure 1 illustre un exemple d'environnement de magasin avec plusieurs
processeurs ISP distants. Chaque processeur ISP communique avec un serveur
d'entreprise central. Les magasins, situés sur des sites différents, disposent tous
d'un processeur ISP exécutant WebSphere Remote Server.
Figure 1. Exemple d'environnement de magasin avec plusieurs processeurs ISP distants
1
Nouveautés de cette édition
Cette rubrique décrit les améliorations et les fonctions fournies avec IBM
WebSphere Remote Server 7.1.1.
Améliorations et fonctions
v Mises à niveau pour les produits middleware et les systèmes d'exploitation
v Prise en charge de la migration automatisée de middleware pris séparément
ainsi que de la migration complète du produit
v Prise en charge de Microsoft® Windows® 7 (32 et 64 bits)
Remarque : Certains produits fournis avec WebSphere Remote Server ne
prennent pas en charge Windows 7 (32 et 64 bits) et certains
produits prennent en charge uniquement Windows 7 32 bits.
v Prise en charge de SUSE Linux® Enterprise Server 10.3
v Prise en charge de Windows XP Professionnel avec Service Pack 3
Composants disponibles
WebSphere Remote Server 7.1.1 contient les composants suivants :
v IBM Retail Store Server Starter Edition
v
v
v
v
v
IBM Retail Store Server Starter Edition with Informix Database
IBM Retail Store Server Advanced Edition
IBM Retail Store Server Advanced Edition with Informix Database
IBM Tivoli Provisioning and Monitoring pour IBM Retail Store Server
IBM WebSphere Central Site Server
v IBM WebSphere Message Broker Retail Store Edition
v IBM WebSphere Enterprise Service Bus Retail Store Edition
Pour plus d'informations sur chaque composant, voir «Versions de WebSphere
Remote Server».
Remarque : Pour les versions 7.0, 7.1 et 7.1.1, le nom du produit WebSphere
Remote Server et le nom d'édition d'IBM Retail Store Server sont
interchangeables.
Versions de WebSphere Remote Server
IBM WebSphere Remote Server version 7.1.1 contient les éditions et composants
décrits dans la présente rubrique. Consultez les dispositions du contrat de licence
(de chaque version de WebSphere Remote Server que vous utilisez) pour connaître
les restrictions en matière de produit et d'environnement.
Remarque : Pour les versions 7.0, 7.1 et 7.1.1, le nom du produit WebSphere
Remote Server et le nom d'édition d'IBM Retail Store Server sont
interchangeables.
IBM Retail Store Server Starter Edition
IBM Retail Store Server Starter Edition permet de découvrir WebSphere
Remote Server et comprend les éléments suivants :
v IBM WebSphere MQ version 7.0.1.2
v DB2 Limited Use Workgroup Edition version 9.7 Fix Pack 2
(fonctionnalité restreinte)
2
v IBM WebSphere Application Server Network Deployment version 7.0.0.9
v IBM HTTP Server version 7.0.0.9
v Accélérateurs de gestion de systèmes
v IBM WebSphere sMash version 1.1.1.5
v IBM Software Assembly Toolkit version 3.2.2
IBM Retail Store Server Starter Edition with Informix Database
IBM Retail Store Server Starter Edition with Informix Database permet de
découvrir WebSphere Remote Server et comprend les éléments suivants :
v IBM Informix Growth Edition 11.50.xC7 (pour plus d'informations, voir
«Configurations matérielle et logicielle requises», à la page 9)
v Accélérateurs de gestion de systèmes
IBM Retail Store Server Advanced Edition
IBM Retail Store Server Advanced Edition offre des performances
maximales avec toutes les fonctions d' IBM Retail Store Server Starter
Edition et comprend la fonctionnalité complète des produits DB2
Workgroup Server Edition version 9.7 Fix Pack 2 et IBM WebSphere
Application Server Network Deployment version 7.0.0.9.
IBM Retail Store Server Advanced Edition with Informix Database
IBM Retail Store Server Advanced Edition with Informix Database offre des
performances maximales avec toutes les fonctions d' IBM Retail Store
Server Starter Edition with Informix Database et comprend la
fonctionnalité complète des produits Informix Growth Edition 11.50.xC7 et
IBM WebSphere Application Server Network Deployment version 7.0.0.9.
ajoute les fonctions de surveillance et d'application des accès aux versions
Starter Edition et Advanced Edition. Ce module complémentaire comprend
les éléments suivants :
v IBM Tivoli Provisioning Manager version 7.2
v IBM Tivoli Composite Application Manager for Applications
version 6.2.3
– IBM Tivoli Monitoring version 6.2.2 groupe de correctifs 1
– IBM Tivoli Composite Application Manager Agent for DB2
version 6.2.2
– IBM Tivoli Composite Application Manager Agent for Oracle
Database version 6.2.1
– IBM Tivoli Composite Application Manager Agent for J2EE
version 6.2.0.4
– IBM Tivoli Composite Application Manager Agent for HTTP Servers
version 7.1
– IBM Tivoli Composite Application Manager Agent for WebSphere MQ
version 7.0.1
3
– IBM Tivoli Composite Application Manager Agent for WebSphere
Broker version 7.0.1
– IBM Tivoli Composite Application Manager Configuration Agent for
WebSphere MQ version 7.0.1
– IBM Tivoli Composite Application Manager Agent for WebSphere
Applications version 7.1
Remarque :
v Avant d'installer ce module complémentaire, l'une des
versions (Starter Edition ou Advanced Edition) doit être
installée sur votre système.
v Tivoli Provisioning Manager version 7.2 ne prend pas en
charge Windows 7 Edition intégrale.
IBM WebSphere Central Site Server
WebSphere Central Site Server fournit une autorisation d'utilisation
complète des produits WebSphere MQ 7.0.1.2, DB2 Workgroup Server
Edition version 9.7 Fix Pack 2 et WebSphere Application Server Network
Deployment version 7.0.0.9 avec une licence appropriée pour le
déploiement au niveau de l'entreprise.
IBM WebSphere Message Broker Retail Store Edition
IBM WebSphere Message Broker Retail Store Edition fournit une grande
variété d'options permettant d'implémenter d'un bus de service
d'entreprise universel pour davantage de connectivité et de transformation
dans des environnements informatiques hétérogènes.
IBM WebSphere Enterprise Service Bus Retail Store Edition
IBM WebSphere Enterprise Service Bus Retail Store Edition prend en
charge l'intégration de technologies orientées services, messages et
événements afin d'offrir une infrastructure de messagerie normalisée aux
entreprises souhaitant mettre en oeuvre rapidement un bus de services
d'entreprise.
Programme d'installation de WebSphere Remote Server
Le programme d'installation, qui fait partie des accélérateurs de gestion de
systèmes, installe une solution conçue à l'aide d'IBM Software Assembly Toolkit.
Cette solution consiste en un modèle d'application, IBM middleware, et un
environnement de développement Eclipse appelé Software Assembly Toolkit
Developer. Les clients, les éditeurs de logiciels indépendants et les intégrateurs
système peuvent utiliser l'environnement de développement pour remplacer le
modèle d'application par une solution qu'ils ont créée eux-mêmes.
Le programme d'installation propose quatre options d'installation :
v Installation de l'environnement d'exécution Retail Store Server 7.1.1 pour
Windows/Linux: Installation de l'environnement d'exécution Retail Store Server
7.1.1 constitué des produits middleware et exemples d'applications IBM pour
WebSphere.
v Migration à partir de WebSphere Remote Server 6.1 ou 6.2.x : mettez à niveau
une installation d'environnement d'exécution WebSphere Remote Server 6.1 ou
6.2.x existante vers les dernières versions des produits middleware Retail Store
Server 7.1.1.
4
Remarque :
– Cette tâche est disponible uniquement sur les plateformes de
migration prises en charge. Pour plus de détails, voir
«Migration», à la page 63.
– Si vous effectuez une migration depuis WebSphere Remote
Server 6.1 ou 6.2.x, vous ne pouvez l'effectuer que vers les
éditions WebSphere Remote Server avec DB2.
v Migration à partir de WebSphere Remote Server 7.0 ou 7.1 : mettez à niveau
7.1 existante vers les dernières versions des produits middleware Retail Store
Server 7.1.1.
Remarque :
– Cette tâche est disponible uniquement pour les utilisateurs des
plateformes de migration prises en charge. Pour plus de détails,
voir «Migration», à la page 63.
– Si vous effectuez une migration depuis des éditions WebSphere
Remote Server avec DB2 vous ne pouvez l'effectuer que vers les
éditions WebSphere Remote Server version 7.1.1 avec DB2. De
même, si vous effectuez une migration depuis des éditions
WebSphere Remote Server avec Informix Database, vous ne
pouvez l'effectuer que vers les éditions WebSphere Remote
Server version 7.1.1 avec Informix Database.
v Installation de l'environnement de développement de solution WebSphere
Remote Server 7.1.1 : l'environnement de développement de la solution est
constitué d'IBM Software Assembly Toolkit 3.2.2, d'un espace de travail de projet
complet et des images d'installation de tous les produits middleware.
Accélérateurs de gestion de systèmes
Les accélérateurs de gestion de systèmes correspondent à un ensemble d'outils
groupé avec toutes les éditions d'IBM Retail Store Server et avec IBM WebSphere
Central Site Server.
Les accélérateurs de gestion de systèmes (ou accélérateurs) fournissent les fonctions
suivantes :
v Installation de solution : Les DVD des accélérateurs de gestion de systèmes vous
permettent d'installer les produits IBM comme solution unique au lieu de devoir
installer chaque produit séparément.
v Migration automatisée : Les DVD des accélérateurs de gestion de systèmes
fournissent une migration automatisée à partir des versions précédentes d'IBM
WebSphere Remote Server.
v Désinstallation : Un outil est fournit pour désinstaller l'ensemble de la solution
avec une seule commande.
v Environnement de développement : L'environnement de développement vous
permet de créer votre propre solution personnalisée sur un DVD. Vous pouvez
ajouter votre propre application à la pile de logiciels WebSphere Remote Server,
supprimer les composants non désirés et personnaliser les configurations.
v Installation à distance : Les progiciels Tivoli fournis avec IBM Tivoli
Provisioning Manager vous permettent de déployer le logiciel WebSphere
Remote Server vers des milliers de serveurs à distance situés dans des magasins
de distribution.
5
v Distribution vers les périphériques du magasin : L'utilitaire de pont Tivoli
Provisioning Manager-Remote Management Agent (TPM-RMA) est fourni pour
combler l'écart entre Tivoli Provisioning Manager et IBM Remote Management
Agent.
v Contrôle à distance : Vous pouvez utiliser les outils de ligne de commande pour
démarrer, arrêter et vérifier le statut des produits middlerware exécutés sur le
serveur du magasin.
v Gestion des mots de passe : Vous pouvez utiliser Tivoli Provisioning Manager
pour gérer les mots de passe des ID utilisateur sur les serveurs du magasin.
v Collecte de journaux : Un outil est fourni pour rechercher et collecter les
journaux pour la transmission au service clients IBM si vous avez besoin d'aide.
Remarque :
v Remote Management Agent n'est pas inclus dans WebSphere
Remote Server.
v Vous devez acheter IBM Tivoli Provisioning and Monitoring pour
IBM Retail Store Server pour utiliser les extensions Tivoli.
Processeurs intégrés au magasin
Un processeur intégré au magasin (ISP) est un serveur de magasin.
Ce serveur exécute un système d'exploitation Linux ou Windows et plusieurs
périphériques y sont connectés, notamment des contrôleurs de point de vente, des
bornes d'information, des caisses automatiques, etc. Le processeur ISP exécute tous
les logiciels nécessaires à la gestion de magasin. WebSphere Remote Server est
installé sur le processeur intégré au magasin pour former une plateforme de base
pour d'autres applications.
Serveur d'entreprise
Le serveur d'entreprise est utilisé comme point de gestion centralisé de tous les
processeurs intégrés au magasin.
Les offres pour le serveur d'entreprise comprennent IBM WebSphere Central Site
Server et IBM Tivoli Provisioning and Monitoring pour IBM Retail Store Server.
Les installations de logiciels sont lancées depuis le serveur d'entreprise. C'est
également ce serveur qui reçoit les données de surveillance. Après l'installation
d'IBM WebSphere Remote Server sur tous les processeurs intégrés au magasin (ISP)
utilisant les accélérateurs, il est possible d'effectuer une grande partie de la gestion
des processeurs ISP à distance.
Le serveur d'entreprise n'est requis que pour exécuter suffisamment de logiciels
pour pouvoir lancer des installations sur les processeurs intégrés au magasin via
les accélérateurs. Par exemple, les clients FTP et Telnet.
Composants supplémentaires
Deux composants supplémentaires sont disponibles pour IBM WebSphere Remote
Server.
6
Ces composants doivent être installés dans les magasins, à un emplacement
différent de WebSphere Remote Server et sur une partition virtuelle ou une
machine physique différente. Pour plus d'informations sur ces composants,
reportez-vous aux liens suivants :
v IBM WebSphere Enterprise Service Bus Retail Store Edition Version 7.0 : Prend
en charge l'intégration de technologies orientées services, messages et
événements afin d'offrir une infrastructure de messagerie normalisée aux
entreprises souhaitant mettre en oeuvre rapidement un bus de services
d'entreprise.
v IBM WebSphere Message Broker Retail Store Edition version 7.0 : Fournit une
grande variété d'options d'implémentation d'un bus de service d'entreprise
universel pour la connectivité et la transformation dans des environnements
informatiques hétérogènes.
7
8
Chapitre 2. Installation et déploiement
Reportez-vous à ces rubriques pour préparer l'installation, installer IBM WebSphere
Remote Server et l'environnement de développement, vérifier l'installation et
déployer les agents.
WebSphere Remote Server Solution Installer permet d'installer WebSphere Remote
Server version 7.1.1 ou d'effectuer la migration vers WebSphere Remote Server
version 7.1.1 à partir des éditions précédentes. Pour plus d'informations sur les
scénarios de migration, voir Chapitre 3, «Mise à jour et migration», à la page 55
De plus, vous pouvez également installer l'environnement de développement de la
solution WebSphere Remote Server. L'environnement de développement vous
permet de développer des solutions personnalisées basées sur IBM WebSphere
Remote Server.
Remarque : L'environnement de développement n'est pas pris en charge sur les
plateformes suivantes :
v Windows Embedded POSReady 2009
v Windows 7
v Windows 2008 Server
Configurations matérielle et logicielle requises
La présente section décrit les configurations matérielle et logicielle requises pour
IBM WebSphere Remote Server et ses composants pris en charge.
Conseil : Afin d'obtenir la liste la plus récente des plateformes matérielles et
logicielles prises en charge pour toutes les éditions de WebSphere
Remote Server, voir la page relative à la configuration système requise et
le document contenant les systèmes d'exploitation pris en charge.
logiciels groupés
WebSphere Remote Server regroupe et prend en charge les niveaux de produits
IBM suivants, en fonction de leur disponibilité :
v DB2 Limited Use Workgroup Edition version 9.7 Fix Pack 2 (disponible dans la
version starter edition), DB2 Workgroup Server Edition version 9.7 Fix Pack 2
(disponible dans la version advanced edition) ou IBM Informix Growth Edition
11.50.xC71
1. La variable x représente l'une des lettres suivantes, qui identifie une plateforme :
– F = 64 bits sur n'importe quelle plateforme UNIX®/Linux
– H = 32 bits, basée sur n'importe quelle plateforme HP 11.x ; fonctionne également sur HP 11.x 64 bits
– T = plateformes Windows
– U = 32 bits sur n'importe quelle plateforme UNIX/Linux
Pour plus d'informations, consultez le tableur de la plateforme Informix.
9
Avant de commencer l'installation, examinez les configurations logicielle et
matérielle requises du processeur intégré au magasin et des serveurs d'entreprise.
Composants séparés
Les deux composants additionnels suivants sont disponibles avec WebSphere
Remote Server :
v IBM WebSphere Enterprise Service Bus Retail Store Edition version 7.0
v IBM WebSphere Message Broker Retail Store Edition version 7.0
Le logiciel suivant fait partie du module complémentaire IBM Tivoli Provisioning
and Monitoring pour IBM Retail Store Server:
v IBM Tivoli Provisioning Manager version 7.2
v IBM Tivoli Composite Application Manager for Applications version 6.2.3
– IBM Tivoli Monitoring version 6.2.2 groupe de correctifs 1
– IBM Tivoli Composite Application Manager Agent for DB2 version 6.2.2
– IBM Tivoli Composite Application Manager Agent for Oracle Database
version 6.2.1
– IBM Tivoli Composite Application Manager Agent for J2EE version 6.2.0.4
– IBM Tivoli Composite Application Manager Agent for HTTP Servers
version 7.1
– IBM Tivoli Composite Application
version 7.0.1
version 7.0.1
WebSphere MQ version 7.0.1
Applications version 7.1
Manager Agent for WebSphere MQ
Manager Agent for WebSphere Broker
Manager Configuration Agent for
Manager Agent for WebSphere
Configuration matérielle
Voici la configuration matérielle minimale requise pour le processeur intégré au
magasin et les serveurs d'entreprise.
Processeur intégré au magasin
v PC serveur IBM doté d'un processeur Intel® Pentium® 32 bits cadencé à
500 MHz (2 GHz ou plus recommandé)
v 2 Go de mémoire
v 12 Go d'espace disque
10
WebSphere Remote Server nécessite plusieurs serveurs d'entreprise. Le serveur
d'entreprise qui exécute Tivoli Provisioning Manager nécessite au minimum la
configuration matérielle suivante :
v PC serveur IBM doté d'un processeur Intel Pentium 32 bits cadencé à 500 MHz
(2 GHz ou plus recommandé)
v 2 Go de mémoire
v 12 Go d'espace disque
Configuration logicielle
Cette rubrique présente la configuration logicielle requise pour le processeur
intégré au magasin et le serveur d'entreprise IBM WebSphere Remote Server.
Processeur intégré au magasin
Environnement Tivoli
Installez Tivoli Common Agent sur chaque processeur intégré au magasin comme
indiqué dans le centre de documentationIBM Tivoli Provisioning Manager Centre
de documentation.
Remarque : Tivoli Provisioning Manager version 7.2 ne prend pas en charge
Windows 7 Edition intégrale.
Environnement non Tivoli
Les systèmes d'exploitation pris en charge par WebSphere Remote Server version
7.1.1 sont indiqués dans le tableau suivant.
Remarque :
v Le système d'exploitation Microsoft Windows Embedded POSReady
2009 est disponible uniquement dans la version 32 bits.
v Windows XP Professionnel avec Service Pack 3 est disponible
uniquement dans la version 32 bits.
Tableau 1. Logiciel pris en charge pour le processeur intégré au magasin
Système d'exploitation
Versions prises en charge
Linux
v SUSE Linux Enterprise Server 10.3
v SUSE Linux Enterprise Server 11
v Red Hat Enterprise Linux 5.3
11
Tableau 1. Logiciel pris en charge pour le processeur intégré au magasin (suite)
Versions prises en charge
Microsoft Windows
v Windows 2003 Server édition Standard ou
Enterprise avec Service Pack 2
v Windows 2003 Server R2 édition Standard
ou Enterprise avec Service Pack 2
v
Windows 2008 Server
v
Windows Embedded POSReady 2009
v Windows XP Professionnel avec Service
Pack 2 (64 bits seulement)
v
v
Windows XP Professionnel avec Service
Pack 3
Windows 7
Assurez-vous que les environnements suivants sont disponibles :
v Environnement permettant la réception de fichiers, tel qu'un serveur FTP.
v Environnement permettant d'exécuter des scripts à distance, tel qu'un serveur
SSH.
Environnement Tivoli
Pour plus d'informations sur l'installation de Tivoli Provisioning Manager,
consultez le centre de documentation IBM Tivoli Provisioning Manager Centre de
documentation.
Environnement non Tivoli
Assurez-vous que les environnements suivants sont disponibles :
v Environnement permettant de distribuer des fichiers, tel qu'un client FTP.
v Environnement permettant de se connecter à des serveurs distants, tel qu'un
client SSH.
Installation du produit
Les rubriques suivantes vous permettront d'installer IBM WebSphere Remote
Server ainsi que l'environnement de développement.
Installation d'IBM WebSphere Remote Server
La présente rubrique vous permettra d'installer IBM WebSphere Remote Server.
Avant de commencer
Si tout ou partie des middleware requis d'une version antérieure de WebSphere
Remote Server sont déjà installés, suivez les instructions fournies dans «Migration»
, à la page 63 pour effectuer l'installation.
Vous devez entrer le nom d'hôte et l'adresse IP dans le fichier hôte sur l'ordinateur
où vous installez WebSphere Remote Server. Dans le cas contraire, l'installation
échouera. Le fichier hôte se trouve au chemin /etc/hosts sous Linux et au chemin
12
%SYSTEMROOT%\System32\drivers\etc\hosts sous Windows. Vous ne devez pas
inclure de trait d'union (-) dans le nom d'hôte. Si vous le faites, l'installation
échouera.
Si vous installez le modèle d'application pour WebSphere et que vous avez besoin
du modèle Trade Performance Benchmark Sample for IBM WebSphere Remote
Server sur un poste de travail dont la langue est l'allemand, vous devez d'abord
mettre à niveau IBM WebSphere Application Server vers la version 7.0.0.11. Pour
télécharger WebSphere Application Server version 7.0.0.11, consultez la page de
support de WebSphere Application Server.
Si vous effectuez l'installation sur un système d'exploitation Windows Embedded
POSReady 2009 ou Windows XP Professionnel et souhaitez utiliser IPv6, vous
devez utiliser la procédure ci-dessous pour créer un alias pour le serveur de base
de données IBM Informix Growth Edition, affecter une adresse IPv4 au nouveau
nom de serveur de base de données supplémentaire et une adresse IPv6 au nom
de serveur de base de données Informix Growth Edition :
1. Dans le fichier onconfig du répertoire $INFORMIXDIR/etc, recherchez le
paramètre de configuration DBSERVERALIASES et ajoutez-lui un nouvel alias.
2. Utilisez l'utilitaire SetNet32 pour affecter une adresse IPv6 au nom de serveur
de base de données existant spécifié dans le paramètre DBSERVERNAME et
une adresse IPv4 au nouvel alias spécifié dans le paramètre
DBSERVERALIASES.
a. Dans le dossier contenant les produits Client SDK, cliquez deux fois sur
SetNet32 pour ouvrir l'utilitaire SetNet32.
b. Cliquez sur l'onglet des informations sur le serveur pour afficher la page
correspondante.
c. Dans la zone IBM Informix Server, sélectionnez le nom de serveur de base
de données spécifié dans le paramètre DBSERVERNAME du fichier
onconfig.
d. Dans la zone Nom hôte, entrez l'adresse IPv6 de l'hôte.
e. Cliquez sur Valider.
f. Dans la zone IBM Informix Server, ajoutez le nom de serveur de base de
données spécifié dans le paramètre DBSERVERALIASES du fichier onconfig.
g. Dans la zone Nom hôte, entrez l'adresse IPv4 de l'hôte.
h. Dans les zones Nom de protocole, Nom de service et Options, affectez des
valeurs associées au serveur de base de données spécifié dans le paramètre
DBSERVERNAME.
i. Cliquez sur Valider.
j. Cliquez sur OK.
k. Redémarrez Informix Growth Edition.
Procédure
1. Insérez le DVD du programme d'installation de WebSphere Remote Server
correspondant à la plateforme appropriée.
Remarques :
v Seule la migration depuis WebSphere Remote Server version
7.1 est prise en charge sur les systèmes d'exploitation 64 bits.
v Sous Linux, vous devez vous connecter en tant qu'utilisateur
root pour effectuer l'installation à l'aide des DVD des
accélérateurs.
13
v Sous Windows Embedded POSReady 2009, vous devez
installer le composant utilitaire de ligne de commande
facultatif avant d'installer WebSphere Remote Server version
7.1.1. Si ce composant facultatif n'est pas déjà installé,
reportez-vous aux instructions d'installation de Windows
Embedded POSReady 2009 pour plus d'informations sur son
installation.
Si le tableau de bord WebSphere Remote Server ne s'ouvre pas
automatiquement lorsque vous insérez le DVD, exécutez la commande
launchpad.exe sous Windows ou la commande launchpad.sh sous Linux à
partir du DVD. Le tableau de bord contient des informations utiles et des
liens permettant de lancer l'installation.
2. A partir du tableau de bord, sélectionnez l'installation de WebSphere Remote
Server.
Lorsque vous sélectionnez le lien d'installation de WebSphere Remote Server,
l'assistant de déploiement est provisoirement installé sur votre disque dur.
Une fois l'installation de l'assistant de déploiement terminée, celui-ci se lance
automatiquement et vous guide à travers l'installation de WebSphere Remote
Server.
3. Cliquez sur I accept both the IBM and the non-IBM terms (J'accepte les
dispositions IBM et non-IBM) pour accepter le contrat de licence, puis cliquez
sur Next (Suivant) pour poursuivre.
4. Cliquez sur Next (Suivant) lorsque la page d'accueil s'affiche pour poursuivre
l'installation.
5. Sélectionnez l'installation de l'environnement d'exécution IBM Retail Store
Server 7.1.1. Pour plus d'informations sur les autres options d'installation, voir
«Migration», à la page 63 et «Installation de l'environnement de
développement», à la page 15.
6. Sélectionnez les composants à installer.
Important :
v Si vous installez Informix Growth Edition, vous pouvez le faire
uniquement dans une partition NTFS.
v IBM HTTP Server peut uniquement être installé si vous
choisissez également d'installer WebSphere Application Server.
v Les modèles d'application peuvent uniquement être installés si
vous choisissez également d'installer les autres composants.
7. Entrez les paramètres d'installation obligatoires et facultatifs lorsque vous y
êtes invité par l'assistant de déploiement.
Pour obtenir une description détaillée de chaque zone, voir «Zones
d'installation de l'environnement d'exécution», à la page 20.
Remarque : Si vous choisissez d'activer la sécurité WebSphere Application
Server sur un système d'exploitation Linux, vous devez arrêter
WebSphere Application Server à chaque redémarrage du serveur.
8. Après avoir vérifié l'exactitude des tâches d'installation affichées dans la
fenêtre Panneau récapitulatif, lancez celles-ci.
9. Vérifiez que les tâches de déploiement ont abouti correctement. Une fois que
toutes les tâches de déploiement sont terminées, la fenêtre Etat du
déploiement vous indique si le déploiement a réussi ou non. Pour obtenir plus
d'informations sur le déploiement, vous pouvez afficher les messages détaillés
et le journal maître.
14
Pour résoudre les éventuelles erreurs d'installation, consultez les journaux
d'installation et la section «Astuces pour l'identification et la résolution des
incidents», à la page 131.
10. Si vous avez effectué l'installation sur un système d'exploitation Windows
Embedded POSReady 2009 ou Windows XP, redémarrez votre serveur pour
que le système d'exploitation puisse accéder aux mises à jour.
Que faire ensuite
Vérifiez votre installation.
Installation de l'environnement de développement
La présente rubrique vous permettra d'installer l'environnement de développement
IBM WebSphere Remote Server.
Pourquoi et quand exécuter cette tâche
L'environnement de développement se compose de Software Assembly Toolkit et
de l'espace de travail de WebSphere Remote Server. Vous pouvez, le cas échéant,
installer WebSphere sMash pour fournir un chemin de communication entre les
unités et les systèmes expéditeurs à l'aide de WebSphere MQ.
L'espace de travail comprend tous les fichiers projet et les modules de déploiement
(supports d'installation des produits middleware sous la forme d'un fichier jar)
pour un système d'exploitation spécifique. Pour développer une solution
WebSphere Remote Server personnalisée, vous devez installer les outils de
développement correspondant au système d'exploitation de votre poste de travail
de développement et l'espace de travail correspondant au système d'exploitation
de chacun de vos serveurs cibles. Vous devez installer les outils de développement
avant d'installer les espaces de travail. Si le système d'exploitation de votre poste
de travail de développement correspond au système d'exploitation de vos serveurs
cible, vous pouvez installer le poste de travail en même temps. L'espace de travail
et les modules de déploiement d'une plateforme donnée sont disponibles sur le
DVD WebSphere Remote Server destiné à cette plateforme. Pour un
développement multiplateforme ou double plateforme, vous devez installer le
poste de travail à partir du DVD WebSphere Remote Server approprié.
Par exemple, supposons que vous effectuez le développement sur un poste de
travail de la plateforme Windows mais que votre plateforme cible est Linux.
Commencez par installer Software Assembly Toolkit à partir du DVD WebSphere
Remote Server pour Windows. Pour installer l'espace de travail de WebSphere
Remote Server pour Linux, exécutez le script WindowsSetup.exe à partir du DVD
WebSphere Remote Server pour Linux. Lorsque vous exécutez le programme
d'installation de la solution pour Linux sur une machine Windows, l'installation de
l'espace de travail de WebSphere Remote Server est la seule option disponible.
Afin de créer une solution, utilisez le programme d'installation pour installer
l'environnement de développement sur un système d'exploitation Windows ou
Linux. Une fois l'environnement de développement installé, ouvrez Software
Assembly Toolkit Developer.
Remarque : L'environnement de développement n'est pas pris en charge sur les
plateformes suivantes :
v Windows Embedded POSReady 2009
v Windows 7
15
v Windows 2008 Server
Procédure
Remarques :
accélérateurs.
installation.
Server.
Server.
l'installation.
5. Choisissez d'installer l'environnement de développement de la solution IBM
Retail Store Server.
6. Indiquez les composants à installer. Ces composants sont Software Assembly
Toolkit, WebSphere sMash et l'espace de travail d'IBM Retail Store Server.
Remarque : Le composant WebSphere sMash n'est pas disponible dans IBM
WebSphere Central Site Server.
Pour obtenir plus de détails sur chaque zone, voir «Zones d'installation de
l'environnement de développement», à la page 28.
7. Indiquez les paramètres d'installation obligatoires et facultatifs lorsque
l'assistant vous y invite.
Si une version antérieure de Software Assembly Toolkit a été installée sur le
serveur, le composant Software Assembly Toolkit inclus dans WebSphere
Remote Server version 7.1.1 sera installé par défaut dans un nouvel
emplacement. Les différentes versions de Software Assembly Toolkit
coexisteront sur le serveur.
16
Remarque : Des versions différentes d'IBM Software Assembly Toolkit
peuvent cohabiter mais ce n'est pas le cas des groupes de
correctifs ou de mises à jour apparentés. Par conséquent, si vous
installez l'environnement de développement de solution
WebSphere Remote Server version 7.1.1 alors que l'environnement
de développement de solution WebSphere Remote Server version
7.1 a déjà été installé, Software Assembly Toolkit version 3.2.1
sera automatiquement mis à niveau vers Software Assembly
Toolkit version 3.2.2.
9. Vérifiez que les tâches de déploiement ont abouti correctement.
10. Ouvrez Software Assembly Toolkit Developer.
Dans le menu Démarrer, sélectionnez Tous les programmes →
IBM Software Assembly Toolkit 3.2 → Software Assembly Toolkit
Developer.
Exécutez la commande cd /opt/IBM/SAT/3.2/SolutionEnabler
./IRU_Developer.sh
Remarque : Si vous effectuez l'installation sur le système d'exploitation SUSE
Linux Enterprise Server 10.3 (64 bits), Software Assembly Toolkit
Developer ne s'ouvrira pas. Pour savoir comment résoudre ce
problème, consultez la section «Software Assembly Toolkit
Developer ne s'ouvre pas sous SUSE Linux Enterprise Server 10.3
(64 bits)», à la page 136 de la rubrique Astuces pour
l'identification et la résolution des incidents.
11. Au démarrage d'Software Assembly Toolkit Developer, une boîte de dialogue
vous demande l'emplacement de l'espace de travail à ouvrir. Sélectionnez
l'emplacement spécifié lors de l'installation de l'environnement du
développeur de solutions et cliquez sur OK. Par défaut, l'espace de travail se
trouve à l'emplacement suivant :
C:\Program Files\IBM\SIF\workspace\wrs711
/opt/IBM/SIF/workspace/irss711
Remarque : Si vous effectuez l'installation sur le système d'exploitation Red
Hat Enterprise Linux 64 bits, l'espace de travail s'ouvre avec deux
exceptions attendues répertoriées dans la vue du journal des
erreurs. Pour plus d'informations, voir la section «Exception
Software Assembly Toolkit après l'installation», à la page 136 de
la rubrique Astuces pour l'identification et la résolution des
incidents.
A l'ouverture de la fenêtre d'application, une page d'accueil s'affiche.
12. Fermez la page d'accueil pour afficher le plan de travail et les projets qui
forment l'espace de travail.
Si vous n'êtes pas familier avec Software Assembly Toolkit Developer,
consultez l'aide intégrée en suivant les étapes ci-dessous :
a. Sélectionnez Aide, puis Table des matières de l'aide dans la barre de
menus d'Software Assembly Toolkit Developer. Une fenêtre intitulée Aide IBM Software Assembly Toolkit Developer s'ouvre.
b. Dans le panneau Table des matières, cliquez sur le lien concernant
l'utilisation de Software Assembly Toolkit Developer.
17
Que faire ensuite
Pour plus d'informations sur Software Assembly Toolkit, visitez le centre de
documentation de Software Assembly Toolkit.
Installation de WebSphere Remote Server à distance
IBM WebSphere Remote Server peut être installé à distance à l'aide d'IBM Tivoli
Provisioning Manager. La pile d'exécution WebSphere Remote Server peut être
installée à distance sur une machine qui ne possède aucune version précédente de
WebSphere Remote Server installée.
Important : Avant de commencer, Tivoli Provisioning Manager 7.2 doit être installé
sur un serveur et Tivoli éditeur de progiciels doit être installé sur une
machine de développement Windows distincte. Pour plus
d'informations sur Tivoli Provisioning Manager 7.2, voir Tivoli
Provisioning Manager Centre de documentation.
Pour installer WebSphere Remote Server à distance, vous devez effectuer les étapes
ci-dessous. Des informations détaillées sur chaque étape sont fournies dans les
sections associées.
1. «Personnalisation du DVD WebSphere Remote Server».
2. Créez les progiciels.
3. Sauvegardez les progiciels dans un référentiel de fichiers.
4. Publiez, distribuez et installez le progiciel.
Personnalisation du DVD WebSphere Remote Server
Pour installer WebSphere Remote Server à distance, vous devez personnaliser le
DVD pour une installation en mode silencieux. Pour personnaliser le DVD
WebSphere Remote Server, procédez comme suit :
1. Copiez le DVD sur le disque dur de la machine de développement. Par
exemple :
xcopy d:\ C:\nomDVD /i /e
mkdir /tmp/nomDVD cp –r /media/cdrom/ /tmp/nomDVD
La valeur de nomDVD est Irss<plateforme>With<bd>DVD pour les systèmes
d'exploitation 32 bits et Irss<plateforme>With<bd>DVD_x64 pour les systèmes
d'exploitation 64 bits. La valeur de la variable <plateforme> est Windows ou Linux
en fonction de votre système d'exploitation. La valeur de <bd> est Db2 ou
Informix, en fonction de l'édition.
2. Editez le fichier de tâches (task.xml) du répertoire de tâches. Pour connaître la
liste de variables pouvant être définies, voir «Zones de saisie de l'assistant de
déploiement», à la page 20. Par exemple :
C:\nomDVD\tasks
/tmp/nomDVD/tasks
Le fichier task.xml contient les paramètres d'entrée destinés à chaque produit
middleware de la pile d'exécution WebSphere Remote Server.
3. Editez le fichier C:\nomDVD\IRU_install.properties. Il s'agit du fichier de
réponses de l'assistant de déploiement. Indiquez les paramètres suivants dans
ce fichier pour effectuer l'installation en mode silencieux, accepter le contrat de
licence et spécifier le fichier de tâches choisi à l'étape 2 :
–silent=true
-taskFile=<chemin du fichier xml de tâches>
18
4. Si vous souhaitez spécifier les composants de WebSphere Remote Server qui
seront installés, éditez le fichier task.xml. Commentez les tâches
correspondantes aux produits que vous ne souhaitez pas installer. Par exemple,
pour supprimer IBM WebSphere MQ de votre installation, éditez le fragment
du fichier de tâches pour WebSphere MQ de la manière suivante :
<!-<deploy taskNumber="3">
<targetHostnames>
<targetHostname>localhost</targetHostname>
</targetHostnames>
<applications>
<application id="Mq_701_Win">
<variables>
</variables>
</application>
</applications>
</deploy>
-->
Création des progiciels
WebSphere Remote Server comprend des fichiers de définition de progiciel (SPD)
Tivoli d'exemple. Ces fichiers SPD sont des fichiers texte pouvant être modifiés à
l'aide d'un éditeur de texte ou de l'éditeur de progiciels Tivoli. Les fichiers SPD
contiennent des commandes d'installation et des pointeurs vers les fichiers
installables du disque. Ouvrez le fichier SPD dans l'éditeur de progiciels, puis
sauvegardez-le en tant que fichier de bloc de progiciel (SPB). L'éditeur de
progiciels compresse tous les fichiers et les commandes nécessaires pour installer le
module dans un fichier SPB. Le fichier SPB est sauvegardé dans un référentiel de
fichiers où il peut être utilisé par le serveur Tivoli Provisioning Manager.
En règle générale, un seul fichier SPB est requis pour l'installation d'un produit
logiciel. Cependant, la taille des fichiers SPB est limitée à 2 Go. Etant donné que la
taille des images d'installation de la pile d'exécution de WebSphere Remote Server
dépasse 2 Go, trois ou quatre fichiers SPB sont nécessaires pour installer le produit
Chacun des deux ou trois premiers fichiers SPD contient des références vers
environ la moitié des fichiers du DVD WebSphere Remote Server. Le troisième ou
le quatrième fichier SPD contient uniquement les commandes d'installation. Ainsi,
les fichiers SPB générés à partir des deux ou trois premiers fichiers SPD sont plutôt
volumineux (environ 2 Go chacun), tandis que le troisième ou le quatrième fichier
SPB est plutôt petit.
Les fichiers SPD d'exemple se trouvent dans le répertoire tpmFiles du DVD
WebSphere Remote Server. (Par exemple, C:\nomDVD\tpmFiles ou
/tpm/nomDVD/tpmFiles si vous avez copié le DVD sur le disque dur, comme
indiqué précédemment.)
Les noms des fichiers SPD pour les systèmes d'exploitation 32 bits sont les suivants
:
v
v
v
v
Irss<plateforme>With<bd>DvdPart1.spd
Irss<plateforme>With<bd>.spd
19
Remarque : La valeur de la variable <plateforme> est Windows ou Linux en fonction
de votre système d'exploitation. La valeur de la variable <bd> est Db2
sous Windows et Informix sous Linux.
Les noms des fichiers SPD pour les systèmes d'exploitation 64 bits sont les suivants
:
v
v
v
v
Irss<plateforme>With<bd>x64DvdPart1.spd
Irss<plateforme>With<bd>x64.spd
Les fichiers SPD d'exemple contiennent des références aux fichiers de
l'arborescence de répertoire C:\nomDVD, qui correspond à l'emplacement où vous
avez copié le DVD WebSphere Remote Server sur le disque dur. Si vous avez copié
le DVD dans un autre emplacement, mettez à jour la variable source dans les
fichiers SPD. Recherchez et mettez à jour si nécessaire la section suivante dans les
fichiers SPD :
default_variables
source = répertoire de votre machine de développement
destination = répertoire de la machine de noeud final cible
end
Sauvegarde des progiciels dans le référentiel de fichiers
Ouvrez les fichiers SPD dans éditeur de progiciels, puis sauvegardez-les en tant
que fichiers SPB dans un référentiel de fichiers accessible par le serveur Tivoli
Provisioning Manager. Pour plus d'informations sur la configuration du référentiel
de fichiers, voir Tivoli Provisioning Manager Centre de documentation.
Publication, répartition et installation du progiciel
Une fois que vous avez sauvegardé les fichiers SPB dans le référentiel de fichiers,
vous pouvez utiliser Tivoli Provisioning Manager pour publier, répartir et installer
les fichiers SPB. Pour plus d'informations sur les fichiers du progiciel, voir
«Création des progiciels», à la page 19 de cette rubrique.
Zones de saisie de l'assistant de déploiement
La présente section décrit les zones de saisie pour chaque section du programme
d'installation.
Zones d'installation de l'environnement d'exécution
Sélection de tâches
La fenêtre Sélection de tâches vous demande quel type d'installation IBM
WebSphere Remote Server vous souhaitez effectuer :
v Installation de l'environnement d'exécution Retail Store Server 7.1.1 pour
Windows/Linux: Installation de l'environnement d'exécution Retail Store Server
7.1.1 constitué des produits middleware et exemples d'applications IBM pour
WebSphere.
v Migration à partir de WebSphere Remote Server 6.1 ou 6.2.x : mettez à niveau
6.2.x existante vers les dernières versions des produits middleware Retail Store
Server 7.1.1.
20
Remarque :
– Cette tâche est disponible uniquement sur les plateformes de
migration prises en charge. Pour plus de détails, voir
«Migration», à la page 63.
– Si vous effectuez une migration depuis WebSphere Remote
Server 6.1 ou 6.2.x, vous ne pouvez l'effectuer que vers les
éditions WebSphere Remote Server avec DB2.
v Migration à partir de WebSphere Remote Server 7.0 ou 7.1 : mettez à niveau
7.1 existante vers les dernières versions des produits middleware Retail Store
Server 7.1.1.
Remarque :
– Cette tâche est disponible uniquement pour les utilisateurs des
plateformes de migration prises en charge. Pour plus de détails,
voir «Migration», à la page 63.
– Si vous effectuez une migration depuis des éditions WebSphere
Remote Server avec DB2 vous ne pouvez l'effectuer que vers les
éditions WebSphere Remote Server version 7.1.1 avec DB2. De
même, si vous effectuez une migration depuis des éditions
WebSphere Remote Server avec Informix Database, vous ne
pouvez l'effectuer que vers les éditions WebSphere Remote
Server version 7.1.1 avec Informix Database.
v Installation de l'environnement de développement de solution WebSphere
Remote Server 7.1.1 : l'environnement de développement de la solution est
constitué d'IBM Software Assembly Toolkit 3.2.2, d'un espace de travail de projet
complet et des images d'installation de tous les produits middleware.
Composant de base IBM Retail Store Server
Variables typiques
v Répertoire d'installation : chemin d'accès complet au répertoire d'installation
des fichiers image du composant de base IBM Retail Store Server.
Variables avancées
v Alias de nom d'hôte : alias du nom d'hôte qui sera utilisé pour configurer les
composants middleware.
DB2 Workgroup Server Edition
Installations sous Linux
des fichiers images de l'installation d'DB2.
v ID utilisateur-administrateur : ID utilisateur utilisé pour se connecter à DB2 en
tant qu'administrateur DB2. Cet utilisateur sera créé s'il n'existe pas déjà. Cet ID
utilisateur doit être différent des ID utilisateur isolés et d'instance.
v Mot de passe administrateur : mot de passe utilisé par l'utilisateuradministrateur DB2 défini ci-dessus. Si l'utilisateur existe déjà, ce mot de passe
doit correspondre au mot de passe de l'utilisateur. Sinon, l'utilisateur sera créé et
le mot de passe donné ici lui sera attribué.
v ID utilisateur d'instance : ID utilisateur qui commande tous les processus DB2
et détient tous les systèmes de fichiers et les périphériques utilisés par les bases
21
v
v
v
v
v
de données contenues dans l'instance. Cet utilisateur sera créé s'il n'existe pas
déjà. Cet ID utilisateur doit être différent de l'ID utilisateur-administrateur.
Mot de passe utilisateur d'instance : mot de passe utilisé pour l'utilisateur
d'instance DB2 défini ci-dessus. Si l'utilisateur existe déjà, ce mot de passe doit
correspondre au mot de passe de cet utilisateur. Sinon, l'utilisateur sera créé et le
mot de passe donné ici lui sera attribué.
ID utilisateur isolé : l'utilisateur isolé est utilisé pour exécuter des fonctions
définies par l'utilisateur et des procédures mémorisées en dehors de l'espace
adresse utilisé par la base de données DB2. Cet utilisateur sera créé s'il n'existe
pas déjà. L'ID utilisateur isolé pourrait être le même que l'ID utilisateur
d'instance ; cependant, nous vous le déconseillons pour les systèmes de
production.
Mot de passe utilisateur isolé : mot de passe utilisé pour l'utilisateur isolé DB2.
Si l'utilisateur existe déjà, ce mot de passe doit correspondre au mot de passe de
cet utilisateur. Sinon, l'utilisateur sera créé et le mot de passe donné ici lui sera
attribué.
Voulez-vous installer le centre de contrôle DB2 ? : si cette option est
sélectionnée, le programme installe le centre de contrôle DB2.
Demandes de langues pour le portugais, le chinois simplifié, l'allemand, le
français, l'espagnol, l'italien, le japonais, le coréen, le chinois traditionnel, le
polonais, le russe : installez ce support de langue en complément des autres
langues spécifiées. La version anglaise est toujours installée.
Installations sous Windows
des fichiers images de l'installation d'DB2.
v ID utilisateur-administrateur DB2 : ID utilisateur utilisé pour se connecter à
DB2 en tant qu'administrateur DB2. Cet utilisateur sera créé s'il n'existe pas déjà.
v Mot de passe administrateur DB2 : mot de passe utilisé par
l'utilisateur-administrateur DB2 défini ci-dessus. Si l'utilisateur existe déjà, ce
mot de passe doit correspondre au mot de passe de cet utilisateur. Sinon,
l'utilisateur sera créé et le mot de passe donné ici lui sera attribué.
v Vérification du mot de passe : permet de vérifier le mot de passe
administrateur DB2 que vous avez défini dans la zone précédente.
v Voulez-vous installer le centre de contrôle DB2 ? : si cette option est
sélectionnée, le programme installe le centre de contrôle DB2.
v Créer des raccourcis dans le menu Démarrer ? : Si cette option est sélectionnée,
des raccourcis vers différentes fonctions DB2 dans le menu Démarrer Windows
sont créés.
v Demandes de langues pour le portugais, le chinois simplifié, l'allemand, le
français, l'espagnol, l'italien, le japonais, le coréen, le chinois traditionnel, le
polonais, le russe : installez ce support de langue en complément des autres
langues spécifiées. La version anglaise est toujours installée.
IBM Informix Growth Edition
Installations sous Linux
des fichiers images de l'installation d'Informix Growth Edition.
v Mot de passe pour l'utilisateur Informix Growth Edition : il s'agit de
l'utilisateur qui dispose de droits d'accès aux comptes sur l'instance Informix
Growth Edition.
22
v Vérification du mot de passe : permet de vérifier le mot de passe utilisateur
que vous avez entré dans la zone précédente.
v Serveur de base : serveur de base central pour les opérations d'administrateur
de base de données élémentaires (sans extensions, bibliothèques ou utilitaires
facultatifs).
v Client SDK version 3.00 : le kit de développement de logiciels client IBM
Informix comprend plusieurs API permettant aux développeurs d'écrire des
applications pour les serveurs de bases de données Informix en langage ESQL, C
et Java™. Vous pouvez également écrire des applications Informix en langage
ESQL/C pour le serveur de bases de données DB2. IBM Informix Connect
contient les bibliothèques d'exécution des API incluses dans le kit de
développement de logiciels client.
v IConnect version 3.00 : IBM Informix Connect contient les bibliothèques
d'exécution des API incluses dans le kit de développement de logiciels client. Si
vous choisissez d'installer le kit de développement de logiciels client, IConnect
ne sera pas installé.
v Extensions du serveur de la base : outils d'administration de bases de données
et extensions de programmation.
v J/Foundation : permet l'écriture de routines définies par l'utilisateur en langage
de programmation Java.
v Modules DataBlade intégrés : permettent l'exécution de tâches telles que la
gestion de l'emplacement des objets LOB, le support des transactions MQ, la
publication XML et la prise en charge des types UDT binaires.
v Prise en charge des conversions et réversions : cette fonction est requise pour
la migration vers et depuis d'autres versions du serveur de bases de données.
v Fonction de publication XML : contient un ensemble de fonctions de
publication des requêtes SQL au format XML.
v Support global des langues nationales : fichiers permettant la prise en charge
des langues, conventions culturelles et jeux de codes. Ces fichiers ne sont pas
nécessaires si l'environnement local par défaut est l'anglais américain (langue par
défaut dans IDS lorsqu'aucune fonction de support global des langues nationales
n'est installée.
v Europe occidentale et Amériques : environnements danois, néerlandais, anglais,
finnois, français, allemand, islandais, italien, norvégien, portugais, espagnol et
suédois.
v Europe de l'est et alphabet cyrillique : environnements tchèque, polonais, russe
et slovaque.
v Chinois : environnements chinois traditionnel et simplifié.
Japonais : environnement japonais.
Coréen : environnement coréen.
Autre : autres environnements.
Sauvegarde et restauration : utilitaires requis pour la sauvegarde et la
restauration des données du serveur de la base.
v Utilitaires ON-Bar : script de shell éditable sous UNIX et fichier de traitement
par lots (onbar.dat) permettant de lancer le pilote correspondant sous Windows.
Utilisez ce script ou ce fichier et les commandes associées pour personnaliser vos
opérations de sauvegarde et de restauration et vérifier la version du gestionnaire
de stockage.
v Interface Informix pour Tivoli Storage Manager : permet d'implémenter les
fonctions XBSA utilisant Tivoli Storage Manager et ON-Bar.
v
v
v
v
23
v Informix Storage Manager : permet de gérer les périphériques et supports de
stockage externes contenant des sauvegardes.
v Utilitaire archecker : permet de vérifier les sauvegardes et de restaurer certaines
parties d'une base de données, des tables, des parties de tables ou des ensembles
de tables.
v Exemples de démonstration : bases de données de démonstration et exemples.
v Utilitaires de chargement de données : facilitent le chargement et le
déchargement des données dans certaines configurations.
v Utilitaires de déchargement et de chargement de données : permettent le
déchargement des données d'une base de données, puis leur rechargement dans
une base de données.
v Utilitaire dbload : permet de charger les données dans des bases de données ou
des tables créées par les produits IBM Informix. Utilisez-le pour transférer les
données d'un ou plusieurs fichiers texte dans une ou plusieurs tables existantes.
v High-Performance Loader (HPL) : ce programme permet le chargement et le
déchargement efficaces d'une grande quantité de données vers ou depuis une
base de données.
v Réplication des données d'entreprise : cette fonction permet de répliquer des
données entre des serveurs de base de données IBM Informix Dynamic Server.
v Utilitaires d'administration : jeux de fonctions supplémentaires pour les
utilitaires d'administration.
v Utilitaires d'analyse des performances : permettent de surveiller les
performances du système via les utilitaires ON-Monitor et onperf.
v Utilitaires d'analyse divers : ces utilitaires permettent d'afficher le journal
logique via l'utilitaire onlog, ou de gérer le serveur de base de données via
SNMP et l'utilitaire onsnmp.
v Utilitaires de contrôle : permettent d'administrer les masques d'audit, les traces
et autres informations d'audit sur le serveur de base de données à l'aide des
utilitaires onaudit et onshowaudit.
v Utilitaires d'importation et d'exportation de base de données : permettent le
déchargement d'une base de données ou d'un schéma de base de données dans
des fichiers texte ou la création et le remplissage d'une base de données à partir
de ces fichiers.
v Séparation des rôles : sélectionnez Oui pour activer la séparation des rôles ou
Non pour la désactiver.
v Compte de groupe de l'administrateur de bases de données : groupe chargé
des tâches d'administration générales (rôle d'administration de systèmes de base
de données). Ceci s'applique uniquement si vous choisissez d'activer la
séparation des rôles.
v Séparation des rôles - Groupe du responsable de la sécurité des bases de
données : groupe du responsable de la sécurité des bases de données pour les
tâches de sécurité de niveau système. Ceci s'applique uniquement si vous
choisissez d'activer la séparation des rôles.
v Séparation des rôles - Groupe du responsable d'audit : groupe du responsable
d'audit pour les tâches d'administration d'audit. (rôle de responsable d'analyse
d'audit). Ceci s'applique uniquement si vous choisissez d'activer la séparation
des rôles.
v Séparation des rôles - Groupes des utilisateurs : groupe des utilisateurs de
base de données. Ceci s'applique uniquement si vous choisissez d'activer la
24
v Création d'un serveur de bases de données de démonstration : état de la
sélection du serveur de démonstration. Sélectionnez create (créer) pour indiquer
que le serveur de base de données de démonstrations doit être créé. Sélectionnez
nocreate (ne pas créer) pour indiquer que le serveur de base de données de
démonstrations ne doit pas être créé.
v Fichier onconfig préexistant : cette option indique si le système doit ou non
utiliser le fichier onconfig préexistant pour la configuration du serveur de
démonstration. Sélectionnez oui pour utiliser un fichier onconfig existant.
Sélectionnez no pour utiliser les valeurs séparées que vous avez fournies. Si
cette valeur est paramétrée sur oui, vous devez indiquer un fichier dans
l'argument de chemin onconfig.
v Chemin d'accès au fichier onconfig préexistant : chemin d'accès au fichier
onconfig qui sera utilisé. Cette zone est nécessaire uniquement si vous
sélectionnez oui dans la zone Fichier onconfig préexistant.
v Nom du serveur : nom du serveur de base de données pour l'instance de base
de données de démonstration.
v Numéro du serveur : valeur du serveur de base de données de démonstration.
Les valeurs acceptées sont des nombres entiers compris entre 0 et 255.
v Racine : chemin d'accès complet à la zone de stockage de l'espace de base de
données racine du serveur de base de données de démonstration.
v Taille de l'espace racine : taille de l'espace de base de données racine du
serveur de bases de données de démonstration.
v Pool de mémoire tampon : informations non fournies par défaut sur le pool de
mémoire tampon qui correspond au serveur de bases de données de
démonstration.
v Nombre de processeurs virtuels d'UC : nombre de processeurs virtuels d'UC à
configurer pour le serveur de bases de données de démonstration.
v Sélection du terminal : terminal qui sera lancé à la fin de l'installation et de la
création d'une instance de base de données de démonstration. Si vous
sélectionnez other (autre), affectez l'option Saisie manuelle du terminal à
l'emplacement du terminal de votre choix.
v Saisie manuelle du terminal : terminal que vous souhaitez utiliser. Par exemple,
lancez xterm en saisissant manuellement l'option dans la commande suivante :
/usr/bin/xterm
Installations sous Windows
des fichiers images de l'installation d'Informix Growth Edition.
v Mot de passe pour l'utilisateur Informix Growth Edition : il s'agit de
l'utilisateur qui dispose de droits d'accès aux comptes sur l'instance Informix
Growth Edition.
que vous avez entré dans la zone précédente.
v Activer la séparation des rôles : sélectionnez Oui pour activer la séparation des
rôles ou Non pour la désactiver.
v Compte de groupe de l'administrateur de bases de données : groupe chargé
des tâches d'administration générales (rôle d'administration de systèmes de base
de données). Ceci s'applique uniquement si vous choisissez d'activer la
v Séparation des rôles - Compte de groupe du responsable de la sécurité des
bases de données : groupe du responsable de la sécurité des bases de données
25
pour les tâches de sécurité de niveau système. Ceci s'applique uniquement si
vous choisissez d'activer la séparation des rôles.
v Séparation des rôles - Compte de l'utilisateur responsable de la sécurité des
bases de données : groupe du responsable de la sécurité des bases de données
v Séparation des rôles - Mot de passe de l'utilisateur responsable de la sécurité
des bases de données : mot de passe utilisateur du responsable de la sécurité
que vous avez entré dans la zone précédente. Ceci s'applique uniquement si
v Séparation des rôles - Compte de groupe du responsable de l'analyse d'audit :
groupe de responsable d'audit pour les tâches d'administration d'audit (rôle de
responsable de l'analyse d'audit). Ceci s'applique uniquement si vous choisissez
d'activer la séparation des rôles.
v Séparation des rôles - Compte de l'utilisateur responsable de l'analyse
d'audit : utilisateur responsable d'audit pour les tâches d'administration d'audit
(rôle de responsable de l'analyse d'audit). Ceci s'applique uniquement si vous
choisissez d'activer la séparation des rôles.
v Séparation des rôles - Mot de passe de l'utilisateur responsable de l'analyse
d'audit : mot de passe de l'utilisateur responsable d'audit pour les tâches
d'administration d'audit. Ceci s'applique uniquement si vous choisissez d'activer
la séparation des rôles.
que vous avez entré dans la zone précédente. Ceci s'applique uniquement si
v Séparation des rôles - Groupes des utilisateurs : groupe des utilisateurs de
base de données. Ceci s'applique uniquement si vous choisissez d'activer la
v Nom du serveur : nom du serveur de bases de données qui identifie ce dernier
auprès des applications client. Dans la plupart des cas, vous pouvez choisir la
valeur par défaut.
v Initialiser le serveur ? : si vous sélectionnez Oui toutes les données existantes
seront perdues.
v Nom de service : nom du service Windows pour l'instance de base de données
Informix Growth Edition. Ceci s'applique uniquement si l'option Initialiser le
serveur est sélectionnée.
v Port : indiquez le numéro de port pour le protocole TCP/IP. Ce numéro indique
le port d'entrée des données du serveur de bases de données dans le registre
sqlhosts. Ceci s'applique uniquement si l'option Initialiser le serveur est
sélectionnée.
v Numéro du serveur : le numéro du serveur de bases de données identifie ce
dernier de manière unique lorsque plusieurs instances du serveur sont installées.
Si une seule instance de la base de données est installée, paramétrez cette valeur
sur 0. Ceci s'applique uniquement si l'option Initialiser le serveur est
sélectionnée.
v Nom de l'espace de base de données : un espace de base de données est un
ensemble logique de blocs auxquels des bases de données et des tables sont
affectées. Ceci s'applique uniquement si l'option Initialiser le serveur est
sélectionnée.
26
v Emplacement des données principales de l'espace de base de données :
correspond à l'emplacement de l'espace de base de données. Ceci s'applique
uniquement si l'option Initialiser le serveur est sélectionnée.
v Taille de l'espace de base de données : en mégaoctets. Ceci s'applique
uniquement si l'option Initialiser le serveur est sélectionnée.
v Nom de l'espace sbspace : un espace sbspace est une zone de stockage logique
utilisée par le serveur de bases de données pour stocker les objets volumineux
intelligents (données CLOB et BLOB). Ceci s'applique uniquement si l'option
Initialiser le serveur est sélectionnée.
v Emplacement des données principales de l'espace sbspace : emplacement de
l'espace sbspace. Ceci s'applique uniquement si l'option Initialiser le serveur est
sélectionnée.
v Taille de l'espace sbspace : en mégaoctets. Ceci s'applique uniquement si
l'option Initialiser le serveur est sélectionnée.
v Taille de page de l'espace sbspace : la taille de page de l'espace sbspace doit
correspondre approximativement à celle des objets volumineux intelligents le
plus fréquemment contenus dans l'espace sbspace. La valeur par défaut est
une page. Ceci s'applique uniquement si l'option Initialiser le serveur est
sélectionnée.
v Installer le pilote JDBC ? : le pilote JDBC permet aux programmeurs Java
d'accéder aux bases de données à partir d'applications ou d'applets Java.
v Installer Informix Connect : Informix Connect (IConnect) contient les
bibliothèques d'exécution des API incluses dans le kit de développement de
logiciels client.
v
v
v
v
Remarque : WebSphere Remote Server ne prend pas en charge IConnect sur les
plateformes Windows 64 bits. Si vous recherchez des fonctions
IConnect sur une plateforme Windows 64 bits, installez le kit de
développement de logiciels client. Celui-ci est un sur-ensemble
d'IConnect et en possède toutes les fonctions.
Installer Client Software Developer's Kit? : ce kit de développement de
logiciels inclut plusieurs API que les développeurs peuvent utiliser pour écrire
des applications destinées aux serveurs de base de données.
Installer le kit de développeur DataBlade? : ce kit de développement de
logiciels inclut des outils permettant de développer et de conditionner des
modules DataBlade.
Installer BladeManage ? : cet outil permet d'enregistrer de nouveaux modules
DataBlade dans la base de données.
Installer ClusterIt ? : utilitaire de configuration de cluster.
WebSphere MQ
Les zones marquées par une balise Linux ou Windows sont disponibles
uniquement dans l'installation de cette plateforme.
Mot de passe de l'utilisateur MQM : mot de passe employé pour
v
l'utilisateur MQM.
Vérification du mot de passe : permet de vérifier le mot de passe
v
utilisateur que vous avez entré dans la zone précédente.
Répertoire d'installation : chemin d'accès complet au répertoire
v
d'installation des fichiers images de l'installation d'IBM WebSphere MQ.
27
Remarque : Ne modifiez pas l'emplacement d'installation de WebSphere MQ
lors de la migration de WebSphere Remote Server version 6.1 vers
la version 7.1.1. La modification de l'emplacement d'installation
empêche la désinstallation du composant WebSphere MQ lors de
l'exécution du programme de désinstallation de WebSphere Remote
Server. Si la désinstallation de tout composant de WebSphere
Remote Server échoue, le composant de base de WebSphere Remote
Server n'est pas désinstallé. Pour plus d'informations, voir «Astuces
pour l'identification et la résolution des incidents», à la page 131.
v Voulez-vous installer MQ Explorer ? : Si cette option est sélectionnée,
WebSphere MQ Explorer sera installé.
WebSphere Application Server Network Deployment
des fichiers images de l'installation d'IBM WebSphere Application Server
Network Deployment.
Configuration des profils autonomes WebSphere Application Server
v Nom du profil WebSphere Application Server : nom du profil à créer. Le nom
du profil doit être unique pour cette installation IBM WebSphere Application
Server.
v Nom de poste : nom de poste de WebSphere Application Server. Le nom de
poste doit être unique dans une cellule.
v Activer la sécurité administrative : si la valeur est true, les utilisateurs doivent
se connecter lorsqu'ils accèdent aux outils d'administration de WebSphere. Un
utilisateur et un mot de passe administratifs sont requis lorsque cette option est
activée.
v Utilisateur administratif : (requis en cas d'utilisation de la sécurité
administrative). ID utilisateur d'accès aux outils d'administration de WebSphere
Application Server.
v Mot de passe de l'utilisateur administratif : (requis en cas d'utilisation de la
sécurité administrative). Mot de passe d'accès aux outils d'administration de
WebSphere Application Server.
d'administration que vous avez entré dans la zone précédente.
v Activer WebSphere pour qu'il s'exécute en tant que service : si la valeur est
true, le serveur WebSphere Application Server sera configuré pour s'exécuter en
tant que service.
IBM HTTP Server
des fichiers images de l'installation d'IBM HTTP Server.
v Port HTTP : indiquez le port par défaut utilisé par le serveur IBM HTTP Server.
v Port du serveur d'administration : indiquez le port par défaut utilisé par le
serveur d'administration.
v Installer le plug-in IBM HTTP Server pour WebSphere Application Server? :
indiquez si le plug-in WebSphere Application Server doit être installé.
Zones d'installation de l'environnement de développement
Sélection de tâches
La fenêtre Sélection de tâches vous invite à indiquer le type d'installation effectué :
28
v Installez Software Assembly Toolkit 3.2.2 : ces outils de développement
fournissent un environnement de développement intégré Eclipse avec le plug-in
Software Assembly Toolkit Developer.
v Installez WebSphere sMash 1.1.1.5 : pour plus d'informations sur cette option,
voir «WebSphere sMash», à la page 97.
v Installez l'espace de travail IBM Retail Store Server 7.1.1 : installez l'espace de
travail et les modules de déploiement pour IBM Retail Store Server 7.1.1.
L'espace de travail contient tous les projets et les codes nécessaires au
développement de solutions personnalisées avec IBM Retail Store Server. Les
modules de déploiement contiennent tous les supports d'installation pour les
produits middleware sur lesquels se fonde IBM Retail Store Server. L'espace de
travail et les modules de déploiement pour Windows peuvent également être
installés sur un serveur de développement Linux pour un développement
multiplateforme. De même, l'espace de travail et les modules de déploiement
pour Linux peuvent également être installés sur un serveur de développement
Windows.
Composant de base IBM Retail Store Server
Variables typiques
des fichiers image du composant de base IBM Retail Store Server.
Variables avancées
v Alias de nom d'hôte : alias du nom d'hôte qui sera utilisé pour configurer les
composants middleware.
Software Assembly Toolkit
des fichiers images Software Assembly Toolkit.
WebSphere sMash
des fichiers images WebSphere sMash.
Espace de travail d'IBM Retail Store Server
v Répertoire d'installation : chemin d'accès complet au répertoire d'installation de
l'espace de travail d'IBM Retail Store Server.
Installation en mode silencieux
Cette rubrique explique comment effectuer une installation du produit en mode
silencieux.
Vous devez personnaliser le fichier de réponses exemple pour votre environnement
avant de procéder à l'installation en mode silencieux. Le fichier exemple contient
également des instructions de personnalisation du fichier. Après avoir personnalisé
le fichier, vous pouvez lancer la commande d'installation en mode silencieux.
L'installation en mode silencieux est particulièrement utile si vous installez
fréquemment le produit ou si vous effectuez l'installation à partir d'une invite de
commande distante.
29
Pour exécuter le programme d'installation en mode silencieux, procédez comme
suit.
Procédure
1. Choisissez le fichier de réponses exemple pour l'installation souhaitée. Le
fichier de réponses exemple se nomme task.xml et se trouve dans le répertoire
tâches du DVD WebSphere Remote Server correspondant à votre système
d'exploitation.
Remarque : Ne modifiez pas la valeur de la propriété <taskNumber> dans le
fichier task.xml, sinon l'installation échouera.
2. Editez le fichier C:\nomDVD\IRU_install.properties. Il s'agit du fichier de
réponses pour l'assistant de déploiement. Indiquez les paramètres suivants
dans ce fichier pour effectuer l'installation en mode silencieux, accepter le
contrat de licence et spécifier le fichier de tâches choisi à l'étape 1 :
–silent=true
-taskFile=<chemin du fichier xml de tâches>
3. Démarrez l'installation à l'aide de l'option d'installation en mode silencieux :
WindowsSetup.exe
LinuxSetup
4. Vérifiez si l'installation à réussi en recherchant les journaux. Si l'emplacement
ci-dessous contient des fichiers journaux, cela signifie que l'installation en mode
silencieux est terminée :
(32 bits) C:\Program Files\SolutionFiles\logs
(64 bits) C:\Program Files (x86)\SolutionFiles\logs
/opt/SolutionFiles/logs
Si les fichiers journaux contiennent des erreurs, voir «Astuces pour
l'identification et la résolution des incidents», à la page 131 pour tenter de les
résoudre.
Vérification de l'installation
La présente section décrit comment vérifier que chaque progiciel a bien été installé
et qu'il fonctionne correctement.
Les étapes permettant de vérifier l'installation de chaque progiciel ou application
sont décrites dans les sections suivantes. La vérification de l'installation est
facultative.
Remarque : Il est recommandé d'installer le groupe de correctifs d'un produit
middleware avant de vérifier l'installation du produit.
Fichiers journaux d'installation
Les fichiers journaux sont créés lors de l'installation de chaque produit
middleware. Ces journaux vous permettront de vérifier que l'installation s'est
déroulée correctement.
Les fichiers journaux d'installation se trouvent dans les répertoires suivantes :
(32 bits)
v SIF_HOME\logs
v %TEMP%\logs
30
v C:\Program Files\SolutionFiles\logs
(64 bits)
v SIF_HOME\logs
v %TEMP%\logs
v C:\Program Files (x86)\SolutionFiles\logs
v SIF_HOME/logs
v /tmp/logs
v /opt/SolutionFiles/logs
Vérification de WebSphere Application Server
L'installation de WebSphere Application Server a déjà été vérifiée lors du processus
d'installation, à l'aide des scripts ivt.bat et ivt.sh.
Vérification de WebSphere MQ
La présente section décrit les étapes permettant de vérifier l'installation d'IBM
WebSphere MQ.
Ce progiciel créé des utilisateurs et des groupes associés à l'application WebSphere
MQ. Les instructions suivantes vous permettent de créer, de démarrer, de terminer
et de supprimer un gestionnaire de files d'attente nommé QM1.
Procédure
v Sous Linux :
1. Connectez-vous au processeur intégré au magasin en tant que
superutilisateur.
2. Entrez la commande suivante pour basculer sur l'utilisateur mqm (utilisateur
créé par le script d'installation) :
su - mqm
3. Entrez la commande suivante pour créer le gestionnaire de files d'attente
nommé QM1 :
crtmqm QM1
4. Entrez la commande suivante pour démarrer le gestionnaire de files
d'attente :
strmqm QM1
5. Entrez les commandes suivantes pour arrêter le gestionnaire de files
d'attente :
endmqm -i QM1
6. Entrez la commande suivante pour supprimer le gestionnaire de files
d'attente :
dltmqm QM1
7. Déconnectez-vous du système intégré au magasin et fermez toutes les
fenêtres.
v Sous Windows :
1. Ouvrez l'invite de commande.
31
2. Entrez la commande suivante pour créer le gestionnaire de files d'attente
nommé QM1 :
crtmqm QM1
3. Entrez la commande suivante pour démarrer le gestionnaire de files
d'attente :
strmqm QM1
4. Entrez les commandes suivantes pour arrêter le gestionnaire de files
d'attente :
endmqm -i QM1
5. Entrez la commande suivante pour supprimer le gestionnaire de files
d'attente :
dltmqm QM1
6. Fermez l'invite de commande.
Vérification d'IBM HTTP Server
L'installation d'IBM HTTP Server a déjà été vérifiée par le programme d'installation
qui arrête et démarre les serveurs HTTP.
Vérification de DB2 Workgroup Server Edition
La présente rubrique décrit les étapes permettant de vérifier l'installation de DB2.
Pour créer et supprimer une base de données, procédez comme suit.
Procédure
1. Accédez à DB2.
Linux
a. Connectez-vous au processeur intégré au magasin en tant que
superutilisateur.
b. Saisissez la commande suivante pour basculer sur l'utilisateur db2inst1
(l'un des utilisateurs créés par le script d'installation) :
su - db2inst1
Windows
a. Ouvrez la fenêtre de commandes DB2 (par exemple, exécutez db2cw).
2. Utilisez ce script pour créer une base de données d'exemple : db2 create
database test.
3. Utilisez ce script pour supprimer une base de données d'exemple : db2 drop
database test.
Vérification d'Informix Growth Edition
Aidez-vous de cette rubrique pour vérifier votre installation Informix Growth
Edition sur les systèmes d'exploitation Windows ou Linux.
Vérification sur des systèmes d'exploitation Windows
La procédure d'installation crée un fichier de traitement par lots dbservername.cmd
qui définit les valeurs des variables d'environnement. Ce fichier est situé dans le
répertoire où Informix Growth Edition est installé. Exécutez ce fichier avant tout
32
utilitaire de ligne de commande Informix Growth Edition. Le nom par défaut et
l'emplacement du fichier est C:\Program Files\IBM\SIF\IBM Informix Dynamic
Server\11.50\ol_svr_custom.cmd.
Pour créer et supprimer une base de données ou un tableau et pour ajouter des
données au tableau, procédez comme suit.
Procédure
1. A partir d'une invite de commande, exécutez les commandes suivantes pour
créer une base de données exemple :
cd informixInstallDir
dbservername.cmd
cd bin
dbaccess - create database sample1;
2. Exécutez les commandes suivantes pour créer et supprimer une table.
Pour créer une table, entrez :
create table test (
a_number integer,
a_string char(50),
another_string char(50));
Pour insérer et extraire des lignes, entrez :
insert into test values (123, "Bonjour", "Je m’appelle David");
select * from test;
a_number 123
a_string Bonjour
another_string Je m’appelle David
a_number 456
a_string Bonjour
Pour supprimer la table et effectuer la déconnexion, entrez :
drop table test;
disconnect all;
3. Exécutez la commande suivante pour supprimer la base de données :
drop database ’sample1’;
Vérification sur des systèmes d'exploitation Linux
Procédure
1. Connectez-vous au processeur intégré au magasin en tant que superutilisateur.
2. Indiquez le fichier suivant :
. /etc/profile.d/setInformixEnv.sh
$INFORMIXDIR/bin/dbaccess - >create database sample1;
3. Exécutez les commandes suivantes pour créer et supprimer une table.
Pour créer une table, entrez :
create table test (
a_number integer,
a_string char(50),
another_string char(50));
Pour insérer et extraire des lignes, entrez :
33
select * from test;
a_number 123
a_string Bonjour
a_number 456
a_string Bonjour
Pour supprimer la table et effectuer la déconnexion, entrez :
drop table test;
disconnect all;
4. Exécutez la commande suivante pour supprimer la base de données :
drop database ’sample1’;
Vérification de WebSphere sMash
Suivez les instructions ci-dessous pour vérifier que WebSphere sMash a été installé.
Pour vérifier que WebSphere sMash a été installé, consultez le fichier install.log
dans le répertoire d'installation de WebSphere sMash.
Pour vérifier qu'IBM Reliable Transport Extension for WebSphere sMash a été
installé, consultez le fichier rte_install.log dans ce même répertoire.
Installation et déploiement des agents IBM Tivoli Monitoring
La présente section fournit des informations sur l'installation et le déploiement des
agents IBM Tivoli Monitoring.
Les agents Tivoli Enterprise Monitoring permettent de surveiller des ressources.
Les agents et les systèmes ou les ordinateurs sur lesquels ils s'exécutent sont
appelés systèmes gérés. Installez les agents sur le système d'exploitation, le
sous-système ou l'ordinateur que vous souhaitez surveiller.
Remarque :
v Nous vous conseillons d'utiliser la méthode d'installation à distance
pour installer les agents.
v Seuls les agents IBM Tivoli Monitoring suivants prennent en charge
Windows 7 (32 et 64 bits) :
– IBM Tivoli Composite Application Manager Agent for HTTP
Servers 7.1
– IBM Tivoli Composite Application Manager Agent for IBM
WebSphere Application Server
v Si les produits suivants nécessitent une surveillance, vous devez les
installer sur les processeurs intégrés au magasin Windows 7 :
– DB2 9.7 Fix Pack 2
– IBM WebSphere Message Broker Retail Store Edition 7.0
– IBM WebSphere MQ 7.0.1.2
v Si vous installez l'agent de surveillance du système d'exploitation
sous SUSE Linux Enterprise Server 10.3 (64 bits), vous devez
disposer des bibliothèques suivantes :
34
libstdc++-devel
libstdc++33-32 bits
Pour obtenir des informations sur l'installation, le déploiement, ou autre, des
agents Tivoli Monitoring, consultez le Centre de documentation Tivoli Monitoring.
Installation des fichiers de prise en charge de l'agent
Lors du déploiement d'un agent ITM, vous devez installer les fichiers de prise en
charge de l'agent sur TEMS et TEPS. Les fichiers de prise en charge sont
disponibles dans l'image d'installation de l'agent.
Suivez les étapes ci-dessous pour installer la prise en charge sur un serveur de
surveillance.
Procédure
1. Arrêtez le serveur de surveillance en exécutant la commande suivante :
/opt/IBM/ITM/bin/itmcmd server stop nom_tems
2. Exécutez la commande suivante à partir du support d'installation :
./install.sh
3. Lorsque le système vous demande le répertoire de base d'IBM Tivoli
Monitoring, appuyez sur Entrée pour accepter la valeur par défaut
(/opt/IBM/ITM) ou entrez le chemin complet du répertoire d'installation utilisé.
4. Une fenêtre s'affiche et vous demande de choisir l'une des options suivantes :
Installer des produits sur l'hôte local, Installer des produits dans le dépôt
pour un déploiement à distance (nécessite TEMS) et Quitter l'installation.
Choisissez la première option pour démarrer le processus d'installation.
5. Entrez le numéro correspondant à la langue dans laquelle vous souhaitez
afficher le contrat de licence logiciel et appuyez sur Entrée.
6. Appuyez sur Entrée pour afficher le contrat.
7. Tapez 1 pour accepter le contrat et appuyez sur Entrée.
8. Tapez la clé de chiffrement de 32 caractères et appuyez sur Entrée. Cette clé
doit être identique à la clé utilisée lors de l'installation du serveur de
surveillance. Une liste numérotée de systèmes d'exploitation et de composants
d'installation disponibles s'affiche.
Remarque : Si vous avez déjà installé un autre composant IBM Tivoli
Monitoring sur cet ordinateur ou que vous installez la prise en
charge pour un agent à partir de l'image d'installation d'un agent,
cette étape n'apparaîtra pas.
9. Entrez le numéro correspondant à la prise en charge du serveur Tivoli Enterprise
Monitoring Server et appuyez sur Entrée.
10. Tapez y pour confirmer et appuyez sur Entrée. Une liste de composants à
installer s'affiche.
11. Entrez le numéro correspondant à tous les éléments ci-dessus et appuyez sur
Entrée.
12. Tapez y pour confirmer l'installation. Le processus d'installation débute.
13. Une fois que tous les composants sont installés, le système vous demande si
vous souhaitez installer des composants pour un système d'exploitation
différent. Tapez n et appuyez sur Entrée.
14. Démarrez le serveur de surveillance en exécutant la commande suivante :
35
/opt/IBM/ITM/bin/itmcmd server start nom_tems
15. Exécutez la commande suivante pour activer la prise en charge des
applications sur le serveur de surveillance, où nom_tems représente le nom du
serveur de surveillance et pc le code produit de l'agent.
/opt/IBM/ITM/bin/itmcmd support -t pc nom_tems
16. Pour afficher le code produit de la prise en charge des applications que vous
venez d'installer, exécutez la commande suivante :
/opt/IBM/ITM/bin/cinfo
17. Tapez 1 lorsque le système vous demande d'afficher les codes produit des
composants installés sur cet ordinateur. Ajoutez uniquement la prise en charge
pour l'agent que vous avez installé. Par exemple, si vous avez installé la prise
en charge pour l'agent DB2, exécutez la commande suivante où ud est le code
produit de l'agent DB2.
/opt/IBM/ITM/bin/itmcmd support -t ud nom_hub_tems
18. Arrêtez le serveur de surveillance en exécutant la commande suivante :
/opt/IBM/ITM/bin/itmcmd server stop nom_tems
19. Exécutez la commande suivante pour redémarrer le serveur de surveillance :
/opt/IBM/ITM/bin/itmcmd server start nom_tems
Déploiement d'agents de surveillance Tivoli Monitoring
La présente section explique comment déployer les agents de surveillance Tivoli
Monitoring à distance sur le processeur ISP à partir de l'entreprise. La fonction de
déploiement à distance est fournie dans Tivoli Monitoring 6.2.2 avec le groupe de
correctifs 1 et est indépendante d'IBM Tivoli Management Framework.
Les déploiements à distance et locaux sont décrits dans les sections suivantes.
Cependant, la méthode recommandée est le déploiement à distance. Le
déploiement local implique le chargement individuel du logiciel d'agent de
surveillance sur chaque processeur ISP, ce qui peut prendre beaucoup de temps
lorsque les agents doivent être installés sur plusieurs machines. Le déploiement à
distance est effectué au niveau de l'entreprise, les images étant créées sur le
serveur de surveillance (TEMS), puis réparties dans l'entreprise vers les
processeurs ISP.
Les agents de surveillance sont des collecteurs de données. Les agents surveillent
les systèmes, les sous-systèmes ou les applications, collectent des données et
transmettent les données à Tivoli Enterprise Portal par le biais du serveur de
surveillance. Il existe deux types d'agents de surveillance :
v Les agents de système d'exploitation, qui surveillent la disponibilité et les
performances des ordinateurs de votre environnement de surveillance.
v Les agents d'application (ou agents indépendants du système d'exploitation), qui
surveillent la disponibilité et les performances d'applications spécifiques.
Tivoli Monitoring fournit également un agent personnalisable appelé Universal
Agent, qui peut être utilisé pour surveiller des données spécifiques à votre
environnement d'entreprise.
Les agents suivants sont déployés sur le processeur ISP :
v Agent de système d'exploitation
v IBM Tivoli Universal Agent
v IBM Tivoli Composite Application Manager Agent for DB2 6.2.2
v IBM Tivoli Composite Application Manager Agent for Oracle Database 6.2.1
36
v IBM Tivoli
v IBM Tivoli
7.1
v IBM Tivoli
v IBM Tivoli
v IBM Tivoli
v IBM Tivoli
MQ 7.0.1
Composite Application Manager Agent for J2EE 6.1
Composite Application Manager Agent for WebSphere Applications
Composite Application
Manager Agent for HTTP Servers 7.1
Manager Agent for WebSphere MQ 7.0.1
Manager Agent for WebSphere Broker 7.0.1
Manager Configuration Agent for WebSphere
Préparation du déploiement à distance
Le déploiement à distance permet de déployer la surveillance des ressources dans
votre environnement à partir d'un emplacement central.
Dans l'emplacement central qu'est l'entreprise, un référentiel est créé pour stocker
les images d'agent qui seront réparties sur le réseau. Ce référentiel est appelé dépôt
d'agent. Le dépôt d'agent est ensuite rempli avec les images d'installation
souhaitées avant d'être vérifié. Une fois que le dépôt a été vérifié et qu'il contient
toutes les images souhaitées, celles-ci sont déployées, ce qui signifie que les agents
sont répartis sur les processeurs ISP via le réseau.
Le déploiement à distance peut également être utilisé pour configurer et appliquer
la maintenance sur les agents déployés.
Prérequis :
Le déploiement à distance nécessite l'installation d'IBM Tivoli Monitoring 6.2.2
avec le groupe de correctifs 1 au niveau de l'entreprise. Cette installation de
l'environnement de surveillance ITM comprend l'installation de Tivoli Enterprise
Monitoring Server (TEMS), de Tivoli Enterprise Portal Server (TEPS) et de Tivoli
Enterprise Portal (TEP). Avant d'installer ITM, vérifiez que DB2 UDB est installé.
Les prérequis pour la configuration de l'entreprise sont les suivants :
v DB2 UDB 9.5 ou ultérieur
v IBM Tivoli Monitoring 6.2.2 groupe de correctifs 1 (TEMS, TEPS, client TEP)
Remplissage du dépôt d'agent :
Le dépôt d'agent est un répertoire d'installation du serveur de surveillance (TEMS)
à partir duquel vous déployez des agents et des modules de maintenance dans
votre environnement. Avant de déployer des agents à partir d'un serveur de
surveillance, vous devez d'abord remplir le dépôt d'agent avec des ensembles. Un
ensemble comprend l'image d'installation de l'agent et les prérequis éventuels.
Lors de l'ajout d'un ensemble au dépôt d'agent, il convient d'ajouter l'ensemble
approprié qui prend en charge le système d'exploitation sur lequel vous souhaitez
déployer cet ensemble. Les différents composants IBM Tivoli Monitoring étant
livrés avec différents CD adaptés à chaque type de plateforme, vous devez ajouter
l'ensemble à partir du CD de la plateforme correspondant au composant. Vous
pouvez disposer d'un dépôt d'agent sur chaque serveur de surveillance (TEMS) de
votre environnement ou partager un dépôt d'agent sur vos serveurs de surveillance
en utilisant un serveur de fichiers partagés.
Tous les agents qui seront déployés dans le réseau nécessitent que leurs fichiers de
support d'application contenant les informations spécifiques à l'agent soient
également installés sur les serveurs d'entreprise (TEMS, TEPS, client TEP).
37
Il existe deux moyens de remplir le dépôt d'agent :
v Remplir le dépôt d'agent depuis l'image d'installation
v Remplir le dépôt d'agent via la commande tacmd addBundles.
Les deux sections suivantes décrivent chacune des méthodes en détail.
Remplissage du dépôt d'agent à partir d'une image d'installation :
Vous ne pouvez utiliser l'image d'installation pour remplir le dépôt d'agent que
lorsque vous remplissez le dépôt avec des ensembles correspondants au même
système d'exploitation que le serveur de surveillance (TEMS). Par exemple, vous
pouvez utiliser une image d'installation Windows de Tivoli Monitoring pour
ajouter un ensemble d'agent Windows à un serveur de surveillance Windows
(TEMS), mais vous ne pouvez pas utiliser une image d'installation Linux de Tivoli
Monitoring pour ajouter un ensemble Linux à un serveur de surveillance
Windows. Pour ajouter des ensembles ne correspondant pas aux systèmes
d'exploitation utilisés par le serveur de surveillance, utilisez la commande tacmd
addBundles.
Suivez les étapes ci-dessous pour remplir le dépôt d'agent à partir de l'image
d'installation d'IBM Tivoli Monitoring sous Windows :
v Lancez l'assistant d'installation en cliquant deux fois sur le fichier setup.exe situé
dans le sous-répertoire \Windows de l'image d'installation.
v Sélectionnez Modifier dans la fenêtre d'accueil et cliquez sur Suivant.
v Un message d'avertissement concernant les composants existants de l'ordinateur
s'affiche. Cliquez sur OK.
v Cliquez sur OK dans la fenêtre Ajouter ou supprimer des fonctions sans
apporter de modifications. Ne supprimez pas les éléments sélectionnés au risque
de les effacer de l'ordinateur.
v Dans la fenêtre Déploiement d'agent, sélectionnez les agents à ajouter au dépôt,
puis cliquez sur Suivant.
v Examinez le récapitulatif de l'installation, puis cliquez sur Suivant pour
commencer l'installation.
v Une fois les agents ajoutés au dépôt d'agent, la fenêtre Type d'installation
s'affiche.
v Etant donné que les composants sont déjà configurés, déselectionnez tous les
composants sélectionnés. Cliquez sur Suivant.
v Cliquez sur Terminer pour terminer l'installation.
d'installation d'un agent d'application sous Windows :
v Lancez l'assistant d'installation en cliquant deux fois sur le fichier setup.exe situé
dans le sous-répertoire \Windows de l'image d'installation.
v Sélectionnez Suivant dans la fenêtre d'accueil.
v Cliquez sur Suivant dans la fenêtre Sélectionner des fonctions sans apporter de
modifications.
v Dans la fenêtre Déploiement d'agent, sélectionnez les agents à ajouter au dépôt,
puis cliquez sur Suivant.
v Examinez le récapitulatif de l'installation, puis cliquez sur Suivant pour
commencer l'installation.
v Une fois les agents ajoutés au dépôt d'agent, la fenêtre Type d'installation
s'affiche.
38
v Etant donné que les composants sont déjà configurés, déselectionnez tous les
composants sélectionnés. Cliquez sur Suivant.
v Cliquez sur Terminer pour terminer l'installation.
d'installation Linux ou UNIX :
v Exécutez la commande ./install.sh dans le répertoire où vous avez extrait les
fichiers d'installation.
v Lorsque vous êtes invité à indiquer le répertoire d'installation d'IBM Tivoli
(/opt/IBM/ITM). Si vous souhaitez utiliser un autre répertoire d'installation,
entrez le chemin d'accès complet à ce répertoire et appuyez sur Entrée.
v Si le répertoire spécifié n'existe pas, vous êtes invité à le créer. Tapez y pour
créer le répertoire.
v A l'invite suivante, choisissez Installer des produits dans le dépôt pour un
déploiement à distance (nécessite TEMS) et appuyez sur Entrée.
v Un écran affiche le contrat de licence. Pour effectuer l'installation, acceptez le
contrat de licence et appuyez sur Entrée.
v Entrez le numéro correspondant aux agents que vous souhaitez ajouter au dépôt
d'agent et appuyez sur Entrée. Pour ajouter plusieurs agents, séparez leur
numéro par une virgule. Pour sélectionner tous les agents disponibles, entrez
tous.
v Vous pouvez sélectionner plusieurs agents avec les numéros correspondants
consécutifs en entrant le premier et le dernier numéro des agents, séparés par un
tiret (-). Par exemple, pour ajouter tous les agents compris entre 8 et 12, entrez
8-12.
v Pour effacer un agent précédemment sélectionné, saisissez de nouveau son
numéro.
v Lorsque tous les agents à ajouter au dépôt d'agent sont sélectionnés, tapez E et
appuyez sur Entrée pour sortir.
Tableau 2. Touches permettant de se déplacer dans la liste d'agents
Touche
Navigation
U
Monte d'une ligne dans la liste.
D
Descend d'une ligne dans la liste.
F
Passe à la page suivante de la liste.
B
Revient à la page précédente de la liste.
Remplissage du dépôt d'agent à partir de l'invite de commande :
Pour remplir le dépôt d'agent à partir de l'invite de commande, utilisez la
commande tacmd addBundles. Avant d'émettre la commandetacmd addBundles, vous
devez vous assurer que l'environnement est défini et ouvrir une session à l'aide
des commandes suivantes :
export CANDLEHOME=/opt/IBM/ITM
tacmd login -s <nom serveur> -u <nom utilisateur> -p <motdepasse> -t <délai_attente>
Où délai_attente représente une valeur exprimée en minutes comprise entre 0 et
1440.
Emettez ensuite la commande tacmd addBundles, dont la syntaxe est la suivante :
39
[-i CHEMIN_IMAGE] [-t CODE_PRODUIT] [-p SYSTEME_EXPLOITATION] [-v VERSION] [-n] [-f]
Pour obtenir des informations sur la syntaxe complète, y compris les descriptions
de paramètres, voir IBM Tivoli Monitoring Command Reference.
Tableau 3. Remplissage du dépôt d'agent
Commande
Description
tacmd addbundles -i
/mnt/cdrom/unix
Copie tous les ensembles d'agent et leurs prérequis
dans le dépôt d'agent d'un ordinateur UNIX à partir
du support d'installation (image du CD) situé dans
/mnt/cdrom/.
tacmd addbundles -i
/mnt/cdrom/unix -t ud
Copie tous les ensembles d'agent pour l'agent DB2
dans le dépôt d'agent d'un ordinateur UNIX à partir
du support d'installation (image du CD) situé dans
/mnt/cdrom/.
tacmd addbundles -i
D:\WINDOWS\Deploy -t ud
Copie tous les ensembles d'agent pour l'agent DB2
dans le dépôt d'agent d'un ordinateur Windows à
partir du support d'installation (image du CD) situé
dans D:\WINDOWS\Deploy.
Par défaut, la commande tacmd addBundles place l'ensemble d'agent à l'endroit
défini dans le fichier de configuration du serveur de surveillance pour
DEPOTHOME. Pour modifier l'emplacement, procédez comme suit avant
d'exécuter la commande tacmd addBundles :
1. Ouvrez le fichier de configuration du serveur de surveillance KBBENV situé
dans le répertoire <rép_install_itm>\CMS sous Windows ou dans le répertoire
<rép_install_itm>/tables/<nom_tems> sous Linux et UNIX.
2. Recherchez la variable DEPOTHOME. Si elle n'existe pas, ajoutez-la au fichier.
Par défaut, le dépôt d'agent se trouve dans le répertoire <rép_install_itm>/
CMS/depot sous Windows ou dans le répertoire <rép_install_itm>/tables/
<nom_tems>/depot sous UNIX.
3. Entrez le chemin d'accès au répertoire à utiliser pour le dépôt d'agent, puis
enregistrez et fermez le fichier.
4. Sous UNIX ou Linux uniquement, ajoutez la même variable et le même
emplacement au fichier kbbenv.ini situé dans <rép_install_itm>/config/
kbbenv.ini.
5. Si vous n'ajoutez pas la variable au fichier kbbenv.ini, elle sera supprimée du
fichier KBBENV lors de la prochaine reconfiguration du serveur de
surveillance.
Vérification du remplissage de l'agent :
La commande tacmd viewDepot vous permet de vérifier si les agents sont ajoutés
au dépôt d'agent. Cette commande répertorie tous les agents du dépôt d'agent.
Avant d'exécuter cette commande, vous devez vous connecter et vérifier l'état du
serveur Tivoli Enterprise Monitoring Server (TEMS).
v Ouvrez la console de gestion avec les statuts de TEMS et de TEPS. Pour ce faire,
exécutez la commande : itmcmd manage
v Assurez-vous que TEMS est en cours d'exécution puis exécutez la commande de
connexion : export CANDLEHOME=/opt/IBM/ITM tacmd login –s <Adresse
IP/nom d'hôte TEMS> -u <nom_utilisateur> -p <motdepasse> -t
<minutes_dépassement_délai>
v Exécutez la commande viewDepot : tacmd viewDepot
40
Vous pouvez utiliser les commandes tacmd listBundles et tacmd removeBundles
pour répertorier tous les ensembles disponibles dans l'image d'installation et
supprimer les ensembles du dépôt d'agent. Pour une description plus détaillée de
ces commandes Tivoli, consultez le centre de documentation IBM Tivoli
Monitoring.
Déploiement d'agents
Cette section décrit les procédures à suivre pour déployer des agents. Déployer des
agents signifie extraire les images d'installation de l'emplacement central vers les
noeuds du réseau.
Déploiement d'agents de système d'exploitation :
Avant de pouvoir déployer un agent indépendant du système d'exploitation sur un
ordinateur, vous devez installer un agent de système d'exploitation sur l'ordinateur
concerné. En plus de surveiller les performances du système d'exploitation
principal, l'agent de système d'exploitation installe également l'infrastructure
requise pour le déploiement et la maintenance à distance. Vous pouvez installer
l'agent de système d'exploitation à distance à l'aide de la commande tacmd
createNode du répertoire suivant : /opt/IBM/ITM/bin.
La commande tacmd createNode créé un répertoire appelé node sur l'ordinateur cible.
Les agents de système d'exploitation sont installés dans ce répertoire et tous les
agents indépendants du système d'exploitation seront déployés également dans
celui-ci.
La commande tacmd createNode utilise l'un des protocoles suivants pour se
connecter aux ordinateurs sur lesquels vous souhaitez installer l'agent de système
d'exploitation :
v Server Message Block (SMB), utilisé principalement pour les serveurs Windows.
v Secure Shell (SSH), utilisé principalement par les serveurs UNIX, mais également
disponible sous Windows.
v Remote Execution (REXEC), utilisé principalement par les serveurs UNIX, mais
peu sécurisé.
v Remote Shell (RSH), utilisé principalement par les serveurs UNIX, mais peu
sécurisé.
Vous pouvez spécifier un protocole à utiliser ; si vous ne le faites pas, la
commande tacmd createNode choisit le protocole approprié de manière dynamique.
La syntaxe de la commande tacmd createNode est la suivante, où la valeur de la
propriété est utilisée pour spécifier le protocole. Pour une explication complète de
tous les attributs de cette commande, voir IBM Tivoli Monitoring et guide de
configuration.
tacmd createnode -h <adresse IP ISP> -u <nom_utilisateur> -w
<mot_passe> -p <nom=valeur>
Où
v -p nom=valeur (Certains agents nécessitent des propriétés personnalisées pour les
paires nom-valeur)
v nom = PROTOCOLE ou PORT
v valeur = IP.UDP, IP.PIPE, IP.SPIPE, SNA lorsque nom=PROTOCOLE
v valeur = 1918 (lorsque PORT=IP.UDP ou IP.PIPE est spécifié)
v valeur = 3660 (lorsque PORT=IP.SPIPE)
41
v valeur = n/a (lorsque PORT=SNA est spécifié)
Vérification du déploiement de l'agent de système d'exploitation :
Le déploiement à distance de l'agent de système d'exploitation comprend le
déploiement, la configuration et le démarrage de l'agent. Une fois l'agent déployé,
vous le voyez en cours d'exécution dans le processeur ISP. Pour vérifier le
déploiement d'un agent de système d'exploitation, vous pouvez afficher celui-ci
dans Tivoli Enterprise Portal (TEP) ou consulter le fichier journal. L'URL de TEP
est la suivante : http://<AdresseIP_TEMS>:1920/.
Sur un ordinateur Windows, le fichier journal se trouve par défaut dans le
répertoire : <CANDLEHOME>\tmaitm6\logs, où CANDLEHOME désigne
C:\IBM\ITM. Sur un ordinateur Linux, il se trouve par défaut dans le répertoire :
<CANDLEHOME>/logs/, où CANDLEHOME désigne /opt/IBM/ITM.
Dans le fichier journal, vous pouvez vérifier si l'agent de système d'exploitation
communique avec TEMS. TEMS est appelé CMS dans le fichier journal. Pour le
vérifier dans TEP, vous pouvez vous connecter au portail et vérifier si l'agent de
système d'exploitation s'affiche, puis consulter les informations système de
l'ordinateur Windows.
Deploiement d'agents indépendants du système d'exploitation :
Vous pouvez déployer des agents indépendants du système d'exploitation via
Tivoli Enterprise Portal (TEP) ou à partir de la ligne de commande TEMS. Le
déploiement et la configuration des agents varie en fonction de l'agent en question.
La procédure suivante fournit des informations de déploiement génériques. Pour
connaître les valeurs exactes requises pour votre agent, consultez les informations
de configuration dans le guide d'utilisation de l'agent. Avant de tenter un
déploiement d'agent, assurez-vous d'avoir rempli votre dépôt d'agent. Vous devez
également avoir installé ou déployé un agent de système d'exploitation sur
l'ordinateur (processeur ISP) sur lequel vous déployez l'agent indépendant du
système d'exploitation. Les agents indépendants du système d'exploitation sont les
suivants : Tivoli Universal Agent, DB2 Agent, Oracle Database Agent, IBM
WebSphere Application Server Agent, IBM WebSphere MQ Agent, J2EE Agent,
HTTP Server Agent, WebSphere Broker Agent et Configuration Agent for
WebSphere MQ.
Déploiement via Tivoli Enterprise Portal :
Les étapes suivantes vous permettent de déployer un agent via l'interface
graphique du portail :
v Dans un environnement avec des fichiers TEMS distants, vous devez propager
des fichiers de support à partir du serveur TEMS distant au serveur TEMS
concentrateur. Sous Linux, vous pouvez utiliser la commande scp pour effectuer
la copie. Emettez les commandes suivantes à partir du système TEMS
concentrateur, en remplaçant les noms par ceux de votre environnement.
scp profil-utilisateur@nomhôte-du-TEMS-distant:/opt/IBM/ITM/tables/serveur-TEMS-distant/ATTRLIB/*ATR*
/opt/IBM/ITM/tables/serveur-TEMS-concentrateur/ATTRLIB
scp profil-utilisateur@nomhôte-du-TEMS-distant:/opt/IBM/ITM/tables/serveur-TEMS-distant/RKDSCATL/*CAT*
/opt/IBM/ITM/tables/serveur-TEMS-concentrateur/RKDSCATL
v Après la copie des fichiers, redémarrez chaque serveur TEMS, le système
concentrateur et le système distant.
v Ouvrez Tivoli Enterprise Portal.
42
v Dans l'arborescence de navigation, accédez à l'ordinateur sur lequel vous
souhaitez déployer l'agent.
v Cliquez avec le bouton droit de la souris sur l'ordinateur, puis cliquez sur
Ajouter un système géré.
v Sélectionnez l'agent que vous souhaitez déployer, puis cliquez sur OK.
v Complétez les zones de configuration requises pour l'agent. Pour plus
d'informations sur ces zones, voir la documentation de configuration
correspondant à l'agent que vous déployez. Cliquez sur Terminer.
v Si l'ordinateur sur lequel vous déployez l'agent possède déjà une version de cet
agent installée, vous pouvez arrêter le déploiement, ajouter une nouvelle
instance de l'agent, le cas échéant, ou reconfigurer l'agent existant.
v Cliquez sur Terminer pour terminer le déploiement.
Déploiement via la ligne de commande TEMS :
Vous pouvez exécuter les commandes suivantes pour déployer un agent à partir de
la ligne de commande :
v tacmd listSystems : Recherche le système d'exploitation géré, actuellement
connecté à TEMS.
v cinfo : Répertorie les codes produit des agents installés sur l'ordinateur actuel.
v tacmd addSystem
Par exemple, la commande suivante déploie l'agent Universal Agent (code produit
um) sur l'ordinateur stone.ibm.com et indique la propriété UA.CONFIG :
tacmd addSystem -t um -n stone.ibm.com:LZ -p UA.CONFIG="fichier_unix.mdl"
Où um désigne le code produit de l'agent Universal Agent et UA.CONFIG la
propriété de configuration et le fichier mdl utilisé pour la configuration lors du
déploiement.
Lorsque vous déployez l'agent Universal Agent, vous devez spécifier un fichier
.mdl et tous les scripts référencés par ce fichier .mdl. Avant de pouvoir déployer
l'agent Universal Agent, placez le fichier .mdl dans le dépôt d'agent, dans le
sous-répertoire /opt/IBM/ITM/tables/HUB_itmserver/depot/UACONFIG et les scripts
dans le sous-répertoire/opt/IBM/ITM/tables/HUB_itmserver/depot/UACONFIG/
UASCRIPT. Vous devez créer ces deux sous-répertoires. Utilisez le dépôt d'agent du
serveur de surveillance auquel se connecte l'agent Universal Agent.
Chaque ensemble d'agent possède ses propres paramètres de configuration
distincts que vous devez fournir dans cette commande. Si vous possédez un agent
installé de même type et que vous souhaitez déployer celui-ci, vous pouvez
afficher les paramètres de configuration en exécutant la commande suivante :
tacmd describeSystemType -t pc -p plateforme. Vous pouvez obtenir plus
d'informations sur les paramètres spécifiques aux agents à partir des liens qui
renvoient aux documents suivants :
v Agent de système d'exploitation et Universal Agent : http://
publib.boulder.ibm.com/infocenter/tivihelp/v15r1/topic/
com.ibm.itm.doc_6.2.2fp1/using.htm
v Centre de documentation IBM Tivoli OMEGAMON XE for Messaging :
http://publib.boulder.ibm.com/infocenter/tivihelp/v15r1/index.jsp?toc=/
com.ibm.omegamon.mes.doc/toc.xml
43
v Centre de documentation IBM Tivoli Monitoring for Databases :
http://publib.boulder.ibm.com/infocenter/tivihelp/v15r1/index.jsp?toc=/
com.ibm.itmfd.doc/toc.xml
v IBM Tivoli Composite Application Manager Centre de documentation:
http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/topic/
com.ibm.itcamwas.doc_6.1/welcome.htm
Dans un environnement avec des fichiers TEMS distants, vous devez propager des
fichiers de support à partir du serveur TEMS distant au serveur TEMS
concentrateur. Sous Linux, vous pouvez utiliser la commande scp pour effectuer la
copie. Emettez les commandes suivantes à partir du système TEMS concentrateur,
en remplaçant les noms de votre environnement.
scp profil-utilisateur@nomhôte-du-TEMS-distant:/opt/IBM/ITM/tables/serveur-TEMS-distant/ATTRLIB/*ATR*
/opt/IBM/ITM/tables/serveur-TEMS-concentrateur/ATTRLIB
scp profil-utilisateur@nomhôte-du-TEMS-distant:/opt/IBM/ITM/tables/serveur-TEMS-distant/RKDSCATL/*CAT*
/opt/IBM/ITM/tables/serveur-TEMS-concentrateur/RKDSCATL
Après la copie des fichiers, redémarrez chaque serveur TEMS, le système
concentrateur et le système distant.
Par exemple, lors du déploiement de l'agent DB2, vous devez indiquer la propriété
INSTANCE : tacmd addSystem -t ud -n stone.ibm.com:LZ -p INSTANCE=db2inst.
Où ud désigne le code produit de l'agent DB2, LZ le code produit de l'agent de
système d'exploitation Linux et db2inst1 l'instance disponible dans DB2.
L'agent DB2 doit s'exécuter comme un utilisateur DB2 ou un utilisateur ayant des
autorisations DB2. Si vous utilisez le déploiement à distance, celui-ci est géré
automatiquement. La commande est la suivante : su - db2inst1 -c
"/opt/IBM/ITM/bin/itmcmd agent -o db2inst1 start ud". Une fois l'agent installé
(en local ou à distance), éditez le fichier /opt/IBM/ITM/config/ud.ini du
processeur ISP et ajoutez "CTIRA_HOSTNAME=$RUNNINGHOSTNAME$", puis
redémarrez l'agent.
Lors de l'installation de l'agent de surveillance Tivoli OMEGAMON XE, la machine
nécessite un gestionnaire de files d'attente déjà installé pour être surveillée. Par
conséquent, vous devez créer et démarrer un gestionnaire de files d'attente sur le
processeur ISP en émettant les commandes suivantes :
su - mqm
crtmqm myqm1
strmqm myqm1
Une fois le gestionnaire de files d'attente créé, il peut être surveillé. Souvenez-vous
qu'un agent ne peut pas être déployé s'il ne possède pas au moins un gestionnaire
de files d'attente. Lors de l'installation de l'agent Tivoli OMEGAMON XE, le
compte à utiliser pour démarrer l'agent doit posséder la valeur mqm comme
groupe primaire. Processeur ISP : itmcmd agent -o qm1 start mq
Remarque : Si vous exécutez la commande tacmd dans l'interpréteur de
commandes pour la première fois, vous devez vous connecter au
serveur avant d'exécuter une commande tacmd : ./tacmd login -s
<adresse-ip-serveur-TEMS> -u <nom-utilisateur-serveur-TEMS> -p
<motdepasse-serveur-TEMS>
Déploiement local de l'agent de surveillance ITCAM for
WebSphere
Le déploiement local implique le chargement individuel du logiciel d'agent de
surveillance sur chaque machine du processeur ISP.
44
Installation et configuration d'un agent de surveillance sous Windows :
La présente section fournit les instructions d'installation et de configuration en
local d'un agent de surveillance sur un ordinateur Windows.
Procédez de la manière suivante pour installer et configurer un agent de
surveillance sur un ordinateur Windows.
1. Lancez l'assistant d'installation en cliquant deux fois sur le fichier setup.exe
situé dans le sous-répertoire \WINDOWS du support d'installation.
2. Cliquez sur Suivant dans la fenêtre d'accueil.
3. Cliquez sur Accepter pour accepter le contrat de licence.
4. Si aucune base de données n'est installée sur cet ordinateur, un message
concernant les logiciels potentiellement manquants s'affiche. Une base de
données n'est pas nécessaire pour installer un agent de gestion sur cet
ordinateur. Vous pouvez donc cliquer sur Suivant et ignorer ce message.
5. Choisissez le répertoire dans lequel vous souhaitez installer le produit.
Cliquez sur Suivant.
Remarque : Vous ne devez effectuer cette étape que pour les agents installés à
partir de l'image d'installation d'IBM Tivoli Monitoring. Les
agents installés à partir de leur image d'installation ne
comportent pas cette étape. Si vous installez un agent à partir de
son image d'installation, passez à l'étape 7.
6. Tapez une clé de chiffrement de 32 caractères. Cette clé doit être identique à la
clé utilisée lors de l'installation du serveur de surveillance auquel se connecte
cet agent de surveillance. Cliquez sur Suivant, puis sur OK pour confirmer la
clé de chiffrement.
7. Développez les agents Tivoli Enterprise Monitoring Agent.
8. Sélectionnez le nom de l'agent que vous voulez installer et cliquez sur
Suivant.
Remarque : Si vous installez l'agent sur un ordinateur qui possède déjà un
serveur de surveillance, l'étape suivante sert à remplir le dépôt. Si
aucun serveur de surveillance n'est installé sur cet ordinateur,
sautez cette étape.
9. Saisissez le nom d'un dossier de programme à utiliser dans votre menu
Démarrer et cliquez sur Suivant. Le dossier par défaut est IBM Tivoli
Monitoring.
Remarque : Vous ne devez effectuer cette étape que pour les agents installés à
partir de l'image d'installation d'IBM Tivoli Monitoring. Les
agents installés à partir de leur image d'installation ne
comportent pas cette étape.
10. Examinez le récapitulatif détaillé de l'installation. Celui-ci identifie les
éléments que vous installez et leur emplacement d'installation. Cliquez sur
Suivant pour commencer l'installation des composants. Une fois les
composants installés et l'environnement de configuration initialisé, une fenêtre
de configuration apparaît.
11. Cliquez sur Suivant pour commencer à configurer les valeurs par défaut de
votre agent.
12. Spécifiez les valeurs par défaut des agents IBM Tivoli Monitoring à utiliser
lorsqu'ils communiquent avec le serveur de surveillance.
45
v Si l'agent doit passer un pare-feu pour accéder au serveur de surveillance,
sélectionnez La connexion doit passer le pare-feu.
v Identifiez le type de protocole que l'agent utilise pour communiquer avec le
serveur de surveillance. Vous avez quatre options : IP.UDP, IP.PIPE,
IP.SPIPE ou SNA. Vous pouvez indiquer trois méthodes de communication cela vous permet de définir des méthodes de communication de
sauvegarde. Si la méthode que vous avez identifiée comme protocole 1
échoue, le protocole 2 est utilisé. Cliquez sur OK.
13. Remplissez les zones suivantes pour définir les communications entre les
agents et le serveur de surveillance.
Tableau 4. Paramètres du protocole de communication
Zone
Description
Paramètres IP.UDP
Nom d'hôte ou adresse IP
Nom d'hôte ou adresse IP du serveur de
surveillance concentrateur.
Numéro et/ou pool de port
Port d'écoute du serveur de surveillance
concentrateur.
Paramètres IP.PIPE
Numéro de port
Port d'écoute du serveur de surveillance. Le
numéro par défaut est 1918.
Paramètres IP.SPIPE
Numéro de port
Port d'écoute du serveur de surveillance
concentrateur. La valeur par défaut est 3660.
Paramètres SNA
Nom réseau
Identificateur de réseau SNA pour votre
emplacement.
Nom de LU
Nom de LU pour le serveur de surveillance.
Ce nom de LU correspond à l'alias de LU
local de votre logiciel de communications
SNA.
Mode de consignation LU 6.2
Nom du mode de consignation (LOGMODE)
LU6.2. La valeur par défaut est
"CANCTDCS."
Nom TP
Nom du programme de transaction du
serveur de surveillance.
Alias de LU local
Alias de LU.
14. Cliquez sur Terminer pour terminer l'installation.
15. Ouvrez l'utilitaire Manage Tivoli Enterprise Monitoring Services (s'il ne
s'ouvre pas automatiquement) pour vérifier si l'agent de surveillance a été
configuré et démarré. Si Oui apparaît dans la colonne Configuré, cela signifie
que l'agent a été configuré et démarré lors du processus d'installation.
16. Si la valeur de la colonne Configuré est nulle et que Modèle apparaît dans la
colonne Tâche/Sous-système, cliquez avec le bouton droit de la souris sur
l'agent Modèle et procédez comme suit :
v Cliquez sur Configurer en utilisant les valeurs par défaut.
46
v Remplissez les fenêtres en indiquant les informations requises à l'aide des
paramètres de configuration spécifiques à l'agent décrits dans le guide
utilisateur de votre agent.
Remarque : Ne saisissez pas de caractères non-ASCII dans ces fenêtres. La
saisie de caractères d'autres jeux de caractères entraîne des
résultats imprévisibles.
v Répétez cet étape si nécessaire pour créer des instances d'agent de
surveillance pour chaque instance d'application que vous voulez surveiller.
Installation et configuration d'un serveur de surveillance sous Linux :
La présente section fournit les instructions d'installation et de configuration en
local d'un agent de surveillance sur un ordinateur Linux. L'installation et la
configuration d'un agent de surveillance sous Linux comporte des étapes distinctes.
Installation de l'agent de surveillance sous Linux
Suivez les étapes ci-dessous pour installer un agent de surveillance sur un
ordinateur Linux :
1. Dans le répertoire où vous avez extrait les fichiers d'installation, exécutez la
commande suivante : ./install.sh.
2. Lorsque le système vous demande le répertoire de base d'IBM Tivoli
(/opt/IBM/ITM) ou entrez le chemin complet d'un répertoire différent.
3. Si le répertoire d'installation n'existe pas, vous êtes invité à en créer un. Tapez
y pour créer ce répertoire et appuyez sur la touche Entrée.
4. Une invite s'affiche, vous permettant de choisir l'une des options d'installation
suivantes : Installer des produits sur l'hôte local, Installer des produits dans
le dépôt pour un déploiement à distance (nécessite TEMS) et Quitter
l'installation. Choisissez la première option pour démarrer le processus
d'installation.
Remarque : Cette invite varie en fonction de l'image d'installation à partir de
laquelle vous effectuez l'installation.
5. Entrez le numéro correspondant à la langue dans laquelle vous souhaitez
afficher le contrat de licence logiciel et appuyez sur Entrée.
6. Appuyez sur Entrée pour afficher le contrat.
7. Tapez 1 pour accepter le contrat et appuyez sur Entrée.
8. Tapez une clé de chiffrement de 32 caractères et appuyez sur Entrée. Cette clé
doit être identique à la clé utilisée lors de l'installation du serveur de
surveillance auquel se connecte cet agent de surveillance. Une liste numérotée
de systèmes d'exploitation disponibles s'affiche.
9. Tapez le numéro du système d'exploitation sur lequel vous effectuez
l'installation. La valeur par défaut est votre système d'exploitation actuel.
Appuyez sur Entrée.
10. Tapez y pour confirmer le système d'exploitation et appuyez sur Entrée. Une
liste numérotée de composants disponibles s'affiche.
11. Tapez le numéro correspondant à l'agent ou les agents de surveillance que
vous souhaitez installer. Si vous souhaitez installer plusieurs agent, utilisez
une virgule ou un espace pour séparer les numéros de chaque agent. Appuyez
sur Entrée. Une liste de composants à installer s'affiche.
12. Tapez y pour confirmer l'installation. L'installation débute.
47
13. Une fois que tous les composants sont installés, le système vous demande si
vous souhaitez installer des composants pour un système d'exploitation
différent. Tapez n et appuyez sur Entrée. Le processus d'installation s'achève.
Remarque : L'installation locale de certains agents ITM sous Linux engendre un
problème connu. Elle échoue car elle détecte une version plus récente
d'un module appelé GSkit lorsque ITM tente d'installer une version
antérieure. Tivoli propose la solution palliative détaillée suivante, qui
implique la modification du script runGSkit : celui-ci se trouve dans
le répertoire /bin. Ce fichier est modifié lors de l'ajout de la nouvelle
prise en charge de plateforme, généralement à chaque niveau de
groupe de correctifs.
Faites une sauvegarde du script avant d'effectuer des modifications.
cd /bin
cp runGSkit runGSkit.orig
Editez runGSkit et procédez aux modifications suivantes :
v Recherchez une instance de texte "string version=7" et insérez les
deux lignes suivantes derrière la ligne recherchée :
versionPref=$(print $version | cut -d. -f1-3)
versionSuff=$(print $version | cut -d. -f4)
v Recherchez une instance de texte "string version=7". S'il s'agit d'une
occurrence différente, insérez les deux lignes suivantes derrière la
ligne recherchée
versionPref=$(print $version | cut -d. -f1-3)
versionSuff=$(print $version | cut -d. -f4)
v Modifiez toutes les occurrences de "grep $version" en "grep
$versionPref". Recherchez les deux lignes :
[ -n "$gskitVersion" ] && loop=no
[ -n "$gskitVersion_64" ] && loop_64=no
et commentez-les.
v Insérez le paragraphe suivant derrière les lignes que vous venez de
commenter :
if [[ -n "$gskitVersion" ]]
then
gskitVersionSuff=$(print $(print $gskitVersion | cut -d. -f4))
[[ "$os" = l* ]] && gskitVersionSuff=$(print $(print $gskitVersion |
cut -d. -f3))
if (( gskitVersionSuff >= versionSuff ))
then
loop=no
fi
fi
if [[ -n "$gskitVersion_64" ]]
then
gskitVersionSuff_64=$(print $(print $gskitVersion_64 | cut -d. -f4))
[[ "$os" = l* ]] && gskitVersionSuff_64=$(print $(print
$gskitVersion_64 | cut -d. -f3))
if (( gskitVersionSuff_64 >= versionSuff_64 ))
then
loop_64=no
fi
fi
Enregistrez le fichier et exécutez install.sh à nouveau.
48
v Une fois que runGSkit a été mis à jour et testé, vous souhaiterez
peut-être mettre à jour l'image de support pour ne pas avoir à
appliquer cette solution palliative pour chaque machine à installer.
v Si vous possédez le support de type CD ou DVD, copiez-le sur le
disque dur pour y avoir accès en lecture. Par exemple, si le support
se trouve sur le disque dans /MEDIAHOME et que l'installation
testée se trouve dans /ITMHOME, les commandes permettant de
mettre à jour l'image sont les suivantes :
cd /ITMHOME
chmod 755 /MEDIAHOME/unix/cienv.tar
tar -rvf /MEDIAHOME/unix/cienv.tar bin/runGSkit bin/runGSkit.orig
Configuration de l'agent de surveillance
Utilisez les étapes suivantes pour configurer votre agent de surveillance :
1. Exécutez la commande suivante :
./itmcmd config -A pc
Où pc est le code produit de votre agent ; pour Linux, utilisez lz.
2. Appuyez sur Entrée lorsque le système vous demande si l'agent se connecte à
un serveur de surveillance.
3. Tapez le nom d'hôte du serveur de surveillance.
4. Tapez le protocole que vous souhaitez utiliser pour communiquer avec le
serveur de surveillance. Vous avez quatre options : ip, sna, ip.spipe ou ip.pipe.
Appuyez sur Entrée pour accepter le protocole par défaut (IP.PIPE).
5. Si vous souhaitez configurer un protocole d'installation, entrez ce protocole et
appuyez sur Entrée. Si vous ne souhaitez pas utiliser de protocole de
sauvegarde, appuyez sur Entrée sans spécifier de protocole.
6. En fonction du type de protocole que vous avez spécifié, indiquez les
informations suivantes lorsque le système vous y invite :
Tableau 5. Protocoles et valeurs du serveur de surveillance UNIX
Protocole
Valeur
IP.UDP
Numéro de port du serveur de surveillance. La valeur par défaut est
1918.
Nom de réseau
SNA
Identificateur de réseau SNA pour votre emplacement.
Nom de LU
Nom de LU pour le serveur de surveillance. Ce nom de LU
correspond à l'alias de LU local de votre logiciel de communications
SNA.
Mode de
consignation
Nom du mode de consignation (LOGMODE) LU6.2. La valeur par
défaut est "CANCTDCS."
IP.PIPE
1918.
IP.SPIPE
3660.
7. Appuyez sur Entrée sans spécifier le nom de partition KDC_PARTITION.
8. Appuyez sur Entrée lorsque le système vous demande de configurer la
connexion à un serveur de surveillance secondaire. La valeur par défaut est no.
9. Appuyez sur Entrée pour accepter la valeur par défaut pour le nom réseau
principal facultatif (aucun).
49
Modification des droits d'accès aux fichiers
Cette section décrit le processus de modification des droits d'accès aux fichiers
pour les agents. Si l'utilisateur utilisé pour installer un agent de surveillance sur un
ordinateur UNIX n'était pas superutilisateur, les droits d'accès aux fichiers sont
initialement définis sur un niveau bas. Procédez comme suit pour modifier ces
droits d'accès aux fichiers :
1. Ouvrez une session sur l'ordinateur en tant que superutilisateur ou devenez
superutilisateur en exécutant la commande su.
2. Créez un nouveau groupe, utilisateurs_itm par exemple, qui possédera tous les
fichiers du répertoire d'installation IBMTivoli Monitoring. Exécutez la
commande suivante : groupadd itmusers.
3. Exécutez la commande suivante pour vous assurer que la variable
d'environnement CANDLEHOME identifie correctement le répertoire
d'installation d'IBM Tivoli Monitoring :
echo $CANDLEHOME
L'exécution des étapes suivantes dans le mauvais répertoire peut modifier les
droits d'accès à chaque fichier de chaque système de fichiers de l'ordinateur.
4. Accédez au répertoire renvoyé lors de l'étape précédente :
cd $CANDLEHOME
5. Exécutez la commande suivante pour vous assurer que vous vous trouvez
dans le répertoire adéquat :
pwd
6. Exécutez les commandes suivantes :
chgrp -R itmusers .
chmod -R o-rwx .
7. Exécutez la commande suivante pour modifier la propriété des fichiers d'agent
supplémentaires :
bin/SetPerm
8. Si vous souhaitez exécuter l'agent en tant qu'utilisateur particulier, ajoutez
l'utilisateur au groupe itmusers. Pour ce faire, éditez le fichier /etc/group et
assurez-vous que l'utilisateur se trouve dans la liste d'utilisateurs du groupe
itmusers. Par exemple, si vous souhaitez exécuter l'agent en tant qu'utilisateur
test1, vérifiez que la ligne suivante se trouve dans le fichier /etc/group :
itmusers:x:504:test1
9. Exécutez la commande su pour basculer sur l'utilisateur avec lequel vous
souhaitez exécuter l'agent ou ouvrez une session sous cet utilisateur.
10. Démarrez l'agent comme décrit dans la section Démarrage des agents de
surveillance.
Démarrage des agents de surveillance
Vous pouvez démarrer tous les agents en cours d'exécution sur un ordinateur ou
démarrer des agents individuels en utilisant les codes produit.
Pour démarrer tous les agents de surveillance, exécutez la commande suivante :
/opt/IBM/ITM/bin/itmcmd agent start all
Pour démarrer des agents spécifiques, exécutez la commande suivante :
/opt/IBM/ITM/bin/itmcmd agent start pc [nom_hôte...]
50
Où pc est le code produit de l'agent que vous souhaitez démarrer. Le code produit
de l'agent Universal Agent est um. Pour obtenir la liste complète des codes produit,
consultez le centre de documentation Tivoli ITM.
Désinstallation
Le script de désinstallation d'IBM WebSphere Remote Server supprime l'ensemble
de la solution WebSphere Remote Server, à savoir, IBM WebSphere Application
Server, DB2, ou Informix Growth Edition et IBM WebSphere MQ. Il supprime
également tout composant ajouté à la solution si vous avez procédé à l'extension
de WebSphere Remote Server.
Désinstallation de WebSphere Remote Server
1. Arrêtez la solution WebSphere Remote Server complète avant d'exécuter le
programme de désinstallation.
Le processus de désinstallation appelle le script wrsstop ; cependant, il se peut
que certains composants de la solution soient encore en cours de
fonctionnement, comme les gestionnaires de files d'attente WebSphere MQ.
2. Accédez au sous-répertoire bin de SIF_HOME.
3. Exécutez les commandes suivantes :
cd %SIF_HOME%\bin
SifRemoveWRS.bat -noprompt [clean]
La commande SifRemoveWRS.bat -noprompt -clean ne supprime pas le
répertoire SIF_HOME sous Windows.
cd $SIF_HOME/bin
./SifRemoveWRS.sh -noprompt [clean]
Remarques :
v -noprompt est un paramètre requis qui vous empêche de
désinstaller WebSphere Remote Server par mégarde. Si ce
paramètre est omis, WebSphere Remote Server ne sera pas
désinstallé.
v -clean est un paramètre facultatif. Si -clean n'est pas spécifié,
seuls les programmes de désinstallation du produit individuel
seront appelés. Si -clean est spécifié, les programmes de
désinstallation exécuteront des étapes supplémentaires pour
supprimer tous les composants de chaque produit. Par exemple,
les répertoires d'installation sont supprimés, les utilisateurs créés
sont supprimés, etc.
Utilisation de l'option clean
Si vous effectuez une désinstallation propre, tous les fichiers WebSphere Remote
Server seront supprimés, mais certains répertoires vides peuvent subsister. Vous
pouvez supprimer ces répertoires vides en toute sécurité.
Remarque : Il est recommandé d'utiliser l'option clean lorsque vous
désinstallezInformix Growth Edition ; cependant, même si la
désinstallation a été effectuée correctement, la réinstallation d'Informix
Growth Edition peut poser des difficultés. Pour plus d'informations,
voir «Astuces pour l'identification et la résolution des incidents», à la
page 131.
51
L'option clean effectue les tâches suivantes :
v Windows:
– cmd /c net user MUSR_MQADMIN /DELETE
– cmd /c net localgroup mqm /DELETE
– Delete C:\DB2
– cmd /c net user DB2ADMIN /DELETE
v Linux:
– rpm -qa | grep WSBAA | xargs -i rpm -e {}
– rpm -qa | grep WSBAA | xargs -i rpm -e {} --nodeps --justdb
– rpm -qa | grep WSPAA | xargs -i rpm -e {}
– rpm -qa | grep WSPAA | xargs -i rpm -e {} --nodeps --justdb
– rm -rf /root/.WASRegistry
–
–
–
–
–
–
rm -rf /opt/.ibm/.nifregistry
rm -rf /opt/.ibm
rpm -qa | grep MQSeries | grep -v 7.0.1-2 | xargs -i rpm -e {}
rpm -qa | grep MQSeries | grep -v Runtime-7.0.1-2 | xargs -i rpm -e {}
rpm -e MQSeriesRuntime-7.0.1-2
rm -rf /var/mqm
– rm -rf /opt/IBM/mqm
– rm -rf /opt/mqm
– rpm -qa | grep DB2 | xargs -i rpm -e {}
–
–
–
–
rm -rf /var/db2
rpm -qa | grep DB2 | xargs -i rpm -e {} --nodeps --justdb
userdel db2inst1
userdel db2fenc1
– userdel dasusr1
– userdel mqm
– groupdel mqm
–
–
–
–
–
groupdel mqbrkrs
groupdel dasadm1
groupdel db2iadm1
groupdel db2fadm1
rm -rf /home/db2inst1 /home/db2fenc1 /home/dasusr1 /home/mqm
v Windows et Linux :
– Répertoire d'installation rd /s /q de WRS BASE
– rd /s /q IFMXDATA
– rd /s /q ISM
– Supprimez toutes les lignes commençant par WSBAA, WSPAA ou WHIHS
dans le fichier vpd.properties. Le fichier Windows se trouve dans
%SYSTEMROOT%\vpd.properties, et le fichier Linux dans /root/vpd.properties.
– Supprimez le répertoire d'installation de WebSphere Application Server.
– Supprimez le répertoire d'installation d'IBM HTTP Server.
– Supprimez le répertoire d'installation de WebSphere MQ.
– Supprimez le répertoire d'installation de DB2.
– Supprimez le répertoire d'installation d'Informix Growth Edition
52
Extension du processus de désinstallation
Lorsque vous procédez à l'extension de la solution WebSphere Remote Server, vous
pouvez ajouter des commandes de désinstallation dans le fichier de métadonnées
correspondant à l'application que vous ajoutez. Le script de désinstallation procède
à la désinstallation de toutes les applications utilisateur avant de désinstaller les
produits middleware WebSphere Remote Server.
Réinstallation des applications
Si vous voulez réinstaller WebSphere Remote Server, modifiez les répertoires
d'installation de WebSphere Application Server et d'IBM HTTP Server afin d'éviter
des erreurs lors de la réinstallation.
Il n'est pas possible de réinstaller Informix Growth Edition si la désinstallation n'a
pas été effectuée proprement. Voir «Astuces pour l'identification et la résolution
des incidents», à la page 131 pour plus d'informations.
53
54
Chapitre 3. Mise à jour et migration
Cette section décrit les étapes à suivre afin de mettre à jour ou migrer IBM
WebSphere Remote Server avec succès.
Stratégie de mise à jour
Il est conseillé de mettre à jour un serveur IBM WebSphere Remote Server à l'aide
d'une solution de mise à jour unifiée.
Ceci vous permet de regrouper les correctifs du middleware, des applications et du
système d'exploitation en un seul package pour une migration simplifiée.
WebSphere Remote Server fournit deux solutions unifiées pour migrer depuis des
versions précédentes pouvant être installées localement à l'aide d'une interface
graphique. Ces solutions sont décrites à la section «Migration», à la page 63.
Pour créer votre propre solution de mise à jour, suivez les étapes de création d'une
solution mentionnées au Chapitre 5, «Extension», à la page 95. L'environnement de
développement WebSphere Remote Server est nécessaire pour la création de la
solution. Si vous avez besoin de mises à jour de produits IBM qui ne se trouvent
pas dans l'environnement de développement WebSphere Remote Server, vous
devez les télécharger depuis l'adresse http://www.ibm.com/support et générer de
nouveaux projets d'application. Ces projets d'application sont décrits au Chapitre 5,
«Extension», à la page 95.
Suivez les instructions suivantes lorsque vous créez une solution de mise à jour :
v Supprimez des packages les fichiers inutiles. Si un package est destiné aux
systèmes d'exploitation Windows, n'ajoutez pas les fichiers requis uniquement
pour les systèmes d'exploitation Linux.
v Limitez les panneaux d'entrée de l'interface utilisateur. WebSphere Remote
Server propose des fonctionnalités qui permettent de détecter à l'aide d'un
programme où le middleware IBM est installé.
Groupes de correctifs et correctifs temporaires de WebSphere Remote
Server
IBM WebSphere Remote Server peut fournir de façon occasionnelle des groupes de
correctifs ou des correctifs temporaires en fonction du besoin. Les groupes de
correctifs fournis par WebSphere Remote Server sont normalement distribués
comme des solutions développées à l'aide de Software Assembly Toolkit. Les
correctifs temporaires (correctifs d'urgence) sont normalement fournis sous la
forme d'un groupe de fichiers et éventuellement sous la forme d'un programme
d'installation simple.
55
Tableau 6. Types de mises à jour fournies par WebSphere Remote Server
Mises à jour
Caractéristiques de chaque mise à jour
Edition
v Nouvelle version de WebSphere Remote
Server qui comprend une nouvelle
fonction importante, comme la
version 7.1.
v Package proposé comme une solution
Software Assembly Toolkit.
v Un test complet de toutes les applications
dotées d'une nouvelle version est
conseillé.
v Une migration est nécessaire à la mise à
niveau.
56
Tableau 6. Types de mises à jour fournies par WebSphere Remote Server (suite)
Mises à jour
Groupe de correctifs
v Il s'agit de la forme standard de livraison
des mises à jour - elle a subi un test de
régression.
v Mis en forme comme une solution
v Un groupe de correctifs représente un
ensemble de correctifs, par exemple Fix
Pack 1 sur la version 7.1 (7.1.0.1).
v Chaque livraison de groupe de correctifs
peut consister en plusieurs groupes de
correctifs pour les produits ou composants
suivants :
– DB2
– Informix Growth Edition
– IBM WebSphere MQ
– IBM HTTP Server
– IBM WebSphere Application Server
Network Deployment
– Java Runtime Environment
– Software Assembly Toolkit
– WebSphere sMash
– WebSphere Remote Server
– Environnement de développement
v Les groupes de correctifs sont installés sur
une version ou un groupe précédent. Par
exemple, la version 7.1.0.2 est appliquée à
la version 7.1.0.1.
v Les groupes de mises à jour sont
cumulatifs, c'est-à-dire que la
version 7.1.0.2 comprend tous les
correctifs de la version 7.1.0.1.
v Les groupes de correctifs désinstallent
tous les correctifs temporaires appliqués à
leur version depuis l'installation du
dernier groupe de correctifs. C'est
pourquoi il est indispensable de vérifier la
liste des correctifs livrés afin de savoir si
un correctif temporaire doit être réinstallé.
v Un test rapide des fonctions essentielles à
l'aide du nouveau groupe de correctifs est
conseillé.
v Reportez-vous à la liste des correctifs et
des instructions d'installation en vue de
déterminer si une migration est nécessaire.
57
Tableau 6. Types de mises à jour fournies par WebSphere Remote Server (suite)
Mises à jour
Correctif temporaire
v Un correctif d'urgence unique.
v Un correctif représente un correctif
temporaire permettant de résoudre un ou
plusieurs défaut(s) de produit.
v Habituellement, WebSphere Remote
Server ne fournit aucun correctif
temporaire pour les produits middleware
de WebSphere Remote Server. Vous
pouvez télécharger des correctifs pour
chaque produit middleware sur le site de
support IBM. Des correctifs de WebSphere
Remote Server sont fournis pour les
composants de WebSphere Remote Server.
v Vous pouvez appliquer un correctif à une
version ou à un groupe de correctifs,
selon les cas.
v Les correctifs temporaires sont créés
lorsqu'un correctif autonome est requis
entre des groupes de correctifs.
v Nous recommandons de tester les
fonctions affectées par le composant
WebSphere Remote Server réparé.
Modification
v Mis en forme comme une solution
v Une version de modification est une mise
à niveau en option.
v Les versions de modification sont
installées sur une version ou un groupe
de correctifs précédent.
v Il pourra être utile d'effectuer une
migration. Reportez-vous à la liste des
correctifs et des instructions d'installation
en vue de déterminer si une migration est
nécessaire.
Tivoli Provisioning Manager-Remote Management Agent Bridge
Le pont IBM Tivoli Provisioning Manager - IBM Remote Management Agent fourni
avec IBM WebSphere Remote Server facilite le déclenchement des mises à jour
logicielles des terminaux de magasin de l'entreprise.
Tivoli Provisioning Manager permet de distriber un package au processeur ISP. Le
pont Tivoli Provisioning Manager-Remote Management Agent décompresse ensuite
ce package et le distribue aux terminaux connectés à ce processeur ISP.
Prérequis d'installation
Les prérequis au niveau de l'entreprise sont un serveur Tivoli Provisioning
Manager et un environnement de développement WebSphere Remote Server déjà
installé.
58
Le pont IBM Tivoli Provisioning Manager-IBM Remote Management Agent est
automatiquement installé lorsque le produit IBM WebSphere Remote Server est
installé sur un processeur ISP.
Le pont Tivoli Provisioning Manager-Remote Management Agent nécessite la
configuration du produit WebSphere Remote Server Enterprise et Tivoli
Provisioning Manager.
Le pont Tivoli Provisioning Manager-Remote Management Agent nécessite que le
processeur ISP de WebSphere Remote Server soit configuré en tant que noeud final
pour WebSphere Remote Server Enterprise. Le programme d'installation du noeud
final est également appelé Tivoli Common Agent.
Le pont Tivoli Provisioning Manager-Remote Management Agent prévoit
également que les terminaux du magasin soient connectés au processeur ISP de ce
dernier et que leur agent General Agent soit enregistré auprès de l'agent Remote
Management Agent Master Agent.
Remarque : Le pont Tivoli Provisioning Manager-Remote Management Agent
nécessite que Remote Management Agent ne force pas les connexions
à utiliser SSL. Pour configurer Remote Management Agent en
fonction, mettez à jour le fichier SI_HOME/user/rma/classes/
ssl.properties avec les modifications suivantes :
v RMA.alias=NOSSL
v RMAMA.alias=NOSSL
Configuration de l'installation de TPM-RMA
La configuration de l'agent IBM Remote Management Agent version 2 s'effectue
via le fichier info.properties. L'exemple de fichier info.properties est fourni
ci-dessous :
Pour configurer le pont Tivoli Provisioning Manager-Remote Management Agent
(TPM-RMA), procédez comme suit :
1. Installez Remote Management Agent version 2.6 Master Agent sur le processeur
ISP. L'agent Master Agent doit être configuré pour utiliser la carte d'interface
réseau (NIC) qui peut être trouvée par l'agent General Agent.
2. Installez Remote Management Agent version 2.6 General Agent sur un autre
serveur situé sur le même réseau que Master Agent.
Remarque : Remote Management Agent Master Agent version 2.6 comprend
deux modes (standard et amélioré). Pour basculer d'un mode à un
autre, modifiez la valeur de com.ibm.retail.si.mgmt.security.mode
dans le fichier SI_HOME/user/rma/security/security.properties.
Vous devez redémarrer le service Remote Management Agent
après avoir changé de mode. Par exemple :
v Mode amélioré :
com.ibm.retail.si.mgmt.security.mode=enhanced
Mode standard :
com.ibm.retail.si.mgmt.security.mode=standard
3. Modifiez le fichier RMA SI_HOME/user/rma/classes/ssl.properties sur toutes
les machines Remote Management Agent. Redémarrez les services Remote
Management Agent après avoir mis à jour les propriétés ssl suivantes :
v RMA.alias=NOSSL
v
59
v RMAMA.alias=NOSSL
4. Modifiez le fichier <SIF_HOME>\RmaBridge\info.properties.
a. Mettez à jour les zones suivantes. (Si vous utilisez la sécurité standard, la
valeur d'EnhancedSecurity est fausse.)
v isEnhancedSecurity
v rmaUsername
v rmaPassword
b. Mettez à jour les paramètres suivants en fonction de votre environnement,
par exemple :
v ftpPackageDir=C:\\Program Files\\IBM\\SIF\\RmaBridge\\
v ftpPolicyDir=C:\\Program Files\\IBM\\SIF\\RmaBridge\\
Remarque : Pour réaliser la distribution de logiciel sur les terminaux,
transmettez les règles de logiciels et le progiciel du terminal à la
machine du processeur ISP. Le fichier XML de règles est disponible
sous le dossier des règles et le logiciel à installer sur le terminal est
placé dans le dossier des packages.
Distribution de logiciel pour TPM RMA
Les règles de logiciels et les logiciels pour le terminal doivent être transmis aux
dossiers du processeur ISP comme indiqué dans la présente rubrique :
Déclenchement de la distribution de logiciel à l'aide du package de distribution
de logiciel (SPD)
Créez un descripteur de progiciel (SPD) IBM Tivoli Provisioning Manager qui
encapsule votre progiciel Remote Management Agent et exécute le script
TriggerScript.sh fourni. Les exemples de fichier SPD suivants sont inclus :
RmaBridgeSampleWin
RmaBridgeSampleLin
TriggerScript accepte six arguments que vous devez lui transmettre à partir du
package d'installation.
Distribuez ce fichier SPD à partir de Tivoli Provisioning Manager vers les noeud
finals (processeur ISP) pour distribuer le fichier de règles et le logiciel dans les
dossiers respectifs comme indiqué ci-dessus.
./TriggerScript.sh version mode
Les paramètres suivants sont utilisés :
Version
La version est Remote Management Agent version 2.6.
Mode La valeur est install ou uninstall.
Remote Management Agent Bridge version 2.6
La présente rubrique fournit des informations sur la fonction IBM Remote
Management Agent Bridge par défaut.
60
Voici la procédure prérequise pour utiliser la fonction de pont Remote
Management Agent Bridge par défaut pour les solutions IBM WebSphere Remote
Server.
v Remote Management Agent General Agent et Master Agent doivent se trouver
sur le même sous-réseau et doivent pouvoir communiquer correctement.
v L'éditeur de progiciels doit être installé dans l'entreprise, où il peut être utilisé
pour publier des fichiers SPB dans le référentiel IBM Tivoli Provisioning
Manager.
v La solution d'exécution WebSphere Remote Server est installée sur le processeur
ISP.
Structure des répertoires Remote Management Agent
Après l'installation des solutions de développement WebSphere Remote Server
dans l'entreprise, les fichiers du pont Remote Management Agent Bridge suivants
sont placés dans la structure de répertoire suivante :
%SIF_HOME%/RmaBridge/
/info.properties
/instructions.txt
/SamplePolicy.xml
/TriggerScript.bat
/TriggerScript.sh
/TcmRmaSwd.jar
%SIF_HOME%/packages/windows/
RmaBridgeSampleWin.spd
%SIF_HOME%/packages/linux/
RmaBridgeSampleLin.spd
Description des fichiers Remote Management Agent
info.properties
Ce fichier contient les informations utilisées par Remote Management
Agent General Agent pour se connecter au serveur et extraire les fichiers
de données et de règles. Mettez à jour les zones du fichier suivantes :
v
v
v
v
v
ftpPackageDir
ftpPolicyDir
policyXMLFileName
isEnhancedSecurity
rmaUsername
v rmaPassword
v clientTargetPath
Vous pouvez mettre à jour le fichier info.properties comme suit :
v ftpPackageDir : A définir sur le répertoire où sont stockés les fichiers de
package. Tous les packages référencés dans votre fichier de règles
doivent se trouver dans ce dossier. Cette propriété doit se terminer par
le caractère de séparation de fichiers (/) (par exemple, package/).
v ftpPolicyDir : A définir en fonction du répertoire où sont stockés les
fichiers de règles. Ce répertoire doit contenir les règles logicielles que
vous distribuez (policyXMLFileName). Cette propriété doit se terminer
par le caractère de séparation de fichiers (/) (par exemple, policy/).
61
v policyXMLFileName : Nom du fichier de règles de distribution de
logiciel Remote Management Agent. Vous devez posséder une copie de
ce fichier dans le répertoire RmaBridge de base et dans le répertoire
spécifié sous ftpPolicyDir.
instructions.txt
Il s'agit du fichier fourni avec le module SamplePolicy.xml. Il est distribué
à Remote Management Agent General Agent sous la structure de répertoire
%SI_HOME%/user/rma/config/swd/staging.
SamplePolicy.xml
Ce fichier contient la liste des commandes à exécuter sur la machine de
General Agent. Pour comprendre et éditer ce fichier, consultez le guide
d'utilisation de Remote Management Agent : ftp://ftp.software.ibm.com/
software/retail/pubs/sw/storeintegration/bqe3_RMA_userguide_mst.pdf.
TriggerScript.bat(sh)
Ce fichier appelle le code RmaBridge avec deux paramètres transmis via le
fichier SPB.
RmaBridgeSampleWin.spd
Progiciel contenant les instructions permettant de placer les fichiers
SamplePolicy.xml et instructions.txt au niveau du processeur ISP.
Ce fichier contient des instructions permettant d'exécuter le script
TriggerScript.bat sur le processeur ISP. Le fichier SPD transmet un total de
six paramètres qui sont utilisés pour appeler le script TriggerScript.bat sur
le processeur ISP. Vous pouvez éditer n'importe lequel des paramètres dans
le fichier SPD avant de le convertir en fichier SPB. Le premier paramètre
doit être défini sur V2 pour utiliser le code Remote Management Agent
Bridge version 2.6. Le deuxième paramètre peut être install ou uninstall.
Si vous utilisez install, General Agent exécute uniquement la balise
<installation> dans le fichier SamplePolicy.xml. Si vous utilisez uninstall, il
exécute uniquement la balise <uninstallation> du fichier SamplePolicy.xml.
RmaBridgeSampleLin.spd
Version Linux du fichier RmaBridgeSampleWin.spd.
Utilisation du code Remote Management Agent Bridge version
2.6
Pour utiliser le code Remote Management Agent Bridge version 2.6, procédez
comme suit.
v Utilisez l'éditeur de progiciels pour convertir tous les fichiers SPD en fichiers
SPB et les publier dans Tivoli Provisioning Manager. Faites toutes les
modifications nécessaires avant la conversion.
v Utilisez la fonctionnalité Tivoli Provisioning Manager pour publier, distribuer et
installer RmaBridgeSampleLinD.spb ou RmaBridgeSampleWinD.spb en fonction
du système d'exploitation du processeur ISP. Vérifiez que la barre verte s'affiche
dans le gestionnaire de tâches Tivoli Provisioning Manager après l'envoi du
fichier SPB. La barre verte indique que l'opération a réussi.
Remarque : Pour comprendre comment configurer l'éditeur de progiciels et
l'infrastructure évolutive Tivoli Provisioning Manager et installer les
fichiers SPB, consultez le livre blanc WebSphere Remote Server Solution
et la section Packaging software for distribution de l'aide en ligne de
Tivoli Provisioning Manager.
62
1. L'éditeur de progiciels est une application de navigateur qui
nécessite IBM Java Runtime Environment 1.5. Il ne fonctionnera
pas avec des versions supérieures de Java.
2. Avant d'enregistrer un progiciel, vérifiez le nom d'hôte du serveur
Web dans vos préférences. Il doit correspondre au nom d'hôte de
votre serveur Tivoli Provisioning Manager.
Migration
IBM WebSphere Remote Server prend en charge la migration automatisée des
processeurs intégrés au magasin des versions 6.1, 6.2, 6.2.1, 7.0 et 7.1 vers la
version 7.1.1 des éditions WebSphere Remote Server.
Le processus de migration est contenu dans la solution utilisée pour les nouvelles
installations et peut être exécuté depuis le DVD.
Le tableau ci-dessous présente la migration prise en charge pour différents
systèmes d'exploitation. Si un système d'exploitation n'y figure pas, cela signifie
qu'aucune migration n'est prise en charge pour lui.
Remarque :
v La migration sur les systèmes d'exploitation 64 bits est prise en
charge uniquement si elle est effectuée depuis WebSphere Remote
Server version 7.1. La migration depuis les autres versions est prise
en charge uniquement sur les systèmes d'exploitation 32 bits.
v La migration depuis Windows XP avec Service Pack 2 et SUSE
Linux Enterprise Server 10.1 et 10.2 est toujours prise en charge.
Cependant, Windows XP avec Service Pack 2 (32 bits) et SUSE
Linux Enterprise Server 10.1 et 10.2 ne sont plus pris en charge sur
WebSphere Remote Server version 7.1.1.
Tableau 7. Liste des systèmes d'exploitation et de la migration prise en charge
Version de WebSphere Remote Server
pouvant être migrée
Microsoft Windows 2003 Server avec Service 6.1, 6.2, 6.2.1, 7.0, 7.1
Pack 2
Microsoft Windows 2003 Server édition 2
avec Service Pack 2
6.1, 6.2, 6.2.1, 7.0, 7.1
SUSE Linux Enterprise Server 10.1 et 10.2
6.2, 6.2.1, 7.0, 7.1
Red Hat Enterprise Linux 5.2 et 5.3
6.2.1, 7.0, 7.1
Microsoft Windows XP avec Service Pack 2
6.2.1, 7.0, 7.1
Microsoft Windows 2008
7.0, 7.1
Microsoft Windows POSReady 2009
7.0, 7.1
SUSE Linux Enterprise Server 11
7.1
Remarque : Il n'y a pas de migration de l'environnement de développement. Des
versions différentes d'IBM Software Assembly Toolkit peuvent
cohabiter mais ce n'est pas le cas des groupes de correctifs ou de
mises à jour apparentés. Vous pouvez par exemple installer les
versions 2.1.x, 2.2.x et 3.1 sur un même ordinateur, mais pas les
versions 2.1.1 et 2.1.2.
63
Migration vers la version 7.1.1
Avant de commencer
v Veillez à arrêter le gestionnaire de files d'attente WebSphere MQ avant de
procéder à la migration. Vous trouverez les instructions d'arrêt du gestionnaire
de files d'attente dans la rubrique Stopping a Queue Manager du centre de
documentation IBM WebSphere MQ.
v Si vous effectuez une migration sur un système d'exploitation Windows 2003,
veillez à installer le module de correction MS08-067 de Microsoft au préalable.
Sans ce module de correction, la migration de WebSphere Application Server
échouera.
v Si vous effectuez une migration depuis la version 6.1 sur un système
d'exploitation Windows 2003, vous devez activer la sécurité de WebSphere
Application Server. Créez un fichier C:\temp\WAS_ID_PW.txt contenant votre nom
d'utilisateur et votre mot de passe WebSphere Application Server avant de
démarrer le programme d'installation de WebSphere Remote Server. Par
exemple, ce fichier doit contenir les éléments suivants :
MyWasAdminUser
MyWasAdminPw
v Si vous effectuez la migration sur un système d'exploitation SUSE Linux
Enterprise Server 10.1 ou 10.2, vous devez d'abord effectuer la mise à niveau
vers SUSE Linux Enterprise Server 10.3 avant la migration vers la version 7.1.1.
SUSE Linux Enterprise Server 10.1 et 10.2 ne sont plus pris en charge sur
WebSphere Remote Server version 7.1.1.
v Si vous effectuez la migration depuis la version 6.1, vous devez aussi définir la
valeur du chemin d'accès aux classes du fournisseur JDBC sur la variable
d'environnement ${DB2UNIVERSAL_JDBC_DRIVER_PATH} avant de démarrer le
processus de migration. Cette variable sera mise à jour lors de la migration.
Dans le cas contraire, la connexion de test pour la source de données des
applications d'exemple échouera une fois la migration terminée. Pour obtenir des
instructions sur le paramétrage de la valeur du chemin d'accès aux classes du
fournisseur JDBC, consultez la rubrique "Configuration d'un fournisseur JDBC à
l'aide de la console d'administration" dans le centre de documentation de
WebSphere Application Server version 6.1.
Procédure
Remarques :
accélérateurs.
installation.
64
Server.
Server.
l'installation.
5. Sélectionnez Migration à partir de WebSphere Remote Server 6.1 ou 6.2.x ou
Migration à partir de WebSphere Remote Server 7.0 ou 7.1, en fonction de la
version à partir de laquelle vous effectuez la migration.
6. Les composants d'exécution et middleware sont présélectionnés. Cliquez sur
Suivant pour poursuivre.
Remarque : Seuls les composants déjà installés dans la version à partir de
laquelle vous effectuez la migration sont présélectionnés. Pour en
installer d'autres, vous devez lancer WebSphere Remote Server
Solution Installer après la migration et sélectionner les
composants à installer à partir de l'option d'installation de
l'environnement d'exécution de Retail Store Server. Pour plus
d'informations sur cette procédure, voir «Installation d'IBM
WebSphere Remote Server», à la page 12.
7. Indiquez un répertoire d'installation pour le composant de base IBM Retail
Store Server et cliquez sur Suivant. Cette valeur est la variable
d'environnement SIF_HOME. Pour SIF_HOME, vous pouvez utiliser en toute
sécurité le même répertoire que celui présent dans votre installation
WebSphere Remote Server existante.
Remarque : Vous ne pouvez pas modifier la valeur de SIF_HOME lors de la
migration.
8. Pour les autres panneaux, indiquez les paramètres d'installation obligatoires et
facultatifs lorsque vous y êtes invité par l'assistant de déploiement.
Pour obtenir une description détaillée de chaque zone, voir «Zones
d'installation de l'environnement d'exécution», à la page 20.
Remarques :
v Pour WebSphere Application Server, le répertoire d'installation
doit être différent de celui présent dans le chemin
d'installation de WebSphere Application Server.
v Le répertoire d'installation, l'ID utilisateur administrateur et le
mot de passe utilisés pour DB2 doivent être identiques à ceux
indiqués pour le composant DB2 existant, à une exception
près. Lors de la migration depuis la version 6.2 ou 6.2.1 vers
la version 7.1.1 sur un système d'exploitation Linux, le
répertoire d'installation doit être différent du répertoire
d'installation DB2 existant.
65
v Les répertoires d'installation d'IBM HTTP Server et de
WebSphere MQ doivent rester identiques aux répertoires
d'IBM HTTP Server et de WebSphere MQ existants.
10. Si vous avez effectué l'installation sur un système d'exploitation Windows,
procédez comme suit :
v Réamorcez votre serveur pour que le système d'exploitation puisse accéder
aux mises à jour.
v Mettez à jour le numéro de port dans le lien de raccourci pour la console
d'administration WebSphere Application Server dans votre menu Démarrer.
Pour plus d'informations, reportez-vous à la note technique WebSphere
Application Server suivante : http://www.ibm.com/support/
docview.wss?rs=180&uid=swg21385225
66
Chapitre 4. Gestion
La section Gestion d'IBM WebSphere Remote Server décrit les différentes tâches de
nettoyage qui doivent être effectuées pour conserver WebSphere Remote Server en
bon état de fonctionnement.
Contrôle de WebSphere Remote Server
Les processeurs intégrés au magasin qui ont été configurés à l'aide de la pile de
composants middleware IBM WebSphere Remote Server doivent être capables de
démarrer et d'arrêter les applications et de les interroger sur leur statut
d'exécution, individuellement ou en tant que pile de serveur.
Principes de fonctionnement
Les scripts sont fournis pour contrôler la solution WebSphere Remote Server selon
des niveaux de granularité différents.
Les tâches de démarrage, d'arrêt ou d'exécution des requêtes de statut des
applications du composant middleware WebSphere Remote Server sont réalisées à
l'aide de commandes appropriées. Les commandes sont exécutées en local sur le
processeur intégré au magasin via un appel local ou à partir d'une machine
distante pouvant exécuter des processus sur le processeur intégré au magasin.
L'exécution des commandes de démarrage, d'arrêt ou d'exécution des requêtes de
statut dans le processeur intégré au magasin (ISP) nécessite de connaître les
informations spécifiques à ce processeur pour pouvoir remplir la tâche de
commande. Le fait de garder dans le processeur intégré au magasin les
informations nécessaires à l'exécution des commandes offre également la plus
grande flexibilité lors de l'exécution des requêtes de commandes à partir des
machines distantes. Lors de l'ajout, de la suppression ou de la modification
d'applications, les informations sur l'application ne doivent pas forcément être
remises à jour dans un emplacement distant centralisé.
Mais comment le processeur intégré au magasin obtient-il les informations
permettant de démarrer, d'arrêter ou d'interroger le statut d'exécution des
middleware qui y sont chargés ? WebSphere Remote Server collecte les
informations spécifiques à la machine au fur et à mesure que les composants
middleware sont installés sur celle-ci. Les données collectées sont stockées dans le
fichier de métadonnées de WebSphere Remote Server dans le processeur intégré au
magasin.
Une fois les informations spécifiques à la machine concernant les middleware
collectées, une application du processeur intégré au magasin peut démarrer,
s'arrêter, ou interroger le statut d'exécution en appelant le script approprié sur ce
même processeur. Les scripts utilisent les informations sur les middleware
contenues dans le fichier de métadonnées WebSphere Remote Server pour exécuter
les tâches de commande de démarrage, d'arrêt ou de statut.
Le fichier de métadonnées WebSphere Remote Server est un fichier XML qui
contient des informations de configuration et de contrôle sur les composants
middleware de WebSphere Remote Server installés sur le processeur intégré au
magasin. Les informations contenues dans ce fichier sont initialement obtenues lors
67
de l'installation de WebSphere Remote Server.
Scripts de contrôle de WebSphere Remote Server
Les scripts suivants utilisés pour contrôler la pile middleware et les applications
(démarrage, arrêt ou interrogation du statut d'exécution) sont fournis avec
WebSphere Remote Server et se trouvent dans le répertoire SIF_HOME/bin :
v wrsstart.sh : démarre la pile ou une application.
v wrsstop.sh : arrête la pile ou une application.
v wrsrunstatus.sh : interroge le statut d'exécution de la pile ou d'une application.
v wrsstart.bat : démarre la pile ou une application.
v wrsstop.bat : arrête la pile ou une application.
v wrsrunstatus.bat : interroge le statut d'exécution de la pile ou d'une application.
Les scripts mentionnés ci-dessus fonctionnent avec l'ensemble de la solution
WebSphere Remote Server et les applications et sous-composants faisant partie de
la solution WebSphere Remote Server.
Remarque : Exécutez les commandes start, stop et de requête de statut à partir
d'une nouvelle fenêtre de ligne de commande. Ces commandes ne
peuvent pas être exécutées à partir de la fenêtre de ligne de
commande que vous avez utilisée pour l'installation car
l'environnement doit être mis à jour. L'ouverture d'une nouvelle
fenêtre met à jour l'environnement.
Le format de chaque commande est indiqué ci-dessous :
wrsstart [application || nom_application nom_sous_composant] [-silent -log -verbose]
wrsstop [application || nom_application nom_sous_composant] [-silent -log -verbose]
wrsrunstatus [application || nom_application nom_sous_composant] [-silent -log -verbose]
Les paramètres suivants sont facultatifs :
v -silent : Les informations relatives au résultat de la commande n'apparaissent
pas à l'écran.
v -log : Les informations relatives au résultat de la commande sont imprimées
dans le fichier journal.
v -verbose : Les informations détaillées sur l'exécution de la commande de
débogage sont imprimées dans le type de sortie indiqué.
Par défaut, les informations récapitulatives liées au résultat de la commande
apparaissent à l'écran.
Pour les opérations de la pile WebSphere Remote Server, le code de statut suivant
apparaît une fois la commande exécutée :
v 0 : Les codes retour de la commande indiquent que toutes les commandes ont
été exécutées avec succès 2
v 1 : Les codes retour de la commande indiquent qu'une ou plusieurs commandes
n'ont pas été exécutées avec succès 2
v 2 : Les codes achèvement des commandes sont inconnus, autrement dit, les
commandes ne peuvent pas être exécutées2
68
Pour les opérations du composant WebSphere Remote Server seul, le code de statut
suivant apparaît une fois la commande exécutée :
Commandes wrsstart, wrsstop :
v 2 : Le code achèvement de cette commande est inconnu, autrement dit, la
commande ne peut pas être exécutée1
v any value : Le code actuel renvoyé lors de l'exécution de la commande (peut
être '2' si '2' est un code valide pour la commande) 1
Commande wrsrunstatus
v 0 : L'élément interrogé est en cours de fonctionnement 2
v 1 : L'élément interrogé n'est pas en cours de fonctionnement 2
v 2 : Le statut de fonctionnement de l'élément interrogé n'est pas totalement
connu 2
1
Le code renvoyé indique le statut démarrage ou arrêt de l'avancement du
traitement de la commande. Il n'indique pas si la pile/application a été démarrée
ou arrêtée. Utilisez la commande wrsrunstatus pour vérifier si la pile/application
est en cours de fonctionnement.
2
Les codes retour des commandes sont normalisés en 0, 1 ou 2.
Si la consignation des commandes est activée pour la commande à l'aide du
paramètre -log, tous les statuts de renvoi pertinents sont consignés dans le fichier
SIF_HOME/logs/wrscommands.log.
Les scripts wrsstart, wrsstop et wrsrunstatus emploient des scripts auxiliaires
spécifiques à un composant donné. Ces scripts sont indiqués ci-dessous et se
trouvent dans le répertoire SIF_HOME/bin :
wrs_DB2Admin_start.bat/sh
wrs_DB2Admin_stop.bat/sh
wrs_DB2Admin_status.bat/sh
wrs_DB2_start.bat/sh
wrs_DB2_stop.bat/sh
wrs_DB2_status.bat/sh
wrs_IDS_start.bat/sh
wrs_IDS_stop.bat/sh
wrs_IDS_status.bat/sh
wrs_IHSAdmin_start.bat/sh
wrs_IHSAdmin_stop.bat/sh
wrs_IHSAdmin_status.bat/sh
wrs_IHS_start.bat/sh
wrs_IHS_stop.bat/sh
wrs_IHS_status.bat/sh
wrs_MQ_start.bat
wrs_MQ_stop.bat
wrs_MQ_status.bat
wrs_WAS_start.bat/sh
wrs_WAS_stop.bat/sh
wrs_WAS_status.bat/sh
Exemples de scripts de contrôle de WebSphere Remote Server
Les scripts de contrôle de WebSphere Remote Server peuvent être utilisés pour
démarrer des solutions, des applications ou des sous-composants d'application.
Dans cette section, nous présentons divers exemples permettant d'illustrer
l'utilisation des scripts de contrôle.
Lorsque WebSphere Remote Server est installé, la solution se nomme WRS et
représente l'ensemble de la pile de middleware. Une solution se compose
d'applications qui représentent les composants middleware. Les applications par
défaut qui constituent la solution WRS sont les suivantes :
Chapitre 4. Gestion
69
v
v
v
v
v
IBM WebSphere Application Server
DB2
Informix Growth Edition
IBM HTTP Server
IBM WebSphere MQ
Solution
Le contrôle du niveau de la solution peut être testé à l'aide des scripts mis à
disposition. La syntaxe utilisée pour le contrôle du niveau de la solution est la
suivante :
v wrsstart : démarre la solution.
v wrsstop : arrête la solution.
v wrsstatus : interroge le statut d'exécution de la solution.
Applications et sous-composants
Les applications et les sous-composants d'application peuvent être contrôlés à
l'aide des scripts de contrôle WebSphere Remote Server illustrés ci-dessus.
Voici, de nouveau, la syntaxe appropriée pour ces scripts :
Les paramètres suivants sont facultatifs :
v -silent : Les informations relatives à l'exécution de la commande n'apparaissent
pas à l'écran.
v -log : Les informations relatives à l'exécution de la commande apparaissent
v -verbose : Les informations détaillées relatives à l'exécution de la commande de
Par exemple, si le profil WRSProfile de WebSphere Application Server doit être
démarré en mode débogage, la commande est wrsstart WAS WRSProfile –verbose.
Les informations de débogage s'affichent à l'écran.
Si le profil WRSProfile de WebSphere Application Server doit être affiché en mode
débogage et que les informations de débogage ne doivent pas s'afficher à l'écran, la
commande est wrsstart WAS WRSProfile -silent -log –verbose.
Les informations de débogage s'affichent uniquement dans le fichier journal.
En plus du contrôle d'applications et de sous-composants simples, une liste
d'éléments devrait également figurer au niveau des applications et des
70
sous-composants. Dans ce cas, la liste sera traitée de la même manière que celle
figurant dans l'exemple de solution ci-dessus.
Pour plus d'informations sur la manière d'étendre l'utilisation des scripts de
contrôle, voir «Contrôle des applications WebSphere Remote Server et ISP», à la
page 121.
Surveillance d'événements
La présente section décrit les tâches d'administration et les outils de surveillance
spécifiques de accélérateurs.
Utilisation de JMX Event Listener
JMX Event Listener s'exécute en tant que bean géré sous IBM Remote Management
Agent et achemine certains événements JMX publiés par les beans gérés sous
proxy du Remote Management Agent vers les mappeurs d'événements
personnalisés.
Ces mappeurs d'événements personnalisés doivent implémenter l'interface
com.ibm.sif.event.JMXEventMapper. Par exemple, vous pouvez créer un mappeur
d'événements personnalisé qui transmet les alertes SNMP. JMX Event Listener
supprime la transmission de certaines classes d'événements par configuration.
Remote Management Agent n'est plus inclus ou installé comme composant d'IBM
WebSphere Remote Server. Cependant, accélérateurs prend toujours en charge
Remote Management Agent.
Si Remote Management Agent est mis à jour manuellement ou via une mise à
niveau du système d'exploitation IBM Retail Environment SUSE Linux (IRES),
procédez comme suit :
v Dans votre environnement spécifique :
Remarque : Si Remote Management Agent ne possède pas de variable
d'environnement COMMON_HOME, vous devez définir celle-ci sur
la même valeur que RMA_HOME.
IBM Retail Environment SUSE Linux
Remplacez la valeur de la variable RMA_HOME du fichier
/opt/ibm/SIF/bin/SifSetupCmdLine.sh par la même valeur RMA_HOME
spécifiée dans le fichier /etc/sysconfig/storeintegrator.
Remplacez la valeur de la variable COMMON_HOME du fichier
/opt/ibm/SIF/bin/SifSetupCmdLine.sh par la même valeur
COMMON_HOME spécifiée dans le fichier /etc/sysconfig/
storeintegrator.
Microsoft Windows
Remplacez la valeur de la variable RMA_HOME du fichier C:\Program
Files\IBM\SIF\bin\SifSetupCmdLine.bat par la même valeur de variable
d'environnement RMA_HOME.
Remplacez la valeur de la variable COMMON_HOME du fichier
C:\Program Files\IBM\SIF\bin\SifSetupCmdLine.bat par la même
valeur de variable d'environnement COMMON_HOME.
Chapitre 4. Gestion
71
Remarque : Dans l'environnement Microsoft Windows, les variables
RMA_HOME et COMMON_HOME sont définies comme variables
d'environnement après l'installation ou la mise à niveau de Remote
Management Agent.
v Réinstallez SNMP Trap Mapper à l'aide du script d'installation accélérateurs.
Pour plus d'informations sur Remote Management Agent, voir Remote Management
Agent User's Guide, disponible dans la section Remote Management Agent du site
Web suivant : http://www2.clearlake.ibm.com/store/support/html/pubs.html.
Démarrage et arrêt de JMX Event Listener
JMX Event Listener s'exécute dans IBM Remote Management Agent en tant que
bean géré. Remote Management Agent peut être configuré pour démarrer
automatiquement JMX Event Listener lorsque Remote Management Agent démarre
et pour l'arrêter lorsque Remote Management Agent s'arrête.
La syntaxe de ces fichiers XML est décrite dans le guide d'utilisation de Remote
Management Agent, accessible à partir de la section Remote Management Agent du
site Web : http://www2.clearlake.ibm.com/store/support/html/pubs.html.
Le fichier XML pour le démarrage de ce bean géré accepte deux arguments de
chaîne.
v Nom de classe de JMXEventMapper à utiliser (par exemple
com.ibm.sif.event.mapper.snmp.TrapGenerator pour SNMP Trap Generator). Cet
argument est obligatoire.
v Une liste séparée par des virgules de noms de classes de notification que JMX
Event Listener ne peut pas transmettre. Les composants séparés par des virgules
peuvent également être spécifiés comme expressions régulières. Cet argument est
facultatif.
Ce fichier de configuration doit être placé dans RMA_HOME\config\startup.
Fichier de configuration d'exemple : SNMPTrapMapperStartup.xml
<?xml version="1.0" ?>
<AgentStartupConfig>
<MBeans>
<MBean className="com.ibm.sif.event.JMXEventListener"
objectName="masteragent:SIFMBean=true,SIFComponent=MGMT,Id=JMXtoSNMP">
<MBeanArg type="java.lang.String">com.ibm.sif.event.mapper.snmp.
TrapGenerator</MBeanArg>
<MBeanArg type="java.lang.String">com.ibm.retail.si.mgmt.notifications.
RtlTracePointNotification</MBeanArg>
</MBean>
</MBeans>
<NotificationListeners>
<NotificationListener listener="masteragent:SIFMBean=true,SIFComponent=MGMT,
Id=JMXtoSNMP"broadcaster="masteragent:SIFMBean=true,SIFComponent=MGMT,
Id=NotificationControl" />
</NotificationListeners>
</AgentStartupConfig>
Remote Management Agent est démarré automatiquement après son installation
(sous Windows et Linux) et son redémarrage (sous Windows). Cependant, si vous
modifiez un fichier de configuration, vous devez redémarrer Remote Management
Agent pour que ces modifications soient prises en compte.
72
Pour démarrer Remote Management Agent sur le processeur ISP, entrez la
commande suivante :
Linux : /etc/init.d/rmsvc-ma start
Windows : Démarrez IBM Remote Management Agent à l'aide du panneau
Services.
Pour arrêter Remote Management Agent sur le processeur ISP, entrez la commande
suivante :
Linux : /etc/init.d/rmsvc-ma stop
Windows : Arrêtez IBM Remote Management Agent à l'aide du panneau
Services.
Modification de la transmission d'événements par défaut
JMX Event Listener peut être configuré pour supprimer la transmission de
certaines classes de notification.
Modifiez le fichier de configuration XML de démarrage de l'agent qui démarre
votre programme d'écoute JMX Event Listener pour supprimer la transmission de
certaines classes de notification.
Modifiez le second bean géré de JMX Event Listener. L'argument doit être une liste
de noms de classes de notification séparée par des virgules que JMX Event Listener
ne peut pas transmettre. Les composants séparés par des virgules peuvent
également être spécifiés comme expressions régulières.
Par exemple, vous pouvez supprimer les notifications d'avertissement et de
débogage en définissant le paramètre sur les valeurs suivantes :
.*Warning.*,.*Debug.*
Interface JMXEventMapper
Vous pouvez générer votre propre extension JMX Event Listener pour traiter des
événements JMX de manière spécifique. Vous devez implémenter l'interface
com.ibm.sif.event.JMXEventMapper, incluse dans le fichier JMXEventListener.jar.
public interface JMXEventMapper extends NotificationListener {
/**
* All NotificationListener objects MUST implement this function.
* This is the function that is invoked when a notification is detected.
* Different "JMX Event Listeners" will want to do different things with
* notifications, but this class will pass the Notifications on to other
* "mapper" classes
*
* @see javax.management.NotificationListener#handleNotification
(javax.management.Notification, java.lang.Object)
*/
public void handleNotification(Notification notification, Object handback);
}
Le nouveau code doit être généré dans un fichier jar et installé dans le répertoire
RMA_HOME\ext. En outre, un nouveau fichier de démarrage de bean géré doit être
créé et installé dans RMA_HOME\config\startup. Enfin, IBM Remote Management
Agent doit être redémarré pour prendre en compte cette modification.
Utilisation des fichiers journaux et de la fonction de trace de
JMX Event Listener
Utilisez la fonction de trace de JMX Event Listener pour faciliter l'identification et
la résolution des problèmes.
Chapitre 4. Gestion
73
Par défaut, la fonction de trace est consignée dans les emplacements suivants :
Linux : /opt/ibm/StoreIntegrator/silogs/simgmt.0
Windows : C:\Program Files\IBM\StoreIntegrator\silogs\simgmt.0
Pour identifier les problèmes, activez la fonction de trace détaillée de JMX Event
Listener.
Procédure
1. Editez le fichier mgmt_log.pro du processeur ISP. Vous trouverez ce fichier
dans les répertoires suivants :
Linux : /opt/ibm/StoreIntegrator/RMA<version-rma> où <version-rma> fait
référence à la valeur de la variable RMA_BUILD spécifiée dans le fichier
/opt/ibm/SIF/bin/SifSetupCmdLine.sh.
Windows : C:\Program Files\IBM\StoreIntegrator\RMA<version-rma> où
<version-rma> fait référence à la valeur de la variable RMA_BUILD
spécifiée dans le fichier C:\Program Files\IBM\SIF\bin\
SifSetupCmdLine.bat.
2. Modifiez la ligne com.ibm.retail.level = FINEST.
3. Redémarrez le serveur de Master Agent sur le processeur ISP.
v Sous Linux, entrez les commandes suivantes :
/etc/init.d/rmsvc-ma start
/etc/init.d/rmsvc-ma stop
v Sous Windows, redémarrez IBM Remote Management Master Agent à l'aide
du panneau Services.
Activation du fournisseur de données WebSphere Remote
Server
Le fournisseur de données IBM WebSphere Remote Server est copié dans la
machine pendant l'installation de WebSphere Remote Server Solution mais n'est
pas activé.
Lors de l'installation de l'agent maître IBM Remote Management Agent, vous
devez sélectionner le mode de sécurité standard. WebSphere Remote Server version
7.1.1 ne prend pas en charge le mode de sécurité amélioré de Remote Management
Agent. Seule l'adresse IPV4 est actuellement prise en charge pour configurer les
données d'identification pour le mode de sécurité standard.
Remarque : Remote Management Agent version 2.2 n'est plus pris en charge, si
bien qu'il est inutile de télécharger et d'installer le correctif APAR
IO08293.
Avant d'activer le fournisseur de données WebSphere Remote Server, procédez
comme suit :
v Installez IBM Tivoli Monitoring Universal Agent sur la même machine.
v Configurez le fichier wrsdp-config.xml.
Après avoir accompli les étapes prérequises, utilisez les commandes suivantes pour
activer le fournisseur de données WebSphere Remote Server.
Windows
"%SIF_HOME%\WRSDP\bin\WRSDPService.exe" -add -wrsdpHome "%SIF_HOME%\WRSDP"
74
Linux
cd $SIF_HOME/bin
./SifInstall.sh WRSDP
Le fournisseur de données WebSphere Remote Server démarre à présent
automatiquement en tant que service à chaque démarrage de la machine. Après
l'activation initiale, vous devez démarrer le service manuellement :
Windows
net start WRSDPWinService
Linux
/opt/IBM/SIF/WRSDP/bin/startWRSDP.sh
Remarque : Le fournisseur de données WebSphere Remote Server doit démarrer
après chaque application qu'il surveille.
Pour désactiver le fournisseur de données WebSphere Remote Server, procédez
comme suit :
Windows
"%SIF_HOME%\WRSDP\bin\WRSDPService.exe" -remove
Linux
rm
rm
rm
rm
rm
rm
rm
/etc/init.d/wrsdp
/etc/init.d/rc2.d/S99wrsdp
/etc/init.d/rc2.d/K98wrsdp
Configuration du fournisseur de données WebSphere Remote
Server pour la surveillance d'événements
Le fournisseur de données IBM WebSphere Remote Server est configuré à l'aide
d'un fichier XML placé dans le dossier etc. Un fichier wrsdp-config.xml d'exemple
a été fourni. Ce fichier indique quels beans gérés et leurs attributs doivent être
surveillés par le fournisseur de données WebSphere Remote Server. Ce fichier est
également utilisé pour générer le métafichier requis par l'agent Universal Agent
pour reconnaître les messages du fournisseur de données WebSphere Remote
Server. Ce fichier doit être modifié au niveau de l'entreprise avant la distribution
de logiciel. Vous pouvez le modifier si vous souhaitez surveiller vos beans gérés
personnalisés à l'aide du fournisseur de données WebSphere Remote Server. Pour
surveiller chaque groupe de beans gérés, une section groupe_attribut doit être
ajoutée. Un groupe d'attributs est une collection d'attributs que vous souhaitez
surveiller pour une sélection de beans gérés.
Remarque : Si vous utilisez WRSDP pour surveiller IBM Remote Management
Agent, vous devez mettre à jour la configuration Remote Management
Agent. Le fournisseur de données WebSphere Remote Server nécessite
que Remote Management Agent ne force pas les connexions à utiliser
SSL. Pour configurer Remote Management Agent en conséquence,
mettez à jour le fichier SI_HOME/user/rma/classes/ssl.properties
avec les modifications suivantes :
v RMA.alias=NOSSL
v RMAMA.alias=NOSSL
Fichier de configuration d'exemple :
Chapitre 4. Gestion
75
<WRSDataProvider>
<application name="JVM" description="RMA MBeans" JMXServerURL="service:jmx:rmi://localhost:10150/jndi/ma"
collectionInterval="120000">
<events objectNameQuery="masteragent:*">
<allow>javax.management.Notification</allow>
</events>
<env key="MA_IP_ADDRESS" value="127.0.0.1" />
<env key="JMX_CREDENTIAL_PROVIDER" value="com.ibm.sif.RMACredentialProvider" />
<env key="java.naming.factory.initial" value="com.sun.jndi.rmi.registry.RegistryContextFactory" />
<env key="java.naming.provider.url" value="rmi://localhost:10150" />
<attribute-group name="JVMEnvironment" description="Master Agent JVM Environment"
objectNameQuery="masteragent:SIFMBean=true,SIFComponent=MGMT,Id=JVMEnvironment,*" delimiter="^^">
<objectNameComponents>
<objectNameComponent name="Id" displayname="MBean Identifier"
description="Uniquely identifies an MBean" type="String" length="14" />
</objectNameComponents>
<attributes>
<attribute name="FreeMemory" displayname="Free Memory (bytes)" type="Numeric" />
<attribute name="TotalMemory" displayname="Total Memory (bytes)" type="Numeric" />
<attribute name="ActiveThreadCount" displayname="Active Thread Count" type="Numeric" />
</attributes>
</attribute-group>
</application>
</WRSDataProvider>
Remarque : Ce fichier de configuration d'exemple nécessite Remote Management
Agent. Il surveille la machine virtuelle Java de Remote Management
Agent.
Description des entités de schéma XML :
v WRSDataProvider : balise principale du fichier de configuration.
v application : correspond à un regroupement majeur d'attributs surveillés,
comme une application unique. Correspond à //APPL dans les termes de
métafichier Universal Agent.
– nom : correspond au nom Universal Agent interne de cette application et doit
suivre les règles de désignation d'Universal Agent (les trois premières lettres
doivent être uniques).
– description : texte d'infobulle affiché dans TEP lorsque vous placez la souris
sur cette application.
– JMXServerUrl : URL destinée à la connexion au serveur JMX de l'application
via JSR-160. Si elle est omise, tente de créer une connexion JSR-77 à la
machine virtuelle Java locale.
– collectionInterval : (facultatif) définit la fréquence de collecte de données pour
cette application. La valeur par défaut est 300 secondes.
v events : à utiliser si vous souhaitez collecter les événements de ce serveur JMX.
– objectNameQuery : (facultatif) ObjectNameQuery JMX indiquant quels beans
gérés doivent être interrogés sur les événements.
v allow : (facultatif) filtre positif des types de classes d'événement.
v deny : (facultatif) filtre négatif des types de classes d'événement.
v env : correspond à une variable d'environnement. Les variables d'environnement
sont parfois nécessaires pour établir des connexions JSR-160.
– key : nom de variable.
– value : valeur de variable.
v attribute-group : collection d'attributs à collecter pour chaque bean géré/groupe
de beans gérés. Chaque attribut spécifié doit être défini sur tous les beans gérés
du groupe. Correspond à //ATTRIBUTES dans les termes de métafichier
Universal Agent.
– name : nom affiché dans TEP pour ce groupe d'attributs.
– description : texte d'infobulle affiché dans pour ce groupe d'attributs.
– objectNameQuery : JMX ObjectNameQuery indique quels beans gérés
doivent être interrogés pour collecter les attributs donnés.
76
– delimiter : (facultatif) caractère utilisé pour délimiter les données de zone lors
de l'envoi de messages à Universal Agent. Il doit s'agir d'un caractère non
utilisé dans les données de zone. Le caractère par défaut est le point-virgule
(;).
v objectNameComponents : composants du nom d'objet du bean géré. Ces
composants sont utilisés pour associer les données à celles de la source d'origine.
– objectNameComponent : composant du nom d'objet du bean géré. Utilisé
pour associer les données à celles de la source d'origine.
– name : portion clé du composant du nom d'objet valeur-clé.
– displayname : texte d'infobulle et nom de colonne affichés dans TEP.
– type : chaîne, numérique ou booléen.
– length : (obligatoire pour le type de chaîne.) Longueur de la chaîne.
v attributes : attributs exposés par les beans gérés dans ce groupe d'attributs.
– attribute : attribut exposé par les beans gérés dans ce groupe d'attributs.
– name : nom de l'attribut du bean géré. MyAttr si le bean géré expose
getMyAttr().
– displayname : texte d'infobulle et nom de colonne affichés dans TEP.
– type : chaîne, numérique ou booléen.
– length : (obligatoire pour le type de chaîne.) Longueur de la chaîne.
Remarque : Parmi les zones décrites ci-dessous, seule la zone de description peut
contenir des caractères non anglais pour des raisons de traduction.
Remarque : Si vous configurez WebSphere Remote Server Data Provider pour
surveiller Remote Management Agent version 2.2, vous devez
télécharger le correctif APAR IO08293 pour Remote Management
Agent. Pour obtenir ce correctif, contactez le support WebSphere
Remote Server.
Configuration des métafichiers
Les fichiers de configuration sont fournis à Universal Agent (également appelés
métafichiers en langange Universal Agent). Ainsi, Universal Agent peut
comprendre les messages provenant du fournisseur de données WebSphere Remote
Server et les données structurées peuvent être envoyées à Tivoli Enterprise Portal.
Le fichier jmx.mdl indique le format des messages JMX Event. Ce fichier est fourni
avec accélérateurs et vous ne devez pas le modifier.
Remarque : Le texte qui suit le caractère @ peut être traduit. Si vous utilisez le
texte traduit, les attributs 'D' doivent être modifiés en ‘U'. Par
exemple,
UserData U 500 @Données spécifiées par notification
Fichier d'exemple (jmx.mdl) :
//APPL JMX
//NAME JmxEvents E @Evénements JMX de Remote Management Agent
//SOURCE SOCK localhost
//ATTRIBUTES ’;’
userData D 500 @Données spécifiées par notification
timeStamp N 13 @Millisecondes depuis le 1er janvier 1970
type D 200 @Provenance de l’événement
message D 500 @Message du bean géré
source D 400 @Nom d’objet du bean géré
seqNum C 5 @Numéro de séquence fourni par le bean géré
Chapitre 4. Gestion
77
Les fichiers de script import_metafiles.bat et import_metafiles.sh analysent la
syntaxe de votre fichier wrsdp-config.xml, génèrent et importent les nouveaux
métafichiers dans Universal Agent. Il est important d'effectuer les personnalisations
requises dans le fichier wrsdp-config.xml avant d'exécuter le script d'importation.
Configuration du démarrage de l'agent
Les fichiers de configuration du démarrage de l'agent IBM Remote Management
Agent peuvent être utilisés pour démarrer certains beans gérés lors du démarrage
de Remote Management Agent. La syntaxe du fichier est décrite dans le guide
d'utilisation d'IBM Remote Management Agent, mais il est possible de configurer
les beans gérés spécifiés d'une autre manière. Le fournisseur de données
WebSphere Remote Server est une extension (implémentations JMXEventMapper)
d'un programme d'écoute d'événement JMX Event Listener. Lorsque JMX Event
Listener est démarré, il peut avoir deux arguments de chaîne :
v Nom de classe de JMXEventMapper à utiliser. Le nom de classe affiché
ci-dessous (com.ibm.sif.event.mapper.snmp.TrapGenerator) n'est qu'un exemple
et n'est pas fourni. Cet argument de nom de classe est obligatoire.
v Une liste séparée par des virgules de noms de classes de notification que JMX
Event Listener ne peut pas transmettre. Les composants séparés par des virgules
peuvent également être spécifiés comme expressions régulières. Il s'agit d'un
argument facultatif.
Ces fichiers doivent être placés dans l'emplacement suivant : RMA_HOME\config\
startup.
<?xml version="1.0" ?>
<AgentStartupConfig>
<MBeans>
<MBean className="com.ibm.sif.event.JMXEventListener"
objectName="masteragent:SIFMBean=true,SIFComponent=MGMT,Id=SNMPTrapMapper">
<MBeanArg type="java.lang.String">com.ibm.sif.event.mapper.snmp.TrapGenerator
</MBeanArg>
</MBean>
</MBeans>
<NotificationListeners>
<NotificationListener listener="masteragent:SIFMBean=true,SIFComponent=MGMT,
Id=WRSDP" broadcaster="masteragent:SIFMBean=true,
SIFComponent=MGMT,Id=NotificationControl" />
</NotificationListeners>
</AgentStartupConfig>
Génération du mappeur d'événements
Il est possible de gérer les événements JMX en créant un mappeur d'événements
personnalisé. Pour ce faire, vous devez implémenter l'interface
com.ibm.sif.event.JMXEventMapper.
public interface JMXEventMapper extends NotificationListener {
/**
All NotificationListener objects MUST implement this function.
This is the function that is invoked when a notification is detected.
Different "JMX Event Listeners" will want to do different things with
notifications, but this class will pass the Notifications on to other
"mapper" classes
*
@see javax.management.NotificationListener#handleNotification(javax.management.Notification, java.lang.Object)
*/
public void handleNotification(Notification notification, Object handback);
}
Le nouveau code doit être généré dans un fichier jar et installé dans le répertoire
RMA_HOME\ext. En outre, un nouveau fichier de démarrage de bean géré (tel
que RMASDPStartup.xml) doit être créé et installé dans RMA_HOME\config\
startup. Vous devez redémarrer RMA pour prendre en compte cette modification.
78
Manipulation des beans gérés en fonction des situations ITM
Manipulez des attributs de beans gérés en créant une situation dans ITM. Une
situation désigne tout simplement une condition. Par exemple, vous pouvez créer
une situation pour le bean géré JVMEnvironment en spécifiant la condition comme
FreeMemory > 0 et en associant une action en fonction de la valeur. La création de
la situation est un élément prérequis.
Pour manipuler les attributs de bean géré, procédez comme suit :
v Cliquez avec le bouton droit de la souris sur un élément de navigateur et
sélectionnez Situations.
v Cliquez sur l'icône permettant de créer de nouvelles situations. La boîte de
dialogue Créer une situation apparaît.
v Indiquez les valeurs pour les zones Nom et Description. Cliquez sur OK.
v La boîte de dialogue Sélectionner une condition apparaît. Choisissez les valeurs
pour Type de condition, Groupe d'attributs et Elément d'attribut, puis cliquez
sur OK.
v Dans l'onglet Formule de la boîte de dialogue Situations pour, choisissez la
condition.
v Dans l'onglet Distribution de la boîte de dialogue Situations pour, choisissez
tous les agents à inclure.
v Dans l'onglet Action de la boîte de dialogue Situations pour, spécifiez ou
sélectionnez les valeurs suivantes :
– Sélection d'une action : commande système
– Commande système : /opt/IBM/SIF/WRSDP/bin/invoke_attribute_script.sh
(chemin qualifié complet du script à exécuter.) Les paramètres suivants
doivent être spécifiés : l'URL de service JMX (JMXServiceURL) du serveur de
bean géré (MBeanServer), le nom d'objet du bean géré (MBean ObjectName),
le nom d'attribut et la nouvelle valeur d'attribut.
Remarques :
- Cette commande définit un attribut de bean géré sur une
nouvelle valeur.
- Vous pouvez également utiliser la commande :
/opt/IBM/SIF/WRSDP/bin/invoke_method_script.sh, qui
accepte les paramètres suivants : l'URL de service JMX
(JMXServiceURL) du serveur de bean géré (MBeanServer), le
nom d'objet du bean géré (MBean ObjectName), le nom de la
méthode et les paramètres (le cas échéant).
- Si le serveur de bean géré (MBeanServer) auquel vous vous
connectez nécessite des variables d'environnement
supplémentaires, vous devez éditer ces scripts et étendre la
variable JAVA_ARGS pour chaque nouveau paramètre. Les
scripts comportent des exemples de variables JAVA_ARGS
nécessaires pour se connecter à IBM Remote Management
Agent et à IBM WebSphere Application Server.
- Si vous vous connectez à plusieurs serveurs de bean géré
(MBeanServers) différents, vous devez effectuer des copies
des scripts invoke_attribute_script.sh et
invoke_method_script.sh scripts et chaque copie doit indiquer
les variables d'environnement d'un serveur spécifique. Par
exemple, vous pouvez copier invoke_attribute_script.sh dans
rma_attribute_script.sh et modifier rma_attribute_script.sh
pour qu'il utilise les variables d'environnement RMA.
Chapitre 4. Gestion
79
– Si la condition est vraie pour plusieurs éléments surveillés : Lancez une
action sur chaque élément.
– Emplacement d'exécution (réalisation) de l'action : Exécutez l'action dans le
système géré (agent).
– Si la condition reste vraie sur plusieurs intervalles : Lancez une action dans
chaque intervalle.
Cliquez sur OK.
Une fois la condition remplie, vous pouvez consulter l'événement dans la Console
d'événements de situation.
Remarque : Pour plus d'informations sur la création de situations, consultez le
Centre de documentation IBM Tivoli Monitoring.
Contrôleur de messages WebSphere MQ Message Controller
IBM WebSphere MQ Message Controller contrôle le flux de messages de l'émetteur
au récepteur et fait en sorte que WebSphere MQ ne monopolise pas la bande
passante du réseau.
Utilisez WebSphere MQ Message Controller pour contrôler le nombre de messages
ou la quantité de données de message envoyée sur le canal WebSphere MQ lorsque
les situations suivantes se produisent :
v Le canal WebSphere MQ est opérationnel après une panne prolongée du réseau.
v La bande passante du réseau est insuffisante et les messages WebSphere MQ
utilisent une partie de la bande passante requise par un trafic de données plus
importantes, comme les journaux des transactions.
Installation du contrôleur de messages WebSphere MQ
Message Controller
Message Controller est un composant de l'offre IBM WebSphere Remote Server et
doit être installé à l'emplacement adapté après installation de WebSphere Remote
Server.
Pour vous assurer que Message Controller est correctement installé, confirmez la
présence des fichiers LinSenderChannelController/
WinSenderChannelController.dll et mqexitprog.properties à l'emplacement
suivant après l'installation de WebSphere Remote Server :
MQ_HOME\exits
SIF_HOME/mqexits
(64 bits) SIF_HOME/mqexits/exits64
L'existence de ces fichiers ne garantit pas que Message Controller est installé sur le
système. Ces fichiers sont mis à disposition par défaut et peuvent donc être
utilisés. Si un besoin métier nécessite l'utilisation du contrôleur, suivez les étapes
de la section «Configuration du contrôleur de messages WebSphere MQ Message
Controller».
Configuration du contrôleur de messages WebSphere MQ
Message Controller
Suivez les étapes présentes dans cette rubrique pour configurer Message Controller.
80
Pour activer l'environnement WebSphere MQ à contrôler, procédez comme suit :
v Configurez les exits de message pour les canaux cibles.
v Modifiez le fichier mqexitprog.properties.
Procédure
1. Configurez le canal WebSphere MQ pour les exits de message à l'aide de
l'explorateur WebSphere MQ Explorer.
a. Naviguez jusqu'au bon gestionnaire de files d'attente.
b. Développez l'onglet Advanced (Avancé) → Channels (Canaux).
c. Cliquez avec le bouton droit de la souris sur le canal émetteur que vous
souhaitez configurer.
d. Accédez à l'onglet Exits et faites défiler la liste jusqu'à la section Message
Exits Name (Nom des exits de message).
e. Repérez le fichier WinSenderChannelController.dll ou le fichier
LinSenderChannelController dans votre système de fichiers.
f. Saisissez le chemin\nomdefichier(ChannelExit). Par exemple, sous Windows,
WebSphere MQ est installé dans C:\Program Files\IBM\MQ ; par exemple,
C:\Program Files\IBM\MQ\exits\WinSenderChannelController(ChannelExit)
g. Cliquez sur OK et redémarrez le canal.
Remarque : Vous pouvez également utiliser la commande Alter Channel
(Modifier le canal) dans l'interpréteur de commandes mqsc
(comme mqm et exécuter runmqsc) pour modifier le canal pour
les exits WebSphere MQ. Cette modification doit être effectuée
sur le système où le canal émetteur est configuré.
Voici des exemples d'utilisation de la commande Alter
Channel :
alter channel (’nom_du_canal’) chltype (SDR)
msgexit (’$SIF_HOME/mqexits/
LinSenderChannelController(ChannelExit)’)
alter channel (’nom_canal’) chltype (SDR)
msgexit (’%MQ_HOME%\exits\
WinSenderChannelController(ChannelExit)’)
2. Modifiez le fichier mqexitprog.properties. Il contient les variables qui
contrôlent l'exécution du contrôleur de messages. Voici les variables définies
dans ce fichier :
v SLEEP_INTERVAL : Valeur par défaut : 0. Valeurs possibles : 0 à 9999. Cette
variable détermine la durée (en secondes) pendant laquelle le canal
WebSphere MQ attend avant d'envoyer le prochain lot de messages. Une
valeur définie sur 0 signifie que l'exit de canal est désactivé.
Remarque : Si vous ne prévoyez pas d'utiliser Message Controller et que
vous choisissez la valeur 0 pour SLEEP_INTERVAL, il
fonctionnera comme prévu mais l'utilisation du processeur sera
plus importante. Il est recommandé de supprimer les exits de
message si vous ne souhaitez pas utiliser le contrôleur de
messages plutôt que de choisir la valeur 0.
Chapitre 4. Gestion
81
v MESSAGE_COUNTER : Valeur par défaut : 0. Valeurs possibles : 0 à 9999.
Cette variable détermine le nombre de messages à envoyer l'intervalle
d'attente de SLEEP_INTERVAL (exprimé en secondes). Si la valeur est
définie sur 0, cette variable n'est pas prise en compte pour le contrôle du flux
de messages.
Remarque : A chaque fois que vous modifiez MESSAGE_COUNTER ou
MESSAGE_SIZE_COUNTER dans les fichiers de propriétés,
vous devez supprimer le fichier appelé mqexitprog.log. Ce
fichier journal se trouve dans les dossiers suivants :
/var/mqm
MQ_HOME\exits
v MESSAGE_SIZE_COUNTER : Valeur par défaut : 0. Valeurs possibles : 0 à
65000 octets. Cette variable indique le volume de données envoyées avant
l'activation de la fonction d'attente. Si la valeur est définie sur 0, cette
variable n'est pas prise en compte pour le contrôle du flux de messages.
v EFFECTIVE_BETWEEN : Valeur par défaut : 0000:0000. Valeurs possibles :
de 0000:0001 à 0000:2359. Cette variable détermine les heures système (de
hhmm à hhmm) durant lesquelles le contrôleur d'attente fonctionne. Au-delà
des heures indiquées, le contrôleur n'a pas d'influence sur le flux de
messages. Si la valeur est définie sur 0000:0000, le contrôleur est actif en
permanence. Indiquez les heures au format 24 heures.
Pour savoir si le contrôleur doit s'arrêter, Message Controller procède de la
façon suivante :
Si Nombre_messages_en_cours < MESSAGE_COUNTER &
Taille_message_effective < MESSAGE_SIZE_COUNTER &
EFFECTIVE_BETWEEN est valide, le message peut être envoyé sans attendre.
Sinon, attendez pendant le nombre de secondes équivalent à
SLEEP_INTERVAL avant d'envoyer le message.
Exemple de développement : SLEEP_INTERVAL 20 (20 secondes d'attente
avant d'envoyer le prochain lot de messages) MESSAGE_COUNTER 10 (mise
en attente tous les 10 messages) MESSAGE_SIZE_COUNTER 20000 (ou dès que
le volume de données envoyées a atteint cette limite) EFFECTIVE_BETWEEN
0800:2100 (à condition qu'il soit entre 8h00 et 21h00).
Remarque : Nous vous conseillons de surveiller attentivement le message
WebSphere MQ généré après la configuration du contrôleur de
messages WebSphere MQ Message Controller. Si vous avez
configuré des valeurs serrées pour les variables définies ci-dessus,
le taux de génération des messages peut dépasser le taux d'envoi
de ceux-ci. Pour éviter de telles situations, il est conseillé de
n'activer le contrôleur de messages que pendant les heures de la
journée où le travail est intensif.
Autres approches de Message Controller
Il existe des approches alternatives permettant de simuler la fonctionnalité du
contrôleur de messages (Message Controller). Chaque approche présente ses
propres avantages et inconvénients. Vous devez comprendre ces approches afin de
déterminer celle qui convient le mieux à vos exigences et à la configuration de
votre entreprise.
82
Réduction de la longueur de file d'attente et augmentation des
tentatives d'envoi via le canal
Avec cette approche, l'administrateur WebSphere MQ peut définir la longueur de
file d'attente de réception sur une valeur très basse (par exemple sur 2) et définir
l'intervalle entre les tentatives d'envoi de messages via le canal sur 60 secondes
par exemple. Ainsi, lorsque la file d'attente de réception atteint la limite de
dépassement, le canal de liaison passe en mode de relance lorsqu'il tente d'envoyer
le message suivant. Cela a pour conséquence indirecte le contrôle du débit du flux
de messages au sein du canal WebSphere MQ.
L'avantage d'une telle configuration est qu'elle ne nécessite aucune application
supplémentaire pour contrôler le flux de messages. Cette approche est également
un peu plus efficace en ce qui concerne l'utilisation des UC et de la mémoire.
L'inconvénient de cette configuration est que cette approche ne garantit pas la
limitation du flux à un nombre défini de messages par minute. Si l'application qui
traite les messages au niveau de l'extrémité réceptrice est assez rapide pour
récupérer les messages avant que la file d'attente n'atteigne la limite de
dépassement, alors cette configuration est inefficace.
Compression des messages
Avec cette approche, l'administrateur WebSphere MQ active la
compression/décompression WebSphere MQ. Le moteur WebSphere MQ
compresse la partie de données du message avant d'envoyer ce dernier sur le
canal. Le moteur WebSphere MQ décompresse ensuite le message au niveau de
l'extrémité réceptrice, avant que le message ne soit ajouté à la file d'attente de
réception.
Les avantages d'une telle approche sont les suivants :
v Elle est entièrement transparente aux applications utilisateur d'envoi/de
réception.
v Temps système UC/mémoire faibles.
v Réduction drastique de la taille des messages (jusqu'à 90 % pour des données
sous forme de texte ASCII).
v Réduction importante de l'utilisation du réseau pour chaque message envoyé.
v Fonctionnement permanent garanti.
En revanche, l'inconvénient de cette approche est qu'elle dépend beaucoup des
types de données du message. La compression est très efficace sur les messages de
texte, mais elle est imperceptible pour les données de message binaires.
Gestion des mots de passe à l'aide des flux de travaux Tivoli
Provisioning Manager
La présente section décrit la fonctionnalité de gestion des mots de passe via les
flux de travaux IBM Tivoli Provisioning Manager. Le composant de gestion des
mots de passe est utilisé pour gérer les mots de passe pour les composants
middleware configurés dans le fichier de métadonnées IBM WebSphere Remote
Server. Par défaut, seuls les comptes utilisateur créés lors de l'installation des
middleware WebSphere Remote Server sont configurés pour être gérés par le
Chapitre 4. Gestion
83
composant de gestion des mots de passe. L'interaction avec le composant de
gestion des mots de passe se fait actuellement via les flux de travaux Tivoli
Provisioning Manager uniquement.
Utilisation du composant de gestion des mots de passe
Le composant de gestion des mots de passe vous permet de demander la date
d'expiration des comptes utilisateur pour les composants middleware de
WebSphere Remote Server et de modifier ces mots de passe à distance.
L'application vous permet de demander les mots de passe sur plusieurs noeuds
finaux en une seule fois}et à distance à partir du serveur Tivoli Provisioning
Manager. Vous pouvez ensuite examiner le fichier de sortie pour déterminer les
comptes utilisateur des noeuds finaux distants qui nécessitent des mises à jour
avec de nouveaux mots de passe. Vous pouvez également créer un fichier au
format CSV contenant les informations importantes sur les comptes utilisateur des
noeuds finaux distants et appeler à la fonctionnalité de modification de mot de
passe pour changer à distance les mots de passe de plusieurs comptes utilisateur
sur plusieurs noeuds finaux.
Pour contribuer au démarrage du flux de travaux d'analyse, vous devez préparer
un fichier CSV contenant l'ID de noeud final et le nom d'hôte de noeud final. Pour
faciliter la création du fichier CSV, vous pouvez utiliser l'utilitaire de génération de
rapports de Tivoli Provisioning Manager pour générer la liste des systèmes que
vous souhaitez gérer.
L'application d'analyse effectue une analyse du fichier de métadonnées présent sur
les noeuds finaux où sont installés les middleware WebSphere Remote Server.
L'application de gestion des mots de passe se limite à la gestion des comptes
utilisateur ayant une entrée pertinente dans le fichier de métadonnées. Ces
comptes utilisateur doivent être en outre des comptes au niveau du système
d'exploitation.
Pour contribuer au démarrage du flux de travaux de modification, vous devez
préparer un fichier CSV contenant la liste des comptes utilisateur sur différents
hôtes pour lesquels l'application doit modifier le mot de passe. Il est recommandé
de se référer au fichier CSV d'exemple inclus dans le package (workflows/samples/
samplehostpasswordfile.csv). L'application de modification analyse le fichier CSV
et créé plusieurs fichiers de travaux temporaires, un sur chaque noeud final, puis
appelle le processus de modification de mot de passe sur chacun des noeuds
finaux. Le statut de modification de mot de passe de chaque utilisateur sur chaque
noeud final est ensuite compilé dans un autre fichier CSV. Le nom et
l'emplacement de ce fichier CSV résultant s'affichent à la fin de l'exécution du flux
de travaux invokeChangePassword.
Avant de commencer à utiliser le composant de gestion des mots de passe, vous
devez importer les flux de travaux dans Tivoli Provisioning Manager. L'installation
du composant de gestion des mots de passe sur le processeur ISP est réalisée au
moment de l'installation des middleware WebSphere Remote Server. Les
composants à installer sur Tivoli Provisioning Manager (entreprise) sont
disponibles dans le dossier SIF_HOME/PasswordMgmt/workflows, présent sur chaque
système où est installé WebSphere Remote Server.
Remarque : Si vous utilisez le composant de gestion des mots de passe sur une
plateforme SUSE Linux Enterprise Server dans une langue autre que
l'anglais, vous devez d'abord exporter la variable d'environnement
LANG dans le fichier /etc/profile. La valeur LANG correspond à
84
l'environnement local du poste de travail SUSE Linux Enterprise
Server contenant les mots de passe à gérer.
Installation du composant de gestion des mots de passe sur le
serveur Tivoli Provisioning Manager
Pour installer le composant de gestion des mots de passe sur le serveur Tivoli
Provisioning Manager, procédez comme suit :
1. Copiez le contenu du dossier SIF_HOME\PasswordMgmt\workflows à partir du
noeud final où est installé WebSphere Remote Server dans un emplacement
temporaire sur le serveur qui héberge Tivoli Provisioning Manager.
2. Exécutez le script installPwdMgmt.bat/sh script avec le paramètre requis
<install location>.
3. Confirmez l'installation. Vérifiez si les répertoires <install location>\workfiles et
<install location>\outputfiles ont été créés. Vérifiez également si <install
location> contient le fichier cleanup.bat/sh.
4. Ouvrez l'interface utilisateur de Tivoli Provisioning Manager Server dans le
navigateur, puis cliquez sur Aller à → Gestion → Application des accès → Flux
de travaux d'application des accès.
.
5. Dans le composeur de flux de travaux d'application des accès, cliquez sur
6. Cliquez sur Sélectionner une action > Ouvrir un flux de travaux.
7. Accédez au fichier de flux de travaux scanPasswordWorkflow.wkf qui se trouve
dans le dossier copié à l'étape 1.
8. Compilez le flux de travaux.
9. Répétez les étapes 6 et 7 pour le fichier de flux de travaux
changePasswordWorkflow.wkf.
Configuration du serveur Tivoli Provisioning Manager et des
noeuds finaux pour la gestion des mots de passe
Pour configurer le serveur Tivoli Provisioning Manager et les noeuds finaux pour
la gestion des mots de passe, procédez comme suit :
Remarque : Avant de commencer cette configuration, assurez-vous que Tivoli
Common Agent est installé sur les noeuds finaux.
1. Le point d'accès au service pour le type de données d'identification du serveur
Tivoli Provisioning Manager (Windows) est le mot de passe de tous les points
d'accès au service.
v Serveur SSH (pour les noeuds finaux Linux) et le critère de recherche est ssh.
v Client SSH (pour les noeuds finaux Linux) et le critère de recherche est ssh.
v Serveur RXA (pour les noeuds finaux Windows) et le critère de recherche est
rxa.
v Client RXA (pour les noeuds finaux Windows) et le critère de recherche est
rxa.
2. Point d'accès au service pour le noeud final Windows.
v Serveur RXA et le critère de recherche est rxa.
v Client RXA et le critère de recherche est rxa.
v Serveur d'agent.
3. Point d'accès au service pour le noeud final Linux.
v Serveur SSH et le critère de recherche est ssh.
v Client SSH et le critère de recherche est ssh.
Chapitre 4. Gestion
85
v Serveur d'agent.
Etant donné que les flux de travaux codent en dur les valeurs des justificatifs de
sécurité de ssh et rxa, il est recommandé d'utiliser les critères de recherche définis
ci-dessus. Comme les informations sur les mots de passe vont être transférées sur
le canal, il est également recommandé d'utiliser les protocoles de chiffrement
suivants pour la communication entre le serveur Tivoli Provisioning Manager et le
noeud final.
Création d'un rapport pour récupérer les listes du système
Vous devez créer un rapport qui fournit une liste de systèmes pour lesquels vous
souhaitez activer la fonctionnalité de gestion des mots de passe. Pour créer un
fichier CSV à utiliser pour le test de la gestion des mots de passe, procédez comme
suit :
1. Ouvrez la console Tivoli Provisioning Manager et ouvrez une session avec le
nom d'utilisateur maxadmin.
2. Cliquez sur Aller à → Gestion → Génération de rapports → Gestion des
rapports.
3. Entrez serverDetails dans Nom du fichier de rapport, puis appuyez sur
Entrée.
4. Sélectionnez l'enregistrement tp_serverDetails.rptdesign pour afficher la
configuration du rapport dans la page Rapport.
5. Cliquez sur Nouvelle ligne pour ajouter une nouvelle ligne à l'aide des
paramètres suivants :
Nom de paramètre
osname
Nom d'attribut
softwareresource.softwaremodule.name
Nom de consultation
tpm_osname
Nom d'affichage
Nom du système d'exploitation
6.
7.
8.
9.
Séquence d'affichage
4
Cliquez sur l'icône d'enregistrement pour sauvegarder la configuration.
Cliquez sur la page de génération de demande pour générer la page de
demande, puis sur Aperçu pour ouvrir celle-ci.
Entrez % dans la zone Nom de l'ordinateur, choisissez le système
d'exploitation approprié dans la zone Nom du système d'exploitation, puis
cliquez sur Soumettre.
Dans la page de génération de rapport, cliquez sur l'icône Exporter des
données pour afficher la page d'exportation de données.
10. Sélectionnez les colonnes id_serveur et nom_serveur, puis cliquez sur OK
pour sauvegarder le fichier CSV.
11. Ouvrez le rapport de liste des systèmes et supprimez tous les noeuds finals
sur lesquels vous n'envisagez pas d'exécuter l'application d'analyse.
Exécution de l'application d'analyse
Pour exécuter l'application d'analyse, procédez comme suit :
86
1. Supposons que vous ayez importé le flux de travail scanPasswordWorkflow
dans Tivoli Provisioning Manager, sélectionnez et exécutez
scanPasswordWorkflow.
2. Le système vous invite à entrer les valeurs suivantes :
v serverIdFileName : chemin d'accès absolu avec le nom de fichier CSV qui
contient la liste des noeuds finaux sur lesquels vous envisagez d'exécuter
l'application d'analyse.
v TPM_PASSWORDMGMT_HOME : emplacement sur le serveur Tivoli
Provisioning Manager où est installé le composant de gestion des mots de
passe.
v TPM_Server_Hostname : nom du serveur Tivoli Provisioning Manager.
Celui-ci doit correspondre à l'entrée de l'enregistrement recensé dans Tivoli
Remarque : Le fichier en entrée CSV pour scanPasswordWorkflow peut
contenir des informations pour les noeuds finaux Windows et
Linux.
3. Une fois scanPasswordWorkflow exécuté, un nouveau fichier CSV contenant
des informations utiles telles que le nom d'hôte, le nom d'utilisateur et la date
d'expiration du mot de passe est créé sur le serveur Tivoli Provisioning
Manager. L'emplacement et le nom du fichier peuvent correspondre à la valeur
du paramètre OutputFile défini lorsque le flux de travaux est terminé. Pour
vérifier cette valeur, cliquez sur l'ID demande du flux de travaux et affichez les
résultats.
Exécution de l'application de modification
Pour exécuter l'application de modification, procédez comme suit :
1. Supposons que vous ayez importé le flux de travaux changePasswordWorkflow
dans Tivoli Provisioning Manager, sélectionnez et exécutez
changePasswordWorkflow.
2. Le système vous invite à entrer les valeurs suivantes :
v hostPasswordFileName : chemin d'accès absolu avec le nom de fichier CSV
qui contient la liste des noeuds finaux ainsi que le nouveau et l'ancien mot
de passe. Pour obtenir un exemple du fichier, reportez-vous au fichier
samplehostpasswordfile.csv.
v TPM_PASSWORDMGMT_HOME : emplacement sur le serveur Tivoli
Provisioning Manager où était installé le composant de gestion des mots de
passe.
v TPM_Server_Hostname : nom du serveur Tivoli Provisioning Manager.
Celui-ci doit correspondre à l'entrée de l'enregistrement recensé dans Tivoli
3. Une fois l'exécution du flux de travaux terminée, la variable de flux de travaux
PasswordChangeStatus récapitule le statut d'exécution du flux de travaux. En cas
d'erreurs d'exécution, reportez-vous aux fichiers indiqués portant la valeur de
variable OutputFile correspondant aux informations sur l'échec.
Remarque : Partout où Tivoli Provisioning Manager demande une entrée sous
la forme nomfichier/cheminfichier pour Windows, vous êtes censé
utiliser \\ et non \ comme séparateur. Pour Linux, utilisez /
comme séparateur de fichiers.
Chapitre 4. Gestion
87
Installation et activation d'IBM Tivoli License Compliance Manager
Tivoli License Compliance Manager gère la conformité à la licence. Il reconnaît et
contrôle quelles offres de produits, avec leurs versions, éditions et groupes de
correctifs, sont installées et utilisées sur le système.
IBM WebSphere Remote Server prend en charge l'utilisation du serveur Tivoli
License Compliance Manager pour collecter et gérer les informations relatives à
l'utilisation.
Pour installer et activer Tivoli License Compliance Manager, vous devez
télécharger l'agent Tivoli License Compliance Manager et l'installer sur chaque
composant WebSphere Remote Server. Vous trouverez les instructions de
téléchargement de Tivoli License Compliance Manager dans le centre de
documentation Tivoli License Compliance Manager.
Le fichier de signature de WebSphere Remote Server pour l'agent Tivoli License
Compliance Manager est déployé sur WebSphere Application Server pendant
l'installation de WebSphere Remote Server. Après l'installation, une version de
sauvegarde du fichier se trouve dans le répertoire SIF_HOME\tivoli. Cinq fichiers
sont disponibles :
v RSSIDSSTR0701.SYS2 (si IBM Retail Store Server Starter Edition with Informix
Database est installé)
v RSSDB2STR0701.SYS2 (si IBM Retail Store Server Starter Edition est installé)
v RSSDB2ADV0701.SYS2 (si IBM Retail Store Server Advanced Edition est installé)
v RSSIDSADV0701.SYS2 (si IBM Retail Store Server Advanced Edition with Informix
Database est installé)
v RSSDB2CSS0701.SYS2 (si IBM WebSphere Central Site Server est installé)
Remarques relatives à la sécurité
L'amélioration de la sécurité des systèmes d'informations orientés vers la vente et
de la transmission et du stockage des données dans ces systèmes est devenue l'un
des problèmes les plus importants rencontrés par les revendeurs. Beaucoup de
grandes entreprises ont connu des violations de sécurité qui leur ont coûté une
fortune à cause des procès, des réparations d'infrastructures informatiques, de la
perte de confiance des clients et des sanctions des principales sociétés de cartes de
crédit.
Afin d'empêcher que des violations de sécurité se reproduisent, des normes de
sécurité telles que la norme PCI DSS (Payment Card Industry Data Security
Standard) ont été développées pour guider le personnel informatique responsable
de la sécurité des systèmes et des données d'une organisation. La conformité PCI
DSS est exigée pour toutes les entreprises qui traitent et/ou stockent le numéro
PAN (Primary Account Number) associé aux cartes de paiement. Même si une
organisation n'utilise pas les numéros PAN, la norme PCI DSS représente un
modèle à suivre pour la sécurité de l'infrastructure informatique dans n'importe
quelle organisation orientée vers la vente.
Les informations présentées dans cette rubrique sont destinées à vous guider dans
le traitement des principales erreurs liées à la sécurité qui peuvent survenir lors de
l'installation et de la configuration d'une solution IBM WebSphere Remote Server.
En prenant pour modèle la norme PCI DSS, les éléments présentés dans cette
rubrique peuvent servir de point de départ pour identifier les problèmes à
examiner lorsque l'on tente de renforcer la sécurité de son système. Les actions
88
préconisées relatives aux composants de l'installation WebSphere Remote Server
sont illustrées pour permettre de se conformer à chacune des douze exigences
principales de la norme PCI.
Pour plus d'informations sur les contenus présentés dans cette rubrique, consultez
les liens suivants :
v PCI Security Standards Council – PCI DSS (en anglais) :
https://www.pcisecuritystandards.org
v WebSphere Application Server version 7.0.0.9, Renforcement des configurations de la
sécurité : http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/
com.ibm.websphere.nd.doc/info/ae/ae/tsec_hardsecconfig.html
v WebSphere Application Server version 7.0.0.9, Réglage, renforcement et gestion des
configurations de la sécurité : http://publib.boulder.ibm.com/infocenter/wasinfo/
v7r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/
tsec_tunehardmaintain.html
v WebSphere Application Server version 7.0.0.9, Sécurisation des mots de passe dans
les fichiers : http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/
com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/tsec_securepwds.html
v Mission: Messaging: WebSphere MQ, PCI DSS et normes de sécurité par T. Rob
Wyatt (en anglais) : http://www.ibm.com/developerworks/websphere/
techjournal/0806_mismes/0806_mismes.html
v Sécurité d'WebSphere MQ : http://publib.boulder.ibm.com/infocenter/wmqv7/
v7r0/index.jsp?topic=/com.ibm.mq.amqzag.doc/fa12730_.htm
v DB2 version 9.7 Fix Pack 2 for Linux, UNIX et Windows, Gaining access to Data
through indirect means : http://publib.boulder.ibm.com/infocenter/db2luw/
v9r7/topic/com.ibm.db2.luw.admin.sec.doc/doc/c0021061.html
v Sécurité d'Informix Growth Edition : http://publib.boulder.ibm.com/infocenter/
idshelp/v115/index.jsp?topic=/com.ibm.sec.doc/SEC_wrapper.htm
PCI DSS
La norme PCI DSS comprend douze exigences de base requises pour la
certification des entreprises qui effectuent une ou plusieurs des opérations
suivantes : stockage, traitement, transmission ou élimination des informations sur
les cartes de paiement. Chacun de ces douze points principaux comporte de
nombreux points secondaires. La norme a été créée dans le cadre d'une
collaboration entre diverses sociétés telles que Visa, Mastercard, American Express,
etc. Dans un souci de concision, seuls les douze points principaux sont présentés
ici.
Les douze exigences de base suivantes peuvent être regroupées de manière logique
en thèmes afin de présenter les domaines fonctionnels à prendre en compte lors de
l'analyse du bon fonctionnement et de la stabilité d'un réseau sécurisé :
Générer et gérer un réseau sécurisé
Sécurisez virtuellement l'ensemble des itinéraires présents dans les
systèmes critiques de votre organisation en bloquant les tentatives
d'intrusion et les attaques inconnues. Cela permet d'assurer la sécurité des
données des titulaires de carte et d'installer une première ligne de défense
forte contre les violations de sécurité.
1. Installez et gérez une configuration de pare-feu pour protéger les
données des titulaires de carte.
Chapitre 4. Gestion
89
2. N'utilisez pas les mots de passe système et autres paramètres de sécurité
par défaut donnés par les fournisseurs.
Protéger les données des titulaires de carte
Protégez les données des titulaires de carte en contrôlant leurs
mouvements, leur mode de stockage et de transmission par le biais des
technologies avec ou sans fil.
3. Protégez les données des titulaires de carte stockées.
4. Chiffrez la transmission des données des titulaires de carte sur les
réseaux ouverts et publics.
Maintenir un programme de gestion des vulnérabilités
Développez et implémentez des procédures de sécurité efficaces pour
toutes les applications de votre infrastructure afin de limiter les
vulnérabilités liées à la sécurité, telles que l'introduction de code
malveillant et les violations de sécurité.
5. Utilisez un logiciel ou des programmes antivirus et mettez-le(s) à jour
régulièrement.
6. Développez et gérez des systèmes et des applications sécurisés.
Implémenter de puissantes mesures de contrôle d'accès
Limitez l'accès aux données des titulaires de carte, définissez les règles de
droits d'accès et les droits d'utilisateur et protégez l'environnement de
données physique contre les violations de sécurité.
7. Limitez l'accès aux données des titulaires de carte suivant les besoins.
8. Attribuez un ID unique à chaque personne qui possède un accès
informatique.
9. Limitez l'accès physique aux données des titulaires de carte.
Surveiller et tester régulièrement les réseaux
Evaluez votre situation actuelle en matière de sécurité et vérifiez que votre
organisation fonctionne de manière sécurisée, qu'elle est protégée contre les
violations de réseau et de sécurité et qu'elle se conforme aux règlements
obligatoires.
10. Surveillez tous les accès aux ressources du réseau et aux données des
titulaires de carte.
11. Testez régulièrement les systèmes et les processus de sécurité.
Gérer une politique de sécurité informatique
Créez, publiez, propagez et gérez une politique de sécurité qui donne à
votre organisation les moyens de se conformer aux règlements de sécurité.
12. Conduisez une politique qui gère la sécurité informatique des employés
et des entrepreneurs.
Exigences PCI DSS
Nous allons à présent examiner chacun de ces douze points et vous fournir des
recommandations pour vous permettre d'appliquer ces principes à votre
environnement de vente.
1. Installez et gérez une configuration de pare-feu pour protéger les données des
v L'objectif est de contrôler le trafic informatique qui entre et sort du réseau.
90
v Utilisez une approche à trois segments :
– Utilisez un pare-feu extérieur pour protéger la zone démilitarisée.
– Placez le serveur Web dans la zone démilitarisée.
– Utilisez un pare-feu interne pour séparer le réseau de production de la zone
démilitarisée.
Séparez votre réseau de production de votre intranet.
2. N'utilisez pas les mots de passe système et autres paramètres de sécurité par
défaut donnés par les fournisseurs.
v Etablissez des accès utilisateur basés sur des règles d'administration et n'utilisez
pas les paramètres par défaut.
v N'exécutez pas les exemples fournis avec les produits dans votre environnement
de production.
Supprimez les outils de développement laissés par le serveur Web, le serveur
d'applications et les programmes d'installation de plug-ins.
v Ne définissez pas d'ID utilisateur et de mot de passe par défaut pour une
ressource.
v
3. Protégez les données des titulaires de carte stockées.
v Stockez le moins possible de données de titulaires de carte.
v Faites en sorte que les données des titulaires de carte soient inexploitables par
les intrus grâce à un stockage et des sauvegardes chiffrés et sécurisés, tout en
garantissant que toutes les données effacées sont irrécupérables.
v N'incluez aucune information sensible dans les données de trace ou d'audit.
4. Chiffrez la transmission des données des titulaires de carte sur les réseaux
ouverts et publics.
v Utilisez le protocole HTTPS dans votre navigateur lorsque vous vous
authentifiez ou que vous effectuez des tâches qui doivent être protégées.
v Configurez le transfert de fichiers sécurisé. L'une des raisons est la suivante : les
agents de noeud extraient les mises à jour de la configuration administrateur en
utilisant un service de transfert de fichier non authentifié. (WebSphere
Application Server)
v Configurez les certificats afin de garantir une validation par certificat
administrateur basée sur le Web en mettant à jour le fichier de clés par défaut.
(WebSphere Application Server)
v Modifiez le fichier de clés par défaut DummyServerKeyFile : créez votre propre
clé privée et votre propre certificat de communication. (WebSphere Application
Server)
v Chiffrez les liens de messagerie par défaut en utilisant le transport
InboundSecureMessaging. (WebSphere Application Server)
v Chiffrez les liens de messagerie WebSphere MQ si WebSphere MQ est utilisé à la
place du fournisseur de messagerie par défaut. (WebSphere Application Server)
v Protégez le connexion entre le serveur d'applications et la base de données afin
de garantir le chiffrement entre le client et la base de données. (WebSphere
Application Server)
5. Utilisez un logiciel ou des programmes antivirus et mettez-le(s) à jour
régulièrement.
Maintenez-le(s) à jour à l'aide des correctifs.
Chapitre 4. Gestion
91
6. Développez et gérez des systèmes et des applications sécurisés.
v Corrigez les vulnérabilités des applications et systèmes nouveaux et existants :
nécessité de s'assurer, grâce à l'évaluation, la surveillance, la gestion, l'analyse et
la génération de rapports sur les vulnérabilités et la sécurité des événements de
votre infrastructure, qu'aucun accès ne peut être obtenu.
v Mettez en place une sécurité globale : IBM WebSphere Application Server ne
propose aucune sécurité par défaut. (WebSphere Application Server)
v Chiffrez la liaision de WebSphere Application Server au protocole LDAP.
v Empêchez le partage des clés privées situées au niveau des systèmes de fichiers.
v Désactivez les ports et les services non utilisés.
v Vérifiez que chaque alias de servlet est sécurisé en le spécifiant dans le fichier
web.xml.
v Ne fournissez pas les servlets par nom de classe. (WebSphere Application
Server)
v Ne placez pas d'informations sensibles à la racine du fichier d'archive Web.
v Définissez un gestionnaire de traitement d'erreurs par défaut pour empêcher les
utilisateurs de voir s'afficher un message d'erreur brut.
v Pensez à désactiver les services de fichiers et la navigation dans les répertoires.
v Activez la sécurité des sessions. (WebSphere Application Server)
v Utilisez la sécurité WebSphere Application Server pour sécuriser les applications.
v Sécurisez chaque couche de l'application, en particulier les EJB.
v Validez toutes les entrées utilisateur pour vous assurer qu'elles ne contiennent
pas de caractères spéciaux pouvant nuire.
v Invalidez les utilisateurs en veille dès que leur session n'est plus utilisée.
v Activez la sécurité Java 2 afin que les spécifications Java 2 Platform Enterprise
Edition soient renforcées pour protéger les API internes de WebSphere
Application Server contre les accès non autorisés. (WebSphere Application
Server)
v Activez la classe MQADMIN en définissant les profils appropriés pour protéger
les ressources à l'aide de commandes. (WebSphere MQ)
v Ne démarrez pas WebSphere MQ en utilisant les droits d'accès de l'utilisateur
root, mais avec l'ID utilisateur d'administration "mqm" de MQSeries sous Unix.
(WebSphere MQ)
v Créez uniquement les objets WebSphere MQ en tant qu'ID utilisateur "mqm"
sous Unix. (WebSphere MQ)
7. Limitez l'accès aux données des titulaires de carte suivant les besoins.
v Limitez l'accès à la file d'attente de messagerie WebSphere MQ par
l'authentification d'utilisateur. (WebSphere Application Server) (WebSphere MQ)
v N'indiquez pas de mots de passe sur la ligne de commande pour les paramètres
des outils et des applications.
v Créez des ID utilisateurs d'administration distincts en fonction du rôle de
l'utilisateur. Par exemple : administrateur, opérateur, surveillant et configurateur.
v Choisissez l'identité de processus appropriée au niveau du système
d'exploitation.
92
v Vérifiez que seuls les utilisateurs habilités ont accès aux éléments DB2 suivants :
– Vues catalogue
– Fonctions de lecteur de journaux
– Réplication des données
– Tables d'exceptions
–
–
–
–
–
Espace table ou base de données de sauvegarde
Traces
Fichiers de vidage
db2dart
db2cat
8. Attribuez un ID unique à chaque personne qui possède un accès
informatique.
v Vérifiez que les actions entreprises sur des données et des systèmes critiques
sont réalisées par des utilisateurs connus et autorisés et qu'on peut assurer leur
suivi.
v Ne définissez pas d'ID utilisateur et de mot de passe par défaut pour une
ressource.
9. Limitez l'accès physique aux données des titulaires de carte.
v Surveillez les personnes pouvant accéder physiquement aux données stockées.
v Protégez l'espace de nom JNDI en limitant l'accès en lecture-écriture.
10. Surveillez tous les accès aux ressources du réseau et aux données des
v Obtenez davantage de visibilité en matière de sécurité de vos données grâce à la
possibilité de surveiller les activités des utilisateurs et de déterminer la cause des
violations de sécurité.
v N'incluez aucune information sensible dans les données de trace ou d'audit.
11. Testez régulièrement les systèmes et les processus de sécurité
Utilisez des méthodes telles que l'analyse de ports, les tests de pénétration et le
piratage éthique pour déterminer si votre réseau et vos systèmes répondent aux
exigences de sécurité.
12. Conduisez une politique qui gère la sécurité informatique des employés et
des prestataires.
Indiquez à vos employés les mesures à respecter en matière de sécurité
informatique.
Solutions de sécurité IBM pour se conformer à la norme PCI DSS
(Payment Card Industry Data Security Standard)
Si votre organisation souhaite se conformer à la norme PCI DSS, IBM vous propose
un portefeuille et une approche complets pour vous aider à atteindre cet objectif.
La solution IBM PCI DSS comprend des services de conseil pour l'analyse des
écarts, la résolution, la validation, les tests et les rapports continus en matière de
conformité, ainsi qu'une gamme de produits qui aident les organisations dans
chaque aspect de la planification, de la gestion et des rapports de conformité en
matière de sécurité. En outre, IBM est l'une des trois sociétés dans le monde à être
Chapitre 4. Gestion
93
certifiée de manière globale pour réaliser les évaluations PCI, l'analyse de réseau
PCI trimestrielle, les analyses des applications de paiement PCI et les services de
réponse aux incidents PCI. Seule IBM possède les solutions pour se conformer aux
12 exigences de la norme PCI DSS.
Pour plus d'informations à propos de la solution IBM PCI, voir :
http://www.ibm.com/software/tivoli/governance/security/pci.html.
94
Chapitre 5. Extension
Cette section décrit les tâches impliquées dans l'extension d'IBM WebSphere
Remote Server.
Extension de la solution
Lorsqu'il est déployé sur un processeur intégré au magasin, IBM WebSphere
Remote Server fournit une pile de logiciels complète qui fait office de base pour les
applications basées serveur qui s'exécutent dans le magasin (ou emplacement de
branche).
La pile de logiciels n'est pas complète tant qu'une ou plusieurs applications ne sont
pas installées et configurées pour s'exécuter sur WebSphere Remote Server.
L'environnement de développement de WebSphere Remote Server fournit les outils
nécessaires à l'extension de WebSphere Remote Server avec vos applications.
Software Assembly Toolkit Developer est l'outil principal permettant de développer
une solution personnalisée qui intègre votre application à la pile de logiciels
WebSphere Remote Server. L'environnement de développement de WebSphere
Remote Server inclut un espace de travail comprenant tous les projets
d'accélérateur de déploiement d'application et les modèles de projets de solution
requis pour développer votre propre solution.
Pour développer une solution personnalisée, vous pouvez réutiliser les projets
d'accélérateur de déploiement d'application existants qui permettent d'installer les
composants et les groupes de correctifs middleware. De plus, vous devez
développer des projets d'accélérateur de déploiement d'application permettant
d'installer et de configurer votre application. L'espace de travail de WebSphere
Remote Server offre des modèles de projets d'accélérateur de déploiement qui
peuvent être copiés et réutilisés dans votre solution avec peu ou sans aucun code à
développer.
Méthode de développement de solutions personnalisées
Il existe deux méthodes principales permettant d'étendre WebSphere Remote
Server en développant des solutions personnalisées.
La première approche convient le mieux aux applications J2EE. L'application Plants
By WebSphere est fournie en tant qu'exemple par le biais d'une collection de
projets d'espace de travail et offre une solution personnalisée comportant des
scripts mais un codage Java limité voire inexistant.
La seconde approche convient mieux aux applications telles que les serveurs
autonomes ou qui comportent un programme d'installation. Cette approche
nécessite en général de développer davantage de code Java. Cependant, l'espace de
travail de WebSphere Remote Server fournit des classes utilitaires qui permettent
d'étendre l'interface de programme d'application fournie par Software Assembly
Toolkit Developer et d'accélérer le développement.
95
Solutions exemples
Les solutions d'exemple fournies avec l'environnement de développement de
WebSphere Remote Server comprennent Trade Performance Benchmark Sample for
IBM WebSphere Application Server (Trade) en tant que modèle d'application.
Dans le contexte des solutions exemples, Trade est divisé en deux projets
d'accélérateur de déploiement d'application. Le premier projet, TradeInstall, copie
les fichiers d'application Trade sur le serveur. Le second projet d'accélérateur de
déploiement d'application, TradeConfig, configure Trade pour qu'il s'exécute sur le
serveur. Cette approche d'installation et de configuration de l'application en deux
phases fournit une flexibilité au client pour déterminer le moment où a lieu la
phase de configuration. L'installation et la configuration peuvent avoir lieu au
même moment lors de l'installation initiale de la solution ou la configuration peut
être réalisée quelque temps après l'installation initiale de la solution.
L'un des avantages de posséder une phase de configuration distincte est que la
configuration peut être répétée, si nécessaire, sans que l'on ait à réinstaller
l'ensemble de la solution. Le report de la configuration présente également des
avantages pour les grands scénarios de déploiement où les serveurs sont
pré-configurés au niveau d'un site central et nécessitent d'être personnalisés une
fois déployés.
En ce qui concerne l'application Trade fournie avec les solutions exemples, la
majeure partie du travail est effectuée lors de la phase de configuration. Pendant la
phase d'installation, le fichier d'archive d'application d'entreprise (EAR) et les
scripts nécessaires pour configurer l'application sont copiés. Pendant la phase de
configuration, une base de données comportant des tables est créée, l'application
est déployée sur WebSphere Application Server, un script permettant de configurer
l'application est exécuté et un servlet est appelé pour remplir la base de données.
Les deux premières étapes de la phase de configuration peuvent faire partie de la
phase d'installation.
Pour suivre l'approche en deux phases permettant d'installer et de configurer votre
application, vous devez créer deux projets d'accélérateur de déploiement
d'application dans Software Assembly Toolkit Developer. Le projet d'accélérateur
de déploiement d'application de la phase de configuration est ajouté en tant que
tâche au projet d'accélérateur de déploiement de solution
WrsApplicationConfigurator. Suite aux instructions permettant de générer la
solution exemple, la solution WrsApplicationConfigurator sera exportée en tant
qu'image du programme de lancement de la solution. Cette image représente à son
tour le contenu du module de prédéploiement du projet d'accélérateur de
déploiement d'application de ConfigWrapper inclus dans la solution exemple. Le
projet d'accélérateur de déploiement d'application de la phase d'installation est
simplement ajouté en tant que tâche à la solution exemple.
Si elle a été conçue pour une approche en deux phases, il est toujours possible
d'installer et de configurer l'application en même temps en plaçant à la fois les
projets d'accélérateur de déploiement d'application de la phase d'installation et de
la phase de configuration dans la solution exemple. Dans ce cas, le projet
d'accélérateur de déploiement d'application ConfigWrapper peut être supprimé de
la solution exemple sans qu'il soit nécessaire de générer et d'exporter la solution
WrsApplicationConfigurator.
96
WebSphere sMash
Le projet d'application IBM WebSphere sMash installe WebSphere sMash et IBM
Reliable Transport Extension for WebSphere sMash.
Lorsque vous installez WebSphere sMash, l'image IBM Reliable Transport
Extension for WebSphere sMash est également ajoutée à l'image WebSphere sMash
dans un sous-répertoire appelé sMashRTE. Vous ne pouvez pas installer WebSphere
sMash sans IBM Reliable Transport Extension for WebSphere sMash, sauf si vous
utilisez pour cela les disques du produit.
Pour plus d'informations sur le mode de vérification de l'installation de WebSphere
sMash, voir «Vérification de WebSphere sMash», à la page 34.
Pour plus d'informations sur l'utilisation d'WebSphere sMash, consultez le centre
de documentation WebSphere sMash.
Génération de la solution exemple
Cette section fournit les instructions permettant de générer les projets de solution
SampleSolutionForWindows et SampleSolutionForLinux.
Génération du modèle
Procédez comme suit pour générer un DVD de la solution exemple.
Procédure
1. Ouvrez Software Assembly Toolkit Developer.
2. Générez la solution WrsApplicationConfiguratorWithDB2 ou
WrsApplicationConfiguratorWithInformix.
a. Dans la fenêtre Software Assembly Toolkit Developer, développez la
catégorie Phase de configuration.
b. Développez la catégorie Projets de solution.
c. Cliquez avec le bouton droit de la souris sur le projet
WrsApplicationConfiguratorWithDB2 ou
d. Sélectionnez Générer une solution.
e. Dans la fenêtre Solution générée avec succès (Solution Generation
Successful), cliquez sur OK.
3. Exportez la solution WrsApplicationConfiguratorWithDB2 ou
a. Cliquez avec le bouton droit de la souris sur le projet
b. Sélectionnez Exporter.
c. Dans la fenêtre Exportation, développez Software Assembly Toolkit.
d. Sélectionnez l'image du programme de lancement Software Assembly
Toolkit Solution et cliquez sur Suivant.
e. Définissez la Taille du support (Mo) sur 650.
f. Dans la zone Exporter les fichiers dans (Export files to), saisissez :
C:\export\WAC
/tmp/export/WAC
97
g. Sous Systèmes d'exploitation, choisissez Windows et Linux.
h. Cliquez sur Suivant.
i. Sélectionnez Ne pas exporter de modules de déploiement (Do not export
any deployment packages).
j. Cliquez sur Suivant.
k. Sélectionnez Langues et cliquez sur Terminer.
l. Cliquez sur Oui à l'invite suivante : Le répertoire cible n'existe pas.
Souhaitez-vous le créer ?.
m. Dans la fenêtre Export de la solution réussi (Solution Export Successful),
répondez à la question en cliquant sur Oui ou sur Non.
4. Générez le module de déploiement ConfigWrapperWithDb2 ou
ConfigWrapperWithInformix.
a.
b.
c.
d.
Développez la catégorie Phase d'installation.
Développez la catégorie Projets d'application.
Développez la catégorie Commun.
Cliquez avec le bouton droit de la souris sur ConfigWrapperWithDb2 ou
ConfigWrapperWithInformix et sélectionnez Générer les modules de
déploiement (Generate Deployment Packages).
e. Dans la fenêtre Spécifier l'emplacement (Specify Location), indiquez :
C:\export\WAC\disk1
/tmp/export/WAC/disk1
Remarque : Il s'agit de l'emplacement de la solution
WrsApplicationConfiguratorWithInformix que vous avez
exportée lors d'une étape précédente en ajoutant le répertoire
disk1.
f. Cliquez sur OK.
g. Dans la fenêtre Module de déploiement généré avec succès (Deployment
Package Generation Successful), cliquez sur OK.
5. Générez le module de déploiement TradeInstall.
Remarque :
v Informix Growth Edition ne prend pas en charge l'application
commerciale.
v was_longSi vous utilisez l'application commerciale sur un poste
de travail dont la langue est l'allemand, vous devez d'abord
mettre à niveau IBM WebSphere Application Server vers la
version 7.0.0.11.
a. Développez la catégorie Phase d'installation.
b. Développez la catégorie Projets d'application.
c. Développez la catégorie Commun.
d. Cliquez avec le bouton droit de la souris sur TradeInstall et sélectionnez
Générer l'application (Generate Application).
e. Cliquez avec le bouton droit de la souris sur TradeInstall et sélectionnez
Générer les modules de déploiement (Generate Deployment Packages).
f. Dans la fenêtre Spécifier l'emplacement (Specify Location), indiquez :
C:\Program Files\IBM\SIF\workspace\wrs71_x64\
TradeInstall\installpackage
98
/opt/IBM/SIF/workspace/wrs71_x64/TradeInstall/
installpackage
g. Cliquez sur OK.
h. Dans la fenêtre Module de déploiement généré avec succès (Deployment
Package Generation Successful), cliquez sur OK.
6. Générez la solution SampleSolutionForWindowsWithDB2 ou
SampleSolutionForWindowsWithInformix, ou la solution
SampleSolutionForLinuxWithDB2 ou SampleSolutionForLinuxWithInformix.
a. Développez la catégorie Phase d'installation.
b. Développez la catégorie Projets de solution.
c. Développez la catégorie Windows ou la catégorie Linux.
d. Cliquez avec le bouton droit de la souris sur le projet de solution.
SampleSolutionForWindowsWithDB2 ou
SampleSolutionForWindowsWithInformix
SampleSolutionForLinuxWithDB2 ou
SampleSolutionForLinuxWithInformix
e. Sélectionnez Générer une solution.
f. Dans la fenêtre Solution générée avec succès (Solution Generation
Successful), cliquez sur OK.
7. Exportez la solution SampleSolutionForWindowsWithDB2 ou
SampleSolutionForWindowsWithInformix ou la solution
SampleSolutionForLinuxWithDB2 ou SampleSolutionForLinuxWithInformix.
a. Cliquez avec le bouton droit de la souris sur le projet de solution.
SampleSolutionForWindowsWithDB2 ou
SampleSolutionForWindowsWithInformix
SampleSolutionForLinuxWithDB2 ou
SampleSolutionForLinuxWithInformix
b. Sélectionnez Exporter....
c. Dans la fenêtre Exportation, développez Software Assembly Toolkit.
d. Sélectionnez l'image du programme de lancement Software Assembly
Toolkit Solution et cliquez sur Suivant.
e. Définissez la Taille du support (Media size) (Mo) sur 650 pour créer un
support CD ou 4482 pour créer un support DVD.
Ce nombre est important uniquement si vous prévoyez réellement de copier
les données sur un support CD ou DVD.
f. Exportez les fichiers dans :
C:\export\SampleSolutionForWindows
/tmp/export/SampleSolutionForWindows
g. Sous Systèmes d'exploitation, sélectionnez Windows ou Linux.
h. Cliquez sur Suivant.
i. Sélectionnez Exporter tous les modules de déploiement (standard) et
cliquez sur Suivant.
j. Cliquez sur Suivant.
k. Sélectionnez Langues et cliquez sur Suivant.
l. Cliquez sur Terminer.
m. Cliquez sur Oui à l'invite : Le répertoire cible n'existe pas.
Souhaitez-vous le créer ?.
99
n. Dans la fenêtre Export de la solution réussi (Solution Export Successful),
répondez à la question en cliquant sur Oui ou sur Non.
Remarque :
Si vous installez la solution d'exemple sur une plateforme
Windows, vous devez confirmer manuellement tous les
messages instantanés du pare-feu Windows pour que
l'installation aboutisse.
v Si vous installez la solution d'exemple en mode automatique
sur une plateforme Windows, vous devez désactiver le pare-feu
Windows avant le lancement de l'installation pour que celle-ci
aboutisse.
v
Que faire ensuite
Modifiez la solution exemple.
Préparation de la solution exemple pour une installation en
mode silencieux
L'installation en mode silencieux est habituellement utilisée pour le déploiement à
distance. Lors d'une installation en mode silencieux, le programme d'installation
récupère les informations de configuration via une interface graphique à partir
d'un fichier et non à partir de l'utilisateur.
Important : Si vous lancez l'installation automatique sur une plateforme Windows,
vous devez désactiver le pare-feu Windows pour que l'installation
aboutisse.
Deux étapes sont nécessaires pour générer une solution dotée d'une installation en
mode silencieux.
1. Création d'un fichier de tâches répertoriant les tâches et les informations du
projet d'application qui seront utilisées lors de l'installation de la solution.
2. Vérification de l'option Exécuter l'installation en mode silencieux (Run
installation silently) lors de l'exportation de la solution.
Les modèles de fichiers de tâches sont fournis avec chacune des solutions
exemples. Les fichiers de tâches se trouvent dans le répertoire tâches, sous les
répertoires du modèle de projet. Le nom du fichier de tâches pour chaque modèle
de projet est taskList.xml.
Les informations relatives aux fichiers de tâches et à l'installation en mode
silencieux sont accessibles à partir du menu Aide d'Software Assembly Toolkit
Developer.
Modification de la solution exemple
Il est recommandé de générer la solution exemple avant d'effectuer une
quelconque modification. Cela vous permettra de vous assurer que
l'environnement de développement et la solution exemple sont installés
correctement. Il est recommandé de démarrer la génération sur des bases solides.
Pour modifier la solution exemple, vous devez comprendre les concepts d'Software
Assembly Toolkit Developer. Software Assembly Toolkit Developer fournit des
aide-mémoire dans le menu Aide. Passez en revue les aide-mémoire suivants :
100
Création d'un projet d'accélérateur de déploiement
Création d'un projet d'accélérateur de déploiement d'application WebSphere
Création d'un projet d'accélérateur de déploiement d'application
Exportation et déploiement d'une image de programme de lancement d'une
solution
v Utilisation de Software Assembly Toolkit Developer
v
v
v
v
Il
v
v
v
v
existe plusieurs manières de modifier la solution exemple. Vous pouvez :
Supprimer le modèle d'application
Supprimer un produit middleware
Ajouter votre propre application/middleware
Fournir davantage d'options de configuration pour les projets d'accélérateur de
déploiement d'application
Pour supprimer le modèle d'application ou le middleware, vous devez ouvrir le
modèle du projet de solution. Dans l'onglet Tâches, supprimez les projets
d'application de la liste des tâches.
Pour ajouter votre propre application ou produit middleware, créez un projet
d'application avec le code source permettant de l'installer. Créez ensuite une tâche
dans le projet de solution qui fait référence au projet d'application que vous avez
créé.
Vous pouvez modifier les options de configuration des projets d'application
existants dans le modèle d'espace de travail. Pour ce faire, ouvrez un projet
d'application et sélectionnez l'onglet Variables. Saisissez les variables pour les
valeurs supplémentaires disponibles dans le fichier de réponses du programme
d'installation de l'application.
Extension de WebSphere Remote Server via un modèle d'application
WebSphere
IBM WebSphere Remote Server inclut un modèle d'application qui offre une
solution plus générique nécessitant un développement de code beaucoup moins
important.
WebSphere Remote Server offre un environnement de développement complet doté
d'outils puissants qui facilitent le développement de solutions intégrées pouvant
être déployées de manière cohérente et aisée. Les premiers de cette série sont les
outils Software Assembly Toolkit qui incluent le plug-in Software Assembly Toolkit
Developer pour Eclipse. En outre, un espace de travail Eclipse complet est fourni
avec tous les projets d'application et de solution nécessaires au développement
d'une solution complète basée sur WebSphere Remote Server.
Trade Performance Benchmark Sample for IBM WebSphere Application Server
(Trade) est fourni en tant que modèle d'application avec l'environnement de
développement de la solution WebSphere Remote Server. L'application est installée
et configurée par deux projets d'application : TradeInstall et TradeConfig. Ces
projets d'application illustrent l'une des approches permettant de déployer et de
configurer une application WebSphere située au sommet de la pile middleware
WebSphere Remote Server. Le projet TradeConfig en particulier, illustre comment
déployer une application J2EE et configurer la base de données DB2 Workgroup
Server Edition à l'aide de scripts et autres codes.
101
Etant donné que les scripts utilisés sont spécifiques à l'application Trade, il est
nécessaire de développer une grande quantité de code et de scripts pour pouvoir
appliquer la même approche à une autre application. WebSphere Remote Server
inclut un modèle d'application qui offre une solution plus générique nécessitant un
développement de code beaucoup plus limité. Cette approche est décrite dans la
présente section. L'espace de travail installé au sein de l'environnement de
développement de la solution WebSphere Remote Server contient plusieurs projets
Software Assembly Toolkit Developer qui illustrent cette technique. Le modèle
d'application est lui-même une version modifiée du modèle d'application J2EE
Plants By WebSphere. Cette application a été modifiée de manière à inclure les
ressources Java Message Service permettant de communiquer avec IBM WebSphere
MQ, ce qui se traduit par un exemple qui utilise l'ensemble de la pile middleware
Description du modèle
La présente section décrit les différents projets qui constituent le modèle et
explique comment s'en servir pour développer votre application.
Présentation du code d'exemple
L'espace de travail comprend les projets ci-dessous qui constituent le modèle :
v Db2Configuration : Projet conçu comme un projet modèle pouvant être copié et
réutilisé au sein de votre solution. Ce projet est conçu pour créer une seule base
de données ainsi que les tables nécessaires et les remplir le cas échéant. Si votre
solution nécessite plusieurs bases de données, vous pouvez utiliser plusieurs
copies de ce projet (renommées, naturellement) dans votre solution. Ce projet est
requis si votre solution emploie une base de données DB2.
v IdsConfiguration : Projet conçu comme un projet modèle pouvant être copié et
réutilisé au sein de votre solution. Ce projet est conçu pour créer une seule base
de données ainsi que les tables nécessaires et les remplir le cas échéant. Si votre
solution nécessite plusieurs bases de données, vous pouvez utiliser plusieurs
copies de ce projet (renommées, naturellement) dans votre solution. Ce projet est
requis si votre solution emploie une base de données Informix Growth Edition.
v MqConfiguration : Autre projet modèle qui peut être copié et réutilisé au sein
de votre solution. Ce projet est conçu pour créer un seul gestionnaire de files
d'attente, tous les canaux nécessaires et les autres objets MQ. Si votre solution
nécessite plusieurs gestionnaires de files d'attente, ce projet peut être copié et
renommé autant de fois que nécessaire. Ce projet est requis si votre solution
emploie WebSphere MQ.
v WasStandaloneProfileConfiguration : Projet modèle pouvant être copié et
réutilisé au sein de votre solution. Il crée un serveur d'applications autonome.
Chaque profil de serveur d'applications autonome inclut un processus de
serveur d'applications server1. Chaque profil définit un serveur d'applications
autonome séparé disposant de sa propre interface d'administration.
v PlantsByWebSphereDeployment : Projet modèle illustrant la manière dont une
application J2EE peut être déployée et configurée dans WebSphere Application
Server. Il s'agit d'un projet WebSphere Application Server généré par Software
Assembly Toolkit Developer à partir d'un déploiement Plants By WebSphere. Ce
projet a été étendu pour fonctionner avec WebSphere Remote Server.
v PlantsByWebSphereSolutionForLinuxWithInformix et
PlantsByWebSphereSolutionForLinuxWithDb2 : ce projet de solution exemple
fournit un exemple complet intégrant tous les modèles de projets ci-dessus et
l'ensemble complet des projets middleware. Ce projet est similaire aux projets
102
SampleSolutionForLinuxWithInformix et SampleSolutionForLinuxWithDB2
également inclus dans l'environnement de développement WebSphere Remote
Server.
v PlantsByWebSphereSolutionForWindowsWithInformix et
PlantsByWebSphereSolutionForWindowsWithDb2 : cette solution exemple est
similaire à PlantsByWebSphereSolutionForLinuxWithInformix et
PlantsByWebSphereSolutionForLinuxWithDb2, mais inclut les projets spécifiques
de Windows pour les composants middleware.
Ces projets sont décrits plus en détail dans les sections suivantes.
Projet Db2Configuration
Le projet Db2Configuration est un projet d'accélérateur de déploiement
d'application Software Assembly Toolkit Developer qui crée une base de données
unique et exécute les scripts requis pour créer les tables et les remplir. Ce projet est
conçu pour proposer un modèle pour les projets personnalisés. Le code Java fourni
avec l'application est généralisé de telle manière qu'il ne nécessite aucune
personnalisation. Les scripts contenus dans l'application effectuent le travail
spécifique à votre solution. L'ensemble du projet d'application peut être copié dans
l'espace de travail et seuls les fichiers script nécessitent d'être modifiés.
Variables
Ce projet présente une seule variable qui est databaseName. Cette variable
représente le nom de la base de données à créer. Vous pouvez la remplacer dans
votre solution par une valeur codée en dur ou la rendre disponible pour l'entrée
utilisateur. Elle peut en général être associée aux variables du projet accélérateur de
déploiement WebSphere pour créer les sources de données nécessaires.
Fichiers script
Deux scripts sont fournis avec ce projet d'application :
v tables.ddl : Fichier DDL qui crée les tables pour la base de données. Ce fichier
est remplacé par votre propre fichier mais doit conserver le même nom.
Généralement, un fichier DDL peut être créé à partir d'une base de données
existante à l'aide de la commande db2look. Pour plus d'informations, consultez
le centre de documentation DB2 à l'adresse : http://publib.boulder.ibm.com/
infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.cmd.doc/doc/
r0002051.html.
v populate.sql : Fichier script qui contient des commandes SQL permettant de
remplir les tables de base de données. Ce fichier est facultatif et les tables de
base de données ne seront pas remplies si ce script n'est pas présent dans le
projet d'application. Si vous fournissez votre propre script, celui-ci doit
conserver le même nom.
Les scripts fournis avec ce projet sont des fichiers exemple utilisés spécialement
pour l'application PlantsByWebSphere et doivent être remplacés par vos propres
scripts.
Projet IdsConfiguration
IdsConfiguration est un projet d'accélérateur de déploiement d'application Software
Assembly Toolkit Developer qui crée une base de données unique et exécute les
scripts requis pour créer les tables et les remplir. Ce projet est conçu pour proposer
103
un modèle pour les projets personnalisés. Le code Java fourni avec l'application est
généralisé de telle manière qu'il ne nécessite aucune personnalisation. Les scripts
contenus dans l'application effectuent le travail spécifique à votre solution.
L'ensemble du projet d'application peut être copié dans l'espace de travail et seuls
les fichiers script nécessitent d'être modifiés.
Variables
Ce projet présente une seule variable qui est databaseName. Cette variable
représente le nom de la base de données à créer. Vous pouvez la remplacer dans
votre solution par une valeur codée en dur ou la rendre disponible pour l'entrée
utilisateur. Elle peut en général être associée aux variables du projet accélérateur de
déploiement WebSphere pour créer les sources de données nécessaires.
Fichiers script
Deux scripts sont fournis avec ce projet d'application :
v tables.sql : Fichier SQL qui crée les tables pour la base de données. Ce fichier
est remplacé par votre propre fichier mais doit conserver le même nom.
v populate.sql : Fichier script qui contient des commandes SQL permettant de
remplir les tables de base de données. Ce fichier est facultatif et les tables de
base de données ne seront pas remplies si ce script n'est pas présent dans le
projet d'application. Si vous fournissez votre propre script, celui-ci doit
conserver le même nom.
Les scripts fournis avec ce projet sont des fichiers exemple utilisés spécialement
pour l'application PlantsByWebSphere et doivent être remplacés par vos propres
scripts.
Projet MqConfiguration
Le projet MqConfiguration est un projet d'accélérateur de déploiement
d'application Software Assembly Toolkit Developer qui créé un seul gestionnaire
de files d'attente pour WebSphere MQ, puis exécute un script MQSC afin de créer
différents objets MQ (files d'attente, canaux, etc.) pour ce gestionnaire. Ce projet est
destiné à être utilisé comme modèle pour les projets personnalisés. Le code Java
fourni avec le projet est générique et ne doit pas être personnalisé. Les scripts
fournis avec le projet effectuent le travail requis par votre solution spécifique.
L'ensemble du projet d'application peut être copié dans l'espace de travail et seuls
les fichiers script nécessitent d'être modifiés.
Variables
Ce projet présente les variables suivantes :
v queueMgrName : Nom du gestionnaire de files d'attente à créer. Ce nom peut
être remplacé au niveau de la solution par une valeur prédéterminée ou être
modifié par l'utilisateur.
v isDefaultQueueMgr : Variable booléenne qui détermine si ce gestionnaire de
files d'attente doit être désigné comme la valeur par défaut du système.
Généralement, elle possède la valeur "true" par défaut, à moins que votre
solution nécessite plusieurs gestionnaires de files d'attente. La valeur de cette
variable doit être déterminée au moment de la phase de conception. Cette
variable ne doit pas être révélée à l'utilisateur qui installe la solution.
v createDeadLetterQueue : Variable booléenne qui détermine si la file d'attente de
rebut doit être créée pour ce gestionnaire de files d'attente. Généralement, elle
104
possède la valeur "true" par défaut, à moins que votre solution nécessite
plusieurs gestionnaires de files d'attente. Cette variable doit également être
définie au niveau de la solution et ne doit pas être révélée à l'utilisateur qui
installe la solution.
v createPubSubQueues : Variable booléenne qui détermine si les files d'attente de
publication/d'abonnement Java Message Service doivent être créées. Si la valeur
est "true", le comportement par défaut consiste à exécuter le fichier exemple
MQJMS_PSQ.mqsc dans le répertoire WebSphere MQ. Toutefois, si un fichier
nommé pubsub.mqsc figure dans le projet d'application, c'est lui qui sera
exécuté. Si la valeur de cette variable est "false", aucun fichier MQSC n'est
exécuté et aucune file d'attente supplémentaire n'est créée. Il s'agit encore d'une
variable qui doit être définie au niveau de la solution et ne doit pas être révélée
à l'utilisateur qui installe la solution.
Fichiers script
Ce projet comprend un fichier script MQSC obligatoire. Un second fichier script
MQSC facultatif peut être fourni afin de proposer un script personnalisé pour les
files d'attente de publication/d'abonnement Java Message Service.
v default.mqsc : Fichier script MQSC par défaut, exécuté après la création du
gestionnaire de files d'attente. Ce fichier script est obligatoire et doit conserver le
nom "default.mqsc". Généralement, ce fichier MQSC peut être généré à partir
d'une installation MQ existante à l'aide de saveqmgr SupportPac. Pour plus
d'informations, voir : http://www.ibm.com/support/
docview.wss?uid=swg24000673.
v pubsub.mqsc : Fichier facultatif qui n'est pas inclus dans l'application par
défaut. Si ce fichier est ajouté au projet d'application et que la valeur de
createPubSubQueues est "true", son script sera exécuté. Cette option a été conçue
pour fournir une alternative à l'exemple de script de publication/d'abonnement
Java Message Service fourni avec WebSphere MQ, le cas échéant.
Le fichier script fourni avec ce projet est un fichier exemple utilisé spécialement
pour l'application PlantsByWebSphere et doit être remplacé par votre propre script.
Projet WasStandaloneProfileConfiguration
Le projet WasStandaloneProfileConfiguration est un projet d'accélérateur de
déploiement d'application Software Assembly Toolkit Developer qui crée un
serveur d'applications autonome. Chaque profil de serveur d'applications
autonome inclut un processus de serveur d'applications server1. Chaque profil
définit un serveur d'applications autonome séparé disposant de sa propre interface
d'administration.
Variables
Ce projet présente les variables suivantes :
v profileName : Nom du profil à créer. Le nom du profil doit être unique pour
cette installation WebSphere Application Server.
v nodeName : Nom de poste pour le serveur d'applications. Le nom de poste doit
être unique dans une cellule.
v enableAdminSecurity : Valeur booléenne que vous pouvez définir afin d'activer
la sécurité administrative. Si cette valeur est définie sur "true", les utilisateurs
105
doivent se connecter pour accéder aux outils d'administration de WebSphere
Application Server. Un nom utilisateur et un mot de passe d'administration sont
requis lorsque cette option est activée.
v wasAdminUser : ID utilisateur permettant d'accéder aux outils d'administration
de WebSphere Application Server. Cette variable est requise si vous utilisez la
sécurité administrative.
v wasAdminPassword : Mot de passe de l'utilisateur d'administration. Cette
variable est requise si vous utilisez la sécurité administrative.
v runAsService : Valeur booléenne que vous pouvez définir pour permettre à
WebSphere Application Server de s'exécuter en tant que service.
Fichiers script
Ce projet inclut deux fichiers script.
v CreateDataSource.py : Crée une source de données JDBC pour votre base de
données DB2 ou Informix Growth Edition.
v enableWASSecurityLocalOS.jacl : Active la sécurité pour WebSphere
Application Server.
v
Projet PlantsByWebSphereDeployment
PlantsByWebSphereDeployment est un projet d'accélérateur de déploiement
d'application WebSphere Software Assembly Toolkit Developer. Ce projet est
généré automatiquement à partir d'un déploiement existant de WebSphere
Application Server à l'aide de l'assistant Nouveau projet d'Software Assembly
Toolkit Developer. Ce projet est étendu via une classe d'accélérateur de
déploiement afin d'utiliser les fonctions exclusives de WebSphere Remote Server.
Ce projet est fourni en tant qu'exemple pour illustrer les éléments de base d'un
projet d'accélérateur de déploiement d'application WebSphere et montrer comment
ces éléments interagissent avec la classe d'accélérateur de déploiement spécifique.
Dans la pratique, vous allez générer votre propre projet en fonction de votre
application WebSphere. Pour plus d'informations sur la manière d'utiliser l'assistant
Projet d'accélérateur de déploiement d'application WebSphere, voir :
http://publib.boulder.ibm.com/infocenter/satinfo/v3r2/topic/com.ibm.sat.doc/
concepts/cerwebap.htm.
Fichiers projet de l'application
Les fichiers suivants représentent le coeur du projet (liste non exhaustive) :
v PlantsByWebSphereEAR-1.1.1.ear : Fichier d'archive J2EE contenant
l'application PlantsByWebSphere. Il est généré automatiquement par l'assistant.
v DeployWebApplications.java : Programme principal qui pilote l'installation en
appelant la commande wsadmin et divers scripts python permettant de déployer
et de configurer l'application. Il s'agit du code standardisé généré par l'assistant.
v DeployWebApplications.py et DeployWebApplicationsProfile.py : Scripts
python exécutés par wsadmin pour déployer le fichier EAR et configurer
l'application. Ces scripts sont générés automatiquement par l'assistant.
v DeployWebApplications.bat : Fichier de commandes simple qui permet
d'appeler la commande wsadmin sur le système d'exploitation Windows. Ce
fichier est fourni par l'assistant.
106
v DeployWebApplications.properties : Fichier de propriétés qui fonctionne
comme le “fichier de réponse” pour l'installation de l'application et est utilisé en
vue de transférer les variables de l'assistant de déploiement vers les codes java
et python.
v WrsDeployWebApplications.java : classe d'accélérateur de déploiement qui est
ajoutée au projet. Cette classe fonctionne comme le programme principal du
projet d'application et étend la classe DeployWebApplications. Cela permet de
modifier les variables transférées à l'application en fonction d'une installation
précédente de WebSphere Remote Server. Cela est particulièrement utile si vous
souhaitez utiliser le modèle de déploiement et de configuration en deux phases
de l'entrepôt de données (comme abordé dans le document référencé ci-dessus)
ou si vous étendez une solution déjà déployée par le biais d'une nouvelle
application. Normalement, ce code est standardisé, mais peut nécessiter quelques
modifications mineures en fonction de votre application.
Variables
Les variables disponibles dans le projet d'accélérateur de déploiement d'application
regroupent en partie les options sélectionnées lorsque l'assistant est lancé dans le
but de créer le projet. Le projet PlantsByWebSphereDeployment contient des
variables issues de la génération d'un projet d'accélérateur de déploiement
d'application WebSphere type. Certaines de ces variables sont transmises comme
arguments de ligne de commande à la classe DeployWebApplications, les unes
sont associées au fichier de propriétés de réponse
DeployWebApplications.properties et d'autres sont remplacées par la classe
d'accélérateur de déploiement WrsDeployWebApplications en fonction des valeurs
obtenues lors d'une installation précédente (ou en cours) d'une solution WebSphere
Remote Server. Ces variables sont abordées plus en détail ci-dessous :
v WAS_HOME_AIX : Variable de chemin pointant sur le répertoire d'installation
de WebSphere Application Server sur la plateforme AIX. Etant donné
qu'actuellement WebSphere Remote Server ne prend pas en charge la plateforme
AIX, cette variable est par défaut une chaîne nulle. Cette variable ne doit pas
être révélée à l'utilisateur qui installe la solution.
v WAS_HOME_LINUX : Variable de chemin qui pointe vers le répertoire
d'installation de WebSphere Application Server sur la plateforme Linux. Cette
variable est remplacée par la classe d'encapsuleur WrsDeployWebApplications
possédant la valeur de la variable installLocation du projet d'application
Was_61013_Lnx. Par conséquent, cette variable ne doit pas être révélée à
l'utilisateur qui installe la solution.
v WAS_HOME_OS400 : Variable de chemin qui pointe vers le répertoire
d'installation de WebSphere Application Server sur la plateforme iSeries. Etant
donné qu'actuellement WebSphere Remote Server ne prend pas en charge la
plateforme iSeries, cette variable est par défaut une chaîne nulle. Cette variable
ne doit pas être révélée à l'utilisateur qui installe la solution.
v WAS_HOME_WINDOWS : Variable de chemin qui pointe vers le répertoire
d'installation de WebSphere Application Server sur la plateforme Windows.
Cette variable est remplacée par la classe d'encapsuleur
WrsDeployWebApplications possédant la valeur de la variable installLocation du
projet d'application Was_61013_Win. Par conséquent, cette variable ne doit pas
v USER : Utilisateur d'administration de WebSphere Application Server. Cette
variable est remplacée par la classe d'encapsuleur WrsDeployWebApplications
possédant la valeur de la variable wasAdminUser du projet d'application
107
v
v
v
v
WasStandaloneProfileConfiguration. Par conséquent, cette variable ne doit pas
PASSWORD : Mot de passe de l'utilisateur d'administration de WebSphere
Application Server. Cette variable est remplacée par la classe d'encapsuleur
WrsDeployWebApplications possédant la valeur de la variable
wasAdminPassword du projet d'application WasStandaloneProfileConfiguration.
Par conséquent, cette variable ne doit pas être révélée à l'utilisateur qui installe
la solution.
databaseName : Nom de la base de données à créer. Cette variable doit être
associée au niveau de la solution à la variable databaseName du projet
d'application Db2Configuration.
dsalias_userId : ID utilisateur de connexion à la base de données correspondant
à l'alias d'authentification dsAlias. Cette variable est remplacée par la classe
d'encapsuleur WrsDeployWebApplications possédant la valeur de la variable
instanceUser des projets d'application Db2_95_Win ou Db2_95_Lnx. Par
conséquent, cette variable ne doit pas être révélée à l'utilisateur qui installe la
solution.
dsalias_password : Mot de passe utilisateur de connexion à la base de données
correspondant à l'alias d'authentification dsAlias. Cette variable est remplacée
par la classe d'encapsuleur WrsDeployWebApplications possédant la valeur de la
variable instancePassword des projets d'application Db2_95_Win ou
Db2_95_Lnx. Par conséquent, cette variable ne doit pas être révélée à l'utilisateur
qui installe la solution.
v queueManagerName : Nom du gestionnaire de files d'attente à créer. Cette
variable doit être associée au niveau de la solution à la variable queueMgrName
du projet d'application MqConfiguration.
Projets PlantsByWebSphereSolutionForLinuxWithInformix,
PlantsByWebSphereSolutionForLinuxWithDb2,
PlantsByWebSphereSolutionForWindowsWithInformix et
PlantsByWebSphereSolutionForWindowsWithDb2
Ces projets d'accélérateur de déploiement de solution, similaires aux projets
SampleSolutionForLinuxWithInformix, SampleSolutionForLinuxWithDB2,
SampleSolutionForWindowsWithInformix et SampleSolutionForWindowsWithDB2,
combinent les projets d'application ci-dessus aux projets d'application middleware
de la plateforme appropriée afin de générer des solutions complètes. Etant donné
que les solutions sont construites de façon similaire, la description suivante
s'applique à tous les projets d'accélérateur de déploiement de solution.
La solution comprend deux tâches. La première tâche de niveau supérieur,
d'installation du middleware de la solution, comprend les sous-tâches nécessaires à
l'installation de la pile de logiciels WebSphere Remote Server comprenant IBM
HTTP Server, WebSphere Application Server, DB2 et WebSphere MQ. La seconde
tâche de niveau supérieur, d'installation et de configuration de l'application,
comprend les projets d'application Db2Configuration, MqConfiguration et
PlantsByWebSphereDeployment en tant que sous-tâches. Toutes les variables de ces
trois projets d'application sont remplacées au niveau de la solution. Le tableau
suivant répertorie les variables et comporte une explication à propos de leur
remplacement.
108
Tableau 8. Variables d'application remplacées au niveau de la solution
Projet d'application
Nom de la variable
Description du remplacement
Db2Configuration
databaseName
Partagé en tant que databaseName
MqConfiguration
queueMgrName
Partagé en tant que queueMgrName
MqConfiguration
isDefaultQueueMgr
Masqué, activé par défaut
MqConfiguration
createDeadLetterQueue
MqConfiguration
createPubSubQueues
PlantsByWebSphereDeployment
WAS_HOME_AIX
Masqué
WAS_HOME_LINUX
Masqué
WAS_HOME_OS400
Masqué
WAS_HOME_WINDOWS
Masqué
databaseName
Partagé en tant que databaseName
queueManagerName
Partagé en tant que queueMgrName
USER
Masqué
PASSWORD
Masqué
dsalias_userId
Masqué
dsalias_password
Masqué
Utilisation de la solution exemple PlantsByWebSphere
Suivez les instructions ci-dessous afin de générer et tester le déploiement du
modèle d'application PlantsByWebSphere pour IBM WebSphere Remote Server.
On suppose que l'environnement de développement WebSphere Remote Server est
installé sur un poste de travail de développement et qu'un serveur de test est
également disponible pour tester le déploiement (il peut également s'agir du poste
de travail de développement). Pour générer et tester la solution, procédez comme
suit :
Procédure
1. Dans Software Assembly Toolkit Developer, cliquez avec le bouton droit de la
souris sur PlantsByWebSphereSolutionForLinuxWithDb2,
PlantsByWebSphereSolutionForLinuxWithInformix,
PlantsByWebSphereSolutionForWindowsWithDb2 ou
PlantsByWebSphereSolutionForWindowsWithInformix, selon la plateforme
cible sur laquelle vous souhaitez tester le déploiement.
2. Dans le menu en incrustation, sélectionnez Générer la solution (Generate
solution).
3. Si vous souhaitez tester le déploiement sur le poste de travail de
développement, procédez comme suit :
a. Cliquez à nouveau avec le bouton droit de la souris sur le même projet de
solution et sélectionnez Tester dans l'assistant de déploiement (Test in
Deployment Wizard) dans le menu.
b. Une fois que l'assistant de déploiement apparaît, suivez les étapes pour
tester le déploiement.
4. Vous pouvez également tester le déploiement sur un autre serveur en
procédant de la manière suivante :
a. Cliquez avec le bouton droit de la souris sur le même projet de solution et
sélectionnez Exporter (Export) dans le menu.
109
b. Lorsque la boîte de dialogue Exporter s'ouvre, sélectionnez Software
Assembly Toolkit → Software Assembly Toolkit Solution Launcher Image
dans la liste des destinations d'exportation, puis cliquez sur Suivant.
c. Spécifiez l'emplacement du répertoire de destination où vous souhaitez
placer l'image et cliquez sur Terminer. L'image du programme de lancement
de la solution peut être copiée sur le serveur de test ou gravée sur un DVD.
L'assistant de déploiement est appelé à l'aide du fichier du programme de
lancement (WindowsSetup.exe ou LinuxSetup, selon la plateforme). Lorsque
l'assistant de déploiement apparaît, suivez les instructions pour tester le
déploiement.
5. Pour tester le déploiement de la solution exemple, saisissez l'adresse suivante
dans un navigateur : http://serveur:9080/PlantsByWebSphere/index.jsp où
serveur correspond au nom d'hôte du serveur sur lequel vous avez déployé la
solution. Vous pouvez à présent parcourir le modèle d'application Plants By
WebSphere.
Développement de votre propre solution
Pour développer votre propre solution à l'aide des techniques décrites dans cette
section, suivez ces instructions de base.
Copie et personnalisation des modèles de projets
Les projets Db2Configuration et MqConfiguration sont prévus pour être utilisés
comme modèles. Copiez les projets complets en leur attribuant un nouveau nom et
remplacez les fichiers script par vos propres fichiers. Copiez uniquement les projets
qui composent votre solution. Par exemple, si votre solution ne nécessite pas IBM
WebSphere MQ, vous n'avez pas besoin du projet MqConfiguration. Vous pouvez
copier ces projets autant de fois que nécessaire pour vous conformer aux exigences
de votre solution. Par exemple, si votre solution nécessite deux bases de données
ou plus, vous pouvez copier les projets Db2Configuration autant de fois que
nécessaire.
Personnalisation du projet Db2Configuration
1. Cliquez avec le bouton droit de la souris sur le projet Db2Configuration dans
Software Assembly Toolkit Developer et sélectionnez Copier dans le menu en
incrustation.
2. Cliquez avec le bouton droit de la souris à n'importe quel endroit de la
sous-fenêtre Navigateur et sélectionnez Coller dans le menu. La boîte de
dialogue Copier un projet apparaît. Saisissez un nouveau nom de projet et
cliquez sur OK. Le projet est copié.
3. A l'aide de la sous-fenêtre Navigateur, développez la vue sous le projet que
vous venez de copier et placez-vous dans le répertoire src|userPrograms. Il
contient deux fichiers script : tables.ddl et populate.sql. Vous devez
remplacer ces fichiers par vos propres scripts, mais il est important que les
nouveaux scripts gardent ces mêmes noms. Il est possible d'éditer ces fichiers
manuellement, mais il existe de meilleures façons de générer ces scripts.
4. Le contenu du fichier tables.ddl peut être généré à partir d'une base de
données existante à l'aide de la commande db2look. Pour plus d'informations,
voir http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/
com.ibm.db2.luw.admin.cmd.doc/doc/r0002051.html.
5. Le fichier script populate.sql peut être supprimé du projet si les tables ne
doivent pas être préremplies avant l'exécution de l'application. Certaines
applications remplissent la base de données au moment de l'exécution, à l'aide
d'un code côté serveur, par exemple, un servlet. Dans ce cas, le fichier
110
populate.sql n'est pas requis. Sinon, ajoutez les instructions INSERT
nécessaires pour remplir les tables, le cas échéant.
Personnalisation du projet IdsConfiguration
1. Cliquez avec le bouton droit de la souris sur le projet IdsConfiguration dans
Software Assembly Toolkit Developer et sélectionnez Copier dans le menu en
incrustation.
vous venez de copier et placez-vous dans le répertoire src|userPrograms où se
trouvent les deux fichiers de script suivants : tables.sql et populate.sql.
Remplacez ces fichiers par vos propres scripts, mais en conservant le nom de
ces fichiers. Il est possible d'éditer ces fichiers manuellement, mais il existe de
meilleures façons de générer ces scripts.
4. Le fichier script populate.sql peut être supprimé du projet si les tables ne
doivent pas être préremplies avant l'exécution de l'application. Certaines
applications remplissent la base de données au moment de l'exécution, à l'aide
d'un code côté serveur, par exemple, un servlet. Dans ce cas, le fichier
populate.sql n'est pas requis. Sinon, ajoutez les instructions INSERT
nécessaires pour remplir les tables, le cas échéant.
Personnalisation du projet MqConfiguration
1. Cliquez avec le bouton droit de la souris sur le projet MqConfiguration dans
Software Assembly Toolkit Developer et sélectionnez Copier dans le menu.
vous venez de copier et placez-vous dans le répertoire src|userPrograms.
Recherchez le fichier script appelé default.mqsc. Remplacez ces fichiers par vos
propres scripts, mais en conservant le nom de ces fichiers. Il est possible
d'éditer ce fichier manuellement, mais il existe de meilleures façons de générer
ce script.
4. Le contenu du fichier default.mqsc peut être codé à la main en utilisant les
commandes MQSC requises pour créer les files d'attente, les canaux et autres
objets nécessaires pour votre solution. Cependant, un jeu de commandes MQSC
peut être généré automatiquement à partir d'une installation WebSphere MQ
existante à l'aide de saveqmgr SupportPac. Pour plus d'informations, voir
http://www.ibm.com/support/docview.wss?uid=swg24000673
5. Par défaut, le modèle de script de publication/d'abonnement Java Message
Service fourni avec WebSphere MQ est exécuté en tant que composant de ce
projet d'application. Si vous voulez exécuter votre propre script dans cette
optique, vous pouvez l'ajouter au projet en lui attribuant le nom pubsub.mqsc.
Par défaut, ce fichier n'existe pas dans le projet.
Création et extension du projet accélérateur de déploiement
WebSphere
L'assistant Projet accélérateur de déploiement WebSphere fournit la méthode la
plus simple pour créer un projet d'application en vue de déployer et de configurer
111
votre application WebSphere. Pour que cet assistant puisse être utilisé, votre
application doit être déployée et configurée sur un serveur accessible sur le réseau
à partir du poste de travail de développement sur lequel Software Assembly
Toolkit Developer est utilisé. La première étape consiste à générer le projet. Le
projet est ensuite étendu pour être utilisé avec IBM WebSphere Remote Server.
Création du projet accélérateur de déploiement WebSphere
Les instructions complètes relatives à l'utilisation de l'assistant Projet accélérateur
de déploiement WebSphere sont disponibles à l'adresse suivante :
http://publib.boulder.ibm.com/infocenter/satinfo/v3r2/topic/com.ibm.sat.doc/
concepts/cerwebap.htm. La procédure suivante offre un aperçu des actions de base
nécessaires pour terminer les tâches de l'assistant et suppose qu'une application
J2EE est utilisée dans ce projet. Certains des panneaux décrits ci-dessous peuvent
différer de ceux que vous rencontrerez car ils dépendent du type d'application et
des caractéristiques de configuration de celle-ci.
1. Dans Software Assembly Toolkit Developer, sélectionnez Fichier → Nouveau →
Projet accélérateur de déploiement WebSphere. L'assistant Projet accélérateur
de déploiement WebSphere s'ouvre.
2. Saisissez un nom de projet et cliquez sur Suivant.
3. Dans le panneau Localisation du profil source, sélectionnez le bouton radio
Répertoire distant et cliquez sur Parcourir. Lorsque la boîte de dialogue
Connexion apparaît, spécifiez l'hôte, le nom d'utilisateur et le mot de passe
nécessaire pour se connecter au serveur où l'application est actuellement
installée. Cliquez sur Connecter. Une boîte de dialogue d'afficheur de fichiers
apparaît. Accédez au répertoire de configuration du profil de WebSphere
Application Server qui exécute l'application et cliquez sur OK. Les
informations de configuration du profil sont alors analysées. Une fois cette
étape terminée, vous pouvez cliquer sur Suivant.
4. Dans la liste, choisissez les applications que vous souhaitez inclure à ce projet.
Cliquez sur Suivant.
5. Dans le panneau Récapitulatif de la configuration, cliquez sur Suivant.
6. Dans le panneau Options générales, choisissez vos options, puis cliquez sur
Suivant.
7. Le panneau suivant demande les noms des utilisateurs ayant un rôle de
sécurité pour l'application. Remplissez les valeurs appropriées et cliquez sur
Suivant.
8. Le panneau suivant demande l'emplacement des fichiers JAR nécessaires pour
“DB2 Universal JDBC Driver Provider (XA)”. Utilisez le bouton Ajouter pour
trouver l'emplacement des fichiers jar appropriés et cliquez sur Suivant.
Remarque : La disponibilité de ce panneau dépend de la configuration des
fournisseurs JDBC pour votre application.
9. Les panneaux restants demandent des données spécifiques à diverses
ressources configurées pour votre application. Ils fournissent généralement des
valeurs par défaut correspondant à la configuration actuelle de votre
application. Si vous souhaitez révéler une ou plusieurs de ces variables pour
qu'elles puissent être spécifiées au moment de l'installation, sélectionnez la
case à cocher Autoriser la modification de cette valeur pendant le
développement (Enable modifying this value during deployment) à côté de
la variable en question. La plupart des variables adoptent les valeurs par
défaut. Les variables que vous êtes susceptible de vouloir modifier peuvent
être le nom de la base de données et le nom du gestionnaire de files d'attente.
112
10. Une fois que vous avez atteint le dernier panneau, cliquez sur Terminer. Le
projet est généré automatiquement pour vous.
Extension du projet accélérateur de déploiement WebSphere
Le projet accélérateur de déploiement WebSphere que vous venez de créer peut
être utilisé directement dans un projet de solution WebSphere Remote Server, en
particulier lorsque vous souhaitez installer et configurer votre solution en une
seule fois. Toutefois, si vous souhaitez suivre le modèle d'installation et de
configuration en deux phases de l'entrepôt de données, vous devez apporter
quelques modifications importantes à ce projet. De la même manière, vous devez
effectuer ces modifications si votre solution est conçue pour déployer votre
application vers des instances WebSphere Remote Server existantes et que le
middleware ne fait pas partie de la solution.
1. Dans la sous-fenêtre Navigateur d'Software Assembly Toolkit Developer,
accédez au sous-répertoire suivant : PlantsByWebSphereDeployment/src/
PlantsByWebSphereDeployment/userPrograms. Recherchez le fichier
WrsDeployWebApplications.java et copiez-le dans le sous-répertoire
userPrograms correspondant de l'espace de travail de votre nouveau projet.
2. Dans Software Assembly Toolkit Developer, ouvrez le fichier application.axml
correspondant au nouveau projet. A partir de l'onglet Programmes, sélectionnez
l'onglet Programme principal. Donnez au programme la valeur
WrsDeployWebApplications. Dans la zone de liste Arguments, supprimez tous
les arguments en les sélectionnant à tour de rôle et en cliquant sur Supprimer.
3. Enregistrez les modifications dans le fichier application.axml.
4. La classe WrsDeployWebApplications recherche en boucle la classe
DeployWebApplications par défaut et autorise la substitution de certaines
valeurs variables par les valeurs récupérées dans le fichier de métadonnées
WebSphere Remote Server. (Il s'agit de valeurs variables et d'autres
métadonnées système créées pendant l'installation initiale de WebSphere
Remote Server.)
Remarque : Cette classe doit gérer les variables les plus importantes et ne doit
pas nécessiter de modifications dans la plupart des instances.
Toutefois, il est important de réviser le code pour comprendre le
fonctionnement. Cela vous permettra de le modifier le cas échéant.
Création de la solution
Le projet de solution consiste à combiner tous les projets d'application en une seule
solution unifiée. Une solution WebSphere Remote Server complète comprend
l'ensemble des projets d'application middleware. Le tableau suivant répertorie les
différents projets d'application pouvant être inclus pour chaque plateforme. Vous
pouvez supprimer de votre solution les projets d'application figurant dans cette
liste, mais l'ordre dans lequel ils apparaissent doit être conservé.
Tableau 9. Projets d'application WebSphere Remote Server (pour solutions 32 bits)
Nom de projet Linux
Nom de projet Windows
Commentaires
IrssBase_711_Lnx
IrssBase_711_Win
Code de base de WebSphere
Remote Server. Requis.
Db2_972_Lnx ou
Informix_1150_Lnx
Db2_972_Win ou
Informix_1150_Win
DB2 Workgroup Server
Edition ou Informix Growth
Edition
Mq_701_Lnx
Mq_701_Win
WebSphere MQ
113
Tableau 9. Projets d'application WebSphere Remote Server (pour solutions 32 bits) (suite)
Nom de projet Linux
Commentaires
Mq_701Fp2_Lnx
Mq_701Fp2_Win
WebSphere MQ
Was_7009_Lnx
Was_7009_Win
WebSphere Application
Server Network Deployment
WasStandaloneProfile
Configuration
Configuration
Profil WebSphere Application
Server
Ihs_70_Lnx
Ihs_70_Win
IBM HTTP Server
WasUpdateInstaller_70_Lnx
WasUpdateInstaller_70_Win
Server Update Installer
Ihs_70Fp9_Lnx
Ihs_70Fp9_Win
Groupe de correctifs IBM
HTTP Server
Smash_1115_Lnx
Smash_1115_Win
WebSphere sMash
ConfigWrapperWithDb2 ou
ConfigWrapperWithInformix
Configurateur d'application
Tableau 10. Projets d'application WebSphere Remote Server (pour solutions 64 bits)
Nom de projet Linux
Commentaires
IrssBase_711_Lnx
IrssBase_711_Win
Code de base de WebSphere
Remote Server. Requis.
Db2_972_Lnx_x64 ou
Informix_1150_Lnx_x64
Db2_972_Win_x64 ou
Informix_1150_Win_x64
DB2 Workgroup Server
Edition ou Informix Growth
Edition
Mq_701_Lnx_x64
Mq_701_Win_x64
WebSphere MQ
Mq_701Fp2_Lnx_x64
Mq_701Fp2_Win_x64
WebSphere MQ
Was_7009_Lnx_x64
Was_7009_Win_x64
Server Network Deployment
Configuration
Configuration
Profil WebSphere Application
Server
Ihs_70_Lnx_x64
Ihs_70_Win_x64
IBM HTTP Server
WasUpdateInstaller_70_Lnx
_x64
WasUpdateInstaller_70_Win
_x64
Server Update Installer
Ihs_70Fp9_Lnx_x64
Ihs_70Fp9_Win_x64
Groupe de correctifs IBM
HTTP Server
Smash_1115_Lnx
Smash_1115_Win
WebSphere sMash
Configurateur d'application
En théorie, tous les projets d'application middleware sont facultatifs ; mais en
pratique, WebSphere Remote Server et DB2 sont la plupart du temps requis,
contrairement à IBM WebSphere MQ et IBM HTTP Server. Cela dépend des
exigences de votre application.
En plus des projets répertoriés ci-dessus, vous devez ajouter le projet
Db2Configuration ou sa copie, le projet MqConfiguration ou sa copie et le projet
accélérateur de déploiement WebSphere créé à la section «Création et extension du
projet accélérateur de déploiement WebSphere», à la page 111.
114
Les instructions suivantes exposent les étapes nécessaires pour créer un projet de
solution similaire à PlantsByWebSphereForLinux ou
PlantsByWebSphereForWindows mais comprenant vos propres projets
d'application.
1. Dans le menu Fichier, sélectionnez Nouveau → Projet de solution. L'assistant
Nouveau projet apparaît.
2. Dans le premier panneau, spécifiez le nom du projet. Choisissez un nom
significatif. Si vous projetez de développer des solutions pour les deux
plateformes de systèmes d'exploitation prises en charge par WebSphere
Remote Server (Linux et Windows), vous pouvez, si vous le souhaitez, inclure
le nom de la plateforme dans le nom du projet. Cliquez sur Suivant.
3. Dans le panneau suivant, spécifiez l'ID et le titre de la solution, selon le cas.
Cliquez sur Terminer. Le projet de la solution est créé. Pour ajouter des
projets d'application à un projet de solution, vous devez d'abord créer des
tâches. Pour cet exemple, vous pouvez créer deux tâches : une pour installer
l'ensemble des middleware WebSphere Remote Server et l'autre pour déployer
et configurer votre application.
4. Basculez vers l'onglet Tâches. A côté de la zone de liste Tâches de la solution,
cliquez sur Ajouter. Lorsque l'assistant Ajouter une tâche apparaît,
sélectionnez le bouton radio Créer une tâche d'installation vide (Create an
empty install task) et cliquez sur Suivant.
5. Saisissez une valeur dans la zone Description de la tâche et cliquez sur
Terminer.
6. Pour ajouter des projets d'application à cette tâche, cliquez sur Ajouter.
Lorsque l'assistant Ajouter apparaît, laissez le bouton radio Ajouter des
applications activé et cliquez sur Suivant.
7. Dans la zone de liste Applications, sélectionnez tous les projets d'application
pour les composants middleware. Consultez les tableaux ci-dessus pour
sélectionner les projets appropriés pour votre plateforme. Une fois terminé,
cliquez sur Terminer.
8. Réorganisez les applications pour qu'elles correspondent à l'ordre des projets
pour les solutions 32 bits (voir tableau 9, à la page 113) ou 64 bits (voir
tableau 10, à la page 114). Sélectionnez une application dans la liste et utilisez
les boutons Haut et Bas pour modifier l'ordre. Recommencez cette étape
jusqu'à ce que l'ordre soit correct.
9. Créez une deuxième tâche pour déployer et configurer votre application en
répétant les étapes 4 et 5.
10. Pour ajouter des projets d'application à cette deuxième tâche, cliquez sur
Ajouter. Lorsque l'assistant Ajouter apparaît, laissez le bouton radio Ajouter
des applications activé et cliquez sur Suivant.
11. Dans la zone de liste Applications, sélectionnez uniquement les projets
d'application que vous avez créés dans les sections ci-dessus. Une fois terminé,
cliquez sur Terminer.
12. Réorganisez les applications de manière à ce que le projet accélérateur de
déploiement WebSphere figure à la fin de la liste. La technique de
réorganisation des applications est identique à celle décrite dans l'étape 8
ci-dessus.
13. Ecrasez les variables. Remplacez les variables d'application (voir tableau 9, à la
page 113 ou tableau 10, à la page 114 ci-dessus). La plupart doivent être
masquées. Certaines doivent être partagées. Pour écraser une variable
d'application, choisissez une application dans la zone de liste Tâches de la
solution, puis cliquez sur Ajouter à droite de la zone de liste Variables
d'application remplacées (Overridden application variables). Un assistant
115
apparaît. Sélectionnez les variables dans la liste. Les pages restantes de
l'assistant vous permettent de spécifier la manière dont chaque variable sera
remplacée (masquée, partagée en tant que, etc.).
14. Générez et testez la solution en suivant les étapes présentées dans la section
«Utilisation de la solution exemple PlantsByWebSphere», à la page 109.
Utilisation de WrsApplicationConfigurator
Les instructions ci-dessus illustrent la façon dont votre application WebSphere peut
être déployée et configurée en tant que tâche séparée d'un projet de solution
unique. Les deux tâches peuvent être exécutées simultanément à partir de
l'assistant de déploiement ou lors d'appels distincts de l'assistant de déploiement,
sous réserve que l'image du programme de lancement de la solution soit toujours
disponible sur la machine cible. Conçu de telle manière, ce projet de solution peut
encore être utilisé dans le modèle d'installation et de configuration en deux phases
de l'entrepôt de données. Ce modèle est traité dans le document sur WebSphere
Remote Server version 6.2 intitulé Deploying WebSphere Remote Server à l'adresse
suivante : http://www.ibm.com/support/docview.wss?rs=2193&context=SSUNCX
&dc=DA480&uid=swg27012849&loc=en_US&cs=utf-8&lang=en.
Remarque : Les instructions du document référencé ci-dessus ont été testées
uniquement avec WebSphere Remote Server version 6.2. Cependant,
vous pouvez l'utiliser comme source d'information.
Dans le document sur WebSphere Remote Server version 6.2, la phase de
configuration a été conçue comme un projet de solution secondaire distinct,
WrsApplicationConfigurator, encapsulé par la suite dans un projet d'application,
ConfigWrapper, puis inclus dans le projet de solution principal. Le projet
d'application ConfigWrapper emploie la sortie de l'image du programme de
lancement de la solution de WrsApplicationConfigurator comme entrée pour créer
son module de déploiement.
Les techniques décrites dans le document sur WebSphere Remote Server version
6.2 peuvent également être utilisées avec le modèle WrsApplicationConfigurator/
ConfigWrapper. Les instructions ci-dessous fournissent un bref aperçu des
différences requises :
1. Ajoutez les projets d'application créés dans les sections «Copie et
personnalisation des modèles de projets», à la page 110 et «Création et
extension du projet accélérateur de déploiement WebSphere», à la page 111 au
projet de solution WrsApplicationConfigurator.
2. Générez la solution et exportez l'image du programme de lancement de la
solution de WrsApplicationConfigurator.
3. Générez le module de déploiement du projet d'application ConfigWrapper.
Vérifiez que le répertoire source pointe vers le répertoire d'exportation de
l'image du programme de lancement de la solution de l'étape précédente.
4. Incluez le projet d'application ConfigWrapper dans votre projet de solution
Création d'une application
Dans cette approche, on suppose que vous ne possédez pas d'application
WebSphere pouvant être encapsulée avec un projet accélérateur de déploiement
WebSphere. Dans ce cas, on considère que vous créez un projet d'application à
partir de zéro. La création d'un projet d'application implique la définition de
116
variables, le mappage de variables en propriétés dans un fichier de réponses et
l'écriture du code requis pour appeler le programme d'installation de votre
application.
IBM Software Assembly Toolkit fournit une interface de programme d'application
(API) complète en vue de faciliter le développement du code Java requis pour
gérer l'installation. L'espace de travail d'IBM WebSphere Remote Server étend cette
interface de programme d'application par le biais de classes de routine de test qui
rationalisent le flux de travaux pré- et post-installation ainsi qu'un jeu de classes
utilitaires qui fournissent une variété de fonctions utiles.
Interface de programme d'application de routine de test
Les classes suivantes étendent les classes SupportBase à partir de l'interface de
programme d'application Software Assembly Toolkit :
v com.ibm.wrs.solution.utils.SoftwareWindowsHarness
v com.ibm.wrs.solution.utils.SoftwareLinuxHarness
v com.ibm.wrs.solution.utils.SoftwareConfigHarness
Les classes de routine de test logicielles divisent le processus d'installation en trois
étapes simples : preInstall, doInstall et postInstall. Les méthodes preInstall et
postInstall doivent être remplacées pour fournir la fonction dont vous avez besoin,
mais offrent un comportement par défaut convenable lorsqu'aucun travail
spécifique n'est requis. La méthode doInstall exécute la commande d'installation de
votre application. Le travail fastidieux d'interprétation des codes retour et des
messages est réalisé par la classe de base de la méthode d'installation. En général,
il ne sera pas nécessaire de substituer cette méthode.
La classe SoftwareConfigHarness offre un processus similaire en trois étapes :
méthodes preConfigure, doConfigure et postConfigure. Comme avec les classes de
routine de test logicielles, vous n'avez besoin d'écrire que le code correspondant à
ces trois étapes. La classe de base gère les codes retour, etc.
Vous n'êtes pas obligé d'utiliser ces classes. L'extension est possible à partir des
classes SupportWindowsBase et SupportLinuxBase fournies par SAT. Mais les
classes de routine de test simplifient votre développement.
Les classes de routine de test fournissent une autre fonction importante qui permet
de mettre à jour le fichier de métadonnées WebSphere Remote Server décrit
ci-après.
Fichier de métadonnées WebSphere Remote Server
Le fichier de métadonnées WebSphere Remote Server est un référentiel des
informations de configuration du système. Il s'agit, plus précisément, d'un fichier
XML stocké à l'emplacement SIF_HOME/solution/WRSMetadata.xml. Ce fichier de
métadonnées stocke les informations de configuration concernant chacun des
composants middleware, notamment l'emplacement d'installation, les valeurs des
paramètres d'installation et les méthodes permettant de démarrer, d'arrêter et de
surveiller le composant. Ces données sont utilisées pour le démarrage et l'arrêt de
la pile complète de logiciels.
Les métadonnées sont composées de cinq éléments XML principaux. L'élément de
solution représente l'ensemble de la solution du système. Par défaut, il possède
l'attribut de nom "WRS". Les éléments d'application représentent des composants
117
de logiciel simples et sont nommés en conséquence : "WAS," "DB2," etc. Ces
éléments sont toujours des enfants d'un élément de solution. Les éléments de
sous-composant représentent une entité principale dans un composant logiciel,
comme par exemple un profil IBM WebSphere Application Server. Ces éléments
sont toujours des enfants des éléments d'application. Les éléments de données
d'identification représentent les noms et les mots de passe des utilisateurs dans le
système. Ces éléments sont considérés comme des éléments globaux pour le
système et existent au même niveau que l'élément de solution. Tous les autres
éléments du fichier de métadonnées (à l'exception de la racine) représentent les
"propriétés" de l'élément parent.
La plupart des données qui apparaissent dans le fichier de métadonnées
WebSphere Remote Server proviennent directement des variables définies dans le
projet d'application. Cependant, certaines informations telles que les commandes
de départ/arrêt ou de désinstallation ne doivent pas être demandées à vos
utilisateurs d'application. Vous devez inclure ces informations supplémentaires
dans le fichier de métadonnées via une interface de programme d'application
adaptée. Il existe cependant une méthode plus simple qui permet d'éviter le
développement de code.
Les classes de routine de test logicielles décrites précédemment offrent une autre
fonction importante - lorsque l'installation est réussie, un "fragment" XML est
fusionné avec le fichier de métadonnées WebSphere Remote Server. Le fragment
XML est un fichier nommé metadata.xml qui existe dans le projet d'application. Le
fichier metadata.xml ressemble à un sous-ensemble du fichier de métadonnées
complet doté des éléments décrits ci-dessus. L'inclusion d'un fichier metadata.xml
dans votre projet et l'extension de votre classe principale à partir de l'une des
classes de routine de test logicielles entraîne la fusion du fichier de fragment de
métadonnées dans un fichier de métadonnées WebSphere Remote Server au
moment de l'installation.
Reportez-vous aux projets d'application dans l'espace de travail pour obtenir des
exemples du fichier metadata.xml.
WebSphere Remote Server stocke des mots de passe codés pour certains des
produits logiciels IBM dans le fichier SIF_HOME/solution/WRSMetadata.xml. Le
codage et le chiffrement des mots de passe empêche de voir les mots de passe.
Cependant, le codage ne peut pas garantir une protection totale des mots de passe.
La sécurité native constitue le principal mécanisme de protection des mots de
passe utilisé dans les fichiers de configuration et de propriétés WebSphere
Application Server. Les liens suivants sont fournis pour vous aider à configurer des
droits d'accès aux fichiers pour chaque système d'exploitation :
v Windows 2008 Server: http://msdn.microsoft.com/en-us/magazine/
cc982153.aspx
v Windows 2003 Server: http://support.microsoft.com/kb/325361
v Windows XP : http://support.microsoft.com/default.aspx/kb/308419
v SUSE Linux Enterprise Server : http://www.novell.com/documentation/sled10/
sled_deployment_sp2/index.html?page=/documentation/sled10/
sled_deployment_sp2/data/sect1_chapter_sled_deployment_sp2.html
v Red Hat Enterprise Linux : http://www.redhat.com/docs/manuals/linux/RHL9-Manual/getting-started-guide/s1-navigating-ownership.html
118
Préparation du déploiement à distance via Tivoli Provisioning Manager
La présente section décrit une stratégie de haut niveau pour utiliser IBM Tivoli
Provisioning Manager afin d'installer des solutions à distance via IBM WebSphere
Remote Server.
Dans les versions précédentes de WebSphere Remote Server, les fichiers de
définition de progiciels Tivoli individuels (appelés fichiers SPD) étaient fournis
pour chaque produit middleware. Vous étiez obligé d'installer les accélérateurs de
gestion des systèmes qui contenaient des fichiers SPD et des images disque de
produits middleware et des scripts d'installation. Cela vous permettait d'installer
les middleware IBM sur des machines distantes, un seul produit à la fois.
WebSphere Remote Server adopte une nouvelle approche d'installation de type
solution plutôt qu'une approche basée sur des produits individuels. WebSphere
Remote Server ne fournit plus les fichiers de modules individuels des produits
middleware. Il fournit désormais des fichiers SPD pour des solutions Windows et
Linux complètes. Une définition de progiciel avec une image CD ou DVD de la
solution peuvent être utilisées pour créer un bloc de progiciel Tivoli (appelé fichier
SPB). Le fichier SPB peut être importé dans le catalogue des logiciels sur le serveur
Tivoli Provisioning Manager. La solution est ensuite prête à être distribuée aux ISP
distants.
Les fichiers SPD fournis par WebSphere Remote Server associés à votre solution
doivent être intégrés à des fichiers SPB. Ces derniers contiennent la définition des
modules ainsi que l'image de support de la solution. Pour créer les fichiers SPB,
vous avez besoin de l'éditeur de progiciels Tivoli, qui est un composant de Tivoli
Notez que trois fichiers SPD sont fournis pour chacune des solutions d'exemple en
raison de la taille des fichiers SPB, limitée à 2 Go. Deux des fichiers SPD
permettent d'installer les images de support sur le processeur ISP. Le troisième
fichier SPD utilise les images de support pour installer la solution actuelle. Si la
taille de votre solution est inférieure à 2 Go, vous n'avez besoin que d'un seul
fichier SPD pour copier les fichiers et effectuer l'installation.
Voici la procédure de haut niveau de déploiement avec Tivoli Provisioning
Manager :
v Installer l'environnement de développement de la solution WebSphere Remote
Server.
v Installer et configurer l'éditeur de progiciels Tivoli (SPE).
v Générer la solution d'exemple ou une solution de votre choix. Assurez-vous
d'exporter la solution en mode silencieux. Voir Préparation de la solution pour une
installation en mode silencieux ci-dessus.
v
v
v
v
v
Créer un fichier SPB et le copier dans la machine Tivoli Provisioning Manager.
Importer dans le catalogue des logiciels.
Publier sur le serveur dépôt.
Transmettre au processeur ISP.
Installer sur le processeur ISP.
119
Création des fichiers SPB
Avant de créer les fichiers SPD, vous devez générer des images de support de
votre solution. Pour installer la solution d'exemple, vous pouvez, si vous le
souhaitez, utiliser les fichiers SPD fournis. Voir la section Génération de la solution
d'exemple.
Vous devez également installer l'éditeur de progiciels Tivoli et le configurer pour
qu'il communique avec votre serveur Tivoli Provisioning Manager. Avant de
procéder à cette étape, consultez le document Gestion des progiciels dans l'éditeur
de progiciels dans le centre de documentation IBM Tivoli Provisioning Manager
Centre de documentation.
Les fichiers SPD d'exemple sont installés dans le répertoire sifDir/packages lors de
l'installation de WebSphere Remote Server. Les fichiers SPD d'exemple contiennent
des références à des répertoires qui doivent contenir les images de support de
votre projet de solution. Par exemple, le fichier
SampleSolutionForWindowsPart1.spd contient des références qui renvoient aux
répertoires C:\export\SampleSolutionForWindows\disk1 et disk2. Ces répertoires
ne sont pas installés par WebSphere Remote Server. Ils sont créés lorsque vous
utilisez le composant Software Assembly Toolkit Developer d'IBM Software
Assembly Toolkit pour exporter votre solution sur le disque. Vous pouvez modifier
l'emplacement des répertoires dans les fichiers SPD. Assurez-vous simplement que
les emplacements des répertoires dans ces fichiers correspondent aux
emplacements actuels des images de support sur votre disque dur.
Remarque : Il existe actuellement une limite de taille pour les fichiers SPB. Leur
taille ne peut pas dépasser 2 Go. Etant donné que la taille de la
solution d'exemple dépasse 2 Go, la solution doit être divisée en
plusieurs fichiers SPB. Trois fichiers SPD sont fournis pour chacune
des solutions d'exemple.
Windows:
v SampleSolutionForWindows.spd
v SampleSolutionForWindowsCd1and2.spd
v SampleSolutionForWindowsCd3and4.spd
Linux:
v SampleSolutionForLinux.spd
v SampleSolutionForLinuxCd1and2.spd
v SampleSolutionForLinuxCd3and4.spd
Les fichiers SPB peuvent être créés à l'aide de l'éditeur de progiciels. Ouvrez les
fichiers SPD dans l'éditeur de progiciels, puis sauvegardez-les avec l'extension .spb.
Une fois cette opération effectuée, l'éditeur génère les fichiers SPB. Si vous avez
configuré l'éditeur de progiciels comme décrit dans le centre de documentation
IBM Tivoli Provisioning Manager Centre de documentation, vous pouvez
enregistrer le fichier SPB directement dans le référentiel de fichiers du serveur
Tivoli Provisioning Manager. Sinon, vous pouvez enregistrer les fichiers SPB dans
le système de fichiers local, puis importer les fichiers SPB dans le catalogue des
logiciels à l'aide de Tivoli Provisioning Manager.
120
Configuration de l'éditeur de progiciels
Remarque : Pour plus d'informations sur la configuration de l'éditeur de
progiciels, consultez la page Démarrage et configuration de l'éditeur
de progiciels dans le centre de documentation IBM Tivoli Provisioning
Manager Centre de documentation.
Avant de démarrer l'éditeur de progiciels via Java Web Start, procédez comme
suit :
v Démarrez l'application Java Web Start à l'aide du plugin IBM JRE 1.5. La fenêtre
du gestionnaire d'application Java Web Start s'affiche. Sur les systèmes UNIX,
démarrez Java Web Start à l'aide de la commande javaws.
v Dans la zone d'emplacement, définissez l'adresse URL suivante :
https://<nom_hôte>:<numéro_port>/SPEWebStart/spe.jnlp où, <nom_hôte>
représente le nom d'hôte du serveur Web et <numéro_port> représente le numéro
de port du serveur Web. Le composant éditeur de progiciels est téléchargé et
s'affiche automatiquement.
v Lancez le composant éditeur de progiciels en cliquant sur Démarrer.
Contrôle des applications WebSphere Remote Server et ISP
L'utilitaire de processeur de commandes IBM WebSphere Remote Server est un
fichier classe contenu dans le fichier SifUtility.jar, lequel se trouve dans le
répertoire SIF_HOME/utility.
Le processeur de commandes WebSphere Remote Server exécute des commandes
au niveau du système d'exploitation définies dans le fichier de métadonnées
WebSphere Remote Server. Les commandes sont appelées en transmettant les
paramètres au processeur de commandes WebSphere Remote Server, ce qui permet
au processeur de trouver les commandes dans le fichier de métadonnées
WebSphere Remote Server et de les exécuter.
WebSphere Remote Server comprend des scripts permettant de contrôler les
applications qui constituent la solution WebSphere Remote Server.
Voici, de nouveau, la syntaxe appropriée pour ces scripts :
où les paramètres suivants sont facultatifs :
v silent : Les informations relatives à l'exécution de la commande n'apparaissent
pas à l'écran.
v log : Les informations relatives à l'exécution de la commande sont imprimées
v verbose : Les informations détaillées sur l'exécution de la commande de
121
Les scripts précédemment mentionnés fonctionnent uniquement avec la solution
WebSphere Remote Server et avec les applications et sous-composants faisant
partie de la solution WebSphere Remote Server. Cependant, vous pouvez modifier
les paramètres de commande par défaut pour les applications et les
sous-composants situés dans le fichier de métadonnées WebSphere Remote Server,
ou ajouter de nouvelles solutions, applications et de nouveaux sous-composants
non inclus dans WebSphere Remote Server. Le processeur de commandes
WebSphere Remote Server est extensible, ce qui permet de contrôler ces
modifications et les applications futures. La section suivante explique comment
utiliser le processeur de commandes WebSphere Remote Server pour ces scénarios.
Modification ou ajout de nouvelles applications ou de
sous-composants à la solution WebSphere Remote Server
La manière la plus simple de modifier ou d'ajouter de nouvelles applications ou
sous-composants à la solution WebSphere Remote Server est d'utiliser les scripts
existants fournis avec la solution WebSphere Remote Server pour constituer une
base de départ.
Exemple : Ajout d'une nouvelle application à la solution WebSphere Remote
Server
Cette application possédera une fonction de départ et d'arrêt.
1. Ajoutez les informations de l'application au fichier de métadonnées de la
solution WebSphere Remote Server. Dans cet exemple, on ajoute les
informations de départ et d'arrêt à l'application TestApplication :
<solution name="WRS">
<application name="TestApplication">
<start>wrs_TestApplication_start.bat </start>
<stop>wrs_TestApplication_stop.bat </stop>
</application>
<solution>
2. Si les commandes souhaitées sont des appels de script, créez les scripts
nécessaires. Dans cet exemple, les commandes seront des appels aux scripts
wrs_TestApplication_start.bat et wrs_TestApplication_stop.bat. Voici le
script wrs_TestApplication_start.bat résultant de l'utilisation du fichier
wrs_DB2_start.bat en tant que modèle (fichier installé si DB2 l'est également) :
@echo off
set SUCCESS=0
set FAILURE=1
set UNKNOWN=2
@CALL "%SIF_HOME%\bin\SifSetupCmdLine.bat"
set BINDIR"%SIF_HOME%\bin
set TEMPLOG="%SIF_HOME%\logs\%~nx0.log"
set rc=%UNKNOWN%
@call "%BINDIR%\TestApplication.exe start" > %TEMPLOG% 2>&1
if "%ERRORLEVEL%" EQU "1" (
@REM Couldn’t start, but may already be started
goto checkifstarted
)
@REM Command succeeded
set rc=%SUCCESS%
goto end
)
:checkifstarted
%JAVACMD% -cp %CP% com.ibm.sif.utility.FindString %TEMPLOG% "Already started"
set rc=%SUCCESS%
goto end
)
122
set rc=%FAILURE%
goto end
)
:end
type %TEMPLOG%
del /s /q %TEMPLOG%
exit /b %rc%
Pour ce script d'exemple, l'algorithme suivant s'affiche :
v Initialisez les variables locales nécessaires.
v Appelez le fichier SifSetupCmdLine.bat ou SifSetupCmdLine.sh. Le script
SifSetupCmdLine doit toujours être appelé afin que les variables
d'environnement nécessaires pour ce dernier soient initialisées (par exemple,
la commande permettant d'appeler Java ou de paramétrer le chemin d'accès
aux classes Java).
v Appelez la commande pour l'application. Dans cet exemple, la commande est
TestApplication.exe start
v Evaluez le résultat de l'appel de la commande. Dans cet exemple, si
TestApplication a été démarré correctement, le code retour est défini
sur %SUCCESS%. Cependant, dans cet exemple, si le démarrage de
TestApplication ne renvoie pas la valeur 0, il se peut que l'application soit
déjà démarrée ; dans ce cas, le texte Already started s'affiche à l'écran. La
fenêtre de résultat est inscrite dans le fichier journal nommé, situé
dans %TEMPLOG%. Vous pouvez rechercher dans ce fichier le texte Already
started à l'aide de com.ibm.sif.utility.FindString, comme illustré ci-dessus. Si
le texte recherché existe, le code retour de l'application est défini
sur %SUCCESS%, sinon il est défini sur %FAILURE%.
v Affichez le résultat de l'appel de la commande.
v Supprimez le fichier temporaire contenant le résultat de la commande.
v Renvoyez le code retour de l'appel de la commande.
3. Appelez le processeur de commandes WebSphere Remote Server pour démarrer
TestApplication. Utilisez, si vous le souhaitez, les paramètres facultatifs
suivants : wrsstart TestApplication [-silent -log -verbose]
Ajout de nouvelles applications ou de sous-composants à des
solutions autres que la solution WebSphere Remote Server
La manière la plus simple d'ajouter de nouvelles applications ou sous-composants
à des solutions autres que la solution WebSphere Remote Server est d'utiliser les
scripts existants fournis avec la solution WebSphere Remote Server pour constituer
une base de départ.
Exemple : Ajout d'une nouvelle application à une nouvelle solution
Cette application possédera une fonction de départ et d'arrêt.
1. Ajoutez la solution au fichier de métadonnées WebSphere Remote Server. Les
balises de la nouvelle solution seront ajoutées au même niveau que la solution
WRS. Dans cet exemple, on ajoute la solution NewSolution.
.... les balises de la solution WRS se trouvent ici
</solution>
<solution name="NewSolution">
</solution>
2. Ajoutez les informations de l'application au fichier de métadonnées WebSphere
Remote Server sous la solution NewSolution. Dans cet exemple, les
informations de départ et d'arrêt sont ajoutées à l'application NewApplication :
123
.... les balises de la solution WRS se trouvent ici
</solution>
<solution name="NewSolution">
<application name="TestApplication">
<start>wrs_NewApplication_start.bat </start>
<stop>wrs_NewApplication_stop.bat </stop>
</application>
</solution>
3. Si les commandes souhaitées sont des appels de script, créez les scripts
nécessaires. Dans cet exemple, les commandes sont des appels aux scripts
wrs_NewApplication_start.bat et wrs_NewApplication_stop.bat. Voici le script
wrs_NewApplication_start.bat résultant de l'utilisation du fichier
wrs_DB2_start.bat en tant que modèle (fichier présent si DB2 a été installé) :
@echo off
set SUCCESS=0
set FAILURE=1
set UNKNOWN=2
set BINDIR"%SIF_HOME%\bin
set rc=%UNKNOWN%
@call "%BINDIR%\NewApplication.exe start"
> %TEMPLOG% 2>&1
@REM Could not start, but may already be started
goto checkifstarted
)
@REM Command succeeded
set rc=%SUCCESS%
goto end
)
:checkifstarted
%JAVACMD% -cp %CP% com.ibm.sif.utility.FindString %TEMPLOG% "Already started"
set rc=%SUCCESS%
goto end
)
set rc=%FAILURE%
goto end
)
:end
type %TEMPLOG%
del /s /q %TEMPLOG%
exit /b %rc%
v Initialisez les variables locales nécessaires.
v Appelez le fichier SifSetupCmdLine.bat ou SifSetupCmdLine.sh. Le script
d'environnement nécessaires pour ce dernier soient initialisées (par exemple, la
commande permettant d'appeler Java ou de paramétrer le chemin d'accès aux
classes Java).
v Appelez la commande pour l'application. Dans cet exemple, la commande est
NewApplication.exe start
v Evaluez le résultat de l'appel de la commande. Dans cet exemple, si
NewApplication a été démarré correctement, le code retour est défini
sur %SUCCESS%. Cependant, dans cet exemple, si le démarrage de
NewApplication ne renvoie pas la valeur 0, il se peut que l'application soit déjà
démarrée ; dans ce cas, le texte Already started s'affiche à l'écran. La fenêtre de
résultat sera inscrite dans le fichier journal nommé, situé dans %TEMPLOG%.
Vous pouvez rechercher dans ce fichier le texte Already started à l'aide de
com.ibm.sif.utility.FindString, comme illustré ci-dessus. Si le texte recherché
existe, le code retour de l'application est défini sur %SUCCESS%, sinon il est
défini sur %FAILURE%.
124
v
v
v
v
Affichez le résultat de l'appel de la commande.
Supprimez le fichier temporaire contenant le résultat de la commande.
Renvoyez le code retour de l'appel de la commande.
Appelez le processeur de commandes WebSphere Remote Server pour démarrer
TestApplication. Utilisez, si vous le souhaitez, les paramètres facultatifs
suivants :
La manière la plus simple d'appeler le processeur de commandes WebSphere
Remote Server pour une nouvelle solution consiste à créer de nouveaux fichiers
script à l'aide des fichiers script fournis pour la solution WebSphere Remote
Server en tant qu'éléments de base. Le script wrsstart.bat sera utilisé comme
exemple pour illustrer la création d'un script de démarrage d'une nouvelle
solution :
@ECHO OFF
@REM setup environment to run the WRSCommandProcessor
CALL "%SIF_HOME%\bin\SifSetupCmdLine.bat"
@REM process the input parameters
IF (%1)==() (GOTO NewSolutionStack) ELSE (GOTO PARAMETERS)
@REM use WRSCommandProcessor to start NewSolution stack
:NewSolutionStack
%JAVACMD% -classpath %CP% com.ibm.wrs.solution.utils.WRSCommandProcessor.class start NewSolution
GOTO END
@REM use WRSCommandProcessor to start item specified by parameters
:PARAMETERS
%JAVACMD% -classpath %CP% com.ibm.wrs.solution.utils.WRSCommandProcessor.class start NewSolution %1 %2 %3 %4 %5 %6 %7 %8 %9
GOTO END
@REM exit the batch file
:END
GOTO:EOF
1. Appelez le script SifSetupCmdLine.bat ou SifSetupCmdLine.sh. Le script
d'environnement nécessaires pour ce dernier soient initialisées (par exemple,
la commande permettant d'appeler Java ou de paramétrer le chemin d'accès
aux classes Java).
2. Appelez le processeur de commandes WebSphere Remote Server en fonction
des paramètres d'entrée. S'il n'existe aucun paramètre d'entrée, considérez
que la pile NewSolution doit être démarrée. Si des paramètres d'entrée
existent, démarrez l'application ou le sous-composant qui se trouve au
niveau indiqué par les paramètres d'entrée.
Deux éléments importants sont à vérifier lors de l'appel du processeur de
commandes WebSphere Remote Server :
– Le nom de la balise du type de commande se trouvant dans le fichier de
métadonnées WebSphere Remote Server doit être le paramètre postérieur
au paramètre WRSCommandProcessor.class. Dans cet exemple, la balise
est nommée start.
– Le nom de la solution est le paramètre qui suit la balise du type de
commande. Dans cet exemple, la solution est nommée NewSolution.
Extension de la gestion des mots de passe pour gérer les applications
utilisateur
Les applications groupées avec IBM WebSphere Remote Server peuvent avoir ou
non des données d'identification. WebSphere Remote Server peut être étendu afin
d'utiliser les utilitaires WebSphere Remote Server pour la gestion des mots de
passe.
Si la nouvelle application utilisateur utilise des données d'identification, la balise
<credential> doit être ajoutée au fichier de métadonnées WebSphere Remote Server
125
sous la balise <root> et la balise <changePasswordCmd> sous la balise
<application>. Cet ajout de balises doit être effectué lors de la création de la balise
<application>. La gestion des mots de passe n'est effective que si des données
d'identification sont associées à l'application.
Par exemple, dans le cas d'IBM WebSphere Application Server, vous pouvez activer
ou non la sécurité. Si vous souhaitez activer la sécurité, vous devez définir les
données d'identification. Ces données d'identification doivent ensuite être ajoutées
au fichier de métadonnées WebSphere Remote Server. Des exemples de balises de
données d'identification sont répertoriés ci-dessous :
<root>
.........
<credential name="wsadmin">
<username>wsadmin</username>
<password encrypt="true">/Q5nlQaS4HpXOVYbTlpzAQ==</password>
<changePassword list="true">
<item sequence="50">${//solution[@name="WRS"]/application[@name="WRSBASE"]/changePasswordCmd}</item>
<item sequence="60">${//solution[@name="WRS"]/application[@name="WAS"]/subcomponent[@name="WRSProfile"]/changePasswordCmd}</item>
</changePassword>
</credential>
</root>
La balise <changePassword> fera référence à la balise <changePasswordCmd> sous
la balise <application>. Voici un exemple de balise <changePasswordCmd> dans la
balise <application> :
<root>
<application name="WAS">
...............
<subcomponent name="WRSProfile">
...............
<enableAdminSecurity>true</enableAdminSecurity>
<changePasswordCmd>wrs_WAS_changePwd server1</changePasswordCmd>
Ici, <changePasswordCmd> fournit la référence de fichier .bat/.sh à exécuter. La
gestion des mots de passe permet d'ajouter les paramètres au moment de
l'exécution, avant d'exécuter le fichier .bat/.sh. Le fichier de métadonnées
WebSphere Remote Server n'affiche pas tous les arguments transmis au fichier
.bat/.sh.
Votre application doit posséder des appels de fonction permettant de modifier le
mot de passe de l'utilisateur. Vous devrez développer le programme .bat/.sh
encapsuleur qui modifie le mot de passe de l'utilisateur. Ce programme de script
encapsuleur doit respecter certaines normes comme mentionné dans le paragraphe
qui suit.
Par exemple, voici à quoi ressemble la commande permettant de modifier le mot
de passe de l'application WebSphere Application Server : _WAS_changePwd {arg1}
{arg2} {arg3} {arg4} {arg5}. Dans cet exemple, arg1 est le nom du serveur, arg2
le nom d'utilisateur, arg3 l'ancien mot de passe, arg4 le nouveau mot de passe et
arg5 le type de commande.
Le nom d'utilisateur, l'ancien mot de passe, le nouveau mot de passe et le type de
commande sont obligatoires pour tout type d'application. Les arguments restants
sont modifiés en fonction des applications. L'ordre des arguments dépend
également de l'application.
Le paramètre de type de commande est ici utilisé pour décrire si la commande à
exécuter est en mode normal ou en mode d'annulation. L'annulation est mise en
oeuvre en appelant la commande changePassword, le nouveau mot de passe étant
identique à l'ancien.
Voici un fichier .bat d'exemple :
126
@echo OFF
@echo ChangePassword WAS server1 -username -oldpassword
Set
set
set
set
set
-newpassword cmdType
WASPROFILE=%1
username=%2
oldpassword=%3
newpassword=%4
cmdtype=%5
set normalCmd=0
set normalCmdSuccessDoRB=1
set normalCmdFailDoRB=2
set
set
set
set
set
STARTED=1
STOPPED=2
UNKNOWN=3
PWDCHANGESUCCESS=0
PWDCHANGEFAIL=-1
set BINDIR=%WAS_HOME%\profiles\%WAS_PROFILE_NAME%\bin
set rc=%UNKNOWN%
if %cmdtype% EQU %normalCmd% (
@echo we are Normal Cmd mode
@CALL "%BINDIR%\serverStatus.bat" %WASPROFILE% -username %username% -password %newpassword% > %TEMPLOG% 2>&1
if NOT "%ERRORLEVEL%" EQU "0" (
@echo Some sort of status error
set rc=%UNKNOWN%
goto :end
)
goto :findstring
)
if %cmdtype% EQU %normalCmdFailDoRB%(
...................
...................
)
if %cmdtype% EQU %normalCmdSuccessDoRB%(
.....................
........................
)
:findstring
%JAVACMD% -cp %CP% com.ibm.sif.utility.FindString %TEMPLOG% "ADMU0508I"
@echo WAS status = started
set rc=%PWDCHANGESUCCESS%
goto :end
)
%JAVACMD% -cp %CP% com.ibm.sif.utility.FindString %TEMPLOG% "ADMU0509I"
@echo WAS status = Stopped
set rc=%PWDCHANGESUCCESS%
goto :end
)
:end
exit /b %rc%
La gestion des mots de passe est déclenchée par IBM Tivoli Provisioning Manager
via l'instanciation de la classe WRSCommandProcessor. Tivoli Provisioning
Manager déclenche l'application de modification de mot de passe ou l'application
d'analyse en transmettant les arguments suivants :
Pour déclencher l'application d'analyse :
v analyse - {arg1}
v données d'identification - {arg2}
v nom de fichier - {arg3}
Pour déclencher l'application de modification de mot de passe :
v modification - {arg1}
v données d'identification - {arg2}
v nom de fichier - {arg3}
Application d'analyse
L'application d'analyse parcourt tous les utilisateurs en commençant par le fichier
de métadonnées WebSphere Remote Server et génère un fichier de sortie. Le fichier
de sortie contient un nom d'utilisateur et sa date d'expiration, extraite du système
127
d'exploitation. Si l'utilisateur analysé à partir du fichier de métadonnées
WebSphere Remote Server n'existe pas dans le système d'exploitation, l'application
d'analyse ajoute le message associé à la place de la date d'expiration.
Il n'est pas nécessaire que l'application utilisateur possède des fonctions exposées
pour l'analyse. Toutefois, pour améliorer la gestion des mots de passe, il est
recommandé que les applications utilisateur appliquent une règle d'expiration des
mots de passe et tirent pleinement parti de l'utilitaire de gestion des mots de passe
fourni avec WebSphere Remote Server pour gérer leurs mots de passe
d'application.
Remarque : Les flux de travaux Tivoli Provisioning Manager utilisés pour
déclencher la gestion des mots de passe ne nécessitent aucune
configuration/modification particulière pour gérer les applications
utilisateur.
128
Chapitre 6. Identification, résolution des incidents et
assistance
Cette section fournit des informations concernant les outils d'identification et de
résolution des incidents, le support et les problèmes liés à l'installation.
Installation et utilisation d'IBM Support Assistant
IBM Support Assistant (ISA) vous permet de rechercher de la documentation
produit, de créer des rapports de gestion des produits (PMR) et de placer les
fichiers journaux dans un package.
ISA est une application autonome que vous pouvez installer sur tout poste de
travail puis améliorer grâce à l'installation de plug-ins pour les produits IBM que
vous utilisez. Pour plus d'informations sur ISA et ses fonctionnalités, voir la page
de support ISA Support. WebSphere Remote Server prend en charge la version
4.0.2 ou suivante d'ISA.
La liste des plateformes prises en charge pour ISA est visible sur le site
http://www.ibm.com/support/docview.wss?rs=3455&uid=swg27012685
Remarque : Si ISA n'est pas installé sur le serveur d'entreprise utilisé pour gérer
les processeurs ISP d'IBM WebSphere Remote Server, alors les scripts
de collecte de journaux regroupés depuis les processeurs ISP doivent
être déplacés manuellement vers le poste de travail d'ISA.
Les étapes suivantes vous expliquent comment installer et exécuter ISA.
Procédure
1. Installez ISA.
2. Utilisez le composant de mise à jour intégré d'ISA pour installer le plug-in de
WebSphere Remote Server. Vous pouvez également télécharger et installer le
plug-in de WebSphere Remote Server et tout autre plug-in de produit
supplémentaire depuis la liste des modules pris en ISAcharge.
a. Ouvrez ISA, et sélectionnez Mise à jour → Chercher de nouveaux →
Additifs produit.
b. Développez le dossier des produits WebSphere et sélectionnez WebSphere
Remote Server V7.1.1.
c. Cliquez sur Suivant.
d. Cliquez une nouvelle fois sur Suivant.
e. Acceptez le Contrat de licence.
f. Cliquez sur Suivant.
g. Affichez le récapitulatif et cliquez sur Terminer pour commencer
l'installation.
h. Lorsque la fenêtre de résultats s'affiche, cliquez sur Terminer.
i. Redémarrez ISA lorsque vous y êtes invité.
129
3. Préparez-vous à utiliser la fonctionnalité d'analyse des incidents d'ISA pour
a. Avant de procéder à la collecte des données et de soumettre un PMR dans
l'infrastructure ISA, assurez-vous que l'outil de collecte de journaux existe
dans le processeur intégré au magasin. Ceci est obligatoire car le plug-in
ISA collecte les fichiers en faisant appel automatiquement à l'outil de
collecte de journaux. Pour plus d'informations, voir «Collecteur de journal».
b. Sélectionnez Analyse d'incident → Collecte des données et cliquez sur
Sélectionner des collecteurs.
c. Développez l'arborescence des produits et recherchez WebSphere Remote
Server 7.1.1.
d. Ajoutez le Collecteur général sous WebSphere Remote Server 7.1.1 à la
File d'attente de collecteur et cliquez sur Collecter tout pour lancer la
collecte des journaux WebSphere Remote Server.
Pendant la collecte, le collecteur de données vous demandera le nom du
fichier de sortie de la collecte et l'emplacement du répertoire de base
WebSphere Remote Server. A la fin de la collecte, le collecteur de données
vous demandera si vous voulez envoyer les journaux par FTP au service de
support IBM.
4. Utilisez les liens figurant sur la page de support ISA Support pour obtenir des
informations détaillées sur l'utilisation d'ISA.
Collecteur de journal
L'outil de collecte de journaux vous aide à récupérer n'importe quel fichier journal
depuis les processeurs intégrés au magasin (ISP) vers le serveur d'entreprise..
Archivage des fichiers journaux
Lorsque la solution WebSphere Remote Server a été installée sur le processeur
intégré au magasin, un script permettant d'archiver des fichiers journaux dans un
fichier JAR, nomHôte_Logs_horodatage.jar, est présent sur le processeur intégré au
magasin dans les répertoires suivants :
SIF_HOME\bin\archivelogs.bat
SIF_HOME/bin/archivelogs_linux.sh
Lorsque vous exécutez l'outil de collecte de journaux, les fichiers journaux collectés
sont placés dans les répertoires suivants :
SIF_HOME\logs\collectedlogs\logs
SIF_HOME/logs/collectedlogs/logs
Si WebSphere Application Server est installé, l'outil de collecte de journaux
regroupe ces fichiers dans un fichier JAR situé dans les répertoires suivants :
SIF_HOME\logs\collectedlogs\archivelogs
SIF_HOME/logs/collectedlogs/archivelogs
Remarque : Si vous voulez conserver les fichiers journaux existants,
sauvegardez-les avant d'exécuter l'outil de collecte de journaux.
Utilisation du flux de travaux du collecteur de journaux
Pour utiliser le flux de travaux du collecteur de journaux, vous devez tout d'abord
ajouter ce flux de travaux à votre serveur IBM Tivoli Provisioning Manager.
130
Remarque : Si vous collectez des fichiers journaux qui seront utilisés avec IBM
Support Assistant mais que le produit ISA est installé sur une autre
machine de l'entreprise, vous pourrez sans doute récupérer les fichiers
journaux directement du processeur ISP vers la machine ISA. L'agent
commun Tivoli doit être installé sur la machine ISA. Les zones
Destination_Hostname et DestinationPath pourront ensuite être définies
avec les mêmes valeurs que celles de la machine ISA.
Procédure
1. Connectez-vous à : https://nom_hôte:9443/maximo/ui/login
2. Cliquez sur Aller à → Gestion → Application des accès → Flux de travaux
d'application des accès.
.
3. Dans le composeur de flux de travaux d'application des accès, cliquez sur
4. Cliquez sur Sélectionner une action → Ouvrir un flux de travaux, puis
sélectionnez ServerSifDir/bin/WRS_logCollection.wkf.
5. Cliquez sur OK.
6. Cliquez sur l'option de compilation du flux de travaux. Une fois la compilation
effectuée, vous pouvez exécuter le flux de travaux pour collecter des fichiers
journaux depuis n'importe quel processeur ISP distant.
7. Cliquez sur l'option d'exécution du flux de travaux.
8. Indiquez les informations correspondant aux zones obligatoires dans la fenêtre
Input Parameter for Workflow - WRS_logCollection :
v Dans Source_Full_Hostname : Entrez le nom d'hôte du processeur ISP. Le
nom d'hôte selon le modèle de données Tivoli Provisioning Manager peut
être le nom de système hôte qualifié complet ou partiel. Pour vérifier la
valeur du nom d'hôte à utiliser, entrez le nom d'hôte dans la zone FIND de
la fenêtre TPM.
v Source_WRS_Home_Directory : entrez le répertoire RACINE_SIF sur le
processeur ISP.
v Destination_Hostname : Entrez le nom d'hôte du serveur Tivoli Provisioning
Manager. Pour vérifier la valeur du nom d'hôte à utiliser, entrez le nom
d'hôte dans la zone FIND de la fenêtre TPM.
v DestinationPath : Entrez le répertoire de destination sur le serveur Tivoli
Provisioning Manager. L'utilisateur tioappadmin (ou tout utilisateur utilisé
pour exécuter le flux de travaux) doit avoir les droits nécessaires pour placer
le fichier dans le chemin de destination.
9. Cliquez sur Run.
Astuces pour l'identification et la résolution des incidents
Cette section décrit certains problèmes et leurs solutions possibles.
v «Le tableau de bord ne se charge pas correctement et affiche une erreur Non
définie», à la page 132
v
v
v
v
«La désinstallation a échoué», à la page 132
«La désinstallation de WebSphere MQ échoue», à la page 133
«Des fichiers ont été ignorés après une désinstallation réussie», à la page 133
«Le programme de désinstallation de WebSphere Remote Server ne détecte pas
certains produits», à la page 133
Chapitre 6. Identification, résolution des incidents et assistance
131
v «L'installation de DB2 échoue si le mot de passe ne correspond pas au mot de
passe précédent», à la page 134
v «L'installation de DB2 échoue sous Linux», à la page 134
v «IBM HTTP Server affiche une erreur relative au nom de domaine complet», à la
page 134
v «Exception de source de données WebSphere Application Server», à la page 134
v «Exception WebSphere Application Server après l'installation», à la page 135
v «Exception WebSphere Application Server relative à l'application commerciale»,
à la page 135
v «Exception liée à la migration de l'application WebSphere Application Server
Trade», à la page 135
v «Exception SRVE0255E», à la page 136
v «Exception Software Assembly Toolkit après l'installation», à la page 136
v «Réinstallation d'Informix Growth Edition», à la page 136
v «Redémarrage d'un serveur Linux avec la sécurité WebSphere Application Server
activée», à la page 136
v «Software Assembly Toolkit Developer ne s'ouvre pas sous SUSE Linux
Enterprise Server 10.3 (64 bits)», à la page 136
v «Exception du fournisseur de données WebSphere Remote Server», à la page 137
v «Graphiques des icônes manquants dans les fenêtres de l'afficheur de fichiers
pour les zones Répertoire d'installation de l'assistant de déploiement sous
Windows 7», à la page 137
Le tableau de bord ne se charge pas correctement et affiche une
erreur Non définie
Le tableau de bord ne peut pas être exécuté depuis une unité distante. Pour
exécuter le tableau de bord, procédez comme suit :
1. Copiez la solution IBM WebSphere Remote Server sur un disque local et
exécutez le tableau de bord.
2. Mappez l'unité réseau vers un identificateur d'unité local et exécutez le tableau
de bord.
La désinstallation a échoué
La solution complète WebSphere Remote Server doit être interrompue avant
l'exécution du programme de désinstallation. Le processus de désinstallation
appelle le script wrsstop. Cependant, certains composants de la solution peuvent
être encore en cours de fonctionnement (comme les gestionnaires de files d'attente
WebSphere MQ). Arrêtez tous les composants de WebSphere Remote Server avant
de lancer la désinstallation.
Si la désinstallation de tout composant de WebSphere Remote Server échoue, le
composant de base de WebSphere Remote Server ne sera pas désinstallé. Si vous
souhaitez résoudre manuellement le problème rencontré lors de la désinstallation,
réparez votre fichier de métadonnées WebSphere Remote Server (voir ci-dessous) et
exécutez à nouveau la désinstallation.
Réparation du fichier de métadonnées de WebSphere Remote Server : le fichier
de métadonnées de WebSphere Remote Server gère les informations relatives à la
solution WebSphere Remote Server. Si un incident survient lors du processus de
désinstallation, il se peut que le fichier de métadonnées de WebSphere Remote
132
Server ne soit pas à jour. Dans ce cas, vous devez mettre à jour le fichier de
métadonnées de WebSphere Remote Server après avoir résolu le problème lié à la
désinstallation. Ce fichier se trouve dans SIF_HOME/solution/WRSMetadata.xml.
Pour le mettre à jour, supprimez les sections relatives aux produits désinstallés. Par
exemple, si vous avez supprimé manuellement WebSphere MQ, supprimez
également la section <application name="MQ"...</application>.
La désinstallation de WebSphere MQ échoue
La modification de l'emplacement d'installation de WebSphere MQ lors de la
migration de WebSphere Remote Server version 6.1 vers la version 7.1.1 peut
entraîner l'échec de la désinstallation de WebSphere Remote Server. L'exception
suivante s'affiche sur la ligne de commande lorsque le programme de
désinstallation tente de désinstaller WebSphere MQ :
ALG00101I: Beginning uninstall of product: MQ
java.lang.Exception: An exception occurred while shelling out for the command cmd /c dspmq.exe -o all
at com.ibm.wrs.solution.utils.ISPUtils.executeCommand(Unknown Source)
at com.ibm.wrs.solution.uninstall.MQ.stopMqQueueMgrs(Unknown Source)
at com.ibm.wrs.solution.uninstall.WRSUninstall.uninstallMQ(Unknown Source)
at com.ibm.wrs.solution.uninstall.WRSUninstall.uninstall(Unknown Source)
at com.ibm.wrs.solution.uninstall.WRSUninstall.main(Unknown Source)
Caused by: java.io.IOException: Cannot run program "cmd" (in directory "C:\Program Files\IBM\puzzle\SIF\MQ\bin"):
CreateProcess error=267, The directory name is invalid.
at java.lang.ProcessBuilder.start(ProcessBuilder.java:470)
at java.lang.Runtime.exec(Runtime.java:604)
... 5 more
Caused by: java.io.IOException: CreateProcess error=267, The directory name is invalid.
at java.lang.ProcessImpl.<init>(ProcessImpl.java:92)
at java.lang.ProcessImpl.start(ProcessImpl.java:41)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:463)
... 6 more
ALG00000I: Invoking command C:\Program Files\IBM\puzzle\SIF\MQ\uninstall\uninstall.bat ALG00030I:
Return code 0
Pour empêcher ce problème, ne modifiez pas l'emplacement d'installation de
WebSphere MQ lors de la migration de WebSphere Remote Server 6.1 vers la
version 7.1.1. Si vous avez modifié l'emplacement d'installation lors de la
migration, voir «La désinstallation a échoué», à la page 132 pour désinstaller
correctement WebSphere Remote Server.
Des fichiers ont été ignorés après une désinstallation réussie
Si un incident se produit pendant le processus de désinstallation, les étapes de
désinstallation "propre" de l'application défaillante ne seront pas exécutées. Vous
devez les exécuter manuellement. Les étapes indispensables sont répertoriées dans
la section Utilisation de l'option de nettoyage de la rubrique «Désinstallation», à la
page 51.
Le programme de désinstallation de WebSphere Remote Server
ne détecte pas certains produits
Si le programme de désinstallation de WebSphere Remote Server ne parvient pas à
détecter certains produits, vous pouvez les désinstaller manuellement grâce aux
commandes suivantes :
WAS : /opt/IBM/SIF/WebSphere/AppServer/uninstall/uninstall -silent
IHS : /opt/IBM/SIF/HTTPServer/uninstall/uninstall -silent
DB2 : /opt/IBM/SIF/db2/V9.7/install/db2_deinstall -a
MQ : /opt/IBM/SIF/bin/uninstallMQ.sh
WRSBASE : /opt/IBM/SIF/uninstall_IrssBase/uninstall -silent
133
WAS : "C:\Program Files\IBM\SIF\WebSphere\AppServer\uninstall\uninstall.exe" -silent
IHS : "C:\Program Files\IBM\SIF\HTTPServer\uninstall\uninstall.exe" -silent
MQ : msiexec.exe /x{5A2B3A23-0999-4D7E-BAAC-3B158C5FF003} /q
DB2 : msiexec.exe /x{D7F20946-5D4B-4EF1-92E4-B3A1D54B7052} /q
WRSBASE : "c:\Program Files\IBM\SIF\uninstall_IrssBase\uninstall.exe" -silent
Si le programme de désinstallation de WebSphere Remote Server ne parvient pas à
détecter certains produits sous Windows, vous pouvez également utiliser la fenêtre
Ajouter ou supprimer des programmes pour les désinstaller.
L'installation de DB2 échoue si le mot de passe ne correspond
pas au mot de passe précédent
Si DB2 a été précédemment installé sur le processeur ISP, alors il est possible que
les ID utilisateur de DB2 existent déjà. L'installation échouera si le mot de passe
que vous saisissez ne correspond pas au mot de passe des ID utilisateur existants
de DB2.
Pour résoudre ce problème, deux options s'offrent à vous :
v Supprimez les ID utilisateur de DB2 (Windows : db2admin, Linux : db2inst1,
dasusr1 et db2fenc1) et installez DB2. Modifiez tous les mots de passe dans le
fichier de tâches en mode silencieux.
v Ne supprimez pas les ID utilisateur DB2. Installez DB2 et indiquez le mot de
passe des ID utilisateur existants de DB2.
L'installation de DB2 échoue sous Linux
Lors de la migration de WebSphere Remote Server version 6.2 ou 6.2.1 vers la
version 7.1.1 sur un système d'exploitation Linux, un nouveau chemin
d'installation doit être spécifié pour DB2. Si le chemin d'installation DB2 existant
est utilisé, l'erreur suivante se produit :
The install location /opt/IBM/SIF/db2/V9.5 contains an installed DB2 product
that is not at the same level as the DB2 product you are attempting to install.
Specify another location.
IBM HTTP Server affiche une erreur relative au nom de domaine
complet
IBM HTTP Server attend un nom de domaine complet et peut renvoyer une erreur
similaire à la suivante :
httpd: Could not determine the server’s fully qualified domain name,
using 9.42.121.61 for NomServeur
Pour résoudre ce problème, il faut mettre à jour le fichier hôte de l'ordinateur avec
le nom de domaine complet. Ce fichier se trouve au chemin /etc/hosts sur Linux
et au chemin %SYSTEMROOT%\System32\drivers\etc\hosts sur Windows. Par
exemple : 9.42.121.61 wrslinisp2.rtp.raleigh.ibm.com wrslinisp2 wrsalias.
Exception de source de données WebSphere Application Server
Lors de la migration de la version 6.x vers la version 7.1.1 de WebSphere Remote
Server, le chemin d'accès aux classes du fournisseur JDBC auquel sont associées les
applications d'exemple (Plants and Trades) est écrit sous forme de code en dur ;
par exemple, /opt/IBM/SIF/db2/V9.5/java. Après la migration, la connexion de test
pour la source de données des applications d'exemple échoue car DB2 est migré
vers la version 9.7 Fix Pack 2 et le chemin /opt/IBM/SIF/db2/V9.5/ n'existe pas.
134
Par exemple, le message d'erreur suivant se produit lors de l'échec de la connexion
de test pour la source de données de l'application Plants :
The test connection operation failed for data source Plants by WebSphere Data Source on server
serveur1 at node NoeudWRS with the following exception: java.lang.ClassNotFoundException: DSRA8000E:
No jar or zip files found in /opt/IBM/SIF/db2/V9.5/java/db2jcc.jar:/opt/IBM/SIF/db2/V9.5/java/
db2jcc_license_cu.jar:/opt/IBM/SIF/db2/V9.5/java/db2jcc_javax.jar. View JVM logs for further details.
Pour remédier à ce problème, utilisez la console d'administration WebSphere
Application Server pour définir la valeur du chemin d'accès aux classes du
fournisseur JDBC sur la variable d'environnement
${DB2UNIVERSAL_JDBC_DRIVER_PATH} avant de démarrer le processus de
migration. Cette variable sera mise à jour lors de la migration.
Exception WebSphere Application Server après l'installation
Après une installation réussie du produit, il se peut que l'exception suivante soit
générée dans le fichier SystemOut.log :
[3/19/09 13:23:03:810 PDT] 00000000 JMSRegistrati E WMSG1623E: The WebSphere MQ messaging
provider installed at C:\PROGRA~1\IBM\SIF\WEBSPH~1\APPSER~1\installedConnectors\wmq.jmsra.rar
has been updated and an application server restart is required to pick up this update. The
WebSphere MQ messaging provider has been disabled.
Vous pouvez ignorer cette exception.
Exception WebSphere Application Server relative à l'application
commerciale
Après une installation réussie des middleware et des applications, il se peut que
l'exception suivante concernant l'application Trade soit générée dans le fichier
SystemOut.log :
[3/28/09 1:26:57:797 PDT] 0000000b WSServerImpl E WSWS1002E: An error occurred while
processing the Web services deployment descriptor for module: tradeWeb.war with error:
java.lang.NullPointerException
at com.ibm.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:449)
at java.lang.ClassLoader.loadClass(ClassLoader.java:609)
at com.ibm.ws.webservices.component.WSServerImpl.setupWsddPort(WSServerImpl.java:1150)
at com.ibm.ws.webservices.component.WSServerImpl.warMetaDataCreated(WSServerImpl.java:2089)
at com.ibm.ws.webservices.component.WSServerImpl.metaDataCreated(WSServerImpl.java:633)
at com.ibm.ws.runtime.component.MetaDataMgrImpl.fireMetaDataCreated(MetaDataMgrImpl.java:189)
at com.ibm.ws.webcontainer.metadata.WebMetaDataFactory.createMetaData(WebMetaDataFactory.java:205)
at com.ibm.ws.runtime.component.MetaDataMgrImpl.createMetaDataFromFactories(MetaDataMgrImpl.java:173)
at com.ibm.ws.runtime.component.MetaDataMgrImpl.createMetaData(MetaDataMgrImpl.java:307)
at com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:605)
at com.ibm.ws.runtime.component.DeployedApplicationImpl.start(DeployedApplicationImpl.java:938)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:721)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:2062)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:437)
at com.ibm.ws.runtime.component.CompositionUnitImpl.start(CompositionUnitImpl.java:122)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:380)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.access$300(CompositionUnitMgrImpl.java:108)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl$CUInitializer.run(CompositionUnitMgrImpl.java:935)
at com.ibm.wsspi.runtime.component.WsComponentImpl$_AsynchInitializer.run(WsComponentImpl.java:349)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1527)
Exception liée à la migration de l'application WebSphere
Application Server Trade
Lors de la migration de WebSphere Remote Server version 6.1 vers la version 7.1.1
sous Windows 2003 avec la sécurité WebSphere Application Server activée,
l'application Trade ne démarre pas et l'exception suivante se produit :
java.utl.ConcurrentModificationException (in com.ibm.jsd.eclipse.main plug-in)
Pour résoudre le problème, ouvrez la console d'administration de WebSphere
Application Server, puis cliquez sur Utilisateurs et groupes → Gérer les
135
utilisateurs → Créer pour créer un compte utilisateur db2admin (ou votre nom
d'utilisateur DB2).
Exception SRVE0255E
Après une installation réussie du produit, il se peut que l'exception suivante
concernant le fichier favicon.ico soit présente dans le fichier SystemOut.log :
[5/4/09 22:57:27:759 PDT] 0000002b webcontainer E com.ibm.ws.webcontainer.WebContainer
handleRequest SRVE0255E: A WebGroup/Virtual Host to handle /favicon.ico has not been defined.
Ce fichier favicon.ico manquant est utilisé dans la console d'administration
WebSphere Application Server afin d'afficher une icône dans le navigateur
correspondant à un signet ou un onglet de navigateur ouvert pour l'application.
Exception Software Assembly Toolkit après l'installation
Après une installation réussie de l'environnement de développement de
WebSphere Remote Server (sur toutes les plateformes), l'espace de travail s'ouvre
avec les exceptions suivantes répertoriées dans la vue Journal des erreurs :
A handler conflict occurred. This may disable some commands (in the org.eclipse.ui.workbench plug-in)
The Java indexing could not index C:\Program Files\ibm\ISAT\3.2\SolutionEnabler\externalSupportJars\
db2jcc.jar|COM\ibm\db2os390\sqlj\custom\DB2SQLJCustomizer.class.
This .class file does not follow the class file format specification. Please report this issue against
the .class vendor (in the org.eclipse.jdt.core plug-in)
Vous pouvez ignorer ces exceptions.
Réinstallation d'Informix Growth Edition
Si vous installez Informix Growth Edition, puis le désinstallez sans utiliser l'option
clean, vous ne pourrez plus l'installer.
La réinstallation après une désinstallation sans l'option clean est possible pour
DB2.
Redémarrage d'un serveur Linux avec la sécurité WebSphere
Application Server activée
Si la sécurité WebSphere Application Server est activée sur un système
d'exploitation Linux, veillez à arrêter WebSphere Application Server avant de
réamorcer le serveur.
Software Assembly Toolkit Developer ne s'ouvre pas sous SUSE
Linux Enterprise Server 10.3 (64 bits)
Si vous ouvrez Software Assembly Toolkit Developer sur le système d'exploitation
SUSE Linux Enterprise Server 10.3 (64 bits) à l'aide de la commande cd
/opt/IBM/SAT/3.2/SolutionEnabler ./IRU_Developer.sh, l'erreur suivante se
produit :
/opt/IBM/ISAT/3.2/SolutionEnable/DJTJRE/bin/javaw:symbol lookup error
:/usr/lib/xulrunner-1.9.1.2/libxul.so:undefined symbol:gdk_screen_get_resolution
136
Pour résoudre le problème, vous devez disposer de XULRunner version 1.8.1.1 ou
1.9.0.6 sur le poste de travail. Pour résoudre le problème, procédez comme suit :
1. Pour vérifier les versions de XULRunner disponibles sur le poste de travail,
vous devez :
a. Accéder au répertoire /usr/lib à l'aide de la commande #cd /usr/lib
b. Exécuter la commande # ls -ld xul* pour afficher les versions de
XULRunner disponibles.
c. Si XULRunner version 1.8.1.1 ou 1.9.0.6 est indisponible sur le poste de
travail, vous pouvez le télécharger à l'adresse
http://releases.mozilla.org/pub/mozilla.org/xulrunner/.
2. Ajoutez la chaîne de paramètre suivante à la fin du fichier IRU_Developer.sh
dans le répertoire /opt/IBM/ISAT/3.2/SolutionEnabler :
-Dorg.eclipse.swt.browser.XULRunnerPath=/usr/lib/xulrunner-1.8.1.1/xulrunner
Remarque : Si vous utilisez XULRunner version 1.9.0.6, vous devez indiquer le
chemin de répertoire suivant dans la chaîne de paramètre à la
place : =/usr/lib/xulrunner-1.9.0.6/xulrunner.
Exception du fournisseur de données WebSphere Remote Server
Lorsque vous utilisez le fournisseur de données WebSphere Remote Server pour
surveiller Remote Management Agent, l'exception suivante risque d'apparaître
dans le fichier orbtrc.13072010.1911.31.txt du répertoire SIF_HOME\WRSDP :
19:11:31.409 com.ibm.rmi.iiop.Connection getCallStream:2325 Thread-7 ORBRas[default]
org.omg.CORBA.COMM_FAILURE: purge_calls:1988 Reason: CONN_ABORT (1), State: ABORT (5)
vmcid: IBM minor code: 306 completed: Maybe
at com.ibm.rmi.iiop.Connection.purge_calls(Connection.java:1987)
at com.ibm.rmi.iiop.Connection.doReaderWorkOnce(Connection.java:3103)
at com.ibm.rmi.transport.ReaderThread.run(ReaderPoolImpl.java:138)
Graphiques des icônes manquants dans les fenêtres de
l'afficheur de fichiers pour les zones Répertoire d'installation de
l'assistant de déploiement sous Windows 7
Si vous utilisez l'assistant de déploiement de WebSphere Remote Server version
7.1.1 sous Windows 7, vous constaterez sans doute que des graphiques sont
absents des icônes de la barre d'outils de navigation dans les fenêtres de l'afficheur
de fichiers pour les zones Répertoire d'installation de l'assistant de déploiement.
Les icônes avec des graphiques manquants sont celles qui permettent demonter
d'un niveau, de créer un dossier, d'établir uneliste et d'afficher les détails.
L'absence des graphiques n'affecte pas la fonction des icônes.
137
138
Ces rubriques contiennent des informations de référence supplémentaires destinées
à vous aider.
Informations générales sur le produit
Le présent document contient les informations nécessaires pour accéder aux
informations de téléchargement, au site de support du produit, aux configurations
logicielle et matérielle et à la documentation d'IBM WebSphere Remote Server.
Accès au site Web de support du produit
Pour rechercher les dernières informations (notes techniques, téléchargements,
correctifs et autres informations de support), visitez le site Web à l'adresse :
http://www.ibm.com/software/webservers/remoteserver/support/
Accès aux configurations matérielle et logicielle
Les configurations matérielle et logicielle sont disponibles dans ce centre de
documentation à l'adresse suivante : «Configurations matérielle et logicielle
requises», à la page 9
Documentation supplémentaire sur le produit
En plus du centre de documentation, des Guides de démarrage rapide sont
disponibles sur un CD-ROM séparé portant le libellé Quick Start (Démarrage
rapide).
La documentation sur le produit est également accessible à partir de la page de la
bibliothèque du produit à l'adresse suivante : http://www-01.ibm.com/software/
webservers/remoteserver/library/index.html
Contact du service de support logiciel IBM
Si vous rencontrez un incident avec le produit WebSphere Remote Server, essayez
dans un premier temps d'exécuter la procédure suivante :
v Suivez les étapes décrites dans la documentation du produit.
v Recherchez la documentation associée dans l'aide en ligne.
Si vous ne parvenez pas à résoudre l'incident au moyen des méthodes précédentes,
contactez le service d'assistance IBM.
L'acquisition de WebSphere Remote Server vous donne droit à un an d'assistance
téléphonique dans le cadre du programme Passport Advantage. Pour plus
d'informations sur le programme Passport Advantage, visitez la page Passport
Advantage.
139
Le numéro d'appel du centre d'assistance WebSphere Remote Server pour les
membres Passport Advantage est le 1-800-426-7378. Avant d'appeler, rassemblez les
informations suivantes :
v Numéro de contrat ou référence Passport Advantage
v Version et niveau de révision du produit WebSphere Remote Server (et
éventuellement des correctifs installés)
v Nom et version du système d'exploitation
v Type et version de la base de données
v Données de topologie de base (nombre de machines en cours de fonctionnement
ou de serveurs d'applications, etc.)
v Messages d'erreur ou d'avertissement liés à l'incident
Livres blancs
Cette section vous indique un lien vers les livres blancs téléchargeables qui
peuvent vous aider à installer, configurer et gérer les composants de votre solution
IBM WebSphere Remote Server.
Rendez-vous à l'adresse URL suivante pour obtenir une liste des livres blancs
disponibles pour WebSphere Remote Server : http://www.ibm.com/support/
search.wss?rs=2193&tc=SSUNCX&rank=8&dc=DA480+DB100&dtm
Remarques et marques
Remarques
Le présent document peut contenir des informations ou des références concernant
certains produits, logiciels ou services IBM non annoncés dans ce pays. Contactez
votre représentant IBM local pour plus d'informations sur les produits et services
actuellement disponibles dans votre pays. Toute référence à un produit,
programme ou service IBM n'implique pas que seul ce produit, programme ou
service IBM puisse être utilisé. Tout autre produit, programme ou service
fonctionnellement équivalent peut être utilisé s'il n'enfreint aucun droit de
propriété intellectuelle d'IBM. Toutefois, il est de la responsabilité de l'utilisateur
d'évaluer et de vérifier le fonctionnement de tout produit, programme ou service
non fourni par IBM.
IBM peut détenir des brevets ou des demandes de brevet couvrant les produits
mentionnés dans le présent document. La remise de ce document ne vous donne
aucun droit de licence sur ces brevets ou demandes de brevet. Si vous désirez
recevoir des informations concernant l'acquisition de licences, veuillez en faire la
demande par écrit à l'adresse suivante :
IBM Director of Licensing
IBM Corporation
North Castle Drive Armonk, NY 10504-1785 U.S.A.
140
Les informations sur les licences concernant les produits utilisant un jeu de
caractères codé sur deux octets peuvent être obtenues auprès du service Propriété
intellectuelle IBM de votre pays, ou en écrivant à l'adresse suivante :
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japan
Le paragraphe suivant ne s'applique ni au Royaume-Uni, ni dans aucun pays dans
lequel il serait contraire aux lois locales. LE PRESENT DOCUMENT EST LIVRE
"EN L'ETAT". IBM DECLINE TOUTE RESPONSABILITE, EXPLICITE OU
IMPLICITE, RELATIVE AUX INFORMATIONS QUI Y SONT CONTENUES, Y
COMPRIS EN CE QUI CONCERNE LES GARANTIES DE NON-CONTREFACON
ET D'APTITUDE A L'EXECUTION D'UN TRAVAIL DONNE. Certaines juridictions
n'autorisent pas l'exclusion des garanties implicites, auquel cas l'exclusion ci-dessus
ne vous sera pas applicable.
Les informations contenues dans ce document sont fournies à titre informatif
uniquement. Ces informations sont basées sur les plans produits et la stratégie
d'IBM qui sont susceptibles d'être modifiés sans préavis. IBM ne sera en aucun cas
responsable de tout dommage résultant de l'utilisation de cette documentation.
Aucun élément de cette documentation ne constitue une garantie d'IBM (ou de ses
fournisseurs) ou ne modifie les dispositions et les conditions du contrat de licence
applicable au logiciel IBM.
Le présent document peut contenir des inexactitudes ou des coquilles. Ce
document est mis à jour périodiquement. Chaque nouvelle édition inclut les mises
à jour. IBM peut, à tout moment et sans préavis, modifier les produits et logiciels
décrits dans ce document.
IBM pourra utiliser ou diffuser, de toute manière qu'elle jugera appropriée et sans
aucune obligation de sa part, tout ou partie des informations qui lui seront
fournies.
Les références à des sites Web non IBM sont fournies à titre d'information
uniquement et n'impliquent en aucun cas une adhésion aux données qu'ils
contiennent. Les éléments figurant sur ces sites Web ne font pas partie des
éléments du présent produit IBM et l'utilisation de ces sites relève de votre seule
responsabilité.
Les informations concernant des produits non-IBM ont été obtenues auprès des
fournisseurs de ces produits, par l'intermédiaire d'annonces publiques ou via
d'autres sources disponibles. IBM n'a pas testé ces produits et ne peut pas
confirmer avec exactitude les performances, la compatibilité ou toutes autres
déclarations relatives aux produits non fournis par IBM. Toute question concernant
les performances de produits non-IBM doit être adressée aux fournisseurs de ces
produits.
Ces informations sont fournies uniquement à titre de planification. Elles sont
susceptibles d'être modifiées avant la mise à disposition des produits décrits.
141
Marques
Les termes qui suivent sont des marques d'International Business Machines
Corporation aux Etats-Unis et/ou dans certains autres pays :
AIX
DataBlade
DB2
Express
IBM
Informix
iSeries
MQSeries
Passport Advantage
SupportPac
Tivoli
WebSphere
Intel, le logo Intel, Intel Inside®, le logo Intel Inside, Intel® Centrino®, le logo Intel
Centrino, Celeron®, Intel® Xeon®, Intel SpeedStep®, Itanium® et Pentium sont des
marques d'Intel Corporation ou de ses filiales aux Etats-Unis et dans certains
autres pays.
Java ainsi que tous les logos et toutes les marques incluant Java sont des marques
de Sun Microsystems, Inc. aux Etats-Unis et/ou dans certains autres pays.
Linux est une marque de Linus Torvalds aux Etats-Unis et/ou dans certains autres
pays.
Microsoft, Windows, Windows NT® et le logo Windows sont des marques de
Microsoft Corporation aux Etats-Unis et/ou dans certains autres pays.
UNIX est une marque de The Open Group aux Etats-Unis et/ou dans certains
autres pays.
Les autres noms de sociétés, de produits et de services peuvent appartenir à des
tiers.
142
143

Centre de documentation de WebSphere Remote Server

Transcription

Documents pareils

Developpeur JAVA J2EE Junior CANADA

WebSphere Application Server V8.5 Administration

PHP pour développeurs IBM i (AS/400)

Recrutement d`un Technicien d`Exploitation Informatique Société

Formation websphere application server

TS 2003 Server

Formation websphere application server

Service Registry and Repository Guide de démarrage rapide

Livre blanc haute disponibilité IBM i - AS400

Service Registry and Repository Guide de démarrage rapide