Einfacher eingespielt

von Martin Loschwitz

Bei SUSE bahnt sich eine Revolution an: Das altehrwürdige YaST geht in absehbarer Zeit in Rente – zumindest für die Installation des Grundsystems. Als Nachfolger steht Agama in den Startlöchern, das auf eine API-basierte Architektur mit Webclient setzt. So ermöglicht das neue Installationswerkzeug umfangreiche Automatisierung und bringt zudem mehr Flexibilität ins Deployment.

In der Linux-Welt ging um das Jahr 2000 SUSE Linux 6.4 mit YaST (Yet Another Setup Tool) an den Start und daran hat sich lange Zeit wenig geändert. Zwar existiert SUSE Linux heute nicht mehr in dieser Form, stattdessen begegnet uns SUSE Linux Enterprise Server oder openSUSE – YaST ist beiden Varianten jedoch bis heute gemeinsam. Noch immer fungiert es als zentrales Werkzeug für Installation und Konfiguration. Auch die fortlaufende Erweiterung des Funktionsumfangs, etwa durch AutoYaST, hat daran nichts geändert. Dennoch zeichnet sich in der SUSE-Welt ein tiefgreifender Wandel ab: Zumindest in seiner Rolle als Installationsroutine dürfte YaST absehbar vor dem Aus stehen.

Aus Sicht von SUSE gibt es dafür handfeste Gründe. YaSTs große Stärke, seine Langlebigkeit, ist inzwischen eher Teil des Problems als der Lösung. Viele Designentscheidungen stammen aus einer Zeit, in der ein Installer vor allem lokale Hardware konfigurierte und am Ende ein möglichst vollständig eingerichtetes System hinterließ. Dieses Modell passte zu klassischen Servern und PCs, gerät jedoch zunehmend in Konflikt mit modernen Anforderungen. Container-Hosts, Immutable-Images, Edge-Systeme, Cloudinstanzen sowie automatisierte Deployments in großer Zahl stellen YaST vor Herausforderungen, auf die es nur noch begrenzt reagieren kann.

Ein Installer muss heute nicht nur interaktiv funktionieren, sondern auch API-gesteuert, automatisierbar und reproduzierbar arbeiten. Er muss sich in unterschiedlichste Installationspfade integrieren lassen, auf Hardware laufen, die niemand physisch zu Gesicht bekommt, und Abläufe unterstützen, die von CI/CD bis zur Bare-Metal-Provisionierung reichen.

YaST passt nicht zu modernen Plattformen

Das Kernproblem von YaST liegt also weniger in seinem Alter als in dem technischen und organisatorischen Umfeld, in dem es entstanden ist. Es geht implizit von einer klar definierten Distribution mit einem stabilen Installationsablauf aus, der in ein klassisches, persistentes Linux-System mündet, das anschließend nur noch schrittweise angepasst wird. Dieses Modell war über Jahrzehnte tragfähig. SUSE hat es mit SLES perfektioniert und mit openSUSE einer breiten Anwenderschaft zugänglich gemacht.

Heute liefert SUSE längst nicht mehr nur eine einzelne Distribution, sondern ein ganzes Ökosystem aus Varianten, Editionen und Zielplattformen. SLES existiert in unterschiedlichen Ausprägungen, Micro-Varianten adressieren Container- und Kubernetes-Szenarien, und mit ALP (Adaptable Linux Platform) verfolgt SUSE ein Konzept, das klassische Annahmen über Installation und Systemzustand gezielt aufbricht. ALP trennt Applikationsschicht und Basissystem, setzt auf Immutable-Ansätze und verlangt Installationsabläufe, die nicht mehr dem traditionellen Linux-Setup folgen.

YaST lässt sich an diese Konzepte nur schwer anpassen. Seine Architektur basiert auf einem vergleichsweise starren Verständnis von Installation und ist kein modularer Baukasten, sondern ein historisch gewachsenes System mit eng verzahnten Komponenten. Änderungen betreffen selten nur einzelne Stellen. Wer YaST modernisieren will, greift schnell in komplexe Abhängigkeitsketten ein und riskiert, ein über Jahre stabiles System aus dem Gleichgewicht zu bringen. SUSE steht mit diesem Problem nicht allein. Aus ähnlichen Gründen hat Canonical den Debian Installer abgelöst und mit (S)ubiquity eine neue Installationsroutine für Ubuntu-Linux geschaffen.

Agama definiert Installationen neu

Agama [1] ist SUSEs Ansatz, Installation nicht länger als Frage der Benutzeroberfläche zu behandeln, sondern als architektonisches Thema. YaST verstand Installation stets als linearen Prozess: Das System bootet, der Administrator klickt sich durch Dialoge, trifft Entscheidungen, und am Ende steht ein fertig installiertes System. Automatisierung kam später in Form von AutoYaST hinzu, steuerte jedoch lediglich diesen linearen Ablauf. Das Grundprinzip von YaST blieb interaktiv. Agama kehrt diese Logik um: Nicht der Dialog bildet den Kern des Installers, sondern eine Installations-Engine, die sich vollständig über das API steuern lässt.

Der zentrale Gedanke dabei lautet: Soll sich Installation zuverlässig, individuell und automatisiert durchführen lassen, muss der Installer selbst wie ein moderner Dienst funktionieren. Dafür benötigt er klar definierte Schnittstellen mit versioniertem API und eine saubere Trennung zwischen Funktion und Steuerung. Agama folgt diesem Ansatz konsequent und setzt auf ein durchgängig API-zentrisches Design.

Wenn im Zusammenhang mit Agama von einem "Web Installer" die Rede ist, klingt das zunächst nach einer rein grafischen Spielerei im Browser. Tatsächlich ist das Gegenteil der Fall. Die Weboberfläche ist nicht die eigentliche Innovation, sondern lediglich die sichtbare Komponente auf der Nutzerseite. Das Frontend fungiert als Client, der über HTTP mit dem Backend kommuniziert. Agama behandelt Installation damit nicht als lokale Anwendung, sondern als fernsteuerbaren Prozess, der sowohl interaktiv als auch automatisiert ablaufen kann. Der Vorteil liegt auf der Hand: Ist die Installationslogik über ein API verfügbar, lässt sie sich nicht nur über ein GUI steuern, sondern ebenso durch Skripte, Provisionierungsplattformen oder CI-Pipelines. Das Zielsystem ist damit nicht mehr an die Person gebunden, die gerade vor dem Bildschirm sitzt.

API als zentrales Steuerinstrument

Im Kern verhält sich Agama wie ein HTTP-basierter API-Dienst. Es nimmt Konfigurationsdaten entgegen, validiert sie, setzt sie um und liefert Statusinformationen zurück. Diese Statusinformationen richten sich nicht nur an Menschen, sondern ausdrücklich auch an Maschinen. Provisionierungswerkzeuge müssen wissen, ob die Netzwerkkonfiguration erfolgreich war, ob die Partitionierung abgeschlossen ist oder ob ein Installationsschritt fehlgeschlagen ist. Agama stellt dafür ein API bereit, das diese Zustände explizit abbildet und sowohl ereignisbasiert als auch auf Anfrage Auskunft gibt.

Wer Linux heute auf Servern oder Desktops installiert, nutzt typischerweise PXE, iPXE, Metal-as-a-Service-Plattformen, Imaging-Verfahren, Kickstart- oder Preseed-ähnliche Mechanismen sowie ein nachgelagertes Konfigurationsmanagement wie etwa Ansible. Agama fügt sich in dieses Umfeld ein, weil es nicht zwingend interaktiv sein will. Dadurch passt es auch nahtlos zum SUSE Manager, SUSEs Werkzeug zur zentralen Verwaltung großer Serverlandschaften.

AutoYaST arbeitet mit Profilen, die im Wesentlichen den Dialogfluss des Installers nachzeichnen. Diese beschreiben, welche Entscheidungen der Installer treffen soll, und YaST spielt diese Schritt für Schritt ab. Das Prinzip ähnelt dem Preseeding des Debian-Installers sehr stark. Agama verfolgt einen grundlegend anderen Ansatz. Automatisierung ist hier keine Zusatzfunktion, sondern ein zentrales Entwurfsprinzip. Das API ist kein Nebenkanal, sondern die maßgebliche Schnittstelle. Entsprechend orientiert sich die Automatisierung nicht an Dialogmasken, sondern an einem objektbasierten Konfigurationsmodell. Beschrieben wird nicht, welche Eingabemaske als Nächstes erscheint, sondern welcher Zielzustand erreicht werden soll: Welche Partitionen existieren, welche Netzwerkschnittstellen konfiguriert sind, welche Benutzer angelegt werden und zahlreiche weitere Eigenschaften.

Diese Herangehensweise verändert die Qualität der Automatisierung deutlich. AutoYaST-Profile sind leistungsfähig, aber oft schwer zu pflegen, da sie eng an konkrete YaST-Versionen, Module und Dialoglogiken gekoppelt sind. Agama-Konfigurationen orientieren sich hingegen an einem klaren Daten- und API-Modell. Sie lassen sich einfacher validieren, versionieren und testen und eignen sich besser zur automatischen Erzeugung, etwa aus Inventardaten oder aus einem CMDB-Export.

Gleichzeitig erleichtert dieses Modell die Übergabe an nachgelagerte Werkzeuge. Systeme lassen sich mit Agama gezielt in einen definierten Ausgangszustand versetzen, den anschließend Konfigurationsmanagement-Werkzeuge übernehmen. Die Installation wird damit nicht mehr als abgeschlossener Einzelschritt verstanden, sondern als integrierter Bestandteil eines durchgängigen Betriebsmodells.

Agama praktisch erproben

Agama ist kein theoretisches Konzept für eine ferne Zukunft, sondern lässt sich bereits heute ausprobieren. Der einfachste Einstieg erfolgt über ein separates ISO-Abbild, das SUSE beziehungsweise das Agama-Projekt zum Download bereitstellt (ebenfalls unter Link [1] zu finden). Dieses ISO-Image enthält eine bootfähige Umgebung, in der Agama direkt startet und den Installationsprozess steuert. Um Agama zu testen, müssen Sie Ihre bestehende SUSE-Installation nicht anpassen, sondern können das Werkzeug isoliert evaluieren, etwa in einer VM, auf Testhardware oder im Lab. Der Ablauf entspricht klassischen Installationsmedien: ISO herunterladen, bootfähigen USB-Stick erstellen und davon starten.

Der Download selbst ist unspektakulär. Sie beziehen das ISO direkt von der Projektseite und prüfen idealerweise – insbesondere in Enterprise-Umgebungen – die bereitgestellten Checksummen. So stellen Sie sicher, dass das Abbild beim Download nicht beschädigt wurde. In dieser Hinsicht unterscheidet sich Agama nicht von anderen Installationsumgebungen. Wer Installationsmedien verteilt oder produktiv einsetzt, will deren Integrität sicherstellen. Anschließend folgt der Schritt, der in der Praxis mehr Fehler verursacht als jede Partitionierung: das Schreiben des Images auf einen USB-Stick.

Unter Linux ist der klassische Weg dabei weiterhin das Werkzeug "dd", auch wenn sich damit bei Unachtsamkeit leicht das falsche Laufwerk überschreiben lässt. Um das zu vermeiden, schließen Sie zunächst den USB-Stick an und identifizieren ihn anschließend in der Liste der Blockgeräte, etwa mit "lsblk". Danach schreiben Sie das Agama-Abbild auf den Stick:

Wichtig ist, dass sich "sdX" tatsächlich auf den USB-Stick bezieht und nicht auf das Laufwerk, das die bestehende Systeminstallation enthält. Nach Abschluss des Vorgangs ist der Stick bootfähig.

Nach dem Boot zeigt sich deutlich, wie stark sich Agama von klassischen Installern unterscheidet. Zwar startet auch hier eine lokale Benutzeroberfläche, parallel läuft jedoch bereits der Agama-Backend-Dienst. Entsprechend zeigt das System unmittelbar an, wie sich das Webfrontend von außen erreichen lässt, etwa über eine per DHCP vergebene IP-Adresse. "Web Installer" bedeutet hier konkret, dass Sie den Installer nicht zwingend am Bildschirm des Zielsystems bedienen, sondern auch über einen Browser von einem anderen Rechner aus.

Das ist besonders dort relevant, wo Zielsysteme in Racks verbaut sind, an schwer zugänglichen Orten laufen oder lediglich als virtuelle Instanzen existieren. In solchen Szenarien greifen Administratoren häufig gar nicht mehr physisch auf einen USB-Stick zu, sondern booten das ISO-Abbild per BMC-Schnittstelle. Die eigentliche Installation erfolgt anschließend vollständig aus der Ferne über den Browser. Der Installer wird damit zu einem Prozess, den Sie über KVM, iDRAC, iLO oder eine serielle Konsole begleiten – oder auch vollständig automatisiert abwickeln.

Klassische Installation wird flexibel

Im interaktiven Betrieb führt Agama durch die klassischen Installationsschritte wie Sprache, Tastatur, Netzwerk, Storage, Benutzer und Softwareauswahl. Der Unterschied liegt weniger im Funktionsumfang als in Darstellung und Logik. Das Agama-Frontend wirkt nicht wie ein monolithischer Assistent, sondern wie eine Oberfläche, die den aktuellen Zustand der Installationskonfiguration abbildet. Der Administrator arbeitet sich nicht ausschließlich Schritt für Schritt vor, sondern kann gezielt einzelne Bereiche anpassen, ohne in einer strikt linearen Dialoglogik gefangen zu sein.

Die Vorteile zeigen sich besonders beim Storage, denn insbesondere in Ceph- oder SAN-Umgebungen entsprechen Partitionierung und Mountpoints häufig nicht dem Standard. Agama zielt darauf ab, solche Konfigurationen so darzustellen, dass sie interaktiv verständlich bleiben und zugleich automatisiert reproduzierbar sind. Ein CephFS-Mountpoint lässt sich in Agama ebenso hinterlegen wie ein NVMe-oF-Target als Basis für das Root-Dateisystem.

Mächtige Features dank API

Seine eigentlichen Stärken spielt Agama jedoch dort aus, wo es nicht interaktiv arbeitet. Sobald das API im Mittelpunkt steht, ist der nächste Schritt konsequent: Der Administrator übergibt dem Installer eine Konfigurationsbeschreibung, typischerweise in Form eines JSON-Templates, die Agama anschließend umsetzt. Im Kern folgt dieser Ansatz dem Prinzip von Infrastructure-as-Code und erlaubt, Systeme vollständig unbeaufsichtigt zu installieren.

Ein einfaches Beispiel ist die Netzwerkkonfiguration. Besitzt ein System mehrere Schnittstellen und soll eine davon zwingend eine statische Adresse erhalten, beschreibt der Administrator diesen Zielzustand direkt im Konfigurationsmodell. In einem API-gesteuerten Ansatz wird nicht der Weg dorthin definiert, sondern das gewünschte Ergebnis – einen entsprechenden Konfigurationsblock zeigt das Listing.

Das Beispiel deckt mehrere anspruchsvolle Aspekte gleichzeitig ab: Es erzeugt während der Installation ein Bonding-Interface sowie eine Bridge. Ebenso lassen sich VLAN-Schnittstellen definieren oder Kombinationen aus allen genannten Elementen umsetzen. Dies ist manuell äußerst aufwendig und Agama nimmt Ihnen an dieser Stelle einen erheblichen Teil der Arbeit ab, weil es die gewünschte Zielkonfiguration einmal sauber beschreibt und anschließend reproduzierbar umsetzt.

User während der Installation definieren

Ein weiteres typisches Beispiel ist das Anlegen von Benutzern. Statt nach Abschluss der Installation manuell Accounts zu erzeugen oder diesen Schritt nachgelagerten Werkzeugen zu überlassen, lassen sich in Agama auf Wunsch Benutzer bereits während der Installation anlegen. Auch hier folgt das System dem gleichen Prinzip wie bei Netzwerk oder Storage: Beschrieben wird nicht der Ablauf, sondern der gewünschte Zielzustand:

Auf Wunsch verwalten Sie die gesamte Installationskonfiguration in Git, rollen sie automatisiert per Pipeline aus und kontrollieren Änderungen über Code Reviews. Die Installation wird damit Bestandteil desselben Prozesses wie das nachgelagerte Konfigurationsmanagement. Infrastruktur entsteht nicht mehr durch einmalige Handarbeit, sondern durch überprüfbaren und reproduzierbaren Code.

Durchgängige Automatisierung

In der Praxis endet Infrastrukturautomatisierung nicht mit dem Installer. Im Gegenteil: Der Installer liefert lediglich den Basisschritt, ab dem ein System erreichbar und verwaltbar ist. Mit Agama können Sie ein System so vorbereiten, dass es sich anschließend nahtlos in bestehende Werkzeuge und Prozesse einfügt.

Ein typischer Ablauf sieht folgendermaßen aus: Agama installiert das Basissystem, konfiguriert Netzwerk, SSH-Schlüssel und Benutzer und installiert grundlegende Pakete. Danach übernimmt ein Werkzeug wie SUSE Manager, Salt, Ansible oder ein internes Provisionierungsframework. Agama muss dabei nicht sämtliche Details selbst abbilden, es sorgt lediglich dafür, dass das System einen definierten Ausgangszustand erreicht. In einem SUSE-Manager-Szenario bedeutet das beispielsweise, dass die Registrierung des Systems oder die Installation des Clients bereits Teil der Installation ist. In einem Ansible-Szenario genügt es, dass das System per SSH erreichbar ist und ein Benutzer mit passenden Rechten existiert.

Weiterentwicklung muss einer klaren Linie folgen

Der Ausblick auf kommende Agama-Funktionen ergibt sich aus dem eingeschlagenen Entwicklungsweg. Absehbar wird SUSE vor allem in drei Bereichen nachlegen: Die Unterstützung für Hardware und Storage weiter ausbauen, das API weiter reifen in Bezug auf Funktionsumfang und Validierung und Fehlermeldungen. Ein API-first-Installer muss Konfiguration nicht nur akzeptieren, sondern auch präzise erklären können, warum bestimmte Angaben nicht funktionieren. Drittens gewinnt die Integration in größere Provisionierungs- und Managementsysteme an Bedeutung, etwa durch eine engere Anbindung an PXE-Workflows, Inventory-Systeme oder nachgelagerte Automationsplattformen.

Langfristig wird sich Agama daran messen lassen müssen, ob es SUSE gelingt, den Installer nicht nur als Ersatz für YaST zu etablieren, sondern als Tool, das die Vielfalt des SUSE-Portfolios trägt – von klassischen SLES-Installationen bis hin zu modernen ALP-Varianten. Genau hier liegt die eigentliche Bewährungsprobe.

Fazit

Agama befindet sich erkennbar noch in der Entwicklung und hat noch nicht den Reifegrad eines über Jahrzehnte gewachsenen YaST erreicht. Bestimmte Sonderfälle, exotische Storage-Layouts oder spezielle Hardwareanforderungen sind bislang nicht in derselben Breite abgedeckt. Das ist wenig überraschend. Ein neues Werkzeug benötigt Zeit, um die gesamte Bandbreite realer Installationsszenarien abzubilden, insbesondere in Enterprise-Umgebungen, in denen Ausnahmen eher die Regel als die Ausnahme sind. Entscheidend ist jedoch, dass Agama bereits heute konzeptionell überzeugt und in der Praxis weitgehend funktioniert.

Agama Installer von SUSE