Guide pratique de gravure d'un CD RedHat

Adaptation française du Burning a RedHat CD HOWTO

Auteur : Luigi Bitonti

Auteur : Morten Kjeldgaard

Auteur : Peter von der Ahé

Vérification et traduction française: Guillaume Lelarge

Relecture de la version française: Guillaume Hatt

Préparation de la publication de la v.f.: Jean-Philippe Guérard

Version : 2.1.fr.1.0

2004-05-02

Historique des versions
Version 2.1.fr.1.02004-05-02GL, GH, JPG
Version 2.12003-10-17LB
Ajout de la RedHat 9. Correction de quelques bogues mineurs. Merci à tous ceux qui ont envoyé des commentaires et des correctifs.
Version 2.03.fr.1.02003-08-18GL, GH, JPG
Version 2.032003-03-10LB
Ajout de quelques commentaires et corrections pour le guide pratique. Les mises à jour anaconda sont maintenant incluses y compris les versions 7.x et plus.
Version 2.022003-03-06LB
La vérification de la signature fonctionne maintenant pour les paquets ciblés pour d'autres versions de la distribution RedHat que celle utilisée pour lancer les scripts. Correction d'un bogue dans la section de comparaison de version des scripts.
Version 2.012002-12-04LB
Deuxième édition de la nouvelle version de ce guide pratique. Tous les scripts ont été revus et nettoyés. Le script updateDist.sh vérifie maintenant que toutes les mises à jour ont été téléchargées avant de vérifier les signatures.
Version 2.02002-10-28LB
Première édition de la version 2 de ce guide pratique.

Résumé

Ce document explique comment créer vos propres CD à partir des différentes versions de la distribution Linux RedHat (jusqu'à la version 9), équivalents à ceux que RedHat commercialise. La structure de la distribution est décrite, ainsi que la procédure d'inclusion de paquets RPM mis à jour. Il donne quelques conseils et quelques exemples de personnalisation de l'installation par défaut. Ce document contient également des scripts automatisant autant que possible la (re)génération des images CD. Créer vos propres CD ne demandera qu'une bonne connexion réseau et un graveur de CD (une connaissance des scripts shells peut aussi être utile).


Table des matières

1. Introduction
1.1. Avertissement et license
2. Anatomie du site FTP de Red Hat
2.1. Organisation des répertoires de la distribution RedHat 9
2.2. Le répertoire RedHat, le cœur de la distribution
2.3. Le répertoire updates
2.4. Différences avec l'arbre 8.0
2.5. Différences avec l'arbre 7.x
2.6. Différences avec l'arborescence de la 6.x
3. Paquets RPM
3.1. Comparer deux versions d'un paquet RPM
4. Obtenir votre copie locale de la distribution
4.1. Utiliser wget et bash
4.2. Utiliser mirror
5. Inclure les mises à jour
5.1. Corriger les modes de protection des fichiers
5.2. Remplacer les RPM mis à jour
5.3. Reconstruire l'installateur
6. Graver le ou les CD
6.1. Essayer l'image ou les images
6.2. Graver le ou des disques
7. Le fichier comps
7.1. Format du fichier comps pour RedHat versions < 6.1
7.2. Format du fichier comps pour RedHat version 6.1
7.3. Format du fichier comps dans RedHat version 6.2
7.4. Format d'un fichier comps dans la RedHat version 7.3
7.5. Format du fichier comps à partir de RedHat version 8.0 et 9
8. Installer à partir du CD
8.1. Démarrer d'un CD amorçable
9. Autres distributions Linux
10. Ce document…
10.1. Documents en rapport
10.2. Remerciements
11. Adaptation française
11.1. Traduction
11.2. Relecture

1. Introduction

Il existe de nombreuses raisons de créer vos propres CD. Peut-être êtes-vous avare et voulez-vous économiser le prix d'une distribution Red Hat. Ou peut-être souhaitez-vous graver des CD contenant la plus récente distribution et toutes les dernières mises à jour. C'est très pertinent car après chaque version majeure de la distribution RedHat, de nombreuses mises à jour sont publiées, dont un certain nombre relatives à la sécurité. Jetez juste un œil sur la page d'errata. Ou peut-être voulez-vous personnaliser l'installation par défaut en ajoutant quelques paquets absents et en en retirant certains autres.

Voici ce que vous apprendrez dans les sections suivantes (je l'espère). Les exemples seront basés sur les versions 7.3, 8.0 et 9 de la distribution. Les notes relatives aux versions précédentes (<6.1) proviennent d'une version précédente et on été rassemblées par les auteurs originaux. Les notes relatives à la version 6.2 sont basées sur des essais que je n'ai pas terminés (et je ne sais pas si je les terminerai) et sur quelques documents que vous trouverez dans la section documents en rapport. La procédure donnée dans les sections suivantes pour RedHat 7.3 et 8.0 peut fonctionner sur toutes les plateformes compatibles avec cette distribution (Alpha, PPC, et cætera), pour toutes les versions 7.x (et peut-être les versions 8.x et 9 dans un avenir pas si lointain) mais je l'ai seulement essayée sur la plateforme i386 avec le Linux RedHat 7.3, 8.0 et 9 (je serais intéressé par plus d'informations).

[Note]Note

Les opérations décrites ont des implications légales, ce qui veut dire que vous ne pouvez pas redistribuer les CD en tant que RedHat Linux si vous les avez modifiés de façon non conforme à la politique de RedHat. Pour les rendre légalement redistribuables, vous devez d'abord appliquer les lignes de conduites indiquées sur le site web de RedHat.

[Note]Note

Rappelez-vous de toujours mettre en place les variables dans rhcd.conf et d'exporter la variable d'environnement RHCDPATH avant de lancer les scripts que vous trouverez tout au long du reste de ce document et en relation avec les versions supérieures ou égales à la 6.2 de la RedHat Linux. Un fichier rhcd.conf d'exemple, qui devrait être bien commenté, est donné avec les scripts.

1.1. Avertissement et license

Ce document est distribué dans l'espoir qu'il sera utile, mais SANS AUCUNE GARANTIE ; sans même la garantie implicite de qualité loyale et marchande ou d'exactitude pour un usage particulier.

Ni l'auteur ni les distributeurs, ou tout autre contributeur de ce document, ne sont de quelque façon que ce soit responsables pour les dommages physiques, financiers, moraux ou de tout autre type, occasionnés en suivant les suggestions de ce texte.

2. Anatomie du site FTP de Red Hat

Dans l'esprit de la communauté Linux, la société RedHat a rendu disponible ses distributions Linux pour plusieurs plateformes sur son site FTP. Elles sont toutes disponibles à partir de la racine du répertoire de distribution (pub/redhat/linux/). Jetez donc un œil sur l'arbre de la distribution.

2.1.  Organisation des répertoires de la distribution RedHat 9

La plus récente distribution n'est, à l'heure où j'écris ces lignes, disponible que pour la plateforme i386. Le répertoire de premier niveau semble un peu inutile, étant donnée la présence d'une seule architecture (/pub/redhat/linux/9/en/os/).

 
i386/

Le répertoire de premier niveau des versions un peu antérieures à la version 9 contient les distributions destinées aux différentes plateformes. Par exemple, le répertoire correspondant de la version 7.1 du Linux RedHat est structuré comme ceci :

 
alpha/   i386/   ia64/   ppc/   s390x/

Pour une distribution RedHat 9, la racine du répertoire i386 ressemble à ce qui suit :

 
-rwxr-xr-x   2 root   root    248 Mar 14  2003  autorun
drwxr-xr-x   7 root   root   4096 Mar 14  2003  dosutils
-rw-r--r--   3 root   root   6192 Mar 14  2003  EULA
-rw-r--r--   3 root   root  18385 Mar 14  2003  GPL
drwxr-xr-x   3 root   root   2048 Mar 14  2003  images
drwxr-xr-x   2 root   root   2048 Mar 14  2003  isolinux
-rw-r--r--   3 root   root   6127 Mar 14  2003  README
-rw-r--r--   2 root   root  13052 Mar 14  2003  README-Accessibility
-rw-r--r--   2 root   root   6686 Mar 14  2003  README.de
-rw-r--r--   2 root   root   6990 Mar 14  2003  README.es
-rw-r--r--   2 root   root   6492 Mar 14  2003  README.fr
-rw-r--r--   2 root   root   6805 Mar 14  2003  README.it
-rw-r--r--   2 root   root   7995 Mar 14  2003  README.ja
-rw-r--r--   2 root   root   7312 Mar 14  2003  README.ko
-rw-r--r--   2 root   root   5070 Mar 14  2003  README.pt
-rw-r--r--   2 root   root   6613 Mar 14  2003  README.pt_BR
-rw-r--r--   2 root   root   5879 Mar 14  2003  README.zh_CN
-rw-r--r--   2 root   root   5892 Mar 14  2003  README.zh_TW
drwxr-xr-x   4 root   root   2048 Mar 14  2003  RedHat
-rw-r--r--   2 root   root  25824 Mar 14  2003  RELEASE-NOTES
-rw-r--r--   2 root   root  29902 Mar 14  2003  RELEASE-NOTES-de.html
-rw-r--r--   2 root   root  30409 Mar 14  2003  RELEASE-NOTES-es.html
-rw-r--r--   2 root   root  32354 Mar 14  2003  RELEASE-NOTES-fr.html
-rw-r--r--   2 root   root  30064 Mar 14  2003  RELEASE-NOTES.html
-rw-r--r--   2 root   root  29925 Mar 14  2003  RELEASE-NOTES-it.html
-rw-r--r--   2 root   root  34666 Mar 14  2003  RELEASE-NOTES-ja.html
-rw-r--r--   2 root   root  33520 Mar 14  2003  RELEASE-NOTES-ko.html
-rw-r--r--   2 root   root  29496 Mar 14  2003  RELEASE-NOTES-pt_BR.html
-rw-r--r--   2 root   root  22747 Mar 14  2003  RELEASE-NOTES-pt.html
-rw-r--r--   2 root   root  25217 Mar 14  2003  RELEASE-NOTES-zh_CN.html
-rw-r--r--   2 root   root  26645 Mar 14  2003  RELEASE-NOTES-zh_TW.html
-rw-r--r--   3 root   root   1910 Mar 14  2003  RPM-GPG-KEY
-r--r--r--   1 root   root   1823 Mar 14  2003  TRANS.TBL

Le répertoire SRPMS contient les paquets RPMS en format source.

Le répertoire images contient les images des disquettes de démarrage et de pilotes. Ces images peuvent être copiés sur une disquette si nécessaire. Pour la version 9, il n'existe qu'une seule image de disque de démarrage. Cette image de démarrage est appelée boot.img. Si l'installation n'est pas exécutée depuis un CD-ROM ou un disque dur, il est nécessaire de préparer également une seconde disquette avec les pilotes. Un fichier boot.iso est maintenant également disponible. Il permet de démarrer une machine à partir du lecteur de CD-ROM afin de pouvoir plus facilement lancer une installation réseau (c'est-à-dire sans avoir besoin de manipuler une tonne de disquettes). Reportez-vous à la section installation et aux références qu'elle contient pour plus d'informations. Consultez le fichier README contenu dans ce répertoire pour obtenir une explication plus détaillée du rôle des différents fichiers.

Le répertoire isolinux contient les fichiers nécessaires au démarrage depuis le CD (et pour reconstruire des CD de démarrage qui fonctionnent de la même façon). Ce processus a été modifié pour passer d'une émulation de disquette à pas d'émulation du tout. Ce qui aide à éviter les contraintes d'espace et les problèmes de compatibilité.

Le répertoire dosutils contient différents programmes pour certains autres systèmes d'exploitation, qui sont parfois utiles pour le bon déroulement du processus d'installation. Il contient aussi un fichier README explicatif.

La liste est complétée par un grand nombre de fichiers et par le répertoire RedHat. Ce dernier est le sujet des sections qui suivent tandis que le contenu des précédents est clairement indiqué par leur nom (sauf peut-être le fichier EULA dont le nom est l'abréviation [en anglais] de « Accord de licence avec l'utilisateur final »).

2.2.  Le répertoire « RedHat », le cœur de la distribution

La majeure partie de l'arborescence de la distribution se situe dans le répertoire RedHat :

 
drwxr-xr-x   2 root   root  53248 Jun 14 03:15  RPMS
drwxr-xr-x   2 root   root   4096 Jun 14 04:15  base

Le répertoire RPMS contient la majeure partie de la distribution RedHat, sous la forme d'un ensemble de fichiers RPM (abréviation de Redhat Package Manager, c'est-à-dire « gestionnaire de paquets RedHat »). Un paquet RPM contient en général des exécutables binaires, accompagnés de leurs fichiers de configuration et de leur documentation. Référez-vous à la section les paquets RPM pour plus d'informations.

Le répertoire base contient différents fichiers nécessaires lors de l'installation, comme le fichier comps.xml, qui définit les composants (groupes de paquets) utilisés durant la phase « Sélection des groupes de paquetages[1] ». Reportez-vous à la section le fichier comps pour plus d'informations sur ce fichier et son utilisation.

Le répertoire base contient 2 autres fichiers d'importance : hdlist et hdlist2. Ils contiennent la plupart des informations incluses dans les champs d'entêtes de l'ensemble des paquets RPM du répertoire RPMS. Il est donc possible de déterminer les interdépendances entre paquets RPM par une simple lecture de ces fichiers, sans avoir à lire chacun des paquet RPM, ce qui est très appréciable notamment lors des installations par FTP. Ces fichiers permettent également de déterminer les fichiers correspondant à un paquet donné (par exemple perl renvoie vers le paquet perl-5.004-6.i386.rpm). Ce qui veut dire que si vous ajoutez vos propres paquets ou des mises à jour RedHat (reportez-vous à la section inclure les mises à jour) dans le répertoire RPMS, vous aurez besoin de mettre à jour hdlist et hdlist2. La façon de réaliser cette mise à jour sera décrite dans reconstruire l'installateur. En dehors de ces fichiers, on trouve les images à partir desquelles l'environnement d'installation est lancé (c'est-à-dire le noyau, l'interpréteur python, anaconda, et cætera).

2.3. Le répertoire « updates »

Le répertoire /pub/redhat/linux/updates contient des mises à jour destinées à toutes les versions de la distribution RedHat depuis la 3.0.3. C'est l'endroit où vous trouverez les paquets qui ont été mis à jour pour une raison ou une autre. Vous devez tout particulièrement faire attention aux mises à jour de sécurité. Elles sont affichées sur la page des erreurs de RedHat dès qu'une correction est disponible. Les fichiers les plus importants trouvés dans le répertoire updates sont :

 
drwxrwsr-x   3 root    root    4096 Jul 13 10:13  5.2
drwxrwsr-x   3 root    root    4096 Jul 13 10:13  6.0
drwxrwsr-x   3 root    root    4096 Jul 13 10:13  6.1
drwxrwsr-x   4 root    root    4096 Jul 13 10:14  6.2
drwxrwsr-x   4 root    root    4096 Jul 13 10:14  7.0
drwxrwsr-x   4 root    root    4096 Jul 13 10:14  7.1
drwxrwsr-x   4 root    root    4096 Jul 13 10:13  7.2
drwxrwsr-x   3 root    root    4096 Jul 13 10:14  7.3
drwxrwsr-x   3 root    root    4096 Jul 13 10:14  8.0
drwxrwsr-x   3 root    root    4096 Jul 13 10:14  9

La structure de chacun de ces sous-répertoires est similaire à ce qui est décrit dans la section l'organisation de la Redhat 9. Donc, pour chaque version, vous trouverez dans le sous-répertoire en/os/ une série de sous-répertoires représentant les nombreuses architectures ainsi que les sous-répertoires noarch et SRPMS, respectivement pour les paquets qui fonctionnent sur toutes les architectures et pour ceux qui sont sous forme de source.

 
drwxrwsr-x   2 root    root    4096 Sep 23 05:28  SRPMS
drwxrwsr-x   2 root    root    4096 Aug 28 18:25  athlon
drwxrwsr-x   2 root    root    8192 Sep 23 05:28  i386
drwxrwsr-x   2 root    root    4096 Jul 13 10:14  i486
drwxrwsr-x   2 root    root    4096 Aug 28 18:26  i586
drwxrwsr-x   2 root    root    4096 Aug 28 18:26  i686
drwxrwsr-x   2 root    root    4096 Jul 13 10:14  noarch

2.4. Différences avec l'arbre 8.0

La disposition de la distribution 8.0 est pratiquement identique à celle que nous venons de décrire. Les seules différences majeures, à cet égard, se trouvent dans le répertoire images.

Le répertoire images contient les images de disquettes de démarrage et de pilotes, pouvant être copiées sur une disquette si nécessaire. La première image de démarrage est appelée boot.img et est nécessaire lorsque l'installation est exécutée directement depuis le CD-ROM. Si vous envisagez une installation via un disque monté par NFS ou par FTP, l'image disque bootnet.img sera nécessaire. Les installations via l'adaptateur PCMCIA nécessitent la disquette pcmcia.img. Reportez-vous à la section installation et aux références qui s'y trouvent pour plus d'informations. Consultez le fichier README contenu dans ce répertoire pour obtenir une explication plus détaillée du rôle des différents fichiers.

2.5. Différences avec l'arbre 7.x

Les deux distributions sont pratiquement similaires sous cet aspect. Les seuls changements intéressants pour nous (et faciles à remarquer en regardant l'arborescence de la distribution) sont la disparition du répertoire isolinux et quelques modifications affectant le répertoire RedHat/base. Le premier changement est dû à la façon dont les CD d'installation sont rendus amorçables dans les versions antérieures à la 8.0 (le mode « émulation disquette » a été changé en mode « pas d'émulation » pour la version 8.0), alors que le second est un effet du passage en XML du fichier comps pour les distributions Redhat postérieures à la 8.0 (ce qui explique pourquoi il a été renommé comps.xml). Dans les distributions RedHat 7.3 et précédentes, le fichier Redhat/base/comps est un simple fichier texte dont la syntaxe n'est pas très souple.

2.6. Différences avec l'arborescence de la 6.x

Pour la version 6.2 (ftp://ftp.redhat.com/pub/redhat/linux/6.2/en/os/), la dernière de la série des 6, l'organisation est la suivante (celle des précédentes versions est à peu près similaire, mais pas complètement) :

alpha/   i386/   sparc/

La racine du répertoire i386, quant à elle, ressemble à ceci :

-rw-r--r--   1 root   root  18385 Sep  7  1999  COPYING
-rw-r--r--   1 root   root   3400 Mar  8  2000  README
-rw-r--r--   1 root   root  16300 Mar  8  2000  RELEASE-NOTES
-rw-r--r--   1 root   root   1908 Sep 25  1999  RPM-GPG-KEY
drwxr-xr-x   1 root   root    512 Sep 27 15:22  RedHat
drwxr-xr-x   1 root   root  17408 Sep 27 15:22  SRPMS
-rwxr-xr-x   1 root   root    538 Sep 26  1999  autorun
-rwxr--r--   1 root   root   2048 Mar  9  2000  boot.cat
drwxr-xr-x   1 root   root    512 Sep 27 15:22  doc
drwxr-xr-x   1 root   root    512 Sep 27 15:22  dosutils
drwxr-xr-x   1 root   root    512 Sep 27 15:22  images
drwxr-xr-x   1 root   root    512 Sep 27 15:22  misc

Dans les paragraphes suivants, j'indiquerai uniquement les différences avec les versions plus récentes ; ce qui ne sera pas explicitement mentionné ici est resté (ou est supposé être resté) inchangé.

Le répertoire doc contient une foule d'informations. En premier lieu, ce répertoire contient le manuel d'installation RedHat au format HTML (qui est aussi disponible sur le site de RedHat : Guide d'installation RedHat 6.2). Il contient également le Guide de référence et le Guide de démarrage (Getting started). La documentation des versions 7.x, 8.0 et 9 est distribuée sur un CD séparé (dans une arborescence différente sur le site ftp).

Le répertoire images contient les images de disquettes de démarrage. Si nécessaire, ces images peuvent être recopiées sur disquette, comme pour les distributions RedHat 9, 8.0 et 7.3. Référez-vous à la section installation et aux références qu'elle contient pour plus d'information. Le répertoire misc contient les sources et les exécutables d'un certain nombre de programmes nécessaires à l'installation.

La plus importante partie de l'arborescence est (encore) située sous le répertoire RedHat :

drwxr-xr-x   2 root   root   28672   Oct 26 09:01  RPMS
drwxr-xr-x   2 root   root    4096   Oct 26 09:01  base
-rw-r--r--   1 root   root       0   Jan 19  1999  i386
drwxr-xr-x   6 root   root    4096   Oct 26 09:01  instimage

Vous devez déjà connaître Le répertoire RPMS. Référez-vous à la section les paquets RPM pour plus d'informations. Le répertoire base contient les différents fichiers nécessaires à l'installation, comme pour les RedHat 7.3, 8.0 et 9. Les seules différences visibles sont la présence d'un unique fichier hdlist et l'absence du fichier stage2.img dont les fonctionnalités devraient être assurées par les fichiers contenus dans le répertoire instimage. Ce répertoire contient, en fait, un vrai système de fichiers limité à l'essentiel et comportant les programmes et bibliothèques partagées nécessaires à l'installation.

Le répertoire updates est en fait similaire à celui qui est décrit pour la version 9, la seule différence étant qu'il comporte davantage de répertoires relatifs aux différentes architectures.

3. Paquets RPM

La majeure partie de la distribution RedHat consiste en un ensemble de fichiers RPM ((abréviation de Redhat Package Manager, c'est-à-dire « gestionnaire de paquets RedHat »). Un paquet RPM contient en général des exécutables binaires, accompagnés de leurs fichiers de configuration et de leur documentation. Le programme rpm est un puissant gestionnaire de paquets, qui peut être utilisé pour installer, interroger, vérifier, mettre à jour, effacer et construire des paquets au format RPM. Rpm est très pratique car il gère une base de données de tous les paquets installés, ce qui permet de savoir à tout moment ce qui est installé.

Les fichiers binaires RPM inclus dans la distribution ont été construits sur un système utilisant lui-même la distribution. C'est important car la plupart des programmes des paquets dépendent de bibliothèques partagées. La nouvelle version 3 de la bibliothèque C standard GNU (compatible 64 bits) a été utilisée à partir de la distribution RedHat 5.0. Cette version de la bibliothèque est communément appelée glibc ou, sous Linux, libc 6. Tous les exécutables de cette distribution ont été liés à cette bibliothèque. Si vous tentez d'installer les fichiers binaires d'une distribution différente, il y a beaucoup de chances que cela ne fonctionne pas, sauf si vous installez le paquet libc5 pour obtenir une compatibilité descendante. Il existe aussi des incompatibilités entre les nombreuses versions du RedHat Package Manager lui-même qui empêcheront l'installation de certains paquets même sur les machines où ils sont supposés fonctionner.

Les noms des paquets RPM contiennent le suffixe .archi.rpm, où archi est l'architecture. Celle-ci a habituellement pour valeur i386 pour les binaires destinés à la plateforme Intel. Les paquets que vous installez doivent correspondre aux versions des bibliothèques partagées installées sur la machine. Le programme rpm est habituellement assez bon pour s'en assurer. Néanmoins, il existe des moyens de passer outre cette vérification. Si vous décider de forcez l'installation d'un paquet de cette façon, soyez vraiment sûr de savoir ce que vous faites. Néanmoins, l'utilisation du disque de démarrage d'installation de RedHat vous garantie qu'un ensemble correct de paquets RPM sera installé sur la machine.

Si vous découvrez un paquet RPM qui n'a pas été installé sur votre système durant le processus d'installation, ne désespérez pas. À tout moment, vous pourrez (sous le compte root) installer des paquets RPM. Par exemple :

# rpm --install WindowMaker-0.18-1b.i386.rpm

Vous pouvez même installer un paquet RPM directement depuis Internet, si vous connaissez son URL :

# rpm --install ftp://rufus.w3.org/redhat-contrib/noarch/mirror-2.9-2.noarch.rpm

Si vous voulez mettre à jour un paquet RPM (ou l'installer s'il n'est pas présent sur la machine), utilisez la commande :

# rpm --update  WindowMaker-0.18-1b.i386.rpm

Si vous voulez mettre à jour un paquet RPM et seulement si une version précédente est déjà installée, utilisez la commande :

# rpm --freshen  WindowMaker-0.18-1b.i386.rpm

Une autre version des paquets RPM contient les sources originaux utilisés pour construire les binaires. Ces paquets ont le suffixe .src.rpm et sont situés dans le répertoire SRPMS. Ces paquets composent les deux derniers CD et une partie du troisième sur cinq, qui font la version 8.0 (ou la 7.3). Pour la 9, ils sont sur trois CD séparés. Pour la 6.2 (et les précédentes versions, pas trop anciennes), les choses changent un peu puisqu'il n'existe qu'un seul CD d'installation qui ne comporte pas les paquets SRPMS, que vous pouvez graver sur un disque différent si vous le voulez.

Pour obtenir plus d'informations sur le gestionnaire de paquet RedHat, je vous suggère de lire les pages man et le livre bien détaillé Maximum rpm.

Dans la prochaine section, j'introduirai un programme C qui sera utilisé dans des scripts variés tout au long du reste de ce guide pratique. Il indique, entre deux versions du même paquet RPM, celui qui est le plus récent. Ce programme est basé sur le code utilisé dans le gestionnaire de paquets RedHat (version 4.1) et est utilisé quand l'option --freshen est ajoutée.

3.1. Comparer deux versions d'un paquet RPM

Le code C inclus dans les trois fichiers Makefile, rvc.h, rvc.c a été extrait du gestionnaire de paquets RedHat et (légèrement) modifié pour combler vos besoins. Ils forment un programme C simple qui, avec deux versions A et B d'un paquet retourne 1, 0 ou -1 si A est respectivement plus récent, égal ou plus ancien que B et d'autres valeurs en cas d'erreur (vous pouvez lire les commentaires du code pour des informations plus détaillées). Pour compiler le programme, vous avez besoin du programme make et du compilateur C gcc. Copiez le fichier dans le même répertoire et envoyez la commande :

$ make

Ce programme est nécessaire pour pratiquement tous les scripts utilisés dans les sections suivantes et met en place la variable RVC dans le fichier rhcd.conf.

Vous pouvez trouver une copie des sources et de la version précompilée dans l'archive rhcd-scripts.tar.gz située dans le répertoire rpmvc.

[Note]Note

Il existait une erreur dans la façon dont ce programme était utilisé par les scripts updateDist.sh (ver. < 1.17) et updateCD.sh (ver. < 1.12). Je vous suggère fortement d'éviter les versions des scripts ayant de plus petits numéros de versions que ceux rapportés ici, même si le problème n'est pas fréquent (au moins apparemment).

4. Obtenir votre copie locale de la distribution

Vous avez besoin d'une copie de la distribution sur un disque où vous pouvez écrire, et accessible à partir de l'ordinateur possédant le graveur. Si vous incorporez les dernières mises à jour, le répertoire doit (aussi) être accessible à partir d'une machine Linux, soit à partir d'un disque local, soit à partir du disque monté par NFS d'une autre machine, soit à partir d'un disque JAZ. Vous pouvez copier la distribution à partir des CD de RedHat (recommandé), ou vous pouvez l'obtenir via FTP. Si vous choisissez d'utiliser FTP, il existe deux moyens de le faire. Vous pouvez utiliser un script shell basé sur wget, script présenté dans la section suivante, ou utiliser le paquet mirror comme suggéré par les versions précédentes et jusqu'à la 1.34 incluse de ce guide pratique (rapporté dans la section utiliser mirror).

4.1. Utiliser wget et bash

Ce n'est pas la plus simple des méthodes, même si elle est la plus précise. Je l'apprécie parce qu'elle permet de comparer les versions RPM des fichiers et non plus leur date/heure ou nom (comme les paquets standards de miroirs) et qu'elle vérifie les signatures des mises à jour à chaque fois qu'elle en télécharge quelques unes, si ceci est bien configuré avec la variable CHECKSIG dans le fichier rhcd.conf.

Créez un répertoire qui contiendra les fichiers d'installation et entrez à l'intérieur (cd) ; lancez ensuite la commande (qui téléchargera environ 3 Go de données sur votre disque dur) :

 
$ wget -r -c -t0 -l0 --retr-symlinks -nH --cut-dirs=9 \
  ftp://ftp.mirror.ac.uk/sites/ftp.redhat.com/pub/redhat/linux/updates/7.3/en/os/i386

Vous voudrez probablement changer le miroir FTP de téléchargement et, en conséquence, le paramètre passé à l'option --cut-dirs. C'est en fait utilisé conjointement avec -nH pour éviter la re-création de la hiérarchie des répertoires du site FTP. Pour plus d'informations sur l'utilisation correcte de cette option, jetez un œil sur la documentation wget et les pages man correspondantes.

Si vous voulez exclure un ou plusieurs répertoires des téléchargements, vous pouvez utiliser l'option -X liste, où liste représente une liste de répertoires séparés par des virgules. Par exemple, pour exclure le répertoire SRPMS des précédents téléchargements, vous pouvez utiliser :

 
$ wget -r -c -t0 -l0 --retr-symlinks -nH --cut-dirs=9 \
   -X /sites/ftp.redhat.com/pub/redhat/linux/updates/7.3/en/os/i386/SRPMS \
   ftp://ftp.mirror.ac.uk/sites/ftp.redhat.com/pub/redhat/linux/updates/7.3/en/os/i386

Cela peut être utile si vous considérez la taille du répertoire SRPMS (environ 1.2 Go) ; en tout cas, je le trouve utile.

Si vous voulez vérifier les signatures GPG pour vous assurer de l'authenticité des paquets (ce que je recommende), vous devez installer le paquet gnupg (nécessaire uniquement pour la RedHat 7.3) et importer la clé publique security@redhat.com que vous trouverez dans le répertoire racine des CD (RPM-GPG-KEY) ou sur le site web RedHat. La clé est importée en lançant la commande : gpg --import <filename> pour les versions jusqu'à la 7.3 (en l'incluant), ce qui a été remplacé par rpm --import <filename> pour la version 8.0 et 9 (pour plus d'informations sur ceci, jetez un œil sur les sites web de GNU Privacy Guard et de RPM — Redhat Package Manager).

Si vous voulez vérifier les paquets RPM, vous pouvez le faire en utilisant la commande suivante (je suppose que vous la lancez à partir du répertoire où vous avez réalisé les téléchargements) :

Pour les versions jusqu'à la 7.3 (comprise) :

 
$ find . -name "*.rpm" -exec rpm -K --nopgp {} \; |grep "NOT *OK"

Pour les versions 8.0 et 9 (ainsi que pour les futures versions, je suppose) :

 
$ find . -name "*.rpm" -exec rpm -K {} \; |grep "NOT *OK"

Si vous ne voulez pas vous « ennuyer » avec toutes ces étapes, j'espère que vous voudrez au moins vérifier l'intégrité des fichiers téléchargés (ce qui ne veut pas dire que personne ne les a modifiés), à l'aide des signatures md5. Ceci est fait avec :

Pour les versions jusqu'à 7.3 (incluse) :

$ find . -name "*.rpm" -exec rpm -K --nopgp --nogpg {} \; |grep "NOT *OK"

Pour les versions 8.0 et 9 (ainsi que pour les versions à venir, je suppose) :

 
$ find . -name "*.rpm" -exec rpm -K --nosignature {} \; |grep "NOT *OK"

Le contenu d'une distribution RedHat ne change pas entre les versions, donc vous avez seulement besoin de télécharger ces paquets UNE FOIS. Tous les changements de la distribution sont dans le répertoire updates. Donc, si vous voulez conserver un miroir à jour de la distribution RedHat, vous avez seulement besoin de maintenir le répertoire updates à jour. Ceci se fait en utilisant le script updateDist.sh. Avant d'utiliser le script, vous devez configurer le fichier rhcd.conf et exporter la variable RHCDPATH pointant vers le répertoire où se trouve le fichier.

$ export RHCDPATH=/home/luigi/tmp/rhcd-scripts
$ sh updateDist.sh

Ce script va télécharger les nouvelles mises à jour en excluant les sous-répertoires contenus dans la variable EXCLUDELIST, en déplaçant les anciens (c'est-à-dire ceux remplacés par les nouvelles versions) dans le répertoire représenté par la variable OLDDIR après avoir réussi deux tests. Le premier test compare les fichiers .listing générés par wget avec le contenu des répertoires locaux pour s'assurer que tous les fichiers ont été téléchargés. Le deuxième test vérifie les signatures des paquets suivant les valeurs de deux variables CHECKSIG et USEGPG (initialisez-les à « yes » si vous souhaitez terminer complètement l'opération). En cas d'échec dans le processus de vérification de signature, le script déplacera les mauvais paquets dans OLDDIR en leur affectant l'extension « .UPDcheckfail » et quittera sans déplacer les anciennes mises à jour dans OLDDIR.

4.2. Utiliser mirror

Mirror est un script perl sophistiqué comparant le contenu d'un répertoire d'un site distant avec un répertoire local. Il utilisera FTP pour récupérer les fichiers qui sont sur le site distant mais pas sur le site local, et supprimera sur le site local les fichiers qui ne sont pas sur le site distant. Le programme mirror est configuré avec un fichier. Le RPM du paquet est disponible à partir de rufus.w3.org. Créez votre copie locale mirror.redhat du fichier de configuration de mirror, et éditez les champs correspondant au haut du fichier. Après la section par défaut, définissez ces paquets:

 
package=updates
  site=ftp.mirror.ac.uk
  exclude_patt=(SRPMS/)
  remote_dir=/sites/ftp.redhat.com/pub/redhat/linux/updates/7.3/en/os/i386
  local_dir=/home/luigi/tmp/redhat-cd/redhat-7.3-updates

package=dist
  site=ftp.mirror.ac.uk
  exclude_patt=(SRPMS/)
  remote_dir=/sites/ftp.redhat.com/pub/redhat/linux/7.3/en/os/i386
  local_dir=/home/luigi/tmp/redhat-cd/redhat-7.3

La commande suivante va copier l'arbre RedHat en entier sur votre disque local. **Pensez**, avant de faire cela, que vous allez télécharger à peu près 1,5 Go de données (si vous avez exclu le répertoire SRPMS) !

 
$ mirror -pdist mirror.redhat 

Ceci va créer le miroir du site FTP de RedHat sur votre disque local. Le contenu de la distribution RedHat ne change pas entre les versions, donc vous avez seulement besoin de télécharger ces paquets une fois. Tout changement dans la distribution se trouve dans le répertoire updates. Donc, si vous voulez que votre miroir reste à jour, vous avez seulement besoin d'actualiser le répertoire updates. Cela se fait avec la commande suivante :

 
$ mirror -pupdates mirror.redhat 

Vous pouvez la lancer régulièrement, disons une fois par semaine, avec un script cron. La distribution RedHat est disponible sur un grand nombre de serveurs FTP tout autour du monde, mis à jour quotidiennement à partir du site maître ftp.redhat.com. Vous devriez choisir un site FTP proche de vous, en consultant la liste des sites miroirs RedHat.

[Note]Note

Je n'ai pas personnellement testé cette procédure. C'était la seule procédure proposée sur les anciennes versions de ce guide pratique (jusqu'à la version 1.34, concernant RedHat < 6.1).

5. Inclure les mises à jour

Il y a trois étapes, les deux premières étant (pratiquement) identiques pour toutes les versions, alors que la dernière change un peu en raison des modifications de l'installateur anaconda :

  1. Corriger les modes de protection de fichier

  2. Remplacer les RPM mis à jour

  3. Reconstruire l'installateur

Pour incorporer les mises à jour, vous avez besoin d'avoir les droits d'accès au répertoire de la distribution à partir de la machine Linux, avec une version fonctionnelle de rpm installée, alors que pour reconstruire l'installateur anaconda, vous avez besoin d'utiliser une version du Linux RedHat égale à celle pour laquelle vous avez reconstruit l'installateur (sinon la procédure échouera) . Si vous maintenez un miroir du répertoire updates, vous pouvez à tout moment produire un CD incluant les dernières mises à jours en répétant ces étapes.

5.1. Corriger les modes de protection des fichiers

Durant le processus d'installation des versions jusqu'à la 6.2 (comprise), quelques programmes sont lancés directement du CD. Malheureusement, le programme FTP ne préserve pas toujours les modes de protection des fichiers et des répertoires qui sont copiés. Donc, il est nécessaire de s'assurer que la permission d'exécuter est donnée aux programmes, scripts shells et bibliothèques partagées, avant que le répertoire ne soit gravé sur le CD. Ceci est fait en lançant le script updatePerm.sh sur votre copie locale de la distribution. C'est réellement nécessaire pour les versions 6.2 et précédentes, la seule partie utile à la procédure des versions 7.3/8.0/9 est la mise à jour des droit des répertoires, même si le reste ne posera pas de problème et que tout restera cohérent. C'est pratiquement identique au script updatePerm inclus dans la précédente version de ce guide pratique, seuls quelques petits changements ont été réalisés. Avant d'utiliser ce script, vous devez configurer le fichier rhcd.conf et exporter la variable RHCDPATH pointant vers le répertoire où se trouve le fichier.

$ export RHCDPATH=/home/luigi/tmp/rhcd-scripts
$ sh updatePerm.sh

5.2. Remplacer les RPM mis à jour

Le script updateCD.sh copie tous les nouveaux fichiers du répertoire update vers le répertoire RPMS (et SRPMS). Le script utilise le programme rvc qui a été présenté dans la section comparer les versions des RPM pour déterminer quels paquets dans le répertoire update sont les plus récents. Les anciens paquets sont déplacés dans le répertoire ${OLDDIR}. Si la variable CHECKSIG est mise sur « yes », tous les paquets dans l'arbre principal verront leur signature vérifiée. Si la vérification de signature d'un paquet échoue (le genre de vérification est configuré par l'usage de la variable USEGPG, assignée dans le fichier rhcd.conf), celui-ci est déplacé dans le répertoire OLDDIR avec une extension ajoutée, « CDcheckfail ».

Avant d'utiliser ce script, vous devez configurer le fichier de configuration rhcd.conf et exporter une variable RHCDPATH pointant vers le répertoire où se trouve ce fichier.

$ export RHCDPATH=/home/luigi/tmp/rhcd-scripts
$ sh updateCD.sh
[Note]Note

Après avoir incorporé les mises à jour dans le répertoire principal RedHat/RPMS, votre copie de la distribution n'est plus un miroir du site de la distribution RedHat. Néanmoins, il est plus à jour ! Donc, si vous essayez de faire le miroir de la distribution en utilisant mirror, les anciennes versions des RPM qui ont été mis à jour seront téléchargées une fois de plus, et les mises à jour supprimées. La procédure basée sur bash/wget ne souffre pas de ce problème, mais laissera l'arbre principal dans un état incohérent. Les anciens et les nouveaux paquets seront dans ce cas mélangés, mais vous pouvez les trouver et les supprimer en intégrant le binaire rvc dans un script shell simple (que je laisserai comme exercice pour le lecteur…).

5.3. Reconstruire l'installateur

Les choses ont bien changé dans cette section avec l'arrivée de l'installateur anaconda (version 6.1) et l'augmentation considérable en taille (et… en nombre de CD) que les distributions 7.x et 8.0 ont connue. Jusqu'à la version 6.2, la seule étape composant cette section était représentée par la génération d'un nouveau fichier hdlist. Avec la version 6.2, cela reste vrai seulement jusqu'à un certain point, en raison des changements dans l'installateur anaconda, dans le logiciel rpm lui-même (à partir des versions 3.x, jusqu'au 4.x) et de la migration des paquets mis à jour vers cette nouvelle version (les mises à jour pour la version 6.2 sont en fait packagées avec les deux versions majeures du logiciel rpm). Nous considèrerons les trois procédures différentes en essayant de couvrir toutes les versions.

5.3.1. RedHat ≤ 6.1

5.3.1.1. Regénérer le fichier hdlist

Lors de l'installation à partir du CD, le programme d'installation sur le CD dépend du fichier RedHat/base/hdlist qui décrit quels sont les paquets RPM disponibles sur le CD. Le fichier hdlist peut être généré par le programme misc/src/install/genhdlist. Ce programme doit être lancé avec le chemin absolu vers la racine de la distribution comme seul argument. Voici le script updateHdlist qui appelle ce programme (à partir de la version 1.34 de ce guide pratique) :

#!/bin/bash

RHVERSION=6.1
ARCH=i386

echo generating hdlist...
RHROOT=/home/luigi/tmp/redhat-${RHVERSION}
GENHDDIR=${RHROOT}/${ARCH}/misc/src/anaconda/utils
          
chmod u+x ${GENHDDIR}/genhdlist
chmod 644 ${RHROOT}/${ARCH}/RedHat/base/hdlist
${GENHDDIR}/genhdlist ${RHROOT}/${ARCH} || echo "*** GENHDLIST FAILED ***"

exit 0
[Note]Note importante pour la RedHat < 6.1

L'installation de la RedHat 6.1 est complètement différente de celle des versions précédentes car RedHat a introduit anaconda. Le programme genhdlist est maintenant localisé à un autre endroit, donc dans le script ci-dessus, nous utilisons

GENHDDIR=${RHROOT}/${ARCH}/misc/src/anaconda/utils

alors que pour les versions jusqu'à la 6.0 (comprise), cette ligne doit être

GENHDDIR=${RHROOT}/${ARCH}/misc/src/install

Dans certains cas, genhdlist échoue lors de son exécution, parce que l'exécutable n'est pas lié statiquement. Dans un tel cas, vous pouvez ajouter une nouvelle ligne ${RHROOT}/${ARCH}/RedHat/instimage/usr/lib dans /etc/ld.so.conf et lancer ldconfig -v.

Une autre solution est de recompiler genhdlist. La modification suivante au script updateHdlist a fonctionné sous RedHat 5.2 :

#!/bin/bash

RHVERSION=6.1
ARCH=i386

RHROOT=/misc/redhat/redhat-${RHVERSION}
GENHDDIR=${RHROOT}/${ARCH}/misc/src/anaconda/utils

echo Compiling genhdlist...
sed -e 's/FD_t/int/' \
    -e 's/fdOpen/open/' \
    -e 's/fdClose/close/' \
    -e 's/fdFileno//' < ${GENHDDIR}/genhdlist.c > /tmp/genhdlist.c
cc -o /tmp/genhdlist -I/usr/include/rpm /tmp/genhdlist.c -lrpm -lz

echo generating hdlist...
chmod 644 ${RHROOT}/${ARCH}/RedHat/base/hdlist
/tmp/genhdlist ${RHROOT}/${ARCH} || echo "*** GENHDLIST FAILED ***"

exit 0

Dans cette version du script, une copie du source C de genhdlist.c est envoyée à sed à travers un tube pour créer une copie dans /tmp qui compilera sous RedHat 5.2. Cette version de genhdlist est alors utilisée pour créer le fichier hdlist.

[Note]Note importante pour la RedHat 5.2

Tel qu'il est distribué avec la RedHat versions 5.2 et précédentes, genhdlist PLANTE si les fichiers dans le répertoire RedHat/RPMS ne sont pas des fichiers RPM ! Il cause des problèmes parce que dans la distribution 5.2, il existe un couple de fichiers non-RPM nommés ls-lR et ls-lR.gz situés dans RedHat/RPMS. Donc, vous devez supprimer tous les fichiers non-RPM du répertoire. Sinon, vous pouvez appliquer le correctif genhdlist.c.diff au fichier misc/src/install/genhdlist.c et faire un make. Ce correctif fait que genhdlist ignore tout fichier non-RPM.

5.3.1.2. Créer l'image iso du CD

Vous aurez besoin de créer un fichier image qui sera écrit sur le CD. Ce fichier fera 500 Mo ou plus donc trouvez une partition avec assez d'espace disque libre. Vous pouvez avoir besoin d'être root pour utiliser mount et cdrecord. Ici, vous préparerez l'image iso du CD amorçable à graver. Il n'est pas strictement nécessaire de créer un CD amorçable parce que vous pouvez utiliser une disquette de démarrage à la place, mais c'est vraiment une fonctionnalité sympathique (et elle rend votre disque plus similaire au disque général). Voici les commandes que j'utilise pour réaliser cette tâche :

$ mkdir /repertoire-destination-images
$ mkisofs  -r  -J  -T  -v  -V "Red Hat 6.1 (Hedwig)" \
   -c boot.cat  -b images/boot.img \
   -o /repertoire-destination-images/i386-disc.iso .

C'est nécessaire pour graver le disque (amorçable) et c'est exécuté à partir du répertoire haut niveau de la distribution. Le répertoire /repertoire-destination-images est le contenant de l'image iso que vous générez et il doit exister (nécessairement) avant le lancement de la procédure. Dans la table suivante, vous pouvez lire une brève explication des nombreuses options et de leur intérêt (la plupart ont été extraites de la page de manuel de mkisofs).

Tableau 1. Options et paramètres de mkisofs

-r  Extensions Rock Ridge avec les valeurs utiles pour les droits
-J  Extensions Joliet pour utiliser le CD avec quelques différents systèmes d'exploitation
-T  Génère un fichier TRANS.TBL dans chaque répertoire pour faire correspondre les noms de fichiers même sur des systèmes qui ne supportent pas des extensions Rock Ridge
-v Mode bavard

-V <volid>

  Spécifie l'ID du volume (nom du volume ou label) à écrire dans le bloc maître.

-c <boot catalog>

  Spécifie le chemin et le nom du fichier du catalogue de démarrage à utiliser lors de la création du CD amorçable « El Torito ». Le nom du fichier doit être relatif au chemin source spécifié à mkisofs.

-b <eltorito boot image>

  Spécifie le chemin et le nom du fichier de l'image de démarrage à utiliser lors de la création du CD amorçable « El Torito ». Le chemin doit être relatif au chemin source spécifié à mkisofs et doit indiquer une image de disquette (ce qui explique pourquoi nous utilisons une des images de disquette trouvée sur le CD original). Vous pouvez vouloir le changer avec l'image pcmcia.img pour installer en utilisant des périphériques pcmcia comme des cartes réseau ou des lecteurs CDROM.

-o <filename>

 Nom du fichier contenant l'image iso générée
.  Ceci est le répertoire racine de notre image iso (nous sommes en train de travailler à partir du répertoire racine de chaque CD, donc un point est suffisant).

Vous trouverez des détails sur la façon de graver une image sur un média dans graver le CD. Les étapes mkisofs et cdrecord peuvent être exécutées en utilisant une application graphique comme X-CD-Roast qui doit déjà supporter la création de CD amorçables (je ne l'ai jamais utilisé, donc ne vous attendez pas à ce que je vous donne une explication).

5.3.2. RedHat 6.2

Apparemment, il existe un problème lorsque vient le moment de graver un CD à mettre à jour. L'introduction de la version 4 du gestionnaire de paquets RedHat (RPM) fait que la procédure de mise à jour de l'installateur anaconda échoue. Donc, les procédures listées fonctionneront seulement si les paquets mis à jour sont construits en utilisant une version du logiciel RPM qui est antérieure ou égale à la 3.0.4 (donc, basiquement, 3.0.4 ou 3.0.5).

Si vous utilisez les paquets originels de RedHat, il faut éviter d'utiliser les mises à jour sorties après le 28 mars 2001 (ce qui est un peu inutile, selon moi) ou alors vous devez reconstruire les paquets en utilisant l'ancien format rpm. Les détails sur la procédure et les outils qui l'implémentent peuvent être trouvés dans le document rpmhack. Je n'ai pas personnellement testé cette procédure, mais elle semble fonctionner d'après les listes de diffusion anaconda-devel et kickstart (vous pouvez les trouver sur la section des listes de diffusion du site web de RedHat).

Si vous décidez de rester sur les anciens paquets originels et de compléter la mise à jour (en utilisant les paquets rpm 4.0.2 après que l'installation est finie), il existe deux façons de le faire, en fonction du type de mise à jour que vous souhaitez faire. Si certaines des mises à jour dépendent directement du processus d'installation (c'est-à-dire le noyau, python, kudzu), vous devrez utiliser la procédure de reconstruction de l'installateur expliquée dans le document Construire un CDROM Red Hat Linux 6.2, sinon vous pouvez toujours utiliser l'ancienne procédure (celle pour les versions précédentes jusqu'à la 6.1 comprise, expliquée dans la section précédente). Les deux dernières étapes, qui sont la création de l'image iso et la gravure du media, sont décrites respectivement dans créer des images iso et graver le CD.

5.3.3. RedHat 9, 8.0 et 7.3

Une fois encore, beaucoup de choses ont été changées avec la sortie des séries 7.x de la distribution. Il y a maintenant plus d'opérations à réaliser pour obtenir une série de CD frais et mis à jour. En réalité, le CD a cessé d'être unique avec la version 7.0 et maintenant l'arbre doit être divisé pour tenir sur le média. Ceci est fait en utilisant le script splitdistro, qui est écrit en python comme beaucoup d'éléments de l'installateur anaconda. Pour terminer cette partie, vous devez utiliser une machine Linux RedHat 7.3, 8.0 ou 9 avec le paquet anaconda-runtime installé (il aura probablement la version 7.3.7, 8.0.4 ou 9.0.4), en fonction de la version que vous voulez reconstruire. La procédure est composée de sept étapes :

  1. Regénérer les fichiers hdlist et hdlist2

  2. Mettre à jour le fichier comps.xml (ou comps)

  3. Reconstruire l'installateur

  4. Diviser la distribution en plusieurs parties de la taille d'un CD

  5. Regénérer (encore) les fichiers hdlist et hdlist2

  6. Générer les images iso

  7. Ajouter et vérifier les signatures md5 dans les images iso

Toutes les étapes sont regroupées dans un seul script présenté dans la dernière section.

5.3.3.1. Opérations préliminaires sur l'arbre principal

Quelques uns des scripts inclus dans le paquet anaconda-runtime ont besoin de l'arbre principal qui doit être déplacé dans un sous-répertoire nommé comme l'architecture que nous allons construire (donc i386/ pour moi). Nous déplacerons tout vers un tel répertoire avant de lancer la procédure et de modifier l'invocation des scripts qui n'ont pas besoin de cette modification.

Pour la RedHat 9 et 8.0 :

$ chmod  -R  u+w  /chemin-abs-de-la-racine
$ mkdir  -p  /chemin-abs-de-la-racine/i386
$ cd  /chemin-abs-de-la-racine
$ /bin/mv  *  i386

Vous devez changer « /chemin-abs-de-la-racine » avec le chemin absolu du répertoire où la racine de votre copie locale de la distribution est placée (peut-être quelque part sur un disque dur). Vous obtiendrez une erreur, à partir de l'exécution de la dernière commande, parce que le répertoire i386/ ne peut être déplacé sous lui-même, mais vous n'avez pas besoin de vous en soucier.

Pour RedHat 7.3 :

$ chmod  -R  u+w  /chemin-abs-de-la-racine
$ mkdir  -p  /chemin-abs-de-la-racine/i386
$ cd /chemin-abs-de-la-racine
$ for i in `ls` ; do [ $i != "SRPMS" -a $i != i386 ] && \
  /bin/mv $i i386 ; done

Vous ne devriez recevoir aucun message d'erreur cette fois, après la dernière commande (avec un peu d'espoir).

5.3.3.2. Regénérer les fichiers hdlist et hdlist2

Ceci est fait au moyen des deux commandes suivantes et avec l'aide du programme genhdlist.

$ /usr/lib/anaconda-runtime/genhdlist /chemin-abs-de-la-racine/i386
$ chmod  644 /chemin-abs-de-la-racine/i386/RedHat/base/hdlist{,2}

Une fois encore, « /chemin-abs-de-la-racine » est le chemin absolu de ce répertoire où la racine de votre copie locale de la distribution est placée. La seconde commande est nécessaire pour vous assurer que les droits sont corrects pour ce fichier. Vous devez déjà avoir une idée de ce que sont ces fichiers si vous avez lu le répertoire RedHat.

5.3.3.3. Mettre à jour le fichier comps.xml

Dans RedHat Linux 8.0, le format du fichier comps a complètement changé et il est maintenant basé sur XML. Il apporte beaucoup plus de flexibilité et de facilité de personnalisation comme vous pouvez le lire dans le fichier comps. Si vous avez modifié ou si vous souhaitez modifier la liste des paquets installés, vous avez besoin de terminer cette étape. Cela implique en retour d'avoir la version modifiée de comps-9.tar.gz (l'original ne fonctionne pas pour moi) ou comps-8.0.tar.gz (suivant la version que vous construisez) qui contient le fichier maître comps trouvé sur le site web de RedHat et le paquet rpm comps-extras. Suivez alors ces étapes pour la Redhat 9 et 8.0 :

$ cd /répertoire-de-votre-choix
$ tar xzvf /chemin-vers-comps-9.tar.gz/comps-9.tar.gz 
$ cd comps
$ make
$ cat comps-milan.xml |sed 's!</comps>!!g' >comps-tmp.xml
$ /usr/share/comps-extras/getfullcomps.py  comps.xml \
   /chemin-abs-de-la-racine i386 >> comps-tmp.xml
$ echo '</comps>' >> comps-tmp.xml
$ cp comps-tmp.xml /chemin-abs-de-la-racine/i386/RedHat/base/comps.xml

Avec « /chemin-abs-de-la-racine », vous devez prendre soin d'assigner les noms valides vers « /répertoire-de-votre-choix » et « /chemin-vers-comps-9.tar.gz ». Le reste des commandes peut simplement être copié. Et vous devez évidemment changer 9 en 8.0 si vous construisez une version 8.0.

De nouveau, avant de lancer la commande make, vous devez modifier le fichier comps-milan.xml.in en utilisant votre éditeur de texte favori et en suivant les lignes de conduite et les suggestions trouvées dans le fichier comps et dans la section anaconda comps du site web RedHat.

Le script présenté dans la dernière section exécutera toutes les étapes nécessaires après la commande make, en utilisant la variable COMPSFILE, pour trouver le fichier comps-milan.xml (il n'a pas besoin d'avoir ce nom, j'utilise juste le nom original, mais vous pouvez le changer si vous le voulez).

Si vous utilisez RedHat 7.3, le fichier comps (avez-vous noté la différence de nom ?) est un fichier textuel avec une syntaxe complètement différente décrite avec plus de détails dans le fichier comps. Dans ce cas, les seules opérations nécessaires concernent la modification du fichier pour coller à vos besoins et la copie du fichier RedHat/base/comps dans l'arbre principal écrasant l'original.

5.3.3.4. Reconstruire l'installateur

Ceci reconstruira l'installateur anaconda dans votre copie locale de la distribution en utilisant les paquets mis à jour. Pour la Redhat 9, lancez :

$ /usr/lib/anaconda-runtime/buildinstall  \
  --pkgorder /chemin-abs-de-la-racine/pkgorder.txt  \
  --comp dist-9 --product "Red Hat Linux" --version 9  \
  --release "Redhat 9 (Shrike)" /chemin-abs-de-la-racine/i386

Où, une fois encore, « /chemin-abs-de-la-racine » est le répertoire où la racine de votre copie locale de la distribution est placée.

Pour la Redhat 8.0, la procédure est pratiquement identique (il manque l'option « --product ») :

$ /usr/lib/anaconda-runtime/buildinstall  \
  --pkgorder /chemin-abs-de-la-racine/pkgorder.txt  \
  --comp dist-8.0 --version 8.0  --release "Redhat 8.0 (Psyche)" \
  /chemin-abs-de-la-racine/i386  

Ou si, comme moi, vous utilisez toujours une Redhat 7.3 :

$ /usr/lib/anaconda-runtime/buildinstall  \
   --pkgorder /chemin-abs-de-la-racine/pkgorder.txt  \
   --comp dist-7.3 --version 7.3 /chemin-abs-de-la-racine/i386  

L'absence de l'option (obligatoire pour la 8.0) --release est la seule différence notable.

5.3.3.5. Diviser la distribution

Ceci créera cinq répertoires, chacun correspondant à un CD différent, et y placera des liens physiques vers les fichiers réels contenus dans votre copie locale de la distribution.

[Note]Note

Ceci ne fonctionnera pas du tout pour la RedHat 7.3 si vous n'utilisez pas la version modifiée du script splitdistro rapporté dans le prochain paragraphe. Pour la RedHat 8.0 et la 9, une version modifiée de splitdistro est proposée principalement parce que, même si les problèmes du script précédent ont été corrigés, l'exécution échouait toujours s'il n'existait pas suffisament de paquets pour remplir tous les CD (les quatre premiers complètement et le dernier juste partiellement).

$ /usr/lib/anaconda-runtime/splitdistro  \
  --fileorder /chemin-abs-de-la-racine/pkgorder.txt  --release \
  "Redhat 9.0 (Shrike)"  /chemin-abs-de-la-racine  i386 

La seule chose que vous avez besoin de changer pour la 8.0 et la 7.3 est la phrase passée à l'option --release (qui doit être « Redhat 8.0 (Psyche) » ou « Redhat 7.3 (Valhalla) »).

Pour la Redhat 7.3, la version utilisée du script (python) splitdistro7.3 était extraite du paquet anaconda-runtime 7.3.7 et modifiée par moi. Vous pouvez le substituer à l'original (peut-être après avoir sauvegardé ce dernier) nommé /usr/lib/anaconda-runtime/splitdistro.

La seule modification (en dehors de quelques petites corrections) que le script a subie est un changement dans son comportement si le répertoire SRPMS n'est pas trouvé (il ne se termine pas, mais génère les CD sans les paquets source).

Pour la Redhat 8.0, la version utilisée du script (python) splitdistro8.0 a été extraite du paquet anaconda-runtime 8.0.4 et modifiée une fois encore par moi pour obtenir certaines améliorations dont je ressentais le besoin. Vous devez y substituer le fichier original (peut-être après avoir sauvegardé ce dernier) nommé /usr/lib/anaconda-runtime/splitdistro. Néanmoins, l'original fonctionne bien, si vous voulez construire une distribution qui a tous les paquets SRPMS (donc pour remplir les cinq CD, sinon le script échouera).

La seule modification apportée au script est un changement dans son comportement si le répertoire SRPMS n'est pas trouvé (il ne se termine pas en échouant, mais génère les CD sans les paquets source) ou s'il y a un CD qui n'a aucun paquet (au lieu d'échouer, le script génère un répertoire vide).

Pour la Redhat 9, vous pouvez trouver une copie du script avec les mêmes modifications appliquées à la version incluse dans la version 8.0 ici : splitdistro9. Tout ce qui a été dit dans le paragraphe précédent pour la Redhat 8.0 s'applique à la version 9.

5.3.3.6. Regénérer les fichiers hdlist et hdlist2

Il est nécessaire de recréer les fichiers hdlist et hdlist2, en utilisant quelques unes des informations obtenues dans les étapes précédentes. Il n'y a pas de différences entre 7.3, 8.0 et 9 pour l'exécution du programme. La commande à envoyer est la suivante:

$ /usr/lib/anaconda-runtime/genhdlist  \
  --fileorder /chemin-abs-de-la-racine/pkgorder.txt  --withnumbers \
  /chemin-abs-de-la-racine/i386-disc[1-3]

Comme vous pouvez le voir, il y a deux nouvelles options passées au programme, si vous vous rappellez le premier lancement. Le premier, --fileorder, indique à genhdlist d'utiliser le fichier pkgorder.txt que nous avons généré lors de la seconde étape (reconstruire l'installateur). Ce fichier garde les informations sur la division des paquets sur les différents CD, et est utilisé par l'installateur pour déterminer dans quel ordre les paquets doivent être installés. De manière simple, si vous ne l'utilisez pas, vous finirez probablement en échangeant les différents CD plusieurs fois durant l'installation. L'option --withnumbers est nécessaire pour associer un numéro de CD à chaque paquet (comme vous le voyez, une expression régulière indiquant les trois premières images iso est utilisée).

5.3.3.7. Générer les images iso

Ici, vous préparez les images iso à graver sur les CD actuels. Il y a deux commandes différentes à utiliser pour le premier disque et pour le reste. Ceci est dû au besoin d'obtenir un premier CD qui soit amorçable. Ce n'est pas strictement nécessaire parce que vous pouvez utiliser une disquette de démarrage à la place mais il s'agit d'une fonctionnalité intéressante (et elle rend le comportement de vos disques plus similaire aux originaux). Il existe des commandes que j'utilise pour terminer la tâche :

$ mkdir /repertoire-destination-images
$ mkisofs  -r  -J  -T  -v  -V "Red Hat 9 (Shrike) disc 1" \
   -c isolinux/boot.cat  -b isolinux/isolinux.bin -no-emul-boot \
   -boot-load-size 4 -boot-info-table \
   -o /repertoire-destination-images/i386-disc1.iso .

Cela est nécessaire pour graver le premier disque (amorçable) pour la RedHat 8.0 et 9 (sans émulation de disquette) et c'est exécuté à partir du répertoire haut-niveau de la distribution. Le répertoire /repertoire-destination-images est le contenant pour les cinq images iso que vous avez générées et il doit exister avant de lancer la procédure. La seule modification à effectuer pour Redhat 8 est le nom du volume, qui devrait être « Red Hat 8.0 (Psyche) disc 1 ».

$ mkdir /repertoire-destination-images
$ mkisofs  -r  -J  -T  -v  -V "Red Hat 7.3 (Valhalla) disc 1" \
   -c boot.cat  -b dosutils/autoboot/boot.img \
   -o /repertoire-destination-images/i386-disc1.iso .

Il est nécessaire de graver le premier disque (amorçable) sur la 7.3 et de l'exécuter à partir du répertoire haut-niveau de la distribution (cette fois avec une émulation de disquette).

Le reste des images peut être écrit au moyen d'une boucle « for » :

$ for i in `echo 2 3 4 5` ; do mkisofs  -r  -J  -T  -v  \
   -V "Red Hat 9 (Shrike) disc ${i}"  \
   -o /repertoire-destination-images/i386-disc${i}.iso . ; done

La boucle présentée va préparer les quatre dernières images en leur donnant les bons numéros. Comme vous pouvez le voir, il y a deux options manquantes à partir du premier lancement, et, comme vous pouvez le deviner, elles sont nécessaires uniquement pour créer un CD amorçable. Dans créer des images iso, vous pouvez lire une brève explication sur les différentes options et leur significations (la plupart ont été extraites des pages man). De nouveau, si vous construisez une Redhat 8.0, vous devriez changer le nom du volume par « Red Hat 8.0 (Psyche) disc1 ».

5.3.3.8. Implanter et vérifier les signatures md5 dans les images iso

C'est une étape optionnelle mais elle permet l'utilisation de l'option « checkmedia » pour vérifier les signatures des CD avant de les installer, et donc de garantir leur intégrité.

Les commandes suivantes permettent d'injecter ou de vérifier une signature md5 sur une image iso :

$ /usr/lib/anaconda-runtime/implantisomd5 image-iso
$ /usr/lib/anaconda-runtime/checkisomd5 image-iso

Après avoir fini toutes ces étapes, nous aurons les cinq images CD à graver. Considérant que taper tout ceci prend du temps, dans la prochaine section sera présenté un script qui réalisera toutes les opérations listées en une seule fois (n'oubliez pas de configurer les paramètres proprement).

5.3.3.9. Réunir toutes les étapes

Le script updateBuild.sh exécutera toutes les étapes nécessaires pour reconstruire les CD de distribution pour la RedHat 7.3, 8.0 et 9 en un seul lancement (réalisé en tant que root). Avant d'utiliser ce script, vous devez configurer le fichier rhcd.conf après l'exportation d'une variable RHCDPATH pointant vers le répertoire où se trouve ce fichier. Si vous voulez inclure le fichier comps.xml modifié (ou comps) dans vos CD comme expliqué dans le fichier comps, vous devrez le copier à l'emplacement défini au moyen de la variable COMPSFILE maintenant (avant d'exécuter le script). N'oubliez pas d'ajouter le script modifié splitdistro dans le répertoire /usr/lib/anaconda-runtime si vous en avez besoin.

# export RHCDPATH=/home/luigi/tmp/rhcd-scripts
# sh updateBuild.sh

6. Graver le ou les CD

Cette étape est composée d'une partie optionnelle et d'une partie obligatoire. Rappellez-vous que vous avez probablement besoin d'être « root » sur votre machine pour lancer cdrecord.

6.1. Essayer l'image ou les images

Si vous êtes paranoïaque, vous pouvez tester votre nouvelle image disque en la montant. Si vous oubliez de corriger les permissions des fichiers ou de mettre en place les extensions rock ridge, alors l'erreur sera évidente puisque les noms de fichier et la structure des répertoires seront erronés. Le test (optionnel) peut être réalisé en tapant la commande suivante :

 
# mount -t iso9660 -o ro,loop=/dev/loop0 image-iso /mnt/cdrom

Où « image-iso » est le nom que vous avez donné à l'image iso à monter (qui doit être seule pour les versions supérieures ou égales à la 6.2). Quand vous avez terminé, n'oubliez pas de la démonter.

# umount /mnt/cdrom

6.2. Graver le ou des disques

Assurez-vous que vous avez mis en place les bons paramètres pour votre périphérique. Par exemple, cette commande est pour un graveur 4x, ce qui est assez lent. De plus, il est vérifié que le graveur CD est ici sur le bus SCSI numéro 0, avec l'ID 0, LUN 0 (vous pouvez obtenir ces valeurs en lançant un cdrecord -scanbus et en les assignant au paramètre -dev=).

# cdrecord -v speed=4 dev=0,0,0 /repertoire-destination-images/disc1.img

7. Le fichier comps

Le fichier comps définit comment les paquets seront assemblés durant l'installation. Dans la distribution RedHat, ceci est fait selon la fonctionnalité qu'ils procurent, par exemple :

  • Support Imprimantes

  • Système X Window

  • GNOME

  • KDE

  • Outils Mail/WWW/News

  • Développement du Noyau

  • Documentation Supplémentaire

Quelquefois durant le processus d'installation, l'utilisateur se trouve face à une fenêtre appelée « Composants à installer ». Quelques-uns des composants ont été présélectionnés, d'autres non. Le dernier point sur la liste des composants est appelé « Tout ». Sur la fenêtre, il existe aussi une option qui permet à l'utilisateur de personnaliser très précisément la liste des paquets qui seront installés. Personnaliser l'installation à la main, ou sélectionner « Tout » dans la liste des composants est le seul moyen d'avoir vos propres paquets installés, sauf si vous modifiez le fichier RedHat/base/comps.

7.1. Format du fichier comps pour RedHat versions < 6.1

Le fichier comps commence avec un en-tête décrivant la version du format comps, suivie d'une ligne vide.

0.1
<empty line>

Après ceci, les composants sont listés, séparés par des lignes vides :

<composant 1>
<ligne vide>
<composant 2>
<ligne vide>
...
<composant n>
<ligne vide>
EOF

Chaque composant a la définition suivante :

(0|1) (--hide)? <name>
<RPM 1>
<RPM 2>
...
<RPM n>
end

Avant le nom de chaque composant est placé un 0 ou un 1. Une valeur de 1 à cet endroit veut dire que le composant est choisi par défaut alors qu'un 0 dit le contraire. L'option --hide veut dire que vous ne pouvez pas voir l'entrée, sauf si vous choisissez l'installation « en mode expert ». Le premier composant est appelé « Base », et il est spécial, dans le sens où il doit être présent et qu'il n'apparait pas dans le dialogue (vous ne pouvez pas désélectionner l'installation de la base, ce qui est sensé). Suit une liste de paquets RPM appartenant à ce composant. Notez qu'il s'agit du nom du paquet stocké dans le fichier rpm, et non pas d'une partie du nom du fichier du paquet (bien qu'il doive être identique par convention).

En ajoutant vos paquets au fichier comps, vous pouvez personnaliser votre propre distribution et vous assurer que vos paquets seront installés par défaut. Une chose à laquelle vous devez porter attention est l'interdépendance entre vos paquets, mais ici c'est à vous de jouer :-) Un mot pour vous prévenir : faites attention de ne pas ajouter ou supprimer ces espaces blancs supplémentaires dans le fichier. Examinez le fichier comps existant (faites une copie de l'original) pour voir comment il est fait (ou vérifiez i386/misc/src/install/pkgs.c si vous voulez voir comment le fichier est analysé).

7.2. Format du fichier comps pour RedHat version 6.1

Avec RedHat version 6.1, le format du fichier comps a changé. Le décodage s'effectue dans ${RHROOT}/${ARCH}/misc/src/anaconda/comps.py. Je n'ai pas encore analysé ce script python et les règles suivantes ont été obtenues seulement en lisant le fichier comps et en testant quelques configurations.

Dans la version 6.1, la définition du composant est étendue pour inclure quelques éléments optionnels supplémentaires avant les <RPM>. Ces élements sont:

<RPM-dépendant-de-architecture 1>
...
<RPM-dépendant-de-architecture n>
<composant-requis 1>
...
<composant-requis n>
<RPM-composant-dépendant 1> 
...
<RPM-composant-dépendant n>

Un <RPM-dépendant-de-architecture> définit une dépendance entre un paquet et une architecture spécifique et a la définition suivante:

(!)?arch: <RPM>

Donc, il peut, par exemple, se présenter dans le monde réel comme :

!alpha: kernelcfg

ce qui veut dire : si l'architecture n'est pas alpha alors il faut installer le paquet kernelcfg.

Ou comme :

i386: mkbootdisk

Ce qui veut dire : si l'architecture est i386 alors il faut installer le paquet mkbootdisk.

Un <composant-requis> renforce la dépendance avec un autre composant et il est défini comme :

@ <component>

Donc, par exemple, si à l'intérieur de la définition d'un composant, vous trouvez la ligne suivante :

@ Station Réseau

cela veut dire que le composant lui-même a besoin de l'installation d'un autre composant nommé Station Réseau.

Un <RPM-composant-dépendant> est utilisé pour sélectionner l'installation de quelques paquets additionnels pour un composant, étant donné la présence d'un autre composant. Sa définition est la suivante :

? <composant> { 
  <RPM 1>
  ...
  <RPM n>
}

Donc si, par exemple, dans la définition d'un composant, il vous arrive de lire les lignes suivantes :

? KDE { 
  kpppload
}

alors si le composant KDE est installé, le paquet kpppload sera installé avec les paquets inclus dans le composant où la définition se trouve.

7.3. Format du fichier comps dans RedHat version 6.2

Avec RedHat version 6.2, le format du fichier comps a apparemment un peu changé. Le décodage se fait aussi dans ${RHROOT}/${ARCH}/misc/src/anaconda/comps.py. Encore une fois, je n'ai pas analysé ce script python et les règles suivantes ont été obtenues seulement en lisant le fichier et en testant quelques configurations.

Dans la version 6.2, la définition du composant est étendue pour inclure deux éléments optionnels supplémentaires :

<RPM-dépendant-language 1>
...
<RPM-dépendant-language n>
<composant-dépendant-architecture 1>
...
<composant-dépendant-architecture n>

Un <RPM-dépendant-language> est nécessaire pour spécifier l'installation d'un paquet au cas où une langue spécifique a été sélectionnée. C'est défini ainsi :

(lang <language>): <RPM>

Par exemple, la ligne suivante

(lang ja_JP)): locale-ja

veut dire : si la langue japonaise est sélectionnée, alors il faut installer le paquet locale-ja avec les autres paquets installés pour ce composant.

Un <composant-dépendant-architecture> étend le concept du <RPM-dépendant-architecture>, introduit lors de la version 6.1, au composant entier, comme vous pouvez le comprendre à la lecture de sa définition :

(!)?arch: <component>

7.4. Format d'un fichier comps dans la RedHat version 7.3

Avec la RedHat version 7.3, le format du fichier comps a gagné en syntaxe. Le décodage prend place (encore) dans le script comps.py, que vous pouvez maintenant trouver dans le répertoire /usr/lib/anaconda/ si vous avez installé le paquet anaconda. Les dépendances sur une langue ou sur une architecture pour un composant ou un paquet peuvent maintenant être liées avec l'opérateur and. Par exemple :

(arch !s390 and arch !s390x and arch !ia64): readline2.2.1

ce qui veut dire que si l'architecture n'est ni s390, ni s390x, ni ia64, alors il faut installer le paquet readline2.2.1. Ceci peut être fait avec des composants au lieu des paquets, et avec des langues à la place des architectures. Tout ceci est définitivement plus qu'assez pour les simples exemples de personnalisation de l'installation par défaut qui seront présentés dans la prochaine section.

7.4.1. Personnaliser l'installation par défaut de la RedHat version 7.3

L'exemple que nous allons parcourir dans cette section implique des modifications dans le fichier comps pour changer les valeurs par défaut qui concernent l'installation des paquets. Je préfère habituellement, particulièrement dans certaines situations, une installation par défaut incluant seulement les paquets de base, avec quelques légères modifications pour certains d'entre eux. Dans le premier des exemples présentés, nous construirons une installation par défaut qui ajoute libsafe au composant « Base », dont la plupart des paquets, qui sont généralement installés par défaut, sont désélectionnés dans le but de construire une installation minimale. Dans le second des exemples, nous modifierons quelques-uns des composants pour construire une autre installation minimale qui remplit nos besoins (cette fois, pratiquement parfaitement ; ce sont, en fait, mes besoins, les vôtres peuvent varier). Si vous voulez inclure un fichier comps modifié dans vos CD, vous devez le copier dans l'arbre principal juste avant de lancer les opérations décrites dans reconstruire l'installateur 7.3 ou 8.0.

7.4.1.1. Ajouter des RPMS et désélectionner les composants par défaut

Pour personnaliser votre installation de cette façon, vous devez éditer le fichier comps avec votre éditeur de texte favori (faites attention à ne pas laisser d'espaces ou de tabulations dans ce fichier) et le déplacer dans le répertoire Redhat/base en écrasant l'original.

Dans le premier fichier comps inclus, le paquet libsafe était ajouté dans le composant « Base system » et presque tous les composants étaient désélectionnés pour obtenir une installation par défaut comportant seulement 200 paquets (je sais qu'ils sont encore trop nombreux).

7.4.1.2. Modifier quelques-uns des composants standards

Nous construisons le deuxième fichier comps ci-joint à partir de l'étape précédente, pour réduire un peu plus l'installation par défaut (cette fois, il n'y aura plus que 154 paquets dans l'installation par défaut). Quelques-uns des groupes ont été divisé pour donner à l'installation plus de granularité. Toutes les modifications que vous faites doivent prendre en compte les interdépendances entre paquets et les applications utilisées durant les phases d'installation (vous ne pouvez pas supprimer kudzu, par exemple, du composant Base, même si vous pouvez le faire après installation). Il doit être dit que des résultats similaires peuvent être obtenus en utilisant kickstart. Pour plus d'informations à ce propos, vous pouvez lire le Guide de Personnalisation du Linux RedHat.

7.5. Format du fichier comps à partir de RedHat version 8.0 et 9

Avec la RedHat version 8.0 et 9, le format du fichier comps a été complètement changé et on utilise maintenant un fichier XML, nommé comps.xml. Les détails sur la syntaxe du fichier peuvent être trouvés dans la section anaconda comps du site web de RedHat.

7.5.1.  Personnaliser l'installation par défaut de la RedHat version 8.0

Nous reproduirons maintenant les exemples présentés pour la version 7.3 en prenant en compte les modifications appliquées aux différents groupes. Le groupe le plus important (le groupe « Base », divisé ici en deux groupes nommés « Base » et « Core ») doit représenter l'installation minimale.

7.5.1.1. Notre premier exemple revisité pour Redhat 8.0

Cette fois, pour personnaliser votre installation, vous devez éditer le fichier comps-milan.xml.in avec votre éditeur de texte favori. Le fichier peut être trouvé dans l'archive comps-8.0.tar.gz sur le site web de RedHat. Pour ajouter les informations de paquets au fichier que vous venez de créer, vous avez besoin d'avoir installé le paquet rpm comps-extras. Les commandes à lancer pour terminer les opérations sont listées dans mettre à jour comps.xml et dans la documentation. Après avoir créé le fichier, vous devez le copier dans le répertoire Redhat/base en écrasant l'original. Si vous utilisez le script updateBuild.sh, vous devez seulement copier comps-milan.xml (après avoir modifié comps-milan.xml.in qui se trouve dans le paquet tar/gzip comps-8.0.tar.gz et lancé la commande make), à l'emplacement que vous avez déjà configuré dans la variable COMPSFILE (dans rhcd.conf).

Dans le premier fichier comps ci-joint, le paquet libsafe a été ajouté au groupe (composant) « Base » et pratiquement tous les groupes (composants) ont été désélectionnés, sauf « Base » et « Core », pour avoir une installation par défaut de seulement 220 paquets environ (probablement trop nombreux, encore une fois).

7.5.1.2. Notre deuxième exemple revisité pour Redhat 8.0

Nous construisons le deuxième fichier comps ci-joint sur la précédente configuration et réduisons un peu plus l'installation par défaut (cette fois, il restera seulement 158 paquets de l'installation par défaut). Encore une fois, des résultats similaires peuvent être obtenus en utilisant kickstart, pour plus d'informations à ce propos, vous pouvez lire le Guide de Personnalisation de la RedHat Linux. Dans cet exemple, je n'ai pas désélectionné complètement l'installation du groupe « Base », parce qu'il y a trop de paquets que j'utilise, donc j'ai juste désélectionné l'installation par défaut pour ces paquets en les rendant optionnels. Comme vous pouvez le voir, même le paquet redhat-logos du groupe « Core » a été rendu optionnel. En considérant que les paquets présents dans ce groupe doivent représenter la plus petite installation possible, vous ne voudrez probablement pas le faire (de plus, mes CD fonctionnent même ainsi ; il doit exister quelques problèmes que je n'ai pas encore détectés). Le paquet tripwire a aussi été ajouté au groupe « Base ». La dernière modification visible a été faite au groupe « dialup », qui sera installé même s'il est désélectionné, parce que le groupe « Base » en dépend (ce qui est indiqué dans la définition du groupe lui-même). J'ai seulement sélectionné certains paquets dont j'ai habituellement besoin à partir de ce groupe pour l'installation et laissé le reste désélectionné.

7.5.2.  Personnaliser l'installation par défaut de la RedHat version 9

Nous allons de nouveau reproduire les exemples présentés pour les versions 7.3 et 8 en prenant en compte les modifications qu'ont subies les différents groupes.

7.5.2.1. Notre premier exemple revisité pour la Redhat 9

Comme dans le cas de la 8.0, pour personnaliser votre installation, vous devez éditer le fichier comps-milan.xml.in avec votre éditeur de texte favori. Ce fichier est disponible dans le fichier comps-9.tar.gz parmi les scripts (comme je l'ai déjà dit, vous ne trouverez pas la même chose sur le site web de Redhat). Pour ajouter les informations des paquets pour les fichiers que vous avez créés, vous avez besoin de disposer du paquet rpm comps-extras pour continuer les opérations listées dans mettre à jour comps.xml et dans la documentation. Après avoir créé le fichier, vous devez le copier dans le répertoire Redhat/base en écrasant l'original. Si vous utilisez le script updateBuild.sh, vous devez seulement copier comps-milan.xml, (après avoir modifié comps-milan.xml.in trouvé dans le paquet tar/gzip comps-9.tar.gz et avoir lancé la commande make), vers la destination que vous avez déjà configurée dans la variable COMPSFILE (rhcd.conf).

Dans le premier fichier comps inclus, le paquet libsafe a été ajouté par le groupe « Base » (composant) et pratiquement chaque groupe (composant) était désélectionné, mis à part « Base » et « Core », de façon à avoir une installation par défaut comprenant seulement ~240 paquets (hummm, la complexité augmente…).

7.5.2.2. Notre second exemple revisité pour Redhat 9

Dans le second fichier comps inclus, nous construisons à partir de l'installeur précédent et supprimons un peu plus d'éléments de l'installation par défaut (cette fois, il n'y aura que ~175 paquets dans l'installation par défaut). Cela ressemble beaucoup à l'exemple présenté pour la Redhat 8.0, donc je vais éviter de vous ennuyer avec les mêmes explications. Encore une fois, des résultats identiques sont obtenus en utilisant kickstart. Plus d'informations sur cela en lisant le Guide de personnalisation du Linux RedHat.

8. Installer à partir du CD

Lors de l'installation à partir du nouveau CD, vous pourriez avoir tout d'abord besoin de créer une disquette d'installation amorçable. IMPORTANT : utilisez une NOUVELLE disquette, tout juste formatée MS-DOS !. Utiliser une vieille disquette peut provoquer des problèmes étranges lors de l'installation ! Sur un système Linux, vous pouvez créer la disquette en utilisant la commande dd :

$ dd if=/mnt/cdrom/images/boot.img of=/dev/fd0 bs=1440k 

Sur un système tournant sous DOS ou Windows-9x, vous avez besoin d'utiliser le programme rawrite.exe, disponible dans le répertoire dosutils du CD. Sur une machine sous Windows-9x/Me/NT/2k, vous pouvez utiliser rawritewin.exe situé dans le répertoire dosutils/rawritewin.

Arrêtez la machine sur laquelle vous voulez l'installer (ou faire une mise à jour du système), insérez la disquette de démarrage et votre CD tout juste gravé, et laissez la machine démarrer à partir de la disquette. Pour plus d'informations sur le processus d'installation, voir les documents ainsi que le guide pratique Installation ou le guide pratique Bootdisk.

8.1. Démarrer d'un CD amorçable

La plupart des machines modernes sont capables de démarrer à partir d'un CD, à condition qu'il soit rendu amorçable avec la procédure indiquée dans la section créer des images iso. Souvent, néanmoins, vous avez besoin de changer le paramétrage du BIOS pour permettre le démarrage à partir du lecteur de CD. Référez-vous à la documentation de votre carte-mère pour savoir comment le faire.

9. Autres distributions Linux

Les informations présentes dans les précédentes versions de ce howto (≤1.34), et reprises dans ce présent document, s'appliquant aux versions jusqu'à la 6.1 du Linux RedHat comprise, sont supposées s'appliquer à toutes les distributions clones de RedHat, telle que la distribution Mandrake. Malgré tout, la procédure est reportée comme non testée (comme vous pouvez le lire dans le howto lui-même).

Des considérations similaires s'appliquent à la distribution LinuxPPC pour Apple PowerMacs. Pour créer une distribution pour la plateforme PowerMac, vous avez besoin d'utiliser mkhybrid au lieu de mkisofs et ce doit être la seule différence.

Les informations apportées pour les nouvelles versions de RedHat (>6.1) ne doivent pas fonctionner avec Mandrake, qui a maintenant un installateur vraiment différent de celui de RedHat. Je ne sais vraiment pas si d'autres clones de RedHat peuvent avoir leur distribution CD mise à jour de cette façon, mais je serais heureux que vous me le disiez.

10. Ce document…

Le source SGML de la plus récente version de ce document peut être trouvée à partir d'ici.

10.1. Documents en rapport

10.1.1. Documentation en rapport avec la version actuelle

Les documents suivants ont été utiles pour la création de ce guide pratique :

Le mini guide (non officiel) sur l'installateur personnalisé de la RedHat 7, par Tony Nugent. Ce document est très intéressant et utile. Donc, si vous pensez sérieusement construire des CD personnalisés, je vous suggère fortement de le lire. Vous le trouverez sur www.linuxworks.com.au

Miguel Freitas a écrit le mini-HOWTO CD RedHat7, que vous pouvez lire sur ce site web.

Ron Yorston a écrit le document rpmhack, intéressant pour la version 6.2 du Linux RedHat.

Quelqu'un (je n'ai pas trouvé son nom) a écrit le document Construire un CDROM Red Hat Linux 6.2, utile pour la version 6.2.

10.1.2. Documentation en rapport à l'édition précédente

Avec le sens des bonnes choses dans la vie, Jussi Torhonen de Finland nous dit comment créer un CD-ROM RedHat Linux 5.2 amorçable fait-à-la-maison.

À partir du LDP, voir le guide pratique de la gravure de CD.

10.2. Remerciements

À part ceux mentionnés ci-dessus, je remercie les personnes suivantes pour les informations de valeur, les retours d'informations, discussions et autres :

10.2.1. Remerciement pour la version actuelle

11. Adaptation française

11.1. Traduction

La traduction française de ce document a été réalisée par Guillaume Lelarge .

11.2. Relecture

La relecture de ce document a été réalisée par Guillaume Hatt .



[1] « Paquetages » est le terme utilisé par RedHat pour parler des « paquets », c'est-à-dire des formats d'archive utilisés pour distribuer des applications et incluant tout ce qui est nécessaire à l'installation, à la désinstallation et au fonctionnement de cette application.