Barium:модули
Содержание
Что за модули такие
UIRD создает корневую файловую систему для дальнейшей загрузки ОС из слоев собранных объединяющей файловой системой aufs/overlayfs. В качестве слоев может использоваться все что возможно смонтировать в Линукс в режиме read only. Чаще всего это squashfs архивы, это и есть модули Бария. Squashfs архив отличает то, что данные из него можно читать блочно, то есть для того чтобы извлечь файл нет необходимости распаковывать весь архив, распаковываются только блоки, в которых лежат части этого файла. Помимо уменьшения размера ОС это часто дает прирост в скорости чтения, особенно с медленных носителей, относительно чтения не сжатых данных с того же носителя. Это происходит потому, что прочитать 1 мегабайт и распаковать его в 3 мегабайта с "быстрым" процессором и "медленным" носителем, будет быстрее чем читать не сжатые 3 мегабайта. Каждый такой модуль содержит свою часть файловой системы. Модуль не равен rpm пакету по содержимому, он может содержать как один файл, так и всю ОС, как это бывает в livecd.
Подключение и отключение модулей
Корневая rootfs собирается на этапе UIRD (initrd Бария) из модулей. Модули при этом подключаются из нескольких каталогов по определенным правилам. Системные модули лежат в /.memory/layer-base/0/base. При обновлении ОС эти модули заменяются новыми. Если положить модуль сюда он будет подключен при старте системы. Но для собственных модулей предназначены другие каталоги:
/.memory/layer-base/0/modules /.memory/layer-base/1/modules
Основное отличие в том, что второй каталог находится на шифрованном разделе предназначенном для пользовательских данных, а первый на системном разделе. (При стандартной установке) Если использовать aufs вместо overlayfs у вас появится возможность подключать и отключать модули "на горячую" используя утилиты:
barium add module.xzm barium rm module.xzm
С overlayfs такая возможность не доступна.
Как сделать модуль
Squashfs архивы создаются утилитой mksquashfs из пакета squahfs-tools, и модули вполне можно сделать имея только mksquashfs, но для большего удобства подготовлено несколько утилит в составе barium-utils.
barium mkmod
Основная задача утилиты сделать модуль из папки с файлами, дополнительно можно склеивать папки и модули в один модуль в любых сочетаниях. Например: У вас есть два файла - программа и ее конфиг. В системе они должны быть размещены по путям:
/usr/bin/superproga /etc/superproga.d/superproga.conf
- Создаем папку с именем будущего модуля:
mkdir ./superproga
- Внутри папки создаем нужные каталоги. Обратите внимание на права и пользователя каталогов. Для системных папок обычно достаточно создавать их под рутом.
mkdir -p ./superproga/usr/bin mkdir -p ./superproga/etc/superproga.d
- копируем файлы в папки, допустим они у нас тоже были в текущем каталоге
cp ./superproga ./superproga/usr/bin/ cp ./superproga.conf ./superproga/etc/superproga.d/
- Пакуем
barium mkmod ./superproga
Итогом будет модуль superproga.xzm, при подключении которого файлы окажутся в системе в нужных подкаталогах. Модули невозможно редактировать, они монтируются только RO, поэтому, если вам нужно будет что-то изменить, придется собирать модуль заново. Если же нужно добавить файл в модуль, можно воспользоваться режимом "склейки" утилиты barium mkmod
mkdir -p ./superproga2/etc/skel/.config/ cp superproga.conf ./superproga2/etc/skel/.config/ barium mkmod ./superproga2 ./superproga.xzm -o superproga2.xzm
Распаковка модулей
Для распаковки модуля проще всего смонтировать модуль и забрать содержимое из точки монтирования. Также можно использовать утилиту unsquashfs. Для разборки составного ("склеенного") модуля есть утилита barium split
barium dnf2mod
Пожалуй наиболее востребованная утилита для сборки модулей. Она использует dnf. То есть устанавливает в модуль запрошенные пакеты из репозитория, вместе с зависимостями и результатом выполнения скриптов из rpm. После установки из модуля удаляются базы rpm, dnf и кэши. Таким образом, при подключении модуля, база rpm не изменится и пакеты не будут зарегистрированы как установленные в системе. Это сделано для того, чтобы модули не были инкрементно зависимы. Любой модуль собранный dnf2mod зависит только от базовых модулей системы и может быть удален в любой момент не нарушая работу других модулей.
Например:
barium dnf2mod nano
Соберет пакет с редактором nano. Пакет будет собран даже в том случае, если nano уже есть в базовой системе. Это позволяет, например, выборочно обновить пакет не дожидаясь обновления всей системы.
Можно передать список модулей:
barium dnf2mod nano mc busybox
С ключoм "-с" утилита будет использовать системные настройки и кэши dnf. В конце строки с параметрами после ключа --dnf можно дописать параметры, которые будут передаваться dnf при установке, например --repofrompath. Нет необходимости запоминать параметры сборки модуля, они хранятся внутри и запустив
barium dnf2mod nano.xzm
вы пересоберете модуль с теми же параметрами как он был собран, но с обновленными пакетами из репозитория.
barium chroot2mod
Утилита пакует в модуль изменения файлов произошедшие в chroot, которые являются результатом выполнения команды или скрипта. Rootfs для chroot при этом собрана из базовых модулей системы. Звучит малопонятно, далее на примерах.
barium chroo2mod -o nano.xzm --command dnf install nano
Утилита создаст rootfs из базовых модулей так, как это делает uird, выполнит в chroot указанную команду, и запакует только новые и измененные в результате выполнения команды файлы.
Результат будет близок к barium dnf2mod nano, за исключением того, что кэши и базы rpm и dnf автоматически не удаляются.
В данном примере используется dnf, но утилита с ним никак не связана, можно запустить какой-то консольный конфигуратор или wget или просто /bin/bash и сделать все руками, после выхода из оболочки все будет запаковано.
Для более сложных случаев вместо параметра --command используется --script, которому передается сценарий сборки, обычно это bash, но не принципиально.
Пример:
Создаем скрипт getproga.sh для гипотетического проекта proga, для простоты допустим, что компилировать не нужно, только забрать скрипты c гит репозитория
#!/bin/bash # устанавливаем необходимые для сборки пакеты dnf install git-core cd /tmp # клонируем проект с гит репозитория git clone https://server/user/proga.git # устанавливаем chmod +x ./proga/bin/* cp ./proga/bin/* /usr/bin/ # зачищаем dnf remove git-core dnf clean all rm -rf /var/cache/dnf
Делаем исполняемым:
chmod +x getproga.sh
Запускаем сборку:
barium chroo2mod -o proga.xzm --script ./getproga.sh
Для того, чтобы использовать внутри сборочной рутфс файлы, находящиеся снаружи (то есть в основной системе), используем параметр --bind. Ему передается два пути к папкам разделенные двоеточием. Первый путь снаружи rootfs, второй внутри. В таком случае --script уже не нужен, указываем --command /путь/в/rootfs/скрипт.sh
Пример:
Создаем папку, в которой будут файлы для сборки модуля. Переносим в нее yandex-browser.rpm Рядом создаем скрипт yb.sh:
#!/bin/bash # переходим в каталог с файлами для сборки cd $(basedir $0) # устанавливаем rpm dnf install -y ./yandex-browser.rpm # зачищаем (если нужно) dnf clean all rm -rf /var/cache/dnf # и т.д.
Делаем исполняемым:
chmod +x yb.sh
Находясь в каталоге со скриптом и rpm пакетом запускаем сборку.
barium chroot2mod -o yandex-browser.xzm --bind ./::/var/lib/YB --command /var/lib/YB/yb.sh
Еще более сложный реальный пример скрипта, для сборки аналогичным способом. С подключением локального каталога с rpm пакетами как репозитория:
#!/bin/bash BASE=$(dirname $0) dnf install -y lsb || echo lsb > /tmp/problem.packages echo "[localrepo] name=tmprepo baseurl=file://${BASE}/REPO enabled=1 gpgcheck=0" > /etc/yum.repos.d/tmp.repo # включаем i686 репозитории for a in $(ls -1 /etc/yum.repos.d |grep i686) ; do sed -i 's/enabled.*/enabled=1/' /etc/yum.repos.d/$a done dnf refresh pushd $BASE cp -fax ./CERT/* / || echo "error ${LINENO}" #Установка корневых сертификатов update-ca-trust enable tar -xf /tmp/stunnel/dis/root_crt.tar.gz -C /etc/pki/ca-trust/source/anchors/ cat x86_64.need |grep -v '^#'| grep -v '^space:*$' | while read a ; do echo $a |xargs dnf install -y || echo $a >> /tmp/problem.packages done echo 'i686 ===============' >> /tmp/problem.packages echo "Install i686 packages" cat i686.need |grep -v '^#'| grep -v '^space:*$' | while read a ; do echo $a |xargs dnf install -y --forcearch i686 || echo $a >> /tmp/problem.packages done echo 'Problem rpms ===========' >> /tmp/problem.packages echo "Install problem packages" cat problem_rpm.need |grep -v '^#'| grep -v '^space:*$' | while read a ; do echo ========= $a =============== dnf download $a name=$(ls -1 |grep -i $a) rpm -Uhv --nodeps ./$name || echo $a >> /tmp/problem.packages rm - $name done # подключение библиотек смарткарт к цитриксу ln -sf /usr/lib64/libeToken.so '/opt/Citrix/ICAClient/PKCS#11/' ln -sf /usr/lib64/libjcPKCS11-2.so '/opt/Citrix/ICAClient/PKCS#11/' # сертификат для цитрикс-клиента cp /etc/pki/127.0.0.1.crt /opt/Citrix/ICAClient/keystore/cacerts/127.0.0.1.pem /opt/Citrix/ICAClient/util/ctx_rehash # русская клавиатура для цитрикса sed -i 's/KeyboardLayout=/KeyboardLayout=Russian/g' /opt/Citrix/ICAClient/config/All_Regions.ini sed -i 's/KeyboardLayout=/KeyboardLayout=Russian/g' /opt/Citrix/ICAClient/config/usertemplate/All_Regions.ini # systemctl daemon-reload # обновляем системное хранилище сертификатов для браузера update-ca-trust # подключаем в загрузку туннели systemctl enable iuspt-in.service systemctl enable iuspt-out.service mkdir -p /opt/cprocsp/var/run/stunnel # подключаем сертификаты к КриптоПро /opt/cprocsp/bin/amd64/certmgr -install -store mCA -file /etc/pki/gazprom_inform_ca_gost_2012.cer /opt/cprocsp/bin/amd64/certmgr -install -store mROOT -file /etc/pki/root_gazprom_ca_gost_2012.cer # устанавливаем скрипт для файрфокса в автостарт chmod +x setup_user.sh cp setup_user.sh /usr/lib/rosa-rw/rc.desktop/all/ popd rm -f /etc/yum.repos.d/tmp.repo dnf clean all rm -rf /var/cache/dnf
Модули собранные утилитой barium chroot2mod, также как и с dnf2mod, хранят cmdline сборки, но пересобраться смогут только те, что собраны независимо, то есть без локальных файлов.
Проекты для chroot2mod
Если модуль предполагается периодически пересобирать для обновления, а сборка требует сценарий и дополнительные файлы, вместо --script удобнее использовать новый параметр --project, которому передается имя папки с проектом. Здесь проект это каталог, который содержит один обязательный файл - build.c2m, а также другие файлы и папки нужные вам для сборки. Файл build.c2m это скрипт, обычно bash, но не обязательно. Он должен иметь права на выполнение. Логика написания скрипта такая же ка для --script. Плюсы --project в том что такие проекты удобнее хранить и собирать.
barium chroot2mod --project ./project_dir
Пример build.c2m для сборки модуля КонтинетАп:
#!/bin/bash cd $(dirname $0) # делаем текущей папку с build.c2m и cts.rpm dnf install ./cts* # устанавливаем локальный rpm файл cts, а также необходимые зависимости. Можно rpm -Uhv если зависимостей нет. systemctl enable cts # включаем сервис cts по умолчанию
barium diff-changes
Утилита помогает вычислять изменения произошедшие в системе и делать модули содержащие эти изменения. Этот способ хуже подходит для сборки модулей чем chroot2mod так как фоновые процессы тоже могут вносить изменения и мы это не контролируем. Но иногда может быть полезной например если нужная вам утилита имеет только графический установщик. В простейшем случае процесс создания модуля с diff-changes выглядит так:
barium diff-changes # создается контрольная точка
Далее выполняете в системе действия по установке и настройке, так как вы бы это делали например в ROSA CHROME. После завершения:
barium diff-changes -d -m
- -d рассчитать разницу
- -m собрать модуль содержащий новые и измененные файлы
Если создано несколько контрольных точек нужно будет дополнительно указать нужную ключом -i. Контрольные точки можно именовать при создании, тогда итоговый модуль будет иметь имя как у контрольной точки.
barium diff-changes -p -i yandex-browser dnf install -y ./yandex-browser.rpm dnf clean all barium diff-changes -i yandex-browser -d -m new
Параметр "new" ключа -m указывает собирать модуль только из новых файлов и игнорировать измененные.
Это только пример, конкретно в этой ситуации правильнее использовать chroot2mod.
Зачем же нужна утилита если не гарантирует корректность созданных модулей. Основная задача diff-changes помочь вам определить какие файлы были изменены или добавлены, с тем, чтобы использовать эту информацию для сборки модуля другим способом или настройки сохранения в модули для этих файлов.
Решение проблем
Случается,что при некорректном завершении сборочных утилит остаются артефакты монтирований. Это может привести к невозможности сборки. В большинстве случаев поможет:
barium b-lib destroy_union 5 barium b-lib destroy_layers 5
"5" здесь предположительное количество некорректно завершенных заданий. Пишите больше не ошибетесь :)