Индексация атрибутов

[d06pbiu]

Всем доброго времени суток!
Просматривал лог 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)?

[egor]

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

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
Но при корректном останове slapd база данных должна была выгрузиться на диск в любом случае (Вы же экспортировали базу slapcat-ом при остановленном slapd и она нормально экспортировалась). Вообще странно, что у Вас база данных хранится в /var/log/ldap -- не самое очевидно место =) .

5) Можно ли делать slapcat при работающем slapd (openldap 2.4.23)?

Нежелательно, нужно хотя бы перевести базу в режим readonly, а лучше остановить slapd.

Егор

[d06pbiu]

Спасибо за помощь, Егор!

Вообще странно, что у Вас база данных хранится в /var/log/ldap...

- чуток очепятался, БД храниться в /var/lib/ldap.

...OpenLDAP с динамической конфигурацией...

Так и есть - раз динамическая конфигурация openldap - так и нужно испоьзовать ее возможностями иначе весь смысл olc теряется)))... что-то я поторопился.
А вот еще такой вопрос будет: <=bdb_equality_candidates:     (uidNumber) - встречается очень-очень часто, за двое суток 191647 раза - её то точно надо индексировать, а как быть с <=bdb_substringing_candidates: (uid) - всего 11 раз за те же 2 дня - стоит ли этот атрибут индексировать или, может быть, излишняя индексация "вредна"?

[egor]

Здравствуйте! Индексы создаются для повышения производительности поиска -- вместо того, чтобы обходить в памяти всю базу, осуществляется проход по оптимизированной структуре индексов и выбираются только необходимые записи. Если память позволяет, я бы рекомендовал индексировать все атрибуты, по которым ведётся поиск -- отклик, особенно при большой базе, будет значительно лучше. Если же памяти мало, то тут уже нужно смотреть, хотя поиск без индексов тоже съедает памяти порядочно, к тому же тратятся ресурсы на задействование системы syslog, так что лучше разжиться памятью и всё-таки проиндексировать всё, что задействовано =).

Егор

[d06pbiu]

День добрый!
В логе, поставщика репликации заметил вот такие строки:

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

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

Что это значит и как быть?)

[egor]

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

Насчёт entryCSN -- нужно поставить индекс eq, скорее всего второе сообщение тоже связано с его отсутствием. Насчёт остальных индексов -- pres и approx не нужны точно, их никто никогда не использует (см. http://pro-ldap.ru/tr/admin24/tuning.html#Presence%20indexing и пример в http://pro-ldap.ru/tr/zytrax/apa/indeces.html), а по поводу sub -- если каталог используется только для учётных записей различных приложений, поиск типа (cn=*) тоже никогда не выполняется, посему и этот индекс не нужен.

Егор