Das Fedora\u2011Projekt arbeitet an einer browserbasierten Ferninstallation f\u00fcr den Anaconda\u2011Installer. Ziel ist, Maschinen ohne Bildschirm \u2014 etwa Server im Rack oder ressourcenarme ARM\u2011Boards \u2014 direkt \u00fcber einen entfernten Browser zu installieren. Das reduziert Datenaufwand und Latenz gegen\u00fcber klassischem Screen\u2011Streaming per VNC oder RDP und nutzt die bereits vorhandene Web\u2011UI von Anaconda.<\/p>\n
Traditionell kommen bei Kopflosen Systemen VNC oder RDP zum Einsatz, um die GTK\u2011Installeroberfl\u00e4che fernzusteuern. Anaconda besitzt inzwischen aber eine vollwertige Web\u2011UI, die zun\u00e4chst in Fedora 42 Workstation eingef\u00fchrt und in Fedora 43 auf alle Live\u2011Spins ausgeweitet wurde. Diese Oberfl\u00e4che basiert auf Cockpit\u2011Werkzeugen und PatternFly\u2011Widgets und l\u00e4uft als Browser\u2011Fullscreen-Anwendung.<\/p>\n
Da die Web\u2011UI ohnehin HTML\/CSS\/JS nutzt, l\u00e4sst sich sie sinnvollerweise direkt an einen entfernten Browser ausliefern. Dieser Ansatz \u00fcbertr\u00e4gt wesentlich weniger Daten als pixelbasiertes Streaming und bietet geringere UI\u2011Latenzen. Au\u00dferdem entf\u00e4llt die Notwendigkeit, auf dem Zielsystem einen grafischen Browser mit GPU\u2011Support zu starten \u2014 was insbesondere auf kleinen ARM\u2011SBCs wie dem Raspberry Pi hilfreich ist.<\/p>\n
Die Kernidee ist simpel: Der Anaconda\u2011Web\u2011Installer wird \u00fcber eine HTTPS\u2011Verbindung bereitgestellt. Ein Anwender \u00f6ffnet im Browser die IP des Zielsystems, meldet sich per PIN an und steuert den Installationsprozess wie lokal. Einige Architekturbeschl\u00fcsse stehen bereits:<\/p>\n
F\u00fcr die erste Authentifizierung ist ein PIN\u2011Mechanismus vorgesehen, der \u00e4hnlich wie bei VNC oder RDP vom Benutzer eingegeben wird. Die Entwickler entschieden sich gegen die Auslieferung eines privaten Schl\u00fcssels auf dem Installationsmedium, daher erfolgt TLS mit einem bei Systemstart erzeugten, selbstsignierten Zertifikat. F\u00fcr gro\u00dfskalige, zertifikateverwaltete Deployments empfiehlt das Team stattdessen vorbereitete Images via Image Builder mit eigenen Zertifikaten einzusetzen.<\/p>\n
Sitzungen verwenden Cookies, die das Schlie\u00dfen eines Tabs \u00fcberdauern, jedoch nach komplettem Schlie\u00dfen des Browsers eine erneute Anmeldung erfordern. Alle Cockpit\u2011spezifischen Einstellungen f\u00fcr den Installationsmodus werden getrennt von regul\u00e4ren Cockpit\u2011Pfaden verwaltet, um Konfigurations\u00fcbertragungen ins Zielsystem zu vermeiden.<\/p>\n
Die Entwickler nennen drei Hauptanwendungsf\u00e4lle:<\/p>\n
VNC und RDP bleiben als Optionen f\u00fcr die \u00e4lteren GTK\u2011Installationsoberfl\u00e4chen erhalten. Technisch teilen sich VNC und RDP das Prinzip, den Bildschirminhalt zu \u00fcbertragen; RDP arbeitet dabei auf Display\u2011Level. Die webbasierte L\u00f6sung hingegen sendet nur Anweisungen und UI\u2011\u00c4nderungen als strukturierten Inhalt an den Browser, wodurch Bandbreite gespart und Reaktionszeiten verbessert werden. Zudem entfallen plattformabh\u00e4ngige Viewer\u2011Installationen: Jeder aktuelle Browser kann als Client dienen. Ein weiterer Vorteil ist ein einheitlicher Codepfad \u2014 Features, die in der Web\u2011UI entwickelt werden, stehen automatisch auch f\u00fcr die Remote\u2011Nutzung zur Verf\u00fcgung, ohne eine zus\u00e4tzliche GTK\u2011Codebasis zu pflegen.<\/p>\n
Der Funktionsumfang im Entwickler\u2011Preview umfasst bereits mehrere Elemente:<\/p>\n
Offene Punkte sind unter anderem die technische Durchsetzung der Einzelsitzung (dazu ist Abstimmung mit den Cockpit\u2011Maintainerinnen und Maintainer n\u00f6tig) sowie die Backend\u2011Erkennung, ob eine Installation bereits l\u00e4uft \u2014 beides relevant f\u00fcr korrektes Reconnect\u2011Verhalten.<\/p>\n
Es existiert ein Proof\u2011of\u2011Concept\u2011Zweig im anaconda\u2011Web\u2011UI\u2011Repository (Branch poc\u2011remote), der die Authentifizierungskomponenten demonstriert. Wer experimentell testen m\u00f6chte, kann den PR\u2011Zweig klonen, ein updates.img<\/em> erzeugen und eine VM mit virt\u2011install so starten, dass das Image als Update bereitgestellt wird und der Remote\u2011Modus aktiviert ist. Wichtiger Hinweis: Dieses PoC ist nicht f\u00fcr produktive Nutzung gedacht \u2014 die PIN ist dort fest auf 1234 eingestellt, TLS ist nicht eingerichtet und die Einzelsitzungsregelung fehlt noch.<\/p>\n Die Fedora\u2011Entwicklerinnen und Entwickler suchen aktiv R\u00fcckmeldungen zu mehreren Entscheidungen. Wichtig ist insbesondere, ob ein minimalistisches Boot\u2011ISO ohne lokalen Browser sinnvoll w\u00e4re \u2014 ein leichtgewichtiges Image, das standardm\u00e4\u00dfig Remote\u2011Installation erlaubt und damit gezielt auf kopf\u2011 und bildschirmlose Szenarien zugeschnitten ist. Alternativ bleibt die bisherige opt\u2011in\u2011L\u00f6sung, die per Bootoption oder Kickstart aktiviert wird.<\/p>\n Falls Sie heute VNC oder RDP f\u00fcr Remote\u2011Installationen nutzen: W\u00fcrde ein Browser\u2011basierter Weg diese Szenarien ersetzen? Welche Anforderungen sehen Sie noch, damit ein solches System in Ihrer Umgebung praktikabel ist? Die Entwickler bitten um Feedback \u00fcber Matrix (#anaconda:fedoraproject.org) oder via Kommentar und verfolgen die Arbeit im anaconda\u2011webui\u2011Repository auf GitHub.<\/p>\n Fazit: Die webbasierte Ferninstallation f\u00fcr Anaconda ist ein nachvollziehbarer Schritt, um Remote\u2011Setups effizienter und wartungs\u00e4rmer zu gestalten. Der aktuelle Stand zeigt eine solide Richtung, aber einige sicherheits\u2011 und betrieblich relevante Details sind noch offen \u2014 jetzt ist der richtige Zeitpunkt, um Einw\u00e4nde und Anforderungen aus der Community einzubringen.<\/p>\nDiskussionspunkte f\u00fcr die Community<\/h2>\n