Guide de mise à niveau de Sun Java Enterprise System 5 pour UNIX |
Chapitre 15
Portal ServerCe chapitre décrit la procédure de mise à niveau de Portal Server vers Java ES 5 (version 5) : Sun Java System Portal Server 7.1.
Ce chapitre présente les considérations relatives à la mise à niveau pour les différentes méthodes de mise à niveau prises en charge par la version 5. Il traite des mises à niveau sur les systèmes d'exploitation Solaris et Linux :
Présentation des mises à niveau de Portal ServerCette section présente les aspects généraux de Portal Server qui ont un impact sur la mise à niveau vers Java ES 5 (version 5) :
À propos de Portal Server pour Java ES version 5
Portal Server pour Java ES version 5 représente, par ses nombreuses améliorations et nouveautés, une version majeure par rapport à la version 4. Une grande partie de ces modifications ont été apportées à une version intermédiaire du logiciel postérieure à la version 4. Par rapport à cette version intermédiaire, la version 5 contient uniquement quelques changements de fonctionnalités mineurs. Pour plus d'informations sur les améliorations et nouveautés de la version intermédiaire du logiciel, reportez-vous aux Notes de version de Sun Java System Portal Server 7.1, http://docs.sun.com/doc/820-0903/6n4l3f365?a=view. L'interface d'administration par ligne de commande de la version 4 a notamment été remplacée par la commande psadmin.
Présentation de la mise à niveau de Portal Server
Le Tableau 15-2 répertorie les méthodes de mise à niveau de Portal Server vers Java ES version 5 prises en charge. Il s'applique à la fois à Solaris et Linux.
Données de Portal Server
Le tableau suivant affiche le type de données susceptible d'être affecté par la mise à niveau du logiciel Portal Server.
Stratégie de mise à niveau de Portal Server
Votre stratégie de mise à niveau de Portal Server dépend généralement des nombreuses considérations traitées dans le Chapter 1, "Planification des mises à niveau" : méthode de mise à niveau, dépendances entre les composants Java ES, mise à niveau sélective ou globale, déploiements portant sur plusieurs instances et ainsi de suite.
Cette section vise à cibler ce sujet général sur Portal Server en présentant les phénomènes susceptibles d'avoir une incidence sur votre planification de mise à niveau de Portal Server.
Problèmes de compatibilité
La version 5 de Portal Server met en place des modifications au niveau de l'interface publique pour la commande psadmin permettant d'administrer Portal Server et les composants de Portal Server Secure Remote Access. Reportez-vous à la Référence de la ligne de commande de Sun Java System Portal Server 7.1, http://docs.sun.com/doc/819-5030.
Par conséquent, la version 5 de Portal Server n'est pas compatible avec les versions antérieures ou avec les versions antérieures des composants de Portal Server Secure Remote Access (y compris SRA Gateway, Rewriter Proxy et Netlet Proxy), à l'exception d'une période de transition pendant laquelle les déploiements portant sur plusieurs instances passent par un processus de mise à niveau progressive. Toutes les instances de Portal Server doivent être synchronisées, parallèlement aux instances de composant de Portal Server Secure Remote Access, au niveau de Java ES version 5.
De même, chacun des composants de Portal Server, y compris le composant d'accès mobile, n'est pas compatible avec les versions antérieures et tous doivent être synchronisés sur Java ES version 5.
En outre, il existe une incompatibilité entre les structures de données Directory Server utilisées par la version 5 et par les versions précédentes de Portal Server. Cette incompatibilité implique une mise à niveau progressive de plusieurs instances de Portal Server utilisant les mêmes données Directory Server.
Dépendances de Portal Server
Les dépendances de Portal Server par rapport à d'autres composants Java ES peuvent avoir une incidence sur votre procédure de mise à niveau et de reconfiguration du logiciel Portal Server. Les modifications apportées aux interfaces ou fonctions de Portal Server, par exemple, peuvent demander une version mise à niveau des composants dont dépend Portal Server. Le besoin de mettre à jour ces composants dépend de la méthode de mise à niveau spécifique.
Portal Server présente des dépendances par rapport aux composants Java ES suivants :
- Composants partagés. Portal Server présente des dépendances par rapport à certains composants partagés Java ES (voir le Tableau 1-9).
- Conteneur Web. Portal Server présente une dépendance obligatoire par rapport aux services de conteneur Web, qui peuvent être fournis par Java ES Web Server, par Java ES Application Server ou par des conteneurs tiers de WebLogic ou WebSphere.
- Access Manager (ou Access Manager SDK). Portal Server présente une dépendance obligatoire par rapport à Access Manager pour fournir aux utilisateurs finals les services d'authentification et d'autorisation, notamment la connexion unique. Si Access Manager est exécuté sur un ordinateur distant, Access Manager SDK doit être disponible en local.
- Directory Server. Portal Server présente une dépendance obligatoire par rapport à Directory Server, qui stocke les données utilisateur ayant fait l'objet d'un accès à l'aide d'Access Manager. Ainsi, les mises à niveau de Portal Server peuvent requérir des extensions du schéma d'annuaire.
- Portal Server Secure Remote Access. Portal Server présente une dépendance facultative par rapport à Portal Server Secure Remote Access, qui fournit un accès distant sécurisé via les composants Gateway, Rewriter Proxy et Netlet Proxy.
- Base de données Java. Portal Server présente une dépendance facultative par rapport à Base de données Java, qui fournit la prise en charge de plusieurs applications de portlet.
- Service Registry. Portal Server has a mandatory dependency on Service Registry, which provides libraries needed for compilation.
- Communications Express. Portal Server, un composant de la Sun Java Communications Suite, qui permet de proposer des canaux de messagerie et de calendrier aux utilisateurs finals. Communications Express ne fait plus partie du produit Java ES.
Problèmes liés à la mise à niveau sélective
Alors que, en règle générale, Java ES version 5 prend en charge la mise à niveau sélective de tous les composants d'un ordinateur, le fait que Portal Server présente des dépendances à un nombre aussi important de composants Java ES complique considérablement la certification de combinaisons arbitraires de composants sur plusieurs versions de Java ES.
En conséquence, Portal Server prend en charge un nombre limité de scénarios de mise à niveau en ce qui concerne Access Manager et les conteneurs Web.
- Si vous effectuez la mise à niveau de Portal Server à partir de Java ES version 4. Vous pouvez mettre à niveau Directory Server, Access Manager et le conteneur Web (Web Server ou Application Server) vers la version 5 avant de procéder à la mise à niveau de Portal Server, ou mettre à niveau uniquement Portal Server vers la version 5 (en laissant les autres composants au niveau de la version 4), mais vous ne pouvez pas conserver de dépendances au niveau 4 tout en en mettant d'autres à niveau vers la version 5.
- Si vous effectuez la mise à niveau de Portal Server à partir de Java ES version 3. Vous devez mettre à niveau Directory Server, Access Manager et le conteneur Web (Web Server ou Application Server) vers la version 4 ou 5 avant de mettre à niveau Portal Server, mais vous ne pouvez pas conserver de dépendances au niveau de la version 3 ni mettre à niveau certaines dépendances vers la version 4 et d'autres vers la version 5.
- Si vous effectuez la mise à niveau de Portal Server à partir de Java ES version 2. Vous devez mettre à niveau Directory Server, Access Manager et le conteneur Web (Web Server ou Application Server) vers la version 4 ou 5 avant de procéder à la mise à niveau de Portal Server. Vous ne pouvez pas conserver de dépendances au niveau de la version 2 ni mettre à niveau certaines dépendances vers la version 4 et d'autres vers la version 5.
Scénarios de mise à niveau du conteneur Web
Portal Server peut être déployé dans un conteneur Web fourni par Web Server ou Application Server. En conséquence, la mise à niveau de Portal Server vers la version 5 peut être rendue complexe en raison de l'éventualité d'une mise à niveau antérieure vers la version 5 du conteneur Web dans lequel il est déployé. À cet égard, il existe un certain nombre de scénarios possibles pour la mise à niveau du conteneur Web ; ces derniers sont énumérés dans le tableau suivant.
Vous devez être vigilant lorsque vous mettez à niveau Portal Server (par exemple lorsque vous utilisez le script psupgrade) : veillez à indiquer les valeurs appropriées pour le scénario de mise à niveau dans le Tableau 15-4 qui s'applique, particulièrement lorsqu'il s'agit d'un changement de version majeure du conteneur Web.
Double mise à niveau
La double mise à niveau, qui permet à la fois la mise à niveau de Portal Server et du système d'exploitation (comme le décrit la section Mises à niveau doubles : Java ES et système d'exploitation) peut être effectuée en utilisant la méthode de mise à niveau d'un système d'exploitation existant :
- Sauvegardez les données de Portal Server.
Reportez-vous à Données de Portal Server concernant l'emplacement des données fondamentales.
- Mettez à niveau le système d'exploitation.
La mise à niveau ne modifie pas le système de fichier existant.
- Procédez à la mise à niveau de Portal Server vers la version 5.
Reportez-vous à la section correspondante du présent chapitre, en fonction de la méthode de mise à niveau.
Mise à niveau de Portal Server à partir de Java ES version 4Cette section présente des informations sur la mise à niveau de Portal Server à partir de Java ES 2005Q4 (version 4) vers Java ES 5 (version 5).
La section aborde les thèmes suivants :
Introduction
Lors de la mise à niveau de Portal Server pour Java ES version 4 vers la version 5, tenez compte des aspects suivants du processus de mise à niveau :
- Approche générale de mise à niveau. La mise à niveau est réalisée à l'aide d'un script de mise à niveau, psupgrade. Ce script installe de nouveaux packages, fait migrer les données de configuration si besoin, met à jour les fichiers de localisation et re-déploie les applications Web Portal Server dans le conteneur Web.
- Dépendances de mise à niveau. Portal Server présente des dépendances par rapport à certains composants partagés Java ES (voir le Tableau 1-9). Alors que la version 5 de Portal Server est compatible avec la version 4 de ces composants partagés, la mise à niveau des composants reste nécessaire car le script psupgrade utilisé pour mettre à niveau Portal Server requiert la version 5 du composant partagé ANT.
Portal Server version 5 présente également des dépendances par rapport à un conteneur Web, Access Manager, et à Directory Server, comme le décrit la section Dépendances de Portal Server. Deux approches sont prises en charge pour mettre à niveau ces dépendances (voir Problèmes liés à la mise à niveau sélective) :
- Compatibilité ascendante. Portal Server version 5 n'est pas compatible avec la version 4.
- Annulation de la mise à niveau. L'annulation de la mise à niveau de la version 5 de Portal Server permettant de revenir à la version 4 consiste à restaurer les packages et les données d'annuaire de la version 4 et à redéployer les applications Web de Portal Server dans le conteneur Web.
- Problèmes relatifs à la plate-forme. L'approche globale de la mise à niveau de Portal Server est identique pour les systèmes d'exploitation Solaris et Linux. En revanche, Portal Server version 5 est installé dans un nouveau fichier sur le système d'exploitation Solaris, tandis qu'il reste dans le même chemin sur Linux.
Mise à niveau de Portal Server pour la version 4
Cette section explique comment effectuer la mise à niveau de Portal Server de Java ES version 4 vers Java ES version 5 sur les plates-formes Solaris et Linux. Lorsqu'une rubrique traite de procédures spécifiques à une plate-forme, le système d'exploitation auquel elle fait référence est indiqué. La section aborde les thèmes suivants :
Tâches à exécuter avant la mise à niveau de la version 4
Avant de mettre à niveau Portal Server, vous devez effectuer les tâches suivantes :
Vérifier les informations sur la version actuelle
Vous pouvez vérifier la version actuelle de Portal Server à l'aide de la commande suivante :
PortalServer6-base/bin/version
Tableau 15-5 Résultat de la vérification de la version de Portal Server
Version de Java ES
Numéro de version de Portal Server
Version 2
6.3
Version 3
6.3.1
Version 4
6.3.11
Version intermédiaire du logiciel
7.0
Version 5
7.1
1La seule différence entre la version 3 et la version 4 est un patch. Vous pouvez vérifier l'application des patchs pour la version 4 en utilisant la commande Solaris showrev -p | grep ID_patch et la commande Linux rpm -qa sun-portal-core et en comparant les versions par rapport à celles qui sont répertoriées dans le Guide de mise à niveau de Java ES version 4.
Mise à niveau des composants présentant des dépendances par rapport à Portal Server
Il est généralement recommandé de mettre à niveau tous les composants Java ES installés sur un même ordinateur (et dans un environnement informatique) vers Java ES version 5.
Alors que la version 5 de Portal Server est compatible avec la version 4 des composants partagés de Java ES, la mise à niveau des composants reste nécessaire car le script psupgrade utilisé pour mettre à niveau Portal Server requiert la version 5 du composant partagé ANT.
Si vous choisissez de mettre à niveau l'une des dépendances de composant produit de Portal Server vers la version 5, vous devez toutes les mettre à niveau (voir Problèmes liés à la mise à niveau sélective). La mise à niveau des dépendances doit être effectuée dans l'ordre suivant (en ignorant celles qui ont éventuellement déjà été mises à niveau), avant de pouvoir mettre à niveau Portal Server.
- Composants partagés. Les instructions de synchronisation des composants partagés Java ES vers la version 5 sont présentées dans la section Mise à niveau des composants partagés Java ES.
- Directory Server. Les instructions de mise à niveau de Directory Server vers la version 5 sont présentées dans le Chapter 5, "Directory Server".
- Logiciels de conteneur Web. Les instructions de mise à niveau de Web Server ou d'Application Server sont présentées respectivement dans le Chapter 7, "Web Server" et le Chapter 11, "Application Server".
- Access Manager (kit SDK d'Access Manager). Les instructions de mise à niveau d'Access Manager vers la version 5 sont présentées dans le Chapter 14, "Access Manager".
- Portal Server Secure Remote Access. Les instructions de mise à niveau de Portal Server Secure Remote Access vers la version 5 sont présentées dans le Chapter 16, "Portal Server Secure Remote Access".
- Base de données Java. Les instructions de mise à niveau de Base de données Java vers la version 5 sont présentées dans le Chapter 8, "Base de données Java".
- Service Registry. Les instructions de mise à niveau de Service Registry vers la version 5 sont présentées dans le Chapter 12, "Service Registry".
- Communications Express. Les instructions de mise à niveau de Communications Express vers la version 5 sont présentées dans le Guide de mise à niveau de Sun Java Communications Suite, http://docs.sun.com/doc/819-7561.
Obtention des mots de passe et informations de configuration requis
Selon le scénario de mise à niveau du conteneur Web (voir le Tableau 15-4), le script psupgrade peut vous demander d'entrer des informations sur les mots de passe et autres données de configuration du conteneur Web. Les informations requises pour les différents scénarios de mise à niveau du conteneur Web sont indiquées dans le Tableau 15-6. Veillez à rassembler les informations appropriées avant de commencer la mise à niveau de Portal Server.
Tableau 15-6 Informations requises par le script psupgrade pour chacun des scénarios de mise à niveau du conteneur Web
Informations
Scénario de mise à niveau1
Web Server 7.x Exemples de valeurs :
Scénario 2Application Server 7.x Exemples de valeurs :
Scénario 52Mise à niveau de Portal Server sur Web Server 7.0 (oui/non)
2
Oui
Non applicable
Répertoire d'installation du conteneur Web
2 et 5
WebServer7-base
AppServer8Install-base
Nom de l'instance de serveur virtuel du conteneur Web
2
https-nomConfig2
Non applicable
Nom de l'instance du conteneur Web
5
Non applicable
server1
Répertoire de l'instance du conteneur Web
2
WebServer7Config-base/
https-nomConfig4/Non applicable
Répertoire de déploiement de l'instance du portail
5
Non applicable
AppServer8Config-base/
domains/nomDomainePort de l'instance du conteneur Web
2 et 5
80
80
Protocole de l'instance du conteneur Web
2 et 5
http
http
Nom de la configuration du conteneur Web
2
nomConfig4
Non applicable
Nom de domaine du conteneur Web
5
Non applicable
domain1
Répertoire racine des documents du conteneur Web
2 et 5
WebServer7Config-base/
https-nomConfig4/docs/AppServer8Config-base/
domains/nomDomaine/
docrootNom de l'hôte d'administration du conteneur Web
2 et 5
localhost
localhost
Port d'administration du conteneur Web
2 et 5
8989
4848
Protocole d'administration du conteneur Web
2 et 5
https
https
ID utilisateur d'administration du conteneur Web
2 et 5
admin
admin
Mot de passe administrateur du conteneur Web
2 à 5
Mot de passe maître du conteneur Web
3 à 5
Non applicable
Mot de passe de Directory Manager (cn=Directory manager)
1 à 5
Mot de passe utilisateur du journal SRA3
1 à 5
Mot de passe administrateur d'Access Manager
1 à 5
Mot de passe utilisateur LDAP de Directory Server
1 à 5
ID de l'instance de portail4
1 à 5
1Le scénario de mise à niveau du conteneur Web n°5 s'applique à la mise à niveau de Portal Server à partir de la version 2.
2La valeur par défaut de nomConfig est nomHôte.nomDomaine.
3Ces informations sont requises pour configurer les composants de Portal Server Secure Remote Access lorsqu'ils sont installés avec Portal Server.
4La valeur attribuée à ce paramètre doit être une valeur unique et non nulle. Par ailleurs, elle doit être alphanumérique et peut contenir un trait d'union (-).
Sauvegarde des informations de configuration de Portal Server pour la version 4
La mise à niveau de Portal Server vers la version 5 ne nécessite pas de nouvelle configuration du logiciel Portal Server. Toutefois, par mesure de précaution, le script psupgrade va sauvegarder les répertoires suivants qui contiennent les informations de configuration :
Enregistrement des paramètres de Java Virtual Machine (JVM)
Veuillez enregistrer les paramètres JVM suivants du conteneur Web, s'ils diffèrent des valeurs par défaut, avant de mettre à niveau Portal Server :
L'emplacement des paramètres JVM dépend du conteneur Web, comme l'indique le tableau suivant.
Vous devrez vérifier ultérieurement que ces paramètres JVM n'ont pas été modifiés suite à la procédure de mise à niveau de Portal Server.
Suppression de la configuration de l'équilibreur de charge
Dans les situations où l'accès aux instances de Portal Server se fait via un équilibreur de charge, la valeur de la propriété LOAD_BALANCER_URL utilisée pour configurer ce type d'accès peut interférer avec la mise à niveau de Portal Server. Par conséquent, ce paramètre doit être modifié avant de procéder à la mise à niveau. Pour modifier le paramètre de propriété LOAD_BALANCER_URL, procédez comme suit :
- Parmi les fichiers de configuration suivants, notez ceux qui résident localement (certains d'entre eux prennent en charge des composants de Portal Server Secure Remote Access susceptibles d'être installés en local) :
PortalServer6Config-base/PSConfig.properties
PortalServer6Config-base/GWConfig.properties (si Gateway est installé en local)
PortalServer6Config-base/RWPConfig.properties (si Rewriter Proxy est installé en local)
PortalServer6Config-base/NLPConfig.properties (si Netlet Proxy est installé en local)- Enregistrez la valeur en cours de la propriété LOAD_BALANCER_URL dans ces fichiers de configuration.
- Modifiez la valeur de la propriété LOAD_BALANCER_URL afin qu'elle pointe vers l'instance appropriée de Portal Server :
LOAD_BALANCER_URL=nomHôtePortail:port/portal
Suppression de la configuration pour Directory Proxy Server ;
Dans les situations où les instances de Portal Server accèdent à Directory Server via une instance de Directory Proxy Server ;, les paramètres d'hôte et de numéro de port de Directory Proxy Server ; doivent être modifiés avant de procéder à la mise à niveau, puis restaurés selon leurs valeurs initiales une fois que la mise à niveau est terminée.
Pour modifier les paramètres appropriés, procédez comme suit :
- Enregistrez les valeurs en cours des propriétés DS_HOST et DS_PORT dans le fichier de configuration Access Manager suivant :
AccessManagerConfig-base/config/AMConfig.properties
- Modifiez la valeur des propriétés DS_HOST et DS_PORT afin qu'elles pointent vers l'instance appropriée de Directory Server :
Mise à niveau de la version 4 de Portal Server (Solaris)
Cette section traite des considérations ayant une incidence sur la procédure de mise à niveau pour Portal Server et décrit ensuite les différentes étapes de cette procédure.
Considérations relatives à la mise à niveau (Solaris)
La mise à niveau de Portal Server vers la version 5 tient compte des considérations suivantes :
- Toutes les instances de Portal Server correspondant à la même image de Portal Server installée sont mises à niveau simultanément.
- Le logiciel Portal Server est constitué de sous-composants qui remplissent des rôles différents, mais qui sont tous mis à niveau ensemble :
- Portal-base. Comprend les Mbeans d'administration et les logiciels d'administration qui les accompagnent, Logging Framework et les logiciels de surveillance associés, le tout faisant partie d'un package unique.
- Portal Server Applications Web. Consistent en un certain nombre d'applications Web qui sont déployées dans un conteneur Web. Certaines de ces applications Web au moins requièrent une prise en charge de la part d'Access Manager et, par la suite, de Directory Server.
- Secure Remote Access Core. Logiciel prenant en charge Portal Server Secure Remote Access : certains servlets et applets intégrés aux fichiers jar et certains fichiers de prise en charge ne pouvant pas être déployés dans un conteneur Web.
- Le script psupgrade détecte automatiquement quels sous-composants de Portal Server et quelles dépendances de conteneur Web sont installés sur l'ordinateur hôte. Par exemple, le script interroge le système pour déterminer la version d'Application Server ou de Web Server sur laquelle vous déployez les applications Web Portal Server ; il adapte alors les informations demandées en fonction des informations qu'il a pu détecter.
Procédure de mise à niveau (Solaris)
La procédure présentée ci-dessous s'applique au logiciel Portal Server installé sur l'ordinateur sur lequel est effectuée la mise à niveau.
- Connectez-vous en tant qu'utilisateur root ou superutilisateur.
su -
- Si vous ne l'avez pas encore fait, synchronisez tous les composants partagés vers la version 5.
Vous trouverez des instructions dans le Chapter 2, "Mise à niveau des composants partagés Java ES".
Cette étape préalable est requise pour pouvoir exécuter le script psupgrade à l'Step 8.
- Arrêtez toutes les instances de Portal Server Secure Remote Access Gateway, Rewriter Proxy ou Netlet Proxy susceptibles d'être en cours d'exécution localement.
PortalServer6-base/bin gateway stop
PortalServer6-base/bin netletd stop
PortalServer6-base/bin rwproxyd stopAssurez-vous que les processus se sont arrêtés.
Gateway : netstat -an | grep 443
Serveur proxy de réécriture : netstat -an | grep 10443
Serveur proxy Netlet : netstat -an | grep 10555- Vérifiez qu'Access Manager est en cours d'exécution s'il est déployé sur un conteneur Web différent de celui sur lequel Portal Server est déployé.
- S'il n'est pas déjà en cours d'exécution, démarrez Portal Server en démarrant le conteneur Web sur lequel il est déployé.
Web Server 6.x :
WebServer-base/https-nomInstance/startWeb Server 7.0:
Admin Server--
WebServer7Config-base/admin-server/bin/startserv
Instance Server--
WebServer7Config-base/https-nomConfig/bin/startservApplication Server 8.x :
AppServer8-base/bin/asadmin start-domain --user ID_admin
--password mot_de_passe nomDomaine- Définissez deux variables d'environnement (ANT_HOME et JAVA_HOME) requises par le script psupgrade. Par exemple :
export ANT_HOME=/usr/sfw
export JAVA_HOME=/usr/jdk/entsys-j2se- Assurez-vous que vous disposez d'un espace de swap suffisant sur votre ordinateur.
À titre d'information, l'espace de swap doit être défini comme étant égal à deux fois la quantité de mémoire vive (RAM) physique.
- Exécutez le script psupgrade à partir de la distribution Java ES version 5.
cd arch_se/Products/portal_svr/Tools/upgrade/bin
./psupgradeoù arch_se correspond à votre plate-forme, telle que Solaris_sparc.
Remarque
Si, par inadvertance, vous exécutez psupgrade à partir d'un répertoire arch_se inapproprié, vous devez annuler la procédure comme suit :
Le script psupgrade détecte les composants et packages de localisation installés de Portal Server, demande au programme d'installation de Java ES d'installer de nouveaux packages et interroge le système afin de détecter l'emplacement, le numéro de port et d'autres informations concernant le conteneur Web dans lequel vous déployez les applications Web de Portal Server. Selon le scénario de mise à niveau du conteneur Web (voir le Tableau 15-4), le script peut vous demander d'entrer les informations complémentaires requises pour déployer Portal Server sur le conteneur Web approprié.
Le Tableau 15-6 présente les informations requises pour les différents scénarios de mise à niveau du conteneur Web dans le Tableau 15-4.
- Si besoin, restaurez les paramètres JVM du conteneur Web.
Pour vérifier que les paramètres JVM prennent en charge la version 5 de Portal Server, procédez comme suit :
- Assurez-vous que les paramètres JVM du conteneur Web pour Portal Server que vous avez enregistrés avant la mise à niveau n'ont pas été modifiés suite à la procédure de mise à niveau.
Voir la section Enregistrement des paramètres de Java Virtual Machine (JVM).
- S'ils ont changé, restaurez les valeurs que vous aviez enregistrées avant la mise à niveau.
Vérifiez que les paramètres JVM suivants sont inclus, même s'ils n'avaient été précédemment définis :
<jvm-options>-XX:MaxPermSize=256m</jvm-options>
<jvm-options>-XX:+CMSPermGenSweepingEnabled</jvm-options>
<jvm-options>-XX:+CMSClassUnloadingEnabled</jvm-options>- Arrêtez puis redémarrez le conteneur Web.
Bien que ce ne soit pas obligatoire pour toutes les situations, le fait de redémarrer le conteneur Web permet de garantir que Portal Server démarre à partir d'un état propre.
- Arrêtez le conteneur Web comme suit :
Web Server 6.x :
WebServer-base/https-nomInstance/stopWeb Server 7.0:
Admin Server--
WebServer7Config-base/admin-server/bin/stopserv
Instance Server--
WebServer7Config-base/https-nomConfig/bin/stopservApplication Server 8.x :
AppServer8-base/bin/asadmin stop-domain --user ID_admin
--password mot_de_passe nomDomaine- Redémarrez le conteneur Web à l'aide des commandes décrites à l'Step 5.
Mise à niveau de Portal Server pour la version 4 (Linux)
Cette section traite des considérations ayant une incidence sur la procédure de mise à niveau pour Portal Server et décrit ensuite les différentes étapes de cette procédure.
Considérations relatives à la mise à niveau (Linux)
Les mêmes considérations s'appliquent à la mise à niveau de Portal Server vers la version 5 sous Linux et Solaris (voir Considérations relatives à la mise à niveau (Solaris)), sauf que Portal Server version 5 est installé dans le même chemin que la version 4 sur le système d'exploitation Linux. En conséquence, le script psupgrade supprime les RPM précédents lorsqu'il installe les RPM de la version 5.
Procédure de mise à niveau (Linux)
La procédure présentée ci-dessous s'applique au logiciel Portal Server installé sur l'ordinateur sur lequel est effectuée la mise à niveau.
Attention
Il est impossible d'annuler une mise à niveau de la version 4 de Java ES vers la version 5 sous Linux. Veillez à sauvegarder votre système avant d'effectuer la procédure suivante.
- Connectez-vous en tant qu'utilisateur root ou superutilisateur.
su -
- Si vous ne l'avez pas encore fait, synchronisez tous les composants partagés vers la version 5.
Vous trouverez des instructions dans le Chapter 2, "Mise à niveau des composants partagés Java ES".
Cette étape préalable est requise pour pouvoir exécuter le script psupgrade à l'Step 8.
- Arrêtez toutes les instances de Portal Server Secure Remote Access Gateway, Rewriter Proxy ou Netlet Proxy susceptibles d'être en cours d'exécution localement.
PortalServer6-base/bin gateway stop
PortalServer6-base/bin netletd stop
PortalServer6-base/bin rwproxyd stopAssurez-vous que les processus se sont arrêtés.
Gateway : netstat -an | grep 443
Serveur proxy de réécriture : netstat -an | grep 10443
Serveur proxy Netlet : netstat -an | grep 10555- Vérifiez qu'Access Manager est en cours d'exécution s'il est déployé sur un conteneur Web différent de celui sur lequel Portal Server est déployé.
- S'il n'est pas déjà en cours d'exécution, démarrez Portal Server en démarrant le conteneur Web sur lequel il est déployé.
Web Server 6.x :
WebServer-base/https-nomInstance/startWeb Server 7.0:
Admin Server--
WebServer7Config-base/admin-server/bin/startserv
Instance Server--
WebServer7Config-base/https-nomConfig/bin/startservApplication Server 8.x :
AppServer8-base/bin/asadmin start-domain --user ID_admin
--password mot_de_passe nomDomaine- Définissez deux variables d'environnement (ANT_HOME et JAVA_HOME) requises par le script psupgrade. Par exemple :
export ANT_HOME=/opt/sun
export JAVA_HOME=/usr/jdk/entsys-j2se- Assurez-vous que vous disposez d'un espace de swap suffisant sur votre ordinateur.
À titre d'information, l'espace de swap doit être défini comme étant égal à deux fois la quantité de mémoire vive (RAM) physique.
- Exécutez le script psupgrade à partir de la distribution Java ES version 5.
cd arch_se/Products/portal_svr/Tools/upgrade/bin
./psupgradeoù arch_se correspond à votre plate-forme, telle que Linux_x86.
Le script psupgrade détecte les composants et packages de localisation installés de Portal Server, demande au programme d'installation de Java ES d'installer de nouveaux packages et interroge le système afin de détecter l'emplacement, le numéro de port et d'autres informations concernant le conteneur Web dans lequel vous déployez les applications Web de Portal Server. Selon le scénario de mise à niveau du conteneur Web (voir le Tableau 15-4), le script peut vous demander d'entrer les informations complémentaires requises pour déployer Portal Server sur le conteneur Web approprié.
Le Tableau 15-6 présente les informations requises pour les différents scénarios de mise à niveau du conteneur Web dans le Tableau 15-4.
- Modifiez le fichier de configuration PortalServer7Config-base/platform.conf.default.
Copiez la ligne comportant gateway.logging.password à partir du fichier suivant, lequel a été sauvegardé par psupgrade :
PortalServer6Config-base.bak/platform.conf.default
et placez cette ligne dans PortalServer7Config-base/platform.conf.default.
- Si besoin, restaurez les paramètres JVM du conteneur Web.
Pour vérifier que les paramètres JVM prennent en charge la version 5 de Portal Server, procédez comme suit :
- Assurez-vous que les paramètres JVM du conteneur Web pour Portal Server que vous avez enregistrés avant la mise à niveau n'ont pas été modifiés suite à la procédure de mise à niveau.
Voir la section Enregistrement des paramètres de Java Virtual Machine (JVM).
- S'ils ont changé, restaurez les valeurs que vous aviez enregistrées avant la mise à niveau.
Vérifiez que les paramètres JVM suivants sont inclus, même s'ils n'avaient été précédemment définis :
<jvm-options>-XX:MaxPermSize=256m</jvm-options>
<jvm-options>-XX:+CMSPermGenSweepingEnabled</jvm-options>
<jvm-options>-XX:+CMSClassUnloadingEnabled</jvm-options>- Arrêtez puis redémarrez le conteneur Web.
Bien que ce ne soit pas obligatoire pour toutes les situations, le fait de redémarrer le conteneur Web permet de garantir que Portal Server démarre à partir d'un état propre.
- Arrêtez le conteneur Web comme suit :
Web Server 6.x :
WebServer-base/https-nomInstance/stopWeb Server 7.0:
Admin Server--
WebServer7Config-base/admin-server/bin/stopserv
Instance Server--
WebServer7Config-base/https-nomConfig/bin/stopservApplication Server 8.x :
AppServer8-base/bin/asadmin stop-domain --user ID_admin
--password mot_de_passe nomDomaine- Redémarrez le conteneur Web à l'aide des commandes décrites à l'Step 5.
Vérification de la mise à niveau
Vous pouvez vérifier l'installation des packages de la version 5 à l'aide de la commande suivante :
Voir le Tableau 15-5 pour les valeurs de résultat.
Pour vérifier l'intégrité de la mise à niveau, confirmez l'affichage du bureau du portail et le fonctionnement de l'utilitaire d'administration psadmin tel qu'il est documenté.
Vous pouvez également consulter les fichiers journaux de mise à niveau suivants :
Tâches à exécuter après la mise à niveau de la version 4
Veuillez noter les procédures post-mise à niveau requises dans le cadre des situations suivantes :
Migration des données web-src personnalisées
Si vous avez ajouté des données personnalisées, telles que des images, des fichiers javascript ou tout autre fichier pour construire portal.war dans le répertoire suivant :
PortalServer6-base/web-src
vous devez copier ces fichiers supplémentaires dans le répertoire correspondant de la version 5 de Portal Server :
PortalServer7-base/web-src
Redéploiement des applications de portlet personnalisées
Si vous avez créé et déployé des applications de portlet personnalisées, ces portlets doivent être redéployés manuellement après la mise à niveau vers la version 5 de Portal Server. Bien que les entrées de profil d'affichage existent et que le nom de canal s'affiche, le contenu ne sera pas visible tant que vous n'aurez pas redéployé vos portlets personnalisés.
Redéployez les portlets à l'aide de la commande suivante :
PortalServer7-base/bin/psadmin deploy-portlet
Vous pouvez confirmer le redéploiement en recherchant les fichiers .war et XML correspondants dans l'emplacement suivant :
PortalServer7Data-base/portals/Upgraded/war
Migration des applications de portlet personnalisées
La migration vers la version 5 et le redéploiement des applications de portlet basées sur la structure d'interface utilisateur fournie par Sun Java Web Console (SJWC) doivent être effectués manuellement.
Cette obligation s'applique particulièrement aux quatre applications Web distribuées à l'aide de Portal Server en tant qu'exemples d'applications de portlet destinées à être personnalisées et installées sur un portail : filesharing, surveys, wiki et rssportlet. Pendant la mise à niveau, des versions aux bogues corrigés de ces exemples d'applications de portlet seront placées sur le disque dans la zone des applications de portlet. Si vous disposez de ces applications de portlet personnalisées pour votre propre usage, vous devez les faire migrer manuellement vers la version 5, puis les redéployer ; elles ne sont pas prises en compte par le processus de mise à niveau de Portal Server.
Par défaut, certaines de ces applications de portlet (filesharing et surveys) sont déployés et disponibles pour les utilisateurs lorsqu'une communauté est créée.
Vous pouvez mettre à niveau, personnaliser et redéployer les applications de portlet basées sur SJWC à l'aide de la procédure suivante. L'application de portlet filesharing est utilisée à titre d'exemple :
- Procédez à l'extraction des fichiers jar SJWC de la version 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- Renommez l'un des fichiers.
mv WEB-INF/lib/commons-collections-3.1.jar
WEB-INF/lib/commons-collections.jar- Recherchez l'application de portlet filesharing.
cd PortalServer7Config-base/portals/portal1/portletapps/filesharing
- Injectez les bibliothèques SJWC mises à jour.
jar uvf src/filesharing.war.tokenized -C /tmp/lh WEB-INF
- Personnalisez l'application de portlet filesharing.
ant customize
- Redéployez l'application de portlet filesharing.
- PortalServer7-base/bin/psadmin undeploy-portlet -u amadmin
-f passwordfile -p ID_portail -i ID_instance -g filesharing- ant deploy
- Allez dans le répertoire suivant (selon le conteneur Web) :
Application Server 8.x :
AppServer8Config-base/domains/domain1/applications/j2ee-modules/
communityportlets/WEB-INFWeb Server 6.x :
WebServer6-base/https-nomInstance/webapps/https-nomInstance/
communityportlets/WEB-INFWeb Server 7.x :
WebServer7Config-base/https-nomConfig/web-app/https-nomConfig/
communityportlets/WEB-INF- Ouvrez le fichier sun-web.xml et ajoutez la ligne suivante juste avant la dernière ligne (c'est-à-dire avant la balise de fin sun-web-app) :
<class-loader delegate="false"/>
- Répétez la procédure de l'Step 2 à l'Step 5 pour surveys et toutes les autres applications de portlet personnalisées basées sur la structure SJWC.
- Redémarrez le conteneur Web.
Correction des liens dans les canaux d'applications et de signets
Lors de la mise à niveau de la version 4 vers la version 5 de Portal Server, les liens vers les canaux d'applications et de signets sont en double et erronés. Pour remédier à ce problème, procédez comme suit :
- Connectez-vous à la PSConsole.
- Dans l'onglet Tâches courantes, cliquez sur l'option Gérer les canaux et les conteneurs.
- Sélectionnez DeveloperSample [Org] comme DN et cliquez sur OK.
- Sélectionnez JSPTabContainer [default] comme type d'affichage.
- Dans MyFrontPageTabPanelContainer, cliquez sur Canaux d'app.
Les propriétés du canal d'application s'affichent dans le cadre de droite.
Pour afficher les propriétés d'un environnement linguistique en particulier, cliquez sur Préférences du tableau et sélectionnez un environnement linguistique : de, fr, es, ja, ko, zh, zh_CN, zh_TW.
- Modifiez la propriété userApps.
- Modifiez la propriété de la cible.
- Dans la propriété de la cible, cliquez sur le lien [Edit Values...]
Une fenêtre contextuelle contenant les cibles s'affiche.
- Supprimez de la liste les cibles suivantes :
NetMailLite|
NetMailServlet?nsid=newHTMLSessionNetMailLite|
NetMailServlet?nsid=newHTMLSessionNetMail|NetMailServlet?nsid=newAppletSession
- Supprimez l'occurrence en double des cibles suivantes :
Instant Messenger (Java WebStart)|
IMLaunch?provider=IMChannel&launch=jnlp&last=falseCorrection de l'accès au serveur de recherche
Lorsque vous procédez à la mise à niveau de la version 4 de Portal Server à la version 5, le serveur de recherche est séparé de Portal Server et l'URL d'accès au serveur de recherche est par conséquent modifié.
Il en résulte que vous devez modifier manuellement les profils d'affichage de tous les canaux de portail prenant en charge les interfaces SearchProvider ou DiscussionProvider, tels que les canaux Search, DiscussionLite, Discussions et Instant Messaging. Pour référencer correctement le serveur de recherche, vous devez notamment modifier la propriété searchServer de ces canaux, quel que soit le niveau d'organisation ou de rôle auquel elle intervient à l'intérieur du profil d'affichage. Modifiez la valeur searchServer comme suit :
De même, pour le canal Instant Messaging, la propriété de configuration du serveur Instant Messaging, iim_arch.portal.search, doit être mise à jour avec le nouvel URL du serveur de recherche.
Restauration de la configuration pour Directory Proxy Server ;
Si des instances de Portal Server ont accès à Directory Server via une instance de Directory Proxy Server ;, les valeurs initiales des paramètres d'hôte et de numéro de port de Directory Proxy Server ; doivent être restaurées. Voir la section Suppression de la configuration pour Directory Proxy Server ;, dans laquelle les valeurs de ces propriétés ont été modifiées dans l'optique d'une mise à niveau.
Enregistrement manuel des composants de Portal Server Secure Remote Access
Si vous rencontrez un problème d'exception de pointeur nul signalé dans le résultat standard à la fin de la procédure de mise à niveau, cela signifie que l'enregistrement des composants éventuels de Portal Server Secure Remote Access a échoué.
Dans ce cas, vous pouvez enregistrer manuellement (activer) les composants de Portal Server Secure Remote Access à l'aide de la commande suivante :
PortalServer7-base/bin/psadmin provision-sra -u utilisateurAmadmin -f fichierMotdepasse
-p ID_portail --gateway-profile nomProfil --enableActivation du canal URLScrapper
Lors de la mise à niveau de la version 4 vers la version 5, vous devez activer le canal URLScrapper. Procédez comme suit :
- Connectez-vous à la console Portal Server.
Cliquez sur l'onglet Portail, puis sur le portail mis à jour.
- Dans le menu déroulant Sélectionner DN, sélectionnez Niveau supérieur (global), puis cliquez sur le lien Télécharger un profil d'affichage.
Stockez le fichier temporaire dans un emplacement temporaire de votre choix.
- Recherchez com.sun.portal.providers.urlscraper.URLScraperProvider.
- Recherchez la partie XML commençant par :
<Provider advanced="false" class="com.sun.portal.providers.urlscraper.URLScraperProvider"
et terminant par :
</Provider>
- Remplacez la partie XML à l'Step 4 par ce qui suit :
<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>
- Enregistrez et chargez le fichier modifié.
Modification dans la page de déconnexion
La page de déconnexion de Portal Server version 5 a changé par rapport à la page de déconnexion précédente d'Access Manager. Notez que ce changement ne représente pas un défaut du logiciel.
Annulation de la mise à niveau (Solaris)
Cette section décrit les points qui ont une influence sur la procédure d'annulation de la mise à niveau de Portal Server, suivis par la description de la procédure elle-même.
Éléments de l'annulation de la mise à niveau (Solaris)
La procédure d'annulation de la mise à niveau vers la version 5 consiste à rétablir l'installation de la version 4 sur PortalServer6-base et à redéployer les applications Web de la version 4.
Procédure d'annulation de la mise à niveau (Solaris)
- Connectez-vous en tant qu'utilisateur root ou superutilisateur.
su -
- Restaurez Directory Server dans l'état où il se trouvait avant la mise à niveau.
Utilisez la ligne de commande de sauvegarde/restauration et les utilitaires de l'interface graphique utilisateur de Directory Server. Reportez-vous au chapitre « Sauvegarde et restauration de Directory Server » du Guide d'administration de Sun Java System Directory Server Enterprise Edition 6.0, http://docs.sun.com/doc/819-0995.
- Arrêtez Portal Server en fermant son conteneur Web.
Web Server 6.x :
WebServer-base/https-nomInstance/stopWeb Server 7.0:
Admin Server--
WebServer7Config-base/admin-server/bin/stopserv
Instance Server--
WebServer7Config-base/https-nomConfig/bin/stopservApplication Server 8.x :
AppServer8-base/bin/asadmin stop-domain --user ID_admin
--password mot_de_passe nomDomaine- Supprimez les packages de Portal Server version 5.
- Redémarrez Portal Server en redémarrant son conteneur Web.
Web Server 6.x :
WebServer-base/https-nomInstance/startWeb Server 7.0:
Admin Server--
WebServer7Config-base/admin-server/bin/startserv
Instance Server--
WebServer7Config-base/https-nomConfig/bin/startservApplication Server 8.x :
AppServer8-base/bin/asadmin start-domain --user ID_admin
--password mot_de_passe nomDomaine- Redéployez les applications Web de Portal Server version 4 en utilisant la commande suivante à partir de la distribution Java ES version 5 :
cd arch_se/Products/portal_svr/Tools/upgrade/bin
./psupgrade rollbackoù arch_se correspond à votre plate-forme, telle que Solaris_sparc.
La commande psupgrade rollback annule le déploiement des applications Web de Portal Server version 5 et redéploie les applications Web de Portal Server version 4.
La commande redéploie le contenu de PortalServer6-base/web-src sur /var/PortalServe6-base/https-nomHôte/deploy-dir/web-apps. Toutes les personnalisations de l'application Web Portal Server doivent d'abord être effectuées sur /web-src puis déployées vers /web-apps. Toute modification apportée sous /web-apps doit être répliquée dans /web-src avant l'exécution de la commande psupgrade rollback, sans quoi elle sera perdue.
- Arrêtez puis redémarrez le conteneur Web.
Bien que ce ne soit pas obligatoire pour toutes les situations, le fait de redémarrer le conteneur Web permet de garantir que Portal Server démarre à partir d'un état propre.
Annulation de la mise à niveau (Linux)
Comme la mise à niveau vers la version 5 requiert la suppression des fichiers binaires de la version 4, il est extrêmement difficile d'annuler la mise à niveau sur Linux.
L'annulation peut être envisagée comme la création et le test d'un système parallèle avant la mise à niveau. Si vous devez annuler la mise à niveau, vous pouvez revenir à ce système parallèle.
Mise à niveau de plusieurs instances
Dans certaines architectures, Portal Server est déployé sur plusieurs systèmes afin de permettre une meilleure évolutivité et une disponibilité accrue. Par exemple, certaines instances de Portal Server peuvent être exécutés sur plusieurs ordinateurs avec un équilibreur de charge pour répartir la charge.
Dans le cas d'instances de Portal Server avec équilibrage de charge, vous pouvez exécuter une mise à niveau progressive, au cours de laquelle les différentes instances de Portal Server seront successivement mises à niveau sans interruption du service, comme le décrit la procédure ci-dessous. La procédure prend en considération la contrainte suivante : la version 4 de Portal Server ne fonctionne pas avec les données d'annuaire de Portal Server version 5.
L'architecture de déploiement représentée à la Figure 15-1 permettra d'illustrer la procédure de mise à niveau progressive des instances de Portal Server version 4 vers la version 5.
Remarque
Pour les architectures comprenant des composants de Portal Server Secure Remote Access, voir la section Mise à niveau de plusieurs instances.
Dans l'architecture de la Figure 15-1, l'accès aux différentes instances de Portal Server se fait via un équilibreur de charge afin d'offrir disponibilité et évolutivité. Les instances de Portal Server accèdent à leur tour aux instances d'Access Manager via un équilibreur de charge. Les instances d'Access Manager et d'Access Manager SDK accèdent à un annuaire configuré pour une réplication multimaître (MMR). Bien que d'autres schémas de réplication de Directory Server soient possibles, la MMR représente des services d'annuaire hautement disponibles et évolutifs.
Dans la Figure 15-1, les instances multiples de Portal Server, Access Manager et de Directory Server sont regroupées afin de faciliter l'explication de la procédure de mise à niveau. Portal Server 2, par exemple, représente les instances de Portal Server comprises entre la 2ème et la énième instance.
Figure 15-1 Exemple d'architecture de déploiement pour plusieurs instances de Portal Server
La mise à niveau progressive de Portal Server version 4 vers la version 5 est réalisée comme suit :
- Si vous effectuez la mise à niveau d'Access Manager version 4 vers la version 5, choisissez une mise à niveau progressive comme le décrit la section Mise à niveau de plusieurs instances. Notez que dans le cadre de la mise à niveau de Portal Server version 4 vers la version 5, il n'est requis de mettre à niveau Access Manager version 4 vers la version 5.
- Configurez Portal Server 2 afin qu'il pointe vers Directory Server 2 plutôt que vers Directory Server 1.
Pour plus de simplicité dans cette étape et dans les suivantes, Portal Server 2 désignera les instances Portal Server 2 à Portal Server n.
- Procédez à la mise à niveau de Portal Server 1.
- Désactivez Portal Server 1 dans Load Balancer B.
Les requêtes ne seront alors plus acheminées vers Portal Server 1.
- Désactivez la réplication multimaître de Directory Server.
Directory Server 2 ne sera alors plus synchronisé avec Directory Server 1.
- Procédez à la mise à niveau d'Access Manager SDK 1B vers la version 5.
Utilisez la procédure décrite dans la section Mises à niveau concernant uniquement le SDK d'Access Manager pour la version 4.
- Procédez à la mise à niveau de Portal Server 1 vers la version 5.
Effectuez la mise à niveau de l'instance de Portal Server telle qu'elle est décrite dans la section Mise à niveau de Portal Server pour la version 4, en prenant en compte les éléments suivants :
- Prenez particulièrement en considération la tâche suivante préalable à la mise à niveau : Suppression de la configuration de l'équilibreur de charge.
- Confirmez, avant de procéder à la mise à niveau, que la valeur de am.encryption.pwd dans le fichier AccessManagerConfig-base/config/AMConfig.properties est la même pour l'installation d'Access Manager SDK locale que pour l'instance d'Access Manager distante qui y est associée.
- Veillez à indiquer une valeur unique non nulle pour le paramètre Portal Instance ID demandé par psupgrade pour chaque instance de Portal Server que vous mettez à niveau.
Les données de Portal Server pour Directory Server 1 sont mises à jour vers la version 5.
- Activez Portal Server 1 dans Load Balancer B.
Les requêtes seront alors à nouveau acheminées vers Portal Server 1.
- Procédez à la mise à niveau de Portal Server 2.
- Désactivez Portal Server 2 dans Load Balancer B.
Les requêtes ne seront alors plus acheminées vers Portal Server 2.
- Restaurez la configuration de Portal Server 2 afin qu'il pointe vers Directory Server 1.
- Procédez à la mise à niveau d'Access Manager SDK 2B vers la version 5.
Utilisez la même procédure qu'à l'Step c.
- Procédez à la mise à niveau de Portal Server 2 vers la version 5.
Utilisez la même procédure qu'à l'Step d.
- Activez Portal Server 2 dans Load Balancer B.
Les requêtes seront alors à nouveau acheminées vers Portal Server 2.
- Activez la réplication multimaître de Directory Server.
Les données de Portal Server pour Directory Server 2 sont alors synchronisées avec les données de Directory Server 1.
Mise à niveau de Portal Server à partir de Java ES version 3La procédure de mise à niveau de Java ES 2005Q1 (version 3) Portal Server vers la version 5 est la même que pour la mise à niveau de Portal Server version 4 vers la version 5, avec néanmoins les exceptions suivantes :
Tâche à exécuter avant la mise à niveau de la version 3 : Mise à niveau des dépendances de Portal Server
Lorsque vous procédez à la mise à niveau de Portal Server à partir de la version 3, vous devez mettre à niveau à la fois Access Manager et le conteneur Web (Web Server ou Application Server) vers la version 4 ou 5 avant de mettre à niveau Portal Server, mais vous ne pouvez pas conserver de dépendances au niveau de la version 3 ni mettre à niveau certaines dépendances vers la version 4 et d'autres vers la version 5. Pour plus d'informations, reportez-vous à la section Problèmes liés à la mise à niveau sélective.
La mise à niveau des dépendances suivantes doit être effectuée dans l'ordre présenté ci-dessous.
- Composants partagés. Les instructions de mise à niveau des composants partagés Java ES vers la version 5 sont présentées dans le Chapter 2, "Mise à niveau des composants partagés Java ES".
- Directory Server. Les instructions de mise à niveau de Directory Server vers la version 5 sont présentées dans le Chapter 5, "Directory Server".
- Logiciels de conteneur Web. Les instructions de mise à niveau de Web Server ou d'Application Server sont présentées respectivement dans le Chapter 7, "Web Server" et le Chapter 11, "Application Server".
- Access Manager (kit SDK d'Access Manager). Les instructions de mise à niveau d'Access Manager vers la version 5 sont présentées dans le Chapter 14, "Access Manager".
Mise à niveau de la version 3 Portal Server
Pour mettre à niveau Portal Server pour la version 3 vers la version 5, suivez les instructions décrites dans la section Mise à niveau de Portal Server à partir de Java ES version 4, mais remplacez chaque fois version 4 par version 3.
Tâches à exécuter après la mise à niveau de la version 3
Lorsque vous mettez à niveau Portal Server pour la version 3 vers la version 5, outre les procédures post-mise à niveau décrites dans la section Tâches à exécuter après la mise à niveau de la version 4, vous devez effectuer les procédures post-mise à niveau requises dans le cadre des situations suivantes :
Abonnement à une discussion
L'abonnement à une discussion dans une communauté échouera à moins que vous ne modifiiez préalablement les propriétés de niveau supérieur du profil d'affichage global afin d'ajouter la propriété String suivante :
helpURL=en/desktop/usedesk.htm
Procédez comme suit :
- Créez un fichier snippet XML de profil d'affichage, helpUrl.xml:
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE DisplayProfile SYSTEM "jar://resources/psdp.dtd">
<Properties>
<String name="helpURL" value="en/desktop/usedesk.htm" />
</Properties>- Exécutez les propriétés de profil d'affichage global à l'aide de la commande suivante :
./psadmin modify-dp -u utilisateurAmadmin -f /tmp/fichierMotdepasse -p ID_portail
-m -g helpUrl.xmloù -m est requise afin de ne pas écraser l'ensemble du profil d'affichage global.
Mise à niveau de plusieurs instances
Dans certaines architectures, Portal Server est déployé sur plusieurs systèmes afin de permettre une meilleure évolutivité et une disponibilité accrue. Par exemple, certaines instances de Portal Server peuvent être exécutés sur plusieurs ordinateurs avec un équilibreur de charge pour répartir la charge.
Dans le cas d'instances de Portal Server avec équilibrage de charge, vous pouvez exécuter une mise à niveau progressive, au cours de laquelle les différentes instances de Portal Server seront successivement mises à niveau sans interruption du service, comme le décrit la procédure ci-dessous. La procédure prend en considération la contrainte suivante : la version 3 de Portal Server ne fonctionne pas avec les données d'annuaire de Portal Server version 5.
Pour réaliser une mise à niveau progressive de Portal Server version 3 vers la version 5, utilisez la procédure décrite dans la section Mise à niveau de plusieurs instances, mais remplacez chaque fois version 3 par version 4. En outre, vous devez mettre à niveau Access Manager, comme le décrit l'Step 1.
Mise à niveau de Portal Server à partir de Java ES version 2Cette section présente des informations sur la mise à niveau de Portal Server pour Java ES 2004Q2 (version 2) vers la version 5. La procédure de mise à niveau est similaire est celle qui s'applique à la mise à niveau de Portal Server version 4 vers la version 5, à l'exception de certains changements décrits dans les sections suivantes :
Remarque
Si vous procédez à une mise à niveau de Portal Server pour la version 2 sur la plate-forme Linux, il vous faudra procéder à une double mise à niveau (pour Portal Server et le système d'exploitation). Portal Server pour la version 5 n'est pas pris en charge sur RHEL 2.1. Pour plus d’informations, reportez-vous à la section Double mise à niveau.
Tâches à exécuter avant la mise à niveau de la version 2
Les tâches préalables à la mise à niveau de Portal Server version 2 sont les mêmes que celles qui sont décrites dans la section Tâches à exécuter avant la mise à niveau de la version 4, à l'exception de tout ce qui concerne la mise à niveau des dépendances de Portal Server.
Lorsque vous procédez à la mise à niveau de Portal Server à partir de la version 2, vous devez mettre à niveau à la fois Access Manager et le conteneur Web (Web Server ou Application Server) vers la version 4 ou 5 avant de mettre à niveau Portal Server, mais vous ne pouvez pas conserver de dépendances au niveau de la version 2 ni mettre à niveau certaines dépendances vers la version 4 et d'autres vers la version 5. Pour plus d'informations, reportez-vous à la section Problèmes liés à la mise à niveau sélective.
En particulier, le logiciel du conteneur Web doit être mis à niveau à partir de la version 2, ce qui signifie que seuls les scénarios 2 et 5 du Tableau 15-4 sont pris en charge lorsque vous exécutez le script psupgrade.
La mise à niveau des dépendances suivantes doit être effectuée dans l'ordre présenté ci-dessous.
- Composants partagés. Les instructions de mise à niveau des composants partagés Java ES vers la version 5 sont présentées dans le Chapter 2, "Mise à niveau des composants partagés Java ES".
- Directory Server. Les instructions de mise à niveau de Directory Server vers la version 5 sont présentées dans la section Mise à niveau de Directory Server à partir de Java ES version 2.
- Logiciels de conteneur Web. Les instructions de mise à niveau de Web Server ou d'Application Server sont présentées respectivement dans le Chapter 7, "Web Server" et le Chapter 11, "Application Server".
- Access Manager (kit SDK d'Access Manager). Les instructions de mise à niveau d'Access Manager vers la version 5 sont présentées dans le Chapter 14, "Access Manager".
Mise à niveau de la version 2 Portal Server
La procédure de mise à niveau de Portal Server à partir de la version 2 vers la version 5 dépend du conteneur Web dans lequel vous déployez le logiciel Portal Server, comme le décrivent les sections suivantes.
Mise à niveau de Portal Server version 2 : conteneur Web Web Server
Pour mettre à niveau Portal Server version 2 vers la version 5, lors d'un déploiement dans un conteneur Web Web Server, suivez les instructions décrites dans la section Mise à niveau de Portal Server à partir de Java ES version 4, en remplaçant chaque occurrence de version 4 par version 2.
Toutefois, si Portal Server est déployé dans Web Server version 5 (Web Server 7.0), vous devez effectuer la procédure suivante avant de mettre à niveau Web Server version 2 :
Mise à niveau de Portal Server version 2 : conteneur Web Application Server
Lorsque vous mettez à niveau Portal Server version 2 vers la version 5 et que vous déployez dans un conteneur Web Application Server, Application Server est mis à niveau de la version 2 vers la version 5.
L'instance d'Application Server version 2 dans laquelle Portal Server a été initialement déployé (nomInstance), lors de la mise à niveau vers la version 5, a été migrée sous un agent de nud créé par le processus de mise à niveau de Application Server. La mise à niveau de Portal Server, dans cette instance d'Application Server mise à niveau, requiert la procédure suivante :
- Connectez-vous en tant qu'utilisateur root ou superutilisateur.
su -
- Si vous ne l'avez pas encore fait, synchronisez tous les composants partagés vers la version 5.
Vous trouverez des instructions dans le Chapter 2, "Mise à niveau des composants partagés Java ES".
Cette étape préalable est requise pour pouvoir exécuter le script psupgrade à l'Step 9.
- Arrêtez toutes les instances de Portal Server Secure Remote Access Gateway, Rewriter Proxy ou Netlet Proxy susceptibles d'être en cours d'exécution localement.
PortalServer6-base/bin gateway stop
PortalServer6-base/bin netletd stop
PortalServer6-base/bin rwproxyd stopAssurez-vous que les processus se sont arrêtés.
Gateway : netstat -an | grep 443
Serveur proxy de réécriture : netstat -an | grep 10443
Serveur proxy Netlet : netstat -an | grep 10555- Vérifiez qu'Access Manager est en cours d'exécution s'il est déployé sur un conteneur Web différent de celui sur lequel Portal Server est déployé.
- S'il n'est pas déjà en cours d'exécution, démarrez Portal Server en démarrant le conteneur Web sur lequel il est déployé.
- Démarrez le serveur d'administration de domaine si ce n'est déjà fait.
AppServer8-base/bin/asadmin start-domain --user ID_admin
--password mot_de_passe nomDomaine- Démarrez l'instance mise à niveau d'Application Server, sur laquelle Portal Server est déployé (nomInstance), si elle n'est pas déjà en cours d'exécution.
Pour ce faire, démarrez l'agent du nud sous lequel l'instance mise à niveau d'Application Server a été migrée :
AppServer8-base/bin/asadmin start-node-agent --user ID_admin
--password mot_de_passe nomAgentNudDans les commandes ci-dessus et dans les étapes suivantes les conventions suivantes sont utilisées :
- où nomAgentNudpossède la forme nomHôte_nomDomaine, mais est simplement nomHôte par défaut.
- La valeur par défaut de nomDomaine est domain1
- La valeur par défaut de nomInstance est server1
- Annulez le déploiement des composants de Portal Server.
AppServer8-base/bin/asadmin undeploy --user ID_admin
--password mot_de_passe --target nomInstance portalAppServer8-base/bin/asadmin undeploy --user ID_admin
--password mot_de_passe --target nomInstance portletsamples- Définissez deux variables d'environnement (ANT_HOME et JAVA_HOME) requises par le script psupgrade. Par exemple :
SE Solaris :
export ANT_HOME=/usr/sfw
export JAVA_HOME=/usr/jdk/entsys-j2seSystème d'exploitation Linux :
export ANT_HOME=/opt/sun
export JAVA_HOME=/usr/jdk/entsys-j2se- Assurez-vous que vous disposez d'un espace de swap suffisant sur votre ordinateur.
À titre d'information, l'espace de swap doit être défini comme étant égal à deux fois la quantité de mémoire vive (RAM) physique.
- Exécutez le script psupgrade à partir de la distribution Java ES version 5.
cd arch_se/Products/portal_svr/Tools/upgrade/bin
./psupgradeoù arch_se correspond à votre plate-forme, telle que Solaris_sparc.
Remarque
Si, par inadvertance, vous exécutez psupgrade à partir d'un répertoire arch_se inapproprié, vous devez annuler la procédure comme suit :
Le script psupgrade demande au programme d'installation de Java ES d'installer de nouveaux packages et interroge le système afin de détecter l'emplacement, le numéro de port et d'autres informations concernant le conteneur Web dans lequel vous déployez les applications Web de Portal Server. Selon le scénario de mise à niveau du conteneur Web (voir le Tableau 15-4), en l'occurrence le scénario 5, le script peut vous demander d'entrer les informations requises pour déployer Portal Server sur le conteneur Web approprié.
Le Tableau 15-6 présente les informations requises lorsqu'Application Server version 2 a été mis à niveau vers la version 5 (scénario 5).
- Arrêtez le serveur d'administration de domaine et l'agent de nud que vous aviez démarrés à l'Step 5.
AppServer8-base/bin/asadmin stop-domain --user ID_admin
--password mot_de_passe nomDomaineAppServer8-base/bin/asadmin stop-node-agent --user ID_admin
--password mot_de_passe nomAgentNud- Redémarrez le serveur d'administration de domaine, l'agent du nud et l'instance de serveur que vous aviez arrêtés à l'Step 10.
Remarque
Veillez à démarrer séparément l'agent du nud à l'aide de l'option startinstances=false avant de démarrer l'instance de serveur, comme cela est décrit ci-dessous.
AppServer8-base/bin/asadmin start-domain --user ID_admin
--password mot_de_passe nomDomaineAppServer8-base/bin/asadmin start-node-agent --port numéroPortDAS --startinstances=false --user ID_admin --password mot_de_passe nomAgentNud
AppServer8-base/bin/asadmin start-instance --port numéroPortDAS --user ID_admin --password mot_de_passe nomInstance
La valeur par défaut de numéroPortDAS est 4848.
Tâches à exécuter après la mise à niveau de la version 2
Lorsque vous mettez à niveau Portal Server version 2 vers la version 5, vous devez effectuer, outre les procédures post-mise à niveau décrites dans la section Tâches à exécuter après la mise à niveau de la version 4, les procédures post-mise à niveau requises dans le cadre des situations suivantes :
Configuration de la connexion unique
Après la mise à niveau de Portal Server à partir de la version 2, les canaux de communication du bureau du portail, tels que Courrier, Calendrier et Carnet d'adresses, qui utilisent le méta-modèle ssoadapter pour accéder à un serveur d'arrière-plan, vont échouer.
Par exemple, si vous avez modifié le méta-modèle ssoadapter de courrier de la version 2, SUN-UWC-MAIL, avec des paramètres propres à votre serveur de messagerie, après la mise à niveau vers la version 5, deux méta-modèles ssoadapter SUN-UWC-MAIL coexisteront : un dans votre version 2, qui n'aura pas été modifié, et l'autre dans la nouvelle version 5. Vous pourrez alors constater que vous avez des méta-modèles ssoadapter en double et avec le même nom dans la console Portal Server et l'interface de ligne de commande psadmin.
Les canaux qui utilisent les méta-modèles ssoadapter seront dans l'impossibilité d'établir une connexion avec le serveur d'arrière-plan et de récupérer les données.
Pour remédier à ce problème, vous devez récupérer les données du méta-modèle ssoadapter, renommer les entrées en double, puis remplacer les données modifiées. Procédez comme suit :
- Exportez les données du méta-modèle ssoadapter.
Faites appel à l'utilitaire amadmin pour exporter les données de service Access Manager, comme suit :
- Créez un fichier de requête amadmin, /tmp/ssoadapter-template-gets.xml.
Ce fichier permettra à l'utilitaire de récupérer les données du méta-modèle ssoadapter :
<?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"
>
<Requêtes>
<SchemaRequests serviceName="SunSSOAdapterService" SchemaType="global">
<GetServiceDefaultValues>
<Attribute name="sunConfigurationTemplates" />
</GetServiceDefaultValues>
</SchemaRequests>
</Requests>- Exécutez la commande asadmin suivante :
AccessManager-base/bin/amadmin -u utilisateurAmadmin -w mot_de_passe
-t ssoadapter-templates-get.xml > /tmp/ssoadapter-templates.xmlLe résultat de la commande est enregistré dans /tmp/ssoadapter-templates.xml.
Le fichier /tmp/ssoadapter-templates.xml possède le format suivant :
sunConfigurationTemplates=
ssoadapter meta-template1>, <ssoadapter meta-template2>, ...]et chaque <ssoadapter meta-template> présente la syntaxe suivante :
default|imap:/?configName=SUN-UWC-MAIL
&proxyAdminPassword=%5BPROXY-ADMIN_PASSWORD%5D&subType=sun-one
&enableProxyAuth=false ...- Modifiez le fichier /tmp/ssoadapter-templates.xml afin de renommer les méta-modèles ssoadapter en double.
- Recherchez chaque modèle dans le fichier /tmp/ssoadapter-templates.xml.
Recherchez la chaîne default|imap:/?configName=.
- Remplacez les noms de méta-modèle ssoadapter en double par des valeurs uniques.
Par exemple, s'il existe deux méta-modèles ssoadapter SUN-UWC-MAIL, remplacez la valeur configName de l'un d'eux par SUN-UWC-MAIL2, ce qui génère deux modèles au nom unique :
default|imap:/?configName=SUN-UWC-MAIL ...
default|imap:/?configName=SUN-UWC-MAIL2 ...- Créez un fichier de requête amadmin qui importera les méta-modèles ssoadapter modifiés et écrasera les données d'origine.
- Copiez le fichier /tmp/ssoadapter-templates.xml dans /tmp/ssoadapter-new-templates.xml.
- Dans /tmp/ssoadapter-new-templates.xml, remplacez la chaîne :
sunConfigurationTemplates=[
par
<?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"
>
<Requêtes>
<SchemaRequests serviceName="SunSSOAdapterService" SchemaType="Global">
<ModifyDefaultValues>
<AttributeValuePair>
<Attribute name="sunConfigurationTemplates" />- Remplacez toutes les perluètes (« & ») par « & ».
Par exemple, la ligne :
default|imap:/?configName=SUN-UWC-MAIL
&proxyAdminPassword=%5BPROXY-ADMIN_PASSWORD%5D
&subType=sun-one&enableProxyAuth=false...devient :
default|imap:/?configName=SUN-UWC-MAIL
&proxyAdminPassword=%5BPROXY-ADMIN_PASSWORD%5D
&subType=sun-one&enableProxyAuth=false ...- Supprimez les virgules (« , ») à la fin de chaque méta-modèle ssoadapter.
- Entourez chaque méta-modèle par une balise <Value> de début et une balise </Value> de fin.
Par exemple :
<Value>default|imap:/?configName=SUN-UWC-MAIL
&proxyAdminPassword=%5BPROXY-ADMIN_PASSWORD%5D
&subType=sun-one&enableProxyAuth=false ...</Value>- Supprimez le crochet fermant (« ] ») du dernier méta-modèle ssoadapter.
- Ajoutez les lignes suivantes à la fin du fichier :
</AttributeValuePair>
</ModifyDefaultValues>
</SchemaRequests>
</Requests>Le fichier ssoadapter-new-templates.xml résultant pour le modèle unique utilisé dans la procédure décrite ci-dessus doit ressembler à cela :
<?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"
>
<Requêtes>
<SchemaRequests serviceName="SunSSOAdapterService" SchemaType="Global">
<ModifyDefaultValues>
<AttributeValuePair>
<Attribute name="sunConfigurationTemplates" />
<Value>default|imap:/?configName=SUN-UWC-MAIL
&proxyAdminPassword=%5BPROXY-ADMIN_PASSWORD%5D
&subType=sun-one&enableProxyAuth=false ...</Value>
</AttributeValuePair>
</ModifyDefaultValues>
</SchemaRequests>
</Requests>- Importez le nouveau fichier ssoadapter-new-templates.xml.
AccessManager-base/bin/amadmin -u utilisateurAmadmin -w mot_de_passe -v
-t ssoadapter-new-templates.xmlÀ ce stade, vous pouvez accéder à l'onglet ssoadapter de la console de Portal Server pour visualiser les méta-modèles ssoadapter mis à jour.
Activation du canal URLScrapper
Lors de la mise à niveau de la version 3 vers la version 5, vous devez activer le canal URLScrapper. Voir la section Activation du canal URLScrapper.
Suppression de l'entrée de service de Gateway
La saisie utilisateur amService-srapGateway doit être manuellement supprimée lorsque vous mettez à niveau Portal Server à partir de la version 2, sans quoi le composant Gateway de Portal Server Secure Remote Access, s'il est utilisé, ne pourra pas démarrer après la mise à niveau. Procédez comme suit :
Mise à niveau de plusieurs instances
Les mises à niveau progressives de plusieurs instances (voir la section Mise à niveau de plusieurs instances) ne sont pas prises en charge dans le cadre de la mise à niveau de la version 2 de Portal Server vers la version 5.
Mise à niveau de Portal Server à partir de la version intermédiaire du logiciel (Interim Feature Release 7.0)Cette section présente des informations sur la mise à niveau de Portal Server à partir de la version intermédiaire du logiciel (Interim Feature Release (IFR) 7.0) 2005Q4 vers Java ES 5 (version 5).
La section aborde les thèmes suivants :
Présentation de la mise à niveau de l'IFR Portal Server
Lors de la mise à niveau de Portal Server IFR 7.0 vers la version 5 de Portal Server, tenez compte des aspects suivants de la procédure :
- Portal Server IFR n'est pas pris en charge sur Application Server 7.x, ce qui fait que le scénario 5 du Tableau 15-4 ne s'applique pas.
- Le script psupgrade, utilisé pour la mise à niveau de Portal Server IFR vers la version 5, n'installe pas de nouveaux packages, comme pour une mise à niveau à partir de la version 4. Au lieu de cela, la procédure de mise à niveau vous demande d'appliquer les patchs suivants :
Tableau 15-8 Patchs1 pour la mise à niveau de Portal Server IFR vers la version 5
Description
ID du patch : Solaris 9 et 10
ID du patch : Linux
Portal Server 7.1
121465-28 (SPARC)
121466-28 (x86)
121467-28
Portal Server 7.1
localisation123254-02 (SPARC)
124590-02 (x86)
123255-02
1Les numéros de révision des patchs sont les numéros minimum requis pour la mise à niveau vers Java ES version 5. S'il existe des versions plus récentes, utilisez-les à la place de celles indiquées dans ce tableau.
- Le script psupgrade ne prend pas en charge la mise à niveau de Portal Server IFR vers la version 5 pour Web Server version 5. Il existe deux raisons à cette restriction :
- Si Web Server a déjà été mis à niveau vers la version 5, vous ne pouvez pas mettre à niveau le logiciel de l'IFR de Portal Server déployé dans le conteneur Web Server antérieur. Par conséquent, le scénario 2 de mise à niveau de conteneur Web décrit dans le Tableau 15-4 n'est pas pris en charge. Prenez connaissance de l'avertissement dans la section Cas particuliers.
- Si Web Server n'a pas encore été mis à niveau vers la version 5, vous pouvez procéder à la mise à niveau du logiciel Portal Server IFR dans le conteneur Web Server (6.x) vers la version 5 en suivant la procédure de la section Mise à niveau de Portal Server IFR 7.0, ci-dessous. Ensuite, mettez à jour Web Server (et Access Manager, le cas échéant) vers la version 5. Si vous choisissez cette méthode, reportez-vous également à la section Mise à niveau dans un conteneur Web Web Server (7.0) version 5 qui contient des instructions de post-mise à niveau supplémentaires.
Mise à niveau de Portal Server IFR 7.0
Cette section explique comment effectuer la mise à niveau de Portal Server à partir de l'IFR vers Java ES version 5 sur les plates-formes Solaris et Linux. Lorsqu'une rubrique traite de procédures spécifiques à une plate-forme, le système d'exploitation auquel elle fait référence est indiqué. La section aborde les thèmes suivants :
Tâches à exécuter avant la mise à niveau d'IFR 7
Les tâches préalables à la mise à niveau de l'IFR sont les mêmes que pour la mise à niveau de la version 4 (voir la section Tâches à exécuter avant la mise à niveau de la version 4), à l'exception des éléments suivants :
Obtention des informations de configuration requis
Les informations requises par le script psupgrade, décrites dans la section Obtention des mots de passe et informations de configuration requis, ne s'applique pas entièrement à la mise à niveau à partir de Portal Server IFR. Portal Server IFR n'étant pas pris en charge sur Application Server 7.x, le scénario 5 du Tableau 15-6, concernant la mise à niveau du conteneur Web, ne s'applique pas.
Configuration du conteneur d'agent commun
Le conteneur d'agent commun est un composant partagé qui fournit des services de conteneur aux agents de contrôle et d'administration de Java ES. Les outils d'administration de Portal Server, tels que la console Portal Server et l'interface de ligne de commande psadmin, utilisent un ensemble d'agents de contrôle et d'administration, collectivement appelés Serveur d'administration du portail et déployés dans le conteneur d'agent commun.
Si les composants partagés de Java ES ont été mis à niveau vers la version 5 avant que vous ne réalisiez la mise à niveau de Portal Server IFR 7.0, la procédure suivante est obligatoire pour que vous puissiez vous connecter à la console de Portal Server version 5 et utiliser l'interface de ligne de commande psadmin. Si les composants partagés de Java ES n'ont pas été mis à niveau vers la version 5 avant que vous ne réalisiez la mise à niveau de Portal Server IFR 7.0, ignorez la procédure suivante.
- Reconfiguration du conteneur d'agent commun
PortalServer7-base/bin/psconfig PortalServer7-base/samples/example2.xml
Le fichier example2.xml fournit les informations de reconfiguration. Vous devez préalablement modifier le fichier example2.xml pour indiquer les mots de passe requis avant d'exécuter la commande psconfig. Si vous utilisez des emplacements autres que les emplacements par défaut pour Portal Server, vous devez en outre indiquer les répertoires appropriés.
- Modifiez le classpath du conteneur Web pour référencer le conteneur d'agent commun.
Le classpath du conteneur Web contient une référence à l'emplacement de la version précédente du conteneur d'agent commun. (rel4CAC-base-dir/lib/cacao_cacao.jar).
Remplacez cette référence par l'emplacement de la version 5 : (rel5CAC-admin-dir/lib/cacao_cacao.jar).
- Vérifiez que le fichier de propriété, pasconnect.properties a bien été créé dans l'annuaire PortalServer7Config-base et qu'il contient la propriété suivante :
pas.host=
La valeur de propriété peut être nulle, localhost ou le nom d'hôte de Portal Server.
- Redémarrage du conteneur d'agent commun
rel5CAC-admin-dir/bin/cacaoadm start
Mise à niveau de Portal Server IFR 7.0 (Solaris)
Cette section traite des considérations ayant une incidence sur la procédure de mise à niveau pour Portal Server IFR et décrit ensuite les différentes étapes de cette procédure.
Considérations relatives à la mise à niveau d'IFR 7 (Solaris)
La mise à niveau de Portal Server IFR vers Java ES version 5 tient compte des mêmes considérations que la mise à niveau de la version 4 (voir la section Considérations relatives à la mise à niveau (Solaris)).
Consultez également les problèmes soulevés dans la section Présentation de la mise à niveau de l'IFR Portal Server.
Procédure de mise à niveau d'IFR 7 (Solaris)
La procédure présentée ci-dessous s'applique au logiciel Portal Server installé sur l'ordinateur sur lequel est effectuée la mise à niveau.
- Connectez-vous en tant qu'utilisateur root ou superutilisateur.
su -
- Arrêtez toutes les instances de Portal Server Secure Remote Access Gateway, Rewriter Proxy ou Netlet Proxy susceptibles d'être en cours d'exécution localement.
PortalServer7-base/bin/psadmin stop-sra-instance -u utilisateurAmadmin
-f fichierMotdepasse -t gateway -N nomProfilGatewayPortalServer7-base/bin/psadmin stop-sra-instance -u utilisateurAmadmin
-f fichierMotdepasse -t rwproxy -N nomProfilGatewayPortalServer7-base/bin/psadmin stop-sra-instance -u utilisateurAmadmin
-f fichierMotdepasse -t nlproxy -N nomProfilGatewayAssurez-vous que les processus se sont arrêtés.
Gateway : netstat -an | grep 443
Serveur proxy de réécriture : netstat -an | grep 10443
Serveur proxy Netlet : netstat -an | grep 10555- Vérifiez qu'Access Manager est en cours d'exécution s'il est déployé sur un conteneur Web différent de celui sur lequel Portal Server est déployé.
- S'il n'est pas déjà en cours d'exécution, démarrez Portal Server en démarrant le conteneur Web sur lequel il est déployé.
Web Server 6.x :
WebServer-base/https-nomInstance/startApplication Server 8.x :
AppServer8-base/bin/asadmin start-domain --user ID_admin
--password mot_de_passe nomDomaine- Obtenez les patchs requis en vous basant sur le Tableau 15-8.
Utilisez toujours la dernière révision de patch disponible, sauf spécification contraire.
Vous pouvez télécharger les patchs dans /tmp à partir de l'adresse : http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
- Appliquez le patch Portal Server approprié et, le cas échéant, le patch de localisation du Tableau 15-8.
patchadd /tmp/ID_patch
- Confirmez la réalisation des mises à niveau de patch :
showrev -p | grep ID_patch
Le résultat doit renvoyer les versions des ID de patchs appliqués à l'Step 6.
- Dans les situations où des packages de localisation ont été mis à jour à l'Step 6, définissez les paramètres d'environnement linguistique de JVM pour la console Portal Server sur UTF-8.
export LC_ALL=ja_JP.UTF-8
export LANG=ja_JP.UTF-8- Définissez deux variables d'environnement (ANT_HOME et JAVA_HOME) requises par le script psupgrade :
export ANT_HOME=/usr/sfw
export JAVA_HOME=/usr/jdk/entsys-j2se- Assurez-vous que vous disposez d'un espace de swap suffisant sur votre ordinateur.
À titre d'information, l'espace de swap doit être défini comme étant égal à deux fois la quantité de mémoire vive (RAM) physique.
- Exécutez le script psupgrade.
cd PortalServer7-base/bin
./psupgradeLe script psupgrade n'est pas exécuté à partir de la distribution Java ES version 5 et n'appelle pas le programme d'installation de Java ES (les packages ont déjà été corrigés par des patchs).
Le script interroge le système afin de détecter l'emplacement, le numéro de port et d'autres informations concernant le conteneur Web dans lequel vous déployez les applications Web de Portal Server. Selon le scénario de mise à niveau du conteneur Web (voir le Tableau 15-4), le script peut vous demander d'entrer les informations complémentaires requises pour déployer Portal Server sur le conteneur Web approprié.
Le Tableau 15-6 présente les informations requises pour les différents scénarios de mise à niveau du conteneur Web dans le Tableau 15-4.
- Arrêtez puis redémarrez le conteneur Web.
Bien que ce ne soit pas obligatoire pour toutes les situations, le fait de redémarrer le conteneur Web permet de garantir que Portal Server démarre à partir d'un état propre.
Mise à niveau de Portal Server IFR 7 (Linux)
Cette section traite des considérations ayant une incidence sur la procédure de mise à niveau pour Portal Server et décrit ensuite les différentes étapes de cette procédure.
Considérations relatives à la mise à niveau d'IFR7 (Linux)
Les mêmes considérations s'appliquent à la mise à niveau du logiciel Portal Server IFR vers la version 5 sous Linux et Solaris (voir la section Considérations relatives à la mise à niveau d'IFR 7 (Solaris)), sauf que l'installation des patchs de la version 5 sur le système d'exploitation Linux supprime les RPM précédents.
Procédure de mise à niveau d'IFR7 (Linux)
La procédure présentée ci-dessous s'applique au logiciel Portal Server installé sur l'ordinateur sur lequel est effectuée la mise à niveau.
Attention
Il est impossible d'annuler une mise à niveau de la version 5 de Portal Server IFR vers la version 5 sous Linux. Veillez à sauvegarder votre système avant d'effectuer la procédure suivante.
- Connectez-vous en tant qu'utilisateur root ou superutilisateur.
su -
- Arrêtez toutes les instances de Portal Server Secure Remote Access Gateway, Rewriter Proxy ou Netlet Proxy susceptibles d'être en cours d'exécution localement.
PortalServer7-base/bin/psadmin stop-sra-instance -u utilisateurAmadmin
-f fichierMotdepasse -t gateway -N nomProfilGatewayPortalServer7-base/bin/psadmin stop-sra-instance -u utilisateurAmadmin
-f fichierMotdepasse -t rwproxy -N nomProfilGatewayPortalServer7-base/bin/psadmin stop-sra-instance -u utilisateurAmadmin
-f fichierMotdepasse -t nlproxy -N nomProfilGatewayAssurez-vous que les processus se sont arrêtés.
Gateway : netstat -an | grep 443
Serveur proxy de réécriture : netstat -an | grep 10443
Serveur proxy Netlet : netstat -an | grep 10555- Vérifiez qu'Access Manager est en cours d'exécution s'il est déployé sur un conteneur Web différent de celui sur lequel Portal Server est déployé.
- S'il n'est pas déjà en cours d'exécution, démarrez Portal Server en démarrant le conteneur Web sur lequel il est déployé.
Web Server 6.x :
WebServer-base/https-nomInstance/startApplication Server 8.x :
AppServer8-base/bin/asadmin start-domain --user ID_admin
--password mot_de_passe nomDomaine- Procurez-vous les patchs requis à l'aide de leurs numéros et des noms de RPM indiqués dans le Tableau 15-8.
Utilisez toujours la dernière révision de patch disponible, sauf spécification contraire.
Vous pouvez télécharger les patchs dans /tmp à partir de l'adresse : http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
- Appliquez le patch Portal Server et, si besoin, les RPM de localisation pour Portal Server, répertoriés dans le Tableau 15-8, en respectant l'ordre défini dans celui-ci.
Consultez le fichier Lisezmoi pour le patch Portal Server ; ce fichier décrit comment utiliser un script pour appliquer les RPM du patch :
cd /tmp
où /tmp est le répertoire dans lequel vous avez téléchargé le patch.
./upgradeportalrpm
Le script de mise à jour installe les RPM.
Pour le chemin de localisation, installez chaque RPM à l'aide de la commande suivante :
rpm -Fvh nomPatch-version.rpm
- Confirmez la réalisation de la mise à niveau du patch :
rpm -qa | grep sun-portal
Le système doit vous renvoyer les numéros de révision mis à niveau des RPM.
- Dans les situations où des packages de localisation ont été mis à jour à l'Step 6, définissez les paramètres d'environnement linguistique de JVM pour la console Portal Server sur UTF-8.
export LC_ALL=ja_JP.UTF-8
export LANG=ja_JP.UTF-8- Définissez deux variables d'environnement (ANT_HOME et JAVA_HOME) requises par le script psupgrade.
export ANT_HOME=/opt/sun
export JAVA_HOME=/usr/jdk/entsys-j2se- Assurez-vous que vous disposez d'un espace de swap suffisant sur votre ordinateur.
À titre d'information, l'espace de swap doit être défini comme étant égal à deux fois la quantité de mémoire vive (RAM) physique.
- Exécutez le script psupgrade.
cd PortalServer7-base/bin
./psupgradeLe script psupgrade n'est pas exécuté à partir de la distribution Java ES version 5 et n'appelle pas le programme d'installation de Java ES (les packages ont déjà été corrigés par des patchs).
Le script interroge le système afin de détecter l'emplacement, le numéro de port et d'autres informations concernant le conteneur Web dans lequel vous déployez les applications Web de Portal Server. Selon le scénario de mise à niveau du conteneur Web (voir le Tableau 15-4), le script peut vous demander d'entrer les informations complémentaires requises pour déployer Portal Server sur le conteneur Web approprié.
Le Tableau 15-6 présente les informations requises pour les différents scénarios de mise à niveau du conteneur Web dans le Tableau 15-4.
- Arrêtez puis redémarrez le conteneur Web.
Bien que ce ne soit pas obligatoire pour toutes les situations, le fait de redémarrer le conteneur Web permet de garantir que Portal Server démarre à partir d'un état propre.
Vérification de la mise à niveau
Vous pouvez vérifier la mise à niveau des packages de Portal Server vers la version 5, réalisée par les patchs, à l'aide de la commande suivante :
Voir le Tableau 15-5 pour les valeurs de résultat.
Pour vérifier l'intégrité de la mise à niveau, confirmez l'affichage du bureau du portail et le fonctionnement de l'utilitaire d'administration psadmin tel qu'il est documenté.
Vous pouvez également consulter les fichiers journaux de mise à niveau dans le répertoire /var/sadm/install/logs :
Tâches à exécuter après la mise à niveau d'IFR 7
Lorsque vous mettez à niveau Portal Server IFR 7 vers la version 5, vous devez effectuer les procédures post-mise à niveau requises dans le cadre des situations suivantes :
Activation de Java ES Monitoring Framework
En activant Java ES Monitoring Framework (composant partagé MFWK), vous permettez aux outils d'administration de Portal Server, tels que la console Portal Server et l'interface de ligne de commande psadmin, de consigner des indicateurs, comme le nombre de visiteurs et les portails qu'ils fréquentent. Pour activer MFWK, procédez comme suit :
- Recherchez les deux fichiers suivants :
MFWK-base/template/jesmf/desktopmfwk.properties
MFWK-base/template/jesmf/com.sun.cmm.ps.xmloù MFWK-base est le chemin suivant :
/opt/SUNWmfwk (Solaris)
/opt/sun/mfwk (Linux)
- Copiez les deux fichiers dans le répertoire suivant :
PortalServer7Data-base/portals/portal_ID/config/Portal_Instance/
- Dans le fichier desktopmfwk.properties, remplacez
com.sun.portal.ProductCollectionId=%PS_DIR%
par
com.sun.portal.ProductCollectionId=Portal_Installed_Location
- Recherchez les deux fichiers jar suivants :
MFWK-base/lib/mfwk_instrum_tk.jar
MFWK-base/lib/mfwk_agent.jarDans le classpath de conteneur Web approprié (fichier server.xml pour Web Server et domain.xml pour Application Server)
- Redémarrez le conteneur Web correspondant.
Mise à niveau dans un conteneur Web Application Server
Si Portal Server est déployé dans un conteneur Web Application Server, vous devez effectuer la procédure complémentaire suivante pour redéployer correctement Portal Server :
- Recherchez la section définissant les paramètres de psconsole dans le fichier AppServer8Config-base/domains/nomDomaine/config/server.policy :
- Ajoutez la ligne suivante à la fin de cette section :
autorisation java.lang.RuntimePermission “getProtectionDomain”
- Redémarrez l'instance d'Application Server.
AppServer8-base/bin/asadmin start-domain --user ID_admin
--password nomDomainemotdepasseAppServer8-base/bin/asadmin start-node-agent --user ID_admin
--password mot_de_passe nomAgentNudoù nomAgentNudpossède la forme nomHôte_nomDomaine, mais est simplement nomHôte par défaut.
Suspension des connexions dans un conteneur Web Application Server
Lorsque le Portal Server mis à niveau est déployé dans un conteneur Web Application Server, il est possible que les applications du portail voient leurs connexions Base de données Java suspendues après un certain délai d'attente. Pour remédier à ce problème, procédez comme suit :
- Supprimez les paramètres dans le fichier PortalServer7Data-base/derby/derby.properties pour les deux paramètres suivants :
derby.drda.maxThreads
derby.drda.timeslice- Redémarrez Base de données Java.
ANT_HOME/bin/ant
-DPS_CONFIG=PortalServer7Config-base/PSConfig.properties
-buildfile PortalServer7-base/lib/derby.xml
[stop-instance|start-instance]où ANT_HOME est /usr/sfw (sur Solaris) et /opt/sun (sur Linux).
- Modifiez les paramètres de configuration de Base de données Java pour Application Server.
À l'aide de la console Application Server, modifiez les valeurs d'attribut pour les ressources de pool de connexions suivantes : communitymcPool, FileSharingDBPool, PointBasePool, SurveyDBPool.
Modifiez les valeurs d'attribut suivantes :
Idle Timeout sur 300 ou davantage
Resource Type sur javax.sql.ConnectionPoolDataSource
Datasource classname sur
org.apache.derby.jdbc.ClientConnectionPoolDataSource- Redémarrez l'instance d'Application Server sur laquelle Portal Server est déployé.
Mise à niveau dans un conteneur Web Web Server (7.0) version 5
Si vous avez mis à niveau Portal Server IFR dans un Web Server qui n'a pas encore été mis à niveau vers la version 5 car le script psupgrade ne prend pas en charge la mise à niveau de Portal Server IFR sur Web Server version 5 (voir la section Présentation de la mise à niveau de l'IFR Portal Server), vous devez réaliser la procédure post-mise à niveau supplémentaire suivante :
- Procédez à la mise à niveau de Web Server (et d'Access Manager, le cas échéant) vers la version 5.
- Reconfigurez les valeurs de conteneurs de Web Server requises par la console Portal Server et par l'interface de ligne de commande psadmin.
- Ouvrez un navigateur LDAP.
Les valeurs de configuration sont stockées dans Directory Server.
- Sous DN, recherchez :
sunPortalAdminPortalDomainID=defaultDomain
->sunPortalAdminPortalDomainPortalID=portal1
->sunPortalAdminPortalDomainPortalServerInstanceIn=host-port- Procédez aux modifications suivantes.
Toutes les entrées commencent par la chaîne suivante : sunPortalAdminPortalDomainPortalServerInstance
- Supprimez l'entrée pour WebContainerInstanceDir.
- Ajoutez une entrée pour WebContainerDomainName et affectez-la à la valeur du Nom de la configuration du conteneur Web dans le Tableau 15-6.
- Modifiez des entrées telles que InstallDir, WebContainerType, DocRoot, et autres paramètres répertoriés dans le Tableau 15-6 afin de les mettre en adéquation avec les valeurs de la version 5 de Web Server (7.0).
- Créez une instance de Portal Server version 5.
PortalServer7-base/bin/psadmin create-instance ID_nouvelleInstance
Si la valeur de ID_nouvelleInstance existe déjà, une erreur se produit : il est donc avantageux d'effectuer cette étape avant l'Step 4 ci-dessous.
- Supprimez l'instance de Portal Server IFR.
PortalServer7-base/bin/psadmin delete-instance ID_ancienneInstance
Redéploiement des applications de portlet personnalisées
Si vous avez créé et déployé des applications de portlet personnalisées, ces portlets doivent être redéployés manuellement après la mise à niveau vers la version 5 de Portal Server. Bien que les entrées de profil d'affichage existent et que le nom de canal s'affiche, le contenu ne sera pas visible tant que vous n'aurez pas redéployé vos portlets personnalisés.
Redéployez les portlets à l'aide de la commande suivante :
PortalServer7-base/bin/psadmin deploy-portlet
Vous pouvez confirmer le redéploiement en recherchant les fichiers .war et XML correspondants dans l'emplacement suivant :
PortalServer7Data-base/portals/Upgraded/war
Migration des applications de portlet personnalisées
La migration vers la version 5 et le redéploiement des applications de portlet basées sur la structure d'interface utilisateur fournie par Sun Java Web Console (SJWC) doivent être effectués manuellement.
Cette obligation s'applique particulièrement aux quatre applications Web distribuées à l'aide de Portal Server en tant qu'exemples d'applications de portlet destinées à être personnalisées et installées sur un portail : filesharing, surveys, wiki et rssportlet. Pendant la mise à niveau, des versions aux bogues corrigés de ces exemples d'applications de portlet seront placées sur le disque dans la zone des applications de portlet. Si vous disposez de ces applications de portlet personnalisées pour votre propre usage, vous devez les faire migrer manuellement vers la version 5, puis les redéployer ; elles ne sont pas prises en compte par le processus de mise à niveau de Portal Server.
Par défaut, certaines de ces applications de portlet (filesharing et surveys) sont déployés et disponibles pour les utilisateurs lorsqu'une communauté est créée.
Vous pouvez mettre à niveau, personnaliser et redéployer les applications de portlet basées sur SJWC à l'aide de la procédure suivante. L'application de portlet filesharing est utilisée à titre d'exemple :
- Procédez à l'extraction des fichiers jar SJWC de la version 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.jarSi PortalServer7-base/portlet/communityportlets.war
est introuvable, utilisez PortalServer7-base/portlet/core/communityportlets.war.- Renommez l'un des fichiers.
mv WEB-INF/lib/commons-collections-3.1.jar
WEB-INF/lib/commons-collections.jar- Recherchez l'application de portlet filesharing.
cd PortalServer7Config-base/portals/portal1/portletapps/filesharing
- Injectez les bibliothèques SJWC mises à jour.
jar uvf src/filesharing.war.tokenized -C /tmp/lh WEB-INF
- Personnalisez l'application de portlet filesharing.
ant customize
- Redéployez l'application de portlet filesharing.
- PortalServer7-base/bin/psadmin undeploy-portlet -u amadmin
-f passwordfile -p ID_portail -i ID_instance -g filesharing- ant deploy
- Allez dans le répertoire suivant (selon le conteneur Web) :
Application Server 8.x :
AppServer8Config-base/domains/domain1/applications/j2ee-modules/
communityportlets/WEB-INFWeb Server 6.x :
WebServer6-base/https-nomInstance/webapps/https-nomInstance/
communityportlets/WEB-INFWeb Server 7.x :
WebServer7Config-base/https-nomConfig/web-app/https-nomConfig/
communityportlets/WEB-INF- Ouvrez le fichier sun-web.xml et ajoutez la ligne suivante juste avant la dernière ligne (c'est-à-dire avant la balise de fin sun-web-app) :
<class-loader delegate="false"/>
- Répétez la procédure de l'Step 2 à l'Step 5 pour surveys et toutes les autres applications de portlet personnalisées basées sur la structure SJWC.
- Redémarrez le conteneur Web.
Correction des liens dans les canaux d'applications et de signets
Lors de la mise à niveau de la version 4 vers la version 5 de Portal Server, les liens vers les canaux d'applications et de signets sont en double et erronés. Pour remédier à ce problème, procédez comme suit :
- Connectez-vous à la PSConsole.
- Dans l'onglet Tâches courantes, cliquez sur l'option Gérer les canaux et les conteneurs.
- Sélectionnez DeveloperSample [Org] comme DN et cliquez sur OK.
- Sélectionnez JSPTabContainer [default] comme type d'affichage.
- Dans MyFrontPageTabPanelContainer, cliquez sur Canaux d'app.
Les propriétés du canal d'application s'affichent dans le cadre de droite.
Pour afficher les propriétés d'un environnement linguistique en particulier, cliquez sur Préférences du tableau et sélectionnez un environnement linguistique : de, fr, es, ja, ko, zh, zh_CN, zh_TW.
- Modifiez la propriété userApps.
- Modifiez la propriété de la cible.
Migration manuelle de portlets basés sur Struts
Si vous avez des portlets personnalisés qui utilisent du code basé sur la structure Struts, ceux-ci doivent être mis à jour manuellement pour pouvoir utiliser le fichier struts.jar inclus dans la version 5 de Portal Server. Procédez comme suit :
- Annulez le déploiement de l'application de portlet basées sur Struts.
PortalServer7-base/bin psadmin undeploy-portlet
- Mettez à jour le fichier .war avec la version appropriée du fichier struts.jar.
Copiez PortalServer7-base/lib/struts.jar dans portletBaséSurStruts/WEB-INF/lib/struts.jar
où portletBaséSurStruts est le répertoire dans lequel les fichiers du portlet basé sur Struts se trouvent.
- Créez une archive .war du répertoire portletBaséSurStruts.
- Redéployez l'application de portlet.
PortalServer7-base/bin psadmin deploy-portlet
Annulation de la mise à niveau (Solaris)
Cette section décrit les points qui ont une influence sur la procédure d'annulation de la mise à niveau de Portal Server, suivis par la description de la procédure elle-même.
Éléments de l'annulation de la mise à niveau (Solaris)
La procédure d'annulation de la mise à niveau vers la version 5 consiste à rétablir l'installation de l'IFR sur PortalServer7-base et à redéployer les applications Web de l'IFR.
Procédure d'annulation de la mise à niveau (Solaris)
- Connectez-vous en tant qu'utilisateur root ou superutilisateur.
su -
- Restaurez Directory Server dans l'état où il se trouvait avant la mise à niveau.
Utilisez la ligne de commande de sauvegarde/restauration et les utilitaires de l'interface graphique utilisateur de Directory Server. Reportez-vous au chapitre « Sauvegarde et restauration de Directory Server » du Guide d'administration de Sun Java System Directory Server Enterprise Edition 6.0, http://docs.sun.com/doc/819-0995.
- Annulez le déploiement des applications Web de Portal Server version 5 redéployées pendant la mise à niveau vers la version 5.
Faites appel aux utilitaires d'administration du conteneur Web (ligne de commande ou console) pour annuler le déploiement des packages suivants :
portal
psconsole
search1
wsssoportlet
guessnumber
portletsamples- Arrêtez Portal Server en fermant son conteneur Web.
Web Server 6.x :
WebServer-base/https-nomInstance/stopWeb Server 7.0:
Admin Server--
WebServer7Config-base/admin-server/bin/stopserv
Instance Server--
WebServer7Config-base/https-nomConfig/bin/stopservApplication Server 8.x :
AppServer8-base/bin/asadmin stop-domain --user ID_admin
--password mot_de_passe nomDomaine- Rétablissez le patch Portal Server 7.1 dans le Tableau 15-8.
patchrm ID_patch
- Redémarrez Portal Server en redémarrant son conteneur Web.
Web Server 6.x :
WebServer-base/https-nomInstance/startWeb Server 7.0:
Admin Server--
WebServer7Config-base/admin-server/bin/startserv
Instance Server--
WebServer7Config-base/https-nomConfig/bin/startservApplication Server 8.x :
AppServer8-base/bin/asadmin start-domain --user ID_admin
--password mot_de_passe nomDomaine- Déployez les applications Web de Portal Server version 5 dont le déploiement a été annulé lors de l'Step 3.
Faites appel aux utilitaires d'administration du conteneur Web (ligne de commande ou console) pour déployer les packages.
- Arrêtez puis redémarrez le conteneur Web.
Bien que ce ne soit pas obligatoire pour toutes les situations, le fait de redémarrer le conteneur Web permet de garantir que Portal Server démarre à partir d'un état propre.
Annulation de la mise à niveau (Linux)
L'annulation de la mise à niveau ne peut être effectuée sous Linux.
Toutefois, vous pouvez créer et tester un système parallèle avant la mise à niveau. Si vous devez annuler la mise à niveau, vous pouvez revenir à ce système parallèle.
Mise à niveau de plusieurs instances
Dans certaines architectures, Portal Server est déployé sur plusieurs systèmes afin de permettre une meilleure évolutivité et une disponibilité accrue. Par exemple, certains composants Portal Server peuvent être exécutés sur plusieurs ordinateurs avec un équilibreur de charge pour répartir la charge.
Dans le cas d'instances de Portal Server avec équilibrage de charge, vous pouvez exécuter une mise à niveau progressive, au cours de laquelle les différentes instances de Portal Server seront successivement mises à niveau sans interruption du service. Vous mettez individuellement chaque instance de Portal Server à niveau pendant que les autres instances continuent de fonctionner. Pour réaliser une mise à niveau progressive de l'IFR vers la version 5, utilisez la procédure décrite dans la section Mise à niveau de plusieurs instances, mais remplacez chaque fois version 4 par IFR.