सर्वर के लिए Immutable Linux Distro का चयन कैसे करें

Immutable Linux distro क्या है

एक immutable Linux distro ऑपरेटिंग सिस्टम को एक image के रूप में प्रदान करता है, इसलिए आप सिस्टम को patch करने के बजाय उसे पूरी तरह बदल देते हैं। चलते हुए सिस्टम पर apt upgrade /usr या अन्य system directories में फाइलों को फिर से लिखना /usr संभव नहीं है। आप एक नई image बनाते हैं या pull करते हैं, मशीन इसे वर्तमान में चल रही image के साथ stage करती है, और अगला reboot सक्रिय image को बदल देता है। पिछली image डिस्क पर ही रहती है, इसलिए किसी खराब update को undo करने के लिए बस एक reboot की आवश्यकता होती है।

"Immutable" शब्द का प्रयोग इसे बढ़ा-चढ़ाकर दिखाने जैसा है। भौतिक रूप से कोई भी चीज root को डिस्क पर लिखने से नहीं रोक सकती। ये सिस्टम क्या करते हैं कि system directories को read-only mount कर देते हैं और उनका स्वामित्व image को दे देते हैं। Persistent डेटा /var /var में रहता है। मशीन-विशिष्ट कॉन्फ़िगरेशन /etc /etc में रहता है। /usr /usr के अंतर्गत सब कुछ image का हिस्सा है, यही कारण है कि एक ही image tag पर चल रहे दो सर्वर बिल्कुल समान system files रखते हैं।

Red Hat द्वारा इन दो मॉडलों के लिए दिए गए नाम सबसे स्पष्ट हैं: package mode और image mode। Package mode एक चलता हुआ सिस्टम है जिसमें एक package manager होता है जो इसे edit करता है। Image mode कहीं और किया गया एक build step है जो एक artifact तैयार करता है, और सर्वर का एकमात्र काम उस artifact को boot करना है जिसे आप उसे point करते हैं। नीचे दी गई हर बात इसी एक अंतर से निकलती है।

सर्वर पर read-only सिस्टम क्यों महत्वपूर्ण है

दो साल से चल रहे सर्वर का एक ऐसा इतिहास होता है जिसे किसी ने दर्ज नहीं किया होता। एक make install जो जल्दबाजी में की गई थी। किसी एक पैकेज के लिए जोड़ा गया third-party repository। outage के दौरान एडिट की गई config file जिसे कभी configuration management में वापस नहीं डाला गया। इसे configuration drift कहते हैं, और यही कारण है कि आपके नोट्स से "वही" सर्वर दोबारा बनाने पर अक्सर एक ऐसी मशीन तैयार होती है जो अलग तरह से व्यवहार करती है। नोट्स में केवल इरादा होता है। डिस्क में सच्चाई होती है।

Image mode उस जगह को हटा देता है जहाँ drift जमा होता है। /usr runtime पर read-only होता है, इसलिए हाथ से किया गया कोई भी install या तो तुरंत विफल हो जाता है या एक layer के रूप में दर्ज हो जाता है जिसे आप एक command से देख सकते हैं। यह दो मशीनों के बीच के अंतर को पुरातत्व संबंधी खोज के बजाय स्पष्ट रूप से दिखाई देने वाला बना देता है। यह वही समस्या है जिसे एक नियमित Linux सर्वर मेंटेनेंस चेकलिस्ट अनुशासन के साथ हल करती है, जिसे यहाँ filesystem द्वारा नियंत्रित किया जाता है।

Rollback का अर्थ है रीबूट, और यही इसकी मुख्य विशेषता है

यह मॉडल जिस विफलता के लिए बनाया गया है, वह वही है जिसे हम पहले ही एक VPS जो kernel अपडेट के बाद बूट नहीं होता के रूप में प्रलेखित कर चुके हैं। पैकेज मोड में आप प्रदाता के rescue console से रिकवरी करते हैं। आप डिस्क को माउंट करते हैं, chroot करते हैं, और मैन्युअल रूप से kernel पैकेज को हटाते हैं। यह इसलिए काम करता है क्योंकि बूटलोडर पुराने kernels को सुरक्षित रखता है, लेकिन केवल kernel ही इस तरह से versioned होता है। उसी ट्रांजेक्शन में आए glibc अपडेट और systemd बदलाव पहले ही लागू हो चुके होते हैं, और कोई एक कमांड उन्हें एक साथ वापस नहीं ले जा सकता।

इमेज मोड में पूरी यूनिट ही सिस्टम होती है। एक bootc होस्ट पर:

sudo bootc status
sudo bootc rollback
sudo systemctl reboot

bootc rollback बूटलोडर की प्राथमिकता को वापस पिछली बूट एंट्री पर सेट कर देता है, जो कि वही इमेज है जिसे आप एक घंटे पहले चला रहे थे, जिसमें kernel और userspace दोनों शामिल हैं। कुछ भी डाउनलोड या रीबिल्ड नहीं होता, क्योंकि पुरानी इमेज कभी डिस्क से हटती ही नहीं है।

Fedora CoreOS अलग नामों से यही प्रक्रिया अपनाता है:

sudo systemctl stop zincati.service
sudo rpm-ostree rollback -r

सबसे पहले Zincati को रोकें। Zincati वह एजेंट है जो Fedora CoreOS मशीन को नवीनतम रिलीज़ पर रखता है, इसलिए यदि आप इसे चालू छोड़ते हैं, तो यह उस अपडेट को फिर से स्टेज कर देगा जिसे आपने अभी हटाया है। -r रोलबैक स्टेज होने के बाद रीबूट करता है। जिस डिप्लॉयमेंट पर आप भरोसा करते हैं उसे garbage collected होने से बचाने के लिए:

sudo ostree admin pin 0
rpm-ostree status

rpm-ostree status उन डिप्लॉयमेंट्स को उस क्रम में सूचीबद्ध करता है जिसमें बूटलोडर उन्हें पेश करेगा, चल रहे डिप्लॉयमेंट को एक डॉट के साथ चिह्नित करता है, और आपके द्वारा पिन किए गए डिप्लॉयमेंट पर Pinned: yes दिखाता है।

Talos इसे आपके वर्कस्टेशन से एक API कॉल के रूप में करता है:

talosctl rollback --nodes 10.20.30.40

Flatcar दो /usr पार्टिशन्स रखता है और उनके बीच स्विच करता है। प्रत्येक स्लॉट में पार्टिशन टेबल के भीतर एक प्राथमिकता और एक try काउंटर होता है, इसलिए जो स्लॉट सफलतापूर्वक बूट नहीं होता, उसके प्रयास समाप्त हो जाते हैं और बूटलोडर दूसरे को चुन लेता है। जाँचें कि आप किस स्लॉट पर हैं और क्या इसे good के रूप में चिह्नित किया गया था:

sudo cgpt show "$(rootdev -s /usr)" | grep successful=1

एक स्वस्थ चल रहा स्लॉट priority=1 tries=0 successful=1 वाली एक लाइन प्रिंट करता है। यदि कोई मेल खाने वाली लाइन नहीं है, तो इसका मतलब है कि वर्तमान स्लॉट की पुष्टि कभी नहीं हुई थी, जो कि अपडेट और उसके पहले सफल बूट के बीच की स्थिति होती है।

"install a package" का विकल्प: bootc और Containerfile

bootc वह टूल है जिसने इस पैटर्न को सामान्यीकृत किया है। यह खुद को OCI (open container initiative) container images का उपयोग करके transactional, in-place ऑपरेटिंग सिस्टम अपडेट के रूप में वर्णित करता है, और यह एक CNCF Sandbox प्रोजेक्ट है। आपका सर्वर एक Containerfile बन जाता है। अगस्त 2026 तक Fedora base image quay.io/fedora/fedora-bootc:44 है और CentOS Stream base quay.io/centos-bootc/centos-bootc:stream10 है।

FROM quay.io/fedora/fedora-bootc:44
RUN dnf -y install nginx && dnf clean all
RUN systemctl enable nginx

इसे किसी अन्य image की तरह build और push करें:

sudo podman build -t registry.example.com/edge/web:2026-08-19 .
sudo podman push registry.example.com/edge/web:2026-08-19

फिर सर्वर पर:

sudo bootc upgrade --check
sudo bootc upgrade --apply

bootc upgrade image source को query करता है और अगले boot के लिए नई image को queue में डालता है। --check रिपोर्ट करता है कि क्या कोई अपडेट उपलब्ध है और कुछ भी बदलता नहीं है। --apply इसे reboot करके लागू करता है। bootc switch registry.example.com/edge/web:next मशीन को एक अलग image की ओर निर्देशित करता है, जबकि /etc और /var को सुरक्षित रखता है। इसी तरह आप सर्वर को reinstall किए बिना image streams के बीच स्थानांतरित करते हैं।

unattended updates के लिए, प्रोजेक्ट द्वारा दिए गए timer को enable करें:

sudo systemctl enable --now bootc-fetch-apply-updates.timer

यह Ubuntu पर unattended upgrades और Rocky और Alma पर dnf-automatic का image-mode उत्तर है। अंतर यह है कि क्या लागू होता है। एक package-mode timer उस रात repository में मौजूद जो भी version हो उसे लागू करता है, इसलिए परिणामी सेट हर मशीन पर थोड़ा अलग होता है। एक image-mode timer उस एक artifact को लागू करता है जिसे आपने पहले ही कहीं और boot कर लिया है।

उस Containerfile से दो build नियम निकलते हैं। Writable data /var के अंतर्गत होना चाहिए, इसलिए जो software अपनी install directory के अंदर लिखने पर जोर देता है, उसे build के समय एक symlink या systemd BindPaths= लाइन की आवश्यकता होती है। और /etc को अपडेट पर three-way merge किया जाता है, जिसका अर्थ है कि जिस file को आपने कभी नहीं छुआ, वह image का नया version ले लेती है, जबकि आपके द्वारा स्थानीय रूप से संपादित file सुरक्षित रहती है।

जब आपको एक debugging session के लिए live box पर किसी टूल की आवश्यकता हो:

sudo bootc usr-overlay
sudo dnf -y install strace

यह /usr पर एक transient writable overlay जोड़ता है जिसे अगले reboot पर हटा दिया जाता है। यह किसी समस्या को देखने के लिए है, न कि उसे ठीक करने के लिए। आप इस तरह kernel को नहीं बदल सकते हैं, और जो कुछ भी आप install करते हैं वह design के अनुसार reboot पर गायब हो जाता है।

Fedora CoreOS: एक बार प्रोविज़न करें, हमेशा अपडेट रखें

Fedora CoreOS में कोई इंटरैक्टिव इंस्टॉलर नहीं होता है। आप एक Butane YAML फ़ाइल लिखते हैं, उसे Ignition JSON में ट्रांसपाइल करते हैं, और पहली बार बूट करते समय मशीन को वह फ़ाइल देते हैं:

podman run --interactive --rm quay.io/coreos/butane:release \
       --pretty --strict < your_config.bu > transpiled_config.ign

Ignition केवल पहली बार बूट होने पर initramfs में चलता है। यह वह हिस्सा है जहाँ cloud-init से आने वाले लोग अक्सर गलती करते हैं। यदि कॉन्फ़िगरेशन में कोई SSH key नहीं है, तो मशीन बिना किसी एक्सेस के बूट हो जाएगी, और इसका एकमात्र समाधान इसे शुरू से दोबारा प्रोविज़न करना है। किसी महत्वपूर्ण सर्वर पर लागू करने से पहले कॉन्फ़िगरेशन को एक अस्थायी मशीन पर टेस्ट करें।

लाइव एनवायरनमेंट से डिस्क पर इंस्टॉल करना:

sudo coreos-installer install /dev/sda \
    --ignition-url https://example.com/example.ign

अपडेट डिफ़ॉल्ट रूप से स्वचालित होते हैं। आप यह नियंत्रित करते हैं कि अपडेट कब होंगे, यह नहीं कि वे होंगे या नहीं। /etc/zincati/config.d/55-updates-strategy.toml पर एक TOML फ़ाइल रखें जो आवधिक रणनीति (periodic strategy) का चयन करती है:

[updates]
strategy = "periodic"

उस रणनीति के तहत आप प्रत्येक array-of-tables प्रविष्टि के लिए एक मेंटेनेंस विंडो जोड़ते हैं, इसलिए प्रत्येक विंडो का हेडर डबल स्क्वायर ब्रैकेट के अंदर updates.periodic.window नाम के साथ शुरू होता है, जिसके बाद तीन कीज़ (keys) होती हैं:

• days, दिनों के नामों की एक सूची, जैसे "Sat" और "Sun"।
• start_time, वह समय जब विंडो खुलती है, जिसे "22:30" के रूप में लिखा जाता है।
• length_minutes, यह कितनी देर तक खुली रहती है, जैसे 60।

ये समय UTC में होते हैं। अपडेट को पूरी तरह से रोकने के लिए, sudo systemctl disable --now zincati.service चलाएं, और यह स्वीकार करें कि अब पैचिंग शेड्यूल की जिम्मेदारी आपकी है।

Package layering एक एस्केप हैच (escape hatch) के रूप में मौजूद है:

sudo rpm-ostree install --allow-inactive vim
sudo systemctl reboot

यह पैकेज जोड़कर एक नया डिप्लॉयमेंट बनाता है, और बदलाव केवल रीबूट के बाद ही प्रभावी होते हैं। इसकी कीमत बाद में चुकानी पड़ती है। आपका लेयर्ड सेट हर नए बेस इमेज के ऊपर फिर से लागू किया जाता है, इसलिए यदि कोई पैकेज अपडेट के दिन रिपॉजिटरी से गायब हो जाता है, तो वह अपडेट विफल हो जाएगा। Fedora का अपना डॉक्यूमेंटेशन आपको किसी भी महत्वपूर्ण कार्य के लिए कंटेनरों का उपयोग करने, और जब आपको वास्तव में OS बदलने की आवश्यकता हो, तो bootc इमेज का उपयोग करने का सुझाव देता है।

Flatcar Container Linux: इसमें कोई package manager नहीं है

Flatcar, CoreOS Container Linux का ही विस्तार है और सामान्य-उद्देश्य वाले विकल्पों में सबसे सख्त है। इसमें वापस जाने के लिए कोई package manager नहीं है। आप जो कुछ भी चलाते हैं, वह एक container होता है। Provisioning के लिए Ignition का उपयोग होता है, जो Fedora CoreOS के समान है। Updates ऊपर वर्णित दो A/B /usr partitions के माध्यम से होते हैं, जो update_engine द्वारा संचालित होते हैं, और locksmithd यह तय करता है कि reboot कब होगा।

update_engine_client -status
update_engine_client -check_for_update

UPDATE_STATUS_UPDATED_NEED_REBOOT का अर्थ है कि passive slot में पहले से ही नई image मौजूद है और केवल reboot बाकी है। डिफ़ॉल्ट reboot strategy reboot है जिसमें पाँच मिनट की देरी होती है, इसलिए एक अकेला production VPS अपने स्वयं के schedule पर restart हो जाएगा, जब तक कि आप अन्यथा न कहें। /etc/flatcar/update.conf में एक window सेट करें:

REBOOT_STRATEGY=reboot
LOCKSMITHD_REBOOT_WINDOW_START="Thu 04:00"
LOCKSMITHD_REBOOT_WINDOW_LENGTH=1h

REBOOT_STRATEGY=off reboot का निर्णय आप पर छोड़ देता है। उसी file में SERVER=disabled update check को पूरी तरह से रोक देता है। एक cluster के लिए, REBOOT_STRATEGY=etcd-lock को locksmithctl set-max 4 के साथ मिलाने से यह सीमित हो जाता है कि एक बार में कितने nodes reboot हो सकते हैं, ताकि कोई update पूरे fleet को एक साथ down न कर दे।

Talos Linux: कोई shell नहीं, कोई SSH नहीं, कोई console नहीं

Talos इन चारों में सबसे सीमित है और अपने उद्देश्य के प्रति सबसे स्पष्ट है। यह Kubernetes nodes चलाता है। इसमें कोई SSH daemon, कोई shell और कोई console login नहीं होता है। प्रत्येक ऑपरेशन आपके workstation से talosctl के माध्यम से किया गया एक gRPC API कॉल है, जो उस machine config के विरुद्ध होता है जिसे आप git में रखते हैं।

talosctl upgrade --nodes 10.20.30.40 \
  --image ghcr.io/siderolabs/installer:v1.10.6

इस tag को उस release से बदलें जिस पर आप जा रहे हैं। यह upgrade एक A-B scheme का उपयोग करता है जो पिछले kernel और OS image को सुरक्षित रखता है, इसलिए यदि नया वर्शन boot होने में विफल रहता है, तो Talos बिना किसी हस्तक्षेप के स्वयं rollback कर लेता है। Debugging का तरीका अलग है क्योंकि इसमें कोई shell नहीं है: आप box पर journalctl के बजाय talosctl logs और talosctl dmesg का उपयोग करते हैं।

यदि आपका workload Kubernetes नहीं है, तो Talos सही विकल्प नहीं है। यदि यह Kubernetes है, तो Talos घटनाओं की एक पूरी श्रेणी को समाप्त कर देता है, क्योंकि "किसी ने node में login करके कुछ बदल दिया" जैसी स्थिति के लिए कोई स्थान ही नहीं बचता।

VPS tenant वास्तव में क्या त्यागता है

चलते हुए सिस्टम पर Ad-hoc इंस्टॉलेशन। यह सबसे महत्वपूर्ण बदलाव है। incident के दौरान रात के 2 बजे sudo apt install htop उपलब्ध नहीं होता है। bootc पर आपको एक transient overlay मिलता है जो reboot के बाद समाप्त हो जाता है। Fedora CoreOS पर आपको एक layered deployment मिलता है जिसके लिए reboot की आवश्यकता होती है। Flatcar और Talos पर आपको कुछ नहीं मिलता।

एक build pipeline जो आपके पास पहले नहीं थी। किसी package को जोड़ने का अर्थ है Containerfile को edit करना, image को build करना, उसे registry में push करना और servers को roll करना। जब pipeline मौजूद हो तो यह आसान है। जब यह न हो, तो इसे खड़ा करना वास्तविक मेहनत का काम है। इसके लिए ऐसी registry चाहिए जहाँ तक servers पहुँच सकें, जो कि एक और service चलाने या एक और बिल चुकाने जैसा है।

Kernel modules। Kernel image से आता है, इसलिए running kernel के लिए compile किया गया module अगले update के बाद नहीं बचता। Out-of-tree modules और DKMS (dynamic kernel module support) packages को उस image के kernel के आधार पर image में ही build करना पड़ता है। जिस भी चीज़ के लिए ऐसे module की आवश्यकता हो जो base image में नहीं है, वह एक install problem के बजाय एक build problem बन जाता है।

Vendor और provider agents। Monitoring और backup agents आमतौर पर .deb या .rpm के रूप में आते हैं, जिनके साथ एक install script होती है जो /usr में लिखती है और एक unit को enable करती है। Read-only सिस्टम पर वह script विफल हो जाती है। कुछ vendors container publish करते हैं या image-mode इंस्टॉलेशन का दस्तावेजीकरण करते हैं। कई ऐसा नहीं करते। प्रतिबद्ध होने से पहले इसकी जाँच करें, क्योंकि जिस fleet को आप monitor नहीं कर सकते, वह drift होने वाली fleet से भी बदतर है।

स्वयं image। लगभग कोई भी VPS control panel Ubuntu और Debian के साथ Fedora CoreOS, Flatcar या Talos को सूचीबद्ध नहीं करता है। आपको disk स्वयं प्रदान करनी होती है, जो कि अगला भाग है।

किराए पर लिए गए VPS पर इसे कैसे सेटअप करें

सबसे पहले अपने प्रदाता (provider) के बारे में दो चीजें सुनिश्चित करें: आपके पास out-of-band console access (जैसे VNC या serial console) होना चाहिए, और आप एक rescue system को boot करने में सक्षम होने चाहिए। यदि console access नहीं है, तो मशीन के वापस न आने पर आपको support ticket खोलना पड़ेगा, जबकि console होने पर यह समस्या पाँच मिनट में ठीक हो सकती है।

यदि प्रदाता custom images स्वीकार करता है, तो vendor की raw या qcow2 image upload करें और काम पूरा हो गया। अन्यथा, आपको rescue system से स्वयं disk लिखनी होगी। Flatcar इसके लिए एक self-contained script प्रदान करता है, जो किसी भी Linux पर चलती है:

curl -fsSLO https://raw.githubusercontent.com/flatcar/init/flatcar-master/bin/flatcar-install
chmod +x flatcar-install
sudo ./flatcar-install -d /dev/sda -i ignition.json

इसे हमेशा rescue system से चलाएं, उस सर्वर से कभी नहीं जिसे आप replace कर रहे हैं, क्योंकि यह script काम करते समय target device को repartition करती है। इसे device पर कम से कम 8 GB usable space की आवश्यकता होती है, और rescue environment में bash, bzip2 या lbzip2, lsblk, wget, udevadm, gpg और gawk उपलब्ध होने चाहिए। आपके ignition.json में एक SSH key होनी चाहिए, अन्यथा installed system में login करने का कोई तरीका नहीं होगा।

Fedora CoreOS का तरीका भी ऐसा ही है, और इसका installer एक container के रूप में चलता है:

sudo podman run --pull=always --privileged --rm \
    -v /dev:/dev -v /run/udev:/run/udev -v .:/data -w /data \
    quay.io/coreos/coreos-installer:release \
    install /dev/vdb -i config.ign

इसे चलाने से पहले lsblk के साथ device name की जाँच करें। गलत device पर लिखने से उस पर मौजूद सारा डेटा नष्ट हो जाएगा, और इसके लिए कोई confirmation prompt नहीं आता है।

bootc एक ऐसा रास्ता प्रदान करता है जिसमें rescue mode की आवश्यकता नहीं होती, क्योंकि यह चल रहे Linux system को सीधे convert कर देता है:

sudo podman run --rm --privileged -v /dev:/dev -v /var/lib/containers:/var/lib/containers -v /:/target \
             --pid=host --security-opt label=type:unconfined_t \
             quay.io/fedora/fedora-bootc:44 \
             bootc install to-existing-root

इसे चलाने से पहले उस base image का documentation पढ़ें जिसका आप उपयोग कर रहे हैं, और इसे ऐसे सर्वर पर आज़माएँ जिसे आप हटा सकें। Reboot के बाद मशीन image को run करती है, और आपके पुराने package set हट जाते हैं।

Immutable server किसे चलाना चाहिए और किसे नहीं

यदि आपके सर्वर 'cattle' (पशुधन) की तरह हैं, तो आपको इसकी आवश्यकता है। एक ही recipe से कई मशीनें बनाना। CI (continuous integration) runners जो केवल एक घंटे के लिए चलते हैं। k3s या Kubernetes nodes जिन्हें ठीक करने के बजाय बदला जाता है। ऐसी कोई भी स्थिति जहाँ खराब सर्वर का समाधान केवल "इसे डिलीट करें और दूसरा बनाएँ" है, वहाँ यह उपयोगी है। यह तब भी फायदेमंद होता है जब आपको किसी ऑडिटर को यह साबित करना हो कि मशीन पर क्या चल रहा है, क्योंकि इसका उत्तर package list के बजाय एक image digest होता है।

यदि आपके पास एक hand-tended VPS है जिस पर तीन services चल रही हैं, आप जरूरत पड़ने पर चीजें install करते हैं, और आपके पास कोई build pipeline नहीं है, तो आपको इसकी आवश्यकता नहीं है। Image mode काम को कम नहीं करता है। यह काम को सर्वर से हटाकर build प्रक्रिया में ले जाता है, और इसके लिए आपको एक registry और pipeline की आवश्यकता होती है। यदि आपके पास उस काम को संभालने के लिए बुनियादी ढांचा है, तो आपको ऐसे सर्वर मिलते हैं जो बिल्कुल एक जैसे होते हैं और rollback केवल एक reboot होता है। यदि आपके पास ऐसा नहीं है, तो आपने एक ठीक चल रहे सर्वर में अनावश्यक जटिलता जोड़ दी है, जिससे रात के 2 बजे की समस्या और कठिन हो जाएगी।

सामान्य मध्यम मार्ग अभी भी कारगर है: automatic security updates के साथ एक सामान्य distribution, और एक ऐसा rebuild जिसे आपने वास्तव में अभ्यास में लाया हो। उस आधार (base) को चुनना एक अलग निर्णय है, जिसे अपने VPS पर कौन सा OS चलाएं, यह चुनना में कवर किया गया है। Image mode सॉफ्टवेयर को मशीन तक पहुँचाने के तरीके पर चल रही एक बहुत पुरानी बहस का नवीनतम दौर है, और Linux distributions का इतिहास काफी हद तक उसी बहस की पुनरावृत्ति है।

FAQ

क्या एक immutable Linux distro वास्तव में immutable होता है?

नहीं, और यह नाम भ्रम पैदा करता है। root अभी भी डिस्क पर लिख सकता है। वास्तव में होता यह है कि runtime पर /usr को read-only mount किया जाता है और अगली image द्वारा इसे पूरी तरह बदल दिया जाता है, जबकि /etc और /var writable रहते हैं और updates के बाद भी बने रहते हैं। /usr के अंतर्गत आप जो बदलाव करते हैं, उन्हें या तो उस समय अस्वीकार कर दिया जाता है या अगली update पर हटा दिया जाता है, इसलिए व्यावहारिक प्रभाव यह होता है कि system directories केवल तभी बदलती हैं जब image बदलती है।

क्या मैं ऐसे VPS पर Fedora CoreOS या Flatcar चला सकता हूँ जो उन्हें offer नहीं करता?

आमतौर पर हाँ, यदि provider आपको rescue system और console access देता है। आप rescue mode में boot करें, distribution की disk image को block device पर लिखें, और फिर reboot करें। Flatcar की flatcar-install script किसी भी Linux से ऐसा कर सकती है, और Fedora CoreOS coreos-installer को एक container के रूप में प्रदान करता है जिसे आप उसी तरह चला सकते हैं। दोनों को एक Ignition file की आवश्यकता होती है जिसमें आपकी SSH key हो, क्योंकि इसमें first-boot password prompt जैसा कोई विकल्प नहीं होता। Console access के बिना, ऐसा करने का प्रयास न करें: यदि मशीन वापस boot नहीं होती है, तो आपके पास जाँचने के लिए कुछ भी नहीं बचेगा।

मैं immutable सर्वर पर package कैसे install करूँ?

आप इसे image में जोड़ते हैं और redeploy करते हैं। bootc पर यह Containerfile में एक RUN dnf -y install ... लाइन है, जिसे rebuild और push करने के बाद मशीन पर sudo bootc upgrade --apply चलाना होता है। Fedora CoreOS पर आप इसे sudo rpm-ostree install के साथ layer कर सकते हैं और reboot कर सकते हैं, लेकिन इसकी कीमत यह है कि वह package हर भविष्य की update पर फिर से apply होगा। Flatcar और Talos पर कोई package manager नहीं है, इसलिए इसका उत्तर एक container है। bootc host पर एक बार के debugging tool के लिए, sudo bootc usr-overlay आपको एक writable /usr देता है जो अगले reboot पर गायब हो जाता है।

क्या image mode उस VPS को ठीक करता है जो kernel update के बाद boot नहीं होता?

यह recovery को rescue-console के काम से बदलकर एक साधारण reboot बना देता है। पिछली image, kernel और userspace के साथ, अभी भी डिस्क पर होती है, इसलिए sudo bootc rollback या sudo rpm-ostree rollback -r आपको वापस उस पर ले आता है। Talos और Flatcar इससे आगे बढ़कर बिना कहे ही roll back कर देते हैं जब नया slot boot होने में विफल रहता है, क्योंकि एक boot entry केवल एक सफल boot के बाद ही default बनती है। इनमें से कोई भी खराब update को रोकता नहीं है। यह केवल उसे undo करना सस्ता बनाता है।

मुझे सर्वर के लिए कौन सा immutable distro चुनना चाहिए?

यदि आप एक general-purpose Linux सर्वर चाहते हैं जिसे आप container image की तरह build करते हैं और अपनी मशीन पर install कर सकते हैं, तो bootc चुनें। यदि आप वही model चाहते हैं जिसमें building आपके लिए पहले से हो और automatic updates भी मिलें, तो Fedora CoreOS चुनें। यदि आप A/B update scheme वाला एक minimal container host चाहते हैं जिसमें किसी के लिए भी package manager न हो, तो Flatcar चुनें। Talos केवल तब चुनें जब मशीन एक Kubernetes node हो, क्योंकि इसमें कोई shell नहीं होता और यह कुछ और नहीं चलाता।