apt purge poisti VPN:n, mutta palvelu käynnistyy yhä käynnistyksen yhteydessä

apt purge kertoo, että paketti on poissa, ja silti tunneli nousee yhä joka käynnistyksellä. Journal kasvaa edelleen, reitit palaavat ja kone käyttäytyy kuin mitään ei olisi poistettu. Toimittajan asennusohjelma voi kirjoittaa tiedostoja, joita paketinhallinta ei koskaan kirjannut, joten paketin poistaminen ja tuotteen poistaminen ovat eri töitä. Alla oleva runbook erottaa kaksi kirjausta ja päättää poistamisen tarkoituksella.

Kaksi asentajaa, kaksi eri kirjausta

Debian-paketit pitävät tiedostoluetteloa, ja purge poistaa täsmälleen sen, minkä luettelo nimeää, sekä paketin kokoonpanon. Shell-asentaja tai .run-paketti ei pidä sellaista luetteloa; se kirjoittaa minne haluaa, tavallisesti hakemistoihin /opt, /usr/local ja /etc/systemd/system. Mikään noista poluista ei esiinny minkään paketin tiedostoluettelossa, joten dpkg ei tunne niitä eikä raportoi niitä. Lopputuloksena on kaksi asennuksen omistajaa yhdellä tiedostojärjestelmällä, ja vain yksi heistä pitää kirjaa.

Kysy dpkg:lta tietystä polusta ennen sen poistamista. Polku, jonka se kiistää, on sinun poistettavaksesi, ja sama vastaus kertoo, palauttaisiko myöhempi päivitys sen.

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

Yksikkö ja sen wants-linkki ovat erillisiä tiedostoja

Käyttöönotto on erillinen toimi asentamisesta. Yksikkö ilmoittaa kohdesuhteet [Install]-osiossaan, ja systemctl enable muuttaa nämä ilmoitukset symbolisiksi linkeiksi kunkin kohteen .wants/-hakemistoon. Nyt on kaksi polkua: yksikön tiedosto ja linkki, joka vetää sen käynnistyskohteeseen. Poista vain tiedosto, niin linkki osoittaa tyhjään, mikä aiheuttaa valituksen käynnistyksessä; poista vain linkki, niin yksikkö pysyy käynnistettävänä nimen perusteella. Molempien on lähdettävä.

Poista ne järjestyksessä ja lataa sen jälkeen uudelleen, jotta systemd lakkaa pitämästä vanhoja määritelmiä muistissa.

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

Lue FragmentPath sen sijaan, että olettaisit sijainnin, koska toimittaja on voinut kirjoittaa hakemistoon /usr/lib/systemd/system tai /lib/systemd/system eikä hakemistoon /etc. Odotetun kopion poistaminen jättää tehokkaan kopion käyntiin, ja korjaus näyttää onnistuneelta seuraavaan uudelleenlataukseen asti. Listaa yksiköiden tiedostot uudelleen, kun lataus on valmis, ja varmista, ettei nimi enää esiinny.

Etsi binääri, joka pitää järjestelyn elossa

Käyttöönotettu yksikkö käynnistää daemonin edelleen, mitä pakettitietokanta tahansa uskookin. Tämä prosessi voi tuoda tunnelin takaisin, lisätä reitit uudelleen tai palauttaa kill-switch-säännön, ja käytös näyttää yliluonnolliselta, kunnes tutkit järjestelyn. Seuraa ExecStart-polkua ja tarkista, onko binääri yhä siellä, sillä hakemistoon /opt jätetty suoritettava tiedosto on kaikki, mitä järjestely tarvitsee. Yksikön poistaminen pysäyttää ajastetun käynnistyksen; se ei poista ohjelmaa.

Käsittele tilahakemistoja samalla huolella. Tilien tokenit, luodut profiilit ja välimuistiin tallennetut palvelinluettelot sijaitsevat hakemiston /var/lib alla tai kotihakemistossa, ja ne ovat tunnistetietoja, eivät heitettävää välimuistia. Poista ne, kun palvelu on pysäytetty, tarkoituksella, ja kirjaa, mitä otit.

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

Valitse yksi käynnistyksen omistaja ja testaa sitä

Kolme ehdokasta voi vaatia käynnistyksen, ja kaikkien kolmen asentaminen tuottaa kilpailun eikä kaksinkertaista varmuutta. Työpöydän automaattinen käynnistystiedosto toimii vasta, kun joku kirjautuu sisään, systemd-yksikkö toimii aiemmin mutta tarvitsee asiakkaan, joka toimii ilman näyttöä, ja cron-@reboot-merkintä laukeaa aikataulun mukaan, joka voi olla väärä verkkoyhteydelle. Toimittajan CLI voi lisäksi vaatia palvelinargumentin, koska käynnistyksessä ei ole aiempaa istuntoa jatkettavaksi. Valitse ehdokas, joka vastaa sitä, miten asiakas todennetaan, ja hylkää muut.

Testaa se käynnistämällä kone uudelleen ja katsomalla kolmea riippumatonta tosiasiaa: yksikön tila, prosessiluettelo ja uusi yhteys johonkin, jonka voit vahvistaa. Asiakas, joka tarvitsee avainrenkaan tai vuorovaikutteisen kirjautumisen, epäonnistuu käynnistyksessä jopa oikealla yksikkötiedostolla, ja journal kertoo sen, jos luet sitä etkä vain palvelun tilaa.

Joko anna asiakkaalle tunnistetieto, joka toimii ilman kyselyä, tai käynnistä se kirjautumisen yhteydessä. Molemmat ovat perusteltuja, ja niiden yhdistäminen on tapa, jolla yksi tunneli saa kaksi omistajaa, jotka riitelevät siitä.

Kirjoita muistiin, mitä seuraavan purgen pitäisi odottaa

Kirjaa kaksi tosiasiaa jokaisen manuaalisen poistamisen jälkeen: mikä asentaja loi järjestelyn ja mikä omistaja käynnistää sen nyt. Tämä muistiinpano muuttaa seuraavan purgen yllätyksestä tarkistuslistan kohdaksi, ja se elää kauemmin kuin työn tehnyt henkilö.

Säilytä sitä palvelun kokoonpanon vieressä äläkä henkilökohtaisessa hakemistossa, ja päivää se, koska toimittajan päivitys voi palauttaa poistamasi yksikön. systemctl list-unit-files-luettelon vertaaminen tähän muistiinpanoon muutaman kuukauden välein nappaa palautuksen kiinni, kun korjaus on vielä halpaa.