Konsole, Shell und SSH: drei getrennte Türen zur selben Maschine
Wenn Sie eine Maschine nicht erreichen, lautet die erste Frage, welche Tür Sie benutzt haben. Es gibt drei, und jede hängt davon ab, dass etwas anderes funktioniert.
AtlasPVE ·
Dieser Eintrag beantwortet
- proxmox konsole öffnet nicht
- proxmox konsole oder shell unterschied
- kein ssh zugriff auf proxmox vm
- nach netzwerkänderung ausgesperrt
- proxmox fehler 401 no ticket
Sie erreichen eine Maschine nicht. Bevor Sie in Panik geraten, stellen Sie eine Frage: welche Tür haben Sie benutzt?
Es gibt drei getrennte Türen zur selben Maschine, und jede hängt davon ab, dass etwas anderes lebt. Zu wissen, welche zugegangen ist, sagt Ihnen direkt, wo das Problem liegt.
Drei Türen
Konsole. Auf Bildschirm und Tastatur der Maschine schauen. Das Gegenstück dazu, an einen physischen Server heranzugehen und einen Monitor anzustecken. Sie benutzt das Netzwerk des Gastes nicht, sie geht über den Host.
Shell. Einen Befehl tippen und Ausgabe zurückbekommen. Sie ahmt keinen Bildschirm nach, sie öffnet direkt einen Befehlskanal.
SSH. Ein Dienst, der im Gast läuft. Er braucht das Netzwerk, er braucht den laufenden Dienst, er braucht Zugangsdaten.
Die Regel: je bequemer die Tür, desto mehr vom Gast muss funktionieren
SSH ist am bequemsten. Sie verbinden sich vom eigenen Terminal, Kopieren und Einfügen funktioniert, Sie verschieben Dateien. Dafür verlangt es am meisten: die Netzwerkkonfiguration muss stimmen, die Schnittstelle muss oben sein, der Dienst muss laufen, die Firewall muss es erlauben, Schlüssel oder Passwort müssen gültig sein. Reißt ein Glied dieser Kette, geht die Tür zu.
Die Konsole ist am unbequemsten. Sie schauen im Browser auf einen Bildschirm, und Kopieren und Einfügen ist meist mühsam. Dafür verlangt sie fast nichts: das Netzwerk des Gastes kann kaputt sein, die Firewall kann alles blockieren, SSH kann gar nicht installiert sein, und der Bildschirm erscheint trotzdem. Denn dieser Bildschirm kommt vom Host, nicht aus dem Netzwerk des Gastes.
Deshalb ist die Konsole ein Rettungsweg. Nicht weil sie bequem ist, sondern weil sie von so wenig abhängt.
Der klassische Vorfall
Sie ändern eine Netzwerkeinstellung. Sie wenden sie an. Die Verbindung bricht ab und kommt nicht zurück.
Was Sie getan haben, muss nicht einmal falsch gewesen sein: manchmal stimmt die Einstellung und die Sitzung stirbt einfach, während die Schnittstelle umschaltet. Aber jetzt erreichen Sie die Maschine nicht mehr über das Netzwerk, und um es zu reparieren, müssten Sie die Maschine erreichen.
Sie öffnen die Konsole, der Bildschirm erscheint, Sie korrigieren die Einstellung. Weil sie nie über das Netzwerk lief, hat das kaputte Netzwerk sie nicht berührt.
Die praktische Gewohnheit daraus: prüfen Sie, ob sich die Konsole öffnet, bevor Sie eine Netzwerkeinstellung anfassen. Machen Sie die riskante Arbeit, während Sie einen funktionierenden Rettungsweg schon in der Hand halten, statt danach einen zu suchen.
Auf der Shell-Seite sind Container und virtuelle Maschine nicht dasselbe
Diese Unterscheidung überrascht viele, denn im Panel stehen beide nebeneinander und beide bieten denselben Knopf.
In einem Container kann der Host direkt hineingehen. Der Container teilt sich den Kernel des Hosts, die Prozesse darin sind für den Host also ohnehin sichtbar. Der Host kann dort einen Befehl ausführen und verlangt vom Inneren nichts.
In einer virtuellen Maschine läuft es nicht so. Eine virtuelle Maschine ist eine verschlossene Kiste: der Host sieht ihre Platte und ihren Speicher als Blöcke und weiß nicht, was darin ist. Der Host kann keinen Befehl in die Kiste schieben.
Der einzige Weg hinein ist, dass etwas in der Kiste zuhört. Genau das ist der Gastagent: ein kleiner Dienst, der in der virtuellen Maschine installiert wird, Anfragen vom Host entgegennimmt und beantwortet. Ist er nicht installiert, existiert die Shell-Tür für diese virtuelle Maschine nicht, und das ist kein Fehler, sondern eine Folge der Architektur.
Aus demselben Grund funktioniert die Shell nicht, solange eine virtuelle Maschine aus ist. Es ist nichts da, das zuhören könnte. Die Konsole dagegen zeigt Ihnen auch den Bildschirm einer ausgeschalteten Maschine, und wenn Sie sie starten, sehen Sie ab der ersten Sekunde, was passiert.
Auch die Konsole hat Grenzen
Ehrlich gesagt ist die Konsole nicht magisch.
Ist der Host selbst aus, sind alle drei Türen zu. Die Konsole geht über den Host, also geht sie mit, wenn er geht.
Und noch etwas: die Konsole gibt Ihnen einen Bildschirm, keine Dateien. Wenn Sie eine Datei herausholen müssen, ist die Konsole ein schlechtes Werkzeug. Gut zur Rettung, nicht für die tägliche Arbeit.
Schließlich ist der Konsolenzugriff eine eigene Berechtigung. Dass ein Benutzer das Panel lesen kann, heißt nicht, dass er auf die Bildschirme der Maschinen schauen darf, und diese Trennung ist beabsichtigt: ein Bildschirm zeigt den Inhalt der laufenden Arbeit.
Was Atlas macht
Atlas öffnet die Konsole vom eigenen Bildschirm aus, ohne eine zweite Anmeldung zu verlangen. Das klingt klein, aber dahinter steckt eine Geschichte, die es wert ist, ehrlich erzählt zu werden.
Die Konsole lebt eigentlich unter der eigenen Adresse des Proxmox-Panels. Atlas liegt unter einer anderen. Für einen Browser sind das zwei getrennte Seiten, und die Sitzung der einen geht nicht von selbst auf die andere über. Ohne Gegenmaßnahme bekommt ein Benutzer beim Druck auf den Konsolenknopf einen Fehler "keine Sitzung" und wird gebeten, sich ein zweites Mal am Panel anzumelden.
Die erste Lösung war diese: die Sitzung aus einem unsichtbaren Rahmen heraus an das Panel übergeben. Es funktionierte. Dann verschärften die Browser ihre Regeln für Cookies von Drittanbietern, und es funktionierte nicht mehr. Im Code war kein Fehler; der Boden darunter hatte sich verschoben.
Die zweite Lösung blieb, weil sie stabiler ist: die Konsole wird von der eigenen Adresse von Atlas ausgeliefert. Der Browser sieht eine einzige Seite, es bleibt keine Sitzung zu übergeben, und das Problem verschwindet an seiner Quelle.
Zwei kleine, aber ehrliche Details: die Cookie-setzenden Kopfzeilen in den Antworten vom Panel werden entfernt, Atlas sammelt also keine Panel-Cookies unter der eigenen Adresse. Und die Verbindung zum Panel bleibt innerhalb der Maschine, sie geht nie hinaus ins Netzwerk.
Die allgemeine Lehre, unabhängig von jedem Produkt: eine funktionierende Lösung, die aufhört zu funktionieren, bedeutet nicht immer einen Fehler. Manchmal hat sich eine Annahme geändert, auf die Sie sich gestützt haben. Die Lösung, die bleibt, ist die, die sich auf weniger Annahmen stützt.
Quellen
Die eigene Dokumentation von Proxmox. Auf Englisch, und sie hat in dieser Sache das letzte Wort.