Cristian Castellari — CV, Progetti e Blog

DocSteer: un tema Jekyll per la documentazione

Tue, 01 Sep 2026 09:00:00 +0200

Chi lavora in IT passa una parte non piccola della giornata dentro documentazione: runbook, procedure, articoli di knowledge base, wiki interne che nessuno ha più aperto da un anno. E la parte difficile non è quasi mai scriverla — è farla ritrovare a chi ne ha bisogno mesi dopo, con un problema aperto e poca pazienza.

DocSteer è un tema Jekyll per esattamente quel tipo di sito: documentazione tecnica, portali di supporto, knowledge base interne. La barra laterale raggruppata, la ricerca e l’indice “In questa pagina” non sono decorazione — sono il motivo per cui il sito esiste.

Perché un altro tema per la documentazione
Cosa fa
Perché “DocSteer”
Come si usa
Come l’ho costruito
Cosa manca ancora
Perché è gratis

Perché un altro tema per la documentazione

Di temi Jekyll per la documentazione ce ne sono già parecchi, e alcuni sono ottimi. Quello che volevo io era qualcosa di più stretto: un tema che si mettesse in piedi in un pomeriggio, che non trascinasse dentro una toolchain Node, e che non chiedesse di imparare un altro framework prima di poter scrivere la prima pagina.

Il tema di questo sito, che pure ho estratto e pubblicato a parte, non ci arrivava: è pensato per un sito personale bilingue con un CV, qualche pagina e un blog. La documentazione è un problema diverso. Serve una barra laterale raggruppata e collassabile, una ricerca che regga su decine di pagine, un indice costruito da solo, un pager avanti/indietro che segua l’ordine della navigazione. Sono tutte cose che si possono aggiungere a mano, una alla volta — ed è esattamente così che si finisce con un tema da blog pieno di pezze.

Cosa fa

Sei skin di colore — aqua, violet, mint, ember, graphite, clay — ognuna con variante chiara e scura, definite in un’unica mappa Sass ed emesse come custom property CSS. Il colore di brand di ogni skin supera il contrasto WCAG AA (4.5:1) sul proprio sfondo.
Tema scuro che segue il sistema operativo, con toggle manuale salvato in localStorage e nessun lampo bianco al caricamento.
Ricerca live — un indice JSON generato da Liquid e una modale da tastiera (/ oppure ⌘K), senza una sola libreria esterna.
Indice automatico costruito dagli heading, con scroll-spy, e pager avanti/indietro che segue da solo l’ordine della navigazione.
Pagine FAQ — layout: faq genera un accordion basato su <details> nativo, con un anchor per domanda, dati strutturati FAQPage, e ogni domanda indicizzata come risultato di ricerca a sé.
Lightbox immagini con gallerie, didascalie e navigazione da tastiera.
Font Awesome 6.5.2 Free incluso localmente di default, così il sito funziona offline e dietro i firewall aziendali. Il CDN resta un’opzione.
SEO — jekyll-seo-tag, sitemap, feed RSS, Open Graph e JSON-LD.

Niente framework CSS, nessuno step di build Node: circa 7 kB di JavaScript vanilla in tutto, tutto defer, CSS compresso e Sass compilato da Jekyll.

Chiaro e scuro non sono due temi da mantenere in parallelo: sono la stessa mappa di custom property con valori diversi. Qui la pagina di configurazione tagliata a metà — chiaro a sinistra, scuro a destra — con barra laterale, indice e blocco di codice con pulsante di copia:

Le sei skin si scelgono dal menu a tavolozza nella navbar, e ognuna ha la sua variante chiara e scura:

Cambiarla non tocca una riga di markup, solo delle custom property. Questa è la stessa identica pagina con la skin Violet:

La ricerca è la parte a cui tengo di più, perché è quella che decide se una knowledge base è consultabile o è solo un archivio. Si apre da tastiera e raggruppa i risultati per sezione mentre si digita:

Perché “DocSteer”

/dɒkˈstɪə/ — dok-STÌR, accento sulla seconda sillaba, in rima con l’inglese beer.

Il nome è la descrizione del mestiere. To steer vuol dire guidare, condurre: la barra laterale, il campo di ricerca e l’indice esistono solo per portare chi legge all’unica pagina che stava cercando. Una documentazione che non lo fa è una cartella di file Markdown con sopra un foglio di stile.

Il resto l’ho scoperto dopo: steer, in inglese, è anche un giovane bue. Non era assolutamente il piano. Ma come descrizione di qualcosa che si trascina dietro una pila enorme di documentazione senza mai lamentarsi è difficile darle torto, e ormai ci ho fatto pace.

Come si usa

Due strade. Come gem, aggiungendola al Gemfile:

gem "jekyll-theme-docsteer", "~> 1.0"

e poi nel _config.yml:

theme: jekyll-theme-docsteer
plugins:
  - jekyll-seo-tag
  - jekyll-sitemap
  - jekyll-feed

Oppure clonando il repo come starter, per partire da un sito già popolato e svuotarlo man mano. La gem sta su RubyGems.

Tutte le opzioni del tema vivono sotto un’unica chiave docsteer: nel _config.yml — skin, tema, ricerca, lightbox e il resto:

docsteer:
  skin: aqua          # aqua | violet | mint | ember | graphite | clay
  mode: auto          # auto (segue il sistema) | light | dark
  skin_switcher: true # mostra il menu a tavolozza nella navbar
  search:
    enabled: true
    collections: [docs]
    hotkey: true      # "/" e Cmd/Ctrl-K aprono la ricerca
  lightbox:
    enabled: true

La navigazione — navbar in alto e barra laterale raggruppata — sta tutta in _data/navigation.yml:

sidebar:
  - title: Getting started
    icon: fa-solid fa-rocket
    children:
      - { title: Introduction, url: /docs/introduction/ }
      - { title: Installation, url: /docs/installation/ }

Il pager in fondo a ogni pagina segue da solo l’ordine di questo file: riordini la navigazione e “precedente/successivo” si aggiusta di conseguenza. Il deploy va su GitHub Pages (via Actions), Netlify, Vercel o Cloudflare Pages.

Demo dal vivo e documentazione completa su cristiancastellari.it/docsteer; codice su GitHub.

Come l’ho costruito

Mi sono fatto dare una mano da Claude Code (e da tanti, tanti token in Opus 5). La regola che mi sono dato è la stessa con cui ho ricostruito questo sito qualche settimana fa: prima il piano scritto, poi il codice. Quali layout servivano (default, home, doc, page), come strutturare l’indice di ricerca, cosa doveva restare configurabile da un solo file — deciso e messo nero su bianco prima di aprire un editor.

Poi l’implementazione un pezzo alla volta, ricompilando e guardando il risultato prima di passare al successivo. Non è pignoleria: su un tema, quando salti la verifica, il bug non lo trovi tu — lo trova chi lo installa.

Il che non vuol dire che ne sia uscito perfetto. DocSteer ha già due release alle spalle nello stesso giorno della 1.0.0, e sono tutte cose che si vedono solo usando il tema, non costruendolo: il burger della navbar non apriva niente fuori dalle pagine di documentazione, i tag in fondo agli articoli erano badge inerti invece di aprire la ricerca, e l’indice di ricerca poteva arrivare dalla cache del browser anche dopo aver pubblicato pagine nuove. Le ho sistemate nella 1.1.0 e nella 1.1.1.

Cosa manca ancora

Per onestà, due cose che so già.

I sorgenti Sass usano ancora @import. Dart Sass stampa avvisi di deprecazione — la build è per il resto pulita — e la migrazione a @use/@forward è pianificata, ma tocca ventuno file e in un tema l’output visivo è il prodotto: una regressione su una delle sei skin, in chiaro o in scuro, resta invisibile finché non la segnala qualcuno. Preferisco farla con calma.

E gli anchor delle domande nelle pagine FAQ derivano dal testo della domanda: riformularla cambia il frammento URL e rompe i deep link già condivisi. Correggere un refuso è sicuro, riscrivere una domanda va pesato.

Perché è gratis

Il tema è MIT, per uso personale e commerciale, senza obbligo di attribuzione: il credito in fondo si toglie da configurazione.

Le cose che ho fatto gratis — la traduzione di Morrowind, quella di Twitter, un convertitore per telefoni DECT che apro forse una volta all’anno — sono quelle che alla fine hanno aiutato più persone, e quasi sempre in silenzio: nessun commento, nessuna mail, solo qualcuno dall’altra parte del mondo che ha risolto il suo problema e ha chiuso la scheda.

Un tema per la documentazione ha esattamente lo stesso profilo. Se fa risparmiare una giornata a qualcuno che non incontrerò mai, è già valsa la pena scriverlo — e se vuole offrirmi un caffè, tanto meglio.

DocSteer: a Jekyll theme for documentation

Tue, 01 Sep 2026 09:00:00 +0200

Anyone working in IT spends a fair chunk of the day inside documentation: runbooks, procedures, knowledge base articles, internal wikis nobody has opened in a year. And the hard part is almost never writing it — it is making it findable months later, by someone with an open ticket and very little patience.

DocSteer is a Jekyll theme for exactly that kind of site: technical documentation, support portals, internal knowledge bases. The grouped sidebar, the search and the “On this page” table of contents are not decoration — they are the reason the site exists.

Why another documentation theme
What it does
Why “DocSteer”
How to use it
How it was built
What’s still missing
Why it’s free

Why another documentation theme

There are already plenty of Jekyll documentation themes, and some of them are very good. What I wanted was something narrower: a theme you could stand up in an afternoon, that did not drag in a Node toolchain, and that did not ask you to learn another framework before writing your first page.

The theme behind this site, which I did extract and publish separately, was never going to get there: it is built for a bilingual personal site with a CV, a handful of pages and a blog. Documentation is a different problem. It needs a grouped, collapsible sidebar, a search that holds up across dozens of pages, a table of contents that builds itself, a prev/next pager that follows the navigation order. Each of those can be bolted on by hand, one at a time — which is precisely how you end up with a blog theme covered in patches.

What it does

Six colour skins — aqua, violet, mint, ember, graphite, clay — each with a light and a dark variant, defined as one Sass map and emitted as CSS custom properties. Every skin’s brand colour clears WCAG AA contrast (4.5:1) against its own background.
Dark mode that follows the OS, with a manual toggle stored in localStorage and no white flash on load.
Live search — a Liquid-generated JSON index and a keyboard-driven modal (/ or ⌘K), with no external library at all.
Auto table of contents built from your headings, with scroll-spy, plus a prev/next pager that follows the navigation order on its own.
FAQ pages — layout: faq renders an accordion built on native <details>, with a per-question anchor, FAQPage structured data, and each question indexed as its own search result.
Image lightbox with galleries, captions and keyboard navigation.
Font Awesome 6.5.2 Free bundled locally by default, so the site works offline and behind corporate firewalls. The CDN stays an option.
SEO — jekyll-seo-tag, sitemap, RSS feed, Open Graph and JSON-LD.

No CSS framework, no Node build step: about 7 kB of vanilla JavaScript in total, all deferred, compressed CSS and Sass compiled by Jekyll.

Light and dark are not two themes to keep in sync: they are the same map of custom properties with different values. Here is the configuration page cut down the middle — light on the left, dark on the right — with the sidebar, the table of contents and a code block with a copy button:

The six skins are picked from the palette menu in the navbar, and each one has its own light and dark variant:

Switching one does not touch a line of markup, only custom properties. This is the exact same page with the Violet skin:

Search is the part I care about most, because it is what decides whether a knowledge base is something you consult or just something you archive. It opens from the keyboard and groups results by section as you type:

Why “DocSteer”

/dɒkˈstɪə/ — dok-STEER, stress on the second syllable, rhyming with beer.

The name is the job description. Steering is the whole point: the sidebar, the search box and the table of contents exist only to get a reader to the one page they actually came for. A docs site that cannot do that is a folder of Markdown with a stylesheet on top.

The rest I found out afterwards: a steer is also a young ox. That was absolutely not the plan. But as a description of something that hauls a large pile of documentation around without ever complaining, it is hard to argue with — and by now I have made my peace with it.

How to use it

Two ways. As a gem, added to your Gemfile:

gem "jekyll-theme-docsteer", "~> 1.0"

and then in _config.yml:

theme: jekyll-theme-docsteer
plugins:
  - jekyll-seo-tag
  - jekyll-sitemap
  - jekyll-feed

Or by cloning the repo as a starter, so you begin from a site that is already populated and empty it out as you go. The gem is on RubyGems.

Every theme option lives under a single docsteer: key in _config.yml — skin, mode, search, lightbox and the rest:

docsteer:
  skin: aqua          # aqua | violet | mint | ember | graphite | clay
  mode: auto          # auto (follow OS) | light | dark
  skin_switcher: true # show the palette dropdown in the navbar
  search:
    enabled: true
    collections: [docs]
    hotkey: true      # "/" and Cmd/Ctrl-K open search
  lightbox:
    enabled: true

Navigation — the top navbar and the grouped sidebar — all lives in _data/navigation.yml:

sidebar:
  - title: Getting started
    icon: fa-solid fa-rocket
    children:
      - { title: Introduction, url: /docs/introduction/ }
      - { title: Installation, url: /docs/installation/ }

The pager at the bottom of every page follows the order of that file on its own: reorder the navigation and “previous/next” rearranges itself. It deploys to GitHub Pages (via Actions), Netlify, Vercel or Cloudflare Pages.

Live demo and full documentation at cristiancastellari.it/docsteer; code on GitHub.

How it was built

I got a hand from Claude Code (and a great many Opus 5 tokens). The rule I set myself is the same one I used when I rebuilt this site a few weeks ago: the written plan first, the code second. Which layouts were needed (default, home, doc, page), how to structure the search index, what had to stay configurable from a single file — all decided and written down before opening an editor.

Then the implementation one piece at a time, rebuilding and looking at the result before moving on. That is not fussiness: on a theme, when you skip the check, you are not the one who finds the bug — the person installing it is.

Which is not to say it came out perfect. DocSteer already has two releases behind it from the same day as 1.0.0, and they are all things you only see by using the theme rather than building it: the navbar burger did nothing outside documentation pages, the tags at the bottom of an article were inert badges instead of opening the search, and the search index could be served from the browser cache even after publishing new pages. Fixed in 1.1.0 and 1.1.1.

What’s still missing

Two things I already know about, for honesty’s sake.

The Sass sources still use @import. Dart Sass prints deprecation warnings — the build is otherwise clean — and the migration to @use/@forward is planned, but it touches twenty-one files, and in a theme the visual output is the product: a regression in one of the six skins, light or dark, stays invisible until somebody reports it. I would rather do that one slowly.

And the question anchors on FAQ pages are derived from the question text: rewording one changes its URL fragment and breaks deep links already shared. Fixing a typo is safe; rewriting a question needs a second thought.

Why it’s free

The theme is MIT, for personal and commercial use, with no attribution required: the footer credit switches off from config.

The things I have made for free — the Italian translation of Morrowind, the Italian translation of Twitter back in 2009, a converter for DECT phones I open maybe once a year — turned out to be the ones that helped the most people, and almost always in silence: no comments, no emails, just somebody on the other side of the world who solved their problem and closed the tab.

A documentation theme has exactly the same profile. If it saves a day for someone I will never meet, it was already worth writing — and if they want to buy me a coffee, even better.

Twitter potrebbe tornare grazie a Operation Bluebird?

Sat, 29 Aug 2026 09:00:00 +0200

Nel 2009 ho raccontato di essere stato scelto dal team di Twitter, insieme a una manciata di altri volontari italiani, per tradurre il sito in italiano — gratis, per lo stesso motivo per cui anni prima avevo tradotto Morrowind: mi piaceva farlo, e il servizio restava gratuito per tutti. Diciassette anni dopo, quel nome che ho contribuito a rendere leggibile in italiano potrebbe tornare. Non per mano di Elon Musk, che nel 2023 lo ha cancellato per trasformarlo in X, ma di una startup che quasi nessuno si aspettava: Operation Bluebird.

Chi c’è dietro Operation Bluebird
La causa: X Corp. v. Operation Bluebird
Un pronostico difficile, ma stimolante
Il mio punto di vista. Personale.

Chi c’è dietro Operation Bluebird

Operation Bluebird è il progetto di Stephen Coates, che è stato per anni general counsel di Twitter (quello vero, pre-Musk), insieme all’avvocato specializzato in marchi Michael Peroff. Il 26 agosto 2026 hanno lanciato pubblicamente Twitter.now, attualmente in accesso anticipato e a numero chiuso: si può prenotare il proprio handle, ma l’ingresso vero e proprio è ancora limitato. Nell’interfaccia si ritrovano reply e retweet praticamente identici a quelli dell’originale, con l’aggiunta di uno strumento di fact-checking che il vecchio Twitter non aveva.

La tesi di fondo di Coates e Peroff è semplice da riassumere: X non usa più il nome “Twitter” né la parola “tweet” da anni, ha rimosso l’uccellino da loghi e comunicazione, quindi quei marchi sono di fatto liberi — e loro vogliono essere i primi a riprenderseli.

La causa: X Corp. v. Operation Bluebird

Qui la storia smette di essere solo un aneddoto tecnologico e diventa una battaglia legale vera, che ha già un nome ufficiale: X Corp. v. Operation Bluebird. A dicembre 2025 X ha fatto causa a Operation Bluebird in Delaware, chiedendo un’ingiunzione preliminare per bloccare sul nascere il lancio di un servizio con il nome Twitter.

Operation Bluebird, dal canto suo, non si è limitata a difendersi: ha depositato all’USPTO (l’ufficio marchi e brevetti americano) una petizione di 105 pagine per far dichiarare decaduti i marchi “Twitter” e “Tweet”, facendo leva su una regola precisa del diritto americano dei marchi (il Lanham Act): tre anni consecutivi di non utilizzo, senza intenzione di riprenderlo, creano una presunzione di abbandono. Come prova principale citano le stesse parole di Musk del 2023, quando annunciò che avrebbe detto addio “al marchio Twitter e, gradualmente, a tutti gli uccellini”.

A dare peso concreto alla tesi ci ha pensato, per ora solo a voce, il giudice distrettuale Colm Connolly: in un’udienza di aprile 2026 ha dichiarato dal banco che X “sembra aver abbandonato i diritti di proprietà intellettuale sulla parola ‘Tweet’, sul logo dell’uccellino, e forse anche sulla parola ‘Twitter’ stessa” — una dichiarazione che le testate tecnologiche hanno riportato ampiamente. È importante essere precisi però: si tratta di un’opinione preliminare espressa a voce durante l’udienza, non di una sentenza scritta — che a fine agosto 2026 non è ancora arrivata. Operation Bluebird ha comunque deciso che bastava come via libera informale per lanciare Twitter.now senza aspettare l’ultima parola del tribunale.

Un pronostico difficile, ma stimolante

Non ho gli strumenti per dire come finirà la causa — il diritto dei marchi è un campo minato anche per chi lo mastica di mestiere, figurarsi da fuori. Ma qualche osservazione mi sento di farla.

La prima è che la scommessa di Operation Bluebird è tanto più forte quanto più X somiglia oggi a una piattaforma diversa, con un altro nome, un altro logo, un altro proprietario che ha esplicitamente detto di volersi allontanare dal brand originale: è raro che chi fa causa per un marchio abbia lasciato in giro così tante proprie dichiarazioni contro se stesso. La seconda è che rifare “un altro Twitter” nel 2026 è molto più difficile che nel 2009: il pubblico è più stanco, più diviso su piattaforme diverse (Bluesky, Threads, Mastodon), e un nome familiare da solo non basta più a spostare milioni di persone — serve anche fiducia, cosa che né Musk né una startup appena nata hanno in abbondanza.

Il mio punto di vista. Personale.

C’è poi un pezzo più personale, ed è quello che mi tiene davvero legato a questa notizia. Mi sento orfano di Twitter da quando è finito nelle mani di Musk: da troppi anni ormai è diventato il megafono della mediocrità, più che una piazza. Ricordo un Twitter autorevole — l’unico media abbastanza veloce da mettere in comunicazione in tempo reale zone disagiate del pianeta, o intere zone di guerra, con tutti noi, spesso prima ancora che la notizia arrivasse ai telegiornali. Ricordo quando la spunta blu te la dava Twitter stesso, perché eri autorevole per quello che facevi o dicevi, non perché avevi una carta di credito: oggi te la compri come l’insalata al mercato, e infatti vale altrettanto.

È anche per questo che continuerò a seguire Operation Bluebird con più di una semplice curiosità tecnica: non tanto per rivedere lo stesso nome tornare online, quanto nella speranza — flebile, lo so — che qualcuno, ripartendo da zero proprio con quel nome, provi davvero a restituirgli l’autorevolezza persa per strada. Un servizio che ho contribuito a tradurre da volontario, quando era ancora un progetto piccolo e un po’ ingenuo, che torna a esistere gestito da chi lo conosceva dall’interno prima che diventasse altro: difficile. Ma vale la pena sperarci.

Il redesign di Ipui2Ipei

Tue, 18 Aug 2026 12:30:00 +0200

Nel 2019 ho scritto un post su un problema piccolo e molto specifico: registrare un cordless Siemens su un centralino di un altro produttore richiede di convertire il suo codice IPUI in un codice IPEI standard. Per risolverlo avevo aggiustato ipui2ipei, un tool trovato su GitHub, e me n’ero sostanzialmente dimenticato.

Perché rifare un tool che quasi nessuno nota
Cosa c’era prima, e perché non bastava più
Stesso schema, aggiustamenti su misura
Riscrivere l’algoritmo senza cambiare un solo bit di output
La palette: dal primo tentativo a quello buono
Una nuova pagina Contatti
Un bug trovato scrivendo la pagina Contatti
Cosa mi porto a casa

Perché rifare un tool che quasi nessuno nota

Guardando Google Search Console per quel dominio, la cosa che salta all’occhio non sono i numeri assoluti — è uno strumento verticale per un problema di nicchia, il traffico è quello che ci si aspetta — ma cosa cercano le persone per arrivarci. Quasi nessuno digita “ipui2ipei”, il nome del progetto: la query dominante è una variante diretta del problema, “ipui to ipei”, seguita da “ipei”, “ipei to ipui” e persino “ipui gigaset” — qualcuno che cerca partendo dalla marca del proprio telefono, non dal nome dello standard. Sono persone che non sanno che il mio tool esiste, sanno solo di avere in mano un cordless Siemens/Gigaset e un centralino che non lo riconosce.

La posizione media per queste query non-branded è comunque bassa, vicina alla decima — eppure il CTR resta sopra il 12%, niente male per un risultato che in teoria è sepolto in fondo alla prima pagina. Chi arriva, insomma, sa esattamente cosa vuole trovare.

C’è un altro modo di guardare la stessa cosa: fra tutte le pagine di destinazione da ricerca organica di cristiancastellari.it, quasi tre quarti dei click finiscono dritti su /ipui2ipei/. Il vecchio post del 2019 che lo racconta è il secondo — insieme, tool e articolo, si prendono quasi 9 click su 10 fra le pagine più cercate del sito. Uno strumento così merita di funzionare bene su schermi diversi da quello 2014 per cui era stato pensato, non di essere abbandonato solo perché nessuno se ne lamenta apertamente.

Cosa c’era prima, e perché non bastava più

Il tool era un fork del 2014 di un progetto di Gorka Hernández, aggiustato da me negli anni fra il 2018 e il 2019: Bootstrap 3.2.0, jQuery, un CSS esterno ma niente di più. Funzionava — è ancora online da anni senza un solo bug segnalato — ma portava lo stesso tipo di debito tecnico da cui sono partito per ricostruire il sito principale poche settimane fa: una libreria CSS ferma al 2014, uno script scritto con variabili globali mai dichiarate con var, zero automazione — ogni modifica andava caricata a mano via FTP.

Con lo schema Jekyll 4 + GitHub Actions appena collaudato e documentato sul sito principale, riapplicarlo qui è stato più veloce che lasciare le cose come stavano.

Stesso schema, aggiustamenti su misura

Non è stato un copia-incolla: ipui2ipei vive come project page sotto lo stesso dominio custom del sito principale (cristiancastellari.it/ipui2ipei/), quindi ha un baseurl diverso — ogni link e ogni asset passa dal filtro giusto di Jekyll per restare coerente sotto quel prefisso, cosa che sul sito principale (che vive alla radice del dominio) non serve.

Il vincolo più importante era però lo stesso di allora: l’URL storico già indicizzato da anni doveva continuare a funzionare. https://cristiancastellari.it/ipui2ipei/ oggi fa da redirect verso la nuova pagina italiana — chi ha quel link salvato nei preferiti, o lo trova ancora citato da qualche parte, non nota nessuna differenza.

Ho anche colto l’occasione per renderlo bilingue, con pagine italiane e inglesi separate invece di uno switcher lato client: la maggior parte del traffico arriva da ricerca organica, e uno switcher JavaScript è invisibile a un motore di ricerca quanto lo è a chi digita “ipei to ipui” in inglese dall’altra parte del mondo.

Riscrivere l’algoritmo senza cambiare un solo bit di output

La parte che mi metteva più a disagio era toccare ipui2ipei.js: è il cuore del tool, e un bug introdotto lì produce un IPEI sbagliato senza che nessuno se ne accorga finché qualcuno non prova a registrare un telefono che non si aggancia. L’ho riscritto da zero — via jQuery, via le variabili globali implicite dell’originale — ma la matematica non doveva cambiare di una virgola: stesso scarto del primo carattere, stessa suddivisione in due blocchi esadecimali, stesso zero-padding, stesso checksum secondo lo standard ETSI EN 300 175-6.

Per essere sicuro di non aver rotto nulla ho scritto un piccolo harness che esegue in parallelo l’algoritmo originale (trascritto tale e quale) e quello nuovo su una batteria di IPUI di prova — compreso un caso limite trovato apposta per forza bruta, quello in cui il checksum dà esattamente 10 e va sostituito con un asterisco secondo lo standard. Output identico su tutta la batteria, poi riconfermato aprendo davvero il tool in un browser headless, compilando il campo e premendo Converti via script, prima di fidarmi della riscrittura.

Un paio di dettagli che prima non c’erano: l’errore di validazione, che era un alert() bloccante del browser, è diventato un messaggio inline con bordo colorato; e il bottone Converti è ora un vero type="submit", quindi premere Invio nel campo IPUI avvia la conversione da solo, senza dover cliccare — comportamento nativo del form, non uno script scritto apposta per intercettare il tasto.

La palette: dal primo tentativo a quello buono

La prima proposta puntava su un’identità visiva totalmente indipendente dal sito principale, in ambra. L’ho rivista dopo essermela guardata per un po’: il bottone Converti e il bordo di validazione dell’IPUI sono rimasti verdi in entrambi i temi — un richiamo diretto al vecchio btn-success di Bootstrap, l’unica cosa della palette originale che valeva la pena conservare — mentre testo ed evidenziazioni sono tornati sul blu del sito principale nel tema chiaro, con un arancione (un omaggio al mondo Gigaset/DECT di cui parla lo strumento) nel tema scuro.

Altri due dettagli minori ma fastidiosi da guardare, prima: nello switcher lingua e nel nav in alto, l’elemento su cui ti trovi già era discreto e quello cliccabile era colorato — esattamente il contrario di quello che ci si aspetta guardando una UI del genere. Ho invertito la gerarchia: ora “sei qui” è evidenziato con un pill pieno, il resto si accende solo al passaggio del mouse.

Una nuova pagina Contatti

Lo strumento non aveva alcun modo per chi lo usa di contattarmi, se non intuendo che il progetto fosse mio da un link GitHub in fondo alla pagina. Ho aggiunto una pagina Contatti che replica la struttura di quella del sito principale — stesso saluto personale come titolo (“Ciao, sono Cristian!”) al posto di un anonimo “Contatti”, stessa griglia di card per canale.

Le icone però sono disegnate a mano in SVG invece di venire da un font di icone: reintrodurne uno solo per sei icone in una pagina avrebbe vanificato il senso di essersi liberati di Bootstrap e di tutto il resto in un colpo solo.

Un bug trovato scrivendo la pagina Contatti

Controllando l’HTML generato per la nuova pagina mi sono accorto che il loop che genera i tag apple-touch-icon per le otto dimensioni richieste (57px, 72px, e così via) non funzionava come pensavo: lo split della stringa "57,72,114,..." avveniva dentro il ciclo invece che prima, quindi il loop girava una sola volta con l’intera stringa come valore unico, producendo un solo link con un nome file illeggibile invece di otto tag separati. Un bug presente fin dalla prima stesura del tema, mai notato perché nessuno controlla mai l’HTML generato per le icone del touch bar di iOS — finché non serve confrontarlo per una pagina nuova.

Cosa mi porto a casa

Il sito principale aveva una scusa evidente per essere ricostruito: è il mio biglietto da visita, ci scrivo sopra, lo guardo ogni giorno. Ipui2ipei non ce l’aveva — è un tool che io stesso apro forse una volta all’anno. Eppure è probabilmente lo strumento che aiuta più sconosciuti, in silenzio, di qualsiasi altra cosa io abbia pubblicato: non genera conversazioni, non genera commenti, genera solo un telefono che finalmente si registra. Vale la pena curarlo con lo stesso standard delle cose che si vedono di più, non di meno — nessuno lo nota quando è fatto bene, ma qualcuno lo nota di sicuro quando è fatto male.

Potenziare la ricerca interna del blog

Sun, 16 Aug 2026 11:32:00 +0200

Il sito è online da qualche giorno, le rifiniture principali sono fatte, e stavo scorrendo le funzionalità una per una per vedere cosa meritasse ancora attenzione. Mi sono fermato sulla lente di ricerca in alto a destra: funziona, ma non ho mai controllato davvero quanto bene funziona.

Cosa faceva, prima
Un confronto con un altro progetto
Cosa ho portato, e come
Un bug silenzioso trovato per strada
Verificare uno script che scarica dati e aggiorna il DOM, da terminale
Cosa mi porto a casa

Cosa faceva, prima

La ricerca di questo blog è tutta lato client: alla build, Jekyll genera un search.json con titolo, URL e descrizione di ogni post; quando apri il pannello, un piccolo script scarica quel file una volta sola e, ad ogni tasto premuto, cerca la query come sottostringa dentro titolo e descrizione. Funzionale, ma con dei limiti concreti:

Le pagine statiche non c’erano. Cercare “CV” non trovava la pagina CV, perché il JSON includeva solo site.posts.
Solo titolo e descrizione, mai tag o categorie — un post taggato “kace” ma senza quella parola nel titolo non usciva cercando “kace”.
Nessun match su più parole: “claude code” veniva cercato come frase esatta, non come due parole da trovare entrambe, magari sparse fra campi diversi.
Nessun ranking: i risultati uscivano nell’ordine cronologico dei post, non in base a quanto fossero pertinenti.

Un confronto con un altro progetto

Ho anche un altro sito Jekyll che curo, quello del mio squadrone di Elite: Dangerous (flottastellare.it — ne ho scritto qualche giorno fa, a proposito di un altro script rotto). Ha anche lui un motore di ricerca interno, decisamente più maturo: usa Simple-Jekyll-Search, una libreria di terze parti con qualche anno sulle spalle, con un search.json che include tag, categorie e data oltre a titolo e descrizione, e persino una tag cloud in fondo alla pagina di ricerca.

Idee valide, ma non tutte da copiare così come sono. Questo sito ha una regola precisa, dichiarata anche nel README ora che il tema è open source: zero JavaScript di terze parti. Aggiungere una libreria — per quanto piccola — solo per la ricerca avrebbe rotto quella regola per un guadagno che potevo ottenere anche scrivendo poche righe in più a mano.

Cosa ho portato, e come

Più contenuto indicizzato. Il search.json ora include, oltre ai post, tutte le pagine che usano un layout “di contenuto” (page, category, blog-index) — CV, Progetti, Contatti, le pagine legali, l’indice del blog e tutte le pagine categoria. Cercare “CV” ora trova la pagina CV.

Ricerca su più campi. Ogni voce del JSON porta con sé anche tag e categorie (uniti in una stringa), non solo titolo e descrizione. La funzione di match adesso guarda dentro tutti questi campi.

Query a più parole, in AND. La query viene spezzata in parole; un elemento risulta un match solo se ogni parola è presente da qualche parte (titolo, descrizione, tag o categoria) — non serve più che compaiano vicine o nell’ordine esatto.

Un ranking minimo, ma sensato. Ogni parola trovata nel titolo vale 3 punti, ogni parola trovata altrove ne vale 1; i risultati sono ordinati per punteggio decrescente. Cercare “kace” fa uscire per prima la pagina categoria Kace e i post che hanno “Kace” nel titolo, poi quelli che ce l’hanno solo nei tag — invece dell’ordine cronologico casuale di prima.

function scoreItem(item, words) {
  var title = (item.title || '').toLowerCase();
  var rest = [item.description, item.tags, item.categories]
    .filter(Boolean).join(' ').toLowerCase();

  var score = 0;
  for (var i = 0; i < words.length; i++) {
    var inTitle = title.indexOf(words[i]) !== -1;
    var inRest = rest.indexOf(words[i]) !== -1;
    if (!inTitle && !inRest) return null; // AND: una parola assente esclude il risultato
    score += inTitle ? 3 : 1;
  }
  return score;
}

Un estratto sotto ogni risultato, non più solo il titolo nudo — così si capisce perché quel risultato è uscito, prima ancora di cliccarci sopra.

Un bug silenzioso trovato per strada

Scrivendo il nuovo search.json ho notato che quello vecchio inseriva titolo e descrizione nel JSON senza nessun escaping:

"title" : "{{ post.title }}",

Nessuno dei titoli attuali contiene virgolette doppie, quindi non si era mai rotto — ma sarebbe bastato un titolo con un " dentro per generare un JSON non valido e far fallire silenziosamente fetch('/search.json').then(r => r.json()) su tutto il sito, senza errori visibili se non aprendo la console. Corretto usando il filtro jsonify di Liquid, che serializza il valore in JSON corretto invece di inserirlo come stringa grezza:

"title" : {{ post.title | jsonify }},

Verificare uno script che scarica dati e aggiorna il DOM, da terminale

L’ultima parte è stata la più scomoda, nel senso buono: come si verifica in automatico — senza aprire davvero un browser e digitare — che una ricerca javascript funzioni? Ho scritto una pagina di prova temporanea che apre il pannello, digita “kace” nel campo e scrive i risultati nel DOM, poi l’ho fotografata con Microsoft Edge headless.

Primo tentativo, fallito: uno screenshot semplice cattura la pagina subito dopo il caricamento, senza aspettare che i setTimeout dello script di prova (e la vera chiamata fetch al search.json reale) abbiano il tempo di completarsi — risultato, uno screenshot con la casella di ricerca ancora vuota. Secondo tentativo: alzare il “budget di tempo virtuale” di Chromium (--virtual-time-budget) a un valore abbondante, cosa che permette al browser di far avanzare timer e rete anche in modalità headless prima di scattare la foto. Con margine sufficiente (6 secondi virtuali), lo script ha avuto tutto il tempo di aprire il pannello, scaricare search.json davvero e mostrare i risultati — verificati poi anche con lo stile reale del sito, non solo con la logica nuda.

Cosa mi porto a casa

Non è stato un lavoro nato da una segnalazione o da un bug in produzione — è nato da una domanda pigra (“come funziona quell’altro sito?”) che si è rivelata utile. A volte il modo più veloce per migliorare qualcosa non è inventarsi la soluzione da zero, ma guardare come l’ha già risolta un progetto simile, capire cosa vale la pena portare a casa e cosa no — e nel farlo, trovare pure un bug che dormiva lì da mesi senza che nessuno se ne accorgesse.

Il nuovo sito, parte 5: breadcrumb, metainfo riordinate e un post in vetrina

Fri, 14 Aug 2026 22:00:00 +0200

Le prime quattro parti di questa serie (1, 2, 3, 4) coprivano la ricostruzione, i bug, le copertine, le rifiniture prima del lancio. Il sito è online da un po’, ora — ed è arrivato il momento di lavorare su cose che si notano solo se funzionano bene: come ci si orienta dentro un articolo, cosa si legge per primo, e come si scopre un contenuto che altrimenti sarebbe sepolto in mezzo a tutti gli altri.

Un breadcrumb, per chi legge e per chi indicizza
La riga con data e tempo di lettura, spostata due volte
Un post in vetrina, e la lezione sulle immagini con testo dentro
Perché questa parte conta

L’idea di partenza era semplice: aggiungere un breadcrumb (Home / Blog / Categoria / Titolo) sopra ogni articolo, per dare un punto di riferimento durante la lettura. Ma il breadcrumb visibile è solo metà del valore — l’altra metà è dati strutturati che Google usa per sostituire l’URL nudo con un percorso leggibile nei risultati di ricerca, a patto di marcarli con lo schema BreadcrumbList in JSON-LD.

jekyll-seo-tag, il plugin che già genera buona parte dei meta tag del sito, non lo fa in autonomia — verificato leggendo l’HTML compilato: produce solo BlogPosting, WebSite e Person. Serviva un secondo blocco application/ld+json indipendente (pratica comune: più blocchi JSON-LD sulla stessa pagina sono validi), generato dagli stessi identici dati del breadcrumb visibile, per non rischiare che i due finiscano per raccontare percorsi diversi.

Liquid, però, non ha letterali per gli hash — non puoi scrivere al volo un array di coppie {etichetta, url}. La soluzione più pulita è stata usare due array paralleli, costruiti con push (lo stesso filtro già usato altrove nel sito per i post correlati):

{% assign crumb_labels = "" | split: "" %}
{% assign crumb_urls = "" | split: "" %}
{% assign crumb_labels = crumb_labels | push: i18n.nav_home[short_lang] %}
{% assign crumb_urls = crumb_urls | push: home_url %}
{% assign crumb_labels = crumb_labels | push: i18n.nav_blog[short_lang] %}
{% assign crumb_urls = crumb_urls | push: blog_url %}
{% include breadcrumb.html labels=crumb_labels urls=crumb_urls %}

e dentro l’include, un solo ciclo genera sia gli <a> che gli <li> del JSON-LD, scorrendo gli stessi due array:

{
  "@type": "ListItem",
  "position": {{ forloop.index }},
  "name": {{ label | jsonify }}
  {% unless forloop.last %},"item": {{ url | absolute_url | jsonify }}{% endunless %}
}

Il primo tentativo aveva però un difetto invisibile finché non lo si guarda affiancato al resto della pagina: il breadcrumb, inserito appena sopra <header class="post-header">, restava ancorato al bordo dell’intero container da 1360px — mentre il titolo sotto vive dentro .post-header, che ha un suo max-width: 760px centrato, la colonna di lettura usata in tutto il sito. Risultato: su schermi larghi il breadcrumb partiva più a sinistra del titolo che gli stava proprio sotto, uno sfasamento che si nota a colpo d’occhio ma che in isolamento — guardando solo il breadcrumb, o solo il titolo — è del tutto invisibile. Bastava spostare l’include dentro l’header per farlo ereditare la stessa colonna.

La riga con data e tempo di lettura, spostata due volte

Volevo che la riga con data, numero di parole e tempo di lettura stesse fra il titolo e il contenuto, non sopra al titolo com’era prima. Mi sono ispirato al layout di un altro blog Jekyll — titolo, poi immagine di copertina, poi metainfo, poi contenuto — e ho spostato tutto lì.

Sbagliato: quel layout metteva le metainfo dopo l’immagine, io le volevo subito sotto il titolo. Un malinteso mio nell’interpretare il riferimento, corretto non appena fatto notare — la differenza è di poche righe di Liquid, ma cambia parecchio la gerarchia visiva della pagina.

Sistemata la posizione, è rimasto un problema di affollamento: sotto al titolo si accalcavano tre elementi tutti “di servizio” — il breadcrumb appena sopra, la pill della categoria, la riga della meta-info — e la pill era ridondante: la stessa categoria è già visibile nel breadcrumb, una riga più in alto. L’ho spostata sotto la riga meta invece che sopra, e ho stretto lo spazio fra breadcrumb e titolo (24px → 8px, che da solo bastava a far sembrare tutto più affollato di quanto fosse davvero).

Un post in vetrina, e la lezione sulle immagini con testo dentro

L’ultima modifica: un post per lingua, marcato featured: true nel front matter, compare come card grande in cima all’indice del blog — escluso dalla griglia normale sotto, per non mostrarlo due volte. Anche qui, ispirazione presa da come altri blog Jekyll gestiscono l’articolo in evidenza.

{% assign featured_post = lang_posts | where: "featured", true | first %}
{% assign grid_posts = "" | split: "" %}
{% for post in lang_posts %}
  {% unless featured_post and post.url == featured_post.url %}
    {% assign grid_posts = grid_posts | push: post %}
  {% endunless %}
{% endfor %}

La parte interessante è stata l’immagine di copertina. Primo tentativo: object-fit: cover con un rapporto fisso 16:9, per dare alla card un’altezza prevedibile. Sembrava ragionevole finché non ho provato con la copertina del post su WireGuard: il ritaglio tagliava via la parte alta dell’immagine, portandosi via il titolo “WireGuard” disegnato dentro la grafica stessa. Ho stretto l’altezza pensando bastasse un object-position: top — e ho provato con un’altra copertina, un banner panoramico (rapporto 4:1) per l’articolo sulla Flotta Stellare. Risultato anche peggiore: il testo “Alto Comando Flotta Stellare” tagliato ai lati, illeggibile.

Il problema non era la posizione del ritaglio, era il ritaglio in sé. Le copertine di questo blog sono quasi sempre grafiche con testo integrato — non fotografie — a proporzioni imprevedibili e con il testo in posizioni diverse ogni volta. Nessun object-position fisso avrebbe funzionato per tutte. La soluzione è stata smettere di ritagliare: l’immagine mantiene le sue proporzioni naturali, esattamente come già succede per le copertine dentro ai singoli articoli. Card più alte o più basse a seconda del post, ma mai un titolo tagliato a metà.

Un’ultima rifinitura, via feedback diretto: la badge “In evidenza” era troppo timida — sfondo tenue, poco riconoscibile — sostituita con uno sfondo pieno, colore d’accento, e un’iconcina a stella.

Perché questa parte conta

Con una manciata di articoli, breadcrumb e post in evidenza sono quasi decorazione. Non lo sono più a lungo andare: più il blog cresce, più contano i punti di riferimento — sapere dove si è, tornare indietro di un livello senza usare il tasto back del browser, scoprire un articolo importante senza doverlo cercare fra dieci schede uguali nella griglia. Sono le stesse rifiniture “poco glamour” della parte 4, applicate un livello più in alto: non più “il sito funziona”, ma “il sito si lascia usare bene”.

Una VPN veloce e solida con WireGuard: da Windows Server 2022 a Windows 11

Fri, 14 Aug 2026 00:15:00 +0200

Sono certificato Fortinet NSE6 e le VPN le so costruire, ma quando serve qualcosa di pronto in pochi click — comprese le VPN onboard sui router Mikrotik, magari per raggiungere l’intera rete di un cliente — uso WireGuard: meno configurazione, meno cose che si rompono, e una velocità che OpenVPN e IPsec non riescono ad avvicinare. Il protocollo è nato su Linux, ma il client ufficiale per Windows è maturo da tempo, e da quando esiste il driver WireGuardNT (a livello kernel, non più il vecchio wireguard-go in user space) le prestazioni su Windows sono del tutto in linea con quelle su Linux.

In questo articolo mettiamo in piedi uno scenario molto comune: un server WireGuard su Windows Server 2022 che fa da punto d’ingresso per uno o più client Windows 11, con accesso alla rete locale dell’ufficio e, opzionalmente, un tunnel completo per instradare anche il traffico Internet. Userò nomi ed indirizzi IP generici — sostituiteli con i vostri prima di andare in produzione.

Perché WireGuard e non OpenVPN o IPsec
Prerequisiti
Architettura e schema di indirizzamento
Installazione su Windows Server 2022
Configurazione del client Windows 11
Verificare che tutto funzioni
Tunnel completo o split tunnel?
Qualche accorgimento di sicurezza
Perché è così veloce
Conclusioni
Download
Riferimenti

Perché WireGuard e non OpenVPN o IPsec

Qualche numero e qualche motivo concreto, senza dilungarmi troppo:

Codice minuscolo: il core di WireGuard è poche migliaia di righe, contro le centinaia di migliaia di OpenVPN. Meno codice vuol dire meno superficie d’attacco e una revisione di sicurezza molto più semplice.
Crittografia moderna e non negoziabile: Curve25519, ChaCha20-Poly1305, BLAKE2s. Non ci sono liste di cifrari da configurare né vecchi algoritmi da disabilitare a mano: WireGuard usa una sola suite crittografica, aggiornata, punto.
Solo UDP: niente “TCP-over-TCP meltdown” (il rallentamento tipico di OpenVPN in modalità TCP su reti con perdita di pacchetti).
Roaming istantaneo: un client può cambiare rete — dal Wi-Fi di casa al 5G, da un hotel a un altro — senza rinegoziare il tunnel. Il server si accorge del nuovo IP sorgente al primo pacchetto valido e continua da lì.
Nessuna sessione, nessuno stato lato server finché non arriva traffico: il server non tiene processi appesi per ogni client connesso.

Il rovescio della medaglia: WireGuard non ha un concetto di utente/password. L’identità di un peer è la sua chiave pubblica, punto. Se vi serve un’autenticazione utente-per-utente in stile “aziendale”, va costruita sopra (una coppia di chiavi per persona/dispositivo, mai condivisa) — ne parlo più avanti nella sezione sulla sicurezza.

Prerequisiti

Un Windows Server 2022 con un indirizzo IP pubblico, oppure dietro un router su cui potete fare port forwarding.
Uno o più Windows 11 da collegare in VPN.
Il client ufficiale WireGuard per Windows, stesso installer su server e client (link nella sezione Download).
Accesso amministrativo su entrambe le macchine, e la possibilità di aprire una porta UDP sul firewall (e sul router, se il server è dietro NAT).
Se volete che i client raggiungano anche la LAN dell’ufficio (non solo il server), un minimo di pianificazione degli indirizzi: vedi lo schema qui sotto.

Architettura e schema di indirizzamento

Lo scenario che useremo come riferimento in tutto l’articolo:

Rete WireGuard: 10.66.0.0/24 (una sottorete dedicata alla VPN, separata dalla LAN reale — così evitiamo conflitti di routing).
Server: indirizzo VPN 10.66.0.1, indirizzo LAN 192.168.1.10.
Client: 10.66.0.2, 10.66.0.3, ecc. — un indirizzo per dispositivo.
Porta di ascolto: UDP 51820 (quella di default; potete cambiarla, vedi la sezione sicurezza).
LAN dell’ufficio da raggiungere in VPN: 192.168.1.0/24.

Nota: se il server è dietro un router (es. connessione domestica o in un ufficio senza IP pubblico diretto), serve un port forward UDP 51820 → indirizzo LAN del server. Se l’IP pubblico non è statico, aggiungete un servizio di DDNS (Dynamic DNS) e usate l’hostname invece dell’IP nell’Endpoint del client.

Installazione su Windows Server 2022

Installate WireGuard per Windows con l’MSI ufficiale (stesso installer del client). L’app si apre con un pannello di gestione tunnel: la useremo solo per generare le chiavi la prima volta, perché su un server la modalità corretta è avviarlo come servizio Windows, non lasciarlo agganciato a una sessione utente.

Generare la coppia di chiavi del server

Dal pannello Gestisci tunnel dell’app, scegliete Aggiungi tunnel > Aggiungi tunnel vuoto: viene generata subito una nuova coppia di chiavi, con la chiave privata già inserita nell’editor di configurazione e la chiave pubblica corrispondente visibile nel pannello di dettaglio del tunnel. Copiatevi da qualche parte la chiave pubblica: dovrete inserirla nella configurazione di ogni client.

Attenzione: la chiave privata è l’unica cosa che identifica il server (o un client) nella VPN — trattatela come una password. Non giriatela per email o chat, non mettetela in un repository, e se sospettate che sia stata esposta rigeneratela e aggiornate tutti i peer.

Il file di configurazione del server

Sostituite il contenuto dell’editor con qualcosa di questo tipo (adattando indirizzi e chiavi):

[Interface]
PrivateKey = <chiave privata del server>
Address = 10.66.0.1/24
ListenPort = 51820

[Peer]
# laptop-01
PublicKey = <chiave pubblica del client>
AllowedIPs = 10.66.0.2/32

Ogni client ha il suo blocco [Peer], con la propria chiave pubblica e un solo indirizzo /32 (il suo, non l’intera sottorete: è così che WireGuard sa a quale peer instradare i pacchetti diretti a quell’IP). Salvate il file come C:\WireGuard\wg0.conf.

Attivare il tunnel come servizio Windows

Su un server, evitate di usare il pulsante “Attiva” dell’app grafica: quel tunnel resta legato alla sessione dell’utente che l’ha avviato e si ferma al logout. La via corretta è installarlo come servizio, così parte da solo al boot ed è indipendente da qualunque sessione:

& "C:\Program Files\WireGuard\wireguard.exe" /installtunnelservice C:\WireGuard\wg0.conf

Per fermarlo o rimuoverlo in seguito:

& "C:\Program Files\WireGuard\wireguard.exe" /uninstalltunnelservice wg0

Verificate che il servizio sia attivo con Get-Service WireGuardTunnel*.

Aprire la porta sul firewall e sul router

Sul firewall di Windows:

New-NetFirewallRule -DisplayName "WireGuard VPN" -Direction Inbound -Protocol UDP -LocalPort 51820 -Action Allow

Se il server è dietro un router, aggiungete anche lì il port forward UDP 51820 verso l’indirizzo LAN del server (192.168.1.10 nel nostro schema).

Configurazione del client Windows 11

Generare la coppia di chiavi del client

Stessa procedura vista per il server: installate WireGuard per Windows, Aggiungi tunnel > Aggiungi tunnel vuoto, copiate la chiave pubblica generata (vi servirà per il blocco [Peer] sul server).

Il file di configurazione del client

[Interface]
PrivateKey = <chiave privata del client>
Address = 10.66.0.2/24
DNS = 192.168.1.1

[Peer]
PublicKey = <chiave pubblica del server>
Endpoint = vpn.tuodominio.it:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Un paio di campi meritano una spiegazione:

Endpoint: l’indirizzo pubblico (o l’hostname DDNS) e la porta a cui il client si connette. È l’unico posto dove serve un indirizzo “raggiungibile dall’esterno” — il server non ha bisogno di conoscere l’IP del client in anticipo.
PersistentKeepalive = 25: manda un pacchetto vuoto ogni 25 secondi per tenere aperto il mapping NAT del router del client. Senza, se il client è dietro un NAT (quasi sempre, su reti domestiche o mobili), il tunnel può “addormentarsi” e il server non riesce più a raggiungerlo per primo.
AllowedIPs: qui decidete se fare tunnel completo o split tunnel — se ne parla nella prossima sezione.

Importate il file da WireGuard > Importa tunnel da file…, oppure incollate il contenuto direttamente nell’editor del tunnel vuoto creato prima.

Aggiungere il peer sul server

Tornate sul server e aggiungete un blocco [Peer] per questo client (o create il file con tutti i peer fin da subito, se sapete già quanti client collegherete):

[Peer]
# laptop-01
PublicKey = <chiave pubblica del client>
AllowedIPs = 10.66.0.2/32

Salvate e riavviate il servizio del tunnel perché rilegga la configurazione:

& "C:\Program Files\WireGuard\wireguard.exe" /uninstalltunnelservice wg0
& "C:\Program Files\WireGuard\wireguard.exe" /installtunnelservice C:\WireGuard\wg0.conf

Verificare che tutto funzioni

Sul client, attivate il tunnel dall’app WireGuard e controllate nella finestra principale: dovreste vedere l’host del server, i contatori di traffico in salita/discesa che si muovono, e l’orario dell’ultimo handshake aggiornarsi periodicamente. Se l’handshake non compare mai, il problema è quasi sempre a livello di rete (porta non raggiungibile, firewall, port forward mancante) prima ancora che di configurazione WireGuard.

Poi, da riga di comando sul client:

ping 10.66.0.1

Se risponde, il tunnel funziona. Per verificare l’accesso alla LAN dell’ufficio (se l’avete abilitato, vedi sotto), provate a raggiungere una risorsa nota, ad esempio ping 192.168.1.10 o l’apertura di una condivisione file.

Nota: se il ping verso 10.66.0.1 funziona ma quello verso la LAN (192.168.1.x) no, il tunnel va bene: manca solo l’IP forwarding sul server, descritto nella prossima sezione.

Tunnel completo o split tunnel?

Il campo AllowedIPs nel blocco [Peer] del client decide cosa passa dentro la VPN:

Tunnel completo — AllowedIPs = 0.0.0.0/0, ::/0: tutto il traffico del client, incluso quello verso Internet, passa dal server. Utile se non vi fidate della rete su cui siete (Wi-Fi pubblico) o se volete che il client “esca” sempre con l’IP del server.
Split tunnel — AllowedIPs = 10.66.0.0/24, 192.168.1.0/24: solo il traffico verso la VPN e la LAN dell’ufficio passa dal tunnel, il resto (Netflix, siti web, tutto il resto) esce direttamente dalla connessione del client. Più leggero per il server, e per l’utente spesso più veloce.

In entrambi i casi, se volete che i client raggiungano host della LAN reale (non solo il server), Windows deve fare da router fra l’interfaccia WireGuard e quella di rete fisica. Per impostazione predefinita non lo fa: va abilitato l’IP forwarding:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" -Name "IPEnableRouter" -Value 1
Restart-Computer

Se invece volete il tunnel completo (i client escono su Internet passando dal server), serve anche il NAT in uscita sull’interfaccia fisica del server:

New-NetNat -Name WireGuardNAT -InternalIPInterfaceAddressPrefix 10.66.0.0/24

Questo comando basta da solo, senza installare il ruolo Routing and Remote Access: il modulo NetNat è incluso in Windows Server dal 2016 in poi.

Qualche accorgimento di sicurezza

Una coppia di chiavi per dispositivo, mai condivisa fra più persone: è l’unico modo per poter revocare l’accesso a un dispositivo (basta togliere il suo blocco [Peer] dal server) senza dover ruotare le chiavi di tutti gli altri.
AllowedIPs il più stretto possibile per ogni peer sul server: un client che si occupa solo di backup non ha bisogno di poter raggiungere l’intera LAN.
Cambiare la porta di default (51820) non è vera sicurezza — è security through obscurity — ma riduce parecchio il rumore di fondo degli scanner automatici che bussano sulla porta standard nei log.
WireGuard non sostituisce l’autenticazione applicativa: dà accesso di rete, non identità utente. Se dietro la VPN c’è RDP, una share file o un pannello di amministrazione, tenete comunque password forti e, dove possibile, MFA su quei servizi — la VPN è un livello, non l’unico.
Backup delle chiavi private in un posto cifrato (password manager, non un file di testo sul desktop): se perdete quella del server dovrete rigenerarla e riconfigurare ogni client.

Perché è così veloce

Vale la pena spendere due righe sul “veloce” del titolo. Su Windows, dalla versione che usa il driver WireGuardNT, l’intero percorso dei pacchetti gira nel kernel, non più in un processo user-space come nelle prime versioni (che si appoggiavano a wireguard-go sopra l’adattatore Wintun). Questo, insieme al fatto che il protocollo non ha l’overhead di negoziazione di IPsec (niente IKE, niente rinegoziazioni continue) e non soffre del rallentamento tipico di OpenVPN in TCP, si traduce in throughput molto vicini al limite della connessione fisica e in una latenza aggiuntiva minima — nella pratica, spesso impercettibile rispetto al traffico non incapsulato.

Conclusioni

Messo in piedi una volta, un tunnel WireGuard fra Windows Server e Windows 11 richiede pochissima manutenzione: nessun certificato da rinnovare, nessuna lista di cifrari da tenere aggiornata, un file di configurazione per peer. I punti dove ci si incastra di solito sono sempre gli stessi tre: porta UDP non raggiungibile (firewall o port forward mancante), IP forwarding disattivato (niente accesso alla LAN) e NAT mancante (niente Internet in tunnel completo) — se il tunnel si stabilisce (handshake visibile) ma qualcosa dopo non funziona, è quasi sempre uno di questi tre.

Download

WireGuard per Windows — stesso installer per server e client, sito ufficiale
wg0-server.conf — template di configurazione per il server, con due peer di esempio
client.conf — template di configurazione per il client, con entrambe le varianti (tunnel completo / split tunnel) commentate

Riferimenti

wireguard.com — sito ufficiale del protocollo
Documentazione WireGuard per Windows — pagina di download e note sul client
New-NetNat (documentazione Microsoft) — dettagli sul cmdlet usato per il NAT in tunnel completo

A fast, solid VPN with WireGuard: from Windows Server 2022 to Windows 11

Fri, 14 Aug 2026 00:15:00 +0200

I’m Fortinet NSE6 certified and know how to build VPNs, but when I need something ready to go in a few clicks — including onboard VPNs on Mikrotik routers, to reach a client’s whole network — I reach for WireGuard: less configuration, fewer things that break, and speed OpenVPN and IPsec can’t get close to. The protocol was born on Linux, but the official Windows client has been mature for a while, and since the WireGuardNT driver (kernel-level, no longer the old user-space wireguard-go) Windows performance is fully in line with Linux.

In this article we’ll set up a very common scenario: a WireGuard server on Windows Server 2022 acting as the entry point for one or more Windows 11 clients, with access to the office LAN and, optionally, a full tunnel that also routes Internet traffic. I’ll use generic names and IP addresses — swap in your own before going to production.

Why WireGuard over OpenVPN or IPsec
Prerequisites
Architecture and addressing scheme
Setting up Windows Server 2022
Setting up the Windows 11 client
Checking that everything works
Full tunnel or split tunnel?
A few security notes
Why it’s this fast
Wrapping up
Download
References

Why WireGuard over OpenVPN or IPsec

A few numbers and concrete reasons, without dragging this out:

Tiny codebase: WireGuard’s core is a few thousand lines, versus OpenVPN’s hundreds of thousands. Less code means a smaller attack surface and a much simpler security review.
Modern, non-negotiable cryptography: Curve25519, ChaCha20-Poly1305, BLAKE2s. There’s no cipher list to configure and no legacy algorithms to disable by hand — WireGuard uses one up-to-date suite, full stop.
UDP only: no “TCP-over-TCP meltdown” (the slowdown typical of OpenVPN over TCP on lossy networks).
Instant roaming: a client can switch networks — home Wi-Fi to mobile data, one hotel to another — without renegotiating the tunnel. The server notices the new source IP on the first valid packet and just continues.
No sessions, no server-side state until traffic actually arrives: the server doesn’t keep a process hanging around per connected client.

The flip side: WireGuard has no concept of user/password. A peer’s identity is its public key, period. If you need per-user, “enterprise-style” authentication, you build it on top (one keypair per person/device, never shared) — more on that in the security section below.

Prerequisites

A Windows Server 2022 with a public IP address, or behind a router where you can set up port forwarding.
One or more Windows 11 machines to connect over VPN.
The official WireGuard for Windows client, same installer on server and clients (link in the Download section).
Administrative access on both machines, and the ability to open a UDP port on the firewall (and on the router, if the server sits behind NAT).
If you want clients to reach the office LAN too (not just the server), a bit of address planning — see the diagram below.

Architecture and addressing scheme

The reference scenario we’ll use throughout the article:

WireGuard network: 10.66.0.0/24 (a subnet dedicated to the VPN, separate from the real LAN — this avoids routing conflicts).
Server: VPN address 10.66.0.1, LAN address 192.168.1.10.
Clients: 10.66.0.2, 10.66.0.3, etc. — one address per device.
Listening port: UDP 51820 (the default; you can change it, see the security section).
Office LAN to reach over VPN: 192.168.1.0/24.

Note: if the server sits behind a router (e.g. a home connection, or an office without a direct public IP), you need a UDP 51820 port forward → the server’s LAN address. If the public IP isn’t static, add a DDNS (Dynamic DNS) service and use the hostname instead of the IP in the client’s Endpoint.

Setting up Windows Server 2022

Install WireGuard for Windows using the official MSI (the same installer as the client). The app opens with a tunnel management panel: we’ll only use it to generate keys the first time, because on a server the right approach is to run it as a Windows service, not leave it tied to a logged-in session.

Generating the server’s keypair

From the app’s Manage tunnels panel, choose Add Tunnel > Add empty tunnel…: a fresh keypair is generated right away, with the private key already filled into the config editor and the matching public key shown in the tunnel’s detail panel. Copy the public key somewhere safe: you’ll need it in every client’s configuration.

Warning: the private key is the only thing that identifies the server (or a client) on the VPN — treat it like a password. Don’t send it over email or chat, don’t put it in a repository, and if you suspect it’s been exposed, regenerate it and update every peer.

The server’s config file

Replace the editor’s content with something like this (adjusting addresses and keys):

[Interface]
PrivateKey = <server private key>
Address = 10.66.0.1/24
ListenPort = 51820

[Peer]
# laptop-01
PublicKey = <client public key>
AllowedIPs = 10.66.0.2/32

Each client gets its own [Peer] block, with its own public key and a single /32 address (its own, not the whole subnet — that’s how WireGuard knows which peer to route packets for that IP to). Save the file as C:\WireGuard\wg0.conf.

Running the tunnel as a Windows service

On a server, avoid the GUI app’s “Activate” button: that tunnel stays tied to the session of whoever started it and stops at logoff. The correct way is to install it as a service, so it starts on its own at boot and doesn’t depend on any session:

& "C:\Program Files\WireGuard\wireguard.exe" /installtunnelservice C:\WireGuard\wg0.conf

To stop or remove it later:

& "C:\Program Files\WireGuard\wireguard.exe" /uninstalltunnelservice wg0

Check the service is running with Get-Service WireGuardTunnel*.

Opening the port on the firewall and the router

On the Windows firewall:

New-NetFirewallRule -DisplayName "WireGuard VPN" -Direction Inbound -Protocol UDP -LocalPort 51820 -Action Allow

If the server is behind a router, also add the UDP 51820 port forward there, pointing to the server’s LAN address (192.168.1.10 in our diagram).

Setting up the Windows 11 client

Generating the client’s keypair

Same process as the server: install WireGuard for Windows, Add Tunnel > Add empty tunnel…, copy the generated public key (you’ll need it for the [Peer] block on the server).

The client’s config file

[Interface]
PrivateKey = <client private key>
Address = 10.66.0.2/24
DNS = 192.168.1.1

[Peer]
PublicKey = <server public key>
Endpoint = vpn.yourdomain.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

A couple of fields worth explaining:

Endpoint: the public address (or DDNS hostname) and port the client connects to. It’s the only place that needs an “externally reachable” address — the server doesn’t need to know the client’s IP in advance.
PersistentKeepalive = 25: sends an empty packet every 25 seconds to keep the client’s router NAT mapping open. Without it, if the client sits behind NAT (almost always true on home or mobile networks), the tunnel can “fall asleep” and the server can no longer reach it first.
AllowedIPs: this is where you decide between a full tunnel and a split tunnel — covered in the next section.

Import the file via WireGuard > Import tunnel(s) from file…, or paste the content directly into the empty tunnel’s editor created earlier.

Adding the peer on the server

Back on the server, add a [Peer] block for this client (or create the file with all peers from the start, if you already know how many clients you’ll connect):

[Peer]
# laptop-01
PublicKey = <client public key>
AllowedIPs = 10.66.0.2/32

Save and restart the tunnel service so it picks up the new config:

& "C:\Program Files\WireGuard\wireguard.exe" /uninstalltunnelservice wg0
& "C:\Program Files\WireGuard\wireguard.exe" /installtunnelservice C:\WireGuard\wg0.conf

Checking that everything works

On the client, activate the tunnel from the WireGuard app and check the main window: you should see the server’s host, the up/down traffic counters moving, and the latest handshake timestamp updating periodically. If the handshake never shows up, the problem is almost always at the network level (unreachable port, firewall, missing port forward) rather than in the WireGuard config itself.

Then, from the client’s command line:

ping 10.66.0.1

If it replies, the tunnel works. To check access to the office LAN (if you’ve enabled it, see below), try reaching a known resource, e.g. ping 192.168.1.10 or opening a file share.

Note: if pinging 10.66.0.1 works but pinging the LAN (192.168.1.x) doesn’t, the tunnel itself is fine: you’re just missing IP forwarding on the server, covered in the next section.

Full tunnel or split tunnel?

The AllowedIPs field in the client’s [Peer] block decides what goes through the VPN:

Full tunnel — AllowedIPs = 0.0.0.0/0, ::/0: all of the client’s traffic, including Internet traffic, goes through the server. Useful if you don’t trust the network you’re on (public Wi-Fi) or if you want the client to always exit with the server’s IP.
Split tunnel — AllowedIPs = 10.66.0.0/24, 192.168.1.0/24: only traffic to the VPN and the office LAN goes through the tunnel, everything else (Netflix, websites, everything else) goes straight out from the client’s own connection. Lighter on the server, and often faster for the user.

Either way, if you want clients to reach hosts on the real LAN (not just the server), Windows needs to route between the WireGuard interface and the physical network interface. By default it doesn’t: you need to enable IP forwarding:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" -Name "IPEnableRouter" -Value 1
Restart-Computer

If you want a full tunnel instead (clients go out to the Internet through the server), you also need outbound NAT on the server’s physical interface:

New-NetNat -Name WireGuardNAT -InternalIPInterfaceAddressPrefix 10.66.0.0/24

That command is enough on its own, no need to install the Routing and Remote Access role: the NetNat module has shipped with Windows Server since 2016.

A few security notes

One keypair per device, never shared between people: it’s the only way to revoke access for one device (just remove its [Peer] block on the server) without rotating everyone else’s keys.
Keep AllowedIPs as narrow as possible for every peer on the server: a client that only handles backups doesn’t need access to the whole LAN.
Changing the default port (51820) isn’t real security — it’s security through obscurity — but it noticeably cuts down the background noise of automated scanners knocking on the standard port in your logs.
WireGuard doesn’t replace application-level authentication: it grants network access, not user identity. If RDP, a file share or an admin panel sits behind the VPN, keep strong passwords and, where possible, MFA on those services too — the VPN is one layer, not the only one.
Back up private keys somewhere encrypted (a password manager, not a text file on the desktop): lose the server’s and you’ll have to regenerate it and reconfigure every client.

Why it’s this fast

Worth spending a couple of lines on the “fast” in the title. On Windows, since the WireGuardNT driver, the entire packet path runs in the kernel, no longer in a user-space process like the early versions (which relied on wireguard-go on top of the Wintun adapter). That, combined with the protocol having none of IPsec’s negotiation overhead (no IKE, no constant renegotiation) and none of OpenVPN’s typical TCP slowdown, translates into throughput very close to the physical connection’s limit and minimal added latency — in practice, often imperceptible compared to unencapsulated traffic.

Wrapping up

Once set up, a WireGuard tunnel between Windows Server and Windows 11 needs very little maintenance: no certificates to renew, no cipher list to keep up to date, one config file per peer. The places people usually get stuck are always the same three: an unreachable UDP port (firewall or missing port forward), IP forwarding disabled (no LAN access), and missing NAT (no Internet in full-tunnel mode) — if the tunnel comes up (handshake visible) but something downstream doesn’t work, it’s almost always one of these three.

Download

WireGuard for Windows — same installer for server and client, official site
wg0-server.conf — server config template, with two example peers
client.conf — client config template, with both variants (full tunnel / split tunnel) commented

References

wireguard.com — the protocol’s official site
WireGuard for Windows documentation — download page and client notes
New-NetNat (Microsoft docs) — details on the cmdlet used for full-tunnel NAT

Il nuovo sito, parte 4: le ultime finiture

Thu, 13 Aug 2026 21:15:00 +0200

Le prime tre parti di questa serie (1, 2, 3) raccontano decisioni con un inizio, uno svolgimento e una fine chiara: ricostruire il sito, correggere i bug, inventarsi le copertine giuste. Questa parte è diversa. È la lista, un po’ meno epica ma altrettanto necessaria, delle rifiniture fatte passando in rassegna il sito pezzo per pezzo prima di considerarlo pronto per andare online.

Un menu che non portava dove prometteva
Un indice per un blog che crescerà
I bottoni di condivisione erano fermi al 2016
Il colore dei social, recuperato dal sito vecchio
Il box dei commenti che si rompeva in silenzio
Tre pixel di troppo
Il vuoto fra il testo e la foto, in home
Perché questa parte conta

La voce “Blog” nel menu principale apriva il sottomenu con le categorie — ma cliccandoci sopra direttamente, invece di finire su /blog/ come ci si aspetterebbe, non succedeva nulla di utile. La voce del menu faceva doppio servizio: link e interruttore del sottomenu insieme, e il secondo comportamento vinceva sempre sul primo.

La correzione è stata separare le due responsabilità in due elementi distinti — un link vero verso /blog/ e, accanto, un piccolo pulsante a freccia dedicato solo ad aprire o chiudere il sottomenu delle categorie:

<li class="nav-item">
  <a class="nav-link" href="{{ '/blog/' | relative_url }}">Blog</a>
  <button type="button" class="nav-caret" aria-label="Mostra le categorie del blog" aria-expanded="false">
    <i class="fa fa-chevron-down" aria-hidden="true"></i>
  </button>
  <ul class="nav-submenu">
    {% for category in site.data.blog %}
    <li><a href="{{ category.href | relative_url }}">{{ category.name }}</a></li>
    {% endfor %}
  </ul>
</li>

Un bug banale da leggere nel codice, ma invisibile finché non si prova davvero a cliccare “Blog” aspettandosi di arrivare al blog.

Un indice per un blog che crescerà

Con dieci post il problema non si pone, ma prima o poi la lista cronologica in /blog/ smetterà di bastare da sola. Ho aggiunto due cose pensando in avanti: un indice di categorie navigabile in cima alla pagina, con il conteggio degli articoli per categoria, e la paginazione vera e propria — quindici post per pagina, tramite il plugin jekyll-paginate (il cui comportamento tutt’altro che intuitivo, con quattro pagine che scrivevano tutte sullo stesso file, è raccontato nella parte 2).

<nav class="category-index" aria-label="Categorie del blog">
  {% for category in site.data.blog %}
  <a class="category-pill" href="{{ category.href | relative_url }}">
    {{ category.name }}
    <span class="category-pill__count">{{ site.categories[category.name].size | default: 0 }}</span>
  </a>
  {% endfor %}
</nav>

Ho scartato di proposito l’idea di una tag cloud: con una manciata di categorie ben curate, le pillole già rispondono alla domanda “cosa trovo qui dentro” in un colpo d’occhio — una nuvola di tag avrebbe aggiunto rumore visivo senza aggiungere informazione.

I bottoni di condivisione erano fermi al 2016

Ogni post ha dei bottoni per condividerlo sui social. Non li avevo toccati durante la ricostruzione — funzionavano, quindi perché guardarli? Guardandoli davvero, la lista dei problemi è stata più lunga del previsto:

Twitter era ancora Twitter. Dominio e testo non aggiornati a X.
LinkedIn usava un endpoint dismesso. shareArticle non è più quello raccomandato da anni: quello attuale è sharing/share-offsite.
Reddit era in http://, non https://, e non passava nemmeno il titolo del post.
Nessun parametro era codificato per l’URL. Il titolo di un articolo con un apostrofo — capita spesso, in italiano — poteva rompere silenziosamente il link di condivisione.
Il testo dell’email era in inglese (“Check out this site”) in mezzo a un sito interamente in italiano.
Mancavano Bluesky, WhatsApp e Telegram, probabilmente più rilevanti oggi di Reddit per un pubblico italiano.

La correzione più istruttiva è quella dell’URL encoding. Senza:

https://x.com/intent/tweet?text={{ page.title }}&url={{ page_url }}

Con un titolo tipo “…dell’Infrastruttura IT…“, quell’apostrofo tipografico finiva letteralmente dentro l’URL, rompendo la struttura dei parametri. Basta un filtro:

https://x.com/intent/tweet?text={{ page.title | url_encode }}&url={{ page_url | url_encode }}

Un dettaglio che non si nota mai, finché non capita il titolo sbagliato.

Nella nuova versione i bottoni di condivisione erano tutti uguali: bordo neutro, colore d’accento del sito. Corretto, ma anonimo — nel sito vecchio ogni icona aveva il proprio colore di brand, e passandoci sopra con il mouse il bottone si riempiva di quel colore invertendo il testo in bianco. Un dettaglio che aiuta a riconoscere le icone a colpo d’occhio, prima ancora di leggerle.

Il file che conteneva quei colori l’avevo cancellato durante la ricostruzione, ma la cronologia Git non dimentica:

git show master:_sass/_social.scss

Da lì ho recuperato le tonalità esatte (Facebook #3b5998, LinkedIn #0077b5, Reddit #ff5700…) e le ho riapplicate, aggiungendo i colori ufficiali delle tre piattaforme nuove. Per X, che oggi non usa più l’uccellino ma un logo che Font Awesome — fermo al 2016 — non conosce, ho dovuto disegnare l’icona a mano con un piccolo SVG inline, esattamente come già fatto per Bluesky nella parte 3.

Il box dei commenti che si rompeva in silenzio

Questo è stato il bug più subdolo dell’intera rifinitura. Un lettore mi ha segnalato che, aprendo certi articoli, il box dei commenti restava vuoto — a meno di ricaricare la pagina, dopodiché funzionava perfettamente.

La causa era in una singola riga, rimasta invariata probabilmente dal giorno in cui questo sito ha adottato Disqus:

cookieValue = document.cookie.match(/(;)?cookiebar=([^;]*);?/)[2];

Se il cookie cookiebar non esiste ancora — cioè alla primissima visita, prima che l’utente interagisca col banner dei cookie — document.cookie.match() restituisce null. E leggere [2] da null non restituisce undefined: lancia un errore JavaScript che interrompe l’intero script sul colpo. Disqus non veniva nemmeno provato a caricare. Solo un secondo caricamento della pagina, con il cookie ormai presente, faceva ripartire lo script da capo — da qui il “funziona solo dopo il reload”.

La correzione è una manciata di righe più difensive:

var cookieMatch = document.cookie.match(/(?:^|; )cookiebar=([^;]*)/);
var cookieValue = cookieMatch ? decodeURIComponent(cookieMatch[1]) : null;

Ne ho approfittato per allineare l’imbottitura di Disqus alla configurazione raccomandata attuale — URL e identificatore di pagina dichiarati esplicitamente invece di lasciarli dedurre automaticamente — e per passare da un URL “protocol-relative” (//...disqus.com/embed.js) a un più corretto https:// esplicito.

Tre pixel di troppo

Ultima segnalazione, la più piccola: nella pagina Progetti, il numero di fork su GitHub andava a capo su una riga propria invece di stare accanto alle stelle, per pochi pixel. Corretto allargando leggermente il contenitore generale del sito (1280 → 1360px, un aumento del 6% impercettibile ovunque tranne che dove serviva) e riducendo il padding orizzontale delle pillole statistiche. Verificato sul caso peggiore — il repository di questo stesso sito, con oltre cento stelle — che ora sta comodamente su una riga sola.

Il vuoto fra il testo e la foto, in home

Ultima segnalazione, arrivata guardando la home su uno schermo largo: nella hero, il blocco di testo a sinistra e la mia foto a destra sembravano due isole scollegate, con un vuoto enorme in mezzo che restringere la finestra non risolveva. Colpa di justify-content: space-between su un contenitore largo quanto l’intera pagina (1360px): spinge i due elementi ai bordi opposti a prescindere da quanto sia effettivamente largo il testo — più lo schermo è ampio, più cresce il vuoto.

Primo tentativo, sbagliato: dare alla hero un max-width proprio e centrarla, per tenere testo e foto più vicini. Il risultato sembrava due blocchi sovrapposti, perché le sezioni sotto (Progetti, Blog) restavano larghe quanto tutta la pagina e non più allineate al bordo sinistro della hero. Corretto tornando alla larghezza piena e sostituendo space-between con justify-content: flex-start più un gap fisso: testo e foto restano un gruppo compatto, ancorato allo stesso margine di tutto il resto della pagina.

Ultimo dettaglio, puramente estetico, che ha richiesto tre tentativi: prima un alone sfumato nel colore d’accento dietro la foto (“sembro una divinità scesa dal cielo”, bocciato giustamente), poi un cerchio piatto più discreto nello stesso colore delle card sotto, e alla fine — con lo spazio ormai risolto dal fix di layout — nessun elemento decorativo. La foto non ne aveva più bisogno: il problema era il vuoto intorno, non l’assenza di uno sfondo.

Perché questa parte conta

Nessuna di queste correzioni cambia in modo visibile il sito per un visitatore distratto. Ma sommate, sono la differenza tra un sito che “sembra pronto” e uno che lo è davvero: link che portano dove devono, un box commenti che funziona sempre e non solo a volte, un dettaglio di colore che aiuta a riconoscere un’icona senza doverla leggere. Le parti divertenti di ricostruire un sito sono le prime tre. Questa è quella che, silenziosamente, fa la differenza quando qualcuno lo usa sul serio.

Il nuovo sito, parte 3: le copertine che si adattano al tema

Thu, 13 Aug 2026 10:00:00 +0200

Nelle prime due parti di questa serie (1, 2) ho raccontato perché ho ricostruito questo sito e i bug scoperti subito dopo. Poi mi serviva un’ultima cosa, piccola: una copertina per quei due articoli. Ci è voluto più tempo di quanto vorrei ammettere, ed è successo letteralmente mentre scrivevo — quindi eccolo qui, come terzo capitolo.

L’idea di partenza
Tre tentativi, tre problemi
L’osservazione che ha cambiato tutto
Catturare uno screenshot “in chiaro” quando il browser insiste per lo scuro
L’implementazione finale: zero JavaScript
Cosa mi porto a casa, di nuovo

L’idea di partenza

Volevo una copertina che raccontasse visivamente il passaggio dal vecchio sito al nuovo: uno screenshot di ciascuna versione, uniti in un’unica immagine — due terzi vecchio e un terzo nuovo per la prima parte, il contrario per la seconda.

Nessun tool di editing immagini a disposizione, solo la riga di comando. Ho installato Pillow (Python) per comporre le immagini, e usato Microsoft Edge in modalità headless per catturare gli screenshot: sia del sito vecchio, ancora online in produzione, sia del nuovo, in locale.

msedge --headless --disable-gpu --window-size=1600,1400 --screenshot=old.png https://cristiancastellari.it/

Fin qui, facile.

Tre tentativi, tre problemi

Primo tentativo: dissolvenza larga tra le due immagini. Risultato: i testi delle due pagine, sovrapposti nella zona di sfumatura, diventavano illeggibili — un doppio esposizione confusa, non una transizione elegante.

Secondo tentativo: ho ristretto il ritaglio a soli 300 pixel in alto, giusto l’header. Risultato: si vedeva solo lo sfondo animato a particelle del vecchio sito, senza alcun indizio che si trattasse davvero di un sito diverso. Contenuto zero, contesto zero.

Terzo tentativo: ritaglio più alto (750px, header più una porzione di contenuto reale) e un taglio netto con una linea di accento blu invece della dissolvenza. Finalmente qualcosa di leggibile e riconoscibile — ma mancava ancora qualcosa.

L’osservazione che ha cambiato tutto

A quel punto ho notato una cosa banale ma rivelatrice: la copertina, da sola, non “sapeva” se sarebbe stata vista su una pagina chiara o scura. Un’immagine con il nuovo sito fotografato in tema scuro, su una pagina già scura, si mimetizza — poco contrasto, poco impatto. La stessa immagine su una pagina chiara, invece, risalta.

La soluzione ovvia, una volta vista: due copertine per articolo, una con il nuovo sito fotografato in chiaro e una in scuro, mostrate in alternativa a seconda del tema con cui il lettore sta guardando il sito in quel momento — sempre quella che fa più contrasto.

Catturare uno screenshot “in chiaro” quando il browser insiste per lo scuro

Qui la parte tecnicamente più interessante. Il sistema su cui lavoro preferisce il tema scuro, quindi ogni screenshot headless usciva scuro di default. Ho provato i flag “giusti” di Chromium per forzare il tema chiaro:

--force-prefers-color-scheme=light
--blink-settings=preferredColorScheme=1

Nessuno dei due ha funzionato con questa versione di Edge headless — lo screenshot continuava a uscire scuro, senza errori, semplicemente ignorando il flag.

La soluzione che ha funzionato: imposta la preferenza attraverso il sito stesso, non attraverso il browser. Il selettore di tema di questo sito salva la scelta in localStorage. Ho creato una micro-pagina temporanea che imposta quel valore e reindirizza alla home:

<script>
localStorage.setItem('theme', 'light');
location.href = '/';
</script>

…e l’ho aperta con Edge headless usando un profilo persistente (--user-data-dir), in due passaggi separati: prima la micro-pagina (per scrivere il valore), poi lo screenshot della home vera e propria, riusando lo stesso profilo — così localStorage sopravviveva tra i due lanci del browser. Non elegantissimo, ma affidabile al 100%.

L’implementazione finale: zero JavaScript

Con gli screenshot giusti in mano, l’ultimo pezzo è stato mostrare l’immagine corretta in base al tema — usando lo stesso meccanismo, puramente CSS, con cui questo sito gestisce già i tre stati automatico/chiaro/scuro:

.post-image--on-dark {
  display: none;
}

@media (prefers-color-scheme: dark) {
  :root:not([data-theme="light"]) {
    .post-image--on-light { display: none; }
    .post-image--on-dark { display: block; }
  }
}

:root[data-theme="dark"] {
  .post-image--on-light { display: none; }
  .post-image--on-dark { display: block; }
}

Il markup diventa semplicemente due tag <img>, uno per variante:

<img class="post-image post-image--on-light" src="cover.jpg">
<img class="post-image post-image--on-dark" src="cover-dark.jpg">

Il browser scarica entrambe le immagini (un piccolo costo, accettabile per due JPEG leggeri) ma ne mostra sempre una sola, decisa dal CSS in base al tema corrente — nessun JavaScript aggiuntivo, nessun flash, nessuna richiesta extra.

Cosa mi porto a casa, di nuovo

La versione finale delle copertine — quella che stai vedendo proprio ora, in cima a questo articolo — è il quinto tentativo, non il primo. Nessuno dei tentativi precedenti era “sbagliato” in senso tecnico: producevano tutti un’immagine valida. Erano semplicemente poco convincenti, ed è stato solo continuando a guardarli con occhio critico — mio, non del codice — che è emerso il problema vero: un’immagine statica non può sapere in che contesto verrà mostrata, a meno che non gliene costruisci due e lasci decidere il CSS.

Anche questo, alla fine, è un dettaglio che nessuno noterà consciamente. Ma se il sito regge bene sia in chiaro che in scuro, è anche per questo pomeriggio passato a litigare con i flag di un browser headless.

Nella parte 4, l’ultima di questa serie: le rifiniture minori ma necessarie trovate ripassando il sito pezzo per pezzo.

Il nuovo sito, parte 2: i bug nascosti in un sito nuovo di zecca

Wed, 12 Aug 2026 18:20:00 +0200

Nella prima parte ho raccontato perché ho deciso di ricostruire questo sito da zero, insieme a Claude Code, e come l’intero lavoro si sia concluso in un pomeriggio invece che in settimane. Quello che non ho detto è che, appena ho iniziato a usare il sito nuovo per davvero — cliccando in giro, cambiando tema, aggiungendo contenuti — sono saltati fuori bug che il codice, da solo, non avrebbe mai rivelato. Codice scritto quel pomeriggio stesso, non debito ereditato dal 2019.

Qui ci sono i cinque più interessanti.

1. Il bottone sottolineato che non voleva saperne
2. Il tema chiaro che si perdeva a ogni pagina
3. Le stelline di GitHub sparite
4. Le pillole delle categorie che puntavano nel vuoto
5. Quattro pagine, un solo file (quello di Jekyll)
Cosa mi porto a casa

1. Il bottone sottolineato che non voleva saperne

Il primo problema evidente: il bottone “Scarica il CV in PDF” con il testo sottolineato, bruttissimo, in mezzo a un componente che doveva essere un bottone pieno. Stessa cosa era già successa sulle card della pagina Contatti.

La causa: le pagine come CV e Contatti avvolgono il loro contenuto in un contenitore .prose, pensato per lo stile tipografico degli articoli del blog (dove i link devono essere sottolineati, per leggibilità e accessibilità). La regola CSS era:

.prose a {
  text-decoration: underline;
}

Il problema è che un bottone (<a class="btn">) o una card cliccabile (<a class="card">), quando si trovano dentro un paragrafo <p> dentro .prose — come capita spesso, per semplice comodità di markup — vengono presi in pieno da questa regola, che ha più specificità della classe del componente stesso. Ho ristretto la regola al vero testo discorsivo:

.prose p a:not(.btn):not(.pill):not(.card),
.prose li a:not(.btn):not(.pill):not(.card),
.prose blockquote a:not(.btn):not(.pill):not(.card) {
  text-decoration: underline;
}

Non basta scrivere “solo i link nei paragrafi vanno sottolineati” — bisogna anche escludere esplicitamente i componenti che, per comodità di impaginazione, finiscono dentro un paragrafo pur non essendo testo.

2. Il tema chiaro che si perdeva a ogni pagina

Avevo costruito un selettore Automatico/Chiaro/Scuro con uno script che, nell’<head>, legge la preferenza salvata e la applica prima del disegno della pagina, per evitare il classico “flash” del tema sbagliato. Cliccavo “Chiaro”, funzionava. Cambiavo pagina, tornava scuro.

Il colpevole: Brave. Il browser blocca, per motivi di privacy, gli script inline (come quello nell’<head>) in certe condizioni, pur lasciando passare i file .js esterni. Il pulsante mostrava comunque “Chiaro” come selezionato — perché quello stato veniva letto correttamente da localStorage da un file esterno — ma nessuno riapplicava davvero l’attributo sulla pagina.

La correzione: non fidarsi che lo script inline avesse fatto il suo lavoro. Il file esterno ora riapplica sempre l’attributo all’avvio, invece di limitarsi ad aggiornare l’aspetto del pulsante:

var initialChoice = currentChoice();
applyAttribute(initialChoice);   // non solo updateButtons(initialChoice)
updateButtons(initialChoice);

Ridondante, se lo script inline funziona. Indispensabile, quando (per qualsiasi motivo, non solo Brave) non funziona.

3. Le stelline di GitHub sparite

Le card dei miei progetti mostrano stelle e fork presi in diretta dalla GitHub API. Funzionava, poi improvvisamente tutti i numeri sono spariti, sostituiti da un trattino.

X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0

L’API pubblica di GitHub, senza autenticazione, concede 60 richieste all’ora per indirizzo IP. Tra i miei test e i ricaricamenti della pagina durante lo sviluppo, l’avevamo esaurita — e con 5 repository interrogati a ogni caricamento della pagina Progetti, in produzione sarebbero bastate 12 visite in un’ora per rifare lo stesso danno.

Non un bug da correggere, ma un limite strutturale da progettare meglio: ho aggiunto una cache lato client di 6 ore in localStorage, così visite ripetute non richiamano l’API ogni volta.

4. Le pillole delle categorie che puntavano nel vuoto

Dopo aver rinominato le categorie del blog — “Kace” è rimasta “Kace”, ma “Tools” è diventata “Strumenti”, “ITIL” è diventata “Filosofia di Lavoro” — le pillole colorate sulle card dei post (quelle che mostrano la categoria e ci si clicca sopra) hanno iniziato a puntare a URL che non esistevano. Il codice faceva semplicemente:

<a class="pill" href="{{ category | downcase | prepend: '/' | relative_url }}">

Funzionava per puro caso quando il nome della categoria coincideva con lo slug dell’URL (Kace → /kace/). Rinominando “Strumenti” (URL reale: /tools/), quella logica ha iniziato a generare /strumenti, una pagina inesistente. La correzione: cercare davvero l’URL configurato, invece di indovinarlo:

{% assign cat_data = site.data.blog | where: "name", category | first %}
<a class="pill" href="{{ cat_data.href | relative_url }}">

Una riga di scorciatoia che ha funzionato per caso finché i nomi non sono cambiati — il tipo di bug che resta invisibile finché qualcuno, mesi dopo, decide di rinominare qualcosa.

5. Quattro pagine, un solo file (quello di Jekyll)

Questo è stato il più tosto. Volevo la paginazione degli articoli del blog (utile quando supereranno i 15 post), e ho aggiunto il plugin jekyll-paginate. Impostato tutto, build pulita, nessun errore — ma abbassando temporaneamente il numero di post per pagina per testare davvero il meccanismo, Jekyll ha iniziato ad avvisarmi:

Conflict: The following destination is shared by multiple files.
  C:/.../blog/index.html
   - blog/index.html
   - blog/index.html
   - blog/index.html
   - blog/index.html

Quattro pagine diverse (pagina 1, 2, 3, 4), tutte scritte nello stesso identico file. Ho dovuto leggere il codice sorgente di Jekyll stesso per capire perché: la mia pagina blog/index.html aveva un permalink: /blog/ esplicito nel front matter. Il plugin di paginazione crea copie della pagina per ogni “numero” (assegnando a ciascuna una diversa sotto-cartella), ma se il file ha un permalink fisso nel front matter, quel valore vince sempre, a prescindere dalla cartella assegnata alla copia — perché nel codice di Jekyll, il metodo che calcola l’URL di una pagina dà priorità assoluta al permalink esplicito:

# jekyll/page.rb
def permalink
  data.nil? ? nil : data["permalink"]
end

Tutte e quattro le copie, leggendo lo stesso file sorgente, ereditavano lo stesso permalink fisso. La correzione, una volta capita la causa, è stata la più semplice di tutte: togliere il permalink esplicito. Il file si chiama index.html e vive nella cartella blog/ — Jekyll gli assegna già /blog/ da solo, senza bisogno di forzarlo, e a quel punto le pagine successive (/blog/pagina2/, /blog/pagina3/…) si generano correttamente.

Cosa mi porto a casa

Nessuno di questi cinque bug era debito tecnico ereditato — erano tutti in codice scritto quello stesso pomeriggio. La lezione non è “l’IA scrive codice pieno di bug”: è che qualsiasi codice, scritto da chiunque, va usato davvero per scoprire dove si rompe. La differenza, lavorando con Claude Code, è stata la velocità con cui ogni bug — dalla sottolineatura CSS al codice sorgente di Jekyll — è stato isolato, spiegato e corretto, quasi sempre nell’arco della stessa conversazione in cui l’ho segnalato.

Un sito nuovo, costruito in un pomeriggio, con la stessa attenzione ai dettagli che normalmente richiederebbe settimane. Continuo a scoprirne di nuovi, probabilmente — ma per ora, il sito che vedete è quello.

C’è anche una parte 3, più leggera: la storia di come sono nate le copertine di questi stessi articoli.

Il nuovo sito, parte 1: perché ho deciso di ripartire da zero

Wed, 12 Aug 2026 18:00:00 +0200

Stamattina ho raccontato come ho passato il pomeriggio a rimettere in sesto le dipendenze di questo sito — Ruby, npm, Bootstrap, Chart.js, tutta roba ferma al 2019 che nessuno aveva mai più toccato davvero. Quel lavoro doveva essere la fine della giornata: sito sistemato, dipendenze pulite, tutti contenti.

Invece, mentre sistemavo l’ennesimo bug dormiente, mi sono fatto una domanda scomoda: sto davvero curando questo sito, o sto solo rallentando la sua fine?

Il momento in cui ho smesso di fare manutenzione
Il vincolo che non potevo permettermi di rompere
Le decisioni prese insieme
La velocità non è un compromesso sulla qualità

Il momento in cui ho smesso di fare manutenzione

Il tema di partenza (derivato da Jalpc) era una landing page one-page con Bootstrap 3, jQuery e una manciata di plugin che oggi nessuno sceglierebbe più: un carosello hero, un menu mobile basato su Bootstrap 3 collapse, un grafico radar via Chart.js per le competenze. Funzionale, nel 2016. Nel 2026, con Bootstrap 3 a fine vita (due XSS moderate mai patchate, per dirne una) e un intero pomeriggio già speso a scoprire quanto debito tecnico si fosse accumulato, la domanda vera non era più “come lo sistemo” ma “vale ancora la pena sistemarlo?”.

La risposta che mi sono dato: no. Non perché il contenuto non valesse — dieci anni di post tecnici, un CV, i miei progetti — ma perché il contenitore aveva fatto il suo tempo. Ho deciso di ricostruire il sito da zero, con un tema nuovo, scritto apposta per quello che sono oggi: un Infrastructure & Service Management Manager con un blog tecnico, non più un laptop pieno di plugin jQuery.

Il vincolo che non potevo permettermi di rompere

C’era però una condizione non negoziabile: ogni URL dei post del blog doveva restare esattamente identico. Dieci anni di articoli tecnici, alcuni ancora citati o linkati da terzi, indicizzati da Google — un redesign che rompe i permalink è un redesign che butta via anni di posizionamento. Qualunque cosa avessi ricostruito, doveva convivere con questo vincolo dall’inizio, non come ripensamento finale.

Ho lavorato con Claude Code, l’assistente IA da riga di comando di Anthropic, che avevo già usato per il lavoro di manutenzione della mattina. La differenza, per un progetto di questa portata, è stata partire con un piano scritto invece che con il codice: prima abbiamo mappato cosa del sito esistente fosse contenuto reale (i miei progetti GitHub, il CV, gli articoli) e cosa fosse invece morto — funzionalità mai attivate (multilingua), sezioni con dati segnaposto mai personalizzati, categorie di blog senza un solo articolo. Poi abbiamo scritto un documento di piano vero e proprio: architettura delle pagine, sistema di design, quali file sarebbero spariti e quali sarebbero rimasti, come verificare che i permalink non si rompessero. Solo dopo, il codice.

Questo approccio — pianificare prima di scrivere, invece di scrivere e sistemare — è probabilmente il motivo per cui un lavoro che immaginavo su più giorni si è concluso in un pomeriggio.

Le decisioni prese insieme

Alcune scelte le ho fatte io, altre le ho delegate, altre ancora le abbiamo discusse:

Stack: restare su Jekyll. GitHub Pages lo supporta nativamente, la pipeline di build l’avevo appena sistemata la mattina stessa, e cambiare generatore avrebbe voluto dire rifare da capo anche quello.
Stile visivo: minimal e professionale. Niente più carosello, niente animazioni jQuery — palette neutra, molto spazio bianco, il blu #3385FF mantenuto come accento (è già nel favicon, nei profili social collegati, non aveva senso perderlo).
Struttura: da one-page a sito multi-pagina — Home, CV, Progetti, Blog, Contatti — più adatta a un sito che deve funzionare sia come portfolio professionale sia come blog tecnico.
Cosa buttare: Bootstrap 3, jQuery e tutti i suoi plugin, l’intera pipeline npm di build (sostituita dalla compilazione Sass nativa di Jekyll, zero dipendenze front-end), il grafico radar Chart.js (sostituito da una lista di competenze raggruppate per area, più leggibile e coerente con lo stile minimal).

Il CV e le competenze, tra l’altro, li avevamo già aggiornati con i dati reali dal mio profilo LinkedIn qualche ora prima — quel lavoro è confluito direttamente nella nuova pagina /cv/.

La velocità non è un compromesso sulla qualità

La parte che mi ha sorpreso di più non è stata la velocità in sé, ma il fatto che non sia arrivata a scapito della verifica. Ogni singolo pezzo — ogni layout, ogni pagina, ogni categoria del blog — è stato ricompilato e controllato prima di passare al successivo. Prima di considerare il lavoro finito, abbiamo fatto una cosa che a mano non avrei mai avuto la pazienza di fare: un confronto automatico, URL per URL, tra il sito vecchio e quello nuovo, per garantire zero permalink rotti. Il risultato: tre nuove pagine aggiunte (/cv/, /progetti/, /contatti/), zero URL persi.

Quello che un redesign di questo genere avrebbe richiesto in settimane — se fatto da solo, nei ritagli di tempo serali — si è concluso in un pomeriggio. Non perché il lavoro fosse meno, ma perché avere un collega che scrive codice, lo verifica, e lo ricontrolla in loop, senza stancarsi e senza saltare passaggi, cambia radicalmente i tempi.

Detto questo — e lo scoprirete nella prossima puntata — “veloce” non ha voluto dire “senza intoppi”. Anche un sito costruito da zero, in poche ore, ha nascosto una manciata di bug genuinamente interessanti: uno di questi mi ha fatto finire a leggere il codice sorgente di Jekyll stesso.

Continua nella parte 2: i bug nascosti in un sito nuovo di zecca.

Manutenzione straordinaria: quando aggiornare le dipendenze rompe tutto

Wed, 12 Aug 2026 14:00:00 +0200

Questo sito gira su Jekyll da anni, con un tema (Jalpc) basato su Bootstrap, jQuery e qualche libreria JS per grafici e animazioni. Come capita spesso ai side-project personali, negli ultimi anni l’ho tenuto vivo solo dal punto di vista dei contenuti, lasciando che Dependabot aprisse pull request di aggiornamento dipendenze in automatico, quasi sempre mergiate a scatola chiusa perché “tanto sono solo numeri di versione”.

Oggi ho deciso di fare pulizia sul serio: verificare gemme Ruby e pacchetti npm, aggiornarli davvero, e assicurarmi che il sito continuasse a funzionare. Quello che è successo è stata una piccola lezione di archeologia informatica.

Il problema di partenza: una build congelata dal 2019
Aggiornare Ruby e Jekyll
Ripulire npm: 25 vulnerabilità, quasi tutte fantasma
Il sito si rompe: colpa di Bootstrap 5 (che in realtà non esiste)
Il grafico delle competenze sparito: Chart.js v2 vs v4
Il bundle JavaScript da 228 byte
Le icone sparite: Font Awesome 4 vs 5
Il filo conduttore
E adesso?

Il problema di partenza: una build congelata dal 2019

La prima cosa che ho scoperto è che gli asset compilati del sito (i file CSS/JS minificati in static/assets/) portavano tutti la data 20190620 nel nome. Sei anni di pull request di Dependabot avevano alzato pian piano i numeri di versione dichiarati in package.json — Bootstrap da 3 a 4 a 5, Chart.js da 2 a 4, Font Awesome da 4 a 5 — ma nessuno aveva mai più eseguito npm run build da allora.

Il sito pubblicato, quindi, funzionava benissimo per un motivo molto semplice: stava ancora servendo i bundle compilati nel 2019, con le librerie di allora. package.json diceva una cosa, i file effettivamente in produzione ne dicevano un’altra. Due sistemi paralleli che non si parlavano da anni.

Appena ho lanciato una build vera, questa finzione è crollata tutta insieme.

Aggiornare Ruby e Jekyll

Prima ostacolo: Jekyll 4.2.2 (versione dichiarata nel Gemfile.lock) non partiva più su Ruby 3.4, l’unica installata sulla macchina. Ruby 3.4 ha smesso di includere csv, logger e bigdecimal come gemme di default, e Jekyll 4.2.2 le usava senza dichiararle esplicitamente. Anche risolto quello, Liquid 4.0.3 (il motore dei template di Jekyll) chiamava String#tainted?, un metodo rimosso da Ruby 3.2 in poi.

Soluzione: aggiornare Jekyll a 4.4.1, che dichiara correttamente le sue dipendenze, e Liquid alla patch 4.0.4 che risolve il problema di tainted?.

Ripulire npm: 25 vulnerabilità, quasi tutte fantasma

Sul lato npm la sorpresa è stata diversa. npm audit segnalava 25 vulnerabilità, ma scavando ho trovato che il package.json conteneva pacchetti come @npmcli/arborist, hosted-git-info, jsprim e persino npm stesso, elencato come dipendenza del progetto. Nessuno di questi veniva mai usato da una riga di codice del sito: erano tutti finiti lì, probabilmente, come effetto collaterale di vecchi npm audit fix che avevano promosso dipendenze transitive a dipendenze dirette invece di usare gli overrides.

Rimuovendo i pacchetti morti (verificato con una ricerca sull’intero repository, zero riferimenti):

25 vulnerabilità → 0
431 pacchetti installati → 40

Nessun codice toccato, solo pulizia.

Il sito si rompe: colpa di Bootstrap 5 (che in realtà non esiste)

Con le dipendenze pulite e aggiornate, ho lanciato per la prima volta in anni una vera ricompilazione degli asset. Il sito è diventato illeggibile: menu di navigazione non collassato, sezioni impilate senza layout, icone sparite.

La causa: il bundle CSS compilato nel 2019 conteneva Bootstrap v3.4.1. Tutto il markup del tema — layout, header, sezioni della landing page — è scritto con classi Bootstrap 3 (navbar-default, navbar-fixed-top, col-lg-*…). Ma package.json dichiarava da tempo bootstrap: "^5.0.0", mai realmente compilato contro quel markup. Il numero “5” in package.json era, di fatto, una bugia mai verificata.

Ho riportato Bootstrap a ^3.4.1, l’unica versione compatibile con il tema così com’è. Bootstrap 3 è però a fine vita: porta con sé due vulnerabilità XSS moderate in popover/tooltip mai patchate. Rischio pratico basso (il sito non inserisce mai contenuto utente in quei componenti), ma è un compromesso consapevole, in attesa di una revisione più profonda del tema.

Il grafico delle competenze sparito: Chart.js v2 vs v4

Nella sezione “Cosa so fare” della home c’è un grafico radar (Chart.js) con le mie competenze. Dopo la ricompilazione, spazio vuoto. Il codice della pagina configurava il grafico così:

options: {
    scale: { ticks: {min: 0, max: 100}, pointLabels: {fontSize: 14} },
    legend: { display: false },
}

Sintassi di Chart.js 2. Nella versione 4 (quella effettivamente installata da tempo) la configurazione è cambiata: scale è diventato scales.r, legend è finito dentro plugins. La vecchia sintassi non generava errori, semplicemente veniva ignorata in silenzio, e il grafico non si disegnava.

options: {
    responsive: true,
    scales: { r: { min: 0, max: 100, pointLabels: {font: {size: 14}} } },
    plugins: { legend: { display: false } },
}

Cinque righe, e il radar è tornato visibile.

Il bundle JavaScript da 228 byte

Questo è stato il bug più subdolo. Lo script di build (build/build.js) passa a UglifyJS l’elenco dei percorsi dei file da minificare e concatenare — jQuery, Bootstrap, Chart.js, eccetera. Dopo la ricompilazione, il file JS finale pesava 228 byte invece delle solite centinaia di KB, e conteneva, testuale:

node_modules,jquery,dist,jquery.js,static,js,bs3,typeahead.js,node_modules,bootstrap,...

I percorsi dei file, non il loro contenuto. UglifyJS li aveva interpretati come codice sorgente — ogni / letto come operatore di divisione tra variabili — invece di leggerli da disco. Il motivo: UglifyJS 3.x ha cambiato API. Nella versione 2 (quella in uso nel 2019), passare un array di percorsi significava “leggi questi file da disco”. Nella 3.x, un array di stringhe viene trattato come codice sorgente letterale: bisogna leggere i file esplicitamente e passare un oggetto {nomefile: contenuto}.

Il bug è nato probabilmente anni fa, quando uglify-js è stato aggiornato alla v3 da una PR di Dependabot — ma è rimasto dormiente, invisibile, perché nessuno rieseguiva più la build. Corretto leggendo i file esplicitamente prima di passarli a UglifyJS, e aggiunto un controllo sugli errori che prima veniva ignorato silenziosamente.

Le icone sparite: Font Awesome 4 vs 5

Ultimo tassello: le iconcine sui bottoni (Linux, Apple, i social nella sezione “Chi sono”) erano vuote. Lo script di build puntava a node_modules/components-font-awesome/css/font-awesome.css — file che non esiste più in Font Awesome 5, che ha riorganizzato i CSS in all.css più uno shim (v4-shims.css) per la retrocompatibilità con i vecchi nomi di classe (fa fa-linux, usati ovunque nel tema). Il riferimento al file mancante veniva ignorato silenziosamente dal compressore CSS, proprio come il resto.

Corretto puntando ai file giusti e copiando i webfont di Font Awesome 5 nella cartella corretta (un dettaglio non banale: i percorsi relativi dentro il CSS compilato si risolvono rispetto alla posizione del bundle finale, non rispetto alla posizione originale dei file sorgente — un’altra assunzione implicita che nessuno aveva mai verificato).

Il filo conduttore

Quattro bug, quattro cause diverse, ma un solo colpevole comune: una pipeline di build che nessuno eseguiva più. Dependabot aggiornava fedelmente i numeri di versione, il sito pubblicato continuava a funzionare (perché serviva asset compilati anni prima), e il divario fra “quello che il progetto dichiara” e “quello che il progetto effettivamente pubblica” cresceva silenzioso, versione dopo versione.

Nessuno di questi bug avrebbe causato danni se qualcuno avesse rilanciato una build ogni tanto. La lezione, come spesso capita, non è tecnica ma di processo: gli aggiornamenti automatici delle dipendenze sono utili, ma senza una build (e magari un deploy) che li verifichi regolarmente, si accumula un debito invisibile che esplode tutto insieme, il giorno che qualcuno ricomincia a guardare.

E adesso?

Il sito torna a funzionare com’era prima, con le dipendenze aggiornate dove ha senso farlo (Ruby, Jekyll, npm) e bloccate dove non lo ha, come Bootstrap 3, in attesa di qualcosa di più definitivo: sto lavorando a una versione completamente nuova di questo sito, con un aspetto più moderno, mantenendo però intatti tutti i permalink degli articoli del blog per non perdere l’indicizzazione su Google. Ne parlerò presto.

Quando l'API va giù: tenere aggiornata la mappa di flottastellare.it

Tue, 11 Aug 2026 18:30:00 +0200

Fuori dall’orario di lavoro (e fuori dal restyling di questo sito, di cui potete leggere qui) gioco a Elite: Dangerous, e faccio parte dell’Alto Comando Flotta Stellare (ACFS), uno squadrone di comandanti indipendenti radunati attorno a una minor faction chiamata, per l’appunto, Flotta Stellare. Il sito dello squadrone, flottastellare.it, è anche lui un sito Jekyll — e anche lui, come questo, ha bisogno ogni tanto di un po’ di manutenzione.

Una tabella che si aggiorna da sola (di solito)
Il candidato scartato
Il sostituto: Spansh
I bug trovati passando i dati al setaccio
Il risultato

Una tabella che si aggiorna da sola (di solito)

Nella pagina about/index.md del sito teniamo una tabella con tutti i sistemi stellari presidiati dalla fazione: governo, popolazione, alleanza, stato di controllo. Sono dati che si muovono di continuo — il BGS (Background Simulation) di Elite Dangerous fa evolvere ogni sistema in base a cosa i giocatori ci fanno dentro, giorno per giorno — quindi tenerla aggiornata a mano non è pensabile. Da qui uno script Python, lanciato ogni tanto dalla root del repository, che va a interrogare un’API pubblica e riscrive la tabella.

Il problema: lo script puntava a EDSM, e l’API di EDSM ha smesso di rispondere.

Il candidato scartato

Prima di cercare un sostituto ho controllato se l’API di Inara — un altro grande database comunitario per Elite Dangerous — potesse coprire lo stesso bisogno. Risposta breve: no. È un’API pensata per essere push-only dal punto di vista di un comandante: riceve eventi come addCommanderReputation o setCommanderRankPilot dal client di gioco, non espone un modo per interrogare popolazione o fazioni presenti in un sistema arbitrario. Gli unici endpoint di lettura sono legati al profilo di un singolo comandante o alle community goal recenti — niente che aiuti a ricostruire lo stato di un sistema. Scartata.

Il sostituto: Spansh

La soluzione arriva da Spansh, un altro strumento molto popolare nella comunità di Elite Dangerous (più noto per il suo route planner), che espone un’API pubblica non ufficiale senza bisogno di alcuna chiave: una richiesta GET con il nome del sistema restituisce governo, popolazione, alleanza, stato di sicurezza e perfino le fazioni minori presenti con la relativa influenza.

Il nuovo script, spansh_sync.py, non si limita a rimpiazzare quello vecchio funzione per funzione — fa qualcosa in più:

Aggiunge le righe mancanti, in ordine alfabetico, per i sistemi che lo squadrone ha conquistato ma che non erano ancora in tabella.
Aggiorna i campi esistenti solo quando il dato live di Spansh è effettivamente diverso da quello in tabella (un sistema passa da Controllato a Non Controllato, cambia governo, l’alleanza si sposta) — e stampa un log riga per riga di cosa è cambiato.
Lascia invariate le righe non trovate su Spansh (es. sistemi visitati ma non ancora presenti nei dump pubblici), invece di cancellarle per errore.
Aggiorna da solo last_modified_at nel front matter a ogni esecuzione.
Ricalcola il totale nella frase “Governiamo su N abitanti”, sommando la popolazione di tutti i sistemi con stato Controllato.

I bug trovati passando i dati al setaccio

Il primo lancio contro dati reali, come spesso succede, ha fatto emergere problemi che uno script “silenzioso” aveva lasciato indisturbati per chissà quanto:

Una riga con il nome duplicato per errore: “V0502 V0502 Ophiuchii” invece di “V0502 Ophiuchii” — non abbastanza simile al nome vero perché Spansh la riconoscesse, quindi mai più aggiornata da anni.
Una riga doppia per lo stesso sistema (“Misir”), con due valori di Governo diversi tra loro — probabilmente il risultato di due inserimenti manuali in momenti diversi.
Un file __pycache__/edsm_fetcher.cpython-314.pyc finito nel repository per sbaglio in un commit precedente — rimosso, e __pycache__ aggiunto finalmente a .gitignore.

Il risultato

Il primo run completo con Spansh ha aggiunto 98 sistemi che mancavano del tutto dalla tabella e ha aggiornato popolazione, governo, alleanza e stato su gran parte delle righe esistenti. Lo script edsm_fetcher.py originale resta nel repository come fallback, per il giorno — se mai arriverà — in cui l’API di EDSM tornerà raggiungibile.

Niente di paragonabile, per portata, al lavoro fatto in questi giorni su questo sito. Ma è lo stesso tipo di soddisfazione: uno script che si era rotto in silenzio, un’alternativa scartata a ragion veduta, una sostituzione che funziona meglio dell’originale. Anche gestire una flotta virtuale di comandanti spaziali, alla fine, è una questione di infrastruttura da tenere in ordine.

Regole operative per la gestione dell’Infrastruttura IT: Il Black Cat Agreement

Thu, 26 Jan 2023 10:00:00 +0100

Regole operative per la gestione dell’Infrastruttura IT

Agreements

Non si effettuano attività sull’infrastruttura IT di produzione il Venerdì, il Sabato e la Domenica/Festivi (ed anche il Giovedì dopo le 16:00)
Prima di effettuare qualsiasi attività sull’infrastruttura IT di test o produzione va inviata una email a tutti i colleghi per informare dell’intervento, con almeno 24h di anticipo.
Il preavviso di 24h si può ridurre al minimo indispensabile in caso di attività da effettuare per risolvere problemi urgenti (la comunicazione va comunque inviata sempre).
Nel caso l’attività abbia un impatto sugli utenti, il preavviso sale ad almeno 72h per la comunicazione, che va inviata anche a tutti gli utenti coinvolti.
Per ciascuna attività va inviata a tutti i soggetti coinvolti (interni ed esterni) una email di inizio attività ed una email di fine attività.
Riunioni interne di allineamento che coinvolgono tutto il gruppo:
- Almeno una a settimana il Venerdì mattina.
- Non più di 3 a settimana.
- Durata MAX di ciascuna riunione 90 minuti
La gestione dei progetti prevede:
- La condivisione degli obiettivi e delle scadenze con la Direzione IT e con il gruppo di progetto, che prevede la presenza fissa dei responsabili delle varie BU interessate.
- L’approvazione del progetto da parte della Direzione IT, prima di iniziare a lavorare sul progetto stesso.
- La redazione della documentazione di progetto prima di iniziare il progetto.
- Che gli eventuali acquisti vanno sempre correlati ad un progetto approvato
Le decisioni prese in riunione possono essere modificate solo a seguito di una nuova riunione che allinei tutti i partecipanti.

Distribuire un aggiornamento di build di Windows 10 via Kace

Mon, 16 Dec 2019 11:30:00 +0100

Gli aggiornamenti di build di Windows 10 non sono patch tradizionali, rollup o service pack. Dal punto di vista della distribuzione, sono progettati e si comportano come un aggiornamento del sistema operativo “in-place”, cioè senza toccare alcun dato od impostazione preesistente, rimuovere la versione di SO precedente e senza salvare nessun dato. Pertanto richiedono maggiore pianificazione e test rispetto alle patch tradizionali, oltre a maggiori risorse (capacità del disco per server e client, larghezza di banda, tempo di installazione, ecc.).

NOTA: questa guida utilizza la versione 1903 di Ottobre 2019 come esempio di build nei passaggi seguenti

Prima fase: Creare il pacchetto di installazione
- Otteniamo una ISO ufficiale di Windows 10
- Montare la ISO e creare un file .zip
Seconda fase: Upload del pacchetto su KACE SMA
- Verifica dell’attivazione di Samba
- Caricamento dell’archivio nella clientdrop
Terza Fase: Mappare il pacchetto di installazione all’interno dell’Inventario
- Scenario Operativo
- Creazione di un Custom Software
Quarta Fase: Creazione e deploy del processo di aggiornamento
- Creazione della Managed Install
- Deploy

Prima fase: Creare il pacchetto di installazione

Gli aggiornamenti di build devono essere ottenuti direttamente da Microsoft. Sono distribuiti in formato ISO e devono essere estratti e ripacchettizzati per la distribuzione tramite prodotti di terze parti come KACE Systems Management Appliance.

Otteniamo una ISO ufficiale di Windows 10

Per ottenere la ISO di Windows 10 useremo uno quasiasi di questi tre metodi:

Scaricare la ISO dalla propria MSDN Library (richiede una licenza MSDN attiva), assicurandosi di ottenere la versione appropriata per il proprio scopo (es: Home, Professional, eccetera)
Usare il Media Creation Tool di Microsoft, scaricandolo da questo indirizzo: https://www.microsoft.com/en-us/software-download/windows10
1. Una volta scaricato, esegui il Tool
2. Quando ti viene richiesto cosa vuoi fare, scegli “Crea supporti di installazione (unità flash USB, DVD o file ISO) per un altro PC” e clicca Avanti
3. Verifica che le opzioni raccomandate (linuga, versione ed architettura) siano corrette in base alle tue necessità e prosegui
4. In “Scegli il supporto da usare” seleziona File ISO e clicca Avanti
5. Scegli un nome per il file (esempio: Windows10_1903_Italiano_x64.iso) e prosegui. Inizierà il download della ISO configurata così come hai deciso nelle opzioni precedenti
6. Clicca Fine al completamento per chiudere il wizard
Metodo Alternativo: Scaricare la ISO direttamente da https://www.microsoft.com/en-us/software-download/windows10ISO, visitando la URL con un computer non Windows (OS X o Linux)

Montare la ISO e creare un file .zip

In Windows 10, la ISO può essere montata facendo clic con il pulsante destro del mouse sul file e scegliendo “Monta” o semplicemente facendo doppio clic sul file ISO.
Assicurati di avere 7-Zip installato. 7-Zip è una condizione essenziale, quindi se non lo hai procuratelo da qui
Una volta montata, seleziona tutti i file all’interno della ISO (non la directory / unità, ma i file al suo interno), quindi fai clic con il pulsante destro del mouse e scegli “7-Zip > Aggiungi all’archivio…”
Nota: visto che la ISO è ovviamente read-only, scegli un percorso di salvataggio dello zip esterno, da qualche parte sul tuo hard disk
Al termine della compressione, il file zip verrà creato nella posizione selezionata con un nome generato automaticamente (esempio: setup.zip). Rinomina in modo appropriato (esempio: Windows10_1903_Italiano_x64.zip). Questo file verrà utilizzato nei seguenti passaggi
Smonta la ISO (fai clic con il pulsante destro del mouse sull’unità ed espelli) e fanne ciò che preferisci. Per questa guida non ne avremo più bisogno

Seconda fase: Upload del pacchetto su KACE SMA

Per via delle limitazioni sulla massima dimensione uploadabile di un file via interfaccia web, il pacchetto zip deve essere caricato su Kace tramite la condivisione samba clientdrop. La dimensione massima del file per il caricamento tramite l’interfaccia utente Web di SMA è infatti di 2GB (versione 8.0 e precedenti) o 4 GB (versione 8.1 e successive), mentre gli aggiornamenti di build tendono ad essere leggermente troppo grandi rispetto a questi limiti. Il metodo Samba evita del tutto il limite di upload e, opinione personale, è anche più veloce e pratico.

Verifica dell’attivazione di Samba

Se Samba non è abilitato, abilitalo (Samba può essere disabilitato dopo che il pacchetto è stato caricato e importato al passaggio 3). Le impostazioni di abilitazione / disabilitazione di Samba si trovano in Settings > Security Settings all’interno dell’interfaccia di Amministrazione. Per abilitare Samba, verifica che sia abilitato il checkbox “Enable organization file shares”
Assicurati anche che la condivisione sia abilitata anche a livello di organizzazione e di conoscere le credenziali per la share clientdrop. In caso contrario la password può essere reimpostata nella pagina Settings > General Settings nell’interfaccia utente di amministrazione (specifica dell’organizzazione per sistemi multi-org)

Caricamento dell’archivio nella clientdrop

Collegati alla share clientdrop. Puoi farlo facilmente aprendo un Esplora Risorse e digitando l’indirizzo UNC della tua appliance Kace (esempio: \\KBOX\clientdrop, sostituendo KBOX con il nome del tuo host SMA).
Trascina all’interno della clientdrop il file .zip creato nella Fase Uno
Concluso con successo il caricamento, passiamo allo Step 3

Terza Fase: Mappare il pacchetto di installazione all’interno dell’Inventario

Scenario Operativo

Per ragioni di performance, andremo a creare un Custom Software Title all’interno del Software Inventory, tralasciando invece il Software Catalog. Questa scelta è dovuta alla grande quantità di versioni e revisioni di Windows 10 all’interno del Catalog che andrebbero ad impattare fortemente sulle prestazioni del database di Kace ad ogni interrogazione dello stesso da parte della Managed Install che andremo a vedere verso la fine di questa guida.

Creeremo anche una apposita regola di inventario personalizzato (“Custom Inventory Rule”), in modo da avere un controllo più preciso e granulare sul processo di aggiornamento attuale e futuro.

Creazione di un Custom Software

Nell’interfaccia di amministraizone, vai su Inventory > Software
Dal menu Choose Action seleziona New
Compila i campi Name, Version, Publisher e Notes come preferisci. Ad esempio:
Nel campo Custom Inventory Rule inseriamo una regola che andrà a verificare una precisa chiave di registro, situata in HKLM\Software\Microsoft\Windows NT\CurrentVersion, per identificare la verisone della build.
Codice:
```
RegistryValueEquals(HKLM64\SOFTWARE\Microsoft\Windows NT\CurrentVersion,ReleaseId,1903)
```
Associamo finalmente il nostro file zip, creato in precendenza e copiato nella condivisione clientdrop, al Custom Software. Per far ciò andremo a scegliere dal menu a tendina Upload and Associate Client Drop File il file, salvando al termine.

Quarta Fase: Creazione e deploy del processo di aggiornamento

Ora che abbiamo tutti i pezzi del puzzle, dobbiamo solo unirli nel passaggio finale. Andremo a creare una Installazione Gestita (Managed Install) che avrà il compito di distrubire la nuova build di Windows 10 nei PC target.
Andremo a dettagliare i passaggi uno per uno ma chi avesse già esperienza con le Managed Install può saltare direttamente alla fine.

Creazione della Managed Install

Nel pannello di Amministrazione, vai in Distribution > Managed Installations
Seleziona Choose Action > **New
Digita un nome per la Managed Install, ad esempio “Windows 10 1903 Upgrade”
Imposta l’opzione di esecuzione desiderata in base ai tuoi requisiti. Se tieni il campo con valore “Disabled” la MI non verrà eseguita
In Inventory scegli Software
Nel menu a discesa Software, scegli il software title che hai creato nello Step 3 ed a cui hai associato lo zip
Verifica che sia selezionato Use associated file e che il fle mostrato sia il tuo zip
Se lo desideri (consigliato), seleziona Delete downloaded files
Installation Options:
1. Seleziona Override default installation ed inserisci questa stringa
  Codice:
```
  setup.exe /auto upgrade /DynamicUpdate disable /showoobe none
```
2. Verifica che sia spuntato il selettore Don’t prepend msiexec.exe
  - Nota: Puoi trovare una spiegazione esaustiva riguardo tutti i parametri di setup.exe tu technet di Microsoft, qui: https://blogs.technet.microsoft.com/home_is_where_i_lay_my_head/2015/09/14/windows-10-setup-command-line-switches/

Deploy

Nella sezione Deploy, assegna alla Managed Install le Labels che ritieni più opportune (è fortemente raccomandato eseguire uno o più test preliminari su un numero ristretto di computer)
Configura la sezione di Notifica, inserendo un messaggio chiaro e che rispecchi le tue necessità
Configura la Schedulazione, anche qui in base alle tue specifiche (Nota: non è consigliabile regolare la finestra di distribuzione, poiché le MIs vengono eseguite solo durante l’intervallo di inventario. Se la finestra è configurata in modo tale da non essere aperta abbastanza a lungo da consentire a tutti i sistemi di eseguire un intervallo di inventario, i sistemi interessati non riceveranno mai l’aggiornamento.)
Premi Save per completare il lavoro. Abbiamo finito, buon aggiornamento di build

(ricorda: PROVA SEMPRE PRIMA DI DISTRIBUIRE!!!)

Deploying a Windows 10 feature update via Kace

Mon, 16 Dec 2019 11:30:00 +0100

Windows 10 feature updates aren’t traditional patches, rollups or service packs. From a deployment standpoint, they’re designed and behave like an “in-place” OS upgrade — meaning they don’t touch any existing data or settings, remove the previous OS version, or save any data. Because of this, they require more planning and testing than traditional patches, along with more resources (disk space on both server and clients, bandwidth, installation time, and so on).

NOTE: this guide uses the October 2019 1903 build as an example throughout the following steps

First step: Create the installation package
- Get an official Windows 10 ISO
- Mount the ISO and create a .zip file
Second step: Upload the package to KACE SMA
- Check that Samba is enabled
- Upload the archive to clientdrop
Third step: Map the installation package inside Inventory
- Operational scenario
- Create a Custom Software title
Fourth step: Create and deploy the upgrade process
- Create the Managed Install
- Deploy

First step: Create the installation package

Feature updates must be obtained directly from Microsoft. They’re distributed as an ISO and need to be extracted and repackaged for deployment through third-party products like the KACE Systems Management Appliance.

Get an official Windows 10 ISO

To get the Windows 10 ISO we’ll use any one of these three methods:

Download the ISO from your own MSDN Library (requires an active MSDN license), making sure to grab the edition appropriate for your purpose (e.g. Home, Professional, etc.)
Use Microsoft’s Media Creation Tool, downloadable from this address: https://www.microsoft.com/en-us/software-download/windows10
1. Once downloaded, run the Tool
2. When asked what you want to do, choose “Create installation media (USB flash drive, DVD, or ISO file) for another PC” and click Next
3. Verify that the recommended options (language, edition, and architecture) match your needs and proceed
4. On “Choose which media to use”, select ISO file and click Next
5. Choose a name for the file (example: Windows10_1903_English_x64.iso) and continue. The download will start for the ISO configured with the options you chose above
6. Click Finish once it completes to close the wizard
Alternative method: download the ISO directly from https://www.microsoft.com/en-us/software-download/windows10ISO, visiting the URL from a non-Windows computer (macOS or Linux)

Mount the ISO and create a .zip file

On Windows 10, the ISO can be mounted by right-clicking the file and choosing “Mount”, or simply double-clicking the ISO file.
Make sure 7-Zip is installed. 7-Zip is a hard requirement, so if you don’t have it, grab it from here
Once mounted, select all the files inside the ISO (not the directory/drive itself, but the files inside it), then right-click and choose “7-Zip > Add to archive…”
Note: since the ISO is obviously read-only, choose an external save path for the zip, somewhere on your hard disk
Once compression finishes, the zip file will be created at the chosen location with an auto-generated name (example: setup.zip). Rename it appropriately (example: Windows10_1903_English_x64.zip). This file will be used in the following steps
Unmount the ISO (right-click the drive and eject) and do whatever you like with it — we won’t need it again for this guide

Second step: Upload the package to KACE SMA

Because of the limit on the maximum uploadable file size through the web interface, the zip package needs to be uploaded to Kace via the clientdrop Samba share. The maximum file size for upload through the SMA Web UI is in fact 2GB (version 8.0 and earlier) or 4GB (version 8.1 and later), while feature update packages tend to run slightly over these limits. The Samba method sidesteps the upload limit entirely and, in my opinion, is also faster and more convenient.

Check that Samba is enabled

If Samba isn’t enabled, enable it (Samba can be disabled again once the package has been uploaded and imported in step 3). The Samba enable/disable settings live under Settings > Security Settings in the Admin interface. To enable Samba, make sure the “Enable organization file shares” checkbox is checked
Also make sure the share is enabled at the organization level too, and that you know the credentials for the clientdrop share. If not, the password can be reset from the Settings > General Settings page in the Admin UI (organization-specific on multi-org systems)

Upload the archive to clientdrop

Connect to the clientdrop share. You can do this easily by opening File Explorer and typing the UNC address of your Kace appliance (example: \\KBOX\clientdrop, replacing KBOX with your SMA host’s name).
Drag the .zip file created in Step One into the clientdrop share
Once the upload completes successfully, move on to Step 3

Third step: Map the installation package inside Inventory

Operational scenario

For performance reasons, we’ll create a Custom Software Title inside the Software Inventory, rather than using the Software Catalog. This choice is due to the sheer number of Windows 10 versions and revisions in the Catalog, which would heavily impact Kace’s database performance on every query issued by the Managed Install we’ll set up toward the end of this guide.

We’ll also create a dedicated Custom Inventory Rule, to have more precise and granular control over the current and future upgrade process.

Create a Custom Software title

In the Admin interface, go to Inventory > Software
From the Choose Action menu, select New
Fill in the Name, Version, Publisher and Notes fields as you prefer. For example:
In the Custom Inventory Rule field, enter a rule that checks a specific registry key, located at HKLM\Software\Microsoft\Windows NT\CurrentVersion, to identify the build version.
Code:
```
RegistryValueEquals(HKLM64\SOFTWARE\Microsoft\Windows NT\CurrentVersion,ReleaseId,1903)
```
Finally, associate our zip file — created earlier and copied to the clientdrop share — with the Custom Software. To do this, choose the file from the Upload and Associate Client Drop File dropdown, then save.

Fourth step: Create and deploy the upgrade process

Now that we have all the pieces of the puzzle, we just need to put them together in this final step. We’ll create a Managed Install whose job will be to deploy the new Windows 10 build to the target PCs.
We’ll go through each step one by one, but if you’re already familiar with Managed Installs, feel free to skip straight to the end.

Create the Managed Install

In the Admin panel, go to Distribution > Managed Installations
Select Choose Action > New
Type a name for the Managed Install, for example “Windows 10 1903 Upgrade”
Set the desired run option based on your requirements. If you leave the field set to “Disabled” the MI won’t run
Under Inventory, choose Software
In the Software dropdown, choose the software title you created in Step 3 and associated the zip with
Verify that Use associated file is selected and that the file shown is your zip
If you’d like (recommended), select Delete downloaded files
Installation Options:
1. Select Override default installation and enter this string
  Code:
```
  setup.exe /auto upgrade /DynamicUpdate disable /showoobe none
```
2. Verify that the Don’t prepend msiexec.exe checkbox is checked
  - Note: You can find an exhaustive explanation of all setup.exe parameters on Microsoft’s technet, here: https://blogs.technet.microsoft.com/home_is_where_i_lay_my_head/2015/09/14/windows-10-setup-command-line-switches/

Deploy

In the Deploy section, assign the Labels you find most appropriate to the Managed Install (running one or more preliminary tests on a small number of computers is strongly recommended)
Configure the Notification section, entering a clear message that fits your needs
Configure the Schedule, again based on your specific needs (Note: adjusting the deployment window isn’t recommended, since MIs only run during the inventory interval. If the window is configured so that it isn’t open long enough for all systems to complete an inventory cycle, affected systems will never receive the update.)
Click Save to finish the job. That’s it, happy build upgrading!

(remember: ALWAYS TEST BEFORE DEPLOYING!!!)

IPUI to IPEI

Thu, 24 Jan 2019 12:30:00 +0100

Aggiornamento (agosto 2026): lo strumento è stato ricostruito da zero — via Bootstrap e jQuery, dentro Jekyll 4, ora bilingue italiano/inglese. Il link qui sotto resta lo stesso di sempre; ho raccontato il dietro le quinte del redesign in un nuovo post.

Talvolta (prendiamo ad esempio le installazioni aziendali) diventa necessario registrare sull’impianto DECT un telefono di produttore diverso da quello del centralino, vuoi per mancanza di disponibilità del prodotto voluto, vuoi per pure e semplici ragioni di budget (un cordless Siemes costa mediamente fra i 50 e i 70€, mentre un terminale ad esempio Spectralink o Avaya supera allegramente i 250€).

L’operazione è comunque veloce ed indolore per ogni tipo di terminale che supporti ovviamente lo standard DECT/GAP in quanto, come detto, è sufficiente l’IPEI del telefono che intendiamo registrare ed il gioco è fatto. Con Siemens, invece, ci servirà un passaggio in più, proprio per via della loro scelta di utilizzare IPUI, che ha una diversa notazione ed una diversa struttura e non viene quindi riconosciuto come IPEI valido.

Cosa è il codice IPEI?
- Come convertire il codice IPEI in IPUI?
Ipui2Ipei: strumento di conversione da IPUI a IPEI
Informazioni aggiuntive
- Come trovare il codice IPUI di un telefono SIEMENS?
- Note ulteriori
Riferimenti

Cosa è il codice IPEI?

L’IPEI è un codice numerico di identificazione, simile al codice IMEI dei telefoni cellulari, dei telefoni DECT/GAP (i cosiddetti “telefoni cordless”).

IPEI è un codice numerico di 13 caratteri
IPUI è un codice alfanumerico di 10 caratteri

Come convertire il codice IPEI in IPUI?

La conversione consiste nella divisione di IPUI in due parti separate, con conseguente trasformazione dei due valori esadecimanli in decimali e qualche altro calcolo più o meno divertente. Oppure, molto più semplicemente, si può utilizzare un tool di conversione come quello indicato di seguito.

Ipui2Ipei: strumento di conversione da IPUI a IPEI

Al questo link è possibile trovare ipui2ipei, un tool web che ho trovato su GitHub e che ho poi provveduto a modificare e migliorare (si spera) secondo le mie esigenze.

Il suo utilizzo è semplicissimo: è sufficiente scrivere nel primo campo il codice IPUI estratto dal telefono Siemens seguendo la procedura indicata successivamente e premere il bottone Converti.

Un attimo dopo avrete il risultato desiderato, con tanto di spiegazione sul tipo di calcoli che sono stati eseguiti.

Informazioni aggiuntive

Come trovare il codice IPUI di un telefono SIEMENS?

col portatile in stand-by, bisogna premere la seguente sequenza di tasti: Tasto MENU’ seguito da [*] [#] 0 6 [#]

Note ulteriori

Il codice IPEI è composto da 13 caratteri: i primi 12 sono il codice vero e proprio, mentre il tredicesimo è un carattere di controllo.
A seconda del produttore del vostro centralino o server DECT dovrete inserirli tutti o solo i primi 12.
La conversione potrebbe portare ad un risultato con quattordici numeri in quanto il codice di controllo può essere un qualsiasi numero compreso fra 1 e 10. In questo caso trasfromate il 10 in “asterisco” [*]

Riferimenti

Come importare un certificato CA su PC Windows con Kace 1000

Mon, 17 Sep 2018 11:30:00 +0200

Per installare certificati in maniera trasparente possiamo usare diversi metodi, il più ovvio e diffuso dei quali è senza dubbio una GPO. Ma non è sempre detto che la GPO sia la soluzione più veloce (ad esempio: chi deve eseguire il deploy dei certificati non ha i permessi per lavorare sulle GPO, o il certificato deve essere installato su un numero esiguo di PC per cui chi dovrebbe fare la GPO non considera questa un’attività primaria da svolgere ed i tempi rischiano di allungarsi)

Andiamo quindi a vedere come distribuire un certificato CA self-signed tramite KACE 1000. In seguito andremo anche ad installare sui client, con la stessa procedura, un secondo certificato intermedio, validato a sua volta dalla CA.

L’utility certutil.exe
Lo script (kscript) su Kace

L’utility certutil.exe

certutil.exe è una utility, presente in tutti i sistemi Windows, che ci permette di fare tante cose con i certificati. Possiamo convertirli in caso il formato che abbiamo non sia quello che ci serve, possiamo importarli ed esportarli (sia in locale che su Active Directory), verificare la validità delle coppie di chiavi privata/pubblica eccetera.

Si usa da riga di comando e per la sintassi completa vi rimando all’apposita pagina sulla Knowledge Base Micorosoft

Definizioni

Entrambi i nostri certificati sono già in formato .cer
Il certificato CA si chiama NGIRootCA01
Il certificato intermedio si chiama NGISSLCA01.cer

Importazione della CA tramite certutil.exe

Il comando di importazione, che possiamo eseguire da un qualsiasi prompt amministrativo, è il seguente

start /wait certutil -addstore Root NGIRootCA01.cer

Il parametro -addstore deifnisce il datastore in cui andremo ad installare il certificato. Root corrisponde a “Autorità di certificazione radice attendibili”

Importazione del certificato intermedio

Il certificato intermedio (che chiameremo SSLCA01.cer) a cui si faceva riferimento poco fa si importerà nella stessa maniera, cambiando solamente il datastore di riferimento:

start /wait certutil -addstore CA NGISSLCA01.cer

Lo script (kscript) su Kace

Andiamo ora a riportare tutto su Kace 1000, creando uno script apposito.

Riassunto delle Attività

Impostazione dei parametri di base
Importazione dei due certificati come dipendenze
Creazione di un batch file
Schedulazione

Realizzazione

Portiamoci in Scripting / Scripts e creiamo un novo kscript (“New”)
Una volta definito un nome, portiamoci nella sezione Operating Systems e clicchiamo su Manage Operating Systems, andando a selezionare tutti i SO Windows (e, visto che andremo a creare un batch file, solo quelli Windows) di nostro interesse
Verifichiamo che Windows Run As sia impostato a Local System
Nella sezione Dependencies facciamo click su +New Dependency… e carichiamo:
1. Il certificato Root
2. Il certificato Intermedio
Facciamo ora click su +Task… nella sezione sottostante ed impostiamo i seguenti passi:
1. Verify that the file “C:\Tools\certificato.ok” exists (questo ci servirà per fare un check sull’applicazione del certificato, che andremo a schedulare e qundi ad eseguire ad intervalli regolari; se il file certificato.ok esiste allora lo script si interrompe). Per riferimento sul percorso scelto, potete vedere questo mio precedente articolo
2. On Success: nulla
3. Remediation: Run the batch file “Install_CA_Root_Script” with params “”
  
  Codice:
```
 @echo off
 start /wait certutil -addstore Root NGIRootCA01.cer
 start /wait certutil -addstore CA NGISSLCA01.cer
 exit
```
4. On Remediaton Success Launch a program…
Clicchiamo su Save per completare la creazione del kscript

Schedulazione

In caso volessimo schedulare lo script, sarà sufficiente, una volta tornati in editing, andare ad impostare la finestra desiderata. Ad esempio, nel nostro caso lo script verrà eseguito sui devices desiderati ogni tre ore secondo questa logica:

Lo script viene eseguito la prima volta
Al termine, lascia un file “certificato.ok”, di dimensione 0 bytes, in C:\Tools\
Dalla volta seguente (ogni tre ore…) se trova il file “certificato.ok” allora si interrompe e non fa null’altro

How to import a CA certificate on Windows PCs with Kace 1000

Mon, 17 Sep 2018 11:30:00 +0200

There are several methods for installing certificates transparently, the most obvious and common of which is undoubtedly a GPO. But a GPO isn’t always the fastest solution (for example: whoever needs to deploy the certificates might not have permissions to work on GPOs, or the certificate might only need to be installed on a handful of PCs, so whoever should create the GPO doesn’t treat it as a priority and the timeline risks stretching out)

So let’s see how to deploy a self-signed CA certificate via KACE 1000. Afterwards, using the same procedure, we’ll also install a second, intermediate certificate on the clients, itself validated by the CA.

The certutil.exe utility
The kscript on Kace

The certutil.exe utility

certutil.exe is a utility, present on every Windows system, that lets us do a lot of things with certificates. We can convert them if the format we have isn’t the one we need, import and export them (both locally and to Active Directory), verify the validity of private/public key pairs, and so on.

It’s used from the command line, and for the full syntax I’ll point you to the dedicated page on the Microsoft Knowledge Base

Definitions

Both of our certificates are already in .cer format
The CA certificate is called NGIRootCA01
The intermediate certificate is called NGISSLCA01.cer

Importing the CA via certutil.exe

The import command, which we can run from any administrative prompt, is the following

start /wait certutil -addstore Root NGIRootCA01.cer

The -addstore parameter defines the datastore where we’ll install the certificate. Root corresponds to “Trusted Root Certification Authorities”

Importing the intermediate certificate

The intermediate certificate (which we’ll call SSLCA01.cer) referenced earlier is imported the same way, only changing the target datastore:

start /wait certutil -addstore CA NGISSLCA01.cer

The kscript on Kace

Now let’s bring all of this over to Kace 1000, by creating a dedicated script.

Task summary

Setting up the basic parameters
Importing the two certificates as dependencies
Creating a batch file
Scheduling

Building it

Go to Scripting / Scripts and create a new kscript (“New”)
Once you’ve given it a name, go to the Operating Systems section and click Manage Operating Systems, selecting all the Windows OSs (and, since we’re going to create a batch file, only the Windows ones) you’re interested in
Verify that Windows Run As is set to Local System
In the Dependencies section, click +New Dependency… and upload:
1. The Root certificate
2. The Intermediate certificate
Now click +Task… in the section below and set up the following steps:
1. Verify that the file “C:\Tools\certificato.ok” exists (this will let us check whether the certificate has already been applied — since we’ll schedule this script to run at regular intervals, if the certificato.ok file exists the script stops right there). For reference on why this path was chosen, see this earlier article of mine
2. On Success: nothing
3. Remediation: Run the batch file “Install_CA_Root_Script” with params “”
  
  Code:
```
 @echo off
 start /wait certutil -addstore Root NGIRootCA01.cer
 start /wait certutil -addstore CA NGISSLCA01.cer
 exit
```
4. On Remediation Success Launch a program…
Click Save to finish creating the kscript

Scheduling

If we want to schedule the script, once back in editing mode it’s enough to set the desired window. For example, in our case the script will run on the target devices every three hours, following this logic:

The script runs for the first time
When it finishes, it leaves a “certificato.ok” file, 0 bytes in size, in C:\Tools\
From the next run onward (every three hours…) if it finds the “certificato.ok” file, it stops and does nothing else

Blocco delle applicazioni con K1000

Wed, 11 Jul 2018 00:00:00 +0200

In questa veloce guida si dà per scontato che il lettore abbia già una buona conoscenza dell’ambiente KACE 1000 (KACE SMA) e del funzionamento delle etichette (Labels)

Il blocco delle applicazioni tramite K1000, passo per passo
Il risultato finale

Il blocco delle applicazioni tramite K1000, passo per passo

Il blocco delle applicazioni su Kace funziona con una doppia logica:

Una Label, in grado di controllare e bloccare i software
Uno o più Software marcati come Not Allowed

Per funzionare, è necessario che entrambe le condizioni siano vere

La Label

Kace mette a disposizione una Label già preconfezionata, secondo i parametri di default.

Useremo quindi questa per illustrare il funzionamento del blocco applicativo.

Portarsi in Home ed in seguito in Label Management e selezionare Labels
La nostra etichetta di default si chiama “ApplicationControlDevices” ed è così impostata:

Significato della Label

Illustriamo velocemente il significato dei vari flag:

Device Inventory: La Label si applica all’Inventario dei devices (quindi: ai PC)
- Allow Application Control: La Label è in grado di controllare l’avvio delle applicazioni
Resources (Processes, Services, Startup Items): La Label si può applicare anche a processi e servizi
Catalog: La Label si applica al Catalogo Software (essenziale per il buon funzionamento del meccanismo di blocco!)
Software: Come sopra, ma per i software non normalizzati dal catalogo

I software da bloccare

Portiamoci nel Software Catalog (Inventory -> Software Catalog), che racchiude e “normalizza” tutti i software rilevati e riconosciuti, all’interno di un unico nome. Più chiaramente, avremo ad esempio “iTunes 12.x”, che contiene tutte le revisioni di iTunes 12 (es: 12.1, 12.4, 12.74 e via dicendo).

Lavorare nel Catalogo Software ci consente di bloccare o monitorare un software indipendentemente dagli aggiornamenti che riceve.

Una volta trovato il nostro software (prendiamo sempre ad esempio iTunes 12.x), selezioniamo il checkbox e da menu “Choose Action” scegliamo “Mark Not Allowed”

In alternativa, è possibile spuntare “Not Allowed” all’interno della pagina del software di nostro interesse. L’autosave è automatico nel momento del cambio di selezione del checkbox.

I PC e la loro Label

Ora che abbiamo capito come funzionano sia la Label (che si applica ai PC) che il marker di blocco (relativo ai software), possiamo metterli insieme ed ottenere l’effetto desiderato.

NOTA BENE: il meccanismo di Kace bloccherà l’apertura dei programmi SOLO sui PC a cui abbiamo applicato la Label “ApplicationControlDevice” e solo a loro. In questa fase sperimentale l’etichetta NON VIENE applicata di default a tutti i device in inventario e l’operazione dovrà quindi essere fatta manualmente.

Un pc che ha un software bloccato ma che non appartiene alla Label continuerà ad eseguire quel software come se nulla fosse, senza alcun problema.

1 Otteniamo il nome od i nomi dei PC che ci interessa inserire nella Label. Per fare ciò abbiamo diverse strade, tutte corrette:
1. Lo conosciamo e lo troviamo direttamente in Inventario
2. Dal Catalogo Software clicchiamo sul numero nella colonna “Installed”, che ci porterà alla lista di tutti i PC con quel software

2 Selezioniamo il checkbox a fianco del o dei PC di nostro interesse e da menu “Choose Action” facciamo click su “Apply Labels”

3 Scegliamo quindi la Label “ApplicationControlDevices” e trasciniamola nella parte destra della finestra, cliccando poi su “Apply Labels”

L’Inventario

Abbiamo fatto le regole. Abbiamo applicato le Labels. Manca ancora qualcosa?

Uno dei punti di forza dell’agente Kace è quello di lavorare sostanzialmente offline: si collega una volta al server, riceve tutte le regole, le informazioni e gli script e poi continua a lavorare, da solo, senza più bisogno di dialogare col server. E continua a fare tutto ciò che gli è stato detto di fare fino a prova contraria. Questo meccanismo si chiama “Inventario” e nel nostro caso viene eseguito una volta ogni 8 ore (almeno) da ogni singolo computer inventariato.

Le nuove regole di blocco, quindi, verranno applicate al PC al suo prossimo contatto (cioè al prossimo inventario). Le potremo forzare manualmente (click sul box del device e poi “Force Inventory”) ma, in condizioni normali, il frutto delle nostre regole si vedrà solo dopo alcune ore (ed un riavvio del PC) e non in tempo reale.

Il risultato finale

In seguito alla creazione della lista di blocco (alcuni software in questa immagine sono solo puramente a scopo di esempio e non si intende veramente bloccarli), all’assegnazione della Label al PC ed al propagarsi delle regole tramite inventario, una volta che l’utente tenterà di aprire il software riceverà un alert nell’angolo basso a destra dello schermo, come questo:

Application Control with K1000

Wed, 11 Jul 2018 00:00:00 +0200

This quick guide assumes the reader already has a good understanding of the KACE 1000 (KACE SMA) environment and of how Labels work

Application control with K1000, step by step
The end result

Application control with K1000, step by step

Application control on Kace works with a two-part logic:

A Label, able to control and block software
One or more Software titles marked as Not Allowed

For it to work, both conditions must be true

The Label

Kace ships with a Label already pre-configured, using default parameters.

We’ll use this one to walk through how application control works.

Go to Home, then to Label Management, and select Labels
Our default label is called “ApplicationControlDevices” and is configured like this:

What the Label means

Let’s quickly go over what each flag means:

Device Inventory: The Label applies to the device Inventory (i.e. PCs)
- Allow Application Control: The Label is able to control the launching of applications
Resources (Processes, Services, Startup Items): The Label can also be applied to processes and services
Catalog: The Label applies to the Software Catalog (essential for the blocking mechanism to work properly!)
Software: Same as above, but for software not normalized by the catalog

The software to block

Let’s head to the Software Catalog (Inventory -> Software Catalog), which groups and “normalizes” all detected and recognized software under a single name. To be clearer, we’ll have for example “iTunes 12.x”, which covers every revision of iTunes 12 (e.g. 12.1, 12.4, 12.74, and so on).

Working from the Software Catalog lets us block or monitor a piece of software regardless of the updates it receives.

Once we’ve found our software (let’s keep using iTunes 12.x as an example), select the checkbox and from the “Choose Action” menu pick “Mark Not Allowed”

Alternatively, you can check “Not Allowed” directly on the software’s own detail page. Autosave kicks in as soon as you change the checkbox selection.

The PCs and their Label

Now that we understand how both the Label (which applies to PCs) and the block marker (which applies to software) work, we can put them together to get the effect we want.

NOTE: Kace’s mechanism will only block programs from opening on PCs that have the “ApplicationControlDevice” Label applied — and only on those. During this experimental phase, the label is NOT applied by default to every inventoried device, so this has to be done manually.

A PC that has a blocked piece of software but doesn’t belong to the Label will keep running that software as if nothing happened, with no issues at all.

1 Get the name(s) of the PC(s) you want to add to the Label. There are several ways to do this, all equally valid:
1. You already know it and can find it directly in Inventory
2. From the Software Catalog, click the number in the “Installed” column, which will take you to the list of all PCs with that software

2 Check the checkbox next to the PC(s) you’re interested in and from the “Choose Action” menu click “Apply Labels”

3 Choose the “ApplicationControlDevices” Label and drag it into the right-hand side of the window, then click “Apply Labels”

Inventory

We’ve made the rules. We’ve applied the Labels. Is anything still missing?

One of the strengths of the Kace agent is that it works essentially offline: it connects to the server once, receives all the rules, information, and scripts, and then keeps working on its own, without needing to talk to the server again. And it keeps doing everything it’s been told to do until told otherwise. This mechanism is called “Inventory”, and in our case it runs once every 8 hours (at minimum) on every single inventoried computer.

New blocking rules, then, will be applied to the PC the next time it checks in (i.e. at its next inventory). We can force this manually (click the device’s box, then “Force Inventory”), but under normal conditions the results of our rules will only show up after a few hours (and a PC restart), not in real time.

The end result

Once the blocklist has been created (some software titles in this image are purely for illustration purposes and aren’t actually meant to be blocked), the Label assigned to the PC, and the rules propagated through inventory, once the user tries to open the software they’ll get an alert in the bottom-right corner of the screen, like this one:

Come bloccare l'hotlinking delle immagini con .htaccess

Fri, 13 Apr 2018 00:00:00 +0200

L’hotlinking danneggia il tuo sito
Come proteggersi da hotlinking
- Spiegazione
  - Concedere l’accesso a Bing, Yahoo e Facebook
- Conclusioni

L’hotlinking danneggia il tuo sito

Facciamo un esempio. L’immagine che vedete qui sotto è stata caricata direttamente su un mio sito (ospite originale di questo articolo). Il server web non fa altro che andare a caricare una risorsa interna (l’immagine stessa) e mostrarla al visitatore, senza alcun carico elaborativo extra.

Il codice dell’immagine è il seguente:

<img src="/wp-content/uploads/2012/05/kenny-mccormick.jpg" alt="" border="0" width="320" height="240" />

Un sito esterno, invece di effettuare il download dell’immagine e di caricarla sul proprio server (cosa che, oltretutto, è sempre consigliabile in quanto migliora moltissimo i tempi di caricamento e le prestazioni generali del sito), ottiene il collegamento diretto alla risorsa e lo include all’interno di una propria pagina.

<img src="https://www.skyflash.it/wp-content/uploads/2012/05/kenny-mccormick.jpg" alt="" border="0" width="320" height="240" />

Il risultato sarà che il secondo sito, eterno al nostro, sfrutta l’immagine senza però sacrificare il proprio spazio web, mentre il nostro sito, su cui risiede l’immagine, sarà sottoposto ad un carico eccessivo (ed assolutamente non richiesto nè tanto meno gradito) sia per quanto riguarda la propria banda passante che per le risorse del server.

Come proteggersi da hotlinking

Sono sufficienti alcune righe da aggiungere al proprio, immancabile, file .htaccess e, se volete, un’immagine preparata per lo scopo, che servirà per sbattere in faccia al webmaster antipatico la dura verità :smile:

ATTENZIONE: la modifica di .htaccess, se fatta da persone non esperte e non particolarmente attente, può generare molti problemi al vostro sito WordPress, fino a renderlo inaccessibile. Assicuratevi quindi di fare SEMPRE una copia di sicurezza di .htaccess prima di cominciare le modifiche

Aprite in un qualsaisi editor di testo il vostro file .htaccess ed in coda (se usate WordPress, dovrebbero esserci solo le direttive di default) e dopo ### END WordPress ### aggiungete il seguente codice:

### Blocca l'hotlinking - Webmaster cattivo pussa via
RewriteEngineon
RewriteCond%{HTTP_REFERER}!^$
RewriteCond%{HTTP_REFERER}!^http(s)?://(www\.)?skyflash.it[NC]
RewriteCond%{HTTP_REFERER}!^http(s)?://(www\.)?google.com[NC]
RewriteCond%{HTTP_USER_AGENT}!googlebot[NC]
RewriteCond%{REQUEST_URI}!^hotlink.jpg$
RewriteRule\.(jpg|jpeg|png|gif|js|swf)$hotlink.jpg[NC,R,L]

Spiegazione

Alla terza riga trovate:

RewriteCond%{HTTP_REFERER}!^$

Questa istruzione consente ai referrer che non forniscono informazioni di accedere al contenuto. Ciò è reso necessario in quanto molti visitatori (soprattutto quelli che si connettono dall’ufficio e si trovano dietro a proxy) sono protetti da un firewall che non rilascia informazioni al server per ragioni di sicurezza.

Righe 4, 5 e 6:

RewriteCond%{HTTP_REFERER}!^http(s)?://(www\.)?skyflash.it[NC]
RewriteCond%{HTTP_REFERER}!^http(s)?://(www\.)?google.com[NC]
RewriteCond%{HTTP_USER_AGENT}!googlebot[NC]

specificano i domini che invece possono effettuare l’hotlinking e quindi visualizzare le immagini presenti sul server. Quindi scriveremo il nostro dominio internet e, in caso vogliate farvi indicizzare le immagini, Google. Tutti gli altri sono fuori.

Riga 7:

RewriteCond%{REQUEST_URI}!^hotlink.jpg$

Se proprio qualcuno vuole rubare qualche immagine, allora lasciamogli prendere quella che abbiamo preparato per segnalare gli hotlinker. Questa riga ci assicura che l’immagine sia sempre visualizzabile.

Riga 8:

RewriteRule\.(jpg|jpeg|png|gif|js|swf)$hotlink.jpg[NC,R,L]

Specifica il formato dei file protetti dall’hotlinking (non solo le immagini ne sono soggette) e sostituisce le richieste con un’immagine statica.

Ovviamente potrete specificare l’immagine che desiderate, ma assicuratevi che questa non sia protetta (vedi riga precedente) oppure, ancora meglio, caricatela su una risorsa esterna come Dropbox, o il risultato sarà un loop infinito!

Concedere l’accesso a Bing, Yahoo e Facebook

Esattamente come abbiamo fatto per Google, aggiungiamo al nostro .htaccess le seguenti direttive:

RewriteCond%{HTTP_REFERER}!msn.[NC]
RewriteCond%{HTTP_REFERER}!yahoo.[NC]
RewriteCond%{HTTP_REFERER}!^https?://(www\.)?facebook\.com[NC]
RewriteCond%{HTTP_USER_AGENT}!facebookplatform[NC]
RewriteCond%{HTTP_USER_AGENT}!msnbot[NC]
RewriteCond${HTTP_USER_AGENT}!slurp[NC]

Conclusioni

Il risultato finale sarà quindi il seguente:

### Blocca l'hotlinking - Webmaster cattivo pussa via

RewriteEngineon
RewriteCond%{HTTP_REFERER}!^$
RewriteCond%{HTTP_REFERER}!^http(s)?://(www\.)?skyflash.it[NC]
RewriteCond%{HTTP_REFERER}!^http(s)?://(www\.)?google.com[NC]
RewriteCond%{HTTP_REFERER}!msn.[NC]
RewriteCond%{HTTP_REFERER}!yahoo.[NC]
RewriteCond%{HTTP_REFERER}!^https?://(www\.)?facebook\.com[NC]
RewriteCond%{HTTP_USER_AGENT}!googlebot[NC]
RewriteCond%{HTTP_USER_AGENT}!facebookplatform[NC]
RewriteCond%{HTTP_USER_AGENT}!msnbot[NC]
RewriteCond${HTTP_USER_AGENT}!slurp[NC]
RewriteCond%{REQUEST_URI}!^hotlink.jpg$
RewriteRule\.(jpg|jpeg|png|gif|js|swf)$hotlink.jpg[NC,R,L]

Chi dovesse linkare ad una risorsa con estensione jpg, jpeg, png, gif, js o swf sul sito così “trattato”, come unico risultato avrà la visualizzazione della seguente immagine

Se guardando le statistiche del vostro spazio web avete notato un consumo eccessivo di banda in uscita o se state rilevando una grande quantità di accessi esterni alle stesse immagini, probabilmente siete hotlinkati da qualcuno. Ora sapete come difendervi.

Risorse esterne:

La traduzione in italiano di Morrowind, Tribunal e Bloodmoon

Thu, 05 Apr 2018 00:00:00 +0200

Il 2002, ludicamente parlando, verrà ricordato per l’uscita dell’attesissimo terzo capitolo della saga The Elder Scrolls.

La Traduzione di Morrowind: Un po’ di storia
Si comincia a tradurre!
I primi problemi…
La quest aggiuntiva
La traduzione in Italiano di Morrowind - Download
Morrowind ITP - Staff

La Traduzione di Morrowind: Un po’ di storia

Atteso dai fan di mezzo mondo, il lancio Italiano di The Elder Scrolls 3: Morrowind destò molte polemiche. Il gioco infatti, inspiegabilmente, non venne tradotto in nessuna sua parte. Ricordo ancora le parole di un P.R. Ubisoft, il quale dichiarò, più o meno, che la traduzione non era stata fatta per motivi di tempo. In pratica, ci disse che non lo avevano tradotto perchè altrimenti ci sarebbe stato un pesante ritardo nella distribuzione, e che quindi avevano preso questa decisione per fare un favore a noi giocatori. Che avesse forse dinanzi un roseo futuro da umorista? O forse da politico? Fatto sta che Morrowind venne distribuito in rigorosa lingua Inglese. Il CRPG che avrebbe rivoluzionato il genere, il gioco con la più grande mole di testi mai realizzato, sarebbe stato di difficile comprensione per molti giocatori Italiani.

Qualche mese prima della sua uscita nel nostro mercato, io ed altri appassionati ci eravamo già procurati la versione USA del gioco (per quanto mi riguarda, fu la Collector’s Edition), scoprendo così le fantastiche potenzialità dell’editor integrato. Tramite il TES Construction Set era possibile realizzare praticamente di tutto; si potevano creare nuovi oggetti, nuove quest, nuovi NPC. Si poteva addirittura realizzare un plugin che cambiasse ogni singola parola del gioco. Come? Era possibile cambiare i testi a video? Allora era anche possibile tradurre Morrowind!

Si comincia a tradurre!

Quasi per gioco, iniziai a tradurre il tutorial e le prime fasi di gioco. In quegli anni uno dei miei contatti era Lello Sarti, responsabile della testata online RPGPlayer.it, poi assorbita da Multiplayer. Lello era a sua volta in contatti con alcuni membri dell’ITP, a cui riferì che io avevo iniziato a tradurre il gioco. Il prossimo passo fu ovvio: stava per prendere il via la traduzione in Italiano più lunga e complessa mai realizzata a livello amatoriale!

Proprio su questo stesso dominio istituimmo una mailing list con cui tenerci in contatto, e creai anche un piccolo forum (utilizzando lo storico Snitz! forum, un ormai obsoleto forum in .ASP). Nel frattempo il gioco era già uscito in Italia e, come c’era da immaginarsi, venne accolto con molta timidezza, proprio a causa della sua gigantesca mole di testo in Inglese. Non ci volle molto perchè la voce secondo cui l’ITP, già noto per il meraviglioso lavoro svolto con Planescape: Torment, si era messo al lavoro su Morrowind si diffondesse. Nel giro di alcuni mesi si parlava di noi su Usenet, sui forum, e persino su qualche rivista.

I primi problemi…

L’opera di traduzione stava procedendo bene, quando ci rendemmo conto di una cosa: la particolare struttura del Journal – il Diario – di Morrowind era basata sul linguaggio HTML, ed alcuni termini erano veri e propri hyperlinks che riconducevano ad altre sezioni, le quali erano a loro volta collegate con altre ancora. Non aver verificato quali fossero questi particolari termini (indicati col prefisso @, es: @elves) significava una sola cosa: era tutto da rifare!

Per nostra grande fortuna, uno dei componenti il team era un buon programmatore e riuscì a realizzare un software il cui compito era quello di analizzare il Journal ed estrarre tutti i termini ‘speciali’. Questo comportò ovviamente un ritardo sui tempi, ma ci permise di non buttare tutto quanto fino a quel momento realizzato, limitandoci a ricontrollare solo le parti indicate dal nostro programma specifico.

I mesi passavano ed il lavoro proseguiva. Le richieste da parte degli utenti fioccavano da più parti, tutti impazienti di poter finalmente giocare a Morrowind senza essere costretti a tenere un vocabolario sulle gambe. Ci fu anche qualche problema con Ubisoft, il publisher, di cui non vi parlerò neppure sotto tortura perchè sono comunque argomenti riservati.

La quest aggiuntiva

Ci mancava ancora qualcosa, però. In fin dei conti si stava lavorando sul TES, e si stava realizzando un plugin, no? E allora, perchè non distribuire nello stesso pacchetto anche una quest aggiuntiva, la quale avrebbe ricompensato il giocatore con un libro il cui contenuto si riferiva a “Coloro i quali fecero l’impresa”? In quel libro avremmo riportato una breve ‘Bio’ di ciascuno di noi, con uno stile ovviamente conforme all’ambientazione di gioco. Dopo tanto lavoro, un minimo di auto referenzialità mi pare dovuta, no?

Purtroppo, a causa di mancanza di tempo, io fui costretto a sospendere la mia collaborazione con l’ITP anzitempo, ma questo non comportò alcun problema per i ragazzi, che non mi stancherò mai di ringraziare per avermi comunque incluso sia fra i ringraziamenti nelle note di rilascio che nella quest aggiuntiva, malgrado la mia defezione anticipata.

Ebbene, se siete arrivati fin qui a leggere e state cercando disperatamente la traduzione di Morrowind, direi che è giunto il momento di ricompensarvi per il tempo dedicato ai miei ricordi.

La traduzione in Italiano di Morrowind - Download

Questa è la versione definitiva della traduzione, che non necessita di preventivi aggiornamenti del gioco. Si basa sull’edizione Game of the Year di Morrowind e contiene sia la traduzione del gioco base che della sua espansione “vampiresca”, BloodMoon. E’ un unico file auto installante che, se necessario, aggiornerà la vostra copia di The Elder Scrolls III: Morrowind alla più recente versione 1.6

Si consiglia di non applicare la traduzione ad una partita già in corso; ciò potrebbe corrompere i salvataggi. E’ comunque possibile “trattare” i propri salvataggi con il programma Savepatcher, distribuito nell’archivio Tribunal.zip

Installare la traduzione di Tribunal solo dopo aver installato il file precedente, relativo alle traduzioni di Morrowind e Bloodmoon

Articolo originariamente pubblicato sullo Skyblog nel 2010.

Morrowind ITP - Staff

Responsabile del gruppo

Daniele ‘Falcocadarn’ Falcone

Responsabili della traduzione

Daniele ‘Falcocadarn’ Falcone
Anahid ‘Misty’ Mazkedian
Maurizio ‘Dester’ Focareta

Responsabile tecnico

Maurizio ‘Dester’ Focareta

Traduttori ITP - Morrowind

Daniele ‘Falcocadarn’ Falcone
Anahid ‘Misty’ Mazkedian
Maurizio ‘Dester’ Focareta
Erica ‘Crysania’ Masserano
Elena ‘Rowena’ Ricci
Jacopo ‘Jacoposki’ Sacerdote
Paolo ‘Judas’ De Sandre
Lorenzo ‘il Somax’ Soma
Luca ‘Darkness’ Liberati
Fabio ‘Gimli81’ Poli
Leonardo ‘Spaziotempo6’ Picchi
Paolo “Tasslehoff” Regonesi
Cristian ‘Skyflash’ Castellari
Francesco ‘Hammer’ Penta

Un sentito grazie al nostro ‘padre spirituale’ Lello ‘wolverine’ Sarti, a Davide ‘Magi System’ Martelli per il supporto web e a Gianluca ‘Eldar’ Barca per l’aiuto nella realizzazione della statua.

Traduttori ITP - Tribunal

Daniele ‘Falcocadarn’ Falcone
Anahid ‘Misty’ Mazkedian
Maurizio ‘Dester’ Focareta
Erica ‘Crysania’ Masserano
Elena ‘Rowena’ Ricci
Jacopo ‘Jacoposki’ Sacerdote
Paolo ‘Judas’ De Sandre
Lorenzo ‘il Somax’ Soma
Michele “Medioman” Lai Chin
Luca ‘Darkness’ Liberati

Un sentito grazie al nostro ‘padre spirituale’ Lello ‘wolverine’ Sarti, a Davide ‘Magi System’ Martelli per il supporto web, a Luca “Fusion” Piombino per il largo aiuto durante lo sviluppo del programma di conversione dei salvataggi, a Jim Adam per le informazioni tratte dal suo sito sul formato dei file di Morrowind, e a Tanilo e Pec dalle terre del Canada per la compagnia “telematica” e per un buon numero di aiuti tecnici.

[K1000 Scripting] Find and report all PCs with a smartcard reader installed

Wed, 14 Feb 2018 00:00:00 +0100

Target

Find and report all managed Windows PCs in K1000 Inventory with a smartcard reader installed.

Overview

The script does not depend on K1000, so if you don’t have KACE SMA in your environment don’t worry: the script is still useful!

Components

[The Query] This script
[The Automation] Kace Systems Management Appliance (AKA ‘K1000’)

How it works

The vbs script executes a WMI query over the target device(s) and saves an output file named smartcard.txt (see below in the Setup section)
The vbs script is scheduled and deployed to the target device(s) via K1000 Online KScript
A K1000 Custom Inventory Rule reads the output file for every inventoried device and stores the information in the database
A scheduled Report (choose your favorite format between HTML, CSV, PDF or Excel) returns only PCs with a smart card reader installed
Done!

Setup

The KScript (smarcard.vbs)

Download the script or copy & paste the following code:

strComputer = "."
Dim log
Set log = Wscript.CreateObject("Scripting.Filesystemobject")
Set f = log.CreateTextFile("C:\Tools\smartcard.txt", 2)
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2") 
Set colItems = objWMIService.ExecQuery( _
    "SELECT * FROM Win32_PnPSignedDriver Where DeviceClass = 'SMARTCARDREADER'",,48) 
For Each objItem in colItems 
    f.WriteLine "DeviceClass: " & objItem.DeviceClass
Next
f.Close

Edit line 4 with the path where you want to save the output file. In our environment every PC has a “C:\Tools” directory for service purpose, so I decided to save the output there.

Set f = log.CreateTextFile("C:\Tools\smartcard.txt", 2)

Go to your K1000 Dashboard, then go to Scripting and create a New Script (Choose Action / New)
Name the script as your wish (for example: Check Smart Card Reader) and follow these steps:

Script Basic Settings

Type: Online KScript
Enabled: Yes
Deploy: one or some devices, all devices or to a Device Label, according to your needs in your environment
Windows Run As: Local System
Upload the smartcard.vbs as New Dependecy

Tasks

We want the script to run once in every PC, so we’ll use a “checkmark” (the smartcard.txt) to verify that…

Verify: Verify a file exists…
- C:\Tools\smartcard.txt
Remediation: Launch a program…
- Directory: $(KACE_SYS_DIR)
- File: cscript.exe $(KACE_DEPENDENCY_DIR)\smartcard.vbs
- Wait for completion: Yes
On Remediation Success: Upload a file… (note: this step is not necessary and only for archiving purpose)
- Directory: C:\Tools
- File: smartcard.txt

…and Save your brand new script.

The Task and its steps are summarized in the following image. When you’re ready, let’s jump to the Step 4!

The Custom Inventory Rule

In the K100 Dashboard, now go to Inventory section, then go to Software and create a new Software entry (Choose Action / New)
Name the rule as your wish (for example: IT Dep — Check Smart Card Reader) and follow these steps:

Publisher: IT Department (it’s useful for further searches into the Software Inventory)
Supported Operating Systems: All the Windows OSs in your Inventory
Custom Inventory Rule: ShellCommandTextReturn(cmd /c type C:\Tools\smartcard.txt)

…and Save your new Custom Inventory Rule.

Here’s the summary image

Now we need all our devices complete their inventory. The new Custom Inventory Rule creates a new entry in every device record managed by the K1000.

If a smart card reader has been discovered we’ll have at least one “DeviceClass: SMARTCARDREADER” text iside the Custom Inventory Fields section into every device record in Inventory / Devices

Otherwise, if a smart card reader has not been discovered, we’ll have no text

When all your devices has been inventoried and you’re ready, jump to the next section

The Report

In the K100 Dashboard, now go to Reporting section, then in Reports and create a new Report (Choose Action / New)

Name the Report as your wish (for example: PCs with Smart Card Reader) and follow these steps:

Title and Topic

Category: Inventory
Topic: Device

Fields to Display

Device: System Name
Operating System Info: Name
User Information: User Name
Manufacturer and BIOS: System Model

Feel free to add and modify any other field, according to your needings.

Filters

Delete the default filter and create this:

Save your new report and try it.

[K1000 Scripting] Find and report all PCs with a smartcard reader installed

Wed, 14 Feb 2018 00:00:00 +0100

Target

Find and report all managed Windows PCs in K1000 Inventory with a smartcard reader installed.

Overview

The script does not depend on K1000, so if you don’t have KACE SMA in your environment don’t worry: the script is still useful!

Components

[The Query] This script
[The Automation] Kace Systems Management Appliance (AKA ‘K1000’)

How it works

The vbs script executes a WMI query over the target device(s) and saves an output file named smartcard.txt (see below in the Setup section)
The vbs script is scheduled and deployed to the target device(s) via K1000 Online KScript
A K1000 Custom Inventory Rule reads the output file for every inventoried device and stores the information in the database
A scheduled Report (choose your favorite format between HTML, CSV, PDF or Excel) returns only PCs with a smart card reader installed
Done!

Setup

The KScript (smarcard.vbs)

Download the script or copy & paste the following code:

strComputer = "."
Dim log
Set log = Wscript.CreateObject("Scripting.Filesystemobject")
Set f = log.CreateTextFile("C:\Tools\smartcard.txt", 2)
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2") 
Set colItems = objWMIService.ExecQuery( _
    "SELECT * FROM Win32_PnPSignedDriver Where DeviceClass = 'SMARTCARDREADER'",,48) 
For Each objItem in colItems 
    f.WriteLine "DeviceClass: " & objItem.DeviceClass
Next
f.Close

Edit line 4 with the path where you want to save the output file. In our environment every PC has a “C:\Tools” directory for service purpose, so I decided to save the output there.

Set f = log.CreateTextFile("C:\Tools\smartcard.txt", 2)

Go to your K1000 Dashboard, then go to Scripting and create a New Script (Choose Action / New)
Name the script as your wish (for example: Check Smart Card Reader) and follow these steps:

Script Basic Settings

Type: Online KScript
Enabled: Yes
Deploy: one or some devices, all devices or to a Device Label, according to your needs in your environment
Windows Run As: Local System
Upload the smartcard.vbs as New Dependecy

Tasks

We want the script to run once in every PC, so we’ll use a “checkmark” (the smartcard.txt) to verify that…

Verify: Verify a file exists…
- C:\Tools\smartcard.txt
Remediation: Launch a program…
- Directory: $(KACE_SYS_DIR)
- File: cscript.exe $(KACE_DEPENDENCY_DIR)\smartcard.vbs
- Wait for completion: Yes
On Remediation Success: Upload a file… (note: this step is not necessary and only for archiving purpose)
- Directory: C:\Tools
- File: smartcard.txt

…and Save your brand new script.

The Task and its steps are summarized in the following image. When you’re ready, let’s jump to the Step 4!

The Custom Inventory Rule

In the K100 Dashboard, now go to Inventory section, then go to Software and create a new Software entry (Choose Action / New)
Name the rule as your wish (for example: IT Dep — Check Smart Card Reader) and follow these steps:

Publisher: IT Department (it’s useful for further searches into the Software Inventory)
Supported Operating Systems: All the Windows OSs in your Inventory
Custom Inventory Rule: ShellCommandTextReturn(cmd /c type C:\Tools\smartcard.txt)

…and Save your new Custom Inventory Rule.

Here’s the summary image

Now we need all our devices complete their inventory. The new Custom Inventory Rule creates a new entry in every device record managed by the K1000.

Otherwise, if a smart card reader has not been discovered, we’ll have no text

When all your devices has been inventoried and you’re ready, jump to the next section

The Report

In the K100 Dashboard, now go to Reporting section, then in Reports and create a new Report (Choose Action / New)

Name the Report as your wish (for example: PCs with Smart Card Reader) and follow these steps:

Title and Topic

Category: Inventory
Topic: Device

Fields to Display

Device: System Name
Operating System Info: Name
User Information: User Name
Manufacturer and BIOS: System Model

Feel free to add and modify any other field, according to your needings.

Filters

Delete the default filter and create this:

Save your new report and try it.

Identificare e terminare processi zombie su Linux

Sun, 25 Oct 2015 00:00:00 +0200

Recentemente ho avuto necessità di eseguire un pò di tuning su un server Linux, spesso infestato da processi zombie che lo portavano a raggiungere elevatissimi carichi operativi. Dalla descrizione di Wikipedia:

Nei sistemi operativi Unix e Unix-like, un processo zombie o processo defunto è un processo informatico che, nonostante abbia terminato la propria esecuzione, possiede ancora un PID ed un process control block, necessario per permettere al proprio processo padre di leggerne il valore di uscita.

Girovagando alla ricerca di informazioni utili, mi sono imbattuto in un ottimo script, da copiare sui vostri server, in grado di identificare e killare lo zombie, oltre a lasciarne una traccia un un file di log apposito.

Lo script kill-zombie
- Funzionamento
- Inserimento nel crontab

Lo script kill-zombie

Come prima cosa, creeremo (con i permessi di root) un nuovo file kill-zombie

cd /root
vi kill-zombies

In seguito copiamo il seguente codice ed incolliamolo nel file appena creato

#! /bin/bash
#
# Zombie processes killing script. Must be run under root.
 
case "$1" in
--admin)
stat=`ps ax | awk '{print $1}' | grep -v "PID" | xargs -n 1 ps lOp | grep -v "UID" | awk '{print"pid: "$3" *** parent_pid: "$4" *** status: "$10" *** process: "$13}' | grep ": Z"`
 
if ((${#stat} > 0));then
echo zombie processes found:
echo .
ps ax | awk '{print $1}' | grep -v "PID" | xargs -n 1 ps lOp | grep -v "UID" | awk '{print"pid: "$3" *** parent_pid: "$4" *** status: "$10" *** process: "$13}' | grep ": Z"
echo -n "Kill zombies? [y/n]: "
read keyb
if [ $keyb == 'y' ];then
echo killing zombies..
ps ax | awk '{print $1}' | grep -v "PID" | xargs -n 1 ps lOp | grep -v "UID" | awk '{print$4" status:"$10}' | grep "status:Z" | awk '{print $1}' | xargs -n 1 kill -9
fi
else
echo no zombies found!
fi
;;
--cron)
stat=`ps ax | awk '{print $1}' | grep -v "PID" | xargs -n 1 ps lOp | grep -v "UID" | awk '{print"pid: "$3" *** parent_pid: "$4" *** status: "$10" *** process: "$13}' | grep ": Z"`
if ((${#stat} > 0));then
ps ax | awk '{print $1}' | grep -v "PID" | xargs -n 1 ps lOp | grep -v "UID" | awk '{print$4" status:"$10}' | grep "status:Z" | awk '{print $1}' | xargs -n 1 kill -9
echo `date`": killed some zombie processes!" >> /var/log/zombies.log
fi
;;
*) echo 'usage: kill-zombies {--cron|--admin}'
;;
esac
exit 0

Ora rendiamolo eseguibile e spostiamolo in /usr/bin

chmod +x kill-zombies
mv kill-zombies /usr/bin

Funzionamento

Lo script viene evocato con un flag, che ne modifica il comportamento:

kill-zombies --admin

L’esecuzione avviene manualmente. Se vengono rilevati processi zombie l’utente ne viene informato e deve confermare l’operazione

kill-zombies --cron

Lo script dovrà essere inserito nel crontab e richiamato quindi a cadenze regolari dal server. I processi vengono killati in automatico e ne viene lasciata traccia in /var/log/zombies.log

Inserimento nel crontab

Richiamiamo l’editor del crontab con questo comando

crontab -e

Ed inseriamo questa riga:

*/10 * * * * /usr/bin/kill-zombies --cron

In questo modo, lo script verrà eseguito ogni 10 minuti a cadenza regolare. In caso si voglia modificare l’intervallo di tempo, sarà sufficiente cambiare ad esempio */10 in */5 (per 5 minuti)

Download kill-zombies.sh

Riferimenti:

CronHowTo

Backup automatizzato dei database su SQL Express

Thu, 24 May 2012 17:03:37 +0200

SQL Server Express viene distribuito senza SQL Agent, quindi non è possibile schedulare internamente a SQL Server processi automatizzati, come ad esempio il backup. E’ però possibile aggirare questo ostacolo creando uno script ad-hoc, che si occupi dei vari job che vogliamo eseguire.

In questo articolo vedremo come creare uno script per il backup di SQL Express e, subito dopo, uno per la manutenzione dei backup, il cui compito sarà quello di tenere sempre le tre copie più recenti, cancellando di volta in volta quelli più vecchi.

Tutto il lavoro verrà svolto all’interno della cartella C:\SQL_Backup e delle due sotto cartelle scripts e Logs, che dovranno quindi essere create preventivamente.

Alla fine dell’articolo trovate i tre script già pronti da scaricare, con la stessa struttura di cartelle descritta qui sopra.

Lo script per il backup di SQL Express
Cancellazione dei backup vecchi
I file di log
Esecuzione
Schedulazione
Aggiornamento (2026): la versione moderna con PowerShell
Download

Lo script per il backup di SQL Express

Portiamoci all’interno di C:\SQL_Backup\scripts e creiamo un file che chiameremo backupDB.sql con questo contenuto:

DECLARE @dateString CHAR(12), @dayStr CHAR(2), @monthStr CHAR(2), @hourStr CHAR(2), @minStr CHAR(2)
--month variable
IF (SELECT LEN(CAST(MONTH(GETDATE()) AS CHAR(2))))=2
SET @monthSTR=CAST(MONTH(GETDATE()) AS CHAR(2))
ELSE
SET @monthSTR= '0' + CAST(MONTH(GETDATE()) AS CHAR(2))
--day variable
IF (SELECT LEN(CAST(DAY(GETDATE()) AS CHAR(2))))=2
SET @daySTR=CAST(DAY(GETDATE()) AS CHAR(2))
ELSE
SET @daySTR='0' + CAST(DAY(GETDATE()) AS CHAR(2))
--hour variable
IF (SELECT LEN(DATEPART(hh, GETDATE())))=2
SET @hourStr=CAST(DATEPART(hh, GETDATE()) AS CHAR(2))
ELSE
SET @hourStr= '0' + CAST(DATEPART(hh, GETDATE()) AS CHAR(2))
--minute variable
IF (SELECT LEN(DATEPART(mi, GETDATE())))=2
SET @minStr=CAST(DATEPART(mi, GETDATE()) AS CHAR(2))
ELSE
SET @minStr= '0' + CAST(DATEPART(mi, GETDATE()) AS CHAR(2))
--name variable based on time stamp
SET @dateString=CAST(YEAR(GETDATE()) AS CHAR(4)) + @monthStr + @dayStr + @hourStr + @minStr
--=================================================================
DECLARE @IDENT INT, @sql VARCHAR(1000), @DBNAME VARCHAR(200)
SELECT @IDENT=MIN(database_id) FROM SYS.DATABASES WHERE [database_id] > 0 AND NAME NOT IN ('TEMPDB')
WHILE @IDENT IS NOT NULL
BEGIN
SELECT @DBNAME = NAME FROM SYS.DATABASES WHERE database_id = @IDENT
/*Change disk location here as required*/
SELECT @SQL = 'BACKUP DATABASE '+@DBNAME+' TO DISK = ''C:\SQL_Backup\'+@DBNAME+'_db_' + @dateString +'.BAK'' WITH INIT'
EXEC (@SQL)
SELECT @IDENT=MIN(database_id) FROM SYS.DATABASES WHERE [database_id] > 0 AND database_id>@IDENT AND NAME NOT IN ('TEMPDB')
END

Lo script andrà a creare tanti backup quanti sono i database all’interno di SQL Express, ed aggiungerà una sorta di “timestamp” alla fine del nome, in modo da identificarli nel tempo, prima di terminare con l’estensione .BAK.

Cancellazione dei backup vecchi

Sempre all’interno di C:\SQL_Backup\scripts creiamo un file deleteoldsqlbaks.vbs in cui scriveremo:

On Error Resume Next
Dim fso, folder, files, sFolder, sFolderTarget
Set fso = CreateObject("Scripting.FileSystemObject")

'location of the database backup files
sFolder = "C:\SQL_Backup\"

Set folder = fso.GetFolder(sFolder)
Set files = folder.Files

'used for writing to textfile - generate report on database backups deleted
Const ForAppending = 8

'you need to create a folder named "scripts" for ease of file management &
'a file inside it named "LOG.txt" for delete activity logging
Set objFile = fso.OpenTextFile(sFolder & "\Logs\cleanuplog.txt", ForAppending)

objFile.Write "================================================================" & VBCRLF & VBCRLF
objFile.Write " DATABASE BACKUP FILE REPORT " & VBCRLF
objFile.Write " DATE: " & FormatDateTime(Now(),1) & "" & VBCRLF
objFile.Write " TIME: " & FormatDateTime(Now(),3) & "" & VBCRLF & VBCRLF
objFile.Write "================================================================" & VBCRLF

'iterate thru each of the files in the database backup folder
For Each itemFiles In files
'retrieve complete path of file for the DeleteFile method and to extract
'file extension using the GetExtensionName method
a=sFolder & itemFiles.Name

'retrieve file extension
b = fso.GetExtensionName(a)
'check if the file extension is BAK
If uCase(b)="BAK" Then

'check if the database backups are older than 3 days
If DateDiff("d",itemFiles.DateCreated,Now()) >= 3 Then

'Delete any old BACKUP files to cleanup folder
fso.DeleteFile a
objFile.WriteLine "BACKUP FILE DELETED: " & a
End If
End If
Next

objFile.WriteLine "================================================================" & VBCRLF & VBCRLF

objFile.Close

Set objFile = Nothing
Set fso = Nothing
Set folder = Nothing
Set files = Nothing

Il compito di questo script sarà quello di posizionarsi nella cartella in cui abbiamo salvato i backup, “contare” i backup presenti e tenere i tre più recenti, cancellando gli altri. Inoltre, scrive un log delle operazioni eseguite.

I file di log

Portiamoci in C:\SQL_Backup\Logs e creiamo due file vuoti, che chiameremo backuplog.txt e cleanuplog.txt

Esecuzione

Creiamo il file databasebackup.cmd

@echo off
REM Lancio il backup e scrivo il log
sqlcmd -S SERVER\SQLEXPRESS -E -i C:\SQL_Backup\scripts\backupDB.sql -o C:\SQL_Backup\Logs\backuplog.txt

REM Lancio lo script di pulizia e aggiorno cleanuplog.txt
C:\SQL_Backup\scripts\deleteoldsqlbaks.vbs

L’unica modifica da fare sarà l’inserimento del nome e della istanza del vostro server, sostituendo SERVER\SQLEXPRESS con i vostri dati corretti (presumibilmente, l’istanza si chiama sempre SQLEXPRESS ma cambia il nome del server)

Schedulazione

Non resta che creare una Operazione pianificata dal Pannello di controllo di Windows, il cui semplice compito consisterà nell’esecuzione di C:\SQL_Backup\scripts\databasebackup.cmd, impostando un orario ed una ricorrenza secondo le proprie necessità.

Aggiornamento (2026): la versione moderna con PowerShell

A 14 anni di distanza, l’approccio di fondo (uno script esterno più un’operazione pianificata, visto che SQL Express non ha mai guadagnato SQL Agent) resta valido, e lo script backupDB.sql funziona ancora così com’è. Quello che è invecchiato è il resto della catena: Microsoft ha avviato la deprecazione di VBScript, con rimozione pianificata da Windows nelle prossime versioni, quindi non ha più senso scrivere nuovo codice che ci si appoggia.

Al posto di deleteoldsqlbaks.vbs e databasebackup.cmd basta un unico script PowerShell, che richiama backupDB.sql tramite sqlcmd (nessuna dipendenza aggiuntiva da installare) e si occupa della pulizia mantenendo solo le ultime copie più recenti per ciascun database, invece del semplice “cancella tutto ciò che ha più di 3 giorni” dello script originale:

# backup.ps1 - versione moderna, sostituisce deleteoldsqlbaks.vbs + databasebackup.cmd
# Richiede solo sqlcmd (incluso in SQL Server / SQL Server Express, oppure
# installabile a parte tramite gli "SQL Server Command Line Utilities")

$SqlInstance = "SERVER\SQLEXPRESS"
$BackupPath  = "C:\SQL_Backup"
$KeepCopies  = 3

# 1. Backup: richiama lo script T-SQL backupDB.sql, invariato
sqlcmd -S $SqlInstance -E -i "$BackupPath\scripts\backupDB.sql" -o "$BackupPath\Logs\backuplog.txt"

# 2. Pulizia: tiene solo le ultime $KeepCopies copie per ciascun database
Get-ChildItem -Path $BackupPath -Filter "*.BAK" |
    Group-Object { $_.Name -replace '_db_\d{12}\.BAK$', '' } |
    ForEach-Object {
        $_.Group | Sort-Object LastWriteTime -Descending | Select-Object -Skip $KeepCopies
    } |
    ForEach-Object {
        Remove-Item $_.FullName -Force
        "$(Get-Date -Format s)  BACKUP FILE DELETED: $($_.FullName)" | Add-Content "$BackupPath\Logs\cleanuplog.txt"
    }

Nell’Operazione pianificata, l’azione da eseguire diventa quindi powershell.exe -ExecutionPolicy Bypass -File C:\SQL_Backup\scripts\backup.ps1 al posto del vecchio databasebackup.cmd.

Download

backupDB.sql
backup.ps1 — versione consigliata (2026)
deleteoldsqlbaks.vbs — script originale del 2012
databasebackup.cmd — script originale del 2012

Via	mssqltips.com

Automated SQL Express database backups

Thu, 24 May 2012 17:03:37 +0200

SQL Server Express ships without SQL Agent, so it isn’t possible to schedule automated processes — like backups — from within SQL Server itself. It is however possible to work around this by creating an ad-hoc script that takes care of the various jobs we want to run.

In this article we’ll see how to create a script to back up SQL Express and, right after, one to maintain the backups, whose job will be to always keep the three most recent copies, deleting the older ones as we go.

All the work will happen inside the C:\SQL_Backup folder and its two subfolders scripts and Logs, which need to be created beforehand.

At the end of the article you’ll find all three scripts ready to download, following the same folder structure described above.

The SQL Express backup script
Deleting old backups
The log files
Running it
Scheduling
Update (2026): the modern PowerShell version
Download

The SQL Express backup script

Let’s go into C:\SQL_Backup\scripts and create a file called backupDB.sql with this content:

DECLARE @dateString CHAR(12), @dayStr CHAR(2), @monthStr CHAR(2), @hourStr CHAR(2), @minStr CHAR(2)
--month variable
IF (SELECT LEN(CAST(MONTH(GETDATE()) AS CHAR(2))))=2
SET @monthSTR=CAST(MONTH(GETDATE()) AS CHAR(2))
ELSE
SET @monthSTR= '0' + CAST(MONTH(GETDATE()) AS CHAR(2))
--day variable
IF (SELECT LEN(CAST(DAY(GETDATE()) AS CHAR(2))))=2
SET @daySTR=CAST(DAY(GETDATE()) AS CHAR(2))
ELSE
SET @daySTR='0' + CAST(DAY(GETDATE()) AS CHAR(2))
--hour variable
IF (SELECT LEN(DATEPART(hh, GETDATE())))=2
SET @hourStr=CAST(DATEPART(hh, GETDATE()) AS CHAR(2))
ELSE
SET @hourStr= '0' + CAST(DATEPART(hh, GETDATE()) AS CHAR(2))
--minute variable
IF (SELECT LEN(DATEPART(mi, GETDATE())))=2
SET @minStr=CAST(DATEPART(mi, GETDATE()) AS CHAR(2))
ELSE
SET @minStr= '0' + CAST(DATEPART(mi, GETDATE()) AS CHAR(2))
--name variable based on time stamp
SET @dateString=CAST(YEAR(GETDATE()) AS CHAR(4)) + @monthStr + @dayStr + @hourStr + @minStr
--=================================================================
DECLARE @IDENT INT, @sql VARCHAR(1000), @DBNAME VARCHAR(200)
SELECT @IDENT=MIN(database_id) FROM SYS.DATABASES WHERE [database_id] > 0 AND NAME NOT IN ('TEMPDB')
WHILE @IDENT IS NOT NULL
BEGIN
SELECT @DBNAME = NAME FROM SYS.DATABASES WHERE database_id = @IDENT
/*Change disk location here as required*/
SELECT @SQL = 'BACKUP DATABASE '+@DBNAME+' TO DISK = ''C:\SQL_Backup\'+@DBNAME+'_db_' + @dateString +'.BAK'' WITH INIT'
EXEC (@SQL)
SELECT @IDENT=MIN(database_id) FROM SYS.DATABASES WHERE [database_id] > 0 AND database_id>@IDENT AND NAME NOT IN ('TEMPDB')
END

The script will create one backup for each database inside SQL Express, appending a kind of “timestamp” to the end of the name to identify them over time, before finishing with the .BAK extension.

Deleting old backups

Still inside C:\SQL_Backup\scripts, let’s create a file deleteoldsqlbaks.vbs containing:

On Error Resume Next
Dim fso, folder, files, sFolder, sFolderTarget
Set fso = CreateObject("Scripting.FileSystemObject")

'location of the database backup files
sFolder = "C:\SQL_Backup\"

Set folder = fso.GetFolder(sFolder)
Set files = folder.Files

'used for writing to textfile - generate report on database backups deleted
Const ForAppending = 8

'you need to create a folder named "scripts" for ease of file management &
'a file inside it named "LOG.txt" for delete activity logging
Set objFile = fso.OpenTextFile(sFolder & "\Logs\cleanuplog.txt", ForAppending)

objFile.Write "================================================================" & VBCRLF & VBCRLF
objFile.Write " DATABASE BACKUP FILE REPORT " & VBCRLF
objFile.Write " DATE: " & FormatDateTime(Now(),1) & "" & VBCRLF
objFile.Write " TIME: " & FormatDateTime(Now(),3) & "" & VBCRLF & VBCRLF
objFile.Write "================================================================" & VBCRLF

'iterate thru each of the files in the database backup folder
For Each itemFiles In files
'retrieve complete path of file for the DeleteFile method and to extract
'file extension using the GetExtensionName method
a=sFolder & itemFiles.Name

'retrieve file extension
b = fso.GetExtensionName(a)
'check if the file extension is BAK
If uCase(b)="BAK" Then

'check if the database backups are older than 3 days
If DateDiff("d",itemFiles.DateCreated,Now()) >= 3 Then

'Delete any old BACKUP files to cleanup folder
fso.DeleteFile a
objFile.WriteLine "BACKUP FILE DELETED: " & a
End If
End If
Next

objFile.WriteLine "================================================================" & VBCRLF & VBCRLF

objFile.Close

Set objFile = Nothing
Set fso = Nothing
Set folder = Nothing
Set files = Nothing

This script’s job is to go into the folder where we’ve saved the backups, “count” the backups present, and keep the three most recent, deleting the rest. It also writes a log of the operations it performs.

The log files

Let’s go into C:\SQL_Backup\Logs and create two empty files, which we’ll call backuplog.txt and cleanuplog.txt

Running it

Let’s create the databasebackup.cmd file

@echo off
REM Run the backup and write the log
sqlcmd -S SERVER\SQLEXPRESS -E -i C:\SQL_Backup\scripts\backupDB.sql -o C:\SQL_Backup\Logs\backuplog.txt

REM Run the cleanup script and update cleanuplog.txt
C:\SQL_Backup\scripts\deleteoldsqlbaks.vbs

The only change needed is entering your server’s name and instance, replacing SERVER\SQLEXPRESS with your own values (presumably the instance is always called SQLEXPRESS, but the server name changes)

Scheduling

All that’s left is to create a Scheduled Task from the Windows Control Panel, whose only job will be to run C:\SQL_Backup\scripts\databasebackup.cmd, setting a time and recurrence to fit your needs.

Update (2026): the modern PowerShell version

14 years on, the underlying approach (an external script plus a scheduled task, since SQL Express never gained SQL Agent) still holds up, and the backupDB.sql script still works exactly as it is. What’s aged is the rest of the chain: Microsoft has started deprecating VBScript, with planned removal from Windows in upcoming versions, so it no longer makes sense to write new code that depends on it.

Instead of deleteoldsqlbaks.vbs and databasebackup.cmd, a single PowerShell script is enough — it calls backupDB.sql via sqlcmd (no extra dependency to install) and handles cleanup by keeping only the most recent copies per database, instead of the original script’s simple “delete anything older than 3 days”:

# backup.ps1 - modern version, replaces deleteoldsqlbaks.vbs + databasebackup.cmd
# Only requires sqlcmd (included with SQL Server / SQL Server Express, or
# installable separately via the "SQL Server Command Line Utilities")

$SqlInstance = "SERVER\SQLEXPRESS"
$BackupPath  = "C:\SQL_Backup"
$KeepCopies  = 3

# 1. Backup: calls the T-SQL script backupDB.sql, unchanged
sqlcmd -S $SqlInstance -E -i "$BackupPath\scripts\backupDB.sql" -o "$BackupPath\Logs\backuplog.txt"

# 2. Cleanup: keeps only the latest $KeepCopies copies per database
Get-ChildItem -Path $BackupPath -Filter "*.BAK" |
    Group-Object { $_.Name -replace '_db_\d{12}\.BAK$', '' } |
    ForEach-Object {
        $_.Group | Sort-Object LastWriteTime -Descending | Select-Object -Skip $KeepCopies
    } |
    ForEach-Object {
        Remove-Item $_.FullName -Force
        "$(Get-Date -Format s)  BACKUP FILE DELETED: $($_.FullName)" | Add-Content "$BackupPath\Logs\cleanuplog.txt"
    }

In the Scheduled Task, the action to run becomes powershell.exe -ExecutionPolicy Bypass -File C:\SQL_Backup\scripts\backup.ps1 instead of the old databasebackup.cmd.

Download

backupDB.sql
backup.ps1 — recommended version (2026)
deleteoldsqlbaks.vbs — original 2012 script
databasebackup.cmd — original 2012 script

Via	mssqltips.com

Come proteggere un sito dagli attacchi - Parte 2 - Il file .htaccess

Tue, 08 May 2012 16:05:48 +0200

Ieri abbiamo illustrato un ottimo e “furbo” metodo per ingabbiare i bad crawlers. La tecnica della “trappola” illustrata è molto efficiente, ma potrebbe non bastare a garantire una protezione di alto livello. Esistono infatti anche bot maligni il cui scopo principale non è quello di effettuare il download indiscriminato di un intero sito web, ma che vanno alla ricerca di exploit, di falle di sicurezza e che magari tentano di eseguire script e simili.

In questi casi, diventa di fondamentale importanza dotarsi di un file .htaccess customizzato quel tanto che serve a bloccare la stragrande maggioranza degli attacchi. Negli ultimi giorni ho provato diverse modifiche al mio .htaccess e ritengo di aver trovato, grazie all’ottimo blog Perishable Press, quella che ritengo una delle migliori soluzioni possibili.

Inoltre, particolare non di poco conto per quanto mi riguarda, l’autore della blacklist ha un blog basato su WordPress e ne testa personalmente il funzionamento proprio su quella piattaforma, garantendone in pratica il funzionamento.

.htaccess 5G Blacklist 2012
Cosa fa la Blacklist
Come si usa
Alcune note

.htaccess 5G Blacklist 2012

L’autore è giunto al quinto rilascio della sua blacklist, che prende quindi il nome attuale di “5G”. E’ già in fase avanzata di sviluppo la futura versione 6G, che comprenderà ulteriori modifiche derivate dai suggerimenti degli utenti e dalla propria esperienza

Cosa fa la Blacklist

La 5G è un set semplice e flessibile di direttive .htaccess che verificano tutte le richieste verso il web server e si occupano delle eventuali contromisure immediate, senza appesantire il carico del web server stesso, permettendoci quindi di risparmiare una grande quantità di banda e di risorse.

Come si usa

Installare la blacklist è relativamente semplice. Sarà sufficiente aggiungere il codice necessario in fondo al proprio file .htaccess

Attenzione: la modifica di .htaccess, se fatta da persone non esperte e non particolarmente attente, può generare molti problemi al vostro sito WordPress, fino a renderlo inaccessibile. Assicuratevi quindi di fare sempre una copia di sicurezza di .htaccess prima di cominciare le modifiche

Aprite il vostro file .htaccess ed in coda (se usate WordPress, dovrebbero esserci solo le direttive di default) e dopo ### END WordPress ### aggiungete il seguente codice:

# 5G BLACKLIST/FIREWALL
# @ http://perishablepress.com/5g-blacklist/

# 5G:[QUERY STRINGS]

RewriteEngine On
RewriteBase /
RewriteCond %{QUERY_STRING} (environ|localhost|mosconfig|scanner) [NC,OR]
RewriteCond %{QUERY_STRING} (menu|mod|path|tag)\=\.?/? [NC,OR]
RewriteCond %{QUERY_STRING} boot\.ini [NC,OR]
RewriteCond %{QUERY_STRING} echo.*kae [NC,OR]
RewriteCond %{QUERY_STRING} etc/passwd [NC,OR]
RewriteCond %{QUERY_STRING} \=\\%27$ [NC,OR]
RewriteCond %{QUERY_STRING} \=\\\'$ [NC,OR]
RewriteCond %{QUERY_STRING} \.\./ [NC,OR]
RewriteCond %{QUERY_STRING} \? [NC,OR]
RewriteCond %{QUERY_STRING} \: [NC,OR]
RewriteCond %{QUERY_STRING} \[ [NC,OR]
RewriteCond %{QUERY_STRING} \] [NC]
RewriteRule .* - [F]

# 5G:[USER AGENTS]

SetEnvIfNoCase User-Agent ^$ keep_out
SetEnvIfNoCase User-Agent (casper|cmsworldmap|diavol|dotbot) keep_out
SetEnvIfNoCase User-Agent (flicky|ia_archiver|jakarta|kmccrew) keep_out
SetEnvIfNoCase User-Agent (libwww|planetwork|pycurl|skygrid) keep_out
SetEnvIfNoCase User-Agent (purebot|comodo|feedfinder|turnit) keep_out
SetEnvIfNoCase User-Agent (zmeu|nutch|vikspider|binlar|sucker) keep_out

Order Allow,Deny
Allow from all
Deny from env=keep_out

# 5G:[REQUEST STRINGS]

RedirectMatch 403 (https?|ftp|php)\://
RedirectMatch 403 /(cgi|https?|ima|ucp)/
RedirectMatch 403 /(Permanent|Better)$
RedirectMatch 403 (\=\\\'|\=\\%27|/\\\'/?|\)\.css\()$
RedirectMatch 403 (\,|//|\)\+|/\,/|\{0\}|\(/\(|\.\.\.|\+\+\+|\||\\\"\\\")
RedirectMatch 403 \.(cgi|asp|aspx|cfg|dll|exe|jsp|mdb|sql|ini|rar)$
RedirectMatch 403 /(contac|fpw|install|pingserver|register)\.php$
RedirectMatch 403 (base64|crossdomain|localhost|wwwroot|e107\_)
RedirectMatch 403 (eval\(|\_vti\_|\(null\)|echo.*kae|config\.xml)
RedirectMatch 403 \.well\-known/host\-meta
RedirectMatch 403 /function\.array\-rand
RedirectMatch 403 \)\;\$\(this\)\.html\(
RedirectMatch 403 proc/self/environ
RedirectMatch 403 msnbot\.htm\)\.\_
RedirectMatch 403 /ref\.outcontrol
RedirectMatch 403 com\_cropimage
RedirectMatch 403 indonesia\.htm
RedirectMatch 403 \{\$itemURL\}
RedirectMatch 403 function\(\)
RedirectMatch 403 labels\.rdf
RedirectMatch 403 /playing.php
RedirectMatch 403 muieblackcat

# 5G:[BAD IPS]

Order Allow,Deny
Allow from all
# uncomment/edit/repeat next line to block IPs
# Deny from 123.456.789

Alcune note

Se sul vostro sito ospitate dei download, fate molta attenzione a questa riga:

RedirectMatch 403 \.(cgi|asp|aspx|cfg|dll|exe|jsp|mdb|sql|ini|rar)$

che contiene un filtro contro, fra gli altri, i files .rar

In caso quindi alcuni dei vostri downloads siano compressi con questo formato, rimuovete semplicemente l’eccezione “rar” dalla regola:

RedirectMatch 403 \.(cgi|asp|aspx|cfg|dll|exe|jsp|mdb|sql|ini)$

Via	5G Blacklist 2012

Come proteggere un sito dagli attacchi - Parte 1 - I bad crawler

Mon, 07 May 2012 11:36:11 +0200

Questo blog da alcuni giorni si trova sotto attacco dei cosiddetti “bad crawler”, cioè di bot il cui scopo consiste nel download indiscriminato di ogni singolo elemento che componga il sito web.

Questo genere di attacco provoca un enorme spreco di banda passante (nel nostro caso, si sono viste punte anche di 2Gb/sec di upload verso Internet per diverse ore, reiterati più volte nell’arco della giornata) ed un impegno della CPU del server che molto spesso raggiunge il 100%, arrivando a bloccare così non solo il sito colpito, ma tutti quanti si trovano ospitati all’interno della stessa macchina.

Infatti, negli ultimi 4 giorni la media delle visite su www.skyflash.it si è quasi dimezzata, arrivando a punte minime davvero non abituali per questo blog, proprio a causa dei frequenti blocchi del server, incapace di soddisfare tutte le richieste a cui era sottoposto. Nei giorni passati sono state ovviamente prese alcune contromisure, la cui bontà è ancora in fase di testing. Alcune di queste sembrano più efficaci di altre che sono quindi state scartate, o che devono ancora ricevere il necessario tuning.

Questo è il primo articolo dedicato alla protezione di un sito Internet basato su WordPress, a cui ne seguirà un altro, basato sulla nostra esperienza diretta e su una discreta quantità di informazioni recepita in rete in questi giorni.

Una trappola per i bots maligni
Creiamo la trappola
Alcune personalizzazioni
Whitelisting dei bot

Una trappola per i bots maligni

Il primo passo da compiere consiste nel realizzare una trappola in grado di ingabbiare i crawlers. Un web crawler non fa altro che collegarsi tramite una richiesta HTTP al sito da colpire, iniziando a scaricare tutto quanto trovi in quella pagina, in modo ricorsivo seguendo ogni singolo link che viene rilevato all’interno della stessa.

L’idea, quindi, consiste nel fargli trovare un link invisibile ad un normale visitatore, che lo faccia puntare ad una specifica directory, che contiene la trappola stessa. La trappola altro non è che uno script php in grado di bannare l’IP del crawler, impedendogli di conseguenza ogni possibile accesso in futuro.

Un crawler normale (come ad esempio googlebot, bing eccetera) non sarà interessato a seguire il link nascosto, e non accederà mai alla trappola in quanto la stessa viene negata all’interno del file robots.txt (file che viene normalmente letto ed interpretato da qualsiasi bot “legale” ed ovviamente ignorato da chi ha intenzioni malevole)

Creiamo la trappola

Per la creazione della trappola, dopo aver provato un paio di script, ho deciso di adottare Blackhole di PerishablePress.

In realtà ci sarebbe anche l’ottimo ZB Block, ma devo ancora finire di approfondirne la conoscenza, e quando l’ho installato e provato per 60 minuti circa, il risultato è stato il blocco anche di visitatori normali, tutti provenienti da ADSL Telecom Italia con IP dinamico. Quindi, per il momento, ZB Block non verrà ulteriormente citato.

Step 1: Innanzi tutto, procediamo a scaricare l’ultima versione dello script dalla pagina ufficiale di Blackhole su Perishable Press e scompattiamo lo zip da qualche parte sul nostro computer

Step 2: Carichiamo quindi via FTP la directory /blackhole/ nella root del nostro sito

Step 3: Verifichiamo che il file /blackhole/ sia regolarmente scrivibile (impostare i permessi a 755)

Step 4: Inserire il seguente codice in cima ad ogni pagina del sito. Nel caso di WordPress, la soluzione migliore è l’inserimento in prima posizione all’interno del file wp-load.php, ricordandosi però di andare a rieseguire la modifica ad ogni aggiornamento:

<?php include($_SERVER['DOCUMENT_ROOT'] . "/blackhole/blackhole.php"); ?>

Lo script blackhole.php controlla l’IP richiedente all’interno della blacklist contenuta nel file blackhole.dat. Se viene trovata una corrispondenza, la richiesta viene bloccata e viene mostrato un breve messaggio (personalizzabile).

Step 5: La trappola vera e propria! Aggiungere al footer.php del proprio template, questo codice:

<a style="display: none;" href="http://example.com/blackhole/" rel="nofollow">Do NOT follow this link or you will be banned from the site!</a>

Questo è il link reso invisibile tramite CSS che i bad crawlers seguiranno diligentemente come tanti topolini seguono il Pifferaio Magico. Essendo reso invisibile, nessun visitatore lo vedrà mai e quindi non esiste il pericolo che possa venire cliccato inavvertitamente.

Sostituite http://example.com con l’indirizzo del vostro sito

Step 6: Passo fondamentale, da eseguire assolutamente. Apriamo il nostro robots.txt ed aggiungiamo:

User-agent: *
Disallow: /blackhole/*

Come detto, i bot “legali” interpretano correttamente il file robots.txt quindi, grazie a questa regola, saranno direttamente esclusi dalla directory contenente la trappola e non correranno quindi il rischio di venire bloccati per errore.

Alcune personalizzazioni

Il file index.php richiede un minimo di configurazione. Aprire /blackhole/index.php ed eseguire le seguenti modifiche:

Riga #54: Il percorso del nostro file robots.txt
Riga #56: Il percorso della nostra pagina per i contatti
Righe #140/141: L’indirizzo email del mittente e del destinatario della notifica che riceveremo per ogni nuovo bot blacklistato da Blackhole
Nel file blackhole/blackhole.php modificare la Riga #53 con le nostre informazioni di contatto esterne al sito

Whitelisting dei bot

Lo script Blackhole si preoccupa, a scanso di errori, di eseguire il whitelisting dei principali bot di indicizzazione. In questa versione, la whitelist comprende:

googlebot (Google)
msnbot (MSN/Bing)
yandex (Yandex)
teoma (Ask)
slurp (Yahoo)

E’ possibile eventualmente inserirne altri, modificando manualmente la riga #40 all’interno del file blackhole.php

Aggiornamento: se installato su un CMS, come Joomla o WordPress, potreste ricevere un errore del tipo “Error opening file…”. Per risolvere il problema, aprite il file blackhole.php e modificate la riga evidenziata, immettendo il percorso assoluto del file blackhole.dat all’interno del vostro server:

$filename = "/var/www/example/web/blackhole/blackhole.dat"; // scan to prevent duplicates
$fp = fopen($filename, "r") or die("Error opening file...");
while ($line = fgets($fp)) {
    if (!preg_match("/(googlebot|slurp|msnbot|teoma|yandex)/i", $line)) {
        $u = explode(" ", $line);
        if ($u[0] == $_SERVER['REMOTE_ADDR']) ++$badbot;
    }
}

Via	Perishable Press

Ciao, Steve

Thu, 06 Oct 2011 08:27:12 +0200

Oggi il blog si ferma, per ricordare il più grande genio creativo dei nostri tempi, nei cui confronti abbiamo - tutti - un enorme debito. Alla visionarietà di Steve Jobs dobbiamo la nascita di device quali iPod, iPhone od iPad. Dispositivi divenuti non solo standard, ma che sono stati capaci di creare un vero e proprio segmento commerciale che fino a quel momento non esisteva.

Mi risulta molto difficile trovare le parole adeguate con cui esprimere, in questo momento, quel senso di smarrimento, di vuoto e di profonda tristezza che sto provando. Steve Jobs, più di ogni altro, ha lasciato un’impronta indelebile nella storia dell’home computing e non potrà mai essere dimenticato.

A Steve Jobs deve andare tutta la nostra riconoscenza.

Questo blog ha deciso di salutare Steve pubblicando quello che forse è il video più famoso fra quelli che lo riguardano. Si tratta del discorso che tenne nel 2005 dinanzi ai laureandi dell’Università di Stanford.

Nel 2011 Apple attivò temporaneamente un indirizzo email attraverso il quale chiunque poteva esprimere il proprio cordoglio per la scomparsa di Steve Jobs: rememberingsteve@apple.com. A distanza di tanti anni quell’indirizzo non è più attivo, ma lo riportiamo qui come testimonianza di quei giorni.

Foto di copertina: Joi Ito, CC BY 2.0, ritagliata e convertita in bianco e nero.

La traduzione in Italiano di Planescape: Torment realizzata dal team ITP

Wed, 14 Oct 2009 13:04:50 +0200

Correva l’anno 1999 quando, in pieno boom dei CRPG, Black Isle Studios rilasciò il suo attesissimo Planescape: Torment. Il gioco, basato sulle regole di Advanced Dungeons and Dragons, era ambientato nell’universo parallelo di Planescape, e si contraddistinse da subito per l’enorme mole di testo e per un gameplay molto orientato al dialogo ed agli effetti delle proprie scelte piuttosto che alla forza bruta.

I temi affrontati si contraddistinguevano per i loro colori forti ed adulti, andando a toccare la religione, il confine fra la vita e la morte e teorie esistenziali.

Il protagonista, il Nameless One (il Senza Nome), si risveglia in un mondo abitato da morti e, in compagnia del simpatico ed a tratti logorroico “Morte” - un teschio fluttuante - inizierà la sua missione con lo scopo di risolvere due fondamentali quesiti: conoscere il proprio passato e tornare mortale.

Il gioco, malgrado la sua indiscutibile qualità (ancora oggi viene definito da molti come il miglior CRPG mai prodotto per computer) ha avuto una scarsa diffusione nel nostro Paese, anche a causa della scelta operata dal distributore, CTO di Bologna, di non tradurlo. Scelta comprensibile vista la mole di testo a video, ma molto svantaggiosa per i giocatori non ferratissimi in Inglese, visto che i dialoghi sono ricchi di slang e modi di dire, e quindi terribilmente complessi da leggere e comprendere per i più.

Alcuni mesi dopo l’uscita del gioco nei negozi un gruppo di ragazzi decise di riunirsi, e di mettersi al lavoro su quella che passerà alla storia come la traduzione amatoriale più grande, complessa e di qualità che sia mai stata realizzata in Italia. Quel gruppo prese il nome di Italian Translation Project o, in breve, ITP.

Fu un lavoro enorme, vista la ferma intenzione dei ragazzi di mantenere quanto più possibile lo stile dei dialoghi in slang, portandoli in una lingua comprensibile per i propri connazionali. Non si fecero remore nel tradurre parole anche non politically-correct, quelle parolacce ed imprecazioni che 10 anni fa nessun editore si sarebbe mai sognato di inserire nelle proprie traduzioni. Ci vollero più di due anni ma alla fine, in pieno 2002, il lavoro venne rilasciato.

Da allora l’ITP si è dedicato ad alcune delle traduzioni più importanti:

Arcanum
Divine Divinity
Morrowind: Bloodmoon
Morrowind: Tribunal
The Elder Scrolls: Morrowind

Per un breve periodo della mia vita, in occasione della conversione di Morrowind, io stesso ho fatto parte di quel gruppo. Un esempio del mio lavoro è tutta la fase iniziale del tutorial di Morrowind, ed una parte dei dialoghi di combattimento dello stesso gioco.

Veniamo ora alla ragione per cui, a distanza di 7 anni, ho deciso di rendere disponibile al download la traduzione di Planescape: Torment. E’ molto semplice: gli anni sono passati, il sito del team ITP ormai non è più attivo, così come non esiste nemmeno più il dominio e, pure cercando su Google, risulta piuttosto difficile reperire questo file che io reputo così importante.

Lo Skyblog esiste da quasi 5 anni; prima di essere un blog, questo dominio ospitò il forum e la mailing list da cui partì la traduzione di The Elder Scrolls: Morrowind. Mi sembra quindi giusto, non avendo io intenzione di sospendere questo dominio ancora per un bel pezzo, permettere a chi sta cercando - o cercherà in futuro - la conversione in Italiano di Torment, di poterne fruire tranquillamente e di poter gustare al meglio il miglior CRPG di sempre, con la migliore traduzione amatoriale Italiana di tutti i tempi.

Per concludere, manca solo il link. Il file è contenuto in un archivio rar.

Scarica la traduzione in Italiano di Planescape: Torment

Twittero in Italiano anche io

Tue, 13 Oct 2009 08:50:08 +0200

Da qualche giorno il team di Twitter ha selezionato una ristretta cerchia di utenti Francesi, Italiani, Tedeschi e Spagnoli a cui ha chiesto se erano interessati a tradurre il proprio portale nelle loro rispettive lingue. Io appartengo a questo gruppo di persone ed ho ovviamente subito accettato di partecipare alla traduzione.

Spesso molte persone mi chiedono “perche’ lo fai gratis?”. Beh, la risposta è piuttosto semplice, e cioè “perchè mi piace farlo, e perchè Twitter è e resta gratuito per tutti”. In fin dei conti, ho avuto il piacere e l’onore di avviare - e partecipare - ad uno dei progetti di traduzione per un Videogioco più enormi che io ricordi, quel The Elder Scrolls III: Morrowind che ogni giocatore che si rispetti non può non aver giocato. Quel progetto partì grazie a me e all’allora responsabile del sito rpgplayer.it, ora “inglobato” da Multiplayer.it, fino ad assumere tratti quasi commerciali. Poi, per cause che non starò ad illustrare, tornò (fortunatamente - dico io -) ad essere amatoriale e la traduzione venne rilasciata dall’ITP dopo oltre due anni di lavoro, ed una mole di testo scritto paragonabile al tomo di Guerra e Pace.

Quindi, se abbiamo tradotto Morrowind gratis (per correttezza, va detto che dovetti mio malgrado abbandonare il team ITP dopo i primi sei mesi di lavoro per cause personali, ma che la mia persona viene comunque citata dalla quest aggiuntiva legata alla traduzione), perché non tradurre quei pochi caratteri che compongono tutto il sito di Twitter?

Inoltre il lavoro che abbiamo accettato di svolgere è indirizzato a tutti gli utenti Italiani, per dare modo a tutti, anche a chi non sa una mezza parola di Inglese, di fruire di uno dei servizi più in voga dell’ultimo periodo, a tal punto da essere integrato addirittura in console come XBox 360 e videogiochi come Uncharted 2.

Napolux, un altro traduttore selezionato, la vede un po’ al mio stesso modo, e sono convinto che questo sia più o meno il pensiero di tutti gli utenti che si sono buttati nell’impresa.

Script bash per il backup di un database MySQL

Sat, 15 Jan 2005 15:08:20 +0100

In passato ho avuto bisogno di uno script che, in modo automatico, mi facesse una serie di backup del database MySQL che gira sul nostro server in azienda.

Così mi sono messo un paio d’ore a studiare il linguaggio bash, che non conoscevo, ed ho “partorito” questo script:

Dopo alcune impostazioni iniziali, non fa altro che eseguire un dump del database e ne mette una copia nella home dell’utente, col nome [database]_DAILY_[data_di_oggi] e, nel caso ci sia, rinomina quello del giorno prima in [database]_OLD

Infine genera un ulteriore dump e lo piazza in una altra directory, che sul mio server corrisponde a /dati e lo nomina Backup_db_[database]_[weekday], dove [weekday] è il giorno della settimana. In questo modo avremo sempre due copie del db nella nostra home (quella odierna e quella di ieri) e ben 7 copie, una per ogni giorno della settimana, in /dati (o altra directory).

E’ molto grezzo, e chi volesse contribuire a migliorarlo è ben accetto 😉

#!/bin/bash
# Impostazioni dello script
# Qui comincia la sezione delle varibili utente da impostare
# Regolare questi valori secondo le proprie necessita'
# INIZIO SEZIONE IMPOSTAZIONE
#
# DIR -> Nome della directory home dell'utente.
# ATTENZIONE: DEVE TERMINARE CON "/"
#
# BACKUP -> Nome della directory dove andranno i backup.
# ATTENZIONE: DEVE TERMINARE CON "/"
#
# DATABASE -> Nome del database MySQL
#
# NAME -> Nome che verra' usato per generare il backup.
# ATTENZIONE: MANTENERE IL SUFFISSO "_DAILY_"
#
# OLD -> Nome che verra' usato per copiare il database
# del giorno prima. ATTENZIONE: MANTENERE IL SUFFISSO "_OLD"
#
DIR="/home/utente/"
BACKUP="/directory/"
DATABASE="NOME DATABASE"
NAME="NOME_DAILY_"
OLD="NOME_OLD"
#
# FINE DELLA SEZIONE DI IMPOSTAZIONE
#
# Queste sono le variabili di data e di ricerca
# in base al nome ricavato dalle variabili precedenti
#
OF=$(date +%d-%m-%Y)
IF=$(ls $DIR | grep $NAME)
DAY=$(date +%w_%a)
#
# Cambio il nome del file trovato
mv $DIR$IF $DIR$OLD.sql
#
# Eseguo il dump del database definito dalle variabili
#
# ALTRE IMPOSTAZIONI
# Cambiare [nome] con il nome utente e [password] con la password
# Cambiare [group] con il gruppo a cui appartiene l'utente (solitamente, uguale a [nome])
#
mysqldump --user=[nome] --password=[password] $DATABASE > $DIR$NAME$OF.sql
mysqldump --user=[nome] --password=[password] $DATABASE > $BACKUP"Backup_db_"$DATABASE"_0"$DAY.sql
#
# Cambio i permessi del dump nella mia home
# perche' sono fighetto e li voglio gia' accessibili al mio utente
#
chown [nome].[group] $DIR$NAME$OF.sql
#
echo Backup del database $DATABASE eseguito!

Download backup-mysql.sh

Nota: passare la password con --password= la rende visibile a chiunque lanci ps sulla stessa macchina, oltre che nella cronologia della shell. Oggi è preferibile salvare le credenziali in un file ~/.my.cnf (con permessi chmod 600) e lanciare mysqldump senza specificarle sulla riga di comando.

Pianificazione automatica

Per eseguire il backup ogni notte senza doversene ricordare, basta aggiungerlo al crontab:

crontab -e

ed inserire una riga come questa, che lo esegue ogni giorno all’1:00 di notte:

0 1 * * * /home/utente/backup-mysql.sh

Cristian Castellari — CV, Progetti e Blog

DocSteer: un tema Jekyll per la documentazione

Perché un altro tema per la documentazione

Cosa fa

Perché “DocSteer”

Come si usa

Come l’ho costruito

Cosa manca ancora

Perché è gratis

DocSteer: a Jekyll theme for documentation

Why another documentation theme

What it does

Why “DocSteer”

How to use it

How it was built

What’s still missing

Why it’s free

Twitter potrebbe tornare grazie a Operation Bluebird?

Chi c’è dietro Operation Bluebird

La causa: X Corp. v. Operation Bluebird

Un pronostico difficile, ma stimolante

Il mio punto di vista. Personale.

Il redesign di Ipui2Ipei

Perché rifare un tool che quasi nessuno nota

Cosa c’era prima, e perché non bastava più

Stesso schema, aggiustamenti su misura

Riscrivere l’algoritmo senza cambiare un solo bit di output

La palette: dal primo tentativo a quello buono

Una nuova pagina Contatti

Un bug trovato scrivendo la pagina Contatti

Cosa mi porto a casa

Potenziare la ricerca interna del blog

Cosa faceva, prima

Un confronto con un altro progetto

Cosa ho portato, e come

Un bug silenzioso trovato per strada

Verificare uno script che scarica dati e aggiorna il DOM, da terminale

Cosa mi porto a casa

Il nuovo sito, parte 5: breadcrumb, metainfo riordinate e un post in vetrina

Un breadcrumb, per chi legge e per chi indicizza

La riga con data e tempo di lettura, spostata due volte

Un post in vetrina, e la lezione sulle immagini con testo dentro

Perché questa parte conta

Una VPN veloce e solida con WireGuard: da Windows Server 2022 a Windows 11

Perché WireGuard e non OpenVPN o IPsec

Prerequisiti

Architettura e schema di indirizzamento

Installazione su Windows Server 2022

Generare la coppia di chiavi del server

Il file di configurazione del server

Attivare il tunnel come servizio Windows

Aprire la porta sul firewall e sul router

Configurazione del client Windows 11

Generare la coppia di chiavi del client

Il file di configurazione del client

Aggiungere il peer sul server

Verificare che tutto funzioni

Tunnel completo o split tunnel?

Qualche accorgimento di sicurezza

Perché è così veloce

Conclusioni

Download

Riferimenti

A fast, solid VPN with WireGuard: from Windows Server 2022 to Windows 11

Why WireGuard over OpenVPN or IPsec

Prerequisites

Architecture and addressing scheme

Setting up Windows Server 2022

Generating the server’s keypair

The server’s config file

Running the tunnel as a Windows service

Opening the port on the firewall and the router

Setting up the Windows 11 client

Generating the client’s keypair

The client’s config file

Adding the peer on the server

Checking that everything works

Full tunnel or split tunnel?

A few security notes

Why it’s this fast