Fichier
Dernière mise à jour le
2021-05-02
Ce document décompose et explique chacun des fichiers de configuration déployés dans un serveur répartiteur standard créé et fourni par Adobe Managed Services. Leur utilisation, leur convention d’appellation, etc.
🔙Précédent Mise en page de base du fichier
Convention d’appellation
Le serveur web Apache ne tient pas compte de l’extension d’un fichier lorsqu’il le cible avec une instruction d’inclusion ou includeoptional. Il est utile de le nommer correctement avec des noms évitant les conflits et la confusion. Les noms utilisés décrivent l’étendue de l’application du fichier, ce qui facilite la vie. Si tout porte le nom .conf, cela devient vraiment confus. Nous voulons éviter les extensions et les fichiers mal nommés. Vous trouverez ci-dessous une liste des différentes extensions de fichier personnalisées et des conventions d’appellation utilisées dans un répartiteur typique configuré par AMS.
Fichiers contenus dans conf.d/
|
|
Description du fichier |
Description |
|---|---|---|
|
<NOMDEFICHIER>.conf |
/etc/httpd/conf.d/ |
Une installation par défaut d’Enterprise Linux fait usage de cette extension de fichier et inclut le dossier comme emplacement pour remplacer les paramètres dans httpd.conf. De plus, elle vous permet d’ajouter d’autres fonctionnalités de façon globale dans Apache. |
|
<NOMDEFICHIER>.vhost |
Test : /etc/httpd/conf.d/available_vhosts/ Activation : /etc/httpd/conf.d/enabled_vhosts/ *Remarque : les fichiers .vhost ne doivent pas être copiés dans le dossier enabled_vhosts, il faut utiliser des liens symboliques vers un chemin relatif au fichier available_vhosts/ .vhost
|
Les fichiers *.vhost (Virtual Host) sont des entrées <VirtualHosts > qui correspondent aux noms d’hôtes et permettent à Apache de gérer le trafic de chaque domaine avec des règles différentes. À partir du fichier .vhost, d’autres fichiers comme les réécritures, les listes blanches seront inclus. |
|
<NOMDEFICHIER>_rewrite.rules |
/etc/httpd/conf.d/rewrites/ |
Les fichiers *_rewrite.rules conservent les règles mod_rewrite à inclure et à utiliser explicitement par un fichier vhost. |
|
<NOMDEFICHIER>_whitelist.rules |
/etc/httpd/conf.d/whitelists/ |
Les fichiers *_ipwhitelist.rules sont inclus dans les fichiers *.vhost. Il contient un regex des adresses IP ou autorise les règles de refus pour activer le whitelistage des adresses IP. Si vous essayez de réduire 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 |
|---|---|---|
|
<NOMDEFICHIER>.any |
/etc/httpd/conf.dispatcher.d/ |
Le module du Dispatcher AEM pour Apache extrait ses paramètres des fichiers *.any. Le fichier d’inclusion parent par défaut est conf.dispatcher.d/dispatcher.any. |
|
<NOMDEFICHIER>_farm.any |
Test : /etc/httpd/conf.dispatcher.d/available_farms/ Activation : /etc/httpd/conf.dispatcher.d/enabled_farms/ *Remarque : ces fichiers de ferme 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 ferme parents servent à contrôler le comportement des modules pour chaque type de rendu ou de site web. Les fichiers sont créés dans le répertoire available_farms et activés par un lien symbolique dans le répertoire enabled_farms.
Il les inclut automatiquement par nom dans le fichier dispatcher.any.
Les fichiers de ferme de la ligne de base commencent par 000_ pour qu’ils puissent être chargés en premier. Les fichiers de ferme personnalisés, dont le modèle de numéro commence par 100_, doivent être chargés par la suite pour assurer le bon comportement d’inclusion. |
|
<NOMDEFICHIER>_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 ferme dispose d’un ensemble de règles permettant de modifier le trafic à filtrer et de ne pas l’acheminer vers les moteurs de rendu. |
|
<NOMDEFICHIER>_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 URI à associer par correspondance de blob pour déterminer le moteur de rendu à utiliser lors du traitement de cette requête. |
|
<NOMDEFICHIER>_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. |
|
<NOMDEFICHIER>_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 quelles adresses IP sont autorisées à envoyer des requêtes de purge et d’invalidation. |
|
<NOMDEFICHIER>_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 quels en-têtes clients doivent être transmis à chaque moteur de rendu. |
|
<NOMDEFICHIER>_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 des adresses IP, du port et le délai d’expiration pour chaque moteur de rendu. Un bon moteur de rendu peut être un serveur LiveCycle ou n’importe quel système AEM sur lequel le répartiteur peut récupérer/transmettre les requêtes. |
Problèmes évités
En suivant la convention d’appellation, vous pouvez éviter certaines erreurs assez faciles à commettre qui peuvent avoir des conséquences graves. Nous vous présenterons quelques exemples.
Exemple de problème
En tant qu’exemple de site pour ExampleCo, deux fichiers de configuration ont été créés par les développeurs des configurations du répartiteur.
/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]
Risque potentiel
Les noms de fichiers sont les mêmes
Si le fichier vhost est accidentellement placé dans le dossier rewrites et que le fichier rewrites est placé dans le dossier vhosts. Le déploiement par nom de fichier semble correct, mais Apache produira une erreur et le problème ne se présentera pas immédiatement.
En quoi cela devient généralement un problème
Si les deux fichiers sont téléchargés au même emplacement, ils peuvent soit s’écraser, soit devenir indissociables, si bien que le processus de déploiement en devient un véritable cauchemar.
Les extensions de fichiers sont les mêmes et sont sujettes à l’auto-inclusion
Les extensions de fichiers sont les mêmes et utilisent l’extension d’auto-inclusion de sorte qu’Apache inclut automatiquement tout fichier .conf dans la plupart de ses dossiers par défaut.
En quoi cela devient généralement un problème
Si le fichier vhost avec l’extension .conf est placé dans le dossier /etc/httpd/conf.d/, ce dernier essaiera de le charger dans la mémoire sur Apache, ce qui fonctionne généralement bien. Cependant, si le fichier de règles de réécriture avec l’extension .conf est placé dans le dossier /etc/httpd/conf.d/, il sera automatiquement inclus et s’appliquera dans sa totalité, provoquant ainsi des résultats contradictoires et peu souhaitables.
Solution proposée
Nommez les fichiers selon leur fonction et en toute sécurité hors de l’espace de nommage des règles d’auto-inclusion.
S’il s’agit d’un fichier d’hôte virtuel, nommez-le avec l’extension .vhost.
S’il s’agit d’un fichier de règles de réécriture, nommez-le en utilisant <site>_rewrite.rules comme suffixe et extension. Grâce à cette convention d’appellation, vous saurez précisément qu’il s’agit d’un ensemble de règles de réécriture et vous connaîtrez le site auquel il est destiné.
S’il s’agit d’un fichier de règles de la liste blanche des adresses IP, nommez-le en utilisant <description>_whitelist.rules comme suffixe et extension. Grâce à cette convention d’appellation, vous obtiendrez une description de sa fonction et vous saurez qu’il s’agit d’un ensemble de règles de correspondance des adresses IP.
L’utilisation de ces conventions d’appellation permettra d’éviter les problèmes si un fichier est déplacé dans un répertoire d’auto-inclusion auquel il n’appartient pas.
Par exemple, placer un fichier nommé contenant . rules, .any, ou .vhost dans le dossier d’auto-inclusion /etc/httpd/conf.d/ n’aurait aucun effet.
Si une demande de modification du déploiement indique "please deploy exampleco_rewrite.rules to production dispatchers" (veuillez déployer exampleco_rewrite.rules aux répartiteurs de production), la personne qui déploie les modifications peut déjà savoir qu’elle n’ajoute pas un nouveau site. Elle met simplement à jour les règles de réécriture comme indiqué par le nom du fichier.
Inclure la commande
Lors de l’extension des fonctionnalités et des configurations du serveur web Apache installé sur Enterpise Linux, il est important de comprendre certaines commandes d’inclusion.
Inclusions de la ligne de base Apache
Comme le montre le diagramme ci-dessus, le binaire httpd ne prend en compte que le fichier httpd.conf comme fichier de configuration. Ce fichier contient les instructions suivantes :
Include conf.modules.d/*.conf IncludeOptional conf.d/*.conf
Inclusions de niveau supérieur AMS
Lorsque nous avons appliqué notre norme, nous avons ajouté d’autres types de fichiers et inclus nos propres fichiers.
Voici les répertoires de la ligne de base et les inclusions de niveau supérieur AMS
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 les dossiers conf.d ainsi que pour les répertoires spécifiques aux modules imbriqués dans /etc/httpd/conf.dispatcher.d/.
Quand Apache charge, il extrait le fichier /etc/httpd/conf.modules.d/02-dispatcher.conf. Celui-ci contient 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éposons un fichier de configuration dans /etc/httpd/conf.d/ nommé dispatcher_vhost.conf. Dans ce fichier, vous verrez comment configurer les paramètres fondamentaux 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 pour notre module du répartiteur afin de récupérer ses fichiers de configuration dans /etc/httpd/conf.dispatcher.d/dispatcher.any.
Prenez en compte le contenu de ce fichier :
/farms {
$include "enabled_farms/*_farm.any"
}
Le fichier dispatcher.any de niveau supérieur contient tous les fichiers de ferme activés qui se trouvent dans /etc/httpd/conf.dispatcher.d/enabled_farms/ avec le nom de fichier <NOMDEFICHIER>_farm.any qui suit notre convention d’appellation standard.
Plus loin dans le fichier dispatcher_vhost.conf mentionné précédemment, nous ajoutons également une instruction d’inclusion pour activer chaque fichier d’hôte virtuel activé se trouvant dans /etc/httpd/conf.d/enabled_vhosts/ avec le nom de fichier <NOMDEFICHIER>.vhost qui suit notre convention d’appellation standard.
IncludeOptional /etc/httpd/conf.d/enabled_vhosts/*.vhost
Dans chacun de nos fichiers .vhost, vous remarquerez que le module du répartiteur est initialisé comme un gestionnaire de fichiers par défaut pour un répertoire. Voici un exemple de fichier .vhost qui montre 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>
Après la résolution des inclusions de niveau supérieur, celles-ci ont d’autres sous-inclusions qui valent la peine d’être mentionnées. Voici un diagramme de haut niveau illustrant la façon dont les fichiers de ferme et vhost incluent d’autres sous-éléments
Inclusions des hôtes virtuels AMS
Quand un fichier .vhost du répertoire /etc/httpd/conf.d/availabled_vhosts/ est lié par un lien symbolique dans le répertoire /etc/httpd/conf.d/enabled_vhosts/, il est utilisé dans la configuration en cours.
Les fichiers .vhost ont des sous-inclusions basées sur des éléments communs que nous avons trouvés. Par exemple, les variables, les listes blanches et les règles de réécriture.
Le fichier .vhost contiendra des instructions pour chaque fichier selon l’endroit où il doit être inclus dans le fichier .vhost. En guise de référence, voici un exemple de syntaxe d’un fichier .vhost :
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 y a 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 quelles variables sont définies :
Define MAIN_DOMAIN dev.weretail.com
Vous pouvez également voir une ligne incluant une liste de fichiers whitelist.rules qui limitent l’accès à ce contenu en fonction de différents critères de la liste blanche. Regardons le contenu d’un des fichiers de la 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 inclut un ensemble de règles de réécriture. Regardons le contenu du fichier weretail_rewrite.rules :
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]
Inclusions de la ferme AMS
Quand un fichier <NOMDEFICHIER>_farm.any du répertoire /etc/httpd/conf.dispatcher.d/available_farms/ est lié par un lien symbolique dans le répertoire /etc/httpd/conf.dispatcher.d/enabled_farms/, il est utilisé dans la configuration en cours.
Les fichiers de la ferme ont des sous-inclusions basées sur les sections de niveau supérieur de la ferme comme le cache, les en-têtes clients, les filtres, les rendus et les fichiers vhosts.
Les fichiers <NOMDEFICHIER>_farm.any contiendront des instructions pour chaque fichier selon l’endroit où ils doivent être inclus dans le fichier de la ferme. En guise de référence, voici un exemple de syntaxe d’un fichier <NOMDEFICHIER>_farm.any :
/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 constater, chaque section de la ferme weretail n’a pas la syntaxe nécessaire. Elle utilise plutôt une instruction d’inclusion.
Examinons la syntaxe de quelques-unes de ces inclusions pour avoir une idée de l’apparence de chaque sous-inclusions.
/etc/httpd/conf.dispatcher.d/vhosts/weretail_publish_vhosts.any :
"brand1.weretail.com" "brand2.weretail.com" "www.weretail.comf"
Comme vous pouvez le voir, il s’agit d’une liste de noms de domaine séparée par une nouvelle ligne qui devrait effectuer le rendu à partir de cette ferme sur les autres.
Regardons maintenant le fichier /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" }
Suivant ➡ Présentation du cache
Accéder à votre compte