Un server che gira da mesi accumula sporcizia: download di pacchetti che non servono più, vecchie immagini del kernel in /boot, container Docker arrestati, cache di build, file di log ruotati, aggiornamenti di sicurezza in attesa di essere applicati e servizi che, lentamente, perdono memoria. Presi singolarmente non sono problemi gravi, ma si sommano finché il disco si riempie, un aggiornamento fallisce o un sito diventa più lento del dovuto.
Fai pulizia su questo server è un solo pulsante che sistema tutto in un unico passaggio — e una conversazione in chat che conferma qualsiasi operazione rischiosa prima di eseguirla.
Cosa fa davvero
Tre categorie, ciascuna eseguibile in modo indipendente: seleziona ciò che vuoi e lascia il resto:
- Libera spazio su disco — svuota la cache dei download dei pacchetti, rimuove le dipendenze dei pacchetti rimossi, elimina container Docker arrestati e immagini non più referenziate, riduce la cache di build Docker più vecchia di una settimana, limita i log systemd agli ultimi 30 giorni, elimina i file di log ruotati (
.gz/.1/.old) più vecchi di 30 giorni e, facoltativamente, rimuove vecchie immagini del kernel / revisioni snap disabilitate. - Installa gli aggiornamenti di sicurezza — aggiorna l'elenco dei pacchetti e installa la versione più recente di ogni pacchetto installato (
apt update+apt upgrade). Se l'aggiornamento include un nuovo kernel, diventa un'azione successiva del tipo "riavvia quando ti è comodo", non qualcosa che succede da sola. - Riavvia i servizi che perdono memoria — facoltativo. Riavvia siti web, database e worker uno alla volta (~10–30s di inattività ciascuno), così la memoria accumulata lentamente nel corso delle settimane viene azzerata. Misuriamo il tempo di risposta prima e dopo e diciamo "più veloce" solo se ci sono prove reali.
In più, vengono sempre eseguiti alcuni controlli in sola lettura: report sui punti che occupano più disco (quali directory stanno consumando spazio), servizi non riusciti (tutto ciò che systemd ha segnalato), accessi SSH recenti (così noti quelli che non riconosci), stato di Fail2ban e verifica di /var/run/reboot-required (il file che l'aggiornamento del kernel crea per segnalare "devi riavviare").
Come avviarla
Quattro punti di ingresso, stessa finestra modale:
| Dove ti trovi | Come |
|---|---|
| Vuoi partire da zero | Digita /cleanup nel compositore della chat e premi Invio |
| Stai sfogliando le ricette | Apri la , trova Fai pulizia su questo server, clicca |
| Il disco inizia a preoccuparti | Apri Dettagli server → scheda Storage → scheda CTA Fai pulizia su questo server in alto |
| Vedi "N aggiornamenti disponibili" nella scheda Aggiornamenti | Dettagli server → scheda Aggiornamenti → scheda CTA Installa questi aggiornamenti con una pulizia completa |
La CTA nella scheda Storage è il percorso più comune: hai notato che il disco si sta riempiendo, sei andato a controllare lo spazio e il pulsante per la pulizia è lì.
La finestra modale preliminare
Facendo clic su uno qualunque dei punti di ingresso si apre la stessa checklist. La finestra modale fa due cose insieme: ti mostra esattamente cosa sta per succedere e autorizza i passaggi sicuri, così la chat non ti fa perdere tempo chiedendoti di nuovo conferme per cose che hai già selezionato.
Leggi i pallini: sono loro a dirti cosa aspettarti:
- Salvia (sicuro) — viene eseguito subito. Nessuna richiesta in chat, nessuna conferma: solo una riga di stato "fatto" alla fine.
- Pesca (conferma in chat) — si ferma e chiede un sì/no nella conversazione prima di procedere. Usato per operazioni come installare aggiornamenti che potrebbero riavviare servizi.
- Rosa (conferma per elemento) — elenca ogni candidato (per esempio ogni volume Docker orfano) e chiede conferma uno per uno. È il livello "sei davvero sicuro di questo elemento specifico?".
Ogni riga ha anche un'apertura "Cosa fa?" con il comando shell esatto che eseguiremo, così gli utenti tecnici possono verificare che non ci siano sorprese. Gli utenti non tecnici possono ignorarla.
L'interruttore Riavvia i workload dopo la pulizia in fondo alla finestra modale è una decisione separata. Riavvia ogni sito web / database / worker in esecuzione uno alla volta, con ~10–30 secondi di inattività ciascuno, misura il tempo di risposta prima e dopo e ti mostra la differenza. Lascialo disattivato se un'interruzione adesso è peggio di un po' di memoria persa; attivalo se stai già facendo manutenzione.
Le tue selezioni vengono ricordate per server: la prossima volta che apri la finestra modale sullo stesso server, le stesse caselle saranno già selezionate. Le nuove azioni aggiunte da aggiornamenti futuri compariranno automaticamente come selezionate per impostazione predefinita se sono sicure (e non selezionate per il resto).
Cosa succede durante l'esecuzione
Fai clic su Avvia pulizia e la finestra modale si chiude. Da qui in poi guida la conversazione:
- Snapshot — un batch rapido di comandi in sola lettura acquisisce la situazione "prima" (spazio libero su disco, RAM, dimensione dei log, aggiornamenti in sospeso, servizi non riusciti, directory più grandi, accessi recenti, Fail2ban). La chat dice solo "Snapshot eseguito, X GB liberi, N aggiornamenti in sospeso. Avvio pulizia…" — non vedi un muro di output grezzo.
- I passaggi sicuri partono automaticamente.
apt update,apt clean,journalctl --vacuum,docker system prune, l'eliminazione dei log ruotati: vengono eseguiti in silenzio, ciascuno con una riga di stato. Nessuna richiesta di approvazione (li hai autorizzati nella finestra modale). - I passaggi da trattare con cautela chiedono conferma. Tutto ciò che ha il pallino pesca (
apt upgrade,docker system prune -a, rimozione del kernel, revisioni snap) mostra una domanda di una riga in chat prima di procedere. Dici sì, l'azione parte; dici no, viene saltata e si passa all'azione successiva: la ricetta non si ferma per un singolo rifiuto.
- I passaggi per elemento chiedono una volta per ogni candidato. Se hai selezionato la rimozione dei volumi orfani, Faro elenca ogni volume non referenziato e chiede conferma uno alla volta, includendo un indizio sull'immagine che lo montava in precedenza. "No a tutto" / "stop" / "salta il resto" interrompe gli elementi rimanenti.
- Riavvii facoltativi dei workload. Se hai attivato l'interruttore, ogni sito/database in esecuzione viene riavviato con campioni del tempo di risposta prima e dopo.
Se in qualunque momento il kernel viene aggiornato e serve un riavvio per usare davvero il nuovo kernel, la ricetta non riavvia automaticamente. Mostra una scheda di follow-up su cui puoi intervenire più tardi.
Quando avviene un riavvio
Qualsiasi cosa faccia cadere la connessione SSH — systemctl reboot, riavvio di sshd / dbus / networking — attiva un banner ambra fisso in alto nella chat. La chat si ferma da sola con un messaggio sintetico "Riavvio avviato. La chat resterà silenziosa per ~30–60s…"; mentre il banner è visibile, l'invio è disabilitato.
Dietro le quinte, una sonda ritenta SSH ogni paio di secondi usando le credenziali che Server Manager ha memorizzato quando ti sei connesso. Quando il server risponde, il banner diventa verde ("Il server è tornato · uptime 8s · ripresa del monitoraggio"), scompare automaticamente dopo 5 secondi e il compositore viene riattivato. Non serve aggiornare il browser.
Il riepilogo e "Cosa devi fare"
Quando l'esecuzione termina, Faro pubblica un messaggio finale con i risultati quantificati subito all'inizio e una tabella delle metriche cambiate.
La tabella include solo le righe in cui l'azione sottostante è stata davvero eseguita E la variazione è diversa da zero: quindi, se hai saltato Docker, non avrai una riga Docker. La colonna "Perché conta" usa linguaggio naturale ("Spazio per database e upload", "Vulnerabilità corrette", "Meno competizione per la CPU"), non gergo.
Se un riavvio di workload ha prodotto un miglioramento misurabile, vedrai anche una tabella Tempo di risposta dei workload per singolo workload — e solo in quel caso. La ricetta non dirà "il tuo sito è più veloce" basandosi sul rumore.
Schede di azione successive
Tutto ciò che la pulizia non è riuscita a completare da sola — un riavvio in sospeso, servizi che usano ancora codice di librerie obsolete, workload che hai scelto di non riavviare, volumi orfani a cui hai detto no — viene mostrato in una sezione Cosa devi fare con schede numerate. Ogni scheda offre due modi per gestirlo:
- Opzione A — chiedimelo qui — un percorso in chat con un clic. Il testo di risposta del callout appare come chip cliccabile sopra il compositore, così non devi scorrere di nuovo verso l'alto.
- Opzione B — tramite la console del tuo provider — passaggi clic per clic specifici del provider per fare la stessa cosa (per esempio "DigitalOcean → Droplet → Power → Reboot"). Utile se preferisci farlo tu in modo deliberato.
- Compromesso — una frase per scheda che spiega quando ha più senso scegliere un percorso o l'altro.
La barra di chip fissata sopra il compositore rispecchia queste schede come follow-up ☐ in sospeso. Fai clic su un chip → il relativo testo di risposta riempie il compositore → premi Invia. Mentre Faro ci lavora, il chip diventa ⏳ in corso; quando ha finito, diventa ✓ barrato e scompare automaticamente dopo 5 secondi. Ogni chip ha anche un piccolo pulsante × per nasconderlo se hai deciso di ignorare quel follow-up: la scelta resta valida per il resto della sessione del browser.
Casi limite comuni
"Nessun volume orfano trovato" — l'azione per elemento lo segnala e passa oltre. Non è un errore: l'elenco era vuoto.
Reboot-required era già impostato prima della pulizia — succede spesso quando qualcun altro (o un'esecuzione precedente) ha installato aggiornamenti senza ancora riavviare. La ricetta controlla /var/run/reboot-required sia al momento dello snapshot sia dopo apt upgrade. Se era già presente, la scheda di follow-up "Riavvia il server" appare anche quando questa pulizia non ha installato nulla di nuovo: resta comunque l'azione corretta.
I miei siti sono dietro Traefik / nginx / Apache — la ricetta non tocca la configurazione del tuo web server. Riavvia i container sottostanti (o le unità systemd) per i siti che riesce a identificare dall'inventario; il proxy continua a funzionare normalmente. Se il reverse proxy di un workload è davanti a container che Server Manager non conosce (una configurazione personalizzata non gestita), viene saltato in silenzio: senza URL di probe non c'è un riavvio misurabile.
Snap non è installato su questo server — il passaggio "Rimuovi revisioni snap disabilitate" dice semplicemente "Snap non è installato — salto." e continua. Selezionarlo su un server senza snap è innocuo.
**apt autoremove rimuoverebbe qualcosa che voglio tenere** — ogni passaggio autoremove è preceduto da una prova a secco che stampa "Would remove: pkg-a, pkg-b, …". Se l'elenco ti sembra sbagliato, dì no: l'esecuzione reale avviene solo dopo la tua conferma.
Ho detto sì a un passaggio e voglio tirarmi indietro a metà — premendo Esc l'agente si ferma. I comandi già in esecuzione non vengono interrotti (arrivano alla fine), ma il ciclo esce. Puoi chiedere a Faro di riprendere più tardi ciò che è stato saltato.
La chat sembra bloccata durante il riavvio di un servizio — qualsiasi operazione che riavvia sshd, dbus o lo stack di rete attiva lo stesso banner del riavvio (variante a orizzonte breve). Se vedi il banner, la chat è in pausa intenzionalmente; se non compare e la chat sembra davvero congelata, consulta Ripristinare quando SSH smette di funzionare.
Il report finale: cosa guardare
Il messaggio di riepilogo ha una struttura volutamente coerente, così puoi leggerlo a colpo d'occhio:
- Titolo — una riga in grassetto: "🧹 Liberati 6,2 GB e applicati 14 aggiornamenti di sicurezza." Questo è il risultato. Il numero che non è cambiato non viene citato.
- Spiegazione in una riga — il miglioramento specifico più importante in linguaggio naturale (più spazio liberato, sicurezza aggiornata, meno servizi in errore: quello che ha pesato di più).
- Tabella "Cosa è cambiato" — Prima / Dopo / Variazione / Perché conta, una riga per ogni metrica che è davvero cambiata. Righe possibili: spazio libero su disco (GB e %), inode liberi (%), uso disco Docker, dimensione dei log di sistema, aggiornamenti di sicurezza in sospeso, servizi non riusciti, memoria disponibile, carico in background.
- Tabella "Tempo di risposta dei workload" (solo se hai scelto i riavvii E c'è stato un miglioramento misurabile) — prima / dopo / variazione per workload.
- Sezione "Cosa devi fare" (solo se ci sono follow-up) — le schede numerate descritte sopra.
- Footer "Saltati: …" (solo se hai rifiutato dei passaggi) — l'elenco delle etichette delle azioni, così puoi rieseguire più tardi e rivederle.
Se il server era già in ordine e non c'era nulla da fare, Faro chiude con "Il tuo server è già in ordine. Non c'è nulla da fare." — niente tabella di riepilogo inventata, niente report allungato artificialmente.
Riferimento
Cosa viene pre-autorizzato e cosa chiede ancora conferma
| Livello | Esempi | Comportamento |
|---|---|---|
| Sicuro | apt update, apt clean, docker system prune -f, journalctl --vacuum-time=30d, find /var/log … -delete | Pre-autorizzato dalle selezioni nella finestra modale — esecuzione automatica, stato in una riga |
| Cautela | apt upgrade, docker system prune -a, rimozione del kernel, rimozione di revisioni snap | Si ferma e chiede sì/no in chat |
| Per elemento | Rimozione di volumi orfani | Chiede uno per uno; "stop"/"salta il resto" interrompe gli elementi rimanenti |
| Controlli di salute in sola lettura | df, free, last, fail2ban-client status, punti di maggiore occupazione del disco | Vengono sempre eseguiti (indipendentemente dalle selezioni) |
Salvataggio delle tue selezioni — la tua selezione (e l'interruttore per il riavvio dei workload) viene salvata nel localStorage del browser, indicizzata per hostname del server. Cancellare i dati del browser riporta le selezioni ai valori predefiniti.
Come funzionano follow-up e bypass del riavvio — quando la ricetta di pulizia è attiva, gli script di snapshot in sola lettura della ricetta e tutti i comandi del livello sicuro che hai selezionato nella finestra modale bypassano il classificatore dei comandi distruttivi: è così che si evitano le richieste duplicate "Approva questo comando?". I livelli cautela e per elemento chiedono sempre di nuovo. Il bypass è consapevole del contenuto (ogni segmento di comando viene validato rispetto a una allow-list in sola lettura) e pattern vietati come rm -rf / vengono sempre bloccati, senza eccezioni.