Ознакомьтесь с нашей политикой обработки персональных данных
  • ↓
  • ↑
  • ⇑
 
19:48 

ПРАВИЛЬНАЯ инциализация OpenLDAP-сервера с динамической конфигурацией

Положим, перед нами стоит задача "с нуля" настроить новый сервер каталогов, при этом использование безнадёжно устаревшего метода конфигурации, - редактирование slapd.conf, - полностью исключено, поскольку завещано нашими предками: "Делай хорошо, а плохо само получится!"
Исходные данные: есть установленный любым путём OpenLDAP-сервер и стандартные утилиты к нему (во многих дистрибутивах по каким-то странным соображениям клиентская и серверная части OL разнесены по разным пакетам, так что в этом случае вам необходимо установить и то, и другое)
Требуется: создать рабочую конфигурацию LDAP-каталога и добавить суффикс dc=example,dc=com, при этом использовать slapd.conf на любом этапе нельзя (мы же твёрдо решили отказаться от этого анахронизма).

Здесь перед вами встаёт дилема: раз нельзя использовать slapd.conf, значит нужно написать конфигурацию каким-либо иным образом. А поскольку известно, что физически на файловой системе дерево конфигурации представляет собой структуру каталогов со вложенными ldif-файлами, то первое, что приходит на ум - это изучение 5-й главы "Руководства администратора OpenLDAP" на предмет того, как бы написать все необходимые LDIF'ы самому (и при этом не сойти с ума, узнав, что operationalAttributes для cn=config никто не отменял). Когда я первый раз решил настроить свой сервер каталогов через cn=config и попытался создать всё дерево настроек вручную, скурпулёзно следуя этой самой 5-й главе, я потерпел фиаско, при этом с пользой потратив время на изучение внутреннего устройства конфигурации. Оказалось, что такой подход - неправильный. Дальнейшее изучение документации, в том числе и man-страниц (для проекта OpenLDAP вообще характерно, что в man'ах можно найти значительно более обстоятельную информацию, нежели в "Руководстве администратора";) привело меня к тому, что можно создать некий простенький стартаповый файл конфигурации slapd.conf, который slapd при запуске со своеобразным "секретным" сочетанием параметров -f <путь_к_slapd.conf> -F <каталог_для_cn=config> - преобразует к формату cn=config'а (впрочем, он это в любом случае делает при каждом запуске) и сам выложит в "каталог_для_cn=config" всю нужную мне структуру. Таким образом я действительно добился результата, в заботливо созданном и подсунутом slapd в параметре -F каталоге и правда появилась структура с нужными ldif'ами, но... при этом получалось, что мне так и не удалось избавиться от slapd.conf, ведь на этапе инициализации он в минималистичном виде, но всё же понадобился. А хотелось не прибегать к помощи slapd.conf'а совсем, к тому же по всем признакам было понятно, что сами разработчики OpenLDAP'а не используют этот неудобный и явно устаревший метод. "А ларчик просто открывался" - решение, оказалось, лежало на поверхности!
Итак, всё НАМНОГО элементарнее, чем вы думали, если вы над этим уже думали, мой дорогой читатель, на что я, честно говоря, очень рассчитываю.
Перво-наперво нужно создать каталог для cn=config, он может называться как угодно и находиться по сути дела где угодно, лишь бы файловая система была доступна на запись и позволяла устанавливать права доступа для UNIX'овых пользователей. Например:

mkdir -p /etc/openldap/slapd.d/example

После создания каталога вам нужно определиться с паролем, который будет использоваться для доступа к конфигурации. Используйте утилиту slappasswd (на самом деле это тот же slapd) для получения шифрованного пароля:

slappasswd -h '{<МЕТОД_ХЕШИРОВАНИЯ>}' -s 'ПАРОЛЬ'

Например:

Команда: slappasswd -h '{MD5}' -s 'topsecret'
Вывод: {MD5}6oR5iLpZcn2/TjTudXJtww==

Если вы немного параноик (что в принципе хорошо) и не привыкли оставлять не предназначенные для чужих глаз сведения в своём history, можете не указывать пароль в открытом виде и опустить опцию -s, но тогда вам придётся два раза вводить одно и то же, как в утилите passwd.
Скопируйте вывод команды slappasswd, например, просто выделив его мышью в окне терминала. Теперь вам предстоит... да-да, написать начальную конфигурацию, которая разрешила бы классическую дилему с курицей и яйцом, возникающую из-за того, что наполнить дерево cn=config можно только после запуска сервера, а сервер не запустить, если для него вообще нет конфигурационной информации.
Но это делается на самом деле даже проще, чем со slapd.conf'ом. Итак, открываем любимый текстовый редактор и пишем:

 

dn: cn=config
objectClass: olcGlobal
cn: config

dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootPW: ШИФР_ПАРОЛЬ


Собственно на место ШИФР_ПАРОЛЬ нужно вставить тот вывод slappasswd, который вы перед этим скопировали.
Вуаля, начальная конфигурация готова, её можно сохранить в файл - например, под именем startup-config.ldif. Теперь всё готово для того, чтобы в правильном формате "скормить" этот файл LDAP-серверу, при этом не запуская его. Для добавления данных в напрямую в бэкенды OpenLDAP, а не через посредство сервера, то есть в режиме оффлайн, предназначена утилита slapadd (опять же, на самом деле это просто ссылка на slapd, имя которой является своеобразным неявным параметром, определяющим, что данному бинарнику следует делать). Шаблон начальной конфигурации, в котором, заметьте, нашего пока ничего, кроме пароля, нет, загружается следующим образом:
slapadd -n 0 -F <КАТАЛОГ_ДЛЯ_cn=config> -l <ФАЙЛ_НАЧАЛЬНОЙ_КОНФИГУРАЦИИ>
Обратите внимание на то, что мы обязательно должны передать утилите slapadd параметр -n 0, что означает "добавить данные в базу номер ноль". Посмотрите на файл начальной конфигурации: в нём описание собственно самой базы cn=config находится в dn: olcDatabase={0}config,cn=config. Следует обратить внимание на число 0, указанное в фигурных скобках - это собственно тот самый индекс базы (для cn=config всегда равен нулю), который мы затем указываем в параметре -n для slapadd. Делать это явным образом нужно потому, что по умолчанию slapadd пытается добавить данные в базу, соответствующую первому инициализированному суффиксу с индексом больше единицы (обычно это уже собственно содержимое каталога, то есть пользовательские данные).
Итак, для примера считаем, что под нужды cn=config мы создали каталог /etc/openldap/slapd.d/example, тогда команда может выглядеть так:
Команда: slapadd -n 0 -F /etc/openldap/slapd.d/example -l ПУТЬ/К/ФАЙЛУ/startup-config.ldif
Вывод: _#################### 100.00% eta none elapsed none fast!
Closing DB...
Убедитесь в том, что теперь каталог cn=config'а не пуст, выполнив в нём ls -lR. Если вы видите структуру каталогов со вложенными ldif'ами, значит всё в порядке, в противном случае перечитайте всё изложенное мной выше и попытайтесь понять, что вы сделали не так :) Вроде бы всё сделали, но остаётся один маленький штришок: поскольку все предыдуще действия были произведены под суперпользователем, а OpenLDAP в целях безопасности должен запускаться с правами собственной учётной записи, если сейчас просто взять и запустить LDAP-сервер указав ему в параметре -F только что инициализированную нами базу cn=config, он не сможет получить доступ к файлам - ведь они принадлежат root и на них утилитой slapadd предусмотрительно установлена маска доступа со сброшенными битами для "группы" и "остальных". Поэтому в каталоге с базой cn=config'а нужно рекурсивно поменять владельца на того пользователя, с правами которого будет запускаться сервер. Для того, чтобы узнать имя этого самого пользователя, посмотрите вывод getent passwd | fgrep -i ldap, скорее всего его так и зовут: "ldap", - хотя в Debian'е, например, традиционно уже решили соригинальничать и назвали его openldap, что не суть важно (в особенности, если вы умеете быстро печатать десятипальцевым методом, который ваш покорный слуга так до сей поры чудесной и не освоил).
В примере после chown -R ldap.ldap /etc/openldap/slapd.d/example мы имеем готовую работоспособную конфигурацию, пусть и простейшую и теперь мы можем запустить сам сервер:



Итак, если вы точно следовали моим рекомендациям, уже сейчас у вас есть сервер OpenLDAP, который больше не нужно перезапускать, все оставшиеся действия по настройке (подключение модулей, расширение схемы, добавление суффиксов) вы будете делать только в режиме "онлайн", изменяя конфигурацию на работающем сервере!

Сделав наш сервер максимально гибким и конфигурируемым благодаря динамическому дереву настроек cn=config, мы конечно же не можем не вопользоваться теперь предоставленными нам широчайшими возможностями для того, чтобы создать суффикс dc=example,dc=net (ведь именно это нам в конечном счёте и нужно, не правда ли?).
Но дабы вы не наступали всё на те же чудные грабли, на которые наступал я и не раз, даже не надейтесь на то, что хотя бы минимально необходимые атрибуты и классы объектов сейчас есть в составе автоматически созданного сервером дерева настроек. Да оно в общем и не мудрено - ведь прописывали же вы все так называемые файлы схем в древнем, как сама история файлике slapd.conf? И ведь там даже core.schema нужно было явным образом указывать, иначе вообще ничего у вас не заработало бы. Ну так я могу вас обрадовать тем, что в случае с cn=config определённый прогресс уже есть и то, что лежит в core по умолчанию будет лежать у вас в cn=schema,cn=config. Всё остальное же нужно добавлять самим. При этом очевидно, что поскольку сама по себе схема каталога интегрирована в дерево cn=config, то и добавлять её составляющие нужно будет как обычные LDIF-файлы: ведь именно то, что мы видим в дереве конфигурации - это и есть представление данных именно в том виде, в котором их читает сервер, эта конфигурация уже не интерпретируется, как раньше происходило с файлом slapd.conf, где include'ы считывались в процессе парсинга. Но где же взять файлы нужных схем в формате LDIF, спросите вы? Вопрос не праздный, потому что никаких утилит преобразования файлов schema в LDIF'ы в поставке OpenLDAP'а нет (что, вообще говоря, довольно странно и вообще вряд ли сей факт имеет какое-о разумное объяснение с учётом того, что до сих пор большинство кустарных схем к огромному количеству самого разного софта так и поставляется в старом формате). Если вы внимательно рассмотрите содержимое каталога /etc/openldap/schema (соответственно, это может быть другой каталог, в зависимости от того, что у вас за система и/или какое значение prefix вы задали на этапе конфигурирования), то найдёте там несколько важных (если не сказать ключевых) и наиболее часто используемых файлов схем в формате LDIF. Любые другие схемы можно добавить, переконвертировав их из schema в ldif довольно простым скриптом на bash, который я приведу чуть позже. А пока давайте просто добавим схемы в том порядке, в котором их взаимные зависимости будут удовлетворены. Поскольку в поставке OpenLDAP'а таких схем маловато, пока что можно особо не заморачиваться взаимозависимостями и сделать это так, как делал я:



Собственно, вся "хитрость" данного подхода заключается в том, что схемы в алфавитном порядке имён файлов грузятся правильно, а если их попытаться "скормить" серверу том порядке, в котором их находит find, возникают конфликты неразрешённых зависимостей. В общем, это всё не суть важно, можно и руками загружать при желании.

Что ж, теперь у нас есть базовый набор схем и можно приступать к настройке суффикса. Впрочем, постойте, а поверх чего этот суффикс будет работать? Ведь наверняка же поверх бэкендов BDB или HDB? А модули для этих бэкендов загружены или, возможно, вполне возможно, всё необходимое статически скомпилировано со slapd? Для того, чтобы узнать, был ли slapd собран полностью статично, попробуйте следующий запрос:



Если в ответ на этот запрос вы получите строку, содержащую olcModuleList - значит у вас модульная конфигурация, если же вы не увидите ничего, значит slapd скомпилирован полностью статически и без поддержки загружаемых модулей.

Для того, чтобы точно узнать, требуются от вас какие-либо дополнительные действия или нет,действуйте по принципу доказательства от противного: попробуйте загрузить LDIF для нового пространства имён (суффикса), например:

 

dn: olcDatabase=bdb,cn=config
objectClass: top
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: bdb
olcSuffix: dc=example,dc=com
olcRootDN: cn=manager,dc=example,dc=com
olcRootPW: ШИФР_ПАРОЛЬ
olcDbDirectory: /var/lib/ldap

Надеюсь, для тех, кто хоть раз настраивал сервер OpenLDAP, всё достаточно очевидно. ШИФР_ПАРОЛЬ сформируйте командой slappasswd по аналогии с тем, как вы это делали для cn=config. В olcDbDirectory прописывается путь к каталогу, в котором будут размещаться файлы базы данных-бэкенда (например, Berkeley DB), то есть это аналог директивы directory в slapd.conf. Если при попытке добавить данный LDIF в дерево конфигурации вы получаете ошибку, свидетельстующую об отсутствии objectClass'а olcBdbConfig, значит, либо не загружен соответствующий модуль (но для этого предыдущая проверка должна была пройти успешно и objectClass olcModuleList присутствует в текущей схеме), либо кто-то (возможно, вы сами) умудрился статически скомпилировать slapd без поддержки Berkeley DB. Аналогично и в случае с HDB.
Если выяснилось, что вам нужно подгрузить модуль, в соответствии с п.п. 5.2.2 "Руководства администратора", добавьте следующий LDIF:

 

dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModuleLoad: ПУТЬ/К/МОДУЛЮ/back_bdb.la


Заметьте, что индексы в фигурных скобках в начале RDN (как тот же "cn={0}module" в Руководстве) на самом деле генерируются сервером автоматически, их нужно указывать явно _только_ в особых случаях (например, когда нужно "раздвинуть" существующие индексы, вставив новый элемент).
Стоит особо отметить, что при истинно модульной конфигурации OpenLDAP, подобной модульной сборке ядра операционной системы, все компоненты по возможности находятся в отдельных подключаемых во время исполнения бинарных файлах с расширением "la". В этих случаях иногда требуется подключить не один-два модуля, а, например, десяток или даже больше. Понятное дело, что каждый раз указывать полный путь к файлам модулей в директиве olcModuleLoad в этом случае несколько нерационально, в особенности если у вас все la-шные файлы лежат в одном и том же каталоге. В этом случае можно добавить директиву olcModulePath, которая выполняет ту же функцию, что и системная переменная PATH - определяет пути поиска файлов по умолчанию. В этом случае LDIF для добавления нужных модулей может выглядеть так:

dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/lib/ldap/bin:/usr/share/samba/ldap/modules:<и т.д.>
olcModuleLoad: back_bdb.la
olcModuleLoad: back_hdb.la
olcModuleLoad: back_sock.la
olcModuleLoad: <ещё_один_модуль>.la

21:04 

Индексы not equal и pres

Индекс pres нужно использовать только для очень редко встречающихся, но часто "искомых" атрибутов
Индекса not equal не существует в природе, но _некоторые_ (сдаётся, мне что двузначные, то есть флаговые например :) ) атрибуты могут создавать индекс not equal на основании индекса equal. В общем для zimbraIsSystemResource, который таки флаг, я индекс eq добавил, а там хоть трава не сохни.
Вообще полезно бывает в 25-й раз одну и ту же страницу документации читать: склероз побуждает к неожиданным открытиям, в особенности если раньше читал то же самое, но по другому поводу :)

Ах да, ещё лучше бы держать логи низкоуровневой БД и собственно данные на разных дисках .
Цитирую OL Admin Guide:

Use fast subsystems. Put each database and logs on separate disks configurable via DB_CONFIG:

# Data Directory

set_data_dir /data/db


# Transaction Log settings
set_lg_dir /logs

Эх, где бы эти раздельные диски ещё найти в наш век тотального RAID'а с LVM'ом...

P.P.S. А вообще по моим наблюдениям ту же MySQL нередко используют почти read-only.

18:01 

schema2ldif конвертер

Скрипт для преобразования схем
из формата .schema в формат .ldif, пригодный для загрузки в динамическую конфигурацию cn=config. Необходимый параметр - имя файла схемы без расширения, который нужно преобразовать. Скрипт отправляет результат в стандартный поток вывода, откуда вы его можете через пайп перенаправить утилите ldapadd или просто сохранить в файл.


Это, наверное, самый простой и самый немудрёный schema2ldif из всех, когда либо сочинённых. Но мне его обычно хватает.
А если вам нужен продвинутый вариант конвертера - пожалуйста, один есть прямо в поставке OpenLDAP (тоже на shell, тоже называется schema2ldif), а другой, на мой взгляд, самый развитый, написан на Perl'е, и он вот здесь: storm.alert.sk/soft/schema2ldif/schema2ldif

06:24 

"Заметки на полях" переезжают

В связи с утомившими меня вечными проблемами форматирования на движке diary.ru, в особенности это касается кода, я в ближайшее время переношу блог на новый движок (и на другой сайт, разумеется). В связи с этим хотелось бы услышать ваши пожелания, уважаемые читатели:
1) Какой блог движок использовать?
Склоняюсь к LiveStreet, поскольку знаком с ним и возможности форматирования кода устраивают. Неудобно, что нет возможности прикреплять файлы - только ссылки на них. Да вот вроде и всё, что неудобно...
2) На какой сайт переезжать?
У меня есть freeadmins.org.ru, но там движок - Joomla, а блогов нормальных для Джумлы я что-то не нашёл...
Есть ещё идея переехать на sysadminblog.ru - я в принципе не гордый и мне совершенно (без разницы), что сайт не мой. Но неизвестно, насколько этот сайт стабилен, то есть если вероятность того, что он в один прекрасный момент "схлопнется" и как последствие кавитационного удара я лишусь всего своего материала. А материал, как вы догадываетесь, нужен не только для кого-то, но и в первую очередь - для меня самого, поскольку память человеческая небезгранична даже сейчас я изредка пользуюсь своими старыми записями.

Пожалуйста, отпишитесь в комментах, кто что думает по означенному поводу :)

Искренне Ваш, DRVTiny

14:09 

Как научиться работать с LDAP?

Ответом на это, разумеется, может быть только RTFM.
А именно, лучшей книгой в онлайн на эту тему, бесспорно, является опубликованный на сайте zytrax.com хрестоматийный учебник "LDAP for Rocket Scientists". Несерьёзное название книги полностью соответствует стилю изложения: лёгкому, слегка ироничному и максимально доходчивому. Собственно. авторы просто не хотели называть её "LDAP для Чайников" - это было бы похоже на моветон, да и сразу понижало бы в глазах потенциального читателя важность и полезность данной работы.
Читать учебник от корки до корки особого смысла, на мой взгляд, не имеет: он содержит множество примеров и различной практически полезной информации, так что "если срочно" (а оно почти всегда так и бывает), ищите в нём ответы на свои конкретно поставленные вопросы, да обрящете. Во всяком случае, зачастую это куда полезнее чтения сильно фрагментированного, непоследовательного, находящегося в перманентном состоянии дописывания руководстве OpenLDAP Administration Guide, и это даже при том, что после "LDAP for Rocket Scientists" именно документация проекта OpenLDAP является, на мой взгляд, наиболее толковой.
P.S. Я очень признателен Zytrax'у за выложенные на их сайте книги, и не только по LDAP, но и по DNS-серверу ISC BIND, например. Зитракс - это вообще отличный пример того как коммерческий проект может без каких-то значительных вложений сделать полезное и нужное дело для всех.

14:50 

Реализация DNS-сервера в ApacheDS...

Как вам такое: directory.apache.org/apacheds/1.5/561-dns-proto... ?
А ещё есть NTP-сервер, например! Чудесно, не правда ли?
Теряюсь в догадках, почему разработчики MySQL не интегрировали в свою мега-СУБД веб-сервер lightHttpd, например. А лучше бы попросту взяли и написали с нуля свой веб-сервер и прямо вместе с кодом php-интерпретатора в код "мускула" его засунули.
Вот ведь уж сколько раз твердили миру, что все попытки воссоздать Active Directory в локальных масштабах не только бесперспективны и необоснованы, но и просто вредны. Очевидно же, что любой производитель софта, не являющийся монополистом со своей технологией в целевом секторе - не может пытаться навязать всем целую инфраструктуру софта. Лучше делать что-то одно и хорошо, даже отлично, как это имеет место в случае лучшего на сегодняшний день и наиболее динамично развивающегося сервера каталогов OpenLDAP, нежели ваять какое-то монструозное решение, в котором куда ни ткни - всё under strongly development, released forever and never. Novell потерялась во времени и пространстве со своим eDirectory, львиная доля функциональности которого без Netware добавляет глюков, но не резонности, теперь вот ещё и Apache Foundation в эту же степь полез со своей перманентной манией величия.
Чем хорош OpenLDAP? Тем, что он встраивается в любую существующую инфраструктуру, он невероятно гибок и метаморфен. Чем хорош ApacheDS? Тем, что предлагает вам заменить буквально всё на чудесное нечто, у которого гигантские пробелы в документации, но зато есть слово Apache в названии? Кхм, ну если бы не Apache, а NGINX, я бы ещё, пожалуй, подумал (вдруг этот сервер каталогов быстрее реактивного истребителя?), а так - ну зачем миру может пригодится yet another nedoAD? Разве что в качестве очередного прекрасного информационного повода для написания тонны-другой Java-кода, дабы на фриланс.ру народ не скучал и свои индусы не сильно голодали?

16:36 

Открылся форум сообщества LDAP-специалистов

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

Добро пожаловать!

14:36 

Фронтэнд для ldap-клиента OpenLDAP

Дописал версию 1.0.1 фронтэнда и одновременно - API на языке оболочки BASH для стандартных LDAP-утилит из состава OpenLDAP
Фронтэнд позволяет:
1) Использовать "параметры по умолчанию" из конфигурационного файла в формате INI, каждая секция в котором описывает соединение с определённым сервером.
На данный момент в INI-файле можно задать такие параметры коннекта к LDAP-серверу, как:
BIND DN, BIND PASSWORD, BASE DN (база поиска по дефолту), ROOT DN (суфикс каталога);
2) Автодополнять DN-ы суфиксом каталога;
2) Гибко форматировать LDIF-вывод, нормализуя строки: значение атрибута длиной больше 79-ти символов будет выведено в одну строку;
3) Убирать BASE64-кодирование значений атрибутов там, где это требуется;
3) Получать информацию о глобальных настройках LDAP-каталога и его схеме с помощью команд ldapgetcaps и ldapgetschema соответственно.

Вот как это выглядит в действии на примере ldapsearch:


ldapsearch -c EXAD -N --b64 dn -- '(sAMAccountName=konovalov)' mail


Здесь "EXAD" - имя секции в config-файле, описыавющей параметры соединения и базу поиска "по умолчанию" (заметьте, что в самой команде ldapsearch параметр -b опущен)

Если кому-то сие интересно, могу выложить архив на FTP :)

P.S. Код потенциально ОЧЕНЬ интересен, поскольку львиная его доля находится в универсальных модулях, не имеющих отношения к ldap-специфике, а просто подключаемых во фронтэнде. Например, там есть функция getArgs (обработка ключей командной строки), по степени проработки сопоставимая с аналогами на языке Perl. Есть ещё parseINI, chk_fl, dbg_out, ну и многое-многое другое, что должно быть полезно хотя бы с точки зрения реализации заложенных в этом идей.

20:55 

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

02:31 

MultiMaster vs. Mirroring

По возможности не используйте Multimaster-репликацию в её полноценном виде:

- теоретически неограниченое количество мастер-серверов,

- каждый мастер-сервер может принимать реплики изменений с любого другого мастер-сервера.

Дело в том, что это работает только в том случае, если все мастер-сервера создаются с нуля и практически одновременно. Это именно так в случае с простым тестом 050-multimaster, на который так любят ссылаться разработчики OpenLDAP. Тем не менее даже такой вроде бы стабильно работающий кластер взаимнореплицируемых серверов может потерять ноду... А потом вторую... В особенности это касается тех случаев, когда нод больше трёх: число три для режима Multimaster'а в OpenLDAP является каким-то магическим порогом, за которым начинаются эксперименты над критически важными данными с плохо прогнозируемыми последствиями.
Mirroring (зеркалирование) - технически тот же MultiMaster (найдите отличия в конфигурации? olcServerID?), но это иная стратегия репликации. Эта стратегия предполагает, что в штатном режиме работы запись производится лишь на одном сервере, а на второй сервер изменения пересылаются репликой. При этом чтение может осуществляться одновременно с двух серверов при помощи внешнего балансирующего нагрузку фронтэнда (не входит в поставку OpenLDAP можно использовать прокси-режимы работы OL). В случае отказа сервера, принимающего операции записи от клиентов, их начинает принимать неактивная часть "зеркала". Как только "отвалившаяся" часть зеркала поднимется, все операции записи, произведённые за время простоя, будут приняты репликой.
В общем, на самом деле, подчёркиваю, никакой принципиальной разницы между мультимастером и зеркалированием нет, кроме собственно количества нод. Но использование описанной стратегии даёт гораздо более предсказуемый результат, даже если вы не используете никаких внешних фронтэндов и все переключения осуществляете вручную.


P.S. Да, и в любом случае backup often ;)

@темы: серверы

12:17 

Сборка OpenLDAP для сервера-реплики

Если нужно собрать реплику на чистом сервере полностью аналогично тому, как был собран мастер, делаем так:

1. Качаем и распаковываем свежую версию сабжа:


(предполагается, что pwd=$HOME, а в $HOME есть каталоги Download и Compile)

2. Устанавливаем зависимости. В yum-based rpm-дистрибутивах это выглядит так:


3. Собираем OpenLDAP
Раз это сервер реплики, то можно и нужно ничего нового не придумывать, а просто скопировать его опции сборки из исходников мастер-сервера:

На мастер-сервере:


На реплике (не путать со слэйвом, реплика может быть и вторым мастер-сервером, если используется multimaster):

Как видите, в моём случае версии OpenLDAP для реплики и мастер-сервера не совпадают, но в ничего страшного в этом нет, если, конечно, разница в версиях не слишком велика. В моём случае мастер-сервер довольно активно используется, поэтому обновлять его приходится редко.
Команда "eval ..." извлекает из файла config.log строчку вызова ./configure, использовавшуюся для сборки мастер-сервера, и выполняет получившуюся команду

02:40 

sudo+ldap в Calculate Directory Server

Будьте внимательны: в популярном у ваятелей LDAP-based архитектур дистрибутиве CDS (Calculate Directory Server) sudo читает отнюдь не /etc/ldap.conf, а что-то другое. То есть конечно если вы внимательно изучали документацию по CDS, то знаете, что именно должен читать sudo в данном дистрибутиве, я же предпочёл попросту скачать свежую версию с офсайта sudo.ws и собрать её со следующими опциями:

./configure --prefix=/usr --with-ldap --with-ldap-conf-file=/etc/ldap.conf -with-ldap-secret-file=/etc/ldap.secret

02:01 

Чудеса на PADL.COM'е

Опытным путём сегодня благополучно выяснил, что в nss_ldap используется в режиме "nss_schema rfc2307bis" знаете какой атрибут членства в группе? uniqueMember! Что в этом необычного? А то, что в последней редакции RFC 2307bis, (которая так же, как и все предыдущие не утверждена IETF, а потому не совсем понятно, чего ради её тот же OpenDS использует по дефолту), в качестве атрибута членства в группе, хранящего полный DN, предлагается member, а не uniqueMember! Об этом по сути нигде толком не сказано, поди догадайся...
Кстати, само описание posixGroup в схеме я предлагаю в таком случае хакнуть при первой же возможности и сделать его следующим:

1.3.6.1.1.1.2.2 NAME 'posixGroup' DESC 'Abstraction of a group of accounts' SUP top STRUCTURAL MUST gidNumber MAY ( cn $ userPassword $ uniqueMember $ memberUid $ description )

Здесь cn вынесен в MAY атрибуты и добавлен MAY-атрибут uniqueMember
Я конечно понимаю, что это некоторое отклонение от стандарта, но... к сожалению иногда и стандарты страдают "несовершенством". Особенно это касается RFC 2307bis, где с одной стороны posixGroup стал вдруг AUXILIARY, что вынуждает добавлять в стек структурный класс, а с другой стороны - в objectClass'ах groupOfNames и groupOfUniqueNames, содержащих типы атрибутов member и uniqueMember соотв., они заявлены как MUST. Из сказанного следует, что даже если Member'ы формируются оверлеем dynlist, Вы всё равно обязаны постоянно держать в записи нечто вроде "uniqueMember: cn=dummy".
Редактирование же определения posixGroup в указанном ключе позволит вам избавиться от необходимости изворачиваться, стряпая противоестественного вида стек objectClass'ов с лишними значениями атрибутов или добавляя туда extensibleObject, что на мой взгляд - тоже хак в обход схемы.

Впрочем, всё сказанное касается исключительно тех, кто использует DN'ы для членов группы, для обычного memberUid'а хватает стандартной nis.schema, соответствующей RFC 2307

00:03 

Как сделать просто ноду, "без прикрас"?

Если нужно добавить элементарный узел в дерево LDAP, пользуйтесь чудесным objectClass'ом "applicationProcess" из RFC 2256.
Вот как выглядит типичный узел с objectClass=applicationProcess:

dn: cn=Accounts,cn=Security
objectClass: applicationProcess
cn: Accounts

Описание applicationProcess:

objectClasses: ( 2.5.6.11 NAME 'applicationProcess' DESC 'RFC2256: an application process' SUP top STRUCTURAL MUST cn MAY ( seeAlso $ ou $ l $ description )

Поскольку непонятно, что это ещё за application process такой (thread что ли?), то я думаю, нет ничего противоречащего "букве и духу" LDAP в использовании данного objectClass'а для создания узлов без дополнительной смысловой нагрузки..

19:56 

Специализированный LDAP-форум

Я понимаю, что diary.ru, как бы ни был он мне мил (и немил тоже), всё же ограничен чёткими рамками блогосферы. Потому и приходится делать тематический форум отдельно от блога. Первая попытка сделать такой форум на бесплатном хостинге, к сожалению, оказалась не совсем удачной. Поэтому я решил вместо самостоятельного сайта под эти нужды создать раздел на форуме freeadmins.org.ru. Я там довольно регулярно бываю и смогу ответить на ваши вопросы.в разумные сроки.
Да, комменты в блоге конечно никто не отменяет :)

17:20 

LDAP как источник аутентификации

Две мои статьи на тему LDAP-аутентификации - написаны относительно давно, но для ознакомления с вопросом должно быть в самый раз:
- Сервер каталогов LDAP как источник аутентификации - учётные записи
- Сервер каталогов LDAP как источник аутентификации - интеграция с AD

15:29 

LDAPCon 2010...

Замечательной конференции, посвящённой проблемам LDAP, в этом году не будет. Сказались финансовые трудности, поглощение Sun'а Ораклом, довольно слабая предыдущая конференция. В итоге, следующий LDAPCon запланирован на 2011-й год.

14:34 

Лучший графический LDAP-клиент

Уже очень давно пользуюсь во всех отношениях приятным LDAP-клиентом LDAP Browser/Editor. Эта компактная кроссплатформенная программа на Java с открытым исходным умеет всё или почти всё (не умеет, например, картинки JPEG напрямую в каталог запихивать). Её ближайшим конкурентом можно назвать Apache Directory Studio - клиент более функциональный, интеллектуальный и навороченный, но и более требовательный к ресурсам. Я предпочитаю пользоваться в основном LDAP Browser/Editor'ом и только в каких-то редких случаях - Apache Directory Studio. Из редких случаев стоит упомянуть работу со схемой, просмотр и редактирование Active Directory, а также загрузку любых файлов в каталог (для чего он совершенно не предназначен, поэтому такое кощунство требуется делать действительно редко).

И да, phpLDAPAdmin - штука довольно недоразвитая, ненаглядная и тормозная (как и большинство навязываемых нам "супер-пупер" веб-технологий), поэтому пользоваться ей рекомендую лишь в тех случаях, когда требуется админить LDAP-сервер удалённо из любой точки планеты, и не только под nix'ами, но и под форточками. Но по жизни для нервной системы полезнее будучи на Багамах всё же скачать автономный LDAP-клиент и пользоваться им.

Отличный обзор LDAP Browser/Editor можно найти на сайте LDAP-сервера OpenDS: www.opends.org/wiki/page/LDAPBrowserEditor Правда, указанная там ссылка на домашнюю страничку автора неактуальна уже (видимо, автор прекратил разработку или продолжил её в составе какого-то другого ПО). Тем не менее, программа очень популярна и скачать её можно во многих местах, например, здесь: www.novell.com/communities/files/Gawor_ldapbrow..., а RPM-пакет - здесь: rpm.pbone.net/index.php3/stat/4/idpl/11310306/d...


@темы: клиенты

17:14 

Mandriva Directory Server

Mandriva Directory Server is not a Directory Server. Ну почти как WINE Is Not An Emulator.
MDS не является сервером каталогов, это просто веб-интерфейс для настройки стандартных компонент Linux-дистрибутивов на взаимодействие с LDAP. Аналогом можно было бы назвать Microsoft Management Console, если бы... собственно, именно MMC называется ключевой компонент MDS'а (первое слово аббревиатуры конечно не Microsoft)! MDS дирижирует оркестром из DNS, DHCP, Samba, Kerberos, Postfix, подсистем NSS, PAM и собственно сервера каталогов для того, чтобы довольно странным методом при наличии весьма кривой документации делать то же, что умеет (только явно логичнее и проще) Calculate Directory Server. Последний, кстати, тоже ни разу не Directory Server, а просто хороший дистрибутив для ваяния либо аналога nix'ового NIS'а на современный лад, либо nix-based контролера домена Windows, причём последнее по известным причинам более востребовано IT-социумом. Но если краеугольным камнем Calculate DS является OpenLDAP, то чем же рулит чудесная веб-консолька MMC? В теории должна бы уметь работать как с тем же OpenLDAP, так и с Fedora Directory Server, на практике... ну не было у меня такой практики :) Но по смыслу офдоков в общем-то понятно, что разработка компании Mandriva c продукцией RedHat'а дружит хуже, чем с OpenLDAP.Да, и повторюсь, смысла в данном продукте в принципе не очень много, он пригодится разве что совсем новичкам или тем, кому надо развернуть доменный контролер предельно быстро на "чистом" каталоге. Если у вас уже есть каталог со своей структурой, отражающей логическую структуру организации, то MDS Вам точно ни к чему, потому что вы точно знаете, почему красивый веб-интерфейс на PHP и кучка модулей на Python - это всё-таки ещё не Сервер Каталогов :)

@темы: клиенты

21:39 

Одна из распространённых проблем репликации

Если ваша база OpenLDAP упорно отказывается реплицироваться, запустите сервер, на который вы хотите залить реплику, с ключом -d 16384 (отладка механизма репликации). И если там будет явная "ругань" на то, что с мастер-сервера невозможно получить entryUUID для некоторых записей, это значит, что в исходном каталоге не хватает служебных атрибутов, без которых репликация действительно не пойдёт. Отложим обсуждение вопроса о том, почему так бывает, просто пофиксим эту проблему:
Если база относительно небольшая, переведите её в read-only и сделайте полный slapcat:
А теперь... физически удалите файлы базы и залейте LDIF-дамп базы, полученный на шаге 1, обратно:
rm -f /path/to/db/files/*
slapadd -F /path/to/config/dir -n номер_базы -l my_db.ldif
chown -R openldap_user.openldap_group /path/to/db/files/


Примечание: под "номером базы" подразумевается то число, которое проставлено для этой базы в cn=config
То есть, например, для DN=olcDatabase={3}hdb,cn=config номер базы соответственно равен трём. Для самой cn=config номер всегда равен нулю (т.е. это всегда olcDatabase={0}config,cn=config)





@темы: серверы

LDAP - заметки на полях

главная