389ds-server

Ta rola instaluje serwer 389DS (serwer LDAP) na docelowej maszynie.

ansible-galaxy install lvps.389ds_server

Funkcje

• Instalacja pojedynczego serwera LDAP
• Konfiguracja logowania
• Dodawanie niestandardowych plików schematu
• Włączanie/wyłączanie dowolnych wtyczek
• Konfiguracja wtyczki DNA dla numerów UID/GID
• Konfiguracja TLS
• Wymuszanie TLS (minimalny SSF i wymaganie bezpiecznych połączeń) lub powrót do opcjonalnego TLS
• Włączanie/wyłączanie LDAPI
• Włączanie/wyłączanie SASL PLAIN

Replikacja jest zarządzana za pomocą innej roli.

Wymagania

• Ansible 2.10 lub nowszy, dla Ansible 2.8 i 2.9 użyj wersji 3.1.x tej roli
• SUSE (OpenSUSE lub SLES) lub CentOS 7, CentOS 8, CentOS 9 lub inny system operacyjny oparty na RHEL

Zmienne roli

Zmienne, które można przekazać do tej roli i ich krótki opis są następujące.

dirsrv_product

Domyślna: zależna od systemu operacyjnego · Można zmieniać: Nie

Istnieją dwie główne wersje: bezpłatny 389 Directory Server i wspierany Red Hat Directory Server. W przypadku darmowych wydań możesz zaufać domyślnym ustawieniom. W przeciwnym razie możesz dostosować tę wartość do swoich potrzeb. Aktualnie jedyną przetestowaną wartością inną niż domyślna jest '@redhat-ds:11' dla Red Hat Directory Server 11, dostępnego w systemie Red Hat EL8.

dirsrv_port

Domyślna: 389 · Można zmieniać: Nie

Port, na którym 389ds nasłuchuje.

dirsrv_suffix

Domyślna: dc=example,dc=com · Można zmieniać: Nie

Sufiks DIT. Wszystkie wpisy na serwerze będą znajdować się pod tym sufiksem. Zwykle tworzy się go z komponentów domeny (dc) głównej domeny Twojej firmy. Przykład: Jeśli jesteś z example.co.uk, a serwer będzie znajdował się pod ldap-server.example.co.uk, ustaw sufiks na dc=example,dc=co,dc=uk, pomijając część subdomeny (ldap-server), ponieważ jest nieistotna.

dirsrv_bename

Domyślna: userRoot · Można zmieniać: Nie

Nazwę wewnętrznej bazy danych sufiksu.

dirsrv_othersuffixes

Domyślna: [] · Można zmieniać: Nie

Lista innych słowników sufiksów w formacie { name: <bename>, dn: <rootDN>}

dirsrv_rootdn

Domyślna: cn=Directory Manager · Można zmieniać: Nie

Root DN, czyli nazwa użytkownika „konta administratora”. Użyj tego DN, aby zignorować wszystkie kontrole autoryzacji.

dirsrv_rootdn_password

Można zmieniać: Nie

Hasło dla root DN, musisz zdefiniować tę zmienną, w przeciwnym razie rola zakończy się niepowodzeniem.

dirsrv_fqdn

Domyślna: {{ansible_nodename}} · Można zmieniać: Nie

FQDN serwera, np. ldap.example.com. Jeśli nazwa hosta serwera jest już FQDN, domyślna powinna zostać automatycznie wykryta.

dirsrv_serverid

Domyślna: default · Można zmieniać: ¹

ID serwera lub ID instancji. Wszystkie dane dotyczące instancji skonfigurowanej przez tę rolę zostaną zapisane w /etc/dirsrv/slapd-default, /var/log/dirsrv/slapd-default itd. Możesz użyć nazwy swojej firmy, np. dla Foo Bar, Inc ustaw zmienną na foobar, a katalogi będą nazwane slapd-foobar.

dirsrv_listen_host

Można zmieniać: Tak

Nasłuchuje na tych adresach/nazwach hostów. Jeśli nie jest ustawione (domyślnie) nic nie robi, a jeśli ustawione na ciąg, ustawi atrybut nsslapd-listenhost. Ustaw na [], aby usunąć atrybut.

dirsrv_secure_listen_host

Można zmieniać: Tak

To samo co dirsrv_listen_host, ale dla LDAPS. Jeśli nie jest ustawione (domyślnie) nic nie robi, a jeśli ustawione na ciąg, ustawi atrybut nsslapd-securelistenhost. Ustaw na [], aby usunąć atrybut.

dirsrv_server_uri

Domyślna: ldap://localhost · Można zmieniać: ¹

URI serwera dla zadań, które łączą się za pośrednictwem LDAP. Ponieważ zadania są uruchamiane na tym samym serwerze co 389DS, w większości przypadków będzie to localhost, nie ma potrzeby dostosowywania tego.

dirsrv_factory

Domyślna: false · Można zmieniać: Tak

Zachowuje domyślne ustawienia dotyczące parametrów autoryzacji i logowania. Jeśli true, parametry dirsrv_logging, dirsrv_simple_auth_enabled, dirsrv_password_storage_scheme, dirsrv_ldapi_enabled, dirsrv_sasl_plain_enabled będą całkowicie ignorowane.

dirsrv_install_examples

Domyślna: false · Można zmieniać: Nie

Tworzy przykładowe wpisy pod sufiksem podczas instalacji.

dirsrv_install_additional_ldif

Domyślna: [] · Można zmieniać: Nie

Instaluje dodatkowe pliki LDIF, domyślnie brak (pusta tablica). Odnosi się to do dyrektywy InstallLdifFile w pliku instalacyjnym inf dla 389DS <= 1.3. Od wersji 1.4 i nowszych, jest to realizowane za pomocą dsconf.

dirsrv_ldif_files_remote

Domyślna: false - można zmieniać: Tak

Pliki ldif znajdują się na zdalnym serwerze, a nie na kontrolerze ansible.

dirsrv_install_additional_ldif_dir

Domyślna: /var/lib/dirsrv/slapd-{{ dirsrv_serverid }}/ldif · Można zmieniać: Nie

Katalog, w którym pliki ldif dla dirsrv_install_additional_ldif są tymczasowo przechowywane. Nie może to być /tmp, ponieważ usługa 389DS ma ustawione systemd PrivateTmp na true od CentOS/RHEL 8.3.

dirsrv_logging

Domyślna: patrz poniżej · Można zmieniać: Tak

Zobacz poniżej.

dirsrv_plugins_enabled

Domyślna: {} · Można zmieniać: Tak

Włącz lub wyłącz wtyczki, szczegóły poniżej. Domyślnie żadna wtyczka nie jest włączona ani wyłączona.

dirsrv_dna_plugin

Domyślna: patrz poniżej · Można zmieniać: Tak

Konfiguracja dla wtyczki DNA (Rozproszona Numeryczna Przypisanie).

dirsrv_custom_schema

Domyślna: [] · Można zmieniać: Tak

Ścieżki do niestandardowych plików schematu. Zostaną umieszczone w /etc/dirsrv/slapd-{{ dirsrv_serverid }}/schema, a zażądany zostanie ponowny załadunek schematu, gdy cokolwiek się zmieni.

dirsrv_allow_other_schema_files

Domyślna: false · Można zmieniać: Tak

Jeśli fałsz (domyślna wartość), ta rola doda określone pliki schematu do /etc/dirsrv/slapd-{{ dirsrv_serverid }}/schema, a następnie usunie wszystkie inne pliki schematu, z wyjątkiem 99user.ldif. Jeśli Twoje pliki schematu są zarządzane tylko przez tę rolę lub dynamicznie (tj. z cn=schema, który zapisuje do 99user.ldif), możesz pozostawić tę zmienną domyślną. Jeśli masz więcej plików schematu w tym katalogu (dodane ręcznie lub przez inne zadania), ustaw to na true, aby je tam zostawić. Wadą jest to, że jeśli wdrażasz e.g. 50example.ldif, a następnie zmieniasz jego nazwę na 50my_example.ldif, kiedy rola uruchomi się ponownie, uznaje to za nowy plik i zostawia poprzedni, co powoduje zamieszanie w katalogu.

dirsrv_tls_enabled

Domyślna: false · Można zmieniać: Tak

Włącz TLS (LDAPS i StartTTLS). Wszystkie zmienne "dirsrv_tls" mają znaczenie tylko wtedy, gdy to jest włączone.

dirsrv_tls_min_version

Domyślna: '1.2' · Można zmieniać: Tak

Minimalna wersja TLS: 1.0, 1.1 lub 1.2. Ewentualnie 1.3, jeśli jest obsługiwana przez wersję 389DS. SSLv2 i SSLv3 są zawsze wyłączone przez tę rolę.

dirsrv_tls_certificate_trusted

Domyślna: true · Można zmieniać: Tak

Certyfikat serwera jest publicznie zaufany. Ustaw na fałsz tylko w środowisku deweloperskim (dla certyfikatów samopodpisanych)!

dirsrv_tls_enforced

Domyślna: false · Można zmieniać: Tak

Wymusza TLS, wymagając bezpiecznych połączeń i minimalnego SSF.

dirsrv_tls_minssf

Domyślna: 256 · Można zmieniać: Tak

Minimalny SSF, używany tylko gdy dirsrv_tls_enforced jest true. 128 wydaje się rozsądne, 256 powinno być bardzo bezpieczne. Ustaw to na 0, aby wymuszać TLS tylko na bezpiecznych połączeniach.

dirsrv_allow_anonymous_binds

Domyślna: 'rootdse' · Można zmieniać: Tak

Zezwalaj na połączenia anonimowe: boolean true dla Tak, boolean false dla Nie, lub 'rootdse'. Przewodnik administracyjny sugeruje używanie rootdse zamiast Nie, ponieważ pozwala na anonimowe połączenia w celu przeszukiwania niektórych danych, które klienci mogą potrzebować przed nawiązaniem połączenia. Zezwolenie na anonimowe połączenia zasadniczo czyni Twój katalog publicznym, chyba że ograniczysz dostęp za pomocą ACI.

dirsrv_simple_auth_enabled

Domyślna: true · Można zmieniać: Tak

Włącz autoryzację SIMPLE, prawdopodobnie true, chyba że chcesz używać tylko SASL PLAIN lub konfigurować inne metody ręcznie.

dirsrv_password_storage_scheme

Domyślna: [] · Można zmieniać: Tak

Jedna wartość, możliwie ciąg "PBKDF2_SHA256". Lub pozostaw domyślną, która usunie wszelkie niestandardowe wartości i użyje domyślnej 389DS, która powinna być wystarczająco bezpieczna.

dirsrv_ldapi_enabled

Domyślna: false · Można zmieniać: Tak

Włącz LDAPI (połączenie z serwerem za pośrednictwem gniazda UNIX w ldapi:///var/run/dirsrv/slapd-{{ dirsrv_serverid }}.socket). Należy pamiętać, że to podlega wymuszeniu TLS, a TLS nie jest obsługiwany, więc jest bezużyteczne, jeśli ustawisz dirsrv_tls_enforced na true.

dirsrv_sasl_plain_enabled

Domyślna: true · Można zmieniać: Tak

Włącz autoryzację SASL PLAIN: jeśli klient próbuje przeprowadzić autoryzację bez TLS i TLS jest wymuszony, tego rodzaju autoryzacja powinna zablokować go przed wysłaniem hasła w postaci czystego tekstu, podczas gdy prosta autoryzacja wyśle hasło i zakończy się niepowodzeniem, ponieważ SSF jest za niski.

Zmienne ekskluzywne dla wersji 389DS 1.4.X

Te zmienne mają wpływ tylko na instalacje wersji 389DS 1.4.X i nie mają wpływu na wcześniejsze wersje, nawet jeśli są zdefiniowane.

dirsrv_defaults_version

Domyślna: 999999999² · Można zmieniać: Nie

Wartości konfiguracyjne domyślne będą tymi ze specyfikowanej wersji 389DS. Format to XXXYYYZZZ, gdzie XXX to wersja główna, YYY to wersja mniejsza i ZZZ to poziom poprawki (wszystkie trzy wartości są wyrównane do długości trzech). Jeśli wybrano 999999999, użyte zostaną ostatnie wersje domyślne.

dirsrv_selfsigned_cert

Domyślna: True² · Można zmieniać: Nie

Określa, czy 389DS wygeneruje certyfikat samopodpisany i automatycznie włączy TLS.

dirsrv_selfsigned_cert_duration

Domyślna: 24² · Można zmieniać: Nie

Okres ważności w miesiącach certyfikatu samopodpisanego wygenerowanego przez 389DS.

dirsrv_create_suffix_entry

Domyślna: False² · Można zmieniać: Nie

Określa, czy 389DS wygeneruje wpis sufiksu w katalogu o podanym sufiksie: cn={{ dirsrv_suffix }}

dirsrv_rundir

Można zmieniać: Nie

Jeśli zdefiniowane, skonfiguruj określoną ścieżkę dla db_home_dir.

dirsrv_rundir

Można zmieniać: Nie

Jeśli zdefiniowane, konfiguruje konkretną ścieżkę dla run_dir.

Interoperacyjność między 1.3.X a 1.4.X

Aby mieć playbook, który zachowuje się w ten sam sposób w wersjach 1.3 i 1.4 389DS, należy użyć następujących wartości:

Zmienna	Wartość
dirsrv_defaults_version	001004002³
dirsrv_selfsigned_cert	False
dirsrv_create_suffix_entry	True

Uwagi

Niektóre zmienne nie mogą być zmieniane przez tę rolę (lub w ogóle) po utworzeniu instancji 389DS. Jeśli jedna z nich zostanie zmieniona i rola zostanie zastosowana ponownie, może wystąpić nieokreślone zachowanie - od „nic” po „rola nie powiedzie się”. Niektóre z nich, np. hasło root DN, można zmienić ręcznie: proszę zapoznać się z Przewodnikiem administracyjnym po więcej szczegółów.

¹ Zmiana tej zmiennej z poprzedniego uruchomienia spowoduje utworzenie innej instancji, innego katalogu całkowicie oddzielonego od poprzedniego, co powinno działać dobrze, jeśli to jest Twój cel.

² To są wartości domyślne od wersji 389DS 1.4.2.15 i mogą się zmienić w późniejszych wersjach: uruchom dscreate create-template na swoim komputerze, aby zobaczyć domyślne ustawienia dla bieżącej wersji.

³ To jest wersja domyślna, na podstawie której ta rola została napisana i zweryfikowana. Ustawienie dirsrv_defaults_version nie jest technicznie wymagane, ale może zapobiec przyszłym aktualizacjom domyślnych ustawień, które mogą złamać playbook, mogąc być niekompatybilne z 389DS 1.3. Z drugiej strony, ustawienie zmiennej zasadniczo zablokuje konfigurację w czasie, a jeśli zostanie wykonane przez dłuższy czas, może uczynić ją przestarzałą. Używaj z rozwagą.

Wszystkie zmienne mają prefiks dirsrv, ponieważ rozpoczęcie nazwy zmiennej liczbą („389ds”) nie działa zbyt dobrze.

dirsrv_logging

To jest domyślna zmienna:

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 domyślnie nie łączy słowników, tzn. jeśli chcesz zmienić tylko audit > enabled na true, musisz zdefiniować wszystkie inne zmienne również. Jeśli chcesz zmienić domyślne ustawienia, warto skopiować cały ten blok do zmiennych i dostosować to, co potrzebujesz.

dirsrv_plugins_enabled

Jeśli chcesz włączyć wtyczkę memberof znajdującą się w cn=MemberOf Plugin,cn=plugins,cn=config, ustaw zmienną na:

dirsrv_plugins_enabled:
  MemberOf Plugin: true

Jeśli jest włączona i chcesz ją wyłączyć, ustaw na:

dirsrv_plugins_enabled:
  MemberOf Plugin: false

Jeśli chcesz włączyć więcej wtyczek:

dirsrv_plugins_enabled:
  MemberOf Plugin: true
  Distributed Numeric Assignment Plugin: true

Jeśli wtyczka nie pojawia się na liście, jej status pozostaje niezmieniony.

Wtyczka o nazwie Foo powinna mieć wpis w cn=Foo,cn=plugins,cn=config, możesz zajrzeć do drzewa cn=plugins,cn=config, aby zobaczyć, które wtyczki są dostępne i ich status.

dirsrv_dna_plugin

Wartość domyślna:

dirsrv_dna_plugin:
  gid_min: 2000
  gid_max: 2999
  uid_min: 2000
  uid_max: 2999

Ansible domyślnie nie łączy słowników, tzn. jeśli chcesz zmienić tylko uid_max i gid_max, musisz również zdefiniować wartości *_min. Kiedy definiujesz dirsrv_dna_plugin, zastępuje to ten domyślny słownik w całości.

Ta konfiguracja ma zastosowanie tylko wtedy, gdy "Wtyczka rozproszonych przypisań numerycznych" jest ustawiona na true w dirsrv_plugins_enabled, i jest usuwana, gdy jest false. Jeśli nie jest wspomniane, nic się nie dzieje.

dirsrv_replica_role musi być zdefiniowane, aby skonfigurować DNA z replikacją. Ta zmienna jest również definiowana w roli lvps/389ds-replication, więc zapoznaj się z dokumentacją tej roli w celu uzyskania szczegółów. Dla tej roli wystarczy, aby była zdefiniowana, jeśli korzystasz z replikacji, wartość nie ma znaczenia.

Tagów

Dostępnych jest kilka tagów, więc możesz uruchomić np.:

ansible-playbook some-playbook.yml --tags dirsrv_schema

co zaktualizuje tylko niestandardowe pliki schematu, nie zmieniając nic innego. Oczywiście some-playbook.yml powinien stosować tę rolę.

Tagi to:

• dirsrv_schema: zadania dotyczące niestandardowych schematów
• dirsrv_tls: wszystkie zadania konfiguracyjne dotyczące TLS, w tym certyfikaty i wymuszania
• dirsrv_cert: zadania dotyczące certyfikatów TLS, podzbiór dirsrv_tls

Wszystkie tagi zawierają również kilka kontroli na początku działania, a na końcu "flush handlers", ponieważ 389DS może wymagać ponownego uruchomienia lub załadowania schematu.

dirsrv_cert jest szczególnie przydatny do automatyzacji zarządzania certyfikatami z ACME: zobacz poniżej przykład "TLS z Let's Encrypt (lub innymi dostawcami ACME)". Jeśli ten sam tag zostanie dodany do wszystkich zadań związanych z ACME, można regularnie uruchamiać ansible-playbook some-playbook.yml --tags dirsrv_cert, aby automatycznie aktualizować certyfikaty.

Zależności

Brak.

Użycie i przykłady

Minimalny działający przykład

- name: Przykładowy playbook
  hosts: example
  roles:
    - role: lvps.389ds_server
      dirsrv_rootdn_password: secret

Połącz się z DN cn=Directory Manager i hasłem secret na porcie 389, sufiks będzie dc=example,dc=local, wszystko inne jest zasadniczo jak czysta instalacja 389DS.

Ansible Vault byłoby dobrym pomysłem, aby uniknąć ujawnienia hasła root DN jako tekstu jawnego w produkcji.

Konfiguracja zapory sieciowej

Nie jest częścią tej roli, ale może być konieczne otwarcie portu LDAP (389) do zdalnego dostępu do serwera:

- name: Zezwól na port ldap w firewalld
  firewalld: service=ldap permanent=true state=enabled

To samo może być potrzebne dla portu LDAPS (636), jeśli włączysz TLS i chcesz używać tego zamiast StartTLS.

Przykładowe wpisy i pewne dostosowania

- name: Przykładowy playbook
  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"

Połącz się z DN cn=admin i hasłem secret na porcie 389, sprawdź przykładowe wpisy dostarczone przez 389DS.

Logi audytu są również włączone, a wszystkie logi są przechowywane przez 14 dni (lub do czasu, gdy staną się zbyt duże).

Wtyczka MemberOf jest również włączona.

Zajrzyj do katalogu molecule, aby znaleźć plik schematu dostosowanego, który jest znany z działania z 389DS, jeśli chcesz przetestować tę część, ale nie masz ważnego pliku schematu. Usuń tę część, aby usunąć wszystkie niestandardowe pliki schematu. Przeładowanie schematu jest realizowane automatycznie.

TLS

- name: Przykładowy playbook
  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 # Prawda, jeśli pliki są już na zdalnym hoście (np. dostarczone przez certbot)
      dirsrv_tls_certificate_trusted: true # Lub fałsz, jeśli certyfikat jest samopodpisany
      # Jeśli chcesz uniknąć prostego LDAP i wymusić TLS, rozważ również te ustawienia:
      dirsrv_tls_enforced: true
      dirsrv_tls_minssf: 256
      # Nic nie ma wspólnego z TLS, ale dla poprawy bezpieczeństwa możesz rozważyć:
      dirsrv_password_storage_scheme: "PBKDF2_SHA256"
      # choć domyślna metoda przechowywania haseł jest już wystarczająco silna.

Kliknij tutaj, aby znaleźć skrypt do generowania certyfikatów samopodpisanych, które były wielokrotnie testowane z 389DS. Albo zajrzyj do katalogu molecule, aby znaleźć przykładowy certyfikat i klucz używany do testów tej roli.

Jednak pamiętaj, że skrypt jest tylko przykładem do testowania, nie jest zalecany do użytku produkcyjnego.

389DS jest automatycznie ponownie uruchamiane w razie potrzeby w celu zastosowania konfiguracji. Zarówno LDAPS (port 636), jak i StartTLS (port 389) są włączone.

Jeśli masz dość posiadania bezpiecznego połączenia, ustaw dirsrv_tls_enabled: false, ale certyfikat pozostanie w bazie danych NSS 389DS. Można go usunąć ręcznie.

Przeładowanie certyfikatu (wymiana certyfikatu i klucza na nowy, np. z powodu wygaśnięcia starych) wydaje się działać zarówno z certyfikatami samopodpisanymi, jak i certyfikatami Let's Encrypt, ale proces jest nadal bardzo skomplikowany i pełen sztuczek i obejść. Jeśli chcesz korzystać z tego w produkcji, warto zapoznać się z odpowiednimi częściami sekcji 9.3 Przewodnika administracyjnego oraz komentarzami w tasks/configure_tls.yml, aby zrozumieć, co się dzieje i dlaczego.

TLS z Let's Encrypt (lub innymi dostawcami ACME)

Kluczowym punktem jest to, że musisz dostarczyć "fullchain" (certyfikat serwera oraz wszystkie certyfikaty pośrednie, bez certyfikatu głównego) do roli serwera 389ds. Ponieważ nie mogłem znaleźć wielu innych przykładów na temat wyzwania http-01 z acme_certificate, dodałem to tutaj, aby lepiej zobrazować wszystkie konieczne kroki.

- name: Przykładowy playbook
  hosts: example
  pre_tasks:
    - name: Upewnij się, że konto ACME istnieje
      acme_account:
        # acme_directory: "http://..."  # Twój dostawca. Pozostaw to puste, aby używać katalogu testowego Let's Encrypt
        account_key_content: "{{ acme_account_key }}"  # "openssl genrsa 2048" aby je wygenerować, ale przeczytaj https://docs.ansible.com/ansible/latest/modules/acme_account_module.html dla bardziej aktualnych informacji
        acme_version: 2
        state: present
        terms_agreed: true
        contact:
          - mailto:[email protected]

    # Potrzebujesz CSR (żądanie podpisania certyfikatu). I klucz prywatny.
    # Nie używaj tego samego klucza konta, stwórz nowy!
    # Wygeneruj je:
    #
    # 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"
    #
    # Tylko domena jest ważna. Zarówno example.key, jak i klucz konta powinny być traktowane jako tajne,
    # można je umieścić w Ansible Vault i użyć szablonu do utworzenia example.key z zmiennej.
    - name: Skopiuj CSR i klucz prywatny
      copy:
        src: "{{ item }}"
        dest: "/etc/some/secret/directory"
        owner: root
        group: root
        mode: "400"  # CSR może być dostępny dla wszystkich, w rzeczywistości, nie jest tajny
        setype: cert_t
      loop:
        - "path/to/your/example.csr"
        - "path/to/your/example.key"

    - name: Utwórz wyzwanie
      acme_certificate:
        acme_directory: "http://..."
        account_key_content: "{{ acme_account_key }}"
        acme_version: 2
        challenge: "http-01"
        # Będziesz potrzebować pełnego łańcucha (który zawiera Twój certyfikat oraz wszystkie
        # certyfikaty pośrednie, ale nie certyfikat główny). To zostanie wprowadzone
        # do NSS/389DS, który powinien służyć wszystkim.
        fullchain: "/etc/some/secret/directory/example.fullchain.pem"
        csr: "/etc/some/secret/directory/example.csr"
        # remaining_days: 10
      register: acme_challenge

    # Musisz mieć uruchomiony serwer HTTP. Wyobraź sobie, że istnieje instancja NGINX, która
    # obsługuje strony na example.com z /var/www/html/example.com
    # Jeśli stwierdzisz, że zawsze działający serwer HTTP jest uciążliwy, można użyć 
    # "when: acme_challenge is changed", aby uruchomić go na czas wyzwania i zatrzymać na końcu...
    #
    # Będziesz również potrzebować kilku katalogów, lub następne zadanie nie powiedzie się, ponieważ
    # nie będą istnieć...
    - name: Utwórz katalogi HTTP do wyzwania ACME http-01
      file:
        name: "{{ item }}"
        state: directory
        owner: root
        group: root
        # Te katalogi nie powinny być tajne (są dostępne z internetu),
        # po prostu nie rób ich zapisywalnymi przez nikogo
        mode: "755"
        setype: httpd_sys_content_t  # tylko do odczytu
      loop:
        - "/var/www/html/example.com"
        - "/var/www/html/example.com/.well-known"
        - "/var/www/html/example.com/.well-known/acme-challenge"

    - name: Wypełnij wyzwanie 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

    # Tak samo jak wcześniej, tylko dodaj "data"
    - name: Wykonaj wyzwanie
      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

    # Nieoptymalne (przez chwilę przed tym zdarzeniem certyfikat ma
    # złe uprawnienia)
    # Może to być możliwe, aby ustawić to zadanie na "state: touch" i umieścić je przed
    # poprzednim, choć.
    - name: Upewnij się, że uprawnienia dla certyfikatu example są właściwe
      file:
        state: file
        path: "/etc/some/secret/directory/example.fullchain.pem"
        owner: root
        group: root
        mode: "400"
        setype: cert_t

  # W tym przykładzie użyłem prawie żadnych zmiennych dla większej przejrzystości
  # (tzn. widzisz, jak powinny wyglądać te ciągi, zamiast umownej
  # nazwy, którą wymyśliłem), ale w prawdziwym playbook warto używać
  # pewnych zmiennych.

  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  # Oba pliki są na serwerze
      dirsrv_tls_certificate_trusted: true  # Nie ma potrzeby wyłączania sprawdzania certyfikatów, hura!

Ponieważ rola wspiera przeładowanie certyfikatów, wystarczy regularnie uruchamiać ten playbook, aby aktualizować certyfikat, gdy zbliża się termin wygaśnięcia.

A co z replikacją?

Dla tego istnieje inna rola.

Testy

Testy korzystają z reprezentacji systemctl w dockerze stworzonej i dystrybuowanej przez gdraheim na podstawie licencji EUPL. Ten skrypt jest pobierany i kopiowany do lokalnego kontenera, aby testy mogły się poprawnie wykonać. Taka dystrybucja odbywa się na tych samych zasadach i warunkach, na jakich gdraheim stworzył i opublikował swoją pracę. Skrypt jest pobierany w stanie takim, jakim jest, i nie dokonuje się w nim żadnych zmian. Uruchamiając testy na swoich maszynach, użytkownik końcowy zgadza się na obsługę pobranego skryptu zgodnie z tymi samymi zasadami EUPL, jakie zamierzano przez jego autora. Należy pamiętać, że testy same (i rola ogólnie) nadal są licencjonowane na podstawie licencji Apache 2.

Ta rola korzysta z molka w celu przeprowadzania testów. Zainstaluj go prawdopodobnie za pomocą pip i przetestuj wszystkie scenariusze:

python -m venv venv
venv/bin/activate
pip install -r requirements.txt
molecule test --all

Lub aby przetestować pojedynczy scenariusz: molecule test -s tls

Przyszłe rozszerzenia

Możliwe do zrealizowania, ale nieplanowane w krótkim terminie

• Wsparcie dla Debiana/Ubuntu/FreeBSD lub innej platformy, którą wspiera 389DS
• Wsparcie dla innych wtyczek, które potrzebują więcej niż włączone/wyłączone
• Wsparcie dla innych atrybutów DNA

Licencja

Apache 2.0 dla roli oraz związanych testów
EUPL v 1.2 dla "zastępczego systemctl docker" skryptu od gdraheim (nie włączone, ale pobierane podczas uruchamiania testów)

Informacje o autorze

Utrzymujący: Ludovico Pavesi
Współtwórca/originalny autor: Colby Prior
Współtwórca/originalny autor: Artemii Kropachev
Podziękowania dla Firstyear za komentarze