The second prototype of the ALP platform replacing SUSE Linux Enterprise

SUSE has published the second prototype of the ALP "Punta Baretti" (Adaptable Linux Platform), positioned as a continuation of the development of the SUSE Linux Enterprise distribution. The key difference between ALP is the division of the distribution's core foundation into two parts: a stripped-down "host OS" for running on top of the hardware and an application support layer focused on running in containers and virtual machines. The assemblies are prepared for the x86_64 architecture. ALP is initially developed using an open development process, in which intermediate builds and test results are publicly available to everyone.

The architecture of ALP is based on the development in the "host OS" of the environment, the minimum necessary to support and control equipment. All applications and user-space components are proposed to run not in a mixed environment, but in separate containers or in virtual machines running on top of the "host OS" and isolated from each other. This organization will allow users to focus on applications and abstract workflows from the low-level system environment and hardware.

The SLE Micro product, based on the developments of the MicroOS project, is used as the basis for the "host OS". For centralized management, Salt (preinstalled) and Ansible (optional) configuration management systems are offered. Podman and K3s (Kubernetes) toolkits are available for running isolated containers. Containerized system components include yast2, podman, k3s, cockpit, GDM (GNOME Display Manager), and KVM.

Of the features of the system environment, the default use of disk encryption (FDE, Full Disk Encryption) is mentioned with the ability to store keys in the TPM. The root partition is mounted in read-only mode and does not change during operation. The environment uses the mechanism of atomic update installation. Unlike the atomic updates based on ostree and snap used in Fedora and Ubuntu, ALP uses a regular package manager and the snapshot mechanism in the Btrfs file system instead of building separate atomic images and deploying additional delivery infrastructure.

A configurable mode for automatic installation of updates is provided (for example, you can enable automatic installation of only fixes for critical vulnerabilities or return to manual confirmation of installation of updates). Live patches are supported to update the Linux kernel without restarting or suspending work. To maintain the survivability of the system (self-healing), the last stable state is fixed using Btrfs snapshots (in case anomalies are detected after applying updates or changing settings, the system is automatically transferred to the previous state).

The platform uses a multi-version software stack, which allows you to use different versions of tools and applications at the same time through the use of containers. For example, you can run applications that depend on different versions of Python, Java, and Node.js by separating incompatible dependencies. Base dependencies come in the form of BCI (Base Container Images) sets. The user can create, update and remove software stacks without affecting other environments.

Main changes in the second ALP prototype:

  • The D-Installer installer is used, in which the user interface is separated from the internal components of YaST and it is possible to use various frontends, including the frontend for managing the installation through a web interface. The basic interface for plant management is built using web technologies and includes a handler that provides access to D-Bus calls via HTTP, and the web interface itself. The web interface is written in JavaScript using the React framework and PatternFly components. To ensure security, D-Installer supports installation on encrypted partitions and allows you to use the TPM (Trusted Platform Module) to decrypt the boot partition, using keys stored in the TPM chip instead of passwords.
  • Provided execution of some YaST clients (bootloader, iSCSIClient, Kdump, firewall, etc.) in separate containers. Two types of containers have been implemented - control containers for working with YaST in text mode, in the GUI and via the Web interface, and test containers for automated texting. A number of modules are also adapted for use in systems with transactional updates. For integration with openQA, the libyui-rest-api library with the implementation of the REST API is proposed.
  • Implemented execution in the container of the Cockpit platform, on the basis of which the web interface of the configurator and installer is built.
  • The possibility of using full disk encryption (FDE, Full Disk Encryption) in installations on top of conventional equipment is provided, and not only in virtualization systems and cloud systems.
  • GRUB2 is used as the main bootloader.
  • Added configurations for deploying containers for building a firewall (firewalld-container) and centralized management of systems and clusters (warewulf-container).

Source: opennet.ru

Add a comment