मेरा ब्लॉग // डिजिटल आर्काइव

विचार, परियोजनाएं और तकनीकी नोट्स

मूल रूप से, मेरा ब्लॉग सेटअप वायरगार्ड (WireGuard) के माध्यम से एक शुद्ध IPv6-प्रोजेक्ट के रूप में नियोजित किया गया था, क्योंकि यह सब एक होम सर्वर पर चलता है (वैसे, आप route64.org पर मुफ्त IPv6 पते प्राप्त कर सकते हैं)। पहुंच बढ़ाने के लिए, मैंने अब एक बाहरी IPv4 प्रॉक्सी जोड़ा है (धन्यवाद @Larvitz)।

हालांकि, इसमें तुरंत SSL समस्याएं आईं: चूंकि मूल रूप से A और AAAA रिकॉर्ड दोनों प्रॉक्सी के माध्यम से चल रहे थे, इसलिए मेरे सर्वर पर Let's Encrypt सत्यापन (validation) विफल हो गया।

समाधान: "IPv6-हैक"

समाधान यह था कि AAAA-रिकॉर्ड को प्रॉक्सी के माध्यम से भेजने के बजाय स्पष्ट रूप से सीधे मेरे सर्वर के वायरगार्ड आईपी (WireGuard-IP) पर निर्देशित किया जाए।

  • Domain: blog.burningboard.org
  • A-Record (Proxy): 194.28.98.217
  • AAAA-Record (Server): 2a11:6c7:f05:a8::2 (WireGuard)

मेरी वायरगार्ड आईपी पर इस सीधे AAAA-रिकॉर्ड के माध्यम से, Let’s Encrypt अभी भी सीधे IPv6 के माध्यम से मेरे सर्वर तक पहुँचता है (क्योंकि AAAA-रिकॉर्ड को डिफ़ॉल्ट रूप से प्राथमिकता दी जाती है) और SSL प्रमाणपत्र जारी करता है। IPv4 ट्रैफ़िक प्रॉक्सी द्वारा एन्क्रिप्ट किया जाता है और मुझे भेज दिया जाता है।

अंतिम कॉन्फ़िगरेशन

यह सुनिश्चित करने के लिए कि संचार सुचारू रूप से चले, हमें Caddy सर्वर को समायोजित करना पड़ा:

1. मेरे सर्वर पर (NixOS, blog.nix)

यह सुनिश्चित करने के लिए कि वास्तविक विज़िटर आईपी सही ढंग से पहुँचें और प्रॉक्सी के आईपी द्वारा ओवरराइट न हों, इसे विश्वसनीय (trusted) के रूप में चिह्नित किया जाना चाहिए:

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

2. बाहरी प्रॉक्सी पर (Caddy)

प्रॉक्सी मेरे सर्वर को HTTPS के माध्यम से सही ढंग से संबोधित करे, इसके लिए उसे होस्टनाम (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
    }
}

ब्लॉग अब IPv4 और IPv6 के माध्यम से उपलब्ध है, सुरक्षित रूप से एन्क्रिप्टेड है और मेरा होम आईपी अभी भी निजी रहता है! 🚀

सबसे महत्वपूर्ण बात: सामान्य Markdown फाइलें आधार बनी रहेंगी – मैं बस इस सरल समाधान का बहुत बड़ा प्रशंसक हूँ। लेकिन पर्दे के पीछे बहुत कुछ बदल गया है:

मैंने सेटअप में काफी बदलाव किए हैं:

📂 MD-फाइलें: ब्लॉग संरचना मार्कडाउन-आधारित सरल बनी हुई है।

🌍 पहले से कहीं अधिक वैश्विक: मेरा ब्लॉग अब 43 भाषाओं में अनुवाद का समर्थन करता है। हाँ, क्लिंगन (Klingon) सहित! 🖖 (Qapla'!)

योजना ब्राउज़र भाषा पहचान के आधार पर पूरी तरह से स्वचालित रीयल-टाइम अनुवाद की थी। स्पॉइलर: इसने केवल आंशिक रूप से काम किया। आप देख सकते हैं: एआई प्रभावशाली है, लेकिन अभी तक पूरी तरह से "वहाँ" नहीं है जहाँ हम इसे देखना चाहते हैं।

समाधान: अब मैं बस हर पोस्ट का पहले से ही सभी निर्धारित भाषाओं में अनुवाद कर देता हूँ, जो सर्च इंजन (SEO) के लिए भी काफी बेहतर है। यदि स्वचालित पहचान कभी काम नहीं करती है, तो आप ग्लोब आइकन के माध्यम से अपनी पसंदीदा भाषा मैन्युअल रूप से सेट कर सकते हैं, जो फिर कुकी (Cookie) के माध्यम से आसानी से सहेज ली जाएगी।

अनुवाद अब Gemini 3 Flash के साथ किए जाते हैं, जो आश्चर्यजनक रूप से अच्छे परिणाम देता है। हालाँकि, एआई पर कड़ी नज़र रखनी चाहिए: पहले बल्क रन में, टैग्स का भी गलती से अनुवाद कर दिया गया था, जो निश्चित रूप से योजना का हिस्सा नहीं था।

कोड अभी भी उपलब्ध है (यदि रुचि हो तो बस मुझे एक संदेश लिखें) 👍 लेकिन ध्यान दें कि सिस्टम को अब अपनी खुद की Gemini API Key 🔑 की आवश्यकता है।

मैंने बिना किसी देरी के अपने ब्लॉग को WriteFreely से हटाकर खुद के बनाए हुए सिस्टम पर स्विच कर लिया है: MD-Blog (यहाँ MD का मतलब निश्चित रूप से Markdown है)। इसकी शुरुआत पुराने सिस्टम के एक असफल अपडेट से हुई थी – लेकिन अंत में, यह सब कुछ पूरी तरह से सरल बनाने और डिज़ाइन पर पूरा नियंत्रण पाने का एक बेहतरीन अवसर साबित हुआ।

इसका मुख्य हिस्सा data/ फ़ोल्डर में मौजूद साधारण Markdown फ़ाइलें हैं, जिन्हें रनटाइम के दौरान आधुनिक HTML में बदल दिया जाता है। इसका परिणाम बिजली जैसा तेज़ है, इसमें किसी डेटाबेस की ज़रूरत नहीं है और खुद के डिज़ाइन सिस्टम (डार्क मोड सहित) की बदौलत अब यह बिल्कुल वैसा ही दिखता है जैसा मैंने सोचा था। यहाँ तक कि अब इसमें एक आधुनिक Mastodon-Share-Button भी सीधे शामिल है।

अगर आप कोड या इस हल्के सेटअप में रुचि रखते हैं, तो बेझिझक Mastodon पर मुझसे संपर्क करें!

वास्तव में #Winboat के पीछे का विचार उत्कृष्ट है, लेकिन वर्तमान में इसका कार्यान्वयन थोड़ा अस्थिर लगता है। साल की शुरुआत में इंस्टॉलेशन के बाद से सिस्टम ठीक चल रहा था, लेकिन आज सॉफ्टवेयर ने पूरी तरह से काम करना बंद कर दिया।

इमेज ने अचानक अपर्याप्त मेमोरी (RAM) की सूचना दी। मैंने समस्या को मैन्युअल रूप से ठीक करने की कोशिश की, लेकिन दुर्भाग्य से इससे सिस्टम पूरी तरह से अनुपयोगी हो गया। समस्या निवारण (troubleshooting) में और समय बर्बाद करने के बजाय, मैं सीधे Dockurr Windows-Image पर स्विच कर गया – वैसे भी यह Winboat का तकनीकी आधार है।

Fehlermeldung

1. तैयारी

चूंकि मैं Podman का उपयोग करता हूं, इसलिए मैंने सबसे पहले अपने होस्ट सिस्टम पर आवश्यक निर्देशिकाएं (directories) बनाईं। इससे डेटा की अखंडता बनी रहती है, यदि कंटेनर को फिर से बनाने की आवश्यकता हो:

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

2. स्टार्टअप कमांड

महत्वपूर्ण नोट: वेरिएबल -e USERNAME और -e PASSWORD में प्लेसहोल्डर्स को अपने व्यक्तिगत लॉगिन विवरण से बदलें।

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

जैसे ही कंटेनर सक्रिय हो जाता है, आप सीधे अपने ब्राउज़र के माध्यम से विंडोज इंस्टेंस को एक्सेस कर सकते हैं:

http://127.0.0.1:8006

Laufender Container

3. सारांश

मुझे ऊपर दिए गए कमांड को केवल एक बार चलाने की आवश्यकता थी। दैनिक संचालन में, विंडोज वातावरण को अब इन शॉर्टकट कमांड के माध्यम से आसानी से नियंत्रित किया जा सकता है:

  • शुरू करना: podman start windows
  • रोकना: podman stop windows (या सीधे विंडोज के भीतर से शटडाउन करें)
  • स्थिति जांचें: podman ps -a

उपयोगी लिंक:

मैंने अपना खुद का ब्लॉग इंस्टॉल किया है — मुख्य रूप से #NixOS को बेहतर ढंग से समझने के लिए। आश्चर्यजनक रूप से, यह सब काफी सरल था।

WriteFreely इसके लिए वास्तव में अच्छा है: न्यूनतम, सेटअप करने में तेज़ और बिना किसी फालतू तामझाम के। बस शुरुआत करने और साथ-साथ कुछ सीखने के लिए यह एकदम सही है। इसका कॉन्फ़िगरेशन काफी स्पष्ट है। कुछ विकल्प सेट किए, डायरेक्टरी तैयार की, रिवर्स प्रॉक्सी लगाया — और बस हो गया।

इसके लिए मेरा वर्तमान 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";
  };

  # ActivityPub की जनरेशन के लिए फिक्स: फेडरेशन के लिए openssl की आवश्यकता है
  systemd.services.writefreely.path = [ pkgs.openssl ];

  # सही अनुमतियों (permissions) के साथ डेटा डायरेक्टरी का स्वचालित निर्माण
  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}
    }
  '';
}

बस इतना ही था। NixOS ऐसी सेवाओं को सफाई से कॉन्फ़िगर करना और उन्हें प्रतिलिपि योग्य (reproducible) बनाए रखना वास्तव में आसान बनाता है।