Форум проекта Pro-LDAP.ru
Администрирование OpenLDAP => Конфигурация через cn=config => Тема начата: d06pbiu от 14 Март 2013, 14:37:48
-
Всем доброго времени суток!
Просматривал лог ldap'a и обнаружил вот такого типа сообщения:
Mar 14 11:39:28 ldapserv slapd[12674]: <=bdb_equality_candidates: (uidNumber) not indexed
Mar 14 11:39:31 ldapserv slapd[12674]: <=bdb_substringing_candidates: (uid) not indexed
В из документации вычитал что, если такие сообщения появляются довольно часто, то нужно нужно провести индексацию этих атрибутов. Проверил как часто данные сообщения появляются:
# grep indexed /var/log/ldap.log | cut -d " " -t 7,8 | sort | uniq -c
6 <=bdb_equality_candidates: (gidNumber)
191647 <=bdb_equality_candidates: (uidNumber)
537 <=bdb_equality_candidates: (uniqueMember)
11 <=bdb_substringing_candidates: (uid)
Для того чтобы проиндексировать эти атрибуты сделал вот что:
0) Остановил slapd;
1) Сделал экспорт каталога в ldif (это меня и спасло) командой slapcat, а также скопировал директорию где хранится сама БД bdb - /var/log/ldap/;
2) В файл /etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif добавил следующие строки:
olcDbIndex: uidNumber eq
olcDbIndex: uniqueMember eq
3) Запустил slapd;
Запуск прошел успешно, в логах ошибок не было, в директории где хранится bdb появились файлы uidNumber.bdb и uniqueMember, НО только после индексации пользователи не могли удаленно подключаться к серверам(ldap-применяется для аутентификации пользователей) - серверы разрывали соединения.
Началась паника :(
Начал восстанавливать каталог - сначала просто удалил всю директорию с текущей БД /var/log/ldap/ и скопировал туда резервную копию БД (см. выше пункт №2) - запустил slapd - в БД оказался каталог 2х месячной давности, из этого сделал вывод что все изменения в записях каталога slapd не скидывал в БД.
Удалил /var/log/ldap/ - и импортировал ldif каталога - все вернулось на место!
Хотелось бы разобраться в следующий вопросах:
1) Правильно ли провел индексацию?
2) Почему после индексации пользователи не смогли аутенифицироваться через ldap, может у кого было такое же?
3) Индексацию нужно проводить только на мастер-ldap-сервере или нужно делать тоже самое на slave (настроена репликация refreshOnly)?
4) Как сделать чтобы при изменении/добавлении записи в каталог slapd скидывал всю инфу в bdb сразу ну или через заданный промежуток времени?
5) Можно ли делать slapcat при работающем slapd (openldap 2.4.23)?
-
Здравствуйте!
1) Правильно ли провел индексацию?
2) Почему после индексации пользователи не смогли аутенифицироваться через ldap, может у кого было такое же?
Если у Вас OpenLDAP с динамической конфигурацией, то гораздо более правильный способ -- внести изменения on-line (без остановки slapd) с помощью LDIF такого содержания:
dn: olcDatabase={1}bdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: uidNumber eq
olcDbIndex: uniqueMember eq
Это LDIF применяется командой ldapmodify. В этом случае вносятся изменения в конфигурацию и сразу происходит переиндексирование. Если же Вы остановили slapd и исправили конфигурацию вручную, то нужно было перед его повторным запуском выполнить slapindex для создания индексов уже существующих в каталоге записей. А так после повторного запуска slapd у Вас создались пустые индексные файлы -- скорее всего в этом причина неудачного поиска. А после импорта LDIF создались индексы для всех записей, и поиск стал работать как надо.
3) Индексацию нужно проводить только на мастер-ldap-сервере или нужно делать тоже самое на slave (настроена репликация refreshOnly)?
Индексацию нужно проводить на всех серверах, где ведётся интенсивный поиск.
4) Как сделать чтобы при изменении/добавлении записи в каталог slapd скидывал всю инфу в bdb сразу ну или через заданный промежуток времени?
http://pro-ldap.su/tr/zytrax/ch6/bdb.html#checkpoint (http://pro-ldap.su/tr/zytrax/ch6/bdb.html#checkpoint)
Но при корректном останове slapd база данных должна была выгрузиться на диск в любом случае (Вы же экспортировали базу slapcat-ом при остановленном slapd и она нормально экспортировалась). Вообще странно, что у Вас база данных хранится в /var/log/ldap -- не самое очевидно место =) .
5) Можно ли делать slapcat при работающем slapd (openldap 2.4.23)?
Нежелательно, нужно хотя бы перевести базу в режим readonly, а лучше остановить slapd.
Егор
-
Спасибо за помощь, Егор!
Вообще странно, что у Вас база данных хранится в /var/log/ldap...
- чуток очепятался, БД храниться в /var/lib/ldap.
...OpenLDAP с динамической конфигурацией...
Так и есть - раз динамическая конфигурация openldap - так и нужно испоьзовать ее возможностями иначе весь смысл olc теряется)))... что-то я поторопился.
А вот еще такой вопрос будет: <=bdb_equality_candidates: (uidNumber) - встречается очень-очень часто, за двое суток 191647 раза - её то точно надо индексировать, а как быть с <=bdb_substringing_candidates: (uid) - всего 11 раз за те же 2 дня - стоит ли этот атрибут индексировать или, может быть, излишняя индексация "вредна"?
-
Здравствуйте! Индексы создаются для повышения производительности поиска -- вместо того, чтобы обходить в памяти всю базу, осуществляется проход по оптимизированной структуре индексов и выбираются только необходимые записи. Если память позволяет, я бы рекомендовал индексировать все атрибуты, по которым ведётся поиск -- отклик, особенно при большой базе, будет значительно лучше. Если же памяти мало, то тут уже нужно смотреть, хотя поиск без индексов тоже съедает памяти порядочно, к тому же тратятся ресурсы на задействование системы syslog, так что лучше разжиться памятью и всё-таки проиндексировать всё, что задействовано =).
Егор
-
День добрый!
В логе, поставщика репликации заметил вот такие строки:
Mar 14 11:39:28 ldapserv slapd[10643]: <= bdb_equality_candidates: (entryCSN) not indexed
Mar 14 11:39:28 ldapserv slapd[10643]: <= bdb_inequality_candidates: (entryCSN) not indexed
Меня смущает то, что (если я правильно понимаю эти сообщения) сначала предлагается проиндексировать entryCSN (bdb_equality_candidates) и следом же идет сообщение bdb_inequality_candidates - т.е. наоборот убрать(?) индексирование entryCSN eq?
Вот все проиндексированные атрибуты на поставщике, entryCSN - не проиндексирован:
olcDbIndex: uidNumber eq
olcDbIndex: uniqueMember eq
olcDbIndex: uid pres,eq,sub
olcDbIndex: uniqueMember eq
olcDbIndex: contextCSN eq
olcDbIndex: objectClass eq
olcDbIndex: cn,sn pres,eq,approx,sub
Что это значит и как быть?)
-
Здравствуйте!
Насчёт entryCSN -- нужно поставить индекс eq, скорее всего второе сообщение тоже связано с его отсутствием. Насчёт остальных индексов -- pres и approx не нужны точно, их никто никогда не использует (см. http://pro-ldap.ru/tr/admin24/tuning.html#Presence%20indexing (http://pro-ldap.ru/tr/admin24/tuning.html#Presence%20indexing) и пример в http://pro-ldap.ru/tr/zytrax/apa/indeces.html (http://pro-ldap.ru/tr/zytrax/apa/indeces.html)), а по поводу sub -- если каталог используется только для учётных записей различных приложений, поиск типа (cn=*) тоже никогда не выполняется, посему и этот индекс не нужен.
Егор