Installations et comparaisons de diverses distributions de linux.

Plan d'action

• MBR et Grub VS Lilo (théorique)
• Sécurité sous grub
• Multi-boot CentOS, Debian
• RunLevels et séquence de démarrage
• D'autres tâches à effectuer.

MBR et Grub VS Lilo.

Lorsqu'on démarre un ordinateur, le premier code qui contrôle la machine c'est le code du BIOS qui réside dans une puce spéciale de la machine. Ce code recherche dans les disques de la machine celui qui contient deux octets spéciaux aux octets 510 et 511 du premier secteur du disque : 0xAA55. Ces deux octets indiquent que le disque contient un MBR valide. Ensuite, le BIOS charge le MBR à l'adresse 0x7c00 et passe le contrôle de la machine au mbr en déplaçant l'exécution à l'adresse 0x7c00 Le boot-loader (chargeur d'amorçage) lui inspecte la table des partitions et charge le Volume boot record de la partition active du disque. C'est ce qu'on appelle un amorçage chaîné : le bios charge le mbr qui charge le vbr qui peut à son tour charger un autre code d'amorçage plus spécialisé, mais surtout plus gros.

Comme le vbr présume tout comme le mbr qu'il a été chargé à l'adresse 0x7c00, la première tâche du mbr est généralement de se copier ailleur. L'image qui suit montre le code en hexadécimal du mbr ainsi qu'une décompilation partielle du code d'amorçage (les commandes hexdump, xxd ou hd peuvent être utilisées pour générer une telle sortie) :

Le MBR est réinstallé à chaque installation de Windows. Windows installe un nouveau code capable de charger son propre vbr, qui lui est capable d'amorcer correctement Windows. Le MBR tel que nous l'avons utilisé jusqu'à maintenant n'est capable d'amorcer qu'un seul système. Celui de partition active, pourvu que ce soit windows.

Linux possède ses propres bootloaders. L'un des plus anciens s'appelle LILO pour linux-loader et le plus populaire de nos jours s'appelle Grub qui en est à sa deuxième version (Grub 2.0), mais c'est souvent Grub1 qui est installé.

Ces codes d'amorçage ont la particularité de pouvoir amorcer plusieurs système d'exploitation à partir d'un même ordinateur et d'offrir ce choix dans un menu de manière assez conviviale. Voici une bonne introduction pour LILO et Grub1

LILO

Lilo est le plus ancien. Il s'installe soit directement dans le mbr pour le premier stage ou ailleur sur le disque. Dans ce deuxième cas, un code d'amorçage capable de charger LILO devra être écrit dans le MBR. LILO est statique ; c'est-à-dire qu'on prépare un fichier de configuration, généralement /etc/lilo.conf contenant les instructions pour préparer le mbr et qu'ensuite on installe lilo à l'aide de la commande /sbin/lilo -v -v. À chaque modification du fichier /etc/lilo.conf le mbr doit être réinstallé. Voici un exemple de fichier lilo.conf

Grub

Comme nous l'avons déjà mentionné, Grub existe essentiellement en deux versions, Grub et Grub2. Le CentOS que vous avez installé utilise Grub et Debian utilise Grub1.98 qui est une version beta en quelque sorte de Grub2. Grub 1 est beaucoup plus facile à utiliser que grub 2. Nous nous concentrerons donc sur grub1.

Tout comme lilo, Grub est configuré à l'aide d'un fichier de configuration (/boot/grub/grub.conf). Attention, Grub2 utilise d'autres fichiers. Contrairement à LILO, ce fichier est lu par Grub lors de l'amorçage. On peut donc le modifier sans réinstaller le mbr. De plus, Grub peut amorcer beaucoup plus de système d'exploitation car il sait lire les différends système de fichier, ce que LILO ne sait pas faire. Grub peut directement charger la plupart des systèmes linux et peut utiliser l'amorçage chaîné pour amorcer windows.

Voici un fichier grub.conf et des explications pour chaque ligne : Grub.

Une des grande force de grub c'est d'avoir un stage 1.5. Le stage 1.5 est chargé par le stage 1, qui réside dans le mbr. Cette étape de l'amorçage permet à grub de passer d'un mode de lecture du disque par secteur à un mode où grub est capable de lire des fichiers dans un système de fichiers. C'est ce stage qui charge le stage 2 qui amorce le système d'exploitation.

Sécurité sous grub

Pour cette section, travaillez avec une machine CentOS étant donnée qu'elle installe Grub et non Grub2.

Vérifiez que vous êtes capable sans aucun mot de passe d'amorcer le système en mode usager unique tel que démontré en classe. Dans ce cas vous êtes root. Vérifiez ceci. Ensuite, sécurisez votre machine. Pour grub vous n'avez qu'à ajouter single au bout de la ligne du kernel. Pour les plus avantureux, vous pouvez faire la même chose avec Grub2 en suivant les instructions ici

Sécurisez votre machine CentOS. Vous aurez besoin de la commande grub-md5-crypt

Avec le résultat de cette commande, modifiez votre fichier /boot/grub/grub.conf

Testez le résultat, assurez-vous qu'il vous faille entrer le mot de passe pour changer les paramètres d'amorçage.

Ne suivez pas ces instructions sur Debian, Debian utilise grub2.

Pour terminer, modifier le fichier grub.conf pour que votre machine s'amorce toujours en mode utilisateur unique.

Pour ceux qui s'ennuient, sécurisé grub2 sous Debian à l'aides des instructions sur ce site

Multi-boot CentOS, Debian

Procédez à l'installation d'un système multi-boot. Pour ce faire, créez un PC possédant deux disques durs. Le premier disque ayant 10GO et le second 8 GO. Ceci vous permettra de distinguer vos disques facilement durant l'installation.

Procédez à l'installation de centos sur le second disque.

Redémarrez ; votre machine ne sera pas fonctionnelle. C'est normal. Procédez ensuite à l'installation de votre machine Debian sur le premier disque. N'oubliez pas d'installer le boot-loader (Grub) à la fin de l'installation.

Vérifiez que vous êtes capable de charger les deux systèmes en tant que root sans entrer de mot de passe en suivant ces instructions : protéger grub2.

Pour ceux qui ont le temps, suivez ces instructions et configurez la protection par mot de passe chiffré en suivant les instructions sur le dernier site mentionné.

Petites tâches supplémentaires à accomplir.

• Sur votre machine multi-boot. Chargez debian puis montez la partition lisible de centos quelque part dans votre système tel que démontré en classe. Utilisez les commandes mount et fdisk. La commande man est toujours pratique.
• Listez en hexadécimal votre disque de centos que vous venez tout juste de monter. Assurez-vous qu'il soit monté en mode lecture uniquement.
• Pour ceux qui s'ennuient, ajoutez à une boîte linux (à partir de VirtualBox) le disque de l'un des pc windows que vous avez installé et listez en hexadécimal le contenue du disque pour voir le MBR. Vous devriez monter votre disque en mode lecture pour éviter d'abîmer votre pc.

RunLevels et séquence de démarrage

Un Runlevel est un état dans laquelle peut-être la machine. Dépendant du système auquel on a affaire, il peut y avoir de 3 à 10 RunLevel. Ce concept a été introduit dans le système Unix System V. À chaque RunLevel correspond en ensemble de daemon qui peuvent exister (donc un ensemble de service offert). Généralement, il y a au moins quatre RunLevels : Arrêt, Redémarrage, SingleUserMode et MultiUserMode. La capture suivante vient du fichier /etc/inittab sur Debian :

Remarquez qu'il y a plusieurs RunLevels pour multiUser. Voici une excellente introduction au processus de démarage des système Linux où le fichier inittab est expliqué ligne par ligne.

Ce fameux fichier inittab contient les informations reliées aux Runlevels et surtout au Runlevel dans lequel le système doit entrer par défaut. Sur certaines distribution linux, il indique au processus init où trouver les scripts de configuration pour un RunLevel donné. Pour chaque RunLevel, un certain nombre de script servant à tuer des processus doit être exécuté et un certain nombre de script servant à démarrer des processus doit être exécuté. C'est généralement dans le fichier /etc/inittab où l'on trouve cette information.

Pour voir quel daemon doivent être actif ou inactif pour un RunLevel donné on utilise la commande chkconfig --list sous Centos ou Redhat. Avec Debian et Ubuntu, il faut utiliser les commande rcconf ou sysv-rc-conf. Vous pouvez constater sur la capture d'écran suivante que le daemon sshd n'est activé que pour les RunLevels 2 à 5.

Si vous suivez la logique des scripts de démarrage à partir du fichier inittab vous verrez que tous les script de démarrage sont en fait des alias vers /etc/init.d. Vous ferez ceci cet après-midi.

D'autres tâches à effectuer.

À partir de Debian, vous aurez besoin du site suivant pour pouvoir lire vos messages dans le fichier /var/log/boot sur Debian.

Vous pouvez rediriger vos messages vers un autre fichier : echo "blablabla">/var/log/Simon.log. Dans ce cas, vous pourrez lire le résultat dans le fichier /var/log/Simon.log

• Allez lire le fichier /etc/inittab sur debian et sur Centos et comparez les.
• Ensuite, avec la commande sysv-rc-conf enlevez le service sshd pour le RunLevel 3, changez le RunLevel par défaut dans le fichier /etc/inittab/ et redémarrez pour tester vos nouveaux réglages.
• Rechangez le RunLevel par défaut pour 2 puis redémarrer. Dans un terminal, changez de Runlevel vers le niveau 3 en utilisant la command telinit ; regardez le man page pour telinit. Testez votre ssh ? Que se passe-t-il ?
• Ajoutez des messages dans vos script de démarrage pour les visualiser dans les fichiers de log de la machine. Par exemple, pour le networking, j'ai ajouté un message qui s'imprime lors du démarrage. On le voit à l'écran et on peut le voir dans le fichier /var/log/boot sur Debian.

• Sur CentOS, j'ai ajouté une ligne dans le fichier de démarrage qui m'indique tous les scripts qui seront exécutés par init. Vous pouvez naturellement faire ceci sur debian.


Ceux qui s'ennuient ou qui veulent se pratiquer peuvent refaire ces tâches sur centos et sur ubuntu. Les fichiers de log changent entre les différentes moutures de linux.