Forums d'entraide informatique - Astuces - Conseils

LE NOYAU LINUX ET DEBIAN
on trouve les différentes versions du noyau auxquelles il peut s'appliquer. Si nous prenons le cas de kernel - patch- bootspl ash,on retrouve une variable KVERSIONS dans le fichier /usr/src/kernel -patches/a11/apply/bootspl ash qui ne spécifie aucune version au-delà de 2.6. I 6.En fonction de la version du noyau compilé, c'est l'un des patchs présents dans /usr/src/kernel -patches/diffs/bootsplash qui sera appliqué.
NOTE
Bien que cela ne soit pas recommandé, il est parfois possible de forcer l'application d'un patch pour une version non prévue du noyau. L'utilitaire patch permet en effet une certaine tolérance (ce qui n'est pas le cas du code lui-même). En modifiant le contenu du fichier dans Kernel -patches/al 1 /apply/ on peut donc «forcer» l'application d'un patch en trompant le test et en ajoutant soi-même la nouvelle version. Une solution plus propre est, bien entendu, de générer un nouveau fichier .diff, de le tester et de le proposer au responsable du paquet.
A ce point de l'article, l'installation d'un patch est relativement simple.II suffit, en effet, d'installer le paquet correspondant, comme kerne] -patch-bootspl ash. Automatiquement une nouvelle arborescence /usr/src/kernel -patches est créée et peuplée.A l'instar des modules, l'ensemble des patchs sont installés dans cet unique répertoire. En revanche, il ne sont pas appliqués automatiquement mais doivent être clairement spécifiés dans la ligne de commande de ma ke- kpkg.Ainsi pour notre exemple, nous utilisons
# make-kpkg clean    make-kpkg \
--append-to-versionz-hs28-1-k7 \ --added-patches bootsplash \ --initrd kernel_image
Nous constatons parmi les différentes étapes de la construction, l'application correcte du patch
START applying bootsplash patch (Bootsplash)
Testing whether "Bootsplash" patch for 2.6.15 applies (dry run): "Bootsplash" patch for 2.6.15 succeeded
Removing empty files:
Done.
Le message dépend du patch,tous ne sont pas aussi explicites quant à leur application. Notez que si vous appliquez plusieurs patchs, il faut les lister tous en argument de - - added-patches séparés par des virgules. Le ou les patchs sont appliqués lors de la phase de configuration des sources, il sont «désappliqués» (unpatch) lors d'un make-kpkg cl ean.
Certains patchs appliquent simplement ces changements dans le code, mais également dans la configuration. Dans le cas de kernel -patch -debi anlogo par exemple, le fichier de configuration du noyau est également changé. La configuration des sources ayant lieu après l'application du patch, le changement est détecté (comme avec un oldconfi g) et le système demande votre intervention
[...]
Standard 224-color Linux logo (L000_LINUX_CLUT224) [Yin] y Debian GNU/Linux Open Use logo (LOGO_LINUX_DEBIAN) [Y/n]
(NEW)
Les problèmes surviennent avec les machines limitées en ressources. En effet, sur un pauvre AMD Duron il serait intéressant de ne pas avoir à recompiler l'intégralité du noyau dans le cas où une version précédente identique mais non patchée est déjà compilée. Malheureusement, il ne semble pas y avoir de solution «propre». Il est impératif d'utiliser cake-kpkg cl ean avant d'utiliser à nouveau cake-kpkg kerneli mage, et donc, de recommencer un cycle complet de compilation de longue durée. Ceci vous incitera sans doute à consulter l'ensemble des patchs intéressants ou nécessaires pour votre configuration AVANT de perdre du temps avec la construction d'un noyau «juste pour voir». Bien entendu, avec une configuration plus récente, voire dernier cri, la compilation n'est plus un problème. Il semblerait que les nouveaux processeurs fassent réellement des merveilles dans ce domaine (les utilisateurs Gentoo sont aux anges).
(D CONCLUSION
Comme précisé en début d'article, la recompilation du noyau, mais également de tous paquets binaires, doit être motivée. Dans la plupart des cas, elle ne sera pas nécessaire. Les distributions Debian sont déjà suffisamment modulaires pour offrir la majorité des fonctionnalités qu'un utilisateur puisse attendre.Vous remarquerez toutefois que, même pour ces manipulations qui restent donc rares, les outils développés et proposés sont exemplaires.
Si vous comptez vous pencher davantage sur la construction de noyaux, et passer du temps à expérimenter les différents patchs, modules et paquets, je vous conseille vivement de vous inscrire aux différentes listes de diffusion des développeurs Debian.Vous pouvez également surveiller régulièrement le système de suivi de bogues (voir article sur le sujet dans le présent numéro).Vos résultats, vos problèmes et vos solutions peuvent être utiles, tout comme le temps que vous consacrerez à la tâche.

Le frame buffering est une méthode qui vous permet d'utiliser une carte graphique. La technique consiste à « mapper » en mémoire les valeurs des pixels qu'affiche la carte graphique. Écrire dans cette zone mémoire revient à écrire sur l'écran. Bien entendu, cela implique un mode spécifique définissant la résolution et la profondeur de couleurs. Le noyau binaire par défaut livré par Debian permet d'utiliser le frame buffering. Il suffit de passer au noyau le paramètre vga= suivi d'une valeur spécifiant le mode à utiliser.
On caractérise souvent le fait d'avoir la fonctionnalité de frame buffering activée par la présence d'une petit mascotte de Linux à l'écran (Tux). Le nombre de Tux indiquant, par la même occasion, le nombre de processeurs trouvés au démarrage.Vous n'avez pas de Tux en utilisant par exemple vga=791 (1024x768, couleurs 16 bits) ? C'est normal, l'option de configuration CONFIG_LOGO n'est pas définie par défaut dans un noyau Debian. Mais, il y a mieux (selon les goûts de chacun) que le Tux. Il y a BootSplash, un système de démarrage graphique reposant sur les fonctionnalités de frame buffering.
La première chose à faire pour profiter de ce système qui existe sous forme de paquet est de patcher votre noyau avec kernel -patch-bootspl ash comme expliqué précédemment. Compilez le noyau, construisez le paquet et installez-le.
Il vous faudra ensuite installer la partie « user space » prenant la forme du paquet bootspl ash qui permet de piloter l'affichage. Le but est simple et multiple :
•    Afficher un splash screen au démarrage.
•    Offrir une console agrémentée de graphismes (fond, logo, etc.).
•    Permettre d'afficher durant le démarrage du système une barre de progression indiquant les étapes en cours et le lancement des différents services (idem lors de l'arrêt du système).
BootSplash utilise un système de thèmes. Il est donc possible de personnaliser l'ensemble. Par défaut, un thème Debian est installé dans /etc/bootsplash/themes/debian et un lien symbolique current est créé pointantvers ce répertoire. Lors de l'installation du paquet 000tspl ash, il vous est demandé s'il faut activer BootSplash et s'il est nécessaire de reconstruire le RAM Disk de démarrage. Ceci est, bien entendu, indispensable. Le fichier ietc/defaul t/bootspl ash contient différents paramètres conditionnant l'utilisation de BootSplash et sa configuration (taille, thème, etc.) et il doit être présent.
Une fois tout ceci installé,vous pourrez modifier votre 1 i 10. conf ou le menu.I st de GRUB pour ajouter les arguments vga=791 et spi ash=si lent à passer au noyau (pensez à garder une porte de sortie en conservant une entrée pour le précédent noyau). Dès le premier démarrage, vous devez voir apparaître un magnifique écran de démarrage et finir sur une console fort sympathique (bien qu'un peu chargée graphiquement) :
Plein de graphiques, mais pas de barre de progression. Elle reste désespérément vide. En effet, le système d'Init doit piloter la progression de la barre pour que cela fonctionne. Seul problème, /etc/i ni t .dirc supporte uspl ash (un autre système du même type), mais pas BootSplash. Installez alors le paquet source de sysv-rc-000tspl a Srl. Dans sysv-rc-bootspl ash- 1 .0 .4, vous trouverez deux fichiers : rc.bootspl a sh la version BootSplash et rc.sysv-rc, le rc original. Mais il ne s'agit pas du bon fichier. Copiez donc /etc/init.d/rc en rc. sysv-rc, reconstruisez le paquet et installez-le.Tadaaaa ! Le tour est joué.
Pour avoir d'autres thèmes, ajoutez une entrée à votre /etc/apt/source.list :deb http://bootsplash.de/ unstable main
Il vous suffit alors,après installation d'un thème, de modifier le ietc/defaul t/bootspl ash.N'oubliez pas d'utiliser updatei ni tramfs -u pour mettre à jour le RAM Disk de démarrage.
re NOTE
Il vous est, bien entendu, possible d'utiliser uspl ash. Celui- ci nécessite également le patch BootSplash du noyau et le paquet bootspl ash, mais évite de devoir jouer avec le script rc. Cependant, vous en conviendrez avec moi, le thème par défaut livré sous la forme du paquet debi anedu-artwork -uspl ash est bien moins spectaculaire.

Je n'ai jamais eu connaissance du fait qu'une distribution Debian soit impliquée de près ou de loin dans le fonctionnement d'une fusée Ariane 5. Il n'en reste pas moins que les bogues (de l'anglais « bugs ») représentent le problème majeur de tout système informatique et qu'une distribution Debian est précisément un système informatique.
Votre distribution est donc pleine de bogues. Mais ne vous inquiétez pas, le projet Debian dispose d'un système très évolué permettant de lutter efficacement contre ce problème. Mieux encore, vous pouvez aider à la tâche via l'infrastructure en question, si ce n'est pour éliminer les bogues, au moins pour les trouver et les dénoncer.
LE PREMIER BOGUE INFORMATIQUE
L'infrastructure Debian permettant le travail collaboratif contre les bogues est appelée (très judicieusement) le « Debian bug-tracking system » ou BTS Debian pour les intimes. Sa partie la plus visible et la plus publique est le site Web bugs.debian.org. Là, vous trouverez tous les rapports, les résumés et les discussions en rapport avec les bogues.
Il faut bien comprendre que le BTS d'une distribution n'est, en principe, pas prévu pour servir les projets amonts, les projets produisant les applications et outils intégrés dans la distribution. Le BTS Debian ne se substitue pas aux infrastructures des projets amonts, il est complémentaire. C'est à la charge du responsable d'un paquet de déterminer si le bogue est spécifique à Debian, s'il peut être corrigé « localement » ou si la correction est le travail du projet amont. Des situations critiques peuvent même conduire à la suppression pure et simple d'un paquet. Ce fut le cas avec OpenVVebmail, un VVebmail écrit en Perl et les quelques messages dans les commentaires du BTS parlent d'eux-mêmes : « The code is rife with vulnerabilities, and needs to be audited une by fine ; I'm not sure this is likely anytime soon. I think we should remove it. » (Andrew Pollock — 28 avril 2005).
Pour utiliser le BTS Debian, il faut tout d'abord comprendre son organisation et la classification des bogues.
(D FONCTIONNEMENT GÉNÉRAL DU BTS
Le BTS Debian est une énorme base de données. Il existe une entrée pour chaque bogue. Ceux-ci sont identifiés par un numéro et se rapportent nécessairement à un paquet. Lorsqu'un utilisateur ou un développeur fait un rapport de bogue, une entrée et un identifiant numérique sont créés.
Une entrée dans le BTS peut être dans l'un des quatre états possibles
•    Open : Le bogue est « ouvert », il n'est pas encore corrigé.
•    Forwarded: Le bogue a été rapporté aux développeurs du projet amont afin qu'ils règlent le problème. La suite n'est plus dépendante du responsable du paquet. Souvent le projet Debian attend simplement une nouvelle version du source amont.
•    Resolved/Done : Le bogue est éliminé, le problème est corrigé.
Le terme est parfois faussement attribué à Grace Hopper :une anecdote raconte qu'elle aurait découvert qu'un insecte (bug), coincé entre deux contacts du relais qui faisait fonctionner l'appareil, était la raison du mauvais fonctionnement d'un des premiers ordinateurs électromécaniques.

•    Pending : Le travail est en cours, un développeur Debian a pris en charge le problème et tente de le résoudre. Il n'est pas nécessaire qu'une autre personne passe du temps dessus. Cet état « en cours » indique également que le problème est en phase d'être résolu et qu'il s'agit d'une question de temps et de délai de propagation de la correction. En réalité, il ne s'agit exactement d'un état du bogue, mais d'une étiquette concernant le rapport de bogue.Cependant,« pending » est utilisé comme état du bogue sur le site Web du BTS (http://www.debian.org/Bugs/).
Pour classifier les bogues, il faut déterminer leur niveau de gravité. Il existe sept niveaux, mais seuls les quatre premiers d'entre eux sont utilisables pour un rapport de bogue. Les trois autres permettent de qualifier un bogue de manière spécifique, car, souvent, il est si grave qu'il a des effets sur l'ensemble de la distribution ou qu'il nécessite un comportement spécial de la part de développeurs Debian. N'utilisez pas ces niveaux de gravité pour vos rapports de bogue. Si le problème est effectivement très important, un développeur Debian requalifiera le bogue de manière adéquate.
Les quatre premiers niveaux, en commençant par le moins important, sont
•    wishlist : Il ne s'agit pas vraiment d'un bogue, mais d'un souhait comme l'ajout d'une fonctionnalité ou une modification dans l'organisation des fichiers du paquet. Il peut également s'agir d'un bogue réel, mais trop compliqué à résoudre.Si Windows était un paquet Debian, un rapport de bogue de niveau wishlist pourrait être « empêcher les spywares d'infecter la machine »
•    minor : Le bogue ou le problème n'empêchent pas le fonctionnement et l'intérêt du paquet. Il s'agit souvent de bogues faciles à résoudre. Un exemple est le bogue 354054 concernant le paquet vi m. Les fichiers source d'octave ne sont pas correctement indentés. Ceci n'interdit pas l'utilisation deVim, mais c'est embêtant.
•    normal : C'est la valeur par défaut qui s'applique à la plupart des bogues.
•    important : C'est le plus haut niveau de gravité pour un rapport de bogue fait par un utilisateur. Il concerne un problème qui nuit gravement à l'utilité du paquet. Il n'en devient pas pour autant inutilisable. Par exemple, le bogue 306539, toujours concernantVim, précise que la console est « en vrac » à la sortie de l'éditeur avec des locales UTF-8 sous certaines conditions. On voit bien qu'il s'agit de problèmes très gênants, mais qui ne surviennent que dans des conditions très précises.
Les trois autres niveaux de gravité, toujours du plus faible au plus important, sont :
•    serious : Le paquets n'est pas distribuable, car il viole sévèrement la charte Debian pour la prochaine distribution stable (http://release.debian.org/ etch rc policy.txt).Le document précise clairement ce qui cause une « sévère violation de la charte Debian ».Toujours concernant Vim, le bogue 381526, est une bonne démonstration. Une précédente version
du paquet utilisait /usr/share/doc/vim comme un répertoire. celui-ci était utilisé ensuite par le paquet via-doc. Cependant, une nouvelle version du paquet via utilisait le répertoire de documentation comme un lien symbolique, mais dpkg ne fait pas le changement répertoire vers lien symbolique. Une erreur survenait donc lors de la mise à jour du paquet.
•    grave :Un bogue de ce niveau rend le paquet inutilisable (ou presque). Il peut s'agir de pertes de données ou de problèmes de sécurité. Ce qui différencie principalement ce niveau du suivant est l'influence du bogue. Ici, elle se limite à un utilisateur. Soit, il perd des données personnelles, soit une faille de sécurité le met en danger (rend possible l'accès à ses données). Exemple :le bogue 320017, découlant de la découverte par Georgi Guninski d'une faille de sécurité dans Vim.
•    critical :Voici le top du top dans la catégorie « bogues catastrophiques ». Un bogue de ce niveau de gravité concerne une perte de données pour le système (et non juste pour l'utilisateur du paquet), une faille de sécurité globale au système, le fait qu'il rende inutilisable d'autres paquets ou, enfin, qu'il bloque le fonctionne du système. Le bogue 330474 concernant le MUA Mutt est explicite : le simple fait d'ouvrir une mbox réécrivait la valeur du champ Content-Length dans l'en-tête des messages à zéro. La conséquence directe était, bien entendu, l'écrasement du corps du message dès la réouverture de la mbox. C'est une perte de données grave pouvant influer sur l'ensemble du système (serveurs POP3/I MAP, MTA, Cron, etc.).
LES BOGUES RC
Un bogue RC est un « Release critical bug »,un bogue empêchant la sortie d'une nouvelle distribution stable de Debian. Ces bogues de gravité critical, grave et serious ne doivent pas apparaître dans une distribution stable. Ils doivent être corrigés ou bien les paquets en cause doivent être supprimés. Le compte de ces bogues est tenu en permanence et un résumé est donné sur http://bugs.debian.org/release-critical/

Les bogues RC sont très importants et, habituellement, toute l'énergie des développeurs Debian leur est consacrée. Cependant, il arrive que le ou les bogues ne puissent pas être corrigés localement (à Debian) et requièrent l'action des développeurs amonts. Il faut alors que le développeur Debian en charge du paquet incite les membres du projet amont à plus de réactivité, sachant que les intérêts de chacun peuvent être différents.
Ce n'est que lorsque le nombre de bogues RC passe en dessous d'un certain seuil que la décision est prise de publier une nouvelle distribution stable.
(D PRENDRE CONNAISSANCE
DES BOGUES EN COURS
Si vous rencontrez un problème avec un paquet ou un logiciel installé via un paquet, vous devez consulter le BTS Debian après avoir, bien entendu, analysé le problème localement. La méthode la plus simple est d'utiliser votre navigateur Web et de le pointer sur http://www.debian.org/Bugs/ (ou http://bugs.debian.org qui vous redirigera).Là,vous trouverez l'interface Web d'interrogation du BTS.
Il vous suffit alors de préciser le paquet, la distribution et les options qui vous intéressent (version du paquet, niveau de gravité, état du bogue, etc.).
Une autre solution plus rapide consiste à préciser le nom du paquet dans l'URL. Par exemple :http://bugs.debian.org/mutt. Vous serez alors redirigé directement vers http://bugs.debian. orgicgi-bin/pkgreport.cgi?pkg=muttalist=unstable• Notez cependant que la distribution concernée est Unstable, ce qui n'est pas toujours souhaitable.
Si vous avez besoin d'avoir des informations sur un bogue précis, vous pouvez préciser dans l'URL, en lieu et place
du nom du paquet, le numéro du bogue : http: //bugs .
debi an. org/3761.36.Vous aurez alors le détail de tout ce qui concerne ce bogue ainsi que les discussions s'y rapportant (dont le rapport de bogue initial).
REPORTBUG
Pour simplifier les choses et permettre aux utilisateurs et aux développeurs de gérer les bogues plus facilement, un utilitaire écrit en Python a été créé : reportbug. Il vous permettra non seulement de prendre connaissance des bogues rapportés, mais également d'ajouter des informations et d'en signaler de nouveaux.
ATTENTION
reportbug n'est pas un jouet. Il permet d'interagir avec le BTS Debian et donc avec l'ensemble des développeurs et des responsables de paquets. Lisez attentivement les recommandations et les indications à l'écran, ne faites pas d'essais stupides, soyez clairs dans vos explications et vérifiez absolument tout ce que vous annoncez.
Pour faire connaissance avec reportbug, commencez par installer le paquet correspondant avec apt-get i nstal 1 reportbug. Dans les explications qui vont suivre, si vous souhaitez essayer, utilisez systématiquement l'option
-d ou - -debug. Ceci changera le comportement final de
l'utilitaire, mais non son utilisation.Aucun vrai rapport de bug ne sera envoyé, vous seul le recevrez.
A présent que vous disposez de l'outil, nous allons voir un cas pratique (simulé, bien entendu). Notre paquet sera ipc et notre rapport de bogue concernera l'ajout de couleurs dans les résultats affichés parl'utilitaire. Nous lançons donc reportbug (avec l'option -d) :
% reportbug -d
Please enter the narre of the package in which you have found a problem, or type 'other' to report a more general problem.
le NOTE
La toute première fois que vous lancerez reportbug, un message vous demandera dans quel mode d'utilisation vous souhaitez travailler. Le mode novi ce est le choix par défaut et une excellente solution pour débuter.
Viendra ensuite la question de l'interface à utiliser.Vous aurez le choix entre text (monde console en ligne de commande) et urwi d (en console, mais avec une interface à menus). Dans le reste de l'article, nous utiliserons l'interface text (pour des raisons de démonstration, mais également parce que les couleurs de l'interface à menus sont particulièrement horribles). Notez que l'interface à menus nécessite l'installation du paquet python-urwid.Dans le cas contraire, reportbug se rabat sur l'interface text.