Ĉu la uzanta sesio posedu la SSHFS-muntadon tra VPN?

Munti komunan dosierujon post kiam la VPN ekfunkcias implicas du identecojn facile konfuzeblajn: la komponanto rajtigita agordi la reton, kaj la konto rajtigita ensaluti al la dosier-servilo. Ili malofte estas la sama. Roota VPN-hoko estas malbona loko por komenci la SSHFS-muntadon de labortabla uzanto, ĉar ĝi havas nek la agenton de la uzanto nek la celitan muntan posedon. Kiam la posedo estas unue ĝusta, la ellasilo fariĝas simpla.

Du identecoj, du apartaj permesoj

La VPN-kliento bezonas privilegiojn por ŝanĝi itinerojn kaj interfacojn. La SSHFS-muntado bezonas SSH-identecon akceptatan de la dosier-servilo kaj FUSE-muntadon posedatan de la konto, kiu legos la dosierojn. Unu skripto ruliĝanta kiel root plenumas la unuan postulon kaj silente rompas la duan.

Munti kiel root lasas la dosierojn ekster la labortabla sesio kaj eble sen aliro al la agento, kiu tenas la ŝlosilon de la uzanto. La muntado ekzistas, la uzanto ne povas skribi tra ĝi, kaj la fiasko aspektas kiel permesa problemo ĉe la servilo. Tiu misdiagnozo kostas posttagmezon kaj bileton al la stokada teamo.

Decidu, kiu konto posedas la muntadon, antaŭ ol skribi ajnan aŭtomatigon, ĉar tiu elekto difinas, kie loĝas la ellasilo kaj al kiuj akreditaĵoj ĝi povas atingi.

Unue starigu permane uzanto-posedatan muntadon

Komencu de ensalutinta uzanto kun malplena muntpunkto, rajtigita SSH-konto kaj funkcianta vojo al la servilo tra la tunelo. Permanenta muntado starigas la bazlinion, kiun ĉiu aŭtomatigo devas reprodukti.

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

La nomoj estas ekzemploj, do anstataŭigu la gastiganton kaj eksportan vojon, kiujn via servilo efektive proponas. Kontrolu la gastigantan ŝlosilon per la aprobita procezo ĉe tiu unua konekto. Notu, ke pasvorto de VPN-konto ne aŭtomate estas la akreditaĵo de la stokada konto, kaj tio estas ofta kaŭzo de malsukcesaj provoj.

Rulu ĝin kiel ordinara uzanto kun muntpunkto posedata de tiu uzanto. Defaŭlte nur la muntanta konto atingas la dosierojn, kaj allow_other vastigas tiun limon al ĉiu loka uzanto. Tio estas intenca vastigo de aliro, ne provizora solvo por aŭtomatigo.

Lasu la ellasilon agi en la sama sesia kunteksto

Lasu la subtenatan VPN-eventan integriĝon peti ruli uzanto-sesian agon, anstataŭ supozi, ke privilegiita callback povas prunti labortablan akreditaĵon. Limigu la ellasilon al la celita konekta identigilo anstataŭ al iu ajn interfaco hazarde nomata tun0. Dispeĉa regulo kongruanta kun la malĝusta afero ekbrulas ĉe ĉiu reta ŝanĝo, inkluzive de tiuj, kiuj havas nenion komunan kun ĉi tiu muntado.

La ago devus konfirmi la atendatan gastigantan nomon, rimarki ekzistantan muntadon kaj fari unu limigitan provon. Enket-buklo, kiu lanĉas novan SSHFS-procezon ĉiun kelkajn sekundojn, aŭ ripetas akreditaĵan peton dum la servilo estas mallevita, transformas mallongan interrompon en amason da ŝtopitaj procezoj. Limigu la provon per tempolimo kaj unu sola reprovo.

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

La unua komando donas la konektan identigilon, kiun la dispeĉo devus kongruigi. La aliaj du montras, ĉu provo jam ruliĝas, kaj tio estas la kontrolo, kiu malhelpas duplikatojn.

Neadministrata servo bezonas proprajn aprobitajn akreditaĵojn kaj propran gastigantan kontrolon en sia propra plenumkunteksto. Ĝi ne povas supozi, ke grafika agento estas malŝlosita, kaj ĝi ne devus provi malŝlosi unu.

Planu la malkonekton antaŭ ol devigi la purigadon

Por planita malkonekto, finu la dosierajn operaciojn kaj malmuntu el la propra laborfluo de la muntanta uzanto. Celu la muntpunkton anstataŭ la procezon, kaj konfirmu la rezulton antaŭ ol raporti sukceson.

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

Malmuntu nur la muntadon, kiun ĉi tiu laborfluo kreis. Se ĝi estas okupata, tio estas decido de la aplikaĵo: deviga apartigo, kiu ekzistas por igi hokon redoni sukceson, kaŝas datumperdon anstataŭ malhelpi ĝin.

Neatendita perdo kondutas alie. SSHFS dokumentas, ke reta interrompo povas bloki dosiersisteman operacion, kaj la opcio reconnect restarigas la transporton sen restarigi tenilojn: dosiero malfermita antaŭ la rekonekto povas fiaski ĉe la sekva skribo, kaj interrompita skribo ne konserviĝas. Tiu distingo plej gravas por redaktiloj, kiuj tenas unu dosieron malfermita dum horoj. Planu rean malferman paŝon anstataŭ supozi reakiron.

Testu la konduton per unuuzaj dosieroj antaŭ ol fidi ĝin. Dosierujo, kiu reaperas post kiam la tunelo revenas, ne pruvas, ke pli fruaj teniloj aŭ nekonservita laboro postvivis.