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