बूट पर Mac VPN: launchd कार्य की निगरानी करता है, सुरंग की नहीं
साफ़ plist क्रेडेंशियल या तैयारी के बारे में कुछ साबित नहीं करता। कार्य को उसके सत्र से मिलाएँ, क्लाइंट को अग्रभूमि में रखें और उसी संदर्भ में परीक्षण करें।
कार्य लॉगिन पर चलता है, लॉग क्लाइंट के शुरू होने को दिखाता है, और सुरंग कभी ऊपर नहीं आती। या आती है और कुछ सेकंड बाद गायब हो जाती है। दोनों मामलों में प्रॉपर्टी सूची संभवतः ठीक थी। launchd ने कार्य स्वीकार करते समय दो वादे किए: यह एक प्रक्रिया की निगरानी करेगा, और वह प्रक्रिया चलती रहेगी। VPN को दोनों चाहिए, और एक सही XML फ़ाइल दोनों में से कोई नहीं देती।
वैध प्रॉपर्टी सूची चलती हुई सेवा नहीं है
plutil -lint संरचना की जाँच करता है। यह नहीं बता सकता कि बाइनरी मौजूद है या नहीं, क्या इस क्लाइंट संस्करण में तर्क समर्थित हैं, या कार्य ऐसे संदर्भ में शुरू होता है जहाँ क्रेडेंशियल उपलब्ध हैं। ये अर्थपूर्ण प्रश्न हैं, और ये उन अधिकांश विफलताओं की व्याख्या करते हैं जो launchd समस्याओं जैसी दिखती हैं।
plutil -lint /Library/LaunchDaemons/com.example.vpn.plist
launchctl print system/com.example.vpn
कार्य लोड हो गया मानने के बजाय दूसरे कमांड का आउटपुट पढ़ें। यह अंतिम निकास स्थिति और सेवा के चलने की जानकारी देता है, जो प्रोफ़ाइल छूने से पहले “कभी शुरू नहीं हुआ” और “शुरू हुआ और मर गया” में अंतर करता है।
एजेंट उपयोगकर्ता सत्र विरासत में पाते हैं, डेमॉन नहीं
Apple का launchd दस्तावेज़ प्रति-उपयोगकर्ता एजेंट को सिस्टम डेमॉन से अलग करता है। एजेंट लॉगिन किए हुए उपयोगकर्ता के संदर्भ में, उसकी कीचेन और वातावरण के साथ चलता है। डेमॉन उस सत्र के बिना चलता है, और कार्य को सिस्टम निर्देशिका में ले जाने से उपयोगकर्ता के इंटरैक्टिव क्रेडेंशियल फिर से नहीं बनते।
यही अंतर डिज़ाइन तय करता है। यदि कनेक्शन के लिए किसी व्यक्ति का लॉगिन करना या MFA अनुरोध स्वीकृत करना आवश्यक है, तो समर्थित व्यवस्था है लॉगिन के बाद चलने वाला उपयोगकर्ता-सत्र कार्य। यदि इसे किसी के लॉगिन के बिना काम करना है, तो क्लाइंट को अपनी नवीनीकरण और निरसन प्रक्रिया वाली स्वीकृत अनुपस्थित पहचान चाहिए। गलत पंक्ति चुनने से ऐसा कार्य बनता है जो साफ़ शुरू होता है और पहले प्रमाणीकरण चरण पर विफल हो जाता है।
तर्क सरणी में पासवर्ड से या प्रमाणपत्र जाँच बंद करके अंतर को न छिपाएँ। दोनों प्रमाणीकरण आवश्यकता को पठनीय फ़ाइल में स्थायी रहस्य बना देते हैं, और दूसरे का अर्थ है कि सुरंग जो भी उत्तर दे उसका प्रमाणीकरण करती है।
निगरानी तभी काम करती है जब प्रक्रिया आगे रहे
जो क्लाइंट स्वयं को डेमॉन बना लेता है, वह नियंत्रण तुरंत launchd को लौटा देता है, और फिर पर्यवेक्षक ऐसी प्रक्रिया देखता है जो पहले ही बाहर निकल चुकी है। सुरंग ऊपर हो सकती है, लेकिन launchd मानता है कि कार्य विफल हुआ, और उसकी पुनःआरंभ नीति कुछ ऐसा करेगी जो आपने नहीं चाहा था।
क्लाइंट के दस्तावेज़ित अग्रभूमि या सेवा मोड का उपयोग करें। यदि उत्पाद की अपनी समर्थित स्टार्टअप सुविधा है, तो वह पहले से जानती है कि अग्रभूमि में कैसे रहना है और नेटवर्क स्टैक को कैसे सौंपना है; कस्टम कार्य अलग डिज़ाइन है, उसका सुधार नहीं।
कार्य को अनोखा लेबल, इच्छित निष्पादन योग्य फ़ाइल और सोच-समझकर बनी तर्क सरणी दें। सरणी shell कमांड लाइन नहीं है, इसलिए पाइप और रीडायरेक्शन वहाँ काम नहीं करते, और उद्धरण चिह्न अलग व्यवहार करते हैं। व्यवस्थापक के टर्मिनल में सफल होने वाला कमांड अधिकतम प्रारंभिक जाँच है।
क्रेडेंशियल को बिना संकेत के काम करना होगा
बिना निगरानी वाला संचालन क्रेडेंशियल समस्या को हटाने के बजाय स्थानांतरित करता है। किसी को पहचान का स्वामी होना चाहिए, यह तय करना चाहिए कि वह कितनी देर जीवित रहेगी, और यह प्रलेखित करना चाहिए कि उसे कैसे बदला जाता है। समाप्ति निगरानी के बिना प्रमाणपत्र कैलेंडर पर तारीख वाला व्यवधान बन जाता है।
रहस्यों को तर्कों से और कार्य के मानक आउटपुट से बाहर रखें। यदि क्लाइंट संरक्षित भंडार से क्रेडेंशियल पढ़ने का समर्थन करता है, तो वह मार्ग अपनाएँ, और जाँचें कि कार्य का निष्पादन संदर्भ भंडार तक पहुँच सकता है। root के रूप में चलने वाला डेमॉन सामान्यतः लॉगिन कीचेन आइटम नहीं पढ़ सकता, और यही ऐसा विवरण है जो केवल सिस्टम संदर्भ में दिखता है।
तैयारी का अर्थ तय करें, फिर वहीं परीक्षण करें
सफल लॉन्च साबित करता है कि प्रक्रिया शुरू हुई। यह साबित नहीं करता कि नेटवर्क ऊपर है, गेटवे ने पहचान स्वीकार की है, या निजी एप्लिकेशन पहुँच योग्य है। यदि कुछ और सुरंग पर निर्भर है, तो उसे कनेक्शन दर्शाने वाला तैयारी संकेत चाहिए, कार्य का आरंभ समय नहीं।
पुनःप्रयास सीमित होने चाहिए और अनुपस्थित नेटवर्क को अस्वीकृत क्रेडेंशियल से अलग पहचानना चाहिए। हर विफलता पर पुनःआरंभ समाप्त प्रमाणपत्र की मरम्मत नहीं कर सकता और समान प्रयासों से भरा लॉग बनाता है जो असली को छिपा देता है।
कार्य को उसी संदर्भ में स्वीकार करें जिसमें वह वास्तव में चलेगा: बूट पर कोई नेटवर्क नहीं, सामान्य लॉगिन, नींद से जागना और नियंत्रित रोक। फिर कार्य लेबल, क्लाइंट संस्करण और प्रोफ़ाइल संशोधन एक साथ दर्ज करें, ताकि अगला व्यक्ति एक बार काम कर चुकी फ़ाइल के बजाय श्रेय-योग्य सेवा विरासत में पाए।