L'intera cosa, non la prima metà.
Ogni guida prende una singola istanza vuota e la trasforma in un servizio a cui puoi indirizzare traffico reale. I comandi vengono eseguiti dall'alto verso il basso nell'ordine in cui sono stampati, i segnaposto sono marcati come tali e l'ultima sezione è sempre un test. Nessuna guida qui termina con "e poi configura il resto a piacere".
Una guida non è una voce di knowledge base
Entrambi i formati esistono perché ciascuno è pessimo nel lavoro dell'altro. Uniscili e ottieni il tipo di documentazione che spiega cosa fa ogni flag senza mai dirti quali flag ti servono.
La knowledge base risponde a una domanda in un minuto. Una guida ti costa un pomeriggio e ti lascia un server in esecuzione alla fine.
Una voce di knowledge base inizia con qualcosa che già possiedi e qualcosa che non va: un mount che non riesce dopo il riavvio, un certificato che si è rinnovato ma non ha ricaricato, una console di rescue da cui non riesci a ottenere un prompt. È breve perché il contesto è già nella tua testa. Arrivi con il problema e te ne vai con la risposta.
Una guida comincia dal nulla. Hai pagato una fattura, hai le credenziali di root e la macchina è un'immagine non configurata in una città scelta per ragioni tue. Alla fine hai un server di posta che supera i controlli di autenticazione, o un ipervisore con guest annidati, o due terabyte in un paese diverso da quello in cui erano stamattina. Il contesto si costruisce cammin facendo, motivo per cui queste guide superano un paio di migliaia di parole anziché duecento.
Scriverle così costa più lavoro e cattura più errori. Ogni guida in questa pagina è stata eseguita dall'inizio alla fine su un'istanza appena distribuita prima della pubblicazione, e ripetuta ogni volta che il progetto upstream pubblicava qualcosa che la rompeva. La data all'inizio di ciascuna è l'ultima data di esecuzione, non la data di una lettura veloce.
Una cosa completa
Non una rassegna di sei opzioni e un'alzata di spalle. Ogni guida sceglie un approccio, spiega perché e lo costruisce. Dove esiste una vera alternativa, guadagna una frase e un link, poi la guida prosegue.
Comandi in sequenza
Copiali nell'ordine stampato su un'immagine fresca e funzionano. Se il passaggio nove richiede un pacchetto installato al passaggio due, il passaggio due lo installa. Nulla dipende da uno stato che non ti è mai stato detto di creare.
Una macchina nominata
Ogni build specifica su quale linea è stata scritta e cosa succede se usi qualcosa di più piccolo. La messa a punto di Postgres che presuppone 64 GB di ECC è un consiglio inutile su una scatola da 16 GB, quindi lo diciamo subito.
La parte noiosa di mezzo
Proprietà dei file, irrigidimento delle unità systemd, regole del firewall, rotazione dei log. Questa è la parte che la maggior parte dei tutorial salta e che decide se il servizio è ancora attivo a marzo.
Un test alla fine
Ogni guida termina con comandi il cui output ti dice senza ambiguità se la build ha funzionato. Non "dovresti vedere la pagina di login". Qualcosa con un codice di uscita o un'intestazione leggibile.
“Se l'ultima riga della pagina è "e poi configurare il firewall", non è una guida, è una lista della spesa.”
Come seguirne una senza perdere una serata
Sono scritte per chi legge l'intera pagina prima di digitare qualsiasi cosa. Quest'abitudine vale circa un'ora per build.
Supponi un'immagine Debian 13 fresca e una shell root, salvo diversa indicazione. Tutto il resto è dichiarato nei primi due paragrafi.
- 01
Distribuisci qualcosa di nuovo
Adattare una guida a una macchina che gestisce già tre servizi è il modo per scoprire quale di essi usava silenziosamente la porta 8080. Un'istanza fresca è pronta in meno di un minuto e puoi distruggerla dopo.
- 02
Leggila tutta una volta
In particolare i passaggi DNS. Metà delle build qui richiedono che un record sia propagato prima che un comando successivo riesca, e il modo più economico per impararlo è alla prima lettura, non al passaggio undici.
- 03
Sostituisci i segnaposto
Qualsiasi cosa simile a example.com, 2001:db8: o tra parentesi angolari la sostituisci tu. Gli intervalli di documentazione sono usati deliberatamente, così un errore di copia-incolla fallisce rumorosamente invece di raggiungere in silenzio una rete di qualcun altro.
- 04
Snapshot prima della parte irreversibile
Ripartizionare, dist-upgrade, qualsiasi cosa che coinvolga la parola "cancella". Un pacchetto snapshot ti dà cinque slot e un ripristino che finisce in secondi, il che è più economico che ripetere i passaggi da uno a nove.
- 05
Esegui la verifica
È l'ultima sezione di ogni guida ed esiste perché "sembrava partire" non è la stessa cosa che "funziona". Due minuti di controllo battono la scoperta da parte di un utente.
Nessuna pagina qui incanala uno script remoto in una shell. Dove un progetto upstream offre solo un programma di installazione in quel modo, la guida ti mostra come recuperarlo, leggerlo ed eseguirlo come file: dovresti sapere cosa è finito sulla tua macchina, e così anche noi.
Quale macchina vuole ogni build
La maggior parte di questi gira senza problemi sull'istanza Ryzen più piccola. Quattro di questi no, e scegliere la riga sbagliata per quei quattro ti fa perdere un pomeriggio prima di arrivare alla parte interessante.
Dove una guida indica un piano, quello è il piano su cui è stata testata. Andare su un piano più piccolo di solito va bene ed è indicato dove non va bene. Andare su uno più grande non cambia nulla tranne i numeri che inserisci nei file di configurazione, e le guide che si occupano di quell'aritmetica mostrano l'aritmetica.
| Build | Linea | Perché quella |
|---|---|---|
| WireGuard, relay Tor, Matrix, monitoraggio | Ryzen R-4 | Single-thread, vincolato alla rete, working set minuscolo. Più core non cambiano nulla. |
| Server di posta, runner CI, Nextcloud | Ryzen R-8 | Le fasi di build e l'antispam amano entrambi core veloci. Le build di immagini sono la cosa più pesante qui. |
| Postgres | EPYC E-8 e superiori | La messa a punto in quella guida presuppone 64 GB di memoria ECC e pinning NUMA-aware. |
| Inferenza locale | GPU G-L40S | Quarantotto gigabyte di VRAM, passati direttamente. Una scheda condivisa è la coda di qualcun altro. |
| Seedbox | Storage S-50 | Cinquanta terabyte di storage bulk dietro un tier di scrittura NVMe, su una porta abbastanza grande da svuotarlo. |
| Proxmox con guest annidati | Bare metal BM-E | La virtualizzazione annidata richiede la macchina fisica. Non c'è un nostro hypervisor in mezzo. |
| Spostare due terabyte tra i siti | Due istanze qualsiasi | Scritto pensando a un nodo di storage e a una macchina Ryzen, ma il metodo è lo stesso a qualsiasi dimensione. |
Ogni guida presuppone il /64 IPv6 instradato fornito con ogni istanza. Due di esse richiedono invece il /48, perché distribuire sottoreti per client da un singolo /64 significa fare proxying della neighbor discovery, e l'IPv6 proxato è una cosa che debugghi per lavoro, non che gestisci.
Privacy
03Infrastruttura
04Sviluppo
02Rete
02Domande sulle guide, piuttosto che sui build
Per lo più sì. Le parti che sono nostre sono i passaggi del pannello, il prefisso instradato e il presupposto di core dedicati. Tutto il resto è Debian standard e software upstream, quindi i comandi si portano puliti su qualsiasi posto che ti dia root e non overselli la CPU.
Perché scrivere dodici guide cinque volte è come la documentazione diventa obsoleta. Debian 13 è la nostra immagine predefinita, i nomi dei pacchetti sono stabili per anni, e tradurre un passaggio per AlmaLinux o Alpine è una sostituzione del gestore di pacchetti, non una riscrittura. L'elenco completo delle immagini è sulla pagina dei sistemi operativi.
Diccelo. Le guide vengono rieseguite su un'immagine pulita quando sentiamo di un problema, e la versione corretta esce la stessa settimana con la data in alto aggiornata. Un ticket con il comando e l'errore è sufficiente; non devi fare noi la diagnosi.
Supportiamo la macchina, la rete e lo storage sottostante. Fare debug dei tuoi file map di Postfix alle tre di notte non è in quella lista, e saremmo comunque pessimi a farlo. L'hardening gestito esiste come componente aggiuntivo se vuoi che la baseline sia mantenuta da qualcun altro.
Per otto delle dodici, sì, e la R-4 è quella su cui sono state scritte diverse. I build Postgres, inferenza, seedbox e Proxmox richiedono la linea indicata nella tabella sopra; il resto è comodo su quattro core dedicati e 16 GB.
Scegli una città, deploy, segui.
L'istanza di cui hai bisogno per la maggior parte di queste costa meno del caffè che berrai mentre la costruisci. Paga in coin, aspetta circa quarantasette secondi e inizia dal primo passaggio.