LINUX.ORG.RU

шифрование, lvm, изменение размера фс и прочее...


0

1

Ситуация такая: имеется свежесобранная система с двумя новыми трехтерабайтниками (в настоящее время тестируются вдоль и поперек посредством badblocks -swv). Задача: установить систему на raid1 с полным шифрованием всех фс (кроме, разумеется, /boot), причем для некоторых пользователей (требуемое пространство для которых заранее предсказать затруднительно) домашние каталоги должны шифроваться отдельно. Также следует учесть, что в будущем возможно добавление новых дисков (с переходом на raid5).

Проблема в следующем: если разбить винты на один маленький (/boot) и один большой раздел (зашифрованная с использованием luks группа томов lvm - для всего остального), то получаем шифрование поверх шифрования (что, имхо, неправильно с точки зрения производительности и использования вычислительных ресурсов), т.к. хоумы вышеупомянутых пользователей - тома lvm с шифрованной фс.

Еще вариант - внутри незашифрованного lvm тома с зашифрованными фс пользователей и том с зашифрованной группой томов (корень, /home, возможно также /tmp и /var) - не знаю, возможно ли создание lvm внутри lvm, не пробовал, но как-то тоже не совсем красиво...

Как бы получше разрулить эту проблему?

Еще вопрос относительно выделения пространства под тома lvm - думаю, на первое время оставить часть пространства внутри группы томов незанятой, чтобы впоследствии можно было добавить пространство к тому тому, к которому это будет необходимо, однако есть сомнения в безопасности такой операции... Конкретный вопрос - насколько безопасно для сохранности инфы увеличение размера файловой системы (ext3/ext4)? Т.е. есть ли гарантия, что информация при этой операции не пострадает?

Далее, вопрос выбора непосредственно файловой системы... Колеблюсь между ext3 и ext4, душа лежит к ext3, т.к. все-таки она проверена временем и огромным количеством серверных установок, однако ext4 манит обещанным ускорением проверки фс, что для трехтерабайтного пространства таки критично... Плюс есть сомнения (не являюсь экспертом в области ФС) в лимитах ext3 - вроде как максимального размера фс в 16Тб теоретически должно хватить на обозримое будущее, но вроде как этот лимит может быть меньше в зависимости от размера блока - не возникнет ли тут подводных камней в процессе увеличения файловых систем с приближением от 3Тб поближе к 16Тб-барьеру?

Система предполагается ubuntu 11.10. Для пользователей, хоумы которых шифруются, будет задействован pam-mount.

Как бы получше разрулить эту проблему?

Сделай два физических тома и соответственно две группы: «системную» и «пользовательскую». PV можно делать как разными массивами, так и разными разделами на одном массиве. Вообще MD/DM можно тасовать по-разному, всё зависит от целей и здравого смысла.

Конкретный вопрос - насколько безопасно для сохранности инфы увеличение размера файловой системы (ext3/ext4)?

У меня проблем не было.

Т.е. есть ли гарантия, что информация при этой операции не пострадает?

Есть. Называется бэкап.

Я бы рекомендовал ext4, проблем не наблюдается, проверка быстрая, производительность высокая, плюс недавно появился онлайновый дефрагментатор.

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

Сделай два физических тома и соответственно две группы: «системную» и «пользовательскую». PV можно делать как разными массивами, так и разными разделами на одном массиве. Вообще MD/DM можно тасовать по-разному, всё зависит от целей и здравого смысла.

Фишка в том, что большая часть информации будет храниться где-нить в /home с общесистемным шифрованием, т.е. доступная (на чтение) всем пользователям (файлопомойка). Но для нескольких (не всех) пользователей их домашние каталоги должны шифроваться отдельно. Т.е. пользователи u1, u2, u3, u4, u5 знают пароль luks (общий или у каждого свой - не суть важно), позволяющий им подключить корень и /home при загрузке компьютера, при этом u1, u2 и u3 в качестве домашних каталогов используют обычную папку в /home, но при авторизации u4 и u5 в место расположения их домашних каталогов монтируется шифрованный том посредством pam-mount. Причем заранее невозможно предсказать, хватит ли им по 10Гб на каждого или же кому-то из них (или обоим) в будущем 200Гб выделить придется... Т.е. между фс в /home и их томами необходимо как-то перераспределять пространство, а значит смысла в двух группах нет...

Есть. Называется бэкап.

Хе, что-то я стормозил, у мя ж второй винт - готовый бэкап... Удалить его из рейда перед ресайзом - и можно быть спокойным, если что не так - грузимся с него :) .

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

Т.е. пользователи u1, u2, u3, u4, u5 знают пароль luks (общий или у каждого свой - не суть важно), позволяющий им подключить корень и /home при загрузке компьютера, при этом u1, u2 и u3 в качестве домашних каталогов используют обычную папку в /home, но при авторизации u4 и u5 в место расположения их домашних каталогов монтируется шифрованный том посредством pam-mount. Причем заранее невозможно предсказать, хватит ли им по 10Гб на каждого или же кому-то из них (или обоим) в будущем 200Гб выделить придется...

Если там действительно имеет место быть ситуация неопределённости, то, на мой взгляд, наиболее безболезненно было бы смириться с двойным шифрованием.

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

А почему не сделать два хомяка? Один шифрованный целиком, а другой с отдельными шифроваными хомяками.

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

между фс в /home и их томами необходимо как-то перераспределять пространство, а значит смысла в двух группах нет

я для подобных целей дома на линуксе гоняю ядерный порт ZFS. Решение красивое, но к серьезному продакшену пока еще не готовое...

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