LINUX.ORG.RU

Муки выбора: LVM поверх LUKS или LUKS поверх LVM

 ,


2

4

Мучаюсь от выбора, что лучше: LVM на LUKS или LUKS на LVM.

Ситуация такая: один жесткий диск, мать с EFI. Раз в пару лет планирую перевозить систему на новый жесткий бОльшего размера. Шифровать по возможности планирую всё, кроме MBR (GPT в моем случае).

Судя по wiki Arch Linux, недостатки LVM на LUKS такие:
1. Нельзя создавать логические тома, которые будут одновременно на двух жестких (но непонятно, будет ли работать pvmove).

Недостатки LUKS на LVM такие:
1. Будет не один пароль на все жесткие диски, а для каждого винта свой. Из-за этого сложно настроить suspend to disk, resume from disk.
2. Сложно зашифровать swap.
3. Сложнее зашифровать /boot.

Какой вариант для моих задач лучше? И вообще пробовал кто-то реализовать следующее: не выключая комп, подключить новый винт к контроллеру SATA III на материнке, сделать pvmove со старого на новый бОльшего размера, после чего отключить старый винт и вынуть - и всё это без перезагрузок?

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

дяди из фсб к твоим данным доступ получат

Пытки паяльником с целью расшифровки LUKS - городская легенда типа крокодилов в канализации.

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

И как в таком случае уехать с одного винта на другой онлайн? Вот в чем вопрос.

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

Исключение подтверждающее правило

Старая новость: ФБР не смогло расшифровать жесткий диск.

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

Camel ★★★★★
()

Будет не один пароль на все жесткие диски, а для каждого винта свой

Делаешь один пароль на все жесткие диски, а в грабе пишешь cryptomount -a.

А по теме: LVM в/на LUKSe

cuss
()

недостатки LVM на LUKS такие:

1. Нельзя создавать логические тома, которые будут одновременно на двух жестких.

Можно. Возможно текущий конструктор initramfs в арче не умеет разруливать такие ситуации. Посмотри в сторону dracut.

но непонятно, будет ли работать pvmove

Будет.

Недостатки LUKS на LVM такие:

2. Сложно зашифровать swap.

Почему? Для swap вообще можно использовать одноразовый случайный ключ.

3. Сложнее зашифровать /boot.

А /boot у тебя в обоих случаях должен быть нешифрованным. Если не можешь держать его на винте, то держи на флешке. Расшифровка корня происходит в initramfs после старта cryptsetup, там же стартует LVM, и в конце, когда блочное устройство с рутовой системой готово, оно монтируется и происходит pivot_root - т.е., упрощенно - загрузка (точнее, продолжение загрузки) с уже настоящего рутового раздела.

Chaser_Andrey ★★★★★
()

btrfs на LUKS.

Deleted
()

По теме: при схеме LUKS на LVM сложнее изменять размеры разделов, особенно уменьшать, потому что изменение размера криптоконтейнера - операция, где надо быть внимательным и легко запороть данные при ошибке. Но сложнее - не значит «невозможно». Всего лишь на n команд больше.

Поищи, как изменяются размеры криптоконтейнеров LUKS/cryptsetup.

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

Хорошо, ну а как в схеме «LVM на LUKS», которая на ЛОРе более популярна, переехать с винта на винт, не перезагружая комп? Логику пытаюсь понять.

Ведь сначала нужно два винта (текущий и новый чистый из магазина) объединить в один логический том, потом перегнать все экстенты на новый, потом уже удалить старый винт из LVM и отсоединить его физически.

При этом не забыть вручную скопировать с первого винта на второй таблицу GPT и разделы /boot/efi и /boot.

Но на wiki Arch Linux написано про «LVM на LUKS»: "...it will not be possible to exploit the ability of LVM and RAID to span multiple disks..."

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

при схеме LUKS на LVM сложнее изменять размеры разделов

потому что изменение размера криптоконтейнера - операция, где надо быть внимательным и легко запороть данные при ошибке

При переезде с винта 1 TB на винт 8 TB при схеме «LVM на LUKS» придется же тоже вручную изменять размер криптоконтейнера, и можно ошибиться?

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

Создаешь на втором винте раздел LUKS, открываешь его, создаешь в открытом криптоконтейнере PV и добавляешь PV к существующей VG. Далее просто pvmove.

При этом не забыть вручную скопировать с первого винта на второй таблицу GPT и разделы /boot/efi и /boot.

/boot у тебя не на LUKS, а отдельно. На флешке, на ещё одном физическом разделе GPT, не важно, но это не имеет никакого отношения к pvmove и lvm over luks.

После pvmove переносишь всё, что осталось, делаешь grub-install и grub-mkconfig (или через дистроспецифичные хэлперы). Как-то так.

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

"...it will not be possible to exploit the ability of LVM and RAID to span multiple disks..."

Я вижу, но не вижу аргументации, почему это нельзя делать. Для LVM плевать, что там за криптоконтейнеры, он работает с блочными устройствами, слава юниксам.

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

При переезде с винта 1 TB на винт 8 TB при схеме «LVM на LUKS» придется же тоже вручную изменять размер криптоконтейнера, и можно ошибиться?

Нет, тебе лишь надо будет сделать LUKS-контейнер нужного размера. Ты же не собираешься делать переезд с помощью dd?

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

А /boot у тебя в обоих случаях должен быть нешифрованным.

Ты не поверишь, но отдельный бут для LVM/LUKS не нужен. Знатно у вас там в федоре мозги промывают. Потом сами и лечат. В убунте всё ставится при установке в 1 раздел. 1 диск, 1 раздел, 1 LUKS!

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

Я вообще на генте. Спасибо за ссылку. Данная возможность достаточно новая, раньше граб такое не умел.

Chaser_Andrey ★★★★★
()
Последнее исправление: Chaser_Andrey (всего исправлений: 1)
Ответ на: комментарий от Chaser_Andrey

После pvmove переносишь всё, что осталось, делаешь grub-install и grub-mkconfig

EFI и граб буду держать на винте, схема будет такая:

1. /boot/efi partition.
2. /boot partition.
3. LUKS - на весь оставшийся диск.
3.1. LVM - тоже до самого конца диска.
3.1.1. /
3.1.2. /home


В моем случае я не пойму, зачем нужно делать grub-install и grub-mkconfig в конце. Разве такой алгоритм не прокатит?

1. Сделать на втором винте новую таблицу GPT, скопировать туда через dd разделы (1) и (2).
2. Создать на втором винте хранилище LUKS с тем же паролем, что и (3).
3. Создать на втором винте LVM до самого конца винта, сделать туда pvmove с первого винта.
4. Удалить первый винт из LVM, отсоединить старый жесткий диск.

По идее, будет работать, и после перезагрузки всё будет хорошо. Не понял, для чего ты предлагал делать grub-install и grub-mkconfig. Программа dd должна нормально отработать же?

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

Добавлю вопрос:

При этом, даже если первый винт был 1 терабайт, второй - 6 терабайт, никаких resize для криптораздела LUKS и LVM делать не надо в случае выполнения шагов 1-4 включительно, а надо только файловую систему в самом конце расширить, в моем случае - сделать resize2fs на ext4 (/) и ext4 (/home), я правильно понимаю?

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

Ты не поверишь, но отдельный бут для LVM/LUKS не нужен

/boot для граб2, наверное, и не нужен в современных дистрибутивах, а вот /boot/efi (FAT32) нужен же.

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

А, если так, то вроде норм. Только вот тут надо быть внимательным, чтобы размеры разделов совпадали или были больше (ведь GPT держит пару копий записей, и перезатереть в начале - недостаточно).

Ты же собираешься копировать с помощью dd только отдельные разделы, а не кусок винта (1 и 2 разделы одновременно)?

И на будущее: будь внимательный, не используется ли где в твоих ручных или сгенерированных конфигах пути к устройствам вида:

/dev/disk/by-id/ata-TOSHIBA_DT01ACA300_31SXYZ8Z

Chaser_Andrey ★★★★★
()
Последнее исправление: Chaser_Andrey (всего исправлений: 2)
Ответ на: комментарий от ns_ramesses

никаких resize для криптораздела LUKS

Не надо, ты не переносишь LUKS, а создаешь заново. Просто создай достаточного размера, чтобы можно было успешно сделать pvmove.

LVM

Если ты о VG, то он сам увеличится, как только ты добавишь PV со второго винта.

Если ты о LV, то ты же делаешь pvmove, оно просто переносит LV, без его модификаций.

а надо только файловую систему в самом конце расширить, в моем случае - сделать resize2fs на ext4 (/) и ext4 (/home), я правильно понимаю?

Если только тебе надо увеличить ФС, но не обязательно. С чего ты вообще решил, что тебе надо делать resize2fs при переносе? Ты это можешь сделать в любой момент.

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

Ты же собираешься копировать с помощью dd только отдельные разделы, а не кусок винта (1 и 2 разделы одновременно)?

Да, сначала через parted создать пустые разделы (1) и (2) тех же размеров, уже потом каждый из разделов отдельно через dd скопировать.

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

Если ты о LV, то ты же делаешь pvmove, оно просто переносит LV, без его модификаций.

Ясно. То есть, после всех манипуляций и отсоединения старого винта для того, чтобы заюзать весь объем нового (допустим, я решил / не трогать, а /home расширить по максимуму) нужно сделать

lvresize --resizefs /dev/vg/lv_home

Так?

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

Да, только я не уверен, что твоя команда сработает. Вот так будет работать:

lvresize --resizefs -l +100%FREE /dev/vg/lv_home

Но немного оставлять свободного места в VG - хороший тон. Это позволит тебе делать снапшоты на живой системе, например, для консистентного бэкапа.

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

Ясно. Но тогда «немного» не гарантирует консистентности, если файлы в томе активно модифицируются. В таком случае размер всего LVM должен примерно половину винта занимать, пустая половина - под временный снэпшот...

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

В таком случае размер всего LVM должен примерно половину винта занимать,

Не всего LVM, а суммарные размеры LV внутри VG. На счёт половины - ты погорячился. Учитываются только измененные данные блоками по пару мегабайт. Если ты собираешься во время бэкапа модифицировать все-все файлы - тогда да, надо половину.

И ещё

Если устройство-«снапшот» полностью заполняется, оно автоматически деактивируется. 
Это легко определить во время бэкапа или по его завершению, так что скрытно ты не получишь «неконсистентный бэкап». Правильно настроенный бэкап должен вывалиться с ошибкой в этом случае.

Chaser_Andrey ★★★★★
()
Последнее исправление: Chaser_Andrey (всего исправлений: 1)
Ответ на: комментарий от ns_ramesses

1. /boot/efi partition.
2. /boot partition.

Нахрена? Достаточно создать EFI раздел, сунуть туда ядро собранное с EFI Stub и initramfs. Два раздела - EFI и LVM. EFI раздел вообще можно куда-нибудь на флешку унести, туда же и заголовок LUKS раздела. А второй диск (если там будет зашифрованный /home) - можно зашифровать отдельно, подключать в /etc/crypttab. Насколько я помню, расшифровывать можно ключем, а его хранить на первом зашифрованном диске. Вот и вся любовь.

Meyer ★★★★★
()
Последнее исправление: Meyer (всего исправлений: 1)
Ответ на: комментарий от Meyer

Я не доверяю флэшкам. Их качество - шлак. Информация, записанная год назад, может быть повреждена (какой-то из битов инвертирован или даже несколько). То есть, мне придется заводить некую регулярную задачу по проверке md5sum образа флэшек, регулярного дублирования инфы на другие флэшки и так далее.

Поэтому и не хочу плодить лишнюю сущность. EFI-раздел на жестком будет, так его бэкапить проще будет на NAS вместе с остальным контентом на жестком.

Возвращаюсь к вопросу «Нахрена?»

Я не люблю FAT32, но EFI-раздел можно создать только в ней. Поэтому стараюсь как можно меньше там держать. Если GRUB можно вынести в раздел с нормальной ФС, я это сделаю.

ns_ramesses
() автор топика
Последнее исправление: ns_ramesses (всего исправлений: 1)
Ответ на: комментарий от ns_ramesses

Не знаю. На нотике - BIOS, нужды в GPT не испытываю, the вопросом не интересовался.

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

GRUB

Для чего нужен этот костыль? Ядро уже давно может запускаться как EFI-приложение. Гроб был нужен для бивиса, это да.

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

Я не доверяю флэшкам.

Можешь записать на CD.

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

Я далёк от EFI/UEFI, но там вроде как в железяке есть спецприёмник, куда этот самый ефи кладётся, а раздел на диске нужен для того, что во флэш не влезло. Это так или нет и где почитать?

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

Для чего нужен этот костыль? Ядро уже давно может запускаться как EFI-приложение.

Вот до чего техника дошла! Спасибо за информацию. Тогда будет два раздела:
1. /boot/efi, vfat
2. LVM on LUKS.

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

Я далёк от EFI/UEFI, но там вроде как в железяке есть спецприёмник, куда этот самый ефи кладётся, а раздел на диске нужен для того, что во флэш не влезло.

Во флеше нужно создавать запись, если твой EFI файл не лежит на EFI разделе в директории boot под названием bootx{32,64}.efi, или если нужно еще и initramfs юзать. А так - достаточно скопировать ядро в \EFI\Boot под именем bootx{32,64}.efi и спокойно загружаться.

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

Да, это понятно. Посмотрю в виртуалке что за зверь такой.

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

Во флеше нужно создавать запись, если твой EFI файл не лежит на EFI разделе в директории boot под названием bootx{32,64}.efi, или если нужно еще и initramfs юзать.

О! Можно подробнее? То есть, после замены материнской платы компа на аналогичную новую из магазина Gentoo, скорее всего, не запустится? Придется грузиться с LiveDVD и еще что-то делать?

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

грузиться с LiveDVD и еще что-то делать?

Да, нужно будет из LiveDVD/USB с помощью efibootmgr добавить запись.

Meyer ★★★★★
()

Я сделал два раздела, один под /boot, другой под LVM. Под LVM зашифровал к черту. В /boot лежат ядра, зачем их шифровать не очень понятно.

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

На случай кражи компа /boot можно и не шифровать.

На случай злого умысла лучше зашифровать. Незваный гость может принести с собой флэшку и подменить ядро, встроив туда кейлоггер или руткит, пока вы в туалете будете. Другой пример: менты изъяли жесткие по подозрению в том, что вы вербуете людей в ИГ, а через неделю вернули, сняв подозрения. Ядро теперь модифицировано ими.

ns_ramesses
() автор топика
Последнее исправление: ns_ramesses (всего исправлений: 1)
Ответ на: комментарий от ns_ramesses

Ядро теперь модифицировано ими.

К тому же - монолит, рассылает спам с призывами. Через час после этого вас «заворачивают» на 23 года и крутят новую дырдочку на кителе. Вполне.

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

На случай злого умысла лучше зашифровать. Незваный гость может принести с собой флэшку и подменить ядро, встроив туда кейлоггер или руткит, пока вы в туалете будете.

Он скорее у тебя бабло из шкафа стырит.

Другой пример: менты изъяли жесткие по подозрению в том, что вы вербуете людей в ИГ, а через неделю вернули, сняв подозрения. Ядро теперь модифицировано ими.

Менты вставят тебе бутылку в задницу, и ты тут же сознаешься в участии в ИГ, заговоре против Путина и убийстве Кеннеди.

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

Менты вставят тебе бутылку в задницу

Они редко кому бутылки вставляют, если статистику рассмотреть.

Тут парадигма мышления другая: если /boot (за исключением EFI-блоба) на Gentoo можно зашифровать, то почему бы и не зашифровать его. Почему бы и нет?

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