Inizialmente, il setup del mio blog era stato pianificato come un progetto puramente IPv6 tramite WireGuard, poiché il tutto gira su un server domestico (a proposito, è possibile ottenere indirizzi IPv6 gratuiti su route64.org). Per migliorare l'accessibilità, ho aggiunto un proxy IPv4 esterno (grazie a @Larvitz).
Tuttavia, sono sorti immediatamente dei problemi con l'SSL: poiché originariamente sia il record A che quello AAAA passavano attraverso il proxy, la validazione di Let's Encrypt sul mio server falliva.
La soluzione: l'"IPv6-Hack"
La soluzione è stata puntare esplicitamente il record AAAA direttamente sull'IP WireGuard del mio server, invece di instradarlo anch'esso attraverso il proxy.
- Dominio:
blog.burningboard.org
- Record A (Proxy):
194.28.98.217
- Record AAAA (Server):
2a11:6c7:f05:a8::2 (WireGuard)
Grazie a questo record AAAA diretto verso il mio IP WireGuard, Let’s Encrypt continua a raggiungere il mio server direttamente via IPv6 (dato che il record AAAA ha la priorità per impostazione predefinita) ed emette il certificato SSL. Il traffico IPv4 viene inoltrato dal proxy a me in modo crittografato.
La configurazione finale
Per far sì che la comunicazione funzioni senza intoppi, abbiamo dovuto adattare i server Caddy:
1. Sul mio server (NixOS, blog.nix)
Affinché i veri IP dei visitatori arrivino correttamente e non vengano sovrascritti dall'IP del proxy, quest'ultimo deve essere contrassegnato come affidabile:
services.caddy.globalConfig = ''
servers {
trusted_proxies static 2a06:9801:1c:1000::10
}
'';
2. Sul proxy esterno (Caddy)
Affinché il proxy contatti correttamente il mio server tramite HTTPS, deve inviare l'hostname (SNI):
reverse_proxy [https://[2a11:6c7:f05:a8::2]:443](https://[2a11:6c7:f05:a8::2]:443) {
header_up Host {host}
transport http {
tls_server_name blog.burningboard.org
}
}
Il blog è ora raggiungibile tramite IPv4 e IPv6, crittografato in modo sicuro, e il mio IP di casa rimane comunque privato! 🚀
La cosa più importante innanzitutto: i soliti file Markdown rimangono la base – sono semplicemente un grande fan di questa soluzione semplice. Ma sotto il cofano sono cambiate molte cose:
Ho messo mano al setup:
📂 File MD: la struttura del blog rimane semplice, basata su Markdown.
🌍 Più globale che mai: il mio blog ora supporta traduzioni in 43 lingue. Sì, incluso il Klingon! 🖖 (Qapla'!)
L'idea era una traduzione in tempo reale completamente automatica basata sul rilevamento della lingua del browser. Spoiler: ha funzionato solo in parte. Si nota che l'IA è impressionante, ma non è ancora del tutto "lì" dove vorremmo che fosse.
La soluzione: ora traduco semplicemente ogni post in anticipo in tutte le lingue stabilite, il che è anche decisamente meglio per i motori di ricerca (SEO). Se il rilevamento automatico non dovesse funzionare, potete impostare manualmente la vostra lingua preferita tramite l'icona del mappamondo, che verrà poi salvata in modo molto semplice tramite cookie.
Le traduzioni vengono ora eseguite con Gemini 3 Flash, che fornisce risultati sorprendentemente buoni. Tuttavia, bisogna tenere d'occhio l'IA: nel primo passaggio in blocco, sono stati erroneamente tradotti anche i tag, cosa che ovviamente non era prevista.
Il codice è ancora disponibile (scrivetemi pure se siete interessati) 👍 Tenete presente però che il sistema ora richiede una propria chiave API Gemini 🔑.
Ho deciso di migrare il mio blog da WriteFreely a una soluzione sviluppata da me: MD-Blog (dove MD sta ovviamente per Markdown). La scintilla è stata un aggiornamento fallito del vecchio sistema – ma alla fine è stato lo stimolo perfetto per semplificare tutto radicalmente e ottenere il pieno controllo sul design.
Il cuore del sistema sono dei semplici file Markdown nella cartella data/, che vengono convertiti in HTML moderno durante l'esecuzione. Il risultato è velocissimo, non richiede un database e, grazie a un sistema di design personalizzato (inclusa la modalità scura), ha esattamente l'aspetto che immaginavo. C'è persino un moderno pulsante di condivisione per Mastodon integrato direttamente.
Se siete interessati al codice o alla configurazione snella, contattatemi pure su Mastodon!
In realtà, l'idea alla base di #Winboat è eccellente, ma l'implementazione sembra essere ancora un po' instabile al momento. Dall'installazione all'inizio dell'anno il sistema ha funzionato, ma oggi il software ha smesso completamente di rispondere.
L'immagine ha improvvisamente segnalato memoria insufficiente (RAM). Ho provato a risolvere il problema manualmente, ma purtroppo questo ha reso il sistema definitivamente inutilizzabile. Invece di investire altro tempo nella risoluzione dei problemi, sono passato direttamente all'immagine Windows di Dockurr, che costituisce comunque la base tecnica di Winboat.
1. Preparazione
Poiché utilizzo Podman, ho innanzitutto creato le directory necessarie sul mio sistema host. In questo modo l'integrità dei dati viene preservata nel caso in cui il container debba essere ricreato:
mkdir -p $HOME/Windows/System
mkdir -p $HOME/Windows/Shared
2. Il comando di avvio
Nota importante: Sostituisci i segnaposto nelle variabili -e USERNAME e -e PASSWORD con le tue credenziali personali.
podman run -d \
--name windows \
-p 8006:8006 \
--device=/dev/kvm \
--cap-add NET_ADMIN \
-e RAM_SIZE="8G" \
-e USERNAME="Carsten" \
-e PASSWORD="1234" \
-e LANGUAGE="German" \
-v $HOME/Windows/System:/storage:Z \
-v $HOME/Windows/Shared:/shared:Z \
--stop-timeout 120 \
dockurr/windows
Appena il container è attivo, puoi accedere all'istanza di Windows direttamente tramite il tuo browser:
http://127.0.0.1:8006
3. Riepilogo
Ho dovuto eseguire il comando sopra menzionato solo una volta. Nell'uso quotidiano, l'ambiente Windows può ora essere controllato comodamente tramite questi comandi rapidi:
- Avvio:
podman start windows
- Arresto:
podman stop windows (o spegnimento direttamente all'interno di Windows)
- Verifica stato:
podman ps -a
Link utili:
Ho installato il mio blog personale, soprattutto per conoscere meglio #NixOS. Sorprendentemente, è stato tutto piuttosto semplice.
WriteFreely è perfetto per questo scopo: minimalista, rapido da configurare e senza troppi fronzoli. L'ideale per iniziare subito e imparare qualcosa nel frattempo. La configurazione è piacevolmente chiara. Qualche opzione impostata, directory preparata, un reverse proxy davanti — ed è fatta.
Ecco come appare la mia attuale configurazione NixOS:
{ config, pkgs, ... }:
{
services.writefreely = {
enable = true;
host = "blog.burningboard.org";
settings = {
server = {
port = 8080;
min_log_level = "debug";
};
app = {
host = "https://blog.burningboard.org";
single_user = true;
landing = "/read";
wf_modesty = true;
federation = true;
public_stats = true;
theme = "write";
};
};
stateDir = "/opt/writefreely";
};
# Fix per la generazione delle chiavi ActivityPub: la federazione richiede openssl
systemd.services.writefreely.path = [ pkgs.openssl ];
# Creazione automatica della directory dei dati con i permessi corretti
systemd.tmpfiles.rules = [
"d /opt/writefreely 0700 writefreely writefreely -"
];
services.caddy.virtualHosts."blog.burningboard.org".extraConfig = ''
reverse_proxy 127.0.0.1:8080 {
header_up Host {host}
header_up X-Real-IP {remote_host}
header_up X-Forwarded-For {remote_host}
header_up X-Forwarded-Proto {scheme}
}
'';
}
Questo è essenzialmente tutto. NixOS rende davvero semplice configurare tali servizi in modo pulito e mantenerli riproducibili.
