re-openldap iddqd idkfa

А почему форк openldap а не другой ldap сервер? Вроде у редхат был какой то.

Очевидно же, люди уже с ним работали.

Кстати, кто-нибудь может кинуть ссылкой на rationale, которым шапка руководствовалась в принятии решения развивать старый новеловский сервер, а не OpenLDAP. Вангую лицензию.

сходил по ссылке

я думал iddqd idkfa - это codename очередного релиза ))

подразните Ховарда этим.

Я почти не в теме, но по идее если протокол не меняется то должно быть всё равно какой сервер? А их, возможно, как раз не устроило то же, что послужило причиной форка.

Приветствую ваши героические усилия и желаю успехов! НУЖНО!

Имею следующие вопросы:

1. Я всегда был уверен, что LDAP-сервера в первую очередь оптимизируются на чтение (что вполне понятно, если учесть основное назначение LDAP - каталог данных + служба аутентификации). Как я понимаю, вы туда пишете непосредственно биллинговую информацию в реальном времени, откуда и требование высокопроизводительной записи? Я вовсе не говорю, что это «забивание микроскопом гвоздей», просто с таким use-case сталкиваюсь впервые;

2. Будет ли в ReOpenLDAP поддержка SLAPI?

3. (шуточный) А может, вашей конторе просто купить Symas Corp с потрохами? Принять наконец патчи, окультурить код, выпустить нормальный продукт, а скрипача разуплотнить. Ей-богу, он уже всем плешь проел. :)

Удачи!

А почему форк openldap а не другой ldap сервер? Вроде у редхат был какой то.

OpenLDAP + LMDB = MVCC 100% и топовая производительность в LDAP-нише.

С этого «уравнения» начинаются наши «исторические причины».

Кстати, кто-нибудь может кинуть ссылкой на rationale, которым шапка руководствовалась в принятии решения развивать старый новеловский сервер, а не OpenLDAP. Вангую лицензию.

У лицензии OpenLDAP действительно есть специфика - она одна из самых старых, при этом простая и мутная: «The OpenLDAP Foundation may revise this license from time to time».

Мы пока просто отложили эту тему, включая trademark. Новые файлы добавляем под шапкой AGPLv3. В планах проработать переход на AGPL и s/OpenLDAP/ReOpenLDAP/g.

Но кроме лицензии у RH точно была еще одна причина - качество кода в исходном OpenLDAP _очень_ специфическое, местами facepalm.

Я почти не в теме, но по идее если протокол не меняется то должно быть всё равно какой сервер? А их, возможно, как раз не устроило то же, что послужило причиной форка.

На github есть wiki-страница (пока единственная), там уже есть ответы.

1. Я всегда был уверен, что LDAP-сервера в первую очередь оптимизируются на чтение (что вполне понятно, если учесть основное назначение LDAP - каталог данных + служба аутентификации). Как я понимаю, вы туда пишете непосредственно биллинговую информацию в реальном времени, откуда и требование высокопроизводительной записи? Я вовсе не говорю, что это «забивание микроскопом гвоздей», просто с таким use-case сталкиваюсь впервые;

Да, оптимизируются на чтение, тут вы правы. Но «биллинг» (деньги) мы в LDAP буквально не засовываем ;)

Главная причина в том, что LDAP (как протокол, как концепт) присутствует в нескольких местах в инфраструктуре управления мобильной сетью. Запросы чтения можно кэшировать и т.д., а обновления приходиться куда-то «девать». Поэтому, как ни крути, нужен какой-то LDAP-сервер со специфическими параметрами быстродействия. Архитектурно решение не идеально, но нет возможности существенно его перестраивать.

2. Будет ли в ReOpenLDAP поддержка SLAPI?

Пока мы ничего не «выпиливаем» и SLAPI остается «как есть». Но по-хорошему чистка напрашивается.

Пожалуй неправильно ныть что в OpenLDAP масса говнокода, всё-таки это Open Source - хочешь делай лучше... Но проблем все-же очень много, основная масса кода OpenLDAP не прозрачна, плохо покрыта тестами и практика показывает что проблем там «дофига и больше». Куда не копни, везде вылазят какие-то off-by-one, течи памяти, неполная обработка ошибок, race conditions и т.д. Поэтому в реальности масса «фичей» не пригодна к промышленной эксплуатации. Например, динамический конфиг - это вообще сплошные костыли, fixme и падения.

Короче, не ясно что лучше - отрезать всё «по самые уши» оставив только тестируемые нами возможности, либо оставить «корочку» сохнуть дальше.

3. (шуточный) А может, вашей конторе просто купить Symas Corp с потрохами? Принять наконец патчи, окультурить код, выпустить нормальный продукт, а скрипача разуплотнить. Ей-богу, он уже всем плешь проел. :)

Окультурить... разве что собрать секту перфекционистов и переписать, ибо большой технический долг - это писец через гангрену. Если слетать в прошлое лет на 15-20, то я бы просто потер им исходники ;) Если вернуться года на 2 назад с текущим пониманием - то мы бы (наверное) взяли OpenDJ и прикрутили бы к нему какой-нибудь более-менее lock-free backend (LMDB, потроха из wired tiger или prostgresql). А сейчас мы «вступили» и решаем те проблем что имеем.

Если серьезно, то использовать компетенции Symas или еще как-либо их «покупать» - пока не понятно зачем. В коде два слоя проблем, условно:

• «технические» - когда понятно «как надо» и можно найти «где неправильно»;
• «идейные» - когда не ясно «как надо», нет спецификации внутреннего API, roadmap-а на использование блокировок и т.д.

Первые мы сейчас сами фиксим лучше, во вторых Symas (судя по коммитам) «плавает» чуть лучше нашего. А скрипач - да, личность особенная 80/20, иногда очень жесткие перлы выдает.., но обсуждать больше не хочу (мы форкнулись и это хорошо).

Удачи!

Спасибо!

Например, динамический конфиг - это вообще сплошные костыли, fixme и падения.

То есть, зря я старался освоить новые технологии... Впрочем, в моих масштабах это вряд ли будет существенно заметно.