我使用 LDAP（主要）作为用户身份验证的后端（pam、samba、web 等）。
现在，我正在尝试将 LDAP 数据库迁移到新的 root-dn。
旧根 DN：
dc=local新的根 DN：
dc=example,dc=com
这个过程很简单，例如
转储到 ldif
更改 ldif 文件中的 root-dn（例如使用 sed）
删除旧数据库
导入 ldif
现在，我想确保众多客户端不会经历过多的停机时间（由于 root-DN 的更改），因为（据我所知）所有客户端的配置中都有硬编码的 root-DN。
我很担心，因为当我切换根 DN 时，我必须手动更新每个客户端，因此最后更新的客户端将会延长停机时间（嗯，不是停机时间，而是用户将无法进行身份验证......）
因此，我正在考虑将我的树同时公开在旧的和新的 root-dn 下，直到所有客户端上的配置都已迁移，最终使用proxy。
我的方法正确吗（例如最佳实践）？还有（更好的）替代方案吗？
答案1
在我从事 Univention 专业服务期间，我参与了多个类似的项目，问题描述中缺少的一点是 LDAP 的实际用途。
你需要检查的第一个问题是
- 你的服务是否具有足够的容错能力来应对短时间的中断
- LDAP 库是否硬编码到任何地方
一旦确定了连接到 LDAP 服务器的内容，您就可以规划每个服务的停机时间。
对于实际停机时间，我发现暂停通常比同时运行两个系统更好。同时运行两个 LDAP 服务器或在一个系统上运行两个 LDAP 服务器通常意味着您需要在两个系统中进行更改并保持同步，最终会比突然转移带来更多的工作和问题。
如果您想尽量减少停机时间，虚拟化或第二台物理服务器将是最佳选择。使用 LDAP 克隆系统，然后将其从网络中删除。按照您自己描述的方式对克隆进行更改。更改新服务器的 IP 和主机名以匹配高效的 ldap 服务器。最好测试大多数应用程序是否有任何影响。关闭旧服务器并将网络连接到新服务器。更改不会自动故障转移的应用程序。
在整个过程中，旧服务器 LDAP 中的任何更改也需要复制到新服务器。请注意，某些服务、计算机（尤其是连接到 Samba 的 Windows）或用户可能会在不通知管理员的情况下更改密码。
如果您使用脚本切换虚拟网络接口，LDAP 的停机时间可以最小化到几秒钟。
答案2
您的方法完全合理。
您可能会失去迁移旧客户端的能力，并且根据我有限的经验（Oracle DS），代理 LDAP 带来了新的挑战，但这是处理这种转变的已知方法。