Итак, мы готовы приступить к инициализации системы конфигурации времени исполнения 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
не запустился — не отчаивайтесь!
slapadd
).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. Сначала добавим необходимые модули.