Ubuntu LTS vs Interim untuk Server: Mana yang Tepat?

Ubuntu LTS vs rilis interim: jawaban singkat

Memilih Ubuntu LTS atau rilis interim untuk server bergantung pada satu angka: berapa lama rilis tersebut terus menerima pembaruan keamanan. LTS mendapatkan pemeliharaan keamanan standar selama lima tahun. Rilis interim mendapatkannya selama sembilan bulan, lalu pembaruan berhenti sehingga Anda harus melakukan upgrade atau rebuild. Gunakan LTS pada sistem yang menjadi dependensi pihak lain. Gunakan rilis interim hanya jika Anda dapat melakukan rebuild tanpa meminta persetujuan siapa pun.

LTS berarti long term support. Canonical merilis satu LTS setiap dua tahun, pada bulan April di tahun genap, serta satu rilis interim setiap enam bulan di antaranya. 26.04 LTS dirilis pada 23 April 2026 dan pemeliharaan keamanan standarnya berlangsung hingga 2031. 26.10 dijadwalkan dirilis pada 15 Oktober 2026 dan merupakan rilis interim, sehingga masa dukungannya berakhir pada Juli 2027.

Berapa lama setiap rilis Ubuntu didukung

[
  {
    "label": "LTS, standard support",
    "support_months": 60,
    "upgrades_over_5_years": 1
  },
  {
    "label": "LTS with Ubuntu Pro",
    "support_months": 120,
    "upgrades_over_5_years": 0
  },
  {
    "label": "Interim release",
    "support_months": 9,
    "upgrades_over_5_years": 10
  }
]

Angka tersebut adalah angka kebijakan yang diterbitkan Canonical per Agustus 2026, bukan hasil pengukuran dari server pengujian. LTS mendapatkan pemeliharaan keamanan standar selama 60 bulan. Dalam lima tahun, periode ini berarti 1 upgrade rilis yang direncanakan. Rilis interim mendapatkan dukungan selama 9 bulan. Jika tetap menggunakan jalur interim selama lima tahun yang sama, Anda harus melakukan 10 upgrade rilis, karena rilis tidak dapat dilewati dan lima tahun mencakup sepuluh rilis.

Langganan Ubuntu Pro meningkatkan dukungan LTS menjadi 120 bulan, atau sepuluh tahun, serta memperluas cakupan dari komponen main ke seluruh arsip. Per Agustus 2026, Pro gratis untuk penggunaan pribadi pada hingga lima mesin, sehingga mencakup sebagian besar armada VPS kecil. Tidak ada layanan yang setara untuk rilis interim. Sembilan bulan adalah seluruh masa dukungannya, dan tidak ada langganan yang dapat memperpanjangnya.

Biaya sembilan bulan pada server nyata

Gunakan 26.10 sebagai contoh. Versi ini dirilis pada 15 October 2026, dan pemeliharaan keamanannya berakhir pada July 2027. Polanya sama dengan 25.10, yang berakhir pada July 2026. Jika dilihat sebagai kalender, pola ini tampak seperti satu periode pemeliharaan setiap tiga kuartal. Anggapan berdasarkan kalender tersebut keliru, dan dampaknya merugikan.

Upgrade rilis mengganti sistem operasi secara langsung pada instalasi yang ada. do-release-upgrade menulis ulang sumber apt, menonaktifkan repositori pihak ketiga, mengubah versi hampir setiap paket yang terinstal, berhenti untuk menanyakan file konfigurasi yang telah Anda edit, lalu melakukan reboot pada akhir proses. Karena itu, upgrade merupakan periode terencana, bukan pekerjaan latar belakang.

Jika dijalankan melalui ssh, alat tersebut melindungi Anda ketika koneksi terputus. Alat ini memulai sesi screen sendiri dan membuka sshd kedua, lalu memberi tahu Anda terlebih dahulu:

To make recovery in case of failure easier, an additional sshd will
be started on port '1022'. If anything goes wrong with the running ssh
you can still connect to the additional one.

Biarkan proses tersebut berjalan. Jika firewall Anda atau firewall jaringan terpisah milik provider memblokir 1022, mekanisme cadangan itu tidak tersedia. Koneksi yang terputus kemudian dapat meninggalkan kumpulan paket yang baru ter-upgrade sebagian. Menjalankan proses di dalam tmux atau screen sendiri memberikan perlindungan yang sama pada server apa pun.

Prompt file konfigurasi dapat mengubah upgrade yang seharusnya berlangsung lima belas menit menjadi satu jam:

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?

Jika mempertahankan file Anda, Anda dapat melewatkan perubahan pada default baru. Jika menggunakan file milik maintainer, konfigurasi hardening Anda hilang sampai dipasang kembali. Tidak ada jawaban yang aman tanpa mengetahui perubahan pada rilis tersebut. Karena itu, membaca catatan rilis merupakan bagian dari periode upgrade, bukan tugas tambahan yang boleh diabaikan.

Berikutnya, kalikan dengan jumlah server. Satu VPS pada jalur interim memerlukan sepuluh periode upgrade dalam lima tahun. Lima VPS memerlukan lima puluh periode, kecuali setiap server bersifat disposable dan dibangun ulang dari image. Lima server pada jalur LTS hanya memerlukan lima upgrade dalam periode yang sama, dan Anda dapat menentukan bulan pelaksanaan setiap upgrade.

Mengapa Anda tidak dapat melewati satu rilis Ubuntu

Jalur upgrade sudah ditetapkan. Rilis interim di-upgrade ke rilis berikutnya, apa pun rilis tersebut. Rilis LTS dapat di-upgrade langsung ke LTS berikutnya, atau ke rilis interim berikutnya jika Anda memintanya. Tidak ada upgrade yang melewati dua tahap sekaligus. Untuk berpindah dari 26.10 ke 28.04 LTS, Anda harus melewati 27.04 dan 27.10, atau menginstal ulang mesin.

Mekanismenya perlu dipahami karena menunjukkan bahwa aturan ini tidak dapat dilewati. do-release-upgrade mengambil file meta-release dari changelogs.ubuntu.com, lalu mengunduh alat upgrade yang dibuat untuk satu transisi tertentu. Canonical membuat dan menguji satu transisi pada satu waktu, sehingga lompatan yang melewati sebuah rilis tidak memiliki alat maupun pengujian yang mendukungnya. Upgrader tidak menolak karena terlalu berhati-hati. Tidak ada mekanisme yang dapat ditawarkannya.

Rilis yang ditawarkan ditentukan oleh satu baris konfigurasi:

grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

Prompt=lts hanya menawarkan LTS berikutnya. Prompt=normal menawarkan rilis berikutnya, baik LTS maupun bukan. Prompt=never tidak menawarkan apa pun. Dengan begitu, Anda dapat mencegah rekan kerja yang bermaksud membantu memulai upgrade yang belum Anda rencanakan. Pada rilis yang bukan LTS, lts berperilaku sama persis seperti normal karena rilis setelah 26.10 adalah 27.04 pada kedua pengaturan tersebut. Pemeriksaan ini menampilkan Checking for a new Ubuntu release, lalu menampilkan baris New release ... available. atau No new release found.

Ada satu aturan penjadwalan lain yang sering mengecoh pengguna. Upgrade dari LTS ke LTS tidak ditawarkan pada hari LTS baru dirilis. Upgrade tersebut dibuka saat point release pertama tersedia, dan 26.04.1 dijadwalkan pada 27 August 2026. Point release bukan versi Ubuntu baru, melainkan rilis yang sama dengan seluruh perbaikan yang terkumpul selama empat bulan dan dimasukkan ke media instalasi baru. Masa tunggu ini diperlukan agar jalur upgrade mendapatkan pengujian selama empat bulan tersebut sebelum ditawarkan kepada pengguna. Mesin 24.04 dengan Prompt=lts yang menjawab No new release found. sepanjang musim panas 2026 tidak mengalami kerusakan. Mesin tersebut mengikuti kebijakan. Saat jalur itu dibuka, upgrade dari 24.04 ke 26.04 LTS adalah proses yang perlu direncanakan dan dilatih terlebih dahulu.

Kapan rilis interim merupakan pilihan yang tepat

Empat kondisi ketika rilis interim benar-benar lebih unggul:

• Anda memerlukan versi kernel atau userspace yang tidak tersedia di arsip LTS pada server ini sekarang.
• Mesin tersebut adalah build host, CI runner, atau server pengujian yang dibangun ulang dari image, sehingga upgrade berarti membuat instance baru, bukan membuka maintenance window.
• Fitur hardware atau hypervisor dirilis setelah LTS dibekukan, dan tidak ada backport.
• Anda sedang memeriksa isi LTS berikutnya. 28.04 dibangun dari 26.10, 27.04, dan 27.10, sehingga menemukan breaking change pada VPS cadangan lebih murah daripada menemukannya pada server utama.

Sebagian besar orang yang memilih rilis interim sebenarnya hanya memerlukan satu package yang lebih baru, bukan distribusi yang lebih baru. Ada dua solusi yang lebih murah. Hardware enablement stack membawa kernel dari rilis yang lebih baru ke LTS: pada 24.04, stack tersebut adalah sudo apt install linux-generic-hwe-24.04, dan diperbarui pada setiap point release, mulai dari point release kedua. Untuk satu aplikasi, container image atau repository milik vendor dapat memperbarui satu komponen tanpa mengubah seluruh sistem operasi.

Kapan rilis interim bukan pilihan yang tepat

• Apa pun yang memiliki pengguna berbayar atau menerapkan rotasi on-call. Anda harus menerima upgrade wajib dua kali setahun sebagai imbalan atas versi paket yang mungkin tidak pernah digunakan.
• Server apa pun yang menggunakan unattended-upgrades untuk menerapkan patch keamanan secara otomatis. Otomatisasi tersebut hanya sebaik repositori security yang menjadi sumbernya.
• Fleet yang di-upgrade secara manual, karena biaya sebenarnya adalah satu window pemeliharaan dikalikan jumlah server.
• Apa pun yang diinstal lalu tidak diperiksa selama setahun. Rilis interim yang terlupakan akan menjadi server yang menghadap Internet tanpa patch sembilan bulan kemudian.

Kegagalan terakhir berlangsung tanpa terlihat. Hal inilah yang membuatnya berbahaya. Saat suatu rilis mencapai akhir masa dukungan, paketnya dipindahkan ke old-releases.ubuntu.com. Akibatnya, sudo apt update mulai gagal mengakses archive.ubuntu.com dan menghasilkan error 404. Daftar paket yang tersimpan di disk menjadi usang. unattended-upgrades tetap berjalan sesuai jadwal dan terus menulis baris seperti ini ke dalam /var/log/unattended-upgrades/unattended-upgrades.log:

No packages found that can be upgraded unattended and no pending auto-removals

Baris tersebut terlihat sama pada server yang seluruhnya telah menerima patch maupun pada server yang rilisnya telah berakhir masa dukungannya empat bulan lalu. Jika tidak ada yang membaca error apt atau melacak tanggal akhir masa dukungan, tidak ada informasi pada mesin yang menunjukkan server mana yang sedang diperiksa.

Jenis perubahan yang lebih dahulu masuk ke jalur interim

Pada Maret 2026, seorang engineer Canonical mengusulkan di Ubuntu Discourse untuk menghapus driver bootloader GRUB bertanda tangan yang disertakan untuk secure boot pada 26.10. Usulan tersebut menghapus driver filesystem untuk btrfs, hfsplus, xfs, dan zfs, parser gambar JPEG dan PNG, tabel partisi Apple, /boot pada LVM, software RAID selain RAID 1, serta /boot terenkripsi LUKS. Alasan yang dikemukakan adalah bahwa parser di dalam bootloader berulang kali menjadi sumber bug keamanan, sedangkan logika penyimpanan dan enkripsi seharusnya berada di initramfs, yaitu filesystem RAM awal berukuran kecil yang di-mount kernel sebelum root yang sebenarnya. Hingga Agustus 2026, ini masih merupakan usulan yang sedang dibahas, bukan perubahan yang telah dirilis.

Untuk sebagian besar instance VPS, perubahan ini tidak akan berdampak karena instance tersebut melakukan boot tanpa secure boot dari /boot ext4 biasa pada tabel partisi GPT. Periksa sistem Anda, jangan berasumsi. Jika root Anda menggunakan ZFS, atau /boot berada pada btrfs atau di dalam LUKS, inilah jenis perubahan yang akan lebih dahulu Anda hadapi pada jalur interim. Dalam thread tersebut, saran untuk pengguna yang terdampak adalah tetap menggunakan rilis LTS. Saran itu merangkum seluruh argumennya dalam satu kalimat. Rilis interim adalah tempat perubahan diuji. LTS adalah tempat perubahan tersebut diterapkan setelah dua tahun rilis interim menunjukkan apa saja yang dapat rusak.

Pola yang sama muncul dalam skala lebih kecil pada setiap rilis interim. Versi default database, runtime bahasa, dan konfigurasi init bergerak maju, sehingga file konfigurasi yang sebelumnya berfungsi dapat berhenti berfungsi. Memajukan versi default adalah tujuan rilis interim, sehingga membaca catatan rilis sebelum setiap dari sepuluh upgrade tersebut merupakan konsekuensi yang harus Anda terima.

Menentukan track saat membangun server

Pilih track saat instalasi, karena mengubahnya setelah itu berarti melakukan reinstall atau menjalankan rangkaian upgrade. Pada server baru, empat perintah menunjukkan kondisi sistem:

lsb_release -a
grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c
pro security-status

lsb_release -a seharusnya menampilkan nama rilis yang ingin Anda instal, dan pada LTS, baris deskripsinya diakhiri dengan LTS. Baris Prompt harus sesuai dengan track yang Anda pilih, bukan dengan track yang kebetulan disertakan dalam image milik provider. Pada LTS saat ini, do-release-upgrade -c seharusnya menghasilkan No new release found.. Jika perintah tersebut menawarkan interim release, Prompt bernilai normal dan seseorang perlu memastikan apakah kondisi itu memang disengaja. pro security-status melaporkan jumlah package yang terinstal berdasarkan update stream yang mencakupnya, serta menyatakan dengan jelas jika mesin belum terhubung ke subscription.

Selanjutnya, catat tanggal akhir masa dukungan di tempat yang akan Anda lihat lagi, bersama catatan build lain untuk server tersebut. Hal ini termasuk pekerjaan lain dalam sepuluh menit pertama pada VPS baru, karena tanggal dukungan yang hanya tersimpan dalam ingatan seseorang adalah tanggal yang kedaluwarsa tanpa disadari. Jika pergantian setiap enam bulan adalah hal yang sepenuhnya ingin Anda hindari, perbandingan model rilis FreeBSD dengan Linux layak dibaca selama satu jam sebelum Anda menetapkan pilihan untuk seluruh fleet.

FAQ

Apakah sebaiknya saya menjalankan rilis interim Ubuntu pada server produksi?

Dalam hampir semua kasus, tidak. Rilis interim berhenti menerima pembaruan keamanan sembilan bulan setelah dirilis. Karena itu, produksi pada jalur tersebut berarti harus melakukan upgrade kira-kira dua kali setahun, selamanya. Pengecualian yang masuk akal adalah mesin yang memang selalu dibuat ulang dari image, seperti runner CI dan host build. Pada mesin tersebut, upgrade berarti membuat instance baru, bukan membuka jendela pemeliharaan. Jika pengguna nyata bergantung pada server tersebut, instal LTS dan gunakan waktu yang dihemat untuk hal lain.

Berapa lama rilis interim Ubuntu didukung?

Sembilan bulan. 26.10 dirilis pada 15 Oktober 2026 dan pemeliharaan keamanannya berakhir pada Juli 2027, mengikuti pola yang sama dengan 25.10 yang berakhir pada Juli 2026. Setiap rilis interim mengikuti pola tersebut: dirilis pada April atau Oktober, lalu berakhir sembilan bulan kemudian. LTS mendapatkan lima tahun pemeliharaan keamanan standar, yang dapat diperpanjang menjadi sepuluh tahun dengan Ubuntu Pro. Per Agustus 2026, layanan ini gratis untuk penggunaan pribadi pada hingga lima mesin.

Apakah saya dapat melewati rilis Ubuntu saat melakukan upgrade?

Tidak. do-release-upgrade berpindah satu langkah setiap kali: rilis interim di-upgrade ke rilis berikutnya, sedangkan LTS dapat langsung di-upgrade ke LTS berikutnya. Untuk berpindah dari 26.10 ke 28.04 LTS, Anda harus menjalankan upgrade melalui 27.04 dan 27.10 terlebih dahulu, atau menginstal ulang mesin. Canonical membuat dan menguji setiap transisi satu per satu. Upgrader mengunduh alat untuk lompatan versi tertentu, sehingga lompatan dua langkah tidak memiliki alat pendukung dan tidak pernah ditawarkan.

Apa yang terjadi ketika rilis Ubuntu saya mencapai akhir masa dukungan?

Paket-paketnya dipindahkan ke old-releases.ubuntu.com. Akibatnya, sudo apt update mulai gagal mengakses archive.ubuntu.com dengan error 404, dan tidak ada lagi pembaruan keamanan baru yang diterbitkan untuk rilis tersebut. Tidak ada apa pun pada mesin yang mengumumkan kondisi ini. Server tetap berjalan dan terus melayani trafik, sementara setiap kerentanan yang baru dipublikasikan pada rilis tersebut tetap terbuka. Pemulihan harus dilakukan dengan upgrade rilis di bawah tekanan waktu atau dengan membangun ulang mesin. Karena itu, pantau tanggalnya, bukan gejalanya.

Apakah kernel LTS terlalu lama untuk perangkat keras baru?

Biasanya tidak, karena LTS tidak mempertahankan kernel aslinya selama lima tahun. Hardware enablement stack, atau HWE, membawa kernel dari rilis yang lebih baru ke LTS melalui point release. Instalasi server dapat mengaktifkannya dengan paket seperti linux-generic-hwe-24.04. Periksa kernel yang sedang digunakan dengan uname -r sebelum menganggap kernel sebagai penghambat. Jika komponen yang kurang adalah versi userspace, bukan kernel, container atau repositori vendor merupakan perubahan yang jauh lebih kecil daripada memindahkan seluruh mesin ke jalur rilis interim.