CHAPITRE 3 |
Ce chapitre décrit la configuration requise et les procédures de mise à niveau à partir des versions antérieures de Sun Secure Global Desktop (SGD).
Cette section répertorie les points à considérer avant de lancer la mise à niveau.
SGD version 4.40 inclut un nouvel outil d'administration via le Web‐, la console d'administration SGD, qui remplace le gestionnaire d'objets, le gestionnaire de baies, l'assistant de configuration et le gestionnaire de sessions. De ce fait, si vous effectuez une mise à niveau à partir d'une version de SGD antérieure à 4.40, cette version contient des modifications significatives au niveau de la hiérarchie d'organisation de SGD. Les principales modifications sont les suivantes :
Les objets d'application sont toujours créés et conservés dans un nouvel objet d'organisation appelé o=applications.
Les objets de serveur d'application, connus précédemment sous le nom d'objets d'hôte, sont toujours créés et conservés dans un nouvel objet d'organisation appelé o=appservers.
Les outils d'administration précédents vous permettaient de construire des relations complexes entre des objets. Les relations autorisées sont désormais plus simples.
Lorsque vous effectuez une mise à niveau à partir d'une version antérieure à 4.40, vos objets d'application et de serveur d'application, ainsi que les objets de groupe et d'unité d'organisation associés, sont déplacés vers les nouvelles organisations. Autant que possible, SGD tente de préserver les relations entre les objets, mais une fois la mise à niveau effectuée, il est possible que certains utilisateurs ne trouvent plus certaines applications sur leur bureau Web.
Avant d'effectuer une mise à niveau à partir d'une version antérieure à 4.40, nous vous recommandons d'effectuer un test pour déterminer les modifications qui vous concernent. Pour cela, mettez à niveau un environnement de pré-production reflétant votre environnement de production normal. Vous pouvez également isoler un serveur secondaire de la baie et le mettre à niveau.
Les mises à niveau des versions EAP (Early Access Program) de SGD ne sont pas prises en charge. Les versions EAP doivent toujours correspondre à une nouvelle installation.
Les mises à niveau vers cette version de SGD ne sont prises en charge qu'à partir des versions suivantes :
Si vous souhaitez mettre à niveau une autre version de SGD ou la version 3.30 (ou une version antérieure) de Tarantella Enterprise 3, contactez le service d'assistance Sun.
Si vous êtes certain de vouloir effectuer une mise à niveau non prise en charge, vous devez créer un fichier vide /opt/tarantella/var/UPGRADE avant d'installer la nouvelle version du logiciel. Votre installation SGD risque de ne pas être mise à niveau correctement.
Lors de la mise à niveau sur une plate-forme SE Solaris, la commande pkgadd réalise diverses vérifications et vous invite à confirmer les modifications avant d'installer le package. Si vous le souhaitez, créez un fichier d'administration pour spécifier que la commande pkgadd doit ignorer ces vérifications et installer le package sans demander la confirmation de l'utilisateur.
Pour éviter les interactions de l'utilisateur, le fichier d'administration doit contenir la ligne suivante :
conflict=nocheck instance=unique
Lors de la mise à niveau de SGD, spécifiez le fichier d'administration à l'aide de la commande pkgadd -a fichieradmin.
Si vous ne spécifiez aucun fichier d'administration lors de la mise à niveau, le programme d'installation de SGD en crée un et vous propose de quitter l'installation pour exécuter à nouveau la commande pkgadd avec l'option -a fichieradmin.
Lors de la mise à niveau, les modifications suivantes sont appliquées à la configuration existante :
La base de données ENS (Enterprise Naming System, système d'attribution de nom d'entreprise) n'est pas modifiée et le programme en réalise une sauvegarde.
La base de données ENS constitue la zone de stockage de tous les objets de la hiérarchie SGD.
Le répertoire /opt/tarantella/var/ens est sauvegardé dans le répertoire /opt/tarantella/var/ens.ancienneversion.
La sauvegarde n'est pas modifiée. Il est possible que la base de données ENS existante soit modifiée si des modifications sont nécessaires pour lui permettre de fonctionner avec la nouvelle version de SGD.
Remarque - Changements d'organisation de la version 4.40 et des versions suivantes contient des détails sur les modifications significatives apportées à la base de données ENS dans cette version. |
La configuration du serveur SGD et la configuration SGD globale ne sont pas modifiées, mais le programme n'en réalise aucune sauvegarde.
Ces paramètres de configuration sont enregistrés dans le répertoire /opt/tarantella/var/serverconfig.
Ils ne sont modifiés que si des fichiers de propriétés doivent être ajoutés ou si de nouveaux attributs doivent être appliqués aux propriétés existantes.
Tous les fichiers des ressources de serveur inclus dans le répertoire /opt/tarantella/var/serverresources sont remplacés.
En général, ces fichiers ne sont pas modifiés, car ils contrôlent le fonctionnement de SGD.
Les scripts de connexion de SGD ne sont pas modifiés et le programme en réalise une sauvegarde.
Le répertoire /opt/tarantella/var/serverresources/expect est sauvegardé dans le répertoire /opt/tarantella/var/serverresources/expect.ancienneversion.
Vos fichiers SGD personnalisés sont sauvegardés, mais ils ne sont pas mis à niveau.
Vous pouvez personnaliser SGD en modifiant les fichiers fournis avec l'installation standard (pour les thèmes de bureau Web, par exemple) ou en ajoutant des fichiers (pour les scripts de connexion, par exemple).
Ces fichiers doivent être mis à niveau manuellement.
Lors de l'installation d'une nouvelle version de SGD, le programme d'installation indique les fichiers susceptibles de requérir une mise à niveau manuelle, le cas échéant. Pour connaître la procédure de mise à niveau manuelle, reportez-vous à la section Mise à niveau d'une installation SGD personnalisée.
La méthode de mise à niveau de SGD dépend du type de version de SGD mise à niveau (version d'évaluation ou version sous licence), ainsi que du type de groupe mis à niveau (groupe multiserveur ou serveur unique). Si vous avez personnalisé SGD, les fichiers personnalisés doivent être mis à niveau manuellement.
Si aucune clé de licence n'est installée pour un serveur SGD, ou s'il n'appartient à aucun groupe sous licence, alors le serveur SGD est en mode d'évaluation. À l'expiration de la période d'essai de 30 jours, le serveur SGD se trouve en mode d'évaluation expirée.
Pour mettre à niveau un serveur SGD en mode d'évaluation ou en mode d'évaluation expirée, installez la version suivante du logiciel.
Notez que l'expiration de la période d'évaluation rend la connexion au serveur Secure Global Desktop impossible, même après la mise à niveau.
Pour obtenir la licence d'un serveur en mode d'évaluation expirée, ajoutez une clé de licence valide à l'aide de la commande tarantella license add ou reliez le serveur à un groupe sous licence.
Tous les serveurs SGD d'une baie de plusieurs serveurs doivent exécuter la même version du logiciel SGD. Par conséquent, pour mettre à niveau une baie de serveurs, vous devez la démanteler, mettre à niveau chaque serveur individuellement, puis reconstituer la baie.
Assurez-vous qu'aucune session utilisateur ni d'application (y compris les sessions suspendues) n'est en cours d'exécution dans le groupe.
À partir du serveur SGD principal, séparez les serveurs SGD secondaires du groupe :
# tarantella array detach --secondary serveur |
Lorsqu'un serveur SGD secondaire est séparé d'un groupe, il perd ses clés de licence, ce qui gêne temporairement la connexion à SGD sur cet hôte.
Pour mettre à niveau le serveur SGD principal, installez la nouvelle version du logiciel.
Pour mettre à niveau les serveurs SGD secondaires, installez la nouvelle version du logiciel.
À partir du serveur SGD principal, ajoutez les serveurs SGD secondaires au groupe :
# tarantella array join --secondary serveur |
Dès qu'un serveur SGD secondaire est ajouté à un groupe, il bénéficie des clés de licence installées sur le serveur SGD principal.
Lors d'une mise à niveau, le programme d'installation SGD ne modifie pas les fichiers personnalisés, mais il ne les met pas non plus à niveau. Le cas échéant, vous devez les mettre à niveau manuellement. La mise à niveau concerne deux jeux de fichiers :
Fichiers de serveur Web SGD : fichiers d'application Web et fichiers utilisés pour configurer le serveur Web SGD ;
Fichiers de serveur SGD : fichiers utilisés par le serveur SGD, tels que les scripts de connexion ;
Deux types de fichiers personnalisés peuvent requérir votre attention après la mise à niveau :
Fichiers personnalisés : fichiers présents dans l'installation SGD standard et modifiés par un administrateur SGD ;
Fichiers spécifiques : fichiers créés par votre organisation, puis ajoutés à une installation SGD.
Lors de la mise à niveau, si le programme d'installation SGD détecte des fichiers de serveur Web SGD personnalisés, il les sauvegarde. Les fichiers sauvegardés et leur emplacement sont répertoriés dans le fichier journal /opt/tarantella/var/log/webservercustomized.list.
La mise à niveau des fichiers personnalisés consiste à comparer les fichiers sauvegardés et les fichiers de l'installation SGD standard, puis à fusionner les différences, par exemple à l'aide des utilitaires diff et patch.
Si le programme d'installation SGD détecte des fichiers de serveur Web SGD spécifiques, il les copie dans la nouvelle installation. Aucune modification n'est apportée à ces fichiers.
Lors de la mise à niveau, si le programme d'installation SGD détecte des fichiers de serveur SGD personnalisés et spécifiques, il les sauvegarde et génère les fichiers journaux suivants :
/opt/tarantella/var/log/upgraded.files : récapitulatif des modifications ;
/opt/tarantella/var/log/customized.list : liste des fichiers modifiés ou ajoutés par l'administrateur ;
/opt/tarantella/var/log/customizedchanged.list : liste des fichiers ayant été modifiés par un administrateur et modifiés lors de la mise à niveau ;
/opt/tarantella/var/log/docrootjava.log :
liste des fichiers Java ajoutés
ou modifiés par rapport à l'installation d'origine.
Ces fichiers journaux permettent d'identifier les fichiers requérant une mise à niveau manuelle.
|
Identifiez les modifications effectuées d'une version de SGD à l'autre.
Le fichier journal customizedchanged.list répertorie les fichiers personnalisés requérant une mise à niveau manuelle. Pour chaque fichier répertorié dans ce fichier journal, le système présente trois versions du fichier :
l'ancienne version personnalisée dans l'un des répertoires suivants :
L'ancienne version standard, sauvegardée dans le répertoire /opt/tarantella/etc/templates.ancienneversion.
La nouvelle version standard, sauvegardée dans le répertoire /opt/tarantella/etc/templates.
Utilisez un utilitaire tel que diff pour compare l'ancien fichier non personnalisé au nouveau fichier non personnalisé. Identifiez les modifications effectuées d'une version de SGD à l'autre.
Appliquez les modifications au fichier personnalisé.
À l'aide d'un utilitaire tel que patch, appliquez les modifications identifiées à l' 2 à la copie du fichier personnalisé.
Copiez le fichier personnalisé mis à niveau à l'emplacement adéquat de la nouvelle installation SGD.
|
Identifiez les modifications effectuées d'une version de SGD à l'autre.
Les fichiers journaux docrootjava.log et customized.list répertorient les fichiers spécifiques requérant une mise à niveau manuelle.
Pour mettre à niveau les fichiers spécifiques, il faut d'abord comparer les versions des fichiers SGD standard afin de repérer les modifications effectuées, puis appliquer les modifications identifiées aux fichiers spécifiques.
Utilisez un utilitaire tel que diff pour compare l'ancien fichier non personnalisé au nouveau fichier non personnalisé. Identifiez les modifications effectuées d'une version de SGD à l'autre.
Pour identifier les modifications, comparez les fichiers suivants :
Appliquez les modifications au fichier spécifique.
À l'aide d'un utilitaire tel que patch, appliquez les modifications identifiées à l'étape 2 à la copie du fichier spécifique.
Copiez le fichier spécifique mis à niveau à l'emplacement adéquat de la nouvelle installation SGD.
Cette section décrit la mise à niveau du module d'enrichissement SGD et du client SGD.
|
Installez la nouvelle version du module d'enrichissement SGD.
Voir Installation du module d'enrichissement SGD pour Microsoft Windows.
|
Lorsque vous mettez à niveau le module d'enrichissement SGD et que vous installez le module audio UNIX, un message peut s'afficher indiquant que le module audio UNIX est déjà en cours d'exécution. Ce message s'affiche lorsque le pilote audio SGD est en cours d'utilisation et ne peut pas être arrêté. Le pilote audio SGD n'ayant pas été modifié dans cette version, vous pouvez ignorer ce message.
Installez la nouvelle version du module d'enrichissement.
Voir Installation du module d'enrichissement SGD sur des plates-formes Solaris.
Installez la nouvelle version du client SGD.
Voir Installation manuelle du client SGD sur les plates-formes SE Solaris et Linux.
Copyright © 2008, Sun Microsystems, Inc. Tous droits réservés