Explicación de los archivos de configuración AEM

Explore un desglose detallado de los archivos de configuración en el servidor de Dispatcher de Adobe Managed Services. Descubra su significado, convenciones de nomenclatura y aplicaciones prácticas.

Descripción

Entorno

Experience Manager

Problema/Síntomas

Este documento desglosará y explicará cada uno de los archivos de configuración implementados en un servidor de Dispatcher creado de forma estándar y aprovisionado en Adobe Managed Services. Su uso, convención de nomenclatura, etc.

Convención de nomenclatura

A Apache Webserver en realidad no le importa cuál sea la extensión de archivo de un archivo al segmentarlo con una instrucción opcional include o includeinclude. Nombrarlos apropiadamente con nombres que eliminen los conflictos y la confusión ayuda mucho. Los nombres utilizados describirán el ámbito de aplicación del archivo, lo que facilita las cosas. Si todo se llama .conf, esto se vuelve muy confuso. Queremos evitar archivos y extensiones con nombres incorrectos.

A continuación se muestra una lista de las diferentes extensiones de archivo personalizadas y convenciones de nomenclatura utilizadas en un Dispatcher configurado de AMS típico.

Archivos incluidos en conf.d/

Archivos incluidos en conf.module.d/

Problemas evitados

Al seguir la convención de nombres, puede evitar algunos errores bastante fáciles de cometer que pueden tener resultados catastróficos. Vamos a ver algunos ejemplos.

Ejemplo de problema

Como ejemplo de sitio para ExampleCo, los desarrolladores de las configuraciones de Dispatcher crearon dos archivos de configuración.

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

POSIBLE PELIGRO

A. Los nombres de archivo son los mismos

Si el archivo vhost se coloca accidentalmente en la carpeta de reescritura y el archivo de reescritura se coloca en la carpeta vhosts. Parece que el nombre de archivo lo implementa correctamente, pero Apache generará un error y el problema no se mostrará inmediatamente.

¿Cómo se convierte esto en un problema?

Si los dos archivos se descargan en la misma ubicación, pueden sobrescribirse o hacerse indistinguibles, lo que convierte el proceso de implementación en una pesadilla.

B. Las extensiones de archivo son las mismas y propensas a la inclusión automática

Las extensiones de archivo son las mismas y utilizan la extensión incluida automáticamente, de modo que Apache incluirá automáticamente cualquier archivo .conf en muchas de sus carpetas predeterminadas.

¿Cómo se convierte esto en un problema?

Si el archivo vhost con la extensión .conf se coloca en la carpeta /etc/httpd/conf.d/ intentará cargarlo en la memoria en Apache, lo que suele ser correcto, pero si el archivo de reglas de reescritura con la extensión .conf se coloca en la carpeta /etc/httpd/conf.d/ , se incluirá automáticamente y se aplicará globalmente, lo que causará resultados confusos y no deseados.

Resolución

Asigne a los archivos un nombre basado en lo que hacen y de forma segura fuera del área de nombres de reglas de inclusión automática.

• Si se trata de un archivo host virtual, asígnele el nombre .vhost como extensión.
• Si se trata de un archivo de reglas de reescritura, asígnele el nombre <site>_rewrite.rules como el sufijo y la extensión. Esta convención de nombres aclarará para qué sitio es y que es un conjunto de reglas de reescritura.
• Si se trata de un archivo de regla de lista blanca de IP, asígnele un nombre <description>_whitelist.rules como el sufijo y la extensión. Esta convención de nombres le dará una descripción de para qué sirve y de que es un conjunto de reglas coincidentes de IP.

El uso de estas convenciones de nomenclatura evitará problemas si un archivo se mueve a un directorio de inclusión automática al que no pertenece.

Por ejemplo, al colocar un archivo denominado con .rules, .any o .vhost en la carpeta de inclusión automática de /etc/httpd/conf.d/ no tendría ningún efecto.

Si una solicitud de cambio de implementación indica please deploy exampleco_rewrite.rules to production dispatchers la persona que implementa los cambios ya puede saber que no está agregando un nuevo sitio; solo está actualizando las reglas de reescritura tal como indica el nombre de archivo.

Incluir pedido

Al ampliar la funcionalidad y las configuraciones en el servidor web Apache instalado en Enterprise Linux, tiene algunos incluir pedidos vas a querer entender.

A. La Línea Base Apache Incluye

Como se ve en el diagrama anterior, el binario httpd solo busca el archivo httpd.conf como su archivo de configuración. Ese archivo contiene las siguientes instrucciones:

Include conf.modules.d/*.conf

IncludeOptional conf.d/*.conf

B. El nivel superior de AMS incluye

Al aplicar nuestro estándar, añadimos algunos tipos de archivo adicionales e incluimos los nuestros.

Estos son los directorios de línea de base de AMS y las inclusiones de nivel superior

Basándonos en la línea de base de Apache, mostramos cómo AMS creó algunas carpetas adicionales e inclusiones de nivel superior para conf.d carpetas, así como directorios específicos de módulo anidados en /etc/httpd/conf.dispatcher.d/

Cuando apache se cargue, se abrirá el /etc/httpd/conf.modules.d/02-dispatcher.conf y ese archivo incluirá el archivo binario /etc/httpd/modules/mod_dispatcher.so en su estado de funcionamiento.

LoadModule dispatcher_module modules/mod_dispatcher.so

Para utilizar el módulo en nuestro </VirtualHost> soltamos un archivo de configuración en /etc/httpd/conf.d/ nombrado dispatcher_vhost.conf y dentro de este archivo verá el uso de configurar los parámetros básicos necesarios para que funcione el módulo:

<IfModule disp_apache2.c>

DispatcherConfig conf.dispatcher.d /dispatcher .any

...SNIP...

</IfModule>

Como puede ver arriba, esto incluye el archivo dispatcher.any de nivel superior para que nuestro módulo de Dispatcher recoja sus archivos de configuración de /etc/httpd/conf.dispatcher.d/dispatcher.any

Preste atención al contenido de este archivo:

/farms {

   $include "enabled_farms/*_farm.any"

}

El archivo dispatcher.any incluye todos los archivos de granja habilitados que residen en /etc/httpd/conf.dispatcher.d/enabled_farms/ con el nombre de archivo <FILENAME>_farm.any que sigue nuestra convención de nomenclatura estándar.

Más adelante, en dispatcher_vhost.conf archivo mencionado anteriormente también hacemos una declaración de inclusión para habilitar cada archivo host virtual habilitado que se encuentre en /etc/httpd/conf.d/enabled_vhosts/ con el nombre de archivo de <FILENAME>.vhost que sigue nuestra convención de nomenclatura estándar.

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

En cada uno de nuestros archivos .vhost verá que el módulo de Dispatcher se inicializa como controlador de archivo predeterminado para un directorio. Este es un ejemplo de archivo .vhost para mostrar la sintaxis:

<VirtualHost *:80>

    ServerName    "weretail"

    ServerAlias www.weretail.com weretail.com

    <Directory />

        <IfModule disp_apache2.c>

            ....SNIP....

            SetHandler dispatcher-handler

        </IfModule>

        ....SNIP....

    </Directory>

    ....SNIP....

</VirtualHost>

Después de que el nivel superior incluye la resolución, tienen otras sub-inclusiones que vale la pena mencionar. Este es un diagrama de alto nivel sobre cómo los archivos farms y vhosts incluyen otros subelementos

C. El host virtual de AMS incluye

Si hay algún archivo .vhost de /etc/httpd/conf.d/availabled_vhosts/ directorio obtener enlace simbólico en el /etc/httpd/conf.d/enabled_vhosts/ se utilizarán en la configuración en ejecución.

Los archivos .vhost tienen sub-inclusiones basadas en partes comunes que hemos encontrado.  Cosas como variables, listas blancas y reglas de reescritura.

El archivo .vhost tendrá instrucciones de inclusión para cada archivo en función de dónde deban incluirse en el archivo .vhost.  Esta es una sintaxis de ejemplo de un archivo .vhost como buena referencia:

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

Como puede ver en el ejemplo anterior, hay una inclusión para las variables necesarias en este archivo de configuración que se utilizan más adelante.

Dentro del archivo /etc/httpd/conf.d/variables/weretail.vars podemos ver qué variables están definidas:

Define MAIN_DOMAIN dev.weretail.com

También puede ver una línea que incluye una lista de archivos whitelist.rules que restringen quién puede ver este contenido en función de diferentes criterios de la lista blanca. Veamos el contenido de uno de los archivos de la lista blanca /etc/httpd/conf.d/whitelists/weretail_mainoffice_whitelist.rules:

<RequireAny>

  Require ip 192.150.16.0/23

</RequireAny>

También puede ver una línea que incluye un conjunto de reglas de reescritura. Vamos a echar un vistazo al contenido de la weretail_rewrite.rules archivo:

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. La granja de AMS incluye

Si existe <FILENAME>_farm.any archivos de /etc/httpd/conf.dispatcher.d/available_farms/ directorio obtener enlace simbólico en el /etc/httpd/conf.dispatcher.d/enabled_farms/ se utilizarán en la configuración en ejecución.

Los archivos de granja tienen subinclusiones basadas en secciones de nivel superior de la granja como cache, clientheaders, filters, renders y vhosts.

El <FILENAME>_farm.any Los archivos tendrán instrucciones de inclusión para cada archivo en función de dónde deban incluirse en el archivo de granja. Este es un ejemplo de sintaxis de un <FILENAME>_farm.any como buena referencia:

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

    }

}

Como puede ver en cada sección de la granja de servidores de correo electrónico, en lugar de tener toda la sintaxis necesaria, se utiliza una instrucción de inclusión.

Veamos la sintaxis de algunas de estas inclusiones para tener la idea de cómo se vería cada subcomponente /etc/httpd/conf.dispatcher.d/vhosts/weretail_publish_vhosts.any:

"brand1.weretail.com"

"brand2.weretail.com"

"www.weretail.comf"

Como puede ver, es una nueva lista separada por líneas de nombres de dominio que deben procesarse desde esta granja sobre los demás.

A continuación, veamos el /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" }