PAM मॉड्यूल अज्ञात है: वास्तव में कौन-सी प्रक्रिया विफल हुई

उस वाक्यांश को पासवर्ड के बारे में नहीं, बल्कि किसी साझा ऑब्जेक्ट और फ़ंक्शन पॉइंटर के बारे में कथन के रूप में पढ़ें। वही शब्द एक OpenVPN प्लगइन से, एक ही सेवा के लिए लोड किए गए PAM स्टैक से, या RADIUS डेमॉन के भीतर से आ सकते हैं, और ये तीन अलग जाँचें हैं। पहले प्रक्रिया तय करें।

नीचे दी गई जाँचें मानती हैं कि संदेश VPN लॉगिन पर Linux-PAM एकीकरण के माध्यम से आया। यदि यह RADIUS सर्वर के अपने कॉन्फ़िगरेशन से आया है, तो उसी डेमॉन के साक्ष्य से शुरू करें।

पैकेज का नाम लेने से पहले प्रक्रिया का नाम लें

तीन घटकों को मॉड्यूल कहा जाता है और उनमें से कोई भी विनिमेय नहीं है। OpenVPN प्रमाणीकरण प्लगइन को VPN डेमॉन लोड करता है और वह उसी डेमॉन का कॉलबैक इंटरफ़ेस लागू करता है। PAM मॉड्यूल एक साझा ऑब्जेक्ट है जिसे libpam किसी नामित सेवा के लिए लोड करता है, और जो इस प्रकार के एंट्री पॉइंट लागू करता है: pam_sm_authenticate। FreeRADIUS मॉड्यूल उसी डेमॉन के अपने कॉन्फ़िगरेशन का एक हिस्सा है। वही शब्दों वाला संदेश तीनों में से किसी से भी आ सकता है, इसलिए पहला प्रश्न यह है कि किस लॉग पंक्ति ने उसे बनाया।

एक विफल प्रयास का टाइमस्टैम्प VPN लॉग और सिस्टम प्रमाणीकरण लॉग के बीच मिलाएँ, फिर सारांश से पहले की पंक्तियाँ पढ़ें। विशिष्ट लोडर संदेश सामान्यतः वहाँ पहले से होता है।

लोडिंग त्रुटि पढ़ें, फिर एंट्री पॉइंट

PAM अज्ञात मॉड्यूल की सूचना तब देता है जब वह चयनित साझा ऑब्जेक्ट लोड नहीं कर सकता, या जब लोड किया गया ऑब्जेक्ट वह फ़ंक्शन प्रदान नहीं करता जिसकी उस स्टैक प्रविष्टि को आवश्यकता है। ये अलग मरम्मतें हैं: पहली पथ, पैकेजिंग या ABI की समस्या है, और दूसरी बेमेल एंट्री पॉइंट है। प्रमाणीकरण पंक्ति को आवश्यकता है pam_sm_authenticate जबकि खाता पंक्ति को आवश्यकता है pam_sm_acct_mgmt, और जो लाइब्रेरी केवल एक को लागू करती है वह दूसरे पर विफल होगी, जैसा कि डिस्पैचर कोड दिखाता है। डिस्क पर फ़ाइल मिलना दोनों में से किसी को सिद्ध नहीं करता।

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

स्टैक जो गारंटियाँ दे रहा था उन्हें बनाए रखें

इस त्रुटि को चुप कराने का सबसे तेज़ तरीका सबसे बुरा भी है: आवश्यक मॉड्यूल को वैकल्पिक चिह्नित करना, खाता चरण हटा देना, या बिना शर्त अनुमति डाल देना। इनमें से प्रत्येक विफल जाँच को अनुपस्थित जाँच में बदल देता है, और फिर लॉगिन ऐसे कारणों से सफल होता है जो किसी ने नहीं चाहे थे। पासवर्ड रीसेट और साझा गोपनीयता में बदलाव भी अनुपस्थित फ़ंक्शन नहीं देते, क्योंकि विफलता किसी भी क्रेडेंशियल के बैकएंड तक पहुँचने से पहले होती है।

बहु-मॉड्यूल स्टैक ने विफल प्रविष्टि से पहले कोई अन्य बैकएंड चलाया हो सकता है, इसलिए यह त्रुटि सिद्ध नहीं करती कि कोई RADIUS अनुरोध नहीं भेजा गया।

मॉड्यूल नहीं, लॉगिन सत्यापित करें

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

मॉड्यूल का स्वच्छ लोड होना प्रगति है, पूर्ण परीक्षण नहीं।

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