sudo, &, -b या --daemon: OpenVPN क्लाइंट को बैकग्राउंड में कैसे चलाएँ
एम्परसैंड टर्मिनल मुक्त करता है, लॉगिन नहीं। sudo -b, --daemon और किसी सेवा इंस्टेंस की तुलना करें—प्रक्रिया का स्वामी कौन है और संकेतों का उत्तर कौन देता है।
‘इसे बैकग्राउंड में चलाओ’ वाक्यांश में दो सवाल छिपे हैं। पहला यह कि क्या यह उपयोगकर्ता विशेषाधिकार प्राप्त प्रक्रिया शुरू ही कर सकता है; दूसरा यह कि क्या सत्र किसी के टर्मिनल में टाइप किए बिना चल सकता है। शेल का एम्परसैंड किसी का भी उत्तर नहीं देता, और sudo पासवर्ड को किसी चर में रखने वाली स्क्रिप्ट पहले का बुरा उत्तर देती है और दूसरे को अछूता छोड़ देती है। इन्हें अलग कीजिए और विकल्पों की तुलना आसान हो जाती है।
तीनों उम्मीदवारों की तुलना स्वामित्व पर करें, सुविधा पर नहीं।
टर्मिनल छोड़ने के तीन तरीके, तीन अलग स्वामी
किसी आदेश के आगे एम्परसैंड लगाने से शेल उसे बैकग्राउंड जॉब के रूप में चलाता है, और जॉब अब भी उसी शेल का रहता है। प्रोग्राम शुरू होने से पहले भी sudo पूछ सकता है, और OpenVPN बाद में कुंजी पासफ़्रेज़ या लॉगिन के लिए पूछ सकता है। इनपुट की अपेक्षा करने वाले आदेश को बैकग्राउंड में भेजने से ऐसी प्रक्रिया बनती है जो ऐसे टर्मिनल का इंतज़ार करती है जिसे कोई नहीं देख रहा। टर्मिनल मुक्त हो जाता है; अंतःक्रिया नहीं।
यह सबसे सस्ता विकल्प है और सबसे भ्रमित करने वाले ढंग से विफल होता है, क्योंकि संकेत वहाँ दिखता है जहाँ से ऑपरेटर पहले ही जा चुका है।
sudo -b क्रेडेंशियल प्रबंधक नहीं है
sudo -b sudo के अपने दृष्टिकोण से आदेश को बैकग्राउंड में चलाता है, जो सुनने में वह गुम सुविधा लगती है, पर है नहीं। sudo मैनुअल के अनुसार, उस मोड में इंटरैक्टिव आदेश सामान्यतः गलत व्यवहार करते हैं, और शेल जॉब नियंत्रण उसकी बनाई प्रक्रियाओं को संभाल नहीं सकता। यह प्रक्रिया को हटाता है, बिना उसे सवालों का जवाब देने का कोई तरीका दिए। इसमें कुछ भी निजी कुंजी का पासफ़्रेज़ या गेटवे लॉगिन नहीं देता।
अगर कनेक्शन को अंतःक्रिया चाहिए, तो समाधान एक समर्थित गैर-इंटरैक्टिव प्रमाणीकरण व्यवस्था है, उसी संकेत को शुरू करने का दूसरा तरीका नहीं।
--daemon प्रोग्राम बदलता है, लॉगिन नहीं
--daemon OpenVPN से ही इनिशियलाइज़ेशन के बाद अलग होने को कहता है। 2.6 मैनुअल बताता है कि syslog रीडायरेक्शन विकल्प के पार्स होने पर होता है, हालाँकि अलग होना बाद में होता है, इसलिए संदेश अपेक्षा से पहले टर्मिनल में दिखना बंद कर सकते हैं। उस बिंदु के बाद की चुप्पी सुरंग के बारे में कुछ साबित नहीं करती। स्पष्ट --log या --log-append जोड़ें ताकि आउटपुट ऐसी जगह पहुँचे जहाँ से आप उसे पढ़ सकें।
डेमन मोड कंसोल को भी स्थायी रूप से हटा देता है। संरक्षित निजी कुंजी को उस मोड में askpass चाहिए, और कंसोल से दिए गए क्रेडेंशियल कैशिंग विकल्पों के साथ मिलकर बाद के पुनःप्रमाणीकरण को पूछने की जगह के बिना छोड़ सकते हैं। बैकग्राउंड शुरुआत अपने पहले कुंजी नवीनीकरण तक टिकेगी, यह मानने से पहले स्थापित संस्करण के सामने प्रमाणीकरण मॉडल जाँचें।
sudo सत्यापन क्या देता है और क्या नहीं
sudo -v कैश किए गए स्थानीय क्रेडेंशियल को मान्य या ताज़ा करता है, और नीति माँगे तो प्रमाणीकरण करता है। यह OpenVPN शुरू नहीं करता, गेटवे के सामने प्रमाणीकरण नहीं करता, और यह गारंटी नहीं देता कि स्क्रिप्ट का बाद का आदेश अनुमत होगा। sudo -n इसका उल्टा कहता है: पूछो मत, विफल हो जाओ। इससे स्थानीय प्राधिकरण विफलता स्पष्ट हो जाती है, जो उपयोगी है, और यह नहीं बताता कि OpenVPN बाद में क्या माँगेगा।
दोनों में से कोई विकल्प सबको पासवर्डरहित आदेश देने या व्यवस्थापक का पासवर्ड स्क्रिप्ट में डालने का कारण नहीं है।
ऐसे स्वामी को प्राथमिकता दें जिसे देखा जा सके
मशीन के स्वामित्व वाली सुरंग के लिए वही सेवा इंस्टेंस इस्तेमाल करें जिसे डिस्ट्रीब्यूशन समर्थित करता है। वह स्वामी शुरू, बंद, स्थिति और लॉग देता है, और आपका सत्र खत्म होने के बाद भी टिका रहता है। शेल बैकग्राउंडिंग, डेमनाइज़ेशन और रीस्टार्ट लूप को एक-दूसरे के इर्द-गिर्द जोड़ने से एक सुरंग के लिए तीन स्वामी बन जाते हैं और यह स्पष्ट उत्तर नहीं मिलता कि कौन चल रहा है।
आप जो भी चुनें, उस संसाधन को सत्यापित करें जिसके लिए सुरंग मौजूद है। सफल शुरुआत अनुरोध एक प्रक्रिया घटना है, कार्यशील कनेक्शन का प्रमाण नहीं।