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

To konfigurasjoner løser samme problem og feiler i motsatte retninger. Å montere delingen ved oppstart gir hver tjeneste et filsystem som enten er der eller en grunn til at oppstarten stoppet. En automatisk montering ved behov gir maskinen en rask oppstart og gir ventingen videre til den som først berører stien. Bak en VPN er den andre som regel den beste handelen, og grunnen er at tunnelen pålegger en rekkefølge som oppstartssekvensen ikke kan se.

Montering ved oppstart mot automatisk montering

En montering ved oppstart er enkel å tenke gjennom. Filsystemmålet venter på monteringen, tjenester som erklærer avhengighet av den starter etterpå, og hvis serveren ikke er tilgjengelig venter maskinen eller feiler avhengig av valgene. Alt nedstrøms arver den ene beslutningen.

En automatisk montering snur dette. Stien finnes med en gang, den egentlige monteringen skjer når noe åpner den, og tjenester som starter tidlig blokkerer ikke på en tunnel som ennå ikke er oppe.

Sammenligningen handler om hvem som skal absorbere forsinkelsen. En arbeidsstasjon som trenger delingen før brukeren kan arbeide bør nok vente. En bærbar PC som starter i en bag, eller en server hvis deling er valgfri, bør ikke.

Ingen av valgene reparerer en manglende rute. Begge bestemmer bare når feilen blir observert.

fstab-linjen, valg for valg

Anta at en eksisterende OpenVPN-klientinstans er [email protected], at serveren er files.corp.example og at monteringspunktet er /mnt/work. Erstatt alle tre med de autoriserte verdiene fra ditt eget anlegg. Én 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 merker monteringen som nettverkskrevende, og den navngir ingen tunnel i det hele tatt. nofail holder delingen valgfri for det vanlige filsystemmålet. x-systemd.automount oppretter utløseren ved behov i stedet for å montere med en gang.

x-systemd.requires= er delen som binder monteringsforsøket til VPN-enheten, og den hører til monteringsoperasjonen, ikke til utløseren. Å legge bred rekkefølge på selve den automatiske monteringsenheten er måten folk lager sykluser som systemd deretter klager over på et språk ingen leser to ganger.

x-systemd.mount-timeout=30s begrenser den innledende monteringskommandoen. Den begrenser ingenting som skjer etterpå, og det er den vanligste misforståelsen om dette valget.

Hva «startet» ikke betyr

Sjekk hva aktiv betyr for VPN-enheten du navnga. En tunneltjeneste kan rapportere seg selv som startet før ruten til filserveren finnes eller før det private navnet løses opp, og å sortere etter den kjøper deg da ingenting. Det er i dette gapet nesten hvert mislykkede forsøk bor. Det er også usynlig med mindre du ser på ruten og resolveren i stedet for enhetens tilstand.

Bruk tilkoblingseierens eget parathetdssignal som en ekstra forutsetning der et finnes. En fast søvn er en gjetning som virker på skrivebordet ditt og feiler på et tregere nettverk eller etter en gjentilkobling.

Undersøk de genererte enhetene for stien i eksempelet: mnt-work.automount og mnt-work.mount. Etter en gjennomgått fstab-endring, last systemd på nytt og administrer disse enhetene direkte i stedet for å kjøre en bred monteringskommando som øver på urelaterte oppføringer.

En advarsel til hører hjemme her. En tjeneste som berører /mnt/work ved oppstart utløser fortsatt monteringen og venter fortsatt på den, så å merke delingen valgfri gjør ikke hver applikasjon tålmodig.

Etter monteringen er det en annen feil

Når NFS er montert, styrer filsystemets gjenforsøks- og gjenopprettingsatferd hva et senere utfall gjør med en lesing eller en skriving. Monterings-tidsavbruddet du satte har ingen innflytelse på det.

En myk montering forkorter noen ventinger og endrer feilsemantikken, med dataintegritetskonsekvenser som er lette å overse når målet er en raskere oppstart. Å velge den for å vinne to sekunder oppstart er sjelden en god handel. Hvis kravet virkelig er en avgrenset operasjon under et utfall, er det en beslutning på applikasjonsnivå, ikke et fstab-flagg.

Bestem hva som skal skje med en prosess som er midt i en skriving når tunnelen faller, og skriv det ned. Det svaret er mer nyttig enn hvilken som helst valgstreng.

Test fire tilstander, ikke én

Normal oppstart med tunnelen tilgjengelig er det enkle tilfellet og beviser nesten ingenting. Det bekrefter at strengen er stavet riktig, og ikke mer. Test den første tilgangen uten VPN, deretter gjenopprettingen når den kommer opp, deretter et kontrollert utfall etter en vellykket montering.

Fire tilstander, fire observasjoner, og notatene går ved siden av fstab-oppføringen. Den neste personen arver atferd i stedet for en konfigurasjon de må reversere.