主页 / server / 问题 / 49777
Accepted
blauwblaatje
Asked: 2009-08-05 06:16:22 +0800 CST

去中心化的用户管理

  • 772

我需要为 +/- 30 台 Linux 服务器的服务器群进行一些用户管理。通常我会想到 LDAP 之类的东西，但我们不想依赖需要对其进行身份验证的全局服务器，以防停机或连接中断。

所以我正在考虑编写一些脚本来同步 /etc/passwd 和 /etc/shadow 并检查主目录是否存在。包括在某些服务器上排除某些用户的可能性。

但是……我无法想象我是世界上唯一需要这种东西的人。那么有人知道做这种事情的开源项目吗？

linux user-management

9 个回答

  1. 即使考虑到您的警告，我仍然会说 LDAP。集中式身份验证单点故障是一个已知多年的问题，这就是为什么 Windows 摆脱了 WinNT 的 PDC/BDC 模型并采用了 Active Directory 的多主机分布式模型的原因。Novell 的 eDirectory（除其他外，是一个非常好的 LDAP 服务器）做多主机已经超过 15 年了。两者都可以通过慢速 WAN 链接与身份验证网络的其余部分暂时分离，并且尽管通常会标记所有 IT 的挂起/重新启动/重建过程，但仍然可以正常工作。除了延长停机时间（一天或更长时间）外，这是一个很大程度上已解决的问题。

    只是在开源空间中没有我见过的那么多。OpenLDAP 确实在多个 LDAP 服务器之间进行复制，从而为您提供容错能力。

    稍微扩展一下，如果您确实有一个与 Samba 一起使用的 Active Directory 环境，那么会提供与 AD 一起使用的方法，这些方法将进行多主机身份处理。如果一个 DC 出现故障，它将与其他 DC 对话。如果您不害怕仍在开发中的 Samba 4，您甚至可以建立一个完全基于 linux 的 AD 环境，并在您的客户端服务器上使用 winbind 来处理分布式身份验证。

    • 6
  2. Best Answer

    我还没有看到开源解决方案，但我们之前推出了自己的解决方案。root运行rsync和同步相对简单/etc/passwd，/etc/shadow主目录包含授权的 SSH 密钥。

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

    另一个注意事项：最好在部署/设置时尽早执行此操作，因为您可能最终在创建“master”时处理 UID 冲突。如果您在已经运行的系统上实现此功能，您将需要确定哪个用户拥有哪个 UID，并相应地更改每个系统上的目录/文件权限。

    • 4

  3. 最简单的解决方案是拥有一个主系统和一个在各个节点上运行的 cron 作业，以定期对 passwd、shadow 和 group 文件进行 rsync。不过，这感觉就像一个讨厌的、肮脏的黑客攻击。

    在更广泛的意义上，您可以将puppet用作一个包罗万象的配置管理工具。这包括用户帐户。实际上，您可以全局定义所有用户属性和组成员身份。然后在一个机器组或每台机器上，您定义有权访问系统的组或单个用户。由于身份验证和授权是在本地进行的，即使您的 puppetmaster 已关闭，用户仍然可以登录。您只会丢失更改传播。

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

    • 3

  4. 这就是 Active Directory 需要（嗯，几乎无论如何）多台服务器的原因。这样当他们中的一个死了，你就不会被搞砸了。

    如果您拥有任何规模的用户群，您都不想依赖分散管理，即使是通过 puppet 之类的方式。移动添加和更改 (MAC) 将不好玩。完全没有。另外，如果没有集中身份验证，您将需要管理本地帐户、samba 帐户、htaccess 帐户……因为您/可以/一次集中验证每个人。

    请重新考虑集中式身份验证以确保您自己的理智。

    • 2

  5. 像这样的东西会起作用吗？显然，他们使用 MySQL 来扩展 OpenLDAP 安装并复制它。

    我认为 Kerberos 也可以设置为分布式。这是一篇较旧的文章，对此进行了一些讨论。

    我不知道您的网络中是否有任何 Windows AD 系统，但如果有，您可以设置模块以针对该系统进行身份验证。

    • 1

  6. 我仍然说 LDAP 是最简单/最好的选择。非常可靠，非常容易维护。几年来，我一直在生产中运行主/从 LDAP 对，没有出现任何故障。在我之前的工作中，他们为 20 到 30 台服务器和数百个工作站提供了身份验证。据我所知，它们从未因故障而失败。当我故意进行故障转移（重启/升级/等）时，没人注意到。

    话虽如此，有一个解决方案几乎可以完全按照您的描述进行，但具有集中管理的优势：NIS。它通过客户端-服务器协议分发密码、主机、组等，但据我了解，如果服务器消失，它完全能够继续运行。它有点复杂，但我能想到的每个 *nix 类操作系统都支持它。

    • 1

  7. LDAP 很棒，但它确实增加了一些您可能无法处理的复杂性。此外，您必须在服务器上构建工具和配置管理才能使用 LDAP。虽然 Linux 中的 PAM 模块（Pluggable Authentication Modules）在支持您的某些需求方面大有帮助，但它们可能无法满足所有需求。

    我也可能建议使用类似puppet的东西（http://reductivelabs.com/products/puppet/）。虽然我没有太多使用它，但它对于您来说可能是一个很好的整体解决方案，而不是 LDAP，或者作为一种添加工具和解决 LDAP 没有的情况的方法。

    • 1

  8. 虽然它不是一个很好的，但您可以在 ldap 客户端（实际上是服务器）上复制 ldap 数据库（或其中的一部分）

    这样做的缺点是数据库会随着 ldap 客户端损坏而损坏，优点是您将拥有大量副本，从而使您的数据非常安全，并且如果主数据库和从数据库之间的连接断开，您可以继续使用副本反而

    • 0

  9. 我会附和其余的建议并建议使用 LDAP。但是，如果您真的想要本地 passwd 文件，请考虑从 LDAP 生成它们。您可以在某个地方集中生成它们然后分发它们（puppet、rsync 等），或者您可以让每个客户端生成自己的。如果 LDAP 服务器不可用，本地 passwd 文件仍然可以使用。有了 LDAP 服务器并维护信息，您可以继续使用或创建配置和用户管理所需的工具，因此，如果您决定信任您的网络/设置冗余服务器，那么您可以进行非常简单的迁移小路。

    • 0

相关问题