Konsola, powłoka i SSH: trzy osobne drzwi do tej samej maszyny

Nie możesz dosięgnąć maszyny. Zanim wpadniesz w panikę, zadaj jedno pytanie: których drzwi używałeś?

Do tej samej maszyny prowadzą trzy osobne drzwi, a każde zależy od tego, żeby coś innego żyło. Wiedza o tym, które się zamknęły, mówi ci wprost, gdzie jest problem.

Troje drzwi

Konsola. Patrzenie na ekran i klawiaturę maszyny. Odpowiednik podejścia do fizycznego serwera i podłączenia monitora. Nie używa sieci gościa, idzie przez hosta.

Powłoka. Wpisanie polecenia i otrzymanie wyjścia. Nie naśladuje ekranu, otwiera wprost kanał poleceń.

SSH. Usługa działająca wewnątrz gościa. Potrzebuje sieci, potrzebuje działającej usługi, potrzebuje poświadczeń.

Reguła: im wygodniejsze drzwi, tym więcej z gościa musi działać

SSH jest najwygodniejsze. Łączysz się z własnego terminala, kopiowanie działa, przenosisz pliki. W zamian wymaga najwięcej: konfiguracja sieci musi być poprawna, interfejs musi stać, usługa musi działać, zapora musi na to pozwolić, klucz albo hasło musi być ważne. Pęknie jedno ogniwo tego łańcucha i drzwi się zamykają.

Konsola jest najmniej wygodna. Patrzysz na ekran w przeglądarce, a kopiowanie bywa uciążliwe. W zamian nie wymaga prawie niczego: sieć gościa może być zepsuta, zapora może blokować wszystko, SSH może być w ogóle nie zainstalowane, a ekran i tak się pojawi. Bo ten ekran przychodzi od hosta, a nie z sieci gościa.

Dlatego konsola jest drogą odzyskania. Nie dlatego, że jest wygodna, tylko dlatego, że zależy od tak niewielu rzeczy.

Klasyczne zdarzenie

Zmieniasz ustawienie sieci. Stosujesz je. Połączenie znika i nie wraca.

To, co zrobiłeś, mogło nawet nie być błędne: czasem ustawienie jest poprawne, a sesja po prostu ginie, gdy interfejs się przełącza. Ale teraz nie dosięgasz maszyny przez sieć, a naprawa wymaga dosięgnięcia maszyny.

Otwierasz konsolę, ekran się pojawia, poprawiasz ustawienie. Ponieważ nigdy nie szła przez sieć, zepsucie sieci jej nie dotknęło.

Praktyczny nawyk, który z tego wynika: upewnij się, że konsola się otwiera, zanim dotkniesz ustawienia sieci. Wykonuj ryzykowną pracę, mając już w ręku działającą drogę odzyskania, zamiast szukać jej potem.

Po stronie powłoki kontener i maszyna wirtualna to nie to samo

To rozróżnienie zaskakuje wielu, bo w panelu oba stoją obok siebie i oba oferują ten sam przycisk.

W kontenerze host może wejść wprost. Kontener dzieli jądro hosta, więc procesy w środku są dla hosta już widoczne. Host może uruchomić tam polecenie i niczego od wnętrza nie żąda.

W maszynie wirtualnej tak to nie działa. Maszyna wirtualna jest zapieczętowanym pudełkiem: host widzi jej dysk i pamięć jako bloki i nie wie, co jest w środku. Host nie może wepchnąć polecenia do pudełka.

Jedyną drogą do środka jest to, żeby coś w pudełku nasłuchiwało. Dokładnie tym jest agent gościa: mała usługa instalowana wewnątrz maszyny wirtualnej, która nasłuchuje żądań hosta i na nie odpowiada. Jeśli nie jest zainstalowana, drzwi powłoki dla tej maszyny nie istnieją, a to nie jest awaria, tylko skutek architektury.

Z tego samego powodu powłoka nie działa, gdy maszyna wirtualna jest wyłączona. Nie ma tam nikogo, kto nasłuchuje. Konsola natomiast pokaże ci ekran także wyłączonej maszyny, a gdy ją uruchomisz, zobaczysz, co się dzieje, od pierwszej sekundy.

Konsola też ma granice

Uczciwie mówiąc, konsola nie jest magiczna.

Jeśli sam host leży, wszystkie troje drzwi są zamknięte. Konsola idzie przez hosta, więc gdy host odchodzi, ona odchodzi razem z nim.

I jeszcze to: konsola daje ci ekran, a nie pliki. Jeśli musisz wyciągnąć plik, konsola jest kiepskim narzędziem. Dobra do odzyskiwania, nie do codziennej pracy.

Wreszcie dostęp do konsoli jest osobnym uprawnieniem. To, że użytkownik może czytać panel, nie znaczy, że może patrzeć na ekrany maszyn, a to rozdzielenie jest celowe: ekran pokazuje treść wykonywanej pracy.

Co robi Atlas

Atlas otwiera konsolę z własnego ekranu, bez proszenia o drugie logowanie. Brzmi to drobno, ale stoi za tym historia warta uczciwego opowiedzenia.

Konsola mieszka w istocie pod własnym adresem panelu Proxmoksa. Atlas jest pod innym. Dla przeglądarki są to dwie osobne witryny, a sesja jednej nie przechodzi sama na drugą. Bez żadnych działań użytkownik naciskający przycisk konsoli dostaje błąd o braku sesji i prośbę o powtórne zalogowanie do panelu.

Pierwsze rozwiązanie było takie: przekazać sesję panelowi z wnętrza niewidocznej ramki. Działało. Potem przeglądarki zaostrzyły reguły dotyczące plików cookie stron trzecich i przestało działać. W kodzie nie było błędu; przesunął się grunt pod nim.

Drugie rozwiązanie zostało, bo jest solidniejsze: konsola serwowana jest z własnego adresu Atlasa. Przeglądarka widzi jedną witrynę, nie zostaje żadna sesja do przekazania, a problem znika u źródła.

Dwa drobne, ale uczciwe szczegóły: nagłówki ustawiające pliki cookie w odpowiedziach wracających z panelu są usuwane, więc Atlas nie gromadzi cookie panelu pod własnym adresem. A połączenie do panelu zostaje wewnątrz maszyny, nigdy nie wychodzi do sieci.

Ogólna lekcja, niezależna od jakiegokolwiek produktu: działające rozwiązanie, które przestaje działać, nie zawsze oznacza błąd. Czasem zmieniło się założenie, na którym się opierałeś. Rozwiązanie, które trwa, to takie, które opiera się na mniejszej liczbie założeń.