nixp.ru v3.0

30 декабря 2024,
понедельник,
15:43:25 MSK

Войти Постучаться

nss_ldap: could not search LDAP server error

GNU/Linux, UNIX, Open Source → Программное обеспечение

Anarchist написал 9 октября 2008 года в 16:18 (4349 просмотров) Ведет себя как мужчина; открыл 258 тем в форуме, оставил 4097 комментариев на сайте.

Есть FreeBSD 6.2-RELEASE #0 хост.

С настроенной и реально нормально работающей системной авторизацией через OpenLDAP 2.3 (вот Шуруп сподобится вывесить статью — можно будет дать на неё ссылку).

Жизнь заставила потренироваться на нём с жёсткой оптимизацией (в том числе с изменением умолчательных параметров, кстати, где бы почитать про их взаимосвязь?).

И вот, при подаче не дотягивающих до нормального значения тестовых нагрузок я вижу в системном логе следующие строки:

[root@mx4 /var/log]# grep "could not search LDAP server" messages
Oct  9 10:11:07 mx4 named[609]: nss_ldap: could not search LDAP server - Server is unavailable
Oct  9 10:11:24 mx4 slapd[754]: nss_ldap: could not search LDAP server - Server is unavailable
[root@mx4 /var/log]# bzcat messages.*bz2 | grep "could not search LDAP server"
Oct  8 13:29:07 mx4 cron[30698]: nss_ldap: could not search LDAP server - Server is unavailable
Oct  8 16:12:15 mx4 cron[99335]: nss_ldap: could not search LDAP server - Server is unavailable
Oct  8 16:13:58 mx4 cron[99931]: nss_ldap: could not search LDAP server - Server is unavailable
Oct  8 17:39:10 mx4 named[609]: nss_ldap: could not search LDAP server - Server is unavailable
Oct  8 17:39:27 mx4 slapd[754]: nss_ldap: could not search LDAP server - Server is unavailable

В логах slapd’а никакой крамолы не нахожу.

Есть подозрение, что затык на уровне тех самых нежно и трепетно любимых параметров ядра (kern.maxfiles уже задран от умолчательного ~2х, моя практика показывает, что если просто увеличивать kern.maxfiles, то вероятен затык ещё на чём-то, но на этот раз подсказки в логах не ищутся).

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

Ответить Цитировать
Yam
1

копать следует в направлении nss_ldap.conf, конфиг в студию, посмотрим.

Ответить Цитировать
GooglieS
2

Целостность базы ЛДАП не нарушенна?

Ответить Цитировать
Anarchist
3
GooglieS
Целостность базы ЛДАП не нарушенна?

Нет.

Когда нагрузка падает всё возвращается к норме.

Ответить Цитировать
Anarchist
4
Yam
копать следует в направлении nss_ldap.conf, конфиг в студию, посмотрим.

Думаешь?

Пожалуйста

host 127.0.0.1
base dc=mydomain,dc=ru
uri ldap://127.0.0.1/
ldap_version 3
binddn  uid=admin,dc=mydomain,dc=ru
bindpw $password
rootbinddn uid=admin,dc=mydomain,dc=ru
port 389
scope one
bind_timelimit 8
bind_policy soft
pam_password {SSHA}
nss_base_passwd            ou=Users,dc=mydomain,dc=ru?one
Ответить Цитировать
unix_apologet
5

вы не с той стороны начинаете траблшутинг. и наличие в проблемных логах слова nss_ldap отнюдь не означает, что копать надо конфиг nss_ldap. Yam — это было вам.

Anarchist

такая надпись при высокой нагрузке означает, что сервер LDAP просто не справляется с запросами. и рыть надо, для начала, в сторону показания диагностических утилит при высокой нагрузке (я думаю каких — вам объяснять не надо). потом рыть в сторону конфига slapd.conf, на предмет отсутствия индексов, на предмет выбора подходящего backend для хранения LDAP базы, также — советую ознакомится с http://www.openldap.org/doc/admin24/tuning.html#Caching если эти параметры еще не тюнились

Ответить Цитировать
Anarchist
6
unix_apologet
такая надпись при высокой нагрузке означает, что сервер LDAP просто не справляется с запросами.

Логично предположить :)

Причём это утверждение содержится ещё в вопросе.

unix_apologet
и рыть надо, для начала, в сторону показания диагностических утилит при высокой нагрузке (я думаю каких — вам объяснять не надо).

Не надо переоценивать меня.

Был бы благодарен, если бы Вы раскрыли тему диагностики системы в случае пиковых нагрузок.

unix_apologet
потом рыть в сторону конфига slapd.conf, на предмет отсутствия индексов, на предмет выбора подходящего backend для хранения LDAP базы, также — советую ознакомится с http://www.openldap.org/doc/admin24/tuning.html#Caching если эти параметры еще не тюнились

База индексирована.

Я же написал: используется OpenLDAP 2.3…

И система перегружена не только (не столько) LDAP’ом.

Ответить Цитировать
unix_apologet
7
Anarchist
Не надо переоценивать меня.

Был бы благодарен, если бы Вы раскрыли тему диагностики системы в случае пиковых нагрузок.

top, iostat, vmstat. для начала — хватит вывода top

Anarchist
База индексирована.

Я же написал: используется OpenLDAP 2.3…

И система перегружена не только (не столько) LDAP’ом.

[/quote]

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

по поводу того, какая версия — простите, не заметил. но в моем случае — это непринципиально.

Anarchist
И система перегружена не только (не столько) LDAP’ом.

[/quote]

прекрасно. какие еще подводные камни в вашем вопросе? если вы расчитываете на помощь — дайте сразу ВСЮ информацию. что работает еще на сервере, что вы крутили уже руками (sysctl, в ядре)?

Ответить Цитировать
Anarchist
8
unix_apologet
top, iostat, vmstat. для начала — хватит вывода top

Проходили и не ограничивались.

Ещё как минимум lsof, ipcs и uptime.

Да, почти забыл, и sockstat.

unix_apologet
почему бы сразу не привести сюда конфиг? если вы просите помощи, зачем заставлять людей гадать на кофейной гуще?

А Вы уверены, что конфиг slapd’а здесь нужен?

А не что-то иное?

unix_apologet
по поводу того, какая версия — простите, не заметил. но в моем случае — это непринципиально.

Да, есть мнение, что версия OpenLDAP’а в данном случае не должна быть критична.

unix_apologet
прекрасно. какие еще подводные камни в вашем вопросе? если вы расчитываете на помощь — дайте сразу ВСЮ информацию. что работает еще на сервере,

Совсем всю — в том числе надёжный способ утопить отвечающих в массиве исходных данных.

unix_apologet
что вы крутили уже руками (sysctl, в ядре)?

Параметры рулятся не только в /etc/sysctl.conf, но и в /boot/loader.conf.

Кстати, может быть Вы сможете ответить почему в FreeBSD 6.X рекомендуют использовать модули? И насколько обосновано это утверждение?

Ответить Цитировать
unix_apologet
9

деточка, вы клоун и пиздобол. я поставил вам прямые вопросы, вы нагадили еще пицот красивых букаф.

особенно я порадовался «утилите диагностики uptime» и lsof, который в данном случае — нахуй не нужен.

без конфига slapd.conf и, как минимум, вывода top — с вами говорить не о чем.

впрочем я сливаюсь из темы. скучновато помогать тем, кто помощи не хочет.

Ответить Цитировать
Anarchist
10
unix_apologet
деточка, вы клоун и пиздобол. я поставил вам прямые вопросы, вы нагадили еще пицот красивых букаф.

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

Понял?

unix_apologet
особенно я порадовался «утилите диагностики uptime» и lsof, который в данном случае — нахуй не нужен.

Пиздобол, ты бы хотя бы включил мозги (я конечно понимаю, что сложно задействовать то, чего нет)…

Документацию («пониманием» которой ты так любишь понтоваться) ты тоже не читаешь.

Иначе бы знал что полезного присутствует в выводе uptime и зачем в данном случае может потребоваться lsof.

Но не сосункам, рулящим всеми параметрами ядра через sysctl (и не подозревающим о существовании /boot/loader.conf) об этом знать…

unix_apologet
без конфига slapd.conf и, как минимум, вывода top — с вами говорить не о чем.

Без демонстрации тобой хотя бы понимания матчасти любые цитирования конфигов — не более чем пустая трата времени и забалтывание темы.

unix_apologet
впрочем я сливаюсь из темы. скучновато помогать тем, кто помощи не хочет.

Действительно.

Лучше — самому уйти (по возможности громко хлопнув дверью).

А то ещё поймают на незнании матчасти.

ЗЫ: Какова обидчивость некомпетентных аффтаров :)))

Ответить Цитировать
Yam
11
Anarchist
Пожалуйста

host 127.0.0.1
base dc=mydomain,dc=ru
uri ldap://127.0.0.1/
ldap_version 3
binddn  uid=admin,dc=mydomain,dc=ru
bindpw $password
rootbinddn uid=admin,dc=mydomain,dc=ru
port 389
scope one
bind_timelimit 8
bind_policy soft
pam_password {SSHA}
nss_base_passwd            ou=Users,dc=mydomain,dc=ru?one




uri ldap://127.0.0.1/

замените на

uri ldapi://%2fvar%2frun%2fldapi/

, соответственно и slapd запускать с параметром -h «ldapi://%2fvar%2frun%2fldapi/», в конфиг дописать строчки:

timelimit 10
bind_timelimit 10
nss_reconnect_tries 4
nss_reconnect_sleeptime 1
nss_reconnect_maxsleeptime 10
nss_reconnect_maxconntries 2

Почему думаю что это поможет, потому что у самого такая же проблема была, nss_ldap цеплялся через ldap:// тоже на каталог расположенный на этой же машине, пока не поменял на ldapi:// и не дописал таймауты и проблема рассосалась.

Ответить Цитировать
unix_apologet
12

Yam

не думаю, что проблема в этом. коннект AF_INET и через AF_UNIX может СИЛЬНО различаться в случае совсем корявой системы. честно — даже пока в голову не приходит, что надо сделать для такого :-\

Ответить Цитировать
Anarchist
13
unix_apologet
не думаю, что проблема в этом. коннект AF_INET и через AF_UNIX может СИЛЬНО различаться в случае совсем корявой системы. честно — даже пока в голову не приходит, что надо сделать для такого :-\

Классический UNIX-сокет и TCP-сокет — суть сильно разные вещи.

База пользователей в LDAP только для локалхоста — хоть даже я могу привести аргументы за, но всё равно — пальба из пушки по воробьям. Локалхостом дело ограничивать не стоит (пусть даже на нём замыкается 95-97% нагрузки).

А вот про таймауты (особенно с учётом того, что я знаю про OpenLDAP) замечание очень интересное (было бы ещё интереснее, если бы ув. тов. Yam хотя бы указал ключик где/как посмотреть умолчательные).

Обязательно обдумаю и опробую. Правда, всё-таки для случая loopback net interface.

Ответить Цитировать
unix_apologet
14
Anarchist
Классический UNIX-сокет и TCP-сокет — суть сильно разные вещи.

с точки зрения приложения — абсолютно одинаковые :) используется один API

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

вообще, если выполнять нормальный траблшутинг, я бы делал так, прежде чем плясать с бубном в конфигах:

1. вынес бы LDAP базу в отдельный раздел. ЕМНИП, она по дефолту в /var, который активно занят другими системными базами и, особенно, логами

2. проверил бы, нет ли избыточных индексов. сильно много индексов — не есть хорошо

3. тюнил бы cachesize

и каждое действие сопровождал бы top/iostat в соседней консоли ;)

Ответить Цитировать
Anarchist
15
unix_apologet
1. вынес бы LDAP базу в отдельный раздел. ЕМНИП, она по дефолту в /var, который активно занят другими системными базами и, особенно, логами

Исходя из моего опыта и представлений о здравом смысле просто вынос в отдельный раздел большого выигрыша не даёт.

Вынос на отдельный физический диск — да, заметно улучшает ситуацию.

unix_apologet
2. проверил бы, нет ли избыточных индексов. сильно много индексов — не есть хорошо

Не поясните ли критерии избыточности?

unix_apologet
3. тюнил бы cachesize

и каждое действие сопровождал бы top/iostat в соседней консоли ;)

Касаемо top у меня есть некоторый скепсис, но не суть важно. :)

С учётом ситуации (нагрузка создаётся не LDAP’ом) я бы скорее смотрел в сторону резервирования ресурсов под LDAP (ещё бы понять что и куда крутить для этого…).

Ответить Цитировать
Anarchist
16
unix_apologet
по поводу таймаутов. бороться надо с причиной, а не со следствием. ну увеличите вы время ожидания ответа. но LDAP то тормозить не перестанет. и не факт, что вы не сделаете хуже, забив его висящими в таймауте коннектами? ну открылся коннект, база работает, трудится, не отбивается по таймауту клиент.. а новые то приходят

А клиент, отбитый по таймауту (в данном случае) возвращается…

Дык вопрос насколько близки умолчательные значения таймаутов к оптимальным?

И как определять эти самые оптимальные?

Ответить Цитировать
unix_apologet
17
Anarchist
Исходя из моего опыта и представлений о здравом смысле просто вынос в отдельный раздел большого выигрыша не даёт.

Вынос на отдельный физический диск — да, заметно улучшает ситуацию.

ну это естественно. я подразумевал это :) мудрено от UFS2 отрезать новый раздел :)

Anarchist
Не поясните ли критерии избыточности?

да все просто. индексировать надо только те поля, по которым ЧАСТО происходит поиск. остальные — зря кушают ресурсы памяти и CPU.

Anarchist
С учётом ситуации (нагрузка создаётся не LDAP’ом) я бы скорее смотрел в сторону резервирования ресурсов под LDAP (ещё бы понять что и куда крутить для этого…).

ОМГ… я уже понял, что у вас не один LDAP. так вот вам надо понять, КАКИХ ресурсов не хватает и ЧТО нужно под LDAP резервировать. каким образом вы это собираетесь сделать, как не используя утилиты диагностики?

Ответить Цитировать
unix_apologet
18
Anarchist
.

Дык вопрос насколько близки умолчательные значения таймаутов к оптимальным?

И как определять эти самые оптимальные?

исходя из моего опыта — они оптимальны. если вам не подходят — то определить их можно только эмпирически — меняя и меряя.

Ответить Цитировать
Anarchist
19
unix_apologet
ну это естественно. я подразумевал это :) мудрено от UFS2 отрезать новый раздел :)

Однако можно учесть/предусмотреть на этапе установки ОС :)

А слоты под жёсткие диски в ряде моделей серверов — ресурс сильно ограниченный.

unix_apologet
да все просто. индексировать надо только те поля, по которым ЧАСТО происходит поиск. остальные — зря кушают ресурсы памяти и CPU.

Направление для поиска по теме сбора данной статистики не укажите?

ИМХО данная формулировка не полна.

unix_apologet
ОМГ… я уже понял, что у вас не один LDAP. так вот вам надо понять, КАКИХ ресурсов не хватает и ЧТО нужно под LDAP резервировать. каким образом вы это собираетесь сделать, как не используя утилиты диагностики?

Дык я же почти сразу говорил, что доля LDAP’а в случае нормальной нагрузки — в пределах единиц процентов. В рассматриваемом случае падает до чуть ли не долей промилле.

Относительно же ресурсов есть подозрение, что проблема не столько в них, сколько в стыках.

Какие утилиты диагностики Вы порекомендуете?

unix_apologet
исходя из моего опыта — они оптимальны. если вам не подходят — то определить их можно только эмпирически — меняя и меряя.

Т.е. по вопросу как их посмотреть Вы не подскажете?

Ответить Цитировать
unix_apologet
20
Anarchist
Направление для поиска по теме сбора данной статистики не укажите?

ИМХО данная формулировка не полна.

в документации по OpenLDAP в разделе tuning описаны наиболее востребованые поля. посмотрите там и сверьтесь со своей ситуацией. вам виднее, какие запросы приходят к вам в базу.

Anarchist
Относительно же ресурсов есть подозрение, что проблема не столько в них, сколько в стыках.

Какие утилиты диагностики Вы порекомендуете?

iostat -x — смотреть wait, svc_t,%b (интерпретация есть в man), gstat, top — обратить внимание на колонку STATE — в каких вызовах/событиях висят ваши сервисы. для начала хватит

Ответить Цитировать
Anarchist
21
unix_apologet
в документации по OpenLDAP в разделе tuning описаны наиболее востребованые поля.

По моему опыту документация OpenLDAP не безупречна :(

Репликацию через slurpd так и не заставил работать (здесь может есть и доля моей вины), момент зависимости выражений, определяющих доступ к дереву от параметров запуска не отражён.

unix_apologet
iostat -x — смотреть wait, svc_t,%b (интерпретация есть в man), gstat, top — обратить внимание на колонку STATE — в каких вызовах/событиях висят ваши сервисы. для начала хватит

Thanks.

Ответить Цитировать
Yam
22

Вы так и будите обсуждать разницу между сокетами и таймаутами или всё же попробуете?

ЗЫ неотчаивайтесь, если не осилили репликацию через slurpd, в ldap > 2.4 используется delta syncrepl и slurpd больше не нужен.

Ответить Цитировать
Anarchist
23
Yam
Вы так и будите обсуждать разницу между сокетами и таймаутами или всё же попробуете?

Понимаете, проблема с OpenLDAP здесь занимает далеко не первое место в рейтинге значимости.

Поэтому понять суть проблемы (и чем грозит забивание на неё) тоже важно.

Yam
ЗЫ неотчаивайтесь, если не осилили репликацию через slurpd, в ldap > 2.4 используется delta syncrepl и slurpd больше не нужен.

Я спокоен как удав. :)

Для ветки 2.3 это тоже не единственный способ репликации.

И, как мне думается, не спроста…

Ответить Цитировать

Последние комментарии

PalarkDevOps as a Service from Palark
24/7 SRE & DevOps service to cover all your Kubernetes needs.