Treba li korisnička sesija posjedovati SSHFS montiranje preko VPN-a?

Montiranje dijeljenog foldera nakon podizanja VPN-a uključuje dva identiteta koja je lako pobrkati: komponentu kojoj je dopušteno konfigurirati mrežu i račun kojemu je dopušteno prijaviti se na datotečni poslužitelj. Rijetko su isti. VPN hook pod rootom loše je mjesto za početak SSHFS montiranja korisnika radne površine jer nema ni korisnikov agent ni namijenjeno vlasništvo montiranja. Ako se vlasništvo prvo ispravi, okidač postaje jednostavan.

Dva identiteta, dvije odvojene dozvole

VPN klijent treba privilegije za promjenu ruta i sučelja. SSHFS montiranje treba SSH identitet koji datotečni poslužitelj prihvaća i FUSE montiranje u vlasništvu računa koji će čitati datoteke. Jedna skripta pod rootom ispunjava prvi uvjet i tiho krši drugi.

Montiranje pod rootom ostavlja datoteke izvan sesije radne površine i vjerojatno bez pristupa agentu koji drži korisnikov ključ. Montiranje postoji, korisnik ne može pisati kroz njega, a kvar izgleda kao problem s dozvolama na strani poslužitelja. Ta pogrešna dijagnoza stoji jedno poslijepodne i tiket timu za pohranu.

Odlučite koji račun posjeduje montiranje prije pisanja bilo kakve automatizacije jer taj izbor određuje gdje okidač živi i kojim vjerodajnicama može pristupiti.

Najprije ručno uspostavite montiranje u vlasništvu korisnika

Pođite od prijavljenog korisnika s praznom točkom montiranja, ovlaštenim SSH računom i radnom putanjom do poslužitelja kroz tunel. Ručno montiranje uspostavlja osnovu koju svaka automatizacija mora reproducirati.

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

Imena su primjeri, pa zamijenite host i izvoznu putanju koje vaš poslužitelj stvarno nudi. Provjerite ključ hosta kroz odobreni postupak pri toj prvoj vezi. Imajte na umu da lozinka VPN računa nije automatski vjerodajnica računa za pohranu i to je čest uzrok neuspjelih pokušaja.

Pokrenite ga kao običan korisnik s točkom montiranja koju taj korisnik posjeduje. Prema zadanim postavkama samo račun koji montira dolazi do datoteka, a allow_other proširuje tu granicu na svakog lokalnog korisnika. To je namjerno proširenje pristupa, a ne zaobilazno rješenje za automatizaciju.

Neka okidač djeluje u istom kontekstu sesije

Neka podržana integracija VPN događaja zatraži pokretanje radnje korisničke sesije, umjesto da se pretpostavi da privilegirani callback može posuditi vjerodajnice radne površine. Ograničite okidač na namijenjeni identifikator veze, a ne na bilo koje sučelje koje se slučajno zove tun0. Pravilo dispečera koje odgovara pogrešnoj stvari aktivira se pri svakoj promjeni mreže, uključujući one koje nemaju nikakve veze s ovim montiranjem.

Radnja treba potvrditi očekivano ime hosta, primijetiti postojeće montiranje i napraviti jedan ograničen pokušaj. Petlja ankete koja pokreće novi SSHFS proces svakih nekoliko sekundi ili ponavlja upit za vjerodajnicama dok je poslužitelj nedostupan pretvara kratki prekid u hrpu zaglavljenih procesa. Ograničite pokušaj vremenskim ograničenjem i jednim ponovnim pokušajem.

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

Prva naredba daje identifikator veze koji dispečer treba upariti. Druge dvije pokazuju je li pokušaj već u tijeku, a to je provjera koja sprječava duplikate.

Nadzirana usluga treba vlastite odobrene vjerodajnice i vlastiti postupak provjere hosta u vlastitom kontekstu izvršavanja. Ne može pretpostaviti da je grafički agent otključan i ne smije ga pokušavati otključati.

Planirajte prekid prije nego što prisilite čišćenje

Za planirani prekid dovršite datotečne operacije i demontirajte iz vlastitog tijeka rada korisnika koji montira. Ciljajte točku montiranja, a ne proces, i potvrdite rezultat prije nego što izvijestite o uspjehu.

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

Demontirajte samo montiranje koje je stvorio ovaj tijek rada. Ako je zauzeto, to je odluka aplikacije: prisilno odvajanje koje postoji kako bi hook vratio uspjeh skriva gubitak podataka umjesto da ga spriječi.

Neočekivani gubitak ponaša se drukčije. SSHFS dokumentira da mrežni prekid može blokirati operaciju datotečnog sustava, a opcija reconnect vraća prijevoz bez vraćanja ručki: datoteka otvorena prije ponovnog povezivanja može pasti pri sljedećem pisanju, a prekinuto pisanje nije sačuvano. Ta razlika najviše znači uređivačima koji drže jednu datoteku otvorenom satima. Planirajte korak ponovnog otvaranja umjesto da pretpostavite oporavak.

Testirajte ponašanje s datotekama za jednokratnu upotrebu prije nego se na njega oslonite. Direktorij koji se ponovno pojavi nakon povratka tunela ne dokazuje da su ranije ručke ili nespremljeni rad preživjeli.