Mankas la binaraĵo pppd: ripari la rulmedian, ne la aŭtentikigon

Nenio atingis la enirejon, ĉar la kliento ne povis trovi binaraĵon, kiun ĝi unue bezonas. La mesaĝo nomas helpanton de la rulmedio, kaj la natura reago estas supozi, ke la alia flanko rifuzis ion. Ĝi ne rifuzis. PPP-bazita integriĝo bezonas tiun helpanton sur la loka maŝino, kaj ĝi mankas, estas nelegebla aŭ ne troviĝas tie, kie la alvokanto rigardas.

La menuo kaj la demono estas malsamaj aferoj

Fenestra redaktilo povas konservi profilon dum la helpanto, kiu starigus ĝin, mankas, ĉar konservado validigas kampojn, ne kapablojn. La du komponantoj venas en malsamaj pakaĵoj kaj malsukcesas en malsamaj momentoj. Profilo konserviĝanta pure kaj konekto malsukcesanta tuj estas tute kongruaj.

La kontraŭa eraro same oftas: plenumebla dosiero ie sur la disko ne pruvas, ke la elektita integriĝo trovas la subtenatan kopion. Kopio en hejma dosierujo povas kontentigi ŝelon kaj tamen resti nevidebla al la servo.

Legu la pakaĵon, ne la dosieron

Kontrolu la staton de la instalita pakaĵo, ĝiajn deklaritajn dependecojn kaj la atendatan dosierliston antaŭ ol tuŝi ion. La pakaĵado de distribuaĵoj dokumentas tion eksplicite, kaj la pakaĵo NetworkManager PPTP de Debian estas utila ekzemplo, ĉar ĝi dependas aparte de la PPP-demona pakaĵo kaj de la PPTP-kliento. Tio estas hereda integriĝo, ne rekomendo uzi PPTP hodiaŭ. Ĝi montras, kiel helpanto venas kiel propra dependeco, ne ene de la kliento.

Tenu aparte tri fiaskmanierojn: pakaĵo, kiu ne instaliĝis, konservejo, kiu proponas neniun kandidaton, kaj binaraĵo instalita permane ekster la posedo de la pakaĵo. Ili bezonas malsamajn riparojn, kaj nur la unua solviĝas per reinstalo de la sama pakaĵo.

Ŝela kontrolo de la plenumebla dosiero priskribas nur la serĉvojon de tiu ŝelo kaj nenion pli. La helpanto de la administrilo povas ruliĝi kun alia vojo, en alia medio aŭ kun eksplicite agordita loko de la plenumebla dosiero.

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

Riparu la rulmedian sen rompi aliajn

Kiam la rulmedio estas pruveble nekompleta, uzu la reviziitan pakaĵtransakcion de la distribuaĵo kaj unue legu, kion ĝi ŝanĝos. PPP estas dividata de pluraj alirretontegraĵoj, do forigo aŭ reinstalo povas forpreni funkciantajn uzantojn. Elpurigi ĉiun rilatan pakaĵon por ripari unu rompitan estas la maniero, kiel tekkomputilo perdas du funkciantajn konektojn.

Ankaŭ instalo de alia VPN-kliento ne estas riparo. Ĝi kreas novan postulon pri kongruo dum lasas la originan profilon neklarigita.

Se la organizo decidis, ke la protokolo mem devas foriri, tio estas migrada decido kun posedanto. Tio ne estas paŝo de problemtrovo, kaj ĝi ne faruĝu en la momento, kiam konekto malsukcesas.

Traktu la sekvan eraron kiel novan etapon

Post kiam la helpanto ekfunkcias, atendu, ke la sekva fiasko estos malsama. PPP-ligintertrakto, uzantaŭtentikigo, adresdisdono, vojoj kaj nomrezolucio povas ĉiu malsukcesi sendepende, kaj ĉiu havas siajn proprajn pruvojn.

Ne respondu al posta rifuzo per malfaro de la dependeca riparo aŭ per ŝalto de ĉiuj malnovaj aŭtentikigaj kaj kunpremaj opcioj en la profilo. Tio turnas unu diagnozeblan problemon en plurajn interagantajn. Ŝanĝu unu agordon samtempe kaj notu, kion ĝi ŝanĝis.

Notu la pakaĵversiojn kaj la precizan mesaĝon, kiun vi vidis. Raporto, kiu nomas la mankantan binaraĵon kaj la pakaĵon, kiu devus provizi ĝin, estas agebla tiel, kiel ĝenerala plendo pri la VPN ne estas.