Mise en place d’Apache sous Unix
Nous pouvons faire pointer httpd vers notre site en utilisant l’option -d (vous remarquerez que l’on donne le chemin complet vers le répertoire site.toddle, il sera peut-être différent sur votre machine) :
% httpd -d /usr/www/APACHE3/site.toddle
Comme vous devrez souvent taper cette commande, il est conseillé de la copier dans un script appelé go, que vous pouvez placer dans /usr/local/bin ou dans chaque arborescence de site. Nous avons choisi la deuxième solution car il sera plus pratique de modifier le script pour un site particulier :
% cd /usr/www/APACHE3/site.toddle
% cat > go
test -d logs || mkdir logs
httpd -f `pwd`/conf/httpd$1.conf -d `pwd`
^d
^d est un raccourci pour Ctrl-D, qui met fin à la saisie et vous ramène à l’invite de commande. Le script go fonctionnera pour n’importe quel site : il crée un répertoire logs si celui-ci n’existe pas et indique explicitement les chemins du répertoire racine du serveur ( -d ) et du fichier de configuration ( -f ). La commande `pwd ` produit le nom du répertoire courant. Les apostrophes inverses sont essentielles : elles permettent d’insérer la valeur renvoyée par pwd dans les chemins utilisés par le script -- autrement dit, nous lancerons Apache avec la configuration qui se trouve dans le répertoire courant. Pour gérer le cas des sites ayant plus d’un fichier de configuration, nous utilisons ...httpd$1... à la place de ...httpd... : le symbole $1 sera remplacé par le premier paramètre (s’il existe) passé au script. Ainsi, ./go 2 utilisera le fichier httpd2.conf et ./go utilisera httpd.conf.
N’oubliez pas de vous placer dans le répertoire du site. Si vous lancez ce script d’un autre endroit, le résultat de pwd n’aura aucun sens et Apache se plaindra avec le message 'could not open document config file ...'.
Rendez go exécutable en tapant les commandes suivantes :
% chmod +x go
% go
Si vous obtenez le message d’erreur suivant :
go: command not found
Tapez :
% ./go
Cette commande lancera Apache en arrière-plan. Vérifiez qu’il tourne en utilisant une commande comme celle-ci (les paramètres de ps varient selon les Unix) :
% ps -aux
Cette commande Unix énumère tous les processus en cours d’exécution : vous devriez trouver plusieurs httpd parmi eux.
Tôt ou tard, vous aurez fini vos tests et vous voudrez mettre fin à Apache. Pour ce faire, vous devez connaître l’identité du processus (PID) du programme httpd en faisant ps -aux :
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
root 701 0.0 0.8 396 240 v0 R+ 2:49PM 0:00.00 ps -aux
root 1 0.0 0.9 420 260 ?? Is 8:13AM 0:00.02 /sbin/init --
root 2 0.0 0.0 0 0 ?? DL 8:13AM 0:00.04 (pagedaemon)
root 3 0.0 0.0 0 0 ?? DL 8:13AM 0:00.00 (vmdaemon)
root 4 0.0 0.0 0 0 ?? DL 8:13AM 0:02.24 (syncer)
root 35 0.0 0.3 204 84 ?? Is 8:13AM 0:00.00 adjkerntz -i
root 98 0.0 1.8 820 524 ?? Is 7:13AM 0:00.43 syslogd
daemon 107 0.0 1.3 820 384 ?? Is 7:13AM 0:00.00 /usr/sbin/portma
root 139 0.0 2.1 888 604 ?? Is 7:13AM 0:00.07 inetd
root 142 0.0 2.0 980 592 ?? Ss 7:13AM 0:00.27 cron
root 146 0.0 3.2 1304 936 ?? Is 7:13AM 0:00.25 sendmail: accept
root 209 0.0 1.0 500 296 con- I 7:13AM 0:00.02 /bin/sh /usr/loc
root 238 0.0 5.8 10996 1676 con- I 7:13AM 0:00.09 /usr/local/libex
root 239 0.0 1.1 460 316 v0 Is 7:13AM 0:00.09 -csh (csh)
root 240 0.0 1.2 460 336 v1 Is 7:13AM 0:00.07 -csh (csh)
root 241 0.0 1.2 460 336 v2 Is 7:13AM 0:00.07 -csh (csh)
root 251 0.0 1.7 1052 484 v0 S 7:14AM 0:00.32 bash
root 576 0.0 1.8 1048 508 v1 I 2:18PM 0:00.07 bash
root 618 0.0 1.7 1040 500 v2 I 2:22PM 0:00.04 bash
root 627 0.0 2.2 992 632 v2 I+ 2:22PM 0:00.02 mince demo_test
root 630 0.0 2.2 992 636 v1 I+ 2:23PM 0:00.06 mince home
root 694 0.0 6.7 2548 1968 ?? Ss 2:47PM 0:00.03 httpd -d /u
webuser 695 0.0 7.0 2548 2044 ?? I 2:47PM 0:00.00 httpd -d /u
webuser 696 0.0 7.0 2548 2044 ?? I 2:47PM 0:00.00 httpd -d /u
webuser 697 0.0 7.0 2548 2044 ?? I 2:47PM 0:00.00 httpd -d /u
webuser 698 0.0 7.0 2548 2044 ?? I 2:47PM 0:00.00 httpd -d /u
webuser 699 0.0 7.0 2548 2044 ?? I 2:47PM 0:00.00 httpd -d /u
Pour arrêter Apache, vous devez trouver le PID de l’instance principale de httpd et faire kill <PID> -- ses processus fils s’arrêteront avec lui. Dans notre exemple, le processus à arrêter est le 694 -- l’instance qui appartient à root :
% kill 694
Si la sortie de ps -aux ne tient pas sur un seul écran, paginez-la avec ps -aux | more -- faites Entrée pour défiler ligne par ligne, ou Espace pour passer à l’écran suivant. Il est important que le processus Apache principal soit correctement arrêté. En effet, vous pouvez stopper un processus fils par erreur, puis lancer une nouvelle instance du serveur avec ses propres fils -- ainsi qu’un fichier de configuration ou des scripts Perl différents -- et vous retrouver ainsi dans un joli pétrin.
Pour n’obtenir que les lignes de ps qui vous intéressent, vous pouvez invoquer :
% ps awlx | grep httpd
Si vous ne voulez pas vous embêter à chercher leurs PID, vous pouvez arrêter tous les processus httpd avec la commande :
% killall httpd
Une autre solution, qui est préférable car elle est moins sujette aux fautes de frappe, consiste à utiliser le fichier .logs/httpd.pid dans lequel Apache écrit lui-même son PID (son emplacement peut avoir été modifié par la directive PidFile ). Vous pouvez, par exemple, écrire le petit script suivant :
kill `cat /usr/www/APACHE3/site.toddle/logs/httpd.pid`
Le script stop est une version plus générale du script précédent :
pwd | read path
kill `cat $path/logs/httpd.pid`
Si vous ne comptez pas vous battre avec plusieurs configurations différentes, vous pouvez également utiliser apachectl pour lancer et arrêter Apache dans le répertoire par défaut. apachectl reconnaît les paramètres suivants :
usage: ./apachectl (start|stop|restart|fullstatus|status|graceful
|configtest|help)
start
Lance httpd.
stop
Arrête httpd.
restart
Relance httpd en lui envoyant le signal SIGHUP s’il s’exécute déjà, ou en le démarrant sinon.
fullstatus
Affiche un descriptif complet de l’état du serveur ; nécessite la présence du programme lynx et l’activation du module mod_status.
status
Affiche un résumé de l’état du serveur ; nécessite la présence du programme lynx et l’activation du module mod_status.
graceful
Relance proprement le serveur en lui envoyant un signal SIGUSR1 ou en le démarrant s’il n’était pas déjà en cours d’exécution.
configtest
Vérifie la syntaxe du fichier de configuration.
help
Affiche l’écran d’aide.
Quand nous avons tapé ./go, rien n’a semblé se passer mais, en examinant le sous-répertoire logs, nous y avons trouvé un fichier nommé error_log contenant la ligne suivante :
[<date>]:'mod_unique_id: unable to get hostbyname ("myname.my.domain")
Le problème, ici, était dû à notre manière de lancer Apache. Il ne se produit que si vous lancez le serveur sur une machine sans DNS ou sur un système qui n’arrive pas à déterminer le nom de l’hôte local. La solution consiste à modifier le fichier /etc/hosts et à ajouter la ligne :
10.0.0.2 monnom.mon.domaine monnom
où 10.0.0.2 est l’adresse IP que nous utilisons pour nos tests.
Cependant, nos problèmes n’étaient pas terminés pour autant. En relançant httpd, nous avons obtenu le message d’erreur suivant :
[<date>]--couldn’t determine user name from uid
Cela signifie bien plus qu’il ne semble de prime abord. Nous nous sommes connecté sous le compte root et Apache a été lancé sous ce compte pour pouvoir se lier au port 80 : à cause du danger qu’implique l’acquisition des droits du super-utilisateur, Apache a tenté de modifier son identifiant utilisateur en -1 qui, sur la plupart des Unix, correspond à l’utilisateur nobody, un utilisateur a priori sans danger. Cependant, il semble que FreeBSD ne comprenne pas cette notion, d’où le message d’erreur. Dans tous les cas, il n’est vraiment pas conseillé d’autoriser Apache à s’exécuter sous le compte nobody (ou sous tout autre compte partagé) car vous courez le risque qu’un attaquant exploite le fait que plusieurs services s’exécutent via le même utilisateur (si vous faites tourner plusieurs services comme ftp, mail, etc. sur la même machine, évidemment).
webuser et webgroup
Le remède au problème évoqué plus haut consiste à créer un utilisateur appelé webuser, appartenant au groupe webgroup. Ces noms ont peu d’importance, ce qui compte est que cet utilisateur soit dans un groupe qui lui est propre et qu’il ne soit pas utilisé pour autre chose. Sur la plupart des systèmes Unix, on crée d’abord le groupe avec la commande adduser -group webgroup, puis l’utilisateur avec adduser. Sur certains systèmes, vous devrez donner un mot de passe à cet utilisateur : utilisez une chaîne de caractères incompréhensible, comme cQuycn75Vg. L’idéal serait de faire en sorte que personne ne puisse se connecter sous ce compte ; la méthode dépend du système d’exploitation : vous devrez remplacer le mot de passe chiffré dans /etc/passwd par un astérisque, ou supprimer le répertoire d’accueil, par exemple. Maintenant que le système connaît cet utilisateur, vous devez l’indiquer à Apache ; ouvrez le fichier httpd.conf et ajoutez-lui les lignes suivantes :
User webuser
Group webgroup
User
La directive User fixe le compte utilisateur sous lequel s’exécutera Apache lorsqu’il répondra aux requêtes.
User compte-unix
Default: User #-1
Configuration du serveur, hôte virtuel
Pour utiliser cette directive, le serveur doit avoir été lancé sous le compte root. compte-unix peut être :
nom-utilisateur
Désigne un utilisateur par le nom de son compte.
#numéro-utilisateur
Désigne un utilisateur par le numéro de son compte (UID).
L’utilisateur webuser ne doit pas être autorisé à accéder aux fichiers qui ne sont pas destinés à être vus de l’extérieur ; de même, il ne doit pas pouvoir exécuter du code non destiné aux requêtes de httpd. Il doit, cependant, avoir accès à certaines choses -- les fichiers qu’il servira aux clients, par exemple, ou le cache de mod_proxy si ce module est activé (voir la directive CacheRoot au chapitre 9).
Si vous lancez le serveur sous un compte différent de root, il ne pourra pas passer sous un compte moins privilégié et continuera donc son exécution sous son compte initial. Si vous le lancez sous le compte root, il est normal que le processus père continue de s’exécuter sous ce compte.
Ne configurez pas User (ou Group ) avec la valeur root, sauf si vous savez exactement ce que vous faites et que vous en connaissez le danger.
Group
La directive Group fixe le groupe sous lequel le serveur répondra aux requêtes des clients.
Group groupe-unix
Default: Group #-1
Configuration du serveur, hôte virtuel
Pour utiliser cette directive, le serveur doit avoir été lancé sous le compte root. groupe-unix est l’une des valeurs suivantes :
nom-groupe
Désigne le groupe par son nom.
#numéro-groupe
Désigne le groupe par son numéro (GID).
Il est conseillé de créer un groupe spécial pour le serveur. Certains administrateurs utilisent le groupe nobody, mais ce n’est ni toujours possible, ni souhaitable, comme nous l’avons vu précédemment.
Si vous lancez le serveur sous un compte différent de root, il ne pourra pas changer de groupe et continuera donc son exécution dans le groupe de cet utilisateur.
Désormais, lorsque vous lancerez httpd et que vous examinerez son PID, vous constaterez qu’une seule instance appartient à root et que toutes les autres appartiennent à webuser. Arrêtez l’instance de root et toutes les autres s’évanouiront également.
Problèmes avec l’installation automatique
Avec l’installation automatique qui utilise un schéma GNU, nous avons remarqué que certaines valeurs par défaut ne sont pas correctement initialisées. Lorsque vous lancez ./go, si ce message d’erreur plutôt curieux apparaît à l’écran :
fopen: No such file or directory
httpd: could not open error log file <chemin vers site.toddle>
site.toddle/var/httpd/log/error_log
vous devez ajouter la ligne suivante :
ErrorLog logs/error_log
à .conf/httpd.conf. Si, après cela, Apache refuse de démarrer et inscrit ce message dans .logs/error_log :
.... No such file or directory.: could not open mime types log file
<chemin vers site.toddle>/site.toddle/etc/httpd/mime.types
vous devez ajouter la ligne suivante :
TypesConfig conf/mime.types
à .conf/httpd.conf. Si, toujours après cela, Apache refuse de démarrer et inscrit ce message dans .logs/error_log :
fopen: no such file or directory httpd: could not log pid to file
<chemin vers site.toddle>/site.toddle/var/httpd/run/httpd.pid
ajoutez cette ligne :
PIDFile logs/httpd.pid
à .conf/httpd.conf.
Exécution d’Apache sous Unix
Si vous lancez Apache maintenant, vous risquez de voir apparaître le message d’erreur suivant :
httpd: cannot determine local hostname
Use ServerName to set it manually.
Ce message vous indique que vous devriez ajouter la ligne suivante dans le fichier httpd.conf :
ServerName < nom-de-votre-machine>
Enfin, avant que quelque chose puisse se passer, vous devez mettre en place les documents que vous comptez proposer aux clients. Le répertoire par défaut de ces documents est .httpd/htdocs -- qui n’est pas celui que vous souhaitez puisque vous êtes dans /usr/www/APACHE3/site.toddle -- vous devez donc modifier cette valeur. Créez le répertoire .site.toddle/htdocs et placez-y un fichier 1.txt contenant l’intemporel : « Bonjour tout le monde ! ». Puis, ajoutez cette ligne à httpd.conf :
DocumentRoot /usr/www/APACHE3/site.toddle/htdocs
Le fichier de configuration .site.toddle/conf/httpd.conf complet ressemble maintenant à ceci :
User webuser
Group webgroup
ServerName my586
DocumentRoot /usr/www/APACHE3/APACHE3/site.toddle/htdocs/
#Correction des valeurs par défaut de l’installation automatique
#Supprimez-les si nécessaire.
#ServerRoot /usr/www/APACHE3/APACHE3/site.toddle
#ErrorLog logs/error_log
#PIDFile logs/httpd.pid
#TypesConfig conf/mime.types
Lorsque vous lancez httpd, vous devriez disposer d’un serveur web en état de marche. Pour le vérifier, lancez un navigateur et faites-le pointer vers http://nom-de-votre-machine/.
Comme nous l’avons vu, http signifie que l’on utilise le protocole HTTP pour récupérer les documents, et le / à la fin de l’URL signifie que l’on souhaite aller dans le répertoire DocumentRoot défini dans le fichier httpd.conf.
Si Lynx -- un navigateur en mode texte fourni avec FreeBSD et d’autres Unix -- est installé sur votre système, tapez :
% lynx http:// nom-de-votre-machine /
Vous devez obtenir :
INDEX OF /
* Parent Directory
* 1.txt
Si vous vous déplacez sur 1.txt avec la touche de curseur vers le bas, puis que vous appuyez sur Entrée ou sur la touche droite de direction du curseur, vous verrez apparaître :
Bonjour tout le monde !
Si aucun navigateur n’est installé sur votre serveur, vous pouvez utiliser telnet :
% telnet nom-de-votre-machine 80
Vous devriez voir apparaître des lignes comme celles-ci :
Trying 192.168.123.2
Connected to my586.mon.domaine
Escape character is '^]'
Tapez alors :
GET / HTTP/1.0 <Entrée><Entrée>
Le résultat ressemblera à ceci :
HTTP/1.0 200 OK
Sat, Tue, 18 Mar 2003 14:14:40 GMT
Server: Apache/1.3
Connection: close
Content-Type: text/html
<HEAD><TITLE>Index of /</TITLE></HEAD><BODY>
<H1>Index of </H1>
<UL><LI> <A HREF="/"> Parent Directory</A>
<LI> <A HREF="1.txt"> 1.txt</A>
</UL></BODY>
Connection closed by foreign host.
C’est une occasion rare de voir un message HTTP complet. Les premières lignes sont des en-têtes qui vous sont normalement cachés par votre navigateur. Tout ce qui se trouve entre les < et les > est du HTML produit par Apache : dans un navigateur, ce code produit le message formaté tel qu’on l’a vu plus haut avec Lynx et comme nous le verrons au chapitre suivant avec Netscape ou Microsoft Internet Explorer.
Les différentes instances d’Apache
Pour voir tous les processus qui s’exécutent sur votre machine, lancez :
% ps -aux
Parmi les lignes produites, vous verrez une seule exécution de httpd sous le compte root et plusieurs sous le compte webuser : ce sont des instances identiques, qui attendent les requêtes des clients.
L’instance root est attachée au port 80 -- ses fils le seront donc également -- mais elle n’est pas en écoute : le compte root a trop de pouvoir, le laisser gérer cette part poserait des problèmes de sécurité. Il est cependant nécessaire que cette instance « maître » continue de s’exécuter sous le compte root car, selon la doctrine sécuritaire Unix -- qui n’est pas vraiment parfaite, seul ce compte a le droit d’ouvrir des ports inférieurs à 1024. Le rôle de cette instance consiste à surveiller le tableau d’état (occupée ou en attente) des autres. S’il y en a trop peu en attente (la valeur minimale par défaut, en l’occurrence 5, est définie par la directive MinSpareServers de httpd.conf ), l’instance maître en lance de nouvelles ; s’il y en a trop qui attendent (la valeur maximale par défaut, en l’occurrence 10, est définie par la directive MaxSpareServers ), elle en supprime quelques-unes. Si vous notez le PID de cette instance maître, et que vous l’arrêtez avec :
% kill PID
vous remarquerez que les autres instances disparaissent également.
Il est cependant préférable d’utiliser le script stop que nous avons décrit dans la section Mise en place d’Apache sous Unix de ce chapitre car il est plus systématique et donc plus simple d’emploi.
Permissions Unix
Pour qu’Apache fonctionne correctement, il est important que les permissions d’accès aux fichiers soient bien configurées. Sur les systèmes Unix, on distingue trois types de permissions : lecture ( r pour read ), écriture ( w pour write ) et exécution ( x pour execute ). Ces permissions s’appliquent à chaque fichier à trois niveaux : le propriétaire ( u pour user ), le groupe ( g pour group ) et les autres ( o pour other ) . Si vous avez installé les sites d’exemple, allez dans .site.cgi/htdocs et tapez :
% ls -l
Cela affichera :
-rw-rw-r-- 5 root bin 1575 Aug 15 07:45 form_summer.html
Le - en début de ligne indique qu’il s’agit d’un fichier normal ; il est suivi de trois groupes de permissions, formés chacun de trois caractères. Ici, ce fichier a donc les permissions suivantes :
Propriétaire ( root )
Droit de lecture ( r ), d’écriture ( w ), mais pas d’exécution.
Groupe ( bin )
Droit de lecture, d’écriture, mais pas d’exécution.
Les autres
Droit de lecture uniquement.
Lorsque les permissions concernent un répertoire, le droit d’exécution x donne la permission d’ accéder à ce répertoire, c’est-à-dire d’en voir le contenu et de descendre dans son arborescence.
Les permissions qui nous intéressent sont celles des autres car l’instance d’Apache qui tente d’accéder à ce fichier appartient à l’utilisateur webuser et au groupe webgroup. Ceux-ci ont été configurés pour n’avoir aucun lien avec root et bin, de façon à ce qu’ils n’aient que les droits des autres sur les fichiers -- le droit de lecture uniquement. Par conséquent, un sale type qui parviendrait à s’introduire dans le système via Apache ne pourrait ni modifier, ni supprimer notre précieux form_summer.html : il ne pourrait que le lire.
Nous pouvons maintenant mettre en place une règle cohérente concernant les permissions. Nous avons fait en sorte que tout le contenu de notre site web, sauf les données vulnérables aux attaques, appartienne à root et au groupe wheel. Nous avons fait ce choix en partie parce qu’il s’agit d’une approche valable, mais aussi parce que c’est la seule qui soit portable. Nos fichiers d’exemples ont tous le propriétaire d’UID 0 et appartiennent tous au groupe de GID 0 : sur n’importe quelle machine, cela se traduit par une appartenance au super-utilisateur.
Cela n’a, bien sûr, de sens que si le webmestre a le droit de se connecter sous le compte root, ce qui est notre cas. Si vous n’avez pas ce droit, vous aurez peut-être à vous adapter et à consulter l’administrateur de votre site.
En général, le contenu d’un site web devrait appartenir à un utilisateur qui n’est pas webuser et à un groupe qui n’est pas webgroup -- en supposant que vous utilisiez cet utilisateur et ce groupe pour votre configuration Apache.
En ce qui nous concerne, nous voulons permettre à webuser d’accéder à quatre types de fichiers : les répertoires, les données, les programmes et les scripts shells. webuser doit pouvoir accéder à tous les répertoires en partant de la racine jusqu’à ceux qui contiennent les fichiers. Si Apache doit accéder à un répertoire, celui-ci et tous ceux qui y mènent doivent avoir la permission x pour les autres. Pour ce faire, utilisez la commande suivante :
% chmod o+x chaque-répertoire-du-chemin
Afin de produire la liste d’un répertoire (pour un index, par exemple), ce répertoire doit pouvoir être lu par les autres :
% chmod o+r répertoire-final
Par contre, les autres ne devraient pas être autorisés à y écrire :
% chmod o-w répertoire-final
Pour servir un fichier aux clients -- et cela comprend des fichiers comme .htaccess (voir le chapitre 3) -- il doit pouvoir être lu par les autres :
% chmod o+r fichier
sans pour autant qu’ils aient le droit de le modifier :
% chmod o-w fichier
Pour lancer un programme, les autres doivent avoir la permission de l’exécuter :
% chmod o+x programme
Pour exécuter un script shell, les autres doivent avoir la permission de le lire et de l’exécuter :
% chmod o+rx script :
Et, pour plus plus de sécurité :
% chmod a=rx script
Où a (pour all ) regroupe les 3 niveaux d’utilisateur.
Si seul le propriétaire doit pouvoir modifier le script :
% chmod u=rwx,og=rx script
Un réseau local
Encouragés par le succès de site.toddle, nous pouvons maintenant mettre en place une configuration plus réaliste, sans pour autant nous aventurer dans les eaux troubles du Web. Nous avons besoin des deux choses : un serveur Apache tournant sur un Unix et un navigateur web. Voici les deux principaux moyens possibles :
- Faire tourner Apache et un navigateur (Netscape ou Lynx, par exemple) sur la même machine : le « réseau » est alors fourni par Unix.
- Faire tourner Apache sur une machine Unix et utiliser un navigateur sur une machine Windows 95/NT ou Mac OS, ou vice-versa, et les relier par Ethernet (c’est ce que nous avons fait pour ce livre, en utilisant FreeBSD).
Nous ne pouvons prétendre donner des explications détaillées pour toutes les variantes possibles de ces situations. Nous supposons que la plupart de nos lecteurs sont des web-mestres confirmés, habitués à ces problèmes, et qu’ils sauteront l’encadré suivant. Cependant, les débutants peuvent tirer profit de notre expérience.
Notre micro-Web expérimental
Nous avons d’abord dû installer une carte réseau sur la machine FreeBSD. Au démarrage, le système teste tous ses composants et en affiche la liste, faisant notamment apparaître la carte et le nom de son pilote. Nous avons utilisé une carte 3Com, les lignes suivantes sont donc apparues :
...
1 3C5x9 board(s) on ISA found at 0x300
ep0 at 0x300-0x30f irq 10 on isa
ep0: aui/bnc/utp[*BNC*] address 00:a0:24:4b:48:23 irq 10
...
Elles indiquent assez clairement que le pilote se nomme ep0 et qu’il a été correctement installé. Si cet affichage défile trop vite pour vous, FreeBSD vous permet d’utiliser la touche « Arrêt Défil. » et de remonter avec « Page Up » dans les lignes produites pour y retrouver celles qui vous intéressent. Un second appui sur « Arrêt Défil » fait reprendre le cours normal des opérations. Vous pouvez également utiliser la commande dmesg (ou, sur certains systèmes, consulter le fichier /var/run/dmesg ) pour prendre connaissance des messages de démarrage de votre système.
La carte étant correctement reconnue, nous avons configuré le pilote ep0 en effectuant les commandes suivantes :
ifconfig ep0 192.168.123.2
ifconfig ep0 192.168.123.3 alias netmask 0xFFFFFFFF
ifconfig ep0 192.168.124.1 alias
La commande alias demande à ifconfig de lier une adresse IP supplémentaire à la même interface. Avec FreeBSD, il faut également utiliser netmask pour empêcher l’affichage d’un message d’erreur (pour plus de détails sur les masques de réseau, consultez TCP/IP - Administration de réseau, de Craig Hunt, publié aux éditions O’Reilly). Les adresses utilisées ici correspondent à notre propre configuration ; vous devrez consulter votre administrateur réseau pour connaître celles qui conviennent à la vôtre. Pour que notre Apache fonctionne, ces commandes doivent être exécutées à chaque redémarrage de FreeBSD ; aussi, la méthode habituelle consiste à les ajouter au fichier /etc/rc.local (ou à son équivalent -- quel que soit son nom, c’est un fichier lancé au démarrage du système).
Si vous respectez la pratique courante sous FreeBSD, vous devrez également mettre ces adresses IP et les noms d’hôtes qui leurs sont associés (ces noms sont des noms de domaine pleinement qualifiés ou FQDN, Fully Qualified Domain Names.) dans le fichier /etc/hosts :
192.168.123.2 www.butterthlies.com
192.168.123.2 sales.butterthlies.com
192.168.123.3 sales-not-vh.butterthlies.com
192.168.124.1 www.faraway.com
Vous remarquerez que www.butterthlies.com et sales.butterthlies.com ont la même adresse IP : c’est pour que nous puissions expliquer le rôle de la directive NameVirtualHosts au chapitre suivant. Nous aurons besoin de sales-not-vh.butterthlies.com dans le site d’exemple site.twocopy. Cette méthode de définition des noms d’hôtes n’est généralement nécessaire que lorsqu’on ne dispose pas d’un DNS -- elle oblige à répéter la configuration sur toutes les machines devant connaître ces noms.