Введение
Ранее, в статье мы описали сборку расширений для LibreOffice. Теперь мы расскажем, как наработки были перенесены на платформу Linux, а также как решались вопросы с подготовкой пакетов для российских сертифицированных операционных системах, таких как AstraLinux, ALTLinux и RedOS.
Постановка задачи и первичная реализация
После успешной реализации нашего продукта DSS для платформы Windows, потребовалось перенести наработки (в том числе и расширение для LibreOffice на C++, о сборке и установке sdk которого, было рассказано ранее) на платформы семейства Linux.
Состав пакета
Соответственно необходимо определить, что мы переносим:
- служба для связи с сервером;
- драйвер для перехвата и обработки обращений к файлам;
- служба для общения и обработки информации от драйвера;
- диалоговое приложение;
- служба шифрования;
- расширение для LO.
Последний пункт легче всего интегрировать, так как сборка под Linux для него описана в нашей статье .
Что касается служб для связи сервером и для обработки обращений к файловой системе, то они написаны на .net core, а данный фреймворк с версии 3.0 также легко переносим на Linux.
Windows драйвер мы заменили на Linux Kernel Module (LKM), подробности по его созданию будут описаны в одной из дальнейших статей.
Службу шифрования также пришлось немного переписать, так как она реализована на C++.
Для переноса приложения, обеспечивающего нас диалоговым окном, написанного на WinForms мы использовали фреймворк Avalonia. По применению и сложностям будет создана отдельная статья. Также возникла необходимость добавить запуск данного приложения через нажатие ПКМ на определённый файл. В Ubuntu в этом помог filemanager-actions (он же в ранних версиях nautilus-actions). При помощи него можно добавить практически любой сценарий обработки ПКМ, но, повторюсь, в рамках Ubuntu(как окажется далее ещё и в AltLinux).
Сборка
Теперь, когда мы определились с содержимым, для начала соберём 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)
При установке переносятся и запускаются 3и демона (приложения работающие фоном, аналог служб Microsoft).
Для проверки их работоспособности выполняем:
systemctl status имя демона.service
Для примера статус нашего dssservice
Далее началось тестирование пакета и выявление всех зависимостей, которые в процессе создания не были учтены. После успешной обработки всех зависимостей, выяснилась одна интересная деталь. Если мы хотим подключаться по rdp к машине, то данный функционал необходимо настроить, так как по дефолту, сервера для подключения по данному протоколу нет, как на Microsoft. Самым простым способом нaстройки rdp является настройка xrdp совместно с xfce4. При настройке xfce4 используется в качестве проводника Thunar и, соответственно, пункт в ПКМ, который мы добавляли через filemanager-actions, для него не добавляется. Но решение довольно быстро было найдено находясь в домашней директории проходим по следующему пути:
.config/Thunar/
и там будет лежать файл 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, сценарии для действий перед/после установки/удаления, а так же описание содержимого пакета (непосредственно пути до того, что необходимо добавить).
После создания файла выполняем:
rpmdev-setuptree
переносим .spec в rpmbuild/SPECS и выполняем:
rpmbuild --bb rpmbuild/SPECS/dssservice.spec
после чего забираем из директории rpmbuild/RPMS созданный
пакет.Пытаемся установить пакет и утыкаемся в те же самые зависимости, которые были при попытке установить конвертированный deb пакет.
Как оказалось, изюминка заключается в том, что при добавлении в rpm исполняемых файлов система думает, что, возможно, их необходимо будет пересобрать, и ставит необходимые для этого пакеты в зависимость. Чтобы такого не было необходимо в файл .spec добавить строку после описания зависимостей:
Autoreq: no
Пробуем установить и да победа, пакет корректно устанавливается.
Для установки 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
