Si può gestire Proxmox senza riga di comando: la risposta onesta

La maggior parte di chi fa questa domanda in realtà si chiede due cose diverse: "ce la faccio" e "mi perderò qualcosa". Entrambe le risposte sono migliori di quanto si creda, ma in mezzo c’è un avvertimento importante.

Il pannello non è una via minore

L’idea diffusa è che l’interfaccia sia una shell semplificata e che il lavoro vero si faccia da riga di comando. Non è così. Il pannello e la riga di comando parlano con la stessa interfaccia: quella di programmazione propria di Proxmox. Il pulsante che premi nel pannello e il comando che scrivi nel terminale passano dalla stessa porta.

Il lavoro fatto dal pannello quindi non è una "versione leggera". È lo stesso lavoro, da una superficie diversa.

Quasi tutto il lavoro quotidiano è già nel pannello

Creare macchine, avviarle, fermarle, prendere istantanee, fare backup, definire storage, sistemare la rete, creare utenti e dare permessi, aggiornare. Tutto questo c’è nell’interfaccia, e per la maggior parte la riga di comando è comunque più lenta.

Dove la riga di comando serve davvero

Quei casi sono pochi ma non zero, ed essere onesti impone di dirlo. Di solito rientrano in tre famiglie: quando un componente si rompe in modo inatteso (leggere i registri di sistema, capire perché un servizio non parte), quando si lavora in massa (applicare la stessa modifica a cento macchine), e quando si usa una capacità nuova o molto particolare che l’interfaccia non copre ancora.

Nota che cosa hanno in comune queste tre: sono tutte fuori dall’ordinario. Nessuna fa parte del lavoro quotidiano.

Il pericolo vero non è il non sapere

È la frase più importante di questa voce: il pericolo non è non conoscere la riga di comando, è incollare un comando che non capisci.

Un comando trovato in rete gira sulla tua macchina con i tuoi permessi, e nessuno guarda il risultato. Questa wiki ne ha due esempi concreti: il comando di una riga che dovrebbe zittire l’avviso di abbonamento e che in realtà distrugge l’intera libreria dell’interfaccia, e i file compose che sembrano configurazione pur potendo consegnare al contenitore l’intera macchina.

In nessuno dei due casi il problema era che la persona non conoscesse la riga di comando. Il problema era che eseguiva qualcosa che non conosceva. Chi non tocca mai la riga di comando non cade in nessuna delle due trappole; chi la conosce a metà ci cade.

Se vuoi imparare, l’ordine giusto

Non stiamo dicendo di evitarla. Ma l’ordine conta: impara prima i comandi che leggono, poi quelli che scrivono. I comandi che mostrano lo stato, leggono i registri ed elencano non rompono nulla, e ti insegnano come ragiona il sistema. Passa ai comandi che scrivono solo quando riesci a leggere che cosa fanno.

E una regola: non eseguire un comando che non capisci su una macchina che porta il tuo lavoro. Se vuoi provare, crea una macchina per provare; tutte le voci su backup e ripristino di questa wiki esistono proprio per questo.

Che cosa fa Atlas

Atlas sta dalla parte di chi porta il lavoro quotidiano nel pannello, quindi cerca di allargare l’elenco del "quasi tutto" qui sopra. Ma nel farlo non nasconde nulla: dice che cosa farà un’operazione, e per le operazioni senza ritorno lo dice prima dell’operazione.

La stessa postura compare in due punti direttamente legati a questa voce. Gli script di installazione e i file compose vengono esaminati prima di essere eseguiti, e le righe che bucano il confine del contenitore ti vengono mostrate. I lavori che toccano file, come zittire l’avviso di abbonamento, si fanno nel prodotto invece che a mano, e dopo la scrittura il file viene riletto e verificato.

L’obiettivo quindi non è nasconderti la riga di comando. L’obiettivo è che tu non debba mai incollare un comando che non capisci.