Blogul meu // Arhivă digitală

Inițial, configurația blogului meu a fost planificată ca un proiect pur IPv6 prin WireGuard, deoarece totul rulează pe un server de acasă (apropo, puteți obține adrese IPv6 gratuite de la route64.org). Pentru a îmbunătăți accesibilitatea, am adăugat acum un proxy IPv4 extern (mulțumesc @Larvitz).

Totuși, au apărut imediat probleme SSL: deoarece inițial atât înregistrarea A, cât și AAAA treceau prin proxy, validarea Let's Encrypt pe serverul meu a eșuat.

Soluția: „IPv6-Hack”-ul

Soluția a fost direcționarea explicită a înregistrării AAAA direct către IP-ul WireGuard al serverului meu, în loc să o trec și pe aceasta prin proxy.

• Domeniu: blog.burningboard.org
• Înregistrare A (Proxy): 194.28.98.217
• Înregistrare AAAA (Server): 2a11:6c7:f05:a8::2 (WireGuard)

Prin această înregistrare AAAA directă către IP-ul meu WireGuard, Let’s Encrypt continuă să îmi acceseze serverul direct prin IPv6 (deoarece înregistrarea AAAA este prioritizată implicit) și emite certificatul SSL. Traficul IPv4 este redirecționat către mine de către proxy, fiind criptat.

Configurația finală

Pentru ca procesul de comunicare să funcționeze fără probleme, a trebuit să ajustăm serverele Caddy:

1. Pe serverul meu (NixOS, blog.nix)

Pentru ca IP-urile reale ale vizitatorilor să ajungă corect și să nu fie suprascrise de IP-ul proxy-ului, acesta trebuie marcat ca fiind de încredere:

services.caddy.globalConfig = ''
  servers {
      trusted_proxies static 2a06:9801:1c:1000::10
  }
'';

2. Pe proxy-ul extern (Caddy)

Pentru ca proxy-ul să apeleze corect serverul meu prin HTTPS, acesta trebuie să trimită și numele de gazdă (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
    }
}

Blogul este acum accesibil prin IPv4 și IPv6, criptat în siguranță, iar IP-ul meu de acasă rămâne în continuare privat! 🚀

Cel mai important lucru de la început: fișierele Markdown obișnuite rămân baza – sunt pur și simplu un mare fan al acestei soluții simple. Dar sub capotă s-au schimbat multe:

Am făcut câteva modificări la configurare:

📂 Fișiere MD: Structura blogului rămâne simplă, bazată pe Markdown.

🌍 Mai global ca niciodată: Blogul meu suportă acum traduceri în 43 de limbi. Da, inclusiv klingoniana! 🖖 (Qapla'!)

Planul era o traducere în timp real complet automată, bazată pe recunoașterea limbii browserului. Spoiler: a funcționat doar parțial. Se observă: AI-ul este impresionant, dar nu este încă exact „acolo” unde ne-am dori să fie.

Soluția: acum traduc pur și simplu fiecare articol în prealabil în toate limbile stabilite, ceea ce este mult mai bine și pentru motoarele de căutare (SEO). Dacă recunoașterea automată nu funcționează uneori, puteți seta manual limba preferată prin intermediul pictogramei globului pământesc, care va fi apoi salvată simplu printr-un cookie.

Traducerile sunt acum realizate cu Gemini 3 Flash, care oferă rezultate surprinzător de bune. Totuși, trebuie să fii cu ochii pe AI: în prima etapă de procesare în masă, au fost traduse din greșeală și tag-urile, ceea ce, desigur, nu era planificat.

Codul este în continuare disponibil (scrieți-mi pur și simplu un mesaj dacă sunteți interesați) 👍 Rețineți însă că sistemul are nevoie acum de un propriu Gemini API Key 🔑.

Mi-am mutat rapid blogul de la WriteFreely la o soluție proprie: MD-Blog (MD vine, desigur, de la Markdown). Motivul a fost o actualizare eșuată a vechiului sistem – dar, în cele din urmă, a fost impulsul perfect pentru a simplifica totul radical și pentru a obține controlul deplin asupra designului.

Elementul central îl reprezintă fișierele Markdown simple din folderul data/, care sunt convertite în HTML modern în timpul rulării. Rezultatul este extrem de rapid, funcționează fără bază de date și, datorită propriului sistem de design (inclusiv Dark Mode), arată acum exact așa cum mi-am imaginat. Chiar și un buton de partajare Mastodon modern este acum integrat direct.

Dacă sunteți interesați de cod sau de configurarea simplificată, nu ezitați să mă contactați pe Mastodon!

În principiu, ideea din spatele #Winboat este excelentă, însă implementarea pare să fie încă puțin instabilă în prezent. De la instalarea de la începutul anului, sistemul a funcționat, dar astăzi software-ul a refuzat complet să mai pornească.

Imaginea a raportat brusc memorie RAM insuficientă. Am încercat să remediez problema manual, ceea ce, din păcate, a făcut sistemul definitiv inutilizabil. În loc să investesc mai mult timp în depanare, am trecut direct la imaginea Windows Dockurr – aceasta constituie oricum baza tehnică a Winboat.

1. Pregătire

Deoarece folosesc Podman, am creat mai întâi directoarele necesare pe sistemul meu gazdă. Astfel, integritatea datelor este menținută în cazul în care containerul trebuie recreat:

mkdir -p $HOME/Windows/System
mkdir -p $HOME/Windows/Shared

2. Comanda de pornire

Notă importantă: În variabilele -e USERNAME și -e PASSWORD, înlocuiește substituenții cu datele tale personale de acces.

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

Imediat ce containerul este activ, poți accesa instanța de Windows direct prin browser:

http://127.0.0.1:8006

3. Rezumat

A trebuit să execut comanda de mai sus o singură dată. În utilizarea zilnică, mediul Windows poate fi acum controlat foarte confortabil prin aceste comenzi scurte:

• Pornire: podman start windows
• Oprire: podman stop windows (sau închidere directă din Windows)
• Verificare status: podman ps -a

Link-uri utile:

• Imaginea utilizată: GitHub - dockur/windows
• Aplicația originală: Winboat.app
• Pagina proiectului Podman: Podman

Mi-am instalat propriul blog — în principal pentru a cunoaște mai bine #NixOS. Surprinzător, totul a decurs destul de simplu.

WriteFreely se potrivește de minune pentru asta: minimalist, rapid de configurat și fără balast inutil. Perfect pentru a începe pur și simplu și pentru a învăța ceva pe parcurs. Configurația este plăcut de clară. Câteva opțiuni setate, directorul pregătit, un reverse proxy în față — gata.

Iată cum arată configurația mea actuală de NixOS pentru acest lucru:

{ 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 pentru generarea cheilor ActivityPub: Federația necesită openssl
  systemd.services.writefreely.path = [ pkgs.openssl ];

  # Crearea automată a directorului de date cu permisiunile corecte
  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}
    }
  '';
}

Asta a fost, în esență. NixOS face cu adevărat simplă configurarea curată a unor astfel de servicii și menținerea lor reproductibilă.