Moet de gebruikerssessie de SSHFS-mount over VPN bezitten?

Het mounten van een gedeelde map nadat de VPN omhoogkomt, omvat twee identiteiten die gemakkelijk te verwarren zijn: het onderdeel dat het netwerk mag configureren, en het account dat mag inloggen op de fileserver. Ze zijn zelden hetzelfde. Een root-eigen VPN-hook is een slechte plek om de SSHFS-mount van een desktopgebruiker te starten, omdat hij noch de agent van de gebruiker noch het bedoelde mount-eigenaarschap heeft. Als het eigenaarschap eerst goed is, wordt de trigger eenvoudig.

Twee identiteiten, twee aparte machtigingen

De VPN-client heeft privileges nodig om routes en interfaces te wijzigen. De SSHFS-mount heeft een SSH-identiteit nodig die de fileserver accepteert en een FUSE-mount die eigendom is van het account dat de bestanden leest. Eén script dat als root draait, voldoet aan de eerste eis en breekt stilletjes de tweede.

Mounten als root laat de bestanden buiten de desktopsessie en mogelijk zonder toegang tot de agent die de sleutel van de gebruiker bewaart. De mount bestaat, de gebruiker kan er niet doorheen schrijven, en de fout lijkt op een machtigingsprobleem aan de serverkant. Die verkeerde diagnose kost een middag en een ticket aan het storage-team.

Bepaal welk account de mount bezit voordat je enige automatisering schrijft, want die keuze bepaalt waar de trigger woont en welke inloggegevens hij kan bereiken.

Stel eerst met de hand een gebruikerseigen mount in

Begin met een aangemelde gebruiker met een leeg mountpunt, een geautoriseerd SSH-account en een werkend pad naar de server via de tunnel. Een handmatige mount legt de basis vast die elke automatisering moet reproduceren.

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

De namen zijn voorbeelden, dus vervang de host en het exportpad die je server werkelijk biedt. Verifieer de hostsleutel via het goedgekeurde proces bij die eerste verbinding. Merk op dat een VPN-accountwachtwoord niet automatisch de inloggegevens van het storage-account zijn, en dat is een veelvoorkomende oorzaak van mislukte pogingen.

Voer het uit als een gewone gebruiker met een mountpunt dat die gebruiker bezit. Standaard bereikt alleen het account dat mount de bestanden, en allow_other verbreedt die grens naar elke lokale gebruiker. Dat is een bewuste verbreding van toegang, geen omweg voor automatisering.

Laat de trigger in dezelfde sessiecontext handelen

Laat de ondersteunde VPN-gebeurtenisintegratie vragen om een actie van de gebruikerssessie uit te voeren, in plaats van aan te nemen dat een bevoorrechte callback desktop-inloggegevens kan lenen. Beperk de trigger tot de bedoelde verbindingsidentificatie en niet tot elke interface die toevallig tun0 heet. Een dispatcher-regel die op het verkeerde past, wordt bij elke netwerkwijziging geactiveerd, ook bij wijzigingen die niets met deze mount te maken hebben.

De actie moet de verwachte hostnaam bevestigen, een bestaande mount opmerken en één begrensde poging doen. Een polllus die elke paar seconden een nieuw SSHFS-proces start, of een inloggegevensprompt herhaalt terwijl de server plat ligt, verandert een korte storing in een berg vastgelopen processen. Begrens de poging met een time-out en één nieuwe poging.

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

De eerste opdracht geeft de verbindingsidentificatie die de dispatcher moet matchen. De andere twee tonen of er al een poging loopt, en dat is de controle die duplicaten voorkomt.

Een onbeheerde service heeft zijn eigen goedgekeurde inloggegevens en zijn eigen hostverificatie in zijn eigen uitvoeringscontext nodig. Hij kan niet aannemen dat een grafische agent ontgrendeld is, en hij mag er geen proberen te ontgrendelen.

Plan de ontkoppeling voordat je de opruiming forceert

Voltooi voor een geplande ontkoppeling de bestandsbewerkingen en ontkoppel vanuit de eigen workflow van de mountende gebruiker. Richt je op het mountpunt in plaats van het proces, en bevestig het resultaat voordat je succes meldt.

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

Ontkoppel alleen de mount die deze workflow heeft gemaakt. Als hij bezet is, is dat een beslissing van de toepassing: een geforceerde ontkoppeling die bestaat om een hook succes te laten teruggeven, verbergt gegevensverlies in plaats van het te voorkomen.

Onverwacht verlies gedraagt zich anders. SSHFS documenteert dat een netwerkonderbreking een bestandssysteembewerking kan blokkeren, en de optie reconnect herstelt het transport zonder handles te herstellen: een bestand dat vóór de herverbinding is geopend, kan bij de volgende schrijfbewerking mislukken, en een onderbroken schrijfbewerking blijft niet bewaard. Dat onderscheid is het belangrijkst voor editors die één bestand urenlang open houden. Plan een stap voor opnieuw openen in plaats van herstel aan te nemen.

Test het gedrag met wegwerpbestanden voordat je erop vertrouwt. Een map die weer verschijnt nadat de tunnel terugkomt, bewijst niet dat eerdere handles of niet-opgeslagen werk hebben overleefd.