Rights: Copyright © 2006-2012 Debian Live Project;
License: Ce programme est un logiciel libre; vous pouvez le redistribuer ou le modifier suivant les termes de la Licence Générale Publique GNU telle que publiée par la Free Software Foundation: soit la version 3 de cette licence, soit (à votre gré) toute version ultérieure.
Ce programme est distribué dans l’espoir qu’il vous sera utile, mais SANS AUCUNE GARANTIE: sans même la garantie implicite de COMMERCIALISABILITÉ ni d’ADÉQUATION À UN OBJECTIF PARTICULIER. Consultez la Licence Générale Publique GNU pour plus de détails.
Vous devriez avoir reçu une copie de la Licence Générale Publique GNU avec ce programme ; si ce n’est pas le cas, consultez http://www.gnu.org/licenses/.
Le texte complet de la Licence Générale Publique GNU peut être trouvé dans le fichier / usr/share/common-licenses/GPL-3
L'objectif principal de ce manuel est servir de point d'accès unique à tous les documents liés au projet Debian Live et particulièrement aux logiciels produits par le projet pour Debian 7.0 "wheezy". Une version mise à jour peut toujours être trouvée à ‹http://live.debian.net/›
Tandis ce manuel est principalement sur vous aider à construire un système Live et non pas sur des sujets de l'utilisateur final, un utilisateur final peut trouver des informations utiles dans ces sections: Les Bases couvrent la préparation des images pour être démarrées sur les supports ou sur le réseau, et Personnalisation des comportements au moment de l'exécution décrit certaines options qui peuvent être spécifiées à l'invite de démarrage, tels 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 en devenant super-utilisateur à l'aide de su ou en utilisant sudo. Afin de distinguer les commandes qui peuvent être exécutées par un utilisateur sans privilèges de celles nécessitant les privilèges de super-utilisateur, les commandes sont précédées respectivement par $ ou #. Ce symbole ne fait pas partie de la commande.
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, sautez aux trois tutoriels à l'avant de la section Exemples destinée à vous apprendre la construction de l'image et les bases de la personnalisation. Lire en premier En utilisant les exemples, suivie par Tutoriel 1: Une image standard, 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 Debian Live.
Nous vous encourageons à revenir à l'étude plus approfondie du manuel, la prochaine lecture peut-être Les bases, passer pour Construire une image netboot, et finissant par la lecture de la Vue d'ensemble de la personnalisation et les autres sections suivantes. En ce point, nous espérons que vous soyez complètement excités par ce que on peut faire avec Debian Live et motivés pour lire le reste du manuel, du début à la fin.
La liste des auteurs (dans l'ordre alphabétique):
Ce manuel est conçu comme un projet communautaire et toutes les propositions d'améliorations et de contributions sont bienvenues. La meilleure façon de soumettre une contribution est l'envoyer à la liste de diffusion. S'il vous plaît voir Contact pour plus d'informations.
Lorsque vous soumettez une contribution, veuillez indiquer clairement le copyright et inclure la 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.
Les sources de ce manuel sont maintenues à l'aide du logiciel de gestion de versions Git. Vous pouvez obtenir la dernière copie en exécutant:
$ git clone git://live.debian.net/git/live-manual.git
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 sisu-complete libnokogiri-ruby
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 manuel dans toutes les langues disponibles, il peut être pratique construire pour une seule langue, par exemple en exécutant:
$ make build LANGUAGES=en
Il est également possible de construire par type de document, par exemple,
$ make build FORMATS=pdf
Ou combiner les deux, par exemple:
$ make build FORMATS=html LANGUAGES=it
Les contributions au dépôt sont possibles pour tout le monde. Cependant, nous vous demandons d'envoyer les changements importants sur la liste de diffusion au préalable. Afin de faire un push au dépôt, les étapes suivantes sont nécessaires.
$ mkdir -p ~/.ssh/identity.d
$ wget http://live.debian.net/other/keys/git@live.debian.net \
-O ~/.ssh/identity.d/git@live.debian.net
$ wget http://live.debian.net/other/keys/git@live.debian.net.pub \
-O ~/.ssh/identity.d/git@live.debian.net.pub
$ chmod 0600 ~/.ssh/identity.d/git@live.debian.net*
$ cat >> ~/.ssh/config << EOF
Host live.debian.net
Hostname live.debian.net
User git
IdentityFile ~/.ssh/identity.d/git@live.debian.net
EOF
$ git clone git@live.debian.net:/live-manual.git
$ cd live-manual && git checkout debian-next
$ git commit -a -m "Adding a section on applying patches."
$ git push
Pour soumettre une traduction pour une nouvelle langue, suivez ces trois étapes:
Remarque: S'il vous plaît soyez conscients que même si les deux make commit et make build suppriment votre répertoire de construction, si vous construisez le manuel pour examiner vos modifications comme il est recommandé, et vous voulez nettoyer votre arbre git avant de les envoyer, vous pouvez utiliser make clean. Cette dernière étape n'est pas obligatoire grâce au fichier .gitignore mais il est une bonne pratique pour éviter d'envoyer certains fichiers involontairement.
Lorsque Debian Live était lancé, il y avait déjà plusieurs systèmes live basés sur debian et ils faisaient un excellent travail. Du point de vue de Debian la plupart d'entre eux ont un ou plusieurs des inconvénients suivants:
Debian est le système d'exploitation universel: Debian a un système live pour montrer autour et pour représenter le vrai, seul et unique système Debian avec les principaux avantages suivants:
Nous seulement utiliserons 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 officiels du système live.
Nous ne changerons pas les paquets. Chaque fois que nous avons besoin de changer quelque chose, nous le ferons en coordination avec le responsable du paquet dans Debian.
À 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 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.
Dans cette phase, nous n'offerons configurations alternatives. Tous les paquets sont utilisés dans leur configuration par défaut comme ils sont après une installation standard de Debian.
Chaque fois que nous avons besoin d'une configuration par défaut différente, nous le ferons en coordination avec le responsable du paquet dans Debian.
Un système de configuration des paquets est fourni avec debconf permettant la personnalisation des paquets installés sur votre image Debian Live, mais pour les images officielles seulement une configuration par défaut sera utilisée . Pour plus d'informations, s'il vous plaît voir Vue d'ensemble de la personnalisation.
Exception: Il y a quelques changements essentiels nécessaires pour mettre un système live en marche. Ces changements essentiels doivent être maintenus aussi minimes que possible et devraient être fusionnées au sein du dépôt Debian s'il est possible.
Les exigences pour la création des images Debian Live sont très peu:
Notez que l'utilisation de Debian ou une distribution dérivée de Debian n'est pas nécessaire - live-build fonctionne sur presque toute distribution avec les exigences ci-dessus.
Vous pouvez installer live-build dans un certain nombre de façons différentes:
Si vous utilisez Debian, la méthode recommandée consiste à installer live-build à partir du dépôt Debian.
Il suffit d'installer live-build comme n'importe quel autre paquet:
# apt-get install live-build
ou
# aptitude install live-build
live-build est développé en utilisant le système de contrôle de version Git. Dans les systèmes basés sur Debian, cela est fourni par le paquet git. Pour examiner le dernier code, exécutez:
$ git clone git://live.debian.net/git/live-build.git
Vous pouvez compiler et installer votre propre paquet Debian en exécutant:
$ cd live-build
$ dpkg-buildpackage -rfakeroot -b -uc -us
$ cd ..
Maintenant, installez les fichiers récemment construits que vous intéresse, p. ex
# dpkg -i live-build_2.0.8-1_all.deb
Vous pouvez également installer live-build directement sur votre système en exécutant:
# make install
et le désinstaller avec:
# make uninstall
Si vous ne souhaitez pas de créer ou d'installer live-build à partir des sources, vous pouvez utiliser des instantanés. Ils sont construits automatiquement à partir de la dernière version du dépôt Git et ils sont disponibles à ‹http://live.debian.net/debian/›.
Remarque: Vous n'avez pas besoin d'installer live-boot ou live-config sur votre système afin de créer des systèmes Debian 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.
Tous deux live-boot et live-config sont disponibles dans le dépôt Debian comme expliqué dans Installation de live-build.
Pour utiliser les dernières sources du git, vous pouvez suivre le procédure ci-dessous. S'il vous plaît assurer que vous êtes familiarisé avec les termes mentionnés dans Termes.
$ git clone git://live.debian.net/git/live-boot.git
$ git clone git://live.debian.net/git/live-config.git
Consultez les pages de manuel de live-boot et live-config pour plus de détails sur la personnalisation si c'est votre raison pour la création de vos paquets à partir des sources.
Vous devez créer sur votre distribution objectif ou en chroot contenant votre plateforme objectif: cela signifie que si votre objectif est wheezy alors vous devez créer sur wheezy.
Utilisez un système de construction automatique personnel tel que pbuilder ou sbuild si vous avez besoin pour créer live-boot pour une distribution objectif qui diffère de votre système de construction. Par exemple, pour les images live de wheezy, créez live-boot dans un chroot wheezy. Si votre distribution objectif correspond à votre distribution vous pouvez créer directement sur le système de construction en utilisant dpkg-buildpackage (fourni par le paquet dpkg-dev) :
$ cd live-boot
$ dpkg-buildpackage -b -uc -us
$ cd ../live-config
$ dpkg-buildpackage -b -uc -us
Comme live-boot et live-config sont installés par le système live-build, l'installation des paquets dans le système hôte ne suffit pas: vous devez traiter les fichiers .deb générés comme aucun autre paquet personnalisé. S'il vous plaît voir Personnalisation de l'installation de paquets pour plus d'informations. Vous devriez prêter une attention particulière à Dépôts additionnels.
Vous pouvez laisser live-build utiliser automatiquement les derniers instantanés de live-boot et live-config configurant un dépôt de tiers dans votre répertoire de configuration de live-build. En supposant que vous avez déjà créé un arbre de configuration dans le répertoire courant avec lb config:
$ lb config --archives live.debian.net
Ce chapitre contient un bref aperçu du procès 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, supports optiques ou un périphérique USB de stockage portable. Dans certains cas particuliers, tels que l'utilisation de la persistance, le type hdd peut être plus approprié pour les périphériques USB. Le chapitre se termine avec des instructions pour la construction et l'utilisation d'une image net , qui est un peu plus compliqué 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 est terminée, il 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 de l'image.
Tout au long du chapitre, nous ferons souvent référence à la valeur par défaut des noms de fichiers produits par live-build. Si vous téléchargez une image précompilée les noms de fichiers peuvent varier.
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 d'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).
Avec Debian Live, c'est un système Debian GNU/Linux, construit pour une des architectures supportées (actuellement amd64, i386, PowerPC et SPARC). Il est fait à partir des éléments suivants:
Vous pouvez utiliser live-build pour construire l'image du système à partir de vos spécifications, configurer un noyau Linux, son initrd, et un chargeur d'amorçage pour les exécuter, tout dans un format en fonction du support (image ISO9660, image disque, etc.)
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, exécuter la séquence suivante de commandes live-build pour créer une image ISO hybride de base contenant tout le système Debian standard sans X.org. Elle est appropriée pour être gravée sur CD ou DVD, et également peut être copiée sur une clé USB.
Tout d'abord, exécutez la commande lb config. Cela va créer une hiérarchie "config/" dans le répertoire courant pour l'utilisation par d'autres commandes:
$ lb config
Aucun paramètre n'est passé à lb config, donc défauts seront utilisés pour l'ensemble de ses diverses options. Voir La commande lb config pour plus de détails.
Maintenant que la hiérarchie "config/" existe, créez l'image avec la commande lb build :
# lb build
Ce processus peut prendre un certain temps, en fonction de la vitesse de votre connexion réseau. Quand il est complet, il devrait y avoir un fichier image binary.hybrid.iso prêt à l'emploi, dans le répertoire courant.
Après la construction ou le téléchargement d'une image ISO hybride, qui peut être obtenue sur ‹http://www.debian.org/CD/live/›, l'étape suivante est d'habitude préparer votre support pour le démarrage, soit sur CD-R(W) ou DVD-R(W), des supports optiques ou une clé USB.
Graver une image ISO est facile. Il suffit d'installer wodim et l'utiliser à partir de la ligne de commande pour graver l'image. Par exemple:
# apt-get install wodim
$ wodim binary.hybrid.iso
Les images ISO préparées avec la commande isohybrid comme les images iso-hybrid produites par défaut, peuvent être simplement copiées sur une clé USB avec dd ou un logiciel équivalent. Brancher une clé USB avec une capacité suffisamment grande pour votre fichier image et déterminez quel dispositif elle est, que nous appellons ci-dessous ${USBSTICK}. C'est le fichier de périphérique de votre clé, tel que /dev/sdb, pas une partition, tel que /dev/sdb1! Vous pouvez trouver le nom du périphérique en regardant la sortie de dmesg après avoir branché le dispositif, ou mieux encore, ls -l /dev/disk/by-id.
Une fois que vous êtes sûr d'avoir le nom correct de l'appareil, utilisez la commande dd pour copier l'image sur la clé. Ceci écrasera tout fichier déjà existant sur votre clé!
$ dd if=binary.hybrid.iso of=${USBSTICK}
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 pénétrer dans 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.
Une fois que vous avez démarré le support, vous êtes présenté avec un menu de démarrage. Si vous appuyez simplement sur enter 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.
En supposant que vous avez sélectionné Live et démarré une image de bureau live par défaut, après les messages de démarrage défilent, vous devriez être automatiquement connecté au compte user et voir un bureau, prêt à l'emploi. Si vous avez démarré une image de la console uniquement, tels que saveurs standard ou rescue des images précompilées, vous devriez être automatiquement connecté à la console pour le compte user et voir une invite du shell, prêt à l'emploi.
Il peut être un gain de temps important pour le développement des images live les faire fonctionner dans une machine virtuelle (VM). Ce n'est pas sans ses avertissements:
À condition que vous pouvez travailler avec ces obstacles, examinez les logiciels VM disponibles et choisissez celui qui convient à vos besoins.
La VM la plus polyvalente de Debian est QEMU. Si votre processeur possède un support matériel pour la virtualisation, vous pouvez utiliser le paquet qemu-kvm; La description du paquet qemu-kvm énumère brièvement les exigences.
Tout d'abord, installez qemu-kvm si votre processeur le soutient. 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 valuable pour créer des images disque virtuels avec qemu-img.
# apt-get install qemu-kvm qemu-utils
Démarrer une image ISO est simple:
$ kvm -cdrom binary.hybrid.iso
Voir les pages de manuel pour plus de détails.
Afin de tester l'ISO avec virtualbox-ose:
# apt-get install virtualbox-ose virtualbox-ose-dkms
$ virtualbox
Créer une nouvelle machine virtuelle, modifiez les paramètres de stockage pour utiliser binary.hybrid.iso comme le périphérique CD/DVD et démarrer la machine.
$ echo virtualbox-ose-guest-x11 >> config/package-lists/my.list.chroot
La construction d'une image HDD est similaire à une ISO hybride à tous les régards, sauf que vous spécifiez -b hdd et le nom du fichier résultant est binary.img qui ne peut être brûlé sur des supports optiques. Il convient pour le démarrage à partir de clés USB, disques durs USB, et divers autres dispositifs de stockage portables. Normalement, une image ISO hybride peut être utilisée à cette fin au lieu, mais si vous avez un BIOS qui ne gère pas correctement les images hybrides, ou si vous voulez utiliser l'espace disponible sur le support à certaines fins, tel que la persistance d'une partition, vous devez utiliser une image HDD.
# lb clean --binary
Exécutez la commande lb config comme avant, sauf que cette fois en spécifiant le type d'image HDD:
$ lb config -b hdd
Maintenant construire l'image avec la commande lb build
# lb build
Quand la création de l'image est finie, un fichier binary.img doit être présent dans le répertoire courant.
L'image binaire générée contient une partition VFAT et le chargeur de démarrage syslinux, prêtes à être écrites directement sur une clé USB. Comme l'utilisation d'une image HDD est juste comme l'utilisation d'une image ISO hybride sur USB, suivez les instructions Utiliser une image live ISO hybride, à l'exception du nom de fichier binary.img en lieu de binary.hybrid.iso.
D'abord, installer qemu comme décrit ci-dessus dans Test d'une image ISO avec QEMU. Ensuite, exécutez kvm ou qemu, selon la version que votre système hôte a besoin, précisant binary.img comme le premier disque dur.
$ kvm -hda binary.img
Pour utiliser l'espace libre restant après avoir copié binary.img sur une clé USB, utilisez un outil de partitionnement tel que gparted ou parted afin de créer une nouvelle partition sur la clé. La première partition sera utilisée par le système Debian Live.
# gparted ${USBSTICK}
Après la partition est créée, où ${PARTITION} est le nom de la partition, tel que /dev/sdb2, vous devez créer un système de fichiers sur elle. Un choix possible serait ext4.
# mkfs.ext4 ${PARTITION}
Remarque: Si vous voulez utiliser l'espace supplémentaire avec Windows, apparemment cet OS ne peut normalement pas accéder à n'importe quelle partition, mais 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éponses faciles. Rappelez-vous: Chaque fois que vous installez une nouvelle binary.img sur la clé, toutes les données sur la clé seront perdues parce que la table de partition est écrasée par le contenu de l'image, vous devez sauvegarder votre partition supplémentaire d'abord la restaurer à nouveau après la mise à jour de l'image live.
La séquence de commandes suivante va créer une image NetBoot de base contenant le système Debian standard sans X.org. Elle peut être démarrée sur le réseau.
# lb clean --binary
Exécutez la commande comme suit pour configurer votre image pour démarrer sur le réseau:
$ lb config -b net --net-root-path "/srv/debian-live" --net-root-server "192.168.0.1"
Contrairement à les images ISO et HDD le démarrage sur le réseau ne serve pas l'image du système de fichiers pour le client, afin que les fichiers doivent être servis via NFS. Les options --net-root-path et --net-root-server spécifien 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.
Maintenant construire l'image avec la commande lb build
# lb build
Dans un démarrage réseau, le client exécute un petit morceau de logiciel qui réside habituellement sur l'EPROM de la carte Ethernet. Ce programme envoie une requête DHCP pour obtenir une adresse IP et les informations sur ce qu'il faut faire ensuite. Typiquement, la prochaine étape est 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.
Par exemple, si vous décompressez le fichier généré binary-net.tar.gz dans le répertoire /srv/debian-live, vous trouverez l'image du système de fichiers dans live/filesystem.squashfs et le noyau, initrd et le chargeur d'amorçage pxelinux dans tftpboot/debian-live/i386.
Nous devons maintenant configurer trois services sur le serveur pour activer le démarrage sur le réseau: le serveur DHCP, serveur TFTP et le serveur NFS.
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.
Voici un exemple source d'inspiration, écrit pour le serveur ISC DHCP isc-dhcp-server dans le fichier de configuration /etc/dhcp/dhcpd.conf:
# /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;
next-server servername;
filename "pxelinux.0";
}
Cela sert le noyau et le ramdisk initial pour le système au moment de l'exécution.
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écuter comme utilisateur root la commande suivante:
# dpkg-reconfigure -plow tftpd-hpa
et remplissez le nuveau répertoire du serveur tftp
Une fois 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.
Vous devez installer le paquet nfs-kernel-server.
Ensuite, rendre l'image du système de fichiers disponible via NFS en ajoutant une ligne comme la suivante /etc/exports:
/srv/debian-live *(ro,async,no_root_squash,no_subtree_check)
et indiquer au serveur NFS sur cette exportation avec la commande suivante:
# exportfs -rv
La configuation de ces trois services peut être un peu dificile. Vous pourriez avoir besoin de patience pour obtenir que tous travaillent ensemble. Pour plus d'informations, consultez le wiki syslinux à ‹http://syslinux.zytor.com/wiki/index.php/PXELINUX› ou la section Debian Installer Manual's TFTP Net Booting à ‹http://d-i.alioth.debian.org/manual/en.i386/ch04s05.html›. Ils pourraient aider parce que leurs processus sont très semblables.
La création d'images NetBoot est facile avec la magie de live-build, mais les essais des images sur des machines physiques peuvent prendre vraiment beaucoup de temps.
Afin de rendre notre vie plus facile, nous pouvons utiliser la virtualisation. Il y a deux solutions.
Èditer /etc/qemu-ifup:
#!/bin/sh
sudo -p "Password for $0:" /sbin/ifconfig $1 172.20.0.1
echo "Executing /etc/qemu-ifup"
echo "Bringing up $1 for bridged mode..."
sudo /sbin/ifconfig $1 0.0.0.0 promisc up
echo "Adding $1 to br0..."
sudo /usr/sbin/brctl addif br0 $1
sleep 2
Obtenir, ou construire un grub-floppy-netboot (dans le svn).
Lancer qemu avec "-net nic,vlan=0 -net tap,vlan=0,ifname=tun0"
#!/usr/bin/vmware
config.version = "8"
virtualHW.version = "4"
memsize = "512"
MemAllowAutoScaleDown = "FALSE"
ide0:0.present = "FALSE"
ide1:0.present = "FALSE"
floppy0.present = "FALSE"
sound.present = "FALSE"
tools.remindInstall = "FALSE"
ethernet0.present = "TRUE"
ethernet0.addressType = "generated"
displayName = "Test Boot PXE"
guestOS = "other"
ethernet0.generatedAddress = "00:0c:29:8d:71:3b"
uuid.location = "56 4d 83 72 5c c4 de 3f-ae 9e 07 91 1d 8d 71 3b"
uuid.bios = "56 4d 83 72 5c c4 de 3f-ae 9e 07 91 1d 8d 71 3b"
ethernet0.generatedAddressOffset = "0"
Ce chapitre contient un aperçu des trois principaux outils utilisés dans les systèmes de construction Debian Live: live-build, live-boot et live-config.
live-build est une collection de scripts pour construire des systèmes Debian Live. Ces scripts sont aussi appelés "commandes".
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.
Plusieurs concepts sont similaires à ceux dans le paquet Debian debhelper écrit par Joey Hess:
Contrairement à debhelper, live-build contient un outil pour générer une arborescence de configuration, lb config. Cela pourrait être considéré comme similaire à des outils tels que dh-make. Pour plus d'informations à propos de lb config, s'il vous plaît voir La commande lb config.
Le reste de cette section examine les trois commandes les plus importantes:
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 fastidieux et source d'erreurs, la commande lb config peut être utilisée pour créer une arborescence de configuration.
Exécuter lb config sans aucun argument crée un sous-répertoire config/ dont il remplit avec certains paramètres, et un sous-répertoire auto/ avec une arborescence de fichiers.
$ lb config
[2012-03-19 15:17:14] lb_config
P: Considering defaults defined in /etc/live/build.conf
P: Creating config tree for a debian system
L'utilisation de lb config sans aucun argument serait approprié pour les utilisateurs qui ont besoin d'une image de base, ou qui ont l'intention d'offrir plus tard, une configuration plus complète via auto/config (voir Gestion d'une configuration pour plus de détails).
Normalement, vous voulez spécifier certaines options. Par exemple, pour inclure la liste du paquet «gnome» dans votre configuration:
$ lb config -p gnome
Il est possible de spécifier plusieurs options, telles que:
$ lb config --binary-images net --bootappend-live "hostname=live-machine username=live-user" ...
Une liste complète des options est disponible dans la page de manuel de lb_config.
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 pour construire votre système Live.
Le travail de la commande lb clean est 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 binary. Voir la page de manuel de lb_clean pour une liste complète des options.
live-boot est une collection de scripts fournissant hooks pour initramfs-tools, utilisé pour générer un initramfs capable de démarrer des systèmes live, comme ceux créés par live-build. Cela inclut les ISOs de Debian Live, netboot tarballs, et les images pour clés USB.
Au démarrage il va chercher un support en lecture seule qui contient un répertoire /live/ où un système de fichiers racine (souvent une image du système de fichiers compressée comme squashfs) est stocké. S'il est trouvé, il va créer un environnement accessible en écriture, en utilisant aufs, afin que systémes similaires à Debian puissent démarrer à partir de ça.
Plus d'information sur initial ramfs dans Debian peut être trouvé dans le Debian Linux Kernel Handbook à ‹http://kernel-handbook.alioth.debian.org/› dans le chapitre sur initramfs.
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 tâches telles que l'établissement du nom d'hôte, paramètres régionaux et le fuseau horaire, la création de l'utilisateur live, l'inhibition des cron jobs et autologin de l'utilisateur live.
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.
Les configurations live sont rarement parfaites du premier coup. Vous aurez probablement besoin de faire une série de révisions jusqu'à ce que vous êtes satisfait. Cependant, des incohérences peuvent se glisser dans votre configuration d'une révision à la prochaine si vous ne faites pas attention. Le principal problème est, une fois qu'une variable est donnée une valeur par défaut, cette valeur ne sera pas recalculée à partir d'autres variables qui peuvent changer dans les révisions ultérieures.
Par exemple, lorsque la distribution est d'abord définie, nombreuses variables sont assignées des valeurs par défaut qui conviennent à cette distribution. Cependant, si vous décidez ultérieurement de modifier la distribution, ces variables dépendantes conservent les anciennes valeurs qui ne sont plus appropriées.
Un deuxième problème lié est que si vous exécutez lb config et ensuite mettez à jour une nouvelle version de live-build qui a changée l'un des noms des variables, vous découvrirez ce que par un examen manuel des variables dans votre fichiers dans config/*, que vous devrez ensuite utiliser pour définir l'option appropriée à nouveau.
Tout cela serait une nuisance terrible si ce n'était pas pour les scripts auto/*, simples emballages pour les commandes lb config, lb build et lb clean qui sont conçus pour vous aider à gérer votre configuration. Il suffit de créer un script auto/config contenant la commande lb config avec toutes les options désirées, et un auto/clean qui supprime les fichiers contenant les valeurs des variables de configuration, et chaque fois que vous lancez lb config et lb clean, ces fichiers seront exécutés. Cela permettra d'assurer que votre configuration a une cohérence interne d'une révision à l'autre et d'une version de live-build à la suivante (bien que vous aurez encore de prendre soin et lire la documentation lorsque vous mettez live-build à niveau pour faire les ajustements nécessaires).
Utiliser des exemples de scripts auto tels que les suivants comme point de départ pour votre nouvelle configuration de live-build. Prenez note que lorsque vous appelez la commande lb que votre script auto emballage, vous devez spécifier noauto comme paramètre afin de s'assurer que le script automatique n'est pas appelé à nouveau, de façon récursive. Aussi, n'oubliez pas de s'assurer que les scripts sont exécutables (par exemple chmod 755 auto/*).
auto/config
#!/bin/sh
lb config noauto \
--package-lists "standard" \
"${@}"
auto/clean
#!/bin/sh
lb clean noauto "${@}"
rm -f config/binary config/bootstrap \
config/chroot config/common config/source
rm -f binary.log
auto/build
#!/bin/sh
lb build noauto "${@}" 2>&1 | tee binary.log
Nous expédions maintenant scripts auto d'exemple avec live-build sur la base des exemples ci-dessus. Vous pouvez copier ces comme point de départ.
$ cp /usr/share/live/build/examples/auto/* auto/
Editer auto/config, en changeant ou en ajoutant des options comme bon vous semble. Dans l'exemple ci-dessus, --package-lists standard est fixé à la valeur par défaut. Changez ce à une valeur appropriée pour votre image (ou le supprimer si vous voulez utiliser par défaut) et ajouter des options supplémentaires dans les lignes suivantes.
Ce chapitre donne un aperçu des diverses façons dont vous pouvez personnaliser un système Debian Live.
Les options de configuration d'un système live sont divisés 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 au moment du 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 ceux qui arrivent plus tard, appliquées par live-config. Toute option d'amorçage peut être modifiée par l'utilisateur en le spécifiant à 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 au système live sans spécifier 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.
Les options de configuration pendant la construction sont décrites dans les pages de manuel pour live-boot and live-config. Bien que les paquets live-boot et live-config sont installés dans le système live que vous construisez, il est recommandé que vous les installez aussi sur votre système de construction pour référence facile lorsque vous travaillez sur votre configuration. On peut faire ça sans danger, car aucun des scripts contenus dans eux sont exécutés à moins que le système est configuré comme un système live.
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 peupler le répertoire chroot avec des paquets pour faire un système Debian de base. Il est suivi 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 démarrable, 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 les supports objectif en dehors du système de fichiers du système live. Après l'image live est construite, s'il est activé, le tarball des sources est construit dans l'étape source.
Dans chacune de ces étapes, il ya une séquence particulière dans laquelle les commandes sont appliquées. Ceux-ci sont disposées de telle manière à assurer que les personnalisations peuvent être superposées de manière raisonnable. Par exemple, dans l'étape chroot, les preseeds sont appliqués avant tous les paquets sont installés, les paquets sont installés avant tous les fichiers locaux inclus ou les correctifs soient appliqués, et les hooks sont exécutés plus tard, après que tous les matériaux sont en place.
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 peut fournir configurations du système au moment de la construction qui serait lourd de 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 au temps de construction ou au moment du démarrage, augmentant la flexibilité déjà considérable de debian-live avec code de votre choix.
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.
La personnalisation la plus fondamentale d'un système Debian Live peut-être la sélection de paquets à inclure dans l'image. Ce chapitre vous guide tout au long des différentes options dans certains moments de la construction pour personnaliser l'installation des paquets avec live-build. Le plus large choix influençant les paquets qui sont disponibles pour l'installation dans l'image sont les zones de distribution et les sections (archive areas). Afin de garantir 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 backports, paquets expérimentaux ou personnalisés, ou inclure des paquets directement en tant que fichiers. Vous pouvez définir vos propres listes de paquets à inclure, utiliser des listes prédéfinies de live-build, utiliser tâches tasksel, ou une combinaison des trois. Enfin, un certain nombre d'options donnent un certain contrôle sur apt, ou si vous préférez, aptitude, au moment de la construction quand les paquets sont installés. Vous pouvez trouver ces très pratique si vous utilisez un proxy, vous voulez désactiver l'installation des paquets recommandés pour économiser l'espace, ou avez besoin de contrôler quels versions des paquets sont installés via APT pinning, pour n'en nommer quelques possibilités.
La distribution que vous choisissez a le plus large impact sur les paquets qui sont disponibles à inclure dans votre image live. Indiquez le nom de code, qui est par défaut wheezy pour la version de live-build dans wheezy. Toute distribution actuelle dans l'archive Debian peut être spécifié par son nom de code ici. (Voir Termes pour plus de détails.) L'option --distribution non seulement influence la source des paquets dans l'archive, mais aussi dit live-build comme it doit construire chaque distribution soutenue. Par exemple, pour construire contre unstable, sid, précisez:
$ lb config --distribution sid
Dans l'archive de distribution, les «archive areas» sont les principales divisions de l'archive. Dans Debian, ce sont main, contrib et non-free. Seulement main contient des logiciels qui font partie de la distribution Debian, donc qui est la valeur par défaut. Une ou plusieurs valeurs peuvent être spécifiées, par exemple
$ lb config --archive-areas "main contrib"
Soutien expérimental est disponible pour certains dérivés de Debian grâce à l'option --mode. L'option debian est définie par défaut, même si vous êtes en créant sur un système non-Debian. Si vous spécifiez --mode ubuntu ou --mode emdebian, les noms de distribution et des areas des archives pour les dérivés spécifiés sont soutenues au lieu de ceux de Debian. Le mode modifie également le comportement de live-build en fonction des dérivés.
Remarque: Les projets pour lesquels ces modes ont été ajoutés sont principalement responsables d'aider les utilisateurs de ces options. Le projet Debian Live, à son tour, fournit un soutien de développement sur une base des meilleurs efforts seulement, en fonction des commentaires sur les projets dérivés que nous n'avons pas développé ou soutenu nous-mêmes.
L'archive Debian est répliqué sur un grand réseau de miroirs autour du monde pour que les habitants dans chaque région puissent choisir un miroir proche avec la meilleur vitesse de téléchargement. Chacune des options --mirror-* régissent quel miroir de distribution est utilisée à différentes étapes de la construction. Rappelez-vous de Étapes de la construction que l'étape bootstrap c'est quand le chroot est initialement peuplée par debootstrap avec un système minimal, et l'étape chroot c'est 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ées 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.
Pour définir les miroirs de distribution utilisés au temps de construction pour pointer vers un miroir local, il suffit de fixer --mirror-bootstrap , --mirror-chroot-security et --mirror-chroot-backports comme suit.
$ lb config --mirror-bootstrap http://localhost/debian/ \
--mirror-chroot-security http://localhost/debian-security/ \
--mirror-chroot-backports http://localhost/debian-backports/
Le miroir chroot, spécifié par --mirror-chroot, par défaut, c'est la valeur --mirror-bootstrap.
Les options --mirror-binary* régissent les miroirs de distribution placés dans l'image binaire. Ils peuvent être utilisés pour installer des paquets supplémentaires lors de l'exécution du système live. Les valeurs par défaut emploient cdn.debian.net, un service qui choisit un miroir géographiquement proche basé sur le numéro IP de l'utilisateur. C'est un choix approprié lorsque vous ne pouvez pas prédire quel miroir sera mieux pour tous vos utilisateurs. Ou vous pouvez spécifier vos propres valeurs, comme indiqué dans l'exemple ci-dessous. Une image construite avec cette configuration seulement serait appropriée pour les utilisateurs sur un réseau où "mirror" est accessible.
$ lb config --mirror-binary http://mirror/debian/ \
--mirror-binary-security http://mirror/debian-security/
Vous pouvez ajouter d'autres dépôts, élargissant votre choix de paquets au-delà ceux disponibles dans votre distribution objectif. Il peut être, par exemple, pour backports, expérimentaux ou des paquets personnalisés. Pour configurer des dépôts supplémentaires, créer les fichiers config/archives/your-repository.list.chroot, et/ou config/archives/your-repository.list.binary. Comme avec les options --mirror-*, elles gouvernent 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 pour les utiliser au moment de l'exécution du système live.
Par exemple, config/archives/live.list.chroot vous permet d'installer les paquets du dépôt des instantanés debian live au moment de la construction du système live.
deb http://live.debian.net/ sid-snapshots main contrib non-free
Si vous ajoutez la même ligne à config/archives/live.list.binary, le dépôt sera ajouté au répertoire /etc/apt/sources.list.d/ de votre système live.
Si ces fichiers existent, ils seront sélectionnés automatiquement.
Vous devriez également mettre la clé GPG utilisée pour signer le dépôt dans fichiers config/archives/your-repository.key.{binary,chroot}
Remarque: certains dépôts de paquets préconfigurés sont disponibles pour une sélection facile grâce à l'option --archives, par exemple pour activer les instantanés live, il suffit une simple commande:
$ lb config --archives live.debian.net
Il y a un certain nombre de façons de choisir quels paquets live-build va installer dans votre image, couvrant une variété de besoins différents. Vous pouvez tout simplement nommer les paquets individuels à installer dans une liste de paquets. Vous pouvez également choisir grandes listes prédéfinies de paquets, ou utiliser des tâches APT. Et enfin, vous pouvez placer 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.
Les listes de paquets sont un excellent moyen d'exprimer quels paquets doivent être installés. La syntaxe de la liste soutient les fichiers inclus et sections conditionnelles qui les rend facile de construire à partir d'autres listes et de les adapter pour une utilisation dans configurations multiples. Vous pouvez utiliser des listes de paquets prédéfinies, offrant une sélection modulaire de paquets provenants de chacun des environnements de bureau majeurs et certaines listes de but spécial, ainsi que les autres listes standard sont basées sur elles. Vous pouvez également fournir votre propre liste de paquets, ou utiliser une combinaison des deux.
Remarque: Le comportement de live-build pour spécifier un paquet qui n'existe pas est déterminé par votre choix de l'utilité APT. Voir Choisir apt ou aptitude pour plus de détails.
La façon la plus simple d'utiliser des listes consiste à spécifier une ou plusieurs listes prédéfinies avec la option --package-lists. Par exemple:
$ lb config --package-lists "gnome rescue"
L'emplacement par défaut pour les fichiers liste sur votre système est /usr/share/live/build/package-lists/. Pour déterminer les paquets dans une liste donnée, lire le fichier correspondant, en accordant une attention aux fichiers inclus et les conditionnels tels que décrits dans les sections suivantes.
Vous pouvez compléter ou remplacer entièrement les listes fournies en utilisant listes de paquets locaux stockées dans config/package-lists/.
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.
Remarque: Si vous ne spécifiez pas le suffixe de l'étape, la liste sera utilisée pour les deux étapes. Normalement, vous voulez spécifier .list.chroot de sorte que les paquets seront 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.
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 les supports 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.
Les listes de paquets qui sont incluses avec live-build font un grand usage des «includes». Reportez-vous à celles-ci dans le répertoire /usr/share/live/build/package-lists/, car elles servent d'exemples pour savoir comment écrire vos propres listes.
Par exemple, pour faire une liste qui comprend la liste prédéfinie gnome, plus iceweasel, créer config/package-lists/my.list.chroot avec le contenu suivant:
#include <gnome>
iceweasel
Toutes les variables de configuration de live-build stockées dans config/* (sans le préfixe LB_) peuvent être utilisées dans instructions conditionnelles dans les listes de paquets. Généralement, cela signifie une option lb config majuscule et avec tirets changés en caractères de soulignement. Mais en pratique, c'est seulement ceux qui influencent la sélection des paquets qui font sens, comme DISTRIBUTION, ARCHITECTURES ou ARCHIVE_AREAS.
Par exemple, pour installer ia32-libs si --architectures amd64 est spécifié:
#if ARCHITECTURES amd64
ia32-libs
#endif
Vous pouvez tester pour un certain nombre de valeurs, par exemple pour installer memtest86+ si --architectures i386 ou --architectures amd64 est spécifié:
#if ARCHITECTURES i386 amd64
memtest86+
#endif
Vous pouvez également tester contre des variables qui peuvent contenir plus d'une valeur, par exemple pour installer vrms si contrib ou non-free est spécifié via --archive-areas:
#if ARCHIVE_AREAS contrib non-free
vrms
#endif
Un conditionnel peut entourer une directive #include:
#if ARCHITECTURES amd64
#include <gnome-full>
#endif
L'imbrication des conditionnels n'est pas soutenu.
L'installateur Debian offre l'utilisateur le choix d'un certain nombre de listes présélectionnées de paquets, chacune centrée sur un type particulier de système ou d'une tâche pour laquelle un système peut être utilisé, comme «environnement de bureau graphique», «serveur de messagerie» ou «portable». Ces listes sont appelés «tâches» (Tasks) et sont soutenues par APT grâce à l'option «Task:» Vous pouvez spécifier une ou plusieurs tâches à live-build en les plaçant dans une liste dans config/task-lists/, comme dans l'exemple ci-dessous.
$ lb config
$ echo "mail-server file-server" >> config/task-lists/my.list.chroot
Les tâches principales disponibles dans l'installateur Debian peuvent être listées avec tasksel --list-tasks dans le système live. Le contenu de n'importe quelle tâche, y compris celles non incluses dans cette liste, peuvent être examinées avec tasksel --task-packages.
Les tâches de bureau et de la 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 aucun n'est offert dans le menu tasksel. De même, il n'y a pas éléments de menu pour les tâches des langues, mais le choix de la langue de l'utilisateur lors de l'installation influence le choix des tâches de la langue correspondante.
Lors du développement d'une image de bureau live, l'image généralement amorce directement à un bureau de travail, le choix du environnement de bureau et la langue par défaut ayant été fait au moment de la construction, non pas au moment de l'exécution comme dans le cas de l'installateur de Debian. Cela ne veut pas dire qu'une image live ne pourrait être construite pour soutenir plusieurs environnements de bureau ou de plusieurs langues et offrir à l'utilisateur un choix, mais ce n'est pas le comportement par défaut de live-build.
Parce qu'il n'y a pas aucune disposition faite automatiquement pour les tâches de la langue, qui comprennent des éléments tels que des polices spécifiques de la langue et des paquets de méthodes de saisie, si vous les voulez, vous devez les spécifier dans votre configuration. Par exemple, une image de bureau GNOME contenant soutien pour le japonais pourrait inclure les tâches suivantes:
$ lb config
$ echo "gnome-desktop desktop standard laptop" >> config/task-lists/my.list.chroot
$ echo "japanese japanese-desktop japanese-gnome-desktop" >> config/task-lists/my.list.chroot
Comme les tâches de bureau sont des tâches «internes», pour chaque tâche de saveur de bureau incluse dans l'image, la valeur correspondante, si elle diffère de la valeur par défaut, "gnome", doit être préconfigurée dans la variable debconf «tasksel/desktop", ou bien tasksel ne la reconnaîtra pas et ne l'installera pas. Ainsi:
$ lb config
$ echo 'tasksel tasksel/desktop multiselect kde' >> config/preseed/my.preseed.chroot
Ce paramètre peut prendre plusieurs valeurs, par exemple "lxde xfce" au lieu de "kde".
Tandis qu'il est contre la philosophie de Debian Live, il peut parfois être nécessaire de construire un système live avec des versions modifiées des paquets qui sont dans le dépôt Debian. C'est peut-être pour modifier ou soutenir des fonctionnalités supplémentaires, des langues et branding, ou même pour supprimer des éléments dans les paquets existants qui sont indésirables. De même, les paquets "de tiers" peuvent être utilisés pour ajouter des fonctionnalités sur mesure et/ou propriétaires.
Cette section ne couvre pas les conseils concernant la construction ou la maintenance des paquets modifiés. La méthode de Joachim Breitner 'How to fork privately' ‹http://www.joachim-breitner.de/blog/archives/282-How-to-fork-privately.html› peut, cependant, être d'intérêt. La création de paquets sur mesure est traité dans le Debian New Maintainers' Guide at ‹http://www.debian.org/doc/maint-guide/› et ailleurs
Il y a deux façons d'installer des paquets personnalisés modifiés:
Utilisant packages.chroot est plus simple à réaliser et utile pour les personnalisations ponctuels mais a un certain nombre d'inconvénients, tout en utilisant un dépôt personnalisé APT est plus fastidieux à mettre en place.
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 spécifier ailleurs.
Les paquets doivent être nommés de la manière prescrite. Une façon simple de le faire consiste à utiliser dpkg-name.
L'utilisation de packages.chroot pour l'installation de paquets personnalisés a des inconvénients:
Contrairement à l'utilisation de packages.chroot, lorsque vous utilisez un dépôt personnalisé APT vous devez vous assurer que vous spécifiez les paquets ailleurs. Voir Choisir les paquets à installer pour plus de détails.
Si créer un dépôt APT pour installer des paquets personnalisés peut sembler un effort inutile, l'infrastructure peut être facilement ré-utilisée à une date ultérieure pour offrir les mises à jour des paquets modifiés.
live-build utilise apt pour installer tous les paquets dans le système live donc il héritera les 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 différents numéros de version, APT choisira d'installer le paquet avec la numéro de version supérieur.
Pour cette raison, vous pouvez incrémenter le numéro de version dans les fichiers debian/changelog de vos paquets personnalisés pour s'assurer que votre version modifiée est installée en lieu d'une dans les dépôts officiels Debian. Cela peut aussi être atteint en modifiant les préférences d'APT pinning dans le système live - voir APT pinning pour plus d'informations.
Vous pouvez configurer APT par un certain nombre d'options appliquées uniquement au moment de la construction. (La configuration d'APT utilisé dans le système live en fonctionnement peut être configurée de façon normale pour un système live, qui est, 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.
Vous pouvez choisir d'utiliser soit apt ou aptitude. Quel logiciel est utilisé est régi par l'argument --apt de lb config. Choisissez la méthode du comportement préférée pour l'installation de paquets, la différence notable étant la manière dont les paquets manquants sont traités.
Une configuration communément requis par APT est pour faire face à la construction d'une image derrière un proxy. Vous pouvez spécifier votre proxy APT avec les options --apt-ftp-proxy ou --apt-http-proxy si nécessaire, par exemple
$ lb config --apt-http-proxy http://proxy/
Vous pouvez avoir besoin d'économiser de l'espace sur les supports d'images, auquel cas l'un ou l'autre ou les deux options suivantes peuvent être d'intérêt.
Si vous ne voulez pas inclure les indices d'APT dans l'image, vous les pouvez omettre avec:
$ lb config --apt-indices false
Cela ne influencera les entrées dans /etc/apt/sources.list, mais simplement de savoir si /var/lib/apt contient les fichiers indices ou non. La contrepartie est que APT a besoin de ces indices afin d'opérer dans le système live, alors avant de procéder à apt-cache search ou apt-get install, par exemple, l'utilisateur doit faire apt-get update pour créer ces indices.
Si vous trouvez que l'installation des paquets recommandés gonfle votre image trop, vous pouvez désactiver l'option par défaut d'APT avec:
$ lb config --apt-recommends false
La contrepartie ici est que si vous n'installez pas les paquets recommandés par un paquet, c'est-à-dire, "paquets qu'on trouverai avec celui-ci dans toute installation standard" (Debian Policy Manual, section 7.2), certains paquets que vous avez vraiment besoin peuvent être omis. Par conséquent, nous vous suggérons d'examiner la différence que désactiver recommends rend à votre liste de paquets (voir le fichier binary.packages généré par lb build) et re-incluez dans votre liste tous les paquets manquants que vous souhaitez toujours installés. Alternativement, si vous trouvez que vous voulez seulement un petit nombre de paquets recommandés exclus, laissez recommends activé et définissez une priorité APT pin négative sur les paquets sélectionnés pour éviter les installér, comme expliqué dans APT pinning.
S'il n'y a pas une option lb config pour modifier le comportement d'APT dans la façon dont vous avez besoin, utiliser --apt-options ou --aptitude-options pour passer des options à votre outil APT configuré. Voir les pages de manuel apt et aptitude pour plus de détails
Pour le contexte, s'il vous plaît lire d'abord la page de manuel apt_preferences(5). APT pinning peut être configuré soit au temps de construction, ou encore pendant l'exécution. Pour le premier, créez config/chroot_apt/preferences. Pour ce dernier, créez config/includes.chroot/etc/apt/preferences.
Imaginons que vous voulez construire un système live wheezy mais il faut installer tous les paquets live qui finissent dans l'image binaire de sid au moment de la construction. Vous devez ajouter sid à votre APT sources et le fixer de sorte que seulement les paquets que vous voulez sont installés au temps de construction et tous les autres sont de la distribution du système objectif, wheezy. Ce qui suit devrait accomplir ça:
$ echo "deb http://mirror/debian sid main" > config/archives/sid.list.chroot
$ cat >> config/chroot_apt/preferences << END
Package: live-boot live-boot-initramfs-tools live-config live-config-sysvinit
Pin: release n=sid
Pin-Priority: 600
Package: *
Pin: release n=sid
Pin-Priority: 1
END
Remarque: Caractères génériques peuvent être utilisés dans les noms des paquets (par exemple Package: live-*) avec la version 0.8.14 ou supérieure d'Apt. Cela signifie qu'il fonctionne avec wheezy en utilisant:
$ lb config --distribution wheezy
Une priorité pin négative évitera installér un paquet, comme dans le cas où vous ne voulez pas un paquet qui est recommandé par un autre paquet. Supposons que vous construisez une image LXDE en utilisant l'option --package-lists lxde mais ne veulez pas que l'utilisateur soit invité à stocker les mots de passe wifi dans le trousseau de clés. Cette liste comprend gdm, que dépend de gksu, que à son tour recommande gnome-keyring. Donc, vous voulez omettre le paquet recommandé gnome-keyring. Cela peut être fait en ajoutant la strophe suivante à config/chroot_apt/preferences:
Package: gnome-keyring
Pin: version *
Pin-Priority: -1
Ce chapitre aborde affiner la personnalisation des contenus du système live delà du simple choix des paquets à inclure. Les includes vous permettent d'ajouter ou de remplacer des fichiers arbitraires dans votre image Debian 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.
Bien qu'idéalement un système Debian Live comprendrait des fichiers entièrement fournis par les paquets Debian non modifiés, on convient parfois 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 live de Debian. live-build prévoit trois mécanismes pour leur utilisation:
S'il vous plaît voir Termes pour plus d'informations sur la distinction entre les images "Live" et "binary".
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épertoir de l'utilisateur (/etc/skel) utilisé par le système live pour créer le répertoire home de l'utilisateur Live. Une autre est de fournir des fichiers de configuration qui peuvent être simplement ajoutés ou remplacés à l'image sans traitement, voir Live/chroot local hooks si le traitement est nécessaire.
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:
$ mkdir -p config/includes.chroot/var/www
$ cp /path/to/my/index.html config/includes.chroot/var/www
Votre configuration aura alors le schéma suivant:
-- config
[...]
|-- includes.chroot
| `-- var
| `-- www
| `-- index.html
[...]
`-- templates
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.
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:
$ cp ~/video_demo.* config/includes.binary/
Ces fichiers apparaissent maintenant dans le répertoire racine du support live.
live-build a certains fichiers standard (comme la documentation) qui seront inclus dans la configuration par défaut sur tous les supports live. Ceci peut être désactivé avec:
$ lb config --includes none
Sinon, le matériel sera installé par live-build dans /includes/ par défaut sur le système de fichiers du support, ou bien vous pouvez spécifier un autre chemin d'accès avec --includes.
Les hooks permettent à les commandes être exécutées dans les étapes de la construction chroot et binary afin de personnaliser l'image.
Pour exécuter des commandes à l'étape chroot, créer un script hook avec le suffixe .chroot contenant les commandes dans le répertoire config/hooks/. Le hook s'exécutera dans le chroot après le reste de votre configuration chroot a été appliquée, donc n'oubliez pas de vous assurer que votre configuration inclut tous les paquets et les fichiers que votre hook a besoin pour fonctionner. Voir les exemples de scripts chroot hook pour diverses tâches courantes de personnalisation chroot fournis dans /usr/share/live/build/examples/hooks que vous pouvez copier ou symlink pour les utiliser dans votre propre configuration.
Pour exécuter des commandes au moment du démarrage, vous pouvez fournir live-config hooks comme expliqué dans la section "Personnalisation" de sa page de manuel. Examiner les hooks de live-config fournis dans /lib/live/config/, en notant les numéros de séquence. Puis fournir 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/, ou comme un paquet personnalisé tel que discuté dans Installation des paquets modifiés ou de tiers.
Pour exécuter des commandes à l'étape binaire, créer un script hook avec le suffixe .binary contenant les commandes dans le répertoire config/hooks/. Le hook sera exécuté après toutes les autres commandes binaires soient exécutées, 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! Voir les exemples de binary hook scripts pour diverses tâches courantes de personnalisation binaires fournis dans /usr/share/live/build/examples/hooks que vous pouvez copier ou symlink pour les utiliser dans votre propre configuration.
Les fichiers dans le répertoire config/preseed/ avec le suffixe .preseed suivi 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.
Pour plus d'informations sur debconf, s'il vous plaît voir debconf(7) dans le paquet debconf.
Toute la configuration qui est faite pendant l'exécution est faite par live-config. Voici quelques options les plus courantes de live-config d'intérêt pour les utilisateurs. Une liste complète de toutes les possibilités peut être trouvée dans la page de manuel de live-config.
Une considération importante est que l'utilisateur live est créé par live-boot au démarrage, non pas par live-config au moment de la construction. Ça influence non seulement là où les documents relatifs à l'utilisateur live sont introduits dans votre construction, tel que discuté dans Live/chroot local includes, mais aussi tous les groupes et les autorisations associées à l'utilisateur live.
Vous pouvez spécifier d'autres groupes pour l'utilisateur live en préconfigurant la valeur debconf passwd/user-default-groups. Par exemple, pour ajouter l'utilisateur live au groupe fuse pendant l'étape chroot, ajoutez la ligne suivante à un fichier dans le répertoire config/chroot_local-preseed:
$ lb config
$ echo user-setup passwd/user-default-groups string audio cdrom \
dip floppy video plugdev netdev powerdev scanner bluetooth fuse \
>> config/preseed/my.preseed.chroot
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 pour quelque raison, vous pouvez facilement faire ça comme suit:
Pour modifier le nom de l'utilisateur par défaut, vous pouvez simplement le spécifier dans votre config:
$ lb config --bootappend-live "username=live-user"
Une façon possible de changer le mot de passe par défaut est au moyen d'un hook comme décrit dans Hooks au moment du 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 200-passwd) et l'ajouter à config/includes.chroot/lib/live/config/
Au démarrage du système live, la langue est impliquée dans trois étapes:
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
$ lb config --bootappend-live "locales=de_CH.UTF-8"
Ce paramètre peut également être utilisé à la ligne de commande du noyau. Vous pouvez spécifier des paramètres régionaux par language_country.encoding.
Tant la console et la configuration du clavier X dépendent du paramètre keyboard-layouts de l'option --bootappend-live. Les options valides pour les dispositions des claviers X peuvent être trouvés dans /usr/share/X11/xkb/rules/base.xml (plutôt limitées à des codes des pays à deux lettres). Pour trouver la valeur (les deux caractères), correspondante à une langue essayez de rechercher le nom anglais de la nation où la langue est parlée, par exemple:
$ grep -i sweden -C3 /usr/share/X11/xkb/rules/base.xml | grep name
<name>se</name>
Pour obtenir les fichiers des paramètres régionaux de l'allemand et la disposition du clavier suisse allemand dans X utiliser:
$ lb config --bootappend-live "locales=de_CH.UTF-8 keyboard-layouts=ch"
Une liste des valeurs valides des claviers pour la console peut être figurée avec la commande suivante:
$ for i in $(find /usr/share/keymaps/ -iname "*kmap.gz"); \
do basename $i | head -c -9; echo; done | sort | less
Alternativement, vous pouvez utiliser le paquet console-setup, un outil pour vous aider à configurer la disposition de la console en utilisant définitions X (XKB), vous pouvez alors définir votre clavier plus précisément avec variables keyboard-layouts, keyboard-variant, keyboard-options et keyboard-model; live-boot pourra également utiliser ces paramètres pour la configuration de X. Par exemple, pour mettre en place un système français avec une disposition Français Dvorak (appelée Bepo) sur un clavier TypeMatrix, à la fois dans la console et X11, utilisez:
$ lb config --bootappend-live \
"locales=fr_FR.UTF-8 keyboard-layouts=fr keyboard-variant=bepo keyboard-model=tm2030usb"
Un paradigme d'un Live CD est ê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.
Un système Debian Live est une généralisation de ce paradigme et soutient ainsi autres supports, en plus de CDs, mais encore, 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 perdus à l'arrêt.
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 pourrait fonctionner il pourrait être utile de savoir que même si le système est démarré et exécuté à partir d'un support en lecture seule, la modification des fichiers et répertoires sont écrits sur des supports inscriptibles, typiquement un disque ram (tmpfs) et aux disques RAM les données ne survivent pas à un redémarrage.
Les données stockées sur ce disque virtuel doivent être enregistrées sur un support inscriptible persistant comme supports de stockage locaux, 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 Debian Live de différentes manières, et tous, moins le dernier, nécessitent un paramètre d'amorçage spéciale à préciser au moment du démarrage: persistence.
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. Un volume persistant est un des éléments suivants:
Il est possible de limiter les types de volumes persistants à utiliser en spécifiant certains paramètres de démarrage décrits dans la page de manuel live-boot(7). Les "étiquettes d'identification" mentionnées ci-dessus peuvent être un des éléments suivants:
Par «persistance pleine» on entend que au lieu d'utiliser un tmpfs pour le stockage des modifications dans le support en lecture seule (avec le système copy-on-write, COW) une partition accessible en écriture est utilisée. Pour ce type de persistance le nom du volume doit être full-ov. Cela pourrait, par exemple, être une partition ext4 sur un disque dur ou sur une clé usb créée avec, par exemple:
# mkfs.ext4 -L full-ov /dev/sdb1
Si vous avez déjà une partition sur votre dispositif, vous pouvez simplement modifier l'étiquette avec l'un des suivants:
$ tune2fs -L full-ov /dev/sdb1 # for ext2,3,4 filesystems
Voici un exemple de comment créer un fichier image ext4 utilisé pour la persistance pleine:
$ dd if=/dev/null of=full-ov bs=1G seek=1 # for a 1GB sized image file
$ /sbin/mkfs.ext4 -F full-ov
Ensuite, copiez le fichier full-ov sur une partition accessible en écriture et redémarrer.
Un volume avec l'étiquette custom-ov peut être configuré pour créer des répertoires persistants arbitraires. Le fichier live-persistence.conf, situé sur le système de fichiers racine du volume, contrôle quels répertoires il fait persistants, et de quelle manière.
Comment on configure monter des couches personnalisées est décrit en détail dans la page de manuel live-persistence.conf(5), mais un simple exemple devrait être suffisant pour la plupart des utilisations. Imaginons que nous voulons faire notre répertoire personnel et APT cache persistants dans un système de fichiers ext4 sur la partition /dev/sdb1:
$ mkfs.ext4 -L custom-ov /dev/sdb1
$ mount -t ext4 /dev/sdb1 /mnt
$ echo "/home" >> /mnt/live-persistence.conf
$ echo "/var/cache/apt" >> /mnt/live-persistence.conf
Alors nous redémarrons. Lors du premier démarrage les contenus du /home et /var/cache/apt seront copiés dans le volume persistant, et à partir de ce moment tous les changements dans ces répertoires seront stockés dans le volume persistant. S'il vous plaît souligner que les chemins d'accès aux répertoriés dans le fichier live-persistence.conf ne peuvent pas contenir d'espaces blancs ou les éléments spéciaux . et ... En outre, ni /live (ou un de ses sous-répertoires), ni / peuvent être rendus persistants en utilisant custom mounts (pour ce dernier, utilisez la persistance full-ov décrite ci-dessus).
Plusieurs volumes de couches personnalisées différents (avec leurs propres fichiers live-persistence.conf) peuvent être utilisées au même temps, mais si plusieurs volumes font 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 que le secondaire de sorte que aucun 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 live-persistence.conf. Voir la page de manuel live-persistence.conf(5) pour savoir comment gérer ce cas, si vous avez vraiment besoin (remarque: vous n'avez généralement pas).
Les instantanés sont des collections de fichiers et de répertoires qui ne sont pas montés lors de l'exécution, mais qui sont copiés à partir d'un périphérique persistant à le système (tmpfs) au démarrage et qui sont resynchronisés au redémarrage/arrêt du système. Le volume doit être étiqueté live-sn. Il est par défaut une simple archive cpio appelée live-sn.cpio.gz. Une coupure de courant pendant l'exécution pourrait conduire à la perte de données, donc un outil appelé live-snapshot --refresh pourrait être appelé pour synchroniser des changements importants. Ce type de persistance, car elle n'écrit pas continuellement dans les supports persistants, est la plus respectuese avec les dispositifs flash et la plus rapide de tous les systèmes de persistance, mais elle occupe autant RAM que la taille de l'instantané non compressée.
Une version d'instantané de /home existe aussi, et son étiquette est home-sn.*; elle fonctionne le même que l'instantané principal, mais c'est seulement appliqué à /home.
Les instantanés ne peuvent pas actuellement gérer la suppression de fichiers.
Si un utilisateur a besoin de stockages persistants multiples du même type pour différents endroits ou l'essai, tel que full-ov-nonwork et full-ov-work, le paramètre de démarrage persistence-subtext utilisé en conjonction avec le paramètre de démarrage persistence permettra multiples, mais uniques, supports persistants. Un exemple serait le cas si un utilisateur voudrait utiliser une partition persistante étiquetée live-sn-subText il utiliserait les paramètres de démarrage: persistence persistence-subtext=subText.
Les modifications de l'exécution du tmpfs pourraient être recueillies à l'aide de live-snapshot dans une squashfs et ajoutées au CD en remasterisant l'ISO dans le cas des CD-R ou en ajoutant une session à un cd/dvd(rw) multisession; live-boot monte tous les systèmes de fichiers /live dans l'ordre ou avec le paramètre de démarrage du module.
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 de différentes façons qui vont de fournir un thème complet à changer le délai de démarrage ou tout simplement ajouter une image splash personnalisée. Certains des exemples de personnalisation suivants utilisent méthodes différentes, comme includes ou hooks.
Si vous souhaitez utiliser un thème complet, vous pouvez spécifier l'option --syslinux-theme (voir man lb_config). live-build téléchargera le thème du miroir et l'installera.
Imaginez que vous voulez construire un client progress, mais vous voulez inclure le thème du serveur parce que vous voulez avoir le menu d'aide. Ensuite, vous devez lancer lb config comme suit:
$ lb config --mode progress --syslinux-theme progress-server
Vous pouvez également créer votre propre thème ou modifier un déjà existant et si vous n'avez pas un miroir, vous pouvez ajouter le paquet à config/packages.chroot. Dans ce cas, il n'est pas nécessaire de spécifier une autre option.
Il y a aussi la possibilité de faire des petits changements. Par exemple, les dérivés de syslinux sont configurés par défaut avec un timeout de 0 (zéro) qui signifie qu'ils se mettront en pause indéfiniment à leur écran de démarrage jusqu'à ce que vous pressez une touche.
Pour modifier le délai de démarrage d'une image iso-hybrid, vous pouvez éditer un fichier isolinux.cfg précisant le timeout dans les unités de secondes et l'ajouter à config/includes.binary/isolinux/
Un isolinux.cfg modifié pour démarrer après cinq secondes ressemblerait à ceci:
include menu.cfg
default vesamenu.c32
prompt 0
timeout 50
Une autre façon d'atteindre le même objectif pourrait être écrire un hook et l'ajouter à config/hooks/ N'oubliez pas d'ajouter le suffixe .binary pour l'exécuter dans l'étape binaire. Un exemple proposé:
#!/bin/sh
sed -i 's|timeout 0|timeout 50|' binary/isolinux/isolinux.cfg
Également, si vous souhaitez utiliser une splash.png personnalisée, vous pouvez ajouter une image de 640x480 pixels à config/includes.binary/isolinux/
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.
Les images du système Debian Live peuvent être intégrées avec l'installateur Debian. Il y a un certain nombre de types d'installation différents, variant en ce qui est inclus et comment fonctionne l'installateur.
S'il vous plaît 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, pas autre chose. On le voit souvent abrégé en «d-i».
Les trois principaux types de programme d'installation sont:
Installateur Debian «Régulière»: C'est une image de Debian Live normale avec un noyau et initrd séparés qui (lorsqu'ils sont sélectionnés à partir du chargeur d'amorçage approprié) se lancen dans une instance d'installateur Debian standard, exactement comme si vous aviez téléchargé une image CD de Debian et la auriez démarrée. Les images contenant un système live et un installateur indépendant sont souvent appelées «images combinées».
Sur ces images, Debian est installé par l'extraction et l'installation de paquets .deb à l'aide de debootstrap ou cdebootstrap, à partir des supports locaux ou sur le réseau, résultant en un système Debian standard en cours d'installation sur le disque dur.
Tout ce processus peut être préconfiguré et personnalisé dans un certain nombre de façons, voir 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 le mettre à l'image et l'activer pour vous.
Installateur Debian "Live" : C'est une image de Debian Live avec un noyau et initrd séparés qui (lorsqu'ils sont sélectionnés à partir du chargeur d'amorçage approprié) se lancen dans une instance de l'installateur Debian.
L'installation continue de manière identique à l'installation «Régulière» 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.
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
Remarque: Pour soutenir 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.
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. C'est facile à utiliser dans certaines situations. Afin de faire usage de cela, le paquet debian-installer-launcher doit être inclus.
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. Aussi, s'il vous plaît 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 spécifiée. Par exemple:
$ lb config --architectures i386 --linux-flavours 486 \
--debian-installer live
$ echo debian-installer-launcher >> config/package-lists/my.list.chroot
Comme décrit dans le Debian Installer Manual, Appendix B at ‹http://www.debian.org/releases/stable/i386/apb.html›, «La préconfiguration est une façon de donner des réponses aux questions posées pendant le processus d'installation, sans avoir à entrer manuellement les réponses alors que l'installation est en marche. Cela permet d'automatiser entièrement la plupart des types d'installation et elle offre certaines fonctionnalités que ne sont pas disponibles pendant les installations normales ». Ce type de personnalisation se fait mieux avec live-build en plaçant la configuration dans un fichier preseed.cfg inclus dans config/binary_debian-installer/. Par exemple, pour préconfigurer les paramètres régionaux pour en_US:
$ echo "d-i debian-installer/locale string en_US" \
>> config/binary_debian-installer/preseed.cfg
Pour des fins expérimentales ou de débogage, vous pouvez inclure paquets udeb d-i construits localement. Et les placer dans config/packages.binary/ pour les inclure dans l'image. Plusieurs fichiers supplémentaires ou de remplacement et plusieurs répertoires peuvent être inclus dans l'initrd de l'installateur ainsi, d'une manière similaire à Live/chroot local includes en plaçant le matériau dans config/includes.binary_debian-installer/.
Debian Live est loin d'être parfait, mais nous voulons le rendre aussi proche que possible de parfait - 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 déposer les rapports de bogues.
Pour les impatients:
Parce que les distributions Debian testing et Debian unstable sont une cible mouvante, quand vous les spécifiez comme les distributions du système objectif, une construction avec succès n'est pas toujours possible.
Si cela provoque trop de difficulté pour vous, ne pas construire un système basé sur testing or unstable, mais plutôt utiliser stable. live-build fait toujours défaut à la version stable.
Les problèmes connus sont énumérés sous la section "status" sur notre page à ‹http://live.debian.net/›.
Il est hors cadre de ce manuel vous former correctement à identifier et corriger les problèmes dans les paquets des distributions de développement, cependant, il y a deux choses que vous pouvez toujours essayer: Si une construction échoue lorsque la distribution objectif est testing, essayez unstable. Si unstable ne fonctionne pas non plus, revenir à testing et fixer la nouvelle version du paquet qui échoue de unstable (voir APT pinning pour plus de détails).
Afin de s'assurer que un bogue en particulier n'est pas causé par un système construit malpropre, s'il vous plaît toujours reconstruire l'ensemble du système live à partir de zéro pour voir si le bogue est reproductible.
L'utilisation de paquets obsolètes peut causer des problèmes importants en essayant de reproduire (et finalement régler) votre problème. Assurez-vous que votre système de construction est mis à jour et tous les paquets inclus dans votre image sont mis à jour aussi.
S'il vous plaît fournir assez d'informations à votre rapport. Incluez au moins la version exacte de live-build où le bogue est rencontré et les mesures pour le reproduire. S'il vous plaît utilisez votre bon sens et incluez d'autres renseignements pertinents, si vous pensez que cela pourrait aider à résoudre le problème.
Pour tirer le meilleur parti de votre rapport de bogue, nous avons besoin d'au moins les informations suivantes:
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).
# lb build 2>&1 | tee build.log
Au démarrage, live-boot stocke un journal dans /var/log/live.log (ou /var/log/live-boot.log).
Par ailleurs, pour écarter d'autres erreurs, c'est toujours une bonne idée 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 pouvons 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).
N'oubliez pas d'envoyer tous les journaux qui ont été produits avec le paramètre régionaux anglais, par exemple exécuter vos commandes live-build précédées par LC_ALL=C ou LC_ALL=en_US.
Si possible, isoler 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 votre cycle de développement bien, en utilisant 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é. Si il est difficile de trier vos modifications qui cassent, il est possible que vous y compris trop dans chaque ensemble de modifications et vous devriez developper en petits incréments.
Où est-ce que le bogue apparaît?
live-build amorce d'abord un système Debian de base avec debootstrap ou cdebootstrap. Selon l'outil d'amorçage utilisé et de la distribution Debian il peut échouer. Si un bogue apparaît ici, vérifiez si l'erreur est liée à un paquet Debian spécifique (plus probable), ou si elle est liée à l'outil d'amorçage lui-même.
Dans les deux cas, ce n'est pas un bogue dans Debian Live, mais plutôt dans Debian lui-même que nous ne pouvons résoudre directement. S'il vous plaît rapportez un bogue sur l'outil d'amorçage ou du paquet défaillant.
live-build installe des paquets supplémentaires de l'archive Debian et en fonction de la distribution Debian utilisée et l'état quotidienne 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.
Si c'est le cas, ce n'est pas un bogue dans Debian Live, mais plutôt dans Debian - s'il vous plaît faire 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.
Aussi, si vous utilisez un miroir local et/ou un proxy et vous rencontrez un problème, s'il vous plaît toujours le reproduire d'abord bootstrapping sur un miroir officiel.
Si votre image ne démarre pas, s'il vous plaît le signaler à la liste de diffusion avec les informations demandées dans Recueillir l'information. Ne pas oublier de mentionner, comment/quand l'image a échoué, dans Qemu, VirtualBox, VMWare ou matériel réel. Si vous utilisez une technologie de virtualisation d'aucune sorte, s'il vous plaît toujours tester sur matériel réel avant de rapporter un bogue. Fournir une copie d'écran de l'échec est également très utile.
Si un paquet a été installé avec succès, mais échoue tout en exécutant le système Live, c'est probablement un bogue dans Debian Live. Cependant,
Avant de présenter le bogue, s'il vous plaît recherchez sur le web le message d'erreur ou un symptôme particulier que vous obtenez. Comme il est hautement improbable que vous êtes la seule personne qui expérience un problème particulier, il y a toujours une chance qu'il a été discuté ailleurs, et une solution possible, un correctif, ou une solution de contournement a été proposé.
Vous devez prêter une attention particulière à la liste de diffusion de Debian Live, ainsi que à la page d'accueil, car elles sont susceptibles de contenir des informations à jour. Si ces informations existent, toujours inclure les références au sein de vos rapport de bogues.
En outre, vous devriez vérifier les listes de bogues en cours de live-build, live-boot, et live-config pour voir si quelque chose de semblable n'a été déjà signalée.
Le projet Debian Live conserve la trace de tous les bogues dans le système Debian Bug Tracking System (BTS). Pour plus d'informations sur la façon d'utiliser le système, s'il vous plaît voir ‹http://bugs.debian.org/›. Vous pouvez également soumettre les bogues en utilisant la commande reportbug du paquet du même nom.
En général, vous devez signaler les erreurs de construction contre le paquet live-build, les erreurs en temps de démarrage contre live-boot, et les erreurs d'exécution contre live-config. Si vous n'êtes pas sûr de quel paquet est approprié ou avez besoin d'aide avant de soumettre un rapport de bogue, s'il vous plaît envoyez un message à la liste de diffusion et nous vous aiderons à décider.
S'il vous plaît notez 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 qu'ils peuvent être également reproduits sur un système Debian en utilisant les paquets Debian officiels.
Ce chapitre documente le style du code utilisé en live-boot et autres.
Mal:
if foo; then
bar
fi
Bien:
if foo
then
bar
fi
Mal:
Foo () {
bar
}
Bien:
Foo ()
{
bar
}
Mal:
FOO=bar
Bien:
FOO="bar"
Mal:
if [ -f "${FOO}"/foo/"${BAR}"/bar ]
then
foobar
fi
Bien:
if [ -f "${FOO}/foo/${BAR}/bar" ]
then
foobar
fi
Ce chapitre documente les procédures au sein du projet Debian Live pour différentes tâches qui ont besoin de coopération avec d'autres équipes dans Debian.
Avant d'envoyer une version d'un udeb au d-i svn, on doit faire:
$ ../../scripts/l10n/output-l10n-changes . -d
La libération d'une nouvelle version stable majeur de Debian inclut beaucoup de équipes différentes travaillant ensemble. À un certain point, l'équipe Live arrive et construit images des systèmes live. Les conditions pour ce faire sont les suivantes:
N'oubliez pas de régler à la fois les miroirs pour chroot et binary lors de la construction de la dernière série d'images pour une version de Debian après qu'elle a été déplacé de ftp.debian.org à archive.debian.org. De cette façon, les vieilles images live précompilées sont encore utiles, sans modifications des utilisateurs.
Un courriel pour l'annonce d'une évolutioun mineure peut être généré en utilisant le modèle ci-dessous et la commande suivante:
$ sed \
-e 's|%major%|5.0|g' \
-e 's|%minor%|5.0.2|g' \
-e 's|%codename%|lenny|g' \
-e 's|%release_mail%|2009/msg00007.html|g'
S'il vous plaît vérifiez le courriel avant l'envoi et le passer à d'autres pour la relecture.
Debian Live images for Debian GNU/Linux %major% updated
The Debian Live project is pleased to announce the availability of
updated Live images for its stable distribution Debian GNU/Linux %major%
(codename "%codename%").
The images are available for download at:
<http://cdimage.debian.org/cdimage/release/current-live/>
This update incorporates the changes made in the %minor% point release,
which adds corrections for security problems to the stable release
along with a few adjustments for serious problems. A full list of the
changes may be viewed at:
<http://lists.debian.org/debian-announce/%release_mail%>
It also includes the following Live-specific changes:
* [INSERT LIVE-SPECIFIC CHANGE HERE]
* [INSERT LIVE-SPECIFIC CHANGE HERE]
* [LARGER ISSUES MAY DESERVE THEIR OWN SECTION]
URLs
----
Download location of updated images:
<http://cdimage.debian.org/cdimage/release/current-live/>
Debian Live project homepage:
<http://live.debian.net/>
The current stable distribution:
<http://ftp.debian.org/debian/dists/stable>
stable distribution information (release notes, errata etc.):
<http://www.debian.org/releases/stable/>
Security announcements and information:
<http://www.debian.org/security/>
About Debian
-------------
The Debian Project is an association of Free Software developers who
volunteer their time and effort in order to produce the completely free
operating system Debian GNU/Linux.
About Debian Live
-----------------
Debian Live is an official sub-project of Debian which produces Debian
systems that do not require a classical installer. Images are available
for CD/DVD discs, USB sticks and PXE netbooting as well as a bare
filesystem images for booting directly from the internet.
Contact Information
-------------------
For further information, please visit the Debian Live web pages at
<http://live.debian.net/> or alternatively send mail to
<debian-live@lists.debian.org>.
Ce chapitre s'occupe d'exemples de constructions pour des cas d'utilisation spécifiques avec Debian Live. Si vous êtes nouveau avec la construction de vos propres images Debian Live, nous vous recommandons d'abord regarder les trois tutoriels en séquence, parce que chacun enseigne nouvelles techniques qui vous aideront à utiliser et à comprendre les exemples restants.
Pour utiliser ces exemples vous avez besoin d'un système pour les construire, lequel répond aux exigences énumérées dans Exigences et qui a live-build installé comme décrit à Installation de live-build.
Notez que, pour des raisons de concision, dans ces exemples, nous ne spécifions pas un 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 spécifier les options lorsque vous utilisez lb config, tel que décrit dans Miroirs de distribution utilisés au temps de 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 par défaut à partir de ces valeurs. Par exemple:
LB_MIRROR_BOOTSTRAP="http://mirror/debian"
LB_MIRROR_CHROOT_SECURITY="http://mirror/debian-security"
LB_MIRROR_CHROOT_BACKPORTS="http://mirror/debian-updates"
Cas d'utilisation: Créer une image simple d'abord, apprenant les bases de live-build.
Dans ce tutoriel, nous construirons une image Debian Live ISO hybride par défaut contenant uniquement paquets de base (pas de Xorg) et quelques paquets Debian de soutien live, comme un premier exercice en utilisant live-build.
Vous ne pouvez pas obtenir rien plus simple que cela:
$ mkdir tutorial1 ; cd tutorial1 ; lb config
Examinez le contenu du répertoire config/ si vous le souhaitez. Vous verrez stockés ici une arborescence de configuration, pour être personnalisee ou, dans ce cas, utiliser immédiatement pour construire une image par défaut.
Maintenant, en tant que superutilisateur, construire l'image en enregistrant un journal avec tee.
# lb build 2>&1 | tee binary.log
En supposant que tout se passe bien, après un certain temps, le répertoire courant contiendra binary.hybrid.iso. Cette image ISO hybride peut être démarrée directement dans une machine virtuelle comme décrit dans Test d'une image ISO avec QEMU et Test d'une image ISO avec virtualbox-ose, ou bien copiée sur un support optique ou un périphérique USB comme décrit dans Graver une image ISO sur un support physique et Copie d'un image ISO hybride sur une clé USB, respectivement.
Cas d'utilisation: Créer une image d'un utilitaire de navigateur Web, en apprenant à appliquer des personnalisations.
Dans ce tutoriel, nous allons créer une image utilisable comme un utilitaire de navigateur Web, en servant d'introduction à la personnalisation d'images Debian Live.
$ mkdir tutorial2
$ cd tutorial2
$ lb config -p lxde
$ echo iceweasel >> config/package-lists/my.list.chroot
Notre choix de LXDE pour cet exemple reflète notre volonté de fournir un environnement de bureau minime, puisque le point 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 soutien supplémentaires pour visualiser différents types de contenu web, mais nous laissons cela comme un exercice pour le lecteur.
Construire l'image, encore une fois en tant que superutilisateur, garder un journal comme dans Tutoriel 1:
# lb build 2>&1 | tee binary.log
Encore une fois, vérifiez que l'image est OK et faire un test, comme dans Tutoriel 1:
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 vos besoins et vos préférences changent.
Puisque nous allons changer notre image personnalisée pendant un certain nombre de révisions, et nous voulons suivre ces changements, d'essayer des choses expérimentalement et éventuellement de les revenir 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.
$ mkdir -p tutorial3/auto
$ cp /usr/share/live/build/examples/auto/* tutorial3/auto/
$ cd tutorial3
Éditer auto/config pour lire comme suit:
#!/bin/sh
lb config noauto \
--architectures i386 \
--linux-flavours 686-pae \
--package-lists lxde \
"${@}"
Maintenant remplir votre liste de paquets locaux:
$ echo "iceweasel xchat" >> config/package-lists/my.list.chroot
Tout d'abord, --architectures i386 assure que sur notre système de construction amd64, nous construisons une version 32 bits qui peut être utilisée sur la plupart des machines. En seconde place, nous utilisons --linux-flavours 686-pae parce que nous ne prévoyons pas utiliser cette image sur des systèmes beaucoup plus anciens. En troisième lieu, nous avons choisi la liste de paquets lxde pour nous donner un bureau minimal. Et enfin, nous avons ajouté deux premiers paquets préférés: iceweasel et xchat.
Maintenant, construire l'image:
# lb build
Notez que contrairement aux deux premiers tutoriels, nous n'avons plus besoin de taper 2>&1 | tee binary.log parce que cela est maintenant inclus dans auto/build.
Une fois que vous avez testé l'image (comme dans Tutoriel 1) et vous êtes satisfait avec son fonctionnement, il est temps pour initialiser notre dépôt git, ajoutant que les scripts d'auto que nous avons juste créé, et ensuite faire le premier commit:
$ git init
$ git add auto
$ git commit -a -m "Initial import."
Dans cette révision, nous allons nettoyer à partir de la première construction, ajouter le paquet vlc à notre configuration, reconstruire, tester et faire le commit.
La commande lb clean va nettoyer tous les fichiers générés par la construction précédente à l'exception du cache, ça évite d'avoir à re-télécharger les paquets. Cela garantit que la lb build suivante ré-exécutera toutes les étapes pour régénérer les fichiers de notre nouvelle configuration.
# lb clean
Maintenant ajouter le paquet vlc à votre liste de paquets locaux dans config/package-lists/my.list.chroot:
$ echo vlc >> config/package-lists/my.list.chroot
Construire à nouveau:
# lb build
Tester, et quand vous soyez satisfaits, commit la prochaine révision:
$ git commit -a -m "Adding vlc media player."
Bien sûr, des changements plus compliqués à la configuration sont possibles, peut-être l'ajout de fichiers dans les sous-répertoires de config/. Quand vous livrez des nouvelles révisions, on doit prendre soin de ne pas modifier à la main ou envoyer au dépôt les fichiers de niveau supérieur dans config contenant variables LB_*, car ce sont aussi des produits de creation et sont toujours nettoyés par lb clean et re-créés avec lb config via leur respectives auto scripts.
Nous sommes arrivés à la fin de notre série de tutoriels. Alors que de nombreux types de personnalisations sont possibles, même juste en utilisant les fonctionnalités explorées dans ces exemples simples, une variété presque infinie d'images différentes peuvent être crées. Les autres exemples de cette section couvrent plusieurs autres cas d'utilisation tirés des expériences recueillies des utilisateurs de Debian Live.
Cas d'utilisation: Créer une image avec live-build pour démarrer directement à un serveur VNC.
Faire un répertoire de construction et créer une arborescence de fichiers construite autour de la liste standard x11, avec gdm3, metacity et xvnc4viewer, désactivant «recommends» pour faire un système minimal:
$ mkdir vnc_kiosk_client
$ cd vnc_kiosk_client
$ lb config -a i386 -k 686-pae -p standard-x11 \
--apt-recommends false
$ echo "gdm3 metacity xvnc4viewer" >> config/package-lists/my.list.chroot
Créez le répertoire /etc/skel avec une .xsession personnalisée pour l'utilisateur par défaut qui va lancer metacity et commencer xvncviewer, en reliant le port 5901 sur un serveur à 192.168.1.2:
$ mkdir -p config/includes.chroot/etc/skel
$ cat > config/includes.chroot/etc/skel/.xsession << END
#!/bin/sh
/usr/bin/metacity &
/usr/bin/xvncviewer 192.168.1.2:1
exit
END
Construire l'image:
# lb build
Amusez-vous bien!
Cas d'utilisation: Créer une image standard avec certains composants éliminés afin de l'adapter sur une clé USB de 128M avec espace laissé pour l'utiliser à votre convenance.
Pour l'optimisation d'une image adaptée à la dimension des certains supports, vous avez besoin de comprendre le compromis que vous faites entre la taille et la fonctionnalité. Dans cet exemple, nous réduisons la taille uniquement que pour faire place au matériel supplémentaire au sein d'une taille de 128M, mais sans faire rien pour détruire l'intégrité des paquets contenus, telle que la purge des données de localisation via le paquet localepurge, ou d'autres optimisations "intrusives". On notera en particulier que vous ne devriez pas utiliser --bootstrap-flavour minimal sauf si vous savez vraiment ce que vous faites et que l'omission des paquets de priorité importante produira probablement un système live cassé.
$ lb config -k 486 -p minimal --apt-indices false \
--memtest none --apt-recommends false --includes none
Maintenant, construire l'image de la manière habituelle:
# lb build 2>&1 | tee binary.log
Sur le système de l'auteur au moment de l'écriture, la configuration ci-dessus produisait une image de 78Mbyte. Cela se compare favorablement avec l'image de 166Mbyte produite par la configuration par défaut dans Tutoriel 1.
Le plus grand espace-économiseur ici, par rapport à la construction d'une image standard sur une architecture i386, est de sélectionner uniquement le saveur du noyau 486 au lieu de la valeur par défaut -k "486 686-pae". Laissant hors «APT's indices» 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. Le choix de la liste minimal laisse de côté les grands paquets de locales et les services associés. Laissant hors les paquets recommandés avec --apt-recommends false économise d'espace supplémentaire, au détriment d'omettre certains paquets que vous pourriez autrement attendre à être là, tel que firmware-linux-free qui peuvent être nécessaires pour soutenir certains supports matériels. Les options restantes économisent petites quantités d'espace supplémentaire. C'est à vous de décider si la fonctionnalité qui est sacrifiée avec chaque optimisation est en vaut la perte de fonctionnalité.
Cas d'utilisation: Créer une image de bureau KDE, localisée pour le portugais brésilien et incluant un installateur.
Nous voulons faire une image iso-hybrid pour l'architecture i386 en utilisant notre bureau préféré, dans ce cas, KDE, contenant tous les paquets qui seraient installés par l'installateur Debian standard pour KDE.
Notre premier problème est la découverte des noms des tâches appropriées. Actuellement, live-build ne peut pas aider à faire ça. Alors que nous pourrions être chanceux et trouver ce par essais et erreurs, il y a un outil, grep-dctrl, qui peut être utilisé pour découvrir les descriptions des tâches dans tasksel-data, de sorte à préparer, assurez-vous que vous avez ces deux choses:
# apt-get install dctrl-tools tasksel-data
Maintenant, nous pouvons rechercher les tâches appropriées, d'abord avec:
$ grep-dctrl -FTest-lang pt_BR /usr/share/tasksel/descs/debian-tasks.desc -sTask
Task: brazilian-portuguese
Par cette commande, nous découvrons que la tâche est appelée, assez clairement, brazilian-portuguese. Maintenant, pour trouver les tâches liées:
$ grep-dctrl -FEnhances brazilian-portuguese /usr/share/tasksel/descs/debian-tasks.desc -sTask
Task: brazilian-portuguese-desktop
Task: brazilian-portuguese-kde-desktop
Au démarrage nous allons générer les paramètres régionaux pt_BR.UTF-8 et sélectionner la configuration du clavier pt-latin1. Nous aurons aussi besoin de préconfigurer notre choix de bureau, "kde" de sorte que tasksel installera la tâche de bureau correcte, car elle diffère de la valeur par défaut (Voir Tâches de bureau et de la langue). Maintenant, nous allons assembler les pièces:
$ mkdir live-pt_BR-kde
$ cd live-pt_BR-kde
$ lb config \
-a i386 \
-k 486 \
--bootappend-live "locales=pt_BR.UTF-8 keyboard-layouts=pt-latin1" \
--debian-installer live
$ echo kde-desktop brazilian-portuguese brazilian-portuguese-desktop \
brazilian-portuguese-kde-desktop >> config/task-lists/my.list.chroot
$ echo debian-installer-launcher >> config/package-lists/my.list.chroot
$ echo tasksel tasksel/desktop multiselect kde >> config/preseed/my.preseed.chroot
Notez que nous avons inclus le paquet debian-installer-launcher pour lancer l'installateur à partir du bureau live, nous avons également précisé le noyau 486, parce qu'il est actuellement nécessaire faire que l'installateur et le noyau du systéme live coïncident pour que le lanceur fonctionne correctement.
This section deals with some general considerations to be taken into account when writing technical documentation for live-manual. They are divided into linguistic features and recommended procedures.
Note: Authors should first read Contributing to this document
Keep in mind that a high percentage of your readers are not native speakers. So as a general rule try to use short, meaningful sentences, followed by a full stop.
This does not mean that you have to use a simplistic, naive style. It is a suggestion to try to avoid, as much as possible, complex subordinate sentences that make the text difficult to understand for non-native speakers.
The most widely spread varieties of English are British and American so it is very likely that most authors will use either one or the other. In a collaborative environment, the ideal variety would be "International English" but it is very difficult, not to say impossible, to decide on which variety among all the existing ones, is the best to use.
We expect that different varieties may mix without creating misunderstandings but in general terms you should try to be coherent and before deciding on using British, American or any other English flavour at your discretion, please take a look at how other people write and try to imitate them.
Do not be biased. Avoid including references to ideologies completely unrelated to live-manual. Technical writing should be as neutral as possible. It is in the very nature of scientific writing.
Try to avoid sexist language as much as possible. If you need to make references to the third person singular preferably use "they" rather than "he" or "she" or awkward inventions such as "s/he", "s(he)" and the like.
Go straight to the point and do not wander around aimlessly. Give as much information as necessary but do not give more information than necessary, this is to say, do not explain unnecessary details. Your readers are intelligent. Presume some previous knowledge on their part.
Keep in mind that whatever you write will have to be translated into several other languages. This implies that a number of people will have to do an extra work if you add useless or redundant information.
As suggested before, it is almost impossible to standardize a collaborative document into a perfectly unified whole. However, every effort on your side to write in a coherent way with the rest of the authors will be appreciated.
Use as many text-forming devices as necessary to make your text cohesive and unambiguous. (Text-forming devices are linguistic markers such as connectors).
It is preferable to describe the point in one or several paragraphs than merely using a number of sentences in a typical "changelog" style. Describe it! Your readers will appreciate it.
Look up the meaning of words in a dictionary or encyclopedia if you do not know how to express certain concepts in English. But keep in mind that a dictionary can either be your best friend or can turn into your worst enemy if you do not know how to use it correctly.
English has the largest vocabulary that exists (With over one million words). Many of these words are borrowings from other languages. When looking up the meaning of words in a bilingual dictionary the tendency of a non-native speaker is to choose the one that sounds more similar in their mother tongue. This often turns into an excessively formal discourse which does not sound quite natural in English.
As a general rule, if a concept can be expressed using different synonyms, it is a good advice to choose the first word proposed by the dictionary. If in doubt, choosing words of Germanic origin (Usually monosyllabic words) is often the right thing to do. Be warned that these two techniques might produce a rather informal discourse but at least your choice of words will be of wide use and generally accepted.
Using a dictionary of collocations is recommended. They are extremely helpful when it comes to know which words usually occur together.
Again it is a good practice to learn from the work of others. Using a search engine to check how other authors use certain expressions may help a lot.
Watch out for false friends. No matter how proficient you are in a foreign language you cannot help falling from time to time in the trap of the so called "false friends", words that look similar in two languages but whose meanings or uses might be completely different.
Try to avoid idioms as much as possible. "Idioms" are expressions that may convey a completely different meaning from what their individual words seem to mean. Sometimes, idioms are difficult to understand even for native speakers!
Even though you are encouraged to use plain, everyday English, technical writing belongs to the formal register of the language.
Try to avoid slang, unusual abbreviations that are difficult to understand and above all contractions that try to imitate the spoken language. Not to mention typical irc and family friendly expressions.
It is important that authors test their examples before adding them to live-manual to ensure that everything works as described. Testing on a clean chroot or VM can be a good starting point. Besides, it would be ideal if the tests were then carried out on different machines with different hardware to spot possible problems that may arise.
When providing an example try to be as specific as you can. An example is, after all, just an example.
It is often better to use a line that only applies to an specific case than using abstractions that may confuse your readers. In this case you can provide a brief explanation of the effects of the proposed example.
There may be some exceptions when the example suggests using some potentially dangerous commands that, if misused, may cause data loss or other similar undesirable effects. In this case you should provide a thorough explanation of the possible side effects.
Links to external sites should only be used when the information on those sites is crucial when it comes to understanding a special point. Even so, try to use links to external sites as sparsely as possible. Internet links are likely to change from time to time resulting in broken links and leaving your arguments in an incomplete state.
Besides, people who read the manual offline will not have the chance to follow those links.
Try to avoid branding as much as possible. Keep in mind that other downstream projects might make use of the documentation you write. So you are complicating things for them if you add certain specific material.
live-manual is licensed under the GNU GPL. This has a number of implications that apply to the distribution of the material (of any kind, including copyrighted graphics or logos) that is published with it.
- Brainstorm!. You need to organize your ideas first in a logical sequence of events.
- Once you have somehow organized those ideas in your mind write a first draft.
- Revise grammar, syntax and spelling.
- Improve your statements and redo any part if necessary.
Use the conventional numbering system for chapters and subtitles. e.g. 1, 1.1, 1.1.1, 1.1.2 ... 1.2, 1.2.1, 1.2.2 ... 2, 2.1 ... and so on. See markup below.
If you have to enumerate a series of steps or stages in your description, you can also use ordinal numbers: First, second, third ... or First, Then, After that, Finally ... Alternatively you can use bulleted items.
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:
$ sisu --help markup
Here are some markup examples that may prove useful:
- For emphasis/bold text:
*{foo}* or !{foo}!
produces: foo or foo. Use it to emphasize certain key words.
- For italics:
/{foo}/
produces: foo. Use them e.g. for the names of debian packages.
- For monospace:
#{foo}#
produces: foo. Use it e.g. for the names of commands. And also to highlight some key words or things like paths.
- For code blocks:
code{
$ foo
# bar
}code
produces:
$ foo
# bar
Use code{ to open and }code to close the tags. It is important to remember to leave a space at the beginning of each line of code.
This section deals with some general considerations to be taken into account when translating the contents of live-manual.
As a general recommendation, translators should have read and understood the translation rules that apply to their specific languages. Usually, translation groups and mailing lists provide information on how to produce translated work that complies with Debian quality standards.
Note: Translators should also read Contributing to this document. In particular the section Translation
The role of the translator is to convey as faithfully as possible the meaning of words, sentences, paragraphs and texts as written by the original authors into their target language.
So they should refrain from adding personal comments or extra bits of information of their own. If they want to add a comment for other translators working on the same documents, they can leave it in the space reserved for that. That is, the header of the strings in the po files preceded by a number sign #. Most graphical translation programs can automatically handle those types of comments.
It is perfectly acceptable however, to include a word or an expression in brackets in the translated text if, and only if, that makes the meaning of a difficult word or expression clearer to the reader. Inside the brackets the translator should make evident that the addition was theirs using the abbreviation "TN" or "Translator's Note".
Documents written in English make an extensive use of the impersonal form "you". In some other languages that do not share this characteristic, this might give the false impression that the original texts are directly addressing the reader when they are actually not doing so. Translators must be aware of that fact and reflect it in their language as accurately as possible.
The trap of "false friends" explained before especially applies to translators. Double check the meaning of suspicious false friends if in doubt.
Translators working initially with pot files and later on with po files will find many markup features in the strings. They can translate the text anyway, as long as it is translatable, but it is extremely important that they use exactly the same markup as the original English version.
Some translators decide to include the code blocks in the translated files because it is easier for them to identify what has already been translated and what has not by looking at the percentages if they use a graphical translation program.
Include the code blocks if you want to score a 100% complete translation.
On the other hand some translators prefer to leave the code blocks "untranslated" (i.e. not including them). This makes the translation easier to maintain once finished because it does not require translators intervention if the code changes.
Leave the code blocks empty (they will be automatically added then) if you want to make your translation easier to maintain.
The translated texts need to have the exact same newlines as the original texts. Be careful to press the "Enter" key or type \n if they appear in the original files. These newlines often appear, for instance, in the code blocks.
Make no mistake, this does not mean that the translated text needs to have the same length as the English version. That is nearly impossible.
Translators should never translate:
- The code names of releases
- The names of programs
- The commands given as examples
- Metadata (often between colons :metadata:)
- Links
- Paths