// Diese Datei wird von .github/workflows/gh-pages.yml generiert - alle lokalen Änderungen gehen irgendwann verloren! = ansible-role-apache2 Jonas Pammer opensource@jonaspammer.at; :toc: left :toclevels: 2 :toc-placement!: :source-highlighter: rouge

https://galaxy.ansible.com/jonaspammer/apache2[image:https://img.shields.io/badge/available%20on%20ansible%20galaxy-jonaspammer.apache2-brightgreen[Version auf Galaxy]] // Sehr wichtige Status-Abzeichen https://github.com/JonasPammer/ansible-role-apache2/actions/workflows/ci.yml[image:https://github.com/JonasPammer/ansible-role-apache2/actions/workflows/ci.yml/badge.svg[Testing CI]]

Eine Ansible-Rolle zur Installation von Apache2, Aktivierung/Deaktivierung von Modulen, Konfiguration der Standardwerte und Erstellung von virtuellen Hosts.

toc::[]

[[meta]] == 🔎 Metadaten Hier finden Sie Informationen zu…

• der erforderlichen Ansible-Version für die Rolle
• den unterstützten Plattformen der Rolle
• den https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html#role-dependencies[Rollenabhängigkeiten]

.link:meta/main.yml[] [source,yaml]

galaxy_info: role_name: "apache2" description: "Eine Ansible-Rolle zur Installation von Apache2, Aktivierung/Deaktivierung von Modulen, Konfiguration der Standardwerte und Erstellung von virtuellen Hosts. Basierend auf der Apache2-Rolle von geerlingguy."

author: "jonaspammer" license: "MIT"

min_ansible_version: "2.11" platforms: - name: EL # (Enterprise Linux) versions: - "9" # aktiv getestet: rockylinux9 - name: Fedora versions: - "38" # aktiv getestet: fedora38 - "39" # aktiv getestet: fedora39 - name: Debian versions: - bullseye # aktiv getestet: debian11 - bookworm # aktiv getestet: debian12 - name: Ubuntu versions: - focal # aktiv getestet: ubuntu2004 - jammy # aktiv getestet: ubuntu2204

galaxy_tags: - web - apache - webserver - html - httpd

dependencies: []

allow_duplicates: true

[[requirements]] == 📌 Anforderungen // Alle Voraussetzungen, die möglicherweise nicht von dieser Rolle oder Ansible selbst abgedeckt sind, sollten hier erwähnt werden. Der Ansible-Benutzer muss in der Lage sein, become auszuführen.

Wenn Sie SSL/TLS verwenden (<>), müssen Sie Ihre eigenen Zertifikats- und Schlüsseldateien bereitstellen.

Wenn Sie Apache mit PHP verwenden, empfehle ich die Verwendung der https://github.com/geerlingguy/ansible-role-php/[geerlingguy.php] Rolle zum Installieren von PHP. Sie können entweder mod_php verwenden (indem Sie das entsprechende Paket hinzufügen, z.B. libapache2-mod-php5 für Ubuntu, zu php_packages), oder zusätzlich die https://github.com/geerlingguy/ansible-role-apache-php-fpm[`geerlingguy.apache-php-fpm` ] verwendet, um Apache über FPM mit PHP zu verbinden. Bitte konsultieren Sie die READMEs der verlinkten Rollen für spezifischere Informationen.

Wenn Sie Solaris-basierte Systeme anvisieren, muss die https://galaxy.ansible.com/community/general[`community.general` Sammlung] (enthält das Modul pkg5) auf dem Ansible-Controller installiert sein.

Wenn Sie Suse-basierte Systeme anvisieren, muss die https://galaxy.ansible.com/community/general[`community.general` Sammlung] (enthält das Modul zypper) auf dem Ansible-Controller installiert sein.

[[variables]] == 📜 Rollenvariablen // Eine Beschreibung der einstellbaren Variablen für diese Rolle sollte hier stehen // und alle Variablen, die über Parameter an die Rolle gesetzt werden können/sollten. // Alle Variablen, die aus anderen Rollen und/oder dem globalen Kontext (d.h. hostvars, group vars usw.) // gelesen werden, sollten hier ebenfalls erwähnt werden.

[source,yaml]

apache_mods_enabled:

• rewrite
• ssl apache_mods_disabled: []

(Nur Debian/RHEL) Apache-Module, die aktiviert oder deaktiviert werden sollen (diese werden an die entsprechende Stelle verlinkt). Überprüfen Sie das Verzeichnis mods-available (Debian) / conf.modules.d (RHEL) innerhalb von <<apache__server_root_dir, dem Stammverzeichnis von Apache>> für alle verfügbaren Module.

[source,yaml]

apache_listen_ip: "*" apache_listen_port: 80 apache_listen_port_ssl: 443

Die IP-Adresse und Ports, auf denen Apache hören soll. Nützlich, wenn Sie einen anderen Dienst (wie einen Reverse-Proxy) haben, der auf Port 80 oder 443 hört und die Standardeinstellungen geändert werden müssen.

[source,yaml]

apache_remove_default_vhost: false

Auf Debian/Ubuntu ist ein Standard-virtueller Host in der Apache-Konfiguration enthalten. Setzen Sie dies auf true, um den Standard zu entfernen.

[source,yaml]

apache_state: started

Setzt den ursprünglichen Zustand von Apache. Empfohlene Werte: started oder stopped

[source,yaml]

apache_enabled: true

Setzt den ursprünglichen Status des Apache-Dienstes. Empfohlene Werte: true oder false

[source,yaml]

apache_restart_state: restarted

Setzt den Zustand, den Apache annehmen soll, wenn eine Konfigurationsänderung vorgenommen wurde (d.h. wenn der Handler restart apache aufgerufen wurde). Empfohlene Werte: restarted oder reloaded

[[apache_default_favicon]] [source,yaml]

apache_default_favicon: favicon.ico

Pfad zu einer Datei auf dem lokalen Ansible-Controller, die auf den Server kopiert und von Apache als Standard-Favicon verwendet wird.

=== Rollenvariablen für die Installation

[source,yaml]

apache_packages: [OS-spezifisch standardmäßig, siehe /defaults-Verzeichnis]

Eine Liste von Paketnamen für die Installation von Apache2 und den wichtigsten Hilfsprogrammen.

[source,yaml]

apache_packages_state: present

Wenn Sie zusätzliche Repositories aktiviert haben, wie zum Beispiel https://launchpad.net/~ondrej/+archive/ubuntu/apache2[`ondrej/apache2`], https://fedoraproject.org/wiki/EPEL[`EPEL`] oder http://rpms.remirepo.net/[`remi`], möchten Sie vielleicht eine einfache Möglichkeit, Versionen zu aktualisieren. Um dies zu gewährleisten, setzen Sie dies auf latest.

[source,yaml]

apache_enablerepo: ""

(Nur RHEL/CentOS) Das https://docs.ansible.com/ansible/latest/collections/ansible/builtin/yum_module.html#parameter-enablerepo[Repository] zum Installieren von Apache. Wenn Sie spätere Versionen von Apache als die in den Kern-Repositories des Betriebssystems verfügbaren wünschen, verwenden Sie ein Repository wie https://fedoraproject.org/wiki/EPEL[EPEL] (das mit der Rolle repo-epel installiert werden kann).

=== Rollenvariablen zur Erstellung virtueller Hosts

[TIPP] Schauen Sie im Abschnitt <> vorbei für Beispiele, wie die erzeugte VirtualHost-Datei aussehen kann.

[HINWEIS]

Diese Rolle versucht, eine funktionierende Apache-Konfiguration sicherzustellen, indem sie https://httpd.apache.org/docs/2.4/programs/httpd.html[Syntaxprüfungen für alle Konfigurationsdateien (-t)] ausführt und den erzeugten virtuellen Host zurücksetzt, wenn ein Fehler aufgetreten ist. ====

[source,yaml]

apache_create_vhosts: true apache_vhosts_filename: "vhosts.conf" apache_vhosts_template: "vhosts.conf.j2"

Wenn auf true gesetzt, wird eine vhosts-Datei erstellt, die von den Variablen dieser Rolle verwaltet wird und im Apache-Konfigurationsordner abgelegt wird. Wenn auf false gesetzt, können Sie Ihre eigene vhosts-Datei in den Konfigurationsordner von Apache legen und die bequemere (aber einfachere) ignorieren, die von dieser Rolle hinzugefügt wurde.

Sie können auch die verwendete Vorlage überschreiben und einen Pfad zu Ihrer eigenen Vorlage angeben, wenn Sie das Layout Ihres VirtualHosts weiter anpassen müssen.

[source,yaml]

apache_global_vhost_settings: | DirectoryIndex index.php index.html

Diese Variable wird außerhalb einer -Direktive in der generierten VirtualHost-Datei verwendet.

[WARNUNG]

Sie ändern hiermit die Einstellungen, die für den allgemeinen Kontext von Apache angewendet werden, anstatt die spezifischen Einstellungen für beispielsweise einen <VirtualHost>/ <Directory> usw. zu ändern.

Eine Sache, die bei diesem Standardwert zu beachten ist, ist, dass der DirectoryIndex nicht setzt, sondern eher hinzufügt (Was bedeutet, dass wir keine anderen vorgenommenen Konfigurationen umkehren), wie auf seiner Dokumentationsseite angegeben:

[Zitat,https://httpd.apache.org/docs/2.4/mod/mod_dir.html]

Mehrere DirectoryIndex-Direktiven im gleichen Kontext fügen die Liste von Ressourcen hinzu, nach denen gesucht werden soll, anstatt sie zu ersetzen.

=====

[source,yaml]

apache_vhosts:

• servername: "local.dev" documentroot: "/var/www/html"

Für jeden Eintrag in dieser Liste wird eine <VirtualHost>-Direktive erzeugt, die auf {{ apache_listen_ip }}:{{ apache_listen_port }} hört.

Jeder Listeneintrag kann die folgenden Eigenschaften haben (Überprüfen Sie den Abschnitt <> für Beispiele. Konsultieren Sie die verlinkten offiziellen Dokumentationsseiten für die Dokumentation der tatsächlichen Apache-Direktiven, die sie darstellen).

https://httpd.apache.org/docs/2.4/mod/core.html#servername[servername] (erforderlich)::

https://httpd.apache.org/docs/2.4/mod/core.html#serveralias[serveralias]::

https://httpd.apache.org/docs/2.4/mod/core.html#serveradmin[serveradmin]::

https://httpd.apache.org/docs/2.4/mod/core.html#documentroot[documentroot]::

documentroot__link:https://httpd.apache.org/docs/2.4/mod/core.html#servername[allowoverride]:: AllowOverride-Direktive, die innerhalb der <Directory> des DocumentRoot verwendet wird. + Standardmäßig auf den Wert von apache_vhosts_default_documentroot__allowoverride gesetzt.

documentroot__link:https://httpd.apache.org/docs/2.4/mod/core.html#options[options]:: Options-Direktive, die innerhalb der <Directory> des DocumentRoot verwendet wird. + Standardmäßig auf den Wert von apache_vhosts_default_documentroot__options gesetzt.

https://httpd.apache.org/docs/2.4/mod/mod_log_config.html#logformat[`logformat`]::

https://httpd.apache.org/docs/2.4/mod/core.html#loglevel[loglevel]::

[[apache_vhosts__errorlog]] https://httpd.apache.org/docs/2.4/mod/core.html#errorlog[errorlog]:: Entweder eine Zeichenfolge (die den Pfad repräsentiert, wird nicht automatisch in Anführungszeichen gesetzt) oder ein komplexer Datentyp: + ==== path:: Pfad. Wird in " eingeschlossen.

extra:: Zusätzliche Zeichenfolge, die nach path angehängt wird.

extra_parameters:: Diese Variable wird so eingefügt, vor der eigentlichen ErrorLog-Anweisung (mit einem Einrückung von 2). + Der Anwendungsfall für diesen Parameter kann darin bestehen, bedingte Protokolle mit SetEnvIf / SetEnv zu aktivieren oder ein benutzerdefiniertes LogFormat für dieses ErrorLog https://httpd.apache.org/docs/2.4/logs.html[Apache-Dokumentation]. ====

[[apache_vhosts__customlogs]] https://httpd.apache.org/docs/2.4/mod/mod_log_config.html#customlog[customlogs]:: Array von CustomLogs. Jeder Eintrag kann entweder eine Zeichenfolge sein (wird nicht automatisch in Anführungszeichen gesetzt) oder ein komplexer Datentyp: + ==== path:: Pfad. Wird in " eingeschlossen.

extra:: Zusätzliche Zeichenfolge, die nach path angehängt wird. Wird nicht in Anführungszeichen gesetzt (um den komplexen zusätzlichen optionalen Parametern von CustomLog gerecht zu werden, die man möglicherweise angeben möchte).

extra_parameters:: Diese Variable wird so eingefügt an das Ende der Schleife für <VirtualHost> (mit einer Einrückung von 2).

[[apache_vhosts_ssl]] [source,yaml]

apache_vhosts_ssl: []

Für jeden Eintrag in dieser Liste wird eine <VirtualHost>-Direktive erzeugt, die auf {{ apache_listen_ip }}:{{ apache_listen_port_ssl }} hört.

Jeder Eintrag einer Liste kann die folgenden Eigenschaften haben (Überprüfen Sie den Abschnitt <> für Beispiele) (Konsultieren Sie die verlinkten offiziellen Dokumentationsseiten für die Dokumentation der tatsächlichen Apache-Direktiven, die sie darstellen).

https://httpd.apache.org/docs/2.4/mod/core.html#servername[servername] (erforderlich)::

https://httpd.apache.org/docs/2.4/mod/core.html#serveralias[serveralias]::

https://httpd.apache.org/docs/2.4/mod/core.html#serveradmin[serveradmin]::

https://httpd.apache.org/docs/2.4/mod/core.html#documentroot[documentroot]::

documentroot__link:https://httpd.apache.org/docs/2.4/mod/core.html#servername[allowoverride]:: AllowOverride-Direktive, die innerhalb der <Directory> des DocumentRoot verwendet wird. + Standardmäßig auf apache_vhosts_default_documentroot__allowoverride gesetzt.

documentroot__link:https://httpd.apache.org/docs/2.4/mod/core.html#options[options]:: Options-Direktive, die innerhalb der <Directory> des DocumentRoot verwendet wird. Standardmäßig auf apache_vhosts_default_documentroot__options gesetzt.

no_actual_ssl:: Wenn auf True gesetzt, hat die <VirtualHost> keine SSL*-Optionen. Wird nur verwendet, wenn Sie eine http-zu-https-Umleitung benötigen, die Sie in extra_parameters definiert haben.

https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatefile[ssl_certificate_file] (erforderlich):: https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatekeyfile[ssl_certificate_key_file] (erforderlich):: https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatechainfile[ssl_certificate_chain_file]:: Bitte beachten Sie, dass dies veraltet ist.

https://httpd.apache.org/docs/2.4/mod/mod_log_config.html#logformat[`logformat`]::

https://httpd.apache.org/docs/2.4/mod/core.html#loglevel[loglevel]::

https://httpd.apache.org/docs/2.4/mod/core.html#errorlog[errorlog]:: Entsprechung von <<apache_vhosts__errorlog,apache_vhosts.errorlog>>.

https://httpd.apache.org/docs/2.4/mod/log_config.html#customlog[customlogs]:: Array von CustomLogs. Entsprechung von <<apache_vhosts__customlogs,apache_vhosts.customlogs>>.

extra_parameters:: Diese Variable wird so eingefügt an das Ende der Schleife für <VirtualHost> (mit einer Einrückung von 2).

[source,yaml]

apache_ignore_missing_ssl_certificate: true

Wenn auf false gesetzt, wird ein gegebener Eintrag von apache_vhosts_ssl nur erzeugt, wenn seine sslcertificatefile existiert.

[source,yaml]

apache_ssl_protocol: "All -SSLv2 -SSLv3" apache_ssl_cipher_suite: "AES256+EECDH:AES256+EDH"

Diese Variablen werden als Standard für jedes apache_vhosts_ssl verwendet. Sie sind denselben Namen wie in den genannten Rollenvariablen zugeordnet (ausgenommen dem Präfix natürlich). Siehe https://httpd.apache.org/docs/current/mod/mod_ssl.html[ Apache-Dokumentation] für die Dokumentation der tatsächlichen Apache-Direktiven, die sie darstellen.

[source,yaml]

apache_vhosts_default_documentroot__allowoverride: "All" apache_vhosts_default_documentroot__options: "-Indexes +FollowSymLinks"

[[public_vars]] == 📜 Fakten/Variablen, die von dieser Rolle definiert sind

Jede in diesem Abschnitt aufgeführte Variable wird dynamisch definiert, wenn diese Rolle ausgeführt wird (und kann nur mit ansible.builtin.set_facts überschrieben werden) und soll nicht nur intern verwendet werden.

[[apache__service]] .pass:[apache__service]

.Beispielverwendung außerhalb dieser Rolle: [source,yaml]

Handler-Datei für rollen.xyz

• name: apache2 neustarten ansible.builtin.service: name: "{{ apache__service | default('apache2') }}" state: restarted

[[apache__daemon]] .pass:[apache__daemon_dir], pass:[apache__daemon]

Ausführbarer Name und Verzeichnis des apache2-Befehls.

[[apache__server_root_dir]] .pass:[apache__server_root_dir]

Verzeichnis, das alle Apache2-Konfigurationen enthält (in /etc).

[[debian_is_different_note]] [HINWEIS] ==== Bei der Arbeit mit den unten stehenden Konfigurationswerten müssen Sie beachten:

[Zitat, Kommentar, der in der /etc/apache2/apache2.conf eines Debian 10 gefunden wurde]

Die Konfiguration des Apache 2 Webservers in Debian ist ziemlich anders als die empfohlene Vorgehensweise von oben zur Konfiguration des Webservers. Dies liegt daran, dass Debians Standardinstallation von Apache2 versucht, das Hinzufügen und Entfernen von Modulen, virtuellen Hosts und zusätzlichen Konfigurationsanweisungen so flexibel wie möglich zu gestalten, um die Automatisierung der Änderungen und die Verwaltung des Servers so einfach wie möglich zu gestalten.

Das bedeutet, dass pass:[apache__server_root_dir] auf Debian so aussieht:

.tree /etc/apache2 einer frischen Debian 10-Maschine nach der Installation von apache2

. ├── apache2.conf ├── conf-available │   ├── charset.conf │   ├── localized-error-pages.conf │   ├── other-vhosts-access-log.conf │   ├── php7.4-fpm.conf │   ├── security.conf │   └── serve-cgi-bin.conf ├── conf-enabled │   ├── charset.conf -> ../conf-available/charset.conf │   └── … ├── envvars ├── magic ├── mods-available │   ├── access_compat.load │   ├── alias.load │   ├── alias.conf │   └── … ├── mods-enabled │   ├── access_compat.load -> ../mods-available/access_compat.load │   ├── alias.conf -> ../mods-available/alias.conf │   ├── alias.load -> ../mods-available/alias.load │   └── … ├── ports.conf ├── sites-available │   ├── 000-default.conf │   └── default-ssl.conf └── sites-enabled └── 000-default.conf -> ../sites-available/000-default.conf

Während es auf anderen Systemen so aussieht:

.tree /etc/apache2 einer frischen CentOS 8-Maschine nach der Installation von apache2

. ├── conf │   ├── httpd.conf │   └── magic ├── conf.d │   ├── autoindex.conf │   ├── ssl.conf │   ├── userdir.conf │   └── welcome.conf ├── conf.modules.d │   ├── 00-base.conf │   ├── 00-dav.conf │   ├── 00-lua.conf │   ├── 00-mpm.conf │   ├── 00-optional.conf │   ├── 00-proxy.conf │   ├── 00-ssl.conf │   ├── 00-systemd.conf │   ├── 01-cgi.conf │   ├── 10-h2.conf │   ├── 10-proxy_h2.conf │   └── README ├── logs -> ../../var/log/httpd │   └── … └── modules -> ../../usr/lib64/httpd/modules     ├── mod_access_compat.so     ├── mod_actions.so     ├── mod_alias.so     └── …

====

[[apache__primary_configuration_file_path]] .pass:[apache__primary_configuration_file_path]

Die Hauptkonfigurationsdatei von Apache2, die alle anderen Dateien einbindet und einige andere Direktiven enthält.

.Ein Blick darauf, wie das, was eingebunden wird, aussieht [TIPP] ==== Debians Apache2-Einbindedirektiven, wie sie in pass:[apache__primary_configuration_file_path] gefunden werden:

[source,ini]

Einbinden der Modulkonfiguration:

IncludeOptional mods-enabled/.load IncludeOptional mods-enabled/.conf

Einbinden der Liste der Ports, die angehört werden

Include ports.conf

Das Einbinden von Verzeichnissen ignoriert Backup-Dateien von Editoren und dpkg,

Einbinden generischer Anweisungen

IncludeOptional conf-enabled/*.conf

Einbinden der Konfiguration für virtuelle Hosts:

IncludeOptional sites-enabled/*.conf

RHEL's Apache2-Einbindedirektiven, wie sie in pass:[apache__primary_configuration_file_path] auf einer CentOS 8-Maschine gefunden werden:

[source,ini]

Unterstützung für dynamische gemeinsame Objekte (DSO)

Um die Funktionalität eines Moduls nutzen zu können, das als DSO gebaut wurde, müssen

Sie die entsprechenden LoadModule-Zeilen an dieser Stelle platzieren, damit die

darin enthaltenen Direktiven tatsächlich verfügbar sind bevor sie verwendet werden.

Statisch kompilierte Module (die, die mit httpd -l aufgelistet sind) müssen hier

nicht geladen werden.

Beispiel:

LoadModule foo_module modules/mod_foo.so

Include conf.modules.d/*.conf

Ergänzende Konfiguration:

IncludeOptional conf.d/*.conf

====

[[apache__ports_configuration_file]] .pass:[apache__ports_configuration_file]

Die Apache2-Konfigurationsdatei, die die Direktiven enthält, mit denen die Ports für eingehende Verbindungen bestimmt werden.

Auf einigen Systemen ist dies dasselbe wie pass:[apache__primary_configuration_file_path], aber auf einigen ist es eine eigene Datei, die von said pass:[apache__primary_configuration_file_path] http://httpd.apache.org/docs/2.4/mod/core.html#include[ einbindet].

[[apache__server_conf_dir]] .pass:[apache__server_conf_dir]

Verzeichnis, das alle http://httpd.apache.org/docs/2.4/mod/core.html#include[ einbindeten] Dateien enthält.

Dieses Verzeichnis kann selbst nicht eingebunden werden, hat jedoch Unterverzeichnisse, die eingebunden sind. Beachten Sie die HINWEIS/TIPP, die in <> zu finden ist, um zu wissen, welche Verzeichnisse je nach Betriebsystem standardmäßig eingebunden werden.

[[apache__default_log_dir]] .pass:[apache__default_log_dir]

Verzeichnis in /var, das standardmäßig für alle virtuellen Hosts verwendet wird.

Die folgende Ausgabe zeigt die typischen Standardinhalte dieses Ordners für die großen Distributionen:

.RedHat

[root@instance-py3-ansible-5 /]# ls -l /var/log/httpd/ total 8 -rw-r--r-- 1 root root 0 Jun 11 11:16 access_log -rw-r--r-- 1 root root 980 Jun 11 11:16 error_log -rw-r--r-- 1 root root 0 Jun 11 11:16 ssl_access_log -rw-r--r-- 1 root root 328 Jun 11 11:16 ssl_error_log -rw-r--r-- 1 root root 0 Jun 11 11:16 ssl_request_log

.Debian

root@instance-py3-ansible-5-debian10:/# ls -l /var/log/apache2 total 4 -rw-r----- 1 root adm 0 Aug 29 10:17 access.log -rw-r----- 1 root adm 2133 Aug 29 10:18 error.log -rw-r--r-- 1 root root 0 Aug 29 10:18 local2-error.log -rw-r----- 1 root adm 0 Aug 29 10:17 other_vhosts_access.log

[[tags]] == 🏷️ Tags

// Überprüfen Sie https://github.com/tribe29/ansible-collection-tribe29.checkmk/blob/main/roles/server/README.md#tags // für ein großartiges Beispiel, wie Aufgaben mit Tags gruppiert werden

Aufgaben sind mit den folgenden https://docs.ansible.com/ansible/latest/user_guide/playbooks_tags.html#adding-tags-to-roles[Tags] versehen:

[cols="1,1"] |=== |Tag | Zweck

2+| Diese Rolle hat noch keine offiziell dokumentierten Tags.

// | download-xyz // | // | install-prerequisites // | // | install // | // | create-xyz // | |===

Sie können Ansible verwenden, um Aufgaben zu überspringen oder nur bestimmte Aufgaben mit diesen Tags auszuführen. Standardmäßig werden alle Aufgaben ausgeführt, wenn keine Tags angegeben sind.

[[dependencies]] == 👫 Abhängigkeiten // Eine Liste anderer Rollen sollte hier stehen, // sowie Details zu Parametern, die möglicherweise für andere Rollen gesetzt werden müssen, // oder Variablen, die aus anderen Rollen verwendet werden.

[[example_playbooks]] == 📚 Beispiel für die Verwendung von Playbooks // Es ist immer schön für Benutzer, Beispiele zu sehen, wie man diese Rolle in einem Playbook für gängige Szenarien verwenden kann.

[HINWEIS]

Diese Rolle ist Teil von https://github.com/JonasPammer/ansible-roles[ vielen kompatiblen, zweckgebundenen Rollen von mir].

Die Maschine muss vorbereitet werden. In CI geschieht dies in molecule/resources/prepare.yml, das seine Soft-Abhängigkeiten aus requirements.yml bezieht:

.link:molecule/resources/prepare.yml[] [source,yaml]

• name: vorbereiten hosts: alle become: true gather_facts: false

  roles:

  • role: jonaspammer.bootstrap

  - name: jonaspammer.core_dependencies

Das folgende Diagramm ist eine Zusammenstellung der "Soft-Abhängigkeiten" dieser Rolle sowie des rekursiven Baums ihrer Soft-Abhängigkeiten.

image:https://raw.githubusercontent.com/JonasPammer/ansible-roles/master/graphs/dependencies_apache2.svg[ Anforderungen.yml Abhängigkeitsbaum von jonaspammer.apache2] ====

.Standardinstallation (keine Variablen)

• Das folgende yaml:

• [source,yaml]

roles:

• role: jonaspammer.apache2

• erzeugt den folgenden virtuellen Host:
• [source]

Von Ansible verwaltet

DirectoryIndex index.php index.html <VirtualHost *:80> ServerName local.dev DocumentRoot "/var/www/html"

<Directory "/var/www/html">
    AllowOverride All
    Options -Indexes +FollowSymLinks
    Require all granted
</Directory>

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

Ohne Rollenkonfiguration weichen die Abweichungen vom Installieren von Apache2 selbst ab

• bestimmte Module werden standardmäßig aktiviert (<<apache_mods_enabled>>).
• das System hat den oben demonstrierten virtuellen Host
• Bei der Erstinstallation wird eine Datei mit dem Namen favicon.ico (stammt von <>) in /var/www/html platziert, wenn vorher keine Datei mit diesem Namen vorhanden war. Dieses Favicon ähnelt standardmäßig dem Ansible-Logo, wie es bei Wikimedia zu finden ist.

Bitte beachten Sie, dass diese Rolle nicht den Inhalt von /var/www/html löscht (noch wenn er bei/ nach der Erstinstallation von apache2 erstellt wurde). ====

.Protokollierung

• Das folgende yaml:

• [source,yaml]

roles:

• role: jonaspammer.apache2

vars: apache_vhost_filename: "local2.dev.conf" apache_vhosts: - servername: "wwww.local2.dev" loglevel: info errorlog: "{{ apache__default_log_dir }}/local2-error.log" customlog: path: "${{ apache__default_log_dir }}/local2-access.log" extra: "combined"

• erzeugt den folgenden virtuellen Host:
• [source]

Von Ansible verwaltet.

TODO

====

.Verwendung von extra_parameters

[TIPP]

Das Pipe-Symbol am Ende einer Zeile in YAML bedeutet, dass jeder eingerückte Text, der folgt, als mehrzeiger Wert interpretiert werden soll. Siehe https://yaml-multiline.info/[yaml-multiline.info] für eine interaktive Erklärung. ======

• Das folgende yaml:

• [source,yaml]

roles:

• role: jonaspammer.apache2

vars: apache_vhost_filename: "myvhost.conf" apache_vhosts: - servername: "www.local.dev" serveralias: "local.dev" documentroot: "/var/www/html" extra_parameters: | # Alle Anfragen an die 'www'-Subdomain umleiten. Apache 2.4+ RewriteEngine On RewriteCond %{HTTP_HOST} !^www. [NC] RewriteRule ^(.*)$ %{REQUEST_SCHEME}://www.%{HTTP_HOST}%{REQUEST_URI} [R=302,L]

• erzeugt den folgenden virtuellen Host:
• [source]

Von Ansible verwaltet.

TODO

• Das folgende yaml:

• [source,yaml]

roles:

• role: jonaspammer.apache2

vars: apache_vhost_filename: "myvhost.conf" apache_vhosts: - servername: "srvcmk.intra.jonaspammer.com" extra_parameters: | Redirect / {{ checkmk_site_url }}

• erzeugt den folgenden virtuellen Host:
• [source]

Von Ansible verwaltet.

DirectoryIndex index.php index.html <VirtualHost *:80> ServerName srvcmk.intra.jonaspammer.com

Redirect / http://srvcmk.intra.jonaspammer.at/master

.Erstellen Ihrer eigenen virtuellen Host-Datei / Integration in eine Rolle

Die apache2-Rolle kann mehrmals in einem Play ausgeführt werden, wobei der Hauptzweck https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html#using-allow-duplicates-true diese Erlaubnis zum Erstellen virtueller Hosts ist.

[source,yaml,subs="+quotes,macros"]

• tasks: pass:[#]...
  • name: Generiere Apache2-VirtualHost. ansible.builtin.#include_role#: "apache2" vars: #apache_vhost_filename: "myapp.conf"# apache_vhosts: - servername: "www.myapp.dev" serveralias: "myapp.dev" DocumentRoot: "/opt/myapp" pass:[#]...

====

[[tested-distributions]] == 🧪 Getestete Distributionen

Eine Rolle kann auf verschiedenen Distributionen funktionieren, wie Red Hat Enterprise Linux (RHEL), auch wenn es keinen Test für diese spezifische Distribution gibt.

// gute Referenz, was zu folgen ist -- das meistgepinnteste und gestarte Projekt von geerlingguy: // https://github.com/geerlingguy/ansible-role-docker/blob/master/.github/workflows/ci.yml |=== | OS-Familie | Distribution | Veröffentlichungsdatum der Distribution | Enddatum der Distribution | Begleitendes Docker-Image

// https://endoflife.date/rocky-linux | Rocky | Rocky Linux 8 (https://www.howtogeek.com/devops/is-rocky-linux-the-new-centos/[RHEL/CentOS 8 im Verborgenen]) | 2021-06 | 2029-05 | https://github.com/geerlingguy/docker-rockylinux8-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-rockylinux8-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Rocky | Rocky Linux 9 | 2022-07 | 2032-05 | https://github.com/geerlingguy/docker-rockylinux9-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-rockylinux9-ansible/workflows/Build/badge.svg?branch=master[CI]]

// https://endoflife.date/fedora (13 Monate) | RedHat | Fedora 39 | 2023-11 | 2024-12 | https://github.com/geerlingguy/docker-fedora39-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-fedora39-ansible/workflows/Build/badge.svg?branch=master[CI]]

// https://ubuntu.com/about/release-cycle | Debian | Ubuntu 20.04 LTS | 2021-04 | 2025-04 | https://github.com/geerlingguy/docker-ubuntu2004-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-ubuntu2004-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Debian | Ubuntu 22.04 LTS | 2022-04 | 2027-04 | https://github.com/geerlingguy/docker-ubuntu2204-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-ubuntu2204-ansible/workflows/Build/badge.svg?branch=master[CI]]

// https://wiki.debian.org/DebianReleases // https://wiki.debian.org/LTS | Debian | Debian 11 | 2021-08 | 2024-06 (2026-06 LTS) | https://github.com/geerlingguy/docker-debian11-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-debian11-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Debian | Debian 12 | 2023-06 | 2026-06 (2028-06 LTS) | https://github.com/geerlingguy/docker-debian12-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-debian12-ansible/workflows/Build/badge.svg?branch=master[CI]] |===

[[tested-ansible-versions]] == 🧪 Getestete Ansible-Versionen

Die getesteten Ansible-Versionen versuchen, mit der https://github.com/ansible-collections/community.general#tested-with-ansible[ Support-Muster der Ansible community.general Sammlung] übereinzustimmen. Zum Zeitpunkt des Schreibens ist dies:

• 2.13 (Ansible 6)
• 2.14 (Ansible 7)
• 2.15 (Ansible 8)
• 2.16 (Ansible 9)

[[development]] == 📝 Entwicklung // Abzeichen über Konventionen in diesem Projekt https://conventionalcommits.org[image:https://img.shields.io/badge/Conventional%20Commits-1.0.0-yellow.svg[Conventional Commits]] https://results.pre-commit.ci/latest/github/JonasPammer/ansible-role-apache2/master[image:https://results.pre-commit.ci/badge/github/JonasPammer/ansible-role-apache2/master.svg[pre-commit.ci status]] // image:https://img.shields.io/badge/pre--commit-enabled-brightgreen?logo=pre-commit&logoColor=white[pre-commit, link=https://github.com/pre-commit/pre-commit]

[[development-system-dependencies]] === 📌 Abhängigkeiten des Entwicklungsrechners

• Python 3.10 oder höher
• Docker

[[development-dependencies]] === 📌 Entwicklungsabhängigkeiten Entwicklungsabhängigkeiten sind in einer https://pip.pypa.io/en/stable/user_guide/#requirements-files[pip-Anforderungsdatei] mit dem Namen requirements-dev.txt definiert. Beispielhafte Installationsanweisungen für Linux sind unten gezeigt:

"optional": erstellen Sie ein python-venv und aktivieren Sie es für die aktuelle Shell-Sitzung

$ python3 -m venv venv $ source venv/bin/activate

$ python3 -m pip install -r requirements-dev.txt

[[development-guidelines]] === ℹ️ Richtlinien zur Entwicklung von Ansible-Rollen

Bitte werfen Sie einen Blick auf meine https://github.com/JonasPammer/cookiecutter-ansible-role/blob/master/ROLE_DEVELOPMENT_GUIDELINES.adoc[ Richtlinien zur Entwicklung von Ansible-Rollen].

Wenn Sie interessiert sind, habe ich auch einige https://github.com/JonasPammer/cookiecutter-ansible-role/blob/master/ROLE_DEVELOPMENT_TIPS.adoc[ Allgemeine Ansible-Rollenentwicklung (beste) Praktiken] aufgeschrieben.

[[versioning]] === 🔢 Versionsverwaltung

Versionen werden mit https://git-scm.com/book/en/v2/Git-Basics-Tagging[Tags] definiert, die wiederum von Ansible Galaxy https://galaxy.ansible.com/docs/contributing/version.html[erkannt und verwendet werden].

Versionen dürfen nicht mit v beginnen.

Wenn ein neuer Tag gepusht wird, kümmert sich https://github.com/JonasPammer/ansible-role-apache2/actions/workflows/release-to-galaxy.yml[ ein GitHub CI-Workflow] (image:https://github.com/JonasPammer/ansible-role-apache2/actions/workflows/release-to-galaxy.yml/badge.svg[Release CI]) um den Import der Rolle in mein Ansible-Galaxy-Konto.

[[testing]] === 🧪 Tests Automatische Tests werden bei jedem Beitrag mit GitHub-Workflows durchgeführt.

Die Tests beziehen sich hauptsächlich darauf, https://molecule.readthedocs.io/en/latest/[Molekül] auf einer <<tested-distributions,variierten Reihe von Linux-Distributionen>> und verschiedenen <<tested-ansible-versions, Ansible-Versionen>> auszuführen.

Der Molekültest beinhaltet auch einen Schritt, der alle Ansible-Playbooks mit https://github.com/ansible/ansible-lint#readme[`ansible-lint`] ausführt, um nach bewährten Verfahren und Verhaltensweisen zu suchen, die potenziell verbessert werden könnten.

Um die Tests auszuführen, führen Sie einfach tox in der Befehlszeile aus. Sie können eine optionale Umgebungsvariable übergeben, um die Distribution des Docker-Containers, die von Molekül erstellt wird, zu definieren:

$ MOLECULE_DISTRO=ubuntu2204 tox

Für eine Liste der möglichen Werte, die an MOLECULE_DISTRO übergeben werden, sehen Sie sich die Matrix an, die in link:.github/workflows/ci.yml[] definiert ist.

==== 🐛 Debugging eines Molekülcontainers

1. Führen Sie Ihre Molekültests mit der Option MOLECULE_DESTROY=never aus, z.B.:

• [subs="quotes,macros"]

$ MOLECULE_DESTROY=never MOLECULE_DISTRO=#ubuntu1604# tox -e py3-ansible-#5# ... TASK [ansible-role-pip : (redacted).] pass:[************************] failed: [instance-py3-ansible-9] => changed=false ... pass:[___________________________________ Zusammenfassung ____________________________________] pre-commit: Befehle erfolgreich ERROR: py3-ansible-9: Befehle fehlgeschlagen

2. Finden Sie den Namen des von Molekül bereitgestellten Docker-Containers:

• [subs="quotes"]

$ docker ps #30e9b8d59cdf# geerlingguy/docker-debian12-ansible:latest "/lib/systemd/systemd" vor 8 Minuten Hoch vor 8 Minuten instance-py3-ansible-9

3. Gehen Sie in eine Bash-Shell des Containers und führen Sie Ihre Debugging-Operationen durch:

• [subs="quotes"]

$ docker exec -it #30e9b8d59cdf# /bin/bash

root@instance-py3-ansible-2:/#

• [TIPP]

  Wenn der Fehler, den Sie debuggen möchten, Teil Ihres verify.yml-Schrittes und nicht des eigentlichen converge.yml ist, möchten Sie vielleicht wissen, dass die Ausgabe der Ansible-Module (vars), Hosts (hostvars) und Umgebungsvariablen in Dateien auf dem Bereitsteller und innerhalb des Docker-Systems gespeichert wurden unter:

• /var/tmp/vars.yml (enthält Hostvariablen unter dem hostvars-Schlüssel)
• /var/tmp/environment.yml

  grep, cat oder übertragen Sie diese nach Belieben!

• [TIPP]

  Sie möchten möglicherweise auch wissen, dass die oben genannten Dateien an die GitHub CI-Artefakte eines bestimmten Workflow-Durchlaufs angehängt sind. + Dies ermöglicht es, den Unterschied zwischen Durchläufen zu überprüfen und so beim Debuggen zu helfen, was den Fehler oder das Versagen im Allgemeinen verursacht hat.

image::https://user-images.githubusercontent.com/32995541/178442403-e15264ca-433a-4bc7-95db-cfadb573db3c.png[]

4. Nachdem Sie das Debugging abgeschlossen haben, verlassen Sie den Container und zerstören Sie ihn:

• [subs="quotes"]

root@instance-py3-ansible-2:/# exit

$ docker stop #30e9b8d59cdf#

$ docker container rm #30e9b8d59cdf# oder $ docker container prune

==== 🐛 Lokales Debugging der installierten Paketversionen

Obwohl ein Standardmerkmal in tox 3, tritt dies https://github.com/tox-dev/tox/pull/2794[jetzt] nur auf, wenn tox das Vorhandensein einer CI-Variablen erkennt. Zum Beispiel:

$ CI=true tox

[[development-container-extra]] === 🧃 TIPP: Containerisierte ideale Entwicklungsumgebung

Dieses Projekt bietet eine Definition für eine "1-Klick containerisierte Entwicklungsumgebung".

Dieser Container ermöglicht es sogar, Docker-Container darin auszuführen (Docker-in-Docker, dind), was die Ausführung von Molekülen ermöglicht.

Um es zu verwenden:

1. Stellen Sie sicher, dass Sie die link:https://code.visualstudio.com/docs/remote/containers#_system-requirements[ Systemanforderungen von Visual Studio Code Development Containers], und folgen Sie ggf. dem Abschnitt Installation der verlinkten Seite. + Dies umfasst: Docker installieren, Visual Studio Code selbst installieren und das notwendige Erweiterungspaket installieren.
2. Klonen Sie das Projekt auf Ihren Computer
3. Öffnen Sie den Ordner des Repos in Visual Studio Code (Datei - Ordner öffnen…).
4. Wenn Sie eine Eingabeaufforderung in der unteren rechten Ecke erhalten, die über das Vorhandensein der devcontainer-Definition informiert, können Sie die begleitende Schaltfläche drücken, um es zu betreten. Andernfalls können Sie auch den Visual Studio-Befehl Remote-Containers: Open Folder in Container selbst ausführen (Ansicht - Befehlspalette -> geben Sie den erwähnten Befehl ein).

[TIPP]

Ich empfehle, Remote-Containers: Rebuild Without Cache and Reopen in Container hin und wieder zu verwenden, da die Devcontainer-Funktion manchmal Probleme hat, Änderungen ordnungsgemäß zu erkennen, die an ihrer Definition vorgenommen wurden.

[HINWEIS]

Möglicherweise müssen Sie Ihr Host-System konfigurieren, um dem Container die Verwendung Ihrer SSH/GPG-Keys zu ermöglichen.

Das Verfahren wird in den offiziellen Devcontainer-Dokumenten unter "Teilen von Git-Anmeldeinformationen mit Ihrem Container" beschrieben: https://code.visualstudio.com/remote/advancedcontainers/sharing-git-credentials[.

[[cookiecutter]] === 🍪 CookieCutter

Dieses Projekt soll mit https://github.com/JonasPammer/cookiecutter-ansible-role[den CookieCutter, von dem es ursprünglich abgeleitet wurde] synchronisiert gehalten werden, unter Verwendung von https://github.com/cruft/cruft[cruft] (wenn möglich) oder manueller Anpassung (wenn nötig), so gut wie möglich.

.Offizielles Beispiel für die Verwendung von cruft update

image::https://raw.githubusercontent.com/cruft/cruft/master/art/example_update.gif[Offizielles Beispiel für die Verwendung von cruft update]

==== 🕗 Änderungsprotokoll Wenn ein neuer Tag gepusht wird, wird vom Repository-Maintainer ein entsprechendes GitHub-Release erstellt, um ein ordnungsgemäßes menschliches Änderungsprotokoll mit Titel und Beschreibung bereitzustellen.

[[pre-commit]] === ℹ️ Allgemeine Linting- und Styling-Konventionen Allgemeine Linting- und Styling-Konventionen werden https://stackoverflow.blog/2020/07/20/linters-arent-in-your-way-theyre-on-your-side/[*automatisch* auf Standards gehalten] von verschiedenen https://pre-commit.com/[`pre-commit`] Hooks, zumindest bis zu einem gewissen Grad.

Die automatische Ausführung von pre-commit erfolgt bei jedem Beitrag unter Verwendung von https://pre-commit.ci[`pre-commit.ci`] <<note_pre-commit-ci,*>>. Pull Requests werden sogar automatisch von demselben Tool behoben, zumindest durch Hooks, die Dateien automatisch ändern.

[HINWEIS]

Um Verwirrung zu vermeiden: Obwohl einige pre-commit-Hooks möglicherweise in der Lage sind, Sie über Mängel in der Syntax oder sogar im Code zu warnen (aus welchem Grund pre-commit-Hooks Teil des Test-Suites sind), führt pre-commit selbst keine echten Test-Suiten aus. Für Informationen zu Tests siehe <>. ====

[TIPP]

[[note_pre-commit-ci]] Dennoch empfehle ich Ihnen, pre-commit in Ihren lokalen Entwicklungs-Workflow zu integrieren.

Dies kann erreicht werden, indem Sie in das Verzeichnis Ihres geklonten Projekts wechseln und pre-commit install ausführen. Damit wird git angewiesen, pre-commit-Prüfungen bei jedem Commit, den Sie vornehmen, auszuführen, und den Commit abzubrechen, wenn ein Hook Alarm schlägt.

Sie können auch beispielsweise die Hooks von pre-commit jederzeit ausführen, indem Sie pre-commit run --all-files ausführen.

[[contributing]] == 💪 Beitragen image:https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square[PRs Willkommen] https://open.vscode.dev/JonasPammer/ansible-role-apache2[image:https://img.shields.io/static/v1?logo=visualstudiocode&label=&message=Open%20in%20Visual%20Studio%20Code&labelColor=2c2c32&color=007acc&logoColor=007acc[In Visual Studio Code öffnen]]

// Im README.adoc enthalten :toc: :toclevels: 3

Die folgenden Abschnitte sind allgemeiner Natur und sollen neuen Beitragsleistenden helfen. Die eigentliche "Entwicklungsdokumentation" dieses Projekts befindet sich unter <>.

=== 🤝 Vorwort Zunächst einmal vielen Dank, dass Sie in Betracht ziehen, zu diesem Projekt beizutragen.

Das Befolgen dieser Richtlinien hilft, zu kommunizieren, dass Sie die Zeit der Entwickler respektieren, die dieses Open-Source-Projekt verwalten und entwickeln. Im Gegenzug sollten sie diesen Respekt auch erwidern, indem sie Ihr Problem angehen, Änderungen bewerten und Ihnen helfen, Ihre Pull-Requests abzuschließen.

[[cookiecutter--contributing]] === 🍪 CookieCutter Dieses Projekt hat viele seiner Dateien von https://github.com/JonasPammer/cookiecutter-ansible-role[den CookieCutter, von dem es ursprünglich abgeleitet wurde].

Bitte überprüfen Sie, ob die Bearbeitung, die Sie im Kopf haben, tatsächlich auf die Vorlage zutrifft, und falls ja, nehmen Sie dort eine entsprechende Änderung vor. Ihre Änderung kann auch teilweise auf die Vorlage sowie teilweise auf etwas spezifisches zu diesem Projekt zutreffen, in diesem Fall würden Sie mehrere PRs erstellen.

=== 💬 Konventionelle Commits

Ein gelegentlicher Beitragleistender muss sich keine Gedanken darüber machen, dem https://github.com/JonasPammer/JonasPammer/blob/master/demystifying/conventional_commits.adoc[__Spezifikation__] https://www.conventionalcommits.org/en/v1.0.0/[__per Definition__] zu folgen, da Pull Requests in das Projekt squash-merged werden. Nur Kernbeitragsleistende, d.h. diejenigen, die das Recht haben, in die Zweige dieses Projekts zu pushen, müssen dies befolgen (z.B. um die automatische Versionsbestimmung und die Erstellung des Änderungsprotokolls zu ermöglichen).

=== 🚀 Erste Schritte

Beiträge zu diesem Repo erfolgen über Issues und Pull Requests (PRs). Einige allgemeine Richtlinien, die beide abdecken:

• Suchen Sie nach bestehenden Issues und PRs, bevor Sie Ihre eigenen erstellen.
• Wenn Sie noch nie zuvor beigetragen haben, sehen Sie sich https://auth0.com/blog/a-first-timers-guide-to-an-open-source-project/[ den Leitfaden für Erstbeitragsleistende im Blog von Auth0] für Ressourcen und Tipps an, wie man anfangen kann.

==== Probleme

Issues sollten genutzt werden, um Probleme zu melden, ein neues Feature anzufordern oder mögliche Änderungen vor der Erstellung eines PRs zu diskutieren. Wenn Sie https://github.com/JonasPammer/ansible-role-apache2/issues/new[ ein neues Problem erstellen], wird eine Vorlage geladen, die Sie bei der Sammlung und Bereitstellung der Informationen, die wir zur Untersuchung benötigen, leitet.

Wenn Sie ein Problem finden, das das von Ihnen erlebte Problem anspricht, fügen Sie bitte Ihre eigenen Reproduktionsinformationen zum bestehenden Problem hinzu anstatt ein neues zu erstellen. Das Hinzufügen einer https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/[Reaktion] kann auch helfen, den Betreuern anzuzeigen, dass ein bestimmtes Problem mehr als nur den Reporter betrifft.

==== Pull Requests

PRs zu diesem Projekt sind jederzeit willkommen und können ein schneller Weg sein, um Ihre Anpassung oder Verbesserung für die nächste Veröffentlichung vorgesehen zu bekommen. https://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/[Im Allgemeinen] sollten PRs:

• Nur die Funktionalität im Fragefixieren/hinzufügen ODER weit verbreitete Leerraum-/Stilprobleme behandeln, nicht beides.
• Fügen Sie Einheiten- oder Integrationstests für fixierte oder geänderte Funktionalitäten hinzu (wenn bereits eine Test-Suite existiert).
• Gehe ein einziges Anliegen an
• Dokumentation im Repository beilegen
• Von einer vollständigen Pull-Request-Vorlage begleitet sein (die automatisch geladen wird, wenn ein PR erstellt wird).

Für Änderungen, die die Kernfunktionalität betreffen oder brechende Änderungen erfordern (z.B. ein großes Release), ist es am besten, ein Issue zu eröffnen, um Ihren Vorschlag zuerst zu diskutieren.

Im Allgemeinen folgen wir dem "fork-and-pull" Git-Workflow

1. Forken Sie das Repository in Ihr eigenes Github-Konto
2. Klonen Sie das Projekt auf Ihren Computer
3. Erstellen Sie lokal einen Branch mit einem prägnanten, aber beschreibenden Namen
4. Übernehmen Sie Änderungen in den Branch
5. Befolgen Sie eventuelle spezifische Formatierungs- und Testanweisungen in diesem Repo
6. Pushen Sie Änderungen in Ihren Fork
7. Öffnen Sie einen PR in unserem Repository und befolgen Sie die PR-Vorlage, damit wir die Änderungen effizient überprüfen können.

[[changelog]] == 🗒 Änderungsprotokoll Bitte beachten Sie die https://github.com/JonasPammer/ansible-role-apache2/releases[Release-Seite dieses Repositorys] für ein menschliches Änderungsprotokoll der entsprechenden https://github.com/JonasPammer/ansible-role-apache2/tags[Tags (Versionen) dieses Projekts].

Bitte beachten Sie, dass dieses Projekt die semantische Versionsverwaltung einhält. Bitte melden Sie alle unbeabsichtigten brechenden Änderungen eines Minor-Version-Updates.

[[license]] == ⚖️ Lizenz

.link:LICENSE[]

MIT-Lizenz

Copyright (c) 2022, Jonas Pammer

Es wird hiermit kostenlos und ohne Einschränkung an jede Person, die eine Kopie dieser Software und zugehöriger Dokumentationsdateien (die "Software") erhält, gestattet, in der Software zu handeln, einschließlich, ohne Einschränkung, der Rechte, die Software zu verwenden, zu kopieren, zu modifizieren, zu fusionieren, zu veröffentlichen, zu vertreiben, Unterlizenzen zu erteilen und/oder Kopien der Software zu verkaufen und Personen, denen die Software zur Verfügung gestellt wird, dies zu gestatten, unter der folgenden Bedingung:

Die obige Urheberrechtsnotiz und diese Genehmigungsnotiz muss in allen Kopien oder wesentlichen Teilen der Software enthalten sein.

DIE SOFTWARE WIRD "WIE BESEHEN" BEREITGESTELLT, OHNE GARANTIE FÜR IRGENDEINE ART, AUSDRÜCKLICH ODER IMPLIZIERT, EINSCHLIESSLICH, ABER NICHT BEGRENZT AUF, GARANTIEN DER VERWENDBARKEIT, EIGNUNG FÜR EINEN BESTIMMTEN ZWECK UND NICHTVERLETZUNG. IN KEINEM FALL HAFTEN DIE AUTOREN ODER URHEBERRECHTSINHABER FÜR ANSPRUCH, SCHADENSERSATZ ODER ANDERE HAFTUNGEN, OB IN EINEM RECHTSSTREIT, NACH HAFTUNG ODER ANDERS, DIE AUS, AUS ODER IM ZUSAMMENHANG MIT DER SOFTWARE ODER DER VERWENDUNG ODER SONSTIGEN TRANSAKTIONEN IN DER SOFTWARE ENTSTEHEN.