Fedora server sa VPS: 13 buwan lang ang support

Gaano katagal tumatanggap ng security updates ang isang Fedora release?

Kailangang mag-upgrade ng version ang isang Fedora server humigit-kumulang isang beses bawat taon, hangga't ginagamit ang machine. Naglalabas ang Fedora ng bagong release humigit-kumulang bawat anim na buwan. Sinusuportahan ang bawat release hanggang humigit-kumulang apat na linggo pagkatapos ilabas ang release na dalawang version ang pagitan, kaya tumatanggap ito ng updates sa loob ng humigit-kumulang 13 buwan. Pagkatapos ng petsang iyon, wala nang security fixes ang release. Patuloy na 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 pagkatapos 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 may ginawang mali.

Fedora kumpara sa isang LTS, sa bilang ng buwan

Ang LTS ay nangangahulugang long term support: isang release na patuloy na bina-patch ng vendor sa loob ng mga taon sa halip na mga buwan. Ang EOL ay nangangahulugang end of life, ang petsa kung kailan ihihinto ang mga patch. Narito ang inilalathala ng bawat project para sa release na maaari mong i-install 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 bawat release. Nagbibigay ang Ubuntu LTS ng 60, habang ang enterprise rebuild gaya ng AlmaLinux ay nagbibigay ng 120. Ituring ang ikalawang column bilang kabuuang maintenance na kakailanganin. Sa loob ng sampung taon, nangangailangan ang Fedora ng humigit-kumulang 10 upgrades ng buong operating system, kumpara sa 2 para sa Ubuntu LTS. Ang 36 buwan para sa Debian ay tumutukoy sa regular nitong security support, at pinalalawig ng hiwalay na LTS team ang karamihan ng mga release hanggang humigit-kumulang limang taon.

Ito ang mga inilathalang support window, na sinuri noong August 2026, at hindi mga sukat ng uptime. Ang dahilan ng pagkakaiba ng mga cadence ay nasa pagkakaiba ng Ubuntu LTS at interim releases sa isang server. Ang mahalaga rito ay ang trabahong nalilikha ng bawat opsyon para sa iyo.

Ano talaga ang kasama sa pag-upgrade ng Fedora version

Ang DNF 5 ang default package manager mula Fedora 41, at pinapatakbo ito ng dnf. Bahagi mismo ng dnf5 ang command na system-upgrade, kaya wala nang kailangang i-install na plugin muna. Magsimula sa kasalukuyang release na kumpletong may patch:

sudo dnf upgrade --refresh
sudo reboot

Mahalaga ang reboot dahil nireresolba ng upgrade ang mga dependency batay sa naka-install at tumatakbong system. Kaya mas mahirap tukuyin ang problema kapag kalahati pa lang ang na-apply na kernel o glibc update. Ihanda ngayon ang bagong release. Palitan ang 44 ng release na lilipatan mo:

sudo dnf system-upgrade download --releasever=44

Reresolbahin nito ang buong transaction at ida-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 maresolba ng dnf ang transaction, hihinto ito rito at ipapakita ang package na naging sanhi ng problema. Mas mabuti ito dahil nangyayari ang failure habang tumatakbo pa ang machine at mayroon ka pang shell.

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. Nirereboot ng dnf system-upgrade reboot ang machine papunta sa isang offline transaction: isang minimal boot kung saan hiwalay na tumatakbo ang RPM transaction. Ganito ito gumagana dahil maaaring magresulta sa kalahating naka-install na system ang pagpapalit ng glibc at systemd habang tumatakbo ang mga serbisyo. Hindi maa-access ang server sa buong transaction, karaniwan nang ilang minuto sa isang maliit na VPS, at magre-reboot itong muli papunta sa bagong release. Maglaan ng dalawang reboot at ng panahon kung kailan hindi sasagot ang SSH.

Kapag bumalik na online:

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 gaya ng Fedora release 44 (Forty Four). Ipinapakita ng log subcommand ang transaction log mula sa offline boot na iyon. Ito ang tanging record ng nangyari habang wala kang shell. Ina-update ng distro-sync ang anumang naiwan gamit ang mga version ng bagong release. Inililista ng repoquery --extras ang mga naka-install na package na wala na sa anumang enabled repository. Dito 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 habang offline boot, hindi na babalik ang SSH. Ang tanging paraan para makapasok ay ang console na ibinibigay ng provider, gaya ng VNC o serial. Tiyaking mayroon kang console o snapshot bago magsimula, hindi pagkatapos.

May isa pang check na madalas nilalaktawan:

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 ino-overwrite ng RPM. Isinusulat nito ang packaged version sa tabi nito bilang .rpmnew. Kaya patuloy na gagana ang sshd o nginx ayon sa dati nitong behavior sa lumang release, habang hindi nababasa sa disk ang mga bagong default. Basahin ang mga file na ito pagkatapos ng bawat upgrade. I-install ang rpmconf at patakbuhin ang sudo rpmconf -a upang suriin ang mga ito nang paisa-isa at makita ang pagkakaiba.

Mga third-party repository ang sumisira sa upgrade

Sabay-sabay nagbabago ang mga package ng Fedora sa araw ng release. Ang mga package mula sa labas ng Fedora ay sumusunod sa schedule ng ibang vendor. Karamihan sa vendor repository ay may $releasever sa URL nito, kaya kapag nag-upgrade ka, magsisimulang humingi ang dnf ng path na maaaring wala pa.

Ilista ang mga repository na mayroon ka:

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

Para sa bawat repository na hindi pagmamay-ari ng Fedora, subukan muna ito laban sa target release bago ka magpatuloy:

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

Kung naglabas na ang vendor ng package para sa release na iyon, ida-download ng dnf ang metadata at tahimik na lalabas. Kung hindi pa, makakakuha ka ng 404 para sa path gaya ng https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml, at ang parehong failure ang pipigil sa system-upgrade download sa susunod. Sa mga unang linggo matapos ang 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, na karaniwang tamang gawin. 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 sa repository ang mga package nito. Mananatiling installed at unmanaged ang mga ito, at kung hinaharangan nila ang transaction, sasabihin ito ng dnf. Kapag idinagdag ang --allowerasing, maaaring mag-alis ang dnf ng mga installed package upang maresolba ang conflict, kaya basahin muna ang listahan ng aalisin bago ito tanggapin. Sa listahang iyon kadalasang hindi sinasadyang nawawala ang database server na dapat sanang panatilihin.

Ano ang nangyayari sa Fedora server na hindi nakaabot sa window

Walang nangyayari sa mismong araw. Lumilitaw ang failure sa susunod na paggamit mo ng package manager. Inaalis ang mga release na end of life sa mirror network at inililipat sa archive. Dahil dito, nagfa-fail ang dnf upgrade habang kinukuha ang metadata, na may 404 sa metalink URL para sa release mo:

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

Patuloy na nagse-serve ng traffic ang machine. Ito ang dahilan kung bakit tahimik ngunit mapanganib ang problemang ito. Wala na itong natatanggap na security updates. Hindi rin ito makapag-install ng anuman. Kaya kapag may lumabas na OpenSSH o nginx advisory, wala kang supported na paraan para ma-patch ito.

Posibleng makaalis sa sitwasyong ito, pero 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 kada upgrade. Kaya kung apat na release ang napag-iwanan ng isang box, kakailanganin nito ng ilang magkakasunod na hop. May sariling posibilidad na mag-fail ang bawat hop. Isinasagawa rin ang bawat isa habang walang visibility sa isang offline boot. Sa isang VPS, karaniwang mas maikli at mas ligtas na trabaho ang pag-rebuild gamit ang kasalukuyang image at paglilipat ng data doon. Pareho rin ito ng proseso ng unang sampung minuto sa bagong VPS.

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

Maaaring awtomatikong i-install ng Fedora ang mga update nito 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, at ino-override nito ang mga default na kasama sa package sa /usr/share/dnf5/dnf5-plugins/automatic.conf. Naka-off bilang default ang apply_updates, kaya sa default na configuration, nagda-download ang timer ng mga update pero walang ini-install. Pinipili ng upgrade_type kung default o security ang gagamitin. Tinatanggap ng reboot ang never, when-changed, o when-needed.

Pinananatili ka nitong updated sa loob ng isang release. Hindi nito ililipat ang Fedora 43 sa Fedora 44, dahil hiwalay at sinadyang operasyon ang version upgrade na nagre-reboot 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 window nang walang anumang pagbabago ng version, at ang mismong version change ay isang planadong gawain gaya ng upgrade mula 24.04 patungong 26.04 isang beses kada ilang taon.

Kapag ang Fedora ang tamang server na gamitin

Magandang piliin ang Fedora kapag mahalaga ang paggamit ng pinakabagong teknolohiya.

• Kailangan mo ng kernel o userspace na mas bago kaysa sa anumang ipinapadala ng LTS: para sa bagong hardware, o container at systemd stack na isang taon pa bago magkaroon ng enterprise release. Nagpapalit din ang Fedora sa mga bagong upstream kernel habang nasa release cycle, kaya hindi lang ito pansamantalang pakinabang sa oras ng installation.
• Sinusuri mo kung ano ang nakatakdang mapunta 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 bina-build at pinapatakbo sa Fedora ngayon ay tine-test laban sa enterprise platform na maaaring gamitin pagkalipas ng ilang taon.
• Idinisenyo ang machine na panandalian lamang. Ang build runner o test box na dine-delete pagkalipas ng dalawang buwan ay hindi aabot sa end-of-life date nito. Kasama rin dito ang mga disposable VM na ibinibigay mo sa coding agents, kung saan mas madalas i-rebuild ang box kaysa sa paglabas ng mga bagong Fedora release.
• May nakatalagang responsable sa upgrade. Maayos gamitin ang Fedora sa server na may partikular na owner at nakatalang iskedyul. Hindi ito magandang piliin para sa box na nakalimutan 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 dalawang ito. Gamitin ang LTS o enterprise rebuild bilang base, pagkatapos ay kunin ang bagong software kung saan mo talaga ito kailangan. Nagbibigay ang container image ng bagong version ng application sa host na hindi mo kailangang i-upgrade para rito (pagpapatakbo ng Docker sa isang VPS). Ang vendor repository para sa isang partikular na package, gaya ng PostgreSQL o nginx, ang mag-a-update sa package na iyon habang hindi ginagalaw ang base.

Parehong may malinaw na kapalit ang dalawang opsyon. Nagbibigay ang container ng bagong userspace sa ibabaw ng lumang kernel ng host, kaya hindi ito makatutulong kung ang kernel mismo ang kailangang i-update. Nagbibigay naman ang vendor repository ng isang bagong package sa base na maaaring hindi gaanong nasubukan ng vendor. Pareho nilang iniiwan ang security updates ng base system sa iskedyul ng LTS, at ang iskedyul na iyon ang nagkakahalaga sa iyo ng maintenance window bawat taon kapag Fedora ang gamit.

Kung pipiliin mo ang Fedora para sa server, ilagay sa calendar ang release cycle. Kapag nag-release ng bagong version, maghintay ng ilang linggo para makahabol ang mga vendor repository, gumawa ng snapshot, isagawa ang upgrade, at pagkatapos ay i-verify na muling gumana ang mga serbisyo. Karaniwang humigit-kumulang isang oras bawat taon ang gastos ng prosesong ito, at maaasahan ito. Ang problemang bersyon ay ang upgrade na naaalala lamang dahil may nasira na.

FAQ

Gaano katagal sinusuportahan ang isang Fedora release?

Humigit-kumulang 13 buwan. Naglalabas ang Fedora ng bagong release halos kada anim na buwan at sinusuportahan ang bawat isa hanggang humigit-kumulang apat na linggo pagkatapos ilabas ang release na dalawang bersyon ang layo. Inilabas ang Fedora 44 noong 28 April 2026, at nakatakda ang end of life nito sa June 2027. Kapag lumampas na sa petsang iyon, hindi na makakatanggap ang release ng mga security update at ililipat ang mga package nito mula sa mirrors patungo sa Fedora archive.

Maaari ko bang laktawan ang isang Fedora release at mag-upgrade nang dalawang bersyon sa isang pagkakataon?

Oo, sa ilang limitasyon. Tumatanggap ang dnf system-upgrade download --releasever= ng target na isa o dalawang release ang layo, at ang pagtalon nang dalawang release bawat upgrade ang eksaktong paraan ng upgrade na ginagawa isang beses bawat taon. Hindi suportadong path ang pagtalon nang higit pa rito, at bawat karagdagang release ay nagpapataas ng posibilidad na mapahinto ng pagpapalit ng pangalan ng package o pagbabago sa config format ang transaction. Kung ilang release na ang nahuhuli ng isang machine at lumampas na sa end of life, karaniwang mas mabilis ang pag-rebuild gamit ang kasalukuyang image kaysa magsagawa ng sunod-sunod na upgrade.

Ano ang mangyayari kung umabot sa end of life ang Fedora server ko?

Patuloy itong tatakbo ngunit hindi na ito mapo-patch. Mabibigo ang susunod na dnf upgrade na may 404 sa metalink URL para sa release mo, 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-isang hop, o i-rebuild ang server gamit ang suportadong release. Hangga't hindi mo ginagawa ang isa sa dalawang paraang ito, walang security update na makakarating sa machine at walang package na mai-install.

Masama bang piliin ang Fedora para sa isang production server?

Hindi ito magandang default, ngunit makatwiran itong piliin kung may malinaw na dahilan. Ang kapalit nito ay buong operating system upgrade bawat taon, nang tuloy-tuloy, sa isang machine na maaaring ayaw mong 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 gusto mong mag-patch ng server sa loob ng maraming taon nang hindi binabago ang bersyon nito.