<!-- Do *not* edit this file; it was automatically generated by ej2html
Look for a name.ej file with the same name as this filename -->
<!-- Last updated Fri Nov 15 21:19:42 2002 -->
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=utf-8">
</HEAD><BODY >
<h1>NOM</h1>
mararc - Format du fichier de configuration mararc utilisé par MaraDNS
<h1>FORMAT DU FICHIER MARARC</h1>
Le fichier mararc utilise une syntaxe constituant un sous-ensemble de la
syntaxe Python 1.5.2. En particulier, Python 1.5.2 (et peut-être
d'autres versions de Python) peut relire un fichier mararc correctement
rédigé sans erreur.
<p>
À la différence de Python, toutefois, un fichier mararc ne peut utiliser
que certains noms de variables, et ces variables doivent être définies
comme suit.
<p>
<h1>COMMENTAIRES</h1>
Les commentaires (lignes ignorées par le parser MaraDNS) commencent par
le caractère '#', comme ceci:
<pre>
# Ceci est un commentaire
</pre>
Le parser MaraDNS ignore également les lignes uniquement composées
d'espace blanc.
<h1>VARIABLES MARARC</h1>
Suit la liste des variables pouvant être déclarées dans le fichier
mararc.
<h1>FORMAT DE VARIABLES DICTIONNAIRE</h1>
Une <b>variable dictionnaire</b>
est un tableau pouvant comporter plusieurs éléments indexés par des
chaînes au lieu de nombres. Ceci est analogue aux tableaux associatifs,
que Perl dénomme hachage.
<p>
La syntaxe d'une variable dictionnaire est la suivante :
<pre>
nom["index"] = "valeur"
</pre>
Où
<b>nom</b>
est le nom de la variable dictionnaire,
<b>index</b>
est l'index du tableau, et
<b>valeur</b>
la valeur stockée à cet index.
<p>
Chaque fois qu'une variable dictionnaire (comme csv1) est utilisée, il
est nécessaire de l'initialiser auparavant de la manière suivante :
<pre>
csv1 = {}
</pre>
Ici, csv1 est le nom de la variable dictionnaire utilisée.
<h1>VARIABLES DICTIONNAIRES</h1>
Voici une liste des variables-dictionnaires qu'utilise MaraDNS:
<h2>csv1</h2>
csv1: Associe un nom de fichier de zone à une zone donnée
<pre>
csv1["zone"] = "fichier"
</pre>
<b>csv1</b>:
Fichier au format csv1. Voir la page de manuel
<b>csv1(5)</b>
pour une description de ce format.
<b>zone</b>:
zone pour laquelle le serveur est autoritaire.
<p>
<b>fichier</b>:
fichier contenant les données de la zone au format csv1.
<p>
Notez que les fichiers csv1 sont lus après que MaraDNS ait changé sa
racine, et, de ce fait, le nom du fichier est relatif à chroot_dir.
<h2>ipv4_alias</h2>
ipv4_alias: utilisé pour donner des noms courts à des groupes de paires
IP/masque d'adresses IPv4 (standard 32 bits)
<pre>
ipv4_alias["nom"] = "ip1/masque1,ip2/masque,etc"
</pre>
<b>nom</b>:
Nom de l'alias en question
<p>
<b>ip</b>:
Adresse IP dans la paire IP/masque
<p>
<b>masque</b>:
Masque de réseau de la paire IP/masque
<p>
<b>,</b>:
Utilisé pour séparer les paires IP/masque. Ne pas séparer avec des
espaces avant ou après.
<p>
Une adresse IP est au format décimal pointé, par exemple 10.1.2.3.
<p>
Le masque peut-être noté de deux manières différents : un simple nombre
entre 1 et 32, qui indique le nombre de bits forts "1" du masque, ou une
adresse en décimal pointé.
<p>
Le masque est utilisé pour désigner une classe d'adresses IP.
<h2>"exemples ipv4_alias"</h2>
<b>10.1.1.1/24</b> désigne toute adresse entre 10.1.1.0 et 10.1.1.255.
<p>
<b>10.1.1.1/255.255.255.0</b> est identique à 10.1.1.1/24.
<p>
<b>10.2.3.4/16</b> désigne toute adresse entre 10.2.0.0 et 10.2.255.255.
<p>
<b>10.2.3.4/255.255.0.0</b> est identique à 10.2.3.4/16.
<p>
<b>127.0.0.0/8</b> désigne toute adresse avec 127 comme premier octet.
<p>
<b>127.0.0.0/255.0.0.0</b> est identique à 127.0.0.0/8.
<p>
Le masque est optionnel et, si absent, indique que seule une adresse
doit faire partie de l'alias, par exemple :
<p>
<b>10.9.9.9/32</b>, <b>10.9.9.9/255.255.255.255</b>, et <b>10.9.9.9</b>
fonctionnent de manière identique, seule l'adresse 10.9.9.9 est
concernée.
<p>
Les alias sont imbricables. Par exemple :
<pre>
ipv4_alias["susan"] = "10.6.7.8/24"
ipv4_alias["office"] = "susan,10.9.9.9"
</pre>
Ainsi, "susan" dans "office" désigne l'alias "susan".
<p>
Il est possible d'imbriquer plusieurs alias. Toutefois, un alias
pointant vers lui-même génèrera une erreur.
<p>
<h2>root_servers</h2>
root_servers: il s'agit d'une variable dictionnaire particulière
désignant (pour l'instant) seulement un unique élément ".", qui désigne
ou une adresse IP, ou un alias d'adresses désignant le ou les serveurs
racine.
<pre>
root_servers["."] = "liste_de_serveurs"
</pre>
"." est la seule référence utilisable pour désigner les serveurs racine
(ce format est utilisé pour une possible extension future), et
liste_de_serveurs est une liste de serveurs de noms racine du même
format que ipv4_aliases.
<p>
Notez que, bien que les IP de la liste des serveurs de noms racine
peuvent comporter des masques, ceux-ci sont ignorés.
<p>
<h2>"Note finale sur les variables-dictionnaire"</h2>
csv1, ipv4_alias, et root_servers sont pour l'instant les seuls
variables-dictionnaire.
<h1>FORMAT STANDARD DE VARIABLE</h1>
Variables standard. Il s'agit de variables ne prenant qu'une seule
valeur.
<p>
La syntaxe d'une variable standard est de la forme :
<pre>
nom = "valeur"
</pre>
Où <b>nom</b> est le nom de cette variable, et <b>value</b> sa valeur.
<h1>VARIABLES NORMALES</h1>
Voici une liste des variables normales utilisées par le fichier mararc :
<h2>bind_address</h2>
bind_address: adresse IP à donner au serveur MaraDNS
<p>
La valeur à donner est une simple adresse IP en notation décimale
pointée (par ex.: "127.0.0.1"), qui spécifie l'adresse IP sur laquelle
le serveur MaraDNS écoutera. Pour faire écouter MaraDNS sur toutes les
adresses IP d'un serveur donné, utiliser la valeur "0.0.0.0".
<p>
<h2>chroot_dir</h2>
chroot_dir: le répertoire dans lequel MaraDNS se chroote.
<p>
La valeur est le chemin absolu à utiliser comme prison de chroot.
Notez que les fichiers de zone csv1 sont lus après cette opération de
chroot. Ainsi, tous les fichiers de zone à charger doivent être
contenus dans cette prison.
<p>
<h2>maradns_uid</h2>
maradns_uid: L'UID numérique de fonctionnement de MaraDNS
<p>
La valeur est un unique nombre : l'identifiant utilisateur sous lequel
faire fonctionner MaraDNS.
<p>
MaraDNS abandonne ses privilèges root dès que possible, minimisant les
dommages potentiels qu'un attaquant pourrait faire subir au système, un
problème de sécurité survenant dans MaraDNS. Ceci est l'UID à utiliser
une fois les privilèges abandonnés.
<p>
<h2>maradns_gid</h2>
maradns_gid: Argument optionnel, GID de fonctionnement de MaraDNS.
<p>
La valeur est un unique nombre : l'identifiant du groupe sous lequel
faire fonctionner MaraDNS.
<p>
Cet argument optionnel donne les privilèges de groupe que MaraDNS doit
utiliser à l'abandon des privilèges.
<p>
<h2>maxprocs</h2>
maxprocs: Nombre maximal de threads ou processus que MaraDNS est
autorisé à lancer à un instant donné.
<p>
Cette variable est utilisée pour minimiser l'impact sur les ressources
du serveur lorsque MaraDNS est hautement sollicité. Lorsque ce nombre
est atteint, il est impossible à MaraDNS de lancer de nouveaux
threads/processus jusqu'à ce que ce nombre diminue.
<p>
<h2>max_tcp_procs</h2>
Parfois il est souhaitable d'avoir un nombre maximum de processus et de
processus du serveur de zones différent. Si cette variable n'est pas
positionnée, le nombre maximum de processus TCP est "maxprocs".
<p>
<h2>no_fingerprint</h2>
no_fingerprint: Drapeau rendant MaraDNS plus difficile à détecter.
<p>
Certaines personnes pensent qu'il est plus approprié que certaines
informations, tel le numéro de version de MaraDNS, ne soit pas public.
<p>
La valeur normale est 0.
<p>
En positionnant no_fingerprint à 1, cette information n'est plus
disponible publiquement.
<p>
<h2>default_rrany_set</h2>
defult_rrany_set: nombre définissant les RRs à retourner si le type de
requête envoyée à MaraDNS est ANY.
<p>
Certains registrars exigent qu'une requête ANY retourne les
enregistrements NS et parfois le SOA également.
<p>
Lorsque default_rrany_set est positionné à 3 (la valeur par défaut), la
réponse à une requête ANY retourne seulement les enregistrements A et MX.
<p>
Lorsque default_rrany_set est positionné à 15, la réponse à une requête
ANY retourne les enregistrements A, MX, NS, et SOA.
<p>
<h2>max_chain</h2>
max_chain: nombre maximal d'enregistrements à renvoyer dans une chaîne
d'enregistrements.
<p>
Avec DNS, il est possible d'avoir plus d'un RR d'un nom DNS donné dans
une même zone. Par exemple, "example.com" peut avoir, comme
enregistrements A, plusieurs adresses IP différentes.
<p>
Ceci positionne le nombre maximum d'enregistrements à retourner pour un
RR donné.
<p>
MaraDNS fait normalement tourner par "round-robin" les enregistrements
d'un nom DNS avec plusieurs RRs donné. Ainsi, tous les enregistrements
disponibles seront visibles, mais pas simultanément, si il y a plus
d'enregistrements que max_chain.
<p>
<h2>max_ar_chain</h2>
max_ar_chain: nombre maximal d'enregistrements à retourner si la section
additionnelle (par ex. l'adresse IP d'un serveur DNS ou l'adresse IP
d'un MX) possède plus d'une valeur.
<p>
Ceci est similaire à max_chain, mais ne s'applique qu'aux
enregistrements de la section additionnelle (AR).
<p>
En raison de limitations dans la structure interne des données que
MaraDNS utilisent pour stocker les RRs, si ce nombre est inférieur au
nombre d'enregistrements du RR, le "round-robin" est désactivé.
<p>
<h2>max_total</h2>
max_total: nombre maximal d'enregistrements à montrer en tout pour une
requête DNS donnée.
<h2>verbose_level</h2>
verbose_level: nombre de messages à journaliser sur la sortie standard
<p>
Ceci peut prendre quatre valeurs:
<p>
0: pas de messages excepté le démenti légal et les erreurs fatales
survenues à l'interprétation du fichier de configuration au démarrage
<p>
1: Seulement les messages de démarrage (niveau par défaut)
<p>
2: Requêtes erronées journalisées
<p>
3: Toutes les requêtes journalisées
<h2>zone_transfer_acl</h2>
zone_transfer_acl: liste d'adresses IP autorisées à pratiquer des
transferts de zone sur le serveur de zones
<p>
Le format de cette variable est identique au format d'une entrée ipv4_alias.
<h2>recursive_acl</h2>
recursive_acl: liste d'adresses autorisées à pratiquer des requêtes
récursives sur le serveur MaraDNS
<p>
Le format de cette variable est identique au format d'une entrée ipv4_alias.
<h2>random_seed_file</h2>
randsom_seed_file: emplacement du fichier depuis lequel 16 octets sont
lus afin d'obtenir la graine de 128 bits nécessaire au fonctionnement du
générateur de nombres pseudo-aléatoires.
<p>
Idéalement ce fichier est une bonne source d'entropie (par ex.
/dev/urandom), mais peut également être un fichier fixe si votre système
d'exploitation ne dispose pas d'une telle source d'entropie. Dans ce
cas, veillez à ce que le contenu de ce fichier soit aléatoire et de
permissions 600, avec root comme propriéraire. Ce fichier est lu *avant*
d'abondonner les privilèges root.
<h2>maximum_cache_elements</h2>
maximum_cache_elements: nombre maximum d'éléments à conserver dans le
cache des requêtes récursives.
<p>
Ce cache de requêtes récursives est utilisé pour conserver des réponses
à des requêtes récursives déjà effectuées.
<p>
Si l'on approche cette limite, le "videur" entre en action. Il retire
des éléments aléatoires du cache\(em(8 éléments retirés par
requête\(emjusqu'à atteindre 99% d'occupation environ.
<h2>spammers</h2>
spammers: une liste de serveurs DNS que le resolver récursif
n'interrogera pas.
<p>
Ceci est là essentiellement pour ne pas autoriser les domaines
de spammers à résoudre, puisque les spammers utilisent fréquemment des
serveurs DNS mal configurés de FAI afin de résoudre leurs domaines, leur
permettant ainsi de passer de FAI en FAI.
<p>
Le format de cette variable est identique au format d'une entrée ipv4_alias.
<h2>max_glueless_level</h2>
Maximum glueless level allowed when performing recursive lookups. The
default value is 10.
<p>
Niveau "glueless" maximum autorisé lors de requêtes récursives. Le
niveau par défaut est 10.
<p>
Ceci est le nombre maximal de fois autorisées où MaraDNS doit "retourner
aux root servers" pour trouver l'adresse IP d'un serveur de noms pour
lequel l'adresse IP n'est pas disponible immédiatement, ou pour trouver
l'enregistrement A associé à un CNAME.
<h2>max_queries_total</h2>
Ceci est le nombre maximal de requêtes à réaliser lors d'une requête
récursive. Le nombre par défaut est 32.
<p>
Ceci est le nombre maximal de fois où MaraDNS peut envoyer une requête
à des serveurs DNS pour trouver la réponse à sa question initiale.
<h2>timeout_seconds</h2>
Ceci ne s'applique qu'aux requêtes récursives.
<p>
Le temps maximum à attendre, en secondes, la réponse à la requête vers
un serveur DNS distant avant d'essayer le serveur DNS suivant disponible
sur la liste. La valeur par défaut est de 2 secondes.
Notez que, plus élevée est la valeur, plus lent MaraDNS sera à pratiquer
les requêtes récursives lorsque le serveur DNS ne répond pas aux
requêtes.
<h2>hide_disclaimer</h2>
Si cette variable est positionnée à "YES", MaraDNS n'affichera pas le
démenti légal au démarrage.
<h1>FICHIER MARARC D'EXEMPLE</h1>
<pre>
# Example mararc file
# The various zones we support
# First, we must initialize the csv1 hash, or things will fail with a
# (potentially) obscure error message
csv1 = {}
# This is just to show the format of the file
csv1["example.com."] = "db.example.com"
# The address this DNS server runs on. If you want to bind
# to all addresses a given machine has, use "0.0.0.0".
bind_address = "127.0.0.1"
# The directory with all of the zone files
chroot_dir = "/etc/maradns"
# The numeric UID MaraDNS will run as
maradns_uid = 99
# The maximum number of processes MaraDNS is allowed to use
maxprocs = 64
# The number of messages we log to stdout
# 0: No messages, except syntax error messages
# 1: Only startup messages logged (Default)
# 2: Error queries logged
# 3: All queries logged (not very verbosely right now)
verbose_level = 1
# Normally, MaraDNS has some MaraDNS-specific features, such as DDIP
# synthesizing, a special DNS query (erre-con-erre-cigarro.maradns.org.
# with a TXT query returns the version of MaraDNS that a server is
# running), unique handling of multiple QDCOUNTs, etc. Some people
# might not like these features, so I have added a switch that lets
# a sys admin disable all these features. Just give "no_fingerprint"
# a value of one here, and MaraDNS should be more or less
# indistinguishable from a tinydns server.
no_fingerprint = 0
# Normally, MaraDNS only returns A and MX records when given a
# QTYPE=* (all RR types) query. Changing the value of default_rrany_set
# to 15 causes MaraDNS to also return the MX and SOA records, which
# some registars require. The default value of this is 3
default_rrany_set = 3
# These constants limit the number of records we will display, in order
# to help keep packets 512 bytes or smaller. This, combined with
# round_robin record rotation, help to use DNS as a crude load-balancer.
# The maximum number of records to display in a chain of records (list
# of records) for a given host name
max_chain = 8
# The maximum number of records to display in a list of records in the
# additional section of a query. If this is any value besides one,
# round robin rotation is disabled (due to limitations in the current
# data structure MaraDNS uses)
max_ar_chain = 1
# The maximum number of records to show total for a given question
max_total = 20
# Initialize the IP aliases, which are used by the list of root
# name servers, the ACL for zone transfers, and the ACL of who
# gets to perform recursive queries
ipv4_alias = {}
# Various sets of root name servers
# Note: Netmasks can exist, but are ignored when specifying root
# name server
# ICANN, the most common and most controversial root name server
ipv4_alias["icann"] = "198.41.0.4,128.9.0.107,192.33.4.12,128.8.10.90,192.203.230.10,192.5.5.241,192.112.36.4,128.63.2.53,192.36.148.17,198.41.0.10,193.0.14.129,198.32.64.12,202.12.27.33"
# OSRC: http://www.open-rsc.org/
ipv4_alias["osrc"] = "199.166.24.1,205.189.73.102,199.166.24.3,204.80.125.130,207.126.103.16,195.117.6.10,199.166.31.3,199.166.31.250,199.5.157.128,205.189.73.10,204.57.55.100,213.196.2.97"
# AlterNIC: http://www.alternic.org/
ipv4_alias["alternic"] = "160.79.129.192,65.2.214.15,160.79.133.70,24.13.64.102,216.99.37.240,199.224.64.190,160.79.133.66,216.99.37.246,216.99.37.247"
# OpenNIC: http://www.opennic.unrated.net/
ipv4_alias["opennic"] = "209.21.75.51,216.74.72.7,216.74.72.8,209.21.75.53,209.104.33.250,209.104.63.249"
# Pacific Root: http://www.pacificroot.com/
ipv4_alias["pacificroot"] = "204.107.129.2,208.179.42.162,12.28.140.20,204.107.129.10,212.115.192.151,202.76.159.5,209.54.94.3,167.160.132.2"
# IRSC: http://www.irsc.ah.net/
ipv4_alias["irsc"] = "203.21.205.2,203.21.205.3,212.234.36.20,212.234.36.19,207.180.91.9,198.199.168.92,207.180.91.10"
# TINC: http://www.tinc-org.com/
ipv4_alias["tinc"] = "64.6.65.10,208.128.113.35,212.172.21.254,207.112.147.14,145.89.234.7,209.133.38.16"
# Super Root: http://www.superroot.org/
ipv4_alias["superroot"] = "195.117.6.10,199.166.31.3,199.5.157.128,205.189.73.10,199.166.31.250,199.166.24.1,205.189.73.102,199.166.24.3,204.80.125.130,207.126.103.16,204.57.55.100"
# Here is the ACL which restricts who is allowed to perform
# zone transfer from the zoneserver program
# VERY IMPORTANT: Do not put spaces in the zone_transfer_acl list
# Good: zone_transfer_acl = "office,home"
# Bad: zone_transfer_acl = "office, home"
# Simplest form: 10.1.1.1/24 (IP: 10.1.1.1, 24 left bits
# in IP need to match) and 10.100.100.100/255.255.255.224
# (IP: 10.100.100.100, netmask 255.255.255.224) are allowed
# to connect to the zone server
# zone_transfer_acl = "10.1.1.1/24,10.100.100.100/255.255.255.224"
# More complex: We create two aliases: One called "office"
# and another called "home". We allow anyone in the office or
# at home to perform zone transfers
# ipv4_alias["office"] = "10.1.1.1/24"
# ipv4_alias["home"] = "10.100.100.100/255.255.255.224"
# zone_transfer_acl = "office,home"
# More complex then the last example. We have three employees,
# Susan, Becca, and Mia, whose computers we give zone transfer
# rights to. Susan and Becca are system administrators, and
# Mia is a developer. They are all part of the company. We
# give the entire company zone transfer access
# ipv4_alias["susan"] = "10.6.7.8/32" # Single IP allowed
# ipv4_alias["becca"] = "10.7.8.9" # also a single IP
# ipv4_alias["mia"] = "10.8.9.10/255.255.255.255" # 1 IP
# ipv4_alias["sysadmins"] = "susan,becca"
# ipv4_alias["devel"] = "mia"
# ipv4_alias["company"] = "sysadmins,devel"
# This is equivalent to the above line
# ipv4_alias["company"] = "susan,becca,mia"
# zone_transfer_acl = "company"
# Recursive ACL: Who is allowd to perform recursive queries.
# The format is identical to that of "zone_transfer_acl",
# including ipv4_alias support
# ipv4_alias["localhost"] = "127.0.0.0/8"
# recursive_acl = "localhost"
# Random seed file: The file form which we read 16 bytes from
# to get the 128-bit random Rijndael key. This is ideally a
# file which is a good source of random runbers, but can also be
# a fixed file if your OS does not have a decent random number
# generator (make sure the contents of that file is random and
# with 600 perms, owned by root, since we read the file *before*
# dropping root privledges)
# random_seed_file = "/dev/urandom"
# The maximum number of elements we can have in the cache. If
# we have more elements in the cache than this amount, the
# "custodian" kicks in to effect, removing elements at random from
# the cache (8 elements removed per query) until we are at the 99%
# level or so again.
# maximum_cache_elements = 1024
# The root servers which we use when making recursive queries.
# The following line must be uncommented to enable recursive queries
# root_servers = {}
# You can choose which set of root servers to use. Current
# values (set above) are: icann, osrc, alternic, opennic,
# pacificroot, irsc, tinc, and superroot.
# root_servers["."] = "osrc"
# You can tell MaraDNS to *not* query certain DNS servers when in
# recursive mode. This is mainly used to not allow spam-friendly
# domains to resolve, since spammers are starting to get in the habit
# of using spam-friendly DNS servers to resolve their domains, allowing
# them to hop from ISP to ISP. The format of this is the same as for
# zone_transfer_acl and recursive_acl
# As of August 12, 2001, azmalink.net is a known spam-friendly DNS
# provider (see doc/en/misc/spammers/azmalink.net for details).
# Note that this is based on IPs, and azmalink.net constantly
# changes IPs (as they constantly have to change ISPs)
# Updated 2002/10/12 to reflect their current ISP
ipv4_alias["azmalink"] = "12.164.194.0/24"
# As of September 20, 2001, hiddenonline.net is a known spam-friendly
# DNS provider (see doc/en/misc/spammers/hiddenonline for details).
ipv4_alias["hiddenonline"] = "65.107.225.0/24"
spammers = "azmalink,hiddenonline"
</pre>
<h1>BOGUES</h1>
Si l'on venait à déclarer deux fois un index dans une variable
dictionnaire, MaraDNS se terminerait en erreur fatale. Ceci est dû au
fait que des versions précédentes de MaraDNS ne réagissait pas comme
Python 1.5.2. Avec Python 1.5.2., la dernière déclaration est utilisée,
alors que MaraDNS utilisait la première.
<h1>LEGAL DISCLAIMER</h1>
THIS SOFTWARE IS PROVIDED BY THE AUTHORS ''AS IS'' AND ANY EXPRESS
OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
<h1>AUTEUR</h1>
Sam Trenholme <br>
http://www.samiam.org/
<h1>TRADUCTEUR</h1>
Traduit en français par Thomas Seyrat <thomas@glou.net>
</BODY></HTML>
