Mia Blogo // Digita arkivo

Pensoj, projektoj kaj teknikaj notoj

Montri afiŝojn kun etikedo: #md-blog Montri ĉiujn ×

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!