- Сборка и установка Linux пакетов в российских сертифицированных ОС
- Постановка задачи и первичная реализация
- Состав пакета
- Сборка
- Установка, удаление и проверка работы
- Разворачивание пакетов в российских сертифицированных ОС
- AstraLinux
- Cборка RPM
- RedOs
- ALTLinux
- Заключение
- Ссылки которые нам помогли
- Устанавливаем RPM пакеты в Linux
- Что из себя представляет RPM?
- Устанавливаем RPM-пакет
- Программа RPM
- Пакетные менеджеры популярных дистрибутивов
- yum
- dnf
- zypper
- Графический интерфейс
Сборка и установка Linux пакетов в российских сертифицированных ОС
Ранее в статье мы описали сборку расширений для LibreOffice. Теперь мы расскажем, как наработки были перенесены на платформу Linux, а также как решались вопросы с подготовкой пакетов для российских сертифицированных операционных систем, таких как AstraLinux, ALTLinux и RedOS.
Постановка задачи и первичная реализация
После успешной реализации нашего продукта DSS для платформы Windows потребовалось перенести наработки (в том числе и расширение для LibreOffice на C++, о сборке и установке sdk которого было рассказано ранее) на платформы семейства Linux.
Состав пакета
Соответственно, необходимо определить, что мы переносим:
- служба для связи с сервером;
- драйвер для перехвата и обработки обращений к файлам;
- служба для общения и обработки информации от драйвера;
- диалоговое приложение;
- служба шифрования;
- расширение для LO.
Сборка
Теперь, когда мы определились с содержимым, для начала соберём deb пакет.
Так как у нас есть службы — их необходимо демонизировать. Для этого используем systemd.
Изначально было принято решение для сборки deb пакета использовать checkinstall. Первый пакет был собран при помощи него. Но при добавлении сборки в CI появились/возникли проблемы с окружением сборки, зависимостями и скриптами до/после установки. Поэтому было решено, что лучше это делать через fakeroot. Эти действия, по большей части, были описаны в данной статье.
Создаём отдельную директорию, содержащую инструкции для systemd, которую после перенесём в /lib/systemd/system.
Создаём директорию с содержимым, которое необходимо перенести при установке пакета.
А также создаём директорию DEBIAN, содержащую сценарии для действий перед/после установки/удаления и control, описывающий основную информацию пакета и его зависимости.
После созданного контента выполняем fakeroot dpkg-deb —build «имя пакета».
В итоге на выходе мы имеем deb пакет с содержимым.
Установка, удаление и проверка работы
Устанавливаем его командой:
sudo dpkg -i «имя пакета».deb
sudo dpkg -r «имя пакета» (указанное в файле control)
sudo dpkg --purge «имя пакета» (указанное в файле control)
При установке переносятся и запускаются три демона (приложения, работающие фоном, аналог служб Microsoft).
Для проверки их работоспособности выполняем:
systemctl status «имя демона».service
Для примера статус нашего dssservice
Далее началось тестирование пакета и выявление всех зависимостей, которые в процессе создания не были учтены. После успешной обработки всех зависимостей выяснилась одна интересная деталь. Если мы хотим подключаться по rdp к машине, то данный функционал необходимо настроить, так как по дефолту сервера для подключения по данному протоколу нет, как на Microsoft. Самым простым способом нaстройки rdp является настройка xrdp совместно с xfce4. При настройке xfce4 используется в качестве проводника Thunar и, соответственно, пункт в ПКМ, который мы добавляли через filemanager-actions, для него не добавляется. Но решение довольно быстро было найдено — находясь в домашней директории, проходим по следующему пути:
и там будет лежать файл uca.xml, содержащий сценарии для ПКМ.
Разворачивание пакетов в российских сертифицированных ОС
После успешного тестирования данного пакета на Ubuntu возник вопрос о работоспособности его на других ОС, использующих dpkg, как менеджер пакетов, а, соответственно, поддерживающих .deb. А, в частности, вспомнилась отечественная разработка (импортозамещение никто не отменял) — AstraLinux.
AstraLinux
С ходу установить пакет не удалось, так как наш пакет имеет в зависимостях filemanager-actions, который мы используем для добавления пункта ПКМ в Nautilus Ubuntu. Но в AstraLinux используется файловый менеджер fly, и для добавления в него мы не будем использовать filemanager-actions, пришли к выводу, что для AstraLinux будем собирать пакет без учёта этой зависимости. А для добавления используется сценарий «имя_процесса».desktop, который добавляется в /usr/share/flyfm/actions/.
Также были разрешены некоторые моменты, связанные с LKM, но их мы рассмотрим в следующей статье.
Cборка RPM
Следующей ОС стала ALTLinux. Она интересна тем, что имеет пакетный менеджер APT, но при этом вместо dpkg у неё используется rpm. А, следовательно, пора нам собрать наш пакет и под rpm.
Изначально попробовали сделать преобразование deb в rpm, как описано в этом мануале.
Alien достаточно мощная утилита, и с её помощью можно достаточно просто преобразовать пакет, достаточно только следовать её подсказкам и добавить недостающее (если она об этом попросит). В итоге при конвертации получили rpm пакет, но при попытке его установки вылезли зависимости, ссылок на которые изначально не было (позже расскажу, в чём была изюминка). Поэтому было принято решение собрать rpm пакет непосредственно средствами rpmbuild.
Сначала решили собирать не под ALTLinux, а под RedOs, так как со стороны бизнеса на неё более перспективные планы. RedOs основана на CentOS, поэтому сборку решили проводить в ней.
Часть с systemd остаётся без изменений, а вот Debian заменяем на файл «имя_проекта».spec, который содержит в себе всю информацию и зависимости из control, сценарии для действий перед/после установки/удаления, а так же описание содержимого пакета (непосредственно пути до того, что необходимо добавить).
После создания файла выполняем:
переносим .spec в rpmbuild/SPECS и выполняем:
rpmbuild --bb rpmbuild/SPECS/dssservice.spec
после чего забираем из директории rpmbuild/RPMS созданный пакет.
Пытаемся установить пакет и утыкаемся в те же самые зависимости, которые были при попытке установить конвертированный deb пакет.
Как оказалось, изюминка заключается в том, что при создании rpm система подтягивала дополнительные библиотеки, и ставила их в зависимость. Чтобы такого не было — необходимо в файл .spec добавить строку после описания зависимостей:
Пробуем установить и да — победа, пакет корректно устанавливается.
Для установки rpm пакета используем команду:
sudo rpm -ivh "имя_пакета".rpm
Для удаления (без удаления пакетов, находящихся в зависимости):
sudo rpm -e --nodeps ""имя_пакета""
RedOs
Далее необходимо разобраться с зависимостями, так как необходимые для работы наших приложений пакеты уже имеют другие названия, а также необходимо разобраться с добавлением пункта в ПКМ.
В RedOs в качестве файлового менеджера используется nemo. Для добавления в него пункта в ПКМ необходимо создать файл «имя_действия».nemo_action, в котором по аналогии с файлом .desktop (для AstraLinux) будет сценарий обработки нажатия на новый пункт меню, и переместить его в ~/.local/share/nemo/actions/, перезагрузить nemo и пункт появится.
ALTLinux
После успешного тестирования rpm пакета на RedOs перешли к формированию rpm пакета под
ALTLinux. По сути, необходимо скорректировать зависимости, так как для каждой оси пакеты будут иметь своё название, и снова понять, как произвести добавление пункта в ПКМ. Тут нам на помощь снова пришёл filemanager-actions, через который также можно добавить пункты в ПКМ и для Mate и Caja, которые как раз и используются в ALTLinux.
В итоге, мы собрали пакеты для основных, используемых у заказчика, ОС.
Заключение
В дальнейших статьях мы расскажем, почему использовали LKM и Avalonia и какие трудности из-за этого были, а также о дальнейших планах на доработку пакетов (в частности, доработка UI для ввода необходимой информации) и приложений, используемых в них.
Ссылки которые нам помогли
- ithelp21.ru/udalennoe-podklyutchenie-k-ubuntu-tcherez-rdp — неплохая инструкция, которой пользовались наши тестировщики для добавления rdp на Ubuntu
- pingvinus.ru/note/nautilus-context-menu-items — настройка nautilus-actions
- www.debian.org/doc/manuals/maint-guide/build.ru.html — сборка deb
- linux-notes.org/pishem-init-skript — Init скрипт для systemd
Устанавливаем RPM пакеты в Linux
Рассказываем о том, что такое RPM-пакеты, где они поддерживаются и как с ними обращаться.
Что из себя представляет RPM?
Ранее этот акроним расшифровывался как Red Hat Packet Manager. Из названия становится ясно, что это пакетный менеджер, разработанный компанией Red Hat. Только остается непонятным, что такое пакетный менеджер и что за компания такая Red Hat.
Пакетный менеджер — утилита, которая помогает распаковать в систему любое приложение и скачать все необходимые для его работы компоненты. Проще говоря — загрузчик и установщик программ в Linux.
Red Hat — ветераны в области создания операционных систем на базе Unix и Linux. На основе их Red Hat Linux были построены такие популярные дистрибутивы как Fedora, OpenSUSE и CentOS. Все они унаследовали RPM.
Также RPM — это формат файлов, который пакетный менеджер Red Hat может обрабатывать. Он довольно распространен и часто встречается на официальных сайтах популярных программ (типа Google Chrome или VS Code). Файлы в этом формате нужно скачивать, если вы используете дистрибутив на базе Red Hat Linux. Самые популярные из них: Fedora, OpenSUSE и CentOS.
Файлы RPM похожи на файлы DEB, которые используются в дистрибутивах на основе Debian (Ubuntu, Mint, Elementary OS) и в самом Debian.
Устанавливаем RPM-пакет
Для установки RPM-пакетов (то есть файлов в формате RPM) можно использовать сразу несколько инструментов. Один из них универсален для всех систем на базе Red Hat Linux, а остальные уникальны для каждого дистрибутива.
Программа RPM
Это как раз та самая универсальная утилита для работы с RPM-пакетами. С помощью нее можно устанавливать, обновлять, удалять и всячески управлять файлами в соответствующем формате.
Она работает следующим образом: вводится команда rpm, затем вводится режим, потом опции и в конце название пакета, над которым нужно провести заданные операции.
- -q — режим получения информации. Используется, чтобы получить определенную характеристику пакета. Например, какие зависимости ему нужны для нормальной работы.
- -i — режим установки. Тут и так все понятно.
- -V — режим проверки. В этом режиме утилита проводит сравнение файлов из пакета с теми, что уже находится в системе. В рамках ее интереса оказывается MD5-сумма, выданные разрешения, тип файла и так далее.
- -U — режим обновления. Тут тоже все ясно без дополнительных комментариев.
- -e — режим удаления. В этом режиме можно избавиться от пакета.
С опциями сложнее. Их количество насчитывает несколько десятков — описывать в этой статье все не имеет смысла. Но некоторые все-таки отметить стоит, так как они непосредственно участвуют в установке RPM-пакетов.
- v — это опция, включающая Verbose, то есть подробный лог всех выполняемых программой действий.
- –force — опция, которая вынуждает RPM выполнять все операции принудительно без дополнительного ожидания.
- __ –nodeps__ — эта опция заставляет RPM игнорировать зависимости в ходе установки пакета.
- __ –replacefiles__ — настройка, которая принуждает RPM к замене всех старых файлов на новые без лишних вопросов.
Также терминал можно запустить, одновременно нажав клавиши Ctrl + Alt + T
Вы можете работать из любой другой папки, но так удобнее
- Потом запускаем RPM.
- Для простой установки подойдет такая команда: sudo rpm -i название пакета.rpm.
Вот так просто можно установить Google Chrome в формате RPM
Чтобы в ходе установки выводить в консоль все, что происходит с RPM, вводим такую команду: __sudo rpm -iv *название пакета*.rpm__.
— Вы вправе комбинировать любые варианты опций и режимов.RPM несовершенен — он имеет один существенный минус, который перекрывает большую часть его преимуществ. Он не умеет находить и устанавливать зависимости. А это значит, что большую часть программ вы просто не сможете установить без ручного поиска зависимостей и ручной загрузки из разных репозиториев.
Ошибка, которая будет часто возникать, если не пользоваться современным менеджером пакетов
Поэтому в дистрибутивах на базе Red Hat Linux появились более продвинутые пакетные менеджеры для работы с RPM-файлами.
Пакетные менеджеры популярных дистрибутивов
Рассмотрим три самых распространенных пакетных менеджера.
yum
Этот вариант используется в дистрибутиве CentOS. Чтобы установить пакет с помощью него, введем в терминал команду sudo yum —nogpcheck localinstall название пакета.rpm.
Базовая команда для установки приложений с помощью YUM
dnf
Более продвинутая версия, которая используется в дистрибутиве Fedora. Чтобы установить пакет с помощью него, введем в терминал команду sudo dnf install название пакета.rpm
А вот так устанавливаются программы в Fedora
zypper
Это пакетный менеджер из операционной системы openSUSE. Чтобы установить пакет с помощью него, введем в терминал команду sudo zypper install название пакета.rpm.
Графический интерфейс
Этот способ установки подойдет тем, кто привык к работе с Windows.
- Просто загружаем RPM-пакет из интернета.
- Открываем его в любом файловом менеджере.
- Кликаем по нему дважды.