Professional Documents
Culture Documents
Sommaire
4.Publication...........................................................................................................................206
4.1 Publication Directe........................................................................................................207
4.2 Changement de racine du serveur..................................................................................207
4.3 Serveurs virtuels............................................................................................................208
4.4 Redirection.....................................................................................................................212
4.5 Répertoires Virtuels.......................................................................................................212
5.Protection du site................................................................................................................213
5.1 Modes d'authentification................................................................................................213
5.2 Provenance des requêtes ...............................................................................................214
5.3 Protection des sites publiés............................................................................................215
5.4 Protection d'une page par un mot de passe....................................................................218
Conclusion..............................................................................................................................221
Annexe PWS..........................................................................................................................222
Comparaison des offres « Windows NT WorkStation » et « Windows 98 »......................222
Composants et sous-composants.........................................................................................222
Annexe IIS..............................................................................................................................224
Composants et sous-composants (par défaut) de IIS...........................................................224
Annexe Apache : Administration graphique sous UNIX...................................................225
Linuxconf.............................................................................................................................225
Webmin ...............................................................................................................................226
Introduction
Ce chapitre est consacré à une présentation générale des serveurs Web, autant sur le plan de leurs
caractéristiques que de l'offre commerciale actuelle.
La troisième section permet d'orienter non seulement le choix des architectes techniques mais
encore celui des décideurs chargés de mettre en œuvre un Intranet au sein de leur entreprise, ou
de mettre en place des serveurs à vocation Internet.
La quatrième section, focalisée sur les serveurs Microsoft, a pour but de présenter l'offre
commerciale de la firme. Cette dernière partie sert de préambule aux deux chapitres suivants.
Avant d'atteindre les services de publication, l'internaute doit se connecter au serveur. En raison
des objectifs du Web, le serveur met en oeuvre par défaut le mode de connexion anonyme. Ce
mode permet de se connecter auprès d'un serveur sans authentification préalable. Pour cela, le
serveur crée un utilisateur "anonyme" reconnu par le système d'exploitation. Les internautes
utilisent à travers leur navigateur de manière transparente ce compte utilisateur pour se
connecter. Dans la barre d'état du navigateur peut s'afficher le mode de connexion.
Néanmoins, le serveur peut protéger l'accès de certaines parties du site plus privées ou plus
confidentielles, en exigeant de l'internaute une authentification traditionnelle : nom d'utilisateur
et mot de passe reconnus par la machine.
Le service Web est un service réseau qui utilise un protocole de communication pour
communiquer le serveur et ses clients (navigateurs) : le protocole HTTP (Hyper Text Transfert
Protocol). L'emploi de ce protocole repose sur celui des protocoles TCP/IP du réseau Internet.
Le schéma suivant rappelle les principes de communication entre un serveur et un de ses clients.
Client Serveur
requête
Serveur
Navigateur 1
Web
HTTP
3
2
réponse
L'internaute, depuis le navigateur, tape l'adresse URL d'un site Web dans la barre d'adresse.
C'est la validation de cette adresse qui envoie une requête HTTP, et donc par-là sollicite le
travail du serveur Web visé par l'adresse.
Si l'adresse ne comporte pas en final de nom de page, le serveur cherche dans son environnement
de publication la page d'accueil déclarée du site.
Une fois la page trouvée (page d'accueil ou autre), le serveur envoie une réponse HTTP incluant
la page Web désirée vers le cache du navigateur du client.
Une fois que la première page est téléchargée et visualisée sur le poste de l'internaute, le fait de
cliquer sur un lien dans cette page lance une deuxième requête.
Si ce lien comporte une adresse URL (http://… par exemple) ou s'il contient un chemin absolu
(débutant donc depuis la racine du serveur symbolisé par un "/"), alors il provoque le lancement
d'une requête HTTP qui ne peut être satisfaite que par le serveur visé.
Rappel : les notions de liens et de chemins absolus ou relatifs sont abordés dans le module
"HTML statique".
D'un autre côté, il est possible d'afficher des pages Web dans son navigateur sans la présence
d'un serveur. En effet, dans l'organisation des fichiers d'un PC, nous disposons de manière native
quelques pages web déposés lors de l'installation de tel ou tel logiciel. Pour les visualiser, il suffit
d'aller les chercher à l'aide du menu "Fichier/Ouvrir" du navigateur (ou double clic sur le fichier
dans l'explorateur Windows). De même, imaginons qu'un logiciel fournisse l'aide en ligne sous
forme d'un site Web. Le parcours de ce site s'effectue sans solliciter de serveur.
Pour obtenir un tel résultat, deux techniques sont possibles. La première consiste à utiliser dans
la définition des liens, au niveau de l'adresse, un chemin relatif pour atteindre la page cible. Ces
Si la sollicitation d'un serveur est obligatoire dans le cas d'adresses URL mentionnant l'adresse
d'un site, elle l'est tout autant dans le cas de scripts ou d'applications lancées depuis une page
Web. Le schéma ci-dessous présente le cas de la consultation d'une application de type "annuaire
électronique".
1
HTML
Client
Serveur 2 Web
Web
3
Pages 7
HTML 1 : Demande de formulaire
4 2 : Envoi du formulaire HTML
3 : Envoi des données saisies
4 : Activation de l'application
5 : Traitement des données
6 : Mise en forme de la réponse en
6 Application langage HTML
5
7 : Envoi des résultats au client
Pages HTML
dynamiques
Le lancement d'une application peut être provoqué par le chargement d'une page, un événement
lié au mouvement de la souris sur la page, l'action d'un bouton ou le clic d'un lien.
L'application sollicitée est gérée par le même serveur Web. Ces pages de script ou applications
sont hébergées et publiées via le même serveur, mais d'une manière différente (voir chapitre
"Applications Web" du module "HTML dynamique").
Le serveur, recevant cette requête, lance l'exécution de l'application (ou de la page de scripts
serveurs) appelée en lui passant les données (ou paramètres) envoyées par le client (voir schéma
ci-dessus). Dans ce cas, l'application ne s'exécute que si l'on sollicite le serveur. L'application
crée en réponse à la demande de l'utilisateur une page dynamique que le serveur renvoie
aussitôt.
Les pages de scripts qui s'exécutent côté serveur ont principalement pour extension *.asp (Active
Server Pages) ou *.php (Personal Home Page).
Les applications ont en général pour extension *.exe tout simplement, ou *.cgi, ou *.dll.
Remarque :
Il existe un autre cas où la présence d'un serveur Web est inutile. Il est rappelé qu'une page Web,
fichier à extension *.htm, peut comporter dans son code source un certain nombre de scripts
ayant pour but d'améliorer l'interactivité de ces pages avec l'internaute. Ces scripts, pour être
interprétés et exécutés, nécessitent le seul logiciel client, donc le navigateur.
En conclusion, suivant la nature des liens reliant les différentes pages d'un site, suivant la nature
du site, la présence d'un serveur est indispensable.
Cette analyse entraîne le classement des sites en deux catégories : les sites statiques et les sites
dynamiques ou applicatifs.
Les premiers ne comportent que des pages Web pures (balises HTML) dont l'extension des
fichiers est du type *.htm. Ces pages peuvent être agrémentées de quelques scripts exécutés côté
clients.
Les seconds sont des sites comprenant bien sûr les applications. Ils comprennent aussi des pages
Web de formulaires, des pages servant d'interfaces entre l'utilisateur et l'application. Ils
comprennent enfin des pages Web d'informations classiques, ne seraient-ce que pour présenter
les applications, leur but, leurs bases de données associées et la façon de les solliciter.
Netscape-Enterprise 3.99%
Zeus Web Application Server 2,42%
Les deux serveurs les plus représentatifs du marché sont le serveur Apache plutôt installé en
environnement UNIX et Microsoft IIS exclusivement installé en environnement Windows. Le
module « Serveurs » réserve justement une part importante à l’étude de ces deux principaux
serveurs.
Même s’il existe plus de trente types de serveurs sur les deux principaux environnements actuels,
les quatre les plus représentés sont cités ci-dessus. Les autres représentent une trop faible part de
marché pour être étudiés.
Néanmoins, une description technique de ces serveurs est proposée dans les lignes suivantes. Il
se peut que des termes inconnus soient invoqués. Dans l'état actuel des choses, l'auteur du
document invite le lecteur à lire des revues adéquates.
Netscape Enterprise v3.51
Le troisième serveur, Netscape Enterprise v3.51, est sur le point d’être remplacé par un autre
serveur qui a déjà commencé à faire parler de lui : iPlanet Web Server v. 4.1 (site
www.iplanet.com).
Cette version du serveur Netscape fournit aux utilisateurs finaux la gestion du site par une
approche appelée "Netshare". Les services Netshare incluent la publication, le contrôle des
accès, et de version. Netshare facilite le travail de groupe, notamment lors de la création d'un
document, en gérant finement le contrôle d'accès à ce dernier, tout ceci sans avoir besoin d'un
administrateur système pour intervenir.
Elle offre aussi la délégation de gestion administrative du serveur et l'intégration de la technique
Java (JavaBeans, JDBC et servlets).
Pour de grandes organisations et beaucoup d'utilisateurs, Netscape Enterprise est utile pour
mettre en œuvre un serveur de gestion centralisée s'appuyant sur une grappe de serveurs Web.
En son sein, le serveur Zeus emploie un petit nombre de processus d'entrée-sortie simples et
chaînés, qui sont chacun capable de traiter des dizaines de milliers de connexions simultanés.
Cependant, un haut trafic nécessite la mise en place d'un groupe de serveurs.
Le serveur Zeus supporte de manière native l'organisation en grappe. Ceci permet à un jeu de
serveurs Web d'agir comme un simple serveur pour l'utilisateur final. Cela permet aussi de
répartir la charge sur des ordinateurs différents. Cela suppose que l'entreprise ait la largeur de
bande suffisante ainsi que des moyens de raccordements multiples.
Système d'exploitation • Certains ne sont supportés que par une plate-forme donnée :
serveurs Microsoft limités à Windows, Zeus Web Application
Server limité à UNIX.
• Le serveur Apache est présent aussi bien dans l'environnement
UNIX que dans l'environnement Windows.
• Le serveur Netscape Enterprise Server et son successeur sont
véritablement multiplateformes : UNIX, Windows, Mac, et
Novell.
Publication et Publication
Enregistrement • Le serveur peut offrir différentes adresses de publication car il
(historique des peut écouter des adresses et des ports multiples.
connexions) • Le serveur peut aussi bien publier des sites situés sous
sa racine de publication que des sites virtuels présents ou non
sur la station, ou des sites accessibles à travers le réseau.
Performance
• Des fichiers de mesure de performance peuvent être mis en
oeuvre.
• Il possède des outils de mesure de performance en temps réel.
fichiers.
Sécurité et Sécurité
Administration • La sécurité de base repose sur le mot de passe.
• Il peut changer la liste de contrôle d'accès d'utilisateur sans
relancer le serveur.
• Des groupes d'utilisateurs sont configurables .
• Un serveur de certificat est intégré.
• Il supporte le protocole sécurisé S-HTTP.
• Il supporte la technique de chiffrement SSL v. 2 et v. 3.
• Le serveur peut cacher la partie d'un document sécurisé.
• Les règles de sécurité peuvent s'appuyer sur les adresses URL.
• Il interdit l'accès par le nom de domaine, l'adresse IP,
l'utilisateur et le groupe.
• Les permissions pour documents sous répertoires héritent des
droits hiérarchiques.
• Il autorise l'exécution de scripts CGI.
Administration
• Le serveur peut inclure des outils d'administration.
Protocoles et Microsoft
"Includes" supportés • Le serveur soutient la technique ISAPI.
Netscape
• Le serveur soutient la technique NSAPI.
Sécurité Microsoft
• Le gestionnaire de certificat X.509 (donc normalisé), est
complété par l'authentification propre à Windows NT.
Zeus
• Il gère les certificats numériques d'authentification.
• Il permet un contrôle d'accès distribué et dynamique.
• La gestion de groupe d'utilisateurs est centralisée via un
annuaire LDAP.
Orientation du Choix
3.1 Site Personnel
Dans l'environnement PC, comme premier serveur d'approche, le serveur web personnel de
Microsoft (PWS) en environnement Windows, et le serveur Apache d'Apache Software
Foundation en environnement UNIX sont suffisants.
• Apache 1.3.12
Il obtient la deuxième place grâce à son système
d'authentification et ses fonctions de restriction d'accès.
Espérons que ces quelques résultats aideront les décideurs à effectuer leur choix…
En conclusion, pour un Intranet léger et pour un rapport performances / prix imbattable (puisque
gratuit), Apache se place en première position. Le serveur iPlanet coûte actuellement 1 677 € HT
(fin d'année 2001), une réduction est annoncée pour mars 2002 ($940). L'acquisition de IIS5.0
nécessite au préalable celle du système d'exploitation : d'où un coût de 3 964 € HT. Pour un site
sécurisé, il vaut mieux choisir iPlanet.
Dans le paragraphe suivant est abordée l'étude des serveurs Microsoft à travers l'examen de leur
offre commerciale. L'étude approfondie des deux serveurs fait l'objet des deux chapitres
ultérieurs.
Offre Microsoft
Même si les serveurs Web de Microsoft ne représentent que 25% à 30% des sites Internet du
marché, les clients dans 80% des cas travaillent dans un environnement Windows. Il parait donc
incontournable de présenter les serveurs Microsoft, dans la mesure où ils vont servir dans le cas
général de serveur de test, ou de serveur d'entreprise à vocation Internet ou Intranet.
Ces deux offres diffèrent par le nom d'appel commercial, mais en vérité utilisent le même
moteur, la même présentation et la même organisation : présence permanente du terme IIS sous
PWS.
En fait, sur le plan des fonctionnalités, si le serveur IIS parait complet à l'égard des services
Internet que l'on peut proposer, le serveur PWS représente une version bridée du premier.
De plus, les offres destinées à Windows 98 ou Windows 95 sont encore plus bridées dans la
mesure où elles ne fournissent plus qu'un service : le service Web.
4.2 Distribution
Ces serveurs sont déjà fournis avec le cédérom d'installation du système d'exploitation.
Le programme d'installation du système peut proposer ces services si l'on opte pour une
installation personnalisée (Windows NT Station). Dans le cas négatif, l'aide en ligne du système
d'exploitation renseigne normalement sur la localisation du serveur sur le cédérom et la
procédure à suivre pour l'installer.
L'inconvénient majeur de la version proposée par le cédérom d'installation du système
d'exploitation réside dans la version du serveur. La version présente est celle livrée au moment
de la commercialisation de ce dernier : PWS version 2.0 pour Windows NT4.0 WS.
Pour bénéficier des versions ultérieures, deux solutions sont proposés : passer par les services
pack (Pack5 offre la version 4.0), ou passer par un cédérom spécifique "Windows NT option
Pack".
Ce dernier cédérom présente l'avantage majeur de fournir toutes les offres (excepté Windows
2000), qu'elles soient destinées à Windows 95 ou 98, Windows NT WorkStation, Windows NT
Server.
Si le cédérom est livré gratuitement avec le système d'exploitation Windows NT, son contenu est
téléchargeable via Internet (600francs à la commande).
4.3 Utilité
Le serveur PWS est présenté comme un serveur Web de bureau qui peut être utilisé autant pour
héberger un site Web sur l'Intranet d'une petite entreprise que pour développer et tester un site
Web avant de le publier chez un fournisseur de services Internet.
Le serveur IIS, de par le nombre des services proposés, et grâce aux différents dispositifs de
sécurité possibles, a plus la vocation d'un serveur Internet d'entreprise hébergeant le site portail
de celle-ci.
4.4 Comparaisons
Pour synthétiser les différentes versions, nous présentons d'abord les prestations de la version la
plus limitée, Windows 98, afin de terminer par la version la plus complète, IIS.
Restrictions de PWS pour Windows 98 (ou 95) par rapport à PWS pour Windows NT
L'originalité et donc l'avantage principal du serveur Web de Microsoft destiné au système
d'exploitation Windows NT est d'offrir à la fois les services Web et FTP.
Il est rappelé que l'offre jointe au cédérom Windows 98 (ou 95) se limite au seul service Web.
Le serveur PWS pour Windows 98 propose une interface d'administration graphique destinée
aux utilisateurs non expérimentés en matière de création et d'administration de sites Web :
Gestionnaire de Serveur Web.
Cette interface constitue également l'outil d'administration par défaut du Serveur Web personnel
pour Microsoft Windows NT Workstation.
Cependant, la version pour Windows NT Workstation permet également d'administrer le site de
publication personnel à l'aide du Gestionnaire des services Internet, l'outil d'administration
complet utilisé pour gérer Microsoft Internet Information Server.
La version "PWS" de "Windows 2000 Pro", la version 5.0, apporte peu de changements par
rapport à la version de Windows NT", sinon que le nom "PWS" a complètement disparu de la
distribution.
Le seul changement notable apparaît au niveau des services fournis : service de relais de
messagerie autrefois limité à la version IIS.
En dehors du fait que IIS passe outre les restrictions évoquées ci-dessus, il propose la gestion
d'autres services Internet :
• Serveur de News,
• Relais SMTP vers le Serveur SMTP de Windows (MS Exchange),
• Moteur de recherche.
Il propose par ailleurs des services d'application étroitement liés au Web: service de transaction,
service de messagerie inter-applicative. Les performances de la version 5.0 de IIS dans ce
domaine ont été mentionnés plus avant.
Conclusion
Le développement de sites Web purement statiques, en dehors des sites personnels, devient plus
rare. Comme il a été développé plus haut, les sites statiques n'ont pas besoin d'un serveur pour
être testés.
Le cas des sites interactifs, à pages dynamiques, applicatifs, ou offrant plusieurs services, est
autre. Dans ce cas, la nécessité d'un serveur de test point rapidement. Le choix reste simple : le
serveur PWS ou Apache suffit.
Par contre, le choix d'un serveur de publication, obligatoire pour mettre en ligne sur le réseau le
site, peut s'avérer plus complexe.
Parmi les critères qui vont motiver les décisions, le choix de l’environnement devrait importer
peu dans la mesure où les services Internet permettent justement d’interconnecter les deux
environnements les plus prisés sur le marché. Un problème de compétence interne, notamment
sous l’environnement UNIX, peut pousser à choisir l’environnement Microsoft dans le cas d’une
PME : serveur IIS.
En ce qui concerne les organismes ne disposant pas d’un budget extraordinaire (PME,
universités), le prix peut être un facteur déterminant pour élire le serveur Apache.
Un des facteurs importants pour le choix reste le type de site. Un site vitrine ou statique ne
nécessite pas un serveur à hautes capacités. S’il s’agit d’un site de système d’information mettant
en jeu plusieurs sites ou sous sites, chaque site faisant interagir plusieurs applications, alors le
choix est tout autre : IIS sous Windows, Zeus sous UNIX, ou Iplanet multiplateforme.
Enfin, en fonction des techniques internes utilisées pour le fonctionnement du site, le choix va
se porter vers l’un ou l’autre : scripts PHP plutôt vers UNIX, scripts ASP plutôt vers Windows.
Les techniques proposées par Microsoft sont encore limitées à l'environnement Windows.
L'objet du présent chapitre est consacré au serveur web "Personal Web Server" de Microsoft
(PWS). Ce serveur a l'avantage de fournir un service FTP aisé à configurer, facilitant ainsi la
dépose et donc la publication de sites clients. Ce service sera le seul étudié au même titre que le
service web.
Ce chapitre rassemble non seulement l'étude de la version PWS dédiée à Windows NT station,
mais aussi celle de la version Windows 2000 Pro, et enfin celle propre à Windows 98 (ou 95).
Pour la version Windows NT, les copies d'écran et commentaires de ce document s'appuient sur
la version 4.0 de PWS ou IIS.
1. Installation
1.1 Configuration requise
Avant d'installer, il est indispensable de se renseigner sur la configuration requise.
Sous Windows 98
Composant matériel Configuration requise Recommandation
Processeur 486 33 MHz Pentium® 90 MHz
Mémoire vive (RAM) 16 Mo 20 - 32 Mo
Espace disque disponible 30 Mo 40 Mo
Sous Windows NT
Composant matériel Configuration requise Recommandation
Processeur 486 66 MHz Pentium® 90 MHz
Mémoire vive (RAM) 32 Mo 32 - 64 Mo
Espace disque disponible 30 Mo (minimum) 100 Mo
L'installation a été réalisée avec le cédérom "Windows NT option Pack" qui fournit la version
4.0. Installer PWS ou IIS diffère uniquement par les services et fonctionnalités proposés. Limité
aux services Internet purs (web, ftp, nntp), la procédure et les paramètres attendus restent les
mêmes.
Pour installer, il est obligatoire de se connecter en tant qu'administrateur de la machine hôte.
Figure 3
Si les étapes préalables d'installation sont satisfaites, le développeur ou le futur webmestre peut
lancer cette dernière directement depuis le cédérom. Les programmes d'installation se situent
sous le chemin suivant : \ntoptpack\fr.
Sous le répertoire spécifique à la version française (fr), l'on trouve des répertoires abritant des
versions différentes selon le type de processeur. Le processeur usuellement rencontré sur les
stations bureautique ou PC est de la famille Intel ou X86.
Il existe en dessous un répertoire spécifique à chaque système d'exploitation : Win.95 (Windows
95 ou 98), Winnt.wks (Windows NT station), Winnt.svr (Windows NT serveur).
Une fois le Système d'Exploitation (S.E.) choisi, il suffit d'exécuter le programme "install.exe".
Messages :
Si les deux composants prérequis sont effectivement présents, le(s deux) message(s) d'erreur qui
s'affiche(nt) néanmoins (figure 2) sont (est) à ignorer car le cédérom a été élaboré du temps du
service Pack 3 de Windows NT. Il ne reconnaît donc pas les services Pack ultérieurs.
Fonctionnalités
De suite, le programme présente les différents services et fonctionnalités (figure 3).
Figure 5
En dehors de celles déjà citées dans le chapitre présentant les serveurs web, il propose :
• Un service transactionnel pour applications interfaçant des bases de données (Transaction
Server),
• Des composants pour attaquer les bases de données (objets ADO, pilotes ODBC)
• Un service client gérant des files d’attente de message pour des programmes applicatifs,
• Un service RAS (Remote Access System via modem)
• Des outils d’administration (entre autres le "gestionnaire de services Internet")
• Des outils pour développeurs (débogueurs de scripts par exemple)
Types d'installation
Que l'on installe PWS ou IIS, le programme propose les trois options suivantes :
• Installation minimale : composants minimaux nécessaires au fonctionnement de PWS.
• Installation par défaut : installation minimale renchérie par des fonctionnalités
supplémentaires et de la documentation.
• Installation personnalisée
Le détail des composants effectivement installés lors des deux premiers types d'installation est
exposé en annexe.
Pour les utilisateurs expérimentés qui veulent choisir dans le détail les services, et notamment le
service FTP, le troisième type d'installation est conseillé.
Figure 6
• MS Management Console
Cet utilitaire représente la première version de la boite à outils qui sous Windows 2000
offre à l'administrateur la possibilité de gérer l'ensemble des services et matériels du
système d'exploitation… Dans un premier temps, il sert à administrer les services Internet
depuis la même interface. A ce niveau, l'on installe le composant principal jouant le rôle
de coquille vide à l'égard du gestionnaire de services Internet installé sous le composant
principal "Serveur Web Personnel".
• Script Debugger
Ce composant est nécessaire aux concepteurs de pages actives ou dynamiques (ASP) en
phase de test.
• Personal Web Server
Il s'agit du composant principal attendu pour faire fonctionner le serveur Web. C'est en
affichant les sous-composants (cliquer sur le bouton) que l'on peut cocher le service et
l'utilitaire nommés ci-dessous si besoin est :
+ Gestionnaire des Services Internet (ou MS Management Console),
+ Serveur FTP (celui de Microsoft ne supporte pas la reprise de téléchargement)
L'exemple de site Web proposé peut être intéressant à cocher.
• Client Message Queue Server
Ce service permet aux programmes d'application de communiquer entre eux facilement,
rapidement, en toute fiabilité et de façon asynchrone en envoyant et en recevant des
messages.
• Service de Connexion Internet pour RAS
Ce service est limité ici à une connexion simultanée au serveur alors que la version IIS
autorise 256 connexions.
• Transaction Server
Le service "Microsoft® Transaction Server" (MTS) prend en charge la création
d'applications transactionnelles à base de pages ASP. Une transaction est une opération
de serveur qui réussit ou échoue globalement, même si elle implique plusieurs étapes.
MTS prend également en charge l'isolation des processus des applications.
Même si le concepteur néophyte ne crée pas de suite des applications transactionnelles, il
est intéressant et conseillé d'installer ce dernier pour bénéficier de la fonctionnalité
d'isolation des processus pendant leur exécution.
Pour mieux apprécier cette explication, la lecture préalable du chapitre "Applications Web" du
module "HTML dynamique" est judicieuse.
Chemins
En fonction des services choisis, le programme propose d’installer d'une part les racines de
publication des services Internet, et d'autre part les programmes en eux-mêmes à l'endroit
habituel :
• Serveur Web InetPub\wwwroot,
• Serveur FTP InetPub\ftproot,
Figure 7
Une fois définis tous ces paramètres, le programme termine l'installation du serveur en 10
minutes environ. A l'issu, le programme oblige à réamorcer le système d'exploitation.
Menu Démarrer
Etant donné que l'installation du serveur a été réalisée avec le cédérom "Windows NT option
Pack", l'ensemble des menus et sous-menus est disponible sous l'option portant le même nom
(figure 6). Les options rencontrées restent fonction des composants cochés lors de l'installation.
Figure 8
Les sous-menus "MS Script Debugger", "MS Transaction Server", "Serveur de connexion
Internet pour RAS" (menu non présent dans la copie d'écran jointe car option non cochée
lors de l'installation),
Directement les options "Documentation en ligne", "Notes de Publication", et aussi
"Installation de…" :
• Cette dernière option permet d'ajouter ou de supprimer ultérieurement des
composants après insertion du cédérom.
Sous le menu principal « Serveur Web Personnel », les options : Administrateur de
serveur Frontpage, Gestionnaire de serveur Web personnel, Gestionnaire de services
Internet.
Les deux autres sections du chapitre vont se focaliser sur l'utilisation de ces gestionnaires.
Explorateur
Ce que le programme a installé sous "Program Files" ou sous Winnt importe peu ! Le plus
intéressant est de parcourir le répertoire de publication (Inetpub ou publication Internet). Ce
répertoire (figure 7) est accessible aux internautes une fois invoqué le service désiré. Décrivons
les répertoires contenus par Inetpub :
Le répertoire "wwwroot" représente la racine du serveur Web.
Dans une adresse URL, il est symbolisé par le premier
signe "/" rencontré, celui situé derrière le nom de
domaine équivalent.
Il en est de même pour "ftproot", racine du serveur FTP.
Le répertoire "iissamples" contient, comme son nom l'indique,
des échantillons de site Web, de formulaire d’entrée de moteur Figure 9
de recherche que l'on peut utiliser pour les sites publiés. Il
Edition février 2002 23242397.doc Page 23 sur 228
Systèmes Répartis INTERNET Serveurs Web
Figure 10
Remarque : la page publiée par défaut correspond aux "Notes de Publication" du menu
principal évoqué ci-avant.
Figure 11
Documentation en ligne
Pour ceux qui veulent en savoir plus sans quitter les menus, ils sont invités à consulter :
1. "Documentation en ligne" sous Windows 98 et Windows NT (figure 10)
• http://localhost/iisHelp/pws/misc/default.asp.
L'accès via une adresse URL oblige l'utilisateur à démarrer le serveur avant.
Figure 12
Sur le bureau, les deux icônes de l'utilitaire "Gestionnaire de Serveur Web personnel" sont bien
présentes.
Figure 13
Sous Windows 98, le menu principal s'intitule "Serveur Web personnel". En fonction des options
cochées, l'on trouve (figure 11) :
• Administrateur de Serveur Frontpage, Gestionnaire de serveur Web personnel,
Documentation en ligne, Installation du serveur Web personnel, Notes de Publication
• MS Transaction Server : Aide, Lisez-moi, Explorateur.
Le serveur Web en lui-même est installé sous Windows\System\inetsvr.
Composants de l'installation
Le nombre d'étapes d'installation est réduit au seul choix des sous-composants proposés par la
fenêtre figure 12.
Figure 14
Par rapport à la version de Windows NT4 décrite avant, un service supplémentaire est fourni : le
service SMTP virtuel.
Les extensions de serveur FrontPage sont maintenues avec la version 2000.
Le gestionnaire de serveur Web, ainsi que le gestionnaire de services Internet propre à Windows
NT (Composant logiciel enfichable…) sont également présents.
Le serveur dans son ensemble est amélioré dans la mesure où un service qui plante est relancé
périodiquement.
Figure 15
Figure 16
Les fichiers d'aide en ligne présents sous "wwwroot" sont accessibles en sollicitant le serveur:
http://localhost/ iisHelp.asp ou iisstart.asp.
Figure 17
Deux pages s'affichent simultanément : l'aide en ligne véritable du serveur (figure 14) ainsi que
la page "localstart.asp" (figure 15).
Figure 18
Il est possible depuis la première page, en cliquant sur "console" d'accéder à une troisième page.
Cette dernière (figure 16) indique comment atteindre le logiciel d'administration du site.
En suivant la procédure indiquée, l'on découvre non seulement le gestionnaire visé mais encore
d'autres utilitaires se rapprochant du même sujet. Les deux gestionnaires principaux seront
décrits dans la section "Administration".
En parcourant toujours cette première page (localhost.asp), si l'on clique sur "Imprimantes", une
autre page s'affiche ouvrant la porte à l'administration des imprimantes partagés via un interface
Web.
Figure 19
Le tour des éléments installés ne serait pas complet si nous ne nous intéressions pas aux comptes
d'utilisateurs. Un compte d'utilisateur anonyme est installé pareillement selon les mêmes règles
de nommage.
2. Administration
Le menu "Windows NT Option Pack" propose pour chaque version un ou deux utilitaires
d'administration :
• Pour "Windows NT Workstation", un "Gestionnaire de services Web", et le gestionnaire
"Microsoft Management Console"
• Pour "Windows 98", uniquement le "Gestionnaire de services Web".
Description du Gestionnaire
Le lancement de Microsoft Management Console (MMC) ouvre une fenêtre composée de deux
volets (figure 18). Le volet gauche est appelé volet de structure. Il affiche l'arborescence de
l'espace de noms, c'est-à-dire une liste hiérarchisée de tous les éléments pouvant être gérés par le
gestionnaire à un moment donné. Chaque élément (ou noeud) de l'arborescence représente un
type d'objet, de tâche ou de conteneur.
Lorsque un noeud est sélectionné dans l'espace de noms, le volet droit de la fenêtre, ou volet de
résultats, affiche les résultats de cette sélection.
Il existe plusieurs niveaux de gestion.
Pour gérer chaque niveau, nous disposons de plusieurs moyens : les menus, les icônes, les menus
déroulants, le menu contextuel à l'objet sélectionné correspondant au menu déroulant "Action".
Nous allons maintenant décrire sommairement les niveaux.
Figure 20
Figure 21
de mettre en place des raccourcis vers des adresses URL (figure 19),
Figure 22
d'installer des contrôles Active X au niveau du nœud sélectionné (figure 20), pour
surveiller le serveur, respectivement dans son fonctionnement général ou au niveau de la charge.
• Si l’on choisit une de ces trois options, un menu adapté s’affiche.
• D'autres options de gestion classique d'un gestionnaire (coller, nouvelle fenêtre, volet de
structure, barre de description)
Les paramètres de configuration d'une console, console « iis » par défaut, sont enregistrés en fin
de session dans le fichier "iis.msc".
Figure 23
L'ajout d'un ordinateur distant (nom DNS ou Netbios, ou adresse IP) permet d'en
gérer les services qui y sont installés (figure 22). La condition préalable est d'avoir un
compte d'administrateur reconnu non seulement par la station distante mais aussi
déclaré comme opérateur du serveur Web au niveau de ce dernier.
Figure 24
Figure 25
Figure 26
Le troisième niveau définit les stations à gérer. On voit ici qu'il est possible de gérer d'autres
serveurs que le serveur local. Décrivons les différentes possibilités :
Icônes
• Des fonctions de gestion classique d'un gestionnaire (dossier parent, masquer/ afficher la
structure), les propriétés du nœud considéré, et des opérations à lancer analogues à celles
décrites au deuxième niveau.
Fenêtre déroulante "Action" (même fonctionnalités que par clic droit) :
• Des fonctions de gestion classique d'un gestionnaire (nouvelle fenêtre, actualiser, volet de
structure, barre de description <supplémentaire>), des fonctions de gestion du nœud considéré
[(dé)connecter, sauvegarder/ restaurer la configuration, propriétés].
L’option (dé)connecter (supprime)ajoute le serveur du volet de structure.
Figure 27
• Les fonctions de gestion classique (dossier parent, masquer/ afficher la structure), des
opérations à lancer à partir du nœud sélectionné (gestionnaire de clés, analyseur de
performances, observateur d’évènements)
• Les fonctions de gestion d'activité du nœud (arrêter, démarrer, pause), et la fonction de
configuration "Propriétés".
Fenêtre déroulante "Action" (ou clic droit sur le nœud sélectionné) :
• De nouvelles fonctions de gestion (explorer, ouvrir, parcourir), mais encore celles
précédemment décrites [nouvelle fenêtre, actualiser, volet de structure, barre de
description (supplémentaire)], les fonctions déjà mentionnées de gestion du nœud
(arrêter, démarrer, interrompre, propriétés) et des nouvelles (menu "Nouveau", tâche),
• C'est à ce niveau que l'on constate une première différence entre PWS et IIS : le champ
« Nouveau » propose uniquement l’option « Répertoire virtuel » pour PWS (car il ne
permet pas de définir plusieurs sites Web ou FTP) alors que le champ « Nouveau » pour
IIS ajoute l’option « Site » afin d'être en mesure de publier d’autres sites.
Menu
Différentes options sont proposées sous le menu « Console » :
Options de gestion de console en rapport avec les fichiers de configuration *.msc :
nouveau, ouvrir, enregistrer (sous)
Ajoût (ou la suppression) d'un composant logiciel enfichable
Quitter
Celui-ci nous propose d’enregistrer les paramètres de la console « iis ».
Figure 28
Figure 29
• Choisissons (figure 27) le service désiré avant de valider (bouton OK) : Index Server
(uniquement IIS), Internet Information Server, MS Transaction Server,
Les options "Contrôle de pilotage", "Contrôle général", "Dossier" et "Lien vers une
adresse Web" ont déjà été décrites plus haut.
• Choisissons sur quelle station installer le composant si plusieurs serveurs sont surveillés : le
compte d’ordinateur local ou un autre.
Ceci termine la description intrinsèque du gestionnaire. Nous allons maintenant nous attacher à
décrire les paramètres de configuration des services.
Propriétés de la Station
Un seul onglet « Internet Information Server » nous est présenté (figure 28) afin de gérer à ce
niveau certains paramètres globaux à l'ensemble des sites publiés. Les trois cartouches visibles
ci-dessous nous permettent de :
• Modifier les propriétés du "Site … par défaut",
o Quel que soit le service choisi, le logiciel affiche une fenêtre de propriétés analogue, à
un onglet près, à celle décrite dans les lignes suivantes. Aussi, en dehors de l'onglet
spécifique, aucun commentaire spécifique ne sera fait à ce niveau.
Figure 30
La seule différence qui existe dans l’affichage des propriétés entre celles de la station et celles du
site réside dans la présence d'un onglet supplémentaire « Administration IIS 3.0 » au niveau de la
station. La légende de l'onglet (figure 29) suffit à expliquer son objectif.
Figure 31
Propriétés du Site Web
Pour accéder aisément à l'ensemble des propriétés du Site Web (par défaut ou autre), il suffit par
exemple de sélectionner l'option "Propriétés" dans le menu contextuel du site sélectionné.
Nous allons présenter sommairement chacun des paramètres des huit onglets qui apparaissent.
1. Site Web
Cet onglet (figure 30) est important car il définit d'une part l'identité du site, et offre l'accès au
fichier journal.
Figure 32
Quatre identifiants sont associés pour décrire le site et gérer son accès : un nom de noeud au
niveau de la MMC (Description) et trois éléments réseau (adresse IP, numéro de port TCP,
nom d'en-tête de l'hôte).
<Description>
• Le nom de nœud reste propre au gestionnaire. Changer le nom descriptif offre un
intérêt pour distinguer les sites les uns des autres dans le cas de la publication de
plusieurs sites. Or le serveur PWS publie un seul site.
<Adresse IP>
• Deux valeurs possibles : une adresse IP assignée au site Web en question, sinon
"toutes non assignées par défaut".
L'assignation d'une adresse IP à un site sous-entend que le nom du serveur (ou le
nom du site) soit configuré au sein du serveur DNS. Sinon, l'internaute doit connaître cette
adresse pour atteindre le site (seul http://@IP fonctionne).
L'assignation est plutôt utilisée dans le cas de sites multiples, ou dans le cas de
l'hébergement de plusieurs services Internet par la même station (une adresse par
service).
L’assignation empêche l’utilisation de l’adresse de boucle locale (localhost ou
127.0.0.1) pour tester son site. Elle limite le test du site à la seule adresse IP de la station ou son
nom d'hôte (complet ou non).
<Port TCP>
• Le numéro de port TCP "80" est celui associé par défaut au protocole HTTP
(service Web).
• Le changement de numéro de port permet de privatiser l'accès à un site donné
dans la mesure où les internautes doivent connaître ce numéro pour l'atteindre. En
pratique, le nom de domaine ou l'adresse IP du site doit être suivi du caractère ":",
puis du nouveau numéro de port.
Prenons l'exemple d'un numéro de port égal à 8080 (premier numéro choisi en dehors
de 80). Le client doit compléter l'adresse URL ainsi : http://www.monsite.com:8080.
Figure 33
Restriction d'emploi :
Les services réseau les plus connus du monde IP (well-known ports) utilisent un numéro
de port entre 1 et 1024. Ce sont des ports réservés que tout administrateur réseau n'utilise
pas en dehors de l'invocation du service associé. Au fur et à mesure des années, le
nombre de ces ports réservés a dépassé le chiffre 6000.
Figure 34
Le dernier champ de la figure 1 est étiquetté ainsi. Il s'agit d'utiliser une des nouvelles
fonctionnalités offertes par le protocole HTTP1.1 : le paramètre de l'en-tête protocolaire
"Host" supporté par les navigateurs de version 4.0 (IE et Netscape). Cette possibilité
existe depuis la version 4.0 de PWS.
Cette possibilité très importante côté serveur, permet de donner des noms de site
génériques différents tout en fonctionnant avec une seule adresse IP.
Ceci est très séduisant dans le cas où le serveur peut publier plusieurs sites (IIS), ce qui
n'est pas le cas de PWS. Si le webmestre veut masquer le nom de station hébergeant le
serveur par le nom générique du seul site publié, il peut utiliser ce procédé.
Les inconvénients de cette méthode sont de ne pas franchir tous les serveurs proxy, et de
ne s'appliquer qu'aux services web.
Nombre de connexions
• Alors que le serveur Web Personnel est limité à 10 connexions "utilisateurs", le champ
reste accessible au webmestre (?!!) qui peut ainsi augmenter le chiffre de 10. Il en est de
même au niveau du « Site ftp par défaut ». Le logiciel envoie le message
d’avertissement suivant, mais laisse le webmestre valider la changement sans l'appliquer :
Les services PWS sont limitées à 10 connexions. La définition à une valeur supérieure à 10
est une violation de votre contrat de licence.
<Délai de connexion>
• Ce délai exprime en fait un seuil au delà duquel le serveur déconnecte l'internaute (900
secondes ou 15 minutes d’inactivité).
Fichier journal
• Situé sous "\Winnt\System32\Logfiles", le fichier journal a pour but d'enregistrer les
connexions des internautes.
• Plusieurs formats de fichiers sont proposés : format "w3c" (valeur par défaut, w3c étant
le consortium du Web), format NCSA, format Microsoft. Le format "W3c" peut encore
être dénommé "CERN" sous d'autres serveurs Web, en souvenir de l'organisme origine de
l'inventeur du Web.
Figure 35
• Un clic sur le bouton "Propriétés" affiche une nouvelle fenêtre comportant un ou deux
onglets, en fonction du format choisi (figure 33).
• Le premier onglet, commun à tous les formats, permet de paramétrer la période de
cycle du journal. Il indique par ailleurs le nom générique du fichier spécifique au
format choisi.
Figure 36
2. Performances
Figure 37
3. Filtres ISAPI
• Ce sont des petits programmes activés par le serveur avant que ce dernier cherche la page
Web désirée (il existe de même les filtres NSAPI de Netscape). Ces filtres recoivent aussi
bien les trames entrantes que sortantes.
• Des filtres sont mis en place si l'on utilise le cryptage SSL ou les extensions de serveur
FrontPage. En général, ce sont les logiciels utilisés qui installent ces filtres.
• Il faut par contre veiller à l'ordre d'utilisation de ces filtres, par exemple le filtre SSL avant
celui des extensions.
L'utilisation de tels filtres peut ralentir les performances du serveur.
A titre d'exemple, certains sont mis en place par défaut au niveau des propriétés de la station
(figure 36).
Figure 38
Figure 39
4. Répertoire de base
Cet onglet est le plus important à paramétrer (figure 38). Il permet de localiser le site ou
plutôt son répertoire racine (en dessous duquel on trouve la page d'accueil). Il permet de
fixer les contrôles d'accès côté serveur Web en fonction du contenu du site et des facilités
proposés.
Figure 40
• Indexer :
Cette option, accessible sous PWS, met en jeu le service d'Index Server que seul
le serveur IIS permet d'installer. En effet, seul IIS propose un moteur de recherche
qui indexe les sites publiés sur sa station, mais aussi des sites publiés par un
serveur PWS distant.
Indexer les pages web du site permet au serveur de puiser des renseignements
dans ces pages, renseignements qu'il range dans des fiches. Ces fiches vont
alimenter au fur et à mesure de la collecte un catalogue. Pour répondre aux
requêtes des internautes, le moteur de recherche constituera une page Web à la
volée contenant les fiches désirées issues du catalogue.
Remarques Importantes :
• Lorsque sont définis les propriétés de sécurité d'un site spécifique, les mêmes
propriétés sont automatiquement définies pour tous les répertoires et fichiers
appartenant à ce site, sauf si les propriétés de sécurité des répertoires et des fichiers
sont redéfinies au niveau individuel.
• Si les permissions NTFS et les permissions du serveur Web sont en conflit, ce sont les
paramètres les plus restrictifs qui sont utilisés.
• Ainsi, les permissions refusant l'accès prévalent toujours sur celles autorisant l'accès.
Paramètres d'application
Le cartouche concerne à la fois l'exécution de pages de scripts côté serveur (pages ASP),
et celle d'applications à base de scripts CGI ou ISAPI.
Figure 41
Figure 42
Répertoire de base
• La racine du serveur est par défaut "C:\Inetpub\wwwroot", mais il est possible de
changer la racine du serveur (bouton Parcourir) tout en restant sur la même machine
(figure 41).
Figure 43
Figure 44
Figure 45
• Une troisième possibilité consiste à aller chercher le site sur un autre serveur
(figure 43). Ce procédé est souvent utilisé par des sites obligés de se délocaliser
fréquemment. Une option permet au webmestre d'utiliser le serveur pour effectuer
une redirection URL permanente.
5. Document
Figure 46
Pied de page
Le serveur insère automatiquement un fichier au format HTML en bas de chaque document
Web. Le fichier de pied de page ne doit pas être un document HTML complet, mais doit
seulement inclure les balises HTML nécessaires pour la mise en forme de l'apparence et de la
fonction du contenu de votre pied de page.
Voici deux exemples d'application : un pied de page commun à toutes les pages d'un site (ou
une partie spécifique), des bandeaux publicitaires des services hébergeurs.
6. Sécurité de répertoire
Cet onglet (figure 45) gère les connexions au serveur ainsi que les moyens d'authentification
des internautes. Il permet de plus de sécuriser l'accès à des sites protégés par l'intermédiaire
d'échanges de certificats.
Figure 47
que ces connexions sont autorisées par défaut. Les autres méthodes d'authentification ne
semblent pas nécessaires à priori.
<Connexions anonymes>
Figure 48
Dans le cas de réseaux hétérogènes (UNIX, Mac ou autre), les connexions anonymes
sont obligatoires.
L'action du bouton "Modifier" (figure 47) nous rappelle le nom du compte utilisateur des
connexions anonymes.
La synchronisation configurée par défaut doit être conservée.
Figure 49
Problème d'accès :
Si un utilisateur anonyme ne peut pas accéder au site, il faut contrôler les éléments
suivants :
• Le mot de passe de l'utilisateur anonyme doit être identique dans le
Gestionnaire des services Internet et dans le Gestionnaire des
utilisateurs.
• Dans le Gestionnaire des services Internet, sélectionnez le site
Web, le répertoire virtuel, répertoire ou fichier dont il faut contrôler la
connexion anonyme.
<Authentification de base>
Lorsque le serveur Web authentifie un utilisateur à l'aide de la méthode
d'authentification de base, le navigateur Web de l'utilisateur transmet les noms
d'utilisateur et mots de passe du compte Windows NT via le réseau sous forme
non cryptée.
Figure 50
Il est possible d'activer les fonctionnalités de cryptage SSL du serveur Web afin
de protéger ses informations de compte. Pour activer SSL, il faut d'abord installer
un certificat de serveur.
Figure 51
Problème d'accès :
Si les utilisateurs disposant des droits d'authentification de base rencontrent des
problèmes pour accéder au site, contrôlez les éléments suivants :
Vérifiez que l'utilisateur dispose des droits Ouvrir une session localement
dans le Gestionnaire des utilisateurs (voir stratégie de compte),
Vérifiez que le domaine de connexion par défaut est indiqué pour
l'utilisateur.
Les deux méthodes d'authentification ci-dessus servent dans le cas où le webmestre doit
protéger l'accès à un site, une partie du site ou même une simple page Web. Dans ce
cas, le webmestre doit définir le niveau à partir duquel il met en place ses méthodes
d'authentification, car les pages situées à des niveaux inférieurs héritent de ces mesures
en question.
En conclusion, les connexions anonymes sont à utiliser au niveau des serveurs Internet,
alors que les autres méthodes sont plutôt réservées à des serveurs Intranet.
Une restriction s'impose. Ces méthodes sont applicables à des organismes fonctionnant
dans leur globalité avec le seul environnement Windows NT, et ci-possible dans le même
domaine NT.
Contrôle d'accès (schéma figure 50)
Lorsqu'un utilisateur tente d'accéder au serveur Web, ce dernier exécute différentes
procédures de contrôle d'accès afin d'identifier l'utilisateur et de déterminer le niveau
d'accès autorisé.
Les ACL ou listes de contrôles d'accès spécifiques au système de fichiers NTFS
terminent la phase d'authentification. Ce procédé est le plus restrictif car il permet de
préciser en détail les utilisateurs autorisés.
Une des façons de déclarer ces utilisateurs est de travailler au niveau des permissions
physiques du répertoire abritant le site.
Figure 52
b) connexions sécurisées
Les connexions peuvent être sécurisées grâce à la mise en oeuvre de la technique SSL. Des
organismes style Verisign fournissent le couple de clés nécessaires pour sécuriser le serveur à
l’égard d’Internet.
Le bouton "Gestionnaire de clés…" lance la même fenêtre que celle décrite dans le
gestionnaire de services.
Exemple de configuration : 1 site public, 1 site privé protégé par SSL sur le même serveur.
7. En-têtes HTTP
Les différentes options de cet onglet (figure 51) concernent les en-têtes protocolaires
HTTP. Le webmestre peut ici configurer le comportement de l'ensemble des pages du
site. Avant de renvoyer la page désirée vers l'internaute, le serveur insère ces éléments
protocolaires. Ils se substituent aux balises META (module HTML statique) que le
concepteur de site a inséré dans l'ensemble de ses pages web.
• Expiration :
Fixer une date d'expiration pour une page donnée entraîne la suppression de cette
page du cache du navigateur (répertoire “Temporary Internet Files”) à partir de
cette date. Ceci oblige le navigateur à actualiser la page lors de la prochaine visite.
Ces options sont intéressantes pour tous les sites dont le contenu change
fréquemment (sites boursiers, sites de quotidiens).
Figure 53
Figure 54
Figure 55
Figure 56
• MIME :
Le serveur indique au navigateur quel est le type du contenu de la page Web.
Dans le cas classique, les pages web sont de type "text/html". Il se peut que le
contenu de la page renvoyée par le serveur soit de tout autre nature : page web
dynamique, fichier téléchargé ("multipart/formdata"), document multimédia, etc.
Soit le concepteur de site l'indique à l'aide des balises META (http-
equiv="Content-Type"), soit le webmestre l'indique dans ce cartouche, mais au
niveau adéquat du site.
Figure 57
Une fois cliqué sur le bouton "Type de fichiers…", la fenêtre figure 55 donne un
tableau de correspondance entre les extensions de fichiers et les types MIME à
installer.
Remarque : la copie d'écran jointe a été réalisée au niveau des propriétés de la station.
8. Messages d’erreurs
Figure 58
Cet onglet (figure 56) permet d'accéder aux différents messages d'erreur renvoyés par le
serveur Web.
La série 400 concerne les erreurs clients alors que la série 500 traite les erreurs côté serveur.
Il est possible pour le webmestre de modifier leur contenu (bouton "Modifier les
propriétés…") ou de restituer les valeurs initiales (bouton "Utiliser les valeurs par défaut…").
Remarques :
• Une fois le site publié, il est possible à tout moment d'en modifier les propriétés. Pour
cela, la procédure conseillée consiste à : 1= arrêter le site, 2= modifier, 3= le relancer.
Figure 59
Figure 60
• Des modifications apportées à un niveau donné peuvent contredire des propriétés définies
à un niveau inférieur. La fenêtre "Héritages outrepassés" demande au webmestre s'il veut
que les noeuds enfants héritent de la nouvelle propriété (figure 58).
• Dès que l'on fait un changement, n'oublions pas de valider celui-ci en cliquant sur
"Appliquer" avant de quitter la fenêtre "Propriétés".
1. Site FTP
A l'image de celle du site Web, cet onglet (figure 59) définit le site et offre l'accès au fichier
journal.
Identification
Les mêmes principes d'identification existent avec les mêmes conséquences.
Le numéro de port par défaut du service (ou protocole) FTP est égal à 21. Il n'est pas
modifiable sous PWS.
Surveillance
Les fichiers historiques du Site FTP se trouvent aussi sous Winnt\System32\Logfiles.
Les noms des fichiers (<ex'an''mois''jour'.log> par exemple), leur durée de cycle, varient
selon le format utilisé.
Figure 61
Deux formats sont présents : IIS et W3C. Seul le format W3C autorise la modification
des champs.
En cliquant sur le bouton "Sessions en cours", le webmestre peut surveiller l'activité des
clients (figure 60).
Figure 62
Remarque :
Il existe une autre possibilité pour le Webmestre sous Windows NT pour visualiser les
clients connectés à l'instant "t" : commande NT "netstat –a".
2. Comptes de Sécurité
L'utilisateur Windows NT prévu pour autoriser les connexions anonymes est configuré
lors de l'installation (figure 61). A priori, il n'y a plus lieu de modifier quoi que ce soit
dans ce cartouche.
Connexions anonymes
L'accès aux services FTP met en œuvre principalement les connexions anonymes (case
cochée par défaut).
Opérateurs de site FTP
Un autre cartouche précise dans le domaine NT quels sont les opérateurs autorisés sur ce
site. Ce cartouche n'est activé qu'avec la version IIS.
Figure 63
3. Répertoire de base
Cet onglet (figure 62) est le plus important car il fixe la localisation du site et les droits
d'accès.
• Les redirections URL se sont pas autorisés.
• Les droits en lecture suffisent pour télécharger des fichiers. Dans le cas de la
dépose de fichiers, il faut ajouter les droits en écriture.
• Il est possible de gérer le type d'affichage : MSDOS (icônes) ou UNIX (liste).
Figure 64
4. Messages
Figure 65
• Trois messages (figure 63) peuvent être envoyés au client : le message de bienvenue,
celui pour Quitter, et le message d'erreur si le maximum de connexions est atteint.
• Si le message de bienvenue est visible depuis le navigateur, les autres messages ne le sont
que si l'on se connecte au service FTP par un autre moyen : logiciel spécialisé ou mode
commande.
• En conséquence, si les clients accèdent au site FTP uniquement depuis leur navigateur,
seul le message de bienvenue suffit.
5. Sécurité du Répertoire
La présence de cet onglet (figure 64) est inutile dans la version PWS dans la mesure où celle-
ci n'autorise pas le filtrage d'adresses IP.
Figure 66
Administration à distance
Le programme d'installation avait demandé si l'administration du serveur était locale ou distante.
Dans le cas où l'administration distante n'a pas été choisie, il est possible de le configurer
ultérieurement.
Le fait de cliquer dans le volet de structure sur l'icône du nouveau serveur à gérer fait apparaître
dans le volet de résultat les sites publiés par le serveur distant.
Remarques :
• Si un site Web réside sur plusieurs ordinateurs exécutant les Services Web Perso, l'on peut
tout gérer depuis un ordinateur central, grâce à un compte d'administrateur NT.
• Il est possible d'administrer depuis son navigateur en saisissant l'adresse URL :
http://nom_serveur_publication/iisadmin.
L'authentification par stimulation ou de base est alors recommandée.
Cinq options sont définies et accessibles depuis le menu situé à gauche dans l'écran principal :
• général, publier, site web, visite, avancé.
Passons en revue les possibilités de chaque option du menu.
Le menu "Publier" permet d'utiliser un assistant de publication, une fois que la page d'accueil est
définie.
Le menu "Visite" (figure 65) permet de découvrir les fonctionnalités du serveur (aide en ligne).
Figure 67
Le menu "Avancé" (figure 66) est le plus important car c'est lui qui permet véritablement de
publier le site.
Le serveur PWS permet la publication d'un seul site.
Le cartouche en question affiche l'arborescence de publication du serveur. Trois boutons à droite
offrent la possibilité d'ajouter, de modifier ou de supprimer les sous sites virtuels publiés.
Le lieu de publication par défaut (ou racine de publication) reste le répertoire
"Inetpub\wwwroot" représenté par <Home> dans la fenêtre.
Les différents répertoires affichés dans cette même fenêtre sont visibles directement sous
wwwroot ou sont localisés dans d'autres répertoires (C:\Program Files\Fichiers
communs\system\msadc pour msadc, C:\WINDOWS\SYSTEM\inetsrv pour IISADMIN,
C:\WINDOWS\Help pour IISHELP , C:\Inetpub pour IISSAMPLES, SCRIPTS et WEBPUB).
Pour le constater, il suffit de sélectionner le nœud en question, puis de cliquer sur le bouton
"Modifier". Les répertoires dont le nom commence par le caractère "_" sont réservés au
fonctionnement interne du serveur Web.
Figure 68
Pour ceux qui ne sont pas localisés sous wwwroot, le serveur a utilisé la technique des
répertoires virtuels pour son propre fonctionnement interne. Il est en effet possible de publier le
site autrement que par la copie du site sous wwwroot. Il faut pour cela définir le nom du nœud
dans l'arborescence, puis aller chercher le site dans l'arborescence de la station. En cliquant sur le
bouton "Ajouter", la fenêtre ouverte nous invite à indiquer ces paramètres.
Les différents techniques de publication sont redécrites dans la section suivante.
Le cartouche suivant "Document par défaut" attend le nom des pages d'accueil de l'ensemble des
sites. La fonctionnalité est activée par défaut.
Deux options permettent d'activer le journal historique des connexions, et d'afficher
l'arborescence du site dans le navigateur du client en cas de page non trouvée.
Figure 69
Une autre possibilité plus globale existe à partir de la gestion de l'ordinateur (figure 68). A partir
de la racine, sous le nœud "Services et applications" se trouvent les "Services Internet (IIS)".
Figure 70
Figure 71
Mais la gestion des services se fait principalement à partir des gestionnaires déjà décrits dans les
versions précédentes : gestionnaire des services Internet, gestionnaire Web personnel.
Figure 72
Figure 73
Un niveau a été supprimé dans cette nouvelle version (figure 71) : celui de la console. Seul
subsiste le nœud des services Internet.
Figure 74
Figure 75
Station
Il est désormais possible de démarrer ou d'arrêter les services à ce niveau (figure 73 et 74).
Figure 76
Site par défaut
Figure 77
Comme le montre la figure 75, le serveur mis en place par Windows 2000 ne permet que la
gestion d'un seul site. Seuls les répertoires virtuels peuvent être configurés à ce niveau.
La gestion des tâches associée à l'activité du serveur est une option rendue disponible pour la
version personnelle (figure 76).
Figure 78
Il paraît donc possible à ce niveau de mettre en place aussi bien des autorisations d'accès au site,
que de configurer les extensions serveurs.
Figure 79
Propriétés de la Station
Un nouvel onglet "Extensions Serveur" a fait son apparition (figure 77).
Outre les autorisations mentionnées, cet onglet permet au webmestre d'améliorer les
performances du serveur dans deux directions : préciser quel langage de script il utilise,
dimensionner la taille du cache du serveur en fonction de la fréquentation de ce dernier.
Il permet par ailleurs d'insérer dans les pages Web envoyées à l'internaute des éléments (balise
d'en-tête) lui permettant de répondre aux auteurs des pages.
En cliquant sur le bouton "Paramètres" au niveau des performances, la fenêtre figure 78 s'affiche.
Figure 80
L'action du bouton "Paramètres" au niveau du courrier électronique lance la fenêtre figure 79.
Figure 81
Figure 82
Figure 83
Au niveau des droits posés sur les pages, une case à cocher a été rajoutée. Il s'agit des pages de
script côté serveur (pages ASP par exemple).
Dans le cas général, l'internaute visualise dans la barre d'adresses du navigateur un fichier à
extension *.asp, alors que le navigateur affiche la page Web créée dynamiquement par les scripts
de cette page ASP. Il n'est donc pas possible dans ce cas d'accéder au code source de la page
ASP mais à celui de la page Web créée. Pour permettre au client d'atteindre le code source de la
page ASP, il suffit de cocher cette case.
Le cartouche réservé au paramétrage des applications sera commenté dans le module consacré
aux applications Web. En conséquence, les menus accessibles par le bouton '"Configurer" ne
seront pas commentés.
La fenêtre déroulante "Protection d'application" correspond à l'ancienne case à cocher "exécuter
dans un espace mémoire séparé". Le webmestre peut choisir entre exécuter l'application
hébergée par le site Web dans le même espace mémoire que celui du serveur IIS, ou la ranger
dans une file d'attente, ou l'exécuter dans un espace distinct (isolé) de celui du serveur.
Sécurité de répertoire
Le cartouche réservé aux certificats de sécurité permet à partir du bouton disponible de lancer un
assistant (figure 82).
Figure 84
A ce jour, pas d'autres nouvelles fonctionnalités ont été constatés concernant le fonctionnement
du site Web comme celui du site FTP, comme celui du serveur Web en général.
Au niveau de la publication, les procédures décrites dans le paragraphe de la version Windows
NT Workstation restent inchangées.
3. Publication
Après avoir installé le serveur, et fait le tour des paramètres de configuration des sites Web et
FTP, jouons maintenant le rôle du webmestre, et notamment celui de l'hébergeur.
Le rôle du serveur FTP classique consiste à offrir aux internautes un certain nombre de logiciels
ou de fichiers multimédia, libres. Le téléchargement de ces fichiers est donc gratuit.
Le rôle du serveur FTP de l'hébergeur consiste à autoriser le client à déposer son site sur le
serveur à un endroit qui lui est dédié.
Dans les lignes qui vont suivre, nous allons essayer de décrire les procédures permettant de
remplir ces deux rôles.
Sous PWS, le webmestre "hébergeur" peut créer des répertoires virtuels pour le serveur FTP,
répertoires pointant vers ceux des clients.
Figure 85
La simple différence avec l'opération précédente réside dans le fait qu'il faille déplacer la
racine vers un autre endroit sur la station.
Le bouton "Parcourir" dans l'onglet "Répertoire de base" nous permet de fixer la localisation
de la nouvelle racine, en lieu et place de "C:\Inetpub\ftproot". Si nous reprenons les
exemples cités à la page précédente, cela donne :
• Internet(D:) \public pour le serveur de téléchargement,
• Perso(D:) pour le serveur hébergeur.
Outre les opérations décrites ci-dessus, pour la publication des répertoires de dépose, le
webmestre peut aussi bien dérouter la racine du serveur FTP qu'utiliser le principe des
répertoires virtuels.
3. Répertoire virtuel
Le principe, déjà décrit au niveau de la gestion du Serveur Web Personnel sous Windows 98,
sera répété dans le paragraphe consacré à la publication de sites Web.
Remarque :
Une des dernières opérations et non des moindres consiste pour le webmestre "hébergeur" à
gérer par un moyen ou un autre la sécurité d'accès au répertoire du client. En fonction de
son nom d'utilisateur et mot de passe, il doit être le seul à pouvoir accéder à son répertoire et
à y pouvoir déposer les fichiers de son site.
Figure 86
Le contenu du site publié apparaît dans le volet de résultats du gestionnaire de services,
une fois le nœud "Site Web par défaut" sélectionné (figure 85).
Figure 87
Remarque :
Dans le cas où le nom de la page d'accueil n'est pas renseigné au niveau des propriétés du
site Web :
• Le client est dans l'obligation de l'indiquer derrière le nom de domaine équivalent
du site, en le précédent du caractère "/" pour atteindre le site. Voici un exemple où la
page d'accueil s'intitule "default.htm" : http://www.monsite.com/default.htm
• Sinon, le serveur renvoie le message d'erreur habituel : "Erreur 404: page non
trouvée".
Figure 88
Figure 89
Côté explorateur, le site choisi se situe sous "SiteESAT". Côté MMC, le site est public sous "Site
Web par défaut", repérable dans le volet de résultat à partir du répertoire "divers".
3. Partage accessible à travers le Réseau NT
Cette possibilité semble plus facile à mettre en œuvre sur des stations gérées par le même
contrôleur de domaine NT.
Côté serveur, au niveau des propriétés du site Web (onglet "Répertoire de base"), le
webmestre doit indiquer le nom de la station (nom Wins ou alias DNS) suivi du nom de
partage comme dans l'exemple suivant :
1. \\nom_station\nom_de_partage_Web.
Le fait de viser une station gérée par un autre domaine NT (DOM2\\…) ou d'utiliser un
compte déclaré sur un autre contrôleur de domaine (DOM2\nom d'utilisateur) semble plus
délicat à réaliser : approbation de domaines, configuration du réseau local, etc…
4. Redirection URL
Cette possibilité met en relation deux serveurs Web. Il est obligatoire que les deux serveurs
soient présents sur le réseau de manière permanente.
Le webmestre doit indiquer l'adresse URL complète au niveau de la définition du site (onglet
"répertoire de base"). Voici un exemple : http://nom_de_domaine.
5. Répertoires virtuels
Cette dernière possibilité est la plus utilisée par le webmestre afin d'éviter de démultiplier le
nombre de sites à gérer.
Dans le cadre de PWS (version NT ou version 98), elle représente la seule possibilité
d'héberger plusieurs "sites" ou plutôt plusieurs sous-sites.
Ces répertoires virtuels sont des alias qui pointent soit vers des répertoires situés sur le
serveur Web, soit vers une ressource partagée d'une autre station gérée par le même domaine
NT. La notion de répertoire virtuel peut s'apparenter à celle de lien symbolique sous UNIX
ou de raccourci sous Windows. Ces répertoires sont virtuellement positionnés sous la racine
du serveur alors qu'ils pointent ailleurs. La racine du serveur n'a pas changé.
Pour créer un répertoire virtuel sous "MS Management Console", il faut pointer sur le "Site
Web par défaut":
• Menu contextuel / Nouveau / Répertoire virtuel (alias)
• Le premier écran attend un nom d'alias pour le répertoire virtuel (figure 88) :
1.1. Il s'agit du nom du répertoire virtuel qui sera visualisé sous la
racine du serveur Web dans l'arborescence de la MMC
1.2. Tant que l'alias n'est pas défini, le champ suivant reste grisé donc
inaccessible
Figure 90
Figure 91
• Le troisième écran (figure 90) demande à ce que l'on reprécise, s'il y a lieu, les droits
posés sur le site : lecture, script, etc...
Figure 92
• L'accès "Exécuter" concerne les pages de script qui s'exécutent côté serveur (ASP,
PHP), ou les applications de type CGI ou ISAPI (dll)
Une fois que la configuration est terminée, l'utilitaire d'administration affiche dans le
volet de résultat le répertoire virtuel "tsml01" avec une icône spécifique (figure 91).
Figure 93
En conséquence, l'internaute visiteur (client), pour atteindre le site en question, doit faire
suivre l'adresse URL du site par le nom de ce répertoire précédé du caractère "/".
Exemple du répertoire virtuel "tsml01" : http://www.monsite.com/tsml01.
Remarques :
• La mise en oeuvre d'un répertoire virtuel s'effectue pareillement pour le service FTP.
• Les propriétés du répertoire virtuel peuvent être modifiés à postériori (figure 92).
Figure 94
Variante de gestion :
La création, suppression ou modification des identifiants d'un répertoire virtuel peuvent
être réalisés autrement que par l'intermédiaire des gestionnaires des services Internet ou
des services Web. Cela nécessite un préalable : avoir le service Web en activité.
Le bouton "Ajouter" ouvre la possibilité de définir plusieurs alias pour le même site.
Figure 95
Figure 96
L'icône "Avancées" nous ouvre un certain nombre d'options :
• Ajouter, modifier ou supprimer un répertoire virtuel
L'action du bouton "Ajouter" lance la fenêtre suivante (figure 94). Il reste à :
définir le nom du répertoire (alias),
aller chercher le site dans l'organisation physique de la station (parcourir),
changer les droits en fonction de la nature du site à publier (cocher
"Exécuter" pour les applications ou scripts CGI).
Conclusion
Ce chapitre se veut le plus complet possible au niveau des versions. Hormis la version Windows
XP, toutes les versions récentes sont mentionnées.
Cependant il manque des exemples d'application pour illustrer chaque possibilité offerte par les
propriétés des sites et les fonctionnalités de MMC. Celles réservées aux applications web seront
plutôt étudiées dans le module "HTML dynamique".
A priori, il manque encore quelques détails sur l'administration à distance ainsi qu'une étude de
la mise en œuvre des extensions de serveur FrontPage.
Il est néanmoins conseillé d'assimiler toutes les notions évoquées dans ce chapitre avant
d'aborder l'étude du serveur IIS ou un autre serveur.
L'objet du présent chapitre est consacré au serveur web "Internet Information Server" de
Microsoft (IIS). Ce serveur représente la plate-forme de publication la plus complète que puisse
proposer Microsoft actuellement.
Il fournit aussi bien un service Web, un service FTP mais aussi un service de News, des services
de gestion d'application Web, et un moteur de recherche.
Dans un premier temps, le document que voilà se bornera à étudier les services Web et FTP,
faciles à configurer.
Ce document doit être considéré non seulement comme une suite du chapitre 1 de présentation
des serveurs Web mais encore comme une suite du chapitre 2 consacré au serveur "Personal
Web Server" de Microsoft. Il ne reprend pas toutes les rubriques du dernier chapitre. Il se limite
à attirer l'attention du lecteur sur les différences existantes entre les deux versions.
Aussi, le document reste découpé pareillement au chapitre précédent : trois sections consacrées à
l'installation, l'administration et la publication.
La partie "administration" consiste à passer en revue les paramètres de configuration du serveur à
plusieurs niveaux.
La partie "publication" explique les différents procédés de mise en ligne des sites.
Cette version apporte un certain nombre d'améliorations par rapport aux versions précédentes. Le
serveur est compatible avec la version 1.1 du protocole HTTP qui offre la prise en charge des en-
têtes HTTP. Grâce aux en-têtes, il est possible d'héberger plusieurs sites intranet sur le même
serveur Windows NT. Ceci est primordial pour la plupart des fournisseurs de services Internet et
très utile pour les intranets d'entreprise.
1. Installation
1.1 Configuration requise
Avant d'installer, il est indispensable de se renseigner sur la configuration requise. Celle décrite
ci-dessous ne rencontre plus d'obstacles actuellement.
Composant matériel Configuration requise Recommandation
Mémoire vive (RAM) 32 Mo 64 à 128Mo
Espace disque disponible 50 Mo 200 Mo
Video 800x600 1024x768
Le serveur à lui tout seul utilise 90Mo de mémoire virtuelle.
Les performances peuvent être améliorées de plus de 25% si on l'installe sur une station bi-
processeur.
Le serveur sera de préférence installé sur un serveur NT autonôme dédié, et non sur un serveur
de contrôle de domaine.
Avant de lancer l'installation, il est obligatoire de se connecter en tant qu'administrateur de la
machine hôte. Le futur webmestre du serveur fait obligatoirement partie des administrateurs
locaux pour gérer finement les accès au serveur.
La description de l'installation qui suit se limite au seul cas du cédérom "Windows NT option
Pack" qui fournit la version 4.0.
Figure 97
Figure 98
Messages (figure 2) :
Si les deux composants prérequis sont effectivement présents, le(s deux) message(s) d'erreur qui
s'affiche(nt) néanmoins sont (est) à ignorer car le cédérom a été élaboré du temps du service
Pack 3 de Windows NT. Il ne reconnaît donc pas les services Pack ultérieurs.
1.3 Fonctionnalités
De même que sous PWS, le programme présente les différents services et fonctionnalités
(figure3). Il propose, en dehors des options communes aux deux versions PWS et IIS, des
options spécifiques à la version :
• Le serveur de news,
• Le relais de messagerie SMTP,
• La partie serveur du service de messagerie entre applications (Message Queue Server),
• Le moteur de recherche "Index Server",
• Un outil d'analyse de sites Web "Content Analyser",
• Un serveur de certificats d'authentification.
Figure 99
Le service Gopher a disparu de la version 2.0 et a été remplacé par le serveur d'indexation.
Figure 100
1.6 Chemins
En fonction des services choisis, le programme propose d’installer d'une part les racines de
publication des services Internet, et d'autre part les programmes.
Si l'installateur a coché "Index Server", le programme demande l'emplacement du catalogue
d’index. Celui-ci est mis par défaut sous le répertoire de publication : X:\Inetpub.
Une fois que l'installation proprement dite est configurée et réalisée, le moteur d'indexation des
pages du site construit son catalogue de fiches (ou d'index) à partir de la documentation en ligne
du serveur. Cette indexation fait que l'installation du serveur dure deux fois plus de temps que
celle de PWS.
Un autre exemple est celui du serveur de certificats. Le webmestre choisit à sa convenance
l'emplacement de ce dernier. Et coetera…
Un dernier exemple est celui du serveur de messages interapplicatif (Message Queue Server).
Pour configurer ce dernier, il faut préparer à l'avance les identifiants relationnels au moteur de
bases de données SQL Server situé sur le même serveur.
Figure 101
Une fois définis tous ces paramètres, le programme termine l'installation du serveur en 10
minutes s'il n'installe pas le moteur de recherche, en 20 minutes autrement. A l'issu, le
programme oblige à réamorcer le système d'exploitation.
Menu Démarrer
Etant donné que l'installation du serveur a été réalisée avec le cédérom "Windows NT option
Pack", l'ensemble des menus et sous-menus est disponible sous l'option portant le même nom
sous Windows NT. Les options rencontrées (figure 6) restent fonction des composants cochés
lors de l'installation.
Figure 102
Figure 103
Le menu principal "MS Internet Information Server" a remplaçé "Serveur Web Personnel". En
dessous, l'on trouve :
o Les menus secondaires « MS NNTP Service » (Serveur de News) et « MS SMTP
Service » (Relais SMTP)
Figure 104
Documentation en ligne
Figure 105
Pour ceux qui veulent en savoir plus sans quitter les menus, ils sont invités à consulter :
3. "Documentation en ligne" : http://localhost/iisHelp/iis/misc/default.asp.
L'accès via une adresse URL oblige l'utilisateur à démarrer le serveur avant.
2. "Notes de Publication" : C:\WINNT\Help\iis\htm\core\iirnlink.htm.
1.9 Architecture
Le serveur IIS est une application de type socket qui repose sur l'interface Winsock 2.0. Il
n'utilise pas le protocole UDP mais le protocole TCP.
En complément de la sécurité native au système de fichiers NTFS, il assure sa propre sécurité.
Services Applicatifs
Exchange Server
Processus Iis
Services Web
(inetinfo.exe) Connecteurs
SQL Server
Services Systèmes
WindowsNT
Figure 106
Processus InetInfo
Le processus Inetinfo contient tous les services sauf l'administration et le service d'indexation.
Comme services partagés, il gère :
• la métabase (base de données utilisée par le service Active Directory et remplaçant à
terme le registre)
Il existe un éditeur présent dans le kit de ressources du serveur : MetaEdit.
Les entrées importantes de la métabase sont les paramètres des sites web, ceux des
journaux, ceux des permissions posés sur les répertoires et fichiers, et enfin ceux
des protocoles.
• un ensemble d'unités élémentaires de traitement (ou threads) pour gérer les transactions
successives au cours d'une session utilisateur
• un cache interne (commun à l'ensemble des sites applicatifs pour les pages Web
dynamiques)
• la journalisation
• un agent SNMP (interrogé par les centres de gestion distants du réseau)
Connecteurs
Le terme de connecteur est un composant logiciel qui permet au serveur d'opérer sur un autre
service. Les connecteurs sont en fait des *.dll ISAPI qui peuvent être invoqués par des liens
(href=…).
La mise en œuvre du relais SMTP comme du serveur de certificats impose à l'administrateur de
connecter respectivement ces services avec un serveur de courrier Microsoft Exchange et un
serveur SGBDR comme Microsoft SQL Server.
Il ne faut pas confondre les connecteurs ISAPI avec les filtres ISAPI qui sont insérés entre le
serveur et les applications internes aux sites.
Services Applicatifs
Interface ISAPI
Les services applicatifs sont gérés par Web Application Manager ou WAM.
D'autres techniques applicatives sont évoquées dans la figure 11 :
• les SSI permettant comme le nom l'indique d'inclure des directives dans les pages web
statiques ou dynamiques,
• les fichiers aux extensions HTX permettant de mettre en forme les réponses aux requêtes
des clients,
• les techniques IDC (ancêtre des pilotes ODBC ou connecteurs aux bases de données) qui
génèrent les requêtes vers les bases de données ou vers le catalogue d'indexation (moteur
de recherche associé à Index Server).
2. Administration
2.1 Architecture
MMC
WSH
Figure 108
Le composant ADSI (Active Directory Service Interface) représente le nouvel interface
d'administration entre le serveur et les composants suivants :
• Le gestionnaire "Microsoft Management Console" (MMC) où diverses appliquettes
(snap-in) permettent de gérer les différents services,
• Le "Gestionnaire de services Internet (HTML)" via un interface web (HTMLA),
• Les scripts d'administrateurs gérés par le composant Windows Scripting Host.
Les scripts ne sont pas étudiés dans ce document. Ils peuvent être écrits en Vbscript ou en
Javascript. Ils s'exécutent depuis des lignes de commande, des fichiers de procédures ou des
pages HTML.
Le deuxième gestionnaire s'utilise uniquement dans le cadre d'une administration distante, alors
que le premier s'utilise nativement en local.
Le deuxième gestionnaire, limité aux seuls services Internet, sera présenté en fin de section. Il
donne les même possibilités que le premier gestionnaire dont il est question principalement.
Le lancement de Microsoft Management Console (MMC) ouvre une fenêtre composée de deux
volets. Le volet gauche est appelé volet de structure. Il affiche l'arborescence de l'espace de
noms, c'est-à-dire une liste hiérarchisée de tous les éléments pouvant être gérés par le
gestionnaire à un moment donné. Chaque élément (ou noeud) de l'arborescence représente un
type d'objet, de tâche ou de conteneur.
Figure 109
Lorsque un noeud est sélectionné dans l'espace de noms, le volet droit de la fenêtre, ou volet de
résultats, affiche les résultats de cette sélection.
Il existe plusieurs niveaux de gestion.
Pour gérer chaque niveau, nous disposons de plusieurs moyens : les menus, les icônes, les menus
déroulants, le menu contextuel à l'objet sélectionné correspondant au menu déroulant "Action".
Les niveaux ont été décrits suffisamment dans le chapitre "PWS". Pour plus de précision, il
convient de relire ce dernier.
Outre les deux « Site par défaut » propre à chaque service, l'on constate la présence d'un site
Web d'administration. Ce site est là pour faciliter l'administration à distance.
Figure 110
seulement le site par défaut mais surtout les serveurs virtuels (voir publication d'un nouveau
site).
Figure 111
La seule différence qui existe dans l’affichage des propriétés entre celles de la station et celles du
site réside dans la présence d'un onglet supplémentaire « Administration IIS 3.0 » (figure 16) au
niveau de la station. La légende de l'onglet suffit à expliquer son objectif.
La version IIS nous octroie, au niveau de la station comme au niveau des sites, un onglet
supplémentaire qui nous permet d'agir sur les opérateurs du serveur, en fonction du service
sélectionné avant. Cet onglet sera commenté dans la partie "Propriétés du site Web".
Figure 112
9. Site Web
Identification du Site Web
Quatre identifiants sont associés pour décrire le site et gérer son accès (figure 17) : un nom
de noeud au niveau de la MMC (Description) et trois éléments réseau (adresse IP, numéro de
port TCP, nom d'en-tête de l'hôte).
<Description>
• La portée du nom choisi pour décrire le site est limité au gestionnaire. Changer le nom
descriptif offre un intérêt pour distinguer les sites les uns des autres dans le cas de la
publication de plusieurs sites.
<Adresse IP>
• Deux valeurs possibles : une adresse IP assignée au site Web en question, sinon "toutes
non assignées par défaut".
L'assignation d'une adresse IP (ou nom de domaine) offre un intérêt dans la mesure où le
serveur publie plusieurs sites indépendants.
L'assignation d'une adresse IP à un site sous-entend que le nom du serveur (ou le nom
du site) soit configuré au sein du serveur DNS. Sinon, l'internaute doit connaître cette
adresse pour atteindre le site (seul http://@IP fonctionne).
L'assignation est plutôt utilisée dans le cas de sites multiples, ou dans le cas de
l'hébergement de plusieurs services Internet par la même station (une adresse par
service).
Figure 113
Remarques :
• Pour une carte réseau donnée, si le système d'exploitation permet de définir plusieurs
adresses IP (nombre illimité sous Windows 2000), alors le webmestre a la possibilité
d'assigner ou non une adresse par site hébergé pour différencier les accès aux sites.
• Il est possible de conserver deux fois les même identifiants si le webmestre prend la
précaution d'arrêter l'activité d'un des sites en question.
• En dehors du choix de l'adresse IP par site, il faut au niveau de la publication Internet,
décider du nom de domaine équivalent. Cette corrélation entre les deux doit être
mentionnée, soit dans les fichiers de configuration de la station hébergeant le serveur
(fichier hosts) pour des tests locaux, soit dans le fichier de zone adéquat du serveur DNS
de rattachement pour les clients distants.
<Port TCP>
• Le numéro de port TCP "80" est celui associé par défaut au protocole HTTP (service
Web).
• Le changement de numéro de port permet de privatiser l'accès à un site donné dans la
mesure où les internautes doivent connaître ce numéro pour l'atteindre. En pratique, le
nom de domaine ou l'adresse IP du site doit être suivi du caractère ":", puis du nouveau
numéro de port.
• Prenons l'exemple d'un numéro de port égal à 8080 (premier numéro choisi en dehors de
80). Le client doit compléter l'adresse URL ainsi : http://www.monsite.com:8080.
• Pour le webmestre, l'avantage d'un tel procédé lui permet de publier des sites officieux,
ou des sous sites officieux insérés au sein de sites officiels.
Figure 114
Restriction d'emploi :
Les services réseau les plus connus du monde IP utilisent un numéro de port entre 1 et
1024 (well-known ports). Ce sont des ports réservés que tout administrateur réseau
n'utilise pas en dehors de l'invocation du service associé. Au fur et à mesure des années,
le nombre de ces ports réservés est passé de 1024 à 6000.
Figure 115
Nombre de connexions
• Il est rappelé que le serveur IIS n'a pas de limitations connus en nombre de connectés.
Fichier journal
• Situé sous "\Winnt\System32\Logfiles", le fichier journal a pour but d'enregistrer les
connexions des internautes.
• En dehors des caractéristiques déjà décrites dans la version PWS, la version IIS nous
propose un quatrième format : le journal ODBC. Ce format est destiné aux suivis des
applications attaquant des bases de données.
10. Opérateurs
Ce nouvel onglet définit les opérateurs habilités à télégérer le serveur. Par défaut, seuls les
administrateurs locaux peuvent opérer sur le serveur.
Figure 116
11. Performances
Les cartouches "Réglage des performances" et "Configuration des connexions" ont déjà été
commentés dans le chapitre portant sur PWS.
Figure 117
La sélection de cette option permet de limiter la bande passante utilisée par les services
Web. La limitation de la bande passante est particulièrement utile si l'on possède une
carte réseau à plusieurs fonctions, telles que la messagerie électronique et les connexions
à distance. La quantité totale de bande passante dont on dispose dépend du type de carte
réseau installé. En règle générale, on commence par limiter la bande passante Web à
50 % de la bande passante de connexion, puis on ajuste vers le haut ou vers le bas selon
les besoins du système. La limitation de bande passante ne limite que la bande passante
utilisée par les fichiers HTML statiques.
Figure 118
Figure 119
Figure 120
Remarques Importantes :
• Lorsque sont définis les propriétés de sécurité d'un site spécifique, les mêmes
propriétés sont automatiquement définies pour tous les répertoires et fichiers
appartenant à ce site, sauf si les propriétés de sécurité des répertoires et des fichiers
sont redéfinies au niveau individuel.
• Si les permissions NTFS et les permissions du serveur Web sont en conflit, ce sont les
paramètres les plus restrictifs qui sont utilisés.
• Ainsi, les permissions refusant l'accès prévalent toujours sur celles autorisant l'accès.
Paramètres d'application
Le cartouche concerne à la fois l'exécution de pages de scripts côté serveur (pages ASP), et
d'applications à base de scripts CGI ou ISAPI.
• Exécuter (y compris le script) :
Ce bouton radio concerne les applications de toutes natures.
Il est conseillé de cocher « espace mémoire séparé » dans le cas d'une application
en cours d'élaboration pour ne pas planter le serveur en même temps que
l'application.
• Scripts :
Ce bouton radio, coché par défaut, concerne les pages de scripts ASP, IDC, etc…
Figure 121
Figure 122
Figure 123
Figure 124
Le troisième onglet "Débogage de l'application" (figure 28) est réservé au débogage de
l'application pendant son développement, ainsi que l'envoi de messages d'erreur une fois
la mise en service effectuée.
Répertoire de base
• La racine du serveur est par défaut "C:\Inetpub\wwwroot", mais il est possible de
changer la racine du serveur (voir parcourir) tout en restant sur la même machine.
• Le serveur offre aussi la possibilité de séparer les données de la localisation du
Serveur (impératif d’appartenir au même domaine NT ou groupe de travail Windows). Le
serveur accède au site à travers un répertoire partagé (figure 30).
Figure 125
Une fois que l'adresse du serveur et le nom de partage Web sont indiqués, il nous est
demandé de préciser le nom d'utilisateur et le mot de passe de connexion au partage en
question.
• Il est enfin possible pour le serveur d'aller chercher le site sur un autre serveur. Ce
procédé est utilisé souvent par des sites obligés de se délocaliser fréquemment. Le
serveur peut effectuer une redirection URL permanente (figure 31).
Figure 126
14. Document
Document par défaut
Le webmestre indique ici (figure 32) le nom de la page d’accueil du site (nom +
extension).
Remarques :
Le fichier "default.asp" représente la page par défaut des applications à bases de scripts
tels que forums de discussion.
Une page minimum doit être indiquée.
Seule la première indiquée est prise en compte.
Figure 127
Pied de page
Le serveur insère automatiquement un fichier au format HTML en bas de chaque
document Web. Le fichier de pied de page ne doit pas être un document HTML complet,
mais doit seulement inclure les balises HTML nécessaires pour la mise en forme de
l'apparence et de la fonction du contenu de votre pied de page.
Voici deux exemples d'application : un pied de page commun à toutes les pages d'un site
(ou une partie spécifique), des bandeaux publicitaires des services hébergeurs.
Figure 128
Figure 129
<Connexions anonymes>
Dans le cas de réseaux hétérogènes (UNIX, Windows, Mac ou autre), les
connexions anonymes sont obligatoires.
L'action du bouton "Modifier" nous rappelle le nom du compte utilisateur des
connxions anonymes (figure 35).
La synchronisation configurée par défaut doit être conservée.
Figure 130
Problème d'accès :
Si un utilisateur anonyme ne peut pas accéder au site, il faut contrôler les éléments
suivants :
• Le mot de passe de l'utilisateur anonyme doit être identique dans le
Gestionnaire des services Internet et dans le Gestionnaire des
utilisateurs.
• Dans le Gestionnaire des services Internet, sélectionnez le site
Web, le répertoire virtuel, répertoire ou fichier dont il faut contrôler la
connexion anonyme.
o Dans la feuille de propriétés Sécurité de fichier, cliquez sur
Modifier dans le champ Connexions anonymes et contrôle
d'authentification.
o Dans la boîte de dialogue Méthodes d'authentification,
vérifiez que la case à cocher Autoriser les connexions
anonymes est activée.
o Cliquez sur Modifier pour afficher le nom d'utilisateur et le
mot de passe employés lorsqu'un utilisateur anonyme se
connecte à votre site. Pour permettre à votre site Web de
synchroniser automatiquement vos paramètres de mot de passe
anonyme avec ceux de Windows NT, activez la case à cocher
Activer la synchronisation automatique de mot de passe (cette
dernière est activée par défaut pour toutes les ressources
autorisant les connexions anonymes).
• Vérifiez que l'utilisateur anonyme dispose des droits Ouvrir une
session localement dans le Gestionnaire des utilisateurs pour les
domaines de Windows NT :
o Dans la barre d'outils Microsoft Management Console
(MMC), démarrez le Gestionnaire des utilisateurs.
o Dans le Gestionnaire des utilisateurs, dans le menu
Stratégies cliquez sur Droits de l'utilisateur.
o Sélectionnez le droit Ouvrir une session localement et
assurez-vous que IUSR_(nom d'hôte) figure dans la liste.
<Authentification de base>
Figure 131
Figure 132
Figure 133
Une fois que les méthodes d'authentification ont été choisies (anonymes ou de base), que
les permissions aient été posées sur le site (onglet Répertoire de base des propriétés du
site), il reste à restreindre les permissions NTFS du répertoire abritant le site.
GL-prof Lire
b) connexions sécurisées
Les connexions peuvent être sécurisées grâce à la mise en oeuvre de la technique SSL.
Des organismes style Verisign fournissent le couple de clés nécessaires pour sécuriser le
serveur à l’égard d’Internet.
Le bouton "Gestionnaire de clés…" lance la même fenêtre que celle décrite dans le
gestionnaire de services.
Exemple de configuration : 1 site public, 1 site privé protégé par SSL sur le même
serveur.
Figure 134
Figure 135
• Une autre fenêtre s'affiche présentant les trois options : ordinateur, groupe
d'ordinateurs ou nom de domaine.
• Dans le cas où l'adresse IP de la station est inconnue, un bouton "Recherche DNS"
permet de retrouver l'adresse IP correspondante au nom de domaine indiqué dans
cette troisième fenêtre (figure 40).
Figure 136
• Cas particulier du Site d’Administrateur : l'accès est refusé à toutes les adresses sauf à
l'adresse locale "localhost" (http://127.0.0.1 :4476 par exemple).
Figure 137
Les différentes options de cet onglet concernent les en-têtes protocolaires HTTP. Le
webmestre peut ici configurer le comportement de l'ensemble des pages du site. Avant de
renvoyer la page désirée vers l'internaute, le serveur insère ces éléments protocolaires. Ils se
substituent aux balises META (module HTML statique) que le concepteur de site a inséré
dans l'ensemble de ses pages web.
Pour plus d'informations, il convient de se reporter au même paragraphe du chapitre
précédent.
Figure 138
Cet onglet permet d'accéder aux différents messages d'erreur renvoyés par le serveur Web.
La série 400 concerne les erreurs clients alors que la série 500 traite les erreurs côté serveur.
Remarques :
Une fois le site publié, il est possible à tout moment d'en modifier les propriétés. Pour cela, la
procédure conseillée est :
1. arrêter le site - 2. modifier - 3. relancer le site
Figure 139
Le numéro de port est important car il permet non seulement l'administration à distance, mais
aussi la consultation à distance de l'aide en ligne.
Figure 140
1. Site FTP
Surveillance
Le format de journal ODBC est présent !!!
2. Comptes de Sécurité
L'utilisateur Windows NT prévu pour autoriser les connexions anonymes est configuré lors
de l'installation. A priori, il n'y a plus lieu de modifier quoi que ce soit dans ce cartouche.
Opérateurs de site FTP
Un autre cartouche (figure 45) précise quels sont les opérateurs autorisés sur ce site. Ce
cartouche n'est activé qu'avec la version IIS. Plusieurs solutions s'offrent à l'administrateur
dont celui d'ajouter un utilisateur du domaine (déconseillé) par le bouton "Ajouter", ou
d'intégrer cet utilisateur dans le groupe des administrateurs décrits (conseillé).
Figure 141
3. Répertoire de base
Les droits en lecture suffisent pour télécharger des fichiers. Dans le cas de la dépose de
fichiers (upload), il faut ajouter les droits en écriture.
Figure 142
4. Messages
Figure 143
Trois messages peuvent être envoyés au client : le message de bienvenue, celui pour
Quitter, et le message d'erreur si le maximum de connexions est atteint.
5. Sécurité du Répertoire
Il est rappelé que seul le serveur IIS autorise le filtrage des accès aux sites. Par défaut, l'accès
est autorisé à toutes les stations. D'autres possibilités sont offertes :
• Soit l'accès est autorisé à toutes les stations, sauf celles dont l'adresse IP est indiquée,
o Il est possible de refuser l'accès à des adresses IP données, ou à un groupe
d'adresses IP (160.192.51.0 par exemple), ou à un domaine DNS complet
en précisant son nom,
• Soit le contraire : refuser l'accès à tous sauf...
Le filtrage par adresse IP est difficile à gérer sur Internet dans la mesure où les fournisseurs
d'accès mettent en œuvre le service DHCP à l'égard de leurs clients.
Voici un exemple où l'accès pour tous les ordinateurs est refusé exceptés ceux qui font partie
du réseau d'adresse 160.192.0.0.
Figure 144
dernier peut servir, en dehors de l'administration des sites, à héberger un serveur de test de ces
sites avant publication.
Examinons maintenant la procédure à suivre :
3. côté serveur :
o s’autoriser à accéder au site web d'administration en ajoutant son adresse
IP, s'autoriser en tant qu'opérateur de site
o repérer le n° port aléatoire du site d'administration pour y accéder depuis
son navigateur (http://serveur-web:n° port).
4. côté station distante :
o sous "MS Management Console", cliquer sur l'icône "ajouter ordinateur"
ou "connecter",
o remplir "\\nom_du_serveur" (nom de domaine ou alias DNS)
Figure 145
Le fait de cliquer dans le volet de structure sur l'icône du nouveau serveur à gérer (figure 49) fait
apparaître dans le volet de résultat les sites publiés par le serveur distant.
Figure 146
Figure 147
L'écran se découpe en trois cadres : une barre horizontale d'icônes permettant d'accéder à l'aide,
un menu vertical à gauche permettant de gérer les services dont l'arborescence est affichée dans
le troisième cadre.
La gestion des services comprend d'une part leur contrôle d'activité (arrêter, démarrer,
interrompre et reprendre), le paramétrage des caractéristiques (renommer, propriétés), la création
ou la suppression des sites.
Le choix de la création d'un site lance la fenêtre suivante.
Figure 148
L'activation des propriétés d'un site nous donne l'écran suivant. Le menu de gauche affiche
maintenant les intitulés des différents onglets de paramétrage.
Figure 149
Cette gestion peut s'effectuer aussi bien au niveau de l'ensemble des sites que d'un site désigné.
Le bas du menu de l'écran principal présente cette possibilité ainsi que celle de pouvoir
sauvegarder la configuration actuelle dans un fichier (ou de restaurer une ancienne, ou d'ouvrir
une autre configuration).
Figure 150
Un problème de droits d'accès au site Web d'administration fait que le serveur nous renvoie le
message d'erreur suivant.
Figure 151
3. Publication
Après avoir installé le serveur, et fait le tour des paramètres de configuration des sites Web et
FTP, jouons maintenant le rôle du webmestre, et notamment celui de l'hébergeur.
Organisation du Serveur
Supposons que le webmestre veuille dédier un premier site FTP au téléchargement libre des
logiciels et un deuxième à l'hébergement des sites des clients.
En n'utilisant qu'un identifiant réseau donné (adresse IP ou numéro de port) pour les sites
hébergés, il va falloir distinguer le client "A" du client "B". Pour cela, le webmestre va créer
autant de répertoires que de clients sous la racine du site FTP d'hébergement.
Lors de la validation de l'inscription, il enverra au client en plus des identifiants habituels (nom
d'utilisateur, mot de passe, adresse du serveur), le nom du répertoire de publication.
Au niveau du site FTP d'hébergement, le webmestre doit autoriser la dépose de fichiers sous le
répertoire de publication du client. Cela se traduit par l'autorisation d'écriture au niveau du
répertoire seul.
Avec IIS, pour la publication proprement dite, le webmestre "hébergeur" peut soit :
• répéter la technique des répertoires virtuels utilisés sous PWS pour pointer vers les
répertoires physiques des clients
• créer autant de sites que désirés (moyennant des identifiants réseau différents), dont la
racine pointe ou l'on veut sur le serveur (ou sur le réseau Intranet).
Création de Sites
Le serveur peut héberger autant de sites que de clients. En fonction du nombre d'identifiants
réseau mis en oeuvre, il peut différencier les multiples sites.
Il peut conserver, par exemple, sous la racine par défaut du serveur (Site FTP par défaut) le site
même de téléchargement de l'hébergeur.
Il peut, par exemple, délocaliser les sites clients. Pour cela, il va donc créer des sites selon la
procédure suivante :
Créer autant de répertoires physiques "ClientX" que de clients sur le lecteur dédié aux
clients (Perso(D:) par exemple),
Figure 152
Figure 153
Figure 154
Autoriser la dépose de fichiers pour chaque site FTP créé en cochant le droit en écriture
(figure59).
L'assistant de création de sites a terminé son travail, mais pas le webmestre. Pour assigner un
identifiant réseau distinct de celui du "Site FTP par défaut", il doit retourner dans
"Propriétés", onglet "Site FTP".
Figure 155
Cas d'une seule adresse IP :
S'il ne dispose que d'une seule adresse IP, le webmestre peut différencier ce nouveau site du
précédent par le changement de numéro de port. Cette mesure l'oblige à communiquer au client
cet identifiant personnalisé.
S'il n'utilise pas le numéro de port, il doit arrêter l'activité du "Site FTP par défaut" pour
démarrer celle du nouveau site.
Remarque :
L'emploi d'un serveur tel que "Internet Information Server" ne se justifie que si l'on
publie plusieurs sites en mettant en œuvre une plage d'identifiants réseau distincts.
Nouveau Site
La procédure, décrite dans le paragraphe concernant la publication FTP, reste la même pour les
sites Web. La séquence de paramètres à configurer est la suivante :
• Une étiquette de publication pour le gestionnaire de services
• Un lieu de publication (sous la racine du serveur ou ailleurs)
• Des droits posés sur le site
Comme pour le site FTP, en dehors de la création réalisée à l'aide de l'assistant graphique, le
webmestre doit retourner dans la fenêtre "Propriétés" pour y effectuer le changement
d'identifiant réseau : assignation d'une adresse IP, modification de numéro de port, nom
générique de site.
Il faut changer les identifiants réseau avant de démarrer l'activité de ce nouveau site.
Exemple d'utilisation d'une seule adresse IP pour publier deux sites avec noms génériques :
Le nom de domaine du serveur est "www.serveur.com", les noms génériques des deux sites
indiqués comme noms d'en-tête de l'hôte sont "www.example1.com" et "www.example2.com".
Les lignes qui suivent sont un extrait de l'en-tête protocolaire qui circule sur le réseau.
Remarques :
• Il faut avoir configuré au préalable les noms génériques de sites comme alias du nom de
domaine du serveur dans le serveur DNS de rattachement.
• La documentation en ligne (ou Kit de ressources) indique comment gérer les navigateurs
d'une génération antérieure aux versions 4 de Internet Explorer ou Netscape
• Dans la mesure où le nom de domaine est spécifié dans un certificat SSL, un seul nom
d'en-tête d'hôte par adresse IP peut être attribué. Cependant, plusieurs adresses IP et
plusieurs ports SSL peuvent être attribués à un même site Web.
L'objet de cette quatrième section est de présenter plus particulièrement le premier outil :
Content Analyser.
Même si le service n'a pas été sélectionné lors de l'installation globale, il est possible de le faire
après coup en utilisant toujours le même cédérom et toujours la même procédure. Il faut choisir
alors la méthode "Personnalisée" pour cocher ce service supplémentaire.
Figure 156
Figure 157
• un lien externe vers le site de Microsoft dédié à la présentation de la version non bridée
de "Site Server"
Figure 158
• une aide à l'emploi des utilitaires d'administration "Usage Import" et "Report Writer"
Figure 159
Figure 160
• un accès aux deux utilitaires "Report Writer" (figure 64) et "Usage Writer" (figure 65)
Figure 161
Figure 162
Si une carte a déjà été constituée, il nous demande de sélectionner un fichier à l'extension *.wmp
(figure 67).
Figure 163
Si une nouvelle carte est à constituer, alors il nous demande (figure 68):
• comment atteindre le site à analyser:
o via une adresse URL :
Il faut saisir l'adresse de la page d'accueil (figure 69).
Par défaut, le site entier est exploré. Par défaut aussi, une fois que la carte est
constituée, il génère un premier rapport.
Figure 164
Figure 165
Figure 166
Figure 167
Figure 168
Figure 169
En fonction de l’endroit cliqué sur l’arborescence, ou sur le graphe, ce dernier évolue en mettant
au centre la dernière page cliquée.
En dehors des deux zones, le logiciel dispose d'un menu, ainsi qu'un certain nombre d'icônes.
Comme d'habitude, les fonctionnalités cachées derrière les icônes sont déjà accessibles depuis le
menu.
Figure 170
Figure 171
Figure 172
Figure 173
Figure 174
Figure 175
Figure 176
Figure 177
Le deuxième menu "Carte" permet de :
• explorer une partie du site (figure 82),
• vérifier les liens (le plus important) (figure 83),
• modifier des options de cartographie (figure 84).
Figure 178
Figure 179
En ce qui concerne les menus, le plus intéressant est le menu "Outils". Le responsable du site
peut :
Figure 180
1) Générer des rapports sur le site… :
• L'action de cette option lance la fabrication d'une page Web comportant un tableau.
Celui-ci établit un rapport exhaustif sur les composants du site (figure 85).
• Il demande au préalable le nom du rapport et sa localisation (revoir création de carte au
lancement du logiciel).
Figure 181
2) Recherche Rapide :
• Cette option offre de multiples sous options (figure 84) : liens rompus, images sans ALT
(sans commentaires ou info-bulles), objets (pages) du site, objets hors site, objets
introuvables (erreur 404), objets non disponibles, objets non vérifiés, taille de chargement
supérieure à 32Ko.
• L'action d'une de ces options lance la réalisation d'une liste des objets sollicités sous
forme de tableau. Voici quelques exemples : objets du site (figure 86), taille de
chargement supérieure à 32Ko (figure 87).
Figure 182
Figure 183
Figure 184
Remarque :
Pour réafficher les deux arborescences initiales à l'issu des différents rapports, il faut passer par
le menu « Fenêtre ».
5. Index Server
5.1 Fonctionnalités
Le serveur IIS propose entre autres un moteur de recherche pour indexer les pages des sites
publiés. Ce moteur porte le nom d'Index Server puisqu'il s'agit en fait d'indexer les pages d'un
site, de constituer un catalogue de fiches à partir de chaque page de contenu.
Le serveur d'index est en mesure de gérer l'indexation de multiples sites publiés sur des
multiples serveurs au travers des répertoires virtuels. Il peut indexer les fichiers gérés par le
serveur de news.
Il supporte de nombreux formats de fichiers. Outre les formats spécifiques au monde Internet,
il est capable d'indexer des documents textes (*.txt) et des documents du Pack Office en
standard, des fichiers PDF moyennant l'adjonction de filtres, etc… Il supporte des documents
écrits dans des langages multiples.
La version proposée permet l'écriture de scripts ASP pour créer des requêtes complexes et
précises ainsi que pour la gestion des résultats de requête. Cette possibilité est combinée avec la
prise en charge de l'interrogation SQL.
Cette solution, nouvelle pour cette version, se superpose à celle des anciennes versions : requêtes
*.idq (Internet Data Query) sollicités par des formulaires *.htm, requêtes activant les réponses
dynamiques effectuées selon le modèle *.htx.
Enfin, et non des moindres, le serveur ne crée aucune charge d'administration car il peut
fonctionner 24 heures sur 24 sans surveillance. L'indexation, par défaut, fonctionne de manière
incrémentale. Il utilise les possibilités du système d'exploitation qui lui signale toute
modification de fichier.
Le serveur indexe les contenus des sites. Encore faut-il autoriser cette indexation au niveau
des sites ! Or il a été vu dans les propriétés des sites Web qu'il existait un droit particulier (onglet
"Répertoire de base") coché par défaut : "Indexer ce répertoire".
5.2 Installation
Même si le service n'a pas été sélectionné lors de l'installation globale, il est possible de le faire
après coup en utilisant toujours le même cédérom et toujours la même procédure.
Prérequis
Quelques prérequis sont à signaler. Un lecteur ayant le système de fichiers NTFS doit être
préféré pour des raisons de sécurité. En fonction du nombre de pages à indexer, il faut prévoir
des capacités en RAM en rapport, comme le suggère le tableau suivant.
Figure 185
Depuis le menu "Démarrer", il existe plusieurs entrées vers :
• un site d'exemples de formulaires d'accueil au moteur de recherche,
• une vers le gestionnaire du serveur sous MMC.
• une vers le gestionnaire du serveur via un interface Web,
Figure 186
Le choix de la première entrée (figure 90) permet au webmestre débutant de parcourir et choisir
le modèle de formulaire d'entrée au moteur.
Il est possible d'enchaîner plusieurs formulaires. À partir de l'exemple de formulaire de recherche
ASP, on peut sélectionner, par exemple, le formulaire "Exemple ASP avancé".
Le menu de gauche suggère au webmestre un certain nombre de prérequis en matière de requêtes
SQL ou de scripts ASP. De même, il faut comprendre le fonctionnement du service avant
d'adapter le moteur fourni à ses besoins.
Outre le menu "Démarrer", il est possible de gérer ce service depuis "Panneau de Configuration /
Services" grâce à la ligne "Index de Contenu".
5.3 Fonctionnement
Dans cette partie, trois explications sont données pour aider le webmestre débutant dans
l'utilisation de ce service :
• d'abord expliquer schématiquement le fonctionnement du processus d'indexation,
• puis expliquer schématiquement l'exécution d'une requête,
• terminer par dire quelques mots sur la sécurité.
La partie "Catalogue d'Index" permettra au webmestre d'intégrer dans les sites hébergés
l'ensemble du service.
Processus d'indexation
Corpus
E
T
/virtual_1
E Filtres Séparateur
N de de mots
/virtual_2
D Contenu
U
/virtual_3
E
Index
Catalogue Index Normalisateur
Index
Figure 187
Le catalogue créé peut donc gérer plusieurs sites au travers de répertoires virtuels.
L'ensemble des fichiers indexés représente l'étendue du catalogue. L'ensemble des sites indexés
s'appelle le corpus. Le schéma ci-dessous explique sommairement le processus d'indexation.
Les filtres sont adaptés aux formats des fichiers indexés.
Le normalisateur trie les mots significatifs; il rejette les articles, les pronoms, etc…
Les différents index constitués sont fusionnés normalement la nuit, par haute compression des
données.
L'indexation ou l'enregistrement des mots et propriétés extraits des fichiers est réalisée via le
processus CiDaemon dans des index (structures de données).
Les mots et propriétés extraits d'un document apparaissent d'abord dans une liste de mots (en
mémoire), puis sont déplacés vers un index secondaire, avant d'aboutir dans un index principal.
Il existe plusieurs paramètres de registre qui contrôlent le comportement des listes de mots. Le
paramètre MaxWordLists correspond au nombre seuil de listes de mots avant fusionnement pour
former un index secondaire.
Un index principal est créé via une fusion principale qui fusionne tous les index secondaires. La
fusion permet non seulement d'éliminer les données redondantes mais aussi de libérer des
ressources.
Un index persistant est un index stocké sur disque. Le nombre total d'index persistants (index
secondaires et index principal) d'un catalogue ne peut pas dépasser le nombre 255.
Figure 188
SERVEUR
SERVEURIIS
IIS
CLIENT
CLIENT
Query.idq
Recherche sur
Query.htm Index Server
Formulaire HTML
Catalog.wci
Index
Results.htm
Query.htx
1. news.htm
2. asp.doc News.htm
3. verisign.ppt Asp.doc
Verisign.ppt
Dispositifs de sécurité
L'accès aux catalogues est restreint aux administrateurs et aux services système.
Les permissions d'accès définissent quels fichiers doivent être retournés au client.
Si le corpus est stocké sur un volume NTFS local, Index Server va respecter toutes les
restrictions de sécurité et appliquer les listes de contrôle d'accès (ACL). Dans un ensemble de
résultats, l'utilisateur ne voit jamais la référence d'un document si la liste de contrôle d'accès
associée à cet objet interdit au client l'accès en lecture. La prise en compte des listes de contrôle
d'accès concernant les répertoires virtuels distants IIS est déterminée par le mode de sécurité IIS
sur ces répertoires virtuels distants.
L'authentification peut être utilisée pour identifier et contrôler la diffusion des documents.
par ajoût d'un répertoire virtuel dans le cas où le "guichetier" utilisé est
resté localisé sous Inetpub
4. tester le moteur avant livraison du service
Catalogue d'Indexation
La première phase traite de la constitution du catalogue indexé sur les pages du site.
Le premier site publié voit son catalogue placé sous le répertoire de publication par défaut (sous
Inetpub). Sous MMC, le catalogue indexe par défaut "le site Web par défaut". Les deux figures
suivantes indiquent la procédure !
Figure 189
Attention : Le serveur d'indexation interdit la constitution d'un nouveau catalogue sous Inetpub.
Si le catalogue existant ne fait qu'indexer les fichiers du serveur, on peut le supprimer sans
remords.
Figure 190
Rappel : pour un gros site, le volume d'un catalogue peut représenter jusqu'à 40% du volume
du site.
3. Il faut maintenant sélectionner le catalogue ainsi créé pour accéder à ses propriétés (clic
droit) afin de terminer le paramétrage préalable à la constitution du catalogue.
Figure 191
Figure 192
En dehors du "Site Web par défaut" (site principal), apparait dans le menu
déroulant la liste des autres sites publiés (ou serveurs virtuels). Un site publié par
répertoire virtuel ne peut disposer de son propre catalogue. Il faut dans ce cas,
étendre l'indexation d'un catalogue existant au répertoire virtuel en question.
Comme le suggère la copie d'écran (figure 96), si le site propose le service de
news, il est possible d'indexer les fichiers de ce service.
Figure 193
onglet Génération :
Cet onglet permet de paramétrer les réponses à donner aux requêtes : nombre de
caractères par enregistrement, filtrage des fichiers ayant des extensions inconnues,
génération de caractérisations.
5. Une fois le paramétrage terminé, il faut valider les changements.
Figure 194
6. Une fois les changements validés, il suffit de redémarrer le service "Index Server" pour
que le catalogue se constitue. On peut surveiller l’activité du serveur, à l'aide du
gestionnaire MMC comme à l'aide de l’explorateur, et mesurer le volume progressif du
dossier « catalog.wci ».
7. Le moteur met à jour les différents éléments du catalogue comme le suggère les dates des
fichiers (figure 99).
Figure 195
Ajoût de répertoires
Figure 196
Imaginons que le catalogue du site soit déjà constitué ! Il s'agit de faire prendre en compte ce
nouveau répertoire publié au niveau du catalogue d'index. Peu importe ou ce sous site est
publié !
Le menu contextuel du catalogue, comme celui du dossier "Répertoires", permet d'ajouter un
répertoire à l'étendue de ce catalogue. La boîte de dialogue "figure 101" sollicite plusieurs
paramètres.
• En premier, saisir le chemin d'accès au répertoire !
• Sinon, en face du champ "Alias (UNC)", taper le nom du serveur et le chemin d'accès de
ce répertoire. Par exemple : \\nomserveur\répertoire_alias
Le texte tapé dans cette zone est renvoyé au client exécutant une requête sur ce répertoire.
Dans le cartouche "Informations de compte", si le nom de serveur saisi dans la zone
"Alias (UNC)" est différent de celui de l'ordinateur local, il faut de plus indiquer ici les
identifiants de connexion à l'ordinateur distant.
• Dans le cartouche "Type", si le répertoire contient un sous-répertoire qui n'est pas à
indexer, il faut cocher "Exclure".
Figure 197
Moteur de Recherche
Il faut distinguer les différents cas de figure :
privatiser les éléments constitutifs du "guichetier" d'un nouveau site dans
le cas de sites multiples,
modifier les éléments du "guichetier" par défaut dans le cas d'un site
unique,
normalement rien si le catalogue existant a été simplement élargi au
nouveau répertoire.
Si la case à cocher "Suivi des racines virtuelles" est activée, il n'y a rien à faire pour le deuxième
et troisième cas ci-dessus. Dans le cas contraire, il suffit d'ajoûter une valeur à un paramètre
interne au fichier de recherche (query.idq ou query.asp). Voici un exemple de fichier query.idq
où l'étendue de la recherche est élargie au nouveau répertoire (virtuel ou non) intitulé
"SitePerso":
CiScope=/,/SitePerso
L'étendue par défaut englobe l'ensemble du répertoire de publication principal sous wwwroot,
d'où la valeur "/" en premier.
L'étude du premier cas oblige à étudier deux techniques applicatives différentes : celle des trois
fichiers *.htm *.idq *.htx, et celle de l'unique fichier *.asp. Les deux techniques restent
propriétaires à l'environnement Microsoft. La première est désormais délaissée au profit de la
seconde. La seconde n'est autre qu'un exercice appliqué de la technologie ASP.
En conséquence, cette étude n'a pas sa place dans ce chapitre consacré aux services IIS. Elle
pourrait prendre place au sein d'un module "Applications Web : exemples". Néanmoins, la
documentation en ligne donne suffisamment d'indications pour privatiser le service.
Pour ceux qui veulent aller plus loin dans l'élaboration des formulaires de recherche, les
approfondissements restent possibles en consultant la documentation en ligne ou le livre
accompagnant le kit de ressources du serveur IIS.
5.5 Administration
L'administration d'Index Server passe d'abord par l'utilisation des gestionnaires du service. Ceci
peut s'effectuer en local sous le gestionnaire des services Internet (MMC) ou à distance via un
interface web.
Figure 198
La sélection du serveur à gauche fait apparaître à droite dans le volet de résultat les différents
catalogues gérés par le service (figure 106).
La sélection d'un catalogue fait apparaître deux dossiers portant respectivement les noms de
"répertoires" et "propriétés" (figure 102).
Ces deux répertoires virtuels permettent de gérer d'une part plusieurs sites ou sous sites à travers
le même catalogue et d'autre part de gérer finement la portée des requêtes, ainsi que la sécurité.
Figure 199
Le choix de la troisième entrée du menu (figure 103) nous permet de découvrir l'interface web
d'administration à distance. L'accès de ce service est réservé au seul administrateur du serveur,
ce qui explique l'adresse visée. En effet, le chemin indiqué derrière le nom de domaine montre
bien que l'on accède aux composants d'administration du serveur. Aussi, pour atteindre ce
service, il faut viser le numéro de port (ici 1234) du site web d'administration du serveur IIS.
Cet interface affiche en page d'accueil des statistiques résultats du choix du premier menu de
gauche. La page nous expose d'abord des statistiques de fonctionnement du service (cache).
Effectivement, le service gère un cache interne où il stocke temporairement les requêtes et
réponses des internautes.
Dans un deuxième temps, il nous renseigne sur le catalogue d'indexation. Un bouton, non visible
sur la copie d'écran, nous permet d'actualiser si besoin ce tableau.
Le menu de gauche "documents non filtrés" offre la possibilité de se remémorer quels sont les
documents des catalogues constitués non filtrés à ce jour (figure 104) s'il y en a.
Figure 200
Le menu "données de la racine virtuelle" permet au webmestre ou propriétaire du site de lancer
des analyses de différents types sur les catalogues en service (figure 105).
Figure 201
Le menu "fusionner l'index" (figure 103) permet enfin de fusionner les différents index d'un
catalogue si besoin.
Mais la meilleure façon de gérer ce service, pour le webmestre, est d'utiliser la version du
gestionnaire des services Internet (Microsoft Management Console) accessible depuis le menu
de IIS.
Figure 202
Si le service "Index Server sur…" n'apparaît pas d'emblée dans les services gérés, il faut alors
appliquer la procédure "Ajout Composant Logiciel enfichable" depuis le menu du gestionnaire
(voir chapitre sur le serveur PWS). La seule question particulière posée demande s'il faut
installer le composant sur un ordinateur local ou distant.
Remarque : le service d'Index Server, localisé à côté d'un serveur IIS, peut en plus, indexer des
sites publiés par d'autres serveurs style PWS, d'où la présence de la case à cocher "Indexer ce
répertoire" dans l'onglet "Répertoire de base" des propriétés du site web d'un serveur PWS.
La figure ci-dessus montre la présence dans le volet de résultats de deux catalogues. Ils ont
chacun un nom, un emplacement. Ce sont les deux principaux paramètres à décider lors de la
constitution du nouveau catalogue. Il faut remarquer le volume du catalogue : en Mo, en nombre
de documents indexés, etc…
Conclusion
Ce document, déjà bien consistant, ne permet pas de tout dire sur le serveur IIS. Bien d'autres
composants ne sont pas évoqués dans ce document et ne le seront pas ailleurs dans l'état actuel
des choses.
Avant d'étudier les serveurs de transactions (MTS) ou serveurs de messagerie inter applicatifs
(MQS), il conviendrait dans un premier temps de pousser des investigations dans trois domaines:
• les extensions de serveur FrontPage permettant au client de publier son site sur le serveur,
• le serveur de certificats s'appuyant sur la technologie SSL permettant de sécuriser les
transactions,
• l'accès distant aux ressources du serveur par RAS.
Dans un deuxième temps, une fois que l'étude des applications Web sera mieux définie, une fois
que les plateformes adéquates seront en place, il sera possible de décrire plus en détail les deux
services évoqués ci-dessus.
Sans aller aussi loin, l'administration poussée du serveur Internet poussera le lecteur à consulter
des livres traitant du sujet. Il pourra ainsi écrire des scripts ASP ou WSH ou des ISAPI pour
peaufiner l'administration. En dehors de la métabase d'Active Directory Service, certains
paramètres fins restent encore configurés en dur dans le registre.
Introduction
L'objet du présent chapitre est consacré au serveur web Apache du consortium du même nom
"Apache Software Foundation" (www.apache.org). Ce serveur a l'énorme avantage d'être
gratuit et donc téléchargéable depuis le site mentionné précédemment. Il présente aussi
l'avantage d'être multiplateformes et de fournir aussi bien une version Windows qu'une version
Linux.
Le document s'adresse aux webmestres déjà coutumiers des serveurs web. Il suppose la lecture
préalable des chapitres consacrés aux serveurs Microsoft. Les parties consacrées à UNIX
supposent des pré requis dans ce domaine pour assurer une meilleure compréhension.
Le document est découpé en cinq sections : présentation, installation, administration, publication
et protection du site.
La section "Administration" consiste à passer en revue les paramètres de configuration du
serveur à plusieurs niveaux. La section "Publication" explique les différents procédés de mise en
ligne des sites. La section "Protection du site" donne des indications complémentaires sur le
sujet.
Ce chapitre s'appuie sur une documentation bilingue (français et anglais) de la version 1.3.20.
Les copies d'écran proviennent de cette version.
1. Présentation
1.1 Origine
L'ancêtre immédiat du serveur Apache fut conçu par le NCSA (National Center for
Supercomputing Applications), à l'université de l'Illinois. La version 1.0 de Apache était
disponible le 1 décembre 1995.
Le serveur Apache tient son nom du fait que le code source disponible du serveur a été corrigé
depuis (patches). Certains pensent que le jeu de mot " a patch " est original. Il faut comprendre
que le serveur Apache, écrit par une équipe de volontaires, est resté gratuit pour ses utilisateurs.
Le serveur Apache était originellement et exclusivement destiné aux systèmes UNIX.
1.2 Particularités
Les principales différences entre le serveur libre Apache et les serveurs commerciaux peuvent se
résumer en deux points :
• Apache se configure principalement par modifications de fichiers textes même s'il
existe des utilitaires graphiques, voire des applications web. Ce type de configuration
reste le plus puissant. On peut donc en conclure qu'Apache est le plus configurable des
serveurs HTTP.
• Il permet d'activer très aisément des extensions (modules), sans recompiler le serveur
selon les besoins des utilisateurs. Ces modules permettent d'ajouter des fonctionnalités
ne serait-ce que le module Perl ou PHP, ou MySQL, etc…
1.3 Emploi
1.1.1.1. Plate-forme Windows
Son emploi dans l'environnement Windows amène quelques restrictions.
Le serveur Apache n'est pas fait pour oeuvrer comme serveur Web de production dans les
environnements grand public tels que Windows 95, 98, ou ME (Edition Millénium). Le serveur
Apache tourne sur ces environnements à des fins de test, de développement. Seuls doivent être
pris en considération les environnements Windows NT 4.0 ou 2000, permettant grâce au système
de fichiers NTFS l'administration de la sécurité côté visiteurs.
De plus, la version Windows se révèle légèrement moins stable que la version UNIX.
1.4 Fonctionnement
Le serveur Apache est destiné à fonctionner sous un système d'exploitation multitâches.
Une fois lancé, le serveur Apache écoute les ports TCP des adresses IP indiquées dans son
fichier de configuration principal httpd.conf. Quand une requête HTTP se présente sur un port
valide, le serveur Apache la reçoit et en analyse les en-têtes. Il applique alors les règles
paramétrées (ou directives) contenues dans le fichier httpd.conf.
2. Installation
Aussi bien sous l'environnement Windows que sous l'environnement Unix, installer le serveur
Apache ne pose pas de réelle difficulté.
Sous Windows, la version binaire est livrée avec un programme d'installation identique pour la
version NT et la version 95 (ou 98). Les sources sont également disponibles.
Les couches protocolaires TCP/IP doivent être installés. L'API "Winsock 2" est nécessaire à
partir de la version 1.3.7 et des suivantes.
Des détails de la dernière version peuvent être trouvés sur le site d'adresse httpd.apache.org.
Le consortium fournit un exécutable d'auto-installation du style apache_1.3.20-win32-no_src-
r2.msi. Cette version, comme le nom l'indique (no_src), ne contient pas les sources. Le logiciel
Microsoft Installer version 1.10 doit être installé sur le PC avant l'installation.
1.1.1.4. Installation
Figure 203
Une fois passé l'écran de bienvenue (figure 1), le deuxième demande d'accepter les contrats de la
licence. Si l'on accepte, le bouton "Next" cesse d'être grisé.
Le troisième écran (figure 2) affiche le contrat entier de la licence.
Le quatrième écran (figure 3) demande en premier le nom du domaine DNS d'appartenance du
serveur. Le logiciel d'installation récupère en fait le nom de domaine auquel appartient la station.
Dans le cas d'un organisme des armées, il affiche le nom de domaine de l'organisme. Dans le cas
d'une connexion Internet personnelle, il affiche celui du fournisseur d'accès.
Dans un deuxième champ, il propose comme futur nom du serveur le nom complet de la station
(Fully Qualified Domain Name) ou à défaut s'inspire de l'adresse de courriel de celui qui installe.
Dans un troisième champ, il sollicite le nom du webmestre du serveur ou son administrateur. S'il
s'agit d'une installation personnelle ou à titre d'essai, il est conseillé d'indiquer ici son adresse de
courriel.
Figure 204
Figure 205
Une série de deux boutons radio impose au webmestre un choix important :
• soit considérer le serveur comme un service parmi d'autres,
• soit le démarrer manuellement en mode console ou depuis le menu "Démarrer".
Figure 206
Figure 207
Le dernier écran indique que l'installation est terminée.
Figure 208
La figure 6 montre les sous-menus de la version du serveur lancé en mode manuel : option
"Start Apache in Console".
La figure 7 correspond au serveur Apache installé en tant que service : sous-menu "Control
Apache Server".
Figure 209
Figure 210
Figure 211
• une option "Start Apache in Console" dans le cas d'une installation avec démarrage
manuel
Le choix de cette option lance une console MS-DOS (figure 9) qui reste active
jusqu'à l'arrêt du serveur Apache.
• un sous-menu "Control Apache Server" dans le cas où le serveur serait géré comme un
service, permettant de démarrer (Start), d'arrêter (Stop) ou de redémarrer le serveur après
modification du fichier de configuration (Restart)
Le serveur fonctionne alors sans fenêtre active.
1.1.1.7. Documentation
La documentation au format HTML présente sous le dossier "htdocs/manual/" est accessible
depuis son navigateur en saisissant l'adresse de la figure 11.
La documentation la plus actualisée est accessible sur le site httpd.apache.org/docs/ : elle reste
bilingue.
Figure 213
1.1.1.8. Lancement
Une précaution doit être prise avant de démarrer le serveur Apache. Il faut arrêter tout autre
serveur Web afin d'éviter un conflit sur le port n°80.
Si le lancement échoue, la commande "netstat -an" permet de renseigner sur les numéros de ports
utilisés par la station.
Quand le serveur est invoqué depuis le menu Démarrer, dans le mode console, il est lancé sans
arguments. Il lit alors de préférence les entrées de registre. En effet, durant l'installation, une clé
de registre a été installée sous Windows NT, par exemple :
HKEY_LOCAL_MACHINE\Software\Apache Group\Apache\1.3.13\ServerRoot
Pour arrêter le serveur, on peut dans le menu "Démarrer" soit sélectionner l'option "Shutdown
Apache console" (non disponible avant la version 1.3.4), ou lancer des commandes dans la
console du serveur. En effet, depuis la version 1.3.13, on est assuré de pouvoir utiliser les
touches Ctrl+C or Ctrl+Break (Arrêt Défil) pour arrêter le serveur.
Il existe aussi la possibilité de fermer la fenêtre console soit en pressant la croix en haut à droite,
soit en sélectionnant dans le menu système l'option "Fermeture" pour arrêter le serveur.
Il reste encore la possibilité de le stopper depuis une autre console par la commande:
• "apache -k shutdown", puis le redémarrer par "apache -k restart".
Pour tester le serveur, il suffit d'essayer l'adresse locale : http://localhost. Une page d'accueil est
publiée par avance (figure 11). Cette page contient un lien vers la page d'accueil du site
documenté principalement en anglais.
Une fois le serveur lancé, il crée sous le dossier "log" un fichier "httpd.pid" contenant
l'identifiant du processus associé au serveur.
Figure 214
Les directives qui acceptent des noms de fichiers comme arguments doivent utiliser les
caractères "slash" ("/"), et non les "backslashs" ("\") pour respecter les normes Internet, ainsi que
les lettres des lecteurs logiques (par exemple : "C:").
La version Apache pour Windows a la capacité de charger des modules, sans recompiler le
serveur. Pour les activer, il suffit de décommenter la directive LoadModule adéquate du fichier
de configuration httpd.conf.
La série des versions 1.3 implémente les appels synchrones. Ceci pose un énorme problème pour
les auteurs de scripts CGI qui ne voient pas les résultats des traitements envoyés immédiatement
au navigateur (résultats non temporisés dans une mémoire tampon). Ceci ne correspond pas au
comportement attendu, mais reflète un effet de bord des ports Windows. La version Apache 2.0
essaie de palier le problème en implémentant un comportement asynchrone.
Le serveur Apache peut aussi charger les extensions ISAPI (et non les filtres ISAPI). La
procédure est mieux documentée désormais.
La lecture du fichier archive crée le répertoire apache_1.3.20 et extrait les fichiers dans ce
répertoire.
Il est conseillé de lire les fichiers README, README.configure et INSTALL avant de
procéder à la compilation et à l’installation du logiciel.
La configuration initiale du logiciel consiste à exécuter le script "./configure" sous le répertoire
cité ci-dessus. Ce script, lancé sans options (attention au point qui précède le "/"), assure une
configuration par défaut. Pour personnaliser cette configuration, il faut exécuter le script
configure avec les arguments disponibles.
Les principales options de configuration, affichées avec "./configure --help" sont :
Option Signification
--layout affiche les répertoires d’installation et de fonctionnement.
--verbose affiche plus de messages lors de la configuration
--quiet n’affiche aucun message lors de la configuration
--prefix=répertoire chemin d’installation du logiciel
--enable-module=nom valide le module dont le nom est donné
--disable-module=nom dévalide le module dont le nom est donné
--add-module=fichier ajoute le fichier dans le répertoire des modules, et dans le fichier de
configuration et valide le module
--enable-suexec valide l’utilisation de suexec
Il est possible à ce moment-là d'assortir la commande d'un certain nombre d'options en fonction
de la politique suivie par celui qui installe.
Soit il choisit d'intégrer au moteur du serveur d'autres modules (plug-in) tels que l'interprétation
de scripts Perl ou PHP, soit il choisit de les laisser en dehors du moteur et donc de les charger (en
tant que modules DSO) selon ses besoins en modifiant une ligne du fichier de configuration
"httpd.conf".
Pour le second choix, il faut s'assurer que la configuration par défaut inclue le module
"mod_so.c". S'il effectue le premier choix, il lance des commandes du style :
• ./configure --enable-module=so
L'option intègre le module mod_so.c qui permettra justement d'utiliser les modules
externes avec le serveur Apache.
Voici la liste des modules du serveur Apache de la version 1.3.19 tels qu'ils sont présentés dans
le fichier d'installation:
Environment creation
(+) mod_env .......…….. Set environment variables for CGI/SSI scripts
(+) mod_setenvif ...…... Set environment variables based on HTTP headers
(-) mod_unique_id .….. Generate unique identifiers for request Content type decisions
(+) mod_mime ......…... Content type/encoding determination (configured)
(-) mod_mime_magic .. Content type/encoding determination (automatic)
(+) mod_negotiation … Content selection based on the HTTP Accept* headers
URL mapping
(+) mod_alias .....……. Simple URL translation and redirection
(-) mod_rewrite ....…... Advanced URL translation and redirection
(+) mod_userdir ....….. Selection of resource directories by username
(-) mod_speling ...…... Correction of misspelled URLs
Directory Handling
deuxième contrainte, il faut savoir que les différents empaquetages s'installent dans un certain
ordre : apache-common-… d'abord.
Pour effectuer simplement une mise à jour de version du serveur précédent, alors la commande
suivante suffit : rpm –Uvh apache-… (U comme update)
Figure 215
Figure 216
Il existe un script "apache" assurant le roulement des fichiers log sous
/etc/logrotate.d/.
o Le répertoire extramodules (optionnel), lien symbolique vers le répertoire
/usr/lib/apache-extramodules/, contient les modules additionnels php ou ssl
o Le répertoire modules contient un certain nombre de modules optionnels (ou
plug-in) qui peuvent être adjoints au serveur. En fait, sous /etc/httpd, il s'agit d'un
lien symbolique pointant vers /usr/lib/apache.
o Le répertoire lib est un lien symbolique vers le répertoire /usr/lib/.
• Le script de démarrage apachectl, situé sous /usr/sbin, est en fait lié symboliquement au
véritable script httpd sous /etc/rc.d/init.d.
• Le serveur lui-même dont la localisation varie selon les versions successives du serveur :
ici sous /usr/sbin.
3. Administration
Bien que des logiciels tels que Webmin sous Linux existent pour configurer graphiquement le
serveur Apache, nous conseillons au lecteur dans le premiers temps de modifier les fichiers du
répertoire conf à l'aide d'éditeurs basiques (Bloc-notes sous Windows, Vi sous UNIX). Quelle
que soit la plateforme, quelle que soit la version, ces fichiers comportent pratiquement les
mêmes paramètres.
Néanmoins, l'annexe du chapitre donne deux exemples de configuration graphique.
Depuis la version 1.3.14, le principal fichier de configuration est le fichier httpd.conf. Celui-ci
contient désormais l'ensemble des paramètres dont il est fait l'inventaire dans la partie "3.1
Standard".
Parmi les directives, il en existe de deux sortes : les directives qui concernent l'ensemble du
serveur ou des ressources publiées, les directives qui ne s'appliquent qu'à un site donné
(<VirtualHost>), une adresse URL donnée (<Location>), un répertoire (<Directory>) ou un
fichier donné (<Files>). Ces dernières sont insérées dans des blocs de directives portant le nom
de directives de blocs ou conteneurs. Ces blocs commencent comme des balises HTML et se
terminent tels quels : </VirtualHost>.
Lors de la première configuration, il est conseillé de ne changer que les valeurs des directives
indispensables au fonctionnement du serveur ainsi qu'à la publication des sites. Le programme
d'installation met en place des fichiers par défaut et donc des valeurs par défaut qu'il convient de
ne pas modifier sans raison valable.
Dès que l'on veut tester une ligne d'un fichier de configuration, il peut être judicieux de dupliquer
cette ligne, de mettre en commentaire la ligne originale, avant de modifier la ligne dupliquée.
La section "Administration" a été découpée comme suit pour des raisons pédagogiques. Dans un
premier paragraphe, on expose les directives communes aux versions UNIX et Windows, puis
celles spécifiques à Windows, et enfin celles spécifiques à UNIX.
Pour ceux qui ne cherchent qu'à publier leurs sites sans vouloir faire le tour exhaustif des
principaux paramètres du fichier de configuration, ils peuvent sauter à la section "Publication".
3.1 Standard
Le fichier de configuration, par défaut, garde certaines directives seulement applicables dans le
monde UNIX, ou difficilement applicable, ou sans intérêts. Ce qui suit a été expurgé, à priori,
des directives spécifiques au monde UNIX (voir partie adéquate), ainsi que de quelques
directives d'importance minime.
ServerType standalone
Le serveur fonctionne en général de manière autonome, donc en mode "standalone". Il
existe un autre mode "inetd", valide uniquement sous UNIX, lui permettant d'être
patronné par le super service réseau "inetd". Dans ce cas, c'est le processus démon inetd
qui attendra les connexions et lancera le serveur Apache. En temps normal, il n'existe
aucune raison d'adopter ce mode.
# Répertoire de localisation des fichiers de configuration et fichiers journaux du serveur
ServerRoot "C:/Program Files/Apache Group/Apache"
Cette directive est importante car elle désigne l'endroit où se trouvent les répertoires conf
et log. Elle constitue l'adresse URL de base pour un certain nombre de directives qui
suivent. Il ne faut pas confondre cette directive avec la racine de publication par défaut
ou DocumentRoot.
#ResourceConfig conf/srm.conf
#AccessConfig conf/access.conf
Il reste possible au webmestre pour des raisons qui l'honorent d'activer les anciens
fichiers de configuration.
# Le temps limite en seconde d'une transaction HTTP (requête et réponse) au bout duquel
# le serveur enverra un message.
Timeout 300
# Autorise les navigateurs à rendre les connexions actives ou persistantes (off pour
# désactiver).
KeepAlive On
Cela revient en fait à activer l'emploi du protocole HTTP1.1 à travers une de ses
fonctionnalités.
# Nombre de connexions persistentes pouvant rester actives simultanément (0 pour
# illimité).
MaxKeepAliveRequests 100
Cette directive ne s'emploie qu'une fois, donc une seule valeur peut être indiquée. La
directive Listen lui est préférée.
# Ecoute d'identifiants réseaux additionnels.
#Listen 3000
#Listen 139.100.100.1
Cette directive est employée dans la mesure où le service web dispose de plusieurs
adresses IP.
Les différentes valeurs prises par la directive Listen doivent se retrouver au niveau des
directives de publication des sites virtuels. Ces valeurs permettent de distinguer un site
d'un autre et de rediriger les requêtes du client vers le site désiré.
La directive Listen s'utilise à la place des directives Port et BindAddress. En effet,
l'écoute d'un port par la directive Listen se substitue à la directive Port. En conséquence,
le port 80 n'est plus écouté. Il faut donc rajouter la directive Listen 80.
# Ces modules sont compilés avec la distribution standard.
# Pour changer le comportement standard, décommenter les lignes suivantes et modifier
# la liste des modules spécifiques à activer par le serveur.
#ClearModuleList
#AddModule mod_so.c mod_mime.c mod_access.c mod_auth.c mod_negotiation.c
#AddModule mod_include.c mod_autoindex.c mod_dir.c mod_cgi.c mod_userdir.c
#AddModule mod_alias.c mod_env.c mod_log_config.c mod_asis.c mod_imap.c
#AddModule mod_actions.c mod_setenvif.c mod_isapi.c
Parmi tous ces modules, on peut noter le module mod_asis.c qui permet aux fichiers d'un
site d'envoyer leurs propres en-têtes HTTP.
# Dynamic Shared Object (DSO) Support
#LoadModule anon_auth_module modules/mod_auth_anon.so
#LoadModule dbm_auth_module modules/mod_auth_dbm.so
#LoadModule digest_auth_module modules/mod_auth_digest.so
#LoadModule cern_meta_module modules/mod_cern_meta.so
#LoadModule digest_module modules/mod_digest.so
#LoadModule expires_module modules/mod_expires.so
#LoadModule headers_module modules/mod_headers.so
#LoadModule proxy_module modules/mod_proxy.so
#LoadModule rewrite_module modules/mod_rewrite.so
#LoadModule speling_module modules/mod_speling.so
#LoadModule info_module modules/mod_info.so
#LoadModule status_module modules/mod_status.so
#LoadModule usertrack_module modules/mod_usertrack.so
Les modules sous UNIX portent l'extension *.so et représentent des bibliothèques
d'objets dynamiques partagés que l'on peut activer à sa convenance.
# La directive ExtendedStatus controle si Apache génère une information d'état complète
# (ExtendedStatus On) ou basique (ExtendedStatus Off) lorsqu'il est interrogé.
#ExtendedStatus On
# Cette directive renvoie au client un nom DNS différent du nom réel de la station.
ServerName localhost
Cette valeur distingue le nom d'hôte propre au serveur web du nom de la station. Elle
apparaît dans les réponses HTTP, ainsi que dans les redirections URL. Il doit être au
préalable configuré au niveau du serveur DNS de rattachement.
Pour une utilisation locale du serveur, il est conseillé de laisser le nom "localhost".
# Localisation de la racine de publication du site web par défaut.
DocumentRoot "C:/Program Files/Apache Group/Apache/htdocs"
Cette directive indique le répertoire de publication par défaut (C:\Inetpub\wwwroot pour
Microsoft).
Il est bien sûr possible de dérouter la racine de publication, donc de modifier
l'emplacement du répertoire sous lequel seront déposés les pages Web.
Le chemin spécifié dans la directive DocumentRoot est ajouté aux noms des fichiers
demandés dans une adresse URL.
Par exemple, en supposant que le nom du serveur ou du site configuré dans le serveur
DNS soit www.site1.com, la requête du client http://www.site1.com/geo.htm demande
# Cette directive UserDir concerne les répertoires de connexion des utilisateurs. Sous
# UNIX, le caractère "~" précède le nom d'utilisateur : ~user. Dans l'environnement
# Windows, il n'est pas courant de déterminer le répertoire de connexion d'un utilisateur.
# Si le webmestre veut utiliser ce procédé, le module ci-dessous le permet (voir
# documentation pour les détails).
<IfModule mod_userdir.c>
UserDir "C:/Program Files/Apache Group/Apache/users/"
</IfModule>
# Nom des pages d'accueil des sites publiés (documents par défaut sous Microsoft).
DirectoryIndex index.html index.htm
<IfModule mod_mime.c>
# Localisation du fichier de définition des types MIME.
TypesConfig conf/mime.types
</IfModule>
# Nom du type MIME envoyé par défaut au navigateur du client lorsque le serveur ne
# connaît pas le type MIME d'un document.
DefaultType text/plain
<IfModule mod_mime_magic.c>
# Détermine les types de fichier à envoyer au client.
MIMEMagicFile conf/magic
</IfModule>
# Lorsque cette valeur est mise à 'on', les adresses des internautes connectés seront
# enregistrés dans le fichier "access.log" selon leur nom de domaine équivalent
# (mastation.mondomaine) et non selon leur adresse IP.
HostnameLookups off
# Nom du fichier historique des erreurs. L'indication d'un chemin relatif suffit car il est
# complété par la racine donnée par la directive ServerRoot.
ErrorLog logs/error.log
# Emplacement du fichier historique des accès. L'indication d'un chemin relatif suffit car
# il est complété par la racine donnée par la directive ServerRoot.
CustomLog logs/access.log common
La directive CustomLog permet de générer des enregistrements liés à un nom de format
déjà mentionné par une directive LogFormat.
Voici un exemple du fichier "access.log".
212.194.6.240 - - [26/Dec/2001:14:56:43 +0100] "GET /scripts/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400 295
default - - [28/Dec/2001:11:53:12 +0100] "GET /server-status HTTP/1.0" 403 291
127.0.0.1 - - [31/Dec/2001:10:56:28 +0100] "GET /Applets/TreeView/wnominus.gif HTTP/1.0" 304 -
127.0.0.1 - - [31/Dec/2001:10:56:45 +0100] "GET /bobo.htm HTTP/1.0" 404 268
127.0.0.1 - - [02/Jan/2002:11:38:01 +0100] "GET /index.html HTTP/1.1" 200 1572
# Lorsque ces lignes ne sont pas commentées, il est possible de spécifier des noms de
# fichiers dans lesquels seront stockés respectivement les adresses des connectés et les
# noms des navigateurs utilisés pour chaque connexion.
#CustomLog logs/referer.log referer
# Si les trois fichiers journaux "agent", "refer" et "access" doivent être combinés, la
# directive suivante doit être utilisée.
#CustomLog logs/access.log combined
Ces fichiers correspondent aux fichiers journaux de suivi des connexions des serveurs
Microsoft. Ici aussi, il est possible de modifier leur emplacement, de même que leur
contenu.
# Ajoute optionellement une ligne contenant la version du serveur et le nom de l'hôte
# virtuel aux pages générées par le serveur (pages d'erreur, mais pas celles générées par
# les applications CGI).
# La valeur "EMail" inclue aussi une adresse mailto: liée au paramètre ServerAdmin.
# Valeurs possibles : On | Off | EMail
ServerSignature On
<IfModule mod_alias.c>
# Permet de définir un alias (ou répertoire virtuel sous Windows) pour une adresse
# donnée (située sur le même système de fichiers sous UNIX), à partir de l'adresse
# indiquée par la directive DocumentRoot.
Alias /icons/ "C:/Program Files/Apache Group/Apache/icons/"
<Directory "C:/Program Files/Apache Group/Apache/icons">…</Directory>
<IfModule mod_autoindex.c>
# La directive FancyIndexing, présente dans les anciennes versions, a été remplacée par
# la directive IndexOptions. Elle permet, dans le cas où le parcours du répertoire est
# autorisé (Options Indexes), l'affichage d'icônes spécfiques aux types de fichiers
# inventoriés ci-après.
IndexOptions FancyIndexing
La figure 15 donne un aperçu de l'emploi du doublet ci-dessus.
Figure 217
# Permet de lier les types de fichiers à des icônes lorsque le parcours des répertoires
# (FancyIndexing) est activé.
AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip
AddIconByType (TXT,/icons/text.gif) text/*
AddIconByType (IMG,/icons/image2.gif) image/*
AddIconByType (SND,/icons/sound2.gif) audio/*
AddIconByType (VID,/icons/movie.gif) video/*
AddIcon /icons/binary.gif .bin .exe
AddIcon /icons/tar.gif .tar
AddIcon /icons/compressed.gif .Z .z .tgz .gz .zip
AddIcon /icons/layout.gif .html .shtml .htm .pdf
AddIcon /icons/text.gif .txt
AddIcon /icons/c.gif .c
AddIcon /icons/p.gif .pl .py
AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl
AddIcon /icons/back.gif
AddIcon /icons/hand.right.gif README
AddIcon /icons/folder.gif ^^DIRECTORY^^
AddIcon /icons/blank.gif ^^BLANKICON^^
<IfModule mod_mime.c>
# Certains navigateurs sont capables de décompresser des fichiers lors de leur réception,
# ces extensions permettant de les identifier.
AddEncoding x-compress Z zip
AddEncoding x-gzip gz
# Associe une extension de noms des fichiers à une demande de langage sous forme de
# type MIME.
AddLanguage en .en
AddLanguage fr .fr
AddLanguage de .de
…
# Cette nouvelle directive reprend les codes internationaux reconnus dans les pages.
AddCharset UTF-8 .utf8
AddCharset WINDOWS-1251 .cp-1251
…
La directive AddLanguage permet de spécifier une langue dans laquelle peuvent être
transmis les documents. Les documents doivent être réalisés dans les langues supportées.
<IfModule mod_negotiation.c>
# Fixe la priorité des langages dans le cas où le client n’émet pas de préférences.
LanguagePriority en da nl et fr de el it ja kr no pl pt pt-br ru ltz ca es sv tw
</IfModule>
Les deux dernières directives sont utiles pour paramétrer la négociation de contenu
autorisés par l'option Multiviews.
Le serveur Apache a la possibilité de servir les documents dans le format demandé par le
navigateur. Cela concerne les types MIME retournés ainsi que le langage et le jeux de
caractères utilisés. Cette possibilité est offerte par le module mod_negociation qui est
intégré par défaut lors de la compilation.
Le protocole HTTP/1.1 permet la négociation de contenu car il reconnaît les entêtes
Accept, Accept-Language, Accept-Charset et Accept-Encoding.
Il existe deux possibilités de gestion du contenu :
o par la directive Option Multiviews qui doit être positionnée pour les répertoires
dans lesquels la négociation est possible.
o un fichier type-map qui contient la liste exacte des variantes.
# Permet d'ajoûter une association autre que celles prévues dans le fichier mime.types,
# entre une extension de fichier et un type MIME (cas d'un fichier SSI).
AddType text/html .shtml
# Permet d'activer les fichiers ayant cette extension comme SSI (Server Side Includes).
AddHandler server-parsed .shtml
# Permet d'activer les fichiers d'extension cgi comme programme CGI en dehors du
# répertoire défini ci-dessus.
#AddHandler cgi-script .cgi
#…
</IfModule>
Un gestionnaire ou Handler est une procédure interne au serveur permettant d’effectuer
des actions lorsque un fichier est demandé. L’association entre un fichier et un
gestionnaire est effectuée soit en fonction de sa position dans le système de fichiers
(SetHandler), soit en fonction de l’extension du fichier (AddHandler).
La directive AddHandler permet d’associer une extension de fichier à un gestionnaire
existant.
La directive SetHandler est utilisée dans un bloc Directory ou Location pour associer
tous les fichiers de ce bloc au gestionnaire spécifié.
Les gestionnaires standards intégrés à Apache sont :
• send-as-is : envoie le fichier tel quel
• cgi-script : gère le fichier comme un script CGI
• imap-file : gère le fichier comme un fichier image-map
• server-info : récupère les informations sur le serveur
• server-parsed : interprète les fichiers SSI
• server-status : récupère l’état du serveur
• type-map : interprète la négociation de contenu
# La directive Action laisse définir les types de média associés à l'exécution d'un script
# préalable avant leur envoi vers le client.
# Format: Action media/type /cgi-script/location
# Format: Action handler-name /cgi-script/location
# Permet de spécifier le nom du répertoire dans lequel le serveur peut trouver les
# informations META à ajouter aux fichiers envoyés.
#MetaDir .web
# Permet de spécifier les extensions des fichiers contenant les informations META à
# ajouter aux fichiers envoyés.
#MetaSuffix .meta
Figure 218
L'erreur 404 seule configurée ci-dessus donne le résultat figure 16.
Il est donc possible de personnaliser les fichiers d'erreur comme dans l'environnement
Windows.
<IfModule mod_setenvif.c>
# Permet de corriger les bogues de navigateurs ne maintenant pas la connexion
# persistante (emploi du protocole HTTP1.0 au lieu de HTTP1.1).
BrowserMatch "Mozilla/2" nokeepalive
BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0
# Permet de répondre aux navigateurs fonctionnant encore avec le protocole HTTP/1.0.
BrowserMatch "RealPlayer 4\.0" force-response-1.0
BrowserMatch "Java/1\.0" force-response-1.0
BrowserMatch "JDK/1\.0" force-response-1.0
</IfModule>
Il est important pour un serveur de prendre en compte les "vieux" navigateurs qui ne
supportent toujours pas la version 1.1 du protocole HTTP.
# Autorise l'accès à la page server-status distribuant les informations sur le serveur.
#<Location /server-status>
#SetHandler server-status
#order deny,allow
#deny from all
#allow from domaine.extension
#</Location>
L'administrateur du serveur peut interroger à distance ce dernier, notamment sur son état
(http://<URLserveur>/server-status).
Pour cela, il faut au préalable faire charger le module mod_status.so par le serveur
(décommenter la ligne). Ensuite, une fois l'ensemble du bloc ci-dessus décommenté, il
faut autoriser la station de l'administrateur par son adresse IP ou son nom de domaine
équivalent. La directive "ExtendedStatus" mis à "On" permet d'avoir une information
complète.
Les figures 17 et 18 permettent de donner l'allure des informations renvoyées.
Les informations renvoyées sont externes à la configuration. Elles présentent d'abord le
serveur : la version du serveur, la date de la dernière compilation (Rebuilt). Puis en
dessous de la ligne horizontale, ce sont des statistiques de fonctionnement qui sont
exposés :
Figure 219
Figure 220
D'autres informations sont en rapport avec la configuration :
• la dernière ligne de texte exprime le fait que sur 50 unités de traitement (threads)
configurés, un seul est utilisé (49 idle),
• les deux dernières lignes de la figure 17 expriment un rapport exact de suivi des
transactions dont la légende est présentée dans l'écran suivant (figure 18).
La page affichée figure 17 représente une photo du fonctionnement du serveur. Il est
possibled’obtenir un affichage rafraîchi périodiquement en spécifiant à la suite de
l’adresse URL, "?refresh=T", ou T est la période en secondes.
# Permet la consultation à distance de rapports de configuration, à l'adresse URL
# http://servername/server-info (nécessite que mod_info.c soit chargé).
#<Location /server-info>
# SetHandler server-info
# Order deny,allow
# Deny from all
# Allow from mondomaine.fr
#</Location>
L'administrateur du serveur peut interroger à distance ce dernier, notamment sur les
modules incorporés à la configuration, ainsi que sur les éléments de sa configuration.
Pour cela, il faut au préalable faire charger le module mod_info.so par le serveur
(décommenter la ligne). Ensuite, une fois l'ensemble du bloc ci-dessus décommenté, il
faut autoriser la station de l'administrateur par son adresse IP ou son nom de domaine
équivalent. Voici un écran (figure 19) permettant de donner l'allure des informations
renvoyées.
Figure 221
# Directives pour serveur proxy.
#<IfModule mod_proxy.c>
# La valeur "On" active la gestion des requêtes d'un client via un serveur proxy (ne
# fonctionne pas sous Windows 95).
#ProxyRequests On
# <Directory proxy:*>
# Order deny,allow
# Deny from all
# Allow from mondomaine.fr
# </Directory>
# formule explicite suggérée par le nom de la directive, si cette date est indéfinie dans les
# pages.
#CacheLastModifiedFactor 0.1
#CacheDefaultExpire 1
# Adresses à ne pas conserver dans le cache local
#NoCache domaine.fr autres_domain.edu …
#</IfModule>
Le serveur Apache peut faire office de serveur proxy ou mandataire. Il peut aussi
dialoguer ou négocier les transactions avec tout serveur proxy se trouvant entre lui et le
client : le serveur proxy de l'organisme du client, le serveur proxy de l'organisme auquel
appartient le serveur Apache objet du cours, ou encore celui des fournisseurs d'accès
respectifs du client et du serveur lui-même.
Les recommandations qui précèdent concernent les deux fonctions principales d'un
serveur proxy : serveur passerelle entre le réseau local de l'entreprise et le réseau Internet,
et serveur cache intermédiaire.
Ces directives ne sont pas mises en œuvre par défaut. Un retour d'expérience sur le sujet
exige non seulement des compétences réseau et SSI que l'auteur du document ne possède
pas actuellement, mais aussi une plate-forme adéquate susceptible de reproduire toute la
chaîne de liaison. Aussi n'est-il pas envisagé d'exposé détaillé. Les éléments donnés ci-
dessus devraient être suffisants pour appréhender la configuration du serveur si besoin.
### Section 3: Virtual Hosts
# Utiliser la ligne de commande avec l'option '-S' pour vérifier la configuration des hôtes
# virtuels.
# Utilisé obligatoirement lors de la mise ne œuvre des hôtes virtuels à base de noms
# génériques.
#NameVirtualHost *
La valeur attendue peut être une adresse IP (suivie éventuellement d'un numéro de port)
ou un nom d'hôte, ou l'astérisque ci-dessus. Le type de valeur le plus souvent rencontré
reste l'adresse IP :
NameVirtualHost 111.22.33.44
Dans ce cas, on suppose que le serveur Apache dispose de plusieurs adresses IP, et que
plusieurs sites sont regroupés sur une même adresse IP.
111.22.33.44 www.site1.ip1.com Site ou hôte virtuel n°1
111.22.33.44 www.site2.ip1.com Site ou hôte virtuel n°2
On spécifie ici l'adresse IP sur laquelle le serveur recevra les requêtes destinées à un ou
plusieurs hôtes virtuels à base de noms. On répète la directive pour chaque adresse.
L'emploi de l'astérique permet au serveur de rediriger les connections vers n'importe
quelle adresse non configurée par une directive NameVirtualHost ou une section
<VirtualHost> plus spécifique.
# Ce bloc donne un exemple de configuration de serveur virtuel (ou hôte virtuel) situé sur
# le même serveur.
#<VirtualHost nom.domaine.extension>
#ServerName nom.domaine.extension
#ServerAdmin webmaster@domaine.extension
#DocumentRoot /repertoire
#DirectoryIndex index.html
#ErrorLog répertoire relatif
#CustomLog répertoire relatif
#</VirtualHost>
La mise en œuvre de cette directive oblige le webmestre à configurer le serveur DNS de
rattachement pour le nom d'hôte ou nom de domaine qualifié (ou nom générique selon
Microsoft) utilisé ici : "nom.domaine.extension".
Il est conseillé de définir une valeur pour les différentes directives utilisées à l'intérieur du
bloc ou conteneur de l'exemple ci-dessus.
La directive DocumentRoot est obligatoire dans la mesure où elle indique la localisation
du site. Il est utile de repréciser le nom de la page d'accueil (DirectoryIndex) si celle-ci
est différente de celle indiquée dans la directive globale.
La directive ServerAdmin offre la possibilité de désigner un administrateur propre au site
qui pourra bénéficier de ses propres fichiers historiques grâce aux directives ErrorLog et
CustomLog.
Des modalités d'accès spécifiques à certains répertoires du site virtuel peuvent être
définies par l'insertion de blocs <Directory> ou <Location> ou <Files> à l'intérieur du
conteneur <VirtualHost>.
L'emploi de ce conteneur est reprécisé dans le paragraphe consacré à la publication par
hôtes virtuels.
<IfModule mod_autoindex.c>
# L'option TrackModified est dédiée aux volumes NTFS. Elle offre le report de la date de
# la dernière modification des fichiers au niveau de l'affichage des répertoires.
IndexOptions TrackModified
</IfModule>
La commande "apache -l" lancée depuis une console Windows donne la liste des modules
compilés :
Compiled-in modules
http_core.c
mod_so.c
mod_mime.c
mod_access.c
mod_auth.c
mod_negociation.c
mod_include.c
mod_autoindex.c
mod_dir.c
mod_cgi.c
mod_userdir.c
mod_alias.c
mod_env.c
mod_log_config.c
mod_asis.c
mod_imap.c
mod_actions.c
mod_setenvif.c
mod_isapi.c
# Le serveur Apache sous Windows permet d'utiliser le registre pour associer les fichiers
# selon leurs extensions. Ce comportement est susceptible de changer avec la version
# Apache 2.0. Pour activer ce comportement, décommenter la directive suivante.
#ScriptInterpreterSource registry
FancyIndexing on
# AddIconByEncoding …
… AddEncodingByType … AddIcon … DefaultIcon … ReadmeName … HeaderName
… IndexIgnore … AccessFileName
TypesConfig /etc/httpd/conf/apache-mime.types
… DefaultType … AddEncoding … AddLanguage … LanguagePriority … Redirect
… BrowserMatch
# La directive Group attend un nom de groupe UNIX ou numéro de GID du groupe sous
# lequel le serveur accède aux ressources de l'ordinateur (nobody avant la version 1.3.14).
Group apache
L'indication d'un numéro d'UID ou de GID doit être précédé du caractère "#".
ServerAdmin…
# Localisation des fichiers de configuration et fichiers journaux.
ServerRoot /etc/httpd
BindAddress Listen
# Emplacement du fichier d'erreurs.
ErrorLog logs/error_log
LogLevel LogFormat …
CustomLog logs/access_log combined
Ces directives spécifient la destination de l’enregistrement défini par une directive
LogFormat antérieure. Si aucune directive LogFormat n’a été spécifiée, elles
enregistrent les messages au format CLF (Common Log Format).
Le format CLF enregistre, pour chaque requête, une ligne contenant :
hôte identité autorisation date requête code taille
avec :
• host : adresse IP ou nom complet du client
• identité : si la directive IdentityCheck est validée et que le client répond
o Cette directive normalisée (RFC), n'est pas fiable pour assurer une bonne
identification. La résolution peut échouer (parefeu), et surtout créer des
délais. A ne pas utiliser !
• autorisation : l’identificateur de l’utilisateur si le document est protégé
• date : la date et l’heure de la requête
• requête : la ligne de requête du client
• code : le code à trois chiffres envoyé au client
• taille : la taille en octets du document envoyé sans prendre en compte les entêtes
Si un champ n’a pas de valeur, il est remplacé par un tiret (-).
# Nom du fichier dans lequel est rangé le numéro de processus du serveur Web (http).
# Ce numéro est utile pour envoyer une commande "kill -HUP <numéro de processus>"
# afin de signifier au serveur qu'il doit relire ses fichiers de configuration.
PidFile /var/run/httpd.pid
######################
# SGI Performance Settings
######################
# Administration particulière des fichiers journaux, des processus enfants, du cas multi-
# processeurs, etc…
##############################
# Add-on Modules and Virtuel Hosts
##############################
# Gestion spécifique au module Perl …
Quand l'on combine l'installation du serveur Apache et du module Perl, le module
mod_perl est mandaté pour fonctionner automatiquement (voir le fichier httpd-perl-
proxied.conf).
Include conf/vhost/Vhosts.conf
#LoadModule vhost_alias_module modules/mod_vhost_alias.so
#AddModule mod_vhost_alias.c
#Include conf/vhost/DynamicVhosts.conf
#Include conf/vhost/VirtualHomePages.conf
Depuis la version 1.3.14 sont apparus de nouveaux fichiers de configuration inclus dans
le fichier principal. Ces fichiers sont là pour déporter la déclaration des hôtes virtuels. Ils
sont utilisés sur le réseau Internet par les services d'hébergement en masse.
1.1.1.18. Fichier Vhosts.conf
Il représente à proprement parler le fichier de configuration des hôtes virtuels dont il a
déjà été question plus haut.
################# Vhosts.conf
#
# Depuis la version Apache 1.3.19, la configuration initiale a été modifiée pour y inclure
# quelques astuces :
# - Sont ajoutés les directives User et Group de telle façon que les hôtes virtuels puissent
# travailler avec la directive suexec. Si celle-ci est activée, le serveur Apache exécutera
# les scripts cgi sous ces identités (sous réserve que les uid et gid soient > 100 par
# sécurité). Les répertoires et fichiers cgi doivent appartenir à ce doublet user/group.
# - Est ajoutée la directive Setenv VLOG. Elle travaille en conjonction avec la directive
# CustomLog dans le fichier "common.conf". Quand la directive Setenv VLOG est
# Inclut le nom du serveur dans les noms des fichiers pour satisfaire aux requêtes
#VirtualDocumentRoot /www/hosts/%0/docs
#VirtualScriptAlias /www/hosts/%0/cgi-bin
# Inclut une partie du nom du serveur dans les noms des fichiers
#VirtualDocumentRoot /www/hosts/%2/docs
# Simple répertoire cgi-bin
#ScriptAlias /cgi-bin/ /www/std-cgi/
Figure 222
Unix
Le webmestre peut tester la cohérence ou la syntaxe du fichier "httpd.conf" en lançant la
commande : apachectl configtest.
4. Publication
Le serveur Apache permet, à l'image des autres serveurs Web, de publier les sites de plusieurs
façons :
• Directement sous la racine de publication "C:/Program Files/Apache
Group/Apache/htdocs" sous Windows ou "/var/www/html" sous UNIX.
• En déroutant cette racine de publication vers un lecteur logique ou dossier dédié
• En utilisant la technique des Hôtes (ou Serveurs) virtuels pour publier plusieurs sites
différenciés selon l'adresse IP ou le numéro de port, ou le nom générique de site
• En utilisant la redirection URL
• En utilisant la technique des alias (ou répertoires virtuels sous Windows)
Il ne permet pas, à priori, de publier le site localisé sur un dossier (ou répertoire) partagé à
travers le réseau (que ce soit sous Windows NT ou sous UNIX avec NFS).
Cette deuxième façon de publier a sa raison d'être s'il l'on dédie un lecteur logique du disque dur
à la publication Web. Pour cela, il suffit de changer dans le fichier "httpd.conf" la valeur de la
directive DocumentRoot.
Une deuxième variante consiste à dérouter le siège des applications CGI vers le dossier du site
publié contenant ces dites applications. Pour cela, deux modifications sont à effectuer dans le
fichier de configuration :
a. La directive ScriptAlias /cgi-bin/ en indiquant la localisation du nouveau dossier, par
exemple " E:/Web/SitesPersos/normands/Scripts/ "
Attention : le dernier "/" revêt une importance accrue par rapport aux autres.
b. Modifier le bloc <Directory "C:/Program Files/Apache Group/Apache/cgi-bin"> (ou le
rajouter dans l'ex-fichier access.conf) selon l'exemple.
<Directory "E:/Web/SitesPersos/normands/Scripts/">
Options ExecCGI
</Directory>
L'option ExecCGI est celle qui donne les droits d'exécution au dossier côté serveur Web.
1.1.1.24. Unix
Cette méthode présente peu d'intérêt sous UNIX.
4.3 Serveurs virtuels
Pour publier des sites multiples, le serveur Apache utilise la technique des serveurs virtuels.
Cette méthode est sans conteste la plus utilisée actuellement.
Pour distinguer ces différents sites, le serveur dispose des trois identifiants réseau déjà cités dans
l'étude des serveurs Microsoft :
• L'adresse IP
• Le numéro de port
• Le nom générique de l'hôte virtuel
Quelle que soit la plate-forme, UNIX ou Windows, les procédures restent identiques.
www.stagiaire10.dtei.msi IN A 160.192.60.146
• Il doit demander au serveur d'écouter l'adresse IP en question (directive Listen ou
BindAddress), préciser le numéro de port derrière si ce dernier est autre que le numéro de
port par défaut. La directive Listen permet de spécifier que le serveur attend des
connexions sur une adresse IP et un port particulier.
• Il doit enfin configurer chaque site publié ainsi à l'aide d'un conteneur ci-dessous.
• Il indique l'adresse IP en dur dans la balise du conteneur <VirtualHost>.
Voici un exemple.
Listen 160.192.60.146
…
<VirtualHost 160.192.60.146>
ServerName www.stagiaire10.dtei.msi
ServerAdmin stagiaire10@dmsi.esat.terre.def
DocumentRoot /home/dtei/stagiaire10
</VirtualHost>
La configuration peut être modifiée pour un hôte virtuel à base d'adresse IP en fixant la directive
UseCanonicalName à la valeur "DNS". Le nom du serveur inséré dans les noms de fichiers
renvoyés vers le client est obtenu par résolution inverse des adresses IP des hôtes virtuels.
1.1.1.26. Multisites à base de numéros de Port
La deuxième méthode de déclaration de serveurs virtuels consiste à différencier les sites ayant la
même adresse IP par le numéro de port d'attribution.
Cette méthode, déjà citée au niveau des serveurs Microsoft, présente un inconvénient majeur.
Elle oblige les clients à mentionner le numéro de port dans l'adresse URL pour accéder aux
pages du site. Si l'on communique aux clients le numéro de port, cela leur permet d'accéder à un
site privé.
Un moyen d'éviter la divulgation du numéro de port est de créer une page d'accueil (portail)
commune à tous les sites. Cette page contiendrait des liens comportant le numéro de port en
question.
D'un autre côté, la procédure est plus simple que la précédente car elle ne fait pas intervenir de
configuration réseau locale ou distante. Les paramètres à configurer sont les suivants.
• Pour que le serveur attende des connexions sur ce numéro de port, il faut paramétrer la
directive Listen "Listen 6000" par exemple ou la directive BindAddress "BindAddress
*:6000.
• Chaque site publié doit être configuré ainsi à l'aide d'un conteneur ci-dessous.
• Le numéro de port est indiqué en dur derrière l'adresse IP dans la balise du conteneur
("*:numéro de port" pour l'unique adresse IP de la station).
On peut supposer que le site ci-dessous est publié sous UNIX en utilisant l'unique adresse IP de
la station ou l'adresse IP standard de la station (par opposition aux adresses IP virtuelles).
<VirtualHost *:6000>
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
Voici un deuxième exemple sous Windows où l'adresse est précisée devant le numéro de port.
Listen 3000
…
<VirtualHost localhost:3000>
DocumentRoot "F:/Web/SiteDMSI/DMSI"
DirectoryIndex dmsiindex.htm
</VirtualHost>
Remarque : l'astérisque permet de ne pas assigner d'adresse IP à chaque site publié sur le serveur.
Cette méthode est actuellement la plus employée sur le réseau Internet, notamment par les sites
d'hébergement en masse. Ceux-ci combinent à la fois la multiplicité des adresses IP et la
multiplicité des noms d'en-tête par adresse IP.
Le webmestre doit faire suivre cette directive par la déclaration d'un conteneur ci-dessous pour
configurer chaque site publié partageant la même adresse IP.
Pour contourner d'éventuels problèmes de serveurs DNS ou de serveur Apache lui-même, il est
conseillé d'indiquer dans la balise plutôt l'adresse IP, et à l'intérieur du bloc, préciser le nom
d'hôte du site (nom générique) comme valeur de la directive ServerName plutôt que d'indiquer
directement le nom générique du site. Voici un premier exemple.
NameVirtualHost 160.192.51.121
<VirtualHost 160.192.51.121>
ServerName www.abc.com
ServerAdmin webgirl@abc.dom
DocumentRoot /var/www/abc
</VirtualHost>
Ce deuxième exemple publie deux sites sur la même adresse IP. Il prend en compte les
navigateurs travaillant encore avec le protocole HTTP1.0 (ServerPath).
NameVirtualHost 160.192.51.121
<VirtualHost 160.192.51.121>
ServerName www.abc1.com
ServerAdmin webboy@abc.dom
DocumentRoot /var/www/abc1
ServerPath /abc1
</VirtualHost>
<VirtualHost 160.192.51.121>
ServerName www.abc2.com
ServerAdmin webgirl@abc.dom
DocumentRoot /var/www/abc2
ServerPath /abc2
</VirtualHost>
Pour tester en local la publication de plusieurs sites sous UNIX sans configurer le serveur DNS
de rattachement, il suffit de rentrer les adresses IP en question dans le fichier /etc/hosts :
• 160.192.50.120 www.exemple1.com
• 160.192.50.120 www.exemple2.com
Sous UNIX, la commande de configuration des interfaces réseau, sous réserve que l'interface
réseau local se nomme eth0, permet d'attribuer une deuxième adresse en utilisant la commande
ifconfig selon la syntaxe suivante : ifconfig eth0 160.192.51.122 alias.
Selon la configuration de l'organisme, il convient aussi de paramétrer le masque du réseau (sous
UNIX, ajouter à la commande ifconfig l'option netmask sous la forme d'une adresse IP, par
exemple 255.255.240.0).
Il est possible de le réaliser graphiquement sous Linux : la figure 23 en annexe présente le
bouton "alias IP pour hôtes virtuels".
Dans le cas de la publication multisites à base d'adresses IP, il faut poursuivre la configuration
ci-dessus par celle du serveur DNS. On utilise le nom du premier site publié comme nom de
domaine équivalant à la nouvelle adresse IP, les autres noms de site étant déclarés comme alias
du premier.
4.4 Redirection
La redirection des URL permet d’accéder à des documents situés ailleurs que sous le répertoire
défini par la directive DocumentRoot.
Les directives à paramétrer pour obtenir une redirection sont :
Directive Signification
Alias Définit un chemin situé sur le même système de fichiers à
substituer dans les URL pour les fichiers standards (comparable
aux répertoires virtuels sous Windows ?!)
ScriptAlias Idem que la directive Alias pour les scripts.
AliasMatch Idem que la directive Alias en utilisant une expression régulière
pour la concordance.
Redirect Permet de substituer une adresse URL par une autre.
RedirectMatch Une expression régulière définit la redirection.
RedirectTemp La redirection est temporaire.
RedirectPermanent La redirection est permanente.
C'est le module mod_rewrite qui permet de transformer les URL reçus à l’aide de règles basées
sur des expressions régulières. Il n’y a pas de limites sur le nombre de règles pouvant être
appliquées. Les définitions peuvent être effectuées au niveau du serveur, du serveur virtuel, ou
du bloc Directory.
Voici un exemple réalisé sous Windows 98. Le client ajoute à l'adresse URL du serveur le nom
de l'alias pour atteindre la page d'accueil du site. Si le nom de domaine pleinement qualifié du
serveur est "www.exemple1.com", le client saisit :
• http://www.exemple1.com/normands
Alias /normands/ "F:/Web/SitesPersos/normands/"
<Directory "F:/Web/SitesPersos/normands">
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
Comme le montre l'exemple, la définition de l'alias est en général suivie d'un conteneur ou bloc
de directives <Directory> dans lequel sont décrits les paramètres de protection du site en
question.
La procédure est identique sous UNIX.
5. Protection du site
La protection des sites publiés s'effectue à plusieurs niveaux.
Par défaut, les connexions anonymes sont activées par l'intermédiaire des directives User et
Group. Autrement, le mode d'authentification de base (nom d'utilisateur,mot de passe) peut être
utilisé sans grande difficulté. Il est largement évoqué dans la partie "Protection d'une page par
mot de passe".
L'étude des différents modules ci-dessus n'est pas abordée, car elle nécessite des connaissances
plus approfondies du serveur et des systèmes d'authentification. Actuellement, deux technologies
semblent faire la préférence des concepteurs de sites Web.
La première est une variante de l'authentification de base. Au lieu d'utiliser le serveur pour
authentifier, ainsi que le fichier texte de déclaration des utilisateurs et mots de passe, les
identifiants de connexion sont stockés dans une base de données que l'on consulte à travers des
pages de scripts : base de données MySQL et scripts PHP par exemple.
La deuxième utilise la technologie de chiffrement SSL qui prend le pas sur toutes les méthodes
d'authentification, que l'on soit sous Windows ou sous UNIX, que l'on travaille avec le serveur
Apache ou le serveur IIS.
Dans l'exemple ci-dessus, l'accès est interdit à tous sauf aux adresses commençant par … Si
l'ordre d'interprétation des directives est inversée (order allow, deny), alors personne ne pourra
accéder aux sites, pas même les stations du réseau 123.156.
Figure 223
• MultiViews
Cette option permet la négociation de contenu.
L'emploi de symboles "+" ou "-" peut être utile pour respectivement faire suivre ou non ces
droits à un répertoire de niveau inférieur. En effet, l'utilisation d'un bloc Directory sur un dossier
de niveau inférieur redéfinit les droits sans hériter de ceux qui ont été définis avant.
Voici par exemple, deux définitions sans symboles "+" ni "-" :
<Directory /web/docs>
Options Indexes FollowSymLinks
</Directory>
<Directory /web/docs/spec>
Options Includes
</Directory>
Seul l'option Includes sera activée pour le répertoire /web/docs/spec. Cependant, si la seconde
directive d'Options utilise les symboles "+" et "-", alors les options FollowSymLinks et
Includes sont validées pour le répertoire /web/docs/spec, et non Indexes.
<Directory /web/docs>
Options Indexes FollowSymLinks
</Directory>
<Directory /web/docs/spec>
Options +Includes -Indexes
</Directory>
Normalement, si plusieurs options sont définies sur un répertoire, alors la plus restrictive est
appliquée ; les autres options ne sont pas combinées. Cependant, si derrière la valeur "all", les
options sont précédées d'un symbole "+" ou "-", alors les options sont combinées entre elles.
Un bloc Files permet de spécifier des directives particulières pour un ou plusieurs fichiers. La
directive FilesMatch fonctionne de façon similaire avec une expression régulière comme
argument.
Un bloc Location permet de spécifier des directives particulières à une adresse donnée. La
directive LocationMatch fonctionne de façon similaire avec une expression régulière comme
argument.
La fabrication d'un mot de passe sous UNIX se fait en utilisant le programme htpasswd selon la
syntaxe suivante : htpasswd [-c] passwordfile username
• avec l'option "-c", le fichier est créé ;
• sans l'option "-c", le fichier est complété par la nouvelle entrée
• passwordfile est le nom du fichier contenant les mots de passe
• username est le nom de l'utilisateur
Il est ensuite possible d'ajouter tout aussi facilement de nouvelles entrées dans ce fichier.
# htpasswd users machintruc
New password:
Re-type new password:
Adding password for user machintruc
Désormais, toute tentative d'accès au répertoire provoque chez le client l'affichage d'une boîte de
dialogue demandant un nom d'utilisateur (figure 22) et le mot de passe correspondant.
Figure 224
Si maintenant nous changeons la ligne "require valid-user" par "require user moimeme", seul
l'utilisateur "moimeme" pourra accéder au contenu en fournissant le mot de passe adéquat.
L'utilisateur "machintruc" avec ou sans mot de passe correct se verra refuser l'accès.
Terminons cette partie en signalant qu'il est possible de conjuguer les directives d'au-
thentification que nous venons de voir avec les directives précédentes deny et allow. Il suffit
pour cela de préciser la politique à adopter en donnant une valeur à la fonction "satisfy".
Soit nous demandons à ce que les deux conditions soient remplies, alors la fonction prend la
valeur "all".
Soit une seule des conditions est nécessaire pour autoriser l'accès, alors la fonction prend la
valeur "any".
a. Le bloc <Directory> (sauf avec des expressions régulières) et le fichier .htaccess sont
évalués simultanément (.htaccess à la préséance sur <Directory>)
b. Les blocs <DirectoryMatch> et <Directory> avec des expressions régulières
c. Les blocs <Files> et <FilesMatch>
d. Les blocs <Location> et <LocationMatch>
Les directives données dans les sections VirtualHost sont évaluées après celles de la
configuration générale.
Conclusion
Le serveur Apache est présenté ici dans ses grandes fonctionnalités. Pour ceux qui veulent en
savoir plus, il faut consulter dans un premier temps la documentation en ligne.
Une étude plus détaillée des fonctionnalités du serveur en ce qui concerne les sites applicatifs est
envisagée : les SSI, les CGI, les scripts Perl, les scripts PHP. Il est envisagé aussi une étude plus
poussée concernant l'utilisation des serveurs proxy, la mise en œuvre des extensions FrontPage,
ainsi que l'utilisation des techniques SSL.
La documentation jointe donne les premières indications sur les versions des autres plates-
formes telles que UnixWare, Novell Netware 5, HP MPE/iX ou IBM/TPF .
Sinon, le site principal du serveur met à notre disposition les dernières FAQ et autres
renseignements.
Enfin, il reste la bibliographie dont voici un extrait :
• Apache - Précis et concis de A.Ford - O'Reilly - novembre 2000
• Apache Server de R.Bowen K.Coar - Campus Press - juillet 2000
• Apache Professionnel de P.Wainwright - Eyrolles - juillet 2000
Un livre anglophone, traitant de la dernière version sortie, est déjà en librairie :
Apache Server 2.0 - A Beginner's Guide de K.Wrightson - Mc Graw Hill - octobre 2001.
Annexe PWS
Comparaison des offres « Windows NT WorkStation » et « Windows 98 »
Fonctionnalité PWS pour Windows NT PWS pour Windows 98
Workstation
Utilisations standard Développement complet de site ou Publication personnelle sur un
publication personnelle sur l'intranet intranet d'entreprise de petite
d'une entreprise envergure
Service WWW Oui Oui
Service FTP Oui Non
Nombre maximal de 10 10
connexions
Active Server Pages Oui Oui
Enregistrement dans Format de fichier journal NCSA Format de fichier journal
un journal de (par défaut), MSCSV standard et NCSA
l'utilisation du site étendu (facultatif)
Sources de publication Lecteurs locaux et réseau Lecteurs locaux uniquement
Gestionnaire des Oui Non
services Internet
Authentification De base ou Stimulation/Réponse de Aucune
Windows NT
Composants et sous-composants
Le tableau ci-dessous décrit les options disponibles pour chaque type d'installation. Un X inscrit
dans la colonne Min. indique les options incluses par défaut lors de l'installation minimale. Un X
inscrit dans la colonne Déf. indique les options supplémentaires incluses lors de l'installation par
défaut. Les options qui ne sont pas précédées d'un X dans les colonnes peuvent être sélectionnées
lors de l'installation personnalisée.
Annexe IIS
Composants et sous-composants (par défaut) de IIS
Mo Nom du Composant
2,7 Certificate Server
0,5 Environnement Scripts
2,5 Extension Serveur FrontPage 98
3,4 Fichiers Partagés de W…
Internet Information Server
31,8 Documentation
5,9 Active Server Pages
3,1 Documentation Admin IIS
0,6 Fichiers Partagés de Documentation
16,8 Multimedia à flux continu
5,3 SDK
3,4 Exemple World Wide Web
1,6 Gestionnaire des Services Internet
0,6 Gestionnaire des Services Internet (HTML)
0,1 Serveur FTP
2,8 Serveur Web
3,3 Serveur NNTP
3,8 Relais SMTP
10,8 MS Data Access Components
1,5 ActiveX Data Objects
2,3 Remote Data Service
0,5 Documents RDS
0,8 Exemples
0,3 Fichiers normaux
0,7 Fichiers RDS v1.1
4,0 Source de Données
11,7 Index Server
1,2 Documentation en ligne
0,4 Fichiers exemples
0,0 Fichiers système
10,1 Ressources en ligne
1,0 MS Management Console
8,6 MS Message Queue
1,8 MS Script Debugger
38,3 MS Site Server Express
17,6 Service de Connexion Internet pour RAS
0,1 Support de déploiement RAD à distance Visual Interdev
17,1 Transaction Server
12,1 Composants
3,1 Développement de …
1,9 Documentation
Figure 225
Sélectionnons le deuxième onglet " taches serveur" : un bouton s'intitule "Apache Web Server".
L'action de ce dernier nous ouvre une nouvelle fenêtre (figure 24).
Figure 226
A travers cet écran, il est possible de configurer :
• Le comportement global et principal du serveur en lui-même
• Les hôtes virtuels
• La protection du site appliquée aux répertoires et fichiers
• Les performances du serveur (TimeOut, …, MaxThreadPerChild, …)
• Les modules à charger
• Le module de chiffrement SSL (Secure Socket Layer)
Webmin
Le logiciel d'administration distante d'une plate-forme UNIX Webmin fonctionne à travers un
interface Web. Une fois installé le logiciel, la page d'accueil du site est accessible via le
protocole https (site sécurisé via la technique SSL) sur le port propriétaire 10000.
Figure 227
Là il faut choisir l'onglet "Servers".
Figure 228
La première icône s'intitule "Apache Webserver". L'action du lien ouvre une page de sommaire
(figure 27).
Figure 229
La page se découpe en deux parties : une réservée à la configuration globale du serveur, et l'autre
dédiée aux hôtes ou serveurs virtuels.
La première partie permet la gestion :
• Des performances du serveur (processes…)
• Des adresses et ports écoutés par le serveur (networking…)
• Des modules à charger (modules)
• Des types de fichiers renvoyés au client
• Des programmes CGI
• De la protection du site (per-directory…)
• Des modules compilés
• Etc…
La deuxième partie offre aussi la possibilité de modifier la configuration du site par défaut
(default server).