OpenVPN हुक आपल्या स्क्रिप्टजवळील फाइल का शोधू शकत नाही

त्रुटीशिवाय चालतात आणि तरीही हरवलेल्या फाइलची तक्रार करतात असे हुक सहसा चुकीच्या ठिकाणी पाहत असतात, आपल्या कामात अपयशी होत नाहीत। स्क्रिप्टमधील सापेक्ष मार्ग प्रक्रियेच्या कार्यरत निर्देशिकेच्या संदर्भात सोडवले जातात, आणि सेवा तुम्ही न निवडलेल्या कार्यरत निर्देशिकेसह सुरू होते। स्क्रिप्टजवळील फाइल आणि प्रक्रिया उघडते ती फाइल एकच गोष्ट तेव्हाच असते जेव्हा काही त्यांना अँकर करते। हेच अंतर परवानगीची समस्या म्हणून चुकीचे वाचले जाणाऱ्या हुक अपयशांचा मोठा भाग स्पष्ट करते।

परवानग्यांपूर्वी मार्ग तपासा, कारण चुकीच्या फाइलवरील परवानगीची त्रुटी तरीही चुकीची फाइलच असते।

सापेक्ष मार्ग फाइलीऐवजी प्रक्रियेच्या संदर्भात सोडवला जातो

जेव्हा स्क्रिप्ट open("policy.json") ला कॉल करते, तेव्हा कर्नेल ते नाव प्रक्रियेच्या सध्याच्या कार्यरत निर्देशिकेच्या संदर्भात सोडवते। स्क्रिप्टच्या स्वतःच्या स्थानातील काहीही त्या शोधात सहभागी होत नाही। OpenVPN आपण निवडलेल्या निर्देशिकेतून हुक सुरू करते, आणि cd पर्याय ती बदलू शकतो, त्यामुळे स्वतःच्या फोल्डरमधून हाताने तपासलेली स्क्रिप्ट डीमन ती चालवतो तेव्हा वेगळी वागते। हातची चाचणी उत्तीर्ण होते, सेवा चालवणे अपयशी ठरते, आणि लॉगची ओळ फक्त हरवलेल्या नावाचा उल्लेख करते।

Python स्क्रिप्टचे स्थान __file__ म्हणून उघड करते, आणि त्यामुळेच अँकरिंग शक्य होते। Path(__file__).resolve().parent / "policy.json" प्रक्रियेऐवजी फाइलमधून मार्ग तयार करते। ती एक ओळ विशेषाधिकारांमध्ये काहीही न बदलता कार्यरत निर्देशिकेचे अवलंबित्व काढून टाकते।

मार्ग हेतुपूर्वक अँकर करा, नंतर resolve काय करते ते तपासा

resolve() प्रतीकात्मक दुव्यांचा मागोवा घेते, त्यामुळे हुक त्याच्या जागी जोडणारी स्थापना दुव्याच्या लक्ष्यावर अँकर होते, दुवा धारण करणाऱ्या निर्देशिकेवर नाही। आवृत्तीबद्ध तैनातीसाठी सहसा हेच हवे असते, आणि प्रतीकात्मक दुव्याच्या शेजारी डेटा अपेक्षिणाऱ्या मांडणीसाठी हे चुकीचे आहे। तैनातीचा अर्थ काय आहे ते ठरवा, आणि उत्पादनात फरक शोधण्याऐवजी त्यानुसार कोड लिहा। Path(__file__).parent शिवाय resolve() दुव्याची स्वतःची निर्देशिका ठेवते।

जर डेटा प्रोग्रामचा नाही तर इन्स्टन्सचा असेल, तर संरचनेतून निरपेक्ष मार्ग घ्या। स्थान हार्डकोड करणे हुकला एकाच होस्ट मांडणीशी बांधते।

चार सीमा क्रमाने पार करा

कार्यरत निर्देशिकेपासून सुरुवात करा: युनिटची WorkingDirectory, OpenVPNचा cd पर्याय आणि exec पूर्वी निर्देशिका बदलणारे कोणतेही आवरण यांची तुलना करा। नंतर सोडवलेले स्थान पुष्टी करा, कारण दुसऱ्या तैनातीतील समान नावाची फाइल शोधाला उत्तर देऊन त्रुटी लपवू शकते। पुढे फाइलसिस्टमचे दृश्य येते: chroot किंवा सेवेचे माउंट नेमस्पेस होस्टचा निरपेक्ष मार्ग सहजपणे अनुपस्थित करू शकतात। शेवटी प्रवेश ओळख, जो दृश्यमानतेपासून वेगळा प्रश्न आहे।

ProtectHome आणि PrivateTmp वेगवेगळी स्थाने लपवतात, आणि दोन्हीपैकी कोणतेही होस्टमधून घेतलेल्या निर्देशिका यादीत दिसत नाही। शेलमध्ये root साठी असलेला मार्ग युनिटच्या नेमस्पेसच्या आत अदृश्य असू शकतो, आणि म्हणूनच सेवेबाहेर तोच आदेश तपासणे फार कमी सिद्ध करते।

सेवा विस्तारित न करता शोध दुरुस्त करा

मार्ग अँकर करणे फक्त पहिली सीमा सोडवते। ते सेवा लपवते ती निर्देशिका उघड करत नाही, आणि अविशेषाधिकारित खात्याला केवळ root साठी असलेल्या फाइलचा प्रवेश देत नाही। script-security वाढवणे OpenVPN कोणत्या स्क्रिप्ट चालवेल हे बदलते; सापेक्ष नाव कुठे सोडवले जाते यावर त्याचा कोणताही परिणाम नाही। संपूर्ण सेवेसाठी कार्यरत निर्देशिका बदलणे समस्येपेक्षा व्यापक आहे, कारण इतर प्रत्येक सापेक्ष प्रमाणपत्र, लॉग किंवा सहाय्यक मार्ग त्याच्यासोबत सरकतो।

अरुंद दुरुस्ती निवडा: स्क्रिप्टमधील निर्धारक मार्ग, इन्स्टन्स डेटासाठी स्पष्ट संरचना मूल्य, आणि हुक प्रत्यक्षात ज्या खात्याखाली चालते त्याला जुळणारी फाइल मालकी।

सीमेचे नाव घेणारे पुरावे नोंदवा

उपयुक्त अपयश अहवालात तीन गोष्टी असतात: हुकने प्रयत्न केलेला नेमका मार्ग, तो निर्माण करणारे वातावरण, आणि कोणत्या सीमेने नकार दिला। फाइलचा आशय न ओतता सोडवलेला मार्ग आणि अपवाद छापा। हे त्रिक चुकीचे अँकर लपलेल्या माउंटपासून आणि परवानगी नाकारण्यापासून वेगळे करते, आणि ती तीन वेगवेगळी दुरुस्ती आहेत।

root टर्मिनलवरून फाइल वाचू शकतो हा दावा त्या प्रश्नांपैकी एकाचे उत्तर देतो आणि बाकीच्या कोणाचेही नाही। त्याऐवजी सेवेच्याच संदर्भातून तपासा।