Berapa Lama Fedora Server Mendapatkan Pembaruan?

Berapa lama rilis Fedora mendapatkan pembaruan keamanan?

Server Fedora memerlukan peningkatan versi sekitar sekali setahun selama mesin tersebut digunakan. Fedora menerbitkan rilis baru kira-kira setiap enam bulan. Setiap rilis didukung hingga sekitar empat minggu setelah rilis dua versi berikutnya, sehingga total periode pembaruannya sekitar 13 bulan. Setelah tanggal tersebut, rilis itu tidak lagi mendapatkan perbaikan keamanan apa pun. Server tetap berjalan, tetapi paket-paketnya tidak lagi diperbarui oleh siapa pun.

Tanggalnya memperjelas hal ini. Pada Agustus 2026, rilis yang masih didukung adalah Fedora 43 dan Fedora 44. Fedora 44 dirilis pada 28 April 2026, dan akhir masa dukungannya dijadwalkan pada Juni 2027. Fedora 42 dirilis pada April 2025 dan mencapai akhir masa dukungan pada Mei 2026, empat minggu setelah Fedora 44 dirilis. Oleh karena itu, server yang dibuat dari image Fedora 42 tidak lagi didukung tiga belas bulan kemudian, meskipun tidak ada kesalahan yang dilakukan siapa pun.

Fedora dibandingkan dengan LTS, dalam bulan

LTS berarti dukungan jangka panjang: rilis yang terus ditambal oleh vendor selama bertahun-tahun, bukan berbulan-bulan. EOL berarti akhir masa pakai, yaitu tanggal ketika patch berhenti dirilis. Berikut informasi yang dipublikasikan setiap proyek untuk rilis yang akan Anda pasang saat ini.

[
  {
    "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 memberi Anda 13 bulan untuk setiap rilis. Ubuntu LTS memberi 60, sedangkan rebuild enterprise seperti AlmaLinux memberi 120. Anggap kolom kedua sebagai beban pemeliharaan. Selama sepuluh tahun, Fedora mengharuskan sekitar 10 kali upgrade seluruh sistem operasi, dibandingkan 2 kali pada Ubuntu LTS. Angka Debian sebesar 36 bulan adalah dukungan keamanan regulernya, dan tim LTS terpisah memperpanjang dukungan untuk sebagian besar rilis hingga sekitar lima tahun.

Ini adalah periode dukungan yang dipublikasikan dan diperiksa pada Agustus 2026, bukan waktu aktif yang diukur. Alasan perbedaan siklus tersebut dibahas dalam perbedaan antara Ubuntu LTS dan rilis interim pada server. Yang penting di sini adalah pekerjaan yang harus Anda lakukan untuk setiap pilihan.

Hal yang sebenarnya terjadi saat upgrade versi Fedora

DNF 5 adalah manajer paket default sejak Fedora 41, dan dnf menjalankannya. Perintah system-upgrade merupakan bagian dari dnf5, jadi Anda tidak perlu memasang plugin terlebih dahulu. Mulai dari rilis saat ini yang sudah sepenuhnya diperbarui:

sudo dnf upgrade --refresh
sudo reboot

Reboot penting karena proses upgrade mencocokkan dependensi dengan sistem yang terpasang dan sedang berjalan. Kernel atau pembaruan glibc yang baru diterapkan sebagian akan membuat langkah berikutnya lebih sulit dianalisis. Sekarang siapkan rilis baru. Ganti 44 dengan rilis tujuan upgrade:

sudo dnf system-upgrade download --releasever=44

Perintah ini menyelesaikan seluruh transaksi dan mengunduh semua paket, tetapi tidak mengubah sistem yang sedang berjalan. Pada server kecil, siapkan ruang untuk beberapa ribu paket dan satu hingga tiga gigabita. Jika dnf tidak dapat menyelesaikan transaksi, proses berhenti di sini dan menyebutkan paket yang menghambatnya. Ini adalah kondisi yang baik karena kegagalan terjadi saat mesin masih aktif dan Anda masih memiliki shell.

Kemudian jalankan:

sudo dnf offline status
sudo dnf system-upgrade reboot

dnf offline status mengonfirmasi bahwa transaksi sudah disiapkan dan menunggu. dnf system-upgrade reboot me-restart mesin ke transaksi offline: boot minimal yang menjalankan transaksi RPM secara mandiri. Cara ini digunakan karena mengganti glibc dan systemd saat service masih berjalan dapat menghasilkan sistem yang terpasang sebagian. Server Anda tidak dapat diakses selama seluruh transaksi, biasanya selama beberapa menit pada VPS kecil, lalu melakukan reboot lagi ke rilis baru. Rencanakan dua kali reboot dan periode ketika SSH tidak merespons.

Setelah sistem kembali aktif:

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

/etc/fedora-release seharusnya mencetak baris seperti Fedora release 44 (Forty Four). Subperintah log mencetak log transaksi dari boot offline tersebut. Ini adalah satu-satunya catatan tentang apa yang terjadi saat Anda tidak memiliki shell. distro-sync menerapkan versi rilis baru pada semua komponen yang masih tertinggal. repoquery --extras menampilkan paket terpasang yang tidak lagi tersedia di repository mana pun yang aktif. Di sinilah Anda dapat menemukan sisa paket dari repository yang tidak pernah menerbitkan paket untuk rilis baru.

Buat snapshot disk sebelum langkah pengunduhan. Transaksi berjalan saat Anda tidak dapat melihat layar. Jika transaksi gagal saat boot offline, SSH tidak akan kembali dan satu-satunya cara untuk mengakses sistem adalah melalui konsol yang disediakan provider, VNC, atau serial. Pastikan Anda memiliki akses ke konsol atau snapshot sebelum memulai, bukan setelahnya.

Ada satu pemeriksaan lain yang sering dilewati:

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

Ketika sebuah paket menyediakan file konfigurasi default baru dan Anda telah mengubah file lama, RPM tidak akan menimpa file Anda. RPM menulis versi yang disediakan paket di sampingnya sebagai .rpmnew. Akibatnya, sshd atau nginx tetap berperilaku sama seperti pada rilis lama, sementara konfigurasi default baru tidak digunakan di disk. Baca file tersebut setiap kali selesai melakukan upgrade. Memasang rpmconf lalu menjalankan sudo rpmconf -a akan menampilkan file-file tersebut satu per satu beserta perbedaannya.

Repositori pihak ketiga menyebabkan upgrade gagal

Paket Fedora sendiri diperbarui secara serentak pada hari rilis. Paket dari luar Fedora mengikuti jadwal pihak lain. Sebagian besar repositori vendor menempatkan $releasever di URL-nya. Karena itu, setelah Anda melakukan upgrade, dnf mulai meminta path yang mungkin belum tersedia.

Tampilkan repositori yang tersedia:

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

Untuk setiap repositori yang bukan milik Fedora, uji repositori tersebut terhadap release target sebelum melanjutkan:

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

Jika vendor telah menyediakan repositori untuk release tersebut, dnf mengunduh metadata lalu keluar tanpa pesan. Jika belum, Anda akan menerima 404 untuk path seperti https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml. Kegagalan yang sama kemudian akan menghentikan system-upgrade download. Pada beberapa minggu pertama setelah Fedora dirilis, ini merupakan alasan paling umum upgrade tidak dapat dimulai.

Ada dua pilihan. Tunggu beberapa minggu hingga vendor menerbitkan repositori tersebut. Biasanya, ini merupakan pilihan yang tepat. Atau lakukan upgrade tanpa repositori itu:

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

Menonaktifkan repositori tidak menghapus paketnya. Paket tersebut tetap terpasang dan tidak dikelola. Jika paket itu menghalangi transaksi, dnf akan memberi tahu Anda. Penambahan --allowerasing memungkinkan dnf menghapus paket yang terpasang untuk menyelesaikan konflik. Karena itu, baca daftar penghapusan sebelum menyetujuinya. Dalam daftar itulah orang sering kehilangan server database yang sebenarnya ingin dipertahankan.

Apa yang terjadi pada server Fedora yang melewatkan periode dukungan

Tidak ada yang terjadi pada hari tersebut. Kegagalan muncul saat Anda menggunakan package manager pada kesempatan berikutnya. Rilis yang sudah mencapai akhir masa dukungan dipindahkan dari jaringan mirror ke arsip. Akibatnya, dnf upgrade gagal saat mengambil metadata dan menghasilkan 404 pada URL metalink untuk rilis Anda:

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

Mesin tetap melayani trafik. Hal inilah yang membuat masalah ini tidak terlihat dan berbahaya. Mesin tidak lagi menerima pembaruan keamanan. Mesin juga tidak dapat menginstal apa pun. Jadi, ketika advisori OpenSSH atau nginx diterbitkan, tidak ada cara yang didukung untuk menerapkan patch.

Masalah ini dapat diatasi, tetapi prosesnya lambat. Anda dapat mengarahkan ulang repositori ke arsip Fedora pada https://dl.fedoraproject.org/pub/archive/fedora/linux/, lalu melakukan upgrade dari sana. Fedora mengharuskan perpindahan satu atau dua rilis setiap kali. Jadi, server yang tertinggal empat rilis harus menjalani beberapa perpindahan secara berurutan. Setiap perpindahan memiliki risiko gagal dan dilakukan tanpa koneksi pada boot offline. Pada VPS, membangun ulang server menggunakan image terbaru lalu memindahkan datanya biasanya lebih singkat dan lebih aman. Pekerjaan ini sama seperti sepuluh menit pertama pada VPS baru.

Pembaruan otomatis menerapkan patch pada suatu rilis. Pembaruan ini tidak pernah meningkatkan versinya.

Fedora dapat memasang pembaruan berdasarkan pengatur waktu:

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

Pengaturan berada di /etc/dnf/automatic.conf, yang menimpa default yang disertakan dalam /usr/share/dnf5/dnf5-plugins/automatic.conf. apply_updates dinonaktifkan secara default. Karena itu, dalam konfigurasi bawaan, pengatur waktu hanya mengunduh pembaruan dan tidak memasang apa pun. upgrade_type memilih antara default dan security. reboot menerima never, when-changed, atau when-needed.

Cara ini membuat sistem tetap mutakhir dalam satu rilis. Cara ini tidak akan pernah memindahkan Fedora 43 ke Fedora 44, karena peningkatan versi adalah operasi terpisah yang dilakukan secara sengaja dan melakukan reboot ke transaksi offline. Inilah perbedaan praktis dibandingkan LTS. Di Ubuntu, pembaruan keamanan tanpa pengawasan menjaga mesin tetap berada dalam seluruh periode lima tahun tanpa perubahan versi sama sekali. Perubahan versi itu sendiri merupakan pekerjaan terencana seperti peningkatan versi 24.04 ke 26.04 yang dilakukan setiap beberapa tahun.

Kapan Fedora tepat digunakan sebagai server

Fedora merupakan pilihan yang baik ketika kebaruan menjadi tujuan utama.

• Anda memerlukan kernel atau userspace yang lebih baru daripada yang disediakan oleh LTS mana pun: untuk perangkat keras terbaru, atau stack container dan systemd yang masih satu tahun lagi dari rilis enterprise. Fedora juga beralih ke kernel upstream baru selama suatu rilis, jadi manfaat ini bukan hanya keuntungan sesaat saat instalasi.
• Anda sedang memvalidasi komponen yang akan masuk ke RHEL (Red Hat Enterprise Linux). Fedora menjadi sumber bagi CentOS Stream, yang kemudian menjadi sumber bagi RHEL. Oleh karena itu, software yang saat ini dibangun dan dijalankan di Fedora sedang diuji terhadap platform enterprise beberapa tahun mendatang.
• Mesin tersebut memang dirancang untuk berumur singkat. Build runner atau mesin pengujian yang dihancurkan dalam dua bulan tidak akan pernah mencapai tanggal akhir masa dukungnya. Logika yang sama berlaku untuk VM sementara yang Anda berikan kepada coding agent, karena mesin tersebut dibuat ulang jauh lebih sering daripada jadwal rilis Fedora.
• Ada pihak yang bertanggung jawab atas upgrade. Fedora sesuai untuk server yang memiliki penanggung jawab dan jadwal yang jelas. Fedora tidak cocok untuk mesin yang sudah dilupakan semua orang.

Jalur tengah: paket terbaru pada basis yang stabil

Sebagian besar orang yang menginginkan Fedora di server hanya membutuhkan dua atau tiga paket terbaru, bukan sistem operasi terbaru. Keduanya dapat dipisahkan. Gunakan LTS atau rebuild enterprise sebagai basis, lalu ambil perangkat lunak terbaru hanya pada bagian yang memang membutuhkannya. Image container memberi Anda versi aplikasi terbaru pada host yang tidak perlu di-upgrade untuk aplikasi tersebut (menjalankan Docker pada VPS). Repository vendor untuk satu paket yang Anda perlukan, seperti PostgreSQL atau nginx, memperbarui paket tersebut tanpa mengubah basis sistem.

Pertukarannya jelas dalam kedua arah. Container memberi Anda userspace baru pada kernel lama milik host. Jadi, container tidak membantu jika kernel adalah komponen yang perlu diperbarui. Repository vendor memberi Anda satu paket baru pada basis yang lebih sedikit diuji oleh vendor. Keduanya tetap menggunakan jadwal pembaruan keamanan sistem basis sesuai siklus LTS. Siklus itulah yang membuat Anda harus menyediakan maintenance window setiap tahun jika menggunakan Fedora.

Jika Anda memilih Fedora untuk server, jadwalkan siklusnya di kalender. Setelah sebuah rilis tersedia, tunggu beberapa minggu agar repository vendor menyusul. Buat snapshot, lakukan upgrade, lalu verifikasi bahwa service kembali berjalan. Siklus ini memerlukan sekitar satu jam per tahun dan dapat diandalkan. Upgrade yang bermasalah adalah upgrade yang hanya diingat setelah sesuatu terlanjur rusak.

FAQ

Berapa lama rilis Fedora didukung?

Sekitar 13 bulan. Fedora menerbitkan rilis kira-kira setiap enam bulan dan mendukung setiap rilis hingga sekitar empat minggu setelah rilis dua versi berikutnya. Fedora 44 dirilis pada 28 April 2026 dan akhir masa dukungannya dijadwalkan pada Juni 2027. Setelah tanggal tersebut, rilis itu tidak lagi menerima pembaruan keamanan dan paketnya dipindahkan dari mirror ke arsip Fedora.

Apakah saya dapat melewati satu rilis Fedora dan melakukan upgrade dua versi sekaligus?

Ya, dengan batasan tertentu. dnf system-upgrade download --releasever= menerima target yang lebih baru satu atau dua rilis, dan melakukan lompatan dua versi sekaligus memang merupakan cara kerja siklus upgrade setahun sekali. Melompat lebih jauh bukan jalur yang didukung, dan setiap rilis tambahan meningkatkan kemungkinan bahwa penggantian nama paket atau perubahan format konfigurasi menghentikan transaksi. Jika sebuah mesin sudah tertinggal beberapa rilis dan melewati akhir masa dukungan, membangun ulang mesin menggunakan image terbaru biasanya lebih cepat daripada melakukan rangkaian upgrade.

Apa yang terjadi jika server Fedora saya mencapai akhir masa dukungan?

Server tetap berjalan, tetapi tidak lagi menerima patch. dnf upgrade berikutnya gagal dengan error 404 pada URL metalink untuk rilis Anda karena rilis yang telah mencapai akhir masa dukungan dipindahkan ke arsip di dl.fedoraproject.org. Anda dapat mengarahkan ulang file repositori ke arsip tersebut lalu melakukan upgrade secara bertahap, atau membangun ulang server menggunakan rilis yang masih didukung. Sebelum salah satu tindakan tersebut dilakukan, tidak ada pembaruan keamanan yang dapat diterima mesin dan tidak ada paket yang dapat diinstal.

Apakah Fedora merupakan pilihan yang buruk untuk server produksi?

Fedora merupakan pilihan default yang buruk, tetapi dapat menjadi pilihan yang wajar jika ada alasannya. Konsekuensinya adalah Anda harus melakukan upgrade sistem operasi secara menyeluruh setiap tahun, tanpa batas waktu, pada mesin yang mungkin tidak ingin sering Anda ubah. Pilih Fedora jika Anda memerlukan kernel atau userspace yang lebih baru daripada yang dirilis oleh LTS, atau jika server tersebut memang dirancang untuk berumur pendek. Pilih LTS atau rebuild enterprise jika Anda ingin melakukan patch pada server selama bertahun-tahun tanpa mengubah versinya.