WIKI TKJ

Linux : Praktikum Audit Repositori dan Diagnosa Instalasi Paket Gagal

Artikel pagi sudah menjelaskan empat lapis: repositori menyimpan, indeks mencatat, apt memilih, dpkg memasang. Sekarang giliran membuktikan keempat lapis itu benar-benar bekerja di mesinmu.

🎯 Tujuan

Setelah menyelesaikan praktikum ini, kamu bisa:

  • Menjelaskan lima lapis bukti yang harus dilewati satu paket sebelum benar-benar terpasang.
  • Mengaudit sumber repositori di mesin Debian tanpa menebak-nebak.
  • Membaca status paket yang tidak selesai dipasang dan memulihkannya.
  • Membuat kerusakan kecil yang terkendali, lalu menemukan lapis mana yang gagal.
  • Mengubah hasil audit jadi laporan singkat: apa yang salah, di lapis mana, dan perintah apa yang memperbaikinya.

📍 Konteks nyata

Bayangkan mekanik di bengkel. Artikel pagi membahas gudang spare part, katalog, dan pemasang part. Sekarang kamu jadi orang yang memeriksa kertas kerja bengkel: apakah katalog yang dipakai memang edisi terbaru, apakah nomor part yang dicari memang ada di gudang, dan apakah part yang terpasang benar-benar sudah dikunci.

Di lab sekolah, pekerjaan ini yang paling sering terlewat. Komputer terlihat normal, apt update selesai tanpa layar merah, lalu tiba-tiba paket yang dicari "tidak ada" padahal gurunya yakin nama paketnya benar.

🔥 Kasus nyata: Lab TKJ sebuah SMK memasang aplikasi praktikum di 30 PC. Petugas lab menjalankan apt update, melihat proses selesai, lalu lanjut apt install. Dua belas PC dapat versi lama, delapan belas dapat versi baru. Saat ujian praktik, menu aplikasi berbeda antar PC dan siswa panik. Penyebabnya baru ketahuan setelah satu jam: satu baris di sources.list.d menunjuk repo internal yang sudah dipindah, dan apt update tetap selesai tanpa berhenti. Indeks lama di /var/lib/apt/lists dipakai diam-diam.

Tesis praktikum sore ini: selesai belum berarti benar. Perintah yang tidak berhenti dengan error belum tentu menghasilkan katalog yang sehat. Yang bisa dipercaya hanya bukti yang kamu lihat sendiri di lima titik pemeriksaan.

🧠 Konsep singkat

Satu paket harus melewati lima lapis sebelum berubah jadi baris ii di dpkg -l. Setiap lapis bisa gagal sendiri-sendiri, dan gejalanya sering mirip.

Lapis Pertanyaan kunci Bukti utama
1. Sumber File mana yang benar-benar dibaca APT? pesan Ign dan Err
2. Indeks Katalog lokal masih segar dan lengkap? isi /var/lib/apt/lists/
3. Pemilihan Versi mana yang jadi kandidat, dari repo mana? apt-cache policy
4. Unduh dan tanda tangan Berkasnya asli dan utuh? pesan NO_PUBKEY
5. Pemasangan dpkg selesai mengonfigurasi? status ii, iU, atau iF

Aturan kerja yang menghemat waktu: berhenti di lapis pertama yang gagal. Kalau lapis 1 sudah salah, mengutak-atik dpkg hanya menambah kerusakan baru.

💡 Tips: selalu baca keluaran apt update sampai baris terakhir. Baris Err, Ign, dan W: adalah tempat kerusakan bersembunyi, bukan di awal output.

🔹 Tiga fakta yang menyelamatkan waktu

  • Status keluar bisa menipu. Di banyak versi APT, apt-get update tetap keluar dengan status 0 walau ada baris E: Some index files failed to download. Skrip apt update && apt upgrade -y pun lanjut seolah tidak terjadi apa-apa.
  • Kandidat dibaca dari katalog lokal. apt install tidak menanyakan versi ke internet saat itu juga. Kalau indeks basi, kamu memasang versi basi walau repo sudah punya versi baru.
  • Satu paket setengah jadi menahan semuanya. Selama ada paket berstatus iU atau iF, APT menolak menyelesaikan instalasi lain sampai masalah itu dibereskan.

🧩 Istilah penting

Istilah Arti sederhana
Suite Nama edisi repo, mis. bookworm atau trixie
Component Bagian isi repo: main, contrib, non-free
Indeks Katalog hasil unduhan apt update, disimpan di /var/lib/apt/lists
Candidate Versi yang akan dipasang kalau kamu mengetik apt install
Pin priority Angka yang menentukan repo atau versi mana yang dipilih APT
Hold Penanda agar paket tidak ikut naik versi otomatis
ii Paket terpasang dan sudah dikonfigurasi, artinya sehat
iU Berkas sudah dibuka, konfigurasi belum selesai
iF Konfigurasi sudah jalan tetapi gagal di tengah
rc Paket dihapus, file konfigurasinya masih tertinggal

📊 Angka penting: indeks paket Debian 12 untuk satu arsitektur bisa mencapai 10–16 MB per suite. Itu sebabnya apt update butuh waktu, dan sebabnya indeks lama masih bisa "menyelamatkan" perintah yang gagal sekaligus menyesatkan.

🔧 Praktik: audit lima lapis dan delapan uji rusak

🔹 Siapkan lab dan aturan main

Gunakan mesin virtual Debian 12 atau 13, bukan server produksi. Ambil snapshot dulu supaya kamu bisa kembali kapan saja.

  1. Snapshot dulu. Praktikum ini sengaja merusak konfigurasi repo.
  2. Satu perubahan, satu bukti. Catat perintah dan keluarannya ke folder kerja.
  3. Selalu pulihkan sebelum lanjut ke uji berikutnya.
  4. Jangan pakai trusted=yes hanya agar praktikum cepat selesai, karena itu mematikan pemeriksaan tanda tangan.
mkdir -p ~/lab-paket
cd ~/lab-paket

🔹 Langkah 1: rekam kondisi awal

Baseline adalah foto sebelum kerusakan. Tanpa baseline, kamu tidak bisa membedakan "memang begitu dari awal" dan "baru rusak gara-gara praktikum". 

cat /etc/os-release
dpkg --print-architecture
grep -rhE '^(deb|Types:)' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null | sort
sudo apt-get update 2>&1 | tee baseline-update.log | tail -n 15
apt-cache policy | head -n 20
apt-get check 2>&1 | tail -n 3
dpkg --audit
apt-mark showhold
ls -lh /var/lib/apt/lists/ | head -n 10

Yang perlu kamu catat: jumlah baris sumber, suite yang dipakai, arsitektur, dan jam berkas indeks. Tiga data terakhir jadi pembanding di semua uji berikutnya.

💡 Tips: kalau keluaran apt-get check bersih dan dpkg --audit kosong, mesinmu sedang sehat. Itu titik nol yang sah untuk praktikum.

🔹 Langkah 2: bukti lima lapis dalam satu putaran

Pasang satu paket kecil sambil memperhatikan tiap lapis. Contoh di sini cowsay, paket kecil yang aman dipasang dan dihapus. 

apt-cache policy cowsay
sudo apt-get install -y cowsay 2>&1 | tee install-cowsay.log
dpkg -l cowsay
dpkg -S /usr/games/cowsay
tail -n 5 /var/log/apt/history.log

Urutan berpikirnya:

  1. apt-cache policy menunjukkan lapis 3: candidate, versi terpasang, dan repo asal.
  2. Baris Get: di log menunjukkan lapis 4: berkas diunduh dan diverifikasi.
  3. dpkg -l menunjukkan lapis 5: status harus ii.
  4. dpkg -S membuktikan file itu memang milik paket tersebut, bukan sisa paket lain.
  5. /var/log/apt/history.log mencatat siapa mengubah apa dan kapan.

🧪 Uji cepat: dpkg -l | grep -v '^ii' menampilkan semua paket yang tidak berstatus sehat. Kalau hasilnya hanya rc yang kamu sengaja tinggalkan, mesinmu bersih.

🔹 Langkah 3: uji A, suite salah ketik

Ubah suite di satu file sumber dari bookworm menjadi bookworm-lama. 

sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak
sudo sed -i 's/ bookworm / bookworm-lama /' /etc/apt/sources.list
sudo apt-get update 2>&1 | tail -n 8
apt-cache policy bash

Gejala yang muncul: baris E: The repository ... does not have a Release file dan peringatan bahwa repo seperti itu tidak bisa dipakai dengan aman. Kandidat untuk bash bisa tetap ada karena repo lain masih sehat, tetapi paket yang hanya ada di repo rusak akan hilang.

Arti: kerusakan ada di lapis 1. dpkg sama sekali belum tersentuh. Pulihkan dengan sudo cp /etc/apt/sources.list.bak /etc/apt/sources.list.

🔹 Langkah 4: uji B, component kurang

Hapus satu component dari baris repo, misalnya contrib, lalu cari paket yang rumahnya di sana. 

sudo sed -i 's/ main contrib non-free-firmware/ main non-free-firmware/' /etc/apt/sources.list
sudo apt-get update > /dev/null 2>&1
apt-cache policy cowsay

Kalau paket contohmu berasal dari contrib, hasilnya Unable to locate package padahal repo-nya benar dan internetnya jalan. Ini beda penting: "tidak ditemukan" bukan berarti "tidak ada di dunia", hanya "tidak ada di katalog yang kamu muat".

⚠️ Hati-hati: jangan langsung menyimpulkan repo mati saat melihat Unable to locate package. Tiga penyebab paling sering: component kurang, arsitektur salah, atau indeks basi.

🔹 Langkah 5: uji C, nama file sumber tidak sah

APT hanya membaca nama file dengan aturan tertentu: huruf, angka, garis bawah, tanda hubung, dan titik, dengan ekstensi .list atau .sources. 

sudo cp /etc/apt/sources.list /etc/apt/sources.list.d/backup-2026.list.bak
sudo apt-get update 2>&1 | grep -i ignoring

Muncul pemberitahuan bahwa file diabaikan karena ekstensinya tidak sah. File itu ada di disk, isinya benar, tetapi tidak pernah dibaca.

📊 Angka penting: aturan nama file di sources.list.d/ hanya mengizinkan a-z, A-Z, 0-9, _, -, dan . Nama seperti repo baru.list atau repo.list.save akan dilewati.

🔹 Langkah 6: uji D, sukses palsu

Ini uji paling penting untuk dunia kerja: tambahkan satu repo yang tidak bisa dijangkau, lalu periksa status keluarnya. 

echo 'deb http://repo-internal.lab.local/debian bookworm main' | sudo tee /etc/apt/sources.list.d/internal.list
sudo apt-get update 2>&1 | tail -n 6
echo "status keluar: $?"
ls -l --time-style=long-iso /var/lib/apt/lists/ | head -n 5

Yang sering terjadi: ada baris E: Some index files failed to download. They have been ignored, or old ones used instead. tetapi status keluar tetap 0. Indeks lama tetap dipakai, dan jam berkas di /var/lib/apt/lists untuk repo sehat ikut diperbarui sementara repo rusak tidak.

Akibat nyata: skrip otomatis menganggap pembaruan berhasil, padahal satu sumber tidak pernah tersentuh. Kalau kamu ingin perintah berhenti saat ada yang gagal, pakai mode galat yang tegas: 

sudo apt-get update -o APT::Update::Error-Mode=any
echo "status keluar: $?"

🔥 Kasus nyata: Sebuah kantor punya skrip harian apt update && apt upgrade -y di 12 server. Repo internal mereka mati setelah pindah ruang server, dan tidak ada satu pun alarm berbunyi selama tiga minggu karena skrip selalu "sukses". Temuan datang dari audit rutin: tanggal berkas indeks di satu server tidak berubah selama 20 hari. Perbaikan yang diambil bukan monitoring rumit, tetapi mengganti perintah menjadi mode galat tegas plus pemeriksaan umur indeks.

🔹 Langkah 7: uji E, tanda tangan tidak bisa diverifikasi

Buat entri repo yang menunjuk berkas kunci yang tidak ada. 

echo 'deb [signed-by=/etc/apt/keyrings/lab.asc] http://deb.debian.org/debian bookworm main' | sudo tee /etc/apt/sources.list.d/lab-key.list
sudo apt-get update 2>&1 | tail -n 8
sudo apt-get install -y --reinstall bash 2>&1 | tail -n 5

APT menolak repo itu karena tanda tangannya tidak bisa dipastikan. Kata kuncinya bisa berupa NO_PUBKEY, is not signed, atau pesan sejenis, karena bunyi persisnya berbeda antar versi APT. Artinya tetap satu: lapis 4 menolak.

Yang perlu dipahami: ini bukan gangguan, ini justru pengaman. Kalau repositori bisa dipakai tanpa kunci, siapa pun yang bisa membajak jalur jaringan bisa mengirim paket palsu yang dipasang sebagai root.

⚠️ Hati-hati: jangan menyelesaikan pesan kunci hilang dengan trusted=yes atau apt-key adv. Cara yang benar: unduh kunci dari sumber resmi, periksa fingerprint-nya, simpan di /usr/share/keyrings/, lalu rujuk lewat signed-by=.

🔹 Langkah 8: uji F, paket lepas dengan dependensi kurang

Sekarang kerusakan yang menyentuh lapis 5. Buat paket latihan yang bergantung pada paket yang belum terpasang. 

mkdir -p latihan/DEBIAN
printf 'Package: paket-latihan\nVersion: 1.0\nArchitecture: all\nMaintainer: Lab TKJ <lab@example.org>\nDepends: cowsay\nDescription: Paket latihan untuk uji dpkg\n\n' | sudo tee latihan/DEBIAN/control
dpkg-deb --build latihan paket-latihan_1.0_all.deb
sudo apt-get remove -y cowsay
sudo dpkg -i paket-latihan_1.0_all.deb 2>&1 | tail -n 8
dpkg -l paket-latihan
dpkg --audit

Hasil yang diharapkan: dpkg memasang berkas, lalu berhenti karena dependensi belum terpenuhi. Statusnya iU, dan dpkg --audit melaporkan ada paket setengah terpasang. Selama kondisi ini bertahan, instalasi paket lain juga bisa ikut tertahan.

Pulihkan dengan membiarkan APT menyelesaikan pekerjaan yang tadi dipaksa: 

sudo apt --fix-broken install
dpkg -l paket-latihan
dpkg --audit

Status harus berubah menjadi ii dan dpkg --audit kembali kosong. Perhatikan bedanya: dpkg -i hanya memasang berkas, sedangkan apt install ./paket-latihan_1.0_all.deb memasang sekaligus menyelesaikan dependensi.

🔥 Kasus nyata: Sebuah klinik memasang aplikasi kasir dari berkas .deb pemberian vendor memakai dpkg -i. Dependensi satu paket pustaka tertinggal, status jadi iU, aplikasi tidak mau jalan. Keesokan harinya petugas mencoba memasang paket lain untuk memperbaiki, dan semua perintah apt install ikut gagal dengan pesan unmet dependencies. Kesimpulan staf saat itu: "server rusak, perlu diinstal ulang". Padahal satu perintah apt --fix-broken install menyelesaikannya dalam hitungan detik.

📊 Angka penting: pemeriksaan dpkg --audit per paket tersedia sejak dpkg 1.17.10. Perintah ini mencari paket yang hanya terpasang sebagian, data kontrol yang hilang, atau berkas yang tidak sesuai catatan.

🔹 Langkah 9: uji G, hold menahan versi

apt-cache policy cowsay
sudo apt-mark hold cowsay
apt-mark showhold
sudo apt-get upgrade --dry-run 2>&1 | grep -iE 'kept back|held'
sudo apt-mark unhold cowsay

Paket yang di-hold tidak ikut naik versi otomatis. Pesan kept back bisa muncul karena hold, bisa juga karena dependensi yang belum siap. Cara membedakannya hanya satu: apt-mark showhold.

💡 Tips: biasakan apt-get upgrade --dry-run sebelum upgrade sungguhan. Kamu melihat daftar paket yang akan berubah tanpa menyentuh sistem.

🔹 Langkah 10: uji H, pin menahan versi tertentu

Pin adalah cara resmi menahan satu paket tanpa mengunci seluruh sistem. 

printf 'Package: bash\nPin: version *\nPin-Priority: 1001\n' | sudo tee /etc/apt/preferences.d/lab-pin
apt-cache policy bash
sudo apt-get upgrade --dry-run 2>&1 | grep -i bash
sudo rm /etc/apt/preferences.d/lab-pin

Perhatikan kolom Pin-Priority berubah menjadi 1001 dan kandidat tetap di versi sekarang. Ini mekanisme yang dipakai administrator untuk mencegah satu paket ikut naik saat repo baru ditambahkan.

⚠️ Hati-hati: pin yang terlalu luas bisa membuat paket keamanan tidak pernah naik. Selalu batasi pin ke satu paket atau satu repo yang benar-benar kamu pahami.

🔹 Langkah 11: pulihkan dan baca riwayat

Setelah delapan uji, bersihkan semua jejak dan buktikan pemulihannya. 

sudo rm -f /etc/apt/sources.list.d/internal.list /etc/apt/sources.list.d/lab-key.list /etc/apt/sources.list.d/backup-2026.list.bak
sudo apt-get update -o APT::Update::Error-Mode=any
sudo apt --fix-broken install
sudo dpkg --configure -a
sudo apt-get check
dpkg --audit
dpkg -l | grep -v '^ii'
sudo apt-get clean

Lalu buka catatan sejarah sistem. Dua berkas ini menjawab "siapa mengubah apa" saat kamu menerima server warisan. 

tail -n 30 /var/log/apt/history.log
tail -n 30 /var/log/dpkg.log
zgrep -h ' install ' /var/log/dpkg.log.*.gz 2>/dev/null | tail -n 10

🔹 Langkah 12: jadikan satu skrip audit

Daripada mengulang sebelas langkah tiap kali, simpan pemeriksaan intinya dalam satu berkas. 

#!/bin/bash
set -u
echo "== identitas =="
. /etc/os-release
echo "$PRETTY_NAME ($(dpkg --print-architecture))"

echo "== sumber aktif =="
grep -rhE '^(deb|Types:)' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null | sed 's/#.*//' | grep -v '^$'

echo "== umur indeks =="
find /var/lib/apt/lists -name 'Packages*' -printf '%TY-%Tm-%Td %p\n' 2>/dev/null | sort | tail -n 3

echo "== konsistensi =="
apt-get check 2>&1 | tail -n 2
dpkg --audit

echo "== status tidak sehat =="
dpkg -l | awk '$1 != "ii" && NR > 5'

echo "== hold =="
apt-mark showhold

echo "== cache =="
du -sh /var/cache/apt/archives 2>/dev/null

🧪 Uji cepat: jalankan skrip ini di setiap server sebelum dan sesudah perubahan repo. Bila keluarannya sama, perubahanmu tidak meninggalkan kerusakan.

🏭 Dipakai di dunia kerja

  • Sekolah dan lab komputer: satu ruang praktik butuh versi paket yang sama di semua PC. Audit indeks adalah cara termurah memastikan tidak ada siswa yang dapat versi berbeda saat ujian berbasis komputer.
  • Kantor dan tim IT support: server warisan sering punya tambahan repo dari vendor lama. Audit sumber menjawab kenapa satu server berperilaku beda dari sembilan server lain yang katanya "settingnya sama".
  • Rumah sakit dan layanan publik: pembaruan keamanan tidak boleh diam-diam berhenti. Memeriksa umur indeks adalah alarm sederhana yang menangkap repo mati sebelum jadi insiden.
  • ISP dan penyedia layanan: armada server besar butuh pembaruan yang bisa diaudit. Status keluar perintah dan jam indeks adalah bukti yang bisa dilampirkan ke laporan perubahan.
  • Industri dan jaringan OT: mesin produksi sering tidak boleh berubah tiba-tiba. Hold dan pin dipakai agar paket pendukung tetap di versi yang sudah diuji.
  • Cloud dan tim platform: template mesin baru harus bisa dibangun ulang dengan hasil sama. Audit repositori memastikan semua mesin memakai sumber resmi yang konsisten.

✅ Verifikasi

Perintah Yang harus terlihat Artinya
apt-get update -o APT::Update::Error-Mode=any status 0, tanpa baris E: semua sumber terbaca
ls -l /var/lib/apt/lists/ jam berkas baru indeks benar-benar diperbarui
apt-cache policy <paket> Candidate dan baris repo 500 lapis 3 sehat
apt-get check selesai tanpa error dependensi konsisten
dpkg --audit kosong tidak ada paket setengah jadi
dpkg -l <paket> ii terpasang dan terkonfigurasi
apt-mark showhold hanya paket yang sengaja ditahan tidak ada hold warisan
apt-get upgrade --dry-run daftar perubahan wajar tidak ada kejutan saat upgrade
tail -n 20 /var/log/apt/history.log perubahanmu tercatat jejak audit tersedia

Langkah verifikasi terakhir: ulangi seluruh praktikum dari snapshot bersih. Kalau hasil setiap uji sama, prosedurmu sudah layak diajarkan ke kelas lain.

⚠️ Kesalahan umum & troubleshooting

Gejala Penyebab paling sering Langkah pertama
Unable to locate package component kurang, arsitektur beda, indeks basi apt-cache policy <paket>
does not have a Release file suite atau URI salah ketik baca baris Err dan Ign
NO_PUBKEY atau is not signed kunci hilang atau salah tempat periksa fingerprint, pasang di /usr/share/keyrings
Hash Sum mismatch mirror setengah sinkron atau cache proxy apt-get clean lalu ulangi
kept back saat upgrade hold atau dependensi belum siap apt-mark showhold
unmet dependencies setelah dpkg -i dependensi tidak ikut dipasang apt --fix-broken install
dpkg was interrupted proses sebelumnya terputus dpkg --configure -a
paket iF berulang skrip postinst gagal baca /var/log/dpkg.log
No space left on device cache dan indeks memenuhi partisi df -h lalu apt-get clean
"sudah versi terbaru" padahal beda pin atau prioritas repo lain apt-cache policy <paket>

Beberapa kebiasaan yang mencegah empat puluh menit kebingungan:

  • Salin keluaran perintah ke berkas sebelum mengubah apa pun. Terminal bisa ditutup, bukti tidak boleh hilang.
  • Ubah satu file sumber per percobaan, lalu jalankan apt-get update. Perubahan bertumpuk membuat penyebab tidak bisa dibedakan.
  • Jangan memperbaiki dpkg sebelum lapis 1 sampai 3 terbukti sehat.
  • Kalau ragu, --dry-run dulu. Tidak ada cerita buruk yang dimulai dari simulasi.

🔐 Catatan keamanan & etika

  • Repo adalah hak root bagi pemiliknya. Menambah sumber berarti mempercayakan eksekusi skrip pemasangan sebagai root kepada pemilik repo itu.
  • Jangan pakai trusted=yes untuk melewati pemeriksaan tanda tangan. Kalau kunci bermasalah, perbaiki kuncinya, jangan matikan pengamannya.
  • Verifikasi fingerprint kunci sebelum dipasang. Kunci yang salah sama saja dengan memberi kunci gudang kepada orang asing.
  • dpkg -i dari berkas tak dikenal menjalankan skrip postinst sebagai root. Periksa asal berkas dan checksum-nya.
  • Pin dan hold adalah alat produksi. Uji di VM dulu, karena pin yang salah bisa menahan pembaruan keamanan berbulan-bulan tanpa ada yang sadar.
  • Etika laboratorium: praktik merusak repo hanya di mesin milikmu atau VM lab. Jangan pernah menguji di server sekolah, kantor, atau mesin orang lain tanpa izin.

🧪 Uji cepat: apt-get indextargets --format '$(SITE) $(RELEASE)' menampilkan daftar sumber yang benar-benar dipahami APT. Cocokkan dengan file yang kamu tulis sendiri.

📌 Kesimpulan

Paket yang gagal terpasang hampir selalu bisa dilacak ke satu dari lima lapis: sumber, indeks, pemilihan, unduhan bertanda tangan, atau pemasangan. Auditor yang baik tidak menebak; ia berhenti di lapis pertama yang gagal dan memperbaiki hanya lapis itu.

Langkah berikutnya: ambil satu server nyata di labmu, jalankan skrip audit dari Langkah 12, dan simpan keluarannya sebagai baseline. Minggu depan jalankan lagi dan bandingkan, karena selisihnya adalah cerita tentang apa yang berubah di mesin itu.

🔗 Materi terkait

📚 Referensi

Retrieved from "https://noctkj.net/index.php?title=Linux_:_Praktikum_Audit_Repositori_dan_Diagnosa_Instalasi_Paket_Gagal&oldid=1679"