Re: Re: CGP LDAP performance

Я не передергиваю. Прочтите внимательно. Да, для того, чтобы сделать эффективный "generic" server - в CGatePro Local Units надо добавить поддержку нескольких индексов (там сейчас просто создается один - на DN, и всё). Сделать это, конечно, надо - но насущной нужды нет, потому и не делается. Хотя в основном там довольно-таки "пионэрская" задача - индексы-то есть, надо просто GUI сделать для их задания-манажмента. И совсем другой вопрос - делать что-то типа аутентикации пользователей - через LDAP. Мало того, что протокол для этого малопригодный, Вы натыкаетесь тут на проблему источника данных и их обработки. Данные в CGatePro - это отнюдь не база данных, это некая база плюс куча правил - например, того же routing. И на "плоскую", "фиксированную" базу она не может ложиться в принципе - без переноса всех тех же алгоритмов рутинга в программы, которые что-то из этой базы пытаются вытащить.

Тут дело не в LDAP, в Directory как месте хранения информации по юзерам. CGatePro ее там не хранит, а если и хранит - в случае тех же Directory-based DOmains - то использует не "в лоб", а все равно пропустя через внутренний Routing.

Для этого, собственно, и был придуман LDAP Provisioning - когда мы обращаемся через LDAP к серверу, а он понимает, что нам нужно, и вместо обращения к "тупой" Directory - делает нечто, что от него хотят, и возвращает резултат, согласно тому, что от него хотели - а вовсе не из Directory (которой может и не быть).

Сделано это было именно для provisioning (добавить-стереть-переименовать-заапдейтить), и для нужд Routing verification годится мало. Можно что-то придумать, чтобы годилось - и тогда можно будет это использовать. Но вот зачем это делать таким кружным путем, если можно сделать прямо через CLI - непонятно. Потому что "ценных мозгов" в этих LDAP Plugin насколько я знаю, нету- и если их переписать нормально, то Вы их перепишете целиком. Так пишите тогда сразу на CLI. проблемы "переносимости" тут тоже не проходят - так как даже скрипт, написанный на LDAP не будет работать не только для 2 разных продуктов, но даже для двух инсталяций одного и того же продукта, потому что он будет завязан не на directory schema (для которой есть хоть какой-то стандарт), но на directory layout - для которой стандарта нет, не было, и уже вряд ли когда нибудь будет.

On Tue, 13 Apr 2004 11:39:37 +0400
  <CGatePro@mx.ru> (Michael Kulakov) wrote:
> [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?
>
> С уважением,
> Михаил Кулаков
>
> ##################################################################
> Вы получили это сообщение потому, что подписаны на список рассылки
> <CGatePro@mx.ru>.
>
> Чтобы отписаться, отправьте сообщение на адрес <CGatePro-off@mx.ru>
> Чтобы переключиться в режим дайджеста - mailto:<CGatePro-digest@mx.ru>
> Чтобы переключиться в индексный режим - mailto:<CGatePro-index@mx.ru>
> Для административных запросов адрес <CGatePro-request@mx.ru>
>
>
>

Sincerely,
Vladimir Получено Tue Apr 13 08:13:25 2004