Proxmox 9.2 ist da, und die Community streitet darüber, wie viel Macht die UI haben sollte
Das Release wirkte groß, weil die Erwartungen größer wurden
Proxmox 9.2 landete wie ein Meilenstein für eine Community, die sich seit Jahren dieselbe Frage stellt: Wie viel von dem hässlichen Kram sollte die Plattform endlich einfacher machen? Der Release-Thread hatte die übliche Aufregung, die übliche „Ich update später"-Energie und die übliche Mischung aus vorsichtigen Admins und Homelab-Draufgängern. Die stärkste Reaktion löste allerdings ein alter, vertrauter Schmerz rund um Berechtigungen aus, kein glanzvolles Highlight-Feature.
Das sagt viel darüber aus, wo Proxmox heute steht. Ob es VMs gut ausführen kann, fragt kaum noch jemand, diese Schlacht ist größtenteils gewonnen. Die Nutzer wollen wissen, ob die tägliche Arbeit mit Containern, geteiltem Storage, Backups, Migrationen, Berechtigungen und hybriden Homelab-Setups weniger nach einem Stapel zusammengeklebter Forenbeiträge aussehen kann. Vor ein paar Jahren hätte ein Release, das das UID- und GID-Mapping von Containern verbessert, wie eine Randnotiz geklungen. In diesem Thread machte genau das die Leute seltsam glücklich.
Das passt auch. Infrastruktur-Nutzer bejubeln nicht immer die glänzenden Dinge. Manchmal jubeln sie, weil eine Config-Datei, die früher wie eine verfluchte Matheaufgabe aussah, jetzt sauberer gehandhabt werden kann, und diese Art von Befreiung mit Web-UI ist alles andere als langweilig.
Das hässliche UID-Mapping-Problem kommt endlich ans Licht
Im Zentrum der Diskussion stand das LXC-Identity-Mapping. Falls Ihnen bei diesem Ausdruck schon die Augen glasig werden: Genau dieses Problem will Proxmox 9.2 entschärfen. Auf dem Papier sind unprivilegierte Container großartig. Sie sind sicherer, sie verkleinern den Explosionsradius, und viele wissen, dass sie sie eigentlich nutzen sollten. Dann kommt die Realität mit Bind-Mounts, Host-Datasets, NFS-Shares, Medienbibliotheken, Download-Clients, User-IDs und Group-IDs, und plötzlich ist jeder nur noch ein missglücktes chown von einem emotionalen Zusammenbruch entfernt.
Ein Nutzer zeigte den alten Weg mit einem Stapel von lxc.idmap-Zeilen, die UIDs und GIDs in Blöcken mappen. So eine Konfiguration sieht weniger nach Administration aus als nach schwarzer Magie, die man um 2 Uhr nachts von einem Fremden kopiert hat. Ein anderer sagte im Grunde, dass der neue Ablauf das alles in eine simple Auswahl verwandelt: Man sucht aus, welche Container-IDs auf welche Host-IDs gemappt werden. Niemand muss mehr mit /etc/subuid oder /etc/subgid ringen, nur damit ein Container ein Host-Verzeichnis anfassen kann, ohne dass man den Verstand verliert.
Die heftige Reaktion kommt daher, dass das Feature eine sehr spezifische Wunde trifft. Viele Proxmox-Nutzer betreiben mehrere LXCs gegen Host-Storage, mal ein ZFS-Dataset für Medien, mal einen NFS-Share, mal einen Haufen App-Daten, der sauber begann und langsam zu einem Berechtigungssumpf wurde. Sobald das Setup wächst, wird es fast unmöglich zu verwalten, welcher Nutzer in welchem Container auf welchen Pfad des Hosts zugreifen darf. Ein Kommentator sagte, den Überblick über all die verschiedenen UIDs und GIDs über Datasets und Container hinweg zu behalten sei „unmöglich zu verfolgen und zu pflegen". Übertrieben ist das nicht, so sieht es aus, wenn gute Sicherheitspraktiken auf echten Homelab-Wildwuchs treffen.
Linux-Berechtigungen werden durch die neuen Mapping-Tools nicht auf magische Weise einfach, das schafft kein Tool. Sie verschieben aber einen guten Teil der Komplexität weg von „diese furchteinflößende Datei bearbeiten und hoffen" und hin zu etwas, das normaler Administration näherkommt, und das ist viel wert.
Das „777-Leben" ist lustig, weil jeder weiß, warum es dazu kommt
Natürlich brachte das Berechtigungsthema sofort die Geständnisse hervor. Jemand scherzte, im 777-Leben zu leben, weil einem die Kopfschmerzen einfach zu viel wurden. Ein anderer antwortete, 777 sei in einem begrenzten Homelab mit Snapshots und Backups vielleicht „akzeptabel", aber auf der Arbeit absolut nicht. In diesen zwei Kommentaren steckt im Grunde die gesamte Kluft zwischen Homelab und Produktion.
Jeder weiß, dass chmod 777 kein Plan ist, eher eine weiße Fahne. Wer sie schwenkt, ist dabei meist eher erschöpft als nachlässig. Sie haben den sicheren Weg versucht, wurden unter ID-Mapping begraben, sahen zu, wie die App das Dataset nicht lesen konnte, änderten den Besitzer zweimal, zerschossen einen weiteren Container und entschieden schließlich, dass der Dienst heute Abend einfach laufen soll. Die zukünftige Sicherheit kann ja ein Ticket aufmachen.
Darin liegt der gefährliche Charme von Homelabs: Sie beginnen als Experiment und werden langsam zur Infrastruktur. Erst wird der Fileserver wichtig, dann die Medienbibliothek, DNS und die Hausautomation. Irgendwann ist die „vorübergehende" Berechtigungsabkürzung Teil des Fundaments, und sechs Monate später erinnert sich niemand mehr, warum ein Dataset UID 121001 gehört oder warum ein LXC als ein Nutzer schreibt, den es nur gibt, weil eine Anleitung das so vorgab.
Manche Nutzer widersprachen der Idee, dass jeder Fall komplexes Mapping braucht. Jemand argumentierte, dass unzählige Tutorials das Ganze überkomplizieren und man in vielen Setups einen Host-Nutzer mit hoher UID anlegen kann, der sich ganz natürlich auf den Nutzer im Container mapped, ganz ohne eigene idmap-Zeilen. Ein anderer bevorzugte es, wo immer möglich echte Host-IDs zu verwenden, besonders wenn Daten später per virtiofs von einem LXC in eine VM wandern könnten. Dieser Punkt wird leicht übersehen, denn der Container von heute könnte die VM von morgen sein. Wenn alle Dateien seltsamen Offset-IDs gehören, wird die Migration zu einem Wochenendprojekt mit chown, Reue und vielleicht Kaffee, der so stark ist, dass man Farben hört.
Der Traum vom OCI-Container wartet weiter vor der Tür
Dann kam der größere Wunschlisten-Punkt, erstklassige OCI-Container-Unterstützung, und hier wurde die Spaltung in der Community lauter. Ein Nutzer sagte, er wolle OCI-Support, um kein Docker mehr in einem LXC laufen zu lassen und stattdessen alles direkt in der Proxmox-UI zu verwalten, idealerweise mit Replikation, HA und all den Annehmlichkeiten auf Plattformebene. Um diesen Traum kreisen viele Nutzer: Proxmox als der eine Ort, an dem sich VMs, LXCs, App-Container, Storage, Backups und Failover verbunden anfühlen.
Der Reiz ist leicht zu verstehen. Docker in einem LXC funktioniert für viele Leute, aber es fühlte sich immer ein bisschen an, als würde man ein winziges Apartment in einem anderen Apartment bauen, praktisch, aber nicht elegant. Die Leute wollen, dass Proxmox weiß, was diese Container sind, statt nur das zu hosten, was sie hostet. Sie wollen nicht mehr zwischen Denkmodellen wechseln, sondern Apps im Docker-Stil mit Infrastrukturkontrollen im Proxmox-Stil.
Der Widerspruch fiel allerdings scharf aus. Ein Kommentator fragte, welche Orchestrierung und welches Tooling man eigentlich von einem Hypervisor erwarte. Docker Compose, so das Argument, sei ein Feature auf Docker-Ebene und nicht auf Proxmox-Ebene, also eine andere Schicht mit einer anderen Aufgabe. Diese konservative Position hat etwas für sich. Proxmox ist gut, weil es einen klaren Schwerpunkt hat, die virtuelle Infrastruktur. Wenn es gleichzeitig Docker Compose, Portainer, Kubernetes-lite und Hypervisor sein will, könnte die Plattform schnell unübersichtlich werden.
Die andere Seite hat trotzdem auch recht, denn die Welt hat sich verändert. Für viele Nutzer umfasst „Infrastruktur" mittlerweile OCI-Container, ob es Hypervisor-Puristen gefällt oder nicht. Wenn die Hälfte der Nutzerbasis Docker in LXCs laufen lässt, ist das ein Signal. Proxmox muss deshalb nicht zwingend das Docker-Tooling komplett kopieren, aber der aktuelle Workaround ist verbreitet genug, um Aufmerksamkeit zu verdienen.
Die interessanteste Antwort liegt wahrscheinlich irgendwo in der Mitte. Proxmox muss kein App Store werden, kann aber auch nicht so tun, als wären OCI-Workloads egal. Gesucht ist eine Proxmox-typische Version von OCI-Support, integriert genug, um sich erstklassig anzufühlen, und zurückhaltend genug, damit die Plattform kein verwirrter Haufen konkurrierender Abstraktionen wird.
Proxmox-Nutzer wollen Power, aber sie sind es leid, bestraft zu werden
Das klarste Thema in der Release-Diskussion war Erschöpfung. Die Leute sind bereit zu lernen, Configs zu bearbeiten, Docs zu lesen, Backups zu testen, Container neu aufzusetzen, UIDs zu mappen und öffentlich über Storage-Semantik zu streiten. Diese Gruppe hat keine Angst vor Komplexität, sie ist es nur leid, Komplexität zu ertragen, die sich unnötig anfühlt.
Zwischen Power und Bestrafung gibt es einen Unterschied. Power heißt, Container-Nutzer sicher auf Host-Storage mappen zu können. Bestrafung heißt, zehn zerbrechliche lxc.idmap-Zeilen und ein perfektes Verständnis von untergeordneten ID-Bereichen zu brauchen, nur um einem Dienst Zugriff auf einen Ordner zu geben. Wer unprivilegierte Container mit geteilten Datasets betreiben kann, hat Power; wer aufgibt und 777 nutzt, weil sich jede sichere Option wie eine Falle anfühlt, wird bestraft. Dasselbe gilt für die Wahl, ob ein Workload in eine VM, ein LXC oder einen OCI-Container gehört, im Gegensatz zum Verschachteln von Tools, weil die Plattform den Workflow noch nicht ganz abdeckt.
Deshalb fühlt sich 9.2 wie Fortschritt an, auch wenn es nicht alles löst. Die besten Infrastruktur-Verbesserungen fügen nicht immer ein brandneues Spielzeug hinzu. Manchmal nehmen sie einfach einen Grund weg, warum Leute etwas Riskantes taten. Wenn einfacheres UID-Mapping mehr Nutzern hilft, unprivilegierte statt privilegierte Container zu wählen, ist das eine Sicherheitsverbesserung, verpackt als Komfort. Und wenn die UI den Storage-Zugriff verständlicher macht, baut sie unnötige Reibung ab, von Verdummung kann keine Rede sein.
Ein paar Leute im Thread sagten sinngemäß: „Dieses winzige Ding macht mich glücklich, und vielleicht ist das traurig." Traurig finde ich das nicht, ausgereifte Software sollte genau das tun. Sie sollte die schmerzhaften Dinge, über die Nutzer immer wieder stolpern, weniger schmerzhaft machen, ohne den Leuten, die sie brauchen, die echte Mechanik zu verstecken.
Das Release zeigt, wie Proxmox in eine schwierigere Rolle hineinwächst
Proxmox hat jetzt eine knifflige Aufgabe. Es muss der Person mit einem einzelnen Mini-PC ebenso dienen wie der Person, die einen VMware-Ersatz evaluiert. Es soll Einsteigern helfen, ohne Experten zu beleidigen, Features hinzufügen, ohne aufgebläht zu werden, und alte Schmerzpunkte glätten, ohne zu einer glänzenden Appliance zu werden, die zu viel versteckt. Diese Balance ist schwierig, und 9.2 zeigt beide Seiten davon.
Die Begeisterung rund um UID- und GID-Mapping zeigt, dass Nutzer es lieben, wenn Proxmox Komplexität auf verantwortungsvolle Weise in die UI zieht. In der OCI-Debatte wird deutlich, dass sie weiter nach mehr fragen werden, manchmal nach deutlich mehr. Die 777-Witze erinnern daran, dass Leute weiterhin Fluchtwege brauchen, weil echte Systeme unordentlich werden, und die Kommentare zur Portabilität zeigen eine Community, die über „heute Abend zum Laufen bringen" hinausdenkt, hin zu „werde ich dieses Setup später hassen?".
Proxmox 9.2 ist damit ein Zeichen dafür, dass eine Plattform von ihrem eigenen Erfolg nach oben gezogen wird. Die Nutzer vertrauen ihr mehr an und erwarten deshalb mehr. Sie bauen größere Setups, in denen die rauen Kanten stärker schmerzen, und je näher sie Produktionsgewohnheiten kommen, desto peinlicher wirken die alten Homelab-Abkürzungen. Sie wollen Enterprise-Features und trotzdem eine Plattform, die zugänglich genug bleibt, damit ein Wochenend-Admin sie übersteht.
Die Debatte darüber, was Proxmox werden sollte, beendet 9.2 nicht, es schärft sie eher. Die Plattform kann fokussiert auf virtuelle Infrastruktur bleiben und trotzdem Container weniger schmerzhaft machen. Sie kann die UI verbessern, ohne jedes fortgeschrittene Feature zu einem Spielzeug zu machen, und die Shell-Fraktion respektieren, während sie normale Menschen vor Config-Datei-Turnübungen rettet.
Das größte Kompliment für 9.2 ist, dass die Leute sofort anfingen, sich auszumalen, was als Nächstes kommt. Das Release hat einen hässlichen Teil des Systems menschlicher wirken lassen, und wer das einmal gekostet hat, will es überall.