Configuration du serveur Web

La configuration de plug-in implique la configuration du serveur Web pour utiliser le module de plug-in binaire fourni par WebSphere® Application Server . La configuration du plug-in comprend également la mise à jour du fichier de configuration XML du plug-in pour refléter la configuration actuelle du serveur d'applications. Le module binaire utilise le fichier XML pour router les demandes du client Web.

Après avoir installé un serveur Web pris en charge, vous devez installer un module de plug-in binaire pour le serveur Web en installant des plug-in du serveur Web. Le module de plug-in permet au serveur Web de communiquer avec le serveur d'applications. Web Server Plug-ins Configuration Tool permet de configurer le serveur Web et de créer une définition de serveur Web dans la configuration du serveur d'applications. Web Server Plug-ins Configuration Tool utilise les fichiers suivants pour configurer un plug-in pour le serveur Web que vous sélectionnez :

Le fichier de configuration du serveur Web sur la machine du serveur Web, tel que le fichier httpd.conf pour IBM® HTTP Server.
Le fichier de plug-in du serveur Web binaire sur la machine du serveur Web.
Le fichier de configuration de plug-in, tel que plugin-cfg.xml, situé sur le serveur d'applications et qu'il faut propager (copier) au serveur Web.
Le fichier de configuration du plug-in (temporaire) par défaut, plugin-cfg.xml, sur la machine du serveur Web.
Le script configureweb_server_name que vous copiez depuis la machine du serveur Web vers la machine du serveur d'applications.

Le processus de configuration de plug-ins utilise les fichiers suivants pour configurer un plug-in pour le serveur Web que vous sélectionnez :

Le fichier de configuration du serveur Web installé sur le serveur Web, tel que httpd.conf pour IBM HTTP Server.
Le fichier de plug-in du serveur Web binaire sur la machine du serveur Web.
Le fichier de configuration de plug-in, tel que plugin-cfg.xml, situé sur le serveur d'applications et qu'il faut propager (copier) au serveur Web.
Le script de configuration pour configurer la définition du serveur d'applications dans un scénario HTTP distant.

Voir ci-après les descriptions de chaque fichier.

Fichier de configuration du serveur Web

Le fichier de configuration du serveur Web est installé avec le serveur Web.

[AIX Solaris HP-UX Linux Windows] Web Server Plug-ins Configuration Tool doit reconfigurer le fichier de configuration d'un serveur Web prise en charge.

Cette configuration consiste à ajouter des instructions identifiant l'emplacement de deux fichiers :

Fichier de plug-in du serveur Web binaire
Fichier de configuration de plug-in, plugin-cfg.xml

Fichier de plug-in du serveur Web binaire

Le fichier mod_was_ap22_http.dll pour IBM HTTP Server sur la plateforme Windows est un exemple de module de plug-in binaire.

[IBM i] Un autre exemple de module de plug-in binaire est le programme de service QSVTAP20 sur la plateforme IBM i .

Le fichier de plug-in binaire ne change pas. Cela étant, le fichier de configuration pour le plug-in binaire est un fichier XML. Le serveur d'applications modifie le fichier de configuration lorsque certaines modifications surviennent dans la configuration de WebSphere Application Server.

Le module binaire lit le fichier XML afin d'ajuster les paramètres et d'acheminer les requêtes au serveur d'applications.

Fichier de configuration de plug-in, plugin-cfg.xml

Le fichier de configuration de plug-in est un fichier XML que vous pouvez paramétrer dans la console d'administration. Le fichier contient toutes les applications installées dans la définition du serveur Web. Le module binaire lit le fichier XML afin d'ajuster les paramètres et d'acheminer les requêtes au serveur d'applications.

[AIX Solaris HP-UX Linux Windows] Le serveur d'applications autonome régénère le fichier plugin-cfg.xml dans le répertoire racine_profil/config/cells/nom_cellule/nodes/nom_serveur_Web_node/servers/nom_serveur_Web . La régénération se fait à chaque fois qu'un changement dans la configuration du serveur d'applications affecte des applications déployées.

[IBM i] Lorsque vous procédez à des modifications dans la configuration du serveur d'applications qui affectent les applications déployées, régénérez le fichier XML de configuration du plug-in.

Après la régénération, propagez (copiez) le fichier vers la machine du serveur Web. Le plug-in binaire peut ensuite accéder à la copie la plus récente de son fichier de configuration.

[AIX Solaris HP-UX Linux Windows] Le service de configuration de plug-in de serveur Web régénère automatiquement le fichier plugin-cfg.xml après certains événements qui modifient la configuration. Ce service propage automatiquement le fichier plugin-cfg.xml à une machine IBM HTTP Server lorsque le fichier est régénéré. Vous devez copier manuellement le fichier sur d'autres serveurs Web.

[IBM i] Sur les systèmes IBM i , le plug-in n'est pas généré automatiquement. Vous devez le régénérer le fichier et le propager manuellement.

Le fichier de configuration de plug-in par défaut, tel que plugin-cfg.xml

Web Server Plug-ins Configuration Tool crée le fichier temporaire plugin-cfg.xml dans le répertoire plugins_root/config/web_server_name. L'outil crée le fichier pour chaque scénario d'installation distante.

Le fichier par défaut est une marque de réservation que vous devez remplacer par le fichier plugin-cfg.xml depuis la définition de serveur Web sur le serveur d'applications. Le fichier par défaut est une réplique du fichier que le serveur d'applications crée pour un serveur d'applications autonome par défaut.

Exécutez le script configureweb_server_name à partir du répertoire racine_serveur_app/bin de la machine du serveur d'applications pour une installation distante ou directement à partir du répertoire racine_plug-in/bin pour une installation locale. Le script crée la définition de serveur Web dans les fichiers de configuration du profil par défaut. Pour configurer un profil différent de celui par défaut, éditez le script configureweb_server_name . Utilisez le paramètre -profileName pour identifier un profil autre que le profil par défaut.

Une fois que la définition de serveur Web est créée, le service de configuration de plug-in du serveur Web dans le serveur d'applications crée le premier fichier plugin-cfg.xml dans la définition de serveur Web sur la machine du serveur d'applications. Si vous installez une application, créez un hôte virtuel ou exécutez une opération qui change la configuration, vous devez propager le fichier mis à jour plugin-cfg.xml depuis la machine du serveur d'applications vers la machine du serveur Web pour remplacer le fichier par défaut.

Configuration du script `web_server_name` pour la définition de serveur Web

L'outil de configuration des plug-ins de serveur Web crée le script configureweb_server_name sur la machine du serveur Web dans le répertoire plugins_root/bin. Si une machine dans un scénario à distance s'exécute sous un système d'exploitation tel que AIX® ou Linux® et que l'autre machine s'exécute sous Windows, utilisez le script créé dans le répertoire plugins_root/bin/crossPlatformScripts . Ce script n'est créé que dans le cas d'installations distantes.

Copiez le script de la machine du serveur Web vers le répertoire app_server_root/bin sur la machine d'un serveur d'applications distant. Il n'est donc pas nécessaire de copier le script sur une installation locale. Exécutez le script pour créer une définition de serveur Web dans la configuration du serveur d'applications.

Lorsque vous utilisez IBM HTTP Server, configurez aussi le système IBM HTTP Administration Server. Ce système fonctionne à l'aide de la console d'administration pour gérer les définitions de serveur Web. En outre, utilisez la console d'administration pour mettre à jour la définition de serveur Web avec les options de gestion de serveur Web distant. Cliquez sur Serveurs > Types de serveurs > Serveurs Web > nom_serveur_Web pour consulter les options de configuration. Par exemple, pour changer les propriétés suivantes, cliquez sur Gestion de serveur Web distant :

Nom d'hôte
Port d'administration
ID utilisateur
Mot de passe

Important: Ouvrez toujours une nouvelle fenêtre de commande avant d'exécuter ce script. Cela permet d'éviter d'éventuels incidents.

En effet, un conflit peut survenir entre une variable d'environnement shell, la variable d'environnement WAS_USER_SCRIPT et le profil par défaut. Le script fonctionne toujours d'après le profil par défaut. Si la variable d'environnement WAS_USER_SCRIPT est définie, un conflit se produit, car le script tente d'utiliser le profil identifié par la variable.

Cette variable se définit facilement par erreur. Emettez n'importe quelle commande à partir du répertoire racine_profil/bin de n'importe quel profil et la variable sera définie pour ce profil.

Si votre système comporte plusieurs profils, il est probable que le profil par défaut et celui que la variable identifie sont différents. Dans ce cas, un conflit se produit et le script peut ne pas créer la définition de serveur Web dans le profil correct ou la définition de serveur Web.

Vous pouvez réinitialiser la variable de deux manières :

Fermez la fenêtre Commande où la variable a été définie et ouvrez-en une autre.
Modifiez les répertoires en fonction du répertoire racine_profil/bin du profil par défaut et lancez le script setupCmdLine.sh :
1. Ouvrez une fenêtre d'invite de commande.
2. Accédez au répertoire racine_serveur_app\bin .
3. Exécutez la commande setupCmdLine.bat.
1. Ouvrez une fenêtre de shell de commande.
2. Accédez au répertoire racine_serveur_app/bin .
3. Exécutez la commande . ./setupCmdLine.sh. Notez l'espace entre les points. Le format spécial de cette commande alimente la commande pour rendre le paramètre actif pour tous les processus démarrés à partir du shell de commande.

S'il existe déjà une définition de serveur Web pour un serveur d'applications autonome, l'exécution du script n'ajoute pas une nouvelle définition de serveur Web. Chaque serveur d'applications autonome ne peut avoir qu'une seule définition de serveur Web.

Vous ne pouvez pas utiliser la console d'administration d'un serveur d'applications autonome pour ajouter ou supprimer une définition de serveur Web. Cela étant, vous pouvez effectuer ces deux opérations à l'aide de l'interface de script d'administration :

Ajoutez une définition de serveur Web via la fonction wsadmin en utilisant le script web_server_name. Le script utilise un script Java™ Command Language (Jacl) nommé configureWebserverDefintion.jacl pour créer et configurer la définition de serveur Web.

Supprimez une définition de serveur Web en utilisant les commandes wsadmin. Le serveur Web est appelé webserver1 dans l'exemple suivant :

 set webserverName webserver1
 set webserverNodeSuffix _node
 set webserverNodeName   $webserverName$webserverNodeSuffix
 $AdminConfig remove [$AdminConfig getid /Node:$webserverNodeName/Server:$webserverName]
 $AdminConfig remove [$AdminConfig getid /Node:$webserverNodeName]
 $AdminConfig save

Script de configuration pour la définition de serveur Web

La configuration de votre serveur Web avec le script configureOs400WebserverDefinition ou à l'aide de l'interface graphique d'administration IBM i crée le script configureweb_server_name sur la machine du serveur Web dans le répertoire racine_plug-in/bin . Ce script n'est créé que dans le cas d'installations distantes.

Copiez le script de la machine du serveur Web dans le répertoire racine_serveur_app/bin de la partition IBM i . Exécutez le script pour créer une définition de serveur Web dans la configuration du serveur d'applications.

L'interface graphique d'administration IBM i comporte des plug-in qui permettent à la console d'administration de gérer des serveurs IBM HTTP . Utilisez la console d'administration pour mettre à jour la définition du serveur Web avec les options de gestion de serveur Web distant. Cliquez sur Serveurs > Types de serveurs > Serveurs Web > nom_serveur_Web pour consulter les options de configuration. Par exemple, pour changer les propriétés suivantes, cliquez sur Gestion de serveur Web distant :

Nom d'hôte
Port d'administration
ID utilisateur
Mot de passe

S'il existe déjà une définition de serveur Web pour un serveur d'applications autonome, l'exécution du script n'ajoute pas une nouvelle définition de serveur Web. Un serveur d'applications autonome ne peut avoir qu'une seule définition de serveur Web.

Ajoutez une définition de serveur Web via la fonction wsadmin en utilisant le script configureweb_server_name. Ce script utilise le script Jacl (Java Command Language) ci-après pour créer et configurer une définition de serveur Web : configureWebserverDefintion.jacl.

Supprimez une définition de serveur Web en utilisant les commandes wsadmin. Le serveur Web est appelé webserver1 dans l'exemple suivant :

set webserverName webserver1
set webserverNodeSuffix _node
set webserverNodeName 
$webserverName$webserverNodeSuffix
$AdminConfig remove 
  [$AdminConfig getid 
    /Node:$webserverNodeName/Server:$webserverName]
$AdminConfig remove 
  [$AdminConfig getid /Node:$webserverNodeName]
$AdminConfig save

Vous pouvez également utiliser les scripts configureOs400WebServerDefinition et removeOs400WebServerDefinition pour réaliser ces tâches.

Remplacement du fichier de configuration de plug-in par défaut par le fichier provenant de la définition de serveur Web (propagation)

Le fichier par défaut utilise des valeurs de paramètre fixes, valeurs susceptibles de ne pas correspondre à celles du fichier présent sur le serveur d'applications. Le fichier par défaut est uniquement une marque de réservation et

ne peut refléter les modifications survenues dans la configuration du serveur d'applications. Le fichier peut aussi ne pas refléter les valeurs non implicites qui peuvent être actives sur le serveur d'applications.

[AIX Solaris HP-UX Linux Windows] Le serveur d'applications doit avoir les valeurs suivantes dans le fichier plugin-cfg.xml réel. Dans ce cas, le fichier par défaut est capable de configurer correctement le module de plug-in binaire. Le module de plug-in peut communiquer alors avec le serveur Web et le serveur d'applications.

[AIX Solaris HP-UX Linux Windows] Supposons que le serveur d'applications ne possède pas les valeurs suivantes dans le fichier plugin-cfg.xml réel. Le fichier par défaut ne configure alors pas le module de plug-in binaire correctement. Le module de plug-in peut toujours communiquer avec le serveur Web. Avec un fichier de configuration inapproprié, il ne peut communiquer correctement avec le serveur d'applications.

Les valeurs suivantes sont des valeurs de paramètre fixes dans le fichier de configuration de plug-in temporaire.

Nom d'hôte virtuel
Valeur par défaut : default_host

Cet hôte virtuel est configuré pour servir DefaultApplication. Cette valeur est probablement la même que la valeur du fichier réel plugin-cfg.xml. Supposons néanmoins que vous créiez un autre hôte virtuel pour des applications de serveur et que vous y installiez l'application par défaut. Le fichier actif plugin-cfg.xml est alors régénéré et Le serveur Web ne peut pas accéder à DefaultApplication. (L'application inclut snoopservlet et hitcount servlet.)

Afin d'accéder aux applications sur le nouvel hôte virtuel, propagez le fichier réel plugin-cfg.xml. La propagation consiste à copier le fichier mis à jour de la machine du serveur d'applications vers la machine du serveur Web.
Port de transport HTTP
Valeur par défaut : 9080

9080 est la valeur par défaut du port de transport HTTP pour l'hôte virtuel default_host. Cette valeur est probablement la même que celle du fichier mis à jour, mais elle change pour chaque profil du serveur d'applications. La valeur du port de transport HTTP doit être unique pour chaque serveur d'applications.

Afin de communiquer via un port différent, propagez le fichier réel plugin-cfg.xml.
Port d'écoute du serveur Web
Valeur par défaut : 80

La valeur 80 est la valeur par défaut du port qui contrôle les communications avec le serveur Web. Toutefois, chaque profil de serveur d'applications doit avoir une valeur de port unique pour pouvoir communiquer avec un serveur Web. La valeur du port actif peut être 81 ou un autre nombre.

Afin de communiquer via un port différent, propagez le fichier réel plugin-cfg.xml.
Port de transfert HTTPS
Valeur par défaut : 9443

9443 est la valeur par défaut du port de transport HTTPS (sécurisé) pour l'hôte virtuel default_host. Cette valeur est probablement la même que celle du fichier mis à jour, mais elle change pour chaque profil du serveur d'applications. La valeur du port de transport HTTPS doit être unique pour chaque serveur d'applications.

Afin de communiquer via un port sécurisé différent, propagez le fichier réel plugin-cfg.xml.
Applications installées sur le serveur d'applications server1
Tous les servlets et applications par défaut sont inclus dans le fichier par défaut.

Pour servir une application que vous avez développée avec le serveur Web, propagez le vrai fichier plugin-cfg.xml.