Manuel Live Systems

À propos

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

2. À propos du Live Systems 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 Seulement des paquets inchangés de Debian «main»
2.2.2 Pas de configuration des paquets du système live
2.3 Contact

Utilisateur

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.2.3 À partir des instantanés
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
3.3.3 À partir des instantanés

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 Utiliser le constructeur web d'images live
4.3.1 Utilisation du constructeur web et avertissements
4.4 Premières étapes: la construction d'une image ISO hybride
4.5 Utilisation d'une image ISO hybride live
4.5.1 Graver une image ISO sur un support physique
4.5.2 Copie d'une image ISO hybride sur une clé USB
4.5.3 Utilisation de l'espace disponible sur une clé USB
4.5.4 Démarrer le support live
4.6 Utiliser une machine virtuelle pour les tests
4.6.1 Test d'une image ISO avec QEMU
4.6.2 Test d'une image ISO avec VirtualBox
4.7 Construire et utiliser une image HDD
4.8 Construction d'une image netboot
4.8.1 Serveur DHCP
4.8.2 Serveur TFTP
4.8.3 Serveur NFS
4.8.4 Guide pratique pour expérimenter avec une image Netboot
4.8.5 Qemu
4.9 Webbooting
4.9.1 Obtenir les fichiers webboot
4.9.2 Démarrer images webboot

5. Aperçu des outils

5.1 Le paquet live-build
5.1.1 La commande lb init
5.1.2 La commande lb config
5.1.3 La commande lb build
5.1.4 La commande lb clean
5.2 Le paquet live-boot
5.3 Le paquet live-config

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

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

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 Tâches de bureau et de langue
8.2.9 Version et type de noyau
8.2.10 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

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 Live/chroot local hooks
9.2.2 Hooks pendant le démarrage
9.2.3 Binary local hooks
9.3 Préconfigurer questions de debconf

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.4 Utilisation de la persistance avec chiffrement

11. Personnalisation de l'image binaire

11.1 Chargeurs d'amorçage
11.2 Métadonnées ISO

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

13. Contribuer au projet

13.1 Faire des changements

14. Signaler des bogues

14.1 Problèmes connus
14.2 Reconstruire à partir de zéro
14.3 Utiliser des paquets mis à jour
14.4 Recueillir l'information
14.5 Isoler le cas qui échoue, si possible
14.6 Utiliser le paquet adéquat pour rapporter un bogue
14.6.1 Pendant la construction durant l'amorçage
14.6.2 Pendant la construction durant l'installation de paquets
14.6.3 Pendant le démarrage
14.6.4 Pendant l'exécution
14.7 Effectuer une recherche
14.8 Où rapporter les bogues

15. Style du code

15.1 Compatibilité
15.2 Indentation
15.3 Adaptateur
15.4 Variables
15.5 Autres

16. Procédures

16.1 Évolutions majeures
16.2 Évolutions mineures
16.2.1 Dernière évolution mineure d'une version Debian
16.2.2 Modèle pour l'annonce d'une évolution mineure

17. Dépôts Git

17.1 Gestion de multiples dépôts

Exemples

18. Exemples

18.1 Utiliser les exemples
18.2 Tutoriel 1: Une image par défaut
18.3 Tutoriel 2: Un utilitaire d'un navigateur Web
18.4 Tutoriel 3: Une image personnalisée
18.4.1 Première révision
18.4.2 Deuxième révision
18.5 Un client kioske VNC
18.6 Une image de base pour une clé USB de 128 Mo
18.7 Un bureau GNOME localisé avec un installateur

Appendix

19. Guide de style

19.1 Lignes directrices pour les auteurs
19.1.1 Caractéristiques linguistiques
19.1.2 Procédures
19.2 Lignes directrices pour les traducteurs
19.2.1 Conseils de traduction

Metadata

Manuel Live Systems

À propos

1. À propos de ce manuel

L'objectif principal de ce manuel est de servir de point d'accès unique à tous les documents liés au Live Systems Project et particulièrement aux logiciels produits par le projet pour Debian 8.0 «jessie». Une version mise à jour peut toujours être trouvée sur ‹http://live-systems.org/› .

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.

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.

1.1 Pour les impatients

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.

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.

Nous vous encourageons à revenir à l'étude plus approfondie du manuel, en poursuivant par exemple votre lecture par Les bases, Construire une image netboot et finissant par la lecture de la Vue d'ensemble de la personnalisation et les sections suivantes. Après cela, nous espérons que vous serez complètement excités par ce qui peut être fait avec les systèmes live et motivés pour lire le reste du manuel, du début à la fin.

1.2 Terminologie

1.3 Auteurs

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

1.4 Contribuer à ce document

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

1.4.1 Appliquer des modifications

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:

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

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

$ make build

Comme il faut un certain temps pour construire le manual dans toutes les langues prises en charge, les auteurs peuvent trouver pratique d'utiliser l'un des raccourcis de construction rapide lors de la révision de la nouvelle documentation ajoutée au manuel anglais. PROOF=1 construit live-manual au format html, mais sans les fichiers html segmentés, et PROOF=2 construit live-manual au format pdf, mais seulement les portraits A4 et US. C'est pourquoi l'utilisation de l'une ou l'autre des possibilités peut sauver une quantité considérable de temps, par exemple:

$ make build PROOF=1

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

$ make build LANGUAGES=de

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

$ make build FORMATS=pdf

Ou combiner les deux, par exemple:

$ make build LANGUAGES=de FORMATS=html

Après avoir relu votre travail et vous être assuré que tout va bien, n'utilisez pas make commit à moins que vous mettiez à jour les traductions dans le commit. Dans ce cas, ne mélangez pas les modifications apportées au manuel en anglais et les traductions dans la même livraison, mais utilisez des commits séparés. Consultez la section Traduction pour plus de détails.

1.4.2 Traduction

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:

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.

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.

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.

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.