NFS bak ein VPN: montering ved oppstart eller automatisk montering ved behov?

To konfigurasjonar løyser same problemet og feilar i motsette retningar. Å montere delinga ved oppstart gjev kvar teneste eit filsystem som anten er der eller ein grunn til at oppstarten stogga. Ei automatisk montering ved behov gjev maskina ein rask oppstart og gjev ventinga vidare til den som først rører stien. Bak ein VPN er den andre som regel den beste handelen, og grunnen er at tunnelen pålegg ein rekkefølgje som oppstartssekvensen ikkje kan sjå.

Montering ved oppstart mot automatisk montering

Ei montering ved oppstart er enkel å tenkje gjennom. Filsystemmålet ventar på monteringa, tenester som erklærer avhengnad av henne startar etterpå, og viss tenaren ikkje er tilgjengeleg ventar maskina eller feilar avhengig av vala. Alt nedstraums arvar den eine avgjerda.

Ei automatisk montering snur dette. Stien finst med ein gong, den eigentlege monteringa skjer når noko opnar han, og tenester som startar tidleg blokkerer ikkje på ein tunnel som enno ikkje er oppe.

Samanlikninga handlar om kven som skal absorbere forseinkinga. Ein arbeidsstasjon som treng delinga før brukaren kan arbeide bør nok vente. Ein berbar PC som startar i ein bag, eller ein tenar der delinga er valfri, bør ikkje.

Ingen av vala reparerer ein manglande rute. Begge avgjer berre når feilen blir observert.

fstab-linja, val for val

Anta at ein eksisterande OpenVPN-klientinstans er [email protected], at tenaren er files.corp.example og at monteringspunktet er /mnt/work. Byt ut alle tre med dei autoriserte verdiane frå ditt eige anlegg. Éi brukbar linje ser slik ut:

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

_netdev merkjer monteringa som nettverkskrevjande, og ho nemner ingen tunnel i det heile. nofail held delinga valfri for det vanlege filsystemmålet. x-systemd.automount opprettar utløysaren ved behov i staden for å montere med ein gong.

x-systemd.requires= er delen som bind monteringsforsøket til VPN-eininga, og han høyrer til monteringsoperasjonen, ikkje til utløysaren. Å leggje brei rekkefølgje på sjølve den automatiske monteringseininga er måten folk lagar syklusar som systemd deretter klagar over på eit språk ingen les to gonger.

x-systemd.mount-timeout=30s avgrensar den innleiande monteringskommandoen. Han avgrensar ingenting som skjer etterpå, og det er den vanlegaste mistydinga om dette valet.

Kva «starta» ikkje tyder

Sjekk kva aktiv tyder for VPN-eininga du namngav. Ei tunnelteneste kan rapportere seg sjølv som starta før ruta til filtenaren finst eller før det private namnet blir løyst opp, og å sortere etter henne kjøper deg då ingenting. Det er i dette gapet nesten kvart mislukka forsøk bur. Det er også usynleg med mindre du ser på ruta og resolvaren i staden for tilstanden til eininga.

Bruk tilkoplingseigaren sitt eige paratheiheitssignal som ein ekstra føresetnad der eit finst. Ein fast søvn er eit gjetting som verkar på skrivebordet ditt og feilar på eit tregare nettverk eller etter ein gjentilkopling.

Undersøk dei genererte einingane for stien i dømet: mnt-work.automount og mnt-work.mount. Etter ei gjennomgått fstab-endring, last systemd på nytt og administrer desse einingane direkte i staden for å køyre ein brei monteringskommando som øvar på urelaterte oppføringar.

Ei åtvaring til høyrer heime her. Ei teneste som rører /mnt/work ved oppstart utløyser framleis monteringa og ventar framleis på henne, så å merkje delinga valfri gjer ikkje kvar applikasjon tolmodig.

Etter monteringa er det ein annan feil

Når NFS er montert, styrer gjenforskings- og gjenopprettingsåtferda til filsystemet kva eit seinare utfall gjer med ei lesing eller ei skriving. Monterings-tidsavbrotet du sette har inga innverknad på det.

Ei mjuk montering forkortar nokre ventingar og endrar feilsemantikken, med dataintegritetskonsekvensar som er lette å oversjå når målet er ein raskare oppstart. Å velje henne for å vinne to sekund av oppstarten er sjeldan ein god handel. Viss kravet verkeleg er ein avgrensa operasjon under eit utfall, er det ei avgjerd på applikasjonsnivå, ikkje eit fstab-flagg.

Avgjer kva som skal skje med ein prosess som er midt i ei skriving når tunnelen fell, og skriv det ned. Det svaret er meir nyttig enn kva som helst valstreng.

Test fire tilstandar, ikkje éin

Normal oppstart med tunnelen tilgjengeleg er det enkle tilfellet og beviser nesten ingenting. Det stadfester at strengen er stava rett, og ikkje meir. Test den første tilgangen utan VPN, deretter gjenopprettinga når han kjem opp, deretter eit kontrollert utfall etter ei vellukka montering.

Fire tilstandar, fire observasjonar, og notata går ved sida av fstab-oppføringa. Den neste personen arvar åtferd i staden for ein konfigurasjon dei må reversere.