Das Fedora‑Projekt arbeitet an einer browserbasierten Ferninstallation für den Anaconda‑Installer. Ziel ist, Maschinen ohne Bildschirm — etwa Server im Rack oder ressourcenarme ARM‑Boards — direkt über einen entfernten Browser zu installieren. Das reduziert Datenaufwand und Latenz gegenüber klassischem Screen‑Streaming per VNC oder RDP und nutzt die bereits vorhandene Web‑UI von Anaconda.

Warum ein webbasiertes Remote‑Installationsverfahren?

Traditionell kommen bei Kopflosen Systemen VNC oder RDP zum Einsatz, um die GTK‑Installeroberfläche fernzusteuern. Anaconda besitzt inzwischen aber eine vollwertige Web‑UI, die zunächst in Fedora 42 Workstation eingeführt und in Fedora 43 auf alle Live‑Spins ausgeweitet wurde. Diese Oberfläche basiert auf Cockpit‑Werkzeugen und PatternFly‑Widgets und läuft als Browser‑Fullscreen-Anwendung.

Da die Web‑UI ohnehin HTML/CSS/JS nutzt, lässt sich sie sinnvollerweise direkt an einen entfernten Browser ausliefern. Dieser Ansatz überträgt wesentlich weniger Daten als pixelbasiertes Streaming und bietet geringere UI‑Latenzen. Außerdem entfällt die Notwendigkeit, auf dem Zielsystem einen grafischen Browser mit GPU‑Support zu starten — was insbesondere auf kleinen ARM‑SBCs wie dem Raspberry Pi hilfreich ist.

Konzept und grundlegende Entscheidungen

Die Kernidee ist simpel: Der Anaconda‑Web‑Installer wird über eine HTTPS‑Verbindung bereitgestellt. Ein Anwender öffnet im Browser die IP des Zielsystems, meldet sich per PIN an und steuert den Installationsprozess wie lokal. Einige Architekturbeschlüsse stehen bereits:

• Authentifizierung per PIN, die über Kickstart oder Boot‑Optionen gesetzt wird; der Anwender gibt die PIN im Browser ein.
• Verschlüsselung per TLS mit einem bei Boot generierten, selbstsignierten Zertifikat. Das schützt die Verbindung, akzeptiert aber die Browserwarnung für nicht vertraute Zertifikate.
• Standardmäßig nur eine gleichzeitige Browserverbindung — parallele Sessions könnten sich widersprechen und Speicher- oder Plattenkonfigurationen beschädigen.
• Beim Verbindungsverlust hängt das Verhalten vom Installationsfortschritt ab: Vor der finalen Bestätigungsseite startet die Session neu, danach gelangt man direkt auf die Fortschrittsanzeige.
• Cockpit‑Konfigurationen für die Installation werden isoliert gehalten, standardmäßig unter /etc/anaconda/cockpit/, damit nichts in das spätere Zielsystem „leakt“.
• Der Dienst soll standardmäßig Port 443 nutzen, lässt sich aber konfigurieren.

Authentifizierung und TLS

Für die erste Authentifizierung ist ein PIN‑Mechanismus vorgesehen, der ähnlich wie bei VNC oder RDP vom Benutzer eingegeben wird. Die Entwickler entschieden sich gegen die Auslieferung eines privaten Schlüssels auf dem Installationsmedium, daher erfolgt TLS mit einem bei Systemstart erzeugten, selbstsignierten Zertifikat. Für großskalige, zertifikateverwaltete Deployments empfiehlt das Team stattdessen vorbereitete Images via Image Builder mit eigenen Zertifikaten einzusetzen.

Sitzungsverwaltung und Konfigurationsisolation

Sitzungen verwenden Cookies, die das Schließen eines Tabs überdauern, jedoch nach komplettem Schließen des Browsers eine erneute Anmeldung erfordern. Alle Cockpit‑spezifischen Einstellungen für den Installationsmodus werden getrennt von regulären Cockpit‑Pfaden verwaltet, um Konfigurationsübertragungen ins Zielsystem zu vermeiden.

Typische Einsatzszenarien

Die Entwickler nennen drei Hauptanwendungsfälle:

• Headless‑Server: Maschinen im Rechenzentrum oder im Rack ohne angeschlossenen Bildschirm lassen sich per Browser vom Schreibtisch aus installieren.
• Ressourcenarme ARM‑Boards: Ein Raspberry Pi oder ähnliches kann lediglich den Installer‑Backend betreiben; alle Rendering‑ und Interaktionsaufgaben übernimmt der Client‑Browser.
• Remote‑Monitoring: Auch bei lokal angeschlossenem Monitor kann das Beobachten oder Mitverfolgen einer Installation von einem anderen Gerät aus nützlich sein.

Vergleich zu VNC und RDP

VNC und RDP bleiben als Optionen für die älteren GTK‑Installationsoberflächen erhalten. Technisch teilen sich VNC und RDP das Prinzip, den Bildschirminhalt zu übertragen; RDP arbeitet dabei auf Display‑Level. Die webbasierte Lösung hingegen sendet nur Anweisungen und UI‑Änderungen als strukturierten Inhalt an den Browser, wodurch Bandbreite gespart und Reaktionszeiten verbessert werden. Zudem entfallen plattformabhängige Viewer‑Installationen: Jeder aktuelle Browser kann als Client dienen. Ein weiterer Vorteil ist ein einheitlicher Codepfad — Features, die in der Web‑UI entwickelt werden, stehen automatisch auch für die Remote‑Nutzung zur Verfügung, ohne eine zusätzliche GTK‑Codebasis zu pflegen.

Aktueller Entwicklungsstand und Proof‑of‑Concept

Der Funktionsumfang im Entwickler‑Preview umfasst bereits mehrere Elemente:

• Eine angepasste Login‑Seite mit PIN‑Authentifizierung.
• Eine separate, socket‑aktivierte systemd‑Unit für die Authentifizierung, getrennt vom Haupt‑Cockpit‑Prozess.
• Sitzungscookies, die Tabwechsel überstehen, aber nach komplettem Browser‑Schließen Neuanmeldung erzwingen.
• Isolierte Cockpit‑Konfiguration unter anaconda‑eigener Pfadstruktur.

Offene Punkte sind unter anderem die technische Durchsetzung der Einzelsitzung (dazu ist Abstimmung mit den Cockpit‑Maintainerinnen und Maintainer nötig) sowie die Backend‑Erkennung, ob eine Installation bereits läuft — beides relevant für korrektes Reconnect‑Verhalten.

Es existiert ein Proof‑of‑Concept‑Zweig im anaconda‑Web‑UI‑Repository (Branch poc‑remote), der die Authentifizierungskomponenten demonstriert. Wer experimentell testen möchte, kann den PR‑Zweig klonen, ein updates.img erzeugen und eine VM mit virt‑install so starten, dass das Image als Update bereitgestellt wird und der Remote‑Modus aktiviert ist. Wichtiger Hinweis: Dieses PoC ist nicht für produktive Nutzung gedacht — die PIN ist dort fest auf 1234 eingestellt, TLS ist nicht eingerichtet und die Einzelsitzungsregelung fehlt noch.

Diskussionspunkte für die Community

Die Fedora‑Entwicklerinnen und Entwickler suchen aktiv Rückmeldungen zu mehreren Entscheidungen. Wichtig ist insbesondere, ob ein minimalistisches Boot‑ISO ohne lokalen Browser sinnvoll wäre — ein leichtgewichtiges Image, das standardmäßig Remote‑Installation erlaubt und damit gezielt auf kopf‑ und bildschirmlose Szenarien zugeschnitten ist. Alternativ bleibt die bisherige opt‑in‑Lösung, die per Bootoption oder Kickstart aktiviert wird.

Falls Sie heute VNC oder RDP für Remote‑Installationen nutzen: Würde ein Browser‑basierter Weg diese Szenarien ersetzen? Welche Anforderungen sehen Sie noch, damit ein solches System in Ihrer Umgebung praktikabel ist? Die Entwickler bitten um Feedback über Matrix (#anaconda:fedoraproject.org) oder via Kommentar und verfolgen die Arbeit im anaconda‑webui‑Repository auf GitHub.

Fazit: Die webbasierte Ferninstallation für Anaconda ist ein nachvollziehbarer Schritt, um Remote‑Setups effizienter und wartungsärmer zu gestalten. Der aktuelle Stand zeigt eine solide Richtung, aber einige sicherheits‑ und betrieblich relevante Details sind noch offen — jetzt ist der richtige Zeitpunkt, um Einwände und Anforderungen aus der Community einzubringen.