Console, shell en SSH: drie aparte deuren naar dezelfde machine

U kunt een machine niet bereiken. Stel voordat u in paniek raakt één vraag: welke deur gebruikte u?

Er zijn drie aparte deuren naar dezelfde machine, en elke deur hangt ervan af dat iets anders werkt. Weten welke dichtging vertelt u meteen waar het probleem zit.

Drie deuren

Console. Naar het scherm en het toetsenbord van de machine kijken. Het equivalent van naar een fysieke server lopen en een monitor aansluiten. Het gebruikt het netwerk van de gast niet, het loopt via de host.

Shell. Een opdracht typen en uitvoer terugkrijgen. Het bootst geen scherm na, het opent rechtstreeks een opdrachtkanaal.

SSH. Een dienst die binnen de gast draait. Die heeft het netwerk nodig, een draaiende dienst en inloggegevens.

De regel: hoe comfortabeler de deur, hoe meer van de gast moet werken

SSH is het comfortabelst. U verbindt vanuit uw eigen terminal, kopiëren en plakken werkt, u verplaatst bestanden. In ruil daarvoor eist het het meeste: de netwerkconfiguratie moet kloppen, de interface moet actief zijn, de dienst moet draaien, de firewall moet het toestaan, de sleutel of het wachtwoord moet geldig zijn. Breekt één schakel in die keten, dan gaat de deur dicht.

De console is het minst comfortabel. U kijkt naar een scherm in een browser, en kopiëren en plakken is er meestal onhandig. In ruil daarvoor eist die bijna niets: het netwerk van de gast mag kapot zijn, de firewall mag alles blokkeren, SSH mag niet eens geïnstalleerd zijn, en het scherm verschijnt toch. Want dat scherm komt van de host, niet uit het netwerk van de gast.

Daarom is de console een herstelweg. Niet omdat die comfortabel is, maar omdat die van zo weinig afhangt.

Het klassieke voorval

U wijzigt een netwerkinstelling. U past die toe. De verbinding valt weg en komt niet terug.

Wat u deed hoeft niet eens fout te zijn geweest: soms klopt de instelling en sterft de sessie gewoon terwijl de interface overschakelt. Maar nu bereikt u de machine niet meer via het netwerk, en om het te herstellen zou u juist de machine moeten bereiken.

U opent de console, het scherm verschijnt, u corrigeert de instelling. Omdat die nooit via het netwerk liep, raakte het kapotte netwerk hem niet.

De praktische gewoonte die daaruit volgt: controleer of de console opent voordat u een netwerkinstelling aanraakt. Doe het riskante werk terwijl u al een werkende herstelweg in handen heeft, in plaats van er achteraf een te zoeken.

Aan de shell-kant zijn een container en een virtuele machine niet hetzelfde

Dit onderscheid verrast veel mensen, want in het paneel staan de twee naast elkaar en bieden ze dezelfde knop.

In een container kan de host rechtstreeks naar binnen. De container deelt de kernel van de host, dus de processen daarbinnen zijn voor de host al zichtbaar. De host kan er een opdracht uitvoeren en vraagt niets aan de binnenkant.

In een virtuele machine werkt dat niet zo. Een virtuele machine is een verzegelde doos: de host ziet de schijf en het geheugen als blokken en weet niet wat erin zit. De host kan geen opdracht de doos in duwen.

De enige weg naar binnen is dat iets binnen de doos luistert. Dat is precies wat de gastagent is: een kleine dienst die in de virtuele machine wordt geïnstalleerd en verzoeken van de host beantwoordt. Is die niet geïnstalleerd, dan bestaat de shell-deur voor die virtuele machine niet, en dat is geen storing maar een gevolg van de architectuur.

Om dezelfde reden werkt de shell niet zolang een virtuele machine uit staat. Er is niets dat luistert. De console daarentegen toont ook het scherm van een uitgeschakelde machine, en zodra u die start ziet u vanaf de eerste seconde wat er gebeurt.

Ook de console heeft grenzen

Eerlijk gezegd is de console niet magisch.

Als de host zelf uit staat, zijn alle drie de deuren dicht. De console loopt via de host, dus die gaat mee als de host valt.

En dan is er dit: de console geeft u een scherm, geen bestanden. Moet u een bestand naar buiten halen, dan is de console een slecht gereedschap. Goed voor herstel, niet voor dagelijks werk.

Tot slot is consoletoegang een aparte bevoegdheid. Dat een gebruiker het paneel kan lezen betekent niet dat die naar de schermen van de machines mag kijken, en die scheiding is bewust: een scherm toont de inhoud van het lopende werk.

Wat Atlas doet

Atlas opent de console vanaf het eigen scherm, zonder een tweede aanmelding te vragen. Dat klinkt klein, maar er zit een verhaal achter dat het waard is eerlijk verteld te worden.

De console woont eigenlijk op het eigen adres van het Proxmox-paneel. Atlas staat op een ander adres. Voor een browser zijn dat twee aparte sites, en de sessie van de ene gaat niet vanzelf over naar de andere. Zonder maatregel krijgt een gebruiker die op de consoleknop drukt een foutmelding "geen sessie" en wordt gevraagd een tweede keer op het paneel in te loggen.

De eerste oplossing was deze: de sessie vanuit een onzichtbaar kader aan het paneel overdragen. Het werkte. Daarna scherpten browsers hun regels voor cookies van derden aan en het hield op te werken. Er zat geen fout in de code; de grond eronder verschoof.

De tweede oplossing bleef omdat die steviger is: de console wordt vanaf het eigen adres van Atlas aangeboden. De browser ziet één site, er blijft geen sessie over om over te dragen, en het probleem verdwijnt bij de bron.

Twee kleine maar eerlijke details: de koppen die cookies zetten in antwoorden vanuit het paneel worden verwijderd, dus Atlas stapelt geen paneelcookies op het eigen adres op. En de verbinding naar het paneel blijft binnen de machine, die gaat nooit het netwerk op.

De algemene les, los van welk product dan ook: een werkende oplossing die stopt met werken betekent niet altijd een fout. Soms is een aanname veranderd waarop u steunde. De oplossing die blijft, is de oplossing die op minder aannames steunt.