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