3.2 Инициализация каталога cn=config

Примеры адаптированы для

Итак, мы готовы приступить к инициализации системы конфигурации времени исполнения cn=config.

Для хранения записей каталога cn=config и работы с ними slapd использует механизм манипуляции данными back-ldif, который хранит записи в текстовых файлах в формате LDIF и использует файловую систему для создания древовидной структуры базы данных. Первым делом необходимо создать корневую директорию базы cn=config, где будут размещаться поддиректории и конечные LDIF-файлы этого DIT. Именно путь к этой директории передаётся в аргументе -F при запуске slapd, поэтому она может, по сути, находиться где угодно и называться как угодно. Тем не менее, существует общепринятая практика размещать её в директории /etc/ldap и называть slapd.d (этот путь slapd пытается использовать по умолчанию, если аргумент -F не задан). Проверьте, возможно такая директория уже создана, если нет, создадим её:

# mkdir /etc/ldap/slapd.d

Теперь нужно наполнить нашу корневую директорию содержимым. По сути, необходимо создать LDIF-файл, описывающий DIT cn=config в минимально необходимом объёме, и создать на его основе базу данных с помощью инструмента slapadd. Под минимально необходимым подразумевается такой объём, чтобы с помощью этого LDIF-файла можно было инициализировать каталог и запустить на его основе slapd, а затем подключиться к нему и осуществлять дальнейшую работу с помощью стандартных LDAP-запросов. LDIF-файл, отвечающий данным требованиям, выглядит так:

dn: cn=config
objectClass: olcGlobal
cn: config

dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootPW: secret

В этом LDIF описываются две записи. Первая из них — корневая запись DIT cn=config, в которую в дальнейшем, в виде атрибутов объектного класса olcGlobal, будут добавляться практически все глобальные настройки нашей службы каталогов. Кроме того, она, как корневая запись, будет являться родительской записью для других системных записей cn=config, а также для записей служебных и пользовательских баз данных.

Вторая запись данного LDIF описывает одну из служебных баз данных, а именно собственно нашу базу данных конфигурации cn=config. Конечно, и её можно было бы не указывать, тогда slapadd при добавлении LDIF создал бы её автоматически. Но ведь нам требуется затем подключаться к cn=config для работы (иначе зачем вообще огород городить), а для этого нужны учётные данные. Подключиться к cn=config можно только от имени rootDN с паролем, которые определяется, соответственно, в атрибутах olcRootDN и olcRootPW объектного класса olcDatabaseConfig, на котором строятся записи конфигурации всех баз данных, в том числе и cn=config. Атрибут olcRootDN мы не указали, его значением по умолчанию для базы данных cn=config будет само cn=config. Если это Вас смущает или пугает, можете задать явно другой rootDN:

olcRootDN: cn=manager,cn=config
или
olcRootDN: cn=admin,cn=config

Имя может быть любым, но обязательное требование — чтобы оно находилось в пределах контекста именования cn=config, иначе slapd не даст Вам подключиться к этой базе данных. В дальнейших примерах мы будем использовать rootDN по умолчанию — cn=config.

Что касается пароля, то его необходимо задавать явно. В приведённом выше примере пароль указан в открытом виде. Конечно, это не лучшее решение для любых парольных атрибутов, а тем более для olcRootPW. Заменим его более безопасным хэшированым значением пароля. Сначала сгенерируем его с помощью инструмента slappasswd:

# slappasswd -h '{SSHA}' -s 'secret'
{SSHA}nBszmKAlK0bWe3uP4oOIz86FgNMod4xv

Первым аргументом команды мы указали алгоритм хэширования (в данном случае это SHA с "солью"), вторым — тот пароль, хэш которого нам требуется получить. Если Вы не хотите оставлять пароль в открытом виде в истории команд, то нужно не указывать аргумент -s, тогда slappasswd дважды попросит Вас ввести пароль:

# slappasswd -h '{SSHA}' 
New password: 
Re-enter new password:
{SSHA}nBszmKAlK0bWe3uP4oOIz86FgNMod4xv

Вывод команды — наш хэшированный пароль. Его нужно тем или иным образом поместить в наш LDIF-файл. Атрибут olcRootPW будет выглядеть так:

olcRootPW: {SSHA}nBszmKAlK0bWe3uP4oOIz86FgNMod4xv

Наш LDIF-файл готов к загрузке. Если его загрузить в таком виде, то к двум нашим записям slapadd добавит описание ещё одной служебной базы данных frontend и системную запись cn=schema. Причём в описание frontend будут добавлены olc-атрибуты, которые slapd установленной версии решит выставить по умолчанию, а cn=schema будет содержать какой-то не слишком очевидный набор схемы данных, представляющий собой смесь системной схемы и части пользовательского набора схемы core (например, там будет описание атрибута cn, который нужен повсеместно в cn=config, но не будет описания атрибута dc, который понадобится нам при инициализации пользовательской базы данных). Поэтому базу данных frontend мы оставим в покое, а запись cn=schema зададим явно и добавим к ней в качестве дочерней записи описание пользовательского набора схемы данных core:

dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema

include: file:///etc/ldap/schema/core.ldif

Ещё один маленький ньюанс — многие системы (в том числе Ubuntu) для корректной работы стартовых скриптов slapd требуют наличия pid-файла и потому ожидают, что в записи cn=config будет задан атрибут olcPidFile. Зададим его и мы (в конце концов, это неплохая практика):

olcPidFile: /var/run/slapd/slapd.pid

Теперь всё готово к тому, чтобы проинициализировать конфигурацию cn=config и благополучно запустить slapd. Наш итоговый LDIF-файл будет выглядеть так:

dn: cn=config
objectClass: olcGlobal
cn: config
olcPidFile: /var/run/slapd/slapd.pid

dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootPW: {SSHA}nBszmKAlK0bWe3uP4oOIz86FgNMod4xv

dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema

include: file:///etc/openldap/schema/core.ldif

Сохраним его как /tmp/ldifs/001-init_cn_config.ldif. Проинициализируем конфигурацию cn=config:

# slapadd -n 0 -F /etc/ldap/slapd.d -l /tmp/ldifs/001-init_cn_config.ldif
_#################### 100.00% eta   none elapsed            none fast!         
Closing DB...

Параметр -n 0 говорит о том, что мы добавляем данные в базу данных с индексом 0, который зарезервирован для cn=config. Если его не указать, slapadd по умолчанию будет пытаться добавить данные в первую базу данных с индексом больше нуля (обычно это первая по списку пользовательская база данных).

Посмотрим, что у нас получилось:

# ls -lR /etc/ldap/slapd.d
/etc/ldap/slapd.d:
итого 8
drwxr-x--- 3 root root 4096 2012-10-14 10:34 cn=config
-rw------- 1 root root  332 2012-10-14 10:34 cn=config.ldif

/etc/ldap/slapd.d/cn=config:
итого 16
drwxr-x--- 2 root root 4096 2012-10-14 10:34 cn=schema
-rw------- 1 root root  307 2012-10-14 10:34 cn=schema.ldif
-rw------- 1 root root  400 2012-10-14 10:34 olcDatabase={0}config.ldif
-rw------- 1 root root  525 2012-10-14 10:34 olcDatabase={-1}frontend.ldif

/etc/ldap/slapd.d/cn=config/cn=schema:
итого 16
-rw------- 1 root root 15456 2012-10-14 10:34 cn={0}core.ldif

Все добавляемые нами записи на месте. Но, поскольку slapadd мы выполняли с правами root, все файлы и поддиректории в slapd.d принадлежат пользователю root и группе root. slapd же запускается от имени пользователя с ограниченными правами openldap и группы openldap. Чтобы при запуске slapd мог получить доступ к файлам в конфигурационной директории, необходимо скорректировать принадлежность её содержимого:

# chown -R openldap:openldap /etc/ldap/slapd.d

Остаётся только ограничить доступ к самой директории slapd.d, чтобы доступ к её содержимому был только у пользователя, от имени которого запускается slapd:

# chmod 750 /etc/ldap/slapd.d

Пора запускать наш slapd:

# service slapd start
Starting OpenLDAP: slapd.

Если случилось страшное, и slapd не запустился — не отчаивайтесь!

# slapd -d -1 -u openldap -g openldap

Итак, slapd запущен. Дальнейшие настройки, по сути, заключаются в добавлении новых и редактировании имеющихся записей DIT cn=config. Мы будем производить эти действия, выполняя стандартные операции LDAP с помощью инструментов OpenLDAP, таких как ldapadd или ldapmodify, подключаясь к cn=config от имени rootDN (cn=config) с паролем, который мы определили в атрибуте olcRootPW (secret). Эти действия можно выполнять как с той же самой машины, так и с любой другой машины в сети, передавая утилите данные о сервере с помощью аргумента -H, параметром которого является LDAP URL, либо сочетанием аргументов -h и -p, указывая в них адрес хоста сервера и порт, который он обслуживает соответственно. Если Вы предпочитаете ldapvi или графические LDAP-клиенты — прекрасно! Просто адаптируйте наши примеры под свой клиент.

База данных cn=config проинициализирована. Приступим к настройке OpenLDAP. Сначала добавим необходимые модули.

Pro-LDAP.ru 2013-2020 г. Последнее изменение страницы — 4 декабря 2017 г. Вопросы и предложения принимаются на форуме проекта.