12 августа 2009 г.

Еще немного про LDAP сервера.

На работе затишье. Можно эксперементировать с интересным софтом. Решил пощупать, что ещё есть из свободных LDAP серверов.

Опыт с Fedora Core LDAP Server не удался. См. предыдущий пост.

На вечерних курсах, слушатель напомнил мне что еще есть LDAP от проекта Apache. Решил посмотреть на него.

Все написнао на java. Я не имею ни каких религиозных забобонов по поводу java, но... как то напрягся.

Скачал rpm, написано, что он для Fedora. Следуя инструкции попытался запустить сервер и ту меня ожидал первый сюрприз.

Я пытался сделать, как это принято в System V

/etc/init.d/apacheds start

Фигушки :) они требуют указать дополнительный параметр. Вот так надо запускать:

/etc/init.d/apacheds start default

Интересно, как тогда интегрировать _это_ в System V? rc.local? Не кошерно однако, при живом стартовом скрипте :)

Но оно не заработало :) (кто бы сомневался? :) )

запуск в режиме консоли

/etc/init.d/apacheds console default

показал, что скрипт не может найти свой конфигурационный файл apacheds. Еще бы! Он ведь находится совсем не там, где ожидает скрипт :) Вместо /etc/sysconfig сие чудо лежало в /usr/etc/sysconfig. Пришлось руками копировать файл куда надо.

Следующий запуск показал, что все равно сервер не стартует. Опять неправильное расположкние файлов. Почему то создатель rpm все разместил в /usr/etc, /usr/var, /usr/lib! Но при этом во всех конфигах написан путь к файлам без /usr, прямо от корня. Пришлось лезть в два конфига и править пути. Вопрос - а почему во втором конфиге не прописать все с учетом переменной из /etc/sysconfig/apacheds? Загадака однако.

Все, сервер запустился. Но не все так просто :)

В конфигах, о умолчанию определен dc=example,dc=com, типа с ним можно сразу начинать работать :) ага, СчаЗ. Клиенты LDAP типа gq и компания, при обращении к этой ветке валятся в корку. Родной apache studio этот контейнер в упор не видит :)

Все оказалось гораздо проще, надо ручками создать ldif с описанием этого контейнера и импортировать его в LDAP сервер. Спрашивается - а чем тогда это отличается от OpenLDAP?

И вот, после серии экспериментов у меня возник вопрос - а нафига все оно надо, если есть нормально работающий, без приколов и плясок с бубуном, OpenLDAP?
Отправить комментарий