INTServeurs

Systèmes Répartis INTERNET Serveurs Web
Sommaire
Chapitre 1 : Présentation des Serveurs..........................................................................................4

Introduction................................................................................................................................4
Emploi et Utilité d'un Serveur..................................................................................................4
1.1 Qu'est ce qu'un Serveur Web ?..........................................................................................4
1.2 Pourquoi un Serveur Web ? ..............................................................................................8
Fonctionnalités d'un Serveur....................................................................................................8
2.1 Quelques Statistiques.........................................................................................................8
2.2 Caractéristiques Communes............................................................................................10
Orientation du Choix ..............................................................................................................12
3.1 Site Personnel..................................................................................................................12
3.2 Site d'Entreprise...............................................................................................................12
3.3 Exemple de banc de test...................................................................................................12
Offre Microsoft........................................................................................................................14
4.1 Offres Commerciales.......................................................................................................14
4.2 Distribution......................................................................................................................14
4.3 Utilité...............................................................................................................................15
4.4 Comparaisons...................................................................................................................15
Conclusion................................................................................................................................16
Chapitre 2 : Serveur Microsoft PWS...........................................................................................17
1.Installation ............................................................................................................................17
1.1 Configuration requise......................................................................................................17
1.2 PWS sous Windows NT 4.0 Station................................................................................18
1.3 PWS sous Windows 98....................................................................................................25
1.4 IIS sous Windows 2000...................................................................................................26
2.Administration......................................................................................................................30
2.1 Sous Windows NT WorkStation......................................................................................31
2.2 Sous Windows 98............................................................................................................68
2.3 Sous Windows 2000........................................................................................................74
3.Publication.............................................................................................................................82
3.1 Publication de Sites FTP..................................................................................................82
3.2 Publication de Sites Web.................................................................................................85
3.3 Publication sous Windows 98..........................................................................................92
Conclusion................................................................................................................................93
Chapitre 3 : Serveur Microsoft IIS..............................................................................................94
1.Installation ............................................................................................................................94
1.1 Configuration requise......................................................................................................94
1.2 Lancement de l'installation..............................................................................................95
1.3 Fonctionnalités.................................................................................................................96
Edition février 2002 23242348.doc Page 1 sur 228

1.4 Types d'installation..........................................................................................................96

1.5 Composants de l'installation personnalisée.....................................................................97
1.6 Chemins ..........................................................................................................................98
1.7 Administration locale ou distante....................................................................................99
1.8 Tour d'horizon des composants installés ........................................................................99
1.9 Architecture...................................................................................................................102
2.Administration....................................................................................................................103
2.1 Architecture...................................................................................................................103
2.2 Arrêt et Démarrage des Services...................................................................................104
2.3 Description du Gestionnaire MMC................................................................................104
2.4 Propriétés de la Station..................................................................................................105
2.5 Propriétés du Site Web..................................................................................................107
2.6 Propriétés du Site FTP...................................................................................................127
2.7 Administration à distance..............................................................................................130
3.Publication...........................................................................................................................134
3.1 Publication de Sites FTP................................................................................................134
3.2 Publication de Sites Web...............................................................................................137
4.Site Server Express 2.0.......................................................................................................138
4.1 Menu Démarrer..............................................................................................................139
4.2 Compléments sur Content Analyser .............................................................................142
4.3 Lancement de Content Analyser....................................................................................142
4.4 Présentation de l'interface..............................................................................................146
5.Index Server........................................................................................................................152
5.1 Fonctionnalités...............................................................................................................152
5.2 Installation.....................................................................................................................153
5.3 Fonctionnement.............................................................................................................155
5.4 Catalogue d'Indexation..................................................................................................157
5.5 Administration...............................................................................................................163
Conclusion..............................................................................................................................166
Chapitre 4 : Serveur Apache......................................................................................................168
Introduction............................................................................................................................168
1.Présentation ........................................................................................................................168
1.1 Origine...........................................................................................................................168
1.2 Particularités..................................................................................................................168
1.3 Emploi............................................................................................................................169
1.4 Fonctionnement.............................................................................................................169
2.Installation ..........................................................................................................................169
2.1 Sous Windows...............................................................................................................169
2.2 Sous UNIX.....................................................................................................................177
3.Administration....................................................................................................................183
3.1 Standard.........................................................................................................................184
3.2 Spécifique Windows......................................................................................................200
3.3 Spécifique UNIX...........................................................................................................201
3.4 Test de la Configuration................................................................................................206

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

Chapitre 1 : Présentation des Serveurs
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 première section de ce document rappelle dans un premier temps les principes de

fonctionnement d'un serveur Web. La question de l'utilité d'un serveur dans le cas du
développement de sites Web est posée. Cette section intéresse tout autant les internautes qui
appréhendent le monde des serveurs que les concepteurs qui veulent tester leur site avant
publication.
La deuxième section de ce document présente les fonctionnalités d'un serveur, fonctionnalités

communes aux quatre serveurs les plus importants du moment. Cette section est destinée aussi
bien aux futurs Webmestres chargés de gérer ces serveurs Web que les internautes férus de
techniques du Web. Elle peut intéresser aussi les architectes de systèmes d'information chargés
du choix primordial d'un serveur sur le plan technique.
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.
 Emploi et Utilité d'un Serveur

1.1 Qu'est ce qu'un Serveur Web ?
Le service Web est un service d'informations qui se veut public, c'est-à-dire accessible aux
internautes du monde entier.
Ce service est mis en oeuvre par un logiciel jouant le rôle de serveur à l'égard des logiciels
clients joués par les navigateurs des internautes.
Ce logiciel est installé sur une station, puis administré par le Webmestre qui prépare
l'environnement de publication des sites à mettre en ligne.
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
1 : La validation d’une adresse URL

lance la requête Pages
HTML
2 : Le serveur traite la requête en cherchant la
page demandée
3 : Le serveur répond en renvoyant la page

trouvée sinon un message d’erreur
Figure 1 : Site Statique
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

chemins, assurant la portabilité du site, ne nécessitent que l'interprétation du navigateur et non

l'action d'un serveur dûment localisé.
La deuxième technique réside dans le fait que les liens cliqués ont pour cible des pages Web
simples (documents à extension *.htm) et non des pages de scripts ou applications (documents à
extension autre). Ces pages Web simples sont appelées pages statiques. Ce sont des pages
invariables, préparées à l'avance, ne nécessitant aucune action du serveur.
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
Figure 2 : Site Dynamique
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.
Comment reconnaître dans le code source des pages ces applications ?

• Grâce à leurs extensions de fichiers.

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.
1.2 Pourquoi un Serveur Web ?

Dans le cas d'un site à publier sur le réseau Internet, ce site sera mis en ligne grâce à l'action de
ce serveur Web. En conséquence, pas de publication sans serveur!
Dans le cas de la conception d'un site statique, l'installation d'un serveur en vue de tester ce
dernier offre moins d'intérêt.
Dans le cas de la conception d'un site applicatif, il est indispensable d'installer, d'administrer et
de publier le site en lui-même pour le tester de bout en bout : aussi bien les tests unitaires que les
tests de synthèse.
 Fonctionnalités d'un Serveur

Pour présenter les fonctionnalités d'un serveur Web, nous nous sommes basés sur les
caractéristiques communes de quelques uns d'entre eux.
Les serveurs choisis sont classés par des sites statistiques comme étant les plus représentatifs du
réseau des réseaux.
2.1 Quelques Statistiques

Un certain nombre de sites effectuent des statistiques mensuelles sur les serveurs Web. Voici le
résultat obtenu pour le mois de septembre 2001 :
Serveur Part de Marché
Apache 59.51%
Microsoft-IIS 27.45%

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.
IPlanet Web Server

La nouvelle alliance de Sun et Netscape a enfanté un nouveau produit pour lequel la technique
java est omniprésente.
La configuration et la gestion est traitée via un interface Web (navigateur).
Il est possible de fonctionner en mode multiprocesseur.
Il existe aussi un certain nombre de connecteurs natifs pour des bases de données (Oracle,
Informix, DB2 et Sybase).
Pour des applications distribuées, iPlanet supporte CORBA et IIOP. IPlanet est maintenant si
complet qu'il peut efficacement rivaliser avec quelques serveurs d'application.
Le serveur iPlanet dispose de services de renseignements puisant dans les services LDAP pour la
gestion des groupes et utilisateurs, association assurant la politique des mots de passe et des
groupes dynamiques.
Zeus Web Application Server 3.3.5

Le quatrième serveur, Zeus Web Application Server 3.3.5 (site www.zeustechnology.com), plus
discret, représente le serveur Web sous UNIX utilisé pour des hébergements de masse chez les
fournisseurs de services (eBay, Lycos, Infoseek).

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.
2.2 Caractéristiques Communes

Les deux paragraphes qui suivent nécessitent des connaissances préalables. Pour les lecteurs
néophytes, il est conseillé de s'imprégner des chapitres consacrés à l'étude d'un serveur
spécifique avant de lire et d'apprécier le contenu qui suit.
En se basant sur les quatre serveurs les mieux placés du moment, énumérons les caractéristiques
communes de ces derniers. Les thèmes principaux se retrouvent dans la colonne de gauche :
système d’exploitation ou environnement d’installation, publication et enregistrement des
connexions, protocoles en service et techniques applicatives, sécurité et administration. La
colonne de droite détaille les fonctionnalités attendues pour chaque thème.
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 historiques (ou log)

• Il archive de multiples fichiers "log" gérés selon le cycle
désiré.
• Le format commun de fichier "log" est de type CERN ou
NCSA
• Les entrées de fichiers historiques peuvent être personnalisées.
• Le serveur peut tracer des utilisateurs donnés au sein de ces

fichiers.
Protocoles et • Il supporte le protocole HTTP/1.1.

"Includes" supportés • Il comprend le format URI dans les requêtes HTTP/1.1.
• Il traite les "image map" incorporés.
• Les scripts CGI ou autres sont en mesure d'accéder aux
variables du serveur.
• Les méthodes non-supportées peuvent invoquer un scénario.
• Un agent SNMP est fourni.
• Un langage de script est incorporé au serveur.
• Il inclue automatiquement n'importe quels en-têtes HTTP dans
les réponses.
Server Side Includes
• Le serveur supporte les SSI.
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.
Voyons maintenant quelques traits spécifiques de chacun.

Lancement et Apache
Enregistrement • Sous Windows NT, il peut fonctionner aussi bien comme un
(historique des service que comme une application.
connexions) Microsoft
• Les enregistrements des fichiers historiques sont effectués par
"EventLog".
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.
Autres Particularités Apache

• Le code source du serveur est fourni.
• Il peut agir comme un serveur proxy avec gestion de cache.
 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.
3.2 Site d'Entreprise

En ce qui concerne l'Intranet d'une entreprise, ou un système d'information Web, il s'agit d'opter
pour un serveur très performant et solide pour tester ou publier le site.
Les plus connus restent encore le serveur Apache et le serveur d'informations Internet v5.0 (IIS)
fourni en standard avec Microsoft Windows 2000 (IIS est la version professionnelle de PWS
énoncée plus haut). Mais un autre concurrent se positionne en candidat de deuxième plan :
Netscape Server Enterprise remplacé par iPlanet Web Server v4.1.
3.3 Exemple de banc de test

Des magazines ou sites Internet spécialisés font périodiquement des bancs de tests pour
comparer les performances des serveurs Web. Le tableau ci-dessous donne un exemple d'étude
basé sur des critères pertinents : rapidité de traitement des requêtes, administration du serveur et
des sites, paramètres de sécurité d'accès, évolutivité en terme de multiplicité d'environnement.
Rapidité • Apache 1.3.12

Avec un nombre moyen de 1 600 pages lues à la seconde en
mode biprocesseur, le serveur Apache sort vainqueur du test
HTTP statique.

• IIS 5.0 sous Windows 2000 Advanced Server.

Avec plus de 1 800 transactions en cinq minutes en mode
biprocesseur, IIS s'impose lors du test CGI/Perl dynamique.
Administration • Web Server Enterprise

En matière de configuration et d'administration, iPlanet présente
les meilleures caractéristiques.
• IIS 5.0 sous Windows 2000 Advanced Server.

Convivial, il présente quelques lacunes notamment en ce qui
concerne les sauvegardes et la création de sites web complexes (il
ne gère en standard que des scripts propriétaires).
Sécurité • Web Server Enterprise

Il se révèle le plus complet particulièrement sur les listes de
contrôle des autorisations d'accès.
• 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.
Evolutivité • Apache 1.3.12

Ce serveur peut être installé dans de multiples environnements
(principaux Unix, NetWare, Windows, Mac OS, Linux, etc.).
• Web Server Enterprise

La compatibilité avec Windows 2000, Mac OS et NetWare 4.5
est annoncée sur le site web de l'éditeur.
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.
L'étude du serveur Apache fait l'objet du dernier chapitre du module.
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.
4.1 Offres Commerciales

L'offre Microsoft se décline principalement selon que l'on ait affaire à un serveur ou une station
Windows.
Dans le premier cas, il s'agit d'"Internet Information Server" (IIS), offre dédiée à Windows NT
Server ou aux différentes implémentations de "Windows 2000 Server".
Dans le deuxième cas, il s'agit de "Personal Web Server" (PWS), offre dédiée à Windows NT
Station, Windows 98 ou Windows 95. L'offre de "Windows 2000 Pro", se rapprochant de la
version IIS, ne mentionne plus PWS.
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.
Restrictions de PWS par rapport à IIS

Le serveur Web Personnel (PWS) administre un seul site FTP (Site FTP par défaut) et un seul
site Web (Site Web par défaut) au niveau de chaque station, alors que IIS en administre
plusieurs.
Le serveur Web Personnel, qu'il s'agisse du service FTP comme du service WEB, est limité à 10
connexions de la part des utilisateurs.
Le serveur Web Personnel ne permet pas, au niveau de la sécurité, de filtrer les adresses IP des
internautes.
Avantages de IIS 4.0

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.
Les performances techniques de chargement de pages ou d'exécution d'application sont un

élément déterminant. Pour peaufiner le tableau des critères, l'évolutivité, la sécurité d’accès ainsi
que la facilité d’administration peuvent largement influencer ce choix vers l’un ou l’autre des
serveurs.

Chapitre 2 : Serveur Microsoft PWS
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.
Le document est découpé en trois parties : installation, administration et 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.
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
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.

1.2 PWS sous Windows NT 4.0 Station

Lancement de l'installation
Une fois le cédérom inséré dans le lecteur, le programme d'installation se lance. La page
d'accueil (Bienvenue) s'affiche (figure1). Une fois la présentation lue, le néophyte parcourt la
rubrique « Installation ». Il découvre alors quelles sont les étapes préalables à celle-ci.
Pour accéder à des informations complémentaires, le webmestre clique sur les deux autres menus
(En savoir plus, Notes de mise à jour).
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".
 le serveur ne s’installe pas si les composants suivants ne le sont pas :

• Service Pack 3.0 situé sur le même cédérom sous « Winntsp3\I386 » :
Nt4sp3_i.exe,
• Internet Explorer 4.0 situé sur le même cédérom sous « Ie401\X86 » :

Ie4setup.exe.
Figure 4

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é.
Composants de l'installation personnalisée

L'écran présenté figure 4 nous donne un aperçu des différents composants disponibles dont nous
allons brosser une présentation sommaire.
• Environnement d'exécution de scripts Windows
Cet environnement est basé sur l'élaboration de scripts dans un langage spécifique au
serveur (wsh). Il permet au webmestre de compléter toutes les fonctionnalités déjà
proposés de manière native.
• Extensions Serveur Frontpage 98
Le serveur Web et le client Web doivent installer les extensions Frontpage pour permettre
au client de modifier, depuis son éditeur FrontPage version 98, les pages Web du site
Web publié. Ces extensions gèrent d'un côté le site par dialogue RPC encapsulé dans
HTTP, et d'un autre côté les Webbots spécifiques à FrontPage.
• Fichiers partagés
Il s'agit de fichiers indispensables au fonctionnement interne au serveur. Il est donc
déconseillé de décocher ce composant.
• MS Data Access Components 1.5
Ces composants facilitent l'utilisation des bases de données avec la prise en charge des
objets ADO (ActiveX™ Data Objects) et le pilote Microsoft® Access.
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,

• Transaction  C:\Program Files\Mts
Administration locale ou distante

Le webmestre peut se limiter à l'administration locale du serveur (obligation pour lui de se
rendre dans la salle des serveurs pour gérer de près ce dernier), ou alors peut configurer
l'administration à distance du serveur en question (depuis sa station bureautique).
Comme le suggère la figure 5, il faut prévoir avec quel compte d'administrateur le webmestre va
effectuer cette télégestion.
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.
Tour d'horizon des éléments installés

Sur le bureau
• Le programme "Gestionnaire de serveur Web personnel" est résident (icône présente dans la
barre de tâches à droite). La présence de l'icône non barrée atteste du démarrage automatique
du serveur Web, une fois le système d'exploitation réamorcé.
• La présence de l'Icône « Publier » sur le bureau à gauche permet de lancer l'utilitaire
"Gestionnaire de serveur Web personnel".
Sous Windows 98, les deux icônes sont également présentes.
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.
L’offre spécifique à « Windows NT WorkStation » nous donne l’affichage suivant :

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.
Services (voir Panneau de Configuration / Services)

Les deux premiers services ci-dessous sont démarrés automatiquement alors que le troisième est
démarré manuellement:
 Service de publication World Wide Web
 Service de publication FTP
 Service IIS Admin
Sous Windows 98, il n'existe pas de gestion des services.
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
contient aussi un fichier de publication par défaut :

welcome.htm (figure 8).
Le contenu du répertoire varie selon la version.
 les répertoires "scripts" (pages ASP ou applications CGI) et
"webpub" (publication via assistants) sont des répertoires
réservés au fonctionnement interne du serveur.
Figure 10
Remarque : la page publiée par défaut correspond aux "Notes de Publication" du menu
principal évoqué ci-avant.
Ajout d'utilisateurs spécifiques au fonctionnement du serveur

Dans l'option "Gestionnaire des utilisateurs" du menu "Outils d'Administration Commun", on
constate la présence de deux nouveaux utilisateurs (figure 9) : IUSR_nom d'hôte réservé aux
connexions anonymes des internautes, et IWAM_nom d'hôte réservé à la gestion des applications
Web publiées sur le serveur.
Figure 11
 Il est fortement conseillé de ne pas toucher à la configuration automatique de ces comptes,

notamment aux mots de passe connus du seul serveur (désynchronisation assurée).
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.

2. "Notes de Publication" (C:\WINNT\Help\pws\htm\core\iirnlink.htm).
Figure 12
1.3 PWS sous Windows 98

Lancement de l'installation
Le CD-ROM de Windows® 98 inclut le Serveur Web personnel (PWS).
Cependant, une étape d'installation distincte est nécessaire pour installer et configurer
entièrement PWS.
Pour installer PWS, il faut suivre la procédure suivante :
1. une fois le cédérom de Windows 98 inséré dans le lecteur, cliquez sur Démarrer, puis
sur Exécuter.
2. Dans la boîte de dialogue Exécuter, tapez x:\add-ons\pws\setup.exe en remplaçant la
lettre x par la lettre correspondante au lecteur de cédérom, puis cliquez sur OK.
Installation proprement dite

Les fonctionnalités incluent :
• Serveur PWS
• Transaction Server
• Components Data Access
• Client Message Queue Server
• Administrative facilities
Deux répertoires annoncés sont créés :

• C:\Inetpub\wwwroot
• C:\Program Files\MTS
Le détail des modules et composants est joint en annexe.
Tour d'horizon des composants installés

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.
1.4 IIS sous Windows 2000

L'installation de cette version s'effectue avec le cédérom d'installation. Le serveur fait partie des
composants additionnels du système d'exploitation.
Le terme de "Personal Web Server" a disparu de la distribution à la place de "Internet
Information Server". Une fois le composant sélectionné, le programme ne propose pas différents
types d'installation.
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.

Une fois cochés les services désirés, le serveur s'installe. Cinq minutes après, celle-ci est close.
Le système ne demande pas de rédémarrer la station. Mais les services sont automatiquement
démarrés (voir "Panneau de configuration / Services").
Tour d'horizon des éléments installés

Il installe aucune icône sur le bureau, aucun raccourci dans le menu Démarrer.
Le programme d'installation met en place le répertoire de publication au même endroit (figure
13).

Figure 15
Deux répertoires supplémentaires sont à noter : Adminscripts (scripts supplémentaires

d'administrateur), mailroot. Le répertoire " mailroot" concerne le nouveau service de serveur
SMTP virtuel.
Le répertoire d'installation du serveur est analogue aux versions précédentes :
\Winnt\System32\Inetsvr.
Deux répertoires nouveaux restent cependant à signaler : "\Program Files\Fichiers
communs\Microsoft Shared\web server extensions" et "\Winnt\Web". Le premier permet à
l'administrateur de site d'installer des extensions au serveur. Ces possibilités seront évoquées
dans la section "Administration". Le second est réservé aux partages d'imprimantes gérés depuis
le serveur Web (figure 17).
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".
En fonction de cette répartition, l'auteur du document a choisi d'exposer :

• Le gestionnaire "Microsoft Management Console" avec "Windows NT Workstation",
• Le "Gestionnaire de services Web" avec "Windows 98".

2.1 Sous Windows NT WorkStation

Le principal outil d'administration locale ou distante des services Internet reste le "Gestionnaire
de Services Internet" (ou MS Management Console ou MMC). Toutes les opérations et
propriétés des services sont configurables graphiquement à l'aide de cet outil.
Arrêt et Démarrage des Services

En revanche, l'arrêt et le démarrage du serveur peuvent être déclenchés de différentes manières:
• en manoeuvrant le menu contextuel de l'icône de la barre des taches (démarrer, arrêter ou
suspendre).
 Seul le service Web est accessible. L'arrêt du service ajoute sur l'icône une croix
blanche sur rond rouge.
• en manoeuvrant le service d'administration IIS dans "Panneau de Configuration / Services"
 Le fait de l'arrêter entraîne l'arrêt des deux autres, l'icône de la barre des tâches est
supprimée.
o Le redémarrage de "Service Administration IIS" ne démarre que ce dernier et non
les 2 autres, il ne réactive pas l'icône dans la barre de tâches.
o Le redémarrage de Service de publication "world wide web" réactive l'icône dans
la barre de tâches, et actualise l'état du nœud dans "MS Management Console".
o Le redémarrage de Service de publication "FTP" actualise l'état du nœud dans
"MS Management Console".
• à l'aide de gestionnaires de services tels que "MS Management Console" (des indications sur
les différentes manières d'opérer seront données dans les paragraphes qui suivent).
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
1er niveau : Console Root

Le premier niveau définit la console de supervision "racine" configurée par défaut. Voici une
description des différentes fonctionnalités accessibles de plusieurs façons:
 Icônes
• Des fonctions de gestion de console autre que la console "root" proposée par défaut (créer
une nouvelle console, ouvrir une console existante, enregistre la console),
 Enregistrer une console dans un fichier permet de conserver la liste des
composants logiciels enfichables qui y sont chargés et la configuration des fenêtres de
la console pour un usage ultérieur.
 Par défaut, un fichier de console porte l'extension « .msc ».
 Il est possible de créer de nouvelles consoles pour, par exemple, bénéficier de
vues simultanées sur des serveurs différents du fonctionnement d'un même service, ou
bénéficier de vues simultanées des différents services activés sur le même serveur.
• Des fonctions de gestion classique d'un gestionnaire (Nouvelle fenêtre, Coller)
 La fonction "masquer/ afficher la structure" concerne le volet de structure.
 Fenêtre déroulante « Action » (même fonctionnalités que par clic droit) :
• Le menu "Nouveau" présente quelques options accessibles soit depuis le menu "Console /
Ajouter un…", ou à partir de plusieurs niveaux de nœuds dans le volet de structure. Elles
permettent :
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".
2ème niveau : Internet Information Server et Transaction Server

Le deuxième niveau définit les services installés (ou logiciels enfichables). Les différentes
options sont accessibles soit par les icônes, soit par menu déroulant, ou par clic droit :
 Icônes
• Des fonctions de gestion classique d'un gestionnaire (couper, copier, coller, supprimer,
dossier parent, masquer/ afficher la structure),
• D'autres fonctions plus spécifiques au niveau :
 Il s'agit du gestionnaire de clés SSL (Secure Socket Layer) qui permet de chiffrer les
sessions entre le serveur et ses clients moyennant un échange préalable de certificats
d'authentification (figure 21).

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
 Cet analyseur de performances, propre aux "Outils d'Administration Commun" du

système d'exploitation, est centré sur l'activité du serveur (figure 23). Quelques
compteurs peuvent être intéressants à ajouter (graphe / objet / service IIS) :
connexions abandonnées, demandes CGI, tentatives de connexion, utilisateurs
anonymes (nb), connexions : vitesse de requêtes http.

Figure 25
 Cet observateur d’évènements, fichier journal du système d'exploitation de la station

accessible depuis les "Outils d'Administration Commun", n'est pas centré sur les
activités du serveur Internet (figure 24).
Figure 26
 Fenêtre déroulante "Action" (ou clic droit sur le nœud sélectionné) :

• Le menu Nouveau comporte les options déjà décrites au premier niveau.
• Les options d'un gestionnaire classique, ainsi qu'une nouvelle option « connecter ».
 L’option « connecter » demande le nom du nouveau serveur dont il faut gérer les
services Internet (idem "Ajouter un ordinateur").
3ème niveau : la station

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.
 L’option « actualiser » force le rafraîchissement de l’affichage.

 L’option « propriétés » ouvre la possibilité au webmestre de définir celles-ci au
niveau de l’ensemble des sites Web ou FTP à publier. Pour la version PWS qui
autorise la publication d’un seul site, cette possibilité semble redondante avec celle
existante au niveau du « Site par défaut ».
 La liste "Sauvegardes" affiche toutes les sauvegardes de configuration créées (figure
25), leur numéro de version ainsi que la date et l'heure de création. Pour revenir à une
configuration précédente, il suffit de sélectionner une sauvegarde et de cliquer sur le
bouton Restaurer.
Figure 27
4ème niveau de IIS : Site Web et Site FTP par défaut

Le quatrième niveau définit enfin les sites des deux services Internet installés. La version
PWS n’autorise que la configuration du « Site par défaut ». Voici une description des différentes
fonctionnalités :
 Icônes

• 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".
• 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

Ajoût d'un composant

Pour différentes raisons, il se peut que le volet de structure s'arrête au deuxième niveau
(stations).
Pour gérer un service, il faut obligatoirement ajouter le composant logiciel enfichable
correspondant au service. La fenêtre actionnée par le menu présente deux onglets "Autonome" et
"Extensions".
• Restons sur « Autonome », laissons « console root » sélectionné dans le menu déroulant,
puis cliquons sur « ajouter …» .
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.

• Limiter la bande passante,

o Cette possibilité, accessible uniquement sous la version IIS, sera commentée dans le
chapitre adéquat.
• Configurer les types MIME des en-têtes HTTP.
o Leur configuration sera commentée au niveau des propriétés des sites.
Limitons notre curiosité à la modification des services.
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
Identification du Site Web

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
• Pour modifier le numéro de port, il faut cliquer sur le bouton "Avancées". La

fenêtre figure 31 s'affiche. Cliquer sur le bouton "Ajouter" ouvre une nouvelle fenêtre
(figure 32) dans laquelle le webmestre saisit le nouveau numéro.
• Dans le cas de PWS, le changement de numéro de port offre un intérêt limité dans
la mesure où l'on rend privé le seul site mis en ligne.
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
<Nom d'en-tête de l'hôte>

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.
Voici un exemple où le nom de domaine du serveur est "www.serveur.com", où le nom

générique du site indiqué comme nom d'en-tête de l'hôte est "www.example.com". Les
lignes qui suivent sont un extrait de l'en-tête protocolaire qui circule sur le réseau.
CLIENT REQUEST FOR www.serveur.com

IP : Destination Address = 172.21.13.45
HTTP : Host = www.example.com
Il existe un préalable important à la mise en œuvre de cette possibilité : celle d'avoir

configuré le nom générique de site comme alias du nom de domaine du serveur dans le
serveur DNS de rattachement.
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
• Le bouton "Parcourir" nous invite à consulter le journal. Le format de journal W3C

est le seul qui nous permette de paramétrer en détail les champs des fichiers
historiques. Voici un aperçu (figure 34) de l'onglet "Propriétés étendues" (champs par
défaut).

2. Performances
Figure 37
Réglage des performances

• Il s'agit, en fonction de la fréquentation du serveur (nombre d'internautes visiteurs),
d'affiner la taille du cache afin d'améliorer ses performances (figure 35).
Configuration des connexions

• Laisser la case cochée sous-entend l'emploi par le serveur de la version 1.1 du
protocole HTTP, version du protocole reconnue par tous les navigateurs et recommandée
comme standard actuel.
• Le terme "connexion HTTP persistante" correspond à un des apports de cette
nouvelle version. En effet, la version HTTP 1.0 déconnectait le visiteur après chaque
transaction (requête et réponse), alors que la version HTTP 1.1 permet de conserver la
connexion pour l'ensemble de la session.
• Le serveur gère en fait plusieurs transactions HTTP à travers la même connexion
TCP. Cette fonction entraîne un gain de performance notable dans le chargement de
pages possédant de nombreuses images. Cependant, cette fonction n’est active que pour
les fichiers dont la taille est connue à l’avance. Cela ne fonctionne donc pas avec des
scripts CGI qui fabriquent des pages Web à la volée.
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
Il est possible d'en rajouter (figure 37).
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.
Contrôle (d'accès au site)

• Accès au journal :
Par défaut, tout accès au site est inscrit au journal.
Figure 40
• Autorisation (lire, écrire) :

Par défaut, la permission de lecture est accordée à tout internaute, celle d'écriture
ne l'est pas. Autoriser l'internaute à écrire revient à lui permettre de modifier le
contenu du source HTML de la page Web visitée depuis son navigateur
(dangereux).
• Contenu (parcourir) :
Dans le cas où la case est cochée, si l'internaute envoie une adresse erronée, le
serveur, au lieu de lui renvoyer le message d'erreur "erreur 404:page non trouvée",
affiche en réponse l'arborescence du site visité. Il est rare que l'hébergeur autorise
l'inspection de l'arborescence par le visiteur. Cette possibilité semble réservée à la
phase de développement ou de test du site.
• Site Web FrontPage :
Cocher cette case permet au concepteur de site de modifier à distance le site
hébergé si le concepteur a installé en vis à vis les extensions FrontPage.

• 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
• 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é » uniquement si une
application est en cours d'élaboration.
• Scripts :
Ce bouton radio, coché par défaut, concerne les pages de scripts ASP, IDC, etc…
L'action du bouton "Configurer" représente un des moyens de publier une application
interne à un site web donné. La fenêtre "Configuration d'application" ainsi lancée nous
propose trois onglets (figure 39). Le premier onglet "mappage d'application" dispose d'un
bouton "Ajouter" qui permet de déclarer effectivement cette application (figure 40).
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
• Le serveur offre aussi la possibilité de séparer les données de la localisation du

serveur. Le serveur accède au site à travers un répertoire partagé de l'environnement
Windows (figure 42).
Dans un premier temps, on indique l'adresse du serveur et le nom de partage réseau.
Dans un deuxième temps, il faut préciser le nom d'utilisateur et le mot de passe de
connexion au partage en question.

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

Document par défaut

Le webmestre indique ici le nom de la page d’accueil du site (nom + extension) que le
visiteur n'est pas censé connaître (figure 44).
Il est possible d'en mettre plusieurs et de les ordonner.
Remarque :
 La page par défaut des applications à base de scripts tels que forums de discussion est
configurée : "default.asp".
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
a) Connexions anonymes et contrôle d'authentification

En principe, les sites Internet sont accessibles à tout le monde. Aucune restriction d'accès
n'est donc mise en œuvre. En cliquant sur le bouton "Modifier" (figure 46), l'on constate

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.

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>
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.

Pour plus d'informations, le webmestre doit consulter la documentation de

sécurité du serveur Web.
Si l'on coche "Authentification de base", la fenêtre d'avertissement figure 48
s'affiche. En passant outre, une deuxième fenêtre s'ouvre et nous invite à saisir le
nom du domaine d'authentification (figure 49).
Cette méthode d'authentification d'accès peut être choisie dans le cas où le
webmestre enlève les connexions anonymes et restreint l'accès aux seuls clients
du domaine d'appartenance du serveur Web, ainsi que ceux du domaine spécifié
dans la fenêtre suivante.
Figure 51
Les clients doivent à chaque accès préciser leur identifiants de connexion.

Remarque :
• Il est déconseillé de désactiver l'authentification de base lorsque le service
est démarré. Il convient d'arrêter au préalable le service.
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.
<Stimulation / réponse de Windows NT>

Cette méthode, cochée par défaut avec celle des connexions anonymes, permet
d'authentifier les utilisateurs sans transmettre les mots de passe réels sur le réseau.
L'authentification au domaine sert d’authentification d’accès. Le navigateur
Internet Explorer de l'utilisateur prouve sa connaissance du mot de passe par un
échange cryptographique avec le serveur Web. L'utilisateur doit ouvrir dans ce cas
une session réseau (voir stratégie de compte).
L'authentification "Stimulation/réponse de Windows NT" est prioritaire par
rapport à l'authentification "De base" pour le navigateur Web de l'utilisateur.

Internet Explorer essaie d'utiliser les informations d'ouverture de session

Windows NT en cours avant de demander à l'utilisateur un nom d'utilisateur et un
mot de passe. Cependant, si l'identification de l'utilisateur échoue dans un premier
temps, Internet Explorer demandera à l'utilisateur de lui fournir un nom
d'utilisateur et un mot de passe de compte Windows NT.
Les extensions de serveur FrontPage authentifient le client avec cette méthode.
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
Prenons l'exemple d'un organisme d'enseignement comprenant des professeurs et des

élèves. Rendons le site privé accessible au corps enseignant et non aux élèves. Le
webmestre va utiliser les groupes globaux GG-prof et GG-eleve que l'administrateur du
domaine avait créé. En tant qu'administrateur local de la station hébergeant le serveur
Web, il va créer deux groupe locaux GL-prof et GL-eleve dans lesquels il va insérer les
deux groupes globaux. Posons les droits sur les groupes locaux de la façon suivante :
Administrateurs Contrôle total

GL-prof Lire
GL-eleve Aucun accès
Cela permet de bien gérer séparément les accès au domaine et ceux du serveur.
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.
c) restrictions IP par adresse et par nom de domaine

Cette option n'est activée qu'avec la version IIS.
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
• En-tête HTTP personnalisé :

Le webmestre, en accord avec le propriétaire du site, peut ajouter des éléments à
destination des navigateurs des clients (figure 52). Au lieu de laisser le concepteur
de site insérer ces éléments à l'aide des balises META dans chacune des pages
Web du site, le webmestre peut demander au serveur de les inclure dans les pages
web avant leur envoi.

Figure 54
• Contrôle d’accès au contenu :

Le paramétrage côté serveur de ces filtres permet aux clients de configurer les
mêmes filtres dans son navigateur Internet Explorer (options Internet, onglet
Contenu). Ces filtres exploitent les informations glissées dans les en-têtes HTTP
des pages elle-mêmes (balise META, http-equiv=PICS-Label).
Figure 55

Figure 56
Le bouton "Modifier le contrôle d'accès…" ouvre une fenêtre à deux onglets

(figure 53). Sachant que le sujet n'est pas facile à appréhender, le premier onglet
nous invite d'une part à nous connecter au site Web de l'organisation ayant élaboré
ce type de contrôle (RSAC), d'autre part à nous inscrire auprès de cet organisme
de référence.
Les balises META incorporées dans les pages Web mentionnent l'organisme de
référence. Cet organisme est contacté pour contrôler la page avant que celle-ci ne
soit renvoyée chez le client.
Le deuxième onglet (figure 54) nous permet après inscription au RSAC, par
exemple, de paramétrer ces contrôles d'accès.
• 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

• Un certain nombre de paramètres décrits au niveau du site peuvent être redéfinis au

niveau d'un répertoire du site ou même d'une page Web donnée (figure 57).
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".
Propriétés du Site FTP

Configurer finement l'ensemble du Site FTP (par défaut ou autre) revient à modifier les
propriétés du menu contextuel. La fenêtre "Propriétés" affiche cinq onglets dont la plupart des
paramètres sont communs avec ceux des propriétés du site web. Nous nous attacherons à
commenter ce qui diffère.
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
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.
Pour bien comprendre la procédure, il faut distinguer le serveur de publication et la station

d'administration distante du webmestre. Pour administrer à distance les sites publiés depuis le
même outil "MMC", le webmestre est amené à installer un serveur web local à cette station. Ce
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 :

1. côté serveur de publication :
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).
2. côté serveur d'administration 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)
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.

Limiter l'accès aux privilèges administratifs du serveur Web

L'accès au groupe Administrateurs du serveur Web doit être limité. En effet, les membres du
groupe Administrateurs disposent d'un contrôle total sur le serveur et ses fonctionnalités de
sécurité. Il est conseillé de respecter les règles suivantes pour contrôler les membres du groupe :
• Accorder les privilèges Administrateurs uniquement aux personnes de confiance.
• Lorsque des groupes d'utilisateurs sont créés, éviter d'accorder des autorisations
Contrôle total, qui permettent aux utilisateurs de manipuler le contenu du serveur.
• Modifier régulièrement le mot de passe du compte Administrateurs.
• Appliquer une stratégie stricte en matière de comptes.
2.2 Sous Windows 98

Pour gérer le serveur, ouvrons le "Gestionnaire de Serveur Web Personnel" en cliquant sur
l'icône "Publier" du bureau.
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 "Général" permet :

• d'arrêter ou de démarrer le service de publication (bouton "Arrêter" ou "Démarrer"
suivant l'état actuel du serveur).
• donne des résultats statistiques sur l'activité du serveur.
o La fenêtre déroulante permet de choisir le type de statistique.

Le menu "Publier" permet d'utiliser un assistant de publication, une fois que la page d'accueil est
définie.
Le menu "Site Web" permet de définir la page d'accueil du site.
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.
2.3 Sous Windows 2000

Avant de passer en revue les nouveautés apportées au niveau des gestionnaires de service,
voyons comment gérer l'activité des services.
Arrêt et Démarrage des Services

Dans "Panneau de configuration / Services", il est possible de démarrer ou d'arrêter les mêmes
services que ceux décrits dans la version "Windows NT" (figure 67).

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

Gestionnaire Web personnel

Il s'agit de la même interface (figure 70) que celle décrite dans la version Windows 98 mais
simplifiée à trois options dans le menu. L'assistant de création de page d'accueil et celui de
publication du site ont été supprimés.
Gestionnaire des services Internet

La présentation de cet outil a été elle aussi simplifiée par rapport à la version IIS pour Windows
NT Server. Les menus ont disparu. Seuls subsistent les icônes et le menu contextuel.
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.
Services Internet (IIS)

Dans le menu contextuel (ou menu déroulant "Action") est apparu une nouvelle option :
"Exporter la liste…" (figure 72).
Pour exporter une ligne ou tout le contenu du volet d'informations (nouveau nom du volet de
droite ou ancien volet de résultats) de la console MMC dans un fichier texte, on peut lancer cette
fonctionnalité.
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
Propriétés du site Web

Un nouvel onglet fait son apparition : Extension Serveur (figure 80).
Extension Serveur
Celui-ci doit être configuré dans les nœuds de niveaux supérieurs pour que le webmestre puisse
redéfinir s'il y a lieu les paramètres à ce niveau.
Répertoire de base

La présentation du cartouche réservé au paramétrage des applications a changé d'aspect (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.
3.1 Publication de Sites FTP

Le serveur FTP est seulement disponible avec le système d'exploitation Windows NT (voire
Windows 2000).
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.
Pour l'un comme pour l'autre, il existe plusieurs procédés :

• Soit conserver le lieu de publication classique sous la racine du serveur FTP,
physiquement présent sous Inetpub\ftproot,
• Soit dérouter la racine du serveur :
o par exemple vers un lecteur logique dédié à Internet puis vers un répertoire
"public" pour le serveur dédié au téléchargement
o par exemple vers un lecteur logique "Perso" dédié à l'hébergement,
comportant autant de répertoires que de clients à héberger.
Sous PWS, le webmestre "hébergeur" peut créer des répertoires virtuels pour le serveur FTP,
répertoires pointant vers ceux des clients.
1. Racine standard du Site FTP par défaut (PWS ou IIS)

Dans ce cas, la publication est très simple :
1. Copier sous Inetpub\ftproot l'arborescence « ftp » du répertoire public en
fichiers « .zip » ou « .exe », ou autre...
2. Configurer sous MMC le message d'accueil, changer éventuellement le type
d'affichage
3. Démarrer le service si besoin
4. Tester en local son serveur FTP, en utilisant l'adresse IP de boucle locale
(127.0.0.1) ou son nom équivalent (localhost), de la façon suivante :
4.1. Depuis son navigateur, taper « ftp://localhost »
4.2. L'arborescence des fichiers apparait précédé du message d'accueil.
2. Dérouter la racine du Site FTP par défaut (PWS ou IIS)

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.
Les autres opérations restent identiques.

Le test en local de la publication depuis le navigateur donne la copie d'écran figure 83.
Hébergement de sites Web

Dans ce cas, le webmestre va autoriser la dépose du site web client sur son lieu de
publication.
Or le serveur PWS ne peut publier qu'un seul site à une adresse IP donnée. Pour distinguer le
client "A" du client "B", le webmestre va pour cela créer autant de répertoires que de
clients sous la racine du serveur FTP.
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 serveur FTP, 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.
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.
3.2 Publication de Sites Web

Adoptons la même démarche au niveau des sites Web en nous identifiant au webmestre.
Les procédés décrits ci-dessus restent pratiquement identiques.
1. Racine standard du Site Web par défaut

Dans ce cas, la mise en ligne pour le webmestre reste tout aussi simple :
5. Copier sous Inetpub\wwwroot le contenu du site et non le répertoire le contenant
6. Configurer sous MMC le nom de la page d'accueil (Propriétés du "Site Web par défaut",
onglet "Documents", index.htm ou autre)
7. Démarrer le site si besoin
8. Tester en local le serveur Web de la façon suivante :
8.1. Depuis son navigateur, taper « http://localhost »
 apparition de la page d'accueil du site.
Dans l'exemple illustré (figure 84), seul le fichier "essai.htm" a été publié sous
"Inetpub\wwwroot".
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".
2. Dérouter la racine du Site Web par défaut

Le principe reste le même que celui décrit au niveau des services FTP.
Les deux copies d'écran qui suivent montrent l'arborescence physique réelle (figure 86) ainsi
que le résultat obtenu dans le gestionnaire de services MMC (figure 87).

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.

En préalable, le webmestre doit s'assurer des faits suivants :

• Le répertoire qui contient le site doit être déclaré comme partage Windows NT,
• Le serveur fonctionnant 24h/24, la station qui héberge le site doit fonctionner
pareillement.
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.
Au moment de la configuration, le serveur enregistre le nom d'utilisateur et le mot de passe

utile pour se connecter. Si le nom d'utilisateur n'apparaît pas, il faut utiliser la fonction de
recherche.
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.
Remarque : toutes ces redirections de répertoire (partage réseau ou redirection URL)

peuvent être envisagées à n'importe quel endroit du site Web : une rubrique du site, une page
du site.
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
• Le deuxième écran demande à préciser la localisation du site (figure 89) :

1.3. Cliquer sur le bouton "Parcourir" pour aller chercher sur la station abritant le
serveur le répertoire contenant le site
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)
 Pas de caractère "espace" au niveau du nom du répertoire virtuel.
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é.
Pour opérer, le webmestre doit , depuis l'explorateur Windows :

 sélectionner le répertoire qui abrite le site à publier,
 dans le menu contextuel, choisir l'option "Propriétés", puis l'onglet
"Partage Web" (figure 93)
 cocher "Partager ce dossier"
 saisir les différents paramètres de publication du répertoire virtuel au vu du
serveur (alias, permissions)
Le bouton "Ajouter" ouvre la possibilité de définir plusieurs alias pour le même site.

Figure 95
Les même possibilités existent sous Windows 98 ou Windows 2000.
3.3 Publication sous Windows 98

L'utilitaire n'est plus le gestionnaire de services Internet ou Microsoft Management Console,
mais le gestionnaire de services Web personnel.
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).

o L'action du bouton "Modifier" permet de changer l'un ou l'autre de ces

paramètres.
• Activer le document par défaut après l'avoir défini
o Plusieurs documents peuvent être indiqués et pris en compte.
• Activer l'exploration des répertoires (voir onglet "Répertoire de base", cartouche
"Permissions" des propriétés du Site Web sous Windows NT Station)
• Enregistrer le journal d'activités du site web (voir onglet "Site Web", cartouche "Journal",
des propriétés du Site Web sous Windows NT Station)
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.

Chapitre 3 : Serveur Microsoft IIS
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.
Ce document s'adresse principalement aux webmestres.
Les copies d'écran et commentaires de ce document proviennent de la version 4.0 de I.I.S.
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.
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.
1.2 Lancement de l'installation

Le lancement est identique à celui décrit dans le chapitre précédent "PWS". Le plus important au
départ est de lire, après la page d'accueil "Bienvenue", la page « Installation » qui indique
quelles sont les étapes préalables à celle-ci.
Pour accéder à des informations complémentaires, le webmestre clique sur les deux autres menus
(En savoir plus, Notes de mise à jour).
Figure 97
 le serveur ne s’installe pas si les composants suivants ne le sont pas :

• Service Pack 3.0 situé sur le même cédérom sous « Winntsp3\I386 » :
Nt4sp3_i.exe,
• Internet Explorer 4.0 situé sur le même cédérom sous « Ie401\X86 » :
Ie4setup.exe.
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.
1.4 Types d'installation

Que l'on installe PWS comme IIS, le programme propose les trois options suivantes :
• Installation minimale : composants minimaux nécessaires au fonctionnement de IIS.

• Installation par défaut : installation minimale ainsi que des fonctionnalités

supplémentaires et de la documentation.
• Installation personnalisée.
Le détail des composants installés par défaut est exposé en annexe.

Pour les utilisateurs expérimentés qui veulent choisir dans le détail les services, le troisième type
d'installation est conseillé.
1.5 Composants de l'installation personnalisée

L'avantage d'une installation personnalisée est de permettre, en fonction des compétences de
l'installateur et des services attendus, de cocher ou décocher à volonté. L'écran présenté figure 4
donne un aperçu des différents composants disponibles dont nous allons brosser une présentation
sommaire.
• Serveur NNTP
Il permet aux utilisateurs de l'entreprise d'engager des discussions au sein de l'entreprise
et en dehors de celle-ci. Ils peuvent lire des articles rédigés par d'autres utilisateurs,
envoyer leurs propres articles et participer à des conversations. Néanmoins, ce serveur de
news reste privatif car il fonctionne uniquement dans l'environnement Windows.
• Relais SMTP
Ce service, outre la fonction d'agent de transfert, comprend des fonctionnalités du
protocole SMTP: exploiter la commande mailto par exemple. Certaines options
permettent également de contrôler le routage et la remise des messages. Il manque un
serveur POP/IMAP pour en faire un véritable serveur de messagerie.
Figure 100

• Message Queue Server (MSMQ)

Ce service permet à des programmes d'application de communiquer plus facilement,
rapidement, en toute sécurité et de manière asynchrone avec d'autres programmes en
envoyant et en recevant des messages.
• Index Server 2.0
Il met à notre disposition un moteur de recherche. Le service Index Server permet
d'indexer automatiquement le contenu des pages HTML et celui d'autres documents
stockés sur des serveurs intranet d'entreprise. Le moteur de recherche des fichiers permet
de rechercher les formats de fichier Microsoft Office, HTML, ASP et NetShow en sept
langues.
• Site Server Express
Il permet aux administrateurs du site d'analyser les fichiers journaux du serveur, de
visualiser et d'analyser le contenu du site et de déployer facilement le contenu sur un
serveur IIS. Site Server Express propose les versions de base des fonctionnalités de
publication et d'analyse de Microsoft Site Server.
• Serveur de Certificats
Il s'agit d'un des composants de sécurité proposé par IIS. Il met en oeuvre des clés de
chiffrement utilisant la technique SSL (Secure Socket Layer).
Il permet de chiffrer l'accès au site, donc de gérer séparément une partie publique (non
protégée) et une partie privée (protégée par certificat d'accès) d'un même site. La
dénomination du service se justifie quand on parle d'authentification d'accès au site privé
certifiée par le serveur.
Côté navigateur "Internet Explorer", la partie cliente se configure dans "Options
Internet", onglet "Contenu", cartouche "Certificats".
• Service de Connexion Internet pour RAS
Ce service prévoit la mise en place de services de télécommunications sécurisés et
transparents via Internet, l'externalisation ou la réduction des coûts de Service d'accès
distant courants et la possibilité de proposer un accès à Internet personnalisé et à moindre
coût aux abonnés d'un fournisseur de services Internet. Ce service, proposé par PWS, voit
le nombre de connexions simultanés au serveur passer à 256 (au lieu d'une).
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.
1.7 Administration locale ou distante

Comme pour le serveur PWS, le webmestre peut se limiter à l'administration locale du serveur
(obligation pour lui de se rendre dans la salle des serveurs pour gérer de près ce dernier), ou alors
peut configuer l'administration à distance du serveur en question (depuis sa station bureautique).
Comme le suggère la figure 5, il faut prévoir avec quel compte d'administrateur le webmestre va
effectuer cette télégestion.
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.
1.8 Tour d'horizon des composants installés

Services (voir Panneau de Configuration / Services)
Outre les services de publication Web et FTP, et le service d'administration IIS, les autres
services sont gérables de la même façon :
 Microsoft NNTP Service
 Microsoft SMTP Service
 Index de Contenu
 Autorité de Certificat, etc…
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.

Comparativement à l’offre PWS, les sous-menus et options suivants sont rajoutés :

 "MS Index Server", "MS Site Server Express", "MS Message Queue Server" (menu non
présent dans la copie d'écran jointe car option non cochée lors de l'installation), "MS
Certificate Server (Commun)"
Figure 102
On retrouve par ailleurs les menus déjà présents sous PWS:

 Les sous-menus "MS Script Debugger", "MS Transaction Server", "Serveur de connexion
Internet pour RAS",
 Directement les options "Documentation en ligne", "Notes de Publication", et aussi
"Installation de…" :
• Cette option permet d'ajouter ou de supprimer des composants après insertion du
cédérom.
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)

o L'utilitaire « Gestionnaire des services (HTML) » se substituant au "Gestionnaire

de Services Web Personnel"
Cette application Web écrite en pages ASP est limitée à la gestion des seuls
services IIS (et non Index Server,…). Elle permet la gestion distante du serveur
via un interface Web.
Les deux autres sections du chapitre vont se focaliser sur l'utilisation de ces gestionnaires.
Explorateur sous Inetpub

Le programme installe le moteur du serveur sous Winnt\System32\inetsvr et les composants
relatifs aux bases de données sous "Program Files".
Mais le plus intéressant reste le répertoire de publication "Inetpub" (ou publication Internet). La
description de son contenu n'a pas varié de celle effectuée avec la version PWS.
Ajout d'utilisateurs spécifiques au fonctionnement du serveur sous Windows NT

Dans l'option "Gestionnaire des utilisateurs" du menu "Outils d'Administration Commun", on
constate la présence des même nouveaux utilisateurs : IUSR_nom d'hôte réservé aux connexions
anonymes des internautes, et IWAM_nom d'hôte réservé à la gestion des applications Web
publiées sur le serveur.
Figure 104
 Il est fortement conseillé de ne pas toucher à la configuration automatique de ces comptes,

notamment aux mots de passe connus du seul serveur (désynchronisation assurée).
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
INDEX HTTP / ODBC Server Sides

ASP
Server (IDC / HTX) Includes
Interface ISAPI
WEB Application Manager

Figure 107
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
HTMLA ADSI IIS Métabase
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.
2.2 Arrêt et Démarrage des Services

De même que sous PWS, l'arrêt et le démarrage du serveur peuvent être déclenchés de
différentes manières:
• en manoeuvrant le "Service Administration IIS" dans "Panneau de Configuration / Services"
• à l'aide des deux gestionnaires de services cités ci-avant.
2.3 Description du Gestionnaire MMC

Le principal outil d'administration local ou distant des services Internet reste le "Gestionnaire de
Services Internet" (ou MS Management Console ou MMC). Toutes les opérations et propriétés
des services sont configurables graphiquement à l'aide de cet outil.
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.
1er niveau : Console Root

Le premier niveau définit la console de supervision "racine" configurée par défaut.
Les paramètres de configuration de cette console sont enregistrés en fin de session dans le fichier
"iis.msc".
2ème niveau : Internet Information Server et Transaction Server

Le deuxième niveau définit les services installés (ou logiciels enfichables).
3ème niveau : la station

Le troisième niveau définit les stations à gérer.
4ème niveau de IIS : Site Web et Site FTP par défaut

Le quatrième niveau définit enfin les sites des deux services Internet installés.
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

• C'est à ce niveau que l'on constate une première différence entre PWS et IIS : pour PWS,
le champ « Nouveau » ne proposait que l’option « Répertoire virtuel » (car PWS 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.
2.4 Propriétés de la Station

Un seul onglet « Internet Information Server » (figure 15) nous est présenté pour gérer à ce
niveau (niveau "master") certains paramètres globaux à l'ensemble des sites publiés : non

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
2.5 Propriétés du Site Web

Pour configurer finement l'ensemble 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é (ou clic sur icône).
Un nouvel onglet apparaît : celui définissant les opérateurs autorisés à opérer à distance sur le
site. Les paramètres des huit autres onglets ont été présentés dans le chapitre précédent. Dans le
paragraphe qui suit sont évoqués les nouveaux paramètres spécifiques à IIS ainsi que des rappels
sur les paramètres importants du chapitre précédent.
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).

 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.
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.
<Nom d'en-tête de l'hôte>

Depuis les deux dernières fenêtres, apparaît ce nouveau champ configurable. Il s'agit
d'utiliser une des nouvelles fonctionnalités offertes par le protocole HTTP1.1 : le champ
ou 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 IIS.
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 pour le webmestre car il peut publier plusieurs sites sans démultiplier le nombre
d'adresses IP. Le webmestre peut ainsi masquer le nom de station hébergeant le serveur
par les noms génériques des sites publiés.
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.
Voici un exemple où le nom de domaine du serveur est "www.serveur.com", où le nom
générique du site indiqué comme nom d'en-tête de l'hôte est "www.example.com". Les
lignes qui suivent sont un extrait de l'en-tête protocolaire qui circule sur le réseau.
HTTP : Host = www.example.com

Il existe un préalable important à la mise en œuvre de cette possibilité : celle d'avoir

configuré le nom générique de site comme alias du nom de domaine du serveur dans le
serveur DNS de rattachement.
Un clic sur le bouton "Avancées" de la figure 17 permet de configurer les sites multiples
selon les deux identifiants décrits ci-dessus. La fenêtre de la figure 18 permet de modifier
ou d'ajouter. Un clic sur "Ajouter" ouvre la figure ci-dessous.
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.
Activer la limitation de bande passante

Ce cartouche n'est activé qu'avec la version IIS (figure 21).
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.
12. 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.
• Il faut veiller à l'ordre d'utilisation de ces filtres, par exemple le filtre SSL avant celui des
extensions FrontPage.
• A titre d'exemple, certains sont mis en place par défaut au niveau des propriétés de la
station (figure 22). Il est possible d'en rajouter (figure 23).
 L'utilisation de tels filtres peut ralentir les performances du serveur.
Figure 118

Figure 119

Cet onglet, en dehors de celui consacré à l'identification du site, est le plus important. Il
permet de localiser le site, sur la station hébergeant le serveur, ou ailleurs sur le réseau. Il
permet de définir les droits globaux d'accès au site.
Contrôle (d'accès au site)

• Accès au journal :
Tout accès au site est inscrit au journal.
• Autorisation (lire, écrire) :
Par défaut, la permission de lecture est accordée à tout internaute, celle d'écriture
ne l'est pas. Autoriser l'internaute à écrire revient à lui permettre de modifier le
contenu du source HTML de la page Web visitée depuis son navigateur
(dangereux).
• Contenu (parcourir) :
Dans le cas où la case est cochée, si l'internaute envoie une adresse erronée, le
serveur, au lieu de lui renvoyer le message d'erreur "erreur 404:page non trouvée",
affiche en réponse l'arborescence du site visité
• Indexer :
Cette option, accessible sous PWS, n'est valide que dans le cas de IIS. En effet,
seul IIS permet d'installer la fonctionnalité d'Index Serveur utilisée par les
moteurs de recherche.
Indexer les pages web du site permet au serveur de puiser des renseignements
qu'il range dans des fiches. Ces fiches vont alimenter au fur et à mesure de la
collecte un catalogue. Le moteur de recherche ira constituer les réponses à
renvoyer à l'internaute demandeur à partir des éléments du catalogue.
• Site Web FrontPage :
Cocher cette case permet de modifier à distance le site hébergé si l'hébergeur a
installé en vis à vis les extensions FrontPage.

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…

Le bouton "Configurer" de l'onglet "Répertoire de base" (figure 24) représente un

des moyens de publier une application interne à un site web donné.
La fenêtre "Configuration d'applications" (figure 25) ainsi lancée ouvre trois
onglets. Le bouton "Ajouter" du 1er onglet "Mappage d'applications" permet de
déclarer cette application (figure 26).
Figure 121
Figure 122
Le deuxième onglet "Options de l'application" (figure 27) permet au propriétaire du site

de bénéficier de pages de scripts ASP livrés avec le serveur pour gérer les sessions des
clients et leur délai de déconnexion, le délai d'exécution avant l'envoi de messages
d'erreur par exemple.

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.
15. Sécurité de répertoire

Cet onglet (figure 33) 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.
a) Connexions anonymes et contrôle d'authentification

En principe, les sites Internet sont accessibles à tout le monde. Aucune restriction d'accès
n'est donc mise en œuvre. En cliquant sur le bouton "Modifier", l'on constate que ces
connexions sont autorisées par défaut (figure 34). Les autres méthodes d'authentification ne
semblent pas nécessaires à priori.

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
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>

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.
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. Pour plus d'informations, le webmestre doit consulter la
documentation de sécurité du serveur Web.
Figure 131
Si l'on coche "Authentification de base", la fenêtre d'avertissement ci-dessus

s'affiche. En passant outre, une deuxième fenêtre s'ouvre et nous invite à saisir le
nom du domaine d'authentification.
Figure 132
Cette méthode d'authentification d'accès peut être choisie dans le cas où le

webmestre enlève les connexions anonymes et restreint l'accès aux seuls clients
du domaine d'appartenance du serveur Web, ainsi que ceux du domaine spécifié
dans la fenêtre suivante.
Les clients doivent à chaque accès préciser leur identifiants de connexion.
Remarque :

Il est déconseillé de désactiver l'authentification de base lorsque le service est

démarré. Il convient d'arrêter au préalable le service.
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.
<Stimulation / réponse de Windows NT>

Cette méthode, cochée par défaut avec celle des connexions anonymes, permet
d'authentifier les utilisateurs sans transmettre les mots de passe réels sur le réseau.
L'authentification au domaine sert d’authentification d’accès. Le navigateur
Internet Explorer de l'utilisateur prouve sa connaissance du mot de passe par un
échange cryptographique avec le serveur Web. L'utilisateur doit ouvrir dans ce
cas une session réseau (voir stratégie de compte).
L'authentification "Stimulation/réponse de Windows NT" est prioritaire par
rapport à l'authentification "De base" pour le navigateur Web de l'utilisateur.
Internet Explorer essaie d'utiliser les informations d'ouverture de session
Windows NT en cours avant de demander à l'utilisateur un nom d'utilisateur et un
mot de passe. Cependant, si l'identification de l'utilisateur échoue dans un premier
temps, Internet Explorer demandera à l'utilisateur de lui fournir un nom
d'utilisateur et un mot de passe de compte Windows NT.
Les extensions de serveur FrontPage authentifient le client avec cette méthode.
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
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é (figure 37).

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.
Prenons l'exemple d'un organisme d'enseignement comprenant des professeurs et des

élèves. Rendons le site privé accessible au corps enseignant et non aux élèves. Le
webmestre va utiliser les groupes globaux GG-prof et GG-eleve que l'administrateur du
domaine avait créé. En tant qu'administrateur local de la station hébergeant le serveur
Web, il va créer deux groupe locaux GL-prof et GL-eleve dans lesquels il va insérer les
deux groupes globaux. Posons les droits sur les groupes locaux de la façon suivante :
Administrateurs Contrôle total
GL-prof Lire
GL-eleve Aucun accès

Cela permet de bien gérer séparément les accès au domaine et ceux du serveur.
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.

c) restrictions IP par adresse et par nom de domaine

• Cette option n'est activée qu'avec la version IIS. En cliquant sur "Modifier", la fenêtre
suivante s'affiche.
Figure 134
• Avant de cliquer sur le bouton "Ajouter" ci-dessus, il faut décider de la politique

globale : autoriser tous les ordinateurs sauf …, ou les refuser tous sauf …
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).
16. En-têtes HTTP
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.

17. Messages d’erreurs
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

• Un certain nombre de paramètres décrits au niveau du site peuvent être redéfinis au

niveau d'un répertoire du site ou même d'une page Web donnée (figure 43).
• 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é.
• 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".
Cas particulier du Site Web d'administration

Le paramétrage effectué lors de l'installation ne doit pas être modifié sans compétence préalable.
On peut noter deux caractéristiques :

• l'attribution d'un numéro de port TCP aléatoire lors de l’installation, 4476 par exemple,
• la localisation du site sous « system32\inetsvr\iis ».
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.
2.6 Propriétés du Site FTP

Comme avec le serveur PWS, configurer un site FTP revient à modifier les propriétés du menu
contextuel. La fenêtre "Propriétés" affiche les cinq onglets déjà décrits dans la version PWS.
Nous nous attacherons à commenter ce qui diffère.
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
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
2.7 Administration à distance

Microsoft Management Console
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.
Pour bien comprendre la procédure, il faut distinguer le serveur de publication et la station

d'administration distante du webmestre. Pour administrer à distance les sites publiés depuis le
même outil "MMC", le webmestre est amené à installer un serveur web local à cette station. Ce

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.
Gestionnaire de Services Internet (HTML)

Le webmestre se connecte en fait à un "Site Web d'administration" configuré lors de
l'installation. L'utilisation de ce procédé via Internet pourrait se révéler dangereux car un intrus
pourrait s'infiltrer et agir sur l'administration du serveur.
Le lancement de ce gestionnaire en local sur le serveur (depuis le menu "Démarrer") permet de
découvrir en fin d'adresse URL le numéro de port du site à viser dans le cadre de l'administration
distante. Le numéro de port, attribué aléatoirement lors de l'installation n'est pas à changer.
Le gestionnaire "MMC", via les propriétés du "Site Web d'Administration", permet de retrouver
ce numéro de port.
Une fois le site Web d'administration atteint via le navigateur de la station distante (Internet
Explorer 4.0 minimum), le premier écran s'affiche (figure 50).
Outre le problème de navigateur, un deuxième écran de ce style s'affiche pour spécifier la taille
de la police à utiliser au niveau de l'interface. Au troisième écran apparaît le gestionnaire.

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.
3.1 Publication de Sites FTP

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é.
Les procédures permettant de remplir ces deux rôles ont déjà été décrites dans le chapitre
précédent portant sur PWS. Dans les lignes qui vont suivre, nous allons simplement décrire la
nouvelle procédure accessible : la publication de plusieurs sites.
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
 Dans "Microsoft Management Console", sélectionner le "Site FTP par défaut" ou le

serveur dans le volet de structure, puis choisir dans le menu contextuel l'option "Nouveau
/ Site" (figure 56),
 Créer autant de sites FTP dont la racine pointe vers "D:\ClientX",
 Fixer en premier pour chacun un nom de nœud différent (figure 57) visible dans le volet
de structure, ce nom personnalisant l'accès au site par le client,

Figure 153
 Aller chercher le site sur la station (bouton Parcourir figure 58),
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.
3.2 Publication de Sites Web

Adoptons la même démarche au niveau des sites Web.
Les procédés décrits dans le chapitre portant sur le serveur PWS et ci-dessus restent identiques.
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.

Rappel de la procédure pour changer ces paramètrs d'identification de site :

1. Dans la feuille de propriétés Site Web, cliquez sur le bouton Avancées.
2. Dans la feuille de propriétés Configuration avancée de site Web multiple, cliquez sur le
bouton Modifier pour attribuer un nom d'en-tête d'hôte, une adresse IP et un port à un site
Web.
Préalable au choix d'une autre adresse IP:
• Dans la configuration réseau de la station, il faut configurer cette autre adresse (onglet
TCP/IP, propriétés, avancées),
• Si à cette adresse IP correspond un nom de domaine équivalent, il faut configurer ce dernier,
soit auprès du serveur DNS de rattachement, soit en local sur le serveur dans le fichier réseau
"hosts".
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.

HTTP : Host = www.example1.com

HTTP : Host = www.example2.com
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.
4. Site Server Express 2.0

Le serveur IIS fournit de manière native au webmestre un outil de suivi des connexions et
d'analyse de site avant publication (Content Analyser), un outil d'aide à la publication des sites
de clients (Posting Acceptor), des outils de rapports d'activité (Report Writer et Usage Import).
L'ensemble constitue le composant "Site Server Express".
Ce composant intéresse tout autant les concepteurs que les responsables de sites.

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.
4.1 Menu Démarrer

Comme le montre la figure 60, le menu "Microsoft Site Server Express 2.0" présente différentes
options :
Figure 156
• un accès à la documentation d'ensemble du produit
Figure 157
• un lien externe vers le site de Microsoft dédié à la présentation de la version non bridée
de "Site Server"

La version non bridée, outre les rapports personnalisés, permet la réplication de

sites (Content Replication) vers des serveurs miroirs, le développement
d'applications (version complète de Visual Interdev).
• une aide à l'emploi de l'utilitaire de publication Posting Acceptor (figure 62)
Il utilise la méthode write, apport du procole HTTP1.1 permettant au client de
publier vers le serveur.
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

4.2 Compléments sur Content Analyser

Outre la présentation sommaire lisible depuis l'aide en ligne (figure 56), quelques compléments
semblent nécessaires pour expliquer son utilisation et son intégration au sein de la plate-forme
d'outils livrés avec le serveur.
Le cœur du logiciel gère une base de données spécifique Webmaps pour enregistrer les données
constitutives des cartes de site.
Au fur et à mesure du développement ou de la maintenance du site, son contenu évolue. Le
risque de voir des liens rompus augmente. Aussi le webmestre doit reconstituer la carte pour
repérer les liens brisés.
A la suite de chaque révision importante, il est conseillé de recréer une carte. Ces cartes
successives permettent de garder une trace des modifications intervenues sur le site. Elles
peuvent aider à la conduite de projet.
Le composant Content Analyser peut servir de plaque tournante aux applications de création ou
de révision de documents. Il suffit de sélectionner le fichier concerné sur le plan, puis de lancer
l'application.
4.3 Lancement de Content Analyser

L'utilitaire est installé sous "Program Files". Au départ, l'utilitaire demande s'il faut analyser un
nouveau site ou consulter une carte de site existante.
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

 Des options sont disponibles. La fenêtre "Options pour…" comporte quatre

onglets : options générales, restrictions, extensions et copie de site. Seul le
premier est configurable.
Figure 166
L'onglet "options générales" permet de singulariser l'analyse selon l'agent

de l'utilisateur (Mozilla/2.0, MSIE 3.0, Mozilla/3.0,etc…).
L'option "obéir au protocole robot" de l'onglet "générales" fait référence au
moteur d'indexation joint à la distribution IIS4.0.
o via l'explorateur (figure 71) en indiquant la page d'accueil du site : chemin d’accès
Figure 167

 L'indication du domaine est obligatoire alors que la localisation des

applications de type "cgi-bin" [parcourir] est facultative.
 Pour le domaine, il s'agit de savoir comment le webmestre va exploiter
l'analyse du site, en local ou à distance.
Figure 168
 La fenêtre "Options" présente trois onglets (figure 72): options générales,

restrictions, extensions. Seul le premier est configurable.
• le nom du fichier constitué à l'issu de l'analyse :

o Si le site est accessible depuis l'explorateur (fichier), une fenêtre « génération de
rapports » s'ouvre pour demander :
Figure 169
- Le nom du rapport sous forme de page Web : domaine _nomSitesummary.html.

- Il réalise par défaut une copie de carte dans le répertoire « rapports ».
o Sinon, il sauvegarde la carte pour analyse ultérieure sous Program Files\…\Webmaps.

- Le nom de carte proposé est du style : domaine_nomSite.wmp.
4.4 Présentation de l'interface

Une fois que le paramétrage est terminé, le logiciel constitue la carte. Puis la fenêtre s'ouvre et
découpe l'écran en deux zones (figure 74) :
• à gauche, un affichage hiérarchique du contenu du site
• à droite, l'affichage cyberbolique du contenu du site sous forme de toile d'araignée,
affichage reflétant la structure logique du site (la carte des liens) et mettant en exergue à
l'aide de changement de couleurs les liens rompus.
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.
Les icônes (figure 74) permettent respectivement de la gauche vers la droite :

• modifier les options de l’affichage cyberbolique (Options d'Affichage),
• exposer les liens d'un objet sélectionné (Affichage / Liens des Objets)
• afficher les propriétés d'un objet (Affichage / Propriétés)
• proposer des statistiques sur le site (Affichage / Site Statistics)
• explorer la carte à un certain niveau (Carte / Explorer le site),
• vérifier les liens (Carte / Vérifier les liens)
• générer des rapports (Outils / Générer des rapports),
o soit à partir du nœud sélectionné dans l’arborescence hiérarchique ou celui
sélectionné dans l’arbre cyberbolique, ou des deux,
o soit depuis la page d’accueil du site analysé,
• fournir une aide contextuelle à l'objet sélectionné (Sommaire de l'aide),
• choisir entre les deux modes de représentation :
o l'arborescence seule (Agrandir…),
o l’arbre cyberbolique seul (Agrandir l'affichage…),
o ou les deux (Arborescence et Affichage cyberbolique)
• orienter l'arbre cyberbolique : de droite à gauche ou centrée
• aligner les noeuds (Alignement)
• retourner à la page d'accueil du site sur les deux arborescences
• modifier la distance entre les nœuds de l’arbre cyberbolique.

Figure 170
Le menu "Afficher" (figure 75) offre l'accès aux:
Figure 171
• propriétés de l'objet sélectionné (figure 76)

Seul le premier onglet des quatre offre des informations.

Figure 172
• informations sur les liens (figure 77),
Figure 173
• statistiques du site complet (figure 78 et 79),

Les deux copies d'écran correspondent aux deux onglets.

Figure 174
Figure 175
Figure 176

• options d'affichage (figure 80),

Sur les deux onglets, seul l'onglet "arbre cyberbolique" est paramétrable finement.
• options du programme (figure 81).
Une fenêtre à quatre onglets s'affiche permettant au webmestre de régler des
points de détail.
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
• L'absence d'erreurs est certes bienvenue.
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.
Nombre de Mémoire minimale Mémoire recommandée

documents (en méga-octets) (en méga-octets)
Moins de 10 000 32 Idem
Moins de 100 000 32 32
100 000 à 250 000 32 64 à 128
Au niveau du disque dur, pour un gros site, le volume d'un catalogue peut représenter jusqu'à
40% du volume du site.

Il faut choisir alors la méthode "Personnalisée" pour cocher ce service supplémentaire. Un
certain nombre de sous-options sont disponibles. Attention, les fichiers système d'Index Server
sont nécessaires à son fonctionnement. Un deuxième niveau de menu intitulé "Ressources de
Langue" offre la possiblité d'indexer les pages de sites multilingues.

La boîte de dialogue "Répertoire du catalogue d'Index Server" indique l'emplacement de création

d'un répertoire nommé catalog.wci chargé de stocker le premier catalogue d'index élaboré lors
de l'installation.
Les fichiers d'Index Server sont copiés sur l'ordinateur aux emplacements suivants :
• les exemples de fichiers HTML et de script dans /Iissamples/Issamples,
• les fichiers d'administration dans /Iisadmin/Isadmin,
• les fichiers de documentation dans /Iishelp/Ix.
L'installation se termine par l'activation du service et l'indexation de ce qui est publié sous le site
web par défaut. Cela peut donc prendre un certain temps.
Tour des composants installés

Après le redémarrage de la station, on peut faire le tour des composants installés.
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.
Exécution d'une requête

Le schéma ci-dessous repose sur l'utilisation du triplet (htm,idq, htx) maintenant délaissé au
profit du fichier *.asp qui réalise seul l'ensmeble de la tache.
Le formulaire de requête proposé par IIS (sous iissamples/...) query.htm vise le fichier
query.idq qui gère le catalogue catalog.wci. Ces fichiers *.idq sont assimilables à des fichiers
de scripts ASP par lequels ils sont désormais remplacés. Ce dernier s'adresse au fichier
query.htx qui fournit la réponse au client. Le fichier *.htx est un modèle de page web.
Le gestionnaire des services d'une part, mais surtout le paramétrage des fichiers en question
permet de limiter la portée d'une requête en précisant les répertoires parcourus, mais aussi les
fichiers interrogés (pas forcément tous les documents d'un répertoire).
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
Les caractéristiques de base d'une requête sont les suivantes :

• Étendue
• Restriction
• Ensembles de résultats
La restriction teste chaque document de l'étendue pour déterminer s'il doit être renvoyé. Il s'agit
d'un ensemble de termes pouvant être combinés par divers opérateurs. L'ensemble de résultats
définit les informations à renvoyer en réponse à la requête.

L'administrateur du serveur ou du site peut imposer un nombre maximal de correspondances à

renvoyer. Par exemple, un ensemble de résultats comprenant 200 correspondances peut être
renvoyé au client en 10 pages de 20 correspondances chacune.
On peut aussi restreindre la requête en fonction de critères avancés.
Les mots recherchés peuvent être surlignés (highlighting).
Enfin, ces requêtes peuvent être historisés dans les fichiers journaux du serveur Web.
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.
5.4 Catalogue d'Indexation

Plusieurs cas de figure existent : a) publication d'un nouveau site, b) ajoût d'un nouveau
répertoire (virtuel ou non) à un site déjà publié.
Dans le premier cas, si l'administrateur de site souhaite intégrer cette fonctionnalité au nouveau
site, le webmestre constitue un catalogue d'indexation sur ce site et installe un moteur de
recherche spécifique.
Dans le deuxième cas, on suppose que le catalogue et le moteur de recherche soient déjà mis en
place. Il suffit alors d'élargir éventuellement l'indexation et la recherche au nouveau répertoire.
Quelle que soit le cas, la mise en œuvre du service d'indexation se fait en plusieurs phases.
Chacune de ces étapes peut faire l'objet d'un nouveau choix de la part de l'administrateur de site.
Les étapes sont les suivantes :
1. indexation du "site" publié par :
1.a constitution d'un nouveau catalogue (voir partie "Catalogue d'Indexation")
1.b élargissement d'un catalogue existant au nouveau répertoire (voir partie
"Ajout de Répertoires"),
2. choix d'un moteur de recherche en :
2.a privatisant les éléments constitutifs du "guichetier" chargé de répondre
aux questions de l'internaute (fichiers query.htm, query.idq et query.htx ou
fichier query.asp) dans le cas du nouveau site
2.b dans le cas d'un nouveau répertoire, modifiant l'étendue du fichier
query.idq du moteur existant si le suivi des racines virtuelles n'est pas
activé au niveau des propriétés du catalogue.
3. lier la page d'accueil du site vers le moteur de recherche :
 simplement dans le cas d'un "guichetier" privé

 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
Avant de constituer un nouveau catalogue, le responsable de site doit effectuer un dernier

choix : l'emplacement du catalogue.
Soit il est laissé dans son emplacement par défaut (arborescence de publication du serveur
principal sous Inetpub). Dans ce cas, il faudra au préalable supprimer le catalogue créé lors de
l'installation. Le choix de cet emplacement peut en entraîner un autre : celui d'utiliser le
"guichetier" en place sous iissamples, ou de privatiser sur place les trois éléments constitutifs du
moteur (*.htm, *.idq, *.htx ou *.asp).
Soit il est intégré au nouveau site indexé. Ce choix peut en entraîner un autre : celui de
dupliquer le "guichetier" ou moteur fourni sur son site et d'en faire un "guichetier" privatif.
Dans les deux cas, on pourra personnaliser le questionnaire initial, la recherche et les réponses.
La localisation du moteur peut ainsi rester indépendante de l'emplacement du site à indexer, et de
son catalogue.
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.
1. Avant de modifier l’arborescence des catalogues située sous « Index Server »

(suppression ou création), il faut prendre la précaution d'arrêter le service (clic droit).
2. Créons un catalogue (figure 93) pour le nouveau site ou nous précisons son nom (=
cours) jouant le rôle d'une étiquette pour MMC, son emplacement (= F:\catalog). Ainsi
(figure 94), le catalogue est en partie paramétré.

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
4. La fenêtre "Propriétés" (figure 95) nous propose trois onglets :

 onglet Emplacement
L'on retrouve les paramètres choisis lors de la création.
 onglet Web
C'est ici que l'on choisit le site à indexer (menu déroulant "serveur virtuel"),
Cours DMSI dans notre exemple. Une option déjà cochée nous demande s'il faut
effectuer le suivi des racines virtuelles (répertoires virtuels, redirections, etc…).

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
Modification de la Racine d'Indexation

Si l’on choisit de modifier définitivement la racine par défaut du service d'indexation
(emplacement du catalogue par défaut), alors il faut modifier la base de registres. Pour modifier
la base, il faut exécuter par exemple le programme « regedit ». Dans la ruche :
HKEY-LOCAL-MACHINE\SYSTEM\CurrentControlSet\Control\ContentIndex, la valeur
du paramètre IsapiDefaultCatalogDirectory est à modifier : par exemple "F:\catalog" au lieu de
"C:\Inetpub".
Les détails de cette procédure sont indiqués dans la documentation du Serveur.
En cas d'oubli de modification, dans le cas d'un fichier de requête *.asp, un message d’erreur du
type suivant apparaît :
<CreateRecordset erreur ‘8004181d’, il n'y a pas de catalogue, /iissamples/query.asp>
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.
Intégrer le Service au Site

Le but est de pointer depuis la page d'accueil du site (ou d'une autre page) vers le service en
question.
Si les trois fichiers sont intégrés au site, aucune procédure particulière n'est à envisager.
Si les trois fichiers du service, personnalisés ou non, sont restés à l'endroit initial, le webmestre
est invité à créer un répertoire virtuel vers l'endroit ou se situe le moteur.
1. Sélectionnons sous MMC le site Web concerné, "SitePerso" par exemple.
2. Ensuite, créons le nouveau répertoire virtuel en choisissant comme nom explicite
"iissamples", puis allons chercher le moteur par exemple sous
"Inetpub/iissamples/ISSAMPLES" (répertoire par défaut), sans oublier de cocher en
final les droits d’exécution.
3. Dans ce cas, le test consiste à saisir l'adresse : http://localhost/iissamples.
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.
Index Server Manager

Le choix de la deuxième entrée du menu lance une instance de MMC dédiée au seul service
d'indexation (figure 102).
Le composant d'Index Server, géré par MMC, est une appliquette nommée "ciadmin.msc" qui
permet :
• la vérification de l'état des catalogues,
• l'ajustement des propriétés globales,
• la création et la configuration des catalogues,
• l'ajustement du cache des propriétés,

• l'ajoût et la suppression des répertoires,

• le déclenchement d'une analyse,
• le déclenchement d'une fusion des index.
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é.
Index Server Manager (HTML)
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…
Pour en savoir plus sur l'administration du service, il convient de se référer à la documentation

en ligne. Celle-ci traite des sujets suivants :
• L'administration de base ou comment administrer Index Server en contrôlant
l'indexation, l'analyse et l'enregistrement.
• La sécurité.
• Les catalogues en explicant leur rôle, leur fonctionnement et comment les contrôler.
• L'indexation d'ordinateurs distants.
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.
Voici quelques exemples de livres :

• Administration et Optimisation de IIS 5.0 sous windows 2000
de W.Stanek - Microsoft Press - septembre 2001,
• Internet Information Server 4 - MCSE - octobre 1999 .

Chapitre 4 : Serveur Apache
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.1.1.2. Plate-forme UNIX

Le serveur Apache tourne sans adaptation particulière sur des plates-formes Unix telles que
Solaris, FreeBSD, QNX ou Linux.
Il tourne aussi sur des stations SCO Unixware, HP-MPE/iX (à partir de la version 6.0)
moyennant certains aménagements.
1.1.1.3. Autres plate formes

Il tourne aussi sur des plates-formes Novell Netware 5, ainsi que sur des plates-formes IBM
fonctionnant sous "MVS OS/390 Open Edition" ou OS/2.
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.
2.1 Sous Windows

Cette version est destinée à fonctionner avec les systèmes d'exploitation Microsoft Windows
NT4.0 et 2000. Il se peut que quelques fonctionnalités soient sans effet sous Windows 98 et 95.
Le programme d'installation ne fonctionne que sur des PC à base de microprocesseurs Intel x86.

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".

Le choix va dépendre du système d'exploitation. Le premier est conseillé dans le cas de

Windows NT ou Windows 2000 qui gère les services, le deuxième l'est dans le cas de Windows
95 ou 98 qui ne les gère pas.
Le cinquième écran (figure 4) demande à quel type d'installation on veut procéder : complète ou
personnalisée (custom). Le choix d'une installation personnalisée offre peu d'alternatives, sinon
de décocher des options.
Figure 206
L'écran suivant permet de changer le répertoire d'installation du serveur (figure 5).
Figure 207
Le dernier écran indique que l'installation est terminée.

1.1.1.5. Composants Installés

Le programme est accessible depuis le menu "Démarrer" (figure 6). Le menu "Apache httpd
Server" contient un certain nombre d'entrées qui diffère légèrement selon que l'on ait choisi
d'installer le serveur comme service ou non.
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

Quel que soit le mode, décrivons ces entrées :

• un sous menu "Configure Apache Server" pour accéder au principal fichier de
configuration du serveur "httpd.conf", ainsi qu'au programme de test de configuration de
ce fichier
• un sous menu "Review Server Log Files" pour consulter successivement le fichier
historique d'accès au serveur "Review Access Log" et celui des erreurs "Review Error
Log"
• une option "Apache docs online" obligeant le webmestre à se connecter à un des sites du
serveur (httpd.apache.org/docs/)
• une option "Help I'm Stuck" rassemblant les FAQ du logiciel
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.6. Organisation du Serveur

Toute l'arborescence du serveur est présente par défaut sous Program Files\Groupe Apache
\Apache. Décrivons la fonction des dossiers en suivant l'ordre alphabétique de la figure 10.
• Le dossier "bin" abrite différents exécutables en relation avec la
sécurité d'accès au serveur (htpasswd pour l'authentification de
base, htdigest pour l'authentification Digest ou MD5), ou le
fonctionnement des fichiers journaux.
• Le dossier cgi-bin est le dossier de publication des applications de
type CGI.
• Le dossier conf héberge les fichiers de configuration du serveur.
• Le dossier htdocs est en premier lieu le dossier de publication des
sites, mais il est aussi le repaire des pages de documentation en
ligne regroupés sous le dossier "manual".
• Le dossier "icons" renferme les icônes spécifiques au parcours du
site par l'internaute, si le propriétaire du site l'autorise.
• Les dossiers "include", "lib" et "libexec" renferment les différentes
bibliothèques nécessaires au fonctionnement du serveur. Figure 212

• Le dossier logs contient les fichiers historiques d'accès et d'erreurs.

• Le dossier "modules" accueille les modules additionnels (ou plug-
in) qui permettent d'activer des fonctionnalités au serveur.
• Le dossier "proxy" sert de cache interne au serveur.
• Le dossier "src" renferme les fichiers sources du serveur.
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.
Incident : le serveur ne se lance pas.

Pour déboguer, il faut lancer le serveur sous une fenêtre MS-DOS (se rendre là ou est le
programme Apache.exe pour le lancer). Ce dernier en cas d’échec signale l’erreur.
Sinon, il faut consulter le fichier "error.log" sous log, sinon les FAQ.
En cas de problème majeur, ne pas hésiter à réparer ou carrément désinstaller par la procédure
habituelle "Ajoût / Suppression de Programmes". Il suffit d'opter pour l'un ou l'autre choix selon
la fenêtre ci-dessous.
Figure 214
1.1.1.9. Fonctionnement spécifique

Parce que la version d'Apache pour Windows est multitraitements (multithreaded), elle n'utilise
pas de processus différent pour chaque requête à l'image de la version UNIX. Au lieu de cela,
seulement deux processus Apache sont lancés : un processus parent, et un processus enfant qui
gère les requêtes. Le processus enfant gère pour chaque requête une unité élémentaire de
traitement séparé (thread).
Aussi est-il recommandé d'utiliser un chiffre élevé pour le nombre de requêtes exécutées par le
seul processus enfant, d'où la valeur par défaut "0" (illimité) de la directive
MaxRequestsPerChild.

L'autre directive à valeur spécifique représente le nombre maximum de connections que le

serveur peut manipuler simultanément. La directive ThreadsPerChild initialisée à la
valeur 50 peut être augmentée en fonction du nombre de visiteurs.
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.
2.2 Sous UNIX

La procédure d'installation décrite concerne le système d'exploitation LINUX, et plus
particulièrement la distribution Mandrake 8.1.
1.1.1.10. Récupération des ressources
Si le serveur Apache n'a pas été mis en place lors de l'installation du système d'exploitation, il est
possible de le faire en récupérant les empaquetages adéquats.
Deux modes opératoires sont proposés : soit récupérer les éléments disponibles sur le cédérom
d'installation du système d'exploitation, soit télécharger la dernière version disponible
depuis le site mère du consortium www.apache.org.
1.1.1.11. Installation suite à téléchargement

Dans le deuxième mode opératoire, le serveur nous parvient sous la forme d'un fichier
d'archive UNIX compressé à l'aide de l'utilitaire "tar" :
• "apache-1.3.20.tar.gz" par exemple.
L'inconvénient de cette méthode est de récupérer non pas les fichiers exécutables du serveur,
mais ses fichiers sources en langage C qu'il faudra ensuite compiler.
Les fichiers sources sous UNIX s'installent sous /usr/…/src (localisation du répertoire variable
selon les distributions).
Après s'être déplacé dans le répertoire indiqué ci-dessus (cd /usr/…/src), nous décompressons le
fichier et restaurons l'archive, obligatoirement à l'aide du même utilitaire, tout ceci en une seule
commande :
• tar zxvf apache-1.3.20.tar.gz
L'option "z" décompresse, l'option "x" extrait ou restaure l'archive, l'option "v" commente
l'opération, et l'option "f" obligatoirement en dernier désigne le fichier cible à traiter.

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

(+) mod_dir .......……. Directory and directory default file handling

(+) mod_autoindex ..... Automated directory index file generation
Access Control
(+) mod_access ...…... Access Control (user, host, network)
(+) mod_auth ......…... HTTP Basic Authentication (user, passwd)
(-) mod_auth_dbm ..... HTTP Basic Authentication via Unix NDBM files
(-) mod_auth_db ...…. HTTP Basic Authentication via Berkeley-DB files
(-) mod_auth_anon .... HTTP Basic Authentication for Anonymous-style users
(-) mod_digest ....…... HTTP Digest Authentication
HTTP response
(-) mod_headers ..….. Arbitrary HTTP response headers (configured)
(-) mod_cern_meta … Arbitrary HTTP response headers (CERN-style files)
(-) mod_expires .….... Expires HTTP responses
(+) mod_asis .....….... Raw HTTP responses
Scripting
(+) mod_include .…... Server Side Includes (SSI) support
(+) mod_cgi .......…... Common Gateway Interface (CGI) support
(+) mod_actions .…... Map CGI scripts to act as internal `handlers'
Internal Content Handlers
(+) mod_status ....….. Content handler for server run-time status
(-) mod_info .....….... Content handler for server configuration summary
Request Logging
(+) mod_log_config .. Customizable logging of requests
(-) mod_log_agent .... Specialized HTTP User-Agent logging (deprecated)
(-) mod_log_referer .. Specialized HTTP Referrer logging (deprecated)
(-) mod_usertrack ..... Logging of user click-trails via HTTP Cookies
Miscellaneous
(+) mod_imap ......…. Server-side Image Map support
(-) mod_proxy ....….. Caching Proxy Module (HTTP, HTTPS, FTP)
(-) mod_so .......……. Dynamic Shared Object (DSO) bootstrapping
Experimental
(-) mod_mmap_static .. Caching of frequently served pages via mmap()
Development
(-) mod_example ...... Apache API demonstration (developers only)
(+) = enabled per default [disable with --disable-module]
(-) = disabled per default [enable with --enable-module ]
La compilation est exécutée simplement en tapant la commande make. Il est possible de garder
une trace de la compilation dans le fichier "make.log" en exécutant la première commande, puis
en consultant la trace à l'aide de la deuxième :
• make > make.log
• tail -f make.log
Une autre possibilité pour vérifier la compilation (et édition de liens) est de lancer après make la
commande make check.
La phase d’installation est aussi accessible que la compilation. Elle s’effectue en tapant la
commande make install. De la même façon, il possible de garder une trace de l’installation en
tapant :

• make install > install.log

• tail -f install.log
1.1.1.12. Installation avec cédérom

Le premier mode opératoire, lui nous demande d'installer les différents éléments du serveur.
Cette méthode a pour inconvénient de ne pas être paramétrable. Il faut d'abord accéder au
répertoire du cédérom d'installation contenant ces empaquetages. Pour cela, nous exécutons les
commandes successives :
• "mount /mnt/cdrom" (ou mount /dev/cdrom /mnt/cdrom) pour accrocher le lecteur
cédérom au système UNIX,
• "cd /mnt/cdrom/Mandrake/RPMS" pour se déplacer sur le lieu des empaquetages
• "ls apac*" pour lister les différents composants dont le nom commence par apache
• quatre composants (version 1.3.14) sont donnés en réponse (six pour la version 1.3.20):
o apache-… (ce qui suit le tiret exprime la version du composant),
o apache-common-…, apache-suexec- …,
o apache-manual-… (documentation disponible depuis la version 1.3.20)
o apache-modules-… (modules du serveur servis séparément depuis la version
1.3.20)
o apache-mod-perl-… (pour les sites applicatifs contenant des scripts perl)
Si une version précédente était en place, il est plus propre et plus sur de la désinstaller avant de
procéder à une nouvelle installation.
Les empaquetages des distributions RedHat et Mandrake portent toutes l'extension *.rpm. Outre
les divers logiciels graphiques disponibles pour installer ces empaquetages (kpackage, gnorpm,
etc…), il existe aussi la commande en ligne "rpm" munie de toutes les options nécessaires.
Avant de supprimer le service, il faut arrêter le serveur si celui-ci fonctionnait. La commande "ps
-ef | more" nous renseigne sur son activité (présence d'une ligne mentionnant le service httpd).
Dans le cas positif, la commande "/etc/rc.d/init.d/httpd stop" arrête son activité.
Pour désinstaller, après s'être déplacé dans le répertoire contenant les empaquetages, il faut
lancer :
• "rpm -qa | grep apache" pour connaître les empaquetages précédemment installés
• "rpm -e (ou -ev) apache-..." pour chaque empaquetage listé
La commande est complétée par les arguments suivants si la précédente version s'était vue
rajoutée des modules complémentaires tels PHP ou Perl : rpm -ev apache-... mod-perl mod-php.
Pour plus de précautions, il convient de copier les empaquetages nécessaires sous /tmp
(commande "cp apac* /tmp"). Pour installer les différents empaquetages, on lance pour chacun
d'eux la commande :
• rpm -ivh apache-…
Un message d'échec nous parvient précisant qu'il manque telle librairie. En fait, il est obligatoire
d'installer l'empaquetage "mm-1.1.3-…" (Shared Memory Abstraction Library) avant le reste car
il contient la librairie "libpq.so.2.0" indispensable au fonctionnement du serveur. Comme

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)
1.1.1.13. Lancement du serveur

Pour démarrer, plusieurs choix sont offerts :
• soit utiliser un utilitaire spécifique (sous /usr/sbin) : apachectl start
• soit lancer le script de démarrage situé sous /etc/rc.d/init.d/ : ./httpd start
La variante "./httpd status" permet d'interroger l'état du serveur :
Apache is not running.
Use ./httpd extendedstatus for more information.
Si la directive ExtendedStatus est activée (voir section Administration), il est possible d'avoir
plus d'informations.
Pour vérifier que le serveur Web s'exécute normalement, il suffit de lancer la commande "ps".
Au lancement, le serveur Apache lit le fichier de configuration httpd.conf.
1.1.1.14. Organisation du serveur

L'emplacement du serveur varie avec les distributions Linux et les versions du serveur. Depuis
la version 1.3.14, l'organisation a été considérablement modifiée mais stabilisée.
Figure 215
• Les répertoires de publication se situent sous /var/www.

o Le répertoire cgi-bin pour les applications de type CGI

o Le répertoire html est le répertoire du site de publication par défaut

 Il contient non seulement le fichier index.shtml (figure 13) constituant
la page par défaut du serveur, mais aussi d'autres fichiers comme
"optim.html" pour les nouveautés de la distribution
Figure 216
 Le répertoire addon-modules (optionnel) contient une page

d'explication sur l'emploi des modules (HOWTO-get-modules.html), ainsi
que des liens vers la documentation portant sur les modules additionnels
(perl, php, ssl)
 Le répertoire manual héberge la documentation en ligne en anglais
(lien symbolique vers /usr/share/doc/apache-manual-1.3.20/).
o Le répertoire icons est le répertoire contenant toutes les icônes de représentation
des dossiers et fichiers. Ils sont utilisés lorsque le webmestre autorise l'internaute
à parcourir l'organisation du site.
o Le répertoire perl (optionnel) contiendrait les scripts perl.
• Les fichiers de configuration se trouvent sous /etc/htppd.
o Le répertoire conf stocke les fichiers de configuration.
Le fichier httpd.conf attendu, mais aussi depuis la version 1.3.20 le

nouveau fichier " commonhttpd.conf " servant de fichier d'exemple de
configuration, mais encore le fichier "httpd-perl.conf" si le module perl
est installé.
 Les fichiers magic.default et magic (idem sous Windows)
 Le fichier apache-mime.types
 Le sous-répertoire addon-modules contient au départ le seul script
perl "proxied_handlers.pl", et le fichier "php.conf" si le module php est
installé.
 Le sous-répertoire Vhosts contenant trois fichiers de configuration :
Vhosts.conf, DynamicVhosts.conf, VirtualHomePages.conf
 Depuis la version 1.3.20, un sous-répertoire bak contenant des
sauvegardes du fichier de configuration httpd.conf du style
"httpd.conf- an-jour-mois-hr.mn.sec".
 Le sous-répertoire ssl si les extensions ont été installées.
o Le répertoire logs stocke les fichiers journaux du serveur. En fait, sous /etc/httpd,
il s'agit d'un lien symbolique pointant vers /var/log/httpd.
 Le fichier access_log contient les informations concernant les accès au
serveur. Chaque ligne est par défaut de la forme :

160.192.22.182 - - [12/Nov/1998:10:35:44 +0000] "GET / HTTP/1.0" 200 1294

160.192.22.182 - - [12/Nov/1998:10:35:45 +0000] "GET /images/M0qqv92s.gif HTTP/1.0" 200 6083
160.192.22.182 - - [12/Nov/1998:10:35:46 +0000] "GET /images/Fworkanm.gif HTTP/1.0" 200 37048
Les différents champs indiquent respectivement la provenance de la
connexion (adresse IP), la date et l'heure de la connexion, le nom de la
page vue, le code protocolaire de lecture ainsi que la taille en octets du
fichier lu.
Chaque ligne est appelée un hit. Pour peu qu'une page HTML contienne 10
images, le fichiers journal contiendra 11 lignes relatives à l'envoi de cette
page.
 Le fichier error_log contient les messages d'erreurs produits par le
serveur. C'est donc un fichier fort utile dans le cas de débogages de
programmes CGI ou de surveillance d'une application.
[Thu Nov 12 10:54:52 1998] [error] File does not exist: h:/apache/donnees/nouveau_site/delphi/blegtext.gif
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 fichier httpd.pid, contenant le numéro de processus du serveur, est sous /var/run.
• Le serveur lui-même dont la localisation varie selon les versions successives du serveur :
ici sous /usr/sbin.
• Le cache interne du serveur sous /var/cache/httpd.
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.
On dénombrait trois fichiers majeurs de configuration avant la version 1.3.14 :

• le fichier access.conf contenant les instructions des droits d'accès au serveur, aux sites
publiés, ou même aux dossiers internes aux sites (voire les pages)
• le fichier srm.conf contenant les instructions de publication des sites

• le fichier httpd.conf contenant les directives propres au fonctionnement du serveur lui-

même
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".
Les fichiers de configuration contiennent un certain nombre de directives respectivement

activées ou non selon la présence ou l'absence du caractère "#" en début de ligne (caractère
annonçant une ligne de commentaire pour l'interpréteur de commandes sous UNIX).
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.
1.1.1.15. Fichier httpd.conf

Ce fichier comprend trois sections de base :
• Section 1: Global Environment
Elle regroupe les directives qui contrôlent les opérations du serveur dans
son ensemble.
• Section 2: 'Main' server configuration
Ses directives définissent les paramètres du serveur 'principal' (main) ou
par 'default'. Elles ne répondent pas aux requêtes visant un hôte virtuel.

Les concepteurs du serveur Apache emploient le terme d'hôtes virtuels (ou

serveurs virtuels) pour désigner les sites publiés autres que le site par
défaut sous la racine de publication.
Ces directives fournissent aussi des valeurs par défaut pour la
configuration de tous les hôtes virtuels.
• Section 3: Virtual Hosts
Cette section concerne exclusivement les hôtes virtuels.
### Section 1: Global Environment
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
# Le nombre de secondes pendant lesquelles le serveur Apache attendra une requête

# postérieure avant de rompre une connexion. Dès qu'une requête est reçue, la valeur de
# la temporisation spécifiée par la directive Timeout s'applique.
KeepAliveTimeout 15
Les paramètres dont les valeurs sont chiffrées sont là pour régler finement les
performances du serveur.

# Nombre maximal de requêtes par connexion

MaxRequestsPerChild 0
# Nombre de threads concurrents par connexion
ThreadsPerChild 50
Le serveur Apache sur les systèmes Win32 crée toujours un processus enfant pour
manipuler les requêtes (une deuxième fenêtre s'affiche fugitivement au lancement du
serveur). S'il meurt, un autre processus enfant est créé automatiquement. Dans son
fonctionnement interne, le processus gère autant d'unités élémentaires de traitement
(threads) que de requêtes d'internautes. Les directives précédentes controlent le
comportement de ces threads et processus.
# Cette option permet d'assigner une adresse IP ou un numéro de port à un hôte virtuel.
#BindAddress *
Si le serveur Apache dispose pour son usage exlusif d'une plage d'adresses pour publier
les différents sites (le serveur FTP a la sienne, etc…), le webmestre peut :
o ne pas assigner une adresse à un site d'où la valeur *,
o en assigner une pour l'ensemble du service ou à un hôte virtuel particulier.
La directive rend possible ici l'indication d'un numéro de port autre que celui indiqué par
la directive Port.
Dans le cas d'une adresse IP unique, la syntaxe suivante est conseillée : *:numéro de port.
Dans le cas de plusieurs adresses sur la station, si le numéro de port autre n'est pas
assigné à une adresse, la syntaxe reste identique, sinon il suffit de faire précéder le
numéro de port par l'adresse IP : 16.19.150.121:3000 par exemple.
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
### Section 2: 'Main' server configuration
# Le port TCP d'accès au serveur est par défaut le port 80.

Port 80
# Adresse de la personne responsable du serveur.

ServerAdmin webmestre@esat.terre.def
# 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

au serveur de chercher le fichier /Program Files/Apache Group/Apache/htdocs

/geo.htm.
# Chaque répertoire de publication peut être configuré en vue d'autoriser ou de désactiver
# des facilités d'accès. Ce qui est défini à un niveau donné est répercuté au niveau de
# l'ensemble des sous-répertoires.
# Au niveau de la racine du serveur (ServerRoot) se configure un jeu de permissions par
# défaut très restrictif.
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
# Directives d'accès concernant le répertoire de publication par défaut.

<Directory "C:/Program Files/Apache Group/Apache/htdocs">
#Options None | All | Includes | Indexes | FollowSymLinks | ExecCGI | MultiViews

# Ces valeurs utilisées selon les besoins sont là pour respectivement : interdire l'accès,
# tout autoriser (sauf Multiviews), autoriser les SSI, autoriser le parcours du site,
# autoriser l'exploitation des liens symboliques, permettre l'exécution des applications de
# type CGI.
# L'option MultiViews accompagne l'option Indexes pour le parcours du site. L'emploi de
# cette valeur nécessite le développement d'un commentaire spécifique.
Options Indexes FollowSymLinks
Cette directive est importante dans la mesure où elle fixe les droits d'accès côté serveur
aux fichiers déposés sous le répertoire de publication (à comparer aux droits de lecture,
parcourir, exécution du monde Microsoft). Des renseignements complémentaires sont
apportés au sein de la section "Protection du Site".
# Permet de gérer les droits d'accès aux fichiers et répertoires des sites selon le contenu
des fichiers ".htaccess".
AllowOverride None
Cette directive est tout aussi importante puisqu'elle fixe les conditions d'accès aux pages
du site, selon les indications écrites dans des fichiers .htaccess. L'emploi de fichiers
".htaccess" est très prisé car il permet de modifier les droits d’accès sans avoir à
redémarrer le serveur.
La valeur None demande au serveur d'ignorer les fichiers en question. La valeur All
demande au contraire de prendre en compte la totalité du contenu de ces fichiers. Les
autres valeurs sont explicitées dans la section "Protection d'un site".
# Contrôle l'accès au site en fonction de la provenance des requêtes à l'aide des deux
# directives allow et deny précédées de la directive order indiquant dans quel ordre
# (important) traiter les deux précédentes.
order allow,deny
allow from all
</Directory>
Cette directive permet en fait de filtrer les adresses IP (ou réseaux, ou…) des clients. Le
paragraphe consacré à la protection du site donnera de plus amples explications.

# 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
# Nom du fichier contenant les informations d'accès à un répertoire.

AccessFileName .htaccess
Il est possible d’ajouter un fichier .htaccess dans chaque répertoires à partir de
DocumentRoot. Ce fichier contient des directives particulières pour le répertoire où il se
trouve ainsi que pour tous les sous-répertoires.
Ce fichier est relativement important pour personnaliser ou protéger l'accès à un
répertoire du site ou à une page Web donnée. La section consacrée à la protection du site
donne de plus amples explications.
# Avec la valeur "on", la directive force le serveur à utiliser ses paramètres ServerName
# et Port pour élaborer la réponse HTTP au lieu d'utiliser le nom réel de la station ainsi
# que le numéro de port visé par la requête du client (valeur off).
UseCanonicalName on
<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

# Donne le niveau de sévérité des alertes à enregistrer dans le fichier d'erreurs.

LogLevel warn
Voici les différentes valeurs et leur signification.
Niveau Signification
Debug les messages de mise au point
Info informations de fonctionnement
Notice conditions normales mais significatives
Warn petits problèmes non graves
Error conditions d’erreur
Crit niveau critique perturbant le fonctionnement
Alert il faut réagir immédiatement
Emerg système inutilisable
Lorsqu’un niveau donné est demandé, tous les messages des niveaux supérieurs sont
affichés.
Voici un exemple du fichier "error.log".
Apache server shutdown initiated...
[Mon Dec 24 07:59:55 2001] [error] forcing termination of child #0 (handle 104)
[Mon Dec 24 14:59:23 2001] [error] [client 127.0.0.1] File does not exist: c:/program files/apache group/
apache/htdocs/date.php
[Fri Dec 28 11:49:15 2001] [error] [client 127.0.0.1] client denied by server configuration: c:/program
files/apache group/apache/htdocs/server-status
# Format des enregistrements dans les fichiers historiques

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-
Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
# 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

#CustomLog logs/agent.log agent
# 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>
# Permet de définir le chemin d'accès par défaut des applications CGI.

ScriptAlias /cgi-bin/ "C:/Program Files/Apache Group/Apache/cgi-bin/"
<Directory "C:/Program Files/Apache Group/Apache/cgi-bin">
AllowOverride None
Options None
</Directory>
</IfModule>
La publication des applications CGI sous Apache est commentée par ailleurs dans le
module "HTML dynamique", chapitre "Applications Web".
# Permet de rediriger l'URL url1 n'existant plus vers un nouveau serveur désigné par
# l'URL url2. Cette directive peut être répétée sur plusieurs lignes.
# Redirect url1 url2
<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^^
# Lorqu'aucune icône n'est associée à un fichier, l'icône suivante est affichée.

DefaultIcon /icons/unknown.gif
# Permet d'assigner un commentaire derrière les fichiers générés dans les affichages de
# répertoires. Format: AddDescription "description" filename
# Nom du fichier explicatif affiché par le navigateur lors de l'affichage des répertoires.
#ReadmeName readme.txt
# Fichier d'en-tête précédant l'affichage de la page des répertoires.
#HeaderName HEADER
# Fichiers ignorés lors de l'affichage d'un répertoire
IndexIgnore .??* *~ *# HEADER* README* RCS
</IfModule>

<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
# Association des erreurs avec des textes appropriés.

#ErrorDocument 500 "Le serveur a commis une erreur
# Association des erreurs avec un fichier HTML (redirection locale)
ErrorDocument 404 /missing.html
# Association des erreurs avec un programme style SSI (redirection locale)
#ErrorDocument 404 /cgi-bin/missing_handler.pl
# Association des erreurs à une redirection externe
#ErrorDocument 402 http://some.other_server.com/subscription_info.html

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 :

• la date courante et celle du dernier démarrage du serveur (Restart), d'où la durée de

fonctionnement deux lignes plus loin
• le nombre de transactions, le volume de pages renvoyées, des performances par
seconde
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>
# Active ou non l'utilisation des en-têtes protocolaires HTTP/1.1.

# ("Full" ajoute la version du serveur; "Block" ote tout outgoing Via: headers)
# Valeurs possibles: Off | On | Full | Block
# ProxyVia On
# Répertoire de cache interne au serveur.

# CacheRoot "C:/Program Files/Apache Group/Apache/proxy"
# Taille du cache en mégaoctets
#CacheSize 5
# Vérification toutes les 4 heures du volume du cache, et élimination de fichiers si le
# volume dépasse celui indiqué ci-avant.
#CacheGcInterval 4
# Nombre d'heures d'expiration du cache
#CacheMaxExpire 24
# La date d'expiration de documents est fixée par le serveur Apache lui-même, selon une

# 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.
3.2 Spécifique Windows

Le serveur Apache met en place deux fichiers par fichier de configuration : un fichier par
défaut " httpd.default.conf" que l'on ne modifie pas, un autre fichier " httpd.conf" que l'on
va modifier. Il en est de même sous le répertoire conf pour les autres fichiers de
configuration cités dans le fichier principal.
### Section 1: Global Environment
<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
### Section 2: 'Main' server configuration
# 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
3.3 Spécifique UNIX

# Depuis les nouvelles versions d'Apache, l'utilisation des fichiers access.conf et srm.conf
# est délaissée au profit du seul fichier httpd.conf.
# Ces deux directives restent utilisées par certains modules, les extensions FrontPage par
# exemple.
ResourceConfig /dev/null
AccessConfig /dev/null
Pour désactiver ces fichiers de configuration, au lieu de laisser les commentaires, il est
possible d'indiquer le nom du fichier "néant".
# ------------------------ Dynamic shared object (DSO) support ---------------------------------
#
# Pour plus de renseignements sur les modules, consulter le fichier README.DSO ou la
# documentation sous /var/www/manual/mod au format HTML.
# La liste des modules installés est accessible par la commande : httpd -l.
LoadModule …
ClearModuleList
AddModule …
# ------------------------ Name Space and Server Settings ---------------------------------------

# Localisation de la racine de publication du site par défaut.
DocumentRoot /var/www/html
# Nom du répertoire conteant les répertoires personnels associés aux utilisateurs.

UserDir public_html
# Nom des pages d'accueil des sites

DirectoryIndex index.html index.php index.php3 index.shtml index.cgi

FancyIndexing on
# AddIconByEncoding …
… AddEncodingByType … AddIcon … DefaultIcon … ReadmeName … HeaderName
… IndexIgnore … AccessFileName
TypesConfig /etc/httpd/conf/apache-mime.types
… DefaultType … AddEncoding … AddLanguage … LanguagePriority … Redirect
# Liste des alias ou répertoires virtuels.

Alias /icons/ /var/www/icons/
Il est possible de définir un alias pointant vers le répertoire de connexion d'un utilisateur,
par exemple : Alias ime ~gmaire.
# Alias pour les applications de type CGI.
ScriptAlias /cgi-bin/ /var/www/cgi-bin/
# Répertoire dédié aux applications CGI s'exécutant dans un espace mémoire protégé.
ScriptAlias /protected-cgi-bin/ /var/ww/protected-cgi-bin/
… AddType … AddHandler … Action … MetaDir … MetaSuffix … ErrorDocument
# Détermination des types de fichier à envoyer au client.

#MimeMagicFile /etc/httpd/conf/magic
… BrowserMatch
# ----------------------------------- Global Access Configuration -------------------------------

<Directory />…
<Directory /var/www/cgi-bin>…
<Directory /var/www/protected-cgi-bin>…
<Location /server-status>…
Alias /doc /usr/share/doc

<Directory /usr/share/doc>…
# ---------------------------------- Server Configuration -----------------------------------------

ServerType … Port … HostNameLookups
# La directive User attend le nom d'utilisateur UNIX "anonyme" ou numéro d'UID de ce

# dernier sous lequel le serveur accède aux ressources de l'ordinateur (nobody avant la
# version 1.3.14).
User apache
# 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
ServerName … UseCanonicalName … CacheNegotiatedDocs … Timeout … KeepAlive

MaxKeepAliveRequests … KeepAliveTimeOut
# Nombre d'instances de serveurs au démarrage.

StartServers 10
# Nombre minimum de serveurs en attente de connexion.
MinSpareServers 8
# Nombre maximum de serveurs en attente de connexion.
MaxSpareServers 20
Le serveur Apache lance par défaut au démarrage plusieurs instances de lui-même (ici
10). Si le nombre minimum est atteint, le serveur "père" lance d'autres instances.
Une augmentation de fréquentation du serveur oblige l'administrateur à revoir les valeurs
à la hausse. Dans un deuxième temps, il faudra augmenter les performances matérielles
de la station (RAM, CPU).
# Nombre maximal de connexions limitant en réalité le nombre de serveurs simultanés.
MaxClients 150

# Nombre maximal de requêtes par connexion

MaxRequestsPerChild 500
Pour commenter l'exemple ci-dessus, nous pouvons dire que dans la limite des 150
clients, si une instance de serveur (child) dépasse les 500 transactions effectuées, alors il
meurt et une autre instance prendra le relais.
# Emplacement d'un cache local au serveur Apache
#CacheRoot /var/cache/httpd
#CacheSize … CacheGcInterval … CacheMaxExpire … CacheLastModifiedFactor …
#CacheDefaultExpire … NoCache
######################
# 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

# activée, le serveur Apache créera un fichier journal de type /var/log/httpd/VLOG

# -YYYY-MM-<ServerName>.log au lieu de remplir le fichier access_log. Il est
# conseillé de l'utiliser au lieu de définir un fichier journal spécifique à chaque hôte,
# autrement les descripteurs de fichiers sont abusivement consommés.
# - Il est aussi possible de spécifier un chemin pour la directive VLOG pour chaque
# hôte virtuel; par exemple, placer les journaux dans le répertoire de chaque utilisateur.
# Cependant, si l'on veut utiliser le fichier pour des raisons statistiques, on le place dans
# un répertoire dont l'administrateur est le propriétaire, sans quoi l'utilisateur pourrait
# l'effacer.
# - Il est suggéré d'inclure la directive ErrorLog seulement si l'hôte virtuel utilise les
# scripts cgi. Encore une fois, cela économise des descripteurs de fichiers !
# - Nous avons ajouté la directive Rewrite de façon que les hôtes virtuels travaillent avec
# la configuration PERLPROXIED.
################# Exemple d'Hôte Virtuel à base d'adresse IP

#<VirtualHost 192.168.2.100>
#User jmdault
#Group jmdault
#DocumentRoot /home/jmdault/public_html
#ServerName test2.com
#Setenv VLOG /home/jmdault/logs
#ErrorLog /home/jmdault/test2-error_log
#</VirtualHost>
################# Exemple d'Hôte Virtuel à base de nom générique

#NameVirtualHost 111.222.33.44
#<VirtualHost 111.222.33.44>
#ServerName www.domain.tld
#ServerPath /domain
#DocumentRoot /web/domain
#</VirtualHost>
1.1.1.19. Fichier DynamicVhosts.conf

Ces directives extraites du fichier httpd.conf concernent la déclaration des hôtes virtuels
décrits à la page "http://www.apache.org/docs/vhosts/mass.html", et utilisant le module
mod_vhost_alias.
# Hôtes virtuels dynamiques simples
#
# Obtenir le nom du serveur à partir de l'en-tête HTTP
#UseCanonicalName Off
#
# Ce format de journal peut être tronçonné au profit de chaque hôte virtuel en traitant le
# premier champ.
#LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
#CustomLog logs/access_log vcommon
#

# 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
1.1.1.20. Fichier VirtualHomePages.conf

Ceci est un ajustement du service taillé pour un serveur de FAI ou d'hébergement de sites
en masse. En utilisant une configuration légèrement plus compliquée, nous pouvons
sélectionner des sous-chaines de noms de serveur à réutiliser dans les noms de fichiers de
telle façon que les documents pour "www.user.isp.com" soient situées sous
"/home/user/".
# Un système de pages d'accueil virtuelles
#
# Obtenir le nom du serveur en exploitant l'en-tête HTTP
#UseCanonicalName Off
# this log format can be split per-virtual-host based on the first field
#LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
#CustomLog logs/access_log vcommon
# 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/
3.4 Test de la Configuration

Windows
Depuis le menu "Démarrer", l'option "Configuration Test" lance une fenêtre console.
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).
4.1 Publication Directe

1.1.1.21. Sous Windows
La procédure s'effectue en trois étapes :
• Déposer le site à l'endroit désiré sous le dossier « htdocs » (directive DocumentRoot
"C:/Program Files/Apache Group/Apache/htdocs")
• Configurer le serveur Apache à l'aide des directives exposées ci-après
• Redémarrer le serveur après modification du (ou des) fichier(s) de configuration
La deuxième étape demande à modifier le fichier de configuration si besoin est :

• Le nom de la page d'accueil du site s'intitulant par exemple "index.htm" doit être déclaré
dans le fichier de configuration (directive DirectoryIndex).
• Si le site contient des appplications de type CGI, il faut les publier à un autre endroit, sous le
dossier "cgi-bin" (directive ScriptAlias /cgi-bin/ "C:/Program Files/Apache
Group/Apache/cgi-bin/").
Après avoir modifié la configuration ("httpd.conf" depuis la version 1.3.14, "srm.conf" avant), il
faut arrêter le serveur puis le redémarrer afin qu'il prenne en compte les modifications apportées.
Pour tester en local la configuration, après avoir lancé son navigateur favori, il suffit de saisir
l'adresse : http://localhost.
1.1.1.22. Sous Unix

Les mêmes opérations sont à effectuer. Seuls les répertoires de publication changent. Le site est à
publier sous /var/www/html, et les applications CGI sous /var/www/cgi-bin.
4.2 Changement de racine du serveur

1.1.1.23. Windows
La procédure s'effectue encore en trois étapes :
• Déposer le site à l'endroit désiré
• Redémarrer le serveur après modification du (ou des) fichier(s) de configuration
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.
Voici un exemple où mon site personnel se situe sous : E:\Web\SitesPersos\normands.

Dans le fichier "httpd.conf", il suffit de remplacer "C:/Program Files/Apache

Group/Apache/htdocs" par " E:/Web/SitesPersos/normands" (directive DocumentRoot). Il est à
noter que le serveur Apache issu du monde UNIX impose l'emploi de "/" à la place du "\".
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
La syntaxe du bloc (ou conteneur) à configurer est :

<VirtualHost adresseIP>
...
</VirtualHost>
Quelle que soit la plate-forme, UNIX ou Windows, les procédures restent identiques.
1.1.1.25. Multisites à base d'adresses IP

La première méthode de déclaration de serveurs virtuels consiste à affecter une adresse IP à
chaque site publié. La procédure est plus longue et plus compliquée dans la mesure où elle fait
intervenir la configuration réseau de la station hébergeant le serveur Apache, ainsi que le serveur
DNS de rattachement du serveur Apache (là où il est déclaré) ! Elle nécessite donc deux étapes
supplémentaires par rapport aux précédentes méthodes.
• Le système doit paramétrer au préalable ces adresses IP au niveau de la configuration
réseau (voir partie "Adresses IP virtuelles de la station").
• Il doit les déclarer dans le serveur DNS de rattachement du serveur Web, par exemple :

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.
1.1.1.27. Multisites à base de noms d'hôte d'en-tête HTTP

La troisième méthode de déclaration de serveurs virtuels consiste à affecter un nom DNS
complet (FQDN) au site publié qui circulera dans les en-têtes procolaires HTTP1.1 dans le
champ "nom d'hôte". Cette méthode, comme la précédente, est d'abord utilisée par les serveurs
ne possédant qu’une adresse IP. Dans ce cas, la discrimination finale s’effectue par le nom d'hôte
(ou nom de site) et non par l'adresse IP.
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.
La procédure s'effectue en trois étapes :

• Déposer le site à l'endroit désiré sur la station hébergeant le serveur Apache
• Configurer le serveur DNS de rattachement
Le client saisit dans son navigateur l'adresse www.abc.com par exemple.
Le serveur DNS de rattachement du serveur Apache doit effectuer une résolution d'adresse :
www.abc.com  160.192.51.121.
Pour cela, le nom d'hôte circulant dans l'en-tête du protocole doit être configuré au préalable
dans le serveur DNS. Dans l'exemple ci-dessous, le site "www.abc.com" est hébergé sur le
serveur " www.svrapache.net". Le nom d'hôte est considéré comme un alias (CNAME) du nom
du serveur.
www.svrapache.net IN A 160.192.51.121
www.abc.com IN CNAME www.svrapache.net
Côté serveur Apache, il s'agit de rediriger la requête <@IP=160.192.51.121, nom=
www.abc.com> vers le bloc de configuration adéquat (bloc <VirtualHost>), d'où la configuration
suivante.
La directive NameVirtualHost est là pour définir l’adresse IP sur laquelle sont accrochés les
serveurs virtuels. Ce mode pose un problème avec les navigateurs générant des requêtes
HTTP/1.0, car le nom n’est pas émis dans la requête. La directive ServerPath (voir
documentation complémentaire), insérée dans le bloc <VirtualHost>, permet en partie, de palier
le problème.
L'adresse IP peut être remplacée par un nom de domaine complet.

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.
<VirtualHost 160.192.51.121>
ServerName www.abc.com
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).
<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
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
1.1.1.28. Adresses IP virtuelles de la station

La publication de plusieurs sites utilisant à la fois plusieurs adresses IP et plusieurs noms
génériques de site par adresse IP oblige l'administrateur de la station à configurer au préalable les
adresses IP en question.
Sous Windows NT, la fenêtre "Propriétés" du protocole TCP/IP de "Voisinage Réseau" permet
d'ajouter sans difficulté une adresse IP.

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.
4.5 Répertoires Virtuels

Il est donc possible à l'instar des serveurs Microsoft de créer des répertoires virtuels. Le serveur
Apache les appelle des alias. La directive Alias permet de définir un alias vers une adresse située
sur le même système de fichiers sous UNIX, ou n'importe quel lecteur logique sur la station
Windows, tout en se basant sur l'adresse indiquée par la directive DocumentRoot.
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.
La première phase consiste à contrôler les connexions au serveur. La partie "Modes

d'authentification" ébauche le sujet.
La deuxième phase vise à contrôler l'accès au serveur en fonction de la provenance des requêtes,
objet de la deuxième partie de cette section.
La troisième phase doit déterminer les permissions côté serveur Apache à l'aide de la troisième
partie "Protection d'une page".
Enfin, le dernier verrou se pose au niveau des droits des fichiers et répertoires parcourus lors
d'une requête, côté système de fichiers, que l'on soit sous Windows avec NTFS ou sous UNIX.
Quelle que soit la plate-forme, UNIX ou Windows, les procédures restent identiques.
5.1 Modes d'authentification

Il existe un certain nombre de modes d'authentification activés par des modules spécifiques :
• mod_auth : authentification par fichiers texte.
• mod_auth_anon : authentification d'utilisateur "anonyme", type FTP.
• mod_auth_db : authentification par fichiers de type Berkeley DB.
• mod_auth_dbm : authentification par fichiers DBM.
• mod_auth_msql (Apache 1.2.* et antérieurs) : authentification par fichiers mSQL.
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.
5.2 Provenance des requêtes

La protection d'une page se fait de façon simple, au sein du fichier httpd.conf (ou anciennement
access.conf), par ajout d'un bloc <Location> (ou <Directory> ou <Files>) assorti des trois
directives détaillées ci-desous.
1.1.1.29. La directive order

Elle contrôle l'ordre dans lequel les directives allow et deny sont évaluées. Cet ordre peut être :
• soit deny, allow : la directive deny est évaluée avant la directive allow.
• soit allow, deny : la directive allow est évaluée avant la directive deny.
Elles expriment la politique de sécurité mise en place par l'administrateur du serveur.
order deny,allow
deny from all
allow from 123.156
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.
1.1.1.30. La directive allow

Syntaxe : allow from host
Elle précise quelle entité du réseau (host) peut accéder à un répertoire donné.
Le paramètre host correspond à l'une de ces valeurs :
• all : tout le monde a accès
• un nom de domaine (ou le suffixe)
• une adresse IP complète
• une adresse IP partielle ( les 1 à 3 premiers octets de l'adresse)
• une paire network/netmask (ex : 10.1.0.0/255.255.0.0)
allow from terre.def
1.1.1.31. La directive deny

Syntaxe : deny from host host ...
La directive deny précise quelle entité du réseau (host) est interdite d'accès à un répertoire donné.
Elle emploie les même valeurs que celles décrites ci-dessus.

L'exemple ci-dessous n'autorise l'accès à "nouveau_site" qu'aux machines dont l'adresse

commence par 160.192.11.
<Location /nouveau_site>
order deny,allow
deny from all
allow from 160.192.11
</Location>
Cette première façon d'opérer est valable si l'on connait toutes les adresses IP de nos clients. Or,
la mobilité des clients entraîne que ces derniers peuvent se connecter au site depuis plusieurs
endroits différents. De la même manière, un client se connectant par l'intermédiaire d'un FAI à
l'aide d'une liaison classique (modem analogique) obtiendra à chaque connection une nouvelle
adresse IP.
Il est donc nécessaire de proposer aux clients une autre méthode pour s'identifier et s'authentifier
auprès du serveur. La méthode la plus simple dans ce cas est de tout simplement utiliser le
principe de l'identifiant et du mot de passe.
Cette authentification par mot de passe peut, comme toute restriction, être faite avec les
directives <Directory> ou <Files> :
• soit dans le fichier httpd.conf (ou access.conf)
• soit via le fichier .htaccess dont il est question après.
5.3 Protection des sites publiés

La protection commence à la racine de publication du serveur.
<Directory />
AllowOverride None
</Directory>
Elle peut se prolonger et se redéfinir d'abord au niveau de chaque site publié. Puis à l'intérieur de
chaque site, elle peut être explicitement autre pour un répertoire du site, voire une page du site.
Les directives qui permettent de définir ces droits d'accès sont Options et AllowOverride.
1.1.1.32. Directive "Options"

En dehors des valeurs présentes dans le fichier de configuration et évoquées dans la section
administration, il existe d'autres valeurs possibles :
• IncludesNOEXEC
Les SSI sont autorisés sans les commandes "#exec" ni "#include" des scripts CGI.
• SymLinksIfOwnerMatch
Le serveur ne suivra les liens symboliques que si le propriétaire du lien est le
même que celui du fichier ou répertoire visé.
• Indexes
Si une adresse URL requise pointe sur un répertoire, et si aucun fichier défini par
la directive DirectoryIndex (ex. index.html) n'existe dans ce répertoire, alors
le serveur retourne une liste formatée du contenu du répertoire (figure 21).

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>
</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>
</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.

1.1.1.33. Directive "AllowOverride "

Cette directive est liée à l'existence et à l'emploi des fichiers de protection du site ".htaccess".
Lorsque le serveur trouve un fichier .htaccess (nom fixé par la directive AccessFileName), il
doit savoir lesquelles des directives déclarées dans ce fichier peuvent outrepasser les droits fixés
par les directives précédentes.
Si la valeur est None, le serveur ne lit pas le fichier .htaccess. La valeur All permet au serveur de
prendre en compte toutes les directives du fichier. Les autres valeurs permettent aux directives
mentionnées entre parenthèses ci-dessous et incluses dans le fichier .htaccess d'outrepasser les
directives précédentes.
• AuthConfig
Autorise l'usage des directives d'autorisation d'accès (AuthDBMGroupFile,
AuthDBMUserFile, AuthGroupFile, AuthName, AuthType, AuthUserFile,
require, etc.).
• FileInfo
Autorise l'usage de directives controllant l'accès aux types de documents
(AddEncoding, AddLanguage, AddType, DefaultType, ErrorDocument,
LanguagePriority, etc.).
• Indexes
Autorise l'usage de directives controllant l'indexation des répertoires
(AddDescription, AddIcon, AddIconByEncoding, AddIconByType, DefaultIcon,
DirectoryIndex, FancyIndexing, HeaderName, IndexIgnore, IndexOptions,
ReadmeName, etc.).
• Limit
Autorise l'usage de directives controllant les accès de certains hôtes (allow, deny
et order).
• Options
Autorise l'usage de directives controllant certaines fonctionnalités spécifiques des
répertoires (Options et XBitHack).
1.1.1.34. Niveaux de protection

Tout répertoire de publication d'un serveur virtuel ou non peut faire l'objet de protections à l'aide
du bloc <Directory>. L’argument dir peut être remplacé aussi bien par un chemin de répertoire
donné que par une expression régulière permettant de spécifier un ensemble de répertoires.
<Directory dir>
AllowOverride None
</Directory>
La directive DirectoryMatch fonctionne de façon similaire avec une expression régulière
comme argument. Par exemple :
<DirectoryMatch "^/www/[09]{3}.*">
L'expression "[09]{3}.*" correspond aux répertoires de /www/ dont le nom commence par
trois chiffres compris entre 0 et 9.

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.
5.4 Protection d'une page par un mot de passe

1.1.1.35. Protection d'une page par directives
La protection d'une page par un mot de passe se fait de façon simple par ajout du bloc <Files>
assorti des quatre directives détaillées ci-dessous, ceci dans le fichier httpd.conf (ou access.conf).
<Files /répertoire/page.html>
AuthName "Zone secure"
AuthType Basic
AuthUserFile /etc/apache/users
require valid-user
</Files>
Les différents paramètres sont :
• /répertoire/page.html est le nom de la page à protéger,
• AuthName est le libellé affiché dans la fenêtre de demande d'authentification, libellé
pouvant refléter l'entrée dans une zone protégée,
• AuthType représente le type d'authentification, Basic ou Digest, ou …
• AuthUserFile désigne le chemin du fichier contenant les noms des utilisateurs autorisés
à accéder à la page ainsi que les mots de passe associés,
• require restreint la liste précédente à celle des utilisateurs mentionnés en paramètres.
Les quatre directives sont nécessaires.

AuthType est le type d'authentification demandé. basic est le paramètre communément utilisé
car il est compatible avec tous les navigateurs. Il définit, entre autre, le fait que l'identifiant de
l'utilisateur et son mot de passe circulent en clair sur le réseau, ce qui peut poser des problèmes
de sécurité.
Un autre type d'authentification est Digest ; il définit un échange de codage MD5 entre le client
et le serveur. Malheureusement, le support de ce type d'authentification est encore trop rare
parmi les clients HTTP pour l'utiliser à grande échelle. Si les données transitant sur le réseau
sont trop confidentielles, la meilleure solution est encore d'utiliser une authentification basique
couplée à un serveur utilisant SSL.
L'argument valid- user de la fonction require spécifie ici que n'importe quel utilisateur qui
satisfaît à l'authentification par mot de passe est accepté. Si l'on souhaite ajuster avec davantage
de précision quel utilisateur peut accéder à ce répertoire, il suffira de spécifier son nom précédé
de l'indication user ici (dans le cas de plusieurs utilisateurs, il faut séparer les noms par un
caractère espace).
Cette fonction peut attendre aussi comme valeur un groupe d'utilisateurs suivi de son nom :

• require group cleaners.
Il en est de même pour la protection d'un répertoire avec le bloc <Directory>.
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
Voici un exemple de création de fichier par l'ajout d'un premier utilisateur :

# htpasswd -c users moimeme
New password:
Re-type new password:
Adding password for user moimeme
Nous pouvons ensuite lister le contenu du fichier users nouvellement créé :

# cat users
moimeme:QUbeW02EGIwGU
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".
Voici pour conclure et synthétiser le sujet un exemple relativement complet appliqué au

répertoire de connexion des utilisateurs.
#<Directory "C:/Program Files/Apache Group/Apache/users">
# AllowOverride FileInfo AuthConfig Limit
# Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
# <Limit GET POST OPTIONS PROPFIND>
# Order allow,deny
# Allow from all
# </Limit>
# <LimitExcept GET POST OPTIONS PROPFIND>
# Order deny,allow
# Deny from all
# </LimitExcept>
#</Directory>
Le bloc ou conteneur <Limit> spécifie des contrôles d'accès selon la méthode d'accès au serveur
utilisée : GET, POST, etc…(voir fonctionnement du protocole HTTP). Comme le suggère
l'exemple, les méthodes paramétrées sont indiquées à l'intérieur de la balise.
L'utilité du bloc suivant <LimitExcept> permet de définir des contrôles d'accès pour les
méthodes non listées dans le bloc précédent.
1.1.1.36. Protection d'une page par fichier .htaccess

Il est possible par ailleurs de décentraliser cette sécurité dans un fichier placé dans le répertoire à
protéger, ou dans le même répertoire que celui de la page à protéger.
Ce fichier contient simplement et au moins les quatre même directives obligatoires mentionnées
précédemment.
Les lignes suivantes, configurées au sein du fichier httpd.conf, empêchent les fichiers ".htaccess"
d'être visibles des clients Web.
<Files ~ "^\.ht">
Order allow,deny
Deny from all
</Files>
1.1.1.37. Ordre d’évaluation

Une attention particulière doit être apportée à l'agencement des différentes directives pour éviter
que certaines soient sans effets. L’ordre d’évaluation de ces directives est donné ci-dessous.
Dans le cas des directives Directory, l’évaluation est effectuée du chemin le plus court au
chemin le plus long. En cas de conflit, l’évaluation est effectuée dans l’ordre des déclarations :

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.
Min. Déf. Composants et sous-composants

X Extensions serveur de FrontPage
Prend en charge l'utilisation de Microsoft® FrontPage® pour gérer votre site
Web et créer son contenu.
X Fichiers d'extension serveur de FrontPage
Kit d'administration de Connection Manager
Documentation du Kit d'administration de Connection Manager
Documentation de mise en route
X Composants Microsoft Data Access (CMDA)
Facilite l'utilisation des bases de données avec la prise en charge des objets
ADO (ActiveX Data Objects) et le pilote Microsoft Access.
X Sources de données
X Jet et Access
Oracle
X SQL Server

X CMDA : ADO, ODBC et OLE DB

Documentation ADO
X Fichiers de base MDAC : ADO, ODBC et OLE DB
X Service de gestion des données à distance (RDS, Remote Data Service)
X Fichiers principaux de RDS
Documentation de RDS
Exemples RDS
Fichiers RDS version 1.1
Microsoft Message Queue
Permet aux applications de passer outre la notification de transaction et de
poursuivre le traitement sans attendre la confirmation de l'achèvement de la
transaction.
Documentation HTML
Client Microsoft Message Queue
Kit de développement logiciel (SDK)
X Serveur Web personnel
Serveur Web qui utilise le protocole TCP/IP pour héberger un site Web sur
l'intranet d'une entreprise.
X Fichiers programme communs
X Documentation
Active Server Pages
X Fichiers de documentation communs
X Documentation de l'administrateur de PWS
X Gestionnaire de serveur Web personnel
X Serveur World Wide Web
X Transaction Server
Prend en charge la création d'applications Microsoft Transaction Server. 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.
X Composants principaux de Transaction Server
X Documentation principale de Transaction Server
Développement de Transaction Server
Développement de Transaction Server
Documentation pour le Développement de Transaction Server
Macro complémentaire Visual Basic pour Transaction Server
Support de déploiement RAD à distance Visual InterDev
Permet le déploiement à distance d'applications sur votre serveur Web à l'aide
de Microsoft® Visual InterDev™.
Support de déploiement RAD à distance Visual InterDev

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

Annexe Apache : Administration graphique

sous UNIX
Linuxconf
Il s'agit du principal outil de configuration des services sous Linux en place depuis au moins la
version 6.0 de la distribution Mandrake.
Après avoir lancé l'outil en question, il faut choisir le bouton "réseau" ou "network". Une
nouvelle fenêtre s'ouvre présentant trois onglets : taches clients, taches serveur, autres.
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).

INTServeurs

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

INTServeurs

Uploaded by

Copyright:

Available Formats

Systèmes Répartis INTERNET Serveurs Web

Chapitre 1 : Présentation des Serveurs..........................................................................................4

Edition février 2002 23242348.doc Page 1 sur 228

1.4 Types d'installation..........................................................................................................96

Edition février 2002 23242348.doc Page 2 sur 228

Edition février 2002 23242348.doc Page 3 sur 228

Chapitre 1 : Présentation des Serveurs

La première section de ce document rappelle dans un premier temps les principes de

La deuxième section de ce document présente les fonctionnalités d'un serveur, fonctionnalités

 Emploi et Utilité d'un Serveur

Edition février 2002 23242348.doc Page 4 sur 228

Edition février 2002 23242348.doc Page 5 sur 228

1 : La validation d’une adresse URL

3 : Le serveur répond en renvoyant la page

Edition février 2002 23242348.doc Page 6 sur 228

chemins, assurant la portabilité du site, ne nécessitent que l'interprétation du navigateur et non

Figure 2 : Site Dynamique

Comment reconnaître dans le code source des pages ces applications ?

Edition février 2002 23242348.doc Page 7 sur 228

1.2 Pourquoi un Serveur Web ?

 Fonctionnalités d'un Serveur

2.1 Quelques Statistiques

Edition février 2002 23242348.doc Page 8 sur 228

IPlanet Web Server

Zeus Web Application Server 3.3.5

Edition février 2002 23242348.doc Page 9 sur 228

2.2 Caractéristiques Communes

Fichiers historiques (ou log)

Edition février 2002 23242348.doc Page 10 sur 228

Protocoles et • Il supporte le protocole HTTP/1.1.

Voyons maintenant quelques traits spécifiques de chacun.

Edition février 2002 23242348.doc Page 11 sur 228

Autres Particularités Apache

3.2 Site d'Entreprise

3.3 Exemple de banc de test

Rapidité • Apache 1.3.12

Edition février 2002 23242348.doc Page 12 sur 228

• IIS 5.0 sous Windows 2000 Advanced Server.

Administration • Web Server Enterprise

• IIS 5.0 sous Windows 2000 Advanced Server.

Sécurité • Web Server Enterprise

Evolutivité • Apache 1.3.12

• Web Server Enterprise

L'étude du serveur Apache fait l'objet du dernier chapitre du module.

Edition février 2002 23242348.doc Page 13 sur 228

4.1 Offres Commerciales

Edition février 2002 23242348.doc Page 14 sur 228

Restrictions de PWS par rapport à IIS

Avantages de IIS 4.0

Edition février 2002 23242348.doc Page 15 sur 228

Les performances techniques de chargement de pages ou d'exécution d'application sont un

Edition février 2002 23242348.doc Page 16 sur 228

Chapitre 2 : Serveur Microsoft PWS

Le document est découpé en trois parties : installation, administration et publication.

Edition février 2002 23242348.doc Page 17 sur 228

1.2 PWS sous Windows NT 4.0 Station

 le serveur ne s’installe pas si les composants suivants ne le sont pas :

• Internet Explorer 4.0 situé sur le même cédérom sous « Ie401\X86 » :

Edition février 2002 23242348.doc Page 18 sur 228

Edition février 2002 23242348.doc Page 19 sur 228

Composants de l'installation personnalisée

Edition février 2002 23242348.doc Page 20 sur 228

Edition février 2002 23242348.doc Page 21 sur 228

• Transaction  C:\Program Files\Mts