Forums d'entraide informatique - Astuces - Conseils

Si vous êtes en train d'installer un serveur qui fait également office de passerelle NAT pour l'accès à Internet (comme c'est bien souvent le cas avec une machine personnelle), vous souhaitez sans doute trouver une solution pour accélérer la navigation sur le Web. Bien sûr, le cache de votre navigateur fait déjà ce travail, mais pour votre poste et votre compte uniquement. Il existe une solution plus globale.
Le principe du cache est relativement simple. Lors d'une transaction normale entre un client et un ser- veur HTTP, le client envoie une requête au serveur, qui l'analyse et retourne l'objet désiré par le client. Ce dialogue s'établit suivant le protocole HTTP. Ainsi, en tant que client, vous passez votre temps à demander des objets aux différents serveurs aux- quels vous vous connectez. Imaginez maintenant qu'au cours d'une visite d'un site vous soyez conduit à repasser par les mêmes pages ou encore à afficher plusieurs fois le même élément graphique (images) sur les différentes pages visitées. Il devient parfaitement inutile de télécharger à nouveau ces pièces depuis le serveur, il nous suffit d'utiliser celles déjà en notre possession.
Voilà exactement ce que fait le cache de votre navi- gateur. Il conserve en permanence une trace des élé- ments déjà téléchargés pendant un certain temps. Lorsque le contenu du cache est considéré comme périmé, il est supprimé.
La solution est intéressante, mais il est possible de faire mieux. En effet, si, sur votre réseau local, plu- sieurs clients accèdent au Web, il est fort probable que les sites et les pages visités soient, dans une cer- taine mesure, similaires. Il est donc intéressant que le cache soit commun à tous les utilisateurs. Le jour où l'un d'entre eux ira sur un site déjà visité par une autre personne, il ne sera plus nécessaire de télé- charger les fichiers du serveur, niais on pourra les prendre directement dans le cache commun. Plus il y aura d'utilisateurs du cache, plus chacun d'entre eux aura de chance d'optimiser de la sorte ses connexions. Un cache de ce type est appelé un proxy.
Le plus connu et sans doute le plus utilisé des proxy est squid. Développé sous licence GPL par un grand nombre de personnes et dirigé par Duane Wessels, le projet squid est rapidement devenu un quasi standard en termes de proxy sous GNU/Linux. L'installation sur votre Debian ne posera pas de problème
root@egon:-# apt-get install squid
Reading Package Lists... Done
Building Dependency Tree... Done
The following NEW packages will be installed: squid
0 packages upgraded, 1 new1y installed, 0 ta remove and 46 flot upgraded.
Need to get 572kB of archives. After unpacking 3760kB will be used.
Get:1 http://ftp.fr.debian.org stable/main squid 2.2.5-3.2 [572kB]
Fetched 572kB in 7s (80.8kB/s)
Sélection du paquet squid précédemment déselectionné.
(Lecture de la base de données .. 30130 fichiers et répertoires déjà installés.)
Dépaquetage de squid (à partir de .../squid_ 2.2.5-3.2_i386 deb)
Paramétrage de squid (2.2.5-3.2) ...
Creating squid spool directory structure 2002/02/07 11:51:431 Creating Swap Directories Starting proxy server: squid.
La procédure d'installation lancera directement le démon/service squid. Vous pourrez à tout moment le stopper et le démarrer avec
# /etc/init.d/squid stop et
# /etc/init.d/squid start
Toute la configuration de squid repose sur un fichier    de    configuration    unique
/etc/squid.conf. . Celui installé par défaut sur la distribution Debian est largement commenté, mais nécessite tout de même quelques explications. squid est, en effet, un logiciel très puissant et largement personnalisable en fonction de vos besoins et des ressources réseau et système dont vous disposez.
En réalité, suite à l'installation, le serveur squid a effectivement démarré, mais le fichier de configuration par défaut, suivant les habitudes de la team Debian, n'autorise pas grand-chose, pour ne pas dire rien du tout. Si, sur le serveur où vous venez d'installer squid, vous configurez votre navigateur pour qu'il utilise le proxy sur le localhost et le port par défaut de squid (3128), comme montré en figure 1, vous vous retrouverez dans l'impossibilité
CID
d'accéder au Web (figure 2). Le serveur squid par défaut refusera de travailler pour vous et ne manquera pas de le signaler dans le journal d'activité de squid (/var/ log/squid/access . log) :
1013178172.171    0 127.0.0.1 TCP_DENIED/403 995
GET http://www.google.com/ - NONE/- -
Jetons un oeil au fichier de configuration. Les ligne non commentées sont les suivantes :
acl ail src 0.0.0.0/0.0.0.0
aci manager pro: cacheobject
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
acl Safe_ports port 80 21 443 563 70 210 1025- 65535
acl purge method PURGE
acl CONNECT method CONNECT
[...]
http_access allow manager localhost http_access deny manager
http_access allow purge localhost http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports [...]
http_access deny ail ]    ]
icp_access allow ail [...]
miss_access allow ail
La «méchante» ligne est la dernière en gras. Elle dit explicitement que l'accès HTTP (http_access) est interdit (deny) à tous (a 1. 1). Il est donc normal que vous ne puissiez pas utiliser le proxy squid. Si vous le désirez, mais uniquement à des fins de test, vous pouvez remplacer deny par allow pour obtenir l'effet strictement inverse, c'est-à-dire, autoriser tout le monde. Mettre la ligne en commentaire apportera le même effet. Ceci n'est pas un paramètre valable pour une configuration de production d'un proxy. Autoriser n'importe qui à utiliser votre serveur est dangereux et inconscient.
Le mot clef ail est défini plus haut dans le fichier de configuration. Il s'agit d'une ACL (Access Classes Lists). Une liste regroupe un ensemble de propriétés liées à un mot clef. Ici, ail est une sorte d'alias pour le masque IP 0.0.0.o/0.0.0.o, c'est- à-dire toutes les adresses possibles sur les 32 bits d'une IP. Un certain nombre d'ACL sont déjà définies dans le fichier de configuration. Il s'agit dustrict minimum pour les autorisations, elles aussi définies par défaut dans le fichier. Nous avons alors sept règles par défaut (dont une que nous venons de voir)
- http_access allow manager localhost
L'accès est autorisé pour un accès avec le protocole cache_object ET depuis le localhost unique- ment. Entendez bien qu'il s'agit d'un ET logique. 11 faut que les deux conditions soit remplies pour que l'autorisation soit accordée.
- http_access deny manager : on interdit le pro- tocole cache_object. Comprenez bien que cette règle n'empêche pas la précédente de s'appliquer. Si la connexion arrive du localhost l'accès sera auto- risé par la règle précédente. Cette ligne ne sera prise en compte que si la connexion vient d'ailleurs. Et dans ce cas nous ne l'autoriserons pas.
- http_access al low purge localhost : On
autorise la méthode PURGE si elle provient du
localhost.
- http_access deny purge : Encore une fois, la méthode PURGE est interdite si elle vient de n'impor- te où.
- http_access deny ISafe_ports : Nous interdi-
sons l'accès SAUF (grâce au «!») sur les ports que l'on considère comme sûrs (80 HTTP, 21 FTP, 443 HTTPS, 563 NTTPS, 70 GOPHER, 210 z3950 et de 1025 à 65535).
- http_access deny CONNECT ! SSL_ports : Nous
interdisons l'accès si la méthode CONNECT est utili- sée et qu'elle ne vient pas d'un port utilisé par un protocole over-SSL (HTTPS ou NTTPS).
Les autorisations, ou règles, sont lues en séquence. Une seule règle est choisie au final ; il y a donc une relation OU entre ces règles. Les lignes de règles sont parcourues jusqu'à ce que l'une d'elles corresponde. Si aucune règle ne correspond, l'action opposée à celle décrite par la dernière règle sera appliquée.
Ces sept règles sont, de base. placées dans le fichier de configuration par défaut. La septième devra être personnalisée et modifiée, mais ne la supprimez pas ! Voici tout d'abord un exemple de configura- tion personnalisée simple. Nous avons déjà une ACL représentant le localhost, celle-ci porte
d'ailleurs le même nom
acl localhost src 127.0.0.1/255.255.255.255
Il nous est donc très simple d'autoriser le local- host à utiliser le proxy squid en ajoutant
http_access allow localhost http_access deny ail
Cette règle est simple et ne devrait pas nécessiter d'explication supplémentaire. Mais n'oubliez pas que les règles sont parcourues dans leur ordre d'ap- parition dans le fichier de configuration. Ces deux lignes ne sont donc pas équivalentes à
http_access deny ail http_access allow localhost
C'est une chose très importante car ici, la première règle applicable est celle qui interdit l'utilisation du proxy. Vous ne pourrez donc pas l'utiliser sur le localhost. Après toute modification du fichier de configuration, il vous sera nécessaire de relancer le service squid avec
# /etc/init.d/squid restart Restarting proxy server: squid.
C'est parfait, le navigateur lancé sur le même hôte que celui où réside le démon squid peut librement utiliser le proxy. Trois fichiers journaux nous per- mettent de suivre les accès, le plus important étant
/var/log/squid/access . log, qui archive les
accès au proxy. Imaginons, à présent. que nous ayons sur notre LAN une machine nommée morga- ne ayant pour IP 192.168.0.10. Nous souhaitons que l'utilisateur de cette machine puisse bénéficier du proxy squid. Nous commençons alors par ajou- ter une ACL :
acl morgane src 192.168.0.10/255.255.255.255
L'ACL morgane (mais vous auriez pu la nommer comme bon vous semble) référence un accès prove- nant de l'adresse 192.168.0.10. Il ne nous reste plus, ensuite, qu'à écrire une nouvelle ligne de règle AVANT http_access deny ail, bien sûr :
http_access allow morgane
Il ne nous reste plus qu'à redémarrer squid et à

configurer le navigateur sur morgane de manière à ce qu'il utilise comme proxy HTTP notre machine sur le port 3128. Ici, nous venons d'autoriser une seule machine à utiliser notre proxy. Dans la plu- part des cas, on autorisera tout un LAN à le faire. Cela n'est pas plus complexe puisque nous pouvons utiliser un masque pour spécifier une plage d'adresses concernée dans une ACL :
acl monlan src 192.168.0.0/255.255.255.0
Ce type de syntaxe est classique pour peu que l'on connaisse les réseaux IP. Ici, nous spécifions que le réseau concerné est 192 .168 . 0 .x.
Configuration avancée
Pour l'heure, nous avons vu comment utiliser squid de manière simple, de façon à mettre en œuvre rapi- dement un proxy pour notre LAN. Nous sommes implicitement parti du principe que les utilisateurs du LAN avait déjà accès à Internet via une passe- relle NAT iptables ou ipchains, ou encore un rou- teur NAT. Mais il faut également savoir qu'un proxy peut parfaitement remplacer une machine NAT, ou encore compléter une telle installation.
Ainsi, en forçant les utilisateurs du LAN à utiliser le proxy pour certaines connexions à Internet (cer- tains ports). nous pouvons très simplement contrô- ler l'accès aux sites Web avec nos règles squid. Imaginons que les utilisateurs doivent utiliser le ser- veur squid pour le Web (il suffit de ne pas faire de NAT sur le port 80 et les utilisateurs ne pourront plus se connecter directement au Web). Nous pou- vons alors interdire l'accès à certains sites en ajou- tant des ACL et des règles.
Ajoutons ceci dans notre fichier de configuration
acl niet dstdomain www.google.com
[    ]
http_access allow morgane !niet
[...1
http_access deny ail
Il faudra, bien sûr, supprimer la ligne http_access précédemment placée pour morgane. Nous ajou- tons une ACL faisant référence à une connexion à destination du moteur de recherche Google. Puis nous la réutilisons en ce qui concerne morgane en définissant que nous autorisons la connexion en provenance de morgane et à destination de n'impor-
te où sauf vers Google. Si l'utilisateur de la machi- ne en 192.168.0.10 essaie de contacter le moteur de recherche, cette règle ne sera pas vérifiée mais http_access deny ail oui. Il se verra donc refu- ser l'accès au site en question.
Nous pouvons ainsi contrôler complètement l'accès aux ressources disponibles sur Internet et ce, quel que soit le type de données accédées. Voici un autre exemple. Ici, nous allons considérer que les images au format JPEG sont formellement interdites pour la machine référencée par l'ACL morgane. Nous définissons donc une nouvelle ACL en utilisant, cette fois, une directive url_regex. Cette directive permet de spécifier une expression régulière/ration- nelle concernant le contenu d'une URL. Une URL est un Universal Ressource Locator. Une URL iden- tifie le nom et l'emplacement d'une ressource et le protocole à utiliser pour y accéder. La syntaxe d'une URL est la suivante : protocole: / /ser- veur/chemin/objet.
Ce qui nous donne, par exemple, pour le protocole HTTP : http..11wwwmonsite.comlindex.html. Il faut également savoir qu'un objet référencé dans un fichier HTML, et qui sera demandé par le naviga- teur, aura également une URL permettant de le localiser. En d'autres termes. une image dans une page HTML possède une URL qui sera utilisée par le navigateur pour la récupérer et l'afficher ensuite sur l'écran. Notre interdiction portant sur les images JPEG ne concerne donc pas uniquement les URL visibles dans le navigateur comme http://www.monsite.conilimage.jpg. Nous interdirons également les fichiers JPEG dans les pages HTML. Voici notre ACL que nous pourrons utiliser ensuite, tout comme nous l'avons fait pour interdire à mor- gane de visiter Google
acl jpeg url_regex jpg
Notre expression régulière n'a vraiment rien de complexe. Elle référencera n'importe quelle URL contenant la chaîne «jpg». Ceci s'appliquera donc, par exemple, aussi bien à http:11www.un- site.comlimage.jpg qu'à  h t tp://ivivw. unsitejpg.coml ou encore à http:11www.unsite.comljpglindex.html.
Il existe encore bien d'autres directives permettant de référencer presque n'importe quel élément d'une transaction
- src, nous l'avons vu, il s'agit de référencer l'adresse IP source d'une connexion.
- dst, idem pour une adresse de destination.
- srcdomain permet de référencer un domaine source.
-    dstdomain idem pour une destination (comme avec Google précédemment).
-    srcdom_regex toujours un domaine source, mais cette fois, le référencement est plus souple à l'aide d'une expression régulière.
-    dstdom regex idem pour une destination.
- urlpath_regex, tout comme url regex vu pré- cédemment, nous référençons une URL mais cette fois uniquement sur la partie concernant le chemin dans l'URL. Attention, l'expression régulière st sensible à la casse des caractères contrairement à url_regex.
- port référence un port IP.
- proto référence un protocole (HTTP, FTP, etc.).
-    method référence une méthode HTTP comme GET, POST, etc.
- browser référence un navigateur Web à l'aide d'une expression régulière.
- ident référence un nom d'utilisateur via ident.
- ident_regex idem mais avec une expression régu- lière.
- max_conn permet de référencer une limite de connexions provenant d'une seule adresse IP.
- reg_mime_type référence un type MIME deman- dé dans l'en-tête d'une requête.
-    arp n'est disponible que si votre version de squid a été compilée avec les options nécessaires. Cette directive permet de référencer l'adresse MAC d'une interface Ethernet.
- t ime permet des référencements de données tem- porelles.
Cette dernière directive est très intéressante sur plus d'un point. Référencer une information concernant
le temps vous permettra de gérer votre accès aux ressources d'Internet. Vous pourrez, avec la syntaxe de cette directive, établir des règles strictes d'utilisa- tion du proxy :
acl nom time [jour] [hl:ml-h2:m2]
jour est une lettre désignant un jour dans la semaine : s (Sunday) pour le dimanche
(Monday) pour le lundi
T (Tuesday) pour le mardi
w (Wednesday) pour le mercredi
H (Thursday) pour le jeudi
F (Friday) pour le vendredi
A (Saturday) pour le samedi
Le dernier paramètre de la ligne permet de spécifier une plage horaire où hi :mi doit impérativement être inférieur à h2 :m2. Voici quelques lignes en guise d'exemple
# référence une connexion le dimanche *peu importe l'heure
acl horairel S
# référence une connexion entre # 9h et 19h peu importe le jour acl horaire2 9:00-19:00
# référence une connexion le samedi # matin uniquement
acl horaire3 A 0:00-12:00
Transparence ?
Nous avons abordé le fait d'obliger les utilisateurs d'un LAN à employer notre serveur proxy précé demment. Il était question de leur refuser l'accès direct à Internet. Le problème dans cette méthode est que l'utilisateur ne configurant pas ou suppri- mant délibérément la configuration du proxy dans son navigateur constatera qu'il y a un problème. Il peut être souhaitable cependant pour un adminis- trateur d'obliger les utilisateurs d'un LAN à utiliser un proxy mais sans qu'ils s'en rendent jamais compte.
La mise en oeuvre de squid permet un filtrage du trafic plus aisé qu'avec ipchains (kernel 2.2 sur Potato) ou même NetFilterliptables (kernel 2.4 sur Woody). Le fichier de configuration de squid est en effet très facile d'emploi et permet toutes les configurations. Le but est donc de faire transiter tout le trafic HTTP vers le proxy mais cela directement, depuis les règles de filtrage. Dans ce cas, c'est la machine faisant le NAT qui fera également fonctionner le proxy. Ici, nous baserons notre exemple sur une Debian Woody. Nous partons. en effet, du principe que même si une Debian Potato est parfaitement adaptée pour la mise en place des services courants, le filtrage est bien plus efficace avec un kernel 2.4 (protection contre les boucles infinies par exemple).
Le principe est simple : il nous suffit de rediriger les connexions arrivant sur le port 80 vers le port utilisé par notre proxy (3128 par défaut pour squid). De ce fait, toutes les connexions passeront obligatoirement par le proxy et les utilisateurs n'auront rien à configurer et ne pourront pas se passer du proxy :
# iptables -t nat -A PREROUTING    eth0 -p
tcp -dport 80 -j REDIRECT -to-port 3128
Voici en détail le contenu de cette ligne : nous ajoutons une règle dans le préroutage (-A PREROUTING) de la table NAT (-t nat). Toutes les connexions à destination du port TCP 80 (-p tcp —dport 80) arrivant sur la première interface Ethernet (-i eth0), sont redirigées (-j REDIRECT) sur le port
3128 (—to-port 3128).
Interface Web
Un package squid-cgi peut être installé. Celui-ci permet de mettre en place une interface via le Web avec le serveur squid. Vous pourrez ainsi, depuis un navigateur accéder aux paramètres de configuration et surtout aux statistiques de charge du proxy. Sur Debian, installez tout d'abord le package avec apt-get :
root@egon:-# apt-get install squid-cgi Reading Package Lists... Done
Building Dependency Tree... Done
The following NEW packages will be installed: squid-cgi
0 packages upgraded, 1 newly installed, 0 to remove and 46 not upgraded.
Need to get 56.0kB of archives. After unpacking 152kB will be used.
Get:l http://ftp.fr.debian.org stable/main squid-cgi 2.2.5-3.2 [56.0kB]
Fetched 56.0kB in 1s (40.8kB/s)
Sélection du paquet squid-cgi précédemment déselectionné.
(Lecture de la base de données ... 30770 fichiers
et répertoires déjà installés.)
Dépaquetage de squid-cgi (à partir de .../squidcgi_2.2.5-3.2_i386.deb)
Paramétrage de squid-cgi (2.2.5-3.2) ...
squid-cgi:    IMPORTANT: Read the documentation in
squid-cgi:    /usr/share/doc/
squid-cgi/README.cachemgr.gz
Le script CGI sera automatiquement installé dans
/usr/lib/cgi-bin/ sous le nom cachemgr.cgi.
Ce CGI ne sera pas directement utilisable puisqu'il
devra être appelé avec les bons paramètres depuis
un formulaire HTML. Vous trouverez dans le
répertoire /usr/doc/squid-cgi/examples une
page HTML contenant ceci :
<HTML><HEAD><TITLE>Cache Manager Interface</TITLE></HEAD>
<BODY><H1>Cache Manager Interface</H1>
<P>This is a WWW interface to the instrumentation interface
for the Squid object cache.</P>
<HR>
<FORM METHOD="GET" ACTION="/cgi-bin/cachemgr.cgin> <TABLE BORDER=0>
<TR>
<TH ALIGN="left">Cache Host:</TH>
<TD><INPUT NAME="host" SIZE=30 VALUE." localhost"></TD>
</TR>
<TR>
<TH ALIGN="left">Cache Port:</TH>
<TD><INPUT NAME="port" SIZE=30 VALUE="3128"></TD>
</TR>
<TR>
<TH ALIGN="left">Manager name:</TH>
<TD><INPUT NAME="user_name" SIZE=30 VALUE=""></TD>
</TR>
<TR>
<TH ALIGN=»left»>Password:</TH>
<TD><INPUT TYPE="password" NAME="passwd" SIZE=30 VALUE=""></TD>
</TR>
</TABLE><BR CLEAR="all"›
<INPUT TYPE="submit" VALUE="Continue...">
</FORM>
<HR> </BODY></HTML>
Il vous suffira d'intégrer ce code HTML quelque part dans votre site pour ouvrir un accès vers le CGI de squid ou plus simplement, de copier le fichier cachemgr . html sur votre serveur FITTP. Attention ! Le plus grand nombre de précautions sont à prendre avec ce type d'interface. Bien que vous puissiez mettre en place une authentification pour accéder au script CGI de squid, mieux faut copier ce fichier dans un répertoire à part. Vous pourrez ensuite y ajouter un fichier . htacces permet- tant de restreindre encore un peu plus l'accès.
Le fichier .htaccess pourrait, par exemple, ne limiter l'accès qu'à une seule machine
order deny,allow
deny from ail
allow from 193.252.124.15
Une autre solution, si vous être plusieurs à adminis- trer le serveur ou si vous êtes susceptible de vous connecter depuis plusieurs endroits, est de mettre en place une authentification par mot de passe :
AuthUserFile /etc/squid.pass AuthName "User/Password Required" AuthType Basic
require user cachemanager
Ici, les mots de passe seront stockés dans / et c / squ id . pas s à l'aide de htpasswd et seul l'uti- lisateur cachemanager pourra accéder au répertoi- re, s'il fournit le mot de passe correspondant. Une autre solution consiste à protéger le script CGI directement en modifiant le fichier de configuration d'Apache et en ajoutant au choix :
<Location /usr/lib/cgi-bin/cachemgr.cgi>
order deny,allow
deny from ail
allow from 193.252.124.15
</Location>
Ou
<Location /usr/local/cgi-bin/cachemgr.cgi> AuthUserFile /etc/squid.pass
AuthGroupFile /dev/null
AuthName User/Password Required
AuthType Basic
<Limit GET>
require user cachemanager
</Location>
selon le type de restriction que vous souhaitez.
Une fois cela en place, éditez à nouveau votre fichier de configuration squid pour sécuriser le CGI. Vous trouverez en commentaire dans le fichier exemple une directive cachemgr_passwd. Celle-ci
permet de définir un mot de passe pour chaque fonctionnalité de configuration parmi 5min, 60min, asndb, authenticator, cbdata, client_list, comm incoming, config, counters, delay, digest_stats, dns, events, filedescriptors, fqdncache, histograms, http_headers, info, io, ipcache, mem, menu, netdb, non_peers, objects, pconn, peer_select, redirector, refresh, ser- ver_list, shutdown *, store digest, storedir, utilization, via headers ou encore vm_obj ects.
Chacune de ces fonctionnalités correspond à un élé- ment de l'interface de configuration. De plus, le al l permet de désigner l'ensemble des fonctionnalités. Ainsi, pour définir le mot de passe motdepasse pour toutes ces fonctionnalités, vous ajouterez dans le fichier de configuration
cachemgr_passwd motdepasse ail
Si vous êtes suffisamment sûr de la limitation d'ac- cès définie au niveau du serveur HTTP. vous pou- vez également spécifier qu'aucun mot de passe n'est nécessaire
cachemgr_passwd none ail
Vous pourrez ensuite faire pointer votre navigateur sur la page où est placé le formulaire (figure 3) et vous identifier. Vous arriverez sur l'interface de ges- tion et de statistique de squid (figure 4). Chaque ligne du menu correspond à une fonctionnalité uti- lisable avec cachemgr_passwd. Vous y trouverez, par exemple. les statistiques d'utilisation de la mémoire (figure 5), les statistiques d'utilisation du cache (figure 6), ou les informations sur l'utilisation du répertoire de stockage du cache (figure 7).
Cette interface Web ne peut pas, bien sûr, remplacer l'édition du fichier de configuration mais vous apportera des informations très importantes sur la charge du serveur squid. Vous pourrez alors optimi- ser votre configuration de manière à l'adapter à vos besoins. Nous n'avons pas couvert ici, toutes les fonctionnalités de squid, loin de là. Les utilisateurs soucieux de tirer le meilleur de ce logiciel sont invi- tés à consulter la documentation en ligne et la FAQ sur le serveur officiel du projet. Le fichier de confi- guration par défaut vous apprendra également bon nombre de choses concernant la configuration avancée.