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 എൻട്രിക്ക് അടുത്ത് പോകുന്നു. അടുത്ത വ്യക്തിക്ക് റിവേഴ്സ് എഞ്ചിനീയർ ചെയ്യേണ്ട കോൺഫിഗറേഷന് പകരം പെരുമാറ്റം പാരമ്പര്യമായി ലഭിക്കുന്നു.