Building and installing Linux packages in Russian certified OS

Introduction

Earlier, in this article, we described building extensions for LibreOffice. Now we will tell you how the developments were transferred to the Linux platform, as well as how the issues with the preparation of packages for Russian certified operating systems, such as AstraLinux, ALTLinux and RedOS, were resolved.

Problem statement and primary implementation

After the successful implementation of our DSS product for the Windows platform, it was necessary to transfer the developments (including the extension for LibreOffice to C ++, the assembly and installation of sdk of which was described earlier) to the platforms of the Linux family.

Package composition

Accordingly, it is necessary to determine what we are transferring:

• service for communication with the server;
• driver for intercepting and processing file requests;
• service for communication and processing information from the driver;
• dialog application;
• encryption service;
• extension for LO.

The last point is the easiest to integrate, since the Linux build for it is described in our article.
As for the services for communication with the server and for handling calls to the file system, they are written in .net core, and this framework from version 3.0 is also easily portable to Linux.
We replaced the Windows driver with the Linux Kernel Module (LKM); details on how to create it will be described in a future article.

The encryption service also had to be rewritten a bit, as it is implemented in C ++.
To port the application that provides us with a dialog box, written in WinForms, we used the Avalonia framework. A separate article will be created on application and complexity. Also, it became necessary to add the launch of this application by pressing the RMB on a specific file. On Ubuntu, filemanager-actions (aka nautilus-actions in earlier versions) helped with this. With the help of it, you can add almost any script for RMB processing, but, I repeat, within the framework of Ubuntu (as it will turn out later in AltLinux).

Assembly

Now that we have decided on the content, let’s first build the deb package.
Since we have services, they need to be demonized. For this we use systemd.
Initially, it was decided to use checkinstall to build a deb package. The first package was built using it. But when adding an assembly to CI, there were / had problems with the build environment, dependencies and scripts before / after installation. Therefore, it was decided that it is better to do this through fakeroot. For the most part, these steps have been described in this article.
We create a separate directory containing instructions for systemd, which we then move to / lib / systemd / system.
Create a directory with the contents that need to be transferred when installing the package.
And also create a DEBIAN directory containing scripts for actions before / after installation / removal and control, describing the basic information of the package and its dependencies.
After the content is created, execute fakeroot dpkg-deb –build “package name”.
As a result, at the output we have a deb package with the contents.

Installation, uninstallation and verification of work

We install it with the command:

sudo dpkg -i «имя пакета».deb

We delete with the commands:

sudo dpkg -r «имя пакета»(указанное в файле control)

sudo dpkg --purge «имя пакета»(указанное в файле control)

During installation, 3 daemon are transferred and launched (applications running in the background, analogous to Microsoft services).
To check their performance, we perform:

systemctl status «имя демона».service

For example, the status of our dssservice

Next, we began testing the package and identifying all the dependencies that were not taken into account during the creation process. After successfully processing all the dependencies, one interesting detail emerged. If we want to connect via rdp to the machine, then this functionality must be configured, since by default, there is no server for connecting via this protocol, as on Microsoft. The easiest way to configure rdp is to configure xrdp with xfce4. When configuring xfce4, Thunar is used as a conductor and, accordingly, the item in the RMB that we added via filemanager-actions is not added for it. But the solution was found pretty quickly – being in the home directory, we go along the following path:

.config/Thunar/

and there will be a uca.xml file containing scripts for RMB.

Deployment of packages in Russian certified OS

After successfully testing this package on Ubuntu, the question arose about its performance on other OS using dpkg as a package manager, and, accordingly, supporting .deb. And, in particular, I remembered the domestic development (no one canceled import substitution) – AstraLinux.

AstraLinux

It was not possible to install the package on the fly, since our package has filemanager-actions in its dependencies, which we use to add a RMB item to Nautilus Ubuntu. But AstraLinux uses the fly file manager, and we will not use filemanager-actions to add it to it, we came to the conclusion that for AstraLinux we will build the package without taking into account this dependency. And to add the script “process_name” .desktop is used, which is added to / usr / share / flyfm / actions /.
Also, some points related to LKM have been resolved, but we will look at them in the next article.

Build RPM

The next OS was ALTLinux. It is interesting in that it has an APT package manager, but instead of dpkg it uses rpm. And, therefore, it’s time for us to build our package under rpm.

Initially we tried to convert deb to rpm as described in this tutorial.
Alien is a powerful enough utility and with its help you can simply convert a package, you just need to follow its prompts and add the missing (if she asks about it). As a result, when converting, we received an rpm package, but when trying to install it, dependencies came out, links to which were not initially there (I’ll tell you later what was the highlight). Therefore, it was decided to build the rpm package directly using rpmbuild.

At first, they decided to build not for ALTLinux, but for RedOs, since from the business side there are more promising plans for it. RedOs is based on CentOS, so they decided to build in it.
The systemd part remains unchanged, but Debian is replaced with the “project_name” .spec file, which contains all the information and dependencies from control, scripts for actions before / after installation / removal, as well as a description of the package contents (directly the path to what needs to be added).

After creating the file, execute:

rpmdev-setuptree

transfer the .spec to rpmbuild / SPECS and execute:

rpmbuild --bb rpmbuild/SPECS/dssservice.spec

after which we take the created package from the rpmbuild / RPMS directory.

We are trying to install the package and stumble upon the same dependencies that were when trying to install the converted deb package.

As it turned out, the highlight is that when executable files are added to rpm, the system thinks that they may need to be rebuilt, and makes the necessary packages dependent for this. To avoid this, you need to add a line to the .spec file after the description of the dependencies:

Autoreq: no

We try to install and yes – victory, the package is installed correctly.

To install the rpm package, use the command:

sudo rpm -ivh "имя_пакета".rpm

To remove (without removing dependency packages):

sudo rpm -e --nodeps ""имя_пакета""

RedOs

Next, you need to figure out the dependencies, since the packages necessary for the operation of our applications already have different names, and also, you need to figure out how to add an item to the RMB.
RedOs uses nemo as its file manager. To add an item to it in the RMB, you need to create a file “action_name” .nemo_action, in which, by analogy with the .desktop file (for AstraLinux), there will be a script for handling clicking on a new menu item, and move it to ~ / .local / share / nemo / actions /, restart nemo and the item will appear.

ALTLinux

After successfully testing the rpm package on RedOs, we switched to creating an rpm package under
ALTLinux. In fact, it is necessary to adjust the dependencies, since for each axis the packages will have their own name and again understand how to add an item to the RMB. Here filemanager-actions again came to our aid, through which you can also add items to the RMB for Mate and Caja, which are exactly used in ALTLinux.
As a result, we have compiled packages for the main OS used by the customer.

Conclusion

In future articles, we will tell you why we used LKM and Avalonia and what difficulties we faced because of this, as well as what further plans for improving the packages (in particular, improving the UI to enter the necessary information) and the applications used in them.

Links that helped us

• ithelp21.ru/udalennoe-podklyutchenie-k-ubuntu-tcherez-rdp – a good instruction that our testers used to add rdp on Ubuntu
• pingvinus.ru/note/nautilus-context-menu-items – setting nautilus-actions
• www.debian.org/doc/manuals/maint-guide/build.ru.html – deb build
• linux-notes.org/pishem-init-skript – Init script for systemd