/usr/share/doc/HOWTO/fr-html/Proxy-ARP-Subnet.html is in doc-linux-fr-html 2013.01-2.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for Linux/x86 (vers 25 March 2009), see www.w3.org">
<meta name="GENERATOR" content="LinuxDoc-Tools 0.9.69">
<title>ProxyARP Subnetting HOWTO</title>
</head>
<body>
<h1>ProxyARP Subnetting HOWTO</h1>
<h2>Bob Edwards,
<<code>Robert.Edwards@anu.edu.au</code>></h2>
Août 1997
<hr>
<em>Ce HOWTO explique l'utilisation d'un sous-réseau avec
mandataire (</em>proxy) ARP (protocole de résolution
d'adresse), pour rendre visible un petit réseau de machines
comme si ces machines étaient reliées directement au
réseau principal. (traduction : Michel Billaud,
<<code>billaud@labri.u-bordeaux.fr</code>>).
<hr>
<h2><a name="s1">1. Introduction</a></h2>
<p>Ce HOWTO explique l'utilisation d'un sous-réseau avec
mandataire (<em>proxy</em>) ARP (protocole de résolution
d'adresse), pour rendre visible un petit réseau de machines
(nous l'appellerons <em>réseau 0</em> dans la suite) comme
si ces machines étaient reliées directement au
réseau principal (<em>réseau 1</em>).</p>
<p>Ceci n'a de sens que si les machines sont reliées par
Ethernet ou autres dispositifs de type <em>ether</em> (autrement
dit ça ne convient pas pour SLIP, PPP, CSLIP, etc.)</p>
<h2><a name="s2">2. Remerciements</a></h2>
<p>Ni ce document, ni mon implémentation du mandatement ARP,
n'auraient été possibles sans l'aide :</p>
<ul>
<li>d'Andrew Tridgell, qui a implémenté sous Linux
les options de sous-réseau pour <em>arp</em>, et qui m'a
aidé personnellement à le faire marcher ;</li>
<li>du mini-HOWTO <em>Proxy-ARP</em> écrit par Al LongYear
;</li>
<li>du mini-HOWTO <em>Multiple-Ethernet</em> de Don Becker ;</li>
<li>du code source et de la page de manuel de la commande
<code>arp(8)</code>, de Fred N. van Kempen et Bernd Eckenfels.</li>
</ul>
<h2><a name="s3">3. Pourquoi utiliser un sous-réseau avec
mandataire ARP ?</a></h2>
<p>Les applications d'un sous-réseau avec mandataire ARP
sont assez spécifiques.</p>
<p>Dans mon cas, j'avais une carte Ethernet sans-fil ISA 8 bits. Je
voulais utiliser cette carte pour raccorder un certain nombre de
machines. Après avoir écrit un pilote
(<em>driver</em>) pour cette carte ISA (c'est le sujet d'un autre
document), je pouvais l'utiliser dans une machine Linux. À
partir de là, il était seulement nécessaire
d'ajouter une seconde interface Ethernet à la machine Linux,
et d'utiliser alors un mécanisme quelconque pour
interconnecter les deux réseaux.</p>
<p>Dans la suite, j'appellerai <em>réseau 0</em> le
réseau local Ethernet relié à la machine Linux
par une carte Ethernet (clone NE-2000) sur <em>eth0</em>. Le
<em>réseau 1</em> est le réseau principal
connecté par la carte Ethernet sans-fil sur <em>eth1</em>.
La <em>machine A</em> est la machine Linux avec ses deux
interfaces. La <em>machine B</em> est une station quelconque du
réseau 0, et la <em>machine C</em> est sur le réseau
1.</p>
<p>Normalement, pour réaliser l'interconnexion, on pourrait
:</p>
<ul>
<li>utiliser le logiciel IP-Bridge (voir le <em>Bridge
mini-HOWTO</em>) pour réaliser un pont entre les deux
interfaces réseau. Malheureusement, la carte Ethernet
sans-fil ne peut pas être mise en mode ``promiscuous''
(autrement dit elle ne peut pas voir tous les paquets circulant sur
le réseau 1). C'est principalement à cause de la
faible bande passante de la carte Ethernet sans-fil (2 Mbits/sec),
ce qui implique que nous ne voulons pas supporter le trafic qui
n'est pas destiné à une autre machine sans-fil - dans
notre cas la machine A -, ou les diffusions générales
(<em>broadcasts</em>). De plus, un pont charge assez lourdement le
processeur.</li>
<li>ou bien utiliser des sous-réseaux et un routeur pour
transmettre les paquets entre les réseaux (voir le
<em>IP-Subnetworking mini-HOWTO</em>). C'est une solution
dépendante du protocole, bénéficiant du fait
que le noyau Linux sait gérer les paquets IP (Internet
Protocol), mais demandant du logiciel supplémentaire pour
router d'autres protocoles (tels qu'AppleTalk). De plus, ceci
nécessite d'allouer un nouveau numéro de
sous-réseau IP, ce qui n'est pas toujours possible.</li>
</ul>
<p>Dans mon cas, il n'était pas possible d'obtenir un
nouveau numéro de sous-réseau, alors je voulais une
solution qui permette aux machines du réseau 0
d'apparaître comme si elles étaient sur le
réseau 1. C'est à cela que sert le mandatement ARP.
D'autres solutions sont utilisées pour connecter d'autres
protocoles (non-IP), comme <em>netatalk</em> pour le routage
AppleTalk.</p>
<h2><a name="s4">4. Comment marche le mandatement ARP d'un
sous-réseau ?</a></h2>
<p>En fait, le mandatement ARP sert uniquement à faire
passer les paquets du réseau 1 vers le réseau 0. Pour
faire passer les paquets dans l'autre sens, on emploie le routage
IP normal.</p>
<p>Dans mon cas, le réseau 1 possède un masque de
sous-réseau à 8 bits <code>255.255.255.0</code>. Pour
le réseau 0, j'ai choisi un masque à 4 bits
(<code>255.255.255.240</code>), qui permet d'avoir 14 noeuds IP sur
le réseau 0 (2^4 = 16, moins deux pour l'adresse de
réseau remplie de zéros et l'adresse de diffusion
remplie de uns ). Remarquez que toute taille de masque de
sous-réseau convient, jusqu'à la taille - non
comprise - du masque de l'autre réseau (dans notre cas : 2,
3, 4, 5, 6 ou 7 bits - pour un seul bit utilisez le mandatement ARP
normal !).</p>
<p>Les numéros IP (au total 16) du réseau 0
apparaissent comme un sous-ensemble du réseau 1. Remarquez
qu'il est très important, dans ce cas, de ne pas donner aux
machines qui sont connectées directement au réseau 1
un numéro pris dans cet intervalle. Dans mon cas, j'ai
``réservé'' les numéros IP du réseau 1
qui se terminent par 64 à 79 pour le réseau 0. Les
numéros IP qui se terminent par 64 et 79 ne peuvent pas
être attribués à des machines : 79 est
l'adresse de diffusion pour le réseau 0.</p>
<p>La machine A a deux numéros IP, l'un dans la plage
d'adresses du réseau 0 pour sa vraie carte Ethernet
(<em>eth0</em>), l'autre dans la plage du réseau 1 (mais en
dehors de la plage du réseau 0) pour la carte Ethernet
sans-fil (<em>eth1</em>).</p>
<p>Supposons que la machine C (du réseau 1) veuille envoyer
un paquet à la machine B (du réseau 0). Comme le
numéro IP de la machine B laisse croire à la machine
C que B est sur le même réseau physique, la machine C
va utiliser le protocole de résolution d'adresse ARP pour
envoyer un message de diffusion sur le réseau 1, demandant
à la machine qui a le numéro IP de B de
répondre avec son adresse matérielle (adresse
Ethernet ou MAC). La machine B ne verra pas cette requête,
puisqu'en réalité elle n'est pas sur le réseau
1, mais la machine A, qui est sur les deux réseaux, la
verra.</p>
<p>La première chose magique se produit maintenant, lorsque
le code <em>arp</em> du noyau de la machine Linux
(configurée en mandataire ARP avec sous-réseau)
détermine que la requête est arrivée sur
l'interface du réseau 1 (<em>eth1</em>), et que le
numéro IP à résoudre est dans l'intervalle du
réseau 0. La machine A envoie alors sa propre adresse
matérielle (adresse Ethernet) à la machine C dans un
paquet de réponse ARP.</p>
<p>La machine C met alors à jour son cache ARP en y ajoutant
une entrée pour la machine B, mais avec l'adresse
matérielle (Ethernet) de la machine A (la carte Ethernet
sans-fil). La machine C peut alors envoyer le paquet pour B
à cette adresse matérielle (Ethernet), et la machine
A le reçoit.</p>
<p>La machine A remarque que l'adresse de destination IP n'est pas
la sienne, mais celle de B. Le code de routage du noyau Linux de la
machine A essaie alors de faire suivre ce paquet vers la machine B
en cherchant dans ses tables de routage pour savoir quelle
interface contient le numéro de réseau de B. Quoi
qu'il en soit, le numéro IP de B est valide aussi bien pour
le réseau 0 (<em>eth0</em>) que pour le réseau 1
(<em>eth1</em>).</p>
<p>C'est alors qu'un autre fait magique se produit : comme le
masque de sous-réseau du réseau 0 a plus de bits
à 1 (il est plus spécifique) que celui du
réseau 1, le code de routage du noyau Linux va associer le
numéro IP de B à l'interface du réseau 0, et
ne va pas chercher à voir si il correspond à
l'interface du réseau 1 (par laquelle le paquet est
arrivé).</p>
<p>Maintenant la machine A doit trouver la ``vraie'' adresse
matérielle (Ethernet) de la machine B (en supposant qu'elle
ne l'a pas déjà dans le cache ARP). La machine A
utilise une requête ARP, mais cette fois-ci le code
<code>arp</code> du noyau Linux voit que la requête ne vient
pas de l'interface du réseau 1 (<em>eth1</em>), et donc ne
renvoie pas l'adresse du mandataire ARP. À la place, il
envoie la requête ARP sur l'interface du réseau 0
(<em>eth0</em>), où la machine B le verra et répondra
en donnant sa propre adresse matérielle (Ethernet). La
machine A peut alors envoyer le paquet (qui venait de C) vers la
machine B.</p>
<p>La machine B reçoit le paquet de C (qui est passé
par A) et veut alors envoyer une réponse. Cette fois, B
remarque que C est sur un sous-réseau différent (le
masque de sous-réseau 255.255.255.240 exclut toutes les
machines qui ne sont pas dans la plage d'adresses IP du
réseau 0). La machine B est configurée avec une route
par défaut vers l'adresse IP de A sur le réseau 0, et
envoie le paquet à la machine A. Cette fois-ci, le code de
routage du noyau Linux de A trouve que l'adresse IP de la
destination (machine C) est sur le réseau 1, et envoie le
paquet à la machine C par l'interface Ethernet
<em>eth1</em>.</p>
<p>Des choses du même genre (mais moins compliquées)
se produisent pour les paquets émis (ou reçus) par la
machine A en direction (ou provenant) d'autres machines sur l'un ou
l'autre des deux réseaux.</p>
<p>De la même façon, il est évident que si une
autre machine D du réseau 0 envoie une requête ARP
concernant B sur le réseau 0, la machine A recevra cette
requête sur son interface du réseau 0 (<em>eth0</em>)
et s'abstiendra d'y répondre, puisqu'elle n'est
configurée comme mandataire que sur son interface du
réseau 1 (<em>eth1</em>).</p>
<p>Remarquez aussi que les machines B, C (et D) n'ont de
spécial à faire, du point de vue IP. Dans mon cas, il
y a un mélange de SUN, de MAC et de PC sous Windows 95 sur
le réseau 0, qui se connectent toutes au reste du monde
à travers la machine Linux A.</p>
<p>Pour finir, notez qu'une fois que les adresses
matérielles (Ethernet) ont été trouvées
par chacune des machines A, B, C (et D), elles sont placées
dans leur cache ARP, et que les paquets suivants sont
tranférés sans surcoût dû à l'ARP.
Normalement, les caches ARP suppriment les informations au bout de
5 minutes d'inactivité.</p>
<h2><a name="s5">5. Installation du mandataire ARP de
sous-réseau</a></h2>
<p>J'ai installé le mandataire ARP du sous-réseau sur
un noyau Linux version 2.0.30, mais il parait que le code
fonctionne avec une version 1.2.x.</p>
<p>La première chose à noter est que le code ARP est
en deux parties : une partie dans le noyau, qui envoie et
reçoit les requêtes et les réponses ARP et met
à jour le cache ARP, etc. ; l'autre partie est
constituée de la commande <code>arp(8)</code> qui permet au
super-utilisateur de mettre à jour manuellement le cache
ARP, et à tout le monde de le consulter.</p>
<p>Le premier problème que j'ai eu était que la
commande <code>arp(8)</code> de ma distribution Slackware 3.1
était antique (datée de 1994 !) et ne communiquait
pas correctement du tout avec le code ARP du noyau (``<code>arp
-a</code>'' donnait un résultat étrange).</p>
<p>La commande <code>arp(8)</code> de
``<code>net-tools-1.33a</code>'', qui est disponible sur un grand
nombre de sites, en particulier (d'après le README qui lui
est joint)
<code>ftp.linux.org.uk:/pub/linux/Networking/PROGRAMS/NetTools/</code>,
fonctionne correctement, et contient de nouvelles pages de manuel
<code>arp(8)</code> qui expliquent les choses bien mieux que les
anciennes.</p>
<p>Une fois muni d'une commande <code>arp(8)</code> décente,
il ne me restait plus qu'à modifier le seul fichier
<code>/etc/rc.d/rc.inet1</code> (pour la Slackware - c'est
probablement différent pour d'autres distributions). Tout
d'abord, il nous faut changer l'adresse de diffusion, le
numéro de réseau, et le masque de <em>eth0</em> :</p>
<pre>
NETMASK=255.255.255.240 # pour la partie hôte sur 4 bits
NETWORK=x.y.z.64 # notre nouveau réseau
# (remplacez x.y.z par votre réseau)
BROADCAST=x.y.z.79 # pour moi.
</pre>
<p>Il faut ensuite ajouter une ligne pour configurer la seconde
interface Ethernet (après les chargements de modules qui
sont éventuellement nécessaires pour lancer le
pilote) :</p>
<p><code>/sbin/ifconfig eth1</code>
<em>nom_sur_le_réseau_1</em> <code>broadcast</code>
<em>x.y.z.255</em> <code>netmask 255.255.255.0</code></p>
<p>Puis nous ajoutons une route pour la nouvelle interface :</p>
<p><code>/sbin/route add -net</code> <em>x.y.z.0</em> <code>netmask
255.255.255.0</code></p>
<p>Et vous aurez sans doute besoin de changer la passerelle par
défaut pour utiliser celle du réseau 1.</p>
<p>Arrivés à ce point, nous pouvons ajouter la ligne
pour le mandatement ARP :</p>
<pre>
/sbin/arp -i eth1 -Ds ${NETWORK} eth1 netmask ${NETMASK} pub
</pre>
<p>Ceci demande à ARP d'ajouter au cache une entrée
statique (``<code>s</code>'') pour le réseau
<code>${NETWORK}</code>. Le ``<code>-D''</code> dit d'utiliser la
même adresse matérielle que l'interface <em>eth1</em>
(la seconde interface), ce qui nous évite d'avoir à
chercher l'adresse matérielle de <em>eth1</em> et de la
coder directement dans la commande.</p>
<p>L'option <code>netmask</code> indique qu'il s'agit d'une
entrée ARP concernant un <em>sous-réseau</em>, qui
est constitué des numéros IP tels que</p>
<blockquote><code><em>numéro_ip</em> & ${NETMASK} ==
${NETWORK} & ${NETMASK}</code></blockquote>
L'option <code>pub</code> demande de <em>publier</em> cette
entrée ARP, c'est-à-dire qu'il s'agit
d'<em>mandatement</em>, et qu'il faudra répondre au nom de
ces numéros IP. L'option ``<code>-i eth1</code>''
précise qu'il ne faudra répondre qu'aux
requêtes ARP arrivant par l'interface <em>eth1</em>.
<p>Normalement, à ce point, si la machine est
redémarrée, tous les machines du réseau 0
sembleront être sur le réseau 1. Vous pouvez
vérifier que l'entrée de mandatement ARP de
sous-réseau a été prise en compte correctement
sur la machine A. Sur ma machine (j'ai changé les noms pour
protéger les innocents) c'est :</p>
<pre>
#/sbin/arp -an
Address HWtype HWaddress Flags Mask Iface
x.y.z.1 ether 00:00:0C:13:6F:17 C * eth1
x.y.z.65 ether 00:40:05:49:77:01 C * eth0
x.y.z.67 ether 08:00:20:0B:79:47 C * eth0
x.y.z.5 ether 00:00:3B:80:18:E5 C * eth1
x.y.z.64 ether 00:40:96:20:CD:D2 CMP 255.255.255.240 eth1
</pre>
<p>Vous pouvez aussi regarder le fichier
<code>/proc/net/arp</code>, par exemple avec
<code>cat(1)</code>.</p>
<p>La dernière ligne est l'entrée de mandatement pour
le sous-réseau. Les indicateurs <code>CMP</code>
révèlent qu'il s'agit d'une donnée statique
(entrée Manuellement) qui doit être Publiée.
Elle ne servira qu'à répondre qu'aux requêtes
ARP qui arrivent par <em>eth1</em> et pour lesquelles le
numéro IP, une fois masqué, correspond au
numéro de réseau (également masqué).
Remarquez que la commande <code>arp(8)</code> a trouvé
automatiquement l'adresse matérielle de <em>eth1</em> et l'a
employée comme adresse à utiliser (à cause de
l'option ``<code>-Ds</code>'').</p>
<p>De la même façon il est probablement prudent de
vérifier que la table de routage a été remplie
correctement. Voici la mienne (ici aussi, les noms ont
été changés pour protéger les
innocents) :</p>
<pre>
#/bin/netstat -rn
Kernel routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
x.y.z.64 0.0.0.0 255.255.255.240 U 0 0 71 eth0
x.y.z.0 0.0.0.0 255.255.255.0 U 0 0 389 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 7 lo
0.0.0.0 x.y.z.1 0.0.0.0 UG 1 0 573 eth1
</pre>
<p>Vous pouvez aussi regarder le contenu du fichier
<code>/proc/net/route</code> (par exemple avec
<code>cat(1)</code>).</p>
<p>Remarquez que la première entrée concerne un
sous-ensemble de la seconde, mais la table de routage les classe
dans l'ordre des masques, et donc l'entrée <em>eth0</em>
sera testée avant celle de <em>eth1</em>.</p>
<h2><a name="s6">6. Autres alternatives au mandatement ARP de
sous-réseau</a></h2>
<p>Dans la même situation il y a d'autres possibilités
que le mandatement ARP de sous-réseau et celles que j'ai
déjà mentionnées (utilisation d'un pont et
routage direct) :</p>
<ul>
<li>``<em>Masquerading IP</em>'' (voir le <em>IP-Masquerade
mini-HOWTO</em>), dans lequel le réseau 0 est
``cachée'' du reste du monde derrière la machine A.
Quand les machines du réseau 0 tentent de se connecter
à l'extérieur à travers la machine A, celle-ci
modifie l'adresse d'origine et le numéro de port des paquets
pour qu'ils aient l'air d'avoir été envoyés
par elle-même, plutôt que par la machine cachée
du réseau 0. C'est une solution élégante, bien
qu'elle empêche toute machine du réseau 1
d'établir une connexion vers une machine du réseau 0,
puisque les machines du réseau 0 n'existent pas en dehors de
celui-ci.
<p>Ceci améliore efficacement la sécurité des
machines du réseau 0, mais cela signifie aussi que les
serveurs du réseau 1 ne peuvent pas vérifier
l'identité des clients du réseau 0 en se basant sur
leur numéros IP (les serveurs NFS, par exemple, utilisent
les noms IP pour contrôler l'accès aux systèmes
de fichiers).</p>
</li>
<li>Une autre possibilité serait un <em>tunnel IP sur
IP</em>, ce qui n'est pas supporté par toutes les
plateformes (comme les Macs et les machines sous Windows), et je
n'ai donc pas opté pour cette solution.</li>
<li>Utiliser le mandatement ARP sans sous-réseau. C'est tout
à fait possible, cela signifie simplement qu'il faut
créer une entrée individuelle pour chaque machine du
réseau 0, au lieu d'une seule entrée pour toutes les
machines (présentes et futures) du réseau 0.</li>
<li>Il se peut que l'<em>aliasing IP</em> puisse être
utilisé ici (NdT: francheement ça
m'étonnerait), mais je n'ai pas du tout exploré cette
voie.</li>
</ul>
<h2><a name="s7">7. Autres applications du mandatement ARP de
sous-réseau</a></h2>
<p>Je ne connais qu'une autre application du mandatement ARP de
sous-réseau, ici à l'Australian National University
(ANU). C'est celle pour laquelle Andrew Tridgell a écrit,
à l'origine, les extensions du mandatement ARP pour les
sous-réseaux. Quoiqu'il en soit, Andrew m'informe qu'il y a,
de fait, plusieurs autres sites dans le monde qui l'utilisent
également (je n'ai aucun détail).</p>
<p>Á l'ANU, l'autre application concerne un laboratoire
d'enseignement qui sert à apprendre aux étudiants
comment configurer des machines pour utiliser TCP/IP, y compris
pour configurer la passerelle. Le réseau utilisé est
un réseau de classe C, et Andrew avait besoin de le
découper en sous-réseaux pour des raisons de
sécurité, de contrôle du trafic et la raison
pédagogique mentionnée plus haut. Il l'a fait en
utilisant le mandatement ARP, et a alors décidé
qu'une seule entrée dans le cache ARP pour tout le
sous-réseau serait plus rapide et plus propre qu'une pour
chaque machine du sous-réseau. Et voilà. Mandatement
ARP de sous-réseau !</p>
<p>Les corrections et les suggestions sont les bienvenues !</p>
<h2><a name="s8">8. Copyright</a></h2>
<p>Copyright 1997 par Bob Edwards
<<code>Robert.Edwards@anu.edu.au</code>></p>
<p>Téléphone : (+61) 2 6249 4090</p>
<p>Sauf mention contraire, les copyrights des documents ``<em>Linux
HOWTO</em>'' sont détenus par leurs auteurs respectifs. Ces
documents peuvent être reproduits et distribués en
tout ou partie, sur tout support physique ou électronique,
du moment que cette notice de copyright figure sur toutes les
copies. La redistribution commerciale est autorisée et
encouragée, cependant l'auteur souhaite en être
averti. Toutes les traductions, les travaux dérivés,
ou ouvrages incorporant un <em>Linux HOWTO</em> doivent être
soumis à cette même notice de copyright. Autrement
dit, vous ne pouvez pas produire un travail dérivé
d'un HOWTO en imposant des restrictions supplémentaires
à sa diffusion. Des dérogations à cette
règle peuvent être accordées sous certaines
conditions, veuillez contacter le coordinateur des Linux HOWTO
à l'adresse indiquée ci-dessous. En
résumé, nous souhaitons promouvoir la diffusion de
cette information par autant de canaux que possible, tout en
conservant le copyright sur les HOWTOs, et nous voudrions
être avertis de tout projet de redistribution de ces
documents. Si vous avez des questions, veuillez contacter Grek
Hankins, coordinateur des Linux HOWTOs, par courrier
électronique à
<<code>greg@sunsie.unc.edu</code>>.</p>
</body>
</html>
|