The guides provide detailed guidance on performing specific tasks or utilize specific features provided by Apertis.

For higher level descriptions of the technology employed in Apertis, please see the architecture documents.

Application distribution using Flatpak

Apertis Flatpak demo Apertis provides a demo Flatpak application. This demo includes a runtime containing the libraries required to run the GNOME Fonts application. In order to install the demo application, the Flatpak repositories for both the runtime and application must first be setup: $ flatpak --user remote-add --no-gpg-verify apertis-demo-runtime https://images.apertis.org/flatpak/runtime $ flatpak --user remote-add --no-gpg-verify apertis-demo-app https://images.apertis.org/flatpak/app You can then proceed with the installation: $ flatpak --user install org.apertis.demo.gnome_font_viewer During installation you will be prompted for which version to install. [Read More]

Device Hardening

Apertis reference implementation provides packages and images geared towards development, allowing more flexibility than actual products. This guidance is targeted towards teams building products with Apertis to aid them with “hardening” the general-purpose development Apertis image/packages to reduce the attack surface on products. This document also lightly touches on measures that can be taken to physically harden a device. The procedures detailed below reduce the attack surface of the Apertis image and in some cases will provide improvements to other facets such as storage optimization and boot performance which are also likely to be important to product teams. [Read More]

Security and Access Control

AppArmor is a Linux Security Module (LSM) implementation, which enforces Mandatory Access Control (MAC) on a system. AppArmor comprises of both a kernel module and user space profiles for each application. Apertis uses AppArmor to enforce security polices for applications and services to allow access to resources based on their profiles. Depending on the mode the application or service is running, AppArmor can generate audit logs or deny access to system resources in order to track or prevent undesired accesses. [Read More]

Apertis integration testing with LAVA

LAVA is a testing system allowing the deployment of operating systems to physical and virtual devices, sharing access to devices between developers. As a rule tests are started in non-interactive unattended mode and LAVA provides logs and results in a human-readable form for analysis. As a common part of the development cycle we need to do some integration testing of the application and validate it’s behavior on different hardware and software platforms. [Read More]

Automated Licensing Compliance Install

Automated Licensing Compliance Install As described in Automated License Compliance a check is performed on image creation to confirm the compliance with the terms that Apertis may wish to avoid. To support this feature several pieces of software need to be installed. FOSSology The recommended FOSSolgy setup consist in FOSSology server PostgreSQL database server Apache HTTP server We recommend to build this setup trough a Docker installation as described in FOSSolgy Docker installation [Read More]

SDK Persistent Workspace

The SDK is distributed as VirtualBox images, with one VirtualBox image for each version of Apertis. As the SDK is designed to be used for development, it is highly likely that developers using it will adjust the SDK to their needs. These changes include installing tools, libraries, changing system configuration files, and adding content to their workspace. Additionally some developers may have to support different versions of the SDK at the same time and it may be advantageous for them to be able to synchronize their customizations between multiple SDK VirtualBox images. [Read More]

Adding and Updating Components

Apertis stores the source of all the shipped packages in GitLab and uses a GitLab CI pipeline to manage the workflows and automate many of the tasks that are required to release a package, thus for many tasks such as adding or updating packages, interaction is only required with GitLab, with automation taking care of the rest of the process. Please see the Apertis workflow for more information regarding the automation provided by Apertis. [Read More]

Apertis Release Process

This document aims as a single resource for all information related to Apertis Release Process. It covers the Major Release process as well as the Point Release process. Apertis Infrastructure The Apertis project is hosted on a couple of infrastructure services, which are tightly coupled to each other, providing end-to-end automation. This includes: Landing new packages into Apertis Landing new security and general updates into Apertis Landing downstream changes into Apertis This document stands as a comprehensive guide to all package related processes as outlined above. [Read More]

VirtualBox

The recommended virtual machine platform for the AMD64 Apertis system images is VirtualBox. It is typical for the Apertis SDK to be run in a virtual machine, though other image types can also be used. This enables development to be performed on computers running Windows, Mac OS, or different Linux distributions. System requirements You will need a PC with the following configuration to install and run the SDK: Hardware Dual core CPU at 2GHz or higher 8 GB RAM or more 12 GB or more free space on the hard disk If your PC supports Virtualization Technology, make sure that it is enabled. [Read More]

Evaluating Vendor Kernels for Use In Apertis

Often target platforms are not supported by Apertis. This may be due to the way the Apertis components are built/configured or due to these components lacking support for the required hardware. Whilst they may lack support in Apertis, these boards frequently have reference images based on another Linux variant with the associated source code being available. This support is often provided in a Yocto-based deliverable. The support generally provides good coverage of the vendors hardware, however the quality of implementation can vary quite dramatically. [Read More]