Erläuterung der Konfigurationsdateien | AEM

Beschreibung description

Umgebung

Experience Manager

Problem/Symptome

In diesem Dokument werden die einzelnen Konfigurationsdateien, die auf einem standardmäßigen, in Adobe Managed Services bereitgestellten Dispatcher-Server bereitgestellt werden, aufgeschlüsselt und erläutert. Verwendung, Benennungskonvention usw.

Benennungskonvention

Apache Webserver kümmert sich bei der Zielgruppenbestimmung mit einer optionalen Include- oder Include-Anweisung nicht darum, welche Dateierweiterung von einer Datei ist. Eine ordnungsgemäße Benennung mit Namen, die Konflikte und Verwirrung beseitigen, hilft einer Tonne. Die verwendeten Namen beschreiben den Umfang, in dem die Datei angewendet wird, und erleichtern das Leben. Wenn alles als .conf bezeichnet wird, wird das wirklich verwirrend. Vermeiden Sie schlecht benannte Dateien und Erweiterungen.

Im Folgenden finden Sie eine Liste der verschiedenen benutzerdefinierten Dateierweiterungen und Namenskonventionen, die in einem typischen AMS-konfigurierten Dispatcher verwendet werden.

In "conf.d/"enthaltene Dateien

Datei
Dateiziel
Beschreibung
< DATEINAME> .conf
/etc/httpd/conf.d/
Eine standardmäßige Enterprise Linux-Installation verwendet diese Dateierweiterung und den Include-Ordner als Ort, um Einstellungen in httpd.conf zu überschreiben und Ihnen das Hinzufügen zusätzlicher Funktionen auf globaler Ebene in Apache zu ermöglichen.
< FILENAME> .vhost

Gestaffelt: /etc/httpd/conf.d/available_vhosts/

Aktiv:

/etc/httpd/conf.d/enabled_vhosts/

*Hinweis: .vhost-Dateien werden nicht in den Ordner "enabled_vhosts"kopiert, sondern verwenden Symlinks zu einem relativen Pfad zur Datei "available_vhosts/.vhost"

*.vhost-Dateien (virtueller Host) sind < VirtualHosts >  -Einträge, um Hostnamen zu entsprechen und es Apache zu ermöglichen, den jeweiligen Domänen-Traffic mit verschiedenen Regeln zu behandeln. Aus der .vhost-Datei stammen andere Dateien wie Neuschreibungen, Whitelisting usw. ist enthalten.
< DATEINAME> _rewrite.rules
/etc/httpd/conf.d/rewrites/
*_rewrite.rules -Dateien speichern mod_rewrite -Regeln, die explizit von einer Vhost-Datei eingeschlossen und genutzt werden sollen
< FILENAME> _whitelist.rules
/etc/httpd/conf.d/whitelists/
*_ipwhitelist.rules-Dateien werden aus den *.vhost-Dateien einbezogen. Es enthält IP-Regex oder erlaubt Ablehnungsregeln, IP-Whitelisting zuzulassen. Wenn Sie versuchen, die Anzeige eines virtuellen Hosts auf der Basis von IP-Adressen zu beschränken, generieren Sie eine dieser Dateien und schließen sie aus Ihrer *.vhost-Datei ein.

In "conf.modules.d/"enthaltene Dateien

Datei
Dateiziel
Beschreibung
< FILENAME> .any
/etc/httpd/conf.dispatcher.d/
Das AEM Dispatcher Apache Module gibt die Einstellungen aus *.any-Dateien. Die standardmäßige übergeordnete Include-Datei lautet "conf.dispatcher.d/dispatcher.any".
< DATEINAME> _farm.any

Staged

:

/etc/httpd/conf.dispatcher.d/available_farms/

Active

:

/etc/httpd/conf.dispatcher.d/enabled_farms/

*Hinweis: Diese Farm-Dateien werden nicht in den Ordner enabled_farms kopiert, sondern verwenden Symlinks zu einem relativen Pfad zur Datei available_farms/_farm.any

*farm.any-Dateien sind in der Datei "conf.dispatcher.d/dispatcher.any"enthalten. Diese übergeordneten Farm-Dateien dienen zur Steuerung des Modulverhaltens für jeden Renderer oder Website-Typ. Die Dateien werden im Verzeichnis "available_farms"erstellt und mit einem Symlink in den Ordner "enabled_farms"aktiviert.

Sie enthält sie automatisch nach Namen aus der Datei "dispatcher.any".

Grundlegende Farm-Dateien beginnen mit 000
, um sicherzustellen, dass sie zuerst geladen werden.

Benutzerdefinierte Farm-Dateien sollten nach geladen werden, indem ihr Zahlenschema bei 100_ gestartet wird, um das richtige Einschlussverhalten sicherzustellen.
< DATEINAME> _filters.any
/etc/httpd/conf.dispatcher.d/filters/
*_filters.any-Dateien werden aus den Dateien "conf.dispatcher.d/enabled_farms/*_farm.any"einbezogen. Jede Farm verfügt über eine Reihe von Regeln, die ändern, welcher Traffic herausgefiltert werden soll, und nicht zu den Renderern.
< DATEINAME> _vhosts.any
/etc/httpd/conf.dispatcher.d/vhosts/
*_vhosts.any-Dateien werden aus den Dateien "conf.dispatcher.d/enabled_farms/*_farm.any"einbezogen. Diese Dateien sind eine Liste von Hostnamen oder URI-Pfaden, die durch eine Blob-Übereinstimmung abgeglichen werden, um zu bestimmen, welcher Renderer für die Bereitstellung dieser Anfrage verwendet werden soll
< DATEINAME> _cache.any
/etc/httpd/conf.dispatcher.d/cache/
*_cache.any-Dateien werden aus den Dateien "conf.dispatcher.d/enabled_farms/*_farm.any"einbezogen. Diese Dateien geben an, welche Elemente zwischengespeichert werden und welche nicht
< FILENAME> _invalidate_allowed.any
/etc/httpd/conf.dispatcher.d/cache/
*_invalidate_allowed.any-Dateien sind in den Dateien "conf.dispatcher.d/enabled_farms/*_farm.any"enthalten. Sie geben an, welche IP-Adressen Flush- und Invalidierungsanfragen senden dürfen.
< FILENAME> _clientheaders.any
/etc/httpd/conf.dispatcher.d/clientheaders/
*_clientheaders.any-Dateien sind in den Dateien "conf.dispatcher.d/enabled_farms/*_farm.any"enthalten. Sie geben an, welche Client-Header an jeden Renderer übergeben werden sollen.
< DATEINAME> _renders.any
/etc/httpd/conf.dispatcher.d/renders/
*_renders.any-Dateien sind in den Dateien "conf.dispatcher.d/enabled_farms/*_farm.any"enthalten. Sie geben IP-, Port- und Timeout-Einstellungen für jeden Renderer an. Ein ordnungsgemäßer Renderer kann ein LiveCycle-Server oder ein beliebiges AEM sein, von dem aus Dispatcher die Anforderungen abrufen/Proxy erstellen kann.

Vermeidete Probleme

Vermeiden Sie bei der Befolgung der Benennungskonvention einige recht einfache Fehler, die katastrophale Folgen haben können. Lassen Sie uns ein paar Beispiele anführen.

Problembeispiel

Als Site-Beispiel für ExampleCo werden zwei Konfigurationsdateien von den Entwicklern der Dispatcher-Konfigurationen erstellt.

/etc/httpd/conf.d/exampleco.conf

<VirtualHost *:80>

    ServerName  "exampleco"

    ServerAlias "www.exampleco.com"

    .......... SNIP ...............

    <IfModule mod_rewrite.c>

        ReWriteEngine   on

        LogLevel warn rewrite:trace1

        Include /etc/httpd/conf.d/rewrites/exampleco.conf

    </IfModule>

</VirtualHost>

/etc/httpd/conf.d/rewrites/exampleco.conf

RewriteRule /$ /content/exampleco/en.html [ PT,L]

RewriteRule /robots.txt$ /content/dam/exampleco/robots.txt [ PT,L]

POTENZIELLE GEFAHR

A. Die Dateinamen sind identisch.

Wenn die vhost-Datei versehentlich im Ordner "rewrites"abgelegt wird und die Datei "rewrites"in den Ordner "vhosts"eingefügt wird. Es scheint ordnungsgemäß vom Dateinamen bereitgestellt zu werden, doch gibt Apache einen Fehler aus und das Problem ist nicht sofort ersichtlich.

Wie wird dies normalerweise zu einem Problem?

Wenn die beiden Dateien an denselben Speicherort heruntergeladen werden, können sie sich entweder selbst überschreiben oder es nicht unterscheidbar machen, was den Implementierungsprozess zu einem Albtraum macht.

B. Die Dateierweiterungen sind identisch und können automatisch einbezogen werden

Die Dateierweiterungen sind identisch und verwenden die automatisch eingeschlossene Erweiterung, in die Apache automatisch alle .conf-Dateien in vielen seiner Standardordner einfügt.

Wie wird dies normalerweise zu einem Problem?

Wenn die vhost-Datei mit der Erweiterung .conf im Ordner /etc/httpd/conf.d/ abgelegt wird, wird versucht, sie in den Speicher auf Apache zu laden, was normalerweise in Ordnung ist. Wenn jedoch die Datei mit den Umschreibungsregeln mit der Erweiterung .conf im Ordner /etc/httpd/conf.d/ platziert wird, wird sie automatisch eingefügt und global angewendet, was zu verwirrenden und unerwünschten Ergebnissen führt.

Auflösung resolution

Benennen Sie die Dateien basierend auf dem, was sie tun, und verlassen Sie sie sicher aus dem Namespace für automatische Einschlussregeln.

  • Wenn es sich um eine virtuelle Host-Datei handelt, benennen Sie sie mit .vhost als Erweiterung.
  • Wenn es sich um eine Rewrite-Regeldatei handelt, benennen Sie sie mit "<site>_rewrite.rules"als Suffix und Erweiterung. Diese Namenskonvention macht deutlich, für welche Site es sich handelt und dass es sich um einen Satz von Neuschreibungsregeln handelt.
  • Wenn es sich um eine IP-Whitelist-Regeldatei handelt, nennen Sie sie "<description>_whitelist.rules"als Suffix und Erweiterung. Diese Namenskonvention gibt eine Beschreibung dessen, wofür sie verwendet wird und ob es sich um einen Satz von IP-Übereinstimmungsregeln handelt.

Durch die Verwendung dieser Namenskonventionen werden Probleme vermieden, wenn eine Datei in ein Verzeichnis mit automatischem Include verschoben wird, zu dem sie nicht gehört.

Das Einfügen einer Datei mit dem Namen .rules, .any oder .vhost in den Ordner "auto-include"von /etc/httpd/conf.d/ hätte beispielsweise keine Auswirkungen.

Wenn in einer Bereitstellungsanfrage please deploy exampleco_rewrite.rules to production dispatchers angegeben wird, kann die Person, die die Änderungen bereitstellt, bereits wissen, dass sie keine neue Site hinzufügt. Sie aktualisiert lediglich die Neuschreibungsregeln, wie durch den Dateinamen angegeben.

Reihenfolge einschließen

Beim Erweitern der Funktionalität und Konfigurationen in Apache Webserver, der auf Enterprise Linux installiert ist, haben Sie einige wichtige Include-Bestellungen, die Sie verstehen möchten.

A. Grundlegende Apache-Includes

Die Apache-Binärdatei beginnt mit httpd.conf , was den Verzeichnissen conf.d/*.conf und conf.modules.d/*.conf eine includeoptional zuordnet.

Wie im Diagramm oben gezeigt, betrachtet die HTTPD-Binärdatei nur die httpd.conf -Datei als Konfigurationsdatei. Diese Datei enthält die folgenden Anweisungen:

Include conf.modules.d/*.conf
IncludeOptional conf.d/*.conf

B. AMS-oberste Ebene enthält

Als wir unseren Standard angewendet haben, haben wir einige zusätzliche Dateitypen und eigene Includes hinzugefügt.

Im Folgenden finden Sie die Grundlinien-Verzeichnisse von AMS und die wichtigsten Includes

Aufbauend auf der Apache-Grundlinie zeigen wir, wie AMS einige zusätzliche Ordner und Top-Level-Includes für conf.d-Ordner sowie modulspezifische Verzeichnisse erstellt hat, die unter /etc/httpd/conf.dispatcher.d/ verschachtelt sind.

Wenn Apache geladen wird, ruft es den /etc/httpd/conf.modules.d/02-dispatcher.conf -Wert ab und diese Datei enthält die Binärdatei /etc/httpd/modules/mod_dispatcher.so in den Ausführungsstatus.

LoadModule dispatcher_module modules/mod_dispatcher.so

Um das Modul in unserem </VirtualHost> zu verwenden, legen wir eine Konfigurationsdatei in /etc/httpd/conf.d/ mit dem Namen dispatcher_vhost.conf ab und in dieser Datei sehen Sie, wie Sie die grundlegenden Parameter einrichten, die für das Modul erforderlich sind, um zu funktionieren:

<IfModule disp_apache2.c>
DispatcherConfig conf.dispatcher.d /dispatcher .any
...SNIP...
</IfModule>

Wie Sie oben sehen können, enthält dies die Datei "dispatcher.any"der obersten Ebene, damit unser Dispatcher-Modul seine Konfigurationsdateien von /etc/httpd/conf.dispatcher.d/dispatcher.any abruft

Beachten Sie den Inhalt dieser Datei:

/farms {
 $include "enabled_farms/*_farm.any"
}

Die Datei "dispatcher.any"auf oberster Ebene enthält alle aktivierten Farm-Dateien, die in "/etc/httpd/conf.dispatcher.d/enabled_farms/"leben, mit dem Dateinamen "<FILENAME>_farm.any", was unserer standardmäßigen Namenskonvention entspricht.

Später in der zuvor erwähnten dispatcher_vhost.conf-Datei führen wir auch eine Include-Anweisung aus, um jede aktivierte virtuelle Host-Datei zu aktivieren, die in /etc/httpd/conf.d/enabled_vhosts/ mit dem Dateinamen <FILENAME>.vhost live ist, was unserer standardmäßigen Namenskonvention entspricht.

IncludeOptional /etc/httpd/conf.d/enabled_vhosts/*.vhost

In jeder unserer .vhost-Dateien werden Sie feststellen, dass das Dispatcher-Modul als Standard-Datei-Handler für ein Verzeichnis initialisiert wird. Im Folgenden finden Sie eine Beispieldatei mit der Syntax:

<VirtualHost *:80>
 ServerName "weretail"
 ServerAlias www.weretail.com weretail.com
 <Directory />
 <IfModule disp_apache2.c>
 ....SNIP....
 SetHandler dispatcher-handler
 </IfModule>
 ....SNIP....
 </Directory>
 ....SNIP....
</VirtualHost>

Nachdem die oberste Ebene aufgelöst wurde, verfügen sie über weitere Untereinschlüsse, die erwähnt werden sollten. Hier finden Sie ein Diagramm auf hoher Ebene darüber, wie Farb- und Vhost-Dateien andere Unterelemente enthalten

C. AMS Virtual Host enthält

Wenn *.vhost-Dateien aus dem Verzeichnis /etc/httpd/conf.d/availabled_vhosts/ mit dem Verzeichnis /etc/httpd/conf.d/enabled_vhosts/ verknüpft werden, werden sie in der laufenden Konfiguration verwendet.

Die .vhost-Dateien enthalten Untereinträge, die auf gemeinsamen Elementen basieren, die wir gefunden haben. Dinge wie Variablen, Whitelists und Neuschreibungsregeln.

Die .vhost-Datei enthält Anweisungen für jede Datei, je nachdem, wo sie in die .vhost-Datei aufgenommen werden muss. Im Folgenden finden Sie eine Beispielsyntax einer Vhost-Datei als Referenz:

Include /etc/httpd/conf .d /variables/weretail .vars VirtualHost *:80
ServerName "${MAIN_DOMAIN}"
Directory / Include /etc/httpd/conf .d /whitelists/weretail *_whitelist.rules
IfModule disp_apache2.c
....SNIP....
SetHandler dispatcher-handler
/IfModule
....SNIP....
/Directory
....SNIP....
IfModule mod_rewrite.c
ReWriteEngine on
LogLevel warn rewrite:trace1
Include /etc/httpd/conf .d /rewrites/weretail_rewrite .rules
/IfModule /VirtualHost

Wie Sie im obigen Beispiel sehen können, gibt es einen Einschluss für die Variablen, die in dieser Konfigurationsdatei benötigt werden und später verwendet werden.

In der Datei /etc/httpd/conf.d/variables/weretail.vars können wir sehen, welche Variablen definiert sind:

Define MAIN_DOMAIN dev.weretail.com

Sie können auch eine Zeile sehen, die eine Liste von "whitelist.rules"-Dateien enthält, die beschränken, wer diesen Inhalt basierend auf verschiedenen Kriterien der Whitelist anzeigen kann. Betrachten wir den Inhalt einer der Whitelist-Dateien /etc/httpd/conf.d/whitelists/weretail_mainoffice_whitelist.rules:

<RequireAny>
 Require ip 192.150.16.0/23
</RequireAny>

Sie können auch eine Zeile sehen, die einen Satz von Neuschreibungsregeln enthält. Sehen wir uns den Inhalt der Datei weretail_rewrite.rules an:

RewriteRule /robots.txt$ /content/dam/weretail/robots.txt [ NC,PT]
RewriteCond %{SERVER_NAME} brand1.weretail.net [ NC]
RewriteRule /favicon.ico$ /content/dam/weretail/favicon.ico [ NC,PT]
RewriteCond %{SERVER_NAME} brand2.weretail.com [ NC]
RewriteRule /sitemap.xml$ /content/weretail/general/sitemap.xml [ NC,PT]
RewriteRule /logo.jpg$ /content/dam/weretail/general/logo.jpg [ NC,PT]

D. AMS Farm Includes

Wenn <FILENAME>_farm.any -Dateien aus dem Verzeichnis /etc/httpd/conf.dispatcher.d/available_farms/ mit dem Verzeichnis /etc/httpd/conf.dispatcher.d/enabled_farms/ verknüpft werden, werden sie in der laufenden Konfiguration verwendet.

Die Farm-Dateien enthalten Untereinträge, die auf den obersten Abschnitten der Farm basieren, wie Cache, Clientheaders, Filtern, Rendering und Vhosts.

Die <FILENAME>_farm.any -Dateien enthalten Anweisungen für jede Datei, je nachdem, wo sie in die Farm-Datei aufgenommen werden müssen. Im Folgenden finden Sie eine Beispielsyntax einer <FILENAME>_farm.any -Datei als Referenz:

/weretailfarm {
 /clientheaders {
 $include "/etc/httpd/conf.dispatcher.d/clientheaders/ams_publish_clientheaders.any"
 $include "/etc/httpd/conf.dispatcher.d/clientheaders/ams_common_clientheaders.any"
 }
 /virtualhosts {
 $include "/etc/httpd/conf.dispatcher.d/vhosts/weretail_vhosts.any"
 }
 /renders {
 $include "/etc/httpd/conf.dispatcher.d/renders/ams_publish_renders.any"
 }
 /filter {
 $include "/etc/httpd/conf.dispatcher.d/filters/ams_publish_filters.any"
 $include "/etc/httpd/conf.dispatcher.d/filters/weretail_search_filters.any"
 }
 ....SNIP....
 /cache {
 ....SNIP....
 /rules {
 $include "/etc/httpd/conf.dispatcher.d/cache/ams_publish_cache.any"
 }
 ....SNIP....
 /allowedClients {
 /0000 {
 /glob "*.*.*.*"
 /type "deny"
 }
 $include "/etc/httpd/conf.dispatcher.d/cache/ams_publish_invalidate_allowed.any"
 }
 ....SNIP....
 }
}

Wie Sie sehen können, verwenden Sie stattdessen eine Include-Anweisung, anstatt die gesamte benötigte Syntax für die Weretail-Farm zu verwenden.

Sehen wir uns die Syntax einiger dieser Includes an, um zu erfahren, wie die einzelnen Unter-Includes wie /etc/httpd/conf.dispatcher.d/vhosts/weretail_publish_vhosts.any aussehen würden:

"brand1.weretail.com"
"brand2.weretail.com"
"www.weretail.comf"

Wie Sie sehen, ist es eine neue, durch Zeilen getrennte Liste von Domänennamen, die von dieser Farm über die anderen gerendert werden sollen.

Als Nächstes sehen wir uns die /etc/httpd/conf.dispatcher.d/filters/weretail_search_filters.any an:

/400 { /type "allow" /method "GET" /path "/bin/weretail/lists/*" /extension "json" }
/401 { /type "allow" /method "POST" /path "/bin/weretail/search/" /extension "html" }
recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f