OpenVPN चालू हुआ पर कुछ छापा नहीं: पहले log-append जाँचें

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

चुप्पी की दो बहुत अलग व्याख्याएँ हैं

पहली यह है कि प्रक्रिया ठीक चल रही है और ऐसी फ़ाइल में लिख रही है जिसे आप नहीं देख रहे। दूसरी यह है कि वह उसी फ़ाइल में दर्ज त्रुटि के साथ तुरंत बाहर निकल गई।

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

निर्देश खोजें, फिर प्रक्रिया खोजें।

ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf

चल रही प्रक्रिया जो गंतव्य उपयोग करती है उसे खोजें

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

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

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

log बनाम log-append: प्रमाण और मिटाना

log-append फ़ाइल में पहले से जो है उसमें जोड़ता है। log फ़ाइल को लिखने के लिए खोलता है और उसे काट देता है, इसलिए दोनों के बीच बदलना उस रन को मिटा सकता है जिसे आप पढ़ने वाले थे।

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

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

जब सेवा रैपर आउटपुट पकड़ लेता है

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

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

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

विस्तार स्तर तभी बढ़ाएँ जब आप उसे पढ़ सकें

गंतव्य खोजने से पहले विस्तार बढ़ाना केवल उस जगह अधिक पाठ पैदा करता है जहाँ आप देख नहीं रहे।

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

फिर वास्तविक त्रुटि पढ़ें। शांत टर्मिनल इस बात का कुछ साबित नहीं करता कि टनल ऊपर आया या नहीं, और फ़ाइल में दर्ज विफलता ही वह है जिसे ठीक करना उचित है।