Re: Re: CGP LDAP performance

[6~Здравствуйте!

On Mon, Apr 12, 2004 at 03:30:31PM -0700, Vladimir A. Butenko wrote:

> >> Да, не так. Не надо ничего искать, просто вынимайте записи по DN
> >> uid=<username>,cn=domain.com (если directory Integration значения
> >> дефолтные), и вот тогда если будет тормозить при числе записей меньше
> >> миллиона - будем разбираться. Если, конечно, при этом еще версия не
> >будет > многолетней давности.
> >
> >правильно искать, безусловно, по dn. но очень много "ldap pluguins"
> >( mod_ldap* etc ) - не делая предположений о том, как образуется dn ищет
> >записи именно таким способом. Поэтому, при подходе: "ищите только по dn"
> >не получится использовать все эти "plugins" совместно с cgp хоть в
> >сколько-нибуль нагруженном варианте.
> >
> >то есть cgp пока нельзя использовать как быстрый, легкий и продвинутый
> >generic ldap server :(

> 
> Можно. Для этого надо индексы по UID создавать. Но дело не в этом. Дело в 
> том, что "технология" в этих плагинах, "заточенных" под OpenLDAP и iPlanet 
> - порочная по определению, и работать не будет по тому же определению. 
> Во-первых, из-за многодоменности CGatePro - см. предыдущее письмо. 
> Во-вторых, собственно, уже не надо - но если хочется....
> 
> Никто мне не мешает сделать ветку в директории 
> uid=musya,cn=host.ru,o=mydarlings, и набить его адресами подружек.
> 
> Ваш "плагин" будет находить адреса в нем так же, как и в "настоящем" 
> поддереве. Это тоже самое, как если бы MSWord искал свои префернсы на диске 
> при помощи поиска ВСЕХ файлов, у которых есть имя msword.*

и ищет :) и даже индекс локальный под full text search для этого построили и процесс переиндексации :)

дело не в этом. если быстрый поиск есть только по dn, который не может не быть не проиндексированный, то приходится, действительно, создавать дополнительные ветки objectclass 'alias', в которых делать ссылки на основную ветку. это не удобно, требует лишних затрат во всем: и на клиенте - создавать больше записей и поддерживать из в consistency, при условии того, что без extensions - ldap не транзакционный протокол и на сервере - просто хранить больше линкованных между собой записей. это можно режить поиском по атрибутам в основной ветки, но для быстрого поиска требуются индексы по атрибутам, по которым идет постоянный поиск.

я помню, что слова "индекс", "база данных" и "oracle" являются ругательными :) дискуссии трех (?) -летней давности про людей с академическим образованием, только создающих сложности практикам, реализующим ldapd - я тоже помню :)

просто хочется получить быстрый, легкий и безпроблемый ldap сервер, которого все еще не было с год назад, когда я последний раз интересовался этой темой. и были расказы, что это cgp, тоже уже годичной давности. можно поискать и найти точные цитаты автора этих расказов :)

на данный момент получается, что использование этого ldap сервера не получается generic, так как в cgp не достаточно эффективно работает ldap_search по атрибутам. сие обидно. способы workarounds - весьма понятный, искать по dn only, проблемы приведены выше.

> >ps. особенно "смешно" выглядит попытка идентификации. Вместо того чтобы
> >взять от пользователя пароль и просто попытаться bind в ldap через
> >dn(login)/password - сначала ищем запись, потом вытастикиваем из нее dn, и
> >уже потом пытаемся ldap_bind по найденному dn. Особо одаренные вырианты
> >пытаются вытащать из ldap пароль и сравнивать его с пользовательским уже
> >на клиентской ( ldap ) стороне.

> 
> Да, именно так и делается. И удивляться тут нечему, увы. Просто яйцеголовые 
> профессора, которые перетаскивали X.500 в Internet слабо себе представляли 
> и X.500, и, главное, Internel - зато знали кучи умных слов, которыми и 
> нашпиговали LDAP стандарт. А шустрые пионэры, которые не понимали ни одного 
> из этих очень умных слов - слабали некие скриптики, которые работали на тех 
> 5 lDAP инсталяциях, которые были у них под рукой. 
> 
> И с тех пор эта тягомотина продолжается. Влезать в нее имеет смысл очень 
> редко, чаще, как в Вашем случае - если пойти на поводу и сделать 
> по-пинэрски, то результат тоже будет пионэрским - будет работать "пока 
> что-то не добавится".

Владимир, не передергивайте :) Поиск по attributes, умный и действительно быстро работаютщий, с индексами, merge по индексам и тд - это далеко не пионерская поделка - сделать честно - достаточно трудоемкая задача. И задачи это - весьма не пионерская, просто не понятно кем она будет оплачена :)

> >> >PS: Изначальная задача уже тут обсуждалась - проверка RCPT на релеях.
> >> >Кто-то нашел способ реализовать не через LDAP?
С уважением,
  Михаил Кулаков Получено Tue Apr 13 07:39:42 2004