Извините, если об этом уже спрашивали, но когда я искал похожие проблемы, я получил такие результаты, как эти (это не имеет смысла для меня).
Я пытался настроить 389-ds с помощью документации Red Hat Directory Server 11 на двух полностью обновленных серверах Rocky Linux 8.6. Мои серверы — supplier1.example.com и supplier2.example.com — находятся в одной подсети. Я настроил файл /etc/hosts каждого сервера, используя их частный IP-адрес и имя хоста, и проверил подключение, проверив IP-адрес и имя хоста другого сервера. Порты 389 и 636 открыты для TCP. Совместно используемыми суффиксами являются «dc=example,dc=com.
Экземпляры сервера каталогов были созданы с использованием интерактивного режима dscreate (LDAP через TCP 389, LDAPS через TCP 636, самозаверяющие сертификаты и т. д.). Я подозреваю, что проблема кроется где-то в этих самоподписанных сертификатах и отсутствии доверия между двумя системами, но я даже не знаю, как это исправить.
Спасибо за чтение этого.
Используя приведенные ниже примеры команд, я смог создать соглашения о репликации...
Сервер 1:
sudo dsconf -D "cn=Диспетчер каталогов" ldap://supplier1.example.com репликация \
включить --suffix="dc=example,dc=com" --role="supplier" --replica-id=2 \
--bind-dn="cn=менеджер репликации,cn=config" --bind-passwd="пароль"
sudo dsconf -D "cn=Диспетчер каталогов" ldap://supplier1.example.com repl-agmt \
создать --suffix="dc=example,dc=com" --host="supplier2.example.com" --port=389 \
--conn-protocol=LDAP --bind-dn="cn=менеджер репликации,cn=config" \
--bind-passwd="пароль" --bind-method=ПРОСТОЙ --init \
пример соглашения между поставщиком1 и поставщиком2
Сервер 2:
dsconf -D "cn=Directory Manager" ldap://supplier2.example.com репликация \
enable --suffix="dc=example,dc=com" --role="supplier" --replica-id=1 \
--bind-dn="cn=менеджер репликации,cn=config" --bind-passwd="пароль"
sudo dsconf -D "cn=Диспетчер каталогов" ldap://supplier2.example.com repl-agmt \
создать --suffix="dc=example,dc=com" --host="supplier1.example.com" --port=389 \
--conn-protocol=LDAP --bind-dn="cn=менеджер репликации,cn=config" \
--bind-passwd="пароль" --bind-method=ПРОСТОЙ --init \
пример-договор-поставщик2-поставщику1
Первоначально документация требовала, чтобы команды соглашения о репликации использовали LDAPS поверх 636, но, когда я пытался, эта репликация всегда терпела неудачу. Вот отрывок из пробега
$ ldapsearch -x -b "cn=mapping tree,cn=config" -D "cn=Directory Manager" -w пароль objectClass=nsDS5ReplicationAgreement -LL
...
nsds5replicaLastUpdateStatus: ошибка (-2) Проблема с подключением к реплике — ошибка LDAP: локальная ошибка (ошибка подключения)
nsds5replicaLastUpdateStatusJSON: {"state": "красный", "ldap_rc": "-2", "ldap_rc_text": "Локальная ошибка", "repl_rc": "16", "repl_rc_text": "ошибка подключения", "дата": «2022-05-26T21:58:31Z», «message»: «Ошибка (-2) Проблема с подключением к реплике — ошибка LDAP: локальная ошибка (ошибка подключения)»}
nsds5replicaUpdateInProgress: ЛОЖЬ
nsds5replicaLastInitStart: 20220526212655Z
nsds5replicaLastInitEnd: 19700101000000Z
nsds5replicaLastInitStatus: ошибка (-2) — ошибка LDAP: локальная ошибка — ответ не получен
nsds5replicaLastInitStatusJSON: {"state": "красный", "ldap_rc": "-2", "ldap_rc_text": "Локальная ошибка", "repl_rc": "255", "repl_rc_text": "ответ не получен", "conn_rc" : "0", "conn_rc_text": "операция выполнена успешно", "date": "2022-05-26T21:27:10Z", "message": "Ошибка (-2) - ошибка LDAP: локальная ошибка - ответ не получен "}