Explication des fichiers de configuration | AEM

Explorez une ventilation détaillée des fichiers de configuration dans le serveur Dispatcher d’Adobe Managed Services. Découvrez leur signification, leurs conventions de dénomination et leurs applications pratiques.

Description description

Environnement

Experience Manager

Problème/Symptômes

Ce document présente la ventilation et l’explication de chacun des fichiers de configuration déployés dans un serveur Dispatcher standard intégré configuré dans Adobe Managed Services. Leur utilisation, convention de dénomination, etc.

Convention d’appellation

Apache Webserver ne se soucie pas vraiment de l’extension de fichier d’un fichier lorsqu’il est ciblé avec une instruction d’inclusion ou d’inclusion facultative. Nommer correctement les noms avec des noms qui éliminent les conflits et la confusion aide une tonne. Les noms utilisés décrivent la portée de l’application du fichier, ce qui facilite la vie. Si tout s’appelle .conf, cela devient vraiment déroutant. Mieux vaut éviter les fichiers et les extensions mal nommés.

Vous trouverez ci-dessous une liste des différentes extensions de fichier personnalisées et des conventions d’affectation de nom utilisées dans un dispatcher configuré par AMS classique.

Fichiers contenus dans conf.d/

Fichier
Description du fichier
Description
< FILENAME> .conf
/etc/httpd/conf.d/
Une installation Enterprise Linux par défaut utilise cette extension de fichier et inclut le dossier comme emplacement pour remplacer les paramètres dans httpd.conf et vous permettre d’ajouter des fonctionnalités supplémentaires à un niveau global dans Apache.
< FILENAME> .vhost

Mise en scène : /etc/httpd/conf.d/available_vhosts/

Actif :

/etc/httpd/conf.d/enabled_vhosts/

*Remarque : les fichiers .vhost ne doivent pas être copiés dans le dossier enabled_vhosts, mais utiliser des liens symboliques vers un chemin relatif au fichier available_vhosts/ .vhost

Les fichiers *.vhost (Virtual Host) sont < VirtualHosts >  des entrées correspondant aux noms d’hôtes et permettant à Apache de gérer chaque trafic de domaine avec des règles différentes. À partir du fichier .vhost, d’autres fichiers tels que les réécritures, la mise en whiteliste, etc. seront inclus.
< FILENAME> _rewrite.rules
/etc/httpd/conf.d/rewrites/
*_rewrite.rules magasin de fichiers mod_rewrite règles à inclure et à utiliser explicitement par un fichier vhost
< FILENAME> _whitelist.rules
/etc/httpd/conf.d/whitelists/
*_Les fichiers ipwhitelist.rules sont inclus dans les fichiers *.vhost. Ils contiennent une expression régulière d’IP ou des règles d’autorisation et de refus pour permettre l’établissement d’une liste autorisée d’IP. Si vous essayez de restreindre l’affichage d’un hôte virtuel en fonction des adresses IP, vous allez générer l’un de ces fichiers et l’inclure à partir de votre fichier *.vhost .

Fichiers contenus dans conf.modules.d/

Fichier
Description du fichier
Description
< FILENAME> .any
/etc/httpd/conf.dispatcher.d/
Le module Apache de Dispatcher AEM source ses paramètres à partir de fichiers *.any. Le fichier d’inclusion parent par défaut est conf.dispatcher.d/dispatcher.any
< FILENAME> _farm.any

Intermédiaire

:

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

Actif

:

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

*Remarque : ces fichiers de fermes ne doivent pas être copiés dans le dossier enabled_farms, mais utiliser des liens symboliques vers un chemin relatif au fichier available_farms/ _farm.any.

*Les fichiers farm.any sont inclus dans le fichier conf.dispatcher.d/dispatcher.any . Ces fichiers de batterie parents sont destinés à contrôler le comportement du module pour chaque type de rendu ou de site web. Les fichiers sont créés dans le répertoire available_farms et activés avec un lien symbolique dans le répertoire enabled_farms.

Elle les inclut automatiquement par nom à partir du fichier dispatcher.any.

Les fichiers de ferme de ligne de base commencent par 000
pour vous assurer qu’elles sont chargées en premier.

Les fichiers de fermes personnalisés doivent être chargés après en lançant leur modèle numérique à 100_ afin d’assurer le comportement d’inclusion approprié.
< FILENAME> _filters.any
/etc/httpd/conf.dispatcher.d/filters/
*_Les fichiers filters.any sont inclus dans les fichiers conf.dispatcher.d/enabled_farms/*_farm.any. Chaque batterie comporte un ensemble de règles qui indiquent le trafic qui doit être filtré et ne doit pas atteindre les moteurs de rendu.
< FILENAME> _vhosts.any
/etc/httpd/conf.dispatcher.d/vhosts/
*_Les fichiers vhosts.any sont inclus dans les fichiers conf.dispatcher.d/enabled_farms/*_farm.any. Ces fichiers sont une liste de noms d’hôtes ou de chemins d’accès URI à mettre en correspondance avec des objets blob pour déterminer le moteur de rendu à utiliser pour diffuser cette requête.
< FILENAME> _cache.any
/etc/httpd/conf.dispatcher.d/cache/
*_Les fichiers cache.any sont inclus dans les fichiers conf.dispatcher.d/enabled_farms/*_farm.any. Ces fichiers spécifient les éléments qui sont mis en cache et ceux qui ne le sont pas.
< FILENAME> _invalidate_allowed.any
/etc/httpd/conf.dispatcher.d/cache/
*_les fichiers invalidate_allowed.any sont inclus dans les fichiers conf.dispatcher.d/enabled_farms/*_farm.any. Ils spécifient les adresses IP autorisées à envoyer des demandes de purge et d’invalidation.
< FILENAME> _clientheaders.any
/etc/httpd/conf.dispatcher.d/clientheaders/
*_les fichiers clientheaders.any sont inclus dans les fichiers conf.dispatcher.d/enabled_farms/*_farm.any. Ils spécifient les en-têtes clients à transmettre à chaque moteur de rendu.
< FILENAME> _renders.any
/etc/httpd/conf.dispatcher.d/renders/
*_Les fichiers renders.any sont inclus dans les fichiers conf.dispatcher.d/enabled_farms/*_farm.any. Ils spécifient les paramètres d’IP, de port et de délai d’expiration pour chaque moteur de rendu. Un moteur de rendu correct peut être un serveur LiveCycle ou tout système AEM sur lequel Dispatcher peut récupérer/remplacer les requêtes de

Problèmes évités

Lorsque vous suivez la convention de dénomination, vous pouvez éviter des erreurs assez faciles à commettre qui peuvent avoir des résultats catastrophiques. Nous allons en présenter quelques exemples.

Exemple de problème

Comme exemple de site pour ExampleCo, deux fichiers de configuration ont été créés par les développeurs des configurations du Dispatcher.

/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]

DANGER POTENTIEL

A. Les noms des fichiers sont identiques

Si le fichier vhost est accidentellement placé dans le dossier rewrites et que le fichier rewrites est placé dans le dossier vhosts. Il semble être déployé correctement par nom de fichier, mais Apache renvoie une erreur et le problème ne sera pas immédiatement visible.

En quoi cela devient-il généralement un problème ?

Si les deux fichiers sont téléchargés au même emplacement, ils peuvent soit s’écraser eux-mêmes, soit les rendre impossibles à distinguer, ce qui fait du processus de déploiement un cauchemar.

B. Les extensions de fichier sont les mêmes et sujettes à l’inclusion automatique

Les extensions de fichier sont les mêmes et utilisent l’extension auto-include qu’Apache va automatiquement inclure tous les fichiers .conf dans la plupart de ses dossiers par défaut.

En quoi cela devient-il généralement un problème ?

Si le fichier vhost avec l’extension .conf est placé dans le dossier /etc/httpd/conf.d/ , il tentera de le charger en mémoire sur Apache, ce qui est généralement correct, mais si le fichier de règles de réécriture avec l’extension .conf est placé dans la variable /etc/httpd/conf.d/ , il sera inclus automatiquement et appliqué globalement, ce qui provoquera des résultats déroutants et indésirables.

Résolution resolution

Nommez les fichiers en fonction de ce qu’ils font et maintenez-les en dehors de l’espace de noms des règles d’inclusion automatique pour une sécurité optimale.

  • S’il s’agit d’un nom de fichier d’hôte virtuel, utilisez .vhost comme extension.
  • S’il s’agit d’un fichier de règle de réécriture, nommez-le par <site>_rewrite.rules comme suffixe et extension. Cette convention d’affectation des noms indique clairement à quel site il sert et qu’il s’agit d’un ensemble de règles de réécriture.
  • S’il s’agit d’un fichier de règle de liste blanche d’adresses IP, nommez-le. <description>_whitelist.rules comme suffixe et extension. Cette convention d’affectation des noms donne une description de son utilité et indique qu’il s’agit d’un ensemble de règles de correspondance d’adresses IP.

L’utilisation de ces conventions de nommage permet d’éviter des problèmes si un fichier est déplacé dans un répertoire d’inclusion automatique auquel il n’appartient pas.

Par exemple, pour placer un fichier nommé avec .rules, .any ou .vhost dans le dossier d’inclusion automatique de /etc/httpd/conf.d/ n'aurait aucun effet.

Si une requête de modification de déploiement indique please deploy exampleco_rewrite.rules to production dispatchers la personne qui déploie les modifications peut déjà savoir qu’elle n’ajoute pas de nouveau site ; elle met simplement à jour les règles de réécriture comme indiqué par le nom du fichier.

Inclure la commande

Lorsque vous étendez des fonctionnalités et des configurations dans le serveur web Apache installé sur Enterprise Linux, vous disposez d’éléments importants. inclure des commandes ; tu voudras comprendre.

A. Inclusions de la ligne de base Apache

ordre d’inclusion de la ligne de base apache. Le binaire apache commence par httpd.conf qui effectue une inclusion facultative dans conf.d/*.conf et conf.modules.d/* Répertoires .conf

Comme le montre le diagramme ci-dessus, le binaire httpd ne regarde que le fichier httpd.conf comme fichier de configuration. Ce fichier contient les instructions suivantes :

Include conf.modules.d/*.conf

IncludeOptional conf.d/*.conf

B. Inclusions de niveau supérieur AMS

Lorsque nous avons appliqué notre norme, nous avons ajouté d’autres types de fichiers et inclus les nôtres.

Voici les répertoires de base AMS et les inclusions de niveau supérieur.

La ligne de base AMS comprend un fichier dispatcher_vhost.conf qui inclura n’importe quel fichier avec le *.vhost du répertoire /etc/httpd/conf.d/enabled_vhosts/ . Les éléments du répertoire /etc/httpd/conf.d/enabled_vhosts/ sont des liens symboliques vers le fichier de configuration réel qui se trouve dans /etc/httpd/conf.d/available_vhosts/

En partant de la ligne de base Apache, nous montrons comment AMS a créé des dossiers supplémentaires et des inclusions de niveau supérieur pour conf.d ainsi que les répertoires spécifiques aux modules imbriqués sous /etc/httpd/conf.dispatcher.d/

Lorsque Apache charge, il extrait la variable /etc/httpd/conf.modules.d/02-dispatcher.conf et ce fichier inclut le fichier binaire. /etc/httpd/modules/mod_dispatcher.so dans son état d'exécution.

LoadModule dispatcher_module modules/mod_dispatcher.so

Pour utiliser le module dans notre </VirtualHost> nous déposerons un fichier de configuration dans /etc/httpd/conf.d/ named dispatcher_vhost.conf et dans ce fichier, vous verrez utiliser configuration des paramètres de base nécessaires au fonctionnement du module :

<IfModule disp_apache2.c>

DispatcherConfig conf.dispatcher.d /dispatcher .any

...SNIP...

</IfModule>

Comme vous pouvez le voir ci-dessus, cela inclut le fichier dispatcher.any de niveau supérieur de notre module de Dispatcher pour récupérer ses fichiers de configuration à partir de /etc/httpd/conf.dispatcher.d/dispatcher.any

Prêtez attention au contenu de ce fichier :

/farms {

   $include "enabled_farms/*_farm.any"

}

Le fichier dispatcher.any de niveau supérieur comprend tous les fichiers de fermes activés qui se trouvent dans /etc/httpd/conf.dispatcher.d/enabled_farms/ avec le nom de fichier de <FILENAME>_farm.any qui suit notre convention de dénomination standard.

Plus tard dans la dispatcher_vhost.conf fichier mentionné précédemment, nous faisons également une instruction d’inclusion pour activer chaque fichier d’hôte virtuel activé qui se trouve dans /etc/httpd/conf.d/enabled_vhosts/ avec le nom de fichier de <FILENAME>.vhost qui suit notre convention de dénomination standard.

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

Dans chacun de nos fichiers .vhost, vous remarquerez que le module dispatcher est initialisé en tant que gestionnaire de fichiers par défaut pour un répertoire. Voici un exemple de fichier .vhost pour afficher la syntaxe :

<VirtualHost *:80>

    ServerName    "weretail"

    ServerAlias www.weretail.com weretail.com

    <Directory />

        <IfModule disp_apache2.c>

            ....SNIP....

            SetHandler dispatcher-handler

        </IfModule>

        ....SNIP....

    </Directory>

    ....SNIP....

</VirtualHost>

Une fois que les inclusions de niveau supérieur sont résolues, elles comportent d’autres sous-inclusions qui méritent d’être mentionnées. Voici un diagramme de haut niveau sur la manière dont les fichiers de fermes de serveurs et vhosts incluent d’autres sous-éléments.

C. Inclusions d’hôte virtuel AMS

les hôtes virtuels ams incluent des sous-éléments. Cette image montre comment un fichier .vhost inclut des fichiers provenant de variables, de listes blanches et réécrit des dossiers.

Lorsque des fichiers .vhost proviennent de /etc/httpd/conf.d/availabled_vhosts/ créer un lien symbolique dans le répertoire /etc/httpd/conf.d/enabled_vhosts/ Ils seront utilisés dans la configuration en cours d’exécution.

Les fichiers .vhost comportent des sous-inclusions basées sur les éléments communs que nous avons trouvés.Il s’agit de variables, de listes autorisées et de règles de réécriture.

Le fichier .vhost comporte des instructions d’inclusion pour chaque fichier en fonction de l’endroit où il doit être inclus dans le fichier .vhost.  Voici un exemple de syntaxe d’un fichier .vhost comme référence appropriée :

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

Comme vous pouvez le voir dans l’exemple ci-dessus, il existe une inclusion pour les variables nécessaires dans ce fichier de configuration qui sont utilisées ultérieurement.

Dans le fichier /etc/httpd/conf.d/variables/weretail.vars nous pouvons voir les variables qui sont définies :

Define MAIN_DOMAIN dev.weretail.com

Vous pouvez également voir une ligne qui contient une liste de fichiers whitelist.rules qui restreignent les utilisateurs autorisés à afficher ce contenu en fonction de différents critères de liste blanche. Examinons le contenu d’un des fichiers de liste blanche. /etc/httpd/conf.d/whitelists/weretail_mainoffice_whitelist.rules:

<RequireAny>

  Require ip 192.150.16.0/23

</RequireAny>

Vous pouvez également voir une ligne qui comprend un ensemble de règles de réécriture. Regardons le contenu de la weretail_rewrite.rules fichier :

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. Inclusions de la ferme AMS

<FILENAME>_farms.any inclut des fichiers .any secondaires pour terminer la configuration de la batterie. Dans cette image, vous pouvez voir qu’une ferme de serveurs va inclure chaque cache de fichiers de section de niveau supérieur, les en-têtes clients, les filtres, les rendus et les fichiers vhosts .any.

Lorsque des fichiers <FILENAME>_farm.any provenant du référentiel /etc/httpd/conf.dispatcher.d/available_farms/ sont liés par un lien symbolique au répertoire /etc/httpd/conf.dispatcher.d/enabled_farms/, ils sont utilisés dans la configuration en cours d’exécution.

Les fichiers de batterie comportent des sous-inclusions basées sur les sections de niveau supérieur de la batterie, comme le cache, les en-têtes clients, les filtres, les rendus et les fichiers vhosts.

Les fichiers <FILENAME>_farm.any contiennent des instructions pour chaque fichier en fonction de l’endroit où ils doivent être inclus dans le fichier de batterie. Voici un exemple de syntaxe d’une <FILENAME>_farm.any comme référence appropriée :

/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....

    }

}

Comme vous pouvez le voir, chaque section de la batterie weretail utilise une instruction d’inclusion au lieu de contenir toute la syntaxe nécessaire.

Examinons la syntaxe de quelques-unes de ces inclusions pour avoir une idée de ce à quoi ressemblerait chaque sous-inclusion. /etc/httpd/conf.dispatcher.d/vhosts/weretail_publish_vhosts.any:

"brand1.weretail.com"

"brand2.weretail.com"

"www.weretail.comf"

Comme vous pouvez le constater, il s’agit d’une nouvelle liste de noms de domaine séparés par des lignes qui doivent être rendus à partir de cette batterie plutôt que par les autres.

Regardons ensuite le /etc/httpd/conf.dispatcher.d/filters/weretail_search_filters.any:

/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