Последние сообщения

Страницы: [1] 2 3 ... 10
1
Какой шанс, что при смене пароля, что-то пойдет не так что даже не поможет возвращение обратно, забекапленного файла /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.

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

Хочу уточнить.
Какой шанс, что при смене пароля, что-то пойдет не так что даже не поможет возвращение обратно, забекапленного файла /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
3
Ну да, это довольно распространённый недочёт при настройке репликации: администраторы забывают про установленные по умолчанию ограничения на количество возвращаемых записей. Если Вы сменили пароль у пользователя 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.

Егор
4
Все три комманды
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)
5
Здравствуйте!
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. По поводу наведения порядка в настройках каталога в целом и репликации в частности, руководство оставляет выбор за мной. А я еще сам не особо понимаю, что для нас лучше.
Надеюсь, прочтение материал по ссылке, которую я привёл выше, поможет разобраться с репликацией и принять осмысленное решение.

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

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. По поводу наведения порядка в настройках каталога в целом и репликации в частности, руководство оставляет выбор за мной. А я еще сам не особо понимаю, что для нас лучше.
7
Декодировал директиву 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
Повторить на каждом сервере.

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

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


А для записи "cn=admin,cn=config" есть какой-то отдельный пароль который никак нельзя сбросить?
9
Ситуация, в принципе, соответствует тому, что Вы говорили: имеется некая круговая схема, при которой первый сервер забирает изменения со второго, второй -- с третьего, а третий, видимо, с первого (в конфиге третьего сервера директива 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. Если всё будет работать как планировалось, перенести схему в продакшн (на боевые сервера) и залить туда данные из резервной копии рабочего каталога.

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

Егор
10
Отправил в личку содержимое файлов (с трёх серверов):
/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


Страницы: [1] 2 3 ... 10