Fedora server sa VPS: gaano katagal ang support?

Gaano katagal tumatanggap ng security updates ang isang Fedora release?

Ang Fedora server ay nangangailangan ng version upgrade halos isang beses bawat taon, habang ginagamit pa ang machine. Naglalabas ang Fedora ng bagong release humigit-kumulang bawat anim na buwan. Sinusuportahan ang bawat release hanggang mga apat na linggo matapos ilabas ang release na dalawang bersyon ang pagitan, na katumbas ng humigit-kumulang 13 buwan ng updates. Pagkatapos ng petsang iyon, wala nang security fixes na matatanggap ang release. Patuloy pa ring tatakbo ang server, pero wala nang nagpa-patch sa package set nito.

Mas malinaw ito kapag tiningnan ang mga petsa. Noong Agosto 2026, ang mga supported release ay Fedora 43 at Fedora 44. Inilabas ang Fedora 44 noong 28 Abril 2026, at nakatakdang mag-end of life ito sa Hunyo 2027. Inilabas ang Fedora 42 noong Abril 2025 at nag-end of life noong Mayo 2026, apat na linggo matapos dumating ang Fedora 44. Dahil dito, ang server na ginawa mula sa Fedora 42 image ay wala nang support pagkalipas ng labintatlong buwan, kahit walang nagkamali.

Fedora kumpara sa LTS, sa bilang ng buwan

Ang LTS ay nangangahulugang long term support: release na patuloy na nilalagyan ng vendor ng patches sa loob ng mga taon sa halip na mga buwan. Ang EOL ay nangangahulugang end of life, o ang petsa kung kailan ihihinto ang mga patch. Narito ang inilalathala ng bawat project para sa release na ii-install mo ngayon.

[
  {
    "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
  }
]

Nagbibigay ang Fedora ng 13 buwan ng support para sa bawat release. Ang isang Ubuntu LTS ay nagbibigay ng 60, at ang enterprise rebuild gaya ng AlmaLinux ay nagbibigay ng 120. Ituring ang ikalawang column bilang workload. Sa loob ng sampung taon, nangangailangan ang Fedora ng humigit-kumulang 10 upgrade ng buong operating system, kumpara sa 2 para sa Ubuntu LTS. Ang halagang 36 buwan para sa Debian ay tumutukoy sa regular nitong security support, at pinalalawig ng hiwalay na LTS team ang karamihan ng release hanggang humigit-kumulang limang taon.

Ang mga ito ay mga inilathalang support window na sinuri noong August 2026, hindi aktuwal na uptime. Ang dahilan ng pagkakaiba ng cadence ay ipinaliwanag sa pagkakaiba ng Ubuntu LTS at interim release sa isang server. Ang mahalaga rito ay ang workload na nililikha ng bawat isa para sa iyo.

Ano talaga ang saklaw ng pag-upgrade ng bersyon ng Fedora

Ang DNF 5 ang default na package manager mula Fedora 41, at pinapatakbo ito ng dnf. Bahagi mismo ng dnf5 ang command na system-upgrade, kaya wala nang plugin na kailangang i-install muna. Kung galing ka sa Debian o Ubuntu server, karamihan ng mga command na karaniwan mong tina-type araw-araw ay may direktang katumbas mula apt papuntang dnf, at ang pag-upgrade ng bersyon sa ibaba ay isa sa iilang gawaing walang tunay na katumbas. Magsimula sa kasalukuyang release na ganap nang may mga patch:

sudo dnf upgrade --refresh
sudo reboot

Mahalaga ang reboot dahil ibinabatay ng upgrade ang resolution sa mga naka-install at kasalukuyang tumatakbong package. Kaya nagiging mahirap suriin ang susunod na hakbang kapag kalahating nailapat ang kernel o glibc update. Ihanda ngayon ang bagong release. Palitan ang 44 ng release na lilipatan mo:

sudo dnf system-upgrade download --releasever=44

Nire-resolve nito ang buong transaction at dina-download ang bawat package. Wala itong binabago sa kasalukuyang tumatakbong system. Asahan ang ilang libong package at isa hanggang tatlong gigabyte sa isang maliit na server. Kung hindi ma-resolve ng dnf ang transaction, hihinto ito rito at sasabihin kung aling package ang nag-block dito. Mabuting sitwasyon ito dahil nangyayari ang failure habang tumatakbo pa ang machine at may shell ka pa.

Pagkatapos, patakbuhin ito:

sudo dnf offline status
sudo dnf system-upgrade reboot

Kinukumpirma ng dnf offline status na naka-stage at naghihintay ang isang transaction. Nire-restart ng dnf system-upgrade reboot ang machine papunta sa isang offline transaction: isang minimal na boot kung saan kusang tumatakbo ang RPM transaction. Ganito ito gumagana dahil ang pagpapalit ng glibc at systemd habang tumatakbo ang mga serbisyo ay maaaring mag-iwan ng kalahating naka-install na system. Hindi maa-access ang server sa buong transaction, karaniwan nang ilang minuto sa isang maliit na VPS, at pagkatapos ay muli itong magre-reboot papunta sa bagong release. Maglaan ng dalawang reboot at ng panahong hindi sasagot ang SSH.

Kapag bumalik na ito:

cat /etc/fedora-release
sudo dnf system-upgrade log --number=-1
sudo dnf distro-sync
sudo dnf repoquery --extras

Dapat mag-print ang /etc/fedora-release ng linyang tulad ng Fedora release 44 (Forty Four). Ipinapakita ng log subcommand ang transaction log mula sa offline boot na iyon. Ito lamang ang record ng nangyari habang wala kang shell. Kinukuha ng distro-sync ang anumang naiwan at ina-update ito sa mga bersyon ng bagong release. Inililista ng repoquery --extras ang mga naka-install na package na wala na sa alinmang enabled repository. Dito mo makikita ang mga natira mula sa repository na hindi naglabas ng package para sa bagong release.

Gumawa ng snapshot ng disk bago ang download step. Tumatakbo ang transaction habang hindi mo nakikita ang screen. Kaya kung mag-fail ito sa offline boot, hindi na babalik ang SSH at ang tanging paraan para makapasok ay ang console na ibinibigay ng provider, gaya ng VNC o serial. Kumpirmahing mayroon kang console o snapshot bago magsimula, hindi pagkatapos.

May isa pang check na madalas nalalaktawan:

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

Kapag naglabas ang isang package ng bagong default config file at na-edit mo ang lumang file, hindi ito o-overwrite ng RPM. Isinusulat nito ang packaged version sa tabi nito bilang .rpmnew. Kaya patuloy na gagana ang sshd o nginx nang eksaktong gaya noong lumang release, habang hindi pa nababasa sa disk ang mga bagong default. Basahin ang mga file na ito pagkatapos ng bawat upgrade. Kapag nag-install ka ng rpmconf at pinatakbo ang sudo rpmconf -a, isa-isa nitong bubuksan ang mga file at ipapakita ang pagkakaiba.

Ang mga third-party repository ang karaniwang nakakasira sa upgrade

Sabay-sabay gumagalaw ang sariling packages ng Fedora sa araw ng release. Ang anumang package mula sa labas ng Fedora ay sumusunod sa iskedyul ng ibang vendor. Karamihan sa mga vendor repository ay may $releasever sa URL nito, kaya kapag nag-upgrade ka, hihingi ang dnf ng path na maaaring wala pa.

Ilista ang mga mayroon ka:

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

Para sa bawat repository na hindi sariling repository ng Fedora, subukan muna ito sa target release bago ka magpatuloy:

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

Kung nag-publish na ang vendor para sa release na iyon, ida-download ng dnf ang metadata at tahimik na lalabas. Kung hindi, makakakuha ka ng 404 para sa path na gaya ng https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml, at hihinto rin ang parehong failure sa system-upgrade download sa susunod. Sa mga unang linggo pagkatapos ng Fedora release, ito ang pinakakaraniwang dahilan kung bakit hindi nagsisimula ang upgrade.

Mayroon kang dalawang opsyon. Maghintay ng ilang linggo hanggang mag-publish ang vendor; karaniwan, ito ang tamang hakbang. O mag-upgrade nang hindi ginagamit ang repository na iyon:

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

Hindi inaalis ng pag-disable ng repository ang mga package nito. Nananatiling naka-install at unmanaged ang mga ito, at kung hinaharangan nila ang transaction, sasabihin ito ng dnf. Kapag idinagdag ang --allowerasing, maaari nitong alisin ang mga naka-install na package para malutas ang conflict, kaya basahin muna ang removal list bago ito tanggapin. Sa listahang iyon kadalasang hindi sinasadyang naaalis ang database server na nais mong panatilihin.

Ano ang nangyayari sa isang Fedora server na hindi nakaabot sa window

Walang nangyayari sa mismong araw. Lumilitaw ang failure sa susunod na paggamit mo ng package manager. Inililipat ang mga release na end of life mula sa mirror network papunta sa archive, kaya dnf upgrade ay nagfa-fail habang kinukuha ang metadata, at nagbabalik ng 404 ang metalink URL para sa release mo:

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

Patuloy na nagsi-serve ng traffic ang machine, kaya tahimik ngunit mapanganib ang sitwasyong ito. Hindi ito nakatatanggap ng security updates. Hindi rin ito makapag-install ng anuman. Kaya kapag may inilabas na advisory para sa OpenSSH o nginx, wala kang suportadong paraan para mag-apply ng patch.

Posibleng makaalis sa sitwasyong ito, ngunit mabagal ang proseso. Maaari mong ituro ang repositories sa Fedora archive sa https://dl.fedoraproject.org/pub/archive/fedora/linux/ at mag-upgrade mula roon. Inaasahan ng Fedora ang pagtalon ng isa o dalawang release sa bawat pagkakataon. Kaya ang isang box na apat na release ang nahuhuli ay nangangailangan ng ilang sunod-sunod na hop. May sariling posibilidad na mag-fail ang bawat hop. Isinasagawa rin ang bawat isa nang walang gabay mula sa system habang offline ang boot. Sa isang VPS, karaniwang mas maikli at mas ligtas na trabaho ang pag-rebuild gamit ang kasalukuyang image at paglilipat ng data. Pareho rin itong proseso ng unang sampung minuto sa isang bagong VPS.

Ang automatic updates ay naglalapat ng patch sa isang release. Hindi nito ina-upgrade ang release.

Maaaring i-install ng Fedora ang mga update ayon sa timer:

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

Nasa /etc/dnf/automatic.conf ang mga setting. Pinapalitan ng mga ito ang mga default na kasama sa release sa /usr/share/dnf5/dnf5-plugins/automatic.conf. Naka-off bilang default ang apply_updates. Kaya sa default na configuration, dina-download ng timer ang mga update pero walang ini-install. Pinipili ng upgrade_type kung gagamit ng default o security. Tinatanggap ng reboot ang never, when-changed, o when-needed.

Pinananatili ka nitong updated sa loob ng kasalukuyang release. Hindi nito kailanman ia-upgrade ang Fedora 43 sa Fedora 44, dahil hiwalay at sadyang isinasagawa ang version upgrade. Nagre-reboot ito para magsagawa ng offline transaction. Ito ang praktikal na kakulangan nito kumpara sa isang LTS. Sa Ubuntu, pinananatili ng mga unattended security upgrade na updated ang machine sa buong limang-taong panahon nang walang anumang version change. Ang mismong version change ay hiwalay na planadong gawain, gaya ng pag-upgrade mula 24.04 patungong 26.04, na isinasagawa kada ilang taon.

Kapag ang Fedora ang tamang server na gamitin

Magandang piliin ang Fedora kapag mahalaga ang pagiging bago nito.

• Kailangan mo ng kernel o userspace na mas bago kaysa sa anumang ipinapadala ng LTS: para sa bagong hardware, o sa container at systemd stack na isang taon pa bago maging available sa isang enterprise release. Nagpapalit din ang Fedora sa mga bagong upstream kernel habang tumatakbo ang isang release, kaya hindi lang ito panandaliang pakinabang sa oras ng installation.
• Sinusuri mo kung ano ang papunta sa RHEL (Red Hat Enterprise Linux). Ang Fedora ang pinagmumulan ng CentOS Stream, at ang CentOS Stream ang pinagmumulan ng RHEL. Dahil dito, ang software na nagbu-build at tumatakbo sa Fedora ngayon ay sinusubukan laban sa enterprise platform na maaaring gamitin pagkalipas ng ilang taon.
• Sadyang panandalian ang paggamit sa machine. Ang build runner o test box na dine-delete pagkalipas ng dalawang buwan ay hindi umaabot sa end-of-life date nito. Saklaw din nito ang mga disposable VM na ibinibigay mo sa coding agents, kung saan mas madalas i-rebuild ang box kaysa sa pag-release ng Fedora.
• May taong responsable sa upgrade. Ayos ang Fedora sa server na may itinalagang owner at nakatakdang entry sa calendar. Hindi ito magandang piliin para sa box na kinalimutan na ng lahat.

Ang gitnang landas: kasalukuyang packages sa stable na base

Karamihan sa mga gustong gumamit ng Fedora sa server ay nangangailangan lamang ng dalawa o tatlong kasalukuyang package, hindi ng kasalukuyang operating system. Magkahiwalay ang mga ito. Gamitin ang LTS o enterprise rebuild bilang base, pagkatapos ay kunin lamang ang bagong software kung saan mo talaga ito kailangan. Nagbibigay ang isang container image ng bagong bersyon ng application sa isang host na hindi mo kailangang i-upgrade para rito (pagpapatakbo ng Docker sa isang VPS). Ang vendor repository para sa iisang package na kailangan mo, gaya ng PostgreSQL o nginx, ang mag-a-update sa package na iyon at hindi gagalawin ang base.

Malinaw ang kapalit sa dalawang panig. Nagbibigay ang container ng bagong userspace sa lumang kernel ng host, kaya hindi ito makatutulong kung ang kernel ang kailangan mong baguhin. Nagbibigay naman ang vendor repository ng isang bagong package sa base na mas kaunting nasubukan ng vendor. Sa dalawang paraan, nananatili sa iskedyul ng LTS ang security updates ng base system, at ang iskedyul na iyon ang nagrerequire ng maintenance window bawat taon kapag Fedora ang gamit.

Kung pipiliin mong gumamit ng Fedora sa server, ilagay sa calendar ang release cycle. Kapag nag-release ng bagong bersyon, maghintay ng ilang linggo para makahabol ang vendor repositories, gumawa ng snapshot, mag-upgrade, at pagkatapos ay i-verify na muling gumana ang mga serbisyo. Humigit-kumulang isang oras bawat taon ang kailangan sa prosesong ito, at maaasahan ito. Nabibigo ang proseso kapag naaalala lamang ang upgrade dahil may nasira na.

FAQ

Gaano katagal sinusuportahan ang isang Fedora release?

Humigit-kumulang 13 buwan. Naglalabas ang Fedora ng bagong release humigit-kumulang bawat anim na buwan at sinusuportahan ang bawat isa hanggang mga apat na linggo matapos ilabas ang release na dalawang version ang pagitan. Inilabas ang Fedora 44 noong 28 April 2026 at nakatakdang mawalan ng support sa June 2027. Kapag lumampas na ang petsang iyon, hindi na makatatanggap ang release ng security updates at inililipat ang mga package nito mula sa mirrors papunta sa Fedora archive.

Maaari ko bang laktawan ang isang Fedora release at mag-upgrade nang dalawang version nang sabay?

Oo, pero may limitasyon. Tumatanggap ang dnf system-upgrade download --releasever= ng target na isa o dalawang release ang layo, at ang pagtalon ng dalawang release bawat upgrade ang eksaktong paraan ng upgrade rhythm na isang beses bawat taon. Hindi suportado ang pagtalon nang higit pa rito, at sa bawat karagdagang release ay tumataas ang posibilidad na mapahinto ang transaction dahil sa pagpapalit ng pangalan ng package o pagbabago sa config format. Kung ilang release na ang nahuhuli ng isang machine at lampas na sa end of life, karaniwang mas mabilis itong i-rebuild gamit ang kasalukuyang image kaysa dumaan sa sunod-sunod na upgrade.

Ano ang mangyayari kapag umabot sa end of life ang aking Fedora server?

Patuloy itong tatakbo ngunit hindi na ito mapo-patch. Mabibigo ang susunod na dnf upgrade na may 404 sa metalink URL para sa iyong release dahil inililipat ang mga release na umabot na sa end of life sa archive sa dl.fedoraproject.org. Maaari mong ituro muli ang repository files sa archive na iyon at mag-upgrade nang paisa-isa o dalawang release bawat hakbang, o i-rebuild ang server gamit ang suportadong release. Hangga't hindi mo ginagawa ang alinman sa dalawang ito, walang security update na makararating sa machine at walang package na mai-install.

Masamang pagpili ba ang Fedora para sa isang production server?

Hindi ito magandang default na pagpili, ngunit makatuwiran ito kapag may malinaw na dahilan. Ang kapalit nito ay buong operating system upgrade bawat taon, magpakailanman, sa isang machine na maaaring mas gusto mong hindi galawin. Piliin ang Fedora kapag kailangan mo ng kernel o userspace na mas bago kaysa sa inilalabas ng isang LTS, o kapag likas na panandalian ang server. Pumili ng LTS o enterprise rebuild kapag nais mong mag-patch ng server sa loob ng maraming taon nang hindi binabago ang version nito.