Die Firma SUSE hat den dritten Prototyp der ALP-Plattform \"Piz Bernina\" (Adaptable Linux Platform) ver\u00f6ffentlicht, die als Fortsetzung der Entwicklung der SUSE Linux Enterprise-Distribution positioniert ist. Das Hauptmerkmal von ALP ist die Aufteilung der Basis der Distribution in zwei Teile: ein abgespecktes \"Host-OS\" f\u00fcr den Betrieb auf der Hardware und eine Schicht zur Unterst\u00fctzung von Anwendungen, die auf Container- und Virtuellen Maschinen ausgerichtet ist. ALP wird von Anfang an in einem offenen Entwicklungsprozess entwickelt, bei dem Zwischenversionen und Testergebnisse \u00f6ffentlich verf\u00fcgbar sind. <\/p>\n
Der dritte Prototyp umfasst zwei separate Bereiche, die gegenw\u00e4rtig \u00e4hnliche Funktionen bieten, in Zukunft jedoch unterschiedliche Anwendungsbereiche und bereitgestellte Dienste entwickeln werden. F\u00fcr Tests steht der Bereich Bedrock zur Verf\u00fcgung, der auf den Einsatz in Serversystemen abzielt, sowie der Bereich Micro, der f\u00fcr die Entwicklung von cloud-nativen Systemen und die Ausf\u00fchrung von Microservices konzipiert ist. Fertige Builds sind f\u00fcr die Architektur x86_64 (Bedrock, Micro) verf\u00fcgbar. Zus\u00e4tzlich sind Build-Skripte (Bedrock, Micro) f\u00fcr die Architekturen Aarch64, PPC64le und s390x verf\u00fcgbar. <\/p>\n
Die Architektur von ALP basiert auf der Entwicklung einer Umgebung f\u00fcr das \"Host-OS\", die minimal erforderlich ist, um die Hardware zu unterst\u00fctzen und zu verwalten. Alle Anwendungen und Komponenten des Benutzerbereichs werden nicht in einer gemischten Umgebung, sondern in separaten Containern oder in virtuellen Maschinen wurde vereinfacht.<\/a>, die \u00fcber das «Host-Betriebssystem» ausgef\u00fchrt werden und voneinander isoliert sind. Diese Struktur erm\u00f6glicht es den Nutzern, sich auf Anwendungen zu konzentrieren und Arbeitsabl\u00e4ufe von der unteren Systemumgebung und der Hardware abzugrenzen. <\/p>\n Als Grundlage f\u00fcr das «Host-Betriebssystem» wird das Produkt SLE Micro verwendet, das auf den Entwicklungen des Projekts MicroOS basiert. F\u00fcr das zentrale Management stehen die Konfigurationsmanagementsysteme Salt (vorinstalliert) und Ansible (als Option) zur Verf\u00fcgung. Zum Starten isolierter Container kommen die Tools Podman und K3s (Kubernetes) zum Einsatz. Zu den systemtechnischen Komponenten, die in Container ausgelagert sind, geh\u00f6ren yast2, podman, k3s, cockpit, GDM (GNOME Display Manager) und KVM. <\/p>\n Zu den Besonderheiten der Systemumgebung geh\u00f6rt die standardm\u00e4\u00dfige Verwendung der Festplattenschl\u00fcsselung (FDE, Full Disk Encryption), wobei die Schl\u00fcssel im TPM gespeichert werden k\u00f6nnen. Die Root-Partition wird im Nur-Lese-Modus gemountet und \u00e4ndert sich w\u00e4hrend des Betriebs nicht. In dieser Umgebung kommt ein Verfahren zur atomaren Installation von Updates zum Einsatz. Im Gegensatz zu den atomaren Updates basierend auf ostree und snap, die in Fedora und Ubuntu verwendet werden, nutzt ALP anstelle der Erstellung separater atomarer Images und der Implementierung einer zus\u00e4tzlichen Lieferinfrastruktur den Standard-Paketmanager und den Snapshot-Mechanismus im Btrfs-Dateisystem. <\/p>\n Es gibt einen anpassbaren Modus f\u00fcr die automatische Installation von Updates (z. B. kann die Auto-Installation nur f\u00fcr kritische Sicherheitsupdates aktiviert oder auf die manuelle Best\u00e4tigung der Installationen zur\u00fcckgekehrt werden). Live-Patches unterst\u00fctzen die Aktualisierung des Linux-Kernels ohne Neustart und Unterbrechung des Betriebs. Um die Ausfallsicherheit des Systems (Self-Healing) zu gew\u00e4hrleisten, wird der letzte stabile Zustand durch Btrfs-Snapshots festgehalten (im Fall von Anomalien nach Updates oder \u00c4nderungen an den Einstellungen wird das System automatisch in den vorherigen Zustand versetzt). <\/p>\n In der Plattform wird ein mehrwertiger Software-Stack eingesetzt \u2013 dank der Verwendung von Containern k\u00f6nnen gleichzeitig verschiedene Versionen von Tools und Anwendungen genutzt werden. Zum Beispiel k\u00f6nnen Anwendungen, die unterschiedliche Versionen von Python, Java und Node.js als Abh\u00e4ngigkeiten verwenden, parallel ausgef\u00fchrt werden, wodurch inkompatible Abh\u00e4ngigkeiten getrennt werden. Die grundlegenden Abh\u00e4ngigkeiten werden in Form von BCI-Sets (Base Container Images) zur Verf\u00fcgung gestellt. Der Benutzer kann Software-Stacks erstellen, aktualisieren und l\u00f6schen, ohne andere Umgebungen zu beeintr\u00e4chtigen. <\/p>\n F\u00fcr die Installation wird der D-Installer verwendet, bei dem die Benutzeroberfl\u00e4che von den internen Komponenten von YaST getrennt ist. Es gibt die M\u00f6glichkeit, verschiedene Frontends zu nutzen, einschlie\u00dflich eines Frontends zur Verwaltung der Installation \u00fcber eine Weboberfl\u00e4che. Die Ausf\u00fchrung von YaST-Clients (Bootloader, iSCSIClient, Kdump, Firewall usw.) in separaten Containern wird unterst\u00fctzt. <\/p>\n Die Haupt\u00e4nderungen im dritten Prototyp von ALP: <\/p>\n\n