apt purge-k VPNa kendu zuen, baina zerbitzua oraindik abiarazten da hasieran

apt purge-k dio paketea desagertu dela, eta hala ere tunel bat agertzen da abio bakoitzean. Journal-a hazten jarraitzen du, ibilbideak itzultzen dira, eta makinak jokatzen du ezer kendu ez balitz bezala. Hornitzailearen instalatzaileak pakete-kudeatzaileak inoiz erregistratu ez zituen fitxategiak idatz ditzake, beraz pakete bat desinstalatzea eta produktu bat desinstalatzea lan desberdinak dira. Hurrengo runbook-ak bi erregistroak bereizten ditu eta kentzea nahita amaitzen du.

Bi instalatzaile, bi erregistro desberdin

Debian paketeek fitxategi-zerrenda bat gordetzen dute, eta purge-k zerrenda horrek izendatzen duena ezabatzen du zehazki, paketearen konfigurazioaz gain. Shell instalatzaile batek edo .run pakete batek ez du halako zerrendarik gordetzen; nahi duen tokian idazten du, normalean /opt, /usr/local eta /etc/systemd/system karpetetan. Bide horietako bat bera ere ez da agertzen inongo paketeren fitxategi-zerrendan, beraz dpkg-k ez daki haietaz ezta haiek salatzen. Azkenean bi instalazio-jabe dituzu fitxategi-sistema bakarrean, eta horietako batek soilik eramaten ditu kontuak.

Galdetu dpkg-ri bide zehatzari buruz ezabatu aurretik. Ukatzen duen bide bat zurea da kentzeko, eta erantzun berak esaten dizu geroagoko eguneratze batek itzuliko lukeen.

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

Unit bat eta bere wants esteka fitxategi bereiziak dira

Gaitzea instalatzearen ekintza bereizia da. Unit-ak helburu-erlazioak adierazten ditu bere [Install] atalean, eta systemctl enable-k adierazpen horiek esteka sinboliko bihurtzen ditu helburu bakoitzaren .wants/ karpetan. Orain bi bide daude: unit-aren fitxategia eta abio-helburu batera tiratzen duen esteka. Fitxategia soilik ezabatuz gero esteka ezer ez duen tokira seinalatzen du, eta horrek kexa sortzen du abioan; esteka soilik ezabatuz gero unit-a izenez abiarazteko modukoa izaten jarraitzen du. Biak joan behar dute.

Kendu itzazu ordenan eta berriz kargatu gero, systemd-k definizio zaharrak memorian ez ditzan gehiago eduki.

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

Irakurri FragmentPath kokapena suposatu beharrean, hornitzaileak /usr/lib/systemd/system edo /lib/systemd/system karpetetan idatzi baitu /etc karpetan beharrean. Espero zenuen kopia ezabatzeak eraginkorra dena martxan uzten du, eta konponketak arrakastatsua dirudi hurrengo berriz kargatzera arte. Zerrendatu berriro unit-en fitxategiak berriz kargatzea amaitzean, eta egiaztatu izena ez dela gehiago agertzen.

Aurkitu antolamendua bizirik mantentzen duen binarioa

Gaitutako unit batek deabrua abiarazten jarraitzen du, pakete-datubaseak zer pentsatzen duen edozein dela ere. Prozesu horrek tunela berriro altxatu, ibilbideak berriro gehitu edo kill-switch arau bat berrezarri dezake, eta portaera naturaz gaindikoa dirudi antolamendua aztertu arte. Jarraitu ExecStart bidea eta egiaztatu binarioa oraindik han ote dagoen, /opt azpian utzitako exekutagarri bat baita antolamenduak behar duen guztia. Unit-a ezabatzeak programatutako abioa gelditzen du; ez du programa ezabatzen.

Tratatu egoera-karpetak arreta berarekin. Kontu-tokenak, sortutako profilak eta cachean gordetako zerbitzari-zerrendak /var/lib azpian edo etxe-karpeta batean bizi dira, eta horiek kredentzialak dira, ez botatzeko cachea. Kendu itzazu zerbitzua geldituta dagoenean, nahita, eta idatzi zer eraman duzun.

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

Aukeratu abioaren jabe bakarra eta probatu

Hiru hautagai lehia daitezke abioaz, eta hirurak instalatzeak lasterketa sortzen du, ez babes bikoitza. Mahaigaineko abio automatiko fitxategi bat norbaitek saioa hasi ondoren soilik exekutatzen da, systemd unit bat lehenago exekutatzen da baina pantailarik gabe lan egiten duen bezero bat behar du, eta cron @reboot sarrera bat sareko bezeroarentzat okerra izan daitekeen ordutegi baten arabera pizten da. Hornitzailearen CLI-k zerbitzari argumentu bat ere eska dezake, abioan ez dagoelako jarraitzeko aurreko saiorik. Aukeratu bezeroak nola autentifikatzen duen bat datorren hautagaia, eta baztertu besteak.

Probatu makina berrabiaraziz eta hiru gertaera independenteri begiratuz: unit-aren egoera, prozesuen zerrenda eta egiaztatu dezakezun zerbaitekin konexio berri bat. Gako-sorta edo saio-hasiera interaktiboa behar dituen bezero batek huts egiten du abioan, unit fitxategia zuzena izan arren, eta journal-ak hori dio, zerbitzuaren egoera soilik ez baina journal-a irakurtzen baduzu.

Edo eman bezeroari galderarik gabe lan egiten duen kredentzial bat, edo abiarazi saio-hasieran. Biak dira defendagarriak, eta biak konbinatzea da tunel batek beraren alde borrokatzen duten bi jabe nola lortzen dituen.

Idatzi hurrengo purge-k zer espero behar duen

Idatzi bi gertaera eskuzko kentze baten ondoren: zein instalatzailek sortu zuen antolamendua eta zein jabek abiarazten duen orain. Ohar horrek hurrengo purge-a ezustekotik kontrol-zerrendako puntu bihurtzen du, eta lana egin zuen pertsonak baino gehiago irauten du.

Gorde zerbitzuaren konfigurazioaren ondoan eta ez karpeta pertsonal batean, eta jarri data, hornitzailearen eguneratze batek ezabatu duzun unit bat berreskura baitezake. systemctl list-unit-files ohar horrekin pare bat hilabetez behin alderatzeak berreskurapena harrapatzen du konponketa oraindik merkea den bitartean.