Installation du plug-in de serveur Web pour les environnements distribués (cellules)

Procédure de configuration et de résolution des incidents pour la propagation automatique

Le service de configuration du plug-in de serveur Web propage automatiquement le fichier plugin-cfg.xml pour IBM HTTP Server uniquement. Pour activer la propagation automatique, effectuez une configuration unique :

1. Créez une entrée user=adminUser, password=adminPassword dans le fichier racine_IHS /conf/admin.passwd. Par exemple : c:\ws\ihs85\bin\htpasswd -cb c:\ws\ihs85\conf\admin.passwd adminUser adminPassword
2. Dans la console d'administration, cliquez sur Serveurs > Serveurs Web > webserver1 > Gestion du serveur Web distant. Définissez les valeurs suivantes : admin Port=8008, User Id=adminUser, Password=adminPassword.
3. Accordez des droits d'accès en lecture/écriture pour les fichiers httpd.conf et plugin-cfg.xml. Pour plus d'informations, consultez le fichier racine_IHS/logs/admin_error.log.

Pour que le fichier de configuration du plug-in puisse être propagé automatiquement, le serveur d'administration IBM HTTP doit être actif. Si vous gérez un serveur IBM HTTP Server à l'aide de la console d'administration WebSphere Application Server, l'erreur suivante peut s'afficher :

"Could not connect to IHS Administration server error"

Suivez la procédure décrite ci-dessous :

1. Vérifiez que le serveur d'administration IBM HTTP Server est en cours d'exécution.
2. Vérifiez que le nom d'hôte et le port du serveur Web définis dans la console d'administration WebSphere Application Server correspondent au nom d'hôte et au port du serveur d'administration IBM HTTP Server.
3. Assurez-vous que le pare-feu ne vous empêche pas d'avoir accès au serveur d'administration IBM HTTP Server à partir de la console d'administration WebSphere Application Server.
4. Vérifiez que le mot de passe et l'ID utilisateur indiqués dans la console d'administration WebSphere Application Server, gérée à distance, sont créés dans le fichier admin.passwd, à l'aide de la commande htpasswd.
5. Lors d'une tentative de connexion sécurisée, veillez à exporter le certificat personnel keydb du serveur d'administration IBM HTTP Server dans la base de données de clés de WebSphere Application Server en tant que certificat de signataire. Cette base de données de clés est spécifiée par la directive com.ibm.ssl.trustStore dans le fichier sas.client.props du profil dans lequel la console d'administration s'exécute. Cette remarque s'applique principalement aux certificats auto-signés.
6. Si vous rencontrez encore des erreurs, consultez le fichier admin_error.log d'IBM HTTP Server et les journaux de WebSphere Application Server (fichier trace.log) pour déterminer la cause de l'incident.

Remarques concernant les différentes plateformes pour l'exécution du script de configuration

La configuration d'un serveur Web distant peut être différente en fonction des systèmes d'exploitation et des plateformes :

• Une machine exécute Windows et l'autre machine exécute Linux ou UNIX.
• Une machine utilise un codage par défaut différent de celui utilisé par l'autre machine.

Une machine s'exécute sous Windows et l'autre sous Linux ou UNIX

Si une machine s'exécute sous Linux ou UNIX et que l'autre machine s'exécute sous Windows, utilisez le script créé dans le répertoire racine_plugins /bin/crossPlatformScripts.

Une machine utilise un codage par défaut différent de celui utilisé par l'autre machine

Le contenu du script configurenom_serveur_Web.bat ou du script configure nom_serveur_Web.sh peut être corrompu si le codage de fichier par défaut est différent sur les deux machines. Ce scénario peut se produire si une machine est configurée pour un environnement local DBCS (Double-Byte Character Set) et l'autre non.

Déterminez le codage de fichier pour chaque machine et suivez une des procédures décrites ci-dessous pour éviter le problème. Pour déterminer le codage des fichiers par défaut, lancez la commande appropriée :

• Systèmes Windows :

  CHCP

• Systèmes Linux et UNIX :

  locale

Utilisez le résultat de la commande sur chaque machine en tant que valeur des variables codage_machine_serveur_web et codage_machine_serveur_applications dans une des procédures suivantes.

Procédures pour la correction des différences de codage

Supposez que le serveur Web est exécuté sur une machine Linux et que Network Deployment est exécuté sur une machine Windows.

Serveur Web en cours d'exécution sur une machine Linux

Lancez la commande suivante sur le système Linux ou UNIX pour coder le fichier de script qui configure la définition du serveur Web avant d'envoyer le fichier par FTP à la machine Windows en mode binaire :

iconv -f codage_machine_serveur_Web \
      -t codage_machine_serveur_applications \
         configurenom_serveur_Web.bat

N'indiquez pas les caractères de continuation (\) Linux et UNIX si vous entrez la commande sur une seule ligne.

Important : Le nom du serveur Web (alias) est utilisé dans le nom du fichier script. Ce nom peut contenir des caractères DBCS (Double-Byte Character Set) si vous souhaitez configurer IBM HTTP Server pour la propagation automatique.

Supposez maintenant que le serveur Web s'exécute sur une machine Windows et que Network Deployment s'exécute sur une machine Linux ou UNIX.

Serveur Web en cours d'exécution sur une machine Windows

Lancez la commande suivante sur le système Linux ou UNIX pour coder le fichier de script qui configure la définition du serveur Web et envoyez ensuite le fichier par FTP en mode binaire :

iconv -f codage_machine_serveur_Web \
      -t codage_machine_serveur_applications \
         configurenom_serveur_Web.sh

N'indiquez pas les caractères de continuation (\) Linux et UNIX si vous entrez la commande sur une seule ligne.

Si le mappage de conversion n'est pas pris en charge par la commande iconv sur votre système, copiez le contenu du script de configuration du serveur Web dans un presse-papiers puis collez-le sur la machine dans laquelle le serveur d'applications est en cours d'exécution.