Xinetd

2011-12-08T07:44:07Z

Puwok20089FlJM :

[[Category:Sécurité]]
= XINETD sous toutes ses coutures =

<div class="leatitre">XINETD sous toutes ses coutures</div><div class="leapar">par [mailto:anne@lea-linux.org Anne]</div><div class="leadesc">Où comment utiliser xinetd pour sécuriser encore plus votre pingouin préféré</div>
----

== Avant propos ==

Cet article a pour objectif d'expliquer le fonctionnement et la configuration du super démon <tt>xinetd</tt>. Pourquoi particulièrement celui-ci ? Parce qu'il est utilisé fréquemment pour l'accès à nombre de services réseau et devient un outil non négligeable de sécurisation de celui-ci (en plus d'un bon firewall bien sûr). Cet article n'a pas pour objectif d'être complètement exhaustif mais de présenter les configurations les plus courantes de <tt>xinetd</tt>. Pour plus d'infos, consulter le man (on s'en serait douté ;) )

== Inetd ou Xinetd ? ==

Selon la distribution vous trouverez soit un démon <tt>inetd</tt>, soit un démon <tt>xinetd</tt>. La tendance est tout de même d'utiliser de plus en plus ce dernier.

=== Définition ===

Dans l'absolu, <tt>inetd</tt> et <tt>xinetd</tt> ont le même rôle, à savoir de piloter l'accès à un ou plusieurs services réseaux. Ils agissent comme une standardiste. Ils reçoivent des requêtes de clients, extérieurs pour la plupart, qui demandent un accès à un service réseau déterminé (ex : ftp, telnet, ssh...). Le super démon va, en fonction des instructions qu'on lui aura données (fichiers de configuration) transmettre ou rejeter l'appel.

=== Ce qu'apporte xinetd ===

<tt>inetd</tt>, jusque là utilisé, permettait, grâce au fichier <tt>/etc/inetd.conf</tt>et au wrapper <tt>tcpd</tt>, de paramétrer l'accès aux services en l'autorisant/interdisant totalement ou partiellement. (cf. les fichiers <tt>/etc/hosts.allow</tt> et <tt>/etc/hosts.deny</tt>).

<tt>xinetd</tt> apporte des fonctionnalités bien plus importantes et permet d'affiner les paramétrages d'accès aux services. On citera dans le désordre :

* possibilité d'affiner les logs des services gérés
* paramétrage d'accès par service et non global
* paramétrage des plages horaires de disponibilité des services
* possibilité de chrooter les services (ex : ftp)
* possibilité de limiter les attaques de type deny of service (contrôle de la priorité d'un serveur, contrôle de la charge CPU, contrôle du nombre de connexions par service, ...)
* redirection de ports

=== Passer de inetd à xinetd ===

Si votre distribution préférée utilise <tt>inetd</tt> et qu'après avoir eu le courage de lire cet article, vous souhaitez utiliser <tt>xinetd</tt>, il existe un script qui vous permettra de transformer le fichier <tt>inetd.conf</tt> en fichier <tt>xinetd.conf</tt>, utilisable par <tt>xinetd</tt>

Ce script, <tt>xconv.pl</tt>, est un script perl fourni avec <tt>xinetd</tt>. Attention si ce script peut vous donner la structure générale du fichier de configuration, il ne vous permettra pas de profiter des apports de <tt>xinetd</tt>. Rien de tel qu'un bon éditeur de texte et ce qui suit ci-dessous.

== configuration générale de xinetd ==

On entre dans le vif du sujet :). Pour configurer <tt>xinetd</tt>, vous aurez à connaître la syntaxe, commune de <tt>/etc/xinetd.conf</tt> et, selon les cas de figure, les fichiers situés dans le répertoire <tt>/etc/xinetd.d</tt>.

=== L'arborescence de xinetd ===

L'arborescence de la configuration de <tt>xinetd</tt> est relativement simple. On en rencontre 2 types : 

* '''un seul fichier de configuration''' : <tt>/etc/xinetd.conf</tt> qui comprendra la configuration générale de <tt>xinetd</tt> '''et''' la configuration des services gérés par xinetd. (exemple plus loin dans l'article)
* un fichier réservé à la '''configuration générale''' de <tt>xinetd</tt>, nommé aussi <tt> /etc/xinetd.conf</tt>. La '''configuration des services''' est déportée dans des fichiers situés dans le répertoire <tt>/etc/xinetd.d</tt>. Ce répertoire comprend un fichier de configuration par service géré par <tt>xinetd</tt>. Le fichier porte le nom du service. Pour utiliser ce deuxième cas de figure, le fichier <tt>/etc/xinetd.conf</tt> doit contenir la ligne suivante : <tt>includedir /etc/xinetd.d</tt>

C'est ce deuxième cas de figure qui est le plus couramment utilisé dans les distributions.

=== Syntaxe générale d'un fichier de configuration ===

Le fichier de configuration de <tt>xinetd</tt> est un ensemble d'une ou plusieurs directives dont la syntaxe est la suivante : 

<blockquote><tt>service nom_du_service { ... }</tt> </blockquote>

Le nom de la directive est soit <tt>defaults</tt> et la configuration porte alors sur l'ensemble des services gérés par <tt>xinetd</tt>, soit le nom d'un des services géré par <tt>xinetd</tt>. A l'intérieur de chacune de ces directives on trouvera des attributs, un par ligne, écrits de la manière suivante : <tt><attribut> <assignement> <valeur> <valeur> ...</tt> Les attributs seront détaillés plus loin. Les assignements peuvent prendre différentes valeurs : <tt>=, -=, +=</tt>. '''Exemple :'''

<blockquote><tt>root@pingu# cat /etc/xinetd.d/telnet service '''telnet''' </tt> <tt>{ ... server = /usr/sbin/in.telnetd ... }</tt> </blockquote>

avec : attribut : server assignement : "=" valeur : /usr/sbin/in.telnetd 

Pour reprendre l'arborescence de <tt>xinetd</tt> et les 2 cas de figure exposés ci-dessus, on obtiendra les fichiers suivants :

{| width="70%" border="1"
| align="center" | '''un seul fichier de configuration'''
| align="center" | '''un fichier de configuration par service'''
|-
| valign="top" | <tt>/etc/xinetd.conf defaults { ... } service service1 { ... } service service2 { ... } </tt>
| <tt>/etc/xinetd.conf defaults { ... } /etc/xinetd.d/service1 service service1 { ... } /etc/xinetd.d/service2 service service2 { ... }</tt> 
|}

=== Écriture des fichiers : attributs obligatoires ===

Nous allons lister les différents attributs utilisables pour configurer <tt>xinetd</tt>. Certains sont facultatifs et vous permettent d'affiner son rôle. Toutefois d'autres sont obligatoires et s'ils ne sont pas présents, empêcheront tout ou partie des services de fonctionner.

Avant de les lister, petit point de vocabulaire : on distingue les services dits internes et externes. A quoi ? A <tt>xinetd</tt> bien sur :). Les services internes, comme <tt>servers, services, xadmin</tt> sont des services propres à <tt>xinetd</tt> qui fournissent des informations sur le fonctionnement du super-démon. Il vaut mieux ne pas utiliser ces services car ils exposent la machine inutilement et les fichiers de log de xinetd vous fourniront les mêmes informations.

Voilà donc les attributs que vous devrez utiliser :

{| width="80%" border="1"
| align="center" | '''Attribut'''
| align="center" | '''Définition'''
|- bgcolor="#cccccc"
| valign="top" | <tt>'''socket-type'''</tt>
| type de socket utilisé pour le service : <tt>dgram</tt> s'il utilise le protocole UDP, <tt>stream</tt> s'il utilise le protocole TCP - consulter le fichier <tt>/etc/services</tt> pour avoir l'information.
|-
| valign="top" | <tt>'''user'''</tt>
| identité sous laquelle le service sera lancé
|- bgcolor="#cccccc"
| valign="top" | <tt>'''server'''</tt>
| chemin et nom du serveur
|-
| valign="top" | <tt>'''wait'''</tt>
| Définit le comportement du service dans le traitement des threads : <tt>yes</tt> pour un service mono-thread (une connexion simultanée par service et une seule), <tt>no</tt> pour un service multithread (possibilité d'avoir plusieurs connexions simultanées au service)
|- bgcolor="#cccccc"
| valign="top" | <tt>'''protocol'''</tt>
| Protocole utilisé par le service. Si rien n'est précisé, c'est le protocole spécifié dans le fichier <tt>/etc/services</tt> qui sera utilisé.
|-
| valign="top" | <tt>'''rpc_version rpc_number'''</tt>
| Ne concerne que les services basés sur les RPC (exemple : NFS)
|- bgcolor="#cccccc"
| valign="top" | <tt>'''port'''</tt>
| Port associé au service. Là encore, s'il n'est pas précisé, c'est le port spécifié pour le service dans le fichier <tt>/etc/services</tt>.
|}

== Affiner les logs avec xinetd ==

Une des fonctionnalités de <tt>xinetd</tt> est de permettre d'affiner ce que vous voulez loguer et dans quel(s) fichier(s) vous voulez le loguer.

=== Localisation des logs ===

C'est l'attribut '''<tt>log_type</tt>''' qui va donner cette localisation. Il peut prendre 2 valeurs :

* <tt>'''SYSLOG syslog_facility [syslog level]'''</tt> : les logs seront alors gérés par le démon <tt>syslogd</tt>. Vous pourrez préciser le ''niveau'' de log (voir man syslog) : avec les valeurs <tt>emerg, alert, crit, err, warning, notice, info, debug</tt>. L'ordre de ces valeurs indique une quantité croissante d'informations récupérées par syslogd. Par défaut, c'est le niveau <tt>info</tt> qui est utilisé. Vous retrouverez ensuite les logs généralement dans le fichier <tt>/var/log/messages</tt> (cf. <tt>/etc/syslog.conf</tt>). Inconvénient de cette méthode : toutes les informations sont stockées dans un seul fichier et difficiles à lire étant donné la quantité d'éléments recueillis pour le noyau. 
* <tt>'''FILE file [soft limit [hard limit]]'''</tt> : vous allez pouvoir complètement configurer la destination de vos logs et dans l'absolu, prévoir un fichier de log par service géré par xinetd. Le mot-clé <tt>FILE</tt> sera suivi du nom du fichier. Si celui-ci n'existe pas, il sera créé. De manière facultative, vous pouvez également préciser 2 types de limites à la taille du fichier de log : une ''limite soft'' qui lorsqu'elle est franchie provoque l'envoi d'un message d'alerte (mais les logs continuent d'alimenter le fichier) et une ''limite hard'', qui lorsqu'elle est franchie bloque l'envoi de logs supplémentaires dans le fichier concerné. L'utilisation de ces deux limites est recommandée pour éviter de saturer le système de fichiers. Les limites sont à donner en octets (1000b), en kilo-octets (1000k) ou en mega-octets (1000m).

=== Contenu des logs ===

Outre la localisation des logs, il est possible également de paramétrer le contenu des logs. On utilisera les attributs <tt>log_on_success</tt> et <tt>log_on_failure</tt> qui, comme l'intitulé l'indique, listent ce qui sera logué en cas de succès et d'échec de l'accès au service. Les valeurs sont :

* <tt>PID</tt> : numéro de process du serveur lancé
* <tt>HOST</tt> : adresse distante cliente du serveur
* <tt>USERID</tt> : user id de l'utilisateur distant
* <tt>DURATION</tt> : durée de la session

Les 4 valeurs sont utilisables avec l'attribut <tt>log_on_success</tt>. Seuls <tt>HOST</tt> et <tt>USERID</tt> sont utilisables avec <tt>log_on_failure</tt>.

'''Exemple :'''

<tt>service trucmuche { ... log_type = FILE /var/log/xinetd/trucmuche.log log_on_success = PID USERID HOST DURATION log_on_failures = HOST USERID ... } </tt>

Dans ce cas de figure, le fichier de log du service trucmuche sera <tt>/var/log/xinetd/trucmuche.log</tt>. Les informations recueillies dans tous les cas seront l'adresse du client et son identité et en cas de succès, on aura également le PID du serveur et la durée de la session

== Xinetd pour contrôler les accès à votre machine ==

Xinetd dispose de nombreux attributs complémentaires, facultatifs mais qui vont permettre d'en faire un outil de sécurisation des services réseaux et du système dans son ensemble. Ci-dessous, les principales fonctionnalités proposées.

=== Contrôler l'origine des accès ===

Avec des attributs supplémentaires, vous allez pouvoir filtrer les clients qui vont pouvoir ou non se connecter à vos serveurs.

'''Filtrer des adresses : <tt>only_from = valeur [valeurs...]</tt>'''. La connexion au service ne sera possible qu'à partir de la liste fournie à cet attribut. Elle peut contenir :

* des adresses IP : facile à comprendre je ne m'étends pas.
* des adresses réseau : 192.168.0.0 par exemple. Seules les adresses IP de ce réseau pourront accéder au service
* des hostnames : Ce sont des noms de machine. A utiliser si et seulement si le fichier <tt>/etc/hosts</tt> est correctement renseigné. La résolution de nom se fait au moment de l'accès.
* des noms de domaine : lea-linux.org par exemple. Seul le domaine de Léa pourra alors accéder à votre service.

Vous pouvez bien sûr panacher les valeurs.

'''Exemple '''<nowiki>: configuration des accès ftp sur ma machine :</nowiki> <tt>service proftpd { ... only_from = citrouille 192.168.1.0 lea-linux.org ... {</tt>

Les seuls autorisés à utiliser mon serveur ftp seront : la machine "citrouille", les machines du réseau 192.168.1.0 et celles du domaine lea-linux.org.

Un attribut qui a également pour effet de filtrer les accès est '''<tt>no_access = valeur [valeurs...]</tt>'''. Il fonctionne exactement de la même façon que <tt>only_from</tt> sauf qu'il détermine les machines, adresses IP, hostnames, adresses réseaux et/ou noms de domaine pour lesquels vous voulez interdire l'accès à votre service.

Attention, encore une fois, <tt>xinetd</tt> utilisé seul ne vous garantira pas la sécurité de votre système. Il est essentiel d'y adjoindre un bon firewall.

=== Contrôler le moment des accès ===

Vous pouvez choisir le moment auquel vous autoriserez les accès à tout ou partie de vos services réseaux. On utilisera l'attribut <tt>access_times</tt>. Il vous permet de définir une ou plusieurs plages horaires pendant lesquelles la connexion sera possible.

'''Syntaxe''' : <tt>access_times = interval [interval...]</tt> L'intervalle de temps s'écrit : heures:minutes-heures:minutes

'''Exemple :''' Je veux limiter l'accès de mon ftp de 9h à 12h et de 14h à 16h. <tt>service proftpd { ... access_time = 9:00-12:00 14:00-16:00 ... {</tt>

=== Contrôler l'exposition du système pendant l'accès : chroot ===

Véritable couteau suisse de la configuration de services réseau, <tt>xinetd</tt> vous permet de "chrooter" un service. ''Rappel'' : la commande <tt>chroot</tt> permet de lancer un programme en restreignant ses accès disques à une sous arborescence. En fait pour le processus, la racine du disque est la racine de l'arborescence dans laquelle il a été restreint.

L'attribut <tt>server_args</tt> va nous permettre d'automatiser le chroot : la commande <tt>chroot</tt> est considérée comme le serveur et le service est passé en argument.

'''Exemple :''' Je veux chrooter mon serveur ftp. <tt>service proftp { ... server = /usr/sbin/chroot server_args = /opt/proftpd/proftpd ... {</tt>

Lorsqu'un client tente un accès ftp, <tt>chroot</tt> est exécuté en tant que serveur et <tt>proftpd</tt> en tant qu'argument, ce qui revient à la commande connue : <tt>/usr/bin/chroot opt/proftpd/proftpd</tt>.

=== Autoriser / interdire un service ===

Dans la plupart des distributions, les services installés et gérés par <tt>xinetd</tt> sont désactivés d'office, pour des raisons de sécurité. D'autre part vous pouvez, pour un temps, choisir de désactiver complètement un service. Tout ceci est lié à l'utilisation de l'attribut <tt>disable</tt>.

'''Syntaxe : '''<tt>disable = yes|no</tt>

'''Exemple :''' Je veux désactiver telnet. <tt>service telnet { disable = yes ... {</tt>

== Xinetd pour limiter les attaques de type Deny of Service ==

* '''Contrôle de la charge CPU : <tt>rlimit_cpu = seconds</tt>'''. Cet attribut vous permet de limiter le temps CPU utilisé par un ou plusieurs services. Un des effets induits par une attaque de type Deny Of Service. 
* '''Priorité accordée au processus serveur : <tt>nice = level</tt>'''. Fonctionnant comme avec la commande <tt>nice</tt>, l'attribut permet de fixer une priorité d'ordonnancement pour le serveur. Le <tt>level</tt> peut prendre les valeurs de -20 (le plus prioritaire) à 19 (le moins prioritaire). Cela vous permet par exemple de passer en process moins prioritaire un serveur ftp par rapport aux process de vos applications courantes. Après tout c'est votre machine ;). 
* '''Limite du nombre de connexions par service : <tt>instances = value</tt>'''. L'attribut détermine le nombre d'instances simultanées du serveur qui seront autorisées. Préciser un nombre. Sans précision, le nombre d'instances pourra être illimité. 
* '''Limite du nombre de connexions ayant la même origine : <tt>per_source = value</tt>'''. Non seulement vous pouvez filtrer les adresses IP clientes, le nombre d'instances du serveur mais vous pouvez aussi limiter le nombre de connexions à un serveur donné provenant d'une même adresse IP. Ceci est une limite non négligeable aux attaques dues à des connexions multiples sur vos serveurs accessibles. 
* '''Blacklister des adresses IP''' : Il vous est possible blacklister des adresses IP qui tenteraient des connexions sur des services que vous avez désactivés mais qui constituent la cible préférée des hackers (exemple : telnet). On utilisera 2 attributs de manière combinée : <blockquote><tt>'''flags = SENSOR deny_time = minutes'''</tt></blockquote>
<tt>SENSOR</tt> empêche toute connexion au service concerné et stocke l'adresse IP pendant un temps déterminé par l'attribut <tt>deny_time</tt>. Si cette même adresse tente de se connecter à '''n'importe quel service géré par xinetd''', il sera automatiquement bloqué. Le temps est déterminé en minutes, mais vous pouvez utiliser également la valeur <tt>FOREVER</tt> : l'IP restera blacklistée jusqu'au prochain redémarrage de <tt>xinetd</tt>.

== Autres fonctionnalités de xinetd ==

Je ne verrai pas ici toutes les possibilités offertes par xinetd mais 2 en particulier : la redirection de port et l'attribution d'un service à une interface réseau.

=== Redirection de ports ===

Même si ce n'est pas sa fonction principale, <tt>xinetd</tt> peut vous permettre de faire de la redirection de port, si vous ne souhaitez pas approfondir <tt>iptables</tt>. On utilisera pour cela l'attribut '''<tt>redirect</tt>'''.

'''Syntaxe :''' <tt>redirect = adresseIP port</tt>

'''Exemple :''' Je dispose d'une passerelle vers Internet et une machine sur le même réseau local dont l'adresse IP est 192.168.0.3. Je souhaite installer un serveur telnet sur cette dernière machine. Je vais donc faire en sorte que les requêtes qui arrivent de l'extérieur pour mon serveur telnet soient redirigées vers cette machine.

<blockquote><tt>root@pingu# cat /etc/xinetd.d/telnet service telnet { ... server = /usr/sbin/in.telnetd redirect = 192.168.0.4 23 } </tt></blockquote>

On teste maintenant la connexion : 

<blockquote><tt>root@pingu# telnet 217.11.12.13 Trying 217.11.12.13... Connected to 217.11.12.13. Escape character is '^]'. Red Hat Linux release 8.0 (Psyche) Kernel 2.4.18-14 on an i586 login: anne Password: Last login: Fri Nov 8 12:26:44 on :0 [anne@citrouille anne]$ hostname citrouille </tt></blockquote>

La connexion telnet est établie et la commande <tt>hostname</tt> nous confirme que je ne suis pas sur la passerelle mais sur la machine citrouille dont l'adresse IP est 192.168.0.4

=== Attribution d'un service à une adresse IP ===

<tt>xinetd</tt> va vous permettre de lier un service à une adresse IP grâce à l'attribut <tt>bind</tt>.

Pour éclaircir la description de cet attribut, nous allons nous appuyer sur un exemple. Je vais reprendre mes 2 machines de l'exemple précédent. Mon objectif : je veux construire 2 serveurs ftp bien différenciés. L'un sera réservé à mes machines en local (serveur de fichiers interne) l'autre mettra à disposition d'autres fichiers sur un serveur ftp réservé aux connexions externes. (Après tout je ne partage pas tout :)).

Ma machine <tt>pingu</tt> (ma passerelle) a 2 interfaces réseau avec les adresses IP respectives : 192.168.0.3 et 217.11.12.13. Je vais donc effectuer les attributions grâce au fichier suivant :

<blockquote><tt>root@pingu# cat /etc/xinetd.d/proftpd service proftpd { id = ftp_public ... server = /opt/proftpd/proftpd bind = 217.11.12.13 } service proftpd { id = ftp_privé ... server = /opt/proftpd/proftpd bind = 192.168.0.3 } </tt></blockquote>

L'attribut <tt>id</tt> sert uniquement à différencier les 2 configurations du service. Tout ceci bien sûr doit s'accompagner d'une configuration de votre serveur ftp.

=== xinetd parle à vos visiteurs ===

Pour finir, <tt>xinetd</tt> vous permet également d'afficher des messages lors de la connexion à un service grâce aux attributs suivants :

* <tt>'''banner = fichier'''</tt> - affiche le contenu de <tt>fichier</tt> si l'accès est autorisé, et avant même authentification.
* <tt>'''banner_succes = fichier'''</tt> - affiche le contenu de <tt> fichier</tt> en cas de réussite de l'authentification
* <tt>'''banner_fail = fichier'''</tt> - affiche le contenu de <tt> fichier</tt> en cas d' échec de l'authentification

== Exemples de configuration ==

Ci-dessous quelques exemples de fichiers de configuration de services, issus entre autres du man de xinetd.conf

=== Exemple 1 ===

Le 1er exemple est un fichier de configuration du service <tt>ftp</tt>.

<blockquote><tt>root@pingu# cat /etc/xinetd.d/ftp service ftp { socket_type = stream wait = no nice = 10 user = root server = /usr/etc/in.ftpd server_args = -l instances = 4 log_type = FILE /var/log/ftp.log log_on_success = DURATION HOST USERID access_times = 2:00-9:00 12:00-24:00 }</tt></blockquote>

Le serveur ftp, hormis les paramètres génériques de configuration, autorise des connexions entre 2h et 9h et entre midi et minuit. Son fichier de log est <tt>/var/log/ftp.log</tt> et contient, en cas de connexions réussies, la durée de la connexion, le nom de la machine cliente et l'UID de l'utilisateur connecté. Seules 4 instances simultanées sont autorisées

.

=== Exemple 2 ===

Le 2e exemple est un fichier de configuration du service <tt>telnet</tt>.

<blockquote><tt>root@pingu# cat /etc/xinetd.d/telnet service telnet { socket_type = stream wait = no nice = 10 user = root server = /usr/etc/in.telnetd rlimit_as = 8M rlimit_cpu = 20 }</tt></blockquote>

=== Exemple 3 ===

Le dernier exemple se compose de 2 fichiers de configuration pour la gestion de <tt>samba</tt>. par xinetd. En effet, le service samba lance 2 démons, <tt>nmbd</tt> et <tt>smbd</tt>

<blockquote><tt>root@pingu# cat /etc/xinetd.d/netbios-ssn service netbios-ssn { socket_type = stream protocol = tcp wait = no user = root server = /usr/sbin/smbd only_from = 192.168.0.0 disable = no } root@pingu# cat /etc/xinetd.d/netbios-ns service netbios-ns { socket_type = dgram protocol = udp wait = no user = root server = /usr/sbin/nmbd only_from = 192.168.0.0 disable = no }</tt></blockquote>

Hormis les paramètres génériques de configuration de smbd et nmbd, on a configuré samba de manière à ce qu'il ne soit utilisable que sur le réseau interne 192.168.0.0.

== Le mot de la fin ==

Je n'ai pas exploré ici l'intégralité des possibilités de xinetd. La meilleur des choses à faire pour cela est de se reporter au man. Si vous disposez encore une distribution utilisant inetd, et au vu de toutes les fonctionnalités de xinetd, il semble opportun d'abandonner le premier pour le deuxième. Bien exploité, il devient véritablement un outil de sécurisation de votre système, dès lors que vous mettez en place un certains nombres de serveurs qui, ouvrant votre machine sur l'extérieur, ouvre également la voie aux vilains hackers ;).

N'hésitez pas à me faire parvenir vos remarques et ajouts divers sur le contenu de cet article.

<div class="merci">Cette page est issue de la documentation 'pré-wiki' de Léa a été convertie avec HTML::WikiConverter. Elle fut créée par Anne le 15/11/2002.</div>

Lea Linux - Contributions [fr]

Xinetd