Let's look at how to highlight this beautiful historic bank building amidst the busy urban scene on Royal Boulevard:
https://avidandrew.com/bank-royal.html

#photography #tutorial #darktable #opensource #foss #canon #camera #linux #software #freesoftware #travel #travelphotography

Il problema non è più “quando” applicare le patch, ma “quanto” siamo espostiPer anni la gestione delle #patch nelle infrastrutture IT ha seguito una logica prudente: rilasciare l’aggiornamento, aspettare qualche giorno o settimana per verificare che non rompa nulla in produzione, poi distribuirlo in ondate controllate. Questo modello, ragionevole quando gli attaccanti impiegavano settimane a sviluppare un exploit funzionante, sta diventando insostenibile di fronte a una realtà cambiata radicalmente: gli attori malevoli usano oggi strumenti di intelligenza artificiale per identificare e sfruttare le vulnerabilità in tempi drasticamente più brevi rispetto ai cicli di patching tradizionali.

Il punto non è più teorico. Il volume di vulnerabilità pubblicate mensilmente ha raggiunto livelli che nessun team può gestire con processi manuali: nel Patch Tuesday di giugno 2026 Microsoft ha corretto 208 vulnerabilità, salite a 621 in luglio, di cui 63 classificate come critiche e almeno 2 già sfruttate attivamente al momento del rilascio. Nessun tecnico può ragionevolmente assorbire quel volume come uno dei tanti task settimanali, e infatti le linee guida Microsoft più recenti raccomandano finestre di differimento inferiori a tre giorni per gli aggiornamenti qualitativi, con deadline di installazione a zero o un giorno e non più di due giorni di margine.

Da “patch dei computer” a “gestione del ciclo di vita di tutto ciò che è connesso”Il cambio di paradigma proposto non è semplicemente “patchare più in fretta”, ma ripensare cosa significhi effettivamente gestire il rischio di un parco IT. Il modello classico, incentrato sull’endpoint patching, lascia scoperta una superficie di attacco enorme e in crescita: stampanti di rete, telecamere IP, sistemi HVAC, telefoni VoIP, PLC industriali. Sono tutti dispositivi connessi alla rete aziendale, spesso raggiungibili da #Internet, quasi mai coperti dai sistemi di patch management tradizionali e, in molti casi, privi di un meccanismo di aggiornamento comodo o di supporto attivo del vendor.

Il risultato è una classe intera di apparati “connessi, esposti e ignorati” — per usare la formula più efficace del problema — che rappresentano oggi un vettore di compromissione tanto concreto quanto un server #Windows non aggiornato, ma con una probabilità molto più bassa di rientrare in un audit di sicurezza periodico.

Un caso reale: PLC industriali sotto attaccoNon è uno scenario ipotetico. Nel corso del 2026 un avviso del governo statunitense ha documentato attori legati all’Iran nell’atto di sfruttare controllori logici programmabili (PLC) esposti direttamente su Internet in infrastrutture critiche di settori governativo, idrico, delle acque reflue ed energetico. Gli attaccanti hanno manipolato i file di progetto dei PLC e alterato le visualizzazioni SCADA, causando interruzioni operative e perdite economiche dirette.

Le raccomandazioni pubblicate da CISA in seguito a questi incidenti non riguardavano tecniche sofisticate di difesa, ma fondamentali di sicurezza rimasti clamorosamente disattesi: rimuovere l’esposizione diretta a Internet dei dispositivi, cambiare le credenziali di default, usare #password complesse, applicare le patch fornite dai vendor quando disponibili. È la controprova di quanto il problema non sia (solo) tecnologico, ma di processo e visibilità.

Cosa cambia in pratica per un team infrastrutturaleTradurre questo cambio di prospettiva in azioni concrete significa lavorare su più fronti contemporaneamente, senza aspettare che sia un incidente a imporre le priorità.

1. Automazione del patching Windows guidata da policyIl primo passo è tecnicamente il più semplice: abbandonare il rollout scaglionato basato solo sulla prudenza a favore di processi automatizzati e guidati da policy documentate, con eccezioni esplicite e motivate anziché ritardi impliciti “per abitudine”. Strumenti come Windows Update for Business, #Intune o WSUS permettono già oggi di configurare deadline aggressive con anelli di sicurezza (rollback automatico, Known Issue Rollback) per i casi in cui un aggiornamento causi regressioni.

2. Inventario di tutto ciò che è connesso, non solo degli endpoint gestitiServe un censimento che vada oltre l’inventario classico di Active Directory o dell’MDM: switch, access point, stampanti di rete, telecamere, sistemi di building automation, dispositivi OT. Molti di questi asset sono scoperti solo tramite scansione attiva della rete o strumenti di asset discovery dedicati, perché non compaiono mai in un dominio Windows.

3. Segmentazione di rete per i sistemi non aggiornabiliPer i dispositivi privi di un percorso di patching realistico — firmware non più supportato, hardware embedded, sistemi legacy critici che non possono essere sostituiti a breve — la mitigazione primaria diventa il contenimento: segmentazione di rete dedicata, accesso solo tramite gateway controllati, credenziali univoche e non condivise, monitoraggio del traffico in ingresso/uscita da quei segmenti.

4. Pianificazione della sostituzione, non solo della protezionePer gli apparati che restano permanentemente non aggiornabili, la sola segmentazione è un palliativo, non una soluzione. Va costruito un piano di sostituzione con priorità basata su esposizione e criticità, invece di lasciare che questi dispositivi restino operativi a tempo indeterminato “perché funzionano ancora”.

Il messaggio di fondo per chi gestisce infrastrutture nel 2026La sintesi più utile di questo cambiamento è che la vecchia domanda — “possiamo aspettare qualche giorno prima di installare questa patch?” — va sostituita da una diversa: “quanto tempo restiamo esposti se aspettiamo, e chi altro nella rete è esposto insieme a noi anche se non lo stiamo patchando direttamente?”. In un contesto in cui gli attaccanti automatizzano la ricognizione e lo sfruttamento delle vulnerabilità con strumenti AI, il differimento smette di essere una misura prudente di default e diventa esso stesso un rischio da giustificare, caso per caso, con un’eccezione documentata.

Per i team più piccoli, senza le risorse di un SOC dedicato, il punto di partenza realistico resta comunque il più efficace: un inventario onesto di tutto ciò che è connesso alla rete, anche (soprattutto) ciò che nessuno ha mai pensato di considerare un “endpoint” da patchare.

Fonte: 4sysops – The patch window is collapsing: why security needs a new control plane e Petri IT Knowledgebase – The Patch Window Is Collapsing. Your Service Model Has to Change, di Amy Babinchak.

Il sintomo che inganna: load average alto, CPU quasi fermaCapita spesso a chi gestisce server #Linux in produzione: il monitoraggio segnala un load average sopra 30 su una macchina con 24 core, gli utenti si lamentano di risposte lente, ma top mostra la #CPU idle al 70%. Il riflesso istintivo è cercare il processo che “mangia CPU”, ma qui il colpevole non c’è da nessuna parte nella lista dei consumi di calcolo: il collo di bottiglia è l’I/O su disco, e la differenza tra i due scenari cambia completamente la strategia di intervento.

Il load average di Linux non misura solo i processi che vogliono la CPU: conta anche quelli bloccati in stato D (uninterruptible sleep), cioè in attesa che il #kernel completi un’operazione di I/O. Un load di 30 con CPU libera significa quasi sempre che decine di thread sono in coda per il disco, non per il processore. Diagnosticare questo scenario richiede un metodo diverso da quello usato per un semplice sovraccarico di calcolo, e la differenza si vede negli strumenti da usare e nell’ordine in cui usarli.

Il metro di misura: I/O wait e perché da solo non bastaL’I/O wait (colonna wa in top) è la percentuale di tempo in cui la CPU è rimasta inattiva pur avendo almeno una richiesta di I/O ancora in sospeso. È un indicatore utile ma ingannevole: se il sistema ha altro lavoro da eseguire mentre il disco è lento, la CPU si tiene occupata e il valore di wa scende, anche se lo storage sottostante continua a rispondere altrettanto male. Per questo motivo l’I/O wait va sempre incrociato con metriche a livello di dispositivo, non usato come unico segnale.

Il flusso diagnostico corretto segue quattro passaggi in sequenza:

Controllare load average e colonna wa in top (premendo 1 per espandere le statistiche per singolo core)

Confermare il sospetto a livello di dispositivo con iostat -xz 1 o /proc/pressure/io

Solo a questo punto, andare a caccia dei processi responsabili con atop e iotop

Misurare in modo oggettivo con un benchmark reale (dd o fio), perché un numero concreto chiude ogni discussione

Passo 1 — Individuare i processi bloccatiPrima di aprire strumenti dedicati, un controllo rapido dei processi in stato “uninterruptible sleep” dà già un’indicazione:

ps -eo state,pid,comm | grep "^D"Se questo comando restituisce più righe, ripetutamente, su un sistema che dovrebbe essere reattivo, l’ipotesi I/O-bound si rafforza. Il passo successivo è capire quanto è grave la situazione a livello di dispositivo di blocco.

Passo 2 — iostat: la vista a livello di dispositivoiostat -xz 1I flag hanno un significato preciso:

-x: statistiche estese, incluse le latenze medie di lettura e scrittura

-z: nasconde i dispositivi inattivi, per non affollare l’output con righe a zero

1: intervallo di refresh in secondi

Le colonne da guardare con attenzione sono r_await e w_await, che esprimono in millisecondi il tempo medio di attesa per operazione di lettura e scrittura: su storage sano questi valori restano a una cifra; valori a due o tre cifre indicano un disco sotto stress severo. La colonna %util va invece presa con cautela sui dispositivi SSD/NVMe, dove può risultare fuorviante a causa del parallelismo interno dei controller moderni, che gestiscono più richieste contemporaneamente senza che questo si traduca in saturazione reale.

Un dettaglio pratico spesso ignorato: il primo report stampato da iostat va scartato, perché media tutte le statistiche dall’avvio del sistema e può “truccare” in positivo un disco che in realtà ha iniziato a comportarsi male solo poche ore prima.

Passo 3 — Pressure Stall Information: la metrica più modernaDai kernel 4.20 in poi è disponibile un meccanismo più sofisticato dell’I/O wait tradizionale: la Pressure Stall Information (PSI), esposta in /proc/pressure/io:

cat /proc/pressure/ioUn output tipico in condizioni di forte stress si presenta così:

some avg10=44.21 avg60=39.07 avg300=31.88 total=8814592211
full avg10=38.90 avg60=35.62 avg300=29.15 total=7913804412La riga some indica la percentuale di tempo in cui almeno un task era bloccato in attesa di I/O; la riga full indica la percentuale di tempo in cui tutti i task non idle erano bloccati contemporaneamente — un segnale molto più grave, perché significa che l’intero sistema è fermo in attesa dello storage. Su alcune distribuzioni PSI richiede il parametro di avvio del kernel psi=1 per essere attivo; vale la pena verificarlo prima di fare affidamento su questi dati in produzione.

Passo 4 — Trovare il colpevole con atop e iotopUna volta confermato che il collo di bottiglia è reale a livello di dispositivo, resta da capire quale processo lo sta generando.

atop mostra le statistiche di I/O per disco direttamente nella vista principale; premendo d durante l’esecuzione si passa alla vista dedicata ai processi che stanno consumando I/O. È utile anche per individuare thread kernel come flush-8:0 (il thread di writeback che scarica su disco le pagine sporche dalla cache) o jbd2/sda5-8 (il journaling di ext4), che spesso vengono scambiati per processi “misteriosi” da chi non li conosce.

iotop offre una vista più mirata:

iotop -oPa-o (--only): mostra solo i processi che stanno effettivamente generando I/O in quel momento

-P (--processes): aggrega per processo invece di elencare ogni singolo thread

-a (--accumulated): mostra il totale di I/O accumulato dall’avvio dello strumento, utile per individuare pattern intermittenti

Un requisito spesso trascurato: dal kernel 5.14 il delay accounting è disabilitato di default, e senza di esso iotop non riesce a calcolare correttamente le statistiche per processo. Va abilitato con:

sudo sysctl kernel.task_delayacct=1Per renderlo persistente ai riavvi è necessario aggiungere delayacct ai parametri di boot del kernel (tramite GRUB), oltre a impostare il sysctl in /etc/sysctl.d/.

Chiudere la discussione con un numero: dd e fioQuando la diagnosi è fatta, spesso serve convincere qualcun altro (un cliente, un team infrastrutturale, un fornitore di storage) che il problema è reale. Un test rapido e riproducibile con dd:

dd if=/dev/zero of=diskbench bs=1M count=1024 conv=fdatasyncIl flag conv=fdatasync è essenziale: forza la sincronizzazione dei dati su disco prima che dd riporti il tempo trascorso, altrimenti si misurerebbe solo la velocità della cache di scrittura del kernel. Un risultato come “1073741824 bytes (1.1 GB) copiati, 46.0156 s, 23.3 MB/s” su uno storage che dovrebbe erogare centinaia di MB/s parla da solo, ed è molto più difficile da contestare di un’opinione: un host può discutere con la vostra opinione, molto più difficilmente lo farà con 23,3 MB/s misurati.

Per un quadro più completo, che tenga conto anche di IOPS e latenza sotto carico concorrente (lo scenario tipico di un database o di un server #web sotto traffico reale), lo strumento di riferimento è fio, che permette di simulare pattern di accesso realistici con più job paralleli, dimensioni di blocco configurabili e miscele di letture/scritture.

Il caso reale: quando il disco lento innesca un effetto dominoUn caso concreto che vale la pena analizzare riguarda un server con un’istanza MySQL configurata con max_connections=2000, un valore decisamente eccessivo per l’hardware disponibile. Ogni connessione MySQL alloca buffer per-thread; moltiplicando la memoria per singolo thread per il numero massimo di connessioni e sommando i buffer globali, il calcolo della memoria potenzialmente necessaria superava ampiamente la RAM installata.

Finché il traffico restava basso, il problema non si manifestava. Ma con un disco già lento (a causa di I/O wait elevato) e un picco di connessioni concorrenti, le richieste si sono accumulate in coda, la pressione di memoria è salita rapidamente, e l’OOM killer del kernel è intervenuto terminando processi critici. Un problema di storage, in altre parole, si è propagato fino a diventare un incidente di memoria e disponibilità.

Buone pratiche per prevenire il problemaAlcune misure pratiche riducono sensibilmente il rischio di trovarsi in questa situazione:

Ridurre la frequenza di scrittura dei log di #Nginx/Apache in scenari ad alto traffico, dove i log di accesso possono generare un volume di I/O sorprendentemente alto

Spostare la cache in memoria (ad esempio su tmpfs) invece che su disco durante i picchi di concorrenza, per eliminare completamente la latenza di storage dal percorso critico

Dimensionare correttamente pm.max_children in #PHP-FPM: un valore troppo basso rifiuta traffico legittimo, uno troppo alto amplifica la pressione su disco e memoria nello stesso momento

Valutare l’hardware: il salto da storage a rotazione a SSD, e da SSD a NVMe, cambia le soglie di r_await/w_await di un ordine di grandezza

Introdurre un livello di #caching come Varnish davanti all’applicazione, una volta che la cache è “primed” e può assorbire la maggior parte delle richieste senza toccare il backend

ConclusioneUn load average alto con CPU libera non è un paradosso: è un sintomo preciso che indica dove guardare. Il metodo — top per una prima ipotesi, iostat e PSI per confermarla a livello di dispositivo, atop/iotop per individuare il processo responsabile, e un benchmark con dd o fio per quantificare il problema in modo indiscutibile — si applica a qualunque stack, dai database ai server web, ed evita di perdere tempo a ottimizzare la CPU quando il vero collo di bottiglia sta girando a 23 MB/s su un disco che dovrebbe farne dieci volte tanto.

Fonte originale: Linux server performance: Is disk I/O slowing your application? – LinuxBlog.io

Perché il TLS handshake è ancora il vostro nemico nascosto del TTFBIl 95% del traffico #web oggi viaggia su HTTPS, ma la maggior parte delle configurazioni #Nginx in produzione #usa ancora i parametri di default che erano ragionevoli cinque anni fa e oggi lasciano sul tavolo decine di millisecondi di Time To First Byte. La buona notizia è che si tratta quasi sempre di ottimizzazioni “una tantum”: si toccano poche direttive, si ricarica Nginx e il guadagno resta lì, per ogni richiesta, per sempre.

In questo articolo vediamo come intervenire su cache di sessione, cifrari, buffer TLS, HTTP/3 e header di sicurezza, con un occhio a cosa è cambiato di recente (OCSP stapling è ormai carta straccia con Let’s Encrypt, HTTP/3 con 0-RTT richiede #OpenSSL aggiornato) e cosa invece continua a essere un mito da sfatare.

Il conto salato dell’handshake TLS ripetutoOgni nuova connessione TLS 1.2 costa un round trip aggiuntivo rispetto a una connessione già “nota” al server; TLS 1.3 lo riduce a un solo round trip nel caso normale, e a zero con il resumption. Il problema è che di default la session cache di Nginx è minuscola e la sua durata troppo breve per traffico reale distribuito su più server.

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets on;
Un dettaglio che quasi nessuno controlla: 1 MB di cache condivisa contiene circa 4.000 sessioni. Con 10m si arrivano a 40.000 sessioni attive, un valore ragionevole per un sito di media grandezza ma da ricalcolare se avete decine di migliaia di client concorrenti (osservate ssl_session_cache statistiche via nginx -V con modulo stub_status compilato, oppure strumentate a livello di access log).

Se gestite un parco di più server dietro un load balancer, i session ticket devono usare la stessa chiave su tutte le istanze, altrimenti ogni volta che il bilanciatore sposta il client su un nodo diverso l’handshake riparte da zero, vanificando il resumption. La chiave va generata una volta e distribuita in modo sicuro (es. tramite un secret manager), non rigenerata ad ogni deploy.

Cifrari: meno scelta, meno lavoro per la CPUSu TLS 1.3 il set di cifrari è già ristretto e sicuro per design, ma su TLS 1.2 — che va ancora mantenuto attivo per compatibilità con client legacy su siti pubblici — vale la pena essere espliciti ed escludere tutto ciò che non è AEAD (GCM o ChaCha20-Poly1305):

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
Nota sul ssl_prefer_server_ciphers off: con TLS 1.3 e client moderni è il client a scegliere in modo sensato, quindi forzare l’ordine lato server (utile in epoca TLS 1.0/1.1 per evitare cifrari deboli) oggi aggiunge solo complessità. Se avete ancora bisogno di forzare l’ordine per policy di #compliance, impostatelo su on e mantenete la lista sopra come riferimento.

Per non reinventare la ruota ogni volta, usate il generatore di configurazione SSL di Mozilla, che tiene aggiornati i profili “modern”, “intermediate” e “old” in base alle #CVE e al supporto #browser corrente.

Il buffer TLS che nessuno ridimensionaUna delle ottimizzazioni meno note e più efficaci riguarda ssl_buffer_size. Di default Nginx usa un buffer da 16 KB per i record TLS, pensato per massimizzare il throughput su file di grandi dimensioni. Per pagine HTML, API JSON e asset piccoli — cioè la stragrande maggioranza del traffico applicativo — questo significa che il client deve attendere di ricevere l’intero buffer prima di poter iniziare a renderizzare qualsiasi cosa.

ssl_buffer_size 4k;
Riducendo il buffer a 4 KB il primo record TLS utile arriva prima, con un impatto misurabile sul TTFB percepito (tipicamente nell’ordine di 30-50ms su connessioni con latenza medio-alta). Il compromesso è un overhead leggermente maggiore per trasferimenti di grandi file per via del maggior numero di record; per questo motivo, se servite prevalentemente download di file di grandi dimensioni da un host dedicato, vale la pena valutare un buffer intermedio (es. 8k) o configurazioni separate per server block diversi.

OCSP stapling: una direttiva ormai innocuaPer anni la configurazione “corretta” includeva l’OCSP stapling per evitare che il browser dovesse contattare l’authority per verificare la revoca del certificato:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /path/to/full_chain.pem;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
Se usate Let’s Encrypt, sappiate che questa configurazione oggi non fa più nulla: dal 6 agosto 2025 Let’s Encrypt ha terminato il supporto agli endpoint OCSP, spostandosi esclusivamente su Certificate Revocation List (CRL) a corto raggio. Non è un errore lasciare le direttive nella configurazione (sono semplicemente inerti), ma se il vostro certificato proviene da un’altra CA verificate lo stato del suo servizio OCSP prima di considerarle superflue.

HTTP/3 e QUIC: attenzione al firewall, non solo a NginxHTTP/3 è disponibile in mainline Nginx dalla versione 1.25.0 e nei pacchetti binari ufficiali di nginx.org; l’adozione globale è ancora intorno al 21% contro il 50%+ di HTTP/2, ma per applicazioni con utenti su reti mobili o ad alta latenza il guadagno di QUIC (0-RTT, niente head-of-line blocking a livello di trasporto) è reale.

listen 443 ssl;
listen 443 quic reuseport;
http2 on;
add_header Alt-Svc 'h3=":443"; ma=86400';
Due avvertenze pratiche, spesso trascurate:

reuseport deve comparire su una sola direttiva listen, altrimenti Nginx non parte o bilancia male tra i worker.

QUIC viaggia su UDP: se la porta 443/UDP non è aperta sul firewall, il fallimento è silenzioso. Il browser prova QUIC, non riceve risposta e ricade automaticamente su HTTP/2 senza loggare alcun errore visibile lato client. Verificate esplicitamente con ufw allow 443/udp (o l’equivalente per il vostro firewall) e controllate con curl --http3 o la colonna “Protocol” di #Chrome DevTools.

Per il 0-RTT (early data) su QUIC serve OpenSSL 3.5.1 o successivo: con versioni precedenti HTTP/3 funziona comunque, semplicemente senza questa ottimizzazione aggiuntiva sul primo round trip.

Header di sicurezza che costano zero millisecondiNon influenzano il TTFB ma sono ormai lo standard minimo per qualunque endpoint HTTPS in produzione:

add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
add_header X-Frame-Options sameorigin;
add_header X-Content-Type-Options nosniff;
Da notare: X-XSS-Protection va rimosso, non aggiunto — i browser moderni lo ignorano e in alcuni casi storici introduceva vulnerabilità XSS reflected invece di prevenirle.

Il limite di questa ottimizzazione: dove il TLS tuning non arrivaVale la pena essere onesti su un punto: il tuning TLS riduce l’overhead del trasporto sicuro, ma non corregge un’applicazione lenta. Se il vostro TTFB è dominato da query database non indicizzate, da un backend PHP-FPM sottodimensionato o dall’assenza di una cache applicativa, i millisecondi guadagnati qui sono nell’ordine del rumore statistico rispetto ai secondi persi altrove. Il tuning TLS va trattato come l’ultimo 10% dell’ottimizzazione, da applicare dopo aver sistemato caching, query e CDN — non come sostituto.

Procedura di verificaDopo ogni modifica, il ciclo è sempre lo stesso:

nginx -t
nginx -s reload
nginx -t valida la sintassi prima del reload, evitando downtime per un errore di battitura in produzione. Per validare l’effetto reale, misurate il TTFB prima e dopo con strumenti come curl -w "%{time_starttransfer}\n" -o /dev/null -s https://vostro-sito.tld ripetuto più volte, oppure con WebPageTest per una view completa lato client reale.

ConclusioneNessuna di queste modifiche richiede un downtime pianificato o un cambio architetturale: sono direttive di configurazione che si testano e si applicano in pochi minuti. Il ritorno, moltiplicato per milioni di richieste al mese, è tutt’altro che trascurabile — ed è uno di quei rari casi in cui “ottimizzazione infrastrutturale” non significa comprare più hardware, ma semplicemente smettere di lasciare Nginx sui default di cinque anni fa.

Fonte originale: Nginx tuning tips: HTTPS/TLS – Turbocharge TTFB/Latency, LinuxBlog.io. Approfondimenti aggiuntivi su HTTP/3 in produzione: Serving HTTP/2 and HTTP/3 with Nginx in 2026.

Se nella vostra organizzazione l’attivazione di #Windows passa ancora da uno script che richiama slmgr.vbs, incorporato in una sequenza di task di System Center Configuration Manager, in un logon script di Active Directory o in un tool RMM, è arrivato il momento di segnarsi una scadenza in agenda. Microsoft ha confermato che il ritiro di VBScript da Windows procede secondo un piano a fasi, e ha rilasciato in parallelo un modulo #PowerShell ufficiale pensato esplicitamente per sostituire l’automazione basata su slmgr.vbs, cscript.exe e wscript.exe.

Non è un’emergenza immediata: VBScript resta disponibile oggi. Ma chi gestisce parchi macchine di centinaia o migliaia di endpoint sa bene che una migrazione di questo tipo, se rimandata all’ultimo, diventa un incendio da spegnere in corsa. Vediamo cosa cambia, quali sono le tempistiche reali e come impostare fin da ora un piano di migrazione ordinato.

Perché VBScript sta per sparireMicrosoft aveva annunciato la deprecazione di VBScript già nel 2023, come parte di una più ampia strategia di riduzione della superficie di attacco: il motore di scripting legacy è stato per anni un vettore privilegiato per #malware e tecniche di living-off-the-land, e la sua rimozione da Windows segue lo stesso percorso già intrapreso per altre componenti storiche del sistema operativo.

Il piano di ritiro si articola in tre fasi:

Fase attuale — VBScript è presente come Feature on Demand e resta abilitato per impostazione predefinita. Tutto continua a funzionare come sempre.

Fase intermedia (indicativamente dal 2027) — il componente rimarrà disponibile ma verrà disabilitato di default: le organizzazioni che ne hanno ancora bisogno dovranno riattivarlo esplicitamente tramite policy o Feature on Demand.

Fase finale — rimozione completa del motore di scripting da Windows. Microsoft non ha ancora comunicato una data precisa per questo passaggio, ma da quel momento slmgr.vbs e qualunque script dipendente da cscript/wscript smetteranno semplicemente di funzionare.

Il punto critico per i sistemisti è proprio la fase intermedia: se l’automazione di attivazione non viene aggiornata prima che VBScript venga disabilitato di default, i processi di provisioning e le immagini di deployment rischiano di rompersi silenziosamente, magari scoperti solo quando un nuovo lotto di macchine non riesce ad attivarsi.

La sostituzione ufficiale: il modulo PowerShell OSLicensePer coprire il vuoto lasciato da slmgr.vbs, Microsoft ha introdotto OSLicense, un modulo PowerShell nativo pensato per replicare — e in parte estendere — le funzioni storiche dello script VBScript. I cmdlet principali sono tre:

Attivazione online (equivalente di slmgr.vbs /ato)

Invoke-OSLicense -ActivateOnline

Installazione di una product key (equivalente di slmgr.vbs /ipk)

Invoke-OSLicense -InstallProductKey "XXXXX-XXXXX-XXXXX-XXXXX-XXXXX"

Verifica dello stato della licenza (equivalente di slmgr.vbs /dlv)

Get-OSLicenseInfoOltre a questi tre comandi base, OSLicense copre scenari enterprise più articolati: attivazione tramite KMS, attivazione basata su Active Directory (AD-based activation) e la gestione della subscription activation per i piani Windows Enterprise E3/E5. In sostanza, chiunque abbia costruito script di provisioning attorno a slmgr.vbs /skms o /ato troverà un cmdlet equivalente pronto all’uso.

Requisiti per usare OSLicense oggiIl modulo non è ancora universalmente disponibile su tutte le versioni di Windows in campo. Al momento richiede:

Windows 11: l’update opzionale KB5120998 (rilasciato il 27 agosto 2026) o successivo;

Windows Server: è disponibile a partire dalla Windows Server vNext Preview build 29651, quindi non ancora nei rami stabili di produzione.

Questo significa che, per buona parte del parco macchine server oggi in produzione, OSLicense non è un’opzione praticabile nel breve termine — un dettaglio da tenere bene a mente quando si pianifica la migrazione.

Un ponte per chi non può ancora usare OSLicensePer gli ambienti in cui Windows Script Host è già stato disabilitato per policy di sicurezza, o dove serve una soluzione utilizzabile subito senza attendere il rollout di OSLicense sui rami server, la community ha già colmato il divario. Il progetto open source slmgr-ps offre un wrapper PowerShell che replica le funzioni più usate di slmgr.vbs, con il vantaggio aggiuntivo del supporto nativo alle operazioni remote:

Informazioni sulla licenza (locale o estesa)

Get-WindowsActivation
Get-WindowsActivation -Extended
Get-WindowsActivation -Expiry

Attivazione con chiave KMS rilevata automaticamente

Start-WindowsActivation -UseKmsClientKey

Attivazione su una macchina remota

Start-WindowsActivation -Computer WS01

Reset delle impostazioni di attivazione

Reset-WindowsActivation -UninstallProductKey
Reset-WindowsActivation -ClearKMSSettingsA differenza dello script VBScript originale, che opera sempre in locale, questi cmdlet accettano array di nomi macchina: è quindi possibile lanciare un audit o una riattivazione su un intero gruppo di endpoint con un’unica riga di PowerShell, invece di iterare manualmente con psexec o sessioni #RDP.

Come impostare la migrazione senza sorpresePrima di riscrivere qualsiasi cosa, il lavoro più importante è capire dove slmgr.vbs è effettivamente referenziato nel proprio ambiente. È un’operazione che conviene affrontare in quattro passaggi:

Censire le dipendenze: cercare riferimenti a slmgr.vbs, cscript.exe e wscript.exe in task sequence MDT/SCCM, script di #Intune, GPO di logon/startup, immagini master e tool RMM di terze parti. Un semplice Select-String ricorsivo sui repository di script è un buon punto di partenza.

Classificare per urgenza: separare gli script che girano su Windows 11 con KB5120998 già installabile da quelli su Windows Server, dove OSLicense non è ancora un’opzione e serve necessariamente un ponte come slmgr-ps o una convivenza temporanea con VBScript.

Validare in un anello di test: prima di sostituire uno script di attivazione in produzione, verificarne il comportamento su un gruppo pilota di macchine, controllando in particolare gli scenari KMS e AD-based activation, storicamente i più delicati da replicare fedelmente.

Documentare e pianificare la disattivazione di VBScript: una volta che tutti gli script critici sono stati migrati, pianificare la disabilitazione esplicita del Feature on Demand VBScript sui gruppi di macchine già pronti, così da anticipare la fase di “disabled by default” invece di subirla.

ConclusioneNon c’è ancora motivo di allarmarsi, ma nemmeno di procrastinare. La finestra utile per pianificare con calma la migrazione dell’automazione di attivazione è oggi, non quando VBScript verrà disabilitato di default sui client aggiornati. Le organizzazioni con un parco Windows 11 già aggiornato possono iniziare da subito con OSLicense; chi gestisce prevalentemente Windows Server dovrà invece appoggiarsi a soluzioni ponte come slmgr-ps fino a quando il modulo ufficiale non arriverà nei rami stabili. In entrambi i casi, il primo passo resta lo stesso: sapere esattamente quanti script nel proprio ambiente dipendono ancora da un motore che, prima o poi, non ci sarà più.

Fonte: Petri.com – Windows Activation Automation Must Move Beyond VBScript, con approfondimenti dal Windows IT Pro Blog di Microsoft.

Per anni lo sviluppo di applicazioni desktop native su #Windows è stato percepito come un percorso lento: XAML da scrivere a mano, documentazione sparsa tra WPF, UWP e WinUI, e agenti AI generalisti che, interrogati su “come si fa in WinUI 3”, rispondono spesso con pattern deprecati presi da esempi UWP o WPF più vecchi e più numerosi nei dati di addestramento. Microsoft ha da poco pubblicato un flusso di lavoro end-to-end — VS Code, .NET 10 e un agente #Copilot specializzato — che promette di ridurre il percorso da “cartella vuota” ad app WinUI 3 pubblicabile a circa 30 minuti. Vale la pena capire cosa c’è davvero dietro, perché la parte interessante non è la demo, ma il modo in cui l’agente viene reso affidabile su un framework di nicchia.

Il problema: agenti AI e API deprecateLa documentazione ufficiale lo dice esplicitamente: senza un intervento mirato, un agente AI generico tende a suggerire pattern Windows obsoleti, perché nei dati di addestramento gli esempi WPF e UWP sono semplicemente più numerosi di quelli WinUI 3. La soluzione adottata non è un modello diverso, ma un plugin che inietta regole esplicite su WinUI 3 come istruzioni personalizzate, sovrascrivendo i comportamenti di default del modello. È un approccio replicabile anche in altri contesti: quando un framework è recente o di nicchia, spesso conviene irrigidire l’agente con conoscenza di dominio esplicita piuttosto che sperare che il modello “la sappia già”.

Gli strumenti coinvoltiL’intero flusso si basa su componenti gratuiti:

Visual Studio Code

.NET SDK 10 o successivo

Windows App Development CLI (winapp), il tool a riga di comando per scaffolding, packaging e testing

#GitHub CLI con estensione Copilot, che richiede un abbonamento GitHub Copilot (è sufficiente il piano gratuito)

Plugin agente WinUI (winui@awesome-copilot)

Estensione WinApp per VS Code

Su Windows l’installazione dei prerequisiti passa quasi interamente da winget:

winget install Microsoft.VisualStudioCode
winget install Microsoft.DotNet.SDK.10
winget install Microsoft.winappcli --source winget
dotnet new install Microsoft.WindowsAppSDK.WinUI.CSharp.Templates
winget install GitHub.cli

gh auth login
gh extension install github/gh-copilot
gh copilot plugin install winui@awesome-copilot

code --install-extension microsoft-winappcli.winapp
winapp --versionL’agente winui-dev e le sue otto skillIl cuore del sistema non è un singolo prompt, ma un pacchetto di otto skill specializzate che l’agente winui-dev orchestra in base al contesto:

winui-setup: verifica e installa i prerequisiti (SDK, template, Developer Mode)

winui-#dev-workflow: guida il ciclo scaffold → build → run → iterazione

winui-design: genera layout XAML con i controlli Fluent Design corretti

winui-code-#review: verifica il codice cercando anti-pattern specifici di WinUI 3

winui-ui-testing: genera test UI basati su Windows UI Automation

winui-packaging: guida su packaging MSIX, firma e pubblicazione in Store

winui-wpf-migration: mappa API WPF verso i corrispondenti WinUI 3

winui-session-report: riassume il lavoro svolto nella sessione

Un dettaglio rilevante per chi lavora già con più strumenti AI: il plugin non è legato a VS Code Copilot Chat. È installabile anche per GitHub Copilot CLI da terminale e, con un registro plugin diverso, per Claude Code:

GitHub Copilot CLI

gh copilot plugin install winui@awesome-copilot
gh copilot plugin list

Claude Code

claude plugin marketplace add microsoft/win-dev-skills
claude plugin install winui@win-dev-skillsIl flusso end-to-end1. Scaffold del progettomkdir MyFirstApp
cd MyFirstApp
dotnet new winui-navviewIl template genera un layout NavigationView con pagine Home, About e Settings già collegate.

2. Prima esecuzionedotnet runL’app parte come pacchetto “loose layout”, senza bisogno di un’installazione MSIX. Solo dopo il primo dotnet run riuscito conviene aprire VS Code con code .: se si preme F5 prima, il debugger cerca un eseguibile che ancora non esiste.

3. Aggiungere funzionalità con l’agenteIn VS Code, con Copilot Chat in modalità Agent e l’agente winui-dev selezionato, basta descrivere cosa serve in linguaggio naturale:

Aggiungi una pagina Impostazioni alla mia app WinUI NavigationView
con un interruttore per la modalità scuraL’agente genera i file necessari, aggiorna la struttura di navigazione e, tramite la skill winui-design, produce XAML coerente con i controlli Fluent Design attuali invece di ricorrere a pattern più datati.

4. PackagingDa un terminale con privilegi elevati (necessario per generare e installare il certificato di sviluppo):

dotnet publish -o ./publish
winapp pack ./publish --generate-cert --install-certPer la sottomissione allo Store, il certificato locale va sostituito con quello fornito da Partner Center.

5. Pubblicazionewinapp store publish ./*.msix --appId Richiede un account Partner Center attivo; la certificazione richiede tipicamente 1-3 giorni lavorativi.

Cosa considerare prima di adottarlo in produzionePer chi gestisce team .NET, il vantaggio pratico non è tanto il tempo risparmiato sulla prima scaffolding — quello lo si ottiene già con i template dotnet new — quanto la skill winui-code-review, che introduce un controllo automatico contro gli anti-pattern più comuni prima ancora del code review umano, e la skill winui-wpf-migration, utile per chi ha ancora applicazioni WPF legacy da modernizzare in modo incrementale. Resta comunque necessaria una revisione umana del codice generato, in particolare su packaging, firma e permessi richiesti dall’app: sono aspetti che incidono direttamente sulla sicurezza dell’installazione finale.

ConclusioneIl flusso descritto da Microsoft è meno una “demo AI” e più un caso di studio su come rendere affidabile un agente su un dominio verticale: prerequisiti scriptabili, skill specializzate invece di un prompt generico, e un plugin compatibile sia con l’ecosistema GitHub Copilot sia con Claude Code. Per i team che sviluppano o mantengono applicazioni Windows native, è uno stack da provare su un progetto pilota prima di considerarlo parte del flusso standard.

Fonte: 4sysops — approfondimento tecnico basato sulla documentazione ufficiale Microsoft Learn: Quickstart e WinUI agent plugin.

Il problema: server Exchange datati che parlano ancora con Exchange OnlineMolte organizzazioni con un deployment ibrido #Exchange non hanno mai completato la migrazione completa al #cloud: mantengono uno o più server Exchange 2016 o 2019 on-premises esclusivamente per gestire l’autenticazione, i connettori di posta o alcuni carichi di lavoro legacy, mentre il grosso delle cassette postali vive già su Exchange Online. È un’architettura comune, ma comporta un rischio spesso sottovalutato: se quel server ibrido non viene aggiornato, diventa silenziosamente un anello debole nella catena di sicurezza dell’intero tenant.

Microsoft ha deciso di intervenire con un piano di enforcement che, a partire dalla seconda settimana di settembre 2026, comincerà a limitare e infine a bloccare i messaggi provenienti da server Exchange 2016 e 2019 che non rispettano una baseline minima di aggiornamento. La notizia è particolarmente rilevante perché il calendario coincide con questi stessi giorni: chi gestisce un ambiente ibrido dovrebbe verificare la propria postura di patching immediatamente, non “quando avrà tempo”.

Cosa cambia esattamenteIl meccanismo riguarda specificamente i server che inviano posta a Exchange Online attraverso un connettore in ingresso di tipo OnPremises: è la configurazione tipica di un ambiente #hybrid, dove il server locale viene autorizzato a inoltrare la posta al cloud bypassando alcuni controlli anti-spam standard, sulla base di una relazione di fiducia. È proprio questa fiducia implicita che Microsoft vuole condizionare a un livello di patching adeguato.

La baseline richiesta è quella dell’ultimo aggiornamento di sicurezza pubblico rilasciato per queste versioni, ovvero il Security Update di ottobre 2025 (Oct25SU) — l’ultimo pacchetto di sicurezza pubblicamente disponibile prima che queste #release entrassero nella fase di solo supporto esteso. In pratica, i livelli minimi accettati sono:

Exchange 2016 CU23 + Oct25SU → build 15.1.2507.61

Exchange 2019 CU15 + Oct25SU → build 15.2.1748.39

Exchange 2019 CU14 + Oct25SU → build 15.2.1544.36

Un dettaglio che genera spesso confusione: verificare di avere installato il CU corretto non basta. Bisogna controllare la build completa, perché due server sullo stesso Cumulative Update possono trovarsi a livelli di #patch di sicurezza diversi se uno dei due ha saltato l’ultimo rollup.

Come si manifesta l’enforcementIl processo segue tre fasi progressive, già collaudate da Microsoft su altre versioni obsolete di Exchange in passato: segnalazione, throttling e infine blocco.

ThrottlingNella fase di rallentamento, Exchange Online ritarda deliberatamente l’accettazione dei messaggi in arrivo dai server non conformi. Il sintomo tipico è un accumulo di code sul server mittente, con retry ripetuti: da fuori sembra un problema di congestione della rete o del server, e questo rende il throttling insidioso da diagnosticare se non si sa cosa cercare.

BloccoSuperata la fase di throttling, i messaggi vengono respinti in modo esplicito, generando NDR (non-delivery report) per i mittenti. A quel punto il problema diventa visibile a tutti — utenti compresi — ma nel frattempo l’organizzazione avrà già perso giorni preziosi di consegna della posta.

Come verificare la propria esposizioneIl primo passo è capire quali server nel proprio ambiente utilizzano effettivamente un connettore OnPremises. Da Exchange Online #PowerShell:

Get-InboundConnector |
Where-Object ConnectorType -eq 'OnPremises' |
Format-List Name,Enabled,SenderIPAddresses,TlsSenderCertificateNameQuesto comando elenca i connettori attivi e gli indirizzi IP autorizzati a inviare posta attraverso di essi: è la mappa di partenza per capire quali server on-premises sono coinvolti.

Sul singolo server Exchange, la versione esatta della build si verifica interrogando ExSetup.exe, molto più affidabile del semplice numero di build mostrato nell’Exchange Admin Center:

Get-Command ExSetup.exe |
ForEach-Object { $_.FileVersionInfo } |
Format-List ProductVersion,FileVersion,FileNamePer un controllo più ampio, che copra anche altri parametri di #salute del server (certificati in scadenza, servizi non funzionanti, configurazioni TLS deboli), vale la pena eseguire lo script Exchange Health Checker, lo strumento diagnostico ufficiale mantenuto dal team Exchange su #GitHub, che segnala automaticamente anche gli scostamenti dalla baseline di sicurezza raccomandata.

Cosa fare prima della scadenzaIl piano d’azione per chi si trova sotto la baseline è relativamente lineare, ma richiede una finestra di manutenzione pianificata con attenzione:

Individuare tutti i server che instradano posta tramite connettori OnPremises e verificarne la build esatta.

Programmare l’installazione dell’aggiornamento di sicurezza di ottobre 2025 (o successivo, se nel frattempo Microsoft ne rilascia uno più recente per questi rami) durante una finestra di manutenzione, con riavvio del server.

Ripetere la verifica della build dopo il riavvio: un’installazione fallita silenziosamente è più comune di quanto si pensi.

Testare i percorsi di failover e i bilanciamenti di carico se si dispone di più server ibridi, per assicurarsi che l’aggiornamento non abbia introdotto regressioni nel routing della posta.

Chi non riesce a completare l’aggiornamento entro i tempi può richiedere una esenzione temporanea, valida fino a 90 giorni per tenant per anno solare (frazionabile in più blocchi), tramite l’Exchange Admin Center o il cmdlet dedicato alla gestione delle esenzioni di enforcement. È una valvola di sfogo utile per chi ha vincoli di change management stringenti, ma va vista come un rinvio, non come una soluzione: la strada obbligata resta l’aggiornamento, oppure — nel medio termine — la migrazione a Exchange Server Subscription Edition o il completamento dello spostamento delle cassette postali residue su Exchange Online.

ConclusioneQuesto enforcement non è un capriccio burocratico: i server Exchange ibridi non aggiornati sono uno dei vettori più sfruttati per compromissioni che, partendo dalla posta, arrivano fino ad Active Directory. Microsoft sta semplicemente smettendo di fidarsi implicitamente di infrastrutture che non dimostrano di essere mantenute in modo attivo. Per i sistemisti che gestiscono ambienti ibridi, il consiglio pratico è di eseguire subito i comandi PowerShell indicati sopra, capire la propria esposizione reale e pianificare l’aggiornamento prima che il throttling si trasformi in un incidente di produzione con gli utenti che segnalano email in ritardo o mai arrivate.

Fonte: Practical365 e Microsoft Tech Community.

Chiunque amministri sistemi #Linux passa gran parte della giornata dentro una shell, e la cronologia dei comandi (history) è probabilmente lo strumento più usato e meno conosciuto a fondo. Sappiamo tutti premere la freccia su o lanciare Ctrl+R, ma pochi sfruttano davvero le variabili che controllano cosa viene salvato, come viene formattato e come sincronizzarlo tra più terminali aperti in contemporanea. Vediamo come portare la gestione della cronologia #Bash a un livello professionale, con configurazioni pronte per essere messe in produzione su server multi-utente.

Le variabili che governano la cronologiaBash tiene traccia dei comandi in due posti distinti: la memoria della sessione corrente e il file su disco (di default ~/.bash_history). Questa distinzione è la fonte di gran parte della confusione quando si lavora con più terminali aperti, quindi vale la pena chiarirla subito con le variabili che la controllano.

HISTSIZE e HISTFILESIZEHISTSIZE stabilisce quanti comandi restano in memoria durante la sessione attiva, mentre HISTFILESIZE determina quante righe vengono conservate nel file su disco. Sono due limiti indipendenti: si può avere una sessione “leggera” con poche centinaia di comandi in memoria ma un archivio storico molto più ampio su disco.

export HISTSIZE=10000
export HISTFILESIZE=20000Impostare un valore negativo (o vuoto) rende la cronologia illimitata: sconsigliato su sistemi condivisi, dove un file di history che cresce senza controllo può diventare un problema sia di #spazio che di sicurezza.

HISTFILEHISTFILE indica dove viene scritta la cronologia. Il default è ~/.bash_history, ma è possibile ridirigerla altrove, ad esempio per tenere una history separata per progetto o per sessioni di audit:

export HISTFILE="$HOME/.bash_history_$(date +%Y%m)"HISTTIMEFORMAT: i timestamp che quasi nessuno abilitaPer impostazione predefinita, history non mostra quando un comando è stato eseguito. Abilitare i timestamp con HISTTIMEFORMAT è probabilmente l’impostazione a più alto rapporto beneficio/sforzo di questo articolo, specialmente in fase di troubleshooting: sapere che un comando è stato lanciato tre minuti prima di un incidente è un’informazione preziosa.

export HISTTIMEFORMAT="%F %T "Con questa impostazione, history | grep nginx restituirà righe del tipo:

1042 2026-09-03 10:14:02 systemctl reload nginxUn dettaglio tecnico da tenere a mente: il timestamp viene registrato internamente come epoch Unix ad ogni comando, ma diventa visibile solo se HISTTIMEFORMAT è impostato prima che i comandi vengano eseguiti. Se lo si abilita a metà sessione, i comandi precedenti non avranno un timestamp recuperabile.

HISTCONTROL: cosa non salvareHISTCONTROL filtra cosa #entra in cronologia:

ignorespace – esclude i comandi che iniziano con uno spazio (utile per non salvare comandi con #password o token inline)

ignoredups – salta i duplicati consecutivi

ignoreboth – combina entrambi i comportamenti precedenti

erasedups – rimuove tutte le occorrenze precedenti di un comando ripetuto, non solo quelle consecutive

export HISTCONTROL=ignorebothIl trucco di ignorespace è particolarmente utile: basta digitare un comando con uno spazio iniziale (es.  curl -H "Authorization: Bearer xyz..." ...) per evitare che token o credenziali finiscano nel file di history in chiaro.

HISTIGNORE: filtrare per patternHISTIGNORE permette di escludere dalla cronologia comandi ricorrenti e poco utili come ls, cd o pwd. Attenzione: i pattern ancorano l’inizio della riga e devono corrispondere all’intero comando, quindi vanno elencati esplicitamente anche gli argomenti comuni.

export HISTIGNORE="ls:ll:la:cd:cd -:pwd:exit:date:clear:history"Le opzioni della shell: histappend e histverifyDue shopt completano la configurazione di base. La prima è quasi obbligatoria su qualunque sistema con più terminali:

shopt -s histappendSenza histappend, Bash sovrascrive il file HISTFILE alla chiusura della shell con il contenuto della sessione corrente, perdendo i comandi salvati da altri terminali chiusi nel frattempo. Con histappend attivo, ogni sessione aggiunge in coda invece di sovrascrivere.

La seconda opzione utile è histverify, che intercetta le espansioni di history (come !! o !497) e le mostra sul prompt per una conferma, invece di eseguirle immediatamente:

shopt -s histverifyQuesto piccolo accorgimento evita un classico incidente: digitare !42 pensando che sia un comando innocuo e scoprire, dopo l’esecuzione, che il comando numero 42 era un rm -rf lanciato ore prima in un altro contesto.

Sincronizzare la cronologia tra terminali multipliPer chi lavora con molte finestre o sessioni tmux/screen aperte in parallelo, il comportamento di default di Bash è frustrante: ogni shell scrive la propria history solo alla chiusura, quindi i comandi digitati in un terminale non sono visibili negli altri finché non li si chiude esplicitamente.

La soluzione è agganciare la scrittura e la ricarica della history a PROMPT_COMMAND, che Bash esegue prima di ogni visualizzazione del prompt:

PROMPT_COMMAND="history -a; history -c; history -r${PROMPT_COMMAND:+; $PROMPT_COMMAND}"Scomponendo la sequenza:

history -a – accoda immediatamente su disco i nuovi comandi della sessione

history -c – svuota la lista in memoria della sessione corrente

history -r – ricarica in memoria l’intero file, inclusi i comandi scritti da altre sessioni

Il risultato: la freccia su e Ctrl+R attingono a una cronologia condivisa e aggiornata quasi in tempo reale tra tutti i terminali aperti. Il costo è un piccolo overhead ad ogni prompt, generalmente trascurabile salvo file di history molto grandi; in quel caso è preferibile una variante più leggera con history -n, che #legge solo le righe nuove invece di ricaricare l’intero file:

PROMPT_COMMAND="history -a; history -n${PROMPT_COMMAND:+; $PROMPT_COMMAND}"Comandi di gestione della historyOltre alle variabili di ambiente, il builtin history offre diverse operazioni utili in amministrazione quotidiana:

Mostra tutta la cronologia con numerazione

history

Ultimi 20 comandi

history 20

Cerca nella cronologia

history | grep nginx

Scrive subito su disco la sessione corrente

history -a

Elimina una riga specifica dalla memoria (es. riga 497)

history -d 497

Elimina e persiste la rimozione sul file

history -d 497 && history -w

Svuota completamente memoria e file

history -c && history -wPer disabilitare temporaneamente la registrazione, ad esempio prima di digitare una password su un comando che non supporta variabili d’ambiente:

set +o history

comandi non registrati qui

set -o historyLe scorciatoie da tastiera che valgono la pena imparareOltre al classico Ctrl+R per la ricerca incrementale, Bash espone un intero linguaggio di espansione della history, largamente sotto-utilizzato:

ScorciatoiaFunzione!!Ripete l’ultimo comando!$Ultimo argomento del comando precedente!^Primo argomento del comando precedente!*Tutti gli argomenti del comando precedente!NEsegue il comando numero N!stringaUltimo comando che inizia con “stringa”!stringa:pMostra il comando senza eseguirlo (preview)^vecchio^nuovoSostituisce e rilancia l’ultimo comandoAlt+.Richiama ciclicamente l’ultimo argomento dei comandi precedenti!$ in particolare è utile più spesso di quanto sembri: dopo mkdir /var/log/miaapp, digitare cd !$ evita di riscrivere il percorso.

Ricerca interattiva avanzata con fzfPer chi trova Ctrl+R limitante, fzf lo sostituisce con un fuzzy finder interattivo molto più potente:

sudo apt install fzf # Debian/Ubuntu
eval "$(fzf --bash)" # da aggiungere a ~/.bashrcUna volta configurato, Ctrl+R apre un filtro interattivo con evidenziazione live: premendo Invio la prima volta il comando viene incollato sul prompt (non eseguito), permettendo di modificarlo prima del lancio effettivo.

Sicurezza: la history non è un controllo, è un logAlcuni punti da tenere presenti quando si gestiscono cronologie su sistemi condivisi o in produzione:

Il file di history dovrebbe avere permessi restrittivi: chmod 600 ~/.bash_history

ignorespace nasconde un comando dalla history solo se lo spazio iniziale viene digitato manualmente: non è un meccanismo automatico

File di history su NFS o directory sincronizzate (Dropbox, syncthing, ecc.) possono esporre comandi sensibili a più host

La cronologia è auditabile dall’utente stesso ma non è un controllo di sicurezza: chiunque abbia accesso alla shell può disabilitarla con set +o history o cancellarla

Per un audit trail affidabile in produzione, la history di Bash va affiancata (non sostituita) da strumenti dedicati come auditd o da logging centralizzato della sessione shell

Configurazione completa consigliataRiassumendo tutto quanto visto in un blocco pronto per ~/.bashrc:

Configurazione History Bash

HISTSIZE=10000
HISTFILESIZE=20000
HISTTIMEFORMAT="%F %T "
HISTCONTROL=ignoreboth
HISTIGNORE="ls:ll:la:cd:cd -:pwd:exit:date:clear:history"

shopt -s histappend
shopt -s histverify

Sincronizza la cronologia tra terminali dopo ogni comando

PROMPT_COMMAND="history -a; history -c; history -r${PROMPT_COMMAND:+; $PROMPT_COMMAND}"Dopo averla incollata, applicarla con:

source ~/.bashrcConclusioneLa cronologia di Bash è uno di quegli strumenti che si usano per anni senza mai configurarli davvero. Pochi minuti spesi su HISTTIMEFORMAT, HISTCONTROL e la sincronizzazione via PROMPT_COMMAND trasformano un log grezzo e volatile in uno strumento di troubleshooting affidabile, specialmente su server dove si lavora regolarmente da più sessioni contemporanee. Per chi gestisce ambienti multi-utente, vale la pena ricordare che la history resta comunque uno strumento lato client: per l’audit reale servono log centralizzati indipendenti dalla volontà dell’utente.

Fonte originale: Master Linux Bash History with historyctl, HISTFILE, and Shortcuts – LinuxBlog.io

Il 31 agosto 2026 Debian 11 “Bullseye” ha ufficialmente raggiunto l’end-of-life: da settembre il progetto Debian non rilascia più aggiornamenti di sicurezza per questa #release. Chi gestisce server, #container o workstation ancora basati su Bullseye si trova quindi davanti a una finestra di rischio che va chiusa al più presto, spostando i sistemi su Debian 12 “Bookworm” o valutando un percorso alternativo di supporto esteso. In questo articolo vediamo cosa comporta davvero la fine del supporto, quali sono le opzioni disponibili e come eseguire l’upgrade in modo controllato, senza sorprese in produzione.

Perché la fine del supporto non è un dettaglio burocraticoDebian 11 è stato rilasciato il 14 agosto 2021 e, seguendo il classico ciclo di vita quinquennale del progetto (circa tre anni di supporto regolare più un periodo di Long Term Support gestito dal team LTS), ha chiuso il proprio percorso di manutenzione ufficiale il 31 agosto 2026. Da questo momento in poi, nessuna vulnerabilità scoperta nei pacchetti di Bullseye — dal #kernel a #OpenSSL, da Apache a #systemd — riceverà più una #patch attraverso i canali ufficiali security.debian.org.

Per un sistema esposto su #internet, anche solo per un servizio SSH o un endpoint HTTP, questo significa che ogni nuova #CVE resta aperta indefinitamente. Non è un problema teorico: gli scanner automatizzati che individuano versioni di pacchetto vulnerabili sono tra gli strumenti più usati per la ricognizione iniziale di un attacco, e un sistema Debian 11 “congelato” diventa un bersaglio sempre più facile man mano che passano i mesi.

Le opzioni sul tavoloChi si trova ancora su Bullseye ha essenzialmente tre strade:

Upgrade a Debian 12 “Bookworm”, attualmente la release seguita dal team Debian LTS con supporto pianificato fino al 30 giugno 2028 per le architetture principali (amd64, i386, arm64, armhf, ppc64el). È la scelta consigliata per la maggior parte degli ambienti.

Extended LTS (ELTS), un programma a pagamento gestito da fornitori esterni (tipicamente tramite Freexian) che estende il supporto di sicurezza per un sottoinsieme di pacchetti Bullseye oltre la data di EOL ufficiale. Utile come misura ponte quando l’upgrade richiede una pianificazione più lunga, non come soluzione permanente.

Migrazione diretta a Debian 13 “Trixie” per chi preferisce saltare una generazione e allineare fin da subito il ciclo di vita, tenendo però conto che il salto tra due major release comporta più rischio di rottura in un’unica finestra di manutenzione.

Cosa cambia passando a BookwormDebian 12 introduce alcune differenze che vale la pena conoscere prima di lanciare l’upgrade, perché possono impattare configurazioni esistenti:

Kernel Linux 6.1 come base, con supporto hardware più recente ma anche nomi dei moduli e comportamenti di alcuni driver che possono differire da quelli di Bullseye (kernel 5.10).

Introduzione del componente non-free-firmware, separato da non-free: i firmware proprietari (Wi-Fi, GPU, RAID controller) vanno ora dichiarati esplicitamente in questa sezione dei repository, altrimenti l’installer o l’upgrade potrebbero non trovarli.

Versioni aggiornate dei runtime più comuni: PHP 8.2, Python 3.11, MariaDB 10.11, il che può richiedere una verifica di compatibilità per applicazioni legacy prima di procedere.

systemd, APT e le librerie di base aggiornate, con conseguente necessità di rispondere a diversi prompt di merge sui file di configurazione durante l’upgrade (in particolare per servizi come SSH, sudo o cron con configurazioni personalizzate).

Checklist pre-upgradePrima di toccare qualsiasi repository, vale la pena dedicare mezz’ora a una checklist minima:

Backup completo del sistema o quantomeno di /etc, dei database e dei dati applicativi, con un piano di rollback (snapshot LVM, snapshot del provider cloud, o immagine del disco).

Verifica dello spazio disco disponibile: l’upgrade scarica e mantiene temporaneamente sia i pacchetti vecchi che quelli nuovi.

Controllo dei repository di terze parti (Docker, PPA non ufficiali, repository di vendor) che potrebbero non avere ancora pacchetti per Bookworm: vanno disabilitati temporaneamente per evitare conflitti di dipendenze.

Elenco dei pacchetti “held” (apt-mark showhold) e di eventuali pacchetti installati manualmente al di fuori di APT.

Se possibile, replica del test su un ambiente di staging identico prima di intervenire sui sistemi di produzione.

La procedura di upgrade passo per passoUna volta completata la checklist, la sequenza classica per un upgrade in-place è la seguente.

1. Portare Bullseye completamente aggiornatosudo apt update
   sudo apt upgrade
   sudo apt --purge autoremove
   Questo passaggio riduce il numero di pacchetti coinvolti nel salto di release e rimuove pacchetti orfani che potrebbero complicare la risoluzione delle dipendenze.

2. Aggiornare i repository APTSi modifica /etc/apt/sources.list (e gli eventuali file in /etc/apt/sources.list.d/) sostituendo ogni occorrenza di bullseye con bookworm, ricordandosi di aggiungere il componente non-free-firmware:

deb https://deb.debian.org/debian/ bookworm main contrib non-free non-free-firmware
deb https://deb.debian.org/debian/ bookworm-updates main contrib non-free non-free-firmware
deb https://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware
3. Eseguire l’upgrade in due fasisudo apt update
sudo apt upgrade --without-new-pkgs
sudo apt full-upgrade
Il primo upgrade --without-new-pkgs applica gli aggiornamenti possibili senza installare nuovi pacchetti o rimuoverne di esistenti, riducendo il rischio di un salto troppo aggressivo in un solo colpo. Il successivo full-upgrade completa la transizione gestendo anche i cambi di dipendenze tra le due release, incluse eventuali rimozioni di pacchetti obsoleti.

Durante questa fase compariranno i prompt interattivi di dpkg per i file di configurazione modificati localmente: la scelta più sicura, quando non si è certi, è mantenere la versione locale e rivedere manualmente i diff dei file più critici (sshd_config, sudoers, i file di configurazione dei servizi applicativi) dopo il reboot.

4. Riavvio e verificasudo systemctl reboot
   Dopo il riavvio, si conferma la versione effettivamente in esecuzione:

lsb_release -a
cat /etc/debian_version
ed è buona pratica eseguire un ultimo giro di pulizia:

sudo apt --purge autoremove
sudo apt clean
Errori comuni da evitareSaltare il passaggio intermedio --without-new-pkgs e lanciare direttamente full-upgrade: funziona quasi sempre, ma su sistemi con molte dipendenze di terze parti aumenta la probabilità di un errore a metà upgrade più difficile da diagnosticare.

Dimenticare i repository esterni (Docker CE, repository PHP di terze parti, agent di monitoring): se restano puntati su bullseye l’upgrade può fallire silenziosamente su quei pacchetti specifici, lasciandoli disallineati dal resto del sistema.

Non verificare la compatibilità delle applicazioni con le nuove versioni di PHP, Python o del database: un salto di versione major di MariaDB o PHP può introdurre breaking change che vanno testati prima, non scoperti in produzione.

Ignorare i pacchetti “held” o compilati manualmente, che possono bloccare la risoluzione delle dipendenze durante il full-upgrade.

Se l’upgrade immediato non è possibileNon tutti gli ambienti possono essere aggiornati nel giro di pochi giorni: applicazioni legacy, certificazioni che richiedono test approfonditi, o semplicemente la mole di sistemi da migrare possono richiedere più tempo. In questi casi, il programma Extended LTS è una misura transitoria ragionevole per coprire le vulnerabilità più critiche mentre si pianifica la migrazione, ma va trattato come tale: un ponte verso Bookworm, non una destinazione finale. Rimandare indefinitamente l’upgrade lasciando un sistema esposto senza patch di sicurezza è il rischio che questa intera operazione serve a evitare.

ConclusioneLa fine del supporto di Debian 11 è un promemoria puntuale di una regola che vale per qualunque distribuzione con ciclo di vita a tempo: pianificare l’upgrade prima della scadenza costa una manutenzione ordinaria, farlo dopo — o non farlo affatto — costa un incidente di sicurezza. La procedura verso Debian 12 è ben collaudata e, con un backup solido e una checklist pre-upgrade seguita con disciplina, resta uno degli aggiornamenti major più prevedibili nell’ecosistema Linux.

Fonte: 4sysops – Debian 11 LTS ends: upgrade to Debian 12 before updates stop, con riferimento all’annuncio ufficiale del progetto Debian.

Chiunque gestisca server Linux in produzione, prima o poi, si scontra con lo stesso muro: l’hardware non è il collo di bottiglia, lo sono i valori di default del kernel. Un server con dischi NVMe e una scheda di rete da 10 Gbps che fatica a superare poche centinaia di connessioni simultanee, o che soffre di latenza inspiegabile sotto carico, nella stragrande maggioranza dei casi non ha un problema di risorse: ha un problema di tuning.

Il kernel Linux espone centinaia di parametri regolabili a runtime tramite l’interfaccia sysctl, che agisce sull’albero /proc/sys/. Sono impostazioni pensate per andare bene “in media” su qualunque macchina, dal Raspberry Pi al server con 512 GB di RAM. Per un ambiente di produzione, però, “in media” spesso non basta. Vediamo quali parametri contano davvero, perché, e come applicarli senza rischiare di rompere il sistema.

Come funziona sysctlPrima di toccare qualunque valore è utile ripassare i comandi base. sysctl permette di leggere e modificare i parametri kernel senza riavviare la macchina:

Elencare tutti i parametri disponibili

sysctl -a

Leggere un singolo parametro

sysctl net.ipv4.tcp_syncookies

Modificarlo temporaneamente (non sopravvive al riavvio)

sudo sysctl -w net.ipv4.tcp_syncookies=1Per rendere le modifiche permanenti, la pratica corretta è creare un file dedicato sotto /etc/sysctl.d/ — evitando di editare direttamente /etc/sysctl.conf, che su molte distribuzioni convive male con i pacchetti che installano le proprie regole:

sudo nano /etc/sysctl.d/99-tuning.conf
sudo sysctl --system # applica tutti i file in /etc/sysctl.d/Rete: buffer TCP e gestione delle connessioniSui server con traffico sostenuto, i buffer TCP di default sono quasi sempre troppo piccoli. Il kernel alloca dinamicamente memoria per i socket entro i limiti impostati da questi tre valori (minimo, default, massimo, in byte):

net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864Alzare il massimo a 64 MB ha senso soprattutto su link ad alta banda e alta latenza (data center distanti, CDN, replica di database geografica), dove il bandwidth-delay product richiede finestre TCP più ampie per saturare il collegamento.

Altrettanto importante è la gestione della coda di connessioni in ingresso, che su un server esposto a picchi di traffico determina quante richieste vengono accettate prima di iniziare a scartarle:

net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 16384
net.ipv4.tcp_syncookies = 1somaxconn in particolare va allineato al backlog configurato lato applicazione (nginx, HAProxy, il socket listener della tua app .NET o Node): se l’applicazione chiede una coda più grande di quella permessa dal kernel, il valore effettivo resta quello più basso.

Attivare BBR come algoritmo di congestion controlIl cambiamento con il rapporto costo/beneficio più alto per la maggior parte dei server moderni è probabilmente il passaggio da CUBIC a BBR come algoritmo di controllo della congestione. CUBIC reagisce alla perdita di pacchetti: aumenta la finestra di invio finché non rileva un drop, poi la dimezza. È un approccio reattivo che su reti con perdita “di fondo” non dovuta a congestione (Wi-Fi, mobile, certi link satellitari) penalizza inutilmente il throughput.

BBR, sviluppato da Google e stabile nei kernel a partire dalla serie 4.9, funziona in modo diverso: stima attivamente il bandwidth-delay product del percorso di rete e modula l’invio di conseguenza, senza aspettare la perdita di pacchetti come segnale. Sui kernel 5.15 e 6.x l’implementazione è ulteriormente raffinata (il set di funzionalità informalmente indicato come “BBRv3”), ma non serve aggiornare il kernel apposta: se hai già un kernel recente, BBR c’è già, va solo abilitato.

Verifica gli algoritmi disponibili

sysctl net.ipv4.tcp_available_congestion_control

Se necessario, carica il modulo

sudo modprobe tcp_bbr
echo tcp_bbr | sudo tee /etc/modules-load.d/tcp-bbr.confE nel file di configurazione:

net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fqIl secondo parametro non è opzionale: BBR è stato progettato e testato insieme alla queue discipline fq (fair queue con pacing), e usarlo con la pfifo_fast di default riduce buona parte del beneficio. Dopo l’attivazione, verifica con:

sysctl net.ipv4.tcp_congestion_control
ss -tin | grep bbrMemoria: swap, cache e writebackIl secondo fronte dove i default fanno più danni è la gestione della memoria, in particolare su server con molta RAM dedicati a database o applicazioni in-memory.

vm.swappiness = 10
vm.vfs_cache_pressure = 50swappiness (range 0-200, default 60) determina quanto aggressivamente il kernel sposta pagine di memoria su swap invece di liberare cache. Un valore basso come 10 dice al kernel di preferire fortemente la RAM fisica e di ricorrere allo swap solo quando davvero necessario — comportamento quasi sempre desiderabile su un server con database, dove uno swap-in inatteso su una query critica si traduce in latenza a due cifre percentuali più alta. vfs_cache_pressure più basso del default (100) fa sì che il kernel trattenga più a lungo la cache di metadati e dentry, utile su filesystem con molti file piccoli.

Altrettanto rilevante è il comportamento di scrittura delle pagine “sporche” (dirty), cioè modificate in memoria ma non ancora sincronizzate su disco:

vm.dirty_ratio = 10
vm.dirty_background_ratio = 5
vm.dirty_expire_centisecs = 1500
vm.dirty_writeback_centisecs = 250Con i default (rispettivamente 20 e 10, spesso più alti su alcune distribuzioni), un server con molta RAM può accumulare diversi gigabyte di dati non ancora scritti su disco prima che il kernel forzi il flush — e quando lo fa, l’intero sistema può bloccarsi per secondi mentre scrive tutto in una volta. Abbassare le soglie distribuisce il lavoro di scrittura in modo più uniforme, a costo di un overhead I/O leggermente maggiore ma costante. Su macchine con centinaia di GB di RAM, conviene passare dai valori percentuali a limiti assoluti in byte (vm.dirty_bytes, vm.dirty_background_bytes), perché una percentuale del 10% su 512 GB di RAM è comunque troppo.

File descriptor e limiti di sistemaUn errore classico su server che gestiscono molte connessioni concorrenti (web server, message broker, database con molti client) è l’esaurimento dei file descriptor disponibili:

fs.file-max = 2097152
fs.nr_open = 1048576
fs.inotify.max_user_watches = 524288Quest’ultimo parametro merita attenzione particolare: inotify.max_user_watches troppo basso è la causa più comune dell’errore “too many open files” riportato da strumenti come Webpack dev server, editor con file watching, o sistemi di sincronizzazione che monitorano grandi alberi di directory — non ha nulla a che fare con i socket di rete, ma con il numero di file che il kernel può tenere sotto osservazione per notifiche di modifica.

Sicurezza di reteUn piccolo set di parametri riduce la superficie d’attacco a livello di stack di rete senza impatto sulle prestazioni:

net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.log_martians = 1rp_filter (reverse path filtering) merita una nota: impostato a 1 (strict mode) rifiuta pacchetti il cui indirizzo sorgente non è raggiungibile tramite l’interfaccia su cui sono arrivati, mitigando IP spoofing. È la scelta giusta per la maggior parte dei server, ma su macchine con routing asimmetrico — tipicamente setup multihomed, alcune configurazioni VPN o BGP — va impostato a 2 (loose mode), altrimenti si rischia di scartare traffico legittimo.

Un parametro storico da NON usareVale la pena segnalarlo esplicitamente perché gira ancora in vecchie guide copiate e incollate da un blog all’altro: net.ipv4.tcp_tw_recycle è stato rimosso dal kernel a partire dalla versione 4.12 perché causava problemi seri dietro NAT (connessioni rifiutate in modo intermittente e difficile da diagnosticare). Se lo trovate in un file sysctl.conf ereditato da un vecchio sistema, va rimosso: su kernel recenti l’impostazione viene semplicemente ignorata, ma la sua presenza è un segnale che quella configurazione non è stata rivista da anni.

Applicare e verificareMettendo insieme i parametri discussi in un unico file di configurazione:

/etc/sysctl.d/99-tuning.conf

Rete: buffer TCP

net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864

Rete: congestion control

net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq

Rete: gestione connessioni

net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 16384
net.ipv4.tcp_syncookies = 1

Memoria

vm.swappiness = 10
vm.vfs_cache_pressure = 50
vm.dirty_ratio = 10
vm.dirty_background_ratio = 5

File descriptor

fs.file-max = 2097152
fs.inotify.max_user_watches = 524288

Sicurezza

net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.log_martians = 1Dopo l’applicazione con sudo sysctl --system, alcuni controlli utili per confermare che tutto sia entrato in vigore:

sysctl net.ipv4.tcp_congestion_control
cat /proc/sys/fs/file-nr
cat /proc/meminfo | grep -i dirty
sudo dmesg | tail -20ConclusioneNessuno di questi parametri va applicato alla cieca copiando un file da internet, incluso questo. Ogni ambiente ha un profilo di carico diverso — un database transazionale, un reverse proxy ad alto traffico e un batch processor hanno esigenze di memoria e rete molto differenti — e il modo corretto di procedere è cambiare pochi parametri alla volta, misurare, e tenere traccia di cosa è stato modificato e perché, magari versionando il file sysctl.d insieme al resto della configurazione infrastrutturale. Il vantaggio di sysctl è proprio questo: ogni modifica è reversibile a runtime, il che rende il tuning un processo iterativo e sicuro invece che un salto nel buio a ogni riavvio.

Fonte originale: Linux Kernel Parameters Tuning for Better Performance, LinuxBlog.io.

Not only can you create powerful masks quickly in darktable, you can also reuse them in multiple modules, saving time and allowing you to apply different types of changes (e.g. exposure, color, or detail) to the same masked area. Let's look at some examples of how to reuse masks below:
https://avidandrew.com/reusing-masks.html

#photography #tutorial #opensource #artwithopensource #foss #fossart #canon #darktable #camera #linux #software #freesoftware #ford #car #classicCar

Il TTFB non dipende solo dall’applicazione: quanto costa davvero l’handshake TLSQuando un sito HTTPS risponde lentamente, il riflesso condizionato di ogni sistemista è guardare al backend: query lente, cache assente, un’applicazione PHP o .NET che non scala. Ma prima ancora che la richiesta arrivi al codice applicativo, il client e il server devono completare un handshake TLS, negoziare un protocollo, verificare un certificato ed eventualmente riprendere una sessione precedente. Ognuno di questi passaggi ha un costo in millisecondi, e su siti ad alto traffico o con molte connessioni “fredde” (nuovi visitatori, CDN edge miss, mobile su rete instabile) quel costo si somma in modo tutt’altro che trascurabile.

La buona notizia è che gran parte di questo overhead è governato da una manciata di direttive Nginx che, se lasciate ai valori di default, non sono ottimizzate per la latenza. In questo articolo vediamo come intervenire in modo mirato su HTTP/2, HTTP/3, cache di sessione TLS, versioni del protocollo, cipher suite e OCSP stapling, con un occhio a cosa è davvero cambiato nel panorama TLS nel 2026 rispetto a configurazioni “storiche” che circolano ancora in molte guide.

HTTP/2 e HTTP/3: come attivarli correttamenteSu Nginx recente (1.25.1 e successivi) il supporto HTTP/2 non si attiva più come parametro del blocco listen, ma con una direttiva dedicata. La sintassi legacy listen 443 ssl http2; è deprecata e in alcune build genera un warning in fase di reload:

listen 443 ssl;
http2 on;Per chi vuole spingersi oltre, HTTP/3 (basato su QUIC, quindi su UDP anziché TCP) è supportato nativamente da Nginx 1.25.0 in poi:

listen 443 ssl;
listen [::]:443 ssl;
listen 443 quic reuseport;
listen [::]:443 quic reuseport;
http2 on;
add_header Alt-Svc 'h3=":443"; ma=86400';L’header Alt-Svc non è opzionale: senza di esso il browser non ha modo di sapere che il server parla anche HTTP/3, e continuerà a usare HTTP/2 anche se QUIC è configurato correttamente sul lato server. Va inoltre ricordato che molte reti aziendali e alcuni provider filtrano il traffico UDP sulla porta 443, quindi HTTP/3 va sempre trattato come miglioramento progressivo e non come sostituto esclusivo di HTTP/2.

Session cache e session ticket: evitare handshake completiOgni handshake TLS completo comporta uno scambio di chiavi asimmetrico, che è l’operazione più costosa dell’intero processo. La cache di sessione permette a un client che si riconnette di saltare questo passaggio:

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets on;Una cache condivisa da 10 MB memorizza circa 4.000 sessioni: per un sito a traffico medio è più che sufficiente, ma su cluster con più worker o più nodi Nginx dietro un load balancer va dimensionata in base al numero di client unici attesi nella finestra di ssl_session_timeout. Un dettaglio spesso trascurato: da Nginx 1.23.2 la gestione delle chiavi dei session ticket è stata migliorata, ma se si opera un’infrastruttura con più server dietro lo stesso load balancer, le chiavi di ticket vanno sincronizzate tra i nodi (tipicamente con ssl_session_ticket_key e un file condiviso via configuration management), altrimenti il beneficio della ripresa di sessione si perde ogni volta che il client finisce su un nodo diverso da quello dell’handshake iniziale.

Versioni del protocollo: perché TLS 1.3 non è solo “più sicuro”La direttiva sulle versioni supportate resta relativamente semplice:

ssl_protocols TLSv1.2 TLSv1.3;Il punto tecnico interessante è che TLS 1.3 non porta solo benefici di sicurezza (rimozione di cipher obsoleti, forward secrecy obbligatoria), ma anche di performance pura: riduce l’handshake a un singolo round trip contro i due richiesti da TLS 1.2, e supporta la ripresa di sessione tramite un meccanismo (0-RTT/PSK) che rende le riconnessioni ancora più rapide. Per un client con RTT di rete di 80-100ms verso il server — scenario comune per utenti mobile o geograficamente distanti dal datacenter — il risparmio di un intero round trip si traduce direttamente in TTFB più basso.

Mantenere TLS 1.2 come fallback resta comunque prudente per compatibilità con client legacy (alcune librerie HTTP embedded, dispositivi IoT, versioni datate di Android). Limitarsi al solo TLS 1.3 va considerato solo per ambienti controllati, come API interne o servizi machine-to-machine dove si conoscono con certezza i client.

Cipher suite: meno è meglio, con TLS 1.3Su TLS 1.2 la scelta delle cipher suite ha ancora impatto pratico:

ssl_prefer_server_ciphers off;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';Da notare l’impostazione ssl_prefer_server_ciphers off: con TLS 1.3 e i client moderni, lasciare che sia il client a scegliere la cipher (in base a cosa è accelerato via hardware sul suo dispositivo, ad esempio AES-NI vs ChaCha20 su mobile) è generalmente più efficiente che imporre l’ordine lato server.

Con TLS 1.3, però, le cipher suite sono fissate dal protocollo stesso: mantenere una lunga stringa ssl_ciphers personalizzata e una direttiva ssl_ecdh_curve manuale non porta quasi nessun beneficio aggiuntivo per le connessioni che negoziano TLS 1.3, e serve solo a coprire il fallback su TLS 1.2. Molte configurazioni “best practice” che circolano online sono più complesse del necessario proprio perché non tengono conto di questo aspetto.

OCSP stapling: un capitolo da riscrivere nel 2026Fino a poco tempo fa, l’OCSP stapling era una delle ottimizzazioni TLS più raccomandate: invece di far verificare al browser lo stato di revoca del certificato con una richiesta separata al CA, il server allega (“stapla”) una risposta OCSP firmata direttamente durante l’handshake, risparmiando un round trip:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /path/to/full_chain.pem;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;Questo è un punto su cui molti sistemisti non sono ancora allineati: Let’s Encrypt ha dismesso il supporto OCSP nell’agosto 2025, passando esclusivamente a CRL (Certificate Revocation List) a corto ciclo di vita per la verifica di revoca. Se i certificati del vostro dominio provengono da Let’s Encrypt, le direttive sopra sono di fatto inerti: Nginx proverà a fare stapling ma non otterrà risposte valide, e conviene rimuoverle per tenere la configurazione pulita e i log privi di errori di risoluzione OCSP inutili. Se invece usate un CA diverso che continua a supportare OCSP, le direttive restano valide e utili.

Buffer TLS: un’ottimizzazione minore ma misurabilessl_buffer_size 4k;Il valore di default di Nginx per il buffer di invio TLS è 16k, pensato per massimizzare il throughput su trasferimenti di grandi dimensioni. Per il traffico HTTP tipico — pagine HTML, chiamate API, asset di dimensioni moderate — un buffer più piccolo (4k) riduce la quantità di dati che devono essere cifrati e trasmessi prima che il client possa iniziare a processare la risposta, con un guadagno tipico nell’ordine di 30-50ms sul TTFB. È un’ottimizzazione minore rispetto a HTTP/2 o al session caching, ma essendo a costo zero (nessun trade-off di sicurezza) vale la pena applicarla su siti dove il TTFB è una metrica critica.

Configurazione completa di riferimentoserver {
listen 443 ssl;
listen [::]:443 ssl;
http2 on;

ssl_certificate     /etc/nginx/ssl/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/privkey.pem;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets on;
ssl_buffer_size 4k;

add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload" always;
add_header X-Frame-Options SAMEORIGIN always;
add_header X-Content-Type-Options nosniff always;

}Da personalizzare rimuovendo il blocco OCSP se il certificato proviene da Let’s Encrypt, e aggiungendo i blocchi listen ... quic reuseport; e l’header Alt-Svc se si vuole abilitare anche HTTP/3.

Cosa aspettarsi (e cosa no) da questa ottimizzazioneVale la pena essere chiari sui limiti: il tuning TLS non risolve un’applicazione lenta. Se il backend impiega 800ms per generare una risposta, risparmiare 50ms sull’handshake è un’ottimizzazione marginale rispetto al problema reale. Dove il tuning TLS fa davvero la differenza è nel ridurre l’overhead fisso presente su ogni richiesta HTTPS, in particolare per le connessioni “fredde” e per utenti con RTT di rete elevato — scenari in cui il costo dell’handshake può facilmente superare il tempo di elaborazione lato server. Caching applicativo, ottimizzazione del backend e CDN restano le leve principali per le performance complessive, ma un livello TLS ben configurato è la base su cui tutte le altre ottimizzazioni si appoggiano, ed è spesso trascurata proprio perché “funziona già” con i valori di default.

Articolo ispirato e approfondito a partire da: Nginx tuning tips: HTTPS/TLS – Turbocharge TTFB/Latency, LinuxBlog.io.

Ogni sistemista Linux, prima o poi, si trova davanti a una domanda che top o free non riescono a risolvere del tutto: perché questo processo consuma tanta memoria? Perché una porta risulta occupata ma netstat non mostra nulla? Perché un servizio continua a scrivere su un file che, in teoria, è stato cancellato? La risposta, quasi sempre, si trova in un posto che molti amministratori conoscono solo superficialmente: /proc.

/proc non è una directory come le altre. È un filesystem virtuale, di tipo procfs, generato e mantenuto interamente dal kernel in memoria: non un singolo byte dei suoi contenuti risiede su disco. È, di fatto, una finestra live sullo stato interno del kernel, esposta attraverso strumenti che ogni sistemista già conosce: cat, grep, awk. Comandi come free, ps, top e iostat non fanno altro che leggere e formattare i dati che /proc mette a disposizione: imparare a leggerlo direttamente significa avere accesso alle stesse informazioni, ma senza filtri, e con la possibilità di combinarle in modi che nessun tool preconfezionato offre.

La struttura: due mondi in una directory/proc contiene sostanzialmente due categorie di contenuti. Da un lato le directory numerate, una per ogni processo in esecuzione (/proc/1234/, dove 1234 è il PID), che espongono lo stato specifico di quel processo. Dall’altro i file di sistema globali, come /proc/meminfo o /proc/cpuinfo, che riflettono lo stato del kernel nel suo complesso, indipendentemente da quale processo li legga.

I file di sistema che contano davvero/proc/cpuinfo e /proc/stat/proc/cpuinfo elenca i core logici della CPU con modello, velocità di clock, dimensione della cache e i flag di supporto per estensioni come vmx (virtualizzazione hardware), aes e avx2. Un one-liner molto usato per contare le CPU logiche disponibili è:

grep -c '^processor' /proc/cpuinfo/proc/stat, invece, espone i contatori di tempo CPU aggregati e per singolo core, suddivisi in colonne: user, nice, system, idle, iowait, irq, softirq. Su un server sotto carico I/O-intensivo, tenere d’occhio la colonna iowait nel tempo è spesso più diagnostico di qualunque dashboard grafica, perché permette di isolare il momento esatto in cui la CPU comincia ad attendere lo storage invece di lavorare.

/proc/meminfo: oltre a “free”/proc/meminfo è la fonte dati grezza dietro al comando free, ma contiene molti più campi di quelli che free mostra normalmente. Due meritano attenzione particolare: MemAvailable, che indica la memoria realmente disponibile per nuovi processi tenendo conto della cache riclamabile (a differenza di MemFree, che è quasi sempre un numero fuorviante), e Dirty, che riporta quanta memoria contiene dati modificati ancora in attesa di essere scritti su disco — un valore che cresce pericolosamente su sistemi con storage lento e scritture intense.

Per un monitoraggio in tempo reale della pressione di memoria, questo comando è estremamente utile in fase di troubleshooting:

watch -n1 'grep -E "MemAvailable|Dirty|Writeback|SwapFree" /proc/meminfo'/proc/diskstats, /proc/loadavg, /proc/net//proc/diskstats fornisce le statistiche I/O per dispositivo — letture, scritture, settori trasferiti, tempo speso in operazioni — ed è la fonte dietro iostat. /proc/loadavg espone le tre celebri medie di carico a 1, 5 e 15 minuti, mentre /proc/uptime riporta i secondi trascorsi dal boot e il tempo cumulativo di inattività della CPU.

La sottodirectory /proc/net/ merita un capitolo a sé: /proc/net/dev contiene i contatori di byte e pacchetti per ogni interfaccia di rete, /proc/net/tcp e tcp6 elencano tutte le connessioni TCP attive in formato esadecimale, /proc/net/sockstat riassume l’utilizzo dei socket a livello di sistema, e /proc/net/snmp espone contatori SNMP utili per individuare retransmit e fallimenti di connessione anomali.

Il mondo per-processo: /proc/PID/Qui si trova la parte più preziosa per il debugging quotidiano. Alcuni file chiave:

/proc/PID/cmdline — il comando esatto con cui il processo è stato lanciato, con gli argomenti delimitati da byte null.

/proc/PID/status — un riepilogo leggibile con UID, GID, utilizzo di memoria e numero di thread. Il campo VmRSS indica la memoria residente effettivamente occupata, mentre VmSwap segnala se (e quanto) il processo è finito in swap.

/proc/PID/fd/ — una directory di symlink, uno per ogni file descriptor aperto dal processo. È la base dati su cui si appoggia lsof. Contare i descrittori aperti è semplice: ls /proc/12345/fd | wc -l.

/proc/PID/io — la contabilità I/O del processo, con read_bytes e write_bytes che riflettono i dati effettivamente passati al layer di storage.

/proc/PID/maps e /proc/PID/smaps — le regioni di memoria mappate dal processo (codice, stack, heap, librerie condivise). smaps va oltre e fornisce, per ogni regione, i dettagli su RSS, PSS e swap.

/proc/PID/environ — le variabili d’ambiente al momento del lancio, anch’esse delimitate da byte null.

/proc/PID/cwd e /proc/PID/exe — symlink rispettivamente alla directory di lavoro corrente e all’eseguibile su disco. Sono fondamentali per identificare binari che sono stati cancellati o sostituiti mentre il processo era ancora in esecuzione (un classico segnale da cercare dopo un aggiornamento di sicurezza mal gestito).

/proc/PID/oom_score e oom_score_adj — il punteggio che l’OOM killer del kernel usa per decidere quale processo terminare per primo in caso di esaurimento memoria. oom_score_adj, con un range da -1000 a 1000, permette di proteggere o “sacrificare” volontariamente un processo specifico.

Due scorciatoie tornano utili spesso: /proc/self/ punta sempre al processo che sta effettuando la lettura, mentre /proc/$$/ punta alla shell corrente all’interno di uno script.

Casi pratici di troubleshootingTrovare quale processo ha in ascolto una determinata porta (qui la porta 443/0x01BB su IPv6), senza usare ss o lsof:

inode=$(awk '$2 ~ /:01BB$/ {print $10; exit}' /proc/net/tcp6)
ls -l /proc/*/fd/ 2>/dev/null | grep "socket:[$inode]"Individuare processi che tengono aperti file già cancellati — una causa classica di dischi che risultano pieni pur senza file visibili, perché lo spazio non viene liberato finché il file descriptor resta aperto:

find /proc/*/fd -ls 2>/dev/null | grep '(deleted)'Ispezionare i contatori di interrupt per CPU, utile per diagnosticare squilibri di IRQ affinity su macchine multi-core:

cat /proc/interrupts | head -20/proc/sys e il tuning via sysctlSotto /proc/sys/ si trovano i file scrivibili che espongono i tunable del kernel — la stessa interfaccia usata da sysctl. Ad esempio, per modificare a caldo la propensione del kernel allo swap:

echo 10 | sudo tee /proc/sys/vm/swappinessTra i tunable più comuni: vm.swappiness (0-200, propensione allo swap), net.ipv4.ip_forward (abilitazione dell’IP forwarding), net.core.somaxconn (backlog massimo per i socket in ascolto) e fs.file-max (limite di file descriptor a livello di sistema). Ricordiamo che le modifiche fatte così sono volatili: per renderle permanenti serve intervenire su /etc/sysctl.conf o su un file in /etc/sysctl.d/.

/proc dentro i containerUn punto che genera spesso confusione: /proc è namespace-aware. Dentro un container Docker, la directory mostra il namespace PID del container, non quello dell’host — il PID 1 visto dall’interno è l’entrypoint del container, non l’init dell’host. Attenzione però: campi come quelli di /proc/meminfo o /proc/stat spesso riflettono ancora i totali dell’host e non i limiti imposti dai cgroup al container, un dettaglio che ha tratto in inganno più di un tool di monitoring scritto ingenuamente.

/proc contro /sys: quando usare cosa/sys (sysfs) è il filesystem virtuale complementare a /proc, ma orientato al modello dei dispositivi del kernel: driver, bus, block device, gestione dell’energia. Un esempio tipico è /sys/devices/system/cpu/cpu0/cpufreq/, che espone i parametri di scaling della frequenza per singolo core. La regola pratica: /proc per processi e stato del kernel a livello di sistema, /sys per configurazione e stato dei dispositivi hardware.

ConclusioneConoscere /proc non è un esercizio accademico: è uno degli strumenti diagnostici più potenti a disposizione di un sistemista Linux, proprio perché sta sotto ogni tool di monitoring che si finisce per usare quotidianamente. Quando top, free o netstat non bastano — o semplicemente non sono installati sulla macchina compromessa o minimale su cui ci si trova a lavorare — sapere leggere direttamente /proc/meminfo, /proc/PID/status o /proc/net/tcp fa la differenza tra un troubleshooting rapido e ore perse a indovinare. Vale la pena tenere a portata di mano, come riferimento minimo, i file /proc/meminfo, /proc/cpuinfo, /proc/stat, /proc/net/dev e la struttura di /proc/PID/: coprono la stragrande maggioranza dei casi reali di debugging su sistemi in produzione.

Fonte originale: A Guide to Linux /proc Filesystem, LinuxBlog.io

Chi gestisce uno stack LEMP o LAMP in produzione conosce bene il dilemma: PHP-FPM va lasciato “respirare” con un process manager dinamico, oppure conviene bloccare tutto su un numero fisso di worker? La risposta non è scontata, e sbagliarla ha un costo diretto in latenza durante i picchi di traffico. Vediamo perché, per molti carichi di lavoro, pm static è la scelta più solida — e come calcolare i parametri giusti senza affidarsi a numeri presi a caso da qualche post su Stack Overflow.

I tre process manager di PHP-FPMPHP-FPM gestisce i processi worker attraverso la direttiva pm nel file di pool (tipicamente /etc/php/8.x/fpm/pool.d/www.conf), che può assumere tre valori:

dynamic: il numero di processi figlio oscilla tra pm.min_spare_servers e pm.max_spare_servers, fino al tetto di pm.max_children. È il default su molte distribuzioni ed è pensato per bilanciare consumo di RAM e capacità di risposta.

ondemand: i processi vengono creati solo quando arriva una richiesta e vengono terminati dopo pm.process_idle_timeout secondi di inattività. Nessun worker “a riposo” occupa memoria, ma ogni nuovo processo comporta un fork che ha un costo in latenza.

static: il numero di worker è fissato esattamente a pm.max_children, tutti avviati all’avvio del servizio e mai terminati. Nessun fork a runtime, nessuna sorpresa.

La differenza pratica tra dynamic/ondemand e static si vede sotto carico: ogni volta che PHP-FPM deve forkare un nuovo processo per rispondere a un picco di richieste, quel fork costa tempo di CPU e, sotto pressione, può accodare le richieste in ingresso nel socket backlog. Su un server che serve traffico costante e prevedibile, questo overhead è puro spreco.

Perché “dynamic” può ingannareIl process manager dinamico sembra la scelta “intelligente” perché si adatta al carico. In realtà introduce una variabile in più proprio nei momenti in cui non la vorresti: durante un picco di traffico, quando i worker spare non bastano più, PHP-FPM deve forkarne di nuovi mentre il sistema è già sotto stress. Il risultato è un aumento di latenza percepibile negli access log, spesso confuso con un problema del database o del codice applicativo quando in realtà è il process manager stesso a introdurre il collo di bottiglia.

Quando usare pm staticLa regola pratica è semplice: se il server ha traffico sostenuto e memoria sufficiente per tenere tutti i worker sempre attivi, static è la scelta giusta. Se invece si gestiscono più pool PHP-FPM su un host condiviso con memoria limitata (tipico di ambienti multi-tenant o hosting condiviso), ondemand resta preferibile perché libera RAM quando il traffico cala.

; /etc/php/8.3/fpm/pool.d/www.conf
pm = static
pm.max_children = 40
pm.max_requests = 1000
Da notare pm.max_requests: anche in modalità static conviene non lasciarlo a 0 (illimitato). Un valore alto — 1000 richieste è un buon punto di partenza — fa sì che ogni worker venga riciclato periodicamente, mitigando eventuali memory leak nelle librerie PHP senza introdurre l’overhead di respawn continui tipico della modalità dinamica.

Come calcolare pm.max_children senza indovinareIl valore corretto di pm.max_children dipende da quanta RAM è disponibile e da quanta ne consuma mediamente un singolo worker PHP-FPM — un dato che varia moltissimo in base al framework (un’app Symfony con Doctrine pesa parecchio di più di uno script WordPress minimale).

Per misurare il consumo medio reale dei worker già in esecuzione:

ps --no-headers -o rss -C php-fpm8.3 | awk '{ sum += $1; n++ } END { print sum/n/1024 " MB" }'Questo comando interroga la RSS (Resident Set Size) di tutti i processi php-fpm attivi e ne calcola la media in MB. Con quel numero in mano, la formula diventa:

pm.max_children = (RAM dedicata a PHP-FPM in MB) / (RSS medio per worker in MB)Ad esempio, su un server con 6 GB di RAM riservati al pool PHP-FPM e worker che consumano in media 60 MB ciascuno:

6000 MB / 60 MB ≈ 100 workerÈ fondamentale non allocare a PHP-FPM tutta la RAM disponibile sulla macchina: bisogna lasciare margine per il sistema operativo, il web server (Nginx o Apache in front-end), la cache degli oggetti (Redis/Memcached) e, se presente sullo stesso host, il database. Una regola prudente è dedicare a PHP-FPM non più del 60-70% della RAM totale su un server dedicato al solo stack web.

Monitoraggio continuo, non solo calcolo una tantumIl consumo medio per worker cambia nel tempo — un deploy che introduce una libreria pesante, una query N+1 che gonfia il footprint di memoria, o semplicemente un aumento del traffico su endpoint più complessi. Vale la pena schedulare periodicamente il comando ps sopra (ad esempio via cron con output su un file di log, oppure integrandolo in un dashboard di monitoring come Netdata o Prometheus con node_exporter) per verificare che il valore di pm.max_children resti coerente con la realtà, invece di scoprirlo durante un incidente in produzione.

Un altro segnale da tenere d’occhio è il log di PHP-FPM stesso: se compaiono righe del tipo

WARNING: [pool www] server reached pm.max_children setting (40), consider raising itsignifica che il tetto è stato raggiunto e le richieste in eccesso stanno finendo in coda sul socket, con conseguente aumento del tempo di risposta. È il segnale più diretto per capire se il dimensionamento fatto a tavolino regge davvero sotto carico reale.

ConclusioneNon esiste un process manager “giusto” in assoluto: la scelta dipende dal profilo di traffico e dalla disponibilità di memoria. Ma per la maggior parte dei server di produzione con traffico prevedibile e risorse dedicate, pm static abbinato a un pm.max_children calcolato sul consumo reale di RSS — e non copiato da un tutorial generico — elimina una fonte di latenza spesso invisibile finché non arriva il picco di traffico che la rende evidente. Vale la pena rivedere la configurazione dei propri pool PHP-FPM con questo approccio, misurando prima di decidere.

Fonte: LinuxBlog.io — PHP-FPM tuning: Using ‘pm static’ for max performance

Il problema che Agent Plugins 1.0 prova a risolvereChi lavora quotidianamente con GitHub Copilot conosce bene la frammentazione degli ultimi due anni: skill scritte per VS Code che non funzionano su Copilot CLI, configurazioni MCP duplicate tra client diversi, agenti custom da ricostruire da zero ogni volta che si cambia strumento. Con Agent Plugins 1.0, annunciato a metà agosto 2026, GitHub prova a chiudere questa frammentazione introducendo uno standard aperto — non un formato proprietario — per pacchettizzare skill e server MCP in un plugin installabile una sola volta e utilizzabile su più superfici: VS Code, Copilot CLI, Copilot SDK, l’app Copilot e il coding agent cloud.

È un cambio di prospettiva interessante anche per chi non usa Copilot come strumento principale: la specifica Agent Plugins non è un’invenzione isolata, ma converge con formati simili già visti in altri ecosistemi (Claude, OpenPlugin), e questo la rende rilevante per chiunque costruisca strumenti per agenti AI, non solo per i team Microsoft/GitHub.

Anatomia di un Agent PluginUn plugin conforme allo standard 1.0 è una directory con una struttura riconoscibile. Il file centrale è plugin.json, che dichiara esplicitamente lo schema a cui aderisce:

{
"$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
"name": "my-dev-tools",
"description": "Utility per lo sviluppo React",
"version": "1.2.0"
}I soli campi obbligatori sono $schema e name; tutto il resto (version, description, author, homepage, repository, license, keywords) è opzionale ma consigliato per la pubblicazione su un marketplace.

Attorno al manifest, la struttura tipica di un plugin più completo è questa:

my-testing-plugin/
plugin.json # Metadati del plugin
skills/
test-runner/
SKILL.md # Istruzioni della skill
run-tests.sh # Script di supporto
agents/
test-reviewer.agent.md # Agente custom (client-specific)
hooks/
hooks.json # Configurazione hook (client-specific)
scripts/
validate-tests.sh
.mcp.json # Definizione dei server MCPLa distinzione più importante per chi progetta un plugin è tra componenti portabili e componenti client-specific:

Portabili (parte dello standard 1.0): server MCP (integrazioni con tool esterni) e skill, cioè istruzioni, script e risorse caricate on-demand dall’agente.

Client-specific (solo VS Code, ad esempio): agenti custom con personalità e configurazione tool dedicata, hook che eseguono comandi shell in punti precisi del ciclo di vita dell’agente, e slash command richiamabili in chat con /.

Questa separazione è la vera innovazione pratica: uno stesso plugin può portare le sue skill e i suoi server MCP ovunque, mentre le personalizzazioni specifiche di un client restano lì dove hanno senso, senza rompere la compatibilità altrove.

Configurare i server MCP dentro un pluginI server MCP si dichiarano in .mcp.json (o mcp.json), con variabili d’ambiente che il runtime dell’agente risolve automaticamente al momento del caricamento:

{
"mcpServers": {
"plugin-database": {
"command": "${PLUGIN_ROOT}/servers/db-server",
"args": ["--config", "${PLUGIN_ROOT}/config.json"],
"env": {
"DB_PATH": "${PLUGIN_ROOT}/data"
}
}
}
}La variabile ${PLUGIN_ROOT} punta sempre alla directory del plugin installato, indipendentemente da dove l’utente finale lo abbia scaricato — un dettaglio che elimina un’intera classe di bug legati a percorsi assoluti hardcoded nei plugin distribuiti da terze parti.

Hook: automazioni sul ciclo di vita dell’agentePer i client che supportano questa estensione (il formato è compatibile con la sintassi già nota da Claude), gli hook permettono di agganciare comandi shell a eventi specifici, ad esempio dopo l’uso di un tool:

{
"hooks": {
"PostToolUse": [
{
"type": "command",
"command": "${PLUGIN_ROOT}/scripts/format.sh"
}
]
}
}Un caso d’uso concreto: formattare automaticamente il codice generato dall’agente subito dopo ogni modifica a un file, senza dover ricordare di lanciare il linter manualmente.

Migrare un plugin Copilot esistenteChi ha già plugin Copilot “vecchio formato” non deve riscrivere nulla da zero. GitHub descrive un percorso di migrazione minimo:

Aggiungere il campo $schema al plugin.json esistente, puntandolo allo schema Agent Plugins 1.0.

Mantenere le skill dove sono già, sotto skills/.

Spostare i file specifici di Copilot (agenti, comandi, regole, hook, canvas) dentro una directory dedicata com.github.copilot/, così da separarli chiaramente dalla parte portabile.

I plugin GitHub Copilot esistenti restano comunque supportati senza obbligo di migrazione: è un aggiornamento incrementale, non un breaking change forzato.

Governance aziendale: managed-settings.jsonPer i team enterprise, probabilmente l’aspetto più rilevante non è la portabilità in sé ma il controllo centralizzato che ne deriva. Il file managed-settings.json permette di definire una baseline aziendale su cosa è installabile:

{
"extraKnownMarketplaces": {
"company-tools": {
"source": { "source": "github", "repo": "vostra-org/plugin-marketplace" }
}
},
"enabledPlugins": {
"code-formatter@company-tools": true
}
}Tre leve principali:

enabledPlugins — installa automaticamente o blocca esplicitamente plugin specifici per tutti gli utenti gestiti.

extraKnownMarketplaces — aggiunge marketplace interni oltre a quelli pubblici di default.

strictKnownMarketplaces — se attivato, limita l’installazione ai soli marketplace esplicitamente autorizzati, impedendo l’uso di sorgenti non gestite.

Le impostazioni enterprise agiscono come baseline additiva: i team possono comunque aggiungere plugin approvati sopra la configurazione centrale, senza però poter aggirare i blocchi imposti a livello organizzativo. Per chi gestisce flotte di sviluppatori con policy di sicurezza stringenti, è la differenza tra “confidare che ognuno installi solo cose sicure” e avere un controllo verificabile.

Dove si installano i pluginIl canale di scoperta di default è l’Awesome Copilot marketplace, disponibile fin da subito in VS Code, Copilot CLI e nell’app Copilot. Per plugin locali o in sviluppo, VS Code offre una registrazione esplicita via impostazioni:

"chat.pluginLocations": {
"/percorso/al/mio-plugin": true,
"/percorso/a/un-altro-plugin": false
}Un dettaglio utile in fase di debug: se un plugin non viene rilevato, vale la pena controllare che chat.plugins.enabled sia attivo, che il nome nel manifest sia in kebab-case (obbligatorio per lo standard 1.0), e — per problemi di installazione persistenti — ripulire la cache locale in ~/.config/Code/agentPlugins/ su Linux.

ConclusioneAgent Plugins 1.0 non introduce funzionalità radicalmente nuove rispetto a quello che skill e server MCP già facevano singolarmente: il suo valore è nella standardizzazione del confezionamento e nella governance che ne deriva. Per un team che sviluppa strumenti interni per i propri agenti AI — che siano skill per il debug, integrazioni con sistemi proprietari via MCP, o automazioni sul ciclo di vita dell’agente — poter scrivere il plugin una sola volta e vederlo funzionare su CLI, editor e SDK senza riscritture è un risparmio di manutenzione concreto, non solo un dettaglio architetturale. Vale la pena tenerlo d’occhio anche per chi non usa Copilot: essendo uno standard aperto, è probabile che altri agent tool ne adottino la compatibilità nei prossimi mesi.

Fonte: Agent Plugins 1.0 in VS Code, Copilot CLI, and the Copilot app — GitHub Changelog

Perché la risoluzione DNS su Linux è più complicata di quanto sembriChiunque amministri server Linux prima o poi si scontra con il fastidioso “Temporary failure in name resolution” o con un DNS che risolve alcuni domini e non altri. La causa quasi sempre non è il DNS in sé, ma la catena di componenti che sta tra un comando come curl e la vera query verso un nameserver: /etc/nsswitch.conf, /etc/resolv.conf, e — sulle distribuzioni moderne — systemd-resolved o NetworkManager che gestiscono tutto al posto nostro, spesso silenziosamente.

In questo articolo ricostruiamo l’intera catena di risoluzione dei nomi su Linux, i comandi giusti per ispezionarla e un metodo pratico per isolare il problema in pochi minuti, invece di procedere per tentativi.

L’ordine di risoluzione: nsswitch.confIl primo file da guardare non è resolv.conf, ma /etc/nsswitch.conf. La riga che interessa è quella che inizia con hosts:, tipicamente:

hosts: files dns myhostnameQuesto significa che il sistema consulta prima /etc/hosts (voce files), poi il DNS, e infine risolve il proprio hostname locale. Se un dominio dovrebbe risolvere correttamente ma non lo fa, e in /etc/hosts c’è una voce residua o sbagliata, il DNS non c’entra affatto: la query non arriva nemmeno a un resolver.

Chi gestisce davvero /etc/resolv.confSulle distribuzioni Linux di qualche anno fa, /etc/resolv.conf era un file statico che si editava a mano. Da Ubuntu 18.04 in poi, e su gran parte delle distribuzioni moderne (Fedora, molte immagini cloud di Debian/RHEL), quel file è generato dinamicamente — modificarlo a mano spesso non produce alcun effetto persistente, perché viene sovrascritto al prossimo evento di rete.

Il modo più veloce per capire chi ha il controllo è guardare cosa punta il file:

ls -la /etc/resolv.confSe è un file regolare, probabilmente la configurazione è statica.

Se è un symlink verso /run/systemd/resolve/stub-resolv.conf, il sistema usa systemd-resolved.

Se punta a /run/NetworkManager/resolv.conf, è NetworkManager a gestire il DNS.

Sapere quale dei due componenti è “al comando” evita l’errore più comune: editare resolv.conf a mano, vederlo funzionare per pochi secondi, e poi ritrovarsi la modifica cancellata al riavvio dell’interfaccia di rete.

Il formato di resolv.confnameserver 1.1.1.1
nameserver 8.8.8.8
search example.com
options ndots:5Alcuni dettagli spesso ignorati ma rilevanti in produzione:

nameserver — Linux ne considera al massimo tre; gli altri vengono ignorati.

search — suffisso di dominio aggiunto automaticamente a hostname “corti” (senza punti o con pochi punti).

options ndots:5 — controlla quando un nome viene considerato “già qualificato” e quando invece riceve il suffisso di search. È un parametro che in ambienti Kubernetes causa non pochi grattacapi, perché una query con pochi punti può generare fino a 5 lookup DNS prima di andare a buon fine.

systemd-resolved: il resolver locale che (quasi) nessuno vedeSulla maggior parte delle distribuzioni moderne, le query DNS delle applicazioni non vanno direttamente a Internet: passano per un listener locale su 127.0.0.53:53, gestito da systemd-resolved, che si occupa di caching e — dove configurato — di DNSSEC. Lo strumento per interagirci è resolvectl.

Stato completo per interfaccia

resolvectl status

Query esplicita tramite systemd-resolved

resolvectl query esempio.it

Svuotare la cache (utile dopo un cambio DNS o un test)

sudo resolvectl flush-caches

Statistiche su cache hit/miss

resolvectl statisticsPer impostare server DNS validi per l’intero sistema, indipendentemente dall’interfaccia attiva, si edita /etc/systemd/resolved.conf:

[Resolve]
DNS=1.1.1.1 1.0.0.1
FallbackDNS=8.8.8.8 8.8.4.4e si riavvia il servizio:

sudo systemctl restart systemd-resolveddig, getent e la differenza che fa risparmiare ore di debugIl tool principale per interrogare direttamente un server DNS è dig (pacchetto dnsutils su Debian/Ubuntu, bind-utils su Fedora/RHEL):

dig esempio.it
dig @8.8.8.8 esempio.it # interroga un resolver specifico
dig esempio.it MX # record di posta
dig esempio.it AAAA # IPv6
dig esempio.it NS # nameserver autoritativi
dig -x 104.21.1.1 # reverse lookup
dig +short esempio.it # output compatto
dig +trace esempio.it # ricostruisce l'intera catena, dai root server in giù
dig +dnssec esempio.it # verifica la firma DNSSECIl punto chiave, spesso sottovalutato: dig ignora completamente /etc/nsswitch.conf e /etc/hosts. Parla direttamente con un server DNS. Questo lo rende perfetto per isolare i problemi, ma pericoloso se usato come unico strumento diagnostico: dig può funzionare perfettamente mentre l’applicazione continua a fallire, perché il problema è nel percorso NSS (Name Service Switch), non nel DNS.

Per replicare esattamente quello che fa un’applicazione, si usa getent:

getent hosts esempio.itSe dig funziona ma getent no, il problema non è di rete: è nella configurazione NSS, in /etc/hosts, o nel modulo myhostname. È una distinzione che vale la pena memorizzare, perché sposta immediatamente l’indagine nella direzione giusta.

Un metodo, non solo comandi: la checklist di troubleshootingDi fronte a un errore di risoluzione, seguire un ordine preciso evita di girare a vuoto:

Controllare che /etc/resolv.conf contenga un nameserver valido e capire chi lo gestisce (ls -la).

Verificare che /etc/nsswitch.conf includa dns nella riga hosts.

Testare un resolver pubblico direttamente: dig @1.1.1.1 google.com. Se funziona, la rete verso l’esterno è a posto.

Testare il resolver locale: dig google.com. Se qui fallisce ma il passo precedente no, il problema è nella configurazione locale (systemd-resolved, NetworkManager, o un resolver aziendale irraggiungibile).

Controllare lo stato del servizio: systemctl status systemd-resolved.

Guardare gli assegnamenti DNS per interfaccia con resolvectl status — particolarmente utile in scenari con VPN e split-DNS.

Svuotare la cache con resolvectl flush-caches se si sospettano record stale.

Confrontare dig e getent: se divergono, il problema è nel percorso NSS.

Per fallimenti persistenti e inspiegabili, dig +trace ricostruisce l’intera catena di delega dai root server fino all’autoritativo, rivelando problemi come delegazioni NS rotte o glue record mancanti.

Split-DNS e VPN: un caso che confonde moltiCon una VPN aziendale attiva, resolvectl status mostra a quale interfaccia è associato ciascun dominio DNS. Se il dominio associato al link VPN è ~., quell’interfaccia diventa la route DNS predefinita per tutte le query. Se invece è qualcosa come ~interna.azienda.it, solo le query per quel dominio specifico vengono instradate sul tunnel — le altre continuano a passare per il resolver pubblico. Non riconoscere questa differenza è una causa frequente di “il sito interno non si risolve, ma internet funziona” o viceversa.

Fissare un DNS statico senza che venga sovrascrittoSu sistemi gestiti da NetworkManager, il modo corretto non è editare resolv.conf ma dire a NetworkManager di non sovrascrivere le impostazioni manuali:

nmcli con mod "Wired connection 1" ipv4.dns "1.1.1.1 8.8.8.8"
nmcli con mod "Wired connection 1" ipv4.ignore-auto-dns yes
nmcli con up "Wired connection 1"Su sistemi con systemd-resolved, la via pulita è impostare DNS= e FallbackDNS= in resolved.conf, come visto sopra. Solo come ultima risorsa — ad esempio su container minimali senza questi servizi — ha senso rendere resolv.conf immutabile:

sudo chattr +i /etc/resolv.conf # blocca il file
sudo chattr -i /etc/resolv.conf # sblocca per un aggiornamento futuroQuale resolver sceglierePer server in produzione, affidarsi al solo router di casa/ufficio è rischioso: se il router si blocca o si riavvia, cade anche la risoluzione DNS di tutti i servizi a valle. Tra i resolver pubblici più usati in ambito professionale: Cloudflare (1.1.1.1 / 1.0.0.1, orientato a bassa latenza e privacy), Google (8.8.8.8 / 8.8.4.4, rete anycast molto ridondata) e Quad9 (9.9.9.9, che filtra domini noti per malware già a livello di resolver).

ConclusioneLa risoluzione DNS su Linux non è un singolo componente ma una catena — NSS, resolv.conf, systemd-resolved o NetworkManager, e infine il resolver remoto. La maggior parte dei problemi “misteriosi” si risolve rapidamente se si segue la catena nell’ordine giusto invece di riavviare servizi a caso. Tenere a mente la differenza tra dig (parla direttamente col DNS) e getent (replica il percorso reale delle applicazioni) è probabilmente il singolo accorgimento che fa risparmiare più tempo in debug.

Fonte: Linux Nameservers and DNS Resolution — LinuxBlog.io

Il problema degli agenti AI che “guardano” il browserChi ha provato a far navigare un agente AI su un sito web sa quanto sia fragile il paradigma attuale: screenshot della pagina, analisi visiva per capire dove cliccare, simulazione del click, nuovo screenshot per verificare cosa è successo, e via così ad ogni passaggio. Funziona, ma è lento, costoso in token e si rompe alla prima modifica del layout o al primo elemento che carica in ritardo. È lo stesso problema che affligge da anni gli script di web scraping tradizionali, solo applicato ad agenti che devono anche “capire” cosa stanno guardando.

WebMCP (Web Model Context Protocol) nasce per rovesciare questo approccio: invece di far indovinare all’agente dove cliccare, è il sito stesso a dichiarare quali azioni sono disponibili, con che parametri, e come invocarle direttamente in codice. Cloudflare ha da poco reso disponibile il supporto sperimentale a WebMCP nella sua piattaforma Browser Run, un’occasione utile per capire come funziona davvero questo standard ancora in bozza.

Cos’è WebMCP e chi lo sta sviluppandoLa proposta iniziale è stata pubblicata nell’agosto 2025 da ingegneri di Microsoft e Google, e oggi è portata avanti principalmente dal team Chrome come bozza sperimentale — non è ancora uno standard web consolidato, ma è già implementabile e testabile in Chrome beta. L’idea centrale è una nuova API del browser, navigator.modelContext, che qualsiasi pagina web può usare per registrare “tool” strutturati, nello stesso spirito del Model Context Protocol usato da Claude e altri assistenti per esporre funzionalità a un LLM — solo che qui il “server” MCP è JavaScript in esecuzione lato pagina, e l’host è il browser stesso.

navigator.modelContext.registerTool({
name: "scroll_to_section",
description: "Scorre la pagina fino a una sezione specifica",
inputSchema: {
type: "object",
properties: { id: { type: "string" } },
required: ["id"]
},
async execute({ id }) {
document.getElementById(String(id))?.scrollIntoView({ behavior: "smooth" });
return "ok";
}
});Un agente che visita la pagina può interrogare l’elenco dei tool disponibili in un dato momento — che cambia dinamicamente in base allo stato della pagina — ed eseguirli con parametri tipizzati, invece di simulare interazioni DOM.

Provarlo con Cloudflare Browser RunCloudflare ha aggiunto un pool sperimentale di sessioni browser con Chrome beta (dove WebMCP è disponibile) alla sua piattaforma Browser Run, separato dal pool di produzione che resta su Chrome stabile. Per avviare una sessione di test basta la CLI wrangler:

assicurarsi di avere l'ultima versione di wrangler

npm i -g wrangler@latest

creare una sessione browser "lab" con keep-alive di 5 minuti

wrangler browser create --lab --keepAlive 300Dalla console DevTools della sessione si può interrogare direttamente l’elenco dei tool esposti da un sito che implementa WebMCP (Cloudflare fornisce come demo pubblica una finta catena di hotel):

navigator.modelContextTesting.listTools();
// [
// { "name": "view_hotel", "description": "...", "inputSchema": "..." },
// { "name": "search_location", "description": "...", "inputSchema": "..." },
// { "name": "lookup_amenity", "description": "...", "inputSchema": "..." }
// ]Eseguire un tool è altrettanto diretto:

await navigator.modelContextTesting.executeTool(
"search_location",
JSON.stringify({ query: "Paris" })
);Un dettaglio interessante per chi progetta flussi che coinvolgono azioni sensibili (pagamenti, prenotazioni, conferme): la specifica prevede nativamente lo human-in-the-loop. Un tool come complete_booking può sospendere l’esecuzione in attesa che l’utente confermi manualmente un’azione nell’interfaccia, prima di restituire il risultato all’agente.

Collegare un agente AI realePer far interagire un vero agente con siti WebMCP, Cloudflare consiglia di appoggiarsi a Chrome DevTools MCP, configurabile in client come Claude Code o Cursor puntando al WebSocket endpoint della sessione lab:

{
"browser-rendering-cdp": {
"command": [
"npx", "-y", "chrome-devtools-mcp@latest",
"--wsEndpoint=wss://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/devtools/browser?keep_alive=600000&lab=true",
"--wsHeaders={"Authorization":"Bearer <CLOUDFLARE_API_TOKEN>"}"
]
}
}Il parametro lab=true è ciò che instrada la connessione verso una sessione con WebMCP abilitato invece che verso il pool di produzione standard.

Il lato server: esporre i tool di un Worker al browserPer chi già costruisce agenti su Cloudflare Workers usando McpAgent, il pacchetto agents include un adapter sperimentale, registerWebMcp, che fa da ponte tra i tool esposti da un server MCP remoto e il registro navigator.modelContext della pagina:

import { registerWebMcp } from "agents/experimental/webmcp";

const handle = await registerWebMcp({
url: "/mcp",
prefix: "remote.",
getHeaders: async () => ({ Authorization: Bearer ${await getToken()} })
});L’adapter scopre i tool del server (tools/list), li registra come shim locali il cui execute inoltra la chiamata al server via client.callTool(), e si mantiene sincronizzato ascoltando le notifiche tools/list_changed. Il risultato pratico è una separazione naturale: tutto ciò che riguarda il DOM (scorrimento, focus, clipboard, stato locale in Zustand o IndexedDB) resta tool in-page; tutto ciò che richiede storage durevole, credenziali segrete o chiamate a API di terze parti resta lato server, ma diventa comunque visibile e invocabile dall’AI del browser attraverso lo stesso registro.

Cosa considerare prima di adottarloVale la pena essere chiari sulla maturità dello standard: le API navigator.modelContext e navigator.modelContextTesting funzionano oggi solo in sessioni Chrome beta o “lab”, non in produzione stabile, e sia la specifica sia l’adapter di Cloudflare sono etichettati esplicitamente come sperimentali, soggetti a modifiche non retrocompatibili. Sul fronte sicurezza, esporre tool strutturati a un agente terzo significa anche esporre una superficie potenzialmente sfruttabile — collisioni di nomi tra tool silenziose, o un agente compromesso che invoca un tool con parametri malevoli, sono scenari da considerare al pari di qualsiasi altra API pubblica. Per chi sviluppa siti pensati per essere “agent-friendly” — e-commerce, prenotazioni, dashboard SaaS — è comunque il momento giusto per iniziare a sperimentare, prima che il pattern diventi lo standard de facto per l’interazione tra agenti AI e web.

ConclusioneWebMCP propone un cambio di paradigma sensato: far dichiarare alle applicazioni web le proprie capacità in modo strutturato, invece di costringere gli agenti AI a reverse-engineering visivo dell’interfaccia. Non è ancora pronto per la produzione, ma la direzione — supportata sia da Google sia da Microsoft, e ora testabile concretamente su Cloudflare Browser Run — merita di essere seguita da chi sviluppa applicazioni web che prima o poi dovranno “parlare” anche con un agente, non solo con un umano davanti a un browser.

Fonte: Cloudflare Browser Run Docs – WebMCP e Cloudflare Agents – WebMCP adapter

Con la versione 2.1.224, rilasciata la prima settimana di agosto 2026, Claude Code introduce la messaggistica tra sessioni: due o più istanze del CLI, avviate in terminali diversi, possono ora scambiarsi messaggi di testo senza che sia l’utente a fare da tramite copiando e incollando contesto da un terminale all’altro. È una funzionalità pensata per chi lavora abitualmente con più sessioni parallele su worktree diversi dello stesso repository, e merita attenzione anche solo per capire come configurarla in modo sicuro in un contesto aziendale.

Il problema che risolveChi #usa Claude Code su progetti complessi finisce spesso per aprire più terminali: uno per il lavoro principale, uno per un hotfix urgente, uno per un refactoring in un worktree separato. Fino a v2.1.223 l’unico modo per far sapere a una sessione cosa stava succedendo in un’altra era manuale: copiare un riassunto, incollarlo, ripetere il contesto. La messaggistica cross-session automatizza esattamente questo passaggio.

Due strumenti nuovi: ListAgents e SendMessageClaude Code espone due tool interni che il modello usa autonomamente, senza che l’utente li invochi direttamente:

ListAgents individua le sessioni raggiungibili: subagent nella sessione corrente, altre sessioni locali sulla stessa macchina (incluse quelle in background) e sessioni remote se è attiva la Remote Control.

SendMessage consegna un messaggio di testo a una sessione specifica, identificata per nome.

Il messaggio non è mai la cronologia della conversazione né un file: è un testo che una Claude scrive per un’altra Claude. Per spostare davvero un intero contesto conversazionale tra terminali resta lo strumento giusto il resume di sessione, non la messaggistica.

Per vedere quali sessioni sono raggiungibili basta lanciare, in un terminale con Claude Code attivo:

/list-agentsIl comando elenca ogni sessione con il nome a cui risponde (derivato dalla cartella di lavoro, oppure impostato con /rename o il flag --name), utile per distinguere sessioni omonime che girano in directory diverse.

Come si usa in praticaNon si compone il messaggio a mano: si dice a Claude cosa si vuole che l’altra sessione sappia, ed è Claude a scrivere il riassunto effettivo. Due esempi di prompt tipici:

Chiedi alla sessione nell'altro terminale se la migrazione è terminataSpiega alla sessione che lavora sulle API di pagamento cosa abbiamo appena cambiatoNel secondo caso il contenuto esatto del messaggio varia: è Claude a decidere come riassumere il lavoro fatto. Quando il messaggio arriva, compare nella conversazione della sessione ricevente con il nome del mittente, e viene compattato in una riga Message from che si espande con Ctrl+O.

Dove viaggia il messaggioIl percorso dipende da dove gira la sessione di destinazione:

Stessa macchina: il messaggio passa attraverso un socket per-sessione, mai attraverso i server Anthropic. In questo caso sono possibili sia nuovi messaggi sia risposte.

Altra macchina dell’utente: il messaggio passa dai server Anthropic e arriva tramite la connessione Remote Control di quella macchina. Da qui è possibile solo rispondere, non avviare una conversazione.

Claude Code on the #web: stesso discorso, solo risposte.

Ogni sessione si registra su disco e apre un proprio “inbox socket”: due sessioni si trovano a vicenda solo se vedono lo stesso filesystem, il che significa che una sessione dentro un #container e una sull’host non possono raggiungersi, mentre due sessioni nello stesso container sì.

Controllo dei messaggi in arrivoPer un uso in ambienti con requisiti di governance, il parametro di configurazione rilevante è crossSessionInbound, impostabile su tre valori:

{
"crossSessionInbound": "accept"
}accept: ogni messaggio viene consegnato direttamente.

hold: Claude Code mostra un avviso ma non consegna nulla, finché l’utente non approva.

refuse: il messaggio viene scartato senza notifica al destinatario.

Quando non è impostato alcun valore, Claude Code decide messaggio per messaggio in base alla modalità di permessi delle due sessioni: se la sessione ricevente richiede conferma per i permessi, il messaggio viene consegnato; se la sessione ricevente salta le conferme (modalità bypassPermissions), il messaggio viene messo in attesa di approvazione, a meno che anche il mittente dichiari di essere in bypass.

Per richiedere sempre un’approvazione esplicita prima che un messaggio lasci la macchina locale, si può impostare:

{
"isolatePeerMachines": true
}Per disattivare del tutto la funzionalità a livello di organizzazione, nelle managed settings:

{
"permissions": {
"deny": ["SendMessage", "ListAgents"]
},
"crossSessionInbound": "refuse"
}Cosa una sessione remota non può fareUn messaggio in arrivo da un’altra sessione non equivale mai al consenso dell’utente: non può approvare un prompt di permesso in sospeso, non può modificare impostazioni di permessi o il file CLAUDE.md, ed eventuali comandi contenuti nel testo (ad esempio /compact) vengono trattati come testo normale, mai eseguiti. Se agire sul messaggio richiede un permesso che la sessione ricevente non ha, scatta comunque il prompt standard.

I limiti attualiLa limitazione più rilevante per chi lavora su #Windows: la messaggistica cross-session funziona su macOS e #Linux, inclusa una sessione Linux dentro WSL 2, ma non su Windows nativo. È inoltre assente su Amazon Bedrock, Claude Platform su #AWS, #Google #Cloud Agent Platform e Microsoft Foundry. Restano infine due limiti strutturali: i messaggi sono solo testo semplice (i protocolli strutturati degli agent team restano interni al team) e i loop di messaggi vengono limitati automaticamente, con un massimo di 50 messaggi accettati in attesa di lettura per sessione.

Quando ha senso usarlaLa documentazione ufficiale indica quattro casi d’uso principali: passare un finding da una sessione a un’altra dopo una scoperta rilevante, coordinare worktree paralleli sullo stesso repository, far riportare lo stato di un’operazione lunga (una migrazione, una suite di test) alla sessione che la sta monitorando, e rispondere a messaggi arrivati da sessioni su altre macchine o dal web. Per chi lavora già con più terminali aperti sullo stesso progetto, è una funzione che elimina una frizione reale, a patto di capire bene i default di crossSessionInbound prima di usarla in un ambiente con permessi sensibili.

Fonte: documentazione ufficiale Claude Code – Cross-session messaging.

Perché le password su SSH sono ormai un rischio da eliminareSe gestisci anche un solo server Linux esposto su Internet, i log di /var/log/auth.log te lo confermano ogni giorno: bot e botnet tentano continuamente il login SSH via password, in modalità brute-force o credential stuffing. Una password, per quanto complessa, resta un segreto condiviso che può essere intercettato, indovinato o riutilizzato da un attaccante che l’ha ottenuta altrove. L’autenticazione a chiave pubblica elimina questo vettore alla radice: il server non conosce mai un segreto trasmissibile, ma verifica solo che il client possieda la chiave privata corrispondente a una chiave pubblica già autorizzata.

Questa guida copre il flusso completo: generazione della coppia di chiavi con ssh-keygen, distribuzione della chiave pubblica, gestione di host multipli con ~/.ssh/config, uso di ssh-agent e, infine, disattivazione sicura del login via password lato server.

Generare la coppia di chiavi con ssh-keygenIl primo passo è la scelta dell’algoritmo. Nel 2026 la raccomandazione per la quasi totalità degli scenari è Ed25519: chiavi più corte di RSA, generazione e verifica più veloci, sicurezza equivalente (o superiore) a RSA 3072/4096 bit. OpenSSH genera Ed25519 come default da ssh-keygen 9.5 (fine 2023), ma vale la pena specificarlo esplicitamente per chiarezza e portabilità degli script:

ssh-keygen -t ed25519 -C "nome@host-o-scopo-della-chiave"Il comando chiede dove salvare la chiave (default ~/.ssh/id_ed25519) e una passphrase. Imposta sempre una passphrase: senza, chiunque copi il file della chiave privata (backup non cifrato, laptop rubato, snapshot di VM) ottiene accesso diretto ai sistemi target. Se devi supportare dispositivi legacy che non gestiscono Ed25519 (raro, ma capita con apparati di rete datati), usa RSA a 4096 bit come alternativa:

ssh-keygen -t rsa -b 4096 -C "nome@host-o-scopo-della-chiave"Un’opzione spesso sottovalutata è l’uso di chiavi FIDO2/hardware, dove il materiale crittografico non lascia mai una security key fisica (es. YubiKey):

ssh-keygen -t ed25519-sk -C "chiave-hardware"Per ambienti con requisiti di compliance elevati o accessi amministrativi privilegiati, vale la pena valutarla: anche in caso di compromissione totale della workstation, la chiave privata resta inaccessibile senza il dispositivo fisico.

Distribuire la chiave pubblicaIl modo più rapido è ssh-copy-id, che si occupa di creare (se assente) la directory ~/.ssh sul server remoto, con permessi corretti, e di appendere la chiave pubblica a authorized_keys:

ssh-copy-id -i ~/.ssh/id_ed25519.pub utente@serverSe ssh-copy-id non è disponibile (ad esempio da un client Windows senza WSL), il metodo manuale equivalente è:

cat ~/.ssh/id_ed25519.pub | ssh utente@server
"mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"I permessi contano davvero: OpenSSH lato server rifiuta silenziosamente authorized_keys se la directory .ssh è scrivibile da altri utenti o se il file ha permessi troppo aperti. Se il login a chiave “non funziona” senza errori evidenti, controlla sempre chmod 700 ~/.ssh e chmod 600 ~/.ssh/authorized_keys prima di cercare altrove.

Gestire host multipli con ~/.ssh/configChi amministra decine di server trae grande beneficio da un file di configurazione client centralizzato. Invece di ricordare chiave, utente e porta per ogni host, definisci alias in ~/.ssh/config:

Host prod-web01
HostName 203.0.113.10
User deploy
Port 2222
IdentityFile ~/.ssh/id_ed25519_prod
IdentitiesOnly yes

Host *.interno.lan
User admin
IdentityFile ~/.ssh/id_ed25519_lan
ForwardAgent noDa quel momento ssh prod-web01 basta e avanza. L’opzione IdentitiesOnly yes è importante quando gestisci più chiavi: senza di essa, il client SSH può offrire al server tutte le identità disponibili nell’agent, esaurendo il numero massimo di tentativi consentiti (MaxAuthTries) prima di arrivare a quella corretta.

ssh-agent: passphrase una sola volta per sessioneCon una passphrase impostata (come dovrebbe essere sempre), digitarla a ogni connessione è scomodo. ssh-agent mantiene la chiave decifrata in memoria per la durata della sessione:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519Sulla maggior parte delle distribuzioni desktop l’agent è già integrato con il session manager. Evita ForwardAgent yes indiscriminato: l’agent forwarding espone la tua chiave in memoria a qualunque processo con privilegi root sul server intermedio, un rischio concreto se quel server non è pienamente fidato. Se ti serve saltare attraverso un bastion host, preferisci ProxyJump:

Host bastion
HostName bastion.example.com
User jump

Host target-interno
HostName 10.0.5.20
User admin
ProxyJump bastionDisabilitare l’autenticazione a password lato serverSolo dopo aver verificato che il login a chiave funziona correttamente (testalo in una sessione separata prima di chiudere quella attuale), disattiva la password lato server. Sulle distribuzioni moderne (Debian/Ubuntu recenti), il modo più pulito è un drop-in dedicato, che viene caricato prima del file principale e quindi vince sui default:

sudo mkdir -p /etc/ssh/sshd_config.d
sudo tee /etc/ssh/sshd_config.d/00-disable-password-auth.conf <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
EOF
sudo sshd -t && sudo systemctl reload sshdsshd -t valida la sintassi prima del reload: un errore di battitura in questo file può tagliarti fuori dal server se non hai un accesso alternativo (console cloud, iDRAC/iLO, ecc.). PermitRootLogin prohibit-password è la scelta consigliata rispetto a no secco: mantiene comunque disponibile il root via chiave per operazioni di emergenza, ma blocca il tentativo via password.

Checklist finale per un hardening solidoUna chiave dedicata per servizio/scopo (deploy, amministrazione, CI/CD), non un’unica chiave riutilizzata ovunque.

Passphrase sempre presente sulle chiavi memorizzate su disco non cifrato.

Audit periodico di authorized_keys su ogni server: rimuovi le chiavi di chi ha lasciato il team o non necessita più di accesso.

AuthorizedKeysCommand con backend centralizzato (Vault, LDAP) se gestisci decine di server e vuoi evitare la distribuzione manuale delle chiavi.

Fail2ban o equivalente comunque attivo, come difesa in profondità anche a password disabilitate.

ConclusioneIl passaggio da password a chiavi SSH richiede pochi minuti per server, ma elimina una delle superfici di attacco più sfruttate contro sistemi Linux esposti. La combinazione di Ed25519, ~/.ssh/config ben strutturato e password disabilitate lato server è oggi lo standard minimo per qualunque infrastruttura, piccola o grande che sia.

Fonte: LinuxBlog.io.

Il problema non è la mancanza di strumenti, è l’ordine in cui si usanoWindows include più utility diagnostiche di quante un amministratore ne userà mai tutte. Eppure la causa più comune di sessioni di troubleshooting infruttuose non è l’ignoranza dei tool, ma la sequenza sbagliata: si parte da un comando di riparazione (sfc /scannow, un reset di Windows Update, un DISM al buio) prima ancora di aver capito quale sottosistema sta effettivamente fallendo. Il risultato è tempo perso, evidenze diagnostiche distrutte dal riavvio, e spesso la causa radice che resta lì, pronta a ripresentarsi la settimana successiva.

Vale la pena fermarsi a formalizzare un metodo, perché è quello che separa un troubleshooting efficace da un’accozzaglia di tentativi casuali. Di seguito un processo in cinque passi, seguito da una rassegna degli strumenti chiave e da una tabella sintesi sintomo → strumento che può diventare un riferimento rapido da tenere a portata di mano durante un incidente.

Un processo ripetibile prima di toccare qualsiasi comandoLa maggior parte delle sessioni di troubleshooting falliscono prima ancora che venga lanciato il primo comando. Un amministratore vede un errore, prova un comando di riparazione che conosce, riavvia, e scopre che il problema originale è ancora lì. Un approccio più solido richiede di rallentare abbastanza da stabilire una baseline:

Confermare o riprodurre il problema: è cronico o è stato un episodio isolato?

Registrare il sintomo esatto: messaggio di errore, orario, utente coinvolto, dispositivo, modifiche recenti.

Raccogliere le evidenze dal sistema più probabilmente coinvolto.

Applicare una modifica alla volta, partendo dall’opzione meno invasiva.

Verificare il risultato e documentare cosa è effettivamente cambiato.

Un esempio concreto: se Windows Update fallisce con un errore generico, la tentazione è resettare tutti i componenti di aggiornamento in blocco. Il primo passo corretto è invece capire in quale fase è avvenuto il fallimento — scan, download, staging, installazione o riavvio — perché questa distinzione determina se bisogna guardare i log di Windows Update, i log di servicing, lo stato del disco, la configurazione delle policy o la connettività di rete.

Event Viewer: il primo posto dove cercare quando c’è un timestampEvent Viewer è il punto di partenza quando il sintomo ha un orario preciso: un crash applicativo, un riavvio inatteso, un servizio che si ferma, un problema di driver, un’installazione fallita. Si parte dai Windows Logs, filtrando Application, System e Setup per eventi Critical, Error e Warning nell’intorno temporale del problema, per poi individuare l’event source, l’event ID, il modulo che genera il fault, il nome del servizio o del driver coinvolto.

Il criterio per separare il segnale dal rumore è la ripetibilità: un warning isolato di ieri è quasi sempre rumore; un errore che compare sistematicamente ogni volta che si apre una determinata applicazione è un segnale affidabile. Le evidenze diagnostiche più utili sono quelle correlate nel tempo e riproducibili, non gli eventi isolati.

SFC prima, DISM solo se SFC non bastaSystem File Checker (SFC) è uno strumento di riparazione mirato per i file di sistema protetti. Si usa quando una feature nativa di Windows si comporta in modo anomalo, un componente integrato non parte, oppure Event Viewer punta a file del sistema operativo mancanti o corrotti:

sfc /scannowSFC è utile perché verifica e sostituisce i file protetti senza richiedere una reinstallazione, ma dipende dal component store locale come sorgente di riparazione. Se quello store è danneggiato, SFC può segnalare corruzione trovata ma non riparabile del tutto. A quel punto il passo successivo è DISM, non ripetere SFC all’infinito sperando in un risultato diverso.

Deployment Image Servicing and Management (DISM) opera a livello di image e component store, uno strato sotto SFC. Va usato quando SFC non riesce a completare le riparazioni, quando l’installazione di Windows Update o di una feature fallisce ripetutamente, o quando il problema è a livello di servicing. Il comando di riparazione online più comune:

DISM /Online /Cleanup-Image /RestoreHealthIn ambienti enterprise, DISM può aver bisogno di una sorgente di riparazione affidabile — supporto di installazione, un’immagine montata, o una posizione di contenuto gestita — soprattutto quando gli endpoint non possono scaricare i contenuti di riparazione da Windows Update. Dopo che DISM completa con successo, conviene rilanciare SFC, così i file protetti possono essere riparati da un component store ormai sano.

Windows Update: capire in quale fase fallisce prima di resettare tuttoIl troubleshooting di Windows Update deve partire dall’identificazione della fase fallita. Un fallimento nello scan suggerisce problemi di policy, rete, proxy o sorgente di aggiornamento. Un fallimento nel download indica problemi di connettività, disponibilità dei contenuti o cache. Un fallimento nell’installazione punta spesso allo servicing stack, al component store, allo spazio su disco, a un riavvio pendente o a un driver in conflitto.

Sulle versioni moderne di Windows, Windows Update si basa su dati Event Tracing for Windows (ETW) piuttosto che scrivere un semplice log testuale in continuo. Per generare un log leggibile quando serve un dettaglio più approfondito lato client, si usa PowerShell:

Get-WindowsUpdateLogVale anche controllare Event Viewer nei log operativi del client di Windows Update e il Setup log per gli eventi di installazione. Se lo stesso pacchetto KB fallisce ripetutamente, conviene verificare se l’aggiornamento è applicabile, se esiste un aggiornamento che lo sostituisce, e da quale sorgente il dispositivo riceve gli update — Windows Update diretto, Microsoft Update, WSUS, oppure una piattaforma di gestione come Intune o Configuration Manager.

Un reset completo di Windows Update dovrebbe essere un passo tardivo, non il primo. Resettare i servizi e svuotare le cache può sbloccare client incastrati, ma distrugge anche evidenze utili. Meglio catturare prima il codice di errore, i log e la cronologia degli aggiornamenti.

“La rete non funziona” è quasi sempre DNS o configurazioneI sintomi di rete richiedono un punto di partenza diverso, perché gli utenti spesso descrivono come “la rete è giù” un problema che in realtà è DNS, routing, autenticazione, policy del firewall o un singolo endpoint applicativo che non risponde. È corretto partire dalla configurazione TCP/IP locale prima di testare i servizi remoti.

Un errore comune tra amministratori meno esperti è dare per scontato che “il ping non risponde” equivalga a “la rete è giù”. In ambienti enterprise questa assunzione è spesso sbagliata: molti sistemi sono configurati per ignorare le richieste ICMP pur continuando a erogare regolarmente il servizio previsto. Un firewall può bloccare ICMP, una policy di sicurezza può disabilitare le risposte, un servizio cloud può non rispondere mai al ping. La domanda giusta non è se un dispositivo risponde al ping, ma se il servizio richiesto è effettivamente raggiungibile: bisogna sempre testare ciò che l’utente sta effettivamente cercando di usare, con strumenti come ipconfig, nslookup e tracert mirati sul servizio specifico.

Tabella di riferimento rapido: sintomo → strumentoSintomoPartire daPerchéApp che va in crash o si chiude inaspettatamenteEvent Viewer, poi Reliability MonitorIdentifica moduli in fault, errori applicativi e pattern di modifiche recentiWindows Update fallisce ripetutamenteLog di Windows Update, Setup log, DISMSepara i fallimenti di scan, download, installazione e servicingFeature di Windows mancanti o instabiliSFC, poi DISM se SFC non riparaRipara i file di sistema protetti e il component store sottostanteUtenti non raggiungono risorse di reteipconfig, ping, nslookup, tracertValida configurazione locale, raggiungibilità, DNS e routing in ordineLe performance degradano improvvisamenteTask Manager, Resource Monitor, Event ViewerCorrela la pressione sulle risorse con servizi, driver ed erroriReliability Monitor merita una menzione a parte perché offre una vista a timeline di crash applicativi, fallimenti di Windows, installazioni di driver ed eventi di aggiornamento. È meno dettagliato di Event Viewer, ma resta eccellente per individuare rapidamente cosa è cambiato immediatamente prima che iniziasse un problema ricorrente.

Costruire il proprio toolkit di troubleshootingPer un professionista IT, l’abilità di troubleshooting più preziosa non è memorizzare comandi, ma sapere quale fonte di evidenza fidarsi per una determinata classe di problema. Event Viewer dice cosa Windows ha registrato; Reliability Monitor mostra quando i problemi sono iniziati. Una checklist pratica da seguire durante un incidente:

Registrare sintomi esatti, orario, dispositivo, utente e modifiche recenti.

Controllare i log più rilevanti prima di applicare riparazioni ad ampio raggio.

Eseguire i comandi di riparazione da un terminale elevato e catturarne l’output.

Cambiare una variabile alla volta, per sapere con certezza cosa ha risolto il problema.

Verificare dal punto di vista dell’utente, non solo dalla console amministrativa.

Questa disciplina previene due errori tipici: eseguire riparazioni distruttive troppo presto, e dichiarare vittoria prima di aver verificato il flusso di lavoro reale. Se un utente non riesce ad aprire una condivisione di rete, un ping riuscito non è il traguardo: il traguardo è l’utente che apre la condivisione, accede ai file attesi e conferma che il problema non si ripresenta.

ConclusioneLa differenza tra una sessione di troubleshooting produttiva e una frustrante raramente sta nella conoscenza di comandi avanzati. Sta nel partire dal sintomo invece che dal comando, chiedersi quale evidenza confermerebbe o smentirebbe la causa più probabile, e solo a quel punto scegliere lo strumento che fornisce quell’evidenza nel modo più veloce. È questa disciplina che trasforma una collezione di utility in un vero toolkit diagnostico.

Fonte: Critical Windows Troubleshooting Tools: Stop Wasting Time on the Wrong Fixes, Petri IT Knowledgebase