Le Jeudi 27 F�vrier 2003 09:40, furstoss maurice a �crit : > Wed, 26 Feb 2003 17:41:24 +0000 > AMORE Rosaire <[EMAIL PROTECTED]> �crivait: > > > Je ne sais pas si je t'ai d�j� demand�, auquel cas, excuses : as-tu > > lanc� portmap (/etc/init.d/portmap start). Sur le client ET sur le serveur. > > NFS et PORTMAP sont lanc�s sur les deux (8.2 et 9.0) > pr�cision, � l'arr�t de la 9 j'ai une erreur sur arr�t de NFS STATD, d'autre part dans MCC/Point de montage NFS la 8 trouve les 2 stations mais la 9 ne trouve rien... > > > > je reviens sur le sujet; tous les services nfs sont lanc�s, le r�seau fonctionne (pings et partage connexion internet), le fichier "exports" est renseign� par l'interface graphique > > > > �a, je ne sais m�me pas ce que �a veut dire. Mais pour �tre s�r (les > > interfaces graphiques ne finissent pas tjs leur boulot), v�rifie le > > fichier /etc/exports. Son contenu doit ressembler, � minima, � ceci : > > ======================= > > /rep_paratag� machines_ou_reso_autoris� (options) > > ======================= > > Ce qui donne concr�tement pour l'exemple que je tire de chez moi (une > > ligne du fichier) : > > > > /ext 192.168.0.2(rw, no_root_squash) > > le mien sur la 9: " /home/furstoss/sauveurs *(ro,all_squash,sync) > /home/furstoss/Documentation *(ro,all_squash,sync)" > "sync" est une nouvaut� de la 9 > je fais exportfs -a si j'y touche, je mounte et toujours le sempiternel:"RPC: �chec de conversion de ports, incapable d'effectuer la r�ception" dans un sens ou dans l'autre... > d�sesp�rant!
ATTENTION /home/furstoss/sauveurs et /home/furstoss/Documentation ne doivent PAS etre vides c est OK ? sinon regardes un peu le HOWTO en fichier joint. > maurice Furstoss > ch. des ch�nes Toupiargues > 30260 SARDAN > t�l: 0466773455 > > -- a+ [EMAIL PROTECTED]Title: Linux WWW-HOWTO: Apache Page suivante Page pr�c�dente Table des mati�res
7. Apache
La version actuelle d'Apache est la 1.3.9. Le site principal d'Apache est sur http://www.apache.org/. Une autre bonne source d'information est Apacheweek sur 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.
7.1 O� l'obtenir ?
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 servir 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 vrai utilisateur de Linux tant que vous ne compilerez pas vos programmes ;)
7.2 Compiler et Installer
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 pas trouver 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 d'inclusion 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.
7.3 Configurer
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 sp�cifie l'arborescence pour les documents principaux, les
actions sp�ciales, etc. Le access.conf sp�cifie les conditions de base
pour l'acc�s. Finalement, le mime.types indique au serveur quel 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 fil du temps, de plus en plus de types mime seront ajout�s pour supporter
de nouveaux programmes. La meilleure chose � faire sera 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 devez 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 d�taillerai pas la configuration d'Apache. Je me contenterai de parler des probl�mes sp�cifiques, des choix � faire, et des options sp�ciales.
Je recommande chaudement que tous les utilisateurs parcourent le chapitre 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.
7.4 H�berger des serveurs web virtuels
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 une seule adresse IP, mais cel� ne fonctionne pas correctement avec les navigateurs qui ne supportent pas le HTTP 1.1.
Ma recommandation pour les sites commerciaux 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 impression plus compl�te d'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 envisager l'h�bergement virtuel par IP partag�e. Ce devrait �tre moins cher que l'h�bergement bas� IP et vous �conomiserez 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.
H�bergement virtuel bas� IP
Pour cette m�thode chaque site virtuel dispose de sa propre adresse IP. En fonction de l'adresse IP � laquelle la requ�te a �t� envoy�e, Apache et d'autres programmes d�terminent quel domaine desservir. C'est un incroyable gaspillage d'adresses IP. Prenez par exemple l'ensemble de 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 � rendre Linux capable de reconna�tre plus d'une adresse IP. La seconde est de configurer apache pour servir les sites virtuels.
La premi�re �tape pour rendre Linux capable d'accepter plusieurs adresses IP consiste � compiler 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/linux/HOWTO/Kernel-HOWTO.html.
Vous devrez ensuite sp�cifier la configuration de chaque interface au lancement du syst�me. Si vous utilisez la distribution Red Hat, 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 constitu�es � partir du 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 serveur de noms (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.
Pour finir, 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�es 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 d'autres 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�e dans les marqueurs du site virtuel. Ceci se fait en utilisant la directive bindaddress. Chaque serveur aura un nom et des fichiers de configuration diff�rents. Chaque serveur r�pondra � une seule adresse IP, sp�cifi�e par la directive bindaddress. C'est un gaspillage incroyable de ressources syst�me.
H�bergement virtuel par IP partag�e
C'est une nouvelle m�thode pour l'h�bergement virtuel. Elle utilise une adresse IP unique, r�servant les adresses IP aux vraies machines (et pas les virtuelles). Dans l'exemple cit� 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 du serveur, qui peut �tre configur�e pour donner la liste des sites virtuels disponibles. Ceci ruine toute l'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 de l'Internic votre domaine 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 plusieurs solutions pour les anciens navigateurs. Je vais vous
expliquer la meilleure. Tout d'abord vous devrez cr�er vos pages principales
comme 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 � se procurer un
nouveau navigateur, et listera les liens sur toutes les sorties cach�es des
sites que vous h�bergez sur cette machine. Lorsqu'un ancien navigateur
acc�dera au site, l'utilisateur sera renvoy� � la page principale, et aura
un lien sur la page correcte. Les nouveaux navigateurs ne verront jamais la
page principale et iront directement sur les sites virtuels. Vous devez
veiller � n'avoir que des liens relatifs � l'int�rieur de chaque site 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 embrouill� ici, mais ce n'est pas d'une compr�hension simple. Apr�s tout, vous devriez peut-�tre envisager 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.
7.5 Scripts CGI
Il existe deux m�thodes diff�rentes pour donner � vos utilisateurs la
possibilit� d'utiliser des scripts CGI. La premi�re est de consid�rer tout
fichier se terminant par .cgi comme un script CGI. La seconde est de cr�er
des r�pertoires de scripts (g�n�ralement nomm�s cgi-bin). Vous pouvez
utiliser les deux m�thodes �galement. Quelle que soit la m�thode utilis�e vos
scripts doivent �tre ex�cutables 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 scripts, c'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 de contenir des scripts ex�cutables. Ce r�pertoire sera utilis� chaque
fois quelqu'un demandera 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 � l'int�rieur de la m�me arborescence que
les 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; mais plut�t
/home/httpd/cgi-bin.
Si vous d�sirez que vos utilisateurs disposent de leurs propres
r�pertoires de scripts vous pouvez utiliser plusieurs 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 ?
7.6 R�pertoires Web des Utilisateurs
Il y a deux m�thodes diff�rentes pour g�rer les 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 ce r�pertoire avec la
directive UserDir dans le fichier srm.conf. Ce
r�pertoire doit �tre lisible et ex�cutable par tout le monde.
Cette m�thode cr�e un risque pour la s�curit� car le r�pertoire
principal des 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 voulez 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 par /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 � avoir aussi un r�pertoire de script (par exemple
/home/httpd/bob/cgi-bin/).
7.7 Mode d�mon contre mode Inetd
Il y a deux m�thodes pour faire tourner Apache. L'une est d'avoir 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 le conserver en mode d�mon et le lancer lorsque vous en avez besoin. Ensuite vous le supprimez 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 d�marrage du syst�me (le fichier rc.local serait
un bon choix).
7.8 Autoriser les commandes put et delete
Les nouveaux outils de publication web supportent cette nouvelle m�thode d'envoi des pages web par http (� la place de FTP). Certains de ces produits ne supportent m�me plus le FTP! Apache supporte cette m�thode, mais il manque d'un script pour se charger des requ�tes. Ce script pourrait �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.
7.9 Authentification de l'Utilisateur / Contr�le des Acc�s
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 script CGI. Elle vous autorise �galement � interdire ou � autoriser l'acc�s sur la base de l'adresse IP ou du nom de domaine du client. C'est une sp�cificit� tr�s int�ressante pour �carter les cr�tins de votre messagerie et de vos livres d'or (vous trouvez l'IP ou le nom de domaine dans vos fichiers de log).
Pour permettre l'authentification de l'utilisateur, le r�pertoire doit avoir
AllowOverrides AuthConfig dans le fichier access.conf. Pour
permettre 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 n�cessite de placer 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�s pour de multiples
fichiers .htaccess si vous le d�sirez.
Pour des raisons de s�curit� je recommande que chacun utilise ces directives dans ses 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, d�crire ces fichiers d�passe le propos de ce document. 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.
7.10 su-exec
su-exec lance les scripts CGI avec l'identit� du propri�taire du script. Normalement, ils sont lanc�s avec la m�me identit� que le serveur web (g�n�ralement nobody). Ceci permet aux utilisateurs de rendre leurs propres fichiers accessibles par les scripts, sans mettre ces fichiers en �criture pour tout le monde (un trou de s�curit�). Mais si vous ne fa�tes pas attention, vous pouvez avoir 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 vous retrouver avec un gros probl�me de s�curit�, vos utilisateurs pouvant obtenir des acc�s super-utilisateurs. Ne modifiez pas le code quelle qu'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. Le fichier doit �tre la
propri�t� du 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 rendus ex�cutables 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. Il ne faut pas lancer de script poss�d� par un
utilisateur syst�me (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 corrig� dans la prochaine version en ce qu'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 vous d�barrasser de la ligne o� Apache annonce qu'il utilise le su-exec wrapper (ce qui est faussement indiqu� en t�te de chaque message).
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.
7.11 Imagemaps
Apache peut g�rer des cartes graphiques du c�t� du serveur. Ce que l'on
appelle "Imagemaps" sont des images dans des pages web qui envoient les
utilisateurs � divers emplacements, selon 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
associ�es chacune � un lien diff�rent. Apache utilise des fichiers d'aires au
format standard NCSA. Voici un exemple utilisant un fichier d'aire dans une
page web:
<a href="">
<img src="" 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.
7.12 SSI/XSSI
Les Server Side Includes (SSI) ajoutent un contenu dynamique � des pages web qui sinon seraient statiques. Les clauses d'inclusion sont ins�r�es 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 pieds de page 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 (if, else, etc). C'est quasiment comme travailler avec un langage de programmation.
L'analyse syntaxique de tous les fichiers relativement aux commandes SSI utiliserait
beaucoup de ressources syst�me. C'est pourquoi il faut 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.
Habituellement on utilise l'extension .shtml.
Pour utiliser SSI/XSSI, v�rifiez tout d'abord que le module des
includes est install�. Editez ensuite srm.conf et supprimez les
commentaires des directives AddType et AddHandler pour les
fichiers .shtml. Enfin, vous devez configurer Options Includes
pour tous les r�pertoires o� vous d�sirez ex�cuter des fichiers SSI/XSSI. Ceci
se fait dans le fichier access.conf. Maintenant, tous les fichiers avec
l'extension .shtml seront analys�s relativement aux commandes SSI/XSSI.
Un autre moyen de faire fonctionner les inclusions est d'utiliser la directive
XBitHack. Si vous l'activez, 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 meilleure m�thode.
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. Elle 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.
7.13 Syst�me modulaire
Les fonctionnalit�s d'Apache peuvent �tre �tendues quasiment � l'infini avec les modules. Il existe d�ja beaucoup de modules. Seuls les modules d'int�r�t g�n�ral sont inclus dans Apache. Pour des pointeurs 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/
Page suivante Page pr�c�dente Table des mati�res
Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft? Rendez-vous sur "http://www.mandrakestore.com";
