VPN के पीछे NFS: बूट पर माउंट या मांग पर ऑटोमाउंट?

दो कॉन्फ़िगरेशन एक ही समस्या हल करते हैं और विपरीत दिशाओं में विफल होते हैं। शेयर को बूट पर माउंट करने से हर सेवा को एक फ़ाइलसिस्टम मिलता है जो या तो मौजूद है या बताता है कि बूट क्यों अटका। मांग पर ऑटोमाउंट मशीन को तेज़ बूट देता है और प्रतीक्षा उसी को सौंप देता है जो पथ को पहले छूता है। VPN के पीछे दूसरा आम तौर पर बेहतर सौदा है, और कारण यह है कि टनल एक ऐसा क्रम थोपता है जिसे बूट क्रम देख नहीं सकता।

बूट माउंट बनाम ऑटोमाउंट

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

ऑटोमाउंट इसे उलट देता है। पथ तुरंत मौजूद होता है, असली माउंट तब होता है जब कुछ उसे खोलता है, और जल्दी शुरू होने वाली सेवाएँ ऐसी टनल पर नहीं अटकतीं जो अभी ऊपर न आई हो।

तुलना इस पर आती है कि देरी कौन सहे। जिस वर्कस्टेशन को उपयोगकर्ता के काम कर सकने से पहले शेयर चाहिए, उसे शायद प्रतीक्षा करनी चाहिए। बैग में बूट होने वाले लैपटॉप को, या जिस सर्वर का शेयर वैकल्पिक है, उसे नहीं।

कोई भी विकल्प गुमशुदा रूट को ठीक नहीं करता। दोनों बस यह तय करते हैं कि विफलता कब देखी जाएगी।

fstab पंक्ति, विकल्प दर विकल्प

मान लें कि मौजूदा OpenVPN क्लाइंट इंस्टेंस [email protected] है, सर्वर files.corp.example है और माउंट पॉइंट /mnt/work है। तीनों को अपनी साइट के अधिकृत मानों से बदलें। एक काम करने वाली पंक्ति ऐसी दिखती है:

files.corp.example:/export/work /mnt/work nfs _netdev,nofail,x-systemd.automount,[email protected],x-systemd.mount-timeout=30s 0 0

_netdev माउंट को नेटवर्किंग की आवश्यकता वाला चिह्नित करता है, और यह किसी टनल का नाम नहीं लेता। nofail सामान्य फ़ाइलसिस्टम लक्ष्य के लिए शेयर को वैकल्पिक रखता है। x-systemd.automount तुरंत माउंट करने के बजाय मांग पर ट्रिगर बनाता है।

x-systemd.requires= वह हिस्सा है जो माउंट प्रयास को VPN यूनिट से बाँधता है, और यह ट्रिगर पर नहीं, माउंट ऑपरेशन पर आता है। ऑटोमाउंट यूनिट पर ही व्यापक क्रम रखना वही तरीका है जिससे लोग ऐसे चक्र बनाते हैं जिनकी शिकायत systemd फिर ऐसी भाषा में करता है जिसे कोई दो बार नहीं पढ़ता।

x-systemd.mount-timeout=30s शुरुआती माउंट कमांड को सीमित करता है। यह बाद में होने वाली किसी भी चीज़ को सीमित नहीं करता, और इस विकल्प के बारे में यही सबसे आम गलतफहमी है।

‘शुरू हुआ’ का क्या अर्थ नहीं है

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

जहाँ हो वहाँ कनेक्शन के मालिक का अपना तैयारी संकेत अतिरिक्त पूर्वशर्त के रूप में इस्तेमाल करें। निश्चित नींद एक अनुमान है जो आपके डेस्क पर काम करता है और धीमे नेटवर्क पर या दोबारा जुड़ने के बाद विफल होता है।

उदाहरण पथ के लिए बनी यूनिट देखें: mnt-work.automount और mnt-work.mount। समीक्षित fstab बदलाव के बाद systemd पुनः लोड करें और असंबंधित प्रविष्टियाँ आज़माने वाला व्यापक माउंट कमांड चलाने के बजाय उन यूनिट को सीधे संभालें।

यहाँ एक और चेतावनी आती है। शुरुआत में /mnt/work को छूने वाली सेवा अब भी माउंट ट्रिगर करती है और अब भी उसकी प्रतीक्षा करती है, इसलिए शेयर को वैकल्पिक चिह्नित करना हर एप्लिकेशन को धैर्यवान नहीं बनाता।

माउंट के बाद यह दूसरी विफलता है

NFS माउंट हो जाने के बाद, फ़ाइलसिस्टम का पुनः प्रयास और पुनर्प्राप्ति व्यवहार तय करता है कि बाद में होने वाला व्यवधान किसी पढ़ने या लिखने के साथ क्या करता है। आपने जो माउंट टाइमआउट सेट किया है उसका इस पर कोई प्रभाव नहीं है।

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

तय करें कि जब टनल गिरे तो लिखने के बीच में मौजूद प्रक्रिया के साथ क्या होना चाहिए, और उसे लिख लें। वह उत्तर किसी भी विकल्प-श्रृंखला से अधिक उपयोगी है।

एक नहीं, चार अवस्थाएँ जाँचें

टनल उपलब्ध होने पर सामान्य बूट आसान स्थिति है और लगभग कुछ साबित नहीं करता। यह पुष्टि करता है कि श्रृंखला सही लिखी है और बस। VPN के बिना पहला एक्सेस जाँचें, फिर उसके ऊपर आने पर पुनर्प्राप्ति, फिर सफल माउंट के बाद नियंत्रित व्यवधान।

चार अवस्थाएँ, चार अवलोकन, और नोट्स fstab प्रविष्टि के पास जाते हैं। अगले व्यक्ति को कॉन्फ़िगरेशन के बजाय व्यवहार विरासत में मिलता है जिसे उसे उलटा इंजीनियर करना पड़े।