Titre: Manuel Live Systems
Auteur: Projet Live Systems <debian-live@lists.debian.org>
Droits relatifs à la ressource: Copyright: Copyright (C) 2006-2015 Live Systems Project
License: Ce programme est un logiciel libre; vous pouvez le redistribuer ou le modifier suivant les termes de la Licence Générale Publique GNU telle que publiée par la Free Software Foundation: soit la version 3 de cette licence, soit (à votre gré) toute version ultérieure.

Ce programme est distribué dans l’espoir qu’il vous sera utile, mais SANS AUCUNE GARANTIE: sans même la garantie implicite de COMMERCIALISABILITÉ ni d’ADÉQUATION À UN OBJECTIF PARTICULIER. Consultez la Licence Générale Publique GNU pour plus de détails.

Vous devriez avoir reçu une copie de la Licence Générale Publique GNU avec ce programme ; si ce n’est pas le cas, consultez http://www.gnu.org/licenses/.

Le texte complet de la Licence Générale Publique GNU peut être trouvé dans le fichier / usr/share/common-licenses/GPL-3

Éditeur: Projet Live Systems <debian-live@lists.debian.org>
Date: 01.05.2015
Fichier source: live-manual.ssm.sst
Filetype: UTF-8 assumed, file encoding check program unavailable
Source digest: SHA256(live-manual.ssm.sst)= a6bb7d135c85d6464592dddbc3845bd398136fd49cd033ab494b0cbed504b679
Generated by: Généré par: SiSU 7.1.2 of 2015w20/1 (2015-05-18)
Version de ruby: ruby 2.1.3p242 (2014-09-19) [x86_64-linux-gnu]
Dernière production du document (metaverse): 2015-05-21 14:50:10 +0000
Manuel Live Systems 1 À propos 2 À propos de ce manuel 3 1. À propos de ce manuel 4 L'objectif principal de ce manuel est de servir de point d'accès unique à tous les documents liés au Live Systems Project et particulièrement aux logiciels produits par le projet pour Debian 9.0 « stretch». Une version mise à jour peut toujours ê tre trouvée sur <http://live-systems.org/> . 5 Ce manuel a principalement pour but de vous aider à construire un système live et non pas de s'articuler autour des sujets relatifs à l'utilisateur final. Toutefois, l'utilisateur final peut trouver des informations utiles dans ces sections: Les Bases couvrent le téléchargement des images précompilées et la préparation des images pour ê tre démarrées sur les supports ou sur le réseau, soit en utilisant le constructeur web, soit en exécutant live-build directement sur le système. Personnalisation des comportements pendant l'exécution décrit certaines options qui peuvent ê tre indiquées à l'invite de démarrage, telles que la sélection d'un clavier, des paramètres régionaux et la persistance. 6 Certaines commandes mentionnées dans le texte doivent ê tre exécutées avec les privilèges de super-utilisateur, qui peuvent ê tre obtenus à l'aide de la commande su ou en utilisant sudo. Afin de distinguer les commandes qui peuvent ê tre exécutées par un utilisateur sans privilège de celles nécessitant les privilèges de super-utilisateur, les commandes sont précédées respectivement par $ ou #. Notez que ce symbole ne fait pas partie de la commande. 7 1.1 Pour les impatients 8 Même si nous croyons que tout dans ce manuel est important pour au moins certains de nos utilisateurs, nous nous rendons compte qu'il y a beaucoup de matière à couvrir et que vous pouvez vouloir expérimenter avant d'entrer dans les détails. Par conséquent, nous vous suggérons de lire dans l'ordre suivant. 9 Tout d'abord, lisez ce chapitre À propos de ce manuel dès le début et finissant avec la section Terminologie. Ensuite, passez aux trois tutoriels à l'avant de la section Exemples destinée à vous apprendre la construction de l'image et les bases de la personnalisation. Lisez en premier En utilisant les exemples, puis Tutoriel 1: Une image par défaut, Tutoriel 2: Un logiciel de navigateur Web et finalement Tutoriel 3: Une image personnalisée. À la fin de ces tutoriels, vous aurez un avant-goüt de ce qui peut ê tre fait avec les systèmes live. 10 Nous vous encourageons à revenir à l'étude plus approfondie du manuel, en poursuivant par exemple votre lecture par Les bases, Construire une image netboot et finissant par la lecture de la Vue d'ensemble de la personnalisation et les sections suivantes. Après cela, nous espérons que vous serez complètement excités par ce qui peut ê tre fait avec les systèmes live et motivés pour lire le reste du manuel, du début à la fin. 11 1.2 Terminologie 12 Système Live: Un système d'exploitation pouvant ê tre démarré sans installation préalable sur un disque dur. Les systèmes live ne modifient pas le système d'exploitation local ou les fichiers installés sur le disque dur sans qu'on leur en donne explicitement l'instruction. D'habitude, les systèmes live sont démarrés à partir des supports tels que des CDs, DVDs, ou des clés USB. Certains systèmes peuvent é galement ê tre démarrés sur le réseau (via des images netboot, voir Construction d'une image netboot), et sur l'Internet (via le paramètre d'amorçage fetch=URL, voir Webbooting). 13 Support live: À la différence du système live, le support live se réfère au CD, DVD ou clé USB oú l'image binaire produite par live-build et utilisée pour démarrer le système live est é crite. D'une manière générale, le terme désigne é galement tout emplacement oú réside l'exécutable qui permet de démarrer le système live, tel que l'emplacement des fichiers de démarrage sur le réseau. 14 Live Systems Project: Le projet qui maintient, entre autres, les paquets live-boot, live-build, live-config live-tools et live-manual. 15 Système hôte: L'environnement utilisé pour créer le système live. 16 Système cible: L'environnement utilisé pour faire fonctionner le système live. 17 live-boot: Une collection de scripts utilisés pour lancer des systèmes live. 18 live-build: Une collection de scripts utilisés pour construire des systèmes live personnalisés. 19 live-config: Une collection de scripts utilisés pour configurer un système live pendant le processus d'amorçage. 20 live-tools: Une collection de scripts supplémentaires utilisés pour effectuer des tâches utiles dans un système live en fonctionnement. 21 live-manual: Ce document est maintenu dans un paquet nommé live-manual. 22 Debian Installer (d-i): Le système d'installation officiel pour la distribution Debian. 23 Paramètres d'amorçage: Les paramètres qui peuvent ê tre entrés à l'invite de démarrage afin de modifier le noyau ou live-config. 24 chroot: Le logiciel chroot, chroot(8), nous permet d'exécuter plusieurs instances concurrentes de l'environnement GNU/Linux sur un système sans redémarrage. 25 Image binaire: Un fichier contenant le système live, tel que live-image-i386.hybrid.iso ou live-image-i386.img. 26 Distribution cible: La distribution sur laquelle votre système live sera basée. Celle-ci peut ê tre différente de la distribution de votre système hôte. 27 stable/testing/unstable: La distribution stable, actuellement nommée stretch, contient la dernière version officielle de Debian. La distribution testing, temporairement nommée buster, est la prochaine version stable oú seulement les paquets suffisamment matures peuvent entrer. Un avantage de cette distribution est qu'elle contient des logiciels de versions plus récentes que la version stable. La distribution unstable, nommée sid de façon permanente, est en constante é volution. En général cette distribution est utilisée par les développeurs et ceux qui aiment le risque. Tout au long du manuel, nous avons tendance à utiliser les noms de code pour les é volutions majeures, tels que buster ou sid, car c'est ce qui est pris en charge par les outils eux-mêmes. 28 1.3 Auteurs 29 La liste des auteurs (dans l'ordre alphabétique): 30 Ben Armstrong 31 Brendan Sleight 32 Carlos Zuferri 33 Chris Lamb 34 Daniel Baumann 35 Franklin Piat 36 Jonas Stein 37 Kai Hendry 38 Marco Amadori 39 Mathieu Geli 40 Matthias Kirschner 41 Richard Nelson 42 Trent W. Buck 43 1.4 Contribuer à ce document 44 Ce manuel est conçu comme un projet communautaire et toutes les propositions d'améliorations et de contributions sont bienvenues. Veuillez consulter la section Contribuer au projet pour des informations détaillées sur la façon d'obtenir une clé et de faire des livraisons (commits). 45 1.4.1 Appliquer des modifications 46 Afin d'apporter des modifications au manuel anglais, vous devez modifier les fichiers adéquats dans manual/en/ mais avant de soumettre votre contribution, veuillez prévisualiser votre travail. Afin de prévisualiser live-manual, assurez-vous que les paquets nécessaires sont installés en exécutant: 47 48 # apt-get install make po4a ruby ruby-nokogiri sisu-complete
Vous pouvez compiler live-manual dans le répertoire de niveau supérieur de votre Git checkout en exécutant: 49 50 $ make build
Comme il faut un certain temps pour construire le manual dans toutes les langues prises en charge, les auteurs peuvent trouver pratique d'utiliser l'un des raccourcis de construction rapide lors de la révision de la nouvelle documentation ajoutée au manuel anglais. PROOF=1 construit live-manual au format html, mais sans les fichiers html segmentés, et PROOF=2 construit live-manual au format pdf, mais seulement les portraits A4 et US. C'est pourquoi l'utilisation de l'une ou l'autre des possibilités peut sauver une quantité considérable de temps, par exemple: 51 52 $ make build PROOF=1
Lors de la révision d'une des traductions, il est possible de construire une seule langue en exécutant, par exemple: 53 54 $ make build LANGUAGES=de
Il est é galement possible de construire par type de document, par exemple, 55 56 $ make build FORMATS=pdf
Ou combiner les deux, par exemple: 57 58 $ make build LANGUAGES=de FORMATS=html
Après avoir relu votre travail et vous ê tre assuré que tout va bien, n'utilisez pas make commit à moins que vous mettiez à jour les traductions dans le commit. Dans ce cas, ne mélangez pas les modifications apportées au manuel en anglais et les traductions dans la même livraison, mais utilisez des commits séparés. Consultez la section Traduction pour plus de détails. 59 1.4.2 Traduction 60 Afin de traduire live-manual, procédez comme suit, selon que vous commencez une traduction à partir de zéro ou vous travaillez sur une traduction déjà existante: 61 Commencer une nouvelle traduction à partir de zéro 62 Traduisez les fichiers about_manual.ssi.pot, about_project.ssi.pot et index.html.in.pot dans manual/pot/ dans votre langue avec votre é diteur préféré (comme poedit) . Envoyez les fichiers .po traduits à la liste de diffusion pour vérifier leur intégrité. La vérification d'intégrité de live-manual garantit non seulement que les fichiers .po sont 100% traduits, mais elle détecte é galement des erreurs possibles. 63 Pour activer une nouvelle langue dans l'autobuild, il suffit d'ajouter les premiers fichiers traduits à manual/po/${LANGUAGE}/ et lancer make commit. Modifier ensuite manual/_sisu/home/index.html en ajoutant le nom de la langue et son nom en anglais entre parenthèses. 64 Continuer avec une traduction déjà commencée 65 Si votre langue cible a déjà é té ajoutée, vous pouvez continuer avec la traduction des fichiers .po dans manual/po/${LANGUAGE}/ de façon aléatoire avec votre é diteur préféré (comme poedit) . 66 N'oubliez pas que vous devez faire un make commit pour assurer que la traduction des manuels est mise à jour à partir des fichiers .po, alors vous pouvez réviser vos modifications avec make build avant git add ., git commit -m "Translating..." et git push. Gardez à l'esprit que make build peut prendre un temps considérable, vous pouvez relire les langues individuellement comme expliqué dans Appliquer des modifications 67 Après l'exécution de make commit, vous verrez beaucoup de texte sur l'écran. Il s'agit essentiellement de messages informatifs sur l'état du processus et de quelques indications sur ce qui peut ê tre fait pour améliorer live-manual. Si vous ne voyez aucune erreur fatale, vous pouvez généralement continuer et soumettre votre contribution. 68 live-manual contient deux utilitaires qui peuvent grandement aider les traducteurs à trouver les textes non traduits et modifiés. Le premier est "make translate". Il lance un script qui vous indique en détail le nombre de messages non traduits qu'il y a dans chaque fichier .po. Le second, "make fixfuzzy", n'agit que sur les messages modifiés, mais il vous aide à les trouver et à les résoudre un par un. 69 Gardez à l'esprit que même si ces utilitaires peuvent ê tre vraiment utiles pour faire un travail de traduction sur la ligne de commande, l'utilisation d'un outil spécialisé comme poedit est la méthode recommandée pour effectuer la tâche. C'est aussi une bonne idée de lire la documentation sur localisation de debian (l10n) et, plus particulièrement pour live-manual, les Lignes directrices pour les traducteurs. 70 Remarque: Vous pouvez utiliser make clean pour nettoyer votre arbre git avant de faire un push. Cette é tape n'est pas obligatoire grâce au fichier .gitignore mais c'est une bonne pratique pour é viter d'envoyer certains fichiers involontairement. 71 À propos du Live Systems Project 72 2. À propos du Live Systems Project 73 2.1 Motivation 74 2.1.1 Ce qui ne va pas avec les systèmes live actuels 75 Lorsque le Live Systems Project a é té lancé, il y avait déjà plusieurs systèmes live basés sur Debian et ils faisaient un excellent travail. Du point de vue de Debian, la plupart d'entre eux ont un ou plusieurs des inconvénients suivants: 76 Ce ne sont pas des projets Debian et ils manquent donc de soutien au sein de Debian. 77 Ils mélangent des distributions différentes comme testing et unstable. 78 Ils ne prennent en charge que i386. 79 Ils modifient le comportement et/ou l'apparence des paquets en les dépouillant pour é conomiser de l'espace. 80 Ils comprennent des paquets ne provenant pas de l'archive Debian. 81 Ils offrent des noyaux personnalisés avec des correctifs supplémentaires qui ne font pas partie de Debian. 82 Ils sont gros et lents en raison de leur dimension et donc pas recommandés comme systèmes de sauvetage. 83 Ils ne sont pas disponibles en différents formats (CDs, DVDs, clés USB et images netboot). 84 2.1.2 Pourquoi créer notre propre système live? 85 Debian est le système d'exploitation universel: Debian a un système live pour servir de vitrine et pour représenter le vrai, seul et unique système Debian avec les principaux avantages suivants: 86 C'est un sous-projet de Debian. 87 Il reflète l'état (actuel) d'une distribution. 88 Il fonctionne sur le plus grand nombre d'architectures possible. 89 Il ne se compose que de paquets Debian inchangés. 90 Il ne contient pas de paquets qui n'appartenant pas à l'archive Debian. 91 Il utilise un noyau Debian inchangé, sans correctifs supplémentaires. 92 2.2 Philosophie 93 2.2.1 Seulement des paquets inchangés de Debian « main» 94 Nous n'utiliserons que les paquets du dépôt Debian dans la section « main». La section non-free ne fait pas partie de Debian et ne peut donc pas ê tre utilisée pour les images officielles du système live. 95 Nous ne changerons pas les paquets. Chaque fois que nous aurons besoin de changer quelque chose, nous le ferons en coordination avec le responsable du paquet dans Debian. 96 À titre d'exception, nos propres paquets tels que live-boot, live-build ou live-config peuvent ê tre utilisés temporairement à partir de notre propre dépôt pour des raisons de développement (par exemple pour créer des instantanés de développement). Ils seront téléchargés sur Debian régulièrement. 97 2.2.2 Pas de configuration des paquets du système live 98 Dans cette phase, nous n'offrirons pas de configurations alternatives. Tous les paquets sont utilisés dans leur configuration par défaut comme ils sont après une installation standard de Debian. 99 Chaque fois que nous aurons besoin d'une configuration par défaut différente, nous la ferons en coordination avec le responsable du paquet dans Debian. 100 Un système de configuration des paquets est fourni avec debconf permettant la personnalisation des paquets installés sur vos images live, mais pour les images live précompilées seulement une configuration par défaut sera utilisée sauf si c'est absolument nécessaire pour fonctionner dans l'environnement live. Autant que possible, nous préférons adapter les paquets dans l'archive Debian de sorte qu'ils fonctionnent mieux dans un système live plutôt que faire des changements à l'ensemble d'outils live ou les configurations des images live. Pour plus d'informations, veuillez consulter Vue d'ensemble de la personnalisation. 101 2.3 Contact 102 Liste de diffusion: Le contact principal du projet est la liste de diffusion <https://lists.debian.org/debian-live/>. Vous pouvez envoyer un courriel à la liste directement en adressant votre courrier à <debian-live@lists.debian.org.> Les archives de la liste sont disponibles sur <https://lists.debian.org/debian-live/>. 103 IRC: Un certain nombre d'utilisateurs et de développeurs sont présents dans le canal #debian-live sur irc.debian.org (OFTC). Quand vous posez une question sur IRC, s'il vous plaît soyez patient en attendant une réponse. Si aucune réponse n'est donnée, veuillez envoyer un courriel à la liste de diffusion. 104 BTS: Le Système de suivi des bogues⌡<https://www.debian.org/Bugs/> (BTS) contient les détails des bogues signalés par les utilisateurs et les développeurs. Chaque bogue reçoit un numéro et est conservé jusqu'à ce qu'il soit marqué comme traité. Pour plus d'informations, veuillez consulter ⌠Rapporter des bogues. 105 Utilisateur 106 Installation 107 3. Installation 108 3.1 Exigences 109 Les exigences pour la création des images des systèmes live sont très faibles: 110 Accès super-utilisateur (root) 111 Une version mise à jour de live-build 112 Un shell POSIX, comme bash ou dash 113 debootstrap ou cdebootstrap 114 Linux 2.6.x ou supérieur. 115 Notez que l'utilisation de Debian ou d'une distribution dérivée de Debian n'est pas nécessaire - live-build fonctionne sur presque toutes les distributions remplissant les exigences ci-dessus. 116 3.2 Installation de live-build 117 Vous pouvez installer live-build d'un certain nombre de façons différentes: 118 À partir du dépôt Debian 119 À partir du code source 120 À partir des instantanés 121 Si vous utilisez Debian, la méthode recommandée consiste à installer live-build à partir du dépôt Debian. 122 3.2.1 À partir du dépôt Debian 123 Il suffit d'installer live-build comme n'importe quel autre paquet: 124 125 # apt-get install live-build
3.2.2 À partir du code source 126 live-build est développé en utilisant le système de contrôle de version Git. Dans les systèmes basés sur Debian, il est fourni par le paquet git. Pour examiner le dernier code, exécutez: 127 128 $ git clone git://live-systems.org/git/live-build.git
Vous pouvez compiler et installer votre propre paquet Debian en exécutant: 129 130 $ cd live-build
   $ dpkg-buildpackage -b -uc -us
   $ cd ..
Maintenant, installez les fichiers récemment construits qui vous intéressent, par exemple 131 132 # dpkg -i live-build_4.0-1_all.deb
Vous pouvez é galement installer live-build directement sur votre système en exécutant: 133 134 # make install
et le désinstaller avec: 135 136 # make uninstall
3.2.3 À partir des instantanés 137 Si vous ne souhaitez pas créer ou installer live-build à partir des sources, vous pouvez utiliser des instantanés. Ils sont construits automatiquement à partir de la dernière version du dépôt Git et sont disponibles sur <http://live-systems.org/debian/>. 138 3.3 Installation de live-boot et live-config 139 Remarque: Vous n'avez pas besoin d'installer live-boot ou live-config sur votre système afin de créer des systèmes live. Cependant, cela ne fera aucun mal et est utile à des fins de référence. Si vous voulez seulement la documentation, vous pouvez maintenant installer les paquets live-boot-doc et live-config-doc séparément. 140 3.3.1 À partir du dépôt Debian 141 live-boot et live-config sont tous les deux disponibles dans le dépôt Debian comme expliqué dans Installation de live-build. 142 3.3.2 À partir du code source 143 Pour utiliser les dernières sources du git, vous pouvez suivre la procédure ci-dessous. Veuillez vous assurer que vous ê tes familiarisé avec les termes mentionnés dans Termes. 144 Examiner les sources de live-boot et live-config 145 146 $ git clone git://live-systems.org/git/live-boot.git
   $ git clone git://live-systems.org/git/live-config.git
Consultez les pages de manuel de live-boot et live-config pour plus de détails sur la personnalisation si la raison pour laquelle vous créez vos paquets à partir des sources. 147 Créer les fichiers .deb de live-boot et live-config 148 Vous devez créer sur votre distribution cible ou dans un chroot contenant votre plateforme cible: cela signifie que si votre cible est buster alors vous devez créer sur buster. 149 Utilisez un système de construction automatique personnel tel que pbuilder ou sbuild si vous avez besoin de créer live-boot pour une distribution cible qui diffère de votre système de construction. Par exemple, pour les images live de buster, créez live-boot dans un chroot buster. Si votre distribution cible correspond à votre distribution vous pouvez créer directement sur le système de construction en utilisant dpkg-buildpackage (fourni par le paquet dpkg-dev) : 150 151 $ cd live-boot
   $ dpkg-buildpackage -b -uc -us
   $ cd ../live-config
   $ dpkg-buildpackage -b -uc -us
Utiliser les fichiers .deb générés nécessaires. 152 Comme live-boot et live-config sont installés par le système de construction live-build, l'installation de ces paquets dans le système hôte ne suffit pas: vous devez traiter les fichiers .deb générés comme d'autres paquets personnalisés. Comme votre objectif pour la construction à partir du code source est de tester nouvelles choses à court terme avant leur publication officielle, suivez Installation de paquets modifiés ou de tiers pour inclure temporairement les fichiers pertinents dans votre configuration. En particulier, remarquez que les deux paquets sont divisés en une partie générique, une partie de documentation et un ou plusieurs back-ends. Incluez la partie générique, un seul back-end et é ventuellement la documentation. En supposant que vous construisiez une image live dans le répertoire courant et ayez généré tous les fichiers .deb pour une version unique des deux paquets dans le répertoire ci-dessus, ces commandes bash copieraient tous les paquets appropriés, y compris les back-ends par défaut: 153 154 $ cp ../live-boot{_,-initramfs-tools,-doc}*.deb &#160;config/packages.chroot/
   $ cp ../live-config{_,-sysvinit,-doc}*.deb &#160;config/packages.chroot/
3.3.3 À partir des instantanés 155 Vous pouvez laisser live-build utiliser automatiquement les derniers instantanés de live-boot et live-config en configurant le dépôt tiers live-systems.org dans votre répertoire de configuration de live-build. 156 Les bases 157 4. Les bases 158 Ce chapitre contient un bref aperçu du processus de construction et des instructions pour utiliser les trois types d'images les plus couramment utilisées. Le type d'image le plus polyvalent, iso-hybrid, peut ê tre utilisé sur une machine virtuelle, un support optique ou un périphérique USB de stockage portable. Dans certains cas particuliers, comme expliqué plus loin, le type hdd peut ê tre plus approprié. Le chapitre contient des instructions détaillées pour la construction et l'utilisation d'une image netboot, qui est un peu plus compliquée en raison de la configuration requise sur le serveur. C'est un sujet un peu avancé pour tous ceux qui ne connaissent pas déjà le démarrage sur le réseau, mais est inclus ici car une fois la configuration terminée, c'est un moyen très pratique pour tester et déployer des images pour le démarrage sur le réseau local sans le tracas des supports d'images. 159 La section se termine par une brève introduction à webbooting qui est, peut-être, la meilleure façon d'utiliser des images différentes à des fins différentes, changeant de l'un à l'autre en fonction des besoins en utilisant l'Internet comme un moyen. 160 Tout au long du chapitre, nous ferons souvent référence à la valeur par défaut des noms des fichiers produits par live-build. Si vous téléchargez une image précompilée, les noms des fichiers peuvent varier. 161 4.1 Qu'est-ce qu'un système live? 162 Un système live signifie généralement un système d'exploitation démarré sur un ordinateur à partir d'un support amovible, tel qu'un CD-ROM, une clé USB ou sur un réseau, prêt à l'emploi sans aucune installation sur le disque habituel, avec auto-configuration fait lors de l'exécution (voir Termes). 163 Avec les systèmes live, c'est un système d'exploitation, construit pour une des architectures prises en charge (actuellement amd64 et i386). Il est fait à partir des é léments suivants: 164 Image du noyau Linux, d'habitude appelé vmlinuz* 165 Image du RAM-disque initiale (initrd): Un disque virtuel RAM configuré pour le démarrage de Linux, contenant possiblement des modules nécessaires pour monter l'image du système et certains scripts pour le faire. 166 Image du système: L'image du système de fichiers du système d'exploitation. Habituellement, un système de fichiers SquashFS comprimé est utilisé pour réduire au minimum la taille de l'image live. Notez qu'il est en lecture seulement. Ainsi, lors du démarrage le système live va utiliser un disque RAM et un mécanisme "union" pour permettre l'écriture de fichiers dans le système en marche. Cependant, toutes les modifications seront perdues lors de l'arrêt à moins que l'option « persistance» soit utilisée (voir Persistance). 167 Chargeur d'amorçage: Un petit morceau de code conçu pour démarrer à partir du support choisi, il peut présenter un menu rapide ou permettre la sélection des options/configurations. Il charge le noyau Linux et son initrd pour fonctionner avec un système de fichiers associé. Différentes solutions peuvent ê tre utilisées, selon le support de destination et le format du système de fichiers contenant les composants mentionnés précédemment: isolinux pour démarrer à partir d'un CD ou DVD au format ISO9660, syslinux pour démarrer un disque dur ou une clé USB à partir d'une partition VFAT, extlinux pour partitions ext2/3/4 et btrfs, pxelinux pour netboot PXE, GRUB pour partitions ext2/3/4, etc. 168 Vous pouvez utiliser live-build pour construire l'image du système à partir de vos spécifications, configurer un noyau Linux, son initrd, et un chargeur d'amorçage pour les exécuter, tout dans un format en fonction du support (image ISO9660, image disque, etc.). 169 4.2 Téléchargement des images précompilées 170 Bien que l'objectif de ce manuel soit le développement et la création de vos propres images live, vous pouvez simplement vouloir tester une de nos images précompilées comme une introduction à leur utilisation ou à la construction de vos propres images. Ces images sont construites à l'aide de notre dépôt git live-images et les versions officielles stables sont publiées sur <https://www.debian.org/CD/live/>. En outre, les versions plus anciennes et les futures, et des images non officielles contenant micrologiciels et pilotes non libres sont disponibles sur <http://live-systems.org/cdimage/release/>. 171 4.3 Utiliser le constructeur web d'images live 172 En tant que service à la communauté, nous gérons un service de construction d'images web sur <http://live-systems.org/build/>. Ce site est maintenu sur la base du meilleur effort. Autrement dit, même si nous nous efforçons de le maintenir à jour et opérationnel à tout moment, et de publier des avis d'importantes interruptions du service, nous ne pouvons pas garantir une disponibilité de 100% ou des constructions d'images rapides, et le service peut parfois avoir des problèmes dont la résolution prend un certain temps. Si vous avez des problèmes ou des questions au sujet du service, veuillez nous contacter en donnant le lien vers votre construction. 173 4.3.1 Utilisation du constructeur web et avertissements 174 L'interface web ne permet actuellement pas d'empêcher l'utilisation de combinaisons d'options invalides, en particulier quand le changement d'une option (c'est-à-dire en utilisant live-build directement) modifie les valeurs des autres options é numérées dans le formulaire web, le constructeur web ne modifie pas ces valeurs par défaut. Plus particulièrement, si vous changez la valeur --architectures qui est par défaut i386 pour amd64, vous devez modifier l'option correspondante --linux-flavours de la valeur par défaut 586 pour amd64. Voir la page de manuel lb_config pour la version de live-build installée sur le constructeur web pour plus de détails. Le numéro de version de live-build est indiqué au bas de la page web. 175 L'estimation du temps donné par le constructeur web est une estimation brute et peut ne pas refléter la durée effective de votre construction. Cette estimation n'est pas actualisée une fois qu'elle est affichée. Soyez patient. Ne rechargez pas la page de la construction, car cela peut soumettre une nouvelle construction avec les mêmes paramètres. Vous devez nous contacter si vous ne recevez pas la notification de votre construction mais seulement une fois que vous ê tes sür que vous avez attendu assez longtemps et vérifié que la notification par e-mail n'a pas é té détectée par votre filtre anti-spam. 176 Le constructeur web est limité dans les types d'images qu'il peut construire. Cela permet de garder les choses simples et efficaces à utiliser et à maintenir. Si vous souhaitez effectuer des personnalisations qui ne sont pas prévues par l'interface web, le reste de ce manuel explique comment construire vos propres images en utilisant live-build. 177 4.4 Premières é tapes: la construction d'une image ISO hybride 178 Quel que soit le type d'image, vous devrez effectuer les mêmes é tapes de base pour créer une image à chaque fois. Comme premier exemple, créez un répertoire de travail, passez dans ce répertoire et exécutez la séquence suivante de commandes live-build pour créer une image ISO hybride de base contenant tout le système Debian par défaut sans X.org. Elle est appropriée pour ê tre gravée sur CD ou DVD, et peut é galement ê tre copiée sur une clé USB. 179 Le nom du répertoire de travail dépend totalement de vous, mais si vous jetez un œil aux exemples utilisés dans live-manual, c'est une bonne idée d'utiliser un nom qui vous aide à identifier l'image avec laquelle vous travaillez dans chaque répertoire, surtout si vous travaillez ou expérimentez avec différents types d'images. Dans ce cas, vous allez construire un système par défaut, nous allons donc l'appeler, par exemple, live-default. 180 181 $ mkdir live-default &&amp; cd live-default
Ensuite, exécutez la commande lb config. Cela va créer une hiérarchie "config/" dans le répertoire courant pour ê tre utilisée par d'autres commandes: 182 183 $ lb config
Aucun paramètre n'est passé à ces commandes, donc les défauts seront utilisés pour l'ensemble de ses diverses options. Consultez La commande lb config pour plus de détails. 184 Maintenant que la hiérarchie "config/" existe, créez l'image avec la commande lb build : 185 186 # lb build
Ce processus peut prendre un certain temps, en fonction de la vitesse de votre ordinateur et de votre connexion réseau. Une fois le processus terminé, il devrait y avoir un fichier image live-image-i386.hybrid.iso prêt à l'emploi, dans le répertoire courant. 187 Remarque: Si vous construisez sur un système amd64 le nom de l'image résultante sera live-image-amd64.hybrid.iso. Gardez à l'esprit cette convention de nommage tout au long du manuel. 188 4.5 Utilisation d'une image ISO hybride live 189 Après la construction ou le téléchargement d'une image ISO hybride, qui peut ê tre obtenue sur <https://www.debian.org/CD/live/>, l'étape suivante est d'habitude de préparer votre support pour le démarrage, soit sur CD-R(W) ou DVD-R(W), des supports optiques ou une clé USB. 190 4.5.1 Graver une image ISO sur un support physique 191 Graver une image ISO est facile. Il suffit d'installer /{xorriso} et de l'utiliser à partir de la ligne de commande pour graver l'image. Par exemple: 192 193 # apt-get install xorriso
   $ xorriso -as cdrecord -v dev=/dev/sr0 blank=as_needed live-image-i386.hybrid.iso
4.5.2 Copie d'une image ISO hybride sur une clé USB 194 Les images ISO préparées avec xorriso peuvent ê tre simplement copiées sur une clé USB avec cp ou un logiciel é quivalent. Branchez une clé USB avec une capacité suffisamment grande pour votre fichier image et déterminez quel périphérique elle est, que nous appelons ci-dessous ${USBSTICK}. C'est le fichier de périphérique de votre clé, tel que /dev/sdb, pas une partition, telle que /dev/sdb1! Vous pouvez trouver le nom du périphérique en regardant la sortie de dmesg après avoir branché le périphérique, ou mieux encore, ls -l /dev/disk/by-id. 195 Une fois que vous ê tes sür d'avoir le nom correct de l'appareil, utilisez la commande cp pour copier l'image sur la clé. Ceci é crasera tout fichier déjà existant sur votre clé! 196 197 $ cp live-image-i386.hybrid.iso ${USBSTICK}
   $ sync
Remarque: La commande sync est utilisée pour s'assurer que toutes les données qui sont stockées dans la mémoire par le noyau lors de la copie de l'image, sont é crites sur la clé USB. 198 4.5.3 Utilisation de l'espace disponible sur une clé USB 199 Après avoir copié live-image-i386.hybrid.iso sur une clé USB, la première partition sera utilisée par le système live. Pour utiliser l'espace libre restant, utilisez un outil de partitionnement tel que gparted ou parted afin de créer une nouvelle partition sur la clé. 200 201 # gparted ${USBSTICK}
Quand la partition est cré&#233;e, vous devez y créer un système de fichiers oú ${PARTITION} est le nom de la partition, comme /dev/sdb2. Un choix possible serait ext4. 202 203 # mkfs.ext4 ${PARTITION}
Remarque: Si vous voulez utiliser l'espace supplémentaire avec Windows, ce système d'exploitation ne peut accéder normalement à aucune partition à part la première. Certaines solutions à ce problème ont é té discutées sur notre liste de diffusion, mais il semble qu'il n'y a pas de réponse facile. 204 Rappelez-vous: Chaque fois que vous installez une nouvelle live-image-i386.hybrid.iso sur la clé, toutes les données sur la clé seront perdues parce que la table de partition est é crasée par le contenu de l'image, vous devez sauvegarder votre partition supplémentaire d'abord pour la restaurer à nouveau après la mise à jour de l'image live. 205 4.5.4 Démarrer le support live 206 La première fois que vous démarrez votre support live, qu'il s'agisse de CD, DVD, clé USB, ou du démarrage par PXE, une certaine configuration dans le BIOS de votre ordinateur peut ê tre d'abord nécessaire. Puisque les BIOS varient grandement en fonctionnalités et raccourcis clavier, on ne peut pas aborder le sujet en profondeur ici. Certains BIOS fournissent une touche pour ouvrir un menu d'amorçage au démarrage, qui est le moyen le plus facile si elle est disponible sur votre système. Sinon, vous avez besoin d'entrer dans le menu de configuration du BIOS et modifier l'ordre de démarrage pour placer le dispositif de démarrage pour le système live devant votre périphérique de démarrage normal. 207 Une fois que vous avez démarré le support, un menu de démarrage vous est présenté. Si vous appuyez simplement sur entrée ici, le système va démarrer en utilisant l'entrée par défaut, Live. Pour plus d'informations sur les options de démarrage, consultez l'entrée « Help» dans le menu et aussi les pages de manuel de live-boot et live-config dans le système live. 208 En supposant que vous ayez sélectionné Live et démarré une image de bureau live par défaut, après que les messages de démarrage aient défilé, vous devriez ê tre automatiquement connecté au compte user et voir un bureau, prêt à l'emploi. Si vous avez démarré une image de la console uniquement, tel que le type standard des images précompilées, vous devriez ê tre automatiquement connecté à la console pour le compte user et voir une invite du shell, prête à l'emploi. 209 4.6 Utiliser une machine virtuelle pour les tests 210 Exécuter les images live dans une machine virtuelle (VM) peut faire gagner beaucoup de temps. Cela ne vient pas sans avertissements: 211 L'exécution d'une VM demande assez de RAM pour le système d'exploitation client et l'hôte et un CPU avec support matériel pour la virtualisation est recommandé. 212 Il y a quelques limitations inhérentes à l'exécution sur une VM, par exemple des performances vidéo médiocres, ou un choix limité de matériel é mulé. 213 Lors du développement d'un matériel spécifique, il n'existe aucun substitut pour l'exécution que le matériel lui-même. 214 Certains ne deviennent visibles que pendant l'exécution dans une VM. En cas de doute, testez votre image directement sur le matériel. 215 À condition de pouvoir travailler avec ces contraintes, examinez les logiciels VM disponibles et choisissez celui qui convient à vos besoins. 216 4.6.1 Test d'une image ISO avec QEMU 217 La VM la plus polyvalente de Debian est QEMU. Si votre processeur dispose d'une gestion matérielle de la virtualisation, vous pouvez utiliser le paquet qemu-kvm; La description du paquet qemu-kvm é numère brièvement les exigences. 218 Tout d'abord, installez qemu-kvm si votre processeur le gère. Sinon, installez qemu. Dans ce cas, le nom du programme est qemu au lieu de kvm dans les exemples suivants. Le paquet qemu-utils est é galement valable pour créer des images de disques virtuels avec qemu-img. 219 220 # apt-get install qemu-kvm qemu-utils
Démarrer une image ISO est simple: 221 222 $ kvm -cdrom live-image-i386.hybrid.iso
Voir les pages de manuel pour plus de détails. 223 4.6.2 Test d'une image ISO avec VirtualBox 224 Afin de tester l'ISO avec virtualbox: 225 226 # apt-get install virtualbox virtualbox-qt virtualbox-dkms
   $ virtualbox
Créez une nouvelle machine virtuelle, modifiez les paramètres de stockage pour utiliser live-image-i386.hybrid.iso comme le périphérique CD/DVD et démarrez la machine. 227 Remarque: Pour les systèmes live contenant X.org que vous voulez essayer avec virtualbox, vous pouvez inclure le paquet des pilotes VirtualBox X.org, virtualbox-guest-dkms et virtualbox-guest-x11, dans votre configuration de live-build. Sinon, la résolution est limitée à 800x600. 228 229 $ echo "virtualbox-guest-dkms virtualbox-guest-x11" > > config/package-lists/my.list.chroot
Pour faire fonctionner le paquet dmks, il faut é galement installer le paquet linux-headers pour le noyau utilisé dans l'image. Au lieu de lister manuellement le paquet linux-headers correct dans la liste de paquets crée ci-dessus, live-build peut faire cela automatiquement. 230 231  &#160;$ lb config --linux-packages "linux-image linux-headers"
4.7 Construire et utiliser une image HDD 232 La construction d'une image HDD est similaire à une ISO hybride à tous les regards, sauf que vous spécifiez -b hdd et le nom du fichier résultant est live-image-i386.img qui ne peut ê tre gravé sur des supports optiques. Il convient pour le démarrage à partir de clés USB, disques durs USB, et divers autres dispositifs de stockage portables. Normalement, une image ISO hybride peut ê tre utilisée à cette fin, mais si vous avez un BIOS qui ne gère pas correctement les images hybrides, vous devez utiliser une image HDD. 233 Remarque: si vous avez cré&#233; une image ISO hybride avec l'exemple précédent, vous devrez nettoyer votre répertoire de travail avec la commande lb clean (voir La commande lb clean): 234 235 # lb clean --binary
Exécutez la commande lb config comme avant, sauf que cette fois en spécifiant le type d'image HDD: 236 237 $ lb config -b hdd
Construisez maintenant l'image avec la commande lb build 238 239 # lb build
Quand la création de l'image est finie, un fichier live-image-i386.img doit ê tre présent dans le répertoire courant. 240 L'image binaire générée contient une partition VFAT et le chargeur d'amorçage syslinux, prêts à ê tre é crits directement sur une clé USB. Encore une fois, comme l'utilisation d'une image HDD est juste comme l'utilisation d'une image ISO hybride sur USB, suivez les instructions Utiliser une image live ISO hybride, en utilisant le nom de fichier live-image-i386.img au lieu de live-image-i386.hybrid.iso. 241 De même, pour tester une image HDD avec Qemu, installez qemu comme décrit ci-dessus dans Test d'une image ISO avec QEMU. Ensuite, exécutez kvm ou qemu, selon la version dont votre système hôte a besoin en précisant live-image-i386.img comme le premier disque dur. 242 243 $ kvm -hda live-image-i386.img
4.8 Construction d'une image netboot 244 La séquence de commandes suivante va créer une image NetBoot de base contenant le système Debian par défaut sans X.org. Elle peut ê tre démarrée sur le réseau. 245 Remarque: Si vous avez réalisé quelques-uns des exemples précédents, vous aurez besoin de nettoyer votre répertoire de travail avec la commande lb clean: 246 247 # lb clean
Dans ce cas spécifique, un lb clean --binary ne serait pas suffisant pour nettoyer les é tapes nécessaires. La raison est que dans les configurations de netboot, une configuration initramfs différente doit ê tre utilisée, laquelle live-build exécute automatiquement lors de la construction des images netboot. Puisque la création d'initramfs appartient à l'étape chroot, si on change à netboot dans un répertoire existant, il faut reconstruire le chroot. Par conséquent, il faut faire un lb clean, (qui permettra d'éliminer l'étape chroot, aussi). 248 Exécutez la commande suivante pour configurer votre image pour démarrer sur le réseau: 249 250 $ lb config -b netboot --net-root-path "/srv/debian-live" --net-root-server "192.168.0.2"
Contrairement aux images ISO et HDD, le démarrage sur le réseau ne sert pas l'image du système de fichiers pour le client. Pour cette raison, les fichiers doivent ê tre servis via NFS. Différents systèmes de fichiers réseau peuvent ê tre choisis avec lb config. Les options --net-root-path et --net-root-server indiquent l'emplacement et le serveur, respectivement, du serveur NFS sur lequel l'image du système de fichiers sera située au moment du démarrage. Assurez-vous que ceux-ci sont fixées à des valeurs appropriées pour votre réseau et serveur. 251 Construisez maintenant l'image avec la commande lb build 252 253 # lb build
Dans un démarrage réseau, le client exécute un petit morceau de logiciel qui réside habituellement sur l'EPROM de la carte Ethernet. Ce programme envoie une requête DHCP pour obtenir une adresse IP et les informations sur ce qu'il faut faire ensuite. Typiquement, la prochaine é tape est d'obtenir un chargeur d'amorçage de niveau supérieur via le protocole TFTP. Cela pourrait ê tre pxelinux, GRUB, ou démarrer directement à un système d'exploitation comme Linux. 254 Par exemple, si vous décompressez l'archive généré live-image-i386.netboot.tar dans le répertoire /srv/debian-live, vous trouverez l'image du système de fichiers dans live/filesystem.squashfs et le noyau, initrd et le chargeur d'amorçage pxelinux dans tftpboot/. 255 Nous devons maintenant configurer trois services sur le serveur pour activer le démarrage sur le réseau: le serveur DHCP, le serveur TFTP et le serveur NFS. 256 4.8.1 Serveur DHCP 257 Nous devons configurer le serveur DHCP de notre réseau pour ê tre sür de donner une adresse IP au client du système du démarrage sur le réseau, et pour annoncer l'emplacement du chargeur d'amorçage PXE. 258 Voici un exemple source d'inspiration, é crit pour le serveur ISC DHCP isc-dhcp-server dans le fichier de configuration /etc/dhcp/dhcpd.conf: 259 260 # /etc/dhcp/dhcpd.conf - configuration file for isc-dhcp-server
&lt;br />   ddns-update-style none;&lt;br />&lt;br />   option domain-name "example.org";&lt;br />   option domain-name-servers ns1.example.org, ns2.example.org;&lt;br />&lt;br />   default-lease-time 600;&lt;br />   max-lease-time 7200;&lt;br />&lt;br />   log-facility local7;&lt;br />&lt;br />   subnet 192.168.0.0 netmask 255.255.255.0 {
    &#160;&#160;range 192.168.0.1 192.168.0.254;&lt;br />    &#160;&#160;filename "pxelinux.0";&lt;br />    &#160;&#160;next-server 192.168.0.2;&lt;br />    &#160;&#160;option subnet-mask 255.255.255.0;&lt;br />    &#160;&#160;option broadcast-address 192.168.0.255;&lt;br />    &#160;&#160;option routers 192.168.0.1;&lt;br />   }
4.8.2 Serveur TFTP 261 Cela sert le noyau et le ramdisk initial pour le système pendant l'exécution. 262 Vous devriez installer le paquet tftpd-hpa. Il peut servir tous les fichiers contenus dans un répertoire racine, d'habitude /srv/tftp. Pour le laisser servir des fichiers dans /srv/debian-live/tftpboot, exécutez comme utilisateur root la commande suivante: 263 264 # dpkg-reconfigure -plow tftpd-hpa
et remplissez le nouveau répertoire du serveur tftp 265 4.8.3 Serveur NFS 266 Quand l'ordinateur hôte a téléchargé et démarré un noyau Linux et chargé son initrd, il va essayer de monter l'image du système de fichiers live via un serveur NFS. 267 Vous devez installer le paquet nfs-kernel-server. 268 Ensuite, rendez l'image du système de fichiers disponible via NFS en ajoutant une ligne comme la suivante /etc/exports: 269 270 /srv/debian-live *(ro,async,no_root_squash,no_subtree_check)
et indiquez cette exportation au serveur NFS avec la commande suivante: 271 272 # exportfs -rv
La configuation de ces trois services peut ê tre un peu dificile. Vous pourriez avoir besoin de patience pour obtenir que tous fonctionnent ensemble. Pour plus d'informations, consultez le wiki syslinux sur <http://www.syslinux.org/wiki/index.php/PXELINUX> ou la section Debian Installer Manual's TFTP Net Booting sur <http://d-i.alioth.debian.org/manual/fr.i386/ch04s05.html>. Ils pourraient aider parce que leurs processus sont très semblables. 273 4.8.4 Guide pratique pour expérimenter avec une image Netboot 274 La création d'images netboot est facile avec live-build, mais les tests des images sur des machines physiques peuvent prendre vraiment beaucoup de temps. 275 Afin de rendre notre vie plus facile, nous pouvons utiliser la virtualisation. 276 4.8.5 Qemu 277 Installer qemu, bridge-utils, sudo. 278 É diter /etc/qemu-ifup: 279 280 #!/bin/sh
   sudo -p "Password for $0:" /sbin/ifconfig $1 172.20.0.1
   echo "Executing /etc/qemu-ifup"
   echo "Bringing up $1 for bridged mode..."
   sudo /sbin/ifconfig $1 0.0.0.0 promisc up
   echo "Adding $1 to br0..."
   sudo /usr/sbin/brctl addif br0 $1
   sleep 2
Obtenir, ou construire un grub-floppy-netboot. 281 Lancer qemu avec "-net nic,vlan=0 -net tap,vlan=0,ifname=tun0" 282 4.9 Webbooting 283 Webbooting est une manière très pratique de télécharger et d'amorcer les systèmes live en utilisant l'Internet comme un moyen. Il ya très peu d'exigences pour webbooting. D'une part, vous avez besoin d'un support avec un chargeur d'amorçage, un disque ram initial et un noyau. D'autre part, un serveur web pour stocker les fichiers squashfs qui contiennent le système de fichiers. 284 4.9.1 Obtenir les fichiers webboot 285 Comme d'habitude, vous pouvez construire les images vous-même ou utiliser les fichiers précompilés, qui sont disponibles sur le site du projet sur <http://live-systems.org/>. L'utilisation des images précompilées serait pratique pour faire l'essai initial jusqu'à ce que l'on peut affiner leurs propres besoins. Si vous avez construit une image live, vous trouverez les fichiers nécessaires pour webbooting dans le répertoire de construction sous binary/live/. Les fichiers sont appelés vmlinuz, initrd.img et filesystem.squashfs. 286 Il est é galement possible d'extraire les fichiers d'une image iso déjà existant. Pour ce faire, on doit monter l'image comme suit: 287 288 # mount -o loop image.iso /mnt
Les fichiers se trouvent sous le répertoire live/. Dans ce cas précis, il serait /mnt/live/. Cette méthode présente l'inconvénient que vous avez besoin d'être root pour pouvoir monter l'image. Cependant, il présente l'avantage qu'elle est facilement scriptable et ainsi, facilement automatisée. 289 Mais sans aucun doute, la meilleure façon d'extraire les fichiers d'une image iso et les télécharger sur le serveur web au même temps, est d'utiliser le midnight commander ou mc. Si vous avez le paquet genisoimage installé, le gestionnaire de fichiers à deux panneaux vous permet de voir le contenu d'un fichier iso dans un panneau et de télécharger les fichiers via FTP dans l'autre panneau. Même si cette méthode nécessite un travail manuel, elle ne nécessite pas les privilèges root. 290 4.9.2 Démarrer images webboot 291 Tandis que certains utilisateurs vont utiliser la virtualisation pour tester le webbooting, nous utilisons du matériel réel ici pour correspondre au possible cas d'utilisation suivant qui seulement devrait ê tre considéré comme un exemple. 292 Afin de démarrer une image webboot il suffit d'avoir les é léments mentionnés ci-dessus, c'est-à-dire, vmlinuz et initrd.img sur une clé usb dans un répertoire nommé live/ et installer syslinux comme chargeur de démarrage. Ensuite, démarrer à partir de la clé usb et taper fetch=URL/CHEMIN/DU/FICHIER aux options de démarrage. live-boot va télécharger le fichier squashfs et le stocker dans la ram. De cette façon, il est possible d'utiliser le système de fichiers compressé téléchargé comme un système live normal. Par exemple: 293 294 append boot=live components fetch=http://192.168.2.50/images/webboot/filesystem.squashfs
Cas d'utilisation: Vous avez un serveur web dans lequel vous avez stocké deux fichiers squashfs, un qui contient un bureau complet, comme par exemple gnome, et un d'un système standard. Si vous avez besoin d'un environnement graphique pour une machine, vous pouvez brancher votre clé usb et télécharger l'image qui contient gnome. Si vous avez besoin des outils inclus dans le deuxième type d'image, peut-être pour une autre machine, vous pouvez télécharger celle du système standard. 295 Aperçu des outils 296 5. Aperçu des outils 297 Ce chapitre fournit un aperçu des trois principaux outils utilisés dans la construction des systèmes live: live-build, live-boot et live-config. 298 5.1 Le paquet live-build 299 live-build est une collection de scripts pour construire des systèmes live. Ces scripts sont aussi appelés "commandes". 300 L'idée derrière live-build est de constituer un cadre qui utilise un répertoire de configuration pour automatiser et personnaliser complètement tous les aspects de la construction d'une image Live. 301 Plusieurs concepts sont similaires à ceux utilisés pour construire des paquets Debian avec debhelper: 302 Les scripts ont un emplacement central pour la configuration de leur fonctionnement. Avec debhelper, c'est le sous-répertoire debian/ d'un arbre de paquets. Par exemple, dh_install cherchera, entre autres, un fichier appelé debian/install pour déterminer quels fichiers doivent exister dans un paquet binaire particulier. De la même manière, live-build enregistre sa configuration entièrement dans un sous-répertoire config/. 303 Les scripts sont indépendants, c'est-à-dire qu'il est toujours sür d'exécuter chaque commande. 304 Contrairement à debhelper, live-build contient des outils pour générer une arborescence de configuration. Cela pourrait ê tre considéré comme similaire à des outils tels que dh-make. Pour plus d'informations sur ces outils, continuer la lecture, parce que le reste de cette section est sur les quatre commandes les plus importantes. Notez que la commande lb est une function générique pour les commandes live-build. 305 lb config: Responsable de l'initialisation d'un répertoire de configuration pour un système Live. Voir La commande lb config pour plus d'informations. 306 lb build: Responsable du démarrage d'un système de construction Live. Voir La commande lb build pour plus d'informations. 307 lb clean: Responsable de la suppression des parties d'un système de construction Live. Voir La commande lb clean pour plus d'informations. 308 5.1.1 La commande lb config 309 Comme indiqué dans live-build, les scripts qui composent live-build lisent leur configuration avec la commande source à partir d'un seul répertoire nommé config/. Comme la construction de ce répertoire à la main serait fastidieuse et source d'erreurs, la commande lb config peut ê tre utilisée pour créer une arborescence de configuration. 310 Exécuter la commande lb config sans aucun argument crée le sous-répertoire config/ qui est peuplée avec certains paramètres dans fichiers de configuration, et deux sous-répertoires auto/ et local/ avec une arborescence de fichiers. 311 312 $ lb config
   [2015-01-06 19:25:58] lb config
   P: Creating config tree for a debian/stretch/i386 system
   P: Symlinking hooks...
L'utilisation de lb config sans aucun argument serait appropriée pour les utilisateurs qui ont besoin d'une image de base, ou qui ont l'intention de fournir plus tard une configuration plus complète via auto/config (voir Gestion d'une configuration pour plus de détails). 313 Normalement, vous voulez indiquer certaines options. Par exemple, pour spécifier le gestionnaire de paquets à utiliser lors de la construction de l'image: 314 315 $ lb config --apt aptitude
Il est possible d'indiquer plusieurs options, telles que: 316 317 $ lb config --binary-images netboot --bootappend-live "boot=live components hostname=live-host username=live-user" ...
Une liste complète des options est disponible dans la page de manuel de lb_config. 318 5.1.2 La commande lb build 319 La commande lb build lit dans votre configuration à partir du répertoire config/. Elle exécute alors les commandes de niveau inférieur nécessaires à la construction de votre système Live. 320 5.1.3 La commande lb clean 321 Le rôle de la commande lb clean est d'enlever les différentes parties d'une construction afin que autres compilations ultérieures puissent commencer à partir d'un é tat propre. Par défaut, les é tapes chroot, binary et source sont nettoyées, mais le cache est laissé intact. En outre, les é tapes peuvent ê tre nettoyées individuellement. Par exemple, si vous avez effectué des changements qui affectent uniquement la phase binaire, utilisez lb clean --binary avant de construire un nouveau binaire. Si vos modifications invalident le bootstrap et/ou les caches de paquets, par exemple, modifications aux options --mode, --architecture ou --bootstrap, vous devez utiliser lb clean --purge. Voir la page de manuel de lb_clean pour une liste complète des options. 322 5.2 Le paquet live-boot 323 live-boot est une collection de scripts fournissant des hooks pour initramfs-tools. Il est utilisé pour générer un initramfs capable de démarrer des systèmes live, comme ceux cré&#233;s par live-build. Cela inclut ISOs, netboot tarballs, et les images pour clés USB. 324 Au démarrage, il va chercher un support en lecture seule qui contient un répertoire /live/ oú un système de fichiers racine (souvent une image du système de fichiers compressée comme squashfs) est stocké. S'il le trouve, il va créer un environnement accessible en é criture, en utilisant aufs, afin que les systèmes similaires à Debian puissent démarrer à partir de cet environnement. 325 Plus d'information sur initial ramfs dans Debian peut ê tre trouvée dans le Debian Linux Kernel Handbook sur <http://kernel-handbook.alioth.debian.org/> dans le chapitre sur initramfs. 326 5.3 Le paquet live-config 327 live-config se compose des scripts qui s'exécutent au démarrage après live-boot pour configurer le système live automatiquement. Il gère les tâches telles que l'établissement du nom d'hôte, des paramètres régionaux et du fuseau horaire, la création de l'utilisateur live, l'inhibition des cron jobs et l'autologin de l'utilisateur live. 328 Gestion d'une configuration 329 6. Gestion d'une configuration 330 Ce chapitre explique comment gérer une configuration d'un système live à partir d'une création initiale, à travers des révisions successives et des versions successives du logiciel live-build et de l'image live elle-même. 331 6.1 Gérer les modifications de la configuration 332 Les configurations live sont rarement parfaites du premier coup. Il peut ê tre bon de passer des options lb config à partir de la ligne de commande pour effectuer une construction unique, mais il est plus courant de réviser ces options et de construire à nouveau jusqu'à ce que vous soyez satisfait. Afin de prendre en charge ces changements, vous aurez besoin des scripts automatiques qui assurent le maintien de votre configuration dans un é tat cohérent. 333 6.1.1 Pourquoi utiliser des scripts auto? Que font-ils? 334 La commande lb config enregistre les options que vous lui passez avec les fichiers dans config/* avec beaucoup d'autres options aux valeurs par défaut. Si vous exécutez lb config à nouveau, il ne réinitialisera pas l'option qui a é té mise par défaut en fonction de vos options initiales. Ainsi, par exemple, si vous exécutez lb config à nouveau avec une nouvelle valeur pour --binary-images, toutes les options qui ont é té mises à leur valeur par défaut pour l'ancienne type d'image ne peuvent plus fonctionner avec la nouvelle option. Ces fichiers ne sont pas destinés à ê tre lus ou modifiés. Ils enregistrent des valeurs pour plus d'une centaine d'options, donc personne (y-compris vous) ne pourra voir dans ces options lesquelles vous avez réellement indiquées. Finalement, si vous lancez lb config, puis mettez live-build à niveau et que celui-ci renomme une option, config/* contiendra toujours des variables nommées en fonction de l'ancienne option et qui ne seront plus valides. 335 Pour toutes ces raisons, les scripts auto/* vous rendront la vie plus facile. Ils sont de simples emballages pour les commandes lb config, lb build et lb clean qui sont conçus pour vous aider à gérer votre configuration. Le script auto/config enregistre votre commande lb config avec toutes les options désirées, le script auto/clean supprime les fichiers contenant les valeurs des variables de configuration et le script auto/build crée un build.log de chaque construction. Et chaque fois que vous lancez la commande lb correspondante, ces fichiers sont exécutés automatiquement. En utilisant ces scripts, votre configuration est plus facile à lire et a une cohérence interne d'une révision à l'autre. En outre, il sera plus facile pour vous d'identifier et corriger les options qui doivent changer lorsque vous mettez à niveau live-build après avoir lu la documentation mise à jour. 336 6.1.2 Utiliser les scripts auto d'exemple 337 Pour votre commodité, live-build est fourni avec des scripts shell d'exemple, pour les copier et les modifier. Lancez une nouvelle configuration par défaut, puis copiez les exemples: 338 339 $ mkdir mylive &&amp; cd mylive &&amp; lb config
   $ mkdir auto
   $ cp /usr/share/doc/live-build/examples/auto/* auto/
Modifiez auto/config en ajoutant des options comme bon vous semble. Par exemple: 340 341 #!/bin/sh
   lb config noauto \
    &#160;&#160;&#160;&#160;--architectures i386 \
    &#160;&#160;&#160;&#160;--linux-flavours 686-pae \
    &#160;&#160;&#160;&#160;--binary-images hdd \
    &#160;&#160;&#160;&#160;--mirror-bootstrap http://ftp.ch.debian.org/debian/ \
    &#160;&#160;&#160;&#160;--mirror-binary http://ftp.ch.debian.org/debian/ \
    &#160;&#160;&#160;&#160;"${@}"
Maintenant, chaque fois que vous utilisez lb config, auto/config réinitialisera la configuration basée sur ces options. Lorsque vous souhaitez effectuer des modifications, modifiez les options dans ce fichier au lieu de les passer à lb config. Lorsque vous utilisez lb clean, auto/clean va nettoyer les fichiers ainsi que tous les autres produits de construction. Et enfin, lorsque vous utilisez lb build, un journal de la construction est é crit par auto/build dans build.log. 342 Remarque: Un paramètre spécial noauto est utilisé ici pour é liminer un autre appel à auto/config, é vitant ainsi une récursion infinie. Assurez-vous que vous ne l'avez pas accidentellement supprimé en modifiant le fichier. Aussi, prenez soin de vous assurer quand vous divisez la commande lb config sur plusieurs lignes pour une meilleure lisibilité, comme le montre l'exemple ci-dessus, que vous n'oubliez pas la barre oblique inverse (\) de sorte que chaque ligne continue à la suivante. 343 6.2 Cloner une configuration publiée via Git 344 Utilisez l'option lb config --config pour cloner un dépôt Git qui contient une configuration d'un système live. Si vous souhaitez baser votre configuration sur une autre maintenue par le Live Systems Project, allez voir le dépôt sur <http://live-systems.org/gitweb> avec le nom live-images sous le titre Packages. Ce dépôt contient les configurations pour les images précompilées 345 Par exemple, pour construire une image standard, utilisez le dépôt live-images comme suit: 346 347 $ mkdir live-images &&amp; cd live-images
   $ lb config --config git://live-systems.org/git/live-images.git
   $ cd images/standard
Modifiez auto/config et toutes les autres choses dont vous avez besoin dans l'arbre config en fonction de vos besoins. Par exemple, les images precompilées non officielles qui contiennent paquets non-free sont faites en ajoutant simplement --archive-areas "main contrib non-free". 348 Vous pouvez é ventuellement définir un raccourci dans votre configuration Git en ajoutant la ligne suivante à votre ${HOME}/.gitconfig: 349 350 [url "git://live-systems.org/git/"]
    &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;insteadOf = lso:
Cela vous permet d'utiliser lso: quand vous voulez indiquer l'adresse d'un dépôt live-systems.org. Si vous supprimez le suffixe optionnel .git, commencer une nouvelle image en utilisant cette configuration est aussi simple que: 351 352 $ lb config --config lso:live-images
Le clonage de la totalité du dépôt live-images copie les configurations utilisées pour plusieurs images. Si vous voulez construire une image différente lorsque vous avez terminé avec la première, changez de répertoire et, é ventuellement, faites les modifications dont vous avez besoin. 353 Dans tous les cas, n'oubliez pas qu'il faut à chaque fois construire l'image en tant que superutilisateur: lb build 354 Personnalisation des contenus 355 7. Vue d'ensemble de la personnalisation 356 Ce chapitre donne un aperçu des diverses façons dont vous pouvez personnaliser un système live. 357 7.1 Configuration pendant la construction vs. l'amorçage 358 Les options de configuration d'un système live sont divisées en options au moment de la construction, ces options sont appliquées pendant la création et des options au moment du démarrage, qui sont appliquées pendant le démarrage. Les options au moment du démarrage sont divisées en celles qui surviennent au début, appliquées par le paquet live-boot, et celles qui arrivent plus tard, appliquées par live-config. Toute option d'amorçage peut ê tre modifiée par l'utilisateur en l'indiquant à l'invite de démarrage. L'image peut é galement ê tre construite avec les paramètres de démarrage par défaut et alors les utilisateurs peuvent normalement démarrer directement le système live sans indiquer aucune option lorsque toutes les valeurs par défaut sont appropriées. En particulier, l'argument lb --bootappend-live se compose de toutes les options de ligne de commande du noyau par défaut pour le système live, comme la persistance, les claviers, ou le fuseau horaire. Voir Personnalisation des paramètres régionaux et la langue, par exemple. 359 Les options de configuration pendant la construction sont décrites dans la page de manuel pour lb config. Les options de configuration pendant l'amorçage sont décrites dans les pages de manuel pour live-boot et live-config. Bien que les paquets live-boot et live-config soient installés dans le système live que vous construisez, il est recommandé que vous les installiez é galement sur votre système de construction pour vous y référer facilement lorsque vous travaillez sur votre configuration. Cela peut ê tre fait sans danger car aucun des scripts contenus ne sont exécutés à moins que le système soit configuré comme un système live. 360 7.2 É tapes de la construction 361 Le processus de construction est divisé en é tapes, avec des personnalisations différentes appliquées dans l'ordre dans chaque é tape. La première é tape à exécuter est l'étape bootstrap. C'est la phase initiale de peuplement du répertoire chroot avec des paquets pour faire un système Debian de base. Elle est suivie par l'étape chroot, qui complète la construction du répertoire chroot, le peuplant de tous les paquets listés dans la configuration, ainsi que tout autre matériel. La plupart de la personnalisation du contenu se produit à ce stade. La dernière é tape de la préparation de l'image live est l'étape binary, qui construit une image amorçable, en utilisant le contenu du répertoire chroot pour construire le système de fichiers racine pour le système Live. Il comprend l'installateur et tout autre matériel supplémentaire sur le support cible en dehors du système de fichiers du système live. Quand l'image live est construite, s'il est activé, le tarball des sources est construit dans l'étape source. 362 À chacune de ces é tapes, les commandes sont appliquées dans un ordre particulier. Les commandes sont ordonnées de manière à assurer que les personnalisations puissent ê tre superposées de manière raisonnable. Par exemple, dans l'étape chroot, les préconfigurations sont appliqués avant que tous les paquets ne soient installés, les paquets sont installés avant que tous les fichiers locaux inclus ne soient copiés et les hooks sont exécutés plus tard, quand tous les matériaux sont en place. 363 7.3 Supplément lb config avec des fichiers 364 Bien que lb config crée une arborescence de configuration dans le répertoire config/, pour accomplir vos objectifs, vous pourriez avoir besoin de fournir des fichiers supplémentaires dans les sous-répertoires de config/. Selon l'endroit oú les fichiers sont stockés dans la configuration, ils peuvent ê tre copiés dans le système de fichiers du système live ou dans le système de fichiers de l'image binaire, ou peuvent fournir pendant la construction des configurations du système qui seraient lourdes à passer comme options de la ligne de commande. Vous pouvez inclure des choses telles que des listes personnalisées de paquets, art personnalisé, ou des scripts hook à exécuter, soit pendant la construction soit au démarrage, ce qui augmente la flexibilité déjà considérable de debian-live avec le code de votre choix. 365 7.4 Tâches de personnalisation 366 Les chapitres suivants sont organisés par les types des tâches de personnalisation que les utilisateurs effectuent généralement: Personnalisation de l'installation de paquets, Personnalisation des contenus et Personnalisation des paramètres régionaux et la langue couvrent quelques choses que vous pourriez vouloir faire. 367 Personnalisation de l'installation de paquets 368 8. Personnalisation de l'installation de paquets 369 La personnalisation la plus fondamentale d'un système live est sans doute la sélection des paquets à inclure dans l'image. Ce chapitre vous guide tout au long des différentes options de construction pour personnaliser l'installation des paquets avec live-build. Le plus large choix influençant les paquets disponibles pour l'installation dans l'image sont la distribution et les zones d'archive. Afin de vous assurer des vitesses de téléchargement décentes, vous devez choisir un miroir de distribution proche. Vous pouvez é galement ajouter vos propres dépôts pour les rétroportages, paquets expérimentaux ou personnalisés, ou inclure des paquets directement comme fichiers. Vous pouvez définir des listes de paquets, incluant des métapaquets qui installent en même temps de nombreux paquets liés, tels que les paquets pour ordinateurs de bureau ou une langue particulière. Enfin, un certain nombre d'options donne un certain contrôle sur apt, ou si vous préférez, aptitude, pendant la construction quand les paquets sont installés. Vous pouvez trouver cela très pratique si vous utilisez un proxy, si vous voulez désactiver l'installation des paquets recommandés pour é conomiser l'espace, ou avez besoin de contrôler quelles versions des paquets sont installées via APT pinning, pour ne nommer que quelques possibilités. 370 8.1 Sources des paquets 371 8.1.1 Distribution, zones d'archive et mode 372 La distribution que vous choisissez a le plus large impact sur les paquets qui sont disponibles pour l'inclusion dans votre image live. Indiquez le nom de code, qui est par défaut buster pour la version de live-build dans buster. Toute distribution actuelle dans l'archive peut ê tre indiquée par son nom de code ici. (Voir Termes pour plus de détails.) L'option --distribution influence non seulement la source des paquets dans l'archive, mais indique é galement à live-build comment construire chaque distribution prise en charge. Par exemple, pour construire sur unstable, sid, précisez: 373 374 $ lb config --distribution sid
Dans l'archive de distribution, les zones d'archive («archive areas») sont les principales divisions de l'archive. Dans Debian, ce sont main, contrib et non-free. Seule main contient des logiciels qui font partie de la distribution Debian, c'est donc la valeur par défaut. Une ou plusieurs valeurs peuvent ê tre indiquées, par exemple: 375 376 $ lb config --archive-areas "main contrib non-free"
La prise en charge d'experimental est disponible pour certains dérivés de Debian grâce à l'option --mode. L'option par défaut est debian mais seulement si vous construisez sur un système Debian ou un système inconnu. Si lb config est appelé sur un des dérivés pris en charge, il créera par défaut une image de ce dérivé. Si par exemple lb config est lancé en mode ubuntu, les noms de distribution et des zones d'archives pour ce dérivé spécifique seront gérés à la place de ceux de Debian. Le mode modifie é galement le comportement de live-build en fonction des dérivés. 377 Remarque: Les projets pour lesquels ces modes ont é té ajoutés sont chargés d'aider les utilisateurs de ces options. Le Live Systems Project, en retour, fournit un soutien de développement sur une base du meilleur effort seulement, en fonction des commentaires sur les projets dérivés que nous n'avons pas développés ou pris en charge nous-mêmes. 378 8.1.2 Miroirs de distribution 379 L'archive Debian est répliquée sur un grand réseau de miroirs autour du monde pour que les habitants de chaque région puissent choisir un miroir proche ayant la meilleure vitesse de téléchargement. Chacune des options --mirror-* régit quel miroir de distribution est utilisé dans les différentes é tapes de la construction. Rappelez-vous dans les Étapes de la construction que l'étape bootstrap a lieu quand le chroot est initialement peuplé par debootstrap avec un système minimal, et l'étape chroot a lieu quand le chroot utilisé pour construire le système de fichiers du système live est construit. Ainsi, les commutateurs des miroirs correspondants sont utilisés pour ces é tapes et plus tard, dans l'étape binary, les valeurs --mirror-binary et --mirror-binary-security sont utilisées, remplaçant tout miroir utilisé dans une é tape antérieure. 380 8.1.3 Miroirs de distribution utilisés lors de la construction 381 Pour définir les miroirs de distribution utilisés pendant la construction pour pointer vers un miroir local, il suffit de fixer --mirror-bootstrap et --mirror-chroot-security comme suit. 382 383 $ lb config --mirror-bootstrap http://localhost/debian/ \
    &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;--mirror-chroot-security http://localhost/debian-security/
Le miroir chroot, indiqué avec --mirror-chroot, est par défaut la valeur de --mirror-bootstrap. 384 8.1.4 Miroirs de distribution utilisés pendant l'exécution 385 Les options --mirror-binary* régissent les miroirs de distribution placés dans l'image binaire. Elles peuvent ê tre utilisées pour installer des paquets supplémentaires lors de l'exécution du système live. Les valeurs par défaut emploient http.debian.net, un service qui choisit un miroir géographiquement proche basé, entre autres choses, sur la famille IP de l'utilisateur et la disponibilité des miroirs. C'est un choix approprié lorsque vous ne pouvez pas prédire quel miroir sera le meilleur pour tous vos utilisateurs. Autrement, vous pouvez indiquer vos propres valeurs, comme indiqué dans l'exemple ci-dessous. Une image construite avec cette configuration ne serait appropriée que pour les utilisateurs sur un réseau oú le "mirror" est accessible. 386 387 $ lb config --mirror-binary http://mirror/debian/ \
    &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;--mirror-binary-security http://mirror/debian-security/ \
    &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;--mirror-binary-backports http://mirror/debian-backports/
8.1.5 Dépôts additionnels 388 Vous pouvez ajouter d'autres dépôts, é largissant votre choix de paquets au-delà de ceux disponibles dans votre distribution cible. Cela peut ê tre, par exemple, pour avoir des paquets rétroportés, personnalisés ou expérimentaux. Pour configurer des dépôts supplémentaires, créez les fichiers config/archives/your-repository.list.chroot, et/ou config/archives/your-repository.list.binary. Comme avec les options --mirror-*, ces fichiers donnent les dépôts utilisés dans l'étape chroot lors de la construction de l'image, et dans l'étape binary, c'est-à-dire pendant l'exécution du système live. 389 Par exemple, config/archives/live.list.chroot vous permet d'installer les paquets du dépôt des instantanés debian live pendant la construction du système live. 390 391 deb http://live-systems.org/ sid-snapshots main contrib non-free
Si vous ajoutez la même ligne à config/archives/live.list.binary, le dépôt sera ajouté au répertoire /etc/apt/sources.list.d/ de votre système live. 392 Si ces fichiers existent, ils seront sélectionnés automatiquement. 393 Vous devriez é galement mettre la clé GPG utilisée pour signer le dépôt dans les fichiers config/archives/your-repository.key.{binary,chroot} 394 Si vous avez besoin d'un APT pinning personnalisé, les préférences APT peuvent ê tre placées dans les fichiers config/archives/your-repository.pref.{binary,chroot} et elles seront automatiquement ajoutées à votre système live dans le répertoire /etc/apt/preferences.d/. 395 8.2 Choisir les paquets à installer 396 Il y a un certain nombre de façons pour choisir quels paquets live-build s'installeront dans votre image, couvrant toute une variété de besoins. Vous pouvez tout simplement nommer les paquets individuels à installer dans une liste de paquets. Vous pouvez é galement choisir des métapaquets dans ces listes, ou les sélectionner en utilisant les champs de contrôle de fichiers des paquets. Enfin, vous pouvez placer des paquets dans votre arbre config/ qui est bien adapté aux essais de nouveaux paquets ou expérimentaux avant qu'ils ne soient disponibles sur un dépôt. 397 8.2.1 Listes de paquets 398 Les listes de paquets sont un excellent moyen d'exprimer quels paquets doivent ê tre installés. La syntaxe de la liste gère des sections conditionnelles, ce qui les rend faciles à construire et à adapter pour leur utilisation dans des configurations multiples. Les noms des paquets peuvent é galement ê tre injectés dans la liste en utilisant des assistants de shell pendant la construction. 399 Remarque: Le comportement de live-build pour indiquer un paquet qui n'existe pas est déterminé par votre choix de l'utilitaire APT. Consultez Choisir apt ou aptitude pour plus de détails. 400 8.2.2 Utilisation des métapaquets 401 La façon la plus simple de remplir votre liste de paquets consiste à utiliser un métapaquet de tâche maintenu par votre distribution. Par exemple: 402 403 $ lb config
   $ echo task-gnome-desktop > config/package-lists/desktop.list.chroot
Cela remplace l'ancienne méthode des listes prédéfinies gérée dans live-build 2.x. Contrairement aux listes prédéfinies, les métapaquets ne sont pas spécifiques au projet Live Systems. Au lieu de cela, ils sont maintenus par des groupes de travail spécialisés dans la distribution et reflètent donc le consensus de chaque groupe sur les paquets pour mieux servir les besoins des utilisateurs. Ils couvrent é galement une gamme beaucoup plus large des cas d'utilisation que les listes prédéfinies qu'ils remplacent. 404 Tous les métapaquets de tâches sont préfixés avec task-, donc un moyen rapide pour déterminer lesquels sont disponibles (même s'il peut y avoir une poignée de faux positifs dont le nom correspond mais qui ne sont pas des métapaquets) est de faire correspondre le nom du paquet avec: 405 406 $ apt-cache search --names-only ^task-
En plus, vous trouverez d'autres métapaquets à des fins diverses. Certains sont des sous-ensembles de paquets de tâches plus larges, comme gnome-core, tandis que d'autres sont des pièces individuelles spécialisées d'un Debian Pure Blend, comme les métapaquets education-*. Pour lister tous les métapaquets dans l'archive, installez le paquet debtags et listez tous les paquets ayant l'étiquette role::metapackage comme suit: 407 408 $ debtags search role::metapackage
8.2.3 Listes de paquets locaux 409 Que vous listiez des métapaquets, des paquets individuels ou une combinaison des deux, toutes les listes de paquets locaux sont stockées dans config/package-lists/. Comme plus d'une liste peut ê tre utilisée, cela se prête bien à une conception modulaire. Par exemple, vous pouvez décider de consacrer une liste à un choix particulier de bureau, l'autre à une collection de paquets connexes qui pourraient aussi bien ê tre utilisés au-dessus d'un bureau différent. Cela vous permet d'expérimenter avec différentes combinaisons d'ensembles de paquets avec un minimum de tracas en utilisant des listes communes entre les différents projets d'images live. 410 Les listes de paquets qui existent dans ce répertoire ont besoin d'avoir un suffixe .list pour ê tre traitées, puis un suffixe d'étape supplémentaire .chroot ou .binary pour indiquer à quelle é tape la liste est destinée. 411 Remarque: Si vous n'indiquez pas le suffixe de l'étape, la liste sera utilisée pour les deux é tapes. Normalement, vous voulez indiquer .list.chroot de sorte que les paquets soient seulement installés dans le système de fichiers live et ne pas avoir une copie supplémentaire des .deb placée sur le support. 412 8.2.4 Listes de paquets locaux pour l'étape binary 413 Pour faire une liste pour l'étape binary, placez un fichier avec le suffixe .list.binary dans config/package-lists/. Ces paquets ne sont pas installés dans le système de fichiers live, mais sont inclus sur le support live sous pool/. Vous utiliserez généralement cette liste avec une des variantes d'installation non-live. Comme mentionné ci-dessus, si vous voulez que cette liste soit la même que votre liste pour l'étape chroot, utilisez simplement le suffixe .list. 414 8.2.5 Listes de paquets générées 415 Il arrive parfois que la meilleure façon de composer une liste soit de la générer avec un script. Toute ligne commençant par un point d'exclamation indique une commande à exécuter dans le chroot lorsque l'image est construite. Par exemple, on pourrait inclure la ligne ! grep-aptavail -n -sPackage -FPriority standard | sort dans une liste de paquets qui permet de produire une liste triée des paquets disponibles avec Priority: standard. 416 En fait, la sélection des paquets avec la commande grep-aptavail (du paquet dctrl-tools) est si utile que live-build fournit un script Packages à titre de commodité. Ce script accepte deux arguments: field et pattern. Ainsi, vous pouvez créer une liste avec le contenu suivant: 417 418 $ lb config
   $ echo '! Packages Priority standard' > config/package-lists/standard.list.chroot
8.2.6 Utiliser des conditions dans les listes de paquets 419 Toutes les variables de configuration de live-build stockées dans config/* (sans le préfixe LB_) peuvent ê tre utilisées dans des instructions conditionnelles dans les listes de paquets. Généralement, cela correspond à toute option lb config en majuscule et avec tirets changés en caractères de soulignement. Mais en pratique, ce ne sont que celles qui influencent la sélection des paquets qui font sens, comme DISTRIBUTION, ARCHITECTURES ou ARCHIVE_AREAS. 420 Par exemple, pour installer ia32-libs si --architectures amd64 est indiqué: 421 422 #if ARCHITECTURES amd64
   ia32-libs
   #endif
Vous pouvez tester pour un certain nombre de valeurs, par exemple pour installer memtest86+ si --architectures i386 ou --architectures amd64 est indiqué: 423 424 #if ARCHITECTURES i386 amd64
   memtest86+
   #endif
Vous pouvez é galement tester avec des variables pouvant contenir plus d'une valeur, par exemple pour installer vrms si contrib ou non-free est indiqué via --archive-areas: 425 426 #if ARCHIVE_AREAS contrib non-free
   vrms
   #endif
L'imbrication des conditions n'est pas prise en charge. 427 8.2.7 Suppression de paquets lors de l'installation 428 Il est possible de lister des paquets dans des fichiers utilisant les extensions .list.chroot_live et .list.chroot_install à l'intérieur du répertoire config/package-lists. Si une liste « install» et une liste « live» existent conjointement, les paquets dans la liste .list.chroot_live seront supprimés par un hook après l'installation (si l'utilisateur utilise l'installeur). Les paquets dans la liste .list.chroot_install sont présents à la fois dans le système live et dans le système installé. Il s'agit d'un paramétrage spécial pour l'installeur et peut se révéler utile si vous avez choisi --debian-installer live dans votre configuration, et souhaitez supprimer des paquets spécifiques aux systèmes live lors de l'installation. 429 8.2.8 Tâches de bureau et de langue 430 Les tâches de bureau et de langue sont des cas particuliers qui ont besoin d'une certaine planification et de configuration supplémentaire. Dans l'installateur Debian, si le support a é té préparé pour un environnement de bureau particulier, la tâche correspondante sera automatiquement installée. Ainsi, il y a tâches internes gnome-desktop, kde-desktop, lxde-desktop et xfce-desktop, dont aucune n'est proposée dans le menu tasksel. De même, il n'y a pas d'élément de menu pour les tâches de langue, mais le choix de la langue de l'utilisateur lors de l'installation influence le choix des tâches de langue correspondantes. 431 Lors du développement d'une image de bureau live, l'image s'amorce généralement directement sur un bureau de travail. Les choix de l'environnement de bureau et la langue par défaut ont é té faits pendant la construction et non pas pendant l'exécution comme dans le cas de l'installateur de Debian. Cela ne veut pas dire qu'une image live ne pourrait pas ê tre construite pour prendre en charge plusieurs environnements de bureau ou plusieurs langues et offrir à l'utilisateur un choix, mais ce n'est pas le comportement par défaut de live-build. 432 Comme aucune disposition n'est faite automatiquement pour les tâches de la langue, qui comprennent des é léments tels que des polices spécifiques à la langue et des paquets de méthodes de saisie, vous devez les indiquer dans votre configuration si vous les voulez. Par exemple, une image de bureau GNOME contenant la prise en charge de l'allemand pourrait inclure les métapaquets de tâches suivants: 433 434 $ lb config
   $ echo "task-gnome-desktop task-laptop" > > config/package-lists/my.list.chroot
   $ echo "task-german task-german-desktop task-german-gnome-desktop" > > config/package-lists/my.list.chroot
8.2.9 Version et type de noyau 435 Un ou plusieurs types de noyau seront inclus dans votre image par défaut, en fonction de l'architecture. Vous pouvez choisir différents types avec l'option --linux-flavours. Chaque type est suffixé à partir de linux-image pour former le nom de chaque métapaquet qui dépend à son tour d'un paquet noyau exact à inclure dans votre image. 436 Ainsi, par défaut, une image pour l'architecture amd64 comprendra le métapaquet linux-image-amd64, et une image pour l'architecture i386 comprendra le métapaquet linux-image-586. 437 Lorsque plus d'une version du paquet du noyau est disponible dans vos archives configurées, vous pouvez indiquer un nom du paquet du noyau différent avec l'option --linux-packages. Par exemple, supposons que vous construisiez une image pour l'architecture amd64 et ajoutiez l'archive expérimentale pour faire des essais. Pour installer le noyau linux-image-3.18.0-trunk-amd64 vous pouvez configurer cette image comme suit: 438 439 $ lb config --linux-packages linux-image-3.18.0-trunk
   $ echo "deb http://ftp.debian.org/debian/ experimental main" > config/archives/experimental.list.chroot
8.2.10 Noyaux personnalisés 440 Vous pouvez créer et inclure vos propres noyaux personnalisés, à condition qu'ils soient intégrés dans le système de gestion des paquets Debian. Le système de live-build ne gère pas les noyaux qui ne sont pas construits sous forme de paquets .deb. 441 La façon correcte et recommandée de déployer vos propres paquets du noyau est de suivre les instructions dans le kernel-handbook. N'oubliez pas de modifier l'ABI et les suffixes de manière appropriée, puis d'inclure une construction complète des paquets linux et linux-latest dans votre dépôt. 442 Si vous optez pour la construction des paquets du noyau sans les métapaquets correspondants, vous devez indiquer une chaîne --linux-packages appropriée tel que discuté dans Version et type de noyau. Comme nous l'expliquons dans Installation de paquets modifiés ou tiers, il est préférable que vous incluiez vos paquets de noyau personnalisés à votre propre dépôt, bien que les alternatives discutées dans cette section fonctionnent bien é galement. 443 Donner des conseils sur la façon de personnaliser votre noyau sort du cadre de ce document. Toutefois, vous devez au moins vous assurer que votre configuration répond à ces exigences minimales: 444 Utilisez un ramdisk initial. 445 Incluez un module d'union de systèmes de fichiers (par exemple aufs). 446 Incluez tous les autres modules du système de fichiers requis pour votre configuration (habituellement squashfs). 447 8.3 Installation de paquets modifiés ou tiers 448 Bien que ce soit contre la philosophie d'un système live, il peut parfois ê tre nécessaire de construire un système live avec des versions modifiées des paquets du dépôt Debian. Cela peut ê tre pour modifier ou prendre en charge des fonctionnalités supplémentaires, des langues et la marque, ou même pour supprimer des é léments indésirable dans les paquets existants.De même, les paquets « tiers» peuvent ê tre utilisés pour ajouter des fonctionnalités sur mesure et/ou propriétaires. 449 Cette section ne couvre pas les conseils concernant la construction ou la maintenance des paquets modifiés. La méthode de Joachim Breitner 'How to fork privately' <http://www.joachim-breitner.de/blog/archives/282-How-to-fork-privately.html> peut, cependant, vous intéresser. La création de paquets sur mesure est traitée dans le guide du nouveau mainteneur Debian à <https://www.debian.org/doc/maint-guide/> et ailleurs 450 Il y a deux façons d'installer des paquets personnalisés modifiés: 451 packages.chroot 452 Utiliser un dépôt APT personnalisé 453 Utiliser packages.chroot est plus simple à réaliser et utile pour les personnalisations ponctuelles mais a un certain nombre d'inconvénients, alors qu'utiliser un dépôt personnalisé APT est plus fastidieux à mettre en place. 454 8.3.1 Utiliser packages.chroot pour installer des paquets personnalisés 455 Pour installer un paquet personnalisé, il suffit de le copier dans le répertoire config/packages.chroot/. Les paquets qui sont dans ce répertoire seront automatiquement installés dans le système live pendant la construction du système - vous n'avez pas besoin de les indiquer ailleurs. 456 Les paquets doivent ê tre nommés de la manière prescrite. Une façon simple de le faire consiste à utiliser dpkg-name. 457 L'utilisation de packages.chroot pour l'installation de paquets personnalisés a des inconvénients: 458 Il n'est pas possible d'utiliser APT de façon sécurisée. 459 Vous devez installer tous les paquets appropriés dans le répertoire config/packages.chroot/. 460 Il ne se prête pas au stockage de configurations des systèmes live dans le contrôle de révision. 461 8.3.2 Utiliser un dépôt APT pour installer des paquets personnalisés. 462 Contrairement à l'utilisation de packages.chroot, lorsque vous utilisez un dépôt personnalisé APT, vous devez vous assurer que vous indiquez les paquets ailleurs. Voir Choisir les paquets à installer pour plus de détails. 463 S'il peut sembler inutile de créer un dépôt APT pour installer des paquets personnalisés, l'infrastructure peut ê tre facilement réutilisée à une date ultérieure pour offrir les mises à jour des paquets modifiés. 464 8.3.3 Les paquets personnalisés et APT 465 live-build utilise apt pour installer tous les paquets dans le système live, il héritera donc des comportements de ce logiciel. Un exemple pertinent est que (en supposant une configuration par défaut), s'il y a un paquet disponible dans deux dépôts différents avec des numéros de version différents, APT choisira d'installer le paquet ayant le numéro de version le plus grand. 466 Pour cette raison, vous pouvez incrémenter le numéro de version dans les fichiers debian/changelog de vos paquets personnalisés pour vous assurer que votre version modifiée sera installée au lieu d'une autre provenant des dépôts officiels Debian. Cela peut aussi ê tre afait en modifiant les préférences d'APT pinning dans le système live − voir APT pinning pour plus d'informations. 467 8.4 Configuration d'APT pendant la construction 468 Vous pouvez configurer APT par un certain nombre d'options appliquées uniquement pendant la construction. (La configuration d'APT utilisée dans le système live en fonctionnement peut ê tre configurée de façon normale pour un système live, c'est-à-dire en incluant les configurations appropriées dans config/includes.chroot/.) Pour une liste complète, regardez les options commençant par apt dans la page de manuel de lb_config. 469 8.4.1 Choisir apt ou aptitude 470 Vous pouvez choisir d'utiliser soit apt, soit aptitude. Le choix du logiciel utilisé dépend de l'argument --apt de lb config. Choisissez la méthode ayant le comportement que vous préférez pour l'installation de paquets, la différence notable é tant la manière dont les paquets manquants sont traités. 471 apt: Avec cette méthode, si un paquet manquant est indiqué, l'installation va é chouer. C'est le réglage par défaut. 472 aptitude: Avec cette méthode, si un paquet manquant est indiqué, l'installation va réussir. 473 8.4.2 Utilisation d'un proxy avec APT 474 Une configuration communément requise par APT est de gérer la construction d'une image derrière un proxy. Vous pouvez indiquer votre proxy APT avec les options --apt-ftp-proxy ou --apt-http-proxy si nécessaire, par exemple 475 476 $ lb config --apt-http-proxy http://proxy/
8.4.3 Régler APT pour é conomiser de l'espace 477 Vous pouvez avoir besoin d'économiser de l'espace sur le support d'image, auquel cas l'une ou l'autre ou les deux options suivantes peuvent ê tre d'intérêt. 478 Si vous ne voulez pas inclure les index d'APT dans l'image, vous pouvez les omettre avec: 479 480 $ lb config --apt-indices false
Cela n'influencera pas les entrées dans /etc/apt/sources.list, mais seulement le fait que /var/lib/apt contienne les fichiers index ou non. La contrepartie est qu'APT a besoin de ces index afin d'opérer dans le système live. Par conséquent, avant de procéder à apt-cache search ou apt-get install par exemple, l'utilisateur doit faire apt-get update pour créer ces index. 481 Si vous trouvez que l'installation des paquets recommandés fait trop gonfler votre image, à condition d'être prêt à faire face aux conséquences décrites ci-dessous, vous pouvez désactiver l'option par défaut d'APT avec: 482 483 $ lb config --apt-recommends false
La conséquence la plus importante de la désactivation des recommandations est que live-boot et live-config recommandent certains paquets qui fournissent des fonctionnalités importantes utilisées par la plupart de configurations live, telles que user-setup qui est recommandé par live-config qui est utilisé pour créer l'utilisateur live. Sauf exception, vous aurez besoin de rajouter au moins certaines de ces recommandationss à vos listes de paquets ou votre image ne fonctionnera pas comme prévu, si elle fonctionne. Regardez les paquets recommandés pour chacun des paquets live-* inclus dans votre construction et si vous n'êtes pas sür de pouvoir les omettre, ajoutez-les à nouveau dans vos listes de paquets. 484 La conséquence la plus générale est que si vous n'installez pas les paquets recommandés par un paquet, c'est-à-dire les « paquets qu'on trouverait avec celui-ci dans toute installation standard» (Debian Policy Manual, section 7.2), certains paquets dont vous avez vraiment besoin peuvent ê tre omis. Par conséquent, nous vous suggérons d'examiner la différence que la désactivation des recommandations induit sur votre liste de paquets (voir le fichier binary.packages généré par lb build) et incluez dans votre liste tous les paquets manquants que vous souhaitez toujours installer. Alternativement, si seulement un petit nombre de paquets que vous ne souhaitez pas est exclus, laissez les recommandations activées et définissez une priorité APT pin négative sur les paquets sélectionnés pour é viter les installer, comme expliqué dans APT pinning. 485 8.4.4 Passer des options à apt ou aptitude 486 S'il n'y a pas d'option lb config pour modifier le comportement d'APT de la façon dont vous avez besoin, utilisez --apt-options ou --aptitude-options pour passer des options par le biais de l'outil APT configuré. Consultez les pages de manuel apt et aptitude pour les détails. Notez que les deux options ont des valeurs par défaut que vous aurez besoin de conserver en plus des remplacements que vous pouvez fournir. Ainsi, par exemple, supposons que vous ayez inclus quelque chose de snapshot.debian.org à des fins de test et que vous vouliez indiquer Acquire::Check-Valid-Until=false pour satisfaire APT avec le fichier Release obsolète. Vous le feriez comme dans l'exemple suivant, avec l'ajout de la nouvelle option après la valeur par défaut --yes: 487 488 $ lb config --apt-options "--yes -oAcquire::Check-Valid-Until=false"
Veuillez lire attentivement les pages de manuel pour bien comprendre ces options et quand les utiliser. Ce n'est qu'un exemple et ne doit pas ê tre interprété comme un conseil pour configurer votre image de cette façon. Par exemple, cette option ne serait pas appropriée pour une version finale d'une image live. 489 Pour les configurations plus compliquées concernant des options apt.conf, vous pourriez vouloir créer un fichier config/apt/apt.conf. Consultez aussi les autres options apt-* pour obtenir quelques raccourcis pratiques pour les options fréquemment utilisées. 490 8.4.5 APT pinning 491 Pour plus de contexte, veuillez d'abord lire la page de manuel apt_preferences(5). APT pinning peut ê tre configuré soit pendant la construction, soit pendant l'exécution. Dans le premier cas, créez config/archives/*.pref, config/archives/*.pref.chroot, et config/apt/preferences. Dans le second cas, créez config/includes.chroot/etc/apt/preferences. 492 Imaginons que vous voulez construire un système live buster mais qu'il faut installer tous les paquets live qui finissent dans l'image binaire de sid pendant la construction. Vous devez ajouter sid à votre fichier APT sources et fixer tous les paquets live avec une priorité supérieure mais tous les autres paquets avec une priorité inférieure à la priorité par défaut de sorte que seuls les paquets que vous voulez soient installés à partir de sid pendant la construction et que tous les autres viennent de la distribution du système cible, buster. Ce qui suit devrait accomplir cela: 493 494 $ echo "deb http://mirror/debian/ sid main" > config/archives/sid.list.chroot
   $ cat > > config/archives/sid.pref.chroot < < EOF
   Package: live-*
   Pin: release n=sid
   Pin-Priority: 600
&lt;br />   Package: *
   Pin: release n=sid
   Pin-Priority: 1
   EOF
Une priorité pin négative é vitera installer un paquet, comme dans le cas oú vous ne voudriez pas un paquet qui est recommandé par un autre paquet. Supposons que vous construisiez une image LXDE en utilisant task-lxde-desktop dans config/package-lists/desktop.list.chroot mais que vous ne vouliez pas que l'utilisateur soit invité à stocker les mots de passe wifi dans le trousseau de clés. Cette liste comprend lxde-core, qui recommande gksu, qui à son tour recommande gnome-keyring. Donc, vous voulez omettre le paquet recommandé gnome-keyring. Cela peut ê tre fait en ajoutant ce qui suit à config/apt/preferences: 495 496 Package: gnome-keyring
   Pin: version *
   Pin-Priority: -1
Personnalisation des contenus 497 9. Personnalisation des contenus 498 Ce chapitre aborde la personnalisation fine des contenus du système live au-delà du simple choix des paquets à inclure. Les inclusions vous permettent d'ajouter ou de remplacer des fichiers arbitraires dans votre image du système live, les hooks vous permettent d'exécuter des commandes arbitraires dans différentes é tapes de la construction et au démarrage et la préconfiguration (preseeding) vous permet de configurer les paquets quand ils sont installés en fournissant des réponses aux questions debconf. 499 9.1 Includes 500 Bien qu'idéalement un système live comprendrait des fichiers entièrement fournis par des paquets non modifiés, il peut ê tre pratique de fournir ou de modifier certains contenus par le biais de fichiers. Avec les « includes», il est possible d'ajouter (ou remplacer) des fichiers arbitraires dans votre image du système live. live-build prévoit deux mécanismes pour leur utilisation: 501 Chroot local includes: Ils vous permettent d'ajouter ou remplacer des fichiers sur le système de fichiers chroot/Live. Veuillez consulter Live/chroot local includes pour plus d'informations. 502 Binary local includes: Ils vous permettent d'ajouter ou de remplacer des fichiers dans l'image binaire. Veuillez consulter Binary local includes pour plus d'informations. 503 Veuillez consulter les Termes pour plus d'informations sur la distinction entre les images "Live" et "binary". 504 9.1.1 Live/chroot local includes 505 Les chroot local includes peuvent ê tre utilisés pour ajouter ou remplacer des fichiers dans le système de fichiers chroot/Live afin qu'ils puissent ê tre utilisés dans le système Live. Une utilisation typique est de peupler l'arborescence du répertoire de l'utilisateur (/etc/skel) utilisée par le système live pour créer le répertoire home de l'utilisateur Live. Une autre est de fournir des fichiers de configuration qui peuvent ê tre simplement ajoutés ou remplacés à l'image sans traitement, voir Live/chroot local hooks si le traitement est nécessaire. 506 Pour inclure des fichiers, il suffit de les ajouter à votre répertoire config/includes.chroot. Ce répertoire correspond au répertoire racine / du système live. Par exemple, pour ajouter un fichier /var/www/index.html dans le système live, utilisez: 507 508 $ mkdir -p config/includes.chroot/var/www
   $ cp /path/to/my/index.html config/includes.chroot/var/www
Votre configuration aura alors le schéma suivant: 509 510 -- config
    &#160;&#160;&#160;[...]
    &#160;&#160;&#160;&#160;|-- includes.chroot
    &#160;&#160;&#160;&#160;| &#160;&#160;`-- var
    &#160;&#160;&#160;&#160;| &#160;&#160;&#160;&#160;&#160;&#160;`-- www
    &#160;&#160;&#160;&#160;| &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;`-- index.html
    &#160;&#160;&#160;[...]
Les chroot local includes sont installés après l'installation de paquets de sorte que les fichiers installés par les paquets sont remplacés. 511 9.1.2 Binary local includes 512 Pour inclure des matériels tels que des documents ou des vidéos sur le système de fichiers des supports, afin qu'ils soient accessibles dès l'insertion du support sans démarrer le système live, vous pouvez utiliser binary local includes. Cela fonctionne de façon similaire aux chroot local includes. Par exemple, supposons que les fichiers ~/video_demo.* sont des vidéos de démonstration du système live décrits par et liés par une page d'index HTML. Copiez simplement le matériel dans config/includes.binary/ comme suit: 513 514 $ cp ~/video_demo.* config/includes.binary/
Ces fichiers apparaissent maintenant dans le répertoire racine du support live. 515 9.2 Hooks 516 Les hooks permettent l'exécution des commandes dans les é tapes de la construction chroot et binary afin de personnaliser l'image. 517 9.2.1 Live/chroot local hooks 518 Pour exécuter des commandes à l'étape chroot, créer un script hook avec le suffixe .hook.chroot contenant les commandes dans le répertoire config/hooks/. Le hook s'exécutera dans le chroot après que le reste de votre configuration chroot ait é té appliqué, donc n'oubliez pas de vous assurer que votre configuration inclut tous les paquets et les fichiers dont votre hook a besoin pour fonctionner. Consultez les exemples de scripts chroot hook pour diverses tâches courantes de personnalisation chroot fournis dans /usr/share/doc/live-build/examples/hooks que vous pouvez copier ou faire un lien symbolique pour les utiliser dans votre propre configuration. 519 9.2.2 Hooks pendant le démarrage 520 Pour exécuter des commandes pendant le démarrage, vous pouvez fournir live-config hooks comme expliqué dans la section "Personnalisation" de sa page de manuel. Examinez les hooks de live-config fournis dans /lib/live/config/, en notant les numéros de séquence. Fournissez ensuite votre propre hook précédé d'un numéro de séquence appropriée, soit comme un chroot local include dans config/includes.chroot/lib/live/config/, soit comme un paquet personnalisé tel que discuté dans Installation des paquets modifiés ou de tiers. 521 9.2.3 Binary local hooks 522 Pour exécuter des commandes à l'étape binaire, créez un script hook avec le suffixe .hook.binary contenant les commandes dans le répertoire config/hooks/. Le hook sera exécuté après toutes les autres commandes binaires, mais avant binary_checksums, la dernière commande binaire. Les commandes de votre hook ne s'exécutent pas dans le chroot, afin de prendre soin de ne pas modifier les fichiers en dehors de l'arbre de construction, ou vous pourriez endommager votre système de construction! Consultez les exemples de scripts de binary hook pour diverses tâches courantes de personnalisation binaires fournis dans /usr/share/doc/live-build/examples/hooks que vous pouvez copier ou lier symboliquement pour les utiliser dans votre propre configuration. 523 9.3 Préconfigurer questions de debconf 524 Les fichiers dans le répertoire config/preseed/ avec le suffixe .cfg suivis de l'étape (.chroot or .binary) sont considérés comme des fichiers de préconfiguration debconf et sont installés par live-build en utilisant debconf-set-selections. 525 Pour plus d'informations sur debconf, veuillez consulter debconf(7) dans le paquet debconf. 526 Personnalisation des comportements pendant l'exécution 527 10. Personnalisation des comportements pendant l'exécution 528 Toute la configuration qui est faite pendant l'exécution est faite par live-config. Voici quelques options parmi les plus courantes de live-config qui peuvent intéresser les utilisateurs. Une liste complète de toutes les possibilités peut ê tre trouvée dans la page de manuel de live-config. 529 10.1 Personnalisation de l'utilisateur live 530 Une considération importante est que l'utilisateur live est cré&#233; par live-boot au démarrage, non pas par live-config pendant la construction. Cela influence non seulement l'emplacement oú les documents relatifs à l'utilisateur live sont introduits dans la construction, tel que discuté dans Live/chroot local includes, mais aussi tous les groupes et autorisations associés à l'utilisateur live. 531 Vous pouvez indiquer d'autres groupes pour l'utilisateur live en utilisant une des possibilités pour configurer live-config. Par exemple, pour ajouter l'utilisateur live au groupe fuse, vous pouvez ajouter le fichier suivant dans config/includes.chroot/etc/live/config/user-setup.conf: 532 533 LIVE_USER_DEFAULT_GROUPS="audio cdrom dip floppy video plugdev netdev powerdev scanner bluetooth fuse"
ou utiliser live-config.user-default-groups=audio,cdrom,dip,floppy,video,plugdev,netdev,powerdev,scanner,bluetooth,fuse comme paramètre d'amorçage. 534 Il est é galement possible de changer le nom de l'utilisateur par défaut « user» et du mot de passe par défaut « live». Si vous voulez faire cela, vous pouvez le faire facilement comme suit: 535 Pour modifier le nom de l'utilisateur par défaut, vous pouvez simplement l'indiquer dans votre configuration: 536 537 $ lb config --bootappend-live "boot=live components username=live-user"
Une façon possible de changer le mot de passe par défaut est d'utiliser un hook comme décrit dans Hooks pendant le démarrage. Pour ce faire vous pouvez utiliser le hook "passwd" de /usr/share/doc/live-config/examples/hooks, ajouter un préfixe correct (par exemple 2000-passwd) et l'ajouter à config/includes.chroot/lib/live/config/ 538 10.2 Personnalisation des paramètres régionaux et de la langue 539 Au démarrage du système live, la langue est impliquée dans deux é tapes: 540 la génération des paramètres régionaux 541 le réglage de la disposition du clavier 542 Les paramètres régionaux par défaut pendant la construction d'un système Live sont locales=en_US.UTF-8. Pour définir les paramètres régionaux qui doivent ê tre générés, utilisez le paramètre locales dans l'option --bootappend-live de lb config, par exemple 543 544 $ lb config --bootappend-live "boot=live components locales=de_CH.UTF-8"
Plusieurs paramètres régionaux peuvent ê tre indiqués dans une liste séparée par des virgules. 545 Ce paramètre, ainsi que les paramètres de configuration du clavier indiqués ci-dessous, peut é galement ê tre utilisé sur la ligne de commande du noyau. On peut indiquer des paramètres régionaux avec language_country (dans ce cas, le codage par défaut est utilisé) ou l'expression complète language_country.encoding. Une liste des paramètres régionaux et le codage pour chacun peuvent ê tre trouvés dans /usr/share/i18n/SUPPORTED. 546 La configuration du clavier pour la console et pour X est faite par live-config en utilisant le paquet console-setup. Pour les configurer, utilisez les paramètres de démarrage keyboard-layouts, keyboard-variants, keyboard-options et keyboard-model avec l'option --bootappend-live. On peut trouver les options valides dans /usr/share/X11/xkb/rules/base.lst. Pour trouver les dispositions et les variantes correspondantes à une langue, essayez de rechercher le nom anglais de la nation oú la langue est parlée, par exemple: 547 548 $ egrep -i '(^!|german.*switzerland)' /usr/share/X11/xkb/rules/base.lst
   ! model
   ! layout
    &#160;&#160;ch &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;German (Switzerland)
   ! variant
    &#160;&#160;legacy &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;ch: German (Switzerland, legacy)
    &#160;&#160;de_nodeadkeys &#160;&#160;ch: German (Switzerland, eliminate dead keys)
    &#160;&#160;de_sundeadkeys &#160;ch: German (Switzerland, Sun dead keys)
    &#160;&#160;de_mac &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;ch: German (Switzerland, Macintosh)
   ! option
Chaque variante présente une description de la disposition appliquée. 549 Souvent, seule la disposition doit ê tre configurée. Par exemple, pour obtenir les fichiers des paramètres régionaux de l'allemand et la disposition du clavier suisse allemand dans X, utilisez: 550 551 $ lb config --bootappend-live "boot=live components locales=de_CH.UTF-8 keyboard-layouts=ch"
Toutefois, pour les cas d'utilisation très spécifiques, on peut inclure d'autres paramètres. Par exemple, pour mettre en place un système français avec une disposition French-Dvorak (Bépo) avec un clavier USB TypeMatrix EZ-Reach 2030, utilisez: 552 553 $ lb config --bootappend-live \
    &#160;&#160;&#160;&#160;"boot=live components locales=fr_FR.UTF-8 keyboard-layouts=fr keyboard-variants=bepo keyboard-model=tm2030usb"
Plusieurs valeurs peuvent ê tre indiquées dans des listes séparées par des virgules pour chacune des options keyboard-*, à l'exception de keyboard-model qui accepte une seule valeur. Veuillez consulter la page de manuel keyboard(5) pour plus de détails et des exemples des variables XKBMODEL, XKBLAYOUT, XKBVARIANT et XKBOPTIONS. Si plusieurs valeurs keyboard-variants sont données, elles seront jumelées une à une avec les valeurs keyboard-layouts (voir setxkbmap(1) option -variant). On peut utiliser des valeurs vides; par exemple pour régler deux dispositions, une par défaut US QWERTY et l'autre US Dvorak, utilisez: 554 555 $ lb config --bootappend-live \
    &#160;&#160;&#160;&#160;"boot=live components keyboard-layouts=us,us keyboard-variants=,dvorak"
10.3 Persistance 556 Le paradigme d'un Live CD est d'être un système pré-installé qui amorce sur un support en lecture seule, comme un cdrom, oú les données et les modifications ne survivent pas aux redémarrages du matériel hôte qui l'exécute. 557 Un système live est une généralisation de ce paradigme et gère ainsi d'autres supports en plus de CDs. Malgré tout, dans son comportement par défaut, il doit ê tre considéré en lecture seule et toutes les é volutions pendant l'exécution du système sont perdues à l'arrêt. 558 La « persistance» est un nom commun pour les différents types de solutions pour sauver, après un redémarrage, certaines ou toutes les données, de cette é volution pendant l'exécution du système. Pour comprendre comment cela fonctionne, il peut ê tre utile de savoir que même si le système est démarré et exécuté à partir d'un support en lecture seule, les modifications des fichiers et répertoires sont é crites sur des supports inscriptibles, typiquement un disque ram (tmpfs) et les données des disques RAM ne survivent pas à un redémarrage. 559 Les données stockées sur ce disque virtuel doivent ê tre enregistrées sur un support inscriptible persistant comme un support de stockage local, un partage réseau ou même une séance d'un CD/DVD multisession (ré)inscriptible. Tous ces supports sont pris en charge dans les systèmes live de différentes manières, et tous, à part le dernier, nécessitent un paramètre d'amorçage spécial à préciser au moment du démarrage: persistence. 560 Si le paramètre de démarrage persistence est réglé (et nopersistence n'est pas utilisé), les supports de stockage locaux (par exemple les disques durs, clés USB) seront examinés pour trouver des volumes persistants pendant le démarrage. Il est possible de limiter les types de volumes persistants à utiliser en indiquant certains paramètres de démarrage décrits dans la page de manuel live-boot(7). Un volume persistant est un des é léments suivants: 561 une partition, identifiée par son nom GPT. 562 un système de fichiers, identifié par son é tiquette de système de fichiers. 563 un fichier image situé sur la racine d'un système de fichiers en lecture (même une partition NTFS d'un système d'exploitation é tranger), identifié par son nom de fichier. 564 L'étiquette du volume pour les overlays doit ê tre persistence mais elle sera ignorée à moins de contenir dans sa racine un fichier nommé persistence.conf qui est utilisé pour personnaliser entièrement la persistance du volume, c'est-à-dire indiquer les répertoires que vous voulez sauvegarder dans votre volume de persistance après un redémarrage. Voir Le fichier persistence.conf pour plus de détails. 565 Voici quelques exemples montrant comment préparer un volume à utiliser pour la persistance. Cela peut ê tre, par exemple, une partition ext4 sur un disque dur ou sur une clé usb cré&#233;e avec: 566 567 # mkfs.ext4 -L persistence /dev/sdb1
Voir aussi Utilisation de l'espace disponible sur une clé USB. 568 Si vous avez déjà une partition sur votre périphérique, vous pouvez simplement modifier l'étiquette avec l'un des exemples suivants: 569 570 # tune2fs -L persistence /dev/sdb1 # for ext2,3,4 filesystems
Voici un exemple montrant comment créer un fichier image avec un système de fichiers ext4 pour ê tre utilisé pour la persistance: 571 572 $ dd if=/dev/null of=persistence bs=1 count=0 seek=1G # for a 1GB sized image file
   $ /sbin/mkfs.ext4 -F persistence
Une fois que le fichier image est cré&#233;, à titre d'exemple, pour rendre /usr persistant mais seulement enregistrer les modifications que vous apportez à ce répertoire et non pas tout le contenu de /usr, vous pouvez utiliser l'option « union». Si le fichier image se trouve dans votre répertoire personnel, copiez-le à la racine du système de fichiers de votre disque dur et montez-le dans /mnt comme suit: 573 574 # cp persistence /
   # mount -t ext4 /persistence /mnt
Ensuite, créez le fichier persistence.conf ajoutant du contenu et démontez le fichier image. 575 576 # echo "/usr union" > > /mnt/persistence.conf
   # umount /mnt
Maintenant, redémarrez dans votre support live avec le paramètre de démarrage "persistence". 577 10.3.1 Le fichier persistence.conf 578 Un volume ayant l'étiquette persistence doit ê tre configuré avec un fichier persistence.conf pour créer des répertoires persistants arbitraires. Ce fichier, situé sur le système de fichiers racine du volume, contrôle quels répertoires il rend persistants, et de quelle manière. 579 La façon de configurer les montages overlays est décrite en détail dans la page de manuel persistence.conf(5), mais un simple exemple devrait suffire pour la plupart des utilisations. Imaginons que nous voulions rendre notre répertoire personnel et APT cache persistants dans un système de fichiers ext4 sur la partition /dev/sdb1: 580 581 # mkfs.ext4 -L persistence /dev/sdb1
   # mount -t ext4 /dev/sdb1 /mnt
   # echo "/home" > > /mnt/persistence.conf
   # echo "/var/cache/apt" > > /mnt/persistence.conf
   # umount /mnt
Puis nous redémarrons. Lors du premier démarrage, les contenus du /home et /var/cache/apt seront copiés dans le volume persistant. À partir de ce moment, tous les changements dans ces répertoires seront stockés dans le volume persistant. Veuiller remarquer que les chemins répertoriés dans le fichier persistence.conf ne peuvent pas contenir d'espaces ou d'éléments spéciaux . et ... En outre, ni /lib, /lib/live (ou un de leurs sous-répertoires), ni / ne peuvent ê tre rendus persistants en utilisant des montages personnalisés. Comme solution à cette limitation, vous pouvez ajouter / union à votre fichier persistence.conf pour obtenir une persistance complète. 582 10.3.2 Utilisation de plusieurs dispositifs de persistance 583 Il existe différentes méthodes d'utilisation de multiples dispositifs de persistance pour les différents cas d'utilisation. Par exemple, utiliser plusieurs dispositifs à la fois ou en sélectionner un seul, entre plusieurs, à des fins très spécifiques. 584 Plusieurs volumes overlays différents (avec leurs propres fichiers persistence.conf) peuvent ê tre utilisés au même temps, mais si plusieurs volumes rendent le même répertoire persistant, un seul d'entre eux sera utilisé. Si les deux sont « imbriqués» (un est un sous-répertoire de l'autre) le premier sera monté avant le second de sorte qu'aucun ne sera caché par l'autre. Monter des é léments personnalisés imbriqués est problématique s'ils sont é numérés dans le même fichier persistence.conf. Voir la page de manuel persistence.conf(5) pour savoir comment gérer ce cas si vous en avez vraiment besoin (remarque: ce n'est généralement pas le cas). 585 Un cas d'utilisation possible: Si vous souhaitez stocker les données de l'utilisateur, c'est-à-dire /home et les données du superutilisateur, c'est-à-dire /root dans des partitions différentes, créer deux partitions avec l'étiquette persistence et ajouter un fichier persistence.conf dans chacun comme ç a # echo "/home" > persistence.conf pour la première partition qui permettra de sauver les fichiers de l'utilisateur et # echo "/root" > persistence.conf pour la seconde partition qui permettra de stocker les fichiers du superutilisateur. Enfin, utiliser le paramètre d'amorçage persistence. 586 Si un utilisateur a besoin de stockages persistants multiples du même type pour différents endroits ou essais, tel que private et work, le paramètre de démarrage persistence-label utilisé en conjonction avec le paramètre de démarrage persistence permettra de multiples mais uniques supports persistants. Dans le cas oú un utilisateur voudrait utiliser une partition persistante é tiquetée private, pour des données personelles comme les marque-pages du navigateur ou d'autres types, il utiliserait les paramètres de démarrage: persistence persistence-label=private. Et pour stocker des données liées au travail, comme des documents, des projets de recherche ou d'autres types, il utiliserait les paramètres de démarrage: persistence persistence-label=work. 587 Il est important de se rappeler que chacun de ces volumes, private et work, a é galement besoin d'un fichier persistence.conf dans sa racine. La page de manuel live-boot contient plus d'informations sur la façon d'utiliser ces é tiquettes avec des noms ancients. 588 10.3.3 Utilisation de la persistance avec chiffrement 589 Utiliser la persistance signifie que certaines données sensibles peuvent ê tre exposées au risque. Surtout si les données persistantes sont stockées sur un dispositif portable tel qu'une clé USB ou un disque dur externe. C'est quand le chiffrement est plus pratique. Même si la procédure complète peut paraître compliquée en raison du nombre d'étapes à suivre, il est vraiment facile de manipuler des partitions chiffrées avec live-boot. Pour utiliser luks, qui est le type de chiffrement pris en charge, vous devez installer cryptsetup tant sur la machine avec laquelle vous créez la partition chiffrée et aussi dans le système live avec lequel vous allez utiliser la partition persistante chiffrée. 590 Pour installer cryptsetup sur votre machine: 591 592 # apt-get install cryptsetup
Pour installer cryptsetup dans votre système live, ajouter à vos listes de paquets: 593 594 $ lb config
   $ echo "cryptsetup" > config/package-lists/encryption.list.chroot
Une fois que vous avez votre système live avec cryptsetup, vous avez essentiellement besoin de créer une nouvelle partition, la chiffrer et démarrer avec les paramètres persistence et persistence-encryption=luks. Nous aurions pu déjà anticipée cette é tape et ajoutée ces paramètres de démarrage selon la procédure habituelle: 595 596 $ lb config --bootappend-live "boot=live components persistence persistence-encryption=luks"
Allons dans les détails pour tous ceux qui ne connaissent pas bien le chiffrement. Dans l'exemple suivant, nous allons utiliser une partition sur une clé usb qui correspond au dispositif /dev/sdc2. S'il vous plaît ê tre averti que vous devez déterminer quelle partition est celui que vous allez utiliser dans votre cas particulier. 597 La première é tape est de brancher votre clé usb et de déterminer quel dispositif il est. La méthode recommandée pour lister les dispositifs dans live-manual est utiliser ls -l /dev/disk/by-id. Après cela, créer une nouvelle partition et la chiffrer avec un mot de passe comme suit: 598 599 # cryptsetup --verify-passphrase luksFormat /dev/sdc2
Ensuite, ouvrir la partition luks dans le mappeur de dispositifs virtuel. Utilisez n'importe quel nom que vous aimez. Nous utilisons live ici à titre d'exemple: 600 601 # cryptsetup luksOpen /dev/sdc2 live
La prochaine é tape est de remplir le dispositif avec des zéros avant de créer le système de fichiers: 602 603 # dd if=/dev/zero of=/dev/mapper/live
Maintenant, nous sommes prêts à créer le système de fichiers. Notez que nous ajoutons l'étiquette persistence de sorte que le dispositif est monté en tant que magasin de persistance au moment du démarrage. 604 605 # mkfs.ext4 -L persistence /dev/mapper/live
Pour continuer avec notre configuration, nous avons besoin de monter le dispositif, par exemple dans /mnt. 606 607 # mount /dev/mapper/live /mnt
Et créer le fichier persistence.conf à la racine de la partition. Ceci est, comme expliqué précédemment, strictement nécessaire. Voir Le fichier persistence.conf. 608 609 # echo "/ union" > /mnt/persistence.conf
Puis, démontez le point de montage: 610 611 # umount /mnt
Et é ventuellement, bien qu'il pourrait ê tre un bon moyen de sécuriser les données que nous venons d'ajouter à la partition, nous pouvons fermer le dispositif: 612 613 # cryptsetup luksClose live
Résumons la procédure. Jusqu'ici nous avons cré&#233; un système capable d'utiliser le chiffrement, qui peut ê tre copié sur une clé usb comme expliqué dans Copie d'une image ISO hybride sur une clé USB. Nous avons é galement cré&#233; une partition chiffrée, qui peut ê tre située dans la même clé USB pour le porter autour et nous avons configuré la partition chiffrée pour ê tre utilisée comme magasin de persistance. Alors maintenant, nous avons seulement besoin de démarrer le système live. Au moment du démarrage, live-boot nous demandera le mot de passe pour monter la partition chiffrée à ê tre utilisé pour la persistance. 614 Personnalisation de l'image binaire 615 11. Personnalisation de l'image binaire 616 11.1 Chargeurs d'amorçage 617 live-build utilise syslinux et certains de ses dérivés (selon le type d'image) comme chargeurs d'amorçage par défaut. Vous pouvez facilement les personnaliser pour répondre à vos besoins. 618 Pour utiliser un thème complet, copiez /usr/share/live/build/bootloaders dans config/bootloaders et modifiez les fichiers là. Si vous ne voulez pas modifier toutes les configurations du chargeur d'amorçage prises en charge, il suffit de fournir une copie locale personnalisée d'un des chargeurs, par exemple copiez la configuration d'isolinux dans config/bootloaders/isolinux, selon votre cas d'utilisation. 619 Lors de la modification d'un des thèmes par défaut, si vous souhaitez utiliser une image de fond personnalisée qui sera affichée avec le menu de démarrage, ajouter une image splash.png de 640x480 pixels. Ensuite, supprimer le fichier splash.svg. 620 Il y a beaucoup de possibilités quand il s'agit de faire des changements. Par exemple, les dérivés de syslinux sont configurés par défaut avec un timeout de 0 (zéro), ce qui signifie qu'ils se mettront en pause indéfiniment à leur é cran de démarrage jusqu'à ce que vous pressiez une touche. 621 Pour modifier le délai de démarrage d'une image iso-hybrid, vous pouvez modifier un fichier isolinux.cfg en précisant le timeout dans les unités de 1/10 secondes. Un isolinux.cfg modifié pour démarrer cinq secondes plus tard serait semblable à ceci: 622 623 include menu.cfg
   default vesamenu.c32
   prompt 0
   timeout 50
11.2 Métadonnées ISO 624 En créant une image binaire ISO9660, vous pouvez utiliser les options suivantes pour ajouter différentes métadonnées textuelles pour votre image. Cela peut vous aider à facilement identifier la version ou la configuration d'une image sans la démarrer. 625 LB_ISO_APPLICATION/--iso-application NAME: Cela devrait décrire l'application qui sera sur l'image. Le nombre maximum de caractères pour ce champ est 128. 626 LB_ISO_PREPARER/--iso-preparer NAME: Cela devrait décrire le préparateur de l'image, généralement avec certains détails de contact. Le défaut de cette option est la version de live-build que vous utilisez, ce qui peut faciliter le débogage plus tard. Le nombre maximum de caractères pour ce champ est 128. 627 LB_ISO_PUBLISHER/--iso-publisher NAME: Ce doit décrire l'éditeur de l'image, généralement avec certains détails de contact. Le nombre maximum de caractères pour ce champ est 128. 628 LB_ISO_VOLUME/--iso-volume NAME: Cela devrait indiquer l'ID de volume de l'image. Il est utilisé comme une é tiquette visible par l'utilisateur sur certaines plateformes comme Windows et Apple Mac OS. Le nombre maximum de caractères pour ce champ est 128. 629 Personnalisation de l'installateur Debian 630 12. Personnalisation du contenu pour l'installateur Debian 631 Les images des systèmes live peuvent ê tre intégrées avec l'installateur Debian. Il y a un certain nombre de types d'installation différents, variant en fonction de ce qui est inclus et de la façon dont fonctionne l'installateur. 632 Veuillez noter l'utilisation prudente des lettres majuscules pour désigner « l'Installateur Debian» dans cette section - lorsqu'il est utilisé comme cela, nous faisons explicitement référence à l'installateur officiel pour le système Debian. On le voit souvent abrégé en « d-i». 633 12.1 Types d'installateur Debian 634 Les trois principaux types de programme d'installation sont: 635 Installateur Debian « Normal»: C'est une image du système live avec un noyau et initrd séparés qui (lorsqu'ils sont sélectionnés à partir du chargeur d'amorçage approprié) se lancent dans une instance d'installateur Debian standard, exactement comme si vous aviez téléchargé une image de CD de Debian et l'aviez démarrée. Les images contenant un système live et un installateur indépendant sont souvent appelées « images combinées». 636 Sur ces images, Debian est installé par l'extraction et l'installation de paquets .deb à l'aide de debootstrap, à partir des supports locaux ou du réseau, résultant en un système Debian par défaut installé sur le disque dur. 637 Tout ce processus peut ê tre préconfiguré et personnalisé d'un certain nombre de façons. Consultez les pages correspondantes dans le manuel de l'Installateur Debian pour plus d'informations. Une fois que vous avez un fichier de préconfiguration qui fonctionne, live-build peut automatiquement l'ajouter à l'image et l'activer pour vous. 638 Installateur Debian "Live" : C'est une image du système live avec un noyau et initrd séparés qui (lorsqu'ils sont sélectionnés à partir du chargeur d'amorçage approprié) se lancent dans une instance de l'installateur Debian. 639 L'installation continue de manière identique à l'installation « normale» décrite ci-dessus, mais à l'étape de l'installation des paquets, au lieu d'utiliser debootstrap pour aller chercher et installer des paquets, l'image du système de fichiers live est copiée vers la cible. Ce résultat est obtenu avec un udeb spécial appelé live-installer. 640 Après cette é tape, l'installateur Debian continue normalement, en installant et configurant des é léments tels que les chargeurs d'amorçage et les utilisateurs locaux, etc. 641 Remarque: Pour prendre en charge les deux options − installateur normal et live − dans le chargeur d'amorçage du même support live, vous devez désactiver live-installer en utilisant la préconfiguration live-installer/enable=false. 642 Installateur Debian "de bureau": Indépendamment du type d'installateur Debian inclus, d-i peut ê tre lancé à partir du bureau en cliquant sur une icône, ce qui est plus facile à utiliser dans certaines situations. Pour pouvoir en faire usage, le paquet debian-installer-launcher doit ê tre inclus. 643 Notez que, par défaut, live-build n'inclut pas les images de l'installateur Debian dans les images, il doit ê tre spécifiquement activé avec lb config. De même, veuillez noter que pour que l'installateur "de bureau" fonctionne, le noyau du système live doit correspondre au noyau que d-i utilise pour l'architecture indiquée. Par exemple: 644 645 $ lb config --architectures i386 --linux-flavours 586 \
    &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;--debian-installer live
   $ echo debian-installer-launcher > > config/package-lists/my.list.chroot
12.2 Personnalisation de l'installateur Debian par préconfiguration 646 Comme décrit dans le manuel de Debian Installer, appendice B sur <https://www.debian.org/releases/stable/i386/apb.html>, « La préconfiguration est une façon de donner des réponses aux questions posées pendant le processus d'installation, sans avoir à entrer manuellement les réponses alors que l'installation est en marche. Cela permet d'automatiser entièrement la plupart des types d'installation et elle offre certaines fonctionnalités que ne sont pas disponibles pendant les installations normales » . Ce type de personnalisation se fait mieux avec live-build en plaçant la configuration dans un fichier preseed.cfg inclus dans config/includes.installer/. Par exemple, pour préconfigurer les paramètres régionaux pour en_US: 647 648 $ echo "d-i debian-installer/locale string en_US" \
    &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#62;&#62; config/includes.installer/preseed.cfg
12.3 Personnalisation de contenu pour l'Installateur Debian 649 À des fins expérimentales ou de débogage, vous pouvez inclure des paquets udeb d-i construits localement. Placez-les dans config/packages.binary/ pour les inclure dans l'image. Plusieurs fichiers supplémentaires ou de remplacement et plusieurs répertoires peuvent aussi ê tre inclus dans l'initrd de l'installateur, d'une manière similaire à Live/chroot local includes en plaçant le contenu dans config/includes.installer/. 650 Projet 651 Contribuer au projet 652 13. Contribuer au projet 653 Lorsque vous soumettez une contribution, veuillez indiquer clairement le copyright et inclure toute mention légale relative à la licence. Notez que pour ê tre acceptée, la contribution doit ê tre déposée sous la même licence que le reste du document, c'est-à-dire la GPL version 3 ou ultérieure. 654 Les contributions au projet, comme les traductions et les correctifs, sont bienvenues. Les livraisons au dépôt sont possibles pour tout le monde, cependant, nous vous demandons d'envoyer les changements importants sur la liste de diffusion au préalable. Veuillez consulter Contacter pour plus d'informations. 655 Le Live Systems Project utilise Git en tant que système de contrôle de version et de gestion du code source. Comme expliqué dans Dépôts Git il existe deux branches de développement principales: debian et debian-next. Tout le monde peut faire des livraisons aux branches debian-next des dépôts live-boot, live-build, live-config, live-images, live-manual et live-tools. 656 Cependant, il y a certaines restrictions. Le serveur rejette: 657 Push non fast-forward. 658 Commits merge. 659 Ajout ou suppression d'étiquettes ou des branches. 660 Même si toutes les livraisons pourraient ê tre révisées, nous vous demandons d'utiliser votre bon sens et de faire bonnes livraisons avec de bons messages de livraison. 661 Veuillez é crire les commentaires de livraison à l'aide de phrases complètes, en commençant par une majuscule et en terminant par un point, et avec la forme 'Fixing/Adding/Removing/Correcting/Translating/...'. 662 É crivez de bons messages de livraison. La première ligne doit ê tre un résumé précis du contenu du commit qui sera inclus dans le changelog. Si vous avez besoin de faire quelques explications supplémentaires, é crivez-les au-dessous en laissant une ligne vide après la première, puis une autre ligne vide après chaque paragraphe. Les lignes des paragraphes ne doivent pas dépasser 80 caractères. 663 Faites des livraisons de façon atomique, c'est-à-dire, ne mélangez pas des choses sans liens entre elles dans la même livraison. Faites un commit différent pour chaque modification que vous apportez. 664 13.1 Faire des changements 665 Afin de faire un push sur les dépôts, vous devez suivre la procédure suivante. Ici, nous utilisons live-manual comme un exemple pour le remplacer par le nom du dépôt dans lequel vous souhaitez travailler. Pour plus d'informations sur la façon de modifier live-manual, consultez Contribuer à ce document. 666 Téléchargez la clé publique: 667 668 $ mkdir -p ~/.ssh/keys
   $ wget http://live-systems.org/other/keys/git@live-systems.org -O ~/.ssh/keys/git@live-systems.org
   $ wget http://live-systems.org/other/keys/git@live-systems.org.pub -O ~/.ssh/keys/git@live-systems.org.pub
   $ chmod 0600 ~/.ssh/keys/git@live-systems.org*
Ajoutez la section suivante à votre configuration openssh-client: 669 670 $ cat > > ~/.ssh/config < < EOF
   Host live-systems.org
    &#160;&#160;&#160;&#160;Hostname live-systems.org
    &#160;&#160;&#160;&#160;User git
    &#160;&#160;&#160;&#160;IdentitiesOnly yes
    &#160;&#160;&#160;&#160;IdentityFile ~/.ssh/keys/git@live-systems.org
   EOF
Clonez live-manual avec ssh: 671 672 $ git clone git@live-systems.org:/live-manual.git
   $ cd live-manual &&amp; git checkout debian-next
Assurez-vous d'avoir renseignés les champs d'auteur et d'email dans Git: 673 674  &#160;$ git config user.name "John Doe"
    &#160;$ git config user.email john@example.org
Important: Rappelez-vous que vous devez livrer les changements sur la branche debian-next. 675 Effectuez vos modifications. Dans cet exemple, vous devriez commencer par é crire une nouvelle section traitant l'application des correctifs et ensuite préparer l'ajout des fichiers et é crire le message de livraison comme ceci: 676 677 $ git commit -a -m "Adding a section on applying patches."
Envoyez votre commit au serveur: 678 679 $ git push
Signaler des bogues 680 14. Signaler des bogues 681 Les systèmes live sont loin d'être parfaits, mais nous voulons les rendre aussi parfaits que possible − avec votre aide. N'hésitez pas à signaler un bogue. Il est préférable de remplir un rapport deux fois plus que jamais. Toutefois, ce chapitre contient des recommandations pour présenter de bons rapports de bogues. 682 Pour les impatients: 683 Commencez toujours par vérifier les mises à jour du statut de l'image sur notre page d'accueil <http://live-systems.org/> pour voir les problèmes connus. 684 Avant de présenter un rapport de bogue, toujours essayer de reproduire le bogue avec les versions les plus récentes de la branche de live-build, live-boot, live-config et live-tools que vous utilisez (comme la dernière version 4.x de live-build si vous utilisez live-build 4). 685 Essayez de donner des informations aussi précises que possible sur le bogue. Cela comprend (au moins) la version de live-build, live-boot, live-config et live-tools, de la distribution utilisée et du système live que vous construisez. 686 14.1 Problèmes connus 687 Puisque les distributions Debian testing et Debian unstable sont des cibles mouvantes, quand vous les indiquez comme distributions du système cible, une construction avec succès n'est pas toujours possible. 688 Si cela vous pose trop de difficulté, ne construisez pas un système basé sur testing ou unstable, mais utilisez plutôt stable. live-build utilise toujours la version stable par défaut. 689 Les problèmes connus sont é numérés dans la section « statut» sur notre page <http://live-systems.org/>. 690 Le sujet de ce manuel n'est pas de vous former à identifier et corriger correctement les problèmes dans les paquets des distributions de développement. Cependant, il y a deux choses que vous pouvez toujours essayer: Si une construction é choue lorsque la distribution cible est testing, essayez unstable. Si unstable ne fonctionne pas non plus, revenez à testing et fixez la nouvelle version du paquet qui é choue de unstable (voir APT pinning pour plus de détails). 691 14.2 Reconstruire à partir de zéro 692 Afin de vous assurer qu'un bogue en particulier n'est pas causé par un système mal construit, veuillez toujours reconstruire l'ensemble du système live à partir de zéro pour voir si le bogue est reproductible. 693 14.3 Utiliser des paquets mis à jour 694 L'utilisation de paquets obsolètes peut causer des problèmes importants en essayant de reproduire (et finalement régler) votre problème. Assurez-vous que votre système de construction est mis à jour et tous les paquets inclus dans votre image sont mis à jour aussi. 695 14.4 Recueillir l'information 696 Veuillez fournir assez d'informations avec votre rapport. Incluez au moins la version exacte de live-build oú le bogue est rencontré et les mesures pour le reproduire. Veuillez utiliser votre bon sens et incluez d'autres renseignements pertinents, si vous pensez que cela pourrait aider à résoudre le problème. 697 Pour tirer le meilleur parti de votre rapport de bogue, nous avons au moins besoin des informations suivantes: 698 L'architecture du système hôte 699 Distribution du système hôte 700 Version de live-build sur le système hôte 701 Version de debootstrap et/ou cdebootstrap sur le système hôte 702 L'architecture du système live 703 Répartition du système live 704 Version de live-boot sur le système live 705 Version de live-config sur le système live 706 Version de live-tools sur le système live 707 Vous pouvez générer un journal du processus de construction en utilisant la commande tee. Nous recommandons de faire cela automatiquement avec un script auto/build (voir Gestion d'une configuration pour les détails). 708 709 # lb build 2>&1 | tee build.log
Au démarrage, live-boot et live-config stockent un journal dans /var/log/live/boot.log. Vérifiez-les pour des messages d'erreur. 710 Par ailleurs, pour é carter d'autres erreurs, c'est toujours une bonne idée de faire un tar de votre répertoire config/ et de le télécharger quelque part (ne pas l'envoyer en pièce jointe à la liste de diffusion), de sorte que nous puissions essayer de reproduire les erreurs que vous rencontrez. Si cela est difficile (en raison par exemple de la taille) vous pouvez utiliser la sortie de lb config --dump qui produit un résumé de votre arbre de config (c'est-à-dire les listes des fichiers dans les sous-répertoires de config/ mais ne les inclut pas). 711 N'oubliez pas d'envoyer tous les journaux produits avec les paramètres régionaux anglais. Par exemple, exécutez vos commandes live-build précédées par LC_ALL=C ou LC_ALL=en_US. 712 14.5 Isoler le cas qui é choue, si possible 713 Si possible, isolez le cas qui é choue au plus petit changement possible. Il n'est pas toujours facile de faire cela, donc si vous ne pouvez pas le gérer pour votre rapport, ne vous inquiétez pas. Toutefois, si vous planifiez bienvotre cycle de développement, en utilisant de petits ensembles de changements par itération, vous pourriez ê tre capable d'isoler le problème en construisant une configuration simple « base» qui correspond é troitement à la configuration réelle avec seulement le changement cassé ajouté. S'il est difficile de trier vos modifications qui cassent, il est possible que vous incluiez trop dans chaque ensemble de modifications et vous devriez développer en petits incréments. 714 14.6 Utiliser le paquet adéquat pour rapporter un bogue 715 Si vous ne savez pas quel composant est responsable du bogue ou si le bogue est un bogue général concernant les systèmes live, vous pouvez remplir un rapport de bogue sur le pseudo-paquet debian-live. 716 Toutefois, nous apprécierions que vous essayiez de le réduire en fonction de l'endroit oú le bogue apparaît. 717 14.6.1 Pendant la construction durant l'amorçage 718 live-build amorce d'abord un système Debian de base avec debootstrap ou cdebootstrap. Selon l'outil d'amorçage utilisé et de la distribution Debian, il peut é chouer. Si un bogue apparaît ici, vérifiez si l'erreur est liée à un paquet Debian spécifique (plus probable), ou si elle est liée à l'outil d'amorçage lui-même. 719 Dans les deux cas, ce n'est pas un bogue dans le système live, mais plutôt dans Debian lui-même que probablement nous ne pouvons pas le résoudre directement. Veuillez signaler un bogue sur l'outil d'amorçage ou du paquet défaillant. 720 14.6.2 Pendant la construction durant l'installation de paquets 721 live-build installe des paquets supplémentaires de l'archive Debian et en fonction de la distribution Debian utilisée et l'état quotidien de l'archive, il peut é chouer. Si un bogue apparaît ici, vérifiez si l'erreur est é galement reproductible sur un système normal. 722 Si c'est le cas, ce n'est pas un bogue dans le système live, mais plutôt dans Debian − veuillez envoyer le rapport sur le paquet défaillant. L'exécution de debootstrap séparément du système de construction ou l'exécution de lb bootstrap --debug vous donnera plus d'informations. 723 Aussi, si vous utilisez un miroir local et/ou un proxy et vous rencontrez un problème, veuillez toujours le reproduire en amorçant d'abord sur un miroir officiel. 724 14.6.3 Pendant le démarrage 725 Si votre image ne démarre pas, veuillez le signaler à la liste de diffusion avec les informations demandées dans Recueillir l'information. N'oubliez pas de mentionner, comment/quand l'image a é choué, soit en virtualisation ou sur du matériel réel. Si vous utilisez une technologie de virtualisation de quelconque sorte, veuillez toujours tester sur du matériel réel avant de signaler un bogue. Fournir une copie d'écran de l'échec est é galement très utile. 726 14.6.4 Pendant l'exécution 727 Si un paquet a é té installé avec succès, mais qu'il é choue lors de l'exécution du système Live, il s'agit probablement d'un bogue dans le système live. Cependant: 728 14.7 Effectuer une recherche 729 Avant de présenter le bogue, veuillez rechercher sur le web le message d'erreur ou un symptôme particulier que vous obtenez. Comme il est hautement improbable que vous soyez la seule personne faisant l'expérience d'un problème particulier, il y a toujours une chance qu'il ait é té discuté ailleurs, et qu'une solution possible, un correctif, ou une solution de contournement ait é té proposés. 730 Vous devez prêter une attention particulière à la liste de diffusion du système live, ainsi qu'à la page d'accueil, car elles sont susceptibles de contenir des informations à jour. Si ces informations existent, incluez toujours les références au sein de vos rapports de bogues. 731 En outre, vous devriez vérifier les listes de bogues en cours de live-build, live-boot, live-config et live-tools pour voir si quelque chose de semblable n'a pas déjà é té signalée. 732 14.8 Oú rapporter les bogues 733 Le Live Systems Project conserve la trace de tous les bogues dans le système de suivi des bogues (BTS). Pour plus d'informations sur la façon d'utiliser le système, veuillez consulter <https://bugs.debian.org/>. Vous pouvez é galement soumettre les bogues en utilisant la commande reportbug du paquet du même nom. 734 En général, vous devez signaler les erreurs de construction contre le paquet live-build, les erreurs lors du démarrage contre live-boot, et les erreurs d'exécution contre live-config. Si vous n'êtes pas sür du paquet approprié ou si vous avez besoin d'aide avant de soumettre un rapport de bogue, veuillez signaler le bogue contre le pseudo-paquet debian-live. Nous le réattribuerons s'il y a lieu. 735 Veuillez noter que les bogues trouvés dans les distributions dérivées de Debian (comme Ubuntu et autres) ne doivent pas ê tre rapportés au BTS de Debian, sauf s'ils peuvent ê tre é galement reproduits sur un système Debian en utilisant les paquets Debian officiels. 736 Style de code 737 15. Style du code 738 Ce chapitre documente le style du code utilisé dans les systèmes live. 739 15.1 Compatibilité 740 N'utilisez pas une syntaxe ou sémantique qui soit unique au shell Bash. Par exemple, l'utilisation de tableaux (arrays). 741 N'utilisez que le sous-ensemble POSIX − par exemple, utilisez $(foo) au lieu de `foo`. 742 Vous pouvez vérifier vos scripts avec 'sh -n' et 'checkbashisms'. 743 Assurez-vous que tout le code fonctionne avec 'set-e '. 744 15.2 Indentation 745 Utilisez toujours des tabulations au lieu des espaces. 746 15.3 Adaptateur 747 Généralement, les lignes sont de 80 caractères au maximum. 748 Utilisez le « style Linux» des sauts de ligne: 749 Mal: 750 751 if foo; then
    &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;bar
   fi
Bien: 752 753 if foo
   then
    &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;bar
   fi
La même chose vaut pour les fonctions: 754 Mal: 755 756 Foo () {
    &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;bar
   }
Bien: 757 758 Foo ()
   {
    &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;bar
   }
15.4 Variables 759 Les variables sont toujours en lettres majuscules. 760 Les variables utilisées dans live-build commencent toujours par le préfixe LB_. 761 Les variables temporaires internes dans live-build devraient commencer avec le préfixe _LB_. 762 Les variables locales commencent avec le préfixe _&#095;LB_. 763 Les variables en relation avec un paramètre de démarrage dans live-config commencent par LIVE_. 764 Toutes les autres variables dans live-config commencent par le préfixe _. 765 Utilisez des accolades autour des variables; é crivez par exemple ${FOO} au lieu de $FOO. 766 Protégez toujours les variables avec des guillemets pour respecter les espaces potentiels: é crire "${FOO}" en lieu de ${FOO}. 767 Pour des raisons de cohérence, utilisez toujours les guillemets lors de l'attribution des valeurs aux variables: 768 Mal: 769 770 FOO=bar
Bien: 771 772 FOO="bar"
Si plusieurs variables sont utilisées, utilisez les guillemets pour l'expression complète: 773 Mal: 774 775 if [ -f "${FOO}"/foo/"${BAR}"/bar ]
   then
    &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;foobar
   fi
Bien: 776 777 if [ -f "${FOO}/foo/${BAR}/bar" ]
   then
    &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;foobar
   fi
15.5 Autres 778 Utilisez "|" (sans les guillemets autour) comme séparateur dans les appels à sed, par exemple "sed -e 's|foo|bar|'" (sans" "). 779 N'utilisez pas la commande test pour des comparaisons ou des tests, utilisez "[" "]" (sans ""); par exemple "if [ -x /bin/foo ]; ..." et non pas "if test -x /bin/foo; ...". 780 Utilisez case dans la mesure du possible au lieu de test, parce qu'il est plus facile à lire et plus rapide à exécuter. 781 Utilisez des noms en majuscule pour les fonctions pour é viter toute interférence avec l'environnement des utilisateurs. 782 Procédures 783 16. Procédures 784 Ce chapitre documente les procédures au sein du Live Systems Project pour différentes tâches qui ont besoin de coopération avec d'autres é quipes dans Debian. 785 16.1 É volutions majeures 786 La libération d'une nouvelle version stable majeure de Debian inclut un grand nombre de différentes é quipes travaillant ensemble. À un certain point, l'équipe Live arrive et construit des images du système live. Les conditions pour ce faire sont les suivantes: 787 Un miroir contenant les versions publiées des archives Debian et debian-security auxquelles le buildd de debian-live peut avoir accès. 788 Les noms de l'image doivent ê tre connus (par exemple debian-live-VERSION-ARCH-FLAVOUR.iso). 789 Les données qui proviennent de debian-cd doivent ê tre synchronisées (udeb exclude lists). 790 Les images sont construites et mises en miroir sur cdimage.debian.org. 791 16.2 É volutions mineures 792 Encore une fois, nous avons besoin de miroirs de Debian et Debian-security mis à jour. 793 Les images sont construites et mises en miroir sur cdimage.debian.org. 794 Envoyer un courriel d'annonce. 795 16.2.1 Dernière é volution mineure d'une version Debian 796 N'oubliez pas de régler à la fois les miroirs pour chroot et binary lors de la construction de la dernière série d'images pour une version de Debian après qu'elle ait é té déplacée de ftp.debian.org vers archive.debian.org. De cette façon, les vieilles images live précompilées sont encore utiles, sans modifications des utilisateurs. 797 16.2.2 Modèle pour l'annonce d'une é volution mineure 798 Un courriel pour l'annonce d'une é volutioun mineure peut ê tre généré en utilisant le modèle ci-dessous et la commande suivante: 799 800 $ sed \
    &#160;&#160;&#160;&#160;-e 's|@MAJOR@|9.0|g' \
    &#160;&#160;&#160;&#160;-e 's|@MINOR@|9.0.1|g' \
    &#160;&#160;&#160;&#160;-e 's|@CODENAME@|stretch|g' \
    &#160;&#160;&#160;&#160;-e 's|@ANNOUNCE@|2017/msgXXXXX.html|g'
Veuillez vérifier le courriel avant l'envoi et le passer à d'autres pour la relecture. 801 802 Updated Live @MAJOR@: @MINOR@ released
&lt;br />   The Live Systems Project is pleased to announce the @MINOR@ update of the
   Live images for the stable distribution Debian @MAJOR@ (codename "@CODENAME@").
&lt;br />   The images are available for download at:
&lt;br />    &#160;&#160;&#60;http://live-systems.org/cdimage/release/current/>&lt;br />
   and later at:
&lt;br />    &#160;&#160;&#60;http://cdimage.debian.org/cdimage/release/current-live/>&lt;br />
   This update includes the changes of the Debian @MINOR@ release:
&lt;br />    &#160;&#160;&#60;https://lists.debian.org/debian-announce/@ANNOUNCE@>&lt;br />
   Additionally it includes the following Live-specific changes:
&lt;br />    &#160;* [INSERT LIVE-SPECIFIC CHANGE HERE]
    &#160;* [INSERT LIVE-SPECIFIC CHANGE HERE]
    &#160;* [LARGER ISSUES MAY DESERVE THEIR OWN SECTION]
&lt;br />   About Live Systems
   ------------------
   The Live Systems Project produces the tools used to build official
   live systems and the official live images themselves for Debian.
&lt;br />   About Debian
   ------------
   The Debian Project is an association of Free Software developers who
   volunteer their time and effort in order to produce the completely free
   operating system Debian.
&lt;br />   Contact Information
   -------------------
   For further information, please visit the Live Systems web pages at
   < http://live-systems.org/>, or contact the Live Systems team at
   < debian-live@lists.debian.org>.
Dépôts Git 803 17. Dépôts Git 804 La liste de tous les dépôts disponibles du Live Systems Project est sur <http://live-systems.org/gitweb/>. Les URLs git du projet ont la forme: protocole://live-systems.org/git/dépôt. Ainsi, afin de cloner live-manual en lecture seule, lancer: 805 806 $ git clone git://live-systems.org/git/live-manual.git
Ou, 807 808 $ git clone https://live-systems.org/git/live-manual.git
Ou, 809 810 $ git clone http://live-systems.org/git/live-manual.git
Les adresses pour cloner avec autorisation d'écriture ont la forme: git@live-systems.org:/dépôt. 811 Donc, encore une fois, pour cloner live-manual sur ssh, vous devez taper: 812 813 $ git clone git@live-systems.org:live-manual.git
L'arbre git est composé de plusieurs branches différentes. Les branches debian et debian-next sont particulièrement remarquables car elles contiennent le travail réel qui sera finalement inclus dans chaque nouvelle version. 814 Après avoir cloné quelques-uns des dépôts existants, vous serez sur la branche debian. Ceci est approprié pour jeter un œil à l'état de la dernière version du projet, mais avant de commencer le travail, il est essentiel de passer à la branche debian-next. Pour ce faire: 815 816 $ git checkout debian-next
La branche debian-next, qui n'est pas toujours fast-forward, est l'endroit oú toutes les modifications sont envoyées en premier, avant de les fusionner dans la branche debian. Pour faire une analogie, c'est comme un terrain d'essai. Si vous travaillez sur cette branche et avez besoin de faire un pull, vous devrez faire un git pull --rebase de sorte que vos modifications locales sont stockées tandis qu'on fait une mise à jour à partir du serveur, puis vos changements seront mis au-dessus de tout cela. 817 17.1 Gestion de multiples dépôts 818 Si vous avez l'intention de cloner plusieurs des dépôts Live Systems et passer à la branche debian-next tout de suite pour vérifier le dernier code, é crire un correctif ou contribuer avec une traduction, vous devriez savoir que le serveur git fournit un fichier mrconfig pour faciliter la manipulation de multiples dépôts. Pour l'utiliser, vous devez installer le paquet mr, puis lancer: 819 820 $ &#160;mr bootstrap http://live-systems.org/other/mr/mrconfig
Cette commande va automatiquement cloner et passer à la branche debian-next les dépôts de développement des paquets Debian produits par le projet. Ceux-ci comprennent, entre autres, le dépôt live-images, qui contient les configurations utilisées pour les images précompilées que le projet publie pour un usage général. Pour plus d'informations sur la façon d'utiliser ce dépôt, voir Cloner une configuration publiée via Git 821 Exemples 822 Exemples 823 18. Exemples 824 Ce chapitre présente des exemples de constructions pour des cas d'utilisation spécifiques avec des systèmes live. Si vous débutez dans la construction de vos propres images des systèmes live, nous vous recommandons de regarder d'abord les trois tutoriels à la suite car chacun d'entre eux enseigne de nouvelles techniques qui vous aideront à utiliser et à comprendre les exemples restants. 825 18.1 Utiliser les exemples 826 Pour utiliser ces exemples, vous avez besoin d'un système pour les construire qui doit répondre aux exigences é numérées dans Exigences et sur lequel live-build est installé comme décrit dans Installation de live-build. 827 Notez que, pour des raisons de concision, dans ces exemples, nous n'indiquons pas de miroir local à utiliser pour la construction. Vous pouvez accélérer considérablement les téléchargements si vous utilisez un miroir local. Vous pouvez indiquer ces options lorsque vous utilisez lb config, tel que décrit dans Miroirs de distribution utilisés pendant la construction, ou pour plus de commodité, fixez par défaut votre système de construction dans /etc/live/build.conf. Il suffit de créer ce fichier et de définir les variables LB_MIRROR_* correspondantes à votre miroir préféré. Tous les autres miroirs utilisés dans la construction seront choisis par défaut à partir de ces valeurs. Par exemple: 828 829 LB_MIRROR_BOOTSTRAP="http://mirror/debian/"
   LB_MIRROR_CHROOT_SECURITY="http://mirror/debian-security/"
   LB_MIRROR_CHROOT_BACKPORTS="http://mirror/debian-updates/"
18.2 Tutoriel 1: Une image par défaut 830 Cas d'utilisation: Créer une image simple d'abord, en apprenant les bases de live-build. 831 Dans ce tutoriel, nous construirons une image ISO hybride par défaut contenant uniquement des paquets de base (pas de Xorg) et quelques paquets de prise en charge live, en guise de premier exercice dans l'utilisation de live-build. 832 Vous ne pouvez pas faire plus simple que cela: 833 834 $ mkdir tutorial1 ; cd tutorial1 ; lb config
Examinez le contenu du répertoire config/ si vous le souhaitez. Vous verrez stockés ici une arborescence de configuration, prête à ê tre personnalisée ou, dans ce cas, utilisée immédiatement pour construire une image par défaut. 835 Maintenant, en tant que superutilisateur, construisez l'image en enregistrant un journal avec tee. 836 837 # lb build 2>&1 | tee build.log
En supposant que tout se passe bien, après un certain temps, le répertoire courant contiendra live-image-i386.hybrid.iso. Cette image ISO hybride peut ê tre démarrée directement dans une machine virtuelle comme décrit dans Test d'une image ISO avec QEMU et Test d'une image ISO avec VirtualBox, ou bien copiée sur un support optique ou un périphérique USB comme décrit dans Graver une image ISO sur un support physique et Copie d'un image ISO hybride sur une clé USB, respectivement. 838 18.3 Tutoriel 2: Un utilitaire d'un navigateur Web 839 Cas d'utilisation: Créer l'image d'un utilitaire de navigation Web, en apprenant à appliquer des personnalisations. 840 Dans ce tutoriel, nous allons créer une image utilisable comme un utilitaire de navigation web, ce qui servira d'introduction à la personnalisation d'images live. 841 842 $ mkdir tutorial2
   $ cd tutorial2
   $ lb config
   $ echo "task-lxde-desktop iceweasel" > > config/package-lists/my.list.chroot
Notre choix de LXDE pour cet exemple reflète notre volonté de fournir un environnement de bureau minimal, puisque le but de l'image est l'utilisation unique que nous avons à l'esprit, le navigateur web. On pourrait aller encore plus loin et offrir une configuration par défaut pour le navigateur web dans config/includes.chroot/etc/iceweasel/profile/, ou des paquets de prise en charge supplémentaires pour visualiser différents types de contenu web, mais nous laissons cela en exercice pour le lecteur. 843 Construisez l'image, encore une fois en tant que superutilisateur, et gardez un journal comme dans Tutoriel 1: 844 845 # lb build 2>&1 | tee build.log
Encore une fois, vérifiez que l'image est OK et faites un test, comme dans Tutoriel 1: 846 18.4 Tutoriel 3: Une image personnalisée 847 Cas d'utilisation: Créer un projet pour construire une image personnalisée, contenant vos logiciels préférés à emporter avec vous sur une clé USB oú que vous alliez, et é voluant dans des révisions successives selon les changements de vos besoins et de vos préférences. 848 Puisque nous allons changer notre image personnalisée pendant un certain nombre de révisions, et que nous voulons suivre ces changements, essayer des choses expérimentalement et é ventuellement les annuler si les choses ne fonctionnent pas, nous garderons notre configuration dans le populaire système de contrôle de version git. Nous allons é galement utiliser les meilleures pratiques d'autoconfiguration via auto scripts tel que décrit dans Gestion d'une configuration. 849 18.4.1 Première révision 850 851 $ mkdir -p tutorial3/auto
   $ cp /usr/share/doc/live-build/examples/auto/* tutorial3/auto/
   $ cd tutorial3
É ditez auto/config comme suit: 852 853 #!/bin/sh
&lt;br />   lb config noauto \
    &#160;&#160;&#160;&#160;--architectures i386 \
    &#160;&#160;&#160;&#160;--linux-flavours 686-pae \
    &#160;&#160;&#160;&#160;"${@}"
Exécutez lb config pour générer l'arbre de configuration, en utilisant le script auto/config qu'on a cré&#233;: 854 855 $ lb config
Remplissez maintenant votre liste de paquets locaux: 856 857 $ echo "task-lxde-desktop iceweasel xchat" > > config/package-lists/my.list.chroot
Tout d'abord, --architectures i386 assure que sur notre système de construction amd64, nous construisons une version de 32 bits qui peut ê tre utilisée sur la plupart des machines. Deuxièmement, nous utilisons --linux-flavours 686-pae parce que nous ne prévoyons pas d'utiliser cette image sur des systèmes très anciens. Troisièmement, nous avons choisi le métapaque de la tâche lxde pour nous donner un bureau minimal. Et enfin, nous avons ajouté deux premiers paquets préférés: iceweasel et xchat. 858 Maintenant, construisez l'image: 859 860 # lb build
Notez que contrairement aux deux premiers tutoriels, nous n'avons plus besoin de taper 2>&1 | tee build.log parce que cela est maintenant inclus dans auto/build. 861 Une fois que vous avez testé l'image (comme dans Tutoriel 1) et vous ê tes satisfait de son fonctionnement, il est temps d'initialiser notre dépôt git, en n'ajoutant que les scripts auto que nous avons juste cré&#233;s, puis de faire le premier commit: 862 863 $ git init
   $ cp /usr/share/doc/live-build/examples/gitignore .gitignore
   $ git add .
   $ git commit -m "Initial import."
18.4.2 Deuxième révision 864 Dans cette révision, nous allons nettoyer à partir de la première construction, ajouter le paquet vlc à notre configuration, reconstruire, tester et faire le commit. 865 La commande lb clean va nettoyer tous les fichiers générés par la construction précédente à l'exception du cache, ce qui é vite d'avoir à retélécharger les paquets. Cela garantit que la commande lb build suivante exécutera à nouveau toutes les é tapes pour régénérer les fichiers de notre nouvelle configuration. 866 867 # lb clean
Ajoutez maintenant le paquet vlc à votre liste de paquets locaux dans config/package-lists/my.list.chroot: 868 869 $ echo vlc > > config/package-lists/my.list.chroot
Construisez à nouveau: 870 871 # lb build
Testez et, quand vous ê tes satisfait, faites le commit de la prochaine révision: 872 873 $ git commit -a -m "Ajout du lecteur de média vlc."
Bien sür, des changements plus compliqués de la configuration sont possibles, comme l'ajout de fichiers dans les sous-répertoires de config/. Quand vous livrez de nouvelles révisions, prenez soin de ne pas modifier à la main ou d'envoyer dans le dépôt les fichiers de niveau supérieur dans config contenant les variables LB_*, car ce sont aussi des produits de lacreation et ils sont toujours nettoyés par lb clean et recré&#233;s avec lb config via leurs scripts auto respectifs. 874 Nous sommes arrivés à la fin de notre série de tutoriels. Alors que de nombreux types de personnalisations sont possibles, même en n'utilisant que les fonctionnalités explorées dans ces exemples simples, une variété presque infinie d'images différentes peut ê tre crée. Les autres exemples de cette section couvrent plusieurs autres cas d'utilisation tirés des expériences recueillies chez les utilisateurs des systèmes live. 875 18.5 Un client kioske VNC 876 Cas d'utilisation: Créer une image avec live-build pour démarrer directement sur un serveur VNC. 877 Créez un répertoire de construction et créez une configuration à l'intérieur, désactivez « recommends» pour faire un système minimal. Puis créez deux listes initiales de paquets: la première générée par un script fourni par live-build nommée Packages (voir Générer listes de paquets), et la seconde incluant xorg, gdm3, metacity et xvnc4viewer. 878 879 $ mkdir vnc-kiosk-client
   $ cd vnc-kiosk-client
   $ lb config -a i386 -k 686-pae --apt-recommends false
   $ echo '! Packages Priority standard' > config/package-lists/standard.list.chroot
   $ echo "xorg gdm3 metacity xvnc4viewer" > config/package-lists/my.list.chroot
Comme il est expliqué dans Régler APT pour é conomiser de l'espace, il se peut que vous deviez ajouter quelques paquets recommandés pour faire fonctionner votre image correctement. 880 Une façon facile d'énumérer les paquets recommendés est d'utiliser apt-cache. Par exemple: 881 882 $ apt-cache depends live-config live-boot
Dans cet exemple, nous avons découvert que nous devions ré-inclure plusieurs paquets recommandés par live-config et live-boot: user-setup pour l'autologin et sudo un logiciel essentiel pour arrêter le système. En outre, il pourrait ê tre utile d'ajouter live-tools pour copier l'image dans la RAM et eject pour é jecter le support live. Alors: 883 884 $ echo "live-tools user-setup sudo eject" > config/package-lists/recommends.list.chroot
Après cela, créez le répertoire /etc/skel dans config/includes.chroot avec un fichier .xsession personnalisé pour l'utilisateur par défaut qui va lancer metacity et xvncviewer, en reliant le port 5901 sur un serveur à 192.168.1.2: 885 886 $ mkdir -p config/includes.chroot/etc/skel
   $ cat > config/includes.chroot/etc/skel/.xsession < < EOF
   #!/bin/sh
&lt;br />   /usr/bin/metacity &&lt;br />   /usr/bin/xvncviewer 192.168.1.2:1
&lt;br />   exit
   EOF
Construire l'image: 887 888 # lb build
Amusez-vous bien! 889 18.6 Une image de base pour une clé USB de 128 Mo 890 Cas d'utilisation: Créer une image par défaut avec certains composants supprimés afin de l'adapter sur une clé USB de 128 Mo avec un peu d'espace laissé pour l'utiliser à votre convenance. 891 Pour l'optimisation d'une image adaptée à la dimension de certains supports, vous avez besoin de comprendre le compromis que vous faites entre la taille et la fonctionnalité. Dans cet exemple, nous ne réduisons la taille que pour faire place aux é léments supplémentaires dans la limite de 128 Mo, mais en é vitant de détruire l'intégrité des paquets contenus, telle que la purge des données de localisation via le paquet localepurge, ou d'autres optimisations "intrusives". On notera en particulier que nous utilisons --debootstrap-options pour créer un système minimal à partir de zéro. 892 893 $ lb config --apt-indices false --apt-recommends false --debootstrap-options "--variant=minbase" --firmware-chroot false --memtest none
Pour faire que l'image fonctionne correctement, nous devons ajouter à nouveau au moins deux paquets recommandés qui sont laissés de côté par l'option --apt-recommends false. Voir Régler APT pour é conomiser de l'espace 894 895 $ echo "user-setup sudo" > config/package-lists/recommends.list.chroot
Maintenant, construisez l'image de la manière habituelle: 896 897 # lb build 2>&1 | tee build.log
Sur le système de l'auteur au moment de l'écriture, la configuration ci-dessus produisait une image de 110 Mo. Cela se compare favorablement avec l'image de 192 Mo produite par la configuration par défaut dans Tutoriel 1. 898 Laisser tomber les index d'APT avec --apt-indices false permet aussi d'économiser une bonne quantité d'espace, le compromis é tant que vous devez faire apt-get update avant d'utiliser apt dans le système live. Abandonner les paquets recommandés avec --apt-recommends false é conomise de l'espace supplémentaire, au détriment de certains paquets dont vous vous attendriez autrement qu'ils soient là. --debootstrap-options "--variant=minbase" construit un système minimal dès le début. L'utilisation de --firmware-chroot false n'inclut pas automatiquement les paquets de micrologiciels. Finalement, --memtest none prévient l'installation d'un testeur de mémoire. 899 Remarque: Un système minimal peut é galement ê tre obtenu en utilisant des hooks comme par exemple le stripped.hook.chroot dans /usr/share/doc/live-build/examples/hooks, il peut gagner de petites quantités supplémentaires d'espace et produire une image de 91 Mo. Cependant, il le fait par l'élimination de la documentation et d'autres fichiers des paquets installés sur le système. Cela porte atteinte à l'intégrité de ces paquets et, comme averti par le commentaire d'en-tête, cela peut avoir des conséquences imprévues. C'est pourquoi l'utilisation de debootstrap est la méthode recommandée pour atteindre cet objectif. 900 18.7 Un bureau GNOME localisé avec un installateur 901 Cas d'utilisation: Créer une image de bureau GNOME, localisée pour la Suisse et incluant un installateur. 902 Nous voulons faire une image iso-hybrid pour l'architecture i386 en utilisant notre bureau préféré, dans ce cas, GNOME, contenant tous les paquets qui seraient installés par l'installateur Debian standard pour GNOME. 903 Notre premier problème est la découverte des noms des tâches appropriées. Actuellement, live-build ne peut pas aider à faire cela. Alors que nous pourrions ê tre chanceux et trouver ces noms par essais et erreurs, il existe un outil, grep-dctrl, qui peut ê tre utilisé pour découvrir les descriptions des tâches dans tasksel-data. Pour la préparation, assurez-vous d'avoir ces deux outils: 904 905 # apt-get install dctrl-tools tasksel-data
Maintenant, nous pouvons rechercher les tâches appropriées, d'abord avec: 906 907 $ grep-dctrl -FTest-lang de /usr/share/tasksel/descs/debian-tasks.desc -sTask
   Task: german
Par cette commande, nous découvrons que la tâche est appelée, assez clairement, german. Maintenant, pour trouver les tâches liées: 908 909 $ grep-dctrl -FEnhances german /usr/share/tasksel/descs/debian-tasks.desc -sTask
   Task: german-desktop
   Task: german-kde-desktop
Pendant le démarrage, nous allons générer la locale de_CH.UTF-8 et sélectionner la disposition de clavier ch. Maintenant, nous allons mettre les morceaux ensemble. En nous rappelant grâce à Utilisation des métapaquets que les métapaquets sont préfixés task-, nous précisons ces paramètres de la langue pendant l'amorçage, puis nous ajoutons les paquets de priorité standard et tous nos métapaquets découverts à notre liste de paquets comme suit: 910 911 $ mkdir live-gnome-ch
   $ cd live-gnome-ch
   $ lb config \
    &#160;&#160;&#160;&#160;-a i386 \
    &#160;&#160;&#160;&#160;--bootappend-live "boot=live components locales=de_CH.UTF-8 keyboard-layouts=ch" \
    &#160;&#160;&#160;&#160;--debian-installer live
   $ echo '! Packages Priority standard' > config/package-lists/standard.list.chroot
   $ echo task-gnome-desktop task-german task-german-desktop > > config/package-lists/desktop.list.chroot
   $ echo debian-installer-launcher > > config/package-lists/installer.list.chroot
Notez que nous avons inclus le paquet debian-installer-launcher pour lancer l'installateur à partir du bureau live. Le noyau 586, qui est actuellement nécessaire pour faire que le lanceur fonctionne correctement, est inclus par défaut. 912 Appendix 913 Guide de style 914 19. Guide de style 915 19.1 Lignes directrices pour les auteurs 916 Cette section traite des considérations générales à prendre en compte lors de la rédaction de la documentation technique pour live-manual. Elles sont divisées en caractéristiques linguistiques et en procédures recommandées. 917 Remarque: Les auteurs doivent lire d'abord Contribuer à ce document 918 19.1.1 Caractéristiques linguistiques 919 Utilisez un anglais simple 920 Gardez à l'esprit qu'un pourcentage é levé de vos lecteurs ne sont pas de langue maternelle anglaise. Donc, en règle générale, essayez d'utiliser des phrases significatives courtes, suivies d'un point. 921 Cela ne signifie pas que vous devez utiliser un style naïf et simpliste. Il s'agit d'une suggestion pour essayer d'éviter, autant que possible, phrases subordonnées complexes qui rendent le texte difficile à comprendre pour les locuteurs non natifs de l'anglais. 922 Variété de l'anglais 923 Les variétés les plus répandues de l'anglais sont la britannique et l'américain, donc il est très probable que la plupart des auteurs utilisent l'un ou l'autre. Dans un environnement collaboratif, la variété idéale serait « l'anglais international», mais il est très difficile, pour ne pas dire impossible, de se prononcer sur quelle variété parmi toutes celles qui existent déjà, est la meilleure à utiliser. 924 Nous croyons que les différentes variétés peuvent se mélanger sans créer incompréhensions, mais en termes généraux, vous devriez essayer d'être cohérent et avant de décider entre britannique, américain ou toute autre variété anglaise à votre discrétion, s'il vous plaît jeter un oeil à la façon dont d'autres gens é crivent et essayer de les imiter. 925 Soyez é quilibré 926 Ne soyez pas partial. É vitez d'inclure des références à des idéologies totalement é trangères à live-manual. L'écriture technique doit ê tre aussi neutre que possible. Il est dans la nature même de l'écriture scientifique. 927 Soyez politiquement correct 928 Essayez d'éviter un langage sexiste autant que possible. Si vous avez besoin de faire référence à la troisième personne du singulier, de préférence utilisez « they» plutôt que « he» ou « she» ou inventions maladroites telles que « s/he», « s(he)», etc. 929 Soyez concis 930 Allez droit au but et ne pas errer sans but. Donner autant d'informations que nécessaire, mais ne donnez pas plus d'informations que nécessaire, c'est-à-dire, ne pas expliquer les détails inutiles. Vos lecteurs sont intelligents. Présumez une certaine connaissance préalable de leur part. 931 Minimiser le travail de traduction 932 Gardez à l'esprit que ce que vous é crivez devra ê tre traduit dans plusieurs autres langues. Cela implique qu'un certain nombre de gens devront faire un travail supplémentaire si vous ajoutez des informations inutiles ou redondantes. 933 Soyez cohérent 934 Comme suggéré précédemment, il est presque impossible de normaliser un document collaboratif dans un ensemble parfaitement unifié. Cependant, tous les efforts de votre côté pour é crire d'une manière cohérente avec le reste des auteurs seront appréciés. 935 Soyez cohésive 936 Utilisez autant de dispositifs de formation de texte que nécessaire pour rendre votre texte cohésive et sans ambiguïtés. (Les dispositifs de formation de texte sont des marqueurs linguistiques tels que les connecteurs). 937 Soyez descriptif 938 Il est préférable de décrire le point en une ou plusieurs paragraphes que simplement en utilisant un certain nombre de phrases dans un style typique "changelog". Décrivez-le! Vos lecteurs apprécieront ç a. 939 Dictionnaire 940 Cherchez le sens des mots dans un dictionnaire ou une encyclopédie si vous ne savez pas comment exprimer certaines notions en anglais. Mais gardez à l'esprit qu'un dictionnaire peut ê tre votre meilleur ami ou peut se transformer en votre pire ennemi si vous ne savez pas comment l'utiliser correctement. 941 L'anglais possède le plus grand vocabulaire qui existe (avec plus d'un million de mots). Beaucoup de ces mots sont des emprunts d'autres langues. Lorsque l'on regarde le sens des mots dans un dictionnaire bilingue, la tendance d'un locuteur non natif de l'anglais est de choisir celui qui sonne plus similaire dans leur langue maternelle. Cela se transforme souvent en un discours excessivement formelle qui ne semble pas tout à fait naturel en anglais. 942 En règle générale, si un concept peut ê tre exprimé en utilisant différents synonymes, c'est un bon conseil choisir le premier mot proposé par le dictionnaire. En cas de doute, le choix des mots d'origine germanique (Habituellement mots monosyllabiques) est souvent la bonne chose à faire. Il faut savoir que ces deux techniques peuvent produire un discours plutôt informel, mais au moins votre choix des mots sera d'utilisation grand et généralement accepté. 943 L'utilisation d'un dictionnaire de collocations est recommandé. Ils sont extrêmement utiles quand il s'agit de savoir quels mots surviennent généralement ensemble. 944 Encore une fois, c'est une bonne pratique apprendre à partir du travail des autres. Grâce à un moteur de recherche pour vérifier comment les autres auteurs utilisent certaines expressions peut aider beaucoup. 945 Faux amis, expressions idiomatiques et autres expressions 946 Attention aux faux amis. Peu importe comment vous ê tes compétent dans une langue é trangère, vous ne pouvez pas vous empêcher de tomber de temps en temps dans le piège de ce qu'on appelle les « faux amis», des mots qui se ressemblent dans les deux langues, mais dont les significations ou les utilisations pourrait ê tre complètement différent. 947 Essayez d'éviter les expressions idiomatiques autant que possible. Les expressions idiomatiques sont des expressions qui peuvent transmettre un sens complètement différent de ce que leurs mots individuels semblent signifier. Parfois, les expressions idiomatiques peuvent ê tre difficiles à comprendre, même pour les locuteurs natifs de l'anglais! 948 Évitez l'argot, les abréviations, les contractions... 949 Même si vous ê tes encouragés à utiliser un langage simple, l'anglais de tous les jours, la rédaction technique appartient au registre formel de la langue. 950 Essayez d'éviter l'argot, abréviations inhabituels qui sont difficiles à comprendre et surtout les contractions qui tentent d'imiter le langage parlé. Sans oublier typique expressions d'irc et favorables à la famille. 951 19.1.2 Procédures 952 Tester avant d'écrire 953 Il est important que les auteurs testent leurs exemples avant de les ajouter à live-manual pour s'assurer que tout fonctionne comme décrit. Tester sur ​​un chroot propre ou une machine virtuelle peut ê tre un bon point de départ. Par ailleurs, il serait idéal si les tests ont ensuite é té effectués sur des machines différentes avec un matériel différent pour repérer d'éventuels problèmes qui pourraient survenir. 954 Exemples 955 En fournissant un exemple essayer d'être aussi précis que possible. Un exemple est, après tout, juste un exemple. 956 Il est souvent préférable d'utiliser une ligne qui ne s'applique qu'à un cas particulier que l'utilisation d'abstractions qui peuvent confondre vos lecteurs. Dans ce cas, vous pouvez fournir une brève explication des effets de l'exemple proposé. 957 Il peut y avoir des exceptions lorsque l'exemple suggère d'utiliser certaines commandes potentiellement dangereuses qui, si elles sont mal utilisées, peuvent causer des pertes de données ou d'autres effets indésirables similaires. Dans ce cas, vous devez fournir une explication approfondie des effets secondaires possibles. 958 Liens externes 959 Les liens externes ne doivent ê tre utilisés lorsque l'information sur ces sites est cruciale quand il s'agit de comprendre un point particulier. Même si, essayez d'utiliser des liens externes aussi peu que possible. Les liens internet sont susceptibles de changer de temps en temps résultant en des liens brisés et en laissant vos arguments dans un é tat incomplet. 960 D'ailleurs, les gens qui lisent le manuel hors ligne n'auront pas la chance de suivre ces liens. 961 Évitez les marques et les choses qui violent la licence sous laquelle le manuel est publié 962 Essayez d'éviter les marques autant que possible. Gardez à l'esprit que d'autres projets peuvent utiliser la documentation que vous é crivez. Donc, vous compliquez les choses pour eux si vous ajoutez certaines matières spécifiques. 963 live-manual est sous la licence GNU GPL. Cela a un certain nombre de conséquences qui s'appliquent à la distribution de la matière (de toute nature, y compris les graphiques ou logos protégées) qui est publiée avec le manuel. 964 Ecrire un premier projet, réviser, modifier, améliorer, refaire si nécessaire 965 - Remue-méninges!. Vous devez organiser vos idées d'abord dans une séquence logique des é vénements. 966 - Une fois que vous avez en quelque sorte organisé ces idées dans votre esprit é crire un premier projet. 967 - Réviser la grammaire, la syntaxe et l'orthographe. Gardez à l'esprit que les noms propres des versions, tels que buster ou sid, ne doivent pas ê tre capitalisés lorsqu'ils sont utilisés comme noms de code. Pour vérifier l'orthographe, on peut exécuter la cible "spell". C'est à dire, make spell 968 - Améliorer vos phrases et refaire n'importe quelle partie si nécessaire. 969 Chapitres 970 Utilisez le système de numérotation classique des chapitres et sous-titres. Par exemple 1, 1.1, 1.1.1, 1.1.2 ... 1.2, 1.2.1, 1.2.2 ... 2, 2.1 ... et cetera. Voir marqueurs ci-dessous. 971 Si vous avez d'énumérer une série d'étapes ou phases dans votre description, vous pouvez é galement utiliser des nombres ordinaux: premier, deuxième, troisième ... ou d'abord, puis, après cela, enfin ... Sinon, vous pouvez utiliser les é léments à puces. 972 Balisage 973 Et finalement, live-manual utilise SiSU pour traiter les fichiers texte et pour produire plusieurs formats. Il est recommandé de consulter le manuel SiSU pour se familiariser avec son balisage, ou bien tapez: 974 975 $ sisu --help markup
Voici quelques exemples de balisage qui peuvent é ventuellement vous aider: 976 - Pour accent/texte en gras: 977 978 *{foo}* or !{foo}!
il produit: foo or foo. Utiliser pour mettre l'accent sur certains mots-clés. 979 - Pour italique: 980 981 /{foo}/
il produit: foo. Utiliser par exemple, pour les noms des paquets Debian. 982 - Pour monospace: 983 984 #{foo}#
il produit: foo. Utiliser par exemple, pour les noms des commandes. Et aussi pour souligner certains mots clés ou des choses comme les chemins. 985 - Pour les blocs de code: 986 987 code{
&lt;br />    &#160;$ foo
    &#160;# bar
&lt;br />   }code
il produit: 988 989 $ foo
   # bar
Utilisez code{ pour ouvrir et }code pour fermer les balises. Il est important de se rappeler de laisser un espace au début de chaque ligne de code. 990 19.2 Lignes directrices pour les traducteurs 991 Cette section traite des considérations générales à prendre en compte lors de la traduction du contenu du live-manual. 992 Comme recommandation générale, les traducteurs doivent avoir lu et compris les règles de traduction qui s'appliquent à leurs langues spécifiques. Habituellement, les groupes de traduction et listes de diffusion fournissent des informations sur la façon de produire un travail de traduction qui respecte les normes de qualité de Debian. 993 Remarque: Les traducteurs doivent aussi lire Contribuer à ce document. En particulier, la section Traduction 994 19.2.1 Conseils de traduction 995 Commentaires 996 Le rôle du traducteur est de transmettre le plus fidèlement possible le sens des mots, des phrases, des paragraphes et des textes comme é crit par les auteurs originaux dans leur langue cible. 997 Donc, ils devraient s'abstenir d'ajouter des commentaires personnels ou des morceaux d'informations supplémentaires de leur propre chef. S'ils veulent ajouter un commentaire pour d'autres traducteurs travaillant sur les mêmes documents, ils peuvent le laisser dans l'espace réservé pour cela. Autrement dit, l'en-tête des chaînes dans les fichiers po précédés d'un signe #. Nombreuses logiciels de traduction graphiques peuvent gérer automatiquement ces types de commentaires. 998 NDT, Note Du Traducteur 999 Il est parfaitement acceptable cependant, inclure un mot ou une expression entre parenthèses dans le texte traduit si, et seulement si, cela fait le sens d'un mot ou d'une expression difficile plus clair pour le lecteur. A l'intérieur des parenthèses, le traducteur doit mettre en é vidence que l'addition a é té leur en utilisant l'abréviation "NDT" ou "Note Du Traducteur ". 1000 Phrases impersonnelles 1001 Les documents é crits en anglais font une utilisation intensive de la forme impersonnelle "you". Dans d'autres langues qui ne partagent pas cette caractéristique, ce pourrait donner la fausse impression que les textes originaux traitent directement le lecteur quand en réalité ils ne le font pas. Les traducteurs doivent ê tre conscients de ce fait et traduir dans leur langue le plus fidèlement que possible. 1002 Faux amis 1003 Le piège des "faux amis" expliqué avant s'applique surtout aux traducteurs. Vérifiez le sens des faux amis suspectes en cas de doute. 1004 Balisage 1005 Les traducteurs qui travaillent d'abord avec les fichiers pot et plus tard avec les fichiers po trouveront de nombreuses caractéristiques de balisage dans les chaînes. Ils peuvent traduire le texte de toute façon, tant qu'il est traduisible, mais il est extrêmement important qu'ils utilisent exactement le même balisage que la version originale anglaise. 1006 Blocs de code 1007 Même si les blocs de code sont généralement intraduisibles, les inclure dans la traduction est la seule façon d'obtenir une traduction complète 100%. Et même si cela signifie plus de travail au début car ç a peut exiger l'intervention des traducteurs si le code change, il est le meilleur moyen, à long terme, d'identifier ce qui a déjà é té traduit et ce qui n'a pas, lors de la vérification de l'intégrité des fichiers .po. 1008 Sauts de ligne 1009 Les textes traduits doivent avoir les mêmes sauts de lignes exactes que les textes originaux. Veillez appuyer sur "Entrée" ou tapez \n si elles apparaissent dans les fichiers originaux. Ces nouvelles lignes apparaissent souvent, par exemple, dans les blocs de code. 1010 Ne vous méprenez pas, cela ne signifie pas que le texte traduit doit avoir la même longueur que la version anglaise. C'est presque impossible. 1011 Chaînes intraduisibles 1012 Les traducteurs ne doivent jamais traduire: 1013 - Les noms de code des versions (qui doivent ê tre é crits en minuscules) 1014 - Les noms des logiciels 1015 - Les commandes fournies à titre d'exemples 1016 - Métadonnées (souvent entre deux points :metadata:) 1017 - Liens 1018 - Les chemins 1019