VPN पछाडि NFS: बुटमा माउन्ट वा माग अनुसार अटोमाउन्ट?
बुटमा माउन्ट अझै नउठेको टनेलमा अड्किन्छ। अटोमाउन्ट पहिलो पहुँचको प्रतीक्षा गर्छ, र VPN निर्भरता ट्रिगरमा होइन, माउन्ट युनिटमा हुनुपर्छ।
दुई कन्फिगरेसनले एउटै समस्या समाधान गर्छन् र विपरीत दिशामा असफल हुन्छन्। बुटमा साझेदारी माउन्ट गर्दा प्रत्येक सेवालाई एउटा फाइलसिस्टम दिन्छ जो या त हुन्छ वा बुट किन रोकियो भन्ने कारण दिन्छ। माग अनुसारको अटोमाउन्टले मेसिनलाई छिटो बुट दिन्छ र प्रतीक्षा पथलाई पहिले छुनेलाई सुम्पन्छ। 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 प्रविष्टिको छेउमा जान्छन्। अर्को व्यक्तिले कन्फिगरेसनको सट्टा व्यवहार उत्तराधिकारमा पाउँछ जसलाई उल्टो इन्जिनियर गर्नुपर्ने हुन्थ्यो।