Насколько безопасно поделиться / bin с NFS?

У меня есть несколько гостей Xen, которые очень похожи: та же самая арка, та же ОС (Debian), обычно различия в оперативной памяти и дисковом пространстве. Я бы хотел использовать конкретные виртуальные машины для конкретных задач, например, одну для VPN и SSH, другую для веб-сервера и т. Д.

Большинство руководств показывают, как NFS удобен для экспорта / home, но меня интересует экспорт базовой системы, такой как / usr / bin, / sbin и т. Д. (На самом деле, может быть, нет / etc из-за определенных программное обеспечение).

Я подумал о том, чтобы перенести все новое (неосновное / специфическое) в / user / local и экспортировать только это, но я должен был бы сохранить там структуру с нулевым разрешением и нарушить совместимость с менеджером пакетов, что приведет к аннулированию любого обновления системы. ,

Я думаю, что я ищу что-то вроде варианта тупых терминалов.

Это возможно? Есть большие плюсы и минусы?

У меня нет никакого опыта в попытках поделиться целым набором системных инструментов, поэтому я, скорее всего, просто беру дикие догадки. Тем не менее, я не думаю, что будет слишком легко выполнить ваш план.

У вас наверняка будут некоторые проблемы в управлении всем набором библиотечных зависимостей, которые несут ваши общие инструменты.

Как и просили, вот некоторые из плюсов и минусов, которые приходят на ум:

PRO

• меньшее потребление памяти на жестком диске, поскольку вам не нужно хранить все отдельно для каждой из ваших машин.

• меньше излишних работ по техническому обслуживанию, так как вам нужно просто поддерживать один набор инструментов в актуальном состоянии

• более высокая степень согласованности, поскольку один и тот же набор инструментов будет доступен во всех системах

ПРОТИВ

• Вы попали в ловушку, если какие-либо необходимые инструменты для восстановления сети просто хранятся в общем сетевом ресурсе.

• единственная точка отказа - если сервер NFS не работает без какой-либо резервной копии, ни одна из ваших систем не будет работать вообще.

• проблемы совместимости - особенно если задействованы разные аппаратные архитектуры, вам придется прибегнуть к symlink, LD_PRELOAD и всем остальным, что вряд ли когда-либо будет управляемым.

• инструменты, требующие setuid, не будут работать, если папки являются общими nosuid

• необходимо поддерживать базу данных пользователей NIS или LDAP, чтобы обеспечить согласованное отображение UID.

• Затраты на безопасность - поддержание всей инфраструктуры Kerberos или IPSec для обеспечения безопасности NFS само по себе кажется огромными затратами.

• медленная работа - задержка сети и накладные расходы на шифрование украдут достаточное количество вычислительной мощности.

• отсутствует изоляция ваших систем - если одна из систем скомпрометирована, все они скомпрометированы.

• противоречивые данные управления пакетами - поскольку все обновления будут установлены в одной центральной мастер-копии, базы данных пакетов ваших клиентов не будут ничего знать о используемых в настоящее время версиях программ и библиотек.

Вероятно, не все перечисленные минусы будут соответствовать вашим конкретным настройкам, поскольку мой опыт исходит из попытки поделиться небольшим набором инструментов в очень разнородной среде, включающей целую кучу различных архитектур и операционных систем, которые вскоре превратились в кошмар, пока вы, кажется, кажетесь намереваться работать с очень однородной (однородной) средой.

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