Nell’ultimo mese ho spostato tutto su Coolify, un PaaS self-hosted open source, installato su un server che gestisco io su Hetzner. Oggi una dozzina di siti WordPress di Sintab e dei suoi progetti (formazione, e-commerce interni, portali corsi) girano lì come container, insieme a n8n, Filebrowser e qualche altro servizio. Ma la parte che mi interessa raccontare non è “ho installato Coolify” — è l’insieme di script che ci ho costruito intorno, perché è lì che si è fatto il lavoro vero.
Il primo problema era che aprire un sito nuovo restava un rito manuale: creare l’app, il database, i domini, le variabili d’ambiente, il backup, e ricordarsi ogni volta un dettaglio che la volta prima avevo dimenticato. Ho scritto nuovo-sito.sh, che prende nome e dominio e fa tutto passando dall’API di Coolify: crea un MariaDB gestito, un’Application buildata dal repo git via Dockerfile, un volume persistente su /var/www/html, le variabili d’ambiente (tutte runtime, mai build-time — altrimenti la password del database finisce nella history dell’immagine Docker), attiva il backup automatico schedulato, fa il primo deploy e infine aggancia il sito a Filebrowser.
Un paio di cose imparate a mie spese sono finite come commenti nello script stesso, perché altrimenti le avrei dimenticate di nuovo:
# I domini si passano ADESSO, alla creazione: Coolify genera le label Traefik
# una sola volta e le salva sull'Application. Cambiare fqdn dopo non le
# rigenera, e il container resta con le label del dominio vecchio -> 503.
La primissima versione, prima ancora di questo script, generava a mano un docker-compose e lo spingeva via API come Service. Funzionava, ma disattivava i backup automatici di Coolify (funzionano solo sulle risorse che gestisce lui) e teneva la configurazione fuori da git. L’ho sostituita perché un sistema comodo ma che rinuncia ai backup gestiti non è un compromesso accettabile.
Il pezzo a cui tengo di più è backup-siti.sh. La prima versione aveva l’elenco dei siti scritto a mano in cima allo script. Ha smesso di andarmi bene l’11 agosto, quando uno dei siti è passato da Service ad Application su Coolify e il volume ha cambiato nome: l’elenco fisso avrebbe continuato a salvare un volume ormai morto, senza dare nessun errore. Un backup che sembra riuscito ma salva il nulla è peggio di un backup che fallisce rumorosamente.
Ora lo script non ha nessun elenco: scopre i siti interrogando i container in esecuzione per la variabile d’ambiente WORDPRESS_DB_NAME, e da lì risale a utente, password e volume dei file. Se conta meno siti del minimo atteso, si ferma prima di scrivere qualsiasi cosa e prima della potatura delle copie vecchie — una copia incompleta che sovrascrive le buone è peggio di nessuna copia.
L’altro cambiamento è dove finiscono le copie offsite. Prima versione upload S3 integrato di Coolify verso Backblaze B2. È bastato che un plugin di export generasse un .wpress da 7,4 GB più due tentativi di upload troncati per saturare il piano gratuito e mandare l’intero account in blocco scrittura. Ho tolto Backblaze e sono passato a un Hetzner Storage Box via rclone, con verifica hash dopo ogni copia e potatura esplicita (copy, non sync: se svuoto per errore la cartella locale non voglio che la notte dopo si porti dietro anche l’offsite).
maintenance-check.sh gira ogni lunedì e mi manda un report via email. Controlla se le immagini Docker esterne (WordPress, PHP, MariaDB, n8n) hanno una patch più recente sullo stesso tag, e soprattutto confronta il commit effettivamente deployato con la HEAD remota del branch di ogni sito — senza bisogno di un checkout locale dei repository, dato che ormai tutto vive dentro Coolify. Il trucco è che il tag dell’immagine Docker di ogni Application è lo SHA del commit buildato: basta un git ls-remote per sapere se un sito è rimasto indietro rispetto a main. Lo stesso report controlla lo stato HTTP di ogni dominio e le risorse del server.
L’ultimo pezzo, filebrowser-sync.sh, risolve un problema più organizzativo che tecnico: qualcuno in ufficio deve poter aprire i file di un sito senza chiedermi ogni volta una chiave SSH. Filebrowser gira come servizio su Coolify con l’IP dell’ufficio (o la VPN) in allowlist, e i suoi mount vengono rigenerati da zero ogni volta a partire dallo stato reale — quali volumi esistono davvero, montati su /var/www/html — invece che aggiunti in coda uno alla volta. È idempotente e si autoripara: se un sito viene cancellato, sparisce anche dal mount; se ne nasce uno nuovo, nuovo-sito.sh lo aggancia da solo come ultimo passo.
Non è solo “ora è tutto su Docker invece che su hosting condivisi”. È che gli script non si fidano più di un elenco scritto una volta e mai più aggiornato: interrogano lo stato reale — i container in esecuzione, i volumi montati, i commit deployati — ogni volta che girano. I due incidenti che li hanno plasmati (il volume rinominato, l’account Backblaze bloccato da un export troppo pesante) sono diventati controlli scritti nel codice, non note a margine da ricordarsi a memoria. Per una dozzina di siti gestiti da una persona sola, è la differenza tra dormire tranquillo e sperare che nessuno faccia domande scomode di lunedì mattina.
]]>Francesco La Vella Ads Tools è un progetto personale che ho costruito per automatizzare alcune operazioni ricorrenti sul mio account Google Ads: estrazione di report, controlli periodici sullo stato delle campagne e aggiornamento di alcuni parametri (budget, stato degli annunci) in base a regole che decido io.
Non è un prodotto destinato ad altri utenti: è un tool che uso esclusivamente per la gestione dei miei account pubblicitari personali.
Il progetto è costruito attorno a n8n, uno strumento di automazione a workflow open source che eseguo su un mio server. I workflow si collegano alla Google Ads API tramite OAuth 2.0, con il mio account Google come unico utente autorizzato.
In pratica il workflow interroga periodicamente l’API per leggere le performance delle campagne, genera report che ricevo automaticamente, e in alcuni casi esegue modifiche puntuali (ad esempio pausare un annuncio sotto una certa soglia di rendimento) secondo regole che ho definito io. I dati settimanali estratti vengono inoltre scritti in un foglio Google Sheets personale, che uso come archivio e per costruire grafici di andamento.
Per funzionare, l’app richiede l’autorizzazione OAuth ai seguenti scope Google:
https://www.googleapis.com/auth/adwords — accesso in lettura e scrittura al mio account Google Ads. Mi serve per leggere le metriche di rendimento delle campagne (impression, click, spesa, conversioni) e per applicare modifiche puntuali che ho definito io stesso, come la pausa di un annuncio sotto una certa soglia di rendimento.https://www.googleapis.com/auth/spreadsheets — accesso in lettura e scrittura ai fogli di calcolo Google Sheets. Mi serve per scrivere ogni settimana i dati estratti da Google Ads in un foglio personale che uso come archivio storico.https://www.googleapis.com/auth/drive.file — accesso limitato ai soli file creati o aperti tramite questa app. Mi serve perché n8n, per scrivere su Google Sheets, deve poter individuare il foglio specifico che ho indicato.Non viene richiesto alcun accesso a dati di altri utenti: l’unico account collegato è il mio.
I dati letti dall’API restano tra il mio account Google Ads e il mio workflow n8n, eseguito su un server che gestisco personalmente. Non vengono raccolti, condivisi o ceduti a terzi, e non vengono usati per finalità diverse da quella descritta sopra.
L’informativa completa sul trattamento dei dati è disponibile nella Privacy Policy del sito.
Per qualsiasi domanda su questo progetto puoi contattarmi ai recapiti indicati nella pagina About.
]]>~/.claude-mem. Locale, appunto.
E io — l’ho già raccontato parlando di questo stesso blog — lavoro da più postazioni. Ogni macchina aveva la sua memoria, isolata dalle altre. Cominciare una sessione sul portatile senza il contesto accumulato al fisso in studio, ogni volta, era esattamente il problema che claude-mem dovrebbe risolvere.
claude-mem offre già un modo per sincronizzare tra macchine: cmem.ai, un servizio cloud della stessa softwarehouse, con un hub proprietario (un Cloudflare Worker per utente) che fa da centro sync. Comodo, supportato, zero configurazione oltre a un token. Ma significa caricare su un’infrastruttura di terzi le narrazioni delle mie sessioni di lavoro — che spesso includono cose di clienti e progetti aziendali. Per uso personale forse ci avrei anche pensato, ma non con dati che non sono solo miei.
Ho controllato se esistesse un modo per auto-ospitare quello stesso hub. Non esiste: ho trovato una discussion su GitHub dove il maintainer conferma che no, self-hosted non è previsto, e gli script di export/import manuale sono anche rotti (FOREIGN KEY constraint failed, per chi è curioso). Altra strada scartata: montare la cartella ~/.claude-mem via rete (NFS o sshfs) e condividerla tra macchine. SQLite in WAL mode — quello che usa claude-mem — sopra un filesystem di rete è una ricetta nota per corruzione dei dati: il locking a byte-range che il WAL richiede spesso non è implementato correttamente da quei filesystem. Meglio di no.
La soluzione più semplice, alla fine, era anche la più ovvia: invece di sincronizzare un database tra macchine diverse, eliminare le macchine diverse. Un solo posto dove il database vive, e ci si collega da dovunque via SSH.
Da un po’ ho messo su un server su Hetzner che uso come base per gestire tutti i miei progetti — repository, ambienti di lavoro, servizi che devono girare in modo continuo. Ci si accede via SSH, con un alias dedicato nel mio ~/.ssh/config. Era la casa naturale anche per claude-mem: un solo posto, sempre acceso, che già considero “il mio server” per tutto il resto.
Qui la parte tecnicamente interessante. claude-mem non gira solo su Node: il suo worker daemon usa bun:sqlite per parlare col database, quindi richiede Bun, non solo Node.js. E per la ricerca semantica usa Chroma via chroma-mcp, lanciato con uvx — quindi serve anche uv, il gestore di pacchetti Python di Astral. Tre runtime diversi (Node, Bun, uv) per un plugin che sulla carta “aggiunge memoria a Claude Code”.
Sul server nuovo, nessuno dei tre era installato. Li ho messi su tutti in user-space, senza toccare i pacchetti di sistema (a parte unzip, richiesto dall’installer di Bun):
nvmuv/uvx via l’installer di AstralPoi marketplace e plugin con la CLI di Claude Code stessa:
claude plugin marketplace add thedotmack/claude-mem
claude plugin install claude-mem@thedotmack
Il primo tentativo di avvio ha subito segnalato nei log l’assenza di Bun (“worker daemon requires Bun because it uses bun:sqlite”). Installato Bun, il worker si è avviato ma senza ricerca semantica (“uvx executable not found for chroma-mcp”). Installato anche uv, riavviato il worker, e al terzo giro tutti i pezzi hanno agganciato: sessione registrata nel database, Chroma connesso, nessun errore nei log.
Il login di Claude Code resta l’unico passaggio davvero manuale — richiede il browser, quindi va fatto una volta a mano dentro una sessione tmux sul server (per non perderlo se cade la connessione SSH). Fatto quello, ho aggiunto un alias in .bashrc che riassume tutto il flusso quotidiano:
alias mc='ssh -t myserver "tmux new-session -A -s claude claude"'
tmux new-session -A crea la sessione se non esiste, altrimenti si riattacca a quella già viva — quindi la prima volta apre claude, le volte dopo ritrovo la sessione esattamente dove l’avevo lasciata, da qualsiasi postazione digiti mc.
Non lavoro più “in locale” quando uso Claude Code per certe cose: lavoro dentro il server, e i progetti che voglio che claude-mem osservi devono vivere lì. È un cambio di abitudine, non solo di configurazione. In cambio ho un solo database SQLite, mai conteso da due macchine insieme, senza rischio di corruzione da filesystem di rete e senza che una singola riga delle mie sessioni finisca su un cloud che non controllo. Per il tipo di lavoro che faccio — clienti, dati aziendali, roba che non è solo mia da condividere — mi sembra il compromesso giusto.
]]>Il primo passo è stato risolvere un mio problema operativo: scrivo da tre macchine diverse — fisso di casa, portatile, fisso in studio — e fino a poco fa il workflow era fragile. Ora lavoro su un repo Git, con la stessa cartella sincronizzata via GitHub, e su ognuna delle tre postazioni ho claude configurato allo stesso modo. Apro il terminale, git pull, lavoro, git push. La parte interessante è che Claude Code legge davvero il progetto: i _posts, i layout, gli SCSS, persino i plugin Ruby in _plugins/. Questo significa che le modifiche non sono mai a tentoni — sono sempre ancorate a quello che c’è già.
L’audit iniziale ha tirato fuori cose imbarazzanti. Il filtro {{ content | liquify }} in _layouts/post.html puntava a una gem che nel Gemfile.lock non esisteva, quindi non faceva niente da chissà quanto. Otto layout caricavano jQuery 3.2.1 da CDN e contemporaneamente, dentro scripts.html, veniva caricata anche la 1.12.2 — due jQuery diversi sulla stessa pagina, uno che si sovrascriveva l’altro. Il plugin custom youtube.rb aveva l’href dell’embed hardcoded a un video specifico: in pratica ogni {% youtube %} puntava sempre allo stesso video sbagliato. Ventidue link target="_blank" senza rel="noopener" — vulnerabilità da reverse-tabnabbing che è lì da sempre.
Pulizia: jQuery via, sostituito da una novantina di righe di vanilla JS in assets/js/menu.js e assets/js/goup.js. Gli script inline duplicati negli otto layout — quaranta righe ciascuno, sempre uguali — diventati un singolo <script defer src="menu.js">. Il filtro morto rimosso, il plugin YouTube corretto, i rel="noopener noreferrer" aggiunti dappertutto.
Non avevo mai guardato nemmeno la dimensione delle immagini. profile.png era 3.1 MB. Tremilacento kilobyte per un avatar che si vede a 300×300. Peggio: lo stesso file, alla stessa risoluzione gigantesca, era usato come og:image per ogni anteprima social. C’era anche avatar_flv.png da 2.3 MB nella cartella, non referenziato da nessuna parte da chissà quando. Con imagemagick e cwebp ho generato profile-300.webp (16 KB), profile-600.webp (38 KB) per il retina, e profile-og.jpg (297 KB) per le anteprime social. Il layout home ora usa un <picture> con srcset 1x/2x. Risultato: la cartella assets/img è passata da 9.6 MB a 4.8 MB, e l’avatar in homepage scarica oggi 16 KB invece di 3.1 MB. Una differenza di duecento volte.
La cookie bar che usavo era CookieConsent v3.0.3, libreria abbandonata dal 2018, caricata via protocollo // (deprecato). L’ho sostituita con vanilla-cookieconsent v3 di orestbida — moderna, leggera, in italiano. Ma il vero cambiamento è un altro: GoatCounter (le mie statistiche) non setta cookie, e Disqus ora è caricato in lazy load solo quando l’utente accetta esplicitamente la categoria “commenti”. Sui post compare un bottone “Mostra commenti” che, se il consenso non c’è, apre il modal preferenze invece di caricare lo script. Niente cookie di tracciamento finché qualcuno non li chiede, di fatto.
Il tema, nato in epoca pre-mobile, era pieno di width: 1000px hardcoded. Su un telefono compariva la scrollbar orizzontale e bisognava zoomare. Ho convertito tutti i container fissi (.ortalaAna, .programcerceve, .iletisim, eccetera) in max-width con width: 100%, ho aggiunto un box-sizing: border-box globale, ho fatto scalare i font con clamp() invece dei pixel fissi, e ho introdotto due breakpoint nuovi a 768 e 480 pixel. La griglia dei progetti diventa due colonne sotto i 768, una sola sotto i 480. Le sidebar collassano sotto al contenuto. C’è anche un blocco @media (prefers-reduced-motion: reduce) che disabilita tutte le animazioni e i blur per chi ha quella preferenza nelle impostazioni del sistema operativo.
Il tema l’avevo preso da un autore turco e mi ero portato dietro le sue classi: .yazi, .yazibilgisi, .programcerceve, .urunResmi, .menuMobil. Funzionavano, ma aprire i DevTools e leggere <div class="programcerceve"> era straniante. In una passata di rinomina massiva ho riscritto tutto in nomi semantici inglesi: .post, .post-meta, .project-frame, .product-image, .menu-drawer. Trentotto classi rinominate in modo coordinato attraverso layout, SCSS e JavaScript, con boundary regex per non rompere prefissi. E il finale: la stringa {{ page.date | date_to_string }} tarihinde yayınlandı. — era turco da sempre, “pubblicato in data X” — è diventata Pubblicato il {% include date-it.html %} con un piccolo include che traduce il mese in italiano. Quindi non più “01 May 2026”, ma “1 maggio 2026”. Otto anni dopo.
Niente di urgente. Le pulizie strutturali sono fatte, il sito è leggero, responsive, accessibile, in italiano, con tutti i bug che mi portavo dietro silenziosamente sistemati. Restano le cose minori: le immagini dei post più vecchi che si potrebbero ottimizzare, qualche @font-face che si potrebbe restringere a subset latino. Cose che si fanno se si ha voglia, non perché serve.
La parte che mi ha colpito di più non è quanto codice è stato scritto — è quanto è stato eliminato. Variabili SCSS morte, plugin che non chiamavo, librerie obsolete, file di asset abbandonati, classi turche, inline duplicati, link rotti a domini scomparsi. Quasi tutto questo lavoro è stato sottrarre, non aggiungere. E quel tipo di lavoro è quello che, da soli, di solito non si fa mai.
]]>Prima di raccontare i singoli progetti, voglio dire una cosa sull’approccio, perché è cambiato qualcosa nel modo in cui lavoro.
Usare un AI come collaboratore tecnico non significa delegare. Significa avere sempre qualcuno con cui fare il punto. Il vantaggio non è la velocità — anche se quella c’è — ma la possibilità di non restare bloccato. Quando un problema diventa opaco, lo spiego ad alta voce e quasi sempre nel farlo capisco già dove guardare. Claude accelera quel processo: ascolta, risponde in modo contestuale, non parte da zero ogni volta se lo tieni aggiornato. Non è un oracolo. Sbaglia, propone soluzioni che non si compilano, a volte si incarta su dettagli che non esistono. Ma è il miglior interlocutore tecnico che ho avuto in anni, e questo conta.
Nella mia nuova sede Blink era necessario installare una “Rete con la R maiuscola”. Ho deciso di progettarlo dall’inizio: MikroTik come router centrale, uno switch managed, subnet separate, DHCP con assegnazioni statiche per i dispositivi fissi, e WireGuard per la VPN.
La parte che mi ha tenuto impegnato di più è stata la configurazione WireGuard lato MikroTik. RouterOS gestisce WireGuard in modo leggermente diverso rispetto a una macchina Linux standard, e la documentazione ufficiale è completa ma non sempre immediata da tradurre in pratica. Ho lavorato molto sulla segmentazione delle route e su cosa doveva passare nel tunnel e cosa no.
Cosa non ha funzionato subito: il routing split. Pensavo fosse banale definire quali traffici instradare via VPN e quali tenere locali. Non lo era. Ci sono voluti diversi cicli di test prima di avere un comportamento stabile e prevedibile. Claude è stato utile soprattutto nel diagnosticare i casi limite — traffico che spariva silenziosamente invece di fallire rumorosamente.
Quello che ho imparato: una rete fatta bene richiede di tenere in testa tre livelli contemporaneamente (fisico, logico, applicativo). Quando perdi il filo tra i tre, vai nel panico. Avere qualcuno con cui ricostituire il filo è stato utile quanto gli strumenti di debug.
Questo è stato il progetto più ambizioso del periodo. Ho costruito una piattaforma di digital signage completamente da zero, senza framework: PHP 8.2 puro, MariaDB, JavaScript vanilla, Apache con mod_rewrite, deploy su Host remoto.
L’idea era semplice: uno schermo remoto che mostra contenuti gestiti da una dashboard web. La realtà era molto meno semplice.
L’autenticazione JWT senza librerie. Ho scelto di implementare JWT a mano — non per masochismo, ma per capire cosa stavo firmando. È stato istruttivo e ha richiesto attenzione ai dettagli: encoding Base64Url, HMAC-SHA256, gestione della scadenza, validazione rigorosa dei claim. Claude ha tenuto il pacing su tutti e tre i layer (generazione, verifica, refresh) evitando che perdessi il filo tra le parti.
Il sistema di pairing. Ogni TV si registra con un codice a 6 cifre che scade. Sembra semplice, ma c’era da gestire la race condition tra la richiesta di pairing e la conferma dal server, lo stato del player durante l’attesa, e il comportamento in caso di codice scaduto o già usato. Abbiamo iterato parecchio su questa parte.
SELinux su Fedora. Questo merita una nota a parte. Il deploy su Fedora con SELinux abilitato è stato un muro. Apache non riusciva a leggere certi file, scrivere in certi path, fare reverse proxy verso socket — tutto silenzioso, senza errori chiari nel log Apache. La diagnostica con audit2why e ausearch è diventata una routine quotidiana. Claude conosceva bene il contesto SELinux e ha aiutato a identificare i contesti corretti senza ricorrere a setenforce 0, che sarebbe stata la resa.
Cosa non ha funzionato subito: il player HTML5 con fallback offline. La logica era: se il server è irraggiungibile, usa l’ultima playlist scaricata. Sembrava lineare. In pratica, la gestione del Service Worker, il caching delle risorse media e la sincronizzazione allo startup hanno richiesto molto più lavoro del previsto. Qualcosa funzionava nel browser di sviluppo e si rompeva sul Server. Debugging remoto su hardware embedded con risorse limitate è una categoria di dolore a sé.
Cosa ho imparato: zero framework non significa zero struttura. Significa che la struttura devi darla tu, e se non la dai con attenzione, il codice diventa rapidamente ingestibile. Ho sviluppato convenzioni molto precise per routing, response format e gestione degli errori — cose che un framework impone di default. Farlo manualmente ti fa capire perché esistono i framework.
L’app Android è ancora in lavorazione, ma la base c’è: Kotlin, Media3/ExoPlayer per la riproduzione, Coil per le immagini, Retrofit per la comunicazione con il server.
La parte più interessante è il kiosk mode. Un’app di signage deve resistere all’utente: niente back, niente home, niente notifiche che compaiono sopra il contenuto. Android ha meccanismi per questo (DevicePolicyManager, lock task mode) ma richiedono di essere il Device Owner dell’apparecchio, cosa che si configura una volta sola al provisioning del dispositivo.
Quello che non ha funzionato subito: la sincronizzazione tra ExoPlayer e la logica della playlist. ExoPlayer gestisce bene le code di media, ma quando la playlist cambia dinamicamente (nuovo contenuto dal server, elemento rimosso, cambio di ordine), la transizione deve essere pulita. Ho trovato diversi edge case in cui il player rimaneva bloccato sull’elemento precedente o saltava un elemento corretto.
Quello che ho imparato: Android ha una quantità enorme di API, molte deprecate e sostituite da alternative più recenti. Muoversi nella documentazione richiede di capire in quale “era” si trova ciascuna API. Claude è stato utile nell’orientarsi tra le versioni e capire cosa usare nel 2025.
Avevo KDE come desktop e mi trovavo bene, ma ho deciso di passare a GNOME che lo trovo molto più moderno. Non una migrazione drammatica, ma qualcosa che ha richiesto attenzione perché avevo configurazioni specifiche, estensioni, shortcut personalizzati.
Il punto interessante è stato capire cosa sopravvive a una migrazione KDE-to-GNOME e cosa invece è legato alla versione specifica. Alcuni file di configurazione in ~/.config/ si trasferiscono direttamente; altri (in particolare le estensioni) dipendono dalla versione di GNOME Shell e possono rompere silenziosamente.
Non è stato il progetto più complicato del mese, ma è stato un buon esempio di come Claude aiuta anche nei task di routine: non facendo le cose al posto tuo, ma ricordandoti i pezzi che avresti dimenticato (le keybindings custom, la configurazione di mimeapps, le impostazioni GTK).
Questo stesso sito. Ho rimesso mano all’ambiente di sviluppo locale dopo mesi di inattività, e Ruby non aspettava che io tornassi.
Il problema classico: dipendenze native che non compilavano. zlib, libyaml, libffi — tutte librerie che Jekyll richiede indirettamente, tutte con header che il sistema non trovava nel percorso giusto. Su Fedora, con la versione di Ruby gestita da rbenv, la sequenza corretta di flag di compilazione non è ovvia.
Ho anche integrato Goatcounter come sistema di analytics. È leggero, self-hostable, rispettoso della privacy, e non richiede cookie banner. L’integrazione in Jekyll è stata semplice — un frammento di JavaScript nel layout base — ma volevo capire esattamente cosa traccia e come, prima di aggiungerlo.
Quello che ho imparato: mantenere un ambiente Jekyll attivo richiede attenzione periodica. Non è un “set and forget”. Le dipendenze Ruby hanno un loro ciclo di vita, e ignorarle per sei mesi significa quasi certamente rompere qualcosa.
Guardando indietro a queste settimane, quello che colpisce non è la quantità di cose fatte — è la varietà. Reti, backend PHP, Android, desktop Linux, Ruby gems: domini diversi, problemi diversi, strumenti diversi.
In passato, questa varietà sarebbe stata un collo di bottiglia. Passare da MikroTik a SELinux a Kotlin in pochi giorni richiedeva ogni volta un riscaldamento cognitivo lungo. Con Claude, quel riscaldamento è più corto. Non perché lui sappia tutto — sbaglia spesso sui dettagli specifici di versione, a volte alucina API che non esistono, a volte propone soluzioni che funzionano in teoria ma hanno problemi pratici ovvi. Ma sa tenere il contesto, fare le domande giuste, e aiutarti a non perdere il filo.
I limiti reali sono due. Il primo: Claude non può testare. Può ragionare su un problema, proporre una soluzione, identificare edge case — ma non può vedere cosa succede quando il codice gira sul Server remoto con quella specifica versione di PHP e SELinux configurato in quel modo. Il testing rimane completamente tuo. Il secondo: il contesto finisce. Conversazioni lunghe su progetti complessi richiedono gestione attiva — ricapitolare lo stato, riorientare la discussione. Non è un difetto fatale, ma è un lavoro che va fatto.
Quello che rimane da fare: SignFlow Player Android ha ancora diversi edge case aperti. La rete BLINK funziona ma voglio aggiungere monitoring. E questo sito ha bisogno di più post.
Generated with the support of AI
Licenza d’uso © CC BY-NC-SA
]]>Oggi vi racconto come ho trasformato una semplice workstation in una fortezza digitale, gestendo storage, streaming 4K e accesso VPN remoto, il tutto su base Fedora Linux.
Siamo partiti con una situazione complessa (RAID degradati), e siamo atterrati sulla soluzione più robusta: JBOD (Just a Bunch Of Disks). Invece di affidarci a controller RAID software instabili, abbiamo montato i 4 dischi singolarmente tramite /etc/fstab.
Vantaggio: Se un disco muore, perdo solo quei dati, non l’intero array.
Organizzazione: Ogni disco ha uno scopo preciso (Film, Serie TV, Dati, Backup), montati in modo pulito sotto /mnt.
Per lo streaming dei media non ho installato software “sporcando” il sistema operativo. Ho scelto Podman (l’alternativa sicura a Docker di RedHat).
La sfida della Transcodifica (HEVC/H.265)
Il problema principale era la riproduzione di file moderni (MKV in H.265). Fedora, essendo open-source puro, non include i codec proprietari di default. La soluzione:
Abilitazione dei repository RPM Fusion.
Installazione tramite dnf5 dei gruppi multimedia e sound-and-video.
Aggiunta delle librerie ffmpeg-libs e x265.
Ora JARVIS macina flussi 4K senza incertezze, e grazie alla configurazione di Podman con flag --restart=always e il servizio podman-restart, il media server torna online da solo anche dopo un blackout.
Qui è dove JARVIS ha fatto il salto di qualità. Invece di un firewall piatto (“apri tutto o chiudi tutto”), abbiamo implementato una strategia a Zone.
Zona 1: La Casa (Rete Fisica enp2s0)
Sulla rete locale, la sicurezza è massima. Abbiamo rimosso il range di porte 1025-65535 (aperto di default su Fedora Workstation) applicando un approccio Whitelist:
Bloccato: Tutto.
Permesso: Solo SSH (22), Samba, Jellyfin (8096) e Torrent (2767 TCP/UDP).
Zona 2: L’Ufficio (VPN sintabVPN)
Il server è collegato all’ufficio tramite una VPN gestita da una Raspberry Pi. Abbiamo spostato l’interfaccia virtuale sintabVPN nella zona Trusted.
Risultato: Chi entra dalla VPN è considerato “fidato” e ha accesso completo ai servizi senza dover aprire porte extra sul firewall pubblico.
Basta ricordare indirizzi IP come 192.168.1.100.
Hostname: Il server risponde al nome jarvis.
Risoluzione Nomi: In casa sfruttiamo mDNS (jarvis.local), mentre per i colleghi in VPN abbiamo configurato i file hosts per un accesso trasparente alle cartelle condivise (\\jarvis).
Inoltre, per i Torrent, abbiamo configurato non solo il firewall di Fedora, ma anche il Port Forwarding sul Router, garantendo la “connettività” completa ai peer per download alla massima velocità.
Un server deve restare pulito. Invece di lanciare comandi a caso, ho creato uno script automatizzato (tagliando.sh) che esegue:
dnf5 update).podman system prune).smartctl).tuned impostato su throughput-performance).JARVIS non è più un semplice PC assemblato. È un server Linux moderno, sicuro e resiliente. Gestisce i dati aziendali via VPN in modo trasparente e l’intrattenimento domestico senza transcodifiche fallite.
La lezione imparata? Pellicola via il superfluo, isola i servizi nei container e usa il firewall in modo intelligente.
Generated with the support of AI
Licenza d’uso © CC BY-NC-SA
]]>Introduzione
Di recente ho deciso di prendere il controllo completo dei miei dati e del mio intrattenimento domestico. L’obiettivo? Creare un sistema che fosse stabile come una roccia, flessibile e capace di gestire tutto: Workstation per ufficio, backup su OneDrive, streaming di film in 4K, recuperando vecchi hard disk da sistemi RAID precedenti.
La mia scelta è ricaduta su Fedora Linux con KDE Plasma. Perché? Perché offre il bilanciamento perfetto tra tecnologie all’avanguardia (BTRFS, Pipewire, Wayland) e una buona stabilità
In questa guida condivido i passaggi chiave della mia configurazione, sperando possa servire da “faro” per chi vuole intraprendere lo stesso viaggio.
Le Fondamenta: Codec e Strumenti Base
Appena installata Fedora (operazione filata liscia senza intoppi e senza sbattimenti), la prima cosa da fare è “sbloccarne” il potenziale multimediale. Fedora sposa la filosofia open source pura, quindi per leggere formati proprietari (come H.265 o MP4) serve un piccolo intervento.
Ho abilitato i repository RPM Fusion e installato la versione completa di FFmpeg, fondamentale per la transcodifica video:
sudo dnf swap ffmpeg-free ffmpeg --allowerasing
sudo dnf group upgrade multimedia --setop="install_weak_deps=False" --exclude=PackageKit-gstreamer-plugin
Inoltre, ho installato KDE Connect, uno strumento che consiglio a tutti: permette di collegare il telefono Android al PC per controllare il mouse dal divano, mettere in pausa i film quando squilla il telefono e trasferire file al volo.
Il Cloud Integrato: OneDrive come se fosse una USB
Uno dei punti critici su Linux è l’assenza di un client ufficiale OneDrive. Ho risolto brillantemente usando Rclone, un tool a riga di comando potentissimo.
Invece di sincronizzare i file (occupando spazio sul disco), ho configurato un “Mount”. In pratica, Fedora vede il cloud come se fosse una chiavetta USB sempre attaccata.
Per rendere tutto automatico all’avvio senza dover aprire il terminale, ho creato un servizio Systemd personalizzato: Ini, TOML
Esempio del mio servizio ~/.config/systemd/user/rclone-onedrive.service
Unit
Description=OneDrive (Rclone)
AssertPathIsDirectory=%h/Cloud
After=network-online.target
Service
Type=notify
ExecStart=/usr/bin/rclone mount onedrive: %h/Cloud --vfs-cache-mode full --no-modtime
ExecStop=/usr/bin/fusermount -u %h/Cloud
Restart=on-failure
Install
WantedBy=default.target
Risultato? Accendo il PC e i miei file cloud sono già lì nella cartella “Cloud”.
Jellyfin e la magia di Podman
Per il media server (l’alternativa open source a Plex), non ho “sporcato” il sistema installando pacchetti a caso. Ho usato Podman.
Podman è l’alternativa a Docker nativa di Fedora: è più sicuro (non richiede permessi di root) e si integra perfettamente col sistema.
Ecco il comando che ho usato per lanciare il server, abilitando l’accelerazione hardware (/dev/dri) per non sforzare la CPU durante i film:
podman run -d \
--name jellyfin \
--label "io.containers.autoupdate=registry" \
--security-opt label=disable \
-p 8096:8096 \
-v ~/.config/jellyfin:/config \
-v ~/.cache/jellyfin:/cache \
-v /mnt/raid_jarvis:/media/jarvis \
--device /dev/dri:/dev/dri \
docker.io/jellyfin/jellyfin:latest
Nota tecnica: L’opzione --security-opt label=disable è stata fondamentale per permettere a Jellyfin di leggere i file dai miei hard disk recuperati da vecchi NAS, aggirando le restrizioni rigide di SELinux.
Gestione Storage: Recupero RAID e Futuro
La parte più delicata è stata gestire 4 hard disk SATA, alcuni provenienti da vecchi sistemi RAID (mdadm). Linux è stato eccezionale nel riconoscere automaticamente i vecchi array RAID 1, permettendomi di montarli e recuperare i dati senza perdere un bit.
Il mio piano per il futuro? Abbandonare il RAID complesso per una configurazione JBOD (Dischi indipendenti) in EXT4. Più semplice, meno rischi di rottura software, e se un disco muore, perdo solo quei dati e non tutto l’array.
Sicurezza ed Efficienza Energetica
Un server acceso h24 deve consumare poco ed essere sicuro.
Backup del Sistema: Ho configurato Timeshift (in modalità RSYNC). Fa delle “foto” al sistema operativo. Se un aggiornamento rompe qualcosa, posso tornare indietro nel tempo in 5 minuti.
Risparmio Energetico: Visto che il PC fa da server, ho usato powerprofilesctl set power-saver per calmare la CPU e hdparm per spegnere i dischi meccanici dopo 20 minuti di inattività.
Conclusione
Questa esperienza mi ha confermato che Linux oggi non è solo per smanettoni, ma è una piattaforma incredibilmente potente per gestire la propria vita digitale. Con Fedora ho un sistema che è mio al 100%, privato, veloce e costruito esattamente sulle mie esigenze.
Generated with the support of AI
Licenza d’uso © CC BY-NC-SA
]]>Anche se questo sito è rimasto dormiente per un pò, grazie all’azzeccatissima scelta di utilizzare jekyll come motore per scrivere questo sito, con pochi passaggi ho di nuovo tutto bello pronto e aggiornato all’ultima versione
Ma prima di aggiornare questo post ho dovuto riconfigurare jekyll sul mio pc, sincronizzare i repo su git e via…
Raccolgo in questa guida tutti i passaggi passo passo, da zero per un sistema funzionante su WSL Ubuntu
Installazione con rbenv (consigliato)
Aggiorna i pacchetti e installa le dipendenze
Apri il tuo terminale WSL e esegui i seguenti comandi per aggiornare la lista dei pacchetti e installare le librerie necessarie per la compilazione di Ruby
sudo apt update
sudo apt install -y build-essential libssl-dev libreadline-dev zlib1g-dev libffi-dev libyaml-dev
Installa rbenv
Clona il repository di rbenv
git clone https://github.com/rbenv/rbenv.git ~/.rbenv
Inizializza rbenv nel tuo terminale (questo aggiungerà le righe necessarie al tuo file .bashrc o .zshrc)
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(rbenv init -)"' >> ~/.bashrc
source ~/.bashrc
Installa il plugin ruby-build Questo plugin permette a rbenv di scaricare e compilare Ruby
git clone https://github.com/rbenv/ruby-build.git "$(rbenv root)"/plugins/ruby-build
Installa Ruby 3.4.6
rbenv install 3.4.6
Questo comando scaricherà e compilerà Ruby, il che potrebbe richiedere alcuni minuti.
Verifica l’installazione
Controlla che Ruby sia stato installato correttamente e che sia la versione desiderata:
ruby -v
Installa Bundler
È utile installare subito Bundler, il gestore di gemme per Ruby
gem install bundler
rbenv rehash
gem update --system
gem install bundler jekyll
rbenv rehash
jekyll -v
bundle update
bundle exec jekyll serve
Anteprima
http://127.0.0.1:4000/
Aggiorna e installa Git (in WSL)
sudo apt update && sudo apt install -y git openssh-client
Configura Git (nome/email e opzioni utili)
Sostituisci con i tuoi dati GitHub.
git config --global user.name "Nome Cognome"
git config --global user.email "la-tua-email-collegata-a-github@example.com"
git config --global init.defaultBranch main
git config --global pull.rebase false
Genera una chiave SSH in WSL (salta questo passaggio se hai già una tua chiave)
Consigliato per evitare token/password ogni volta.
ssh-keygen -t ed25519 -C "la-tua-email-collegata-a-github@example.com"
Premi Invio per accettare ~/.ssh/id_ed25519 e (facoltativo) imposta una passphrase
Avvia l’agent e carica la chiave
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
Aggiungi la chiave pubblica al tuo account GitHub
Copia la chiave
cat ~/.ssh/id_ed25519.pub
Vai su GitHub → Settings → SSH and GPG keys → New SSH key.
Incolla l’output.
(Se preferisci via CLI, puoi installare gh e fare gh auth login, ma non è necessario.)
Testa la connessione SSH a GitHub
ssh -T git@github.com
Alla prima connessione, rispondi yes. Se vedi un messaggio tipo “Hi
Scegli dove mettere il progetto e clona il repo
mkdir -p ~/progetti && cd ~/progetti
git clone git@github.com:tuorepo.git
cd progetti
Verifiche rapide
git remote -v # deve mostrare l'URL SSH
git status # stato della working tree
git add -A
git commit -m "Aggiornamenti"
git push origin main
Se hai il tuo progetto in una cartella Documenti di windows spesso il comando è un pò lungo, per velocizzare la cosa ho impostato un alias, ti mostro come fare
In WSL le directory di Windows sono in /mnt/c/
un comando tipico potrebbe essere cd “/mnt/c/Users/Francesco/Code/repo-git” (è messo tra “ “ perchè in questo modo eventuali spazi presenti nelle directory sono gestiti senza errori)
Utlizziamo gli alias per praticità
Se usi bash (default in WSL):
nano ~/.bashrc
Aggiungi l’alias in fondo al file
alias jekyll='cd "/mnt/c/Users/Francesco/Code/repo-git"'
Così il comando sarà jekyll
Ricarica la configurazione
source ~/.bashrc # o ~/.zshrc se usi zsh
D’ora in poi, ti basta digitare:
jekyll
e verrai portato direttamente nella cartella del progetto.
il build “nativo” di GitHub Pages non supporta Jekyll 4.4 (al momento GitHub Pages usa lo stack github-pages che blocca Jekyll a 3.10.x)
Per usare Jekyll 4.4 devi costruire il sito con GitHub Actions e pubblicare l’output di _site
DNS Github page A records,
185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153
AAAA records
2606:50c0:8000::153
2606:50c0:8001::153
2606:50c0:8002::153
2606:50c0:8003::153
Nel mio caso specifico:
Valore: @ Tipo: A Valore: 185.199.108.153
Valore: @ Tipo: A Valore: 185.199.109.153
Valore: @ Tipo: A Valore: 185.199.110.153
Valore: @ Tipo: A Valore: 185.199.111.153
Valore: www Tipo: CNAME Valore: francescolv.github.io
Ricordi di forzare nel pannello di ghithub HTTPS
Applicativi aggiuntivi che possono tornare utili
sudo apt-get install libmagickwand-dev
Github Page Actions non digerisce la gallery con questo metodo, quindi ho riscritto completamente la Gallery utilizzando solo HTML/CSS senza plugin esterni
Licenza d’uso © CC BY-NC-SA
]]>E’ passato veramente tanto tempo dall’ultimo post pubblicato, un pò a causa di impegni professionali, un pò perchè questo sito in jekyll hostato su github aveva qualche problema.
Allora mi sono deciso a traslocare su un server personale ed aggiornare Jekyll all’ultima versione 4.0
Devo dire che la cosa è stata abbastanza semplice avendo già una LAMP pronta, è stato sufficiente trasferire la directory _site generata con il comando jekyll build , puntare il virtual host e i DNS al nuovo server ed il gioco è fatto
E visto che la cosa mi è piaciuta, abbiamo deciso di rinnovare anche il sito www.sintab.it con jekyll - Presto online
L’unica cosa che mi rimane da capire è come sincronizzare in modo più rapido il sito locale con quello remoto, con git era veramente immediato, con FTP la cosa è un pò più macchinosa. Quando trovo una soluzione interessante ci faccio un nuovo post.
Upgrade La soluzione che ho trovato per trasferire i file sul server è attraverso il comando rsync (premesso che io ho una chiave ssh con passphrase):
Per trasferire da locale a remoto
rsync -aP -e "ssh -i /home/utente/.ssh/chiavessh" _site/ utente@IPSERVER:/home/utente/sitojekyll/
Nel server dalla directory sincronizzata con il comando precedente, sincronizzo con la directory presente in /var/www
sudo rsync -aP sitojekyll/ /var/www/sitojekyll/
Licenza d’uso © CC BY-NC-SA
]]>Creare una gallery per la pubblicazione delle Immagini e la generazione automatica di thumbnails delle foto caricate
Installare su Ubuntu le dipendenze
apt install libmagick++-dev
gem install rmagick exifr
Installare il plugin jekyll-gallery-generator o attraverso
gem install jekyll-gallery-generator
o attraverso gem 'jekyll-gallery-generator' nel file Gemfile
e lanciare il comando bundle
Aggiungere jekyll-gallery-generator nella lista dei plugin in _config.yml:
plugins:
- jekyll-gallery-generator
Crea una directory photos e al suo interno una directory per ogni gallery
Aggiungere nel file _config.yml
gallery:
dir: photos # Path to the gallery
symlink: false # false: copy images into _site. true: create symbolic links (saves disk space)
title: "Photos" # Title for gallery index page
title_prefix: "Photos: " # Title prefix for gallery pages. Gallery title = title_prefix + gallery_name
sort_field: "date_time" # How to sort galleries on the index page.
# Possible values are: title, date_time, best_image
thumbnail_size:
x: 400 # max width of thumbnails (in pixels)
y: 400 # max height of thumbnails (in pixels)
# The following options are for individual galleries.
galleries:
nome_gallery:
best_image: image.jpg # The image to show on the gallery index page. Defaults to the last image.
name: "nome_gallery"
hidden: true # Don't show this gallery on the index page. People must guess the URL.
sort_reverse: true # Reverse sort images in gallery.
info:
desc: "Gallery Description" # Info fields can be used in custom templates.
per ulteriori informazioni: https://github.com/ggreer/jekyll-gallery-generator
Licenza d’uso © CC BY-NC-SA
]]>