id: Гость   вход   регистрация
текущее время 10:31 29/03/2024
Автор темы: Гость, тема открыта 22/09/2005 12:56 Печать
http://www.pgpru.com/Форум/UnixLike/PGPDiskПодLinuxСистемыШифрования
создать
просмотр
ссылки

"PGP Disk под Linux" / системы шифрования


Существует простая и замечательная программка – PGP Disk, я использую версию 6.0.2i. Знает ли кто-нибудь способы монтирования *.pgd -файлов под Linux ? (хоть под какую-нибудь версию). Сейчас живу на 98-й винде, но про Линукс не раз задумывался. Переезду мешает отсутствие ряда программ, и PGP Disk в их числе. Кто что думает по этому поводу ?


 
На страницу: 1, 2, 3, 4, 5 След.
Комментарии
— Гость (03/05/2013 14:16)   <#>

Если на красную кнопку нажать, вылезет меню, там есть штуки 4 опции. Одна из них suspend, другая — hibernate. Судя по вами пописанной ситуации, вы использовали suspend.


Есть, но рисковано и геморройно :)


Это не для новичков. :) Например, лично я с этим серьёзно не разбирался, было дешевле попросить сделать того, кто знает.

Логика примерно такова: уменьшается файловая система (shrink file system),* уменьшается логический том, создаётся другой логический том, туда переносятся данные. Это если вы хотите отедльную файловую систему для /home. Если есть желание сделать её отдельным DOS-разделом на диске — это уже другое, там надо будет ещё с физическим томом поиграться.

Иерархия примерно такова: физический диск → физический криптотом → группа логических томов lvm (в т.ч. своп там обычно), причём шифрование происходит на уровне физического криптотома вроде бы. Смотреть, что куда смонтировано и как — man lvdisplay, man pvdisplay.

*Команда наподобие resize2fs -p /dev/mapper/УСТРОЙСТВО
— Гость (03/05/2013 14:31)   <#>

>Судя по вами пописанной ситуации
Извиняюсь, пост пал жертвой собственных многократных исправлений. :(
— Гость (04/05/2013 01:00)   <#>
не факт что получится без потерь изменить корень и выделенное пространство отправить под home в новый lvm-том.
есть пакет gui для работы с lvm2.
нужно запустить систему и воспользоваться этим пакетом изнутри.
— Гость (04/05/2013 04:28)   <#>

Что концептуальное может, по-вашему, помешать? Кривизна рук разве что?
— Гость (04/05/2013 13:50)   <#>
Что концептуальное может, по-вашему, помешать?
теоретически ничего. но бэкап важной инфы лучше сделать.
— Гость (04/05/2013 19:22)   <#>
бэкап важной инфы лучше сделать.
Это всегда рекомендуется делать, при любой процедуре. :)
— unknown (04/05/2013 22:15)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
По повоту гибернации. Если стоит стандартный пакет hibernate, то имеются соответственно /usr/sbin/hibernate-disk и /usr/sbin/hibernate-ram. Смотрите их вывод, syslog, dmesg. Возможны варианты. В т.ч. гибернация нестандартным способом TuxOnIce со своим шифрованием. Таким шифрованием пользоваться не рекомендуется.

По поводу переразбивки LVM. Если шифрован физический том, а логические на нём — нет (а по дефолту скорее всего так), то можно делать resize2fs, вот только не знаю, делает ли она усечение (shrink) на работающем смонтированном корне. В любом случае, корень лучше сбэкапить (на другой шифрованый носитель).

Далее возможны варианты. Даже если resizefs shrink пройдёт нормально, то после этого надо уменьшить логический том корневого раздела. lvresize для этого подходит, но разница с lvreduce не очень ясна. Нельзя уменьшить до размера, меньшего, чем усечённая ФС — иначе потеря данных. Но если урезать сам том недостаточно, то может возникнуть ошибка при загрузке с предложением запустить filesystemcheck, который услужливо снесёт всю систему, правда показав перед этим кучу предупреждений и ошибок. Тогда нужно отказаться от исправлений filesystemcheck и сделать опять resize2fs, но с расширением до нового размера корневого тома, это делается точно и без ошибок, нужно только указать том в качестве устройства, а размер не задавать, он подгонится сам.

Если что-то из этого не работает, возможно придёться поднимать расшифрованный физический том cryptsetup luksOpen /dev/sd[x]2 /dev/mapper/root[name], затем pvscan, затем lvchange -a y, проделывая нечто из предыдущего абзаца, но уже с live-CD/live-USB на отмонтированной корневой системе.

После того как успешно создан уменьшенный логический том корня, на свободном пространстве физического тома создаётся том под /home посредством lvcreate, mkfs и прописывается в /etc/fstab.

Если логический том корня всё-таки повредили, то его придёться пересоздать, сделать mkfs и накатить систему из бэкапа.

pvchange -a n [name] – отцепление томов, тоже бывает полезно при закрытии раздела. При зависании томов есть жестокие команды dmsetup ls, dmsetup remove -f -j [number_1] -m [number_2] — это если у вас отвалился какой-нибудь usb-носитель с бэкапом, например: чтобы не ребутиться, а просто его переткнуть.

При более сложных конфигурациях возможны приключения с перепаковкой рамдиска, внесением туда, в новый корень в /etc/cryptab, /boot/grub.cfg новых UID, но вроде это не ваш случай. Т.е. выкрутиться можно практически из любой ситуации, если самому не сделать какой-то фатальный шаг, хотя при наличии бэкапа можно хоть весь винчестер стереть, только затем будет больше геморроя с ручной настройкой конфигов, UID, GRUB, LVM, dm-crypt. Опять же, зависит от желания и возможности разобраться, как это всё работает.
— Гость (04/05/2013 23:09)   <#>

Такое впечатление, что пособие для самоубийц пишете. :) Естественно, все операции с корнем нужно выполнять, загрузившись
с live-CD/live-USB

С живой подмонтированной файловой системы даже бэкап посредством dd выполнять не рекомендуется по вполне понятным причинам. Я подозреваю, что система и не даст сделать shrink для подмонтированной файловой системы (то же самое, возможно, касается и ряда операций с lvm).
— Гость (04/05/2013 23:09)   <#>
иногда бывает проще переустановить систему в нужной конфигурации разделов, чем краить и "резайзить". тем более, когда речь идет о зашифрованных разделах.
— unknown (04/05/2013 23:21, исправлен 04/05/2013 23:40)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Ладно, в форуме можно написать неточно вспоминая, не до конца вникая, второпях и несвязно. Но хотя бы предупредив о возможных неточностях. Но в man только путём некоторого логического предположения можно понять, что налету можно делать expand, а не shrink:


If the filesystem is mounted, it can be used to expand the size of the mounted filesystem, assuming the kernel supports on-line resizing. (As of this writing, the Linux 2.6 kernel supports on-line resize for filesystems mounted using ext3 and ext4.).

kernel supports on-line resize for filesystems

Даже если не выдирать эту фразу из контекста, по ману про shrink просто умалчивается: либо пользователь сам догадается, что on-line resize не относится к shrink, а только к expand; либо какой-то другой вариант.


Но явного однозначного толкования не дано.



Но можно делать LVM-снэпшоты :) Бэкап лучше делать таром, сделав
А ещё есть cpio и rsync. Главное переносить файлы на другую ФС, зачем dd? Причём при bind-монтировании получим корректный бэкап без мусора, с которого можно обратно накатить рабочую систему. Проверено неоднократно, только в таких вещах много чего может вылезти, с чем придёться разбираться по ходу дела. Поэтому трудно советовать на все случаи жизни и у многих есть некоторые отличия в выборе методик.



Зависит от ситуации, от опыта таких низкоуровневых ковыряний. Как-то что-то подобное приходилось делать, но с мотивацией: если не получится, то тогда можно и заново переустановить. Получилось, какой-то дополнительный опыт появился :)

— Гость (05/05/2013 01:33)   <#>

За тем, что в dd думать не надо, и получим полный валидный клон диска.1 Не надо думать о наличествующих файловых системах, разделах и пр. В конце концов, не надо монтировать критические данные на длительный по времени срок только для того, чтобы их сбэкапить.2 Тем не менее, всё, конечно же, зависит от задачи и ситуации. Я бы сделал rdiff-backup и потом восстановил из него. Можно играться с cpio и архивами, но это минное поле. Могут побиться права, неправильно раскрыться симлинки и т.д. Учтите, что в корне много спецфайлов, типа тех, что в директории /dev, и все их надо корректо обработать. Когда-то делал бэкапы каких-то директорий методом
# find / -xdev -depth -path /path/to\* -o -print0 | cpio -pvd0m /mnt
и что-то не сработало, потому что в конкретно моей версии cpio был один непофиксенный баг. Грабли раскиданы повсюду, и надо с этим играться постоянно, чтобы знать, что работает, а что нет. Если никогда ранее подобные операции не проводились, вероятность того, что блин будет комом, стремится к единице.


А при dd не придётся, если не будете пытаться смонтировать одновременно старую и новую файловые системы (это вызовет конфлит идентичных uuid'ов).


1Это если битых секторов нет. Если же они есть, то имеются другие тулзы, производные от dd, которые всё равно автоматически всё сделают.
2Первый бэкап для дисков современной ёмкости — это очень не быстро.
— unknown (05/05/2013 14:12)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Раньше были баги в cpio и tar. Обычно, они возникали из-за того, что на исходной ФС были неполадки и из-за неправильного чтения файла, tar или cpio вываливался с ошибкой. Поскольку — это очень древние и широко используемые утилиты, то их регулярно фиксят. Метод бэкапа и переразвёртывания из-под работающей системы tar'ом, rsync'om, cpio многократно опробован. Особенно полезно, когда надо переносить данные на другое железо, на винты или разделы других размеров, копировать по сети через ssh.


А dd бэкапит много лишнего, в т.ч. возможно дефекты ФС. Опять же, в поставленной задаче после бэкапа dd, снятый образ как-то придётся примонтировать, чтобы тем же таром из-него переносить данные на новый LV с другим размером.
— Гость (05/05/2013 21:59)   <#>

На системе, релизнутой в 2010-ом году, наткнулся позже на какой-то баг в cpio, связанный то ли с сохранением permission'ов на файлы, то ли ещё чем, уже не помню. Но в целом с вами согласен. Метод dd — скорее экстренное снятие копии с диска в момент, когда понимаешь, что он умирает и счёт его жизни, возможно, пошёл уже на часы или минуты, а разбираться с другими тулзами некогда, т.к. инфраструктура для нормальных бэкапов не была сделана. Для всех других случаев хватает тех же, например, rdiff-backup, rsync и пр.
— Гость (09/05/2013 19:42)   <#>

resize2fs делается, естественно, не на лету, и до ресайза лог. тома с корнем. Я всегда делал так: уменьшал с запасом, потом ресайзил лог. том, потом делал еще один ресайз ФС с автоподгонкой под том.
— pgprubot (26/09/2015 22:59, исправлен 13/10/2015 20:24)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

Скрипт для случая «expand»:

#!/bin/sh
 
# Enlarging encrypted LVM
# The device must be already mounted
 
LUKS_NAME=$1   # (without path ``/dev/mapper/'' and ``_crypt'')
SIZE=$2        # Size of enlarging. E.g. 10G.
 
LUKS_DEVICE=${LUKS_NAME}_crypt && \
echo LUKS device is: $LUKS_DEVICE && \
DIR=$(mount |grep $LUKS_DEVICE |cut -d ' ' -f3) && \
echo It is mounted on: $DIR && \
LVM_DEVICE=$(cryptsetup status $LUKS_DEVICE \
            |grep 'device:' |sed 's/^.*\/dev/\/dev/') && \
echo It is on LV: $LVM_DEVICE
 
set -x
umount /dev/mapper/$LUKS_DEVICE && \
fsck -C0 -f /dev/mapper/$LUKS_DEVICE && \
sync; sleep 1 && \
cryptsetup luksClose $LUKS_DEVICE && \
sync; sleep 1 && \
lvextend -L +$SIZE $LVM_DEVICE && \
cryptsetup luksOpen $LVM_DEVICE $LUKS_DEVICE && \
cryptsetup -v resize $LUKS_DEVICE && \
mount /dev/mapper/$LUKS_DEVICE $DIR && \
umount $DIR && \
e2fsck -C0 -f /dev/mapper/$LUKS_DEVICE && \
resize2fs /dev/mapper/$LUKS_DEVICE && \
mount /dev/mapper/$LUKS_DEVICE $DIR
Предполагается, что увеличивается размер LUKS-шифрованного логического тома LVM, который на момент запуска скрипта уже куда-то подмонтирован, но вы увидели, что там недостаточно места. Скрипт сам определяет, куда подмонтирована файловая система (ФС) с LUKS'а, и с каким LV ассоциирован данный LUKS. Скрипт сам отмонтирует ФС, увеличивает размер файловой системы и снова монтирует её туда же — вы получаете ровно то же состояние системы (mount'ы, открытые LUKS'ы), какое было до скрипта, но с увеличенным размером ФС. Для тех ФС, которые не ext<N>, скрипт из коробки не заработает, его придётся редактировать.


Пример метода запуска:



Эта команда увеличила на 20M LUKS-том, который в тот момент был подмонтирован и открыт как /dev/mapper/LUKSNAME_crypt.** Учтите, что скрипт не проверяет, используется ли в данный момент эта ФС какими-то процессами, т.е., если нужно, вы должны вручную завершить все нужные процессы до запуска скрипта. Предупреждение «WARNING: This metadata update is NOT backed up», вероятно, вызвано тем, что в /etc/lvm/ не сохраняются логи с информацией обо всех когда-либо подключавшихся LVM-устройствах.


P.S. Когда тестировал, при первом запуске скрипт почему-то поругался на luksClose, что блочное устройство кем-то используется, хотя это было не так. Само устройство скриптом при этом всё-таки было успешно отключено. На будущее поставил для гарантии (и без понимания) sync и sleep в двух местах, и больше такая ошибка не писалась. Может быть, это излишне, а первый раз просто случился какой-то глюк.


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


** Концовку «_crypt» при запуске скрипта указывать не надо. Если у вас приняты другие именования расшифрованных блочных устройств, исправьте скрипт до его запуска под свой случай.

На страницу: 1, 2, 3, 4, 5 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3