Préparer et configurer des hôtes virtuels sur OracleAS 10g HTTP Server
OBJECTIF : Oracle Application Server 10g
Expliquer les étapes de base de la configuration d'hôtes virtuels avec Oracle
Application Server 10g, en particulier pour Oracle HTTP Server, en renvoyant
aux sections de la documentation Oracle qui décrivent les étapes nécessaires
pour les autres composants.
Ce document a été rédigé à l'origine pour la version 9.0.4, et sa pertinence a été vérifiée
pour les versions actuelles. Comme l'hébergement virtuel d'Oracle HTTP Server n'a
pas changé d'une version à l'autre, il reste d'actualité. Toutefois, les versions récentes
comportent davantage de composants et de dépendances à prendre en compte. Cette note explique comment
configurer et tester un hôte virtuel dans Oracle HTTP Server, mais son utilisation
dans l'ensemble d'Oracle Application Server dépend de votre implémentation. Il est
toujours recommandé de consulter la documentation Oracle pour toutes les étapes. Cette
note vous oriente vers la documentation Oracle à suivre.
Voir aussi :
Note 314381.1 How to Setup Oracle HTTP Server as a Virtual Host Reverse Proxy
PORTÉE : documentation d'Oracle HTTP Server ou d'Oracle Web Cache
Cet article n'a pas pour but de fournir toutes les étapes de configuration
d'un hôte virtuel. Consultez la documentation appropriée pour les étapes elles-mêmes, soit
la documentation d'Oracle HTTP Server, soit celle d'Oracle Web Cache, selon le composant qui
assure l'hébergement virtuel. Ce document présente les étapes
qui permettent à tous les composants OracleAS de fonctionner ensemble avec un hébergement virtuel.
Notez que, dans une configuration d'hébergement virtuel, chaque situation peut être différente. Aucun
document succinct ne peut couvrir de façon exhaustive chaque scénario avec des instructions
précises, étape par étape.
Configurer des hôtes virtuels sur Oracle Application Server 10g
Au départ, la configuration d'hôtes virtuels est une tâche très simple. Comme elle peut toucher
de nombreux éléments, c'est en réalité une question complexe : il y a une série
d'étapes et de dépendances à régler chaque fois que vous changez le protocole, le nom d'hôte ou
le port utilisé dans l'URL. Un hôte virtuel peut changer le nom d'hôte ou le port.
La configuration d'un hôte virtuel dans Oracle Application Server comporte au
moins cinq grandes étapes ou considérations :
1. Ajouter un VirtualHost pour l'Infrastructure (facultatif)
2. Ajouter un VirtualHost pour le Middle Tier (le cas le plus courant)
3. Les services Single Sign-On (SSO) de l'Infrastructure doivent être
reconfigurés. Cela comprend OID et OIDDAS, mais surtout si
l'Infrastructure a introduit un VirtualHost dans sa propre installation. Cela
comprend toute configuration SSL, qui utilise un VirtualHost.
4. Les services SSO du Middle Tier doivent être reconfigurés. On parle
généralement d'application partenaire (Partner Application).
5. La configuration SSO de Portal doit être reconfigurée. Il s'agit
d'une application partenaire, mais ses étapes diffèrent de celles d'une application générique.
Il faut aussi procéder installation par installation : autrement dit, l'Infrastructure
doit fonctionner d'abord, puis le Mid-Tier. Faites d'abord fonctionner l'Infrastructure
(ou le home Identity Management distinct), puis les éventuels Mid-Tiers.
Cela dépend aussi de l'emplacement de l'hôte virtuel : sur le Mid-Tier, sur l'Infrastructure
ou sur les deux. Vous n'avez pas toujours besoin d'un VirtualHost sur l'Infrastructure. Mais si SSL
est mis en œuvre sur Oracle HTTP Server, un hôte virtuel l'est aussi.
Au départ, on ne souhaite généralement des hôtes virtuels que sur les Mid-Tiers, où il
peut y avoir plusieurs noms pour accéder à un site. Sur l'Infrastructure, un seul nom sera
probablement utilisé : vous pouvez donc simplement remplacer la valeur du paramètre Servername du fichier httpd.conf
par le nouveau nom, puis réenregistrer le HTTP Server auprès de SSO avec ce
nom. Si vous utilisez SSL, il s'agit d'un hôte virtuel distinct dans le fichier ssl.conf, qui
doit être traité séparément de la configuration globale du httpd.conf.
Remarque :
Vous n'avez rien à changer sur l'Infrastructure, sauf si vous mettez en œuvre SSL
avec SSO ou si vous souhaitez changer la valeur ServerName du serveur SSO. L'ampleur
du changement dépend de vos objectifs globaux.
Pour commencer : configurer les hôtes virtuels d'Oracle HTTP Server
La toute première étape, sur toute installation, consiste à vérifier que l'hôte virtuel fonctionne avec
la configuration souhaitée. Il peut être configuré de plusieurs façons, selon
les fonctionnalités voulues. Voici un test d'hôte virtuel qui utilise l'hébergement virtuel par port
dans Oracle HTTP Server. L'hébergement virtuel par port est la méthode la plus simple si
un autre serveur HTTP se trouve devant Oracle HTTP Server (comme Oracle Web Cache) :
---in httpd.conf---
Listen 8000
Listen 8001
NameVirtualHost *:8000
<VirtualHost *:8000>
# If a different name is desired:
ServerName yourname0.com
# If the request is initially handled by another http server (like Web Cache):
Port 80
# Just to proove the virtualhost config is found:
DocumentRoot "/space/home/oracle/orahome/Apache/Apache/htdocs/vh-yourname8000"
# Insert any vh-specific config here
</VirtualHost>
NameVirtualHost *:8001
<VirtualHost *:8001>
# If a different name is desired:
ServerName yourname1.com
# If the request is initially handled by another http server (like Web Cache):
Port 80
# Just to proove the virtualhost config is found:
DocumentRoot "/space/home/oracle/orahome/Apache/Apache/htdocs/vh-yourname8001"
# Insert any vh-specific config here
</VirtualHost>
---end httpd.conf---
Remarque :
Dans une configuration d'hébergement virtuel, chaque situation peut être différente. Aucun document succinct
ne peut couvrir de façon exhaustive chaque scénario avec des instructions précises, étape par étape.
Avec l'exemple ci-dessus, en supposant qu'il y a un fichier html *différent* dans les
répertoires vh-yourname8000 et vh-yourname8001, les adresses suivantes devraient fonctionner
et afficher des pages différentes :
http://yourname0:8000/
http://yourname1:8001/
Si vous passez par un équipement frontal, comme Oracle Web Cache, configuré
par défaut dans Application Server, vous devriez pouvoir utiliser le
port Listen d'Oracle Web Cache. Dans l'exemple ci-dessus, il s'agit du port 80 :
http://yourname/ --> forwards to --> http://yourname:8001/
http://yourname/ --> forwards to --> http://yourname:8001/
La première étape consiste à vérifier que les URL de base de l'Infrastructure (ou du home IM)
fonctionnent correctement. Assurez-vous que cette configuration fonctionne comme prévu... sur
l'Infrastructure, sur le Mid-Tier et/ou lorsque SSL est activé. Si cela ne fonctionne pas
comme prévu, les autres dépendances seront plus difficiles à configurer.
^^^major checkpoint 1^^^Dépendances d'un VirtualHost sur l'Infrastructure (serveur SSO)
L'étape suivante consiste à vérifier que la configuration SSO fonctionne correctement. Voici
quelques informations sur la configuration Single Sign-On qu'il sera important
d'examiner :
ORASSO Schema (WWSEC_ENABLER_CONFIG_INFO$)
virtualname:port
http://virtualname:port/pls/orasso/orasso.wwsso_app_admin.ls_login
The SSO Server (orasso)
http://virtualname:port/pls/orasso/orasso.wwsso_home.process_signon
http://virtualname:port/pls/orasso/orasso.wwsso_app_admin.ls_login
http://virtualname:port/pls/orasso/orasso.home
http://virtualname:port/pls/orasso/orasso.wwsec_app_priv.logout
Référence :
Note:244112.1 Capture Single Sign-On orasso Schema Tables
Il faut éliminer toute occurrence d'un ancien nom, ou du nom de la machine,
et la remplacer par le nom virtuel et le port. Pour simplifier, supposons
que vous ne voulez qu'un seul hôte virtuel sur l'Infrastructure (ou le home IM).
Aucune configuration d'hôte virtuel n'est alors nécessaire dans le httpd.conf. Il vous
suffit de changer le paramètre ServerName, de réenregistrer le serveur HTTP auprès de SSO,
et de ne pas utiliser l'option virtualhost comme paramètre d'ossoreg.jar.
Remarque 1 :
Vous n'avez rien à changer sur l'Infrastructure, sauf si vous mettez en œuvre SSL
avec SSO ou si vous souhaitez un ServerName différent pour le serveur SSO.
Remarque 2 :
Si vous utilisez SSL, le recours au ssl.conf implique l'utilisation d'un hôte virtuel pour la
configuration SSL. Consultez la documentation indiquée plus bas pour un Mid-Tier si
des VirtualHosts *sont* souhaités sur l'Infrastructure. Suivez ensuite les étapes 6 à 10 pour
reconfigurer le serveur SSO. Notez que vous pouvez configurer UN seul hôte virtuel
et donner la même valeur au Servername global.
Nous verrons d'abord la méthode la plus simple pour configurer un hôte virtuel non SSL
sur l'Infrastructure, afin de distinguer les étapes SSO des autres étapes :
ACTIONS
-------
1. Dans le httpd.conf, en le modifiant avec Application Server Control :
remplacez ceci :
ServerName machinename.domain.com
par ceci :
ServerName Remarque :
On suppose ici que "virtualname" se résout en l'adresse IP de cette machine.
Ce n'est toutefois pas important pour la requête initiale, car le serveur HTTP
répond lorsque l'adresse IP est demandée. Le paramètre Servername
intervient lors de la définition des en-têtes de réponse appropriés, avec
le paramètre Port.
2. Vérifiez qu'aucune configuration "VirtualHost" n'a été ajoutée dans le httpd.conf.
3. C'est le moment de changer les paramètres Listen et Port pour le ou les ports souhaités.
4. Redémarrez le HTTP_Server.
5. Testez l'accès :
http://virtualname:port/6. Configurez SSO avec les nouveaux paramètres d'URL :
$ORACLE_HOME/sso/bin/ssocfg.sh http virtualname 7777Cette opération est *toujours* nécessaire lorsque vous changez le protocole, l'hôte ou le port)
7. Vérifiez qu'OID est correctement configuré :
Ouvrez OID Directory Manager et procédez comme suit :
Connectez-vous avec le compte orcladmin.
Développez l'arborescence :
Entry Management
cn=OracleContext
cn=Products
cn=DAS
Sélectionnez la page cn=OperationURLs ; ne développez pas l'arborescence, cliquez simplement sur
la page cn=OperationURLs. Le volet de droite affiche un certain nombre de
champs ou d'attributs. Le dernier champ, orcldasurlbase,
doit pointer vers le HTTP Server de l'Infrastructure et son port. Modifiez cette
entrée pour refléter le nouveau nom et le nouveau port, p. ex. http://virtualname:port.
(il s'agit simplement de l'"url" souhaitée : n'incluez donc pas le port 80
ou 443).
8. Consultez cette note pour rafraîchir le cache d'OID :
Note:292380.1 How to Refresh Cache for OID Parameters
9. Réenregistrez le OHS de l'Infrastructure auprès de SSO...
- Positionnez $ORACLE_HOME et l'environnement sur les répertoires de l'Infrastructure.
- Vérifiez que vous utilisez le Java fourni avec l'installation,
avec la commande "which java".
Collez ceci dans un fichier texte brut, mettez le tout sur une seule ligne en adaptant
les valeurs à votre configuration, puis collez-le dans la ligne de commande :
$ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/sso/lib/ossoreg.jar
-oracle_home_path
-site_name \
-config_mod_osso TRUE \
-mod_osso_url http://virtualname:port
-u oracle \ # since oracle user starts ohs
Sometimes needed:
-ssoDBConnect :1521:asdb
-pass
L'objectif est de définir la bonne URL. Comme le VirtualHost *est* le Servername,
nous n'avons pas besoin de l'option -virtualhost, et cet enregistrement définira le
fichier osso.conf obscurci par défaut.
10. Redémarrez le serveur HTTP
Voilà, nous l'espérons, "10 étapes pour faire fonctionner l'Infrastructure avec un hôte virtuel"
Testez-le uniquement sur l'Infrastructure :
http://virtualname:port/pls/orasso/ --> log in and out as orcladmin
http://virtualname:port/oiddas/ --> log in and out as orcladmin
Ne continuez pas tant que cela ne fonctionne pas. Une fois que cela fonctionne, vous pouvez configurer
des VirtualHosts sur le Mid-Tier et faire fonctionner Portal avec eux. Si vous
souhaitez plusieurs hôtes virtuels, ou si vous configurez SSL, configurez
l'Infrastructure comme s'il s'agissait d'un Mid-Tier (selon les instructions ci-dessous),
puis suivez les étapes 6 à 10 ci-dessus. Notez que vous pouvez configurer UN seul hôte
virtuel, donner la même valeur au Servername (et au Port) global,
et tout devrait bien fonctionner. Ce sont là les seules dépendances. Si vous
utilisez plusieurs hôtes virtuels, ou si vous activez l'hôte virtuel SSL, il y
a davantage de dépendances.
^^^point de contrôle majeur 2^^^
Remarque : dans la version 10.1.2.x, la documentation a été grandement améliorée et inclut toutes les
étapes de configuration des dépendances après un changement de nom ou de port. Un bon point
de départ est la documentation Oracle suivante :
Oracle Application Server Administrator's Guide 10g Release 2 (10.1.2)
http://download.oracle.com/docs/cd/B14099_19/core.1012/b13995/toc.htm
"4 Managing Ports"
En général, un changement de port s'effectue un home Oracle à la fois...
Par défaut, home Infrastructure ou Identity Management :
"4.4.3 Changing the HTTP Server Port on an Identity Management Installation"
http://download.oracle.com/docs/cd/B14099_19/core.1012/b13995/ports.htm#i1039402
Configurer un VirtualHost ne signifie pas nécessairement changer le port, mais cela peut être le cas.
Les mêmes étapes sont requises lorsque vous changez le protocole, le nom ou le port d'accès
au serveur SSO.
Dépendances d'un VirtualHost sur le Middle Tier
L'étape suivante consiste à configurer les Mid-Tiers avec la ou les URL souhaitées.
p. ex. :
http://mid-vh:port/Utilisez la documentation suivante pour configurer des VirtualHosts dans
Oracle HTTP Server, sur le Mid-Tier ou sur l'Infrastructure :
Oracle HTTP Server Administrator's Guide 10g (9.0.4)
Managing Virtual Hosts
http://download.oracle.com/docs/cd/B10464_01/portal.904/b10356/cg_advnc.htm#1054433
Mais s'il s'agit d'un Mid-Tier, vous faites probablement passer l'hôte virtuel par Web Cache :
1 Introduction to OracleAS Web Cache
Virtual Hosting
http://download.oracle.com/docs/cd/B10464_01/caching.904/b10401/intro.htm#1020047
http://mid-vh:wc-port/ --> Should forward to the Mid OHS.Notez que, même si c'est Oracle Web Cache qui assure l'hébergement virtuel, la configuration
d'Oracle HTTP Server dans le fichier httpd.conf reste nécessaire, comme dans l'exemple ci-dessus.
Une fois que tout cela fonctionne, il faut reconfigurer SSO. Consultez cette documentation :
Oracle Application Server Single Sign-On Administrator's Guide 10g (9.0.4)
4 Configuring and Administering Partner Applications
Configuring mod_osso with Virtual Hosts
http://download.oracle.com/docs/cd/B10464_02/manage.904/b13791/part_apps.htm#sthref243
Et enfin (une grande partie de ces informations s'y trouve, si seul Portal vous concerne) :
Oracle Application Server Portal Configuration Guide 10g (9.0.4)
5.4 Configuring Virtual Hosts
http://download.oracle.com/docs/cd/B10464_01/portal.904/b10356/cg_advnc.htm#1054433
Pour la version 10.1.2, des étapes similaires sont documentées dans les guides respectifs
mentionnés. Une configuration courante dans ce domaine est toutefois décrite dans la
note Metalink suivante :
Note 378003.1 How to Configure Virtual Hosts on HTTP_Server for LBR Access or SSL Termination
Remarque :
Les instructions données ici sont volontairement moins détaillées, car il peut
exister de nombreuses configurations et topologies différentes. Dans une configuration d'hébergement virtuel, chaque
situation peut être différente. Aucun document succinct ne peut couvrir de façon exhaustive chaque
scénario avec des instructions précises, étape par étape. Le but n'est pas ici de
réécrire la documentation Oracle indiquée ci-dessus. Il faut la lire pour bien
comprendre, en tenant compte de votre topologie.
Une fois configurées les requêtes traitées par Oracle HTTP Server, chaque fois que l'adresse
d'accès au serveur change, d'autres composants d'Oracle Application Server doivent
être configurés pour cette nouvelle adresse. Pour Oracle Application Server 10g (10.1.2.0.2),
types d'installation Mid-Tier, il s'agit généralement d'un simple changement de port, et la
documentation suivante permet de reconfigurer les différents composants :
Oracle Application Server Administrator's Guide 10g Release 2 (10.1.2)
http://download.oracle.com/docs/cd/B14099_19/core.1012/b13995/toc.htm
4 Managing Ports
4.3.5.1 Changing the OracleAS Web Cache Listen Ports
Tâche 1 : permettre à OracleAS Web Cache de s'exécuter en tant que root pour les ports inférieurs à 1024 (UNIX uniquement)
Tâche 2 : changer le port d'écoute d'OracleAS Web Cache
Tâche 3 : changer le port du site logique d'OracleAS Web Cache
Tâche 4 : mettre à jour la directive Port d'Oracle HTTP Server
Tâche 5 : mettre à jour Application Server Control Console
Tâche 6 : mettre à jour mod_osso
Tâche 7 : mettre à jour la configuration d'OracleAS Portal
Tâche 8 : mettre à jour les fournisseurs Web
Tâche 9 : mettre à jour OracleAS Wireless
Tâche 10 : mettre à jour OracleBI Discoverer
Tâche 11 : mettre à jour OracleAS Reports Services
Tâche 12 : redémarrer l'instance Middle Tier
Comme de nombreux composants sont concernés par un changement d'adresse (protocole,
nom d'hôte ou port), les instructions pour administrer ces changements peuvent se trouver dans
plusieurs guides de configuration. Les concepts de base devraient être les mêmes, mais
certaines étapes peuvent être propres à chaque composant. Ce qui suit se trouve
dans le guide de configuration de Portal :
Oracle Application Server Portal Configuration Guide 10g Release 2 (10.1.2)
5.4 Configuring Virtual Hosts
http://download.oracle.com/docs/cd/B14099_19/portal.1012/b14037/cg_advnc.htm#i1054431
--------------------------------------------------------------------------------
En résumé, la configuration d'hôtes virtuels avec Oracle Application Server
doit se faire étape par étape, et seulement après avoir soigneusement planifié les étapes
adaptées à la situation visée. Les hôtes virtuels peuvent être configurés sur Oracle
Web Cache et/ou sur Oracle HTTP Server. Une fois que l'hôte virtuel fonctionne correctement,
le serveur SSO et Oracle Portal doivent être reconfigurés pour tenir compte du changement d'URL.
--------------------------------------------------------------------------------
ANNEXE : Oracle HTTP Server, serveurs basés sur Apache
Dans le httpd.conf ou le ssl.conf, les paramètres Servername et Port servent tous deux
aux en-têtes de "réponse". Autrement dit, ils n'ont rien à voir avec la façon dont
Oracle HTTP Server écoute les requêtes. Les serveurs basés sur Apache écoutent sur l'adresse IP
d'installation et sur le port défini par le paramètre Listen. C'est au DNS de
résoudre correctement le nom en adresse IP. Tout fonctionne bien : la requête est traitée et
reçoit une réponse. Si Servername et Port sont mal définis, le mauvais
en-tête Host: est envoyé au navigateur. Cela ne change rien pour l'utilisateur,
ni pour Oracle HTTP Server, qui fait simplement ce qu'on lui
demande. Les en-têtes entrent en jeu parce qu'une application peut utiliser l'en-tête
(comme un cookie) et s'y référer pour les requêtes suivantes. Autrement dit,
l'application dit au navigateur : "envoie simplement une autre requête à l'emplacement
précédent". Le navigateur récupère l'en-tête Host: (sous la forme servername:port)
et, avec quelques autres, construit l'URL à transmettre. Dans le cas de SSO, celui-ci récupère
les en-têtes nécessaires, les stocke sous forme d'une seule chaîne et redirige la requête
vers l'URL précédente. L'"application" est ici SSO. Il arrive aussi que Portal
récupère ces informations, et Portal devient alors l'"application". Cela dépend
de l'endroit où se fait le traitement et de sa nature. Si quelque chose échoue à la connexion, c'est
"sso" qui joue le rôle d'application. En plus d'une configuration correcte, l'enregistrement
SSO est tout aussi important.
C'est là qu'apparaît une dépendance entre plusieurs composants. Un composant applicatif
peut exiger certains réglages pour fonctionner de façon optimale.
Portal (en tant que composant applicatif) utilise RDBMS, OHS, WC, SSO, OC4J_Portal
SSO (en tant que composant applicatif) utilise OID, OHS, WC, OC4J_SECURITY
WC est autonome (utilisé par un composant pour permettre l'accès à l'application)
OHS est autonome (utilisé par un composant pour permettre l'accès à l'application)
Si vous définissez les paramètres Servername et Port dans le httpd.conf ou le ssl.conf,
ce sera pour une seule raison : lorsque le nom et le port frontaux de l'URL sont
différents de l'adresse IP sur laquelle Oracle HTTP Server est installé, ou
différents du paramètre Listen. (Sur la même machine, le Servername
sera le même ; seul le Port sera différent.) L'utilisation ou non de SSL ou d'hôtes
virtuels est aussi à prendre en compte. C'est une notion à 'saisir'
et à appliquer dans chaque cas.
Diagnostiquer un problème parmi ces dépendances peut être difficile. Mais il est
utile de procéder une étape à la fois, en vérifiant que chaque composant autonome fonctionne
par lui-même. Par exemple, une page statique par défaut doit être accessible via Oracle
HTTP Server. Si vous utilisez Oracle Web Cache, cette même page doit être accessible via
le port Listen d'Oracle Web Cache. Vérifiez ensuite que SSO et/ou Portal sont configurés correctement
pour l'URL souhaitée (protocol://servername:port), en gardant à l'esprit qu'une certaine
configuration dans Oracle Web Cache et/ou Oracle HTTP Server peut être nécessaire pour un
fonctionnement optimal.