La version actuelle d'Apache est la 1.2.4. La version 1.3 est en test. Le site principal d'Apache est � http://www.apache.org/. Une autre bonne source d'information est Apacheweek � http://www.apacheweek.com/. La documentation d'Apache est bonne, je ne rentrerai donc pas dans les d�tails de la configuration d'apache. La documentaion est sur le site web et �galement incluse dans les sources (au format HTML). Il y a �galement des fichiers textes inclus dans les sources, mais la version HTML est meilleure. La documentation doit devenir bien meilleure depuis que le Apache Documentation Project a �t� lanc�. Pour l'instant la plupart des documents sont �crits par les d�veloppeurs. Sans vouloir discr�diter les d�veloppeurs, ils sont un peu difficiles � comprendre si vous ne connaissez pas la terminologie.
Apache est inclus dans les distributions Red Hat, Slackware, et OpenLinux. Cependant il se peut que ce ne soit pas la derni�re version, ce sont des binaires tr�s fiables. La mauvaise nouvelle est que vous aurez � vivre avec leurs choix de r�pertoires (qui sont totalement diff�rents les uns des autres et de ceux par d�faut d'Apache).
Le source est disponible sur le site web d'Apache � http://www.apache.org/dist/. Les binaires sont �galement disponibles au m�me endroit. Vous pouvez aussi obtenir les binaires de sunsite � ftp://sunsite.unc.edu/pub/Linux/apps/www/servers/ et pour la France sur ftp://ftp.lip6.fr/pub/linux/sunsite/apps/www/servers/. Et pour ceux d'entre vous qui utilisent une Red Hat le dernier fichier RPM se trouve g�n�ralement dans le r�pertoire des contributions � ftp://ftp.redhat.com/pub/contrib/i386/.
Si votre serveur doit desservir un dessein commercial, il est hautement recommand� que vous obteniez les sources � partir du site web d'Apache et de le compiler vous m�me. L'autre option est d'utiliser un binaire qui provient d'une distribution majeure, par exemple Slackware, Red Hat, ou OpenLinux. La principale raison en est la s�curit�. Un binaire inconnu peut avoir une "sortie cach�e" pour les hackers, ou une correction instable peut crasher votre syst�me. Ceci vous donnera �galement plus de contr�le sur les modules compil�s, et vous autorisera � changer les r�pertoires par d�faut. Il n'est pas difficile de compiler Apache, et vous ne serez pas un r�el utilisateur de Linux tant que vous ne compilerez pas vos programmes ;)
Tout d'abord d�compactez l'archive dans un r�pertoire temporaire. Ensuite
placez vous dans le r�pertoire src. Editez alors le fichier Configuration si
vous d�sirez ajouter des modules sp�ciaux. Les modules les plus commun�ment
utilis�s sont d�j� inclus. Il n'y a pas besoin de changer les r�gles ou le
makefile pour Linux. Lancez ensuite le script shell Configure
(./Configure). V�rifiez qu'il vous dit que vous utilisez une
plateforme Linux et gcc en tant que compilateur.
Ensuite vous pouvez �diter le fichier httpd.h pour changer les r�pertoires
par d�faut.
L'emplacement du serveur (o� sont conserv�s les fichiers de configuration)
par d�faut est /usr/local/etc/httpd/, mais vous pouvez le changer
pour juste /etc/httpd/. Et le r�pertoire principal du serveur (o�
sont conserv�es les pages HTML) par d�faut est
/usr/local/etc/httpd/htdocs/, mais j'appr�cie le r�pertoire
/home/httpd/html (le d�faut de Red Hat pour Apache). Si vous devez
utiliser su-exec (voir les options sp�ciales plus bas) vous pouvez �galement
d�sirer changer le r�pertoire. Le r�pertoire principal peut �galement �tre
chang� � partir des fichiers de config. Mais il est �galement bon de le
compiler, juste au cas o� Apache ne puisse trouvez ou lire les fichiers de
configuration. Tout le reste doit �tre chang� � partir des fichiers de
configuration.
Lancez enfin make pour compiler Apache.
Si vous avez des probl�mes au sujet de fichiers include manquants, v�rifiez les points suivants. V�rifiez que vous avez les ent�tes du noyau (fichiers include) install�s pour votre version du noyau. V�rifiez �galement que vous avez ces liens symboliques install�s:
/usr/include/linux doit �tre un lien sur /usr/src/linux/include/linux
/usr/include/asm doit �tre un lien sur /usr/src/linux/include/asm
/usr/src/linux doit �tre un lien sur les sources de Linux (ex.linux-2.0.30)
ln -s, cel� fonctionnera comme la
commande cp � part qu'il fera un lien ((ln -s SOURCE DESTINATION).Lorsque make a termin� il doit y avoir un ex�cutable nomm� httpd dans le
r�pertoire. Il est n�cessaire de le d�placer dans un r�pertoire bin.
/usr/sbin ou /usr/local/sbin seraient de bons choix.
Copiez les sous-r�pertoires conf, logs, et icons des sources vers
l'emplacement du serveur. Renommez ensuite trois des fichiers du
sous-r�pertoire conf pour vous d�barasser de l'extension -dist
((ex. httpd.conf-dist devient httpd.conf).
Il y a aussi divers programmes de support qui sont inclus avec Apache. Ils
sont dans le r�pertoire support et doivent �tre compil�s et install�s
s�par�ment/
La plupart d'entre eux peuvent �tre cr��s en utilisant le makefile de leur
r�pertoire (ce qui est fait lorsque vous lancez le script principal
Configure). Vous n'avez besoin d'aucun d'entre eux pour utiliser
Apache, mais certains rendent le travail des administrateurs plus simple.
Maintenant vous devez avoir quatre fichiers dans votre sous-r�pertoire
conf de l'emplacement du serveur. Le fichier httpd.conf met en
place le daemon du serveur (num�ro de port, utilisateur, etc). Le
srm.conf donne l'arborescence pour les documents principaux, les
actions sp�ciales, etc. Le access.conf donne les cas basiques pour
l'acc�s. Finalement, le mime.types dit au serveur que type mime il doit
envoyer au navigateur pour quelle extension.
Les fichiers de configuration sont assez bien document�s (ils sont pleins de commentaires), tant que vous comprenez le langage. Vous devriez les lire attentivement avant de mettre votre serveur en marche. Chaque option de configuration est couvert dans la documentation Apache.
Le fichier mime.types n'est pas r�ellement un fichier de configuration.
Il est utilis� par le serveur pour traduire les extensions des fichiers en
types mime � envoyer au navigateur. La plupart des types mime communs sont
d�j� dans le fichier. La majorit� des gens ne devrait pas �diter ce fichier.
Au cours du temps, plus de types mime seront ajout�s pour supporter de
nouveaux programmes. La meilleure chose � faire est de prendre un nouveau
fichier mime.types (et peut-�tre une nouvelle version du serveur) � ce
moment l�.
Souvenez vous toujours que lorsque vous changez les fichiers de
configuration vous devrez relancer Apache ou lui envoyer le signal SIGHUP
avec kill pour que les changements prennent effet. V�rifiez que vous
envoyez le signal au process parent et non aux process enfants. Le parent a
g�n�ralement le chiffre id le plus faible. L'id du process du parent est
�galement dans le fichier httpd.pid du r�pertoire log. Si vous envoyez
accidentellement le signal � un des process enfants, le process stoppera et
le parent le relancera.
Je ne vous conduirai pas le long des chemins de la configuration d'Apache. A la place je parlerai des probl�mes sp�cifiques, des choix � faire, et des options sp�ciales.
Je recommande chaudement que tous les utilisateurs lisent les trucs sur la s�curit� dans la documentation Apache. Elle est �galement disponible sur le site web d'Apache � http://www.apache.org/docs/mics/security_tips.html.
L'h�bergement virtuel existe lorsqu'un seul ordinateur dispose de plus d'un nom de domaine. L'ancienne m�thode �tait d'avoir une adresse IP pour chaque site virtuel. La nouvelle m�thode utilise uniquement une adresse IP, mais cel� ne fonctionne pas correctement avec les navigateurs qui ne supportent pas le HTTP 1.1.
Ma recommandation pour le commerce est de conserver un h�bergement virtuel bas� sur plusieurs IP jusqu'� ce que la majorit� des gens disposent de navigateurs supportant HTTP 1.1 (donnez leur un an ou deux). Ceci vous donne �galement une illusion plus compl�te de l'h�bergement virtuel. Alors que les deux m�thodes peuvent vous donner des possibilit�s de courrier virtuel (est ce que quelqu'un peut confirmer?), seul l'h�bergement virtuel bas� IP peut �galement vous donner un serveur FTP virtuel.
S'il s'agit d'un club ou d'une page personnelle, vous pouvez consid�rer l'h�bergement virtuel par IP li�e. Ce devrait �tre moins cher que l'h�bergement bas� IP et vous sauverez de pr�cieuses addresses IP.
Vous pouvez �galement m�langer les h�bergements virtuels par IP fixes et par IP partag�es sur le m�me serveur. Pour plus d'information sur l'h�bergement virtuel voyez Apacheweek sur http://www.apacheweek.com/features/vhost.
Pour cette m�thode chaque site virtuel dispose de sa propre adresse IP. En d�terminant l'adresse IP � laquelle la requ�te �tait envoy�e, Apache et d'autres programmes peuvent dire quel domaine desservir. C'est un incroyable gain d'adresses IP. Prenez par exemple les serveurs o� est conserv� mon domaine virtuel. Ils ont plus de 35.000 comptes virtuels, ce qui signifie 35.000 adresses IP. Pourtant je crois qu'aux derniers comptes ils avaient moins de 50 serveurs r�els.
La configuration se fait en deux parties. La premi�re consiste � obtenir de Linux l'acceptation de plus d'une adresse IP. La seconde est de configurer apache pour servir les sites virtuels.
La premi�re �tape dans la configuration pour l'acceptation par Linux de multiples adresses IP est de cr�er un nouveau noyau. Ceci fonctionne mieux avec la s�rie des noyaux 2.0 (ou sup�rieure). Vous devrez inclure le support pour "IP networking" et "IP aliasing". Si vous avez besoin d'aide pour la compilation du noyau voyez le kernel howto, ou sa version fran�aise sur http://www.freenix.org/unix/linux/HOWTO/Kernel-HOWTO.html.
Vous devrez ensuite configurer chaque interface au lancement. Si vous utilisez la distribution Red Hat akirs ceci peut �tre fait � partir du panneau de contr�le. Lancez X-Window en tant que super-utilisateur, vous devriez voir un panneau de contr�le. Double-cliquez sur "network configuration" (configuration r�seau). Allez ensuite sur le panneau des interfaces et choisissez votre carte r�seau. Ensuite cliquez sur alias en bas de l'�cran. Rentrez les informations et cliquez sur "done". Ceci devra �tre fait pour chaque site virtuel / adresse IP.
Si vous utilisez une autre distribution vous pouvez avoir � le faire
manuellement. Vous pouvez simplement mettre les commandes dans le fichier
rc.local de /etc/rc.d (en r�alit� vous devriez les mettre avec
toutes celles concernant le r�seau). Vous devrez avoir une commande
ifconfig et route pour chaque p�riph�rique. Les adresses en alias
sont divis�es sous le p�riph�rique principal. Par exemple eth0 aurait les
alias eth0:0, eth0:1, eth0:2, etc. Voici un exemple de configuration d'un
alias:
ifconfig eth0:0 192.168.1.57
route add -host 192.168.1.57 dev eth0:0
Vous devrez ensuite configurer votre domain name server (DNS) pour desservir ces nouveaux domaines. Et si vous ne poss�dez pas d�j� les noms de domaine, vous devrez contacter l' Internic pour enregistrer les noms de domaines. Voyez le DNS-howto pour plus d'informations sur la configuration de votre DNS.
Derni�rement vous devrez configurer Apache de mani�re � desservir
correctement le domaine virtuel. Ceci se fait dans le fichier de
configuration httpd.conf pr�s de la fin. Ils vous donnent un exemple
sur la fa�on de proc�der. Toutes les commandes sp�cifiques au site virtuel
sont plac�s entre les marqueurs virtualhost. Vous pouvez mettre � peu
pr�s n'importe quelle commande ici.
G�n�ralement vous devrez placer diff�rents r�pertoires pour le serveur, le
r�pertoire script, et les fichiers de log. Vous pouvez avoir un nombre
quasi-illimit� de sites virtuels en ajoutant plus de marqueurs
virtualhost.
Dans de rares cas vous pouvez avoir � lancer des serveurs s�par�s si une directive est n�cessaire pour un site virtuel, mais n'est pas accept� dans les marqueurs du site virtuel. Ceci se fait en utilisant la directive bindaddress. Chaque serveur aura un nom des fichiers de configuration diff�rents. Chaque serveur r�pondra seulement � une seule adresse IP, sp�cifi�e par la directive bindaddress. C'est un gain incroyable de ressources syst�me.
C'est une nouvelle m�thode pour l'h�bergement virtuel. Elle utilise une adresse IP simple, tout en conservant les adresses IP pour les vrais machines (et pas les virtuelles). Dans le m�me exemple utilis� plus haut ces 30.000 sites virtuels utiliseraient seulement 50 adresses IP (une pour chaque machine). Ceci est fait en utilisant le nouveau protocole HTTP 1.1. Le navigateur dit au serveur quel site il d�sire lorsqu'il envoie la demande. Le probl�me est que les navigateurs qui ne supportent pas HTTP 1.1 obtiendront la page principale des serveurs, qui peut �tre configur�e pour donner la liste des sites virtuels disponibles. Ceci ruine la totale illusion de l'h�bergement virtuel. L'illusion que vous avez votre propre serveur.
La configuration est bien plus simple que pour l'h�bergement virtuel bas� sur IP. Vous aurez toujours besoin d'obtenir votre domaine � partir de l'Internic et de configurer votre DNS. Cette fois-ci le DNS pointe sur la m�me adresse IP que le domaine original. Ensuite Apache se configure comme pr�c�demment. Puisque vous utilisez la m�me adresse IP dans les marqueurs virtualhost, Apache sait que vous d�sirez l'h�bergement virtuel par IP partag�e.
Il y a diff�rentes choses � faire pour les anciens navigateurs. Je vais vous
expliquer la meilleure. Tout d'abord vous devrez cr�er vos pages principales
pour un serveur virtuel (soit bas� IP, soit par IP partag�e). Ceci lib�re la
page principale pour un lien listant tous vos sites virtuels. Ensuite vous
devrez cr�er une sortie cach�e pour les anciens navigateurs. On le r�alise
en utilisant la directive ServerPath pour chaque site virtuel de la
directive virtualhost. Par exemple en ajoutant ServerPath
/monsite/ � www.monsite.com, les anciens navigateurs pourront acc�der
au site par www.monsite.com/monsite/. Ensuite mettez dans la page par d�faut
du serveur principal un message qui les incitera poliment � obtenir un
nouveau navigateur, et listera les liens sur toutes les sorties cach�es des
sites qye vous h�bergez sur cette machine. Lorsqu'un ancien navigateur
acc�dera au site ils seront renvoy�s � la page principale, et auront un lien
sur la page correcte. Les nouveaux navigateurs ne verront jamais la page
principale et iront directement sur les sites virtuels. Vous devez vous
rappeler de conservez tous vos liens relatifs entre les sites web, car les
pages seront demand�es � partir de deux URL diff�rentes (www.monsite.com et
www.monsite.com/monsite/).
J'esp�re que je ne vous ai pas perdu ici, mais ce n'est pas d'une compr�hension simple. Apr�s tout, vous devriez peut-�tre consid�rer l'h�bergement bas� IP. Une explication tr�s similaire se trouve sur le site web d'apache � http://www.apache.org/manual/host.html.
Si quelqu'un dispose d'un pointeur sympathique pour l'h�bergement par IP partag�e, j'aimerais le conna�tre. Il serait agr�able de conna�tre le pourcentage de navigateurs qui supportent le HTTP 1.1, et d'avoir une liste des navigateurs et des versions qui supportent HTTP 1.1.
Il existe deux m�thodes diff�rentes pour donner � vos utilisateurs la
possibilit� d'utiliser des scripts CGI. La premi�re est de d�clarer tout
fichier se terminant par .cgi comme script CGI. La seconde est de cr�er
des r�pertoires de scripts (g�n�ralement nomm�s cgi-bin). Vous pouvez
�galement utiliser les deux m�thodes. Quelque soit la m�thode utilis�e vos
scripts doivent �tre ex�cutable par n'importe qui (chmod 711). En
donnant � vos utilisateurs l'acc�s aux scripts vous cr�ez un gros risque de
s�curit�. Fa�tes proprement votre travail afin de minimiser les risques
concernant la s�curit�.
Je pr�f�re la premi�re m�thode, sp�cialement pour les scripts complexes.
Ceci vous autorisera � mettre les scripts dans n'importe quel r�pertoire.
J'aime mettre mes scripts au m�me endroit que les pages web qui s'en
servent. Pour les sites avec beaucoup de script, ceci est beaucoup mieux que
d'avoir un r�pertoire plein de scripts. La configuration est simple. Tout
d'abord supprimez le commentaire du marqueur .cgi � la fin du fichier
srm.conf. Ensuite v�rifiez que tous vos r�pertoires ont les marqueurs
option ExecCGI ou All dans le fichier access.conf.
Cr�er un r�pertoire de scripts est consid�r� comme plus s�r.
Pour cr�er un r�pertoire de scripts vous utilisez la directive ScriptAlias
dans le fichier srm.conf. Le premier argument est l'Alias, et le second
le r�pertoire r�el. Par exemple ScriptAlias /cgi-bin/
/usr/httpd/cgi-bin/ rend le r�pertoire /usr/httpd/cgi-bin
capable d'ex�cuter les scripts. Ce r�pertoire sera utilis� m�me si
quelqu'un demande le r�pertoire /cgi-bin/. Pour des raisons de
s�curit� vous devez �galement changer les propri�t�s du r�pertoire pour
Options none, AllowOveride none dans le fichier access.conf
(supprimer simplement les commentaires de l'exemple donn�). Egalement ne
placez pas vos r�pertoires de scripts en tant que sous r�pertoire de vos
r�pertoires de pages web. Par exemple si vous servez les pages � partir de
/home/httpd/html/, ne cr�ez pas le r�pertoire de scripts en tant
que /home/httpd/html/cgi-bin; au lieu de �a mettez le dans
/home/httpd/cgi-bin.
Si vous d�sirez que vos utilisateurs disposent de leurs propres
r�pertoires de scripts vous pouvez utiliser de multiples commandes
ScriptAlias. Les sites virtuels doivent avoir cette commande
ScriptAlias dans leurs directives virtualhost.
Est ce que quelqu'un conna�t un moyen simple pour autoriser les utilisateurs
� avoir leur propre r�pertoire cgi-bin sans utiliser des commandes
individuelles ScriptAlias ?
Il y a deux diff�rentes m�thodes pour s'occuper des r�pertoires web des
utilisateurs. La premi�re est d'avoir un sous-r�pertoire dans les
r�pertoires des utilisateurs (g�n�ralement public_html).
La seconde est d'avoir une aborescence enti�rement diff�rente pour les
r�pertoires web.
Pour ces deux m�thodes v�rifiez les options d'acc�s aux r�pertoires dans le
fichier access.conf.
La premi�re m�thode est configur�e par d�faut dans apache. Lorsqu'une
demande pour /~bob/ arrive, Apache regarde dans le r�pertoire
public_html du r�pertoire principal de bob. Vous pouvez changer le
r�pertoire avec la directive UserDir dans le fichier srm.conf. Ce
r�pertoire doit lisible et ex�cutable par tout le monde.
Cette m�thode cr�e un risque pour la s�curit� car Apache le r�pertoire
principal eds utilisateurs doit �tre ex�cutable par toute personne afin
qu'Apache puisse y acc�der.
La seconde m�thode est facile � configurer. Vous devez juste changer la
directive UserDir dans le fichier srm.conf. Il y a
beaucoup de formats diff�rents; vous pouvez voir la documentation d'Apache
pour clarification. Si vous que chaque utilisateur dispose de son propre
r�pertoire sous /home/httpd/, vous utiliserez UserDir
/home/httpd. Ensuite lorsqu'une demande arrivera pour /~bob/
Apache la traduira pour /home/httpd/bob/. Ou si vous avez un
sous-r�pertoire dans le r�pertoire de bob vous pouvez utiliser UserDir
/home/httpd/*/html. Ceci traduira en /home/httpd/bob/html/ et
vous autorisera �galement � avoir un r�pertoire de script (par exemple
/home/httpd/bob/cgi-bin/).
Il y a deux m�thodes par lesquelles apache peut tourner. L'une est un d�mon qui tourne tout le temps (Apache appelle ceci standalone). La seconde est celle du super-serveur inetd.
Le mode d�mon est de loin sup�rieur au mode inetd. Apache est configur� pour le mode d�mon par d�faut. La seule raison d'utiliser le mode d'inetd est pour les applications tr�s peu utilis�es, comme les tests de scripts en interne, l'Intranet d'une petite compagnie, etc. Le mode inetd �conomisera de la m�moire car apache ne sera charg� que lorsqu'il sera demand�. Seul le d�mon inetd restera en m�moire.
Si vous n'utilisez pas tr�s souvent apache vous pouvez juste vouloir le conserver en mode d�mon et le lancer lorsque vous en avez besoin. Ensuite vous pouvez le supprimer lorsque vous avez termin� (soyez s�r de bien supprimer le processus parent et non pas un des enfants).
Pour configurer le mode inetd vous devrez �diter quelques fichiers. Tout
d'abord /etc/services regardez si http est d�j� pr�sent. S'il n'y
est pas alors ajoutez ceci:
http 80/tcp
/etc/inetd.conf et ajouter la ligne pour Apache:
http stream tcp nowait root /usr/sbin/httpd httpd
Si le d�mon inetd est d�j� lanc� (inetd), alors vous devez lui envoyer
le signal SIGHUP (par kill; voyez la page de manuel de kill pour plus
d'infos) ou relancer l'ordinateur pour que les changements soient effectifs.
Si vous n'avez pas lanc� inetd alors vous pouvez le lancer
manuellement. Vous devez �galement l'ajouter � vos fichiers d'initialisation
afin qu'il soit charg� au lancement (le fichier rc.local serait un bon
choix).
Les nouveaux outils de publication web supportent cette nouvelles m�thodes d'envoi des pages web par http (� la place de FTP). Certains de ces produits ne supportent m�me plus le FTP! Apache le supporte, mais il manque d'un script pour se charger des requ�tes. Le script peut �tre un gros trou de s�curit�, soyez certain de ce que vous fa�tes avant de tenter d'en �crire ou d'en installer un.
Si quelqu'un conna�t un script qui fonctionne fa�tes le moi savoir et j'incluerai l'adresse ici.
Pour plus d'informations voyez l'article d'Apacheweek � http://www.apacheweek.com/features/put.
Il s'agit de l'une de mes options pr�f�r�es. Elle vous autorise � prot�ger un r�pertoire ou un fichier par un mot de passe sans utiliser de scripts CGI. Il vous autorise �galement � interdire ou � autoriser l'acc�s sur la base de l'adresse IP ou du nom de domainde du client. C'est une sp�cificit� tr�s int�ressante pour laisser les cr�tins hors de votre messagerie et des vos livres d'or (vous avez l'IP ou le nom de domaine � partir de vos fichiers de log).
Pour autoriser l'authentification de l'utilisateur le r�pertoire doit avoir
AllowOverrides AuthConfig dans le fichier access.conf. Pour
autoriser le contr�le d'acc�s (par domaine ou adresse IP) AllowOverrides
Limit doit �tre mis pour ce r�pertoire.
La configuration du r�pertoire oblige le placement d'un fichier
.htaccess dans le r�pertoire. Pour l'authentification de l'utilisateur
il est �galement utilis� avec un .htpasswd et optionnellement un
fichier .htgroup. Ces fichiers peuvent �tre partag�es pour de multiples
fichiers .htaccess si vous le d�sirez.
Pour des raisons de s�curit� je recommande que chacun utilise ces directives dans leur fichier access.conf:
<files ~ "/\.ht">
order deny,allow
deny from all
</files>
Si vous n'�tes pas l'administrateur du syst�me vous pouvez �galement l'ajouter dans votre fichier .htaccess si AllowOverride Limit est configur� pour votre r�pertoire. Cette directive interdira � quiconque de regarder dans vos fichiers de contr�le d'acc�s (.htaccess, .htpasswd, etc).
Il y a de nombreux types de fichiers et d'options qui peuvent �tre utilis�s avec le contr�le d'acc�s. Toutefois il n'est pas de la comp�tence de ce document de d�crire ces fichiers. Pour les informations sur la configuration de l'authentification des utilisateurs voyez l'article d'Apacheweek � http://www.apacheweek.com/features/userauth ou les pages de la NCSA � http://hoohoo.ncsa.uiuc.edu/docs-1.5/tutorials/user.html.
su-exec lance les scripts CGI en tant qu'utilisateur du propri�taire. Normalement ils sont lanc�s en tant qu'utilisateur du serveur web (g�n�ralement nobody). Ceci autorise les utilisateurs � acc�der � leurs propres fichiers CGI sans les rendre autoris�s en �criture (un trou de s�curit�). Mais si vous ne fa�tes pas attention vous pouvez un trou encore plus gros en utilisant le code su-exec. Celui-ci effectue des contr�les de s�curit� avant d'ex�cuter les scripts, mais si vous le configurez de mani�re incorrecte vous aurez un trou de s�curit�.
Le code su-exec n'est pas pour les amateurs. Ne l'utilisez pas si vous ne savez pas ce que vous fa�tes. Vous pouvez terminer par un gros probl�me de s�curit� o� vos utilisateurs peuvent obtenir des acc�s super-utilisateurs pour votre syst�me. Ne modifiez pas le code quelqu'en soit la raison. Lisez attentivement toute la documentation. Le code su-exec est intentionnellement difficile � configurer afin d'�viter l'utilisation par des amateurs (tout doit �tre fait � la main, il n'y a pas de script d'installation).
Le code su-exec se trouve dans le r�pertoire support des sources. Tout
d'abord vous devez �diter le fichier suexec.h pour votre syst�me.
Ensuite vous devez compiler le code su-exec avec cette commande:
gcc suexec.c -o suexec
/usr/local/etc/httpd/sbin/. Ceci peut �tre
chang� en �ditant le fichier httpd.h dans les sources d'Apache et en
recompilant Apache. Apache regardera seulement dans ce r�pertoire, Il ne
cherchera pas ailleurs. Ensuite le fichier doit �tre chang� pour la
possession par le super-utilisateur (chown root suexec) et les
permissions doivent �tre chang�es (chmod 4711 suexec).
Enfin relancez Apache, il doit vous donner un message sur la console
indiquant que su-exec est utilis�.Les scripts CGI doivent �tre mis en ex�cutable par tous comme d'habitude.
Ils seront automatiquement lanc�s par le possesseur du script CGI. Si vous
changez les permissions les scripts CGI ne fonctionneront pas. Si le
r�pertoire ou le fichier est en �criture par tous ou par un groupe le script
ne fonctionnera pas. Les scripts poss�d�s par les utilisateurs syst�me ne
doivent pas �tre lanc�s (root, bin, etc.). Pour les autres conditions de
s�curit� qui doivent �tre remplies voyez la documentation de su-exec. Si
vous avez des probl�mes voyez le fichier de log de su-exec nomm�
cgi.log.
Su-exec ne fonctionne pas si vous lancez Apache par inetd, il fonctionne seulement en mode d�mon. Ceci sera fix� dans la prochaine version car il n'y aura pas de mode inetd. Si vous aimez jouer avec le code source, vous pouvez �diter le fichier http_main.c. Vous pouvez rire de la ligne o� Apache annonce qu'il utilise le su-exec wrapper (ceci est faussement marqu� sur l'avant de toute sortie).
Lisez attentivement la documentation d'Apache sur su-exec. Elle est inclue dans les sources et est disponible sur le site web d'Apache � http://www.apache.org/docs/suexec.html.
Apache peut g�rer des cartes d'images du c�t� du serveur. Ce que l'on
appelle "Imagemaps" sont les images des pages web qui envoient les
utilisateurs � divers emplacements, d�pendant de l'endroit o� ils cliquent.
Pour utiliser les imagemaps v�rifiez que le module imagemap est install�
(c'est un des modules par d�faut). Ensuite vous devez supprimer le
commentaire de la ligne .map � la fin du fichier srm.conf.
Maintenant tous les fichiers se terminant en .map seront des fichiers
d'imagemap. Les fichiers imagemap d�limitent diff�rentes aires sur l'image
renvoyant vers des liens s�par�s. Apache utilise des fichiers d'aires au
format standard NCSA. Voici un exemple utilisant un fichier d'aire dns une
page web:
<a href="/map/mapfile.map">
<img src="picture.gif" ISMAP>
</a>
mapfile.map est le fichier d'aires, et
picture.gif est l'image cliquable.Il y a de nombreux programmes qui peuvent g�n�rer des fichiers d'aires compatibles NCSA ou vous pouvez les cr�er vous-m�me. Pour une discussion plus d�taill�e sur les imagemaps et les fichiers d'aires voyez l'article d'Apacheweek � http://www.apacheweek.com/features/imagemaps.
Les Server Side Includes (SSI) ajoutent un contenu dynamique � des pages web qui sinon seraient statiques. Les en-t�tes sont ajout�s dans les pages web en tant que commentaires. Le serveur web les ex�cute ensuite et passe les r�sultats au serveur web. SSI peut ajouter des en-t�tes et des notes de pieds aux documents, ajouter la date � laquelle le document a �t� modifi� pour la derni�re fois, ex�cuter une commande syst�me ou un script CGI. avec le tout nouveau eXtended Server Side Includes (XSSI) vous pouvez faire bien plus. XSSI ajoute les variables et les instructions de contr�le du flux (if, else, etc). C'est quasiment comme avoir un langage de programmation avec lequel on peut travailler.
L'analyse syntaxique de tous les fichiers pour les commandes SSI utiliserait
beaucoup de ressources syst�me. Cependant vous devez distinguer les fichiers
HTML normaux de ceux qui contiennent les commandes SSI. Ceci se fait
g�n�ralement en changeant l'extension des fichiers HTML utilisant SSI.
G�n�ralement on utilise l'extension .shtml.
Pour faire fonctionner SSI/XSSI v�rifiez tout d'abord que le module des
en-t�tes est install�. Editez ensuite srm.conf et supprimez les
commentaires des directives AddType et AddHandler pour les
fichiers .shtml. Finalement vous devez configurer Options Includes
pout tous les r�pertoires o� vous d�sirez lancer des fichiers SSI/XSSI. Ceci
se fait dans le fichier access.conf. Maintenant tous les fichiers avec
l'extension .shtml seront analys�s pour les commandes SSI/XSSI.
Un autre moyen de faire fonctionner les en-t�tes est d'utiliser la directive
XBitHack. Si vous la mettez en marche il regardera si le fichier est
ex�cutable par l'utilisateur. Si il l'est et que Options Includes est
autoris� pour le r�pertoire, alors le fichier sera trait� comme un fichier
SSI. Ceci fonctionne seulement pour les fichiers dont le type mime est
text/html (fichiers .html .htm). Ceci n'est pas la m�thode pr�f�r�e.
Il y a un risque pour la s�curit� en autorisant SSI � ex�cuter des commandes
syst�mes et des scripts CGI. Toutefois il est possible de bloquer cette
possibilit� avec la directire Option IncludesNOEXEC au lieu de Option
Includes dans le fichier access.conf. Toutes les autres commandes SSI
fonctionneront encore.
Pour plus d'informations voyez la documentation d'Apache mod_includes qui se trouve dans les sources. Il est �galement disponible sur le site web � http://www.apache.org/docs/mod/mod_include.html.
Pour une discussion plus d�taill�e de l'impl�mentation SSI/XSSI voyez l'article d'Apacheweek � http://www.apacheweek.com/features/ssi.
Pour plus d'informations sur les commandes SSI voyez la documentation de la NCSA � http://hoohoo.ncsa.uiuc.edu/docs/tutorials/includes.html.
Pour plus d'informations sur les commandes XSSI allez sur ftp://pageplus.com/pub/hsf/xssi/xssi-1.1.html.
Apache peut �tre �tendu pour supporter quasiment tout avec les modules. Il y a beaucoup de modules qui existent d�j�. Seul les modules d'int�r�t g�n�ral sont inclus avec Apache. Pour les liens vers les modules existants allez voir le
Apache Module Registry � http://www.zyzzyva.com/module_registry/.
Pour les informations sur la programmation des modules voyez http://www.zyzzyva.com/module_registry/reference/
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:21