Lea Linux - Contributions [fr]

DKMS

2007-04-27T19:30:26Z

Pterjan : /* Structure sur le disque */

[[Category:Configurer votre noyau]]

= DKMS : Donnez l'indépendance à vos pilotes =

== Contexte ==

Sous Linux, les pilotes (le logiciel qui permet au système d'exploitation de communiquer avec le matériel) peuvent soit être directement inclus dans le noyau soit être disponibles sous la forme de modules à charger dans le noyau. Un tel module est compilé pour un noyau particulier et ne peut être utilisé sur un autre.

En ce qui concerne les pilotes libres, cela ne pose en général aucun problème car ils sont soit livrés avec votre noyau, soit compilés en même temps que le noyau que vous compilez vous-même.

Dans le cas de pilotes non libres (comme ceux de nVidia ou ATI) ou de pilotes distribués séparément et que vous compilez à la main, le pilote doit être recompilé à chaque version de noyau, ce qui peut devenir fastidieux.

De plus, si vous souhaitez utiliser les pilotes distribués par votre distributeur Linux, vous devez attendre que les pilotes soient recompilés pour le nouveau noyau, et ne pouvez espérer qu'ils fonctionnent avec un noyau que vous auriez personnalisé.

== Objectifs de DKMS ==

DKMS (Dynamic Kernel Module Support ou en français Gestion Dynamique des Modules Noyau) est un système très simple conçu par Dell et permettant de compiler dynamiquement et facilement les modules noyau pour tous les noyaux de votre système. Ce système est à la base conçu pour faciliter à Dell la distribution de pilotes Linux et de correctifs.

Cela évite à la fois aux éditeurs et aux utilisateurs de devoir passer par des mises à jour du noyau pour une correction sur un pilote particulier et permet de distribuer un pilote supplémentaire sous la forme d'un seul paquetage quel que soit le noyau de l'utilisateur.

Cet article a pour but de présenter ce système, à la fois aux développeurs et distributeurs de modules noyau qui pourraient l'utiliser pour faciliter la vie à leurs utilisateurs, et aux utilisateurs qui peuvent également l'utiliser tout seuls.

== Comment ça marche ==

Le principe de DKMS est très simple. À condition que le module soit prévu pour être utilisé avec DKMS (fourniture d'un dkms.conf), l'utilisation d'un nouveau module en passant par DKMS consiste à exécuter les 3 étapes suivantes :

* Insertion dans l'arbre DKMS (action add)
* Compilation pour le noyau (action build)
* Installation avec les autres modules du noyau (action install)

Ces étapes sont séparées et ne sont pas forcement toutes réalisées à la suite. La figure 1 montre les différents états d'un module dans le système DKMS, et les transitions possibles entre ces états à l'aide des actions de la commande dkms.

Figure 1 : États d'un module dans le système DKMS

=== Structure sur le disque ===

Afin de bien séparer la gestion des différentes versions de module et de la version du noyau, le fonctionnement de DKMS se base sur la présence de 3 arborescences :

* Les sources des modules, dans <tt>/usr/src</tt>
* L'arborescence des modules du noyau <tt>/lib/modules</tt> : DKMS y remplacera ou ajoutera les modules que l'on va lui faire gérer
* L'arborescence de DKMS <tt>/var/lib/dkms</tt>, contenant :
o Les répertoire ou seront construits les modules
o Les modules originaux sauvegardés
o Les modules générés par DKMS

Les chemins indiqués sont ceux par défaut et il est possible de les modifier dans <tt>/etc/dkms/framework.conf</tt> mais nous supposerons dans le reste de l'article que les valeurs par défaut ont été conservées.

== Mise en oeuvre de DKMS par un utilisateur ==

=== La commande dkms ===

La gestion des modules au sein du système DKMS se fait à l'aide de la commande dkms. Cette commande a une syntaxe très simple : dkms <action> [options]
Les actions et les options sont par contre plutôt nombreuses et même si je vous les explique ci-dessous, seules les principales devraient être utiles à la majorité d'entre vous (à savoir: add, build, install, remove en ce qui concerne les actions et -m, -v et --all en ce qui concerne les options).

Voici tout d'abord la liste des options génériques s'appliquant à diverses commandes, celles restreintes à une commande particulière seront expliquées dans la description de celle-ci.

* -m <module> : Le nom du module sur lequel effectuer l'action.
* -v <version du module> : La version du module sur laquelle effectuer l'action.
* -k <version du noyau> : La version du noyau sur laquelle effectuer l'action. Il est possible pour certaines actions de spécifier plusieurs versions du noyau en utilisant plusieurs fois -k, si l'action spécifiée ne le supporte pas une erreur sera émise.
* -a <architecture> : L'architecture pour laquelle effectuer l'action. Si cette option n'est pas précisée, l'architecture choisie est celle indiquée par uname -m. Il est possible de répéter cette option afin d'indiquer plusieurs architectures, mais dans ce cas il doit y avoir exactement autant de -k que de -a. Chaque noyau sera associé à l'architecture de position identique. Par exemple si vous indiquez -k noyau1 -k noyau2 -a i386 -k noyau3 -a i586 -a x86_64, DKMS comprendra que noyau1 est en i386, noyau2 est en i586 et noyau3 est en x86_64.
* --all : Indique d'appliquer l'action pour toutes les versions de noyau et toutes les architectures pour lesquelles le module a été compilé. Cela est particulièrement utile pour l'action remove.
* --rpm_safe_upgrade : Cette option est nécessaire pour les commandes DKMS appelées à l'intérieur d'un RPM. Cela évite des problèmes lors de mise à jour d'un RPM à un autre contenant la même version du module. Cela évite aussi les problèmes d'interblocage dus au système de verrous de rpm.

Nous allons maintenant étudier ce que permet de faire DKMS à travers le parcours des actions que l'on peut faire effectuer à la commande dkms.

* add : Ajoute à l'arbre des sources de DKMS une version d'un module (les options -m et -v sont donc obligatoires, c'est le cas pour la majorité des commandes). Les sources du module doivent être précédemment placées dans /usr/src/<module>-<version du module>/ et contenir un fichier dkms.conf. Si le fichier dkms.conf ne se trouve pas dans /usr/src/<module>-<version du module>/, il faut ajouter l'option -c pour indiquer son chemin.

<code>[root@plop src]# dkms add -m exemple -v 0.9.0 -c /tmp/dkms.conf
Creating symlink /var/lib/dkms/exemple/0.9.0/source ->
/usr/src/exemple-0.9.0

DKMS: add Completed.</code>

* remove : Supprime une version d'un module. Il faut en plus des options -m et -v, soit préciser une version de noyau avec l'option -k, soit demander à supprimer le module de tout les noyaux pour lesquelles cette version avait été compilée, avec l'option --all.

Si le module avait été installé, il est d'abord désinstallé (comme si on avait appelé l'action uninstall) et d'éventuelles versions précédentes sont réinstallées. Après un remove, le module n'est plus du tout connu de DKMS et il faut recommencer à l'étape add.

<code>[root@plop src]# dkms remove -m exemple -v 0.9.0 --all

------------------------------
Deleting module version: 0.9.0
completely from the DKMS tree.
------------------------------
Done.</code>

* build : Compile une version d'un module pour le noyau indiqué avec l'option -k ou pour le noyau utilisé actuellement si aucun n'est précisé. En cas d'erreurs lors de la compilation, il est utile de savoir que celle-ci se déroule dans /var/lib/dkms/<module>/<version du module>/build/ et que tout ce qui est affiché pendant la compilation est enregistré dans un fichier make.log dans ce même répertoire.

La commande build accepte quelques options facultatives :
o --config <fichier .config du noyau> : Cette option permet d'indiquer à la commande build ou trouver le fichier .config si celui-ci n'est pas à l'emplacement standard de la distribution ou n'a pas le nom habituel.
o --no-prepare-kernel : Cette option demande à DKMS de ne pas préparer les sources du noyau avant de compiler un module pour lui. Il est recommandé de ne pas utiliser cette option si l'on souhaite que les modules soient correctement construits.
o --no-clean-kernel : Cette option demande à DKMS de ne pas nettoyer les sources du noyau après avoir compilé un module.
o --kernelsourcedir <chemin vers les sources du noyau> : Cette option permet d'indiquer l'emplacement des sources du noyau lorsqu'elles ne se trouvent pas dans /lib/modules/<version du noyau>/build.

<code>[root@plop src]# dkms build -m slmodem -v 2.9.10 -k 2.6.12-12mdk-i686-up-4GB

Preparing kernel 2.6.12-12mdk-i686-up-4GB for module build:
(This is not compiling a kernel, only just preparing kernel symbols)
Storing current .config to be restored when complete
Running Generic preparation routine
make mrproper.........
using /boot/config-2.6.12-12mdk-i686-up-4GB
make oldconfig......
make prepare-all......

Building module:
cleaning build area....
make KERNELRELEASE=2.6.12-12mdk-i686-up-4GB KERNEL_DIR=/lib/modules/2.6.12-12mdk-i686-up-4GB/build drivers....
cleaning build area....
cleaning kernel tree (make mrproper)....

DKMS: build Completed.</code>

* install : Installe une version d'un module dans l'arborescence du noyau indiqué (ou du noyau utilisé actuellement si aucun n'est précisé par l'option -k). Cette version doit précédemment avoir été compilée pour le noyau en question à l'aide de l'action build.

Lors de la première installation d'une version d'un module donné sur un noyau donné, DKMS cherche si ce module existait déjà avec ce noyau et le sauvegarde pour pouvoir le réinstaller lorsque l'on demandera à DKMS de désinstaller la nouvelle version. Pour information, la version originale est sauvée dans /var/lib/dkms/<module>/original_module/<version du noyau>/<architecture>/

<code>[root@plop src]# dkms install -m slmodem -v 2.9.10 -k 2.6.12-12mdk-i686-up-4GB
Running module version sanity check.

slamr.ko.gz:
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/2.6.12-12mdk-i686-up-4GB/kernel/drivers/char/

slusb.ko.gz:
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/2.6.12-12mdk-i686-up-4GB/kernel/drivers/char/

depmod.....

DKMS: install Completed.</code>

* uninstall : Désinstalle une version d'un module pour une version du noyau (celle précisée par l'option -k ou la version utilisée actuellement si aucune n'est précisée). Cette commande ne gère pas l'option --all donc il vous faudra désinstaller pour chaque noyau séparément.

<code>[root@plop src]# dkms uninstall -m slmodem -v 2.9.10 -k 2.6.12-12mdk-i686-up-4GB

-------- Uninstall Beginning --------
Module: slmodem
Version: 2.9.10
Kernel: 2.6.12-12mdk-i686-up-4GB (i586)
-------------------------------------

Status: Before uninstall, this module version was ACTIVE on this kernel.

slamr.ko.gz:
- Uninstallation
- Deleting from: /lib/modules/2.6.12-12mdk-i686-up-4GB/kernel/drivers/char/
- Original module
- No original module was found for this module on this kernel.
- Use the dkms install command to reinstall any previous module version.

slusb.ko.gz:
- Uninstallation
- Deleting from: /lib/modules/2.6.12-12mdk-i686-up-4GB/kernel/drivers/char/
- Original module
- No original module was found for this module on this kernel.
- Use the dkms install command to reinstall any previous module version.

DKMS: uninstall Completed.</code>

* mkrpm : Génére un RPM pour un couple module/version donné. Si vous désirez que le RPM ne contienne que les sources (et donc que les modules soient compilés lors de l'installation), vous devez ajouter l'option --source-only. Sinon, le choix des modules à distribuer se fait à l'aide de -k et -a, comme pour les autres actions.

Si vous maîtrisez la création de RPM et souhaitez personnaliser ce qui est généré, sachez que DKMS regarde d'abord si /usr/src/<module>-<version du module>/<module>-dkms-mkrpm.spec existe, si oui l'utilise comme modèle, et sinon utilise /etc/dkms/template-dkms-mkrpm.spec.

* status : Affiche l'état des différents modules pour chaque version, noyau et architecture.

<code>[root@plop src]# dkms status
ipw2200, 1.0.4: added
slmodem, 2.9.10, 2.6.12-11mdk-i686-up-4GB, i586: installed
slmodem, 2.9.10, 2.6.12-12mdk-i686-up-4GB, i586: built
sysprof, 1.0, 2.6.12-12mdk-i686-up-4GB, i586: installed</code>

* match : Cette commande fort sympathique permet de compiler et installer pour un noyau donné tout les modules qui avaient été installés pour un autre noyau (spécifié par l'option --templatekernel). Par exemple, après exécution de dkms match --templatekernel 2.6.12-11mdk-i686-up-4GB -k 2.6.12-12mdk-i686-up-4GB, toutes les combinaisons module/version qui étaient installées pour le noyau 2.6.12-11mdk-i686-up-4GB le seront pour le noyau 2.6.12-12mdk-i686-up-4GB.
* mktarball : Crée une archive tar.gz pour le module et la version indiquées. Cette archive contiendra les sources et les modules précédemment compilés. Par défaut l'archive est créée pour le noyau utilisé actuellement. Si vous en souhaitez un (ou plusieurs) autre, vous pouvez l'indiquer en utilisant les options -k et -a. Cette commande dispose également de quelques options supplémentaires :
o --archive <fichier.tar.gz> : Permet de préciser le nom à donner à l'archive (ne pas indiquer de chemin, il sera toujours placé dans /var/lib/dkms/<module>/<version du module>/tarball/). Sans cette option, le fichier s'appelle <module>-<version du module>-<versions des noyaux>.dkms.tar.gz
o --binaries-only : Ne pas inclure les sources du module
o --sources-only : Ne pas inclure les modules pré compilés. L'archive s'appellera <module>-<version du module>-source-only.dkms.tar.gz, sauf si vous précisez un autre nom à l'aide de --archive

<code>[root@plop src]# dkms mktarball -m slmodem -v 2.9.10 -k 2.6.12-11mdk-i686-up-4GB -k 2.6.12-12mdk-i686-up-4GB
Marking modules for 2.6.12-11mdk-i686-up-4GB (i586) for archiving...
Marking modules for 2.6.12-12mdk-i686-up-4GB (i586) for archiving...

Marking /usr/src/slmodem-2.9.10 for archiving...

Tarball location: /var/lib/dkms/slmodem/2.9.10/tarball/slmodem-2.9.10-kernel2.6.12-11mdk-i686-up-4GB-i586-kernel2.6.12-12mdk-i686-up-4GB-i586.dkms.tar.gz

DKMS: mktarball Completed.</code>

* ldtarball : Importe une archive tar.gz créé à l'aide de l'action mktarball et spécifié à l'aide de l'option --archive.

Les fichiers sont importés dans l'arborescence de DKMS et pas dans celle du noyau, les modules sont donc au mieux dans l'état built(compilé) et il faut lancer ensuite la commande dkms install pour chacun d'eux.

Par ailleurs, si des fichiers existent déjà lors de l'import, un avertissement sera affiché et ils seront laissés tels quels. Si vous souhaitez que ces éventuels fichiers soient écrasés, il faut ajouter l'option --force.
* mkdriverdisk : Crée une disquette avec les pilotes pour permettre l'installation d'une distribution, c'est particulièrement utile lorsque le CD d'installation ne contient pas les pilotes pour un nouveau contrôleur disque.
o --size <taille de la disquette> : Cette option est utilisée par la commande mkdriverdisk pour décider de la taille de la disquette à créer. La valeur doit être un nombre entier de kilo-octets, divisible par 20, et vaut 1440 si cette option n'est pas précisée.
o --distrib <distribution> : Cette option obligatoire indique la distribution cible. Les valeurs actuellement supportées sont suse, UnitedLinux, redhat, redhat1 and redhat2. Red Hat supportant les disquettes de pilotes multi-architecture depuis la RHEL3, redhat1 force à utiliser l'ancien format, redhat2 force à utiliser le nouveau.
o --release <version> : Cette option est nécessaire si vous construisez une disquette pour SuSE ou UnitedLinux. Elle indique la version de la distribution, par exemple --distrib suse --release 9.1 indiquera que vous construisez la disquette pour une SuSE 9.1
Les options --binaries-only et --sources-only de mktarball peuvent également être utilisées.

=== Utilisation basique ===

Après vous avoir noyé sous les commandes et les options, je pense qu'un exemple d'utilisation classique est nécessaire pour vous persuader de la simplicité d'utilisation. Voici donc comment installer un module exemple, fourni sous la forme de exemple-1.0.tar.gz contenant un unique répertoire exemple-1.0 avec les sources du module et un dkms.conf.

<code>cd /usr/src
tar xzf /tmp/exemple-1.0.tar.gz
dkms add -m exemple -v 1.0
dkms build -m exemple -v 1.0
dkms install -m exemple -v 1.0</code>

Listing 1 : Ajout d'un pilote en utilisant DKMS

Si tout s'est bien passé, le module est compilé et installé, et modprobe exemple fonctionne ! Si cela ne s'est pas bien passé, c'est vraisemblablement lors de l'étape build, et vous pouvez essayer de déterminer le problème en allant lire le fichier /var/lib/dkms/exemple/1.0/build/make.log. Si vous n'avez pas les compétences pour cela, le plus simple est d'envoyer ce fichier à l'auteur du dkms.conf afin qu'il corrige l'erreur.

Un mode de distribution courant, que nous détaillerons plus loin, consiste à distribuer les sources et le dkms.conf sous la forme d'un package RPM et non pas d'un tar.gz. Dans ce cas, installer le package RPM suffit et exécutera automatiquement les différentes commandes.

== Mise en oeuvre de DKMS par un distributeur ==

=== Adaptation des sources ===
DKMS a besoin des sources du module dans le répertoire /usr/src/<nom du module>-<version du module>/ et d'un fichier dkms.conf dans ce même répertoire. Nous allons étudier la syntaxe de ce fichier sur un exemple classique avant de détailler toutes les options disponibles.

=== Exemple de dkms.conf pour l'ipw2200 1.0.4 ===

<code>PACKAGE_VERSION="1.0.4"
PACKAGE_NAME="ipw2200"

MAKE[0]="make -C ${kernel_source_dir} SUBDIRS=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build modules HOSTAP_SRC=${kernel_source_dir}/3rdparty/hostap/"
CLEAN="make -C ${kernel_source_dir} SUBDIRS=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build clean"

BUILT_MODULE_NAME[0]="$PACKAGE_NAME"
BUILT_MODULE_NAME[1]="ieee80211_crypt_ccmp"
BUILT_MODULE_NAME[2]="ieee80211_crypt"
BUILT_MODULE_NAME[3]="ieee80211_crypt_tkip"
BUILT_MODULE_NAME[4]="ieee80211_crypt_wep"
BUILT_MODULE_NAME[5]="ieee80211"
DEST_MODULE_LOCATION[0]="/kernel/drivers/net/wireless/ipw2200/"
DEST_MODULE_LOCATION[1]="/kernel/drivers/net/wireless/ipw2200/"
DEST_MODULE_LOCATION[2]="/kernel/drivers/net/wireless/ipw2200/"
DEST_MODULE_LOCATION[3]="/kernel/drivers/net/wireless/ipw2200/"
DEST_MODULE_LOCATION[4]="/kernel/drivers/net/wireless/ipw2200/"
DEST_MODULE_LOCATION[5]="/kernel/drivers/net/wireless/ipw2200/"

MODULES_CONF_ALIAS_TYPE[0]="eth"

REMAKE_INITRD="no"
AUTOINSTALL="yes"</code>

Listing 2: Exemple de dkms.conf pour le pilote ipw2200 version 1.0.4

Comme vous pouvez le voir ce fichier a une syntaxe très simple, une option par ligne sous la forme OPTION="valeur". Voyons maintenant plus précisément à quoi correspondent les options définies dans cet exemple.

PACKAGE_VERSION et PACKAGE_NAME ne méritent je pense aucune explication. Il est toutefois intéressant de noter que lors de la sortie d'une nouvelle version du module, la seule ligne à modifier dans le dkms.conf est en général PACKAGE_VERSION.

MAKE[0] contient la commande à exécuter pour compiler le module, elle peut utiliser de nombreuses variables, listées dans la section suivante. La majorité des modules peuvent se compiler avec la commande suivante : make -C ${kernel_source_dir} SUBDIRS=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build modules

CLEAN contient une commande permettant de nettoyer le répertoire de construction, elle est appelée avant et après la compilation du module.

Les 12 lignes suivantes indiquent les modules générés (ici il y en a 6) et ou il faut les installer. BUILT_MODULE_NAME[i] contient le nom du module numéro i (en commençant à 0) et DEST_MODULE_LOCATION[i] le chemin où installer le module numéro i. Le chemin est relatif à l'arborescence des modules du noyau concerné, /lib/modules/<version du noyau>.

L'option MODULES_CONF_ALIAS_TYPE[0]="eth" indique qu'il faudra ajouter dans /etc/modprobe.conf (ou modules.conf) un alias vers ce module qui s'appelera eth0 (ou eth1, eth2, ... selon ce qui est déjà pris).

REMAKE_INITRD="no" indique que ce pilote n'a pas besoin d'être dans l'initrd. L'initrd est l'image contenant tout les modules et commandes nécessaires pour accéder au disque dur, cette option a donc rarement besoin d'être à yes en dehors des pilotes de contrôleur disque.

AUTOINSTALL="yes" indique que l'on veut que ce module soit compilé et installé automatiquement lorsque l'on démarre sur un nouveau noyau.

=== Variables disponibles ===

Quelques variables peut être utilisées dans les options et les commandes comme vous pouvez le voir dans la commande MAKE[0] de l'exemple précédent. Ces variables sont définies par la configuration de DKMS ou par les options passées à la commande dkms.

* $kernelver : Cette variable contient la version du noyau pour laquelle le module est en train d'être construit. C'est particulièrement utile dans la définition de la commande MAKE, par exemple MAKE[0]="make INCLUDEDIR=/lib/modules/${kernelver}/build/include"
* $dkms_tree : Cette variable indique ou se trouve l'arbre DKMS sur le système local. Par défaut il s'agit de /var/lib/dkms, mais cette valeur ne doit pas être mise en dur dans les dkms.conf au cas ou l'utilisateur aurait changé cela sur son système (Un tel réglage se fait à l'aide de /etc/dkms/framework.conf ou en ajoutant l'option --dkmstree lors de l'appel, mais nous ne verrons pas ce genre d'utilisations avancées dans cette article).
* $source_tree : Cette variable indique ou DKMS stocke les sources des modules sur le système. Par défaut il s'agit de /usr/src, mais cette valeur ne doit pas être mise en dur dans les dkms.conf au cas ou l'utilisateur aurait changé cela sur son système (à l'aide de /etc/dkms/framework.conf ou en ajoutant l'option --sourcetree lors de l'appel).
* $kernel_source_dir : Cette variable contient le chemin vers les sources du kernel pour lequel on construit le module. Il s'agit en général de /lib/modules/$kernelver/build, à moins qu'un autre chemin ait été spécifié avec l'option --kernel-sourcedir

=== Options que l'on peut définir dans le fichier dkms.conf ===
Tout d'abord, le nom des options est sensible à la casse donc elles doivent être écrites en majuscules. Seules 4 options sont obligatoires :

* PACKAGE_NAME : le nom du package
* PACKAGE_VERSION : la version du package
* BUILT_MODULE_NAME[0] : le nom du module construit. S'il y en a plusieurs, ça sera BUILT_MODULE_NAME[1], BUILT_MODULE_NAME[2], ... Les modules non listés ici ne seront pas installés même s'il sont construit par la commande MAKE[0]
* DEST_MODULE_LOCATION[0] : l'emplacement ou installer le module numéro 0. Ce chemin est relatif au répertoire des modules, et sera par exemple "3rdparty". Il faut renseigner DEST_MODULE_LOCATION[#] pour chaque module listé dans BUILT_MODULE_NAME

De nombreuses autres options bien pratiques mais facultatives dont disponibles :

* MAKE[#] : la commande pour compiler le(s) modules. Voir l'explication de MAKE_MATCH pour la signification du numéro passé en paramètre. Cette option est facultative dans la mesure ou la commande standard de construction d'un module kernel sera utilisée si elle n'est pas définie.
* MAKE_MATCH[#] : cet ensemble d'options permet d'avoir une commande de construction différente en fonction des versions du kernel. Chacune contient une expression régulière qui sera comparée à la version du noyau. Le numéro de la dernière qui correspond indiquera le numéro de commande MAKE à utiliser.
* BUILT_MODULE_LOCATION[#] : le chemin relatif vers le module généré. Cela est nécessaire lorsque le module est généré dans un sous répertoire du répertoire de compilation.
* DEST_MODULE_NAME[#] : le nom a utiliser pour installer le module, s'il y a besoin de le renommer. L'extension (.o ou .ko) ne doit pas être spécifiée. Par défaut le nom original BUILT_MODULE_NAME[#] est conservé.
* MODULES_CONF_ALIAS_TYPE[#] : cette option indique pour chaque module quel alias créer dans /etc/modprobe.conf. DKMS calculera automatiquement le numéro de l'alias en fonction de ceux qui existent déjà. Par exemple si MODULES_CONF_ALIAS_TYPE[0] contient eth et que vous avez déjà eth0 et eth1 définis dans /etc/modprobe.conf, DKMS ajoutera un alias eth2 vers le module. Cette fonctionnalité est à utiliser avec précaution dans la mesure ou elle gère mal les cas complexes, comme par exemple les systèmes avec plusieurs cartes réseau utilisant le même module.
* MODULES_CONF_OBSOLETES[#] : cette option indique à DKMS quels modules vers lesquels pointent des alias dans /etc/modprobe.conf doivent être remplacés par ce nouveau module. Si il y en a plusieurs, les séparer par une virgule. Je pense que ce sera plus clair sur un exemple. Considérons le fichier modprobe.conf suivant :

<code>alias eth0 bcm4400
alias eth1 e1000</code>

Si l'on se contente des options suivantes, DKMS n'a aucun moyen de deviner que b44 et bcm4400 gèrent la même carte et un nouvel alias sera généré.

<code>BUILT_MODULE_NAME[0]="b44"
MODULES_CONF_ALIAS_TYPE[0]="eth"</code>

Le nouveau modprobe.conf contiendra donc :

<code>alias eth0 bcm4400
alias eth1 e1000
alias eth2 b44</code>

Si par contre on ajoute MODULES_CONF_OBSOLETES[0]="bcm4400", le nouveau modprobe.conf sera correct :

<code>alias eth0 b44
alias eth1 e1000</code>

* MODULES_CONF_OBSOLETE_ONLY[#] : Si cette option vaut yes, DKMS ne modifiera modprobe.conf que s'il trouve un alias vers un module obsolète à remplacer. Il n'y aura donc jamais de nouveaux alias de créés.
* STRIP[#] : Par défaut, les symboles de deboguage sont supprimés des modules à l'aide de strip -g. Positionner cette option à "no" pour l'un des modules permet de les conserver dans ce module.
* REMAKE_INITRD : Cette option indique, lorsque la première lettre est y ou Y, qu'il faut régénérer l'initrd après l'installation d'une nouvelle version du module. C'est surtout nécessaire pour les pilotes de contrôleur disque.
* MODULES_CONF[#] : Cette option permet d'indiquer des lignes à ajouter au fichier modprobe.conf. Lorsqu'une première version du module est installée sur l'un des noyaux, les lignes de MODULES_CONF sont ajoutées au fichier modprobe.conf (avant que l'initrd soit régénéré si REMAKE_INITRD est activé). Elles sont supprimées lorsque la dernière version est désinstallée. On peut imaginer par exemple dans le cas de l'ipw2200 MODULES_CONF[0]="options ipw2200 led=1".
* PATCH[#] : Cette option permet d'indiquer des patchs à appliquer sur les sources du pilote avant de le compiler. Tout les patchs doivent se trouver dans /usr/src/<module>-<version du module>/patches/ et sont appliqués avec patch -p1. Vous pouvez spécifier pour quels noyaux chaque patch doit être appliqué en utilisant l'option PATCH_MATCH ci-dessous.
* PATCH_MATCH[#] : Cette option sert à indiquer pour quels noyaux les patchs contenus dans le tableau PATCH doivent être appliqués. PATCH_MATCH[i] contient une expression régulière qui est comparés à la version du noyau cible pour décider si PATCH[i] doit être appliqué.
* AUTOINSTALL : Si cette option vaut "yes", le service dkms (/etc/rc.d/init.d/dkms) essayera automatiquement de construire et installer ce module sur le noyau sur lequel vous démarrez. Ce service ne fera toutefois rien si plusieurs versions du module sont présentes dans l'arbre DKMS, ce sera à vous de décider laquelle vous souhaitez.
* BUILD_EXCLUSIVE_KERNEL : Cette option permet d'indiquer une expression régulière décrivant les versions de noyau pour lesquelles DKMS est autorisé à construire votre module. Si vous essayez de construire le module pour un noyau ne correspondant pas à cette expression régulière, DKMS provoquera une erreur. Par exemple, si vous indiquez "^2.6.*", votre module ne pourra être construit que pour les noyaux 2.6 et une erreur se produira sur les 2.4.
* BUILD_EXCLUSIVE_ARCH : Cette option fonctionne comme BUILD_EXCLUSIVE_KERNEL mais limite l'architecture du noyau au lieu de sa version. Par exemple, si cette option vaut "i.86" votre module pourra être construit pour i386 ou i586 mais pas ppc, x86_64, ni s390.
* POST_ADD : Cette option indique le nom d'un script à exécuter après le traitement de la commande add. Le chemin doit être indiqué relativement aux sources du module.
* POST_BUILD : Cette option indique le nom d'un script à exécuter après le traitement de la commande build. Le chemin doit être indiqué relativement aux sources du module.
* POST_INSTALL : Cette option indique le nom d'un script à exécuter après le traitement de la commande install. Le chemin doit être indiqué relativement aux sources du module.
* POST_REMOVE : Cette option indique le nom d'un script à exécuter après le traitement de la commande remove. Le chemin doit être indiqué relativement aux sources du module.
* PRE_BUILD : Cette option indique le nom d'un script à exécuter avant le traitement de la commande build. Le chemin doit être indiqué relativement aux sources du module.

=== Intégration avec rpm ===

Les possibilités d'intégration de DKMS avec RPM sont doubles :

* Création manuelle de RPM contenant les sources et le dkms.conf ;
* Création automatique de rpm contant un module compilé à l'aide de dkms, et dont la gestion est faite par DKMS.

En ce qui concerne le premier cas, la création du RPM est assez simple si vous savez construire des RPM. Vous indiquez comme source le tar.gz des sources du module et dans la section %install vous copiez les sources vers /usr/src/<nom du module>-<version du module> et vous y écrivez le dkms.conf (Il est également possible de mettre le dkms.conf dans un fichier annexe et de l'inclure comme source, mais l'avoir inclus permet d'utiliser les macros RPM %name, %version, ... afin de créer rapidement un .spec pour un nouveau module). Ensuite vous indiquez en %post et %preun les commandes DKMS à invoquer (add, build et install en %post et remove en %preun).
Le modèle de fichier spec suivant pourra vous servir de base dans la majorité des cas.

<code>%define module_name rt2500

Name: dkms-%{module_name}
Version: 1.4.6.2
Release: 1mdk
Summary: DKMS-ready kernel-source for the RT2500 driver
License: GPL
URL: http://www.ralinktech.com/supp-1.htm
Source: http://www.ralinktech.com/drivers/Linux/RT2500-Linux-STA-%{version}.tar.bz2
Group: System/Kernel and hardware
Requires(pre): dkms
Requires(post): dkms
Buildroot: %{_tmppath}/%{name}-%{version}-root
Buildarch: noarch

%description
Driver for the Ralink RT2500 802.11g chipset

%prep
%setup -q -n RT2500-Linux-STA-%{version}
chmod 0755 Module/2.*.x

%build

%clean
rm -fr $RPM_BUILD_ROOT

%install
mkdir -p %{buildroot}/usr/src/%{module_name}-%{version}-%{release}
cp -a Module/* %{buildroot}/usr/src/%{module_name}-%{version}-%{release}
cp -af Module/2.6.x/Makefile %{buildroot}/usr/src/%{module_name}-%{version}-%{release}
cat > %{buildroot}/usr/src/%{module_name}-%{version}-%{release}/dkms.conf <<EOF

PACKAGE_VERSION="%{version}-%{release}"

# Items below here should not have to change with each driver version
PACKAGE_NAME="%{module_name}"
MAKE[0]="make -C \${kernel_source_dir} SUBDIRS=\${dkms_tree}/\${PACKAGE_NAME}/\${PACKAGE_VERSION}/build modules"
CLEAN="make -C \${kernel_source_dir} SUBDIRS=\${dkms_tree}/\${PACKAGE_NAME}/\${PACKAGE_VERSION}/build clean"

BUILT_MODULE_NAME[0]="\$PACKAGE_NAME"

DEST_MODULE_LOCATION[0]="/kernel/drivers/net/wireless/"

MODULES_CONF_ALIAS_TYPE[0]="ra"

REMAKE_INITRD="no"
AUTOINSTALL=yes

EOF

%post
dkms add -m %{module_name} -v %{version}-%{release} --rpm_safe_upgrade
dkms build -m %{module_name} -v %{version}-%{release} --rpm_safe_upgrade
dkms install -m %{module_name} -v %{version}-%{release} --rpm_safe_upgrade

%preun
dkms remove -m %{module_name} -v %{version}-%{release} --rpm_safe_upgrade --all ||:

%files
%defattr(-,root,root)
/usr/src/%{module_name}-%{version}-%{release}</code>

Listing 7: Exemple de fichier .spec pour un package DKMS

Il y a peu de remarques à faire sur ce fichier si ce n'est l'importance de ne pas oublier --rpm_safe_upgrade et surtout ||: dans le %preun qui permet que le rpm puisse être désinstallé même si le remove échoue (par exemple parce que le build avait échoué donc le module n'est pas installé).

Pour ce qui est du deuxième cas (création de RPM binaires), c'est encore plus simple, il suffit de compiler le module puis d'utiliser dkms mkrpm en précisant le module, sa version et le ou les noyaux qui vous intéressent. Contrairement aux RPM créés à la main comme précédemment, cette méthode nécessite par contre d'être root sur la machine générant le package (ou d'avoir par exemple un sudo sur la commande dkms).

== Avantages et inconvénients ==

Pour finir, voici une petite liste des avantages et des inconvénients que je vois à utiliser DKMS. Cette liste vous aidera probablement à décider si vous souhaiter essayer de gérer vos pilotes additionnels avec DKMS.

=== Avantages ===

* Il n'y a plus besoin de se préoccuper de ses pilotes additionnels lorsque l'on met à jour son noyau ;
* Il est beaucoup plus facile de distribuer des pilotes (y compris les modules propriétaires avec une couche libre de jonction). Avec un seul paquetage à installer l'utilisateur n'a rien à faire pour que ça marche sur son noyau ;
* Il est beaucoup plus facile (et léger) de distribuer des correctifs sur les noyaux. Il n'y a plus besoin de distribuer un nouveau noyau lorsque le problème n'affecte qu'un module, DKMS gérera très bien le remplacement du module original, même si celui-ci n'était initialement pas installé avec DKMS ;
* Il est possible d'avoir plusieurs versions du module présentes sur sa machine simultanément et de basculer entres elles à l'aide de la commande dkms, ce qui est très pratique pour des tests ;
* Il est possible de distribuer le module avec la partie userspace associée plutôt qu'avec le noyau, ce qui permet d'éviter les problèmes de désynchronisation.

=== Inconvénients ===

* Le fonctionnement classique de DKMS implique la présence d'un compilateur sur la machine, ce qui est en particulier problématique pour la sécurité des serveurs. Toutefois, DKMS reste utile sans compilateur sur le serveur pour générer depuis une autre machine un RPM contenant la nouvelle version compilée du module et pouvoir ainsi facilement mettre à jour toutes ses machines.
* De même DKMS a besoin des sources du noyau, ce qui occupe beaucoup d'espace disque.
* La recompilation dynamique par un service au démarrage n'est pas adaptée pour les modules nécessaires plus tôt (pilotes de contrôleur disque par exemple), il faut donc dans ce cas s'assurer de faire compiler à DKMS le pilote pour le nouveau noyau avant de redémarrer. Cet inconvénient n'en est toutefois pas réellement un dans la mesure où le problème est le même lorsque le module en question est compilé à la main sans DKMS.
* DKMS est basé sur RPM et ne fonctionnera donc que sur des distributions utilisant RPM (RedHat, Mandriva, SuSE, ...). L'utilisation de rpm est pourtant très localisée (par exemple détection de l'architecture du noyau cible) et il devrait être assez facile de s'en passer.
* DKMS ne prend pour le moment pas en compte le fichier .config du noyau mais celui par défaut fourni par la distribution pour la famille de noyaux (smp, 64G, ...).

=== Références ===

* [http://linux.dell.com/dkms/dkms.html http://linux.dell.com/dkms/dkms.html]
* [http://www.linuxjournal.com/article/6896 http://www.linuxjournal.com/article/6896]
* [http://linux.dell.com/dkms/dkms-ols2004.pdf http://linux.dell.com/dkms/dkms-ols2004.pdf]
* [http://www.dell.com/downloads/global/power/1q04-ler.pdf http://www.dell.com/downloads/global/power/1q04-ler.pdf]
* [http://linux.dell.com/dkms/dkms-LWE-Boston2005.pdf http://linux.dell.com/dkms/dkms-LWE-Boston2005.pdf]

Pascal Terjan <pterjan at mandriva dot com> 
Cet article a été initialement publié dans le GNU/Linux Magazine 80 de Février 2006

{{Copy|2006|Pascal Terjan|LDL}}

DKMS

2007-04-27T19:29:45Z

Pterjan : ajout de tt autour de quelques chemins

[[Category:Configurer votre noyau]]

= DKMS : Donnez l'indépendance à vos pilotes =

== Contexte ==

Sous Linux, les pilotes (le logiciel qui permet au système d'exploitation de communiquer avec le matériel) peuvent soit être directement inclus dans le noyau soit être disponibles sous la forme de modules à charger dans le noyau. Un tel module est compilé pour un noyau particulier et ne peut être utilisé sur un autre.

En ce qui concerne les pilotes libres, cela ne pose en général aucun problème car ils sont soit livrés avec votre noyau, soit compilés en même temps que le noyau que vous compilez vous-même.

Dans le cas de pilotes non libres (comme ceux de nVidia ou ATI) ou de pilotes distribués séparément et que vous compilez à la main, le pilote doit être recompilé à chaque version de noyau, ce qui peut devenir fastidieux.

De plus, si vous souhaitez utiliser les pilotes distribués par votre distributeur Linux, vous devez attendre que les pilotes soient recompilés pour le nouveau noyau, et ne pouvez espérer qu'ils fonctionnent avec un noyau que vous auriez personnalisé.

== Objectifs de DKMS ==

DKMS (Dynamic Kernel Module Support ou en français Gestion Dynamique des Modules Noyau) est un système très simple conçu par Dell et permettant de compiler dynamiquement et facilement les modules noyau pour tous les noyaux de votre système. Ce système est à la base conçu pour faciliter à Dell la distribution de pilotes Linux et de correctifs.

Cela évite à la fois aux éditeurs et aux utilisateurs de devoir passer par des mises à jour du noyau pour une correction sur un pilote particulier et permet de distribuer un pilote supplémentaire sous la forme d'un seul paquetage quel que soit le noyau de l'utilisateur.

Cet article a pour but de présenter ce système, à la fois aux développeurs et distributeurs de modules noyau qui pourraient l'utiliser pour faciliter la vie à leurs utilisateurs, et aux utilisateurs qui peuvent également l'utiliser tout seuls.

== Comment ça marche ==

Le principe de DKMS est très simple. À condition que le module soit prévu pour être utilisé avec DKMS (fourniture d'un dkms.conf), l'utilisation d'un nouveau module en passant par DKMS consiste à exécuter les 3 étapes suivantes :

* Insertion dans l'arbre DKMS (action add)
* Compilation pour le noyau (action build)
* Installation avec les autres modules du noyau (action install)

Ces étapes sont séparées et ne sont pas forcement toutes réalisées à la suite. La figure 1 montre les différents états d'un module dans le système DKMS, et les transitions possibles entre ces états à l'aide des actions de la commande dkms.

Figure 1 : États d'un module dans le système DKMS

=== Structure sur le disque ===

Afin de bien séparer la gestion des différentes versions de module et de la version du noyau, le fonctionnement de DKMS se base sur la présence de 3 arborescences :

* Les sources des modules, dans <tt>/usr/src</tt>
* L'arborescence des modules du noyau <tt>/lib/modules</tt> : DKMS y remplacera ou ajoutera les modules que l'on va lui faire gérer
* L'arborescence de DKMS <tt>/var/lib/dkms</tt>, contenant :
o Les répertoire ou seront construit les modules
o Les modules originaux sauvegardés
o Les modules générés par DKMS

Les chemins indiqués sont ceux par défaut et il est possible de les modifier dans <tt>/etc/dkms/framework.conf</tt> mais nous supposerons dans le reste de l'article que les valeurs par défaut ont été conservées.

== Mise en oeuvre de DKMS par un utilisateur ==

=== La commande dkms ===

La gestion des modules au sein du système DKMS se fait à l'aide de la commande dkms. Cette commande a une syntaxe très simple : dkms <action> [options]
Les actions et les options sont par contre plutôt nombreuses et même si je vous les explique ci-dessous, seules les principales devraient être utiles à la majorité d'entre vous (à savoir: add, build, install, remove en ce qui concerne les actions et -m, -v et --all en ce qui concerne les options).

Voici tout d'abord la liste des options génériques s'appliquant à diverses commandes, celles restreintes à une commande particulière seront expliquées dans la description de celle-ci.

* -m <module> : Le nom du module sur lequel effectuer l'action.
* -v <version du module> : La version du module sur laquelle effectuer l'action.
* -k <version du noyau> : La version du noyau sur laquelle effectuer l'action. Il est possible pour certaines actions de spécifier plusieurs versions du noyau en utilisant plusieurs fois -k, si l'action spécifiée ne le supporte pas une erreur sera émise.
* -a <architecture> : L'architecture pour laquelle effectuer l'action. Si cette option n'est pas précisée, l'architecture choisie est celle indiquée par uname -m. Il est possible de répéter cette option afin d'indiquer plusieurs architectures, mais dans ce cas il doit y avoir exactement autant de -k que de -a. Chaque noyau sera associé à l'architecture de position identique. Par exemple si vous indiquez -k noyau1 -k noyau2 -a i386 -k noyau3 -a i586 -a x86_64, DKMS comprendra que noyau1 est en i386, noyau2 est en i586 et noyau3 est en x86_64.
* --all : Indique d'appliquer l'action pour toutes les versions de noyau et toutes les architectures pour lesquelles le module a été compilé. Cela est particulièrement utile pour l'action remove.
* --rpm_safe_upgrade : Cette option est nécessaire pour les commandes DKMS appelées à l'intérieur d'un RPM. Cela évite des problèmes lors de mise à jour d'un RPM à un autre contenant la même version du module. Cela évite aussi les problèmes d'interblocage dus au système de verrous de rpm.

Nous allons maintenant étudier ce que permet de faire DKMS à travers le parcours des actions que l'on peut faire effectuer à la commande dkms.

* add : Ajoute à l'arbre des sources de DKMS une version d'un module (les options -m et -v sont donc obligatoires, c'est le cas pour la majorité des commandes). Les sources du module doivent être précédemment placées dans /usr/src/<module>-<version du module>/ et contenir un fichier dkms.conf. Si le fichier dkms.conf ne se trouve pas dans /usr/src/<module>-<version du module>/, il faut ajouter l'option -c pour indiquer son chemin.

<code>[root@plop src]# dkms add -m exemple -v 0.9.0 -c /tmp/dkms.conf
Creating symlink /var/lib/dkms/exemple/0.9.0/source ->
/usr/src/exemple-0.9.0

DKMS: add Completed.</code>

* remove : Supprime une version d'un module. Il faut en plus des options -m et -v, soit préciser une version de noyau avec l'option -k, soit demander à supprimer le module de tout les noyaux pour lesquelles cette version avait été compilée, avec l'option --all.

Si le module avait été installé, il est d'abord désinstallé (comme si on avait appelé l'action uninstall) et d'éventuelles versions précédentes sont réinstallées. Après un remove, le module n'est plus du tout connu de DKMS et il faut recommencer à l'étape add.

<code>[root@plop src]# dkms remove -m exemple -v 0.9.0 --all

------------------------------
Deleting module version: 0.9.0
completely from the DKMS tree.
------------------------------
Done.</code>

* build : Compile une version d'un module pour le noyau indiqué avec l'option -k ou pour le noyau utilisé actuellement si aucun n'est précisé. En cas d'erreurs lors de la compilation, il est utile de savoir que celle-ci se déroule dans /var/lib/dkms/<module>/<version du module>/build/ et que tout ce qui est affiché pendant la compilation est enregistré dans un fichier make.log dans ce même répertoire.

La commande build accepte quelques options facultatives :
o --config <fichier .config du noyau> : Cette option permet d'indiquer à la commande build ou trouver le fichier .config si celui-ci n'est pas à l'emplacement standard de la distribution ou n'a pas le nom habituel.
o --no-prepare-kernel : Cette option demande à DKMS de ne pas préparer les sources du noyau avant de compiler un module pour lui. Il est recommandé de ne pas utiliser cette option si l'on souhaite que les modules soient correctement construits.
o --no-clean-kernel : Cette option demande à DKMS de ne pas nettoyer les sources du noyau après avoir compilé un module.
o --kernelsourcedir <chemin vers les sources du noyau> : Cette option permet d'indiquer l'emplacement des sources du noyau lorsqu'elles ne se trouvent pas dans /lib/modules/<version du noyau>/build.

<code>[root@plop src]# dkms build -m slmodem -v 2.9.10 -k 2.6.12-12mdk-i686-up-4GB

Preparing kernel 2.6.12-12mdk-i686-up-4GB for module build:
(This is not compiling a kernel, only just preparing kernel symbols)
Storing current .config to be restored when complete
Running Generic preparation routine
make mrproper.........
using /boot/config-2.6.12-12mdk-i686-up-4GB
make oldconfig......
make prepare-all......

Building module:
cleaning build area....
make KERNELRELEASE=2.6.12-12mdk-i686-up-4GB KERNEL_DIR=/lib/modules/2.6.12-12mdk-i686-up-4GB/build drivers....
cleaning build area....
cleaning kernel tree (make mrproper)....

DKMS: build Completed.</code>

* install : Installe une version d'un module dans l'arborescence du noyau indiqué (ou du noyau utilisé actuellement si aucun n'est précisé par l'option -k). Cette version doit précédemment avoir été compilée pour le noyau en question à l'aide de l'action build.

Lors de la première installation d'une version d'un module donné sur un noyau donné, DKMS cherche si ce module existait déjà avec ce noyau et le sauvegarde pour pouvoir le réinstaller lorsque l'on demandera à DKMS de désinstaller la nouvelle version. Pour information, la version originale est sauvée dans /var/lib/dkms/<module>/original_module/<version du noyau>/<architecture>/

<code>[root@plop src]# dkms install -m slmodem -v 2.9.10 -k 2.6.12-12mdk-i686-up-4GB
Running module version sanity check.

slamr.ko.gz:
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/2.6.12-12mdk-i686-up-4GB/kernel/drivers/char/

slusb.ko.gz:
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/2.6.12-12mdk-i686-up-4GB/kernel/drivers/char/

depmod.....

DKMS: install Completed.</code>

* uninstall : Désinstalle une version d'un module pour une version du noyau (celle précisée par l'option -k ou la version utilisée actuellement si aucune n'est précisée). Cette commande ne gère pas l'option --all donc il vous faudra désinstaller pour chaque noyau séparément.

<code>[root@plop src]# dkms uninstall -m slmodem -v 2.9.10 -k 2.6.12-12mdk-i686-up-4GB

-------- Uninstall Beginning --------
Module: slmodem
Version: 2.9.10
Kernel: 2.6.12-12mdk-i686-up-4GB (i586)
-------------------------------------

Status: Before uninstall, this module version was ACTIVE on this kernel.

slamr.ko.gz:
- Uninstallation
- Deleting from: /lib/modules/2.6.12-12mdk-i686-up-4GB/kernel/drivers/char/
- Original module
- No original module was found for this module on this kernel.
- Use the dkms install command to reinstall any previous module version.

slusb.ko.gz:
- Uninstallation
- Deleting from: /lib/modules/2.6.12-12mdk-i686-up-4GB/kernel/drivers/char/
- Original module
- No original module was found for this module on this kernel.
- Use the dkms install command to reinstall any previous module version.

DKMS: uninstall Completed.</code>

* mkrpm : Génére un RPM pour un couple module/version donné. Si vous désirez que le RPM ne contienne que les sources (et donc que les modules soient compilés lors de l'installation), vous devez ajouter l'option --source-only. Sinon, le choix des modules à distribuer se fait à l'aide de -k et -a, comme pour les autres actions.

Si vous maîtrisez la création de RPM et souhaitez personnaliser ce qui est généré, sachez que DKMS regarde d'abord si /usr/src/<module>-<version du module>/<module>-dkms-mkrpm.spec existe, si oui l'utilise comme modèle, et sinon utilise /etc/dkms/template-dkms-mkrpm.spec.

* status : Affiche l'état des différents modules pour chaque version, noyau et architecture.

<code>[root@plop src]# dkms status
ipw2200, 1.0.4: added
slmodem, 2.9.10, 2.6.12-11mdk-i686-up-4GB, i586: installed
slmodem, 2.9.10, 2.6.12-12mdk-i686-up-4GB, i586: built
sysprof, 1.0, 2.6.12-12mdk-i686-up-4GB, i586: installed</code>

* match : Cette commande fort sympathique permet de compiler et installer pour un noyau donné tout les modules qui avaient été installés pour un autre noyau (spécifié par l'option --templatekernel). Par exemple, après exécution de dkms match --templatekernel 2.6.12-11mdk-i686-up-4GB -k 2.6.12-12mdk-i686-up-4GB, toutes les combinaisons module/version qui étaient installées pour le noyau 2.6.12-11mdk-i686-up-4GB le seront pour le noyau 2.6.12-12mdk-i686-up-4GB.
* mktarball : Crée une archive tar.gz pour le module et la version indiquées. Cette archive contiendra les sources et les modules précédemment compilés. Par défaut l'archive est créée pour le noyau utilisé actuellement. Si vous en souhaitez un (ou plusieurs) autre, vous pouvez l'indiquer en utilisant les options -k et -a. Cette commande dispose également de quelques options supplémentaires :
o --archive <fichier.tar.gz> : Permet de préciser le nom à donner à l'archive (ne pas indiquer de chemin, il sera toujours placé dans /var/lib/dkms/<module>/<version du module>/tarball/). Sans cette option, le fichier s'appelle <module>-<version du module>-<versions des noyaux>.dkms.tar.gz
o --binaries-only : Ne pas inclure les sources du module
o --sources-only : Ne pas inclure les modules pré compilés. L'archive s'appellera <module>-<version du module>-source-only.dkms.tar.gz, sauf si vous précisez un autre nom à l'aide de --archive

<code>[root@plop src]# dkms mktarball -m slmodem -v 2.9.10 -k 2.6.12-11mdk-i686-up-4GB -k 2.6.12-12mdk-i686-up-4GB
Marking modules for 2.6.12-11mdk-i686-up-4GB (i586) for archiving...
Marking modules for 2.6.12-12mdk-i686-up-4GB (i586) for archiving...

Marking /usr/src/slmodem-2.9.10 for archiving...

Tarball location: /var/lib/dkms/slmodem/2.9.10/tarball/slmodem-2.9.10-kernel2.6.12-11mdk-i686-up-4GB-i586-kernel2.6.12-12mdk-i686-up-4GB-i586.dkms.tar.gz

DKMS: mktarball Completed.</code>

* ldtarball : Importe une archive tar.gz créé à l'aide de l'action mktarball et spécifié à l'aide de l'option --archive.

Les fichiers sont importés dans l'arborescence de DKMS et pas dans celle du noyau, les modules sont donc au mieux dans l'état built(compilé) et il faut lancer ensuite la commande dkms install pour chacun d'eux.

Par ailleurs, si des fichiers existent déjà lors de l'import, un avertissement sera affiché et ils seront laissés tels quels. Si vous souhaitez que ces éventuels fichiers soient écrasés, il faut ajouter l'option --force.
* mkdriverdisk : Crée une disquette avec les pilotes pour permettre l'installation d'une distribution, c'est particulièrement utile lorsque le CD d'installation ne contient pas les pilotes pour un nouveau contrôleur disque.
o --size <taille de la disquette> : Cette option est utilisée par la commande mkdriverdisk pour décider de la taille de la disquette à créer. La valeur doit être un nombre entier de kilo-octets, divisible par 20, et vaut 1440 si cette option n'est pas précisée.
o --distrib <distribution> : Cette option obligatoire indique la distribution cible. Les valeurs actuellement supportées sont suse, UnitedLinux, redhat, redhat1 and redhat2. Red Hat supportant les disquettes de pilotes multi-architecture depuis la RHEL3, redhat1 force à utiliser l'ancien format, redhat2 force à utiliser le nouveau.
o --release <version> : Cette option est nécessaire si vous construisez une disquette pour SuSE ou UnitedLinux. Elle indique la version de la distribution, par exemple --distrib suse --release 9.1 indiquera que vous construisez la disquette pour une SuSE 9.1
Les options --binaries-only et --sources-only de mktarball peuvent également être utilisées.

=== Utilisation basique ===

Après vous avoir noyé sous les commandes et les options, je pense qu'un exemple d'utilisation classique est nécessaire pour vous persuader de la simplicité d'utilisation. Voici donc comment installer un module exemple, fourni sous la forme de exemple-1.0.tar.gz contenant un unique répertoire exemple-1.0 avec les sources du module et un dkms.conf.

<code>cd /usr/src
tar xzf /tmp/exemple-1.0.tar.gz
dkms add -m exemple -v 1.0
dkms build -m exemple -v 1.0
dkms install -m exemple -v 1.0</code>

Listing 1 : Ajout d'un pilote en utilisant DKMS

Si tout s'est bien passé, le module est compilé et installé, et modprobe exemple fonctionne ! Si cela ne s'est pas bien passé, c'est vraisemblablement lors de l'étape build, et vous pouvez essayer de déterminer le problème en allant lire le fichier /var/lib/dkms/exemple/1.0/build/make.log. Si vous n'avez pas les compétences pour cela, le plus simple est d'envoyer ce fichier à l'auteur du dkms.conf afin qu'il corrige l'erreur.

Un mode de distribution courant, que nous détaillerons plus loin, consiste à distribuer les sources et le dkms.conf sous la forme d'un package RPM et non pas d'un tar.gz. Dans ce cas, installer le package RPM suffit et exécutera automatiquement les différentes commandes.

== Mise en oeuvre de DKMS par un distributeur ==

=== Adaptation des sources ===
DKMS a besoin des sources du module dans le répertoire /usr/src/<nom du module>-<version du module>/ et d'un fichier dkms.conf dans ce même répertoire. Nous allons étudier la syntaxe de ce fichier sur un exemple classique avant de détailler toutes les options disponibles.

=== Exemple de dkms.conf pour l'ipw2200 1.0.4 ===

<code>PACKAGE_VERSION="1.0.4"
PACKAGE_NAME="ipw2200"

MAKE[0]="make -C ${kernel_source_dir} SUBDIRS=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build modules HOSTAP_SRC=${kernel_source_dir}/3rdparty/hostap/"
CLEAN="make -C ${kernel_source_dir} SUBDIRS=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build clean"

BUILT_MODULE_NAME[0]="$PACKAGE_NAME"
BUILT_MODULE_NAME[1]="ieee80211_crypt_ccmp"
BUILT_MODULE_NAME[2]="ieee80211_crypt"
BUILT_MODULE_NAME[3]="ieee80211_crypt_tkip"
BUILT_MODULE_NAME[4]="ieee80211_crypt_wep"
BUILT_MODULE_NAME[5]="ieee80211"
DEST_MODULE_LOCATION[0]="/kernel/drivers/net/wireless/ipw2200/"
DEST_MODULE_LOCATION[1]="/kernel/drivers/net/wireless/ipw2200/"
DEST_MODULE_LOCATION[2]="/kernel/drivers/net/wireless/ipw2200/"
DEST_MODULE_LOCATION[3]="/kernel/drivers/net/wireless/ipw2200/"
DEST_MODULE_LOCATION[4]="/kernel/drivers/net/wireless/ipw2200/"
DEST_MODULE_LOCATION[5]="/kernel/drivers/net/wireless/ipw2200/"

MODULES_CONF_ALIAS_TYPE[0]="eth"

REMAKE_INITRD="no"
AUTOINSTALL="yes"</code>

Listing 2: Exemple de dkms.conf pour le pilote ipw2200 version 1.0.4

Comme vous pouvez le voir ce fichier a une syntaxe très simple, une option par ligne sous la forme OPTION="valeur". Voyons maintenant plus précisément à quoi correspondent les options définies dans cet exemple.

PACKAGE_VERSION et PACKAGE_NAME ne méritent je pense aucune explication. Il est toutefois intéressant de noter que lors de la sortie d'une nouvelle version du module, la seule ligne à modifier dans le dkms.conf est en général PACKAGE_VERSION.

MAKE[0] contient la commande à exécuter pour compiler le module, elle peut utiliser de nombreuses variables, listées dans la section suivante. La majorité des modules peuvent se compiler avec la commande suivante : make -C ${kernel_source_dir} SUBDIRS=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build modules

CLEAN contient une commande permettant de nettoyer le répertoire de construction, elle est appelée avant et après la compilation du module.

Les 12 lignes suivantes indiquent les modules générés (ici il y en a 6) et ou il faut les installer. BUILT_MODULE_NAME[i] contient le nom du module numéro i (en commençant à 0) et DEST_MODULE_LOCATION[i] le chemin où installer le module numéro i. Le chemin est relatif à l'arborescence des modules du noyau concerné, /lib/modules/<version du noyau>.

L'option MODULES_CONF_ALIAS_TYPE[0]="eth" indique qu'il faudra ajouter dans /etc/modprobe.conf (ou modules.conf) un alias vers ce module qui s'appelera eth0 (ou eth1, eth2, ... selon ce qui est déjà pris).

REMAKE_INITRD="no" indique que ce pilote n'a pas besoin d'être dans l'initrd. L'initrd est l'image contenant tout les modules et commandes nécessaires pour accéder au disque dur, cette option a donc rarement besoin d'être à yes en dehors des pilotes de contrôleur disque.

AUTOINSTALL="yes" indique que l'on veut que ce module soit compilé et installé automatiquement lorsque l'on démarre sur un nouveau noyau.

=== Variables disponibles ===

Quelques variables peut être utilisées dans les options et les commandes comme vous pouvez le voir dans la commande MAKE[0] de l'exemple précédent. Ces variables sont définies par la configuration de DKMS ou par les options passées à la commande dkms.

* $kernelver : Cette variable contient la version du noyau pour laquelle le module est en train d'être construit. C'est particulièrement utile dans la définition de la commande MAKE, par exemple MAKE[0]="make INCLUDEDIR=/lib/modules/${kernelver}/build/include"
* $dkms_tree : Cette variable indique ou se trouve l'arbre DKMS sur le système local. Par défaut il s'agit de /var/lib/dkms, mais cette valeur ne doit pas être mise en dur dans les dkms.conf au cas ou l'utilisateur aurait changé cela sur son système (Un tel réglage se fait à l'aide de /etc/dkms/framework.conf ou en ajoutant l'option --dkmstree lors de l'appel, mais nous ne verrons pas ce genre d'utilisations avancées dans cette article).
* $source_tree : Cette variable indique ou DKMS stocke les sources des modules sur le système. Par défaut il s'agit de /usr/src, mais cette valeur ne doit pas être mise en dur dans les dkms.conf au cas ou l'utilisateur aurait changé cela sur son système (à l'aide de /etc/dkms/framework.conf ou en ajoutant l'option --sourcetree lors de l'appel).
* $kernel_source_dir : Cette variable contient le chemin vers les sources du kernel pour lequel on construit le module. Il s'agit en général de /lib/modules/$kernelver/build, à moins qu'un autre chemin ait été spécifié avec l'option --kernel-sourcedir

=== Options que l'on peut définir dans le fichier dkms.conf ===
Tout d'abord, le nom des options est sensible à la casse donc elles doivent être écrites en majuscules. Seules 4 options sont obligatoires :

* PACKAGE_NAME : le nom du package
* PACKAGE_VERSION : la version du package
* BUILT_MODULE_NAME[0] : le nom du module construit. S'il y en a plusieurs, ça sera BUILT_MODULE_NAME[1], BUILT_MODULE_NAME[2], ... Les modules non listés ici ne seront pas installés même s'il sont construit par la commande MAKE[0]
* DEST_MODULE_LOCATION[0] : l'emplacement ou installer le module numéro 0. Ce chemin est relatif au répertoire des modules, et sera par exemple "3rdparty". Il faut renseigner DEST_MODULE_LOCATION[#] pour chaque module listé dans BUILT_MODULE_NAME

De nombreuses autres options bien pratiques mais facultatives dont disponibles :

* MAKE[#] : la commande pour compiler le(s) modules. Voir l'explication de MAKE_MATCH pour la signification du numéro passé en paramètre. Cette option est facultative dans la mesure ou la commande standard de construction d'un module kernel sera utilisée si elle n'est pas définie.
* MAKE_MATCH[#] : cet ensemble d'options permet d'avoir une commande de construction différente en fonction des versions du kernel. Chacune contient une expression régulière qui sera comparée à la version du noyau. Le numéro de la dernière qui correspond indiquera le numéro de commande MAKE à utiliser.
* BUILT_MODULE_LOCATION[#] : le chemin relatif vers le module généré. Cela est nécessaire lorsque le module est généré dans un sous répertoire du répertoire de compilation.
* DEST_MODULE_NAME[#] : le nom a utiliser pour installer le module, s'il y a besoin de le renommer. L'extension (.o ou .ko) ne doit pas être spécifiée. Par défaut le nom original BUILT_MODULE_NAME[#] est conservé.
* MODULES_CONF_ALIAS_TYPE[#] : cette option indique pour chaque module quel alias créer dans /etc/modprobe.conf. DKMS calculera automatiquement le numéro de l'alias en fonction de ceux qui existent déjà. Par exemple si MODULES_CONF_ALIAS_TYPE[0] contient eth et que vous avez déjà eth0 et eth1 définis dans /etc/modprobe.conf, DKMS ajoutera un alias eth2 vers le module. Cette fonctionnalité est à utiliser avec précaution dans la mesure ou elle gère mal les cas complexes, comme par exemple les systèmes avec plusieurs cartes réseau utilisant le même module.
* MODULES_CONF_OBSOLETES[#] : cette option indique à DKMS quels modules vers lesquels pointent des alias dans /etc/modprobe.conf doivent être remplacés par ce nouveau module. Si il y en a plusieurs, les séparer par une virgule. Je pense que ce sera plus clair sur un exemple. Considérons le fichier modprobe.conf suivant :

<code>alias eth0 bcm4400
alias eth1 e1000</code>

Si l'on se contente des options suivantes, DKMS n'a aucun moyen de deviner que b44 et bcm4400 gèrent la même carte et un nouvel alias sera généré.

<code>BUILT_MODULE_NAME[0]="b44"
MODULES_CONF_ALIAS_TYPE[0]="eth"</code>

Le nouveau modprobe.conf contiendra donc :

<code>alias eth0 bcm4400
alias eth1 e1000
alias eth2 b44</code>

Si par contre on ajoute MODULES_CONF_OBSOLETES[0]="bcm4400", le nouveau modprobe.conf sera correct :

<code>alias eth0 b44
alias eth1 e1000</code>

* MODULES_CONF_OBSOLETE_ONLY[#] : Si cette option vaut yes, DKMS ne modifiera modprobe.conf que s'il trouve un alias vers un module obsolète à remplacer. Il n'y aura donc jamais de nouveaux alias de créés.
* STRIP[#] : Par défaut, les symboles de deboguage sont supprimés des modules à l'aide de strip -g. Positionner cette option à "no" pour l'un des modules permet de les conserver dans ce module.
* REMAKE_INITRD : Cette option indique, lorsque la première lettre est y ou Y, qu'il faut régénérer l'initrd après l'installation d'une nouvelle version du module. C'est surtout nécessaire pour les pilotes de contrôleur disque.
* MODULES_CONF[#] : Cette option permet d'indiquer des lignes à ajouter au fichier modprobe.conf. Lorsqu'une première version du module est installée sur l'un des noyaux, les lignes de MODULES_CONF sont ajoutées au fichier modprobe.conf (avant que l'initrd soit régénéré si REMAKE_INITRD est activé). Elles sont supprimées lorsque la dernière version est désinstallée. On peut imaginer par exemple dans le cas de l'ipw2200 MODULES_CONF[0]="options ipw2200 led=1".
* PATCH[#] : Cette option permet d'indiquer des patchs à appliquer sur les sources du pilote avant de le compiler. Tout les patchs doivent se trouver dans /usr/src/<module>-<version du module>/patches/ et sont appliqués avec patch -p1. Vous pouvez spécifier pour quels noyaux chaque patch doit être appliqué en utilisant l'option PATCH_MATCH ci-dessous.
* PATCH_MATCH[#] : Cette option sert à indiquer pour quels noyaux les patchs contenus dans le tableau PATCH doivent être appliqués. PATCH_MATCH[i] contient une expression régulière qui est comparés à la version du noyau cible pour décider si PATCH[i] doit être appliqué.
* AUTOINSTALL : Si cette option vaut "yes", le service dkms (/etc/rc.d/init.d/dkms) essayera automatiquement de construire et installer ce module sur le noyau sur lequel vous démarrez. Ce service ne fera toutefois rien si plusieurs versions du module sont présentes dans l'arbre DKMS, ce sera à vous de décider laquelle vous souhaitez.
* BUILD_EXCLUSIVE_KERNEL : Cette option permet d'indiquer une expression régulière décrivant les versions de noyau pour lesquelles DKMS est autorisé à construire votre module. Si vous essayez de construire le module pour un noyau ne correspondant pas à cette expression régulière, DKMS provoquera une erreur. Par exemple, si vous indiquez "^2.6.*", votre module ne pourra être construit que pour les noyaux 2.6 et une erreur se produira sur les 2.4.
* BUILD_EXCLUSIVE_ARCH : Cette option fonctionne comme BUILD_EXCLUSIVE_KERNEL mais limite l'architecture du noyau au lieu de sa version. Par exemple, si cette option vaut "i.86" votre module pourra être construit pour i386 ou i586 mais pas ppc, x86_64, ni s390.
* POST_ADD : Cette option indique le nom d'un script à exécuter après le traitement de la commande add. Le chemin doit être indiqué relativement aux sources du module.
* POST_BUILD : Cette option indique le nom d'un script à exécuter après le traitement de la commande build. Le chemin doit être indiqué relativement aux sources du module.
* POST_INSTALL : Cette option indique le nom d'un script à exécuter après le traitement de la commande install. Le chemin doit être indiqué relativement aux sources du module.
* POST_REMOVE : Cette option indique le nom d'un script à exécuter après le traitement de la commande remove. Le chemin doit être indiqué relativement aux sources du module.
* PRE_BUILD : Cette option indique le nom d'un script à exécuter avant le traitement de la commande build. Le chemin doit être indiqué relativement aux sources du module.

=== Intégration avec rpm ===

Les possibilités d'intégration de DKMS avec RPM sont doubles :

* Création manuelle de RPM contenant les sources et le dkms.conf ;
* Création automatique de rpm contant un module compilé à l'aide de dkms, et dont la gestion est faite par DKMS.

En ce qui concerne le premier cas, la création du RPM est assez simple si vous savez construire des RPM. Vous indiquez comme source le tar.gz des sources du module et dans la section %install vous copiez les sources vers /usr/src/<nom du module>-<version du module> et vous y écrivez le dkms.conf (Il est également possible de mettre le dkms.conf dans un fichier annexe et de l'inclure comme source, mais l'avoir inclus permet d'utiliser les macros RPM %name, %version, ... afin de créer rapidement un .spec pour un nouveau module). Ensuite vous indiquez en %post et %preun les commandes DKMS à invoquer (add, build et install en %post et remove en %preun).
Le modèle de fichier spec suivant pourra vous servir de base dans la majorité des cas.

<code>%define module_name rt2500

Name: dkms-%{module_name}
Version: 1.4.6.2
Release: 1mdk
Summary: DKMS-ready kernel-source for the RT2500 driver
License: GPL
URL: http://www.ralinktech.com/supp-1.htm
Source: http://www.ralinktech.com/drivers/Linux/RT2500-Linux-STA-%{version}.tar.bz2
Group: System/Kernel and hardware
Requires(pre): dkms
Requires(post): dkms
Buildroot: %{_tmppath}/%{name}-%{version}-root
Buildarch: noarch

%description
Driver for the Ralink RT2500 802.11g chipset

%prep
%setup -q -n RT2500-Linux-STA-%{version}
chmod 0755 Module/2.*.x

%build

%clean
rm -fr $RPM_BUILD_ROOT

%install
mkdir -p %{buildroot}/usr/src/%{module_name}-%{version}-%{release}
cp -a Module/* %{buildroot}/usr/src/%{module_name}-%{version}-%{release}
cp -af Module/2.6.x/Makefile %{buildroot}/usr/src/%{module_name}-%{version}-%{release}
cat > %{buildroot}/usr/src/%{module_name}-%{version}-%{release}/dkms.conf <<EOF

PACKAGE_VERSION="%{version}-%{release}"

# Items below here should not have to change with each driver version
PACKAGE_NAME="%{module_name}"
MAKE[0]="make -C \${kernel_source_dir} SUBDIRS=\${dkms_tree}/\${PACKAGE_NAME}/\${PACKAGE_VERSION}/build modules"
CLEAN="make -C \${kernel_source_dir} SUBDIRS=\${dkms_tree}/\${PACKAGE_NAME}/\${PACKAGE_VERSION}/build clean"

BUILT_MODULE_NAME[0]="\$PACKAGE_NAME"

DEST_MODULE_LOCATION[0]="/kernel/drivers/net/wireless/"

MODULES_CONF_ALIAS_TYPE[0]="ra"

REMAKE_INITRD="no"
AUTOINSTALL=yes

EOF

%post
dkms add -m %{module_name} -v %{version}-%{release} --rpm_safe_upgrade
dkms build -m %{module_name} -v %{version}-%{release} --rpm_safe_upgrade
dkms install -m %{module_name} -v %{version}-%{release} --rpm_safe_upgrade

%preun
dkms remove -m %{module_name} -v %{version}-%{release} --rpm_safe_upgrade --all ||:

%files
%defattr(-,root,root)
/usr/src/%{module_name}-%{version}-%{release}</code>

Listing 7: Exemple de fichier .spec pour un package DKMS

Il y a peu de remarques à faire sur ce fichier si ce n'est l'importance de ne pas oublier --rpm_safe_upgrade et surtout ||: dans le %preun qui permet que le rpm puisse être désinstallé même si le remove échoue (par exemple parce que le build avait échoué donc le module n'est pas installé).

Pour ce qui est du deuxième cas (création de RPM binaires), c'est encore plus simple, il suffit de compiler le module puis d'utiliser dkms mkrpm en précisant le module, sa version et le ou les noyaux qui vous intéressent. Contrairement aux RPM créés à la main comme précédemment, cette méthode nécessite par contre d'être root sur la machine générant le package (ou d'avoir par exemple un sudo sur la commande dkms).

== Avantages et inconvénients ==

Pour finir, voici une petite liste des avantages et des inconvénients que je vois à utiliser DKMS. Cette liste vous aidera probablement à décider si vous souhaiter essayer de gérer vos pilotes additionnels avec DKMS.

=== Avantages ===

* Il n'y a plus besoin de se préoccuper de ses pilotes additionnels lorsque l'on met à jour son noyau ;
* Il est beaucoup plus facile de distribuer des pilotes (y compris les modules propriétaires avec une couche libre de jonction). Avec un seul paquetage à installer l'utilisateur n'a rien à faire pour que ça marche sur son noyau ;
* Il est beaucoup plus facile (et léger) de distribuer des correctifs sur les noyaux. Il n'y a plus besoin de distribuer un nouveau noyau lorsque le problème n'affecte qu'un module, DKMS gérera très bien le remplacement du module original, même si celui-ci n'était initialement pas installé avec DKMS ;
* Il est possible d'avoir plusieurs versions du module présentes sur sa machine simultanément et de basculer entres elles à l'aide de la commande dkms, ce qui est très pratique pour des tests ;
* Il est possible de distribuer le module avec la partie userspace associée plutôt qu'avec le noyau, ce qui permet d'éviter les problèmes de désynchronisation.

=== Inconvénients ===

* Le fonctionnement classique de DKMS implique la présence d'un compilateur sur la machine, ce qui est en particulier problématique pour la sécurité des serveurs. Toutefois, DKMS reste utile sans compilateur sur le serveur pour générer depuis une autre machine un RPM contenant la nouvelle version compilée du module et pouvoir ainsi facilement mettre à jour toutes ses machines.
* De même DKMS a besoin des sources du noyau, ce qui occupe beaucoup d'espace disque.
* La recompilation dynamique par un service au démarrage n'est pas adaptée pour les modules nécessaires plus tôt (pilotes de contrôleur disque par exemple), il faut donc dans ce cas s'assurer de faire compiler à DKMS le pilote pour le nouveau noyau avant de redémarrer. Cet inconvénient n'en est toutefois pas réellement un dans la mesure où le problème est le même lorsque le module en question est compilé à la main sans DKMS.
* DKMS est basé sur RPM et ne fonctionnera donc que sur des distributions utilisant RPM (RedHat, Mandriva, SuSE, ...). L'utilisation de rpm est pourtant très localisée (par exemple détection de l'architecture du noyau cible) et il devrait être assez facile de s'en passer.
* DKMS ne prend pour le moment pas en compte le fichier .config du noyau mais celui par défaut fourni par la distribution pour la famille de noyaux (smp, 64G, ...).

=== Références ===

* [http://linux.dell.com/dkms/dkms.html http://linux.dell.com/dkms/dkms.html]
* [http://www.linuxjournal.com/article/6896 http://www.linuxjournal.com/article/6896]
* [http://linux.dell.com/dkms/dkms-ols2004.pdf http://linux.dell.com/dkms/dkms-ols2004.pdf]
* [http://www.dell.com/downloads/global/power/1q04-ler.pdf http://www.dell.com/downloads/global/power/1q04-ler.pdf]
* [http://linux.dell.com/dkms/dkms-LWE-Boston2005.pdf http://linux.dell.com/dkms/dkms-LWE-Boston2005.pdf]

Pascal Terjan <pterjan at mandriva dot com> 
Cet article a été initialement publié dans le GNU/Linux Magazine 80 de Février 2006

{{Copy|2006|Pascal Terjan|LDL}}

DKMS

2006-06-10T10:34:26Z

Pterjan : /* Comment ça marche */

[[Category:Configurer votre noyau]]

= DKMS : Donnez l'indépendance à vos pilotes =

== Contexte ==

Sous Linux, les pilotes (le logiciel qui permet au système d'exploitation de communiquer avec le matériel) peuvent soit être directement inclus dans le noyau soit être disponibles sous la forme de modules à charger dans le noyau. Un tel module est compilé pour un noyau particulier et ne peut être utilisé sur un autre.

En ce qui concerne les pilotes libres, cela ne pose en général aucun problème car ils sont soit livrés avec votre noyau, soit compilés en même temps que le noyau que vous compilez vous-même.

Dans le cas de pilotes non libres (comme ceux de nVidia ou ATI) ou de pilotes distribués séparément et que vous compilez à la main, le pilote doit être recompilé à chaque version de noyau, ce qui peut devenir fastidieux.

De plus, si vous souhaitez utiliser les pilotes distribués par votre distributeur Linux, vous devez attendre que les pilotes soient recompilés pour le nouveau noyau, et ne pouvez espérer qu'ils fonctionnent avec un noyau que vous auriez personnalisé.

== Objectifs de DKMS ==

DKMS (Dynamic Kernel Module Support ou en français Gestion Dynamique des Modules Noyau) est un système très simple conçu par Dell et permettant de compiler dynamiquement et facilement les modules noyau pour tous les noyaux de votre système. Ce système est à la base conçu pour faciliter à Dell la distribution de pilotes Linux et de correctifs.

Cela évite à la fois aux éditeurs et aux utilisateurs de devoir passer par des mises à jour du noyau pour une correction sur un pilote particulier et permet de distribuer un pilote supplémentaire sous la forme d'un seul paquetage quel que soit le noyau de l'utilisateur.

Cet article a pour but de présenter ce système, à la fois aux développeurs et distributeurs de modules noyau qui pourraient l'utiliser pour faciliter la vie à leurs utilisateurs, et aux utilisateurs qui peuvent également l'utiliser tout seuls.

== Comment ça marche ==

Le principe de DKMS est très simple. À condition que le module soit prévu pour être utilisé avec DKMS (fourniture d'un dkms.conf), l'utilisation d'un nouveau module en passant par DKMS consiste à exécuter les 3 étapes suivantes :

* Insertion dans l'arbre DKMS (action add)
* Compilation pour le noyau (action build)
* Installation avec les autres modules du noyau (action install)

Ces étapes sont séparées et ne sont pas forcement toutes réalisées à la suite. La figure 1 montre les différents états d'un module dans le système DKMS, et les transitions possibles entre ces états à l'aide des actions de la commande dkms.

Figure 1 : États d'un module dans le système DKMS

=== Structure sur le disque ===

Afin de bien séparer la gestion des différentes versions de module et de la version du noyau, le fonctionnement de DKMS se base sur la présence de 3 arborescences :

* Les sources des modules, dans <tt>/usr/src</tt>
* L'arborescence des modules du noyau/lib/modules : DKMS y remplacera ou ajoutera les modules que l'on va lui faire gérer
* L'arborescence de DKMS /var/lib/dkms, contenant :
o Les répertoire ou seront construit les modules
o Les modules originaux sauvegardés
o Les modules générés par DKMS

Les chemins indiqués sont ceux par défaut et il est possible de les modifier dans <tt>/etc/dkms/framework.conf</tt> mais nous supposerons dans le reste de l'article que les valeurs par défaut ont été conservées.

== Mise en oeuvre de DKMS par un utilisateur ==

=== La commande dkms ===

La gestion des modules au sein du système DKMS se fait à l'aide de la commande dkms. Cette commande a une syntaxe très simple : dkms <action> [options]
Les actions et les options sont par contre plutôt nombreuses et même si je vous les explique ci-dessous, seules les principales devraient être utiles à la majorité d'entre vous (à savoir: add, build, install, remove en ce qui concerne les actions et -m, -v et --all en ce qui concerne les options).

Voici tout d'abord la liste des options génériques s'appliquant à diverses commandes, celles restreintes à une commande particulière seront expliquées dans la description de celle-ci.

* -m <module> : Le nom du module sur lequel effectuer l'action.
* -v <version du module> : La version du module sur laquelle effectuer l'action.
* -k <version du noyau> : La version du noyau sur laquelle effectuer l'action. Il est possible pour certaines actions de spécifier plusieurs versions du noyau en utilisant plusieurs fois -k, si l'action spécifiée ne le supporte pas une erreur sera émise.
* -a <architecture> : L'architecture pour laquelle effectuer l'action. Si cette option n'est pas précisée, l'architecture choisie est celle indiquée par uname -m. Il est possible de répéter cette option afin d'indiquer plusieurs architectures, mais dans ce cas il doit y avoir exactement autant de -k que de -a. Chaque noyau sera associé à l'architecture de position identique. Par exemple si vous indiquez -k noyau1 -k noyau2 -a i386 -k noyau3 -a i586 -a x86_64, DKMS comprendra que noyau1 est en i386, noyau2 est en i586 et noyau3 est en x86_64.
* --all : Indique d'appliquer l'action pour toutes les versions de noyau et toutes les architectures pour lesquelles le module a été compilé. Cela est particulièrement utile pour l'action remove.
* --rpm_safe_upgrade : Cette option est nécessaire pour les commandes DKMS appelées à l'intérieur d'un RPM. Cela évite des problèmes lors de mise à jour d'un RPM à un autre contenant la même version du module. Cela évite aussi les problèmes d'interblocage dus au système de verrous de rpm.

Nous allons maintenant étudier ce que permet de faire DKMS à travers le parcours des actions que l'on peut faire effectuer à la commande dkms.

* add : Ajoute à l'arbre des sources de DKMS une version d'un module (les options -m et -v sont donc obligatoires, c'est le cas pour la majorité des commandes). Les sources du module doivent être précédemment placées dans /usr/src/<module>-<version du module>/ et contenir un fichier dkms.conf. Si le fichier dkms.conf ne se trouve pas dans /usr/src/<module>-<version du module>/, il faut ajouter l'option -c pour indiquer son chemin.

<code>[root@plop src]# dkms add -m exemple -v 0.9.0 -c /tmp/dkms.conf
Creating symlink /var/lib/dkms/exemple/0.9.0/source ->
/usr/src/exemple-0.9.0

DKMS: add Completed.</code>

* remove : Supprime une version d'un module. Il faut en plus des options -m et -v, soit préciser une version de noyau avec l'option -k, soit demander à supprimer le module de tout les noyaux pour lesquelles cette version avait été compilée, avec l'option --all.

Si le module avait été installé, il est d'abord désinstallé (comme si on avait appelé l'action uninstall) et d'éventuelles versions précédentes sont réinstallées. Après un remove, le module n'est plus du tout connu de DKMS et il faut recommencer à l'étape add.

<code>[root@plop src]# dkms remove -m exemple -v 0.9.0 --all

------------------------------
Deleting module version: 0.9.0
completely from the DKMS tree.
------------------------------
Done.</code>

* build : Compile une version d'un module pour le noyau indiqué avec l'option -k ou pour le noyau utilisé actuellement si aucun n'est précisé. En cas d'erreurs lors de la compilation, il est utile de savoir que celle-ci se déroule dans /var/lib/dkms/<module>/<version du module>/build/ et que tout ce qui est affiché pendant la compilation est enregistré dans un fichier make.log dans ce même répertoire.

La commande build accepte quelques options facultatives :
o --config <fichier .config du noyau> : Cette option permet d'indiquer à la commande build ou trouver le fichier .config si celui-ci n'est pas à l'emplacement standard de la distribution ou n'a pas le nom habituel.
o --no-prepare-kernel : Cette option demande à DKMS de ne pas préparer les sources du noyau avant de compiler un module pour lui. Il est recommandé de ne pas utiliser cette option si l'on souhaite que les modules soient correctement construits.
o --no-clean-kernel : Cette option demande à DKMS de ne pas nettoyer les sources du noyau après avoir compilé un module.
o --kernelsourcedir <chemin vers les sources du noyau> : Cette option permet d'indiquer l'emplacement des sources du noyau lorsqu'elles ne se trouvent pas dans /lib/modules/<version du noyau>/build.

<code>[root@plop src]# dkms build -m slmodem -v 2.9.10 -k 2.6.12-12mdk-i686-up-4GB

Preparing kernel 2.6.12-12mdk-i686-up-4GB for module build:
(This is not compiling a kernel, only just preparing kernel symbols)
Storing current .config to be restored when complete
Running Generic preparation routine
make mrproper.........
using /boot/config-2.6.12-12mdk-i686-up-4GB
make oldconfig......
make prepare-all......

Building module:
cleaning build area....
make KERNELRELEASE=2.6.12-12mdk-i686-up-4GB KERNEL_DIR=/lib/modules/2.6.12-12mdk-i686-up-4GB/build drivers....
cleaning build area....
cleaning kernel tree (make mrproper)....

DKMS: build Completed.</code>

* install : Installe une version d'un module dans l'arborescence du noyau indiqué (ou du noyau utilisé actuellement si aucun n'est précisé par l'option -k). Cette version doit précédemment avoir été compilée pour le noyau en question à l'aide de l'action build.

Lors de la première installation d'une version d'un module donné sur un noyau donné, DKMS cherche si ce module existait déjà avec ce noyau et le sauvegarde pour pouvoir le réinstaller lorsque l'on demandera à DKMS de désinstaller la nouvelle version. Pour information, la version originale est sauvée dans /var/lib/dkms/<module>/original_module/<version du noyau>/<architecture>/

<code>[root@plop src]# dkms install -m slmodem -v 2.9.10 -k 2.6.12-12mdk-i686-up-4GB
Running module version sanity check.

slamr.ko.gz:
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/2.6.12-12mdk-i686-up-4GB/kernel/drivers/char/

slusb.ko.gz:
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/2.6.12-12mdk-i686-up-4GB/kernel/drivers/char/

depmod.....

DKMS: install Completed.</code>

* uninstall : Désinstalle une version d'un module pour une version du noyau (celle précisée par l'option -k ou la version utilisée actuellement si aucune n'est précisée). Cette commande ne gère pas l'option --all donc il vous faudra désinstaller pour chaque noyau séparément.

<code>[root@plop src]# dkms uninstall -m slmodem -v 2.9.10 -k 2.6.12-12mdk-i686-up-4GB

-------- Uninstall Beginning --------
Module: slmodem
Version: 2.9.10
Kernel: 2.6.12-12mdk-i686-up-4GB (i586)
-------------------------------------

Status: Before uninstall, this module version was ACTIVE on this kernel.

slamr.ko.gz:
- Uninstallation
- Deleting from: /lib/modules/2.6.12-12mdk-i686-up-4GB/kernel/drivers/char/
- Original module
- No original module was found for this module on this kernel.
- Use the dkms install command to reinstall any previous module version.

slusb.ko.gz:
- Uninstallation
- Deleting from: /lib/modules/2.6.12-12mdk-i686-up-4GB/kernel/drivers/char/
- Original module
- No original module was found for this module on this kernel.
- Use the dkms install command to reinstall any previous module version.

DKMS: uninstall Completed.</code>

* mkrpm : Génére un RPM pour un couple module/version donné. Si vous désirez que le RPM ne contienne que les sources (et donc que les modules soient compilés lors de l'installation), vous devez ajouter l'option --source-only. Sinon, le choix des modules à distribuer se fait à l'aide de -k et -a, comme pour les autres actions.

Si vous maîtrisez la création de RPM et souhaitez personnaliser ce qui est généré, sachez que DKMS regarde d'abord si /usr/src/<module>-<version du module>/<module>-dkms-mkrpm.spec existe, si oui l'utilise comme modèle, et sinon utilise /etc/dkms/template-dkms-mkrpm.spec.

* status : Affiche l'état des différents modules pour chaque version, noyau et architecture.

<code>[root@plop src]# dkms status
ipw2200, 1.0.4: added
slmodem, 2.9.10, 2.6.12-11mdk-i686-up-4GB, i586: installed
slmodem, 2.9.10, 2.6.12-12mdk-i686-up-4GB, i586: built
sysprof, 1.0, 2.6.12-12mdk-i686-up-4GB, i586: installed</code>

* match : Cette commande fort sympathique permet de compiler et installer pour un noyau donné tout les modules qui avaient été installés pour un autre noyau (spécifié par l'option --templatekernel). Par exemple, après exécution de dkms match --templatekernel 2.6.12-11mdk-i686-up-4GB -k 2.6.12-12mdk-i686-up-4GB, toutes les combinaisons module/version qui étaient installées pour le noyau 2.6.12-11mdk-i686-up-4GB le seront pour le noyau 2.6.12-12mdk-i686-up-4GB.
* mktarball : Crée une archive tar.gz pour le module et la version indiquées. Cette archive contiendra les sources et les modules précédemment compilés. Par défaut l'archive est créée pour le noyau utilisé actuellement. Si vous en souhaitez un (ou plusieurs) autre, vous pouvez l'indiquer en utilisant les options -k et -a. Cette commande dispose également de quelques options supplémentaires :
o --archive <fichier.tar.gz> : Permet de préciser le nom à donner à l'archive (ne pas indiquer de chemin, il sera toujours placé dans /var/lib/dkms/<module>/<version du module>/tarball/). Sans cette option, le fichier s'appelle <module>-<version du module>-<versions des noyaux>.dkms.tar.gz
o --binaries-only : Ne pas inclure les sources du module
o --sources-only : Ne pas inclure les modules pré compilés. L'archive s'appellera <module>-<version du module>-source-only.dkms.tar.gz, sauf si vous précisez un autre nom à l'aide de --archive

<code>[root@plop src]# dkms mktarball -m slmodem -v 2.9.10 -k 2.6.12-11mdk-i686-up-4GB -k 2.6.12-12mdk-i686-up-4GB
Marking modules for 2.6.12-11mdk-i686-up-4GB (i586) for archiving...
Marking modules for 2.6.12-12mdk-i686-up-4GB (i586) for archiving...

Marking /usr/src/slmodem-2.9.10 for archiving...

Tarball location: /var/lib/dkms/slmodem/2.9.10/tarball/slmodem-2.9.10-kernel2.6.12-11mdk-i686-up-4GB-i586-kernel2.6.12-12mdk-i686-up-4GB-i586.dkms.tar.gz

DKMS: mktarball Completed.</code>

* ldtarball : Importe une archive tar.gz créé à l'aide de l'action mktarball et spécifié à l'aide de l'option --archive.

Les fichiers sont importés dans l'arborescence de DKMS et pas dans celle du noyau, les modules sont donc au mieux dans l'état built(compilé) et il faut lancer ensuite la commande dkms install pour chacun d'eux.

Par ailleurs, si des fichiers existent déjà lors de l'import, un avertissement sera affiché et ils seront laissés tels quels. Si vous souhaitez que ces éventuels fichiers soient écrasés, il faut ajouter l'option --force.
* mkdriverdisk : Crée une disquette avec les pilotes pour permettre l'installation d'une distribution, c'est particulièrement utile lorsque le CD d'installation ne contient pas les pilotes pour un nouveau contrôleur disque.
o --size <taille de la disquette> : Cette option est utilisée par la commande mkdriverdisk pour décider de la taille de la disquette à créer. La valeur doit être un nombre entier de kilo-octets, divisible par 20, et vaut 1440 si cette option n'est pas précisée.
o --distrib <distribution> : Cette option obligatoire indique la distribution cible. Les valeurs actuellement supportées sont suse, UnitedLinux, redhat, redhat1 and redhat2. Red Hat supportant les disquettes de pilotes multi-architecture depuis la RHEL3, redhat1 force à utiliser l'ancien format, redhat2 force à utiliser le nouveau.
o --release <version> : Cette option est nécessaire si vous construisez une disquette pour SuSE ou UnitedLinux. Elle indique la version de la distribution, par exemple --distrib suse --release 9.1 indiquera que vous construisez la disquette pour une SuSE 9.1
Les options --binaries-only et --sources-only de mktarball peuvent également être utilisées.

=== Utilisation basique ===

Après vous avoir noyé sous les commandes et les options, je pense qu'un exemple d'utilisation classique est nécessaire pour vous persuader de la simplicité d'utilisation. Voici donc comment installer un module exemple, fourni sous la forme de exemple-1.0.tar.gz contenant un unique répertoire exemple-1.0 avec les sources du module et un dkms.conf.

<code>cd /usr/src
tar xzf /tmp/exemple-1.0.tar.gz
dkms add -m exemple -v 1.0
dkms build -m exemple -v 1.0
dkms install -m exemple -v 1.0</code>

Listing 1 : Ajout d'un pilote en utilisant DKMS

Si tout s'est bien passé, le module est compilé et installé, et modprobe exemple fonctionne ! Si cela ne s'est pas bien passé, c'est vraisemblablement lors de l'étape build, et vous pouvez essayer de déterminer le problème en allant lire le fichier /var/lib/dkms/exemple/1.0/build/make.log. Si vous n'avez pas les compétences pour cela, le plus simple est d'envoyer ce fichier à l'auteur du dkms.conf afin qu'il corrige l'erreur.

Un mode de distribution courant, que nous détaillerons plus loin, consiste à distribuer les sources et le dkms.conf sous la forme d'un package RPM et non pas d'un tar.gz. Dans ce cas, installer le package RPM suffit et exécutera automatiquement les différentes commandes.

== Mise en oeuvre de DKMS par un distributeur ==

=== Adaptation des sources ===
DKMS a besoin des sources du module dans le répertoire /usr/src/<nom du module>-<version du module>/ et d'un fichier dkms.conf dans ce même répertoire. Nous allons étudier la syntaxe de ce fichier sur un exemple classique avant de détailler toutes les options disponibles.

=== Exemple de dkms.conf pour l'ipw2200 1.0.4 ===

<code>PACKAGE_VERSION="1.0.4"
PACKAGE_NAME="ipw2200"

MAKE[0]="make -C ${kernel_source_dir} SUBDIRS=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build modules HOSTAP_SRC=${kernel_source_dir}/3rdparty/hostap/"
CLEAN="make -C ${kernel_source_dir} SUBDIRS=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build clean"

BUILT_MODULE_NAME[0]="$PACKAGE_NAME"
BUILT_MODULE_NAME[1]="ieee80211_crypt_ccmp"
BUILT_MODULE_NAME[2]="ieee80211_crypt"
BUILT_MODULE_NAME[3]="ieee80211_crypt_tkip"
BUILT_MODULE_NAME[4]="ieee80211_crypt_wep"
BUILT_MODULE_NAME[5]="ieee80211"
DEST_MODULE_LOCATION[0]="/kernel/drivers/net/wireless/ipw2200/"
DEST_MODULE_LOCATION[1]="/kernel/drivers/net/wireless/ipw2200/"
DEST_MODULE_LOCATION[2]="/kernel/drivers/net/wireless/ipw2200/"
DEST_MODULE_LOCATION[3]="/kernel/drivers/net/wireless/ipw2200/"
DEST_MODULE_LOCATION[4]="/kernel/drivers/net/wireless/ipw2200/"
DEST_MODULE_LOCATION[5]="/kernel/drivers/net/wireless/ipw2200/"

MODULES_CONF_ALIAS_TYPE[0]="eth"

REMAKE_INITRD="no"
AUTOINSTALL="yes"</code>

Listing 2: Exemple de dkms.conf pour le pilote ipw2200 version 1.0.4

Comme vous pouvez le voir ce fichier a une syntaxe très simple, une option par ligne sous la forme OPTION="valeur". Voyons maintenant plus précisément à quoi correspondent les options définies dans cet exemple.

PACKAGE_VERSION et PACKAGE_NAME ne méritent je pense aucune explication. Il est toutefois intéressant de noter que lors de la sortie d'une nouvelle version du module, la seule ligne à modifier dans le dkms.conf est en général PACKAGE_VERSION.

MAKE[0] contient la commande à exécuter pour compiler le module, elle peut utiliser de nombreuses variables, listées dans la section suivante. La majorité des modules peuvent se compiler avec la commande suivante : make -C ${kernel_source_dir} SUBDIRS=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build modules

CLEAN contient une commande permettant de nettoyer le répertoire de construction, elle est appelée avant et après la compilation du module.

Les 12 lignes suivantes indiquent les modules générés (ici il y en a 6) et ou il faut les installer. BUILT_MODULE_NAME[i] contient le nom du module numéro i (en commençant à 0) et DEST_MODULE_LOCATION[i] le chemin où installer le module numéro i. Le chemin est relatif à l'arborescence des modules du noyau concerné, /lib/modules/<version du noyau>.

L'option MODULES_CONF_ALIAS_TYPE[0]="eth" indique qu'il faudra ajouter dans /etc/modprobe.conf (ou modules.conf) un alias vers ce module qui s'appelera eth0 (ou eth1, eth2, ... selon ce qui est déjà pris).

REMAKE_INITRD="no" indique que ce pilote n'a pas besoin d'être dans l'initrd. L'initrd est l'image contenant tout les modules et commandes nécessaires pour accéder au disque dur, cette option a donc rarement besoin d'être à yes en dehors des pilotes de contrôleur disque.

AUTOINSTALL="yes" indique que l'on veut que ce module soit compilé et installé automatiquement lorsque l'on démarre sur un nouveau noyau.

=== Variables disponibles ===

Quelques variables peut être utilisées dans les options et les commandes comme vous pouvez le voir dans la commande MAKE[0] de l'exemple précédent. Ces variables sont définies par la configuration de DKMS ou par les options passées à la commande dkms.

* $kernelver : Cette variable contient la version du noyau pour laquelle le module est en train d'être construit. C'est particulièrement utile dans la définition de la commande MAKE, par exemple MAKE[0]="make INCLUDEDIR=/lib/modules/${kernelver}/build/include"
* $dkms_tree : Cette variable indique ou se trouve l'arbre DKMS sur le système local. Par défaut il s'agit de /var/lib/dkms, mais cette valeur ne doit pas être mise en dur dans les dkms.conf au cas ou l'utilisateur aurait changé cela sur son système (Un tel réglage se fait à l'aide de /etc/dkms/framework.conf ou en ajoutant l'option --dkmstree lors de l'appel, mais nous ne verrons pas ce genre d'utilisations avancées dans cette article).
* $source_tree : Cette variable indique ou DKMS stocke les sources des modules sur le système. Par défaut il s'agit de /usr/src, mais cette valeur ne doit pas être mise en dur dans les dkms.conf au cas ou l'utilisateur aurait changé cela sur son système (à l'aide de /etc/dkms/framework.conf ou en ajoutant l'option --sourcetree lors de l'appel).
* $kernel_source_dir : Cette variable contient le chemin vers les sources du kernel pour lequel on construit le module. Il s'agit en général de /lib/modules/$kernelver/build, à moins qu'un autre chemin ait été spécifié avec l'option --kernel-sourcedir

=== Options que l'on peut définir dans le fichier dkms.conf ===
Tout d'abord, le nom des options est sensible à la casse donc elles doivent être écrites en majuscules. Seules 4 options sont obligatoires :

* PACKAGE_NAME : le nom du package
* PACKAGE_VERSION : la version du package
* BUILT_MODULE_NAME[0] : le nom du module construit. S'il y en a plusieurs, ça sera BUILT_MODULE_NAME[1], BUILT_MODULE_NAME[2], ... Les modules non listés ici ne seront pas installés même s'il sont construit par la commande MAKE[0]
* DEST_MODULE_LOCATION[0] : l'emplacement ou installer le module numéro 0. Ce chemin est relatif au répertoire des modules, et sera par exemple "3rdparty". Il faut renseigner DEST_MODULE_LOCATION[#] pour chaque module listé dans BUILT_MODULE_NAME

De nombreuses autres options bien pratiques mais facultatives dont disponibles :

* MAKE[#] : la commande pour compiler le(s) modules. Voir l'explication de MAKE_MATCH pour la signification du numéro passé en paramètre. Cette option est facultative dans la mesure ou la commande standard de construction d'un module kernel sera utilisée si elle n'est pas définie.
* MAKE_MATCH[#] : cet ensemble d'options permet d'avoir une commande de construction différente en fonction des versions du kernel. Chacune contient une expression régulière qui sera comparée à la version du noyau. Le numéro de la dernière qui correspond indiquera le numéro de commande MAKE à utiliser.
* BUILT_MODULE_LOCATION[#] : le chemin relatif vers le module généré. Cela est nécessaire lorsque le module est généré dans un sous répertoire du répertoire de compilation.
* DEST_MODULE_NAME[#] : le nom a utiliser pour installer le module, s'il y a besoin de le renommer. L'extension (.o ou .ko) ne doit pas être spécifiée. Par défaut le nom original BUILT_MODULE_NAME[#] est conservé.
* MODULES_CONF_ALIAS_TYPE[#] : cette option indique pour chaque module quel alias créer dans /etc/modprobe.conf. DKMS calculera automatiquement le numéro de l'alias en fonction de ceux qui existent déjà. Par exemple si MODULES_CONF_ALIAS_TYPE[0] contient eth et que vous avez déjà eth0 et eth1 définis dans /etc/modprobe.conf, DKMS ajoutera un alias eth2 vers le module. Cette fonctionnalité est à utiliser avec précaution dans la mesure ou elle gère mal les cas complexes, comme par exemple les systèmes avec plusieurs cartes réseau utilisant le même module.
* MODULES_CONF_OBSOLETES[#] : cette option indique à DKMS quels modules vers lesquels pointent des alias dans /etc/modprobe.conf doivent être remplacés par ce nouveau module. Si il y en a plusieurs, les séparer par une virgule. Je pense que ce sera plus clair sur un exemple. Considérons le fichier modprobe.conf suivant :

<code>alias eth0 bcm4400
alias eth1 e1000</code>

Si l'on se contente des options suivantes, DKMS n'a aucun moyen de deviner que b44 et bcm4400 gèrent la même carte et un nouvel alias sera généré.

<code>BUILT_MODULE_NAME[0]="b44"
MODULES_CONF_ALIAS_TYPE[0]="eth"</code>

Le nouveau modprobe.conf contiendra donc :

<code>alias eth0 bcm4400
alias eth1 e1000
alias eth2 b44</code>

Si par contre on ajoute MODULES_CONF_OBSOLETES[0]="bcm4400", le nouveau modprobe.conf sera correct :

<code>alias eth0 b44
alias eth1 e1000</code>

* MODULES_CONF_OBSOLETE_ONLY[#] : Si cette option vaut yes, DKMS ne modifiera modprobe.conf que s'il trouve un alias vers un module obsolète à remplacer. Il n'y aura donc jamais de nouveaux alias de créés.
* STRIP[#] : Par défaut, les symboles de deboguage sont supprimés des modules à l'aide de strip -g. Positionner cette option à "no" pour l'un des modules permet de les conserver dans ce module.
* REMAKE_INITRD : Cette option indique, lorsque la première lettre est y ou Y, qu'il faut régénérer l'initrd après l'installation d'une nouvelle version du module. C'est surtout nécessaire pour les pilotes de contrôleur disque.
* MODULES_CONF[#] : Cette option permet d'indiquer des lignes à ajouter au fichier modprobe.conf. Lorsqu'une première version du module est installée sur l'un des noyaux, les lignes de MODULES_CONF sont ajoutées au fichier modprobe.conf (avant que l'initrd soit régénéré si REMAKE_INITRD est activé). Elles sont supprimées lorsque la dernière version est désinstallée. On peut imaginer par exemple dans le cas de l'ipw2200 MODULES_CONF[0]="options ipw2200 led=1".
* PATCH[#] : Cette option permet d'indiquer des patchs à appliquer sur les sources du pilote avant de le compiler. Tout les patchs doivent se trouver dans /usr/src/<module>-<version du module>/patches/ et sont appliqués avec patch -p1. Vous pouvez spécifier pour quels noyaux chaque patch doit être appliqué en utilisant l'option PATCH_MATCH ci-dessous.
* PATCH_MATCH[#] : Cette option sert à indiquer pour quels noyaux les patchs contenus dans le tableau PATCH doivent être appliqués. PATCH_MATCH[i] contient une expression régulière qui est comparés à la version du noyau cible pour décider si PATCH[i] doit être appliqué.
* AUTOINSTALL : Si cette option vaut "yes", le service dkms (/etc/rc.d/init.d/dkms) essayera automatiquement de construire et installer ce module sur le noyau sur lequel vous démarrez. Ce service ne fera toutefois rien si plusieurs versions du module sont présentes dans l'arbre DKMS, ce sera à vous de décider laquelle vous souhaitez.
* BUILD_EXCLUSIVE_KERNEL : Cette option permet d'indiquer une expression régulière décrivant les versions de noyau pour lesquelles DKMS est autorisé à construire votre module. Si vous essayez de construire le module pour un noyau ne correspondant pas à cette expression régulière, DKMS provoquera une erreur. Par exemple, si vous indiquez "^2.6.*", votre module ne pourra être construit que pour les noyaux 2.6 et une erreur se produira sur les 2.4.
* BUILD_EXCLUSIVE_ARCH : Cette option fonctionne comme BUILD_EXCLUSIVE_KERNEL mais limite l'architecture du noyau au lieu de sa version. Par exemple, si cette option vaut "i.86" votre module pourra être construit pour i386 ou i586 mais pas ppc, x86_64, ni s390.
* POST_ADD : Cette option indique le nom d'un script à exécuter après le traitement de la commande add. Le chemin doit être indiqué relativement aux sources du module.
* POST_BUILD : Cette option indique le nom d'un script à exécuter après le traitement de la commande build. Le chemin doit être indiqué relativement aux sources du module.
* POST_INSTALL : Cette option indique le nom d'un script à exécuter après le traitement de la commande install. Le chemin doit être indiqué relativement aux sources du module.
* POST_REMOVE : Cette option indique le nom d'un script à exécuter après le traitement de la commande remove. Le chemin doit être indiqué relativement aux sources du module.
* PRE_BUILD : Cette option indique le nom d'un script à exécuter avant le traitement de la commande build. Le chemin doit être indiqué relativement aux sources du module.

=== Intégration avec rpm ===

Les possibilités d'intégration de DKMS avec RPM sont doubles :

* Création manuelle de RPM contenant les sources et le dkms.conf ;
* Création automatique de rpm contant un module compilé à l'aide de dkms, et dont la gestion est faite par DKMS.

En ce qui concerne le premier cas, la création du RPM est assez simple si vous savez construire des RPM. Vous indiquez comme source le tar.gz des sources du module et dans la section %install vous copiez les sources vers /usr/src/<nom du module>-<version du module> et vous y écrivez le dkms.conf (Il est également possible de mettre le dkms.conf dans un fichier annexe et de l'inclure comme source, mais l'avoir inclus permet d'utiliser les macros RPM %name, %version, ... afin de créer rapidement un .spec pour un nouveau module). Ensuite vous indiquez en %post et %preun les commandes DKMS à invoquer (add, build et install en %post et remove en %preun).
Le modèle de fichier spec suivant pourra vous servir de base dans la majorité des cas.

<code>%define module_name rt2500

Name: dkms-%{module_name}
Version: 1.4.6.2
Release: 1mdk
Summary: DKMS-ready kernel-source for the RT2500 driver
License: GPL
URL: http://www.ralinktech.com/supp-1.htm
Source: http://www.ralinktech.com/drivers/Linux/RT2500-Linux-STA-%{version}.tar.bz2
Group: System/Kernel and hardware
Requires(pre): dkms
Requires(post): dkms
Buildroot: %{_tmppath}/%{name}-%{version}-root
Buildarch: noarch

%description
Driver for the Ralink RT2500 802.11g chipset

%prep
%setup -q -n RT2500-Linux-STA-%{version}
chmod 0755 Module/2.*.x

%build

%clean
rm -fr $RPM_BUILD_ROOT

%install
mkdir -p %{buildroot}/usr/src/%{module_name}-%{version}-%{release}
cp -a Module/* %{buildroot}/usr/src/%{module_name}-%{version}-%{release}
cp -af Module/2.6.x/Makefile %{buildroot}/usr/src/%{module_name}-%{version}-%{release}
cat > %{buildroot}/usr/src/%{module_name}-%{version}-%{release}/dkms.conf <<EOF

PACKAGE_VERSION="%{version}-%{release}"

# Items below here should not have to change with each driver version
PACKAGE_NAME="%{module_name}"
MAKE[0]="make -C \${kernel_source_dir} SUBDIRS=\${dkms_tree}/\${PACKAGE_NAME}/\${PACKAGE_VERSION}/build modules"
CLEAN="make -C \${kernel_source_dir} SUBDIRS=\${dkms_tree}/\${PACKAGE_NAME}/\${PACKAGE_VERSION}/build clean"

BUILT_MODULE_NAME[0]="\$PACKAGE_NAME"

DEST_MODULE_LOCATION[0]="/kernel/drivers/net/wireless/"

MODULES_CONF_ALIAS_TYPE[0]="ra"

REMAKE_INITRD="no"
AUTOINSTALL=yes

EOF

%post
dkms add -m %{module_name} -v %{version}-%{release} --rpm_safe_upgrade
dkms build -m %{module_name} -v %{version}-%{release} --rpm_safe_upgrade
dkms install -m %{module_name} -v %{version}-%{release} --rpm_safe_upgrade

%preun
dkms remove -m %{module_name} -v %{version}-%{release} --rpm_safe_upgrade --all ||:

%files
%defattr(-,root,root)
/usr/src/%{module_name}-%{version}-%{release}</code>

Listing 7: Exemple de fichier .spec pour un package DKMS

Il y a peu de remarques à faire sur ce fichier si ce n'est l'importance de ne pas oublier --rpm_safe_upgrade et surtout ||: dans le %preun qui permet que le rpm puisse être désinstallé même si le remove échoue (par exemple parce que le build avait échoué donc le module n'est pas installé).

Pour ce qui est du deuxième cas (création de RPM binaires), c'est encore plus simple, il suffit de compiler le module puis d'utiliser dkms mkrpm en précisant le module, sa version et le ou les noyaux qui vous intéressent. Contrairement aux RPM créés à la main comme précédemment, cette méthode nécessite par contre d'être root sur la machine générant le package (ou d'avoir par exemple un sudo sur la commande dkms).

== Avantages et inconvénients ==

Pour finir, voici une petite liste des avantages et des inconvénients que je vois à utiliser DKMS. Cette liste vous aidera probablement à décider si vous souhaiter essayer de gérer vos pilotes additionnels avec DKMS.

=== Avantages ===

* Il n'y a plus besoin de se préoccuper de ses pilotes additionnels lorsque l'on met à jour son noyau ;
* Il est beaucoup plus facile de distribuer des pilotes (y compris les modules propriétaires avec une couche libre de jonction). Avec un seul paquetage à installer l'utilisateur n'a rien à faire pour que ça marche sur son noyau ;
* Il est beaucoup plus facile (et léger) de distribuer des correctifs sur les noyaux. Il n'y a plus besoin de distribuer un nouveau noyau lorsque le problème n'affecte qu'un module, DKMS gérera très bien le remplacement du module original, même si celui-ci n'était initialement pas installé avec DKMS ;
* Il est possible d'avoir plusieurs versions du module présentes sur sa machine simultanément et de basculer entres elles à l'aide de la commande dkms, ce qui est très pratique pour des tests ;
* Il est possible de distribuer le module avec la partie userspace associée plutôt qu'avec le noyau, ce qui permet d'éviter les problèmes de désynchronisation.

=== Inconvénients ===

* Le fonctionnement classique de DKMS implique la présence d'un compilateur sur la machine, ce qui est en particulier problématique pour la sécurité des serveurs. Toutefois, DKMS reste utile sans compilateur sur le serveur pour générer depuis une autre machine un RPM contenant la nouvelle version compilée du module et pouvoir ainsi facilement mettre à jour toutes ses machines.
* De même DKMS a besoin des sources du noyau, ce qui occupe beaucoup d'espace disque.
* La recompilation dynamique par un service au démarrage n'est pas adaptée pour les modules nécessaires plus tôt (pilotes de contrôleur disque par exemple), il faut donc dans ce cas s'assurer de faire compiler à DKMS le pilote pour le nouveau noyau avant de redémarrer. Cet inconvénient n'en est toutefois pas réellement un dans la mesure où le problème est le même lorsque le module en question est compilé à la main sans DKMS.
* DKMS est basé sur RPM et ne fonctionnera donc que sur des distributions utilisant RPM (RedHat, Mandriva, SuSE, ...). L'utilisation de rpm est pourtant très localisée (par exemple détection de l'architecture du noyau cible) et il devrait être assez facile de s'en passer.
* DKMS ne prend pour le moment pas en compte le fichier .config du noyau mais celui par défaut fourni par la distribution pour la famille de noyaux (smp, 64G, ...).

=== Références ===

* [http://linux.dell.com/dkms/dkms.html http://linux.dell.com/dkms/dkms.html]
* [http://www.linuxjournal.com/article/6896 http://www.linuxjournal.com/article/6896]
* [http://linux.dell.com/dkms/dkms-ols2004.pdf http://linux.dell.com/dkms/dkms-ols2004.pdf]
* [http://www.dell.com/downloads/global/power/1q04-ler.pdf http://www.dell.com/downloads/global/power/1q04-ler.pdf]
* [http://linux.dell.com/dkms/dkms-LWE-Boston2005.pdf http://linux.dell.com/dkms/dkms-LWE-Boston2005.pdf]

Pascal Terjan <pterjan at mandriva dot com> 
Cet article a été initialement publié dans le GNU/Linux Magazine 80 de Février 2006

Tunnels ethernet avec OpenSSH

2006-02-12T12:43:44Z

Pterjan : quelques corrections

Depuis la version 4.3 de Openssh, l'option pour faire des tunnels ip a été ajoutée, mais la doc sur internet est plutot rare sur le sujet.

Avant tout, il faut vérifier la version d'openssh sur le serveur et le client.
<code multi>
~ $ rpm -q openssh
openssh-4.3p1-3mdk
~ $ ssh sisay rpm -q openssh
openssh-4.3p1-0.1.20060mdk
</code>

L'exemple ici a été fait à partir de 2 mandriva, mais ça doit marcher sans modification
sur un autre linux ou *bsd.

Tout d'abord, il faut les droits root sur les 2 machines. En effet, il y a quelques opérations à faire, aussi bien au niveau de la configuration que du réseau.

== Sur le serveur ==

La première chose à faire est de dire à openssh d'autoriser les tunnels, en rajoutant cette directive :

<code>PermitTunnel yes</code>

dans /etc/ssh/sshd_config.

Il faut aussi retirer la séparation des priviléges, ou jouer sur les permissions de /dev/tun .
J'ai pris la facilité pour le moment, j'ai rajouté

<code>UsePrivilegeSeparation no</code>

Une autre solution est de donner les permissions en lecture écriture à un groupe particulier
sur /dev/tun, ce qui est bien plus simple et sûr.

<code>chmod :mongroupe /dev/tun</code>

et bien sur, être dans le groupe en question.

Il faut ensuite charger le module tun :

<code>modprobe tun</code>

et le rajouter dans /etc/modprobe.preload

<code>echo tun >> /etc/modprobe.preload</code>

pour le charger au prochain démarrage.

== Sur le client ==

Il faut simplement les droits sur /dev/tun, donc soit tourner en root, ou avoir la permission
d'écrire sur /dev/tun, comme plus haut, puis faire ( sisay etant le serveur ) :

<code>ssh -w any:any sisay</code>

Vous pouvez jeter une oeil sur les options -f et -N pour ne pas lancer de shell sur la machine distante. Et bien sur, les options habituelles marchent encore ( clé, tunnel, master/slave ).

Puis, en root, vous pourrez changer l'ip de la nouvelle interface tun0 sur le serveur

<code>ifconfig tun0 10.0.0.1</code>

et faire pareil sur le client :

<code>ifconfig tun0 10.0.0.2</code>

Et finalement, vous pouvez maintenant tester le ping depuis le client :

<code>ping 10.0.0.1</code>

Le reste, c'est de la configuration normale pour les interfaces. Vous pouvez rajouter des routes, un firewall, n'importe quoi.

Néanmoins, il faut savoir que les connexions tcp par dessus tcp ( comme c'est le cas avec ssh ) sont déconseillées, de par la nature de tcp ( http://docs.mandragor.org/files/Misc/GLFM/lm31/TCP_over_TCP_mauvaise_iD.html ).

Lea Linux:Compte-rendu AG 2005

2005-12-03T10:54:25Z

Pterjan : cohérence des mois, le pric c'était pas aux tanneries

[[Category:Association]]

= Bilan moral =
L'association Léa existe officiellement depuis maintenant 4 ans ; son existence a été rendue publique lors du salon Linux Solutions de février 2003. Le site Lea-Linux.org existe, quant à lui, depuis 1999.

Cette année a été riche en événements pour Léa.

Tout d'abord, c'était la troisième année où Léa sortait dans la vie réelle. Ainsi avons-nous participé à des manifestations, dont vous verrez le résumé plus bas.

Ensuite, le site a aussi évolué :
* en changeant de charte graphique (nous tenons à remercier Ayo et LinuxGraphic.org)
* en s'ouvrant à une contribution plus large.

Le forum et la liste aide tournent déjà grâce au support de quelques habitués : Léa les remercie de leur présence et de leur disponibilité. Néanmoins, nous sommes toujours en perpétuel quête de contributeurs pour faire « vivre » l'association, le site, le forum, les listes de diffusion etc...

Il restait à faire vivre les articles du site. Grâce au Wiki, nous espérons avec vous relever le défi de maintenir une documentation à jour.

Enfin, nous avons tout au cours de cette année fait de nombreuses actions de prosélytisme et de lobbying pour Linux et les Logiciels Libres, des conférences, des install-parties.

Du côté administratif, cet été, le siège social de l'association a déménagé en même temps que son président à l'adresse suivante : 12 rue Boucry – 75018 PARIS.

== Compte-rendu des actions ==
=== Site Web ===
==== Léa ====
Avant l'été, il a été mis en place un système de paiement de dons en ligne par carte de paiement à travers le service de Paypal. Ce service ne nécessite pas la création de compte Paypal.

Durant les RMLL, Léa a décidé d'étudier l'ouverture à la contribution sur ses articles à l'aide d'un Wiki. Après des études de faisabilité durant Juillet/Août, le CA a décidé de commencer les travaux de migration du site vers le moteur MediaWiki.

Le site de Léa tourne depuis fin Octobre sous un MediaWiki auquel nous avons ajouté quelques extensions (dont certaines sont disponibles sur la page de [[Utilisateur:Lea|Lea]]) ainsi qu'un cache statique qui sert de filtre entre les modifications et le net.

==== Forum ====
Le forum tourne toujours sous Phorum. Des maintenances correctives et de sécurité ont été effectuées.

==== Liste Aide ====
Emmanuel Fleury est toujours modérateur de la liste.

==== LinuxFrench ====
Au printemps, LinuxFrench a failli fermer ces portes lors du départ d'Albert Bruc.
Heureusement, Jean-Claude Stiegler reprend le site en accord avec Albert.
La ligne éditoriale restera la même et nous espèrons que certains d'entre vous rejoindront la rédaction passagèrement ou sur plus long terme.

=== Manifestations ===
==== Concours Kakémono ====
Pour représenter Léa lors de ces manifestations, le CA a décidé en Juin d'organiser un concours pour la réalisation d'un kakémono.

Après la délibération du jury, les délais ont été très court pour sa première sortie lors des RMLL.
Le vainqueur de ce concours a été skeepin.

==== Liste de manifestations ====
Remarque : Ce rapport ne mentionne que les actions dont le conseil d'administration a été mis au courant, il se peut donc que les actions de tous les membres de Léa ne soient pas dans ce rapport.

* '''1 au 3 Février 2005 : Solutions Linux''' : Prosélytisme Linux et vente de CDs, Léa-Books et T-Shirts. Léa a remporté le 1er prix du meilleur site web aux Coups de Coeur du Libre
* '''19 Mars 2005 : Install-Party à la Villette''' : Conférences, Install-Party et prosélytisme Linux
* '''1 et 2 Avril 2005 : Game Over à Limoges''' : Prosélytisme Linux et vente de Live CDs, Léa-Books et T-Shirts
* '''23 au 25 avril 2004 : Libr'east''' : Prosélytisme Linux, Install Party et vente de CDs, Léa-Books et T-Shirts
* '''30 Avril 2004 : AG 2004 et Léa-Party''' : AG 2004, Conférences et Repas entre membres de l'associations
* '''14 et 15 Mai 2005 Salon Multimédia de Proville''' : Prosélytisme Linux
* '''4 au 9 Juillet 2005 : RMML à Dijon''' : Prosélytisme Linux et vente de CDs, Léa-Books et T-Shirts. Le stand de Léa a remporté le second prix ex-aequo du stand le plus sympa du village
* '''9, 10 et 11 Septembre 2005 : Fête de l'Huma''' : Prosélytisme Linux
* '''14 et 15 Octobre 2005 : Journées du Logiciel Libre à Lyon''' : Prosélytisme Linux

=== Lobbying ===
* Lors du Salon Linux Solution, Léa a participé matériellement, humainement et financièrement à la tenue d'un stand de conférences libres sur le Libre.

== Action à mener ==
=== Site Web ===
* Maintenance du serveur
* Améliorer la gestion des modifications de la page de modération
* Mieux intégrer Awstats à mediawiki
* Restructurer le wiki (voir [[Lea Linux:Modération/Structuration du wiki|Modération/Structuration du wiki]])

=== Manifestations ===
* 31 Janvier au 2 Février 2006 : Linux Solutions 2006
* Juillet 2006 : RMLL à Nancy ???
* Léa-Party et Install-Parties
* Salon de l'Education

=== Lobbying ===
* Brevets logiciels
* Loi DADVSI

{{DP}}

Lea Linux:Compte-rendu AG 2005

2005-12-03T10:53:08Z

Pterjan : typo

[[Category:Association]]

= Bilan moral =
L'association Léa existe officiellement depuis maintenant 4 ans ; son existence a été rendue publique lors du salon Linux Solutions de février 2003. Le site Lea-Linux.org existe, quant à lui, depuis 1999.

Cette année a été riche en événements pour Léa.

Tout d'abord, c'était la troisième année où Léa sortait dans la vie réelle. Ainsi avons-nous participé à des manifestations, dont vous verrez le résumé plus bas.

Ensuite, le site a aussi évolué :
* en changeant de charte graphique (nous tenons à remercier Ayo et LinuxGraphic.org)
* en s'ouvrant à une contribution plus large.

Le forum et la liste aide tournent déjà grâce au support de quelques habitués : Léa les remercie de leur présence et de leur disponibilité. Néanmoins, nous sommes toujours en perpétuel quête de contributeurs pour faire « vivre » l'association, le site, le forum, les listes de diffusion etc...

Il restait à faire vivre les articles du site. Grâce au Wiki, nous espérons avec vous relever le défi de maintenir une documentation à jour.

Enfin, nous avons tout au cours de cette année fait de nombreuses actions de prosélytisme et de lobbying pour Linux et les Logiciels Libres, des conférences, des install-parties.

Du côté administratif, cet été, le siège social de l'association a déménagé en même temps que son président à l'adresse suivante : 12 rue Boucry – 75018 PARIS.

== Compte-rendu des actions ==
=== Site Web ===
==== Léa ====
Avant l'été, il a été mis en place un système de paiement de dons en ligne par carte de paiement à travers le service de Paypal. Ce service ne nécessite pas la création de compte Paypal.

Durant les RMLL, Léa a décidé d'étudier l'ouverture à la contribution sur ses articles à l'aide d'un Wiki. Après des études de faisabilité durant Juillet/Août, le CA a décidé de commencer les travaux de migration du site vers le moteur MediaWiki.

Le site de Léa tourne depuis fin Octobre sous un MediaWiki auquel nous avons ajouté quelques extensions (dont certaines sont disponibles sur la page de [[Utilisateur:Lea|Lea]]) ainsi qu'un cache statique qui sert de filtre entre les modifications et le net.

==== Forum ====
Le forum tourne toujours sous Phorum. Des maintenances correctives et de sécurité ont été effectuées.

==== Liste Aide ====
Emmanuel Fleury est toujours modérateur de la liste.

==== LinuxFrench ====
Au printemps, LinuxFrench a failli fermer ces portes lors du départ d'Albert Bruc.
Heureusement, Jean-Claude Stiegler reprend le site en accord avec Albert.
La ligne éditoriale restera la même et nous espèrons que certains d'entre vous rejoindront la rédaction passagèrement ou sur plus long terme.

=== Manifestations ===
==== Concours Kakémono ====
Pour représenter Léa lors de ces manifestations, le CA a décidé en Juin d'organiser un concours pour la réalisation d'un kakémono.

Après la délibération du jury, les délais ont été très court pour sa première sortie lors des RMLL.
Le vainqueur de ce concours a été skeepin.

==== Liste de manifestations ====
Remarque : Ce rapport ne mentionne que les actions dont le conseil d'administration a été mis au courant, il se peut donc que les actions de tous les membres de Léa ne soient pas dans ce rapport.

* '''1 au 3 février 2005 : Solutions Linux''' : Prosélytisme Linux et vente de CDs, Léa-Books et T-Shirts. Léa a remporté le 1er prix du meilleur site web aux Coups de Coeur du Libre
* '''19/03/2005 : Install-Party à la Villette''' : Conférences, Install-Party et prosélytisme Linux
* '''1 et 2 avril 2005 : Game Over à Limoges''' : Prosélytisme Linux et vente de Live CDs, Léa-Books et T-Shirts
* '''23 au 25 avril 2004 : Libr'east''' : Prosélytisme Linux, Install Party et vente de CDs, Léa-Books et T-Shirts
* '''30 avril 2004 : AG 2004 et Léa-Party''' : AG 2004, Conférences et Repas entre membres de l'associations
* '''14 et 15 Mai 2005 Salon Multimédia de Proville''' : Prosélytisme Linux
* '''4 au 9 juillet 2005 : RMML à Dijon''' : Prosélytisme Linux et vente de CDs, Léa-Books et T-Shirts. Le stand de Léa a remporté le second prix ex-aequo du stand le plus sympa du village, lors d'une soirée aux Tanneries (espace autogéré)
* '''9, 10 et 11 Septembre 2005 : Fête de l'Huma''' : Prosélytisme Linux
* '''14 et 15 Octobre 2005 : Journées du Logiciel Libre à Lyon''' : Prosélytisme Linux

=== Lobbying ===
* Lors du Salon Linux Solution, Léa a participé matériellement, humainement et financièrement à la tenue d'un stand de conférences libres sur le Libre.

== Action à mener ==
=== Site Web ===
* Maintenance du serveur
* Améliorer la gestion des modifications de la page de modération
* Mieux intégrer Awstats à mediawiki
* Restructurer le wiki (voir [[Lea Linux:Modération/Structuration du wiki|Modération/Structuration du wiki]])

=== Manifestations ===
* 31 Janvier au 2 Février 2006 : Linux Solutions 2006
* Juillet 2006 : RMLL à Nancy ???
* Léa-Party et Install-Parties
* Salon de l'Education

=== Lobbying ===
* Brevets logiciels
* Loi DADVSI

{{DP}}

Lea Linux:Statuts du 03-12-2005

2005-12-03T10:50:47Z

Pterjan : Vraie liste

[[Category:Association]]
Ecrits par les membres fondateurs : Frédéric Bonnaud, Jean-Christophe Cardot, Anne-Laure Nicolas, Serge Tchesmeli.

= Article 1 : constitution et dénomination =
Il est fondé entre les adhérents aux présents statuts une association régie par la loi du 1er juillet 1901 et le décret du 16 août 1901, ayant pour dénomination l'association Léa (Linux entre amis).

= Article 2 : objet =
Cette association a pour but de promouvoir et de défendre par tous les moyens dont elle dispose, y compris juridiques, les logiciels libres au sens ou l'entendent l'association « Free Software Foundation (FSF) » et l'organisme « Open Source Initiative (OSI) », dont le système d'exploitation Linux, afin d'aider à leur installation et configuration par divers moyens tels que :
* la rédaction et la publication d'articles en ligne, en particulier sur les sites web http://lea-linux.org, http://linuxfrench.net et http://asill.org animés par l'association ou sur tout autre site partenaire,
* la publication permanente et en langue française d'articles et de brèves réalisés par ou pour l'association et ceci sur tous les formats possibles (numérique ou non),
* des réunions d'utilisateurs avec des conférences et des débats animés par l'association ou des personnes externes,
* la présence et interventions dans diverses manifestations,
* la défense légale des documentations réalisées par ses membres.

= Article 3 : siège social =
Le siège social est fixé à l'adresse suivante :
:c/o Jean-Christophe Cardot
:12, rue Boucry
:75018 PARIS

Il pourra être transféré par simple décision du conseil d'administration.

= Article 4 : durée =
La durée de l'association est de 99 ans.

= Article 5 : composition de l'association =
L'association se compose de :
* '''membres actifs'''. Sont membres actifs ceux qui sont à jour de leur cotisation annuelle. Il peut y avoir deux types de membres actifs : les personnes physiques et les personnes morales. Ils disposent chacun d'une voix lors des votes de l'assemblée générale. Si une personne physique est également représentante d'une personne morale, elle dispose d'une voix en tant que personne physique, et d'une voix en tant que personne morale.
* '''membres d'honneur'''. Le titre de membre d'honneur peut être décerné par le conseil d' administration aux personnes qui rendent ou ont rendu des services signalés à l'association. Les membres d' honneur sont des membres de l' Assemblée Générale et ne sont pas tenus de payer une cotisation annuelle.
* '''membres bienfaiteurs'''. Personnes physiques ou morales qui auront versé une cotisation annuelle au moins double de la cotisation des membres actifs.

= Article 6 : admission et adhésion =
Pour faire partie de l'association, il faut adhérer aux présents statuts, être agréé par le conseil d'administration, avoir souscrit un bulletin d'adhésion qui précise la qualité de l'adhérant (personne morale ou physique), avoir acquitté un droit d'entrée égal à la cotisation annuelle.

En cas de refus d'une adhésion par le conseil d'administration (un avis sera alors transmis à l'intéressé), le droit d'entrée éventuellement perçu sera intégralement remboursé.

= Article 7 : cotisation =
Une cotisation annuelle doit être acquittée par les adhérents. Son montant est fixé chaque année par le conseil d'administration. Celui-ci pourra être différent pour les personnes physiques et les personnes morales.

Sur décision du conseil d'administration, un ou tous les membres de l'association peuvent être dispensés de cotisation.

Toute cotisation pourra être rachetée moyennant le paiement d'une somme minima égale à dix fois le montant annuel sans que la somme globale ne puisse dépasser un montant de 15 (quinze) euros (cf. loi du 1er Janvier 1901, modifiée par la loi du 23 juin 1948, n°48-1001.)

= Article 8 : radiation =
La qualité de membre se perd par :
* le décès,
* la démission qui doit être adressée par écrit au conseil d'administration,
* le non-paiement de la cotisation dans un délai de 2 mois après sa date d'exigibilité (validée dans ce cas par une décision du conseil d'administration),

La radiation est prononcée par le conseil d'administration pour le non-paiement de la cotisation, ou pour motif grave, l'intéressé ayant été invité par lettre recommandée à se présenter devant le bureau pour fournir des explications.

= Article 9 : ressources =
Les ressources de l'association comprennent :
* le montant des cotisations,
* les subventions de l'état et des collectivités territoriales,
* les recettes des manifestations exceptionnelles,
* toute autre ressource que peut percevoir une association régie par la loi du 1er juillet 1901 et le décret du 16 août 1901 et qui ne soit pas contraire aux règles en vigueur.

= Article 10 : bureau et conseil d'administration =
L'association est dirigée par un bureau et un conseil d'administration. Le bureau est composé des 4 membres fondateurs, permanents (sauf démission du bureau ou du conseil d'administration ou radiation de l'association). Le conseil d'administration est composé du bureau augmenté sur décision du conseil de 0 à 7 membres élus par l'assemblée générale.

Les membres fondateurs sont :
* Frédéric Bonnaud,
* Jean-Christophe Cardot,
* Anne-Laure Nicolas,
* Serge Tchesmeli (démissionnaire).

Ils forment le '''Bureau''' qui élira en son sein, lors de chaque assemblée générale, un '''président''', un '''vice-président''', un '''secrétaire''' et un '''trésorier'''. En cas de départ de l'association d'un de ces quatre membres, celui sera remplacé : provisoirement, avant la prochaine assemblée générale, par le conseil, puis par une élection pour deux ans par cette assemblée générale. De plus, le bureau peut décider d'admettre un membre en son sein, par cooptation puis vote des membres du bureau.

En cas de vacances de poste au conseil, celui-ci pourvoit de la même façon au remplacement du ou des membres aux postes vacants. De même, en cas de décision du conseil d'augmenter le nombre de ses membres, ce ou ces membres sont élus pour 2 années lors de la prochaine assemblée générale.

Les mineurs de moins de 16 ans peuvent être élus au conseil d'administration après acceptation de leur candidature par le conseil d'administration sortant.

= Article 11 : rôle des membres du bureau =
Les rôles respectifs du bureau et du conseil d'administration pourront être précisés dans le règlement intérieur.

'''Président''' 
Le président convoque les assemblées générales ainsi que le conseil d'administration et le Bureau. Il représente l'association dans tous les actes de la vie civile et est investi de tous pouvoirs à cet effet. Il peut déléguer certaines de ses attributions.
Il a notamment qualité pour ester en justice au nom de l'association, tant en demande qu'en défense.
En cas d'absence ou de maladie, il est remplacé par tout administrateur spécialement délégué par le Conseil, en priorité par le vice-président.

'''Vice-président''' 
Il remplace le président en cas d'incapacité de ce dernier à remplir ses obligations, sur demande de ce dernier ou sur demande du bureau.

'''Responsable de la publication technique et éditoriale''' 
Le responsables de la publication est chargé d'assurer la coordination des articles publiés ainsi que de leur validité.
Il est défini deux postes :
un responsable de la publication technique
un responsable de la publication éditoriale
Ceux-ci sont nommés par le bureau et peuvent être membre de celui-ci ou bien du conseil d'administration de l'association.

'''Secrétaire''' 
Le Secrétaire est chargé de tout ce qui concerne la correspondance et des archives.
Il rédige les procès verbaux des délibérations
Il tient le registre spécial prévu par la loi et assure l'exécution des formalités prescrites.

'''Trésorier''' 
Le trésorier est chargé de tenir, ou faire tenir, sous son contrôle, la comptabilité de l'association. Il perçoit toute recette ; il effectue tout paiement, sous réserve de l'autorisation du président ainsi que l'inventaire. En cas d'empêchement, il est remplacé par le président.

À l'égard des organismes bancaires ou postaux, le président, le trésorier, ou tout autre personne désignée par le président avec l'accord du conseil d'administration, ont pouvoir, chacun séparément, de signer tous moyens de paiement (chèques, virements...).

= Article 12 : réunion du conseil d'administration =
Le conseil d'administration se réunit tous les six mois, sur convocation du président, ou sur demande de la moitié de ses membres. Au moins la moitié des membres doivent être présents pour que le conseil d'administration puisse délibérer valablement.

Il est tenu un compte-rendu des séances.

Les décisions sont prises à la majorité des voix; en cas de partage, la voix du président est prépondérante.

Tout membre du conseil qui, sans excuse, n'aura pas assisté à trois réunions consécutives, pourra être considéré comme démissionnaire par le conseil d'administration.

Ces réunions pourront être faite «en ligne» sur internet (via des outils de communication en direct) au cas où plusieurs membres sont dans l'incapacité de se déplacer.

= Article 13 : assemblée générale ordinaire =
L'assemblée générale ordinaire se réunit une fois par an et comprend tous les membres de l'association à jour de leur cotisation. Quinze jours au moins avant la date fixée, les membres de l'association sont convoqués. La convocation pourra se faire par courrier, courrier électronique ou tout autre moyen de communication. L'ordre du jour sera communiqué sur les convocations.

Le président, assisté des membres du conseil, préside l'assemblé et expose la situation morale de l'association. Le trésorier rend compte de sa gestion et expose la situation financière. Le bilan est soumis à l'approbation de l'assemblée.

L'assemblée délibère ensuite sur les orientations à venir ; il est procédé, après épuisement de l'ordre du jour, au remplacement, au scrutin secret, des membres du conseil éventuellement sortants.

Les membres empêchés peuvent se faire représenter par un autre membre de l' association au moyen d' un pouvoir écrit (par voie électronique signée, par fax ou par courier).

= Article 14 : assemblée générale extraordinaire =
Si besoin est, ou sur demande d'un tiers plus un des membres inscrits, le président peut convoquer une assemblée générale extraordinaire, suivant les formalités de l'article treize.

= Article 15 : rémunération =
Les membres de l'association ont droit au remboursement des dépenses engagées pour l'association, sur présentation de justificatifs et après accord du bureau.

Les frais de déplacements seront remboursés sur le barème de l'administration fiscale. Leurs fonctions sont principalement bénévoles mais une rémunération exceptionnelle peut être prévue dans les limites fixées par la réglementation fiscale.

= Article 16 : règlement intérieur =
Un règlement intérieur peut être établi par le conseil d'administration qui le fait alors approuver par l'assemblée générale ordinaire. Il s'impose à tous les membres de l'association.

Ce règlement permettra de bien cerner l'esprit de l'association, et donnera des directives et des conseils pour le fonctionnement de l' association. Et il pourra permettre éventuellement de fixer les divers points non prévus par les statuts.

Il pourra être modifié par le conseil d'administration, et ratifié par l'assemblée générale ordinaire.

Ce règlement éventuel est destiné à fixer les divers points non prévus par les statuts.

= Article 17 : dissolution =
La dissolution est prononcée par l'assemblée générale extraordinaire qui nomme un liquidateur. L'actif, s'il y a lieu, sera dévolu conformément à l'article 9 de la loi du 1er juillet 1901 et au décret du 16 août 1901, en faveur d'une ou plusieurs associations ayant un objet voisin.

{{DP}}

Lea Linux:Statuts du 03-12-2005

2005-12-03T10:50:24Z

Pterjan : Vraie liste

[[Category:Association]]
Ecrits par les membres fondateurs : Frédéric Bonnaud, Jean-Christophe Cardot, Anne-Laure Nicolas, Serge Tchesmeli.

= Article 1 : constitution et dénomination =
Il est fondé entre les adhérents aux présents statuts une association régie par la loi du 1er juillet 1901 et le décret du 16 août 1901, ayant pour dénomination l'association Léa (Linux entre amis).

= Article 2 : objet =
Cette association a pour but de promouvoir et de défendre par tous les moyens dont elle dispose, y compris juridiques, les logiciels libres au sens ou l'entendent l'association « Free Software Foundation (FSF) » et l'organisme « Open Source Initiative (OSI) », dont le système d'exploitation Linux, afin d'aider à leur installation et configuration par divers moyens tels que :
* la rédaction et la publication d'articles en ligne, en particulier sur les sites web http://lea-linux.org, http://linuxfrench.net et http://asill.org animés par l'association ou sur tout autre site partenaire,
* la publication permanente et en langue française d'articles et de brèves réalisés par ou pour l'association et ceci sur tous les formats possibles (numérique ou non),
* des réunions d'utilisateurs avec des conférences et des débats animés par l'association ou des personnes externes,
* la présence et interventions dans diverses manifestations,
* la défense légale des documentations réalisées par ses membres.

= Article 3 : siège social =
Le siège social est fixé à l'adresse suivante :
:c/o Jean-Christophe Cardot
:12, rue Boucry
:75018 PARIS

Il pourra être transféré par simple décision du conseil d'administration.

= Article 4 : durée =
La durée de l'association est de 99 ans.

= Article 5 : composition de l'association =
L'association se compose de :
* '''membres actifs'''. Sont membres actifs ceux qui sont à jour de leur cotisation annuelle. Il peut y avoir deux types de membres actifs : les personnes physiques et les personnes morales. Ils disposent chacun d'une voix lors des votes de l'assemblée générale. Si une personne physique est également représentante d'une personne morale, elle dispose d'une voix en tant que personne physique, et d'une voix en tant que personne morale.
* '''membres d'honneur'''. Le titre de membre d'honneur peut être décerné par le conseil d' administration aux personnes qui rendent ou ont rendu des services signalés à l'association. Les membres d' honneur sont des membres de l' Assemblée Générale et ne sont pas tenus de payer une cotisation annuelle.
* '''membres bienfaiteurs'''. Personnes physiques ou morales qui auront versé une cotisation annuelle au moins double de la cotisation des membres actifs.

= Article 6 : admission et adhésion =
Pour faire partie de l'association, il faut adhérer aux présents statuts, être agréé par le conseil d'administration, avoir souscrit un bulletin d'adhésion qui précise la qualité de l'adhérant (personne morale ou physique), avoir acquitté un droit d'entrée égal à la cotisation annuelle.

En cas de refus d'une adhésion par le conseil d'administration (un avis sera alors transmis à l'intéressé), le droit d'entrée éventuellement perçu sera intégralement remboursé.

= Article 7 : cotisation =
Une cotisation annuelle doit être acquittée par les adhérents. Son montant est fixé chaque année par le conseil d'administration. Celui-ci pourra être différent pour les personnes physiques et les personnes morales.

Sur décision du conseil d'administration, un ou tous les membres de l'association peuvent être dispensés de cotisation.

Toute cotisation pourra être rachetée moyennant le paiement d'une somme minima égale à dix fois le montant annuel sans que la somme globale ne puisse dépasser un montant de 15 (quinze) euros (cf. loi du 1er Janvier 1901, modifiée par la loi du 23 juin 1948, n°48-1001.)

= Article 8 : radiation =
La qualité de membre se perd par :
* le décès,
* la démission qui doit être adressée par écrit au conseil d'administration,
* le non-paiement de la cotisation dans un délai de 2 mois après sa date d'exigibilité (validée dans ce cas par une décision du conseil d'administration),

La radiation est prononcée par le conseil d'administration pour le non-paiement de la cotisation, ou pour motif grave, l'intéressé ayant été invité par lettre recommandée à se présenter devant le bureau pour fournir des explications.

= Article 9 : ressources =
Les ressources de l'association comprennent :
- le montant des cotisations,
- les subventions de l'état et des collectivités territoriales,
- les recettes des manifestations exceptionnelles,
- toute autre ressource que peut percevoir une association régie par la loi du 1er juillet 1901 et le décret du 16 août 1901 et qui ne soit pas contraire aux règles en vigueur.

= Article 10 : bureau et conseil d'administration =
L'association est dirigée par un bureau et un conseil d'administration. Le bureau est composé des 4 membres fondateurs, permanents (sauf démission du bureau ou du conseil d'administration ou radiation de l'association). Le conseil d'administration est composé du bureau augmenté sur décision du conseil de 0 à 7 membres élus par l'assemblée générale.

Les membres fondateurs sont :
* Frédéric Bonnaud,
* Jean-Christophe Cardot,
* Anne-Laure Nicolas,
* Serge Tchesmeli (démissionnaire).

Ils forment le '''Bureau''' qui élira en son sein, lors de chaque assemblée générale, un '''président''', un '''vice-président''', un '''secrétaire''' et un '''trésorier'''. En cas de départ de l'association d'un de ces quatre membres, celui sera remplacé : provisoirement, avant la prochaine assemblée générale, par le conseil, puis par une élection pour deux ans par cette assemblée générale. De plus, le bureau peut décider d'admettre un membre en son sein, par cooptation puis vote des membres du bureau.

En cas de vacances de poste au conseil, celui-ci pourvoit de la même façon au remplacement du ou des membres aux postes vacants. De même, en cas de décision du conseil d'augmenter le nombre de ses membres, ce ou ces membres sont élus pour 2 années lors de la prochaine assemblée générale.

Les mineurs de moins de 16 ans peuvent être élus au conseil d'administration après acceptation de leur candidature par le conseil d'administration sortant.

= Article 11 : rôle des membres du bureau =
Les rôles respectifs du bureau et du conseil d'administration pourront être précisés dans le règlement intérieur.

'''Président''' 
Le président convoque les assemblées générales ainsi que le conseil d'administration et le Bureau. Il représente l'association dans tous les actes de la vie civile et est investi de tous pouvoirs à cet effet. Il peut déléguer certaines de ses attributions.
Il a notamment qualité pour ester en justice au nom de l'association, tant en demande qu'en défense.
En cas d'absence ou de maladie, il est remplacé par tout administrateur spécialement délégué par le Conseil, en priorité par le vice-président.

'''Vice-président''' 
Il remplace le président en cas d'incapacité de ce dernier à remplir ses obligations, sur demande de ce dernier ou sur demande du bureau.

'''Responsable de la publication technique et éditoriale''' 
Le responsables de la publication est chargé d'assurer la coordination des articles publiés ainsi que de leur validité.
Il est défini deux postes :
un responsable de la publication technique
un responsable de la publication éditoriale
Ceux-ci sont nommés par le bureau et peuvent être membre de celui-ci ou bien du conseil d'administration de l'association.

'''Secrétaire''' 
Le Secrétaire est chargé de tout ce qui concerne la correspondance et des archives.
Il rédige les procès verbaux des délibérations
Il tient le registre spécial prévu par la loi et assure l'exécution des formalités prescrites.

'''Trésorier''' 
Le trésorier est chargé de tenir, ou faire tenir, sous son contrôle, la comptabilité de l'association. Il perçoit toute recette ; il effectue tout paiement, sous réserve de l'autorisation du président ainsi que l'inventaire. En cas d'empêchement, il est remplacé par le président.

À l'égard des organismes bancaires ou postaux, le président, le trésorier, ou tout autre personne désignée par le président avec l'accord du conseil d'administration, ont pouvoir, chacun séparément, de signer tous moyens de paiement (chèques, virements...).

= Article 12 : réunion du conseil d'administration =
Le conseil d'administration se réunit tous les six mois, sur convocation du président, ou sur demande de la moitié de ses membres. Au moins la moitié des membres doivent être présents pour que le conseil d'administration puisse délibérer valablement.

Il est tenu un compte-rendu des séances.

Les décisions sont prises à la majorité des voix; en cas de partage, la voix du président est prépondérante.

Tout membre du conseil qui, sans excuse, n'aura pas assisté à trois réunions consécutives, pourra être considéré comme démissionnaire par le conseil d'administration.

Ces réunions pourront être faite «en ligne» sur internet (via des outils de communication en direct) au cas où plusieurs membres sont dans l'incapacité de se déplacer.

= Article 13 : assemblée générale ordinaire =
L'assemblée générale ordinaire se réunit une fois par an et comprend tous les membres de l'association à jour de leur cotisation. Quinze jours au moins avant la date fixée, les membres de l'association sont convoqués. La convocation pourra se faire par courrier, courrier électronique ou tout autre moyen de communication. L'ordre du jour sera communiqué sur les convocations.

Le président, assisté des membres du conseil, préside l'assemblé et expose la situation morale de l'association. Le trésorier rend compte de sa gestion et expose la situation financière. Le bilan est soumis à l'approbation de l'assemblée.

L'assemblée délibère ensuite sur les orientations à venir ; il est procédé, après épuisement de l'ordre du jour, au remplacement, au scrutin secret, des membres du conseil éventuellement sortants.

Les membres empêchés peuvent se faire représenter par un autre membre de l' association au moyen d' un pouvoir écrit (par voie électronique signée, par fax ou par courier).

= Article 14 : assemblée générale extraordinaire =
Si besoin est, ou sur demande d'un tiers plus un des membres inscrits, le président peut convoquer une assemblée générale extraordinaire, suivant les formalités de l'article treize.

= Article 15 : rémunération =
Les membres de l'association ont droit au remboursement des dépenses engagées pour l'association, sur présentation de justificatifs et après accord du bureau.

Les frais de déplacements seront remboursés sur le barème de l'administration fiscale. Leurs fonctions sont principalement bénévoles mais une rémunération exceptionnelle peut être prévue dans les limites fixées par la réglementation fiscale.

= Article 16 : règlement intérieur =
Un règlement intérieur peut être établi par le conseil d'administration qui le fait alors approuver par l'assemblée générale ordinaire. Il s'impose à tous les membres de l'association.

Ce règlement permettra de bien cerner l'esprit de l'association, et donnera des directives et des conseils pour le fonctionnement de l' association. Et il pourra permettre éventuellement de fixer les divers points non prévus par les statuts.

Il pourra être modifié par le conseil d'administration, et ratifié par l'assemblée générale ordinaire.

Ce règlement éventuel est destiné à fixer les divers points non prévus par les statuts.

= Article 17 : dissolution =
La dissolution est prononcée par l'assemblée générale extraordinaire qui nomme un liquidateur. L'actif, s'il y a lieu, sera dévolu conformément à l'article 9 de la loi du 1er juillet 1901 et au décret du 16 août 1901, en faveur d'une ou plusieurs associations ayant un objet voisin.

{{DP}}

Discussion Lea Linux:AG 2005

2005-11-17T23:14:55Z

Pterjan :

* [[Utilisateur:ST|ST]] (AG + Confs + Soirée) - 1 personne
* [[Utilisateur:Maston28|Maston28]] (AG + Confs + Soirée) - 1 personne
* [[Utilisateur:Fred|Fred]] (AG + Confs + Soirée ... si hébergement) - 1 personne
* [[Utilisateur:Ennael|Anne]] (AG + Confs + Soirée) - 2 personnes
* [[Utilisateur:Phlogistique|Noé Rubinstein]] (Confs) - 1 personne - pas sur
* [[Utilisateur:Zragg|Zragg]] (AG + Confs + Soirée) - 1 personnes
* [[Utilisateur:Philheap|Philheap]] (AG + Confs + Soirée) - 2 personnes
* [[Utilisateur:LeaJice|Jice]] (AG + Confs + Soirée) - 1 personne
* [[Utilisateur:Pterjan|CMoi]] (Confs + Soirée) - 1 personne

Iptables

2005-10-26T10:14:30Z

Pterjan : DENY -> DROP

[[Category:Sécurité]]
= IpTables par l'exemple =

<div class="leatitre">IpTables par l'exemple</div><div class="leapar">Arnaud de Bermingham</div><div class="leadesc">IpTables par l'exemple</div>
----

''Contact : [mailto:duracell chez apinc point org duracell chez apinc point org]'' ''révision par Jice <[mailto:jice chez lea-linux point org jice chez lea-linux point org]>'' ''révision par Fred <[mailto:fred chez lea-linux point org fred chez lea-linux point org]>''

== Introduction ==

Cet article présente de façon pratique la mise en place d'un firewall / proxy sur une machine Linux tournant avec un noyau 2.4. Pour des informations plus théoriques sur les firewall/proxies, vous pouvez lire l'[firewall.php3 article firewall].

=== <nowiki>* Présentation d'IpTables</nowiki> ===

IpTables est une solution complète de firewall (noyau 2.4) remplaçant ''ipchains'' (noyau 2.2) tournant sous le système GNU/Linux. IpTables permet de faire du firewalling ''stateful'' (à états), de la translation de port et d'adresse, du filtrage au niveau 2 et beaucoup d'autres choses que nous n'allons pas aborder comme le "Mangle" ou modification des paquets à la volée (atchoum).

IpTables est fiable et dispose de très nombreuses options qui permettent de faire du filtrage très fin.

=== <nowiki>* Licence de cet article</nowiki> ===

Cette documentation est sous licence LDP

=== <nowiki>* Licence de NetFilter</nowiki> ===

NetFilter est sous licence libre GPL, i.e. gratuit et modifiable du moment que les modifications et améliorations apportées soit rendues publiques.

== 1/ Installation ==

=== 1.1/ Prérequis ===

IpTables est installé en standard sur de nombreuses distributions Linux récentes. En particulier, il est installé sur Linux RedHat 7.1 et sur la plupart des distributions basées sur un kernel 2.4.x.

IpTables a besoin d'un '''kernel de génération 2.4''' compilé avec des options spéciales. Ceci ne pose pas de problèmes avec les noyaux 2.4 génériques des principales distributions basées sur cette génération de kernel.

=== 1.2/ Options de compilation du kernel ===

Si vous désirez re-compiler votre kernel, il faut spécifier les options nécessaires au fonctionnement d'iptables.

Les options suivantes doivent êtres activées en module (<tt>M</tt>) ou dans le kernel (<tt>Y</tt>) :

<tt>CONFIG_PACKET</tt> <tt>CONFIG_NETFILTER</tt>

<tt>CONFIG_IP_NF_CONNTRACK</tt> <tt>CONFIG_IP_NF_FTP</tt> <tt>CONFIG_IP_NF_IRC</tt> <tt>CONFIG_IP_NF_IPTABLES</tt> <tt>CONFIG_IP_NF_FILTER</tt> <tt>CONFIG_IP_NF_NAT</tt> <tt>CONFIG_IP_NF_MATCH_STATE</tt> <tt>CONFIG_IP_NF_TARGET_LOG</tt> <tt>CONFIG_IP_NF_MATCH_LIMIT</tt> <tt>CONFIG_IP_NF_TARGET_MASQUERADE</tt>

et éventuellement :

<tt>CONFIG_IP_NF_COMPAT_IPCHAINS</tt> pour garder la compatibilité avec ipchains. <tt>CONFIG_IP_NF_COMPAT_IPFWADM</tt> pour garder la compatibilité avec ipfwadm. <tt>CONFIG_IP_NF_TARGET_REDIRECT</tt> indispensable, pour les proxies transparents par exemple. <tt>CONFIG_IP_NF_MATCH_MAC</tt> permet de matcher avec les adresses MAC.

Ne pas oublier le support réseau et TCP/IP et compiler le kernel comme d'habitude : <tt>make dep && make clean && make bzImage && make modules && make modules_install</tt>

=== 1.3/ Installation ===

Sur une RedHat 7.1, récupérer le package <tt>netfilter</tt> et l'installer comme d'habitude avec <tt>rpm -Uvh netfilter-x.y.z.rpm</tt>. Sur les versions inférieures a la 7.1, il faut compiler un kernel 2.4 car iptables ne supporte pas les kernels 2.2.x. La compilation de iptables est complexe. Le mieux est de lire le fichier INSTALL du package des sources.

=== 1.4/ Chargement des modules ===

Dans le cas ou les options iptables du kernel ont étés compilées en modules, il est nécessaire de charger ces modules avant de pouvoir utiliser iptables :

<tt><nowiki># modprobe ip_tables</nowiki></tt>

selon les besoins, on peut éventuellement charger les modules suivants :

<blockquote><tt><nowiki># modprobe ip_nat_ftp</nowiki></tt> <tt><nowiki># modprobe ip_nat_irc</nowiki></tt> <tt><nowiki># modprobe iptable_filter</nowiki></tt> <tt><nowiki># modprobe iptable_mangle</nowiki></tt> <tt><nowiki># modprobe iptable_nat</nowiki></tt></blockquote>

Si on a besoin de pouvoir forwarder<nowiki>*</nowiki> les paquets IP (dans la plupart des cas), il sera nécessaire d'exécuter cette commande :

<blockquote><tt><nowiki># echo 1 > /proc/sys/net/ipv4/ip_forward</nowiki></tt></blockquote>

afin de l'indiquer au noyau.

; <nowiki>* </nowiki>forwarder
: il s'agit de faire passer des paquets IP d'une interface réseau vers une autre. Par exemple, un paquet qui arrive de l'internet via un modem ou une carte réseau sera ''redirigé'' (ou ''forwardé'') vers la carte réseau par laquelle le firewall est attaché au réseau local.

'''Nota Bene :''' tous les modprobe semblent inutiles car le kernel les chargent automatiquement si l'on se sert de l'une des fonctionnalités d'iptables.

== 2/ Présentation ==

=== 2.1/ Les tables ===

* '''Table NAT''' (Network Address Translation) : Table utilisée pour la translation d'adresse ou la translation de port. Il a 2 types de chaînes<nowiki>#</nowiki> : ''PREROUTING'' qui permet de spécifier "à l'arrivée du firewall" et la chaîne ''POSTROUTING'' qui permet de spécifier "à la sortie du firewall". Il existe 3 targets (ou cibles) : ''DNAT<nowiki>*</nowiki>, SNAT<nowiki>*</nowiki>'' et ''MASQUERADE<nowiki>*</nowiki>''.
* '''Table FILTER''' : C'est la table par défaut lorsque l'on en spécifie pas. Cette table contient toutes les règles de filtrage, il existe 3 types de chaînes : ''FORWARD'' pour les paquets passant par le firewall, ''INPUT'' pour les paquets entrant et ''OUTPUT'' pour les paquets sortants. Les cibles disponibles sont : ''ACCEPT, DENY, DROP, REJECT °''.
* '''Table Mangle''' : C'est la table qui contient les règles pour la modification de paquets. Elle est peu utilisée et ne sera pas décrite dans cet article.

A noter : Les règles sont matchées dans l'ordre, par défaut la table ''FILTER'' est vide et donc accepte tout. Aucune règle de translation d'adresse n'est présente par défaut.

; <nowiki>#</nowiki> chaîne
: une chaîne est une suite de règles, qui sont prises dans l'ordre ; dès qu'une règle matche un paquet, elle est déclenchée, et la suite de la chaîne est ignorée.
; * SNAT
: permet de modifier l'adresse source du paquet.
; * DNAT
: permet de modifier l'adresse destination du paquet.
; * MASQUERADE
: Une gateway transforme les paquets sortants passant par elle pour donner l'illusion qu'ils sortent de la gateway elle-même par un port alloué dynamiquement ; lorsque la gateway recoit une réponse sur ce port, elle utilise une table de correspondance entre le port et les machines du réseau privé qu'elle gère pour lui faire suivre le paquet.
; ° policy ACCEPT
: permet d'accepter un paquet grâce à la règle vérifiée.
; ° policy DROP
: Rejet d'un paquet sans message d'erreur si la règle est vérifiée ("non ! j'en veux pas mais je dis rien à l'expediteur").
; ° policy REJECT
: Rejet avec un retour de paquet d'erreur à l'expediteur si la la règle est verifiée ("un paquet recommandé de La Poste refusé par son destinataire").

=== 2.2/ Les commandes ===

IpTables n'est pas livré avec une interface graphique ; les commandes et les règles sont passées en ligne de commande. Le mieux est d'écrire des scripts (à rajouter dans <tt>/etc/rc.d/init.d</tt>) qui permettent d'appliquer toutes les règles d'un seul coup, dès le démarrage du Linux.

==== 2.2.1/ Commandes principales ====

<tt>-A --append</tt> : Ajoute la règle à la fin de la chaîne spécifiée ''Exemple :'' <tt><nowiki># iptables -A INPUT ...</nowiki></tt>

<tt>-D --delete</tt> : Permet de supprimer une chaîne. On peut la matcher de 2 manières, soit en spécifiant le numéros de la chaîne a supprimer, soit en spécifiant la règle à retirer. ''Exemples :'' <tt><nowiki># iptables -D INPUT --dport 80 -j DROP</nowiki></tt> <tt><nowiki># iptables -D INPUT 1</nowiki></tt>

<tt>-R --replace</tt> : Permet contrairement à <tt>--delete</tt> de remplacer la chaîne spécifiée. ''Exemple :'' <tt><nowiki># iptables -R INPUT 1 -s 192.168.0.1 -j DROP</nowiki></tt>

<tt>-I --insert</tt> : Permet d'ajouter une chaîne dans un endroit spécifié de la chaîne. ''Exemple :'' <tt><nowiki># iptables -I INPUT 1 --dport 80 -j ACCEPT</nowiki></tt>

<tt>-L --list</tt> : Permet d'afficher les règles. ''Exemples :'' ''<tt><nowiki># iptables -L </nowiki></tt><nowiki># Affiche toutes les règles des chaînes de FILTER</nowiki>'' ''<tt><nowiki># iptables -L INPUT </nowiki></tt><nowiki># Affiche toutes les règles de INPUT (FILTER)</nowiki>''

<tt>-F --flush</tt> : Permet de vider toutes les règles d'une chaîne. ''Exemple :'' <tt><nowiki># iptables -F INPUT</nowiki></tt>

<tt>-N --new-chain</tt> : Permet de créer une nouvelle chaîne. ''Exemple :'' <tt><nowiki># iptables -N LOG_DROP</nowiki></tt>

<tt>-X --delete-chain</tt> : Permet d'effacer une chaîne. ''Exemple :'' <tt><nowiki># iptables -X LOG_DROP</nowiki></tt>

<tt>-P --policy</tt> : Permet de spécifier au kernel la target par défaut d'une chaîne DENY, ACCEPT, REJECT, DROP ... ''Exemple :'' <tt><nowiki># iptables -P INPUT DROP</nowiki></tt>

==== 2.2.2/ Commandes pour matcher ====

Remarques :

Le "!" peut être utilisé pour certaines commandes afin de spécifier le contraire (on peut le traduire par "sauf"). Par exemple une commande qui doit refuser tout trafic TCP sauf ce qui provient de l'adresse IP 10.42.42.42 sera traduite par la commande suivante : ''Exemple :'' <tt><nowiki># iptables -A INPUT -p tcp --source ! 10.42.42.42 -j DROP</nowiki></tt>

Les adresses IP peuvent optionnellement être spécifiées avec le masque associé sous la forme [adresse ip]/[masque].

<tt>-p --protocol</tt> : Spécifier un protocole : <tt>tcp</tt>, <tt>udp</tt>, <tt>icmp</tt>, <tt>all</tt> (tous) ''Exemple :'' <tt><nowiki># iptables -A INPUT -p icmp -j DROP</nowiki></tt>

<tt>-s --source</tt> : Spécifier une adresse source à matcher ''Exemple :'' <tt><nowiki># iptables -A INPUT -p tcp -s 192.168.42.42 -j ACCEPT</nowiki></tt>

<tt>-d --destination</tt> : Spécifier une adresse destination ''Exemple :'' <tt><nowiki># iptables -A FORWARD -p tcp -d 10.1.0.1 -j ACCEPT</nowiki></tt>

<tt>-i --in-interface</tt> : Spécifier une interface d'entrée ''Exemple :'' <tt><nowiki># iptables -A INPUT -p icmp -i eth0 -j DROP</nowiki></tt>

<tt>-o --out-interface</tt> : Spécifier une interface de sortie ''Exemple :'' <tt><nowiki># iptables -A OUTPUT -p icmp -o eth0 -j DROP</nowiki></tt>

<tt>-f --fragment</tt> : Paquet fragmenté ''Exemple :'' <tt><nowiki># iptables -A INPUT -p icmp -f -j DROP</nowiki></tt>

<tt>--sport --source-port</tt> : Spécifier le port source ou une plage de ports, fonctionne aussi en udp, <tt>-m multiport</tt> permet de spécifier plusieurs ports à matcher. ''Exemples :'' <tt><nowiki># iptables -A INPUT -p tcp --sport 80 -j ACCEPT</nowiki></tt> <tt><nowiki># iptables -A INPUT -p udp --sport 80 -j DROP</nowiki></tt> <tt><nowiki># iptables -A OUTPUT -p tcp -m multiport --sport 3128,21,1000 -j DROP</nowiki></tt> <tt><nowiki># iptables -A OUTPUT -p tcp --sport 1024:2042 -j ACCEPT</nowiki></tt>

<tt>--dport --destination-port</tt> : Spécifier le port destination ou une plage de ports, fonctionne aussi en udp, <tt>-m multiport</tt> permet de spécifier plusieurs ports a matcher. ''Exemples :'' <tt><nowiki># iptables -A INPUT -p tcp --dport 110 -j DROP</nowiki></tt> <tt><nowiki># iptables -A INPUT -p udp --dport 110 -j DROP</nowiki></tt> <tt><nowiki># iptables -A INPUT -p tcp -m multiport --dport 110,4242,119 -j DROP</nowiki></tt> <tt><nowiki># iptables -A INPUT -p tcp --sport 4925:4633 -j ACCEPT</nowiki></tt>

<tt>--tcp-flags</tt> : Spécifier un flag tcp à matcher : <tt>SYN ACK FIN RST URG PSH ALL NONE</tt> ''Exemple :'' <tt><nowiki># iptables -A INPUT -p tcp --dport 42 --tcp-flags SYN,ACK -j ACCEPT</nowiki></tt>

<tt>--icmp-type</tt> : Spécifier un type de paquet icmp à matcher ''Exemple :'' <tt><nowiki># iptables -A INPUT -p icmp --icmp-type 8 -j DROP</nowiki></tt>

<tt>--mac-source</tt> : Spécifier l'adresse MAC à matcher ''Exemple :'' <tt><nowiki># iptables -A INPUT --mac-source 42.42.AA.42.42.AA -j DROP</nowiki></tt>

<tt>--state</tt> : Permet de spécifier l'état du paquet à matcher parmi les états suivants : <tt> ESTABLISHED </tt><nowiki>: paquet associé à une connexion déjà établie </nowiki> <tt> NEW </tt><nowiki>: paquet demandant une nouvelle connexion </nowiki> <tt> INVALID </tt><nowiki>: paquet associé à une connexion inconnue </nowiki> <tt> RELATED </tt><nowiki>: Nouvelle connexion mais liée, idéal pour les connexions FTP </nowiki> ''Exemples :'' <tt><nowiki># iptables -A INPUT -i eth0 -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT</nowiki></tt> <tt><nowiki># iptables -A OUTPUT -o eth0 -p tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT</nowiki></tt>

Spécificités NAT :

<tt>--to-destination</tt> : Utilisé en target pour le DNAT, permet de spécifier l'adresse de destination de la translation, on peut également spécifier un port s'il est différent du port source. ''Exemples :'' <tt><nowiki># iptables -t nat -A PREROUTING -d 42.12.42.12 -p tcp --dport 110 -j DNAT --to-destination 192.168.1.2:6110</nowiki></tt> <tt><nowiki># iptables -t nat -A PREROUTING -d ! 42.12.42.12 -p tcp --dport 80 -j DNAT --to-destination 192.168.2.1:3128</nowiki></tt>

<tt>--to-source</tt> : Utilisé pour en target pour le SNAT, permet de spécifier l'adresse source de la translation.

Spécificités pour les LOGS :

<tt>--log-level</tt> : Level, niveau de log ''Exemple : Cf. chapitre 3''

<tt>--log-prefix</tt> : Permet de spécifier un préfixe pour les logs. ''Exemple : Cf. chapitre 3'' 

==== 2.2.3/ Quelques exemples : ====

Les exemples qui suivent supposent que vous êtes reliés à internet par modem via l'interface ppp0 (mais en remplaçant ppp0 par eth0 - par exemple, on peut adapter les exemples pour d'autres type de liaisons) et que votre réseau local est 192.168.1.0/24 (classe C).

* Pour fixer les '''politiques par défaut''' (cad: ce qui se passe quand aucune règle ne correspond - ne matche pas), ici, on refuse tout (normal, on fait un firewall, oui ou non ?) : <blockquote><tt> iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP</tt></blockquote>
* Pour '''logguer''' tout ce qu'on jette : <blockquote><tt> iptables -N LOG_DROP iptables -A LOG_DROP -j LOG --log-prefix '[IPTABLES DROP] : ' iptables -A LOG_DROP -j DROP</tt></blockquote> Et ensuite, plutôt que de mettre <tt>-j DROP</tt>, il faut mettre <tt>-j LOG_DROP</tt> et les trois dernières règles doivent être : <blockquote><tt> iptables -A FORWARD -j LOG_DROP iptables -A INPUT -j LOG_DROP iptables -A OUTPUT -j LOG_DROP </tt></blockquote>
* Pour '''accepter''' tout ce qui se passe sur l'interface <tt>lo</tt> (sinon ce n'est pas la peine d'activer le réseau !) : <blockquote><tt> iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT </tt></blockquote>
* Pour '''accepter''' tout ce qui se passe sur le '''réseau local''' <tt>192.168.1.0</tt> : <blockquote><tt> iptables -A INPUT -s 192.168.1.0/24 -j ACCEPT iptables -A OUTPUT -d 192.168.1.0/24 -j ACCEPT iptables -A FORWARD -s 192.168.1.0/24 -j ACCEPT </tt></blockquote>
* Pour accepter les résolutions de nom (ie: le '''dns''') : <blockquote><tt> iptables -A INPUT -i ppp0 --protocol udp --source-port 53 -j ACCEPT iptables -A OUTPUT -o ppp0 --protocol udp --destination-port 53 -j ACCEPT iptables -A INPUT -i ppp0 --protocol tcp --source-port 53 -j ACCEPT iptables -A OUTPUT -o ppp0 --protocol tcp --destination-port 53 -j ACCEPT </tt></blockquote>
* Pour accepter le traffic '''web''' (on veut surfer!) : <blockquote><tt> iptables -A INPUT -i ppp0 --protocol tcp --source-port 80 -m state --state ESTABLISHED -j LOG_ACCEPT iptables -A OUTPUT -o ppp0 --protocol tcp --destination-port 80 -m state --state NEW,ESTABLISHED -j LOG_ACCEPT</tt></blockquote> La première ligne pour accepter ce qui entre sur notre interface ppp0 sur le port 80 (le port http) si c'est une connexion déjà établie, la seconde pour accepter ce qui sort sur ppp0 sur le port 80 si c'est une nouvelle connexion ou si c'est une connexion déjà établie.
Pour autoriser le '''ssh''', il faut préciser le port 22; pour autoriser l''''irc''', le port 6667 (ou celui que vous utilisez pour vous connecter à votre serveur); pour le '''smtp''' (envoi d'emails), le port 25; pour le '''pop3''' (réception d'emails), le port 110; pour le '''imap''' (réception d'emails), les ports 143 et 220 ('''imap3''') ; pour le '''cvs''', le port 2401 ; pour le '''https''', le port 443. De manière générale, le numéros de port se trouvent dans /etc/services.
* Pour le '''ftp''' c'est un peu plus complexe. D'abord, il faut charger le module : <tt>ip_conntrack_ftp</tt> (c'est lui qui suit - track en anglais - les connexions ftp) et, si vous ''nat''ez (en utilisant le masquerading par exemple) vos connexions ftp vers d'autres postes le module : <tt>ip_nat_ftp</tt> : <blockquote><tt> modprobe ip_conntrack_ftp</tt> # éventuellement : <tt> modprobe ip_nat_ftp</tt> </blockquote> Ensuite, il faut taper les commandes suivantes : <blockquote><tt> iptables -A INPUT -i ppp0 -p tcp --sport 21 -m state --state ESTABLISHED -j ACCEPT iptables -A OUTPUT -o ppp0 -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT </tt></blockquote> Cela pour que la connexion puisse s'établir. Ensuite (et c'est la qu'on a besoin de <tt>ip_conntrack_ftp</tt>) : <blockquote><tt> iptables -A INPUT -i ppp0 -p tcp --sport 20 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -o ppp0 -p tcp --dport 20 -m state --state ESTABLISHED -j ACCEPT </tt></blockquote> Pour que serveur puisse établir la connexion pour les données (en mode actif). Et enfin : <blockquote><tt> iptables -A INPUT -i ppp0 -p tcp --sport 1024:65535 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT iptables -A OUTPUT -o ppp0 -p tcp --sport 1024:65535 --dport 1024:65535 -m state --state ESTABLISHED,RELATED -j ACCEPT </tt></blockquote> Pour que le serveur puisse établir la connexion pour les données (en mode passif). Ici aussi <tt>ip_conntrack_ftp</tt> est nécessaire.
* Pour '''partager une connexion''', il faut que le forwarding soit activé dans le noyau (<tt>echo 1 > /proc/sys/net/ipv4/ip_forward</tt>), puis il faut autoriser iptable à faire le forwarding : <blockquote><tt> iptables -F FORWARD iptables -A FORWARD -j ACCEPT </tt></blockquote> et enfin, cacher les machines forward-ées par le firewall : <blockquote><tt> iptables -A POSTROUTING -t nat -o ppp0 -j MASQUERADE </tt></blockquote> Sur chaque machine devant être cachée par le firewall (ou devant partager la connexion avec la machine qui est connectée à internet), il faut ajouter une route par defaut : <blockquote><tt> route add default gw 192.168.1.1 </tt></blockquote> Si la machine connectée à internet a comme ip : 192.168.1.1. Il suffit avec une redhat/mandrake d'éditer : <blockquote><tt>/etc/sysconfig/network</tt></blockquote> et d'ajouter dedans : <blockquote><tt>GATEWAY=192.168.1.1</tt></blockquote> puis de redémarer le réseau :<blockquote><tt>/etc/rc.d/init.d/network restart</tt></blockquote>

== 3/ Application par l'exemple ==

Nous allons mettre en place un firewall / proxy.

Pour cet exemple, le firewall aura la connexion à Internet (interface eth2) et disposera de 2 pattes sur des réseaux privés (eth0 et eth1) :

* il fait office de proxy sur le port 3128 pour un réseau qui aura ainsi un accès internet
* et une DMZ<nowiki>*</nowiki> ("zone démilitarisée") sur laquelle il y a un ensemble de serveurs disponibles de l'extérieur dont un serveur web qui a pour adresse 192.168.1.2 écoutant sur le port 80 en TCP.

<blockquote><tt> ____ '''eth1''' '''.->''' ---+------+------+--- _/ \_ ____ 3128'''/''' [PC1] [PC2] [PC3] ( ) '''eth2'''| |'''<--'''' réseau local 198.168.2.0 (INTERNET)'''<--->'''|'''Fire'''| (_ _) ppp0|'''wall'''| \____/ |____|'''<--.''' DMZ serveurs 198.168.1.0 '''eth0\''' [WEB] [NEWS] [FTP] ''''->''' ---+------+------+--- ''ASCIIArt (c) Jice''</tt></blockquote>

La classe d'adresse IP 192.168.2.0 correspond au réseau interne sur l'interface <tt>eth1</tt>. La classe d'adresse IP 192.168.1.0 correspond a la DMZ sur l'interface <tt>eth0</tt>. L'interface de la connexion Internet est ppp0 sur l'interface <tt>eth2</tt>.

; <nowiki>* </nowiki>DMZ, ou zone démilitarisée
: Sous-réseau dans lequel des serveurs accessibles depuis internet sont en adressage privé (classe d'adresse IP réservée comme 192.168.x.x) derrière un firewall.

=== 3.1/ Le script init.d ===

Nous allons écrire un script qui permettra de charger automatiquement au démarrage de la machine ou sur demande les règles du firewall qui seront stockées dans le fichier <tt>/etc/firewall.sh</tt>. Le script de démarrage sera nommé <tt>/etc/init.d/firewall</tt>. Bien sûr, on n'oubliera pas d'exécuter un <tt>chmod +x</tt> sur les 2 scripts que nous allons créer au long de ce chapitre.

Go ! Fichier de chargement <tt>/etc/init.d/firewall</tt> : 

<center>

{| width="90%" bgcolor="#FFFFCC"
|
<tt><nowiki>#!/bin/bash</nowiki></tt> <tt><nowiki>#</nowiki></tt> <tt><nowiki># Lancement du script de Firewall</nowiki></tt> <tt><nowiki># Arnaud de Bermingham</nowiki></tt>

<tt>. /etc/init.d/functions</tt>

<tt>RETVAL=0</tt>

<tt><nowiki># Fonction pour le lancement du firewall</nowiki></tt> <tt>start() {</tt> <tt> echo -n "Application des règles IpTables: "</tt> <tt> /etc/firewall.sh</tt> <tt> RETVAL=0</tt> <tt> [ $RETVAL -eq 0 ] && touch /var/lock/subsys/firewall</tt> <tt> echo</tt> <tt>}</tt>

<tt><nowiki># Fonction pour arrêter le firewall (on flush)</nowiki></tt> <tt>stop() {</tt> <tt> echo -n "Flush des règles IpTables: "</tt> <tt> /etc/flush_iptables.sh</tt> <tt> RETVAL=0</tt> <tt> [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/firewall</tt> <tt> echo</tt> <tt>}</tt>

<tt>case $1 in</tt> <tt> start)</tt> <tt> start</tt> <tt> ;;</tt> <tt> stop)</tt> <tt> stop</tt> <tt> ;;</tt> <tt> restart)</tt> <tt> stop</tt> <tt> start</tt> <tt> ;;</tt> <tt> status)</tt> <tt> /sbin/iptables -L</tt> <tt> /sbin/iptables -t nat -L</tt> <tt> RETVAL=0</tt> <tt> ;;</tt> <tt> *)</tt> <tt> echo "Usage: firewall {start|stop|restart|status}"</tt> <tt> RETVAL=1</tt> <tt>esac</tt>

<tt>exit</tt>
|}

</center>

C'est tout simple non ?

=== 3.2/ Le script pour flusher (vider) les règles ===

Et maintenant : <tt>/etc/flush_iptables.sh</tt>.

<center>

{| width="90%" bgcolor="#FFFFCC"
|
<tt><nowiki>#!/bin/sh</nowiki></tt> <tt><nowiki># </nowiki></tt> <tt><nowiki># Script pour vider les règles iptables</nowiki></tt> <tt><nowiki># Arnaud de Bermingham</nowiki></tt> <tt><nowiki># duracell@apinc.org</nowiki></tt>

<tt><nowiki>#</nowiki></tt> <tt><nowiki># On remet la police par défaut à ACCEPT</nowiki></tt> <tt><nowiki>#</nowiki></tt> <tt>iptables -P INPUT ACCEPT</tt> <tt>iptables -P FORWARD ACCEPT</tt> <tt>iptables -P OUTPUT ACCEPT</tt>

<tt><nowiki>#</nowiki></tt> <tt><nowiki># On remet les polices par défaut pour la table NAT</nowiki></tt> <tt><nowiki>#</nowiki></tt> <tt>iptables -t nat -P PREROUTING ACCEPT</tt> <tt>iptables -t nat -P POSTROUTING ACCEPT</tt> <tt>iptables -t nat -P OUTPUT ACCEPT</tt>

<tt><nowiki>#</nowiki></tt> <tt><nowiki># On vide (flush) toutes les règles existantes</nowiki></tt> <tt><nowiki>#</nowiki></tt> <tt>iptables -F</tt> <tt>iptables -t nat -F</tt>

<tt><nowiki>#</nowiki></tt> <tt><nowiki># Et enfin, on efface toutes les chaînes qui ne</nowiki></tt> <tt><nowiki># sont pas à defaut dans la table filter et nat</nowiki></tt>

<tt>iptables -X</tt> <tt>iptables -t nat -X</tt>

<tt><nowiki># Message de fin</nowiki></tt> <tt>echo " [termine]"</tt>
|}

</center>

Bon, on va enfin commencer les choses sérieuses : le script du firewall :)

=== 3.3/ Les prérequis pour le script du firewall et création des tables pour les logs ===

Le script sera commenté au fur et à mesure, afin de décrire chaque étape. 

<center>

{| width="90%" bgcolor="#FFFFCC"
|
<tt><nowiki>#!/bin/sh</nowiki></tt>

<tt><nowiki># script </nowiki>'''/etc/firewall.sh'''</tt>

<tt><nowiki># Firewall d'exemple a but pédagogique</nowiki></tt> <tt><nowiki># Arnaud de Bermingham</nowiki></tt> <tt><nowiki># duracell@apinc.org</nowiki></tt>

<tt><nowiki># </nowiki>'''Activation du forwarding'''</tt> <tt><nowiki># C'est pas pour faire joli, on aura des règles</nowiki></tt> <tt><nowiki># de forward et il faut bien que les paquets</nowiki></tt> <tt><nowiki># traversent la machine, donc on met ce fichier à 1</nowiki></tt>

<tt>echo 1 > /proc/sys/net/ipv4/ip_forward</tt>

<tt><nowiki># Alors la, on va appliquer quelques astuces</nowiki></tt> <tt><nowiki># pour empêcher les attaques de type </nowiki>''spoofing''</tt> <tt><nowiki># et bloquer les réponses ICMP du firewall,</nowiki></tt> <tt><nowiki># comme ça c'est très propre. Attention, le</nowiki></tt> <tt><nowiki># fait de bloquer le trafic ICMP sur</nowiki></tt> <tt><nowiki># le firewall bloque les pings.</nowiki></tt>

<tt><nowiki># Je veux </nowiki>'''pas de spoofing'''</tt>

<tt>if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]</tt> <tt>then</tt> <tt> for filtre in /proc/sys/net/ipv4/conf/*/rp_filter</tt> <tt> do</tt> <tt> echo 1 > $filtre</tt> <tt> done</tt> <tt>fi</tt>

<tt><nowiki># </nowiki>'''pas de icmp'''</tt>

<tt>echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all</tt> <tt>echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts</tt>

<tt><nowiki># On va utiliser iptables. Si on l'a compilé en module</nowiki></tt> <tt><nowiki># dans le kernel, il faut </nowiki>'''charger le module ip_tables'''.</tt>

<tt>modprobe ip_tables</tt>

<tt><nowiki># on va charger quelques </nowiki>'''modules supplémentaires''' pour</tt> <tt><nowiki># gérer la </nowiki>'''translation''' d'adresse, l''''IRC''' et le '''FTP'''</tt> <tt><nowiki># Tu me fait 4 pompes. Chef oui chef !</nowiki></tt>

<tt>modprobe ip_nat_ftp</tt> <tt>modprobe ip_nat_irc</tt> <tt>modprobe iptable_filter</tt> <tt>modprobe iptable_nat</tt>

<tt><nowiki># Pour faire bien, on va </nowiki>'''vider toutes les règles'''</tt> <tt><nowiki># avant d'appliquer les nouvelles règles de firewall</nowiki></tt>

<tt>iptables -F</tt> <tt>iptables -X</tt>

<tt><nowiki># On va rajouter 2 nouvelles </nowiki>'''chaînes'''.</tt> <tt><nowiki># Ceci permettra d'ajouter des nouvelles cibles qui</nowiki></tt> <tt><nowiki># auront la possibilité de loguer ce qui se passe.</nowiki></tt>

<tt><nowiki># La on logue et on refuse le paquet,</nowiki></tt> <tt><nowiki># on rajoute un préfixe pour pouvoir</nowiki></tt> <tt><nowiki># s'y retrouver dans les logs</nowiki></tt> <tt>iptables -N LOG_DROP</tt> <tt>iptables -A LOG_DROP -j LOG \</tt> <tt> --log-prefix '[IPTABLES DROP] : '</tt> <tt>iptables -A LOG_DROP -j DROP</tt>

<tt><nowiki># ici, on logue et on accepte le paquet,</nowiki></tt> <tt><nowiki># on rajoute un préfixe pour pouvoir</nowiki></tt> <tt><nowiki># s'y retrouver dans les logs</nowiki></tt> <tt>iptables -N LOG_ACCEPT</tt> <tt>iptables -A LOG_ACCEPT -j LOG \</tt> <tt> --log-prefix '[IPTABLES ACCEPT] : '</tt> <tt>iptables -A LOG_ACCEPT -j ACCEPT</tt>

<tt><nowiki># On veut faire un firewall efficace,</nowiki></tt> <tt><nowiki># donc la politique a appliquer est de tout</nowiki></tt> <tt><nowiki># refuser par défaut et rajouter une a une</nowiki></tt> <tt><nowiki># les règles que l'on autorise.</nowiki></tt> <tt><nowiki># Bien sur, on a RTFM un peu et on a vu que</nowiki></tt> <tt><nowiki># l'option -P permet de définir</nowiki></tt> <tt><nowiki># </nowiki>'''la cible par défaut'''</tt>

<tt>iptables -P INPUT DROP</tt> <tt>iptables -P OUTPUT DROP</tt> <tt>iptables -P FORWARD DROP</tt>

<tt><nowiki># Pour éviter les problèmes, on va </nowiki>'''tout accepter sur'''</tt> <tt><nowiki># </nowiki>'''la machine en local''' (interface lo).</tt> <tt><nowiki># Je déconseille de retirer cette règle car</nowiki></tt> <tt><nowiki># ça pose pas mal de problèmes et ça peut</nowiki></tt> <tt><nowiki># faire perdre la main sur la machine</nowiki></tt>

<tt>iptables -A INPUT -i lo -j ACCEPT</tt> <tt>iptables -A OUTPUT -o lo -j ACCEPT</tt>

<tt><nowiki># Bon, la partie initialisation et préparation est</nowiki></tt> <tt><nowiki># terminée, passons aux choses sérieuses</nowiki></tt> <tt><nowiki># Comme on l'a dit dans la présentation de</nowiki></tt> <tt><nowiki># l'architecture réseau, le firewall fait</nowiki></tt> <tt><nowiki># également office de proxy grâce par exemple</nowiki></tt> <tt><nowiki># à un squid installé dessus. On va donc</nowiki></tt> <tt><nowiki># accepter que le </nowiki>'''proxy''' ait une '''connexion'''</tt> <tt><nowiki># </nowiki>'''internet directe'''. Tant qu'à faire, on va</tt> <tt><nowiki># mettre des états pour que ça soit bien sécurisé</nowiki></tt>

<tt>iptables -A OUTPUT -o ppp0 -m state \</tt> <tt> --state NEW,ESTABLISHED -p tcp --dport 80 -j ACCEPT</tt> <tt>iptables -A INPUT -i ppp0 -m state \</tt> <tt> --state ESTABLISHED -p tcp --sport 80 -j ACCEPT</tt>

<tt><nowiki># Maintenant, on va faire en sorte que le</nowiki></tt> <tt><nowiki># </nowiki>'''proxy soit totalement transparent pour le LAN'''</tt> <tt><nowiki># bénéficiant de la connexion internet.</nowiki></tt> <tt><nowiki># L'astuce consiste a rediriger toutes les</nowiki></tt> <tt><nowiki># requêtes ayant un port de destination 80</nowiki></tt> <tt><nowiki># vers le port 3128 du proxy, ici c'est le</nowiki></tt> <tt><nowiki># firewall (qui est sur le firewall et qui</nowiki></tt> <tt><nowiki># a l'adresse IP 192.168.2.1 ).</nowiki></tt> <tt><nowiki># Une règle de NAT suffira largement pour faire ça.</nowiki></tt>

<tt>iptables -t nat -A PREROUTING -i eth1 -p tcp \</tt> <tt> --dport 80 -j DNAT --to-destination 192.168.2.1:3128</tt>

<tt><nowiki># Bon, c'est pas trop compliqué ! Maintenant</nowiki></tt> <tt><nowiki># on sait que l'on a un </nowiki>'''serveur web sur la DMZ'''</tt> <tt><nowiki># (la machine d'adresse IP 192.168.1.2) sur</nowiki></tt> <tt><nowiki># le port 80. On souhaite que toutes les requêtes</nowiki></tt> <tt><nowiki># provenant d'internet arrivant sur l'adresse IP</nowiki></tt> <tt><nowiki># publique du serveur ( ici 42.42.42.42 ) soit</nowiki></tt> <tt><nowiki># redirigées sur le serveur web de la DMZ.</nowiki></tt> <tt><nowiki># Rien de bien compliqué. Dans l'exemple,</nowiki></tt> <tt><nowiki># on peut retirer le :80 de la target</nowiki></tt> <tt><nowiki># --to-destination</nowiki></tt>

<tt>iptables -t nat -A PREROUTING -d 42.42.42.42 \</tt> <tt> -p tcp --dport 80 -j DNAT --to-destination 192.168.1.2:80</tt>

<tt><nowiki># C'est bien tout ça ! mais le problème c'est</nowiki></tt> <tt><nowiki># que les chaînes de la table FILTER sont toutes</nowiki></tt> <tt><nowiki># à DENY, donc tout ceci ne fait rien du tout.</nowiki></tt> <tt><nowiki># On va donc passer a la </nowiki>'''configuration du'''</tt> <tt><nowiki># </nowiki>'''firewall''' proprement dit.</tt>

<tt><nowiki># On va quand même </nowiki>'''accepter les connexions ssh'''</tt> <tt><nowiki># (port 22) provenant d'une machine (la votre en</nowiki></tt> <tt><nowiki># l'occurrence, on va dire 192.168.2.42) vers le</nowiki></tt> <tt><nowiki># firewall pour pouvoir modifier les règles</nowiki></tt> <tt><nowiki># facilement pour bien surveiller, on vas quand</nowiki></tt> <tt><nowiki># même loguer les connexions provenant de mon IP</nowiki></tt> <tt><nowiki># et à destination du ssh du firewall</nowiki></tt>

<tt>iptables -A INPUT -i eth1 -s 192.168.2.42 -m state \</tt> <tt> --state NEW,ESTABLISHED -p tcp --dport 22 -j LOG_ACCEPT</tt> <tt>iptables -A OUTPUT -o eth1 -d 192.168.2.42 -m state \</tt> <tt> --state ESTABLISHED -p tcp --sport 22 -j LOG_ACCEPT</tt>

<tt><nowiki># On veut que le </nowiki>'''LAN''' connecté à l'interface</tt> <tt><nowiki># eth1 ait un accès complet à </nowiki>'''internet'''.</tt> <tt><nowiki># La règle de NAT qui permettait d'avoir</nowiki></tt> <tt><nowiki># un </nowiki>'''proxy transparent''' sera automatiquement</tt> <tt><nowiki># appliqué. L'interface correspondant</nowiki></tt> <tt><nowiki># à la connexion internet est ici ppp0</nowiki></tt>

<tt>iptables -A FORWARD -i eth1 -o ppp0 -j ACCEPT</tt> <tt>iptables -A FORWARD -o eth1 -i ppp0 -j ACCEPT</tt>

<tt><nowiki># Maintenant on donne le droit au </nowiki>'''LAN''' de</tt> <tt><nowiki># </nowiki>'''consulter les pages web du serveur de la DMZ'''</tt>

<tt>iptables -A FORWARD -i eth1 -o eth0 -p tcp \</tt> <tt> --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT</tt> <tt>iptables -A FORWARD -i eth0 -o eth1 -p tcp \</tt> <tt> --sport 80 -m state --state ESTABLISHED -j ACCEPT</tt>

<tt><nowiki># Maintenant il n'y a plus qu'à dire au firewall</nowiki></tt> <tt><nowiki># d'autoriser à transmettre des paquets TCP à</nowiki></tt> <tt><nowiki># destination du port 80 provenant de l'adresse</nowiki></tt> <tt><nowiki># IP publique (i.e. d'</nowiki>'''internet''') '''vers le serveur'''</tt> <tt><nowiki># </nowiki>'''web de la DMZ''' que nous avons naté précédemment.</tt>

<tt>iptables -A FORWARD -i ppp0 -o eth0 -p tcp \</tt> <tt> --destination-port 80 -m state --state NEW,ESTABLISHED -j ACCEPT</tt> <tt>iptables -A FORWARD -o ppp0 -i eth0 -p tcp \</tt> <tt> --source-port 80 -m state --state ESTABLISHED -j ACCEPT</tt>

<tt><nowiki># Maintenant il ne reste plus grand chose à faire !</nowiki></tt>

<tt><nowiki># Il faut permettre à l'ensemble du LAN de dialoguer</nowiki></tt> <tt><nowiki># sur internet avec la même adresse IP sinon, bien</nowiki></tt> <tt><nowiki># évidemment ça ne marchera pas (à moins que vous</nowiki></tt> <tt><nowiki># ayez 30 adresses ip !).</nowiki></tt> <tt><nowiki># Une petite règle de NAT avec un -j MASQUERADE</nowiki></tt> <tt><nowiki># suffira (masquerade = dialoguer avec l'adresse</nowiki></tt> <tt><nowiki># IP publique sur firewall)</nowiki></tt>

<tt>iptables -t nat -A POSTROUTING \</tt> <tt> -s 192.168.2.0/24 -j MASQUERADE</tt>

<tt><nowiki># Il faut également que le serveur web de la DMZ</nowiki></tt> <tt><nowiki># soit masqueradé sinon, le serveur</nowiki></tt> <tt><nowiki># dialoguera sur internet avec son IP privée</nowiki></tt>

<tt>iptables -t nat -A POSTROUTING \</tt> <tt> -s 192.168.1.0/24 -j MASQUERADE</tt>

<tt><nowiki># Toutes les règles qui n'ont pas passé les</nowiki></tt> <tt><nowiki># règles du firewall seront refusées et loguées...</nowiki></tt> <tt><nowiki># facile :</nowiki></tt>

<tt>iptables -A FORWARD -j LOG_DROP</tt> <tt>iptables -A INPUT -j LOG_DROP</tt> <tt>iptables -A OUTPUT -j LOG_DROP</tt>

<tt><nowiki># Pour faire zoli</nowiki></tt> <tt>echo " [Termine]"</tt>

<tt><nowiki># c'est enfin fini</nowiki></tt>
|}

</center>

Et voilà ! le firewall de compèt' est prêt et fonctionnel.

Ceci était bien évidemment un exemple, vous pouvez dès à présent préparer votre propre firewall personnalisé ! Vous pouvez l'adapter à vos besoins, votre connexion vers internet (par ADSL par exemple), etc.

<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 Arnaud de Bermingham le 12/11/2001.</div>

= Copyright =
Copyright © 12/11/2001, Arnaud de Bermingham
{{CC-BY-NC-SA}}

=Autres ressources=
Le [http://lea-linux.org/trucs/index.php3?aff_item=272 partage de connexion] facile.

Tester votre firewall [http://grc.com/default.htm là].

Cliquez sur 'ShieldsUP!', puis sur l'un des boutons : 'Test My Shields !" et "Probe My Ports !". Ça vaut pas un bon <tt>nmap</tt> fait par un ami, mais ça permet de voir ou on en est.

LéaLinux:Accueil

2005-10-14T12:53:36Z

Pterjan : /* Utilisateurs */

__NOTOC__
= Bienvenue sur Léa =
{| width="100%"
| valign="top" |
== Léa passe au Wiki ==
Les contributeurs de Léa sont très nombreux, mais contribuer à Léa a toujours été problématique. L'histoire de Léa est longue et lourde. Je veux dire par là que pendant très longtemps les évolutions de Léa ont été suspendues aux bonnes volontés du tout petit groupe d'administrateurs.

Il fallait que ça change. Tout d'abord les administrateurs se trouvent crouler (pleurez avec nous) sous la charge de travail. Ensuite les contributeurs ont l'impression que nous n'apprécions pas leur travail puisque nous ne le mettons pas en ligne. Enfin, rien n'était ''user friendly''.

C'est pourquoi Léa a décidé de changer presque complètement : elle passe au Wiki. C'est à dire que tout le monde peut proposer des modifications pour toutes les pages. Seulement, pour que ces modifications restent un minimum vérifiées, à la différence d'un wiki classique, celui de Léa sera modéré a priori. C'est à dire que les modifications n'apparaîtront de suite, elles devront être validées par les modérateurs.

Pour éviter un minimum les robots et autres spammeurs en puissance, nous avons aussi décidé qu'il faudrait être enregistré pour pouvoir éditer une page. Ceci dit, la création d'un compte sera simple, et ne nécessitera pas notre approbation.

| valign="top" |
== Utilisateurs ==

Léa aura aussi besoin de 2 nouvelles catégories d'utilisateurs : les '''éditeurs''' et les '''modérateurs''', les premiers seront des utilisateurs pouvant voir et modifier l'intégralité du wiki de Léa et en modifier les pages (enfin pour les modifications, certaines parties du site resteront en accès administrateur uniquement). Les seconds auront les mêmes droits, plus celui de valider les modifications d'une page pour affichage sur la partie publique du site.

Les adhérents de l'association Léa pourront demander un droit d'accès éditeurs. Les modérateurs seront recrutés parmi l'ensemble des utilisateurs habituels de Léa par les administrateurs du site.

Il est prévu d'unifier les identifications au forum et mediawiki par l'intermédiaire d'un ''plugin'' d'authentification à mediawiki. Pour l'instant ce ''plugin'' est à l'étude.

|-
| valign="top" |

== Choix du Wiki ==

Nous avons choisi comme wiki pour Léa : [http://mediawiki.org mediawiki], il est bien maintenu et dispose d'une grande base d'utilisateurs. Comme mediawiki ne permet pas la modération à priori des articles nous avons donc du développer une interface de modération ainsi qu'un cache statique (ie: une page du wiki ne générera en général qu'un seul appel à PHP, elle sera ensuite sauvée sous son nom dans l'arborescence de Léa évitant à la demande suivante un appel à php, et donc limitera la charge du serveur). De plus nous avons installé TurckMMCache sur le serveur de Léa puisque mediawiki sait le gérer.

PS: Il semblerait que TurckMMCache occasionne des plantages d'apache. Nous ne savons donc pas encore s'il va rester en place.

| valign="top" |

== Transition ==
Il a fallu transformer la plupart des pages de Léa au format Wiki, cette transformation n'a pas été faite à la main ! Nous ne sommes pas des bêtes de somme ! Le revers de la médaille c'est que certaines pages ont été mal converties. Nous allons donc faire appel à vous et au fait que Léa est maintenant un wiki pour régler ce problème. Pas la peine de nous consulter : '''éditez vous même !''' Vous verrez c'est facile.

'''P.S. :''' normalement, toutes les anciennes pages de Léa restent accessibles, soit qu'elles aient été traduites en wiki, soit que les répertoires en question restent inchangés. Si une page a disparu : [[LéaLinux:BugReport|faites un rapport de bug]]
|}

Ceci dit, il y a aussi des bugs ! Vous serez gentils de bien vouloir les signaler sur cette page : [[LéaLinux:BugReport]].

<newbox>Un premier travail collectif</newbox>
Comme premier travail collectif, nous vous demandons de concevoir le contenu de la page d'accueil. Pour cela nous n'allons pas travailler sur cette page ci, mais sur la page : [[LéaLinux:Accueil]]

<newbox>Les nouvelles du libres (en direct des flux RSS)</newbox>
{| width="100%" border="0"
| width="50%" valign="top" |<rss>http://www.agendadulibre.org/rss.php?region=all|short|max=5</rss>
| width="50%" valign="top" |<rss>http://linuxfr.org/backend/news/rss20.rss|short|max=5</rss>
|}

<newbox>Les pages d'introduction à Linux</newbox>
{| width="100%" border="0"
! width="50%" valign="top" align="left" | Les pages suivantes constituent le point d'entrée obligatoire à Léa.
! width="50%" valign="top" align="left" | Les pages suivantes sont des fiches spéciales débutant
|-
| valign="top" | <DPL>category=Introduction à Linux</DPL>
| valign="top" |<DPL>category=Fiches pratiques</DPL>
|}

{{DP}}

LéaLinux:Accueil

2005-10-14T12:41:29Z

Pterjan : /* Utilisateurs */

__NOTOC__
= Bienvenue sur Léa =
{| width="100%"
| valign="top" |
== Léa passe au Wiki ==
Les contributeurs de Léa sont très nombreux, mais contribuer à Léa a toujours été problématique. L'histoire de Léa est longue et lourde. Je veux dire par là que pendant très longtemps les évolutions de Léa ont été suspendues aux bonnes volontés du tout petit groupe d'administrateurs.

Il fallait que ça change. Tout d'abord les administrateurs se trouvent crouler (pleurez avec nous) sous la charge de travail. Ensuite les contributeurs ont l'impression que nous n'apprécions pas leur travail puisque nous ne le mettons pas en ligne. Enfin, rien n'était ''user friendly''.

C'est pourquoi Léa a décidé de changer presque complètement : elle passe au Wiki. C'est à dire que tout le monde peut proposer des modifications pour toutes les pages. Seulement, pour que ces modifications restent un minimum vérifiées, à la différence d'un wiki classique, celui de Léa sera modéré a priori. C'est à dire que les modifications n'apparaîtront de suite, elles devront être validées par les modérateurs.

Pour éviter un minimum les robots et autres spammeurs en puissance, nous avons aussi décidé qu'il faudrait être enregistré pour pouvoir éditer une page. Ceci dit, la création d'un compte sera simple, et ne nécessitera pas notre approbation.

| valign="top" |
== Utilisateurs ==

Léa aura aussi besoin de 2 nouvelles catégories d'utilisateurs : les '''éditeurs''' et les '''modérateurs''', les premiers seront des utilisateurs pouvant voir et modifier l'intégralité du wiki de Léa et en modifier les pages (enfin pour les modifications, certaines parties du site resteront en accès administrateur uniquement). Les seconds auront les mêmes droits, plus celui de valider les modifications d'une page pour affichage sur la partie publique du site.

Les adhérents de l'association Léa pourront demander un droit d'accès éditeurs. Les modérateurs seront recrutés parmi l'ensemble des utilisateurs habituels de Léa par les administrateurs du site.

Il est prévu d'unifier les identifications à phorum et mediawiki par l'intermédiaire d'un ''plugin'' d'authentification à mediawiki. Pour l'instant ce ''plugin'' est à l'étude.

|-
| valign="top" |

== Choix du Wiki ==

Nous avons choisi comme wiki pour Léa : [http://mediawiki.org mediawiki], il est bien maintenu et dispose d'une grande base d'utilisateurs. Comme mediawiki ne permet pas la modération à priori des articles nous avons donc du développer une interface de modération ainsi qu'un cache statique (ie: une page du wiki ne générera en général qu'un seul appel à PHP, elle sera ensuite sauvée sous son nom dans l'arborescence de Léa évitant à la demande suivante un appel à php, et donc limitera la charge du serveur). De plus nous avons installé TurckMMCache sur le serveur de Léa puisque mediawiki sait le gérer.

PS: Il semblerait que TurckMMCache occasionne des plantages d'apache. Nous ne savons donc pas encore s'il va rester en place.

| valign="top" |

== Transition ==
Il a fallu transformer la plupart des pages de Léa au format Wiki, cette transformation n'a pas été faite à la main ! Nous ne sommes pas des bêtes de somme ! Le revers de la médaille c'est que certaines pages ont été mal converties. Nous allons donc faire appel à vous et au fait que Léa est maintenant un wiki pour régler ce problème. Pas la peine de nous consulter : '''éditez vous même !''' Vous verrez c'est facile.

'''P.S. :''' normalement, toutes les anciennes pages de Léa restent accessibles, soit qu'elles aient été traduites en wiki, soit que les répertoires en question restent inchangés. Si une page a disparu : [[LéaLinux:BugReport|faites un rapport de bug]]
|}

Ceci dit, il y a aussi des bugs ! Vous serez gentils de bien vouloir les signaler sur cette page : [[LéaLinux:BugReport]].

<newbox>Un premier travail collectif</newbox>
Comme premier travail collectif, nous vous demandons de concevoir le contenu de la page d'accueil. Pour cela nous n'allons pas travailler sur cette page ci, mais sur la page : [[LéaLinux:Accueil]]

<newbox>Les nouvelles du libres (en direct des flux RSS)</newbox>
{| width="100%" border="0"
| width="50%" valign="top" |<rss>http://www.agendadulibre.org/rss.php?region=all|short|max=5</rss>
| width="50%" valign="top" |<rss>http://linuxfr.org/backend/news/rss20.rss|short|max=5</rss>
|}

<newbox>Les pages d'introduction à Linux</newbox>
{| width="100%" border="0"
! width="50%" valign="top" align="left" | Les pages suivantes constituent le point d'entrée obligatoire à Léa.
! width="50%" valign="top" align="left" | Les pages suivantes sont des fiches spéciales débutant
|-
| valign="top" | <DPL>category=Introduction à Linux</DPL>
| valign="top" |<DPL>category=Fiches pratiques</DPL>
|}

{{DP}}