Комментарии 28
Используйте yum вместо dnf на более старых системах, таких как CentOS.
Пожалуйста, объясните почему CentOS стала старой системой?
НЛО прилетело и опубликовало эту надпись здесь
Есть такое понятие как «life cycle» — У федоры это 6 месяцев, у centos — 10 лет. Именно поэтому Centos — enterprise OS.
Грубо говоря, федора — для десктопов «красноглазиков», а centos — для серверов, которые рассчитаны на то, что весь жизненный цикл они не будут выключаться.
Грубо говоря, федора — для десктопов «красноглазиков», а centos — для серверов, которые рассчитаны на то, что весь жизненный цикл они не будут выключаться.
Ну на самом деле для Fedora Server давно обсуждается как минимум цикл в 6 релизов: https://fedoraproject.org/wiki/Server/Proposals/Server_Lifecycle и подобные разговоры у нас в рассылке всплывали с регулярным постоянством в прошлом. Везде есть свои плюсы и минусы и у всего есть своя цена.
Однако полагаю это всё же уже оффтопик.
Однако полагаю это всё же уже оффтопик.
В данном контексте это было лишь к тому что туда ещё не пришёл dnf на смену yum.
$( ls -dl "$2" | cut -d' ' -f3)
*sigh* ну так же проще
$( stat --format=%U "$2" )
Да можно и так. И ещё десятком способов…
Смысл придираться к командам?
У меня есть желание распространять знания по написанию эффективных шелл скриптов. Мой вариант примерно вдвое быстрее. Тон комментария возможно получился неподходящий. Но русский язык мне вообще часто мешается, хочется общаться копипастами из консоли. Тут явно нужно было вставить какой-то текст между двумя шелл строками, вставил первый пришедший в голову.
Поясните, какие проблемы могут возникнуть, если, к примеру, будет потеряна связь с удаленным хостом, e; примонтированным, и как развитие ситуации, на котором есть открытые файлы и идет чтение/запись. И если причиной будет не сеть а проблемы с удаленным сервером (перезапуск)?
Корректно ли будет восстановлена связь или точка монтирования зависнет?
Я помню у меня с обычным nfs проблемы были, даже -o soft не помогало. (точнее помогало, но как то странно и требовало закрытие всех приложений, использующих точку монтрования и перемонтрования)
Корректно ли будет восстановлена связь или точка монтирования зависнет?
Я помню у меня с обычным nfs проблемы были, даже -o soft не помогало. (точнее помогало, но как то странно и требовало закрытие всех приложений, использующих точку монтрования и перемонтрования)
Если хост недоступен, разумеется вы не сможете читать его. Но, во-первых, это просто sshfs, поведение будет в точности такое же. К afuse это не имеет отношения.
Но если вернуться к вопросу как оно будет себя вести, то при переходе в эту директорию команда просто подвиснет. В моём примере используется опция "-o reconnect", соответственно sshfs будет постоянно пытаться переконнектиться, и сделает это как только хост станет доступен, то есть вы увидите просто задержку. Если же хост стал полностью недоступен, вы можете просто убить соответствующий sshs процесс с помощью kill. Ну и отмонтировать конкретную директорию: fusermount -u somehost
Но если вернуться к вопросу как оно будет себя вести, то при переходе в эту директорию команда просто подвиснет. В моём примере используется опция "-o reconnect", соответственно sshfs будет постоянно пытаться переконнектиться, и сделает это как только хост станет доступен, то есть вы увидите просто задержку. Если же хост стал полностью недоступен, вы можете просто убить соответствующий sshs процесс с помощью kill. Ну и отмонтировать конкретную директорию: fusermount -u somehost
Кстати, вместо использования sshfs вы вполне также можете использовать автомаонтирование nfs с помощью afuse! Потребуются незначительные модификации скрипта-хелпера. Однако nfs требует экспорта файловых систем, вся прелесть sshfs в том что вы можете так монтировать любой хост, на который у вас есть ssh доступ, без каких-то дополнительных подготовок на нём.
Использую в работе Autofs для подключения Samba-ресурсов, т. к. далеко не каждая софтина умеет smb протокол и отсутствуют многие плюшки вроде превью изображений (по крайней мере в KDE5).
Принцип работы похожий. Умеет, естественно, не только Samba.
Принцип работы похожий. Умеет, естественно, не только Samba.
Autofs тоже хорошая штука, согласен. Я его тоже использовал.
Из важных плюсов — умеет отмонтировать файловые системы по настроенному таймауту и это удобно.
Из серьёзных минусов:
Из важных плюсов — умеет отмонтировать файловые системы по настроенному таймауту и это удобно.
Из серьёзных минусов:
- значительно сложнее в настройке. Работает на древнем automount
- при этом далеко не тривиален в дебаге, если что-то не так работает как хочется. Вот например я ставил пару багов на него: bz#961312, bz#961299.
- Последнюю закрыли не разбираясь, по таймауту :( Если посмотреть в багзилле кроме моих, то их тоже очень не мало, что тоже немного отталкивает.
Когда искал, первое, на что наткнулся, — autofs. Про afuse узнал только из этой статьи.
В целом работа autofs меня устраивает, но есть пара моментов, с которыми никак руки не дойдут разобраться.
Настройка действительно несколько замороченная — разобрался не сразу, что куда писать.
Надо бы и afuse попробовать.
В целом работа autofs меня устраивает, но есть пара моментов, с которыми никак руки не дойдут разобраться.
Настройка действительно несколько замороченная — разобрался не сразу, что куда писать.
Надо бы и afuse попробовать.
Здорово было бы что-нибудь аналогичное, но более универсальное.
Чтобы работать и с архивами, и с образами дисков.
Например, есть архив:
/media/user/flashdrive/ar.zip
Доступ к содержимому через некий специальный маркер в пути:
/media/user/flashdrive/ar.zip#/pictureinside.jpg
Правда, получается, что тут поверх всей файловой системы надо смонтировать обработчик и fuse убъет всю производительность.
Если я не ошибаюсь, то в HURD что-то такое обещали. Никто не в курсе?
Интересно, насколько такое реализуемо в линуксе?
Чтобы работать и с архивами, и с образами дисков.
Например, есть архив:
/media/user/flashdrive/ar.zip
Доступ к содержимому через некий специальный маркер в пути:
/media/user/flashdrive/ar.zip#/pictureinside.jpg
Правда, получается, что тут поверх всей файловой системы надо смонтировать обработчик и fuse убъет всю производительность.
Если я не ошибаюсь, то в HURD что-то такое обещали. Никто не в курсе?
Интересно, насколько такое реализуемо в линуксе?
https://ru.wikipedia.org/wiki/Archivemount
Да вот, специально для вас было уже.
Правда никому особо было не нужно и уже давно не обновляется.
А в херде могут обещать все что угодно, все равно никогда не будет работать.
Да вот, специально для вас было уже.
Правда никому особо было не нужно и уже давно не обновляется.
А в херде могут обещать все что угодно, все равно никогда не будет работать.
Ну тут действительно проблема в том что нужно отслеживать всё дерево, включая удалённые файловые системы. А с ними вообще будет беда по скорости.
И наверное теоретически FUSE можно было бы реализовать, но как вы сами заметили, скорость будет вряд ли приемлемой.
Для архивов в общем вполне не плохо справляются все среды, чтобы зайти в них, и Gnome и KDE. В консоли тот же Midnight прекрасно «заходит» в архивы.
Да, это не вполне удобно, потому что решения разные, симлинки не сделаешь, нет интероперабельности… Но с другой стороны, в большинстве случаев такой доступ всё равно очень медленный и нужен лишь чтобы «быстренько взглянуть что там», ну или поглядеть пару небольших файлов вроде README. А с этим указанные средства вполне справляются. Если вам понадобилось содержимое архива полностью, то полное его извлечение будет на порядок быстрее с помощью последовательного чтения и использования родного архиватора.
И наверное теоретически FUSE можно было бы реализовать, но как вы сами заметили, скорость будет вряд ли приемлемой.
Для архивов в общем вполне не плохо справляются все среды, чтобы зайти в них, и Gnome и KDE. В консоли тот же Midnight прекрасно «заходит» в архивы.
Да, это не вполне удобно, потому что решения разные, симлинки не сделаешь, нет интероперабельности… Но с другой стороны, в большинстве случаев такой доступ всё равно очень медленный и нужен лишь чтобы «быстренько взглянуть что там», ну или поглядеть пару небольших файлов вроде README. А с этим указанные средства вполне справляются. Если вам понадобилось содержимое архива полностью, то полное его извлечение будет на порядок быстрее с помощью последовательного чтения и использования родного архиватора.
В системах с systemd достаточно в флагах монтирования в fstab прописать noauto,x-systemd.automount, и монтирование будет делаться при первом обращении к директории.
Полагаю вы не вполне поняли для чего afuse и autofs.
x-systemd.automount не делает ничего более, как формирует automount unit for filesystem.
Это удобно для сетевых систем, прописанных в /etc/fstab, чтобы они сразу не монтировались, а только по мере доступа к ним.
Но т.к. юнит формируется по строке из fstab, то вы должны будете прописать все ваши сотни серверов для возможности монтирования по sshfs! Это именно то, от чего мы хотели избавиться!
Мы так или иначе прописываем одну строку для моунтпоинта автомонтирования (/mnt/remote в моём примере). Будет ли она работать с x-systemd.automount я не знаю, но смысл всё равно отсутствует — в сущности это ж псевдо система, и пока вы не обратититесь внутрь этой системы, да ещё и к директории с нужным именем, ничего удалённого здесь всё равно не монтируется.
x-systemd.automount не делает ничего более, как формирует automount unit for filesystem.
Это удобно для сетевых систем, прописанных в /etc/fstab, чтобы они сразу не монтировались, а только по мере доступа к ним.
Но т.к. юнит формируется по строке из fstab, то вы должны будете прописать все ваши сотни серверов для возможности монтирования по sshfs! Это именно то, от чего мы хотели избавиться!
Мы так или иначе прописываем одну строку для моунтпоинта автомонтирования (/mnt/remote в моём примере). Будет ли она работать с x-systemd.automount я не знаю, но смысл всё равно отсутствует — в сущности это ж псевдо система, и пока вы не обратититесь внутрь этой системы, да ещё и к директории с нужным именем, ничего удалённого здесь всё равно не монтируется.
Все это здорово конечно, но при работе с серверами надо быть уверенными что ошибки минимизированы. Иной раз лучше пробежаться по серверам, сократив «радиус поражения» до одной системы. А последний апдейт на гитхабе (без дня четыре года назад) уже повод подумать о безопасности. Afuse может быть привлекателен программистам, а вот админы надают по рукам.
Простите, не совсем понимаю что вы имели ввиду. Что лучше не монтировать автоматически потому что можно удалить не тот файл? Ну так и если по SSH если будете заходить — не исключена ошибка ввода не того имени хоста. А чем отличается уровень возможности ошибки при ввода хоста в строке подключения от строки файлового пути — не очень понятно.
- Ну, обычно этих маунтпоинтов сотни, и их я группирую подкаталогами-проектами внутри папки маунта (т.п. не ls -l, а глубже надо бы перебирать).
- Ориентироваться на владельца каталога как пользователя которым коннектится — точно неправильно (как правило коннектится надо рутом или какими-то спецаккаунтами, которых на десктопной машине нет).
- Еще надо порт учитывать (у меня там чтото типа root@server.xxx-2224, не знаю, можно ли красивее).
Разумеется вы можете придумать дальше нужную вам схему, в том числе порт. Кстати в Linux нет проблемы использовать: в имени директории, соответственно вполне можно создавать и традиционный путь вроде root@server.xxx:2224. У меня ж пример, всё что может понадобится не предусмотреть, хотя замечание хорошее.
А вот на пользователя директории для коннекта никто не ориентируется. По умолчанию берётся тот, кто прописан для хоста в ~/.ssh/config. А если нужно указать другого, то для этого случая я и описал в статье что можно использовать нотацию user@host.
А вот на пользователя директории для коннекта никто не ориентируется. По умолчанию берётся тот, кто прописан для хоста в ~/.ssh/config. А если нужно указать другого, то для этого случая я и описал в статье что можно использовать нотацию user@host.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Automount afuse