Prima di lanciare uno script della comunità sul vostro host Proxmox: cinque cose da leggere

Gli script della comunità sono davvero buoni. Portano competenza che qualcuno ha pagato con serate perse, gestiscono i casi scomodi in cui sareste incappati a mezzanotte, e per molti compiti lo script è meglio di quello che avreste scritto voi. Questo articolo non è un argomento contro di loro.

Riguarda una lacuna precisa. Un'installazione da pacchetto e uno script incollato su una riga sembrano ugualmente ordinari sullo schermo, e non sono affatto la stessa cosa.

Cosa vi dà un pacchetto e una riga incollata no

Una firma. I pacchetti sono firmati e la firma viene verificata. Un indirizzo viene verificato solo contro la vostra ipotesi che l'indirizzo sia giusto.

Una versione. Potete dire quale versione avete, e anche chi vi aiuta. "Lo script del readme, qualche settimana fa" non è una versione.

Una via di disinstallazione. I pacchetti registrano cosa hanno messo e sanno rimuoverlo. Uno script spesso mette file in sei posti e non se lo ricorda.

Un rapporto con un manutentore. Quando un pacchetto cambia comportamento c'è un registro delle modifiche. Uno script può cambiare sotto lo stesso indirizzo senza lasciare nulla da leggere.

Nulla di tutto ciò rende cattivi gli script. Li rende un tipo diverso di cosa, che merita un'abitudine diversa.

Le cinque cose da leggere

Non tutto lo script, e non riga per riga. Queste cinque risposte di solito si vedono in una passata.

① Cosa tocca fuori dalla sua cartella? Uno script che scrive solo sotto la propria cartella è facile da inquadrare. Uno che modifica file nelle cartelle di configurazione di sistema sta facendo cambiamenti che gli sopravvivranno.

② Aggiunge un repository o una chiave? È la riga con le conseguenze più pesanti in quasi tutti gli script e passa in un secondo. Aggiungere una fonte di pacchetti significa che ogni futuro aggiornamento su quella macchina si fida di una nuova parte. Può essere del tutto ragionevole e dovrebbe essere una decisione, non un effetto collaterale.

③ Tocca avvio, kernel o rete? Sono i tre che possono lasciare un host irraggiungibile o non avviabile, e su un hypervisor questo vuol dire che se ne va tutto ciò che ci sta sopra. Uno script che installa un'applicazione web non ha nulla a che fare con la configurazione del bootloader, e se la tocca vale la pena capirlo prima che parta.

④ C'è una via di ritorno? Cercate una procedura di disinstallazione o, in mancanza, un elenco di ciò che ha creato. Se non c'è né l'una né l'altro, la vostra via di ritorno è uno snapshot preso prima, il che vuol dire che dovete prenderlo.

⑤ Cosa succede se gira due volte? Molti script sono scritti per una macchina pulita, e rilanciarli duplica voci, azzera configurazioni che avevate modificato, oppure fallisce a metà lasciando uno stato a metà. Prima o poi lo lancerete due volte, di solito perché il primo giro è sembrato fallire.

La riga incollata, in particolare

Lo schema di scaricare uno script e mandarlo direttamente in una shell ha una proprietà che merita di essere nominata: non potete leggere quello che avete eseguito. Non "non l'avete fatto", non potete, perché non è mai stato un file.

C'è anche una variante più sottile. Leggere lo script nel browser e lanciare il comando scarica-e-invia sono due richieste distinte. Nulla garantisce che abbiano restituito gli stessi byte.

La soluzione costa un passaggio in più. Scaricate il file, guardatelo, poi eseguite la copia locale. Ora sapete cosa è girato, potete rieseguire l'identico più avanti, e se qualcosa si rompe avete il testo vero invece del ricordo di una pagina web.

Un hypervisor non è il posto dove provare

È questo che separa un host Proxmox da un portatile. Tutto il resto della macchina sta sotto di lui. Uno script che lascia un portatile in uno stato strano vi costa una serata; lo stesso script su un host si porta via ogni macchina virtuale.

Due abitudini rendono sicura quasi tutta la faccenda:

Provatelo prima in una macchina virtuale, se plausibilmente potete. La maggior parte degli script che installano un servizio non ha bisogno di stare sull'host. Non è un aggiramento, di solito è il posto giusto.

Se deve davvero girare sull'host, prima uno snapshot. Non perché lo script sia sospetto, ma perché "provo e vedo" è esattamente la frase che precede il bisogno di una via di ritorno.

Cosa non è questo articolo

Non è un motivo per diffidare della comunità. Gli script condivisi sono una delle cose migliori di questo ecosistema, e chi li scrive di solito è più attento di chi li esegue.

Non è un motivo per leggere ogni riga. Cinque domande in una passata bastano a intercettare il tipo di sorpresa che fa davvero male.

Cosa fa Atlas

Atlas prende uno snapshot prima delle operazioni che cambiano lo stato dell'host, così la via di ritorno esiste senza che dobbiate ricordarvi di crearla. Copre il quarto punto dell'elenco sopra, cioè quello che si salta.

Il registro di controllo annota chi ha eseguito cosa, quando, su cosa e con quale esito, trasformando "martedì scorso è cambiato qualcosa" in una risposta leggibile invece che in un'indagine.

La catena delle risorse aiuta più dopo che al momento di decidere: se dopo un'installazione qualcosa si comporta diversamente, la mappa mostra com'è fatta ora la macchina davvero, dagli ospiti fino ai dischi fisici.

E dove Atlas installa software da sé, tramite il catalogo applicazioni, la versione è fissata, la fonte è fissa e prima di iniziare viene preso un punto di ripristino. È un percorso volutamente stretto e curato e non sostituisce gli script della comunità. Sono semplicemente le stesse cinque domande, risposte in anticipo per le applicazioni che porta.