[Настройка Linux, Разработка под Linux] Сборка и установка Linux пакетов в российских сертифицированных ОС
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Введение
Ранее, в статьемы описали сборку расширений для 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
===========
Источник:
habr.com
===========
Похожие новости:
- [*nix, Игры и игровые приставки] Универсальный менеджер приложений (игр)
- [Разработка под iOS, Разработка мобильных приложений, IT-инфраструктура, Разработка под Android, DevOps] Да кто такой этот ваш Mobile DevOps?
- [Серверное администрирование, Amazon Web Services, DevOps, Облачные сервисы] Как защититься от неожиданных счетов за AWS (перевод)
- [Open source, *nix] FOSS News №47 – дайджест новостей и других материалов о свободном и открытом ПО за 14-20 декабря 2020 года
- [Системы сборки, DevOps] «Нюансы» использования TeamCity
- Red Hat объясняет трансформацию CentOS желанием сделать более открытой разработку RHEL
- [Тестирование IT-систем, Разработка мобильных приложений, IT-инфраструктура, Разработка под Android, DevOps] VirtualBox — Запуск Android эмулятора в виртуальной среде для тестирования Android проекта
- [SQL, Apache, DevOps, Data Engineering] Наши грабли — залог вашего успеха. Кейсы DevOps и SQL-команд
- [IT-инфраструктура, Машинное обучение, DevOps] Приглашаем на митап «Машинное обучение и инфраструктура вокруг него» 18 декабря в 14:00
- [Python, IT-инфраструктура, Администрирование баз данных, DevOps, Микросервисы] Vault+Pydantic: продолжение саги, локальная разработка
Теги для поиска: #_nastrojka_linux (Настройка Linux), #_razrabotka_pod_linux (Разработка под Linux), #_devops, #_bash, #_linux, #_blog_kompanii_cross_technologies (
Блог компании Cross Technologies
), #_nastrojka_linux (
Настройка Linux
), #_razrabotka_pod_linux (
Разработка под Linux
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 16:42
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Введение Ранее, в статьемы описали сборку расширений для LibreOffice. Теперь мы расскажем, как наработки были перенесены на платформу Linux, а также как решались вопросы с подготовкой пакетов для российских сертифицированных операционных системах, таких как AstraLinux, ALTLinux и RedOS.  Постановка задачи и первичная реализация После успешной реализации нашего продукта DSS для платформы Windows, потребовалось перенести наработки (в том числе и расширение для LibreOffice на C++, о сборке и установке sdk которого, было рассказано ранее) на платформы семейства Linux. Состав пакета Соответственно необходимо определить, что мы переносим:
Последний пункт легче всего интегрировать, так как сборка под 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/
Разворачивание пакетов в российских сертифицированных ОС После успешного тестирования данного пакета на 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
rpmbuild --bb rpmbuild/SPECS/dssservice.spec
Пытаемся установить пакет и утыкаемся в те же самые зависимости, которые были при попытке установить конвертированный 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 для ввода необходимой информации) и приложений, используемых в них. Ссылки которые нам помогли
=========== Источник: habr.com =========== Похожие новости:
Блог компании Cross Technologies ), #_nastrojka_linux ( Настройка Linux ), #_razrabotka_pod_linux ( Разработка под Linux ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 16:42
Часовой пояс: UTC + 5