Pourquoi ? Pourquoi avoir recours à une telle gestion des disques sur notre serveur/poste de travail. Tout simplement car un collègue m’a récemment demandé conseil sur l’infrastructure informatique à mettre en place pour la création d’une TPE/petite-PME. Je lui ai donc répondu que les rats quittaient le navire, que de la part de … ça ne m’aurait pas étonné, mais toi, toi ! Disparais céans ou je te flagelle à coup de RJ45, fumier. Il a répliqué qu’il s’agissait d’un ami à lui qui heu, voulait heu, enfin tu vois, se lancer dans une activité heu, dans le tertiaire, voilà c’est ça, le tertiaire. Pleinement soulagé et rassuré quant à la loyauté et la droiture du collègue, je me confondais en excuse et lui promettais de réfléchir rapidement à la question, d’autant que son ami semblait pressé. Le sujet étant vaste et néanmoins bougrement intéressant, je m’arrête dans cet article à la problématique du stockage sur un serveur GNU/Linux, nul besoin d’un Windows pour cela, le but étant ici d’allier fiabilité (RAID1), flexibilité (LVM2) et sécurité (chiffrement LUKS).
Je précise d’emblée aux esprits chagrins que le but ici n’est pas de discourir sur la pertinence d’une solution donnée par rapport à une autre (RAID1 vs RAID5, NAS vs serveur multi-rôles, etc). L’idée est uniquement de détailler la procédure de partitionnement (même si le terme est un poil galvaudé) lors de l’installation de l’OS car contre toute attente, ce fut un peu laborieux. Je me heurtais systématiquement à un message d’erreur indiquant que GRUB ne pouvait s’installer sur /dev/sda (ni même sur /dev/sdb ou encore hd0). Soupçonnant une quelconque erreur dans ma méthode, j’ai testé différentes procédures (RAID1 + LVM, RAID1 + Chiffrement global, LVM + Chiffrement global et même RAID1 + LVM + Chiffrement séparé de chaque volume logique) sans le moindre problème. Ce n’est qu’en recommençant une n-ième fois que je me suis finalement rendu compte que la configuration de la partition /boot disparaissait au cours de la procédure…
Pré-requis :
- Un serveur GNU/Linux (ici Debian Squeeze 64 bits)
- 2 disques durs de même capacité (ici 8,6 Gio)
Conventions :
- prompt : # commande : exécuter la commande sous le compte root ou précédée de la commande « sudo »
- prompt : $ commande : exécuter la commande sous le compte utilisateur
En avant pour la visité guidée (je n’ai pas lésiné sur les captures d’écran, je vous préviens). Notez que les captures suivantes ont été réalisée sur une machines virtuelle KVM sous Proxmox mais ça ne change rien à l’affaire.
- Choisir le partitionnement manuel et créer au début de chaque disque une partition primaire de 256 Mio qui aura comme point de montage /boot. La partition de démarrage ne pouvant être chiffrée, on la traite à part.
- Configurer ces 2 partitions en tant que volumes physiques pour RAID, valider les changements puis configurer le RAID logiciel. Créer un volume multi-disques RAID1 de 2 disques, sans disque de secours, puis sélectionner les 2 partitions des 256 Mio. Faire de même avec les 2 partitions restantes et valider la configuration du RAID1.
- Sélectionner le volume RAID1 de 256 Mio et le formater en Ext3 avec /boot comme point de montage :
- Chiffrer la partition RAID1 de 8,3 Gio, rien de spécial à signaler ici, il suffit de suivre les captures d’écran. Notez qu’il faut bien sûr accepter d’écrire des données aléatoires sur tous les secteurs de la partition mais que cela peut prendre beaucoup de temps, en fonction de la taille de cette partition. On remarquera que sur la première capture d’écran ci-dessous, la partition RAID1 de 256 Mio est bien configurée avec comme point de montage /boot.
- Après le chiffrement de la partition de 8,3 Gio, on constate sur la première capture d’écran ci-dessous que la partition RAID1 de 256 Mio n’a plus de point de montage (il faudra donc penser à reconfigurer cette partition avant de poursuivre l’installation de l’OS sous peine de se retrouver avec un chargeur d’amorçage incapable de s’installer correctement). On passe maintenant à la configuration des volumes logiques. Après avoir créé un groupe de volume logique (VG) dans la partition chiffrée, créer les volumes logiques désirés (ici vg-root, vg-swap et vg-home) et terminer la procédure.
- Configurer le formatage et le point de montage de chaque volume logique :
- Reconfigurer le point de montage (/boot) de la partition RAID1 de 256 Mio et finir la procédure de configuration des disques :
- Une fois l’installation achevée et le système redémarré, il ne reste plus qu’à installer GRUB2 sur /dev/sdb (il s’installe sur /dev/sda par défaut) afin de pouvoir démarrer sur les 2 disques :
# grub-install "/dev/sdb" |
Vérifier que Grub est bien installé sur les 2 disques en débranchant chaque disque alternativement et en démarrant le système. That’s all folks !
Chargement des tweets
Ma liste de flux RSS Netvibes
Ma liste de flux RSS RSSLounge
Ma liste de podcasts pour Miro
Mon Shaarli
http://www.laquadrature.net/
https://packliberte.org/
13 commentaires
Passer au formulaire de commentaire ↓
PsyGNUx
16 novembre 2011 à 14 h 48 min (UTC 1) Lier vers ce commentaire
Bonjour DocGreen, d’abord félicitations pour cette article clair et détaillé. Comme toi je mets en place sur mon poste de travail du RAID1 + LUKS + LVM . Mais a l’époque ou j’ai commencé à faire ça l’installateur de Debian ne permettait pas de gérer le cryptage, donc je faisais ça à la main ainsi que le LVM. La particularité est que je lisais sur plusieurs tuto que le kernel ne pouvait pas « fonctionner » sur une partition mirroré (RAID), donc j’ai toujours laissé les 1ers partitions de chaque disque (sda1 et sdb1) tel quel, en copiant le MBR de sda sur sdb avec la commande dd, et en parametrant un rsync dans le crontab pour synchroniser leurs données ttes les 5min (sachant que /boot ne change pas très souvent en soi). Bref, je suis étonné et content à la fois de voir dans ton article que le kernel peut apparemment fonctionner sur une partition RAID car ça m’évitera quelques manipulations dans mes futurs installations. Aurais-tu une idée du pourquoi j’ai pu avoir l’occasion de lire cette incompatibilité entre kernel et RAID auparavant ? Librement
DocGreen
16 novembre 2011 à 18 h 38 min (UTC 1) Lier vers ce commentaire
Bonjour et merci pour ton commentaire.
C’est assez drôle parce que j’avais lu pour ma part que Debian Lenny (et GNU/Linux en général) maîtrisait très bien le RAID1 logiciel. Un des serveurs que j’administre est toujours sous Debian Lenny et fonctionne parfaitement bien en RAID1. A l’époque j’avais consulté pas mal de tutoriels et celui-ci montrait que l’usage de RAID1 + LUKS + LVM était possible même si c’était assez laborieux à mettre en place. Pour les versions antérieures, je n’ai pas d’infos.
Le but de l’article est d’avoir une méthode claire, qui signale l’écrasement potentiel de la configuration de /boot (potentiel, car cela n’arrive pas lorsqu’on configure cette partition en dernier) et qui fonctionne.
J’ai aussi souri à la lecture de ta technique de réplication de /boot (dd + rsync), ingénieux ! Heureusement qu’on est plus obligé de passer par là aujourd’hui…
La seule « faiblesse » de sécurité de cette méthode concerne la partition /boot qui ne peut être chiffrée, il reviendrait alors au BIOS/UEFI de la déchiffrer pour continuer la procédure de démarrage, il me semble avoir lu quelque chose là dessus il y a plusieurs mois mais rien depuis…
Je serai curieux de connaître la version de Debian que tu utilisais.
Aleks2a
4 février 2012 à 15 h 56 min (UTC 1) Lier vers ce commentaire
Re-Salut DocGreen,
J’ai bien suivi tes conseils pour la gestion des espaces et je t’en remercie. J’ai par contre un blocage à la fin de l’installation de ma distribution, au niveau de Grub. Pas moyen de l’installer dans /dev/sda : j’ai le message d’erreur suivant « Impossible d’installer Grub dans /dev/sda
Dans les logs de l’installation, j’ai ces lignes :
/usr/sbin/grub-setup : warn this GPT partition has no boot partition; embedding won’t be possible
/usr/sbin/grub-setup : error : embedding is not possible, but this is required when the root device is on a raid array or LVM volume
/usr/sbin/grub-setup : Running grub-install –no-floppy –force « /dev/sda » failed.
Aurais-tu une idée ?
En attendant, je vais tenter un installation de Grub sur chacun des disques avec le mode Rescue du CD et en débranchant un à un les disques durs (J’ai trouvé l’info ici >> http://www.debian-fr.org/installation-en-raid1-t36125.html#p364542)
Je reviens après ici en cas de réponse positive ou négative …
@+
Aleks.
DocGreen
4 février 2012 à 22 h 27 min (UTC 1) Lier vers ce commentaire
Salut,
je pense tu eu as le même problème que moi à savoir que la configuration de la partition /boot « sautait » lors de la configuration des autres partitions.
Vérifie donc que /boot est bien configuré à la fin de la procédure de partitionnement (comme sur les 3 avant-derniers screenshots).
Doc.
Aleks2a
8 février 2012 à 10 h 49 min (UTC 1) Lier vers ce commentaire
Salut,
Petit retour d’expérience : après quelques jours passés (assez laborieux =)) pour trouver d’où venait ce problème d’installation de Grub, j’ai découvert sur d’autres forums que ce problème apparaissait sur des cartes mères équipées d’un bios EFI (mon cas).
Pour contourner ce problème, il suffit de créer une nouvelle partition en fat32 d’une centaine de Mo avec le drapeau « bios-grub » au début de chaque disque (ne surtout pas toucher ou monter cette partition depuis le CD d’install de Debian) . Par contre, pour créer ces partitions, obligation d’utiliser un liveCD Gparted car c’est impossible de créer ce fameux drapeau avec partman du cd d’installation de Debian.
Ensuite il suffit de créer les autre partitions avec le cd d’install de Debian et à la fin, au moment où l’assistant propose d’installer Grub automatiquement, il faut répondre « non » et choisir manuellement l’emplacement : /dev/sda. Je sais que par défaut il l’installe dans cet emplacement mais dès que je l’utilise, ça me fait sauter la 1ere partition bios-grub créée au début).
Ensuite, installer Grub dans /dev/sdb comme indiqué dans le tuto
Ça marche enfin ^^
Aleks..
DocGreen
8 février 2012 à 11 h 02 min (UTC 1) Lier vers ce commentaire
salut,
content que tu ais enfin finalisé ton installation !
Je ne connaissais pas le problème des cartes-mère EFI, merci de ton retour d’expérience, ça pourra aider des personnes dans le même cas.
A l’occasion, je testerai la manip et compléterai le tuto. Espérons que tout ça sera pris en charge par la future version de Debian.
Doc
Aleks2a
10 février 2012 à 11 h 12 min (UTC 1) Lier vers ce commentaire
Re-salut,
J’ai parlé un peu trop vite… après avoir testé si le 2e disque dur bootait bien si le premier est débranché, Grub bug et reboot indéfiniment au moment où il charge.
J’ai trouvé des infos sur internet qui disent de modifier la configuration de Grub et notamment ajouter/modifier
insmod raid
set root=(md0)
(source http://www.developpez.net/forums/d1147703/systemes/linux/systeme/probleme-grub2-debian-squeeze-raid-1-a/#post6328242)
J’ai donc ajouté ces lignes dans /etc/default/grub (source https://wiki.archlinux.org/index.php/GRUB2#Raid)
Mais quand je fais un update-grub, j’ai un message d’erreur en retour : « insmod: can’t read ‘raid’: No such file or directory »
Je pense que je ne dois pas modifier au bon endroit (surement une erreur de débutant).
Aurais-tu une piste à explorer ?
Aleks
Aleks2a
10 février 2012 à 13 h 00 min (UTC 1) Lier vers ce commentaire
Bon ben je viens tout juste de trouver pourquoi ….
Rien avoir avec ce que j’ai écris précédemment, il suffit d’activer GRUB_TERMINAL=console dans /etc/default/grub
(source http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626853#20)
J’ai refait un update-grub derrière et maintenant chacun de mes disques boot
pas2l
28 février 2013 à 12 h 39 min (UTC 1) Lier vers ce commentaire
Bonjour,
Même problème Aleks2a, impossible d’installer grub sur /dev/sda lors de l’install de debian.
J’ai créé une partition de 100M au début de chaque disque avec Gparted, en fat32 avec le drapeau « bios-grub ». Plus d’erreur lors de l’install au moment d’installer grub sur /dev/sda. Par contre le système ne trouve pas de disque bootable. J’ai ensuite re-vérifié avec GParted, et les partitions sont bien toujours là, avec le drapeau.
Auriez-vous une piste à explorer ?
Aleks2a
28 février 2013 à 15 h 07 min (UTC 1) Lier vers ce commentaire
Hello !
Essais de débrancher un de tes disques dur pour arriver à booter sur l’un ou l’autre. Une fois ton serveur booté, tu identifies le disque dur surlequel tu arrives à booter, tu éteints tout et tu branches en master le disque dur qui boote, et l’autre en slave.
Normalement, si tu redémarres, tu devrais arriver à booter (y aura juste ton raid à resynchroniser que tu pourras faire plus tard). Il te reste plus qu’à installer Grub en ligne de commande sur le disque dur qui boot pas.
Ensuite, test le boot de chacun des tes disques en les débranchant.
En espérant t’avoir aidé.
pas2l
28 février 2013 à 16 h 12 min (UTC 1) Lier vers ce commentaire
Merci pour cette réponse, mais malheureusement j’avais bien essayé de booter sur chaque disque et rien à faire, ça ne démarre pas. Aucun des deux disque ne semble bootable. Je vais supprimer toute mes partitions avec GParted et recommencer depuis le début. J’ai peut-être loupé quelque chose quelque part.
Je reviendrai donner le résultat ici.
pas2l
1 mars 2013 à 16 h 10 min (UTC 1) Lier vers ce commentaire
Après de nombreuses recherches, j’ai trouvé d’où venait le problème.
Les deux disques en RAID ont des capacités de 3TB, il fallait donc activer dans le bios, section boot, l’option « Enable UEFI », ET désactiver tous les autres périphériques sur lesquels booter (USB, optique, LAN…).
Il s’agit d’une carte mère Intel, je ne sais pas si les autres cartes mères ont ce type de comportement avec des disques > 2TB, mais en tout cas, maintenant ca fonctionne chez moi.
En tout cas, merci pour cet article très clair et les commentaires bien utiles
DocGreen
10 février 2012 à 14 h 38 min (UTC 1) Lier vers ce commentaire
Tu résous les problèmes plus rapidement que je lis tes commentaires