* [Comm] RAID, LVM & LUKS @ 2010-05-20 14:18 Vaso VV 2010-05-25 6:45 ` Vaso VV 2010-05-26 8:27 ` Nikolay A. Fetisov 0 siblings, 2 replies; 4+ messages in thread From: Vaso VV @ 2010-05-20 14:18 UTC (permalink / raw) To: community Дано: AltLinux Desktop KDE4 P5 # cat /proc/mdstat Personalities : [raid1] md5 : active raid1 sdb7[0] sda7[1] 216821120 blocks [2/2] [UU] ... Задача: Создать на md5 пару-тройку масштабируемых шифрованных разделов. Возникшие вопросы: 1. Как кошерней: а) организовать сначала LVM-тома, а затем зашифровать их cryptsetup-ом (можно ли [каким образом] в таком случае изменять размер разделов?); или б) создать шифрованный раздел и на него повесить LVM? 2. Нужен ли скрипт [где его пристроить?], выполняемый перед выключением для корректного размонтирования/даективации такого «бутерброда»? 3. Есть ли ещё какие-то особенности, которые нужно учесть в организации связки RAID-LVM-LUKS? -- WBR........[ ] TFTHAOT....[x] AMF........[ ] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Comm] RAID, LVM & LUKS 2010-05-20 14:18 [Comm] RAID, LVM & LUKS Vaso VV @ 2010-05-25 6:45 ` Vaso VV 2010-05-26 8:27 ` Nikolay A. Fetisov 1 sibling, 0 replies; 4+ messages in thread From: Vaso VV @ 2010-05-25 6:45 UTC (permalink / raw) To: community 20.05.2010 17:18, Vaso VV пишет: > Дано: AltLinux Desktop KDE4 P5 > # cat /proc/mdstat > Personalities : [raid1] > md5 : active raid1 sdb7[0] sda7[1] > 216821120 blocks [2/2] [UU] > ... > > Задача: > Создать на md5 пару-тройку масштабируемых шифрованных разделов. > > Возникшие вопросы: > 1. Как кошерней: а) организовать сначала LVM-тома, а затем зашифровать > их cryptsetup-ом (можно ли [каким образом] в таком случае изменять > размер разделов?); или > б) создать шифрованный раздел и на него повесить LVM? > 2. Нужен ли скрипт [где его пристроить?], выполняемый перед выключением > для корректного размонтирования/даективации такого «бутерброда»? > 3. Есть ли ещё какие-то особенности, которые нужно учесть в организации > связки RAID-LVM-LUKS? > а если хауту на altlinux.org обяжусь написать? -- WBR........[ ] TFTHAOT....[x] AMF........[ ] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Comm] RAID, LVM & LUKS 2010-05-20 14:18 [Comm] RAID, LVM & LUKS Vaso VV 2010-05-25 6:45 ` Vaso VV @ 2010-05-26 8:27 ` Nikolay A. Fetisov 2010-05-28 15:37 ` Vaso VV 1 sibling, 1 reply; 4+ messages in thread From: Nikolay A. Fetisov @ 2010-05-26 8:27 UTC (permalink / raw) To: ALT Linux Community general discussions В Чтв, 20/05/2010 в 17:18 +0300, Vaso VV пишет: > Дано: AltLinux Desktop KDE4 P5 ... > Задача: > Создать на md5 пару-тройку масштабируемых шифрованных разделов. > > Возникшие вопросы: > 1. Как кошерней: а) организовать сначала LVM-тома, а затем зашифровать > их cryptsetup-ом (можно ли [каким образом] в таком случае изменять > размер разделов?); или > б) создать шифрованный раздел и на него повесить LVM? Тут основной вопрос - для чего и как эти разделы планируется дальше использовать. В зависимости от этого и можно будет выбирать конкретную схему. Кстати, помимо этих двух перечисленных есть и третий вариант - сделать LUKS-разделы поверх логических разделов дисков, и уже их объединять в MD-RAID. Не говоря о вариантах, когда часть входящих в VG PV располагаются на LUKS-разделах, а часть - на обычных некриптованных. Из тех особенностей, которые сходу пришли в голову: Вариант partition - LUKS - mdraid - LVM - FS: - независимые ключи на каждый из дисковых разделов; - невозможно получить информацию о структуре RAID'а и вышестоящих уровней; - вся информация криптуется; - легко изменяются размеры LV (т.е. без лишних действий), работают snapshot'ы, и т.п. - возможно в прозрачном режиме перенести имеющиеся LV на криптованные диски и/или обратно; - требуется ручная сборка mdraid, активация PV, VG, монтирование файловых систем; - корректная остановка всей системы при выключении машины, за исключением закрытия разделов LUKS (что, впрочем, мешать не будет). Вариант partition - mdraid - LUKS - LVM - FS: - Один общий ключ на PV; - автоматическая сборка mdraid при загрузке машины; - невозможно получить заголовок PV и информацию о структуре вышестоящих уровней; - вся информация криптуется; - легко изменяются размеры LV (т.е. без лишних действий), работают snapshot'ы, и т.п. - возможно в прозрачном режиме перенести имеющиеся LV на криптованные диски и/или обратно; - требуется ручная активация PV, VG, монтирование файловых систем; - возможны проблемы деактивации mdraid при выключении машины. Вариант partition - mdraid - LVM - LUKS - FS: - Независимые ключи на разные LV; - автоматическая сборка mdraid и LVM при загрузке машины; - криптуются только конкретные LV; - возможно использование LV без LUKS; - при изменении размеров LV требуется также изменение размера тома LUKS, с дополнительными действиями по подготовке нового пространства; - вопросы при работе с snapshot'ами; как минимум, не будет работать freeze файловых систем перед созданием snapshot'а; - возможно перемещение LV с LUKS между разными PV без угрозы защиты данных; - требуется ручное монтирование файловых систем в LV с LUKS; - возможны проблемы деактивации LVM/mdraid при выключении машины. Изменение размеров разделов LUKS вполне возможно, последовательность стандартная: при увеличении - увеличить размер диска нижнего уровня, заполнить добавленную часть мусором, увеличить размер раздела LUKS, увеличить размер на следующем уровне. При уменьшении - в обратную сторону. Нюансы появляются при определении той части диска, которую требуется заполнить мусором. Наиболее лёгкий вариант, но плохо подходящий при изменении размеров при параллельной штатной работе системы - сначала увеличить размер файловой системы, потом создать на ней файл, заполнив до конца доступное место, и удалить его. Другие варианты требуют расчётов размера раздела LUKS и потенциально опасны. > 2. Нужен ли скрипт [где его пристроить?], выполняемый перед выключением > для корректного размонтирования/даективации такого «бутерброда»? Вообще, для варианта mdraid - LVM - LUKS обхожусь и без чего-либо дополнительного. Впрочем, штатные перезагрузки крайне редки, и когда выполняются, то перед ними обычно руками останавливается всё начиная с VE и кончая размонтированием практически всех файловых систем. > 3. Есть ли ещё какие-то особенности, которые нужно учесть в организации > связки RAID-LVM-LUKS? В зависимости от требований к системе. Как минимум, имеет смысл задаться вопросом о целях построения такой системы и о том, куда и _как_ будут делаться резервные копии данных. -- С уважением, Николай Фетисов ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Comm] RAID, LVM & LUKS 2010-05-26 8:27 ` Nikolay A. Fetisov @ 2010-05-28 15:37 ` Vaso VV 0 siblings, 0 replies; 4+ messages in thread From: Vaso VV @ 2010-05-28 15:37 UTC (permalink / raw) To: community 26.05.2010 11:27, Nikolay A. Fetisov пишет: [скип] > … Не говоря о вариантах, когда часть входящих в VG PV > располагаются на LUKS-разделах, а часть - на обычных некриптованных. А если ещё и эти VG тщательно размазать по PV (lvcreate -i)… И какая выгода от такого "частичного" шифрования? [скип] > - возможно в прозрачном режиме перенести имеющиеся LV на криптованные > диски и/или обратно; "в прозрачном" - это как? [скип] > - возможно перемещение LV с LUKS между разными PV без угрозы защиты > данных; опечатка? [скип] > > Изменение размеров разделов LUKS вполне возможно, последовательность > стандартная: при увеличении - увеличить размер диска нижнего уровня, > заполнить добавленную часть мусором, увеличить размер раздела LUKS, > увеличить размер на следующем уровне. При уменьшении - в обратную > сторону. > Нюансы появляются при определении той части диска, которую требуется > заполнить мусором. Наиболее лёгкий вариант, но плохо подходящий при > изменении размеров при параллельной штатной работе системы - сначала > увеличить размер файловой системы, потом создать на ней файл, заполнив > до конца доступное место, и удалить его. Другие варианты требуют > расчётов размера раздела LUKS и потенциально опасны. Где-то так?: Хотим увеличить на 1Гб LUKS раздел c ФС ext3 на LVM томе "LV1": # lvextend -L+1G /dev/vg00/LV1 # cryptsetup luksOpen /dev/vg00/LV1 foo # resize2fs /dev/mapper/foo # mount -t ext3 /dev/mapper/foo /mnt/mountpoint $ dd if=/dev/urandom of=/mnt/mountpoin/big.file bs=1M $ rm -f /mnt/mountpoin/big.file тут нигде "cryptsetup resize -b" махать не надо? А если отрезать 1G от такого LUKS раздела - lvextend не повыкидывает нужные LE (т.е., LE заполненные шифр-кашей LUKSа видятся для LVM как LE с данными?)? Какая из трёх вышеперечисленных комбинаций на Ваш взгляд наиболее сбоеустойчивая? >> 2. Нужен ли скрипт [где его пристроить?], выполняемый перед выключением >> для корректного размонтирования/даективации такого «бутерброда»? [скип] В разделе раздел Mounting and umounting этой статьи: http://linuxgazette.net/140/pfeiffer.html некий Рене Файфер предлагает варианты скриптов для старта/завершения связки RAID-LUKS-LVM. Насколько они актуальны для AltLinux Desktop P5? [скип] Огромное спасибо за развёрнутый ответ! По сути вышла почти готовая статья на тему сабжа :) -- WBR........[ ] TFTHAOT....[x] AMF........[ ] ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2010-05-28 15:37 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-05-20 14:18 [Comm] RAID, LVM & LUKS Vaso VV 2010-05-25 6:45 ` Vaso VV 2010-05-26 8:27 ` Nikolay A. Fetisov 2010-05-28 15:37 ` Vaso VV
ALT Linux Community general discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/community/0 community/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 community community/ http://lore.altlinux.org/community \ mandrake-russian@linuxteam.iplabs.ru community@lists.altlinux.org community@lists.altlinux.ru community@lists.altlinux.com public-inbox-index community Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.community AGPL code for this site: git clone https://public-inbox.org/public-inbox.git