status=200/CHDIR: systemd ले OpenVPN कहिल्यै सुरु गरेन
CHDIR असफलताको अर्थ systemd कुनै निर्देशिकामा प्रवेश गर्न सकेन, OpenVPN ले प्रोफाइल पढ्न सकेन भन्ने होइन। VPN कन्फिगरेसन छुनुअघि unit पढ्नुहोस्।
सेवा असफल हुन्छ, लगहरूमा 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 सँग कसरी बुझिन्छ भनी परिभाषित गर्छ। सम्झनुपर्ने ढाँचा सरल छ: हरेक स्थिति कोडले फरक चरणको नाम दिन्छ, र केवल अनुप्रयोगका आफ्नै त्रुटिले अनुप्रयोगको वर्णन गर्छन्।