|
| |
| Sun Java Enterprise System 5-Aktualisierungshandbuch für UNIX | |
Kapitel15
Portal ServerIn diesem Kapitel wird die Aktualisierung von Portal Server auf Java ES 5 (Release 5) beschrieben: Sun Java System Portal Server 7.1.
Das Kapitel enthält einen Überblick über die Aspekte der verschiedenen Aktualisierungswege, die von Release 5 unterstützt werden. Es wird sowohl die Aktualisierung unter dem Solaris- als auch unter dem Linux-Betriebssystem berücksichtigt:
Überblick über Aktualisierungen von Portal ServerIn diesem Abschnitt werden die folgenden allgemeinen Aspekte bezüglich der Aktualisierung von Portal Server auf Java ES 5 (Release 5) beschrieben:
Über Java ES Release 5 Portal Server
Java ES Release 5 Portal Server stellt eine Major-Release im Hinblick auf Release 4 dar und weist zahlreiche neue Optimierungen und Funktionen auf. Viele der Änderungen wurden in einem vorläufigen Release (Interim Feature Release, IFR) vorgenommen, das nach Release 4 eingeführt wurde. Release 5 enthält in Bezug auf das IFR nur kleine Funktionsänderungen. Informationen zu den IFR-Optimierungen und neuen Funktionen sind in den Sun Java System Portal Server 7.1 Release Notes unter http://docs.sun.com/doc/820-0901/6n4l3f365?a=view zu finden. Insbesondere wurde die Release 4-Befehlszeilenschnittstelle für die Verwaltung durch den Befehl psadmin ersetzt.
Wegweiser für die Aktualisierung von Portal Server
Tabelle 15-2 zeigt die unterstützten Wege für die Aktualisierung von Portal Server auf Java ES Release 5. Die Tabelle gilt sowohl für das Solaris- als auch für das Linux-Betriebssystem.
Portal Server-Daten
Die folgende Tabelle enthält die Datentypen, die von einer Aktualisierung der Portal Server-Software betroffen sein können.
Portal Server Vorgehensweise zur Aktualisierung
Ihre Vorgehensweise bei der Aktualisierung von Portal Server hängt grundsätzlich von den zahlreichen in Chapter 1, "Planung hinsichtlich der Aktualisierungen" erläuterten Aspekten ab: Aktualisierungsweg, Abhängigkeiten zwischen den Java ES-Komponenten, selektive Aktualisierung im Vergleich zur Aktualisierung aller Komponenten, Bereitstellung mehrerer Instanzen usw.
Dieser Abschnitt konzentriert diese grundsätzliche Erläuterung auf Portal Server, indem Probleme dargestellt werden, die möglicherweise Ihren Aktualisierungsplan für Portal Server beeinflussen.
Kompatibilität
Release 5 Portal Server enthält Änderungen an der öffentlichen Schnittstelle im Befehl psadmin, mit dem Portal Server- und Portal Server Secure Remote Access-Komponenten verwaltet werden. Weitere Informationen finden Sie in Sun Java System Portal Server 7.1 Command-Line Reference (http://docs.sun.com/doc/819-5030).
Daher ist Release 5 Portal Server nicht mit früheren Versionen bzw. mit früheren Versionen von Portal Server Secure Remote Access-Komponenten (einschließlich SRA-Gateway, Rewriter-Proxy und Netlet-Proxy) rückwärtskompatibel, außer in einer Übergangsphase, in der Bereitstellungen mehrerer Instanzen ein Rolling Upgrade durchlaufen. Alle Portal Server-Instanzen müssen zusammen mit den Instanzen der Portal Server Secure Remote Access-Komponenten auf Java ES Release 5 synchronisiert werden.
Einzelne Portal Server-Komponenten einschließlich der Mobile Access-Komponente sind ebenso wenig rückwärtskompatibel mit früheren Versionen; sie müssen alle auf Java ES Release 5 synchronisiert werden.
Des Weiteren liegt eine Inkompatibilität zwischen den in Portal Server Release 5 und früheren Portal Server-Versionen verwendeten Directory Server-Datenstrukturen vor. Diese Inkompatibilität wirkt sich auf das Rolling Upgrade mehrerer Portal Server-Instanzen aus, die dieselben Directory Server-Daten verwenden.
Portal Server-Abhängigkeiten
Portal Server-Abhängigkeiten zu anderen Java ES-Komponenten beeinflussen möglicherweise das Verfahren für die Aktualisierung und Neukonfiguration der Portal Server-Software. Änderungen der Portal Server-Schnittstellen oder -Funktionen könnten beispielsweise eine aktualisierte Version der Komponenten erforderlich machen, von denen Portal Server abhängig ist. Welche dieser Komponenten aktualisiert werden müssen, hängt von dem jeweiligen Aktualisierungsweg ab.
Für Portal Server bestehen Abhängigkeiten zu folgenden Java ES-Komponenten:
- Gemeinsam genutzte Komponenten. Portal Server ist von bestimmten gemeinsam genutzten Java ES-Komponenten abhängig (siehe Tabelle 1-9).
- Webcontainer. Portal Server verfügt über eine obligatorische Abhängigkeit zu Webcontainerdiensten, die entweder durch Java ES Webserver, Java ES Anwendungsserver oder durch Drittanbieter-Webcontainer von Weblogic und WebSphere bereitgestellt werden können.
- Access Manager (oder Access Manager SDK). Portal Server verfügt über eine obligatorische Abhängigkeit zu Access Manager, um Authentifizierungs- und Autorisierungsdienste für Endbenutzer, einschließlich Single-Sign-On, bereitzustellen. Wenn Access Manager auf einem Remote-Computer ausgeführt wird, muss Access Manager SDK lokal zur Verfügung stehen.
- Directory Server. Portal Server verfügt über eine obligatorische Abhängigkeit zu Directory Server, der Benutzerdaten speichert, auf die über Access Manager zugegriffen wird. Daher sind bei einer Aktualisierung von Portal Server möglicherweise Erweiterungen des Directory-Schemas erforderlich.
- Portal Server Secure Remote Access. Portal Server verfügt über eine optionale Abhängigkeit zu Portal Server Secure Remote Access, der sicheren dezentralen Zugriff über die Gateway-, Rewriter Proxy- und Netlet Proxy-Komponenten zur Verfügung stellt.
- Java DB. Portal Server verfügt über eine optionale Abhängigkeit zu Java DB, der verschiedene Portlet-Anwendungen unterstützt.
- Service Registry. Portal Server verfügt über eine obligatorische Abhängigkeit zu Service Registry, der Bibliotheken zur Verfügung stellt, die zur Kompilierung benötigt werden.
- Communications Express. Portal Server verfügt über eine optionale Abhängigkeit zu Communications Express, eine Sun Java Communications Suite-Komponente, die der Breitstellung von Messaging- und Kalenderkanälen für Endbenutzer dient. Communications Express ist keine Java ES-Produktkomponente mehr.
Selektive Aktualisierung
Zwar unterstützt Java ES Release 5 im Allgemeinen die selektive Aktualisierung aller Komponenten auf einem Computer; da Portal Server jedoch von so vielen anderen Java ES-Komponenten abhängt, gestaltet es sich sehr schwierig, beliebige Komponentenkombinationen über verschiedene Java ES-Release-Versionen hinweg zu zertifizieren.
Aus diesem Grund unterstützt Portal Server eine eingeschränkte Reihe von Aktualisierungsszenarios im Hinblick auf Access Manager und Webcontainer.
- Bei Aktualisierung Portal Server von Java ES Release 4. Sie können Directory Server, Access Manager und Webcontainer (Webserver oder Anwendungsserver) vor Portal Server oder nur Portal Server auf Release 5 aktualisieren (wobei die anderen Komponenten auf Release 4-Ebene verbleiben); Sie können jedoch keine Abhängigkeiten in Release 4 belassen und andere auf Release 5 aktualisieren.
- Bei Aktualisierung Portal Server von Java ES Release 3. Sie müssen Directory Server, Access Manager und Webcontainer (Webserver oder Anwendungsserver) vor Portal Server auf Release 4 oder Release 5 aktualisieren; Sie können jedoch weder Abhängigkeiten in Release 3 belassen noch einige Abhängigkeiten auf Release 4 und andere auf Release 5 aktualisieren.
- Bei Aktualisierung Portal Server von Java ES Release 2. Sie müssen Directory Server, Access Manager und Webcontainer (Webserver oder Anwendungsserver) vor Portal Server auf Release 4 oder Release 5 aktualisieren. Sie können jedoch weder Abhängigkeiten in Release 2 belassen noch einige Abhängigkeiten auf Release 4 und andere auf Release 5 aktualisieren.
Aktualisierungsszenarios für den Webcontainer
Portal Server kann in einem Webcontainer eingesetzt werden, der entweder von Webserver oder Anwendungsserver bereitgestellt wurde. Daher kann die Aktualisierung von Portal Server auf Release 5 dadurch kompliziert werden, dass möglicherweise auch der Webcontainer auf Release 5 aktualisiert werden muss, in dem er eingesetzt wird. Es sind eine Reihe von Aktualisierungsszenarien für den Webcontainer möglich, die in der folgenden Tabelle dargestellt werden.
Gehen Sie bei der Aktualisierung von Portal Server (z. B. bei der Verwendung des Skripts psupgrade) vorsichtig vor und geben Sie die für das in Tabelle 15-4 entsprechend dargestellte Aktualisierungsszenario korrekten Werte ein, insbesondere wenn dies eine Aktualisierung einer Major-Version des Webcontainers beinhaltet.
Duale Aktualisierung
Die duale Aktualisierung, bei der sowohl Portal Server als auch das Betriebssystem aktualisiert werden (wie unter Duale Aktualisierungen: Java ES und Betriebssystem-Software beschrieben), kann mithilfe des Ansatzes zur Aktualisierung des vorhandenen Betriebssystems durchgeführt werden:
- Sichern Sie die vorhandenen Portal Server-Daten.
Informationen zum Speicherort wichtiger Daten finden Sie unter Portal Server-Daten.
- Aktualisieren Sie das Betriebssystem.
Bei der Aktualisierung wird das vorhandene Dateisystem beibehalten.
- Aktualisieren Sie auf Release 5 Portal Server.
Weitere Informationen finden Sie im entsprechenden Abschnitt dieses Kapitels, abhängig vom Aktualisierungspfad.
Aktualisieren von Portal Server von Java ES Release 4Dieser Abschnitt enthält Informationen zur Aktualisierung von Portal Server von Java ES 2005Q4 (Release 4) auf Java ES 5 (Release 5).
In diesem Abschnitt werden folgende Themen behandelt:
Einführung
Berücksichtigen Sie bei der Aktualisierung von Java ES von Portal Server Release 4 auf Release 5 folgende Aspekte des Aktualisierungsvorgangs:
- Allgemeiner Aktualisierungsansatz. Die Aktualisierung erfolgt durch die Verwendung eines Aktualisierungsskripts, psupgrade. Das Skript installiert neue Pakete, migriert Konfigurationsdaten, wenn erforderlich, aktualisiert Lokalisierungsdateien und stellt dem Webcontainer Portal Server-Webanwendungen erneut bereit.
- Aktualisierungsabhängigkeiten. Portal Server ist von einer Reihe gemeinsam genutzter Java ES-Komponenten abhängig (siehe Tabelle 1-9). Portal Server Release 5 ist zwar mit der Release 4-Version dieser gemeinsamen Komponenten kompatibel, jedoch ist eine Aktualisierung dennoch erforderlich, da das für die Aktualisierung von Portal Server verwendete Skript psupgrade die Release 5-Version der gemeinsam genutzten ANT-Komponente benötigt.
Portal Server Release 5 verfügt auch über Abhängigkeiten von einem Webcontainer, Access Manager sowie Directory Server, wie unter Portal Server-Abhängigkeiten beschrieben. Es werden zwei Ansätze zur Aktualisierung dieser Abhängigkeiten unterstützt (siehe Selektive Aktualisierung):
- Rückwärtskompatibilität. Release 5 Portal Server ist nicht mit Release 4 rückwärtskompatibel.
- Aufheben der Aktualisierung. Das Aufheben der Aktualisierung von Portal Server auf Release 5 erfolgt durch Wiederherstellen der Pakete von Release 4. Hierbei werden die Verzeichnisdaten von Release 4 wiederhergestellt und die Portal Server-Webanwendungen dem Webcontainer erneut bereitgestellt.
- Plattformspezifische Aspekte. Der allgemeine Ansatz für die Aktualisierung von Portal Server ist für das Solaris- und Linux-Betriebssystem identisch, jedoch wird Portal Server Release 5 unter Solaris in einem neuen Pfad und unter Linux im selben Release 4-Pfad installiert.
Aktualisierung der Release 4-Version von Portal Server
In diesem Abschnitt wird die Aktualisierung von Portal Server von Java ES Release 4 auf Java ES Release 5 unter Solaris und Linux beschrieben. Plattformspezifische Vorgänge sind durch die Angabe des jeweiligen Betriebssystems, auf das sich der Vorgang bezieht, gekennzeichnet. In diesem Abschnitt werden folgende Themen behandelt:
Aufgaben vor der Aktualisierung von Release 4
Bevor Sie mit der Aktualisierung von Portal Server beginnen, führen Sie die folgenden Aufgaben durch:
Aktuelle Versionsinformationen überprüfen
Sie können die aktuelle Version von Portal Server mithilfe des folgenden Befehls überprüfen:
PortalServer6-base/bin/version
Tabelle 15-5 Ausgabe der Versionsüberprüfung von Portal Server
Java ES Release
Portal Server-Versionsnummer
Release 2
6.3
Release 3
6.3.1
Release 4
6.3.11
IFR
7.0
Release 5
7.1
1Release 3 und Release 4 unterscheiden sich lediglich durch einen Patch. Sie können die Release 4-Patches mit dem Solaris-Befehl showrev -p | grep patch_ID und dem Linux-Befehl rpm -qa sun-portal-core suchen und die Versionen mit den im Java ES Release 4 Aktualisierungshandbuch aufgeführten vergleichen.
Portal Server-Abhängigkeiten aktualisieren
Es wird grundsätzlich empfohlen, alle Java ES-Komponenten auf einem Computersystem (und in einer Netzwerkumgebung) auf Java ES Release 5 zu aktualisieren.
Portal Server Release 5 ist zwar mit der Release 4-Version dieser gemeinsamen Java ES-Komponenten kompatibel, jedoch ist eine Aktualisierung dennoch erforderlich, da das für die Aktualisierung von Portal Server verwendete Skript psupgrade die Release 5-Version der gemeinsam genutzten ANT-Komponente benötigt.
Wenn Sie Abhängigkeiten der Portal Server-Produktkomponenten auf Release 5 aktualisieren möchten, müssen alle aktualisiert werden (siehe Selektive Aktualisierung). Die Abhängigkeiten sollten vor der Aktualisierung von Portal Server in der nachstehend genannten Reihenfolge aktualisiert werden (bereits aktualisierte können hierbei übersprungen werden).
- Gemeinsam genutzte Komponenten. Anweisungen zur Aktualisierung der gemeinsam genutzten Java ES-Komponenten auf Release 5 finden Sie unter Aktualisieren der gemeinsam genutzten Java ES-Komponenten.
- Directory Server. Anweisungen zur Aktualisierung von Directory Server auf Release 5 finden Sie in Chapter 5, "Directory Server".
- Webcontainer-Software. Anweisungen zur Aktualisierung von Webserver und Anwendungsserver finden Sie in Chapter 7, "Webserver" bzw. Chapter 11, "Anwendungsserver".
- Access Manager (Access Manager SDK). Anweisungen zur Aktualisierung von Access Manager auf Release 5 finden Sie in Chapter 14, "Access Manager".
- Portal Server Secure Remote Access. Anweisungen zur Aktualisierung von Portal Server Secure Remote Access auf Release 5 finden Sie in Chapter 16, "Portal Server Secure Remote Access".
- Java DB. Anweisungen zur Aktualisierung von Java DB auf Release 5 finden Sie in Chapter 8, "Java DB".
- Service Registry. Anweisungen zur Aktualisierung von Service Registry auf Release 5 finden Sie in Chapter 12, "Service Registry".
- Communications Express. Anweisungen zur Aktualisierung von Communications Express auf Release 5 finden Sie im Sun Java Communications Suite Upgrade Guide, http://docs.sun.com/doc/819-7561.
Erforderliche Konfigurationsinformationen und Passwörter abrufen
Je nach Aktualisierungsszenario der Webcontainer (siehe Tabelle 15-4) müssen Sie für das Skript psupgrade Informationen zu Passwörtern und andere Webcontainer-Konfigurationsdaten eingeben. Die Informationen, die für die verschiedenen Aktualisierungsszenarien für Webcontainer benötigt werden, sind in Tabelle 15-6 aufgeführt. Denken Sie daran, sich vor der Aktualisierung von Portal Server die relevanten Informationen zu beschaffen.
Tabelle 15-6 Vom Skript psupgrade für die Webcontainer-Aktualisierungsszenarien benötigte Informationen
Information
Aktualisierungsszenario1
Webserver 7.x Beispielwerte:
Szenario 2Anwendungsserver 8.x Beispielwerte:
Szenario 52Aktualisierung von Portal Server auf Webserver 7.0 (ja/nein)
2
Ja
N/V
Webcontainer-Installationsverzeichnis
2 und 5
WebServer7-base
AppServer8Install-base
Webcontainer-Objektname des virtuellen Servers
2
https-configName2
N/V
Webcontainer-Objektname
5
N/V
Server1
Webcontainer-Objektverzeichnis
2
WebServer7Config-base/
https-configName4/N/V
Portal-Instanz-Bereitstellungsverzeichnis
5
N/V
AppServer8Config-base/
Domänen/domainNameWebcontainer-Instanzanschluss
2 und 5
80
80
Webcontainer-Instanzprotokoll
2 und 5
http
http
Webcontainer-Konfigurationsname
2
configName4
N/V
Webcontainer-Domänenname
5
N/V
domain1
Webcontainer-Dokument-Root-Verzeichnis
2 und 5
WebServer7Config-base/
https-configName4/docs/AppServer8Config-base/
Domänen/domainName/
docrootWebcontainer-Admin-Hostname
2 und 5
Lokaler Host
Lokaler Host
Webcontainer-Admin-Anschluss
2 und 5
8989
4848
Webcontainer-Admin-Protocol
2 und 5
https
https
Webcontainer-Admin-Benutzer-ID
2 und 5
admin
admin
Webcontainer-Admin-Passwort
2 bis 5
Webcontainer-Master-Passwort
3 bis 5
N/V
Directory Manager (cn=Directory manager)-Passwort
1 bis 5
SRA-Protokoll-Benutzerpasswort3
1 bis 5
Access Manager-Admin-Passwort
1 bis 5
ldapuser-Passwort für Directory Server
1 bis 5
Portal-Instanz-ID4
1 bis 5
1Webcontainer-Aktualisierungsszenario #5 gilt für die Aktualisierung von Portal Server von Release 2.
2Der Standardwert von configName lautet hostName.domainName.
3Diese Informationen werden zum Konfigurieren der Portal Server Secure Remote Access-Komponenten bei Installation mit Portal Server benötigt.
4Für diesen Parameter muss ein einmaliger Wert angegeben werden, der nicht Null sein darf. Der Wert muss alphanumerisch sein und kann einen Bindestrich (-) enthalten.
Konfigurationsinformationen von Portal Server Release 4 sichern
Bei der Aktualisierung von Portal Server auf Release 5 ist keine Neukonfiguration der Portal Server-Software erforderlich. Als Vorsichtsmaßnahme sichert jedoch das Skript psupgrade die folgenden Verzeichnisse mit Konfigurationsinformationen:
Aufzeichnen der Java Virtual Machine (JVM)-Einstellungen
Zeichnen Sie vor dem Aktualisieren von Portal Server die folgenden JVM-Webcontainer-Einstellungen auf, sofern sie von den Standardeinstellungen abweichen:
Der Speicherort der JVM-Einstellungen hängt vom Webcontainer ab, wie in der nachfolgenden Tabelle angezeigt.
Sie müssen später überprüfen, ob diese JVM-Einstellungen im Laufe der Portal Server-Aktualisierung nicht geändert wurden.
Konfiguration des Lastenausgleichsprogramms entfernen
In Fällen, in denen über ein Lastenausgleichsprogramm auf die Portal Server-Instanzen zugegriffen wird, kann der Wert der Eigenschaft LOAD_BALANCER_URL, der für die Konfiguration dieses Zugriffs verwendet wird, mit der Portal Server-Aktualisierung interferieren. Daher muss diese Einstellung vor Durchführung der Aktualisierung geändert werden. So ändern Sie die Einstellung der Eigenschaft LOAD_BALANCER_URL
- Notieren Sie sich, welche der folgenden Konfigurationsdateien lokal vorhanden sind (von denen einige Portal Server Secure Remote Access-Komponenten unterstützen und möglicherweise lokal installiert sind):
PortalServer6Config-base/PSConfig.properties
PortalServer6Config-base/GWConfig.properties (wenn Gateway lokal vorhanden ist)
PortalServer6Config-base/RWPConfig.properties (wenn Rewriter-Proxy lokal ist)
PortalServer6Config-base/NLPConfig.properties (wenn Netlet Proxy lokal vorhanden ist)- Notieren Sie den aktuellen Wert der Eigenschaft LOAD_BALANCER_URL in diesen Konfigurationsdateien.
- Ändern Sie den Wert der Eigenschaft LOAD_BALANCER_URL so, dass er auf die relevante Portal Server-Instanz verweist:
LOAD_BALANCER_URL=portalHostName:port/portal
Konfiguration entfernen von Directory Proxy Server
In Fällen, in denen Portal Server-Instanzen über eine Directory Proxy Server-Instanz auf Directory Server zugreifen, müssen die Einstellungen des Directory Proxy Server-Hosts und der Anschlussnummer vor Durchführung der Aktualisierung geändert werden. Nach erfolgter Aktualisierung müssen ihre ursprünglichen Werte wiederhergestellt werden.
So ändern Sie die entsprechenden Einstellungen
Aktualisieren der Release 4-Version von Portal Server (Solaris)
Dieser Abschnitt enthält eine Beschreibung der Aspekte, die Einfluss auf das Aktualisierungsverfahren von Portal Server haben, sowie eine Beschreibung des eigentlichen Aktualisierungsverfahrens.
Zu berücksichtigende Aspekte bei der Aktualisierung (Solaris)
Bei der Aktualisierung der Portal Server-Software auf Release 5 müssen folgende Aspekte berücksichtigt werden:
- Alle Portal Server-Instanzen, die demselben installierten Portal Server-Image entsprechen, werden gleichzeitig aktualisiert.
- Die Portal Server-Software besteht aus Unterkomponenten, die eine Reihe unterschiedlicher Rollen ausführen, jedoch alle zusammen aktualisiert werden:
- Portal-base. Enthält Verwaltungs-Mbeans und begleitende Verwaltungssoftware, Logging Framework und Software im Zusammenhang mit der Überwachung, die alle in einem Paket zusammengefasst sind.
- Portal Server Webanwendungen. Besteht aus einer Reihe von Webanwendungen, die in einem Webcontainer bereitgestellt werden. Zumindest einige dieser Webanwendungen benötigen Unterstützung von Access Manager und wiederum Directory Server.
- Secure Remote Access Core Software, die Portal Server Secure Remote Access unterstützt: Einige in JAR-Dateien eingebettete Servlets und Applets sowie einige Unterstützungsdateien können in einem Webcontainer nicht bereitgestellt werden.
- Das Skript psupgrade erkennt automatisch, welche Portal Server-Unterkomponenten und welche Webcontainer-Abhängigkeiten auf dem Host-Computer installiert sind. Beispiel: Das Skript weist das System an, die Version von Anwendungsserver oder Webserver zu erkennen, der Sie Portal Server-Webanwendungen bereitstellen, und passt die erforderlichen Informationen unter Verwendung der Informationen an, die es erkennen kann.
Aktualisierungsverfahren (Solaris)
Das im Folgenden beschriebene Verfahren ist für Portal Server auf dem Computer anzuwenden, auf dem die Aktualisierung durchgeführt wird.
- Melden Sie sich als Root oder Superuser an.
su -
- Synchronisieren Sie alle gemeinsam genutzten Komponenten auf Release 5, sofern dies noch nicht erfolgt ist.
Anweisungen hierzu erhalten Sie unter Chapter 2, "Aktualisieren der gemeinsam genutzten Java ES-Komponenten".
Dieser Schritt ist eine erforderliche Voraussetzung für die Ausführung des Skripts psupgrade in Step 8.
- Stoppen Sie etwaige Instanzen von Portal Server Secure Remote Access Gateway, Rewriter-Proxy oder Netlet-Proxy, die möglicherweise lokal ausgeführt werden.
PortalServer6-base/bin gateway stop
PortalServer6-base/bin netletd stop
PortalServer6-base/bin rwproxyd stopÜberprüfen Sie, ob die Prozesse angehalten wurden:
Gateway: netstat -an | grep 443
Rewriter Proxy: netstat -an | grep 10443
Netlet Proxy netstat -an | grep 10555- Vergewissern Sie sich, dass Access Manager ausgeführt wird, wenn es in einem anderen Webcontainer bereitgestellt wird als dem, in dem Portal Server bereitgestellt wird.
- Starten Sie Portal Server, sofern es nicht bereits ausgeführt wird, indem Sie den Webcontainer starten, in dem es bereitgestellt wird.
Webserver 6.x:
WebServer-base/https-instanceName/startWebserver 7.0:
Admin Server--
WebServer7Config-base/admin-server/bin/startserv
Instance Server--
WebServer7Config-base/https-configName/bin/startservAnwendungsserver 8.x:
AppServer8-base/bin/asadmin start-domain --user admin_ID
--password password domainName- Setzen Sie die zwei Umgebungsvariablen (ANT_HOME und JAVA_HOME), die vom Skript psupgrade benötigt werden. Beispiel:
export ANT_HOME=/usr/sfw
export JAVA_HOME=/usr/jdk/entsys-j2se- Stellen Sie sicher, dass auf Ihrem Computer ausreichend Swap-Speicher zur Verfügung steht.
Der Swap-Speicher sollte grundsätzlich die doppelte Größe des physikalischen RAM aufweisen.
- Führen Sie das Skript psupgrade über die Java ES Release 5-Bereitstellung aus.
cd os_arch/Products/portal_svr/Tools/upgrade/bin
./psupgradewobei os_arch der Plattform entspricht, wie z. B. Solaris_sparc.
Hinweis
Sollten Sie psupgrade versehentlich vom falschen os_arch-Verzeichnis aus gestartet haben, müssen Sie das Verfahren folgendermaßen rückgängig machen:
Das Skript psupgrade erkennt installierte Portal Server-Komponenten und Lokalisierungspakete, ruft das Java ES-Installationsprogramm auf, um neue Pakete zu installieren und weist das System an, Speicherort, Anschlussnummer und andere Informationen zum Webcontainer zu erkennen, in dem Sie Portal Server-Webanwendungen bereitstellen. Je nach Webcontainer-Aktualisierungsszenario (siehe Tabelle 15-4) fordert das Skript Sie auf, zusätzliche Informationen einzugeben, die für die Bereitstellung von Portal Server für den entsprechenden Webcontainer erforderlich sind.
Tabelle 15-6 enthält die Informationen, die für die verschiedenen Webcontainer-Aktualisierungsszenarien in Tabelle 15-4 erforderlich sind.
- Stellen Sie gegebenenfalls die JVM-Einstellungen des Webcontainers wieder her.
Um sicherzustellen, dass die JVM-Einstellungen Portal Server Release 5 unterstützen, führen Sie die folgenden Schritte durch:
- Stellen Sie sicher, dass die JVM-Einstellungen des Webcontainers für Portal Server, die Sie vor der Aktualisierung aufgezeichnet haben, nicht im Laufe der Aktualisierung geändert wurden.
Siehe auch Aufzeichnen der Java Virtual Machine (JVM)-Einstellungen.
- Wenn die Änderungen geändert wurden, stellen Sie die Werte wieder her, die Sie vor der Aktualisierung aufgezeichnet haben.
Vergewissern Sie sich, dass die folgenden JVM-Einstellungen enthalten sind, selbst wenn sie zuvor nicht eingerichtet wurden:
<jvm-options>-XX:MaxPermSize=256m</jvm-options>
<jvm-options>-XX:+CMSPermGenSweepingEnabled</jvm-options>
<jvm-options>-XX:+CMSClassUnloadingEnabled</jvm-options>- Halten Sie den Webcontainer an und starten Sie ihn erneut.
Ein Neustart des Webcontainers ist zwar nicht in jedem Fall erforderlich, dadurch wird jedoch sichergestellt, dass der Status von Portal Server beim Start eindeutig ist.
- Halten Sie den Webcontainer wie folgt an:
Webserver 6.x:
WebServer-base/https-instanceName/stopWebserver 7.0:
Admin Server--
WebServer7Config-base/admin-server/bin/stopserv
Instance Server--
WebServer7Config-base/https-configName/bin/stopservAnwendungsserver 8.x:
AppServer8-base/bin/asadmin stop-domain --user admin_ID
--password password domainName- Starten Sie den Webcontainer mit den Befehlen in Step 5 neu.
Aktualisieren der Release 4-Version von Portal Server (Linux)
Dieser Abschnitt enthält eine Beschreibung der Aspekte, die Einfluss auf das Aktualisierungsverfahren von Portal Server haben, sowie eine Beschreibung des eigentlichen Aktualisierungsverfahrens.
Zu berücksichtigende Aspekte bei der Aktualisierung (Linux)
Bei der Aktualisierung der Portal Server-Software auf Release 5 unter Linux sind dieselben Aspekte wie unter Solaris zu berücksichtigen (siehe Zu berücksichtigende Aspekte bei der Aktualisierung (Solaris)), jedoch wird Portal Server Release 5 unter Linux im selben Pfad wie Release 4 installiert. Daher entfernt das Skript psupgrade bei der Installation der RPMs für Release 5 die vorherigen RPMs.
Aktualisierungsverfahren (Linux)
Das im Folgenden beschriebene Verfahren ist für Portal Server auf dem Computer anzuwenden, auf dem die Aktualisierung durchgeführt wird.
- Melden Sie sich als Root oder Superuser an.
su -
- Synchronisieren Sie alle gemeinsam genutzten Komponenten auf Release 5, sofern dies noch nicht erfolgt ist.
Anweisungen hierzu erhalten Sie unter Chapter 2, "Aktualisieren der gemeinsam genutzten Java ES-Komponenten".
Dieser Schritt ist eine erforderliche Voraussetzung für die Ausführung des Skripts psupgrade in Step 8.
- Stoppen Sie etwaige Instanzen von Portal Server Secure Remote Access Gateway, Rewriter-Proxy oder Netlet-Proxy, die möglicherweise lokal ausgeführt werden.
PortalServer6-base/bin gateway stop
PortalServer6-base/bin netletd stop
PortalServer6-base/bin rwproxyd stopÜberprüfen Sie, ob die Prozesse angehalten wurden:
Gateway: netstat -an | grep 443
Rewriter Proxy: netstat -an | grep 10443
Netlet Proxy netstat -an | grep 10555- Vergewissern Sie sich, dass Access Manager ausgeführt wird, wenn es in einem anderen Webcontainer bereitgestellt wird als dem, in dem Portal Server bereitgestellt wird.
- Starten Sie Portal Server, sofern es nicht bereits ausgeführt wird, indem Sie den Webcontainer starten, in dem es bereitgestellt wird.
Webserver 6.x:
WebServer-base/https-instanceName/startWebserver 7.0:
Admin Server--
WebServer7Config-base/admin-server/bin/startserv
Instance Server--
WebServer7Config-base/https-configName/bin/startservAnwendungsserver 8.x:
AppServer8-base/bin/asadmin start-domain --user admin_ID
--password password domainName- Setzen Sie die zwei Umgebungsvariablen (ANT_HOME und JAVA_HOME), die vom Skript psupgrade benötigt werden. Beispiel:
export ANT_HOME=/opt/sun
export JAVA_HOME=/usr/jdk/entsys-j2se- Stellen Sie sicher, dass auf Ihrem Computer ausreichend Swap-Speicher zur Verfügung steht.
Der Swap-Speicher sollte grundsätzlich die doppelte Größe des physikalischen RAM aufweisen.
- Führen Sie das Skript psupgrade über die Java ES Release 5-Bereitstellung aus.
cd os_arch/Products/portal_svr/Tools/upgrade/bin
./psupgradewobei os_arch der Plattform entspricht, wie z. B. Linux_x86.
Das Skript psupgrade erkennt installierte Portal Server-Komponenten und Lokalisierungspakete, ruft das Java ES-Installationsprogramm auf, um neue Pakete zu installieren und weist das System an, Speicherort, Anschlussnummer und andere Informationen zum Webcontainer zu erkennen, in dem Sie Portal Server-Webanwendungen bereitstellen. Je nach Webcontainer-Aktualisierungsszenario (siehe Tabelle 15-4) fordert das Skript Sie auf, zusätzliche Informationen einzugeben, die für die Bereitstellung von Portal Server für den entsprechenden Webcontainer erforderlich sind.
Tabelle 15-6 enthält die Informationen, die für die verschiedenen Webcontainer-Aktualisierungsszenarien in Tabelle 15-4 erforderlich sind.
- Ändern Sie die Konfigurationsdatei PortalServer7Config-base/platform.conf.default.
Kopieren Sie die Zeile mit gateway.logging.password aus der folgenden, von psupgrade gesicherten Datei:
PortalServer6Config-base.bak/platform.conf.default
und platzieren Sie die Zeile in PortalServer7Config-base/platform.conf.default.
- Stellen Sie gegebenenfalls die JVM-Einstellungen des Webcontainers wieder her.
Um sicherzustellen, dass die JVM-Einstellungen Portal Server Release 5 unterstützen, führen Sie die folgenden Schritte durch:
- Stellen Sie sicher, dass die JVM-Einstellungen des Webcontainers für Portal Server, die Sie vor der Aktualisierung aufgezeichnet haben, nicht im Laufe der Aktualisierung geändert wurden.
Siehe auch Aufzeichnen der Java Virtual Machine (JVM)-Einstellungen.
- Wenn die Änderungen geändert wurden, stellen Sie die Werte wieder her, die Sie vor der Aktualisierung aufgezeichnet haben.
Vergewissern Sie sich, dass die folgenden JVM-Einstellungen enthalten sind, selbst wenn sie zuvor nicht eingerichtet wurden:
<jvm-options>-XX:MaxPermSize=256m</jvm-options>
<jvm-options>-XX:+CMSPermGenSweepingEnabled</jvm-options>
<jvm-options>-XX:+CMSClassUnloadingEnabled</jvm-options>- Halten Sie den Webcontainer an und starten Sie ihn erneut.
Ein Neustart des Webcontainers ist zwar nicht in jedem Fall erforderlich, dadurch wird jedoch sichergestellt, dass der Status von Portal Server beim Start eindeutig ist.
- Halten Sie den Webcontainer wie folgt an:
Webserver 6.x:
WebServer-base/https-instanceName/stopWebserver 7.0:
Admin Server--
WebServer7Config-base/admin-server/bin/stopserv
Instance Server--
WebServer7Config-base/https-configName/bin/stopservAnwendungsserver 8.x:
AppServer8-base/bin/asadmin stop-domain --user admin_ID
--password password domainName- Starten Sie den Webcontainer mit den Befehlen in Step 5 neu.
Überprüfen der Aktualisierung
Sie können die Installation der Pakete von Release 5 mithilfe des folgenden Befehls überprüfen:
Ausgabewerte finden Sie in Tabelle 15-5.
Zur Überprüfung der gesamten Aktualisierung vergewissern Sie sich, dass der Portal-Desktop angezeigt wird und das Administrationsprogramm psadmin wie dokumentiert funktioniert.
Sie können außerdem die folgenden Aktualisierungs-Protokolldateien überprüfen:
Aufgaben nach der Aktualisierung von Release 4
Beachten Sie die für die folgenden Situationen erforderlichen Aufgaben nach der Aktualisierung:
Migrieren von benutzerdefinierten web-src-Daten
Wenn Sie benutzerdefinierte Dateien wie z. B. Bilder, Javascript-Dateien oder andere Dateien für das Konstruieren von portal.war dem folgenden Verzeichnis hinzugefügt haben:
PortalServer6-base/web-src
müssen Sie diese zusätzlichen Dateien in das entsprechende Verzeichnis in Portal Server Release 5 kopieren:
PortalServer7-base/web-src
Erneutes Bereitstellen von benutzerdefinierten Portlet-Anwendungen
Wenn Sie benutzerdefinierte Portlet-Anwendungen erstellt und bereitgestellt haben, müssen diese Portlets Portal Server Release 5 nach der Aktualisierung manuell erneut bereitgestellt werden. Zwar sind Anzeige-Profileinträge vorhanden und der Kanalname wird angezeigt, der Inhalt ist jedoch erst zu sehen, nachdem Sie die benutzerdefinierten Portlets erneut bereitgestellt haben.
Stellen Sie die Portlets mit dem folgenden Befehl erneut bereit:
PortalServer7-base/bin/psadmin deploy-portlet
Sie können die erneute Bereitstellung überprüfen, indem Sie die entsprechenden .war- und XML-Dateien im folgenden Verzeichnis suchen:
PortalServer7Data-base/portals/Upgraded/war
Migrieren von benutzerdefinierten Portlet-Anwendungen
Portlet-Anwendungen, die auf dem von Sun Java Web Console (SJWC) gelieferten Benutzerschnittstellen-Framework basieren, müssen manuell in Release 5 migriert und erneut bereitgestellt werden.
Diese Anforderung betrifft insbesondere vier Webanwendungen, die mit Portal Server als Beispiel-Portlet-Anwendungen verteilt werden, welche dazu gedacht sind, angepasst und in einem Portal installiert zu werden: filesharing, surveys, wiki, rssportlet. Bei der Aktualisierung werden fehlerkorrigierte Versionen dieser Beispiel-Portlet-Anwendungen im Bereich der Portlet-Anwendungen auf dem Datenträger platziert. Wenn Sie diese Portlet-Anwendungen für Ihren Gebrauch angepasst haben, müssen Sie sie manuell in Release 5 migrieren und erneut bereitstellen; sie werden nicht vom Portal Server-Aktualisierungsprozess erfasst.
Standardmäßig werden einige dieser Portlet-Anwendungen (filesharing und surveys) bereitgestellt und dem Benutzer zugänglich gemacht, wenn eine Community erstellt wird.
Sie können SJWC-basierende Portlet-Anwendungen folgendermaßen aktualisieren, anpassen und erneut bereitstellen. Die Portlet-Anwendung filesharing dient hierbei als Beispiel:
- Extrahieren Sie die SJWC-JAR-Dateien von Release 5.
- mkdir /tmp/lh
- cd /tmp/lh
- /usr/jdk/entsys-j2se/bin/jar xvf PortalServer7-base/portlet/communityportlets.war
WEB-INF/lib/commons-beanutils.jar
WEB-INF/lib/commons-collections-3.1.jar
WEB-INF/lib/commons-digester.jar
WEB-INF/lib/commons-logging.jar
WEB-INF/lib/dataprovider.jar WEB-INF/lib/jsf-api.jar
WEB-INF/lib/jsf-impl.jar WEB-INF/lib/webui.jar- Benennen Sie eine dieser Dateien um.
mv WEB-INF/lib/commons-collections-3.1.jar
WEB-INF/lib/commons-collections.jar- Suchen Sie die Portlet-Anwendung filesharing.
cd PortalServer7Config-base/portals/portal1/portletapps/filesharing
- Geben Sie die aktualisierten SJWC-Bibliotheken ein.
jar uvf src/filesharing.war.tokenized -C /tmp/lh WEB-INF
- Passen Sie die Portlet-Anwendung filesharing an.
ant customize
- Stellen Sie die Portlet-Anwendung filesharing erneut bereit.
- PortalServer7-base/bin/psadmin undeploy-portlet -u amadmin
-f passwordfile -p portal_id -i instance_id -g filesharing- ant deploy
- Gehen Sie zum folgenden Verzeichnis (je nach Webcontainer):
Anwendungsserver 8.x:
AppServer8Config-base/domains/domain1/applications/j2ee-modules/
communityportlets/WEB-INFWebserver 6.x:
WebServer6-base/https-instanceName/webapps/https-instanceName/
communityportlets/WEB-INFWebserver 7.x:
WebServer7Config-base/https-configName/web-app/https-configName/
communityportlets/WEB-INF- Öffnen Sie die Datei sun-web.xml und fügen Sie unmittelbar vor der letzten Zeile (d. h. vor dem End-Tag sun-web-app) die folgende Zeile hinzu:
<class-loader delegate="false"/>
- Wiederholen Sie Step 2 bis Step 5 für surveys und alle weiteren auf dem SJWC-Framework basierenden benutzerdefinierten Portlet-Anwendungen.
- Starten Sie den Webcontainer neu.
Korrigieren Sie die Verknüpfungen in den Lesezeichen und Anwendungskanälen
Wenn Sie von Portal Server Release 4 auf Release 5 aktualisieren, entstehen in den Lesezeichen- und Anwendungskanälen doppelte und falsche Verknüpfungen. Gehen Sie folgendermaßen vor, um diese Verknüpfungen zu korrigieren.
- Melden Sie sich bei PSConsole an.
- Klicken Sie auf der Registerkarte Allgemeine Aufgaben“ auf Kanäle und Container verwalten“.
- Wählen Sie DeveloperSample [Org]“ als DN aus, und klicken Sie auf OK.
- Wählen Sie JSPTabContainer [default]“ als Ansichtstyp aus.
- Klicken Sie unter MyFrontPageTabPanelContainer“ auf Anwendungskanal“.
Im rechten Bereich werden die Eigenschaften des Anwendungskanals angezeigt.
Um die Eigenschaften für ein bestimmtes Gebietsschema anzuzeigen, zeigen Sie die Tabelleneinstellungen an, und geben Sie den entsprechenden Wert ein: de, fr, es, ja, ko, zh, zh_CN, zh_TW.
- Bearbeiten Sie die Eigenschaft userApps“.
- Klicken Sie dort auf die Verknüpfung [Werte bearbeiten...]“.
Ein Popup-Fenster mit den vorhandenen Anwendungen wird angezeigt.
- Entfernen Sie die folgenden Anwendungen aus der Liste:
NetMail Lite
NetMail- Fügen Sie die folgende Anwendung der Liste hinzu:
NetFile
- Klicken Sie auf Speichern“ und anschließend auf Schließen“.
- Bearbeiten Sie die Zieleigenschaft
- Klicken Sie dort auf die Verknüpfung [Werte bearbeiten...]“.
Ein Popup-Fenster mit den vorhandenen Zielen wird angezeigt.
- Entfernen Sie die folgenden Ziele aus der Liste:
NetMailLite|
NetMailServlet?nsid=newHTMLSessionNetMailLite|
NetMailServlet?nsid=newHTMLSessionNetMail|NetMailServlet?nsid=newAppletSession
- Entfernen Sie das doppelte Auftreten der folgenden Ziele:
Instant Messenger (Java WebStart)|
IMLaunch?provider=IMChannel&launch=jnlp&last=falseRichtiger Zugriff auf den Suchserver
Bei der Aktualisierung von Portal Server Release 4 auf Release 5 wird der Suchserver von Portal Server getrennt, wodurch sich der URL-Zugriff auf diesen Server ändert.
Daher müssen Sie die Anzeigeprofile zu allen Portalkanälen (z. B. Search, DiscussionLite, Discussions und den Instant Messaging-Kanal) aktualisieren, die die Schnittstellen SearchProvider oder DiscussionProvider implementieren. Sie müssen insbesondere die Eigenschaft searchServer dieser Kanäle im Hinblick darauf ändern, auf welcher organisatorischen oder Rollenebene sie im Anzeigeprofil auftreten, um den Suchserver ordnungsgemäß zu referenzieren. Ändern Sie den Wert searchServer folgendermaßen:
Für den Instant Messaging-Kanal muss außerdem die Instant Messaging-Serverkonfigurationseigenschaft iim_arch.portal.search mit der neuen URL des Suchservers aktualisiert werden.
Konfiguration wiederherstellen von Directory Proxy Server
Wenn Portal Server-Instanzen über eine Directory Proxy Server-Instanz auf Directory Server zugegriffen haben, müssen die ursprünglichen Werte der Directory Proxy Server-Host- und Anschlussnummerneinstellungen vor dem Aktualisieren wiederhergestellt werden. Siehe Konfiguration entfernen von Directory Proxy Server; hier wurden die Werte dieser Eigenschaften als Vorbereitung auf die Aktualisierung geändert.
Manuelles Registrieren von Portal Server Secure Remote Access-Komponenten
Wenn ein Null Pointer-Ausnahmefehler auftritt, der an der Standardausgabe am Ende des Aktualisierungsverfahrens gemeldet wird, bedeutet dies, dass die Registrierung der Portal Server Secure Remote Access-Komponenten, sofern vorhanden, fehlgeschlagen ist.
In dieser Situation können Sie die Portal Server Secure Remote Access-Komponenten durch Ausführen des folgenden Befehls manuell registrieren (aktivieren):
PortalServer7-base/bin/psadmin provision-sra -u amadminUser -f passwordFile
-p Portal_ID --gateway-profile profileName --enableAktivieren des URLScrapper-Kanals
Beim Aktualisieren von Release 4 auf Release 5 müssen Sie den URLScrapper-Kanal aktivieren. Gehen Sie folgendermaßen vor:
- Melden Sie sich bei der Portal Server-Konsole an.
Klicken Sie auf die Registerkarte "Portal" und anschließend auf das aktualisierte Portal.
- Wählen Sie aus dem Dropdown-Menü "Select DN" (DN auswählen) die Option "TopLevel (Global)" (Obere Ebene (Global)) und klicken Sie auf die Verknüpfung "Download Display Profile" (Anzeigeprofil herunterladen).
Speichern Sie die heruntergeladene Datei an einem temporären Speicherort.
- Suchen Sie com.sun.portal.providers.urlscraper.URLScraperProvider.
- Suchen Sie den XML-Teil, der folgendermaßen beginnt:
<Provider advanced="false" class="com.sun.portal.providers.urlscraper.URLScraperProvider"
und folgendermaßen endet:
</Provider>
- Ersetzen Sie den XML-Teil in Step 4 mit der folgenden Angabe:
<Provider advanced="false" class="com.sun.portal.providers.urlscraper.URLScraperProvider" container="false" lock="false" merge="fuse" name="URLScraperProvider" version="2">
<Properties advanced="false" lock="false" merge="fuse" name="_properties" propagate="true">
<String advanced="false" lock="false" merge="replace" name="title" propagate="true" value="UrlScraper Channel"/>
<String advanced="false" lock="false" merge="replace" name="description" propagate="true" value="This is a test for urlscraper"/>
<Boolean advanced="true" lock="false" merge="replace" name="isEditable" propagate="true" value="false"/>
<Boolean advanced="true" lock="false" merge="replace" name="isTopLevel" propagate="true" value="false"/>
<String advanced="true" lock="false" merge="replace" name="editType" propagate="true" value="edit_subset"/>
<Boolean advanced="true" lock="false" merge="replace" name="enableUBT" propagate="true" value="false"/>
<String advanced="false" lock="false" merge="replace" name="urlScraperRulesetID" propagate="true" value="default_ruleset"/>
<String advanced="false" lock="false" merge="replace" name="width" propagate="true" value="thick"/>
<String advanced="true" lock="false" merge="replace" name="refreshTime" propagate="true" value="0"/>
<String advanced="true" lock="false" merge="replace" name="helpURL" propagate="true" value="en/desktop/urlscrpr.htm"/>
<String advanced="false" lock="false" merge="replace" name="url" propagate="true" value=""/>
<String advanced="false" lock="false" merge="replace" name="fontFace1" propagate="true" value="Sans-serif"/>
<String advanced="false" lock="false" merge="replace" name="productName" propagate="true" value="Sun JavaTM System Portal Server 7"/>
<Boolean advanced="false" lock="false" merge="replace" name="cookiesToForwardAll" propagate="true" value="true"/>
<String advanced="false" lock="false" merge="replace" name="inputEncoding" propagate="true" value="UTF-8"/>
<Collection advanced="false" lock="false" merge="fuse" name="cookiesToForwardList" propagate="true"/>
<Integer advanced="false" lock="false" merge="replace" name="timeout" propagate="true" value="100"/>
<String advanced="true" lock="false" merge="replace" name="formData" propagate="true" value=""/>
<Boolean advanced="true" lock="false" merge="replace" name="isHttpAuth" propagate="true" value="false"/>
<String advanced="true" lock="false" merge="replace" name="loginUrl" propagate="true" value=""/>
<String advanced="true" lock="false" merge="replace" name="loginFormData" propagate="true" value=""/>
<String advanced="true" lock="false" merge="replace" name="uid" propagate="true" value=""/>
<String advanced="true" lock="false" merge="replace" name="password" propagate="true" value=""/>
<ConditionalProperties advanced="false" condition="client" lock="false" merge="fuse" propagate="true" value="HTML">
<ConditionalProperties advanced="false" condition="locale" lock="false" merge="fuse" propagate="true" value="en">
<String advanced="true" lock="false" merge="replace" name="helpURL" propagate="true" value="en/desktop/urlscrpr.htm"/>
<String advanced="false" lock="false" merge="replace" name="url" propagate="true" value=""/>
</ConditionalProperties>
<String advanced="true" lock="false" merge="replace" name="helpURL" propagate="true" value="en/desktop/urlscrpr.htm"/>
<String advanced="false" lock="false" merge="replace" name="url" propagate="true" value=""/>
</ConditionalProperties>
<ConditionalProperties advanced="false" condition="locale" lock="false" merge="fuse" propagate="true" value="en">
<String advanced="false" lock="false" merge="replace" name="title" propagate="true" value="UrlScraper Channel"/>
<String advanced="false" lock="false" merge="replace" name="description" propagate="true" value="This is a test for urlscraper"/>
</ConditionalProperties>
</Properties>
</Provider>
- Speichern Sie die geänderte Datei und laden Sie sie hoch.
Vornehmen von Änderungen in der Abmeldeseite
Die Abmeldeseite in Portal Server Release 5 hat sich gegenüber der vorherigen Access Manager-Abmeldeseite geändert. Beachten Sie, dass diese Änderung keinen Fehler in der Software darstellt.
Aufheben der Aktualisierung (Solaris)
Dieser Abschnitt enthält eine Beschreibung der Aspekte, die Einfluss auf das Verfahren zum Aufheben der Aktualisierung Portal Server haben, sowie eine Beschreibung des eigentlichen Verfahrens zum Aufheben der Aktualisierung.
Zu berücksichtigende Aspekte beim Aufheben der Aktualisierung (Solaris)
Beim Aufheben der Aktualisierung auf Release 5 wird die Installation von Release 4 in PortalServer6-base wiederhergestellt und die Webanwendungen von Release 4 werden erneut bereitgestellt.
Verfahren zum Aufheben der Aktualisierung (Solaris)
- Melden Sie sich als Root oder Superuser an.
su -
- Stellen Sie den Zustand von Directory Server vor der Aktualisierung wieder her.
Verwenden Sie die Directory Server-Sicherungs-/Wiederherstellungs-Befehlszeile und die GUI-Programme. Lesen Sie hierzu das Kapitel zum Sichern und Wiederherstellen von Directory Server im Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide, http://docs.sun.com/doc/819-0995.
- Beenden Sie Portal Server, indem Sie seinen Webcontainer beenden.
Webserver 6.x:
WebServer-base/https-instanceName/stopWebserver 7.0:
Admin Server--
WebServer7Config-base/admin-server/bin/stopserv
Instance Server--
WebServer7Config-base/https-configName/bin/stopservAnwendungsserver 8.x:
AppServer8-base/bin/asadmin stop-domain --user admin_ID
--password password domainName- Entfernen Sie die Portal Server Release 5-Pakete.
- Starten Sie Portal Server neu, indem Sie seinen Webcontainer neu starten.
Webserver 6.x:
WebServer-base/https-instanceName/startWebserver 7.0:
Admin Server--
WebServer7Config-base/admin-server/bin/startserv
Instance Server--
WebServer7Config-base/https-configName/bin/startservAnwendungsserver 8.x:
AppServer8-base/bin/asadmin start-domain --user admin_ID
--password password domainName- Stellen Sie die Webanwendungen von Portal Server Release 4 erneut bereit. Verwenden Sie hierzu den folgenden Befehl aus der Java ES Release 5-Verteilung:
cd os_arch/Products/portal_svr/Tools/upgrade/bin
./psupgrade rollbackwobei os_arch der Plattform entspricht, wie z. B. Solaris_sparc.
Mit dem Befehl psupgrade rollback wird die Bereitstellung der Webanwendungen von Portal Server Release 5 aufgehoben und die Webanwendungen von Portal Server Release 4 werden erneut bereitgestellt.
Mit dem Befehl wird der Inhalt aus PortalServer6-base/web-src in /var/PortalServe6-base/https-hostName/deploy-dir/web-apps erneut bereitgestellt. Anpassungen der Portal Server-Webanwendung sollten daher zuerst in /web-src vorgenommen und anschließend in /web-apps bereitgestellt werden. Änderungen, die Sie unter /web-apps vornehmen, sollten in /web-src repliziert werden, bevor Sie den psupgrade rollback-Befehl ausführen. Andernfalls werden diese Änderungen überschrieben.
- Halten Sie den Webcontainer an und starten Sie ihn erneut.
Ein Neustart des Webcontainers ist zwar nicht in jedem Fall erforderlich, dadurch wird jedoch sichergestellt, dass der Status von Portal Server beim Start eindeutig ist.
Aufheben der Aktualisierung (Linux)
Da für die Aktualisierung auf Release 5 die binären Release 4-Dateien entfernt werden müssen, ist das Aufheben der Aktualisierung unter Linux sehr aufwändig.
Eine Möglichkeit zum Aufheben der Aktualisierung besteht darin, vor der Aktualisierung ein paralleles System zu erstellen und dieses System vor der Aktualisierung zu testen. Wenn Sie die Aktualisierung aufheben müssen, können Sie zu diesem parallelen System zurückkehren.
Aktualisierung mehrerer Instanzen
In manchen Bereitstellungsarchitekturen wird Portal Server auf mehreren Computersystemen bereitgestellt, um die Skalierbarkeit zu gewährleisten und die Verfügbarkeit zu verbessern. Möglicherweise führen Sie beispielsweise Portal Server-Instanzen auf mehreren Computern zusammen mit einem Lastenausgleichsprogramm aus, um die Last zu verteilen.
Für Portal Server-Instanzen mit Lastenausgleich können Sie ein sogenanntes Rolling Upgrade durchführen, bei dem Sie alle Portal Server-Instanzen nacheinander aktualisieren, ohne den Dienst zu unterbrechen, wie nachstehend beschrieben. Für dieses Verfahren gelten folgende Einschränkungen: Portal Server Release 4 funktioniert nicht mit Verzeichnisdaten aus Portal Server Release 5.
Die in Abbildung 15-1 dargestellte Bereitstellungsarchitektur dient zur Demonstration eines Rolling Upgrade der Portal Server Release 4-Instanzen auf Release 5.
Hinweis
Informationen zu Architekturen, die Portal Server Secure Remote Access-Komponenten enthalten, finden Sie unter Aktualisierung mehrerer Instanzen.
In der in Abbildung 15-1 dargestellten Architektur erfolgt der Zugriff auf mehrere Portal Server-Instanzen über einen Lastenausgleich, um Verfügbarkeit und Skalierbarkeit zu gewährleisten. Die Portal Server-Instanzen greifen wiederum über einen Lastenausgleich auf die Access Manager-Instanzen zu. Die Access Manager- und Access Manager-SDK-Instanzen greifen auf ein Verzeichnis zu, das für die Multimaster-Replikation (MMR) eingerichtet wurde. Während andere Directory Server-Replikationsschemata möglich sind, ist MMR repräsentativ für hochverfügbare und skalierbare Directory-Dienste.
In Abbildung 15-1 werden die verschiedenen Instanzen von Portal Server, Access Manager und Directory Server gruppiert dargestellt, um die Erklärung des Aktualisierungsvorgangs zu erleichtern. Portal Server 2 stellt beispielsweise die zweite bis n-te Instanz von Portal Server dar.
Abbildung 15-1 Beispiel für Bereitstellungsarchitektur für mehrere Portal Server-Instanzen
Das Rolling Upgrade von Portal Server Release 4 auf Release 5 wird folgendermaßen durchgeführt:
- Wenn Sie von Access Manager Release 4 auf Release 5 aktualisieren, führen Sie ein Rolling Upgrade durch, wie unter Aktualisierung mehrerer Instanzen beschrieben. Wenn Sie Portal Server Release 4 auf Release 5 aktualisieren, brauchen Sie Access Manager Release 4 nicht auf Release 5 zu aktualisieren.
- Konfigurieren Sie Portal Server 2 mit einem Verweis auf Directory Server 2 statt auf Directory Server 1.
Um die Anweisungen zu verkürzen, bedeutet Portal Server 2“ in den folgenden Schritten Portal Server 2 bis Portal Server n.
- Aktualisieren Sie Portal Server 1.
- Deaktivieren Sie Portal Server 1 im Lastenausgleichsprogramm B.
Anfragen werden nicht mehr an Portal Server 1 weitergeleitet.
- Deaktivieren Sie Directory Server MMR.
Directory Server 2 wird nicht mehr mit Directory Server 1 synchronisiert.
- Aktualisieren Sie Access Manager SDK 1B auf Release 5.
Führen Sie hierzu das unter Ausschließliche Aktualisierung der Release 4-Version von Access Manager SDK beschriebene Verfahren durch.
- Aktualisieren Sie Portal Server 1 auf Release 5.
Führen Sie die Aktualisierung der Portal Server-Instanz wie unter Aktualisierung der Release 4-Version von Portal Server beschrieben durch, und achten Sie dabei auf Folgendes:
- Die folgende Aufgabe muss vor der Aktualisierung durchgeführt werden: Konfiguration des Lastenausgleichsprogramms entfernen.
- Vergewissern Sie sich vor der Durchführung der Aktualisierung, dass der Wert am.encryption.pwd in der Datei AccessManagerConfig-base/config/AMConfig.properties im lokalen Access Manager-SDK sowie dessen zugeordneter Access Manager-Remote-Instanz identisch ist.
- Achten Sie darauf, einen einmaligen Wert, der nicht Null lautet, für den von psupgrade benötigten Parameter Portal Instance ID für jede zu aktualisierende Portal Server-Instanz anzugeben.
Die Portal Server-Daten für Directory Server 1 werden auf Release 5 aktualisiert.
- Aktivieren Sie Portal Server 1 im Lastenausgleichsprogramm B.
Anfragen werden wieder an Portal Server 2 weitergeleitet.
- Aktualisieren Sie Portal Server 1.
- Deaktivieren Sie Portal Server 1 im Lastenausgleichsprogramm B.
Anfragen werden nicht mehr an Portal Server 2 weitergeleitet.
- Stellen Sie die Konfiguration von Portal Server 1 wieder her, sodass auf Directory Server 1 verwiesen wird.
- Aktualisieren Sie Access Manager SDK 1B auf Release 5.
Verwenden Sie dasselbe Verfahren wie unter Step c.
- Aktualisieren Sie Portal Server 2 auf Release 5.
Verwenden Sie dasselbe Verfahren wie unter Step d.
- Aktivieren Sie Portal Server 1 im Lastenausgleichsprogramm B.
Anfragen werden wieder an Portal Server 2 weitergeleitet.
- Aktivieren Sie Directory Server MMR.
Die Portal Server-Daten für Directory Server 2 werden nun mit Directory Server 1 synchronisiert.
Aktualisieren von Portal Server von Java ES Release 3Die Vorgehensweise für die Aktualisierung von Java ES 2005Q1 (Release 3) Portal Server auf Release 5 ist abgesehen von den folgenden Ausnahmen mit der Aktualisierung von Release 4 Portal Server auf Release 5 identisch.
Aufgabe vor der Aktualisierung von Release 3: Aktualisieren der Portal Server-Abhängigkeiten
Bei der Aktualisierung von Portal Server von Release 3 müssen Sie jedoch sowohl Access Manager als auch die Webcontainer (Webserver oder Anwendungsserver) auf Release 4 oder Release 5 aktualisieren, bevor Sie Portal Server aktualisieren. Sie können weder Abhängigkeiten in Release 3 belassen noch bestimmte Abhängigkeiten auf Release 4 und andere auf Release 5 aktualisieren. Weitere Informationen finden Sie unter Selektive Aktualisierung.
Die folgenden Abhängigkeiten müssen in der unten gezeigten Reihenfolge aktualisiert werden.
- Gemeinsam genutzte Komponenten. Anweisungen zur Aktualisierung der gemeinsam genutzten Java ES-Komponenten auf Release 5 finden Sie in Chapter 2, "Aktualisieren der gemeinsam genutzten Java ES-Komponenten".
- Directory Server. Anweisungen zur Aktualisierung von Directory Server auf Release 5 finden Sie in Chapter 5, "Directory Server".
- Webcontainer-Software. Anweisungen zur Aktualisierung von Webserver und Anwendungsserver finden Sie in Chapter 7, "Webserver" bzw. Chapter 11, "Anwendungsserver".
- Access Manager (Access Manager SDK). Anweisungen zur Aktualisierung von Access Manager auf Release 5 finden Sie in Chapter 14, "Access Manager".
Aktualisieren von Release 3 Portal Server
Um die Release 3-Version von Portal Server auf Release 5 zu aktualisieren, folgen Sie den Anweisungen unter Aktualisieren von Portal Server von Java ES Release 4. Ersetzen Sie in den Anweisungen jedoch Verweise auf Release 4 durch Release 3.
Aufgaben nach der Aktualisierung von Release 3
Bei der Aktualisierung von Portal Server von Release 3 auf Release 5 müssen Sie zusätzlich zu den unter Aufgaben nach der Aktualisierung von Release 4 beschriebenen Verfahren nach der Aktualisierung die Verfahren für die folgenden Situationen durchführen:
Abonnieren einer Diskussion
Das Abonnieren einer Diskussion in einer Community erfolgt erst dann erfolgreich, wenn Sie die Eigenschaften der obersten Ebene des globalen Anzeigeprofils bearbeitet haben, um die folgende String-Eigenschaft hinzuzufügen:
helpURL=en/desktop/usedesk.htm
Gehen Sie folgendermaßen vor:
- Erstellen Sie eine Anzeigeprofil-XML-Snippet-Datei, helpUrl.xml:
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE DisplayProfile SYSTEM "jar://resources/psdp.dtd">
<Eigenschaften>
<String name="helpURL" value="en/desktop/usedesk.htm" />
</Properties>- Führen Sie die Eigenschaften des globalen Anzeigeprofils mit dem folgenden Befehl aus:
./psadmin modify-dp -u amadminUser -f /tmp/passwordFile -p portal_ID
-m -g helpUrl.xmlDie -m-Option ist erforderlich, damit nicht das gesamte globale Anzeigeprofil überschrieben wird.
Aktualisierung mehrerer Instanzen
In manchen Bereitstellungsarchitekturen wird Portal Server auf mehreren Computersystemen bereitgestellt, um die Skalierbarkeit zu gewährleisten und die Verfügbarkeit zu verbessern. Möglicherweise führen Sie beispielsweise Portal Server-Instanzen auf mehreren Computern zusammen mit einem Lastenausgleichsprogramm aus, um die Last zu verteilen.
Für Portal Server-Instanzen mit Lastenausgleich können Sie ein sogenanntes Rolling Upgrade durchführen, bei dem Sie alle Portal Server-Instanzen nacheinander aktualisieren, ohne den Dienst zu unterbrechen, wie nachstehend beschrieben. Für dieses Verfahren gelten folgende Einschränkungen: Portal Server Release 3 funktioniert nicht mit Verzeichnisdaten aus Portal Server Release 5.
Zur Durchführung eines Rolling Upgrade von Portal Server Release 3 auf Release 5 gehen Sie wie unter Aktualisierung mehrerer Instanzen beschrieben vor. Ersetzen Sie in den Anweisungen jedoch Verweise auf Release 4 durch Release 3. Außerdem müssen Sie Access Manager aktualisieren, wie unter Step 1 beschrieben.
Aktualisieren von Portal Server von Java ES Release 2Dieser Abschnitt enthält Informationen zum Aktualisieren von Java ES 2004Q2 (Release 2) Portal Server auf Release 5. Das Aktualisierungsverfahren ähnelt dem für das Aktualisieren von Release 4 Portal Server auf Release 5 mit Ausnahme von einigen Änderungen, die in den nachfolgenden Abschnitten erläutert sind:
Hinweis
Wenn Sie von Portal Server Release 2 auf der Linux-Plattform aktualisieren, müssen Sie eine duale Aktualisierung durchführen, bei der Portal Server und das Betriebssystem aktualisiert werden (Portal Server Release 5 wird auf RHEL 2.1 nicht unterstützt). Weitere Informationen finden Sie unter Duale Aktualisierung.
Aufgaben vor der Aktualisierung von Release 2
Die Aufgaben vor der Aktualisierung von Portal Server von Release 2 sind mit den in Aufgaben vor der Aktualisierung von Release 4 beschriebenen identisch, mit Ausnahme der Aktualisierung der Portal Server-Abhängigkeiten.
Bei der Aktualisierung von Portal Server von Release 2 müssen Sie sowohl Access Manager als auch die Webcontainer (Webserver oder Anwendungsserver) auf Release 4 oder Release 5 aktualisieren, bevor Sie Portal Server aktualisieren. Sie können weder Abhängigkeiten in Release 2 belassen noch bestimmte Abhängigkeiten auf Release 4 und andere auf Release 5 aktualisieren. Weitere Informationen finden Sie unter Selektive Aktualisierung.
Insbesondere muss die Webcontainer-Software von Release 2 aktualisiert werden, was bedeutet, dass nur Szenario 2 und Szenario 5 in Tabelle 15-4 bei Ausführung des Skripts psupgrade unterstützt werden.
Die folgenden Abhängigkeiten müssen in der unten gezeigten Reihenfolge aktualisiert werden.
- Gemeinsam genutzte Komponenten. Anweisungen zur Aktualisierung der gemeinsam genutzten Java ES-Komponenten auf Release 5 finden Sie in Chapter 2, "Aktualisieren der gemeinsam genutzten Java ES-Komponenten".
- Directory Server. Anweisungen zur Aktualisierung von Directory Server auf Release 5 finden Sie unter Aktualisieren von Directory Server von Java ES Release 2.
- Webcontainer-Software. Anweisungen zur Aktualisierung von Webserver und Anwendungsserver finden Sie in Chapter 7, "Webserver" bzw. Chapter 11, "Anwendungsserver".
- Access Manager (Access Manager SDK). Anweisungen zur Aktualisierung von Access Manager auf Release 5 finden Sie in Chapter 14, "Access Manager".
Aktualisieren von Release 2 Portal Server
Das Verfahren für die Aktualisierung von Portal Server Release 2 auf Release 5 hängt von dem Webcontainer ab, in dem die Portal Server-Software bereitgestellt werden soll, wie in den nachfolgenden Abschnitten beschrieben.
Aktualisieren der Release 2-Version von Portal Server: Webserver-Webcontainer
Um die Release 2-Version von Portal Server auf Release 5 zu aktualisieren, wobei die Bereitstellung in einem Webserver-Webcontainer erfolgt, folgen Sie den Anweisungen unter Aktualisieren von Portal Server von Java ES Release 4. Ersetzen Sie in den Anweisungen jedoch Verweise auf Release 4 durch Release 2.
Wenn Portal Server jedoch in Webserver Release 5 (Webserver 7.0) bereitgestellt wird, müssen Sie vor der Aktualisierung von Webserver Release 2 die folgenden Schritte durchführen:
- Melden Sie sich bei der Webserver-Konsole an.
- Klicken Sie auf "Edit Virtual Servers" (Virtuelle Server bearbeiten) > "Web Applications" (Web-Anwendungen).
- Entfernen Sie alle bereitgestellten Webanwendungen mit einer URI, die /portal oder /portalsamples
- Klicken Sie auf "Speichern".
- Klicken Sie auf "Deployment Pending" (Bereitstellung ausstehend).
Aktualisieren der Release 2-Version von Portal Server: Anwendungsserver-Webcontainer
Bei der Aktualisierung von Portal Server Release 2 auf Release 5 wurde der Anwendungsserver bei einer Bereitstellung in einem Anwendungsserver-Webcontainer von Release 2 auf Release 5 aktualisiert.
Die Anwendungsserver-Instanz von Release 2, in der Portal Server ursprünglich bereitgestellt wurde (instanceName), wurde bei der Aktualisierung auf Release 5 in einen vom Anwendungsserver-Aktualisierungsvorgang erstellten Knotenagenten migriert. Für die Aktualisierung von Portal Server in dieser aktualisierten Anwendungsserver-Instanz sind folgende Schritte erforderlich:
- Melden Sie sich als Root oder Superuser an.
su -
- Synchronisieren Sie alle gemeinsam genutzten Komponenten auf Release 5, sofern dies noch nicht erfolgt ist.
Anweisungen hierzu erhalten Sie unter Chapter 2, "Aktualisieren der gemeinsam genutzten Java ES-Komponenten".
Dieser Schritt ist eine erforderliche Voraussetzung für die Ausführung des Skripts psupgrade in Step 9.
- Stoppen Sie etwaige Instanzen von Portal Server Secure Remote Access Gateway, Rewriter-Proxy oder Netlet-Proxy, die möglicherweise lokal ausgeführt werden.
PortalServer6-base/bin gateway stop
PortalServer6-base/bin netletd stop
PortalServer6-base/bin rwproxyd stopÜberprüfen Sie, ob die Prozesse angehalten wurden:
Gateway: netstat -an | grep 443
Rewriter Proxy: netstat -an | grep 10443
Netlet Proxy netstat -an | grep 10555- Vergewissern Sie sich, dass Access Manager ausgeführt wird, wenn es in einem anderen Webcontainer bereitgestellt wird als dem, in dem Portal Server bereitgestellt wird.
- Starten Sie Portal Server, sofern es nicht bereits ausgeführt wird, indem Sie den Webcontainer starten, in dem es bereitgestellt wird.
- Starten Sie den Domain Administration Server (DAS), falls dieser noch nicht gestartet wurde.
AppServer8-base/bin/asadmin start-domain --user admin_ID
--password password domainName- Starten Sie die aktualisierte Anwendungsserver-Instanz, in der Portal Server bereitgestellt wurde (instanceName), wenn diese Serverinstanz nicht bereits ausgeführt wird.
Starten Sie hierfür den Knotenagenten, in den die aktualisierte Anwendungsserver-Instanz migriert wurde.
AppServer8-base/bin/asadmin start-node-agent --user admin_ID
--password password nodeagentNameIn den oben genannten Befehlen und in den folgenden Schritten werden folgende Konventionen verwendet:
- wobei nodeagentName der Form hostName_domainName entspricht, jedoch standardmäßig nur hostName lautet.
- Der Standard für domainName lautet domain1.
- Der Standard für instanceName lautet server1.
- Heben Sie die Bereitstellung der Portal Server-Komponenten auf.
AppServer8-base/bin/asadmin undeploy --user admin_ID
--password password --target instanceName portalAppServer8-base/bin/asadmin undeploy --user admin_ID
--password password --target instanceName portletsamples- Setzen Sie die zwei Umgebungsvariablen (ANT_HOME und JAVA_HOME), die vom Skript psupgrade benötigt werden. Beispiel:
Solaris OS:
export ANT_HOME=/usr/sfw
export JAVA_HOME=/usr/jdk/entsys-j2seLinux OS:
export ANT_HOME=/opt/sun
export JAVA_HOME=/usr/jdk/entsys-j2se- Stellen Sie sicher, dass auf Ihrem Computer ausreichend Swap-Speicher zur Verfügung steht.
Der Swap-Speicher sollte grundsätzlich die doppelte Größe des physikalischen RAM aufweisen.
- Führen Sie das Skript psupgrade über die Java ES Release 5-Bereitstellung aus.
cd os_arch/Products/portal_svr/Tools/upgrade/bin
./psupgradewobei os_arch der Plattform entspricht, wie z. B. Solaris_sparc.
Hinweis
Sollten Sie psupgrade versehentlich vom falschen os_arch-Verzeichnis aus gestartet haben, müssen Sie das Verfahren folgendermaßen rückgängig machen:
Das Skript psupgrade ruft das Java ES-Installationsprogramm auf, um neue Pakete zu installieren, und weist das System an, Speicherort, Anschlussnummer und andere Informationen zum Webcontainer zu erkennen, in dem Sie Portal Server-Webanwendungen bereitstellen. Je nach Webcontainer-Aktualisierungsszenario (siehe Tabelle 15-4), in diesem Fall Szenario 5, fordert das Skript Sie auf, Informationen einzugeben, die für die Bereitstellung von Portal Server für den entsprechenden Webcontainer erforderlich sind.
Tabelle 15-6 enthält die erforderlichen Informationen, wenn Anwendungsserver Release 2 auf Release 5 aktualisiert wurde (Szenario 5).
- Beenden Sie den Domain Administration Server (DAS) und den in Step 5 gestarteten Knotenagenten.
AppServer8-base/bin/asadmin stop-domain --user admin_ID
--password password domainNameAppServer8-base/bin/asadmin stop-node-agent --user admin_ID
--password password nodeagentName- Starten Sie den Domain Administration Server (DAS), den Knotenagenten und die in Step 10 angehaltene Serverinstanz neu.
Hinweis
Starten Sie den Knotenagent separat mithilfe der Option startinstances=false, bevor die Serverinstanz wie unten dargestellt gestartet wird.
AppServer8-base/bin/asadmin start-domain --user admin_ID
--password password domainNameAppServer8-base/bin/asadmin start-node-agent --port DASportNumber --startinstances=false --user admin_ID --password password nodeagentName
AppServer8-base/bin/asadmin start-instance --port DASportNumber --user admin_ID --password password instanceName
Der Standardwert für DASportNumber lautet 4848.
Aufgaben nach der Aktualisierung von Release 2
Bei der Aktualisierung von Portal Server von Release 2 auf Release 5 müssen Sie zusätzlich zu den unter Aufgaben nach der Aktualisierung von Release 4 beschriebenen Verfahren nach der Aktualisierung die Verfahren für die folgenden Situationen durchführen:
Single Sign-On-Konfiguration
Nach der Aktualisierung von Portal Server von Release 2 schlagen Desktop-Kommunikationskanäle wie Mail, Kalender und Adressbuch, die mittels der ssoadapter-Meta-Vorlage auf einen Back-End-Server zugreifen, fehl.
Wenn Sie beispielsweise die ssoadapter-Mail-Meta-Vorlage SUN-UWC-MAIL in Release 2 geändert, d. h. speziell für Ihren Messaging-Server eingestellt haben, gibt es nach der Aktualisierung auf Release 5 zwei ssoadapter-Meta-Vorlagen SUN-UWC-MAIL: Eine ist die unveränderte Version in Release 2, die andere die neue in Release 5. Doppelte ssoadapter-Meta-Vorlagen sind in der Portal Server-Konsole und der Befehlszeilenschnittstelle psadmin vorhanden; sie haben beide denselben Namen.
Kanäle, die die ssoadapter-Meta-Vorlagen verwenden, können keine Verbindung zum Back-End-Server aufbauen und Daten abrufen.
Zur Behebung dieses Problems müssen Sie die Daten der ssoadapter-Meta-Vorlagen abrufen, die doppelten Einträge umbenennen und die geänderten Daten anschließend ersetzen. Gehen Sie folgendermaßen vor:
- Exportieren Sie die Daten der ssoadapter-Meta-Vorlagen.
Verwenden Sie das Programm amadmin folgendermaßen zum Exportieren der Access Manager-Dienstdaten:
- Erstellen Sie eine amadmin-Anforderungsdatei /tmp/ssoadapter-template-gets.xml.
Diese Datei wird vom Programm zum Abrufen der Daten der ssoadapter-Meta-Vorlagen verwendet:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Requests
PUBLIC "-//iPlanet//iDSAME 5.0 Admin CLI DTD//EN"
"jar://com/iplanet/am/admin/cli/amAdmin.dtd"
>
<Requests>
<SchemaRequests serviceName="SunSSOAdapterService" SchemaType="global">
<GetServiceDefaultValues>
<Attribute name="sunConfigurationTemplates" />
</GetServiceDefaultValues>
</SchemaRequests>
</Requests>- Führen Sie folgenden asadmin-Befehl aus:
AccessManager-base/bin/amadmin -u amadminUser -w password
-t ssoadapter-templates-get.xml > /tmp/ssoadapter-templates.xmlDie Ausgabe des Befehls wird in /tmp/ssoadapter-templates.xml gespeichert.
Die Datei /tmp/ssoadapter-templates.xml hat das folgende Format:
sunConfigurationTemplates=
[<ssoadapter meta-template1>, <ssoadapter meta-template2>, ...]und jede <ssoadapter-Meta-Vorlage> hat die folgende Syntax:
default|imap:/?configName=SUN-UWC-MAIL
&proxyAdminPassword=%5BPROXY-ADMIN_PASSWORD%5D&subType=sun-one
&enableProxyAuth=false ...- Ändern Sie die Datei /tmp/ssoadapter-templates.xml, um die doppelten ssoadapter-Meta-Vorlagen umzubenennen.
- Suchen Sie alle Vorlagen in der Datei /tmp/ssoadapter-templates.xml.
Suchen Sie die Zeichenfolge default|imap:/?configName= .
- Ersetzen Sie die Namen der doppelten ssoadapter-Meta-Vorlagen durch einmalige Werte.
Wenn beispielsweise zwei ssoadapter-Meta-Vorlagen mit dem Namen SUN-UWC-MAIL vorliegen, ersetzen Sie den Wert configName einer der Vorlagen durch SUN-UWC-MAIL2. Hierdurch entstehen anschließend zwei Vorlagen mit einmaligem Namen:
default|imap:/?configName=SUN-UWC-MAIL ...
default|imap:/?configName=SUN-UWC-MAIL2 ...- Erstellen Sie eine amadmin-Anforderungsdatei, die die geänderten ssoadapter-Meta-Vorlagen importiert und die ursprünglichen Daten überschreibt.
- Kopieren Sie /tmp/ssoadapter-templates.xml in /tmp/ssoadapter-new-templates.xml
- Ersetzen Sie in /tmp/ssoadapter-new-templates.xml die Zeichenfolge:
sunConfigurationTemplates=[
durch:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Requests
PUBLIC "-//iPlanet//iDSAME 5.0 Admin CLI DTD//EN"
"jar://com/iplanet/am/admin/cli/amAdmin.dtd"
>
<Requests>
<SchemaRequests serviceName="SunSSOAdapterService" SchemaType="Global">
<ModifyDefaultValues>
<AttributeValuePair>
<Attribute name="sunConfigurationTemplates" />- Ersetzen Sie alle UND-Zeichen ("&") durch "&".
So würde beispielsweise die Zeile:
default|imap:/?configName=SUN-UWC-MAIL
&proxyAdminPassword=%5BPROXY-ADMIN_PASSWORD%5D
&subType=sun-one&enableProxyAuth=false...anschließend so aussehen:
default|imap:/?configName=SUN-UWC-MAIL
&proxyAdminPassword=%5BPROXY-ADMIN_PASSWORD%5D
&subType=sun-one&enableProxyAuth=false ...- Entfernen Sie die Kommas (",") am Ende einer jeden ssoadapter-Meta-Vorlage.
- Umbrechen Sie jede ssoadapter-Meta-Vorlage mit einem Anfangs-Tag <Wert> und einem End-Tag </Wert>.
For example:
<Wert>default|imap:/?configName=SUN-UWC-MAIL
&proxyAdminPassword=%5BPROXY-ADMIN_PASSWORD%5D
&subType=sun-one&enableProxyAuth=false ...</Wert>- Entfernen Sie die eckige Schließungsklammer ("]") aus der letzten ssoadapter-Meta-Vorlage.
- Fügen Sie an das Ende der Datei die folgenden Zeilen an:
</AttributeValuePair>
</ModifyDefaultValues>
</SchemaRequests>
</Requests>Die entstandene Datei ssoadapter-new-templates.xml für die in den obigen Schritten verwendete Vorlage sollte folgendermaßen aussehen:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Requests
PUBLIC "-//iPlanet//iDSAME 5.0 Admin CLI DTD//EN"
"jar://com/iplanet/am/admin/cli/amAdmin.dtd"
>
<Requests>
<SchemaRequests serviceName="SunSSOAdapterService" SchemaType="Global">
<ModifyDefaultValues>
<AttributeValuePair>
<Attribute name="sunConfigurationTemplates" />
<Wert>default|imap:/?configName=SUN-UWC-MAIL
&proxyAdminPassword=%5BPROXY-ADMIN_PASSWORD%5D
&subType=sun-one&enableProxyAuth=false ...</Wert>
</AttributeValuePair>
</ModifyDefaultValues>
</SchemaRequests>
</Requests>- Importieren Sie die neue Datei ssoadapter-new-templates.xml.
AccessManager-base/bin/amadmin -u amadminUser -w password -v
-t ssoadapter-new-templates.xmlNun können Sie auf die ssoadapter-Registerkarte in der Portal Server-Konsole zugreifen, um Einblick in die geänderten ssoadapter zu erhalten.
Aktivieren des URLScrapper-Kanals
Beim Aktualisieren von Release 3 auf Release 5 müssen Sie den URLScrapper-Kanal aktivieren. Siehe auch Aktivieren des URLScrapper-Kanals.
Löschen des Gateway-Diensteintrags
Der Benutzereintrag amService-srapGateway muss beim Aktualisieren von Portal Server von Release 2 manuell gelöscht werden, da die Portal Server Secure Remote Access-Gateway-Komponente nach der Aktualisierung ansonsten nicht gestartet werden kann. Führen Sie die folgenden Schritte aus:
Aktualisierung mehrerer Instanzen
Rolling Upgrades mehrerer Instanzen (siehe Aktualisierung mehrerer Instanzen) werden bei der Aktualisierung von Portal Server Release 2 auf Release 5 nicht unterstützt.
Aktualisieren von Portal Server von der Interim Feature Release 7.0Dieser Abschnitt enthält Informationen zur Aktualisierung von Portal Server von der Interim Feature Release (IFR) 7.0 2005Q4 auf Java ES 5 (Release 5).
In diesem Abschnitt werden folgende Themen behandelt:
Portal Server Einführung in die IFR-Aktualisierung
Berücksichtigen Sie bei der Aktualisierung von Portal Server IFR 7.0 auf Release 5 Portal Server die folgenden Aspekte des Aktualisierungsvorgangs:
- Die Portal Server-IFR wird in Anwendungsserver 7.x nicht unterstützt, daher trifft das Aktualisierungsszenario 5 in Tabelle 15-4 nicht zu.
- Das Skript psupgrade, das zur Aktualisierung der Portal Server-IFR auf Release 5 verwendet wird, installiert, anders als bei der Aktualisierung von Release 4, keine neuen Pakete. Stattdessen müssen Sie für die Aktualisierung die folgenden Patches anwenden:
Tabelle 15-8 Patches1 für die Aktualisierung der Portal Server-IFR auf Release 5
Beschreibung
Patch-ID: Solaris 9 & 10
Patch-ID: Linux
Portal Server 7.1
121465-28 (SPARC)
121466-28 (x86)
121467-28
Portal Server 7.1
-Lokalisierung123254-02 (SPARC)
124590-02 (x86)
123255-02
1Diese Patch-Versionsnummern sind für die Aktualisierung auf Java ES Release 5 mindestens erforderlich. Wenn neuere Versionen verfügbar sind, verwenden Sie anstelle der in dieser Tabelle genannten Versionen die neueren Versionen.
- Das Skript psupgrade unterstützt die Aktualisierung der Portal Server-IFR auf Release 5 für Webserver Release 5 nicht. Diese Einschränkung kann zwei Auswirkungen haben:
- Wenn Webserver bereits auf Release 5 aktualisiert wurde, können Sie die Portal Server-IFR-Software, die im früheren Webserver-Container bereitgestellt wurde, nicht aktualisieren. Daher wird das Webcontainer-Aktualisierungsszenario 2 in Tabelle 15-4 nicht unterstützt. Beachten Sie die Warnung unter Sonderfälle.
- Wenn Webserver noch nicht auf Release 5 aktualisiert wurde, können Sie zuerst die Portal Server-IFR-Software in dem älteren Webserver (6.x)-Container auf Release 5 aktualisieren, wie nachfolgend unter Aktualisieren von Portal Server IFR 7.0, beschrieben. Anschließend können Sie Webserver (und gegebenenfalls Access Manager) auf Release 5 aktualisieren. Wenn Sie dieses Aktualisierungsszenario durchführen, finden Sie unter Aktualisierung in Release 5 Webserver (7.0) Web Container zusätzliche Anweisungen zu den Aufgaben nach der Aktualisierung.
Aktualisieren von Portal Server IFR 7.0
In diesem Abschnitt wird die Aktualisierung von Portal Server von der IFR auf Java ES Release 5 unter Solaris und Linux beschrieben. Plattformspezifische Vorgänge sind durch die Angabe des jeweiligen Betriebssystems, auf das sich der Vorgang bezieht, gekennzeichnet. In diesem Abschnitt werden folgende Themen behandelt:
Aufgaben vor der Aktualisierung der IFR 7
Die Aufgaben, die vor der Aktualisierung von IFR durchgeführt werden müssen, sind mit denen für eine Release 4-Aktualisierung identisch (siehe Aufgaben vor der Aktualisierung von Release 4). Es gelten jedoch folgende Ausnahmen:
Erforderliche Konfigurationsinformationen abrufen
Die vom Skript psupgrade benötigten Informationen, wie unter Erforderliche Konfigurationsinformationen und Passwörter abrufen beschrieben, sind nicht vollständig auf die Aktualisierung von Portal Server IFR anwendbar. Die Portal Server-IFR wird in Anwendungsserver 7.x nicht unterstützt, daher trifft das Webcontainer-Aktualisierungsszenario 5 in Tabelle 15-6 nicht zu.
Konfiguration von Common Agent Container
Common Agent Container ist eine gemeinsam genutzte Komponente, die Containerdienste für Java ES-Überwachungs- und Administrationsagenten bietet. Portal Server-Administrationstools wie die Portal Server-Konsole und die Befehlszeilenschnittstelle psadmin verwenden eine Reihe von Überwachungs- und Administrationsagenten, zusammengefasst Portal Administration Server genannt, die in Common Agent Container bereitgestellt werden.
Wenn gemeinsam genutzte Java ES-Komponenten vor der Aktualisierung der Portal Server-IFR 7.0 auf Release 5 aktualisiert wurden, müssen Sie die folgenden zusätzlichen Schritte durchführen, um sich bei der Portal Server Release 5-Konsole anzumelden und die Befehlszeilenschnittstelle psadmin zu verwenden. (Wenn gemeinsam genutzte Java ES-Komponenten nicht vor der Aktualisierung der Portal Server-IFR 7.0 auf Release 5 aktualisiert wurden, können Sie die folgenden zusätzlichen Schritte ignorieren.)
- Konfigurieren Sie Common Agent Container neu.
PortalServer7-base/bin/psconfig --config PortalServer7-base/samples/example2.xml
Die Datei example2.xml enthält Informationen zur Neukonfiguration. Sie müssen zuerst die Datei example2.xml bearbeiten, um die erforderlichen Passwörter anzugeben, bevor Sie den Befehl psconfig ausführen. Wenn Sie keine Standard-Speicherorte für Portal Server verwenden, müssen Sie auch die richtigen Verzeichnisse angeben.
- Bearbeiten Sie den classpath des Webcontainers so, dass er auf Common Agent Container verweist.
Der classpath des Webcontainers enthält einen Verweis auf den Speicherort der früheren Common Agent Container-Version: (rel4CAC-base-dir/lib/cacao_cacao.jar).
Ersetzen Sie diesen Verweis durch den Speicherort von Release 5: (rel5CAC-admin-dir/lib/cacao_cacao.jar).
- Prüfen Sie, ob die Datei pasconnect.properties im Verzeichnis PortalServer7Config-base erstellt wurde und über die folgende Eigenschaft verfügt:
pas.host=
Der Eigenschaftswert kann Null, localhost oder der tatsächliche Portal Server-Hostname sein.
- Starten Sie Common Agent Container neu.
rel5CAC-admin-dir/bin/cacaoadm start
Aktualisieren der Portal Server-IFR 7.0 (Solaris)
Dieser Abschnitt enthält eine Beschreibung der Aspekte, die Einfluss auf das Aktualisierungsverfahren der Portal Server-IFR haben, sowie eine Beschreibung des eigentlichen Aktualisierungsverfahrens.
Zu berücksichtigende Aspekte bei der Aktualisierung der IFR 7 (Solaris)
Bei der Aktualisierung der Portal Server-IFR auf Java ES Release 5 sind dieselben Aspekte zu berücksichtigen wie bei der Aktualisierung von Release 4 (siehe Zu berücksichtigende Aspekte bei der Aktualisierung (Solaris)).
Informationen zu aufgetretenen Problemen finden Sie außerdem unter Portal Server Einführung in die IFR-Aktualisierung.
IFR 7-Aktualisierungsverfahren (Solaris)
Das im Folgenden beschriebene Verfahren ist für Portal Server auf dem Computer anzuwenden, auf dem die Aktualisierung durchgeführt wird.
- Melden Sie sich als Root oder Superuser an.
su -
- Stoppen Sie etwaige Instanzen von Portal Server Secure Remote Access Gateway, Rewriter-Proxy oder Netlet-Proxy, die möglicherweise lokal ausgeführt werden.
PortalServer7-base/bin/psadmin stop-sra-instance -u amadminUser
-f passwordFile -t gateway -N gatewayProfileNamePortalServer7-base/bin/psadmin stop-sra-instance -u amadminUser
-f passwordFile -t rwproxy -N gatewayProfileNamePortalServer7-base/bin/psadmin stop-sra-instance -u amadminUser
-f passwordFile -t nlproxy -N gatewayProfileNameÜberprüfen Sie, ob die Prozesse angehalten wurden:
Gateway: netstat -an | grep 443
Rewriter Proxy: netstat -an | grep 10443
Netlet Proxy netstat -an | grep 10555- Vergewissern Sie sich, dass Access Manager ausgeführt wird, wenn es in einem anderen Webcontainer bereitgestellt wird als dem, in dem Portal Server bereitgestellt wird.
- Starten Sie Portal Server, sofern es nicht bereits ausgeführt wird, indem Sie den Webcontainer starten, in dem es bereitgestellt wird.
Webserver 6.x:
WebServer-base/https-instanceName/startAnwendungsserver 8.x:
AppServer8-base/bin/asadmin start-domain --user admin_ID
--password password domainName- Beziehen Sie die in Tabelle 15-8 angegebenen erforderlichen Patches.
Verwenden Sie immer die aktuellste, verfügbare Patch-Revision, es sei denn, Sie werden angewiesen, eine bestimmte Revision zu verwenden.
Patches zum Download in das /tmp-Verzeichnis erhalten Sie unter: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
- Wenden Sie zunächst den entsprechenden Portal Server-Patch und bei Bedarf das Lokalisierungs-Patch aus Tabelle 15-8 an.
patchadd /tmp/patch_ID
- Stellen Sie sicher, dass die Patch-Aktualisierungen erfolgreich durchgeführt wurden:
showrev -p | grep patch_ID
Die Ausgabe sollte die Versionen der in Step 6 angewendeten Patch-IDs zurückgeben.
- Falls die Lokalisierungs-Patches in Step 6 aktualisiert wurden, setzen Sie das Gebietsschema der Portal Server-Konsolen-JVM auf UTF-8.
export LC_ALL=ja_JP.UTF-8
export LANG=ja_JP.UTF-8- Setzen Sie die zwei Umgebungsvariablen (ANT_HOME und JAVA_HOME), die vom Skript psupgrade benötigt werden:
export ANT_HOME=/usr/sfw
export JAVA_HOME=/usr/jdk/entsys-j2se- Stellen Sie sicher, dass auf Ihrem Computer ausreichend Swap-Speicher zur Verfügung steht.
Der Swap-Speicher sollte grundsätzlich die doppelte Größe des physikalischen RAM aufweisen.
- Führen Sie das Skript psupgrade aus.
cd PortalServer7-base/bin
./psupgradeDas psupgrade-Skript wird nicht aus der Java ES Release 5-Verteilung ausgeführt und ruft nicht das Java ES-Installationsprogramm auf (auf die Pakete wurden bereits Patches angewendet).
Das Skript weist das System an, Speicherort, Anschlussnummer und weitere Informationen zum Webcontainer zu erkennen, in dem Sie Portal Server-Webanwendungen bereitstellen. Je nach Webcontainer-Aktualisierungsszenario (siehe Tabelle 15-4) fordert das Skript Sie auf, zusätzliche Informationen einzugeben, die für die Bereitstellung von Portal Server für den entsprechenden Webcontainer erforderlich sind.
Tabelle 15-6 enthält die Informationen, die für die verschiedenen Webcontainer-Aktualisierungsszenarien in Tabelle 15-4 erforderlich sind.
- Halten Sie den Webcontainer an und starten Sie ihn erneut.
Ein Neustart des Webcontainers ist zwar nicht in jedem Fall erforderlich, dadurch wird jedoch sichergestellt, dass der Status von Portal Server beim Start eindeutig ist.
Aktualisieren der Portal Server-IFR 7 (Linux)
Dieser Abschnitt enthält eine Beschreibung der Aspekte, die Einfluss auf das Aktualisierungsverfahren von Portal Server haben, sowie eine Beschreibung des eigentlichen Aktualisierungsverfahrens.
Zu berücksichtigende Aspekte bei der Aktualisierung von IFR 7 (Linux)
Bei der Aktualisierung der Portal Server-IFR-Software auf Release 5 unter Linux sind dieselben Aspekte wie unter Solaris zu berücksichtigen (siehe Zu berücksichtigende Aspekte bei der Aktualisierung der IFR 7 (Solaris)), jedoch werden die vorherigen RPMs bei der Installation der Patches von Release 5 unter Linux entfernt.
IFR 7-Aktualisierungsverfahren (Linux)
Das im Folgenden beschriebene Verfahren ist für Portal Server auf dem Computer anzuwenden, auf dem die Aktualisierung durchgeführt wird.
- Melden Sie sich als Root oder Superuser an.
su -
- Stoppen Sie etwaige Instanzen von Portal Server Secure Remote Access Gateway, Rewriter-Proxy oder Netlet-Proxy, die möglicherweise lokal ausgeführt werden.
PortalServer7-base/bin/psadmin stop-sra-instance -u amadminUser
-f passwordFile -t gateway -N gatewayProfileNamePortalServer7-base/bin/psadmin stop-sra-instance -u amadminUser
-f passwordFile -t rwproxy -N gatewayProfileNamePortalServer7-base/bin/psadmin stop-sra-instance -u amadminUser
-f passwordFile -t nlproxy -N gatewayProfileNameÜberprüfen Sie, ob die Prozesse angehalten wurden:
Gateway: netstat -an | grep 443
Rewriter Proxy: netstat -an | grep 10443
Netlet Proxy netstat -an | grep 10555- Vergewissern Sie sich, dass Access Manager ausgeführt wird, wenn es in einem anderen Webcontainer bereitgestellt wird als dem, in dem Portal Server bereitgestellt wird.
- Starten Sie Portal Server, sofern es nicht bereits ausgeführt wird, indem Sie den Webcontainer starten, in dem es bereitgestellt wird.
Webserver 6.x:
WebServer-base/https-instanceName/startAnwendungsserver 8.x:
AppServer8-base/bin/asadmin start-domain --user admin_ID
--password password domainName- Das erforderliche Patch lässt sich anhand der entsprechenden Patch-Nummern und RPM-Namen aus Tabelle 15-8 entnehmen.
Verwenden Sie immer die aktuellste, verfügbare Patch-Revision, es sei denn, Sie werden angewiesen, eine bestimmte Revision zu verwenden.
Patches zum Download in das /tmp-Verzeichnis erhalten Sie unter: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
- Wenden Sie zunächst das Portal Server-Patch und anschließend bei Bedarf die Lokalisierungs-RPMs für Portal Server aus Tabelle 15-8 an.
Lesen Sie die Readme-Datei zum Portal Server-Patch; hierin ist beschrieben, wie Sie ein Skript zur Anwendung der RPMs des Patch verwenden:
cd /tmp
Dabei ist /tmp das Verzeichnis, in das Sie den Patch herunterladen.
./upgradeportalrpm
Das Aktualisierungsskript installiert die RPMs.
Installieren Sie die einzelnen RPMs für das Lokalisierungs-Patch mit folgendem Befehl:
rpm -Fvh patchName-version.rpm
- Stellen Sie sicher, dass die Patch-Aktualisierung erfolgreich durchgeführt wurde:
rpm -qa | grep sun-portal
Die Aktualisierungs-Revisionsnummern der RPMs sollten zurückgegeben werden.
- Falls die Lokalisierungs-Patches in Step 6 aktualisiert wurden, setzen Sie das Gebietsschema der Portal Server-Konsolen-JVM auf UTF-8.
export LC_ALL=ja_JP.UTF-8
export LANG=ja_JP.UTF-8- Setzen Sie die zwei Umgebungsvariablen (ANT_HOME und JAVA_HOME), die vom Skript psupgrade benötigt werden:
export ANT_HOME=/opt/sun
export JAVA_HOME=/usr/jdk/entsys-j2se- Stellen Sie sicher, dass auf Ihrem Computer ausreichend Swap-Speicher zur Verfügung steht.
Der Swap-Speicher sollte grundsätzlich die doppelte Größe des physikalischen RAM aufweisen.
- Führen Sie das Skript psupgrade aus.
cd PortalServer7-base/bin
./psupgradeDas psupgrade-Skript wird nicht aus der Java ES Release 5-Verteilung ausgeführt und ruft nicht das Java ES-Installationsprogramm auf (auf die Pakete wurden bereits Patches angewendet).
Das Skript weist das System an, Speicherort, Anschlussnummer und weitere Informationen zum Webcontainer zu erkennen, in dem Sie Portal Server-Webanwendungen bereitstellen. Je nach Webcontainer-Aktualisierungsszenario (siehe Tabelle 15-4) fordert das Skript Sie auf, zusätzliche Informationen einzugeben, die für die Bereitstellung von Portal Server für den entsprechenden Webcontainer erforderlich sind.
Tabelle 15-6 enthält die Informationen, die für die verschiedenen Webcontainer-Aktualisierungsszenarien in Tabelle 15-4 erforderlich sind.
- Halten Sie den Webcontainer an und starten Sie ihn erneut.
Ein Neustart des Webcontainers ist zwar nicht in jedem Fall erforderlich, dadurch wird jedoch sichergestellt, dass der Status von Portal Server beim Start eindeutig ist.
Überprüfen der Aktualisierung
Sie können die Anwendung der Patches der Portal Server-Pakete von Release 5 mithilfe des folgenden Befehls überprüfen:
Ausgabewerte finden Sie in Tabelle 15-5.
Zur Überprüfung der gesamten Aktualisierung vergewissern Sie sich, dass der Portal-Desktop angezeigt wird und das Administrationsprogramm psadmin wie dokumentiert funktioniert.
Sie können im Verzeichnis /var/sadm/install/logs auch die folgenden Aktualisierungs-Protokolldateien überprüfen:
Aufgaben nach der Aktualisierung der IFR 7
Bei der Aktualisierung von Portal Server von der IFR 7 auf Release 5 müssen Sie folgende Verfahren nach der Aktualisierung für die folgenden Situationen durchführen:
Aktivieren des Java ES Monitoring Framework
Durch Aktivieren des Java ES Monitoring Framework (gemeinsam genutzte MFWK-Komponenten) werden Portal Server-Administrationstools wie die Portal Server-Konsole und die Befehlszeilenschnittstelle psadmin angewiesen, Metriken wie z. B. die Anzahl der Besucher und die von ihnen besuchten Portale zu protokollieren. So aktivieren Sie MFWK:
- Suchen Sie die folgenden beiden Dateien:
MFWK-base/template/jesmf/desktopmfwk.properties
MFWK-base/template/jesmf/com.sun.cmm.ps.xmlwobei MFWK-base dem folgenden Pfad entspricht:
/opt/SUNWmfwk (Solaris)
/opt/sun/mfwk (Linux)
- Kopieren Sie die beiden Dateien in das folgende Verzeichnis:
PortalServer7Data-base/portals/portal_ID/config/Portal_Instance/
- Ersetzen Sie in der Datei desktopmfwk.properties
com.sun.portal.ProductCollectionId=%PS_DIR%
with
com.sun.portal.ProductCollectionId=Portal_Installed_Location
- Fügen Sie die folgenden beiden JAR-Dateien:
MFWK-base/lib/mfwk_instrum_tk.jar
MFWK-base/lib/mfwk_agent.jardem classpath des entsprechenden Containers hinzu (Datei server.xml für Webserver und domain.xml für Anwendungsserver).
- Starten Sie den entsprechenden Webcontainer neu.
Aktualisierung im Anwendungsserver-Webcontainer
Wenn Portal Server in einem Anwendungsserver-Webcontainer bereitgestellt wird, müssen Sie das folgende zusätzliche Verfahren durchführen, um Portal Server erfolgreich erneut bereitzustellen:
- Suchen Sie den Abschnitt, in dem die psconsole-Einstellungen in der Datei AppServer8Config-base/domains/domainName/config/server.policy definiert sind:
- Fügen Sie an das Ende des Abschnitts die folgende Zeile an:
permission java.lang.RuntimePermission getProtectionDomain“
- Starten Sie die Anwendungsserver-Instanz neu.
AppServer8-base/bin/asadmin start-domain --user admin_ID
--password passworddomainNameAppServer8-base/bin/asadmin start-node-agent --user admin_ID
--password password nodeagentNamewobei nodeagentName der Form hostName_domainName entspricht, jedoch standardmäßig nur hostName lautet.
Verbindungen bleiben im Anwendungsserver-Webcontainer hängen
Wenn der aktualisierte Portal Server in einem Anwendungsserver-Webcontainer bereitgestellt wird, kann es vorkommen, dass die Portalanwendungen beim Warten auf Java DB-Verbindungen hängenbleiben. Gehen Sie folgendermaßen vor, um dieses Problem zu beheben:
- Entfernen Sie die Einstellungen in PortalServer7Data-base/derby/derby.properties zu den folgenden beiden Parametern:
derby.drda.maxThreads
derby.drda.timeslice- Starten Sie Java DB neu.
ANT_HOME/bin/ant
-DPS_CONFIG=PortalServer7Config-base/PSConfig.properties
-buildfile PortalServer7-base/lib/derby.xml
[stop-instance|start-instance]wobei ANT_HOME /usr/sfw (unter Solaris) und /opt/sun (unter Linux) entspricht.
- Ändern Sie die Java DB-Konfigurationseinstellungen für Anwendungsserver.
Ändern Sie mithilfe der Anwendungsserver-Konsole die Attributwerte zu den folgenden Verbindunsgpool-Ressourcen: communitymcPool, FileSharingDBPool, PointBasePool, SurveyDBPool.
Ändern Sie die folgenden Attributwerte wie folgt:
Idle Timeout in 300 oder mehr
Resource Type in javax.sql.ConnectionPoolDataSource
Datasource classname in
org.apache.derby.jdbc.ClientConnectionPoolDataSource- Starten Sie die Anwendungsserver-Instanz neu, in der Portal Server bereitgestellt wird.
Aktualisierung in Release 5 Webserver (7.0) Web Container
Wenn Sie die Portal Server-IFR in einem Webserver aktualisiert haben, der noch nicht auf Release 5 aktualisiert wurde, weil das Skript psupgrade die Aktualisierung der Portal Server-IFR auf Webserver Release 5 nicht unterstützt (siehe Portal Server Einführung in die IFR-Aktualisierung), müssen Sie die folgenden zusätzlichen Verfahren nach der Aktualisierung durchführen:
- Aktualisieren Sie Webserver (und gegebenenfalls Access Manager) auf Release 5.
- Konfigurieren Sie die von der Portal Server-Konsole benötigten Webserver -Containerwerte und die Befehlszeilenschnittstelle psadmin neu.
- Öffnen Sie einen LDAP-Browser.
Die Konfigurationswerte werden in Directory Server gespeichert.
- Suchen Sie unter DN nach:
sunPortalAdminPortalDomainID=defaultDomain
->sunPortalAdminPortalDomainPortalID=portal1
->sunPortalAdminPortalDomainPortalServerInstanceIn=host-port- Nehmen Sie Änderungen folgendermaßen vor.
Beachten Sie, dass alle Einträge von dieser Zeichenfolge eingeleitet werden: sunPortalAdminPortalDomainPortalServerInstance
- Löschen Sie den Eintrag für WebContainerInstanceDir..
- Fügen Sie einen Eintrag für WebContainerDomainName hinzu, und weisen Sie ihm den Wert des Webcontainer-Konfigurationsnamen aus Tabelle 15-6 zu.
- Bearbeiten Sie Werte wie InstallDir, WebContainerType, DocRoot und andere Parameter in Tabelle 15-6 so, dass sie den Werten in Webserver Release 5 (7.0) entsprechen.
- Erstellen Sie eine Portal Server Release 5-Instanz.
PortalServer7-base/bin/psadmin create-instance newInstance_ID
Wenn der Wert von newInstance_ID bereits vorhanden ist, wird ein Fehler ausgegeben, daher ist es von Vorteil, diesen Schritt vor dem nachstehenden Step 4 durchzuführen.
- Löschen Sie die Portal Server-IFR-Instanz.
PortalServer7-base/bin/psadmin delete-instance oldInstance_ID
Erneutes Bereitstellen von benutzerdefinierten Portlet-Anwendungen
Wenn Sie benutzerdefinierte Portlet-Anwendungen erstellt und bereitgestellt haben, müssen diese Portlets Portal Server Release 5 nach der Aktualisierung manuell erneut bereitgestellt werden. Zwar sind Anzeige-Profileinträge vorhanden und der Kanalname wird angezeigt, der Inhalt ist jedoch erst zu sehen, nachdem Sie die benutzerdefinierten Portlets erneut bereitgestellt haben.
Stellen Sie die Portlets mit dem folgenden Befehl erneut bereit:
PortalServer7-base/bin/psadmin deploy-portlet
Sie können die erneute Bereitstellung überprüfen, indem Sie die entsprechenden .war- und XML-Dateien im folgenden Verzeichnis suchen:
PortalServer7Data-base/portals/Upgraded/war
Migrieren von benutzerdefinierten Portlet-Anwendungen
Portlet-Anwendungen, die auf dem von Sun Java Web Console (SJWC) gelieferten Benutzerschnittstellen-Framework basieren, müssen manuell in Release 5 migriert und erneut bereitgestellt werden.
Diese Anforderung betrifft insbesondere vier Webanwendungen, die mit Portal Server als Beispiel-Portlet-Anwendungen verteilt werden, welche dazu gedacht sind, angepasst und in einem Portal installiert zu werden: filesharing, surveys, wiki, rssportlet. Bei der Aktualisierung werden fehlerkorrigierte Versionen dieser Beispiel-Portlet-Anwendungen im Bereich der Portlet-Anwendungen auf dem Datenträger platziert. Wenn Sie diese Portlet-Anwendungen für Ihren Gebrauch angepasst haben, müssen Sie sie manuell in Release 5 migrieren und erneut bereitstellen; sie werden nicht vom Portal Server-Aktualisierungsprozess erfasst.
Standardmäßig werden einige dieser Portlet-Anwendungen (filesharing und surveys) bereitgestellt und dem Benutzer zugänglich gemacht, wenn eine Community erstellt wird.
Sie können SJWC-basierende Portlet-Anwendungen folgendermaßen aktualisieren, anpassen und erneut bereitstellen. Die Portlet-Anwendung filesharing dient hierbei als Beispiel:
- Extrahieren Sie die SJWC-JAR-Dateien von Release 5.
- mkdir /tmp/lh
- cd /tmp/lh
- /usr/jdk/entsys-j2se/bin/jar xvf PortalServer7-base/portlet/communityportlets.war
WEB-INF/lib/commons-beanutils.jar
WEB-INF/lib/commons-collections-3.1.jar
WEB-INF/lib/commons-digester.jar
WEB-INF/lib/commons-logging.jar
WEB-INF/lib/dataprovider.jar WEB-INF/lib/jsf-api.jar
WEB-INF/lib/jsf-impl.jar WEB-INF/lib/webui.jarWenn die Datei PortalServer7-base/portlet/communityportlets.war
nicht gefunden wird, verwenden Sie die Datei PortalServer7-base/portlet/core/communityportlets.war.- Benennen Sie eine dieser Dateien um.
mv WEB-INF/lib/commons-collections-3.1.jar
WEB-INF/lib/commons-collections.jar- Suchen Sie die Portlet-Anwendung filesharing.
cd PortalServer7Config-base/portals/portal1/portletapps/filesharing
- Geben Sie die aktualisierten SJWC-Bibliotheken ein.
jar uvf src/filesharing.war.tokenized -C /tmp/lh WEB-INF
- Passen Sie die Portlet-Anwendung filesharing an.
ant customize
- Stellen Sie die Portlet-Anwendung filesharing erneut bereit.
- PortalServer7-base/bin/psadmin undeploy-portlet -u amadmin
-f passwordfile -p portal_id -i instance_id -g filesharing- ant deploy
- Gehen Sie zum folgenden Verzeichnis (je nach Webcontainer):
Anwendungsserver 8.x:
AppServer8Config-base/domains/domain1/applications/j2ee-modules/
communityportlets/WEB-INFWebserver 6.x:
WebServer6-base/https-instanceName/webapps/https-instanceName/
communityportlets/WEB-INFWebserver 7.x:
WebServer7Config-base/https-configName/web-app/https-configName/
communityportlets/WEB-INF- Öffnen Sie die Datei sun-web.xml und fügen Sie unmittelbar vor der letzten Zeile (d. h. vor dem End-Tag sun-web-app) die folgende Zeile hinzu:
<class-loader delegate="false"/>
- Wiederholen Sie Step 2 bis Step 5 für surveys und alle weiteren auf dem SJWC-Framework basierenden benutzerdefinierten Portlet-Anwendungen.
- Starten Sie den Webcontainer neu.
Korrigieren Sie die Verknüpfungen in den Lesezeichen und Anwendungskanälen
Wenn Sie von Portal Server Release 4 auf Release 5 aktualisieren, entstehen in den Lesezeichen- und Anwendungskanälen doppelte und falsche Verknüpfungen. Gehen Sie folgendermaßen vor, um diese Verknüpfungen zu korrigieren.
- Melden Sie sich bei PSConsole an.
- Klicken Sie auf der Registerkarte Allgemeine Aufgaben“ auf Kanäle und Container verwalten“.
- Wählen Sie DeveloperSample [Org]“ als DN aus, und klicken Sie auf OK.
- Wählen Sie JSPTabContainer [default]“ als Ansichtstyp aus.
- Klicken Sie unter MyFrontPageTabPanelContainer“ auf Anwendungskanal“.
Im rechten Bereich werden die Eigenschaften des Anwendungskanals angezeigt.
Um die Eigenschaften für ein bestimmtes Gebietsschema anzuzeigen, zeigen Sie die Tabelleneinstellungen an, und geben Sie den entsprechenden Wert ein: de, fr, es, ja, ko, zh, zh_CN, zh_TW.
- Bearbeiten Sie die Eigenschaft userApps“.
- Bearbeiten Sie die Zieleigenschaft
Manuelle Migration von Struts-basierten Portlets
Wenn Sie über benutzerdefinierte Portlets verfügen, die auf dem Struts-Framework basierende Codes verwenden, müssen diese Portlets manuell aktualisiert werden, damit die in Portal Server Release 5 enthaltene Datei struts.jar verwendet werden kann. Gehen Sie folgendermaßen vor:
- Heben Sie die Bereitstellung der Struts-basierten Portlet-Anwendung auf.
PortalServer7-base/bin psadmin undeploy-portlet
- Aktualisieren Sie die war-Datei mit der richtigen Version der Datei struts.jar.
Kopieren Sie PortalServer7-base/lib/struts.jar in strutsbasedPortlet/WEB-INF/lib/struts.jar
wobei strutsbasedPortlet dem Verzeichnis entspricht, in dem sich die Struts-basierten Portlet-Dateien befinden.
- Erstellen Sie ein .war-Archiv des Verzeichnisses strutsbasedPortlet.
- Stellen Sie die Portlet-Anwendung erneut bereit.
PortalServer7-base/bin psadmin deploy-portlet
Aufheben der Aktualisierung (Solaris)
Dieser Abschnitt enthält eine Beschreibung der Aspekte, die Einfluss auf das Verfahren zum Aufheben der Aktualisierung Portal Server haben, sowie eine Beschreibung des eigentlichen Verfahrens zum Aufheben der Aktualisierung.
Zu berücksichtigende Aspekte beim Aufheben der Aktualisierung (Solaris)
Beim Aufheben der Aktualisierung auf Release 5 wird die IFR-Installation in PortalServer6-base wiederhergestellt und die Webanwendungen der IFR werden erneut bereitgestellt.
Verfahren zum Aufheben der Aktualisierung (Solaris)
- Melden Sie sich als Root oder Superuser an.
su -
- Stellen Sie den Zustand von Directory Server vor der Aktualisierung wieder her.
Verwenden Sie die Directory Server-Sicherungs-/Wiederherstellungs-Befehlszeile und die GUI-Programme. Lesen Sie hierzu das Kapitel zum Sichern und Wiederherstellen von Directory Server im Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide, http://docs.sun.com/doc/819-0995.
- Heben Sie die Bereitstellung der Webanwendungen in Portal Server Release 5 auf, die während der Aktualisierung auf Release 5 erneut bereitgestellt wurden.
Verwenden Sie die Administrationsprogramme des Webcontainers (Befehlszeile oder Konsole) zum Aufheben der Bereitstellung der folgenden Pakete:
portal
psconsole
search1
wsssoportlet
guessnumber
portletsamples- Beenden Sie Portal Server, indem Sie seinen Webcontainer beenden.
Webserver 6.x:
WebServer-base/https-instanceName/stopWebserver 7.0:
Admin Server--
WebServer7Config-base/admin-server/bin/stopserv
Instance Server--
WebServer7Config-base/https-configName/bin/stopservAnwendungsserver 8.x:
AppServer8-base/bin/asadmin stop-domain --user admin_ID
--password password domainName- Heben Sie das Portal Server 7.1-Patch aus Tabelle 15-8 auf.
patchrm patch_ID
- Starten Sie Portal Server neu, indem Sie seinen Webcontainer neu starten.
Webserver 6.x:
WebServer-base/https-instanceName/startWebserver 7.0:
Admin Server--
WebServer7Config-base/admin-server/bin/startserv
Instance Server--
WebServer7Config-base/https-configName/bin/startservAnwendungsserver 8.x:
AppServer8-base/bin/asadmin start-domain --user admin_ID
--password password domainName- Stellen Sie die Webanwendungen in Portal Server Release 5 bereit, deren Bereitstellung während Step 3 aufgehoben wurde.
Verwenden Sie die Administrationsprogramme des Webcontainers (Befehlszeile oder Konsole), um die Pakete bereitzustellen.
- Halten Sie den Webcontainer an und starten Sie ihn erneut.
Ein Neustart des Webcontainers ist zwar nicht in jedem Fall erforderlich, dadurch wird jedoch sichergestellt, dass der Status von Portal Server beim Start eindeutig ist.
Aufheben der Aktualisierung (Linux)
Die Aktualisierung kann auf Linux nicht aufgehoben werden.
Sie können jedoch vor der Aktualisierung ein paralleles System erstellen und dieses System vor der Aktualisierung testen. Wenn Sie die Aktualisierung aufheben müssen, können Sie zu diesem parallelen System zurückkehren.
Aktualisierung mehrerer Instanzen
In manchen Bereitstellungsarchitekturen wird Portal Server auf mehreren Computersystemen bereitgestellt, um die Skalierbarkeit zu gewährleisten und die Verfügbarkeit zu verbessern. Möglicherweise führen Sie beispielsweise Portal Server-Komponenten auf mehreren Computern zusammen mit einem Lastenausgleichsprogramm aus, um die Last zu verteilen.
Für Portal Server-Instanzen mit Lastenausgleich können Sie ein sogenanntes Rolling Upgrade durchführen, bei dem Sie alle Portal Server-Instanzen nacheinander aktualisieren, ohne den Dienst zu unterbrechen. Dabei werden die verschiedenen Portal Server-Instanzen einzeln aktualisiert, während die übrigen Instanzen weiter ausgeführt werden. Zur Durchführung eines Rolling Upgrade von der IFR auf Release 5 gehen Sie wie unter Aktualisierung mehrerer Instanzen beschrieben vor. Ersetzen Sie in den Anweisungen jedoch Verweise auf Release 4 durch die IFR.
