Origine mia blog-agordo estis planita kiel pura IPv6-projekto per WireGuard, ĉar la tuto estas funkciigata sur hejma servilo (senpagajn IPv6-adresojn oni cetere ricevas ĉe route64.org). Por plibonigi la atingeblon, mi nun aldonis eksteran IPv4-prokurilon (Dankon al @Larvitz).
Tamen tuj aperis SSL-problemoj: Ĉar origine kaj la A- kaj la AAAA-rikordo iris tra la prokurilo, la validigo de Let's Encrypt malsukcesis sur mia servilo.
La solvo: La „IPv6-truko“
La solvo estis direkti la AAAA-rikordon eksplicite al la WireGuard-IP de mia servilo, anstataŭ gvidi ĝin same tra la prokurilo.
- Domanio:
blog.burningboard.org
- A-rikordo (Prokurilo):
194.28.98.217
- AAAA-rikordo (Servilo):
2a11:6c7:f05:a8::2 (WireGuard)
Per tiu rekta AAAA-rikordo al mia WireGuard-IP, Let’s Encrypt daŭre atingas mian servilon rekte per IPv6 (ĉar la AAAA-rikordo estas defaŭlte prioritatita) kaj eldonas la SSL-atestilon. La IPv4-trafiko estas plusendita al mi ĉifrite de la prokurilo.
La fina agordo
Por ke la komunikado funkciu senprobleme, ni devis adapti la Caddy-servilojn:
1. Sur mia servilo (NixOS, blog.nix)
Por ke la veraj IP-adresoj de la vizitantoj alvenu ĝuste kaj ne estu anstataŭigitaj per la IP de la prokurilo, tiu ĉi devas esti markita kiel fidinda:
services.caddy.globalConfig = ''
servers {
trusted_proxies static 2a06:9801:1c:1000::10
}
'';
2. Sur la ekstera prokurilo (Caddy)
Por ke la prokurilo ĝuste kontaktu mian servilon per HTTPS, ĝi devas kune sendi la gastigan nomon (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
}
}
La blogo nun estas atingebla per IPv4 kaj IPv6, sekure ĉifrita, kaj mia hejma IP-adreso tamen restas privata! 🚀
La plej grava afero unue: La kutimaj Markdown-dosieroj restas la bazo – mi estas simple granda fano de tiu ĉi nekomplika solvo. Sed sub la kapoto multe okazis:
Mi iom prilaboris la agordon:
📂 MD-dosieroj: La bloga strukturo restas simpla sur Markdown-bazo.
🌍 Pli tutmonda ol iam ajn: Mia blogo nun subtenas tradukojn en 43 lingvojn. Jes, inkluzive de la klingona! 🖖 (Qapla'!)
Planita estis tute aŭtomata realtempa tradukado bazita sur la retumila lingvorekono. Spolilo: Ĝi funkciis nur parte. Oni rimarkas: La KI estas impona, sed ankoraŭ ne tute "tie", kie ni ŝatus havi ĝin.
La solvo: Mi nun simple antaŭtradukas ĉiun afiŝon en ĉiujn difinitajn lingvojn, kio estas ankaŭ signife pli bona por serĉiloj (SEO). Se la aŭtomata rekono foje ne funkcias, vi povas permane agordi vian preferatan lingvon per la monda ikono, kiu poste estas tute simple konservita per kuketo.
La tradukoj nun estas farataj per Gemini 3 Flash, kio donas mirinde bonajn rezultojn. Tamen, oni devas atente kontroli la KI-on: En la unua amasa rundo, ankaŭ la etikedoj estis erare tradukitaj, kio kompreneble ne estis planita tiel.
La kodo estas ankoraŭ disponebla (simple skribu al mi mesaĝon se vi interesiĝas) 👍 Sed rimarku, ke la sistemo nun bezonas propran Gemini API-ŝlosilon 🔑.
Mi senprokraste ŝanĝis mian blogon de WriteFreely al propra evoluaĵo: MD-Blog (la MD kompreneble signifas Markdown). La kaŭzo estis malsukcesa ĝisdatigo de la malnova sistemo – sed finfine tio estis la perfekta impulso por radikale simpligi ĉion kaj gajni plenan kontrolon pri la fasonado.
La kerno estas simplaj Markdown-dosieroj en la dosierujo data/, kiuj estas konvertataj al moderna HTML dum la rultempo. La rezulto estas fulmrapida, funkcias sen datumbazo kaj, danke al propra fason-sistemo (inkluzive de malhela reĝimo), nun aspektas precize tiel, kiel mi imagis ĝin. Eĉ moderna Mastodon-kundon-butono nun estas rekte inkluzivita.
Se vi interesiĝas pri la kodo aŭ la svelta agordo, bonvolu kontakti min per Mastodon!
Fakte la ideo malantaŭ #Winboat estas bonega, sed la efektivigo ŝajnas nuntempe ankoraŭ iom malstabila. Ekde la instalado komence de la jaro la sistemo ja funkciis, sed hodiaŭ la softvaro tute rifuzis servi.
La imago subite raportis nesufiĉan ĉefmemoron (RAM). Mi ankoraŭ provis solvi la problemon mane, kio tamen bedaŭrinde definitive igis la sistemon neuzebla. Anstataŭ investi plian tempon en la serĉadon de eraroj, mi rekte transiris al la Dockurr-Windows-imago – ĉi tiu ĉiuokaze formas la teknikan bazon de Winboat.
1. Preparado
Ĉar mi uzas Podman, mi unue kreis la necesajn dosierujojn en mia gastiga sistemo. Tiel la datuma integreco restas certigita, se la kontenero devas esti rekreita:
mkdir -p $HOME/Windows/System
mkdir -p $HOME/Windows/Shared
2. La startkomando
Grava noto: Anstataŭigu en la variabloj -e USERNAME kaj -e PASSWORD la lokokupilojn per viaj personaj ensalutdatumoj.
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
Tuj kiam la kontenero estas aktiva, vi povas aliri la Windows-instancon rekte per via retumilo:
http://127.0.0.1:8006
3. Resumo
Mi devis plenumi la supre menciitan komandon nur unufoje. En la ĉiutaga funkciado, la Windows-medio nun estas tre oportune regebla per ĉi tiuj mallongaj komandoj:
- Startigi:
podman start windows
- Haltigi:
podman stop windows (aŭ malŝalti rekte ene de Windows)
- Kontroli staton:
podman ps -a
Pluaj ligiloj:
Mi instalis mian propran blogon — ĉefe por pli bone konatiĝi kun #NixOS. Surprize, ĉio okazis sufiĉe senprobleme.
WriteFreely tre bone taŭgas por tio: minimumisma, rapide agordebla kaj sen troa balasto. Perfekte por simple komenci kaj samtempe lerni ion. La agordo estas agrable klara. Kelkaj opcioj fiksitaj, dosierujo preparita, inversa prokurilo antaŭe — pretas.
Jen kiel aspektas mia aktuala NixOS-agordo por tio:
{ 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";
};
# Riparo por la generado de ActivityPub-ŝlosiloj: Federacio postulas openssl
systemd.services.writefreely.path = [ pkgs.openssl ];
# Aŭtomata kreado de la datuma dosierujo kun la ĝustaj permesoj
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}
}
'';
}
Tio estis esence ĉio. NixOS vere faciligas agordi tiajn servojn pure kaj konservi ilin reprodukteblaj.
