apt purge menghapuskan VPN, tetapi perkhidmatan masih bermula semasa boot

apt purge berkata pakej sudah tiada, namun terowong masih timbul pada setiap permulaan. Journal terus membesar, laluan kembali, dan mesin berkelakuan seolah-olah tiada apa yang dibuang. Pemasang vendor boleh menulis fail yang tidak pernah direkodkan oleh pengurus pakej, jadi menanggalkan pakej dan menanggalkan produk ialah dua kerja berbeza. Runbook di bawah memisahkan kedua-dua rekod dan menyelesaikan penyingkiran dengan sengaja.

Dua pemasang, dua rekod berbeza

Pakej Debian menyimpan senarai fail, dan purge memadam tepat apa yang disenaraikan oleh senarai itu serta konfigurasi pakej. Pemasang shell atau bundel .run tidak menyimpan senarai sedemikian; ia menulis di mana-mana yang ia suka, biasanya ke /opt, /usr/local dan /etc/systemd/system. Tiada satu pun laluan itu muncul dalam senarai fail mana-mana pakej, jadi dpkg tidak mengetahuinya dan tidak melaporkannya. Anda berakhir dengan dua pemilik pemasangan pada satu sistem fail, dan hanya seorang daripada mereka menyimpan akaun.

Tanya dpkg tentang laluan tertentu sebelum memadamnya. Laluan yang ditolaknya adalah milik anda untuk dibuang, dan jawapan yang sama memberitahu sama ada peningkatan kemudian akan mengembalikannya.

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

Unit dan pautan wants-nya ialah fail berasingan

Mengaktifkan ialah tindakan berasingan daripada memasang. Unit mengisytiharkan hubungan sasaran dalam bahagian [Install], dan systemctl enable menukar isytihar itu menjadi pautan simbolik di dalam direktori .wants/ setiap sasaran. Kini ada dua laluan: fail unit, dan pautan yang menariknya ke sasaran boot. Padam fail sahaja dan pautan menunjuk ke tiada, yang menghasilkan aduan semasa boot; padam pautan sahaja dan unit kekal boleh dimulakan mengikut nama. Kedua-duanya mesti pergi.

Buang kedua-duanya mengikut urutan dan muat semula selepas itu, supaya systemd berhenti menyimpan takrif lama dalam 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 dan bukannya menganggap lokasinya, kerana vendor mungkin menulis ke /usr/lib/systemd/system atau /lib/systemd/system dan bukan ke /etc. Memadam salinan yang anda jangkakan membiarkan yang berkesan terus berjalan, dan pembaikan kelihatan berjaya sehingga muat semula seterusnya. Senaraikan fail unit semula selepas muat semula selesai, dan sahkan nama itu tidak lagi muncul.

Cari binari yang mengekalkan susunan ini hidup

Unit yang diaktifkan terus memulakan daemon apa pun yang dipercayai oleh pangkalan data pakej. Proses itu boleh membawa terowong kembali, menambah laluan semula atau memulihkan peraturan kill-switch, dan kelakuannya kelihatan luar biasa sehingga anda memeriksa susunannya. Ikut laluan ExecStart dan periksa sama ada binari itu masih ada, kerana fail boleh laku yang ditinggalkan di bawah /opt ialah semua yang diperlukan oleh susunan itu. Memadam unit menghentikan permulaan berjadual; ia tidak memadam program.

Tangani direktori keadaan dengan hati-hati yang sama. Token akaun, profil yang dijana dan senarai pelayan yang dicache hidup di bawah /var/lib atau dalam direktori rumah, dan itu kelayakan, bukan cache buangan. Buangnya selepas perkhidmatan 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 seorang pemilik boot dan ujinya

Tiga calon boleh menuntut boot, dan memasang ketiga-tiganya menghasilkan perlumbaan dan bukannya perlindungan berganda. Fail autostart desktop hanya berjalan selepas seseorang log masuk, unit systemd berjalan lebih awal tetapi memerlukan klien yang berfungsi tanpa skrin, dan entri cron @reboot menyala mengikut jadual yang mungkin salah untuk klien rangkaian. CLI vendor mungkin juga memerlukan hujah pelayan, kerana semasa boot tiada sesi sebelumnya untuk diteruskan. Pilih calon yang sepadan dengan cara klien mengesahkan identiti, dan buang yang lain.

Ujinya dengan memulakan semula mesin dan melihat tiga fakta bebas: keadaan unit, senarai proses, dan sambungan baharu ke sesuatu yang boleh anda sahkan. Klien yang memerlukan keyring atau log masuk interaktif gagal semasa boot walaupun dengan fail unit yang betul, dan journal menyatakannya jika anda membacanya dan bukan hanya status perkhidmatan.

Sama ada beri klien kelayakan yang berfungsi tanpa gesaan, atau mulakannya semasa log masuk. Kedua-duanya boleh dipertahankan, dan menggabungkannya ialah cara satu terowong mendapat dua pemilik yang berebut.

Catat apa yang patut dijangka oleh purge seterusnya

Catat dua fakta selepas setiap penyingkiran manual: pemasang mana yang mencipta susunan itu, dan pemilik mana yang memulakannya sekarang. Nota itu menukar purge seterusnya daripada kejutan kepada butiran senarai semak, dan ia hidup lebih lama daripada orang yang melakukan kerja itu.

Simpan di sebelah konfigurasi perkhidmatan dan bukan dalam direktori peribadi, dan beri tarikh, kerana kemas kini vendor boleh memulihkan unit yang anda padam. Membandingkan systemctl list-unit-files dengan nota itu setiap beberapa bulan menangkap pemulihan itu semasa pembaikannya masih murah.