Konzol, shell és SSH: három külön ajtó ugyanahhoz a géphez

Egy gép elérhetetlenné vált. Pánik előtt egyetlen kérdés jön: melyik ajtón át zajlott a hozzáférés?

Ugyanahhoz a géphez három külön ajtó vezet, és mindegyik más dolgok életben létén múlik. Abból, hogy melyik zárult be, közvetlenül kiderül, hol a hiba.

Három ajtó

Konzol. A gép képernyőjének és billentyűzetének elérése. Annak felel meg, mintha valaki odasétálna a fizikai szerverhez és monitort dugna bele. Nem a vendég hálózatát használja, hanem a gazdagépen keresztül megy.

Shell. Parancs beírása és a kimenet visszakapása. Nem képernyőt utánoz, hanem közvetlenül parancscsatornát nyit.

SSH. A vendégen belül futó szolgáltatás. Kell hozzá a hálózat, kell hozzá, hogy a szolgáltatás fusson, és kellenek hitelesítő adatok.

A szabály: minél kényelmesebb az ajtó, annál többnek kell működnie a vendégen belül

Az SSH a legkényelmesebb. A kapcsolat saját terminálból indul, a másolás és beillesztés működik, fájlok mozgathatók. Cserébe ez követeli a legtöbbet: a hálózati beállításnak helyesnek kell lennie, a csatolónak fent kell lennie, a szolgáltatásnak futnia kell, a tűzfalnak engednie kell, a kulcsnak vagy a jelszónak érvényesnek kell lennie. Ha ebben a láncban bármelyik szem elszakad, az ajtó bezárul.

A konzol a legkényelmetlenebb. Egy képernyő látszik a böngészőben, a másolás és beillesztés pedig többnyire nehézkes. Cserébe szinte semmit nem követel: a vendég hálózata lehet elromolva, a tűzfal blokkolhat mindent, az SSH lehet eltávolítva, a képernyő ettől még megjelenik. Mert ez a képernyő a gazdagéptől érkezik, nem a vendég hálózatából.

Ezért a konzol helyreállítási útvonal. Nem azért, mert kényelmes, hanem mert olyan kevés mindenen múlik.

A klasszikus eset

Egy hálózati beállítás módosul. Az érvényesítés megtörténik. A kapcsolat megszakad, és nem tér vissza.

Lehet, hogy a művelet nem is volt hibás: néha a beállítás helyes, és a munkamenet egyszerűen elhal, miközben a csatoló átvált. A gép viszont ettől kezdve nem érhető el a hálózaton, a javításhoz pedig el kellene érni a gépet.

A konzol megnyitása után megjelenik a képernyő, és a beállítás javítható. Mivel a konzol soha nem ment át a hálózaton, a hálózat elrontása nem érintette.

Az ebből következő gyakorlati szokás: hálózati beállítás érintése előtt érdemes meggyőződni arról, hogy a konzol megnyílik. A kockázatos munka akkor jó, ha a működő helyreállítási útvonal már megvan, nem pedig utólag kell keresni.

A shell oldalán a konténer és a virtuális gép nem ugyanaz

Ez a különbség sokakat meglep, mert a panelen a kettő egymás mellett ül, és mindkettő ugyanazt a gombot kínálja.

Konténer esetén a gazdagép egyenesen belép. A konténer a gazdagép rendszermagján osztozik, ezért a benne futó folyamatok eleve láthatók a gazdagép számára. A gazdagép le tud futtatni ott egy parancsot, és semmit nem kér a belső oldaltól.

Virtuális gép esetén ez nem így működik. A virtuális gép lezárt doboz: a gazdagép a lemezét és a memóriáját blokként látja, és nem tudja, mi van benne. A gazdagép nem tud parancsot betolni a dobozba.

Bejutni csak úgy lehet, ha a dobozon belül valami figyel. Pontosan ez a vendégügynök: a virtuális gépbe telepített kis szolgáltatás, amely a gazdagép kéréseit figyeli és válaszol rájuk. Ha nincs telepítve, a shell ajtó nem létezik az adott virtuális géphez, és ez nem hiba, hanem a felépítés következménye.

Ugyanezért nem működik a shell, amíg a virtuális gép ki van kapcsolva. Nincs ott semmi, ami figyelne. A konzol ezzel szemben a kikapcsolt gép képernyőjét is megmutatja, és indítás után az első másodperctől látszik, mi történik.

A konzolnak is vannak korlátai

Őszintén szólva a konzol nem varázslat.

Ha maga a gazdagép áll, mindhárom ajtó áll. A konzol a gazdagépen keresztül megy, tehát a gazdagéppel együtt bukik.

És még valami: a konzol képernyőt ad, nem fájlokat. Fájl kimentéséhez gyenge eszköz. Helyreállításra jó, napi munkára nem.

Végül a konzolhoz való hozzáférés külön jogosultság. Attól, hogy egy felhasználó olvashatja a panelt, még nem nézhet bele a gépek képernyőjébe, és ez a szétválasztás szándékos: a képernyő az elvégzett munka tartalmát mutatja.

Mit csinál az Atlas

Az Atlas a saját képernyőjéről nyitja meg a konzolt, második bejelentkezés kérése nélkül. Ez apróságnak hangzik, de van mögötte egy történet, amelyet érdemes őszintén elmondani.

A konzol valójában a Proxmox panel saját címén lakik. Az Atlas egy másikon. A böngésző számára ez két külön oldal, és az egyik oldal munkamenete magától nem kerül át a másikra. Beavatkozás nélkül a konzol gombot megnyomó felhasználó "nincs munkamenet" hibát kap, és a rendszer másodszor is kéri a panelbe való bejelentkezést.

Az első megoldás ez volt: a munkamenet átadása a panelnek egy láthatatlan kereten belülről. Működött. Aztán a böngészők szigorítottak a harmadik feles sütikre vonatkozó szabályaikon, és ez megszűnt működni. A kódban nem volt hiba; a talaj mozdult el alatta.

A második megoldás azért maradt, mert szilárdabb: a konzol az Atlas saját címéről érkezik. A böngésző egyetlen oldalt lát, nem marad átadandó munkamenet, és a gond a forrásánál tűnik el.

Két apró, de őszinte részlet: a panelről visszaérkező válaszokon a sütiket beállító fejlécek eltávolításra kerülnek, így az Atlas nem gyűjt panelsütiket a saját címén. A panelhez tartó kapcsolat pedig a gépen belül marad, soha nem lép ki a hálózatra.

Az általános tanulság, terméktől függetlenül: a működő megoldás leállása nem mindig hibát jelent. Néha egy feltevés változott meg, amelyre a megoldás támaszkodott. Az a megoldás tart ki, amelyik kevesebb feltevésre támaszkodik.