Jump to content

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


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 удобнее использовать новый параметр --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