Debian Live Manual Debian Live Project <debian-live@lists.debian.org>

Rights: Copyright: Copyright (C) 2006-2015 Live Systems Project, Copyright (C) 2016-2026 The Debian Live team
License: This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/.
The complete text of the GNU General Public License can be found in /usr/share/common-licenses/GPL-3 file.

# Debian Live Manual

# À propos

# À propos de ce manuel

#### 1. À propos de ce manuel

##### 1.1 Pour les impatients

##### 1.2 Terminologie

##### 1.3 Auteurs

##### 1.4 Contribuer à ce document

###### 1.4.1 Appliquer des modifications

###### 1.4.2 Traduction

# À propos du Debian Live Project

#### 2. À propos du Debian Live Project

##### 2.1 Motivation

###### 2.1.1 Ce qui ne va pas avec les systèmes live actuels

###### 2.1.2 Pourquoi créer notre propre système live?

##### 2.2 Philosophie

###### 2.2.1 Only unchanged packages from Debian "main" and "non-free-firmware"

###### 2.2.2 Pas de configuration des paquets du système live

##### 2.3 Contact

# Utilisateur

# Installation

#### 3. Installation

##### 3.1 Exigences

##### 3.2 Installation de live-build

###### 3.2.1 À partir du dépôt Debian

###### 3.2.2 À partir du code source

##### 3.3 Installation de live-boot et live-config

###### 3.3.1 À partir du dépôt Debian

###### 3.3.2 À partir du code source

# Les bases

#### 4. Les bases

##### 4.1 Qu'est-ce qu'un système live?

##### 4.2 Téléchargement des images précompilées

##### 4.3 Premières étapes: la construction d'une image ISO hybride

##### 4.4 Utilisation d'une image ISO hybride live

###### 4.4.1 Graver une image ISO sur un support physique

###### 4.4.2 Copie d'une image ISO hybride sur une clé USB

###### 4.4.3 Utilisation de l'espace disponible sur une clé USB

###### 4.4.4 Démarrer le support live

##### 4.5 Utiliser une machine virtuelle pour les tests

###### 4.5.1 Test d'une image ISO avec QEMU

###### 4.5.2 Test d'une image ISO avec VirtualBox

##### 4.6 Construire et utiliser une image HDD

##### 4.7 Construction d'une image netboot

###### 4.7.1 Serveur DHCP

###### 4.7.2 Serveur TFTP

###### 4.7.3 Serveur NFS

###### 4.7.4 Guide pratique pour expérimenter avec une image Netboot

###### 4.7.5 Qemu

##### 4.8 Webbooting

###### 4.8.1 Obtenir les fichiers webboot

###### 4.8.2 Démarrer images webboot

# Aperçu des outils

#### 5. Aperçu des outils

##### 5.1 Le paquet live-build

###### 5.1.1 La commande `lb config`

###### 5.1.2 La commande `lb build`

###### 5.1.3 La commande `lb clean`

##### 5.2 Le paquet live-boot

##### 5.3 Le paquet live-config

# Gestion d'une configuration

#### 6. Gestion d'une configuration

##### 6.1 Gérer les modifications de la configuration

###### 6.1.1 Pourquoi utiliser des scripts auto? Que font-ils?

###### 6.1.2 Utiliser les scripts auto d'exemple

##### 6.2 Cloner une configuration publiée via Git

# Personnalisation des contenus

#### 7. Vue d'ensemble de la personnalisation

##### 7.1 Configuration pendant la construction vs. l'amorçage

##### 7.2 Étapes de la construction

##### 7.3 Supplément lb config avec des fichiers

##### 7.4 Tâches de personnalisation

# Personnalisation de l'installation de paquets

#### 8. Personnalisation de l'installation de paquets

##### 8.1 Sources des paquets

###### 8.1.1 Distribution, zones d'archive et mode

###### 8.1.2 Miroirs de distribution

###### 8.1.3 Miroirs de distribution utilisés lors de la construction

###### 8.1.4 Miroirs de distribution utilisés pendant l'exécution

###### 8.1.5 Dépôts additionnels

##### 8.2 Choisir les paquets à installer

###### 8.2.1 Listes de paquets

###### 8.2.2 Utilisation des métapaquets

###### 8.2.3 Listes de paquets locaux

###### 8.2.4 Listes de paquets locaux pour l'étape binary

###### 8.2.5 Listes de paquets générées

###### 8.2.6 Utiliser des conditions dans les listes de paquets

###### 8.2.7 Suppression de paquets lors de l'installation

###### 8.2.8 Summary

###### 8.2.9 Tâches de bureau et de langue

###### 8.2.10 Version et type de noyau

###### 8.2.11 Noyaux personnalisés

##### 8.3 Installation de paquets modifiés ou tiers

###### 8.3.1 Utiliser `packages.chroot` pour installer des paquets personnalisés

###### 8.3.2 Utiliser un dépôt APT pour installer des paquets personnalisés.

###### 8.3.3 Les paquets personnalisés et APT

##### 8.4 Configuration d'APT pendant la construction

###### 8.4.1 Choisir apt ou aptitude

###### 8.4.2 Utilisation d'un proxy avec APT

###### 8.4.3 Régler APT pour économiser de l'espace

###### 8.4.4 Passer des options à apt ou aptitude

###### 8.4.5 APT pinning

# Personnalisation des contenus

#### 9. Personnalisation des contenus

##### 9.1 Includes

###### 9.1.1 Live/chroot local includes

###### 9.1.2 Binary local includes

##### 9.2 Hooks

###### 9.2.1 Chroot local hooks

###### 9.2.2 Binary local hooks

###### 9.2.3 Hooks pendant le démarrage

##### 9.3 Préconfigurer questions de debconf

# Personnalisation des comportements pendant l'exécution

#### 10. Personnalisation des comportements pendant l'exécution

##### 10.1 Personnalisation de l'utilisateur live

##### 10.2 Personnalisation des paramètres régionaux et de la langue

##### 10.3 Persistance

###### 10.3.1 Le fichier persistence.conf

###### 10.3.2 Utilisation de plusieurs dispositifs de persistance

###### 10.3.3 Utilisation de la persistance avec chiffrement

# Personnalisation de l'image binaire

#### 11. Personnalisation de l'image binaire

##### 11.1 Chargeurs d'amorçage

##### 11.2 Métadonnées ISO

# Personnalisation de l'installateur Debian

#### 12. Personnalisation du contenu pour l'installateur Debian

##### 12.1 Types d'installateur Debian

##### 12.2 Personnalisation de l'installateur Debian par préconfiguration

##### 12.3 Personnalisation de contenu pour l'Installateur Debian

# Projet

# Contribuer au projet

#### 13. Contribuer au projet

##### 13.1 Traduction des pages de manuel

# Signaler des bogues

#### 14. Signaler des bogues

##### 14.1 Problèmes connus

##### 14.2 Effectuer une recherche

##### 14.3 Reconstruire à partir de zéro

##### 14.4 Utiliser des paquets mis à jour

##### 14.5 Recueillir l'information

##### 14.6 Isoler le cas qui échoue, si possible

##### 14.7 Utiliser le paquet adéquat pour rapporter un bogue

###### 14.7.1 Pendant la construction durant l'amorçage

###### 14.7.2 Pendant la construction durant l'installation de paquets

###### 14.7.3 Pendant le démarrage

###### 14.7.4 Pendant l'exécution

##### 14.8 Où rapporter les bogues

# Style de code

#### 15. Style du code

##### 15.1 Compatibilité

##### 15.2 Indentation

##### 15.3 Adaptateur

##### 15.4 Variables

##### 15.5 Autres

# Exemples

#### 16. Exemples

##### 16.1 Utiliser les exemples

##### 16.2 Tutoriel 1: Une image par défaut

##### 16.3 Tutoriel 2: Un utilitaire d'un navigateur Web

##### 16.4 Tutoriel 3: Une image personnalisée

###### 16.4.1 Première révision

###### 16.4.2 Deuxième révision

##### 16.5 Un client kioske VNC

##### 16.6 A minimal image for a 512MB USB key

##### 16.7 Un bureau GNOME localisé avec un installateur

# Appendix

# Guide de style

#### 17. Guide de style

##### 17.1 Lignes directrices pour les auteurs

###### 17.1.1 Caractéristiques linguistiques

###### 17.1.2 Procédures

##### 17.2 Lignes directrices pour les traducteurs

###### 17.2.1 Conseils de traduction

1

# Debian Live Manual

2

# À propos

3

# À propos de ce manuel

4

#### 1. À propos de ce manuel

5

This manual serves as a single access point to all documentation related to the Debian Live Project and in particular applies to the software produced by the project for the Debian "bookworm" release. An up-to-date version can always be found at ‹https://live-team.pages.debian.net/live-manual/›

6

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.

7

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.

8

##### 1.1 Pour les impatients

9

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.

10

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.

11

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 enthousiaste 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.

12

##### 1.2 Terminologie

13

- 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. Habituellement, 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).

14

- 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.

15

- Debian Live Project: Le projet qui maintient, entre autres, les paquets live-boot, live-build, live-config live-tools et live-manual.

16

- Système hôte: L'environnement utilisé pour créer le système live.

17

- Système cible: L'environnement utilisé pour faire fonctionner le système live.

18

- live-boot: Une collection de scripts utilisés pour lancer des systèmes live.

19

- live-build: Une collection de scripts utilisés pour construire des systèmes live personnalisés.

20

- live-config: Une collection de scripts utilisés pour configurer un système live pendant le processus d'amorçage.

21

- live-tools: Une collection de scripts supplémentaires utilisés pour effectuer des tâches utiles dans un système live en fonctionnement.

22

- live-manual: Ce document est maintenu dans un paquet nommé live-manual.

23

- Debian Installer (d-i): Le système d'installation officiel pour la distribution Debian.

24

- 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.

25

- 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.

26

- Binary image: A file containing the live system, such as live-image-amd64.hybrid.iso or live-image-amd64.img.

27

- 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.

28

- stable/testing/unstable: La distribution stable, actuellement nommée bookworm, contient la dernière version officielle de Debian. La distribution testing, temporairement nommée trixie, 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 trixie ou sid, car c'est ce qui est pris en charge par les outils eux-mêmes.

29

##### 1.3 Auteurs

30

La liste des auteurs (dans l'ordre alphabétique):

31

- Ben Armstrong

32

- Brendan Sleight

33

- Carlos Zuferri

34

- Chris Lamb

35

- Daniel Baumann

36

- Franklin Piat

37

- Jonas Stein

38

- Kai Hendry

39

- Marco Amadori

40

- Mathieu Geli

41

- Matthias Kirschner

42

- Richard Nelson

43

- Roland Clobus

44

- Trent W. Buck

45

##### 1.4 Contribuer à ce document

46

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).

47

###### 1.4.1 Appliquer des modifications

48

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:

49

# apt-get install make po4a ruby ruby-nokogiri sisu-complete

50

Vous pouvez compiler live-manual dans le répertoire de niveau supérieur de votre Git checkout en exécutant:

51

$ make build

52

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:

53

$ make build PROOF=1

54

Lors de la révision d'une des traductions, il est possible de construire une seule langue en exécutant, par exemple:

55

$ make build LANGUAGES=de

56

Il est également possible de construire par type de document, par exemple,

57

$ make build FORMATS=pdf

58

Ou combiner les deux, par exemple:

59

$ make build LANGUAGES=de FORMATS=html

60

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.

61

###### 1.4.2 Traduction

62

Note: Pour la traduction des pages de manuel, voir Traduction des pages de manuel

63

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:

64

- Commencer une nouvelle traduction à partir de zéro

65

- 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.

66

- Once checked, to enable a new language in the autobuild it is enough to add the initial translated files to `manual/po/${LANGUAGE}/` and edit `manual/_sisu/home/index.html` adding the name of the language and its name in English between brackets. And then, add the folder `manual/${LANGUAGE}/` to the file `.gitignore`. Finally, run `make commit`.

67

- Continuer avec une traduction déjà commencée

68

- 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) .

69

- 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

70

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.

71

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.

72

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.

73

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.

74

# À propos du Debian Live Project

75

#### 2. À propos du Debian Live Project

76

##### 2.1 Motivation

77

###### 2.1.1 Ce qui ne va pas avec les systèmes live actuels

78

When Debian Live Project was initiated (around 2006), there were already several Debian based live systems available and they are doing a great job. From the Debian perspective most of them have one or more of the following disadvantages:

79

- Ce ne sont pas des projets Debian et ils manquent donc de soutien au sein de Debian.

80

- Ils mélangent des distributions différentes comme testing et unstable.

81

- Ils ne prennent en charge que i386.

82

- Ils modifient le comportement et/ou l'apparence des paquets en les dépouillant pour économiser de l'espace.

83

- Ils comprennent des paquets ne provenant pas de l'archive Debian.

84

- Ils offrent des noyaux personnalisés avec des correctifs supplémentaires qui ne font pas partie de Debian.

85

- Ils sont gros et lents en raison de leur dimension et donc pas recommandés comme systèmes de sauvetage.

86

- Ils ne sont pas disponibles en différents formats (CDs, DVDs, clés USB et images netboot).

87

###### 2.1.2 Pourquoi créer notre propre système live?

88

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:

89

- C'est un sous-projet de Debian.

90

- Il reflète l'état (actuel) d'une distribution.

91

- Il fonctionne sur le plus grand nombre d'architectures possible.

92

- Il ne se compose que de paquets Debian inchangés.

93

- Il ne contient pas de paquets qui n'appartiennent pas à l'archive Debian.

94

- Il utilise un noyau Debian inchangé, sans correctifs supplémentaires.

95

##### 2.2 Philosophie

96

###### 2.2.1 Only unchanged packages from Debian "main" and "non-free-firmware"

97

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.

98

Starting with Debian 12 bookworm we added the "non-free-firmware" section for better support of modern hardware.

99

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.

100

À 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.

101

###### 2.2.2 Pas de configuration des paquets du système live

102

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.

103

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.

104

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.

105

##### 2.3 Contact

106

- Mailing list: The primary contact for the project is the mailing list at ‹https://lists.debian.org/debian-live/›. You can email the list directly by addressing your mail to ‹debian-live@lists.debian.org›​. The list archives are available at ‹https://lists.debian.org/debian-live/›.

107

- 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.

108

- BTS : Le Système de suivi des bogues (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.

109

# Utilisateur

110

# Installation

111

#### 3. Installation

112

##### 3.1 Exigences

113

Building live system images has very few system requirements for the host system:

114

- Accès super-utilisateur (root)

115

- Une version mise à jour de live-build

116

- Un shell POSIX, comme bash ou dash

117

- debootstrap

118

- Linux 2.6 or newer

119

- A mount point with dev and exec rights.

120

# mount <your_mount_point> -odev,exec,remount

121

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.

122

##### 3.2 Installation de live-build

123

Vous pouvez installer live-build d'un certain nombre de façons différentes:

124

- À partir du dépôt Debian

125

- À partir du code source

126

- À partir des instantanés

127

Si vous utilisez Debian, la méthode recommandée consiste à installer live-build à partir du dépôt Debian.

128

###### 3.2.1 À partir du dépôt Debian

129

Il suffit d'installer live-build comme n'importe quel autre paquet:

130

# apt-get install live-build

131

###### 3.2.2 À partir du code source

132

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:

133

$ git clone https://salsa.debian.org/live-team/live-build.git

134

Vous pouvez compiler et installer votre propre paquet Debian en exécutant:

135

$ cd live-build
$ dpkg-buildpackage -b -uc -us
$ cd ..

136

Maintenant, installez les fichiers récemment construits qui vous intéressent, par exemple

137

# dpkg -i live-build_4.0-1_all.deb

138

Vous pouvez également installer live-build directement sur votre système en exécutant:

139

# make install

140

et le désinstaller avec:

141

# make uninstall

142

##### 3.3 Installation de live-boot et live-config

143

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.

144

###### 3.3.1 À partir du dépôt Debian

145

live-boot et live-config sont tous les deux disponibles dans le dépôt Debian comme expliqué dans Installation de live-build.

146

###### 3.3.2 À partir du code source

147

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.

148

- Examiner les sources de live-boot et live-config

149

$ git clone https://salsa.debian.org/live-team/live-boot.git
$ git clone https://salsa.debian.org/live-team/live-config.git

150

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.

151

- Créer les fichiers .deb de live-boot et live-config

152

Vous devez créer sur votre distribution cible ou dans un chroot contenant votre plateforme cible: cela signifie que si votre cible est trixie alors vous devez créer sur trixie.

153

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 trixie, créez live-boot dans un chroot trixie. 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) :

154

$ cd live-boot
$ dpkg-buildpackage -b -uc -us
$ cd ../live-config
$ dpkg-buildpackage -b -uc -us

155

- Utiliser les fichiers .deb générés nécessaires.

156

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 de 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 :

157

$ cp ../live-boot{_,-initramfs-tools,-doc}*.deb config/packages.chroot/
$ cp ../live-config{_,-sysvinit,-doc}*.deb config/packages.chroot/

158

# Les bases

159

#### 4. Les bases

160

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.

161

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.

162

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.

163

##### 4.1 Qu'est-ce qu'un système live?

164

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).

165

With live systems, it's an operating system, built for one of the supported architectures (currently amd64 and arm64). It is made from the following parts:

166

- Image du noyau Linux, d'habitude appelé `vmlinuz*`

167

- 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.

168

- 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).

169

- 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.

170

You can use live-build to build the system image from your specifications, set up a Linux kernel, its initrd, and a bootloader to run them, all in one medium-dependent format (ISO9660 image, disk image, etc.).

171

##### 4.2 Téléchargement des images précompilées

172

You can download one of the prebuilt images from ‹https://www.debian.org/CD/live/›. For many of the popular desktop environments (GNOME, Xfce, KDE, etc.) a specific live image is prepared.

173

If you are unsure which file to download, use the 'Live GNOME' image from the 'stable' release. You can then skip reading the next sections and run the image in a virtual machine.

174

##### 4.3 Premières étapes: la construction d'une image ISO hybride

175

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.

176

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.

177

$ mkdir live-default && cd live-default

178

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:

179

$ lb config

180

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.

181

Maintenant que la hiérarchie "config/" existe, créez l'image avec la commande `lb build` :

182

# lb build

183

This process can take a while, depending on the speed of your computer and your network connection. When it is complete, there should be a `live-image-amd64.hybrid.iso` image file, ready to use, in the current directory.

184

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.

185

##### 4.4 Utilisation d'une image ISO hybride live

186

After either building or downloading an ISO hybrid image the usual next step is to prepare your medium for booting, either CD-R(W) or DVD-R(W) optical media or a USB stick.

187

###### 4.4.1 Graver une image ISO sur un support physique

188

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:

189

# apt-get install xorriso
$ xorriso -as cdrecord -v dev=/dev/sr0 blank=as_needed live-image-amd64.hybrid.iso

190

###### 4.4.2 Copie d'une image ISO hybride sur une clé USB

191

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`.

192

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é!

193

$ cp live-image-amd64.hybrid.iso ${USBSTICK}
$ sync

194

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.

195

###### 4.4.3 Utilisation de l'espace disponible sur une clé USB

196

After copying the `live-image-amd64.hybrid.iso` to a USB stick, the first partition on the device will be filled up by the live system. To use the remaining free space, use a partitioning tool such as gparted or parted to create a new partition on the stick.

197

# gparted ${USBSTICK}

198

Quand la partition est créé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.

199

# mkfs.ext4 ${PARTITION}

200

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.

201

Remember: Every time you install a new live-image-amd64.hybrid.iso on the stick, all data on the stick will be lost because the partition table is overwritten by the contents of the image, so back up your extra partition first to restore again after updating the live image.

202

###### 4.4.4 Démarrer le support live

203

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.

204

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.

205

Assuming you've selected `Live` and booted a default desktop live image, after the boot messages scroll by, you should be automatically logged into the `user` account and see a desktop, ready to use. If you have booted a console-only image, you should be automatically logged in on the console to the `user` account and see a shell prompt, ready to use.

206

##### 4.5 Utiliser une machine virtuelle pour les tests

207

Exécuter les images live dans une machine virtuelle (VM) peut faire gagner beaucoup de temps. Cela ne vient pas sans avertissements:

208

- 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é.

209

- 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é.

210

- 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.

211

- Certains ne deviennent visibles que pendant l'exécution dans une VM. En cas de doute, testez votre image directement sur le matériel.

212

À condition de pouvoir travailler avec ces contraintes, examinez les logiciels VM disponibles et choisissez celui qui convient à vos besoins.

213

###### 4.5.1 Test d'une image ISO avec QEMU

214

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.

215

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`.

216

# apt-get install qemu-kvm qemu-utils

217

Démarrer une image ISO est simple:

218

$ kvm -cdrom live-image-amd64.hybrid.iso -m 4G

219

Voir les pages de manuel pour plus de détails.

220

Note: For live systems containing a desktop environment that you want to test with qemu, you may wish to include the spice-vdagent package in your live-build configuration. This will automatically adjust the resolution and enable the clipboard between the virtual machine and the host.

221

$ echo "spice-vdagent" >> config/package-lists/spice.list.chroot

222

###### 4.5.2 Test d'une image ISO avec VirtualBox

223

Afin de tester l'ISO avec virtualbox:

224

# apt-get install virtualbox virtualbox-qt virtualbox-dkms
$ virtualbox

225

Create a new virtual machine, change the storage settings to use `live-image-amd64.hybrid.iso` as the CD/DVD device, and start the machine.

226

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.

227

$ echo "virtualbox-guest-dkms virtualbox-guest-x11" >> config/package-lists/my.list.chroot

228

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.

229

$ lb config --linux-packages "linux-image linux-headers"

230

##### 4.6 Construire et utiliser une image HDD

231

Building an HDD image is similar to an ISO hybrid one in all respects except you specify `-b hdd` and the resulting filename is `live-image-amd64.img` which cannot be burnt to optical media. It is suitable for booting from USB sticks, USB hard drives, and various other portable storage devices. Normally, an ISO hybrid image can be used for this purpose instead, but if you have a BIOS which does not handle hybrid images properly, you need an HDD image.

232

Remarque: si vous avez créé 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):

233

# lb clean --binary

234

Exécutez la commande `lb config` comme avant, sauf que cette fois en spécifiant le type d'image HDD:

235

$ lb config -b hdd

236

Construisez maintenant l'image avec la commande `lb build`

237

# lb build

238

When the build finishes, a `live-image-amd64.img` file should be present in the current directory.

239

The generated binary image contains a VFAT partition and the syslinux bootloader, ready to be directly written on a USB device. Once again, using an HDD image is just like using an ISO hybrid one on USB. Follow the instructions in Using an ISO hybrid live image, except use the filename `live-image-amd64.img` instead of `live-image-amd64.hybrid.iso`.

240

Likewise, to test an HDD image with Qemu, install qemu as described above in Testing an ISO image with QEMU. Then run `kvm` or `qemu`, depending on which version your host system needs, specifying `live-image-amd64.img` as the first hard drive.

241

$ kvm -hda live-image-amd64.img

242

##### 4.7 Construction d'une image netboot

243

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.

244

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`:

245

# lb clean

246

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).

247

Exécutez la commande suivante pour configurer votre image pour démarrer sur le réseau:

248

$ lb config -b netboot --net-root-path "/srv/debian-live" --net-root-server "192.168.0.2"

249

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.

250

Construisez maintenant l'image avec la commande `lb build`

251

# lb build

252

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.

253

For example, if you unpack the generated `live-image-amd64.netboot.tar` archive in the `/srv/debian-live` directory, you'll find the filesystem image in `live/filesystem.squashfs` and the kernel, initrd and pxelinux bootloader in `tftpboot/`.

254

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.

255

###### 4.7.1 Serveur DHCP

256

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.

257

Voici un exemple source d'inspiration, écrit pour le serveur ISC DHCP `isc-dhcp-server` dans le fichier de configuration `/etc/dhcp/dhcpd.conf`:

258

# /etc/dhcp/dhcpd.conf - configuration file for isc-dhcp-server
ddns-update-style none;
option domain-name "example.org";
option domain-name-servers ns1.example.org, ns2.example.org;
default-lease-time 600;
max-lease-time 7200;
log-facility local7;
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.1 192.168.0.254;
filename "pxelinux.0";
next-server 192.168.0.2;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.0.255;
option routers 192.168.0.1;
}

259

###### 4.7.2 Serveur TFTP

260

Cela sert le noyau et le ramdisk initial pour le système pendant l'exécution.

261

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:

262

# dpkg-reconfigure -plow tftpd-hpa

263

et remplissez le nouveau répertoire du serveur tftp

264

###### 4.7.3 Serveur NFS

265

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.

266

Vous devez installer le paquet nfs-kernel-server.

267

Ensuite, rendez l'image du système de fichiers disponible via NFS en ajoutant une ligne comme la suivante `/etc/exports`:

268

/srv/debian-live *(ro,async,no_root_squash,no_subtree_check)

269

et indiquez cette exportation au serveur NFS avec la commande suivante:

270

# exportfs -rv

271

Setting up these three services can be a little tricky. You might need some patience to get all of them working together. For more information, see the syslinux wiki at ‹https://wiki.syslinux.org/wiki/index.php?title=PXELINUX› or the Debian Installer Manual's TFTP Net Booting section at ‹https://www.debian.org/releases/stable/amd64/ch04s05.en.html›. They might help, as their processes are very similar.

272

###### 4.7.4 Guide pratique pour expérimenter avec une image Netboot

273

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.

274

Afin de rendre notre vie plus facile, nous pouvons utiliser la virtualisation.

275

###### 4.7.5 Qemu

276

- Installer qemu, bridge-utils, sudo.

277

Éditer `/etc/qemu-ifup`:

278

#!/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

279

Obtenir, ou construire un `grub-floppy-netboot`.

280

Lancer `qemu` avec "`-net nic,vlan=0 -net tap,vlan=0,ifname=tun0`"

281

##### 4.8 Webbooting

282

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.

283

###### 4.8.1 Obtenir les fichiers webboot

284

As usual, you can build the images yourself or use the prebuilt files. Using prebuilt images would be handy for doing initial testing until one can fine tune their own needs. If you have built a live image you will find the files needed for webbooting in the build directory under `binary/live/`. The files are called `vmlinuz`, `initrd.img` and `filesystem.squashfs`.

285

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:

286

# mount -o loop image.iso /mnt

287

The files are to be found under the `live/` directory. In this specific case, it would be `/mnt/live/`. This method has the disadvantage that you need to be root to be able to mount the image. However, it has the advantage that it is easily scriptable and thus, easily automated.

288

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.

289

###### 4.8.2 Démarrer images webboot

290

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.

291

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:

292

append boot=live components fetch=http://192.168.2.50/images/webboot/filesystem.squashfs

293

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.

294

# Aperçu des outils

295

#### 5. Aperçu des outils

296

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.

297

##### 5.1 Le paquet live-build

298

live-build est une collection de scripts pour construire des systèmes live. Ces scripts sont aussi appelés "commandes".

299

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.

300

Plusieurs concepts sont similaires à ceux utilisés pour construire des paquets Debian avec debhelper:

301

- 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/`.

302

- Les scripts sont indépendants, c'est-à-dire qu'il est toujours sûr d'exécuter chaque commande.

303

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.

304

- 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.

305

- lb build: Responsable du démarrage d'un système de construction Live. Voir La commande lb build pour plus d'informations.

306

- lb clean: Responsable de la suppression des parties d'un système de construction Live. Voir La commande lb clean pour plus d'informations.

307

###### 5.1.1 La commande `lb config`

308

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.

309

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.

310

$ lb config
[2025-02-15 12:34:56] lb config
P: Using http proxy: http://127.0.0.1:3142
P: Creating config tree for a debian/testing/amd64 system
P: Symlinking hooks...

311

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).

312

Normalement, vous voulez indiquer certaines options. Par exemple, pour spécifier le gestionnaire de paquets à utiliser lors de la construction de l'image:

313

$ lb config --apt aptitude

314

Il est possible d'indiquer plusieurs options, telles que:

315

$ lb config --binary-images netboot --bootappend-live "boot=live components hostname=live-host username=live-user" ...

316

Une liste complète des options est disponible dans la page de manuel de `lb_config`.

317

###### 5.1.2 La commande `lb build`

318

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.

319

###### 5.1.3 La commande `lb clean`

320

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.

321

##### 5.2 Le paquet live-boot

322

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éés par live-build. Cela inclut ISOs, netboot tarballs, et les images pour clés USB.

323

At boot time it will look for read-only media containing a `/live/` directory where a root filesystem (often a compressed filesystem image like squashfs) is stored. If found, it will create a writable environment, using OverlayFS, for Debian like systems to boot from.

324

More information on initial ramfs in Debian can be found in the Debian Linux Kernel Handbook at ‹https://kernel-team.pages.debian.net/kernel-handbook/› in the chapter on initramfs.

325

##### 5.3 Le paquet live-config

326

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.

327

# Gestion d'une configuration

328

#### 6. Gestion d'une configuration

329

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.

330

##### 6.1 Gérer les modifications de la configuration

331

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.

332

###### 6.1.1 Pourquoi utiliser des scripts auto? Que font-ils?

333

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'ancien 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.

334

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.

335

###### 6.1.2 Utiliser les scripts auto d'exemple

336

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:

337

$ mkdir mylive && cd mylive && lb config
$ mkdir auto
$ cp /usr/share/doc/live-build/examples/auto/* auto/

338

Modifiez `auto/config` en ajoutant des options comme bon vous semble. Par exemple:

339

#!/bin/sh
lb config noauto \
--distribution stable \
--binary-images hdd \
--mirror-bootstrap http://ftp.ch.debian.org/debian/ \
--mirror-binary http://ftp.ch.debian.org/debian/ \
"${@}"

340

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`.

341

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.

342

##### 6.2 Cloner une configuration publiée via Git

343

Use the `lb config --config` option to clone a Git repository that contains a live system configuration. If you would like to base your configuration on one maintained by the Debian Live Project, look at ‹https://salsa.debian.org/live-team/› for the repository named `live-images` in the category `Subgroups and projects`. This repository contains the configurations for the live systems prebuilt images.

344

Par exemple, pour construire une image standard, utilisez le dépôt `live-images` comme suit:

345

$ mkdir live-images && cd live-images
$ lb config --config https://salsa.debian.org/live-team/live-images.git::debian
$ cd images/standard

346

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 des paquets non-free sont faites en ajoutant simplement `--archive-areas "main contrib non-free"`.

347

Vous pouvez éventuellement définir un raccourci dans votre configuration Git en ajoutant la ligne suivante à votre `${HOME}/.gitconfig`:

348

[url "https://salsa.debian.org/live-team/"]
insteadOf = lso:

349

This enables you to use `lso:` anywhere you need to specify the address of a `salsa.debian.org` git repository. If you also drop the optional `.git` suffix, starting a new image using this configuration is as easy as:

350

$ lb config --config lso:live-images::debian

351

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.

352

Dans tous les cas, n'oubliez pas qu'il faut à chaque fois construire l'image en tant que superutilisateur: `lb build`

353

# Personnalisation des contenus

354

#### 7. Vue d'ensemble de la personnalisation

355

Ce chapitre donne un aperçu des diverses façons dont vous pouvez personnaliser un système live.

356

##### 7.1 Configuration pendant la construction vs. l'amorçage

357

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.

358

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.

359

##### 7.2 Étapes de la construction

360

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.

361

À 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.

362

##### 7.3 Supplément lb config avec des fichiers

363

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.

364

##### 7.4 Tâches de personnalisation

365

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.

366

# Personnalisation de l'installation de paquets

367

#### 8. Personnalisation de l'installation de paquets

368

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 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.

369

##### 8.1 Sources des paquets

370

###### 8.1.1 Distribution, zones d'archive et mode

371

The distribution you choose has the broadest impact on which packages are available to include in your live image. Specify the codename, which defaults to testing. Any current distribution carried in the archive may be specified by its codename here. (See Terms for more details.) The `--distribution` option not only influences the source of packages within the archive, but also instructs live-build to enable other sources.

372

For example, to build against the stable release, with security, updates (enabled per default) and additionally proposed-updates and backports, specify:

373

$ lb config --distribution stable --proposed-updates true --backports true

374

Similarly, for the unstable release, sid, which has neither security nor updates, specify:

375

$ lb config --distribution sid

376

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:

377

$ lb config --archive-areas "main contrib non-free"

378

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.

379

Remarque: Les projets pour lesquels ces modes ont été ajoutés sont chargés d'aider les utilisateurs de ces options. Le Debian Live 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.

380

###### 8.1.2 Miroirs de distribution

381

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.

382

###### 8.1.3 Miroirs de distribution utilisés lors de la construction

383

Pour définir les miroirs de distribution utilisés pendant la construction pour pointer vers un miroir local, il suffit de paramétrer `--mirror-bootstrap` et `--mirror-chroot-security` comme suit.

384

$ lb config --mirror-bootstrap http://localhost/debian/ \
--mirror-chroot-security http://localhost/debian-security/

385

Le miroir chroot, indiqué avec `--mirror-chroot`, est par défaut la valeur de `--mirror-bootstrap`.

386

###### 8.1.4 Miroirs de distribution utilisés pendant l'exécution

387

The `--mirror-binary*` options govern the distribution mirrors placed in the binary image. These may be used to install additional packages while running the live system. The defaults employ `deb.debian.org`, a service that chooses a geographically close mirror based, among other things, on the user's IP family and the availability of the mirrors. This is a suitable choice when you cannot predict which mirror will be best for all of your users. Or you may specify your own values as shown in the example below. An image built from this configuration would only be suitable for users on a network where "`mirror`" is reachable.

388

$ lb config --mirror-binary http://mirror/debian/ \
--mirror-binary-security http://mirror/debian-security/ \
--mirror-binary-backports http://mirror/debian-backports/

389

###### 8.1.5 Dépôts additionnels

390

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.

391

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.

392

deb http://debian-live.alioth.debian.org/ sid-snapshots main contrib non-free

393

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.

394

Si ces fichiers existent, ils seront sélectionnés automatiquement.

395

You should also put the ASCII-armored GPG key used to sign the repository into `config/archives/your-repository.key.{binary,chroot}` files.

396

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/`.

397

Similarly, if you need custom APT_AUTH.CONF(5) authentication configuration, this can be placed in `config/archives/your-repository.auth.{binary,chroot}` files and will be automatically added to your live system's `/etc/apt/auth.conf.d/` directory

398

##### 8.2 Choisir les paquets à installer

399

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.

400

###### 8.2.1 Listes de paquets

401

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.

402

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.

403

###### 8.2.2 Utilisation des métapaquets

404

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:

405

$ lb config
$ echo task-gnome-desktop > config/package-lists/desktop.list.chroot

406

This supersedes the older predefined list method supported in `live-build` 2.x. Unlike predefined lists, task metapackages are not specific to the Live System project. Instead, they are maintained by specialist working groups within the distribution and therefore reflect the consensus of each group about which packages best serve the needs of the intended users. They also cover a much broader range of use cases than the predefined lists they replace.

407

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:

408

$ apt-cache search --names-only ^task-

409

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:

410

$ debtags search role::metapackage

411

###### 8.2.3 Listes de paquets locaux

412

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.

413

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.

414

The packages in the `.list.chroot_install` list are present both in the live system and in the installed system.

415

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.

416

###### 8.2.4 Listes de paquets locaux pour l'étape binary

417

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`.

418

###### 8.2.5 Listes de paquets générées

419

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`.

420

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:

421

$ lb config
$ echo '! Packages Priority standard' > config/package-lists/standard.list.chroot

422

###### 8.2.6 Utiliser des conditions dans les listes de paquets

423

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`.

424

Par exemple, pour installer `ia32-libs` si `--architectures amd64` est indiqué:

425

#if ARCHITECTURES amd64
ia32-libs
#endif

426

Vous pouvez tester pour un certain nombre de valeurs, par exemple pour installer memtest86+ si `--architectures i386` ou `--architectures amd64` est indiqué:

427

#if ARCHITECTURES i386 amd64
memtest86+
#endif

428

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`:

429

#if ARCHIVE_AREAS contrib non-free
vrms
#endif

430

L'imbrication des conditions n'est pas prise en charge.

431

###### 8.2.7 Suppression de paquets lors de l'installation

432

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.

433

###### 8.2.8 Summary

434

The table below shows which configuration files are required to achieve the desired availability of the package.

435

| X.chroot | X.chroot_live | X | X.binary
--- | --- | --- | --- | ---
Package is installed in the live system | Yes | Yes | Yes | No
Package is removed after installing the live system | No | Yes | No | N/A
Package can be installed from the live system without network | N/A | N/A | Yes *1 | Yes

436

*1: Because the installer needs this package

437

`X` = `config/package-lists/custom_name.list`

438

###### 8.2.9 Tâches de bureau et de langue

439

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.

440

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.

441

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:

442

$ 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

443

###### 8.2.10 Version et type de noyau

444

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.

445

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`.

446

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:

447

$ lb config --linux-packages linux-image-3.18.0-trunk
$ echo "deb http://deb.debian.org/debian/ experimental main" > config/archives/experimental.list.chroot

448

###### 8.2.11 Noyaux personnalisés

449

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`.

450

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.

451

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.

452

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:

453

- Utilisez un ramdisk initial.

454

- Include the union filesystem module (i.e. usually `OverlayFS`).

455

- Incluez tous les autres modules du système de fichiers requis pour votre configuration (habituellement `squashfs`).

456

##### 8.3 Installation de paquets modifiés ou tiers

457

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ésirables 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.

458

This section does not cover advice regarding building or maintaining modified packages. Joachim Breitner's 'How to fork privately' method from ‹http://www.joachim-breitner.de/blog/archives/282-How-to-fork-privately.html› may be of interest, however. The creation of bespoke packages is covered in the Debian New Maintainers' Guide at ‹https://www.debian.org/doc/manuals/maint-guide/› and elsewhere.

459

Il y a deux façons d'installer des paquets personnalisés modifiés:

460

- `packages.chroot`

461

- Utiliser un dépôt APT personnalisé

462

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.

463

###### 8.3.1 Utiliser `packages.chroot` pour installer des paquets personnalisés

464

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.

465

Les paquets doivent être nommés de la manière prescrite. Une façon simple de le faire consiste à utiliser `dpkg-name`.

466

L'utilisation de `packages.chroot` pour l'installation de paquets personnalisés a des inconvénients:

467

- Il n'est pas possible d'utiliser APT de façon sécurisée.

468

- Vous devez installer tous les paquets appropriés dans le répertoire `config/packages.chroot/`.

469

- Il ne se prête pas au stockage de configurations des systèmes live dans le contrôle de révision.

470

###### 8.3.2 Utiliser un dépôt APT pour installer des paquets personnalisés.

471

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.

472

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.

473

The APT repository does not necessarily need to be online, you can use a local repository instead. However, in both cases the repository needs to be signed.

474

Example:

475

$ gpg --armor --output config/archives/custom_repo.gpg.key${EXTENSION} --export-options export-minimal --export ${SIGNING_KEY}
$ cat << EOF > config/archives/custom_repo.list${EXTENSION}
deb [signed-by=/etc/apt/trusted.gpg.d/custom_repo.gpg.key${EXTENSION}.asc] ${URI} ${SUITE} ${COMPONENTS}
EOF
$ echo "${PACKAGES_FROM_REPOSITORY}" > config/package-lists/custom_repo.list${EXTENSION}

476

Where:

477

- `${EXTENSION}` : the optional stage suffix, see the summary

478

- `${SIGNING_KEY}`: the keyID of the signature of the repository

479

- `${URI}`: the URI to the repository, e.g. `http://deb.debian.org/debian/` or `file://$(pwd)/my_local_repository`

480

- `${SUITE}`: the suite within the repository, e.g. `my-debian-based-distro`

481

- `${COMPONENTS}`: the components within the repository, e.g. `main`

482

- `${PACKAGES_FROM_REPOSITORY}`: the names of the packages to install (dependencies will automatically be installed as well)

483

###### 8.3.3 Les paquets personnalisés et APT

484

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.

485

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 fait en modifiant les préférences d'APT pinning dans le système live − voir APT pinning pour plus d'informations.

486

##### 8.4 Configuration d'APT pendant la construction

487

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`.

488

###### 8.4.1 Choisir apt ou aptitude

489

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.

490

- `apt`: Avec cette méthode, si un paquet manquant est indiqué, l'installation va échouer. C'est le réglage par défaut.

491

- `aptitude`: Avec cette méthode, si un paquet manquant est indiqué, l'installation va réussir.

492

###### 8.4.2 Utilisation d'un proxy avec APT

493

One commonly required APT configuration is to deal with building an image behind a proxy. You may specify your APT proxy with the `--apt-http-proxy` option as needed, e.g.

494

$ lb config --apt-http-proxy http://proxy/

495

###### 8.4.3 Régler APT pour économiser de l'espace

496

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.

497

Si vous ne voulez pas inclure les index d'APT dans l'image, vous pouvez les omettre avec:

498

$ lb config --apt-indices false

499

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.

500

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:

501

$ lb config --apt-recommends false

502

The most important consequence of turning off recommends is that `live-boot` and `live-config` themselves recommend some packages that provide important functionality used by most Live configurations.

503

Two packages which you most probably will want to add again are:

504

- `user-setup` which `live-config` recommends is used to create the live user.

505

- `sudo` which `live-config` recommends is used to obtain root access in the live-image, which is needed to shutdown the computer.

506

$ lb config --apt-recommends false
$ echo "user-setup sudo" > config/package-lists/recommends.list.chroot

507

In all but the most exceptional circumstances you need to add back at least some of these recommends to your package lists or else your image will not work as expected, if at all. Look at the recommended packages for each of the `live-*` packages included in your build and if you are not certain you can omit them, add them back into your package lists.

508

The more general consequence is that if you don't install recommended packages for any given package, that is, "packages that would be found together with this one in all but unusual installations" ( Debian Policy Manual, section 7.2 ), some packages that users of your Live system actually need may be omitted. Therefore, we suggest you review the difference turning off recommends makes to your packages list (see the `binary.packages` file generated by `lb build`) and re-include in your list any missing packages that you still want installed. Alternatively, if you find you only want a small number of recommended packages left out, leave recommends enabled and set a negative APT pin priority on selected packages to prevent them from being installed, as explained in APT pinning.

509

###### 8.4.4 Passer des options à apt ou aptitude

510

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`:

511

$ lb config --apt-options "--yes -oAcquire::Check-Valid-Until=false"

512

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.

513

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.

514

###### 8.4.5 APT pinning

515

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`.

516

Imaginons que vous voulez construire un système live trixie 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, trixie. Ce qui suit devrait accomplir cela:

517

$ 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
Package: *
Pin: release n=sid
Pin-Priority: 1
EOF

518

Une priorité pin négative empêchera l'installation d'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`:

519

Package: gnome-keyring
Pin: version *
Pin-Priority: -1

520

# Personnalisation des contenus

521

#### 9. Personnalisation des contenus

522

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.

523

##### 9.1 Includes

524

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:

525

- 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.

526

- 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.

527

Veuillez consulter les Termes pour plus d'informations sur la distinction entre les images "Live" et "binary".

528

###### 9.1.1 Live/chroot local includes

529

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 Chroot local hooks si le traitement est nécessaire.

530

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:

531

$ mkdir -p config/includes.chroot/var/www
$ cp /path/to/my/index.html config/includes.chroot/var/www

532

Votre configuration aura alors le schéma suivant:

533

-- config
[...]
|-- includes.chroot
| `-- var
| `-- www
| `-- index.html
[...]

534

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.

535

###### 9.1.2 Binary local includes

536

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:

537

$ cp ~/video_demo.* config/includes.binary/

538

Ces fichiers apparaissent maintenant dans le répertoire racine du support live.

539

##### 9.2 Hooks

540

Les hooks permettent l'exécution des commandes dans les étapes de la construction chroot et binary afin de personnaliser l'image. Selon que vous construisez une image live ou une image normal du système, vous devez placer vos hooks dans `config/hooks/live` ou `config/hooks/normal` respectivement. Ceux-ci sont souvent appelés hooks locales parce qu'ils sont exécutés dans l'environnement de construction.

541

Il y a aussi des hooks pendant le démarrage qui vous permettent d'exécuter des commandes une fois que l'image a déjà été construite, au cours du processus de démarrage.

542

###### 9.2.1 Chroot local hooks

543

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/live` ou `config/hooks/normal`. 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.

544

###### 9.2.2 Binary local hooks

545

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/live` ou `config/hooks/normal`. 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 binary 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.

546

###### 9.2.3 Hooks pendant le démarrage

547

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.

548

##### 9.3 Préconfigurer questions de debconf

549

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`.

550

Pour plus d'informations sur debconf, veuillez consulter `debconf(7)` dans le paquet debconf.

551

# Personnalisation des comportements pendant l'exécution

552

#### 10. Personnalisation des comportements pendant l'exécution

553

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.

554

##### 10.1 Personnalisation de l'utilisateur live

555

Une considération importante est que l'utilisateur live est créé par live-boot au démarrage, non pas par live-build 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.

556

You can specify additional groups that the live user will belong to by using any of the possibilities to configure live-config. For example, to add the live user to the `fuse` group, you can either add the following file in `config/includes.chroot/etc/live/config.conf.d/10-user-setup.conf`:

557

LIVE_USER_DEFAULT_GROUPS="audio cdrom dip floppy video plugdev netdev powerdev scanner bluetooth fuse"

558

ou utiliser `live-config.user-default-groups=audio,cdrom,dip,floppy,video,plugdev,netdev,powerdev,scanner,bluetooth,fuse` comme paramètre d'amorçage.

559

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:

560

Pour modifier le nom de l'utilisateur par défaut, vous pouvez simplement l'indiquer dans votre configuration:

561

$ lb config --bootappend-live "boot=live components username=live-user"

562

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/`

563

##### 10.2 Personnalisation des paramètres régionaux et de la langue

564

Au démarrage du système live, la langue est impliquée dans deux étapes:

565

- la génération des paramètres régionaux

566

- le réglage de la disposition du clavier

567

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

568

$ lb config --bootappend-live "boot=live components locales=de_CH.UTF-8"

569

Plusieurs paramètres régionaux peuvent être indiqués dans une liste séparée par des virgules.

570

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`.

571

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:

572

$ egrep -i '(^!|german.*switzerland)' /usr/share/X11/xkb/rules/base.lst
! model
! layout
ch German (Switzerland)
! variant
legacy ch: German (Switzerland, legacy)
de_nodeadkeys ch: German (Switzerland, eliminate dead keys)
de_sundeadkeys ch: German (Switzerland, Sun dead keys)
de_mac ch: German (Switzerland, Macintosh)
! option

573

Chaque variante présente une description de la disposition appliquée.

574

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:

575

$ lb config --bootappend-live "boot=live components locales=de_CH.UTF-8 keyboard-layouts=ch"

576

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:

577

$ lb config --bootappend-live \
"boot=live components locales=fr_FR.UTF-8 keyboard-layouts=fr keyboard-variants=bepo keyboard-model=tm2030usb"

578

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:

579

$ lb config --bootappend-live \
"boot=live components keyboard-layouts=us,us keyboard-variants=,dvorak"

580

##### 10.3 Persistance

581

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.

582

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.

583

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.

584

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`.

585

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:

586

- une partition, identifiée par son nom GPT.

587

- un système de fichiers, identifié par son étiquette de système de fichiers.

588

- 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.

589

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.

590

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éée avec:

591

# mkfs.ext4 -L persistence /dev/sdb1

592

Voir aussi Utilisation de l'espace disponible sur une clé USB.

593

Si vous avez déjà une partition sur votre périphérique, vous pouvez simplement modifier l'étiquette avec l'un des exemples suivants:

594

# tune2fs -L persistence /dev/sdb1 # for ext2,3,4 filesystems

595

Voici un exemple montrant comment créer un fichier image avec un système de fichiers ext4 pour être utilisé pour la persistance:

596

$ dd if=/dev/null of=persistence bs=1 count=0 seek=1G # for a 1GB sized image file
$ /sbin/mkfs.ext4 -F persistence

597

Une fois que le fichier image est créé, à 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:

598

# cp persistence /
# mount -t ext4 /persistence /mnt

599

Ensuite, créez le fichier `persistence.conf` ajoutant du contenu et démontez le fichier image.

600

# echo "/usr union" >> /mnt/persistence.conf
# umount /mnt

601

Maintenant, redémarrez dans votre support live avec le paramètre de démarrage "persistence".

602

###### 10.3.1 Le fichier persistence.conf

603

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.

604

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:

605

# 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

606

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.

607

###### 10.3.2 Utilisation de plusieurs dispositifs de persistance

608

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.

609

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).

610

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`.

611

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`.

612

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.

613

###### 10.3.3 Utilisation de la persistance avec chiffrement

614

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.

615

Pour installer cryptsetup sur votre machine:

616

# apt-get install cryptsetup

617

Pour installer cryptsetup dans votre système live, ajouter à vos listes de paquets:

618

$ lb config
$ echo "cryptsetup cryptsetup-initramfs" > config/package-lists/encryption.list.chroot

619

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:

620

$ lb config --bootappend-live "boot=live components persistence persistence-encryption=luks"

621

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.

622

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:

623

# cryptsetup --verify-passphrase luksFormat /dev/sdc2

624

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:

625

# cryptsetup luksOpen /dev/sdc2 live

626

La prochaine étape est de remplir le dispositif avec des zéros avant de créer le système de fichiers:

627

# dd if=/dev/zero of=/dev/mapper/live

628

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.

629

# mkfs.ext4 -L persistence /dev/mapper/live

630

Pour continuer avec notre configuration, nous avons besoin de monter le dispositif, par exemple dans `/mnt`.

631

# mount /dev/mapper/live /mnt

632

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.

633

# echo "/ union" > /mnt/persistence.conf

634

Puis, démontez le point de montage:

635

# umount /mnt

636

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:

637

# cryptsetup luksClose live

638

Résumons la procédure. Jusqu'ici nous avons créé 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éé 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.

639

# Personnalisation de l'image binaire

640

#### 11. Personnalisation de l'image binaire

641

##### 11.1 Chargeurs d'amorçage

642

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.

643

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.

644

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.

645

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.

646

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:

647

include menu.cfg
default vesamenu.c32
prompt 0
timeout 50

648

##### 11.2 Métadonnées ISO

649

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.

650

- `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.

651

- `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.

652

- `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.

653

- `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 32.

654

# Personnalisation de l'installateur Debian

655

#### 12. Personnalisation du contenu pour l'installateur Debian

656

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.

657

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».

658

##### 12.1 Types d'installateur Debian

659

Les trois principaux types de programme d'installation sont:

660

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».

661

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.

662

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.

663

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.

664

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.

665

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.

666

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`.

667

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.

668

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:

669

$ lb config --debian-installer live
$ echo debian-installer-launcher >> config/package-lists/my.list.chroot

670

##### 12.2 Personnalisation de l'installateur Debian par préconfiguration

671

As described in the Debian Installer Manual, Appendix B at ‹https://www.debian.org/releases/stable/amd64/apb.en.html›, "Preseeding provides a way to set answers to questions asked during the installation process, without having to manually enter the answers while the installation is running. This makes it possible to fully automate most types of installation and even offers some features not available during normal installations." This kind of customization is best accomplished with live-build by placing the configuration in a `preseed.cfg` file included in `config/includes.installer/`. For example, to preseed setting the locale to `en_US`:

672

$ echo "d-i debian-installer/locale string en_US" \
>> config/includes.installer/preseed.cfg

673

##### 12.3 Personnalisation de contenu pour l'Installateur Debian

674

À 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/`.

675

# Projet

676

# Contribuer au projet

677

#### 13. Contribuer au projet

678

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.

679

Contributions to the project, such as translations and patches, are greatly welcome. Anyone can send merge requests. The projects are hosted on Salsa: ‹https://salsa.debian.org/live-team› follow Salsa's documentation for instructions on how to contribute.

680

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.

681

- 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/...'.

682

- É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.

683

- 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.

684

##### 13.1 Traduction des pages de manuel

685

Vous pouvez également contribuer au projet en travaillant à la traduction des pages man pour les différents paquets live-* que le projet maintient. La procédure est différente suivant que vous démarriez une nouvelle traduction ou que vous continuiez à travailler sur une traduction déjà existante :

686

- Continuer avec une traduction déjà commencée

687

Si vous voulez maintenir la traduction d'une langue déjà existante, vous devez effectuer vos modifications dans le ou les fichier(s) `manpages/po/${LANGUAGE}/*.po` puis, lancer la commande `make rebuild` depuis le répertoire `manpages/`. Ceci mettra à jour les pages de manuel dans `manpages/${LANGUAGE}/*`

688

- Commencer une nouvelle traduction à partir de zéro

689

Pour ajouter une nouvelle traduction de l'une des pages de manuel du projet, il vous faut suivre une procédure similaire. Elle peut être résumée comme suit :

690

- Ouvrez le ou les fichiers(s) `manpages/pot/` dans votre éditeur favori, comme poedit, et sauvegardez-le en tant que fichier dans `manpages/po/${LANGUAGE}/`. (Vous devrez créer votre répertoire `${LANGUAGE}/`).

691

- Lancez `make rebuild` depuis l'intérieur du répertoire `manpages/` pour créer les fichiers `manpages/${LANGUAGE}/` contenant les pages de manuel.

692

Souvenez-vous que vous devrez ajouter tous les répertoires et les fichiers, puis faire le commit, et finalement, poussez sur le serveur git.

693

# Signaler des bogues

694

#### 14. Signaler des bogues

695

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.

696

Pour les impatients:

697

- First check whether the bugs has been reported already. You can see the full list of bugs that are assigned to the live-team at ‹https://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=debian-live%40lists.debian.org›.

698

- Before submitting a bug report always try to reproduce the bug with the most recent versions of the packages of live-build, live-boot, live-config and live-tools that you're using.

699

- 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.

700

##### 14.1 Problèmes connus

701

Currently known issues are listed in the BTS at ‹https://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=debian-live%40lists.debian.org›.

702

Note: Since Debian testing and Debian unstable distributions are moving targets, when you specify either of them as the target system distribution, a successful build may not always be possible.

703

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.

704

It is out of the scope of this manual to train you to correctly identify and fix problems in packages of the development distributions, however, you can always try the following: If a build fails when the target distribution is testing, try unstable. If unstable does work, revert to testing and pin the newer version of the failing package from unstable (see APT pinning for details).

705

##### 14.2 Effectuer une recherche

706

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.

707

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.

708

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.

709

##### 14.3 Reconstruire à partir de zéro

710

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.

711

##### 14.4 Utiliser des paquets mis à jour

712

Using outdated packages can cause significant problems when trying to reproduce (and ultimately fix) your problem. Make sure your build system is up-to-date and any packages included in your image are up-to-date as well. If possible, try to reproduce the bug with the newest code from source, see Installation for details.

713

##### 14.5 Recueillir l'information

714

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.

715

Pour tirer le meilleur parti de votre rapport de bogue, nous avons au moins besoin des informations suivantes:

716

- L'architecture du système hôte

717

- Distribution du système hôte

718

- Version de live-build sur le système hôte

719

- Version de debootstrap sur le système hôte

720

- L'architecture du système live

721

- Répartition du système live

722

- Version de live-boot sur le système live

723

- Version de live-config sur le système live

724

- Version de live-tools sur le système live

725

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).

726

# lb build 2>&1 | tee build.log

727

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.

728

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).

729

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`.

730

##### 14.6 Isoler le cas qui échoue, si possible

731

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.

732

##### 14.7 Utiliser le paquet adéquat pour rapporter un bogue

733

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.

734

Toutefois, nous apprécierions que vous essayiez de le réduire en fonction de l'endroit où le bogue apparaît.

735

###### 14.7.1 Pendant la construction durant l'amorçage

736

live-build amorce d'abord un système Debian de base avec debootstrap. 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.

737

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.

738

###### 14.7.2 Pendant la construction durant l'installation de paquets

739

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.

740

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.

741

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.

742

###### 14.7.3 Pendant le démarrage

743

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.

744

###### 14.7.4 Pendant l'exécution

745

If a package was successfully installed, but fails while actually running the Live system, this is probably a bug in live-config.

746

##### 14.8 Où rapporter les bogues

747

Le Debian Live 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.

748

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.

749

# Style de code

750

#### 15. Style du code

751

Ce chapitre documente le style du code utilisé dans les systèmes live.

752

##### 15.1 Compatibilité

753

- Avoid "bashisms", the codebase must be POSIX compliant and thus universally compatible.

754

- Furthermore it must comply with the version of the POSIX specification chosen by the current Debian Policy.

755

- Vous pouvez vérifier vos scripts avec 'sh -n' et 'checkbashisms'.

756

- Assurez-vous que tout le code fonctionne avec 'set-e '.

757

##### 15.2 Indentation

758

- Utilisez toujours des tabulations au lieu des espaces.

759

- Keep case branch terminators (";;") aligned with the "content" of the branch, rather than the branch "entry".

760

Bien:

761

case "${1}" in
foo)
foobar
;;
bar)
foobar
;;
esac

762

##### 15.3 Adaptateur

763

- Generally, lines should be 80 chars at maximum.

764

- Placement of keywords like `then` and `do` should be chosen with good judgement with respect to clutter and readability. For small bits of code in particular it should be preferred to have them on the same line as the prior keyword they relate to (`if`; `for`; etc). Only place on the next line where it makes good sense to do so; typically this might only be to comply with maximum line length restrictions. One situation where they should always be placed on the next line is where what they follow is broken up onto multiple lines, and thus it being on a new line creates clear separation between that and the body of code following it. I.e. :

765

Preferred:

766

if foo; then
bar
fi
for FOO in $ITEMS; do
bar
done
if [ "${MY_LOCATION_VARIABLE}" = "something" ] && [ -e "${MY_OUTPUT_FILE}" ]
then
MY_OTHER_VARIABLE="$(some_bin ${FOOBAR} | awk -F_ '{ print $1 }')"
fi
if [ "${MY_FOO}" = "something" ] && [ -e "path/${FILE_1}" ] ||
[ "${MY_BAR}" = "something_else" ] && [ ${ALLOW} = "true" ]
then
foobar
fi

767

Less ideal:

768

if [ "${MY_LOCATION_VARIABLE}" = "something" ] && [ -e "${MY_OUTPUT_FILE}" ]; then
MY_OTHER_VARIABLE="$(some_bin ${FOOBAR} | awk -F_ '{ print $1 }')"
fi

769

Horrible:

770

if [ "${MY_LOCATION_VARIABLE}" = "something" ] && [ -e "${MY_OUTPUT_FILE}" ] || [ "${MY_LOCATION_VARIABLE}" = "something-else" ] && [ -e "${MY_OUTPUT_FILE_2}" ]; then
MY_OTHER_VARIABLE="$(some_bin ${FOOBAR} | awk -F_ '{ print $1 }')"
fi

771

- Prefer placing the opening brace of a function on a new line (for consistency with established style), and keep the braces aligned with the function name:

772

Bien:

773

Foo ()
{
bar
}

774

Bad (inconsistent with existing style):

775

Foo () {
bar
}

776

Awful:

777

Foo ()
{
bar
}

778

##### 15.4 Variables

779

- Les variables sont toujours en lettres majuscules.

780

- Config variables used in live-build should start with an `LB_` prefix.

781

- Local function variables should be restricted to local scope.

782

- Les variables en relation avec un paramètre de démarrage dans live-config commencent par `LIVE_`.

783

- Toutes les autres variables dans live-config commencent par le préfixe `_`.

784

- Utilisez des accolades autour des variables; écrivez par exemple `${FOO}` au lieu de `$FOO`.

785

- Always protect variables with quotes to respect potential whitespaces (except where necessary to achieve correct word splitting): write `"${FOO}"` not `${FOO}`.

786

- Pour des raisons de cohérence, utilisez toujours les guillemets lors de l'attribution des valeurs aux variables:

787

Mal:

788

FOO=bar

789

Bien:

790

FOO="bar"

791

- If multiple variables are used, prefer quoting the full expression:

792

Typically bad:

793

if [ -f "${FOO}"/foo/"${BAR}"/bar ]; then
foobar
fi

794

Bien:

795

if [ -f "${FOO}/foo/${BAR}/bar" ]; then
foobar
fi

796

##### 15.5 Autres

797

- Prefer "`|`" (without the surround quotes) as a separator in calls to sed, e.g. "`sed -e 's|foo|bar|'`" (without "").

798

- Don't use the `test` command for comparisons or tests, use "`[`" and "`]`" (without ""); e.g. "`if [ -x /bin/foo ]; ...`" and not "`if test -x /bin/foo; ...`".

799

- Use `case` wherever it makes code more readable than conditional checks (`if foo; ...` and tests without the actual `if` keyword, e.g. `[ -e "${FILE}" ] || exit 0`).

800

- Use "Foo_bar" style names for functions, i.e. a capital first letter, then all lowercase, with sensible use of underscores for better readability.

801

# Exemples

802

# Exemples

803

#### 16. Exemples

804

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.

805

##### 16.1 Utiliser les exemples

806

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.

807

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:

808

LB_MIRROR_BOOTSTRAP="http://mirror/debian/"
LB_MIRROR_CHROOT_SECURITY="http://mirror/debian-security/"
LB_MIRROR_CHROOT_BACKPORTS="http://mirror/debian-updates/"

809

##### 16.2 Tutoriel 1: Une image par défaut

810

Cas d'utilisation: Créer une image simple d'abord, en apprenant les bases de live-build.

811

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.

812

Vous ne pouvez pas faire plus simple que cela:

813

$ mkdir tutorial1 ; cd tutorial1 ; lb config

814

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.

815

Maintenant, en tant que superutilisateur, construisez l'image en enregistrant un journal avec `tee`.

816

# lb build 2>&1 | tee build.log

817

Assuming all goes well, after a while, the current directory will contain `live-image-amd64.hybrid.iso`. This ISO hybrid image can be booted directly in a virtual machine as described in Testing an ISO image with Qemu and Testing an ISO image with VirtualBox, or else imaged onto optical media or a USB flash device as described in Burning an ISO image to a physical medium and Copying an ISO hybrid image to a USB stick, respectively.

818

##### 16.3 Tutoriel 2: Un utilitaire d'un navigateur Web

819

Cas d'utilisation: Créer l'image d'un utilitaire de navigation Web, en apprenant à appliquer des personnalisations.

820

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.

821

$ mkdir tutorial2
$ cd tutorial2
$ lb config
$ echo "task-lxde-desktop firefox-esr" >> config/package-lists/my.list.chroot

822

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.

823

Construisez l'image, encore une fois en tant que superutilisateur, et gardez un journal comme dans Tutoriel 1:

824

# lb build 2>&1 | tee build.log

825

Encore une fois, vérifiez que l'image est OK et faites un test, comme dans Tutoriel 1:

826

##### 16.4 Tutoriel 3: Une image personnalisée

827

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.

828

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.

829

###### 16.4.1 Première révision

830

$ mkdir -p tutorial3/auto
$ cp /usr/share/doc/live-build/examples/auto/* tutorial3/auto/
$ cd tutorial3

831

Éditez `auto/config` comme suit:

832

#!/bin/sh
lb config noauto \
--distribution stable \
"${@}"

833

Exécutez `lb config` pour générer l'arbre de configuration, en utilisant le script `auto/config` qu'on a créé:

834

$ lb config

835

Remplissez maintenant votre liste de paquets locaux:

836

$ echo "task-lxde-desktop spice-vdagent hexchat" >> config/package-lists/my.list.chroot

837

First, `--distribution stable` ensures that ⌠stable} is used instead of the default {testing⌡. Second, we have added spice-vdagent for easier testing the image in qemu. And finally, we have added an initial favourite package: hexchat.

838

Maintenant, construisez l'image:

839

# lb build

840

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`.

841

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éés, puis de faire le premier commit:

842

$ git init
$ cp /usr/share/doc/live-build/examples/gitignore .gitignore
$ git add .gitignore auto config
$ git commit -m "Initial import."

843

###### 16.4.2 Deuxième révision

844

In this revision, we're going to clean up from the first build, replace the smplayer package with vlc package, rebuild, test and commit.

845

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.

846

# lb clean

847

Now install the vlc package before the lxde package chooses between smplayer, vlc and mplayer-gui in our local package list in `config/package-lists/my.list.chroot`:

848

$ echo "vlc task-lxde-desktop spice-vdagent hexchat" >> config/package-lists/my.list.chroot

849

Construisez à nouveau:

850

# lb build

851

Testez et, quand vous êtes satisfait, faites le commit de la prochaine révision:

852

$ git commit -a -m "Replacing smplayer with vlc."

853

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éés avec `lb config` via leurs scripts `auto` respectifs.

854

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.

855

##### 16.5 Un client kioske VNC

856

Cas d'utilisation: Créer une image avec live-build pour démarrer directement sur un serveur VNC.

857

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.

858

$ mkdir vnc-kiosk-client
$ cd vnc-kiosk-client
$ lb config --apt-recommends false
$ echo '! Packages Priority standard' > config/package-lists/standard.list.chroot
$ echo "xorg gdm3 metacity xtightvncviewer" > config/package-lists/my.list.chroot

859

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.

860

Une façon facile d'énumérer les paquets recommendés est d'utiliser apt-cache. Par exemple:

861

$ apt-cache depends live-config live-boot

862

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:

863

$ echo "live-tools user-setup sudo eject" > config/package-lists/recommends.list.chroot

864

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`:

865

$ mkdir -p config/includes.chroot/etc/skel
$ cat > config/includes.chroot/etc/skel/.xsession << EOF
#!/bin/sh
/usr/bin/metacity &
/usr/bin/xvncviewer 192.168.1.2:1
exit
EOF

866

Construire l'image:

867

# lb build

868

Amusez-vous bien!

869

##### 16.6 A minimal image for a 512MB USB key

870

Use case: Create a default image with some components removed in order to fit on a 512MB USB key with a little space left over to use as you see fit.

871

When optimizing an image to fit a certain media size, you need to understand the tradeoffs you are making between size and functionality. In this example, we trim only so much as to make room for additional material within a 512MB media size, but without doing anything to destroy the integrity of the packages contained within, such as the purging of locale data via the localepurge package, or other such "intrusive" optimizations. Of particular note, we use `--debootstrap-options` to create a minimal system from scratch and `--binary image hdd` to create an image that can be copied to a USB key.

872

$ lb config --binary-image hdd --apt-indices false --apt-recommends false --debootstrap-options "--variant=minbase" --firmware-chroot false --memtest none

873

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

874

$ echo "user-setup sudo" > config/package-lists/recommends.list.chroot

875

Additionally, you'll want to have network access, so another two recommended packages need to be re-added:

876

$ echo "ifupdown isc-dhcp-client" >> config/package-lists/recommends.list.chroot

877

Maintenant, construisez l'image de la manière habituelle:

878

# lb build 2>&1 | tee build.log

879

On the author's system at the time of writing this, the above configuration produced a 298MiB image. This compares favourably with the 380MiB image produced by the default configuration in Tutorial 1, when `--binary-image hdd` is added.

880

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.

881

Note: A minimal system can also be achieved using hooks, like for example the `stripped.hook.chroot` hook found in `/usr/share/doc/live-build/examples/hooks`. It may shave off additional small amounts of space and produce an image of 277MiB. However, it does so by removal of documentation and other files from packages installed on the system. This violates the integrity of those packages and that, as the comment header warns, may have unforeseen consequences. That is why using a minimal debootstrap is the recommended way of achieving this goal.

882

##### 16.7 Un bureau GNOME localisé avec un installateur

883

Cas d'utilisation: Créer une image de bureau GNOME, localisée pour la Suisse et incluant un installateur.

884

We want to make an iso-hybrid image using our preferred desktop, in this case GNOME, containing all of the same packages that would be installed by the standard Debian installer for GNOME.

885

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:

886

# apt-get install dctrl-tools tasksel-data

887

Maintenant, nous pouvons rechercher les tâches appropriées, d'abord avec:

888

$ grep-dctrl -FTest-lang de /usr/share/tasksel/descs/debian-tasks.desc -sTask
Task: german

889

Par cette commande, nous découvrons que la tâche est appelée, assez clairement, german. Maintenant, pour trouver les tâches liées:

890

$ grep-dctrl -FEnhances german /usr/share/tasksel/descs/debian-tasks.desc -sTask
Task: german-desktop
Task: german-kde-desktop

891

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:

892

$ mkdir live-gnome-ch
$ cd live-gnome-ch
$ lb config \
--bootappend-live "boot=live components locales=de_CH.UTF-8 keyboard-layouts=ch" \
--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

893

Note that we have included the debian-installer-launcher package to launch the installer from the live desktop.

894

# Appendix

895

# Guide de style

896

#### 17. Guide de style

897

##### 17.1 Lignes directrices pour les auteurs

898

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.

899

Remarque: Les auteurs doivent lire d'abord Contribuer à ce document

900

###### 17.1.1 Caractéristiques linguistiques

901

- Utilisez un anglais simple

902

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.

903

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.

904

- Variété de l'anglais

905

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.

906

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.

907

- Soyez équilibré

908

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.

909

- Soyez politiquement correct

910

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.

911

- Soyez concis

912

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.

913

- Minimiser le travail de traduction

914

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.

915

- Soyez cohérent

916

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.

917

- Soyez cohésive

918

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).

919

- Soyez descriptif

920

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.

921

- Dictionnaire

922

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.

923

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.

924

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é.

925

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.

926

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.

927

- Faux amis, expressions idiomatiques et autres expressions

928

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.

929

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!

930

- Évitez l'argot, les abréviations, les contractions...

931

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.

932

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.

933

###### 17.1.2 Procédures

934

- Tester avant d'écrire

935

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.

936

- Exemples

937

En fournissant un exemple essayer d'être aussi précis que possible. Un exemple est, après tout, juste un exemple.

938

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é.

939

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.

940

- Liens externes

941

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.

942

D'ailleurs, les gens qui lisent le manuel hors ligne n'auront pas la chance de suivre ces liens.

943

- Évitez les marques et les choses qui violent la licence sous laquelle le manuel est publié

944

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.

945

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.

946

- Ecrire un premier projet, réviser, modifier, améliorer, refaire si nécessaire

947

- Remue-méninges!. Vous devez organiser vos idées d'abord dans une séquence logique des événements.

948

- Une fois que vous avez en quelque sorte organisé ces idées dans votre esprit écrire un premier projet.

949

- Réviser la grammaire, la syntaxe et l'orthographe. Gardez à l'esprit que les noms propres des versions, tels que trixie 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`

950

- Améliorer vos phrases et refaire n'importe quelle partie si nécessaire.

951

- Chapitres

952

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.

953

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.

954

- Balisage

955

And last but not least, live-manual uses SiSU to process the text files and produce a multiple format output. It is recommended to take a look at SiSU's manual to get familiar with its markup, or else type:

956

$ sisu --help markup

957

Voici quelques exemples de balisage qui peuvent éventuellement vous aider:

958

- Pour accent/texte en gras:

959

*{foo}* or !{foo}!

960

il produit: foo or foo. Utiliser pour mettre l'accent sur certains mots-clés.

961

- Pour italique:

962

/{foo}/

963

il produit: foo. Utiliser par exemple, pour les noms des paquets Debian.

964

- Pour monospace:

965

#{foo}#

966

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.

967

- Pour les blocs de code:

968

code{
$ foo
# bar
}code

969

il produit:

970

$ foo
# bar

971

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.

972

##### 17.2 Lignes directrices pour les traducteurs

973

Cette section traite des considérations générales à prendre en compte lors de la traduction du contenu du live-manual.

974

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.

975

Remarque: Les traducteurs doivent aussi lire Contribuer à ce document. En particulier, la section Traduction

976

###### 17.2.1 Conseils de traduction

977

- Commentaires

978

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.

979

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.

980

- NDT, Note Du Traducteur

981

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 ".

982

- Phrases impersonnelles

983

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.

984

- Faux amis

985

Le piège des "faux amis" expliqué avant s'applique surtout aux traducteurs. Vérifiez le sens des faux amis suspects en cas de doute.

986

- Balisage

987

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.

988

- Blocs de code

989

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.

990

- Sauts de ligne

991

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.

992

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.

993

- Chaînes intraduisibles

994

Les traducteurs ne doivent jamais traduire:

995

- Les noms de code des versions (qui doivent être écrits en minuscules)

996

- Les noms des logiciels

997

- Les commandes fournies à titre d'exemples

998

- Métadonnées (souvent entre deux points :metadata:)

999

- Liens

1000

- Les chemins