Чи повинна сесія користувача володіти монтуванням 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 відновлює транспорт без відновлення дескрипторів: файл, відкритий до повторного підключення, може не записатися наступного разу, а перерваний запис не зберігається. Ця різниця найважливіша для редакторів, які тримають один файл відкритим годинами. Сплануйте крок повторного відкриття, а не сподівайтеся на відновлення.

Перевірте поведінку на одноразових файлах, перш ніж покладатися на неї. Тека, яка знову з'являється після повернення тунелю, не доводить, що попередні дескриптори або незбережена робота вижили.