分散的用户pipe理

我还没有看到一个开源的解决scheme，但我们之前已经推出了自己的解决scheme。 拥有root run rsync和同步/etc/passwd ， /etc/shadow和包含授权SSH密钥的主目录是相对简单的。

有一点需要记住 – /etc/passwd和/etc/shadow的“主”副本需要具有所有系统上所有用户的详细信息。 这意味着如果你有一台机器用MySQL，另一台机器用Apache，passwd / shadow文件将需要同时包含mysql用户和www-data用户。 这导致在某些机器上passwd / shadow的条目比需要的更多。

另外需要注意的是：尽可能在部署/设置的时候尽可能做到这一点，因为在创build“主”时最终可能会遇到UID冲突。 如果您在已经运行的系统上执行此操作，则需要确定哪个用户具有哪个UID，并相应地更改每个系统上的目录/文件权限。

即使给出了警告，我仍然说LDAP。 集中式身份validation单点故障是一个多年以来已知的问题，这就是为什么Windows摆脱了WinNT的PDC / BDC模式，并采用Active Directory的多主分布式模式。 Novell的eDirectory（一个非常优秀的LDAP服务器）已经有15年的历史了。 通过缓慢的WAN连接，两者都可以很好地暂时与authenticationnetworking的其余部分分离，并且尽pipe通常挂起/重新引导/重build过程能够标记所有IT，但它们仍然起作用。 除了延长停机时间（一天或更长时间）之外，这是一个很大程度上解决的问题。

就我所见，在开放源代码领域没有那么多。 OpenLDAP确实在多个LDAP服务器之间进行复制，从而为您提供容错function。

分支出来，如果你有一个活动目录环境来与Samba一起工作，那么就有了使用AD来处理多主机身份处理的方法。 如果一个DC掉电，它会和其他DC通话。 如果您不害怕仍在开发的Samba 4，您甚至可以build立一个完全基于Linux的AD环境，并在您的客户端服务器上使用winbind来处理分布式身份validation。

最简单的解决scheme是拥有一个主系统和一个在单个节点上运行的cron作业，以定期对密码，影子和组文件进行rsync同步。 虽然这感觉像一个讨厌，肮脏的黑客。

从更广泛的意义上说，你可以使用puppet作为一个全面的configurationpipe理工具。 这包括用户帐户。 实际上，您可以全局定义所有用户属性和组成员身份。 然后，在机器组或每台机器上，您可以定义可访问系统的组或单个用户。 由于authentication和授权是在本地进行的，所以即使您的傀儡pipe理员被closures，用户仍然可以login。 你只会失去变化传播。

由于傀儡只pipe理您明确定义的文件和服务，因此可以轻松集中pipe理某些方面，同时在本地pipe理其他方面。

这就是为什么活动目录需要（好，几乎总是）多个服务器。 所以当他们中的一个死了，你没有拧。

如果你有一个任意规模的用户群，你不想依靠分散的pipe理，即使是通过类似puppet的东西。 移动添加和更改（MAC）将没有乐趣。 完全一样。 此外，没有集中authentication，你需要pipe理本地帐户，桑巴帐户，htaccess帐户…在哪里/你可以/集中authentication每一个人。

为了您自己的理智，请重新考虑集中authentication。

会这样的工作吗？ 显然，他们使用MySQL来扩展OpenLDAP安装并复制它。

我认为Kerberos也可以设置为分布式的。 这是一个较老的文章 ，稍微讨论一下。

我不知道你的networking中是否有任何Windows AD系统，但是如果你这样做，你可以设置模块进行authentication 。

我仍然说LDAP是最简单/最好的select。 疯狂可靠，很容易维护。 我已经在生产中运行了多年的主/从LDAP对，没有任何错误。 在我以前的工作中，他们为20-30台服务器和数百台工作站提供了authentication。 据我所知，他们从来没有因故障而失败。 当我故意故障切换（重新启动/升级/等）没有人注意到。

这就是说，有一种解决scheme几乎完全符合你的描述，但是具有集中pipe理的优势： NIS 。 它通过一个客户端 – 服务器协议分发密码，主机，组等，但据我所知，如果服务器消失，它完全能够继续工作。 这有点复杂，但是我能想到的每个类似nix的操作系统都支持它。

LDAP非常棒，但是确实增加了一些复杂性，你可能没有办法处理。 此外，您将不得不在服务器上构build工具和configurationpipe理以使用LDAP。 虽然Linux中的PAM模块（可插入authentication模块）在支持您的某些需求方面有很长的路要走，但是它们可能无法满足所有需求。

我也可能会build议使用puppet （ http://reductivelabs.com/products/puppet/ ）。 虽然我没有用太多的东西，但是作为一个完整的解决scheme，您可能不是使用LDAP，而是作为添加工具和解决LDAP不支持的方法。

虽然这不是一个好的方法，但可以在ldap客户机（实际上是服务器）上复制ldap数据库（或其中的一部分）

这样做的弱点在于数据库在ldap客户端被损坏的时候被破坏了，优点是你将拥有大量的副本，使你的数据非常安全，如果主数据库和从属数据库之间的连接断开，你可以继续使用副本代替

我会和其他人一起提出build议，并提出LDAP。 如果你真的想要本地passwd文件，可以考虑从LDAP生成它们。 你可以将它们集中生成，然后分发（puppet，rsync等），也可以让每个客户端自己生成。 如果LDAP服务器不可用，则本地passwd文件仍然存在。 在那里安装LDAP服务器并维护这些信息使您可以继续使用或创build供应和用户pipe理所需的工具，因此，如果您决定信任您的networking/设置冗余服务器，则可以进行非常简单的迁移path。