Automount afuse

    Я хотел рассказать про своё открытие afuse — автомонтирование файловых систем по требованию, автоматически. Разве не здорово просто сделать:

    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 незначительно улучшен код в хелпере для получения пользователя, от которого будет монтироваться директория. Он стал более простым и понятным.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 28

      +1
      Используйте yum вместо dnf на более старых системах, таких как CentOS.

      Пожалуйста, объясните почему CentOS стала старой системой?
      • НЛО прилетело и опубликовало эту надпись здесь
          +1
          Есть такое понятие как «life cycle» — У федоры это 6 месяцев, у centos — 10 лет. Именно поэтому Centos — enterprise OS.
          Грубо говоря, федора — для десктопов «красноглазиков», а centos — для серверов, которые рассчитаны на то, что весь жизненный цикл они не будут выключаться.
            0
            Ну на самом деле для Fedora Server давно обсуждается как минимум цикл в 6 релизов: https://fedoraproject.org/wiki/Server/Proposals/Server_Lifecycle и подобные разговоры у нас в рассылке всплывали с регулярным постоянством в прошлом. Везде есть свои плюсы и минусы и у всего есть своя цена.

            Однако полагаю это всё же уже оффтопик.
          +2
          В данном контексте это было лишь к тому что туда ещё не пришёл dnf на смену yum.
          +5
          $( ls -dl "$2" | cut -d' ' -f3)
          

          *sigh* ну так же проще

          $( stat --format=%U "$2" )
          
            0
            Да можно и так. И ещё десятком способов…
              +1
              Смысл придираться к командам?
                +1
                У меня есть желание распространять знания по написанию эффективных шелл скриптов. Мой вариант примерно вдвое быстрее. Тон комментария возможно получился неподходящий. Но русский язык мне вообще часто мешается, хочется общаться копипастами из консоли. Тут явно нужно было вставить какой-то текст между двумя шелл строками, вставил первый пришедший в голову.
                  0
                  Я внёс изменения в пример. Не считаю это критичным, но в общем вполне согласен что ваш вариант лучше.
              +1
              Поясните, какие проблемы могут возникнуть, если, к примеру, будет потеряна связь с удаленным хостом, e; примонтированным, и как развитие ситуации, на котором есть открытые файлы и идет чтение/запись. И если причиной будет не сеть а проблемы с удаленным сервером (перезапуск)?
              Корректно ли будет восстановлена связь или точка монтирования зависнет?

              Я помню у меня с обычным nfs проблемы были, даже -o soft не помогало. (точнее помогало, но как то странно и требовало закрытие всех приложений, использующих точку монтрования и перемонтрования)
                0
                Если хост недоступен, разумеется вы не сможете читать его. Но, во-первых, это просто sshfs, поведение будет в точности такое же. К afuse это не имеет отношения.

                Но если вернуться к вопросу как оно будет себя вести, то при переходе в эту директорию команда просто подвиснет. В моём примере используется опция "-o reconnect", соответственно sshfs будет постоянно пытаться переконнектиться, и сделает это как только хост станет доступен, то есть вы увидите просто задержку. Если же хост стал полностью недоступен, вы можете просто убить соответствующий sshs процесс с помощью kill. Ну и отмонтировать конкретную директорию: fusermount -u somehost
                  0
                  Кстати, вместо использования sshfs вы вполне также можете использовать автомаонтирование nfs с помощью afuse! Потребуются незначительные модификации скрипта-хелпера. Однако nfs требует экспорта файловых систем, вся прелесть sshfs в том что вы можете так монтировать любой хост, на который у вас есть ssh доступ, без каких-то дополнительных подготовок на нём.
                    0
                    Не совсем любой, на той стороне должно быть приложение sftp, разве нет?
                      0
                      Нет, по умолчанию ssh достаточно! Есть конечно возможность его ограничить отдельным списком команд дополнительно, но мы сейчас не будем рассматривать эти случаи. А вообще работает даже с shared хостингами на ура.
                  +1
                  Использую в работе Autofs для подключения Samba-ресурсов, т. к. далеко не каждая софтина умеет smb протокол и отсутствуют многие плюшки вроде превью изображений (по крайней мере в KDE5).
                  Принцип работы похожий. Умеет, естественно, не только Samba.
                    0
                    Autofs тоже хорошая штука, согласен. Я его тоже использовал.
                    Из важных плюсов — умеет отмонтировать файловые системы по настроенному таймауту и это удобно.
                    Из серьёзных минусов:
                    • значительно сложнее в настройке. Работает на древнем automount
                    • при этом далеко не тривиален в дебаге, если что-то не так работает как хочется. Вот например я ставил пару багов на него: bz#961312, bz#961299.
                    • Последнюю закрыли не разбираясь, по таймауту :( Если посмотреть в багзилле кроме моих, то их тоже очень не мало, что тоже немного отталкивает.

                      +1
                      Когда искал, первое, на что наткнулся, — autofs. Про afuse узнал только из этой статьи.
                      В целом работа autofs меня устраивает, но есть пара моментов, с которыми никак руки не дойдут разобраться.
                      Настройка действительно несколько замороченная — разобрался не сразу, что куда писать.

                      Надо бы и afuse попробовать.
                    +1
                    Здорово было бы что-нибудь аналогичное, но более универсальное.
                    Чтобы работать и с архивами, и с образами дисков.

                    Например, есть архив:
                    /media/user/flashdrive/ar.zip
                    Доступ к содержимому через некий специальный маркер в пути:
                    /media/user/flashdrive/ar.zip#/pictureinside.jpg

                    Правда, получается, что тут поверх всей файловой системы надо смонтировать обработчик и fuse убъет всю производительность.

                    Если я не ошибаюсь, то в HURD что-то такое обещали. Никто не в курсе?
                    Интересно, насколько такое реализуемо в линуксе?
                      –1
                      https://ru.wikipedia.org/wiki/Archivemount
                      Да вот, специально для вас было уже.
                      Правда никому особо было не нужно и уже давно не обновляется.
                      А в херде могут обещать все что угодно, все равно никогда не будет работать.
                        0
                        Ну тут действительно проблема в том что нужно отслеживать всё дерево, включая удалённые файловые системы. А с ними вообще будет беда по скорости.

                        И наверное теоретически FUSE можно было бы реализовать, но как вы сами заметили, скорость будет вряд ли приемлемой.

                        Для архивов в общем вполне не плохо справляются все среды, чтобы зайти в них, и Gnome и KDE. В консоли тот же Midnight прекрасно «заходит» в архивы.
                        Да, это не вполне удобно, потому что решения разные, симлинки не сделаешь, нет интероперабельности… Но с другой стороны, в большинстве случаев такой доступ всё равно очень медленный и нужен лишь чтобы «быстренько взглянуть что там», ну или поглядеть пару небольших файлов вроде README. А с этим указанные средства вполне справляются. Если вам понадобилось содержимое архива полностью, то полное его извлечение будет на порядок быстрее с помощью последовательного чтения и использования родного архиватора.
                        +1

                        В системах с systemd достаточно в флагах монтирования в fstab прописать noauto,x-systemd.automount, и монтирование будет делаться при первом обращении к директории.

                          +1
                          Полагаю вы не вполне поняли для чего afuse и autofs.

                          x-systemd.automount не делает ничего более, как формирует automount unit for filesystem.
                          Это удобно для сетевых систем, прописанных в /etc/fstab, чтобы они сразу не монтировались, а только по мере доступа к ним.

                          Но т.к. юнит формируется по строке из fstab, то вы должны будете прописать все ваши сотни серверов для возможности монтирования по sshfs! Это именно то, от чего мы хотели избавиться!

                          Мы так или иначе прописываем одну строку для моунтпоинта автомонтирования (/mnt/remote в моём примере). Будет ли она работать с x-systemd.automount я не знаю, но смысл всё равно отсутствует — в сущности это ж псевдо система, и пока вы не обратититесь внутрь этой системы, да ещё и к директории с нужным именем, ничего удалённого здесь всё равно не монтируется.
                          0
                          Все это здорово конечно, но при работе с серверами надо быть уверенными что ошибки минимизированы. Иной раз лучше пробежаться по серверам, сократив «радиус поражения» до одной системы. А последний апдейт на гитхабе (без дня четыре года назад) уже повод подумать о безопасности. Afuse может быть привлекателен программистам, а вот админы надают по рукам.
                            0
                            Простите, не совсем понимаю что вы имели ввиду. Что лучше не монтировать автоматически потому что можно удалить не тот файл? Ну так и если по SSH если будете заходить — не исключена ошибка ввода не того имени хоста. А чем отличается уровень возможности ошибки при ввода хоста в строке подключения от строки файлового пути — не очень понятно.
                              0
                              Ну так и если по SSH если будете заходить — не исключена ошибка ввода не того имени хоста
                              оно самое, к примеру. Поэтому пострадает один хост. Безопасным будет автомонтирование в read-only, если очень нужно.
                            +1
                            • Ну, обычно этих маунтпоинтов сотни, и их я группирую подкаталогами-проектами внутри папки маунта (т.п. не ls -l, а глубже надо бы перебирать).
                            • Ориентироваться на владельца каталога как пользователя которым коннектится — точно неправильно (как правило коннектится надо рутом или какими-то спецаккаунтами, которых на десктопной машине нет).
                            • Еще надо порт учитывать (у меня там чтото типа root@server.xxx-2224, не знаю, можно ли красивее).
                              0
                              Разумеется вы можете придумать дальше нужную вам схему, в том числе порт. Кстати в Linux нет проблемы использовать: в имени директории, соответственно вполне можно создавать и традиционный путь вроде root@server.xxx:2224. У меня ж пример, всё что может понадобится не предусмотреть, хотя замечание хорошее.

                              А вот на пользователя директории для коннекта никто не ориентируется. По умолчанию берётся тот, кто прописан для хоста в ~/.ssh/config. А если нужно указать другого, то для этого случая я и описал в статье что можно использовать нотацию user@host.

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                            Самое читаемое