ldap_search: а чего это оно так оригинально ищет? :)

0

2

Есть объект разновидности «people»,
его стек objectClass'ов прост до примитивизма:
[objectClass: top]
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson

Теперь: берём за основу фильтра objectClass=person, наследниками которого являются organizationalPerson и inetOrgPerson, ищем так: (&(objectClass=person)(uid=sidorov-ip))
В результате имеем: некий модуль авторизации для Wiki не работает, ldapsearch с этим фильтром раз 5 выдаёт правильный результат и вдруг - начинает возвращать просто «пусто», даже не No such object(32)! OK, меня всё это вводит в лёгкий ступор, я меняю objectClass=person на objectClass=inetOrgPerson - и всё вдруг начинает работать!
OpenLDAP 2.4.23 из состава «стабильного» Debian Squeeze, каталог самый обычный. Пробовал как под админом искать, так и под анонимусом - на результат это никак не влияет (ACL пока не настроены).

Что это за стук под полом, куда смотреть?

Ссылка

←	Список маков и портов на свитчах D-Link, преобразование из DEC в HEX

Прикидываю ... к носу. Нужны мнения.

→

Да, в отладке сервера фильтр отображается как (?objectClass=person), словно он не понимает, что это за objectClass такой и где его взять...

DRVTiny ★★★★★
(27.06.12 17:16:55 MSK) автор топика

Ответ на: комментарий от DRVTiny 27.06.12 17:16:55 MSK

Jun 27 17:28:17 ldap slapd[737]: conn=23900 op=1 SRCH base=«dc=x,dc=y» scope=2 deref=3 filter="(&(objectClass=person)(uid=sidorov-ip))"
Jun 27 17:28:17 ldap slapd[737]: conn=23900 op=1 SRCH attr=uid
Jun 27 17:28:17 ldap slapd[737]: conn=23900 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=

Т.е. все нормально. Дай пример записи - проверю.

~~zgen~~ ★★★★★
(27.06.12 17:34:29 MSK)

Ответ на: комментарий от zgen 27.06.12 17:34:29 MSK

У тебя же не сборка Debian'овская версии 2.4.23, а небось что-то куда более новое. Я не слежу за тем, что в OL фиксят, но очень возможно, что уже в 2.4.24 этот баг исправили. Подозреваю, что в действительности все классы, являющиеся parent для inetOrgPerson'а, не хранятся явным образом (как и очевидный objectClass: top для не-alias'ов) и, возможно, результаты поиска по ним криво индексируются. Так-то оно не мешает, но без wireshark'а я бы просто не знал, в чём проблема.

DRVTiny ★★★★★
(27.06.12 19:09:03 MSK) автор топика

Ответ на: комментарий от DRVTiny 27.06.12 19:09:03 MSK

Я не слежу за тем, что в OL фиксят, но очень возможно, что уже в 2.4.24 этот баг исправили.

У меня 2.4.26 (не debian). Честно говоря, я вообще сомневаюсь, что там есть такой баг - потому что это бы значило что неисправны >1 вида запросов, а это не позволяет вообще как-то эксплуатировать его.

подозреваю что-то другое. Например, не дай бог, правленные схемы ;)