我使用LDAP（主要）作为用户身份validation的后端（pam，samba，web，…）。
现在我正在尝试将LDAP数据库迁移到新的root-dn。
旧的root-dn： dc=local
新的root-dn： dc=example,dc=com
这个过程很简单，例如
转储到ldif
改变ldif文件中的root-dn（例如用sed）
丢弃旧的数据库
导入ldif
现在，我想确保，众多的客户端不会经历过多的停机时间（由于root-dn的改变），因为（afaict）所有的客户端在configuration中都有根DN的硬编码。
我很担心，因为当我切换root-dn时，我必须手动更新每个客户端，所以最后一次客户端更新将会有一个长时间的停机时间（当然，不是停机时间，但用户将无法进行身份validation…）
所以我正在考虑在新的root-dn下暴露我的树，直到所有客户端上的configuration都被迁移，最终使用proxy 。
我的方法是否正确（例如最佳实践）？ 有（更好）替代品吗？
在Univention的专业服务工作期间，我曾在多个类似的项目中工作过，而问题描述中缺less的一件事就是实际使用LDAP。
你需要检查的第一个问题是
一旦确定了LDAP服务器的附件，就可以计划每个服务的停机时间。
对于实际的停机时间，我发现rest往往比两个系统并行运行要好。 在一个系统上并行运行两个LDAP服务器或两个LDAP基础通常需要在两个系统中进行更改并使其保持同步，并最终导致更多的工作和问题，然后突然转变。
如果你想最大限度地减less停机时间，虚拟化或第二个物理服务器将是一条路。 用您的LDAP克隆系统，然后从networking中删除它。 按照自己的描述对克隆进行更改。 更改新服务器的IP和主机名以匹配高效的ldap服务器。 最好testing你的大部分应用程序是否有任何影响。 closures旧服务器并将networking连接到新服务器。 自动更改不失败转移的应用程序。
在整个过程中，旧服务器的LDAP中的任何更改都需要复制到新服务器。 请注意，某些服务，计算机（尤其是连接到Samba的Windows）或用户可能会在不告诉pipe理员的情况下更改其密码。
如果使用脚本切换虚拟networking接口，则可以将LDAP的停机时间降至几秒。
你的方法是完全合理的。
您可能会失去迁移旧客户端的影响力，并且在我有限的经验（Oracle DS）中，代理LDAP带来了新的挑战，但这是处理这种转换的已知方式。