Explication des fichiers de configuration | AEM

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 d’affectation des noms, etc.

Convention d’affectation de nom

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. Nous voulons é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/

Fichiers contenus dans conf.modules.d/

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.

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

Comment 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

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

• 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ègles de liste autorisée 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 d’affectation de noms 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 ; ils mettent simplement à jour les règles de réécriture comme indiqué par le nom de 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

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.

En partant de la ligne de base d’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

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 "< 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 "< 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

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 placer sur la liste autorisée.rules qui limitent qui peut afficher ce contenu en fonction de différents critères de liste autorisée. Examinons le contenu d’un des fichiers de liste autorisée. /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

Lorsque "< FILENAME> _farm.any fichiers provenant de /etc/httpd/conf.dispatcher.d/available_farms/ créer un lien symbolique dans le répertoire /etc/httpd/conf.dispatcher.d/enabled_farms/ Ils seront utilisés dans la configuration en cours d’exécution.

Les fichiers de fermes comportent des sous-inclusions basées sur sections de niveau supérieur de la ferme de serveurs comme cache, clientheaders, filtres, rendus et vhosts.

Le <` FILENAME`>` _farm.any` files will have include statements for each file based on where they need to be included in the farm file. Here is an example syntax of a < 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 voir chaque section pour la ferme de serveurs weretail au lieu de disposer de toutes les syntaxes nécessaires, elle utilise plutôt une instruction d’inclusion.

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 ferme de serveurs par rapport aux 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" }

Ressources Business.Adobe.com