ls /mnt/remote/web.example.com/var/lib/www/
И сразу увидеть файлы web-сервера, никак не устанавливая с ним соединение специально? Я этим пользуюсь уже давно, а главное:
- Это работает из любого источника: Не важно, делаете вы указанный вывод в консоли, сохранили ссылку в MC или переходите из favorites вашего любимого менеджера такого как nautilus или dolphin
- Вы можете переходить на любой хост, куда у вас есть доступ по ключам (настроить запрос пароля тоже можно, но это не интересно)
- Вы можете запросто указать под каким пользователем входить на сервер, используя @:
cd /mnt/remote/apache@web.example.com/var/lib/www/
Что это и зачем
Использоваться это может с разными системам, но удобнее всего конечно с sshfs. Думаю с ней многие имели дело, это действительно удобно, но если нужно походить по удалённой файловой системе, каждый раз приходится её монтировать:
sshfs hostname: mountpointЭто становится крайне утомительно когда вы работаете с сотней удалённых серверов, особенно когда вам это нужно например, чтобы быстренько перекинуть маленький конфиг-файл с одного удалённого сервера на другой (а качать большие файлы по sshfs и не очень эффективно, лучше использовать rsync или bbcp).
Afuse проект с открытым исходным кодом и сам является fuse файловой системой. Он доступен для большинства современных дистрибутивов.
Очень неплохая статья про его описание, а также настройку уже была на Хабре. Всех кто первый раз пробует, отправляю туда.
Мы же, чтобы не повторяться, пойдём немного дальше.
Единственное хотелось заметить что для дистрибутивов, базирующихся на RPM (Fedora, CentOS, RHEL, Scientific Linux…) вам потребуется использовать yum/dnf:
dnf install afuseИспользуйте yum вместо dnf на более старых системах, таких как CentOS.
Настройка же ключей, хостов и опций монтирования вряд ли будет сильно отличаться, для тонкостей всегда можно обратиться к манулу.
Afuse automount
Полагаю что вы уже поигрались и вам понравилось монтирование sshfs налету. Вот только в вышеупомянутой статье указан ну очень кривой способ монтирования самого afuse. Полагаю что у вас тоже остался осадочек: «Как же так, файловую систему, монтирующую другие файловые системы, нужно каждый раз монтировать вручную!?»
Вот именно как это сделать я и хотел поделиться.
На самом деле, все механизмы уже есть в системе. Так, раз afuse сама является файловой системой, то почему бы не монтировать её стандартным образом из /etc/fstab!?
В принципе это очень даже возможно, однако нет прямого способа передать столько желаемых аргументов.
Поэтому предполагается создать скрипт-обертку /usr/sbin/mount.afuse (выложил также как gist кому так удобнее, там же есть более подробное описание его) приблизительно такого содержания:
# Mount under user and group which are owners of mount point
su -l $( stat --format=%U "$2" ) -c "afuse -o mount_template='sshfs -o reconnect -o auto_cache -o kernel_cache %r:/ %m' -o unmount_template='fusermount -u -z %m' -o auto_unmount '$2'"Не забываем сделать его исполняемым:
chmod +x /usr/sbin/mount.afuseТеперь мы готовы добавить новую системную точку монтирования в /etc/fstab:
afuse# /mnt/remote afuse auto 0 0Всё, с этого момента, даже после перезагрузки системы afuse примонтирована, а все соединения с удалёнными хостами будут восстановлены автоматически, если какие-то программы работали с удалёнными файлами по таким путям. Не будет ошибок что что-то не доступно.
Разумеется точку монтирования вы можете изменить по своему желанию, может что-то типа /remote. Не забудьте только создать директорию.
Update 14.02.2017: По комментарию Self_Perfection незначительно улучшен код в хелпере для получения пользователя, от которого будет монтироваться директория. Он стал более простым и понятным.
Комментарии (28)
Self_Perfection
11.02.2017 18:48+5$( ls -dl "$2" | cut -d' ' -f3)
*sigh* ну так же проще
$( stat --format=%U "$2" )
webasyster
13.02.2017 20:22+1Смысл придираться к командам?
Self_Perfection
14.02.2017 00:22+1У меня есть желание распространять знания по написанию эффективных шелл скриптов. Мой вариант примерно вдвое быстрее. Тон комментария возможно получился неподходящий. Но русский язык мне вообще часто мешается, хочется общаться копипастами из консоли. Тут явно нужно было вставить какой-то текст между двумя шелл строками, вставил первый пришедший в голову.
Hubbitus
14.02.2017 15:21Я внёс изменения в пример. Не считаю это критичным, но в общем вполне согласен что ваш вариант лучше.
rPman
11.02.2017 19:41+1Поясните, какие проблемы могут возникнуть, если, к примеру, будет потеряна связь с удаленным хостом, e; примонтированным, и как развитие ситуации, на котором есть открытые файлы и идет чтение/запись. И если причиной будет не сеть а проблемы с удаленным сервером (перезапуск)?
Корректно ли будет восстановлена связь или точка монтирования зависнет?
Я помню у меня с обычным nfs проблемы были, даже -o soft не помогало. (точнее помогало, но как то странно и требовало закрытие всех приложений, использующих точку монтрования и перемонтрования)Hubbitus
11.02.2017 19:57Если хост недоступен, разумеется вы не сможете читать его. Но, во-первых, это просто sshfs, поведение будет в точности такое же. К afuse это не имеет отношения.
Но если вернуться к вопросу как оно будет себя вести, то при переходе в эту директорию команда просто подвиснет. В моём примере используется опция "-o reconnect", соответственно sshfs будет постоянно пытаться переконнектиться, и сделает это как только хост станет доступен, то есть вы увидите просто задержку. Если же хост стал полностью недоступен, вы можете просто убить соответствующий sshs процесс с помощью kill. Ну и отмонтировать конкретную директорию: fusermount -u somehost
Hubbitus
11.02.2017 20:08Кстати, вместо использования sshfs вы вполне также можете использовать автомаонтирование nfs с помощью afuse! Потребуются незначительные модификации скрипта-хелпера. Однако nfs требует экспорта файловых систем, вся прелесть sshfs в том что вы можете так монтировать любой хост, на который у вас есть ssh доступ, без каких-то дополнительных подготовок на нём.
Lsh
12.02.2017 00:04Не совсем любой, на той стороне должно быть приложение sftp, разве нет?
Hubbitus
12.02.2017 13:15Нет, по умолчанию ssh достаточно! Есть конечно возможность его ограничить отдельным списком команд дополнительно, но мы сейчас не будем рассматривать эти случаи. А вообще работает даже с shared хостингами на ура.
Yuego
11.02.2017 23:20+1Использую в работе Autofs для подключения Samba-ресурсов, т. к. далеко не каждая софтина умеет smb протокол и отсутствуют многие плюшки вроде превью изображений (по крайней мере в KDE5).
Принцип работы похожий. Умеет, естественно, не только Samba.Hubbitus
12.02.2017 13:27Autofs тоже хорошая штука, согласен. Я его тоже использовал.
Из важных плюсов — умеет отмонтировать файловые системы по настроенному таймауту и это удобно.
Из серьёзных минусов:
- значительно сложнее в настройке. Работает на древнем automount
- при этом далеко не тривиален в дебаге, если что-то не так работает как хочется. Вот например я ставил пару багов на него: bz#961312, bz#961299.
- Последнюю закрыли не разбираясь, по таймауту :( Если посмотреть в багзилле кроме моих, то их тоже очень не мало, что тоже немного отталкивает.
Yuego
13.02.2017 15:26+1Когда искал, первое, на что наткнулся, — autofs. Про afuse узнал только из этой статьи.
В целом работа autofs меня устраивает, но есть пара моментов, с которыми никак руки не дойдут разобраться.
Настройка действительно несколько замороченная — разобрался не сразу, что куда писать.
Надо бы и afuse попробовать.
Lsh
12.02.2017 00:52+1Здорово было бы что-нибудь аналогичное, но более универсальное.
Чтобы работать и с архивами, и с образами дисков.
Например, есть архив:
/media/user/flashdrive/ar.zip
Доступ к содержимому через некий специальный маркер в пути:
/media/user/flashdrive/ar.zip#/pictureinside.jpg
Правда, получается, что тут поверх всей файловой системы надо смонтировать обработчик и fuse убъет всю производительность.
Если я не ошибаюсь, то в HURD что-то такое обещали. Никто не в курсе?
Интересно, насколько такое реализуемо в линуксе?Erelecano
12.02.2017 03:12-1https://ru.wikipedia.org/wiki/Archivemount
Да вот, специально для вас было уже.
Правда никому особо было не нужно и уже давно не обновляется.
А в херде могут обещать все что угодно, все равно никогда не будет работать.
Hubbitus
12.02.2017 13:38Ну тут действительно проблема в том что нужно отслеживать всё дерево, включая удалённые файловые системы. А с ними вообще будет беда по скорости.
И наверное теоретически FUSE можно было бы реализовать, но как вы сами заметили, скорость будет вряд ли приемлемой.
Для архивов в общем вполне не плохо справляются все среды, чтобы зайти в них, и Gnome и KDE. В консоли тот же Midnight прекрасно «заходит» в архивы.
Да, это не вполне удобно, потому что решения разные, симлинки не сделаешь, нет интероперабельности… Но с другой стороны, в большинстве случаев такой доступ всё равно очень медленный и нужен лишь чтобы «быстренько взглянуть что там», ну или поглядеть пару небольших файлов вроде README. А с этим указанные средства вполне справляются. Если вам понадобилось содержимое архива полностью, то полное его извлечение будет на порядок быстрее с помощью последовательного чтения и использования родного архиватора.
GamePad64
12.02.2017 12:15+1В системах с systemd достаточно в флагах монтирования в fstab прописать
noauto,x-systemd.automount, и монтирование будет делаться при первом обращении к директории.Hubbitus
12.02.2017 13:51+1Полагаю вы не вполне поняли для чего afuse и autofs.
x-systemd.automount не делает ничего более, как формирует automount unit for filesystem.
Это удобно для сетевых систем, прописанных в /etc/fstab, чтобы они сразу не монтировались, а только по мере доступа к ним.
Но т.к. юнит формируется по строке из fstab, то вы должны будете прописать все ваши сотни серверов для возможности монтирования по sshfs! Это именно то, от чего мы хотели избавиться!
Мы так или иначе прописываем одну строку для моунтпоинта автомонтирования (/mnt/remote в моём примере). Будет ли она работать с x-systemd.automount я не знаю, но смысл всё равно отсутствует — в сущности это ж псевдо система, и пока вы не обратититесь внутрь этой системы, да ещё и к директории с нужным именем, ничего удалённого здесь всё равно не монтируется.
dm00
13.02.2017 18:48Все это здорово конечно, но при работе с серверами надо быть уверенными что ошибки минимизированы. Иной раз лучше пробежаться по серверам, сократив «радиус поражения» до одной системы. А последний апдейт на гитхабе (без дня четыре года назад) уже повод подумать о безопасности. Afuse может быть привлекателен программистам, а вот админы надают по рукам.
Hubbitus
13.02.2017 18:51Простите, не совсем понимаю что вы имели ввиду. Что лучше не монтировать автоматически потому что можно удалить не тот файл? Ну так и если по SSH если будете заходить — не исключена ошибка ввода не того имени хоста. А чем отличается уровень возможности ошибки при ввода хоста в строке подключения от строки файлового пути — не очень понятно.
dm00
14.02.2017 11:52Ну так и если по SSH если будете заходить — не исключена ошибка ввода не того имени хоста
оно самое, к примеру. Поэтому пострадает один хост. Безопасным будет автомонтирование в read-only, если очень нужно.
belonesox
13.02.2017 19:13+1- Ну, обычно этих маунтпоинтов сотни, и их я группирую подкаталогами-проектами внутри папки маунта (т.п. не ls -l, а глубже надо бы перебирать).
- Ориентироваться на владельца каталога как пользователя которым коннектится — точно неправильно (как правило коннектится надо рутом или какими-то спецаккаунтами, которых на десктопной машине нет).
- Еще надо порт учитывать (у меня там чтото типа root@server.xxx-2224, не знаю, можно ли красивее).
Hubbitus
13.02.2017 20:14Разумеется вы можете придумать дальше нужную вам схему, в том числе порт. Кстати в Linux нет проблемы использовать: в имени директории, соответственно вполне можно создавать и традиционный путь вроде root@server.xxx:2224. У меня ж пример, всё что может понадобится не предусмотреть, хотя замечание хорошее.
А вот на пользователя директории для коннекта никто не ориентируется. По умолчанию берётся тот, кто прописан для хоста в ~/.ssh/config. А если нужно указать другого, то для этого случая я и описал в статье что можно использовать нотацию user@host.
Pingvi
Пожалуйста, объясните почему CentOS стала старой системой?
ggrnd0
На centos/rhel/debian обновления пакетов происходит с большей задержкой.
На fedora/ubuntu обновления появляются раньше и чаще.
xtotec
Есть такое понятие как «life cycle» — У федоры это 6 месяцев, у centos — 10 лет. Именно поэтому Centos — enterprise OS.
Грубо говоря, федора — для десктопов «красноглазиков», а centos — для серверов, которые рассчитаны на то, что весь жизненный цикл они не будут выключаться.
Hubbitus
Ну на самом деле для Fedora Server давно обсуждается как минимум цикл в 6 релизов: https://fedoraproject.org/wiki/Server/Proposals/Server_Lifecycle и подобные разговоры у нас в рассылке всплывали с регулярным постоянством в прошлом. Везде есть свои плюсы и минусы и у всего есть своя цена.
Однако полагаю это всё же уже оффтопик.
Hubbitus
В данном контексте это было лишь к тому что туда ещё не пришёл dnf на смену yum.