различия в базах, проблема с репликацией?

[sfmc]

Доброго времени суток!

На новом месте работы мне достались в наследство три LDAP  сервера.
Используюутся, они по большей части для ssh авторизации, но не только.
Я в этой технологи пока-что очень слаб, спросить неукого.
Пока что мне максимум приходилось добавлять пользователей через web-консоль phpldapadmin.
Думаю один из сервеов мастер остальные подчинённые, но это не точно (как это узнать?)
Поскольку на серверах есть каталог "/etc/openldap/slapd.d/cn\=config" - предполагаю, что я пишу в нужной ветке форума.

Недавно произошло следующее:
Добавил пользователя "new_user" через web-консоль phpldapadmin.

Дал ему права на подключение к "HOST-A", но подключится к нему он так и не смог.
'getent passwd' на "HOST-A" не показывает этого пользователя.

Дал ему права на подключение к хосту "B" - всё ок.
'getent passwd' на "HOST-B"  - пользователь виден.

на хосте "А" в конфиге "/etc/ldap/ldap.conf" есть такая строка
URI     ldaps://ldap-server01.com ldaps://ldap-server02.com ldaps://ldap-server03.com


при успешном логине на хост "A", старым пользователем "old_user", в log файле "/var/log/daemon.log"
появляются строчки:
   Feb 20 19:28:49 HOST-A nslcd[1521]: [8c3f32] <authc="old_user"> username changed from "old_user" to "vova.pukin"
   Feb 20 19:28:52 HOST-A nslcd[1521]: [8c3f32] <authc="old_user"> connected to LDAP server ldaps://ldap-server02.com

из чего я сделал вывод что "HOST-A" стучится на второй сервер dap-server02.com (как можно оперативно, без перезагрузок, заставить "HOST-A" стучаться например на ldap-server01.com?)

при момощи утилиты ldapsearch я получил список пользователей от всех серверов:

LDAPTLS_REQCERT=allow ldapsearch -LLLD uid=vova.pupkin,ou=people,dc=hc,dc=com -w 'veryhardpassword' -b 'dc=hc,dc=com' -H 'ldaps://ldap-server01.com/' '(&(objectClass=posixAccount))' 'uid'

LDAPTLS_REQCERT=allow ldapsearch -LLLD uid=vova.pupkin,ou=people,dc=hc,dc=com -w 'veryhardpassword' -b 'dc=hc,dc=com' -H 'ldaps://ldap-server02.com/' '(&(objectClass=posixAccount))' 'uid'

LDAPTLS_REQCERT=allow ldapsearch -LLLD uid=vova.pupkin,ou=people,dc=hc,dc=com -w 'veryhardpassword' -b 'dc=hc,dc=com' -H 'ldaps://ldap-server03.com/' '(&(objectClass=posixAccount))' 'uid'


пользователь "new_user" был получен только от сервера ldap-server01.com.

на серверах ldap-server02.com и ldap-server03.com, в "journalctl -u slapd" пристуствуют такие строки:

  лют 20 16:52:33 ldap-server03.com slapd[953]: <= bdb_substring_candidates: (sudoUser) not indexed

  лют 19 05:47:27 ldap-server02.com slapd[3444]: <= bdb_substring_candidates: (sudoUser) not indexed
  лют 19 05:47:28 ldap-server02.com slapd[3444]: <= bdb_inequality_candidates: (modifyTimestamp) not indexed
  лют 19 05:47:28 ldap-server02.com slapd[3444]: <= bdb_inequality_candidates: (modifyTimestamp) not indexed

прадва я не уверен, что проблема в этом.

Из этого всего я сделал вывод, что что-то не так с репликацией.
Хотелось бы првильно это все разрулить НЕ сломав совсем!!!

Пожалуйста, поделитесь опытом, помогите разрешить сложившуюся ситуацию.

[egor]

Здравствуйте!

Скорее всего проблема действительно в репликации, но разобраться с ней без знания конфигурации всех трёх серверов не получится. Если у Вас актуальная информация в ldap-server01.com, то можете пока временно переключить службы имён своих хостов на этот сервер. Судя по логам, используется nslcd, тогда нужно в файле /etc/nslcd.conf найти и поправить соответствующим образом параметр uri (см. man-страницу). Старые настройки лучше закомментировать, чтобы можно было потом к ним вернуться. После изменения конфигурационного файла перезапустите службу nslcd:

Код: [Выделить]

systemctl restart nslcdи проверьте видимость пользователя:

Код: [Выделить]

id new_user
Чтобы посмотреть конфигурацию slapd обращаясь к конфигурационному каталогу, нужно иметь к этому каталогу административный доступ. Возможно, это парольная аутентификация, тогда нужно знать соответствующий пароль:

Код: [Выделить]

ldapsearch -LLL -H ldaps://ldap-server01.com -D cn=config -w ADMINPASSWORD -b cn=config dn

В Ubuntu при настройках slapd по умолчанию можно получить доступ к этому каталогу без пароля, если выполнить запрос на самом LDAP-сервере от имени системной учётной записи root с использованием SASL-механизма EXTERNAL:

Код: [Выделить]

ldapsearch -LLL -H ldapi:/// -Y EXTERNAL -b cn=config dn

Если хотя бы одна из команд вернёт что-то вразумительное, покажите вывод в ответе или напишите мне в личку. Если ни то, ни другое не получится, можно просто из-под root-а посмотреть содержимое конфигурационного каталога прямо в файловой системе, что-то типа

Код: [Выделить]

ls -Rl /etc/openldap/slapd.d/cn\=config
Вывод команды (с трёх серверов) опять же либо в ответ, либо в личку.

А дальше уже будем смотреть по обстановке.

Егор

[sfmc]

Действительно, поправил конфиг:

Код: [Выделить]

/etc/nslcd.confПерезапустил сервис nslcd
и HOST_A начал смотреть на первый сервер.

Непосредственно на серверах, выполнил команду:

Код: [Выделить]

ldapsearch -LLL -H ldapi:/// -Y EXTERNAL -b cn=config dn
Вот вывод:

Код: [Выделить]

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
No such object (32)
Потом, выполнил на трёх серверах команду:

Код: [Выделить]

ls -lR /etc/openldap/slapd.d/cn\=config
ldap-server01.com:

Код: [Выделить]

/etc/openldap/slapd.d/cn=config:
total 68
-rw------- 1 ldap ldap   538 вер 24 15:44 cn=module{0}.ldif
drwxr-x--- 2 ldap ldap   328 вер 22 15:58 cn=schema
-rw------- 1 ldap ldap 47357 чер  1  2018 cn=schema.ldif
-rw------- 1 ldap ldap   658 чер  1  2018 olcDatabase={0}config.ldif
-rw------- 1 ldap ldap  1213 чер  1  2018 olcDatabase={-1}frontend.ldif
drwxr-x--- 2 ldap ldap   143 вер 24 16:26 olcDatabase={1}hdb
-rw------- 1 ldap ldap  3313 чер  1  2018 olcDatabase={1}hdb.ldif
-rw------- 1 ldap ldap   632 чер  1  2018 olcDatabase={2}monitor.ldif

/etc/openldap/slapd.d/cn=config/cn=schema:
total 84
-rw------- 1 ldap ldap 15546 чер  1  2018 cn={0}core.ldif
-rw------- 1 ldap ldap   921 чер  1  2018 cn={10}ldapns.ldif
-rw------- 1 ldap ldap  1464 вер 22 15:58 cn={11}ldapprofile.ldif
-rw------- 1 ldap ldap 11363 чер  1  2018 cn={1}cosine.ldif
-rw------- 1 ldap ldap  2857 чер  1  2018 cn={2}inetorgperson.ldif
-rw------- 1 ldap ldap  6495 чер  1  2018 cn={3}nis.ldif
-rw------- 1 ldap ldap  1519 чер  1  2018 cn={4}misc.ldif
-rw------- 1 ldap ldap  2633 чер  1  2018 cn={5}sudo.ldif
-rw------- 1 ldap ldap   761 чер  1  2018 cn={6}openssh-lpk-openldap.ldif
-rw------- 1 ldap ldap 15210 чер  1  2018 cn={7}samba.ldif
-rw------- 1 ldap ldap  3883 чер  1  2018 cn={8}ppolicy.ldif
-rw------- 1 ldap ldap  2188 чер  1  2018 cn={9}extension.ldif

/etc/openldap/slapd.d/cn=config/olcDatabase={1}hdb:
total 16
-rw------- 1 ldap ldap 481 чер  1  2018 olcOverlay={0}memberof.ldif
-rw------- 1 ldap ldap 477 чер  1  2018 olcOverlay={1}refint.ldif
-rw------- 1 ldap ldap 483 чер  1  2018 olcOverlay={2}syncprov.ldif
-rw------- 1 ldap ldap 523 вер 24 16:26 olcOverlay={3}ppolicy.ldif
ldap-server02.com:

Код: [Выделить]

/etc/openldap/slapd.d/cn=config:
total 76
-rw------- 1 ldap ldap   512 чер 11  2018 cn=module{0}.ldif
drwxr-x--- 2 ldap ldap  4096 кві 29  2016 cn=schema
-rw------- 1 ldap ldap 47357 чер 11  2018 cn=schema.ldif
-rw------- 1 ldap ldap   658 чер 11  2018 olcDatabase={0}config.ldif
-rw------- 1 ldap ldap  1213 чер 11  2018 olcDatabase={-1}frontend.ldif
drwxr-x--- 2 ldap ldap  4096 тра  3  2016 olcDatabase={1}hdb
-rw------- 1 ldap ldap  3313 кві  3  2019 olcDatabase={1}hdb.ldif
-rw------- 1 ldap ldap   632 чер 11  2018 olcDatabase={2}monitor.ldif

/etc/openldap/slapd.d/cn=config/cn=schema:
total 80
-rw------- 1 ldap ldap 15546 чер 11  2018 cn={0}core.ldif
-rw------- 1 ldap ldap   921 чер 11  2018 cn={10}ldapns.ldif
-rw------- 1 ldap ldap 11363 чер 11  2018 cn={1}cosine.ldif
-rw------- 1 ldap ldap  2857 чер 11  2018 cn={2}inetorgperson.ldif
-rw------- 1 ldap ldap  6495 чер 11  2018 cn={3}nis.ldif
-rw------- 1 ldap ldap  1519 чер 11  2018 cn={4}misc.ldif
-rw------- 1 ldap ldap  2633 чер 11  2018 cn={5}sudo.ldif
-rw------- 1 ldap ldap   761 чер 11  2018 cn={6}openssh-lpk-openldap.ldif
-rw------- 1 ldap ldap 15210 чер 11  2018 cn={7}samba.ldif
-rw------- 1 ldap ldap  3883 чер 11  2018 cn={8}ppolicy.ldif
-rw------- 1 ldap ldap  2188 чер 11  2018 cn={9}extension.ldif

/etc/openldap/slapd.d/cn=config/olcDatabase={1}hdb:
total 12
-rw------- 1 ldap ldap 481 чер 11  2018 olcOverlay={0}memberof.ldif
-rw------- 1 ldap ldap 483 чер 11  2018 olcOverlay={4}syncprov.ldif
-rw------- 1 ldap ldap 480 чер 11  2018 olcOverlay={6}refint.ldif
ldap-server03.com:

Код: [Выделить]

/etc/openldap/slapd.d/cn=config:
total 88
-rw------- 1 ldap ldap   512 тра 21  2018 cn=module{0}.ldif
drwxr-x--- 2 ldap ldap  4096 сер 22  2016 cn=schema
-rw------- 1 ldap ldap 60131 тра 21  2018 cn=schema.ldif
-rw------- 1 ldap ldap   658 тра 21  2018 olcDatabase={0}config.ldif
-rw------- 1 ldap ldap  1213 тра 21  2018 olcDatabase={-1}frontend.ldif
drwxr-x--- 2 ldap ldap  4096 тра  4  2016 olcDatabase={1}hdb
-rw------- 1 ldap ldap  3514 тра 21  2018 olcDatabase={1}hdb.ldif
-rw------- 1 ldap ldap   632 тра 21  2018 olcDatabase={2}monitor.ldif

/etc/openldap/slapd.d/cn=config/cn=schema:
total 80
-rw------- 1 ldap ldap 15546 тра 21  2018 cn={0}core.ldif
-rw------- 1 ldap ldap   921 тра 21  2018 cn={10}ldapns.ldif
-rw------- 1 ldap ldap 11363 тра 21  2018 cn={1}cosine.ldif
-rw------- 1 ldap ldap  2857 тра 21  2018 cn={2}inetorgperson.ldif
-rw------- 1 ldap ldap  6495 тра 21  2018 cn={3}nis.ldif
-rw------- 1 ldap ldap  1519 тра 21  2018 cn={4}misc.ldif
-rw------- 1 ldap ldap  2633 тра 21  2018 cn={5}sudo.ldif
-rw------- 1 ldap ldap   761 тра 21  2018 cn={6}openssh-lpk-openldap.ldif
-rw------- 1 ldap ldap 15210 тра 21  2018 cn={7}samba.ldif
-rw------- 1 ldap ldap  3883 тра 21  2018 cn={8}ppolicy.ldif
-rw------- 1 ldap ldap  2188 тра 21  2018 cn={9}extension.ldif

/etc/openldap/slapd.d/cn=config/olcDatabase={1}hdb:
total 12
-rw------- 1 ldap ldap 598 тра 21  2018 olcOverlay={0}memberof.ldif
-rw------- 1 ldap ldap 477 тра 21  2018 olcOverlay={1}refint.ldif
-rw------- 1 ldap ldap 483 тра 21  2018 olcOverlay={2}syncprov.ldif

Вот логи запуска служб slapd на втором и третьем серверах.

ldap-server02.com:

Код: [Выделить]

лют 21 14:31:36 ldap-server02.com systemd[1]: Starting OpenLDAP Server Daemon...
лют 21 14:31:37 ldap-server02.com runuser[20796]: pam_unix(runuser:session): session opened for user ldap by (uid=0)
...
...
...
лют 21 14:31:37 ldap-server02.com slapd[20798]: @(#) $OpenLDAP: slapd 2.4.44 (Jan 29 2019 17:42:45) $
                                                                      mockbuild@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap-2.4.44/openldap-2.4.44/servers/slapd
лют 21 14:31:37 ldap-server02.com slapd[20800]: slapd starting
лют 21 14:31:37 ldap-server02.com systemd[1]: Started OpenLDAP Server Daemon.
лют 21 14:31:37 ldap-server02.com slapd[20800]: UNKNOWN attributeDescription "PWDFAILURETIME" inserted.
лют 21 14:31:37 ldap-server02.com slapd[20800]: UNKNOWN attributeDescription "PWDCHANGEDTIME" inserted.
лют 21 14:31:37 ldap-server02.com slapd[20800]: UNKNOWN attributeDescription "PWDHISTORY" inserted.
лют 21 14:35:43 ldap-vu01.huntersconsult.com slapd[20800]: conn=1018 op=1 INTERM oid=1.3.6.1.4.1.4203.1.9.1.4
...
...
...
лют 21 17:43:52 ldap-server02.com slapd[20800]: do_syncrep2: rid=101 (-1) Can't contact LDAP server
лют 21 17:43:52 ldap-server02.com slapd[20800]: do_syncrepl: rid=101 rc -1 retrying (4 retries left)
ldap-server03.com:

Код: [Выделить]

лют 21 17:43:52 ldap-server03.com systemd[1]: Starting OpenLDAP Server Daemon...
лют 21 17:43:52 ldap-server03.com runuser[26095]: pam_unix(runuser:session): session opened for user ldap by (uid=0)
лют 21 17:43:52 ldap-server03.com slaptest[26096]: auxpropfunc error invalid parameter supplied
лют 21 17:43:52 ldap-server03.com slaptest[26096]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: ldapdb
лют 21 17:43:52 ldap-server03.com slaptest[26096]: ldapdb_canonuser_plug_init() failed in sasl_canonuser_add_plugin(): invalid parameter supplied
лют 21 17:43:52 ldap-server03.com slaptest[26096]: _sasl_plugin_load failed on sasl_canonuser_init for plugin: ldapdb
лют 21 17:43:52 ldap-server03.com slapcat[26099]: auxpropfunc error invalid parameter supplied
лют 21 17:43:52 ldap-server03.com slapcat[26099]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: ldapdb
лют 21 17:43:52 ldap-server03.com slapcat[26099]: ldapdb_canonuser_plug_init() failed in sasl_canonuser_add_plugin(): invalid parameter supplied
лют 21 17:43:52 ldap-server03.com slapcat[26099]: _sasl_plugin_load failed on sasl_canonuser_init for plugin: ldapdb
лют 21 17:43:52 ldap-server03.com runuser[26106]: pam_unix(runuser:session): session opened for user ldap by (uid=0)
...
...
...
лют 21 17:43:52 ldap-server03.com slapd[26154]: @(#) $OpenLDAP: slapd 2.4.44 (Jan 29 2019 17:42:45) $
                                                                        mockbuild@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap-2.4.44/openldap-2.4.44/servers/slapd
лют 21 17:43:52 ldap-server03.com slapd[26154]: auxpropfunc error invalid parameter supplied
лют 21 17:43:52 ldap-server03.com slapd[26154]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: ldapdb
лют 21 17:43:52 ldap-server03.com slapd[26154]: ldapdb_canonuser_plug_init() failed in sasl_canonuser_add_plugin(): invalid parameter supplied
лют 21 17:43:52 ldap-server03.com slapd[26154]: _sasl_plugin_load failed on sasl_canonuser_init for plugin: ldapdb
лют 21 17:43:52 ldap-server03.com slapd[26156]: slapd starting
лют 21 17:43:52 ldap-server03.com systemd[1]: Started OpenLDAP Server Daemon.
лют 21 17:43:53 ldap-server03.com slapd[26156]: UNKNOWN attributeDescription "PWDFAILURETIME" inserted.
лют 21 17:43:53 ldap-server03.com slapd[26156]: UNKNOWN attributeDescription "PWDCHANGEDTIME" inserted.
лют 21 17:43:53 ldap-server03.com slapd[26156]: UNKNOWN attributeDescription "PWDHISTORY" inserted.
лют 21 17:43:53 ldap-server03.com slapd[26156]: syncrepl_message_to_entry: rid=102 mods check (objectClass: value #8 invalid per syntax)
лют 21 17:43:53 ldap-server03.com slapd[26156]: do_syncrepl: rid=102 rc 21 retrying (4 retries left)




Узнал, что у нас система с несколькими главными серверами и для выполнения операций чтения (поиска) и/или записи (модификации) клиенты могут обращаться к любому серверу и что
бывший сотрудник модифицировал схему на одном из серверов, без остановки slapd!

[egor]

Здравствуйте! Извините, что не сразу отвечаю -- много суеты.

Чтобы работала репликация с несколькими главными серверами чаще всего конфигурацию на них стараются сделать максимально идентичной. В Вашем случае на первом сервере к рабочей БД (olcDatabase={1}hdb) добавлено наложение ppolicy (на двух других его нет), на третьем сервере файл с настройками БД (/etc/openldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif) значительно отличается по размеру от тех же файлов на других серверах. Мне кажется (судя по логам), что проблема именно в наложении ppolicy, хотя, конечно, могут быть и другие факторы.

Для анализа нужны файлы (с трёх серверов):
/etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif
/etc/openldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif
/etc/openldap/slapd.d/cn=config/olcDatabase={1}hdb/olcOverlay={2}syncprov.ldif <-- на разных серверах индекс отличается

Лучше прислать в личку, ну или можно отправить архивы в настроечными каталогами с каждого сервера целиком.

Вообще хотелось бы понять, зачем используется multimaster-репликация? Это оправдано, если у организации несколько территориально разнесённых филиалов, и в каждом своя административная группа ведёт каталог, а потом они синхронизируются друг с другом. Если репликация нужна просто для резервирования и/или балансировки нагрузки, то лучше использовать master-slave схему -- она проще в настройке и управлении, и проблем с ней возникает на порядок меньше.

Егор

[sfmc]

Отправил в личку содержимое файлов (с трёх серверов):
/etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif
/etc/openldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif
/etc/openldap/slapd.d/cn=config/olcDatabase={1}hdb/olcOverlay={2}syncprov.ldif   <-- на третьем сервере индекс {4}

Зачем используется multimaster-репликация, я чесно говоря не знаю, когда я пришел так уже было и мне никто ничего не рассказывал
Все три сервера находятся физически в разным местах, я думаю таким образом организован фейловер.
Мне сказали, что сервера реплицируются как-то по кругу, правда я не знаю как это и полезная ли это инфа.

Бывший сотрудник действительно добавлял в схему ppolicy но, говорит, что она нигде не используется.
Может добавлял что-то еще, єто не известно.
Также неизвестно на каком из серверов он это делал.

phpldapadmin смотрит на ldap-server01 и там есть запись

Код: [Выделить]

cn=ppolicy,dc=hc,dc=com

[egor]

Ситуация, в принципе, соответствует тому, что Вы говорили: имеется некая круговая схема, при которой первый сервер забирает изменения со второго, второй -- с третьего, а третий, видимо, с первого (в конфиге третьего сервера директива olcSyncrepl была в base64, Вы её зачем-то забили X-ми). Судя по приведённым вами логам сервер 2 пытается после запуска провести синхронизацию с сервером 3, но не может к нему подключиться (Can't contact LDAP server) и цепочка обрывается. Так что такая круговая схема никакого фейловера не создаёт, а делает только хуже.

Кроме того, мне не совсем понятны избыточные настройки tls в директиве olcSyncrepl на каждом сервере. Для анализа не хватает ещё файлов /etc/openldap/slapd.d/cn=config.ldif с каждого сервера, там задаётся идентификатор сервера и основные настройки TLS  (я по запарке вместо них попросил в прошлый раз файлы /etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif). Если нетрудно, пришлите мне их тоже в личку.

В общем ситуация запутанная и простого решения "в одну команду" я не вижу, тем более, как я понял, у Вас всё равно нет пароля для доступа к конфигурационному каталогу cn=config (то есть пароля для записи cn=admin,cn=config). Оптимальное (на мой взгляд) решение будет следующим:
1. Снять резервную копию с рабочего каталога dc=hc,dc=com с наиболее полного сервера.
2. Определиться с руководством, какие именно задачи вы хотите решать с помощью репликации.
3. Сделать на стенде соответствующую конфигурацию из трёх серверов и оттестировать репликацию.
4. Если всё будет работать как планировалось, перенести схему в продакшн (на боевые сервера) и залить туда данные из резервной копии рабочего каталога.

Тогда досконально будете знать, как всё устроено и работает и проблем уж точно будет меньше.

Егор

[sfmc]

Декодировал директиву olcSyncrepl третьего сервера из base64 в обычный текс и переслал вам конфиг в личку
вместе с содержимым файлов "/etc/openldap/slapd.d/cn=config.ldif" c трёх серверов.


А для записи "cn=admin,cn=config" есть какой-то отдельный пароль который никак нельзя сбросить?

[egor]

Декодировал директиву olcSyncrepl третьего сервера из base64 в обычный текс и переслал вам конфиг в личку
вместе с содержимым файлов "/etc/openldap/slapd.d/cn=config.ldif" c трёх серверов.

Да, посмотрел. В принципе всё более-менее понятно. Если такой вариант репликации работал, можно попытаться восстановить его. Для начала нужно добиться чтобы прошёл запрос ldapsearch с параметрами из директивы olcSyncrepl по вашему "кругу", то есть первый сервер должен получить данные со второго, второй -- с третьего, а третий -- с первого.

То есть на первом сервере нужно добиться корректного завершения такого запроса (пароль в опции -w поставите какой нужно):

Код: [Выделить]

LDAPTLS_CACERT=/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt ldapsearch -xLLL -H ldaps://ldap-server02.com:636 -D cn=ldapreader,dc=hc,dc=com -w VeryXXXXXXXXX -b dc=hc,dc=com dn
На втором такого:

Код: [Выделить]

LDAPTLS_CACERT=/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt ldapsearch -xLLL -H ldaps://ldap-server03.com:636 -D cn=ldapreader,dc=hc,dc=com -w VeryXXXXXXXXX -b dc=hc,dc=com dn
На третьем такого

Код: [Выделить]

LDAPTLS_CACERT=/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt ldapsearch -xLLL -H ldaps://ldap-server01.com:636 -D cn=ldapreader,dc=hc,dc=com -w VeryXXXXXXXXX -b dc=hc,dc=com dn
Пока эти запросы не отработают без ошибок и превышения лимитов, дальше двигаться бессмысленно.

А для записи "cn=admin,cn=config" есть какой-то отдельный пароль который никак нельзя сбросить?

Сбросить нельзя, можно подменить. Для этого нужно:
1. Сформировать пароль утилитой slappasswd (пример смотрите здесь).
2. Остановить slapd на сервере

Код: [Выделить]

systemctl stop slapd3. Открыть файл /etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif в редакторе с правами root (сначала я бы сделал резервную копию этого файла) и подменить значение атрибута olcRootPW. Он должен будет выглядеть примерно так:

Код: [Выделить]

olcRootPW: {SSHA}nBszmKAlK0bWe3uP4oOIz86FgNMod4xvПоскольку значение не закодировано в base64, после названия атрибута должно быть одно двоеточие (не два!).
4. Поменять в файле /etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif контрольную сумму CRC32, чтобы slapd при запуске не ругался. Как это сделать написано здесь.
5. Запустить slapd

Код: [Выделить]

systemctl start slapd6. Проверить что пароль работает:

Код: [Выделить]

ldapsearch -xLLL -H ldaps://ldap-server01.com -D cn=admin,cn=config -w NEWPASSWORD -b cn=config dn
Повторить на каждом сервере.

Вы говорили с руководством по поводу наведения порядка в настройках каталога в целом и репликации в частности? Что решили?

Егор

[sfmc]

И снова здравствуйте!
Приношу извенения за паузу, был занят другими вопросами.

1. Если я правильно понимаю, сейчас самые актуальные данные на ldap-server01.com и не рабочая репликация.
То если бы она заработала, какой шанс, что сервер ldap-server01.com подтянет данные из ldap-server02.com и
тем самым затрет данные, которые добавлялись в базу при не рабочей репликации?
Вообще не сильно понимаю как они не затерают друг друга...

2. что делает эта команда ?

Код: [Выделить]

LDAPTLS_CACERT=/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt ldapsearch -xLLL -H ldaps://ldap-server02.com:636 -D cn=ldapreader,dc=hc,dc=com -w VeryXXXXXXXXX -b dc=hc,dc=com dn
Она должна также выполниться и на любом компьютере, лишь бы были наместе сертификаты и стояли openldap-utils?

3. По поводу наведения порядка в настройках каталога в целом и репликации в частности, руководство оставляет выбор за мной. А я еще сам не особо понимаю, что для нас лучше.

[egor]

Здравствуйте!

1. Если я правильно понимаю, сейчас самые актуальные данные на ldap-server01.com и не рабочая репликация.
То если бы она заработала, какой шанс, что сервер ldap-server01.com подтянет данные из ldap-server02.com и
тем самым затрет данные, которые добавлялись в базу при не рабочей репликации?
Вообще не сильно понимаю как они не затерают друг друга...

Добавленные данные не сотрутся, но могут (и должны) стереться записи, которые были удалены со второго сервера в период отсутствия репликации. Репликация в OpenLDAP происходит по методу LDAP Content Synchronization protocol (SyncRepl) (RFC 4533), там довольно сложный алгоритм обмена данными, чтобы не пересказывать, могу посоветовать грамотное описание.

2. что делает эта команда ?

Код: [Выделить]

LDAPTLS_CACERT=/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt ldapsearch -xLLL -H ldaps://ldap-server02.com:636 -D cn=ldapreader,dc=hc,dc=com -w VeryXXXXXXXXX -b dc=hc,dc=com dn
Она должна также выполниться и на любом компьютере, лишь бы были наместе сертификаты и стояли openldap-utils?

SyncRepl -- это расширение обычного поискового запроса Search протокола LDAP. Поэтому пока поисковый запрос, на котором основана синхронизация, не выполнится без ошибок, не заработает и сама синхронизация. В данной команде я сэмулировал тот поисковый запрос, который прописан у Вас в директиве olcSyncrepl в настройках slapd. Если запрос в таком виде не исполняется или исполняется с ошибками (например, часто при настройке репликации не учитываются лимиты на количество запрашиваемых записей), то репликация работать не будет. Надеюсь, я понятно объяснил.

Да, это обычная команда ldapsearch, выполняющая стандартный поисковый запрос. Её можно выполнить откуда угодно. Но если она не отработает корректно на сервере 1, то этот сервер будет не в состоянии синхронизироваться с сервером 2. Всё просто.

3. По поводу наведения порядка в настройках каталога в целом и репликации в частности, руководство оставляет выбор за мной. А я еще сам не особо понимаю, что для нас лучше.

Надеюсь, прочтение материал по ссылке, которую я привёл выше, поможет разобраться с репликацией и принять осмысленное решение.

Егор

[sfmc]

Все три комманды

Код: [Выделить]

LDAPTLS_CACERT=/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt ldapsearch -xLLL -H ldaps://ldap-server0X.com:636 -D cn=ldapreader,dc=hc,dc=com -w VeryXXXXXXXXX -b dc=hc,dc=com dnна всех трех серверах
выдают 1199 dn записей из LDAP базы и завершаются так

Код: [Выделить]

Size limit exceeded (4)

[egor]

Ну да, это довольно распространённый недочёт при настройке репликации: администраторы забывают про установленные по умолчанию ограничения на количество возвращаемых записей. Если Вы сменили пароль у пользователя cn=admin,dc=config , то можно сделать такой LDIF-файл:

Код: [Выделить]

dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcLimits
olcLimits: dn.exact="cn=ldapreader,dc=hc,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited

и применить его на всех трёх серверах командой типа:

Код: [Выделить]

LDAPTLS_CACERT=/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt ldapmodify -x -H ldaps://ldap-server01.com -D cn=admin,cn=config -W -f ./add_limits.ldif

После этого ещё раз протестировать поисковый запрос с помощью ldapsearch.

Егор

[sfmc]

Пароль я еще не менял, по вашей же рекомендации, о бессмысленном движении дальше, пока эти запросы не отработают без ошибок и превышения лимитов.

Хочу уточнить.
Какой шанс, что при смене пароля, что-то пойдет не так что даже не поможет возвращение обратно, забекапленного файла /etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif ?
Просто оч.стрёмно, у нас на этом авторизация пользователей завязана и черт его знает какие еще сервисы через него могут авторизироваться.

И еще, для подификации схемы, мне полюбому нужен именно этот пароль?
И если да, то по логике вещей сотрудник который правил схему, тоже должен был пользоатся именно этим паролем?

или это не считается модификацией схемы?

Код: [Выделить]

LDAPTLS_CACERT=/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt ldapmodify -x -H ldaps://ldap-server01.com -D cn=admin,cn=config -W -f ./add_limits.ldif

[egor]

Какой шанс, что при смене пароля, что-то пойдет не так что даже не поможет возвращение обратно, забекапленного файла /etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif ?
Просто оч.стрёмно, у нас на этом авторизация пользователей завязана и черт его знает какие еще сервисы через него могут авторизироваться.

Еще раз проверил свою инструкцию по замене пароля -- если всё сделать по ней, ничего не умрёт. По сути, LDIF-файл (в виде которого представлены настройки slapd) -- это обычный текстовый файл, в котором имена атрибутов ассоциируются со значениями. Меняя значение атрибута olcRootPW, Вы всего лишь заменяете одно тектовое значение на другое. Максимум, что может пойти не так -- это Вы получите ещё один неработающий пароль для olcRootDN (если неправильно сгенерируете его утилитой slappasswd), все остальные настройки slapd останутся без изменений. В общем, здесь нет никакой магии, обычный текстовый файл с настройками, вот и всё. Тем более изменение настроечного каталога не повлияет на рабочую БД с учётками пользователей.

Естественно, как и перед любыми изменениями настроек, нужно сделать резерную копию и директории /etc/openldap/slapd.d , и рабочей БД (при остановленном slapd). Если случится страшное и slapd не запустится, просто вернёте /etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif обратно, для этого и делается бэкап.

Если уж делать совсем правильно, то нужно протестировать изменения конфигурационного каталога на макете, а потом воспроизвести эти изменения в продакшн. В принципе, так должно происходить всегда, потому что экспериментировать на продакшн-системе, по меньшей мере, самонадеянно и непрофессионально -- всегда можно нарваться на неожиданные последствия.

И еще, для подификации схемы, мне полюбому нужен именно этот пароль?
И если да, то по логике вещей сотрудник который правил схему, тоже должен был пользоатся именно этим паролем?

или это не считается модификацией схемы?

Код: [Выделить]

LDAPTLS_CACERT=/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt ldapmodify -x -H ldaps://ldap-server01.com -D cn=admin,cn=config -W -f ./add_limits.ldif

Современный способ настройки slapd -- это конфигурационный каталог cn=config. Разработчики OpenLDAP отказались от плоского конфигурационного файла slapd.conf в пользу конфигурационного каталога в первую очередь потому, что можно, не останавливая работу slapd (что очень важно в нагруженных системах), внести изменения, которые сразу же будут приняты и отразятся на работе сервиса. То, что Вы называете "модификацией схемы", как мне кажется, относится именно к внесению изменений в настройки slapd посредством модификации конфигурационного каталога cn=config. В мире LDAP-каталогов термин "схема" имеет другое значение и относится к схеме данных каталога, так что фраза "модифицировать схему без перезагрузки" может несколько дезориентировать собеседника. Если я правильно Вас понял, и Вы имели ввиду именно изменение настроек slapd, то давайте впредь будем использовать такую терминологию.

По сути, конфигурационный каталог cn=config ничем не отличается от других LDAP-каталогов, изменения в него вносятся с помощью стандартных запросов Modify протокола LDAP (это можно сделать через LDAP-браузер типа phpldapadmin или применением LDIF-файлов с помощью консольных утилит типа ldapmofify). Важный момент -- для модификации данных любого каталога нужно иметь соответствующие права на выполнение модификации. Пользователь, DN которого указано в значении атрибута olcRootDN в настройках каталога, получает неограниченные права на доступ к этому каталогу (по аналогии с учёткой root в Unix-системах). Для Вашего рабочего каталога это будет пользователь cn=admin,dc=hc,dc=com , для каталога cn=config -- пользователь cn=admin,cn=config , каждый из них может выполнять любые действия, но именно со своим каталогом. Для того, чтобы пользователь авторизовался в системе, ему нужно пройти аутентификацию, для этого и задаётся пароль в атрибуте olcRootPW.

Резюме: Внести изменения в настройки slapd путём модификации каталога cn=config можно (и нужно) без остановки сервера slapd -- для этого данный каталог и был разработан. Чтобы внести изменения в cn=config нужно обладать правами для модификации этого каталога, чаще всего для этих целей применяют аутентификацию от имени пользователя, указанного в атрибуте olcRootDN, с паролем из атрибута olcRootPW.

Надеюсь, стало понятнее. Егор