VPN सेवा को फिर से शुरू करने से उसका उपयोग करने वाला हर सत्र समाप्त हो जाता है, इसलिए विंडो बातचीत के इर्द-गिर्द बननी चाहिए, पैकेज प्रबंधक के इर्द-गिर्द नहीं। उपयोगकर्ताओं को संवेदनशील काम पूरा करने के लिए पर्याप्त सूचना चाहिए, और आपको लौटने का ऐसा रास्ता चाहिए जो उस टनल पर निर्भर न हो जिसे आप अभी रोकने वाले हैं। प्लेबुक में बाकी सब कुछ इन दो तथ्यों को संभव बनाने के लिए है। इनमें से कोई एक छोड़ दें और नियमित अपडेट बिना निकास वाला व्यवधान बन जाता है।

नीचे का क्रम जानबूझकर है: हर चरण कुछ ऐसा बनाता है जो अगले चरण को चाहिए, और कोई भी चरण शुरू होने से पहले बदलाव समाप्त कर सकता है।

बदलने से पहले मौजूद सेवा दर्ज करें

याद की हुई यूनिट नहीं, इंस्टॉल की गई यूनिट पढ़ें: systemctl cat [email protected] यूनिट और कोई भी drop-in छापता है, और systemctl show [email protected] -p ExecStart -p User -p WorkingDirectory दिखाता है कि वास्तव में क्या और किस पहचान के रूप में चल रहा है। उस यूनिट द्वारा बताए गए बाइनरी से पूछें, क्योंकि शेल से openvpn --version किसी दूसरे बिल्ड पर हल हो सकता है। प्रोफ़ाइल का पथ और उसके द्वारा संदर्भित हर फ़ाइल दर्ज करें।

सुनने वाले सॉकेट पर भी ध्यान दें: ss -lunp | grep 1194 बताता है कि आज डेमन के पास कौन-सा पता और प्रोटोकॉल है। यदि उत्तर वह नहीं है जो प्रोफ़ाइल सुझाता है, तो कोई drop-in या एनवायरनमेंट फ़ाइल उसे ओवरराइड कर रही है, और अपग्रेड वही आश्चर्य विरासत में लेगा।

ऐसा रिकवरी सेट इकट्ठा करें जिसे कोई और उपयोग कर सके

रिकवरी सेट ऐसा होना चाहिए कि 03:00 बजे आपके संदर्भ के बिना सहकर्मी उसका उपयोग कर सके। प्रभावी कॉन्फ़िगरेशन के साथ हर संदर्भित फ़ाइल, PKI स्वामी के नियंत्रण वाली विश्वास और निरसन सामग्री, प्रति-क्लाइंट आवंटन और हुक, और आज स्थापित सटीक पैकेज संस्करण शामिल करें। एक फ़ाइल नाम की प्रति कॉन्फ़िगरेशन नहीं है। इसे ऐसी जगह रखें जहाँ ऑन-कॉल ऑपरेटर VPN के बिना पहुँच सके।

पहुँच नियंत्रण उस सेट पर भी लागू होते हैं, क्योंकि इसमें निजी कुंजियाँ या बैकएंड क्रेडेंशियल हैं। केवल पैकेज संस्करण बदलने पर CA दोबारा न बनाएँ और पहचान दोबारा जारी न करें।

वास्तविक क्लाइंट के साथ पायलट श्रोता पर अभ्यास करें

उम्मीदवार रिलीज़ को अलग श्रोता पर उसकी अपनी पोर्ट और पता योजना के साथ चलाएँ, उसी सॉकेट पर उत्पादन इंस्टेंस के बगल में नहीं। उन क्लाइंट इंजनों से जुड़ें जो आपके उपयोगकर्ता वास्तव में चलाते हैं, मुश्किल वाले सहित। पता आवंटन, धकेला गया DNS, एक महत्वपूर्ण एप्लिकेशन और एक ऐसा पथ जाँचें जो अवरुद्ध रहना चाहिए। कस्टम हुक सेवा के वास्तविक विशेषाधिकार और फ़ाइलसिस्टम संदर्भ में चलने चाहिए, क्योंकि रूट शेल उनके बारे में कुछ सिद्ध नहीं करता।

रिलीज़ नोट केवल नई सुविधाओं के लिए नहीं, व्यवहार परिवर्तनों के लिए पढ़ें। साइफ़र और TLS डिफ़ॉल्ट संस्करणों के बीच बदलते हैं, और अभी भी पार्स होने वाला प्रोफ़ाइल भी हैंडशेक में विफल हो सकता है। यदि अपग्रेड को प्रोफ़ाइल या प्रमाणपत्र परिवर्तन चाहिए, तो उसे पैकेज अपडेट में मिलाने के बजाय अलग चरण के रूप में रखें।

एक बार स्विच करें, टनल के बाहर के पथ से

विंडो ऐसे कंसोल या प्रबंधन नेटवर्क से शुरू करें जो सेवा से न गुज़रे। पुष्टि करें कि उपयोगकर्ताओं को सूचित किया गया है और दूसरा ऑपरेटर रोलबैक जानता है। तैयार बदलाव को उसके स्वामी के माध्यम से लागू करें, फिर sudo systemctl restart [email protected] से पुनः आरंभ करें और journalctl -u openvpn-server@office -b -f से जर्नल का पालन करें। जब केवल यूनिट परिभाषाएँ बदली हों तो रीलोड पर्याप्त है; बदला हुआ प्रोफ़ाइल प्रक्रिया के पुनः आरंभ की माँग करता है।

अपेक्षा करें कि हर क्लाइंट फिर से जुड़ेगा, और यह भी कि कुछ एप्लिकेशन सत्र फिर से शुरू नहीं होंगे। जो वर्कलोड इसे सह नहीं सकते उनके साथ साफ़ ठहराव समन्वित करें।

स्वीकार करें या रोलबैक करें, फिर उपयोगकर्ताओं को बताएँ कि क्या बदला

स्वीकृति का अर्थ है नया लॉगिन, वास्तविक संचालन, और अब भी लागू प्रतिबंध। सक्रिय यूनिट और हरी स्थिति पंक्ति प्रक्रिया के तथ्य हैं। यदि मानदंड विंडो के भीतर विफल हों, तो तैयार विधि से रोलबैक करें, एक फ़ाइल बहाल करके आशा करने से नहीं; बदला हुआ बाइनरी या सेवा नीति कॉन्फ़िगरेशन बहाली के बाद भी टिकती है। विंडो के दौरान किया गया कोई भी निरसन या प्राधिकरण परिवर्तन सुरक्षित रखें ताकि रोलबैक सुरक्षा कार्य को न बिगाड़े।

अगले ऑपरेटर के लिए संस्करण, प्रोफ़ाइल परिवर्तन और स्वीकृति परिणाम दर्ज करें, पायलट श्रोता को सेवामुक्त करें, और उपयोगकर्ताओं को बताएँ कि अब कौन-सी प्रोफ़ाइल उपयोग करनी है। वह नोट छोड़कर समाप्त होने वाली विंडो अगले अपडेट पर फिर से बहस में आती है।

संबंधित लेख