Bonjour Nal,
Je me souviens, lorsque la première fois j'ai entendu parler de LVM, grâce à ce journal, d'avoir été ébahi par tant de beauté technologique. Je me suis alors promis, qu'un jour, quand je serai grand (beau et fort), j'opterai pour une telle solution. C'était il y a déjà presque trois années, et depuis, j'ai vieilli sans grandir, et je n'ai toujours rien fait de tel.
Le temps passe, vite, et entre temps je me suis tant1 intéressé à la vie privée et à l'utilité du chiffrement des disques grâce à LUKS (ou plus particulièrement dm-crypt).
Maintenant que j'ai envie de mettre en pratique toutes ces belles années à bander sur les nouvelles technologies, tout en n'en branlant pas une, je me rends compte que ce n'est pas forcement évident de lier la beauté de la gestion des disques logiques avec l'utilité du chiffrement.
Avec une méthode de type LVM on LUKS (la plus couramment utilisée), on perd la possibilité d'étendre ses volumes logiques sur plusieurs disques ; alors qu'avec une méthode de type LUKS on LVM, on chiffre séparément chaque disque logique, ce qui n'est pas le plus pratique. De plus cette méthode semble peu utilisée, et causerait d'autres désagréments (impossible d'hiberner ?).
Vous, quelles solutions utilisez-vous pour vous affranchir du hardware en alliant la sureté de vos données ?
[1] Temps temps tant, sur un air de Beethoven.
# Debian Wheezy / Hibernation: Retour d'expérience
Posté par Sylvain Briole (site web personnel) . Évalué à 10.
J'utilise la méthode LUKS sur LVM sur un portable Lenovo (X220T) qui tourne sous Debian Wheezy.
Pas rencontré de problème particulier avec l'hibernation (commande s2disk).
Pour éviter d'avoir à taper x fois mon mot de passe pour les différentes partitions, j'utilise une clef USB et ai suivi les conseils suivants:
- http://wejn.org/how-to-make-passwordless-cryptsetup.html
- http://www.hermann-uwe.de/blog/howto-disk-encryption-with-dm-crypt-luks-and-debian (site non dispo' alors que j'écris ces lignes)
[^] # Re: Debian Wheezy / Hibernation: Retour d'expérience
Posté par Aeris (site web personnel) . Évalué à 6.
Je préfère ma méthode : https://blog.imirhil.fr/2014/04/29/dechiffrer-plusieurs-luks.html
Elle n’est pas passwordless mais n’en nécessite qu’un seul pour déverrouiller tous les disques et elle a l’avantage de ne pas avoir la clef de déverrouillage en clair sur un support, même USB :P
[^] # Re: Debian Wheezy / Hibernation: Retour d'expérience
Posté par Thomas Debesse (site web personnel) . Évalué à 4.
Les systèmes modernes¹ permettent de déchiffrer tous les volumes qui utilisent la même passphrase en une seule fois, sans configuration. Lors de la phase initramfs, le mot de passe est demandé pour le premier volume, et lorsque vient le tour des volumes suivants d’être déchiffrés, ce mot de passe est essayé au cas où avant de le demander à l’utilisateur, s’ils contiennent tous des partitions à monter automatiquement au démarrage et décrites par
/etc/fstab.¹Genre une Ubuntu avec Systemd et Plymouth, ça marche au déballage sans configuration.
La seule chose qui demande une petite configuration (une ligne dans un fichier de conf), c’est si
/bootest dans le volume chiffré, et dans ce cas là on y coupe pas, il faut taper deux fois le mot de passe, une fois pour GRUB, une autre fois pour Linux, mais après, 10, 20, 30 volumes chiffrés, il ne redemande pas.ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Debian Wheezy / Hibernation: Retour d'expérience
Posté par Aeris (site web personnel) . Évalué à 3.
Personnellement, je préfère éviter de chiffrer mes disques principaux avec une phrase de passe. J’utilise exclusivement un fichier de clef de 512 octets. Ça évite un éventuel bruteforce de ma passphrase :P
La passphrase se trouve uniquement dans le mini-conteneur LUKS contenant la partition de clef, qui sert ensuite à déchiffrer tout le reste.
# Les deux
Posté par GNUtoo . Évalué à 10.
J'utilise "LVM on LUKS" quand c'est pas possible d'étendre les disques, comme par exemple sur un ordinateur portable.
Quand c'est possible j'utilise LVM on LUKS on LVM, içi on peut étendre les disques, par contre faut vraiment savoir ce qu'on fait car on peut vite etre perdu.
J'ai aussi tendence a ne pas avoir de partition /boot séparée, en clair.
Il est possible de le faire grace a GRUB qui suporte LVM et LUKS.
- Comme j'ai une version libre de coreboot, GRUB est dans la puce flash du BIOS.
- Dans le cas d'un BIOS, tu peux configurer GRUB pour avoir LVM et LUKS dans le MBR.
- Dans le cas d'un fimrware de boot UEFI ou EFI, je sait pas. J'ai pas encore essayé tianocore avec coreboot. A noter que maintenant le driver FAT libéré est upstream dans tianocore.
Denis.
# LVM on LUKS on RAID
Posté par gouttegd (site web personnel) . Évalué à 10.
Un schéma vaut sans doute mieux qu’on long discours :
(La configuration initiale ne comportait que les deux disques de 320 Go, les disques de 1 To ont été rajoutés a posteriori — quand j’ai commencé à manquer de place sur
/dev/md1. J’aurais peut-être organisé ça différemment si j’avais disposé des quatre disques depuis le début…)[^] # Re: LVM on LUKS on RAID
Posté par Thomas Debesse (site web personnel) . Évalué à 7.
Ah tiens, c’est pas mal !
Sur mon ordinateur portable ma configuration est celle-ci :
J’hésite à faire un volume étendu entre les deux SSD (marre des liens symboliques !) mais ça augmente la probabilité de panne, déjà qu’il n’y a pas de miroir…
Sur mon ordinateur fixe, j’ai actuellement ceci (ça va changer) :
La partition “bios” c’est une petite partition de 4M nécessaire aux systèmes de démarrage non-EFI de démarrer avec une séquence de démarrage traditionnelle àla BIOS sur une partition GPT.
Le disque tout à droite est un disque de sauvegarde, il y en a plusieurs en fait qui sont des clones exacts, je les fais tourner, ils ont un tiroir hotplug dédié, et quand l’un est dans l’ordinateur pour les sauvegardes quotidiennes (le disque est électriquement éteint en dehors du moment de sauvegarde), les autres sont à plusieurs kilomètres de là. Le disque de sauvegarde est un disque SMR : les données sont écrites par couche, ce qui augmente la densité mais réduit sérieusement les accès en écriture, inutilisable pour une reconstruction RAID, déconseillé pour travailler dessus, impeccable pour des sauvegardes, c’est plus pratique qu’une bande tout de même.
La configuration RAID/LUKS/LVM est “un peu” overkill parce qu’il y a beaucoup de passif… certains disques qui servaient à autre chose avant on été intégrés tels quels, et par exemple dans certains cas le LVM est resté alors qu’il ne reste plus qu’un volume logique dedans (il fut un temps ou mon premier RAID 4T contenait / et /home, ça faisait sens), beaucoup de couches LVM inutiles donc, et puis le bcache qui se prend deux fois la crypto c’est inutile. Et puis surtout j’en ai marre de faire des liens symboliques entre mes deux raids, aussi.
Pour les RAID, je sais qu’on peut faire ça directement sur les disques sans partitionnement, mais le partitionnement GPT permet d’utiliser des label de partitions et ça c’est hyper pratique, je nomme tout à tous les étages : partition, volumes logiques, système de fichiers…
À propos des mots de passe, vu que /boot est dans un volume LUKS, je dois taper le mot de passe (en qwerty !) pour déverrouiller grub, puis le mot de passe LUKS lors de la phase de montage de l’initramfs, puis mon mot de passe d’ouverture de session (qui déverrouille le trousseau puisque c’est le même). Ce qui fait trois mot de passe pour arriver au bureau.
Puisque mes 4 LUKS actuels (hors sauvegarde) ont le même mot de passe, lorsque l’initramfs me demande le mot de passe, il ne me le demande qu’une fois, et pas 4 fois (ouf) !
Oui, lorsque le disque de sauvegarde est dans son tiroir, le système voit une surface disque de 24,256 TB, pour 128G de système, 8T de données, 64G de cache et 8T de sauvegarde.
Dès que j’ai un peu de temps je transforme cela ainsi :
Pour info mon bcache est en RAID1 car je me réserve la possibilité de le configurer en writeback pour les écritures séquentielles, et parce que c’est le SPOF de mon système, ce serait bien entendu bien plus performant en RAID0 mais l’actuel me va très bien, si je vais transformer mon système en RAID0 c’est pour avoir un seule volume
/homede 8T et pour en finir avec les montagesbindet les liens symboliques, les performances sont déjà très bonnes : mes disques de 4T sont des Constellation ES 3 à 7200tr/min avec 128M de cache, ça envoie du pâté, en fait chacun de ces disques 4T est plus rapide que le SSD 128G qui me sert pour le système et qui est un SSD SATA connu pour être très lent mais pas cher (on me l’a offert en échange d’un service). Les SSD pour le bcache sont des M.2 sur une carte PCIe. Ce ne sont pas des foudres mais c’est sympa, je pourrais toujours les remplacer par plus rapide, et ils n’ont pas besoin d’être très gros.Je ne compte pas utiliser les fonctionnalités de RAID de btrfs, je préfère être frileux, idem pour les fonctionnalités de cache de LVM.
Mon
/est toujours en ext4 parce que j’ai pas encore sauté le pas, en fait j’ai mis btrfs sur mes/homedans l’espoir de dédupliquer (mais je n’ai pas encore utilisé cette fonctionnalité, j’y vais doucement).Mon swap est complètement inutile, il n’est jamais utilisé, il y a assez de ram pour ne pas en avoir besoin, mais il est là par acquis de conscience.
Je compte faire des journaux-tuto quand je referai tout cela. :-)
ce commentaire est sous licence cc by 4 et précédentes
# LUKS on LVM
Posté par Aeris (site web personnel) . Évalué à 1.
Hum, je n’ai jamais tenté, mais je ne vois pas en quoi ça serait génant.
Une fois ouvert, le conteneur LVM sera vu comme un périphérique bloc (dans /dev/mapper) et me semble du coup totalement utilisable comme volume physique LVM normal, donc y compris pour extension d’un volume logique sur plusieurs disques…
[^] # Re: LUKS on LVM
Posté par Aeris (site web personnel) . Évalué à 3. Dernière modification le 16 août 2016 à 11:43.
Alors je viens de tester, je ne vois pas l’impossibilité ou alors je ne l’ai pas comprise…
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 8G 0 disk
├─sda1 8:1 0 94M 0 part /boot
└─sda2 8:2 0 7,9G 0 part
└─sda2_crypt 254:0 0 7,9G 0 crypt
└─vg-lv 254:2 0 15,9G 0 lvm /
sdb 8:16 0 8G 0 disk
└─sdb1 8:17 0 8G 0 part
└─sdb1_crypt 254:1 0 8G 0 crypt
└─vg-lv 254:2 0 15,9G 0 lvm /
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.