Fedora serverకు security updates ఎన్ని నెలలు?

Fedora release కు ఎంతకాలం security updates లభిస్తాయి?

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

తేదీలతో ఇది స్పష్టంగా తెలుస్తుంది. August 2026 నాటికి Fedora 43 మరియు Fedora 44 supported releases గా ఉన్నాయి. 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 మరియు 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 సార్లు upgrade చేయాలని కోరుతుంది. Ubuntu LTS లో ఇది 2 upgrades. Debian యొక్క 36 నెలల గణాంకం దాని సాధారణ security support కు సంబంధించినది. ప్రత్యేక LTS team చాలా releases కు సుమారు ఐదు సంవత్సరాల వరకు support పొడిగిస్తుంది.

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

Fedora version upgrade వాస్తవంగా ఏమి కలిగి ఉంటుంది

Fedora 41 నుంచి DNF 5 డిఫాల్ట్ package manager గా ఉంది, మరియు dnf దాన్ని అమలు చేస్తుంది. system-upgrade command, dnf5 లోనే భాగంగా ఉంటుంది. అందువల్ల ముందుగా ఏ plugin ను install చేయాల్సిన అవసరం లేదు. ప్రస్తుతం ఉన్న release నుంచి ప్రారంభించి, అన్ని updates ను install చేయండి:

sudo dnf upgrade --refresh
sudo reboot

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

sudo dnf system-upgrade download --releasever=44

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

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

sudo dnf offline status
sudo dnf system-upgrade reboot

dnf offline status ద్వారా transaction staging పూర్తయి, అమలు కోసం వేచి ఉందని నిర్ధారించవచ్చు. dnf system-upgrade reboot యంత్రాన్ని offline transaction లోకి restart చేస్తుంది. ఇందులో కనిష్ఠ boot సమయంలో RPM transaction స్వతంత్రంగా నడుస్తుంది. నడుస్తున్న services కింద glibc మరియు systemd ను భర్తీ చేయడం వల్ల వ్యవస్థ సగం మాత్రమే install అయిన స్థితిలోకి వెళ్లవచ్చు. అందుకే ఇది ఈ విధంగా పనిచేస్తుంది. మొత్తం transaction సమయంలో మీ server అందుబాటులో ఉండదు. చిన్న VPS లో సాధారణంగా దీనికి కొన్ని నిమిషాలు పడతాయి. తర్వాత అది కొత్త release లోకి మళ్లీ reboot అవుతుంది. రెండు reboots మరియు 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) వంటి ఒక 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 తిరిగి అందుబాటులోకి రాదు. అప్పుడు provider అందించే console, VNC లేదా serial ద్వారా మాత్రమే server లోకి ప్రవేశించగలరు. ప్రారంభించే ముందు 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 ను అమలు చేస్తే ఆ files ను ఒక్కొక్కటిగా పరిశీలించి తేడాను చూపిస్తుంది.

మూడవ పక్ష 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ని target releaseతో పరీక్షించండి. ఏ మార్పునూ ఖరారు చేసే ముందు ఇది చేయాలి:

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

ఆ release కోసం vendor packages ప్రచురించి ఉంటే, dnf metadataను download చేసి నిశ్శబ్దంగా ముగుస్తుంది. లేకపోతే 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 తొలగిపోవు. అవి installedగానే ఉండి, నిర్వహణ లేకుండా ఉంటాయి. అవి transactionకు అడ్డంకిగా ఉంటే dnf ఆ విషయాన్ని తెలియజేస్తుంది. సంఘర్షణను పరిష్కరించడానికి installed packagesను తొలగించేందుకు --allowerasing ను జోడించవచ్చు. కాబట్టి అంగీకరించే ముందు removal listను పరిశీలించండి. మీరు ఉంచాలనుకున్న database serverను కోల్పోయే అవకాశం ఉన్నది ఈ జాబితాలోనే.

window ను కోల్పోయిన Fedora server కు ఏమవుతుంది

ఆ రోజున వెంటనే ఏమీ జరగదు. మీరు తదుపరిసారి package manager ను ఉపయోగించినప్పుడు సమస్య బయటపడుతుంది. End of life releases ను mirror network నుంచి archive కు తరలిస్తారు. అందువల్ల metadata ను పొందే సమయంలో dnf upgrade విఫలమవుతుంది. మీ release కు సంబంధించిన metalink URL పై 404 కనిపిస్తుంది:

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

ఆ machine 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 విఫలమయ్యే అవకాశం కలిగి ఉంటుంది. Offline boot లో ప్రతి hop సమయంలో మీరు పరిస్థితిని ప్రత్యక్షంగా గమనించలేరు. VPS విషయంలో current image పై తిరిగి నిర్మించి data ను తరలించడం సాధారణంగా తక్కువ సమయం పట్టే, మరింత సురక్షితమైన పని. ఇది కొత్త VPS పై మొదటి పది నిమిషాల్లో చేసే పనితో సమానమే.

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

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

సర్వర్‌గా నడపడానికి 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 పై పరీక్షించబడుతోంది.
• ఆ machine ను ఉద్దేశపూర్వకంగా తక్కువకాలం మాత్రమే ఉపయోగిస్తున్నప్పుడు. రెండు నెలల్లో తొలగించే build runner లేదా test box, దాని end of life తేదీని చేరదు. coding agents కు అందించే తాత్కాలిక VMs కు కూడా ఇదే వర్తిస్తుంది. ఆ box ను Fedora releases కంటే చాలా తరచుగా మళ్లీ build చేస్తారు.
• upgrade బాధ్యతను ఎవరో ఒకరు స్వీకరించినప్పుడు. పేరు స్పష్టంగా ఉన్న owner మరియు calendar entry ఉన్న server పై Fedora అనుకూలంగా ఉంటుంది. అందరూ మర్చిపోయిన box కు ఇది సరైన ఎంపిక కాదు.

స్థిరమైన ఆధారంపై ప్రస్తుత ప్యాకేజీలు: మధ్యస్థ మార్గం

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

ఈ మార్పిడి రెండు దిశల్లోనూ స్పష్టమైన పరిమితులను కలిగి ఉంటుంది. Container, host యొక్క పాత kernelపై కొత్త userspace ను అందిస్తుంది. కాబట్టి మీకు అవసరమైనది kernel అయితే అది సహాయపడదు. Vendor repository ద్వారా తక్కువగా పరీక్షించబడిన base systemపై ఒక్క కొత్త ప్యాకేజీ లభిస్తుంది. రెండు సందర్భాల్లోనూ 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న విడుదలైంది. దాని life cycle ముగింపు June 2027కు షెడ్యూల్ చేయబడింది. ఆ తేదీ దాటిన తర్వాత ఆ విడుదలకు security updates అందవు. దాని packages mirrors నుంచి తొలగించి Fedora archiveకు తరలిస్తారు.

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

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

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

అది నడుస్తూనే ఉంటుంది, కానీ patchలు అందుకోవడం ఆగిపోతుంది. తరువాతి dnf upgrade మీ release కోసం ఉన్న metalink URLపై 404 errorతో విఫలమవుతుంది. కారణం, end of life releasesను 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పై ఈ upgradeను నిరవధికంగా నిర్వహించాలి. LTS release అందించే దానికంటే కొత్త kernel లేదా userspace అవసరమైతే Fedoraను ఎంచుకోండి. Server స్వల్పకాలం మాత్రమే ఉండేలా రూపొందించబడి ఉంటే కూడా Fedoraను ఎంచుకోవచ్చు. Version మార్చకుండా serverకు అనేక సంవత్సరాలు patchలు అందించాలనుకుంటే LTS లేదా enterprise rebuildను ఎంచుకోండి.