Дали корисничката сесија треба да го поседува SSHFS монтирањето преку VPN?

Монтирањето на споделена папка откако VPN ќе се подигне вклучува два идентитета што лесно се мешаат: компонентата што смее да ја конфигурира мрежата и сметката што смее да се најави на серверот за датотеки. Тие ретко се исти. Root VPN кука е лошо место за почеток на SSHFS монтирање на десктоп корисник, бидејќи нема ниту агент на корисникот ниту предвиденото сопственост на монтирањето. Ако сопственоста прво се постави правилно, тригерот станува едноставен.

Два идентитета, две одделни дозволи

VPN клиентот бара привилегии за менување рути и интерфејси. SSHFS монтирањето бара SSH идентитет што серверот за датотеки го прифаќа и FUSE монтирање во сопственост на сметката што ќе ги чита датотеките. Една скрипта што работи како root го исполнува првиот услов и тивко го крши вториот.

Монтирањето како root ги остава датотеките надвор од десктоп сесијата и можеби без пристап до агентот што го чува клучот на корисникот. Монтирањето постои, корисникот не може да пишува преку него, а дефектот изгледа како проблем со дозволи на страната на серверот. Таа погрешна дијагноза чини попладне и тикет до тимот за складирање.

Одлучете која сметка го поседува монтирањето пред да напишете каква било автоматизација, бидејќи тој избор одредува каде живее тригерот и до кои акредитиви може да стигне.

Прво рачно воспоставете монтирање во сопственост на корисникот

Започнете од најавен корисник со празна точка на монтирање, овластена SSH сметка и работна патека до серверот преку тунелот. Рачното монтирање ја поставува основата што секоја автоматизација мора да ја репродуцира.

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

Имињата се примери, затоа заменете ги хостот и извозната патека што вашиот сервер навистина ги нуди. Проверете го клучот на хостот преку одобрениот процес при таа прва врска. Имајте на ум дека лозинката на VPN сметката не е автоматски акредитив на сметката за складирање и тоа е честа причина за неуспешни обиди.

Извршете го како обичен корисник со точка на монтирање што ја поседува тој корисник. Стандардно само сметката што монтира стигнува до датотеките, а allow_other ја проширува таа граница на секој локален корисник. Тоа е намерно проширување на пристапот, а не заобиколен начин за автоматизација.

Нека тригерот дејствува во истиот контекст на сесијата

Нека поддржаната интеграција на VPN настани побара извршување на дејство на корисничка сесија, наместо да се претпостави дека привилегиран callback може да позајми десктоп акредитив. Ограничете го тригерот на предвидениот идентификатор на врска, а не на кој било интерфејс што случајно се вика tun0. Правило на диспечерот што се совпаѓа со погрешното нешто се активира при секоја промена на мрежата, вклучително и оние што немаат никаква врска со ова монтирање.

Дејството треба да го потврди очекуваното име на хостот, да забележи постоечко монтирање и да направи еден ограничен обид. Анкетна јамка што стартува нов SSHFS процес на секои неколку секунди или го повторува барањето за акредитиви додека серверот е исклучен, краткиот прекин го претвора во куп заглавени процеси. Ограничете го обидот со таймаут и едно повторување.

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

Првата команда го дава идентификаторот на врската што диспечерот треба да го совпадне. Другите две покажуваат дали обидот веќе работи, и тоа е проверката што спречува дупликати.

Услугата без надзор бара свои одобрени акредитиви и сопствена проверка на хостот во сопствениот контекст на извршување. Таа не може да претпостави дека графички агент е отклучен и не треба да се обиде да отклучи еден.

Планирајте го исклучувањето пред да го присилите чистењето

За планирано исклучување, завршете ги операциите со датотеки и демонтирајте од сопствениот работен тек на корисникот што монтира. Целете ја точката на монтирање, а не процесот, и потврдете го резултатот пред да пријавите успех.

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

Демонтирајте само го монтирањето што го создаде овој работен тек. Ако е зафатено, тоа е одлука на апликацијата: присилното одвојување што постои за куката да врати успех го крие губењето податоци наместо да го спречи.

Неочекуваното губење се однесува поинаку. SSHFS документира дека прекин на мрежата може да блокира операција на датотечниот систем, а опцијата reconnect го враќа преносот без да ги врати рачките: датотека отворена пред повторното поврзување може да не успее при следното пишување, а прекинатото пишување не се зачувува. Таа разлика е најважна за уредувачи што држат една датотека отворена со часови. Планирајте чекор за повторно отворање наместо да претпоставите обновување.

Тестирајте го однесувањето со еднократни датотеки пред да се потпрете на него. Папка што повторно се појавува откако тунелот ќе се врати не докажува дека претходните рачки или незачуваната работа преживеале.