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 बद्दलच्या सामान्य तक्रारीत नसलेल्या पद्धतीने कृतीयोग्य आहे।