बूट होताना Mac वर VPN: launchd कामावर नजर ठेवते, बोगद्यावर नाही

लॉगिनच्या वेळी काम सुरू होते, लॉग क्लायंट सुरू झाल्याचे दाखवतो, पण बोगदा कधीच वर येत नाही। किंवा वर येतो आणि काही सेकंदांनी नाहीसा होतो। दोन्ही प्रसंगी गुणधर्म यादी बहुधा ठीक होती। 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 म्हणून चालणारा डीमन सामान्यतः लॉगिन कीचेन आयटम वाचू शकत नाही, आणि हा असा तपशील आहे जो केवळ सिस्टम संदर्भात दिसतो।

तयार म्हणजे काय हे ठरवा, मग तिथेच चाचणी करा

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

पुनःप्रयत्न मर्यादित असावेत आणि गहाळ नेटवर्क आणि नाकारलेले क्रेडेन्शियल यात फरक करावा। प्रत्येक अयशस्वीतेवर पुन्हा सुरू करणे कालबाह्य प्रमाणपत्र दुरुस्त करू शकत नाही आणि खरे प्रयत्न लपवणाऱ्या एकसारख्या प्रयत्नांनी भरलेला लॉग तयार करते।

काम ते प्रत्यक्षात चालेल त्या संदर्भात स्वीकारा: बूट होताना नेटवर्क नाही, सामान्य लॉगिन, झोपेतून जागे होणे आणि नियंत्रित थांबणे। मग कामाचे लेबल, क्लायंट आवृत्ती आणि प्रोफाइल पुनरावृत्ती एकत्र नोंदवा, जेणेकरून पुढील व्यक्तीला एकदा चाललेल्या फाइलऐवजी श्रेय देण्यायोग्य सेवा वारसा मिळेल।