apt purge menghapus VPN, tetapi layanan tetap mulai saat boot

apt purge menyatakan paket sudah hilang, namun terowongan tetap muncul setiap kali mulai. Journal terus bertambah, rute kembali, dan mesin berperilaku seolah tidak ada yang dihapus. Pemasang dari vendor dapat menulis berkas yang tidak pernah dicatat pengelola paket, jadi menghapus paket dan menghapus produk adalah dua pekerjaan berbeda. Runbook di bawah memisahkan kedua catatan dan menuntaskan penghapusan dengan sengaja.

Dua pemasang, dua catatan berbeda

Paket Debian menyimpan daftar berkas, dan purge menghapus persis apa yang disebut daftar itu ditambah konfigurasi paket. Pemasang shell atau bundel .run tidak menyimpan daftar semacam itu; ia menulis ke mana saja, biasanya ke /opt, /usr/local, dan /etc/systemd/system. Tidak satu pun jalur itu muncul di daftar berkas paket mana pun, sehingga dpkg tidak mengetahuinya dan tidak melaporkannya. Anda berakhir dengan dua pemilik pemasangan pada satu sistem berkas, dan hanya satu di antaranya yang mencatat pembukuan.

Tanyakan dpkg tentang jalur tertentu sebelum menghapusnya. Jalur yang tidak diakuinya adalah milik Anda untuk dihapus, dan jawaban yang sama memberi tahu apakah peningkatan nanti akan mengembalikannya.

dpkg -S /etc/systemd/system/acmevpn.service
systemctl list-unit-files | grep -i acmevpn

Unit dan tautan wants-nya adalah berkas terpisah

Mengaktifkan adalah tindakan terpisah dari memasang. Unit menyatakan hubungan target di bagian [Install], dan systemctl enable mengubah pernyataan itu menjadi tautan simbolik di dalam direktori .wants/ setiap target. Kini ada dua jalur: berkas unit, dan tautan yang menariknya ke target boot. Hapus hanya berkasnya dan tautan menunjuk ke ketiadaan, yang menimbulkan keluhan saat boot; hapus hanya tautannya dan unit tetap bisa dijalankan dengan nama. Keduanya harus pergi.

Hapus keduanya secara berurutan lalu muat ulang, agar systemd berhenti menyimpan definisi lama di memori.

systemctl disable --now acmevpn.service
systemctl show -p FragmentPath -p ExecStart acmevpn.service
sudo rm /etc/systemd/system/acmevpn.service
sudo rm /etc/systemd/system/multi-user.target.wants/acmevpn.service
systemctl daemon-reload

Baca FragmentPath alih-alih mengasumsikan lokasinya, karena vendor mungkin menulis ke /usr/lib/systemd/system atau /lib/systemd/system dan bukan ke /etc. Menghapus salinan yang Anda duga meninggalkan salinan efektif tetap berjalan, dan perbaikan tampak berhasil sampai pemuatan ulang berikutnya. Daftarkan berkas unit lagi setelah pemuatan ulang selesai, dan pastikan nama itu tidak lagi muncul.

Temukan biner yang menjaga tatanan ini tetap hidup

Unit yang aktif terus menjalankan daemon apa pun yang diyakini basis data paket. Proses itu dapat mengembalikan terowongan, menambah rute lagi, atau memulihkan aturan kill-switch, dan perilakunya tampak supranatural sampai Anda memeriksa tatanannya. Ikuti jalur ExecStart dan periksa apakah biner itu masih ada, karena berkas yang dapat dieksekusi yang tertinggal di bawah /opt adalah semua yang dibutuhkan tatanan ini. Menghapus unit menghentikan start terjadwal; itu tidak menghapus programnya.

Perlakukan direktori status dengan kehati-hatian yang sama. Token akun, profil yang dihasilkan, dan daftar server yang di-cache hidup di bawah /var/lib atau di direktori home, dan itu kredensial, bukan cache sekali buang. Hapus setelah layanan dihentikan, dengan sengaja, dan catat apa yang Anda ambil.

sudo ls -l /opt/acmevpn /usr/local/bin/acmevpn
sudo find /var/lib -maxdepth 2 -iname "*acme*"
systemctl is-enabled acmevpn.service

Pilih satu pemilik boot dan ujilah

Tiga kandidat dapat mengklaim boot, dan memasang ketiganya menghasilkan perlombaan alih-alih pengaman ganda. Berkas autostart desktop hanya berjalan setelah seseorang masuk, unit systemd berjalan lebih awal tetapi membutuhkan klien yang bekerja tanpa layar, dan entri cron @reboot menyala menurut jadwal yang bisa salah untuk klien jaringan. CLI vendor mungkin juga memerlukan argumen server, karena saat boot tidak ada sesi sebelumnya untuk dilanjutkan. Pilih kandidat yang cocok dengan cara klien mengautentikasi, dan buang yang lain.

Ujilah dengan memulai ulang mesin dan melihat tiga fakta independen: status unit, daftar proses, dan koneksi baru ke sesuatu yang dapat Anda verifikasi. Klien yang memerlukan keyring atau login interaktif gagal saat boot bahkan dengan berkas unit yang benar, dan journal mengatakan demikian jika Anda membacanya alih-alih hanya status layanan.

Entah beri klien kredensial yang bekerja tanpa prompt, atau jalankan saat login. Keduanya dapat dipertahankan, dan menggabungkannya adalah cara satu terowongan memperoleh dua pemilik yang berebut.

Catat apa yang harus diharapkan purge berikutnya

Catat dua fakta setelah setiap penghapusan manual: pemasang mana yang membuat tatanan itu, dan pemilik mana yang kini menjalankannya. Catatan itu mengubah purge berikutnya dari kejutan menjadi butir daftar periksa, dan ia hidup lebih lama daripada orang yang melakukan pekerjaan itu.

Simpan di samping konfigurasi layanan, bukan di direktori pribadi, dan beri tanggal, karena pembaruan vendor dapat memulihkan unit yang Anda hapus. Membandingkan systemctl list-unit-files dengan catatan itu setiap beberapa bulan menangkap pemulihan selagi perbaikannya masih murah.