pppd बाइनरी नहीं मिली: रनटाइम ठीक करें, प्रमाणीकरण नहीं

गेटवे तक कुछ नहीं पहुँचा, क्योंकि क्लाइंट को पहले जरूरी बाइनरी नहीं मिली। संदेश रनटाइम सहायक का नाम लेता है, और स्वाभाविक प्रतिक्रिया यह मानना है कि दूसरे सिरे ने कुछ अस्वीकार किया। उसने अस्वीकार नहीं किया। PPP आधारित एकीकरण को स्थानीय मशीन पर वह सहायक चाहिए, और वह अनुपस्थित है, अपठनीय है या कॉलर जहाँ देखता है वहाँ नहीं है।

मेन्यू और डेमॉन अलग चीजें हैं

डेस्कटॉप संपादक प्रोफ़ाइल सहेज सकता है जबकि उसे स्थापित करने वाला सहायक अनुपस्थित हो, क्योंकि सहेजना फ़ील्ड की जाँच करता है, क्षमताओं की नहीं। दोनों घटक अलग पैकेजों में आते हैं और अलग क्षणों में विफल होते हैं। साफ़ सहेजी गई प्रोफ़ाइल और तुरंत विफल होने वाला कनेक्शन पूरी तरह सुसंगत हैं।

उलटी गलती भी उतनी ही आम है: डिस्क पर कहीं पड़ी कोई निष्पादन-योग्य फ़ाइल यह साबित नहीं करती कि चुना गया एकीकरण समर्थित प्रति ढूँढ लेता है। होम डिरेक्टरी में पड़ी प्रति शेल को संतुष्ट कर सकती है और फिर भी सेवा के लिए अदृश्य रह सकती है।

फ़ाइल नहीं, पैकेज पढ़ें

कुछ भी छूने से पहले स्थापित पैकेज की स्थिति, उसकी घोषित निर्भरताएँ और अपेक्षित फ़ाइल सूची जाँचें। डिस्ट्रिब्यूशन पैकेजिंग इसे स्पष्ट रूप से दर्ज करती है, और Debian का NetworkManager PPTP पैकेज उपयोगी उदाहरण है, क्योंकि वह PPP डेमॉन पैकेज और PPTP क्लाइंट पर अलग-अलग निर्भर है। यह आज PPTP तैनात करने की सिफ़ारिश नहीं, बल्कि पुराना एकीकरण है। यह दिखाता है कि सहायक क्लाइंट के भीतर नहीं, अपनी निर्भरता के रूप में कैसे आता है।

विफलता के तीन ढंग अलग रखें: वह पैकेज जो स्थापित नहीं हुआ, वह रिपॉज़िटरी जो कोई उम्मीदवार नहीं देती, और वह बाइनरी जो पैकेज के स्वामित्व से बाहर हाथ से स्थापित हुई। इन्हें अलग मरम्मत चाहिए, और केवल पहला ही वही पैकेज फिर से स्थापित करके ठीक होता है।

किसी शेल में निष्पादन-योग्य की जाँच केवल उस शेल का खोज-पथ बताती है, और कुछ नहीं। प्रबंधक का सहायक अलग पथ, अलग वातावरण या स्पष्ट रूप से कॉन्फ़िगर किए गए निष्पादन-योग्य स्थान के साथ चल सकता है।

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

दूसरों को तोड़े बिना रनटाइम ठीक करें

जब रनटाइम स्पष्ट रूप से अपूर्ण हो, तो डिस्ट्रिब्यूशन का समीक्षित पैकेज लेनदेन इस्तेमाल करें और पहले पढ़ें कि वह क्या बदलेगा। PPP को कई एक्सेस-नेटवर्क एकीकरण साझा करते हैं, इसलिए उसे हटाना या फिर से स्थापित करना काम कर रहे उपभोक्ताओं को साथ ले जा सकता है। एक टूटे पैकेज को ठीक करने के लिए हर संबंधित पैकेज साफ़ करना वही तरीका है जिससे लैपटॉप दो काम करते कनेक्शन खो देता है।

दूसरा VPN क्लाइंट स्थापित करना भी मरम्मत नहीं है। यह नई अनुकूलता की माँग बनाता है जबकि मूल प्रोफ़ाइल को बिना व्याख्या छोड़ देता है।

अगर संगठन ने तय किया है कि प्रोटोकॉल को ही जाना चाहिए, तो यह मालिक वाला माइग्रेशन निर्णय है। यह समस्या-निवारण का चरण नहीं है, और कनेक्शन विफल होने के क्षण में यह नहीं लिया जाना चाहिए।

अगली त्रुटि को नया चरण मानें

सहायक के शुरू होने के बाद अपेक्षा रखें कि अगली विफलता अलग होगी। PPP लिंक बातचीत, उपयोगकर्ता प्रमाणीकरण, पता आवंटन, रूट और नाम-समाधान में से हर एक स्वतंत्र रूप से विफल हो सकता है, और हर एक के अपने साक्ष्य हैं।

बाद के अस्वीकरण का जवाब निर्भरता-मरम्मत पलट कर या प्रोफ़ाइल में सभी पुराने प्रमाणीकरण और संपीड़न विकल्प चालू करके न दें। इससे एक निदान-योग्य समस्या कई परस्पर-क्रियाशील समस्याओं में बदल जाती है। एक बार में एक सेटिंग बदलें और लिखें कि उसने क्या बदला।

पैकेज संस्करण और जो सटीक संदेश आपने देखा, दर्ज करें। जो रिपोर्ट अनुपस्थित बाइनरी और उसे देने वाले पैकेज का नाम लेती है, वह उस तरह कार्रवाई-योग्य है जिस तरह VPN के बारे में सामान्य शिकायत नहीं।