Forigo de la VPN-pakaĵo malsukcesis en prerm: kion kontroli unue
Malsukcesa prerm-skripto haltigas malinstalon antaŭ ol la dosieroj malaperos. Legu la staton de la pakaĵo kaj la ĝustan etapon, poste uzu la subtenatan riparvojon.
Malinstaloj povas halti duonvoje kun eraro, kiu nomas prizorgan skripton, lasante la VPN-on duone forigita: agordaj dosieroj restas, la servo eble ankoraŭ funkcias, kaj la pakaĵmastrumilo rifuzas daŭrigi. La alloga solvo en malnova forumfadeno estas forigi la skripton kaj devigi la forigon. Tio traktas la simptomon kaj forĵetas la purigan paŝon, kiu malsukcesis. Legu unue la etapon kaj la staton de la pakaĵo.
Kiun paŝon de la vivociklo fakte malsukcesis
Debian-pakaĵoj rulas preinst kaj postinst ĉe instalado, kaj prerm kaj postrm ĉe forigo aŭ plena purigado, kaj la elirstato de ĉiu skripto direktas la sekvan agon. Eraro de prerm signifas, ke la forigo haltis antaŭ ol la dosieroj de la pakaĵo estis forigitaj; eraro de postrm signifas, ke la forigo jam okazis kaj la purigado malsukcesis. Tiuj estas malsamaj situacioj kun malsama riparo. La politiko de la distribuo ankaŭ atendas, ke skriptoj toleru ripetan ruladon, ĉar malsukcesa etapo devas esti ripetita, ne evitita.
Notu la unuan eraron laŭvorte, kune kun la nomo, versio kaj eldono de la distribuo de la pakaĵo. Postaj eraroj kutime estas sekvoj.
Legu la staton de la pakaĵo antaŭ ol ŝanĝi ĝin
Demandu la pakaĵmastrumilon, kion ĝi opinias okazinta, antaŭ ol eldoni alian komandon.
dpkg -l vpn-package
dpkg --audit
apt-get -s remove vpn-packageLa listo montras la statajn flagojn de la pakaĵo, la revizio trovas pakaĵojn lasitajn rompitaj aŭ duone agorditaj, kaj la simulita forigo presas, kion apt farus sen tuŝi ion. Simulado, kiu malsukcesas ĉe la sama skripto, konfirmas la etapon, ne la reton. Notu la skripton nomitan en la eraro kaj listigu la informajn dosierojn de la pakaĵo, se vi bezonas vidi, kiuj skriptoj ekzistas. Nenio el tio ankoraŭ pravigas redakti tiujn dosierojn.
Protektu la administran vojon antaŭ la riparo
Se la VPN portas vian solan SSH-sesion al tiu ĉi gastiganto, forigi ĝin finas vian aliron meze de la riparo. Unue aranĝu konzolon, ekstran administran interfacon aŭ duan vojon, kaj konfirmu, ke ĝi funkcias antaŭ ol komenci. Konservu la profilon kaj ajnajn reinstalajn instrukciojn, kiujn vi bezonos poste, ĉar plena purigado povas forigi generitan agordon. Tenu identigilojn ekster la notoj, kiujn vi algluas en bileton, kaj tenu privatajn ŝlosilojn tute ekster la diagnozo.
Traktu dokumentitan manan superpriskribon kiel lastan rimedon sub gvidado de la pakaĵposedanto, kun la preterlasitaj paŝoj kompensitaj. Neniam forigu skriptojn per ĵokero, ĉar la propra puriglisto de la pakaĵo estas la registro de tio, kio ankoraŭ restas farenda.
Apartigu rezultojn de pakaĵo, reto kaj identigiloj
Tri rezultojn oni devas sendepende kontroli, kiam la subtenata proceduro finiĝas. La pakaĵa transakcio devus montri puran staton, sen duone agorditaj enskriboj restantaj en la revizio. La reto devus kongrui kun tio, kion vi intencis: la ĝusta servo haltigita, neniuj kadukaj vojoj aŭ DNS-agordoj, kaj funkcianta vojo por anstataŭigo aŭ rekta aliro. La fora flanko estas la tria rezulto, kaj kadukaj identigiloj devus esti retiritaj per la posedanto de tiu konto, ĉar malinstali klienton revokas nenion.
Poste rekonektiĝu kaj testu unu permesitan celon. Pura pakaĵstato kun ankoraŭ funkcianta tunelo estas malsama rezulto ol pura reto, kaj nur la dua diras al vi, ke la forigo fakte efektiviĝis.