Je pense que c’est trop tôt pour que le RAID soit activé. Il faut au moins attendre la détection des disques, sinon le partitionneur.
Pourquoi as-tu besoin d’apt-get ?
Mon avis : ne cherche pas à chiffrer /boot lors de l’installation. Tu vas t’embêter pour rien, il vaut mieux le faire après.
apt et apt-get c’était pour avoir les commandes mdadm et lsblk par exemple mais je dois être à coté de la plaque
du coup en effet je me disais que j’allais recommencer et chiffrer /boot après mais je me dis que ce qui complique c’est la présence du RAID1 car dans l’article que je suis pour chiffrer /boot après install, l’auteur n’utilise pas de RAID1 soft en tous cas
Quoiqu’il en soit merci pour votre intérêt et je ne pense pas en rajouter aujourd’hui 
le temps de digérer https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html pour le mettre en application je pense que cela me prendra plus que l’apm 
Mon partitionnement sachant que sda et sdb sont des disques SATA qui ne contiendront pas le système
le départ du problème…
dans main (/dev/md126) je crée 3 LV pour / , /home et une swap
lsblk n’est pas disponible dans l’installateur. Pour mdadm, si tu ne peux pas attendre les étapes suivantes pour qu’il soit disponible tu peux exécuter
anna-install mdadm-udeb
Tu auras peut-être besoin d’installer le paquet md-modules-5.10.0-16-amd64-di (ajuster à la version du noyau de l’installateur) s’il ne l’est pas déjà. Et peut-être exécuter depmod ensuite pour que les modules soient utilisables avec modprobe.
Et cela complique d’autant plus lors de l’installation. Après l’installation, je ne vois pas trop pourquoi ça compliquerait, il devrait suffire d’adapter la procédure aux noms de périphériques utilisés. Mais je ne l’ai pas lue.
Et la touche finale, ce sera la mise en place de la redondance pour l’amorçage EFI. Je te souhaite bien du plaisir.
mauvaise idée, ce type d’installation c’est bien quand tu es un expert sinon tu t’engages dans un chemin dont tu ne verras pas la fin.
En fait, tu t’embêtes pour rien.
perso je fais une installation normale chifrée avec tous qui va bien sur un disque.
ensuite sur l’autre disque je créée le premier node du raid en lui specifiant que l’autre noeud est inactif.
Puis je déplace ce qui est sur le premier disque sur le deuxième disque (noeud 1 du raid)
Ensuite je definie le second noeud du raid, et je laisse faire le Raid pour synchroniser les deux noeud.
ne reste plus qu’a s’assurer que le bootloader pointe corectement
Certes c’est une méthode qui est à l’origine utilisée pour passer d’une machine sans raid à une machine en raid 1
Pour le EFI ca marche sns soucis, mais il te faut une grappe raid pour l’efi et une autre pour le reste
Là, nous sommes d’accord.
Là par contre, je trouve que ça complique inutilement. Je ne vois aucune raison de ne pas faire l’installation initiale directement en RAID.
Là non plus je ne suis pas d’accord. Une partition EFI en RAID c’est loin d’être sans souci pour une raison simple : l’EFI ne reconnaît pas le format RAID logiciel de Linux.
Oui aussi je viens de le faire vite fait sur une VM Virtualbox entre mon message precedent et celui-ci (VM non EFI par contre).
j’ai une machine EFI avec un disque 1To NVME et 1 To SSD qui est en raid et qui tourne très bien depuis au moins un an.
root@dsrvbull01:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931,5G 0 disk
├─sda1 8:1 0 285M 0 part
│ └─md0 9:0 0 284,9M 0 raid1 /boot/efi
└─sda2 8:2 0 931,2G 0 part
└─md1 9:1 0 931,1G 0 raid1
├─BULL01VG01-swap 253:0 0 7,4G 0 lvm [SWAP]
├─BULL01VG01-root 253:1 0 23,3G 0 lvm /
├─BULL01VG01-home 253:2 0 4,7G 0 lvm /home
├─BULL01VG01-var 253:3 0 43,3G 0 lvm /var
├─BULL01VG01-tmp 253:4 0 1,9G 0 lvm /tmp
├─BULL01VG01-varlog 253:5 0 14,3G 0 lvm /var/log
├─BULL01VG01-varlogaudit 253:6 0 4,7G 0 lvm /var/log/audit
└─BULL01VG01-vartmp 253:7 0 1,9G 0 lvm /var/tmp
nvme0n1 259:0 0 931,5G 0 disk
├─nvme0n1p1 259:1 0 285M 0 part
│ └─md0 9:0 0 284,9M 0 raid1 /boot/efi
└─nvme0n1p2 259:2 0 931,2G 0 part
└─md1 9:1 0 931,1G 0 raid1
├─BULL01VG01-swap 253:0 0 7,4G 0 lvm [SWAP]
├─BULL01VG01-root 253:1 0 23,3G 0 lvm /
├─BULL01VG01-home 253:2 0 4,7G 0 lvm /home
├─BULL01VG01-var 253:3 0 43,3G 0 lvm /var
├─BULL01VG01-tmp 253:4 0 1,9G 0 lvm /tmp
├─BULL01VG01-varlog 253:5 0 14,3G 0 lvm /var/log
├─BULL01VG01-varlogaudit 253:6 0 4,7G 0 lvm /var/log/audit
└─BULL01VG01-vartmp 253:7 0 1,9G 0 lvm /var/tmp
Ben je ne sais pas comment au faire au plus simple, enfin je ne savais pas merci pour les partages d’infos
Je veux absolument pouvoir chiffrer /boot car un admin d’un ancien boulot le seul où 80% du parc était sous GNU/Linux (postes de travail et serveurs) et je l’ai lu dans un post sur debian-fr , disaient que c’est le seul moyen de rendre la machine totalement secure face à un accès physique. Je ne parle pas d’un « piratage » par le réseau machine allumée comme on n’a pas pu me « vanter le manque d’intérêt » de chiffrer un serveur.
double moi qui me disait je devrais tester sur une VM… mais je ne suis pas sûr de pouvoir le faire en 30min
donc sur ta machine /boot est chiffrée dans le RAID principal et avec une autre grappe RAID pour /boot/efi ? non chiffrée?
le fait de vouloir chiffrer /boot? ou la méthode pour y arriver?
Non tu ne peux pas avoir un /boot chiffré sur une machine EFI à cause de l’EFI
Le tuto que tu as pris 
Je ne conteste pas que ça peut marcher (je l’ai fait aussi) mais seulement que c’est « sans souci ».
Tu as mis /boot/efi dans un ensemble RAID. Cela pose deux problèmes :
Je vais te décevoir : ce n’est ni nécessaire ni suffisant. N’oublie pas que GRUB lui-même qui se trouve dans la partition EFI ne peut pas être chiffré. On peut donc lui faire charger un autre noyau (qui doit être signé si le secure boot est activé) ou initramfs (non vérifié par même avec le secure boot).
Je m’apprêtais à écrire quand une notif m’a signalé ta réponse 
Je me disais que j’allais me lancer dans l’install avec boot legacy mais finalement au niveau que je recherche, /boot chiffré ou non c’est la même car sans /boot chiffré j’y étais arrivé
là où je me suis mis dans le pétrin c’est lorsque j’ai voulu ajouter au démarrage le montage du 3e RAID qui ne sert que de stockage sans OS qui lui aussi est chiffré
je veux être sûr qu’à ma mort on ne retrouvera pas mes sex-tape sur mon serveur 
Plaisanterie mise à part
Mon objectif est de transférer mon actuel nextcloud qui est sur une autre machine qui n’a pas la même config que celle-ci et sur laquelle je me suis contenté d’installer proxmox et chiffrer les VM mais c’est la croix et la bannière à chaque nécessité de reboot d’une VM (pb de clavier US-FR notamment)
je voulais monter d’un cran la sécurité ou la protection de mes données et me faciliter la vie sur le long terme…
en fin de compte retour à la case départ mais cette fois sans oublier crypttab au moment de l’ ajout de mon espace de « datas » pour le montage au boot.
Merci à vous 
La sécurité implique de se compliquer la vie, on ne peut pas la simplifier avec.
Le chiffrage d’un disque c’est uniquement pour le cas où quelqu’un récupère le disque. Çà n’a pas d’impact sur l’accès distant.
Personnellement les seules machines chiffrées sont des VM qui ne sont jamais online. Je les allume quand j’en ai besoin je les éteint ensuite. Donc quelqu’un ayant accès à celle-ci devra d’abord avoir accès au Host, ensuite il devra pouvoir dechiffrer et c’est là que son problème commence, il n’aura pas le mot de passe qui fait plus de 20 caractères. De plus la machine n’etant pas fonctionnellement necessaire d’etre accessible à distance, il ne pourra pas y acceder à distance non plus.
J’ajouterais que pour sécuriser vraiment cela necessite du matériel, comme des équivalent des puces titan sur les smartphone.
En effet ça ne fait pas de différence vis-à-vis du chiffrement. Par contre ça simplifie grandement la redondance de l’amorçage puisqu’il est possible de configurer grub-pc pour installer le chargeur dans le MBR de chaque disque alors que grub-efi-amd64 n’a pas d’option équivalente pour installer le chargeur dans plusieurs partitions EFI.
c’est vrai, là je pensais au fait de devoir déchiffrer chaque VM face à déchiffrer le disque du serveur une bonne fois pour toute
Oui j’en ai tout à fait conscience et comme il s’agit d’un serveur quelque part en France, je trouvais pertinent de chiffrer les disques (mode paranoïd)
Merci pour l’info car je ne le savais pas c’est une option que j’envisageais, cela va m’éviter encore de reprendre à zéro quand je m’en serai rendu compte plus tard…
Heureusement j’ai fait un break hier soir et rien réinstallé
Bonjour
Je reviens d’abord remercier pour l’aide qui m’a été apportée pour arriver à mes fins et continuer l’histoire 
après un petit break de qq jours, j’ai repris là où j’en étais (à savoir au point de départ)…
J’ai refait l’installation en legacy boot, grappe soft RAID1 pour /boot et une autre grappe soft RAID1 chiffrée qui contient les volumes LVM qui m’intéressent.
J’ai dû créer une partition bios-grub de 1Mo, la table de partition des disques étant GPT et je me demandais s’il y avait une utilité à avoir une partition EFI? Car elle ne devrait servir que si le serveur boot en EFI!?
Je m’attaque au montage lors du boot d’une autre partition chiffrée et en soft RAID1 mais j’ai l’impression qu’il faut passer par un fichier si on utilise la passphrase. Il n’est pas possible de saisir cette passphrase au boot comme pour la partition système, sachant que les deux passphrases sont différentes?
Une dernière question, sur les KVM ip c’est la galère pour le clavier lorsque notre config est en français sur le pc « qui prend la main ».
Comment faites-vous à part prendre un clavier US?
Merci d’avance.
As-tu essayé de changer la configuration du clavier
apt update & apt install keyboard-configuration
Puis exécuter la commande suivante
dpkg-reconfigure keyboard-configurationUne sur chaque disque, avec installation de GRUB dans le MBR des deux disques pour assurer la redondance de l’amorçage ?
Une partition EFI (une par disque pour un amorçage redondant, mais c’est une autre histoire) ne sert que pour l’amorçage EFI, mais l’avoir en réserve peut être utile dans l’éventualité où il faudrait passer l’amorçage en mode EFI, par exemple pour bénéficier du secure boot ou je ne sais quelle autre fonctionnalité, ou s’il fallait remplacer la carte mère par un modèle qui ne supporte pas l’amorçage legacy.
Ça dépend de ce qu’on met dans le 3e champ (key file) de /etc/crypttab. Avec none, la passphrase est demandée interactivement lors de l’activation du volume chiffré.
Si plymouth est installé et si les deux volumes chiffrés ont la même passphrase, alors elle ne sera demandée qu’une fois.
Quitte à paraître idiot, tu parles de la config du clavier du serveur?
Seule la redondance de grub n’est pas encore faite, c’est sur la todo…
Merci pour cette source de connaissance
J’ai testé avec none, la passphrase est demandée mais je passe systématiquement sur le mode de secours du coup je l’ai mis en place avec fichier.
Je pense que la config clavier IPMI y est pour qqchose, j’y reviendrai
Comment fais-tu pour taper la passphrase du volume principal ?
Là je dois mon salut au dieu du coup de bol, j’ai activé une deuxième config clavier sur un PC sous windows à la maison que je passe en anglais US et en testant la saisie dans le champs login au démarrage du serveur, je me suis rendu compte que la 1ère passphrase ne comporte que des caractères qui passe et en français et en anglais.
J’ai pensé à changer la passphrase mais ce n’est pas vraiment une solution…
Si, ça peut être une solution. Il faut seulement rallonger la passphrase pour qu’elle soit aussi robuste. Ça n’a guère de sens de mettre une passphrase « faible » pour le volume principal et une passphrase « forte » pour le volume secondaire si cette dernière est stockée dans un fichier du volume principal.