Retrouvez cet article dans : Linux Magazine 82

Dans un précédent numéro du magazine (80), un système GNU/Linux complet fonctionnant entièrement en mémoire a été construit. Cet article lui fait suite en détaillant l’installation d’applicatifs sur cette base.

1 Mon troisième RIM-Linux

1.1 Un peu de cosmétique : bootsplash

achez ces logs que je ne saurais voir ! Bootsplash est un patch cosmétique qui permet d’avoir un beau boot graphique avec une barre de progression. Bootsplash, c’est un patch, mais aussi des utilitaires que nous allons compiler, Bootsplash permet d’avoir des animations illustrant les différentes phases de boot, mais nous n’irons pas jusque-là, nous nous contenterons d’une barre de progression et de messages textes. Il nous faudra ajouter la bibliothèque libfreetype nécessaire à fbtruetype, l’utilitaire qui nous permet d’afficher ces messages. Pour pouvoir utiliser Bootsplash, il faut démarrer en mode framebuffer (paramètre vga=xxx; voyez la documentation du noyau pour les valeurs de paramètres à passer). Avec Bootsplash, on peut gérer le fait de booter en différentes résolutions. Dans notre cas nous nous limiterons au mode 800x600 16 bits qui présente l’avantage d’exister sur 99,9% des combinaisons ordinateurs+écran. Ce mode s’active avec l’option vga=788 que nous avons déjà placé dans notre isolinux.cfg. Bootsplash peut se placer dans deux modes différents : le mode silent où l’on masque la console en affichant une belle image et le mode verbose, où l’on affiche la console. Le mode de départ est déterminé par le paramètre splash=silent (ou verbose) dans les paramètres du noyau. Au cours de l’exécution des scripts de démarrage, on pourra passer de l’un à l’autre facilement via et On utilise en général deux images, l’une pour le mode silent et une autre qui sert de fond d’écran pour le mode verbose. Tout cela est défini dans un fichier de configuration. Nous allons avoir besoin d’un thème. Sur le site allemand de Bootsplash [1], on trouvera les derniers patches, utilitaires et de nombreux thèmes. La documentation de Bootsplash n’est pas très fournie mais en examinant des exemples, on arrive à s’en sortir assez facilement. Le thème que nous allons utiliser (dans (chemin)/bootsplash/rimlinux) est composé simplement d’une belle photo JPEG et d’un fichier de configuration, on utilise la même image pour le mode silent et pour le mode verbose. Copions donc le contenu de notre thème dans notre rootbase : Afin que le kernel puisse afficher très tôt l’image silent, c’est-à-dire avant ses initialisations, l’utilitaire splash permet d’ajouter une ou plusieurs images à un initrd. Pour un initramfs, on procèdera de la façon suivante : Cela va créer un fichier bootsplash que le kernel saura traiter. Comme l’utilitaire splash prend comme argument le fichier de configuration contenant le chemin absolu vers l’image utilisée, le plus simple est de créer un lien symbolique sur votre système (on suppose que le répertoire /etc/bootsplash existe) : De cette façon, l’instruction complète que nous ajouterons à notre script de création de l’iso sera : On pourra utiliser le script fourni make_new_iso_bootsplash.sh . Mais un écran fixe pendant la séquence de boot, ce n’est pas terrible parce qu’on ne sait pas ce que fait le système, d’où la barre de progression. L’affichage de la barre de progression se fait de la façon suivante : où x représente un entier compris entre 0 et 65534, c’est aussi simple que ça. On peut aussi afficher un texte avec une taille et une couleur donnée avec fbtruetype. En utilisant tous ces outils, on obtient les scripts fournis rcS-iso3 et setHardware-iso3.pl que l’on va recopier dans notre rootbase : Nous modifierons également le fichier isolinux.config afin d’ajouter splash=silent dans les paramètres du noyau. On aura alors une belle séquence de boot graphique comme en figure 1. Au passage, l’arbre est un magnifique olivier centenaire poussant sous le soleil du Portugal chez ma belle-sœur... :-)

Fig. 1 : Séquence de boot avec Bootsplash

1.2 Un script de configuration de plus : configHardware.pl

A la suite du script setHardware.pl qui détecte le matériel, nous allons lancer dans le rcS un autre script qui va effectuer quelques configurations :

• Montage par subfs des CD-ROM/DVD et floppys
• Montage en lecture seule des partitions locales si l’utilisateur en fait la demande.
• Configuration d’interface réseau par DHCP si l’utilisateur en fait la demande.
• Effacement des modules si l’utilisateur en fait la demande.
• Montage automatique des CD et floppys

On examine le contenu de /proc/sys/dev/cdrom/info et on en ressort la liste des CD-ROM. On crée les points de montage et on monte par subfs :

Pour les floppys, on fait à peu près le même travail, mais on en obtient la liste en examinant /dev/fdx :

• Montage automatique des partitions locales

Si l’utilisateur passe localmount=yes, on monte les partitions locales en lecture seule, libre ensuite à l’utilisateur de les remonter en lecture/écriture. On cherche les partitions dans /proc/partitions, on élimine les périphériques loop (c’est pour plus tard...), on crée les points de montage et on monte :

A noter que l’utilisateur peut lancer localmount.pl a posteriori pour monter les partitions.

• Configuration réseau

Si l’utilisateur passe ethx=dhcp sur la ligne de commande du kernel, on tente de configurer cette interface par DHCP avec le client DHCP udhcpc :

Je n’ai pas fait d’interface de configuration réseau. Il faudra donc le faire à la main mais ce n’est pas très compliqué. Par exemple, on veut configurer eth0 avec l’adresse 192.168.0.145, masque 255.255.255.0, la passerelle par défaut est 192.168.0.253 et le DNS est 192.168.0.252 :

• Effacement des modules

Si l’utilisateur passe keepmods=no, on efface le répertoire des modules du noyau, cela permet de gagner de la place dans les environnements à faible mémoire. Par contre, tout ce qui est hotplug et qui n’a pas encore été détecté ne fonctionnera pas.

• En résumé

En résumé, on va copier les scripts fournis localmount.pl et configHardware.pl :

1.3 Montage de partages NFS

Afin de pouvoir monter des partages NFS, il faut lancer le programme portmap que nous allons copier depuis notre distribution (il sera lancé par rcS) :

On pourra ensuite monter les partages NFS. Pour monter par exemple machine1:/partage, on va créer un point de montage, par exemple /localmounts/nfs/machine1/partage et exécuter :

1.4 Montage de partages Windows avec samba

Pour les partages samba [2], nous allons avoir besoin de smbmount. Le problème est qu’en général, smbmount est lié à beaucoup trop de bibliothèques pour être copié tel quel dans notre RIM-Linux. Par exemple, sur ma SuSE 9.3, un ldd sur smbmount donne :

On voit que samba a été compilé avec un support LDAP, un support kerberos. C’est vraiment trop pour nous qui souhaitons faire des montages simples de partages Windows... Eh oui, on est bon pour recompiler !

Un ldd sur le smbmount nouvellement compilé donne quelque chose qui est beaucoup mieux, puisque nous n’aurons pas à rajouter de bibliothèques. Si on veut monter //machine1/partage avec comme login alfred et comme mot de passe alfred25, on créera d’abord un point de montage, par exemple /localmounts/smb/machine1/partage et on exécutera :

1.5 Un serveur XXX

1.5.1 Xserver : Buildit

Lorsque Keith Packard était encore dans le groupe XFree86, il avait développé Kdrive une version de X compacte, peu consommatrice en mémoire et ne nécessitant aucun fichier de configuration ni polices annexes pour démarrer. Compiler Kdrive était un peu pénible. Il fallait télécharger les sources de XFree86, modifier quelques fichiers de configuration après quelques heures laborieuses de recherche de documentation. Lors du changement de licence de XFree86, Keith Packard est parti en emmenant Kdrive dans son sac et c’est devenu le projet Xserver de freedesktop.org [3]. Xserver a été grandement amélioré par rapport au Kdrive de XFree86-4.2 que j’avais utilisé dans Womp. Il gère plus d’extensions, les polices TrueType avec l’extension Render, la transparence avec l’extension Composite, etc. Une grande amélioration est qu’il utilise les gnu autotools. Plus besoin de xmkmf et compagnie. Il n’y a pas de package téléchargeable, il faut utiliser le CVS. On trouve sur le site un script permettant d’automatiser la construction du serveur (http://www.freedesktop.org/wiki/XserverBuildScript). Je fournis néanmoins un tarball du CVS au 17 octobre 2005. On pourra l’utiliser ou préférer la version CVS. On trouvera dans ce tarball le script original XserverBuildScript et deux scripts séparant les deux fonctions du premier, à savoir obtenir les sources d’une part (Getsources) et les compiler (Buildit) d’autre part. Le script Buildit (de même que l’original XserverBuildScript) utilise sudo qui vous permet de compiler en tant qu’utilisateur normal. Si vous ne voulez pas utiliser sudo, éditez le fichier Buildit, supprimez tous les sudo et compilez en root. A noter un petit problème dans les noms de packages, résolu par la création de liens symboliques dans Buildit. L’installation se fera dans le répertoire /opt/fdo :

La compilation est relativement longue... Go take a coffee. Une fois terminée, nous avons dans /opt/fdo/bin plusieurs serveurs. Nous allons utiliser uniquement le driver Xvesa qui fonctionnera avec le plus de matériels différents. Il possède une option -shadow qui accélère son fonctionnement et le rend utilisable même à de très hautes résolutions (je m’en suis servi en 1400x1050 avec confort). Nous allons donc recopier le serveur et les bibliothèques créés dans notre rootbase. Nous copions également la bibliothèque libz de notre distribution nécessaire au serveur X et créons un lien de /usr/X11R6/lib/X11 vers /usr/lib/X11, le serveur cherchant ses polices dans /usr/lib/X11/fonts. Les informations de locale seront prises par contre dans l’installation locale de Xorg. Certains fichiers étant manquants dans l’installation que nous venons de faire.

On pourra aussi copier xcompmgr (composite manager) pour jouer avec. On copiera aussi une petite sélection de polices, bien que sous certaines conditions, du moins en local, le serveur puisse fonctionner sans. Il est nécessaire d’en avoir quelques-unes en mode terminal.

Au final, nous avons maintenant une installation de X qui prend... 3,1 Mo !

1.5.2 Xserver : Use it

Nous allons décrire sommairement le fonctionnement de ce serveur X. Au préalable, en lançant le serveur avec l’option -listmodes, nous allons obtenir la liste des modes VESA disponibles. Notez que les modes affichés ne présupposent rien sur l’écran. Ce n’est pas parce que la carte sait faire du 1280x1024x16 que l’écran saura le faire. Voici un type de sortie obtenu :

Attention ! Les modes affichés dépendent de la carte vidéo. Ce n’est pas parce que dans cet exemple 0x0117 représente le mode 1024x768 16 bits qu’il en sera de même avec une autre carte, il est nécessaire d’effectuer cette opération de listage des modes. Ensuite on lance le serveur en lui spécifiant le mode à utiliser :

Si on a sur le réseau une machine acceptant les connexions Xdmcp(1), on peut d’ores et déjà se servir de notre RIM-Linux tel quel en tant que Terminal X en tapant :

(1) Il faut qu’un gestionnaire de connexion fonctionne, par exemple xdm,kdm ou gdm. Dans les distributions modernes, l’écoute des connexions distantes est souvent désactivé par défaut, l’activer est plus ou moins facile suivant la distribution. Pour kdm, le fichier kdmrc doit contenir Enable=true dans le groupe [Xdmcp].

On obtiendra alors l’écran de connexion de la machine en question. Les autres arguments qui vont nous intéresser sont -ac qui équivaut à effectuer un xhost + préalable, -shadow qui accélère le fonctionnement du serveur X, et -mouse qui permet de spécifier le périphérique de la souris avec en option, le nombre de boutons, la molette étant prise en compte en spécifiant 5 boutons :

1.6 Gestionnaire de fenêtre : Boîte noire

Pour une utilisation en local et non en terminal X, il va nous falloir un gestionnaire de fenêtres. Il existe des gestionnaires de fenêtre très compacts et néanmoins fonctionnels. Parmi eux citons : swm [4], windowlab [5] et blackbox [6]. Les deux premiers sont très petits, moins de 100 ko ! On les utilisera pour des applications très contraintes en taille mémoire. Pour cet exemple, j’ai préféré utiliser blackbox qui allie une taille raisonnable et des fonctionnalités confortables. Nous utilisons dans la suite une méthode très simple permettant de faire des pseudo-packages, consistant à installer dans un répertoire /usr/local vide. Ce n’est pas forcément très élégant mais c’est pratique. On aurait pu aussi préférer utiliser la forme make DESTDIR=/some/where install lors de l’installation, mais il faut packager de toute façon après. Un ldd sur notre blackbox nous indique les bibliothèques que nous allons devoir ajouter. Il nous manque : Nous voyons que blackbox utilise le package fontconfig, un package dont le but est de centraliser la configuration des polices (et entre autres les polices TrueType) et dont l’auteur n’est autre que... Keith Packard. Nous allons utiliser l’installation locale de fontconfig et ajouter un répertoire de polices TrueType au même endroit que sur la distribution locale. On peut y mettre les polices qu’on veut mais attention à ne pas abuser, car cela prend de la place. Pour ma part, j’y mets les polices luxi* fournies avec Xorg. Cela prend moins d’un Mo. Copions maintenant les autres bibliothèques et blackbox lui-même. On pourra personnifier le menu de blackbox dans rootbase/usr/local/share/blackbox/menu. Copiez le fichier fourni menu.blackbox.

1.7 Emulateur de terminal : rxvt-unicode

Toujours pour travailler en local, il nous faut un émulateur de terminal. On peut en recopier un depuis sa distribution ou en recompiler un, ce que je propose ici avec rxvt-unicode [7], mon préféré :

1.8 Midnight Commander : un gestionnaire de fichiers en mode texte

Gnu Midnight Commander [9] est un gestionnaire de fichier en mode texte très performant, qui sera très utile pour effectuer des copies/transferts de fichiers sur les partitions locales, CD et montages réseau. Il comporte entre autres fonctionnalités un pager (mcview) et un éditeur de texte (mcedit)(2). (2) Petite remarque concernant la distribution Suse : quand on fait un su, /opt/gnome/bin et /opt/kde3/bin ne sont pas dans le PATH, or configure a besoin par exemple pour gtk d’accéder à gtk-config. Si on veut faire le configure en root, il faut au préalable faire "export PATH=/opt/gnome/bin:/opt/kde3/bin:$PATH ou bien alors travailler carrément connecté en root. Intégrons mc dans notre rootbase en épurant un peu, notamment les fichiers de locale : Nous avons également besoin de la Glib 1.2 (libglib,libgmodule,libgthread) que nous prenons dans la distribution locale.

1.9 Serveurs de son

Pour utiliser notre RIM-Linux en tant que terminal X avec le maximum de confort, il est intéressant de pouvoir rediriger le son vers notre terminal, de la même façon que l’on redirige l’affichage. Il n’y a malheureusement pas de méthode aussi standard que X pour effectuer cela. Il existe principalement 3 serveurs de son permettant cela :

• artsd le serveur de son de KDE [10].
• esd le serveur de son de Enlightement et Gnome [11].
• nasd un serveur de son à vocation générale [12].

Nous allons installer ces trois serveurs dans notre RIM-Linux afin de laisser le choix.

1.9.1 artsd

artsd est maintenant complètement intégré à KDE, mais il existe une version stand-alone que nous allons utiliser. Pour pouvoir compiler (du moins avec l’emplacement des headers de la glib sur ma distribution), il faut modifier le fichier arts/gmcop/giomanager.h en remplaçant la ligne : par La compilation se fait ensuite classiquement : Il ne reste plus qu’à l’intégrer dans notre rootbase : Il nous faut aussi copier libaudiofile de notre distribution : Sur le terminal X (c’est-à-dire le RIM-Linux), on va lancer artsd de la façon suivante : Sur la machine distante, on va définir la variable d’environnement ARTS_SERVER sur <IP du terminal>:16000, par exemple si l’IP de notre RIM-Linux est 192.168.0.192 : Les applications utilisant arts (Xmms ou Mplayer par exemple) comme sortie se connecteront au serveur artsd sur le RIM-Linux.

1.9.2 esd

La compilation se fait classiquement. On copie dans notre rootbase : Sur le terminal X (c’est-à-dire le RIM-Linux), on va lancer esd de la façon suivante (notre esd ne fonctionne qu’avec alsa, bien qu’il soit censé fonctionner également avec OSS). Sur la machine distante, on va définir la variable d’environnement ESPEAKER sur <IP du terminal>:16001, par exemple si l’IP de notre RIM-Linux est 192.168.0.192 : Les applications utilisant esd (Xmms ou Mplayer par exemple) comme sortie se connecteront au serveur esd sur le RIM-Linux.

1.9.3 nasd

nas se compile un peu différemment. Il n’utilise pas les autotools, mais le système d’auto-configuration de X11 bien que n’utilisant absolument pas X. Si vous souhaitez compiler des applications avec le support natif nas, il faudra installer nas sur votre système en tapant make install. Personnellement, je me suis fait un RPM pour nas (à ce propos, il existe un utilitaire qui s’appelle checkinstall [8] qui vous crée un RPM en interceptant les appels d’un make install). Copions donc nasd dans notre rootbase : Sur le terminal X (c’est-à-dire le RIM-Linux), on va lancer nasd de la façon suivante : Le port utilisé est spécifié avec un offset de 8000, :0 correspond à 8000, :1 à 8001 etc. Sur la machine distante, on va définir la variable d’environnement AUDIOSERVER sur <IP du terminal>:0, par exemple si l’IP de notre RIM-Linux est 192.168.0.192 : Si l’application a le support natif nas (mais il y en a assez peu), ce sera la même chose que précédemment. Par contre, pour les autres applications, il faudra utiliser une bibliothèque supplémentaire qui redirige le son oss sur nas (pour arts et esd, ce sont des programmes séparés artsdsp et esddsp qui effectuent cette opération). Du côté de la machine distante, il nous faudra compiler et installer audiooss : Avant de lancer une application son, il faudra positionner la variable d’environnement LD_PRELOAD sur la bibliothèque installée : Ca ne fonctionne pas avec toutes les applications son, mais ça fonctionne entre autres avec Xmms utilisant oss comme pilote de sortie.

1.10 Navigateur grand luxe : Firefox

Pour l’installation de Firefox [13], nous allons utiliser simplement l’installateur de Firefox et l’installer directement dans notre rootbase/usr/local, comme l’installation ne hardcode pas dans les fichiers l’emplacement de l’installation, cela ne pose pas de problèmes. On pourra aussi simplement recopier une installation locale faite à partir du tarball. Suivre les instructions habituelles en choisissant rootbase/usr/local/firefox comme répertoire d’installation. Choisissez l’installation personnalisée et désélectionnez Agent de rapport de qualité. Comme nous l’apprend un ldd sur firefox-bin (les bibliothèques marquées not found sont les bibliothèques incluses dans l’installation de Firefox, le script de démarrage repositionnant LD_LIBRARY_PATH). Il va nous falloir ajouter pas mal de choses pour que Firefox puisse fonctionner, dont les bibliothèques Gtk2, Atk, Pango et Glib2. Ces bibliothèques désignées par ldd et fichiers de configurations associés vont être pris dans notre distribution. On créera également un lien symbolique dans rootbase/usr/local/bin : On pourra aussi ajouter par exemple le plugin Flash composé des fichiers flashplayer.xpt et libflashplayer.so dans le répertoire plugin de Firefox. Attention toutefois ! Il y a un bug soit dans Flash soit dans le serveur X. Flash fait planter Firefox dans les modes 16 bits du serveur X. Pour utiliser Flash, il faut être en 24 bits.

1.11 Multimédia : MPlayer

Mplayer [14] est un des meilleurs lecteurs multimédias sous Linux. Il est capable de lire à peu près tous les fichiers multimédias existants, dont une grande part sans l’ajout de fichiers de codecs supplémentaires. Codecs supplémentaires éventuels qu’il suffit de placer dans /usr/lib/codecs. Un ldd sur Mplayer va nous permettre d’identifier les bibliothèques qui nous manquent. Copions donc celles-ci : Puis l’installation de Mplayer : Nous aurons également besoin d’un revêtement. Nous utiliserons Blue-1.4.tar.bz2 qui est le revêtement par défaut de MPlayer.

1.12 Bonus : mplayerplug-in

Mplayerplug-in [15] est un excellent plugin pour mozilla/netscape/firefox, qui intègre Mplayer dans le navigateur pour visualiser tous les fichiers que sait lire Mplayer. Mplayerplug-in est de plus assez intelligent dans la gestion du son, puisqu’il teste la présence de différents serveurs de son, dans l’ordre : artsd, esd puis se rabat sur OSS.

1.13 Touche finale

Le script fourni, startx.pl, permet de simplifier le lancement de X. Il commence par proposer une liste de modes ordonnés par profondeur et par taille, puis demande si on veut travailler en terminal X ou en local. Si on travaille en terminal X, il propose de lancer un serveur de son puis demande le nom ou l’IP de la machine distante. Si on travaille en local, il lance le serveur X puis le gestionnaire de fenêtres. mixer.pl est un script tout simple qui lance alsamixer si le son est configuré avec alsa et lance rexima sinon. J’ai ajouté également Vncviewer, dont je me sers assez souvent, directement de ma distribution ainsi que les bibliothèques supplémentaires nécessaires.

1.14 Création de l’iso

Encore un peu de cosmétique avec Isolinux. Lorsque l’on boote, on a un écran noir avec un prompt boot: ce qui n’est pas très plaisant quand on s’est embêté à configurer un beau Bootsplash pour la suite. Nous allons donc voir comment ajouter une image dès l’amorçage d’Isolinux. Avec The Gimp, nous allons éditer une image que l’on souhaite faire apparaître au démarrage. Pour notre exemple, il s’agit encore de la photo de l’olivier avec un texte ajouté : F1 : Help. Tout d’abord, nous allons la redimensionner en 640x480 ou plutôt à peine plus petit pour laisser la place pour le prompt d’Isolinux, soit en 640x450. Puis nous allons changer le mode de l’image et l’amener en mode indexé : Menu Image -> Mode -> Indexe en choisissant une palette optimale 16 couleurs (eh oui je sais, ce n’est pas beaucoup). A la suite de quoi nous allons enregistrer cette image sous le format ppm avec formatage des données brut. Nous avons maintenant un fichier isolinux.ppm qu’il va falloir convertir en un format spécifique à Isolinux. Pour ce faire, nous utiliserons le script perl ppmtolls16 inclus dans le package syslinux : Il faut ensuite que nous fabriquions un fichier isolinux.msg contenant : où <CAN> représente le caractère ASCII 24 ou encore le caractère de contrôle <Ctrl-X>. Cela peut se faire facilement avec la ligne de commande suivante : Pour finir, il va nous falloir modifier notre isolinux.cfg de façon à ce qu’il pointe sur ce fichier .msg en y ajoutant la ligne display isolinux.msg. En ce qui concerne le texte F1 : Help ajouté à l’image, il semble nous souffler l’idée que si on appuie sur [F1] on aura de l’aide... Cela se fait très simplement en ajoutant la ligne F1 help.txt à notre fichier isolinux.cfg et en ajoutant bien sur un fichier help.txt qui va décrire les différentes options du boot. On trouvera fourni les fichiers isolinux.lss, isolinux.msg, help.txt et isolinux.cfg pour cette troisième iso dans un répertoire isolinux-iso3 : La création de l’iso se fait comme d’habitude. On utilisera le script make_new_iso_bootsplash.sh. La taille de l’image est de 33 Mo et la taille du rootbase décompressé en mémoire est de 68 Mo.

2 C’est beau mais c’est trop gros ! Let’s shrink !

Si on examine la taille de notre rootbase en tapant du -sh rootbase, on voit que la taille de celui-ci est de 68 Mo. Pas question de pouvoir charger cette iso sur une machine ne faisant que 64 Mo donc et même difficilement avec 128 Mo. Il faut dire qu’on a particulièrement chargé la mule, en ajoutant de grosses applications : Firefox, Mplayer. Ceci dit, on se dit d’abord que si on ne sert pas des deux en même temps, ce serait pas mal d’avoir l’autre sous forme compressée... Et puis tant qu’à faire, en entrant dans le détail, ce serait même pas mal si tous les fichiers du système qui ne servent pas à un instant donné soit conservé sous forme compressée ! C’est ce que réalise l’excellent module squashfs que nous avons intégré à notre noyau. Il s’agit d’un système de fichier compressé en lecture seule qui décompresse les fichiers à la demande. Bon ! Ca c’est un outil qui est déjà pas mal, le seul problème c’est qu’étant en lecture seule, on ne peut quand même pas faire ce qu’on veut. D’où l’utilisation conjointe du non moins excellent module unionfs que nous avons également intégré à notre noyau. Unionfs (qui est utilisé maintenant par plusieurs distributions live dont Knoppix) est un système de fichiers permettant d’avoir réuni en une seule arborescence plusieurs branches de systèmes de fichiers, dont certaines en lecture seule, d’autres en lecture-écriture. Ainsi, on peut éditer et modifier des fichiers qui sont en lecture seule dans leur branche, la version modifiée se trouvant dans une branche en lecture-écriture, et tout cela de manière complètement transparente ! Nous allons donc couper en deux notre rootbase. Dans l’une des deux parties, nous allons mettre le strict nécessaire pour amorcer le système. Dans l’autre, nous " squashfs-iserons "... tout le reste !

2.1 Compilation et utilisation des utilitaires squashfs

Nous n’avons pas encore compilé les utilitaires squashfs : Copiez le programme mksquashfs quelque part dans le chemin de recherche des exécutables (/usr/bin par exemple). mksquashfs possède de nombreuses options, mais son utilisation la plus simple se résume à celle-ci : où destination représente soit un périphérique réel, soit un fichier que l’on montera ensuite en tant que loop. A noter une différence de comportement sensible suivant que l’on ait un unique répertoire source ou plusieurs. Dans le cas d’un unique répertoire source, le squashfs résultant contiendra le contenu du répertoire en éliminant le nom de celui-ci, une sorte de chroot quoi. Dans le cas de plusieurs répertoires sources, le squashfs résultant contiendra à sa racine les répertoires source.

2.2 Séparation du rootbase en deux parties

Nous allons donc couper en deux notre rootbase. Nous allons avoir deux répertoires : rootbase et rootbase-squash. A l’aide de mksquashfs, nous créerons un fichier squash à partir de rootbase-squash qui sera notre fichier squash principal. Par la suite, nous introduirons les rim-modules qui seront simplement des fichiers squash supplémentaires que nous intègrerons à notre RIM-Linux au moment de la création de l’iso, ce qui nous fera un système modulaire (on pourrait par exemple enlever Firefox et Mplayer du squash principal et faire deux fichiers rim-modules séparés, l’un pour Firefox, l’autre pour Mplayer. Au moment de la création de l’iso, on choisit suivant l’application les modules qu’on ajoute, etc.). Le mécanisme du boot sera celui décrit en figure 2.

Fig. 2 : Mécanisme de boot avec le squash Dans un premier temps, renommons rootbase en rootbase-squash et créons un nouveau répertoire rootbase. De quoi avons-nous besoin strictement pour booter ? Eh bien tout simplement à quelque chose près ce que nous avions dans notre ridiculissime première iso plus quelques fichiers de configuration : Busybox, ses liens symboliques, le fichier inittab, les premiers fichiers du /dev, le fichier de démarrage /etc/init.d/rcS, les modules (qui sont compressés ça tombe bien), les utilitaires de modules, les bibliothèques utilisées par ces programmes, unionctl pour la gestion de l’union, quelques répertoires vides pour la structure et... ça devrait suffire. Le script suivant devrait faire le travail (do_split_rootbase.sh) :

On a déplacé le répertoire bootsplash car on a un lien symbolique qui pointe dessus dans notre système. Il va de plus falloir créer les devices loopback dans notre /dev, car on va les utiliser en tout début de boot, avant même que udev soit démarré :

Enfin, le début de notre script rcS va devoir être modifié pour effectuer le travail supplémentaire (script fourni rcS-iso4) :

Le reste du script est identique à celui de l’iso 3. On commence par charger les modules squashfs et unionfs, on monte proc temporairement, on crée l’union dans le répertoire .union avec comme branche unique /. On regarde ensuite dans le répertoire .rimmodules et pour chaque fichier qu’on y trouve (s’il s’y trouve, il est censé être un fichier squash), on le monte en loopback et on l’ajoute à l’union. Enfin, on démonte notre proc temporaire et on effectue un pivot_root dans l’union. On notera que tel que c’est fait, on peut avoir plusieurs fichiers et donc une certaine modularité. On pourra avoir par exemple un fichier principal, un fichier pour Firefox, etc.

2.3 Création de l’iso

Pour la création de l’iso, nous utiliserons le script make_new_iso-sq.sh qui effectue en plus l’opération de fabrication du fichier squash :

On notera qu’avant de créer le fichier squash, on prend soin d’effacer le précédent, en effet mksquashfs n’écrase pas la destination si elle existe mais ajoute au bout.

2.4 Tests de l’iso

Les fonctionnalités de cette quatrième et dernière iso sont les mêmes que celles de la troisième, à ceci près que la place occupée statiquement en mémoire est deux fois inférieure (35 Mo contre 68 Mo pour l’iso 3). Cela veut dire qu’on pourra s’en servir sur des machines avec moins de mémoire ou bien... ajouter encore plus de fonctionnalités !!

2.5 To infinity and beyond... [16] ou comment on rejoint les live-CD ?

Avant de conclure cet article, une dernière remarque. Vu les techniques qu’on a utilisées à la fin, unionfs + squashfs, on n’est pas très loin des techniques de live-CD. Les deux petits scripts qui suivent ajoutent cette fonctionnalité à notre RIM-Linux. On pourra utiliser des fichiers squash se trouvant sur un support quelconque du moment qu’il est monté :

Le premier script use-livemodule.pl prend comme argument un nom de fichier. Ce fichier sera considéré comme un fichier squash. On crée un point de montage, on le monte en loopback et on l’ajoute à l’union. Le second script use-livedir.pl prend comme argument un nom de répertoire, tous les fichiers de ce répertoire sont considérés comme des fichiers squash, montés en loopback et intégrés à l’union. On trouvera deux exemples de fichiers d’extension : firefox-java-plugin.rim (31 Mo) et mplayer-codecs.rim (10Mo). A noter que si l’on place ces fichiers dans le répertoire rootbase/.rimmodules avant la création de l’iso, ils seront intégrés directement dans le Rim-Linux. Mais alors il faudra beaucoup de mémoire pour le faire tourner...

Conclusion

Voilà, nous arrivons au bout de cet article qui je l’espère vous aura intéressé. En le suivant, nous avons vu comment réaliser (de manière quick and dirty sous certains aspects, notamment dans la partie applicative) une mini-distribution fonctionnant entièrement en mémoire vive et comportant de nombreuses fonctionnalités. Cette mini-distribution n’avait pas d’autre fin que de servir de support à cet article, mais elle nous a permis de passer en revue de nombreux aspects sous-jacents d’un système Linux auxquels on ne touche pas vraiment quand on est simple utilisateur d’une distribution moderne où tout est fait pour nous simplifier la vie. Références :

• [1] http://www.bootsplash.de/files/
• [2] http://www.samba.org/
• [3] http://www.freedesktop.org/wiki/Software_2fXserver
• [4] http://www.informatik.hu-berlin.de/~sperling/prog/swm.html
• [5] http://www.nickgravgaard.com/windowlab/
• [6] http://blackboxwm.sourceforge.net/
• [7] http://dist.schmorp.de/rxvt-unicode/
• [8] http://asic-linux.com.mx/~izto/checkinstall/
• [9] http://www.ibiblio.org/mc/
• [10] http://www.arts-project.org/doc/arts-0.5.4.html
• [11] http://ftp.gnome.org/pub/gnome/sources/esound/0.2/
• [12] http://radscan.com/nas.html
• [13] http://www.mozilla.org/firefox
• [14] http://www.mplayerhq.hu/
• [15] http://mplayerplug-in.sourceforge.net/
• [16] Buzz l’éclair dans Toy Story!

• Retrouvez cet article dans : Linux Magazine 82