Voici quelques ordre de grandeur qui vous permettront d'avoir les idées un peu plus claires sur les performances de votre système. Imaginez que le swap est 100 000 fois plus lent que la mémoire du processus ! Qu'un algorithme de création d'arbre peut être plus lent qu'un algorithme linéaire si chaque nœud de l'arbre se retrouve sur une page différente (pensez à vos centaines de malloc pour remplir un arbre) !

Notez que l'important ce sont les ordres de grandeur, vous pouvez facilement trouver des éléments qui font le double ou la moitié de ces performances.

Interprétations

Sérieusement, pas besoin de giga de swap sur votre serveur. Mettez un tout petit peu et vous monitorez dès que ca dépasse, imaginez la division par un nombre à 5 chiffres du nombre de pages vues sur votre serveur ! Pour ma part je préfère répondre à moins de requêtes par seconde et garder un serveur utilisable.

Mais sur votre station de travail vous faites ce que vous voulez, on est en général plus patient :-)

Pas de gettime à gogo dans votre code pour mesurer les perf, ça tue les perfs ...

Le réseau fait a peu près aussi bien que votre disque.

Pas de malloc à gogo pour des structures morcelées et très utilisées. faites une structure unique si vous devez en avoir beaucoup.

Le SSD c'est bien mais ca vaut pas l'accès direct au flash.

Étant donné la vitesse de compression un swap compressé peut vraiment valoir le coup.

Le cache processeur sert vraiment à quelque chose ... si on sait coder pour qu'il soit utilisé (ou laisser le compilateur faire).

Le fork c'est un peu lent, prévoyez un prefork correct sur vos applications fréquemment appelées.

Avoir beaucoup de processus n'est pas si coûteux en soi (context switch).

PS : Si vous avez des données pour compléter ce tableau, n'hésitez pas à me laisser des commentaires.

Si vous avez aimé, il y a aussi :

1. Que faire et ne pas faire en raid

Petite fiche technique pour ne pas se perdre dans le monde de l'hébergement :

Housing

C'est le même terme en français, on dit aussi colocation, il désigne en général la fourniture de l'espace dans une armoire, du réseau et de l'électricité et c'est tout.

Pourtant c'est en général l'offre la plus chère car la plus lourde à gérer pour l'hébergeur. C'est plutôt destiné aux entreprises qui ont leur propre matériel et/ou dont l'activité sera de revendre l'accès à leur propre matériel.

Server hosting

Ou serveur dédié en français. Pratique pour une PME, ce concept permet à un sysadmin ou une petite boite d'avoir un ou des serveurs qu'elle gère entièrement, sans contraintes mais aussi sans avoir à gérer la redondance électrique ou la redondance du réseau.

On a en général une bien meilleure disponibilité et un bien meilleur débit qu'un serveur hébergé chez soi. Donc valable dès qu'on offre des services à l'extérieur. De plus on ne s'embête plus avec les matériel et ses pannes ou presque.

VPS

Ou serveur virtuel en français. C'est une machine virtuelle sur laquelle vous avez tout pouvoir (root) mais située sur une machine physique partagée avec d'autres clients.

Cela permet de faire des machines très peu chères en contrepartie d'une absence de garantie de performances.

A noter qu'OVH a sorti un produit intermédiaire entre le vps et le dédié nommé RPS. Il s'agit d'un dédié léger mais dont le disque est partagé sur le réseau.

Web hosting

Hébergement mutualisé en français. Ce genre d'offre en général est la moins cher et la plus facile à gérer. Disponible immédiatement ou presque, vous avez plus ou moins d'espace disque, une base de données plus ou moins grosse et un virtualhost php avec parfois un nom de domaine.

A choisir lorsqu'on fait un "simple" site web.

Cloud

Petit nouveau, le cloud désigne en fait un groupe de machines dont on vous vend la puissance de calcul. Il existe autant de formes de cloud que de vendeurs de cloud, tous ont cette particularité de vendre des quantités variables.. Il y a ceux qui vous vendent des vm en grande quantité, il y a ceux qui vous vendent des serveurs d'application, il y a ceux qui vous vendent de la base de données ou du simple dépôt de fichier.

A choisir lorsqu'on a des applications scalable et qu'on prévoit un grand nombre de clients potentiels.

Autres

Les hébergeur offrent aussi sous forme de pack des noms de domaine, des services dns, des services de boite mail, d'envoi en masse de mail, en général pour pas trop cher, cherchez, vous trouverez.

Il existe aussi d'autres offres plus rares d'hébergement d'application ruby, python, java mais il faudra chercher pour trouver quelque chose d'intéressant.

Dans le genre exotique vous verrez aussi des offres de type shell où vous avez un shell sur une machine partagée entre plusieurs utilisateurs. Ce genre d'activité nécessite en général une certaine confiance et a plutôt tendance à fonctionner à travers des réseaux sociaux.

Si vous avez aimé, il y a aussi :

1. Hébergement de fichiers avec WebDAV
2. PKI
3. Raid 10 ou raid 0+1 ?

Aujourd'hui les disques atteignent des limites qui n'avaient pas été prévues lorsqu'on les fabriquait comme des machines à laver (notez que le premier disque tournait déjà à 3600 tours par minute.

Les disques ont d'abord été adressés au format cylindre, tête, secteur (CHS), puis au format LBA. Les différentes limites ont évolué en fonctions de la taille du bus d'adressage.

Limites

Aujourd'hui on rencontre encore plusieurs limites. Tout d'abord au niveau logiciel, les partitions qui prévoyaient un adressage linéaire sur 32 bits des secteurs trouvent une limite à 2To (2^32 * 512).

Aujourd'hui au niveau du disque lui-même, les fabricants qui stockaient les informations de redondance et de structure du disque sur chaque secteur commencent à trouver cet espace très restreint.

Aujourd'hui les disques sont tellement gros que la lecture d'un disque entier est extrêmement longue, une erreur dans un fichier et la récupération du système de fichier devient une opération très lourde.

Aujourd'hui les disques sont tellement gros que la restauration d'un disque dans un raid prends un temps énorme, au point qu'il est possible d'avoir une seconde défaillance pendant ce temps.

Aujourd'hui les disques normaux sont tellement gros qu'on utilise le même disque pour plusieurs machines.

Aujourd'hui les disques sont tellement petits qu'on en utilise plusieurs par machine.

Avec tous ces problèmes, on voit beaucoup de choses évoluer.

RAID 6+1

Les disques étant de plus en plus lents et de plus en plus gros, on est déjà passé du raid5 au raid6 pour éviter les problèmes de lenteur lorsqu'un disque manquait, on envisage d'ajouter un nouveau disque de redondance pour éviter le cas où un 2e disque grille pendant la restauration du premier.

SAN

Maintenant tout le monde a un NAS chez lui, mais les serveurs utilisent des SANs qui se partagent sur des interfaces réseau standard et plus seulement SCSI ou Fiber Channel. Le iSCSI, le AoE ainsi que d'autres protocoles permettent d'accéder à ces périphériques de façon transparente et sans matériel supplémentaire.

GPT

Les disques atteignent couramment une taille de 2To. Le format de partition actuel ne permet pas d'utiliser le disque au delà de cette taille. Il devient donc rapidement obligatoire de passer au format GPT. Ceci implique des modifications dans le bios et dans le système d'exploitation.

Secteur 4k

Les secteurs de 512 octets devenant petit, on commence à fabriquer des disques ayant des secteurs de 4ko. Cela permettra une plus grande capacité, de meilleures performances, mais implique aussi des changements au niveau du bios et de système d'exploitation (très lourd cette fois). Quelques références et solutions.

Filesystem

Toutes ces fonctionnalités nouvelles peuvent êtres prises en compte au niveau du système de fichier pour permettre des fonctionnalités sympathiques. Le snapshot fréquent voir continu, l'utilisation de plusieurs disques locaux voire distants, la vérification d'intégrité en live, la récupération d'une perte sans downtime, la possibilité d'utiliser des disques d'une taille quasiment infinie pour notre époque, l'usage d'un même filesystem par plusieurs machines ...

Tout ceci n'était qu'un aperçu qui je l'espère vous donnera envie de connaître les nouvelles technologies à venir.

Si vous avez aimé, il y a aussi :

1. Lecture d’image disque
2. Disque dur
3. Table des partitions

Lorsqu'on parle de redondance, de haute disponibilité et de disque, on parle de Raid. J'en ai déjà parlé

Voici un petit aperçu des différents types de RAID, le but est ici de trouver les qualités de chacun. Un tableau final récapitule les avantage et les inconvénients qu'il y a à choisir un type de raid donné.

Jbod

Just a bunch of disk, ce n'est pas un raid, le choix de ceux qui veulent pouvoir ajouter des disques bout à bout sans gain de performance.

Contrairement au raid 0 il a un avantage, la perte d'un disque n'empêche pas la récupération des données sur les disques restants par un outil de récupération tel que photorec. En effet, comme les disques sont simplement mis bouts à bout, la plupart des fichiers tiennent intégralement sur un seul des disques. Il est donc possible d'en récupérer le contenu après un crash.

Le jbod se fait avec du LVM sans striping ou avec le driver linear de md.

Raid 0

Le choix de ceux qui veulent des performances.

Chaque disque est découpé en bande (stripe) et les bandes sont entrelacées pour donner le disque final. Ce qui donne un gain de performance appréciable puisque les disque peuvent être lus simultanément, même pendant la lecture d'un gros fichier. Et ils peuvent être écrits simultanément pendant les écritures.

Le raid 0 peut être matériel, logiciel avec le driver md de linux ou logiciel avec LVM (avec striping)

Raid 1

Le choix de ceux qui ne veulent pas de pertes.

Tous les disques sont des copies intégrales. L'avantage le plus important est que lors de la perte d'un disque tout fonctionne comme si de rien n'était. On peut donc remplacer ce disque (ou pas :-).

Un autre avantage existe lors des lectures non séquentielles (lors de la lecture de 2 fichiers par exemple), dans ce cas il est possible d'utiliser un disque pour chaque lecture et donc d'accélérer ce type de lecture. Par contre la lecture d'un seul gros fichier n'est pas accélérée (sous linux).

Il n'y a en revanche aucun impact sur l'écriture, c'est le disque le plus lent qui détermine la vitesse d'écriture (la vitesse devrait être à peu près identique pour chacun).

Notez qu'on peut faire du raid 1 avec plus de 2 disques.

Le Raid 1 peut être matériel, logiciel avec le driver md ou logicielle avec LVM (support du miroring), enfin il est possible de faire du raid1 réseau avec drbd.

Raid 5

Le choix des économes.

En raid 5 chaque disque est découpé en bande, pour chaque groupe de bandes situées au même endroit des disques, une des bandes est choisie pour contenir des octets de redondance (la différence avec le 4 c'est le choix de la bande). Ainsi ce type de raid peut survivre au crash d'un des disques (la redondance permet de reconstruire la bande manquante), mais pas de plusieurs.

L'avantage du raid 5 est que lorsqu'on a de nombreux disques on économise des disques de redondance en n'en achetant qu'un pour la redondance et les autres pour les données.

Mais le raid 5 est assez limité en performances. La lecture se passe comme pour le raid 1. Par contre l'écriture nécessite la lecture de chacune des bandes d'un groupe pour écrire la bande de données, puis calculer et écrire la bande de redondance. C'est donc très lent, à éviter pour les bases de données actives.

D'autre part, lors du crash d'un disque, toutes bandes des disques doivent être lues pour reconstituer une bande manquante. Ce qui implique des baisses de performances énormes, auxquelles il faut ajouter la baisse de performances due à la reconstruction du disque qu'on va remettre. Comme les disque tournent à fond, il n'est pas rare de voir un autre disque exploser en vol à ce moment là -> fin des données.

Le raid 5 peut être matériel ou logiciel avec le driver md de linux.

Raid 6

Le choix des très gros disques.

Le raid 6 fonctionne de la même façon que le raid 5 mais ajoute un deuxième disque de redondance. Ce ne sont pas simplement les données de redondance qui sont dupliquée, mais le calcul qui est différent, toutefois le concept est identique.

Le raid 6 soufre des mêmes inconvénients que le raid 5, il utilise même un disque de plus donc est un peu plus cher, de plus cela provoque une écriture supplémentaire pour chaque groupe de bandes.

Mais le raid 6 résiste au crash de 2 disques, ce qui est intéressant lorsque les disques sont assez gros et que la reconstruction du raid comment à être assez longue (et donc le risque de perte plus gros).

Le raid 6 peut être matériel ou logiciel avec le driver md de linux.

Raid 10

Le choix des riches.

Le raid 10 consiste à accumuler plusieurs raid 1 avec du raid 0 pour en augmenter la taille et les performances.

Le raid 10 offre les avantages simultanés du raid 1 et du raid 0. La perte d'un disque n'empêche pas le raid de tourner et l'utilisation de plusieurs disques en striping permet d'augmenter les performances de lectures.

Le seul inconvénient, c'est qu'il coûte deux fois le prix du raid 0.

Il peut se faire en matériel ou logiciel, md ou lvm.

Raid 0+1

Le mauvais choix.

Le raid 0+1 consiste à mettre 2 raid 0 en parallèle pour les redonder avec du raid 1. On pourrait croire que c'est la même chose que du raid 10, mais non. Et même si certains veulent vous faire croire que les performances sont meilleures, il n'en est rien.

Mais surtout imaginez un instant la perte d'un disque. Dans ce cas un des raid 0 sous-jacent est perdu. Il faut donc le recréer avec un nouveau disque (ce qui est à peu près instantané puisqu'on le laisse vide), puis reconstruire le raid 1 situé au dessus. Et cette deuxième partie va être longue puisqu'elle doit être faite sur la taille totale du raid 0, contrairement au raid 10 qui ne l'aurait fait que sur la taille totale du disque perdu.

Petit récapitulatif

Si vous avez aimé, il y a aussi :

1. Que faire et ne pas faire en raid
2. LaVoMatic
3. L’avenir du disque

Maintenant que nous connaissons le processus de boot, si on examinait ce processus d'un point de vue de la sécurité !

Lorsqu'on parle de sécurité, il faut d'abord savoir dans quel cas on se positionne et de quoi on cherche à se prémunir. Ici, je considère que le système lui-même est sécurisé. Je suppose que l'attaquant est devant la machine et cherche un accès root.

On considère que chaque élément est sécurisé pour ce qui est de ses propres fonctionnalités, ce qui veut dire que si le bootloader est protégé par mot de passe, il n'y a pas de faille dans le bootloader lui-même permettant d'outrepasser ce mot de passe. Nous nous attacherons donc à chercher ce qui peut être détourné dans le flux d'exécution en entrée et en sortie de chaque élément.

Je vais commencer par la fin, du plus facile au plus difficile.

rc

Rc est lancé par init et ne prend ses paramètres que de init. Ceux-ci sont fixés en dur dans /etc/inittab. Son démarrage ne peut donc être détourné que d'une façon : par modification du contenu du disque. GoTo partition /

Parmi ces paramètres il y a le paramètre 1 qui lance rc dans le runlevel 1, ce qui dans la plupart des cas se termine par un sulogin. Ouf on est protégé par le mot de passe root.

Mais vérifiez bien, dans certains cas il se termine par un simple shell et donc réussir à passer un tel paramètre permettrait à l'attaquant un accès root à votre machine.

Pour passer 1 en paramètre GoTo init

init

Init est lancé par le noyau après lecture de la racine. Il lit sa configuration dans /etc/inittab. Il peut donc être détourné par modification du disque : GoTo partition /

Parmi les paramètres qu'on peut lui passer il y a 1 et S, 1 renvoie au problème ci-dessus et S lance lui-même sulogin, donc même vérification. Ces paramètres viennent du noyau : GoTo noyau

Init est un binaire choisi par le noyau, or il est possible de dire au noyau de changer d'init à travers le bon paramètre. Par exemple, je peux ajouter init=/bin/sh aux paramètres du noyau pour qu'init ne soit jamais lancé qu'un shell apparaisse à sa place. Ça y est je suis root ! C'est d'ailleurs la technique pour changer de mot de passe root lorsque vous l'avez perdu.

Pour changer d'init GoTo noyau.

Init peut aussi être lancé par initrd, il souffre dans ce cas exactement des mêmes problèmes que lorsqu'il est lancé par le noyau : GoTo initrd.

Note upstart, initrdng... :
Il se peut (et ca va être de plus en plus courant) qu'init ou rc soit remplacé par autre chose, type upstart. Dans ce cas seul les noms des paramètres et le format des fichiers change. Mais les impacts sont exactement les mêmes.

Initrd

Initrd prend ses paramètres de la ligne de commande du noyau, mais généralement (il y a plein d'initrd différents) ils sont passés tels quels à init.

D'autre part initrd peut être chargé par 2 moyens, j'ai décrit le bootloader comme un moyen mais le noyau peut aussi charger lui-même l'initrd si on lui demande (avec le paramètre initrd=). On peut donc détourner son chargement par plusieurs moyens : GoTo noyau, GoTo bootloader.

Il est aussi possible de modifier directement l'initrd, par exemple lors d'une réinstallation distante. Celui-ci contenant tout ce qu'on veut, modifier son contenu permet de lancer n'importe que processus ... GoTo partition /boot

Noyau

Le noyau en lui-même ne vous rend pas root mais rien ne vous empêche d'y faire une modification pour qu'il vous fasse root une fois le système chargé.

Le noyau est chargé depuis la partition /boot donc une modification de cette partition et c'est gagné : GoTo partition /boot

Le noyau prend ses paramètres du bootloader, parmi ceux-ci de nombreux paramètres permettent de détourner le système : root= init= initrd= et surement bien d'autres. GoTo bootloader

Partition /

Jusque là, nous n'avons évoqué que les risques mais pas encore de faille. C'est parce qu'aucune interférence de l'utilisateur n'a été possible, tout est automatisé. Mais ça va changer.

Lors du montage de la racine, il y a une interférence possible : le disque contenant / peut avoir été modifié, voire remplacé, pour modifier /etc/inittab, /sbin/init, /etc/init.d/rc ou toute autre chose.

Pour éviter ce problème, il y a deux possibilités :

• mettre un cadenas sur la machine pour garantir l'intégrité physique du disque
• chiffrer le disque

Dans le premier cas, le problème est remonté aux autres couches pour garantir l'intégrité logique et éviter qu'on réussisse à booter sur un autre OS pour modifier le disque. GoTo bootloader.

Dans le deuxième cas, le chiffrement (par exemple avec luks ou truecrypt) doit être assuré par une clé.

• si cette clé est sur la machine et son mot de passe aussi : elle est dans un élément de boot (initrd, partition de boot ...) on reporte le problème GoTo partition /boot
• si cette clé ou son mot de passe n'est pas sur la machine (carte à puce, mot de passe, clé usb ...) alors il y a besoin d'un personne présente à chaque boot ...
• le chiffrement peut aussi être assuré par une puce (TPM) qui ne quitte pas la machine, auquel cas, on garanti que le disque ne quittera pas la machine pour être lu ou modifié (mais pas de garantie contre le formatage), par contre il peut être lu sur place par un autre OS.

Dans tous les cas, seul le démarrage post-noyau est préservé, pour le reste GoTo bootloader.

bootloader

Le bootloader est la source de tous les maux. C'est en effet par lui que l'utilisateur a tout loisir de modifier des paramètres de démarrage.

Le bootloader passe ses paramètres au noyau qui les passe à l'initrd qui les passe à init. Ces paramètres viennent de la configuration du bootloader mais pour un certain nombre de bootloader ils peuvent être directement demandés à l'utilisateur. Dans ce cas il y a moyen d'interdire cette modification à travers un mot de passe. Par exemple grub.

Le bootloader charge sa configuration puis choisit et charge le noyau et l'initrd, tout ceci depuis la partition de boot. Dans tous les cas il doit lire une version non chiffrée, ce qui interdit le chiffrement de cette partition.

Pire, le bootloader est incapable de savoir que le disque n'a pas changé. Donc un simple ajout de disque permet de le faire booter sur un noyau/initrd différent.

Vous ne pouvez presque rien y faire: GoTo partition /boot.

Bon en supposant qu'il n'y a pas de problème, le bootloader est chargé par le bios, il peut donc être détourné : GoTo Bios.

Partition /boot

J'inclue dans la définition de la partition de boot tout ce qui contient la configuration du bootloader, le bootloader lui-même, le noyau et l'initrd, même si ils peuvent être physiquement à des endroits différents. Protéger la partition de boot est très complexe, car tout doit être accessible en clair depuis des outils ayant des fonctionnalités très restreintes.

Les possibilités sont :

• sceau physique sur la machine
• TPM

Mettre un gros cadenas sur la machine permet d'éviter une lecture ou une modification de /boot. Mais il on ne se prémunit pas d'une personne un peu patiente avec un accès complet à la machine.

La dernière solution, complexe à mettre en place et sans garantie absolue est d'utiliser une puce TPM qui va vérifier (mesurer) le bootloader à chaque étape de son chargement, puis vérifier chaque élément que le bootloader charge avant de lancer le noyau.

Bios

Le bios s'exécute tout seul depuis lui-même, il se charge puis lis ses paramètres. Parmi ces paramètres il y a la séquence de boot, qui peut elle-même être modifiée par l'utilisateur.

Il est donc possible, voire facile de dire au bios de booter sur une clé USB et de prendre le contrôle du disque et donc de la machine. Pour éviter ce cas de figure il est possible de mettre un mot de passe au bios. Ainsi on est sûr de booter sur le bon disque, mais seulement s'il y a un cadenas sur la machine puisque le bios ne vérifie pas que le disque n'a pas été remplacé.

GoTo Matériel.

Matériel

Il est possible de changer le bios lui-même. Et ce de plusieurs façons. Si c'est un flash, il est possible de le remplacer logiciellement, si c'est une rom il est possible de la remplacer matériellement.

Et enfin le plus simple pour remplacer le bios est de remplacer la carte mère. Hop ni vu ni connu ...

Pour se protéger de cela ? Le cadenas ... ou la puce TPM, dont la mise en place est toujours très complexe et non garantie.

Conclusion

Résumons-nous car cet article commence à être un peu long. Différencions les cas dont on veut se protéger.

Accès réseau

Si l'attaquant n'a accès à la machine que par le réseau, on est tranquille pour ce qui est de la séquence de boot : No problemo.

Accès KVM

Si l'attaquant n'a accès à la machine que par KVM (pas de possibilité de toucher aux périphériques). Mettre un mot de passe sur le bootloader, le bios et vérifier que le mode rescue demande le mot de passe root devrait suffire. En effet les seul moyen d'attaque sont les paramètres de lancement du système.

N'oubliez pas que le simple accès KVM permet des choses comme le reboot via les magic keys

Accès cadenassé

Si on suppose que l'attaquant peut apporter un CD ou une clé usb sur le système, paramétrer le bios pour booter sur un disque et y mettre un mot de passe est un moyen simple à mettre en place pour éviter le boot sur un autre système.

Mais attention, il ne faut pas que l'utilisateur puisse ouvrir la machine, il pourrait réinitialiser le bios.

Accès au disque sans droit de boot

A partir du moment où l'attaquant a accès au disque c'est presque foutu. Si l'attaquant n'est pas une personne autorisée à booter la machine, il est possible de chiffrer le disque avec une clé qui ne se trouve pas sur le disque. Il faudra alors la rentrer à chaque démarrage. L'attaquant ne disposant pas de cette clé, il me pourra ni lire ni modifier les données où le système. Mais c'est déjà une solution assez contraignante.

D'autant plus que pour être complète cette solution doit garantir le noyau et l'éventuel initrd sur lequel on boote et donc vérifier soi même à chaque boot qu'on utilise une partition de boot non modifiée.

On en arrive au dernier cas ...

Accès complet

Lorsque l'attaquant a un accès complet à la machine, il n'existe qu'un moyen de se protéger (et encore) : la puce TPM.

Elle permet de :

• protéger le bios d'un changement
• protéger le bootloader d'un changement
• protéger le noyau d'un changement
• protéger le contenu du disque d'un changement

Mais tout cela est compliqué et nécessiterait un autre article que je ne suis pas encore prêt à faire, je n'ai même pas de puce TPM chez moi.

PS : Notez une dernière chose que je n'ai pas abordé, le chiffrement des données. Le chiffrement du disque contenant les données (/home et /srv selon vos besoins) devient obligatoire dès qu'on prévoit qu'il y aura un accès physique. Il doit de préférence se faire avec un moyen propre à l'utilisateur (mot de passe / clé / carte à puce ...) pour éviter les attaques à travers le boot de l'OS.

PPS : Considérez qu'a partir du moment où quelqu'un a un accès physique à votre machine c'est mort.

PPPS : Sauf si votre machine est une carte à puce.

PPPPS : Et encore ...

Bon courage !

Si vous avez aimé, il y a aussi :

1. Processus de boot
2. Mesurer le temps de boot
3. Réinstallation distante

Je ne me souviens pas avoir fait un article complet sur le processus de boot. Il y en avait un partiel ici. En voici un !

BIOS

Le bios est le premier élément à être lancé, si on excepte l'appui sur le bouton ON et quelques autres détails. Celui-ci initialise le processeur ainsi qu'une partie du matériel, comme la carte vidéo ou le clavier.

Le bios est constitué d'une mémoire (rom ou flash) placée sur la carte mère.

Notez que quasiment tous les bios étant maintenant des flash il est possible de les mettre à jour, voire de les remplacer. Et justement un projet existe pour remplacer les bios propriétaires par des bios libres (comme Max): coreboot de son ancien nom linuxbios.

Le bios est configuré pour choisir un périphérique sur lequel booter. En général c'est le premier disque dur, mais cela peut aussi être une clé usb ou un lecteur disquette. Il est même possible de choisir au moment du boot.

Sur le périphérique en question, et à l'exception du lecteur CD qui a son protocole (el torito), le bios charge le premier secteur (512 octets), le met en RAM, et le lance.

Notez que le "BIOS" est spécifique aux PC, d'autres architectures ont des firmware EFI (Apple) ou des OpenBoot (Sun).

Bootloader

Dans ce premier secteur se trouve le bootloader (grub, lilo, silo, syslinux, mbr dos ...).

Le bootloader est découpé en plusieurs morceaux à cause de la limite des 512 octets. Sa première activité est de réussir à se charger complètement.

Celui de windows est assez simpliste, mais sous linux on en trouve avec plein de fonctionnalités sympa.

Une fois qu'il est prêt, il lit sa configuration puis choisit un périphérique et une partition où lire le noyau et éventuellement un initrd. Et enfin il passe la main au noyau en lui donnant quelques paramètres.

Noyau

Le noyau est déjà chargé, il n'a "presque" plus rien à faire. Si ce n'est tout initialiser : les interruptions, le mode du processeur, les périphériques ...

Une fois qu'il a fini (ou même un peu avant) il monte la racine (/) à partir de de qui lui a été spécifié en ligne de commande.

Et enfin il lance init en lui passant quelques paramètres provenant de sa propre ligne de commande.

Si un initrd est chargé, il l'utilise comme racine et prend l'init s'y trouvant. Dans ce cas il ne cherche pas à monter la racine. Sinon GoTo init.

Initrd

Initrd est un intermédiaire qui a été rajouté au processus de boot pour permettre le chargement dynamique de driver ainsi que la configurations de certain éléments comme le réseau ou le NFS.

Initrd est un ancien nom. En pratique, c'est maintenant un initramfs qui est chargé (c'est la même chose mais en mieux, le premier est un block device et le second une archive) avant le montage de la racine. Celui-ci est monté à la racine. Son boulot, rendre la vraie racine accessible. NFS, driver manquant, LVM, toutes les raisons sont bonnes pour utiliser un initrd.

Et enfin celui-ci charge le vrai init pour l'étape suivante.

Init

Init est cette fois un vrai processus unix lancé par le noyau, et comme c'est le premier il a pour pid 1. Il prend sa configuration dans /etc/inittab. Dans sa configuration il y a quelques processus à lancer et à surveiller, il s'agit essentiellement des terminaux locaux.

Mais surtout il lance /etc/init.d/rc en lui passant en paramètre le runlevel dans lequel on est sensé fonctionner.

rc

rc est un simple script qui a pour pour seul objectif de lancer les différents démons qu'on trouve dans /etc/rcX.d où X est un runlevel

Et voila, à partir de là on peut considérer que le système est lancé.

Notez que sous certains systèmes comme ubuntu on trouve des outils comme upstart qui remplacent à la fois init et rc pour faire à peu près la même chose.

Si vous avez aimé, il y a aussi :

1. Sécurité du processus de boot
2. Mesurer le temps de boot
3. Course de niveaux

Sensors

Comment connaître les différentes températures à l'intérieur de votre machine ? Il y a des capteurs, donc il y a bien une information quelque part. Linux a tous les drivers nécessaires, mais pour ceux qui se sont essayé à regarder, c'est difficile de savoir qui sert à quoi. Heureusement, il y a lm-sensors pour venir à notre secours.

Pour avoir la liste de tous les capteurs disponibles sur la machine ainsi que les driver linux associés à charger, il existe une commande toute simple une fois le paquet lm-sensors installé :

$ sensors-detect

Cette commande scanne le matériel, vous pose une question ou deux et termine en vous listant les modules noyau à charger pour pouvoir obtenir les valeurs. Deux choses à faire :

# On charge le(s) module(s)
$ modprobe lemodule
# Et on automatise ça pour le prochain reboot
$ echo lemodule >> /etc/modules

Et voilà, il ne vous reste plus qu'à lire les valeurs. Pour cela, vous avez plusieurs outils :

# lecture simple des valeurs en mode texte
$ sensors 
# lecture avec interface graphique (ne marche pas chez moi)
$ xsensors

Ou les traditionnelles applet qu'on peut trouver sur gnome, kde, gkrellm, windowmaker ...

Hddtemp

Si vous voulez aussi lire la température de vos disque, il existe hddtemp du paquet éponyme. Celui-ci marche directement en ligne de commande :

# Il faut être root
$ hddtemp /dev/sda

Il existe aussi en mode démon, une fois installé, modifiez /etc/default/hddtemp (debian) et relancez le démon :

$ /etc/init.d/hddtemp restart
# vérifions qu'il marche
$ telnet localhost 7634

Et voila, il ne vous reste plus qu'a ajouter le disque dur dans l'applet.

Attention, l'applet de gnome nécessite d'être redémarrée pour détecter hddtemp.

Fancontrol

C'est la fête, passons maintenant aux ventilateurs. Vous avez déjà remarqué que vous pouvez avoir la vitesse de rotation dans vos applet. Ajoutez la au moins temporairement, ça peut vous être utile pour la suite.

En effet, nous n'allons pas seulement lire la vitesse des ventilateurs, mais nous allons la modifier. Pour ceux qui veulent regarder sous le capot, tout cela se trouve dans /sys/devices/platform/<sensordriver>/

Fancontrol est un paquet qui contient deux choses : un script permettant de régler automatiquement la vitesse de rotation des ventilateurs et un outil permettant de le configurer sans se forcer.

Pour utiliser fancontrol, il faut avoir des sensors opérationnels. Gardez de préférence un oeil sur votre applet pour éviter les débordements de température et pour savoir quoi répondre au script.

$ pwmconfig

Ce script vous pose plein de questions, arrête les ventilateurs, les relance, les ralentit ... dans le but de savoir quel ventilateur fait quoi, à quel capteur de température on peut l'associer et comment il marche. Sachez au passage que les processeurs acceptent des températures assez élevées, pas besoin de les forcer à 40°C, vous économiserez du bruit. Regardez la doc de votre fabricant si vous voulez un avis sérieux.

Le script pose 2 questions difficiles à comprendre

• MINSTART est la valeur de configuration au dessus de laquelle le ventilateur commence à tourner
• MINSTOP est la valeur de configuration au dessous de laquelle le ventilateur s'arrête de tourner

De façon générale, MINSTOP doit être supérieur à MINSTART (hystérésis), mais les valeurs sont assez proches. Vous pouvez aussi choisir ces valeurs par rapport à ce que vous entendez plutôt qu'à la vitesse réelle de rotation.

Une fois le tout configuré :

$ /etc/init.d/fancontrol start

Et écoutez ce silence en provenance de votre ventilateur. Surtout lorsque vous faites des activités peu intensives.

Si vous avez aimé, il y a aussi :

1. Exécution non simultanée de crons