{"id":106211,"date":"2022-12-21T15:37:51","date_gmt":"2022-12-21T13:37:51","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vtoroj-prototip-platformy-alp-idushhej-na-smenu-suse-linux-enterprise"},"modified":"2022-12-21T15:37:51","modified_gmt":"2022-12-21T13:37:51","slug":"vtoroj-prototip-platformy-alp-idushhej-na-smenu-suse-linux-enterprise","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/vtoroj-prototip-platformy-alp-idushhej-na-smenu-suse-linux-enterprise","title":{"rendered":"Die zweite Prototypversion der ALP-Plattform, die SUSE Linux Enterprise ersetzen soll","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Das Unternehmen SUSE hat den zweiten Prototyp der ALP \"Punta Baretti\" (Adaptable Linux Platform) ver\u00f6ffentlicht, der als Fortsetzung der Entwicklung der SUSE Linux Enterprise Distribution positioniert wird. Ein herausragendes Merkmal von ALP ist die Aufteilung der Basis des Distributionssystems in zwei Teile: ein reduziertes \"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. Die Builds sind f\u00fcr die Architektur x86_64 vorbereitet. ALP wird urspr\u00fcnglich in einem offenen Entwicklungsprozess entwickelt, bei dem Zwischenversionen und Testergebnisse \u00f6ffentlich f\u00fcr alle Interessierten zug\u00e4nglich sind. <\/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

Wesentliche \u00c4nderungen im zweiten Prototyp von ALP: <\/p>\n