Looking for Computer Science & Information Technology online
courses ?
Check my new web site: https://www.yesik.it !
Techniquement, il est possible d'installer un système Debian sur une clé USB, et de s'en servir comme s'il s'agissait d'un disque dur. Mais c'est sans compter qu'une mémoire flash (comme celle qui équipe les clés USB) a un nombre de cycles de lecture/écriture limité. Or, en fonctionnement normal, un système Unix sollicite beaucoup le disque. Bref, ce n'est pas l'idéal pour la durée de vie de votre clé.
Face à ce problème, quand on désire disposer d'un Linux bootable sur une clé, une approche plus viable consiste à appliquer la même technique que pour un Live CD. A savoir faire une installation capable de fonctionner en sollicitant au minimum le média contenant le système – et surtout sans requérir la possibilité d'y écrire. Une installation Live atteint ce but en utilisant un RAM disk, souvent couplé à un système de fichiers Copy on Write comme AuFS ou UnionFS, afin de simuler l'existence d'un média disponible en écriture. Le corollaire étant que, dans ce mode de fonctionnement, toutes les modifications effectuées sur un système Live sont perdues à l'arrêt de ce système. Ce qui peut aussi être vu comme un avantage, puisqu'ainsi on peut raisonnablement supposer qu'à chaque démarrage le système est propre et non compromis. Par contre, dans un contexte où la sécurité est importante, on veillera quand même à utiliser un média Write Once Read Many ou équipé d'un dispositif physique pour prévenir l'écriture sur celui-ci. Mais ce n'est pas mon contexte ici...
D'un point de vue pratique, faire une installation Live CD – ou dans notre cas Live USB – est une tâche relativement fastidieuse. Mais Debian Lenny nous facilite le travail grâce à l'outil live-helper(7), dont je vais maintenant me servir pour installer Debian Live sur une clé USB.
Sommaire
Configurer l'environnement de travail
Installation
Sous Debian vous aurez besoin des paquets live-helper et debootstrap pour ce qui suit. Si ces logiciels ne sont pas déjà sur votre machine utilisez le gestionnaire de paquets de votre distribution pour procéder à l'installation.
sh# apt-get install live-helper sh# apt-get install debootstrap
Pour commencer, nous allons tout d'abord créer notre environnement de travail. Un grand mot pour essentiellement dire un dossier dans lequel nous allons construire notre système Live. Nous utiliserons lh_config(1) pour initialiser cet environnement:
sh$ mkdir DEBIAN-LIVE-USB sh$ cd DEBIAN-LIVE-USB # Initialise l'environnement pour la création d'un live sur support USB ou disque dur sh$ lh config -b usb-hdd sh$ ls -la total 36 drwxr-xr-x 5 sylvain sylvain 4096 2010-08-13 20:40 . drwxr-xr-x 99 sylvain sylvain 20480 2010-08-13 20:31 .. drwxr-xr-x 22 sylvain sylvain 4096 2010-08-13 20:40 config drwxr-xr-x 2 sylvain sylvain 4096 2010-08-13 20:40 scripts drwxr-xr-x 2 sylvain sylvain 4096 2010-08-13 20:40 .stage
Comme vous le constatez, la commande lh_config(1) a créé un certain nombre de dossiers et fichiers. Ceux-ci seront utilisés par lh (live-helper) tout au long de son travail. Les fichiers de configuration sont modifiables directement – bien que la procédure recommandée soit de passer plutôt par lh_config(1), comme nous allons le voir dans un instant.
Note:
Vous remarquerez tout au long de cet article – et lors de votre utilisation de live-helper – que les commandes sont écrites tantôt avec un souligné (lh_config), tantôt sans (lh config).
En fait, la vraie commande s'écrit avec un souligné. Mais live-helper fournit aussi une commande générique (lh(1)) qui sert de wrapper pour invoquer les différentes sous-commandes.
Si vous examinez le script /usr/bin/lh vous verrez qu'en l'état actuel des choses, utiliser l'une ou l'autre est surtout une question de préférence...
Personnaliser la configuration
Configurer les miroirs des dépôts
Live-helper télécharge de nombreux paquets pour créer l'image Debian Live. Cela va consommer énormément de bande passante sur votre accès internet. C'est un problème si comme moi vous avez un accès bas débit. Mais même dans le cas contraire, c'est tout de même dommage de télécharger encore et toujours les mêmes paquets si vous êtes amenés à créer plusieurs Live différents. Ou tout simplement si vous vous y reprenez en plusieurs fois pour créer votre distribution idéale.
Pour limiter ce problème, par défaut, live-helper garde en cache dans le répertoire de travail une copie des paquets téléchargés. Ça n'est pas nécessairement la meilleure solution: en effet, la contrepartie est une consommation disque importante en local. D'autant plus, si vous créez plusieurs Live dans des dossiers différents: en effet le cache n'est pas mutualisé.
Dans mon cas, et comme j'ai déjà installé un cache APT sur mon réseau, une solution plus efficace est de solliciter mon proxy APT pour les téléchargements plutôt que les dépôts officiels:
sh$ lh config --mirror-bootstrap http://10.129.36.102:9999/ftp.de.debian.org/debian/ \ --mirror-chroot http://10.129.36.102:9999/ftp.de.debian.org/debian/ \ --mirror-chroot-security http://10.129.36.102:9999/security.debian.org \ --mirror-binary http://10.129.36.102:9999/ftp.de.debian.org/debian/ \ --mirror-binary-security http://10.129.36.102:9999/security.debian.org
--mirror-binary et --mirror-binary-security
Les miroirs configurés avec --mirror-binary et --mirror-binary-security sont ceux qui seront configurés dans le fichier /etc/apt/sources.list du système Live. Et en théorie ils ne devraient pas intervenir lors de la création de cette installation. Pourtant, sur mon système, si!?! C'est pourquoi je les ai configurés aussi avec l'adresse de mon cache APT...
Enfin, comme avec cette configuration la récupération des paquets sur le réseau local est relativement performante, je n'ai plus besoin de garder les paquets en cache sur ma machine:
sh$ lh config --cache-packages disabled
Configurer le clavier et la langue
Après ces modifications somme toute spécifique à ma configuration, voici quelque-chose qui devrait concerner tout utilisateur francophone: Configurer la langue par défaut du système Debian Live – sans oublier de configurer également notre bon vieux clavier AZERTY français. Ces deux opérations se font grâce à l'option --bootappend-live qui permet de spécifier les paramètres de boot qui seront utilisés lors du démarrage du Debian Live:
sh$ lh_config --bootappend-live "locale=fr_FR.UTF-8 keyb=fr"
Piège:
Vous ne pouvez pas configurer les paramètres de boot en plusieurs fois:
# ATTENTION: CECI NE FAIT PAS CE QUE VOUS VOULEZ!!! sh$ lh_config --bootappend-live "locale=fr_FR.UTF-8" sh$ lh_config --bootappend-live "keyb=fr"
En effet, chaque appel à lh_config --bootappend-live ... remplace les paramètres de boot par ceux que vous précisez. Autrement dit, lors de deux appels consécutifs, les paramètres ne sont pas concaténés: les derniers écrasent purement et simplement les premiers.
C'est aussi le comportement des autres options de la commande lh_config.
Ajouter individuellement des paquets
Il est temps maintenant de choisir quels paquets installer sur votre système Live. Plusieurs techniques sont possibles – et vous pouvez même les combiner.
Ainsi, si vous avez des paquets individuels à rajouter, vous pouvez les indiquer dans le fichier config/chroot. Cherchez les lignes suivantes, et indiquez dans LH_PACKAGES les différents paquets qui vous intéressent:
# $LH_PACKAGES: set packages to install
# (Default: empty)
LH_PACKAGES="filezilla iceweasel"
Piège:
La technique officielle consiste à utiliser lh config --packages ...:
sh$ lh config --packages "gdm iceweasel"
Mais il semblerait que dans la version dont je dispose (lh_config version 1.0.3-2), cette commande ne prenne en compte que le premier paquet de la liste spécifiée...
Par ailleurs, live-helper est livré avec un certain nombre de configurations prédéfinies. Celles-ci sont dans /usr/share/live-helper/lists/:
sh$ ls /usr/share/live-helper/lists/ devel-live gnome-junior kde-core lxde standard studio-kde gnome gnustep kde-extra minimal standard-x11 studio-xfce gnome-core junior-pkgs kde-full rescue studio xfce gnome-full kde kde-junior science studio-gnome xfce-junior
Imaginons que je souhaite utiliser mon Debian Live pour faire de l'analyse forensic. La configuration rescue contient (entre autres) les paquets nécesssaires. Si en plus, je ne veux pas me passer de mon environnement graphique Gnome, j'aurais aussi besoin de gnome-core. Pour indiquer que je veux les paquets de ces deux jeux, il faut modifier LH_PACKAGES_LISTS dans le fichier config/chroot:
# $LH_PACKAGES_LISTS: set package list to install
# (Default: rescue)
LH_PACKAGES_LISTS="rescue gnome-core"
Piège:
Ici encore, la technique officielle qui utilise la commande lh config --packages-lists ... ne permet pas d'indiquer plusieurs listes de paquets, c'est pourquoi je modifie le fichier à la main.
Construire l'image
Une fois toutes les opérations de configuration effectuées, reste à construire l'image. Deux techniques sont possibles. Tout-en-un. Ou étape par étape.
Tout-en-un
La construction de l'image Live se fait en quatre étapes. Live-helper fournit la commande lh_build(1) pour les enchaîner automatiquement. C'est donc le moyen le plus simple de procéder quand vous n'avez pas besoin d'intervenir au cours du processus (par exemple, pour changer manuellement un fichier de configuration):
sh$ sudo lh build
Remarque:
lh build monte l'image comme un périphérique loop. C'est pourquoi cette commande requiert les privilèges root.
Après quelques minutes – voire quelques heures si vous téléchargez beaucoup de paquets – vous obtenez l'image de votre installation Live:
sh$ ls -ld binary*
drwxr-xr-x 6 root root 4096 2010-08-17 14:53 binary
-rw-r--r-- 1 root root 149946368 2010-08-17 14:53 binary.img
-rw-r--r-- 1 root root 2184 2010-08-17 14:53 binary.list
-rw-r--r-- 1 root root 15952 2010-08-17 14:53 binary.packages
Étape par étape
Si lh_build(1) enchaîne automatiquement les étapes, il est aussi possible de les exécuter manuellement les unes après les autres:
# Installe un système de base avec debootstrap(8) (ou cdebootstrap(1)). sh$ sudo lh bootstrap # Installe les paquets supplémentaires dans l'environnement chroot(8). sh$ sudo lh chroot # Construit l'image disque. sh$ sudo lh binary sh$ ls -ld binary* drwxr-xr-x 6 root root 4096 2010-08-17 14:27 binary -rw-r--r-- 1 root root 149946368 2010-08-17 14:27 binary.img -rw-r--r-- 1 root root 2184 2010-08-17 14:27 binary.list -rw-r--r-- 1 root root 15952 2010-08-17 14:27 binary.packages
# Étape optionnelle: Ajoute les sources de l'image dans le dossier chroot. # Pour faire quelque chose, cette étape nécessite que LH_SOURCE soit # définie à "enabled" dans le fichier "config/source". sh$ sudo lh source
Dans la pratique, décomposer les différents étapes ne semble réellement utile que si vous souhaiter intervenir sur l'installation (située dans le dossier chroot) au cours du processus. Ce que nous allons illustrer avant la fin de cet article...
Installation sur le média
Copier l'image
Nous voici avec une image toute propre, prête à être copiée sur clé USB. La procédure est simple, car l'image binary.img est une image disque complète. La commande dd(1) va donc être parfaitement suffisante. Mais cela nécessite de savoir à quel périphérique bloc votre clé USB est associée. Après l'avoir connectée à votre ordinateur, vous devriez pouvoir obtenir cette information en consultant dmesg(1):
sh$ sudo dmesg | grep sd | tail -6 sd 1:0:0:0: [sda] 15646720 512-byte hardware sectors (8011 MB) sd 1:0:0:0: [sda] Write Protect is off sd 1:0:0:0: [sda] Mode Sense: 23 00 00 00 sd 1:0:0:0: [sda] Assuming drive cache: write through sda: sda1 sd 1:0:0:0: [sda] Attached SCSI removable disk
Comme vous le constatez, je récupère un certain nombre d'informations intéressantes. Tout d'abord, visiblement le média que je viens d'introduire correspond au périphérique bloc /dev/sda (les périphériques USB sont des périphériques série – d'où sda). Par ailleurs, la taille du média confirme que c'est ma clé: 15646720 blocs × 512 octets/bloc = 8011120640 octets. Soit 8011 Mo.
Enfin, une information importante m'est donnée:
sda: sda1
Cela signifie que cette clé contient une partition accessible via /dev/sda1. Il faut démonter toutes les partitions de la clé avant de poursuivre. Donc, dans mon cas:
sh$ mount | grep sda /dev/sda1 on /media/MA_CLE type vfat (rw,nosuid,nodev,uhelper=hal,shortname=lower,uid=1000) sh$ sudo umount /dev/sda1
Maintenant que tout est prêt, passons à la copie. Mais avant un avertissement important: le contenu de la clé va être entièrement perdu lors de l'installation de l'image disque! Ok. Pas de regrets? Alors, allons-y:
sh$ sudo dd if=binary.img of=/dev/sda
292864+0 records in
292864+0 records out
149946368 bytes (150 MB) copied, 39.8048 s, 3.8 MB/s
Remarque:
Une fois l'installation terminée, plutôt que de rebooter tout de suite, vous pouvez tester votre Live USB à l'aide de votre outil de virtualisation préféré. Par exemple, avec QEMU:
sh$ qemu -hda /dev/sda
Ajouter une partition utilisateur
Donc, nous voici avec une image Live sur une clé USB. D'un autre côté, c'est peut-être dommage de ne pouvoir rien enregistrer d'une utilisation à l'autre alors que l'on dispose tout de même d'un média disponible en écriture.
Debian Live offre plusieurs options à cet effet. Ainsi, il est en théorie possible de monter automatiquement sur /home une partition à la simple condition qu'elle soit nommée home-rw. Dans la pratique, je n'y suis pas parvenu. Et les examens des scripts impliqués montrent qu'ils sont conçus pour monter la première partition ou image disque qui porte le nom adéquat. Ce qui me laisse un doute du point de vue de la sécurité: en effet, je veux être certain de monter la partition de ma clé. Pas une partition d'un disque attaché au système et qui par hasard posséderait le nom magique...
C'est donc l'occasion de voir que l'on peut customiser une installation live. Ici, je vais ajouter un script de démarrage pour monter la seconde partition de ma clé sur le répertoire /home/user. C'est un script de démarrage à installer dans DEBIAN-LIVE-USB/chroot/etc/init.d/:
sh$ cd chroot/etc/init.d
sh$ cat > local-mount-home.sh << EOF
#! /bin/sh
### BEGIN INIT INFO
# Provides: local-mount-home
# Required-Start: checkfs
# Required-Stop:
# Default-Start: S
# Default-Stop:
# Short-Description: Mount user file system
# Description:
### END INIT INFO
PATH=/sbin:/bin:/usr/bin
. /lib/lsb/init-functions
do_start()
{
#
# Mount the second partition of the boot device on /home/user
#
# !!! This assume:
# The live user name is 'user'
# The live user uid is 1000
# The live user gid is 1000
# The boot partition is the first on the device
# The 'user' partition is the second
# Get the boot partition
BOOT_PART=`mount | grep /live/image | cut -d ' ' -f 1`
# Get the second paritition on the same device
HOME_PART=`echo ${BOOT_PART} | sed 's/1$/2/'`
# mount options for fat32
mount ${HOME_PART} /home/user -o rw,gid=1000,uid=1000,noatime
}
do_stop ()
{
umount /home/user
}
case "$1" in
start|"")
do_start
;;
restart|reload|force-reload)
stop
start
;;
stop)
stop
;;
*)
echo "Usage: local-mount-home.sh [start|stop]" >&2
exit 3
;;
esac
EOF
Le script est long à cause de la plomberie inhérente à tout script de démarrage. Mais en réalité son fonctionnement se résume en trois lignes pour monter la seconde partition du disque contenant l'image de boot:
# ... BOOT_PART=`mount | grep /live/image | cut -d ' ' -f 1` HOME_PART=`echo ${BOOT_PART} | sed 's/1$/2/'` mount ${HOME_PART} /home/user -o rw,gid=1000,uid=1000,noatime
Remarque:
Ce script est adapté à ma configuration. Comme indiqué dans les commentaires, un certain nombre de conditions sont pré-supposées. Il faudra donc l'adapter si vous sortez du cadre strict décrit ici.
Ce script est à lancer au démarrage après mountall:
sh$ sudo ln -s S37local-mount-home.sh ../init.d/local-mount-home.sh
Voilà: j'ai modifié le système installé par live-helper dans le dossier chroot. Reste à reconstruire l'image disque. C'est l'étape binary dans live-helper. Avant de relancer une étape, il est nécessaire de demander à lh_clean de faire le ménage:
# On revient à la racine du répertoire d'installation sh$ cd ../../.. sh$ basename `pwd` DEBIAN-LIVE-USB # On 'efface' l'étape 'binary' sh$ sudo lh clean --binary # On relance l'étape 'binary' sh$ sudo lh binary
Une fois cela fait, il faut recopier la nouvelle image sur la clé (comme précédemment):
sh$ dd if=binary.img of=/dev/sda
Et enfin, je vais créer une seconde partition sur la clé pour qu'elle puisse être montée par mon script de démarrage. Ici, vous pouvez utiliser les outils classiques fdisk(8) et mkfs(8). Pour ma part, je vais plutôt utiliser parted(8) (la version texte de gparted(8)):
# Afficher la table des partitions de la clé sh$ /sbin/parted /dev/sda print WARNING: You are not superuser. Watch out for permissions. Model: Kingston DataTraveler G2 (scsi) Disk /dev/sda: 8011MB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 512B 150MB 150MB primary fat16 boot
Voici donc la table des partitions de ma clé après installation de l'image Debian Live. Une seule partition de 150Mo. Beaucoup d'espace perdu sur une cla de 8Go! Créons donc une partition supplémentaire:
# Nouvelle partition primaire sur /dev/sda qui s'étend de la fin de # la partition 1 (voir résultat de "parted /dev/sda print") # jusqu'à la fin du disque (100%). La partition va être formatée # en "fat32" sh$ sudo parted /dev/sda mkpartfs primary fat32 150MB 100%
Piège:
Ici, j'utilise FAT32 pour pouvoir continuer à utiliser mon média comme une clé USB ordinaire sur la majorité des systèmes.
Mais, si vous préférez, vous pouvez utiliser un autre système de fichier comme ext2 par exemple. Par contre évitez ext3 ou tout autre système de fichiers journalisé. En effet, un tel système de fichier cause beaucoup (trop) d'écritures pour une utilisation avec une mémoire flash comme celle d'une clé USB.
Voilà: l'image est installée, et une seconde partition est disponible sur la clé. Je vous laisse rebooter pour constater que ça marche!
Attention:
Je le répète: à chaque réinstallation de l'image sur la clé, dd va écraser l'image et la table des partitions rendant les données stockées sur clé inaccessibles! Pensez à faire un backup de votre partition utilisateur lors de la mise à jour de votre système live. D'ailleurs, l'ensemble du processus gagnerait à être automatisé par script. Ce qui devrait être relativement aisé...
Conclusion
Au final, live-helper est un outil bien pratique pour créer un système live. En effet, malgré quelques bugs ou difficultés d'utilisation, il permet de produire un système Debian Live sans obstacle majeur. Et qui plus est, un live que vous pouvez adapter à votre besoin spécifique. La seule barrière à une adoption large est sans doute la documentation actuellement réduite. Mais en tout cas, j'espère que cet article vous donnera l'envie et les informations nécessaires pour pouvoir entreprendre la création de votre propre Live!
