lvps.389ds_server

389ds-server

Diese Rolle installiert den 389DS-Server (LDAP-Server) auf der Zielmaschine.

ansible-galaxy install lvps.389ds_server

Funktionen

Installiere einen einzelnen LDAP-Server
Konfiguriere Logging
Füge benutzerdefinierte Schema-Dateien hinzu
Aktiviere/deaktiviere beliebige Plugins
Konfiguriere das DNA-Plugin für UID/GID-Nummern
Konfiguriere TLS
Erzwinge TLS (minimale SSF und sichere Bindungen erforderlich) oder gehe zurück zu optionalem TLS
Aktiviere/deaktiviere LDAPI
Aktiviere/deaktiviere SASL PLAIN

Die Replikation wird mit einer anderen Rolle verwaltet.

Anforderungen

Ansible 2.10 oder neuer; für Ansible 2.8 und 2.9 benutze die 3.1.x-Versionen dieser Rolle
SUSE (OpenSUSE oder SLES) oder CentOS 7, CentOS 8, CentOS 9 oder andere RHEL-basierte Betriebssysteme

Rollen-Variablen

Die Variablen, die dieser Rolle übergeben werden können, sowie eine kurze Beschreibung sind wie folgt.

dirsrv_product

Standard: vom Betriebssystem abhängig · Kann geändert werden: Nein

Es gibt zwei Hauptzweige. Den kostenlosen 389 Directory Server und den unterstützten Red Hat Directory Server. Bei den kostenlosen Versionen kannst du auf die Standardwerte vertrauen. Andernfalls kannst du diesen Wert nach deinen Bedürfnissen konfigurieren. Momentan ist der einzige getestete nicht-standardmäßige Wert '@redhat-ds:11' für den Red Hat Directory Server 11, der in Red Hat EL8 verfügbar ist.

dirsrv_port

Standard: 389 · Kann geändert werden: Nein

Der Port, an dem der 389ds lauscht.

dirsrv_suffix

Standard: dc=example,dc=com · Kann geändert werden: Nein

Suffix des DIT. Alle Einträge im Server werden unter diesem Suffix abgelegt. Normalerweise besteht es aus den Domain-Komponenten (dc) deiner Hauptdomain. Zum Beispiel, wenn du von example.co.uk bist und der Server unter ldap-server.example.co.uk läuft, setze den Suffix auf dc=example,dc=co,dc=uk und lasse den Subdomain-Teil (ldap-server) weg, da er irrelevant ist.

dirsrv_bename

Standard: userRoot · Kann geändert werden: Nein

Interner Datenbankname des Suffix.

dirsrv_othersuffixes

Standard: [] · Kann geändert werden: Nein

Liste der anderen Suffix-Dikts in der Form { name: <bename>, dn: <rootDN>}

dirsrv_rootdn

Standard: cn=Directory Manager · Kann geändert werden: Nein

Root DN oder "Administrator"-Kontoname. Binde mit diesem DN, um alle Autorisierungskontrollen zu umgehen.

dirsrv_rootdn_password

Kann geändert werden: Nein

Passwort für den Root DN; du musst diese Variable definieren, oder die Rolle schlägt fehl.

dirsrv_fqdn

Standard: {{ansible_nodename}} · Kann geändert werden: Nein

Server FQDN, z.B. ldap.example.com. Wenn der Server-Hostname bereits ein FQDN ist, sollte der Standardwert automatisch übernommen werden.

dirsrv_serverid

Standard: default · Kann geändert werden: ¹

Server-ID oder Instanz-ID. Alle mit dieser Rolle verbundenen Daten werden in /etc/dirsrv/slapd-default, /var/log/dirsrv/slapd-default, usw. abgelegt. Du könntest deinen Firmennamen verwenden, z.B. für Foo Bar, Inc setze die Variable auf foobar und die Verzeichnisse werden slapd-foobar genannt.

dirsrv_listen_host

Kann geändert werden: Ja

Höre auf diesen Adressen/Hostnamen. Wenn nicht gesetzt (Standard), passiert nichts. Wenn auf einen String gesetzt, wird das Attribut nsslapd-listenhost gesetzt. Auf [] setzen, um das Attribut zu löschen.

dirsrv_secure_listen_host

Kann geändert werden: Ja

Dasselbe wie dirsrv_listen_host, jedoch für LDAPS. Wenn nicht gesetzt (Standard), passiert nichts. Wenn auf einen String gesetzt, wird das Attribut nsslapd-securelistenhost gesetzt. Auf [] setzen, um das Attribut zu löschen.

dirsrv_server_uri

Standard: ldap://localhost · Kann geändert werden: ¹

Server-URI für Aufgaben, die über LDAP verbinden. Da die Aufgaben auf demselben Server wie 389DS ausgeführt werden, wird dies in den meisten Fällen localhost sein, keine Anpassung erforderlich.

dirsrv_factory

Standard: false · Kann geändert werden: Ja

Behalte die werkseitigen Standardwerte zu Authentifizierungs- und Logging-Parametern. Wenn true, werden dirsrv_logging, dirsrv_simple_auth_enabled, dirsrv_password_storage_scheme, dirsrv_ldapi_enabled, dirsrv_sasl_plain_enabled vollständig ignoriert.

dirsrv_install_examples

Standard: false · Kann geändert werden: Nein

Erstelle Beispiel-Einträge unter dem Suffix während der Installation.

dirsrv_install_additional_ldif

Standard: [] · Kann geändert werden: Nein

Installiere diese zusätzlichen LDIF-Dateien, standardmäßig keine (leeres Array). Dies entspricht der Direktive InstallLdifFile in der Installationsdatei für 389DS <= 1.3. Ab Version 1.4 erfolgt dies über dsconf.

dirsrv_ldif_files_remote

Standard: false - kann geändert werden: Ja

Die ldif-Dateien befinden sich auf dem Remote-Server, nicht auf dem Ansible-Controller.

dirsrv_install_additional_ldif_dir

Standard: /var/lib/dirsrv/slapd-{{ dirsrv_serverid }}/ldif · Kann geändert werden: Nein

Verzeichnis, in dem LDIF-Dateien für dirsrv_install_additional_ldif vorübergehend gespeichert werden. Kann nicht /tmp sein, da der 389DS-Dienst von CentOS/RHEL 8.3 auf systemd PrivateTmp gesetzt ist.

dirsrv_logging

Standard: siehe unten · Kann geändert werden: Ja

Siehe unten

dirsrv_plugins_enabled

Standard: {} · Kann geändert werden: Ja

Aktiviere oder deaktiviere Plugins, siehe unten für Details. Standardmäßig sind keine Plugins aktiviert oder deaktiviert.

dirsrv_dna_plugin

Standard: siehe unten · Kann geändert werden: Ja

Konfiguration für das DNA (Distributed Numeric Assignment) Plugin.

dirsrv_custom_schema

Standard: [] · Kann geändert werden: Ja

Pfade zu benutzerdefinierten Schema-Dateien. Diese werden in /etc/dirsrv/slapd-{{ dirsrv_serverid }}/schema abgelegt, und ein Schema-Reload wird angefordert, wenn sich etwas ändert.

dirsrv_allow_other_schema_files

Standard: false · Kann geändert werden: Ja

Wenn false (Standardwert), wird diese Rolle die angegebenen Schema-Dateien zu /etc/dirsrv/slapd-{{ dirsrv_serverid }}/schema hinzufügen und dann alle anderen Schema-Dateien dort bis auf 99user.ldif löschen. Wenn deine Schema-Dateien nur von dieser Rolle oder dynamisch verwaltet werden (d.h. von cn=schema, das in 99user.ldif schreibt), kannst du diese Variable auf false belassen. Wenn du mehr Schema-Dateien in diesem Verzeichnis hast (manuell hinzugefügt oder durch andere Aufgaben), setze dies auf true, um sie dort zu belassen. Der Nachteil ist, dass, wenn du z.B. 50example.ldif bereitstellst, es dann in 50my_example.ldif umbenennst, die Rolle beim nächsten Lauf es als neue Datei betrachtet und die vorherige dort lässt, was dein Verzeichnis durcheinander bringen kann.

dirsrv_tls_enabled

Standard: false · Kann geändert werden: Ja

Aktiviere TLS (LDAPS und StartTTLS). Alle "dirsrv_tls"-Variablen haben nur dann Wirkung, wenn dies aktiviert ist.

dirsrv_tls_min_version

Standard: '1.2' · Kann geändert werden: Ja

Minimale TLS-Version: 1.0, 1.1 oder 1.2. Möglicherweise sogar 1.3, wenn von deiner 389DS-Version unterstützt. SSLv2 und SSLv3 sind durch diese Rolle immer deaktiviert.

dirsrv_tls_certificate_trusted

Standard: true · Kann geändert werden: Ja

Das Serverzertifikat ist öffentlich vertrauenswürdig. Setze es auf false nur in der Entwicklung (für selbstsignierte Zertifikate)!

dirsrv_tls_enforced

Standard: false · Kann geändert werden: Ja

Erzwinge TLS, indem du sichere Bindungen und minimale SSF verlangst.

dirsrv_tls_minssf

Standard: 256 · Kann geändert werden: Ja

Minimale SSF, die nur angewendet wird, wenn dirsrv_tls_enforced auf true gesetzt ist. 128 scheint angemessen, 256 sollte sehr sicher sein. Setze dies auf 0, um TLS nur mit sicheren Bindungen durchzusetzen.

dirsrv_allow_anonymous_binds

Standard: 'rootdse' · Kann geändert werden: Ja

Erlaube anonyme Bindungen: boolean true für Ja, boolean false für Nein oder 'rootdse'. Die Administrationsanleitung empfiehlt, rootdse anstelle von Nein zu verwenden, da dies anonyme Bindungen erlaubt, um einige Daten zu durchsuchen, die Clients möglicherweise benötigen, bevor sie eine Bindung durchführen. Anonyme Bindungen zuzulassen macht dein Verzeichnis im Wesentlichen öffentlich, es sei denn, du schränkst den Zugriff mit ACIs ein.

dirsrv_simple_auth_enabled

Standard: true · Kann geändert werden: Ja

Aktiviere die einfache Authentifizierung, wahrscheinlich true, es sei denn, du möchtest nur SASL PLAIN verwenden oder andere Methoden manuell konfigurieren.

dirsrv_password_storage_scheme

Standard: [] · Kann geändert werden: Ja

Ein einzelner Wert, möglicherweise der String "PBKDF2_SHA256". Oder lass den Standardwert, der einen benutzerdefinierten Wert löscht und den Standardwert von 389DS verwendet, der ziemlich sicher sein sollte.

dirsrv_ldapi_enabled

Standard: false · Kann geändert werden: Ja

Aktiviere LDAPI (verbinde dich mit dem Server über einen UNIX-Socket bei ldapi:///var/run/dirsrv/slapd-{{ dirsrv_serverid }}.socket). Hinweis: Dies unterliegt der TLS-Durchsetzung und TLS wird nicht unterstützt, daher ist es nutzlos, wenn du dirsrv_tls_enforced auf true gesetzt hast.

dirsrv_sasl_plain_enabled

Standard: true · Kann geändert werden: Ja

Aktiviere die SASL PLAIN-Authentifizierung: wenn ein Client versucht, sich ohne TLS zu authentifizieren und TLS durchgesetzt wird, sollte diese Art der Authentifizierung dies stoppen, bevor das Klartextpasswort gesendet wird, während eine einfache Bindung das Passwort sendet und dann fehlschlägt, weil SSF zu niedrig ist.

Variablen exklusiv für 389DS-Version 1.4.X

Diese Variablen betreffen nur Installationen der 389DS-Version 1.4.X und haben keinen Einfluss auf frühere Versionen, selbst wenn sie definiert sind.

dirsrv_defaults_version

Standard: 999999999² · Kann geändert werden: Nein

Die Standardkonfigurationswerte sind die für die angegebene Version von 389DS. Das Format ist XXXYYYZZZ, wobei XXX die Hauptversion, YYY die Nebenversion und ZZZ die Patchstufe ist (alle drei Werte werden auf die Länge von drei mit Nullen aufgefüllt). Wenn 999999999 ausgewählt ist, werden die neuesten Standardwerte verwendet.

dirsrv_selfsigned_cert

Standard: True² · Kann geändert werden: Nein

Bestimmt, ob 389DS ein selbstsigniertes Zertifikat generiert und TLS automatisch aktiviert.

dirsrv_selfsigned_cert_duration

Standard: 24² · Kann geändert werden: Nein

Gültigkeit in Monaten für das selbstsignierte Zertifikat, das von 389DS generiert wird.

dirsrv_create_suffix_entry

Standard: False² · Kann geändert werden: Nein

Bestimmt, ob 389DS einen Suffixeintrag im Verzeichnis mit dem gegebenen Suffix generiert: cn={{ dirsrv_suffix }}

dirsrv_rundir

Kann geändert werden: Nein

Wenn definiert, konfiguriere einen bestimmten Pfad für db_home_dir.

dirsrv_rundir

Kann geändert werden: Nein

Wenn definiert, konfiguriert es einen bestimmten Pfad für run_dir.

Interoperabilität zwischen 1.3.X und 1.4.X

Um ein Playbook zu haben, das sich in den Versionen 1.3 und 1.4 von 389DS gleich verhält, sollten die folgenden Werte verwendet werden:

Variable	Wert
dirsrv_defaults_version	001004002³
dirsrv_selfsigned_cert	False
dirsrv_create_suffix_entry	True

Hinweise

Einige Variablen können von dieser Rolle (oder überhaupt) nicht geändert werden, nachdem eine Instanz von 389DS erstellt wurde. Wenn eine von ihnen geändert wird und die Rolle erneut angewendet wird, kann das undefiniertes Verhalten auftreten, das von "nichts" bis "die Rolle schlägt fehl" reicht. Einige von ihnen, z.B. das Passwort des Root DN, können manuell geändert werden: bitte beziehe dich auf die Administrationsanleitung für weitere Details.

¹ Wenn du diese Variable von einem vorherigen Lauf änderst, führt dies zur Erstellung einer anderen Instanz, die ein völlig separates Verzeichnis vom vorherigen darstellt, was in Ordnung sein sollte, wenn das dein Ziel ist.

² Dies sind die Standardwerte der 389DS-Version 1.4.2.15 und können sich in späteren Versionen ändern: führe dscreate create-template auf deinem Rechner aus, um die Standardwerte für die aktuelle Version zu sehen.

³ Dies ist die Versionsnummer der Standards, auf denen diese Rolle geschrieben und validiert wurde. Die Einstellung von dirsrv_defaults_version ist technisch nicht erforderlich, kann jedoch zukünftige Aktualisierungen der Standards verhindern, die das Playbook brechen, indem sie nicht mit 389DS 1.3 kompatibel sind. Andererseits wird die Einstellung der Variablen die Konfiguration zeitlich festlegen und wenn dies über einen längeren Zeitraum geschieht, könnte sie veraltet sein. Mit Bedacht verwenden.

Alle Variablen sind mit dirsrv vorangestellt, da das Beginnen eines Variablennamens mit einer Zahl ("389ds") nicht so gut funktioniert.

dirsrv_logging

Dies ist die Standardvariable:

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 verbindet standardmäßig keine Dictionaries. d.h. wenn du nur audit > enabled auf true setzen möchtest, musst du alle anderen Variablen ebenfalls definieren. Wenn du die Standards ändern möchtest, ist es wahrscheinlich eine gute Idee, diesen gesamten Block in die Variablen zu kopieren und die erforderlichen Anpassungen vorzunehmen.

dirsrv_plugins_enabled

Wenn du das MemberOf-Plugin aktivieren möchtest, das sich unter cn=MemberOf Plugin,cn=plugins,cn=config befindet, setze die Variable auf:

dirsrv_plugins_enabled:
  MemberOf Plugin: true

Wenn es aktiviert ist und du es deaktivieren möchtest, setze es auf:

dirsrv_plugins_enabled:
  MemberOf Plugin: false

Wenn du mehr Plugins aktivieren möchtest:

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

Wenn ein Plugin nicht in der Liste erschienen ist, bleibt es in seinem aktuellen Status.

Ein Plugin namens Foo sollte einen Eintrag unter cn=Foo,cn=plugins,cn=config haben. Du kannst den Baum cn=plugins,cn=config durchsehen, um zu sehen, welche Plugins verfügbar sind und welchen Status sie haben.

dirsrv_dna_plugin

Standardwert:

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

Ansible kombiniert standardmäßig keine Dictionaries. d.h. wenn du nur uid_max und gid_max ändern möchtest, musst du auch die _min-Variablen definieren. Wenn du dirsrv_dna_plugin definierst, ersetzt es diesen Standard-Dictionary vollständig.

Diese Konfiguration wird nur angewendet, wenn "Distributed Numeric Assignment Plugin" in dirsrv_plugins_enabled auf true gesetzt ist und wird entfernt, wenn es false ist. Wenn es nicht erwähnt wird, passiert nichts.

dirsrv_replica_role muss definiert sein, um DNA mit Replikation zu konfigurieren. Diese Variable wird auch in der Rolle lvps/389ds-replication definiert, also sieh dir diese für die Dokumentation an. Für diese Rolle ist es ausreichend, wenn sie definiert ist, wenn du Replikation verwendest, der Wert spielt keine Rolle.

Abhängigkeiten

Keine.

Verwendung und Beispiele

Minimales funktionierendes Beispiel

- name: Ein Beispiel-Playbook
  hosts: example
  roles:
    - role: lvps.389ds_server
      dirsrv_rootdn_password: secret

Binde mit DN cn=Directory Manager und Passwort secret am Port 389, der Suffix wird dc=example,dc=local sein, alles andere ist größtenteils wie bei einer frischen 389DS-Installation.

Ansible Vault wäre eine gute Idee, um das Root-DN-Passwort im Klartext in der Produktion zu vermeiden.

Firewall konfigurieren

Nicht Teil dieser Rolle, aber du musst möglicherweise den LDAP-Port (389) öffnen, um remote auf den Server zuzugreifen:

- name: Erlaube LDAP-Port bei Firewalld
  firewalld: service=ldap permanent=true state=enabled

Das Gleiche könnte für den LDAPS-Port (636) erforderlich sein, wenn du TLS aktivierst und das anstelle von StartTLS verwenden möchtest.

Beispiel-Einträge und einige Anpassungen

- name: Ein Beispiel-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"

Binde mit DN cn=admin und Passwort secret am Port 389, schaue dir die Beispiel-Einträge an, die von 389DS bereitgestellt werden.

Audit-Logs sind ebenfalls aktiviert, und alle Logs werden 14 Tage lang aufbewahrt (oder bis sie zu groß werden).

Das MemberOf-Plugin ist ebenfalls aktiviert.

Sieh in das molecule-Verzeichnis für eine benutzerdefinierte Schema-Datei, die bekannt dafür ist, mit 389DS zu funktionieren, wenn du diesen Teil testen möchtest, aber keine gültige Schema-Datei hast. Lösche diesen Teil, um alle benutzerdefinierten Schema-Dateien zu entfernen. Das Schema-Reload wird automatisch durchgeführt.

TLS

- name: Ein Beispiel-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 # True, wenn die Dateien bereits auf dem Remote-Host sind (z.B. bereitgestellt von certbot)
      dirsrv_tls_certificate_trusted: true # Oder false, wenn selbstsigniert
      # Wenn du einfache LDAP-Verbindungen vermeiden und TLS durchsetzen möchtest, bedenke auch diese Einstellungen:
      dirsrv_tls_enforced: true
      dirsrv_tls_minssf: 256
      # Hat nichts mit TLS zu tun, aber zur Verbesserung der Sicherheit könntest du in Erwägung ziehen:
      dirsrv_password_storage_scheme: "PBKDF2_SHA256"
      # obwohl das standardmäßige Passwortspeicherschema bereits stark genug ist.

Hier findest du ein Skript zur Generierung selbstsignierter Zertifikate, die wiederholt mit 389DS getestet wurden. Oder sieh in das molecule-Verzeichnis für ein Beispielzertifikat und einen Schlüssel, die für Tests der Rolle verwendet werden.

Beachte jedoch, dass das Skript nur als Beispiel für Tests gedacht ist und nicht für den produktiven Einsatz empfohlen wird.

389DS wird automatisch neu gestartet, wenn es nötig ist, um die Konfiguration anzuwenden. Sowohl LDAPS (Port 636) als auch StartTLS (Port 389) sind aktiviert.

Wenn du es leid bist, eine sichere Verbindung zu haben, setze dirsrv_tls_enabled: false, aber das Zertifikat bleibt in der NSS-Datenbank von 389DS. Es kann manuell entfernt werden.

Zertifikat-Rollover (das Ersetzen des Zertifikats und des Schlüssels durch einen neuen, z.B. weil die alten abgelaufen sind) scheint sowohl mit selbstsignierten als auch mit Let's Encrypt-Zertifikaten zu funktionieren, aber der Prozess ist nach wie vor sehr kompliziert und voller Hacks und Workarounds. Wenn du dies in der Produktion verwenden möchtest, ist es ratsam, die relevanten Teile von Abschnitt 9.3 der Administrationsanleitung und die Kommentare in tasks/configure_tls.yml zu lesen, um zu verstehen, was passiert und warum.

TLS mit Let's Encrypt (oder anderen ACME-Anbietern)

Der entscheidende Punkt ist, dass du die "Fullchain" (Server-Zertifikat und alle Zwischenzertifikate, kein Root-Zertifikat) in die 389ds-server-Rolle speisen musst. Da ich nicht viele andere Beispiele zur http-01-Challenge mit acme_certificate finden konnte, habe ich es hier hinzugefügt, um dir eine bessere Vorstellung von allen notwendigen Schritten zu geben.

- name: Ein Beispiel-Playbook
  hosts: example
  pre_tasks:
    - name: Stelle sicher, dass das ACME-Konto existiert
      acme_account:
        # acme_directory: "http://..."  # Dein Anbieter. Lass dies weg, um das Let's Encrypt-Staging-Verzeichnis zu nutzen
        account_key_content: "{{ acme_account_key }}"  # "openssl genrsa 2048" zum Generieren, aber lies https://docs.ansible.com/ansible/latest/modules/acme_account_module.html für aktuellere Informationen
        acme_version: 2
        state: present
        terms_agreed: true
        contact:
          - mailto:[email protected]

    # Du benötigst einen CSR (Zertifikatsanforderung) und einen privaten Schlüssel.
    # Verwende *nicht* den Kontoschlüssel, erstelle einen neuen!
    # Generiere sie:
    #
    # 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"
    #
    # Nur die Domain ist wichtig. Sowohl example.key als auch dein Kontoschlüssel sollten geheim gehalten werden,
    # du könntest sie in Ansible Vault platzieren und eine Vorlage nutzen, um example.key aus der Variablen zu erstellen.
    - name: Kopiere CSR und privaten Schlüssel
      copy:
        src: "{{ item }}"
        dest: "/etc/some/secret/directory"
        owner: root
        group: root
        mode: "400"  # Der CSR könnte weltweit lesbar sein, tatsächlich war er nicht geheim
        setype: cert_t
      loop:
        - "path/to/your/example.csr"
        - "path/to/your/example.key"

    - name: Erstelle Herausforderung
      acme_certificate:
        acme_directory: "http://..."
        account_key_content: "{{ acme_account_key }}"
        acme_version: 2
        challenge: "http-01"
        # Du benötigst die fullchain (die dein Zertifikat und alle
        # Zwischenzertifikate enthält, aber kein Root-Zertifikat). Dies wird in
        # NSS/389DS eingespeist, die alle bedienen sollte.
        fullchain: "/etc/some/secret/directory/example.fullchain.pem"
        csr: "/etc/some/secret/directory/example.csr"
        # remaining_days: 10
      register: acme_challenge

    # Du benötigst einen laufenden HTTP-Server. Stelle dir vor, es gibt eine NGINX-Instanz,
    # die Seiten auf example.com aus /var/www/html/example.com bedient
    # Wenn du feststellst, dass ein immer laufender HTTP-Server stört, kann "when: acme_challenge is changed"
    # verwendet werden, um ihn für die Herausforderung zu starten und am Ende zu stoppen...
    #
    # Du brauchst auch ein paar Verzeichnisse, sonst schlägt die nächste Aufgabe fehl, weil sie
    # nicht existieren...
    - name: Erstelle HTTP-Verzeichnisse für die ACME http-01-Herausforderung
      file:
        name: "{{ item }}"
        state: directory
        owner: root
        group: root
        # Diese sollten nicht geheim sein (sie sind über das Internet zugänglich),
        # mach sie einfach nicht schreibbar für jedermann
        mode: "755"
        setype: httpd_sys_content_t  # Nur lesen
      loop:
        - "/var/www/html/example.com"
        - "/var/www/html/example.com/.well-known"
        - "/var/www/html/example.com/.well-known/acme-challenge"

    - name: Erfülle die http-01-Herausforderung
      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

    # Dasselbe wie die vorherige acme_certificate-Aufgabe, nur "data" hinzufügen
    - name: Mache Herausforderung
      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

    # Nicht optimal (für einen kurzen Moment, bevor dies geschieht, hat das Zertifikat die
    # falschen Berechtigungen)
    # Es könnte möglich sein, diese Aufgabe auf "state: touch" zu setzen und sie vor
    # der vorherigen zu platzieren, obwohl.
    - name: Stelle sicher, dass die Berechtigungen für das Beispiel-Zertifikat korrekt sind
      file:
        state: file
        path: "/etc/some/secret/directory/example.fullchain.pem"
        owner: root
        group: root
        mode: "400"
        setype: cert_t

  # In diesem Beispiel habe ich fast keine Variablen verwendet, um größere Klarheit zu schaffen
  # (d.h. du siehst, wie diese Strings aussehen sollten, anstatt einen willkürlich erfundenen
  # Namen, den ich gewählt habe), aber in einem realen Playbook kann es besser sein,
  # einige Variablen zu verwenden.

  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  # Beide Dateien befinden sich auf dem Server
      dirsrv_tls_certificate_trusted: true  # Keine Notwendigkeit, die Zertifikatsprüfungen zu deaktivieren, juchhu!

Da Zertifikat-Rollover von dieser Rolle unterstützt wird, musst du nur dieses Playbook regelmäßig ausführen, um das Zertifikat zu aktualisieren, wenn es kurz davor ist, abzulaufen.

Was ist mit der Replikation?

Es gibt eine andere Rolle dafür.

Tests

Tests nutzen das docker systemctl replacement-Skript, das von gdraheim unter der EUPL-Lizenz erstellt und verteilt wurde. Dieses Skript wird heruntergeladen und in einen lokalen Container kopiert, um sicherzustellen, dass die Tests korrekt ausgeführt werden können. Diese Verteilung erfolgt unter denselben Lizenzen und Bedingungen, unter denen gdraheim sein Werk erstellt und veröffentlicht hat. Das Skript wird unverändert heruntergeladen und keine Änderungen daran vorgenommen. Durch das Ausführen der Tests auf ihren Maschinen erklärt sich der Endbenutzer bereit, das heruntergeladene Skript unter denselben Bedingungen zu behandeln, die von seinem Autor beabsichtigt sind. Beachte, dass die Tests selbst (und die Rolle insgesamt) weiterhin unter der Apache 2-Lizenz lizenziert sind.

Diese Rolle verwendet Molecule für ihre Tests. Installiere sie wahrscheinlich mit pip und teste alle Szenarien:

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

Oder um ein einzelnes Szenario zu testen: molecule test -s tls

Zukünftige Erweiterungen

Könnte gemacht werden, aber kurzfristig nicht geplant

Unterstützung für Debian/Ubuntu/FreeBSD oder andere Plattformen, die 389DS unterstützt
Unterstützung für andere Plugins, die mehr als nur aktiv oder inaktiv benötigen
Unterstützung für andere DNA-Attribute

Lizenz

Apache 2.0 für die Rolle und die zugehörigen Tests
EUPL v 1.2 für das "docker systemctl replacement"-Skript von gdraheim (nicht enthalten, aber beim Ausführen von Tests heruntergeladen)

Autorinformationen

Betreuer: Ludovico Pavesi
Mitwirkender/originaler Autor: Colby Prior
Mitwirkender/originaler Autor: Artemii Kropachev
Danke an Firstyear für die Kommentare

Über das Projekt

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

Installieren

ansible-galaxy install lvps.389ds_server

GitHub Repository

25 Sterne

17 Forks

5 Offene Issues

Lizenz

apache-2.0

Downloads

80.6k

Besitzer

lvps

389ds-server

Funktionen

Anforderungen

Rollen-Variablen

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

Variablen exklusiv für 389DS-Version 1.4.X

dirsrv_defaults_version

dirsrv_selfsigned_cert

dirsrv_selfsigned_cert_duration

dirsrv_create_suffix_entry

dirsrv_rundir

dirsrv_rundir

Interoperabilität zwischen 1.3.X und 1.4.X

Hinweise

dirsrv_logging

dirsrv_plugins_enabled

dirsrv_dna_plugin

Tags

Abhängigkeiten

Verwendung und Beispiele

Minimales funktionierendes Beispiel

Firewall konfigurieren

Beispiel-Einträge und einige Anpassungen

TLS

TLS mit Let's Encrypt (oder anderen ACME-Anbietern)

Was ist mit der Replikation?

Tests

Zukünftige Erweiterungen

Könnte gemacht werden, aber kurzfristig nicht geplant

Lizenz

Autorinformationen

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