Konsol, skal och SSH: tre separata dörrar till samma maskin

Du når inte en maskin. Innan du får panik, ställ en fråga: vilken dörr använde du?

Det finns tre separata dörrar till samma maskin, och var och en beror på att olika saker lever. Att veta vilken som stängdes säger direkt var problemet sitter.

Tre dörrar

Konsol. Att titta på maskinens skärm och tangentbord. Motsvarigheten till att gå fram till en fysisk server och koppla in en bildskärm. Den använder inte gästens nätverk, den går via värden.

Skal. Att skriva ett kommando och få utdata tillbaka. Det härmar ingen skärm, det öppnar en kommandokanal direkt.

SSH. En tjänst som körs inuti gästen. Den behöver nätverket, den behöver att tjänsten är igång, den behöver inloggningsuppgifter.

Regeln: ju bekvämare dörren är, desto mer av gästen måste fungera

SSH är bekvämast. Du ansluter från din egen terminal, kopiera och klistra in fungerar, du flyttar filer. I gengäld kräver den mest: nätverkskonfigurationen måste stämma, gränssnittet måste vara uppe, tjänsten måste köra, brandväggen måste tillåta det, nyckeln eller lösenordet måste vara giltigt. Brister en länk i den kedjan stängs dörren.

Konsolen är minst bekväm. Du tittar på en skärm i en webbläsare, och att kopiera och klistra in är oftast krångligt. I gengäld kräver den nästan ingenting: gästens nätverk kan vara trasigt, brandväggen kan blockera allt, SSH behöver inte ens vara installerat, och skärmen dyker upp ändå. För den skärmen kommer från värden, inte från gästens nätverk.

Därför är konsolen en återställningsväg. Inte för att den är bekväm, utan för att den beror på så lite.

Den klassiska händelsen

Du ändrar en nätverksinställning. Du tillämpar den. Anslutningen faller och kommer inte tillbaka.

Det du gjorde behöver inte ens ha varit fel: ibland är inställningen korrekt och sessionen dör helt enkelt medan gränssnittet växlar över. Men nu når du inte maskinen över nätverket, och för att fixa det skulle du behöva nå maskinen.

Du öppnar konsolen, skärmen dyker upp, du rättar inställningen. Eftersom den aldrig gick över nätverket rörde det trasiga nätverket den inte.

Den praktiska vanan som följer: kontrollera att konsolen öppnas innan du rör en nätverksinställning. Gör det riskabla arbetet medan du redan håller en fungerande återställningsväg i handen, i stället för att leta efter en efteråt.

På skalsidan är en container och en virtuell maskin inte samma sak

Den här skillnaden överraskar många, eftersom de två står bredvid varandra i panelen och båda erbjuder samma knapp.

I en container kan värden gå rakt in. Containern delar värdens kärna, så processerna därinne är redan synliga för värden. Värden kan köra ett kommando där utan att be insidan om något.

I en virtuell maskin fungerar det inte så. En virtuell maskin är en förseglad låda: värden ser dess disk och minne som block och vet inte vad som finns inuti. Värden kan inte trycka in ett kommando i lådan.

Enda vägen in är att något inuti lådan lyssnar. Det är precis vad gästagenten är: en liten tjänst som installeras inuti den virtuella maskinen och som lyssnar på förfrågningar från värden och svarar. Är den inte installerad finns skaldörren inte för den virtuella maskinen, och det är inte ett fel utan en följd av arkitekturen.

Av samma skäl fungerar skalet inte medan en virtuell maskin är avstängd. Det finns inget som lyssnar. Konsolen visar däremot även skärmen på en avstängd maskin, och när du startar den ser du vad som händer från första sekunden.

Konsolen har också gränser

Ärligt talat är konsolen inte magisk.

Är värden själv nere är alla tre dörrarna stängda. Konsolen går via värden, så den följer med när värden faller.

Och en sak till: konsolen ger dig en skärm, inte filer. Behöver du få ut en fil är konsolen ett dåligt verktyg. Bra för återställning, inte för dagligt arbete.

Slutligen är konsolåtkomst en egen behörighet. Att en användare kan läsa panelen betyder inte att hen får titta på maskinernas skärmar, och den uppdelningen är avsiktlig: en skärm visar innehållet i det arbete som pågår.

Vad Atlas gör

Atlas öppnar konsolen från sin egen skärm utan att begära en andra inloggning. Det låter litet, men bakom finns en historia värd att berätta ärligt.

Konsolen bor egentligen på Proxmox-panelens egen adress. Atlas ligger på en annan. För en webbläsare är det två separata webbplatser, och den enas session följer inte med till den andra av sig själv. Utan åtgärd får en användare som trycker på konsolknappen ett fel om "ingen session" och ombeds logga in på panelen en andra gång.

Den första lösningen var denna: lämna över sessionen till panelen inifrån en osynlig ram. Det fungerade. Sedan skärpte webbläsarna sina regler för tredjepartskakor och det slutade fungera. Det fanns inget fel i koden; marken under den flyttade sig.

Den andra lösningen blev kvar för att den är stadigare: konsolen serveras från Atlas egen adress. Webbläsaren ser en enda webbplats, ingen session återstår att lämna över, och problemet försvinner vid källan.

Två små men ärliga detaljer: rubrikerna som sätter kakor i svaren från panelen rensas bort, så Atlas samlar inte panelkakor på sin egen adress. Och anslutningen till panelen stannar inuti maskinen, den går aldrig ut på nätverket.

Den allmänna lärdomen, oberoende av produkt: en lösning som fungerade och slutar fungera betyder inte alltid ett fel. Ibland har ett antagande du lutade dig mot ändrats. Den lösning som består är den som lutar sig mot färre antaganden.