Skip to content

Linux Attitude

Le libre est un état d'esprit

Archive

Tag: Savoir-faire

Niveau :      
Résumé : lilo ; grub

Même si la plupart des distributions sont passées à grub, on s'est longtemps posé la question d'utiliser lilo ou grub. Il servent tous les deux à charger linux (le noyau), voyons comment ça marche.

Bios

Avant de nous intéresser au bootloader, étudions le processus de démarrage d'une machine (x86 type intel).

  1. Appui sur le bouton
  2. Allumage de l'alimentation, électricité dans la carte mère
  3. Allumage du processeur dans un état connu
  4. Passage du contrôle au bios
  5. Lecture d'un disque, chargement du secteur de boot nommé MBR (généralement un bootloader)
  6. Chargement du noyau et d'éventuels modules, passage du contrôle au noyau
  7. Montage d'un système de fichier et passage du contrôle au processus d'init (sur les unix)

Bon, le début, vous connaissez.

L'état connu du processeur c'est : mode réel, 16bits, exécution pointant sur les derniers octets du premier Mo (FFFF:0000). Ici se trouve mappé statiquement le bios qui va se lancer et initialiser le matériel qu'il connaît. Il laisse disponible quelques fonctions via des interruptions, par exemple pour accéder à la carte vidéo ou au disque dur. Et il termine en chargeant le premier secteur (512 octets) du premier périphérique (disque, dur, clé usb ...) bootable qu'il trouve et lui passe la main (à l'adresse 0000:7C00).

C'est ici qu'on trouve lilo, grub, syslinux et même parfois linux lui-même sur de vieilles versions. Comme vous le constatez, 512 octets c'est très petit pour coder un bootloader (surtout que les octets ne sont pas tous disponibles à cause de la table des partitions). C'est pourquoi les bootloaders ont tous une architecture un peu bizarre avec plusieurs étapes.

Lilo

Lilo est un bootloader spécifique à linux (LInux LOader). Il fonctionne en 2 temps, un secteur de boot qui va charger un fichier un peu plus gros dont il connaît les secteurs sur le disque. Ce dernier peut éventuellement proposer un menu puis charge le bon noyau et lui passe la main.


continue reading...

Niveau :      
Résumé : make menuconfig ; make ; make-kpkg

Un bon sysadmin doit savoir recompiler son noyau, et ce pour plusieurs raisons. Tout d'abord, c'est l'occasion de passer en revue les nouveautés (support d'un nouveau driver, changement d'architecture ...), c'est aussi comme ça qu'on peut ajouter les patchs dont on a besoin. Ensuite cela peut permettre de se passer de l'initrd (et donc de gagner une étape au boot) et enfin cela permet de faire des noyaux purement monolithiques si l'on veut renforcer la sécurité d'équipements critiques.

Avant de compiler un noyau, il faut le configurer. Cette étape est longue, très longue, surtout pour une première fois. Mais c'est aussi la plus intéressante. Je vais donc vous la présenter en long, en large, et surtout en travers. Si cela vous parait lourd, ne partez pas, sautez quelques étapes et revenez-y plus tard.

La base

Commençons par récupérer les sources du noyau. Personnellement je prends les sources officielles de Linus, simples à trouver :

# usuellement on se met dans /usr/src, mais ça n'a rien d'obligatoire
$ lftp ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.XXX.tar.bz2
# qu'on va décompresser
$ tar xfj linux-2.6.XXX.tar.bz2
$ cd linux-2.6.XXX

# les debianeux peuvent aussi avoir les sources patchés debian
$ apt-get install linux-source-2.6.XX

Nous allons récupérer la configuration actuelle du noyau pour partir sur des bases saines et ne pas avoir peur de tout casser si on saute une étape. Le fichier de configuration s'appelle .config

# la meilleur méthode si disponible : lire la configuration en live
$ zcat/proc/config.gz > .config
# sinon récupérer un ancien fichier
$ cp ../linux-2.6.XX-1/.config .
# ou celui fourni par la distrib
$ cp /boot/config-2.6.XX-1 .config

Lançons la configuration :

# en mode texte (il vous faut libncurses5-dev)
$ make menuconfig
# en mode graphique (qvec qt depuis quelque temps)
$ make xconfig 
# ou avec gtk
$ make gconfig

continue reading...

Niveau :      
Résumé : openssl base64 ; perl -MMIME::Base64

De nombreux standards sont définis pour être explicitement lisibles par l'utilisateur, par exemple le mail. Il doivent donc être composés de caractères lisibles. Cela peut poser problème si on veut transmettre un fichier binaire qui par définition peut contenir n'importe quoi.

C'est à ce moment qu'on a inventé l'encodage en base 64. Le principe est simple, plutôt que d'utiliser des octets de 8 bits, on va utiliser des "octets" de 6 bits (2^6 = 64, vous aurez compris le nom), lesquels seront écrit dans des octets de 8 bits, mais en utilisant exclusivement des caractères ascii lisibles (A-Z,a-z,0-9,+,/). Exemple :

# on transforme 3 octets en base 64
Caractères  (/8) : "ABC"
Hexadécimal (/8) : 41 42 43
Binaire     (/8) : 01000001 01000010 01000011
Binaire     (/6) : 010000 010100 001001 000011
Hexadécimal (/6) : 10 14 09 03
Base64           : "QUJD"

La dernière étape n'a rien d'évidente puisqu'elle n'utilise pas la table ascii, mais une table spécifique que voici :

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/

On y ajoute quelques subtilités, par exemple il n'est pas toujours possible de faire des blocs de 6 complets. Si le nombre d'octets à coder n'est pas multiple de 3, on complète les caractères base64 manquant par des '=' pour indiquer de ne pas prendre en compte les bits correspondant. Notez que tous les caractères qui ne font pas partie de l'encodage sont autorisés et simplement ignorés lors de décodage. Ce qui veut dire que vous pouvez formater votre base64 comme vous voulez avec des espaces et des retours à la ligne.

Maintenant que vous avez compris le principe vous n'allez pas toujours encoder ou décoder à la main. Des outils sont déjà présents chez vous :

# avec openssl 
$ echo "Binaire" | openssl base64
> QmluYWlyZQo=
$ echo "QmluYWlyZQo=" | openssl base64 -d
> Binaire

# ou avec perl
$ perl -MMIME::Base64 -e 'print encode_base64("Binaire\n");'
> QmluYWlyZQo=
$ perl -MMIME::Base64 -e 'print decode_base64("QmluYWlyZQo=");'
> Binaire

Conclusion  : maintenant vous savez pourquoi les pièces jointes des email prennent 33% de plus de bande passante que leur taille réelle (il en est de même pour les news binaires ;-). Et vous savez aussi pourquoi il vous est possible de copier/coller facilement votre clé ssh ou gpg alors que ce sont des binaires.

Niveau :      
Résumé : sauvegarde, archivage, SSL, sécurité, hacker, pirate, stabilité

Sauvegarde et archivage

L'archivage, c'est stocker des données de manière plus ou moins définitives dans le but de pouvoir les relire dans un avenir plus ou moins lointain. Exemples : les logs d'accès, le contenu d'un site à certaines dates, la documentation ...

La sauvegarde, c'est stocker des données dans le but de le récupérer dans un avenir proche en cas de problème. Exemples : le système, les données du serveur, les bases de données ...

Ce qui veut dire qu'une archive doit être stockée sur un média durable. De plus une archive n'as pas nécessairement besoin d'être stockée sur un média réinscriptible contrairement à la sauvegarde. Une sauvegarde doit être disponible très rapidement pour permettre un rétablissement rapide de la situation.

SSL et sécurité

SSL sert à sécuriser une communication. ce n'est pas parce que vous utiliserez SSL que votre application pourra être dite sécurisée. La communication ne pourra pas être lue ou modifiée sou certaines conditions (vérification du certificat). Mais rien n'empêche votre application d'être trouée de bugs ou même votre serveur de se faire pirater.

Pirate et hacker

Un hacker, c'est un bidouilleur, un passionné dans un domaine comme l'informatique ou l'électronique. Un hacker peut être bon ou mauvais. Mais de par sa passion il a plus souvent tendance à être bon, contrairement à ce que la presse informatique cherche régulièrement à nous faire croire. Je vous invite à lire le manifeste du hacker ou sa traduction française pour mieux comprendre comment pensent les hacker.

Un pirate c'est un marin qui attaque les bateaux pour son propre profit.

Stabilité et stabilité

Celle-ci est plus difficile. Il existe plusieurs sortes de stabilité. La stabilité peut qualifier la stabilité de du code, c'est-à-dire son peu de changement. C'est grâce à ce genre de stabilité qu'un code valide reste un code valide dont le nombre de bug n'augmente jamais, mais ca ne veut pas dire qu'il est nul. C'est à cette stabilité qu'on pense lorsqu'on parle de la stabilité de Debian.

Mais il existe aussi ce qu'on appelle la stabilité du système. Il s'agit de qualifier le nombre de "plantages", ou plutôt de bugs graves. C'est à cette stabilité que l'on pense lorsqu'on dit que Windows n'est pas stable.

Notez qu'en général ces deux formes de stabilité s'opposent. En effet, un code stable a tendance à conserver ses bugs, alors qu'un code dont les bugs sont régulièrement corrigés évolue aussi en général beaucoup.

Niveau :      
Résumé : asciidoc

Aujourd'hui évitons de réinventer la roue. Si vous cherchez à écrire un langage de présentation simplifié (bbcode, dotclear, mediawiki, doku wiki et les centaines de sortes de wiki existantes), laissez tomber et prenez quelque chose qui existe. Je vais vous en présenter un parmi tant d'autres, un qui a l'avantage d'être parfaitement lisible directement en mode texte.

Supposons que vous ayez un petit texte à écrire pour votre usage personnel (mémo, post-it, article de blog, mail ...). Écrivez le simplement sous la forme qui vous semble naturelle dans un éditeur de texte :

Mes courses
===========

Fauchon
-------
* Fraisier
* Chocolats

Foucher
-------
* Rochers noirs
* Cerises

Et voila, vous avez la partie texte, éditable et lisible.

Vous le voulez en html ?

$ asciidoc -b html4 fichier.txt

Vous le voulez en pdf ?

# on passe par du docbook
$ asciidoc -b docbook fichier.txt
$ docbook2pdf fichier.xml

En fait asciidoc ne supporte nativement que xhtml 1.1, docbook et html 4, mais le docbook permet de sortir dans pla plupart des formats de fichiers (y compris odf :-).

Notez que le manuel complet d'asciidoc a été écrit en asciidoc. Il a l'air long, mais seuls les chapitres 7 à 13 sont utiles pour les cas courants.

Alors de grâce n'inventez plus de nouveau langage, celui-ci suffit amplement. Il est tellement simple à lire et à écrire que je connais une entreprise qui l'utilise exclusivement pour sa documentation interne ! Vous pouvez envoyer vos documentations par mail, diff et patch fonctionnent, vous pouvez les publier proprement (css est votre ami), vous n'avez pas besoin d'un gigaoctet de ram pour l'éditer puisque vi suffit et enfin vous pouvez l'éditer depuis les modems 9600bps du Népal.

Niveau : Star Star Star Empty Empty
Résumé : a lire

Après les incontournables, les contournables. Je suis sur que vous voue ennuyez et que votre lecteur de flux est bien vide en ce moment. Je vous propose donc quelques sites et blogs moins connus mais donnant de nombreuses informations techniques de qualité :

Tout d'abord les francophones :

Et quelques anglophones pour la forme :

J'ai laissé de coté certains blogs qui publiaient très peu, mais si vous en avez de bons à m'indiquer n'hésitez pas.

Niveau :      
Résumé : sysrq ; sysrq-trigger ; sysrqd

Sysrq, nom de la touche clavier pour system request (aussi connue sous le nom de print-screen). Les magic-sysrq sont une fonctionnalité optionnelle du noyau utilisant cette touche. Lorsqu'elle est compilée dans votre noyau et activée, elle est disponible en utilisant la combinaison de touche alt-sysrq-X où X est une touche du clavier.

Ces touches sont particulièrement utiles en situation d'urgence. Les plus importantes à mémoriser sont 'sub'. Une utilisation typique ressemblera plutôt à 'rfesiub' (pensez a laisser un peu de temps entre les touches).

Les touches les plus courantes sont :

  • b : reboot pur et simple de la machine
  • e : termine proprement (SIGTERM) tous les processus
  • f : tue un processus consommateur de mémoire (au hasard)
  • h : affiche l'aide si vous êtes en console (la touche espace aussi)
  • i : tue (SIGKILL) tous les processus
  • k : tue les processus lancés dans la console en cours (dont xorg si c'est le cas), Cela permet de récupérer l'accès au clavier. Certaines mesures de sécurité exigent de l'utiliser avant de se logguer en console pour tuer d'éventuels keyloggers.
  • r : réinitialise le mode de fonctionnement du clavier (à la suite d'un crash de xorg par exemple)
  • s : synchronise les systèmes de fichier (pour ne pas avoir de problèmes avant un reboot violent)
  • u : passe les systèmes de fichier en lecture seule
  • 0-9 : change le loglevel des messages du noyau

Et d'autres plus rares :

  • c : lance un kexec
  • d : affiche les locks en cours
  • m : affiche un dump mémoire
  • n : utilisé pour le temps réel
  • o : éteint la machine (ne marche pas toujours)
  • p : affiche les registres du processeur
  • q : affiche les timers
  • t : affiche des informations sur les processus
  • w : affiche les processus bloqués

Il est possible de désactiver l'usage de ces fonctionnalités

$ echo 0 > /proc/sys/kernel/sysrq

Ou plus finement avec un nombre supérieur à 1 (voir /usr/src/linux/Documentation/sysrq.txt).

Et si vous êtes à distance vous pouvez faire appel à une de ces fonctions en ligne de commande :

$ echo s > /proc/sysrq-trigger

Et si vous êtes encore plus à distance (ssh ne fonctionne plus), il y a aussi moyen de les déclencher avec sysrqd. Sysrqd est un démon qui doit tourner sur la machine (bloquée donc bon courage). Et à ce moment :

# port 4094
$ telnet crashed.machine sysrqd