Barium modules

Модули Бария (barium modules)

Что за модули такие

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 ./super-proga

Внутри папки создаем нужные каталоги. Обратите внимание на права и пользователя каталогов. Для системных папок обычно достаточно создавать их под рутом.

   mkdir -p ./super-proga/usr/bin 
   mkdir -p ./super-proga/etc/superproga.d 

Копируем файлы в папки, допустим они у нас тоже находятся в текущем каталоге:

   cp ./superproga ./super-proga/usr/bin/ 
   cp ./superproga.conf ./super-proga/etc/superproga.d/ 

 Пакуем

   barium mkmod ./super-proga 

Итогом будет модуль ./superproga.xzm, при подключении которого файлы окажутся в системе в нужных подкаталогах. Модули невозможно редактировать, они монтируются только RO, поэтому, если вам нужно будет что-то изменить, придется собирать модуль заново. Если же нужно добавить файл в модуль, можно воспользоваться режимом склейки утилиты barium mkmod:

   mkdir -p ./super-proga2/etc/skel/.config/ 
   cp superproga.conf ./superproga2/etc/skel/.config/ 
   barium mkmod ./superproga2 ./super-proga.xzm -o super-proga2.xzm 
                               

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

Утилита пакует в модуль изменения произошедшие c rootfs в 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 

Модули собранные утилитой barium chroot2mod, также как и с dnf2mod, хранят cmdline сборки, но пересобраться смогут только те, что собраны независимо, то есть без локальных файлов.

Проекты для chroot2mod

Если модуль предполагается периодически пересобирать для обновления, а сборка требует сценарий и дополнительные файлы, вместо "--script" и "--bind" удобнее использовать параметр "--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, и его зависимости. 
   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 помочь вам определить какие файлы были изменены или добавлены, с тем, чтобы использовать эту информацию для сборки модуля другим способом или настройки сохранения в модули для этих файлов.

Распаковка модулей

Для распаковки модуля проще всего смонтировать модуль и забрать содержимое из точки монтирования. Также можно использовать утилиту unsquashfs. Для разборки составного (склеенного из нескольких) модуля есть утилита barium split

Решение проблем

Случается,что при некорректном завершении сборочных утилит остаются артефакты монтирований. Это может привести к невозможности сборки. В большинстве случаев поможет:

   barium lib clear