Fedora Server का उपयोग कब करें और अपडेट कैसे मैनेज करें

Fedora release को सुरक्षा अपडेट कब तक मिलते हैं?

Fedora server को जब तक उपयोग में लाया जाता है, तब तक लगभग हर साल एक version upgrade की आवश्यकता होती है। Fedora लगभग हर छह महीने में एक नया release जारी करता है। प्रत्येक release को उसके दो संस्करण बाद वाले release के आने के चार सप्ताह बाद तक support मिलता है, जो कि लगभग 13 महीनों के अपडेट के बराबर होता है। उस तिथि के बाद, release को कोई भी सुरक्षा सुधार (security fixes) प्राप्त नहीं होते हैं। सर्वर चलता रहता है, लेकिन इसमें ऐसे packages होते हैं जिन्हें अब कोई patch नहीं करता है।

तारीखें इसे स्पष्ट करती हैं। अगस्त 2026 तक, supported releases Fedora 43 और Fedora 44 हैं। Fedora 44 को 28 April 2026 को जारी किया गया था और इसका end of life जून 2027 के लिए निर्धारित है। Fedora 42 को April 2025 में जारी किया गया था और यह Fedora 44 के आने के चार सप्ताह बाद, May 2026 में end of life हो गया। इसलिए, Fedora 42 image से बनाया गया एक सर्वर तेरह महीने बाद support से बाहर हो गया, बिना किसी गलती के।

Fedora बनाम LTS, महीनों में

LTS का अर्थ है long term support: एक ऐसा release जिसे vendor महीनों के बजाय वर्षों तक patch करता रहता है। EOL का अर्थ है end of life, वह तारीख जब patches मिलना बंद हो जाते हैं। यहाँ वह जानकारी है जो प्रत्येक project उस release के लिए प्रकाशित करता है जिसे आप आज install करेंगे।

[
  {
    "distro": "Fedora 44",
    "support_window": 13,
    "upgrades_per_decade": 10
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "support_window": 60,
    "upgrades_per_decade": 2
  },
  {
    "distro": "Debian 13 stable",
    "support_window": 36,
    "upgrades_per_decade": 3
  },
  {
    "distro": "AlmaLinux 10",
    "support_window": 120,
    "upgrades_per_decade": 1
  }
]

Fedora आपको प्रति release 13 महीने देता है। एक Ubuntu LTS 60 महीने देता है, और AlmaLinux जैसा enterprise rebuild 120 महीने देता है। दूसरे column को एक बिल की तरह पढ़ें। दस वर्षों में, Fedora को पूरे operating system के लगभग 10 upgrades की आवश्यकता होती है, जबकि Ubuntu LTS पर यह संख्या 2 है। Debian का 36 महीनों का आंकड़ा इसके नियमित security support का है, और एक अलग LTS team अधिकांश releases को लगभग पाँच वर्षों तक बढ़ा देती है।

ये प्रकाशित support windows हैं, जिन्हें August 2026 में जाँचा गया है, न कि मापा गया uptime। ये आवृत्तियाँ (cadences) क्यों भिन्न हैं, यह server पर Ubuntu LTS और interim releases के बीच का अंतर में बताया गया है। यहाँ जो महत्वपूर्ण है, वह यह है कि प्रत्येक विकल्प आपके लिए कितना कार्य उत्पन्न करता है।

Fedora version upgrade में वास्तव में क्या शामिल है

Fedora 41 के बाद से DNF 5 डिफ़ॉल्ट पैकेज मैनेजर है, और dnf इसे चलाता है। system-upgrade कमांड स्वयं dnf5 का हिस्सा है, इसलिए पहले कोई प्लगइन इंस्टॉल करने की आवश्यकता नहीं है। वर्तमान रिलीज़ से शुरुआत करें, जो पूरी तरह से पैच की गई हो:

sudo dnf upgrade --refresh
sudo reboot

Reboot महत्वपूर्ण है क्योंकि अपग्रेड इस आधार पर होता है कि क्या इंस्टॉल है और क्या चल रहा है, इसलिए आधा-अधूरा लागू हुआ kernel या glibc अपडेट अगली प्रक्रिया को समझना कठिन बना देता है। अब नई रिलीज़ को स्टेज करें। 44 को उस रिलीज़ से बदलें जिस पर आप जा रहे हैं:

sudo dnf system-upgrade download --releasever=44

यह पूरे ट्रांजेक्शन को हल करता है और हर पैकेज को डाउनलोड करता है, और यह चल रहे सिस्टम पर कुछ भी नहीं बदलता है। एक छोटे सर्वर पर कुछ हजार पैकेज और एक से तीन गीगाबाइट डेटा की अपेक्षा रखें। यदि dnf ट्रांजेक्शन को हल नहीं कर पाता है, तो यह यहीं रुक जाता है और उस पैकेज का नाम बताता है जिसने इसे रोका है। यह एक अच्छी स्थिति है, क्योंकि विफलता तब होती है जब मशीन अभी भी चालू है और आपके पास shell उपलब्ध है।

फिर इसे चलाएँ:

sudo dnf offline status
sudo dnf system-upgrade reboot

dnf offline status पुष्टि करता है कि एक ट्रांजेक्शन स्टेज किया गया है और प्रतीक्षा कर रहा है। dnf system-upgrade reboot मशीन को एक ऑफ़लाइन ट्रांजेक्शन में रीस्टार्ट करता है: एक न्यूनतम बूट जहाँ RPM ट्रांजेक्शन अपने आप चलता है। यह इस तरह काम करता है क्योंकि चल रही सेवाओं के नीचे glibc और systemd को बदलना ही वह तरीका है जिससे सिस्टम आधा-अधूरा इंस्टॉल हो सकता है। आपका सर्वर पूरी ट्रांजेक्शन के दौरान पहुंच से बाहर रहता है, आमतौर पर एक छोटे VPS पर कुछ मिनट, फिर यह नई रिलीज़ में फिर से रीबूट होता है। दो रीबूट और उस समय के लिए योजना बनाएँ जब SSH काम नहीं करेगा।

जब यह वापस आता है:

cat /etc/fedora-release
sudo dnf system-upgrade log --number=-1
sudo dnf distro-sync
sudo dnf repoquery --extras

/etc/fedora-release को Fedora release 44 (Forty Four) जैसी एक लाइन प्रिंट करनी चाहिए। log सब-कमांड उस ऑफ़लाइन बूट से ट्रांजेक्शन लॉग प्रिंट करता है, जो इस बात का एकमात्र रिकॉर्ड है कि जब आपके पास shell नहीं था तब क्या हुआ था। distro-sync जो कुछ भी पीछे रह गया है उसे नई रिलीज़ के वर्ज़न पर लाता है। repoquery --extras उन इंस्टॉल किए गए पैकेजों को सूचीबद्ध करता है जो अब किसी भी सक्षम रिपॉजिटरी में नहीं हैं, जहाँ आपको उन रिपॉजिटरी के अवशेष मिलते हैं जिन्होंने नई रिलीज़ के लिए कभी पब्लिश नहीं किया।

डाउनलोड चरण से पहले डिस्क का स्नैपशॉट लें। ट्रांजेक्शन तब चलता है जब आप स्क्रीन नहीं देख सकते, इसलिए यदि यह ऑफ़लाइन बूट के दौरान विफल हो जाता है, तो SSH वापस नहीं आएगा और आपके पास प्रवेश करने का एकमात्र तरीका वह कंसोल है जो प्रदाता आपको देता है, VNC या सीरियल। शुरू करने से पहले पुष्टि करें कि आपके पास कंसोल या स्नैपशॉट है, बाद में नहीं।

एक और जाँच जिसे लोग छोड़ देते हैं:

sudo find /etc -name '*.rpmnew' -o -name '*.rpmsave'

जब कोई पैकेज एक नई डिफ़ॉल्ट कॉन्फ़िगरेशन फ़ाइल भेजता है और आपने पुरानी फ़ाइल को संपादित किया है, तो RPM आपकी फ़ाइल को ओवरराइट नहीं करता है। यह पैकेज्ड वर्ज़न को इसके बगल में .rpmnew के रूप में लिखता है। इसलिए आपका sshd या nginx बिल्कुल वैसा ही व्यवहार करता रहता है जैसा उसने पुरानी रिलीज़ पर किया था, जबकि नए डिफ़ॉल्ट डिस्क पर बिना पढ़े रह जाते हैं। हर अपग्रेड के बाद उन फ़ाइलों को पढ़ें। rpmconf इंस्टॉल करना और sudo rpmconf -a चलाना उन्हें एक-एक करके दिखाता है और आपको अंतर स्पष्ट करता है।

Third-party repositories अपग्रेड को बाधित करते हैं

Fedora के अपने सभी packages release के दिन एक साथ अपडेट होते हैं। Fedora के बाहर का कोई भी package किसी और के schedule पर चलता है। अधिकांश vendor repositories अपने URL में $releasever का उपयोग करते हैं, इसलिए जैसे ही आप अपग्रेड करते हैं, dnf ऐसे path की मांग करने लगता है जो शायद अभी मौजूद ही न हो।

अपने पास मौजूद repositories की सूची देखें:

sudo dnf repo list --enabled
grep -R -e baseurl -e metalink /etc/yum.repos.d/

हर उस repository के लिए जो Fedora की अपनी नहीं है, अपग्रेड करने से पहले target release के साथ उसका परीक्षण करें:

sudo dnf --releasever=44 --repo=docker-ce-stable makecache

यदि vendor ने उस release के लिए packages प्रकाशित कर दिए हैं, तो dnf metadata डाउनलोड करेगा और चुपचाप exit हो जाएगा। यदि नहीं, तो आपको https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml जैसे path के लिए 404 error मिलेगा, और यही विफलता बाद में system-upgrade download को रोक देगी। Fedora release के बाद के शुरुआती हफ्तों में, अपग्रेड शुरू न हो पाने का यह सबसे आम कारण है।

आपके पास दो विकल्प हैं। कुछ सप्ताह प्रतीक्षा करें जब तक vendor उसे प्रकाशित न कर दे, जो आमतौर पर सही निर्णय होता है। या फिर उस repository के बिना अपग्रेड करें:

sudo dnf system-upgrade download --releasever=44 --disable-repo=docker-ce-stable

Repository को disable करने से उसके packages हटते नहीं हैं। वे installed और unmanaged रहते हैं, और यदि वे transaction को रोकते हैं, तो dnf इसकी सूचना देता है। --allowerasing जोड़ने से dnf को conflict हल करने के लिए installed packages को हटाने की अनुमति मिल जाती है, इसलिए स्वीकार करने से पहले removal list को ध्यान से पढ़ें। इसी सूची में अक्सर लोग वह database server खो देते हैं जिसे वे रखना चाहते थे।

यदि Fedora सर्वर अपडेट विंडो चूक जाए तो क्या होता है

उस दिन कुछ नहीं होता है। समस्या तब आती है जब आप अगली बार package manager का उपयोग करते हैं। End of life releases को mirror network से हटाकर archive में डाल दिया जाता है, इसलिए dnf upgrade metadata fetch करते समय विफल हो जाता है, और आपके release के लिए metalink URL पर 404 error आता है:

Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-42&arch=x86_64

मशीन traffic सर्व करना जारी रखती है, जो इसे शांत और खतरनाक बनाता है। इसे कोई security updates नहीं मिलते हैं। यह कुछ भी install भी नहीं कर सकती है, इसलिए जिस दिन OpenSSH या nginx के लिए कोई advisory आती है, आपके पास इसे patch करने का कोई समर्थित तरीका नहीं होता है।

इससे बाहर निकलना संभव है लेकिन यह धीमी प्रक्रिया है। आप repositories को Fedora के archive पर https://dl.fedoraproject.org/pub/archive/fedora/linux/ पर repoint कर सकते हैं और वहां से upgrade कर सकते हैं। Fedora एक बार में एक या दो releases के hop की अपेक्षा करता है, इसलिए यदि कोई box चार releases पीछे है, तो इसका मतलब है कि लगातार कई hops करने होंगे। हर hop में विफलता की संभावना होती है और हर बार offline boot में बिना सुरक्षा के काम करना पड़ता है। VPS पर, एक current image पर rebuild करना और data को स्थानांतरित करना आमतौर पर छोटा और सुरक्षित काम होता है, और यह नए VPS पर शुरुआती दस मिनट के समान ही काम है।

Automatic updates किसी release को patch करते हैं। वे कभी भी उसे upgrade नहीं करते हैं।

Fedora अपने updates को एक timer पर install कर सकता है:

sudo dnf install -y dnf5-plugin-automatic
sudo systemctl enable --now dnf5-automatic.timer

Settings /etc/dnf/automatic.conf में रहती हैं, जो /usr/share/dnf5/dnf5-plugins/automatic.conf में दिए गए डिफ़ॉल्ट मानों को override करती हैं। apply_updates डिफ़ॉल्ट रूप से बंद (off) रहता है, इसलिए डिफ़ॉल्ट रूप से यह timer केवल updates को download करता है और कुछ भी install नहीं करता है। upgrade_type, default और security के बीच चयन करता है। reboot में never, when-changed या when-needed स्वीकार किए जाते हैं।

यह आपको एक release के भीतर अद्यतित (current) रखता है। यह कभी भी Fedora 43 को Fedora 44 में नहीं बदलेगा, क्योंकि version upgrade एक अलग और जानबूझकर की जाने वाली प्रक्रिया है जो एक offline transaction के लिए reboot करती है। LTS के मुकाबले यही व्यावहारिक अंतर है। Ubuntu पर, unattended security upgrades बिना किसी version परिवर्तन के पूरे पांच साल की अवधि तक मशीन को सुरक्षित रखते हैं, और version परिवर्तन स्वयं एक नियोजित कार्य होता है, जैसे कि 24.04 से 26.04 का upgrade, जो हर कुछ वर्षों में एक बार किया जाता है।

Fedora सर्वर के रूप में कब सही विकल्प है

जब नवीनतम तकनीक का उपयोग करना मुख्य उद्देश्य हो, तो Fedora एक अच्छा विकल्प है।

• आपको ऐसे kernel या userspace की आवश्यकता है जो किसी भी LTS release से अधिक नए हों: जैसे कि नया hardware, या ऐसा container और systemd stack जो enterprise release में आने में अभी एक साल दूर हो। Fedora एक release के दौरान भी नए upstream kernels पर अपडेट होता रहता है, इसलिए यह केवल install के समय मिलने वाला लाभ नहीं है।
• आप यह validate कर रहे हैं कि RHEL (Red Hat Enterprise Linux) में क्या आने वाला है। Fedora, CentOS Stream को फीड करता है, जो RHEL को फीड करता है। इसलिए जो software आज Fedora पर build और run होता है, उसे भविष्य के enterprise platform के लिए test किया जा रहा है।
• मशीन का जीवनकाल छोटा है। एक build runner या test box जिसे दो महीने में नष्ट कर दिया जाना है, वह कभी भी अपने end of life तक नहीं पहुँचता। यही तर्क coding agents को दी जाने वाली disposable VMs पर भी लागू होता है, जहाँ box को Fedora के release cycle से कहीं अधिक बार rebuild किया जाता है।
• कोई व्यक्ति upgrade की जिम्मेदारी लेता है। Fedora ऐसे सर्वर पर ठीक काम करता है जिसका एक नामित स्वामी हो और जिसके लिए calendar में entry हो। यह उन मशीनों के लिए बिल्कुल उपयुक्त नहीं है जिन्हें हर कोई भूल चुका है।

मध्यम मार्ग: एक स्थिर आधार पर वर्तमान पैकेज

जो लोग सर्वर पर Fedora चाहते हैं, उनमें से अधिकांश को केवल दो या तीन वर्तमान पैकेज चाहिए होते हैं, न कि एक वर्तमान ऑपरेटिंग सिस्टम। इन्हें अलग किया जा सकता है। आधार के रूप में एक LTS या enterprise rebuild चलाएं, फिर जहां वास्तव में आवश्यकता हो वहां नया सॉफ्टवेयर लाएं। एक container image आपको उस होस्ट पर एप्लिकेशन का नया संस्करण देती है जिसे आपको इसके लिए कभी अपग्रेड नहीं करना पड़ता (VPS पर Docker चलाना)। जिस एक पैकेज की आपको परवाह है, जैसे PostgreSQL या nginx, उसके लिए vendor repository उस एक चीज़ को आगे बढ़ाती है और आधार को वैसा ही रहने देती है।

यह समझौता दोनों दिशाओं में स्पष्ट है। एक container आपको होस्ट के पुराने kernel पर एक नया userspace देता है, इसलिए जब आपको kernel की ही आवश्यकता हो तो यह मदद नहीं करता। एक vendor repository आपको उस आधार पर एक नया पैकेज देती है जिसे vendor ने कम टेस्ट किया है। दोनों ही आधार सिस्टम के security updates को LTS घड़ी पर छोड़ देते हैं, और वही घड़ी वह हिस्सा है जिसके कारण Fedora पर आपको हर साल एक maintenance window का खर्च उठाना पड़ता है।

यदि आप सर्वर के लिए Fedora चुनते हैं, तो इसके चक्र को कैलेंडर पर रखें। जब कोई release आती है, तो vendor repositories के अपडेट होने के लिए कुछ सप्ताह प्रतीक्षा करें, snapshot लें, अपग्रेड करें, और फिर सत्यापित करें कि सेवाएं वापस आ गई हैं। उस लय में साल में लगभग एक घंटे का समय लगता है और यह काम करता है। वह संस्करण विफल होता है जिसे केवल इसलिए याद किया जाता है क्योंकि कुछ पहले ही टूट चुका होता है।

FAQ

Fedora release को कितने समय तक support किया जाता है?

लगभग 13 महीने। Fedora लगभग हर छह महीने में एक release प्रकाशित करता है और प्रत्येक release को उसके दो version बाद वाली release के चार सप्ताह बाद तक support करता है। Fedora 44 को 28 April 2026 को release किया गया था और इसका end of life June 2027 में निर्धारित है। उस तारीख के बाद, release को security updates मिलना बंद हो जाते हैं और इसके packages को mirrors से हटाकर Fedora के archive में डाल दिया जाता है।

क्या मैं एक Fedora release को छोड़कर सीधे दो version upgrade कर सकता हूँ?

हाँ, कुछ सीमाओं के भीतर। dnf system-upgrade download --releasever= एक या दो release आगे के target को स्वीकार करता है, और एक बार में दो version कूदना ही वह तरीका है जिससे साल में एक बार upgrade करने की प्रक्रिया काम करती है। इससे अधिक आगे जाना समर्थित मार्ग नहीं है, और हर अतिरिक्त release के साथ इस बात की संभावना बढ़ जाती है कि package का नाम बदलने या config format में बदलाव के कारण transaction रुक जाए। यदि कोई machine पहले से ही कई release पीछे है और end of life हो चुकी है, तो upgrades की श्रृंखला चलाने के बजाय वर्तमान image पर rebuild करना आमतौर पर तेज होता है।

यदि मेरा Fedora server end of life तक पहुँच जाए तो क्या होगा?

यह चलता रहेगा लेकिन इसमें patches मिलना बंद हो जाएंगे। अगली dnf upgrade command आपकी release के लिए metalink URL पर 404 error के साथ विफल हो जाएगी, क्योंकि end of life हो चुकी releases को dl.fedoraproject.org पर archive में स्थानांतरित कर दिया जाता है। आप repository files को उस archive पर point कर सकते हैं और टुकड़ों में upgrade कर सकते हैं, या फिर किसी समर्थित release पर server को rebuild कर सकते हैं। जब तक आप इन दोनों में से कोई एक काम नहीं करते, तब तक machine को कोई security update नहीं मिलेगा और कोई भी package install नहीं होगा।

क्या production server के लिए Fedora एक बुरा विकल्प है?

यह एक बुरा default विकल्प है, लेकिन किसी ठोस कारण के साथ यह एक उचित विकल्प हो सकता है। इसकी कीमत यह है कि आपको उस machine पर हर साल पूरा operating system upgrade करना होगा जिसे आप शायद छूना भी न चाहें। Fedora तब चुनें जब आपको LTS द्वारा प्रदान किए जाने वाले kernel या userspace से नया संस्करण चाहिए हो, या जब server का जीवनकाल ही छोटा हो। यदि आप बिना version बदले वर्षों तक server को patch करना चाहते हैं, तो LTS या enterprise rebuild का चयन करें।