Episode ini mengupas package management Rocky Linux: perintah sehari-hari DNF5 untuk menginstal, mencari, dan memperbarui paket, struktur konfigurasi dan repositori, serta dasar RPM untuk query, verifikasi integritas, dan ekstraksi paket.

Di episode 3 sebelumnya kalian sudah menginstal Rocky Linux dan mungkin menambahkan beberapa paket. Sekarang saatnya memahami mesin di balik instalasi paket: DNF5 dan RPM. Di Rocky Linux 10, DNF5 adalah package manager default — versi modern yang lebih cepat dan hemat memori dibanding pendahulunya. Package management adalah keterampilan yang paling sering kalian pakai sebagai sysadmin: menginstal web server, memperbarui sistem, menelusuri konflik dependency, memverifikasi file yang rusak, sampai rollback transaksi — semuanya berpusat pada dnf dan rpm.
Rocky 8 dan 9 memakai DNF, yang sendiri merupakan evolusi dari yum. DNF5 adalah penerus yang ditulis ulang dengan fokus pada kecepatan dan penggunaan memori yang lebih efisien. Di Rocky 10, dnf5 menjadi perintah utama, meskipun sebagian besar perintah lama tetap berfungsi sebagai alias.
dnf5 --versiondnf5 search nginx
dnf5 install nginxdnf5 upgrade
dnf5 remove nginxdnf5 install nginx menyelesaikan semua dependency secara otomatis — keunggulan package manager dibanding menginstal dari file individual. dnf5 upgrade memperbarui semua paket yang terpasang ke versi terbaru yang tersedia di repositori, dan sebaiknya dijalankan secara rutin.
Untuk memahami apa yang tersedia dan apa yang sudah terpasang, gunakan repoquery dan list:
dnf5 repoquery --available '*nginx*'
dnf5 list installed
dnf5 info nginxdnf5 info nginx menampilkan deskripsi, versi, ukuran, dan repositori asal paket — cara cepat menilai apakah sebuah paket layak diinstal sebelum melakukannya.
Saat menghapus sebuah paket, dependency yang tidak lagi dibutuhkan mungkin tertinggal. dnf5 autoremove membersihkan paket-paket oris yang hanya terpasang sebagai dependency:
dnf5 autoremoveKebiasaan ini menjaga sistem tetap ramping dan mengurangi permukaan serangan — prinsip yang sama dengan memilih Minimal Install di episode 3.
Konfigurasi DNF5 tersimpan di /etc/dnf/dnf5.conf — file ini mengontrol perilaku global seperti penanganan transaksi dan konten cache:
dnf5 config-manager dumpSebagian besar pengaturan tidak perlu diubah untuk penggunaan normal, tetapi penting mengetahui lokasinya jika nanti kalian perlu menyesuaikan perilaku default.
Repositori didefinisikan dalam file .repo di /etc/yum.repos.d/. Setiap file berisi satu atau lebih blok repositori dengan nama, URL, dan pengaturan seperti gpgcheck:
dnf5 repolistdnf5 repolist --allDi sinilah kalian melihat BaseOS, AppStream, CRB, dan Extras yang kita bahas di episode 2, ditambah repositori pihak ketiga seperti EPEL jika sudah ditambahkan. Verifikasi tanda tangan GPG (gpgcheck=1) selalu aktif di repositori resmi — ini melindungi kalian dari paket yang dirusak di tengah jalan.
RPM (Red Hat Package Manager) adalah format paket inti. DNF5 bekerja di atas RPM — DNF mengelola dependency dan transaksi, sementara RPM menangani instalasi fisik, metadata, dan verifikasi. Memahami RPM berarti memahami fondasi di balik DNF5.
Operasi query tidak mengubah sistem dan aman dijalankan kapan saja:
rpm -q nginx
rpm -qa | head
rpm -qi systemdrpm -q nginx menampilkan versi persis paket yang terpasang. rpm -qi systemd (info) menunjukkan deskripsi, lisensi, dan waktu instalasi. Untuk menampilkan file yang dimiliki sebuah paket:
rpm -ql nginxDan untuk mengetahui paket mana yang memiliki sebuah file:
rpm -qf /etc/nginx/nginx.confSalah satu fitur RPM yang paling berharga adalah verifikasi — membandingkan file yang terpasang dengan kondisi asli saat instalasi:
rpm -V nginxOutput menunjukkan perubahan seperti S (ukuran), M (mode), 5 (digest berubah). Jika tidak ada output, semua file tidak berubah sejak instalasi. Verifikasi ini sangat berguna untuk mendeteksi file yang rusak atau diubah — langkah awal investigasi keamanan.
Kadang kalian mendapat file .rpm langsung, bukan dari repositori. RPM bisa menginstalnya, tetapi tanpa resolusi dependency otomatis:
rpm -ivh package.rpm
rpm -Uvh package.rpm-i untuk install, -U untuk upgrade, -h menampilkan progress bar. Ingat: sebaiknya biarkan DNF5 yang menginstal file RPM lokal (via dnf5 install ./package.rpm) agar dependency diselesaikan dengan benar.
RPM menyimpan file dalam format cpio. Untuk melihat isi paket tanpa menginstalnya — misalnya memeriksa file konfigurasi yang akan ditimpa:
rpm2cpio package.rpm | cpio -idmvrpm2cpio package.rpm | cpio -tTeknik ini sangat membantu saat audit atau forensik: kalian bisa melihat persis apa yang akan disebarkan oleh sebuah paket.
Setiap operasi DNF5 dicatat sebagai transaksi. Riwayat ini menjadi catatan audit — apa yang diinstal, kapan, dan oleh siapa:
dnf5 historydnf5 history info 14Jika sebuah update merusak sistem, DNF5 bisa membalik transaksi tertentu:
dnf5 history undo 14dnf5 history rollback 12dnf5 history rollback mengembalikan sistem ke status setelah transaksi tertentu — alat yang sangat menenangkan saat update mingguan menimbulkan masalah.
Success
Kunci ketenangan dalam manajemen paket adalah perencanaan: baca changelog update, uji di staging, dan simpan riwayat transaksi. DNF5 mencatat semuanya untuk kalian — gunakan sebagai jaring pengaman.
Di episode 4 ini kalian sudah menguasai fondasi package management Rocky Linux: operasi sehari-hari DNF5 seperti install, remove, search, dan upgrade, struktur konfigurasi di /etc/dnf/dnf5.conf dan repositori di /etc/yum.repos.d/, dasar-dasar RPM untuk query, verifikasi, dan ekstraksi, serta history dan rollback transaksi sebagai jaring pengaman.
Inti yang harus dibawa pulang:
install, remove, upgrade, search, dan repoquery./etc/yum.repos.d/; pastikan gpgcheck=1 selalu aktif.rpm -q, rpm -V, dan rpm2cpio adalah dasar untuk query, verifikasi, dan ekstraksi paket.dnf5 history undo dan rollback mengubah upgrade yang bermasalah menjadi momen yang tenang.Di episode 5 selanjutnya kita akan membahas repositori, modules, dan AppStream — cara kerja BaseOS dan AppStream, module streams yang memungkinkan beberapa versi aplikasi berjalan berdampingan, repositori pihak ketiga seperti EPEL, serta perbedaan konsep antara multi-version di AppStream dan multi-repositori. Sampai jumpa di episode berikutnya!