Konsol, skal og SSH: tre separate døre til den samme maskine

Du kan ikke nå en maskine. Inden du går i panik, så stil ét spørgsmål: hvilken dør brugte du?

Der er tre separate døre til den samme maskine, og hver af dem afhænger af, at forskellige ting lever. At vide hvilken der lukkede, fortæller dig direkte, hvor problemet ligger.

Tre døre

Konsol. At kigge på maskinens skærm og tastatur. Svarende til at gå hen til en fysisk server og sætte en skærm til. Den bruger ikke gæstens netværk, den går via værten.

Skal. At skrive en kommando og få output tilbage. Den efterligner ikke en skærm, den åbner en kommandokanal direkte.

SSH. En tjeneste, der kører inde i gæsten. Den skal bruge netværket, den skal have tjenesten kørende, den skal bruge legitimationsoplysninger.

Reglen: jo mere bekvem døren er, jo mere af gæsten skal virke

SSH er den mest bekvemme. Du forbinder fra din egen terminal, kopiér og indsæt virker, du flytter filer. Til gengæld kræver den mest: netværksopsætningen skal være rigtig, grænsefladen skal være oppe, tjenesten skal køre, firewallen skal tillade det, nøglen eller adgangskoden skal være gyldig. Brister ét led i den kæde, lukker døren.

Konsollen er den mindst bekvemme. Du ser på en skærm i en browser, og kopiér og indsæt er som regel besværligt. Til gengæld kræver den næsten intet: gæstens netværk kan være ødelagt, firewallen kan blokere alt, SSH behøver slet ikke at være installeret, og skærmen dukker op alligevel. For den skærm kommer fra værten, ikke fra gæstens netværk.

Derfor er konsollen en redningsvej. Ikke fordi den er bekvem, men fordi den afhænger af så lidt.

Den klassiske hændelse

Du ændrer en netværksindstilling. Du anvender den. Forbindelsen falder og kommer ikke tilbage.

Det du gjorde behøver ikke engang at have været forkert: nogle gange er indstillingen korrekt, og sessionen dør blot, mens grænsefladen skifter over. Men nu når du ikke maskinen over netværket, og for at rette det skulle du netop nå maskinen.

Du åbner konsollen, skærmen dukker op, du retter indstillingen. Fordi den aldrig gik over netværket, rørte det ødelagte netværk den ikke.

Den praktiske vane, der følger: bekræft at konsollen åbner, før du rører en netværksindstilling. Lav det risikable arbejde, mens du allerede holder en fungerende redningsvej, i stedet for at lede efter en bagefter.

På skalsiden er en container og en virtuel maskine ikke det samme

Denne forskel overrasker mange, for i panelet står de to ved siden af hinanden og tilbyder den samme knap.

I en container kan værten gå direkte ind. Containeren deler værtens kerne, så processerne derinde er allerede synlige for værten. Værten kan køre en kommando derinde uden at bede indersiden om noget.

I en virtuel maskine virker det ikke sådan. En virtuel maskine er en forseglet kasse: værten ser dens disk og hukommelse som blokke og ved ikke, hvad der er indeni. Værten kan ikke skubbe en kommando ind i kassen.

Den eneste vej ind er, at noget inde i kassen lytter. Det er præcis, hvad gæsteagenten er: en lille tjeneste installeret inde i den virtuelle maskine, som lytter efter forespørgsler fra værten og svarer. Er den ikke installeret, findes skaldøren ikke for den virtuelle maskine, og det er ikke en fejl, men en følge af arkitekturen.

Af samme grund virker skallen ikke, mens en virtuel maskine er slukket. Der er intet, der lytter. Konsollen viser derimod også skærmen på en slukket maskine, og når du starter den, ser du fra første sekund, hvad der sker.

Konsollen har også grænser

Ærligt talt er konsollen ikke magisk.

Er værten selv nede, er alle tre døre lukkede. Konsollen går via værten, så den forsvinder sammen med den.

Og så er der dette: konsollen giver dig en skærm, ikke filer. Skal du have en fil ud, er konsollen et dårligt værktøj. God til redning, ikke til dagligt arbejde.

Endelig er konsoladgang en separat rettighed. At en bruger kan læse panelet betyder ikke, at vedkommende må se maskinernes skærme, og den adskillelse er tilsigtet: en skærm viser indholdet af det arbejde, der er i gang.

Hvad Atlas gør

Atlas åbner konsollen fra sin egen skærm uden at bede om et andet login. Det lyder småt, men bag ligger en historie, der er værd at fortælle ærligt.

Konsollen bor faktisk på Proxmox-panelets egen adresse. Atlas ligger på en anden. For en browser er det to separate websteder, og den enes session følger ikke automatisk med til den anden. Uden tiltag får en bruger, der trykker på konsolknappen, en fejl om "ingen session" og bliver bedt om at logge ind på panelet en gang til.

Den første løsning var denne: at overdrage sessionen til panelet inde fra en usynlig ramme. Det virkede. Så strammede browserne deres regler for tredjeparts cookies, og det holdt op med at virke. Der var ingen fejl i koden; jorden under den flyttede sig.

Den anden løsning blev, fordi den er mere solid: konsollen serveres fra Atlas sin egen adresse. Browseren ser ét enkelt websted, der er ingen session tilbage at overdrage, og problemet forsvinder ved kilden.

To små, men ærlige detaljer: de hoveder, der sætter cookies i svarene fra panelet, fjernes, så Atlas samler ikke panelcookies på sin egen adresse. Og forbindelsen til panelet bliver inde i maskinen, den går aldrig ud på netværket.

Den generelle lære, uafhængigt af produkt: en løsning, der virkede og holder op med at virke, betyder ikke altid en fejl. Nogle gange har en antagelse, du lænede dig op ad, ændret sig. Den løsning, der holder, er den, der læner sig op ad færre antagelser.