Хабр Курсы для админов
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Администрирование доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 13
Вроде ж МРД не сертифицировано для BTRFS?
Официально да, Astra не поддерживает Btrfs. В чате астры в телеграме проскакивали сообщения о рассмотрении официальной поддержки.
Сам я использую только МКЦ, но у меня ранее спрашивали работает ли МРД. Чисто технически все работает, т.к. МКЦ/МРД это всего лишь расширенный атрибут на файле/каталоге, т.е. сделать официальную поддержку ничего не мешает.
Но данный скрипт в принципе переносит не только астру.
Вопрос в том, что в btrfs могут быть способы получить доступ к информации в обход мандатных меток. Например, через процедуру удалённой репликации и т.д.
как раз сегодня астру1.8.4 установленную на ext4 перенес на btrfs с сжатием zstd:15 так:
создал в виртуалке новый диск, на него установил астру по минимуму на btrfs (эти дурни в инсталляторе не могут добавить строку customs для монтирования, чтобы опции сжатия для btrfs добавить)
запустился с livecd, примонтировал корень старой системы в /mnt/ext4/, и новую в /mnt/btrfs/ с опцией -o compress-force=zstd:15
через mc удалил из /mnt/btrfs/ всё кроме /boot/ и /etc/fstab
и просто скопировал всё кроме /boot/ и /etc/fstab из /mnt/ext4/ в /mnt/btrfs/
копировалось сразу со сжатием
добавил в /mnt/btrfs/etc/fstab опцию для сжатия
в итоге: 40Гб с ext4 сжались в 15Гб на btrfs
виртуальный диск скопировал на физический.
всё загрузилось и не пришлось даже обновлять grub и initramfs (т.к. ядро одинаковое)
кстати, где для астры новое ядро взять ? сейчас 6.12, хотелось бы 6.17
Астра компилит только lts ядра. Остается надеяться, что скомпилят 6.18 для astra 1.8.
можно было чуть проще, ext4 вполне себе конвертируется в btrfs прямо наживую, потом поправить uid раздела в fstab и cmdline, обновить конфиг граба, ребут. после ребута можно удалить созданный блочный сабвол нужный для отката назад и всё.
делал так несколько раз, всё работает отлично
Я ведь правильно понимаю, что проблема, которую вы решаете, в том, что инсталлятор системы поддерживает Btrfs в принципе, но не даёт возможности указать, что на какой сабвольюм ставить и с какими параметрами эти сабвольюмы нужно создать?
Если так, то эту можно поступить немного проще: у тома Btrfs есть параметр "сабвольюм по умолчанию". Он отвечает за поведение при монтировании без явной опции -o subvol= — а инсталляторы, по всей видимости, монтируют файловые системы именно так. И идея состоит в том, чтобы самостоятельно создать нужную иерархию сабвольюмов, выбрать дефолтный, а потом сказать инсталлятору, чтобы он использовал файловую систему как есть, не форматируя.
Я в прошлом году проверял эту идею, когда устанавливал серверную Ubuntu. Выглядело это так. Когда загрузился инсталлятор, я переключился в консоль и вручную разметил диск, создал файловую систему и сабвольюм с нужным именем:
# cfdisk /dev/sda
# mkfs.btrfs --label ubuntu --data single --metadata single /dev/sdaX
# mount /dev/sdaX /mnt
# btrfs subvolume create /mnt/@
# btrfs subvolume set-default /mnt/@
# umount /mnt
После этого вернулся в инсталлятор, выбрал там "Leave formatted as btrfs, mountpoint: /" и установил систему. А уже после перезагрузки в установленную систему перенёс /home на отдельный сабвольюм и поправил fstab (хотя это можно было сделать и сразу, до перезагрузки).
Я сам не проверял (потому что мне не нужно было так сложно), но кажется, что идея останется рабочей, даже если добавить создание дополнительных сабвольюмов @/home, @/var/tmp, @/var/tmp и т.д. с индивидуальной настройкой их параметров.
на убунте и дебиане можно впринципе выкинуть инсталер на мороз и ставить систему при помощи debootstrap получив гораздо больше гибкости чем даёт инсталлер.
впрочем и на других дистрибутивах можно подобное, только в случае с rpm based дистрибутивами вам не нужен отдельный инструмент, пакетные менеджеры dnf и zypper сами могут поставить систему в отдельный корень родив тем самым новую систему.
Я ведь правильно понимаю, что проблема, которую вы решаете, в том, что инсталлятор системы поддерживает Btrfs в принципе, но не даёт возможности указать, что на какой сабвольюм ставить и с какими параметрами эти сабвольюмы нужно создать?
Да
Если так, то эту можно поступить немного проще:...
С астрой так не получится, т.к. при установке напрямую в subvolume, на корне раздела не будет атрибута security.PDPL, без которого МКЦ/МРД на сабволумах использовать не получится. Т.е. должна быть соблюдена иерархия меток (корень-раздела-->subvolume). Именно поэтому я в скрипте сначала из chroot ставлю метку на корень раздела, а потом разношу всё по сабволумам. В данном случае корректную установку прямо на сабволумы, а не перенос, может сделать только разработчик астры.
А уже после перезагрузки в установленную систему перенёс /home на отдельный сабвольюм и поправил fstab
И опять же нужно будет выполнять перенос в другие сабволумы после установки и править fstab. Просто я это как раз автоматизировал.
при установке напрямую в subvolume, на корне раздела не будет атрибута security.PDPL
Возможно, это не будет проблемой — корневой сабвольюм Btrfs-раздела ведь даже никуда не примонтирован, по идее, модуль ядра, отвечающий за контроль этих меток, его даже не видит, и с его точки зрения файловая иерархия начинается с того сабвольюма, куда установлена система.
корректную установку прямо на сабволумы, а не перенос, может сделать только разработчик астры
И я ведь правильно понимаю, что этот security.PDPL — просто расширенный атрибут файла/каталога, такой же как security.selinux? Его можно перенести с каталога на каталог при помощи setfattr или каких-то специфичных инструментов Астры?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ОС linux на btrfs subvolume. Изобретаем велосипед вместо дистрибьюторов