Paket repo atau paket klien VPN: mana dulu?

Anda memasang paket vendor, perintah mengembalikan nol, tetapi tetap tidak ada aplikasi VPN untuk dijalankan. Itu terjadi ketika paket yang Anda pasang mengonfigurasi repo alih-alih menyertakan klien, dan perbedaannya terlihat pada apa yang ditinggalkannya di disk. Apakah Anda perlu keduanya, dan dalam urutan apa, bergantung pada tiga kondisi, bukan pada penamaan vendor. Keputusan di bawah ini menjaga penyiapan sumber, penyegaran metadata, dan pemasangan aplikasi sebagai tindakan terpisah dengan bukti terpisah.

Apa yang sebenarnya diubah tiap paket

Paket konfigurasi repo menulis entri sumber APT, mengimpor kunci penandatanganan yang dipercaya entri itu, lalu keluar. Isinya beberapa berkas di bawah /etc/apt ditambah keyring, dan tidak ada yang bisa dijalankan. Paket klien membawa daemon atau aplikasi desktop, pustakanya, dan dependensinya, dan itulah objek yang berakhir di menu atau unit systemd.

Nama berkas yang berakhiran -release menyarankan jenis pertama, tetapi akhiran itu konvensi, bukan jaminan. Pernyataan yang andal tentang peran sebuah paket adalah daftar berkas dan dependensinya, keduanya bisa dibaca sebelum memasang apa pun. Vendor yang membentuk ulang paketnya mempertahankan nama berkas yang sama dan mengubah isinya, sehingga jawaban yang disalin dari utas dua tahun lalu bisa menggambarkan paket yang sudah tidak ada. Baca instruksi penyedia yang berlaku untuk rilis yang Anda jalankan, lalu periksa apa yang dideklarasikan paket itu.

Tiga tahap mengikuti pemisahan itu: daftarkan sumber, segarkan metadata yang disuplainya, lalu pasang aplikasi dengan namanya. Panduan pemasangan Debian dan Ubuntu menjaganya tetap terpisah, karena itulah klien diminta pada langkah berikutnya, bukan oleh paket yang menyiapkan sumber.

Tiga kondisi yang menentukan urutan

Kondisi pertama adalah apakah vendor menerbitkan repo untuk rilis distribusi Anda yang tepat. Baris sumber yang dibuat untuk satu suite dapat diselesaikan terhadap dependensi suite lain dan memasang campuran yang belum pernah diuji siapa pun.

Kondisi kedua adalah apakah distribusi Anda sudah membawa klien. Bila sudah, paket distro mengikuti transisi pustaka dan pembaruan keamanan rilis Anda, sedangkan paket vendor bisa bergerak lebih cepat dan membawa salinannya sendiri atas pustaka bersama.

Kondisi ketiga adalah fitur apa yang benar-benar Anda butuhkan. Build vendor bisa membawa implementasi protokol yang lebih baru atau integrasi desktop yang belum dipaketkan distribusi Anda, dan itu alasan nyata untuk menerima sumber kedua. Jika build distro mencakup pemakaian Anda, menambahkan repo pihak ketiga membeli pekerjaan pembaruan dan satu hubungan kepercayaan lagi dengan imbalan yang sangat sedikit.

Putuskan ketiga jawaban itu sebelum baris sumber ada, karena menghapusnya nanti berarti membersihkan paket dan kuncinya. Setelah diputuskan, urutan di dalam jalur vendor bukan pilihan: sumber dulu, metadata kedua, aplikasi ketiga, tidak pernah terbalik.

Periksa apa yang ditinggalkan paket rilis

Sebelum memasang apa pun, baca daftar berkasnya, bukan deskripsinya. Pada sistem keluarga Debian, manifes paket menjawab apa yang dikonfigurasi dan ke mana kuncinya mendarat.

dpkg -L proton-vpn-release | grep -E 'apt|keyring'
apt-cache policy proton-vpn-gnome-desktop
grep -r protonvpn /etc/apt/sources.list.d/

Baris pertama menunjukkan berkas sumber dan jalur keyring, sedangkan baris kedua melaporkan versi apa yang bisa ditawarkan sumber yang dikonfigurasi. Jika apt-cache policy tidak mencetak apa pun untuk nama klien, penyegaran metadata belum terjadi atau sumber menargetkan suite lain. Baris ketiga memastikan entri berada di tempat yang benar-benar dibaca APT.

Cocokkan jalur keyring dengan bidang signed-by= di baris sumber. Kunci di direktori yang salah menghasilkan galat sumber tidak terautentikasi, yang merupakan kegagalan berbeda dari paket yang tidak tersedia.

Perlakukan kegagalan dependensi sebagai tahap terpisah

Memasang .deb hasil unduhan dengan dpkg -i tidak menyelesaikan apa pun: perintah itu memeriksa dependensi, melaporkan apa yang kurang, dan meninggalkan paket setengah terkonfigurasi. Itu perilaku yang diharapkan, bukan unduhan rusak.

apt --fix-broken install lalu meminta APT keadaan yang konsisten dari sumber yang Anda miliki. APT tidak tahu VPN mana yang Anda inginkan, dan rencananya bisa menghapus paket untuk memenuhi batasan yang ditemukannya. Baca transaksi yang diusulkan sebelum menjawab ya, dan berhenti bila penghapusan menyentuh sesuatu yang Anda butuhkan. Mengulangi perbaikan tanpa membaca rencananya adalah cara celah dependensi kecil berubah menjadi desktop yang tidak lagi menyala.

Simpan pesan bermakna pertama dari manajer paket dan klasifikasikan sebelum bertindak. Repo tanpa tanda tangan, paket yang tidak dibawa sumber terkonfigurasi, konflik versi, dan klien yang menyala lalu mati adalah empat kegagalan berbeda.

Verifikasi aplikasinya, bukan reponya

Pastikan klien mencapai status terpasang, lalu pastikan programnya menyala. dpkg-query -W -f='${Status} ${Version}' proton-vpn-gnome-desktop seharusnya melaporkan install ok installed dengan versi, dan kegagalan peluncuran setelah itu adalah masalah aplikasi, bukan masalah pemaketan.

Catat pemilik repo dan paket aplikasi sebagai objek terpisah, agar penghapusan nanti mengambil yang tepat dan meninggalkan yang lain utuh. Saat vendor mengubah panduannya, entri sumber adalah yang Anda baca ulang; nama klien adalah yang Anda pasang ulang.