LINUX.ORG.RU

Муки разметки

 ,


0

1

Хочу установить систему, используя полное шифрование дисков. Моя текущая разметка выглядит следующим образом:

/dev/sda1    boot
/dev/sda2    /
/dev/sda3    home
/dev/sdb1    storage

Это SSD, на котором настроены ссылки для больших файлов на HDD.

Сначала я хотел использовать такую же разметку, но подумал, что это плохая идея, потому видно, где boot, /, home, что может как-то помочь злоумышленику. В идеале, я хочу получить что-то вроде:

/dev/sda1 LUKS
/dev/sdb1 LUKS

Первое, о чем я подумал – это настроить LVM в LUKS контейнере, но как грамотно добавить туда sdb1, чтобы это работало также как и сейчас. Или может LVM избыточен для моего случая и есть способ проще и лучше?

От шифрования отказываться не собираюсь, как и от желания «спрятать» boot, /и home из разметки.


Ответ на: комментарий от andytux

Не мудри без меры, перемудришь.

Твой вариант?

Неужели у тебя все еще БИОС?

А что тут удивительного? Никаких плюсов в UEFI я не вижу, плюс для него нужен ESP раздел.

Panika
() автор топика
Ответ на: комментарий от Panika

плюс для него нужен ESP раздел…

Каламбурчик получился.

Он более чем, заменит твой боот-раздел. А вот в боот-разделе одни только минусы.

andytux ★★★★★
()
Ответ на: комментарий от andytux

Каламбурчик получился.

С первого раза мало что хорошо получается. Главное то, что я хочу получить, на этом и сконцентрируемся.

Panika
() автор топика

Там выбор невелик: lvm или btrfs. Если /dev/sdb1 это файлопомойка и ты хочешь, чтобы тяжелые файлы находились там, а не на SSD, то используй символические ссылки, смотри man ln короче.

The_Coon
()
Ответ на: комментарий от The_Coon

lvm или btrfs.

И что из этого выбрать?

Если /dev/sdb1 это файлопомойка и ты хочешь, чтобы тяжелые файлы находились там, а не на SSD, то используй символические ссылки, смотри man ln короче.

Спасибо!

Panika
() автор топика

А в чем вопрос? Создай luks раздел, внутри него lvm, а нем какие угодно логические тома.

mxfm ★★
()
Ответ на: комментарий от Panika

Для тех, кто в танке: альтернатива lvm - это любая fs, которая умеет создавать subvolume (например, btrfs или zfs или другие), которые могут имитировать отдельные тома. Отличием этой схемы от lvm является то, что по сути fs остаётся одной - если она повреждается, то повреждаются все виртуальные разделы (subvolume). В схеме lvm каждый раздел имеет свою fs, которая не зависит от других, и на разных логических томах могут располагаться разные fs. Добавлять другие диски в виртуальные разделы можно как с fs, так и с lvm.

mxfm ★★
()
Ответ на: комментарий от Panika

С btrfs - проблем нет. У этого человека - да. Он появляется в каждой теме про btrfs и предлагает не пользоваться ей. В одной из таких тем было большое обсуждение в чём дело - оказалось, у него на основании прочтения тем про btrfs сложилось мнение, что это плохая fs. Ради интереса я как-то прошёлся по списку тем с тегом btrfs - случаи потери данных единичны, а которые имели место - были вызваны случайными действиями пользователей.

mxfm ★★
()

я так делаю

bastet:~ # lvs
  LV               VG        Attr       LSize   Pool Origin        Data%  Meta%  Move Log Cpy%Sync Convert
  lv_home          root_nvme -wi-ao---- 500.00g                                                           
  lv_root          root_nvme -wi-ao----  70.00g                                                           
  vm_xxx           root_nvme swi-aos---  30.00g      vm_windows_10 42.95                                  
  vm_devbox        root_nvme swi-a-s---  50.00g      vm_windows_10 61.19                                  
  vm_windows_10    root_nvme owi-a-s--- 100.00g                                                           
bastet:~ # lsblk
NAME                               MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme0n1                            259:0    0 931.5G  0 disk  
├─nvme0n1p1                        259:1    0   680M  0 part  /boot/efi
├─nvme0n1p2                        259:2    0     1G  0 part  /boot
└─nvme0n1p3                        259:3    0 929.8G  0 part  
  ├─root_nvme-lv_root              254:0    0    70G  0 lvm   
  │ └─cr_root_nvme-lv_root         254:1    0    70G  0 crypt /
  ├─root_nvme-lv_home              254:2    0   500G  0 lvm   
  │ └─cr_root_nvme-lv_home         254:9    0   500G  0 crypt /home
  ├─root_nvme-vm_windows_10-real   254:3    0   100G  0 lvm   
  │ ├─root_nvme-vm_windows_10      254:4    0   100G  0 lvm   
  │ ├─root_nvme-vm_xxx   254:6    0   100G  0 lvm   
  │ └─root_nvme-vm_devbox          254:8    0   100G  0 lvm   
  ├─root_nvme-vm_xxx-cow 254:5    0    30G  0 lvm   
  │ └─root_nvme-vm_xxx   254:6    0   100G  0 lvm   
  └─root_nvme-vm_devbox-cow        254:7    0    50G  0 lvm   
    └─root_nvme-vm_devbox          254:8    0   100G  0 lvm   

LVM чисто для виртуалок, когда хочется побыстрее и иногда перемещаю разделы на внешние диски, но в большинстве случаев это реально избыточно, в ооочень редких случах для эксперементов создаю снапшоты домашнего раздела

sparks ★★★★
()
Ответ на: комментарий от mxfm

у меня были проблемы с btrfs subvolume’мами и потерей данных, SUSE на който хрен оч любит их использовать в связке со snapper, вот оно и доставило разок изрядное количество радости, после этого сижу на xfs

sparks ★★★★
()
Ответ на: комментарий от sparks

Моя текущая разметка создавалась с учетом беспроблемного переезда. То есть, форматнул boot и / и переустанавливай, ставь другую систему, примонтировав home и storage.

Какие действия я должен предпринять с lvm при таком переезде? Можно командами для наглядности.

Panika
() автор топика
Ответ на: комментарий от Panika

Какие действия я должен предпринять с lvm при таком переезде?

Делаешь тоже самое: форматируешь тома и накатываешь систему, примонтировав по пути остальное.

The_Coon
()

Первое, о чем я подумал – это настроить LVM в LUKS контейнере, но как грамотно добавить туда sdb1, чтобы это работало также как и сейчас. Или может LVM избыточен для моего случая и есть способ проще и лучше?

Cамое простое - создать второй luks контейнер на sdb1 и монтировать его в /storage. LVM по желанию. Бывает удобен, когда хочется перетасовать пользовательские разделы. Как-то так:

NAME                      MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                         8:0    0 465,8G  0 disk  
├─sda1                      8:1    0   512M  0 part  /boot/efi
└─sda2                      8:2    0   465G  0 part  
  └─md0                     9:0    0 464,9G  0 raid1 
    └─cryptoroot          253:0    0 464,9G  0 crypt 
      ├─pc--01--vg-root   253:1    0 432,9G  0 lvm   /
      └─pc--01--vg-swap_1 253:2    0    32G  0 lvm   [SWAP]
sdb                         8:16   0   3,7T  0 disk  
└─sdb1                      8:17   0   3,7T  0 part  
  └─md1                     9:1    0   3,7T  0 raid1 
    └─cryptodata          253:3    0   3,7T  0 crypt 
      └─pc--01--vg1-data  253:4    0   3,7T  0 lvm   /data
sdc                         8:32   0   3,7T  0 disk  
└─sdc1                      8:33   0   3,7T  0 part  
  └─md1                     9:1    0   3,7T  0 raid1 
    └─cryptodata          253:3    0   3,7T  0 crypt 
      └─pc--01--vg1-data  253:4    0   3,7T  0 lvm   /data

Grub умеет грузить md, luks1, lvm. Можно попробовать завести два диска в линейный массив и обойтись одним luks’ом, но надо поверять, понимает ли груб md linear.

Если так сильно хочется зашифровать /boot, придется покрасноглазить вручную. Debian тот же самый через инсталлятор не ставится в таком случае. Установка зависит от типа системы (mbr или efi). mbr обходится одним разделом, загрузчик ставится в пустое пространство после mbr’a, но можно нарваться на особенности реализации конкретного bios’a. Для efi нужно 2 раздела: системный и для luks.

undef ★★
()
Ответ на: комментарий от undef

я искренне не понимаю смысла mdraid, раньше у lvm была особенность зеркальных томов в требовании чёткого указания где будет храниться жрунал, теперь этого нет и можно как stripe так и mirror из коробки

[root@nas ~]# lvs -o +devices
  LV                VG      Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices                                      
  lv_bitcoin        vg_data rwi-aor--- 512.00g                                    100.00           lv_bitcoin_rimage_0(0),lv_bitcoin_rimage_1(0)
  lv_common_upload  vg_data -wi-ao----   1.00t                                                     /dev/sdd(837632)                             
  lv_distr          vg_data -wi-ao----   2.00t                                                     /dev/sdd(0)                                  
  lv_docker_storage vg_data -wi-ao----   1.00t                                                     /dev/sdd(575488)                             
  lv_postgresdb     vg_data -wi-ao---- 200.00g                                                     /dev/sdd(524288)                             
  root              vg_root -wi-ao----  30.00g                                                     /dev/sdc2(0)  
[root@nas ~]# lsblk
NAME                          MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda                             8:0    0   1.8T  0 disk 
├─vg_data-lv_bitcoin_rmeta_0  253:5    0     4M  0 lvm  
│ └─vg_data-lv_bitcoin        253:9    0   512G  0 lvm  /common/bitcoin
└─vg_data-lv_bitcoin_rimage_0 253:6    0   512G  0 lvm  
  └─vg_data-lv_bitcoin        253:9    0   512G  0 lvm  /common/bitcoin
sdb                             8:16   0   1.8T  0 disk 
sdc                             8:32   0 232.9G  0 disk 
├─sdc1                          8:33   0     1G  0 part /boot
├─sdc2                          8:34   0    30G  0 part 
│ └─vg_root-root              253:0    0    30G  0 lvm  /
└─sdc3                          8:35   0 201.9G  0 part 
sdd                             8:48   0   5.5T  0 disk 
├─vg_data-lv_distr            253:1    0     2T  0 lvm  /common/distr
├─vg_data-lv_postgresdb       253:2    0   200G  0 lvm  /srv/db
├─vg_data-lv_docker_storage   253:3    0     1T  0 lvm  /var/lib/docker
├─vg_data-lv_common_upload    253:4    0     1T  0 lvm  /common/upload
├─vg_data-lv_bitcoin_rmeta_1  253:7    0     4M  0 lvm  
│ └─vg_data-lv_bitcoin        253:9    0   512G  0 lvm  /common/bitcoin
└─vg_data-lv_bitcoin_rimage_1 253:8    0   512G  0 lvm  
  └─vg_data-lv_bitcoin        253:9    0   512G  0 lvm  /common/bitcoin
zram0                         252:0    0     8G  0 disk [SWAP]
sparks ★★★★
()
Последнее исправление: sparks (всего исправлений: 2)
Ответ на: комментарий от sparks

Лично у меня так сложилось исторически. Сейчас работает - не трожь. mdadm, lvm, luks, фс с подтомами пересекаются по функционалу. В контексте темы (шифрованный /boot) вопрос в том, что из этого зоопарка поддерживает grub. Вон, соседней теме ТС пытается подружить grub с luks2.

undef ★★
()

Почему бы не использовать нативное шифрование ZFS, как раз можно добавить несколько дисков в один пул и избежать использования многослойного пирога в виде lvm+luks+fs

passw0rd
()
Ответ на: комментарий от passw0rd

Потому что никто не предложил даже не предложил такой вариант.

Panika
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.