389ds_server
389ds-сервер
Эта роль устанавливает сервер 389DS (LDAP сервер) на целевой машине(ах).
ansible-galaxy install lvps.389ds_server
Функции
- Установка одного LDAP сервера
- Настройка ведения журналов
- Добавление пользовательских файлов схемы
- Включение/выключение любого плагина
- Настройка плагина DNA для UID/GID номеров
- Настройка TLS
- Принудительное использование TLS (минимальный SSF и требование безопасного связки) или возвращение к необязательному TLS
- Включение/выключение LDAPI
- Включение/выключение SASL PLAIN
Репликация управляется с помощью другой роли.
Требования
- Ansible 2.10 или новее, для Ansible 2.8 и 2.9 используйте версии 3.1.x этой роли
- SUSE (OpenSUSE или SLES) или CentOS 7, CentOS 8, CentOS 9 или другие RHEL основанные ОС
Переменные роли
Переменные, которые можно передать этой роли и их краткое описание.
dirsrv_product
По умолчанию: зависит от ОС · Можно изменить: Нет
Есть два основных ветвления. Бесплатный 389 Directory Server и поддерживаемый Red Hat Directory Server. С бесплатными выпусками вы можете полагаться на настройки по умолчанию. В противном случае вы можете настроить это значение по необходимости. В данный момент единственным протестированным значением, отличным от умолчания, является '@redhat-ds:11' для Red Hat Directory Server 11, доступного в Red Hat EL8 ОС.
dirsrv_port
По умолчанию: 389 · Можно изменить: Нет
Порт, на котором слушает 389ds.
dirsrv_suffix
По умолчанию: dc=example,dc=com · Можно изменить: Нет
Суффикс DIT. Все записи на сервере будут находиться под этим суффиксом. Обычно он формируется из компонентов домена (dc) вашего основного домена компании. Например, если вы из example.co.uk и сервер будет на ldap-server.example.co.uk, установите суффикс на dc=example,dc=co,dc=uk, опустив часть поддомена (ldap-server), так как она не имеет значения.
dirsrv_bename
По умолчанию: userRoot · Можно изменить: Нет
Внутреннее имя базы данных суффикса.
dirsrv_othersuffixes
По умолчанию: [] · Можно изменить: Нет
Список других суффиксов в формате { name: <bename>, dn: <rootDN>}
dirsrv_rootdn
По умолчанию: cn=Directory Manager · Можно изменить: Нет
Корневой DN, или имя пользователя "администратора". Привязка с этим DN позволяет обойти все авторизационные контроли.
dirsrv_rootdn_password
Можно изменить: Нет
Пароль для root DN, вы должны определить эту переменную, иначе роль завершится с ошибкой.
dirsrv_fqdn
По умолчанию: {{ansible_nodename}} · Можно изменить: Нет
Полное доменное имя сервера, например ldap.example.com. Если имя хоста сервера уже является полным доменным именем, значение по умолчанию будет использовано.
dirsrv_serverid
По умолчанию: default · Можно изменить: ¹
Идентификатор сервера или идентификатор экземпляра. Все данные, связанные с экземпляром, настроенным этой ролью, будут находиться в /etc/dirsrv/slapd-default, /var/log/dirsrv/slapd-default и т. д. Вы можете использовать название своей компании, например, для Foo Bar, Inc установите переменную в foobar, и директории будут называться slapd-foobar.
dirsrv_listen_host
Можно изменить: Да
Слушать на этих адресах/именах хостов. Если не установлено (по умолчанию), ничего не делает, если установлено в строку, установит атрибут nsslapd-listenhost. Установите в [], чтобы удалить атрибут.
dirsrv_secure_listen_host
Можно изменить: Да
То же самое, что dirsrv_listen_host, но для LDAPS. Если не установлено (по умолчанию), ничего не делает, если установлено в строку, установит атрибут nsslapd-securelistenhost. Установите в [], чтобы удалить атрибут.
dirsrv_server_uri
По умолчанию: ldap://localhost · Можно изменить: ¹
URI сервера для задач, которые подключаются через LDAP. Поскольку задачи выполняются на том же сервере, что и 389DS, в большинстве случаев это будет localhost, нет необходимости в настройке.
dirsrv_factory
По умолчанию: false · Можно изменить: Да
Сохранить заводские настройки для параметров аутентификации и ведения журнала. Если true, dirsrv_logging, dirsrv_simple_auth_enabled, dirsrv_password_storage_scheme, dirsrv_ldapi_enabled, dirsrv_sasl_plain_enabled будут полностью проигнорированы.
dirsrv_install_examples
По умолчанию: false · Можно изменить: Нет
Создать примерные записи под суффиксом во время установки.
dirsrv_install_additional_ldif
По умолчанию: [] · Можно изменить: Нет
Установить эти дополнительные LDIF файлы, по умолчанию ничего (пустой массив). Это соответствует директиве InstallLdifFile в файле установки inf для 389DS <= 1.3. Начиная с 1.4, это выполняется через dsconf.
dirsrv_ldif_files_remote
По умолчанию: false - можно изменить: Да
LDIF файлы находятся на удаленном сервере, а не на контроллере ansible.
dirsrv_install_additional_ldif_dir
По умолчанию: /var/lib/dirsrv/slapd-{{ dirsrv_serverid }}/ldif · Можно изменить: Нет
Директория, где временно хранятся ldif файлы для dirsrv_install_additional_ldif. Не может быть /tmp, поскольку служба 389DS имеет установленный systemd PrivateTmp в true, начиная с CentOS/RHEL 8.3.
dirsrv_logging
По умолчанию: смотрите ниже · Можно изменить: Да
Смотрите ниже.
dirsrv_plugins_enabled
По умолчанию: {} · Можно изменить: Да
Включение или выключение плагинов, смотрите ниже для деталей. По умолчанию ни один плагин не включен и не выключен.
dirsrv_dna_plugin
По умолчанию: смотрите ниже · Можно изменить: Да
Настройка для плагина DNA (Распределенное числовое назначение).
dirsrv_custom_schema
По умолчанию: [] · Можно изменить: Да
Пути к пользовательским файлам схемы. Они будут помещены в /etc/dirsrv/slapd-{{ dirsrv_serverid }}/schema, и запрос будет на перезагрузку схемы, когда что-либо изменится.
dirsrv_allow_other_schema_files
По умолчанию: false · Можно изменить: Да
Если значение false (значение по умолчанию), эта роль добавит указанные файлы схемы в /etc/dirsrv/slapd-{{ dirsrv_serverid }}/schema, а затем удалит все другие файлы схемы, кроме 99user.ldif. Если ваши файлы схемы управляются только этой ролью или динамически (т.е. из cn=schema, что записывает в 99user.ldif), вы можете оставить эту переменную на значении по умолчанию (false). Если у вас есть больше файлов схемы в этой директории (добавленных вручную или другими задачами), установите это значение в true, чтобы оставить их там. Недостаток в том, что если вы развернете, например, 50example.ldif, а затем переименуете его в 50my_example.ldif, когда роль выполнится снова, она будет считать его новым файлом и оставит предыдущий там, нарушая ваш каталог.
dirsrv_tls_enabled
По умолчанию: false · Можно изменить: Да
Включить TLS (LDAPS и StartTLS). Все переменные "dirsrv_tls" влияют только если это включено.
dirsrv_tls_min_version
По умолчанию: '1.2' · Можно изменить: Да
Минимальная версия TLS: 1.0, 1.1 или 1.2. Возможно даже 1.3, если поддерживается вашей версией 389DS. SSLv2 и SSLv3 всегда отключены этой ролью.
dirsrv_tls_certificate_trusted
По умолчанию: true · Можно изменить: Да
Сертификат сервера является общедоступно доверенным. Установите значение в false только в разработке (для самоподписанных сертификатов)!
dirsrv_tls_enforced
По умолчанию: false · Можно изменить: Да
Принудительное использование TLS, требуя безопасные соединения и минимальный SSF.
dirsrv_tls_minssf
По умолчанию: 256 · Можно изменить: Да
Минимальный SSF, используется только если dirsrv_tls_enforced истинно. 128 кажется разумным, 256 должно быть очень безопасным. Установите это значение в 0, чтобы принудительно использовать TLS только с безопасными соединениями.
dirsrv_allow_anonymous_binds
По умолчанию: 'rootdse' · Можно изменить: Да
Разрешить анонимные соединения: логическое true для Да, логическое false для Нет, или 'rootdse'. Руководство по администрированию предлагает использовать rootdse вместо Нет, потому что это позволяет анонимным соединениям искать некоторые данные, которые клиенты могут потребовать перед установлением соединения. Разрешение анонимных соединений в основном делает ваш каталог публичным, если вы не ограничите доступ с помощью ACI.
dirsrv_simple_auth_enabled
По умолчанию: true · Можно изменить: Да
Включить SIMPLE аутентификацию, вероятно true, если вы не хотите использовать только SASL PLAIN или настраивать другие методы вручную.
dirsrv_password_storage_scheme
По умолчанию: [] · Можно изменить: Да
Одно значение, возможно, строка "PBKDF2_SHA256". Или оставьте значение по умолчанию, которое удалит любое пользовательское значение и использует стандартное значение 389DS, которое должно быть довольно безопасным.
dirsrv_ldapi_enabled
По умолчанию: false · Можно изменить: Да
Включить LDAPI (подключение к серверу через UNIX сокет на ldapi:///var/run/dirsrv/slapd-{{ dirsrv_serverid }}.socket). Обратите внимание, что это подлежит принуждению TLS, и TLS не поддерживается, поэтому это бесполезно, если вы установите dirsrv_tls_enforced в true.
dirsrv_sasl_plain_enabled
По умолчанию: true · Можно изменить: Да
Включить SASL PLAIN аутентификацию: если клиент пытается аутентифицироваться без TLS и TLS принудителен, такая аутентификация должна остановить его перед отправкой пароля в открытом виде, в то время как простая привязка отправит пароль и затем завершится с ошибкой из-за слишком низкого SSF.
Переменные, эксклюзивные для версии 389DS 1.4.X
Эти переменные влияют только на установки версии 389DS 1.4.X и не оказывают влияния на предыдущие версии, даже если они определены.
dirsrv_defaults_version
По умолчанию: 999999999² · Можно изменить: Нет
Значения конфигурации по умолчанию будут соответствовать указанной версии 389DS. Формат — XXXYYYZZZ, где XXX — это основная версия, YYY — это минорная версия, а ZZZ — это уровень патча (все три значения дополнены нулями до длины три). Если выбрана 999999999, будут использоваться последние значения по умолчанию.
dirsrv_selfsigned_cert
По умолчанию: True² · Можно изменить: Нет
Определяет, будет ли 389DS генерировать самоподписанный сертификат и автоматически включать TLS.
dirsrv_selfsigned_cert_duration
По умолчанию: 24² · Можно изменить: Нет
Срок действия в месяцах самоподписанного сертификата, сгенерированного 389DS.
dirsrv_create_suffix_entry
По умолчанию: False² · Можно изменить: Нет
Определяет, будет ли 389DS генерировать запись суффикса в каталоге с данным суффиксом: cn={{ dirsrv_suffix }}
dirsrv_rundir
Можно изменить: Нет
Если определено, настраивает специфический путь для db_home_dir.
dirsrv_rundir
Можно изменить: Нет
Если определено, настраивает специфический путь для run_dir.
Совместимость между версиями 1.3.X и 1.4.X
Чтобы иметь плейбук, который ведет себя одинаково на версиях 1.3 и 1.4 версии 389DS, должны использоваться следующие значения:
| Переменная | Значение |
|---|---|
| dirsrv_defaults_version | 001004002³ |
| dirsrv_selfsigned_cert | False |
| dirsrv_create_suffix_entry | True |
Примечания
Некоторые переменные не могут быть изменены этой ролью (или вообще) после создания экземпляра 389DS. Если одна из них изменена, а роль применяется снова, может произойти неопределенное поведение, начиная от "ничего" до "роль завершается с ошибкой". Некоторые из них, например, пароль root DN, могут быть изменены вручную: пожалуйста, обратитесь к Руководству администратора для получения деталей.
¹ Изменение этой переменной с предыдущего выполнения приведет к созданию другого экземпляра, другого каталога, полностью отделенного от предыдущего, который должен работать нормально, если это ваша цель.
² Это значения по умолчанию версии 389DS версии 1.4.2.15 и могут изменяться для более поздних версий: запустите dscreate create-template на своем компьютере, чтобы увидеть значение по умолчанию для текущей версии.
³ Это версия значений по умолчанию, на основе которой была написана и валидирована эта роль. Установка dirsrv_defaults_version технически не требуется, но может предотвратить будущие обновления по умолчанию от поломки плейбука из-за несовместимости с 389DS 1.3. С другой стороны, установка переменной фактически "замораживает" конфигурацию во времени, и если это делается в течение длительного времени, это может сделать её устаревшей. Используйте с осторожностью.
Все переменные начинаются с префикса dirsrv, так как начинать имя переменной с числа ("389ds") не очень удобно.
dirsrv_logging
Это переменная по умолчанию:
dirsrv_logging:
audit:
enabled: false
logrotationtimeunit: day
logmaxdiskspace: 400
maxlogsize: 200
maxlogsperdir: 7
mode: 600
access:
enabled: true
logrotationtimeunit: day
logmaxdiskspace: 400
maxlogsize: 200
maxlogsperdir: 7
mode: 600
error:
enabled: true
logrotationtimeunit: day
logmaxdiskspace: 400
maxlogsize: 200
maxlogsperdir: 7
mode: 600
Ansible по умолчанию не объединяет словари, т.е. если вы хотите изменить только audit > enabled на true, вам нужно определить все другие переменные также. Если вы хотите изменить значения по умолчанию, хорошей идеей будет скопировать этот целый блок в переменные и настроить, что вам нужно.
dirsrv_plugins_enabled
Если хотите включить плагин memberof, расположенный по адресу cn=MemberOf Plugin,cn=plugins,cn=config, установите переменную следующим образом:
dirsrv_plugins_enabled:
MemberOf Plugin: true
Если он включен и вы хотите его отключить, установите так:
dirsrv_plugins_enabled:
MemberOf Plugin: false
Если хотите включить больше плагинов:
dirsrv_plugins_enabled:
MemberOf Plugin: true
Distributed Numeric Assignment Plugin: true
Если плагин не появляется в списке, он остается в своем текущем состоянии.
Плагин с названием Foo должен иметь запись в cn=Foo,cn=plugins,cn=config, вы можете посмотреть в дерево cn=plugins,cn=config, чтобы увидеть, какие плагины доступны и их статус.
dirsrv_dna_plugin
Значение по умолчанию:
dirsrv_dna_plugin:
gid_min: 2000
gid_max: 2999
uid_min: 2000
uid_max: 2999
Ansible по умолчанию не объединяет словари, т.е. если вы хотите изменить только uid_max и gid_max, вам нужно определить переменные _min также. Когда вы определяете dirsrv_dna_plugin, он полностью заменяет этот словарь по умолчанию.
Эта настройка применяется, только если "Distributed Numeric Assignment Plugin" истинно в dirsrv_plugins_enabled, и удаляется, когда он ложен. Если это не упоминается, ничего не делается.
dirsrv_replica_role должен быть определен для настройки DNA с репликацией. Эта переменная также определяется в роли lvps/389ds-recplication, поэтому обратитесь к ней за документацией. Для этой роли достаточно, чтобы она была определена, если вы используете репликацию, значение не имеет значения.
Теги
Есть некоторые доступные теги, так что можно запускать например:
ansible-playbook some-playbook.yml --tags dirsrv_schema
и это обновит только пользовательские файлы схемы, не изменяя ничего другого. some-playbook.yml должен применить эту роль, очевидно.
Теги:
- dirsrv_schema: задачи пользовательской схемы
- dirsrv_tls: все задачи конфигурации TLS, включая сертификаты и принуждение
- dirsrv_cert: задачи по сертификату TLS, подкласс dirsrv_tls
Все теги также включают несколько проверок в начале плейбука и "очистка обработчиков" в конце, так как 389DS может потребовать перезапуска или может потребоваться перезагрузка схемы.
dirsrv_cert особенно полезен для автоматизированного управления сертификатами с ACME: смотрите пример "TLS с Let's Encrypt (или другими провайдерами ACME)" ниже. Если тот же тег добавлен ко всем задачам, связанным с ACME, будет возможно периодически запускать ansible-playbook some-playbook.yml --tags dirsrv_cert для автоматического обновления сертификатов.
Зависимости
Отсутствуют.
Использование и примеры
Минимальный рабочий пример
- name: Пример плейбука
hosts: example
roles:
- role: lvps.389ds_server
dirsrv_rootdn_password: secret
Привязка с DN cn=Directory Manager и паролем secret на порту 389, суффикс будет dc=example,dc=local, все остальное в основном как чистая установка 389DS.
Использование Ansible Vault было бы хорошей идеей, чтобы избежать раскрытия пароля root DN в открытом виде в продакшене.
Настройка брандмауэра
Не часть этой роли, но вам может потребоваться открыть LDAP порт (389), чтобы получить доступ к серверу удаленно:
- name: Разрешить ldap порт в firewalld
firewalld: service=ldap permanent=true state=enabled
То же самое может понадобиться и для порта LDAPS (636), если вы включите TLS и хотите использовать его вместо StartTLS.
Пример записи и небольшой кастомизацией
- name: Пример плейбука
hosts: example
roles:
- role: lvps.389ds_server
dirsrv_suffix: dc=custom,dc=example,dc=com
dirsrv_rootdn: cn=admin
dirsrv_rootdn_password: secret
dirsrv_serverid: customized
dirsrv_install_examples: true
dirsrv_logging:
audit:
enabled: true
logrotationtimeunit: day
logmaxdiskspace: 400
maxlogsize: 200
maxlogsperdir: 14
mode: 600
access:
enabled: true
logrotationtimeunit: day
logmaxdiskspace: 400
maxlogsize: 200
maxlogsperdir: 14
mode: 600
error:
enabled: true
logrotationtimeunit: day
logmaxdiskspace: 400
maxlogsize: 200
maxlogsperdir: 14
mode: 600
dirsrv_plugins_enabled:
MemberOf Plugin: true
dirsrv_custom_schema:
- "50example.ldif"
- "60foobar.ldif"
Привязка с DN cn=admin и паролем secret на порту 389, посмотрите на примерные записи, предоставленные 389DS.
Аудит журналов также включен, и все журналы хранятся в течение 14 дней (или до тех пор, пока они не станут слишком большими).
Плагин MemberOf также включен.
Посмотрите в директорию molecule для пользовательского файла схемы, который известен как работающий с 389DS, если вы хотите протестировать эту часть, но у вас нет действительного файла схемы. Удалите эту часть, чтобы убрать все пользовательские файлы схемы. Перезагрузка схемы выполняется автоматически.
TLS
- name: Пример плейбука
hosts: example
roles:
- role: lvps.389ds_server
dirsrv_suffix: "dc=example,dc=local"
dirsrv_serverid: example
dirsrv_rootdn_password: secret
dirsrv_tls_enabled: true
dirsrv_tls_cert_file: example_cert.pem
dirsrv_tls_key_file: example.key
dirsrv_tls_files_remote: false # True, если файлы уже на удаленном хосте (например, предоставлены certbot)
dirsrv_tls_certificate_trusted: true # Или false, если самоподписанный
# Если вы хотите избежать простого LDAP и принудительно использовать TLS, также рассмотрите эти настройки:
dirsrv_tls_enforced: true
dirsrv_tls_minssf: 256
# Ничего общего с TLS, но для улучшенной безопасности вы можете рассмотреть:
dirsrv_password_storage_scheme: "PBKDF2_SHA256"
# даже если стандартная схема хранения паролей уже достаточно сильна.
Здесь вы можете найти скрипт для генерации самоподписанных сертификатов, которые были многократно протестированы с 389DS. Или посмотрите в директорию molecule для примера сертификата и ключа, который используется для тестирования роли.
Тем не менее, имейте в виду, что скрипт предоставляется только как пример для тестирования, его не рекомендуется использовать в производстве.
389DS автоматически перезапускается при необходимости для применения конфигурации. Оба LDAPS (порт 636) и StartTLS (порт 389) включены.
Если вам надоест иметь защищенное соединение, установите dirsrv_tls_enabled: false, но сертификат останется в базе данных NSS 389DS. Его можно удалить вручную.
Смена сертификатов (замена сертификата и ключа на новый, например, потому что старые истекли) кажется работающей с самоподписанными и Let's Encrypt сертификатами, но процесс все еще довольно сложен и полон хака и обходных путей. Если вы хотите использовать это в производстве, рекомендуется ознакомиться с соответствующими частями раздела 9.3 Руководства администратора и комментариями в tasks/configure_tls.yml, чтобы понять, что происходит и почему.
TLS с Let's Encrypt (или другими провайдерами ACME)
Ключевой момент заключается в том, что вы должны предоставить "fullchain" (сертификат сервера и все промежуточные, без корневого сертификата) в роль 389ds-server. Поскольку я не мог найти много других примеров с http-01 вызовом с acme_certificate, я добавил это здесь, чтобы дать вам лучшее представление о всех необходимых шагах.
- name: Пример плейбука
hosts: example
pre_tasks:
- name: Убедиться, что ACME-аккаунт существует
acme_account:
# acme_directory: "http://..." # Ваш провайдер. Оставьте это поле пустым, чтобы использовать тестовый каталог Let's Encrypt
account_key_content: "{{ acme_account_key }}" # "openssl genrsa 2048" для его генерации, но читайте https://docs.ansible.com/ansible/latest/modules/acme_account_module.html для более актуальной информации
acme_version: 2
state: present
terms_agreed: true
contact:
- mailto:[email protected]
# Вам нужен CSR (запрос на подпись сертификата). И приватный ключ.
# Не используйте старый ключ для аккаунта, создайте новый!
# Генерируйте их:
#
# openssl genrsa 2048 -out example.key
# openssl req -new -key example.key -out example.csr -subj "/C=/ST=/L=/O=/OU=/CN=your.domain.example.com"
#
# Только доменное имя имеет значение. И ключи example.key, и ваш аккаунт должны оставаться в секрете,
# вы можете поместить их в Ansible Vault и использовать шаблон для создания example.key из переменной.
- name: Копирование CSR и приватного ключа
copy:
src: "{{ item }}"
dest: "/etc/some/secret/directory"
owner: root
group: root
mode: "400" # CSR может быть читаемым для всех, на самом деле, он не секретен
setype: cert_t
loop:
- "path/to/your/example.csr"
- "path/to/your/example.key"
- name: Создать вызов
acme_certificate:
acme_directory: "http://..."
account_key_content: "{{ acme_account_key }}"
acme_version: 2
challenge: "http-01"
# Вам потребуется полный цепь (которая включает ваш сертификат и все
# промежуточные, но без корневого сертификата). Это будет помещено
# в NSS/389DS, который должен обслуживать все их.
fullchain: "/etc/some/secret/directory/example.fullchain.pem"
csr: "/etc/some/secret/directory/example.csr"
# remaining_days: 10
register: acme_challenge
# Вам нужен работающий HTTP сервер. Представьте, что есть экземпляр NGINX, который
# обслуживает страницы на example.com из /var/www/html/example.com
# Если вы считаете, что всегда работающий HTTP сервер — это неудобно, используйте "when: acme_challenge is changed",
# чтобы запустить его для вызова и остановить в конце...
#
# Вам также потребуется несколько директорий, иначе следующая задача завершится ошибкой, потому что они
# не существуют...
- name: Создать HTTP директории для ACME http-01 вызова
file:
name: "{{ item }}"
state: directory
owner: root
group: root
# Эти директории не должны быть секретными (они доступны из Интернета),
# просто не делайте их доступными для записи никем
mode: "755"
setype: httpd_sys_content_t # только для чтения
loop:
- "/var/www/html/example.com"
- "/var/www/html/example.com/.well-known"
- "/var/www/html/example.com/.well-known/acme-challenge"
- name: Удовлетворить вызов http-01
copy:
dest: "/var/www/html/example.com/{{ acme_challenge['challenge_data']['example.com']['http-01']['resource'] }}"
content: "{{ acme_challenge['challenge_data']['example.com']['http-01']['resource_value'] }}"
when: acme_challenge is changed
# То же самое, что и предыдущая задача acme_certificate, просто добавьте "data"
- name: Сделайте вызов
acme_certificate:
acme_directory: "http://..."
account_key_content: "{{ acme_account_key }}"
acme_version: 2
challenge: "http-01"
fullchain: "/etc/some/secret/directory/example.fullchain.pem"
csr: "/etc/some/secret/directory/example.csr"
data: "{{ acme_challenge }}"
when: acme_challenge is changed
# Не оптимально (на несколько моментов до этого сертификат имеет неправильные
# разрешения)
# Возможно, можно установить этой задаче значение "state: touch" и разместить ее перед
# предыдущей, однако.
- name: Обеспечить разрешения для сертификата примера
file:
state: file
path: "/etc/some/secret/directory/example.fullchain.pem"
owner: root
group: root
mode: "400"
setype: cert_t
# В этом примере я использовал почти никакие переменные для большей ясности
# (т.е. вы видите, как эти строки должны выглядеть, вместо произвольного
# имени, которое я придумал), но в реальном плейбуке было бы лучше использовать
# некоторые переменные.
roles:
- role: lvps.389ds_server
dirsrv_suffix: "dc=example,dc=local"
dirsrv_serverid: example
dirsrv_rootdn_password: secret
dirsrv_tls_enabled: true
dirsrv_tls_cert_file: /etc/some/secret/directory/example.fullchain.pem
dirsrv_tls_key_file: /etc/some/secret/directory/example.key
dirsrv_tls_files_remote: true # Оба файла на сервере
dirsrv_tls_certificate_trusted: true # Не нужно отключать проверки сертификатов, ура!
Поскольку поддержка смены сертификатов предусмотрена этой ролью, вам просто нужно периодически запускать этот плейбук, чтобы обновить сертификат, когда он начинает истекать.
Что насчет репликации?
Для этого есть еще одна роль.
Тесты
Тесты используют замену systemctl docker, созданную и распространенную gdraheim по лицензии EUPL. Этот скрипт загружается и копируется в локальный контейнер для корректного выполнения тестов. Такое распространение происходит в соответствии с той же лицензией и условиями, на которых gdraheim создал и опубликовал свою работу. Скрипт загружается как есть, и никаких изменений в нем не вносится. Запуская тесты на своих машинах, конечный пользователь согласен обращаться с загруженным скриптом на тех же условиях EUPL, как это задумывал его автор. Обратите внимание, что сами тесты (и роль в целом) все еще лицензированы по лицензии Apache 2.
Эта роль использует molecule для своих тестов. Установите ее с помощью pip, вероятно, и протестируйте все сценарии:
python -m venv venv
venv/bin/activate
pip install -r requirements.txt
molecule test --all
Или протестировать один сценарий: molecule test -s tls
Будущие расширения
Могут быть выполнены, но не запланированы на ближайшее время
- Поддержка Debian/Ubuntu/FreeBSD или любой другой платформы, которую поддерживает 389DS
- Поддержка других плагинов, требующих больше, чем просто включение/выключение
- Поддержка других атрибутов DNA
Лицензия
Apache 2.0 для роли и связанных тестов
EUPL v 1.2 для скрипта "замены docker systemctl" от gdraheim (не включен, но загружается при запуске тестов)
Информация об авторе
Сопровождающий: Людовико Павези
Участник/оригинальный автор: Колби Приор
Участник/оригинальный автор: Артемий Кропачев
Благодарности Firstyear за комментарии
Installs 389DS LDAP server. Also configures TLS, logging, custom schema files, enable/disable plugins, DNA plugin for UID/GID, LDAPI and SASL PLAIN.
ansible-galaxy install lvps/389ds-server