L’aggiornamento cumulativo di settembre 2026 per #Windows 11, KB5124008, ha portato con sé un effetto collaterale che molti amministratori di dominio stanno scoprendo a proprie spese: alcune postazioni perdono il trust relationship con Active Directory, con conseguente impossibilità di autenticarsi usando le credenziali di dominio. Non è un bug generico di rete, ma il risultato di un’interazione precisa tra una #patch di sicurezza e una funzionalità introdotta di recente per proteggere gli account macchina: la Machine Identity Isolation.

Se gestite ambienti ibridi con Windows 11 24H2/25H2 joinati a un dominio on-premises, vale la pena capire esattamente cosa succede prima che il problema si presenti in produzione — o per diagnosticarlo rapidamente se è già successo.

Cosa succede in praticaI dispositivi colpiti mostrano il classico messaggio:

The trust relationship between this workstation and the primary domain failed.oppure, nella variante italiana:

Non è stato possibile stabilire una relazione di trust protetta tra questa workstation e il dominio primario.Gli utenti che hanno già effettuato l’accesso in precedenza possono spesso continuare a lavorare grazie alla cache delle credenziali, ma qualunque nuova autenticazione verso il dominio — accesso a share di rete, applicazioni Kerberos-aware, nuovi login — fallisce. Microsoft ha confermato che il problema non interessa la replica di Active Directory né i servizi dei domain controller: è circoscritto ai client (e in alcuni casi ai server membri) che ricevono l’aggiornamento.

La causa: Machine Identity Isolation e configurazioni pregresseLa Machine Identity Isolation è una funzionalità di sicurezza pensata per isolare e proteggere meglio le credenziali dell’account macchina, riducendo la superficie d’attacco per tecniche come il pass-the-hash o il furto del computer account. Il problema emerge nelle configurazioni dove:

Credential Guard è abilitato sul dispositivo Windows 11;

il dispositivo è joinato a un dominio Active Directory on-premises tradizionale;

la Machine Identity Isolation era stata abilitata in precedenza tramite #Intune, Group Policy o direttamente via registro di sistema, in un ambiente che non dispone ancora del supporto al Domain Functional Level di Windows Server 2025.

In sintesi: KB5124008 inizia a far rispettare (to honor, nella formulazione Microsoft) impostazioni che erano già presenti nel sistema ma che finora venivano tollerate in modo permissivo. Se il dominio non è ancora pronto ad accettare quella postura di isolamento più rigida, il canale sicuro tra client e domain controller si rompe silenziosamente al successivo tentativo di autenticazione.

È un pattern piuttosto comune nelle patch di hardening Microsoft: la funzionalità di sicurezza esisteva già, ma l’aggiornamento la rende effettiva, e gli ambienti che l’avevano attivata “per prova” o per errore ne pagano il conto mesi dopo.

Come verificare se siete a rischioPrima di applicare KB5124008 su larga scala, controllate se la Machine Identity Isolation risulta configurata sui vostri endpoint. Da #PowerShell, con privilegi amministrativi:

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" `
-Name "MachineIdentityIsolation" -ErrorAction SilentlyContinue

Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\System" `
-Name "MachineIdentityIsolation" -ErrorAction SilentlyContinueSe uno dei due percorsi restituisce un valore diverso da zero (o comunque configurato), e il dominio è ancora su un Domain Functional Level precedente a Windows Server 2025, è opportuno valutare un test controllato prima del rollout esteso della patch, oppure prepararsi in anticipo con la remediation descritta di seguito.

Come risolvere (o prevenire) il problemaMicrosoft indica un percorso di remediation in tre passaggi, da applicare tramite lo stesso canale con cui la policy era stata originariamente distribuita:

Disabilitare la Machine Identity Isolation usando lo stesso meccanismo di deployment originale — Intune, Group Policy o registro — così da garantire che la modifica si propaghi correttamente e non venga sovrascritta al successivo refresh delle policy;

Riavviare il dispositivo per applicare la modifica alla configurazione di sicurezza;

Riparare il canale sicuro con Active Directory, ad esempio con il classico comando PowerShell (richiede il modulo Active Directory RSAT):

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)Su dispositivi dove il canale è irrimediabilmente compromesso e Test-ComputerSecureChannel non risolve, resta l’opzione, più invasiva, di rimuovere e ri-aggiungere il computer al dominio:

Remove-Computer -UnjoinDomainCredential (Get-Credential) -PassThru -Restart
Add-Computer -DomainName "contoso.local" -Credential (Get-Credential) -RestartIndicazioni operative per chi gestisce parchi macchine Windows 11Alcuni suggerimenti pratici prima di distribuire KB5124008 su larga scala:

Verificate il Domain Functional Level del vostro dominio (Get-ADDomain | Select DomainMode) e pianificate l’upgrade a Windows Server 2025 se non è già in programma;

Fate un audit delle policy GPO e delle configurazioni Intune relative a Credential Guard e Machine Identity Isolation prima di approvare l’update sui canali di distribuzione (WSUS, Intune, Autopatch);

Distribuite la patch a un anello ring pilota che includa dispositivi con Credential Guard attivo, non solo macchine “generiche”, per intercettare il problema prima del rollout esteso;

Documentate la procedura di ripristino del canale sicuro nel vostro runbook di incident response: è uno scenario che, una volta noto, si risolve in pochi minuti, ma solo se il team di supporto sa cosa cercare.

ConclusioneIl caso KB5124008 è un promemoria utile: le patch che rafforzano funzionalità di sicurezza già presenti nel sistema possono comportarsi in modo imprevisto quando incontrano configurazioni legacy o parzialmente implementate. La Machine Identity Isolation è, di per sé, un miglioramento importante per la protezione degli account macchina — ma la sua piena efficacia richiede un dominio allineato al Domain Functional Level più recente. Prima di ogni patch Tuesday che tocca l’autenticazione, vale sempre la pena controllare le note di rilascio con l’occhio rivolto non solo a “cosa fa” l’aggiornamento, ma a “cosa inizia finalmente a far rispettare”.

Fonte: Petri IT Knowledgebase

Java 27 è arrivato, e cambia due default che riguardano tuttiIl 15 settembre 2026 Oracle ha rilasciato #Java 27 (JDK 27), la nuova #release a cadenza semestrale del linguaggio. Come spesso accade con le versioni “dispari” del ciclo a sei mesi, non è la release con il maggior numero di feature preview eclatanti, ma introduce due cambiamenti strutturali che meritano attenzione da parte di chi gestisce applicazioni Java in produzione: il garbage collector G1 diventa il default in ogni ambiente, e arriva il supporto nativo a scambi di chiavi TLS 1.3 resistenti al calcolo quantistico. Sono esattamente il tipo di cambiamenti “silenziosi” che possono modificare il comportamento di un’applicazione senza che una sola riga di codice venga toccata.

JEP 523: G1 diventa il garbage collector di default ovunqueDa JDK 9, G1 (Garbage-First) è il collector di default negli ambienti “server”, mentre le JVM avviate in configurazioni più leggere o vincolate in termini di risorse ricadevano sul Serial Collector, storicamente più economico in termini di footprint di memoria e tempo di avvio ma limitato a un singolo thread di collezione.

Con JEP 523, questa distinzione sparisce: G1 diventa il default in tutti gli ambienti, incluse le configurazioni precedentemente riservate a Serial. La motivazione tecnica dichiarata dal team OpenJDK è che il lavoro di ottimizzazione degli ultimi anni ha reso G1 “competitivo con Serial a qualsiasi dimensione di heap”, con throughput, latenza, footprint di memoria e tempo di startup comparabili anche sui carichi più piccoli — lo scenario in cui Serial aveva storicamente il vantaggio più netto.

Per chi amministra JVM in produzione, questo significa in pratica:

Se non specificate esplicitamente un collector con -XX:+UseSerialGC, -XX:+UseParallelGC o -XX:+UseZGC, dopo l’upgrade a Java 27 la vostra applicazione userà G1 anche in scenari dove prima girava su Serial — ad esempio #container con limiti di memoria molto stretti o #microservizi con heap ridotti.

G1 introduce collezione a più thread e fasi concorrenti che Serial non ha: aspettatevi un pattern di utilizzo #CPU leggermente diverso durante i cicli di garbage collection, specialmente su ambienti con pochi core disponibili.

Se avete pipeline di test delle #performance o SLA di latenza stretti su servizi con footprint minimo (ad esempio funzioni serverless o batch job short-lived), vale la pena ripetere un benchmark mirato prima di fare l’upgrade in produzione, anche se il team OpenJDK dichiara di non aver osservato regressioni significative.

Per tornare al comportamento precedente è sufficiente il flag esplicito -XX:+UseSerialGC in fase di avvio della JVM: nessuna riscrittura di codice necessaria.

Va inoltre ricordato che da JDK 24 le Compact Object Headers (JEP 450, poi consolidate) sono considerate stabili e restano attive di default anche in Java 27: l’header degli oggetti passa da 96 a 64 bit su architetture a 64 bit, con benefici diretti su densità di deployment, località dei dati in cache e footprint complessivo dell’heap. Combinato con G1 come default universale, il risultato netto è una JVM pensata per comportarsi in modo più uniforme sia su un server con centinaia di GB di heap sia su un container #Kubernetes con 256 MB di limite.

JEP 527: scambio di chiavi TLS 1.3 ibrido e resistente al quantum computingLa seconda novità di rilievo riguarda la sicurezza delle comunicazioni. JEP 527 introduce nelle API javax.net.ssl il supporto a schemi di scambio di chiavi ibridi per TLS 1.3, che combinano un algoritmo classico basato su curve ellittiche con un algoritmo post-quantistico basato su reticoli (ML-KEM, standardizzato da NIST).

La motivazione non è ipotetica: il problema noto come “harvest now, decrypt later” descrive una minaccia già attuale, in cui traffico cifrato oggi con algoritmi classici viene intercettato e archiviato da attori con risorse importanti, in attesa che un futuro computer quantistico sufficientemente potente permetta di decifrarlo retroattivamente. Per dati con un valore di confidenzialità che si estende su anni — cartelle cliniche, segreti industriali, comunicazioni governative — agire ora, prima che il quantum computing su scala sia disponibile, è l’unica strategia sensata.

Uno schema ibrido ha una proprietà rassicurante per chi deve fidarsi della #crittografia oggi: rimane sicuro finché almeno uno dei due algoritmi componenti resiste, offrendo quindi il meglio di entrambi i mondi senza scommettere tutto sulla novità.

I tre gruppi supportatiJEP 527 introduce tre nuovi “named group” per TLS 1.3, ciascuno combinazione di ECDHE classico e ML-KEM:

X25519MLKEM768 — Curve25519 + ML-KEM-768

SecP256r1MLKEM768 — curva secp256r1 + ML-KEM-768

SecP384r1MLKEM1024 — curva secp384r1 + ML-KEM-1024, il livello di sicurezza più alto

L’ordine di preferenza di default della JVM diventa: X25519MLKEM768, x25519, secp256r1, secp384r1, secp521r1, x448, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192. In altre parole, X25519MLKEM768 ha la priorità più alta: se sia client che server supportano TLS 1.3 su Java 27 senza configurazioni personalizzate, lo scambio di chiavi ibrido post-quantistico viene negoziato automaticamente, senza alcuna modifica al codice applicativo.

Come controllare o disabilitare il comportamentoChi ha bisogno di un controllo più fine — ad esempio per motivi di compatibilità con sistemi legacy o per test di interoperabilità — può intervenire in due modi.

Via system property, per sovrascrivere globalmente l’elenco dei gruppi supportati:

-Djdk.tls.namedGroups="secp256r1,x25519"Oppure programmaticamente, tramite SSLParameters, per un controllo puntuale sulla singola connessione:

SSLSocket tlsSock = (SSLSocket)(SSLContext.getDefault().
getSocketFactory().createSocket());
SSLParameters params = tlsSock.getSSLParameters();
params.setNamedGroups(new String[] {
"SecP256r1MLKEM768", "X25519MLKEM768", "secp256r1", "x25519"
});
tlsSock.setSSLParameters(params);Un punto operativo da non sottovalutare: i messaggi TLS ClientHello che negoziano questi gruppi ibridi sono più grandi rispetto a quelli con solo curve ellittiche classiche, per via delle chiavi pubbliche ML-KEM più voluminose. Se avete middlebox, load balancer o proxy TLS datati che fanno parsing rigido dei pacchetti ClientHello, vale la pena verificarne il comportamento prima del rollout su larga scala — è un problema già osservato in altri ecosistemi (#browser, OpenSSH) nella fase di adozione del PQC ibrido.

Altre novità degne di notaJEP 533 — Structured Concurrency (settima preview): il modello che tratta gruppi di task correlati eseguiti su thread diversi come un’unica unità di lavoro continua la sua maturazione, riducendo i rischi di thread leak e semplificando cancellazione e gestione degli errori nei flussi concorrenti. Resta in preview, quindi da usare con il flag --enable-preview e non ancora adatta a codice di produzione stabile.

JEP 532 — Primitive Types in Patterns (quinta preview): estende il pattern matching ai tipi primitivi, avvicinando ulteriormente la maturazione di questa funzionalità.

JEP 537 — Vector API (dodicesimo incubator): continua il lungo percorso di incubazione delle API vettoriali per carichi di data analytics e inferenza AI, pensate per sfruttare le istruzioni SIMD della CPU.

Cosa significa per chi pianifica un upgradeNessuna delle due novità principali richiede modifiche al codice applicativo, ma entrambe cambiano comportamenti impliciti su cui molti team non hanno mai dovuto ragionare esplicitamente. Prima di un upgrade a Java 27 in produzione, ha senso:

Verificare quale garbage collector state effettivamente usando oggi (spesso implicito, mai impostato esplicitamente) e ripetere un test di carico rappresentativo dopo l’upgrade, specialmente su servizi con heap piccoli o vincoli di latenza stretti.

Testare l’interoperabilità TLS con eventuali componenti di rete intermedi (load balancer, WAF, proxy) prima di esporre servizi che useranno automaticamente lo scambio di chiavi ibrido.

Se la vostra organizzazione ha requisiti di conformità legati alla crittografia post-quantistica (settore finanziario, sanitario, pubblica amministrazione), Java 27 offre finalmente un percorso “out of the box” senza dover ricorrere a provider crittografici di terze parti.

Nel complesso, Java 27 conferma una tendenza già vista in altri runtime e protocolli (OpenSSH, i principali browser): la crittografia post-quantistica sta passando rapidamente da tema di ricerca a default silenzioso nelle piattaforme che usiamo ogni giorno. Vale la pena arrivarci preparati, piuttosto che scoprirlo il giorno dell’upgrade.

Fonte: Oracle Java Blog – The Arrival of Java 27, con approfondimenti da Phoronix e dalle specifiche ufficiali JEP 523 e JEP 527 su OpenJDK.org.

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

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.

Gli aggiornamenti cumulativi di settembre 2026 per #Windows Server hanno introdotto un problema serio su Remote Desktop Services: dopo l’installazione delle #patch, le sessioni #RDP su alcuni host iniziano a bloccarsi o a rifiutare nuove connessioni, spesso dopo diverse ore di funzionamento normale. Per chi gestisce collection RDS in produzione — RDSH multi-sessione, VDI o semplicemente jump server amministrativi — è un problema da conoscere prima di distribuire la patch su larga scala, perché tocca esattamente le macchine che gli amministratori usano per raggiungere il resto dell’infrastruttura.

Quali sistemi sono coinvoltiIl problema riguarda tre cumulative update distinti, uno per versione di sistema operativo:

KB5122876 — Windows Server 2019

KB5122882 — Windows Server 2022

KB5122871 — Windows Server 2025

Le note di rilascio Microsoft segnalano separatamente anche problemi su Windows Server 2016, con la redirezione audio di Remote Desktop non funzionante dopo l’installazione. Va inoltre ricordato che il pacchetto di settembre non è “solo” quello che introduce il bug: nello stesso ciclo Microsoft ha corretto oltre 970 vulnerabilità, incluse due zero-day già sfruttate attivamente. Questo rende la scelta “disinstallo la patch” tutt’altro che indolore.

Sintomi osservatiDalle segnalazioni raccolte dagli amministratori nei forum tecnici e da chi ha già debuggato il problema, il pattern tipico è il seguente:

RDS funziona normalmente per diverse ore dopo il riavvio post-patch;

le sessioni RDP esistenti smettono di disconnettersi o effettuare il logoff correttamente;

i nuovi tentativi di connessione restano bloccati sulla schermata “Connecting…” fino a fallire;

in alcuni casi il servizio va in crash dopo il primo logout utente, impedendo login successivi;

Task Manager e le impostazioni di sistema diventano a loro volta non responsive sull’host colpito, rendendo necessario un hard reset.

Chi ha fatto debugging più approfondito ha individuato nei log un deadlock nella libreria server RDP durante la chiusura di sessione: l’evento si blocca nella routine RDPSERVERBASE!WDLIB_Close, apparentemente senza timeout configurato, generando uno stallo tra il processo RDP e LSM (Local Session Manager). Nei log di sistema il sintomo si traduce nell’evento 20498 nel canale Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin.

Come verificare se un host è colpitoPrima di intervenire, è utile raccogliere qualche riscontro diagnostico in sola lettura:

Verifica eventi di timeout sulla connessione RDP

Get-WinEvent -FilterHashtable @{
LogName = 'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin'
Id = 20498
} -MaxEvents 5 | Format-Table TimeCreated, Message -Wrap

Controlla lo stato del servizio Terminal Services

Get-Service -Name TermService | Select-Object Name, StatusSe l'evento 20498 compare in concomitanza con logoff o riconnessioni di sessione, l'host è verosimilmente esposto al bug.

Le opzioni sul tavoloAl momento della stesura di questo articolo Microsoft non ha ancora confermato pubblicamente la causa né rilasciato una patch out-of-band; l'azienda ha dichiarato di essere a conoscenza delle segnalazioni e di stare indagando. Questo lascia agli amministratori due strade principali, entrambe con compromessi da valutare con attenzione:

1. Rollback del pacchetto cumulativoÈ l'opzione più testata e documentata. Rimuove il bug ma riporta l'host allo stato di vulnerabilità precedente, comprese le due zero-day corrette a settembre — accettabile solo come misura temporanea su host isolati o con mitigazioni compensative (segmentazione di rete, restrizioni di accesso RDP tramite VPN/Bastion) già in campo.

Individua il pacchetto della cumulative update installata

dism.exe /Online /Get-Packages /Format:Table | findstr /i "Package_for_RollupFix"

Rimuove il pacchetto (sostituire con il nome esatto restituito sopra)

dism.exe /Online /Remove-Package /PackageName:Package_for_RollupFix31bf3856ad364e35amd64~~20348.5622.1.2 /NoRestart

Riavvio richiesto per applicare la modifica

Restart-Computer -ForceSu una collection RDS gestita, conviene prima spostare l'host fuori rotazione per evitare che riceva nuove connessioni durante l'intervento:

Import-Module RemoteDesktop
Set-RDSessionHost -CollectionName "NomeCollection" -SessionHost "host.dominio.local" -NewConnectionAllowed No

... rollback e riavvio ...

Set-RDSessionHost -CollectionName "NomeCollection" -SessionHost "host.dominio.local" -NewConnectionAllowed Yes2. Workaround alternativi circolati in communityAlcuni blog tecnici indipendenti propongono un override tramite feature flag in HKLM\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides, con l'obiettivo di disattivare selettivamente il componente incriminato senza rimuovere l'intera patch di sicurezza. Va detto con chiarezza: si tratta di un workaround non ufficiale, non validato da Microsoft, che tocca un'area del registro sensibile e non documentata pubblicamente per questo scopo. Non è consigliabile applicarlo direttamente in produzione: se lo si vuole testare, farlo solo su un host di laboratorio isolato, con backup del ramo di registro prima e dopo, e senza aspettarsi supporto ufficiale in caso di problemi.

Cosa fare adessoIl consiglio più solido, in attesa di una risposta ufficiale Microsoft, resta quello suggerito dai team di sicurezza che seguono il caso: distribuire l'aggiornamento di settembre prima su un piccolo gruppo di host RDS non critici, monitorare l'evento 20498 e lo stato del servizio TermService per 24-48 ore, e mantenere pronto un piano di rollback per gli host di produzione più esposti. Vale anche la pena avvisare in anticipo chi gestisce l'help desk: sessioni RDP che si bloccano "a caso" dopo qualche ora sono un sintomo facile da scambiare per un problema di rete o di carico, mentre qui l'origine è chiaramente lato patch.

Fonte: 4sysops – September Windows Server updates break Remote Desktop Services (RDS); approfondimenti tecnici da BleepingComputer e Cyber Security News.

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.

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.

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

Il problema che risolveChi progetta reti Azure da qualche anno conosce bene il limite: gli endpoint privati (Private Endpoint) e Azure Private Link, il meccanismo che permette di raggiungere un servizio PaaS — storage account, database, Key Vault — attraverso un indirizzo IP privato all’interno della propria rete virtuale invece che tramite l’endpoint pubblico, hanno sempre funzionato solo su IPv4. Per le organizzazioni che stanno completando la transizione verso reti dual-stack o IPv6-only — spinte da esaurimento di spazio IPv4 privato, requisiti normativi o semplicemente modernizzazione dell’infrastruttura — questo obbligava a mantenere un livello di traduzione o connettività IPv4 residua solo per parlare con i servizi PaaS.

Microsoft ha annunciato la preview pubblica di Azure Private Link over IPv6, che elimina questa dipendenza: gli endpoint privati possono ora esporre un indirizzo IPv6, permettendo a client e workload nativamente IPv6 di raggiungere i servizi PaaS supportati senza alcuna intermediazione IPv4.

Servizi supportati nella previewAl momento della preview pubblica, il supporto copre un sottoinsieme mirato di servizi PaaS ad alto utilizzo:

Azure Storage (Blob, ecc.)

Azure SQL Database

Azure Key Vault

Azure Data Explorer

È lecito aspettarsi che l’elenco si allarghi man mano che la feature matura verso la disponibilità generale, seguendo lo schema tipico delle preview Azure: si parte dai servizi con maggiore adozione enterprise e si estende progressivamente.

Due scenari di connettivitàLa documentazione distingue due modalità d’uso, entrambe rilevanti per chi progetta reti ibride:

Connettività nativa AzureMacchine virtuali dual-stack o IPv6-only all’interno di una rete virtuale Azure accedono ai servizi PaaS tramite l’endpoint privato IPv6, con il traffico che rimane interamente sulla dorsale privata Microsoft — lo stesso principio di isolamento dal traffico pubblico che Private Link garantisce già per IPv4.

Connettività ibrida on-premisesClient IPv6 in un datacenter on-premises possono raggiungere i servizi Azure attraverso ExpressRoute, con una connessione privata end-to-end che non attraversa mai la rete pubblica Internet. Questo scenario richiede tipicamente una Virtual Network Routing Appliance (VNRA) con route definite dall’utente (UDR) per instradare correttamente il traffico IPv6 tra l’ambiente on-premises e la rete virtuale Azure.

Requisiti di configurazionePer attivare e usare la feature in preview servono alcuni passaggi preliminari:

Registrazione della subscription al feature flag della preview pubblica (come per la maggior parte delle feature in anteprima su Azure, tramite az feature register o dal portale).

Rete virtuale dual-stack: la VNet deve avere spazio di indirizzamento sia IPv4 sia IPv6 configurato, non è sufficiente aggiungere IPv6 alla sola subnet dell’endpoint privato.

Endpoint privati abilitati IPv6, creati esplicitamente con configurazione dual-stack.

DNS coerente: le zone DNS private devono risolvere i nomi dei servizi PaaS anche verso i record AAAA (indirizzi IPv6) associati agli endpoint privati, non solo verso i record A esistenti.

Per lo scenario ibrido, la VNRA con UDR menzionata sopra, per garantire che il traffico IPv6 proveniente da ExpressRoute venga instradato correttamente verso l’endpoint privato.

Un dettaglio che vale la pena sottolineare per chi pianifica un rollout: la configurazione DNS è spesso il punto in cui i deployment IPv6 falliscono silenziosamente. Se la zona privata continua a restituire solo record A, i client dual-stack proveranno comunque a instradare la richiesta su IPv4, vanificando parte del vantaggio della nuova feature. Vale la pena verificare esplicitamente con nslookup -type=AAAA o dig AAAA che la risoluzione avvenga come previsto prima di considerare il deployment completo.

Disponibilità regionaleLa preview pubblica è per ora limitata a un numero ristretto di region:

West Central US

East Asia

UK South

Central US

North Europe

Chi opera in altre region europee (ad esempio West Europe o Italy North) dovrà attendere l’espansione della preview o la disponibilità generale prima di poter testare la feature sui propri workload di produzione — un fattore da tenere in conto nella pianificazione di eventuali migrazioni a reti IPv6-only che dipendano da questa capacità.

Perché conviene iniziare a pianificare oraAnche per chi non ha una scadenza imminente per l’adozione IPv6, ci sono buone ragioni pratiche per iniziare a familiarizzare con questa capacità:

Esaurimento dello spazio IPv4 privato: le grandi organizzazioni con centinaia di VNet e subnet spesso si scontrano con conflitti di indirizzamento RFC 1918 quando serve fare peering tra reti create in tempi diversi o durante fusioni aziendali. IPv6 elimina strutturalmente questo problema.

Compliance e requisiti governativi: diverse amministrazioni pubbliche, in Italia come altrove, hanno tabelle di marcia che richiedono supporto IPv6 nativo per i servizi digitali entro scadenze specifiche.

Riduzione della complessità NAT: meno traduzione di indirizzi significa meno stato da gestire e da diagnosticare quando qualcosa si rompe — un vantaggio concreto in fase di troubleshooting di rete.

Per un architetto di rete Azure, il percorso pragmatico consiste nel registrare fin da ora una subscription non di produzione alla preview, distribuire una VNet dual-stack di test e verificare il comportamento end-to-end (inclusa la risoluzione DNS) prima che la feature diventi disponibile su larga scala. Arrivare preparati alla disponibilità generale, quando probabilmente coprirà più servizi e più region, evita di dover improvvisare un redesign di rete sotto pressione.

ConclusioneAzure Private Link over IPv6 chiude una lacuna che gli architetti di rete Azure conoscono da anni: l’impossibilità di raggiungere i servizi PaaS più comuni tramite endpoint privati IPv6 senza intermediazione IPv4. La preview è ancora limitata per servizi e region, ma la direzione è chiara e coerente con il resto dell’ecosistema Azure networking (Application Gateway ed ExpressRoute hanno già ricevuto supporto IPv6 esteso nell’ultimo periodo). Chi gestisce infrastrutture ibride o pianifica una transizione IPv6 farebbe bene a iniziare i test già in questa fase di anteprima.

Fonte: Azure Private Link Over IPv6 Enters Public Preview — Petri IT Knowledgebase. Annuncio ufficiale: Microsoft Tech Community.

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 12 gennaio 2027 #Windows Server 2016 uscirà dal supporto esteso: niente più aggiornamenti di sicurezza “gratuiti” tramite Windows Update o WSUS. Per molte aziende italiane che ancora gestiscono infrastrutture on-premises con carichi legacy su questa versione, non è una scadenza lontana da ignorare. Microsoft ha appena reso generally available una via per guadagnare tempo senza dover migrare tutto su macchine virtuali #Azure: gli Extended Security Updates (ESU) abilitati da Azure Arc, con un modello pay-as-you-go. Vediamo cosa cambia concretamente e come prepararsi.

Cosa sono gli ESU e perché contanoGli Extended Security Updates sono #patch che coprono esclusivamente vulnerabilità classificate come Critical e Important: niente nuove funzionalità, niente fix non di sicurezza. Per Windows Server 2016 la finestra di copertura ESU va dal 12 gennaio 2027 al gennaio 2030, quindi fino a tre anni extra di protezione per i sistemi che non possono essere aggiornati o migrati in tempo.

Finora, per usufruirne su server on-premises servivano contratti tramite Volume Licensing e chiavi di attivazione da gestire manualmente, un processo tutt’altro che agile su larga scala. La novità è che ora gli ESU si possono attivare direttamente tramite Azure Arc, senza spostare il carico di lavoro su una VM Azure.

Come funziona l’abilitazione via Azure ArcIl meccanismo si basa sul fatto che il server, anche se resta fisicamente on-premises, in edge o presso un altro #cloud provider, viene “proiettato” in Azure come risorsa Arc-enabled. Una volta connesso, diventa possibile:

Iscrivere il server agli ESU direttamente dal portale Azure, senza chiavi di attivazione tradizionali da inserire manualmente su ogni macchina.

Pagare a consumo (pay-as-you-go) invece di dover sottoscrivere un impegno pluriennale anticipato: utile per chi non sa ancora con precisione quanti server serviranno la copertura o per quanto tempo.

Gestire in modo centralizzato lo stato di copertura ESU su tutta la flotta di server, dentro e fuori Azure.

Va tenuto presente un requisito di licensing: le Extended Security Updates per Windows Server 2016 richiedono, nella maggior parte dei casi, Software Assurance attiva tramite un programma di Volume Licensing. È un punto da verificare con il proprio referente Microsoft prima di pianificare l’onboarding su larga scala.

Non solo patch: cosa arriva in dote con Azure ArcConnettere i server a Azure Arc per gli ESU porta con sé, quasi come effetto collaterale positivo, l’accesso a un set di strumenti di gestione che normalmente sono associati alle risorse cloud native:

Azure Update Manager: visibilità e pianificazione delle patch su tutta la flotta, ibrida o multicloud, da un’unica console.

Change Tracking and Inventory: tracciamento delle modifiche a file, registro di sistema e software installato, utile in fase di audit o incident response.

Azure Policy Guest Configuration: verifica automatica della conformità della configurazione interna della macchina rispetto a policy definite centralmente.

Per chi gestisce decine o centinaia di server Windows Server 2016 sparsi tra data center e sedi periferiche, questo significa passare da un controllo manuale, server per server, a una gestione centralizzata paragonabile a quella di un ambiente cloud nativo, pur restando on-premises.

Come prepararsi in praticaMicrosoft indica un percorso di preparazione abbastanza lineare, che vale la pena pianificare per tempo:

1. Censire i server a rischioIdentificare tutte le istanze Windows Server 2016 (edizioni Standard e Datacenter) che non potranno essere aggiornate o dismesse prima di gennaio 2027.

2. Connetterle ad Azure ArcL’onboarding richiede l’installazione dell’agente Azure Connected Machine sui server target e la relativa registrazione nel proprio tenant Azure. È il prerequisito tecnico per tutto il resto.

3. Verificare i canali di distribuzione degli aggiornamentiI server devono poter ricevere gli aggiornamenti tramite almeno uno di questi canali: Windows Update diretto, WSUS, oppure lo stesso Azure Update Manager. Vale la pena controllare ora, non a ridosso della scadenza, che le regole firewall e i proxy aziendali non blocchino questi endpoint.

4. Iscrivere i server agli ESUUna volta Arc-enabled, l’attivazione della copertura ESU si fa dal portale Azure, senza dover distribuire chiavi di licenza manualmente su ogni singola macchina.

Un ponte, non una destinazioneMicrosoft è esplicita su questo punto, e vale la pena ripeterlo a chi in azienda pensasse di usare gli ESU come soluzione permanente: gli Extended Security Updates sono pensati come bridge temporaneo per applicazioni business-critical che hanno bisogno di più tempo, non come alternativa a lungo termine alla modernizzazione. I tre anni di copertura vanno usati per pianificare concretamente la migrazione, che sia verso Windows Server più recenti on-premises, verso VM Azure, o verso il ridisegno delle applicazioni interessate.

Chi si limita a “comprare tempo” senza usarlo per muoversi si troverà comunque, a gennaio 2030, davanti allo stesso problema, ma con meno margine di manovra.

ConclusioneIl passaggio degli ESU per Windows Server 2016 da un modello a chiavi manuali a un’attivazione via Azure Arc pay-as-you-go semplifica sensibilmente la gestione della #compliance di sicurezza su ambienti ibridi, e porta in dote strumenti di visibilità che normalmente restano appannaggio del cloud puro. Per i sistemisti che gestiscono infrastrutture legacy, il momento giusto per censire i server coinvolti e avviare l’onboarding su Azure Arc è adesso, non a dicembre 2026.

Fonte: Petri IT Knowledgebase – Microsoft Makes Azure Arc-Enabled ESUs for Windows Server 2016 Generally Available e Microsoft Community Hub – Azure Arc Blog

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