Fedora सर्व्हरला किती काळ security updates मिळतात?

Fedora release ला सुरक्षा अद्यतने किती काळ मिळतात?

मशीन अस्तित्वात असेपर्यंत Fedora server ला साधारण वर्षातून एकदा version upgrade करावे लागते. Fedora साधारण दर सहा महिन्यांनी नवीन release प्रकाशित करते. प्रत्येक release ला त्यानंतरच्या दोन releases पैकी दुसरा release प्रकाशित झाल्यानंतर सुमारे चार आठवडे support मिळतो. त्यामुळे एकूण सुमारे 13 महिने अद्यतने मिळतात. त्यानंतर त्या release साठी कोणतेही security fixes मिळत नाहीत. मशीन चालू राहते; मात्र त्यातील package set वर पुढे कोणीही patches देत नाही.

तारखांमुळे हे स्पष्ट होते. August 2026 नुसार समर्थित releases Fedora 43 आणि Fedora 44 आहेत. Fedora 44 28 April 2026 रोजी प्रकाशित झाले आणि त्याची end of life June 2027 साठी नियोजित आहे. Fedora 42 April 2025 मध्ये प्रकाशित झाले आणि Fedora 44 उपलब्ध झाल्यानंतर चार आठवड्यांनी, May 2026 मध्ये, त्याची end of life झाली. त्यामुळे Fedora 42 image वर तयार केलेला server कोणीही चूक न करता काम करत असतानाही तेरा महिन्यांनी support बाहेर गेला. Fedora 45 15 September 2026 रोजी beta स्थितीत पोहोचले. ते प्रकाशित झाल्यानंतर Fedora 43 साठी सुमारे चार आठवड्यांची अद्यतने शिल्लक राहतील.

Fedora विरुद्ध LTS, महिन्यांमध्ये

LTS म्हणजे long term support: काही महिन्यांऐवजी vendor अनेक वर्षे patches देत राहतो असा release. 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 महिने support देते, तर AlmaLinux सारखा enterprise rebuild 120 महिने support देतो. दुसरा column ही तुमची किंमत समजा. दहा वर्षांच्या कालावधीत Fedora संपूर्ण operating system चे अंदाजे 10 upgrades मागते. Ubuntu LTS वर ही संख्या 2 आहे. Debian चे 36 महिने हे त्याचे नियमित security support आहे. स्वतंत्र LTS team बहुतेक releases चा support सुमारे पाच वर्षांपर्यंत वाढवते.

ही प्रकाशित support windows आहेत. त्या August 2026 मध्ये तपासल्या आहेत. त्या measured uptime नाहीत. Cadence मध्ये हा फरक का आहे, हे server वर Ubuntu LTS आणि interim releases मधील फरक येथे स्पष्ट केले आहे. येथे महत्त्वाचे म्हणजे प्रत्येक पर्यायामुळे तुमच्यावर येणारे काम.

Fedora आवृत्ती अपग्रेडमध्ये प्रत्यक्षात काय होते

Fedora 41 पासून DNF 5 हा default package manager आहे आणि dnf तो चालवते. system-upgrade command स्वतः dnf5 चाच भाग आहे, त्यामुळे आधी कोणतेही plugin install करण्याची गरज नाही. Debian किंवा Ubuntu box वरून येत असल्यास, दैनंदिन वापरातील बहुतेक commands साठी apt ते dnf चे थेट समतुल्य उपलब्ध आहे; खालील version upgrade मात्र त्याला खरे समतुल्य नसलेल्या मोजक्या कामांपैकी एक आहे. सध्याच्या release पासून सुरुवात करा आणि system पूर्णपणे patched ठेवा:

sudo dnf upgrade --refresh
sudo reboot

Upgrade installed आणि running system च्या स्थितीवर resolve होते, त्यामुळे हा reboot महत्त्वाचा आहे. अर्धवट लागू झालेला kernel किंवा glibc update असल्यास पुढील पायरी समजून घेणे कठीण होते. आता नवीन release stage करा. ज्या release वर upgrade करायचे आहे त्यानुसार 44 बदला:

sudo dnf system-upgrade download --releasever=44

यामुळे संपूर्ण transaction resolve होतो आणि प्रत्येक package download होतो; running system मध्ये मात्र कोणताही बदल होत नाही. लहान server वर काही हजार packages आणि एक ते तीन gigabytes अपेक्षित ठेवा. 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 बदलल्यास system अर्धवट install झालेल्या स्थितीत जाऊ शकतो. म्हणून ही प्रक्रिया अशा प्रकारे चालते. संपूर्ण transaction दरम्यान तुमचा server unreachable राहतो. लहान VPS वर यासाठी साधारणपणे काही मिनिटे लागतात आणि त्यानंतर machine पुन्हा नवीन release मध्ये reboot होते. दोन reboots आणि SSH प्रतिसाद देत नसलेला कालावधी गृहीत धरून नियोजन करा.

Machine परत उपलब्ध झाल्यावर:

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 subcommand त्या offline boot मधील transaction log दाखवते. Shell उपलब्ध नसताना काय झाले याची हीच नोंद असते. distro-sync मागे राहिलेल्या सर्व गोष्टी नवीन release च्या versions वर आणते. repoquery --extras कोणत्याही enabled repository मध्ये आता उपलब्ध नसलेली installed packages दाखवते. नवीन release साठी कधीही publish न झालेल्या repository मधील उरलेले packages येथे सापडतात.

Download step पूर्वी disk चा snapshot घ्या. Screen पाहता येत नसताना transaction चालतो. त्यामुळे offline boot दरम्यान failure झाल्यास SSH पुन्हा उपलब्ध होणार नाही. प्रवेशाचा एकमेव मार्ग provider देत असलेला console, VNC किंवा serial असेल. सुरुवात करण्यापूर्वी console किंवा snapshot उपलब्ध असल्याची खात्री करा; failure झाल्यानंतर नाही.

लोक अनेकदा वगळतात अशी आणखी एक तपासणी:

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

Package नवीन default config file देत असताना तुम्ही जुनी file संपादित केली असल्यास RPM तुमची file overwrite करत नाही. त्याऐवजी तो packaged version .rpmnew म्हणून तिच्या शेजारी लिहितो. त्यामुळे तुमचा sshd किंवा nginx जुन्या release प्रमाणेच कार्य करत राहतो, आणि नवीन defaults disk वर न वाचलेले पडून राहतात. प्रत्येक upgrade नंतर या files वाचा. rpmconf install करून sudo rpmconf -a चालवल्यास त्या एकावेळी एक उघडतात आणि फरक दाखवतात.

तृतीय-पक्ष repositories मुळे upgrade अपयशी ठरते

Release day ला Fedora ची स्वतःची सर्व packages एकत्रितपणे पुढे जातात. Fedora बाहेरील packages इतरांच्या वेळापत्रकानुसार पुढे जातात. बहुतेक 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 साठी, कोणताही बदल निश्चित करण्यापूर्वी ते target release सोबत तपासा:

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

Vendor ने त्या release साठी repository प्रकाशित केली असल्यास, dnf metadata download करून शांतपणे बंद होते. तसे नसल्यास, https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml सारख्या path साठी 404 मिळतो आणि पुढे system-upgrade download मध्येही हीच त्रुटी upgrade थांबवते. Fedora release नंतरच्या पहिल्या काही आठवड्यांत upgrade सुरू न होण्याचे हे सर्वात सामान्य कारण असते.

तुमच्याकडे दोन पर्याय आहेत. Vendor ने repository प्रकाशित करेपर्यंत काही आठवडे प्रतीक्षा करा. सामान्यतः हाच योग्य पर्याय असतो. किंवा त्या repository शिवाय upgrade करा:

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

Repository disable केल्याने त्यातील packages काढल्या जात नाहीत. त्या installed आणि unmanaged स्थितीत राहतात. त्या transaction मध्ये अडथळा आणत असल्यास dnf ते स्पष्टपणे सांगते. --allowerasing जोडल्यास conflict सोडवण्यासाठी dnf installed packages काढू शकते. त्यामुळे स्वीकारण्यापूर्वी removal list वाचा. याच list मुळे ठेवायचा database server अनेकदा काढला जातो.

Fedora server ही कालमर्यादा चुकवल्यावर काय होते

त्या दिवशी काहीही होत नाही आणि त्यानंतरही काही ठळकपणे बिघडत नाही. Fedora ची mirror service end of life झालेल्या releases साठीही प्रतिसाद देत राहते. तुमच्या release साठीचा metalink URL अजूनही mirrors ची वैध यादी परत करतो. ते mirrors आता तुमचा release Fedora च्या archive tree मधून उपलब्ध करून देतात, dl.fedoraproject.org यासह. त्यामुळे dnf upgrade अजूनही metadata fetch करते, नवीन काहीही सापडत नाही आणि मशीन अद्ययावत असल्याप्रमाणे exit होते. Fedora ने कधीही उपलब्ध न केलेल्या release साठीच metalink service 404 परत करते. 10 October 2026 नुसार हे May 2026 मध्ये निवृत्त झालेल्या Fedora 42 साठी आणि Fedora 20 इतक्या जुन्या releases साठी लागू आहे. तुमचा release कुठून उपलब्ध करून दिला जात आहे ते पाहण्यासाठी:

curl -s 'https://mirrors.fedoraproject.org/metalink?repo=fedora-42&arch=x86_64' | grep -m 3 archive

मशीन network traffic serve करत राहते. त्यामुळे ही स्थिती शांत आणि धोकादायक ठरते. त्या release साठी पुढे कधीही नवीन काही प्रकाशित होत नसल्यामुळे त्याला security updates मिळत नाहीत. dnf frozen archive वाचत राहते. त्यामुळे मशीनवर काहीही बिघडल्यासारखे दिसत नाही. मात्र OpenSSH किंवा nginx साठी security advisory प्रकाशित झाल्यावर तुमच्या release साठी fixed package उपलब्ध नसते आणि ते patch करण्यासाठी तुमच्याकडे समर्थित मार्ग राहत नाही.

या स्थितीतून बाहेर पडता येते, पण प्रक्रिया संथ असते. तुमच्या release चे metadata अजूनही https://dl.fedoraproject.org/pub/archive/fedora/linux/ येथील Fedora archive कडे resolve होत असल्यामुळे तुम्ही सध्याच्या स्थितीतून upgrade करू शकता. Metalink तुमच्यासाठी काम करणे थांबले तरच repository files त्या archive कडे manually वळवाव्या लागतात. Fedora एका वेळी एक किंवा दोन releases पुढे जाण्याची अपेक्षा करते. त्यामुळे चार releases मागे असलेल्या मशीनला सलग अनेक hops करावे लागतात. प्रत्येक hop अयशस्वी होण्याची स्वतंत्र शक्यता असते आणि प्रत्येक hop offline boot मध्ये अनिश्चित परिणाम देऊ शकतो. VPS वर current image वापरून पुन्हा build करून data हलवणे सहसा अधिक जलद आणि सुरक्षित ठरते. हे नवीन VPS वरील पहिल्या दहा मिनिटांइतकेच काम असते.

Automatic updates release ला patch करतात. ते release चे upgrade कधीही करत नाहीत.

Fedora timer नुसार updates 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 मधील shipped defaults override करतात. apply_updates default ने बंद असते. त्यामुळे सुरुवातीच्या configuration मध्ये timer updates download करते, पण काहीही install करत नाही. upgrade_type, default, security आणि distro-sync यांपैकी निवड करते. reboot मध्ये never, when-changed किंवा when-needed स्वीकारले जातात.

यामुळे तुम्ही एका release च्या मर्यादेत अद्ययावत राहता. ते Fedora 43 ला Fedora 44 मध्ये कधीही बदलणार नाही, कारण version upgrade ही स्वतंत्र आणि जाणीवपूर्वक करायची प्रक्रिया आहे. त्यात offline transaction साठी reboot केले जाते. LTS च्या तुलनेत हीच व्यावहारिक मर्यादा आहे. Ubuntu वर unattended security upgrades कोणताही version change न करता मशीनला संपूर्ण पाच वर्षांच्या कालावधीत patch करत राहतात. Version change स्वतः काही वर्षांनी एकदा करायचे नियोजित काम असते, जसे 24.04 ते 26.04 upgrade.

सर्व्हर चालवण्यासाठी Fedora योग्य कधी ठरते

नवीनतम सॉफ्टवेअर हीच मुख्य गरज असेल, तेव्हा Fedora योग्य पर्याय ठरते.

• कोणत्याही LTS आवृत्तीत उपलब्ध नसलेले अधिक नवीन kernel किंवा userspace आवश्यक असेल: उदाहरणार्थ, अलीकडील hardware किंवा enterprise release उपलब्ध होण्यास अजून एक वर्ष लागणारा container आणि systemd stack. Fedora एखाद्या release च्या कालावधीतही नवीन upstream kernels स्वीकारते. त्यामुळे हा फायदा फक्त installation च्या वेळी एकदाच मिळत नाही.
• RHEL (Red Hat Enterprise Linux) मध्ये पुढे समाविष्ट होणाऱ्या सॉफ्टवेअरचे validation करायचे असेल. Fedora मधून CentOS Stream आणि CentOS Stream मधून RHEL तयार होते. त्यामुळे आज Fedora वर build आणि run होणाऱ्या सॉफ्टवेअरची काही वर्षांनंतरच्या enterprise platform विरुद्ध चाचणी होत असते.
• मशीनचे आयुष्य आधीपासूनच कमी ठेवलेले असेल. दोन महिन्यांत नष्ट केला जाणारा build runner किंवा test box त्याच्या end of life तारखेपर्यंत पोहोचत नाही. coding agents ना देण्यात येणाऱ्या disposable VMs साठीही हेच लागू होते; अशा VM ची पुनर्बांधणी Fedora releases पेक्षा खूप अधिक वेळा केली जाते.
• upgrade ची जबाबदारी कोणीतरी निश्चितपणे घेत असेल. स्पष्ट जबाबदार व्यक्ती आणि calendar entry असलेल्या server वर Fedora योग्य आहे. मात्र ज्याची जबाबदारी कोणीही घेतलेली नाही अशा मशीनसाठी Fedora योग्य पर्याय नाही.

स्थिर बेसवर सध्याची पॅकेजेस: मध्यम मार्ग

सर्व्हरसाठी Fedora हवे असलेल्या बहुतेक लोकांना दोन किंवा तीन सध्याची पॅकेजेस हवी असतात; त्यांना सध्याची operating system आवश्यक नसते. हे दोन्ही वेगळे ठेवता येतात. बेस म्हणून LTS किंवा enterprise rebuild वापरा. त्यानंतर जिथे प्रत्यक्ष गरज आहे तिथे नवीन software आणा. Container image मुळे अशा host वर application ची नवीन version मिळते, ज्यासाठी host upgrade करण्याची गरज नसते (VPS वर Docker चालवणे). PostgreSQL किंवा nginx सारख्या तुम्हाला आवश्यक असलेल्या एकाच package साठी vendor repository वापरल्यास ते एक package नवीन version कडे जाते आणि base मध्ये बदल होत नाही.

या दोन्ही पर्यायांतील तडजोड स्पष्ट आहे. Container मुळे host च्या जुन्या kernel वर नवीन userspace मिळतो. त्यामुळे kernel मध्येच बदल आवश्यक असल्यास container उपयोगी ठरत नाही. Vendor repository मुळे vendor ने कमी तपासलेल्या base वर एक नवीन package मिळते. दोन्ही पर्यायांत base system चे security updates LTS च्या वेळापत्रकानुसारच येतात. Fedora वरील दरवर्षी maintenance window आवश्यक होण्याचे मुख्य कारण हेच वेळापत्रक आहे.

तरीही सर्व्हरसाठी Fedora निवडत असाल, तर release cycle calendar मध्ये नोंदवा. नवीन release उपलब्ध झाल्यावर vendor repositories अद्ययावत होईपर्यंत काही आठवडे प्रतीक्षा करा. Snapshot घ्या, upgrade करा आणि त्यानंतर सेवा पुन्हा सुरू झाल्या आहेत का ते तपासा. या पद्धतीसाठी वर्षाला साधारण एक तास लागतो आणि ती कार्यक्षम आहे. Upgrade फक्त काहीतरी आधीच बिघडल्यानंतरच आठवते, अशी पद्धत अपयशी ठरते.

FAQ

Fedora release ला किती काळ support मिळतो?

सुमारे 13 महिने. Fedora साधारण दर सहा महिन्यांनी release प्रकाशित करते आणि त्यानंतरच्या दोन releases पैकी दुसरा release प्रकाशित झाल्यानंतर सुमारे चार आठवड्यांपर्यंत प्रत्येक release ला support देते. Fedora 44 28 April 2026 रोजी प्रकाशित झाले आणि त्याची end of life June 2027 साठी नियोजित आहे. ही तारीख उलटल्यानंतर त्या release ला security updates मिळणे थांबते आणि त्याची packages Fedora archive मध्ये हलवली जातात. dnf त्या packages वाचू शकते, पण archive मध्ये पुढे कोणताही बदल होत नाही.

Fedora release वगळून दोन versions ने एकाच वेळी upgrade करू शकतो का?

होय, काही मर्यादांसह. dnf system-upgrade download --releasever= एक किंवा दोन releases पुढील target स्वीकारते. वर्षातून एकदा upgrade करण्याच्या पद्धतीत दोन releases ने पुढे जाणे अपेक्षितच आहे. त्यापेक्षा पुढे जाणे समर्थित मार्ग नाही. प्रत्येक अतिरिक्त release मुळे package rename किंवा config format change मुळे transaction थांबण्याची शक्यता वाढते. मशीन आधीच अनेक releases मागे असेल आणि तिची end of life झालेली असेल, तर upgrades ची साखळी करण्यापेक्षा current image वर पुन्हा build करणे सामान्यतः जलद असते.

माझ्या Fedora server ची end of life झाल्यावर काय होते?

तो चालू राहतो, पण त्याला patches मिळणे थांबते. पुढील dnf upgrade error शिवाय चालते, कारण Fedora ची mirror service तुमच्या release ला त्याच्या archive copy कडे, dl.fedoraproject.org यासह, निर्देशित करत राहते. मात्र तिथे नवीन काहीही सापडत नाही. त्यामुळे मशीनवर कोणतीही सूचना दिसत नाही. त्यानंतर तुम्ही hops करून upgrade करू शकता किंवा समर्थित release वर server पुन्हा build करू शकता. यापैकी एकही काम करेपर्यंत त्या मशीनसाठी कोणतेही security update प्रकाशित होणार नाही.

Production server साठी Fedora हा खराब पर्याय आहे का?

तो default म्हणून खराब पर्याय आहे; मात्र योग्य कारण असल्यास तो वाजवी पर्याय ठरू शकतो. त्याची किंमत म्हणजे दरवर्षी, कायमस्वरूपी, संपूर्ण operating system upgrade करणे. तुम्हाला शक्यतो हात न लावता ठेवायच्या मशीनवर हे करावे लागते. LTS मध्ये उपलब्ध असलेल्या आवृत्तीपेक्षा नवीन kernel किंवा userspace आवश्यक असल्यास, किंवा server मुळातच अल्पकाळासाठी वापरण्याचा असल्यास Fedora निवडा. Version न बदलता अनेक वर्षे server patch करायचा असल्यास LTS किंवा enterprise rebuild निवडा.