Con le build più recenti di #Windows 11 26H2, Microsoft ha fatto un passo che molti amministratori di sistema aspettavano da anni: #Sysmon, lo storico strumento di System Monitor di Sysinternals, è ora integrato direttamente nel sistema operativo come funzionalità opzionale. Non serve più scaricare l’eseguibile da Microsoft Sysinternals, accettare l’EULA a riga di comando e gestirne manualmente l’aggiornamento su ogni macchina: Sysmon diventa un componente nativo di Windows, installabile e configurabile con gli stessi strumenti che si usano già per le altre feature opzionali.

Per chi si occupa di hardening, detection engineering o semplicemente di avere una visibilità decente sui propri endpoint, questa è una notizia rilevante: significa poter distribuire una baseline di monitoraggio coerente via #Intune, Group Policy o Configuration Manager, senza dipendere da un binario di terze parti da tenere aggiornato fuori dal normale ciclo di patching di Windows.

Cos’è Sysmon e perché è diverso da un semplice Event LogSysmon è un servizio di sistema e un driver che osserva l’attività del sistema operativo a un livello molto più granulare di quanto non facciano i log di sicurezza standard di Windows. In particolare registra, con un dettaglio che il Security Log nativo non offre:

creazione di processi, con riga di comando completa, hash del binario e processo padre;

connessioni di rete, incluse porta e processo che le ha originate;

modifiche agli orari di creazione dei file (un indicatore classico di timestomping);

caricamento di driver e DLL;

modifiche al registro di sistema;

creazione di named pipe, accessi WMI e molto altro, in base alla configurazione XML applicata.

Questi eventi finiscono in un log dedicato, visibile in Visualizzatore eventi > Registri applicazioni e servizi > Microsoft-Windows-Sysmon/Operational, e sono la materia prima su cui si basano la maggior parte delle regole SIGMA, delle query #Sentinel/Splunk per il threat hunting e delle configurazioni pubbliche più note, come la celebre sysmon-config di SwiftOnSecurity.

La versione integrata in Windows 11 non è un prodotto diverso: è lo stesso motore Sysinternals, reso disponibile come optional feature del sistema operativo. Cambia il meccanismo di distribuzione e di lifecycle, non la logica di funzionamento né il formato della configurazione XML, che resta pienamente compatibile con quella usata finora.

PrerequisitiPrima di procedere, verifica due cose:

Se sulla macchina è già installata una copia “classica” di Sysmon scaricata da Sysinternals, va disinstallata (sysmon64 -u o sysmon -u a seconda della versione) prima di abilitare la feature integrata, per evitare conflitti tra driver.

La build di Windows 11 deve includere la feature. Al momento della stesura è disponibile sui canali Insider (#Dev e Beta, a partire dalle build 26220.7752 e 26300.7733) in vista del rollout su 26H2; su alcune installazioni potrebbe non essere ancora presente.

Abilitare Sysmon via PowerShellIl modo più diretto per abilitare la feature è #PowerShell, da una sessione con privilegi di amministratore:

Enable-WindowsOptionalFeature -Online -FeatureName SysmonIn alternativa, lo stesso risultato si ottiene da prompt dei comandi con DISM:

DISM /Online /Enable-Feature /FeatureName:SysmonOppure, per chi preferisce l’interfaccia grafica, da Impostazioni > App > Funzionalità facoltative > Altre funzionalità di Windows, selezionando la voce Sysmon.

Attenzione: abilitare la feature registra il componente nel sistema, ma non avvia ancora il servizio. È un dettaglio facile da perdere per chi ha familiarità con il vecchio flusso “scarica ed esegui”, e la causa più comune di “non vedo eventi nel log” dopo l’attivazione.

Inizializzare il servizioDopo aver abilitato la feature, va eseguito il comando di inizializzazione, sempre con privilegi elevati:

sysmon -iQuesto comando installa il driver, avvia il servizio e accetta implicitamente l’EULA (nelle versioni Sysinternals andava confermato esplicitamente con -accepteula alla prima esecuzione; vale la pena controllare che il comportamento sia identico anche nella build che si sta usando). Senza argomenti aggiuntivi, Sysmon parte con una configurazione predefinita piuttosto permissiva, che per un uso in produzione è quasi sempre da sostituire con una configurazione XML personalizzata.

Applicare una configurazione XML personalizzataIl punto di forza di Sysmon è la possibilità di definire con precisione cosa loggare e cosa escludere, per evitare di saturare il log con rumore (ad esempio il traffico di rete di un #browser) e concentrarsi sugli eventi rilevanti per la detection. La configurazione si applica con:

sysmon -c C:\Config\sysmon-config.xmlPer vedere la configurazione attualmente caricata, senza modificarla:

sysmon -cChi parte da zero può usare come base una configurazione pubblica ben mantenuta, come quella di SwiftOnSecurity o quella del progetto Olaf Hartong / sysmon-modular, e adattarla poi all’ambiente specifico (escludendo ad esempio i processi di antivirus/EDR già presenti, che altrimenti generano un volume enorme di eventi ridondanti).

Verificare che Sysmon stia scrivendo eventiIl test più rapido è generare un evento e controllarlo da PowerShell:

Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 10 |
Select-Object TimeCreated, Id, MessageSe il log restituisce eventi recenti (tipicamente Event ID 1 per la creazione di processi, Event ID 3 per le connessioni di rete), il servizio è attivo e sta applicando correttamente la configurazione. In caso contrario, verifica lo stato del servizio con:

Get-Service Sysmon*e, se necessario, ripeti l’inizializzazione con sysmon -i.

Cosa cambia per chi gestisce molte macchineFinché Sysmon era un download esterno, distribuirlo su larga scala significava impacchettarlo come applicazione (via Intune, SCCM/ConfigMgr o uno script di login) e gestirne separatamente gli aggiornamenti rispetto al ciclo di #patch Tuesday. Con l’integrazione nativa, l’attivazione della feature può essere veicolata come una qualsiasi impostazione di sistema: una Configuration Service Provider (CSP) policy via Intune, una Group Policy che abilita la optional feature, o semplicemente uno script di provisioning eseguito in fase di imaging. La configurazione XML resta comunque da distribuire separatamente (ad esempio via Intune come file di configurazione o script di avvio), ma il componente di base segue finalmente lo stesso ciclo di vita del sistema operativo.

Per i team di detection engineering, questo riduce sensibilmente l’attrito nell’adottare Sysmon come standard di baseline su flotte Windows 11, soprattutto in ambienti dove l’installazione di software non Microsoft è soggetta a processi di approvazione più lunghi.

ConclusioneL’arrivo di Sysmon come funzionalità integrata in Windows 11 è un cambiamento più organizzativo che tecnico: la logica di logging resta quella nota da anni, ma la distribuzione diventa parte del sistema operativo stesso. Per chi già usa Sysmon in produzione, vale la pena pianificare la migrazione dalla versione Sysinternals a quella nativa non appena disponibile sui canali stabili, portandosi dietro la configurazione XML esistente. Per chi non lo ha ancora adottato, questo è probabilmente il momento più semplice per iniziare: niente più download manuali, niente più EULA da accettare a mano su ogni macchina, solo Enable-WindowsOptionalFeature e sysmon -i.

Fonte: 4sysops.com

Il 10 ottobre 2026 #Exchange Online smette di fare da “buon vicino” con le applicazioni che parlano ancora Exchange #Web Services (EWS). Da quella data, avere EWS abilitato sul tenant non basta più: ogni app, script o integrazione che chiama EWS deve comparire in un elenco esplicito di AppID autorizzati, altrimenti viene bloccata all’istante. È la fase finale di un ritiro annunciato da anni, ma che molti amministratori hanno rimandato perché “funzionava ancora tutto”. Questo articolo spiega cosa cambia davvero, come verificare se il vostro tenant è a rischio e come costruire l’allow list senza rompere le integrazioni .NET o #PowerShell che dipendono da EWS.

Cos’è EWSAllowedAppIDsEWSAllowedAppIDs è un parametro della configurazione #dell’organizzazione Exchange Online che funziona come allow list: contiene l’elenco, separato da virgole, degli Application ID (AppID) di Microsoft #Entra ID autorizzati a usare EWS. Qualsiasi chiamata EWS proveniente da un’app il cui AppID non è in quella lista viene rifiutata, indipendentemente dal fatto che EwsEnabled sia impostato su $true.

In pratica Microsoft sta trasformando un interruttore “on/off” globale in un controllo granulare per singola applicazione, lo stesso modello già visto con le app EWS “note” (Outlook per Mac, Skype for Business, strumenti di migrazione) negli anni precedenti.

Le date che contanoLa timeline comunicata da Microsoft nel Message Center (MC1485116) è questa:

2 ottobre 2026 — Microsoft individua i tenant interessati; da questa data ogni nuova abilitazione di EWS richiede la configurazione manuale dell’AppID.

8-9 ottobre 2026 — per i tenant che avevano già EwsEnabled = $true ma nessuna lista configurata, Microsoft popola automaticamente EWSAllowedAppIDs sulla base dell’attività osservata negli ultimi 60 giorni.

10 ottobre 2026 — inizia l’enforcement: le applicazioni non presenti nella lista perdono l’accesso a EWS.

Entro luglio 2027 — completamento del rollout su tutti gli ambienti, inclusi GCC, GCC High e DoD.

Il punto debole dell’auto-popolamento è evidente: un job pianificato che chiama EWS una volta al mese, o un’integrazione usata solo a fine trimestre, può restare fuori dalla finestra di osservazione dei 60 giorni e quindi fuori dall’allow list automatica.

Come verificare lo stato del tenantIl primo comando da eseguire, con il modulo Exchange Online PowerShell connesso, è:

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsEnabled, EwsAllowedAppIDsAttenzione a un dettaglio poco intuitivo: lo switch -RetrieveEwsOperationAccessPolicy è obbligatorio. Senza di esso, EwsAllowedAppIDs viene restituito vuoto anche se in realtà è configurato, inducendo falsi allarmi (o false sicurezze).

Trovare le applicazioni che usano ancora EWSPrima di scrivere la lista, bisogna sapere cosa c’è davvero in circolazione. L’approccio consigliato combina due fonti:

La lista attuale (se esiste) restituita dal comando sopra.

Le service principal di Microsoft Entra ID che possiedono il ruolo applicativo full_access_as_app su Exchange Online, il cui Role ID è dc890d15-9560-4a4c-9b7f-a736ec74ec40.

Con il modulo Microsoft Graph PowerShell è possibile incrociare le due liste:

Connect-MgGraph -Scopes "Application.Read.All"

$ewsRoleId = "dc890d15-9560-4a4c-9b7f-a736ec74ec40"
$exchangeSpn = Get-MgServicePrincipal -Filter "AppId eq '00000002-0000-0ff1-ce00-000000000000'"

Get-MgServicePrincipal -All | ForEach-Object {
$assignments = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $.Id
if ($assignments.AppRoleId -contains $ewsRoleId) {
[PSCustomObject]@{ DisplayName = $.DisplayName; AppId = $_.AppId }
}
}Il risultato è l’elenco delle app che potrebbero ancora dover parlare con EWS. Confrontandolo con la lista già approvata si individuano sia le app dimenticate (permesso presente, ma assenti dall’allow list) sia gli AppID “fantasma” già presenti nella lista ma di origine incerta, probabilmente da ripulire.

Configurare l’allow list senza sorpreseIl comando per impostare la lista è semplice, ma nasconde un comportamento critico: la lista viene sovrascritta interamente, non esiste un’operazione di append.

Set-OrganizationConfig -EwsEnabled $true -EwsAllowedAppIDs "f8d98a96-0999-43f5-8af3-69971c7bb423,,"Questo significa che ogni modifica deve includere tutti gli AppID necessari in un unico comando, Outlook e gli strumenti Microsoft compresi se risultano nei log di utilizzo (Outlook classico, Power Query in Excel, alcuni connettori Power BI possono ancora passare da EWS in scenari legacy). Dimenticare un solo AppID equivale a disattivare quell’integrazione dal giorno alla notte.

Un altro dettaglio operativo da non sottovalutare: le modifiche alla allow list richiedono fino a 24 ore per propagarsi su tutto il servizio. Chi arriva al 9 o 10 ottobre a correggere la lista rischia una finestra di downtime non banale.

La vera via d’uscita: migrare a Microsoft GraphEWSAllowedAppIDs è un cerotto, non una cura. La direzione strategica di Microsoft resta la stessa da anni: migrare da EWS alle API di Microsoft Graph per Mail, Calendar e Contacts. Per chi mantiene integrazioni .NET basate sulla EWS Managed API, il percorso tipico è sostituire le chiamate SOAP con il Microsoft Graph SDK per .NET:

var graphClient = new GraphServiceClient(credential, scopes);

var messages = await graphClient.Users["user@contoso.com"]
.Messages
.GetAsync(config =>
{
config.QueryParameters.Top = 25;
config.QueryParameters.Select = new[] { "subject", "from", "receivedDateTime" };
});Il vantaggio non è solo la sopravvivenza alla scadenza del 10 ottobre: le API Graph supportano permessi granulari con Microsoft Entra ID, throttling più predicibile e webhook nativi, assenti nel mondo EWS.

Checklist operativa prima del 10 ottobreEseguire Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy su ogni tenant gestito.

Incrociare la lista con le service principal che hanno il ruolo full_access_as_app.

Includere esplicitamente le app Microsoft first-party se emergono dai log di utilizzo.

Pianificare la modifica con almeno 24-48 ore di margine, non il 9 ottobre pomeriggio.

Avviare (o completare) la migrazione delle integrazioni critiche verso Microsoft Graph, trattando EWSAllowedAppIDs come misura ponte.

Fonte: 4sysops e Microsoft Tech Community.

Un’estensione che cambia pelle: da editor SQL a hub per agenti AICon la versione 1.46, rilasciata il 28 settembre 2026, l’estensione MSSQL per Visual Studio Code compie un passo che va ben oltre il consueto giro di bugfix. Microsoft porta a disponibilità generale (GA) il nuovo #SQL Formatter e, soprattutto, introduce un meccanismo di onboarding pensato per collegare in un solo click l’estensione alle Microsoft SQL Agent Skills, un pacchetto di competenze specialistiche per #GitHub #Copilot (e non solo) dedicato allo sviluppo, alla migrazione e alla gestione di database SQL Server e Azure SQL.

Per chi lavora ogni giorno con T-SQL, Entity Framework o pipeline di migrazione verso il #cloud, questa #release merita attenzione: non si tratta di un ennesimo assistente generico, ma di un sistema di “skill” specializzate che l’agente carica automaticamente in base al contesto della richiesta, senza sintassi speciale da imparare.

Cosa cambia in pratica nella versione 1.46Il changelog ufficiale del rilascio 1.46.0 elenca diverse novità, ma tre sono quelle rilevanti per un pubblico tecnico:

SQL Formatter GA: il formattatore T-SQL, finora in anteprima, diventa stabile e offre maggiore controllo su stile e layout del codice, utile per standardizzare gli script tra i membri di un team.

Getting Started page: una nuova pagina guidata (in preview) che centralizza l’installazione delle SQL Agent Skills con un click, i template per i #container di sviluppo locale e i percorsi di apprendimento guidato.

Notifiche audio: le query di lunga esecuzione possono ora segnalare il completamento con un suono, configurabile tramite mssql.query.playCompletionSound e mssql.query.completionSoundFile — piccolo dettaglio ma utile per chi lancia migrazioni di dati che richiedono minuti.

Si aggiungono inoltre miglioramenti a Schema Compare (filtri per tipo di oggetto), al Data API Builder (configurazioni di deployment persistenti, supporto alle colonne vector e json) e all’esportazione dei risultati dai SQL Notebook, che ora permette di copiare i dati come CSV, JSON, istruzioni INSERT INTO o elenchi per clausole IN.

Configurare le notifiche audioPer chi gestisce query batch pesanti, ecco un esempio di configurazione da aggiungere al file settings.json di VS Code:

{
"mssql.query.playCompletionSound": true,
"mssql.query.completionSoundFile": "default"
}
Le SQL Agent Skills: cosa sono davveroIl pezzo più interessante della release non è nell’estensione in sé, ma nel repository microsoft/microsoft-sql, che raccoglie i plugin installabili per agenti di coding pubblicati dal team prodotto di Microsoft SQL. Non è un singolo assistente, ma un insieme di cinque plugin specializzati:

microsoft-sql: competenze generali di sviluppo e gestione operativa su #Azure SQL.

microsoft-azuresqldb-container: workflow per lo sviluppo locale con database containerizzati.

microsoft-sql-vscode: integrazione specifica con l’estensione MSSQL di VS Code.

microsoft-sql-migration: assistenza per la migrazione da SQL Server on-premise ad Azure.

microsoft-sql-fdh: analisi dell’inventario e della sicurezza in Fabric Database Hub.

Il punto tecnico interessante è che questi plugin non sono legati esclusivamente a GitHub Copilot: il repository dichiara compatibilità anche con Claude Code, OpenAI Codex CLI, Cursor e Grok Build, segno che Microsoft sta puntando su uno standard di “agent skills” trasversale piuttosto che su un ecosistema chiuso.

Installazione delle skill nei diversi agentiL’installazione varia leggermente a seconda dell’agente utilizzato. Per GitHub Copilot CLI:

copilot plugin marketplace add microsoft/microsoft-sql
copilot plugin install microsoft-sql@microsoft-sql
Per Claude Code:

/plugin marketplace add microsoft/microsoft-sql
Per Cursor:

cursor-agent plugin marketplace add https://github.com/microsoft/microsoft-sql
Una volta installate, le skill vengono richiamate automaticamente in base al contesto della richiesta: non serve un prompt speciale. Un esempio citato nella documentazione è la richiesta in linguaggio naturale “connetti la mia app Node ad Azure SQL Database senza password”, che attiva la skill dedicata all’autenticazione con Microsoft Entra e alle managed identity — un tema che i lettori di questo blog conoscono già bene, essendo già stato trattato negli articoli su identità di workload e Managed Identity.

Cosa copre nel dettaglio l’insieme delle skillAl di là dei nomi dei plugin, le competenze incluse coprono un ventaglio di problemi molto concreti per chi lavora quotidianamente con SQL Server e Azure SQL:

Progettazione dello schema e migrazioni sicure (con generazione di script di rollback);

Autenticazione e sicurezza, inclusi Microsoft Entra ID e la row-level security;

Diagnostica delle performance tramite Query Store ed execution plan;

Ricerca vettoriale e scenari di retrieval-augmented generation (RAG) su dati relazionali;

Automazione del deployment con Azure Functions;

Import/export dei dati e procedure di recovery;

Valutazione e validazione delle migrazioni verso il cloud.

Quest’ultimo punto, in particolare, rende la skill microsoft-sql-migration un candidato interessante per chi sta pianificando lo spostamento di carichi SQL Server on-premise verso Azure SQL Managed Instance, un processo che tradizionalmente richiede settimane di assessment manuale con strumenti come il Data Migration Assistant.

Come iniziareIl percorso più rapido per provare tutto insieme è aggiornare l’estensione MSSQL all’ultima versione dal Marketplace di VS Code, aprire la nuova pagina “Getting Started” (accessibile dalla command palette) e da lì installare le skill con un click. È necessaria una sottoscrizione a GitHub Copilot attiva; una volta connessi a un database (SQL Server 2025, Azure SQL o SQL Database in Fabric), è sufficiente fare clic destro sul database e selezionare “Chat with this database” per iniziare a interagire in linguaggio naturale.

Per chi gestisce ambienti misti on-premise/cloud, vale la pena testare prima le skill in un container di sviluppo locale (workflow coperto dal plugin microsoft-azuresqldb-container) prima di applicarle a database di produzione: la generazione automatica di script DDL, per quanto assistita, va sempre validata da un DBA prima dell’esecuzione.

ConclusioneLa release 1.46 dell’estensione MSSQL conferma una tendenza che i sistemisti e gli sviluppatori .NET faranno bene a monitorare: l’AI assistita non si limita più al completamento del codice, ma si sta strutturando in “competenze” verticali, installabili e portabili tra agenti diversi. Per i team che gestiscono database SQL Server e Azure SQL, le nuove SQL Agent Skills rappresentano un punto di partenza concreto per automatizzare compiti ripetitivi — dalla scrittura di query alla pianificazione di migrazioni — mantenendo però la revisione umana come passaggio obbligato prima di ogni modifica su ambienti critici.

Fonte: Azure SQL Dev Corner – Microsoft DevBlogs e note di rilascio ufficiali su GitHub.

Perché la maggior parte degli script bash “funziona sulla mia macchina” e poi fallisce in produzioneChiunque amministri sistemi #Linux ha almeno uno script #bash scritto in dieci minuti per risolvere un problema urgente, che poi è finito silenziosamente in produzione tramite un cron job. Il problema è che uno script funzionale non è automaticamente uno script affidabile: la differenza si vede quando lo script gira senza terminale, senza nessuno che guarda l’output, magari in concorrenza con un’altra esecuzione dello stesso job.

In questo articolo ripassiamo rapidamente le basi della scrittura di script bash, ma ci concentriamo soprattutto su ciò che separa uno script “da developer” da uno pronto per l’automazione in un ambiente sistemistico reale: gestione degli errori, logging, locking e debugging.

Le fondamenta, in breveUno script bash è un file di testo con una sequenza di comandi che la shell esegue in ordine. La prima riga, lo shebang, indica al #kernel quale interprete usare:

#!/usr/bin/env bash
echo "Hello, world"Usare /usr/bin/env bash invece di /bin/bash hardcoded rende lo script più portabile su sistemi dove bash non risiede nel path standard (tipico su alcune distribuzioni minimali o #container). Reso eseguibile con chmod +x script.sh, lo script si lancia con ./script.sh.

Variabili e quotingUna convenzione diffusa negli ambienti Linux è usare il maiuscolo per variabili globali/di configurazione e il minuscolo per variabili locali, evitando di sovrascrivere variabili di sistema come PATH, HOME o USER. La regola più importante, spesso ignorata, è: quotare sempre le variabili.

SITE="miosito.it"
DATE=$(date +%Y-%m-%d)
echo "Backup di $SITE il $DATE"Senza le virgolette, un valore contenente spazi o caratteri speciali può spezzare la logica dello script in modi difficili da diagnosticare, specialmente con percorsi di file.

Argomenti e parametri posizionaliif [ $# -lt 1 ]; then
echo "Uso: $0 "
exit 1
fi
FILE="$1"Per script più complessi, destinati a essere invocati con flag (-v, --dry-run), conviene usare getopts per le opzioni brevi, che gestisce automaticamente la validazione e i messaggi di errore standard, evitando il parsing manuale di $@ con cicli while annidati e propensi a bug.

Dove gli script “da sviluppatore” falliscono in produzione1. Modalità strict e i suoi limiti realiLa pratica più citata è attivare la modalità rigorosa in testa allo script:

set -euo pipefail-e: esce immediatamente se un comando termina con stato diverso da zero

-u: tratta le variabili non definite come errore

-o pipefail: propaga il fallimento anche a metà di una pipeline, non solo sull’ultimo comando

È una buona base, ma va usata sapendo dove non funziona: set -e viene ignorato all’interno delle condizioni di if, nelle catene &&/|| e in certi contesti di funzione. Inoltre pipefail può creare falsi positivi con comandi come grep (che esce con stato diverso da zero se non trova corrispondenze) o head (che chiude il descrittore a monte, generando l’exit code 141 su SIGPIPE). Se il vostro script fa comando | grep pattern dentro uno script in pipefail, uno “zero risultati” legittimo può far abortire l’intero job: va gestito esplicitamente, ad esempio con grep pattern || true quando l’assenza di match è un esito accettabile.

2. Logging: se gira da cron, nessuno vede lo stdoutUno script lanciato da terminale che scrive con echo è inutile quando lo stesso script gira da cron: l’output, se non rediretto, o finisce in una mail di sistema che nessuno #legge, o si perde. La soluzione minima è una funzione di logging centralizzata:

LOGFILE="/var/log/watchdog.log"

log() {
echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" >> "$LOGFILE"
}

log "Script avviato"Questo pattern, combinato con local per le variabili interne alle funzioni (evitando l’inquinamento dello scope globale), è alla base di quasi ogni script di automazione che vale la pena mettere in cron.

3. Evitare esecuzioni concorrenti con flockUn errore classico: un job schedulato ogni minuto che, in caso di rallentamento (I/O lento, rete, dipendenza esterna), parte una seconda volta prima che la prima istanza sia terminata. Il modo standard per evitarlo su Linux è flock, che #usa un file descriptor come lock a livello di kernel:

#!/usr/bin/env bash
set -euo pipefail

LOCK_FILE="/run/lock/$(basename "$0").lock"
exec 200>"$LOCK_FILE"

if ! flock -n 200; then
echo "Esecuzione precedente ancora attiva, salto questo ciclo" >&2
exit 0
fi

echo "Lock acquisito, avvio il job reale"

... logica dello script ...Il flag -n rende l’acquisizione non bloccante: se un’altra istanza detiene già il lock, lo script esce subito invece di accodarsi. Se preferite attendere fino a un certo timeout invece di saltare il ciclo, -w 30 attende fino a 30 secondi prima di arrendersi. È preferibile salvare il lock file sotto /run/lock piuttosto che /tmp, che su molte distribuzioni viene ripulito periodicamente anche mentre un processo è in esecuzione. In alternativa, il locking si può applicare direttamente dal crontab senza toccare lo script:

*/1 * * * * /usr/bin/flock -n /run/lock/sync.lock /usr/local/bin/sync.sh4. Un watchdog completo, con logica di retryMettendo insieme logging, controllo di stato e gestione #dell’errore, un caso d’uso ricorrente per un sistemista è un watchdog che verifica un servizio #systemd e tenta un riavvio in caso di failure:

#!/usr/bin/env bash
set -euo pipefail

SERVICE="nginx"
LOGFILE="/var/log/watchdog.log"

log() {
echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" >> "$LOGFILE"
}

if ! systemctl is-active --quiet "$SERVICE"; then
log "$SERVICE risulta down. Tento il riavvio."
systemctl restart "$SERVICE"
if systemctl is-active --quiet "$SERVICE"; then
log "$SERVICE riavviato correttamente."
else
log "$SERVICE non è ripartito: serve intervento manuale."
exit 1
fi
fiNotate l’uso di exit 1 nel caso di fallimento definitivo: se questo script è invocato da un sistema di monitoraggio esterno (Nagios, Zabbix, un semplice controllo su exit code), un codice di uscita diverso da zero è ciò che permette di trasformare un log dimenticato in un alert reale.

Debug: strumenti che risparmiano orebash -n script.sh — verifica solo la sintassi, senza eseguire nulla

bash -x script.sh — traccia ogni comando con le variabili espanse, utile per capire cosa succede realmente riga per riga

set -x / set +x — attiva/disattiva il tracing solo su una porzione dello script

shellcheck script.sh — #analisi statica che individua variabili non quotate, condizioni malformate e pipe inutili che bash -n non può rilevare; è disponibile nei repository di tutte le principali distribuzioni ed è ormai lo standard de facto prima di qualsiasi merge in un repository di script di automazione

ConclusioneLe basi della sintassi bash si imparano in un pomeriggio; la differenza tra uno script giocattolo e uno adatto alla produzione sta tutta negli aspetti che spesso vengono aggiunti solo dopo il primo incidente in produzione: modalità strict usata consapevolmente, logging pensato per l’esecuzione non interattiva, locking per evitare sovrapposizioni, e una pipeline minima di verifica (shellcheck più test manuale con bash -x) prima di schedulare qualsiasi cosa su cron o systemd timer. Vale la pena trattare gli script di automazione con lo stesso rigore riservato al codice applicativo: revisione, versionamento e, quando possibile, un minimo di test automatizzati.

Fonte originale: Linux Bash Scripting: Writing Your First Script, LinuxBlog.io.

Il 29 settembre 2026 Microsoft ha reso generalmente disponibili i #container #WSL, portando su #Windows la possibilità di eseguire container #Linux nativi senza installare #Docker Desktop. La funzionalità arriva con wslc.exe, un nuovo strumento a riga di comando integrato direttamente nel Windows Subsystem for Linux (WSL 3.0.1), e segna un passo importante per chi lavora quotidianamente con container su macchine Windows: sviluppatori .NET, team #DevOps e sistemisti che gestiscono ambienti ibridi.

In questo articolo vediamo cosa cambia rispetto a Docker Desktop, come installare e usare wslc, quali sono i controlli enterprise disponibili tramite #Intune e #Defender for Endpoint, e quali limiti bisogna conoscere prima di adottarlo in produzione.

Perché WSL containers e non “solo” Docker DesktopFino ad oggi, eseguire container Linux su Windows significava quasi sempre installare Docker Desktop, che a sua volta si appoggia su una VM WSL2 per fornire il kernel Linux. Con i container WSL, Microsoft sposta il motore dei container direttamente dentro l’infrastruttura WSL, eliminando uno strato intermedio: niente demone Docker separato da gestire, niente licenza Docker Desktop da considerare per le aziende con più di 250 dipendenti o oltre 10 milioni di dollari di fatturato (requisito che per molte realtà italiane ha reso Docker Desktop un costo da giustificare).

Il risultato dichiarato da Microsoft è un accesso ai file Windows fino a 2 volte più veloce rispetto alle soluzioni basate su virtiofs tradizionale, grazie a un nuovo modello di rete chiamato internamente “Consommé mode”, che instrada il traffico della VM attraverso un processo Windows eseguito con i permessi dell’utente della sessione, migliorando la compatibilità con VPN aziendali e firewall perimetrali — uno scenario molto comune nelle reti enterprise italiane dove Docker Desktop spesso va in conflitto con client VPN come Cisco AnyConnect o Fortinet.

Installazione e primi comandiNon serve installare nulla di separato: wslc.exe è incluso a partire da WSL 3.0.1. Basta aggiornare WSL dal prompt dei comandi o da PowerShell:

wsl --update
wsl --versionIl comando wsl --version deve riportare almeno la 3.x (oppure 2.9.3+ per chi è rimasto sul canale di anteprima). Fatto questo, si può avviare subito un primo container di prova:

wslc run --rm -it ubuntu:latest bash -c "echo Hello world from WSL container!"Per un caso d’uso più realistico, ecco come avviare un web server Nginx in background con il port forwarding verso l’host Windows:

wslc run -it --rm -d -p 8080:80 --name web nginx
curl localhost:8080La gestione del ciclo di vita dei container ricalca la sintassi Docker, cosa che rende la curva di apprendimento quasi nulla per chi già conosce Docker CLI:

wslc container ps
wslc container stop web
wslc container restart web
wslc container cp web:/var/log/nginx/access.log .
wslc system info
wslc eventsCon la GA sono arrivati anche comandi per la gestione della rete, utili quando si orchestrano più container che devono comunicare tra loro:

wslc network create mynet
wslc network connect mynet web
wslc network disconnect mynet webPer le immagini, sono supportati i flag più comuni per operazioni di pull/push ed ispezione:

wslc pull --all-tags myregistry/myimage
wslc image list --all --digests
wslc image inspect --size myregistry/myimageArchitettura: cosa succede sotto il cofanoDal punto di vista architetturale, Microsoft ha separato le responsabilità in due processi distinti:

wslservice.exe crea la macchina virtuale WSL ma non ne mantiene la proprietà operativa dei container;

wslcsession.exe, eseguito a livello utente, gestisce effettivamente i container, il mounting dei volumi e il binding delle porte.

Questa separazione mantiene isolate le operazioni privilegiate dal resto, un dettaglio che conta per chi deve valutare la postura di sicurezza dell’ambiente. Ogni sessione utente ha il proprio disco virtuale dedicato, salvato in %AppData%\Local\wslc\sessions, che contiene immagini, container, reti e volumi di quella sessione. I path Windows vengono montati tramite virtiofs, mentre i filesystem nativi Linux usano volumi basati su VHD per prestazioni migliori.

Supporto GPU e integrazione .NETPer chi sviluppa su Windows con carichi di lavoro che richiedono accelerazione hardware (training di modelli, inferenza locale, elaborazione video), l’accesso alla GPU è esposto tramite il nuovo pacchetto NuGet Microsoft.WSL.Containers, che oltre alla GPU espone anche stdin/stdout, mount di file e configurazione di rete direttamente da codice C#. È un’ottima notizia per i team .NET che vogliono orchestrare container Linux senza uscire dal proprio stack di sviluppo abituale, magari dentro una pipeline di test o un tool interno scritto in C#.

Da notare che il supporto per la projection C++/WinRT è ancora in anteprima e soggetto a breaking change, mentre l’API per sviluppatori C# risulta più stabile e pronta per un uso quotidiano.

Controlli enterprise: Intune e Defender for EndpointPer i reparti IT che devono governare l’adozione di questa tecnologia in azienda, Microsoft ha introdotto due leve di controllo tramite Intune:

Allow WSL containers access: un interruttore on/off per abilitare o disabilitare completamente la funzionalità sui dispositivi gestiti;

WSL containers registry allow list: permette di restringere il pull delle immagini solo ai registry approvati, un controllo fondamentale per evitare che gli utenti scarichino immagini da fonti non verificate.

Sul fronte della sicurezza runtime, il plugin WSL di Microsoft Defender for Endpoint è stato esteso per coprire anche i container, mostrando attività di processo, file e rete collegate all’host Windows. È importante sottolineare che si tratta di visibilità e capacità di indagine, non di un meccanismo di enforcement in tempo reale: Defender segnala e documenta, ma la prevenzione attiva resta affidata alle policy Intune.

I limiti da conoscere prima di migrarePrima di sostituire Docker Desktop in produzione, vale la pena considerare alcuni limiti ancora presenti alla GA:

Nessun supporto Compose: è la funzionalità più richiesta dalla community e il lavoro è iniziato, ma Microsoft non ha ancora comunicato una data di rilascio. Chi ha workflow multi-servizio basati su docker compose up dovrà continuare a usare strumenti alternativi o avviare manualmente i singoli container;

Compatibilità “quasi” totale: test di terze parti riportano buona compatibilità con i comandi Docker esistenti, ma non totale — vale la pena testare gli script di automazione esistenti prima di un rollout su larga scala;

API C++/WinRT instabile: chi sviluppa tooling nativo in C++ dovrà aspettarsi possibili breaking change nelle prossime release.

Conclusione: chi dovrebbe provarlo subitoPer sviluppatori singoli e piccoli team che non dipendono da Docker Compose, i container WSL rappresentano già oggi un’alternativa solida, gratuita e integrata nativamente in Windows, con un vantaggio prestazionale concreto sull’I/O dei file. Per i team che si affidano a Compose nei workflow quotidiani, conviene affiancare wslc agli strumenti attuali e monitorare l’evoluzione del supporto. Per i reparti IT enterprise, il consiglio è di testare i controlli di governance (Intune e Defender) in un gruppo pilota prima di abilitare la funzionalità su larga scala, verificando in particolare il comportamento con le VPN aziendali e i registry Docker privati già in uso.

Fonte: 4sysops.com e WindowsForum

A partire da metà ottobre 2026, Microsoft #Entra ID inizierà a bloccare gli script di terze parti iniettati nelle pagine di accesso ospitate su login.microsoftonline.com. La modifica, annunciata tramite il Microsoft 365 Message Center (riferimento MC1481309), introduce una Content Security Policy (CSP) che limita l’esecuzione di codice JavaScript ai soli domini CDN approvati da Microsoft, chiudendo di fatto una superficie di attacco che negli ultimi anni è stata sfruttata per campagne di cross-site scripting (XSS) contro i flussi di autenticazione aziendale.

Per chi amministra ambienti Microsoft 365 e #Azure, questa non è una modifica da ignorare: se la vostra organizzazione utilizza estensioni #browser, strumenti di monitoraggio #dell’autenticazione o soluzioni di personalizzazione del branding che iniettano codice nella pagina di login, è il momento di fare un inventario e testare prima che il blocco diventi effettivo.

Cosa cambia esattamenteOggi alcune soluzioni di sicurezza, monitoraggio e personalizzazione aggiungono funzionalità alla pagina di accesso di Entra ID iniettando script direttamente nel DOM della pagina ospitata da Microsoft. È una pratica comune per strumenti che vogliono, ad esempio, raccogliere metriche aggiuntive sul comportamento dell’utente durante il login, aggiungere elementi di branding personalizzato oltre a quanto consentito dalle opzioni native di Entra ID, oppure integrare controlli di sicurezza di terze parti nel flusso di autenticazione.

Il problema è che l’iniezione di script, per quanto utile, amplia la superficie d’attacco della pagina più critica di tutte: quella dove gli utenti inseriscono le proprie credenziali. Un header CSP mal configurato, un’estensione compromessa o una libreria di terze parti vulnerabile possono trasformarsi in un vettore per attacchi XSS mirati a sottrarre credenziali o token di sessione.

Con questa modifica, Microsoft aggiunge un header CSP alle pagine di sign-in che consente l’esecuzione solo di script provenienti da domini CDN Microsoft attendibili. Qualsiasi script esterno iniettato da estensioni browser o strumenti di terze parti smetterà di funzionare.

Tempistiche del rolloutSecondo l’annuncio nel Message Center, il rollout è pianificato nel seguente modo:

Inizio: metà ottobre 2026;

Completamento: fine ottobre 2026;

Scadenza consigliata per le verifiche: 19 ottobre 2026.

Un dettaglio importante: la modifica è abilitata di default come parte dell’aggiornamento del servizio e non richiede alcuna configurazione da parte del tenant. Non esiste quindi un interruttore per ritardare l’attivazione: l’unica strategia possibile è prepararsi in anticipo, non rimandare la verifica a dopo il rollout.

Chi è interessato (e chi no)Il blocco si applica esclusivamente alle esperienze di accesso basate su browser che transitano da login.microsoftonline.com. Rientrano nel perimetro le organizzazioni che:

autenticano gli utenti tramite il flusso #web standard su login.microsoftonline.com;

hanno distribuito estensioni browser o strumenti che iniettano script nella pagina di login per finalità di monitoraggio, sicurezza o personalizzazione.

Restano invece esclusi dall’impatto:

i tenant Microsoft Entra External ID, non toccati da questa modifica;

le applicazioni che si autenticano tramite MSAL (Microsoft Authentication Library) o tramite flussi basati su API, dato che la CSP si applica solo alle interfacce web renderizzate nel browser.

In altre parole: il normale login da browser continuerà a funzionare per tutti gli utenti, anche per quelli le cui organizzazioni usano strumenti che verranno bloccati. Semplicemente, quegli strumenti aggiuntivi smetteranno di funzionare o genereranno errori silenziosi, senza impedire l’accesso.

Cosa deve fare un amministratore prima di ottobreSe la vostra organizzazione non utilizza strumenti che iniettano script nelle pagine di login, non è richiesta alcuna azione. Per tutti gli altri, il percorso di preparazione dovrebbe includere questi passaggi:

Censire gli strumenti in uso. Verificate quali estensioni browser aziendali, soluzioni #SIEM/SOAR o prodotti di customer identity management iniettano codice nelle pagine di sign-in Entra ID. Spesso questi strumenti sono stati distribuiti anni fa da team diversi (sicurezza, UX, help desk) e la conoscenza del “perché sono lì” si è persa nel tempo.

Testare in un ambiente pilota. Create un tenant di test o isolate un gruppo di utenti pilota per verificare l’impatto reale prima che il blocco diventi globale a metà ottobre.

Identificare alternative supportate. Per esigenze di branding personalizzato, Entra ID offre opzioni native (Company Branding) che non richiedono iniezione di script e che continueranno a funzionare regolarmente. Per esigenze di monitoraggio, valutate soluzioni basate su log di sign-in e Microsoft Graph API invece che su script lato client.

Aggiornare la documentazione e informare l’help desk. Se uno strumento di monitoraggio smette improvvisamente di raccogliere dati dopo metà ottobre, il team di supporto deve sapere che la causa è questa modifica pianificata e non un guasto imprevisto.

Verificare i fornitori terzi. Se usate prodotti di sicurezza o identity verification di terze parti che si integrano con la pagina di login Entra ID, contattate il vendor per sapere se e come stanno adattando il proprio prodotto alla nuova CSP.

Perché questa modifica ha senso dal punto di vista della sicurezzaLe pagine di autenticazione sono per definizione l’obiettivo più ambito dagli attaccanti: chi riesce a eseguire codice arbitrario in quel contesto può potenzialmente intercettare credenziali, manipolare il DOM per ingannare l’utente, o dirottare token di sessione prima ancora che l’utente completi l’MFA. Irrigidire la CSP su un dominio ad altissimo valore come login.microsoftonline.com è una misura coerente con la direzione che Microsoft ha preso negli ultimi mesi su hardening dell’identità (si pensi anche agli interventi recenti su Conditional Access e sul monitoraggio dei token refresh).

Per i sistemisti, questo caso è anche un promemoria generale: qualsiasi integrazione che si basa sull’iniezione di script in pagine di terze parti — specialmente pagine di login — va considerata intrinsecamente fragile, perché può essere disabilitata da un giorno all’altro con un aggiornamento lato fornitore, senza preavviso configurabile. Dove possibile, è preferibile orientarsi verso integrazioni ufficiali basate su API (Microsoft Graph, webhook, log di audit) piuttosto che su meccanismi non supportati.

ConclusioneIl blocco dello script injection su Entra ID è una modifica di sicurezza silenziosa ma potenzialmente dirompente per chi non si prepara: non blocca l’accesso degli utenti, ma può interrompere strumenti di monitoraggio o personalizzazione distribuiti da tempo senza che nessuno se ne accorga fino a quando smettono di funzionare. L’azione concreta da fare questa settimana è una sola: verificare con il proprio team di identity management se esistono integrazioni basate su script injection nella pagina di login, e pianificare un test prima della finestra di rollout di metà ottobre 2026.

Fonte: Petri IT Knowledgebase e Microsoft 365 Message Center (MC1481309)

Canonical ha annunciato un cambio radicale nel ciclo di rilascio del #kernel #Ubuntu: dalle attuali cadenze separate — quattro settimane per gli aggiornamenti “regolari” e due settimane per quelli di sicurezza — si passa a un ciclo unico di Stable #Release Update (SRU) di due settimane, sovrapposto, che si traduce in un nuovo build del kernel disponibile ogni singola settimana. La motivazione, spiegata direttamente da Canonical, non è la solita ricerca di agilità #DevOps: è la necessità di reggere il ritmo di un flusso di #CVE che sta crescendo in modo esponenziale a causa della scoperta di bug assistita dall’intelligenza artificiale.

Per chi amministra flotte Ubuntu in produzione — LTS in primis, ma anche release interim — questo è un cambiamento che tocca direttamente il processo di #patch management, i cicli di test di regressione interni e la pianificazione delle finestre di manutenzione. Vale la pena capire cosa cambia concretamente e perché.

Il problema: l’IA ha trasformato la caccia ai bug in una linea di produzioneNel blog ufficiale, Canonical descrive con chiarezza la causa del cambiamento: “large language models (LLM) e agenti IA specializzati hanno trasformato la scoperta di bug da un processo manuale e dispendioso in termini di tempo a un motore altamente automatizzato”. In pratica, strumenti basati su modelli linguistici vengono oggi usati su larga scala per analizzare il codice sorgente del kernel #Linux alla ricerca di pattern potenzialmente vulnerabili, con una velocità e una copertura che nessun team di revisione umano potrebbe eguagliare.

Questo si somma a un cambiamento organizzativo avvenuto a monte: la community del kernel Linux è diventata una CVE Numbering Authority (CNA), il che significa che assegna direttamente identificatori CVE a migliaia di bug che in precedenza non venivano nemmeno tracciati come vulnerabilità formali. Il criterio adottato a monte è volutamente ampio: quasi ogni tipo di bug che può influenzare un sistema in esecuzione viene potenzialmente classificato come vulnerabilità di sicurezza, anche quando l’impatto pratico di sfruttabilità è minimo o nullo.

Il risultato combinato di questi due fattori — scoperta automatizzata su scala industriale e classificazione CVE estremamente inclusiva — è un flusso di identificatori CVE relativi al kernel che è semplicemente esploso rispetto a quanto i cicli di rilascio tradizionali erano progettati per gestire.

Come cambia il ciclo di rilascioIl vecchio modello prevedeva due binari separati e asincroni: un ciclo “feature” di quattro settimane per gli aggiornamenti generali del kernel e un ciclo di sicurezza dedicato di due settimane per le patch critiche. Questa separazione creava inevitabilmente colli di bottiglia quando il volume di CVE da processare superava la capacità del ciclo breve.

Il nuovo modello unifica tutto in cicli SRU di due settimane, ma sovrapposti: un nuovo ciclo inizia ogni settimana, invece che ogni due. La struttura interna di ciascun ciclo si articola così:

Settimana 1 — Preparazione: build del kernel e smoke test per verificarne la funzionalità di base. Entro la fine della settimana, i pacchetti vengono pubblicati nel pocket -proposed del repository Ubuntu.

Settimana 2 — Certificazione: test estesi sull’hardware certificato Ubuntu, verifica dell’integrazione con il resto della distribuzione e test di regressione approfonditi. Al termine, il kernel passa dai repository -proposed ai repository stabili.

Poiché i cicli si sovrappongono con partenza scaglionata di una settimana, il risultato netto per l’utente finale è la disponibilità di un nuovo kernel stabile ogni settimana, anziché ogni due o quattro come in precedenza.

Due velocità per due esigenze diverseUn aspetto interessante per chi gestisce infrastrutture di produzione è che il nuovo schema offre implicitamente due percorsi:

Il percorso “veloce”: seguire il pocket -proposed, disponibile già dalla fine della prima settimana del ciclo. Questo dà accesso alle correzioni con una settimana di anticipo, ma sposta sull’organizzazione l’onere del test di certificazione che normalmente svolge Canonical — un compromesso ragionevole per ambienti con forte esposizione a exploit noti e capacità interna di validazione rapida.

Il percorso “standard”: attendere il completamento del ciclo di due settimane e ricevere kernel pienamente testati e certificati sull’hardware supportato da Canonical, la scelta più sensata per la maggior parte degli ambienti di produzione che non hanno un processo di staging in grado di assorbire release settimanali non completamente validate.

Cosa succede mentre si aspetta la patch: workaround entro 24-48 oreUn elemento pratico rilevante per chi fa incident response e vulnerability management: Canonical si impegna a fornire workaround o raccomandazioni di hardening entro 24-48 ore dalla divulgazione pubblica di una vulnerabilità, anche quando la patch definitiva richiede più tempo per completare il ciclo di certificazione. Questo riduce la finestra di esposizione reale, permettendo ai team di sicurezza di portare i sistemi in uno stato “difendibile” (mitigazione temporanea, disabilitazione di moduli non essenziali, regole di firewall aggiuntive) senza dover attendere il rilascio completo del kernel patchato.

È un approccio che ricalca, concettualmente, quanto già fanno da tempo fornitori come Red Hat con gli advisory di mitigazione temporanea, ma applicato qui specificamente al contesto del kernel Ubuntu e giustificato esplicitamente dal volume di CVE indotto dall’IA.

Implicazioni pratiche per i team di sistemisticaPer chi gestisce Ubuntu Server, container base image derivate da Ubuntu o flotte cloud su Azure/AWS/GCP basate su Ubuntu LTS, questo cambiamento ha alcune conseguenze operative concrete da pianificare:

Finestre di manutenzione più frequenti: se finora la pianificazione delle patch del kernel seguiva un ritmo mensile o bisettimanale, ora bisogna prevedere un flusso settimanale, anche se non ogni release richiederà necessariamente un riavvio immediato in produzione.

Revisione della strategia di live patching: chi utilizza Ubuntu Pro con Livepatch per applicare patch del kernel senza riavvio dovrebbe verificare come la nuova cadenza si integra con il servizio, dato che un flusso più fitto di CVE potenzialmente livepatchabili può cambiare la frequenza con cui Livepatch interviene.

Triage dei CVE più selettivo: con un CNA a monte che classifica come vulnerabilità anche bug dall’impatto pratico marginale, diventa ancora più importante per i team di sicurezza avere un processo di triage basato su sfruttabilità reale ed exposure, invece di rincorrere ogni singolo identificativo CVE con la stessa priorità.

Automazione del patch testing: con release settimanali, i team che ancora validano manualmente ogni kernel prima del rollout in produzione dovrebbero considerare l’automazione dei test di regressione per non trasformare la nuova cadenza in un collo di bottiglia interno.

ConclusioneIl passaggio di Ubuntu a un ciclo di rilascio del kernel settimanale è un segnale che va oltre la singola distribuzione: è una risposta diretta a come l’IA sta cambiando la superficie di vulnerabilità nota del software open source, generando un volume di scoperte che i processi tradizionali di patch management, pensati per un ritmo pre-IA, faticano a sostenere. Per i team di sistemistica, il messaggio pratico è chiaro: automatizzare dove possibile il testing dei kernel, affinare i criteri di triage dei CVE in base al rischio reale e verificare fin da ora come la nuova cadenza settimanale si inserisce nei propri processi di change management, prima che diventi lo standard anche per altre distribuzioni enterprise.

Fonte: Canonical Blog e 4sysops

Microsoft ha ufficializzato quello che molti amministratori di sistema temevano da tempo: #Windows Deployment Services (WDS), insieme al suo motore #PXE (Preboot Execution Environment), è stato dichiarato deprecato a partire dalla prossima #release di Windows Server. Non si tratta di una rimozione immediata — il ruolo resta funzionante su Windows Server 2016, 2019, 2022, 23H2 e 2025 — ma la direzione è chiara, e chi gestisce infrastrutture di imaging bare-metal farebbe bene a iniziare a pianificare la migrazione già ora, prima che la finestra di manovra si riduca.

In questo articolo vediamo cosa cambia esattamente, perché Microsoft ha preso questa decisione, e quali sono le alternative concrete indicate dalla documentazione ufficiale, con relativi pro e contro per chi deve scegliere il percorso di migrazione.

Cosa viene deprecato, nel dettaglioLa deprecazione non riguarda un singolo componente, ma l’intero stack WDS:

Il ruolo server WDS e i suoi componenti Deployment Server / Transport Server

La funzionalità di PXE boot e network bootstrap fornita da WDS

Gli strumenti di gestione, le CLI (wdsutil), le API e i percorsi di attivazione del servizio

Il trasporto multicast e i flussi di deployment che ne dipendono

I componenti WinPE-WDS-Tools usati per costruire immagini di boot personalizzate

Non è una novità improvvisa: già nel 2021 Microsoft aveva deprecato i flussi di boot.wim basati su WDS per Windows 11 e versioni successive, e ad aprile 2026 gli scenari di deployment “hands-free” tramite WDS sono stati disabilitati di default nelle installazioni più recenti. La deprecazione formale del ruolo server è quindi l’ultimo tassello di un percorso iniziato da anni.

Perché ora?WDS si appoggia su un’architettura di rete e boot (BIOS/PXE legacy, multicast, protocolli TFTP non cifrati) che non si allinea più con i requisiti di sicurezza moderni: niente autenticazione del client prima del trasferimento dell’immagine, nessuna cifratura del traffico di boot, e una superficie di attacco che include il classico problema del “server DHCP/PXE non autorizzato in rete”. Con l’adozione crescente di UEFI Secure Boot, TPM 2.0 e gestione #cloud-first dei dispositivi, mantenere un componente legacy come WDS come via principale di provisioning ha sempre meno senso per Microsoft.

Le alternative raccomandate1. Configuration Manager PXE responder (senza WDS)È l’alternativa che Microsoft raccomanda in modo più esplicito per chi già #usa (o può adottare) Microsoft Configuration Manager (ConfigMgr/MECM). Il PXE responder di ConfigMgr può funzionare in modalità standalone, senza dipendere dal ruolo WDS sottostante, gestendo direttamente le richieste di boot di rete. La distribuzione del sistema operativo tramite ConfigMgr (task sequence, immagini, driver package) resta una capacità pienamente supportata e non deprecata: cambia solo il livello di trasporto della fase di boot iniziale.

Per chi ha già un’infrastruttura ConfigMgr consolidata, questa è generalmente la strada a minor attrito: la migrazione richiede di riconfigurare il ruolo di distribuzione point per gestire il PXE senza il servizio WDS legacy sottostante, verificando compatibilità di firmware e switch di rete (in particolare per IP helper/DHCP relay).

2. Soluzioni PXE di terze partiEsistono implementazioni PXE non Microsoft, sia commerciali sia open source, che restano ovviamente non toccate dalla deprecazione. Tra le più note in ambito #Linux/eterogeneo:

Esempio: avvio di un server PXE minimale con dnsmasq su Linux

sudo apt install dnsmasq
cat <<EOF > /etc/dnsmasq.d/pxe.conf
interface=eth0
dhcp-range=192.168.10.100,192.168.10.200,12h
dhcp-boot=pxelinux.0
enable-tftp
tftp-root=/srv/tftp
EOF
sudo systemctl restart dnsmasqSoluzioni come netboot.xyz, iPXE o piattaforme MDM/deployment di terze parti offrono spesso funzionalità più moderne (boot via HTTP/HTTPS, script di boot dinamici, interfacce #web) rispetto al vecchio WDS, ma richiedono comunque un progetto di migrazione: mappatura delle immagini esistenti, retraining del personale, e in alcuni casi costi di licenza.

3. UEFI HTTP(S) BootPer i dispositivi con firmware UEFI moderno, il boot via HTTP(S) è un’alternativa nativa al PXE tradizionale, con il vantaggio di poter cifrare il trasferimento dell’immagine di boot. Microsoft è però esplicita nel dire che non è un sostituto diretto del PXE responder di ConfigMgr: si tratta di un meccanismo di trasporto complementare, utile in scenari specifici (ad esempio boot attraverso reti che non supportano bene il multicast/broadcast PXE), ma che da solo non copre tutte le funzionalità di un flusso di OS deployment completo.

4. Windows Autopilot per i nuovi dispositiviPer chi acquista hardware nuovo, Microsoft continua a spingere verso Windows Autopilot: il provisioning avviene “out of the box”, senza immagine personalizzata da distribuire via rete, con il dispositivo che si registra e si configura da cloud (Entra ID/Intune) al primo avvio. Non è un rimpiazzo 1:1 di WDS per il re-imaging di parco macchine esistente, ma per il ciclo di vita dei nuovi PC riduce drasticamente (o azzera) la necessità di un’infrastruttura PXE.

Come pianificare la migrazionePrima di scegliere una strada, la documentazione Microsoft raccomanda alcuni passi di analisi che vale la pena seguire alla lettera:

Censire tutte le implementazioni WDS attive nell’organizzazione, comprese quelle “nascoste” in filiali o laboratori

Verificare le dipendenze da Configuration Manager, immagini WinPE personalizzate e utilizzo di wdsutil in script di automazione

Valutare l’impatto sulla capacità di deployment unicast se oggi si fa affidamento sul multicast di WDS per grandi rollout simultanei

Validare le alternative in condizioni realistiche di rete e firmware, non solo in laboratorio: switch, VLAN, IP helper e compatibilità UEFI vanno testati sul campo

Per organizzazioni di medie e grandi dimensioni, la combinazione più pragmatica nel breve-medio termine è spesso: ConfigMgr PXE responder per il parco macchine esistente da re-immaginare, e Windows Autopilot per tutto l’hardware di nuovo acquisto. Le soluzioni di terze parti restano un’opzione valida soprattutto per ambienti eterogenei Linux/Windows che già non dipendevano fortemente da WDS.

ConclusioneNon c’è ancora una data di rimozione definitiva per WDS, ma il messaggio di Microsoft è inequivocabile: è il momento di uscire dalla comfort zone del vecchio PXE responder integrato in Windows Server. Chi gestisce infrastrutture di imaging dovrebbe iniziare subito il censimento delle dipendenze e un piccolo pilot su una delle alternative disponibili, per evitare di trovarsi a rincorrere la migrazione quando il supporto verrà effettivamente ritirato.

Fonte: Microsoft Support e 4sysops

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Il flusso diagnostico corretto segue quattro passaggi in sequenza:

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

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

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

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

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

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

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

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

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

1: intervallo di refresh in secondi

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

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

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

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

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

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

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

iotop offre una vista più mirata:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Il piano di ritiro si articola in tre fasi:

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

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

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

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

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

Attivazione online (equivalente di slmgr.vbs /ato)

Invoke-OSLicense -ActivateOnline

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

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

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

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

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

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

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

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

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

Informazioni sulla licenza (locale o estesa)

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

Attivazione con chiave KMS rilevata automaticamente

Start-WindowsActivation -UseKmsClientKey

Attivazione su una macchina remota

Start-WindowsActivation -Computer WS01

Reset delle impostazioni di attivazione

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

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

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

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

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

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

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

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

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

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

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

Visual Studio Code

.NET SDK 10 o successivo

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

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

Plugin agente WinUI (winui@awesome-copilot)

Estensione WinApp per VS Code

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

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

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

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

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

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

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

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

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

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

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

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

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

GitHub Copilot CLI

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

Claude Code

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Exchange 2016 CU23 + Oct25SU → build 15.1.2507.61

Exchange 2019 CU15 + Oct25SU → build 15.2.1748.39

Exchange 2019 CU14 + Oct25SU → build 15.2.1544.36

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Fonte: Practical365 e Microsoft Tech Community.

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

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

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

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

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

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

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

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

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

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

ignoredups – salta i duplicati consecutivi

ignoreboth – combina entrambi i comportamenti precedenti

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Mostra tutta la cronologia con numerazione

history

Ultimi 20 comandi

history 20

Cerca nella cronologia

history | grep nginx

Scrive subito su disco la sessione corrente

history -a

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

history -d 497

Elimina e persiste la rimozione sul file

history -d 497 && history -w

Svuota completamente memoria e file

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

set +o history

comandi non registrati qui

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

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

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

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

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

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

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

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

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

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

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

Configurazione History Bash

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

shopt -s histappend
shopt -s histverify

Sincronizza la cronologia tra terminali dopo ogni comando

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Elencare tutti i parametri disponibili

sysctl -a

Leggere un singolo parametro

sysctl net.ipv4.tcp_syncookies

Modificarlo temporaneamente (non sopravvive al riavvio)

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

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

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

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

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

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

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

Verifica gli algoritmi disponibili

sysctl net.ipv4.tcp_available_congestion_control

Se necessario, carica il modulo

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

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

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

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

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

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

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

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

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

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

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

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

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

Rete: buffer TCP

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

Rete: congestion control

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

Rete: gestione connessioni

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

Memoria

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

File descriptor

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

Sicurezza

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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