Skal brugersessionen eje SSHFS-monteringen over VPN?

Montering af en delt mappe, efter at VPN'en er oppe, involverer to identiteter, som er lette at forveksle: den komponent, der må konfigurere netværket, og den konto, der må logge ind på fileserveren. De er sjældent den samme. Et root-ejet VPN-hook er et dårligt sted at starte en skrivebordsbrugers SSHFS-montering, fordi det hverken har brugerens agent eller det tilsigtede monteringsejerskab. Når ejerskabet først er rigtigt, bliver udløseren enkel.

To identiteter, to adskilte tilladelser

VPN-klienten har brug for privilegier til at ændre ruter og grænseflader. SSHFS-monteringen har brug for en SSH-identitet, som fileserveren accepterer, og en FUSE-montering, der ejes af den konto, som skal læse filerne. Ét script, der kører som root, opfylder det første krav og bryder stiltiende det andet.

Montering som root efterlader filerne uden for skrivebordssessionen og muligvis uden adgang til den agent, der holder brugerens nøgle. Moneringen findes, brugeren kan ikke skrive igennem den, og fejlen ligner et tilladelsesproblem på serversiden. Den fejldiagnose koster en eftermiddag og en billet til storage-teamet.

Beslut, hvilken konto der ejer monteringen, før du skriver nogen automatisering, fordi det valg bestemmer, hvor udløseren bor, og hvilke legitimationsoplysninger den kan nå.

Opret først en brugerejet montering manuelt

Start med en logget bruger med et tomt monteringspunkt, en autoriseret SSH-konto og en fungerende sti til serveren gennem tunnelen. En manuel montering fastlægger den baseline, som enhver automatisering skal genskabe.

mkdir -p "$HOME/mnt/team"
sshfs [email protected]:/exports/team "$HOME/mnt/team"
mount | grep sshfs

Navnene er eksempler, så erstat det værtsnavn og den eksportsti, som din server faktisk tilbyder. Bekræft værtsnøglen gennem den godkendte proces ved den første forbindelse. Bemærk, at en VPN-kontoadgangskode ikke automatisk er storage-kontoens legitimationsoplysninger, og det er en almindelig årsag til mislykkede forsøg.

Kør det som en almindelig bruger med et monteringspunkt, som den bruger ejer. Som standard er det kun den konto, der monterer, der når filerne, og allow_other udvider den grænse til alle lokale brugere. Det er en bevidst udvidelse af adgangen, ikke en omvej til automatisering.

Lad udløseren handle i samme sessionskontekst

Lad den understøttede VPN-begivenhedsintegration bede om at køre en handling i brugersessionen i stedet for at antage, at et privilegeret callback kan låne en skrivebordslegitimationsoplysning. Begræns udløseren til den tilsigtede forbindelsesidentifikator i stedet for til enhver grænseflade, der tilfældigvis hedder tun0. En dispatcher-regel, der matcher det forkerte, udløses ved enhver netværksændring, også dem der intet har at gøre med denne montering.

Handlingen bør bekræfte det forventede værtsnavn, bemærke en eksisterende montering og gøre ét begrænset forsøg. En afspørringsløkke, der starter en ny SSHFS-proces hvert par sekunder, eller gentager en legitimationsanmodning, mens serveren er nede, forvandler en kort afbrydelse til en bunke fastlåste processer. Begræns forsøget med en timeout og et enkelt nyt forsøg.

nmcli -g UUID connection show --active
systemctl --user list-units 'sshfs*'
pgrep -a sshfs

Den første kommando giver den forbindelsesidentifikator, som dispatcheren skal matche. De to andre viser, om et forsøg allerede kører, og det er kontrollen, der forhindrer dubletter.

En uovervåget tjeneste har brug for sine egne godkendte legitimationsoplysninger og sin egen værtsbekræftelse i sin egen udførelseskontekst. Den kan ikke antage, at en grafisk agent er oplåst, og den bør ikke forsøge at låse en op.

Planlæg afbrydelsen, før du tvinger oprydningen

Ved en planlagt afbrydelse skal du afslutte filoperationerne og afmontere fra den monterende brugers eget arbejdsforløb. Ret dig mod monteringspunktet i stedet for processen, og bekræft resultatet, før du rapporterer succes.

fusermount3 -u "$HOME/mnt/team"
mountpoint "$HOME/mnt/team"

Afmontér kun den montering, som dette arbejdsforløb har oprettet. Hvis den er optaget, er det en beslutning i programmet: en tvungen afkobling, der findes for at få et hook til at returnere succes, skjuler datatab i stedet for at forhindre det.

Uventet tab opfører sig anderledes. SSHFS dokumenterer, at en netværksafbrydelse kan blokere en filsystemoperation, og reconnect-indstillingen genskaber transporten uden at genskabe handles: en fil, der blev åbnet før genopkoblingen, kan fejle ved den næste skrivning, og en afbrudt skrivning bevares ikke. Den forskel betyder mest for editorer, der holder én fil åben i timer. Planlæg et trin med genåbning i stedet for at antage gendannelse.

Test adfærden med engangsfiler, før du stoler på den. En mappe, der dukker op igen, efter at tunnelen vender tilbage, beviser ikke, at tidligere handles eller ikke-gemt arbejde overlevede.