NFS sa likod ng VPN: mount sa pag-boot o automount kapag hiniling?

Dalawang configuration ang lumulutas sa parehong problema at nabigo sa magkasalungat na direksyon. Ang pag-mount ng share sa pag-boot ay nagbibigay sa bawat serbisyo ng filesystem na naroon o may dahilan kung bakit natigil ang boot. Ang automount kapag hiniling ay nagbibigay sa makina ng mabilis na boot at inililipat ang paghihintay sa unang makahawak sa path. Sa likod ng VPN, ang pangalawa ay karaniwang mas mabuting palitan, at ang dahilan ay ang tunnel ay nagpapataw ng pagkakasunod-sunod na hindi nakikita ng boot sequence.

Mount sa pag-boot kumpara sa automount

Ang mount sa pag-boot ay madaling isipin. Naghihintay ang target ng filesystem sa mount, ang mga serbisyong nagdedeklara ng dependency dito ay nagsisimula pagkatapos, at kung hindi maabot ang server, ang makina ay maghihintay o mabibigo depende sa mga opsyon. Lahat ng nasa ibaba ay nagmamana ng nag-iisang desisyong iyon.

Binabaligtad ito ng automount. Umiiral agad ang path, ang tunay na mount ay nangyayari kapag may nagbukas nito, at ang mga serbisyong nagsisimula nang maaga ay hindi nahaharang sa tunnel na hindi pa nakaupo.

Ang paghahambing ay bumababa sa kung sino ang dapat sumipsip ng pagkaantala. Ang workstation na nangangailangan ng share bago makapagtrabaho ang user ay dapat yatang maghintay. Ang laptop na nag-boot sa loob ng bag, o isang server na opsyonal ang share, ay hindi dapat.

Wala sa dalawang opsyon ang nag-aayos ng nawawalang ruta. Pareho lamang nilang pinagpapasyahan kung kailan mapapansin ang pagpalya.

Ang linya ng fstab, opsyon bawat opsyon

Ipagpalagay na ang umiiral na OpenVPN client instance ay [email protected], ang server ay files.corp.example at ang mount point ay /mnt/work. Palitan ang tatlo ng awtorisadong halaga mula sa sarili mong site. Ang isang gumaganang linya ay ganito ang hitsura:

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

Minarkahan ng _netdev ang mount bilang nangangailangan ng network, at hindi ito nagbabanggit ng anumang tunnel. Pinapanatili ng nofail ang share na opsyonal para sa normal na target ng filesystem. Lumilikha ang x-systemd.automount ng trigger kapag hiniling sa halip na agad na mag-mount.

Ang x-systemd.requires= ang bahaging nagtatali ng pagtatangkang mag-mount sa VPN unit, at kabilang ito sa operasyon ng mount, hindi sa trigger. Ang paglalagay ng malawak na pagkakasunod-sunod sa automount unit mismo ang paraan ng mga tao upang lumikha ng mga cycle na inirereklamo ng systemd mamaya sa wikang walang nagbabasa nang dalawang beses.

Nililimitahan ng x-systemd.mount-timeout=30s ang paunang mount command. Hindi nito nililimitahan ang anumang nangyayari pagkatapos, at iyon ang pinakakaraniwang maling akala tungkol sa opsyong ito.

Ano ang hindi ibig sabihin ng «nagsimula»

Suriin kung ano ang ibig sabihin ng aktibo para sa VPN unit na pinangalanan mo. Ang isang tunnel service ay maaaring mag-ulat na nagsimula na bago pa umiiral ang ruta patungo sa file server o bago maresolba ang pribadong pangalan, at ang pag-order pagkatapos nito ay wala nang mabibili sa iyo. Sa puwang na ito nakatira ang halos lahat ng nabigong pagtatangka. Ito rin ay hindi nakikita maliban kung titingnan mo ang ruta at ang resolver sa halip na ang estado ng unit.

Gamitin ang sariling signal ng pagiging handa ng may-ari ng koneksyon bilang karagdagang paunang kondisyon kung saan mayroon. Ang fixed sleep ay isang hula na gumagana sa iyong mesa at nabibigo sa mas mabagal na network o pagkatapos ng muling pagkonekta.

Suriin ang mga nabuong unit para sa path sa halimbawa: mnt-work.automount at mnt-work.mount. Pagkatapos ng nasuring pagbabago sa fstab, i-reload ang systemd at pamahalaan ang mga unit na iyon nang direkta sa halip na magpatakbo ng malawak na mount command na nagsasanay sa walang kaugnayang entry.

May isa pang paalala na kabilang dito. Ang serbisyong humahawak sa /mnt/work sa pagsisimula ay nagti-trigger pa rin ng mount at naghihintay pa rin dito, kaya ang pagmamarka ng share bilang opsyonal ay hindi ginagawang matiyaga ang bawat application.

Pagkatapos ng mount, ibang pagpalya ito

Kapag naka-mount na ang NFS, ang pag-uugali ng retry at recovery ng filesystem ang nagtatakda kung ano ang ginagawa ng susunod na pagkawala sa isang pagbasa o isang pagsulat. Ang timeout ng mount na itinakda mo ay walang impluwensya doon.

Ang soft mount ay nagpapaikli ng ilang paghihintay at nagbabago ng semantics ng error, na may mga kahihinatnan sa integridad ng data na madaling palampasin kapag ang layunin ay mas mabilis na boot. Ang piliin ito upang manalo ng dalawang segundo ng pagsisimula ay bihirang mabuting palitan. Kung ang pangangailangan ay tunay na limitadong operasyon sa panahon ng pagkawala, desisyon iyon sa antas ng application, hindi flag ng fstab.

Magpasya kung ano ang dapat mangyari sa isang prosesong nasa gitna ng pagsulat kapag bumagsak ang tunnel, at isulat ito. Ang sagot na iyon ay mas kapaki-pakinabang kaysa sa anumang string ng opsyon.

Subukan ang apat na estado, hindi isa

Ang normal na pag-boot na may tunnel na magagamit ay ang madaling kaso at halos wala itong pinapatunayan. Kinukumpirma lamang nito na ang string ay tama ang baybay at wala nang iba. Subukan ang unang pag-access na wala ang VPN, pagkatapos ang pagbangon kapag umangat ito, pagkatapos ang kontroladong pagkawala pagkatapos ng matagumpay na mount.

Apat na estado, apat na obserbasyon, at ang mga tala ay pumupunta sa tabi ng fstab entry. Ang susunod na tao ay nagmamana ng pag-uugali sa halip na configuration na kailangan niyang i-reverse engineer.