NFS bag en VPN: montering ved opstart eller automatisk montering ved behov?

To konfigurationer løser det samme problem og fejler i modsatte retninger. Montering af delingen ved opstart giver hver tjeneste et filsystem, der enten er der, eller en grund til at opstarten gik i stå. En automatisk montering ved behov giver maskinen en hurtig opstart og giver ventetiden videre til den, der først rører stien. Bag en VPN er den anden som regel den bedste handel, og grunden er, at tunnelen pålægger en rækkefølge, som opstartssekvensen ikke kan se.

Montering ved opstart kontra automatisk montering

En montering ved opstart er nem at gennemskue. Filsystemmålet venter på monteringen, tjenester der erklærer afhængighed af den starter bagefter, og hvis serveren er utilgængelig, venter maskinen enten eller fejler afhængigt af indstillingerne. Alt nedstrøms arver den ene beslutning.

En automatisk montering vender det om. Stien findes med det samme, den egentlige montering sker, når noget åbner den, og tjenester der starter tidligt, blokerer ikke på en tunnel, der endnu ikke er oppe.

Sammenligningen handler om, hvem der skal absorbere forsinkelsen. En arbejdsstation, der har brug for delingen, før brugeren kan arbejde, bør sandsynligvis vente. En bærbar computer, der starter i en taske, eller en server, hvis deling er valgfri, bør ikke.

Ingen af mulighederne retter en manglende rute. Begge beslutter blot, hvornår fejlen observeres.

fstab-linjen, mulighed for mulighed

Antag, at en eksisterende OpenVPN-klientinstans er [email protected], at serveren er files.corp.example, og at monteringspunktet er /mnt/work. Erstat alle tre med de autoriserede værdier fra dit eget anlæg. En brugbar linje ser sådan ud:

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

_netdev markerer monteringen som havende brug for netværk, og den nævner ingen tunnel overhovedet. nofail holder delingen valgfri for det normale filsystemmål. x-systemd.automount opretter udløseren ved behov i stedet for at montere med det samme.

x-systemd.requires= er den del, der binder monteringsforsøget til VPN-enheden, og den hører til monteringshandlingen snarere end til udløseren. At sætte bred rækkefølge på selve den automatiske monteringsenhed er måden, hvorpå folk skaber cyklusser, som systemd derefter klager over på et sprog, ingen læser to gange.

x-systemd.mount-timeout=30s begrænser den indledende monteringskommando. Det begrænser intet, der sker bagefter, og det er den mest udbredte misforståelse om denne mulighed.

Hvad »startet« ikke betyder

Kontroller, hvad aktiv betyder for den VPN-enhed, du navngav. En tunneltjeneste kan rapportere sig selv som startet, før ruten til filserveren findes, eller før det private navn opløses, og at sortere efter den køber dig intet. Det er i dette hul, næsten ethvert mislykket forsøg lever. Det er også usynligt, medmindre du ser på ruten og resolveren i stedet for enhedens tilstand.

Brug forbindelsesejerens eget parathedssignal som en ekstra forudsætning, hvor et findes. En fast søvn er et gæt, der virker på dit skrivebord og fejler på et langsommere netværk eller efter en genopkobling.

Undersøg de genererede enheder for stien i eksemplet: mnt-work.automount og mnt-work.mount. Efter en gennemgået fstab-ændring skal du genindlæse systemd og styre disse enheder direkte i stedet for at køre en bred monteringskommando, der øver uvedkommende poster.

En advarsel mere hører til her. En tjeneste, der rører /mnt/work ved opstart, udløser stadig monteringen og venter stadig på den, så en valgfri deling gør ikke enhver applikation tålmodig.

Efter monteringen er det en anden fejl

Når NFS er monteret, bestemmer filsystemets genforsøgs- og gendannelsesadfærd, hvad et senere udfald gør ved en læsning eller en skrivning. Den monteringstimeout, du har sat, har ingen indflydelse på det.

En blød montering forkorter nogle ventetider og ændrer fejlsemantikken, med dataintegritetskonsekvenser, der er nemme at overse, når målet er en hurtigere opstart. At vælge den for at vinde to sekunders opstart er sjældent en god handel. Hvis kravet virkelig er en afgrænset operation under et udfald, er det en beslutning på applikationsniveau, ikke et fstab-flag.

Beslut, hvad der skal ske med en proces, der er midt i en skrivning, når tunnelen falder, og skriv det ned. Det svar er mere brugbart end enhver mulighedsstreng.

Test fire tilstande, ikke én

Normal opstart med tunnelen tilgængelig er det nemme tilfælde og beviser næsten intet. Det bekræfter, at strengen er stavet rigtigt, og ikke mere. Test den første adgang uden VPN, derefter gendannelsen, når den kommer op, derefter et kontrolleret udfald efter en vellykket montering.

Fire tilstande, fire observationer, og noterne går ved siden af fstab-posten. Den næste person arver adfærd i stedet for en konfiguration, de skal reverse engineering på.