systemd मध्ये OpenVPN ची यादृच्छिक निवड: ExecStart का अयशस्वी होते

एका देशासाठी चाळीस .ovpn फाइल्स पुरवठादाराकडून येतात, आणि योजना स्पष्ट दिसते: यादृच्छिक एक त्याच्या जागी कॉपी करा, नंतर बोगदा सुरू करा. ExecStart च्या आत पाइपलाइन म्हणून लिहिल्यास, ती योजना बूटच्या वेळी काहीही स्पष्ट न करणाऱ्या स्थिती कोडसह मरते. युनिट फाइल स्क्रिप्ट नाही, आणि दुरुस्ती म्हणजे एकतर शेल स्पष्टपणे आणणे किंवा फाइल्स निवडणे पूर्णपणे थांबवणे.

लक्षण: सुरू होऊन लगेच मरणारे युनिट

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

जर्नलमधून अचूक कमांड लाइन वाचणे हे याची पुष्टी करण्याचा सर्वात वेगवान मार्ग आहे. systemd ने जे कार्यान्वित केले ते पुन्हा सांगते, आणि स्ट्रिंग पाइपलाइनची अक्षरे ऑपरेटर म्हणून नव्हे, तर शब्दशः आर्ग्युमेंट म्हणून दाखवेल.

ExecStart पाइपलाइन का चालवू शकत नाही

systemd स्वतः कमांड लाइन विभागते, स्वतःचे अवतरण आणि चल-प्रतिस्थापन लागू करते, आणि नंतर निकाल थेट कार्यान्वित करते. पाइप, रीडायरेक्शन, शेलचे ग्लोब विस्तार आणि कमांड प्रतिस्थापन या व्याकरणाचा भागच नाहीत. ही रचनेची निवड आहे, चूक नाही: युनिट काय चालवायचे ते घोषणात्मकपणे सांगते, आणि शेलचा तर्क युनिट ज्या स्क्रिप्टला कॉल करते तिच्यात असतो. दोन्ही दुरुस्त्या यातूनच येतात, आणि दोन्हीपैकी कोणतीही युनिटला अधिक विशेषाधिकार देण्याची मागणी करत नाही.

हे भ्रामक एक्झिट कोडचेही स्पष्टीकरण देते. पहिले आर्ग्युमेंट बायनरी म्हणून वापरले जाते, त्यामुळे चुकीची ओळ तुमच्या तर्काचा कोणताही भाग चालण्यापूर्वीच अयशस्वी होते.

निवड ExecStartPre मध्ये करा

थेट दुरुस्ती म्हणजे शेलला स्पष्टपणे कॉल करणारे तयारीचे पाऊल, जे निवड आणि सुरुवात एकाच युनिटमध्ये ठेवते, जेणेकरून एकातील अपयश दुसऱ्याला एकटे चालू ठेवू शकणार नाही.

[Service]
Type=notify
ExecStartPre=/bin/bash -c "ls /etc/openvpn/profiles/au* | shuf -n 1 | xargs -r -I{} cp -f {} /etc/openvpn/%i.conf"
ExecStart=/usr/sbin/openvpn --config /etc/openvpn/%i.conf

तीन तपशील ठरवतात की हे खऱ्या मशीनच्या संपर्कात टिकेल का. नाव देणे हा पहिला सापळा आहे: systemd युनिट पार्स करतानाच, bash चालण्याच्या खूप आधी %i बदलते, त्यामुळे स्पेसिफायर एकेरी अवतरणांबाहेर असले पाहिजे. ग्लोब कोणत्याही गोष्टीशी जुळत नसताना xargs -r cp ला आर्ग्युमेंटशिवाय चालण्यापासून रोखते. आणि अयशस्वी तयारीचे पाऊल युनिट थांबवते, आणि हाच योग्य निकाल आहे: कालच्या कॉन्फिगरेशनसह सुरुवात करणे सुरुवात न करण्यापेक्षा वाईट आहे. नेहमी एकच फाइल घेणारी यादृच्छिक निवड सहसा दुर्दैव नसते. कॉपी केलेली फाइल पॅकेज अद्यतनामुळे ओव्हरराइट होत आहे का, किंवा ग्लोब फक्त एका जुन्या नोंदीशी जुळत आहे का ते तपासा.

किंवा OpenVPN लाच एंडपॉइंट निवडू द्या

OpenVPN आधीच एका प्रोफाइलमध्ये अनेक एंडपॉइंट ठेवू शकते आणि त्यातून यादृच्छिकपणे निवडू शकते, ज्यामुळे शेल, प्रत आणि लिहिण्याचा अधिकार बूट मार्गातून पूर्णपणे निघून जातात.

client
remote-random
<connection>
remote au1.example.net 1194 udp
</connection>
<connection>
remote au2.example.net 1194 udp
</connection>

हा प्रकार सर्व्हर निवड पुरवठादाराने लिहिलेल्या फाइलेत ठेवतो, त्यामुळे फाइलींची नावे बदलणारे रोटेशन युनिट तोडत नाही. डिरेक्टरीवरील ग्लोबला कधीच नसते ते गुणही तो देतो: उमेदवारांची यादी लेखापरीक्षणयोग्य होते. प्रोफाइल एंडपॉइंटपेक्षा जास्त गोष्टींमध्ये वेगळे असतात तेव्हा शफलला अजूनही स्थान असते: वेगळी प्रमाणपत्रे, वेगळे राउटिंग निर्देश, वेगळे सिफर धोरण. त्या स्थितीत निवड संपूर्ण कॉन्फिगरेशनमधील असते आणि शेलचे पाऊल ते व्यक्त करण्याचा प्रामाणिक मार्ग आहे.

वापरलेले इन्स्टन्स आणि फाइल पुन्हा वाचा

त्याचा आशय डीबग करण्यापूर्वी कोणते युनिट खरोखर चालू आहे ते निश्चित करा. पॅकेज केलेली मेटा सेवा आणि टेम्पलेट ही पायाभूत सुविधा आहे; तुमच्या फाइलींशी जुळणारी युनिट्स हीच त्यांच्या नावाने ओळखली जाणारी इन्स्टन्स आहेत.

systemctl list-units 'openvpn*'
systemctl cat [email protected]
journalctl -u openvpn@au -n 30 --no-pager

कोणाच्याही लक्षात नसलेले इन्स्टन्स सहसा पॅकेज डिरेक्टरीतील हरवलेल्या कॉन्फिगरेशन फाइलकडे नेते. टेम्पलेटऐवजी ते नाव असलेले इन्स्टन्स बंद करा, अन्यथा पुढील पॅकेज अपग्रेड ते परत आणेल. बदलानंतर युनिट सुरू करा आणि जर्नल जी कमांड लाइन नोंदवते ती वाचा, नंतर त्याने खरोखर उघडलेला कॉन्फिगरेशन मार्ग निश्चित करा. ती एकच तपासणी कार्यरत यादृच्छिक निवड आणि गेल्या महिन्याची फाइल गुपचूप पुन्हा वापरणाऱ्या सेवेमध्ये फरक करते.