Сборка проприетарного пакета с нуля
Данное руководство покажет, как правильно собрать пакет RPM в Sisyphus с нуля в инфраструктуре Gear и git.alt, не имея исходного кода пакета, на примере пакета StarBoardSoftware.
Входные требования
- Желательно иметь локальное зеркало Сизифа.
- Установленный и немного настроенный hasher[1].
- Пакет, который необходимо пересобрать для Сизифа.
- Ну, и самое главное, желание этим заниматься.
Исследование пакета
Первым делом нужно исследовать пакет на его кривость.
Для начала смотрим список файлов, которые появляются после установки пакета: rpm -qlp StarBoardSoftware-9.2.i586.rpm | less.
И видим, что все файлы ставятся в каталог /usr/local/.
Попытка установить пакет
Пробуем поставить этот пакет в hasher, на голую систему:
- hsh --initroot-only -v ~/hasher
- hsh-install -v `pwd`/StarBoardSoftware-9.2.i586.rpm
Следующие пакеты имеют неудовлетворенные зависимости: StarBoardSoftware: Требует: perl(strict) но пакет не может быть установлен E: Извините, `битые' пакеты
Удовлетворение зависимостей
Ладно, создаём фиктивный пакет со следующим спеком в ~/RPM/SPECS/:
Name: perl-strict Version: 1.0 Release: alt1 Provides: perl(strict) BuildArch: noarch Summary: perl(strict) Group: Test License: test %description %files %changelog
Выполняем
- rpmbuild -bb perl-strict.spec
Обрабатываются файлы: perl-strict-1.0-alt1 Provides: perl(strict) Записан: /home/becase/RPM/RPMS/noarch/perl-strict-1.0-alt1.noarch.rpm
Ставим наш самособранный пакет в hasher:
- hsh-install -v `pwd`/perl-strict-1.0-alt1.noarch.rpm
Вторая попытка установки
Второй подход к установке:
- hsh-install -v `pwd`/StarBoardSoftware-9.2.i586.rpm
Получаем вывод:
>>> preinst start PARAMETERS 1 /root/tmp/rpm-tmp.92646: line 36: rmmod: command not found <<< preinst end error: unpacking of archive failed on file /: cpio: utime failed - Operation not permitted hsh-install: Packages installation failed.
Из этого следует, что пакет перед установкой пытается выполнить какой-то скрипт preinst, далее нам не позволяют устанавливать корень системы.
Смотрим
- rpm -qlp StarBoardSoftware-9.2.i586.rpm | less head -n5
/ /usr /usr/local /usr/local/HitachiSolutions /usr/local/HitachiSolutions/StarBoard
Да, действительно почему-то авторы исходного пакета решили упаковать корень. В связи с этим, при установке этого пакета rpm пытается обновить дату создания /.
Запускаем mc mc, смотрим содержимое пакета, входя в него, как в архив. В частности, нас интересуют действия, выполняемые в сценариях установки. Они находятся в INFO/SCRIPTS/ во внутренностях пакета. Смотрим скрипты, ужасаемся и решаем, что ни в коем случае не следует устанавливать этот пакет как есть.
Зато видим, что в пункте postinstall выполняется команда
- /usr/local/StarBoardSoftware/installation-scripts/install.sh binary uspace app
Здесь-то и находится вся логика установки!
Извлечение файлов из пакета
Достаём файлы из пакета без установки:
- rpm2cpio StarBoardSoftware-9.2.i586.rpm | cpio -i
Как мы и ожидали, у нас появился каталог usr.
Для удобства дальнейшей работы упаковываем этот каталог в tar-архив: tar -cvf starboard_usr.tar usr
Исследование лицензии
Также исследуем файлы на предмет наличия лицензии. Находим ./usr/local/StarBoardSoftware/Resources/documents/COPYING, который содержит GPLv2. Также находим файл ./usr/local/StarBoardSoftware/Resources/documents/license/ru/license.rtf, который содержит следующие строки:
Передавать Программное обеспечение и все права по данному Соглашению третьей стороне вместе с копией данного Соглашения, если третья сторона соглашается принять положения и условия данного Соглашения. Если Вы передаете Программное обеспечение, Вы должны или одновременно передать третьей стороне все копии в печатной или машиночитаемой форме, включая все модификации и части Программного обеспечения, содержащиеся в других программах или объединенные с ними, или уничтожить все непереданные копии.
Значит, можно пакет пересобрать для Сизифа.
Под лицензией GPLv2 поставляется драйвер для доски StarBoard, будем считать, что он уже собран. В отличии от других систем, в ALTLinux скомпилированный драйвер ядра ставится в /lib/modules/`uname -r`/lsadrv/lsadrv.ko.
Автоматизация установки
Для множественных попыток установить этот софт в hasher создаём сценарий автоматизации.
#!/bin/sh -x #Корневой каталог системы в hasher root=$HOME/hasher/chroot #Корневой каталог программы sroot=/usr/local/StarBoardSoftware #Каталог с файлом starboard_usr.tar archive_dir=/media/disk/ALTLinux/left/starboard2010/StarBoardSoftware #Имя созданного нами архива archive_name=starboard_usr.tar #Префикс для запуска команды под фиктивным рутом в hasher prefix="hsh-run --rooter -- " #Пересоздание системы в hasher hsh --initroot-only -v ~/hasher #Список установки, будет дополняться, желательно как можно более приближающий систему в hasher к реальной install_list="kernel-modules-lsadrv-std-def" #Ставим в hasher пакеты из нашего списка hsh-install -v $install_list #Копируем наш архив в подкаталог фиктивного корня системы rsync --progress --inplace $archive_dir/$archive_name $root/.in/ #Запускаем от фиктивного рута установку файлов в фиктивный корень $prefix tar -xvf $archive_name -C / #Удаляем архив, чтобы не занимал место rm -f $root/.in/$archive_name #Запускается сценарий, в котором будут исправляться установочные сценарии . starboard-fix-install-script #Создаём файлы, в которых будет храниться списки файлов до запуска скрипта и после touch $root/.out/filelist.1 $root/.out/filelist.2 #Создаём от имени "рута" каталог, в котором будем хранить копию настроек системы $prefix mkdir /.res #Копируем содержимое настроек системы $prefix cp -ar /etc /.res/etc #Получаем список файлов до работы скрипта $prefix find / > $root/.out/filelist.1 #Запускаем скрипт, что-то вытворяющий с системой, которую нам не жалко $prefix $sroot/installation-scripts/install.sh #Получаем список файлов после работы скрипта $prefix find / > $root/.out/filelist.2 #Получаем список, отражающий, что этот скрипт натворил diff -Nau $root/.out/filelist.1 $root/.out/filelist.2 > $root/.out/files.diff #И как повлиял на содержимое файлов настройки $prefix diff -Naur /.res/etc /etc > $root/.out/etc.diff
Запуск установочного сценария
После запуска нашего скрипта получаем следующее.
Ошибки сценария:
/usr/local/StarBoardSoftware/installation-scripts/install.sh: line 318: [: =: unary operator expected /usr/local/StarBoardSoftware/installation-scripts/install.sh: line 326: $DEFAULTSLIST: ambiguous redirect
Смотрим, что добавилось:
- grep '+/' hasher/chroot/.out/files.diff
Что-то подозрительное:
+/tmp/fxduo.driver.build.log +/etc/ld.so.conf.d/lsadrv.conf +/lib/modules/2.6.35-std-def-alt9/kernel/drivers/usb/input
Выходит, что во время установки сценарий пытался скомпилировать драйвер и поставить его в /lib/modules/2.6.35-std-def-alt9/kernel/drivers/usb/input, но у него это не вышло. И ещё он решил добавить каталог поиска системных библиотек в /etc/ld.so.conf.d/lsadrv.conf, что не может не вызвать подозрение на нарушение целостности системы.
Смотрим, что там такое:
- cat hasher/chroot/etc/ld.so.conf.d/lsadrv.conf
/usr/local/lsadrv/lib
- ls hasher/chroot/usr/local/lsadrv/lib
libborqt-6.9.0-qt2.3.qm.ja liblsadev.so liblsdrv.so libQtCore.so libQtCore.so.4.5.2 libQtGui.so.4.5 libborqt-6.9.0-qt2.3.so liblsadev.so.0 liblsdrv.so.2 libQtCore.so.4 libQtGui.so libQtGui.so.4.5.2 libborqt-6.9-qt2.3.so liblsadev.so.0.0.0 liblsdrv.so.2.0.0 libQtCore.so.4.5 libQtGui.so.4
Наличие в /usr/local/lsadrv/lib библиотек Qt может пагубно повлиять на системные Qt-программы, если этот путь будет использоваться системой.
Изменённые настройки
- grep -a diff hasher/chroot/.out/etc.diff
diff -Naur /.res/etc/ld.so.cache /etc/ld.so.cache diff -Naur /.res/etc/ld.so.conf.d/lsadrv.conf /etc/ld.so.conf.d/lsadrv.conf diff -Naur /.res/etc/lsadrv/lsdrv.ini /etc/lsadrv/lsdrv.ini diff -Naur /.res/etc/lsdrv.ini /etc/lsdrv.ini diff -Naur /.res/etc/modules /etc/modules diff -Naur /.res/etc/modules.bak /etc/modules.bak diff -Naur /.res/etc/starboard/registry/HKEY_LOCAL_MACHINE.reg /etc/starboard/registry/HKEY_LOCAL_MACHINE.reg diff -Naur /.res/etc/udev/rules.d/42-starboard.rules /etc/udev/rules.d/42-starboard.rules
Отсюда видим, что изменился файл, в котором указывается список загружаемых при старте модулей /etc/modules, также изменился кэш с информацией о системных библиотеках /etc/ld.so.cache. Если первое ещё терпимо, то второе уж точно в данном случае допускать нельзя.
Исправление сценария установки
- cd ~/hasher/chroot/usr/local/StarBoardSoftware
- grep -r kernel/drivers/usb/input installation-*
installation-scripts/uninstall.sh:MODULELOC=/lib/modules/`uname -r`/kernel/drivers/usb/input/ installation-scripts/install.sh:MODULELOC=/lib/modules/`uname -r`/kernel/drivers/usb/input/ installation-tools/reinstalldriver.sh:MODULELOC=/lib/modules/`uname -r`/kernel/drivers/usb/input/ installation-tools/starboardservice: MODULEFILE=/lib/modules/`uname -r`/kernel/drivers/usb/input/lsadrv.ko
Примечания
- ↑ После установки hasher необходимо создать вспомогательных пользователей и перезайти в систему.