十多年来，我一直在我的小办公室的完整 Debian 环境中工作（目前有 1 台服务器、7 名用户、3 台台式机、4 台笔记本电脑）。身份验证基于 Kerberos，用户配置文件在 LDAP 中管理，$HOME 在 pam_mount 或 autofs 的帮助下通过 NFSv4 提供给所有客户端。对于在本地局域网上工作的桌面用户来说，此设置非常合适。
两年前，我开始为笔记本电脑用户使用相同的设置。 WiFi 连接导致了一些额外的缓慢，并且可以肯定的是，一旦用户尝试在办公室外使用笔记本电脑，速度就会变得非常慢。优化 $XDG_{CACHE,DATA,CONFIG}_HOME 并研究 Firefox on NFS 的具体优化让事情变得更好一些。
我现在正在考虑将 $HOMES 转移到笔记本电脑+台式机。如果设备出现故障，用户可以切换设备，这很好，但这种情况只是偶尔发生一次。牺牲这种灵活性来获得更快的日常用户体验似乎是一个不错的决定。如果我可以在启动和关闭时将本地 $HOME 双向同步到中央服务器，那么可能根本不需要权衡......
- “unison”似乎是保持本地 $HOME 与中央副本同步的良好候选者，但它似乎需要服务器和客户端之间完全相同的版本，而我无法承诺。
- “lsyncd”似乎是一个非常好的候选者，但我似乎没有找到任何使用该工具用于其 $HOME 目录的用户故事......
- 我什至简单地浏览了“GlusterFS”，但这似乎是一个不平凡的替代品。任何人都有任何经验和最佳实践可以分享吗？我不介意进行一些实验，但我担心我错过了上述的一些明显的缺点......谢谢！
答案1
我用同步事物对于与此类似的设置，无论是完整的主目录还是主目录的子集。它可以双向或单向同步文件；如果用户从未在两个不同的地方对相同的文件进行更改，那么它是透明的，即使存在冲突的更改，它也能很好地应对 - 它不会丢失数据。
它在一定范围内适用于倾斜版本。我让它在各种手机和电脑上运行；手机自动跟踪最新版本，计算机使用已安装的发行版中的任何版本。完整的主目录同步只能在具有相同发行版的计算机上真正起作用（因为配置文件的更改），但部分同步适用于不同的设置。
Syncthing 在 LAN 上运行得非常好，但它也支持通过 Internet 同步，并且是可配置的，以便您可以将其调整到您感兴趣的任何信任级别。
答案2
正如 @marcus-müller 指出的那样，此功能被广泛称为“漫游用户配置文件”，它主要围绕两个支柱构建：
- 用户凭证
- 用户 $HOME 目录
第一个通常通过 LDAP+Kerberos 等集中式系统以及客户端上的 SSSD 来解决。第二个问题可以使用 NFSv4 和 krb5/krb5i/krb5p 来解决，但如果您的客户端使用 WiFi 或位于远程位置，则可能会导致速度缓慢。
如果您想为用户放弃集中式 $HOME，但又不想完全放弃集中式设置的灵活性，解决方法可能是：
- 登录后，运行 rsync 脚本（如果本地 $HOME 不存在则创建本地 $HOME，并）将本地 $HOME 与中央 $HOME 双向同步
- 注销后，运行 rsync 脚本将所有本地更改上传到中央 $HOME
- （可选）执行间歇同步
GDM 可以设置为在登录 ( /etc/gdm/PostLogin/Default) 和注销 ( /etc/gdm/PostSession/Default) 时运行脚本。可以为间歇性同步设置 cronjob 或 systemd 计时器。
我想到的一些注意事项：
- 尝试限制 $HOME 目录的大小，例如使用配额和一个单独的目录，用户可以在其中存储共享文档（仍然可以通过 NFS 共享，而不会造成整体缓慢的损失）
- 优化 rsync 脚本以省略缓存和 tmp 目录（或者可能只是将 $XDG_CACHE_HOME 和 $XDG_DATA_HOME 重新定位到 $HOME 之外）
/编辑：我发布了一个 shell 脚本来帮助同步本地 $HOME 与远程 $HOME：https://github.com/zenlord/vagabond.sh- 欢迎发表评论:)
答案3
在登录期间从中央服务器拉取主目录并在注销时将其同步回来也可以通过 PAM 来完成pam 脚本模块 - 使用它来调用适当的 rsync 命令。
答案4
“unison”似乎是保持本地 $HOME 与中央副本同步的良好候选者，但它似乎需要服务器和客户端之间完全相同的版本，而我无法承诺。
您可以在服务器上安装多个版本。在 Unison 配置文件中进行设置addversionno = true以使其在服务器上运行。unison-VERSION
您可以在服务器上安装多个版本。如果您不想自己构建的麻烦，那么官方二进制文件Debian 软件包仅依赖于 Glibc。官方软件包目前是在 Ubuntu 18.04 上构建的，但实际上它们甚至可以在旧系统上运行。
如果您安装自己的版本，您当然必须监视安全问题。我不记得曾在 Debian 中看到过安全建议，而且（相对较新的）中也没有。Github 问题跟踪器但这并不意味着它不会发生。
请注意，不仅 Unison 的版本必须匹配，而且构建它们所用的 OCaml 版本也可能必须匹配。另一方面，操作系统和CPU架构不需要匹配。
所以从技术角度来看，Unison 就可以了。然而，我不确定从用户的角度来看这是否合适。当冲突发生时，用户必须说出如何协调。这是任何双向同步系统所固有的，因此这里的问题不是是否使用 Unison，而是是否使用双向同步。如果目标是允许用户在多个设备上交替工作，则确实需要双向同步。但如果目标只是在设备损坏时允许快速故障转移，那么备份和恢复是更好的方法。