apt purge forigis la VPN, sed la servo tamen startas ĉe la lanĉo

apt purge diras, ke la pakaĵo malaperis, kaj tamen tunelo ankoraŭ aperas ĉe ĉiu starto. La journal daŭre kreskas, la vojoj revenas, kaj la maŝino kondutas kvazaŭ nenio estus forigita. Provizanta instalilo povas skribi dosierojn, kiujn la pakaĵmastrumilo neniam registris, do malinstali pakaĵon kaj malinstali produkton estas malsamaj taskoj. La runbook ĉi-sube apartigas la du registrojn kaj finas la forigon intence.

Du instaliloj, du malsamaj registroj

Debianaj pakaĵoj tenas dosierliston, kaj purge forigas ĝuste tion, kion tiu listo nomas, plus la pakaĵan agordon. Ŝela instalilo aŭ .run pakaĵaro tenas nenian tian liston; ĝi skribas kie ĝi volas, kutime en /opt, /usr/local kaj /etc/systemd/system. Neniu el tiuj vojoj aperas en dosierlisto de iu ajn pakaĵo, do dpkg nek scias pri ili nek raportas ilin. Vi finas kun du instalposedantoj sur unu dosiersistemo, kaj nur unu el ili tenas librojn.

Demandu dpkg pri la konkreta vojo antaŭ ol forigi ĝin. Vojo, kiun ĝi rifuzas, estas via por forigi, kaj la sama respondo diras al vi, ĉu posta ĝisdatigo revenigus ĝin.

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

Unuo kaj ĝia wants-ligo estas apartaj dosieroj

Ŝalti estas aparta ago de instali. La unuo deklaras celrilatojn en sia sekcio [Install], kaj systemctl enable igas tiujn deklarojn simbolaj ligoj en la dosierujo .wants/ de ĉiu celo. Nun ekzistas du vojoj: la unua dosiero, kaj la ligo, kiu tiras ĝin en startan celon. Forigu nur la dosieron kaj la ligo montras al nenio, kio kaŭzas plendon ĉe la starto; forigu nur la ligon kaj la unuo restas startebla laŭ nomo. Ambaŭ devas foriri.

Forigu ilin laŭorde kaj poste reŝargu, por ke systemd ĉesu teni la malnovajn difinojn en la memoro.

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

Legu FragmentPath anstataŭ supozi la lokon, ĉar provizanto eble skribis al /usr/lib/systemd/system aŭ /lib/systemd/system anstataŭ /etc. Forigi la kopion, kiun vi atendis, lasas la efektivan plu funkcii, kaj la riparo ŝajnas sukcesa ĝis la sekva reŝargo. Listigu la unuajn dosierojn denove post la reŝargo, kaj konfirmu, ke la nomo ne plu aperas.

Trovu la plenumeblon, kiu tenas la aranĝon viva

Ŝaltita unuo daŭre startas la demonon, kion ajn la pakaĵa datumbazo kredas. Tiu procezo povas revenigi la tunelon, denove aldoni vojojn aŭ restarigi kill-switch regulon, kaj la konduto ŝajnas supernatura ĝis vi ekzamenas la aranĝon. Sekvu la vojon ExecStart kaj kontrolu, ĉu la plenumeblo ankoraŭ estas tie, ĉar plenumeblo lasita sub /opt estas ĉio, kion la aranĝo bezonas. Forigi la unuon haltigas la planitan starton; ĝi ne forigas la programon.

Traktu statdosierujojn kun la sama zorgemo. Kontaj ĵetonoj, generitaj profiloj kaj kaŝmemoraj servilaj listoj loĝas sub /var/lib aŭ en hejma dosierujo, kaj tiuj estas akreditaĵoj, ne forĵetebla kaŝmemoro. Forigu ilin post kiam la servo haltis, intence, kaj notu, kion vi prenis.

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

Elektu unu startposedanton kaj testu ĝin

Tri kandidatoj povas postuli la starton, kaj instali ĉiujn tri kreas vetkuron anstataŭ duoblan sekurecon. Labortabla aŭtomata startdosiero funkcias nur post kiam iu ensalutas, systemd unuo funkcias pli frue sed bezonas klienton, kiu funkcias sen ekrano, kaj cron @reboot enskribo ekbrulas laŭ horaro, kiu povas esti malĝusta por reta kliento. Provizanta CLI eble krome postulas servilan argumenton, ĉar ĉe la starto mankas antaŭa sesio por daŭrigi. Elektu la kandidaton, kiu kongruas kun la maniero, kiel la kliento aŭtentikigas, kaj forĵetu la aliajn.

Testu ĝin per restartigo de la maŝino kaj rigardo al tri sendependaj faktoj: la unua stato, la proceza listo, kaj nova konekto al io, kion vi povas kontroli. Kliento, kiu bezonas ŝlosilringon aŭ interagan ensaluton, malsukcesas ĉe la starto eĉ kun ĝusta unua dosiero, kaj la journal tion diras se vi legas ĝin anstataŭ nur la servan staton.

Aŭ donu al la kliento akreditaĵon, kiu funkcias sen demando, aŭ startigu ĝin ĉe ensaluto. Ambaŭ estas defendeblaj, kaj kombini ilin estas kiel unu tunelo akiras du posedantojn, kiuj disputas pri ĝi.

Skribu, kion la sekva purge atendu

Notu du faktojn post ĉiu permana forigo: kiu instalilo kreis la aranĝon, kaj kiu posedanto nun startas ĝin. Tiu noto igas la sekvan purge de surprizo en eron de kontrolŝlosilo, kaj ĝi vivas pli longe ol la persono, kiu faris la laboron.

Tenu ĝin apud la serva agordo, ne en persona dosierujo, kaj datu ĝin, ĉar provizanta ĝisdatigo povas restarigi unuon, kiun vi forigis. Kompari systemctl list-unit-files kun tiu noto ĉiun kelkajn monatojn kaptas la restarigon dum ripari ĝin ankoraŭ malmultekostas.