Console, shell e SSH: tre porte distinte verso la stessa macchina

Non riesci a raggiungere una macchina. Prima di farti prendere dal panico, fatti una domanda: quale porta stavi usando?

Ci sono tre porte distinte verso la stessa macchina, e ognuna dipende da cose diverse che devono funzionare. Sapere quale si è chiusa ti dice subito dov'è il problema.

Tre porte

Console. Guardare lo schermo e la tastiera della macchina. L'equivalente di avvicinarsi a un server fisico e collegare un monitor. Non usa la rete dell'ospite, passa dall'host.

Shell. Scrivere un comando e ricevere l'output. Non imita uno schermo, apre direttamente un canale di comando.

SSH. Un servizio che gira dentro l'ospite. Serve la rete, serve il servizio attivo, servono le credenziali.

La regola: più la porta è comoda, più parti dell'ospite devono funzionare

SSH è la più comoda. Ti colleghi dal tuo terminale, copia e incolla funziona, sposti file. In cambio chiede il massimo: la configurazione di rete deve essere giusta, l'interfaccia deve essere attiva, il servizio deve girare, il firewall deve permetterlo, chiave o password devono essere valide. Si spezza un anello della catena e la porta si chiude.

La console è la meno comoda. Guardi uno schermo dentro un browser, e copia e incolla di solito è scomodo. In cambio non chiede quasi nulla: la rete dell'ospite può essere rotta, il firewall può bloccare tutto, SSH può non essere nemmeno installato, e lo schermo compare lo stesso. Perché quello schermo arriva dall'host, non dalla rete dell'ospite.

Per questo la console è una via di recupero. Non perché sia comoda, ma perché dipende da pochissimo.

L'incidente classico

Cambi un'impostazione di rete. La applichi. La connessione cade e non torna.

Quello che hai fatto potrebbe non essere nemmeno sbagliato: a volte l'impostazione è corretta e la sessione muore semplicemente mentre l'interfaccia passa alla nuova configurazione. Ma ora non raggiungi più la macchina via rete, e per sistemarla dovresti proprio raggiungerla.

Apri la console, lo schermo compare, correggi l'impostazione. Non essendo mai passata dalla rete, la rete rotta non l'ha toccata.

L'abitudine pratica che ne deriva: verifica che la console si apra prima di toccare un'impostazione di rete. Fai il lavoro rischioso quando hai già in mano una via di recupero funzionante, invece di cercarne una dopo.

Sul lato shell, container e macchina virtuale non sono la stessa cosa

Questa distinzione sorprende molti, perché nel pannello i due stanno affiancati e offrono lo stesso pulsante.

In un container l'host può entrare direttamente. Il container condivide il kernel dell'host, quindi i processi dentro sono già visibili all'host. L'host può eseguire un comando lì dentro senza chiedere nulla all'interno.

In una macchina virtuale non funziona così. Una macchina virtuale è una scatola sigillata: l'host vede il suo disco e la sua memoria come blocchi e non sa cosa contengano. L'host non può spingere un comando dentro la scatola.

L'unica via d'ingresso è che qualcosa dentro la scatola stia in ascolto. L'agente ospite è esattamente questo: un piccolo servizio installato dentro la macchina virtuale che ascolta le richieste dell'host e risponde. Se non è installato, la porta della shell per quella macchina virtuale non esiste, e non è un guasto, è una conseguenza dell'architettura.

Per lo stesso motivo la shell non funziona mentre una macchina virtuale è spenta. Non c'è nulla in ascolto. La console invece mostra anche lo schermo di una macchina spenta, e quando la accendi vedi cosa succede dal primo secondo.

Anche la console ha limiti

Ad essere onesti, la console non è magica.

Se l'host stesso è spento, tutte e tre le porte sono chiuse. La console passa dall'host, quindi se ne va insieme a lui.

E poi c'è questo: la console ti dà uno schermo, non i file. Se devi tirare fuori un file, la console è uno strumento pessimo. Buona per il recupero, non per il lavoro quotidiano.

Infine l'accesso alla console è un permesso separato. Che un utente possa leggere il pannello non significa che possa guardare gli schermi delle macchine, e quella separazione è voluta: uno schermo mostra il contenuto del lavoro in corso.

Cosa fa Atlas

Atlas apre la console dal proprio schermo, senza chiedere un secondo accesso. Sembra poco, ma dietro c'è una storia che vale la pena raccontare onestamente.

La console vive in realtà all'indirizzo proprio del pannello Proxmox. Atlas sta a un altro. Per un browser sono due siti distinti, e la sessione di uno non passa da sola all'altro. Senza fare nulla, l'utente che preme il pulsante console riceve un errore "nessuna sessione" e gli viene chiesto di accedere al pannello una seconda volta.

La prima soluzione era questa: passare la sessione al pannello da dentro un riquadro invisibile. Funzionava. Poi i browser hanno stretto le regole sui cookie di terze parti e ha smesso di funzionare. Nel codice non c'era alcun errore; si era spostato il terreno sotto di esso.

La seconda soluzione è rimasta perché è più solida: la console viene servita dall'indirizzo proprio di Atlas. Il browser vede un solo sito, non resta nessuna sessione da passare, e il problema sparisce alla fonte.

Due dettagli piccoli ma onesti: le intestazioni che impostano cookie nelle risposte in arrivo dal pannello vengono rimosse, quindi Atlas non accumula cookie del pannello al proprio indirizzo. E la connessione verso il pannello resta dentro la macchina, non esce mai in rete.

La lezione generale, indipendente da qualsiasi prodotto: una soluzione che funzionava e smette di funzionare non significa sempre un errore. A volte è cambiata un'ipotesi su cui ti appoggiavi. La soluzione che dura è quella che si appoggia a meno ipotesi.