NFS za VPN: priklop ob zagonu ali samodejni priklop na zahtevo?

Dve konfiguraciji rešita isto težavo in spodletita v nasprotnih smereh. Priklop skupne rabe ob zagonu da vsaki storitvi datotečni sistem, ki je bodisi tam bodisi pojasni, zakaj se je zagon ustavil. Samodejni priklop na zahtevo da stroju hiter zagon in čakanje preda tistemu, ki se poti dotakne prvi. Za VPN je druga običajno boljša menjava, razlog pa je, da tunel vsili vrstni red, ki ga zaporedje zagona ne vidi.

Priklop ob zagonu proti samodejnemu priklopu

Priklop ob zagonu je preprosto razumeti. Cilj datotečnega sistema čaka na priklop, storitve, ki razglasijo odvisnost od njega, se zaženejo zatem, in če strežnik ni dosegljiv, stroj bodisi čaka bodisi spodleti glede na možnosti. Vse spodaj podeduje to eno odločitev.

Samodejni priklop to obrne. Pot obstaja takoj, pravi priklop se zgodi, ko jo nekaj odpre, in storitve, ki se zaženejo zgodaj, se ne ustavijo na tunelu, ki še ni dvignjen.

Primerjava se skrči na to, kdo naj bi vpojil zamudo. Delovna postaja, ki potrebuje skupno rabo, preden lahko uporabnik dela, bi verjetno morala počakati. Prenosnik, ki se zažene v torbi, ali strežnik, katerega skupna raba je neobvezna, ne bi smel.

Nobena možnost ne popravi manjkajoče poti. Obe le odločita, kdaj bo napaka opažena.

Vrstica fstab, možnost za možnostjo

Predpostavimo, da je obstoječa odjemalska instanca OpenVPN [email protected], strežnik files.corp.example in priklopna točka /mnt/work. Vse tri zamenjajte z dovoljenimi vrednostmi s svojega mesta. Ena delujoča vrstica je videti takole:

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

_netdev označi priklop kot tak, ki potrebuje omrežje, in ne imenuje nobenega tunela. nofail ohrani skupno rabo neobvezno za običajni cilj datotečnega sistema. x-systemd.automount ustvari sprožilec na zahtevo, namesto da bi priklopil takoj.

x-systemd.requires= je del, ki pripne poskus priklopa na enoto VPN, in spada k priklopni operaciji, ne k sprožilcu. Prav širok vrstni red na sami enoti samodejnega priklopa je način, kako ljudje ustvarijo cikle, zaradi katerih se systemd pozneje pritožuje v jeziku, ki ga nihče ne bere dvakrat.

x-systemd.mount-timeout=30s omeji začetni ukaz priklopa. Ne omeji ničesar, kar se zgodi pozneje, in to je najpogostejši nesporazum o tej možnosti.

Česa „zagnano“ ne pomeni

Preverite, kaj aktivno pomeni za enoto VPN, ki ste jo navedli. Storitev tunela se lahko prijavi kot zagnana, preden obstaja pot do datotečnega strežnika ali preden se razreši zasebno ime, in urejanje po njej vam takrat ne prinese ničesar. Prav v tej vrzeli živi skoraj vsak neuspešen poskus. Je tudi nevidna, razen če gledate na pot in razreševalnik namesto na stanje enote.

Uporabite lastni signal pripravljenosti lastnika povezave kot dodatni pogoj, kjer obstaja. Fiksno spanje je ugibanje, ki deluje na vaši mizi in spodleti v počasnejšem omrežju ali po ponovni povezavi.

Preglejte ustvarjene enote za pot iz primera: mnt-work.automount in mnt-work.mount. Po pregledani spremembi fstab znova naložite systemd in upravljajte te enote neposredno, namesto da bi zagnali splošen ukaz za priklop, ki vadi nepovezane vnose.

Sem spada še eno opozorilo. Storitev, ki se ob zagonu dotakne /mnt/work, še vedno sproži priklop in še vedno čaka nanj, zato označitev skupne rabe kot neobvezne ne naredi potrpežljive vsake aplikacije.

Po priklopu je to druga okvara

Ko je NFS priklopljen, vedenje datotečnega sistema pri ponovnem poskusu in obnovitvi določa, kaj poznejša prekinitev naredi z branjem ali pisanjem. Časovna omejitev priklopa, ki ste jo nastavili, na to ne vpliva.

Mehak priklop skrajša nekatera čakanja in spremeni pomen napak, s posledicami za celovitost podatkov, ki jih je ob hitrejšem zagonu zlahka spregledati. Izbrati ga, da bi pridobili dve sekundi zagona, je redkokdaj dobra menjava. Če je zahteva res omejena operacija med prekinitvijo, je to odločitev na ravni aplikacije, ne zastavica v fstab.

Odločite, kaj se mora zgoditi s procesom, ki je sredi pisanja, ko tunel pade, in to zapišite. Ta odgovor je bolj uporaben kot katerikoli niz možnosti.

Testirajte štiri stanja, ne enega

Običajen zagon z razpoložljivim tunelom je lahek primer in ne dokaže skoraj ničesar. Potrdi, da je niz pravilno zapisan, in nič več. Testirajte prvi dostop brez VPN, nato obnovitev, ko se dvigne, nato nadzorovano prekinitev po uspešnem priklopu.

Štiri stanja, štiri opažanja, in zapiski gredo poleg vnosa fstab. Naslednja oseba podeduje vedenje namesto konfiguracije, ki jo mora obrniti.