NFS efter in VPN: mount by it opstarten of automatysk mount op oanfraach?

Twa konfiguraasjes lossen itselde probleem op en mislearje yn tsjinoerstelde rjochtingen. De diele by it opstarten mounte jout elke tsjinst in bestânsysteem dat óf der is óf in reden wêrom’t it opstarten stûke. In automatyske mount op oanfraach jout de masine in fluch opstarten en jout it wachtsjen oan wa’t it paad as earste oanrekket. Efter in VPN is it twadde meastentiids de bettere ruil, en de reden is dat de tunnel in oarder oplizze dy’t de opstartsekwinsje net sjen kin.

Mount by it opstarten tsjin automatyske mount

In mount by it opstarten is maklik te berêden. It bestânsysteem-doel wachtet op de mount, tsjinsten dy’t in ôfhinklikens dêrfan ferklearje starte dêrnei, en as de tsjinner net berikber is wachtet de masine of mislearret it neffens de opsjes. Alles wat dêrnei komt erft dy iene beslissing.

In automatyske mount keart dat om. It paad bestiet fuort, de echte mount bart as eat it iepenet, en tsjinsten dy’t betiid starte blokkearje net op in tunnel dy’t noch net omheech is.

De fergeliking komt del op wa’t de fertraging absorbearje moat. In wurkstasjon dat de diele nedich hat foardat de brûker wurkje kin soe wierskynlik wachtsje moatte. In laptop dy’t yn in tas opstartet, of in tsjinner waans diele opsjoneel is, soe dat net moatte.

Gjin fan beide opsjes reparearret in ûntbrekkende rûte. Beide beslisse gewoan wannear’t de flater waarnommen wurdt.

De fstab-rigel, opsje foar opsje

Stel dat in besteande OpenVPN-kliïnteksimplaar [email protected] is, de tsjinner files.corp.example en it mountpunt /mnt/work. Ferfange alle trije troch de autorisearre wearden fan jo eigen side. Ien wurkjende rigel sjocht der sa út:

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

_netdev markearret de mount as ien dy’t netwurk nedich hat, en it neamt hielendal gjin tunnel. nofail hâldt de diele opsjoneel foar it gewoane bestânsysteem-doel. x-systemd.automount makket de trigger op oanfraach yn plak fan fuortendaliks te mounten.

x-systemd.requires= is it part dat de mountpoging oan de VPN-ienheid bynt, en it heart by de mount-operaasje yn plak fan by de trigger. In brede oarder op de automatyske mount-ienheid sels sette is hoe’t minsken syklussen meitsje dêr’t systemd dan oer klaget yn in taal dy’t nimmen twa kear lêst.

x-systemd.mount-timeout=30s beheint it earste mountkommando. It beheint neat wat dêrnei bart, en dat is it meast foarkommende misferstân oer dizze opsje.

Wat ‘start’ net betsjut

Kontrolearje wat aktyf wêze betsjut foar de VPN-ienheid dy’t jo neamden. In tunfeltsjinst kin himsels as start rapporteare foardat de rûte nei de bestânstsjinner bestiet of foardat de priveenamme oplost, en dêrnei oarderje leveret jo dan neat op. Yn dizze kleau libbet hast elke mislearre poging. It is ek ûnsichtber, útsein as jo nei de rûte en de oplosser sjogge yn plak fan de steat fan de ienheid.

Brûk it eigen gereedheidssinjaal fan de ferbinings-eigner as ekstra betingst dêr’t ien bestiet. In fêste sliep is in gissing dy’t op jo buro wurket en mislearret op in stadiger netwurk of nei in opnij ferbinen.

Undersykje de generearre ienheden foar it foarbyldpaad: mnt-work.automount en mnt-work.mount. Nei in neisjoene fstab-wiziging, herlaad systemd en behear dy ienheden direkt yn plak fan in brede mountkommando te draaien dat net-relatearre ynfieringen oefenet.

Hjir heart noch ien warskôging. In tsjinst dy’t by it opstarten /mnt/work oanrekket, aktivearret noch altyd de mount en wachtet der noch altyd op, dus de diele opsjoneel markearje makket net elke applikaasje geduldich.

Nei de mount is it in oare flater

Sadree’t NFS monteare is, bepaalt it weromsykjen en herstelgedrach fan it bestânsysteem wat in lettere útfal docht mei in lêzen of in skriuwen. De mount-timeout dy’t jo ynsteld hawwe hat dêr gjin ynfloed op.

In sêfte mount ferkoartet guon wachtsjen en feroaret de semantyk fan flaters, mei gefolgen foar gegevensyntegriteit dy’t maklik oersjoen wurde as it doel in flugger opstarten is. It kieze om twa sekonden opstarten te winnen is selden in goede ruil. As de eask echt in beheinde operaasje by in útfal is, dan is dat in beslissing op applikaasjenivo, net in fstab-flagge.

Beslis wat der barre moat mei in proses dat midden yn in skriuwen sit as de tunnel falt, en skriuw it op. Dat antwurd is nuttiger as hokker opsjerige dan ek.

Test fjouwer steaten, net ien

Normaal opstarten mei de tunnel beskikber is it maklike gefal en bewissiget hast neat. It befêstiget dat de rigel goed stavere is en net mear. Test de earste tagong sûnder de VPN, dan it herstel as er omheech komt, dan in kontrolearre útfal nei in slagge mount.

Fjouwer steaten, fjouwer waarnimmings, en de notysjes geane njonken de fstab-ynfiering. De folgjende persoan erft gedrach yn plak fan in konfiguraasje dy’t hy weromûntwerpe moat.