SSHFS-mounts hearre by de brûker, net by de VPN-heak
It rjocht om in ynterface op te heegjen is net it rjocht om in dielde map te mounten. Bewiis de mount fan de brûkerssesje mei de hân, en lit dan de trigger deselde kontekst freegje.
De oanname is maklik oan te nimmen en dreech te merken: in VPN-ferbiningheak draait as root, dus de mount dy't er start moat ek as root regele wurde. Dy redenaasje leveret in teammap dy't de buroblêdbrûker net iepenje kin, in mount dy't ferdwynt as de triggerstsjinst op 'e nij start, en in autentikaasjefraach yn in kontekst dêr't nimmen dy beantwurdzje kin. De heak en de mount binne twa ferskillende taken, en mar ien fan beide hat rjochten nedich.
De myte: netwurkrjochten betsjutte mountrjochten
In ynterface opheegje en by in bestânsserver autentisearje binne los fan elkoar steande fermogens, en se hearre meastentiids by ferskillende akkounts. De VPN-komponint hat genôch rjochten nedich om rûtes en ynterfaces te feroarjen. It akkount fan de bestânsserver hat in kaai of in wachtwurd, in beslút oer de hostkaai en in thúsmap nedich om yn te mounten. De ynloggegevens fan de twadde taak oan de earste identiteit jaan is hoe't in netwurkstsjinst einiget mei it bewarjen fan in kaai fan in brûker.
Op in laptop foar ien brûker kinne dat itselde akkount wêze, en dy tafal is gjin ûntwerp.
Sadree't in rjochtmjittige heak it mounten docht, geane trije dingen stil mis. De mount is eigendom fan root, de agent fan de brûker ûntbrekt yn dy omjouwing, en flaters ferskine yn it log fan de netwurkstsjinst ynstee fan yn de sesje dy't it oanbelanget. Net ien fan dy wurdt reparearre troch opsjes oan it mountkommando ta te foegjen. Se wurde reparearre troch de taak oan de sesje te jaan dy't de identiteit besit.
Wêrom't de mount by de oanmelde brûker heart
In SSHFS-mount is in FUSE-mount dy't eigendom is fan it proses dat him makke hat, en tagong folget dat eigendom ynstee fan de modus fan de âldermap. De referinsje advisearret in gewoane brûker mei in mountpunt dat dy brûker besit, en dat is krekt wêrom't in mount makke troch in root-proses ûnhandich is foar alle oaren. In rjochtenferoaring op it mountpunt reparearret it net, want it obstakel is de eigner fan de mount sels.
Begjin mei in hânmjittige basisline yn 'e sesje fan de brûker: in besteand leech mountpunt ûnder de thúsmap, in autorisearre akkount op de server, en in hostkaai dy't al ferifiearre is fia jo goedkarde proses. Mount him ien kear mei de hân en brûk him, want dat bewiist dat it identiteitspaad wurket foardat der hokker automisaasje dan ek is. Notearje wat it kommando nedich hie: de akkountnamme, it eksportpaad en de privee hostnamme. Behâld krekt dy kontekst foar de automatisearre ferzje, want in wurkjende hânmjittige mount is de spesifikaasje dy't de trigger reprodusearje moat.
sshfs [email protected]:/exports/team "$HOME/mnt/team"Behannelje elke namme en elk paad yn dy rigel as in plakferfanger, ynklusyf it akkount en de eksport. In wachtwurd foar in VPN-akkount is net automatysk de ynloggegevens fan it opslachakkount.
Wat de trigger de sesje freegje moat
De stipe regeling is in fersyk fan 'e netwurkbarren nei de sesje fan 'e brûker, net in liende ynloggegevens. Behein de trigger ta de ferbining dy't jo bedoele, by namme of UUID, ynstee fan ta elke ynterface dy't tafallich tun0 hjit. Dy iene feroaring stopet in twadde profyl, in testtunnel of de debugsesje fan in kollega om in mount te starten.
De aksje oan 'e sesjekant moat it bedoelde besteande mountpunt sykje en dan ien beheind besykjen dwaan.
Besykje net by elke polling op 'e nij, en freegje net troch om ynloggegevens wylst de server net berikber is, want beide meitsje fan in tydlike útfal in akkountsluting. In tsjinst sûnder tafersjoch is in apart ûntwerp mei syn eigen goedkarde ynloggegevens en eigen hostferifikaasje yn syn eigen útfieringskontekst, en kin net fertrouwe op it feit dat immen in grafyske agent ûntskoattele hat. Beslis hokker fan de beide jo bouwe foardat jo kieze wêr't de koade wennet. It measte fan de betizing hjir komt fan it bouwen fan 'e iene en it ferwachtsjen fan 'e oare.
Ferbrekke is in barren fan it bestânssysteem, net in barren fan 'e heak
In plande ferbrekking moat bestânsoperaasjes finishje en út 'e sesje fan de mountende brûker ôfmontje mei it stipe kommando foar dat soarte bestânssysteem. In ôfskieding twinge om in heak fluch weromkomme te litten is hoe't applikaasjes har wurkmap ferlieze en brûkers fertrouwen yn 'e automisaasje ferlieze. In beset mount hat in beslút op applikaasjenivo nedich, lykas it bestân slute of it skriuwen stopje, net in sterker sinjaal. De útgongstatus fan 'e heak is net it ding dat optimalisearre wurdt.
fusermount3 -u "$HOME/mnt/team"Unferwachte ferlies is in oar gefal, en SSHFS dokumintearret dat in ûnderbrutsen operaasje blokkearje kin wylst it transport wer ferbynt.
De werferbiningopsje herstelt it transport, en bestannen dy't foar dy werferbining iepene binne kinne noch flaters werombringe en moatte wer iepene wurde. In VPN dy't weromkomt bewiist neat oer eardere hânfetten of net-bewarre wurk. Kies it gedrach dat jo by in útfal wolle — pauze, in flater toane of mei opsetsin wer mounte — en test it mei ienmalige bestannen foardat eat dêrfan ôfhinget.