apt purge VPN'i kaldırdı ama hizmet yine de açılışta başlıyor

apt purge paketin gittiğini söylüyor, yine de her açılışta bir tünel yeniden yükseliyor. Journal büyümeye devam ediyor, rotalar geri geliyor ve makine hiçbir şey kaldırılmamış gibi davranıyor. Satıcının kurulum betiği, paket yöneticisinin hiç kaydetmediği dosyalar yazabilir, bu yüzden bir paketi kaldırmak ile bir ürünü kaldırmak iki farklı iştir. Aşağıdaki runbook iki kaydı ayırır ve kaldırmayı bilerek tamamlar.

İki kurulum betiği, iki farklı kayıt

Debian paketleri bir dosya listesi tutar ve purge tam olarak bu listenin adlandırdığı şeyleri artı paket yapılandırmasını siler. Bir shell kurulum betiği veya .run paketi böyle bir liste tutmaz; istediği yere yazar, genellikle /opt, /usr/local ve /etc/systemd/system içine. Bu yolların hiçbiri herhangi bir paketin dosya listesinde görünmez, bu yüzden dpkg onları ne bilir ne de bildirir. Sonunda tek bir dosya sisteminde iki kurulum sahibi olur ve yalnızca biri defter tutar.

Silmeden önce belirli yolu dpkg'ye sorun. Reddettiği yol sizin kaldırmanız içindir ve aynı yanıt, daha sonraki bir yükseltmenin onu geri getirip getirmeyeceğini de söyler.

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

Bir unit ve wants bağlantısı ayrı dosyalardır

Etkinleştirme kurulumdan ayrı bir eylemdir. Unit, hedef ilişkilerini [Install] bölümünde bildirir ve systemctl enable bu bildirimleri her hedefin .wants/ dizininde sembolik bağlantılara çevirir. Artık iki yol vardır: unit dosyası ve onu bir açılış hedefine çeken bağlantı. Yalnızca dosyayı silerseniz bağlantı hiçbir yeri göstermez, bu da açılışta şikâyet üretir; yalnızca bağlantıyı silerseniz unit adıyla başlatılabilir kalır. İkisi de gitmelidir.

Bunları sırayla kaldırın ve sonra yeniden yükleyin, böylece systemd eski tanımları bellekte tutmayı bırakır.

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

Konumu varsaymak yerine FragmentPath okuyun, çünkü satıcı /etc yerine /usr/lib/systemd/system veya /lib/systemd/system içine yazmış olabilir. Beklediğiniz kopyayı silmek etkin olanı çalışır bırakır ve düzeltme bir sonraki yeniden yüklemeye kadar başarılı görünür. Yeniden yükleme bitince unit dosyalarını tekrar listeleyin ve adın artık görünmediğini doğrulayın.

Bu düzeni canlı tutan ikili dosyayı bulun

Etkin bir unit, paket veritabanı neye inanırsa inansın arka plan sürecini başlatmaya devam eder. O süreç tüneli geri getirebilir, rotaları yeniden ekleyebilir veya bir kill-switch kuralını geri yükleyebilir ve düzeni inceleyene kadar davranış doğaüstü görünür. ExecStart yolunu izleyin ve ikili dosyanın hâlâ orada olup olmadığına bakın, çünkü /opt altında bırakılmış bir çalıştırılabilir dosya bu düzenin ihtiyacı olan her şeydir. Unit'i silmek planlanmış başlatmayı durdurur; programı silmez.

Durum dizinlerine de aynı özenle davranın. Hesap belirteçleri, üretilmiş profiller ve önbelleğe alınmış sunucu listeleri /var/lib altında veya bir ev dizininde yaşar ve bunlar kimlik bilgileridir, atılacak önbellek değil. Hizmet durduktan sonra bunları bilerek kaldırın ve ne aldığınızı not edin.

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

Tek bir açılış sahibi seçin ve test edin

Üç aday açılışı talep edebilir ve üçünü birden kurmak çift güvence yerine bir yarış üretir. Masaüstü otomatik başlatma dosyası ancak biri oturum açtıktan sonra çalışır, systemd unit'i daha erken çalışır ama ekransız çalışan bir istemci gerektirir ve cron @reboot girdisi bir ağ istemcisi için yanlış olabilecek bir zamanlamayla tetiklenir. Satıcının CLI'si ek olarak bir sunucu argümanı isteyebilir, çünkü açılışta sürdürülecek önceki bir oturum yoktur. İstemcinin kimlik doğrulama biçimine uyan adayı seçin ve diğerlerini bırakın.

Makineyi yeniden başlatıp üç bağımsız gerçeğe bakarak test edin: unit durumu, süreç listesi ve doğrulayabileceğiniz bir şeye yeni bağlantı. Anahtarlık veya etkileşimli oturum açma gerektiren bir istemci doğru unit dosyasıyla bile açılışta başarısız olur ve journal bunu söyler, yalnızca hizmet durumunu değil onu okursanız.

Ya istemciye sormadan çalışan bir kimlik bilgisi verin ya da oturum açılışında başlatın. İkisi de savunulabilir ve ikisini birleştirmek bir tünelin onun için kavga eden iki sahibi olmasının yoludur.

Bir sonraki purge'in neyi beklemesi gerektiğini yazın

Her elle kaldırmadan sonra iki gerçeği not edin: bu düzeni hangi kurulum betiği oluşturdu ve şimdi hangi sahip başlatıyor. Bu not, bir sonraki purge'i sürprizden bir kontrol listesi maddesine çevirir ve işi yapan kişiden daha uzun yaşar.

Onu kişisel bir dizinde değil hizmet yapılandırmasının yanında tutun ve tarih atın, çünkü bir satıcı güncellemesi sildiğiniz unit'i geri getirebilir. systemctl list-unit-files listesini birkaç ayda bir o notla karşılaştırmak, düzeltme henüz ucuzken geri getirmeyi yakalar.