WebSphere Remote Server Information Center Version 7.1.1

Transcription

WebSphere WebSphere® Remote Server
®
Version 7.1.1
IBM WebSphere Remote Server
Information Center Version 7.1.1
򔻐򗗠򙳰
Ausgabe November 2010
Diese Veröffentlichung ist eine Übersetzung des Handbuchs
IBM WebSphere Remote Server Version 7.1.1 Remote Server Information Center,
herausgegeben von International Business Machines Corporation, USA
© Copyright International Business Machines Corporation 2004, 2010
© Copyright IBM Deutschland GmbH 2010
Informationen, die nur für bestimmte Länder Gültigkeit haben und für Deutschland, Österreich und die Schweiz
nicht zutreffen, wurden in dieser Veröffentlichung im Originaltext übernommen.
Möglicherweise sind nicht alle in dieser Übersetzung aufgeführten Produkte in Deutschland angekündigt und verfügbar; vor Entscheidungen empfiehlt sich der Kontakt mit der zuständigen IBM Geschäftsstelle.
Änderung des Textes bleibt vorbehalten.
Herausgegeben von:
SW TSC Germany
Kst. 2877
November 2010
Inhaltsverzeichnis
Kapitel 1. Produktübersicht . . . . . . 1
Neuerungen in diesem Release . . . . . .
WebSphere Remote Server-Editionen . . . .
WebSphere Remote Server-Installationsprogramm
staller) . . . . . . . . . . . . . .
Systems Management Accelerators . . . . .
Filialrechner (ISPs) . . . . . . . . . .
Unternehmensserver . . . . . . . . . .
Zusätzliche Komponenten . . . . . . . .
. .
. .
(In. .
. .
. .
. .
. .
2
2
4
5
6
6
6
Kapitel 2. Installation und Implementierung . . . . . . . . . . . . . . . . 9
Hardware- und Softwarevoraussetzungen . . . . 9
Hardwarevoraussetzungen . . . . . . . . 10
Softwarevoraussetzungen . . . . . . . . . 11
Produkt installieren. . . . . . . . . . . . 12
IBM WebSphere Remote Server installieren . . . 12
Entwicklungsumgebung installieren . . . . . 14
WebSphere Remote Server über Remotezugriff installieren . . . . . . . . . . . . . . 17
Eingabefelder in Deployment Wizard . . . . . 20
Unbeaufsichtigte Installation. . . . . . . . 29
Installation prüfen . . . . . . . . . . . . 30
Installationsprotokolldateien . . . . . . . . 30
WebSphere Application Server prüfen . . . . 30
WebSphere MQ prüfen . . . . . . . . . 30
IBM HTTP Server prüfen . . . . . . . . . 31
DB2 Workgroup Server Edition prüfen . . . . 31
Informix Growth Edition prüfen . . . . . . 32
WebSphere sMash prüfen. . . . . . . . . 33
IBM Tivoli Monitoring-Agenten installieren und implementieren . . . . . . . . . . . . . . 34
Agentenunterstützungsdateien installieren . . . 34
Tivoli Monitoring-Überwachungsagenten implementieren . . . . . . . . . . . . . . 36
Deinstallation. . . . . . . . . . . . . . 51
Kapitel 3. Aktualisierung oder Migration
durchführen . . . . . . . . . . . . 55
Aktualisierungsstrategie . . . . . . . . . .
WebSphere Remote Server-Fixpacks und vorläufige
Fixes . . . . . . . . . . . . . . . .
Tivoli Provisioning Manager - Remote Management
Agent Bridge . . . . . . . . . . . . . .
Installationsvoraussetzungen . . . . . . .
TPM-RMA-Installation konfigurieren . . . . .
Softwareverteilung für TPM-RMA . . . . . .
Remote Management Agent V2.6 Bridge . . . . .
Migration . . . . . . . . . . . . . . .
Migration auf 7.1.1 . . . . . . . . . . .
Kapitel 4. Verwaltung
55
55
58
58
59
60
61
63
64
WebSphere Remote Server steuern . . . . . . .
Ereignisse überwachen . . . . . . . . . .
JMX-Ereignislistener verwenden . . . . . .
WebSphere Remote Server Data Provider aktivieren . . . . . . . . . . . . . . . .
WebSphere Remote Server Data Provider für die
Ereignisüberwachung konfigurieren . . . . .
WebSphere MQ-Nachrichtencontroller . . . . .
WebSphere MQ-Nachrichtencontroller installieren
WebSphere MQ Message Controller konfigurieren
Alternativen zum Nachrichtencontroller . . . .
Kennwortmanagement mit Tivoli Provisioning Manager-Workflows . . . . . . . . . . . .
IBM Tivoli License Compliance Manager installieren
und aktivieren . . . . . . . . . . . . .
Sicherheitsaspekte . . . . . . . . . . . .
67
71
71
74
75
80
80
81
83
84
88
88
Kapitel 5. Erweiterung . . . . . . . . 95
Lösung erweitern . . . . . . . . . . . . 95
WebSphere sMash . . . . . . . . . . . . 96
Musterlösung erstellen . . . . . . . . . . 97
Muster erstellen . . . . . . . . . . . . 97
Musterlösung für unbeaufsichtigte Installation
vorbereiten . . . . . . . . . . . . . 100
Musterlösung ändern. . . . . . . . . . 100
WebSphere Remote Server mit einer WebSphereMusteranwendung erweitern . . . . . . . . 101
Erläuterung des Mustercodes . . . . . . . 102
Musterlösung 'PlantsByWebSphere' verwenden 109
Eigene Lösungen entwickeln . . . . . . . 110
Anwendung erstellen . . . . . . . . . . . 117
Implementierung über Remotezugriff mit Tivoli
Provisioning Manager vorbereiten . . . . . . 119
WebSphere Remote Server- und ISP-Anwendungen
steuern . . . . . . . . . . . . . . . 121
Kennwortmanagement für das Verwalten von Benutzeranwendungen erweitern . . . . . . . 126
Kapitel 6. Fehlerbehebung und Unterstützung . . . . . . . . . . . . . 129
IBM Support Assistant installieren und verwenden
Log Collector . . . . . . . . . . . . .
Workflow von Log Collector verwenden . . .
Tipps zur Fehlerbehebung . . . . . . . . .
129
130
130
131
Kapitel 7. Referenzinformationen . . . 139
Allgemeine Produktinformationen
White Papers . . . . . . .
Bemerkungen und Marken . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 139
. 140
. 140
. . . . . . . . 67
iii
iv
Kapitel 1. Produktübersicht
IBM® WebSphere Remote Server ist eine der führenden SOA-Plattformen (Service
Oriented Architecture) für fern verwaltete, verteilte Umgebungen und speziell für
die Integration und Unterstützung von bisherigen, aktuellen und zukünftigen Einheiten und Anwendungen der Geschäftsebene konzipiert.
Als zentrale Komponente für IBM Retail Integration Framework bietet WebSphere
Remote Server die Basis für Innovationen in Geschäftsumgebungen, in denen der
Kundenkontakt ebenso wie Selbstbedienungstechnologien zur Vermittlung einer
differenzierten Serviceumgebung für den Kunden von großer Bedeutung sind.
WebSphere Remote Server stellt eine Plattform für die Erstellung, Assemblierung,
Implementierung und Verwaltung dieser Lösungen der nächsten Generation bereit,
die Unterstützung für Branchenstandards und Schutz vorhandener Lösungen bietet
und eine vollwertige Plug-and-Play-Plattform mit der Nutzung von J2EE-Middlewaretechnologien darstellt.
WebSphere Remote Server besteht aus einer Sammlung von IBM Middlewareprodukten und ist für die Installation auf einem Server in einem Geschäft vorgesehen.
Diese Server werden als Filialrechner (In-store Processors, ISPs) bezeichnet.
Abb. 1 veranschaulicht an einem Beispiel, wie eine Geschäftsumgebung mit mehreren fernen Filialrechnern (ISPs) aussehen könnte. Jeder ISP tauscht Daten mit einem zentralen Unternehmensserver aus. Die Geschäfte befinden sich an unterschiedlichen Standorten und verfügen jeweils über einen ISP, auf dem WebSphere
Remote Server ausgeführt wird.
Unternehmen
Unternehmensserver
ISP
Geschäft 1
I SP
Geschäft 2
I SP
Geschäft 3
I SP
…
Geschäft N
Abbildung 1. Muster für eine Umgebung mit mehreren fernen ISPs
1
Neuerungen in diesem Release
In diesem Abschnitt werden neue funktionale Erweiterungen und Komponenten
beschrieben, die im Lieferumfang von IBM WebSphere Remote Server 7.1.1 enthalten sind.
Funktionale Erweiterungen und Features
v Upgrades für Middlewareprodukte und Betriebssysteme
v Unterstützung für automatisierte individuelle Middlewaremigration sowie vollständige Produktmigration
v Unterstützung für Microsoft® Windows® 7 (32- und 64-Bit)
Anmerkung: Einige der Produkte im WebSphere Remote Server-Produktpaket
unterstützen Windows 7 (32-Bit und 64-Bit) nicht; einige Produkte
unterstützen nur die 32-Bit-Version von Windows 7.
v Unterstützung für SUSE Linux® Enterprise Server 10.3
v Unterstützung für Windows XP Professional mit Service-Pack 3
Verfügbare Komponenten
WebSphere Remote Server 7.1.1 enthält die folgenden Komponenten:
v IBM Retail Store Server Starter Edition
v
v
v
v
v
IBM Retail Store Server Starter Edition mit Informix Database
IBM Retail Store Server Advanced Edition
IBM Retail Store Server Advanced Edition mit Informix Database
IBM Tivoli Provisioning and Monitoring Add On for 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
Weitere Informationen zu den einzelnen Komponenten finden Sie im Abschnitt
„WebSphere Remote Server-Editionen”.
Anmerkung: Bei den Versionen 7.0, 7.1 und 7.1.1 können der Produktname WebSphere Remote Server und der Editionsname IBM Retail Store Server
gleichbedeutend verwendet werden.
WebSphere Remote Server-Editionen
IBM WebSphere Remote Server V7.1.1 enthält die im vorliegenden Abschnitt beschriebenen Editionen und Komponenten. Die Lizenzbedingungen (für die jeweils
verwendete Edition von WebSphere Remote Server) enthalten Informationen zu
den Einschränkungen hinsichtlich des Produkts und der Umgebung.
Anmerkung: Bei den Versionen 7.0, 7.1 und 7.1.1 können der Produktname WebSphere Remote Server und der Editionsname IBM Retail Store Server
gleichbedeutend verwendet werden.
IBM Retail Store Server Starter Edition
IBM Retail Store Server Starter Edition bietet einen Einstieg in WebSphere
Remote Server und umfasst Folgendes:
v IBM WebSphere MQ V7.0.1.2
2
v DB2 Limited Use Workgroup Edition V9.7 Fixpack 2 (eingeschränkte
Funktionalität)
v IBM WebSphere Application Server Network Deployment V7.0.0.9 (eingeschränkte Funktionalität)
v IBM HTTP Server V7.0.0.9
v Systems Management Accelerators
v IBM WebSphere sMash V1.1.1.5
v IBM Software Assembly Toolkit V3.2.2
IBM Retail Store Server Starter Edition mit Informix Database
IBM Retail Store Server Starter Edition mit Informix Database bietet ebenfalls einen Einstieg in WebSphere Remote Server und umfasst Folgendes:
v IBM Informix Growth Edition 11.50.xC7 (Details siehe „Hardware- und
Softwarevoraussetzungen” auf Seite 9)
v IBM WebSphere Application Server Network Deployment V7.0.0.9 (eingeschränkte Funktionalität)
v Systems Management Accelerators
IBM Retail Store Server Advanced Edition
IBM Retail Store Server Advanced Edition bietet den maximalen Leistungsumfang mit allen Funktionen von IBM Retail Store Server Starter Edition
und umfasst die gesamte Funktionalität von DB2 Workgroup Server Edition V9.7 Fixpack 2 und IBM WebSphere Application Server Network Deployment V7.0.0.9.
IBM Retail Store Server Advanced Edition mit Informix Database
IBM Retail Store Server Advanced Edition mit Informix Database bietet
den maximalen Leistungsumfang mit allen Funktionen von IBM Retail
Store Server Starter Edition mit Informix Database und umfasst die gesamte Funktionalität von Informix Growth Edition 11.50.xC7 und IBM WebSphere Application Server Network Deployment V7.0.0.9.
IBM Tivoli Provisioning and Monitoring Add On for IBM Retail Store Server
Mit IBM Tivoli Provisioning and Monitoring Add On for IBM Retail Store
Server werden Überwachungs- und Bereitstellungsfunktionen zur Starter
Edition bzw. Advanced Edition hinzugefügt. Dieses Add-on umfasst Folgendes:
v IBM Tivoli Provisioning Manager V7.2
v IBM Tivoli Composite Application Manager for Applications V6.2.3
– IBM Tivoli Monitoring V6.2.2 Fixpack 1
– IBM Tivoli
– IBM Tivoli
se V6.2.1
– IBM Tivoli
– IBM Tivoli
V7.1
– IBM Tivoli
V7.0.1
Composite Application Manager Agent for DB2 V6.2.2
Composite Application Manager Agent for Oracle DatabaComposite Application Manager Agent for J2EE V6.2.0.4
Composite Application Manager Agent for HTTP Servers
Composite Application Manager Agent for WebSphere MQ
3
– IBM Tivoli Composite Application Manager Agent for WebSphere
Broker V7.0.1
– IBM Tivoli Composite Application Manager Configuration Agent for
WebSphere MQ V7.0.1
– IBM Tivoli Composite Application Manager Agent for WebSphere Applications V7.1
Anmerkung:
v Vor der Installation dieses Add-ons muss die Starter Edition oder die Advanced Edition installiert sein.
v Tivoli Provisioning Manager V7.2 bietet keine Unterstützung für Windows 7 Ultimate Edition.
IBM WebSphere Central Site Server
WebSphere Central Site Server umfasst das volle Nutzungsrecht für WebSphere MQ 7.0.1.2, DB2 Workgroup Server Edition V9.7 Fixpack 2 und
WebSphere Application Server Network Deployment V7.0.0.9 mit einer Lizenz, die für eine Implementierung auf Unternehmensebene geeignet ist.
IBM WebSphere Message Broker Retail Store Edition
IBM WebSphere Message Broker Retail Store Edition bietet eine Reihe verschiedener Optionen für die Implementierung eines universellen Enterprise
Service Bus für die Konnektivität und Umsetzung in heterogenen IT-Umgebungen.
IBM WebSphere Enterprise Service Bus Retail Store Edition
IBM WebSphere Enterprise Service Bus Retail Store Edition unterstützt die
Integration von serviceorientierten, nachrichtenorientierten und ereignisgesteuerten Technologien zur Bereitstellung einer standardisierten MessagingInfrastruktur für Unternehmen, die eine rasche Aktivierung eines Enterprise Service Bus wünschen.
WebSphere Remote Server-Installationsprogramm (Installer)
Mit dem Installationsprogramm, einem Teil von Systems Management Accelerators,
wird eine mit IBM Software Assembly Toolkit erstellte Lösung installiert.
Die Lösung besteht aus einer Musteranwendung, IBM Middleware und einer auf
Eclipse basierenden Entwicklungsumgebung namens Software Assembly Toolkit
Developer. Kunden, ISVs und Systemintegratoren können die Entwicklungsumgebung dazu verwenden, die Musteranwendung zu ersetzen und eine eigene Lösung
zu erstellen.
Das Installationsprogramm bietet vier Installationsoptionen:
v Retail Store Server 7.1.1 Runtime for Windows/Linux installieren: Hiermit
wird Retail Store Server 7.1.1 Runtime mit IBM Middlewareprodukten und Musteranwendungen für WebSphere installiert.
v Von WebSphere Remote Server 6.1 oder 6.2.x migrieren: Hiermit wird ein Upgrade für eine vorhandene Installation von WebSphere Remote Server 6.1 oder
6.2.x Runtime auf die neuesten Versionen der Retail Store Server 7.1.1-Middlewareprodukte durchgeführt.
Anmerkung:
– Diese Task ist nur auf den unterstützten Migrationsplattformen
verfügbar. Details hierzu finden Sie im Abschnitt „Migration”
auf Seite 63.
4
– Wenn Sie eine Migration von WebSphere Remote Server 6.1
oder 6.2.x durchführen, können Sie nur auf WebSphere Remote
Server-Editionen mit DB2 migrieren.
v Von WebSphere Remote Server 7.0 oder 7.1 migrieren: Hiermit wird ein Upgrade für eine vorhandene Installation von WebSphere Remote Server 7.0 oder
7.1 Runtime auf die neuesten Versionen der Retail Store Server 7.1.1-Middlewareprodukte durchgeführt.
Anmerkung:
– Diese Task ist nur für Benutzer auf den unterstützten Migrationsplattformen verfügbar. Details hierzu finden Sie im Abschnitt „Migration” auf Seite 63.
– Wenn Sie eine Migration von WebSphere Remote Server-Editionen mit DB2 durchführen, können Sie nur auf WebSphere Remote Server V7.1.1-Editionen mit DB2 migrieren. Ebenso
können Sie bei einer Migration von WebSphere Remote ServerEditionen mit Informix Database nur auf WebSphere Remote
Server V7.1.1Editionen mit Informix Database migrieren.
v WebSphere Remote Server 7.1.1-Lösungsentwicklungsumgebung installieren:
Die Lösungsentwicklungsumgebung besteht aus IBM Software Assembly Toolkit
3.2.2, einem vollständigen Projektarbeitsbereich und den Installationsimages für
alle Middlewareprodukte.
Systems Management Accelerators
Systems Management Accelerators ist eine Gruppe von Tools, die im Produktpaket
aller IBM Retail Store Server-Editionen sowie im Produktpaket von IBM WebSphere Central Site Server enthalten sind.
Mit Systems Management Accelerators (oder Accelerators) stehen die folgenden
Funktionen zur Verfügung:
v Lösungsinstallation: Mithilfe der Systems Management Accelerators-DVDs können Sie die IBM Softwareprodukte als einzelne Lösung installieren und müssen
nicht für jedes Produkt eine separate Installation ausführen.
v Automatisierte Migration: Die Systems Management Accelerators-DVDs bieten
die Möglichkeit, eine automatisierte Migration von früheren IBM WebSphere Remote Server-Releases durchzuführen.
v Deinstallation: Es steht ein Tool zur Verfügung, mit dem die gesamte Lösung mit
einem einzigen Befehl deinstalliert werden kann.
v Entwicklungsumgebung: Die Entwicklungsumgebung ermöglicht Ihnen das Erstellen einer eigenen angepassten Lösung auf einer DVD. Sie können Ihre eigene
Anwendung zum WebSphere Remote Server-Software-Stack hinzufügen, nicht
benötigte Komponenten entfernen und Konfigurationen anpassen.
v Installation über Remotezugriff: Die Tivoli-Softwarepakete, die mit IBM Tivoli
Provisioning Manager bereitgestellt werden, ermöglichen Ihnen die Implementierung der WebSphere Remote Server-Software auf mehreren Tausend fernen Servern in Geschäften bzw. Filialen.
v Verteilung an Einheiten im Geschäft: Das Dienstprogramm Tivoli Provisioning
Manager-Remote Management Agent (TPM-RMA) Bridge wird bereitgestellt, um
die Distanz zwischen Tivoli Provisioning Manager und IBM Remote Management Agent zu überbrücken.
5
v Remotesteuerung: Sie können Befehlszeilentools dazu verwenden, die auf dem
Filialserver ausgeführten Middlewareprodukte zu starten und zu stoppen, sowie
dazu, den Status dieser Produkte zu überprüfen.
v Kennwortmanagement: Mit Tivoli Provisioning Manager können Sie die Kennwörter für die Benutzer-IDs auf den Filialservern verwalten.
v Protokollerfassung: Es steht ein Tool zur Verfügung, mit dem Sie Protokolle suchen und erfassen können, die an die IBM Kundenunterstützung weitergeleitet
werden, falls Sie Serviceunterstützung benötigen.
Anmerkung:
v Remote Management Agent ist nicht Teil von WebSphere Remote
Server.
v Sie müssen IBM Tivoli Provisioning and Monitoring Add On for
IBM Retail Store Server erwerben, um die funktionalen Erweiterungen von Tivoli zu nutzen.
Filialrechner (ISPs)
Ein Filialrechner (In-store Processor, ISP) ist ein Server im Geschäft.
Dieser Server führt ein Linux- oder Windows-Betriebssystem aus und ist mit verschiedenen Einheiten verbunden wie beispielsweise mit Point-of-Sale-Controllern,
Selbstbedienungsterminals, Selbstbedienungskassen und anderen Einheiten. Auf
dem ISP wird die gesamte erforderliche Software für die Geschäftsoperationen ausgeführt. WebSphere Remote Server ist auf dem Filialrechner als Basisplattform für
andere Anwendungen installiert.
Unternehmensserver
Der Unternehmensserver wird als zentraler Verwaltungspunkt für alle Filialrechner
(ISPs) eingesetzt.
Zu den Produktangeboten für den Unternehmensserver gehören beispielsweise
IBM WebSphere Central Site Server und IBM Tivoli Provisioning and Monitoring
Add On for IBM Retail Store Server.
Auf dem Unternehmensserver werden Softwareinstallationen gestartet und Überwachungsdaten empfangen. Nachdem IBM WebSphere Remote Server mithilfe von
Accelerators auf allen ISPs installiert wurde, können die meisten Managementmaßnahmen für die ISPs über Remotezugriff ausgeführt werden.
Der Unternehmensserver ist nur erforderlich, um die nötige Software zum Einleiten von Installationen auf den ISPs über Accelerators auszuführen. Beispiele: FTPClient und Telnet-Client.
Zusätzliche Komponenten
Für IBM WebSphere Remote Server werden zwei zusätzliche Komponenten bereitgestellt.
Diese Komponenten müssen in den Geschäften, getrennt von WebSphere Remote
Server und auf einer separaten physischen Maschine oder virtuellen Partition installiert werden. Weitere Informationen zu diesen Komponenten erhalten Sie über
die folgenden Links:
6
v IBM WebSphere Enterprise Service Bus Retail Store Edition Version 7.0: Unterstützt die Integration von serviceorientierten, nachrichtenorientierten und ereignisgesteuerten Technologien zur Bereitstellung einer standardisierten MessagingInfrastruktur für Unternehmen, die eine rasche Aktivierung eines Enterprise
Service Bus wünschen.
v IBM WebSphere Message Broker Retail Store Edition Version 7.0: Stellt eine Reihe von Optionen für die Implementierung eines universellen Enterprise Service
Bus für die Konnektivität und Umsetzung in heterogenen IT-Umgebungen bereit.
7
8
Kapitel 2. Installation und Implementierung
Gehen Sie wie in den folgenden Themen beschrieben vor, um die Installation vorzubereiten, IBM WebSphere Remote Server und die Entwicklungsumgebung zu installieren, die Installation zu prüfen und die Agenten zu implementieren.
WebSphere Remote Server Solution Installer kann für die Installation von WebSphere Remote Server V7.1.1 oder für die Migration auf WebSphere Remote Server
V7.1.1 von früheren Releases verwendet werden. Weitere Informationen zu den
Migrationsszenarios finden Sie im Abschnitt Kapitel 3, „Aktualisierung oder Migration durchführen”, auf Seite 55.
Darüber hinaus können Sie auch die Entwicklungsumgebung der WebSphere Remote Server-Lösung installieren. Sie können mit der Entwicklungsumgebung angepasste Lösungen auf der Basis von IBM WebSphere Remote Server entwickeln.
Anmerkung: Die Entwicklungsumgebung wird auf den folgenden Plattformen
nicht unterstützt:
v Windows Embedded POSReady 2009
v Windows 7
v Windows 2008 Server
Hardware- und Softwarevoraussetzungen
In diesem Abschnitt werden die Hardware- und Softwarevoraussetzungen für IBM
WebSphere Remote Server und die unterstützten Komponenten beschrieben.
Tipp: Eine aktuelle Liste der unterstützten Hardware- und Softwareplattformen für
alle Editionen von WebSphere Remote Server finden Sie auf der Seite mit
den Systemvoraussetzungen und im Dokument mit den unterstützten Betriebssystemen.
Softwarepaket
WebSphere Remote Server bündelt und unterstützt die folgenden IBM Produktversionen bei allgemeiner Verfügbarkeit:
v IBM WebSphere Application Server Network Deployment V7.0.0.9
v DB2 Limited Use Workgroup Edition V9.7 Fixpack 2 (in Starter Edition verfügbar), DB2 Workgroup Server Edition V9.7 Fixpack 2 (in Advanced Edition verfügbar) oder IBM Informix Growth Edition 11.50.xC71
1. Die Variable x steht für einen der folgenden Buchstaben, die eine jeweils eine Plattform darstellen:
– F = 64-Bit auf beliebiger UNIX®-/Linux-Plattform
– H = 32-Bit auf beliebiger HP 11.x-Plattform (kann auch unter HP 11.x 64-Bit ausgeführt werden)
– T = Windows-Plattformen
– U = 32-Bit auf beliebiger UNIX-/Linux-Plattform
Weitere Informationen finden Sie in der Übersicht für Informix-Plattformen.
9
Bevor Sie mit der Installation beginnen, informieren Sie sich über die Hardwareund Softwarevoraussetzungen für den Filialrechner (ISP) und die Unternehmensserver.
Separate Komponenten
Die beiden folgenden zusätzlichen Komponenten sind mit WebSphere Remote Server verfügbar:
v IBM WebSphere Enterprise Service Bus Retail Store EditionV7.0
v IBM WebSphere Message Broker Retail Store EditionV7.0
Die folgende Software ist Teil von IBM Tivoli Provisioning and Monitoring Add
On for IBM Retail Store Server:
v IBM Tivoli Provisioning Manager V7.2
v IBM Tivoli Composite Application Manager for Applications V6.2.3
– IBM Tivoli Monitoring V6.2.2 Fixpack 1
–
–
–
–
–
–
IBM Tivoli Composite Application
V7.0.1
– IBM Tivoli Composite Application
Sphere MQ V7.0.1
– IBM Tivoli Composite Application
tions V7.1
Manager Agent
Manager Agent
Manager Agent
Manager Agent
Manager Agent
Manager Agent
for
for
for
for
for
for
DB2 V6.2.2
Oracle Database V6.2.1
J2EE V6.2.0.4
HTTP Servers V7.1
WebSphere MQ V7.0.1
WebSphere Broker
Manager Configuration Agent for WebManager Agent for WebSphere Applica-
Hardwarevoraussetzungen
Die folgenden Hardwaremindestvoraussetzungen müssen von Filialrechnern (Instore Processors, ISPs) und Unternehmensservern erfüllt werden.
Filialrechner (ISP)
v IBM PC-Server mit 32-Bit-Prozessor von Intel® Pentium® 500 MHz (empfohlen
werden 2 GHz oder höher)
v 2 GB Hauptspeicher
v 12 GB Plattenspeicher
Unternehmensserver
Für WebSphere Remote Server sind mehrere Unternehmensserver erforderlich. Für
den Unternehmensserver, auf dem Tivoli Provisioning Manager ausgeführt wird,
gelten die folgenden Hardwaremindestvoraussetzungen:
10
v IBM PC-Server mit 32-Bit-Prozessor von Intel Pentium 500 MHz (empfohlen
werden 2 GHz oder höher)
v 2 GB Hauptspeicher
v 12 GB Plattenspeicher
Softwarevoraussetzungen
In diesem Abschnitt sind die Softwarevoraussetzungen für den Filialrechner (ISP)
und den Unternehmensserver von IBM WebSphere Remote Server aufgeführt.
Filialrechner
Tivoli-Umgebung
Installieren Sie Tivoli Common Agent auf jedem ISP wie im IBM Tivoli Provisioning Manager Information Center beschrieben.
Anmerkung: Tivoli Provisioning Manager V7.2 bietet keine Unterstützung für
Windows 7 Ultimate Edition.
Nicht-Tivoli-Umgebung
Die von WebSphere Remote Server V7.1.1 unterstützten Betriebssysteme sind in
der folgenden Tabelle aufgeführt.
Anmerkung:
v Das Betriebssystem Microsoft Windows Embedded POSReady 2009
ist nur in der 32-Bit-Version verfügbar.
v Windows XP Professional mit Service-Pack 3 ist nur in der 32-BitVersion verfügbar.
Tabelle 1. Unterstützte Software für den Filialrechner
Betriebssystem
Unterstützte Versionen
Linux
v SUSE Linux Enterprise Server 10.3
v SUSE Linux Enterprise Server 11
v Red Hat Enterprise Linux 5.3
Microsoft Windows
v Windows 2003 Server Standard Edition
oder Enterprise Edition mit Service-Pack 2
v Windows 2003 Server R2 Standard Edition
oder Enterprise Edition mit Service-Pack 2
v Windows XP Professional mit ServicePack 2 (nur 64-Bit)
v
v
Windows XP Professional mit ServicePack 3
Windows 7
11
Stellen Sie sicher, dass die folgenden Umgebungen vorhanden sind:
v Eine Umgebung zum Empfangen von Dateien, z. B. ein FTP-Server.
v Eine Umgebung zum Ausführen von fernen Scripts, z. B. ein SSH-Server.
Unternehmensserver
Tivoli-Umgebung
Weitere Informationen zur Installation von Tivoli Provisioning Manager finden Sie
im IBM Tivoli Provisioning Manager Information Center.
Nicht-Tivoli-Umgebung
Stellen Sie sicher, dass die folgenden Umgebungen vorhanden sind:
v Eine Umgebung zum Verteilen von Dateien, z. B. ein FTP-Server.
v Eine Umgebung für Verbindungen zu fernen Servern, z. B. ein SSH-Client.
Produkt installieren
Gehen Sie wie in den nachstehenden Themen beschrieben vor, um IBM WebSphere
Remote Server und die Entwicklungsumgebung zu installieren.
IBM WebSphere Remote Server installieren
Gehen Sie wie in diesem Abschnitt beschrieben vor, um IBM WebSphere Remote
Server zu installieren.
Vorbereitende Schritte
Wenn Sie die erforderliche Middleware bereits ganz oder teilweise aus einer früheren Version von WebSphere Remote Server installiert haben, führen Sie die Installation anhand der Anweisungen in „Migration” auf Seite 63 durch.
Sie müssen den Hostnamen und die IP-Adresse in die Hostdatei des Computers
eingeben, auf dem WebSphere Remote Server installiert werden soll. Wenn Sie den
Hostnamen und die IP-Adresse nicht in die Hostdatei eingeben, schlägt die Installation fehl. Die Hostdatei befindet sich im Verzeichnis /etc/hosts unter Linux bzw.
im Verzeichnis %SYSTEMROOT%\System32\drivers\etc\hosts unter Windows. Der
Hostname darf keine Silbentrennungsstriche (-) enthalten. Wenn der Hostname einen Silbentrennungsstrich (-) enthält, schlägt die Installation fehl.
Wenn Sie die Musteranwendungen für WebSphere installieren und das Muster
'Trade Performance Benchmark Sample for IBM WebSphere Remote Server' auf einer Workstation mit der Landessprache Deutsch benötigen, müssen Sie zuerst ein
Upgrade für IBM WebSphere Application Server auf Version 7.0.0.11 durchführen.
Auf der WebSphere Application Server-Unterstützungsseite erhalten Sie Informationen zum Download von WebSphere Application Server Version 7.0.0.11.
Wenn Sie bei einer Installation auf einem Windows Embedded POSReady 2009oder Windows XP Professional-Betriebssystem IPv6 verwenden möchten, müssen
Sie die folgenden Schritte ausführen, um einen neuen Aliasnamen für den IBM Informix Growth Edition-Datenbankserver zu erstellen, dem neuen, zusätzlichen Datenbankservernamen eine IPv4-Adresse zuzuordnen und dem vorhandenen Informix Growth Edition-Datenbankservernamen eine IPv6-Adresse zuzuordnen:
12
1. Suchen Sie in der Datei onconfig im Verzeichnis $INFORMIXDIR/etc nach dem
Konfigurationsparameter DBSERVERALIASES und fügen Sie diesem einen neuen Aliasnamen hinzu.
2. Verwenden Sie das Dienstprogramm 'SetNet32', um dem vorhandenen, im Parameter DBSERVERNAME angegebenen Datenbankservernamen eine IPv6-Adresse und dem neuen, im Parameter DBSERVERALIASES angegebenen Aliasnamen eine IPv4-Adresse zuzuordnen.
a. Klicken Sie im Ordner mit den Client-SDK-Produkten doppelt auf
'SetNet32', um das Dienstprogramm 'SetNet32' zu öffnen.
b. Klicken Sie auf die Registerkarte Server Information, um die Seite Server
Information aufzurufen.
c. Wählen Sie im Feld IBM Informix Server den Datenbankservernamen aus,
der im Parameter DBSERVERNAME in der Datei onconfig angegeben ist.
d. Geben Sie in das Feld HostName die IPv6-Hostadresse ein.
e. Klicken Sie auf Apply.
f. Fügen Sie im Feld IBM Informix Server den neuen Datenbankservernamen
hinzu, der im Parameter DBSERVERALIASES in der Datei onconfig angegeben ist.
g. Geben Sie in das Feld HostName die IPv4-Hostadresse ein.
h. Ordnen Sie in den Feldern Protocolname, Service Name und Options die
dem Datenbankserver entsprechenden Werte zu, der im Parameter DBSERVERNAME angegeben ist.
i. Klicken Sie auf Apply.
j. Klicken Sie auf OK.
k. Führen Sie einen Neustart für Informix Growth Edition durch.
Vorgehensweise
1. Legen Sie die DVD mit dem Installationsprogramm von WebSphere Remote
Server für die entsprechende Plattform ein.
Hinweise:
v Auf 64-Bit-Betriebssystemen wird nur die Migration von WebSphere Remote Server V7.1 unterstützt.
v Unter Linux müssen Sie sich als Rootbenutzer anmelden, um die
Installation mit den Accelerators-DVDs durchzuführen.
v Unter Windows Embedded POSReady 2009 müssen Sie vor der
Installation von WebSphere Remote Server V7.1.1 die optionale
Komponente mit den Befehlszeilendienstprogrammen installieren. Wenn Sie diese optionale Komponente noch nicht installiert
haben, lesen Sie die entsprechenden Installationsanweisungen zu
Windows Embedded POSReady 2009.
Wenn beim Einlegen der DVD die Klickstartleiste (das Launchpad) von WebSphere Remote Server nicht automatisch geöffnet wird, führen Sie den Befehl
'launchpad.exe' unter Windows oder den Befehl 'launchpad.sh' unter Linux
auf der DVD aus. Die Klickstartleiste enthält nützliche Informationen und
Links zum Starten der Installation.
2. Wählen Sie in der Klickstartleiste die Installation von WebSphere Remote Server aus.
Wenn Sie den Link zur Installation von WebSphere Remote Server auswählen,
wird Deployment Wizard vorübergehend auf Ihrem Festplattenlaufwerk ins-
13
talliert. Nach Abschluss der Installation von Deployment Wizard wird dieser
automatisch gestartet und führt Sie durch die Installation von WebSphere Remote Server.
3. Klicken Sie auf I accept both the IBM and the non-IBM terms (Ich akzeptiere
die Bedingungen von IBM und anderen Anbietern), wenn Sie mit der Lizenzvereinbarung einverstanden sind, und klicken Sie dann auf Next, um fortzufahren.
4. Klicken Sie auf Next, wenn die Begrüßungsseite geöffnet wird, um mit der Installation fortzufahren.
5. Wählen Sie die Installation von IBM Retail Store Server 7.1.1 Runtime aus.
Weitere Informationen zu anderen Installationsoptionen finden Sie in den Abschnitten „Migration” auf Seite 63 und „Entwicklungsumgebung installieren”.
6. Komponenten für die Installation auswählen.
Wichtig:
v Beachten Sie bei der Installation von Informix Growth Edition,
dass es nur in einer NTFS-Partition installiert werden kann.
v IBM HTTP Server kann nur installiert werden, wenn auch WebSphere Application Server installiert wird.
v Musteranwendungen können nur installiert werden, wenn alle
anderen Komponenten ebenfalls installiert werden.
7. Geben Sie die erforderlichen und die optionalen Installationsparameter an,
wenn Sie von Deployment Wizard dazu aufgefordert werden.
Eine detaillierte Beschreibung der Felder finden Sie im Abschnitt „Felder für
die Laufzeitinstallation” auf Seite 20.
Anmerkung: Wenn Sie die WebSphere Application Server-Sicherheit auf einem Linux-Betriebssystem aktivieren möchten, müssen Sie bei
jedem Serverneustart WebSphere Application Server beenden.
8. Implementieren Sie die Installationstasks, nachdem Sie sie im Fenster mit der
Zusammenfassungsanzeige auf ihre Richtigkeit hin überprüft haben.
9. Prüfen Sie, ob die Implementierungstasks erfolgreich ausgeführt wurden.
Wenn alle Implementierungstasks ausgeführt wurden, ist im Fenster mit dem
Implementierungsstatus zu sehen, dass die Implementierung erfolgreich war.
Die detaillierten Nachrichten sowie das Hauptprotokoll können für weitere Informationen zur Implementierung zurate gezogen werden.
Prüfen Sie zum Lösen von Installationsfehlern die Installationsprotokolle und
verwenden Sie die Informationen im Abschnitt „Tipps zur Fehlerbehebung”
auf Seite 131.
10. Wenn Sie die Installation unter dem Betriebssystem Windows Embedded POSReady 2009 oder unter Windows XP ausgeführt haben, führen Sie einen Neustart für den Server durch, damit das Betriebssystem die Aktualisierungen
übernehmen kann.
Nächste Schritte
Installation prüfen.
Entwicklungsumgebung installieren
Gehen Sie wie in diesem Abschnitt beschrieben vor, um die IBM WebSphere Remote Server-Entwicklungsumgebung zu installieren.
14
Informationen zu diesem Vorgang
Die Entwicklungsumgebung besteht aus Software Assembly Toolkit und dem WebSphere Remote Server-Arbeitsbereich. Sie können optional WebSphere sMash installieren, um einen Übertragungsweg von Einheiten zu Back-End-Systemen mithilfe
von WebSphere MQ bereitzustellen.
Der Arbeitsbereich umfasst alle Projektdateien sowie die Implementierungspakete
(Installationsmedien für die Middlewareprodukte in Form einer .jar-Datei) für ein
bestimmtes Betriebssystem. Für die Entwicklung einer angepassten WebSphere Remote Server-Lösung müssen Sie das Toolkit für das Betriebssystem Ihrer Entwicklungsworkstation und den Arbeitsbereich für das Betriebssystem der einzelnen
Zielserver installieren. Das Toolkit muss vor dem Arbeitsbereich installiert werden.
Wenn das Betriebssystem Ihrer Entwicklungsworkstation mit dem Betriebssystem
der Zielserver übereinstimmt, können Sie den Arbeitsbereich zum selben Zeitpunkt
installieren. Die Arbeitsbereichs- und Implementierungspakete für eine vorgegebene Plattform sind auf der DVD von WebSphere Remote Server für die entsprechende Plattform verfügbar. Bei der plattformübergreifenden Entwicklung oder der Entwicklung auf zwei Plattformen müssen Sie den Arbeitsbereich von der
entsprechenden WebSphere Remote Server-DVD installieren.
Beispiel: Sie entwickeln auf einer Windows-Plattformworkstation, bei der Zielplattform handelt es sich jedoch um eine Linux-Plattform. Sie müssen zuerst Software
Assembly Toolkit von der DVD mit WebSphere Remote Server für Windows installieren. Zur Installation des WebSphere Remote Server-Arbeitsbereichs für Linux
führen Sie das Script WindowsSetup.exe von der DVD mit WebSphere Remote Server für Linux aus. Bei der Ausführung des Lösungsinstallationsprogramms für Linux auf einer Windows-Maschine ist die Installation des WebSphere Remote Server-Arbeitsbereichs die einzige verfügbare Option.
Zum Erstellen einer Lösung verwenden Sie das Installationsprogramm, um die
Entwicklungsumgebung unter einem Windows- oder Linux-Betriebssystem zu installieren. Nach der Installation der Entwicklungsumgebung müssen Sie Software
Assembly Toolkit Developer öffnen.
Anmerkung: Die Entwicklungsumgebung wird auf den folgenden Plattformen
nicht unterstützt:
v Windows 7
Vorgehensweise
Hinweise:
15
3.
4.
5.
6.
wird Deployment Wizard vorübergehend auf Ihrem Festplattenlaufwerk installiert. Nach Abschluss der Installation von Deployment Wizard wird dieser
Klicken Sie auf I accept both the IBM and the non-IBM terms (Ich akzeptiere
Klicken Sie auf Next, wenn die Begrüßungsseite geöffnet wird, um mit der Installation fortzufahren.
Wählen Sie die Installation der IBM Retail Store Server-Lösungsentwicklungsumgebung aus.
Geben Sie die zu installierenden Komponenten an. Dies sind die Komponenten Software Assembly Toolkit, WebSphere sMash und der IBM Retail Store
Server-Arbeitsbereich.
Anmerkung: Die Komponente WebSphere sMash ist in IBM WebSphere Central Site Server nicht verfügbar.
Details zu den einzelnen Feldern finden Sie im Abschnitt „Felder für die Installation der Entwicklungsumgebung” auf Seite 28.
7. Geben Sie die erforderlichen und die optionalen Installationsparameter an,
wenn Sie von Deployment Wizard dazu aufgefordert werden.
Wenn auf dem Server eine frühere Version von Software Assembly Toolkit installiert ist, wird das Software Assembly Toolkit, das in WebSphere Remote Server V7.1.1 enthalten ist, standardmäßig an einer neuen Speicherposition installiert. Die unterschiedlichen Versionen von Software Assembly Toolkit können
auf dem Server koexistieren.
Anmerkung: Unterschiedliche Versionen von IBM Software Assembly Toolkit
können koexistieren, gleichgeordnete Aktualisierungen oder Fixpacks jedoch nicht. Wenn Sie daher die Lösungsentwicklungsumgebung von WebSphere Remote Server V7.1.1 installieren,
während die Lösungsentwicklungsumgebung von WebSphere
Remote Server V7.1 bereits installiert ist, wird für Software Assembly Toolkit V3.2.1 automatisch ein Upgrade auf Software Assembly Toolkit V3.2.2 durchgeführt.
9. Prüfen Sie, ob die Implementierungstasks erfolgreich ausgeführt wurden.
10. Öffnen Sie Software Assembly Toolkit Developer.
Wählen Sie im Startmenü Alle Programme → IBM Software
Assembly Toolkit 3.2 → Software Assembly Toolkit Developer aus.
16
Führen Sie diesen Befehl aus: cd /opt/IBM/SAT/3.2/
SolutionEnabler./IRU_Developer.sh
Anmerkung: Bei einer Installation auf dem Betriebssystem SUSE Linux Enterprise Server 10.3 (64-Bit) kann Software Assembly Toolkit Developer nicht geöffnet werden. Informationen zur Behebung dieses
Problems finden Sie im Abschnitt „Software Assembly Toolkit
Developer kann unter SUSE Linux Enterprise Server 10.3 (64-Bit)
nicht geöffnet werden.” auf Seite 136 der Tipps zur Fehlerbehebung.
11. Beim Start von Software Assembly Toolkit Developer werden Sie in einem Dialogfenster aufgefordert, die Position des zu öffnenden Arbeitsbereichs anzugeben. Wählen Sie die Position aus, die während der Installation der Lösungsentwicklungsumgebung angegeben wurde, und klicken Sie anschließend auf
OK. Standardmäßig lautet die Arbeitsbereichsposition wie folgt:
C:\Program Files\IBM\SIF\workspace\wrs711
/opt/IBM/SIF/workspace/irss711
Anmerkung: Bei einer Installation unter dem Red Hat Enterprise Linux-64Bit-Betriebssystem sind beim Öffnen des Arbeitsbereichs zwei erwartete Ausnahmebedingungen in der Fehlerprotokollansicht
aufgeführt. Weitere Informationen hierzu finden Sie bei den Hinweisen zur Fehlerbehebung im Abschnitt „Software Assembly
Toolkit-Ausnahmebedingung nach Installation” auf Seite 136.
Wenn das Anwendungsfenster geöffnet wird, wird eine Begrüßungsseite
('Welcome') angezeigt.
12. Schließen Sie die Begrüßungsseite, um die Arbeitsumgebung und die Projekte
anzuzeigen, aus denen sich der Arbeitsbereich zusammensetzt.
Wenn Sie mit Software Assembly Toolkit Developer nicht vertraut sind, informieren Sie sich in der integrierten Hilfefunktion. Führen Sie dazu folgende
Schritte aus:
a. Wählen Sie in der Menüleiste von Software Assembly Toolkit Developer
die Optionen Help und Help Contents aus. Das Fenster 'Help - IBM Software Assembly Toolkit Developer' wird geöffnet.
b. Klicken Sie im Fenster Contents auf den Link für Using the Software Assembly Toolkit Developer.
Nächste Schritte
Weitere Informationen zu Software Assembly Toolkit finden Sie im Software Assembly Toolkit Information Center.
WebSphere Remote Server über Remotezugriff installieren
IBM WebSphere Remote Server kann über Remotezugriff mit IBM Tivoli Provisioning Manager installiert werden. Der WebSphere Remote Server-Laufzeitstack kann
über Remotezugriff auf einer Maschine installiert werden, auf der keine vorhergehende Version von WebSphere Remote Server installiert ist.
Wichtig: Bevor Sie beginnen, muss Tivoli Provisioning Manager 7.2 auf einem Server und Tivoli Softwarepaketeditor auf einer separaten Windows-Entwicklungsmaschine installiert sein. Informationen zu Tivoli Provisioning
Manager 7.2 finden Sie im Tivoli Provisioning Manager Information Center.
17
Die im Folgenden beschriebenen Schritte müssen für eine Installation von WebSphere Remote Server über Remotezugriff ausgeführt werden. In den jeweiligen
Abschnitten finden Sie ausführliche Informationen zur Ausführung der einzelnen
Schritte.
1. „WebSphere Remote Server-DVD anpassen”.
2. Softwarepakete erstellen.
3. Softwarepakete in einem Dateirepository speichern.
4. Softwarepaket veröffentlichen, verteilen und installieren.
WebSphere Remote Server-DVD anpassen
Sie müssen die DVD für eine unbeaufsichtigte Installation anpassen, um WebSphere Remote Server über Remotezugriff zu installieren. Gehen Sie wie folgt vor,
um die WebSphere Remote Server-DVD anzupassen:
1. Kopieren Sie die DVD auf die Festplatte der Entwicklungsmaschine. Beispiel:
xcopy d:\ C:\dvdName /i /e
mkdir /tmp/dvdName cp –r /media/cdrom/ /tmp/dvdName
Der Wert für dvdName ist Irss<plattform>With<db>DVD für 32-Bit-Betriebssysteme und Irss<plattform>With<db>x64DVD für 64-Bit-Betriebssysteme. Der Wert
für die Variable <plattform> ist Windows oder Linux, abhängig vom verwendeten
Betriebssystem. Der Wert für <db> ist Db2 oder Informix, abhängig von der jeweiligen Edition.
2. Bearbeiten Sie die Taskdatei (task.xml) im Verzeichnis 'tasks' Eine Liste der Variablen, die festgelegt werden können, finden Sie im Abschnitt „Eingabefelder
in Deployment Wizard” auf Seite 20. Beispiel:
C:\dvdName\tasks
/tmp/dvdName/tasks
Die Datei task.xml enthält Eingabeparameter für die einzelnen Middlewareprodukte im WebSphere Remote Server-Laufzeitstack.
3. Bearbeiten Sie die Datei C:\dvdName\IRU_install.properties. Bei dieser Datei
handelt es sich um die Antwortdatei von Deployment Wizard. Geben Sie die
folgenden Einstellungen in dieser Datei an, um eine unbeaufsichtigte Installation durchzuführen, die Lizenzvereinbarung zu bestätigen und die von Ihnen in
Schritt 2 ausgewählte Taskdatei anzugeben:
–silent=true
-taskFile=<Pfad der Task-XML>
4. Wenn Sie angeben möchten, welche Komponenten von WebSphere Remote Server installiert werden sollen, bearbeiten Sie die Datei task.xml entsprechend.
Setzen Sie die Tasks in Kommentarzeichen, die den Produkten entsprechen, die
nicht installiert werden sollen. Wenn beispielsweise IBM WebSphere MQ nicht
in der Installation enthalten sein soll, bearbeiten Sie das Snippet für WebSphere
MQ in der Taskdatei wie folgt:
<!-<deploy taskNumber="3">
<targetHostnames>
<targetHostname>localhost</targetHostname>
</targetHostnames>
<applications>
<application id="Mq_701_Win">
<variables>
</variables>
18
</application>
</applications>
</deploy>
-->
Softwarepakete erstellen
WebSphere Remote Server enthält Musterdateien mit Tivoli-Softwarepaketdefinitionen (SPD-Dateien). SPD-Dateien sind Textdateien, die mithilfe eines Texteditors
oder mithilfe des Tivoli-Softwarepaketeditors modifiziert werden können. Die SPDDateien enthalten Installationsbefehle und Verweise auf die installierbaren Dateien
auf dem Datenträger. Öffnen Sie die SPD-Datei im Softwarepaketeditor und speichern Sie sie als SPB-Datei (SPB = Softwarepaketblock). Der Softwarepaketeditor
komprimiert alle Dateien und Befehle, die zum Installieren des Pakets benötigt
werden, in einer SPB-Datei. Die SPB-Datei wird in einem Dateirepository gespeichert, in dem sie der Tivoli Provisioning Manager-Server verwenden kann.
Normalerweise wird nur eine SPB-Datei für die Installation eines Softwareprodukts
benötigt. SPB-Dateien weisen jedoch eine Größenbegrenzung von 2 GB auf. Da die
Installationsimages für den WebSphere Remote Server-Laufzeitstack größer als 2
GB sind, werden drei oder vier SPB-Dateien zum Installieren des WebSphere Remote Server-Produkts benötigt.
Jede der ersten zwei bzw. drei SPD-Musterdateien enthält Verweise auf etwa die
Hälfte der Dateien auf der WebSphere Remote Server-DVD. Die dritte bzw. vierte
SPD-Datei enthält nur die Installationsbefehle. Daher sind die SPB-Dateien, die aus
den ersten zwei bzw. drei SPD-Dateien generiert werden, relativ groß (knapp 2 GB
pro Datei), die dritte bzw. vierte SPB-Datei relativ klein ist.
Die SPD-Musterdateien befinden sich im Verzeichnis tpmFiles der WebSphere Remote Server-DVD. (Beispiel: C:\dvdName\tpmFiles oder /tpm/dvdName/tpmFiles,
wenn Sie die DVD den oben angeführten Anweisungen entsprechend auf die Festplatte kopiert haben.)
Die SPD-Dateien für 32-Bit-Betriebssysteme sind wie folgt benannt:
v Irss<plattform>With<db>DvdPart1.spd
v Irss<plattform>With<db>.spd
Anmerkung: Der Wert für die Variable <plattform> ist Windows oder Linux, abhängig vom verwendeten Betriebssystem. Der Wert für die Variable <db>
ist Db2 unter Windows und Informix unter Linux.
Die SPD-Dateien für 64-Bit-Betriebssysteme sind wie folgt benannt:
v Irss<plattform>With<db>x64DvdPart1.spd
v Irss<plattform>With<db>x64.spd
Die SPD-Musterdateien enthalten Verweise auf Dateien in der Verzeichnisstruktur
C:\dvdName. Dies ist die Speicherposition auf der Festplatte, an die Sie die WebSphere Remote Server-DVD kopiert haben. Wenn Sie die DVD an eine andere Posi-
19
tion kopiert haben, müssen Sie die Variable 'source' in den SPD-Dateien aktualisieren. Suchen und aktualisieren Sie den folgenden Abschnitt in den SPD-Dateien,
falls nötig:
default_variables
source = Verzeichnis auf Ihrer Entwicklungsmaschine
destination = Verzeichnis auf der Zielendpunktmaschine
end
Softwarepakete im Dateirepository speichern
Öffnen Sie die SPD-Dateien im Softwarepaketeditor und speichern Sie sie als SPBDateien in einem Dateirepository, auf das der Tivoli Provisioning Manager-Server
zugreifen kann. Informationen zum Einrichten des Dateirepositorys finden Sie im
Tivoli Provisioning Manager Information Center.
Softwarepaket veröffentlichen, verteilen und installieren
Wenn Sie die SPB-Dateien im Dateirepository gespeichert haben, können Sie Tivoli
Provisioning Manager dazu verwenden, die SPB-Dateien zu veröffentlichen, zu
verteilen und zu installieren. Informationen zu den Dateien im Softwarepaket finden Sie unter „Softwarepakete erstellen” auf Seite 19 in diesem Abschnitt.
Eingabefelder in Deployment Wizard
In diesem Abschnitt werden die Eingabefelder für jeden Abschnitt des Installationsprogramms beschrieben.
Felder für die Laufzeitinstallation
Tasks auswählen - Installationstyp auswählen
Im Fenster Tasks auswählen - Installationstyp auswählen werden Sie dazu aufgefordert, den IBM WebSphere Remote Server-Installationstyp anzugeben, den Sie
durchführen:
v Retail Store Server 7.1.1 Runtime for Windows/Linux installieren: Hiermit
wird Retail Store Server 7.1.1 Runtime mit IBM Middlewareprodukten und Musteranwendungen für WebSphere installiert.
v Von WebSphere Remote Server 6.1 oder 6.2.x migrieren: Hiermit wird ein Upgrade für eine vorhandene Installation von WebSphere Remote Server 6.1 oder
6.2.x Runtime auf die neuesten Versionen der Retail Store Server 7.1.1-Middlewareprodukte durchgeführt.
Anmerkung:
– Diese Task ist nur auf den unterstützten Migrationsplattformen
verfügbar. Details hierzu finden Sie im Abschnitt „Migration”
auf Seite 63.
– Wenn Sie eine Migration von WebSphere Remote Server 6.1
oder 6.2.x durchführen, können Sie nur auf WebSphere Remote
Server-Editionen mit DB2 migrieren.
v Von WebSphere Remote Server 7.0 oder 7.1 migrieren: Hiermit wird ein Upgrade für eine vorhandene Installation von WebSphere Remote Server 7.0 oder
7.1 Runtime auf die neuesten Versionen der Retail Store Server 7.1.1-Middlewareprodukte durchgeführt.
20
Anmerkung:
– Diese Task ist nur für Benutzer auf den unterstützten Migrationsplattformen verfügbar. Details hierzu finden Sie im Abschnitt „Migration” auf Seite 63.
– Wenn Sie eine Migration von WebSphere Remote Server-Editionen mit DB2 durchführen, können Sie nur auf WebSphere Remote Server V7.1.1-Editionen mit DB2 migrieren. Ebenso
können Sie bei einer Migration von WebSphere Remote ServerEditionen mit Informix Database nur auf WebSphere Remote
Server V7.1.1Editionen mit Informix Database migrieren.
v WebSphere Remote Server 7.1.1-Lösungsentwicklungsumgebung installieren:
Die Lösungsentwicklungsumgebung besteht aus IBM Software Assembly Toolkit
3.2.2, einem vollständigen Projektarbeitsbereich und den Installationsimages für
alle Middlewareprodukte.
IBM Retail Store Server-Basiskomponente
Typische Variablen
v Installationsverzeichnis: Der vollständig qualifizierte Pfadname, unter dem die
Imagedateien der IBM Retail Store Server-Basiskomponente installiert werden.
Erweiterte Variablen
v Hostaliasname: Der Hostaliasname, der für das Konfigurieren der Middlewarekomponenten verwendet werden soll.
DB2 Workgroup Server Edition
Linux-Installationen
Installationsimagedateien von DB2 installiert werden.
v Administrator-ID: Die Benutzer-ID, mit der eine Verbindung zu DB2 als DB2Administrator hergestellt wird. Dieser Benutzer wird erstellt, wenn er noch nicht
vorhanden ist. Diese Benutzer-ID darf nicht mit der ID für die Instanz und der
ID für den abgeschirmten Benutzer übereinstimmen.
v Administratorkennwort: Das Kennwort, das für den oben definierten DB2-Administrator verwendet wird. Wenn der Benutzer bereits vorhanden ist, muss dieses Kennwort mit dem Kennwort des betreffenden Benutzers übereinstimmen.
Andernfalls wird der Benutzer mit dem hier angegebenen Kennwort erstellt.
v Instanzbenutzer-ID: Diese Benutzer-ID steuert alle DB2-Prozesse und ist der
Eigner aller Dateisysteme und Einheiten, die von den Datenbanken innerhalb
der Instanz verwendet werden. Dieser Benutzer wird erstellt, wenn er noch nicht
vorhanden ist. Diese Benutzer-ID darf nicht mit der Administrator-ID übereinstimmen.
v Instanzbenutzerkennwort: Das Kennwort, das für den oben definierten DB2Instanzbenutzer verwendet wird. Wenn der Benutzer bereits vorhanden ist, muss
dieses Kennwort mit dem Kennwort des vorhandenen Benutzers übereinstimmen. Andernfalls wird der Benutzer mit dem hier angegebenen Kennwort erstellt.
v ID des abgeschirmten Benutzers: Der abgeschirmte Benutzer wird verwendet,
um benutzerdefinierte Funktionen (UDFs) und gespeicherte Prozeduren außerhalb des von der DB2-Datenbank verwendeten Adressraums auszuführen. Dieser
Benutzer wird erstellt, wenn er noch nicht vorhanden ist. Die ID des abgeschirmten Benutzers kann mit der Instanzbenutzer-ID identisch sein, dies wird
jedoch für Produktionssysteme nicht empfohlen.
21
v Kennwort des abgeschirmten Benutzers: Das Kennwort, das für den oben definierten abgeschirmten DB2-Benutzer verwendet wird. Wenn der Benutzer bereits
vorhanden ist, muss dieses Kennwort mit dem Kennwort des vorhandenen Benutzers übereinstimmen. Andernfalls wird der Benutzer mit dem hier angegebenen Kennwort erstellt.
v Soll die DB2-Steuerzentrale installiert werden?: Bei Auswahl dieser Option
wird die DB2-Steuerzentrale installiert.
v Spracheingabeaufforderungen für Portugiesisch (Brasilien), vereinfachtes Chinesisch, Deutsch, Französisch, Spanisch, Italienisch, Japanisch, Koreanisch,
traditionelles Chinesisch, Polnisch und Russisch: ('Sprachunterstützung für
<gewünschte Sprache> zusätzlich zu den anderen angegebenen Sprachen installieren.'): Installiert diese Sprachunterstützung zusätzlich zu den anderen angegebenen Sprachen. Englisch ist immer installiert.
Windows-Installationen
Installationsimagedateien von DB2 installiert werden.
v DB2-Administrator-ID: Die Benutzer-ID, mit der eine Verbindung zu DB2 als
DB2-Administrator hergestellt wird. Dieser Benutzer wird erstellt, wenn er noch
nicht vorhanden ist.
v DB2-Administratorkennwort: Das Kennwort, das für den oben definierten DB2Administrator verwendet wird. Wenn der Benutzer bereits vorhanden ist, muss
dieses Kennwort mit dem Kennwort des vorhandenen Benutzers übereinstimmen. Andernfalls wird der Benutzer mit dem hier angegebenen Kennwort erstellt.
v Kennwort überprüfen: Überprüft das im vorangegangenen Feld definierte DB2
Administratorkennwort.
v Soll die DB2-Steuerzentrale installiert werden?: Bei Auswahl dieser Option
wird die DB2-Steuerzentrale installiert.
v Direktaufrufe für das Startmenü erstellen?: Bei Auswahl dieser Option werden
Direktaufrufe für verschiedene DB2-Funktionen im Menü 'Start' von Windows
erstellt.
v Spracheingabeaufforderungen für Portugiesisch (Brasilien), vereinfachtes Chinesisch, Deutsch, Französisch, Spanisch, Italienisch, Japanisch, Koreanisch,
traditionelles Chinesisch, Polnisch und Russisch: ('Sprachunterstützung für
<gewünschte Sprache> zusätzlich zu den anderen angegebenen Sprachen installieren.'): Installiert diese Sprachunterstützung zusätzlich zu den anderen angegebenen Sprachen. Englisch ist immer installiert.
IBM Informix Growth Edition
Linux-Installationen
Installationsimagedateien von Informix Growth Edition installiert werden.
v Kennwort für Informix Growth Edition-Benutzer: Dies ist der Benutzer mit der
Kontoberechtigung für die Informix Growth Edition-Instanz.
v Kennwort überprüfen: Überprüft Ihr im vorangegangenen Feld eingegebenes
Benutzerkennwort.
v Basisserver: Der zentrale Datenbankserver für DBA-Basisoperationen ohne optionale Erweiterungen, Bibliotheken oder Dienstprogramme.
v Client SDK Version 3.00: Das IBM Informix Client Software Developer's Kit
(Client SDK) umfasst mehrere Anwendungsprogrammierschnittstellen (APIs),
22
mit denen Entwickler Anwendungen für Informix-Datenbankserver in ESQL, C
und Java™ schreiben können. Sie können auch Informix-ESQL/C-Anwendungen
für den DB2-Datenbankserver schreiben. IBM Informix Connect enthält die Laufzeitbibliotheken der APIs im Client-SDK.
v IConnect version 3.00: IBM Informix Connect enthält die Laufzeitbibliotheken
der APIs im Client-SDK. Wenn Sie sich für die Installation des Client-SDK entscheiden, wird IConnect nicht installiert.
v Datenbankservererweiterungen: Datenbankverwaltungsprogramme und Programmierungserweiterungen.
v J/Foundation: Schreiben von benutzerdefinierten Routinen in der Programmiersprache Java.
v Integrierte DataBlade-Module: Ausführen von Tasks, wie beispielsweise Verwaltung der Speicherposition großer Objekte (LOB), MQ-Transaktionsunterstützung,
XML-Veröffentlichung und Unterstützung binärer benutzerdefinierter Typen.
v Unterstützung für Konvertierung und Zurücksetzung: Framework, das für die
Migration von anderen Versionen und auf andere Versionen des Datenbankservers erforderlich ist.
v Komponente für die XML-Veröffentlichung: Enthält eine Reihe von Funktionen
für die Veröffentlichung von SQL-Abfragen im XML-Format.
v Globale Sprachenunterstützung: Die Komponentendateien für die Unterstützung von Sprachen, länderspezifischen Konventionen und codierten Zeichensätzen. Diese Dateien sind nicht erforderlich, wenn Ihre Standardlocale amerikanisches Englisch verwendet; hierbei handelt es sich um die voreingestellte Sprache
in IDS, wenn keine globale Sprachenunterstützung installiert ist.
v West-Europa sowie Nord- und Südamerika: Locales für Dänisch, Niederländisch, Englisch, Finnisch, Französisch, Deutsch, Isländisch, Italienisch, Norwegisch, Portugiesisch, Spanisch und Schwedisch.
v Osteuropäisch und Kyrillisch: Locales für Tschechisch, Polnisch, Russisch und
Slowakisch.
v Chinesisch: Locales für traditionelles Chinesisch und vereinfachtes Chinesisch.
v Japanisch: Locales für Japanisch.
v Koreanisch: Locales für Koreanisch.
v Sonstige: Sonstige Locales.
v Backup und Restore: Dienstprogramme für das Backup und den Restore von
Datenbankserverdaten.
v OnBar-Dienstprogramme: Ein editierbares Shell-Script unter UNIX und eine Stapeldatei unter Windows (onbar.dat) zum Starten des OnBar-Treibers. Verwenden
Sie das OnBar-Script bzw. die OnBar-Stapeldatei sowie die zugehörigen Befehle,
um Backup- und Restoreoperationen anzupassen und die Speichermanagerversion zu überprüfen.
v Informix-Schnittstelle für Tivoli Storage Manager: Implementieren der XSBAFunktionen, die Tivoli Storage Manager mit OnBar verwenden.
v Informix Storage Manager: Verwalten externer Speichereinheiten und Datenträger, die Backups enthalten.
v Dienstprogramm 'archecker': Prüfen von Backups und Wiederherstellen von Teilen einer Datenbank, von Tabellen, von Teilen einer Tabelle oder von einer Gruppe von Tabellen.
v Demos: Demonstrationsdatenbanken und Beispiele.
v Dienstprogramme für das Laden von Daten: Effizientes Laden und Entladen
von Daten in bestimmten Konfigurationen.
23
v Dienstprogramme 'onunload' und 'onload': Entladen von Daten aus einer Datenbank und anschließendes Laden dieser Daten in eine Datenbank.
v Dienstprogramm 'dbload': Laden von Daten in Datenbanken oder Tabellen, die
mit IBM Informix-Produkten erstellt wurden. Verwenden Sie das Dienstprogramm 'dbload' dazu, Daten von einer oder mehreren Textdateien in eine oder
mehrere vorhandene Tabllen zu übertragen.
v High-Performance Loader (HPL): Effizientes Laden und Entladen großer Datenmengen in eine oder aus einer Datenbank.
v Unternehmensweite Replikation: Replizieren von Daten zwischen IBM Informix
Dynamic Server-Datenbankservern.
v Verwaltungsdienstprogramme: Zusätzliche Komponentengruppen für Verwaltungsdienstprogramme.
v Dienstprogramme für die Leistungsüberwachung: Überwachen der Leistung
mit den Dienstprogrammen 'onmonitor' und 'onperf'.
v Sonstige Überwachungsdienstprogramme: Anzeigen des logischen Protokolls
mithilfe des Dienstprogramms 'onlog' oder Verwalten des Datenbankservers mit
SNMP mithilfe des Dienstprogramms 'onsnmp'.
v Prüfdienstprogramme: Verwalten von Prüfmasken, Prüflisten und weiteren
Prüfinformationen zum Datenbankserver mithilfe der Dienstprogramme 'onaudit' und 'onshowaudit'.
v Datenbankimport- und -exportdienstprogramme: Entladen einer Datenbank in
eine Textdatei; Erstellen und Füllen einer Datenbank aus diesen Textdateien; Entladen eines Datenbankschemas in eine Textdatei.
v Rollentrennung: Wählen Sie Yes aus, um die Rollentrennung zu aktivieren oder
wählen Sie No aus, um sie zu inaktivieren.
v DBSA-Gruppenaccount: Gruppe für allgemeine Verwaltungsaufgaben (Verwaltungsrolle für das Datenbanksystem). Dies ist nur anwendbar, wenn die Rollentrennung aktiviert ist.
v Rollentrennung - Gruppe der Datenbanksicherheitsbeauftragten: Gruppe der
Datenbanksicherheitsbeauftragten für Sicherheitsaufgaben auf Systemebene. Dies
ist nur anwendbar, wenn die Rollentrennung aktiviert ist.
v Rollentrennung - Gruppe der Prüfungsbeauftragten: Gruppe der Prüfungsbeauftragten für Prüfungsverwaltungsaufgaben. (Rolle des Beauftragten für die
Prüfungsanalyse). Dies ist nur anwendbar, wenn die Rollentrennung aktiviert ist.
v Rollentrennung - Benutzergruppe: Gruppe für Datenbankbenutzer. Dies ist nur
anwendbar, wenn die Rollentrennung aktiviert ist.
v Demo erstellen: Auswahlstatus des Demonstrationsdatenbankservers. Wählen
Sie create aus, um anzugeben, dass der Demonstrationsdatenbankserver erstellt
werden soll. Wählen Sie nocreate aus, um anzugeben, dass der Demonstrationsdatenbankserver nicht erstellt werden soll.
v Bereits vorhandene Datei 'onconfig': Gibt an, ob eine bereits vorhandene Datei
'onconfig' für die Konfiguration des Demonstrationsdatenbankservers verwendet
werden soll. Wählen Sie yes aus, wenn eine vorhandene Datei 'onconfig' verwendet werden soll. Wählen Sie no aus, um individuell angegebene Werte zu
verwenden. Wenn für diesen Wert yes festgelegt ist, müssen Sie im Pfadargument der Datei 'onconfig' eine Datei angeben.
v Pfad der bereits vorhandenen Datei 'onconfig': Gibt den Pfad der zu verwendenden Datei 'onconfig' an. Dieses Feld ist nur erforderlich, wenn Sie yes im
Feld Pfad der bereits vorhandenen Datei ausgewählt haben.
v Servername: Der Datenbankservername für die Demonstrationsdatenbankinstanz.
24
v Servernummer: Der Wert für den Demonstrationsdatenbankserver. Gültige Werte sind ganze Zahlen zwischen 0 und 255.
v Rootpfad: Vollständiger Pfad für den Speicherbereich des Rootdatenbankbereichs für den IDS-Demonstrationsdatenbankserver.
v Größe des Rootdatenbankbereichs: Die Größe des Rootdatenbankbereichs für
den Demonstrationsdatenbankserver.
v Pufferpool: Vom Standardwert abweichende Pufferpoolinformationen für den
Demonstrationsdatenbankserver.
v Anzahl der virtuellen Prozessoren der CPU: Anzahl der virtuellen Prozessoren
der CPU, die für den Demonstrationsdatenbankserver konfiguriert werden sollen.
v Terminalauswahl: Das Terminal, das nach einer erfolgreichen Installation und
Erstellung der Demonstrationsdatenbankinstanz gestartet werden soll. Bei der
Auswahl von other muss für Manual Terminal Input das von Ihnen gewünschte Terminal angegeben werden.
v Manuelle Terminaleingabe: Das Terminal, das Sie verwenden wollen. Beispiel:
Um 'xterm' mit der Option für manuelle Eingabe zu starten, verwenden Sie den
folgenden Befehl: /usr/bin/xterm
Windows-Installationen
Installationsimagedateien von Informix Growth Edition installiert werden.
v Kennwort für Informix Growth Edition-Benutzer: Dies ist der Benutzer mit der
Kontoberechtigung für die Informix Growth Edition-Instanz.
Benutzerkennwort.
v Rollentrennung aktivieren: Wählen Sie Yes aus, um die Rollentrennung zu aktivieren, oder wählen Sie No aus, um sie zu inaktivieren.
v DBSA-Gruppenaccount: Gruppe für allgemeine Verwaltungsaufgaben (Verwaltungsrolle für das Datenbanksystem). Dies ist nur anwendbar, wenn die Rollentrennung aktiviert ist.
v Rollentrennung - DBSSO-Gruppenaccount: Gruppe der Datenbanksicherheitsbeauftragten für Sicherheitsaufgaben auf Systemebene. Dies ist nur anwendbar,
wenn die Rollentrennung aktiviert ist.
v Rollentrennung - DBSSO-Benutzeraccount: Datenbanksicherheitsbeauftragter
für Sicherheitsaufgaben auf Systemebene. Dies ist nur anwendbar, wenn die Rollentrennung aktiviert ist.
v Rollentrennung - DBSSO-Benutzerkennwort: Benutzerkennwort des Datenbanksicherheitsbeauftragten für Sicherheitsaufgaben auf Systemebene. Dies ist
nur anwendbar, wenn die Rollentrennung aktiviert ist.
Benutzerkennwort. Dies ist nur anwendbar, wenn die Rollentrennung aktiviert
ist.
v Rollentrennung - AAO-Gruppenaccount: Gruppe der Prüfungsbeauftragten für
Prüfungsverwaltungsaufgaben (Rolle des Beauftragten für die Prüfungsanalyse).
Dies ist nur anwendbar, wenn die Rollentrennung aktiviert ist.
v Rollentrennung - AAO-Benutzeraccount: Prüfungsbeauftragter für Prüfungsverwaltungsaufgaben (Rolle des Beauftragten für die Prüfungsanalyse). Dies ist nur
25
v Rollentrennung - AAO-Benutzerkennwort: Benutzerkennwort für Prüfungsbeauftragte für Prüfungsverwaltungsaufgaben. Dies ist nur anwendbar, wenn die
Rollentrennung aktiviert ist.
Benutzerkennwort. Dies ist nur anwendbar, wenn die Rollentrennung aktiviert
ist.
v Rollentrennung - Benutzergruppe: Gruppe für Datenbankbenutzer. Dies ist nur
v Servername: Der Datenbankservername identifiziert den Datenbankserver für
Clientanwendungen. In den meisten Fällen können Sie den Standardwert auswählen.
v Server initialisieren?: Wenn Sie Ja auswählen, gehen alle vorhandenen Daten
verloren.
v Servicename: Der Name des Service (Windows-Dienstes) für die Informix
Growth Edition-Datenbankinstanz. Dies ist nur zutreffend, wenn Server initialisieren ausgewählt ist.
v Port: Geben Sie die Portnummer für das TCP/IP-Protokoll an. Die Portnummer
gibt den Porteintrag für den Datenbankserver in der Registrierdatenbank "sqlhosts" an. Dies ist nur zutreffend, wenn Server initialisieren ausgewählt ist.
v Servernummer: Die Datenbankservernummer identifiziert einen Datenbankserver eindeutig, falls mehrere Instanzen des Datenbankservers installiert sind.
Wenn nur eine Instanz der Datenbank installiert ist, legen Sie für diese Nummer
den Wert '0' fest. Dies ist nur zutreffend, wenn Server initialisieren ausgewählt
ist.
v DBSpace-Name: Ein Datenbankbereich (DBSpace) ist eine logische Gruppe von
Chunks, denen Datenbanken und Tabellen zugeordnet sind. Dies ist nur zutreffend, wenn Server initialisieren ausgewählt ist.
v DBSpace-Primärdatenposition: Speicherposition für den Datenbankbereich
(DBSpace). Dies ist nur zutreffend, wenn Server initialisieren ausgewählt ist.
v DBSpace-Größe: Größe des Datenbankbereichs (DBSpace) in Megabyte. Dies ist
nur zutreffend, wenn Server initialisieren ausgewählt ist.
v SBSpace-Name: Ein SBSpace ist ein logischer Speicherbereich, den der Datenbankserver dazu verwendet, intelligente große Objekte (CLOB- und BLOB-Daten) zu speichern. Dies ist nur zutreffend, wenn Server initialisieren ausgewählt
ist.
v SBSpace-Primärdatenposition: Speicherposition des SBSpace. Dies ist nur zutreffend, wenn Server initialisieren ausgewählt ist.
v SBSpace-Größe: Größe des SBSpace in Megabyte. Dies ist nur zutreffend, wenn
Server initialisieren ausgewählt ist.
v SBSpace-Seitengröße: Die SBSpace-Seitengröße sollte in etwa der Größe des am
häufigsten vorkommenden intelligenten großen Objekts im SBSpace entsprechen.
Der Standardwert ist eine Seite. Dies ist nur zutreffend, wenn Server initialisieren ausgewählt ist.
v JDBC-Treiber installieren?: Mit dem JDBC-Treiber können Java-Programmierer
von Java-Anwendungen oder -Applets aus auf Datenbanken zugreifen.
v Informix Connect installieren?: Informix Connect (IConnect) enthält die Laufzeitbibliotheken der APIs im Client-SDK.
Anmerkung: WebSphere Remote Server bietet keine Unterstützung für IConnect
auf 64-Bit-Windows-Plattformen. Wenn Sie IConnect-Funktionen
auf einer 64-Bit-Windows-Plattform benötigen, müssen Sie stattdes-
26
v
v
v
v
sen das Client-SDK installieren. Das Client-SDK ist ein Superset
von IConnect und enthält alle IConnect-Funktionen.
Client Software Developer's Kit (CSDK) installieren?: Dieses SDK enthält eine
Reihe von Anwendungsprogrammierschnittstellen (APIs), mit denen Entwickler
Anwendungen für Datenbankserver schreiben können.
DataBlade Developer's Kit installieren?: Dieses Entwicklerkit enthält Tools zum
Entwickeln und Packen von DataBlade-Modulen.
BladeManager installieren?: Mit BladeManager können neue DataBlade-Module
in Informix-Datenbanken registriert werden.
ClusterIt installieren?: Dienstprogramm für die Clusterkonfiguration.
WebSphere MQ
Felder, die mit der Markierung Linux oder Windows versehen sind, stehen nur für
die Installation auf der entsprechenden Plattform zur Verfügung.
Kennwort für Benutzer mqm: Das Kennwort, das für den Benutzer
v
mqm verwendet wird.
Kennwort überprüfen: Überprüft Ihr im vorangegangenen Feld einv
gegebenes Benutzerkennwort.
Installationsverzeichnis: Der vollständig qualifizierte Pfadname, unv
ter dem die Installationsimagedateien von IBM WebSphere MQ installiert werden.
Anmerkung: Ändern Sie die Installationsposition von WebSphere MQ nicht,
wenn Sie eine Migration von WebSphere Remote Server Version
6.1 auf Version 7.1.1 durchführen. Wird die Installationsposition
geändert, ist keine erfolgreiche Deinstallation der WebSphere MQKomponente möglich, wenn das WebSphere Remote Server-Deinstallationsprogramm ausgeführt wird. Wenn die Deinstallation eines
Teils von WebSphere Remote Server nicht erfolgreich ist, wird die
WebSphere Remote Server-Basiskomponente nicht deinstalliert.
Weitere Informationen hierzu finden Sie in „Tipps zur
Fehlerbehebung” auf Seite 131.
v Möchten Sie MQ Explorer installieren?: Bei Auswahl dieser Option wird WebSphere MQ Explorer installiert.
WebSphere Application Server Network Deployment
Installationsimagedateien von IBM WebSphere Application Server Network Deployment installiert werden.
Konfiguration des WebSphere Application Server-Standalone-Profils
v Name des WebSphere Application Server-Profils: Der Name des zu erstellenden Profils. Der Profilname muss für diese IBM WebSphere Application ServerInstallation eindeutig sein.
v Knotenname: Der Knotenname für WebSphere Application Server. Der Knotenname muss innerhalb einer Zelle eindeutig sein.
v Verwaltungssicherheit aktivieren: Ist diese Option auf 'true' (wahr) gesetzt,
müssen sich Benutzer anmelden, wenn sie auf WebSphere-Verwaltungstools zugreifen. Ein Benutzer mit Verwaltungsaufgaben und das zugehörige Kennwort
sind erforderlich, wenn diese Option aktiviert ist.
27
v Benutzer mit Verwaltungsaufgaben: Bei der Verwendung der Verwaltungssicherheit erforderlich: Benutzer-ID für den Zugriff auf WebSphere Application
Server-Verwaltungstools.
v Kennwort für Benutzer mit Verwaltungsaufgaben: Bei der Verwendung der
Verwaltungssicherheit erforderlich: Kennwort für den Zugriff auf WebSphere
Application Server-Verwaltungstools.
Kennwort für Benutzer mit Verwaltungsaufgaben.
v WebSphere für die Ausführung als Service aktivieren: Ist diese Option auf
'true' gesetzt, wird WebSphere Application Server für die Ausführung als Service
konfiguriert.
IBM HTTP Server
Installationsimagedateien von IBM HTTP Server installiert werden.
v HTTP-Port: Geben Sie den von IBM HTTP Server verwendeten Standardport an.
v Port des Verwaltungsservers: Geben Sie den vom Verwaltungsserver verwendeten Standardport an.
v IBM HTTP Server-Plug-in für WebSphere Application Server installieren?: Geben Sie an, ob das WebSphere Application Server-Plug-in installiert werden soll.
Felder für die Installation der Entwicklungsumgebung
Tasks auswählen - Installationstyp auswählen
Im Fenster 'Tasks auswählen - Installationstyp auswählen' werden Sie dazu aufgefordert, den Installationstyp anzugeben, den Sie ausführen:
v Software Assembly Toolkit 3.2.2 installieren: Dieses Toolkit bietet eine vollständige und Eclipse-basierte integrierte Entwicklungsumgebung mit dem Software
Assembly Toolkit Developer-Plug-in.
v WebSphere sMash 1.1.1.5 installieren: „WebSphere sMash” auf Seite 96 enthält
weitere Informationen zu dieser Option.
v IBM Retail Store Server 7.1.1-Arbeitsbereich installieren: Hiermit werden der
Arbeitsbereich und die Implementierungspakete für IBM Retail Store Server 7.1.1
installiert. Der Arbeitsbereich enthält den Code und alle Projekte, die zum Entwickeln von angepassten Lösungen mit IBM Retail Store Server benötigt werden.
Die Implementierungspakete enthalten alle Installationsmedien für die Middlewareprodukte, auf denen IBM Retail Store Server basiert. Der Arbeitsbereich und
die Implementierungspakete für Windows können auch auf einem Linux-basierten Entwicklungsserver installiert werden, um die plattformübergreifende Entwicklung zu ermöglichen. Ebenso können der Arbeitsbereich und die Implementierungspakete für Linux auch auf einem Windows-basierten Entwicklungsserver
installiert werden.
IBM Retail Store Server-Basiskomponente
Typische Variablen
Imagedateien der IBM Retail Store Server-Basiskomponente installiert werden.
Erweiterte Variablen
v Hostaliasname: Der Hostaliasname, der für das Konfigurieren der Middlewarekomponenten verwendet werden soll.
28
Software Assembly Toolkit
Imagedateien von Software Assembly Toolkit installiert werden.
WebSphere sMash
Imagedateien von WebSphere sMash installiert werden.
IBM Retail Store Server-Arbeitsbereichskomponente
v Installationsverzeichnis: Der vollständig qualifizierte Pfadname, unter dem der
Arbeitsbereich von IBM Retail Store Server installiert wird.
Unbeaufsichtigte Installation
In diesem Thema wird beschrieben, wie die unbeaufsichtigte Installation des Produkts durchgeführt wird.
Sie müssen die Musterantwortdatei für Ihre Entwicklungsumgebung anpassen, bevor Sie die unbeaufsichtigte Installation durchführen. In der Musterdatei sind auch
Anweisungen zum Anpassen der Datei vorhanden. Nach dem Anpassen der Datei
können Sie den Befehl absetzen, mit dem die unbeaufsichtigte Installation durchgeführt wird. Die unbeaufsichtigte Installation ist insbesondere nützlich, wenn Sie Ihr
Produkt häufig installieren oder wenn Sie von einer fernen Eingabeaufforderung
aus installieren.
Führen Sie die folgenden Anweisungen aus, um das Installationsprogramm in unbeaufsichtigtem Modus auszuführen.
Vorgehensweise
1. Wählen Sie die Musterantwortdatei für die gewünschte Installation aus. Die
Musterantwortdatei hat den Namen task.xml und befindet sich im Verzeichnis
tasks der Ihrem Betriebssystem entsprechenden WebSphere Remote ServerDVD.
Anmerkung: Ändern Sie nicht den Wert der Eigenschaft <taskNumber> in der
Datei task.xml, da andernfalls die Installation fehlschlägt.
2. Bearbeiten Sie die Datei C:\dvdName\IRU_install.properties. Bei dieser Datei
handelt es sich um die Antwortdatei für Deployment Wizard. Geben Sie die folgenden Einstellungen in dieser Datei an, um eine unbeaufsichtigte Installation
durchzuführen, die Lizenzvereinbarung zu bestätigen und die von Ihnen in
Schritt 1 ausgewählte Taskdatei anzugeben:
–silent=true
-taskFile=<Pfad der Task-XML>
3. Starten Sie den Installationsvorgang mit der Option für die unbeaufsichtigte Installation:
WindowsSetup.exe
LinuxSetup
4. Prüfen Sie die Protokolle, um festzustellen, ob die Installation erfolgreich war.
Wenn an der folgenden Position Protokolldateien vorhanden sind, ist die unbeaufsichtigte Installation abgeschlossen:
(32-Bit) C:\Program Files\SolutionFiles\logs
(64-Bit) C:\Program Files (x86)\SolutionFiles\logs
29
/opt/SolutionFiles/logs
Wenn in den Protokolldateien Fehler dokumentiert sind, lesen Sie den Abschnitt „Tipps zur Fehlerbehebung” auf Seite 131, um mögliche Problemlösungen zu finden.
Installation prüfen
In diesem Abschnitt wird beschrieben, wie Sie prüfen können, ob die einzelnen
Softwarepakete korrekt installiert wurden und ordnungsgemäß funktionieren.
Die Schritte zum Überprüfen der Installation der einzelnen Softwarepakete bzw.
Anwendungen werden in den folgenden Abschnitten angegeben. Die Prüfung der
Installation ist optional.
Anmerkung: Es empfiehlt sich, vor dem Überprüfen der Produktinstallation die
Fixpacks für Middlewareprodukte zu installieren.
Installationsprotokolldateien
Während der Installation der einzelnen Middlewareprodukte werden jeweils Protokolldateien erstellt. Überprüfen Sie anhand dieser Protokolle, ob die Installation erfolgreich ausgeführt wurde.
Die Installationsprotokolldateien befinden sich in den folgenden Verzeichnissen:
(32-Bit)
v SIF_HOME\logs
v %TEMP%\logs
v C:\Program Files\SolutionFiles\logs
(64-Bit)
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
WebSphere Application Server prüfen
Die Installation von WebSphere Application Server wurde bereits während des Installationsprozesses mithilfe der Scripts ivt.bat und ivt.sh geprüft.
WebSphere MQ prüfen
In diesem Abschnitt wird beschrieben, welche Schritte ausgeführt werden müssen,
um die Installation von IBM WebSphere MQ zu prüfen.
Dieses Softwarepaket erstellt Benutzer und Gruppen, die der Anwendung WebSphere MQ zugeordnet sind. Die folgenden Anweisungen unterstützen Sie beim
30
Erstellen, Starten, Beenden und Löschen eines Warteschlangenmanagers mit dem
Namen "QM1".
Vorgehensweise
v Unter Linux:
1. Melden Sie sich beim Filialrechner (ISP) als Benutzer mit Rootzugriff an.
2. Geben Sie den folgenden Befehl ein, um zum Benutzer "mqm" zu wechseln
(dem Benutzer, der vom Installationsscript erstellt wurde):
su - mqm
3. Geben Sie den folgenden Befehl ein, um den Warteschlangenmanager mit
dem Namen "QM1" zu erstellen:
crtmqm QM1
4. Geben Sie den folgenden Befehl ein, um den Warteschlangenmanager zu
starten:
strmqm QM1
5. Geben Sie die folgenden Befehle ein, um den Warteschlangenmanager zu beenden:
endmqm -i QM1
6. Geben Sie den folgenden Befehl ein, um den Warteschlangenmanager zu löschen:
dltmqm QM1
7. Melden Sie sich bei dem Filialsystem ab und schließen Sie alle Fenster.
v Unter Windows:
1. Öffnen Sie die Eingabeaufforderung.
2. Geben Sie den folgenden Befehl ein, um den Warteschlangenmanager mit
dem Namen "QM1" zu erstellen:
crtmqm QM1
3. Geben Sie den folgenden Befehl ein, um den Warteschlangenmanager zu
starten:
strmqm QM1
4. Geben Sie die folgenden Befehle ein, um den Warteschlangenmanager zu beenden:
endmqm -i QM1
5. Geben Sie den folgenden Befehl ein, um den Warteschlangenmanager zu löschen:
dltmqm QM1
6. Schließen Sie die Eingabeaufforderung.
IBM HTTP Server prüfen
Die Installation von IBM HTTP Server wurde bereits vom Installationsprogramm
geprüft, das die HTTP-Server stoppt und startet.
DB2 Workgroup Server Edition prüfen
In diesem Abschnitt wird beschrieben, welche Schritte ausgeführt werden müssen,
um die Installation von DB2 zu prüfen.
Um eine Datenbank zu erstellen und zu löschen, gehen Sie wie folgt vor:
31
Vorgehensweise
1. Greifen Sie auf DB2 zu.
Linux
a. Melden Sie sich beim Filialrechner (ISP) als Benutzer mit Rootzugriff an.
b. Geben Sie den folgenden Befehl ein, um zum Benutzer db2inst1 zu wechseln (einer der Benutzer, die vom Installationsscript erstellt wurden):
su - db2inst1
Windows
a. Öffnen Sie ein DB2-Befehlsfenster (zum Beispiel mit execute db2cw).
2. Verwenden Sie das folgende Script, um eine Musterdatenbank zu erstellen: db2
create database test.
3. Verwenden Sie das folgende Script, um eine Musterdatenbank zu löschen: db2
drop database test.
Informix Growth Edition prüfen
Gehen Sie wie in diesem Abschnitt beschrieben vor, um Ihre Informix Growth Edition-Installation unter Windows- oder Linux-Betriebssystemen zu überprüfen.
Prüfung unter Windows-Betriebssystemen
Durch das Installationsverfahren wird eine Stapeldatei dbservername.cmd erstellt,
die Werte für die Umgebungsvariablen festlegt. Diese Datei befindet sich in dem
Verzeichnis, in dem Informix Growth Edition installiert wurde. Führen Sie diese
Datei aus, bevor Sie eines der Informix Growth Edition-Befehlszeilendienstprogramme ausführen. Der Standardname und die Position der Datei lauten:
C:\Program Files\IBM\SIF\IBM Informix Dynamic Server\11.50\
ol_svr_custom.cmd.
Führen Sie diese Schritte aus, um eine Datenbank zu erstellen bzw. zu löschen, um
eine Tabelle zu erstellen bzw. zu löschen und um Daten zu einer Tabelle hinzuzufügen.
Vorgehensweise
1. Führen Sie von einer Eingabeaufforderung aus die folgenden Befehle aus, um
eine Musterdatenbank zu erstellen:
cd informixInstallDir
dbservername.cmd
cd bin
dbaccess - create database sample1;
2. Führen Sie die folgenden Befehle aus, um eine Tabelle zu erstellen und zu löschen.
Gehen Sie wie folgt vor, um eine Tabelle zu erstellen:
create table test (
a_number integer,
a_string char(50),
another_string char(50));
Gehen Sie wie folgt vor, um Zeilen einzufügen und abzurufen:
insert into test values (123, "Hello", "My name is David");
insert into test values (456, "Bonjour", "Je m’appelle David");
select * from test;
a_number 123
32
a_string Hello
another_string My name is David
a_number 456
a_string Bonjour
another_string Je m’appelle David
Gehen Sie wie folgt vor, um die Tabelle zu löschen und die Verbindung zu
trennen:
drop table test;
disconnect all;
3. Führen Sie den folgenden Befehl aus, um die Datenbank zu löschen:
drop database ’sample1’;
Prüfung unter Linux-Betriebssystemen
Vorgehensweise
1. Melden Sie sich beim Filialrechner (ISP) als Benutzer mit Rootzugriff an.
2. Suchen Sie nach der folgenden Datei:
. /etc/profile.d/setInformixEnv.sh
$INFORMIXDIR/bin/dbaccess - >create database sample1;
3. Führen Sie die folgenden Befehle aus, um eine Tabelle zu erstellen und zu löschen.
Gehen Sie wie folgt vor, um eine Tabelle zu erstellen:
create table test (
a_number integer,
a_string char(50),
another_string char(50));
Gehen Sie wie folgt vor, um Zeilen einzufügen und abzurufen:
insert into test values (123, "Hello", "My name is David");
insert into test values (456, "Bonjour", "Je m’appelle David");
select * from test;
a_number 123
a_string Hello
another_string My name is David
a_number 456
a_string Bonjour
another_string Je m’appelle David
Gehen Sie wie folgt vor, um die Tabelle zu löschen und die Verbindung zu
trennen:
drop table test;
disconnect all;
4. Führen Sie den folgenden Befehl aus, um die Datenbank zu löschen:
drop database ’sample1’;
WebSphere sMash prüfen
Gehen Sie wie in diesen Anweisungen beschrieben vor, um zu prüfen, ob WebSphere sMash installiert ist.
Um zu prüfen, ob WebSphere sMash installiert wurde, überprüfen Sie die Datei
install.log im WebSphere sMash-Installationsverzeichnis.
33
Um zu prüfen, ob IBM Reliable Transport Extension for WebSphere sMash installiert wurde, überprüfen Sie die Datei rte_install.log im selben Verzeichnis.
IBM Tivoli Monitoring-Agenten installieren und implementieren
Dieser Abschnitt enthält Informationen zum Installieren und Implementieren von
IBM Tivoli Monitoring-Agenten.
Tivoli Enterprise Monitoring Agents werden zur Überwachung von Ressourcen
verwendet. Die Agenten und die Systeme oder Computer, auf denen sie ausgeführt
werden, werden als verwaltete Systeme bezeichnet. Installieren Sie die Agenten auf
dem zu überwachenden Betriebssystem, Subsystem oder Computer.
Anmerkung:
v Es wird empfohlen, die Agenten über Remotezugriff zu installieren.
v Nur die folgenden IBM Tivoli Monitoring-Agenten unterstützen
Windows 7 (32-Bit und 64-Bit):
– IBM Tivoli Composite Application Manager Agent for HTTP
Servers 7.1
– IBM Tivoli Composite Application Manager Agent for IBM
WebSphere Application Server
v Wenn für die folgenden Produkte eine Überwachung erfolgen soll,
müssen sie auf den ISPs installiert werden, die nicht unter Windows 7 ausgeführt werden.
– DB2 9.7 Fixpack 2
– IBM WebSphere Message Broker Retail Store Edition 7.0
– IBM WebSphere MQ 7.0.1.2
v Wenn Sie OS Monitoring Agent unter SUSE Linux Enterprise Server 10.3 (64-Bit) installieren, müssen die folgenden Bibliotheken installiert sein:
libstdc++-devel
libstdc++33-32bit
Informationen zur Installation und Implementierung sowie weitere Informationen
zu Tivoli Monitoring-Agenten finden Sie im Tivoli Monitoring Information Center.
Agentenunterstützungsdateien installieren
Wenn Sie einen beliebigen ITM-Agenten implementieren, müssen Sie die Agentenunterstützungsdateien in TEMS und TEPS installieren. Unterstützungsdateien sind
im Agenteninstallationsimage verfügbar.
Führen Sie folgende Schritte aus, um Unterstützung auf einem Überwachungsserver zu installieren.
Vorgehensweise
1. Stoppen Sie den Überwachungsserver mit dem folgenden Befehl:
/opt/IBM/ITM/bin/itmcmd server stop tems_name
2. Führen Sie von den Installationsmedien den folgenden Befehl aus:
./install.sh
34
3. Wenn Sie zur Eingabe des Ausgangsverzeichnisses von IBM Tivoli Monitoring
aufgefordert werden, drücken Sie die Eingabetaste, um den Standardwert
(/opt/IBM/ITM) zu übernehmen, oder geben Sie den vollständigen Pfad zu
dem von Ihnen verwendeten Installationsverzeichnis ein.
4. Es wird ein Fenster angezeigt, in dem Sie aufgefordert werden, eine Auswahl
zwischen den folgenden Optionen zu treffen: Install products to the local
host, Install products to depot for remote deployment (requires TEMS) und
Exit install. Wählen Sie die erste Option aus, um den Installationsprozess zu
starten.
5. Geben Sie die Zahl für eine Sprache ein, in der Sie die Softwarelizenzvereinbarung anzeigen möchten, und drücken Sie die Eingabetaste.
6. Drücken Sie die Eingabetaste, um die Vereinbarung anzuzeigen.
7. Geben Sie 1 ein, um die Vereinbarung zu akzeptieren, und drücken Sie die
Eingabetaste.
8. Geben Sie den 32-stelligen Verschlüsselungsschlüssel ein, und drücken Sie die
Eingabetaste. Dieser Schlüssel muss mit dem Schlüssel übereinstimmen, der
bei der Installation des Überwachungsservers verwendet wurde. Eine nummerierte Liste der verfügbaren Betriebssysteme und Installationskomponenten
wird angezeigt.
9.
10.
11.
12.
13.
Anmerkung: Wenn Sie bereits eine andere Komponente von IBM Tivoli Monitoring auf diesem Computer installiert haben oder von einem
Agenteninstallationsimage Unterstützung für einen Agenten installieren, wird dieser Schritt nicht angezeigt.
Geben Sie die Zahl ein, die der Tivoli Enterprise Monitoring Server-Unterstützung entspricht, und drücken Sie die Eingabetaste.
Geben Sie y zur Bestätigung ein, und drücken Sie die Eingabetaste. Eine Liste
der installierbaren Komponenten wird angezeigt.
Geben Sie die Zahl ein, die allen oben angeführten Optionen entspricht, und
drücken Sie die Eingabetaste.
Geben Sie y ein, um die Installation zu bestätigen. Der Installationsprozess
wird gestartet.
Nachdem alle Komponenten installiert sind, werden Sie gefragt, ob Sie Komponenten für ein anderes Betriebssystem installieren wollen. Geben Sie n ein,
und drücken Sie die Eingabetaste.
14. Starten Sie den Überwachungsserver mit dem folgenden Befehl:
/opt/IBM/ITM/bin/itmcmd server start tems_name
15. Führen Sie den folgenden Befehl aus, um die Anwendungsunterstützung auf
dem Überwachungsserver zu aktivieren, wobei tems_name der Name des
Überwachungsservers und pc der Produktcode für den Agenten ist:
/opt/IBM/ITM/bin/itmcmd support -t tems_name pc
16. Führen Sie den folgenden Befehl aus, um den Produktcode für die gerade installierte Anwendungsunterstützung anzuzeigen:
/opt/IBM/ITM/bin/cinfo
17. Geben Sie 1 ein, wenn Sie aufgefordert werden, die Produktcodes für die auf
diesem Computer installierten Komponenten anzuzeigen. Fügen Sie nur die
Unterstützung für den Agenten hinzu, den Sie installiert haben. Wenn Sie beispielsweise die Unterstützung für den DB2(R)-Agenten installiert haben, führen Sie den folgenden Befehl aus, wobei ud der Produktcode für den DB2Agenten ist:
/opt/IBM/ITM/bin/itmcmd support -t hub_tems_name ud
18. Stoppen Sie den Überwachungsserver mit dem folgenden Befehl:
35
/opt/IBM/ITM/bin/itmcmd server stop tems_name
19. Führen Sie den folgenden Befehl aus, um den Überwachungsserver erneut zu
starten:
/opt/IBM/ITM/bin/itmcmd server start tems_name
Tivoli Monitoring-Überwachungsagenten implementieren
In diesem Abschnitt wird beschrieben, wie die Überwachungsagenten von Tivoli
Monitoring auf dem ISP über Remotezugriff vom Unternehmen aus implementiert
werden. Die Funktion für die Implementierung über Remotezugriff wird in Tivoli
Monitoring 6.2.2 Fixpack 1 bereitgestellt und ist nicht von IBM Tivoli Management
Framework abhängig.
In den folgenden Abschnitten wird sowohl die ferne als auch die lokale Implementierung beschrieben. Das empfohlene Verfahren ist jedoch die ferne Implementierung. Bei der lokalen Implementierung muss die Überwachungsagentensoftware
auf jedem ISP einzeln geladen werden, was sehr lange dauern kann, wenn viele
Maschinen installiert werden müssen. Die ferne Implementierung wird auf dem
Unternehmensserver ausgeführt. Dabei werden die Images auf dem Überwachungsserver (TEMS) erstellt und anschließend im Unternehmen an die ISPs verteilt.
Überwachungsagenten sind Datenkollektoren. Agenten überwachen Systeme, Subsysteme oder Anwendungen, erfassen Daten und leiten diese über den Überwachungsserver an Tivoli Enterprise Portal weiter. Es gibt zwei Arten von Überwachungsagenten:
v Betriebssystemagenten: Sie überwachen die Verfügbarkeit und Leistung der
Computer in der Überwachungsumgebung.
v Anwendungsagenten (oder Nicht-Betriebssystemagenten): Sie überwachen die
Verfügbarkeit und Leistung bestimmter Anwendungen.
Tivoli Monitoring stellt auch einen anpassungsfähigen Agenten bereit, der als Universal Agent bezeichnet wird und zur Überwachung von Daten dient, die für Ihre
Unternehmensumgebung spezifisch sind.
Die folgenden Agenten werden auf dem ISP implementiert:
v
v
v
v
v
OS Agent
IBM Tivoli
IBM Tivoli
IBM Tivoli
IBM Tivoli
Universal Agent
Composite Application Manager Agent for DB2 6.2.2
Composite Application Manager Agent for Oracle Database 6.2.1
Composite Application Manager Agent for J2EE 6.1
v IBM Tivoli Composite Application Manager Agent for WebSphere Applications
7.1
v IBM Tivoli Composite Application Manager Agent for HTTP Servers 7.1
v IBM Tivoli Composite Application Manager Agent for WebSphere MQ 7.0.1
v IBM Tivoli Composite Application Manager Agent for WebSphere Broker 7.0.1
v IBM Tivoli Composite Application Manager Configuration Agent for WebSphere
MQ 7.0.1
Implementierung über Remotezugriff vorbereiten
Die Implementierung über Remotezugriff bietet die Möglichkeit, von einen zentralen Standort aus die Ressourcenüberwachung in der ganzen Umgebung einzurichten.
36
An diesen zentralen Standort, dem Unternehmensserver, wird ein Repository zum
Speichern der Agentenimages erstellt, die für die Verteilung im Netz vorgesehen
sind. Dieses Repository wird als Agentendepot bezeichnet. Anschließend wird das
Agentendepot mit den gewünschten Installationsimages gefüllt und überprüft.
Wenn sich bei der Prüfung ergibt, dass sich alle gewünschten Images in dem Depot befinden, werden sie implementiert, das bedeutet, die Agenten werden über
das Netz an die ISPs verteilt.
Die Implementierung über Remotezugriff kann auch verwendet werden, um die
implementierten Agenten zu konfigurieren und Verwaltungsaufgaben auf ihnen
auszuführen.
Voraussetzungen:
Für die Implementierung über Remotezugriff muss IBM Tivoli Monitoring 6.2.2
Fixpack 1 auf dem Unternehmensserver installiert sein. Diese Installation der ITMÜberwachungsumgebung umfasst die Installation von Tivoli Enterprise Monitoring
Server (TEMS), Tivoli Enterprise Portal Server (TEPS) und Tivoli Enterprise Portal
(TEP). Stellen Sie vor der Installation von ITM sicher, dass DB2 UDB installiert ist.
Die Voraussetzungen für die Unternehmenskonfiguration lauten wie folgt:
v DB2 UDB ab Version 9.5
v IBM Tivoli Monitoring 6.2.2 Fixpack 1 (TEMS, TEPS, TEP Client)
Agentendepot füllen:
Das Agentendepot ist ein Installationsverzeichnis auf dem Überwachungsserver
(TEMS), von dem aus Sie Agenten und Wartungspakete in Ihrer Umgebung implementieren. Bevor Sie Agenten von einem Überwachungsserver aus implementieren können, müssen Sie erst das Agentendepot mit Paketen füllen. Ein Paket ist
das Agenteninstallationsimage mit allen Voraussetzungen.
Wenn Sie zum Agentendepot ein Paket hinzufügen, muss dieses Paket das Betriebssystem unterstützen, in dem Sie es implementieren wollen. Da die unterschiedlichen IBM Tivoli Monitoring-Komponenten verschiedene CDs für die einzelnen Plattformtypen bereitstellen, müssen Sie das jeweilige Paket von der
plattformspezifischen CD für die Komponente hinzufügen. Auf jedem Überwachungsserver (TEMS) in Ihrer Umgebung kann ein Agentendepot vorhanden sein.
Alternativ dazu kann ein Agentendepot mithilfe eines gemeinsam genutzten Dateiservers von Ihren Überwachungsservern gemeinsam genutzt werden.
Für alle Agenten, die im Netz implementiert werden sollen, müssen auch die zugehörigen Anwendungsunterstützungsdateien, in denen die agentenspezifischen Informationen enthalten sind, auf den Unternehmensservern (TEMS, TEPS, TEP Client) installiert werden.
Es gibt zwei Verfahren zum Füllen des Agentendepots:
v Agentendepot über das Installationsimage füllen
v Agentendepot mit dem Befehl tacmd addBundles füllen
Diese Verfahren werden in den beiden folgenden Abschnitten genauer beschrieben.
Agentendepot über ein Installationsimage füllen:
Das Installationsimage kann nur dann zum Füllen eines Agentendepots verwendet
werden, wenn Sie das Depot mit Paketen für das Betriebssystem füllen, unter dem
37
Ihr Überwachungsserver (TEMS) läuft. Beispielsweise können Sie ein Tivoli Monitoring-Installationsimage für Windows verwenden, um ein Paket für einen Windows-Agenten zu einem Windows-Überwachungsserver (TEMS) hinzuzufügen. Sie
können jedoch kein Tivoli Monitoring-Installationsimage für Linux verwenden, um
ein Linux-Paket zu einem Windows-Überwachungsserver hinzuzufügen. Wenn Sie
Pakete für andere Betriebssysteme als das vom Überwachungsserver eingesetzte
hinzufügen müssen, müssen Sie den Befehl tacmd addBundles verwenden.
Verwenden Sie die nachfolgend aufgeführten Schritte, um das Agentendepot mithilfe des Installationsimage für IBM Tivoli Monitoring unter Windows zu füllen:
v Starten Sie den Installationsassistenten, indem Sie doppelt auf die Datei "setup.exe" im Unterverzeichnis \Windows des Installationsimage klicken.
v Wählen Sie im Fenster Welcome die Option Modify aus, und klicken Sie dann
auf Next.
v Es wird eine Warnung zu den vorhandenen Komponenten auf dem Computer
angezeigt. Klicken Sie auf OK.
v Klicken Sie im Fenster Add or Remove Features auf OK, ohne Änderungen vorzunehmen. Wählen Sie keine ausgewählten Elemente ab, da sie dadurch vom
Computer entfernt werden.
v Wählen Sie im Fenster Agent Deployment die Agenten aus, die Sie zu dem Depot hinzufügen wollen, und klicken Sie auf Next.
v Prüfen Sie die Installationszusammenfassung, und klicken Sie auf Next, um die
Installation zu starten.
v Nachdem die Agenten zu dem Agentendepot hinzugefügt wurden, wird das
Fenster Setup Type angezeigt.
v Wählen Sie alle ausgewählten Komponenten ab, da die Komponenten bereits
konfiguriert sind. Klicken Sie auf Next.
v Klicken Sie auf Finish, um die Installation abzuschließen.
Verwenden Sie die nachfolgend aufgeführten Schritte, um das Agentendepot mithilfe des Installationsimage eines Anwendungsagenten unter Windows zu füllen:
v Starten Sie den Installationsassistenten, indem Sie doppelt auf die Datei "setup.exe" im Unterverzeichnis \Windows des Installationsimage klicken.
v Wählen Sie im Fenster Welcome die Option Next aus.
v Klicken Sie im Fenster Select Features auf Next, ohne Änderungen vorzunehmen.
v Wählen Sie im Fenster Agent Deployment die Agenten aus, die Sie zu dem Depot hinzufügen wollen, und klicken Sie auf Next.
v Prüfen Sie die Installationszusammenfassung, und klicken Sie auf Next, um die
Installation zu starten.
v Nachdem die Agenten zu dem Agentendepot hinzugefügt wurden, wird das
Fenster Setup Type angezeigt.
v Wählen Sie alle ausgewählten Komponenten ab, da die Komponenten bereits
konfiguriert sind. Klicken Sie auf Next.
v Klicken Sie auf Finish, um die Installation abzuschließen.
Verwenden Sie die nachfolgend aufgeführten Schritte, um das Agentendepot mithilfe des Linux- oder UNIX-Installationsimage zu füllen:
v Führen Sie den Befehl "./install.sh" in dem Verzeichnis aus, in das Sie die Installationsdateien extrahiert haben.
38
v Wenn Sie zur Eingabe des Ausgangsverzeichnisses von IBM Tivoli Monitoring
aufgefordert werden, drücken Sie die Eingabetaste, um den Standardwert ("/
opt/IBM/ITM") zu übernehmen. Wenn Sie ein anderes Installationsverzeichnis
verwenden wollen, geben Sie den vollständigen Pfad zu diesem Verzeichnis ein,
v Wenn das von Ihnen angegebene Verzeichnis nicht vorhanden ist, werden Sie
dazu aufgefordert, es zu erstellen. Geben Sie y ein, um das Verzeichnis zu erstellen.
v Wählen Sie in der folgenden Eingabeaufforderung die Option Install products to
depot for remote deployment (requires TEMS) aus, und drücken Sie die Eingabetaste.
v Eine Anzeige enthält die Lizenzvereinbarung. Akzeptieren Sie zum Fortsetzen
der Installation die Lizenzvereinbarung, und drücken Sie die Eingabetaste.
v Geben Sie die Zahl ein, die den Agenten entspricht, die Sie zum Agentendepot
hinzufügen wollen, und drücken Sie die Eingabetaste. Wenn Sie mehrere Agenten hinzufügen wollen, verwenden Sie als Trennzeichen zwischen den Zahlen
ein Komma (,). Geben Sie all ein, um alle verfügbaren Agenten auszuwählen.
v Sie können mehrere Agenten mit aufeinanderfolgenden entsprechenden Zahlen
auswählen, indem Sie die erste und die letzte Zahl für die Agenten eingeben,
wobei diese durch einen Silbentrennungsstrich (-) getrennt werden. Um beispielsweise alle Agenten zwischen 8 und 12 hinzuzufügen, müssen Sie "8-12"
eingeben.
v Um einen Agenten, den Sie zuvor ausgewählt haben, wieder abzuwählen, geben
Sie die Zahl für diesen Agenten erneut ein.
v Wenn Sie alle Agenten, die Sie zum Agentendepot hinzufügen wollen, ausgewählt haben, geben Sie E ein, und drücken Sie die Eingabetaste, um die Anzeige
zu verlassen.
Tabelle 2. Tasten für die Navigation in der Agentenliste
Taste
Navigation
U
Bewegt den Cursor in der Liste eine Zeile nach
oben.
D
Bewegt den Cursor in der Liste eine Zeile nach
unten.
F
Bewegt den Cursor in der Liste eine Seite nach
vorn.
B
Bewegt den Cursor in der Liste eine Seite zurück.
Agentendepot über die Eingabeaufforderung füllen:
Zum Füllen des Agentendepots über die Eingabeaufforderung wird der Befehl
tacmd addBundles verwendet. Bevor Sie den Befehl tacmd addBundles absetzen, müssen Sie zuerst sicherstellen, dass die Umgebung konfiguriert ist und die Anmeldung stattgefunden hat; hierfür werden die folgenden Befehle verwendet:
export CANDLEHOME=/opt/IBM/ITM
tacmd login -s <servername> -u <benutzername> -p <kennwort> -t <zeitlimit>
Dabei steht zeitlimit für einen Wert in Minuten im Bereich 0 bis 1440.
Setzen Sie anschließend den Befehl tacmd addBundles ab; dabei sieht die Syntax wie
folgt aus:
[-i IMAGEPFAD] [-t PRODUKTCODE] [-p BETRIEBSSYSTEM] [-v VERSION] [-n] [-f]
39
Die vollständige Syntax, einschließlich der Parameterbeschreibungen finden Sie im
Handbuch 'IBM Tivoli Monitoring Command Reference'.
Tabelle 3. Agentendepot füllen
Befehl
Beschreibung
tacmd addbundles -i
/mnt/cdrom/unix
Kopiert alle Agentenpakete einschließlich der Voraussetzungen in das Agentendepot auf einem
UNIX-Computer. Die Daten werden dabei den
Installationsmedien (CD-Image) entnommen, die im
Verzeichnis '/mnt/cdrom/' gespeichert sind.
tacmd addbundles -i
/mnt/cdrom/unix -t ud
Kopiert alle Agentenpakete für den DB2-Agenten in
das Agentendepot auf einem UNIX-Computer. Die
Daten werden dabei den Installationsmedien (CDImage) entnommen, die im Verzeichnis '/mnt/
cdrom/' gespeichert sind.
tacmd addbundles -i
D:\WINDOWS\Deploy -t ud
Kopiert alle Agentenpakete für den DB2-Agenten in
das Agentendepot auf einem Windows-Computer.
Die Daten werden dabei den Installationsmedien
(CD-Image) entnommen, die im Verzeichnis 'D:\
WINDOWS\Deploy' gespeichert sind.
Standardmäßig speichert der Befehl tacmd addBundles das Agentenpaket an der
Position, die in der Konfigurationsdatei des Überwachungsservers für die Variable
DEPOTHOME definiert wurde. Wenn Sie diese Position ändern wollen, müssen Sie
wie folgt vorgehen, bevor Sie den Befehl tacmd addBundles ausführen:
1. Öffnen Sie die Konfigurationsdatei des Überwachungsservers KBBENV im Verzeichnis '<itm_installationsverzeichnis>\CMS' unter Windows und im Verzeichnis
'<itm_installationsverzeichnis>/tables/<tems_name>' unter Linux und UNIX.
2. Suchen Sie die Variable DEPOTHOME. Wenn sie nicht vorhanden ist, fügen Sie
sie der Datei hinzu. Standardmäßig befindet sich das Agentendepot im Verzeichnis '<itm_installationsverzeichnis>/CMS/depot' unter Windows und im Verzeichnis '<itm_installationsverzeichnis>/tables/<tems_name>/depot' unter UNIX.
3. Geben Sie den Pfad zu dem Verzeichnis ein, das Sie für das Agentendepot verwenden wollen. Speichern und schließen Sie anschließend die Datei.
4. Nur unter UNIX oder Linux: Fügen Sie dieselbe Variable und dieselbe Position
zur Datei 'kbbenv.ini' hinzu, die sich im '<itm_installationsverzeichnis>/config/
kbbenv.ini' befindet.
5. Falls Sie die Variable nicht zur Datei 'kbbenv.ini' hinzufügen, wird die Variable
aus der Datei KBBENV gelöscht, wenn der Überwachungsserver das nächste
Mal rekonfiguriert wird.
Prüfen, ob Agenten in das Agentendepot gefüllt wurden:
Mithilfe des Befehls tacmd viewDepot können Sie prüfen, ob die Agenten in das
Agentendepot gefüllt wurden. Dieser Befehl listet alle Agenten aus dem Agentendepot auf. Bevor Sie diesen Befehl ausführen, müssen Sie sich anmelden und den
Status von Tivoli Enterprise Monitoring Server (TEMS) prüfen.
v Öffnen Sie die Managementkonsole mit dem Status von TEMS und TEPS. Führen Sie dazu den folgenden Befehl aus: itmcmd manage
v Stellen Sie sicher, dass TEMS betriebsbereit ist, und führen Sie anschließend den
Anmeldebefehl aus: tacmd login –s <TEMS_ip_adresse/hostname> -u <benutzername> -p <kennwort> -t <zeitlimit_minuten>
v Führen Sie den Befehl 'viewDepot' aus: tacmd viewDepot
40
Mithilfe der Befehle tacmd listBundles und tacmd removeBundles können Sie alle
Pakete auflisten, die im Installationsimage verfügbar sind, bzw. die Pakete aus dem
Agentendepot entfernen. Eine ausführlichere Beschreibung dieser Tivoli-Befehle
finden Sie im IBM Tivoli Monitoring Information Center.
Agenten implementieren
In diesem Abschnitt werden die Prozeduren beschrieben, die zur Implementierung
von Agenten ausgeführt werden müssen. Die Implementierung von Agenten bedeutet, dass die Installationsimages von dem zentralen Standort aus an die Knoten
im Netz verteilt werden.
Betriebssystemagenten implementieren:
Bevor Sie einen vom Betriebssystemagenten abweichenden Agenten implementieren können, müssen Sie einen Betriebssystemagenten auf dem Computer installieren, auf dem der vom Betriebssystemagenten abweichende Agent implementiert
werden soll. Neben der Überwachung der Leistung des Basisbetriebssystems wird
mit dem Betriebssystemagenten auch die erforderliche Infrastruktur für die Implementierung über Remotezugriff und die Wartung installiert. Der Betriebssystemagent kann mit dem Befehl tacmd createNode im folgenden Verzeichnis über Remotezugriff installiert werden: /opt/IBM/ITM/bin.
Der Befehl tacmd createNode erstellt auf dem Zielsystem ein Verzeichnis mit dem
Namen node. Die Betriebssystemagenten werden in diesem Verzeichnis installiert,
und alle vom Betriebssystemagenten abweichenden Agenten werden ebenfalls hier
implementiert.
Der Befehl tacmd createNode verwendet eines der folgenden Protokolle, um eine
Verbindung zu den Computern herzustellen, auf denen der Betriebssystemagent installiert werden soll:
v Server Message Block (SMB), hauptsächlich für Windows-Server verwendet
v Secure Shell (SSH), hauptsächlich von UNIX-Servern verwendet, aber auch unter
Windows verfügbar
v Remote Execution (REXEC), hauptsächlich von UNIX-Servern verwendet, aber
nicht sehr sicher
v Remote Shell (RSH), hauptsächlich von UNIX-Servern verwendet, aber nicht
sehr sicher
Sie können ein Protokoll angeben, das verwendet werden soll. Wenn Sie dies nicht
tun, wählt der Befehl tacmd createNode das geeignete Protokoll dynamisch aus.
Im Folgenden sehen Sie die Syntax für den Befehl tacmd createNode; dabei wird der
Eigenschaftswert zur Angabe des Protokolls verwendet. Eine vollständige Erläuterung aller Attribute für diesen Befehl finden Sie im Handbuch IBM Tivoli Monitoring and Setup Guide.
tacmd createnode -h <ISP-IP-adresse> -u <benutzername> -w <kennwort> -p <name=wert>
Dabei gilt Folgendes:
v -p name=wert (Einige Agenten benötigen angepasste Eigenschaften in Name/
Wert-Paaren)
v name = PROTOCOL oder PORT
v wert = IP.UDP, IP.PIPE, IP.SPIPE, SNA, wenn name=PROTOCOL
v wert = 1918 (wenn PORT=IP.UDP oder IP.PIPE angegeben wird)
v wert = 3660 (wenn PORT=IP.SPIPE angegeben wird)
41
v wert = nicht zutreffend (wenn PORT=SNA angegeben wird)
Implementierung des Betriebssystemagenten überprüfen:
Zur Implementierung des Betriebssystemagenten über Remotezugriff gehören das
Implementieren, Konfigurieren und Starten des Agenten. Wenn der Agent implementiert ist, können Sie anzeigen, dass er auf dem ISP ausgeführt wird. Um die
Implementierung des Betriebssystemagenten zu prüfen, können Sie den Agenten in
Tivoli Enterprise Portal (TEP) anzeigen oder die Protokolldatei öffnen. Die URL für
TEP lautet wie folgt: 'http://<TEMS_ip_adresse>:1920/'.
Auf einem Windows-Computer ist die Protokolldatei standardmäßig im folgenden
Verzeichnis verfügbar: '<CANDLEHOME>\tmaitm6\logs'. Dabei hat CANDLEHOME den Wert 'C:\IBM\ITM'. Auf einem Linux-Computer ist die Protokolldatei
standardmäßig im folgenden Verzeichnis verfügbar: '<CANDLEHOME>/logs/'.
Dabei hat CANDLEHOME den Wert '/opt/IBM/ITM'.
In der Protokolldatei können Sie prüfen, ob der Betriebssystemagent mit TEMS
kommuniziert. In der Protokolldatei wird TEMS als CMS bezeichnet. Um die Prüfung des Betriebssystemagenten in TEP auszuführen, können Sie sich am Portal anmelden und feststellen, ob der Betriebssystemagent angezeigt wird und ob die Systeminformationen des Windows-Computers aufgeführt werden.
Vom Betriebssystemagenten abweichende Agenten implementieren:
Vom Betriebssystemagenten abweichende Agenten können über Tivoli Enterprise
Portal (TEP) oder über die TEMS-Befehlszeile implementiert werden. Die Implementierung und Konfiguration der Agenten ist je nach dem verwendeten Agenten
unterschiedlich. Die folgende Prozedur besteht aus generischen Implementierungsinformationen. Die exakten Werte, die für Ihren Agenten erforderlich sind, können
Sie den Konfigurationsdaten im Benutzerhandbuch des jeweiligen Agenten entnehmen. Stellen Sie sicher, dass Sie Ihr Agentendepot mit Daten gefüllt haben, bevor
Sie versuchen, Agenten zu implementieren. Darüber hinaus müssen Sie bereits einen Betriebssystemagenten auf dem Computer (ISP) installiert oder implementiert
haben, auf dem Sie nun den vom Betriebssystemagenten abweichenden Agenten
implementieren. Vom Betriebssystemagenten abweichende Agenten sind 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 und Configuration Agent for WebSphere MQ.
Implementierung über TEP:
Sie können die folgenden Schritte ausführen, um einen Agenten über die PortalGUI zu implementieren:
v In einer Umgebung mit fernen TEMS-Dateien müssen Sie Unterstützungsdateien
vom fernen TEMS an den Hub-TEMS verteilen. Unter Linux können Sie den Kopiervorgang mit dem Befehl scp ausführen. Setzen Sie die folgenden Befehle auf
dem TEMS-Hub-System ab, und setzen Sie die Namen aus Ihrer Umgebung ein.
scp benutzerprofil@hostname_des_fernen_TEMS:/opt/IBM/ITM/tables/ferner_TEMS-server/ATTRLIB/*ATR*
/opt/IBM/ITM/tables/TEMS-hub-server/ATTRLIB
scp benutzerprofil@hostname_des_fernen_TEMS:/opt/IBM/ITM/tables/ferner_TEMS-server/RKDSCATL/*CAT*
/opt/IBM/ITM/tables/TEMS-hub-server/RKDSCATL
v Starten Sie nach dem Kopieren der Dateien die einzelnen TEMS-Server (sowohl
Hubsystem als auch fernes System) neu.
v Öffnen Sie Tivoli Enterprise Portal.
42
v Navigieren Sie in der Baumstruktur Navigation zu dem Computer, auf dem Sie
den Agenten implementieren wollen.
v Klicken Sie mit der rechten Maustaste auf den Computer und anschließend auf
Add Managed System.
v Wählen Sie den Agenten aus, den Sie implementieren wollen, und klicken Sie
dann auf OK.
v Füllen Sie die Konfigurationsfelder aus, die für den Agenten erforderlich sind.
Informationen zu diesen Feldern finden Sie in der Konfigurationsdokumentation
für den Agenten, den Sie gerade implementieren. Klicken Sie auf Finish.
v Wenn auf dem Computer, auf dem Sie den Agenten implementieren, bereits eine
Version dieses Agenten installiert ist, können Sie die Implementierung stoppen,
eine neue Instanz des Agenten hinzufügen (falls möglich) oder den bestehenden
Agenten rekonfigurieren.
v Klicken Sie auf Finish, um die Implementierung abzuschließen.
Implementierung über die TEMS-Befehlszeile:
Um einen Agenten über die Befehlszeile zu implementieren, können die folgenden
Befehle ausgeführt werden:
v tacmd listSystems: Findet die verwalteten Betriebssysteme (Managed OS), die
momentan mit TEMS verbunden sind.
v cinfo - Listet die Produktcodes für Agenten auf, die auf dem aktuellen Computer
installiert sind.
v tacmd addSystem
Der folgende Befehl installiert beispielsweise Universal Agent (Produktcode 'um')
auf dem Computer stone.ibm.com und gibt die Eigenschaft UA.CONFIG an:
tacmd addSystem -t um -n stone.ibm.com:LZ -p UA.CONFIG="datei_unix.mdl"
Dabei bezieht sich um auf den Produktcode von Universal Agent und UA.CONFIG
auf die Konfigurationseigenschaft sowie auf die MDL-Datei, die bei der Implementierung für die Konfiguration verwendet wird.
Wenn Sie Universal Agent implementieren, sollten Sie eine MDL-Datei und alle
Scripts angeben, auf die in dieser MDL-Datei verwiesen wird. Bevor Sie Universal
Agent implementieren können, speichern Sie die MDL-Datei im Agentendepot im
Unterverzeichnis /opt/IBM/ITM/tables/HUB_itmserver/depot/UACONFIG und die
Scripts im Unterverzeichnis /opt/IBM/ITM/tables/HUB_itmserver/depot/UACONFIG/
UASCRIPT. Diese beiden Unterverzeichnisse müssen erstellt werden. Verwenden Sie
das Agentendepot auf dem Überwachungsserver, zu dem Universal Agent eine
Verbindung herstellt.
Jedes Agentenpaket verfügt über eigene eindeutige Konfigurationsparameter, die
Sie in diesem Befehl angeben müssen. Wenn Sie über einen installierten Agenten
mit demselben Typ verfügen, den Sie auch implementieren wollen, können Sie die
Konfigurationsparameter anzeigen, indem Sie den folgenden Befehl ausführen:
tacmd describeSystemType -t pc -p plattform. Weitere Informationen zu agentenspezifischen Parametern finden Sie unter den folgenden Dokumentlinks:
v Betriebssystemagent und Universal Agent: http://publib.boulder.ibm.com/
infocenter/tivihelp/v15r1/topic/com.ibm.itm.doc_6.2.2fp1/using.htm
v IBM Tivoli OMEGAMON XE for Messaging Information Center: http://
publib.boulder.ibm.com/infocenter/tivihelp/v15r1/index.jsp?toc=/
com.ibm.omegamon.mes.doc/toc.xml
43
v IBM Tivoli Monitoring for Databases Information Center: http://
publib.boulder.ibm.com/infocenter/tivihelp/v15r1/index.jsp?toc=/
com.ibm.itmfd.doc/toc.xml
v IBM Tivoli Composite Application Manager Information Center: http://
publib.boulder.ibm.com/infocenter/tivihelp/v3r1/topic/
com.ibm.itcamwas.doc_6.1/welcome.htm
In einer Umgebung mit fernen TEMS-Dateien müssen Sie Unterstützungsdateien
vom fernen TEMS an den Hub-TEMS verteilen. Unter Linux können Sie den Kopiervorgang mit dem Befehl 'scp' ausführen. Setzen Sie die folgenden Befehle auf
dem TEMS-Hubsystem ab, und setzen Sie die Namen aus Ihrer Umgebung ein.
scp benutzerprofil@hostname_des_fernen_TEMS:/opt/IBM/ITM/tables/ferner_TEMS-server/ATTRLIB/*ATR*
/opt/IBM/ITM/tables/TEMS-hub-server/ATTRLIB
scp benutzerprofil@hostname_des_fernen_TEMS:/opt/IBM/ITM/tables/ferner_TEMS-server/RKDSCATL/*CAT*
/opt/IBM/ITM/tables/TEMS-hub-server/RKDSCATL
Starten Sie nach dem Kopieren der Dateien die einzelnen TEMS-Server (sowohl auf
dem Hubsystem als auch auf dem fernen System) neu.
Bei der Implementierung des DB2-Agenten müssen Sie beispielsweise die Eigenschaft INSTANCE wie folgt angeben: tacmd addSystem -t ud -n stone.ibm.com:LZ
-p INSTANCE=db2inst. Dabei bezieht sich ud auf den Produktcode des DB2-Agenten, LZ auf den Produktcode von Linux OS Agent und db2inst1 auf die Instanz, die
in DB2 verfügbar ist.
Der DB2-Agent muss als DB2-Benutzer oder als Benutzer mit DB2-Berechtigungen
ausgeführt werden. Bei einer fernen Implementierung erfolgt dies automatisch. Der
Befehl lautet wie folgt: su - db2inst1 -c "/opt/IBM/ITM/bin/itmcmd agent -o
db2inst1 start ud". Bearbeiten Sie nach der (lokalen oder fernen) Installation des
Agenten die Datei /opt/IBM/ITM/config/ud.ini auf dem ISP und fügen Sie
"CTIRA_HOSTNAME=$RUNNINGHOSTNAME$" hinzu. Führen Sie danach einen
Neustart des Agenten aus.
Bei der Installation des Tivoli OMEGAMON XE-Überwachungsagenten muss auf
der Maschine bereits einen Warteschlangenmanager installiert sein, damit der
Agent überwacht werden kann. Erstellen und starten Sie daher auf dem ISP einen
Warteschlangenmanager, indem Sie die folgenden Befehle absetzen:
su - mqmcrtmqm myqm1
strmqm myqm1
Nach der Erstellung des Warteschlangenmanagers kann der Agent überwacht werden. Denken Sie daran, dass ein Agent nicht ohne mindestens einen Warteschlangenmanager implementiert werden kann. Beim Installieren des Tivoli OMEGAMON XE-Agenten muss der Agent über einen Account gestartet werden, dessen
Primärgruppe mqm lautet. ISP: itmcmd agent -o qm1 start mq
Anmerkung: Wenn Sie den Befehl tacmd erstmals in der Shell ausführen, müssen
Sie sich beim Server anmelden, bevor Sie den Befehl tacmd ausführen: ./tacmd login -s <ip-adresse_des_TEMS-servers> -u
<benutzername_des_TEMS-servers> -p <kennwort_des_TEMS-servers>
ITCAM für WebSphere-Überwachungsagenten lokal implementieren
Eine lokale Implementierung umfasst das individuelle Laden der Überwachungsagentensoftware auf den einzelnen ISP-Maschinen.
Überwachungsagenten unter Windows installieren und konfigurieren:
44
In diesem Abschnitt wird beschrieben, wie Sie Überwachungsagenten auf einem
Windows-Computer lokal installieren und konfigurieren.
Führen Sie folgende Schritte aus, um einen Überwachungsagenten auf einem Windows-Computer zu installieren und zu konfigurieren.
1. Starten Sie den Installationsassistenten, indem Sie doppelt auf die Datei 'setup.exe' im Unterverzeichnis \WINDOWS des Installationsmediums klicken.
2. Klicken Sie im Willkommensfenster auf Next.
3. Klicken Sie auf Accept, um die Lizenzvereinbarung zu akzeptieren.
4. Wenn auf diesem Computer keine Datenbank installiert ist, wird eine Nachricht zu einer möglicherweise fehlenden Software angezeigt. Für die Installation eines Managementagenten auf diesem Computer ist keine Datenbank erforderlich; Sie können also auf Next klicken und diese Nachricht ignorieren.
5. Wählen Sie das Verzeichnis aus, in dem Sie das Produkt installieren möchten.
Klicken Sie auf Next.
Anmerkung: Dieser Schritt gilt nur für die Agenten, die Sie mithilfe des Installationsimages für IBM Tivoli Monitoring installieren. Dieser
Schritt gilt nicht für Agenten, die mithilfe des Agenteninstallationsimages installiert werden. Wenn Sie einen Agenten mithilfe
eines Agenteninstallationsimages installieren, fahren Sie mit
Schritt 7 fort.
6. Geben Sie einen 32-stelligen Verschlüsselungsschlüssel ein. Dieser Schlüssel
muss mit dem Schlüssel übereinstimmen, der bei der Installation des Überwachungsservers verwendet wurde, zu dem dieser Überwachungsagent eine Verbindung herstellt. Klicken Sie auf Next und anschließend auf OK, um den
Verschlüsselungsschlüssel zu bestätigen.
7. Erweitern Sie den Eintrag für die Tivoli Enterprise Monitoring Agents.
8. Wählen Sie den Namen des Agenten aus, den Sie installieren möchten, und
klicken Sie auf Next.
Anmerkung: Wenn Sie den Agenten auf einem Computer installieren, auf
dem bereits ein Überwachungsserver installiert ist, müssen Sie
als Nächstes das Depot füllen. Wenn sich auf diesem Computer
kein Überwachungsserver befindet, müssen Sie diesen Schritt
überspringen.
9. Geben Sie in Ihrem Startmenü einen Programmordner an, und klicken Sie auf
Next. Der Standardordner ist IBM Tivoli Monitoring.
Anmerkung: Dieser Schritt gilt nur für die Agenten, die Sie mithilfe des Installationsimages für IBM Tivoli Monitoring installieren. Dieser
Schritt gilt nicht für Agenten, die mithilfe des Agenteninstallationsimages installiert werden.
10. Überprüfen Sie die Details der Installationszusammenfassung. In dieser Zusammenfassung wird angegeben, welche Komponente Sie installieren, und es
wird die ausgewählte Installationsposition angegeben. Klicken Sie auf Next,
um mit der Installation der Komponenten zu beginnen. Nach der Installation
der Komponenten und der Initialisierung der Konfigurationsumgebung wird
ein Konfigurationsfenster angezeigt.
11. Klicken Sie auf Next, um mit der Konfiguration der Standardwerte für Ihren
Agenten zu beginnen.
45
12. Geben Sie die Standardwerte für sämtliche IBM Tivoli Monitoring-Agenten an,
die bei der Kommunikation mit dem Überwachungsserver verwendet werden
sollen.
v Wenn der Agent eine Firewall überwinden muss, um auf den Überwachungsserver zuzugreifen, wählen Sie die Option Connection must pass
through firewall aus.
v Geben Sie den Typ des Protokolls an, das der Agent bei der Kommunikation mit dem Überwachungsserver verwendet. Sie haben vier Auswahlmöglichkeiten: IP.UDP, IP.PIPE, IP.SPIPE oder SNA. Sie können drei Kommunikationsverfahren angeben; dadurch haben Sie die Möglichkeit,
Backupkommunikationsverfahren einzurichten. Wenn das Verfahren, das Sie
als Protokoll 1 angegeben haben, fehlschlägt, wird Protokoll 2 verwendet.
Klicken Sie auf OK.
13. Vervollständigen Sie die folgenden Felder, um die Kommunikationsverfahren
zwischen Agenten und dem Überwachungsserver zu definieren.
Tabelle 4. Kommunikationsprotokolleinstellungen
Feld
Beschreibung
IP.UDP - Einstellungen
Hostname oder IP-Adresse
Der Hostname oder die IP-Adresse für den
Hubüberwachungsserver.
Portnummer und/oder Port-Pools
Der Empfangsport für den
IP.PIPE - Einstellungen
Portnummer
Überwachungsserver. Die Standardnummer
lautet 1918.
IP.SPIPE - Einstellungen
Portnummer
Hubüberwachungsserver. Der Standardwert
lautet 3660.
SNA-Einstellungen
Netzname
Die SNA-Netzkennung für Ihren Standort.
LU-Name
Der LU-Name für den Überwachungsserver.
Dieser LU-Name entspricht dem Aliasnamen
der lokalen LU in Ihrer SNADatenübertragungssoftware.
LU 6.2-Protokollmodus
Der Name des LU6.2-Protokollmodus. Der
Standardwert ist CANCTDCS.
Transaktionsprogrammname
Der Transaktionsprogrammname für den
Überwachungsserver.
Aliasname der lokalen LU
Der LU-Aliasname.
14. Klicken Sie auf Finish, um die Installation abzuschließen.
15. Öffnen Sie das Dienstprogramm zum Verwalten von Tivoli Enterprise Monitoring-Services (falls es nicht automatisch geöffnet wird), um festzustellen, ob
46
der Überwachungsagent konfiguriert und gestartet wurde. Wenn Yes in der
Spalte Configured angezeigt wird, wurde der Agent beim Installationsprozess
konfiguriert und gestartet.
16. Wenn in der Spalte Configured kein Wert angezeigt wird und Template in
der Spalte für 'Task/Subsystem' angezeigt wird, klicken Sie mit der rechten
Maustaste auf den Schablonenagenten, und führen Sie die folgenden Schritte
aus:
v Klicken Sie auf Configure Using Defaults.
v Geben Sie in allen Fenstern, in denen Informationen angegeben werden
müssen, die entsprechenden Informationen an, indem Sie die agentenspezifischen Konfigurationseinstellungen aus dem Benutzerhandbuch Ihres
Agenten verwenden.
Anmerkung: In diesen Fenstern dürfen keine anderen Zeichen als ASCIIZeichen eingegeben werden. Wenn Sie Zeichen anderer Zeichensätze eingeben, führt dies zu unvorhersehbaren Ergebnissen.
v Wiederholen Sie bei Bedarf diesen Schritt, um Überwachungsagenteninstanzen für die einzelnen zu überwachenden Anwendungsinstanzen zu erstellen.
Überwachungsagenten unter Linux installieren und konfigurieren:
In diesem Abschnitt wird beschrieben, wie Sie einen Überwachungsagenten auf einem Linux-Computer lokal installieren und konfigurieren. Unter Linux gibt es separate Schritte für die Installation und Konfiguration eines Überwachungsagenten.
Den Überwachungsagenten unter Linux installieren
Führen Sie folgende Schritte aus, um einen Überwachungsagenten auf einem Linux-Computer zu installieren:
1. Führen Sie in dem Verzeichnis, in das Sie die Installationsdateien extrahiert
haben, den folgenden Befehl aus: ./install.sh.
2. Wenn Sie zur Eingabe des Ausgangsverzeichnisses von IBM Tivoli Monitoring
aufgefordert werden, drücken Sie die Eingabetaste, um den Standardwert
(/opt/IBM/ITM) zu übernehmen, oder geben Sie den vollständigen Pfad zu einem anderen Verzeichnis ein.
3. Wenn das Installationsverzeichnis nicht vorhanden ist, werden Sie dazu aufgefordert, es zu erstellen. Geben Sie y ein, um dieses Verzeichnis zu erstellen,
4. Es wird eine Eingabeaufforderung angezeigt, in der Sie die Auswahl zwischen
den folgenden Installationsoptionen haben: Install products to the local host,
Install products to depot for remote deployment (requires TEMS) und Exit
install. Wählen Sie die erste Option aus, um den Installationsprozess zu starten.
Anmerkung: Je nach dem Installationsimage, von dem Sie die Installation
vornehmen, kann diese Eingabeaufforderung unterschiedlich
aussehen.
5. Geben Sie die Zahl für die Sprache ein, in der Sie die Softwarelizenzvereinbarung anzeigen möchten, und drücken Sie die Eingabetaste.
6. Drücken Sie die Eingabetaste, um die Vereinbarung anzuzeigen.
47
7. Geben Sie 1 ein, um die Vereinbarung zu akzeptieren, und drücken Sie die
Eingabetaste.
8. Geben Sie einen 32-stelligen Verschlüsselungsschlüssel ein, und drücken Sie
die Eingabetaste. Dieser Schlüssel muss mit dem Schlüssel übereinstimmen,
der bei der Installation des Überwachungsservers verwendet wurde, zu dem
dieser Überwachungsagent eine Verbindung herstellt. Eine nummerierte Liste
der verfügbaren Betriebssysteme wird angezeigt.
9. Geben Sie die Nummer des Betriebssystems ein, auf dem Sie die Installation
vornehmen. Der Standardwert ist Ihr aktuelles Betriebssystem. Drücken Sie
die Eingabetaste.
10. Geben Sie y ein, um das Betriebssystem zu bestätigen, und drücken Sie die
Eingabetaste. Eine nummerierte Liste der verfügbaren Komponenten wird angezeigt.
11. Geben Sie die Zahl ein, die dem bzw. den Überwachungsagenten entspricht,
den/die Sie installieren wollen. Wenn Sie mehrere Agenten installieren wollen,
verwenden Sie als Trennzeichen zwischen den Zahlen ein Komma (,) oder ein
Leerzeichen. Drücken Sie die Eingabetaste. Eine Liste der zu installierenden
Komponenten wird angezeigt.
12. Geben Sie y ein, um die Installation zu bestätigen. Die Installation wird gestartet.
13. Nachdem alle Komponenten installiert sind, werden Sie gefragt, ob Sie Komponenten für ein anderes Betriebssystem installieren wollen. Geben Sie n ein,
und drücken Sie die Eingabetaste. Der Installationsprozess wird abgeschlossen.
Anmerkung: Es gibt ein bekanntes Problem mit einer lokalen Installation einiger
ITM-Agenten unter Linux. Die Installation schlägt fehl, da sie eine
neuere Version eines Pakets namens GSkit feststellt, wenn ITM versucht, eine ältere Version zu installieren. Tivoli stellt die folgende
Ausweichlösung bereit, die die Modifikation des Scripts runGSkit
umfasst: Das Script runGSkit befindet sich im Verzeichnis '/bin'. Diese Datei wird geändert, wenn eine neue Plattformunterstützung hinzugefügt wird, dies geschieht üblicherweise bei jedem neuen Fixpack.
Führen Sie ein Backup des Scripts durch, bevor Sie Änderungen vornehmen.
cd /bin
cp runGSkit runGSkit.orig
Bearbeiten Sie runGSkit, und nehmen Sie die folgenden Änderungen
vor:
v Suchen Sie eine Instanz des Textes 'string version=7', und fügen
Sie die folgenden zwei Zeilen im Anschluss an die gesuchte Zeile
ein:
versionPref=$(print $version | cut -d. -f1-3)
versionSuff=$(print $version | cut -d. -f4)
v Suchen Sie weiter nach einer Instanz des Textes 'string version=7'.
Handelt es sich dabei um eine andere Stelle, dann fügen Sie die
folgenden zwei Zeilen im Anschluss an die gesuchte Zeile ein:
versionPref=$(print $version | cut -d. -f1-3)
versionSuff=$(print $version | cut -d. -f4)
v Ändern Sie alle Vorkommen von 'grep $version' in 'grep $versionPref'. Suchen Sie die zwei Zeilen:
48
[ -n "$gskitVersion" ] && loop=no
[ -n "$gskitVersion_64" ] && loop_64=no
Setzen Sie Kommentarzeichen vor diese Zeilen.
v Fügen Sie das Folgende im Anschluss an die neu mit Kommentarzeichen versehenen Zeilen ein:
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
Speichern Sie die Datei, und führen Sie 'install.sh' erneut aus.
v Nachdem runGSkit aktualisiert und getestet ist, können Sie das
Medienimage aktualisieren, sodass Sie diese Ausweichlösung nicht
auf jede Maschine anwenden müssen, die Sie installieren wollen.
v Wenn Sie die Medien auf einem externen Datenträger gespeichert
haben, kopieren Sie sie auf die Festplatte, sodass Sie Schreibzugriff
darauf haben. Wenn sich die Medien z. B. auf der Platte unter
/MEDIAHOME befinden und die getestete Installation unter
/ITMHOME, könnten Sie mit folgenden Befehlen das Image aktualisieren:
cd /ITMHOME
chmod 755 /MEDIAHOME/unix/cienv.tar
tar -rvf /MEDIAHOME/unix/cienv.tar bin/runGSkit bin/runGSkit.orig
Überwachungsagenten konfigurieren
Führen Sie folgende Schritte aus, um Ihren Überwachungsagenten zu konfigurieren:
1. Führen Sie den folgenden Befehl aus:
./itmcmd config -A pc
Dabei ist pc der Produktcode Ihres Agenten. Für Linux müssen Sie lz verwenden.
2. Drücken Sie die Eingabetaste, wenn Sie gefragt werden, ob der Agent eine Verbindung zu einem Überwachungsserver herstellt.
3. Geben Sie den Hostnamen für den Überwachungsserver ein.
4. Geben Sie das Protokoll ein, das Sie für die Kommunikation mit dem Überwachungsserver verwenden wollen. Sie haben vier Auswahlmöglichkeiten: ip, sna,
ip.spipe und ip.pipe. Drücken Sie die Eingabetaste, um das Standardprotokoll
(IP.PIPE) zu übernehmen.
49
5. Wenn Sie ein Sicherungsprotokoll einrichten möchten, geben Sie dessen Namen
ein, und drücken Sie die Eingabetaste. Wenn Sie kein Sicherungsprotokoll verwenden möchten, drücken Sie die Eingabetaste ohne ein Protokoll anzugeben.
6. Geben Sie in Abhängigkeit vom angegebenen Protokolltyp folgende Informationen ein, wenn Sie dazu aufgefordert werden:
Tabelle 5. Protokolle und Werte für UNIX-Überwachungsserver
Protokoll
Wert
IP.UDP
Die Portnummer für den Überwachungsserver. Der Standardwert ist
1918.
SNA-Netzname
Die SNA-Netzkennung für Ihren Standort.
LU-Name
Der LU-Name für den Überwachungsserver. Dieser LU-Name entspricht dem Aliasnamen der lokalen LU in Ihrer SNADatenübertragungssoftware.
Protokollmodus
Der Name des LU6.2-Protokollmodus. Der Standardwert ist
CANCTDCS.
IP.PIPE
1918.
IP.SPIPE
3660.
7. Drücken Sie die Eingabetaste ohne den Namen der Partition KDC_PARTITION
anzugeben.
8. Drücken Sie die Eingabetaste, wenn Sie aufgefordert werden, die Verbindung
zu einem sekundären Überwachungsserver zu konfigurieren. Der Standardwert
ist 'no'.
9. Drücken Sie die Eingabetaste, um den Standardwert "none" für den optionalen
primären Netznamen (Optional Primary Network Name) zu übernehmen.
Dateiberechtigungen ändern
In diesem Abschnitt wird der Prozess zur Änderung der Dateiberechtigungen für
Agenten beschrieben. Wenn Sie auf einem UNIX-Computer einen Überwachungsagenten als Benutzer ohne Rootberechtigung installiert haben, werden die Dateiberechtigungen zu Anfang auf eine niedrige Stufe gesetzt. Gehen Sie wie folgt vor,
um diese Dateiberechtigungen zu ändern:
1. Melden Sie sich bei dem Computer als Root an, oder führen Sie den Befehl su
aus, um die Rootberechtigung zu erhalten.
2. Erstellen Sie eine neue Gruppe, beispielsweise itmusers, um Eigner aller Dateien im Installationsverzeichnis von IBM Tivoli Monitoring zu werden. Führen
Sie den folgenden Befehl aus: groupadd itmusers.
3. Führen Sie den folgenden Befehl aus, um sicherzustellen, dass die Umgebungsvariable CANDLEHOME das Installationsverzeichnis von IBM Tivoli
Monitoring ordnungsgemäß angibt:
echo $CANDLEHOME
Wenn Sie die folgenden Schritte im falschen Verzeichnis ausführen, werden
unter Umständen die Berechtigungen für alle Dateien in allen Dateisystemen
des Computers geändert.
4. Wechseln Sie in das Verzeichnis, das bei dem vorigen Schritt zurückgegeben
wurde:
cd $CANDLEHOME
50
5. Führen Sie den folgenden Befehl aus, um sicherzustellen, dass Sie sich im
richtigen Verzeichnis befinden:
pwd
6. Führen Sie folgende Befehle aus:
chgrp -R itmusers
chmod -R o-rwx
7. Führen Sie den folgenden Befehl aus, um den Eigner der zusätzlichen Agentendateien zu ändern:
bin/SetPerm
8. Wenn Sie den Agenten als bestimmter Benutzer ausführen wollen, müssen Sie
diesen Benutzer zur Gruppe 'itmusers' hinzufügen. Bearbeiten Sie dazu die
Datei /etc/group, und stellen Sie sicher, dass der Benutzer in der Benutzerliste
von 'itmusers' enthalten ist. Wenn Sie beispielsweise den Agenten als Benutzer
test1 ausführen wollen, müssen Sie sicherstellen, dass in der Datei /etc/group
die folgende Zeile enthalten ist:
itmusers:x:504:test1
9. Führen Sie den Befehl su aus, um zu dem Benutzer zu wechseln, unter dessen
Namen der Agent ausgeführt werden soll, oder melden Sie sich als dieser Benutzer an.
10. Starten Sie den Agenten, wie im Abschnitt 'Überwachungsagenten starten' beschrieben.
Überwachungsagenten starten
Sie können entweder alle Agenten, die auf einem Computer ausgeführt werden,
oder einzelne Agenten über die Produktcodes starten.
Führen Sie zum Starten aller Überwachungsagenten den folgenden Befehl aus:
/opt/IBM/ITM/bin/itmcmd agent start all
Führen Sie zum Starten bestimmter Agenten den folgenden Befehl aus:
/opt/IBM/ITM/bin/itmcmd agent start pc [hostname...]
Dabei ist pc der Produktcode für den Agenten, den Sie starten wollen. Der Produktcode für Universal Agent beispielsweise lautet um. Eine vollständige Liste der
Produktcodes finden Sie im Tivoli ITM Information Center.
Deinstallation
Das IBM WebSphere Remote Server-Deinstallationsscript entfernt die gesamte WebSphere Remote Server-Lösung, einschließlich IBM WebSphere Application Server,
DB2 oder Informix Growth Edition und IBM WebSphere MQ. Darüber hinaus entfernt es alle Komponenten, die der Lösung durch Erweiterung von WebSphere Remote Server möglicherweise hinzugefügt wurden.
WebSphere Remote Server deinstallieren
1. Stoppen Sie die komplette WebSphere Remote Server-Lösung, bevor Sie das
Deinstallationsprogramm ausführen.
Der Deinstallationsprozess ruft das Script wrsstop auf, es kann aber sein, dass
noch einige Komponenten der Lösung aktiv sind, wie z. B. die WebSphere MQWarteschlangenmanager.
2. Navigieren Sie zum Unterverzeichnis bin von SIF_HOME.
3. Führen Sie folgende Befehle aus:
51
cd %SIF_HOME%\bin
SifRemoveWRS.bat -noprompt [clean]
Der Befehl SifRemoveWRS.bat -noprompt -clean entfernt das Verzeichnis SIF_HOME unter Windows nicht.
cd $SIF_HOME/bin
./SifRemoveWRS.sh -noprompt [clean]
Hinweise:
v -noprompt ist ein erforderlicher Parameter, der verhindert, dass Sie
WebSphere Remote Server unbeabsichtigt deinstallieren. Wird dieser
Parameter übergangen, wird WebSphere Remote Server nicht deinstalliert.
v -clean ist ein optionaler Parameter. Wenn -clean nicht angegeben ist,
werden lediglich die einzelnen Produktdeinstallationsprogramme aufgerufen. Wenn -clean angegeben ist, werden von den Produktdeinstallationsprogrammen zusätzliche Schritte zum Entfernen sämtlicher
Teile jedes Produkts ausgeführt. Es werden z. B. Installationsverzeichnisse gelöscht, erstellte Benutzer werden gelöscht usw.
Option clean verwenden
Wenn Sie eine vollständige Deinstallation durchführen, werden alle WebSphere Remote Server-Dateien gelöscht, möglicherweise bleiben jedoch noch einige leere
Verzeichnisse vorhanden. Diese leeren Verzeichnisse können problemlos entfernt
werden.
Anmerkung: Es empfiehlt sich, dass Sie die Option clean verwenden, wenn Sie
Informix Growth Edition deinstallieren. Jedoch können trotz einer
vollständigen Deinstallation bei der erneuten Installation von Informix Growth Edition Probleme auftreten. Weitere Informationen finden Sie im Abschnitt „Tipps zur Fehlerbehebung” auf Seite 131.
Die Option clean führt die folgenden Tasks aus:
v Windows:
– cmd /c net user MUSR_MQADMIN /DELETE
– cmd /c net localgroup mqm /DELETE
– Löscht den Ordner 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
–
–
–
–
52
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 und Linux:
– Löscht das WRS-Basisinstallationsverzeichnis
– rd /s /q IFMXDATA
– rd /s /q ISM
– Entfernt alle Zeilen, die mit WSBAA, WSPAA oder WHIHS beginnen, aus Ihrer Datei vpd.properties. Die Windows-Datei befindet sich in %SYSTEMROOT%\
vpd.properties, die Linux-Datei befindet sich in /root/vpd.properties.
– Löscht das WebSphere Application Server-Installationsverzeichnis.
– Löscht das IBM HTTP Server-Installationsverzeichnis.
– Löscht das WebSphere MQ-Installationsverzeichnis.
– Löscht das DB2-Installationsverzeichnis.
– Löscht das Informix Growth Edition-Installationsverzeichnis.
Deinstallationsprozess erweitern
Wenn Sie die WebSphere Remote Server-Lösung erweitern, können Sie Deinstallationsbefehle in den Metadaten für die hinzuzufügende Anwendung hinzufügen. Das
Deinstallationsscript führt alle Deinstallationen der Benutzeranwendung aus, bevor
es die WebSphere Remote Server-Middlewareprodukte deinstalliert.
Nach Deinstallation erneut installieren
Wenn Sie WebSphere Remote Server nach einer Deinstallation des Produkts erneut
installieren wollen, ändern Sie die Installationsverzeichnisse für WebSphere Application Server und IBM HTTP Server, um zu verhindern, dass die erneute Installation fehlschlägt.
Die erneute Installation von Informix Growth Edition nach einer nicht vollständigen Deinstallation wird nicht unterstützt. Weitere Informationen finden Sie im Abschnitt „Tipps zur Fehlerbehebung” auf Seite 131.
53
54
Kapitel 3. Aktualisierung oder Migration durchführen
In diesem Abschnitt werden die Schritte beschrieben, die Sie für eine erfolgreiche
Aktualisierung oder Migration von IBM WebSphere Remote Server ausführen müssen.
Aktualisierungsstrategie
Es wird empfohlen, dass IBM WebSphere Remote Server mit einer einheitlichen
Aktualisierungslösung aktualisiert wird.
Bei dieser Methode können Sie Programmkorrekturen (Fixes) für die Middleware,
Anwendungen und Betriebssysteme zu einem einzelnen Paket für eine reibungslosere Migration kombinieren. WebSphere Remote Server bietet zwei einheitliche Lösungen für die Migration von Vorgängerreleases, die lokal über eine grafische Benutzerschnittstelle installiert werden können. Die Lösungen werden im Abschnitt
„Migration” auf Seite 63 beschrieben.
Wenn Sie Ihre eigene Aktualisierungslösung erstellen wollen, führen Sie die Schritte für die Erstellung einer Lösung in Kapitel 5, „Erweiterung”, auf Seite 95 aus. Für
die Erstellung der Lösung benötigen Sie die WebSphere Remote Server-Entwicklungsumgebung. Wenn Sie Aktualisierungen für IBM Produkte benötigen, die nicht
in der WebSphere Remote Server-Entwicklungsumgebung enthalten sind, müssen
Sie diese von der Website 'http://www.ibm.com/support' herunterladen und neue
Anwendungsprojekte erstellen. Anwendungsprojekte werden in Kapitel 5,
„Erweiterung”, auf Seite 95 beschrieben.
Halten Sie sich bei der Erstellung einer Aktualisierungslösung an die folgenden
Richtlinien:
v Löschen Sie die nicht benötigten Dateien aus den Paketen. Wenn das Paket für
Windows-Betriebssysteme bestimmt ist, schließen Sie keine ausschließlich für
Linux-Betriebssysteme erforderlichen Dateien ein.
v Beschränken Sie die Eingabeanzeigen der Benutzerschnittstelle. WebSphere Remote Server stellt Dienstprogramme zur Verfügung, die über das Programm ermitteln, wo IBM Middleware installiert ist.
WebSphere Remote Server-Fixpacks und vorläufige Fixes
IBM WebSphere Remote Server stellt bei Bedarf Fixpacks oder vorläufige Fixes zur
Verfügung. Fixpacks von WebSphere Remote Server werden normalerweise als
Lösungen bereitgestellt, die mithilfe von Software Assembly Toolkit entwickelt
wurden. Vorläufige Fixes (provisorische Änderungen) werden normalerweise als
Dateigruppe und möglicherweise als einfaches Installationsprogramm bereitgestellt.
55
Tabelle 6. Aktualisierungstypen, die von WebSphere Remote Server bereitgestellt werden
Aktualisierungen
Merkmale jeder Aktualisierung
Release
v Ein neuer WebSphere Remote Server, der
wichtige neue Funktionen enthält (wie z.
B. Version 7.1)
v Ist als Software Assembly Toolkit-Lösung
gepackt
v Umfassendes Testen aller Anwendungen
mit neuem Release wird empfohlen
v Erfordert Migration, um das Upgrade
durchzuführen
56
Tabelle 6. Aktualisierungstypen, die von WebSphere Remote Server bereitgestellt werden (Forts.)
Aktualisierungen
Fixpack
v Standardmäßig werden Aktualisierungen
auf diese Weise bereitgestellt und sind bereits einem Regressionstest unterzogen
worden
gepackt
v Ein Fixpack ist ein kumulatives Paket mit
Fixes, z. B. Fixpack 1 unter Version 7.1
(7.1.0.1)
v Jede Bereitstellung eines Fixpacks kann
aus mehreren Fixpacks für die folgenden
Produkte oder Komponenten bestehen:
– 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
– WebSphere Remote ServerEntwicklungsumgebung
v Fixpacks werden über ein Release oder
einen vorherigen Fixpack installiert, wie z.
B. das Anwenden von Version 7.1.0.2 auf
Version 7.1.0.1.
v Fixpacks sind kumulativ, das bedeutet,
Version 7.1.0.2 enthält alle Fixes aus Version 7.1.0.1.
v Fixpacks deinstallieren alle vorläufigen
Fixes, die auf das Release seit der Installation des letzten Fixpacks angewendet
wurden. Daher ist es notwendig, die Liste
der bereitgestellten Fixes zu überprüfen,
um festzustellen, ob ein vorläufiger Fix
erneut installiert werden muss.
v Ein kurzer Test der kritischen Funktionen
mit dem neuen Fixpack wird empfohlen
v Prüfen Sie die Liste der Fixes und
Installationsanweisungen, um zu ermitteln, ob eine Migration erforderlich ist.
57
Tabelle 6. Aktualisierungstypen, die von WebSphere Remote Server bereitgestellt werden (Forts.)
Aktualisierungen
Vorläufiger Fix
v Eine einzelne veröffentlichte provisorische
Änderung.
v Ein Fix ist ein vorläufiger Fix, der mindestens einen Produktfehler behebt.
v WebSphere Remote Server stellt in der
Regel keine vorläufigen Fixes für WebSphere Remote ServerMiddlewareprodukte bereit. Fixes für
Middlewareprodukte können von der IBM
Unterstützungssite für jedes
Middlewareprodukt heruntergeladen werden. WebSphere Remote Server-Fixes werden für WebSphere Remote ServerKomponenten bereitgestellt.
v Ein Fix kann sowohl auf ein Release als
auch auf ein Fixpack angewendet werden.
v Vorläufige Fixes werden erstellt, wenn ein
Standalone-Fix zwischen Fixpacks benötigt wird.
v Es wird empfohlen, die Funktionen zu
testen, die von der korrigierten WebSphere Remote Server-Komponente betroffen sind.
Änderung
gepackt.
v Ein Änderungsrelease ist ein optionales
Upgrade.
v Änderungsreleases werden über ein Release oder ein vorheriges Fixpack installiert.
v Eine Migration ist möglicherweise erforderlich. Prüfen Sie die Liste der Fixes und
Installationsanweisungen, um zu ermitteln, ob eine Migration erforderlich ist.
Tivoli Provisioning Manager - Remote Management Agent Bridge
Die Komponente IBM Tivoli Provisioning Manager-IBM Remote Management
Agent Bridge, die im Lieferumfang von IBM WebSphere Remote Server enthalten
ist, bietet Unterstützung beim Auslösen von Software-Updates für die Geschäftsterminals des Unternehmens.
Tivoli Provisioning Manager wird zum Verteilen eines Pakets an den ISP verwendet. Anschließend entpackt Tivoli Provisioning Manager-Remote Management
Agent Bridge das Paket und verteilt es an Terminals, die mit dem ISP verbunden
sind.
Installationsvoraussetzungen
Für das Unternehmen sind ein Tivoli Provisioning Manager-Server und eine installierte WebSphere Remote Server-Entwicklungsumgebung erforderlich.
58
IBM Tivoli Provisioning Manager-IBM Remote Management Agent Bridge wird automatisch installiert, wenn IBM WebSphere Remote Server auf einem ISP installiert
wird.
Für Tivoli Provisioning Manager-Remote Management Agent Bridge ist die Konfiguration von WebSphere Remote Server Enterprise und Tivoli Provisioning Manager erforderlich.
Für Tivoli Provisioning Manager-Remote Management Agent Bridge ist es erforderlich, dass der ISP von WebSphere Remote Server als Endpunkt für WebSphere Remote Server Enterprise konfiguriert wird. Das Installationsprogramm für Endpunkte wird auch als Tivoli Common Agent bezeichnet.
Für Tivoli Provisioning Manager-Remote Management Agent Bridge ist es darüber
hinaus erforderlich, dass die Geschäftsterminals mit dem Geschäfts-ISP verbunden
sind und dass auf diesen Terminals die Komponente 'General Agent' vorhanden
ist, die bei Remote Management Agent Master Agent registriert ist.
Anmerkung: Für Tivoli Provisioning Manager-Remote Management Agent Bridge
ist es erforderlich, dass Remote Management Agent für keine Verbindung die Verwendung von SSL erzwingt. Aktualisieren Sie die Datei
'SI_HOME/user/rma/classes/ssl.properties' mit den folgenden Änderungen, um Remote Management Agent entsprechend zu konfigurieren:
v RMA.alias=NOSSL
v RMAMA.alias=NOSSL
TPM-RMA-Installation konfigurieren
Die Konfiguration von IBM Remote Management Agent V2 erfolgt über die Datei
'info.properties'. Die Musterdatei 'info.properties' ist nachfolgend bereitgestellt.
Führen Sie die folgenden Schritte aus, um die TPM-RMA-Bridge (Tivoli Provisioning Manager-Remote Management Agent) zu konfigurieren:
1. Installieren Sie Remote Management Agent V2.6 Master Agent auf dem ISP.
Master Agent muss für die Verwendung der Netzschnittstellenkarte (NIC) konfiguriert sein, die über General Agent ermittelt werden kann.
2. Installieren Sie Remote Management Agent V2.6 General Agent auf einem anderen Server, der sich im selben Netz wie Master Agent befindet.
Anmerkung: In Remote Management Agent Master Agent V2.6 stehen zwei
Modi (Standardmodus und erweiterter Modus) zur Verfügung.
Um von einem Modus zum anderen zu wechseln, bearbeiten Sie
den Wert für 'com.ibm.retail.si.mgmt.security.mode' in der Datei
SI_HOME/user/rma/security/security.properties. Nach dem Moduswechsel müssen Sie den Remote Management Agent-Service
neu starten. Beispiel:
v Erweiterter Modus:
com.ibm.retail.si.mgmt.security.mode=enhanced
v Standardmodus:
com.ibm.retail.si.mgmt.security.mode=standard
3. Bearbeiten Sie die Datei RMA SI_HOME/user/rma/classes/ssl.properties auf allen Remote Management Agent-Maschinen. Starten Sie nach dem Aktualisieren
der folgenden ssl.properties-Dateien die Remote Management Agent-Services
neu:
59
v RMA.alias=NOSSL
v RMAMA.alias=NOSSL
4. Bearbeiten Sie die Datei <SIF_HOME>\RmaBridge\info.properties.
a. Aktualisieren Sie die folgenden Felder. (Wenn Sie die Standardsicherheitseinstellungen verwenden, gilt für ' EnhancedSecurity' der Wert 'false'.)
v isEnhancedSecurity
v rmaUsername
v rmaPassword
b. Aktualisieren Sie die folgenden Parameter der jeweiligen Umgebung entsprechend. Beispiele:
v ftpPackageDir=C:\\Program Files\\IBM\\SIF\\RmaBridge\\
v ftpPolicyDir=C:\\Program Files\\IBM\\SIF\\RmaBridge\\
Anmerkung: Damit die Softwareverteilung für die Einheiten ausgeführt werden kann, übertragen Sie die Softwarerichtlinie und das Softwarepaket für das jeweilige Terminal an die ISP-Maschine. Die Richtlinien-XML ist im Ordner 'policies' und die auf dem Terminal zu
installierende Software im Ordner 'packages' enthalten.
Softwareverteilung für TPM-RMA
Die Softwarerichtlinie und die Software für das Terminal sollten die ISP-Ordner
übertragen werden, wie im vorliegenden Abschnitt beschrieben.
Softwareverteilung mithilfe des Softwareverteilerpakets (SPD-Datei) auslösen
Erstellen Sie ein IBM Tivoli Provisioning Manager-Softwareverteilerpaket (SPD-Datei, SPD = Software Package Definition, Softwarepaketdefinition) als Wrapper für
Ihr Remote Management Agent-Softwarepaket, das das enthaltene Script 'TriggerScript.sh' ausführt. Die folgenden SPD-Musterdateien sind enthalten:
RmaBridgeSampleWin
RmaBridgeSampleLin
Das Script 'TriggerScript' akzeptiert sechs Argumente, die vom Installationspaket
übergeben werden müssen.
Verteilen Sie diese SPD-Datei von Tivoli Provisioning Manager an die Endpunkte
(ISP), um die Richtliniendatei und die Software wie oben angegeben auf die jeweiligen Ordner zu verteilen.
./TriggerScript.sh version mode
Die folgenden Parameter werden verwendet:
version
Die Version ist Remote Management Agent V2.6.
mode
60
Der Wert lautet entweder 'install' oder 'uninstall'.
Remote Management Agent V2.6 Bridge
Dieser Abschnitt enthält Informationen zur IBM Remote Management Agent
Bridge-Standardfunktion.
Die erforderlichen Schritte für die Verwendung der Remote Management Agent
Bridge-Standardfunktion für IBM WebSphere Remote Server-Lösungen sind im Folgenden aufgeführt.
v General Agent und Master Agent von Remote Management Agent müssen sich
im selben Teilnetz befinden und eine ordnungsgemäße Kommunikation durchführen können.
v Der Softwarepaketeditor muss auf dem Unternehmensserver installiert sein, wo
er für die Veröffentlichung von SPB-Dateien im IBM Tivoli Provisioning Manager-Repository verwendet werden kann.
v Die WebSphere Remote Server-Laufzeitlösung ist auf dem ISP installiert.
Remote Management Agent-Verzeichnisstruktur
Nach der Installation der WebSphere Remote Server-Entwicklungslösungen auf
dem Unternehmensserver werden die folgenden Remote Management Agent
Bridge-Dateien in der folgenden Verzeichnisstruktur gespeichert:
%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
Remote Management Agent-Dateibeschreibung
info.properties
In dieser Datei sind die Informationen enthalten, die von Remote Management Agent General Agent zum Anmelden am Server sowie zum Extrahieren der Daten und Richtliniendateien verwendet werden. Aktualisieren Sie
die folgenden Felder in dieser Datei:
v ftpPackageDir
v ftpPolicyDir
v policyXMLFileName
v isEnhancedSecurity
v rmaUsername
v rmaPassword
v clientTargetPath
Sie können die Datei 'info.properties' wie folgt aktualisieren:
v ftpPackageDir: Geben Sie hier das Verzeichnis an, in dem die Paketdateien gespeichert sind. Alle Pakete, auf die in Ihrer Richtliniendatei ver-
61
wiesen wird, müssen sich in diesem Ordner befinden. Diese Eigenschaft
muss mit dem Dateitrennzeichen (/) enden (z. B. package/).
v ftpPolicyDir: Geben Sie hier das Verzeichnis an, in dem die Richtliniendateien gespeichert sind. Dieses Verzeichnis muss die Softwarerichtlinie
enthalten, die Sie verteilen (policyXMLFileName). Diese Eigenschaft
muss mit dem Dateitrennzeichen (/) enden (z. B. policy/).
v policyXMLFileName: Der Name der Richtliniendatei für die Remote
Management Agent-Softwareverteilung. Sie benötigen eine Kopie dieser
Datei im Stammverzeichnis RmaBridge sowie im Verzeichnis, das unter
ftpPolicyDir angegeben wird.
instructions.txt
Dies ist die Datei, die vom Paket 'SamplePolicy.xml' bereitgestellt wird. Sie
wird für Remote Management Agent General Agent in der Verzeichnisstruktur %SI_HOME%/user/rma/config/swd/staging bereitgestellt.
SamplePolicy.xml
Diese Datei enthält die Liste der Befehle, die auf der General Agent-Maschine ausgeführt werden sollen. Im Benutzerhandbuch zu Remote Management Agent finden Sie Informationen zu dieser Datei sowie zu deren Bearbeitung: ftp://ftp.software.ibm.com/software/retail/pubs/sw/
storeintegration/bqe3_RMA_userguide_mst.pdf.
TriggerScript.bat(sh)
Durch diese Datei wird der RMA Bridge-Code mit zwei Parametern aufgerufen, die über die SPB-Datei übergeben werden.
RmaBridgeSampleWin.spd
Dieses Softwarepaket enthält Anweisungen zum Speichern der Dateien
'SamplePolicy.xml' und 'instructions.txt' auf dem ISP.
Diese Datei enthält Anweisungen zum Ausführen des Scripts 'TriggerScript.bat' auf dem ISP. Die SPD-Datei übergibt insgesamt sechs Parameter, die zum Aufrufen des Scripts 'TriggerScript.bat' auf dem ISP verwendet werden. Sie können sämtliche Parameter in der SPD-Datei bearbeiten, bevor Sie sie in eine SPB-Datei umwandeln. Für den ersten Parameter
muss der Wert V2 definiert werden, damit der Remote Management Agent
V2.6 Bridge-Code verwendet wird. Der zweite Parameter kann entweder
install oder uninstall lauten. Bei der Verwendung von install führt General Agent nur den Tag <installation> in der Datei SamplePolicy.xml aus.
Bei der Verwendung von uninstall führt General Agent nur den Tag <uninstallation> in der Datei SamplePolicy.xml aus.
RmaBridgeSampleLin.spd
Die Linux-Version der Datei 'RmaBridgeSampleWin.spd'.
Remote Management Agent V2.6 Bridge-Code verwenden
Führen Sie die nachfolgend beschriebenen Schritte aus, um den Remote Management Agent V2.6 Bridge-Code zu verwenden.
v Verwenden Sie den Softwarepaketeditor, um alle SPD-Dateien in SPB-Dateien zu
konvertieren und um sie in Tivoli Provisioning Manager zu veröffentlichen.
Nehmen Sie alle erforderlichen Änderungen vor, bevor Sie die SPD-Dateien in
SPB-Dateien konvertieren.
v Verwenden Sie die Tivoli Provisioning Manager-Funktionalität zum Veröffentlichen, Verteilen und Installieren der Dateien RmaBridgeSampleLinD.spb bzw.
RmaBridgeSampleWinD.spb in Abhängigkeit vom Betriebssystem des ISPs. Stellen Sie sicher, dass nach dem Senden der SPB-Datei der grüne Balken im Task-
62
Manager von Tivoli Provisioning Manager angezeigt wird. Der grüne Balken bedeutet, dass der Vorgang erfolgreich war.
Anmerkung: Informationen zum Einrichten des Softwarepaketeditors und der skalierbaren Tivoli Provisioning Manager-Infrastruktur sowie zum Installieren der SPB-Dateien finden Sie im White Paper WebSphere Remote Server Solution und im Abschnitt Packaging software for distribution
in der Tivoli Provisioning Manager-Onlinehilfe.
1. Der Softwarepaketeditor ist eine Browseranwendung, die IBM
Java Runtime Environment 1.5 erfordert. Er unterstützt neuere
Versionen von Java nicht.
2. Bevor Sie ein Softwarepaket speichern, überprüfen Sie den WebServer-Hostnamen (Web server hostname) in Ihren Einstellungen.
Es sollte sich um den Hostnamen Ihres Tivoli Provisioning Manager-Servers handeln.
Migration
IBM WebSphere Remote Server unterstützt die automatisierte Migration von Filialrechnern von den Versionen 6.1, 6.2, 6.2.1, 7.0 und 7.1 auf die Version 7.1.1 der
WebSphere Remote Server-Editionen.
Der Migrationsprozess ist in derselben Lösung enthalten, die für Neuinstallationen
verwendet wird, und kann von der DVD ausgeführt werden.
Die Tabelle listet die unterstützte Migration für unterschiedliche Betriebssysteme
auf. Ist ein Betriebssystem nicht aufgeführt, dann ist für dieses Betriebssystem keine unterstützte Migration vorhanden.
Anmerkung:
v Die Migration auf 64-Bit-Betriebssystemen wird nur für das Migrieren von WebSphere Remote Server V7.1 unterstützt. Die Migration für alle anderen Versionen wird nur auf 32-Bit-Betriebssystemen unterstützt.
v Die Migration von Windows XP mit Service-Pack 2 sowie von
SUSE Linux Enterprise Server 10.1 und 10.2 wird weiterhin unterstützt. Windows XP mit Service-Pack 2 (32-Bit) sowie SUSE Linux
Enterprise Server 10.1 und 10.2 werden jedoch in WebSphere Remote Server V7.1.1 nicht mehr unterstützt.
Tabelle 7. Liste mit Betriebssystemen und unterstützter Migration
Version von WebSphere Remote Server, die
migriert werden kann
Betriebssystem
Microsoft Windows 2003 Server mit ServicePack 2
6.1, 6.2, 6.2.1, 7.0, 7.1
Microsoft Windows 2003 Server R2 mit Service-Pack 2
6.1, 6.2, 6.2.1, 7.0, 7.1
SUSE Linux Enterprise Server 10.1 und 10.2
6.2, 6.2.1, 7.0, 7.1
Red Hat Enterprise Linux 5.2 und 5.3
6.2.1, 7.0, 7.1
Microsoft Windows XP mit 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
63
Tabelle 7. Liste mit Betriebssystemen und unterstützter Migration (Forts.)
Betriebssystem
Version von WebSphere Remote Server, die
migriert werden kann
SUSE Linux Enterprise Server 11
7.1
Anmerkung: Eine Migration der Entwicklungsumgebung ist nicht vorgesehen. Unterschiedliche Versionen von IBM Software Assembly Toolkit können
koexistieren, gleichgeordnete Aktualisierungen oder Fixpacks jedoch
nicht. So können Sie beispielsweise die Versionen 2.1.x, 2.2.x und 3.1
auf einem Computer installieren, nicht jedoch die Versionen 2.1.1
und 2.1.2.
Migration auf 7.1.1
Vorbereitende Schritte
v Stellen Sie sicher, dass Sie den WebSphere MQ-Warteschlangenmanager gestoppt
haben, bevor Sie die Migration ausführen. Anweisungen zum Stoppen des Warteschlangenmanagers finden Sie im entsprechenden Thema im IBM WebSphere
MQ Information Center.
v Wenn Sie auf das Betriebssystem Windows 2003 migrieren, müssen Sie sicherstellen, dass Sie vor der Migration den Microsoft-Patch MS08-067 installieren.
Ohne diesen Patch schlägt die Migration auf WebSphere Application Server fehl.
v Wenn Sie eine Migration von Version 6.1 auf einem Windows 2003-Betriebssystem durchführen, muss die WebSphere Application Server-Sicherheit aktiviert
sein. Erstellen Sie eine Datei mit dem Namen C:\temp\WAS_ID_PW.txt, die Ihren
WebSphere Application Server-Benutzernamen und das zugehörige Kennwort
enthält, bevor Sie das Installationsprogramm von WebSphere Remote Server starten. Die Datei sollte z. B. Folgendes enthalten:
MyWasAdminUser
MyWasAdminPw
v Für die Migration auf einem SUSE Linux Enterprise Server-Betriebssystem der
Version 10.1 oder 10.2 müssen Sie zuerst ein Upgrade auf SUSE Linux Enterprise
Server 10.3 durchführen, bevor Sie die Migration auf Version 7.1.1 ausführen.
SUSE Linux Enterprise Server 10.1 und 10.2 werden in WebSphere Remote Server V7.1.1 nicht mehr unterstützt.
v Bei einer Migration von V6.1 müssen Sie darüber hinaus den Wert für den Klassenpfad im JDBC-Provider auf den Wert der Umgebungsvariablen
${DB2UNIVERSAL_JDBC_DRIVER_PATH} setzen, bevor Sie den Migrationsprozess starten. Diese Variable wird während der Migration aktualisiert. Andernfalls
schlägt die Testverbindung für die Datenquelle der Musteranwendungen nach
Abschluss der Migration fehl. Anweisungen zum Festlegen des Werts für den
Klassenpfad im JDBC-Provider finden Sie unter "JDBC-Provider mit der Administrationskonsole konfigurieren" im WebSphere Application Server Version 6.1
Information Center.
Vorgehensweise
Hinweise:
64
wird Deployment Wizard vorübergehend auf Ihrem Festplattenlaufwerk installiert. Nach Abschluss der Installation von Deployment Wizard wird dieser
3. Klicken Sie auf I accept both the IBM and the non-IBM terms (Ich akzeptiere
4. Klicken Sie auf Next, wenn die Begrüßungsseite geöffnet wird, um mit der Installation fortzufahren.
5. Wählen Sie Migration von WebSphere Remote Server 6.1 oder 6.2.x oder Migration von WebSphere Remote Server 7.0 oder 7.1 aus, abhängig von der
Version, von der aus Sie die Migration ausführen möchten.
6. Die Laufzeit und die Middlewarekomponenten sind vorausgewählt. Klicken
Sie auf Weiter, um fortzufahren.
Anmerkung: Es sind nur die Komponenten vorausgewählt, die in der Version, von der aus die Migration ausgeführt werden soll, bereits installiert sind. Zur Installation von Komponenten, die zuvor nicht
installiert waren, müssen Sie nach der Migration WebSphere Remote Server Solution Installer starten und die zu installierenden
Komponenten über die Option Retail Store Server-Laufzeit installieren auswählen. Weitere Informationen zu dieser Prozedur
finden Sie in „IBM WebSphere Remote Server installieren” auf
Seite 12.
7. Geben Sie ein Installationsverzeichnis für die Basiskomponente von IBM Retail
Store Server an und klicken Sie auf Weiter. Dieser Wert ist die Umgebungsvariable SIF_HOME. Sie können für SIF_HOME bedenkenlos dasselbe Verzeichnis verwenden, in dem sich Ihre vorhandene WebSphere Remote Server-Installation befindet.
Anmerkung: Sie können den Wert von SIF_HOME nicht ändern, wenn Sie
eine Migration durchführen.
8. Geben Sie in den übrigen Anzeigen erforderliche und optionale Installationsparameter an, wenn Sie von Deployment Wizard dazu aufgefordert werden.
Eine detaillierte Beschreibung der Felder finden Sie im Abschnitt „Felder für
die Laufzeitinstallation” auf Seite 20.
65
Hinweise:
v Das Installationsverzeichnis für WebSphere Application Server
muss sich vom vorhandenen WebSphere Application Server-Installationspfad unterscheiden.
v Das Installationsverzeichnis, die Administrator-ID und das
Kennwort für DB2 müssen mit denen übereinstimmen, die für
das vorhandene DB2 angegeben wurden. Hierbei gilt jedoch eine
Ausnahme. Bei der Migration von Version 6.2 oder 6.2.1 auf Version 7.1.1 auf einem Linux-Betriebssystem darf das Installationsverzeichnis nicht mit dem vorhandenen DB2-Installationspfad
übereinstimmen.
v Die Installationsverzeichnisse für IBM HTTP Server und WebSphere MQ dürfen nicht von den vorhandenen Installationspfaden für IBM HTTP Server und WebSphere MQ abweichen.
10. Wenn die Installation unter einem Windows-Betriebssystem erfolgt ist, führen
Sie Folgendes aus:
v Führen Sie einen Warmstart für Ihren Server aus, damit das Betriebssystem
die Aktualisierungen übernehmen kann.
v Aktualisieren Sie die Portnummer im Direktaufruflink für die WebSphere
Application Server-Verwaltungskonsole in Ihrem Startmenü. Lesen Sie die
folgenden technischen WebSphere Application Server-Hinweise, um weitere
Informationen zu erhalten: http://www.ibm.com/support/
docview.wss?rs=180&uid=swg21385225
66
Im Abschnitt zur IBM WebSphere Remote Server-Verwaltung werden verschiedene
Verwaltungstasks beschrieben, die ausgeführt werden müssen, um einen guten
Funktionsstatus von WebSphere Remote Server zu gewährleisten.
WebSphere Remote Server steuern
ISPs, die mit dem IBM WebSphere Remote Server-Middlewarekomponentenstack
konfiguriert wurden, müssen über die Fähigkeit verfügen, die Anwendungen zu
starten, zu stoppen oder diese einzeln oder als Serverstack zu ihrem Ausführungsstatus abzufragen.
Funktionsübersicht
Es stehen Scripts zur Verfügung, mit denen die WebSphere Remote Server-Lösung
unter Verwendung unterschiedlicher Granularitätsgrade gesteuert werden kann.
Die WebSphere Remote Server-Middlewarekomponentenanwendungen werden gestartet, gestoppt oder ihr Ausführungsstatus wird abgefragt, indem die entsprechenden Befehle abgesetzt werden. Die Befehle werden lokal auf dem ISP durch
lokales Aufrufen oder von einer fernen Maschine ausgeführt, die Prozesse auf dem
ISP ausführen kann.
Für das Absetzen der Befehle zum Starten, Stoppen oder Abfragen des Ausführungsstatus für den ISP sind Kenntnisse ISP-maschinenspezifischer Informationen
erforderlich, damit die Befehlstask vollständig ausgeführt werden kann. Das Verwalten der Informationen, die für die vollständige Ausführung der Befehle auf
dem ISP nötig sind, bietet ein Höchstmaß an Flexibilität, wenn die Befehlsanforderungen von fernen Maschinen abgesetzt werden. Wenn Anwendungen hinzugefügt, gelöscht oder modifiziert werden, ist es möglicherweise nicht erforderlich, die
aktualisierten Anwendungsinformationen an eine ferne, zentralisierte Position zurückzusenden.
Wie erhält der ISP die Informationen zum Starten, Stoppen oder Abfragen des Ausführungsstatus der Middleware, die auf den ISP geladen wurde? WebSphere Remote Server erfasst die maschinenspezifischen Informationen, wenn die Middlewarekomponenten auf der Maschine installiert werden. Die erfassten Daten werden in
der WebSphere Remote Server-Metadatendatei auf dem ISP gespeichert.
Sobald die maschinenspezifischen Middlewareinformationen erfasst sind, kann eine
Anwendung auf dem ISP starten, stoppen oder den Ausführungsstatus abfragen,
indem das entsprechende Script auf dem ISP aufgerufen wird. Die Scripts verwenden die Middlewareinformationen aus der WebSphere Remote Server-Metadatendatei, um die Befehlstask für das Starten, Stoppen oder Abfragen des Status auszuführen.
Bei der WebSphere Remote Server-Metadatendatei handelt es sich um eine XMLDatei, die die Konfigurations- und Steuerungsinformationen für die auf dem ISP
installierten WebSphere Remote Server-Middlewarekomponenten enthält. Die in
dieser Datei enthaltenen Informationen werden anfangs während der WebSphere
Remote Server-Installation abgerufen.
67
WebSphere Remote Server-Steuerscripts
Die folgenden Scripts stehen zur Steuerung des Middleware-Stacks und der Anwendungen (Starten, Stoppen bzw. Abfragen des Ausführungsstatus) in WebSphere
Remote Server zur Verfügung; sie befinden sich im Verzeichnis 'SIF_HOME/bin':
v wrsstart.sh – Startet den Stack oder eine Anwendung.
v wrsstop.sh – Stoppt den Stack oder eine Anwendung.
v wrsrunstatus.sh: Fragt den Ausführungsstatus des Stacks oder der Anwendung
ab.
v wrsstart.bat: Startet den Stack oder eine Anwendung.
v wrsstop.bat: Stoppt den Stack oder eine Anwendung.
v wrsrunstatus.bat: Fragt den Ausführungsstatus des Stacks oder der Anwendung
ab.
Die oben aufgeführten Scripts können für die gesamte WebSphere Remote ServerLösung sowie alle Anwendungen und Unterkomponenten ausgeführt werden, die
in der WebSphere Remote Server-Lösung enthalten sind.
Anmerkung: Führen Sie in einem neuen Befehlszeilenfenster die Befehle zum Starten (start) und Stoppen (stop) sowie die Befehle zum Abfragen des
Ausführungsstatus aus. Die Befehle können nicht von dem Befehlszeilenfenster aus abgesetzt werden, das Sie zum Installieren verwendet haben, da die Umgebung aktualisiert werden muss. Durch Öffnen eines neuen Fensters wird die Umgebung aktualisiert.
Das Format für jeden Befehl ist nachfolgend dargestellt:
wrsstart [anwendung || anwendungsname unterkomponentenname] [-silent -log -verbose]
wrsstop [anwendung || anwendungsname unterkomponentenname] [-silent -log -verbose]
wrsrunstatus [anwendung || anwendungsname unterkomponentenname] [-silent -log -verbose]
Die folgenden Parameter sind optional:
v -silent: Befehlsausgabeinformationen werden nicht in der Anzeige ausgegeben.
v -log: Befehlsausgabeinformationen werden in der Protokolldatei ausgegeben.
v -verbose: Ausführliche Informationen zur Debugbefehlsausgabe werden im angegebenen Ausgabetyp ausgegeben.
Der Ergebnistext für die Befehlsausgabe wird standardmäßig in der Anzeige ausgegeben.
Für WebSphere Remote Server-Stackoperationen wird beim Abschluss des Befehls
der folgende Statuscode zurückgegeben:
v 0: Die Befehlsrückkehrcodes geben die erfolgreiche Ausführung aller Befehle an2
v 1: Die Befehlsrückkehrcodes geben an, dass mindestens ein Befehl nicht erfolgreich ausgeführt wurde2
v 2: Die Beendigungscodes für die Befehle sind nicht bekannt; z. B. können die Befehle nicht ausgeführt werden2
Für einzelne WebSphere Remote Server-Komponentenoperationen wird beim Abschluss des Befehls der folgende Statuscode zurückgegeben:
68
Befehle wrsstart und wrsstop:
v 2: Der Beendigungscode für den Befehl ist unbekannt, das heißt beispielsweise,
dass der Befehl nicht ausgeführt werden kann1
v Beliebiger Wert: Tatsächlicher Code, der nach der Befehlsausführung zurückgegeben wurde (kann '2' lauten, falls '2' ein gültiger Code für den Befehl ist)1
Der Befehl wrsrunstatus:
v 0: Abgefragtes Element wird ausgeführt2
v 1: Abgefragtes Element wird nicht ausgeführt2
v 2: Ausführungsstatus für abgefragtes Element ist nicht vollständig bekannt2
1
Der zurückgegebene Code gibt den Beendigungsstatus für den Start- oder Stoppbefehlsprozess an. Der Code gibt nicht an, ob der Stack oder die Anwendung gestartet oder gestoppt wurden. Überprüfen Sie mithilfe des Befehls 'wrsrunstatus',
ob der Stack bzw. die Anwendung ausgeführt wird.
2
Die Rückkehrcodes der Befehle werden in 0, 1 oder 2 normalisiert.
Wenn die Befehlsprotokollierung für den Befehl mithilfe des Parameters '-log' aktiviert wurde, wird jeder relevante Rückgabestatus in der Datei
SIF_HOME/logs/wrscommands.log protokolliert.
Die Scripts 'wrsstart', 'wrsstop' und 'wrsrunstatus' nutzen Hilfsscripts, die für die
individuellen Komponenten spezifisch sind. Diese Scripts sind im Folgenden aufgelistet. Sie befinden sich im Verzeichnis 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
Beispiele für WebSphere Remote Server-Steuerscripts
Die WebSphere Remote Server-Steuerscripts können verwendet werden, um Lösungen, Anwendungen oder Anwendungsunterkomponenten zu starten. In diesem
Abschnitt sind verschiedene Beispiele dargestellt, die die Verwendung der Steuerscripts veranschaulichen.
Bei der Installation von WebSphere Remote Server erhält die Lösung den Namen
WRS; sie stellt den gesamten Middleware-Stack dar. Eine Lösung besteht aus Anwendungen, die die einzelnen Middlewarekomponenten darstellen. Die Standardanwendungen, aus denen die Lösung WRS besteht, sind nachfolgend aufgeführt:
v IBM WebSphere Application Server
v DB2
v Informix Growth Edition
69
v IBM HTTP Server
v IBM WebSphere MQ
Lösung
Für die Steuerung auf Lösungsebene können die vorgefertigten Scripts verwendet
werden. Die Syntax für die Steuerung auf Lösungsebene lautet wie folgt:
v wrsstart - Starten der Lösung.
v wrsstop - Stoppen der Lösung.
v wrsstatus - Abfragen des Ausführungsstatus der Lösung.
Anwendungen und Unterkomponenten
Anwendungen und Unterkomponenten von Anwendungen können mithilfe der
oben aufgeführten WebSphere Remote Server-Steuerscripts gesteuert werden.
Die Syntax für diese Scripts wird nachfolgend aufgeführt:
Die folgenden Parameter sind optional:
v -silent: Informationen zur Befehlsausführung werden nicht in der Anzeige ausgegeben.
v -log: Informationen zur Befehlsausführung werden in der Protokolldatei ausgegeben.
v -verbose: Ausführliche Informationen zur Debugbefehlsausführung werden im
angegebenen Ausgabetyp ausgegeben.
Wenn z. B. das WebSphere Application Server-Profil 'WRSProfile' im Debugmodus
gestartet werden soll, lautet der Befehl: wrsstart WAS WRSProfile –verbose.
Die Debuginformationen werden in der Anzeige angezeigt.
Wenn das WebSphere Application Server-Profil 'WRSProfile' im Debugmodus gestartet werden soll, die Debuginformationen jedoch nicht am Bildschirm angezeigt
werden sollen, lautet der Befehl: wrsstart WAS WRSProfile -silent -log –verbose.
Die Debuginformationen werden nur in der Protokolldatei dokumentiert.
Neben dem Steuern einzelner Anwendungen oder Unterkomponenten kann auch
eine Auflistung der Elemente auf Anwendungs- und Unterkomponentenebene vorhanden sein. In diesem Fall wird die Liste genau wie die Liste im oben angeführten Lösungsbeispiel verarbeitet.
Weitere Informationen zum Erweitern der Verwendung der Steuerscripts finden Sie
im Abschnitt „WebSphere Remote Server- und ISP-Anwendungen steuern” auf Seite 121.
70
Ereignisse überwachen
Dieser Abschnitt enthält eine Beschreibung der für Accelerators spezifischen Verwaltungstasks und Überwachungstools.
JMX-Ereignislistener verwenden
Ein JMX-Ereignislistener wird als MBean unter IBM Remote Management Agent
ausgeführt und leitet bestimmte, von den Proxy-MBeans veröffentlichte JMX-Ereignisse von Remote Management Agent an den angepassten Ereignismapper weiter.
Diese angepassten Ereignismapper müssen die Schnittstelle 'com.ibm.sif.event.JMXEventMapper' implementieren. Sie können beispielsweise einen angepassten Ereignismapper erstellen, der SNMP-Traps weiterleitet. Ein JMX-Ereignislistener unterdrückt je nach Konfiguration die Weiterleitung bestimmter Ereignisklassen.
Remote Management Agent wird nicht mehr als Teil von IBM WebSphere Remote
Server geliefert bzw. installiert. Accelerators unterstützten jedoch Remote Management Agent weiterhin.
Wenn Remote Management Agent manuell oder mithilfe eines Upgrades für IBM
Retail Environment SUSE Linux (IRES) aktualisiert wird, müssen Sie die folgenden
Schritte durchführen:
v Gehen Sie in der jeweiligen Umgebung wie folgt vor:
Anmerkung: Wenn Remote Management Agent nicht über die Umgebungsvariable COMMON_HOME verfügt, müssen Sie für COMMON_HOME
denselben Wert definieren wie für RMA_HOME.
IBM Retail Environment SUSE Linux
Ersetzen Sie den Wert der Variablen RMA_HOME in der Datei
/opt/ibm/SIF/bin/SifSetupCmdLine.sh durch den Wert derselben Variablen RMA_HOME, der in der Datei /etc/sysconfig/storeintegrator angegeben ist.
Ersetzen Sie den Wert der Variablen COMMON_HOME in der Datei
/opt/ibm/SIF/bin/SifSetupCmdLine.sh durch den Wert derselben Variablen COMMON_HOME, der in der Datei /etc/sysconfig/
storeintegrator angegeben ist.
Microsoft Windows
Ersetzen Sie den Wert der Variablen RMA_HOME in der Datei
C:\Program Files\IBM\SIF\bin\SifSetupCmdLine.bat durch den Wert
derselben Umgebungsvariablen RMA_HOME.
Ersetzen Sie den Wert der Variablen COMMON_HOME in der Datei
C:\Program Files\IBM\SIF\bin\SifSetupCmdLine.bat durch den Wert
derselben Umgebungsvariablen COMMON_HOME.
Anmerkung: In der Microsoft Windows-Umgebung werden die Variablen RMA_HOME und COMMON_HOME nach der Installation bzw. nach
dem Upgrade von Remote Management Agent als Umgebungsvariablen definiert.
v Installieren Sie SNMP Trap Mapper erneut und verwenden Sie dabei das Accelerators-Installationsscript.
Weitere Informationen zu Remote Management Agent finden Sie in der Veröffentlichung Remote Management Agent User's Guide, die im Abschnitt zu Remote MaKapitel 4. Verwaltung
71
nagement Agent auf der folgenden Website verfügbar ist: http://
www2.clearlake.ibm.com/store/support/html/pubs.html.
JMX-Ereignislistener starten und stoppen
Ein JMX-Ereignislistener wird in IBM Remote Management Agent als MBean ausgeführt. Remote Management Agent kann so konfiguriert werden, dass ein JMXEreignislistener beim Starten von Remote Management Agent automatisch gestartet
und beim Stoppen von Remote Management Agent automatisch gestoppt wird.
Die Syntax dieser XML-Dateien wird in der Veröffentlichung Remote Management
Agent User's Guide beschrieben, auf die über den Abschnitt zu Remote Management Agent der folgenden Website zugegriffen werden kann: http://
www2.clearlake.ibm.com/store/support/html/pubs.html.
Die XML-Datei für diesen MBean-Start kann zwei Zeichenfolgeargumente enthalten.
v Der Klassenname des zu verwendenden JMX-Ereignismappers (z. B. 'com.ibm.sif.event.mapper.snmp.TrapGenerator' für eine SNMP-Trapgenerierungsfunktion).
Dieses Argument ist erforderlich.
v Eine durch Kommata getrennte Liste mit Namen von Benachrichtigungsklassen,
die vom JMX-Ereignislistener nicht weitergeleitet werden sollen. Die durch Kommata getrennten Komponenten können auch als reguläre Ausdrücke angegeben
werden. Dieses Argument ist optional.
Diese Konfigurationsdatei muss sich im Verzeichnis RMA_HOME\config\startup befinden.
Musterkonfigurationsdatei: 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 wird nach der Installation (unter Windows und Linux)
und einem Neustart (unter Windows) automatisch gestartet. Wenn Sie jedoch Änderungen an einer Konfigurationsdatei vorgenommen haben, müssen Sie Remote
Management Agent erneut starten, damit diese Änderungen wirksam werden.
Geben Sie den folgenden Befehl ein, um Remote Management Agent auf dem ISP
zu starten:
Linux: /etc/init.d/rmsvc-ma start
Windows: Starten Sie IBM Remote Management Agent über das Fenster
Dienste.
72
Geben Sie den folgenden Befehl ein, um Remote Management Agent auf dem ISP
zu stoppen:
Linux: /etc/init.d/rmsvc-ma stop
Windows: Stoppen Sie IBM Remote Management Agent über das Fenster
Dienste.
Standardereignisweiterleitung ändern
Ein JMX-Ereignislistener kann so konfiguriert werden, dass die Weiterleitung bestimmter Benachrichtigungsklassen unterdrückt wird.
Modifizieren Sie die XML-Konfigurationsdatei für den Agentenstart, über die der
JMX-Ereignislistener gestartet wird, wenn Sie die Weiterleitung bestimmter Benachrichtigungsklassen unterdrücken möchten.
Ändern Sie das zweite Vorkommen von 'MBeanArg' in der MBean für einen JMXEreignislistener. Das Argument muss eine Liste von durch Kommata getrennten
Namen von Benachrichtigungsklassen sein, die von einem JMX-Ereignislistener
nicht weitergeleitet werden sollen. Die durch Kommata getrennten Komponenten
können auch als reguläre Ausdrücke angegeben werden.
Definieren Sie den Parameter z. B. wie folgt, wenn Benachrichtigungen für Warnungen und zur Fehlerbehebung (Debug) unterdrückt werden sollen:
.*Warning.*,.*Debug.*
JMXEventMapper-Schnittstelle
Sie können eine eigene Erweiterung für den JMX-Ereignislistener erstellen, die
JMX-Ereignisse auf spezielle Weise verarbeitet. Sie müssen die Schnittstelle 'com.ibm.sif.event.JMXEventMapper' implementieren, die in der Datei
JMXEventListener.jar enthalten ist.
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);
}
Der neue Code muss in eine JAR-Datei integriert und im Ordner RMA_HOME\ext installiert werden. Darüber hinaus muss eine neue MBean-Startdatei erstellt und in
RMA_HOME\config\startup installiert werden. Starten Sie schließlich IBM Remote
Management Agent erneut, damit die Änderung wirksam wird.
Protokolldateien und Traceerstellung des JMX-Ereignislisteners
verwenden
Verwenden Sie die Traceerstellung eines JMX-Ereignislisteners als Hilfe bei der
Fehlerbehebung.
73
Standardmäßig wird die Traceerstellung an den folgenden Positionen protokolliert:
Linux: /opt/ibm/StoreIntegrator/silogs/simgmt.0
Windows: C:\Program Files\IBM\StoreIntegrator\silogs\simgmt.0
Aktivieren Sie für die Fehlerermittlung die ausführliche Traceerstellung eines JMXEreignislisteners.
Vorgehensweise
1. Bearbeiten Sie die Datei 'mgmt_log.pro' auf dem ISP. Diese Datei befindet sich
in einem der folgenden Verzeichnisse:
Linux: /opt/ibm/StoreIntegrator/RMA<rma-build-version>. Dabei bezieht
sich <rma-build-version> auf den Wert der Variablen RMA_BUILD, die in der
Datei /opt/ibm/SIF/bin/SifSetupCmdLine.sh angegeben ist.
Windows: C:\Program Files\IBM\StoreIntegrator\RMA<rma-build-version>.
Dabei bezieht sich <rma-build-version> auf den Wert der Variablen RMA_BUILD, die in der Datei C:\Program Files\IBM\SIF\bin\
SifSetupCmdLine.bat angegeben ist.
2. Ändern Sie die Zeile com.ibm.retail.level = FINEST.
3. Starten Sie den Master Agent-Server auf dem ISP erneut.
v Geben Sie unter Linux die folgenden Befehle ein:
/etc/init.d/rmsvc-ma start
/etc/init.d/rmsvc-ma stop
v Starten Sie unter Windows das Programm IBM Remote Management Master
Agent über die Anzeige Dienste erneut.
WebSphere Remote Server Data Provider aktivieren
IBM WebSphere Remote Server Data Provider wird bei der Installation der WebSphere Remote Server-Lösung auf die Maschine kopiert, jedoch nicht aktiviert.
Wenn Sie den Masteragenten von IBM Remote Management Agent installieren,
müssen Sie den Standardsicherheitsmodus auswählen. WebSphere Remote Server
V7.1.1 unterstützt den erweiterten Sicherheitsmodus von Remote Management
Agent nicht. Für die Konfiguration der Berechtigungsnachweise für den Standardsicherheitsmodus wird zurzeit nur die IPV4-Adresse unterstützt.
Anmerkung: Remote Management Agent V2.2 wird nicht mehr unterstützt, sodass
APAR IO08293 nicht heruntergeladen und installiert werden muss.
Gehen Sie vor dem Aktivieren von WebSphere Remote Server Data Provider wie
folgt vor:
v Installieren Sie IBM Tivoli Monitoring Universal Agent auf derselben Maschine.
v Konfigurieren Sie die Datei wrsdp-config.xml.
Nachdem Sie diese erforderlichen Schritte ausgeführt haben, aktivieren Sie WebSphere Remote Server Data Provider mit den folgenden Befehlen:
Windows
"%SIF_HOME%\WRSDP\bin\WRSDPService.exe" -add -wrsdpHome "%SIF_HOME%\WRSDP"
Linux
cd $SIF_HOME/bin
./SifInstall.sh WRSDP
74
WebSphere Remote Server Data Provider wird nun bei jedem Starten der Maschine
automatisch als Service gestartet. Nach der ersten Aktivierung müssen Sie den Service manuell starten:
Windows
net start WRSDPWinService
Linux
/opt/IBM/SIF/WRSDP/bin/startWRSDP.sh
Anmerkung: WebSphere Remote Server Data Provider muss nach jeder überwachten Anwendung gestartet werden.
Führen Sie folgende Schritte aus, um WebSphere Remote Server Data Provider zu
inaktivieren:
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
WebSphere Remote Server Data Provider für die Ereignisüberwachung konfigurieren
IBM WebSphere Remote Server Data Provider wird mit einer XML-Datei im Ordner 'etc' konfiguriert. Die Musterdatei 'wrsdp-config.xml' steht zur Verfügung. In
dieser Datei wird angegeben, welche MBeans mit den entsprechenden Attributen
von WebSphere Remote Server Data Provider überwacht werden sollen. Darüber
hinaus wird diese Datei auch zum Generieren der Metadatei verwendet, die Universal Agent für die Erkennung von Nachrichten von WebSphere Remote Server
Data Provider benötigt. Diese Datei muss auf dem Unternehmensserver vor der
Softwareverteilung geändert werden. Sie können diese Datei ändern, wenn Sie Ihre
angepassten MBeans unter Verwendung von WebSphere Remote Server Data Provider überwachen möchten. Zur Überwachung der einzelnen Gruppen von MBeans muss ein Abschnitt attribute-group (Attributgruppe) hinzugefügt werden. Eine
Attributgruppe ist eine Sammlung von Attributen, die Sie für eine Auswahl von
MBeans überwachen wollen.
Anmerkung: Wenn Sie WRSDP verwenden, um IBM Remote Management Agent
zu überwachen, müssen Sie die Remote Management Agent-Konfiguration aktualisieren. Für WebSphere Remote Server Data Provider ist
es erforderlich, dass Remote Management Agent keine Verbindungen
zur Verwendung von SSL zwingt. Aktualisieren Sie die Datei
SI_HOME/user/rma/classes/ssl.properties mit den folgenden Änderungen, um Remote Management Agent entsprechend zu konfigurieren:
v RMA.alias=NOSSL
v RMAMA.alias=NOSSL
Musterkonfigurationsdatei:
<WRSDataProvider>
<application name="JVM" description="RMA MBeans" JMXServerURL="service:jmx:rmi://localhost:10150/jndi/ma"
collectionInterval="120000">
75
<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>
Anmerkung: Für diese Musterkonfigurationsdatei ist Remote Management Agent
erforderlich. Damit wird die Java Virtual Machine (JVM) von Remote
Management Agent überwacht.
Beschreibung der XML-Schemaentitäten:
v WRSDataProvider: Haupttag für die Konfigurationsdatei.
v application: Entspricht einer größeren Gruppe überwachter Attribute ähnlich einer einzelnen Anwendung. Entspricht //APPL in der UA-Metadateiterminologie.
– name: Entspricht dem internen UA-Namen dieser Anwendung und muss mit
den UA-Namenskonventionen übereinstimmen (die ersten drei Buchstaben
müssen eindeutig sein).
– description: QuickInfo-Text, der in TEP angezeigt wird, wenn der Mauszeiger
auf dieser Anwendung positioniert wird.
– JMXServerUrl: URL für die Herstellung einer Verbindung zum JMX-Server
der Anwendung über JSR-160. Wird diese nicht angegeben, wird versucht,
eine JSR-77-Verbindung zur lokalen JVM (Java Virtual Machine) herzustellen.
– collectionInterval: (Optional) Definiert für diese Anwendung die Häufigkeit,
mit der Daten erfasst werden; der Standardwert ist 300 Sekunden.
v events: Wird verwendet, wenn Ereignisse von diesem JMX-Server erfasst werden
sollen.
– objectNameQuery: (Optional) JMX ObjectNameQuery gibt an, welche MBeans
nach Ereignissen abgefragt werden sollen.
v allow: (Optional) Positiver Filter für Ereignisklassentypen.
v deny: (Optional) Negativer Filter für Ereignisklassentypen.
v env: Entspricht einer Umgebungsvariablen. Umgebungsvariablen sind in einigen
Fällen erforderlich, um JSR-160-Verbindungen herzustellen.
– key: Variablenname.
– value: Variablenwert.
v attribute-group: Gruppe von Attributen, die für jede MBean/MBean-Gruppe erfasst werden sollen. Jedes angegebene Attribut muss für alle MBeans in der
Gruppe definiert sein. Entspricht //ATTRIBUTES in der UA-Metadateiterminologie.
– name: Der in TEP für diese Attributgruppe angezeigte Name.
– description: Der in TEP für diese Attributgruppe angezeigte QuickInfo-Text.
– objectNameQuery: JMX ObjectNameQuery gibt an, für welche MBeans eine
Abfrage ausgeführt werden soll, um die angegebenen Attribute zu erfassen.
76
– delimiter: (Optional) Zeichen, mit dem Felddaten beim Senden von Nachrichten an UA begrenzt werden. Hierbei muss es sich um ein Zeichen handeln,
das in den Felddaten nicht verwendet wird. Der Standardwert ist das Semikolon (;).
v objectNameComponents: Komponenten des Objektnamens der MBean. Diese
Komponenten werden dazu verwendet, Daten der Quelle zuzuordnen.
– objectNameComponent: Komponente des Objektnamens der MBean. Diese
Komponente wird dazu verwendet, Daten der Quelle zuzuordnen.
– name: Schlüssel in der Schlüssel-Wert-Objektnamenkomponente.
– displayname: In TEP angezeigter QuickInfo-Text und Spaltenname.
– type: Einer der Typen 'String', 'Numeric' oder 'Boolean'.
– length: (Für den Typ 'String' erforderlich). Länge der Zeichenfolge.
v attributes: Durch die MBeans in dieser Attributgruppe zugänglich gemachte Attribute.
– attribute: Durch die MBeans in dieser Attributgruppe zugänglich gemachtes
Attribut.
– name: Name des MBean-Attributs. Wenn MBean getMyAttr() zugänglich
macht, ist dies MyAttr.
– displayname: In TEP angezeigter QuickInfo-Text und Spaltenname.
– type: Einer der Typen 'String', 'Numeric' oder 'Boolean'.
– length: (Für den Typ 'String' erforderlich). Länge der Zeichenfolge.
Anmerkung: Bei Übersetzungen darf von den oben beschriebenen Feldern nur das
Feld 'description' andere als in der englischen Sprache verwendete
Zeichen enthalten.
Anmerkung: Wenn Sie WebSphere Remote Server Data Provider für die Überwachung von Remote Management Agent v2r2 konfigurieren, müssen
Sie den APAR IO08293 für Remote Management Agent herunterladen. Wenden Sie sich an die WebSphere Remote Server-Unterstützung, um diese Programmkorrektur zu erhalten.
Metadateien konfigurieren
Die Konfigurationsdateien (in der Universal Agent-Terminologie auch als Metadateien bezeichnet) werden für Universal Agent bereitgestellt, damit dieser die Nachrichten versteht, die von WebSphere Remote Server Data Provider übergeben werden, und damit strukturierte Daten an Tivoli Enterprise Portal gesendet werden
können. In der Datei 'jmx.mdl' wird das Format von JMX-Ereignisnachrichten angegeben. Diese Datei ist im Lieferumfang von Accelerators enthalten und darf
nicht geändert werden.
Anmerkung: Zu Übersetzungszwecken: Der Text nach dem kommerziellen A (@)
kann übersetzt werden. Bei der Verwendung von übersetztem Text
muss das Attribut 'D' in 'U' geändert werden. Beispiel:
UserData U 500 @Von Benachrichtigung angegebene Daten
Musterdatei (jmx.mdl):
//APPL JMX
//NAME JmxEvents E @JMX Events from the Remote Management Agent
//SOURCE SOCK localhost
//ATTRIBUTES ’;’
userData D 500 @Data specified by notification
timeStamp N 13 @Milliseconds since Jan 1 1970
type D 200 @Where the event came from
77
message D 500 @Message from the MBean
source D 400 @Objectname of the MBean
seqNum C 5 @Sequence number as supplied by MBean
Die Scriptdateien 'import_metafiles.bat' und 'import_metafiles.sh' führen eine Syntaxanalyse für die Datei 'wrsdp-config.xml' durch, generieren neue Metadateien
und importieren diese in Universal Agent. Vor der Ausführung des Importscripts
müssen an der Datei 'wrsdp-config.xml' unbedingt alle erforderlichen Anpassungen
vorgenommen werden.
Agentenstart konfigurieren
Die Konfigurationsdateien für den Agentenstart von IBM Remote Management
Agent können dazu verwendet werden, beim Start von Remote Management
Agent bestimmte MBeans zu starten. Die Syntax für die Datei ist in der Veröffentlichung 'IBM Remote Management Agent User's Guide' beschrieben. Für die angegebenen MBeans ist jedoch eine zusätzliche Konfiguration möglich. WebSphere Remote Server Data Provider ist eine Erweiterung (JMXEventMapperImplementierungen) eines JMX-Ereignislisteners. Wenn ein JMX-Ereignislistener gestartet wird, können dafür zwei Zeichenfolgeargumente angegeben werden:
v Der zu verwendende Klassenname von JMXEventMapper. Der nachfolgend angegebene Klassenname (com.ibm.sif.event.mapper.snmp.TrapGenerator) dient lediglich als Beispiel und steht nicht zur Verfügung. Das Klassennamenargument
ist erforderlich.
v Eine durch Kommata getrennte Liste mit Namen von Benachrichtigungsklassen,
die vom JMX-Ereignislistener nicht weitergeleitet werden sollen. Die durch Kommata getrennten Komponenten können auch als reguläre Ausdrücke angegeben
werden. Dabei handelt es sich um ein optionales Argument.
Diese Dateien müssen an der folgenden Position gespeichert werden: 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>
Ereignismapper erstellen
JMX-Ereignisse können durch die Erstellung eines angepassten Ereignismappers
verarbeitet werden. Dazu müssen Sie die Schnittstelle "com.ibm.sif.event.JMXEventMapper" implementieren.
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);
}
78
Der neue Code muss in eine JAR-Datei integriert und im Verzeichnis
"RMA_HOME\ext" installiert werden. Darüber hinaus muss eine neue MBeanStartdatei (wie beispielsweise "RMASDPStartup.xml") erstellt und im Verzeichnis
"RMA_HOME\config\startup" installiert werden. RMA muss erneut gestartet werden, damit diese Änderung wirksam wird.
MBeans auf der Basis von ITM-Situationen bearbeiten
Attribute für MBeans werden durch Erstellen einer Situation in ITM bearbeitet.
Eine Situation ist nichts anderes als eine Bedingung. Beispielsweise können Sie eine
Situation für die MBean "JVMEnvironment" erstellen, indem Sie die Bedingung als
FreeMemory > 0 angeben und je nach Wert eine Aktion zuordnen. Das Erstellen der
Situation ist dabei eine Voraussetzung.
Führen Sie zum Bearbeiten von Attributen für MBeans die folgenden Schritte aus:
v Klicken Sie mit der rechten Maustaste auf ein Navigatorelement und wählen Sie
Situations aus.
v Klicken Sie auf das Symbol, mit dem Sie neue Situationen erstellen können. Das
Dialogfenster Create Situation wird geöffnet.
v Geben Sie die Werte für die Felder Name und Description an. Klicken Sie auf
OK.
v Das Dialogfenster Select Condition wird geöffnet. Wählen Sie die Werte für
Condition Type, Attribute Group und Attribute Item aus und klicken Sie dann
auf OK.
v Wählen Sie auf der Registerkarte Formula des Dialogfensters Situations for die
Bedingung aus.
v Wählen Sie auf der Registerkarte Distribution des Dialogfensters Situations for
alle Agenten aus, die Sie aufnehmen wollen.
v Wählen Sie auf der Registerkarte Action des Dialogfensters Situations for die
folgenden Werte aus bzw. geben Sie sie an:
– Action Selection: System Command (Systembefehl).
– System Command: /opt/IBM/SIF/WRSDP/bin/invoke_attribute_script.sh (der
vollständig qualifizierter Pfad des auszuführenden Scripts). Die folgenden Parameter müssen angegeben werden: JMXServiceURL für MBeanServer, MBean-Objektname, Attributname und neuer Attributwert.
Hinweise:
- Durch diesen Befehl wird ein MBean-Attribut auf einen neuen
Wert gesetzt.
- Sie können auch den Befehl '/opt/IBM/SIF/WRSDP/bin/
invoke_method_script.sh' verwenden, bei dem die folgenden Parameter angegeben werden: JMXServiceURL für MBeanServer,
MBean-Objektname, Name der Methode und Parameter (falls
vorhanden).
- Wenn für den MBeanServer, zu dem Sie eine Verbindung herstellen, weitere Umgebungsvariablen erforderlich sind, müssen
Sie diese Scripts bearbeiten und die Variable JAVA_ARGS für jeden neuen Parameter erweitern. Die Scripts enthalten Beispiele
für die Variable JAVA_ARGS, die für die Herstellung einer Verbindung zu IBM Remote Management Agent und IBM WebSphere Application Server erforderlich ist.
- Wenn Sie zu mehreren verschiedenen MBeanServern eine Verbindung herstellen, müssen Sie Kopien der Scripts invoke_attribute_script.sh und invoke_method_script.sh erstellen, wobei
79
jede Kopie Umgebungsvariablen für einen bestimmten Server
angibt. Sie können beispielsweise invoke_attribute_script.sh
nach rma_attribute_script.sh kopieren und rma_attribute_script.sh für die Verwendung von RMA-spezifischen Umgebungsvariablen modifizieren.
– If the condition is true for more than one monitored item (Wenn die Bedingung für mehr als ein überwachtes Element zutrifft): Aktion für jedes Element
ausführen.
– Where should the action be executed (performed) (Wo soll die Aktion ausgeführt werden): Aktion auf dem verwalteten System (Agenten) ausführen.
– If the condition stays true over multiple intervals (Wenn die Bedingung
über mehrere Intervalle hinweg zutrifft): In jedem Intervall eine Aktion ausführen.
Klicken Sie auf OK.
Wenn die Bedingung erfüllt wird, wird das Ereignis in der Situationsereigniskonsole (Situation Event Console) angezeigt.
Anmerkung: Weitere Einzelheiten zur Erstellung von Situationen finden Sie im
IBM Tivoli Monitoring Information Center.
WebSphere MQ-Nachrichtencontroller
Der IBM WebSphere MQ-Nachrichtencontroller steuert den Nachrichtenfluss vom
Absender zum Empfänger und stellt sicher, dass WebSphere MQ die Netzbandbreite nicht beeinträchtigt.
Verwenden Sie den WebSphere MQ-Nachrichtencontroller zum Steuern der Nachrichtenanzahl oder der Nachrichtendatenmenge, die über den WebSphere MQ-Kanal gesendet wird, wenn die folgenden Situationen auftreten:
v Der WebSphere MQ-Kanal wird nach einem längeren Netzausfall erneut aktiviert.
v Die Netzbandbreite ist knapp und die WebSphere MQ-Nachrichten beanspruchen einen beträchtlichen Anteil der Bandbreite, der für wichtigeren Datenverkehr, wie zum Beispiel Transaktionsprotokolle, benötigt wird.
WebSphere MQ-Nachrichtencontroller installieren
Der Nachrichtencontroller gehört zum Lieferumfang von IBM WebSphere Remote
Server und muss an der richtigen Position installiert werden, wenn WebSphere Remote Server installiert wird.
Um sicherzustellen, dass der Nachrichtencontroller ordnungsgemäß installiert wurde, stellen Sie fest, ob sich die Dateien LinSenderChannelController/
WinSenderChannelController.dll und mqexitprog.properties nach der Installation
von WebSphere Remote Server an den folgenden Positionen befinden:
MQ_HOME\exits
SIF_HOME/mqexits
(64-Bit) SIF_HOME/mqexits/exits64
Beachten Sie, dass das Vorhandensein dieser Dateien auf dem System nicht bedeutet, dass der Nachrichtencontroller bereits auf dem System installiert ist. Diese Dateien werden standardmäßig für die Verwendung zur Verfügung gestellt. Ist eine
80
Geschäftsanforderung für die Verwendung des Controllers vorhanden, müssen Sie
die im Abschnitt „WebSphere MQ Message Controller konfigurieren” beschriebenen Schritte befolgen.
WebSphere MQ Message Controller konfigurieren
Gehen Sie wie in diesem Abschnitt beschrieben vor, um den Message Controller zu
konfigurieren.
Sie müssen folgende Schritte ausführen, um die zu steuernde WebSphere MQ-Umgebung zu aktivieren:
v Konfigurieren Sie die Nachrichtenexits für die Zielkanäle.
v Ändern Sie die Datei mqexitprog.properties.
Vorgehensweise
1. Konfigurieren Sie den WebSphere MQ-Kanal für Nachrichtenexits mithilfe von
WebSphere MQ Explorer.
a. Navigieren Sie zum richtigen Warteschlangenmanager.
b. Blenden Sie die Registerkarte Advanced → Channels ein.
c. Klicken Sie mit der rechten Maustaste auf den Senderkanal, den Sie konfigurieren wollen.
d. Wechseln Sie zur Registerkarte Exits und blättern Sie abwärts zum Abschnitt Message Exits Name.
e. Suchen Sie die Datei WinSenderChannelController.dll oder
LinSenderChannelController in Ihrem Dateisystem.
f. Geben Sie Folgendes ein: pfad\dateiname(ChannelExit). Unter Windows wird
WebSphere MQ beispielsweise im Pfad C:\Program Files\IBM\MQ installiert.
Beispiel: C:\Program Files\IBM\MQ\exits\
WinSenderChannelController(ChannelExit).
g. Klicken Sie auf OK und starten Sie den Kanal erneut.
Anmerkung: Alternativ dazu können Sie den Befehl 'Alter Channel' in der
MQSC-Shell (zum Benutzer 'mqm' wechseln und den Befehl
'runmqsc' ausführen) verwenden, um den Kanal für WebSphere MQ-Exits zu modifizieren. Diese Änderung muss auf
dem System erfolgen, auf dem der Senderkanal konfiguriert
wurde.
Nachfolgend sind Beispiele für den Befehl 'Alter Channel' aufgeführt:
alter channel (’channel_name’) chltype (SDR)
msgexit (’$SIF_HOME/mqexits/
LinSenderChannelController(ChannelExit)’)
alter channel (’channel_name’) chltype (SDR)
msgexit (’%MQ_HOME%\exits\
WinSenderChannelController(ChannelExit)’)
2. Ändern Sie die Datei mqexitprog.properties. Diese Datei enthält die Variablen,
die die Funktionsweise des Nachrichtencontrollers steuern. Die folgenden Variablen sind in dieser Datei definiert:
81
v SLEEP_INTERVAL: Standardwert 0. Bereich: 0 bis 9999. Diese Variable legt
die Dauer in Sekunden fest, die der WebSphere MQ-Kanal vor dem Senden
des nächsten Nachrichtenstapels wartet. Ein Wert 0 bedeutet, dass der Kanalexit inaktiviert ist.
Anmerkung: Wenn Sie den Nachrichtencontroller nicht verwenden wollen
und SLEEP_INTERVAL auf 0 setzen, wird der Controller erwartungsgemäß ausgeführt, allerdings erhöht sich dadurch
Prozessorauslastung. Anstatt den Wert auf 0 zu setzen, wird
empfohlen, die Nachrichtenexits zu entfernen, falls der Nachrichtencontroller nicht verwendet werden soll.
v MESSAGE_COUNTER: Standardwert 0. Bereich: 0 bis 9999. Diese Variable
legt die Anzahl der Nachrichten fest, die gesendet werden, bevor der Ruhemodus für die Dauer der mit SLEEP_INTERVAL angegebenen Sekunden eintritt. Der Wert 0 bedeutet, dass diese Variable nicht beim Steuern des Nachrichtenflusses berücksichtigt wird.
Anmerkung: Bei jeder Änderung von MESSAGE_COUNTER oder MESSAGE_SIZE_COUNTER in der Eigenschaftendatei muss die Datei
'mqexitprog.log' gelöscht werden. Diese Protokolldatei befindet
sich in den folgenden Ordnern:
/var/mqm
MQ_HOME\exits
v MESSAGE_SIZE_COUNTER: Standardwert 0. Bereich: 0 bis 65000 Byte. Diese
Variable gibt das Datenvolumen an, das gesendet wird, bevor die Ruhemodusfunktion aktiviert wird. Der Wert 0 bedeutet, dass diese Variable nicht
beim Steuern des Nachrichtenflusses berücksichtigt wird.
v EFFECTIVE_BETWEEN: Standardwert 0000:0000. Bereich: 0000:0001 bis
0000:2359. Diese Variable legt die Systemzeit in hhmm bis hhmm fest, in der
der Controller für den Ruhemodus ausgeführt wird. Der Controller steuert
den Nachrichtenfluss nicht außerhalb der angegebenen Zeit. Der Wert
0000:0000 bedeutet, dass der Controller die ganze Zeit über aktiv ist. Geben
Sie die Zeit im 24-Stunden-Format an.
Der Nachrichtencontroller führt die nachfolgend beschriebenen Berechnungen
durch, um festzustellen, ob er in den Ruhemodus versetzt werden muss.
Wenn Current_Msg_Count (Anzahl aktueller Nachrichten) kleiner als MESSAGE_COUNTER, Effective_Msg_Size (Größe aktiver Nachrichten) kleiner als
MESSAGE_SIZE_COUNTER und EFFECTIVE_BETWEEN gültig ist, dann wird
die Nachricht ohne Verzögerung gesendet. Andernfalls wird für die Dauer der
in SLEEP_INTERVAL angegebenen Sekunden gewartet, bevor die Nachricht gesendet wird.
Um dies weiter auszuführen: SLEEP_INTERVAL 20 (wartet 20 Sekunden vor
dem Senden des nächsten Nachrichtenstapels) MESSAGE_COUNTER 10 (wird
nach jeder 10. Nachricht in den Ruhemodus versetzt) MESSAGE_SIZE_COUNTER 20000 (oder bis die Größe der gesendeten Daten diesen Grenzwert erreicht
hat) EFFECTIVE_BETWEEN 0800:2100 (vorausgesetzt, es ist zwischen 8:00 und
21:00 Uhr).
Anmerkung: Es wird empfohlen, das WebSphere MQ-Nachrichtenaufkommen
genau zu überwachen, nachdem Sie den WebSphere MQ-Nachrichtencontroller konfiguriert haben. Wenn Sie für die oben beschriebenen Variablen extreme Werte konfiguriert haben, kann die
82
Rate für das Generieren von Nachrichten die Rate für das Senden
von Nachrichten überschreiten. Zum Vermeiden solcher Situationen wird empfohlen, dass der Nachrichtencontroller nur während
der täglichen Hauptarbeitszeiten aktiviert wird.
Alternativen zum Nachrichtencontroller
Es gibt verschiedene Ansätze für die Simulation der Nachrichtencontrollerfunktion.
Jeder dieser Ansätze hat jeweils Vorteile und Nachteile. Sie müssen diese Ansätze
verstehen, um zu bestimmen, welcher für Ihre Anforderungen und die jeweilige
Unternehmenskonfiguration am besten geeignet ist.
Niedrige Tiefe und häufige Wiederholung einer Kanaloperation
Bei diesem Ansatz kann der WebSphere MQ-Administrator die Warteschlangenlänge der Empfangswarteschlange auf einen sehr niedrigen Wert, zum Beispiel 2, und
das Wiederholungsintervall einer Kanaloperation auf einen Wert wie z. B. 60 Sekunden setzen. Wenn nun die Empfangswarteschlange den Überlaufgrenzwert erreicht, wechselt der Verbindungskanal in den Wiederholungsmodus, wenn er versucht, die nächste Nachricht zu senden. Dadurch wird mit dieser Methode indirekt
die Rate des Nachrichtenflusses durch den WebSphere MQ-Kanal gesteuert.
Der Vorteil einer solchen Einstellung ist, dass keine weitere Anwendung für die
Steuerung des Nachrichtenflusses benötigt wird. Dieser Ansatz weist darüber hinaus günstigere Werte im Hinblick auf die CPU-Belegung und die Speicherauslastung auf.
Der Nachteil einer solchen Einstellung ist, dass bei diesem Ansatz nicht garantiert
werden kann, dass der Nachrichtenfluss auf eine festgelegte Anzahl von Nachrichten pro Minute beschränkt wird. Wenn die Anwendung, die die Nachrichten auf
der Empfangsseite verarbeitet, die Nachrichten schnell genug aufnimmt, bevor die
Warteschlange den Überlaufgrenzwert erreicht, ist diese Einstellung unwirksam.
Nachrichtenkomprimierung
Bei diesem Ansatz aktiviert der WebSphere MQ-Administrator die
Komprimierung/Dekomprimierung von WebSphere MQ. Die WebSphere MQ-Steuerkomponente komprimiert den Datenteil der Nachricht, bevor sie sie durch den
Kanal sendet. Auf der Empfangsseite dekomprimiert die WebSphere MQ-Steuerkomponente die Nachricht, bevor sie in die Empfangswarteschlange gestellt wird.
Die Vorteile dieses Ansatzes:
v Vollständige Transparenz gegenüber den sendenden/empfangenden Benutzeranwendungen.
v CPU-Belegung/Speicherauslastung sind gering.
v Erhebliche Reduzierung der Nachrichtengröße (bis zu 90 % bei ASCII-Textdaten).
v Erhebliche Reduzierung der Netzauslastung für jede gesendete Nachricht.
v Die Funktionalität ist durchweg gewährleistet.
Der Nachteil dieses Ansatzes besteht darin, dass er stark vom Typ der Nachrichtendaten abhängt. Die Komprimierung liefert gute Ergebnisse für textbasierte
Nachrichten, für binäre Nachrichtendaten ist jedoch praktisch keine Komprimierung erkennbar.
83
Kennwortmanagement mit Tivoli Provisioning Manager-Workflows
In diesem Abschnitt wird die Kennwortmanagementfunktion mit IBM Tivoli Provisioning Manager-Workflows beschrieben. Die Kennwortmanagementkomponente
wird zum Verwalten der Kennwörter für die Middlewarekomponenten verwendet,
die in der IBM WebSphere Remote Server-Metadatendatei konfiguriert sind. Standardmäßig werden nur die während der Installation der WebSphere Remote Server-Middleware erstellten Benutzeraccounts für die Verwaltung durch die Kennwortmanagementkomponente konfiguriert. Die Interaktion mit der
Kennwortmanagementkomponente ist zum gegenwärtigen Zeitpunkt ausschließlich
über Tivoli Provisioning Manager-Workflows möglich.
Kennwortmanagementkomponente verwenden
Mithilfe der Kennwortmanagementkomponente können Sie das Ablaufdatum der
Benutzeraccounts für die WebSphere Remote Server-Middlewarekomponenten abfragen und die entsprechenden Kennwörter dann über Remotezugriff ändern. Die
Anwendung ermöglicht es Ihnen, die Kennwörter vom Tivoli Provisioning Manager-Server aus über Remotezugriff für mehrere Endpunkte gleichzeitig abzufragen.
Sie können dann anhand der Ausgabedatei feststellen, für welche Benutzeraccounts
auf welchen fernen Endpunkten aktualisierte Kennwörter erforderlich sind. Sie
können eine CSV-Datei (Datei mit Werten, die durch Komma voneinander getrennt
sind) erstellen, die die relevanten Informationen zu den Benutzeraccounts der fernen Endpunkte enthält, und die Kennwortänderungsfunktion aufrufen, um die
Kennwörter für mehrere Benutzeraccounts an mehreren Endpunkten über Remotezugriff zu ändern.
Als Eingabe zum Starten des Scan-Workflows müssen Sie eine CSV-Datei erstellen,
die die Endpunkt-ID und den Endpunkthostnamen enthält. Zur vereinfachten Erstellung der CSV-Datei können Sie das Berichterstellungsdienstprogramm von Tivoli Provisioning Manager verwenden, um eine Liste der zu verwaltenden Systeme
zu erstellen.
Die Scananwendung führt eine Syntaxanalyse der Metadatendatei an den Endpunkten durch, an denen WebSphere Remote Server-Middleware installiert ist. Die
Kennwortmanagementanwendung ist auf die Verwaltung der Benutzeraccounts begrenzt, die über einen relevanten Eintrag in der Metadatendatei verfügen und bei
denen es sich um Accounts auf Betriebssystemebene handelt.
Als Eingabe zum Starten des Änderungsworkflows müssen Sie eine CSV-Datei erstellen, die eine Liste der Benutzeraccounts auf verschiedenen Hosts enthält, für
die die Anwendung das Kennwort ändern soll. Es wird empfohlen, die im Paket
enthaltene CSV-Musterdatei als Referenz zu verwenden (workflows/samples/
samplehostpasswordfile.csv). Die Änderungsanwendung führt eine Syntaxanalyse
der CSV-Datei durch, erstellt mehrere temporäre Arbeitsdateien - eine für jeden
Endpunkt - und ruft anschließend den Kennwortänderungsprozess für die einzelnen Endpunkte auf. Der Kennwortänderungsstatus für die einzelnen Benutzer der
einzelnen Endpunkte wird dann in einer weiteren CSV-Datei kompiliert. Der Name
und die Position der daraus resultierenden CSV-Datei werden am Ende der Ausführung des invokeChangePassword-Workflows angezeigt.
Bevor Sie mit der Verwendung der Kennwortmanagementkomponente beginnen,
müssen Sie die Workflows in Tivoli Provisioning Manager importieren. Die Installation der Kennwortmanagementkomponente wird auf der ISP-Seite während der
Installation der WebSphere Remote Server-Middleware durchgeführt. Die Komponenten, die auf dem Tivoli Provisioning Manager-Unternehmensserver installiert
84
werden müssen, stehen im Ordner SIF_HOME/PasswordMgmt/workflows zur Verfügung. Dieser Ordner befindet sich bereits auf jedem System, auf dem WebSphere
Remote Server installiert ist.
Anmerkung: Wenn Sie die Kennwortmanagementkomponente auf einer SUSE Linux Enterprise Server-Plattform in einer anderen Sprache als Englisch verwenden, müssen Sie zuerst die Umgebungsvariable LANG in
der Datei /etc/profile exportieren. Der Wert von LANG ist die Ländereinstellung der SUSE Linux Enterprise Server-Workstation, die die
zu verwaltenden Kennwörter enthält.
Kennwortmanagementkomponente auf dem Tivoli Provisioning
Manager-Server installieren
Führen Sie zum Installieren der Kennwortmanagementkomponente auf dem Tivoli
Provisioning Manager-Server die folgenden Schritte aus:
1. Kopieren Sie den Inhalt des Ordners SIF_HOME\PasswordMgmt\workflows vom
Endpunkt der WebSphere Remote Server-Installation in ein temporäres Verzeichnis auf dem Server, auf dem sich Tivoli Provisioning Manager befindet.
2. Führen Sie das Script 'installPwdMgmt.bat/sh' mit dem erforderlichen Parameter <install location> aus.
3. Überprüfen Sie die Installation. Prüfen Sie, ob die Verzeichnisse '<install
location>\workfiles' und '<install location>\outputfiles' erstellt wurden. Prüfen
Sie außerdem, ob <install location> die Datei 'cleanup.bat/sh' enthält.
4. Öffnen Sie die Serverbenutzerschnittstelle von Tivoli Provisioning Manager im
Browser und klicken Sie auf Go To → Administration → Provisioning → Provisioning Workflows.
5. Klicken Sie im Erstellungsprogramm für Bereitstellungsworkflows (Provisioning
.
Workflow Composer) auf
6. Klicken Sie auf Select Action > Open Workflow.
7. Suchen Sie die Workflowdatei 'scanPasswordWorkflow.wkf', die sich in dem
Ordner befindet, den Sie in Schritt 1 kopiert haben.
8. Kompilieren Sie den Workflow.
9. Wiederholen Sie die Schritte 6 und 7 für die Workflowdatei 'changePasswordWorkflow.wkf'.
Tivoli Provisioning Manager-Server und Endpunkte für Kennwortmanagement konfigurieren
Führen Sie zum Konfigurieren des Tivoli Provisioning Manager-Servers und der
Endpunkte für das Kennwortmanagement die folgenden Schritte aus:
Anmerkung: Bevor Sie diese Konfiguration starten, stellen Sie sicher, dass Tivoli
Common Agent auf den Endpunkten installiert ist.
1. Der Berechtigungsnachweistyp von Service Access Point (Servicezugangspunkt)
für Tivoli Provisioning Manager-Server (Windows) ist das Kennwort für alle
Service Access Points.
v SSH-Server (für Linux-Endpunkte) und Suchkriterium ist ssh.
v SSH-Client (für Linux-Endpunkte) und Suchkriterium ist ssh.
v RXA-Server (für Windows-Endpunkte) und Suchkriterium ist rxa.
v RXA-Client (für Windows-Endpunkte) und Suchkriterium ist rxa.
2. Service Access Point für Windows-Endpunkt.
85
v RXA-Server und Suchkriterium ist rxa.
v RXA-Client und Suchkriterium ist rxa.
v Agent-Server.
3. Service Access Point für Linux-Endpunkt.
v SSH-Server und Suchkriterium ist ssh.
v SSH-Client und Suchkriterium ist ssh.
v Agent-Server.
Es wird empfohlen, dass Sie die oben genannten Suchkriterien verwenden, da die
Workflows die Werte für den Sicherheitsberechtigungsnachweis, ssh und rxa, fest
codieren. Außerdem wird empfohlen, dass Sie diese auf Verschlüsselung basierenden Protokolle für die Kommunikation zwischen dem Tivoli Provisioning Manager-Server und dem Endpunkt verwenden, da die kennwortbezogenen Informationen über den Kanal übertragen werden.
Bericht zum Abrufen der Systemlisten erstellen
Sie müssen einen Bericht erstellen, der eine Liste mit Systemen bereitstellt, für die
Sie die Kennwortmanagementfunktion benötigen. Führen Sie zum Erstellen einer
CSV-Datei zum Testen des Kennwortmanagements die folgenden Schritte aus:
1. Öffnen Sie die Tivoli Provisioning Manager-Konsole und melden Sie sich mit
dem Benutzernamen maxadmin an.
2. Klicken Sie auf Go To → Administration → Reporting → Report Administration.
3. Geben Sie serverDetails in Report File Name ein und drücken Sie die Eingabetaste.
4. Wählen Sie den Eintrag tp_serverDetails.rptdesign aus, um die Konfiguration
des Berichts auf der Berichtsseite anzuzeigen.
5. Klicken Sie auf New Row, um eine neue Zeile mit den folgenden Parametern
hinzuzufügen:
Parametername
osname
Attributname
softwareresource.softwaremodule.name
Suchname
tpm_osname
Anzeigename
Betriebssystemname
6.
7.
8.
9.
86
Anzeigereihenfolge
4
Klicken Sie auf das Speichersymbol, um die Konfiguration zu speichern.
Klicken Sie auf Generate Request page, um die Anforderungsseite zu generieren, und klicken Sie anschließend auf Preview, um sie zu öffnen.
Geben Sie % in das Feld Computer Name ein, wählen Sie das entsprechende
Betriebssystem im Feld Operating System Name aus und klicken Sie dann
auf Submit.
Klicken Sie auf der Seite Reporting auf das Symbol für den Datenexport, um
die Seite Export Data anzuzeigen.
10. Wählen Sie die Spalten server_id und server_name aus und klicken Sie dann
auf OK, um die CSV-Datei zu speichern.
11. Öffnen Sie den Systemlistenbericht und entfernen Sie alle Endpunkte, für die
Sie die Scananwendung nicht ausführen möchten.
Die Scananwendung ausführen
Gehen Sie wie folgt vor, um die Scananwendung auszuführen:
1. Es wird vorausgesetzt, dass Sie den Workflow 'scanPasswordWorkflow' auf den
Tivoli Provisioning Manager-Server importiert haben. Wählen Sie den Workflow 'scanPasswordWorkflow' aus und führen Sie ihn aus.
2. Sie werden zur Eingabe der folgenden Werte aufgefordert:
v serverIdFileName: Der absolute Pfad zusammen mit dem Dateinamen der
CSV-Datei, die die Liste mit den Endpunkten enthält, auf denen Sie die Scananwendung ausführen wollen.
v TPM_PASSWORDMGMT_HOME: Die Position auf dem Tivoli Provisioning
Manager-Server, an der die Kennwortmanagementkomponente installiert ist.
v TPM_Server_Hostname: Der Name des Tivoli Provisioning Manager-Servers.
Dieser Name muss mit dem Eintrag im Inventarisierungsdatensatz in Tivoli
Provisioning Manager übereinstimmen.
Anmerkung: Die CSV-Eingabedatei für den Workflow 'scanPasswordWorkflow'
kann Informationen zu Windows- und Linux-Endpunkten enthalten.
3. Sobald Sie 'scanPasswordWorkflow' ausführen, wird eine neue CSV-Datei mit
den relevanten Informationen, z. B. Hostname, Benutzername und Ablaufdatum
für das Kennwort, auf dem Tivoli Provisioning Manager-Server erstellt. Die Position und der Name der Datei kann als Wert des Parameters 'OutputFile' eingesehen werden. Dieser wird festgelegt, wenn der Workflow erfolgreich ausgeführt wurde. Zum Überprüfen dieses Werts klicken Sie auf die AnforderungsID des Workflows und zeigen das Ergebnis an.
Die Änderungsanwendung ausführen
Gehen Sie wie folgt vor, um die Änderungsanwendung auszuführen:
1. Es wird vorausgesetzt, dass Sie den Workflow 'changePasswordWorkflow' auf
den Tivoli Provisioning Manager-Server importiert haben. Wählen Sie den
Workflow 'changePasswordWorkflow' aus und führen Sie ihn aus.
2. Sie werden zur Eingabe der folgenden Werte aufgefordert:
v hostPasswordFileName: Der absolute Pfad zusammen mit dem Dateinamen
der CSV-Datei, die die Liste mit den Endpunkten sowie das neue Kennwort
und das alte Kennwort enthält. Sie können sich die Datei 'samplehostpasswordfile.csv' als Muster dieser Datei ansehen.
v TPM_PASSWORDMGMT_HOME: Die Position auf dem Tivoli Provisioning
Manager-Server, an der die Kennwortmanagementkomponente installiert
wurde.
v TPM_Server_Hostname: Der Name des Tivoli Provisioning Manager-Servers.
Dieser Name muss mit dem Eintrag im Inventarisierungsdatensatz in Tivoli
Provisioning Manager übereinstimmen.
3. Sobald die Workflow-Ausführung beendet ist, fasst die Workflow-Variable PasswordChangeStatus den Ausführungsstatus des Workflows zusammen. Falls während der Ausführung Fehler aufgetreten sind, überprüfen Sie die mit dem Wert
der Variable OutputFile angegebene Datei auf Fehlerinformationen.
87
Anmerkung: Immer wenn Sie vom Tivoli Provisioning Manager-Server zur
Eingabe eines Dateinamens und Dateipfads (dateiname/dateipfad)
aufgefordert werden, müssen Sie unter Windows als Trennzeichen
\\ angeben und nicht \. Unter Linux verwenden Sie / als Trennzeichen.
IBM Tivoli License Compliance Manager installieren und aktivieren
Tivoli License Compliance Manager überwacht die Lizenzeinhaltung. Im Grunde
erkennt und überwacht es, welche Produktangebote mit den zugehörigen Versionen, Releases und Fixpacks auf dem System installiert sind und verwendet werden.
IBM WebSphere Remote Server unterstützt die Verwendung von Tivoli License
Compliance Manager-Server, um Verwendungsinformationen zu sammeln und zu
überwachen.
Zum Installieren und Aktivieren von Tivoli License Compliance Manager müssen
Sie den Tivoli License Compliance Manager-Agenten herunterladen und ihn auf jedem WebSphere Remote Server installieren. Anweisungen zum Herunterladen von
Tivoli License Compliance Manager finden Sie im Tivoli License Compliance Manager Information Center.
Die erforderliche WebSphere Remote Server-Signaturdatei für den Tivoli License
Compliance Manager-Agenten wird während der WebSphere Remote Server-Installation auf WebSphere Application Server implementiert. Eine Sicherungsversion
der Datei befindet sich nach der Installation im Verzeichnis SIF_HOME\tivoli. Fünf
Dateien stehen zur Verfügung:
v RSSIDSSTR0701.SYS2 (Falls IBM Retail Store Server Starter Edition mit Informix
Database installiert ist)
v RSSDB2STR0701.SYS2 (Falls IBM Retail Store Server Starter Edition installiert ist)
v RSSDB2ADV0701.SYS2 (Falls IBM Retail Store Server Advanced Edition installiert
ist)
v RSSIDSADV0701.SYS2 (Falls IBM Retail Store Server Advanced Edition mit Informix Database installiert ist)
v RSSDB2CSS0701.SYS2 (Falls IBM WebSphere Central Site Server installiert ist)
Sicherheitsaspekte
Die Verbesserung der Sicherheit für einzelhandelsorientierte Informationssysteme
sowie für die von diesen Systemen übertragenen und gespeicherten Daten ist zu
einer der zentralen Aufgaben geworden, mit denen sich Einzelhändler auseinandersetzen müssen. Bei vielen großen Unternehmen sind Sicherheitsverstöße aufgetreten, die sie hohe Beträge aufgrund von Rechtsstreitigkeiten, der erforderlichen
Behebung von Sicherheitslücken in ihrer IT-Infrastruktur, des schwindenden Kundenvertrauens und der Sanktionen durch einflussreiche Kreditkartenunternehmen
kosteten.
Um Sicherheitsverstöße zukünftig zu verhindern, wurden Sicherheitsstandards entwickelt, wie beispielsweise PCI DSS (Payment Card Industry Data Security Standard). Sie sollen die für die System- und Datensicherheit eines Unternehmens verantwortlichen IT-Mitarbeiter unterstützen. Die Einhaltung des Standards PCI DSS
ist für alle Unternehmen erforderlich, die die beim Kartenzahlungsverkehr verwendete PAN (Primary Account Number) verarbeiten und/oder speichern. Selbst für
88
Unternehmen, die nicht mit PANs arbeiten, dient PCI DSS als gutes Modell für die
IT-Infrastruktursicherheit in einem einzelhandelsorientierten Unternehmen.
Die Informationen im vorliegenden Thema sollen Ihnen als Richtlinie dienen, wenn
Sie sich mit wichtigen Sicherheitsaspekten befassen, die bei der Installation und
Konfiguration einer IBM WebSphere Remote Server-Lösung möglicherweise eine
Rolle spielen. In Anlehnung an die Vorgaben von PCI DSS können die in diesem
Abschnitt aufgeführten Punkte als Basis für die Identifizierung von Problembereichen dienen, die im Rahmen der Verbesserung Ihrer Systemsicherheit besondere
Aufmerksamkeit erfordern. Zu jeder der zwölf Hauptanforderungen des PCI-Standards sind vorgeschlagene Aktionen für die einzelnen Komponenten der WebSphere Remote Server-Installation aufgeführt.
Weitere Informationen zum Inhalt des vorliegenden Abschnitts erhalten Sie über
die folgenden Links:
v PCI Security Standards Council – PCI DSS: https://
www.pcisecuritystandards.org
v WebSphere Application Server V7.0.0.9, Abschotten der Sicherheitskonfigurationen
des Systems: http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/
com.ibm.websphere.nd.doc/info/ae/ae/tsec_hardsecconfig.html
v WebSphere Application Server V7.0.0.9, Optimierung, Abschottung und Verwaltung
von Sicherheitskonfigurationen: 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 V7.0.0.9, Kennwörter in Dateien sichern: 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, and security standards von T. Rob
Wyatt: http://www.ibm.com/developerworks/websphere/techjournal/
0806_mismes/0806_mismes.html
v WebSphere MQ-Sicherheit: http://publib.boulder.ibm.com/infocenter/wmqv7/
v7r0/index.jsp?topic=/com.ibm.mq.amqzag.doc/fa12730_.htm
v DB2 V9.7 Fixpack 2 für Linux, UNIX und Windows, Indirekte Methoden des Zugriffs auf Daten: http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/
com.ibm.db2.luw.admin.sec.doc/doc/c0021061.html
v Informix Growth Edition-Sicherheit: http://publib.boulder.ibm.com/infocenter/
idshelp/v115/index.jsp?topic=/com.ibm.sec.doc/SEC_wrapper.htm
PCI DSS
PCI DSS besteht aus zwölf Basisanforderungen für die Zertifizierung, die Unternehmen erfüllen müssen, die mindestens eine der folgende Tätigkeiten ausführen:
Daten des kartengestützten Zahlungsverkehrs speichern, verarbeiten, übertragen
und/oder löschen. Jeder dieser zwölf Hauptpunkte ist in eine Reihe von untergeordneten Punkten unterteilt. Dieser Standard wurde im Rahmen einer Kooperation
von Unternehmen wie Visa, Mastercard, American Express und anderen entwickelt. Die Informationen in diesem Abschnitt beschränken sich der Kürze halber
auf die zwölf Hauptpunkte.
Die zwölf nachfolgend aufgeführten Basisanforderungen können logisch in Themen
gruppiert werden, die sich auf die Funktionsbereiche beziehen, die bei der Analyse
des ordnungsgemäßen Betriebs und der Stabilität eines gesicherten Netzes berücksichtigt werden müssen:
89
Erstellen und Pflegen eines gesicherten Netzes
Sichern Sie möglichst alle Zugänge zu den kritischen Systemen Ihres Unternehmens, indem Sie unbefugte Zugriffsversuche und unbekannte Angriffe blockieren. Dies hilft Ihnen dabei, zu gewährleisten, dass die Daten
von Karteninhabern sicher sind und dass Sie über eine zuverlässige erste
Abwehr gegen Sicherheitsverstöße verfügen.
1. Installieren und pflegen Sie eine Firewallkonfiguration zum Schutz der
Daten von Karteninhabern.
2. Verwenden Sie keine Standardeinstellungen des Herstellers für Systemkennwörter und andere Sicherheitsparameter.
Schützen der Daten von Karteninhabern
Schützen Sie die Daten von Karteninhabern, indem Sie das Versetzen, das
Speichern sowie das festnetzgebundene und das festnetzunabhängige
Übertragen von Daten kontrollieren.
3. Schützen Sie gespeicherte Daten von Karteninhabern.
4. Verschlüsseln Sie die Übertragung der Daten von Karteninhabern in offenen bzw. öffentlich zugänglichen Netzen.
Pflegen eines Verwaltungsprogramms zur Überwachung von Schwachstellen
Entwickeln und implementieren Sie effektive Sicherheitsprozeduren für alle
Anwendungen in Ihrer Infrastruktur, um Schwachstellen im Sicherheitssystem, wie beispielsweise das Eindringen von zerstörerischem Programmcode und Sicherheitslücken, zu minimieren.
5. Verwenden Sie Virenschutzsoftware bzw. Antivirenprogramme und aktualisieren Sie diese regelmäßig.
6. Entwickeln und pflegen Sie sichere Systeme und Anwendungen.
Implementieren strikter Zugriffskontrollmaßnahmen
Schränken Sie den Zugriff auf Daten von Karteninhabern ein, legen Sie Berechtigungsregeln und Benutzerberechtigungen fest und schützen Sie die
physische Datenumgebung gegen Sicherheitsverstöße.
7. Beschränken Sie den Zugriff auf Daten von Karteninhabern auf Personen
mit berechtigtem Geschäftsinteresse.
8. Ordnen Sie jeder Person mit Zugriff auf den Computer eine eindeutige
ID zu.
9. Schränken Sie den physischen Zugriff auf die Daten von Karteninhabern
ein.
Regelmäßiges Überwachen und Testen von Netzen
Bewerten Sie Ihre aktuelle Sicherheitssituation und vergewissern Sie sich,
dass Ihr Unternehmen sicher arbeitet, gegen Netz- und Sicherheitslücken
geschützt ist und den einschlägigen Bestimmungen entspricht.
10. Verfolgen und überwachen Sie den gesamten Zugriff auf Netzressourcen und die Daten von Karteninhabern.
11. Testen Sie die Sicherheitssysteme und -prozesse regelmäßig.
Implementieren einer Informationssicherheitsstrategie
Implementieren, veröffentlichen, verteilen und pflegen Sie eine Sicherheitsstrategie, die die Methoden Ihres Unternehmens zur Einhaltung von Sicherheitsvereinbarungen definiert und umsetzt.
90
12. Implementieren Sie eine Strategie für die Informationssicherheit für
Mitarbeiter und Auftragnehmer.
PCI DSS-Anforderungen
Die zwölf Punkte werden nun im Einzelnen erläutert, und es werden Empfehlungen zur Anwendung dieser Richtlinien in Ihrer Einzelhandelsumgebung gegeben.
1. Installieren und pflegen Sie eine Firewallkonfiguration zum Schutz der Daten
von Karteninhabern.
v Das Ziel ist die Kontrolle des Computerdatenverkehrs in das Netz und aus dem
Netz.
v Verwenden Sie eine dreistufige Methode:
– Verwenden Sie eine äußere Firewall zum Schutz der DMZ.
– Richten Sie den Web-Server in der DMZ ein.
– Verwenden Sie ein innere Firewall zum Schutz des Produktionsnetzes gegenüber der DMZ.
Trennen Sie Ihr Produktionsnetz von Ihrem Intranet.
2. Verwenden Sie keine Standardeinstellungen des Herstellers für Systemkennwörter und andere Sicherheitsparameter.
v Richten Sie den Benutzerzugriff auf der Basis von Richtlinien ein und verwenden Sie keine Standardeinstellungen.
v Führen Sie keine Muster, die mit Produkten bereitgestellt werden, in der Produktionsumgebung aus.
v Entfernen Sie JDKs, die vom Web-Server, vom Anwendungsserver und von
Plug-in-Installationsprogrammen stammen.
v Definieren Sie keine Standard-Benutzer-ID und kein Standardkennwort für eine
Ressource.
3. Schützen Sie gespeicherte Daten von Karteninhabern.
v Begrenzen Sie das Speichern der Daten von Karteninhabern auf ein Minimum.
v Machen Sie die Daten von Karteninhabern für unbefugt zugreifende Personen
unbrauchbar, indem Sie sicherstellen, dass das Speichern und der Backup von
Daten gesichert und verschlüsselt erfolgen und dass alle gelöschten Daten nicht
wiederherstellbar sind.
v Zeichnen Sie keine sensiblen Informationen in Traces oder Prüfprotokollen auf.
4. Verschlüsseln Sie die Übertragung der Daten von Karteninhabern in offenen
bzw. öffentlich zugänglichen Netzen.
v Verwenden Sie HTTPS im Browser, wenn Sie Authentifizierungen oder sonstige
Vorgänge durchführen, die geschützt ablaufen müssen.
v Konfigurieren Sie eine gesicherte Dateiübertragung. Ein Grund hierfür ist, dass
Knotenagenten Administrationskonfigurationsaktualisierungen über einen nicht
authentifizierten Dateiübertragungsservice abrufen. (WebSphere Application Server)
v Konfigurieren Sie Zertifikate, um eine angemessene webbasierte Administratorzertifikatsprüfung zu gewährleisten, indem Sie die Standardschlüsselringdatei
aktualisieren. (WebSphere Application Server)
91
v Ändern Sie die Standardschlüsseldatei (DummyServerKeyFile) und erstellen Sie
einen eigenen privaten Schlüssel und ein eigenes Zertifikat für die Kommunikation. (WebSphere Application Server)
v Verschlüsseln Sie die Standardlinks für die Nachrichtenübertragung, indem Sie
den InboundSecureMessaging-Transport verwenden. (WebSphere Application
Server)
v Verschlüsseln Sie die WebSphere MQ-Nachrichtenübertragungslinks, wenn Sie
WebSphere MQ anstelle des Standard-Messaging-Providers verwenden. (WebSphere Application Server)
v Schützen Sie die Anwendungsserververbindung zur Datenbank, um die Verschlüsselung zwischen dem Client und der Datenbank sicherzustellen. (WebSphere Application Server)
5. Verwenden Sie Virenschutzsoftware bzw. Antivirenprogramme und aktualisieren Sie diese regelmäßig.
Verwenden Sie stets die neuesten Patches und Programmkorrekturen.
6. Entwickeln und pflegen Sie sichere Systeme und Anwendungen.
v Beheben Sie Schwachstellen bei neuen und vorhandenen Systemen und Anwendungen. Sie müssen gewährleisten, dass kein Zugriff möglich ist, indem Sie Sicherheitslücken und sicherheitsrelevante Ereignisse in Ihrer Infrastruktur bewerten, überwachen, verwalten, analysieren und dokumentieren.
v Aktivieren Sie die globale Sicherheit. Standardmäßig stellt IBM WebSphere Application Server keine Sicherheit bereit. (WebSphere Application Server)
v Verschlüsseln Sie die WebSphere Application Server-LDAP-Verbindung. (WebSphere Application Server)
v Schützen Sie die privaten Schlüssel auf Ihren Dateisystemen vor gemeinsamem
Zugriff.
v Inaktivieren Sie nicht verwendete Ports und Services.
v Stellen Sie sicher, dass alle Servletaliasnamen sicher sind, indem Sie in der Datei
'web.xml' die entsprechenden Angaben machen.
v Verwenden Sie für die Bereitstellung von Servlets keine Klassennamen. (WebSphere Application Server)
v Speichern Sie keine sensiblen Informationen im WAR-Stammverzeichnis. (WebSphere Application Server)
v Definieren Sie eine Standardfehlerbehandlungsroutine, um zu verhindern, dass
Benutzer die unformatierten Nachrichten sehen.
v Ziehen Sie in Betracht, Dateiservices und das Browsing von Verzeichnissen zu
inaktivieren. (WebSphere Application Server)
v Aktivieren Sie die Sitzungssicherheit. (WebSphere Application Server)
v Verwenden Sie die WebSphere Application Server-Sicherheit, um Anwendungen
zu schützen. (WebSphere Application Server)
v Sichern Sie jede Anwendungsebene, vor allem EJBs.
v Überprüfen Sie die gesamte Benutzereingabe, um sicherzustellen, dass sie keine
potenziell gefährlichen Sonderzeichen enthält.
v Sperren Sie inaktive Benutzer, sobald die Sitzung nicht mehr benötigt wird.
(WebSphere Application Server)
v Aktivieren Sie die Java 2-Sicherheit, sodass die J2EE-Spezifikationen umgesetzt
werden, um die internen WebSphere Application Server-APIs vor unbefugtem
Zugriff zu schützen. (WebSphere Application Server)
92
v Aktivieren Sie die Klasse MQADMIN und definieren Sie die entsprechenden
Profile zum Schutz von Ressourcen in Befehlen. (WebSphere MQ)
v Starten Sie WebSphere MQ nicht über Rootzugriff, sondern über die MQSeriesAdministrator-ID 'mqm' unter UNIX. (WebSphere MQ)
v Erstellen Sie WebSphere MQ-Objekte nur mit der Benutzer-ID 'mqm' unter
UNIX. (WebSphere MQ)
7. Beschränken Sie den Zugriff auf Daten von Karteninhabern auf Personen mit
berechtigtem Geschäftsinteresse.
v Schränken Sie den Zugriff auf WebSphere MQ-Nachrichtenwarteschlangen ein,
indem Sie Benutzerauthentifizierung verwenden. (WebSphere Application Server) (WebSphere MQ)
v Geben Sie in der Befehlszeile keine Kennwörter als Parameter für Tools und Anwendungen an.
v Erstellen Sie separate IDs für Benutzer mit Verwaltungsaufgaben auf der Basis
der Benutzerrolle. Beispiel: Administrator, Bediener, Überwachungsbeauftragter
und Konfigurationsbeauftragter.
v Wählen Sie die geeignete Prozess-ID auf Betriebssystemebene aus.
v Stellen Sie sicher, dass nur berechtigte Benutzer über Zugriff auf folgende DB2Komponenten verfügen:
– Katalogsichten
– Protokoll-Lesefunktionen
–
–
–
–
–
–
Datenreplikation
Ausnahmetabellen
Backup-Tabellenbereich oder -Datenbank
Traces
Speicherauszugsdateien
db2dart
– db2cat
8. Ordnen Sie jeder Person, die über Zugriff auf den Computer verfügt, eine eindeutige ID zu.
v Stellen Sie sicher, dass Aktionen für kritische Daten und Systeme von bekannten
und berechtigten Benutzern ausgeführt werden und diesen zugeordnet werden
können.
v Definieren Sie keine Standard-Benutzer-ID und kein Standardkennwort für eine
Ressource.
9. Schränken Sie den physischen Zugriff auf die Daten von Karteninhabern ein.
v Kontrollieren Sie den physischen Zugang zu den gespeicherten Daten.
v Schützen Sie den JNDI-Namensbereich durch Einschränkung des Schreib-/
Lesezugriffs.
10. Verfolgen und überwachen Sie den gesamten Zugriff auf Netzressourcen und
die Daten von Karteninhabern.
v Sorgen Sie für Transparenz bei Ihrer Datensicherheit, indem Sie es möglich machen, Benutzeraktivitäten zu verfolgen und zu überwachen und die Ursachen
von Sicherheitsverstößen zu bestimmen.
v Zeichnen Sie keine sensiblen Informationen in Traces oder Prüfprotokollen auf.
93
11. Testen Sie die Sicherheitssysteme und -prozesse regelmäßig.
Nutzen Sie Methoden wie das Scannen von Ports, Tests zur Gewährleistung der Sicherheit vor unbefugtem Zugriff und präventives Hacken, um festzustellen, ob Ihr
Netz und Ihre Systeme die Sicherheitsanforderung erfüllen.
12. Implementieren Sie eine Strategie für die Informationssicherheit für Mitarbeiter und Auftragnehmer.
Stellen Sie sicher, dass die Mitarbeiter über ihre Aufgaben und ihre Verantwortung
hinsichtlich der Informationssicherheit informiert sind.
IBM Sicherheitslösungen für Payment Card Industry Data Security Standard (PCI DSS)
Wenn Sie für Ihr Unternehmen die Kompatibilität mit PCI DSS anstreben, bietet Ihnen IBM ein umfassendes Lösungsportfolio und ein Gesamtkonzept, mit dem Sie
dieses Ziel erreichen können. Zur IBM PCI DSS-Lösung gehören Beratungsleistungen für die Analyse von Kompatibilitätslücken, Korrektur, Prüfung, kontinuierliches Testen und Dokumentieren sowie eine Reihe von Produkten, die Unternehmen bei den einzelnen Aspekten der Sicherheitsplanung, Verwaltung und der
Kompatibilitätsprotokollierung unterstützen. Darüber hinaus ist IBM eines von
weltweit nur drei Unternehmen, die global zertifiziert sind, PCI-Bewertungen (PCI
Assessment), ein vierteljährliches PCI-Netzscanning (PCI Quarterly Network Scanning), PCI-Zahlungsanwendungsbewertungen (PCI Payment Application Assessments) und Services zur Reaktion auf Störungen im Zusammenhang mit PCI (PCI
Incident Response Services) auszuführen. Nur IBM bietet Lösungen, die alle zwölf
PCI DSS-Anforderungen berücksichtigen.
Weitere Informationen zur IBM PCI-Lösung finden Sie unter der folgenden Adresse: http://www.ibm.com/software/tivoli/governance/security/pci.html.
94
Kapitel 5. Erweiterung
In diesem Abschnitt werden die Tasks beschrieben, die an der Erweiterung von
IBM WebSphere Remote Server beteiligt sind.
Lösung erweitern
IBM WebSphere Remote Server bietet bei der Implementierung auf einem ISP einen
umfassenden Software-Stack als Basis für serverbasierte Anwendungen, die im Geschäft (oder in der Filiale) ausgeführt werden.
Der Software-Stack ist für sich genommen erst dann vollständig, wenn mindestens
eine Anwendung für die Ausführung mit WebSphere Remote Server installiert und
konfiguriert ist. Die WebSphere Remote Server-Entwicklungsumgebung stellt die
Tools bereit, die für die Erweiterung von WebSphere Remote Server mit Ihren Anwendungen erforderlich sind. Software Assembly Toolkit Developer ist das zentrale
Tool für die Entwicklung einer angepassten Lösung, mit der Ihre Anwendung in
den WebSphere Remote Server-Software-Stack integriert wird. Teil der WebSphere
Remote Server-Entwicklungsumgebung ist ein Arbeitsbereich mit allen Anwendungs-Deployment Accelerator-Projekten und Deployment Accelerator-Musterlösungsprojekten, die Sie für die Entwicklung einer eigenen Lösung benötigen.
Zur Entwicklung einer angepassten Lösung können Sie die vorhandenen Anwendungs-Deployment Accelerator-Projekte, mit denen die Middlewarekomponenten
und Fixpacks installiert werden, wiederverwenden. Darüber hinaus müssen Sie
Anwendungs-Deployment Accelerator-Projekte zum Installieren und Konfigurieren
Ihrer Anwendung entwickeln. Der WebSphere Remote Server-Arbeitsbereich stellt
Deployment Accelerator-Musterprojekte bereit, die mit keinem oder nur geringem
Codeentwicklungsaufwand kopiert und in Ihrer Lösung wiederverwendet werden
können.
Methoden zum Entwickeln von angepassten Lösungen
Es gibt zwei allgemeine Methoden, wie WebSphere Remote Server durch die Entwicklung angepasster Lösungen erweitert werden kann.
Die erste Methode eignet sich am besten für eine J2EE-Anwendung. Die Anwendung 'Plants By WebSphere' wird mithilfe einer Gruppe von Arbeitsbereichsprojekten als Muster bereitgestellt und bietet eine angepasste Lösung, die etwas Scripterstellung, aber nur wenig bzw. keine Java-Codierung umfasst.
Die zweite Methode eignet sich am besten für Anwendungen wie Standalone-Server oder Anwendungen, die mithilfe eines Installationsprogramms gepackt wurden. Bei dieser Methode ist im Allgemeinen mehr Java-Codeentwicklung erforderlich. Der WebSphere Remote Server-Arbeitsbereich stellt jedoch auch hierfür
Dienstprogrammklassen zur Verfügung, die die von Software Assembly Toolkit Developer bereitgestellte API erweitern und so die Entwicklung beschleunigen.
Musterlösungen
Zu den in der WebSphere Remote Server-Entwicklungsumgebung bereitgestellten
Musterlösungen gehört unter anderem 'Trade Performance Benchmark Sample for
IBM WebSphere Application Server' ('Trade') als Musteranwendung.
95
Im Kontext der Musterlösungen wird 'Trade' in zwei Anwendungs-Deployment
Accelerator-Projekte unterteilt. Das erste Projekt, 'TradeInstall', kopiert die Anwendungsdateien von 'Trade' auf den Server. Das zweite Anwendungs-Deployment
Accelerator-Projekt, 'TradeConfig', konfiguriert 'Trade' für die Ausführung auf dem
Server. Dank diesem zweiphasigen Verfahren zur Installation und Konfiguration
der Anwendung kann der Kunde flexibel entscheiden, wann die Konfigurationsphase beginnt. Die Installation und die Konfiguration können gleichzeitig im Rahmen der Erstinstallation der Lösung erfolgen, oder die Konfiguration kann einige
Zeit nach der Erstinstallation der Lösung durchgeführt werden.
Einer der Vorteile bei einer separaten Konfigurationsphase besteht darin, dass die
Konfiguration bei Bedarf wiederholt werden kann, ohne dass die gesamte Lösung
erneut installiert werden muss. Das Zurückstellen der Konfiguration ist auch in
umfangreichen Implementierungsszenarios vorteilhaft, wenn die Server auf einem
zentralen System vorkonfiguriert werden, jedoch nach ihrer Implementierung angepasst werden müssen.
Bei der in den Musterlösungen enthaltenen Anwendung 'Trade' wird ein Großteil
der Arbeit in der Konfigurationsphase ausgeführt. In der Installationsphase werden
die EAR-Datei und die Scripts kopiert, die zum Konfigurieren der Anwendung benötigt werden. In der Konfigurationsphase werden eine Datenbank mit Tabellen erstellt, die Anwendung in WebSphere Application Server implementiert, ein Script
zum Konfigurieren der Anwendung ausgeführt und ein Servlet zum Füllen der
Datenbank aufgerufen. Die beiden ersten Schritte der Konfigurationsphase können
in der Installationsphase ausgeführt werden.
Um das zweiphasige Verfahren zur Installation und Konfiguration Ihrer Anwendung nutzen zu können, müssen Sie in Software Assembly Toolkit Developer zwei
Anwendungs-Deployment Accelerator-Projekt erstellen. Das Anwendungs-Deployment Accelerator-Projekt für die Konfigurationsphase wird als Task zum LösungsDeployment Accelerator-Projekt 'WrsApplicationConfigurator' (WebSphere Remote
Server – Anwendungskonfigurationsprogramm) hinzugefügt. Wenn Sie die Anweisungen zum Erstellen der Musterlösung befolgen, wird die Lösung 'WrsApplicationConfigurator' als Solution Launcher-Image exportiert. Dies wiederum ist der
Inhalt des Implementierungsvorbereitungspakets für das in der Musterlösung enthaltene Anwendungs-Deployment Accelerator-Projekt 'ConfigWrapper' (Wrapper
für Anwendungskonfigurationsprogramm). Das Anwendungs-Deployment Accelerator-Projekt für die Installationsphase wird einfach als Task zu der Musterlösung
hinzugefügt.
Auch wenn die Anwendung auf das zweiphasige Verfahren ausgelegt ist, können
die Installation und die Konfiguration gleichzeitig erfolgen. Dazu müssen die Anwendungs-Deployment Accelerator-Projekte für die Installationsphase und die
Konfigurationsphase in derselben Lösung enthalten sein. In diesem Fall kann das
Anwendungs-Deployment Accelerator-Projekt 'ConfigWrapper' aus der Musterlösung entfernt werden, und die Lösung 'WrsApplicationConfigurator' muss nicht erstellt und exportiert werden.
WebSphere sMash
Das IBM WebSphere sMash-Anwendungsprojekt installiert WebSphere sMash und
IBM Reliable Transport Extension for WebSphere sMash.
Wenn Sie WebSphere sMash installieren, wird das IBM Reliable Transport Extension for WebSphere sMash-Image in einem Unterverzeichnis mit dem Namen
sMashRTE ebenfalls dem WebSphere sMash-Image hinzugefügt. Sie können Web-
96
Sphere sMash nicht ohne IBM Reliable Transport Extension for WebSphere sMash
installieren, es sei denn, Sie führen die Installation mithilfe der Produktplatten
durch.
Details dazu, wie Sie prüfen, dass WebSphere sMash installiert wurde, finden Sie
im Abschnitt „WebSphere sMash prüfen” auf Seite 33.
Weitere Informationen zur Verwendung von WebSphere sMash finden Sie im WebSphere sMash Information Center.
Musterlösung erstellen
Dieser Abschnitt enthält Anweisungen zum Erstellen der Lösungsprojekte 'SampleSolutionForWindows' (Musterlösung für Windows) und 'SampleSolutionForLinux'
(Musterlösung für Linux).
Muster erstellen
Gehen Sie wie folgt vor, um eine DVD der Musterlösung zu erstellen:
Vorgehensweise
1. Öffnen Sie Software Assembly Toolkit Developer.
2. Generieren Sie die Lösung 'WrsApplicationConfiguratorWithDB2' oder die Lösung 'WrsApplicationConfiguratorWithInformix'.
a. Erweitern Sie im Fenster Software Assembly Toolkit Developer die Kategorie Configuration Phase.
b. Erweitern Sie die Kategorie Solution Projects.
c. Klicken Sie mit der rechten Maustaste auf das Projekt WrsApplicationConfiguratorWithDB2 oder auf das Projekt WrsApplicationConfiguratorWithInformix.
d. Wählen Sie Generate Solution aus.
e. Klicken Sie im Fenster Solution Generation Successful auf OK.
3. Exportieren Sie die Lösung 'WrsApplicationConfiguratorWithDB2' oder die Lösung 'WrsApplicationConfiguratorWithInformix'.
a. Klicken Sie mit der rechten Maustaste auf das Projekt WrsApplicationConfiguratorWithDB2 oder auf das Projekt WrsApplicationConfiguratorWithInformix.
b. Wählen Sie Export aus.
c. Erweitern Sie im Fenster Export die Option Software Assembly Toolkit.
d. Wählen Sie Software Assembly Toolkit Solution Launcher Image aus und
e. Setzen Sie den Wert für Media size (MB) auf 650.
f. Geben Sie im Feld Export files to Folgendes ein:
C:\export\WAC
/tmp/export/WAC
g. Wählen Sie unter Operating systems die Optionen Windows und Linux
aus.
h. Klicken Sie auf Next.
i. Wählen Sie Do not export any deployment packages aus.
j. Klicken Sie auf Next.
k. Wählen Sie die Sprachen (Languages) aus und klicken Sie auf Finish.
97
l. Klicken Sie bei der Eingabeaufforderung Target directory does not exist.
Would you like to create it? auf Yes.
m. Klicken Sie im Fenster Solution Export Successful auf Yes oder No, um die
Frage nach dem Erfolg des Lösungsexports zu beantworten.
4. Generieren Sie das Implementierungspaket 'ConfigWrapperWithDb2' oder die
Lösung 'ConfigWrapperWithInformix'.
Erweitern Sie die Kategorie Installation Phase.
Erweitern Sie die Kategorie Application Projects.
Erweitern Sie die Kategorie Common.
Klicken Sie mit der rechten Maustaste auf ConfigWrapperWithDb2 oder auf
ConfigWrapperWithInformix und wählen Sie Generate Deployment Packages aus.
e. Geben Sie im Fenster Specify Location Folgendes ein:
C:\export\WAC\disk1
/tmp/export/WAC/disk1
a.
b.
c.
d.
Anmerkung: Dies ist die Position der zuvor exportierten Lösung
'WrsApplicationConfiguratorWithDB2' oder 'WrsApplicationConfiguratorWithInformix' mit dem angehängten Verzeichnis
disk1.
f. Klicken Sie auf OK.
g. Klicken Sie im Fenster Deployment Package Generation Successful auf
OK.
5. Generieren Sie das Implementierungspaket TradeInstall.
Anmerkung:
v Informix Growth Edition bietet keine Unterstützung für die
Anwendung 'Trade'.
v Wenn Sie die Anwendung 'Trade' auf einer Workstation mit der
Landessprache Deutsch verwenden, müssen Sie zuerst ein Upgrade für IBM WebSphere Application Server auf Version
7.0.0.11 durchführen.
a. Erweitern Sie die Kategorie Installation Phase.
b. Erweitern Sie die Kategorie Application Projects.
c. Erweitern Sie die Kategorie Common.
d. Klicken Sie mit der rechten Maustaste auf TradeInstall und wählen Sie Generate Application aus.
e. Klicken Sie mit der rechten Maustaste auf TradeInstall und wählen Sie Generate Deployment Packages aus.
f. Geben Sie im Fenster Specify Location Folgendes ein:
C:\Program Files\IBM\SIF\workspace\wrs71_x64\
TradeInstall\installpackage
/opt/IBM/SIF/workspace/wrs71_x64/TradeInstall/
installpackage
g. Klicken Sie auf OK.
h. Klicken Sie im Fenster Deployment Package Generation Successful auf
OK.
6. Generieren Sie die Lösung 'SampleSolutionForWindowsWithDB2' bzw. 'SampleSolutionForWindowsWithInformix' oder die Lösung
'SampleSolutionForLinuxWithDB2' bzw. 'SampleSolutionForLinuxWithInformix'.
98
Erweitern Sie die Kategorie Installation Phase.
Erweitern Sie die Kategorie Solution Projects.
Erweitern Sie die Kategorie Windows oder die Kategorie Linux.
Klicken Sie mit der rechten Maustaste auf das Lösungsprojekt.
'SampleSolutionForWindowsWithDB2' bzw. 'SampleSolutionForWindowsWithInformix'
'SampleSolutionForLinuxWithDB2' bzw. 'SampleSolutionForLinuxWithInformix'
e. Wählen Sie Generate Solution aus.
f. Klicken Sie im Fenster Solution Generation Successful auf OK.
7. Exportieren Sie die Lösung 'SampleSolutionForWindowsWithDB2' bzw. 'SampleSolutionForWindowsWithInformix' oder die Lösung
'SampleSolutionForLinuxWithDB2' bzw. 'SampleSolutionForLinuxWithInformix'.
a. Klicken Sie mit der rechten Maustaste auf das Lösungsprojekt.
'SampleSolutionForWindowsWithDB2' bzw. 'SampleSolutionForWindowsWithInformix'
'SampleSolutionForLinuxWithDB2' bzw. 'SampleSolutionForLinuxWithInformix'
a.
b.
c.
d.
b. Wählen Sie Export... aus.
c. Erweitern Sie im Fenster Export die Option Software Assembly Toolkit.
d. Wählen Sie Software Assembly Toolkit Solution Launcher Image aus und
e. Setzen Sie den Wert für Media size (MB) auf 650, um CD-Medien zu erstellen, oder auf 4482, um DVD-Medien zu erstellen.
f.
g.
h.
i.
j.
k.
Diese Zahl spielt nur dann eine Rolle, wenn Sie vorhaben, die Daten auf
CD- oder DVD-Datenträger zu kopieren.
Exportieren Sie die Dateien an folgende Position:
C:\export\SampleSolutionForWindows
/tmp/export/SampleSolutionForWindows
Wählen Sie unter Operating systems die Option Windows oder Linux aus.
Wählen Sie Export all deployment packages (typical) aus und klicken Sie
auf Next.
Wählen Sie die Sprachen (Languages) aus und klicken Sie auf Next.
l. Klicken Sie auf Finish.
m. Klicken Sie bei der Eingabeaufforderung Target directory does not exist.
Would you like to create it? auf Yes.
n. Klicken Sie im Fenster Solution Export Successful auf Yes oder No, um die
Frage nach dem Erfolg des Lösungsexports zu beantworten.
Anmerkung:
v Wenn Sie die Musterlösung auf einer Windows-Plattform installieren, müssen Sie alle Popup-Nachrichten der WindowsFirewall manuell bestätigen, um die Installation erfolgreich
auszuführen.
v Wenn Sie die Musterlösung über eine unbeaufsichtigte Installation auf einer Windows-Plattform installieren, müssen Sie die
99
Windows-Firewall vor dem Starten der Installation inaktivieren, um die unbeaufsichtigte Installation erfolgreich auszuführen.
Nächste Schritte
Ändern Sie die Musterlösung.
Musterlösung für unbeaufsichtigte Installation vorbereiten
Eine unbeaufsichtigte Installation wird normalerweise für die Implementierung
über Remotezugriff verwendet. Bei einer unbeaufsichtigten Installation ruft das Installationsprogramm die Konfigurationsinformationen aus einer Datei ab, nicht
vom Benutzer über eine grafische Benutzerschnittstelle.
Wichtig: Wenn Sie die unbeaufsichtigte Installation auf einer Windows-Plattform
starten, müssen Sie zuvor die Windows-Firewall inaktivieren, um die unbeaufsichtigte Installation erfolgreich auszuführen.
Zum Generieren einer Lösung, die unbeaufsichtigt installiert wird, müssen zwei
Schritte ausgeführt werden.
1. Erstellen Sie eine Taskdatei, in der die Tasks und Anwendungsprojektinformationen aufgeführt sind, die bei der Installation der Lösung verwendet werden.
2. Aktivieren Sie beim Export der Lösung die Option Run installation silently.
Mit jeder Musterlösung werden auch Mustertaskdateien bereitgestellt. Die Taskdateien befinden sich im Verzeichnis tasks unterhalb der Musterprojektverzeichnisse.
Der Taskdateiname für jedes der Musterprojekte lautet taskList.xml.
Informationen zu den Taskdateien und zur unbeaufsichtigten Installation finden
Sie im Menü Help von Software Assembly Toolkit Developer.
Musterlösung ändern
Es empfiehlt sich, die Musterlösung zunächst zu erstellen, bevor Sie sie ändern.
Dadurch wird sichergestellt, dass die Entwicklungsumgebung und die Musterlösung ordnungsgemäß installiert wurden. Es empfiehlt sich, die Erstellung auf einer
geschützten Basis zu starten.
Zum Ändern der Musterlösung müssen Sie die Konzepte von Software Assembly
Toolkit Developer verstehen. Software Assembly Toolkit Developer stellt Cheat
Sheets im Menü Help bereit. Überprüfen Sie folgende Cheat-Sheets:
v Deployment Accelerator für Lösungen erstellen
v
v
v
v
WebSphere-Deployment Accelerator-Projekt für Anwendungen erstellen
Anwendungs-Deployment Accelerator erstellen
Solution Launcher-Image exportieren und implementieren
Software Assembly Toolkit Developer verwenden
Sie können die Musterlösung auf unterschiedliche Weise ändern. Folgende Möglichkeiten stehen zur Verfügung:
v Musteranwendung entfernen
v Middlewareprodukt entfernen
v Eigene Anwendung oder Middleware hinzufügen
100
v Weitere Konfigurationsoptionen für die Anwendungs-Deployment AcceleratorProjekte bereitstellen
Zum Entfernen der Musteranwendung oder der Middleware müssen Sie das Projekt mit der Musterlösung öffnen. Entfernen Sie auf der Registerkarte Tasks die
Anwendungsprojekte aus der Taskliste.
Wenn Sie eine eigene Anwendung oder ein eigenes Middlewareprodukt hinzufügen wollen, müssen Sie ein Anwendungsprojekt und den für die Installation erforderlichen Quellcode erstellen. Anschließend erstellen Sie eine Task in dem Lösungsprojekt, das auf das erstellte Anwendungsprojekt verweist.
Sie können im Musterarbeitsbereich die Konfigurationsoptionen für die vorhandenen Anwendungsprojekte ändern. Öffnen Sie dazu ein Anwendungsprojekt und
wählen Sie die Registerkarte Variables aus. Geben Sie die Variablen für zusätzliche
Werte an, die in der Antwortdatei des Installationsprogramms für die Anwendung
verfügbar sind.
WebSphere Remote Server mit einer WebSphere-Musteranwendung erweitern
IBM WebSphere Remote Server enthält eine Musteranwendung, die eine generischere Lösung bietet, für die deutlich weniger Codeentwicklung erforderlich ist.
WebSphere Remote Server stellt eine vollständige Entwicklungsumgebung mit leistungsfähigen Tools zur Verfügung, die Sie bei der Entwicklung von integrierten Lösungen unterstützen. Diese Lösungen können ohne großen Aufwand in konsistenter Art und Weise implementiert werden. Software Assembly Toolkit ist das
Haupttool, in dem das Software Assembly Toolkit Developer-Plug-in für Eclipse
enthalten ist. Darüber hinaus ist ein vollständiger Eclipse-Arbeitsbereich mit allen
notwendigen Anwendungs- und Lösungsprojekten enthalten, die für die Entwicklung einer vollständigen Lösung auf der Basis von WebSphere Remote Server benötigt werden.
'Trade Performance Benchmark Sample for IBM WebSphere Application Server'
(Trade) ist als Musteranwendung in der WebSphere Remote Server-Lösungsentwicklungsumgebung enthalten. Die Anwendung wird von zwei Anwendungsprojekten mit dem Namen TradeInstall und TradeConfig installiert und konfiguriert.
Diese Anwendungsprojekte stellen eine Methode dar, mit der eine WebSphere-Anwendung auf der Basis eines WebSphere Remote Server-Middleware-Stacks implementiert und konfiguriert werden kann. Besonders das Projekt 'TradeConfig' veranschaulicht die Implementierung einer J2EE-Anwendung und die Konfiguration der
DB2 Workgroup Server Edition-Datenbank mithilfe von Scripts und anderem Code.
Um dieselbe Methode auf eine andere Anwendung anzuwenden, ist ein beträchtliches Maß an Code- und Scriptentwicklungsarbeit erforderlich, da die verwendeten Scripts speziell auf die Anwendung Trade zugeschnitten sind. WebSphere Remote Server enthält eine Musteranwendung, die eine generischere Lösung bietet,
für die deutlich weniger Codeentwicklung erforderlich ist. In diesem Abschnitt
wird die Methode beschrieben. Der Arbeitsbereich, der als Teil der WebSphere Remote Server-Lösungsentwicklungsumgebung installiert wird, enthält mehrere Software Assembly Toolkit Developer-Projekte, in denen die Methode veranschaulicht
wird. Bei der Musteranwendung handelt es sich um eine geänderte Version der
J2EE-Musteranwendung 'Plants By WebSphere'. Diese Anwendung wurde so geändert, dass sie JMS-Ressourcen einschließt, die eine Kommunikation mit IBM WebKapitel 5. Erweiterung
101
Sphere MQ ermöglichen; dadurch verfügen Sie über ein Beispiel, in dem der vollständige WebSphere Remote Server-Middleware-Stack Anwendung findet.
Erläuterung des Mustercodes
In diesem Abschnitt werden verschiedene Projekte beschrieben, aus denen sich der
Mustercode zusammensetzt. Außerdem erfahren Sie, wie Sie diese Projekte bei der
Entwicklung Ihrer Anwendung verwenden können.
Mustercode - Übersicht
Der Arbeitsbereich enthält die folgenden Projekte, aus denen sich der Mustercode
zusammensetzt:
v Db2Configuration: Dieses Projekt wurde als Schablonenprojekt entworfen, das
Sie in Ihre Lösung kopieren und dort wiederverwenden können. Dieses Projekt
wurde entworfen, um eine einzelne Datenbank und die nötigen Tabellen zu erstellen sowie um optional die Tabellen zu füllen. Wenn in Ihrer Lösung mehrere
Datenbanken erforderlich sind, können Sie mehrere (natürlich umbenannte) Kopien dieses Projekts in Ihrer Lösung verwenden. Sie benötigen dieses Projekt,
wenn in Ihrer Lösung eine DB2-Datenbank verwendet wird.
v IdsConfiguration: Dieses Projekt wurde als Schablonenprojekt entworfen, das
Sie in Ihre Lösung kopieren und dort wiederverwenden können. Dieses Projekt
wurde entworfen, um eine einzelne Datenbank und die nötigen Tabellen zu erstellen sowie um optional die Tabellen zu füllen. Wenn in Ihrer Lösung mehrere
Datenbanken erforderlich sind, können Sie mehrere (natürlich umbenannte) Kopien dieses Projekts in Ihrer Lösung verwenden. Sie benötigen dieses Projekt,
wenn in Ihrer Lösung eine Informix Growth Edition-Datenbank verwendet wird.
v MqConfiguration: Bei diesem Projekt handelt es sich um ein weiteres Schablonenprojekt, das Sie in Ihre Lösung kopieren und dort wiederverwenden können.
Dieses Projekt wurde entworfen, um einen einzelnen Warteschlangenmanager
und alle nötigen Kanäle sowie weitere MQ-Objekte zu erstellen. Werden in Ihrer
Lösung mehrere Warteschlangenmanager benötigt, können Sie dieses Projekt so
oft wie nötig in Ihre Lösung kopieren und dort umbenennen. Sie benötigen dieses Projekt, wenn in Ihrer Lösung WebSphere MQ verwendet wird.
v WasStandaloneProfileConfiguration: Dieses Projekt ist ein Schablonenprojekt,
das Sie in Ihre Lösung kopieren und dort wiederverwenden können. Es erstellt
einen Standalone-Anwendungsserver. Zu jedem Profil eines Standalone-Anwendungsservers gehört ein Anwendungsserverprozess 'server1'. Jedes Profil definiert einen separaten Standalone-Anwendungsserver, der über eine eigene Verwaltungsschnittstelle verfügt.
v PlantsByWebSphereDeployment: Dieses Projekt ist ein Musterprojekt, mit dem
veranschaulicht wird, wie eine J2EE-Anwendung in WebSphere Application Server implementiert und konfiguriert werden kann. Bei diesem Projekt handelt es
sich um ein WebSphere Application Server-Projekt, das von Software Assembly
Toolkit Developer aus einer vorhandenen Implementierung 'Plants By WebSphere' generiert wird. Dieses Projekt wurde für die Arbeit mit WebSphere Remote Server erweitert.
v PlantsByWebSphereSolutionForLinuxWithInformix and PlantsByWebSphereSolutionForLinuxWithDb2: Dieses Musterlösungsprojekt ist ein vollständiges
Beispiel, in dem alle oben genannten Musterprojekte und der komplette Satz
Middlewareprojekte enthalten ist. Dieses Projekt ähnelt den Projekten 'SampleSolutionForLinuxWithInformix' und 'SampleSolutionForLinuxWithDB2', die ebenfalls in der Entwicklungsumgebung von WebSphere Remote Server enthalten
sind.
102
v PlantsByWebSphereSolutionForWindowsWithInformix and PlantsByWebSphereSolutionForWindowsWithDb2: Diese Musterlösung ähnelt den Lösungen
'PlantsByWebSphereSolutionForLinuxWithInformix' und
'PlantsByWebSphereSolutionForLinuxWithDb2', schließt darüber hinaus aber die
Windows-spezifischen Projekte für die Middlewarekomponenten mit ein.
Diese Projekte werden in den folgenden Abschnitten detaillierter beschrieben.
Projekt 'Db2Configuration'
Das Projekt 'Db2Configuration' ist ein Anwendungs-Deployment Accelerator-Projekt von Software Assembly Toolkit Developer, das eine einzelne Datenbank erstellt
und Scripts ausführt, die zum Erstellen und Füllen von Tabellen erforderlich sind.
Dieses Projekt ist dazu gedacht, eine Schablone für angepasste Projekte zur Verfügung zu stellen. Der in der Anwendung bereitgestellte Java-Code ist so verallgemeinert, dass keine Anpassung erforderlich ist. Die in der Anwendung enthaltenen
Scripts führen die für Ihre Lösung spezifische Arbeit aus. Das gesamte Anwendungsprojekt kann innerhalb des Arbeitsbereichs kopiert werden. Es müssen lediglich die Scriptdateien geändert werden.
Variablen
Dieses Projekt weist nur eine Variable namens 'databaseName' auf. Diese Variable
steht für den Namen der zu erstellenden Datenbank. Sie können die Variable in Ihrer Lösung mit einem fest codierten Wert überschreiben oder die Benutzereingabe
für sie ermöglichen. Diese Variable kann in der Regel mit Variablen im Projekt
'WebSphere Application Deployment' verknüpft werden, um die nötigen Datenquellen zu erstellen.
Scriptdateien
Dieses Anwendungsprojekt enthält zwei Scripts:
v tables.ddl: Eine DDL-Datei, die die Tabellen für die Datenbank erstellt. Diese
Datei wird durch Ihre eigene Datei ersetzt, für sie sollte aber derselbe Name beibehalten werden. In der Regel kann eine DDL-Datei von einer vorhandenen Datenbank mit dem Befehl 'db2look' erstellt werden. Weitere Informationen finden
Sie im Information Center von DB2 unter der folgenden Adresse: http://
publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/
com.ibm.db2.luw.admin.cmd.doc/doc/r0002051.html.
v populate.sql: Eine Scriptdatei mit SQL-Befehlen zum Füllen von Datenbanktabellen. Diese Datei ist optional und die Datenbanktabellen werden nicht gefüllt,
wenn dieses Script im Anwendungsprojekt fehlt. Wenn Sie Ihr eigenes Script bereitstellen, muss es denselben Namen aufweisen.
Bei den in diesem Projekt enthaltenen Scripts handelt es sich um Musterdateien,
die speziell für die Anwendung 'PlantsByWebSphere' verwendet werden, und Sie
müssen diese Scripts durch Ihre eigenen Scripts ersetzen.
Projekt 'IdsConfiguration'
Das Projekt 'IdsConfiguration' ist ein Anwendungs-Deployment Accelerator-Projekt
von Software Assembly Toolkit Developer, das eine einzelne Datenbank erstellt
und Scripts ausführt, die zum Erstellen und Füllen von Tabellen erforderlich sind.
Dieses Projekt ist dazu gedacht, eine Schablone für angepasste Projekte zur Verfügung zu stellen. Der in der Anwendung bereitgestellte Java-Code ist so verallgeKapitel 5. Erweiterung
103
meinert, dass keine Anpassung erforderlich ist. Die in der Anwendung enthaltenen
Scripts führen die für Ihre Lösung spezifische Arbeit aus. Das gesamte Anwendungsprojekt kann innerhalb des Arbeitsbereichs kopiert werden. Es müssen lediglich die Scriptdateien geändert werden.
Variablen
Dieses Projekt weist nur eine Variable namens 'databaseName' auf. Diese Variable
steht für den Namen der zu erstellenden Datenbank. Sie können die Variable in Ihrer Lösung mit einem fest codierten Wert überschreiben oder die Benutzereingabe
für sie ermöglichen. Diese Variable kann in der Regel mit Variablen im Projekt
'WebSphere Application Deployment' verknüpft werden, um die nötigen Datenquellen zu erstellen.
Scriptdateien
Dieses Anwendungsprojekt enthält zwei Scripts:
v tables.sql: Eine SQL-Datei, die die Tabellen für die Datenbank erstellt. Diese Datei wird durch Ihre eigene Datei ersetzt, für sie sollte aber derselbe Name beibehalten werden.
v populate.sql: Eine Scriptdatei mit SQL-Befehlen zum Füllen von Datenbanktabellen. Diese Datei ist optional und die Datenbanktabellen werden nicht gefüllt,
wenn dieses Script im Anwendungsprojekt fehlt. Wenn Sie Ihr eigenes Script bereitstellen, muss es denselben Namen aufweisen.
Bei den in diesem Projekt enthaltenen Scripts handelt es sich um Musterdateien,
die speziell für die Anwendung 'PlantsByWebSphere' verwendet werden, und Sie
müssen diese Scripts durch Ihre eigenen Scripts ersetzen.
Projekt 'MqConfiguration'
Das Projekt 'MqConfiguration' ist ein Anwendungs-Deployment Accelerator-Projekt
von Software Assembly Toolkit Developer, das einen einzelnen Warteschlangenmanager für WebSphere MQ erstellt und anschließend ein MQSC-Script ausführt, um
verschiedene MQ-Objekte wie Warteschlangen, Kanäle usw. für diesen Warteschlangenmanager zu erstellen. Dieses Projekt soll als Schablone für angepasste
Projekte verwendet werden. Der Java-Code, der mit dem Projekt bereitgestellt
wird, ist generisch und darf nicht angepasst werden. Die im Projekt eingeschlossenen Scripts führen die Arbeit aus, die für Ihre spezifische Lösung notwendig ist.
Das gesamte Anwendungsprojekt kann innerhalb des Arbeitsbereichs kopiert werden. Es müssen lediglich die Scriptdateien geändert werden.
Variablen
Dieses Projekt weist die folgenden Variablen auf:
v queueMgrName: Dies ist der Name des zu erstellenden Warteschlangenmanagers. Der Name kann auf der Lösungsebene mit einem vorher festgelegten Wert
überschrieben werden oder er kann dem Benutzer zum Ändern verfügbar gemacht werden.
v isDefaultQueueMgr: Dies ist eine boolesche Variable, die festlegt, ob dieser Warteschlangenmanager als Systemstandardwert verwendet werden soll. In der Regel nimmt diese Variable standardmäßig den Wert 'true' (wahr) an, sofern Ihre
Lösung nicht mehrere Warteschlangenmanager benötigt. Der Wert für diese Variable muss während der Entwurfsphase festgelegt werden. Diese Variable sollte
dem Benutzer, der die Lösung installiert, nicht verfügbar gemacht werden.
104
v createDeadLetterQueue: Dies ist eine boolesche Variable, die festlegt, ob die Systemwarteschlange für nicht zustellbare Nachrichten für diesen Warteschlangenmanager erstellt werden soll. In der Regel nimmt diese Variable standardmäßig
den Wert 'true' (wahr) an, sofern Ihre Lösung nicht mehrere Warteschlangenmanager benötigt. Diese Variable muss auch auf der Lösungsebene definiert werden, und sie darf dem Benutzer, der die Lösung installiert, nicht verfügbar gemacht werden.
v createPubSubQueues: Dies ist eine boolesche Variable, die festlegt, ob JMS Publish/Subscribe-Warteschlangen erstellt werden sollen. Wenn der Wert ‘true'
(wahr) ist, wird standardmäßig die Musterdatei 'MQJMS_PSQ.mqsc' im WebSphere MQ-Verzeichnis ausgeführt. Enthält das Anwendungsprojekt jedoch eine
Datei namens pubsub.mqsc, wird diese stattdessen ausgeführt. Wenn der Wert
dieser Variable 'false' (falsch) lautet, werden keine MQSC-Dateien ausgeführt
und keine weiteren Warteschlangen erstellt. Diese Variable muss ebenfalls auf
der Lösungsebene definiert werden, und sie darf dem Benutzer, der die Lösung
installiert, nicht verfügbar gemacht werden.
Scriptdateien
Dieses Projekt enthält eine erforderliche MQSC-Scriptdatei. Eine optionale zweite
MQSC-Scriptdatei kann in das Projekt aufgenommen werden, um ein angepasstes
Script für JMS-Publish/Subscribe-Warteschlangen zur Verfügung zu stellen.
v default.mqsc: Dies ist die Standard-MQSC-Scriptdatei, die nach dem Erstellen
des Warteschlangenmanagers ausgeführt wird. Diese Scriptdatei ist erforderlich
und muss den Namen 'default.mqsc' aufweisen. In der Regel kann diese MQSCDatei aus einer vorhandenen MQ-Installation mithilfe von 'saveqmgr' (SupportPac) generiert werden. Weitere Informationen finden Sie unter der folgenden Adresse: http://www.ibm.com/support/docview.wss?uid=swg24000673.
v pubsub.mqsc: Diese Datei ist optional und sie ist standardmäßig nicht in der
Anwendung enthalten. Wird diese Datei dem Anwendungsprojekt hinzugefügt
und hat 'createPubSubQueues' den Wert 'true', wird dieses Script ausgeführt.
Diese Option soll bei Bedarf eine Alternative zu dem mit WebSphere MQ bereitgestellten Muster-JMS-Publish/Subscribe-Script darstellen.
Bei der in diesem Projekt enthaltenen Scriptdatei handelt es sich um eine Musterdatei, die speziell für die Anwendung 'PlantsByWebSphere' verwendet wird, und
Sie müssen dieses Script durch Ihr eigenes Script ersetzen.
Projekt 'WasStandaloneProfileConfiguration'
Das Projekt 'WasStandaloneProfileConfiguration' ist ein Anwendungs-Deployment
Accelerator-Projekt von Software Assembly Toolkit Developer, das einen Standalone-Anwendungsserver erstellt. Zu jedem Profil eines Standalone-Anwendungsservers gehört ein Anwendungsserverprozess 'server1'. Jedes Profil definiert einen separaten Standalone-Anwendungsserver, der über eine eigene
Verwaltungsschnittstelle verfügt.
Variablen
Dieses Projekt weist die folgenden Variablen auf:
v profileName: Der Name des zu erstellenden Profils. Der Profilname muss für
diese WebSphere Application Server-Installation eindeutig sein.
v nodeName: Der Knotenname für den Anwendungsserver. Der Knotenname
muss innerhalb einer Zelle eindeutig sein.
105
v enableAdminSecurity: Ein boolescher Wert, den Sie festlegen können, um die
Verwaltungssicherheit zu aktivieren. Wenn dieser Wert auf 'true' (wahr) gesetzt
ist, müssen Benutzer sich anmelden, um auf die Verwaltungstools von WebSphere Application Server zugreifen zu können. Der Name eines Benutzers mit
Verwaltungsaufgaben und das zugehörige Kennwort sind erforderlich, wenn
diese Option aktiviert ist.
v wasAdminUser: Benutzer-ID für den Zugriff auf WebSphere Application ServerVerwaltungstools. Diese Variable ist erforderlich, wenn Sie die Verwaltungssicherheit verwenden.
v wasAdminPassword: Das Kennwort eines Benutzers mit Verwaltungsaufgaben.
Diese Variable ist erforderlich, wenn Sie die Verwaltungssicherheit verwenden.
v runAsService: Ein boolescher Wert, den Sie festlegen können, um WebSphere
Application Server für die Ausführung als Service zu aktivieren.
Scriptdateien
Zum Projekt gehören zwei Scriptdateien.
v CreateDataSource.py: Erstellt eine JDBC-Datenquelle für Ihre DB2- oder Informix Growth Edition-Datenbank.
v enableWASSecurityLocalOS.jacl: Aktiviert die Sicherheit für WebSphere Application Server.
v
Projekt 'PlantsByWebSphereDeployment'
Das Projekt 'PlantsByWebSphereDeployment' ist ein WebSphere-Anwendungsimplementierungs-Accelerator-Projekt von Software Assembly Toolkit Developer. Es
handelt sich um ein Projekt, das automatisch von einer vorhandenen WebSphere
Application Server-Implementierung unter Verwendung des Assistenten 'New Project' innerhalb von Software Assembly Toolkit Developer generiert wird. Dieses
Projekt wird mit einer Deployment Accelerator-Klasse erweitert, um die auf WebSphere Remote Server beschränkten Funktionen zu verwenden.
Dieses Projekt dient als Mustercode, um die Basiselemente eines Projekts 'WebSphere Application Deployment Accelerator' darzustellen. Darüber hinaus zeigt es,
wie diese Elemente mit der spezielle Deployment Accelerator-Klasse interagieren.
Wenn es an die Umsetzung geht, werden Sie aber Ihr eigenes Projekt auf der Basis
Ihrer WebSphere-Anwendung generieren. Weitere Informationen zur Verwendung
des Assistenten 'WebSphere Application Deployment Accelerator Project' finden Sie
unter der folgenden Adresse: http://publib.boulder.ibm.com/infocenter/satinfo/
v3r2/topic/com.ibm.sat.doc/concepts/cerwebap.htm.
Anwendungsprojektdateien
Die folgenden Dateien bilden den Kern des Projekts (diese Liste ist nicht vollständig):
v PlantsByWebSphereEAR-1.1.1.ear: Diese J2EE-Archivdatei enthält die Anwendung 'PlantsByWebSphere'. Sie wird automatisch vom Assistenten generiert.
v DeployWebApplications.java: Dies ist das Hauptprogramm, das die Installation
ausführt, indem es den Befehl 'wsadmin' mit verschiedenen Python-Scripts aufruft, um die Anwendung zu implementieren und zu konfigurieren. Hierbei handelt es sich um den Standardcode, der vom Assistenten generiert wird.
106
v DeployWebApplications.py und DeployWebApplicationsProfile.py: Diese Python-Scripts werden von dem Befehl 'wsadmin' ausgeführt, um die EAR-Datei
zu implementieren und die Anwendung zu konfigurieren. Diese Scripts werden
automatisch vom Assistenten generiert.
v DeployWebApplications.bat: Mit dieser einfachen Batchdatei wird der Befehl
'wsadmin' im Windows-Betriebssystem aufgerufen. Diese Datei wird vom Assistenten bereitgestellt.
v DeployWebApplications.properties: Diese Eigenschaftendatei agiert als “Antwortdatei” für die Installation der Anwendung und wird verwendet, um Variablen von Deployment Wizard an den Java- und Python-Code zu übergeben.
v WrsDeployWebApplications.java: Hierbei handelt es sich um die Deployment
Accelerator-Klasse, die dem Projekt hinzugefügt wird. Diese Klasse stellt das
Hauptprogramm für das Anwendungsprojekt dar und erweitert die Klasse 'DeployWebApplications'. Dadurch können die Variablen modifiziert werden, die an
die Anwendung übergeben werden, die auf einer vorherigen Installation von
WebSphere Remote Server basiert. Dies ist besonders nützlich, wenn Sie die Verwendung des zwei Phasen umfassenden Data-Warehouse-Modells der Implementierung und Konfiguration planen (wie in der oben angegebenen Veröffentlichung beschrieben wird) oder wenn Sie eine bereits implementierte Lösung mit
einer neuen Anwendung erweitern wollen. Dieser Code soll als Standard dienen,
er muss aber abhängig von Ihrer Anwendung unter Umständen geringfügig geändert werden.
Variablen
Die im Anwendungs-Deployment Accelerator-Projekt verfügbaren Variablen sind
teilweise auf die Optionen zurückzuführen, die Sie bei der Ausführung des Assistenten zum Erstellen des Projekts ausgewählt haben. Das Projekt 'PlantsByWebSphereDeployment' enthält Variablen, die das Ergebnis der Generierung eines typischen Projekts 'WebSphere WebSphere Application Deployment Accelerator' sind.
Einige dieser Variablen werden als Befehlszeilenparameter an die Klasse 'DeployWebApplications' übergeben, einige Variablen werden der Antworteigenschaftendatei 'DeployWebApplications.properties' zugeordnet und einige Variablen werden
von der Deployment Accelerator-Klasse 'WrsDeployWebApplications' auf der Basis
der Werte überschrieben, die von einer vorherigen (oder aktuellen) Installation einer WebSphere Remote Server-Lösung abgerufen wurden. Diese Variablen werden
nachfolgend detaillierter beschrieben:
v WAS_HOME_AIX: Eine Dateipfadvariable, die auf das WebSphere Application
Server-Installationsverzeichnis auf der AIX-Plattform verweist. Da WebSphere
Remote Server derzeit die AIX-Plattform nicht unterstützt, ist diese Variable
standardmäßig eine Nullzeichenfolge. Diese Variable darf dem Benutzer, der die
Lösung installiert, nicht verfügbar gemacht werden.
v WAS_HOME_LINUX: Eine Dateipfadvariable, die auf das WebSphere Application Server-Installationsverzeichnis auf der Linux-Plattform verweist. Diese Variable wird von der Wrapperklasse 'WrsDeployWebApplications' mit dem Wert
der Variablen 'installLocation' aus dem Anwendungsprojekt 'Was_61013_Lnx'
überschrieben. Folglich darf diese Variable dem Benutzer, der die Lösung installiert, nicht verfügbar gemacht werden.
v WAS_HOME_OS400: Eine Dateipfadvariable, die auf das WebSphere Application Server-Installationsverzeichnis auf der iSeries-Plattform verweist. Da WebSphere Remote Server derzeit die iSeries-Plattform nicht unterstützt, ist diese
Variable standardmäßig eine Nullzeichenfolge. Diese Variable darf dem Benutzer, der die Lösung installiert, nicht verfügbar gemacht werden.
107
v WAS_HOME_WINDOWS: Eine Dateipfadvariable, die auf das WebSphere Application Server-Installationsverzeichnis auf der Windows-Plattform verweist.
Diese Variable wird von der Wrapperklasse 'WrsDeployWebApplications' mit
dem Wert der Variablen 'installLocation' aus dem Anwendungsprojekt
'Was_61013_Win' überschrieben. Folglich darf diese Variable dem Benutzer, der
die Lösung installiert, nicht verfügbar gemacht werden.
v USER: Der WebSphere Application Server-Benutzer mit Verwaltungsaufgaben.
Diese Variable wird von der Wrapperklasse 'WrsDeployWebApplications' mit
dem Wert der Variablen 'wasAdminUser' aus dem Anwendungsprojekt 'WasStandaloneProfileConfiguration' (WebSphere Application Server - Konfiguration
des Standalone-Profils) überschrieben. Folglich darf diese Variable dem Benutzer,
der die Lösung installiert, nicht verfügbar gemacht werden.
v PASSWORD: Das Kennwort des WebSphere Application Server-Benutzers mit
Verwaltungsaufgaben. Diese Variable wird von der Wrapperklasse 'WrsDeployWebApplications' mit dem Wert der Variablen 'wasAdminPassword' aus dem
Anwendungsprojekt 'WasStandaloneProfileConfiguration' überschrieben. Folglich
darf diese Variable dem Benutzer, der die Lösung installiert, nicht verfügbar gemacht werden.
v databaseName: Der Name der zu erstellenden Datenbank. Diese Variable muss
auf der Lösungsebene mit der Variablen 'databaseName' aus dem Anwendungsprojekt 'Db2Configuration' verknüpft werden.
v dsalias_userId: Die Datenbankbenutzer-ID für den Authentifizierungsaliasnamen
'dsAlias'. Diese Variable wird von der Wrapperklasse 'WrsDeployWebApplications' mit dem Wert der Variablen 'instanceUser' aus den Anwendungsprojekten
'Db2_95_Win' oder 'Db2_95_Lnx' überschrieben. Folglich darf diese Variable dem
Benutzer, der die Lösung installiert, nicht verfügbar gemacht werden.
v dsalias_password: Das Datenbankbenutzerkennwort für den Authentifizierungsaliasnamen 'dsAlias'. Diese Variable wird von der Wrapperklasse 'WrsDeployWebApplications' mit dem Wert der Variablen 'instancePassword' aus den Anwendungsprojekten 'Db2_95_Win' oder 'Db2_95_Lnx' überschrieben. Folglich darf
diese Variable dem Benutzer, der die Lösung installiert, nicht verfügbar gemacht
werden.
v queueManagerName: Der Name des zu erstellenden Warteschlangenmanagers.
Diese Variable muss auf der Lösungsebene mit der Variablen 'queueMgrName'
aus dem Anwendungsprojekt 'MqConfiguration' verknüpft werden.
Projekte 'PlantsByWebSphereSolutionForLinuxWithInformix',
'PlantsByWebSphereSolutionForLinuxWithDb2', 'PlantsByWebSphereSolutionForWindowsWithInformix' und
'PlantsByWebSphereSolutionForWindowsWithDb2'
Diese Lösungs-Deployment Accelerator-Projekte, die den Projekten 'SampleSolutionForLinuxWithInformix' (Musterlösung für Linux mit Informix),
'SampleSolutionForLinuxWithDB2' (Musterlösung für Linux mit DB2), 'SampleSolutionForWindowsWithInformix' (Musterlösung für Windows mit Informix) und
'SampleSolutionForWindowsWithDB2' (Musterlösung für Windows mit DB2) ähneln, kombinieren die oben angeführten Anwendungs-Deployment AcceleratorProjekte mit den Anwendungs-Deployment Accelerator-Projekten für Middleware
für die entsprechende Plattform zu vollständigen Lösungen. Da die Lösungen in
ähnlicher Art und Weise erstellt werden, gilt die folgende Beschreibung für alle
Lösungs-Deployment Accelerator-Projekte.
Die Lösung besteht aus zwei Tasks. Die erste übergeordnete Task für die Installation der Lösungsmiddleware (Install Solution Middleware) umfasst die untergeord-
108
neten Tasks, die zur Installation des WebSphere Remote Server-Software-Stacks,
einschließlich IBM HTTP Server, WebSphere Application Server, DB2 und WebSphere MQ, notwendig sind. Die zweite übergeordnete Task für die Installation
und Konfiguration der Anwendung (Install and configure Application), umfasst die
Anwendungsprojekte 'Db2Configuration', 'MqConfiguration' und 'PlantsByWebSphereDeployment' als untergeordnete Tasks. Alle Variablen für diese drei Anwendungsprojekte werden auf der Lösungsebene überschrieben. Die folgende Tabelle
enthält die Variablen und eine Erläuterung dazu, wie sie überschrieben werden.
Tabelle 8. Anwendungsvariablen, die auf Lösungsebene überschrieben werden
Anwendungsprojekt
Variablenname
Db2Configuration
databaseName
Beschreibung der Überschreibung
Wird als databaseName gemeinsam genutzt
MqConfiguration
queueMgrName
Wird als queueMgrName gemeinsam genutzt
MqConfiguration
isDefaultQueueMgr
Wird ausgeblendet und nimmt standardmäßig
den Wert 'true' an
MqConfiguration
createDeadLetterQueue
den Wert 'true' an
MqConfiguration
createPubSubQueues
den Wert 'true' an
PlantsByWebSphereDeployment
WAS_HOME_AIX
Wird ausgeblendet
WAS_HOME_LINUX
Wird ausgeblendet
WAS_HOME_OS400
Wird ausgeblendet
WAS_HOME_WINDOWS
Wird ausgeblendet
databaseName
Wird als databaseName gemeinsam genutzt
queueManagerName
Wird als queueMgrName gemeinsam genutzt
USER
Wird ausgeblendet
PASSWORD
Wird ausgeblendet
dsalias_userId
Wird ausgeblendet
dsalias_password
Wird ausgeblendet
Musterlösung 'PlantsByWebSphere' verwenden
Erstellen und testen Sie anhand dieser Anweisungen die Implementierung der
Musteranwendung 'PlantsByWebSphere' für IBM WebSphere Remote Server.
Es wird davon ausgegangen, dass die Entwicklungsumgebung von WebSphere Remote Server auf einer Entwicklungsworkstation installiert ist und dass außerdem
ein Testserver zur Verfügung steht, um die Implementierung zu testen (Testserver
und Entwicklungsworkstation können identisch sein). Führen Sie zum Erstellen
und Testen der Lösung die folgenden Schritte aus:
Vorgehensweise
1. Klicken Sie in Software Assembly Toolkit Developer abhängig von der Zielplattform, auf der Sie die Implementierung testen wollen, mit der rechten
Maustaste auf PlantsByWebSphereSolutionForLinuxWithDb2 (PlantsByWebSphere-Lösung für Linux mit DB2), PlantsByWebSphereSolutionForLinuxWithInformix (PlantsByWebSphere-Lösung für Linux mit Informix), PlantsByWebSphereSolutionForWindowsWithDb2 (PlantsByWebSphere-Lösung für Windows
mit DB2) oder PlantsByWebSphereSolutionForWindowsWithInformix (PlantsByWebSphere-Lösung für Windows mit Informix).
2. Wählen Sie Generate solution im Popup-Menü aus.
3. Führen Sie die folgenden Schritte aus, wenn Sie die Implementierung auf der
Entwicklungsworkstation testen wollen.
109
a. Klicken Sie mit der rechten Maustaste erneut auf dasselbe Lösungsprojekt
und wählen Sie die Option Test in Deployment Wizard im Menü aus.
b. Sobald Deployment Wizard angezeigt wird, befolgen Sie den Eingabeaufforderungen, um die Implementierung zu testen.
4. Führen Sie alternativ hierzu die folgenden Schritte aus, wenn Sie die Implementierung auf einem separaten Server testen wollen:
a. Klicken Sie mit der rechten Maustaste auf dasselbe Lösungsprojekt und
wählen Sie Export im Menü aus.
b. Wenn das Dialogfenster Export geöffnet wird, wählen Sie die Optionen
Software Assembly Toolkit → Software Assembly Toolkit Solution Launcher Image in der Liste der Exportziele aus und klicken Sie anschließend
auf Next.
c. Geben Sie die Verzeichnisposition To an, an der das Image erstellt werden
soll, und klicken Sie auf Finish. Das Solution Launcher-Image kann auf den
Testserver kopiert oder auf eine DVD gebrannt werden. Deployment Wizard
wird mithilfe der Startprogrammdatei (je nach Plattform WindowsSetup.exe
oder LinuxSetup) aufgerufen. Sobald Deployment Wizard angezeigt wird,
befolgen Sie die Eingabeaufforderungen, um die Implementierung zu testen.
5. Zum Testen der Implementierung der Musterlösung verweisen Sie mit einem
Browser auf die folgende Adresse: http://server:9080/PlantsByWebSphere/
index.jsp. Dabei ist server der Hostname des Servers, auf dem Sie die Lösung
implementiert haben. Nun können Sie die Musteranwendung 'PlantsByWebSphere' anzeigen.
Eigene Lösungen entwickeln
Damit Sie Ihre eigene Lösung mithilfe der in diesem Abschnitt beschriebenen Verfahren entwickeln können, müssen Sie diese Basisrichtlinien befolgen.
Schablonenprojekte kopieren und anpassen
Die Projekte 'Db2Configuration' (DB2 - Konfiguration) und 'MqConfiguration'
(WebSphere MQ – Konfiguration) sollen als Schablonen verwendet werden. Kopieren Sie die vollständigen Projekte einfach mit einem neuen Namen und ersetzen
Sie die Scriptdateien durch Ihre eigenen. Kopieren Sie nur die Projekte, die in Ihrer
Lösung Anwendung finden. Wenn Ihre Lösung z. B. IBM WebSphere MQ nicht benötigt, können Sie auf das Projekt 'MqConfiguration' verzichten. Sie können andererseits die Projekte so oft wie nötig kopieren, um die Voraussetzungen für Ihre
Lösung zu erfüllen. Wenn Ihre Lösung z. B. zwei oder mehr Datenbanken benötigt,
können Sie die Projekte 'Db2Configuration' so oft wie erforderlich kopieren.
Das Projekt 'Db2Configuration' anpassen
1. Klicken Sie mit der rechten Maustaste auf das Projekt Db2Configuration in
Software Assembly Toolkit Developer und wählen Sie im Popup-Menü die Option Copy aus.
2. Klicken Sie mit der rechten Maustaste auf eine beliebige Position im Teilfenster
Navigator und wählen Sie im Menü die Option Paste aus. Das Dialogfenster
Copy Project wird geöffnet. Geben Sie einen neuen Projektnamen an und klicken Sie auf OK. Das Projekt wird kopiert.
3. Erweitern Sie unter Verwendung des Fensters Navigator die Sicht unterhalb Ihres neu kopierten Projekts und navigieren Sie abwärts zum Verzeichnis
src|userPrograms. Dort finden Sie zwei Scriptdateien: tables.ddl und populate.sql. Sie müssen diese Dateien durch Ihre eigenen Scripts ersetzen, dabei ist
110
es allerdings wichtig, dass die neuen Scripts dieselben Namen aufweisen. Obwohl Sie diese Dateien manuell bearbeiten können, gibt es bessere Methoden,
diese Scripts zu generieren.
4. Der Inhalt der Datei tables.ddl kann von einer vorhandenen Datenbank mithilfe des Befehls db2look generiert werden. Weitere Informationen finden Sie
unter der folgenden Adresse: http://publib.boulder.ibm.com/infocenter/
db2luw/v9r7/topic/com.ibm.db2.luw.admin.cmd.doc/doc/r0002051.html.
5. Die Scriptdatei populate.sql kann aus dem Projekt entfernt werden, wenn die
Tabellen nicht im Voraus gefüllt werden müssen, bevor die Anwendung ausgeführt werden kann. Einige Anwendungen füllen die Datenbank während der
Ausführung mithilfe serverseitigen Codes, wie z. B. mithilfe eines Servlets. In
diesem Fall wird die Datei populate.sql nicht benötigt. Andernfalls fügen Sie
die nötigen INSERT-Anweisungen hinzu, um die Tabellen nach Bedarf zu füllen.
Das Projekt 'IdsConfiguration' anpassen
1. Klicken Sie mit der rechten Maustaste auf das Projekt IdsConfiguration in Software Assembly Toolkit Developer und wählen Sie im Popup-Menü die Option
Copy aus.
2. Klicken Sie mit der rechten Maustaste auf eine beliebige Position im Fenster
3. Erweitern Sie über das Fenster Navigator die Sicht unterhalb Ihres neu kopierten Projekts und navigieren Sie zum Verzeichnis src|userPrograms, in dem sich
die zwei folgenden Scriptdateien befinden: tables.sql und populate.sql. Ersetzen Sie diese Dateien durch Ihre eigenen Scripts, behalten Sie jedoch dieselben Scriptnamen bei. Obwohl Sie diese Dateien manuell bearbeiten können,
gibt es bessere Methoden, diese Scripts zu generieren.
4. Die Scriptdatei populate.sql kann aus dem Projekt entfernt werden, wenn die
Tabellen nicht im Voraus gefüllt werden müssen, bevor die Anwendung ausgeführt werden kann. Einige Anwendungen füllen die Datenbank während der
Ausführung mithilfe serverseitigen Codes, wie z. B. mithilfe eines Servlets. In
diesem Fall wird die Datei populate.sql nicht benötigt. Andernfalls fügen Sie
die nötigen INSERT-Anweisungen hinzu, um die Tabellen nach Bedarf zu füllen.
Das Projekt 'MqConfiguration' anpassen
1. Klicken Sie mit der rechten Maustaste auf das Projekt MqConfiguration in
Software Assembly Toolkit Developer und wählen Sie Copy im Menü aus.
2. Klicken Sie mit der rechten Maustaste auf eine beliebige Position im Teilfenster
3. Erweitern Sie unter Verwendung des Fensters Navigator die Sicht unterhalb Ihres neu kopierten Projekts und navigieren Sie abwärts zum Verzeichnis
src|userPrograms. Suchen Sie die Scriptdatei mit dem Namen default.mqsc.
Ersetzen Sie diese Dateien durch Ihre eigenen Scripts, behalten Sie jedoch dieselben Scriptnamen bei. Obwohl Sie diese Datei manuell bearbeiten können,
gibt es bessere Methoden, dieses Script zu generieren.
4. Der Inhalt der Datei default.mqsc kann manuell mit den MQSC-Befehlen codiert werden, die für das Erstellen der nötigen Warteschlangen, Kanäle und
weiterer Objekte für Ihre Lösung benötigt werden. Es kann jedoch ein Satz von
111
MQSC-Befehlen automatisch von einer vorhandenen WebSphere MQ-Installation mithilfe von 'saveqmgr' (SupportPac) generiert werden. Weitere Informationen finden Sie unter der folgenden Adresse: http://www.ibm.com/support/
docview.wss?uid=swg24000673.
5. Das in WebSphere MQ enthaltene JMS-Publish/Subscribe-Beispielscript wird
standardmäßig als Teil dieses Anwendungsprojekts ausgeführt. Wenn Sie stattdessen Ihr eigenes Script ausführen wollen, können Sie es dem Projekt unter
dem Namen pubsub.mqsc hinzufügen. Diese Datei ist im Projekt nicht standardmäßig enthalten.
Projekt 'WebSphere Deployment Accelerator' erstellen und erweitern
Der Assistent für das Projekt 'WebSphere Deployment Accelerator' ist die einfachste
Methode für das Erstellen eines Anwendungsprojekts zur Implementierung und
Konfiguration Ihrer WebSphere-Anwendung. Damit Sie diesen Assistenten verwenden können, muss Ihre Anwendung bereits auf einem Server implementiert und
konfiguriert sein, auf den über ein Netz von der Entwicklungsworkstation aus zugegriffen werden kann, auf der Software Assembly Toolkit Developer verwendet
wird. Zuerst muss das Projekt generiert werden. Anschließend wird das Projekt für
die Verwendung mit IBM WebSphere Remote Server erweitert.
Projekt 'WebSphere Deployment Accelerator' erstellen
Vollständige Anweisungen für die Verwendung des Assistenten für das Projekt
'WebSphere Deployment Accelerator' finden Sie unter der folgenden Adresse:
http://publib.boulder.ibm.com/infocenter/satinfo/v3r2/topic/com.ibm.sat.doc/
concepts/cerwebap.htm. Die folgenden Schritte bieten eine Übersicht über die
grundlegenden Voraussetzungen, die zur vollständigen Ausführung des Assistenten nötig sind. Es wird vorausgesetzt, dass eine J2EE-Anwendung in diesem Projekt verwendet wird. Einige der unten beschriebenen Anzeigen können von den
Anzeigen abweichen, die Sie am Bildschirm sehen, da sie von dem Typ der Anwendung und den Spezifikationen der jeweiligen Konfiguration abhängen.
1. Wählen Sie in Software Assembly Toolkit Developer die Optionen File → New
→ WebSphere Deployment Accelerator Project aus. Der Assistent für das Projekt 'WebSphere Deployment Accelerator' wird geöffnet.
2. Geben Sie einen Projektnamen an und klicken Sie auf Next.
3. Wählen Sie in der Anzeige Locate Source Profile das Optionsfeld Remote directory aus und klicken Sie auf Browse. Wenn das Dialogfenster Connect angezeigt wird, geben Sie den Host, den Benutzernamen und das Kennwort an,
die für das Herstellen einer Verbindung zu dem Server benötigt werden, auf
dem die Anwendung derzeit installiert ist. Klicken Sie auf Connect. Ein Dialogfenster für einen Dateibrowser wird angezeigt. Navigieren Sie zum Verzeichnis 'config' des WebSphere Application Server-Profils, das die Anwendung ausführt, und klicken Sie auf OK. Die Konfigurationsdaten für das
Profil werden anschließend analysiert. Nach Abschluss dieses Vorgangs können Sie auf Next klicken.
4. Wählen Sie die Anwendungen in der Liste aus, die Sie in dieses Projekt aufnehmen wollen. Klicken Sie auf Next.
5. Klicken Sie in der Anzeige Review Configuration Summary auf Next.
6. Wählen Sie in der Anzeige General Options Ihre Optionen aus und klicken
Sie anschließend auf Next.
112
7. In der nächsten Anzeige werden Sie zur Angabe der Sicherheitsrollenbenutzernamen für die Anwendung aufgefordert. Geben Sie die entsprechenden Werte
ein und klicken Sie auf Next.
8. In der nächsten Anzeige werden Sie zur Angabe der Position der JAR-Dateien
aufgefordert, die für “DB2 Universal JDBC Driver Provider (XA)” erforderlich
sind. Suchen Sie mit der Schaltfläche Add die Position der entsprechenden
JAR-Dateien und klicken Sie auf Next.
Anmerkung: Diese Anzeige steht Ihnen, je nachdem wie die JDBC-Provider
für Ihre Anwendung konfiguriert wurden, unter Umständen
nicht zur Verfügung.
9. In den übrigen Anzeigen werden Sie zur Angabe von Daten aufgefordert, die
für verschiedene für Ihre Anwendung konfigurierten Ressourcen spezifisch
sind. In der Regel werden die Standardwerte bereitgestellt, die aktuell für Ihre
Anwendung konfiguriert sind. Wenn Sie mindestens eine dieser Variablen zugänglich machen wollen, sodass sie während der Installation angegeben werden kann, wählen Sie das Markierungsfeld Enable modifying this value during deployment neben der in Frage kommenden Variablen aus. Die meisten
Variablen übernehmen die Standardwerte. Zu den Variablen, die Sie modifizieren wollen, könnten der Datenbankname und der Name des Warteschlangenmanagers gehören.
10. Wenn Sie die letzte Anzeige erreicht haben, klicken Sie auf Finish. Das Projekt
wird automatisch für Sie generiert.
Projekt 'WebSphere Deployment Accelerator' erweitern
Das Projekt 'WebSphere Deployment Accelerator', das Sie soeben erstellt haben,
kann direkt in einem WebSphere Remote Server-Lösungsprojekt verwendet werden, vor allem wenn Sie vorhaben, Ihre Lösung gleichzeitig zu installieren und zu
konfigurieren. Wenn Sie aber das zwei Phasen umfassende Data-Warehouse-Modell
der Installation und Konfiguration anwenden wollen, müssen Sie an diesem Projekt einige wichtige Änderungen vornehmen. Diese Änderungen müssen Sie auch
vornehmen, wenn Ihre Lösung die Anwendung in vorhandenen WebSphere Remote Server-Instanzen implementieren soll und die Middleware nicht in der Lösung
enthalten ist.
1. Navigieren Sie im Teilfenster Navigator von Software Assembly Toolkit Developer zum folgenden Unterverzeichnis: PlantsByWebSphereDeployment/src/
PlantsByWebSphereDeployment/userPrograms. Suchen Sie an dieser Position die
Datei WrsDeployWebApplications.java und kopieren Sie diese in das entsprechende Unterverzeichnis userPrograms des Arbeitsbereichs Ihres neuen Projekts.
2. Öffnen Sie in Software Assembly Toolkit Developer die Datei application.axml
für das neue Projekt. Wählen Sie über die Registerkarte Programs die Registerkarte Main Program aus. Ändern Sie den Wert von 'Program' in WrsDeployWebApplications. Entfernen Sie aus dem Listenfenster Arguments alle Argumente, indem Sie jedes Argument der Reihe nach auswählen und auf Remove klicken.
3. Speichern Sie die Änderungen in der Datei application.axml.
4. Die Klasse 'WrsDeployWebApplications' schließt die Standardklasse 'DeployWebApplications' mit ein und ermöglicht, dass bestimmte Variablenwerte mit den
aus der WebSphere Remote Server-Metadatendatei abgerufenen Werten überschrieben werden. (Hierbei handelt es sich um Variablenwerte und andere Systemmetadaten, die während der Erstinstallation von WebSphere Remote Server
erstellt wurden.)
113
Anmerkung: Diese Klasse muss die wichtigsten Variablen handhaben und darf
in den meisten Fällen keine Änderungen anfordern. Es ist jedoch
wichtig, dass Sie den Code überprüfen, damit Sie die Vorgänge
verstehen, sodass Sie bei Bedarf am Code Änderungen vornehmen können.
Lösung erstellen
Im Lösungsprojekt werden alle Anwendungsprojekte zu einer einzelnen Lösung
vereinigt. Eine vollständige WebSphere Remote Server-Lösung enthält alle Middlewareanwendungsprojekte. Die folgende Tabelle enthält die verschiedenen Anwendungsprojekte, die für jede Plattform aufgenommen werden können. Obwohl Sie
die Anwendungsprojekte in dieser Liste aus Ihrer Lösung entfernen können, ist die
Reihenfolge wichtig, in der sie aufgeführt sind.
Tabelle 9. WebSphere Remote Server-Anwendungsprojekte (für 32-Bit-Lösungen)
Linux-Projektname
Windows-Projektname
Kommentare
IrssBase_711_Lnx
IrssBase_711_Win
WebSphere Remote ServerBasiscode Erforderlich.
Db2_972_Lnx oder
Informix_1150_Lnx
Db2_972_Win oder
Informix_1150_Win
DB2 Workgroup Server Edition oder Informix Growth
Edition
Mq_701_Lnx
Mq_701_Win
WebSphere MQ
Mq_701Fp2_Lnx
Mq_701Fp2_Win
WebSphere MQ Fixpack
Was_7009_Lnx
Was_7009_Win
WasStandaloneProfileConfiguration
WebSphere Application Server-Profil
Ihs_70_Lnx
Ihs_70_Win
IBM HTTP Server
WasUpdateInstaller_70_Lnx
WasUpdateInstaller_70_Win
WebSphere Application Server Update Installer
Ihs_70Fp9_Lnx
Ihs_70Fp9_Win
IBM HTTP Server Fixpack
Smash_1115_Lnx
Smash_1115_Win
WebSphere sMash
'ConfigWrapperWithDb2'
WebSphere Remote Serveroder
oder
Anwendungskonfigura'ConfigWrapperWithInformix' 'ConfigWrapperWithInformix' tionsprogramm
Tabelle 10. WebSphere Remote Server-Anwendungsprojekte (für 64-Bit-Lösungen)
114
Linux-Projektname
Windows-Projektname
Kommentare
IrssBase_711_Lnx
IrssBase_711_Win
WebSphere Remote ServerBasiscode Erforderlich.
Db2_972_Lnx_x64 oder
Informix_1150_Lnx_x64
Db2_972_Win_x64 oder
Informix_1150_Win_x64
DB2 Workgroup Server Edition oder Informix Growth
Edition
Mq_701_Lnx_x64
Mq_701_Win_x64
WebSphere MQ
Mq_701Fp2_Lnx_x64
Mq_701Fp2_Win_x64
WebSphere MQ Fixpack
Was_7009_Lnx_x64
Was_7009_Win_x64
WebSphere Application Server-Profil
Tabelle 10. WebSphere Remote Server-Anwendungsprojekte (für 64-Bit-Lösungen) (Forts.)
Linux-Projektname
Windows-Projektname
Kommentare
Ihs_70_Lnx_x64
Ihs_70_Win_x64
IBM HTTP Server
WasUpdateInstaller_70_Lnx
_x64
WasUpdateInstaller_70_Win
_x64
WebSphere Application Server Update Installer
Ihs_70Fp9_Lnx_x64
Ihs_70Fp9_Win_x64
IBM HTTP Server Fixpack
Smash_1115_Lnx
Smash_1115_Win
WebSphere sMash
WebSphere Remote Serveroder
oder
Anwendungskonfigura'ConfigWrapperWithInformix' 'ConfigWrapperWithInformix' tionsprogramm
Alle Middlewareanwendungsprojekte sind vom technischen Standpunkt aus betrachtet optional. In der Praxis werden jedoch WebSphere Remote Server und DB2
wahrscheinlich benötigt, IBM WebSphere MQ und IBM HTTP Server dagegen
möglicherweise nicht. Dies ist von den Voraussetzungen für Ihre Anwendung abhängig.
Zusätzlich zu den oben aufgeführten Projekten müssen Sie das Projekt
'Db2Configuration' bzw. Ihre Kopie davon, das Projekt 'MqConfiguration' bzw. Ihre
Kopie davon und das Projekt 'WebSphere Deployment Accelerator', das Sie im Abschnitt „Projekt 'WebSphere Deployment Accelerator' erstellen und erweitern” auf
Seite 112 erstellt haben, hinzufügen.
Die folgenden Anweisungen zeigen die Schritte auf, die nötig sind, um ein Lösungsprojekt zu erstellen, das den Projekten 'PlantsByWebSphereForLinux' oder
'PlantsByWebSphereForWindows' ähnelt, aber Ihre eigenen Anwendungsprojekte
enthält.
1. Wählen Sie über das Menü File die Optionen New → Solution project aus.
Der Projektassistent New wird geöffnet.
2. Geben Sie in der ersten Anzeige den Projektnamen an. Wählen Sie einen aussagekräftigen Namen aus. Wenn Sie für beide von WebSphere Remote Server
unterstützten Betriebssystemplattformen (Linux und Windows) Lösungen entwickeln möchten, empfiehlt es sich, den Namen der Plattform im Projektnamen anzugeben. Klicken Sie auf Next.
3. Geben Sie in der nächsten Anzeige die Lösungs-ID und den Lösungstitel entsprechend an. Klicken Sie auf Finish. Das Lösungsprojekt wird erstellt. Sie
müssen zuerst Tasks erstellen, damit Sie einem Lösungsprojekt Anwendungsprojekte hinzufügen können. Für dieses Beispiel können Sie zwei Tasks erstellen: eine Task zum Installieren sämtlicher Middleware von WebSphere Remote
Server und eine weitere Task zum Implementieren und Konfigurieren Ihrer
Anwendung.
4. Wechseln Sie zur Registerkarte Tasks. Klicken Sie neben dem Listenfenster Solution Tasks auf Add. Wenn der Taskassistent Add angezeigt wird, wählen
Sie das Optionsfeld Create an empty install task aus und klicken Sie auf
Next.
5. Geben Sie einen Wert in das Feld Task Description ein und klicken Sie auf Finish.
6. Klicken Sie auf Add, um dieser Task Anwendungsprojekte hinzuzufügen.
Wenn der Assistent Add angezeigt wird, behalten Sie die Auswahl des Optionsfelds Add applications bei und klicken Sie auf Next.
115
7. Wählen Sie im Listenfenster Applications alle Anwendungsprojekte für die
Middlewarekomponenten aus. Die oben angeführten Tabellen enthalten die
Projekte, die Sie jeweils für Ihre Plattform auswählen können. Wenn Sie die
entsprechenden Projekte ausgewählt haben, klicken Sie auf Finish.
8. Ändern Sie die Reihenfolge der Anwendungen so, dass sie mit der Reihenfolge der Projekte übereinstimmt, die in der oben stehenden Tabelle 9 auf Seite
114 für 32-Bit-Lösungen bzw. Tabelle 10 auf Seite 114 für 64-Bit-Lösungen aufgeführt sind. Wählen Sie eine Anwendung in der Liste aus und verwenden
Sie die Schaltflächen Up und Down zum Ändern der Reihenfolge. Wiederholen Sie diesen Prozess, bis die Reihenfolge korrekt ist.
9. Erstellen Sie eine zweite Task für das Implementieren und Konfigurieren Ihrer
Anwendung, indem Sie die Schritte 4 und 5 wiederholen.
10. Klicken Sie auf Add, um dieser zweiten Task Anwendungsprojekte hinzuzufügen. Wenn der Assistent Add angezeigt wird, behalten Sie die Auswahl des
Optionsfelds Add applications bei und klicken Sie auf Next.
11. Wählen Sie im Listenfenster Applications nur die Anwendungsprojekte aus,
die Sie in den obigen Abschnitten erstellt haben. Wenn Sie die entsprechenden
Projekte ausgewählt haben, klicken Sie auf Finish.
12. Ändern Sie die Reihenfolge der Anwendungen so, dass das Projekt 'WebSphere Deployment Accelerator' am Ende der Liste aufgeführt wird. Sie ändern die Reihenfolge der Anwendungen auf dieselbe Weise, wie sie in Schritt
8 beschrieben wird.
13. Überschreiben Sie die Variablen. Verwenden Sie die oben dargestellte Tabelle 9
auf Seite 114 bzw. Tabelle 10 auf Seite 114 als Referenz beim Überschreiben der
Anwendungsvariablen. Die meisten Variablen sollten ausgeblendet sein. Einige
Variablen sollten gemeinsam genutzt werden. Wählen Sie zum Überschreiben
einer Anwendungsvariablen eine Anwendung im Listenfenster Solution Tasks
aus und klicken Sie anschließend auf Add rechts neben dem Listenfenster
Overridden application variables. Ein Assistent wird angezeigt. Wählen Sie
die Variablen in der Liste aus. Beim Durcharbeiten der übrigen Seiten des Assistenten können Sie angeben, wie jede Variable überschrieben werden soll (ob
sie ausgeblendet, gemeinsam genutzt usw. werden soll).
14. Erstellen und testen Sie die Lösung mithilfe der Schritte, die im Abschnitt
„Musterlösung 'PlantsByWebSphere' verwenden” auf Seite 109 beschrieben
werden.
WrsApplicationConfigurator verwenden
In den obigen Anweisungen wird beschrieben, wie Ihre WebSphere-Anwendung
als separate Task in einem einzelnen Lösungsprojekt implementiert und konfiguriert werden kann. Beide Tasks können gleichzeitig von Deployment Wizard oder
während separater Aufrufe von Deployment Wizard ausgeführt werden vorausgesetzt, dass das Solution Launcher-Image noch auf der Zielmaschine verfügbar ist.
Durch diese Art des Entwurfs kann dieses Lösungsprojekt auch im zwei Phasen
umfassenden Data-Warehouse-Modell für Installation und Konfiguration verwendet werden. Dieses zweiphasige Modell wird in der WebSphere Remote Server
V6.2-Veröffentlichung mit dem Titel Deploying WebSphere Remote Server erläutert,
die unter der folgenden Adresse zur Verfügung steht: http://www.ibm.com/
support/docview.wss?rs=2193&context=SSUNCX&dc=DA480&uid=swg27012849
&loc=en_US&cs=utf-8&lang=en.
116
Anmerkung: Die Anweisungen in der oben angeführten Veröffentlichung wurden
lediglich mit WebSphere Remote Server V6.2 getestet. Sie können die
darin enthaltenen Erläuterungen jedoch als allgemeine Informationen
nutzen.
In der Veröffentlichung WebSphere Remote Server V6.2 wird die Konfigurationsphase als separates sekundäres Lösungsprojekt 'WrsApplicationConfigurator' entworfen, das in das Anwendungsprojekt 'ConfigWrapper' integriert und anschließend in das primäre Lösungsprojekt aufgenommen wird. Das Anwendungsprojekt
'ConfigWrapper' verwendet die Ausgabe des Solution Launcher-Images aus der Lösung 'WrsApplicationConfigurator' als Eingabe zum Erstellen des Implementierungspakets.
Die in der Veröffentlichung WebSphere Remote Server V6.2 beschriebenen Methoden können auch mit dem Muster 'WrsApplicationConfigurator/ConfigWrapper'
verwendet werden. Die unten aufgeführten Anweisungen bieten einen kurzen
Überblick über die wichtigen Unterschiede:
1. Fügen Sie die Anwendungsprojekte, die Sie in den Abschnitten „Schablonenprojekte kopieren und anpassen” auf Seite 110 und „Projekt 'WebSphere Deployment Accelerator' erstellen und erweitern” auf Seite 112 erstellt haben, zu
dem Lösungsprojekt 'WrsApplicationConfigurator' hinzu.
2. Generieren Sie die Lösung und exportieren Sie das Solution Launcher-Image
für 'WrsApplicationConfigurator'.
3. Generieren Sie das Implementierungspaket für das Anwendungsprojekt 'ConfigWrapper'. Stellen Sie dabei sicher, dass das Quellenverzeichnis auf das Verzeichnis verweist, wohin im vorherigen Schritt das Solution Launcher-Image
exportiert wurde.
4. Nehmen Sie das Anwendungsprojekt 'ConfigWrapper' in Ihr WebSphere Remote Server-Lösungsprojekt auf.
Anwendung erstellen
Bei dieser Methode wird davon ausgegangen, dass Sie nicht über eine WebSphereAnwendung verfügen, für die ein WebSphere-Anwendungsimplementierungsprojekt als Wrapper verwendet werden kann. In diesem Fall wird angenommen, dass
Sie ein Anwendungsprojekt neu erstellen. Die Erstellung eines Anwendungsprojekts umfasst die Definition von Variablen, die Zuordnung von Variablen zu Eigenschaften in einer Antwortdatei und das Schreiben von Code, der zum Aufrufen des
Installationsprogramms für Ihre Anwendung erforderlich ist.
IBM Software Assembly Toolkit stellt eine vollständige API bereit, die Sie bei der
Entwicklung von Java-Code unterstützt, der zur Verwaltung der Installation benötigt wird. Der IBM WebSphere Remote Server-Arbeitsbereich erweitert diese API
zusätzlich mit Harness-Klassen, die den Arbeitsablauf vor und nach der Installation optimieren, sowie mit einer Reihe von Dienstprogrammklassen, die eine Vielzahl nützlicher Funktionen bereitstellen.
Harness-API
Die folgenden Klassen erweitern die SupportBase-Klassen der Software Assembly
Toolkit-API:
v com.ibm.wrs.solution.utils.SoftwareWindowsHarness
v com.ibm.wrs.solution.utils.SoftwareLinuxHarness
v com.ibm.wrs.solution.utils.SoftwareConfigHarness
117
Die Software-Harness-Klasse teilt den Installationsprozess in drei einfache Schritte
auf: preInstall, doInstall und postInstall. Die Methoden preInstall und postInstall
müssen außer Kraft gesetzt werden, damit die benötigte Funktion zur Verfügung
steht, bieten jedoch ein angemessenes Standardverhalten, falls keine speziellen
Tasks erforderlich sind. Die Methode doInstall führt den Installationsbefehl für Ihre
Anwendung aus. Die zeitaufwendigen Aufgaben des Interpretierens von Rückkehrcodes und der Nachrichtenübertragung werden durch die Basisklasse in der Installationsmethode durchgeführt. Normalerweise muss diese Methode nicht außer
Kraft gesetzt werden.
Die Klasse SoftwareConfigHarness stellt einen ähnlichen, aus drei Schritten bestehenden Prozess zur Verfügung: die Methoden preConfigure, doConfigure und
postConfigure. Wie bei der Software-Harness-Klasse müssen Sie lediglich den Code
für diese drei Schritte schreiben. Die Basisklasse übernimmt die Bearbeitung der
Rückkehrcodes etc.
Es ist nicht unbedingt erforderlich, diese Klassen zu verwenden. Sie können eine
Erweiterung auf der Basis der von SAT bereitgestellten Klassen SupportWindowsBase und SupportLinuxBase vornehmen. Durch die Harness-Klassen wird die
Entwicklung jedoch vereinfacht.
Darüber hinaus bieten die Harness-Klassen eine weitere wichtige Funktion: die im
Folgenden beschriebene Aktualisierung der WebSphere Remote Server-Metadatendatei.
WebSphere Remote Server-Metadatendatei
Die WebSphere Remote Server-Metadatendatei ist ein Repository für Systemkonfigurationsdaten. Genauer ausgedrückt handelt es sich um eine XML-Datei, die unter SIF_HOME/solution/WRSMetadata.xml gespeichert ist. In der Metadatendatei werden Konfigurationsdaten zu den einzelnen Middlewarekomponenten gespeichert,
wie beispielsweise die Installationsposition, Installationsparameterwerte sowie Methoden zum Starten, Stoppen und Überwachen der Komponente. Diese Daten werden zum Starten und Stoppen des gesamten Software-Stacks verwendet. .
Die Metadaten bestehen aus fünf zentralen XML-Elementen. Das Lösungselement
stellt die gesamte Lösung auf dem System dar. Standardmäßig ist ihm das Namensattribut 'WRS' zugeordnet. Die Anwendungselemente stellen einzelne Softwarekomponenten dar und weisen die entsprechenden Benennungen auf: 'WAS',
'DB2' etc. Diese Elemente sind stets untergeordnete Elemente eines Lösungselements. Die Unterkomponentenelemente stellen eine zentrale Entität innerhalb einer
Softwarekomponente dar, z. B. ein IBM WebSphere Application Server-Profil. Diese
Elemente sind stets untergeordnete Elemente von Anwendungselementen. Die Berechtigungsnachweiselemente stellen Benutzernamen und Kennwörter innerhalb
des Systems dar. Diese Elemente werden für das System als global betrachtet und
befinden sich auf derselben Ebene wie das Lösungselement. Alle anderen Elemente
in den Metadaten (mit Ausnahme des Stammelements) stellen Eigenschaften des
übergeordnetes Elements dar.
Die meisten der in der WebSphere Remote Server-Metadatendatei enthaltenen Daten stammen direkt von den im Anwendungsprojekt definierten Variablen. Einige
Informationen, wie zum Beispiel die Start-/Stoppbefehle oder die Deinstallationsbefehle, dürfen jedoch nicht bei den Benutzern der Anwendung abgefragt werden.
Diese zusätzlichen Informationen müssen über eine für diesen Zweck erstellte API
in die Metadaten aufgenommen werden; es gibt jedoch eine einfachere Methode,
für die keine Codeentwicklung erforderlich ist.
118
Die oben beschriebenen Software-Harness-Klassen stellen eine weitere wichtige
Funktion bereit. Nach der erfolgreichen Installation wird ein XML-Snippet in die
WebSphere Remote Server-Metadatendatei aufgenommen. Das XML-Snippet ist
eine Datei mit dem Namen metadata.xml, die sich im Anwendungsprojekt befindet. Die Datei metadata.xml entspricht in ihrer Form einer Untermenge der gesamten Metadatendatei mit denselben, oben beschriebenen Elementen. Wenn Sie eine
Datei metadata.xml in Ihr Projekt aufnehmen und Ihre Hauptklassen auf der Basis
einer der Software-Harness-Klassen erweitern, wird die Metadaten-Snippetdatei
zum Zeitpunkt der Installation in die WebSphere Remote Server-Metadatendatei
aufgenommen.
Beispiele für die Datei metadata.xml finden Sie in den Anwendungsprojekten im
Arbeitsbereich.
WebSphere Remote Server speichert codierte Kennwörter für einige der IBM Middlewareprodukte in der Datei SIF_HOME/solution/WRSMetadata.xml. Die Codierung
und Verschlüsselung von Kennwörtern verhindert die zufällige Einsicht von Kennwörtern; die Codierung ist jedoch nicht ausreichend, um Kennwörter vollständig
zu schützen. Die systemeigene Sicherheit ist der primäre Mechanismus zum Schützen der in WebSphere Application Server-Konfigurations- und Eigenschaftendateien verwendeten Kennwörter. Die folgenden Links bieten Unterstützung bei der
Festlegung von Dateiberechtigungen für das jeweilige Betriebssystem:
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
Implementierung über Remotezugriff mit Tivoli Provisioning Manager
vorbereiten
In diesem Abschnitt wird eine grundlegende Strategie für die ferne Installation von
IBM WebSphere Remote Server-Lösungen mithilfe von IBM Tivoli Provisioning
Manager beschrieben.
In den früheren Releases von WebSphere Remote Server wurden für jedes Middlewareprodukt einzelne Tivoli-Softwarepaketdefinitionsdateien (als SPD-Dateien bezeichnet) bereitgestellt. Neben den CD-Images der Middlewareprodukte und den
Installationsscripts mussten Sie Systems Management Accelerators mit den SPDDateien installieren. Dadurch ließ sich bei der Installation von IBM Middleware auf
fernen Maschinen jeweils ein Produkt pro Arbeitsgang installieren.
WebSphere Remote Server dagegen verwendet ein Verfahren, bei dem statt einzelner Produkte eine Lösung installiert wird. In WebSphere Remote Server werden keine einzelnen Paketdateien mehr für Middlewareprodukte bereitgestellt. Stattdessen
werden SPD-Musterdateien für vollständige Windows- und Linux-Lösungen bereitgestellt. Eine SPD kann zusammen mit einem CD- oder DVD-Image der Lösung
zum Erstellen eines Tivoli-Softwarepaketblocks (als SPB-Datei bezeichnet) verwen-
119
det werden. Die SPB-Datei kann in den Softwarekatalog auf dem Tivoli Provisioning Manager-Server importiert werden. Damit ist die Lösung zur Verteilung an
ferne ISPs bereit.
Die von WebSphere Remote Server bereitgestellten SPD-Dateien müssen gemeinsam mit Ihrer Lösung in SPB-Dateien erstellt werden. Die SPB-Dateien enthalten
sowohl die Paketdefinition als auch das Medienimage der Lösung. Zum Erstellen
der SPB-Dateien benötigen Sie den Tivoli-Softwarepaketeditor, eine Komponente
von Tivoli Provisioning Manager.
Beachten Sie, dass für jede Musterlösung drei SPD-Dateien bereitgestellt werden.
Der Grund hierfür ist die Größeneinschränkung der SPB-Dateien auf 2 GB. Zwei
der SPD-Dateien werden für die Installation der Medienimages auf dem ISP verwendet. Die dritte SPD-Datei verwendet die Medienimages für die Installation der
eigentlichen Lösung. Wenn Ihre Lösung kleiner als 2 GB ist, ist nur eine SPD-Datei
erforderlich; dadurch werden die Dateien kopiert und die Installation durchgeführt.
Für die Implementierung mit Tivoli Provisioning Manager müssen Sie die folgenden grundlegenden Schritte ausführen:
v Installieren Sie die WebSphere Remote Server-Lösungsentwicklungsumgebung.
v Installieren und konfigurieren Sie den Tivoli-Softwarepaketeditor (SPE).
v Erstellen Sie die Musterlösung oder eine eigene Lösung. Achten Sie darauf, die
Lösung im unbeaufsichtigten Modus zu exportieren. Siehe Abschnitt Musterlösung für unbeaufsichtigte Installation vorbereiten oben.
v Erstellen Sie eine SPB-Datei und kopieren Sie sie auf die Maschine mit Tivoli
Provisioning Manager.
v Importieren Sie sie in den Softwarekatalog.
v Stellen Sie sie auf dem Depotserver bereit.
v Verteilen Sie sie an den ISP.
v Installieren Sie sie auf dem ISP.
SPB-Dateien erstellen
Bevor Sie die SPD-Dateien erstellen, müssen Sie Medienimages Ihrer Lösung generieren. Optional können Sie die bereitgestellten SPD-Dateien verwenden, die zur
Installation der Musterlösung benutzt werden können. Siehe Abschnitt Musterlösung erstellen.
Darüber hinaus müssen Sie den Tivoli-Softwarepaketeditor installieren und für die
Kommunikation mit Ihrem Tivoli Provisioning Manager-Server konfigurieren. Lesen Sie vor dem Ausführen dieses Schritts die Informationen in Softwarepakete im
Softwarepaketeditor verwalten im IBM Tivoli Provisioning Manager Information
Center.
Bei der Installation von WebSphere Remote Server werden im Verzeichnis 'sifDir/
packages' SPD-Musterdateien installiert. Die SPD-Musterdateien enthalten Verweise
auf Verzeichnisse, in denen sich die Medienimages Ihres Lösungsprojekts befinden
müssen. Die Datei SampleSolutionForWindowsPart1.spd beispielsweise enthält Verweise auf die Verzeichnisse C:\export\SampleSolutionForWindows\disk1 und C:\
export\SampleSolutionForWindows\disk2. Diese Verzeichnisse werden nicht von
WebSphere Remote Server installiert. Sie werden erstellt, wenn Sie die Komponente
Software Assembly Toolkit Developer von IBM Software Assembly Toolkit zum Exportieren Ihrer Lösung auf einen Datenträger verwenden. Sie können die Verzeich-
120
nispositionen in den SPD-Dateien ändern. Sie müssen nur sicherstellen, dass die
Verzeichnispositionen in den SPD-Dateien mit den eigentlichen Positionen der Medienimages auf Ihrem Festplattenlaufwerk übereinstimmen.
Anmerkung: Derzeit gibt es eine Größeneinschränkung für SPB-Dateien. SPB-Dateien dürfen nicht größer als 2 GB sein. Da der Wert für die Musterlösung höher als 2 GB ist, muss die Lösung auf mehrere SPB-Dateien
verteilt werden. Für jede Musterlösung werden drei SPD-Dateien bereitgestellt.
Windows:
v SampleSolutionForWindows.spd
v SampleSolutionForWindowsCd1and2.spd
v SampleSolutionForWindowsCd3and4.spd
Linux:
v SampleSolutionForLinux.spd
v SampleSolutionForLinuxCd1and2.spd
v SampleSolutionForLinuxCd3and4.spd
Die SPB-Dateien können mit dem Softwarepaketeditor erstellt werden. Öffnen Sie
die SPD-Dateien im Softwarepaketeditor und speichern Sie sie anschließend mit
der Erweiterung .spb. Dabei generiert der Editor die SPB-Dateien. Wenn Sie den
Softwarepaketeditor so konfiguriert haben, wie im IBM Tivoli Provisioning Manager Information Center beschrieben, können Sie die SPB-Datei direkt in dem vom
Tivoli Provisioning Manager-Server verwendeten Dateirepository speichern. Andernfalls können Sie die SPB-Dateien im lokalen Dateisystem speichern und anschließend mit Tivoli Provisioning Manager in den Softwarekatalog importieren.
Softwarepaketeditor konfigurieren
Anmerkung: Informationen zur Konfiguration des Softwarepaketeditors finden Sie
in Softwarepaketeditor starten und konfigurieren im IBM Tivoli Provisioning Manager Information Center.
Führen Sie die folgenden Schritte aus, bevor Sie den Softwarepaketeditor über Java
Web Start starten:
v Starten Sie die Java Web Start-Anwendung mithilfe des IBM JRE-Plug-ins 1.5.
Das Fenster Java Web Start Application Manager wird aufgerufen. Starten Sie
Java Web Start auf UNIX-Systemen mit dem Befehl javaws.
v Geben Sie in das Feld Location die folgende URL-Adresse ein: https://
<hostname>:<portnummer>/SPEWebStart/spe.jnlp, wobei <hostname> der Hostname des Web-Servers und <portnummer> die Portnummer des Web-Servers ist. Die
Softwarepaketeditorkomponente wird automatisch heruntergeladen und angezeigt.
v Starten Sie die Softwarepaketeditorkomponente, indem Sie auf Start klicken.
WebSphere Remote Server- und ISP-Anwendungen steuern
Das IBM WebSphere Remote Server-Befehlsprozessordienstprogramm ist eine Klassendatei, die in der Datei SifUtility.jar enthalten ist. Diese Datei befindet sich
im Verzeichnis SIF_HOME/utility.
121
Der WebSphere Remote Server-Befehlsprozessor führt Befehle auf Betriebssystemebene aus, die in der WebSphere Remote Server-Metadatendatei definiert sind. Die
Befehle werden durch die Übergabe von Parametern an den WebSphere Remote
Server-Befehlsprozessor aufgerufen. Diese Parameter ermöglichen dem Prozessor,
die Befehle in der WebSphere Remote Server-Metadatendatei zu finden und den
entsprechenden Befehl auszuführen.
WebSphere Remote Server enthält vorgefertigte Scripts für das Steuern der Anwendungen, aus denen sich die WebSphere Remote Server-Lösung zusammensetzt.
Die Syntax für diese Scripts ist nachfolgend aufgeführt:
Dabei sind die folgenden Parameter optional:
v silent: Informationen zur Befehlsausführung werden nicht in der Anzeige ausgegeben.
v log: Informationen zur Befehlsausführung werden in der Protokolldatei ausgegeben.
v verbose: Ausführliche Informationen zur Debugbefehlsausführung werden im
angegebenen Ausgabetyp ausgegeben.
Die zuvor genannten Scripts können nur für die WebSphere Remote Server-Lösung
sowie für alle Anwendungen und Unterkomponenten ausgeführt werden, die in
der WebSphere Remote Server-Lösung enthalten sind. Sie können jedoch die Standardsteuerparameter für Anwendungen und Unterkomponenten ändern, die sich
in der WebSphere Remote Server-Metadatendatei befinden, oder Sie können neue,
in WebSphere Remote Server nicht enthaltene Lösungen, Anwendungen und Unterkomponenten hinzufügen. Für diesen Fall ist der WebSphere Remote ServerBefehlsprozessor so erweiterbar, dass diese Änderungen und zukünftigen Anwendungen gesteuert werden können. In dem folgenden Abschnitt wird gezeigt, wie
der WebSphere Remote Server-Befehlsprozessor für diese Szenarios verwendet werden kann.
Neue Anwendungen oder Unterkomponenten ändern bzw. diese
zur WebSphere Remote Server-Lösung hinzufügen
Die einfachste Methode, neue Anwendungen oder Unterkomponenten zu ändern
bzw. diese zur WebSphere Remote Server-Lösung hinzuzufügen, ist, mit den in der
WebSphere Remote Server-Lösung vorhandenen Scripts eine Ausgangsbasis zu erstellen.
Beispiel: Hinzufügen einer neuen Anwendung zur WebSphere Remote ServerLösung
Diese Anwendung verfügt über Start- und Stoppfunktionen.
122
1. Fügen Sie die Anwendungsinformationen zur Metadatendatei in der WebSphere Remote Server-Lösung hinzu. In diesem Beispiel wird die Anwendung
TestApplication mit Start- und Stoppinformationen hinzugefügt:
<solution name="WRS">
<application name="TestApplication">
<start>wrs_TestApplication_start.bat </start>
<stop>wrs_TestApplication_stop.bat </stop>
</application>
<solution>
2. Handelt es sich bei den gewünschten Befehlen um Scriptaufrufe, erstellen Sie
die nötigen Scripts. In diesem Beispiel sind die Befehle Aufrufe für die Scripts
wrs_TestApplication_start.bat und wrs_TestApplication_stop.bat. Die Datei
wrs_DB2_start.bat (diese Datei wird bei der Installation von DB2 installiert)
wird als Schablone verwendet; die hieraus resultierende Datei
wrs_TestApplication_start.bat ist unten dargestellt:
@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
)
set rc=%FAILURE%
goto end
)
:end
type %TEMPLOG%
del /s /q %TEMPLOG%
exit /b %rc%
Dieses Beispielscript stellt die folgende Verarbeitung dar:
v Initialisieren benötigter lokaler Variablen.
v Aufrufen der Datei SifSetupCmdLine.bat oder SifSetupCmdLine.sh. Das
Script 'SifSetupCmdLine' muss immer aufgerufen werden, sodass die im
Script benötigten Umgebungsvariablen initialisiert werden, wie z. B. der Befehl für das Aufrufen von Java oder das Festlegen des Java-Klassenpfads.
v Aufrufen des Befehls für die Anwendung. In diesem Beispiel lautet der Befehl: TestApplication.exe start
v Bewerten der Ausgabe des Befehlsaufrufs. In diesem Beispiel ist der Rückkehrcode auf %SUCCESS% gesetzt, falls TestApplication ordnungsgemäß gestartet wurde. Wenn allerdings in diesem Beispiel das Starten von TestApplication nicht die Rückgabe 0 ergibt, kann die Anwendung bereits aktiv sein
und der hieraus resultierende Text, der in der Anzeige angezeigt wird, enthält die Wörter Already started (Bereits gestartet). Der Inhalt des Ausgabefensters wird in die benannte Protokolldatei geschrieben, die sich in
123
%TEMPLOG% befindet. Diese Datei kann wie oben gezeigt mithilfe von com.ibm.sif.utility.FindString nach dem Text Already started durchsucht werden. Wird der gesuchte Text gefunden, wird der Rückkehrcode der Anwendung auf %SUCCESS% gesetzt, andernfalls wird der Rückkehrcode auf
%FAILURE% gesetzt.
v Anzeigen der Ausgabe des Befehlsaufrufs.
v Löschen der temporären Datei, in der die Befehlsausgabe enthalten ist.
v Zurückgeben des Rückkehrcodes des Befehlsaufrufs.
3. Rufen Sie den WebSphere Remote Server-Befehlsprozessor auf, um die Anwendung 'TestApplication' zu starten; verwenden Sie hierzu bei Bedarf optionale
Parameter: wrsstart TestApplication [-silent -log -verbose].
Neue Anwendungen oder Unterkomponenten zu anderen Lösungen als der WebSphere Remote Server-Lösung hinzufügen
Die einfachste Methode, neue Anwendungen oder Unterkomponenten zu anderen
Lösungen als der WebSphere Remote Server-Lösung hinzuzufügen, ist, mit den in
der WebSphere Remote Server-Lösung vorhandenen Scripts eine Ausgangsbasis zu
erstellen.
Beispiel: Hinzufügen einer neuen Anwendung zu einer neuen Lösung
Diese Anwendung verfügt über Start- und Stoppfunktionen.
1. Fügen Sie die Lösung zur WebSphere Remote Server-Metadatendatei hinzu. Die
neuen Lösungstags werden auf derselben Ebene hinzugefügt wie die Lösung
WRS. In diesem Beispiel wird die Lösung NewSolution hinzugefügt.
.... Tags für die WRS-Lösung sind hier
</solution>
<solution name="NewSolution">
</solution>
2. Fügen Sie die Anwendungsinformationen zur WebSphere Remote Server-Metadatendatei unter der Lösung 'NewSolution' hinzu. In diesem Beispiel wird die
Anwendung NewApplication mit Start- und Stoppinformationen hinzugefügt:
.... Tags für die WRS-Lösung sind hier
</solution>
<solution name="NewSolution">
<application name="TestApplication">
<start>wrs_NewApplication_start.bat </start>
<stop>wrs_NewApplication_stop.bat </stop>
</application>
</solution>
3. Handelt es sich bei den gewünschten Befehlen um Scriptaufrufe, erstellen Sie
die nötigen Scripts. In diesem Beispiel sind die Befehle Aufrufe für die Scripts
wrs_NewApplication_start.bat und wrs_NewApplication_stop.bat. Die Datei
wrs_DB2_start.bat (diese Datei wurde bei der Installation von DB2 installiert)
wird als Schablone verwendet; die hieraus resultierende Datei
wrs_NewApplication_start.bat ist unten dargestellt:
@echo off
set SUCCESS=0
set FAILURE=1
set UNKNOWN=2
set BINDIR"%SIF_HOME%\bin
set rc=%UNKNOWN%
@call "%BINDIR%\NewApplication.exe start"
124
> %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 Initialisieren benötigter lokaler Variablen.
v Aufrufen der Datei SifSetupCmdLine.bat oder SifSetupCmdLine.sh. Das Script
'SifSetupCmdLine' muss immer aufgerufen werden, sodass die im Script benötigten Umgebungsvariablen initialisiert werden, wie z. B. der Befehl für das Aufrufen von Java oder das Festlegen des Java-Klassenpfads.
v Aufrufen des Befehls für die Anwendung. In diesem Beispiel lautet der Befehl:
NewApplication.exe start
v Bewerten der Ausgabe des Befehlsaufrufs. In diesem Beispiel ist der Rückkehrcode auf %SUCCESS% gesetzt, falls NewApplication ordnungsgemäß gestartet
wurde. Wenn allerdings in diesem Beispiel das Starten von NewApplication
nicht die Rückgabe 0 ergibt, kann die Anwendung bereits aktiv sein und der hieraus resultierende Text, der in der Anzeige angezeigt wird, enthält die Wörter
Already started (Bereits gestartet). Der Inhalt des Ausgabefensters wird in die
benannte Protokolldatei geschrieben, die sich in %TEMPLOG% befindet. Diese
Datei kann wie oben gezeigt mithilfe von com.ibm.sif.utility.FindString nach dem
Text Already started durchsucht werden. Wird der gesuchte Text gefunden,
wird der Rückkehrcode der Anwendung auf %SUCCESS% gesetzt, andernfalls
wird der Rückkehrcode auf %FAILURE% gesetzt.
v Anzeigen der Ausgabe des Befehlsaufrufs.
v Löschen der temporären Datei, in der die Befehlsausgabe enthalten ist.
v Zurückgeben des Rückkehrcodes des Befehlsaufrufs.
v Rufen Sie den WebSphere Remote Server-Befehlsprozessor auf, um die Anwendung 'TestApplication' zu starten; verwenden Sie hierzu bei Bedarf optionale Parameter:
Die einfachste Methode, den WebSphere Remote Server-Befehlsprozessor für eine
neue Lösung aufzurufen, ist, neue Scriptdateien mithilfe der Scriptdateien zu erstellen, die für die WebSphere Remote Server-Lösung als Ausgangsbasis bereitgestellt werden. Das Script wrsstart.bat wird als Beispiel dafür verwendet, wie
das Startscript für eine neue Lösung erstellt wird:
@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
125
: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. Aufrufen des Scripts SifSetupCmdLine.bat oder SifSetupCmdLine.sh. Das
Script 'SifSetupCmdLine' muss immer aufgerufen werden, sodass die im
Script benötigten Umgebungsvariablen initialisiert werden, wie z. B. der Befehl für das Aufrufen von Java oder das Festlegen des Java-Klassenpfads.
2. Aufrufen des WebSphere Remote Server-Befehlsprozessors auf der Basis der
Eingabeparameter. Wenn keine Eingabeparameter vorhanden sind, gehen Sie
davon aus, dass der Stack 'NewSolution' gestartet werden soll. Wenn Eingabeparameter vorhanden sind, starten Sie die Anwendung/Unterkomponente,
die sich auf der von den Eingabeparametern angegebenen Ebene befindet.
Es sind zwei wichtige Punkte zu beachten, wenn Sie den WebSphere Remote
Server-Befehlsprozessor aufrufen:
– Der Name des Tags für den Befehlstyp, der in der WebSphere Remote Server-Metadatendatei vorhanden ist, muss als Parameter nach dem Parameter 'WRSCommandProcessor.class' aufgeführt werden. In diesem Beispiel
hat der Tag den Namen start.
– Der Name der Lösung ist der nächste Parameter, der auf den Tag für den
Befehlstyp folgt. In diesem Beispiel hat die Lösung den Namen NewSolution.
Kennwortmanagement für das Verwalten von Benutzeranwendungen
erweitern
Die im Produktpaket von IBM WebSphere Remote Server enthaltenen Anwendungen verfügen unter Umständen über Berechtigungsnachweise. WebSphere Remote
Server kann für die Verwendung der WebSphere Remote Server-Dienstprogramme
für das Kennwortmanagement erweitert werden.
Wenn die neue Benutzeranwendung Berechtigungsnachweise verwendet, muss der
Tag <credential> in der WebSphere Remote Server-Metadatendatei unter dem Tag
<root> und dem Tag <changePasswordCmd> unter dem Tag <application> hinzugefügt werden. Dieses Hinzufügen von Tags muss während der Erstellung des
Tags <application> erfolgen. Das Kennwortmanagement kann nur durchgeführt
werden, wenn Berechtigungsnachweise mit der Anwendung verknüpft werden.
Bei IBM WebSphere Application Server können Sie z. B. die Sicherheit aktivieren.
Wenn Sie die Sicherheit aktivieren wollen, müssen Sie die Berechtigungsnachweise
definieren. Diese Berechtigungsnachweise müssen anschließend der WebSphere Remote Server-Metadatendatei hinzugefügt werden. Unten sind Beispieltags für einen
Berechtigungsnachweis aufgeführt:
<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>
Der Tag <changePassword> verweist auf den Tag <changePasswordCmd> unter
dem Tag <application>. Der Tag <changePasswordCmd> im Tag <application>
sieht folgendermaßen aus:
126
<root>
<application name="WAS">
...............
<subcomponent name="WRSProfile">
...............
<enableAdminSecurity>true</enableAdminSecurity>
<changePasswordCmd>wrs_WAS_changePwd server1</changePasswordCmd>
Hier stellt der Tag <changePasswordCmd> den Verweis auf die .bat/.sh-Datei zur
Verfügung, die ausgeführt werden soll. Das Kennwortmanagement fügt die Parameter während der Ausführung hinzu, bevor die .bat/.sh-Datei ausgeführt wird.
Die WebSphere Remote Server-Metadatendatei zeigt nicht alle Argumente an, die
an die .bat/.sh-Datei übergeben werden.
Ihre Anwendung muss zum Ändern des Benutzerkennworts über Funktionsaufrufe
verfügen. Sie müssen das .bat/.sh-Wrapperprogramm entwickeln, mit dem das Benutzerkennwort geändert wird. Dieses Wrapperscriptprogramm muss bestimmte
Standards einhalten, wie im nächsten Absatz erläutert wird.
Der Befehl zum Ändern des Kennworts für eine WebSphere Application ServerAnwendung sieht z. B. folgendermaßen aus: _WAS_changePwd {arg1} {arg2}
{arg3} {arg4} {arg5}. Dabei steht arg1 für den Servernamen, arg2 für den Benutzernamen, arg3 für das alte Kennwort, arg4 für das neue Kennwort und arg5 für
den Befehlstyp.
Benutzername, altes Kennwort, neues Kennwort und Befehlstyp sind für jede Anwendung obligatorisch. Die übrigen Argumente werden ausgehend von den Anwendungen geändert. Die Reihenfolge der Argumente hängt ebenfalls von der Anwendung ab.
Hier wird der Parameter für den Befehlstyp verwendet, um zu beschrieben, ob sich
der auszuführende Befehl im normalen Modus oder im Rollbackmodus befindet.
Ein Rollback wird implementiert, indem der Befehl 'changePassword' mit dem neuen Kennwort, das auf das alte Kennwort gesetzt ist, aufgerufen wird.
Die .bat-Musterdatei sieht ungefähr folgendermaßen aus:
@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%(
...................
...................
)
127
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%
Das Kennwortmanagement wird von IBM Tivoli Provisioning Manager ausgelöst,
indem eine Instanz der Klasse WRSCommandProcessor erstellt wird. Tivoli Provisioning Manager löst die Anwendung für die Kennwortänderung oder die Scananwendung durch die Übergabe der folgenden Argumente aus:
Zum Auslösen der Scananwendung:
v Scannen - {arg1}
v Berechtigungsnachweis - {arg2}
v Dateiname - {arg3}
Zum Auslösen der Anwendung für die Kennwortänderung:
v Ändern - {arg1}
v Berechtigungsnachweis - {arg2}
v Dateiname - {arg3}
Scananwendung
Die Scananwendung liest alle Benutzer aus der WebSphere Remote Server-Metadatendatei und generiert eine Ausgabedatei. Die Ausgabedatei enthält den Benutzernamen und sein Ablaufdatum, das vom Betriebssystem abgerufen wird. Wenn der
Benutzer, der aus der WebSphere Remote Server-Metadatendatei gescannt wird,
nicht im Betriebssystem vorhanden ist, fügt die Scananwendung eine entsprechende Nachricht anstelle des Ablaufdatums hinzu.
Es ist nicht obligatorisch, dass die Benutzeranwendung ihre Funktionen für das
Scannen zugänglich macht. Zugunsten eines besseren Kennwortmanagements wird
allerdings empfohlen, dass Benutzeranwendungen eine Art Richtlinie für den Ablauf der Kennwortgültigkeit anwenden und das zum Lieferumfang von WebSphere
Remote Server gehörende Kennwortmanagementdienstprogramm in vollem Umfang nutzen, um die Anwendungskennwörter zu verwalten.
Anmerkung: Tivoli Provisioning Manager-Workflows, die zum Auslösen des
Kennwortmanagements verwendet werden, benötigen keine besondere Konfiguration bzw. keine besonderen Änderungen, um die Benutzer von Benutzeranwendungen zu verwalten.
128
Kapitel 6. Fehlerbehebung und Unterstützung
Dieser Abschnitt enthält Informationen zu Fehlerbehebungstools, Unterstützung sowie Problemen mit der Installation.
IBM Support Assistant installieren und verwenden
IBM Support Assistant (ISA) ermöglicht es Ihnen, die Produktdokumentation zu
durchsuchen, Produktmanagementberichte (PMRs) zu erstellen und Protokolldateien zu paketieren.
ISA ist eine eigenständige Anwendung, die Sie auf jeder Workstation installieren
und anschließend erweitern können, indem Sie Plug-in-Module für die von Ihnen
verwendeten IBM Produkte installieren. Weitere Informationen zu ISA und den bereitgestellten Funktionen finden Sie auf der ISA-Unterstützungsseite. WebSphere
Remote Server unterstützt Version 4.0.2 oder höher von ISA.
Sie finden eine Liste der für ISA unterstützten Plattformen unter folgender Adresse: http://www.ibm.com/support/docview.wss?rs=3455&uid=swg27012685.
Anmerkung: Wenn ISA nicht auf dem Unternehmensserver installiert wird, der
zum Verwalten der IBM WebSphere Remote Server-Filialrechner
(ISPs) verwendet wird, müssen die Protokollerfassungsscripts, die
von ISPs gesammelt werden, manuell auf die ISA-Maschine verschoben werden.
Die folgenden Schritte zeigen, wie ISA installiert und ausgeführt wird.
Vorgehensweise
1. Installieren Sie ISA.
2. Verwenden Sie die integrierte ISA-Aktualisierungskomponente, um das WebSphere Remote Server-Plug-in zu installieren. Alternativ können Sie das WebSphere Remote Server-Plug-in und alle zusätzlichen Produkt-Plug-ins aus der
Liste der unterstützten ISA-Plug-ins herunterladen und installieren.
a. Öffnen Sie ISA und navigieren Sie zu Update → Find new → Product Addons.
b. Erweitern Sie den WebSphere-Produktordner und wählen Sie WebSphere
Remote Server V7.1.1 aus.
Klicken Sie erneut auf Next.
Akzeptieren Sie die Lizenzvereinbarung (License Agreement).
Zeigen Sie die Zusammenfassung an und klicken Sie auf Finish, um die Installation zu starten.
h. Wenn das Ergebnisfenster angezeigt wird, klicken Sie auf Finish.
i. Starten Sie ISA erneut, wenn Sie dazu aufgefordert werden.
3. Bereiten Sie den Einsatz der ISA-Funktionalität zum Analysieren von Problemen für WebSphere Remote Server vor.
c.
d.
e.
f.
g.
129
a. Vor der Ausführung der Datenerfassung und PMR-Übergabe im ISA-Framework müssen Sie sicherstellen, dass das Log Collector-Tool auf dem Filialrechner vorhanden ist. Dies ist erforderlich, da das ISA-Plug-in Dateien erfasst, indem es automatisch das Log Collector-Tool aufruft. Weitere
Informationen finden Sie im Abschnitt „Log Collector”.
b. Navigieren Sie zu Analyze Problem → Collect Data und klicken Sie auf Select Collectors.
c. Erweitern Sie die Produktbaumstruktur und suchen Sie nach WebSphere
Remote Server 7.1.1.
d. Fügen Sie den General Collector unter WebSphere Remote Server 7.1.1 der
Collector Queue hinzu und klicken Sie auf Collect All, um mit der Erfassung von WebSphere Remote Server-Protokollen zu beginnen.
Während der Erfassung erfragt der Datenkollektor den Namen der Ausgabedatei der Erfassung und die Position des WebSphere Remote Server-Ausgangsverzeichnisses. Wenn die Erfassung abgeschlossen ist, fragt der Datenkollektor, ob Sie die Protokolle per FTP-Verbindung an die IBM
Unterstützungsfunktion senden wollen.
4. Ausführliche Anweisungen zur Verwendung von ISA erhalten Sie über die
Links auf der ISA-Unterstützungsseite.
Log Collector
Das Tool 'Log Collector' erleichtert das Abrufen von Protokolldateien von den Filialrechnern (ISPs) auf den Unternehmensserver.
Protokolldateien archivieren
Nach der Installation der WebSphere Remote Server-Lösung auf dem ISP befindet
sich dort ein Script, mit dem Sie Protokolldateien in einer JAR-Datei
Hostname_Logs_zeitmarke.jar archivieren können, und zwar im folgenden Pfad:
SIF_HOME\bin\archivelogs.bat
SIF_HOME/bin/archivelogs_linux.sh
Wenn Sie das Log Collector-Tool ausführen, werden die Protokolldateien im folgenden Verzeichnis erfasst:
SIF_HOME\logs\collectedlogs\logs
SIF_HOME/logs/collectedlogs/logs
Wenn WebSphere Application Server installiert ist, erfasst das Log Collector-Tool
diese Dateien in einer JAR-Datei, die sich in folgendem Verzeichnis befindet:
SIF_HOME\logs\collectedlogs\archivelogs
SIF_HOME/logs/collectedlogs/archivelogs
Anmerkung: Wenn Sie die vorhandenen Protokolldateien aufbewahren wollen,
müssen Sie sie vor Ausführen des Log Collector-Tools sichern.
Workflow von Log Collector verwenden
Bevor Sie den Workflow von Log Collector verwenden können, müssen Sie ihn zu
Ihrem IBM Tivoli Provisioning Manager-Server hinzufügen.
130
Anmerkung: Wenn Sie Protokolldateien zur Verwendung mit IBM Support Assistant erfassen, ISA jedoch auf einer anderen Maschine in Ihrem Unternehmen installiert ist, können Sie die Protokolldateien gegebenenfalls
direkt vom ISP auf die ISA-Maschine abrufen. Tivoli Common Agent
muss auf der ISA-Maschine installiert sein, dann können für Destination_Hostname und DestinationPath die Werte festgelegt werden, die
denen auf der ISA-Maschine entsprechen.
Vorgehensweise
1. Melden Sie sich bei https://hostname:9443/maximo/ui/login an.
2. Klicken Sie auf Go To → Administration → Provisioning → Provisioning Workflows.
3. Klicken Sie im Erstellungsprogramm für Bereitstellungsworkflows (Provisioning
.
Workflow Composer) auf
4. Klicken Sie auf Select Action → Open Workflow und wählen Sie dann
ServerSifDir/bin/WRS_logCollection.wkf aus.
5. Klicken Sie auf OK.
6. Klicken Sie auf Compile Workflow. Sobald der Workflow erfolgreich kompiliert wurde, können Sie ihn ausführen, um Protokolldateien von jedem fernen
ISP zu erfassen.
7. Klicken Sie auf Run Workflow.
8. Geben Sie die erforderlichen Informationen in den Pflichtfeldern im Fenster 'Input Parameter for Workflow - WRS_logCollection' ein:
v Source_Full_Hostname: Geben Sie den ISP-Hostnamen ein. Der Hostname
im Tivoli Provisioning Manager-Datenmodell kann der kurze oder der vollständig qualifizierte Hostname sein. Um den für den Hostnamen zu verwendenden Wert zu prüfen, geben Sie den Hostnamen in das Feld FIND im
Fenster TPM ein.
v Source_WRS_Home_Directory: Geben Sie das Verzeichnis SIF_HOME auf
dem ISP ein.
v Destination_Hostname: Geben Sie den Hostnamen des Tivoli Provisioning
Manager-Servers ein. Um den für den Hostnamen zu verwendenden Wert zu
prüfen, geben Sie den Hostnamen in das Feld FIND im Fenster TPM ein.
v DestinationPath: Geben Sie das Zielverzeichnis auf dem Tivoli Provisioning
Manager-Server ein. Der Benutzer tioappadmin (oder jeder andere Benutzer,
über den der Workflow ausgeführt wird) muss die Berechtigung haben, die
Datei im Zielpfad zu speichern.
9. Klicken Sie auf Run.
Tipps zur Fehlerbehebung
In diesem Abschnitt werden einige potenzielle Fehler und die möglichen Lösungen
aufgeführt.
v „Das Launchpad wird nicht ordnungsgemäß geladen und zeigt den Fehler nicht
definiert an” auf Seite 132
v „Deinstallation schlägt fehl” auf Seite 132
v „Deinstallation von WebSphere MQ schlägt fehl” auf Seite 133
v „Nach einer erfolgreichen Deinstallation sind weiterhin Dateien vorhanden” auf
Seite 133
131
v „WebSphere Remote Server-Deinstallationsprogramm erkennt bestimmte Produkte nicht ” auf Seite 133
v „DB2-Installation schlägt fehl, wenn das Kennwort nicht mit dem vorherigen
Kennwort übereinstimmt” auf Seite 134
v „DB2-Installation schlägt unter Linux fehl” auf Seite 134
v „IBM HTTP Server zeigt einen Fehler bezüglich des vollständig qualifizierten
Domänennamens an” auf Seite 134
v „WebSphere Application Server-Ausnahmebedingung für Datenquelle” auf Seite
134
v „WebSphere Application Server-Ausnahmebedingung nach Installation” auf Seite
135
v „WebSphere Application Server-Ausnahmebedingung zur Handelsanwendung”
auf Seite 135
v „WebSphere Application Server-Ausnahmebedingung zur Migration der Anwendung 'Trade'” auf Seite 135
v „Ausnahmebedingung SRVE0255E” auf Seite 136
v „Software Assembly Toolkit-Ausnahmebedingung nach Installation” auf Seite
136
v „Informix Growth Edition erneut installieren” auf Seite 136
v „Linux-Server mit aktivierter WebSphere Application Server-Sicherheit erneut
starten” auf Seite 136
v „Software Assembly Toolkit Developer kann unter SUSE Linux Enterprise Server
10.3 (64-Bit) nicht geöffnet werden.” auf Seite 136
v „WebSphere Remote Server Data Provider-Ausnahmebedingung” auf Seite 137
v „Fehlende Symbolgrafiken in den Dateibrowserfenstern für die Installationsverzeichnisfelder im Implementierungsassistenten unter Windows 7” auf Seite 137
Das Launchpad wird nicht ordnungsgemäß geladen und zeigt
den Fehler nicht definiert an
Das Launchpad kann nicht von einem fernen Laufwerk aus ausgeführt werden.
Gehen Sie wie folgt vor, um das Launchpad ordnungsgemäß auszuführen:
1. Kopieren Sie die IBM WebSphere Remote Server-Lösung in ein lokales Laufwerk und führen Sie das Launchpad aus.
2. Ordnen Sie das Netzlaufwerk einem lokalen Laufwerk zu und führen Sie das
Launchpad aus.
Deinstallation schlägt fehl
Die komplette WebSphere Remote Server-Lösung muss gestoppt werden, bevor das
Deinstallationsprogramm ausgeführt wird. Der Deinstallationsprozess ruft das
Script 'wrsstop' auf; es kann aber sein, dass noch einige Komponenten der Lösung
aktiv sind (wie z. B. die WebSphere MQ-Warteschlangenmanager). Stoppen Sie alle
Komponenten von WebSphere Remote Server, bevor Sie die Deinstallation ausführen.
Wenn die Deinstallation eines Teils von WebSphere Remote Server nicht erfolgreich
ist, wird die WebSphere Remote Server-Basiskomponente nicht deinstalliert. Wenn
Sie das bei der Deinstallation aufgetretene Problem manuell korrigieren, reparieren
Sie Ihre WebSphere Remote Server-Metadatendatei (siehe unten) und führen Sie die
Deinstallation erneut aus.
132
WebSphere Remote Server-Metadatendatei reparieren: Die WebSphere Remote
Server-Metadatendatei verwaltet die Informationen zur WebSphere Remote ServerLösung. Tritt während des Deinstallationsprozesses ein Fehler auf, ist die WebSphere Remote Server-Metadatendatei möglicherweise nicht mehr auf dem aktuellsten Stand. In diesem Fall müssen Sie die WebSphere Remote ServerMetadatendatei aktualisieren, nachdem Sie das Deinstallationsproblem behoben haben. Die Datei befindet sich in 'SIF_HOME/solution/WRSMetadata.xml'. Zum Aktualisieren der Datei entfernen Sie die Abschnitte, die sich auf die deinstallierten
Produkte beziehen. Wenn Sie z. B. WebSphere MQ manuell entfernt haben, entfernen Sie den Abschnitt <application name="MQ"...</application>.
Deinstallation von WebSphere MQ schlägt fehl
Wenn die Installationsposition von WebSphere MQ bei der Migration von WebSphere Remote Server Version 6.1 auf Version 7.1.1 geändert wird, kann dies dazu
führen, dass die Deinstallation von WebSphere Remote Server nicht erfolgreich
durchgeführt werden kann. Die folgende Ausnahmebedingung wird in der Befehlszeile angezeigt, wenn das Deinstallationsprogramm versucht, WebSphere MQ zu
deinstallieren:
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
Um dieses Problem zu verhindern, ändern Sie die Installationsposition von WebSphere MQ bei der Migration von WebSphere Remote Server 6.1 auf Version 7.1.1
nicht. Falls Sie die Installationsposition während der Migration geändert haben,
können Sie die im Abschnitt „Deinstallation schlägt fehl” auf Seite 132 beschriebenen Schritte ausführen, um WebSphere Remote Server erfolgreich zu deinstallieren.
Nach einer erfolgreichen Deinstallation sind weiterhin Dateien
vorhanden
Tritt während des Deinstallationsprozesses ein Fehler auf, führt die Anwendung
mit dem Fehler nicht die Schritte für eine vollständige Deinstallation aus. Sie müssen diese Schritte manuell ausführen. Die erforderlichen Schritte sind im Abschnitt
Die Option 'clean' verwenden des Themas „Deinstallation” auf Seite 51 aufgeführt.
WebSphere Remote Server-Deinstallationsprogramm erkennt bestimmte Produkte nicht
Wenn das WebSphere Remote Server-Deinstallationsprogramm bestimmte Produkte
nicht erkennt, können Sie diese manuell mit den folgenden Befehlen deinstallieren:
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
Wenn das WebSphere Remote Server-Deinstallationsprogramm bestimmte Produkte
auf einer Windows-Plattform nicht findet, können Sie die Produkte auch über das
Fenster zum Hinzufügen oder Entfernen von Produkten deinstallieren.
DB2-Installation schlägt fehl, wenn das Kennwort nicht mit dem
vorherigen Kennwort übereinstimmt
Wenn DB2 bereits auf dem ISP installiert war, sind die DB2-Benutzer-IDs möglicherweise noch vorhanden. Die Installation kann nicht ausgeführt werden, wenn
das von Ihnen angegebene Kennwort nicht mit dem Kennwort für die vorhandenen DB2-Benutzer-IDs übereinstimmt.
Zur Behebung dieses Problems stehen zwei Möglichkeiten zur Verfügung:
v Löschen Sie die DB2-Benutzer-IDs (Windows: db2admin, Linux: db2inst1, dasusr1, db2fenc1) und installieren Sie DB2. Ändern Sie alle Kennwortwerte in der
Datei für unbeaufsichtigte Tasks.
v Löschen Sie die DB2-Benutzer-IDs nicht. Installieren Sie DB2 und geben Sie das
Kennwort für die vorhandenen DB2-Benutzer-IDs an.
DB2-Installation schlägt unter Linux fehl
Bei der Migration von WebSphere Remote Server Version 6.2 oder 6.2.1 auf Version
7.1.1 auf einem Linux-Betriebssystem muss ein neuer Installationspfad für DB2 angegeben werden. Wenn der bereits vorhandene DB2-Installationspfad verwendet
wird, tritt der folgende Fehler auf:
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 zeigt einen Fehler bezüglich des vollständig
qualifizierten Domänennamens an
IBM HTTP Server erwartet einen vollständig qualifizierten Domänennamen und
gibt möglicherweise einen Fehler ähnlich dem folgenden zurück:
httpd: Could not determine the server’s fully qualified domain name, using
9.42.121.61 for ServerName (httpd: Der vollständig qualifizierte Domänenname
konnte unter Verwendung von 9.42.121.61 für ServerName nicht festgestellt werden)
Die Problemlösung hierfür besteht darin, die Datei 'hosts' des Computers mit dem
vollständig qualifizierten Domänennamen zu aktualisieren. Die Datei befindet sich
im Verzeichnis /etc/hosts unter Linux bzw. im Verzeichnis %SYSTEMROOT%\
System32\drivers\etc\hosts unter Windows. Beispiel: 9.42.121.61
wrslinisp2.rtp.raleigh.ibm.com wrslinisp2 wrsalias.
WebSphere Application Server-Ausnahmebedingung für Datenquelle
Bei der Migration von Version 6.x auf Version 7.1.1 von WebSphere Remote Server
wird der Klassenpfad im JDBC-Provider, dem die Musteranwendungen ('Plants'
und 'Trades') zugeordnet sind, fest codiert, zum Beispiel: /opt/IBM/SIF/db2/V9.5/
134
java. Nach der Migration schlägt die Testverbindung für die Datenquelle der Musteranwendungen fehl, da DB2 auf Version 9.7 Fixpack 2 migriert wurde und der
Pfad /opt/IBM/SIF/db2/V9.5/ nicht vorhanden ist. Wenn die Testverbindung für
die Datenquelle der Anwendung 'Plants' fehlschlägt, wird beispielsweise die folgende Fehlernachricht ausgegeben:
The test connection operation failed for data source Plants by WebSphere Data Source on server
server1 at node WRSNode 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.
Zur Vermeidung dieses Problems verwenden Sie die WebSphere Application Server-Administrationskonsole, um den Wert des Klassenpfads im JDBC-Provider auf
die Umgebungsvariable ${DB2UNIVERSAL_JDBC_DRIVER_PATH} zu setzen, bevor
Sie den Migrationsprozess starten. Diese Variable wird während der Migration aktualisiert.
WebSphere Application Server-Ausnahmebedingung nach Installation
Nach einer erfolgreichen Installation des Produkts wird möglicherweise die folgende Ausnahmebedingung in der Datei SystemOut.log angezeigt:
[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.
Sie können diese Ausnahmebedingung ignorieren.
WebSphere Application Server-Ausnahmebedingung zur Handelsanwendung
Nach einer erfolgreichen Installation der Middleware und der Anwendungen wird
möglicherweise die folgende Ausnahmebedingung zur Handelsanwendung in der
Datei SystemOut.log angezeigt:
[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)
WebSphere Application Server-Ausnahmebedingung zur Migration der Anwendung 'Trade'
Bei der Migration von WebSphere Remote Server Version 6.1 auf Version 7.1.1 auf
dem Windows 2003-Betriebssystem mit aktivierter WebSphere Application Server-Sicherheit kann die Anwendung 'Trade' nicht gestartet werden und die folgende Ausnahmebedingung wird ausgegeben:
135
java.utl.ConcurrentModificationException (in com.ibm.jsd.eclipse.main plug-in)
Zur Behebung dieses Problems öffnen Sie die Administrationskonsole von WebSphere Application Server und klicken Sie auf Users and Groups → Manage Users
→ Create, um einen Benutzeraccount 'db2admin' (bzw. einen Account mit Ihrem
DB2-Benutzernamen) zu erstellen.
Ausnahmebedingung SRVE0255E
Nach einer erfolgreichen Installation des Produkts wird möglicherweise die folgende Ausnahmebedingung zur Datei favicon.ico in der Datei SystemOut.log angezeigt:
[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.
Diese fehlende Datei favicon.ico wird in der WebSphere Application Server-Verwaltungskonsole verwendet, um im Browser ein Symbol für ein Lesezeichen oder
auf einer Browserregisterkarte anzuzeigen, die in der Anwendung geöffnet ist. Sie
können diese Ausnahmebedingung einfach ignorieren.
Software Assembly Toolkit-Ausnahmebedingung nach Installation
Nach einer erfolgreichen Installation der Entwicklungsumgebung von WebSphere
Remote Server (auf allen Plattformen) werden beim Öffnen des Arbeitsbereichs die
folgenden Ausnahmebedingungen in der Fehlerprotokollansicht aufgeführt:
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)
Informix Growth Edition erneut installieren
Wenn Sie Informix Growth Edition installieren und anschließend deinstallieren,
ohne dabei die Option clean zu verwenden, wird die erneute Installation von Informix Growth Edition nicht unterstützt.
Die erneute Installation nach einer Deinstallation, bei der die Option clean nicht
verwendet wurde, wird für DB2 unterstützt.
Linux-Server mit aktivierter WebSphere Application Server-Sicherheit erneut starten
Wenn Sie die WebSphere Application Server-Sicherheit auf einem Linux-Betriebssystem aktiviert haben, müssen Sie sicherstellen, dass WebSphere Application Server heruntergefahren ist, bevor Sie einen Warmstart für den Server ausführen.
Software Assembly Toolkit Developer kann unter SUSE Linux
Enterprise Server 10.3 (64-Bit) nicht geöffnet werden.
Wenn Sie Software Assembly Toolkit Developer auf dem Betriebssystem SUSE Linux Enterprise Server 10.3 (64-Bit) mit dem Befehl cd /opt/IBM/SAT/3.2/
SolutionEnabler./IRU_Developer.sh öffnen, tritt der folgende Fehler auf:
136
/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
Zur Behebung des Problems muss auf der Workstation XULRunner Version 1.8.1.1
oder Version 1.9.0.6 verfügbar sein. Führen Sie zur Behebung des Problems die folgenden Schritte aus:
1. Überprüfen Sie wie folgt, welche XULRunner-Versionen auf der Workstation
verfügbar sind:
a. Navigieren Sie in das Verzeichnis /usr/lib, indem Sie diesen Befehl ausführen: #cd /usr/lib
b. Führen Sie den Befehl # ls -ld xul* aus, um die verfügbaren XULRunnerVersionen anzuzeigen.
c. Wenn XULRunner V1.8.1.1 oder V1.9.0.6 auf der Workstation nicht verfügbar ist, können Sie die gewünschte Version unter der folgenden Adresse herunterladen: http://releases.mozilla.org/pub/mozilla.org/xulrunner/.
2. Fügen Sie die folgende Parameterzeichenfolge am Ende der Datei
IRU_Developer.sh im Verzeichnis /opt/IBM/ISAT/3.2/SolutionEnabler hinzu:
-Dorg.eclipse.swt.browser.XULRunnerPath=/usr/lib/xulrunner-1.8.1.1/xulrunner
Anmerkung: Bei der Verwendung von XULRunner V1.9.0.6 müssen Sie stattdessen den folgenden Verzeichnispfad in der Parameterzeichenfolge angeben: =/usr/lib/xulrunner-1.9.0.6/xulrunner.
WebSphere Remote Server Data Provider-Ausnahmebedingung
Bei der Verwendung von WebSphere Remote Server Data Provider zur Überwachung von Remote Management Agent kann die folgende Ausnahmebedingung in
der Datei orbtrc.13072010.1911.31.txt im Verzeichnis SIF_HOME\WRSDP auftreten:
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)
Fehlende Symbolgrafiken in den Dateibrowserfenstern für die
Installationsverzeichnisfelder im Implementierungsassistenten
unter Windows 7
Bei der Verwendung des Implementierungsassistenten für WebSphere Remote Server V7.1.1 unter Windows 7 fehlen möglicherweise die Symbolgrafiken in der Navigationsleiste der Dateibrowserfenster für die Installationsverzeichnisfelder im Implementierungsassistenten. Die fehlenden Symbolgrafiken sind Eine Ebene nach
oben, Neuen Ordner erstellen, Liste und Details.
Die fehlenden Grafiken haben keine Auswirkung auf die Funktionsfähigkeit der
Symbole.
137
138
Kapitel 7. Referenzinformationen
Die nachstehenden Themen werden als zusätzliche Referenzinformationen zu Ihrer
Unterstützung bereitgestellt.
Allgemeine Produktinformationen
In diesem Dokument sind Informationen für den Zugriff auf die Downloadinformationen, die Produktunterstützungssite, die Hardware- und Softwarevoraussetzungen sowie die Dokumentation von IBM WebSphere Remote Server enthalten.
Auf die Website für die Produktunterstützung zugreifen
Rufen Sie die folgende URL-Adresse auf, um nach den neuesten technischen Hinweisen, Downloads, Programmkorrekturen und anderen Unterstützungsinformationen zu suchen: http://www.ibm.com/software/webservers/remoteserver/
support/.
Auf Hardware- und Softwarevoraussetzungen zugreifen
Informationen zu den Hardware- und Softwarevoraussetzungen finden Sie im Information Center unter „Hardware- und Softwarevoraussetzungen” auf Seite 9.
Zusätzliche Produktdokumentation
Zusätzlich zu diesem Information Center sind auf einer separaten CD mit der Bezeichnung Quick Start Handbücher für den Schnelleinstieg verfügbar.
Sie können auch über die Bibliotheksseite des Produkts unter der Adresse http://
www-01.ibm.com/software/webservers/remoteserver/library/index.html auf Produktdokumentation zugreifen.
Kontaktaufnahme mit IBM Software Support
Wenn Sie ein Problem mit WebSphere Remote Server feststellen, führen Sie zunächst die folgenden Aktionen aus:
v Führen Sie die in der Produktdokumentation beschriebenen Schritte aus.
v Suchen Sie nach Referenzliteratur in der Onlinehilfe.
Wenn Sie Ihr Problem mit keiner dieser Methoden lösen können, wenden Sie sich
an die technische Unterstützungsfunktion von IBM.
Wenn Sie WebSphere Remote Server beziehen, erhalten Sie ein Jahr lang telefonische Unterstützung im Rahmen des Programms Passport Advantage. Details zu
Passport Advantage finden Sie auf der Seite für Passport Advantage.
139
Mitglieder von Passport Advantage erhalten Unterstützung zu WebSphere Remote
Server unter der Telefonnummer +49-7032-15-49201. Halten Sie die folgenden Informationen bereit:
v Ihre Vertrags- oder Passport Advantage-Nummer
v Ihre Version und Änderungsstufe von WebSphere Remote Server sowie alle installierten Programmkorrekturen
v Name und Version des verwendeten Betriebssystems
v Typ und Version der verwendeten Datenbank
v Basisdaten zur Topologie: Anzahl der verwendeten Maschinen, Anzahl der Anwendungsserver usw.
v Fehlernachrichten oder Warnungen (falls vorhanden) zum betreffenden Problem
White Papers
Dieser Abschnitt enthält einen Link zu für den Download verfügbaren White Papers, die Ihnen Unterstützung bei der Installation, Konfiguration und Verwaltung
der Komponenten Ihrer IBM WebSphere Remote Server-Lösung bieten.
Unter der folgenden URL finden Sie eine Liste der für WebSphere Remote Server
verfügbaren White Paper: http://www.ibm.com/support/search.wss?rs=2193
&tc=SSUNCX&rank=8&dc=DA480+DB100&dtm
Bemerkungen und Marken
Bemerkungen
Die vorliegenden Informationen wurden für Produkte und Services entwickelt, die
auf dem deutschen Markt angeboten werden.
Möglicherweise bietet IBM die in dieser Dokumentation beschriebenen Produkte,
Services oder Funktionen in anderen Ländern nicht an. Informationen über die gegenwärtig im jeweiligen Land verfügbaren Produkte und Services sind beim zuständigen IBM Ansprechpartner erhältlich. Hinweise auf IBM Lizenzprogramme
oder andere IBM Produkte bedeuten nicht, dass nur Programme, Produkte oder
Services von IBM verwendet werden können. Anstelle der IBM Produkte, Programme oder Services können auch andere, ihnen äquivalente Produkte, Programme
oder Services verwendet werden, solange diese keine gewerblichen oder anderen
Schutzrechte von IBM verletzen. Die Verantwortung für den Betrieb von Produkten, Programmen und Services anderer Anbieter liegt beim Kunden.
Für in diesem Handbuch beschriebene Erzeugnisse und Verfahren kann es IBM Patente oder Patentanmeldungen geben. Mit der Auslieferung dieser Dokumentation
ist keine Lizenzierung dieser Patente verbunden. Lizenzanforderungen sind schriftlich an folgende Adresse zu richten (Anfragen an diese Adresse müssen auf Englisch formuliert werden):
IBM Director of Licensing
IBM Europe, Middle East & Africa
Tour Descartes
2, avenue Gambetta
92066 Paris La Defense
France
140
Der Inhalt dieser Dokumentation dient nur zu Informationszwecken. Diese Informationen basieren auf der aktuellen Produktplanung und -strategie von IBM, die
sich jederzeit ohne Vorankündigung ändern kann. IBM haftet nicht für Schäden,
die durch Verwendung oder im Zusammenhang mit dieser Dokumentation entstehen. Aus dem Inhalt dieser Dokumentation können kein Gewährleistungsanspruch
oder andere Anforderungen an IBM (oder seine Lieferanten oder Lizenzgeber) abgeleitet werden, noch kann der Inhalt eine Änderung der Bedingungen der geltenden Lizenzvereinbarung, der die Nutzung der IBM Software unterliegt, bewirken.
Trotz sorgfältiger Bearbeitung können technische Ungenauigkeiten oder Druckfehler in dieser Veröffentlichung nicht ausgeschlossen werden. Die hier enthaltenen Informationen werden in regelmäßigen Zeitabständen aktualisiert und als Neuausgabe veröffentlicht. IBM kann ohne weitere Mitteilung jederzeit Verbesserungen und/
oder Änderungen an den in dieser Veröffentlichung beschriebenen Produkten und/
oder Programmen vornehmen.
Werden an IBM Informationen eingesandt, können diese beliebig verwendet werden, ohne dass eine Verpflichtung gegenüber dem Einsender entsteht.
Verweise in diesen Informationen auf Websites anderer Anbieter werden lediglich
als Service für den Kunden bereitgestellt und stellen keinerlei Billigung des Inhalts
dieser Websites dar. Das über diese Websites verfügbare Material ist nicht Bestandteil des Materials für dieses IBM Produkt. Die Verwendung dieser Websites geschieht auf eigene Verantwortung.
Alle Informationen zu Produkten anderer Anbieter stammen von den Anbietern
der aufgeführten Produkte, deren veröffentlichten Ankündigungen oder anderen
allgemein verfügbaren Quellen. IBM hat diese Produkte nicht getestet und kann
daher keine Aussagen zu Leistung, Kompatibilität oder anderen Merkmalen machen. Fragen zu den Leistungsmerkmalen von Produkten anderer Anbieter sind
an den jeweiligen Anbieter zu richten.
Diese Veröffentlichung dient nur zu Planungszwecken. Die in dieser Veröffentlichung enthaltenen Informationen können geändert werden, bevor die beschriebenen Produkte verfügbar sind.
Marken
Folgende Namen sind Marken der IBM Corporation in den USA und/oder anderen Ländern:
AIX
DataBlade
DB2
Express
IBM
Informix
iSeries
MQSeries
Passport Advantage
SupportPac
Tivoli
WebSphere
Kapitel 7. Referenzinformationen
141
Intel, das Intel-Logo, Intel Inside®, das Intel Inside-Logo, Intel® Centrino®, das Intel
Centrino-Logo, Celeron®, Intel® Xeon®, Intel SpeedStep®, Itanium® und Pentium
sind Marken oder eingetragene Marken der Intel Corporation oder deren Tochtergesellschaften in den USA oder anderen Ländern.
Java und alle auf Java basierenden Marken und Logos sind Marken von Sun Microsystems, Inc. in den USA und/oder anderen Ländern.
Linux ist eine eingetragene Marke von Linus Torvalds in den USA und/oder anderen Ländern.
Microsoft, Windows, Windows NT® und das Windows-Logo sind Marken der Microsoft Corporation in den USA und/oder anderen Ländern.
UNIX ist eine eingetragene Marke von The Open Group in den USA und anderen
Ländern.
Weitere Unternehmens-, Produkt- oder Servicenamen können Marken anderer Hersteller sein.
142
Antwort
WebSphere® Remote Server
IBM WebSphere Remote Server
Information Center Version 7.1.1
Version 7.1.1
Anregungen zur Verbesserung und Ergänzung dieser Veröffentlichung nehmen wir gerne entgegen. Bitte informieren Sie uns über Fehler, ungenaue Darstellungen oder andere Mängel.
Zur Klärung technischer Fragen sowie zu Liefermöglichkeiten und Preisen wenden Sie sich bitte entweder an Ihre
IBM Geschäftsstelle, Ihren IBM Geschäftspartner oder Ihren Händler.
Unsere Telefonauskunft "HALLO IBM" (Telefonnr.: 0180 3 313233) steht Ihnen ebenfalls zur Klärung allgemeiner Fragen zur Verfügung.
Kommentare:
Danke für Ihre Bemühungen.
Sie können ihre Kommentare betr. dieser Veröffentlichung wie folgt senden:
v Als Brief an die Postanschrift auf der Rückseite dieses Formulars
v Als E-Mail an die folgende Adresse: [email protected]
Name
Adresse
Firma oder Organisation
Rufnummer
E-Mail-Adresse
򔻐򗗠򙳰
Antwort
IBM Deutschland GmbH
SW TSC Germany
71083 Herrenberg

WebSphere Remote Server Information Center Version 7.1.1

Transcription

Similar documents

Vorwort - Ministère de la Famille et de l`Intégration

Handbuch LaCash-Einzelhandel

Trading Post LIVE bei Metro

Manuel d`instruction Bedienungsanleitung Manuale di

Cluster-in-a-box auf Basis von PRIMERGY CX420-C