Fant ikke pppd-binæren: reparer kjøretidsmiljøet, ikke påloggingen

Ingenting nådde gatewayen, fordi klienten ikke fant en binær den trenger først. Meldingen nevner en hjelper i kjøretidsmiljøet, og den naturlige responsen er å anta at den andre enden avviste noe. Det gjorde den ikke. En PPP-basert integrasjon trenger den hjelperen på den lokale maskinen, og den mangler, er uleselig eller ligger ikke der den som kaller ser.

Menyen og daemonen er forskjellige ting

En skrivebordseditor kan lagre en profil mens hjelperen som skulle opprette den mangler, fordi lagring validerer felt, ikke evner. De to komponentene leveres i forskjellige pakker og feiler på forskjellige tidspunkter. En profil som lagres rent, og en tilkobling som feiler umiddelbart, er helt konsistente.

Den motsatte feilen er like vanlig: en kjørbar fil et sted på disken beviser ikke at den valgte integrasjonen finner den støttede kopien. En kopi i hjemmekatalogen kan tilfredsstille et skall og likevel være usynlig for tjenesten.

Les pakken, ikke filen

Undersøk tilstanden til den installerte pakken, de deklarerte avhengighetene og den forventede fillisten før du rører noe. Distribusjonenes pakking dokumenterer dette uttrykkelig, og Debians NetworkManager PPTP-pakke er et nyttig eksempel, fordi den avhenger av PPP-daemonpakken og av PPTP-klienten hver for seg. Det er en eldre integrasjon, ikke en anbefaling om å rulle ut PPTP i dag. Den viser hvordan en hjelper kommer som sin egen avhengighet og ikke inne i klienten.

Hold tre feilmoduser fra hverandre: en pakke som ikke ble installert, et arkiv som ikke tilbyr noen kandidat, og en binær som er installert manuelt utenfor pakkens eierskap. De trenger forskjellige reparasjoner, og bare den første løses ved å installere den samme pakken på nytt.

En skallkontroll av den kjørbare filen beskriver bare søkestien til det skallet og ingenting mer. Behandlerens hjelper kan kjøre med en annen sti, i et annet miljø eller med en eksplisitt konfigurert plassering av den kjørbare filen.

dpkg -s network-manager-pptp | grep -E "Status|Depends"
dpkg -L ppp | grep -E "bin/pppd$"
command -v pppd; ls -l /usr/sbin/pppd

Reparer kjøretidsmiljøet uten å ødelegge andre

Når kjøretidsmiljøet er påviselig ufullstendig, bruk distribusjonens gjennomgåtte pakketransaksjon og les først hva den vil endre. PPP deles av flere tilgangsnettverksintegrasjoner, så fjerning eller reinstallasjon kan ta med seg fungerende brukere. Å rydde alle relaterte pakker for å reparere én ødelagt er måten en bærbar PC mister to fungerende tilkoblinger.

Å installere en annen VPN-klient er heller ikke en reparasjon. Det skaper et nytt kompatibilitetskrav mens den opprinnelige profilen blir stående uforklart.

Hvis organisasjonen har bestemt at selve protokollen skal bort, er det en migreringsbeslutning med en eier. Det er ikke et feilsøkingstrinn, og det bør ikke tas i det øyeblikket en tilkobling feiler.

Behandle den neste feilen som en ny fase

Når hjelperen starter, forvent at den neste feilen er annerledes. PPP-linkforhandling, brukerautentisering, adressetildeling, ruter og navneoppslag kan hver for seg feile uavhengig, og hver har sine egne bevis.

Ikke svar på en senere avvisning ved å angre avhengighetsreparasjonen eller ved å slå på alle gamle autentiserings- og komprimeringsvalg i profilen. Det gjør ett diagnostiserbart problem til flere som virker inn på hverandre. Endre én innstilling om gangen og noter hva den endret.

Noter pakkeversjonene og den nøyaktige meldingen du så. En rapport som navngir den manglende binæren og pakken som skulle levert den, er handlingsrettet på en måte en generell klage på VPN ikke er.