status=200/CHDIR: systemd ने OpenVPN कधीही सुरू केले नाही

सेवा अयशस्वी होते, लॉगमध्ये spawn आणि डिरेक्टरीचा उल्लेख असतो, आणि पहिली प्रवृत्ती VPN कॉन्फिगरेशन तपासण्याची असते। त्या फाइलमधून अजून काहीही वाचले गेले नाही। systemd प्रक्रिया तयार करताना, एक्झिक्युटेबल चालण्यापूर्वीच अयशस्वी झाले, त्यामुळे कोणताही parser, कोणतेही प्रमाणपत्र आणि कोणताही दूरस्थ होस्ट विचारला गेला नाही। स्थिती कोड OpenVPN बद्दल नव्हे तर systemd बद्दल विधान म्हणून वाचणे हेच याला छोटी चौकशी बनवते।

अनुप्रयोगापूर्वी स्थिती कोड वाचा

सेवा नावानंतरचा संख्यात्मक कोड अपयशी झालेल्या टप्प्याचे नाव देतो। डिरेक्टरी अपयश CHDIR स्थिती म्हणून नोंदवले जाते, तर चालू न शकलेली एक्झिक्युटेबल फाइल पूर्णपणे वेगळा कोड आहे। दोन्ही सारांश ओळीत सारखे दिसतात आणि त्यांच्या कारणांमध्ये काहीही सामायिक नाही।

हा फरक महत्त्वाचा आहे कारण दुरुस्त्या वेगवेगळ्या फाइलांमध्ये आहेत। CHDIR अपयश पथ आणि सेवा तो कसा पाहते याशी संबंधित आहे। Exec अपयश बायनरी, त्याचा इंटरप्रिटर किंवा असंबद्ध mount शी संबंधित आहे। VPN चा दूरस्थ बिंदू, सिफर यादी किंवा प्रमाणपत्राचा पथ बदलल्याने यापैकी काहीही सुटणार नाही।

अपयश सुरुवातीला आहे, यशस्वी चालनानंतर नाही याची खात्री करा। सेवा काल चालत होती आणि आता त्याच टप्प्यावर अयशस्वी होत असेल, तर डिरेक्टरी, तिच्या परवानग्या किंवा unit मध्येच काहीतरी बदलले आहे, आणि तोच बदल शोधायचा पुरावा आहे।

unit ला विचारा की त्याला कुठे असायचे आहे

प्रभावी unit वाचा, आपण स्थापित समजत असलेली फाइल नव्हे, कारण drop-in फाइल्स मुख्य unit कधीही न बदलता कार्य डिरेक्टरी ओव्हरराइड करू शकतात। show चे आउटपुट प्रश्नाला थेट उत्तर देते:

systemctl cat [email protected]
systemctl show [email protected] -p WorkingDirectory -p RootDirectory -p User -p ProtectHome
journalctl -u [email protected] -b --no-pager | tail -30

upstream सर्व्हर टेम्पलेटसाठी कार्य डिरेक्टरी सर्व्हर कॉन्फिगरेशन डिरेक्टरी आहे आणि इंस्टन्सचे नाव तिच्यातील प्रोफाइल निवडते। त्यामुळे branch नावाचा इंस्टन्स त्याच डिरेक्टरीत स्वतःच्या फाइलची अपेक्षा करतो, आणि दुसर्या ठिकाणी ठेवलेले प्रोफाइल कार्य डिरेक्टरीची अट अजिबात पूर्ण करत नाही।

unit काय मागतो आणि काय अस्तित्वात आहे याची तुलना करा। पूर्वी असलेला पथ, आता दुसरीकडे निर्देश करणारा सिंबॉलिक लिंक, किंवा आता डिरेक्टरीशी जुळणारे नसलेले इंस्टन्स नाव—हे सर्व सामान्य बदल आहेत जे नेमके हेच अपयश निर्माण करतात।

पथ सेवा जसा पाहते तसा तपासा

तुमचा shell आणि सेवा फाइल सिस्टमचे एकच दृश्य सामायिक करत नाहीत। कॉन्फिगर केलेली रूट डिरेक्टरी किंवा root image unit मधील निरपेक्ष पथाचा अर्थ बदलते, आणि होस्टवर स्पष्टपणे असलेला पथ त्या नावाच्या जागेत नसू शकतो। मॅन्युअल चाचणीवर विश्वास ठेवण्यापूर्वी unit च्या सेटिंग्ज वाचा।

परवानग्या समस्या वाढवतात। सेवा विशिष्ट वापरकर्त्याच्या रूपात चालते, आणि त्या वापरकर्त्याला लक्ष्यापर्यंत पोहोचण्यासाठी प्रत्येक पालक डिरेक्टरीतून जाता आले पाहिजे, केवळ लक्ष्य वाचता आले पाहिजे असे नाही। root साठी वाचनीय पण सेवा वापरकर्त्यासाठी अगम्य डिरेक्टरी अशी अपयश निर्माण करते जी गहाळ पथासारखी दिसते।

namei -l /etc/openvpn/server
systemctl show [email protected] -p ProtectSystem -p ReadOnlyPaths

कडकपणाच्या सेटिंग्जही या चित्राचा भाग आहेत। जो unit होम डिरेक्टर्या लपवतो किंवा फाइल सिस्टमचा काही भाग केवळ-वाचनीय करतो, तो जेमतेम त्यासाठीच कॉन्फिगर केलेला आहे तेच करतो, आणि कार्य डिरेक्टरी तिथे असली पाहिजे जिथे sandbox अजूनही ती उघड करतो।

मालक दुरुस्त करा, मग दुसर्या त्रुटीची अपेक्षा करा

लेआउट किंवा unit त्या कॉन्फिगरेशनच्या मालकामार्फत दुरुस्त करा। प्रोफाइल अपेक्षित डिरेक्टरीत हलवणे हे लेआउट चुकीचे असताना योग्य दुरुस्ती आहे, पण प्रवेश न होऊ शकणार्या डिरेक्टरीचे ते स्पष्टीकरण देत नाही, म्हणून त्याला सर्वसाधारण उत्तर मानू नका।

कॉन्फिगरेशन ट्रीवर परवानग्या वाढवण्याच्या किंवा sandbox काढण्याच्या शॉर्टकटला विरोध करा। दोन्ही लक्षणे मिटवतात आणि तेथे जाणीवपूर्वक ठेवलेली संरक्षणेही काढून टाकतात, आणि पुढील अपयश समजावून सांगणे कठीण होईल।

इंस्टन्स पुन्हा सुरू करा आणि यश गृहीत धरण्याऐवजी पुढील घटना वाचा। संभाव्य पुढील त्रुटी म्हणजे OpenVPN स्वतःची कॉन्फिगरेशन फाइल उघडू शकत नाही, जी प्रगती आहे: कार्य डिरेक्टरीत प्रवेश झाला आणि parser आता चालू आहे। तिथून unit च्या वास्तविक फाइल मॅपिंगचे अनुसरण करा, नेटवर्क समस्या सोडवण्याकडे परत जाऊ नका।

systemd चा कार्यान्वयन संदर्भ कार्य डिरेक्टरी रूट डिरेक्टर्या आणि sandbox सोबत कशी समजली जाते हे परिभाषित करतो। लक्षात ठेवण्याचा नमुना सोपा आहे: प्रत्येक स्थिती कोड वेगळ्या टप्प्याचे नाव देतो, आणि केवळ अनुप्रयोगाच्या स्वतःच्या त्रुटी अनुप्रयोगाचे वर्णन करतात।