The second prototype of the ALP platform, which is set to replace SUSE Linux Enterprise.

SUSE has released the second prototype of the ALP "Punta Baretti" (Adaptable Linux Platform), positioned as a continuation of the SUSE Linux Enterprise distribution. A key distinction of ALP is the division of the base distribution into two parts: a stripped-down "host OS" for running on hardware and a layer for application support, focused on running within containers and virtual machines. The builds have been prepared for x86_64 architecture. ALP is initially being developed using an open development process, where intermediate builds and testing results are publicly available to anyone interested.

The architecture of ALP is based on the development of the 'host OS' environment, which is the minimum necessary to support and manage hardware. All applications and user space components are suggested to run not in a mixed environment, but in separate containers or in units executed on top of the 'host OS' and isolated from one another. This organization will allow users to focus on applications and abstract workflows, separating them from the low-level system environment and hardware. virtual machines, executed on top of the 'host OS' and isolated from each other. This organization will allow users to focus on applications and abstract workflows, separating them from the low-level system environment and hardware.

The SLE Micro product, based on the MicroOS project, serves as the foundation for the 'host OS'. For centralized management, configuration management systems Salt (pre-installed) and Ansible (optional) are offered. For launching isolated containers, tools such as Podman and K3s (Kubernetes) are available. Among the system components moved into containers are yast2, podman, k3s, cockpit, GDM (GNOME Display Manager), and KVM.

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

A customizable automatic update installation mode is provided (for example, it is possible to enable auto-installation only for critical vulnerability patches or to revert to manual confirmation of update installations). Live patches are supported for updating the Linux kernel without rebooting and without interrupting operations. To maintain system resilience (self-healing), the last stable state is recorded using Btrfs snapshots (if anomalies are detected after applying updates or changing settings, the system automatically reverts to the previous state).

The platform uses a multi-version software stack — thanks to the use of containers, different versions of tools and applications can be utilized simultaneously. For example, applications that depend on different versions of Python, Java, and Node.js can run concurrently, isolating incompatible dependencies. Base dependencies are provided in the form of BCI (Base Container Images) sets. Users can create, update, and delete software stacks without affecting other environments.

Key changes in the second prototype of ALP:

  • The D-Installer has been implemented, where the user interface is separated from YaST's internal components and allows for the use of various front-ends, including a web interface for installation management. The basic interface for installation management is built using web technologies and includes a handler that provides access to D-Bus calls via HTTP, along with 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 the use of TPM (Trusted Platform Module) for decrypting the boot partition using keys stored in the TPM chip instead of passwords.
  • Some YaST clients (bootloader, iSCSIClient, Kdump, firewall, etc.) are now run in separate containers. Two types of containers have been implemented—management containers for working with YaST in text mode, GUI, and via the web interface, and testing containers for automated text testing. A number of modules have also been adapted for use in systems with transactional updates. A library, libyui-rest-api, with a REST API implementation has been proposed for integration with openQA.
  • Execution within the Cockpit platform containers has been implemented, on which the configurator and installer web interface is based.
  • Full disk encryption (FDE) is now available for installations on standard hardware, not just in virtualization and cloud systems.
  • GRUB2 has been adopted as the primary bootloader.
  • Configurations have been added for deploying containers for building a firewall (firewalld-container) and centralized management of systems and clusters (warewulf-container).

Source: opennet.ru

Buy reliable website hosting with DDoS protection, VPS VDS servers 🔥 Buy reliable website hosting with DDoS protection, VPS VDS servers | ProHoster