Fedora సర్వర్‌కు 13 నెలల అప్‌డేట్ గడువు ఎందుకు?

Fedora విడుదలకు ఎంతకాలం భద్రతా నవీకరణలు లభిస్తాయి?

ఒక Fedora server ఉన్నంతకాలం, దానికి సుమారు సంవత్సరానికి ఒకసారి version upgrade అవసరం అవుతుంది. Fedora సుమారు ప్రతి ఆరు నెలలకు ఒక కొత్త release ప్రచురిస్తుంది. ప్రతి release కు, దాని తర్వాత రెండు versions విడుదలైన సుమారు నాలుగు వారాల వరకు support ఉంటుంది. అంటే సుమారు 13 నెలల పాటు updates లభిస్తాయి. ఆ తేదీ తర్వాత ఆ release కు ఎలాంటి security fixes లభించవు. ఆ server పనిచేస్తూనే ఉంటుంది, కానీ దానిలోని package set ను ఇకపై ఎవరూ patch చేయరు.

తేదీలను పరిశీలిస్తే విషయం స్పష్టమవుతుంది. August 2026 నాటికి support లో ఉన్న 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తో నిర్మించిన server, ఎవరూ తప్పు చేయకపోయినా, పదమూడు నెలల తర్వాత support వెలుపలికి వెళ్లింది.

Fedora మరియు LTS: నెలల పరంగా

LTS అంటే దీర్ఘకాలిక మద్దతు. అంటే vendor కొన్ని నెలలు కాకుండా అనేక సంవత్సరాల పాటు patches అందించే release. EOL అంటే జీవితకాలం ముగింపు. అంటే 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 నెలల మద్దతు ఉంటుంది. Ubuntu LTS కు 60, AlmaLinux వంటి enterprise rebuild కు 120 నెలల మద్దతు ఉంటుంది. రెండో కాలమ్‌ను మీపై పడే నిర్వహణ భారంగా చూడండి. పది సంవత్సరాల్లో Fedora మొత్తం operating system ను సుమారు 10 సార్లు upgrade చేయాల్సి ఉంటుంది. Ubuntu LTS లో ఇది 2 upgrades. Debian లోని 36 నెలలు దాని సాధారణ security support కు సంబంధించినవి. అదనంగా, ప్రత్యేక LTS team చాలా releases కు సుమారు ఐదు సంవత్సరాల వరకు మద్దతు పొడిగిస్తుంది.

ఇవి August 2026 లో పరిశీలించిన, ప్రకటించిన support windows. ఇవి కొలిచిన uptime కాదు. Cadenceలు ఎందుకు వేర్వేరుగా ఉంటాయో సర్వర్‌లో Ubuntu LTS మరియు interim releases మధ్య తేడాలో చూడండి. ఇక్కడ ముఖ్యమైనది, ప్రతి ఎంపిక మీకు కలిగించే నిర్వహణ పని.

Fedora version upgrade లో వాస్తవంగా జరిగేది

Fedora 41 నుంచి DNF 5 default package manager గా ఉంది, మరియు dnf దాన్ని నడుపుతుంది. system-upgrade command dnf5 లోనే భాగంగా ఉంటుంది. అందువల్ల ముందుగా plugin install చేయాల్సిన అవసరం లేదు. మీరు Debian లేదా Ubuntu box నుంచి వస్తే, రోజువారీగా టైప్ చేసే చాలా commands కు apt నుంచి dnf కు నేరుగా సమానమైన రూపం ఉంటుంది. అయితే దిగువ version upgrade వాటిలో నిజమైన ప్రత్యామ్నాయం లేని కొద్ది పనుల్లో ఒకటి. ప్రస్తుతం ఉన్న release నుంచే ప్రారంభించండి. ముందుగా అన్ని updates install చేసి ఉండాలి:

sudo dnf upgrade --refresh
sudo reboot

Upgrade, ప్రస్తుతం install అయి నడుస్తున్న packages ఆధారంగా resolve అవుతుంది. అందువల్ల reboot చేయడం ముఖ్యం. సగం మాత్రమే వర్తించిన kernel లేదా glibc update ఉంటే తదుపరి దశను విశ్లేషించడం కష్టమవుతుంది. ఇప్పుడు కొత్త release ను సిద్ధం చేయండి. మీరు upgrade చేయబోయే release సంఖ్యతో 44 ను మార్చండి:

sudo dnf system-upgrade download --releasever=44

ఇది మొత్తం transaction ను resolve చేసి ప్రతి package ను download చేస్తుంది. నడుస్తున్న system లో మాత్రం ఎలాంటి మార్పు చేయదు. చిన్న server లో కొన్ని వేల packages, ఒకటి నుంచి మూడు gigabytes వరకు download అవుతాయని అంచనా వేయండి. dnf transaction ను resolve చేయలేకపోతే ఇక్కడే ఆగి, దాన్ని అడ్డుకున్న package పేరును చూపిస్తుంది. ఇది అనుకూలమైన పరిస్థితి. ఎందుకంటే machine ఇంకా నడుస్తూనే ఉంటుంది, మీకు shell కూడా అందుబాటులో ఉంటుంది.

తర్వాత transaction ను అమలు చేయండి:

sudo dnf offline status
sudo dnf system-upgrade reboot

dnf offline status transaction సిద్ధంగా ఉండి అమలు కోసం వేచి ఉందని నిర్ధారిస్తుంది. dnf system-upgrade reboot machine ను offline transaction mode లోకి restart చేస్తుంది. ఇది కనిష్ఠ boot environment; అందులో RPM transaction స్వతంత్రంగా నడుస్తుంది. ఈ విధానం అవసరం. ఎందుకంటే నడుస్తున్న services కింద glibc, systemd ను మార్చడం వల్ల సగం మాత్రమే install అయిన system ఏర్పడవచ్చు. మొత్తం transaction సమయంలో మీ server అందుబాటులో ఉండదు. చిన్న VPS లో ఇది సాధారణంగా కొన్ని నిమిషాలు పడుతుంది. తర్వాత అది కొత్త release లోకి మళ్లీ reboot అవుతుంది. రెండు reboots అవసరమయ్యేలా, SSH స్పందించని సమయాన్ని కూడా కలుపుకొని maintenance window ను ప్లాన్ చేయండి.

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 ఉపయోగించలేని సమయంలో ఏమి జరిగిందో తెలిపే ఏకైక record ఇదే. distro-sync మిగిలిపోయిన వాటిని కొత్త release versions కు update చేస్తుంది. ప్రస్తుతం enable చేసిన ఏ repository లోనూ లేని installed packages ను repoquery --extras చూపిస్తుంది. కొత్త release కోసం ఎప్పుడూ publish చేయని repository నుంచి మిగిలిన packages ను ఇక్కడ గుర్తించవచ్చు.

Download దశకు ముందు disk snapshot తీసుకోండి. Screen ను చూడలేని సమయంలో transaction నడుస్తుంది. Offline boot సమయంలో అది విఫలమైతే SSH తిరిగి పనిచేయదు. అప్పుడు system లోకి ప్రవేశించే మార్గం provider ఇచ్చే console, VNC లేదా serial మాత్రమే కావచ్చు. ప్రారంభించే ముందు console లేదా snapshot అందుబాటులో ఉందని నిర్ధారించండి. తర్వాత కాదు.

చాలామంది విస్మరించే మరో check:

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 ను విఫలమయ్యేలా చేస్తాయి

Fedora యొక్క స్వంత packages అన్నీ release రోజున ఒకేసారి నవీకరించబడతాయి. Fedora వెలుపలి packages ఇతరుల schedule ప్రకారం విడుదలవుతాయి. చాలా vendor repositories తమ URLలో $releasever ను ఉంచుతాయి. అందువల్ల మీరు upgrade చేసిన వెంటనే, ఇంకా అందుబాటులోకి రాని path కోసం dnf అభ్యర్థన పంపడం ప్రారంభిస్తుంది.

మీ వద్ద ఉన్న 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 కోసం packages ప్రచురించి ఉంటే, dnf metadata ను download చేసి ఎలాంటి output లేకుండా ముగుస్తుంది. లేకపోతే https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml వంటి path కు 404 వస్తుంది. తరువాత system-upgrade download వద్ద ఇదే సమస్య upgrade ను ఆపేస్తుంది. Fedora release అయిన తర్వాత మొదటి కొన్ని వారాల్లో upgrade ప్రారంభం కాకపోవడానికి ఇదే అత్యంత సాధారణ కారణం.

మీకు రెండు మార్గాలు ఉన్నాయి. Vendor packages ప్రచురించే వరకు కొన్ని వారాలు వేచి ఉండండి. సాధారణంగా ఇదే సరైన నిర్ణయం. లేదా ఆ repository లేకుండా upgrade చేయండి:

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

Repository ను disable చేయడం వల్ల దాని packages తొలగిపోవు. అవి installed గానే ఉండి, management లేకుండా కొనసాగుతాయి. అవి transaction ను అడ్డుకుంటే dnf ఆ విషయాన్ని తెలియజేస్తుంది. --allowerasing జోడిస్తే conflict పరిష్కరించడానికి dnf installed packages ను తొలగించవచ్చు. అందువల్ల అంగీకరించే ముందు removal list ను చదవండి. మీరు ఉంచాలనుకున్న database server ను కోల్పోయే పరిస్థితి తరచుగా ఆ list వల్లే ఏర్పడుతుంది.

విండోను దాటిన Fedora సర్వర్‌కు ఏమి జరుగుతుంది

ఆ రోజున ప్రత్యేకంగా ఏమీ జరగదు. మీరు తదుపరిసారి package manager ను ఉపయోగించినప్పుడు సమస్య కనిపిస్తుంది. End of life releases ను mirror network నుంచి archive కు తరలిస్తారు. అందువల్ల dnf upgrade metadata ను పొందే సమయంలో విఫలమవుతుంది. మీ release కు సంబంధించిన 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 advisory వచ్చిన రోజున దాన్ని patch చేయడానికి మీకు supported మార్గం ఉండదు.

ఈ పరిస్థితి నుంచి బయటపడవచ్చు, కానీ ప్రక్రియ నెమ్మదిగా ఉంటుంది. మీరు repositories ను Fedora archive లోని https://dl.fedoraproject.org/pub/archive/fedora/linux/ కు మార్చి, అక్కడి నుంచి upgrade చేయవచ్చు. Fedora సాధారణంగా ఒకేసారి ఒకటి లేదా రెండు releases మాత్రమే దాటాలని ఆశిస్తుంది. కాబట్టి నాలుగు releases వెనుకబడిన box కు వరుసగా అనేక hops చేయాలి. ప్రతి hop విఫలమయ్యే అవకాశం ఉంటుంది. ప్రతి hop సమయంలో offline boot లో పనిచేస్తున్నందున మీకు స్థితి స్పష్టంగా కనిపించదు. VPS విషయంలో current image తో కొత్తగా నిర్మించి, data ను దానికి తరలించడం సాధారణంగా తక్కువ సమయంలో పూర్తయ్యే మరియు సురక్షితమైన పని. ఇది కొత్త VPS పై మొదటి పది నిమిషాల్లో చేసే పనితో సమానమే.

స్వయంచాలక updates ఒక release కు patches ను వర్తింపజేస్తాయి. అవి 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 లో ఉంటాయి. ఇవి shipped defaults అయిన /usr/share/dnf5/dnf5-plugins/automatic.conf ను override చేస్తాయి. apply_updates డిఫాల్ట్‌గా off లో ఉంటుంది. అందువల్ల ప్రారంభ configuration లో timer updates ను download చేస్తుంది, కానీ ఏదీ install చేయదు. upgrade_type, default మరియు security మధ్య ఎంపిక చేస్తుంది. reboot, never, when-changed లేదా when-needed ను అంగీకరిస్తుంది.

ఇది ఒకే release పరిధిలో సిస్టమ్‌ను current గా ఉంచుతుంది. ఇది Fedora 43 ను Fedora 44 కు ఎప్పుడూ మార్చదు. కారణం, version upgrade అనేది విడిగా, ఉద్దేశపూర్వకంగా చేసే operation. ఇది offline transaction లోకి reboot చేస్తుంది. LTS తో పోలిస్తే ఇది ప్రధానమైన ప్రాయోగిక తేడా. Ubuntu లో, unattended security upgrades version మార్పు లేకుండానే పూర్తి ఐదు సంవత్సరాల కాలంలో machine ను నిర్వహిస్తాయి. Version మార్పు మాత్రం ప్రతి కొన్ని సంవత్సరాలకు ఒకసారి చేసే ప్రణాళికాబద్ధమైన పని. ఉదాహరణకు 24.04 నుంచి 26.04 కు upgrade అలాంటి పని.

సర్వర్‌ను నడపడానికి Fedora సరైన సందర్భాలు

కొత్తదనం ప్రధాన అవసరమైనప్పుడు Fedora మంచి ఎంపిక.

• ఏదైనా LTS విడుదల అందించే దానికంటే కొత్త kernel లేదా userspace అవసరమైనప్పుడు: తాజా hardware కోసం, లేదా enterprise విడుదలకు ఇంకా ఒక సంవత్సరం సమయం ఉన్న container మరియు systemd stack కోసం. Fedora ఒక విడుదల కొనసాగుతున్న సమయంలో కూడా కొత్త 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 తేదీకి ఎప్పుడూ చేరదు. coding agents కు అందించే తాత్కాలిక VMs కు కూడా ఇదే వర్తిస్తుంది. ఆ box, Fedora releases కంటే చాలా తరచుగా మళ్లీ నిర్మించబడుతుంది.
• Upgrade బాధ్యత ఒక నిర్దిష్ట వ్యక్తికి ఉన్నప్పుడు. బాధ్యత వహించే వ్యక్తి పేరు మరియు calendar entry ఉన్న serverలో Fedora అనుకూలంగా ఉంటుంది. ఎవరికీ గుర్తులేని boxకు ఇది సరైన ఎంపిక కాదు.

స్థిరమైన baseపై ప్రస్తుత packages: మధ్యమార్గం

సర్వర్‌పై Fedora కావాలనుకునే చాలా మందికి ప్రస్తుత operating system అవసరం ఉండదు; రెండు లేదా మూడు ప్రస్తుత packages మాత్రమే అవసరం. ఈ రెండింటినీ వేరు చేయవచ్చు. baseగా LTS లేదా enterprise rebuild ఉపయోగించి, నిజంగా అవసరమైన చోట మాత్రమే కొత్త softwareను తీసుకురండి. Container image ద్వారా, hostను upgrade చేయాల్సిన అవసరం లేకుండానే application యొక్క కొత్త versionను పొందవచ్చు (VPSపై Docker నడపడం). PostgreSQL లేదా nginx వంటి మీకు అవసరమైన ఒక్క package కోసం vendor repository ఉపయోగిస్తే, ఆ packageను మాత్రమే కొత్తదిగా మార్చి baseను అలాగే ఉంచవచ్చు.

ఈ మార్పిడిలో రెండు వైపుల పరిమితులు స్పష్టంగా ఉంటాయి. Container ద్వారా hostలోని పాత kernelపై కొత్త userspace లభిస్తుంది. కాబట్టి మీకు అవసరమైనది kernel అయితే అది సహాయపడదు. Vendor repository ద్వారా vendor తక్కువగా పరీక్షించిన baseపై ఒక్క కొత్త package లభిస్తుంది. రెండు విధానాల్లోనూ base system యొక్క security updates LTS షెడ్యూల్‌నే అనుసరిస్తాయి. Fedoraలో ప్రతి సంవత్సరం నిర్వహణకు ప్రత్యేక సమయం కేటాయించాల్సి రావడానికి ప్రధాన కారణం ఇదే.

మీరు సర్వర్ కోసం Fedora ఎంచుకుంటే, ఈ cycleను calendarలో నమోదు చేయండి. Release వచ్చినప్పుడు vendor repositories నవీకరించబడే వరకు కొన్ని వారాలు వేచి ఉండండి. Snapshot తీసుకుని upgrade చేయండి. తరువాత services మళ్లీ ప్రారంభమయ్యాయో లేదో నిర్ధారించండి. ఈ విధానానికి సంవత్సరానికి సుమారు ఒక గంట పడుతుంది, ఇది పనిచేస్తుంది. ఇప్పటికే ఏదైనా విఫలమైనప్పుడు మాత్రమే upgrade గుర్తుకు వచ్చే విధానమే సమస్యలకు దారితీస్తుంది.

FAQ

Fedora విడుదలకు ఎంతకాలం మద్దతు ఉంటుంది?

సుమారు 13 నెలలు. Fedora సుమారు ప్రతి ఆరు నెలలకు ఒక విడుదలను అందిస్తుంది. ప్రతి విడుదలకు, దాని తర్వాత వచ్చే రెండవ వెర్షన్ విడుదలైన సుమారు నాలుగు వారాల వరకు మద్దతు ఉంటుంది. Fedora 44 28 April 2026న విడుదలైంది. దీనికి end of life June 2027లో షెడ్యూల్ చేయబడింది. ఆ తేదీ దాటిన తర్వాత ఆ విడుదలకు security updates అందవు. దాని packages mirrors నుంచి తొలగించి Fedora archiveలో ఉంచుతారు.

Fedora విడుదలను దాటేసి, ఒకేసారి రెండు వెర్షన్లు upgrade చేయవచ్చా?

అవును, కొన్ని పరిమితులతో. dnf system-upgrade download --releasever= లక్ష్యంగా ఒకటి లేదా రెండు విడుదలలు ముందున్న releaseను అంగీకరిస్తుంది. సంవత్సరానికి ఒకసారి upgrade చేసే విధానంలో రెండు విడుదలలను ఒకేసారి దాటడం సహజమే. అంతకంటే ఎక్కువ దూరం వెళ్లడం supported path కాదు. ప్రతి అదనపు విడుదల package rename లేదా config format మార్పు కారణంగా transaction ఆగిపోయే అవకాశాన్ని పెంచుతుంది. ఒక machine ఇప్పటికే అనేక విడుదలలు వెనుకబడి, end of life దాటిపోయి ఉంటే, వరుసగా upgrades చేయడం కంటే current imageతో rebuild చేయడం సాధారణంగా వేగంగా పూర్తవుతుంది.

నా Fedora server end of lifeకు చేరితే ఏమి జరుగుతుంది?

అది నడుస్తూనే ఉంటుంది, కానీ patches అందుకోవడం ఆపేస్తుంది. మీ releaseకు సంబంధించిన metalink URLపై తదుపరి dnf upgrade 404 errorతో విఫలమవుతుంది. కారణం, end of life విడుదలలను dl.fedoraproject.orgలోని archiveకు తరలిస్తారు. మీరు repository filesలోని చిరునామాలను ఆ archiveకు మార్చి దశలవారీగా upgrade చేయవచ్చు. లేదా supported releaseపై serverను rebuild చేయవచ్చు. ఈ రెండింటిలో ఏదో ఒకటి చేసే వరకు machineకు security update చేరదు. ఏ package కూడా install కాదు.

Production serverకు Fedora అనుకూలం కాదా?

కారణం లేకుండా ఎంచుకునే defaultగా ఇది అనుకూలం కాదు. సరైన కారణం ఉంటే ఇది సముచితమైన ఎంపిక. ప్రతి సంవత్సరం పూర్తి operating system upgrade చేయాల్సి రావడం దీని ప్రధాన వ్యయం. మీరు తరచుగా మార్చకూడదనుకునే machineపై ఈ ప్రక్రియను నిరంతరం నిర్వహించాలి. LTS విడుదలలో లభించేదానికంటే కొత్త kernel లేదా userspace అవసరమైనప్పుడు Fedoraను ఎంచుకోండి. Serverను ఉద్దేశపూర్వకంగా స్వల్పకాలం మాత్రమే ఉపయోగించనున్నప్పుడు కూడా Fedora అనుకూలంగా ఉంటుంది. Versionను మార్చకుండా సంవత్సరాల పాటు serverను patch చేయాలనుకుంటే LTS లేదా enterprise rebuildను ఎంచుకోండి.