Я использую LDAP, который (в основном) используется в качестве бэкэнда для аутентификации пользователей (pam, samba, web, ...).
Сейчас пытаюсь перенести LDAP-базу данных на новый root-dn.
старый root-dn: dc=local
новый root-dn: dc=example,dc=com
Процесс достаточно простой, например.
дамп в ldif
измените root-dn (например, с помощью sed) в файле ldif
удалить старую базу данных
импорт ldif
Теперь я хотел бы убедиться, что у многочисленных клиентов не будет чрезмерных простоев (из-за изменения root-dn), поскольку (afaict) все клиенты имеют корневое DN, жестко запрограммированное в конфигурациях.
Я волнуюсь, потому что, когда я переключаю root-dn, мне приходится вручную обновлять каждого клиента, поэтому последний обновленный клиент будет иметь длительное время простоя (ну, не простои, но пользователи не смогут пройти аутентификацию ...)
Итак, я думал о том, чтобы открыть свое дерево как под старым, так и под новым root-dn до тех пор, пока конфигурация на всех клиентах не будет перенесена, в конечном итоге используя proxy.
Правильно ли мой подход (например, лучшая практика)? Есть ли (лучшие) альтернативы?
Во время моего пребывания в профессиональной службе Univention я работал над несколькими похожими проектами, и в описании проблемы не хватает одной вещи: для чего фактически используется LDAP.
Первый вопрос, который вам нужно будет проверить:
После того, как вы определили, что подключено к серверу LDAP, вы можете спланировать время простоя для каждой службы.
Что касается фактического времени простоя, я обнаружил, что перерыв часто бывает лучше, чем параллельная работа двух систем. Параллельная работа двух LDAP-серверов или двух LDAP-серверов в одной системе часто влечет за собой необходимость внести изменения в обе системы и обеспечить их синхронизацию, что приведет к большему количеству работы и проблем, чем может быть внезапный сдвиг.
Если вы хотите минимизировать время простоя, лучше всего подойдет виртуализация или второй физический сервер. Клонируйте систему с помощью LDAP, а затем удалите ее из сети. Внесите изменения в клон, как вы описали сами. Измените IP-адрес и имя хоста нового сервера, чтобы они соответствовали продуктивному серверу ldap. Желательно протестировать большинство ваших приложений на предмет возможных последствий. Выключите старый сервер и подключите сеть к новому. Измените приложения, которые не падают автоматически.
В течение всей процедуры любые изменения в LDAP старого сервера необходимо реплицировать и на новый. Просто имейте в виду, что некоторые службы, компьютеры (особенно Windows, подключенные к Samba) или пользователи могут менять свои пароли, не сообщая об этом администратору.
Время простоя LDAP можно свести к минимуму до пары секунд, если переключить виртуальный сетевой интерфейс с помощью скрипта.
Ваш подход вполне разумен.
Вы можете потерять влияние при миграции устаревших клиентов, и по моему ограниченному опыту (Oracle DS) прокси-сервер LDAP создает новые проблемы, но это известный способ обработки такого перехода.