Verwijderen van VPN-pakket mislukt in prerm: wat je eerst moet controleren

De-installaties kunnen halverwege stoppen met een fout die een onderhoudsscript noemt, waardoor de VPN half verwijderd achterblijft: configuratiebestanden blijven staan, de service draait mogelijk nog, en de pakketbeheerder weigert door te gaan. De verleidelijke oplossing in een oude forumthread is het script verwijderen en de verwijdering forceren. Dat behandelt het symptoom en gooit de opschoningsstap weg die mislukte. Lees eerst de fase en de pakketstatus.

Welke levenscyclusstap werkelijk is mislukt

Debian-pakketten voeren preinst en postinst uit bij installatie, en prerm en postrm bij verwijdering of volledige opschoning, waarbij de exitstatus van elk script de volgende actie bepaalt. Een fout van prerm betekent dat de verwijdering stopte voordat de bestanden van het pakket werden verwijderd; een fout van postrm betekent dat de verwijdering al had plaatsgevonden en dat het opschonen mislukte. Dat zijn verschillende situaties met een verschillend herstel. Het distributiebeleid verwacht ook dat scripts een herhaalde uitvoering verdragen, omdat een mislukte fase opnieuw moet worden uitgevoerd in plaats van vermeden.

Noteer de eerste fout letterlijk, samen met de pakketnaam, versie en distributierelease. Latere fouten zijn meestal gevolgen.

Lees de pakketstatus voordat je die wijzigt

Vraag de pakketbeheerder wat er volgens hem is gebeurd voordat je een ander commando geeft.

dpkg -l vpn-package
dpkg --audit
apt-get -s remove vpn-package

De lijst toont de statusvlaggen van het pakket, de audit vindt pakketten die kapot of half geconfigureerd zijn achtergelaten, en de gesimuleerde verwijdering print wat apt zou doen zonder iets aan te raken. Een simulatie die bij hetzelfde script mislukt, bevestigt de fase in plaats van het netwerk. Let op het script dat in de fout wordt genoemd en toon de informatiefbestanden van het pakket als je wilt zien welke scripts bestaan. Niets daarvan rechtvaardigt het nog om die bestanden te bewerken.

Bescherm het beheerpad voor de reparatie

Als de VPN je enige SSH-sessie naar deze host draagt, beëindigt het verwijderen ervan je toegang midden in de reparatie. Regel eerst een console, een out-of-band beheerinterface of een tweede route, en bevestig dat die werkt voordat je begint. Bewaar het profiel en eventuele heraanmeldingsinstructies die je later nodig hebt, omdat een volledige opschoning gegenereerde configuratie kan verwijderen. Houd inloggegevens buiten de notities die je in een ticket plakt, en houd privésleutels volledig buiten de diagnostiek.

Behandel een gedocumenteerde handmatige override als laatste redmiddel onder begeleiding van de pakketeigenaar, met de overgeslagen stappen verantwoord. Verwijder nooit scripts met jokertekens, omdat de eigen opschoningslijst van het pakket het overzicht is van wat er nog moet gebeuren.

Scheid de uitkomsten voor pakket, netwerk en inloggegevens

Drie uitkomsten moeten onafhankelijk worden gecontroleerd wanneer de ondersteunde procedure eindigt. De pakkettransactie hoort een schone status te tonen, zonder half geconfigureerde vermeldingen in de audit. Het netwerk hoort te kloppen met wat je bedoelde: de juiste service gestopt, geen verouderde routes of DNS-instellingen, en een werkend pad voor vervanging of directe toegang. De externe kant is de derde uitkomst, en verouderde inloggegevens horen via de eigenaar van dat account te worden ingetrokken, omdat het de-installeren van een client niets herroept.

Maak daarna opnieuw verbinding en test één toegestane bestemming. Een schone pakketstatus met een tunnel die nog draait is een andere uitkomst dan een schoon netwerk, en alleen het tweede vertelt je dat de verwijdering echt effect had.