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, поэтому обратитесь к ней за документацией. Для этой роли достаточно, чтобы она была определена, если вы используете репликацию, значение не имеет значения.

Все теги также включают несколько проверок в начале плейбука и "очистка обработчиков" в конце, так как 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.

role ldap

Установить

ansible-galaxy install lvps/389ds-server

GitHub репозиторий

23 звезд(ы)

14 форк(ов)

11 открытых задач

Лицензия

apache-2.0

Загрузки

66394

Владелец

lvps

389ds-сервер

Функции

Требования

Переменные роли

dirsrv_product

dirsrv_port

dirsrv_suffix

dirsrv_bename

dirsrv_othersuffixes

dirsrv_rootdn

dirsrv_rootdn_password

dirsrv_fqdn

dirsrv_serverid

dirsrv_listen_host

dirsrv_secure_listen_host

dirsrv_server_uri

dirsrv_factory

dirsrv_install_examples

dirsrv_install_additional_ldif

dirsrv_ldif_files_remote

dirsrv_install_additional_ldif_dir

dirsrv_logging

dirsrv_plugins_enabled

dirsrv_dna_plugin

dirsrv_custom_schema

dirsrv_allow_other_schema_files

dirsrv_tls_enabled

dirsrv_tls_min_version

dirsrv_tls_certificate_trusted

dirsrv_tls_enforced

dirsrv_tls_minssf

dirsrv_allow_anonymous_binds

dirsrv_simple_auth_enabled

dirsrv_password_storage_scheme

dirsrv_ldapi_enabled

dirsrv_sasl_plain_enabled

Переменные, эксклюзивные для версии 389DS 1.4.X

dirsrv_defaults_version

dirsrv_selfsigned_cert

dirsrv_selfsigned_cert_duration

dirsrv_create_suffix_entry

dirsrv_rundir

dirsrv_rundir

Совместимость между версиями 1.3.X и 1.4.X

Примечания

dirsrv_logging

dirsrv_plugins_enabled

dirsrv_dna_plugin

Теги

Зависимости

Использование и примеры

Минимальный рабочий пример

Настройка брандмауэра

Пример записи и небольшой кастомизацией

TLS

TLS с Let's Encrypt (или другими провайдерами ACME)

Что насчет репликации?

Тесты

Будущие расширения

Могут быть выполнены, но не запланированы на ближайшее время

Лицензия

Информация об авторе

Installs 389DS LDAP server. Also configures TLS, logging, custom schema files, enable/disable plugins, DNA plugin for UID/GID, LDAPI and SASL PLAIN.