Ubuntu 16.04 पर 10 साल तक ब्लॉग चलाने के बाद उसे FreeBSD पर माइग्रेट किया

 (crocidb.com)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Ubuntu 16.04 LTS आधारित DigitalOcean VPS सपोर्ट समाप्त होने और सुरक्षा जोखिम के बावजूद अंत तक 1491 दिनों का uptime बनाए रखा
  • नया सर्वर जर्मनी के Hetzner VPS और FreeBSD 14.3 पर माइग्रेट किया गया, और पहले के $13 प्रति माह वाले सर्वर से बेहतर स्पेक्स 6 यूरो प्रति माह से कम में मिले
  • Jails और Bastille के साथ साइट-वार isolate किए गए environment बनाए गए, जहाँ Caddy Jail SSL और reverse proxy संभालकर हर nginx Jail तक ट्रैफ़िक भेजता है
  • लोड टेस्ट में नए FreeBSD सर्वर ने 10,000 concurrent connections के लिए kern.ipc.somaxconn समायोजित करने के बाद request throughput में 3 से 11 गुना बेहतर प्रदर्शन किया
  • इस बदलाव में networking और FreeBSD configuration सीखना पड़ा, लेकिन centralized configuration और अच्छी documentation की वजह से सेटअप उम्मीद से आसान रहा

माइग्रेशन की पृष्ठभूमि

  • मौजूदा ब्लॉग DigitalOcean VPS पर 10 साल से अधिक समय तक चलाया गया था, और New York data center के Ubuntu 16.04 LTS का उपयोग करता था
    • Ubuntu 16.04 LTS का सपोर्ट कम से कम 5 साल पहले समाप्त हो चुका था, और उसे apt package repository updates नहीं मिल रहे थे
    • पुराना सिस्टम सुरक्षा के लिहाज़ से नुकसानदेह था, और पहले एक अलग WordPress ब्लॉग पर पुराने VPS में casino और gambling links injection attack भी हुआ था
  • मौजूदा सर्वर ब्लॉग के अलावा कुछ और साइट्स भी serve करता था, लेकिन उनमें से ज़्यादातर static sites थीं
    • सबसे लोकप्रिय ब्लॉग भी आम तौर पर महीने में कुछ हज़ार pageviews तक ही जाता था, और ट्रैफ़िक सिर्फ़ तब बढ़ता था जब Hacker News पर कुछ पोस्ट viral हो जाती थीं
    • सर्वर nginx/1.10.3 से static files serve करता था, और site-specific configuration /etc/nginx/sites-available में थी
    • ब्लॉग Hugo से generate होता था, और पुरानी deployment प्रक्रिया local writing → repository commit·push → server पर SSH login → repository pull → hugo run थी
  • शुरुआती दिनों में यह VPS testing और programming के लिए भी इस्तेमाल हुआ था, इसलिए उस पर काफी पुराना software बचा हुआ था
    • इसके बावजूद यह ठीक से काम करता रहा, और बंद किए जाने के समय इसका uptime 1491 दिन था, यानी लगभग 4 साल तक बिना reboot के चला
  • नया सर्वर जर्मनी के Hetzner VPS पर शिफ्ट किया गया, जो पुराने सर्वर से अधिक शक्तिशाली था और उसकी मासिक लागत आधे से भी कम थी
    • पुराना DigitalOcean सर्वर 2GB RAM, 1 vCPU, 50GB disk, 2TB monthly traffic, और $13 प्रति माह पर था
    • Hetzner का सबसे सस्ता सर्वर भी पुराने से दोगुनी memory और CPU देता था, storage थोड़ा कम था लेकिन traffic 10 गुना था
    • अंततः चुना गया Hetzner configuration 6 यूरो प्रति माह से कम में और बेहतर specs देता था

FreeBSD चुनने की वजह

  • FreeBSD को इसलिए चुना गया क्योंकि नए सिस्टम को वास्तविक production environment में आज़माना था
    • इसके integrated design, stability, security, और Jails को प्रमुख फायदे माना गया
  • Jails FreeBSD में 25 साल से अधिक समय से मौजूद virtualization और containerization feature है
    • इससे ऐसे “mini systems” sandbox की तरह चलाए जा सकते हैं जो host system तक पहुँच नहीं रखते
    • Docker जैसे container solutions program packaging के लिए अधिक उपयुक्त होते हैं और अक्सर ephemeral तथा immutable प्रकृति के होते हैं, जबकि Jails shared kernel वाले subsystem या mini VM की तरह उपयोग किए जाते हैं
  • ZFS भी server filesystem के रूप में एक आकर्षक विकल्प था
    • इसमें data integrity और snapshot features हैं, और कुछ हद तक Linux के Btrfs जैसा है
    • ZFS को Btrfs की तुलना में कहीं अधिक mature माना गया, और बार-बार snapshots लेने पर VPS provider के paid snapshot या backup system पर निर्भरता कम हो सकती थी
  • लक्ष्य architecture यह था कि हर site के लिए एक Jail हो, और उस Jail में ज़रूरी build tools तथा nginx मौजूद हों
    • main web server वाला Jail बाहरी दुनिया से जुड़ने वाले reverse proxy की भूमिका निभाता
    • अगर किसी खास Jail में compromise होता, तो उस Jail को हटाकर नया बनाया जा सकता था

FreeBSD इंस्टॉलेशन और Bastille का उपयोग

  • Hetzner के VM creation screen पर default OS images सीमित थीं, इसलिए BSD सीधे दिखाई नहीं दिया
    • FreeBSD के आधिकारिक YouTube चैनल की Hetzner installation video का सहारा लिया गया
    • Hetzner FreeBSD ISO image देता है, लेकिन VM बनने के बाद console के ISO Images tab में जाकर उसे mount करना पड़ता है
    • इंस्टॉलेशन के लिए FreeBSD 14.3 ISO का इस्तेमाल किया गया, और सिस्टम सेटअप के लिए आधिकारिक वीडियो का flow follow किया गया
  • Bastille को Jails management आसान बनाने के लिए चुना गया
    • manual Jail creation में लगने वाले कई steps को bastille command से संभाला जा सकता है
    • उदाहरण commands हैं bastille list, bastille create, bastille console
    • इंस्टॉलेशन और enable करने की प्रक्रिया Bastille getting started documentation के अनुसार की गई
pkg install bastille
sysrc bastille_enable="YES"

नेटवर्क और reverse proxy architecture

  • पूरा stack इस तरह बनाया गया कि एक Caddy Jail सभी domains और SSL certificates संभाले, और site-specific Jails तक traffic reverse proxy करे
    • हर site Jail में सिर्फ़ वही tools रखे गए जो site को build और serve करने के लिए ज़रूरी थे
    • इसे एक ही network में चल रही कई virtual machines जैसी संरचना माना जा सकता है
  • internal virtual network interface bastille0 बनाया गया
sudo sysrc cloned_interfaces+="lo1"
sudo sysrc ifconfig_lo1_name="bastille0"
sudo service netif cloneup
sudo sysrc ifconfig_bastille0="inet 10.0.0.1 netmask 255.255.255.0"
  • loopback interface को clone करके bastille0 नाम दिया गया और 10.0.0.1/24 network assign किया गया
  • Jails इसी network interface पर चलते हैं
  • बाहरी HTTP और HTTPS requests को PF(Packet Filter) rules के जरिए Caddy Jail तक भेजा गया
    • /etc/pf.conf में external interface vtnet0, internal interface bastille0, और tailscale1 configure थे
    • 80, 443 port का traffic Caddy server बनने वाले 10.0.0.5 पर redirect किया गया
ext_if = "vtnet0"
int_if = "bastille0"
vpn_if = "tailscale1"
set skip on $int_if
set skip on $vpn_if
nat on $ext_if from 10.0.0.0/24 to any -> ($ext_if)
rdr pass on $ext_if proto tcp from any to any port {80, 443} -> 10.0.0.5
block all
pass out quick on $ext_if keep state
  • PF और gateway को इन commands से enable किया गया
sysrc pf_enable="YES"
service pf start
sysrc gateway_enable="YES"

Caddy और साइट-वार Jail configuration

  • पुराने सर्वर पर लंबे समय तक nginx इस्तेमाल हुआ था, लेकिन नए setup में SSL certificate management automate करने के लिए Caddy चुना गया
    • पुराने nginx environment में certbot से certificates को समय-समय पर renew करना पड़ता था, और renewal कई बार छूट भी गया था
  • Caddy Jail बनाने से पहले FreeBSD release को Bastille में bootstrap किया गया
bastille bootstrap 14.3-RELEASE
  • Caddy Jail 10.0.0.5 IP पर बनाया गया
bastille create caddy 14.3-RELEASE 10.0.0.5 bastille0
bastille start caddy
  • Jail का नाम caddy, release 14.3-RELEASE, और interface bastille0 था
  • bastille list से running status देखा जा सकता है, और bastille console caddy से Jail के अंदर shell में प्रवेश किया जा सकता है
  • Caddy installation और service enable करना Jail के अंदर किया गया
pkg install caddy
sysrc caddy_enable="YES"
service caddy start
  • Caddy configuration file Jail के अंदर /usr/local/etc/caddy/Caddyfile में है
    • अगर host से config file manage करनी हो, तो host directory को Jail के अंदर mount किया जा सकता है
    • उदाहरण में nullfs और read-only ro option से mount किया गया ताकि Caddy config बदल न सके
bastille mount caddy /usr/local/etc/my-caddy-config /usr/local/etc/caddy nullfs ro 0 0

साइट और ब्लॉग deployment

  • पहला deployment target es.cro.to था, और site repository GitHub repository में manage की जाती थी
    • repository को host के /usr/local/www/escroto में रखा गया, और site Jail में वही directory read-only रूप में mount की गई
    • सभी sites को host के /usr/local/www के नीचे रखने का pattern अपनाया गया
  • escroto Jail को nginx Bastille template से बनाया गया
bastille bootstrap https://github.com/bastillebsd/templates
bastille create escroto 14.3-RELEASE 10.0.0.11 bastille0
bastille template escroto www/nginx
  • IP 10.0.0.11 रखा गया
  • FreeBSD convention के अनुसार nginx default page /usr/local/www/nginx से serve होती है
  • host की site directory को Jail में read-only mount किया गया
bastille mount escroto /usr/local/www/escroto /usr/local/www/escroto nullfs ro 0 0
  • repository की .git directory वेब पर expose न हो, इसके लिए deployment script का इस्तेमाल किया गया
rm -fr /usr/local/www/nginx/*
cp -R /usr/local/www/escroto/* /usr/local/www/nginx/
rm -fr /usr/local/www/nginx/.git
  • नए version का deployment host पर repository update करने के बाद Jail के अंदर deployment script चलाकर किया जाता था
cd /usr/local/www/escroto
git pull
bastille cmd escroto /root/deploy.sh
  • Caddy configuration cro.to को स्थायी रूप से es.cro.to पर redirect करती है, और es.cro.to को 10.0.0.11 पर proxy करती है
cro.to {
    redir https://es.cro.to{uri} permanent
}
es.cro.to {
    reverse_proxy 10.0.0.11
}
  • ब्लॉग Hugo का उपयोग करता है और GitHub repository में manage किया जाता है
    • repository को host के /usr/local/www/blog में clone किया गया
    • blog Jail को escroto की तरह ही बनाया गया, और IP 10.0.0.12 रखा गया
bastille create blog 14.3-RELEASE 10.0.0.12 bastille0
bastille template blog www/nginx
bastille mount blog /usr/local/www/blog /usr/local/www/blog nullfs ro 0 0
  • Hugo को blog Jail के अंदर install किया गया
bastille pkg blog update
bastille pkg blog install gohugo
  • ब्लॉग deployment script nginx web root खाली करके Hugo output को /usr/local/www/nginx में generate करती है
rm -fr /usr/local/www/nginx/*
cd /usr/local/www/blog
hugo -d /usr/local/www/nginx
  • DNS बदलने से पहले पुराने domain की जगह crocidb.cro.to को नए ब्लॉग सर्वर से जोड़कर test किया गया
crocidb.cro.to {
    reverse_proxy 10.0.0.12
}

बेंचमार्क और लोड टेस्ट

  • DNS records बदलने से पहले पुराने सर्वर crocidb.com और नए सर्वर crocidb.cro.to की load handling क्षमता की तुलना की गई
    • ब्लॉग के visitors मुख्य रूप से North America से आते थे, उसके बाद Europe और South America से, इसलिए नए Germany सर्वर की latency कुछ users के लिए थोड़ा अधिक हो सकती थी
    • मुख्य रुचि static site serving की speed और high load संभालने की क्षमता में थी
  • GTMetrix, Pingdom, WebPageTest जैसे मुफ्त online tools भी इस्तेमाल किए गए, लेकिन दोनों सर्वरों के बीच अंतर ज़्यादातर latency तक ही सीमित दिखा
  • HTTP load benchmark tools के रूप में wrk और hey का उपयोग किया गया
    • ये दोनों tools बड़ी संख्या में concurrent requests भेजते हैं और request latency, error responses, throughput आदि collect करते हैं
  • उसी Hetzner के एक दूसरे VPS से wrk चलाने पर नया सर्वर काफ़ी आगे निकला
wrk -t4 -c100 -d30s --latency https://crocidb.com/
  • options थे 4 threads, 100 concurrent connections, और 30 seconds duration
  • पुराने सर्वर का average latency 89.63ms, requests per second 833.41, throughput 8.29MB/s था
  • नए सर्वर का average latency 6.75ms, requests per second 12260.10, throughput 130.80MB/s था
  • test machine उसी data center में थी जहाँ नया सर्वर था, इसलिए तुलना पूरी तरह निष्पक्ष नहीं थी
  • Proton VPN के ज़रिए अलग-अलग regions से wrk चलाने की कोशिश भी की गई, लेकिन परिणाम उम्मीद से कमज़ोर रहे
    • पुराने सर्वर का average लगभग 300 requests per second रहा, और नया सर्वर लगभग 800 requests per second तक पहुँचा
    • अंततः सामान्य user VPN की बजाय अलग-अलग regions में वास्तविक VPS बनाने का फैसला किया गया

Vultr VPS आधारित region-wise test

  • DigitalOcean और Hetzner से अलग infrastructure इस्तेमाल करने के लिए Vultr चुना गया
    • manual effort की वजह से regions को सिर्फ़ London, São Paulo, Silicon Valley, और Tokyo तक सीमित रखा गया
    • हर region में सबसे सस्ता Fedora VM बनाया गया और वही test चलाए गए
  • अंतिम test tool के रूप में hey को अधिक उपयुक्त माना गया
./hey_linux_amd64 -n 1000000 -c 10000 -t 10 -z 5m -h2 https://crocidb.com/ > crocidb.com.log
./hey_linux_amd64 -n 1000000 -c 10000 -t 10 -z 5m -h2 https://crocidb.cro.to/ > crocidb.cro.to.log
  • configuration थी कुल 1,000,000 requests, 10,000 concurrent requests, 10 second timeout, कुल runtime 5 minutes, और HTTP/2 enabled
  • यह वास्तविक ब्लॉग ट्रैफ़िक की तुलना में बहुत भारी load था
  • पहली run में नया FreeBSD सर्वर 10,000 concurrent connections नहीं संभाल सका और शुरुआत में ही fail हो गया
    • netstat -Lan से socket queue size देखने पर सभी मान 128 निकले
    • default kern.ipc.somaxconn value 128 थी, इसलिए इसे इस तरह बढ़ाया गया
sysctl kern.ipc.somaxconn=16384
  • São Paulo test में दोनों सर्वरों ने काफ़ी errors लौटाए, लेकिन FreeBSD सर्वर अपेक्षित 1,000,000 requests तक पहुँचा, जबकि Ubuntu सर्वर 20,000 requests भी वापस नहीं दे सका
    • पुराने Ubuntu सर्वर ने कुल requests का लगभग 7% ही पूरा किया
    • नए FreeBSD सर्वर ने लगभग 94% पूरा किया
    • Tokyo में नए सर्वर की success rate थोड़ी कम थी, लेकिन इसे बहुत चिंता की बात नहीं माना गया
  • requests per second के आधार पर नया सर्वर पुराने से कम-से-कम 3 गुना और अधिकतम 11 गुना बेहतर रहा
    • latency percentiles में नया सर्वर लगभग 90% बिंदु तक अधिक linear रूप से बढ़ा, इसलिए उसका behavior अधिक predictable था
    • बहुत अधिक load पर भी दुनिया के अधिकांश क्षेत्रों में ब्लॉग के main page का content 3.5 seconds से कम में मिल गया
  • Tokyo के परिणामों का गहराई से विश्लेषण नहीं किया गया
    • hey के request phase analysis में संकेत मिले कि Japan की ओर जाने वाला traffic शायद धीमा था
    • दूसरे domain के DNS dial-up और lookup values असामान्य रूप से कम दिखे, और CNAME record का असर संभव लगा
    • resp wait और resp read values भी असामान्य रूप से अधिक थीं, लेकिन क्योंकि केवल सफल requests गिनी गई थीं, संभव है कि पुराना सर्वर शुरुआत में तेज़ जवाब दे रहा था और बाद में नए requests को लगभग रोक रहा था

अंतिम बदलाव और मुख्य सीख

  • benchmark सब सवालों का जवाब नहीं दे पाए, लेकिन नतीजों से संतुष्ट होकर DNS records को नए सर्वर पर स्विच कर दिया गया
    • इसके बाद यह ब्लॉग आधिकारिक रूप से FreeBSD आधारित Hetzner सर्वर पर चलने लगा
  • FreeBSD पर site hosting machine सेट करना कई घंटों के प्रयोग, बदलाव, build, और failures से गुज़रा, लेकिन यह अपेक्षा से कम जटिल निकला
    • ज़रूरतें पूरी करने वाली managed web hosting service भी ली जा सकती थी, और उदाहरण के रूप में OpenBSD Amsterdam का उल्लेख हुआ
    • Proxmox के साथ containers और management dashboard भी इस्तेमाल किए जा सकते थे
    • FreeBSD ecosystem के विकल्प के रूप में Sylve का भी ज़िक्र हुआ
    • लेकिन खुद इसे configure करने की प्रक्रिया ने बहुत कुछ सिखाया, इसलिए यह रास्ता संतोषजनक रहा
  • पुराना Ubuntu सर्वर भी काफ़ी मज़बूत साबित हुआ
    • उसने 10 साल तक site load अच्छी तरह संभाला, और अंतिम 4 साल बिना reboot के चला
    • बहुत अधिक configuration effort के बिना भी वह स्थिरता से काम करता रहा
  • FreeBSD configuration उम्मीद से आसान निकला, और system settings को एक जगह centralize करने का तरीका तथा online documentation की गुणवत्ता अच्छी लगी
  • अपनी ब्लॉग hosting machine खुद बनानी हो तो game developer के सामान्य ज्ञान से आगे बढ़कर networking knowledge की ज़रूरत पड़ती है
    • अलग systems सीखने की प्रक्रिया आनंददायक लगी, और आगे OpenBSD या NetBSD आज़माने की भी संभावना बताई गई
    • अंत में यह भी कहा गया कि ब्लॉग ट्रैफ़िक का अधिकांश हिस्सा AI systems की crawling से आता है, इसलिए इस पूरे प्रयास की practical value सीमित है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News टिप्पणियाँ

  • मेरी सबसे बड़ी गलती ज़्यादा uptime थी
    arjie.com Hetzner VPS पर 10 साल से भी ज़्यादा समय तक चलता रहा, इसलिए जब Hetzner उस underlying machine को बंद करने वाला था, तब मुझे ज़रा भी पता नहीं था कि मेरी किशोर उम्र वाले version ने उसमें क्या-क्या सेट किया था
    बैकअप हैं, लेकिन साइट 10 साल से बंद पड़ी है
    अब मैं चीज़ों को इस तरह बनाता हूँ कि उन्हें migrate किया जा सके, और सच में कुछ बार migrate करके देख भी लेता हूँ कि सब काम करता है या नहीं

    • “सबसे बड़ी गलती ज़्यादा uptime थी” — यह बात सही है
      मुझे वह दौर याद है जब machine uptime को मानो सम्मान का तमगा समझा जाता था
      उम्र तो बढ़ गई है, पर ज़रूरी नहीं कि मैं ज़्यादा समझदार हुआ हूँ; अब मैं service uptime देखता हूँ
      पहले भी MX जैसे DNS records कुछ हद तक इसी उद्देश्य के लिए थे, और पुराने cluster काफ़ी पेचीदा थे, लेकिन split brain जैसी चीज़ों से ऐसे सबक मिले कि आज भी मुझे समझाना पड़ता है कि Proxmox 2-node cluster क्यों टूटता है, और अतिरिक्त witness की सलाह क्यों दी जाती है
      VMware ने पहले 2-node HA cluster की समस्या को एक बड़े अस्थायी जुगाड़ से ढक दिया था, वह भी ग़लत था, और अगर वह तरीका अभी भी बचा है तो शायद आज भी ग़लत ही होगा
      ज़्यादा uptime का मतलब है कि patch नहीं लगाए गए, और patch लगाना तो सबको बहुत पसंद होता है
    • इससे मुझे जापान का Ise Grand Shrine याद आता है
      उसे हर 20 साल में पूरी तरह तोड़कर फिर से बनाया जाता है, और हाल में पढ़ी Dan Wang की Breakneck में बताया गया है कि इस तरह की पुनर्निर्माण परंपरा उस ज्ञान को बचाए रखती है जो समय के साथ खो सकता है
      Wang ने Ise Grand Shrine और Notre Dame की तुलना की है, और उनका मानना है कि Notre Dame की छत को फिर से बनाना मुश्किल होने का एक कारण ज्ञान का खो जाना भी हो सकता है
      मैं इन दोनों इमारतों से इतना परिचित नहीं हूँ कि कह सकूँ तुलना पूरी तरह निष्पक्ष है, लेकिन सिद्धांत मुझे पसंद है
      किताब में यह बस एक छोटा-सा रूपक है, और कुल मिलाकर मैं इसे मज़बूती से recommend करता हूँ
    • VM में ज़्यादा uptime का बहुत कम मतलब होता है
      reboot कुछ ही सेकंड में हो जाता है, और upgrade भी बिना downtime के सिर्फ़ DNS को नई instance पर बदलकर किया जा सकता है
      जिन physical machines को आसानी से clone नहीं किया जा सकता, वहाँ कहानी अलग है
    • मैंने configuration को एक बड़े Ansible playbook repository में रखना शुरू किया है
      सब कुछ Ansible से पूरी तरह manage करना ज़रूरी नहीं है; मैं ज़्यादातर सिर्फ़ शुरुआती setup वहीं रखता हूँ, और अब भी काफ़ी चीज़ें हाथ से manage करता हूँ
    • मैं व्यक्तिगत projects के लिए भी कभी-कभी Architectural Decision Records लिखता हूँ
      थोड़ा हास्यास्पद लगता है, लेकिन उम्मीद से ज़्यादा बार काम आ जाता है

  • व्यक्तिगत/हॉबी कामों के लिए मैं ज़्यादातर Caddy frontend + Docker Compose वाला setup चलाता हूँ
    अगर simple website हो तो Caddy सीधे content serve करता है, और अगर “web app” हो तो मैं लगभग हमेशा उसे containerize कर देता हूँ, फिर Caddy TLS termination और Docker के नीचे चल रहे app तक reverse proxy का काम करता है
    आमतौर पर structure ~/apps/appname होता है, और हर app directory में Docker Compose file और mounted data directory रहती है
    compose down के बाद (s)ftp से data निकालकर long-term storage में रखा जा सकता है या site/service को migrate किया जा सकता है
    एक समय मैंने dedicated server पर कई VM चलाए थे, लेकिन बाद में OVH के अलग-अलग VPS पर चला गया; और अगर OVH पर mail चलाना है तो local zone VM से बचना चाहिए, क्योंकि वे mail hosting allow नहीं करते
    माहौल के हिसाब से स्थिति अलग हो सकती है

    • एक project में मैंने Traefik इस्तेमाल करना शुरू किया, और यह nginx proxy manager से बेहतर upgrade साबित हुआ
      NPM भी शानदार है और उसका web GUI भी अच्छा है, लेकिन Traefik में बस Docker Compose file में जो behavior चाहिए वह लिख दो और काम हो जाता है
    • मेरे घर का setup भी काफ़ी मिलता-जुलता है
      बस वहाँ Unraid containers चलाता है, और उनमें से एक nginx-family का tool है जिसे दूसरे services के लिए reverse proxy करने के लिए बनाया गया है
    • मैं भी लगभग यही तरीका अपनाता हूँ
      बस सोच रहा हूँ कि Debian से Flatcar जैसी किसी container-first, immutable system/OS की तरफ़ जाऊँ या नहीं
      FreeBSD के कुछ दिलचस्प technical फायदे हैं, लेकिन चाहें या न चाहें, बहुत-सा open source software Docker को ही default मानकर चलता है, और मेरे पास इतना समय या उत्साह नहीं है कि सब कुछ FreeBSD jail में migrate करूँ

  • कुछ हफ़्ते पहले मैंने भी यही काम किया था
    server शायद 2015 के बाद से update नहीं हुआ था, और उस ज़माने का Ghost blog और node 0.10 उस पर installed था
    मैंने थोड़ा rough तरीका अपनाया: पहले backup लिया, फिर Hermes agent (Gemini 3.1 Pro) को छोड़ दिया
    उसने सारे ज़रूरी upgrades और patches किए, और latest compatible items तक migration भी कर दिया
    उसके बाद server hardening और बेकार services हटाने का भी काफ़ी काम हुआ, और अगर AI support न होता तो शायद मैं यह काम और टालता रहता

    • AI के बिना भी update करना अपने-आप में बहुत आसान हो सकता है
      असली समस्या यह जोखिम है कि कुछ टूट सकता है, और उसे backup काफ़ी हद तक संभाल लेता है

  • व्यक्तिगत server पर FreeBSD इस्तेमाल करना मज़ेदार था
    उसमें कुछ cool, साफ़-सुथरा, simple और “punk rock” जैसा एहसास था
    लेकिन कुछ बड़े pain points की वजह से छोड़ना पड़ा: PM2 में FreeBSD पर bugs थे और वही process management के लिए इस्तेमाल करता था; विकल्प के तौर पर rc.d से daemon चलाने की कोशिश की, लेकिन logging setup बहुत मुश्किल लगा; firewall में ICMP जैसी security best practices तक सही ढंग से सेट करने के लिए बहुत कुछ हाथ से करना पड़ता था, और UFW defaults जैसे templates की कमी महसूस हुई

    • FreeBSD में ऐसे default templates शामिल हैं
      वे PF नहीं बल्कि IPFW में implemented हैं
      rc.conf में firewall_type key देखें: https://cgit.freebsd.org/src/tree/libexec/rc/rc.conf?id=8e08...
      single-machine firewall आसानी से configure करने के लिए firewall_type=client इस्तेमाल कर सकते हैं, या अगर कुछ host करना है तो firewall_type=workstation
      दूसरे मामले में firewall_myservices और firewall_allowservices यह नियंत्रित करते हैं कि कौन-से ports खुलेंगे और किन networks/IPs को access मिलेगा
      बहुत simple NAT gateway के लिए firewall_type=simple और firewall_simple_(iif|inet|oif|onet)(_ipv6)? से ISP side/internal side interface names और IPv4/IPv6 network ranges सेट कर सकते हैं
      हर option वास्तव में क्या करता है, यह /etc/rc.firewall में implemented है: https://cgit.freebsd.org/src/tree/libexec/rc/rc.firewall?id=...
    • क्या आपने PM2 को supervision के लिए इस्तेमाल किया था, यह जानने की जिज्ञासा है
      rc.d daemons के logs के लिए Unix-style simple messages हों तो logger(1) इस्तेमाल किया जा सकता है, या file में redirect करके newsyslog(8) से size manage की जा सकती है
      firewall के लिए मैं The Book of PF[0] recommend करूँगा
      FreeBSD का PF, OpenBSD के pf से syntax में अलग है, लेकिन firewall कैसे काम करता है और कौन-से rules लिखने चाहिए, यह समझने के लिए काफ़ी है
      [0]: https://nostarch.com/book-of-pf-4e
    • PM2 में तो किसी भी OS पर हमेशा bugs रहे हैं
      शुरुआत में वह बहुत convenient लगता है, लेकिन साथ ही इस्तेमाल करने में बेहद झुंझलाहट भरा software था, और deployment के समय environment variable updates कभी भी मेरी उम्मीद के मुताबिक़ काम नहीं करते थे
    • मेरा सबसे बड़ा pain point यह था कि power outage के बाद यह टिक नहीं पाता था
      बिजली जाने पर reboot के बाद file system के लिए manually fsck चलाने को कहता था

  • थोड़ा अलग सवाल है, लेकिन अभी सबसे लंबे support lifecycle वाला free Linux distribution कौन-सा है?
    कुछ समय तक मैं छोटे VMs पर CentOS 7 चलाता था, क्योंकि लंबे समय तक security updates मिलते थे और updates से कुछ टूटने का ख़तरा भी कम रहता था
    थोड़ा देखने पर लगता है कि अभी Alma/Rocky Linux सबसे अच्छा विकल्प है और 10 साल का support देते हैं
    लेकिन यह जानने की उत्सुकता है कि क्या उनका maintenance वाक़ई अच्छा है

    • मैंने भी servers पर 10 साल से ज़्यादा समय तक CentOS इसी उम्मीद में चलाया कि long-term stability और mental peace मिलेगा
      लेकिन इतना लंबा समय बीतने पर ecosystem बहुत drift कर जाता है, और OS के ऊपर applications को up to date रखकर चलाना धीरे-धीरे मुश्किल होता जाता है
      glibc, Python/Apache combinations, GCC जैसे infrastructure packages धीरे-धीरे modern application stacks से मेल खाना बंद कर देते हैं
      बाद में version upgrades भी दर्दनाक थे; सिर्फ़ इसलिए नहीं कि मैंने अजीब package mix करके खुद को कोने में पहुँचा दिया था, बल्कि इसलिए भी कि upgrade path खुद हमेशा best-effort ही रहा
      शायद 6 से 7 पर जाते समय मैंने हार मान ली थी, और अंत में समझ आया कि मुझे वास्तव में Fedora चाहिए था
      अगर आप हर साल या आधे साल में update करते हैं, तो distribution packages से लड़ना नहीं पड़ता, configuration updated रहती है और चलती रहती है, major distribution upgrades भी smooth रहते हैं, और downtime भी न्यूनतम होता है
      मैं फिर कभी “server distribution” पर वापस नहीं जाऊँगा
    • Alma अब RHEL source-compatible नहीं है, इसलिए उसके पास थोड़ी flexibility है
      उदाहरण के लिए, वह privilege escalation vulnerabilities को fix करने वाले kernel updates जल्दी जारी कर सकता है
      Rocky ने RHEL से नीचे आने का इंतज़ार करते हुए exploit mitigation देने वाले optional security repositories के ज़रिए प्रतिक्रिया दी थी
      हाल की घटनाओं को देखें तो दोनों का maintenance काफ़ी अच्छा लगता है
    • मुझे समझ नहीं आता कि व्यक्तिगत server पर rolling release distribution न इस्तेमाल करने की वजह क्या है
      सभी services container में चलाइए, और base OS को जितनी ज़रूरत हो उतनी बार auto-update होने दीजिए
      मैंने openSUSE MicroOS चुना है, और लगभग हर दिन updates और reboot होने के कारण मुझे काफ़ी भरोसा है कि server healthy है
      atomic updates होने से अगर कुछ टूट भी जाए और तुरंत deal करने का मन न हो, तो Cockpit में rollback button दबाकर बाद में समय मिलने पर देख सकते हैं
    • यह मानकर चलना है कि जो आप host कर रहे हैं वह आपके अगले upgrade cycle से ज़्यादा नहीं जिएगा
      क्योंकि जब आख़िरकार upgrade आएगा, तो उसके काफ़ी दर्दनाक होने की संभावना है
      बहुत लंबा समय बीतने के बाद सब कुछ बदल जाने पर बड़ा jump लेने से बेहतर है कि छोटे version jumps ज़्यादा बार लिए जाएँ
    • अगर आपको पूरी तरह free कुछ चाहिए या machines ज़्यादा हैं, तो Alma और Rocky ठीक हैं
      अगर Red Hat के साथ register करने में दिक्कत नहीं है, तो RHEL भी है, जो प्रति registered account 10 machines तक updates की access free देता है
      RHEL निश्चित रूप से major distributions में सबसे stable है, और Alma व Rocky मूलतः RHEL के downstream clones हैं

  • मैं भी उसी नाव में हूँ
    मेरे पास 2 पुराने servers हैं जिन्हें “बहुत” लंबे समय तक ऐसे ही छोड़ दिया गया, और अब उन्हें update करने के लिए छूने से भी डर लगता है
    लेकिन Linux distributions आजकल age verification/proof के मामले में जो तमाशा कर रहे हैं, उसे देखकर कभी-कभी लगता है कि सब छोड़ दूँ
    मैंने Artix भी आज़माया, लेकिन पिछले हफ़्ते reboot के बाद वह टूट गया, और लगता है पिछला kernel update ही गड़बड़ था, इसलिए rescue ISO तक निकालनी पड़ी
    इसलिए उस machine को Devuan पर बदल दिया, लेकिन अभी फैसला सुरक्षित है
    कोई बड़ी शिकायत नहीं है, पर अभी burn-in phase चल रहा है
    laptop पर Arch चला रहा हूँ, लेकिन community censorship issue की वजह से थोड़ी hostile लगती है, इसलिए किसी weekend पर समय मिलते ही उसे wipe करके कुछ और install करने का सोच रहा हूँ
    मुझे software में political drama नहीं चाहिए
    दिलचस्प बात यह है कि यही पहली बार था जब मैंने नया laptop खरीदा, Windows में एक बार भी boot नहीं किया, और सीधे Linux install कर दिया — और सब कुछ “बस काम कर गया”
    अब जब Linux को लेकर उत्साहित होने का समय है, तब बड़े players का AI everywhere, age proof/verification, default-on telemetry जैसी privacy erosion वाली चीज़ों को अपनाना दुखद लगता है
    मैं ऐसी चीज़ों के साथ interaction के लिए बस “nope” कहना चाहता हूँ

    • मैंने पहले एक Ubuntu server को 10 साल तक ऐसे ही छोड़ा था, और फिर 20 मिनट में बिना दर्द के उसे update कर लिया
      वह server आज भी latest LTS पर चल रहा है
      शुरू में वह Ubuntu 4 था या 6, यह भी याद नहीं, लेकिन पूरी यात्रा काफ़ी smooth रही
      शायद धीमे upgrades ने early adopter pain से बचा लिया
      आजकल मैं Debian बहुत ज़्यादा इस्तेमाल करता हूँ
      supply-chain attacks के इस दौर में Debian Stable सचमुच एक रत्न जैसा है, और भले कुछ packages के लिए अलग से काम करना पड़े क्योंकि उनके नए versions चाहिए, फिर भी उसकी पुरानी, सादी engineering spirit बहुत पसंद है
    • age verification/proof वाले मुद्दे पर लगता है कि आपको ग़लत दिशा दी गई है
    • reboot के बाद पिछला kernel update टूट गया — यह ज़्यादातर Arch/Artix की प्रकृति है
      ये दोनों सबसे जल्दी bleeding edge को follow करते हैं, और stability के लिए हमेशा सबसे अच्छे नहीं होते
      लेकिन इसका मतलब यह नहीं कि rolling distributions को हमेशा हर चीज़ का latest version ही देना चाहिए
      पिछले कुछ महीनों से मैं Void Linux इस्तेमाल कर रहा हूँ; यह rolling distribution है, लेकिन LTS kernel इस्तेमाल करता है, mainline भी optional है, और maintainers तेज़ updates से ज़्यादा stable app versions पर ध्यान देते हैं
    • मेरे servers/VMs आमतौर FreeBSD या Alpine चलाते हैं
      जहाँ ज़रूरत हो वहाँ थोड़ा Debian भी है, जैसे Proxmox, ऐसे VPS जो Alpine support नहीं करते, या company-related equipment
      Chimera चलाने वाले कुछ test systems भी हैं, लेकिन stable release आने से पहले उस पर ज़्यादा निर्भर रहने का इरादा नहीं है
      AerynOS के साथ भी थोड़ा प्रयोग कर रहा हूँ
    • काश FreeBSD का support lifecycle और लंबा होता
      releases की support life 1 साल से कम है, इसलिए अगर upgrade window छूट जाए तो बाद का upgrade Debian Stable जैसी दूसरी distributions की तुलना में ज़्यादा मुश्किल हो जाता है

  • servers के लिए मैं Debian और Ubuntu पर चला गया, लेकिन 2000s के मध्य में, जब मैं जवान था, तब मैं FreeBSD का बड़ा प्रशंसक था
    असल में उपयोगी काम करने से ज़्यादा समय मैं configuration और setup में बिताता था
    उस समय BSD variants देने वाले dedicated servers या VPS ढूँढना मुश्किल था, और शायद अंत में Panix.com पर आकर ठहरा था
    उससे पहले मुझे 15MinuteServers नाम की एक कंपनी याद है, जो शायद New Jersey के NAC से जुड़ी थी, और BSD offer करती थी
    अब तो बस यादें ताज़ा कर रहा हूँ

    • आजकल मेरे providers के यहाँ installation काफ़ी आसान है
      मैं Hetzner और OVH पर FreeBSD इस्तेमाल कर रहा हूँ, और पहले Vultr भी इस्तेमाल कर चुका हूँ
    • OVH के पास FreeBSD template है
      और ज़्यादातर KVM VM/VPS providers console access और custom ISO mount करने देते हैं, इसलिए आप जो चाहें install कर सकते हैं

  • fastfetch अगर असलियत से ज़्यादा memory usage report कर रहा है, तो शायद वजह ZFS ARC है
    Linux के page cache की तरह इसे कभी भी reclaim किया जा सकता है, और अलग-अलग tools इसे अलग नाम से दिखाते हैं: https://www.linuxatemyram.com/

  • जब किसी ने मुझे पहली बार Docker समझाया था, तो मुझे याद है मैंने कहा था, “ओह, मतलब jail?”
    जैसा कि लेख में बताया गया है, दोनों पूरी तरह एक जैसे नहीं हैं
    kqueue भी एक बड़ी जीत थी
    FreeBSD developers का सच में आभारी हूँ
    मैंने अपनी पहली कंपनी 15 साल तक FreeBSD पर चलाई, और उसका uptime व resilience कमाल का था

  • मेरे पास भी एक Ubuntu 16.04 server है जिसे update करने से डर लगता है
    अभी उसका uptime 1281 दिन है, और अब reboot करना लगभग बुरा लगने लगा है

    • file system को किसी दूसरी machine पर dd से copy करके qemu जैसे emulator में boot कर लें, और rehearsal run कर लें
      बस सावधान रहें कि auto-start होने वाली कोई चीज़ बाहर connect न करने लगे
    • मुझे समझ नहीं आता कि डर किस बात का है
      backup तो है न?
      Debian/Ubuntu systems को नियमित auto-updates और reboot के लिए आसानी से configure किया जा सकता है, ताकि manual maintenance सिर्फ़ बड़े version upgrades तक सीमित रह जाए
    • मेरा सबसे पुराना server 8.04 पर है