Guides

Apertis maintains an instance of Eclipse cloud2edge that can be used to test the IoT images using Eclipse Kanto. The following sections describe how to set up the IoT image’s suite-connector configuration to be able to connect to this instance. The following sections describe how to set the IoT image’s suite-connector configuration. Required Information Various stub values will be seen throughout the commands in this document that will need to be replaced. [Read More]

The purpose of this guideline is to provide advice how to handle evolution of your API/ABI in order to minimize breakage and keep your library binary compatible as much as possible. Other higher level Apertis documents are available regarding the API stability: Supported API aims to explain the relevant issues around API (Application Programming Interface) and ABI (Application Binary Interface) stability. It introduces as well, the strategy used by several big projects to maintain a certain stability without sacrificing the evolution of their components. [Read More]

This guide aims to explain how to build your first image on Apertis using the GitLab UI. A comprehensive documentation to manually build a customized image is available at Image building. This document will explain how to create a GitLab account and how to use its UI and pipelines to modify and create a custom Apertis image. Create a GitLab account To build your Apertis image, you first need an account on the Apertis GitLab instance. [Read More]

This guide will give an overview of the Apertis reference Flatpak runtimes, as well as creating, signing, and publishing your own runtimes and applications. Reference Runtimes Apertis provides a reference Flatpak runtime, available in two variants: org.apertis.headless.Platform and org.apertis.headless.Sdk: A basic runtime with some common libraries that headless applications may use. org.apertis.hmi.Platform and org.apertis.hmi.Sdk: A larger runtime for graphical applications, based on the headless one but with additional packages included that are generally needed by graphical applications. [Read More]

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]

This document outlines the OBS ACL feature that has been implemented on the Collabora instance of OBS. This is a feature specific to Collabora OBS only. Background OBS currently supports creating multiple projects but it lacks support for a more fine-grained access restriction, for instance to allow certain projects to have a restricted view of other repositories. This support has been implemented by Collabora using ACLs for projects. This document describes the details of the implementation and how to use it. [Read More]

AppArmor is a Linux Security Module (LSM) implementation, which enforces Mandatory Access Control (MAC) on individual application basis. AppArmor confines applications by only allowing access to resources or privileges which are explicitly whitelisted in the profile which is associated with the application. Since AppAmor uses a path-based approach, a great deal of flexibility regarding which applications to confine is achieved. Hence, not all applications on a system need to be confined. [Read More]

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 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 FOSSology Docker installation [Read More]

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]