From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_00,DNS_FROM_OPENWHOIS, DNS_FROM_RFC_DSN autolearn=no version=3.2.5 Message-ID: <4BFFE335.40003@ukr.net> Date: Fri, 28 May 2010 18:37:25 +0300 From: Vaso VV User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10pre) Gecko/20100406 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: community@lists.altlinux.org References: <4BF5449C.3060606@ukr.net> <1274862449.18677.193.camel@v3405.naf.net.ru> In-Reply-To: <1274862449.18677.193.camel@v3405.naf.net.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Comm] RAID, LVM & LUKS X-BeenThere: community@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Community general discussions List-Id: ALT Linux Community general discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 15:37:32 -0000 Archived-At: List-Archive: List-Post: 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........[ ]