Fedora VPS सर्व्हरला दरवर्षी upgrade का करावे लागते?

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

Fedora सर्व्हर अस्तित्वात असेपर्यंत साधारण वर्षातून एकदा version upgrade आवश्यक असते. Fedora साधारण प्रत्येक सहा महिन्यांनी नवीन release प्रकाशित करते. प्रत्येक release ला त्यानंतरच्या दोन versions प्रकाशित झाल्यानंतर आणखी साधारण चार आठवडे 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 मध्ये प्रकाशित झाला आणि May 2026 मध्ये end of life झाला, म्हणजे Fedora 44 उपलब्ध झाल्यानंतर चार आठवड्यांनी. त्यामुळे Fedora 42 image वर तयार केलेला सर्व्हर तेरा महिन्यांनंतर support बाहेर गेला; त्यासाठी कोणाचीही चूक असणे आवश्यक नव्हते.

Fedora आणि LTS यांची महिन्यांतील तुलना

LTS म्हणजे long term support: vendor काही महिन्यांऐवजी अनेक वर्षे ज्या release साठी 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 देते, तर AlmaLinux सारखी enterprise rebuild 120 देते. दुसरा column तुमच्यावर येणारा upgrade भार दर्शवतो. दहा वर्षांत 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 करण्याची गरज नाही. सध्याच्या release पासून सुरुवात करा आणि ती पूर्णपणे patched आहे याची खात्री करा:

sudo dnf upgrade --refresh
sudo reboot

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

sudo dnf system-upgrade download --releasever=44

यामुळे संपूर्ण transaction resolve होते आणि प्रत्येक package download होते. Running system मध्ये कोणताही बदल होत नाही. छोट्या server वर काही हजार packages आणि एक ते तीन gigabytes अपेक्षित ठेवा. dnf ला transaction resolve करता आला नाही, तर ते याच टप्प्यावर थांबते आणि कोणत्या package मुळे अडथळा आला ते दाखवते. ही चांगली परिस्थिती आहे, कारण machine अजून सुरू असताना आणि तुमच्याकडे shell असताना failure होते.

त्यानंतर ते चालवा:

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

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

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

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

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

तृतीय-पक्ष repositories मुळे upgrade अयशस्वी होते

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

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

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

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

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

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

विंडो चुकलेल्या Fedora सर्व्हरचे काय होते

त्याच दिवशी काहीही होत नाही. पुढच्या वेळी तुम्ही package manager वापरता, तेव्हा बिघाड दिसून येतो. End-of-life releases mirror network मधून archive मध्ये हलवल्या जातात. त्यामुळे release साठी metadata आणताना dnf upgrade अयशस्वी होते आणि metalink URL वर 404 दिसतो:

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

मशीन network traffic देत राहते. त्यामुळे ही समस्या शांत आणि धोकादायक ठरते. तिला security updates मिळत नाहीत. तसेच ती काहीही install करू शकत नाही. त्यामुळे OpenSSH किंवा nginx साठी security advisory प्रसिद्ध झाल्याच्या दिवशी ते patch करण्याचा समर्थित मार्ग तुमच्याकडे राहत नाही.

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

स्वयंचलित अद्यतने release वर patches लागू करतात. ती release upgrade करत नाहीत.

Fedora timer द्वारे आपली अद्यतने install करू शकते:

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

सेटिंग्ज /etc/dnf/automatic.conf मध्ये असतात. हे shipped defaults /usr/share/dnf5/dnf5-plugins/automatic.conf मध्ये override करते. apply_updates default ने off असते. त्यामुळे सुरुवातीच्या configuration मध्ये timer अद्यतने download करतो, पण काहीही install करत नाही. upgrade_type हे default आणि security यांपैकी निवड करते. reboot मध्ये never, when-changed किंवा when-needed स्वीकारले जातात.

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

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

नवीनतम सॉफ्टवेअर वापरणे हा उद्देश असेल, तेव्हा Fedora योग्य पर्याय ठरतो.

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

स्थिर base वर अद्ययावत packages: मध्यम मार्ग

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

या पर्यायांमधील तडजोड दोन्ही बाजूंनी स्पष्ट आहे. 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 आवृत्तीला किती काळ समर्थन मिळते?

सुमारे 13 महिने. Fedora साधारणपणे दर सहा महिन्यांनी एक आवृत्ती प्रकाशित करते आणि प्रत्येक आवृत्तीला तिच्यानंतर दोन आवृत्त्या प्रकाशित झाल्यानंतर सुमारे चार आठवड्यांपर्यंत समर्थन देते. Fedora 44 ही आवृत्ती 28 April 2026 रोजी प्रकाशित झाली आणि तिची end of life तारीख June 2027 साठी निश्चित आहे. ही तारीख उलटल्यानंतर त्या आवृत्तीला सुरक्षा अद्यतने मिळणे बंद होते आणि तिची पॅकेजेस mirrors वरून काढून Fedora च्या archive मध्ये हलवली जातात.

Fedora ची एखादी आवृत्ती वगळून एकाच वेळी दोन आवृत्त्यांचे upgrade करू शकतो का?

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

माझा Fedora server end of life पर्यंत पोहोचल्यास काय होते?

तो चालू राहतो, पण त्याला patch मिळणे बंद होते. पुढील dnf upgrade तुमच्या आवृत्तीसाठी असलेल्या metalink URL वर 404 सह अपयशी ठरतो, कारण end of life झालेल्या आवृत्त्या dl.fedoraproject.org येथील archive मध्ये हलवल्या जातात. तुम्ही repository files त्या archive कडे निर्देशित करून टप्प्याटप्प्याने upgrade करू शकता किंवा समर्थित आवृत्तीवर server पुन्हा तयार करू शकता. यापैकी एक कृती करेपर्यंत कोणतेही सुरक्षा अद्यतन machine पर्यंत पोहोचू शकत नाही आणि कोणतेही package install होणार नाही.

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

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