Fedora VPS server को कितनी बार upgrade करना होगा?

Fedora release को कितने समय तक security updates मिलते हैं?

Fedora server के लिए लगभग हर साल version upgrade करना पड़ता है, जब तक मशीन मौजूद रहती है। Fedora लगभग हर छह महीने में नई release publish करता है। प्रत्येक release को उसके दो version बाद वाली release के आने के लगभग चार सप्ताह बाद तक support मिलता है। इसका अर्थ लगभग 13 महीने के updates हैं। इस तारीख के बाद उस release को कोई security fix नहीं मिलता। मशीन चलती रहती है, लेकिन उसके package set को फिर कोई patch नहीं करता।

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

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

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

[
  {
    "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 महीने का support देता है। Ubuntu LTS 60 महीने देता है, जबकि AlmaLinux जैसा enterprise rebuild 120 महीने देता है। दूसरे column को आवश्यक upgrade work के रूप में देखें। दस वर्षों में Fedora पर पूरे operating system को लगभग 10 बार upgrade करना पड़ता है, जबकि Ubuntu LTS पर यह संख्या 2 है। Debian का 36 महीनों का आँकड़ा उसके नियमित security support के लिए है। अलग LTS team अधिकांश releases का support लगभग पाँच वर्षों तक बढ़ाती है।

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

Fedora version upgrade में वास्तव में क्या होता है

Fedora 41 से DNF 5 डिफ़ॉल्ट package manager है और dnf इसे चलाता है। system-upgrade command स्वयं dnf5 का हिस्सा है, इसलिए पहले कोई plugin install करने की जरूरत नहीं है। यदि आप Debian या Ubuntu box से आ रहे हैं, तो रोज़ाना टाइप किए जाने वाले अधिकांश commands के लिए apt से dnf का सीधा समकक्ष उपलब्ध है। नीचे दिया गया version upgrade उन कुछ कार्यों में से एक है जिसका कोई वास्तविक समकक्ष नहीं है। वर्तमान release से शुरू करें और पहले उसे पूरी तरह patch करें:

sudo dnf upgrade --refresh
sudo reboot

Reboot महत्वपूर्ण है, क्योंकि upgrade installed और running स्थिति के आधार पर resolve होता है। इसलिए आधा लागू हुआ kernel या glibc update अगले चरण को समझना कठिन बना देता है। अब नई release को stage करें। 44 को उस release number से बदलें जिस पर आप जा रहे हैं:

sudo dnf system-upgrade download --releasever=44

यह पूरी transaction को resolve करता है और हर package download करता है। Running system में इससे कोई बदलाव नहीं होता। छोटे server पर कुछ हजार packages और one to three gigabytes download होने की अपेक्षा रखें। यदि dnf transaction resolve नहीं कर पाता, तो वह यहीं रुक जाता है और उस package का नाम बताता है जिसने इसे रोका। यह अच्छी स्थिति है, क्योंकि failure उस समय होता है जब machine अभी चल रही होती है और आपके पास shell उपलब्ध होता है।

अब इसे चलाएँ:

sudo dnf offline status
sudo dnf system-upgrade reboot

dnf offline status पुष्टि करता है कि transaction stage होकर प्रतीक्षा कर रही है। dnf system-upgrade reboot machine को offline transaction के लिए restart करता है। इसमें minimal boot होता है और RPM transaction अपने-आप चलती है। ऐसा इसलिए किया जाता है क्योंकि running services के नीचे glibc और systemd को replace करने से system आधा-installed स्थिति में आ सकता है। पूरी transaction के दौरान आपका server unreachable रहेगा। छोटे VPS पर इसमें आम तौर पर कई मिनट लगते हैं। इसके बाद server नई release में फिर reboot होता है। दो reboots और उस अवधि के लिए योजना बनाएँ जब SSH जवाब नहीं देगा।

जब server वापस आए:

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) जैसी line print करनी चाहिए। log subcommand उस offline boot की transaction log print करता है। जब आपके पास shell नहीं था, तब क्या हुआ, इसका यही एकमात्र record होता है। distro-sync पीछे छूटे packages को नई release के versions पर लाता है। repoquery --extras उन installed packages की सूची दिखाता है जो अब किसी enabled repository में उपलब्ध नहीं हैं। यहीं आपको उस repository के leftovers मिलेंगे जिसने नई release के लिए कभी package publish नहीं किया।

Download step से पहले disk का snapshot लें। Transaction उस समय चलती है जब आप screen नहीं देख सकते। इसलिए यदि offline boot के दौरान failure होता है, तो SSH वापस नहीं आएगा। ऐसे में अंदर जाने का एकमात्र तरीका provider का console, VNC या serial होगा। शुरू करने से पहले सुनिश्चित करें कि आपके पास console या snapshot उपलब्ध है, बाद में नहीं।

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

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

जब कोई package नई default config file release करता है और आपने पुरानी file को edit किया है, तो RPM आपकी file को overwrite नहीं करता। वह packaged version को .rpmnew नाम से उसके पास लिखता है। इसलिए आपका sshd या nginx पुरानी release की तरह ही काम करता रहता है, जबकि नई defaults disk पर बिना पढ़ी पड़ी रहती हैं। हर upgrade के बाद इन files को पढ़ें। rpmconf install करके और sudo rpmconf -a चलाने पर ये files एक-एक करके दिखाई जाती हैं और उनका अंतर बताया जाता है।

तृतीय-पक्ष repositories upgrade को विफल कर सकती हैं

Fedora के अपने सभी packages release के दिन एक साथ आगे बढ़ते हैं। Fedora के बाहर के packages किसी और के schedule पर जारी होते हैं। अधिकांश vendor repositories अपने URL में $releasever रखती हैं। इसलिए upgrade करते ही dnf ऐसे path के लिए अनुरोध करना शुरू कर देता है, जो अभी मौजूद न हो।

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

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

Fedora की अपनी repository के अलावा प्रत्येक repository को upgrade शुरू करने से पहले target release के साथ जाँचें:

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

यदि vendor ने उस release के लिए package प्रकाशित किया है, तो dnf metadata download करके बिना कोई error दिखाए बंद हो जाता है। यदि package उपलब्ध नहीं है, तो https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml जैसे path के लिए 404 मिलता है। यही failure बाद में system-upgrade download को भी रोक देगा। Fedora release के बाद के पहले कुछ हफ्तों में upgrade शुरू न होने का यह सबसे सामान्य कारण है।

आपके पास दो विकल्प हैं। Vendor के package प्रकाशित करने तक कुछ हफ्ते प्रतीक्षा करें। आम तौर पर यही सही विकल्प होता है। या उस repository के बिना upgrade करें:

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 पढ़ें। इसी list के कारण लोग अक्सर वह database server खो देते हैं, जिसे वे रखना चाहते थे।

विंडो छूट जाने पर Fedora server के साथ क्या होता है

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

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

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

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

Automatic updates किसी release में patches लागू करते हैं। वे release को कभी upgrade नहीं करते।

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

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

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

इससे आप किसी release के भीतर up to date रहते हैं। यह Fedora 43 को Fedora 44 में कभी नहीं ले जाएगा, क्योंकि version upgrade एक अलग और जानबूझकर किया जाने वाला operation है, जो offline transaction के लिए reboot करता है। यही LTS की तुलना में व्यावहारिक अंतर है। Ubuntu पर unattended security upgrades बिना किसी version change के पूरे five year window में machine को updated रखते हैं। Version change स्वयं कुछ वर्षों में एक बार किया जाने वाला planned job है, जैसे 24.04 से 26.04 upgrade।

जब server चलाने के लिए Fedora सही विकल्प हो

Fedora तब अच्छा विकल्प है, जब नया होना ही मुख्य आवश्यकता हो।

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

स्थिर base पर current packages: बीच का रास्ता

Server पर Fedora चाहने वाले अधिकांश लोगों को दो या तीन current packages चाहिए होते हैं, current operating system नहीं। इन दोनों को अलग रखा जा सकता है। Base के रूप में LTS या enterprise rebuild चलाएँ, फिर जहाँ वास्तव में जरूरत हो वहाँ नया software लाएँ। Container image आपको ऐसे host पर application का नया version देती है जिसे उसके लिए कभी upgrade नहीं करना पड़ता (VPS पर Docker चलाना)। PostgreSQL या nginx जैसे आपके लिए महत्वपूर्ण किसी एक package के लिए vendor repository उस package को आगे बढ़ाती है और base को यथावत रखती है।

यह समझौता दोनों दिशाओं में स्पष्ट है। Container host के पुराने kernel पर नया userspace देता है, इसलिए जब आपको kernel ही नया चाहिए तब यह मदद नहीं करता। Vendor repository ऐसे base पर एक नया package देती है जिसे vendor ने कम परीक्षण किया है। दोनों विकल्प base system के security updates को LTS schedule पर ही रखते हैं, और Fedora में हर वर्ष maintenance window की जरूरत इसी schedule के कारण पड़ती है।

यदि आप server के लिए Fedora चुनते हैं, तो release cycle को calendar में दर्ज करें। जब कोई release जारी हो, तो vendor repositories के नए version के लिए कुछ सप्ताह प्रतीक्षा करें, snapshot लें, upgrade करें, फिर verify करें कि services दोबारा start हो गई हैं। इस प्रक्रिया में वर्ष में लगभग एक घंटे लगते हैं और यह काम करती है। समस्या वाला तरीका वह है जिसमें upgrade तभी याद आता है जब कुछ पहले ही fail हो चुका हो।

FAQ

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

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

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

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

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

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

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

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