|
| |
| Guide de mise à niveau de Sun Java Enterprise System 5 pour UNIX | |
Chapitre 14
Access ManagerCe chapitre décrit les procédures de mise à niveau du logiciel Access Manager de versions Java ES antérieures vers Java ES 5 (version 5) : Sun Java System Access Manager 7.1.
Ce chapitre présente globalement les problèmes et procédures de mise à niveau de Access Manager 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 d'Access ManagerCette section présente les aspects généraux d'Access Manager qui ont un impact sur la mise à niveau vers Java ES 5 (version 5) :
À propos d'Access Manager pour Java ES version 5
Access Manager pour Java ES version 5 constitue une mise à jour mineure. Elle apporte un certain nombre de corrections de bogues et d'améliorations par rapport à Access Manager pour Java ES version 4, qui constituait une version majeure. Parmi les améliorations qu'apporte la version 5, on trouve notamment une nouvelle fonction de contrôle basée sur la structure de contrôle de Java ES. Pour plus d'informations sur les améliorations qu'apporte la version 5, reportez-vous aux Notes de version de Sun Java System Access Manager 7.1 (http://docs.sun.com/doc/820-0362).
Comme avec la version 4, Access Manager pour la version 5 prend en charge plusieurs référentiels d'identité (emplacements de stockage des données utilisateur). Access Manager pour la version 5 prend donc en charge non seulement un annuaire LDAP, tel que Directory Server, mais également d'autres protocoles et formats de stockage de données.
Du côté de l'interface, la console Access Manager permet de configurer les nouveaux services et référentiels d'identité d'Access Manager.
Afin de proposer une compatibilité ascendante avec les autres composants Java ES, la version 5 peut être exécutée en mode hérité, qui prend en charge les composants Java ES dépendant des services Access Manager pour la version 3 (pour plus d'informations, reportez-vous à la section Problèmes de compatibilité).
Présentation de la mise à niveau d'Access Manager
Le Tableau 14-2 répertorie les méthodes de mise à niveau d'Access Manager vers Java ES version 5 prises en charge. Il s'applique à la fois à Solaris et Linux.
Tableau 14-2 Méthodes de mise à niveau vers Java ES 5 (version 5) : Access Manager 7.1
Version de Java ES
Access Manager Version
Approche globale
Reconfiguration requise
Version 4
Sun Java System Access Manager 7.0 2005Q4
Mise à niveau directe :
effectuée en exécutant un script avant la mise à niveau pour supprimer la version 4, puis en effectuant une installation et une reconfiguration complètes de la version 5.Données de configuration
JSP personnalisées pour la console et l'interface d'authentification d'Access Manager
Schéma d'annuaire
Version 3
Sun Java System Access Manager 6.3 2005Q1
Mise à niveau directe :
effectuée en exécutant un script avant la mise à niveau pour supprimer la version 3, puis en effectuant une installation et une reconfiguration complètes de la version 5.Données de configuration
JSP personnalisées pour la console et l'interface d'authentification d'Access Manager
Schéma d'annuaire
Version 2
Sun Java System Identity Server
6.2 2004Q2
et 6.2 SP1Mise à niveau directe :
effectuée en exécutant un script avant la mise à niveau pour supprimer la version 2, puis en effectuant une installation et une reconfiguration complètes de la version 5.Données de configuration
JSP personnalisées pour la console et l'interface d'authentification d'Access Manager
Schéma d'annuaire
Version 1
Sun ONE Identity Server 6.1
Pas de mise à niveau directe :
effectuez d'abord une mise à niveau vers la version 3 à l'aide des procédures décrites dans le Guide de migration et de mise à niveau de Java Enterprise System 2005Q1 (http://docs.sun.com/doc/819-0062).Ensuite, effectuez la mise à niveau de la version 3 vers la version 5.
Données de configuration
JSP personnalisées pour la console et l'interface d'authentification d'Access Manager
Schéma d'annuaire
Versions antérieures à Java ES
Sun ONE Identity Server 6.0 ou 6.0 SP 1 ou
iPlanet Directory Server Access Management Edition (DSAME) 5.1
Pas de mise à niveau directe.
Données d'Access Manager
Access Manager, comme les autres composants Java ES, utilise divers types de données, qui, pour une mise à niveau particulière, peuvent requérir une migration vers une version mise à niveau. Le tableau suivant affiche les types de données susceptibles d'être affectés par une mise à niveau du logiciel Access Manager.
Stratégie de mise à niveau d'Access Manager
De manière générale, la stratégie à utiliser pour effectuer la mise à niveau d'Access Manager dépend de nombreuses considérations, décrites 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 aborde spécifiquement les questions susceptibles d'influencer le plan de mise à niveau d'Access Manager.
Problèmes de compatibilité
Access Manager pour la version 5 bénéficie d'une compatibilité ascendante avec la version 4 ; néanmoins, la version 4 était une version majeure non compatible avec les versions antérieures (sauf lorsqu'elle était configurée pour s'exécuter en mode hérité). De même, sauf lorsqu'il est configuré pour s'exécuter en mode hérité, Access Manager pour la version 5 ne bénéficie pas de la compatibilité ascendante avec la version 3 (ni avec la version 4 configurée pour s'exécuter en mode hérité).
De plus, Access Manager pour la version 5 n'est pas compatible avec la version 2, quel que soit le mode d'exécution ; la version 5 ne peut pas interagir avec le kit SDK d'Access Manager pour la version 2 et vice-versa.
Access Manager pour la version 5, lorsqu'il est configuré pour s'exécuter dans le nouveau mode domaine, prend en charge plusieurs référentiels d'identité et protocoles de stockage de données. Les données de l'annuaire doivent être migrées dans une nouvelle structure pour que le fonctionnement en mode domaine soit pris en charge. En outre, le mode domaine ne prend pas en charge les autres composants Java ES, comme Portal Server, ni les composants Sun Java Communications Suite, comme Communications Express, Messaging Server etc.
Néanmoins, lorsqu'il est configuré pour s'exécuter en mode domaine, Access Manager pour la version 5 est compatible avec la version 3 (avec quelques exceptions mineures – voir les Notes de version de Sun Java System Access Manager 7.1 (http://docs.sun.com/doc/820-0362)) et les données d'annuaire correspondantes.
Le mode hérité est indispensable à la prise en charge d'autres composants Java ES, ainsi que d'anciennes versions d'agents de modalité d'Access Manager, qui ne peuvent pas interagir avec Access Manager en mode domaine. Cette incompatibilité constitue un point important de la mise à niveau et signifie que, dans la plupart des déploiements de Java ES, Access Manager doit être mis à niveau vers la version 5 en mode hérité.
Même lorsqu'il est configuré pour s'exécuter en mode hérité, Access Manager pour la version 5 n'est pas compatible avec la version 3, ni avec les composants de Sun Java Communications Suite antérieurs. Si Access Manager est mis à niveau vers la version 5, Delegated Administrator pour la version 3 ou une version antérieure doit également être mis à niveau vers la version 5 pour que les utilisateurs puissent utiliser Messaging Server et Calendar Server. Cependant, Messaging Server et Calendar Server n'ont pas besoin, eux, d'être mis à niveau vers la version 5.
La console d'Access Manager pour la version 5, comme la console de la version 4, prend en charge les modes domaine et hérité. En revanche, si vous avez configuré Access Manager pour s'exécuter en mode hérité, vous pouvez utiliser la console réservée au mode hérité qui accompagnait les versions 2 et 3.
Dépendances d'Access Manager
Les dépendances d'Access Manager par rapport à d'autres composants Java ES peuvent avoir une influence sur la procédure de mise à niveau et de reconfiguration du logiciel Access Manager. Les modifications apportées aux interfaces ou fonctions d'Access Manager, par exemple peuvent demander une version mise à niveau des composants dont dépend Access Manager. Le besoin de mettre à jour ces composants dépend de la méthode de mise à niveau spécifique.
Access Manager présente des dépendances par rapport aux composants Java ES suivants :
- Composants partagés. Access Manager présente des dépendances par rapport à des composants partagés Java ES particuliers (voir le Tableau 1-9). Les mises à niveau d'Access Manager peuvent dépendre des versions mises à niveau de ces composants.
- Conteneur Web. Access Manager présente une dépendance obligatoire par rapport aux services de conteneur Web, qui peuvent être fournis soit par Java ES Web Server, soit par Java ES Application Server, ou encore, par des conteneurs Web tiers de WebLogic ou WebSphere. Les mises à niveau d'Access Manager peuvent nécessiter que les JSP personnalisées pour la console Access Manager Console ou pour l'interface d'authentification soient migrées vers l'environnement Access Manager mis à niveau.
- Directory Server. Access Manager présente une dépendance obligatoire par rapport à Directory Server, qui sert à stocker les données de configuration et les données utilisateur. Ainsi, les mises à niveau d'Access Manager peuvent requérir des extensions du schéma d'annuaire.
Scénarios de mise à niveau du conteneur Web
Access Manager peut être déployé dans un conteneur Web fourni par Web Server ou Application Server. Cela peut compliquer la mise à niveau d'Access Manager vers la version 5 car il peut être également nécessaire de mettre à niveau vers la version 5 le 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.
Lors de la mise à niveau d'Access Manager (par exemple lorsque vous utilisez le scriptamconfig), veillez à fournir les valeurs appropriées au scénario de mise à niveau du Tableau 14-4 applicable, surtout s'il implique une mise à niveau majeure de la version du conteneur Web.
Double mise à niveau
La double mise à niveau, qui permet à la fois la mise à niveau d'Access Manager et du système d'exploitation (comme le décrit la section Mises à niveau doubles : Java ES et système d'exploitation) n'est pas prise en charge pour Access Manager.
Par conséquent, si vous devez procéder à une double mise à niveau, vous devez installer ou mettre à niveau un système d'exploitation, puis réinstaller et reconfigurer Access Manager.
Mise à niveau d'Access Manager à partir de Java ES version 4Cette section fournit des informations sur la mise à niveau d'Access Manager à partir de Java ES 2005Q4 (version 4) vers Java ES 5 (version 5). La section aborde les thèmes suivants :
Introduction
Lors de la mise à niveau d'Access Manager pour Java ES version 4 vers la version 5, tenez compte des aspects suivants du processus de mise à niveau :
- Approche générale de mise à niveau. La mise à niveau est effectuée par la suppression des versions précédentes et l'installation de la version 5. Le script ampre71upgrade est fourni pour la suppression de la version 4 et le programme d'installation de Java ES permet alors d'installer la version 5. Access Manager est ensuite reconfiguré à l'aide du script amconfig et le schéma d'annuaire est migré à l'aide du script amupgrade.
- Dépendances pour la mise à niveau. Bien que Access Manager présente des dépendances par rapport à plusieurs composants partagés Java ES (voir le Tableau 1-9), ils sont tous automatiquement mis à niveau vers la version 5 par le programme d'installation de Java ES lorsque vous effectuez la mise à niveau d'Access Manager. Il s'agit notamment de la prise en charge de la nouvelle structure de contrôle de Java ES, qui nécessite un certain nombre de composants partagés qui n'étaient pas nécessaires pour Access Manager pour la version 4.
De plus, Access Manager pour la version 5 dépend de Directory Server et de Web Server (ou d'Application Server ou de conteneurs Web tiers), comme cela est expliqué dans la section Dépendances d'Access Manager. Toutefois, il s'agit de dépendances souples pour la mise à niveau. La mise à niveau de ces composants est facultative dans le cadre de la mise à niveau d'Access Manager vers la version 5.
- Compatibilité ascendante. Access Manager pour la version 5 est compatible avec la version 4 mais n'est pas compatible avec les versions antérieures (voir Problèmes de compatibilité).
- Annulation de la mise à niveau. Il n'existe aucun utilitaire d'annulation de la mise à niveau d'Access Manager. En réalité, le nombre de reconfigurations requises pour restaurer Access Manager à son état initial rend toute annulation complexe. La meilleure manière de pouvoir annuler la mise à niveau est de créer une installation avec les fichiers de configuration sauvegardés et de tester cette installation avant d'effectuer la mise à niveau sur l'installation principale. Vous pouvez ainsi revenir à l'installation d'origine si nécessaire.
- Problèmes relatifs à la plate-forme. L'approche générale de mise à niveau d'Access Manager est identique pour les systèmes d'exploitation Solaris et Linux. Les procédures suivantes indiquent les commandes spécifiques à la plate-forme ou l'emplacement des fichiers si nécessaire.
Mise à niveau complète d'Access Manager pour la version 4
Cette section explique comment effectuer une mise à niveau complète d'Access Manager de Java ES version 4 vers Java ES version 5 :
Tâches à exécuter avant la mise à niveau
Avant de mettre à niveau Access Manager, vous devez effectuer les tâches décrites ci-dessous :
Vérification des informations sur la version actuelle
Vous pouvez vérifier la version actuelle d'Access Manager à l'aide de la commande suivante :
Mise à niveau des dépendances d'Access Manager
Il est généralement recommandé de mettre à niveau tous les composants Java ES sur un même ordinateur (et dans son environnement) vers Java ES version 5. Access Manager présente des dépendances strictes pour la mise à niveau par rapport à un certain nombre de composants partagés (voir le Tableau 1-9).
Si vous choisissez de mettre à niveau les composants par rapport auxquels Access Manager présente des dépendances, vous devez le faire dans l'ordre décrit ci-dessous (en sautant tous les composants déjà mis à niveau), avant d'effectuer la mise à niveau d'Access Manager. La mise à niveau des composants partagés est habituellement réalisée automatiquement par le programme d'installation de Java ES.
- 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. Néanmoins, tous les composants partagés requis par Access Managersont automatiquement mis à niveau par le programme d'installation de Java ES lorsque vous effectuez la mise à niveau d'Access Manager vers la version 5.
- Directory Server (dépendance souple pour la mise à niveau). Les instructions de mise à niveau de Directory Server vers la version 5 sont présentées dans le Chapter 5, "Directory Server".
- Logiciels de conteneur Web (dépendance souple pour la mise à niveau). 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".
Si le conteneur Web n'est pas mis à niveau avant Access Manager, la procédure de mise à niveau (à l'aide du script amconfig) configurera et redéploiera Access Manager dans le conteneur Web existant.
Sauvegarde des données de Directory Server
Le processus de mise à niveau d'Access Manager utilise des scripts qui modifient le schéma de Directory Server. Par conséquent, avant de mettre à niveau Access Manager, sauvegardez vos données Directory Server à l'aide de la console Directory Server ou d'un utilitaire de ligne de commande, tel que db2bak. Vous pouvez utiliser db2ldif pour sauvegarder le schéma et l'arborescence d'informations d'annuaire (DIT) d'Access Manager.
Pour plus d'informations sur la sauvegarde des informations de Directory Server, reportez-vous au Guide d'administration de Sun Java System Directory Server Enterprise Edition 6.0 (http://docs.sun.com/doc/819-0995).
Sauvegarde des informations de configuration d'Access Manager pour la version 4
Étant donné que la reconfiguration d'Access Manager pour la version 5 requiert la reconfiguration de la version 4, il est indispensable de sauvegarder les fichiers de configuration dans un emplacement connu. Vous devez sauvegarder les fichiers suivants :
- Fichier AMConfig.properties
AccessManagerConfig-base/config/AMConfig.properties- Fichier serverconfig.xml
AccessManagerConfig-base/config/serverconfig.xml- Fichiers de configuration du conteneur Web :
- Pour Web Server : recherchez l'emplacement des fichiers server.policy et server.xml dans le Tableau 14-3.
- Pour Application Server : recherchez l'emplacement des fichiers server.policy et domain.xml dans le Tableau 14-3.
- Pour les conteneurs Web tiers : les fichiers de configuration appropriés.
- Fichiers JAR pour l’authentification et les modules personnalisés.
Sauvegarde des fichiers personnalisés du conteneur Web
Si vous disposez de fichiers personnalisés de conteneur Web auxquels Access Manager fait référence, vous devez les sauvegarder. Ces personnalisations peuvent inclure les éléments suivants :
Sauvegarde des fichiers de débogage et journaux d'Access Manager pour la version 4
À des fins d'analyse des informations sur l'état du système, il est conseillé de sauvegarder les fichiers de débogage et les fichiers journaux. Ces fichiers se trouvent aux emplacements suivants :
Sauvegarde des fichiers personnalisés
Si vous avez personnalisé les fichiers localisés installés par le programme d'installation de Java ES ou si vous avez ajouté une localisation non installée par le programme d'installation de Java ES, vous devez sauvegarder ces personnalisations. Ces personnalisations peuvent inclure les éléments suivants :
- Localisation personnalisée de l'interface utilisateur d'Access Manager
AccessManager-base/locale/*_langue.properties- Pages JSP d'interface d’authentification personnalisées
AccessManager-base/web-src/services/config/auth/default_langue- Traductions personnalisées de l'aide en ligne
AccessManager-base/web-src/services/html/langueObtention des mots de passe et informations de configuration requis
Pour mettre à niveau Access Manager, vous devez fournir des informations de configuration particulières, notamment :
Mise à niveau de la version 4 de Access Manager
La mise à niveau du logiciel Access Manager vers Java ES version 5 inclut les procédures de reconfiguration d'Access Manager et de migration de ses données.
Résumé de la mise à niveau
La procédure de mise à niveau d'Access Manager se compose des étapes suivantes :
- Supprimez la version d'Access Manager pour Java ES version 4. Utilisez le script ampre71upgrade.
- Si la mise à niveau vers la version 5 doit être localisée, supprimez les packages de localisation de la version 4. Cette étape doit être effectuée manuellement.
- Installez la version d'Access Manager pour Java ES version 5. Utilisez le programme d'installation de Java ES avec l'option Configurer ultérieurement.
- Annulez le déploiement d'Access Manager, reconfigurez-le et redéployez-le dans un conteneur Web. Utilisez le script amconfig.
- Mettez à jour la structure et le schéma d'annuaire. Utilisez le script amupgrade.
Toutes ces étapes sont détaillées dans les procédures ci-après.
Procédure de mise à niveau
- Effectuez la mise à niveau du logiciel d'accès mobile d'Access Manager.
Le logiciel d'accès mobile d'Access Manager doit être mis à niveau par l'ajout d'un patch pour la version 4. Le tableau suivant répertorie les patchs nécessaires :
Tableau 14-6 Patchs1 de mise à niveau du logiciel d'accès mobile d'Access Manager
Description
ID du patch : Solaris 9 et 10
ID du patch : Linux
Logiciel d'accès mobile
119530-05 (SPARC)
119531-05 (x86)
119532-05
1Les numéros de révision des patchs sont les numéros minimum requis pour la mise à niveau vers Java ES version 5. S'il existe des versions plus récentes, utilisez-les à la place de celles indiquées dans ce tableau.
- Notez les numéros des patchs requis à l'aide du Tableau 14-6.
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
- Effectuez les procédures à effectuer avant d'appliquer le patch qui sont décrites dans les fichiers README.
- Récupérez les valeurs des paramètres suivants requis par le patch :
Tableau 14-7 Paramètres du patch du logiciel d'accès mobile
Paramètre
Valeur
DN du gestionnaire d'annuaires
par défaut : cn=Directory Manager
Mot de passe du gestionnaire d'annuaires
- Appliquez les patchs répertoriés dans le Tableau 14-6.
Sous Solaris :
patchadd ID_patchSous Linux :
./updateEffectuez les procédures à effectuer après l'application du patch qui sont décrites dans les fichiers README.
- Supprimez la version d'Access Manager pour Java ES version 4.
- Connectez-vous en tant qu'utilisateur root sur l'ordinateur qui héberge Access Manager pour la version 4 ou devenez superutilisateur.
su -
- Passez au répertoire arch_se/Product/identity_svr/Tools dans la distribution Java ES version 5, arch_se correspondant à votre plate-forme (par exemple Solaris_sparc).
- Récupérez les valeurs des paramètres suivants requis par le script ampre71upgrade :
Tableau 14-8 Paramètres de configuration d'Access Manager : ampre71upgrade
Paramètre
Valeur
Hôte de Directory Server
Définissez le nom complet : nom_hôte.domaine
Port de Directory Server
Indiquez un numéro de port non SSL1
Valeur par défaut : 389DN de l'administrateur de niveau supérieur
Par défaut : uid=amadmin,ou=People,default_org_DN
Mot de passe de l'administrateur de niveau supérieur
Répertoire dans lequel stocker les fichiers de sauvegarde
Par défaut : AccessManager-base
1Le processus précédant la mise à niveau ne s'effectue pas correctement si vous indiquez un port SSL Directory Server, tel que la valeur SSL par défaut 636.
- Assurez-vous que Directory Server est en cours d'exécution, sinon démarrez-le.
- Exécutez le script ampre71upgrade.
./ampre71upgrade
Le script sauvegarde les fichiers de configuration d'Access Manager et supprime les packages de base de la version 4 (les packages localisés doivent être supprimés manuellement avec la procédure ci-dessous (Step 3)).
- Si la mise à niveau vers la version 5 doit être localisée, supprimez les packages de localisation de la version 4.
Le script ampre71upgrade exécuté à l'Step 2 ci-dessus ne supprime pas les packages de localisation ; vous devrez donc les supprimer manuellement, en effectuant les procédures décrites ci-dessous.
Sous Solaris :
- Recherchez les packages de localisation.
pkginfo | grep SUNWaml
pkginfo | grep SUNWamclnt
pkginfo | grep SUNWamdistauth- Supprimez tous les packages de localisation trouvés à l'Step a ci-dessus.
pkgrm SUNWamllangue
pkgrm SUNWamclntlangue
pkgrm SUNWamdistauthlangueSous Linux :
- Recherchez les RPM de localisation.
rpm -qa | grep sun-identity-sdk-*
rpm -qa | grep sun-identity-clientsdk-*
rpm -qa | grep sun-identity-distauth-*- Supprimez tous les RPM de localisation trouvés à l'Step a ci-dessus.
rpm -e sun-identity-sdk-langue-*
rpm -e sun-identity-clientsdk-langue-*
rpm -e sun-identity-distauth-langue-*- Installez la version d'Access Manager pour Java ES version 5.
Procédez comme suit :
- Lancez le programme d'installation de Java ES sur l'ordinateur qui héberge Access Manager pour la version 4.
cd distribution Java ES version 5/arch_se
./installeroù arch_se correspond à votre plate-forme, telle que Solaris_sparc. (Utilisez l’option installer -nodisplay pour l’interface de ligne de commande.)
Une fois que les pages de bienvenue et du contrat de licence se sont affichées, vous accédez à la page de sélection de composant. (Lorsque des composants installés pouvant être directement mis à niveau par le programme d’installation de Java ES sont détectés, ils sont présentés avec l’état “pouvant être mis à niveau”.)
- Sélectionnez Access Manager dans la page de sélection des composants.
- Spécifiez le même répertoire d'installation que celui dans lequel la version 4 est installée.
- Sélectionnez l'option Configurer ultérieurement.
- Si besoin, sélectionnez l’option d’installation des packages localisés.
- Lorsque l'installation est terminée, quittez le programme d'installation de Java ES.
- Personnalisez de nouveau les JSP d'Access Manager.
Appliquez de nouveau les personnalisations de la version 4 aux pages JSP de la console Access Manager et de l'interface d'authentification que vous avez enregistrées dans la section Sauvegarde des fichiers personnalisés du conteneur Web.
Copiez ensuite les fichiers JSP personnalisés dans les répertoires appropriés :
- Console Access Manager en mode domaine/hérité
AccessManager-base/web-src/services/console- Console Access Manager réservée au mode hérité
AccessManager-base/web-src/applications/console- Interface d'authentification : AccessManager-base/web-src/services/config/auth/default ou AccessManager-base/web-src/services/config/auth/default_langue (où langue est un indicateur d'environnement linguistique tel que ja).
Pour plus d'informations, reportez-vous au Guide du développeur de Sun Java System Access Manager 7.1 (http://docs.sun.com/doc/819-4675).
- Annulez le déploiement d'Access Manager, reconfigurez-le et redéployez-le dans un conteneur Web.
Exécutez le script amconfig pour configurer Access Manager pour votre conteneur Web. Le script amconfig et le fichier d'entrée modèle amsamplesilent se trouvent dans le répertoire suivant :
AccessManager-base/lib
Pour plus d'informations sur le script amconfig et le fichier modèle amsamplesilent, reportez-vous au Guide d'administration de Sun Java System Access Manager 7.1 (http://docs.sun.com/doc/817-4670).
Procédez comme suit pour reconfigurer Access Manager et le redéployer dans le conteneur Web :
- Si vous décidez de mettre à jour le logiciel du conteneur Web, comme décrit dans la section Mise à niveau des dépendances d'Access Manager, assurez-vous que la mise à niveau est complète.
- Vérifiez que l'instance administrative de votre conteneur Web est en cours d'exécution et se trouve dans un mode pris en charge par le script amconfig, comme indiqué dans le tableau suivant :
- Si le conteneur Web s'exécute en mode SSL, vérifiez que les certificats SSL du conteneur n'ont pas expiré et sont toujours en cours de validité.
- Si Access Manager est déployé dans Web Server pour la version 5, désactivez tous les composants Java ES présentant une dépendance par rapport à Access Manager s'exécutant dans la même instance qu'Access Manager.
Il s'agit de composants tels que Portal Server ou des composants Sun Java Communications Suite tels que Communications Express, Instant Messaging ou Delegated Administrator.
La procédure est la suivante :
- Connectez-vous en tant qu'administrateur à l'adresse https://host:8989.
- Allez dans Modifier serveur virtuel.
- Sélectionnez l'onglet Applications Web.
- Cochez toutes les applications dépendant d'Access Manager.
- Cliquez sur Désactiver.
- Cliquez sur Enregistrer.
- Cliquez sur déploiement en attente|Déployer config.
Le changement de configuration va être répercuté à l'instance de Web Server.
- Vérifiez que Directory Server et le conteneur Web approprié sont en cours d'exécution.
- Créez un fichier d'entrée amconfig à partir du fichier d'entrée modèle amsamplesilent :
cp amsamplesilent fichier-config
Dans les étapes suivantes, on considère que fichier-config se trouve dans le même répertoire que amsamplesilent.
- Définissez les paramètres de configuration dans fichier-config.
Ils doivent tous être définis correctement. Certaines valeurs peuvent être migrées du fichier AMConfig.properties et d'autres sont plus spécifiques à la procédure de mise à niveau, comme indiqué dans le tableau ci-dessous.
Tableau 14-10 Paramètres de configuration d'Access Manager : amconfig
Paramètre
Valeur
Paramètres de mise à niveau
DEPLOY_LEVEL
Définissez la valeur 26 pour annuler le déploiement ou
Définissez la valeur 1 pour reconfigurer et déployerDIRECTORY_MODE
Définissez la valeur 5
AM_REALM1
Définissez la valeur disabled si le mode hérité est activé.
Définissez la valeur enabled si le mode domaine est activé.
Valeur par défaut : enabledJAVA_HOME
Définissez cette variable sur le répertoire du JDK version 5 : /usr/java/jdk1.5.0_04/
WEB_CONTAINER
Définissez la valeur WS pour Web Server 7.x
Définissez la valeur WS6 pour Web Server 6.x
Définissez la valeur AS8 pour Application Server 8.x
Définissez la valeur WAS5 pour IBM WebSphere 5.x
Définissez la valeur WL8 pour BEA WebLogic 8.x
et remplissez uniquement la section correspondante dans fichier-config.WS_INSTANCE
(si vous utilisez Web Server 7.x comme conteneur Web)Définissez la valeur de cette variable sur le nom du répertoire de configuration de l'instance (sensible à la casse) : https-nomConfig/
Ce répertoire se trouve dans le chemin suivant : WebServer7Config-base/https-nomConfig/
WS61_INSTANCE
(si vous utilisez Web Server 6.x comme conteneur Web)Définissez la valeur de cette variable sur le nom du répertoire de configuration de l'instance (sensible à la casse) : https-nomInstance
Ce répertoire se trouve dans le chemin suivant : WebServer6-base/https-nomInstance/
AS81_INSTANCE
(si vous utilisez Application Server 8.x comme conteneur Web)Définissez cette variable sur le nomInstance d'Application Server 8.x .
Par défaut : server
AS81_INSTANCE_DIR
(si vous utilisez Application Server 8.x comme conteneur Web)Définissez la variable sur le répertoire de domaine d'Application Server 8.x pour l'instance, qui est par défaut
AppServer8Config-base/domains/domain1
AS81_DOCS_DIR
(si vous utilisez Application Server 8.x comme conteneur Web)Définissez cette variable sur le répertoire docroot d'Application Server 8.x pour l'instance, qui est par défaut
AppServer8Config-base/domains/domain1/docroot
Migré du fichier AMConfig.properties
SERVER_PROTOCOL
com.iplanet.am.server.protocol
SERVER_PORT
com.iplanet.am.server.port
SERVER_HOST
com.iplanet.am.server.host
DS_HOST
com.iplanet.am.directory.host
DS_PORT
com.iplanet.am.directory.port
ROOT_SUFFIX2
com.iplanet.am.defaultOrg
CONSOLE_DEPLOY_URI
com.iplanet.am.console.deploymentDescriptor
SERVER_DEPLOY_URI
com.iplanet.am.services.deploymentDescriptor
PASSWORD_DEPLOY_URI
com.sun.identity.password.deploymentDescriptor
AM_ENC_PWD2
am.encryption.pwd3
1Pour plus d'informations sur les modes domaine et hérité, reportez-vous à la section Problèmes de compatibilité.
2La valeur de ce paramètre doit être la même que dans la version précédente d'Access Manager.
3Lorsque Access Manager et le kit SDK d'Access Manager sont tous les deux déployés, la valeur de cette propriété doit être la même pour l'instance d'Access Manager et l'instance de SDK associée.
Pour les autres paramètres, reprenez les mêmes valeurs que celles utilisées dans la configuration de la version 4 que vous mettez à niveau, sauf si vous changez de conteneur Web ou de mots de passe. Par exemple, si vous avez mis à niveau Web Server vers la version 5, utilisez les valeurs suivantes :
- Exécutez amconfig pour annuler le déploiement d'Access Manager.
Paramétrez la valeur de DEPLOY_LEVEL dans fichier-config sur 26.
cd /AccessManager-base/bin
./amconfig -s AccessManager-base/bin/fichier-config- Vérifiez que le conteneur d'agent commun est en cours d'exécution.
netstat -an | grep 11163
Si ce n'est pas le cas, démarrez-le.
/usr/sbin/cacaoadm start
- Exécutez amconfig pour reconfigurer Access Manager et le déployer dans le conteneur Web.
Paramétrez la valeur de DEPLOY_LEVEL dans fichier-config sur 1.
cd /AccessManager-base/bin
./amconfig -s AccessManager-base/bin/fichier-config- Mettez à jour la structure et le schéma d'annuaire.
Access Manager pour la version 5 coexiste avec la structure d'annuaire de la version 4, mais cette structure doit être modifiée pour prendre en charge les fonctionnalités de la version 5. Mettez à jour la structure et le schéma d'annuaire d'Access Manager vers la version 5 en exécutant le script amupgrade qui se trouve dans le répertoire suivant :
- Sous Solaris :
AccessManager-base/upgrade/scripts- Sous Linux :
AccessManager_base/identity/upgrade/scripts- Récupérez les valeurs des paramètres suivants requis par le script amupgrade :
Tableau 14-12 Paramètres de configuration d'Access Manager : amupgrade
Paramètre
Valeur
Nom complet de l'hôte Directory Server
Définissez le nom complet : nom_hôte.domaine
Port de Directory Server
Indiquez un numéro de port non SSL1
Valeur par défaut : 389DN du gestionnaire d'annuaires
Par défaut : cn=Directory Manager
Mot de passe du gestionnaire d'annuaires
DN de l'administrateur de niveau supérieur
Par défaut : uid=amadmin,ou=People,default_org_DN
Mot de passe de l'administrateur de niveau supérieur
Activer mode domaine
(ce paramètre n'est pas requis pour la mise à niveau à partir du mode domaine de la version 4)Y/N : Yes signifie que le mode domaine est activé et que les données de services sont migrées vers la nouvelle arborescence Domaine2. No (valeur par défaut) signifie que les données des services restent en mode hérité.
1Vous devez spécifier pour Directory Server un port SSL différent de la valeur SSL par défaut (636).
2Voir la section Migration vers le mode domaine.
- Exécutez le script amupgrade.
cd AccessManager-base/upgrade/scripts
./amupgradeSi la mise à niveau est réussie, le script affiche « Upgrade completed ».
- Vérifiez les informations d'extension du schéma d'annuaire dans le fichier journal de mise à niveau suivant :
Sous Solaris :
/var/sadm/install/logs/
Sun_Java_System_Access_Manager_upgrade_dit_log.mmddhhmmSous Linux :
/var/log/Sun_Java_System_Access_Manager_upgrade_dit_log.mmddhhmm- Activez les composants désactivés dans l'Step d.
- Redémarrez le conteneur Web sur lequel Access Manager est déployé.
- Démarrez Access Manager.
Redémarrez le conteneur Web sur lequel Access Manager est déployé.
Vérification de la mise à niveau d'Access Manager
Une fois la mise à niveau terminée, vérifiez qu'elle a été correctement effectuée, comme suit :
AccessManager-base/bin/amadmin --version
Voir le Tableau 14-5 pour les valeurs de résultat.
- Vérifiez l'état de la mise à niveau en consultant les fichiers journaux de mise à niveau suivants dans le répertoire /var/sadm/install/logs :
- Vérifiez l'état de la migration d'Access Manager en recherchant les erreurs dans la fenêtre de terminal pendant l'exécution du script amupgrade.
Consultez également le fichier journal suivant dans le répertoire /var/sadm/install/logs :
Sun_Java_System_Access_Manager_upgrade_dit_log.horodatage
- Vérifiez les fichiers de dépannage d'Access Manager pour déceler toute erreur.
Ces fichiers se trouvent dans l'emplacement spécifié dans la propriété com.iplanet.services.debug.directory du fichier AMConfig.properties. Les valeurs par défaut sont les suivantes :
Sous Solaris :
/var/opt/SUNWam/debugSous Linux :
/var/opt/sun/identity/debugTâches à exécuter après la mise à niveau
Veuillez noter les procédures post-mise à niveau requises dans le cadre des situations suivantes :
Migration vers le mode domaine
Si vous avez migré vers le mode domaine pendant la mise à niveau d'Access Manager vers la version 5 (pendant l'exécution du script amupgrade pour mettre à jour le schéma et la structure d'annuaire, vous avez répondu Yes lorsque le système vous a proposé d'activer le mode domaine), vous devez effectuer les étapes suivantes :
Security Assertion Markup Language
Si vous utilisez le service SAML (Security Assertion Markup Language), vous devez ajouter et activer le module d'authentification SAML à l'aide de la console Access Manager. Pour plus d'informations sur la création d'une instance de module d'authentification SAML, reportez-vous au Guide d'administration de Sun Java System Access Manager 7.1 (http://docs.sun.com/doc/819-4670).
Annulation de la mise à niveau
Aucun script n'est fourni pour la restauration d'Access Manager à son état antérieur à la mise à niveau. Ce processus doit être réalisé manuellement à l'aide des données d'Access Manager sauvegardées au cours des tâches antérieures à la mise à niveau (voir la section Sauvegarde des fichiers de débogage et journaux d'Access Manager pour la version 4). L'annulation de la mise à niveau est trop difficile pour être pratique.
Pour annuler la mise à niveau, vous pouvez réinstaller la version 4 et migrer tous les fichiers de configuration que vous avez sauvegardés vers les emplacements appropriés. Vous pouvez aussi créer un système parallèle en utilisant les fichiers de configuration sauvegardés avant d'effectuer la mise à niveau et tester cette installation avant d'effectuer la mise à niveau sur l'installation principale.
Mise à niveau de plusieurs instances
Dans certaines architectures, Access Manager est déployé sur plusieurs systèmes afin de permettre l'évolutivité et une haute disponibilité.
Il est généralement souhaitable de mettre à niveau les instances d'Access Manager les unes après les autres afin de ne pas interrompre le service. Cette section explique comment effectuer la mise à niveau progressive d'Access Manager pour la version 4 vers la version 5.
L'architecture de déploiement décrite dans la figure suivante sera utilisée pour illustrer la procédure de mise à niveau progressive.
Figure 14-1 Exemple d'architecture de déploiement pour plusieurs instances d'Access Manager
Dans cette architecture, plusieurs instances d'Access Manager sont accessibles par l'intermédiaire d'un équilibreur de charge, et ces instances accèdent elles-mêmes à un annuaire configuré pour la réplication multimaître (MMR). Même s'il est possible d'utiliser d'autres schémas de réplication Directory Server, l'utilisation de MMR est représentative des services d'annuaire haute disponibilité évolutifs. Dans la Figure 14-1, les instances d'Access Manager et de Directory Server sont regroupées pour faciliter l'explication de la procédure de mise à niveau. Par exemple Access Manager 2 illustre les instances d'Access Manager de la 2ème à la nème.
La procédure expliquant la mise à niveau progressive d'Access Manager pour la version 4 vers la version 5 est basée sur l'interopérabilité suivante : des instances d'Access Manager pour la version 5 et pour la version 4 peuvent coexister et s'exécuter simultanément en exploitant le même annuaire si le schéma d'annuaire n'a pas encore été mis à jour vers la version 5.
C'est pourquoi, pour les instances d'Access Manager pointant sur une seule instance de Directory Server, vous pouvez effectuer une mise à niveau progressive en reportant la mise à jour du schéma d'annuaire jusqu'à ce que toutes les instances d'Access Manager aient été mises à niveau.
Pour effectuer une mise à niveau progressive d'Access Manager pour la version 4 vers la version 5, procédez comme suit :
- Sauvegardez les informations de configuration de la version 4 de toutes les instances d'Access Manager.
Voir le Tableau 14-3.
- Mettez à niveau Access Manager 1.
- Désactivez Access Manager 1 dans l'équilibreur de charge.
Les requêtes ne sont plus routées vers Access Manager 1.
- Effectuez la mise à niveau partielle d'Access Manager 1.
Effectuez la mise à niveau d'Access Manager comme cela est décrit dans la section Mise à niveau de la version 4 de Access Manager, sans effectuer la mise à jour de la structure et du schéma d'annuaire (Step 7).
- Activez Access Manager 1 dans l'équilibreur de charge.
- Mettez à niveau les instances Access Manager 2 àAccess Manager n.
Pour plus de simplicité, dans les étapes suivantes, Access Manager 2 désignera les instances Access Manager 2 à Access Manager n.
- Désactivez Access Manager 2 dans l'équilibreur de charge.
Les requêtes ne sont plus routées vers Access Manager 2.
- Effectuez la mise à niveau partielle d'Access Manager 2.
Effectuez la mise à niveau de toutes les instances d'Access Manager comme cela est décrit dans la section Mise à niveau de la version 4 de Access Manager, sans effectuer la mise à jour de la structure et du schéma d'annuaire (Step 7).
- Activez Access Manager 2 dans l'équilibreur de charge.
Les requêtes sont de nouveau routées vers Access Manager 2.
- Mettez à jour la structure et le schéma d'annuaire pour Directory Server 1.
Utilisez le script amupgrade comme cela est décrit dans l'Step 7. Access Manager 1 fonctionne toujours lorsque le schéma pour Directory Server 2 a été mis à jour.
Mises à niveau concernant uniquement le SDK d'Access Manager pour la version 4
Dans certaines architectures de déploiement, le composant SDK d'Access Manager est installé sur un ou plusieurs ordinateurs sans que d'autres composants d'Access Manager soient installés sur ces ordinateurs. Le SDK d'Access Manager sert d'interface distante vers Access Manager et doit être reconfiguré dans le même mode de fonctionnement qu'Access Manager : hérité ou domaine.
Le SDK d'Access Manager et l'instance complète d'Access Manager pour laquelle il sert d'interface distante doivent tous les deux être mis à niveau vers la version 5. Néanmoins, Access Manager pour la version 5 est compatible avec le kit SDK d'Access Manager pour la version 4 ; pour cette raison, Access Manager doit généralement être mis à niveau avant de mettre à niveau le kit SDK d'Access Manager sur les autres ordinateurs.
En tant qu'interface distante vers Access Manager, il est inutile de configurer le kit SDK pour accéder à Directory Server. Si le kit SDK d'Access Manager sert à prendre en charge un composant Web (tel que Portal Server) qui dépend des services de conteneur Web, il doit être configuré pour le conteneur Web correspondant. En revanche, le kit SDK d'Access Manager peut aussi prendre en charge des composants non Web, auquel cas aucun conteneur Web n'est nécessaire.
La procédure de mise à niveau du SDK d'Access Manager représente une partie de la procédure de la mise à niveau complète d'Access Manager, en fonction des caractéristiques ci-dessus.
Cette section explique comment effectuer une mise à niveau uniquement du SDK d'Access Manager de Java ES version 4 vers Java ES version 5 :
Tâches à exécuter avant la mise à niveau
Les tâches à effectuer avant la mise à niveau du SDK d'Access Manager sont identiques à celles à effectuer avant la mise à niveau de la version complète d'Access Manager (voir Tâches à exécuter avant la mise à niveau) mais excluent les étapes liées à Directory Server et aux personnalisations des pages JSP des outils d'administration. Les tâches à exécuter avant la mise à niveau du SDK d'Access Manager sont les suivantes :
Mise à niveau du SDK d'Access Manager pour la version 4
Les procédures de mise à niveau du SDK d'Access Manager sont identiques à celles de la mise à niveau de la version complète d'Access Manager, mais excluent les étapes liées à la localisation, aux personnalisations des pages JSP des outils d'administration et à la migration du schéma d'annuaire.
- Supprimez le kit SDK d'Access Manager correspondant à Java ES version 4.
Suivez les instructions décrites dans la section Supprimez la version d'Access Manager pour Java ES version 4., mais ne supprimez que le kit SDK d'Access Manager.
- Installez le kit SDK d'Access Manager correspondant à Java ES version 5.
Suivez les instructions décrites dans la section Installez la version d'Access Manager pour Java ES version 5., mais n'installez que le kit SDK d'Access Manager.
- Reconfigurez le kit SDK d'Access Manager.
Suivez les instructions décrites dans la section Annulez le déploiement d'Access Manager, reconfigurez-le et redéployez-le dans un conteneur Web., mais définissez DEPLOY_LEVEL comme suit :
Vérification de la mise à niveau du SDK d'Access Manager
Il existe trois méthodes pour savoir si la mise à niveau du SDK d'Access Manager est réussie :
- Exécutez Portal Server, ou tout autre composant utilisant le kit SDK d'Access Manager comme interface avec Access Manager, et vérifiez que l'authentification fonctionne.
- Exécutez les exemples du kit SDK d'Access Manager qui se trouvent à l'emplacement suivant :
AccessManager-base/samples/sdk
- Vérifiez la valeur de la propriété com.iplanet.am.version qui se trouve dans le fichier AMConfig.properties :
AccessManagerConfig-base/config/AMConfig.properties
Annulation de la mise à niveau
Aucun script n'est fourni pour la restauration d'Access Manager à son état antérieur à la mise à niveau. Ce processus doit être réalisé manuellement à l'aide des données d'Access Manager sauvegardées au cours des tâches antérieures à la mise à niveau (voir la section Sauvegarde des fichiers de débogage et journaux d'Access Manager pour la version 4). L'annulation de la mise à niveau est trop difficile pour être pratique.
Pour annuler la mise à niveau, vous pouvez réinstallez la version 4 et faire migrer tous les fichiers de configuration que vous avez sauvegardés vers les emplacements appropriés. Vous pouvez aussi créer un système parallèle en utilisant les fichiers de configuration sauvegardés avant d'effectuer la mise à niveau et tester cette installation avant d'effectuer la mise à niveau sur l'installation principale.
Mise à niveau d'Access Manager à partir de Java ES version 3La procédure de mise à niveau d'Access Manager ou du kit SDK d'Access Manager pour Java ES 2003Q1 (version 3) vers la version 5 est similaire à celle de mise à niveau d'Access Manager ou du kit SDK d'Access Manager pour la version 4 vers la version 5, sauf pour les mises à niveau portant sur plusieurs instances.
Mise à niveau de Access Manager pour la version 3
Pour mettre à niveau Access Manager ou le kit SDK d'Access Manager pour la version 3 vers la version 5, suivez les instructions décrites dans la section Mise à niveau d'Access Manager à partir de Java ES version 4, en remplaçant chaque occurrence de version 4 par version 3.
Mise à niveau de plusieurs instances
Dans certaines architectures, Access Manager est déployé sur plusieurs systèmes afin de permettre l'évolutivité et une haute disponibilité.
Il est généralement souhaitable de mettre à niveau les instances d'Access Manager les unes après les autres afin de ne pas interrompre le service. Cette section explique comment effectuer la mise à niveau progressive d'Access Manager pour la version 3 vers la version 5.
L'architecture de déploiement décrite dans la figure suivante sera utilisée pour illustrer la procédure de mise à niveau progressive.
Figure 14-2 Exemple d'architecture de déploiement pour plusieurs instances d'Access Manager
Dans cette architecture, plusieurs instances d'Access Manager sont accessibles par l'intermédiaire d'un équilibreur de charge, et ces instances accèdent elles-mêmes à un annuaire configuré pour la réplication multimaître (MMR). Même s'il est possible d'utiliser d'autres schémas de réplication Directory Server, l'utilisation de MMR est représentative des services d'annuaire haute disponibilité évolutifs. Dans la Figure 14-2, les instances d'Access Manager et de Directory Server sont regroupées pour faciliter l'explication de la procédure de mise à niveau. Par exemple Access Manager 2 illustre les instances d'Access Manager de la 2ème à la nème.
La procédure de mise à niveau progressive d'Access Manager de la version 3 vers la version 5 est soumise à la contrainte suivante : Access Manager pour la version 5 ne peut pas coexister avec la structure d'annuaire de la version 3. Cependant, si les instances de Directory Server sont répliquées, comme dans la Figure 14-2, vous pouvez effectuer une mise à niveau progressive en utilisant la procédure suivante :
- Sauvegardez les informations de configuration de la version 3 de toutes les instances d'Access Manager.
Voir la section Tableau 14-3.
- Modifiez la configuration d'Access Manager 1.
- Mettez à niveau les instances Access Manager 2 àAccess Manager n.
Pour plus de simplicité, dans les étapes suivantes, Access Manager 2 désignera les instances Access Manager 2 à Access Manager n.
- Désactivez Access Manager 2 dans l'équilibreur de charge.
Les requêtes ne sont plus routées vers Access Manager 2.
- Effectuez la mise à niveau partielle d'Access Manager 2.
Effectuez la mise à niveau de toutes les instances d'Access Manager comme cela est décrit dans la section Mise à niveau de la version 4 de Access Manager, sans effectuer la mise à jour de la structure et du schéma d'annuaire (Step 7).
- Désactivez la fonction MMR de Directory Server.
- Mettez à jour la structure et le schéma d'annuaire pour Directory Server 1.
Utilisez le script amupgrade comme cela est décrit dans l'Step 7. Access Manager 1 fonctionne toujours car le schéma pour Directory Server 2 n'a pas été mis à jour.
- Redémarrez Access Manager 2.
- Activez Access Manager 2 dans l'équilibreur de charge.
Les requêtes sont de nouveau routées vers Access Manager 2.
- Mettez à niveau Access Manager 1.
- Désactivez Access Manager 1 dans l'équilibreur de charge.
Les requêtes ne sont plus routées vers Access Manager 1.
- Effectuez la mise à niveau partielle d'Access Manager 1.
Effectuez la mise à niveau d'Access Manager comme cela est décrit dans la section Mise à niveau de la version 4 de Access Manager, sans effectuer la mise à jour de la structure et du schéma d'annuaire (Step 7).
- Activez la fonction MMR de Directory Server.
Le schéma (et les données) de Directory Server 2 sont maintenant mis à jour.
- Restaurez la configuration d'Access Manager 1 pour que celui-ci pointe sur Directory Server 1.
- Redémarrez Access Manager 1.
- Activez Access Manager 1 dans l'équilibreur de charge.
Les requêtes sont de nouveau routées vers Access Manager 1 ainsi que vers toutes les autres instances d'Access Manager mises à niveau.
Mise à niveau d'Access Manager à partir de Java ES version 2La procédure de mise à niveau d'Access Manager pour Java ES 2004Q2 (version 2) vers la version 5 est similaire à la procédure de mise à niveau d'Access Manager pour la version 4 vers la version 5 (à quelques détails près) comme cela est indiqué dans les sections ci-dessous :
De même, la procédure de mise à niveau du kit SDK d'Access Manager pour Java ES 2004Q2 (version 2) vers la version 5 est similaire à la procédure de mise à niveau du kit SDK d'Access Manager pour la version 4 vers la version 5 (voir la section Mises à niveau concernant uniquement le SDK d'Access Manager pour la version 4), avec les mêmes types d'exceptions. Les mises à niveau ne concernant que le kit SDK d'Access Manager excluent les procédures liées à la localisation, aux personnalisations des pages JSP de l'outil d'administration d'Access Manager et à la migration du schéma d'annuaire.
Le kit SDK d'Access Manager pour la version 2 et l'instance complète d'Access Manager pour la version 2 pour laquelle il sert d'interface distante doivent tous les deux être mis à niveau vers la version 5. Il n'est pas possible d'utiliser un mélange de composants de la version 2 et de la version 5. C'est pourquoi toutes les instances d'Access Manager pour la version 2 et du kit SDK d'Access Manager pour la version 2 doivent être mises à niveau vers la version 5.
Remarque
Si vous procédez à une mise à niveau d'Access Manager pour la version 2 sur la plate-forme Linux, il vous faudra procéder à une double mise à niveau (pour Access Manager et le système d'exploitation). Access Manager pour la version 5 n'est pas pris en charge sur RHEL 2.1. Pour plus d’informations, reportez-vous à la section Double mise à niveau.
Tâches à exécuter avant la mise à niveau
Avant de mettre à niveau Access Manager, réalisez les procédures décrites dans la section Tâches à exécuter avant la mise à niveau, avec les exceptions et tâches supplémentaires suivantes :
Mise à niveau des dépendances d'Access Manager
Comparées à la mise à niveau à partir de la version 4, les tâches à exécuter avant la mise à niveau de la version 2 vers la version 5 incluent la mise à niveau vers la version 5 de tous les composants partagés (voir le Tableau 1-9) et de tous les composants locaux dont dépend Access Manager.
La mise à niveau des composants dépendant d'Access Manager doit être effectuée dans l'ordre suivant, avant la mise à niveau d'Access Manager. Vous pouvez ignorer tout composant déjà mis à niveau.
- Composants partagés. Les instructions de synchronisation 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". Néanmoins, tous les composants partagés Java ES sont automatiquement mis à niveau par le programme d'installation lorsque vous effectuez une nouvelle installation d'Access Manager pour la version 5.
- Directory Server. Directory Server se trouve rarement sur le même ordinateur qu'Access Manager. Vous trouverez tout de même les instructions de mise à niveau de Directory Server vers la version 5 dans la section Mise à niveau de Directory Server à partir de Java ES version 2.
- Logiciels de conteneur Web. Les instructions de mise à niveau de Web Server ou d'Application Server sont présentées respectivement dans les sections Mise à niveau de Web Server à partir de Java ES version 3 et Mise à niveau d'Application Server à partir de Java ES version 2.
Mise à niveau du schéma d'annuaire
Si Directory Server a été configuré avec l'outil Directory Preparation Tool de Sun Java Communications Suite (comm_dssetup.pl) pour assurer la prise en charge des composants Communication Suite tels que Messaging Server et Calendar Server, vous devez commencer par effectuer la mise à niveau du schéma d'annuaire en utilisant Directory Preparation Tool 6.4 avant d'effectuer la mise à niveau d'Access Manager (reportez-vous au Guide de mise à niveau de Sun Java Communications Suite 5, http://docs.sun.com/doc/819-7561). Effectuez cette tâche antérieure à la mise à niveau une fois que vous avez mis à niveau les composants dépendant d'Access Manager.
Réindexation de l'annuaire
Pour éviter les complications au moment de la mise à niveau d'Access Manager après la mise à niveau du schéma d'annuaire (voir la section Mise à niveau du schéma d'annuaire, ci-dessus), vous devez réindexer manuellement le suffixe de la racine de l'annuaire d'Access Manager, de la manière suivante :
Directory Server pour la version 2 à 4 :
Directory Server pour la version 5 :
- cd DirServer-base/ds6/bin
- ./dsconf reindex -D "cn=Directory Manager" -e -w fichierMotdepasse suffixe
où
-e spécifie une connexion non sécurisée
-D désigne le gestionnaire d'annuaires
-w est un fichier de mot de passe contenant seulement le mot de passe
suffixe est le suffixe de la racine du document de l'annuaire d'Access Manager
En fonction du nombre d'entrées dans l'annuaire, la réindexation peut prendre beaucoup de temps.
Mise à niveau d'Access Manager pour la version 2
La procédure de mise à niveau d'Access Manager à partir de la version 2 vers la version 5 dépend du conteneur Web dans lequel vous déployez le logiciel Access Manager.
Mise à niveau d'Access Manager pour la version 2 : conteneur Web Web Server
Pour mettre à niveau Access Manager pour la version 2 vers la version 5, lors d'un déploiement dans un conteneur Web Server, suivez les instructions décrites dans la section Mise à niveau de la version 4 de Access Manager, en remplaçant chaque occurrence de version 4 par version 2.
Mise à niveau d'Access Manager pour la version 2 : conteneur Web Application Server
Pour mettre à niveau Access Manager pour la version 2 vers la version 5, lors du déploiement dans un conteneur Web Application Server, il existe deux cas possibles :
- Application Server pour la version 5 vient d'être installé. Dans ce cas, pour mettre à niveau Access Manager pour la version 2 vers la version 5, suivez les instructions décrites dans la section Mise à niveau de la version 4 de Access Manager, en remplaçant chaque occurrence de version 4 par version 2.
- Application Server pour la version 2 vient d'être mis à niveau vers la version 5. L'instance d'Application Server pour la version 2 dans laquelle Access Manager a été initialement déployé (nomInstance), lors de sa mise à niveau vers la version 5, a été migrée sous un agent du nud créé par le processus de mise à niveau. La mise à niveau d'Access Manager dans cette instance mise à niveau d'Application Server demande l'exécution des étapes supplémentaires décrites dans les sections suivantes :
Résumé de la mise à niveau
La procédure de mise à niveau d'Access Manager se compose des étapes suivantes :
- Supprimez la version d'Access Manager pour Java ES version 2. Utilisez le script ampre71upgrade.
- Si la mise à niveau vers la version 5 doit être localisée, supprimez les packages de localisation de la version 2. Cette étape doit être effectuée manuellement.
- Installez la version d'Access Manager pour Java ES version 5. Utilisez le programme d'installation de Java ES avec l'option Configurer ultérieurement.
- Démarrez les instances suivantes d'Application Server : Serveur d'administration du domaine, agent du nud et instance de serveur dans laquelle Access Manager est déployé.
- Annulez le déploiement d'Access Manager, reconfigurez-le, puis redéployez-le dans l'instance d'Application Server. Utilisez le script amconfig.
- Mettez à jour la structure et le schéma d'annuaire. Utilisez le script amupgrade.
Toutes ces étapes sont détaillées dans les procédures ci-après.
Procédure de mise à niveau
- Effectuez la mise à niveau du logiciel d'accès mobile d'Access Manager.
Le logiciel d'accès mobile d'Access Manager doit être mis à niveau par l'ajout d'un patch pour la version 2. Le tableau suivant répertorie les patchs nécessaires :
Tableau 14-13 Patchs1 de mise à niveau du logiciel d'accès mobile d'Access Manager
Description
ID du patch : Solaris 9 et 10
ID du patch : Linux
Logiciel d'accès mobile
119530-05 (SPARC)
119531-05 (x86)
119532-05
1Les numéros de révision des patchs sont les numéros minimum requis pour la mise à niveau vers Java ES version 5. S'il existe des versions plus récentes, utilisez-les à la place de celles indiquées dans ce tableau.
- Notez les numéros des patchs requis à l'aide du Tableau 14-6.
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
- Effectuez les procédures à effectuer avant d'appliquer le patch qui sont décrites dans les fichiers README.
- Récupérez les valeurs des paramètres suivants requis par le patch :
Tableau 14-14 Paramètres du patch du logiciel d'accès mobile
Paramètre
Valeur
DN du gestionnaire d'annuaires
par défaut : cn=Directory Manager
Mot de passe du gestionnaire d'annuaires
- Appliquez les patchs répertoriés dans le Tableau 14-6.
Sous Solaris :
patchadd ID_patchSous Linux :
./updateEffectuez les procédures à effectuer après l'application du patch qui sont décrites dans les fichiers README.
- Supprimez la version d'Access Manager pour Java ES version 2.
- Connectez-vous en tant qu'utilisateur root sur l'ordinateur qui héberge Access Manager pour la version 4 ou devenez superutilisateur.
su -
- Passez au répertoire arch_se/Product/identity_svr/Tools dans la distribution Java ES version 5, arch_se correspondant à votre plate-forme (par exemple Solaris_sparc).
- Récupérez les valeurs des paramètres suivants requis par le script ampre71upgrade :
Tableau 14-15 Paramètres de configuration d'Access Manager : ampre71upgrade
Paramètre
Valeur
Hôte de Directory Server
Définissez le nom complet : nom_hôte.domaine
Port de Directory Server
Indiquez un numéro de port non SSL1
Valeur par défaut : 389DN de l'administrateur de niveau supérieur
Par défaut : uid=amadmin,ou=People,default_org_DN
Mot de passe de l'administrateur de niveau supérieur
Répertoire dans lequel stocker les fichiers de sauvegarde
Par défaut : AccessManager-base
1Vous devez spécifier pour Directory Server un port SSL différent de la valeur SSL par défaut (636).
- Assurez-vous que Directory Server est en cours d'exécution, sinon démarrez-le.
- Exécutez le script ampre71upgrade.
./ampre71upgrade
Le script sauvegarde les fichiers de configuration d'Access Manager et supprime les packages de base de la version 4 (les packages localisés doivent être supprimés manuellement avec la procédure ci-dessous (Step 3)).
- Si la mise à niveau vers la version 5 doit être localisée, supprimez les packages de localisation de la version 2.
Le script ampre71upgrade exécuté à l'Step 2 ci-dessus ne supprime pas les packages de localisation ; vous devrez donc les supprimer manuellement, en effectuant les procédures décrites ci-dessous.
Sous Solaris :
- Recherchez les packages de localisation.
pkginfo | grep SUNWaml
pkginfo | grep SUNWamclnt
pkginfo | grep SUNWamdistauth- Supprimez tous les packages de localisation trouvés à l'Step a ci-dessus.
pkgrm SUNWamllangue
pkgrm SUNWamclntlangue
pkgrm SUNWamdistauthlangueSous Linux :
- Recherchez les RPM de localisation.
rpm -qa | grep sun-identity-sdk-*
rpm -qa | grep sun-identity-clientsdk-*
rpm -qa | grep sun-identity-distauth-*- Supprimez tous les RPM de localisation trouvés à l'Step a ci-dessus.
rpm -e sun-identity-sdk-langue-*
rpm -e sun-identity-clientsdk-langue-*
rpm -e sun-identity-distauth-langue-*- Installez la version d'Access Manager pour Java ES version 5.
Procédez comme suit :
- Lancez le programme d'installation de Java ES sur l'ordinateur qui héberge Access Manager pour la version 2.
cd distribution Java ES version 5/arch_se
./installeroù arch_se correspond à votre plate-forme, telle que Solaris_sparc. (Utilisez l’option installer -nodisplay pour l’interface de ligne de commande.)
Une fois que les pages de bienvenue et du contrat de licence se sont affichées, vous accédez à la page de sélection de composant. (Lorsque des composants installés pouvant être directement mis à niveau par le programme d’installation de Java ES sont détectés, ils sont présentés avec l’état “pouvant être mis à niveau”.)
- Sélectionnez Access Manager dans la page de sélection des composants.
- Spécifiez le même répertoire d'installation que celui dans lequel la version 2 est installée.
- Sélectionnez l'option Configurer ultérieurement.
- Si besoin, sélectionnez l’option d’installation des packages localisés.
- Lorsque l'installation est terminée, quittez le programme d'installation de Java ES.
- Personnalisez de nouveau les JSP d'Access Manager.
Appliquez de nouveau les personnalisations de la version 2 aux pages JSP de la console Access Manager et de l'interface d'authentification que vous avez enregistrées dans la section Sauvegarde des fichiers personnalisés du conteneur Web.
Copiez ensuite les fichiers JSP personnalisés dans les répertoires appropriés :
- Console Access Manager réservée au mode hérité
AccessManager-base/web-src/applications/console- Interface d'authentification : AccessManager-base/web-src/services/config/auth/default ou AccessManager-base/web-src/services/config/auth/default_langue (où langue est un indicateur d'environnement linguistique tel que ja).
Pour plus d'informations, reportez-vous au Guide du développeur de Sun Java System Access Manager 7.1 (http://docs.sun.com/doc/819-4675).
- Assurez-vous que Directory Server est en cours d'exécution.
- Démarrez les instances suivantes d'Application Server :
Dans les commandes et étapes suivantes, les conventions suivantes sont utilisées :
- où nomAgentNud est au format nomHôte_nomDomaine, mais est simplement nomHôte par défaut
- La valeur par défaut de nomDomaine est domain1
- La valeur par défaut de nomInstance est server1
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.
- Démarrez le serveur d'administration du domaine.
AppServer8-base/bin/asadmin start-domain --user ID_admin
nomDomaine- 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 --startinstances=false --user ID_admin nomAgentNud
- Démarrez si nécessaire l'instance de serveur dans laquelle Access Manager est déployé (nomInstance).
AppServer8-base/bin/asadmin start-instance --user ID_admin nomInstance
- Annulez le déploiement d'Access Manager, reconfigurez-le, puis redéployez-le dans l'instance d'Application Server.
- Si le conteneur Web s'exécute en mode SSL, vérifiez que les certificats SSL du conteneur n'ont pas expiré et sont toujours en cours de validité.
- Créez un fichier d'entrée amconfig à partir du fichier d'entrée modèle amsamplesilent :
cp amsamplesilent fichier-config
Dans les étapes suivantes, on considère que fichier-config se trouve dans le même répertoire que amsamplesilent.
- Définissez les paramètres de configuration dans fichier-config.
Ils doivent tous être définis correctement. Certaines valeurs peuvent être migrées du fichier AMConfig.properties et d'autres sont plus spécifiques à la procédure de mise à niveau, comme indiqué dans le tableau ci-dessous.
Tableau 14-16 Paramètres de configuration d'Access Manager : amconfig
Paramètre
Valeur
Paramètres de mise à niveau
DEPLOY_LEVEL
Définissez la valeur 26 pour annuler le déploiement ou
Définissez la valeur 1 pour reconfigurer et déployerDIRECTORY_MODE
Définissez la valeur 5
AM_REALM1
Définissez la valeur disabled si le mode hérité est activé.
Définissez la valeur enabled si le mode domaine est activé.
Valeur par défaut : enabledJAVA_HOME
Définissez cette variable sur le répertoire du JDK version 5 : /usr/java/jdk1.5.0_04/
WEB_CONTAINER
Définissez la valeur AS8 pour Application Server 8.x
et remplissez uniquement la section correspondante dans fichier-config.AS81_INSTANCE
(si vous utilisez une version d'Application Server 8.x mise à niveau à partir d'Application Server 7.x comme conteneur Web)Définissez cette variable sur le nomInstance d'Application Server 7.x, qui est par défaut server1.
AS81_INSTANCE_DIR
(si vous utilisez Application Server 8.x comme conteneur Web)Définissez la variable sur le répertoire de domaine d'Application Server 8.x pour l'instance, qui est par défaut
AppServer8Config-base/domains/domain1
AS81_DOCS_DIR
(si vous utilisez Application Server 8.x comme conteneur Web)Définissez cette variable sur le répertoire docroot d'Application Server 8.x pour l'instance, qui est par défaut
AppServer8Config-base/domains/domain1/docroot
Migré du fichier AMConfig.properties
SERVER_PROTOCOL
com.iplanet.am.server.protocol
SERVER_PORT
com.iplanet.am.server.port
SERVER_HOST
com.iplanet.am.server.host
DS_HOST
com.iplanet.am.directory.host
DS_PORT
com.iplanet.am.directory.port
ROOT_SUFFIX2
com.iplanet.am.defaultOrg
CONSOLE_DEPLOY_URI
com.iplanet.am.console.deploymentDescriptor
SERVER_DEPLOY_URI
com.iplanet.am.services.deploymentDescriptor
PASSWORD_DEPLOY_URI
com.sun.identity.password.deploymentDescriptor
AM_ENC_PWD2
am.encryption.pwd3
1Pour plus d'informations sur les modes domaine et hérité, reportez-vous à la section Problèmes de compatibilité.
2La valeur de ce paramètre doit être la même que dans la version précédente d'Access Manager.
3Lorsque Access Manager et le kit SDK d'Access Manager sont tous les deux déployés, la valeur de cette propriété doit être la même pour l'instance d'Access Manager et l'instance de SDK associée.
Pour les autres paramètres, reprenez les mêmes valeurs que celles utilisées dans la configuration de la version 2 que vous mettez à niveau, sauf si vous changez de conteneur Web ou de mots de passe.
- Exécutez amconfig pour annuler le déploiement d'Access Manager.
Paramétrez la valeur de DEPLOY_LEVEL dans fichier-config sur 26.
cd /AccessManager-base/bin
./amconfig -s AccessManager-base/bin/fichier-config- Vérifiez que le conteneur d'agent commun est en cours d'exécution.
netstat -an | grep 11163
Si ce n'est pas le cas, démarrez-le.
/usr/sbin/cacaoadm start
- Exécutez amconfig pour reconfigurer Access Manager et le déployer dans le conteneur Web.
Paramétrez la valeur de DEPLOY_LEVEL dans fichier-config sur 1.
cd /AccessManager-base/bin
./amconfig -s AccessManager-base/bin/fichier-config- Vérifiez que les informations classpath-suffix et server-classpath d'Access Manager ont été migrées vers le fichier domain.xml d'Application Server pour la version 5.
- Copiez les informations classpath-suffix et server-classpath d'Access Manager dans le fichier server.xml de l'instance Application Server pour la version 2 dans laquelle Access Manager a été initialement déployé :
AppServer7Config-base/domains/nomDomaine/nomInstance/config/server.xml
- Vérifiez que les entrées classpath-suffix et server-classpath ont été ajoutées à la fin du fichier domain.xml de l'instance Application Server mise à niveau dans laquelle Access Manager est déployé :
AppServer8Config-base/nodeagents/nomAgentNud/nomInstance/
config/domain.xmlLes informations classpath doivent être ajoutées au bloc nomInstance-config du fichier domain.xml d'Application Server pour la version 5. Ce bloc commence par la ligne suivante :
<config dynamic-reconfiguration-enabled="true" name="nomInstance-config">
- Mettez à jour la structure et le schéma d'annuaire.
Access Manager pour la version 5 coexiste avec la structure d'annuaire de la version 4, mais cette structure doit être modifiée pour prendre en charge les fonctionnalités de la version 5. Mettez à jour la structure et le schéma d'annuaire d'Access Manager vers la version 5 en exécutant le script amupgrade qui se trouve dans le répertoire suivant :
- Sous Solaris :
AccessManager-base/upgrade/scripts- Sous Linux :
AccessManager_base/identity/upgrade/scripts- Récupérez les valeurs des paramètres suivants requis par le script amupgrade :
Tableau 14-17 Paramètres de configuration d'Access Manager : amupgrade
Paramètre
Valeur
Hôte de Directory Server
Définissez le nom complet : nom_hôte.domaine
Port de Directory Server
Indiquez un numéro de port non SSL1
Valeur par défaut : 389DN du gestionnaire d'annuaires
Par défaut : cn=Directory Manager
Mot de passe du gestionnaire d'annuaires
DN de l'administrateur de niveau supérieur
Par défaut : uid=amadmin,ou=People,default_org_DN
Mot de passe de l'administrateur de niveau supérieur
Activer mode domaine
(ce paramètre n'est pas requis pour la mise à niveau à partir du mode domaine de la version 4)Y/N : Yes signifie que le mode domaine est activé et que les données de services sont migrées vers la nouvelle arborescence Domaine. No (valeur par défaut) signifie que les données des services restent en mode hérité.
1La procédure de mise à niveau ne s'effectuera pas correctement si vous indiquez un port SSL Directory Server tel que la valeur SSL par défaut 636.
- Exécutez le script amupgrade.
cd AccessManager-base/upgrade/scripts
./amupgradeSi la mise à niveau est réussie, le script affiche « Upgrade completed ».
- Vérifiez les informations d'extension du schéma d'annuaire dans le fichier journal de mise à niveau suivant :
Sous Solaris :
/var/sadm/install/logs/
Sun_Java_System_Access_Manager_upgrade_dit_log.mmddhhmmSous Linux :
/var/log/Sun_Java_System_Access_Manager_upgrade_dit_log.mmddhhmm- Arrêtez le serveur d'administration du domaine, l'agent du nud et l'instance de serveur.
Il s'agit des instances démarrées à l'Step 7.
AppServer8-base/bin/asadmin stop-domain --user ID_admin
nomDomaineAppServer8-base/bin/asadmin stop-node-agent --user ID_admin
nomAgentNud- Redémarrez le serveur d'administration du domaine, l'agent du nud et l'instance de serveur.
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
nomDomaineAppServer8-base/bin/asadmin start-node-agent --port numéroPortDAS --startinstances=false --user ID_admin --password mot_de_passe nomAgentNoeud
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
Vérification de la mise à niveau d'Access Manager
Une fois la mise à niveau terminée, vérifiez qu'elle a été correctement effectuée, comme indiqué dans la section Vérification de la mise à niveau d'Access Manager.
Tâches à exécuter après la mise à niveau
Si vous utilisez le service SAML (Security Assertion Markup Language), vous devez ajouter et activer le module d'authentification SAML à l'aide de la console Access Manager. Pour plus d'informations sur la création d'une instance de module d'authentification SAML, reportez-vous au Guide d'administration de Sun Java System Access Manager 7.1 (http://docs.sun.com/doc/819-4670).
Annulation de la mise à niveau
Aucun script n'est fourni pour la restauration d'Access Manager à son état antérieur à la mise à niveau. Ce processus doit être réalisé manuellement à l'aide des données d'Access Manager sauvegardées au cours des tâches antérieures à la mise à niveau (voir la section Sauvegarde des fichiers de débogage et journaux d'Access Manager pour la version 4). L'annulation est trop difficile pour être pratique.
Mise à niveau de plusieurs instances
Dans certaines architectures, Access Manager est déployé sur plusieurs systèmes afin de permettre l'évolutivité et une haute disponibilité.
Il est généralement souhaitable de mettre à niveau les instances d'Access Manager les unes après les autres afin de ne pas interrompre le service. La procédure de mise à niveau progressive d'Access Manager de la version 2 vers la version 5 est soumise à la contrainte suivante : Access Manager pour la version 5 ne peut pas coexister avec la structure d'annuaire de la version 2. Cependant, si les instances de Directory Server sont répliquées, comme dans la Figure 14-2, vous pouvez effectuer une mise à niveau progressive en utilisant la procédure décrite dans la section Mise à niveau de plusieurs instances.
