Live manual

test @ sisudoc.org

sisu

[ document manifest ]

<< previous toc next >>

Manuel Live Systems

Gestion d'une configuration

6. Gestion d'une configuration

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.

6.1 Gérer les modifications de la configuration

Les configurations live sont rarement parfaites du premier coup. Il peut être bon de passer des options lb config à partir de la ligne de commande pour effectuer une construction unique, mais il est plus courant de réviser ces options et de construire à nouveau jusqu'à ce que vous soyez satisfait. Afin de prendre en charge ces changements, vous aurez besoin des scripts automatiques qui assurent le maintien de votre configuration dans un état cohérent.

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

La commande lb config enregistre les options que vous lui passez avec les fichiers dans config/* avec beaucoup d'autres options aux valeurs par défaut. Si vous exécutez lb config à nouveau, il ne réinitialisera pas l'option qui a été mise par défaut en fonction de vos options initiales. Ainsi, par exemple, si vous exécutez lb config à nouveau avec une nouvelle valeur pour --binary-images, toutes les options qui ont été mises à leur valeur par défaut pour l'ancienne type d'image ne peuvent plus fonctionner avec la nouvelle option. Ces fichiers ne sont pas destinés à être lus ou modifiés. Ils enregistrent des valeurs pour plus d'une centaine d'options, donc personne (y-compris vous) ne pourra voir dans ces options lesquelles vous avez réellement indiquées. Finalement, si vous lancez lb config, puis mettez live-build à niveau et que celui-ci renomme une option, config/* contiendra toujours des variables nommées en fonction de l'ancienne option et qui ne seront plus valides.

Pour toutes ces raisons, les scripts auto/* vous rendront la vie plus facile. Ils sont de simples emballages pour les commandes lb config, lb build et lb clean qui sont conçus pour vous aider à gérer votre configuration. Le script auto/config enregistre votre commande lb config avec toutes les options désirées, le script auto/clean supprime les fichiers contenant les valeurs des variables de configuration et le script auto/build crée un build.log de chaque construction. Et chaque fois que vous lancez la commande lb correspondante, ces fichiers sont exécutés automatiquement. En utilisant ces scripts, votre configuration est plus facile à lire et a une cohérence interne d'une révision à l'autre. En outre, il sera plus facile pour vous d'identifier et corriger les options qui doivent changer lorsque vous mettez à niveau live-build après avoir lu la documentation mise à jour.

6.1.2 Utiliser les scripts auto d'exemple

Pour votre commodité, live-build est fourni avec des scripts shell d'exemple, pour les copier et les modifier. Lancez une nouvelle configuration par défaut, puis copiez les exemples:

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

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

#!/bin/sh
lb config noauto \
     --architectures i386 \
     --linux-flavours 686-pae \
     --binary-images hdd \
     --mirror-bootstrap http://ftp.ch.debian.org/debian/ \
     --mirror-binary http://ftp.ch.debian.org/debian/ \
     "${@}"

Maintenant, chaque fois que vous utilisez lb config, auto/config réinitialisera la configuration basée sur ces options. Lorsque vous souhaitez effectuer des modifications, modifiez les options dans ce fichier au lieu de les passer à lb config. Lorsque vous utilisez lb clean, auto/clean va nettoyer les fichiers ainsi que tous les autres produits de construction. Et enfin, lorsque vous utilisez lb build, un journal de la construction est écrit par auto/build dans build.log.

Remarque: Un paramètre spécial noauto est utilisé ici pour éliminer un autre appel à auto/config, évitant ainsi une récursion infinie. Assurez-vous que vous ne l'avez pas accidentellement supprimé en modifiant le fichier. Aussi, prenez soin de vous assurer quand vous divisez la commande lb config sur plusieurs lignes pour une meilleure lisibilité, comme le montre l'exemple ci-dessus, que vous n'oubliez pas la barre oblique inverse (\) de sorte que chaque ligne continue à la suivante.

6.2 Cloner une configuration publiée via Git

Utilisez l'option lb config --config pour cloner un dépôt Git qui contient une configuration d'un système live. Si vous souhaitez baser votre configuration sur une autre maintenue par le Live Systems Project, allez voir le dépôt sur ‹http://live-systems.org/gitweb› avec le nom live-images sous le titre Packages. Ce dépôt contient les configurations pour les images précompilées

Par exemple, pour construire une image de récupération, utilisez le dépôt live-images comme suit:

$ mkdir live-images && cd live-images
$ lb config --config git://live-systems.org/git/live-images.git
$ cd images/rescue

Modifiez auto/config et toutes les autres choses dont vous avez besoin dans l'arbre config en fonction de vos besoins. Par exemple, les images precompilées non officielles qui contiennent paquets non-free sont faites en ajoutant simplement --archive-areas "main contrib non-free".

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

[url "git://live-systems.org/git/"]
         insteadOf = lso:

Cela vous permet d'utiliser lso: quand vous voulez indiquer l'adresse d'un dépôt live-systems.org. Si vous supprimez le suffixe optionnel .git, commencer une nouvelle image en utilisant cette configuration est aussi simple que:

$ lb config --config lso:live-images

Le clonage de la totalité du dépôt live-images copie les configurations utilisées pour plusieurs images. Si vous voulez construire une image différente lorsque vous avez terminé avec la première, changez de répertoire et, éventuellement, faites les modifications dont vous avez besoin.

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


[ document manifest ]

<< previous toc next >>