Kunne ikke finde pppd-binæren: ret kørselsmiljøet, ikke godkendelsen

Intet nåede gatewayen, fordi klienten ikke kunne finde en binær, den har brug for først. Beskeden nævner en hjælper i kørselsmiljøet, og den naturlige reaktion er at antage, at den anden ende afviste noget. Det gjorde den ikke. En PPP-baseret integration har brug for den hjælper på den lokale maskine, og den mangler, er ulæselig eller ligger ikke, hvor kalderen kigger.

Menuen og dæmonen er forskellige ting

En skrivebordseditor kan gemme en profil, mens den hjælper, der skulle etablere den, mangler, fordi lagring validerer felter, ikke evner. De to komponenter leveres i forskellige pakker og fejler på forskellige tidspunkter. En profil, der gemmes rent, og en forbindelse, der fejler med det samme, er fuldstændig forenelige.

Den omvendte fejl er lige så almindelig: en eksekverbar fil et sted på disken beviser ikke, at den valgte integration finder den understøttede kopi. En kopi i en hjemmemappe kan tilfredsstille et shell og stadig være usynlig for tjenesten.

Læs pakken, ikke filen

Undersøg den installerede pakkes tilstand, dens deklarerede afhængigheder og dens forventede filliste, før du rører noget. Distributionernes pakning dokumenterer dette udtrykkeligt, og Debians NetworkManager PPTP-pakke er et nyttigt eksempel, fordi den afhænger af PPP-dæmonpakken og af PPTP-klienten hver for sig. Det er en ældre integration og ikke en anbefaling om at udrulle PPTP i dag. Den viser, hvordan en hjælper kommer som sin egen afhængighed og ikke inde i klienten.

Hold tre fejltilstande adskilt: en pakke, der ikke blev installeret, et arkiv, der ikke tilbyder nogen kandidat, og en binær, der er installeret manuelt uden for pakkens ejerskab. De kræver forskellige reparationer, og kun den første løses ved at geninstallere den samme pakke.

Et shell-tjek af den eksekverbar fil beskriver netop det shells søgesti og intet andet. Administratorhjælperen kan køre med en anden sti, i et andet miljø eller med en eksplicit konfigureret placering af den eksekverbar fil.

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

Ret kørselsmiljøet uden at ødelægge andres

Når kørselsmiljøet beviseligt er ufuldstændigt, brug distributionens gennemgåede pakketransaktion, og læs først, hvad den vil ændre. PPP deles af flere adgangsnetværksintegrationer, så fjernelse eller geninstallation kan tage fungerende forbrugere med sig. At rydde alle relaterede pakker for at rette én ødelagt er måden, hvorpå en bærbar computer mister to fungerende forbindelser.

Det er heller ikke en reparation at installere en anden VPN-klient. Det skaber et nyt kompatibilitetskrav, mens den oprindelige profil efterlades uforklaret.

Hvis organisationen har besluttet, at selve protokollen skal væk, er det en migreringsbeslutning med en ejer. Det er ikke et fejlfindingsskridt, og det bør ikke træffes i det øjeblik, en forbindelse fejler.

Behandl den næste fejl som en ny fase

Når hjælperen starter, forvent da, at den næste fejl er anderledes. PPP-linkforhandling, brugergodkendelse, adressetildeling, ruter og navneopløsning kan hver især fejle uafhængigt, og hver har sine egne beviser.

Svar ikke på en senere afvisning ved at fortryde afhængighedsreparationen eller ved at slå alle gamle godkendelses- og komprimeringsindstillinger til i profilen. Det gør ét diagnosticerbart problem til flere indbyrdes påvirkende. Skift én indstilling ad gangen, og noter, hvad den ændrede.

Notér pakkeversionerne og den præcise besked, du så. En rapport, der navngiver den manglende binære fil og den pakke, der burde levere den, er handlingsanvisende på en måde, som en generel klage over VPN ikke er.