Barium:модули

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

UIRD создает корневую файловую систему для дальнейшей загрузки ОС из слоев собранных объединяющей файловой системой aufs/overlayfs. В качестве слоев может использоваться все что возможно смонтировать в Линукс в режиме read only. Чаще всего это squashfs архивы, это и есть модули Бария. Squashfs архив отличает то, что данные из него можно читать блочно, то есть для того чтобы извлечь файл нет необходимости распаковывать весь архив, распаковываются только блоки, в которых лежат части этого файла. Помимо уменьшения размера ОС это часто дает прирост в скорости чтения, особенно с медленных носителей, относительно чтения не сжатых данных с того же носителя. Это происходит потому, что прочитать 1 мегабайт и распаковать его в 3 мегабайта с "быстрым" процессором и "медленным" носителем, будет быстрее чем читать не сжатые 3 мегабайта. Каждый такой модуль содержит свою часть файловой системы. Модуль не равен rpm пакету по содержимому, он может содержать как один файл, так и всю ОС, как это бывает в livecd.

Как сделать модуль

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

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

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

   barium b-lib destroy_union  5
   barium b-lib destroy_layers 5 

Пять здесь предположительное количество некорректно завершенных заданий. Пишите больше не ошибетесь :)