Объединенное монтирование в Linux
Это довольно просто.
На локальной стороне (сервер S) запустите сервер openssh. Это запустит ssh-сервер по умолчанию на порту 22 - при необходимости вы можете изменить этот порт в файле / etc / ssh / sshd_config.
service ssh start
На удаленной стороне (клиент A) запустите прокси-сервер socks И установите удаленный порт на локальной стороне для подключения к прокси-серверу socks.
ssh -N -D 127.0.0.1:8888 -p 22 <server-s>
ssh -N -R 2222:127.0.0.1:8888 -p 22 <server-s>
На локальной стороне (сервер S) используйте настройку прокси-сервера socks на порту 2222, например, через для подключения к Google.
curl --socks5 127.0.0.1:2222 https://www.google.com
По каждой из конкретных точек:
Корневой доступ :Если он использует FUSE, ему не нужен корень, если он не использует FUSE, ему нужен корень, если вы не выполняете специальную настройку либо с возможностями (, либо с потенциально опасными ), либо с пространствами имен.
Монтирование на
/:Я предполагаю, что вы имеете в виду корневую файловую систему при запуске, и в этом случае любая из них, работающая в режиме ядра, теоретически должна работать, хотя некоторые из них более надежны, чем другие. Большинство LiveCD делают это, поэтому я бы посоветовал поискать информацию по этому конкретному вопросу.Запись в базовые ветки :Это зависит от того, что вы имеете в виду. Если вы имеете в виду распространение записей в смонтированном представлении на нижние ветки, я понятия не имею. Если вы имеете в виду запись в нижние ветви из полосы -полосы -из самой основной файловой системы, технически все большие три делают это, но все они требуют повторного монтирования, чтобы гарантировать, что изменение будет распространено на смонтированное представление.
Настраиваемые политики записи :Я не знаю конкретно об этом, но я думаю, что большая тройка (UnionFS, AUFS и OverlayFS )не поддерживает это.
Файл -зависимый порядок приоритетов :Я думаю, что этот тип также подпадает под вопрос третьего подпункта -, и, как и в этом случае, я не знаю ни одного, который специально поддерживает его.
Что касается некоторых подробностей по каждому из них:
UnionFS :Насколько я могу судить, это была первоначальная реализация стекируемой файловой системы union для Linux.Он существует уже много лет и используется во многих Linux-дисках LiveCD. Он работает в режиме ядра и требует использования исправлений для основного ядра.
AUFS :Возникла как форк UnionFS, а затем стала отдельной вещью. Этот пытался объединить основную ветку и был отклонен из-за качества кода. Он заменил UnionFS в некоторых дистрибутивах LiveCD, в основном производных от Debian и Gentoo. Как и UnionFS, он работает в режиме ядра и требует исправлений для вышестоящего ядра.
OverlayFS :Я мало что знаю об исходной разработке этого, кроме того, что он поддерживается парой производных от BSD. В частности, это реализация вышестоящей файловой системы overlay/union в ядре Linux. Он также работает в режиме ядра.
UnionFS -FUSE :Этот проект с несколько запутанным названием на самом деле не имеет ничего общего с UnionFS, кроме предоставления практически той же функциональности. Это наиболее широко используемая реализация объединенной файловой системы FUSE, но это все, что я о ней знаю.
mhddfs :Это странное исключение, которое больше похоже на реализацию файловой гранулярности RAID -0, чем на обычную объединенную файловую систему. Он поддерживает балансировку файлов между несколькими резервными каталогами в зависимости от использования пространства. Он также основан на FUSE.
Следует отметить пару особенностей, которые не относятся к конкретной реализации:
Все параметры ядра в -имеют ограничения на то, какими могут быть резервные файловые системы, в частности, они не работают с сетевыми файловыми системами или BTRFS.
Все реализации FUSE имеют проблемы при использовании в качестве корневой файловой системы. Это не относится к реализациям файловой системы union, а больше относится к FUSE в целом.