Open Source LDAP-проекты

Не так давно единственной доступной Open Source LDAP-системой был OpenLDAP (изначально основанный на коде Мичиганского университета), но сейчас положение дел изменилось. Вам могут понравиться 389 Directory Server (бывший Fedora Directory Server), также основанный на разработках Мичиганского университета, OpenDJ (ответвление от OpenDS — Java-реализации LDAP от Sun, на сегодняшний момент неактивной) или ApacheDS (Apache Directory) также написанный на Java. Все эти замечательные службы каталогов вместе с OpenLDAP предоставляют богатейший выбор возможностей и функций в сфере Open Source LDAP.

На наш взгляд, наличие нескольких проектов ничего, кроме пользы в деле поступательного развития служб каталогов, принести не может. В своём руководстве, в дополнение к информации об OpenLDAP, мы решили добавить документацию по ApacheDS как представителю второго поколения служб каталогов с рядом интересных возможностей, которые, как нам кажется, указывают то направление, в котором LDAP будет развиваться.

Нам бы очень хотелось, чтобы участники разных проектов меньше конфликтовали и не забывали про вежливость друг к другу, поскольку наличие разных реализаций идет на пользу не только пользователям, но и сообществам разработчиков. Далее приведена наша оценка этих проектов. Однако, следует учитывать, что каждый из них имеет уникальные особенности и множество верных последователей. Эта оценка лишь отражает нашу точку зрения в данный момент времени, и, конечно, она основана на том, что мы знаем (хотя много ли мы знаем?).

Примечание: просто пропустите этот раздел, если Вам не нравится то, что здесь написано. Если же Вам кажется, что мы что-то упустили или неправильно поняли, и Ваш священный долг нам об этом сообщить, то на каждой странице Вы найдете две ссылки, по которым с нами можно связаться. Мы обязательно ответим Вам в том же духе, в котором Вы напишете.

OpenLDAP - широко известная и заслуженно считающаяся эталонной служба каталогов, основанная на оригинальном исходном коде Мичиганского университета. Первоначальный код с годами был существенно изменен, реструктурирован и доработан. Поскольку он написан на языке программирования C, мы считаем что он всегда будет работать быстрее, чем код, написанный на Java. Возможно, когда-нибудь это положение изменится (с введением Java-компиляторов и т. п.), но что-то не верится. Дискуссии на этот счёт ещё продолжаются. Одни утверждают, что с ростом производительности CPU разница между программами на этих языках теряет былое значение, другие же считают, что производительность ввода/вывода является существенным сдерживающим фактором в любых условиях. До версии 2.2 в OpenLDAP больше уделяли внимания реализации стандартов, нежели функциональным особенностям, но начиная с версии 2.4 система приобрела такие значимые функции, как конфигурация времени исполнения, продвинутая репликация, и даже репликация с участием нескольких главных серверов (multi-master). Поскольку OpenLDAP реализует почти всё, что указано в стандартах, он может быть довольно сложен в настройке, особенно если Вы пытаетесь интегрировать его в гетерогенную среду AD. Кроме того, проект имеет особенность менять что-то в каждой новой версии. Так, конфигурационный файл, исправно работавший в версии x, ругается в версии y, а исправленный вариант ругается вновь в версии z. Это резко контрастирует с такими программами как Apache, где кажется, что конфигурационный файл имеет безграничную власть. И всё же мы считаем, что для больших проектов с достаточным количеством рабочих ресурсов (людей/знаний) и для проектов с неизвестным количеством ресурсов, OpenLDAP - правильный выбор, и он будет летать даже на относительно слабом железе.

Проект 389 Directory Services (бывший Fedora Directory Server) также основан на коде Мичиганского университета. В течение своей жизни он не раз преобразовывался и был известен как Netscape Directory Server, Redhat Directory Server и, наконец, стал именоваться 389. Написан на C и должен обладать сходной с OpenLDAP производительностью. Обладает продвинутыми функциями, такими как конфигурация в реальном времени, репликация с участием нескольких главных серверов (multi-master). Мы уверены, что новшества продолжат появляться. Отметим, что за первые 18 месяцев (или около того) своего существования под новым именем большинство изменений проекта было направлено на исправление ошибок и увеличение производительности, а не на наращивание функционала. Достойно и похвально одновременно.

Мы не большие поклонники Java - складывается впечатление, что этот язык вобрал в себя худшие черты C++, да ещё и не имеет указателей (это была шутка, но если с чувством юмора у Вас туговато, просто вспомните, что мы программируем на C и Ruby, и посочувствуйте нам). Java - очень продуктивный и распространённый язык, позволяющий в короткие сроки написать значительное количество функций и обеспечить работу практически на любой платформе "из коробки", если только Вы готовы смириться с более скромной (по сравнению с C) производительностью и огромным объемом требуемой памяти. Оба новичка в классе LDAP с открытым исходным кодом (OpenDS и ApacheDS) решили использовать Java.

Всё более очевидными становятся реальные шаги Open Source LDAP (каталогов) в сторону упрощения установки и конфигурации безопасных каталогов, способных тесно интегрироваться с AD для обеспечения управления идентификацией и других возможностей в гетерогенных средах. Идеальным решением, на наш взгляд, будет установка в один клик всего сразу (LDAP, базы данных, kerberos, ssl), приемлемая рабочая конфигурация "из коробки" и простота расширения (функциональности и рабочих характеристик) с помощью инструментов высокого уровня. Мы считаем это основными требованиями к каталогам, содержащим от 100 до 200 000 записей. Если же записей больше, на первый план выходят увеличение ресурсов для их поддержки и соображения производительности. Тот факт, что LDAP основан на стандартах, позволяет относительно безболезненно мигрировать от одной реализации службы каталогов к другой и даёт пользователям возможность выбирать реализацию с оптимальными характеристиками (функциональности, либо производительности) в зависимости от изменения потребностей.

Мы решили сосредоточиться на ApacheDS - представителе нового поколения LDAP-серверов, приближающемуся к описанному нами выше уровню функциональности. В частности, мы отмечаем Directory Studio (основанный на Eclipse) и идеи проекта по оптимизации доступа к данным за счет использования возможностей классических транзакционных баз данных, таких как хранимые процедуры и триггеры. Решение сосредоточиться на ApacheDS совсем не говорит о нашем негативном отношении к OpenDS, за которым мы продолжаем следить с большим интересом.

Проблемы, комментарии, предположения, исправления (включая битые ссылки) или есть что добавить? Пожалуйста, выкроите время в потоке занятой жизни, чтобы написать нам, вебмастеру или в службу поддержки. Оставшийся день Вы проведёте с чувством удовлетворения.

Нашли ошибку в переводе? Сообщите переводчикам!