NFS malantaŭ VPN: muntado ĉe ekŝargo aŭ aŭtomuntado laŭmende?

Du agordoj solvas la saman problemon kaj malsukcesas en kontraŭaj direktoj. Munti la kunhavon ĉe ekŝargo donas al ĉiu servo dosiersistemon, kiu aŭ ekzistas aŭ klarigas, kial la ekŝargo haltis. Aŭtomuntado laŭmende donas al la maŝino rapidan ekŝargon kaj transdonas la atendo al tiu, kiu unue tuŝos la vojon. Malantaŭ VPN la dua estas kutime la pli bona interŝanĝo, kaj la kialo estas, ke la tunelo trudas ordon, kiun la ekŝarga sinsekvo ne povas vidi.

Muntado ĉe ekŝargo kontraŭ aŭtomuntado

Muntado ĉe ekŝargo estas facila pripensi. La dosiersistema celo atendas la muntadon, servoj, kiuj deklaras dependecon de ĝi, startas poste, kaj se la servilo neatingeblas, la maŝino aŭ atendas aŭ malsukcesas laŭ la opcioj. Ĉio malsupra heredas tiun ununuran decidon.

Aŭtomuntado inversigas tion. La vojo ekzistas tuj, la reala muntado okazas kiam io malfermas ĝin, kaj servoj, kiuj startas frue, ne blokiĝas sur tunelo, kiu ankoraŭ ne leviĝis.

La komparo reduktiĝas al tio, kiu devus sorbigi la prokraston. Laborejo, kiu bezonas la kunhavon antaŭ ol la uzanto povas labori, verŝajne devus atendi. Tekkomputilo, kiu ekŝargas en sako, aŭ servilo, kies kunhavo estas laŭvola, ne devus.

Neniu el la du opcioj riparas mankan vojon. Ambaŭ simple decidas, kiam la fiasko estos observata.

La fstab-linio, opcio post opcio

Supozu, ke ekzistanta klienta kazo de OpenVPN estas [email protected], la servilo estas files.corp.example kaj la muntopunkto estas /mnt/work. Anstataŭigu ĉiujn tri per la rajtigitaj valoroj de via propra ejo. Unu funkcianta linio aspektas tiel:

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

_netdev markas la muntadon kiel bezonantan reton, kaj ĝi nomas neniun tunelon. nofail tenas la kunhavon laŭvola por la normala dosiersistema celo. x-systemd.automount kreas la laŭmendan ellasilon anstataŭ tuj munti.

x-systemd.requires= estas la parto, kiu ligas la muntan provon al la VPN-unuo, kaj ĝi apartenas al la munta operacio, ne al la ellasilo. Meti vastan ordon sur la aŭtomuntan union mem estas kiel homoj kreas ciklojn, pri kiuj systemd poste plendas en lingvo, kiun neniu legas dufoje.

x-systemd.mount-timeout=30s limigas la komencan muntan komandon. Ĝi limigas nenion, kio okazas poste, kaj tio estas la plej ofta miskompreno pri ĉi tiu opcio.

Kion «startinta» ne signifas

Kontrolu, kion aktiva signifas por la VPN-unuo, kiun vi nomis. Tunela servo povas raporti sin kiel startinta antaŭ ol ekzistas la vojo al la dosieruja servilo aŭ antaŭ ol solviĝas la privata nomo, kaj ordigi post ĝi tiam aĉetas al vi nenion. En tiu breĉo loĝas preskaŭ ĉiu malsukcesa provo. Ĝi ankaŭ estas nevidebla, se vi ne rigardas la vojon kaj la solvilon anstataŭ la staton de la unuo.

Uzu la propran pretecan signalon de la posedanto de la konekto kiel plian antaŭkondiĉon, kie ĝi ekzistas. Fiksa dormo estas konjekto, kiu funkcias sur via tablo kaj malsukcesas sur pli malrapida reto aŭ post rekonekto.

Ekzamenu la generitajn unuojn por la vojo en la ekzemplo: mnt-work.automount kaj mnt-work.mount. Post reviziita ŝanĝo de fstab, reŝargu systemd kaj administru tiujn unuojn rekte anstataŭ lanĉi vastan muntan komandon, kiu ekzercas ne rilatajn enskribojn.

Ankoraŭ unu averto apartenas ĉi tie. Servo, kiu tuŝas /mnt/work ĉe starto, ankoraŭ elvokas la muntadon kaj ankoraŭ atendas ĝin, do marki la kunhavon laŭvola ne igas ĉiun aplikaĵon pacienca.

Post la muntado temas pri alia fiasko

Post kiam NFS estas muntita, la ripeta kaj reakira konduto de la dosiersistemo regas, kion posta interrompo faras al legado aŭ skribado. La munta tempolimo, kiun vi agordis, havas neniun influon al tio.

Mola muntado mallongigas kelkajn atendojn kaj ŝanĝas la semantikon de eraroj, kun sekvoj por datumintegro, kiujn oni facile preteratentas, kiam la celo estas pli rapida ekŝargo. Elekti ĝin por gajni du sekundojn da starto malofte estas bona interŝanĝo. Se la postulo vere estas limigita operacio dum interrompo, tio estas decido je aplika nivelo, ne fstab-flago.

Decidu, kio devus okazi al procezo, kiu estas meze de skribado, kiam la tunelo falas, kaj skribu ĝin. Tiu respondo pli utilas ol iu ajn opcia ĉeno.

Testu kvar statojn, ne unu

Normala starto kun havebla tunelo estas la facila kazo kaj pruvas preskaŭ nenion. Ĝi konfirmas, ke la ĉeno estas ĝuste literumita, kaj nenion pli. Testu la unuan aliron kun la VPN forestanta, poste la reakiron kiam ĝi leviĝas, poste kontrolitan interrompon post sukcesa muntado.

Kvar statoj, kvar observoj, kaj la notoj iras apud la fstab-enskribo. La sekva persono heredas konduton anstataŭ agordon, kiun ĝi devas retroinĝenieri.