मैं अपने Homelab का मेंटेनेंस नहीं करता

• व्यक्तिगत Homelab चलाने का बोझ कम करने के लिए single server configuration और automatic updates पर ध्यान दिया गया है, जिससे रोज़मर्रा के ज़्यादातर maintenance काम लगभग खत्म हो गए हैं
• कई servers को एक में समेटने से environment की complexity कम हुई और server count के हिसाब से maintenance भी 75% घट गया
• Raspberry Pi 4 पर Home Assistant OS चलता है, और network में UniFi के automatic और scheduled updates पर निर्भर रहने से manual management points कम हो गए हैं
• Docker services को हफ़्ते में एक बार crontab के ज़रिए docker compose pull और docker compose up -d चलाकर अपडेट किया जाता है, जबकि root crontab मुख्य रूप से backups के लिए इस्तेमाल होता है
• अगर कोई emergency न हो, तो monthly maintenance लगभग 15 मिनट का रहता है, और apt update व reboot टालने पर भी तुरंत service impact लगभग नहीं होता

---

सरल बनाया गया इन्फ्रास्ट्रक्चर कॉन्फ़िगरेशन

• Homelab services को कई devices से समेटकर single server पर लाया गया है
  • पहले 4 servers इस्तेमाल होते थे, लेकिन अब services एक ही physical server पर रखी गई हैं
  • cluster, hypervisor, hybrid cloud की जगह basement में रखे एक physical device से सब चलाया जा रहा है
  • इस simplification से servers के हिसाब से maintenance workload 75% कम हो गया
• Raspberry Pi 4 अलग से है, लेकिन Home Assistant OS अपने updates खुद संभालता है, इसलिए management burden बहुत कम है
  • तकनीकी रूप से यह server के क़रीब है, लेकिन वास्तविक उपयोग में यह self-maintaining IoT device जैसा लगता है
• Network equipment mini rack में UniFi setup के साथ चलाया जाता है
  • इसमें UniFi Dream Machine Pro, switch और कई AP शामिल हैं
  • automatic updates और scheduled updates का support होने से network devices को भी बार-बार manually छूने की ज़रूरत नहीं पड़ती

स्वचालित software updates और backups

• Docker service updates server पर एक ही crontab entry से हर हफ़्ते चलती हैं
  • 0 0 * * 0 docker-update
  • docker-update ~/docker/*/ के नीचे हर directory में sudo docker compose pull और sudo docker compose up -d चलाता है
• root user का crontab ज़्यादातर backup के लिए है
  • यह रोज़ system report बनाता है
  • Immich और Piped के PostgreSQL dumps बनाता है
  • Plex, web server, Nginx settings, Docker directories और SSH files का ZFS pool में rsync backup करता है
  • Docker directory backup में database, cache, temporary files और कुछ log paths को exclude किया जाता है
• जो manual काम बचे हैं, वे apt update, apt upgrade, apt autoremove चलाना और ज़रूरत पड़ने पर reboot करना भर हैं
  • इन कामों में लगभग 60 सेकंड लगते हैं
• अगर कोई emergency न हो, तो maintenance time महीने में लगभग 15 मिनट रहता है
  • पूरे महीने SSH से login करके update न करने पर भी actual services पर असर नहीं पड़ता
  • 6 महीने से ज़्यादा समय तक भी बिना छुए शायद कुछ खराब न हो, लेकिन इसे जानबूझकर आज़माने की योजना नहीं है
• मौजूदा setup व्यस्त दिनचर्या में भी privacy, security, convenience के बीच संतुलन देता है

[GN⁺]

Lobste.rs की राय

• मैं अपना होम सर्वर भी लगभग इसी तरह चला रहा हूँ
  Debian पर unattended security upgrades चालू हैं, सब कुछ version-pin किए हुए rootless containers में चलता है, और systemd उन्हें Podman Quadlet के ज़रिये मैनेज करता है
  Podman का auto-update container updates संभालता है, और systemd timers backup व image cleanup जैसे दोहराए जाने वाले काम देखते हैं
  सिर्फ kernel upgrade होने पर या image version बढ़ाते समय reboot के लिए लॉग इन करता हूँ, और यह काम Ansible करता है

  • “version pinning” और “Podman auto-update” का साथ-साथ इस्तेमाल थोड़ा भ्रमित करता है
    मैंने version pinning का मतलब यह समझा था कि updates अपने-आप नहीं लाए जाते, लेकिन लगता है कि असल में updates हो रहे हैं, इसलिए साफ नहीं है कि अलग-अलग चीज़ें update हो रही हैं या नहीं
  • मैं 10 साल से ज़्यादा समय से लगभग यही setup इस्तेमाल कर रहा हूँ, और हर दो साल में latest stable पर upgrade करता हूँ
    अलग से मैनेज करने वाला सिर्फ एक router है, वह OpenBSD है, इसलिए करीब हर 6 महीने में नया version आने पर upgrade करता हूँ
    दोनों इतने stable हैं कि उबाऊ लगते हैं

• मिलता-जुलता है, लेकिन जब तक कोई feature न चाहिए हो, मैं कुछ भी update नहीं करता
  self-hosting software की अच्छी बात यह है कि मैं अपने schedule के हिसाब से update कर सकता हूँ
  अगर सब कुछ ठीक चल रहा है, सिर्फ Tailscale के ज़रिये access होता है और सीधे internet पर expose नहीं है, तो hardware failure को छोड़कर इसे ऐसे ही छोड़ देना stable रहता है

  • मुझे समझ नहीं आता कि application का सीधे internet पर expose होना और Tailscale के ज़रिये expose होना अलग क्यों है
    application तक पहुँचने वाला data आखिरकार वही होता है, तो वही vulnerabilities exploit हो सकती हैं, ऐसा लगता है

• अगर स्थिति ऐसी है तो यह काफ़ी अच्छी बात है
  मैं भी वहाँ पहुँचना चाहता हूँ, लेकिन अभी पूरी तरह नहीं पहुँच पाया हूँ
  Debian major upgrades में हर 2 साल में अब भी manual काम चाहिए: "Issues to be aware of for trixie", "Obsolescence and deprecation", "Cleanup after the upgrade"
  पुराना Ansible नए Debian systems को handle नहीं कर पाता, इसलिए Debian server upgrade करने पर Ansible version भी बढ़ाना पड़ता है और आखिर में playbooks को भी नए Ansible के हिसाब से ठीक करना पड़ता है
  अभी मैं using more Docker containers से इसे कम करने की कोशिश कर रहा हूँ, लेकिन Ansible को पूरी तरह replace करना मुश्किल लगता है
  freeDNS, dynv6.net जैसी online services भी हैं जिन्हें मैं खुद host नहीं करना चाहता, और वे भी कभी-कभी breaking changes निकालती हैं
  फिर भी कुल मिलाकर यह काफ़ी ठीक है
  सच कहें तो “maintenance-free” homelab का management असल में हम उन दुनिया भर के open source developers पर छोड़ रहे हैं जो हमारे इस्तेमाल वाले software, packages और Docker images maintain करते हैं

• अपने setup को “homelab” कहना मुझे थोड़ा झिझकाता है, लेकिन यह एक unRAID NAS है जिस पर कई Docker containers चलते हैं
  unRAID के लिए पैसे देकर भी संतुष्ट रहने की एक वजह यह है कि Docker support ठीक-ठाक अच्छा है, plugin से containers का auto-update संभव है, और बाकी maintenance भी काफ़ी simple है

• निजी तौर पर “lab” मुझे प्रयोग करने की जगह जैसा लगता है, और बात यह थोड़ी खटकती है कि प्रयोग को खुद maintain करने की ज़रूरत नहीं होती
  containers का इस्तेमाल फायदे और नुकसान दोनों लिए हुए है
  कुछ projects में container first-class distribution method है, इसलिए उस तरीके से सही updates मिल सकते हैं
  लेकिन लगता है कि बहुत से लोग ऐसे containers चला रहे हैं जिनकी maintenance अस्पष्ट है, और वहीं से काफी समस्याएँ पैदा होंगी
  मुख्य बात यह पहचानना है कि जिस software का मैं इस्तेमाल कर रहा हूँ, उसमें updates पाने का official path क्या है
  मैं ज़्यादातर RHEL clones को automatic updates के साथ चलाता हूँ, और reboot की ज़रूरत हो तो Nagios बता देता है
  अधिकतर services RHEL या EPEL के अंदर हैं, इसलिए maintenance काफ़ी कम है

• मेरे homelab maintenance के लिए pyinfra आलस की ठीक-ठाक सही सीमा साबित हुआ
  configuration process को code में लिखकर रख सकता हूँ, खासकर config files जैसी चीज़ों के लिए उपयोगी है, और nix में इसे कैसे handle करूँ जैसी चिंता किए बिना ज़रूरत पड़ने पर apt call कर सकता हूँ
  यह बहुत smart tool नहीं है, लेकिन single shell script से बेहतर है, और आगे इसे और विकसित करके देखना चाहता हूँ
  अगर agent-style coding इस्तेमाल करते हैं, तो bonus यह है कि Claude को pyinfra file दिखाकर configuration debugging में मदद ली जा सकती है

• server पर NixOS इस्तेमाल कर रहा हूँ, और जब याद आता है तो कभी-कभार update कर देता हूँ
  ज़्यादातर काम nix flake update && nix run .#deploy तक ही सीमित रहता है, इसलिए ज्यादा ध्यान नहीं देना पड़ता

• मेरी स्थिति भी बहुत मिलती-जुलती है, हालांकि मानना नहीं चाहता, लेकिन बड़ा हिस्सा आखिरकार setup के ज्यादा simple हो जाने की वजह से है
  पहले मुझे rotating logs तक वाला पूरा observability stack पसंद था, लेकिन पिछले 2 साल से ज़्यादा समय में आई सारी झंझटें उसी complexity से निकली छोटी-मोटी समस्याएँ थीं
  जैसे logs और metrics की वजह से disk भर जाना
  समाधान बहुत आसान है, लेकिन अब मैं ऐसी चीज़ें संभालना नहीं चाहता

• docker-compose setup को latest रखने के लिए मुझे Watchtower पसंद है
  https://hub.docker.com/r/nickfedor/watchtower
  versions लगातार बढ़ाते हुए भी major changes का कुछ हद तक ध्यान रख सकने वाले configuration options काफ़ी अच्छे हैं
  base operating system Debian LTS है, जिस पर सिर्फ unattended updates चालू हैं, और नया kernel आने पर reboot के लिए लॉग इन करता हूँ
  सच में बहुत काम नहीं है, और मैं इस बात से सहमत हूँ कि महीने में 15 मिनट से कम लगता है