"PGP Disk под Linux" / системы шифрования
Существует простая и замечательная программка – PGP Disk, я использую версию 6.0.2i. Знает ли кто-нибудь способы монтирования *.pgd -файлов под Linux ? (хоть под какую-нибудь версию). Сейчас живу на 98-й винде, но про Линукс не раз задумывался. Переезду мешает отсутствие ряда программ, и PGP Disk в их числе. Кто что думает по этому поводу ?
Если на красную кнопку нажать, вылезет меню, там есть штуки 4 опции. Одна из них suspend, другая — hibernate. Судя по вами пописанной ситуации, вы использовали suspend.
Есть, но рисковано и геморройно :)
Это не для новичков. :) Например, лично я с этим серьёзно не разбирался, было дешевле попросить сделать того, кто знает.
Логика примерно такова: уменьшается файловая система (shrink file system),* уменьшается логический том, создаётся другой логический том, туда переносятся данные. Это если вы хотите отедльную файловую систему для /home. Если есть желание сделать её отдельным DOS-разделом на диске — это уже другое, там надо будет ещё с физическим томом поиграться.
Иерархия примерно такова: физический диск → физический криптотом → группа логических томов lvm (в т.ч. своп там обычно), причём шифрование происходит на уровне физического криптотома вроде бы. Смотреть, что куда смонтировано и как — man lvdisplay, man pvdisplay.
*Команда наподобие resize2fs -p /dev/mapper/УСТРОЙСТВО
>Судя по вами пописанной ситуации
Извиняюсь, пост пал жертвой собственных многократных исправлений. :(
есть пакет gui для работы с lvm2.
нужно запустить систему и воспользоваться этим пакетом изнутри.
Что концептуальное может, по-вашему, помешать? Кривизна рук разве что?
комментариев: 9796 документов: 488 редакций: 5664
По поводу переразбивки 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. Опять же, зависит от желания и возможности разобраться, как это всё работает.
Такое впечатление, что пособие для самоубийц пишете. :) Естественно, все операции с корнем нужно выполнять, загрузившись
С живой подмонтированной файловой системы даже бэкап посредством dd выполнять не рекомендуется по вполне понятным причинам. Я подозреваю, что система и не даст сделать shrink для подмонтированной файловой системы (то же самое, возможно, касается и ряда операций с lvm).
комментариев: 9796 документов: 488 редакций: 5664
Ладно, в форуме можно написать неточно вспоминая, не до конца вникая, второпях и несвязно. Но хотя бы предупредив о возможных неточностях. Но в man только путём некоторого логического предположения можно понять, что налету можно делать expand, а не shrink:
Даже если не выдирать эту фразу из контекста, по ману про shrink просто умалчивается: либо пользователь сам догадается, что on-line resize не относится к shrink, а только к expand; либо какой-то другой вариант.
Но явного однозначного толкования не дано.
Но можно делать LVM-снэпшоты :) Бэкап лучше делать таром, сделав
А ещё есть cpio и rsync. Главное переносить файлы на другую ФС, зачем dd? Причём при bind-монтировании получим корректный бэкап без мусора, с которого можно обратно накатить рабочую систему. Проверено неоднократно, только в таких вещах много чего может вылезти, с чем придёться разбираться по ходу дела. Поэтому трудно советовать на все случаи жизни и у многих есть некоторые отличия в выборе методик.
Зависит от ситуации, от опыта таких низкоуровневых ковыряний. Как-то что-то подобное приходилось делать, но с мотивацией: если не получится, то тогда можно и заново переустановить. Получилось, какой-то дополнительный опыт появился :)
За тем, что в dd думать не надо, и получим полный валидный клон диска.1 Не надо думать о наличествующих файловых системах, разделах и пр. В конце концов, не надо монтировать критические данные на длительный по времени срок только для того, чтобы их сбэкапить.2 Тем не менее, всё, конечно же, зависит от задачи и ситуации. Я бы сделал rdiff-backup и потом восстановил из него. Можно играться с cpio и архивами, но это минное поле. Могут побиться права, неправильно раскрыться симлинки и т.д. Учтите, что в корне много спецфайлов, типа тех, что в директории /dev, и все их надо корректо обработать. Когда-то делал бэкапы каких-то директорий методом
А при dd не придётся, если не будете пытаться смонтировать одновременно старую и новую файловые системы (это вызовет конфлит идентичных uuid'ов).
1Это если битых секторов нет. Если же они есть, то имеются другие тулзы, производные от dd, которые всё равно автоматически всё сделают.
2Первый бэкап для дисков современной ёмкости — это очень не быстро.
комментариев: 9796 документов: 488 редакций: 5664
А dd бэкапит много лишнего, в т.ч. возможно дефекты ФС. Опять же, в поставленной задаче после бэкапа dd, снятый образ как-то придётся примонтировать, чтобы тем же таром из-него переносить данные на новый LV с другим размером.
На системе, релизнутой в 2010-ом году, наткнулся позже на какой-то баг в cpio, связанный то ли с сохранением permission'ов на файлы, то ли ещё чем, уже не помню. Но в целом с вами согласен. Метод dd — скорее экстренное снятие копии с диска в момент, когда понимаешь, что он умирает и счёт его жизни, возможно, пошёл уже на часы или минуты, а разбираться с другими тулзами некогда, т.к. инфраструктура для нормальных бэкапов не была сделана. Для всех других случаев хватает тех же, например, rdiff-backup, rsync и пр.
resize2fs делается, естественно, не на лету, и до ресайза лог. тома с корнем. Я всегда делал так: уменьшал с запасом, потом ресайзил лог. том, потом делал еще один ресайз ФС с автоподгонкой под том.
комментариев: 511 документов: 2 редакций: 70
Скрипт для случая «expand»:
Пример метода запуска:
Эта команда увеличила на 20M LUKS-том, который в тот момент был подмонтирован и открыт как /dev/mapper/LUKSNAME_crypt.** Учтите, что скрипт не проверяет, используется ли в данный момент эта ФС какими-то процессами, т.е., если нужно, вы должны вручную завершить все нужные процессы до запуска скрипта. Предупреждение «WARNING: This metadata update is NOT backed up», вероятно, вызвано тем, что в /etc/lvm/ не сохраняются логи с информацией обо всех когда-либо подключавшихся LVM-устройствах.
P.S. Когда тестировал, при первом запуске скрипт почему-то поругался на luksClose, что блочное устройство кем-то используется, хотя это было не так. Само устройство скриптом при этом всё-таки было успешно отключено. На будущее поставил для гарантии (и без понимания) sync и sleep в двух местах, и больше такая ошибка не писалась. Может быть, это излишне, а первый раз просто случился какой-то глюк.
Скрипт основан на последовательности команд, рекомендованной одной заметкой в сети. Возможно, эта последовательность сомнительная, избыточная или в чём-то слишком перестраховочная, но я пока не видел, чтоб она приводила к каким-либо проблемам.
** Концовку «_crypt» при запуске скрипта указывать не надо. Если у вас приняты другие именования расшифрованных блочных устройств, исправьте скрипт до его запуска под свой случай.