Barium:модули — различия между версиями

Текущая версия на 12:04, 24 марта 2023

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

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" здесь предположительное количество некорректно завершенных заданий. Пишите больше не ошибетесь :)