Sun Java logo     Précédent      Contenu      Index      Suivant     

Sun logo
Guide de mise à niveau de Sun Java Enterprise System 5 pour UNIX 

Chapitre  15
Portal Server

Ce 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 Server

Cette 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.

Tableau 15-2  Méthodes de mise à niveau vers Java ES 5 (version 5) : Portal Server 7.1  

Version de Java ES

Portal Server Version

Approche globale

Reconfiguration requise

Version intermédiaire du logiciel

Sun Java System Portal Server IFR 7.0 2005Q4

Mise à niveau directe :
exécutée en appliquant des patchs puis en utilisant un script de mise à niveau.

Les personnalisations doivent être réappliquées manuellement.

Version 4

Sun Java System Portal Server 6.3.1 2005Q4

Mise à niveau directe :
exécutée à l'aide d'un script de mise à niveau.

Les personnalisations doivent être réappliquées manuellement.

Version 3

Sun Java System Portal Server 6.3.1 2005Q1

Mise à niveau directe :
exécutée à l'aide d'un script de mise à niveau.

Les personnalisations doivent être réappliquées manuellement.

Version 2

Sun Java System Portal Server
6.3 2004Q2

Mise à niveau directe :
exécutée à l'aide d'un script de mise à niveau.

Les personnalisations doivent être réappliquées manuellement.

Version 1

Sun ONE Portal Server 6.1 (2003Q4)

Pas de mise à niveau directe :
en revanche, il est possible de l'exécuter en effectuant préalablement la mise à niveau vers la version 3, puis de la version 3 à la version 5.

Données de configuration

Versions antérieures à Java ES

 

Pas de mise à niveau directe.

 

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.

Tableau 15-3  Portal Server Utilisation des données 

Type de données

Emplacement

Utilisation

Données de configuration

PortalServer6Config-base/

Configuration de Portal Server

Fichiers de configuration et de contrôle d'accès du conteneur Web

Web Server 7.0 (Java ES version 5)
fichiers server.policy et server.xml dans
WebServer7Config-base/https-nomConfig/config

Web Server 6.x (Java ES versions 2, 3 et 4)
fichiers server.policy et server.xml dans
WebServer6-base/https-nomHôte/config

Application Server 8.x (Java ES versions 3, 4 et 5) :
fichiers server.policy et domain.xml dans
AppServer8Config-base/domains/nomDomaine/config

Application Server 7.x (Java ES version 2) :
fichiers server.policy et server.xml dans
AppServer7Config-base/domains/nomDomaine/config

Configuration de l'instance de conteneur Web de Portal Server

Données de personnalisation

PortalServer6Config-base/desktop

Fichiers JAR pour les modules personnalisés

Exemple de bureau Portal Server personnalisé

Schéma d'annuaire

Configuration des services

Données utilisateur

Directory Server

Portal Server dépend de configurations de services, telles que le bureau Portal, et de données de profil utilisateur stockées dans un répertoire.

Données d'application dynamiques

Aucune

Portal Server ne stocke pas en permanence les données d'application, telles que l'état de la session.

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 :

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.

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.

Tableau 15-4  Scénarios de mise à niveau du conteneur Web pour la mise à niveau de Portal Server

Scénario

Conteneur Web dans lequel Portal Server est initialement déployé

Conteneur Web dans lequel Portal Server est déployé après la mise à niveau

Chemins de mise à niveau
de Portal Server applicables : Mises à niveau à partir de

Scénario 1

Web Server 6.x

Web Server 6.x

Version 2
Version 3
Version 4
IFR 7.0

Scénario 2

Web Server 6.x

Web Server 7.0

Version 2
Version 3
Version 4

Scénario 3

Application Server 8.1

Application Server 8.1

Version 3
Version 4
IFR 7.0

Scénario 4

Application Server 8.1

Application Server 8.2

Version 3
Version 4
IFR 7.0

Scénario 5

Application Server 7x

Application Server 8.2

Version 2

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 :

  1. Sauvegardez les données de Portal Server.
  2. Reportez-vous à Données de Portal Server concernant l'emplacement des données fondamentales.

  3. Mettez à niveau le système d'exploitation.
  4. La mise à niveau ne modifie pas le système de fichier existant.

  5. Procédez à la mise à niveau de Portal Server vers la version 5.
  6. 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 4

Cette 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).


Remarque

Cette section ne s'applique pas au cas particulier où Portal Server est déployé dans un conteneur Web Application Server et a été mis à niveau de la version 2 vers la version 3 ou 4 avant la mise à niveau vers la version 5. Cette méthode de mise à niveau n'est pas prise en charge pour l'instant.


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 :

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 :

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.

  1. 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.
  2. Directory Server.  Les instructions de mise à niveau de Directory Server vers la version 5 sont présentées dans le Chapter 5, "Directory Server".
  3. 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".

  4. Remarque

    La mise à niveau de conteneurs Web tiers, tels que ceux de WebLogic et WebSphere, peut provoquer l'arrêt de Portal Server car les personnalisations apportées à ces conteneurs pour la prise en charge de Portal Server sont écrasées par la mise à niveau du conteneur.

    Dans ce cas, vous devez réinstaller et reconfigurer Portal Server pour les environnements de conteneur Web mis à niveau.


  5. 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".
  6. 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".
  7. 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".
  8. Service Registry.  Les instructions de mise à niveau de Service Registry vers la version 5 sont présentées dans le Chapter 12, "Service Registry".
  9. 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 2

Application Server 7.x Exemples de valeurs :
Scénario 52

Mise à 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/nomDomaine

Port 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/
docroot

Nom 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.

Tableau 15-7  Emplacement des paramètres JVM

Conteneur Web

Fichier de configuration

Versions 2, 3 et 4 de
Web Server (6.x)

WebServer6-base/https-nomInstance/config/server.xml

Version 5
Web Server (7.0)

WebServer7Config-base/https-nomConfig/config/server.xml

Versions 3, 4 et 5
d'Application Server (8.x)

AppServer8Config-base/domains/nomDomaine/config/domain.xml

Instance d'Application Server
gérée par l'Agent du nud

AppServer8Config-base/nodeagents/nomAgentNud/config/
domain.xml

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 :

  1. 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) :
  2. 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)

  3. Enregistrez la valeur en cours de la propriété LOAD_BALANCER_URL dans ces fichiers de configuration.
  4. Modifiez la valeur de la propriété LOAD_BALANCER_URL afin qu'elle pointe vers l'instance appropriée de Portal Server :
  5. 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 :

  1. Enregistrez les valeurs en cours des propriétés DS_HOST et DS_PORT dans le fichier de configuration Access Manager suivant :
  2. AccessManagerConfig-base/config/AMConfig.properties

  3. 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 :

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.

  1. Connectez-vous en tant qu'utilisateur root ou superutilisateur.
  2. su -

  3. Si vous ne l'avez pas encore fait, synchronisez tous les composants partagés vers la version 5.
  4. 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.

  5. 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.
  6. PortalServer6-base/bin gateway stop
    PortalServer6-base/bin netletd stop
    PortalServer6-base/bin rwproxyd stop

    Assurez-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

  7. 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é.
  8. 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é.
  9. Web Server 6.x :
    WebServer-base
    /https-nomInstance/start

    Web Server 7.0:
    Admin Server--
    WebServer7Config-base/admin-server/bin/startserv
    Instance Server--
    WebServer7Config-base/https-nomConfig/bin/startserv

    Application Server 8.x :
    AppServer8-base
    /bin/asadmin start-domain --user ID_admin
         --password mot_de_passe nomDomaine

  10. Définissez deux variables d'environnement (ANT_HOME et JAVA_HOME) requises par le script psupgrade. Par exemple :
  11. export ANT_HOME=/usr/sfw
    export JAVA_HOME=/usr/jdk/entsys-j2se

  12. Assurez-vous que vous disposez d'un espace de swap suffisant sur votre ordinateur.
  13. À titre d'information, l'espace de swap doit être défini comme étant égal à deux fois la quantité de mémoire vive (RAM) physique.

  14. Exécutez le script psupgrade à partir de la distribution Java ES version 5.
  15. cd arch_se/Products/portal_svr/Tools/upgrade/bin
    ./psupgrade

    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 :

      1. Accédez au répertoire arch_se adéquat.
      2. Effectuez les modifications inverses sur les données de Portal Server.
      3. ./psupgrade rollback

        Indiquez les paramètres et mots de passe requis.

      4. Exécutez à nouveau psupgrade.

    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.


    Remarque

    Veillez à entrer les valeurs correctes pour les paramètres de psupgrade car il est impossible de revenir en arrière et de les modifier et extrêmement difficile d'annuler les modifications apportées par le script psupgrade. Pour annuler les modifications apportées aux données de Portal Server, vous devez exécuter

      ./psupgrade rollback

    avant d'essayer de réexécuter psupgrade.


  16. Si besoin, restaurez les paramètres JVM du conteneur Web.
  17. Pour vérifier que les paramètres JVM prennent en charge la version 5 de Portal Server, procédez comme suit :

    1. 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.
    2. Voir la section Enregistrement des paramètres de Java Virtual Machine (JVM).

    3. S'ils ont changé, restaurez les valeurs que vous aviez enregistrées avant la mise à niveau.
    4. 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>

  18. Arrêtez puis redémarrez le conteneur Web.
  19. 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.

    1. Arrêtez le conteneur Web comme suit :
    2. Web Server 6.x :
      WebServer-base
      /https-nomInstance/stop

      Web Server 7.0:
      Admin Server--
      WebServer7Config-base/admin-server/bin/stopserv
      Instance Server--
      WebServer7Config-base/https-nomConfig/bin/stopserv

      Application Server 8.x :
      AppServer8-base
      /bin/asadmin stop-domain --user ID_admin
           --password mot_de_passe nomDomaine

    3. 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.


  1. Connectez-vous en tant qu'utilisateur root ou superutilisateur.
  2. su -

  3. Si vous ne l'avez pas encore fait, synchronisez tous les composants partagés vers la version 5.
  4. 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.

  5. 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.
  6. PortalServer6-base/bin gateway stop
    PortalServer6-base/bin netletd stop
    PortalServer6-base/bin rwproxyd stop

    Assurez-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

  7. 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é.
  8. 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é.
  9. Web Server 6.x :
    WebServer-base
    /https-nomInstance/start

    Web Server 7.0:
    Admin Server--
    WebServer7Config-base/admin-server/bin/startserv
    Instance Server--
    WebServer7Config-base/https-nomConfig/bin/startserv

    Application Server 8.x :
    AppServer8-base
    /bin/asadmin start-domain --user ID_admin
         --password mot_de_passe nomDomaine

  10. Définissez deux variables d'environnement (ANT_HOME et JAVA_HOME) requises par le script psupgrade. Par exemple :
  11. export ANT_HOME=/opt/sun
    export JAVA_HOME=/usr/jdk/entsys-j2se

  12. Assurez-vous que vous disposez d'un espace de swap suffisant sur votre ordinateur.
  13. À titre d'information, l'espace de swap doit être défini comme étant égal à deux fois la quantité de mémoire vive (RAM) physique.

  14. Exécutez le script psupgrade à partir de la distribution Java ES version 5.
  15. cd arch_se/Products/portal_svr/Tools/upgrade/bin
    ./psupgrade

    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.


    Remarque

    Veillez à entrer les valeurs correctes pour les paramètres de psupgrade car il est impossible de revenir en arrière et de les modifier et extrêmement difficile d'annuler les modifications apportées par le script psupgrade. Rappel : sauvegardez votre système avant d'exécuter le script psupgrade.


  16. Modifiez le fichier de configuration PortalServer7Config-base/platform.conf.default.
  17. 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.

  18. Si besoin, restaurez les paramètres JVM du conteneur Web.
  19. Pour vérifier que les paramètres JVM prennent en charge la version 5 de Portal Server, procédez comme suit :

    1. 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.
    2. Voir la section Enregistrement des paramètres de Java Virtual Machine (JVM).

    3. S'ils ont changé, restaurez les valeurs que vous aviez enregistrées avant la mise à niveau.
    4. 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>

  20. Arrêtez puis redémarrez le conteneur Web.
  21. 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.

    1. Arrêtez le conteneur Web comme suit :
    2. Web Server 6.x :
      WebServer-base
      /https-nomInstance/stop

      Web Server 7.0:
      Admin Server--
      WebServer7Config-base/admin-server/bin/stopserv
      Instance Server--
      WebServer7Config-base/https-nomConfig/bin/stopserv

      Application Server 8.x :
      AppServer8-base
      /bin/asadmin stop-domain --user ID_admin
           --password mot_de_passe nomDomaine

    3. 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 :

  1. Procédez à l'extraction des fichiers jar SJWC de la version 5.
    1. mkdir /tmp/lh
    2. cd /tmp/lh
    3. /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
    4. Renommez l'un des fichiers.
    5. mv WEB-INF/lib/commons-collections-3.1.jar
      WEB-INF/lib/commons-collections.jar

  2. Recherchez l'application de portlet filesharing.
  3. cd PortalServer7Config-base/portals/portal1/portletapps/filesharing

  4. Injectez les bibliothèques SJWC mises à jour.
  5. jar uvf src/filesharing.war.tokenized -C /tmp/lh WEB-INF

  6. Personnalisez l'application de portlet filesharing.
  7. ant customize

  8. Redéployez l'application de portlet filesharing.
    1. PortalServer7-base/bin/psadmin undeploy-portlet -u amadmin
      -f passwordfile -p ID_portail -i ID_instance -g filesharing
    2. ant deploy
    3. Allez dans le répertoire suivant (selon le conteneur Web) :
    4. Application Server 8.x :

      AppServer8Config-base/domains/domain1/applications/j2ee-modules/
      communityportlets/WEB-INF

      Web Server 6.x :

      WebServer6-base/https-nomInstance/webapps/https-nomInstance/
      communityportlets/WEB-INF

      Web Server 7.x :

      WebServer7Config-base/https-nomConfig/web-app/https-nomConfig/
      communityportlets/WEB-INF

    5. 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) :
    6. <class-loader delegate="false"/>

    7. Répétez l'Step c et l'Step d pour le fichier sun-web.xml sous filesharing/WEB-INF.
  9. 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.
  10. 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 :

  1. Connectez-vous à la PSConsole.
  2. Dans l'onglet Tâches courantes, cliquez sur l'option Gérer les canaux et les conteneurs.
  3. Sélectionnez DeveloperSample [Org] comme DN et cliquez sur OK.
  4. Sélectionnez JSPTabContainer [default] comme type d'affichage.
  5. Dans MyFrontPageTabPanelContainer, cliquez sur Canaux d'app.
  6. 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.

  7. Modifiez la propriété userApps.
    1. Dans la propriété userApps, cliquez sur le lien [Edit Values...]
    2. Une fenêtre contextuelle contenant les applications s'affiche.

    3. Supprimez de la liste les applications suivantes :
    4. NetMail Lite
      NetMail

    5. Ajoutez l'application suivante à la liste :
    6. NetFile

    7. Cliquez sur Enregistrer et sur Fermer.
  8. Modifiez la propriété de la cible.
    1. Dans la propriété de la cible, cliquez sur le lien [Edit Values...]
    2. Une fenêtre contextuelle contenant les cibles s'affiche.

    3. Supprimez de la liste les cibles suivantes :
    4. NetMailLite|
      NetMailServlet?nsid=newHTMLSessionNetMailLite|
      NetMailServlet?nsid=newHTMLSession

      NetMail|NetMailServlet?nsid=newAppletSession

    5. Supprimez l'occurrence en double des cibles suivantes :
    6. Instant Messenger (Java WebStart)|
      IMLaunch?provider=IMChannel&launch=jnlp&last=false

      Instant Messenger (Navigateur)|
      IMLaunch?provider=IMChannel&launch=plugin&last=false

    1. Ajoutez la cible suivante à la liste :

      NetFile|/portal/NetFileApplet?Refer=java2

    1. Cliquez sur Enregistrer et sur Fermer.
Correction 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 --enable

Activation 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 :

  1. Connectez-vous à la console Portal Server.
  2. Cliquez sur l'onglet Portail, puis sur le portail mis à jour.

  3. 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.
  4. Stockez le fichier temporaire dans un emplacement temporaire de votre choix.

  5. Recherchez com.sun.portal.providers.urlscraper.URLScraperProvider.
  6. Recherchez la partie XML commençant par :
  7. <Provider advanced="false" class="com.sun.portal.providers.urlscraper.URLScraperProvider"

    et terminant par :

    </Provider>

  8. Remplacez la partie XML à l'Step 4 par ce qui suit :
  9. <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>

  10. 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)
  1. Connectez-vous en tant qu'utilisateur root ou superutilisateur.
  2. su -

  3. Restaurez Directory Server dans l'état où il se trouvait avant la mise à niveau.
  4. 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.

  5. Arrêtez Portal Server en fermant son conteneur Web.
  6. Web Server 6.x :
    WebServer-base
    /https-nomInstance/stop

    Web Server 7.0:
    Admin Server--
    WebServer7Config-base/admin-server/bin/stopserv
    Instance Server--
    WebServer7Config-base/https-nomConfig/bin/stopserv

    Application Server 8.x :
    AppServer8-base
    /bin/asadmin stop-domain --user ID_admin
         --password mot_de_passe nomDomaine

  7. Supprimez les packages de Portal Server version 5.
    1. Lancez le programme de désinstallation de Java ES.
    2. /var/sadm/prod/SUNWentsys5/uninstall

    3. Sélectionnez tous les composants de Portal Server installés.
    4. Confirmez votre décision de désinstaller.
    5. Quittez le programme de désinstallation de Java ES.
  8. Redémarrez Portal Server en redémarrant son conteneur Web.
  9. Web Server 6.x :
    WebServer-base
    /https-nomInstance/start

    Web Server 7.0:
    Admin Server--
    WebServer7Config-base/admin-server/bin/startserv
    Instance Server--
    WebServer7Config-base/https-nomConfig/bin/startserv

    Application Server 8.x :
    AppServer8-base
    /bin/asadmin start-domain --user ID_admin
         --password mot_de_passe nomDomaine

  10. Redéployez les applications Web de Portal Server version 4 en utilisant la commande suivante à partir de la distribution Java ES version 5 :
  11. cd arch_se/Products/portal_svr/Tools/upgrade/bin
    ./psupgrade rollback

    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.

  12. Arrêtez puis redémarrez le conteneur Web.
  13. 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

Diagramme qui présente un exemple d'architecture de déploiement pour plusieurs instances de Portal Server accédant à plusieurs instances d'Access Manager.

La mise à niveau progressive de Portal Server version 4 vers la version 5 est réalisée comme suit :

  1. 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.
  2. Configurez Portal Server 2 afin qu'il pointe vers Directory Server 2 plutôt que vers Directory Server 1.
  3. Pour plus de simplicité dans cette étape et dans les suivantes, Portal Server 2 désignera les instances Portal Server 2 à Portal Server n.

  4. Procédez à la mise à niveau de Portal Server 1.
    1. Désactivez Portal Server 1 dans Load Balancer B.
    2. Les requêtes ne seront alors plus acheminées vers Portal Server 1.

    3. Désactivez la réplication multimaître de Directory Server.
    4. Directory Server 2 ne sera alors plus synchronisé avec Directory Server 1.

    5. Procédez à la mise à niveau d'Access Manager SDK 1B vers la version 5.
    6. Utilisez la procédure décrite dans la section Mises à niveau concernant uniquement le SDK d'Access Manager pour la version 4.

    7. Procédez à la mise à niveau de Portal Server 1 vers la version 5.
    8. 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.

    9. Activez Portal Server 1 dans Load Balancer B.
    10. Les requêtes seront alors à nouveau acheminées vers Portal Server 1.

  5. Procédez à la mise à niveau de Portal Server 2.
    1. Désactivez Portal Server 2 dans Load Balancer B.
    2. Les requêtes ne seront alors plus acheminées vers Portal Server 2.

    3. Restaurez la configuration de Portal Server 2 afin qu'il pointe vers Directory Server 1.
    4. Procédez à la mise à niveau d'Access Manager SDK 2B vers la version 5.
    5. Utilisez la même procédure qu'à l'Step c.

    6. Procédez à la mise à niveau de Portal Server 2 vers la version 5.
    7. Utilisez la même procédure qu'à l'Step d.

    8. Activez Portal Server 2 dans Load Balancer B.
    9. Les requêtes seront alors à nouveau acheminées vers Portal Server 2.

  6. Activez la réplication multimaître de Directory Server.
  7. 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 3

La 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.

  1. 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".
  2. Directory Server.  Les instructions de mise à niveau de Directory Server vers la version 5 sont présentées dans le Chapter 5, "Directory Server".
  3. 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".

  4. Remarque

    La mise à niveau de conteneurs Web tiers, tels que ceux de WebLogic et WebSphere, peut provoquer l'arrêt de Portal Server car les personnalisations apportées à ces conteneurs pour la prise en charge de Portal Server sont écrasées par la mise à niveau du conteneur.

    Dans ce cas, vous devez réinstaller et reconfigurer Portal Server pour les environnements de conteneur Web mis à niveau.


  5. 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 :

  1. Créez un fichier snippet XML de profil d'affichage, helpUrl.xml:
  2. <?xml version="1.0" encoding="utf-8" ?>
      <!DOCTYPE DisplayProfile SYSTEM "jar://resources/psdp.dtd">
        <Properties>
          <String name="helpURL" value="en/desktop/usedesk.htm" />
        </Properties>

  3. Exécutez les propriétés de profil d'affichage global à l'aide de la commande suivante :
  4. ./psadmin modify-dp -u utilisateurAmadmin -f /tmp/fichierMotdepasse -p ID_portail
        -m -g helpUrl.xml

    -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 2

Cette 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 :

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.

  1. 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".
  2. 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.
  3. 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".

  4. Remarque

    La mise à niveau de conteneurs Web tiers, tels que ceux de WebLogic et WebSphere, peut provoquer l'arrêt de Portal Server car les personnalisations apportées à ces conteneurs pour la prise en charge de Portal Server sont écrasées par la mise à niveau du conteneur. Dans ce cas, vous devez réinstaller et reconfigurer Portal Server pour les environnements de conteneur Web mis à niveau.


  5. 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 :

  1. Connectez-vous à la console d'administration de Web Server.
  2. Cliquez sur Modifier les serveurs virtuels > Applications Web.
  3. Supprimez toutes les applications Web déployées possédant un URI qui inclut soit /portal soit /portalsamples.
  4. Cliquez sur Enregistrer.
  5. Cliquez sur Déploiement en attente.

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 :

  1. Connectez-vous en tant qu'utilisateur root ou superutilisateur.
  2. su -

  3. Si vous ne l'avez pas encore fait, synchronisez tous les composants partagés vers la version 5.
  4. 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.

  5. 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.
  6. PortalServer6-base/bin gateway stop
    PortalServer6-base/bin netletd stop
    PortalServer6-base/bin rwproxyd stop

    Assurez-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

  7. 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é.
  8. 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é.
    1. Démarrez le serveur d'administration de domaine si ce n'est déjà fait.
    2. AppServer8-base/bin/asadmin start-domain --user ID_admin
           --password mot_de_passe nomDomaine

    3. 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.
    4. 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 nomAgentNud

      Dans les commandes ci-dessus et dans les étapes suivantes les conventions suivantes sont utilisées :

    5. nomAgentNudpossède la forme nomHôte_nomDomaine, mais est simplement nomHôte par défaut.
    6. La valeur par défaut de nomDomaine est domain1
    7. La valeur par défaut de nomInstance est server1
  9. Annulez le déploiement des composants de Portal Server.
  10. AppServer8-base/bin/asadmin undeploy --user ID_admin
         --password mot_de_passe --target nomInstance portal

    AppServer8-base/bin/asadmin undeploy --user ID_admin
         --password mot_de_passe --target nomInstance portletsamples

  11. Définissez deux variables d'environnement (ANT_HOME et JAVA_HOME) requises par le script psupgrade. Par exemple :
  12. SE Solaris :

    export ANT_HOME=/usr/sfw
    export JAVA_HOME=/usr/jdk/entsys-j2se

    Système d'exploitation Linux :

    export ANT_HOME=/opt/sun
    export JAVA_HOME=/usr/jdk/entsys-j2se

  13. Assurez-vous que vous disposez d'un espace de swap suffisant sur votre ordinateur.
  14. À titre d'information, l'espace de swap doit être défini comme étant égal à deux fois la quantité de mémoire vive (RAM) physique.

  15. Exécutez le script psupgrade à partir de la distribution Java ES version 5.
  16. cd arch_se/Products/portal_svr/Tools/upgrade/bin
    ./psupgrade

    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 :

      1. Accédez au répertoire arch_se adéquat.
      2. Effectuez les modifications inverses sur les données de Portal Server.
      3. ./psupgrade rollback

        Indiquez les paramètres et mots de passe requis.

      4. Exécutez à nouveau psupgrade.

    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).


    Remarque

    Veillez à entrer les valeurs correctes pour les paramètres de psupgrade car il est impossible de revenir en arrière et de les modifier et extrêmement difficile d'annuler les modifications apportées par le script psupgrade. Pour annuler les modifications apportées aux données de Portal Server, vous devez exécuter

      ./psupgrade rollback

    avant d'essayer de réexécuter psupgrade.


  17. Arrêtez le serveur d'administration de domaine et l'agent de nud que vous aviez démarrés à l'Step 5.
  18. AppServer8-base/bin/asadmin stop-domain --user ID_admin
         --password mot_de_passe nomDomaine

    AppServer8-base/bin/asadmin stop-node-agent --user ID_admin
         --password mot_de_passe nomAgentNud

  19. 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.

  20. 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 nomDomaine

    AppServer8-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 :

  1. Exportez les données du méta-modèle ssoadapter.
  2. Faites appel à l'utilitaire amadmin pour exporter les données de service Access Manager, comme suit :

    1. Créez un fichier de requête amadmin, /tmp/ssoadapter-template-gets.xml.
    2. 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>

    3. Exécutez la commande asadmin suivante :
    4. AccessManager-base/bin/amadmin -u utilisateurAmadmin -w mot_de_passe
       -t ssoadapter-templates-get.xml > /tmp/ssoadapter-templates.xml

      Le 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 ...

  3. Modifiez le fichier /tmp/ssoadapter-templates.xml afin de renommer les méta-modèles ssoadapter en double.
    1. Recherchez chaque modèle dans le fichier /tmp/ssoadapter-templates.xml.
    2. Recherchez la chaîne default|imap:/?configName=.

    3. Remplacez les noms de méta-modèle ssoadapter en double par des valeurs uniques.
    4. 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 ...

  4. 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.
    1. Copiez le fichier /tmp/ssoadapter-templates.xml dans /tmp/ssoadapter-new-templates.xml.
    2. Dans /tmp/ssoadapter-new-templates.xml, remplacez la chaîne :
    3. 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" />

    4. Remplacez toutes les perluètes (« & ») par « &amp; ».
    5. 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
      &amp;proxyAdminPassword=%5BPROXY-ADMIN_PASSWORD%5D
      &amp;subType=sun-one&amp;enableProxyAuth=false ...

    6. Supprimez les virgules (« , ») à la fin de chaque méta-modèle ssoadapter.
    7. Entourez chaque méta-modèle par une balise <Value> de début et une balise </Value> de fin.
    8. Par exemple :

      <Value>default|imap:/?configName=SUN-UWC-MAIL
      &amp;proxyAdminPassword=%5BPROXY-ADMIN_PASSWORD%5D
      &amp;subType=sun-one&amp;enableProxyAuth=false ...</Value>

    9. Supprimez le crochet fermant (« ] ») du dernier méta-modèle ssoadapter.
    10. Ajoutez les lignes suivantes à la fin du fichier :
    11.       </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
      &amp;proxyAdminPassword=%5BPROXY-ADMIN_PASSWORD%5D
      &amp;subType=sun-one&amp;enableProxyAuth=false ...</Value>
            </AttributeValuePair>
          </ModifyDefaultValues>
        </SchemaRequests>
      </Requests>

  5. Importez le nouveau fichier ssoadapter-new-templates.xml.
  6. 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 :

  1. Connectez-vous à la console Access Manager.
  2. Répertoriez tous les utilisateurs du nom de domaine de l'organisation.
  3. Supprimez l'utilisateur amService-srapGateway.

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 :

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.

  1. Reconfiguration du conteneur d'agent commun
  2. 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.

  3. Modifiez le classpath du conteneur Web pour référencer le conteneur d'agent commun.
  4. 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).

  5. 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 :
  6. pas.host=

    La valeur de propriété peut être nulle, localhost ou le nom d'hôte de Portal Server.

  7. Redémarrage du conteneur d'agent commun
  8. 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.

  1. Connectez-vous en tant qu'utilisateur root ou superutilisateur.
  2. su -

  3. 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.
  4. PortalServer7-base/bin/psadmin stop-sra-instance -u utilisateurAmadmin
       -f fichierMotdepasse -t gateway -N nomProfilGateway

    PortalServer7-base/bin/psadmin stop-sra-instance -u utilisateurAmadmin
       -f fichierMotdepasse -t rwproxy -N nomProfilGateway

    PortalServer7-base/bin/psadmin stop-sra-instance -u utilisateurAmadmin
       -f fichierMotdepasse -t nlproxy -N nomProfilGateway

    Assurez-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

  5. 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é.
  6. 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é.
  7. Web Server 6.x :
    WebServer-base
    /https-nomInstance/start

    Application Server 8.x :
    AppServer8-base
    /bin/asadmin start-domain --user ID_admin
         --password mot_de_passe nomDomaine

  8. Obtenez les patchs requis en vous basant sur le Tableau 15-8.
  9. 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

  10. Appliquez le patch Portal Server approprié et, le cas échéant, le patch de localisation du Tableau 15-8.
  11. patchadd /tmp/ID_patch

  12. Confirmez la réalisation des mises à niveau de patch :
  13. showrev -p | grep ID_patch

    Le résultat doit renvoyer les versions des ID de patchs appliqués à l'Step 6.

  14. 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.
  15. export LC_ALL=ja_JP.UTF-8
    export LANG=ja_JP.UTF-8

  16. Définissez deux variables d'environnement (ANT_HOME et JAVA_HOME) requises par le script psupgrade :
  17. export ANT_HOME=/usr/sfw
    export JAVA_HOME=/usr/jdk/entsys-j2se

  18. Assurez-vous que vous disposez d'un espace de swap suffisant sur votre ordinateur.
  19. À titre d'information, l'espace de swap doit être défini comme étant égal à deux fois la quantité de mémoire vive (RAM) physique.

  20. Exécutez le script psupgrade.
  21. cd PortalServer7-base/bin
    ./psupgrade

    Le 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.


    Remarque

    Veillez à entrer les valeurs correctes pour les paramètres de psupgrade car il est impossible de revenir en arrière et de les modifier et extrêmement difficile d'annuler les modifications apportées par le script psupgrade.


  22. Arrêtez puis redémarrez le conteneur Web.
  23. 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.


  1. Connectez-vous en tant qu'utilisateur root ou superutilisateur.
  2. su -

  3. 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.
  4. PortalServer7-base/bin/psadmin stop-sra-instance -u utilisateurAmadmin
       -f fichierMotdepasse -t gateway -N nomProfilGateway

    PortalServer7-base/bin/psadmin stop-sra-instance -u utilisateurAmadmin
       -f fichierMotdepasse -t rwproxy -N nomProfilGateway

    PortalServer7-base/bin/psadmin stop-sra-instance -u utilisateurAmadmin
       -f fichierMotdepasse -t nlproxy -N nomProfilGateway

    Assurez-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

  5. 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é.
  6. 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é.
  7. Web Server 6.x :
    WebServer-base
    /https-nomInstance/start

    Application Server 8.x :
    AppServer8-base
    /bin/asadmin start-domain --user ID_admin
         --password mot_de_passe nomDomaine

  8. Procurez-vous les patchs requis à l'aide de leurs numéros et des noms de RPM indiqués dans le Tableau 15-8.
  9. 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

  10. 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.
  11. 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

  12. Confirmez la réalisation de la mise à niveau du patch :
  13. rpm -qa | grep sun-portal

    Le système doit vous renvoyer les numéros de révision mis à niveau des RPM.

  14. 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.
  15. export LC_ALL=ja_JP.UTF-8
    export LANG=ja_JP.UTF-8

  16. Définissez deux variables d'environnement (ANT_HOME et JAVA_HOME) requises par le script psupgrade.
  17. export ANT_HOME=/opt/sun
    export JAVA_HOME=/usr/jdk/entsys-j2se

  18. Assurez-vous que vous disposez d'un espace de swap suffisant sur votre ordinateur.
  19. À titre d'information, l'espace de swap doit être défini comme étant égal à deux fois la quantité de mémoire vive (RAM) physique.

  20. Exécutez le script psupgrade.
  21. cd PortalServer7-base/bin
    ./psupgrade

    Le 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.


    Remarque

    Veillez à entrer les valeurs correctes pour les paramètres de psupgrade car il est impossible de revenir en arrière et de les modifier et extrêmement difficile d'annuler les modifications apportées par le script psupgrade.


  22. Arrêtez puis redémarrez le conteneur Web.
  23. 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 :

  1. Recherchez les deux fichiers suivants :
  2. MFWK-base/template/jesmf/desktopmfwk.properties
    MFWK-base/template/jesmf/com.sun.cmm.ps.xml

    MFWK-base est le chemin suivant :

    /opt/SUNWmfwk    (Solaris)

    /opt/sun/mfwk    (Linux)

  3. Copiez les deux fichiers dans le répertoire suivant :
  4. PortalServer7Data-base/portals/portal_ID/config/Portal_Instance/

  5. Dans le fichier desktopmfwk.properties, remplacez
  6. com.sun.portal.ProductCollectionId=%PS_DIR%

    par

    com.sun.portal.ProductCollectionId=Portal_Installed_Location

  7. Recherchez les deux fichiers jar suivants :
  8. MFWK-base/lib/mfwk_instrum_tk.jar
    MFWK-base/lib/mfwk_agent.jar

    Dans le classpath de conteneur Web approprié (fichier server.xml pour Web Server et domain.xml pour Application Server)

  9. 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 :

  1. Recherchez la section définissant les paramètres de psconsole dans le fichier AppServer8Config-base/domains/nomDomaine/config/server.policy :
  2. Ajoutez la ligne suivante à la fin de cette section :
  3. autorisation java.lang.RuntimePermission “getProtectionDomain”

  4. Redémarrez l'instance d'Application Server.
  5. AppServer8-base/bin/asadmin start-domain --user ID_admin
         --password nomDomainemotdepasse

    AppServer8-base/bin/asadmin start-node-agent --user ID_admin
         --password mot_de_passe nomAgentNud

    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 :

  1. Supprimez les paramètres dans le fichier PortalServer7Data-base/derby/derby.properties pour les deux paramètres suivants :
  2. derby.drda.maxThreads
    derby.drda.timeslice

  3. Redémarrez Base de données Java.
  4. ANT_HOME/bin/ant
        -DPS_CONFIG=
    PortalServer7Config-base/PSConfig.properties
        -buildfile
    PortalServer7-base/lib/derby.xml
        [stop-instance|start-instance]

    ANT_HOME est /usr/sfw (sur Solaris) et /opt/sun (sur Linux).

  5. Modifiez les paramètres de configuration de Base de données Java pour Application Server.
  6. À 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

  7. 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 :

  1. Procédez à la mise à niveau de Web Server (et d'Access Manager, le cas échéant) vers la version 5.
  2. Reconfigurez les valeurs de conteneurs de Web Server requises par la console Portal Server et par l'interface de ligne de commande psadmin.
    1. Ouvrez un navigateur LDAP.
    2. Les valeurs de configuration sont stockées dans Directory Server.

    3. Sous DN, recherchez :
      sunPortalAdminPortalDomainID=defaultDomain
      ->sunPortalAdminPortalDomainPortalID=portal1
      ->sunPortalAdminPortalDomainPortalServerInstanceIn=host-port
    4. Procédez aux modifications suivantes.
    5. 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).
  3. Créez une instance de Portal Server version 5.
  4. 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.

  5. Supprimez l'instance de Portal Server IFR.
  6. 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 :

  1. Procédez à l'extraction des fichiers jar SJWC de la version 5.
    1. mkdir /tmp/lh
    2. cd /tmp/lh
    3. /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
    4. Si PortalServer7-base/portlet/communityportlets.war
      est introuvable, utilisez PortalServer7-base/portlet/core/communityportlets.war.

    5. Renommez l'un des fichiers.
    6. mv WEB-INF/lib/commons-collections-3.1.jar
      WEB-INF/lib/commons-collections.jar

  2. Recherchez l'application de portlet filesharing.
  3. cd PortalServer7Config-base/portals/portal1/portletapps/filesharing

  4. Injectez les bibliothèques SJWC mises à jour.
  5. jar uvf src/filesharing.war.tokenized -C /tmp/lh WEB-INF

  6. Personnalisez l'application de portlet filesharing.
  7. ant customize

  8. Redéployez l'application de portlet filesharing.
    1. PortalServer7-base/bin/psadmin undeploy-portlet -u amadmin
      -f passwordfile -p ID_portail -i ID_instance -g filesharing
    2. ant deploy
    3. Allez dans le répertoire suivant (selon le conteneur Web) :
    4. Application Server 8.x :

      AppServer8Config-base/domains/domain1/applications/j2ee-modules/
      communityportlets/WEB-INF

      Web Server 6.x :

      WebServer6-base/https-nomInstance/webapps/https-nomInstance/
      communityportlets/WEB-INF

      Web Server 7.x :

      WebServer7Config-base/https-nomConfig/web-app/https-nomConfig/
      communityportlets/WEB-INF

    5. 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) :
    6. <class-loader delegate="false"/>

    7. Répétez l'Step c et l'Step d pour le fichier sun-web.xml sous filesharing/WEB-INF.
  9. 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.
  10. 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 :

  1. Connectez-vous à la PSConsole.
  2. Dans l'onglet Tâches courantes, cliquez sur l'option Gérer les canaux et les conteneurs.
  3. Sélectionnez DeveloperSample [Org] comme DN et cliquez sur OK.
  4. Sélectionnez JSPTabContainer [default] comme type d'affichage.
  5. Dans MyFrontPageTabPanelContainer, cliquez sur Canaux d'app.
  6. 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.

  7. Modifiez la propriété userApps.
    1. Dans la propriété userApps, cliquez sur le lien [Edit Values...]
    2. Une fenêtre contextuelle contenant les applications s'affiche.

    3. Ajoutez l'application suivante à la liste :
    4. NetFile

    5. Cliquez sur Enregistrer et sur Fermer.
  8. Modifiez la propriété de la cible.
    1. Dans la propriété de la cible, cliquez sur le lien [Edit Values...]
    2. Une fenêtre contextuelle contenant les cibles s'affiche.

    3. Ajoutez la cible suivante à la liste :

      NetFile|/portal/NetFileApplet?Refer=java2

    1. Cliquez sur Enregistrer et sur Fermer.
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 :

  1. Annulez le déploiement de l'application de portlet basées sur Struts.
  2. PortalServer7-base/bin psadmin undeploy-portlet

  3. Mettez à jour le fichier .war avec la version appropriée du fichier struts.jar.
  4. Copiez PortalServer7-base/lib/struts.jar dans portletBaséSurStruts/WEB-INF/lib/struts.jar

    portletBaséSurStruts est le répertoire dans lequel les fichiers du portlet basé sur Struts se trouvent.

  5. Créez une archive .war du répertoire portletBaséSurStruts.
  6. Redéployez l'application de portlet.
  7. 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)
  1. Connectez-vous en tant qu'utilisateur root ou superutilisateur.
  2. su -

  3. Restaurez Directory Server dans l'état où il se trouvait avant la mise à niveau.
  4. 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.

  5. Annulez le déploiement des applications Web de Portal Server version 5 redéployées pendant la mise à niveau vers la version 5.
  6. 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

  7. Arrêtez Portal Server en fermant son conteneur Web.
  8. Web Server 6.x :
    WebServer-base
    /https-nomInstance/stop

    Web Server 7.0:
    Admin Server--
    WebServer7Config-base/admin-server/bin/stopserv
    Instance Server--
    WebServer7Config-base/https-nomConfig/bin/stopserv

    Application Server 8.x :
    AppServer8-base
    /bin/asadmin stop-domain --user ID_admin
         --password mot_de_passe nomDomaine

  9. Rétablissez le patch Portal Server 7.1 dans le Tableau 15-8.
  10. patchrm ID_patch

  11. Redémarrez Portal Server en redémarrant son conteneur Web.
  12. Web Server 6.x :
    WebServer-base
    /https-nomInstance/start

    Web Server 7.0:
    Admin Server--
    WebServer7Config-base/admin-server/bin/startserv
    Instance Server--
    WebServer7Config-base/https-nomConfig/bin/startserv

    Application Server 8.x :
    AppServer8-base
    /bin/asadmin start-domain --user ID_admin
         --password mot_de_passe nomDomaine

  13. Déployez les applications Web de Portal Server version 5 dont le déploiement a été annulé lors de l'Step 3.
  14. Faites appel aux utilitaires d'administration du conteneur Web (ligne de commande ou console) pour déployer les packages.

  15. Arrêtez puis redémarrez le conteneur Web.
  16. 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.



Précédent      Contenu      Index      Suivant     


Numéro de référence : 819-6553-11
Juin 2007.   Copyright 2007 Sun Microsystems, Inc. Tous droits réservés.