Briefing di missione, day zero. Un mini PC appena scatolato. Una chiavetta USB vuota. Uno slot libero nella flotta. Entro sera questa macchina deve essere installata, blindata, raggiungibile sulla mesh e capace di sopravvivere a un blackout con nessuno a casa. Questo nodo l’hai già incontrato due volte: in Ghost Protocol faceva girare agenti di coding a ciclo continuo, in Pocket Protocol riceveva ordini da un telefono mentre eri in coda all’anagrafe. Non l’hai mai visto nascere. Fino a ora.

La missione che era stata saltata

Operation Minilab ha trattato l’architettura: due case, mini PC economici, un’unica operazione sincronizzata. Gli articoli successivi hanno trattato cosa ci gira sopra: l’architettura dei container , il livello di comando di Home Assistant , la dev machine sempre accesa, il relay sul telefono. Ognuno di essi dà per scontata una macchina già installata, patchata e raggiungibile in rete.

Nessuno mostra la macchina che nasce. Questo è quel pezzo: il nodo più recente della flotta, portato dall’immagine di fabbrica a membro della mesh in un pomeriggio. Scriverlo serve allo stesso scopo di sempre: la prossima volta deve essere ripetibile, noioso e indipendente dal ricordarsi cosa aveva funzionato.

La recluta

L’hardware è della stessa classe del resto della flotta, ed è una scelta deliberata. Un Blackview MP80: Intel N97, quattro core, nessun thread da rimpiangere. 16GB di RAM. Un SSD da 512GB per l’hypervisor e tutto ciò che fa girare. Niente di esotico, niente di costoso, stessa economicità da sleeper agent dei box di Operation Minilab .

Un disco in più conta: un SSD Crucial da 1TB viaggia a bordo come semplice destinazione di backup, montato su /mnt/backups, con cartelle per servizio scritte direttamente sopra: quelle di questo nodo (frigate, ha-rg) e copie portate qui dal nodo master via mesh, come i suoi dati immich e jellyfin. Due nodi in due case, ognuno con una copia dei servizi dell’altro, è l’offsite dei poveri: il box può morire senza che muoiano con lui gli archivi.

Proxmox VE non è mai stato in discussione. È la risposta di default a “fai girare VM e container su una macchina sola”, e per buone ragioni: maturo, ben documentato, noioso nei modi giusti. La dottrina resta identica su ogni nodo della flotta: il livello dell’hypervisor resta pulito e stabile, e ogni servizio vero vive nel proprio LXC o VM sopra di esso. Tocca l’host il meno possibile; il resto di questo briefing è la lista completa di cosa ci va sopra: una pulizia post-install e Tailscale stesso. Tutto il resto è eliminabile e rimpiazzabile.

Flash, boot, fatto

L’installazione è la parte meno interessante della storia, ed è esattamente il punto. Scarica l’ISO più recente di Proxmox VE (9.1.4 il giorno dell’installazione, 9.2 adesso: aggiornata in seguito da un laptop via mesh, senza tastiera. Noia nei modi giusti) e flashala su una chiavetta USB. Su macOS, diskutil list per individuare la chiavetta, poi balenaEtcher se preferisci una GUI, o la via diretta:

diskutil unmountDisk /dev/diskN          # la chiavetta USB, non il tuo disco di backup (macOS)
sudo dd if=proxmox-ve.iso of=/dev/rdiskN bs=4m   # rdiskN: il device raw, molto più veloce
diskutil eject /dev/diskN

Avvia il mini PC dalla chiavetta (su questo hardware, martella il tasto del Boot Menu all’accensione) e rispondi alle domande dell’installer: disco di destinazione, paese, fuso orario, tastiera, interfaccia di gestione, hostname, IP statico. Venti minuti, senza drammi. A fine installazione il nodo risponde già su https://<ip-del-nodo>:8006.

Un giro di pulizia prima di tutto il resto. Lo script post-install della community sistema i repository dei pacchetti (quelli no-subscription, salvo abbonamento), rimuove l’avviso di abbonamento mancante e aggiorna l’host, tutto da un menu:

bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/tools/pve/post-pve-install.sh)"

Sì, è una shell root che esegue uno script scaricato da internet: leggilo prima di eseguirlo, e sappi chi lo mantiene. Il progetto community-scripts è la continuazione mantenuta della raccolta tteck originale.

I servizi diventano one-liner

Qui sta il vero vantaggio. Proxmox VE Helper-Scripts (community-scripts/ProxmoxVE) trasforma “studiare la configurazione LXC giusta, scriverla a mano, sbagliare i mount point due volte” in “copia una riga da community-scripts.org e incollala nella shell del nodo”. Cerca il servizio nel catalogo, copia il comando, eseguilo:

bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/ct/jellyfin.sh)"

La modalità Default sceglie risorse sensate (CPU, RAM, disco) e fa solo le domande minime. La modalità Advanced ti mette in mano ogni parametro prima di iniziare. In entrambi i casi, qualche minuto dopo c’è un container che esegue il servizio, e viene fornito con un helper post-install per aggiornamenti e impostazioni comuni, così anche la manutenzione non è manuale.

Immich, Jellyfin, il prossimo che sia: il lavoro di setup ripetitivo e noioso è già risolto da chi l’ha fatto prima e l’ha condiviso. Il tuo compito si riduce a scegliere dalla lista e puntare le cose allo storage giusto. Pochi anni fa, mettere in piedi un nodo così era l’intero progetto. Oggi è il primo pomeriggio.

L’insidia: sopravvivere al blackout

Ecco quello che mi avrebbe dato un vero problema più avanti: questa macchina doveva sopravvivere a un blackout senza una visita fisica, e appena uscita dalla scatola non ci riusciva. La maggior parte dei mini PC consumer resta spenta quando torna la corrente, se nessuno glielo dice, che è esattamente il contrario di ciò che serve a qualcosa che deve girare incustodito in una casa in cui non sei sempre.

L’impostazione esiste, è solo dove non cercheresti per prima. Su questo firmware è sepolta sotto Advanced / OEM Extended Setup Configuration invece che nell’ovvia scheda Boot: Start After G3 → Power On (lo stato G3 è “alimentazione rimossa”, quindi la traduzione letterale è “quando torna la corrente, riaccenditi”).

Poi verificala nel modo onesto: stacca la spina, conta fino a dieci, ricollega, e guarda il nodo tornare online da solo. Il giorno giusto è mentre la macchina è ancora vuota, prima che ci giri sopra qualcosa con uno stato. Un recovery che non hai testato è una diceria, non una capacità.

Entrare nella mesh

Ultimo passo: Tailscale, così questa macchina è raggiungibile da ogni altro dispositivo dell’operazione senza aprire una sola porta verso internet. Installalo sull’host e attivalo:

curl -fsSL https://tailscale.com/install.sh | sh
tailscale up --accept-dns=false

Entrambi nella shell root del nodo: una Proxmox appena installata non ha sudo e qui non serve. tailscale up stampa un URL di login da aprire una volta nel browser e, già che sei nella console, disattiva la scadenza delle chiavi per questo nodo: una macchina a cui non puoi arrivare a piedi non deve mai perdere le sue chiavi.

--accept-dns=false lascia intatta la configurazione DNS dell’host: un server deve risolvere come l’hai configurato tu, non come decide un client VPN. Il compromesso è che l’host non risolverà da solo i nomi della tailnet; ogni altro membro della mesh lo raggiunge comunque col suo hostname privato, indipendentemente da quale casa, o continente, occupino fisicamente i due capi.

L’host che entra nella mesh ti dà SSH e la UI di Proxmox da qualsiasi luogo. I servizi dentro i container hanno due opzioni, entrambe one-liner: far entrare nella tailnet i singoli container che ti interessano (c’è anche per questo uno helper script, add-tailscale-lxc), oppure annunciare la subnet interna del nodo come route con tailscale up --advertise-routes=192.168.1.0/24 (la subnet della tua LAN; la route va approvata una volta nella console). Scegli per servizio: tutto ciò che vuoi raggiungere dal telefono entra direttamente, il resto resta interno.

Da lì, i servizi si impilano sopra come sempre: ognuno nel proprio LXC o VM, niente condivide stato con l’hypervisor.

Day zero, chiuso

Questa è tutta l’origine della macchina che hai già incontrato due volte: il nodo che porta una VM di Home Assistant, Frigate e Zigbee2MQTT che tengono vive le percezioni di una casa, Uptime Kuma che veglia sull’intera flotta, ComfyUI e Ollama per il turno AI locale, e la sua parte dell’operazione con gli agenti di coding. Nessun passo ha richiesto più di un caffè, e l’unico momento davvero non ovvio è stata un’impostazione BIOS nascosta un menu più in profondità di dove doveva stare.

Il day zero è chiuso. Il nodo è online e già dimenticabile. La prossima volta che la missione si ripresenta, è solo un altro pomeriggio: flash, boot, join, fatto.

Questo briefing non si autodistruggerà. È sotto version control.