我有几个非常相似的 Xen 客户机：相同的架构、相同的操作系统 (Debian)，通常差异在于 RAM 和磁盘空间。我想使用特定的 VM 来执行特定任务，例如，一个用于 VPN 和 SSH，另一个用于 Web 服务器等。
大多数指南都展示了 NFS 如何导出 /home，但我感兴趣的是导出基本系统，如 /usr/bin、/sbin 等......（实际上可能不是 /etc，因为特定的软件）。
我考虑将所有新内容（非基础/特定）推送到 /user/local 并仅导出该内容，但我必须在那里保留一个零配置结构，并且会破坏与包管理器的兼容性，使任何系统升级无效。
我想我正在寻找一些类似于哑终端的变体。
这可行吗？有什么大的优点和缺点吗？
答案1
我没有尝试分享所有的系统工具集，所以我很可能只是在胡乱猜测。不过，我认为实现你的计划并不容易。
在管理共享工具带来的整套库依赖关系时，您肯定会遇到一些麻烦。
根据要求，以下是我想到的一些优点和缺点：
赞成
由于您不必为每台机器单独存储所有内容，因此硬盘存储的消耗更少。
减少冗余维护工作，因为您只需保持一套工具保持最新状态
由于所有系统上都提供同一套工具，因此一致性更高
反对
如果任何恢复网络所需的基本工具只是存储在网络共享上，那么您就陷入困境了。
单点故障 - 如果 NFS 服务器瘫痪且没有任何备份，那么您的所有系统都将无法运行。
兼容性问题 - 特别是如果涉及不同的硬件架构，您将不得不求助于符号链接、LD_PRELOAD 以及几乎无法管理的任何程度。
如果文件夹是共享的，则需要 setuid 的工具将无法运行 nosuid
必须维护 NIS 或 LDAP 用户数据库以确保一致的 UID 映射。
安全开销 - 维护整个 kerberos 或 ipsec 基础设施仅仅为了保证 NFS 的安全似乎是一笔巨大的开销。
运行缓慢——网络延迟和加密开销将消耗大量的计算能力。
缺少系统隔离——如果其中一个系统受到损害，则所有系统都会受到损害。
不一致的包管理数据 - 由于所有更新都将安装在一个中央主副本中，因此客户端的包数据库将对当前正在使用的程序和库版本一无所知。
可能并非所有列出的缺点都适合您的特定设置，因为我的经验源于尝试在非常异构的环境中共享一小组工具，该环境涉及一大堆不同的架构和操作系统，但很快就变成了一场噩梦，而您似乎打算在一个非常同质（统一）的环境中工作。
尽管如此，在全身心投入这样的冒险之前，我最好三思而后行。