Explicação dos arquivos de configuração | AEM

Descrição

Ambiente
Experience Manager
Problema/Sintomas
Este documento detalhará e explicará cada um dos arquivos de configuração implantados em um servidor de dispatcher padrão criado no Adobe Managed Services. Seu uso, convenção de nomenclatura etc.





Convenção de nomenclatura



 


Na verdade, o servidor Web Apache não se importa com a extensão de arquivo de um arquivo ao direcioná-lo com uma instrução include ou includeoptional.  Nomeá-los corretamente com nomes que eliminam conflitos e confusão ajuda muito. Os nomes usados descreverão o escopo de aplicação do arquivo, facilitando a vida. Se tudo é chamado de .conf, fica realmente confuso. Queremos evitar arquivos e extensões com nomes inadequados.  Abaixo está uma lista das diferentes extensões de arquivo personalizadas e convenções de nomenclatura usadas em um dispatcher típico configurado pelo AMS.




 

Arquivos contidos em conf.d/

Arquivo Destino do arquivo Descrição
FILENAME.conf /etc/httpd/conf.d/ Uma instalação padrão do Enterprise Linux usa essa extensão de arquivo e inclui a pasta como um local para substituir as configurações no httpd.conf e permitir que você adicione funcionalidades adicionais em um nível global no Apache.
FILENAME.vhost Preparado: /etc/httpd/conf.d/available_vhosts/

Ativo:

/etc/httpd/conf.d/enabled_vhosts/

*Observação: Os arquivos .vhost não devem ser copiados para a pasta enabled_vhosts, mas usam links simbólicos para um caminho relativo para o arquivo available_vhosts/ .vhost

*.vhost (Host Virtual) são entradas VirtualHosts para corresponder a nomes de host e permitir que o Apache manipule cada tráfego de domínio com regras diferentes. No arquivo .vhost, outros arquivos como regravações, listas de permissões etc. serão incluídos.
FILENAME_rewrite.rules /etc/httpd/conf.d/rewrites/ Os arquivos *_rewrite.rules armazenam as regras mod_rewrite para serem incluídas e consumidas explicitamente por um arquivo vhost
FILENAME_whitelist.rules /etc/httpd/conf.d/whitelists/ Os arquivos *_ipwhitelist.rules são incluídos de dentro dos arquivos *.vhost. Ele contém regex de IP ou permite regras de negação para permitir a lista de permissões de IP. Se estiver tentando restringir a visualização de um host virtual com base em endereços IP, você gerará um desses arquivos e o incluirá no arquivo *.vhost




 

Arquivos contidos em conf.modules.d/



 

Arquivo Destino do arquivo Descrição
FILENAME.any /etc/httpd/conf.dispatcher.d/ O AEM Dispatcher Apache Module gera as configurações de *.any files. O arquivo de inclusão principal padrão é conf.dispatcher.d/dispatcher.any
FILENAME_farm.any Preparado:

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

Ativo:

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

*Observação: esses arquivos farm não devem ser copiados para a pasta enabled_farms, mas usam links simbólicos para um caminho relativo para available_farms/ arquivo farm.any* Os arquivos farm.any estão incluídos no arquivo conf.dispatcher.d/dispatcher.any. Esses arquivos farm primários existem para controlar o comportamento do módulo para cada renderização ou tipo de site. Os arquivos são criados no diretório available_farms e ativados com um link simbólico no diretório enabled_farms.



Ele os inclui automaticamente pelo nome do arquivo dispatcher.any.



Os arquivos farm de linha de base começam com 000 para garantir que sejam carregadas primeiro.

Os arquivos farm personalizados devem ser carregados depois, iniciando o esquema numérico em 100
para garantir o comportamento de inclusão correto.
FILENAME_filters.any /etc/httpd/conf.dispatcher.d/filters/ *_filters.any os arquivos estão incluídos nos arquivos conf.dispatcher.d/enabled_farms/*_farm.any. Cada farm tem um conjunto de regras que alteram o tráfego que deve ser filtrado e não para os renderizadores.
FILENAME_vhosts.any /etc/httpd/conf.dispatcher.d/vhosts/ Os arquivos *_vhosts.any estão incluídos nos arquivos conf.dispatcher.d/enabled_farms/*_farm.any. Esses arquivos são uma lista de nomes de host ou caminhos de uri que devem ser correspondidos pela correspondência de blob para determinar qual renderizador usar para fornecer essa solicitação
FILENAME_cache.any /etc/httpd/conf.dispatcher.d/cache/ Os arquivos *_cache.any estão incluídos nos arquivos conf.dispatcher.d/enabled_farms/*_farm.any. Esses arquivos especificam quais itens são armazenados em cache e quais não são
FILENAME_invalidate_allowed.any /etc/httpd/conf.dispatcher.d/cache/ *_invalidate_allowed.any os arquivos estão incluídos nos arquivos conf.dispatcher.d/enabled_farms/*_farm.any. Eles especificam quais endereços IP podem enviar solicitações de liberação e invalidação.
FILENAME_clientheaders.any /etc/httpd/conf.dispatcher.d/clientheaders/ Os arquivos *_clientheaders.any estão incluídos nos arquivos conf.dispatcher.d/enabled_farms/*_farm.any. Eles especificam quais cabeçalhos do cliente devem ser passados para cada renderizador.
FILENAME_renders.any /etc/httpd/conf.dispatcher.d/renders/ *_renders.any os arquivos estão incluídos nos arquivos conf.dispatcher.d/enabled_farms/*_farm.any. Eles especificam as configurações de IP, porta e tempo limite para cada renderizador. Um renderizador adequado pode ser um servidor do livecycle ou qualquer sistema de AEM em que o dispatcher possa buscar/proxy as solicitações de




 

Problemas evitados



 


Ao seguir a convenção de nomenclatura, você pode evitar erros bastante fáceis de cometer que podem ter resultados catastróficos.  Abordaremos alguns exemplos.




 

Exemplo de problema



 


Como um Exemplo de site para o ExampleCo, dois arquivos de configuração foram criados pelos desenvolvedores das configurações do dispatcher.

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





 



1
2
3
4
5
6
7
8
9
10
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





 



1
2
RewriteRule /$ /content/exampleco/en.html PT,L RewriteRule /robots.txt$ /content/dam/exampleco/robots.txt PT,L






 

POTENCIAL PERIGO



 


Os nomes dos arquivos são iguais

Se o arquivo vhost for colocado acidentalmente na pasta de regravações e o arquivo de regravações for colocado na pasta vhosts.  Parece que ele foi implantado corretamente pelo nome do arquivo, mas o Apache emitirá um erro e o problema não será imediatamente aparente.

Como isso normalmente se torna um problema

Se os dois arquivos forem baixados no mesmo local, eles poderão se substituir ou torná-lo indistinguível, tornando o processo de implantação um pesadelo.

As extensões de arquivo são iguais e propensas à inclusão automática

As extensões de arquivo são as mesmas e usam a extensão de inclusão automática que o Apache incluirá automaticamente quaisquer arquivos .conf em muitas das pastas padrão.

Como isso normalmente se torna um problema

Se o arquivo vhost com a extensão .conf for colocado na pasta /etc/httpd/conf.d/, ele tentará carregá-lo na memória do Apache, o que normalmente é ok, mas se o arquivo de regras de regravação com a extensão .conf for colocado na pasta /etc/httpd/conf.d/, ele será incluído automaticamente e aplicado globalmente, causando resultados confusos e indesejados.

Resolução

Nomeie os arquivos com base no que eles fazem e com segurança fora do namespace de regras de inclusão automática.

Se for um arquivo de host virtual, nomeie-o com .vhost como a extensão.

Se for um arquivo de regra de regravação, nomeie-o com site_rewrite.rules como o sufixo e a extensão. Essa convenção de nomenclatura deixará claro para qual site é e que é um conjunto de regras de regravação.

Se for um arquivo de regra da lista de permissões de IP, nomeie-o como o sufixo e a extensão description_whitelist.rules. Essa convenção de nomenclatura fornecerá uma descrição do seu objetivo e que é um conjunto de regras de correspondência de IP.

O uso dessas convenções de nomenclatura evitará problemas, se um arquivo for movido para um diretório de inclusão automática ao qual não pertence.

Por exemplo, colocar um arquivo chamado com .rules, .any ou .vhost na pasta de inclusão automática de /etc/httpd/conf.d/ não teria nenhum efeito.

Se uma solicitação de alteração de implantação indicar “implante exampleco_rewrite.rules nos dispatchers de produção”, a pessoa que implantou as alterações já poderá saber que não está adicionando um novo site, apenas atualizando as regras de regravação conforme indicado pelo nome do arquivo.

 Incluir pedido

Ao estender a funcionalidade e as configurações no servidor Web Apache instalado no Enterprise Linux, você tem alguns pedidos de inclusão importantes que deseja entender

 Inclusões da linha de base do Apache
ordem de inclusão da linha de base do apache.  o binário do apache começa com httpd.conf, que faz uma inclusão opcional ao conf.d/*.conf e conf.modules.d/* diretórios .conf

Conforme visto no diagrama acima, o binário httpd somente é exibido no arquivo httpd.conf como arquivo de configuração.  Esse arquivo contém as seguintes instruções:

 

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


 Inclusões de nível superior do AMS

Quando aplicamos nosso padrão, adicionamos alguns tipos de arquivo adicionais e inclusões próprias.

Aqui estão os diretórios de linha de base do AMS e as inclusões de nível superior
A linha de base do AMS inclui iniciar com um dispatcher_vhost.conf que incluirá qualquer arquivo com o *.vhost do diretório /etc/httpd/conf.d/enabled_vhosts/.  Os itens no diretório /etc/httpd/conf.d/enabled_vhosts/ são links simbólicos para o arquivo de configuração real que está ativo em /etc/httpd/conf.d/available_vhosts/

Ao criar a linha de base do Apache, mostramos como o AMS criou algumas pastas adicionais e as inclusões de nível superior para pastas conf.d, bem como diretórios específicos do módulo aninhados em /etc/httpd/conf.dispatcher.d/

Quando o apache é carregado, ele recebe a variável /etc/httpd/conf.modules.d/02-dispatcher.conf e esse arquivo incluirá o arquivo binário /etc/httpd/modules/mod_dispatcher.so no estado de execução.

 

1 LoadModule dispatcher_module modules /mod_dispatcher .so

Para usar o módulo em *VirtualHost /* soltamos um arquivo de configuração em */etc/httpd/conf.d/nomeado dispatcher_vhost.conf e dentro desse arquivo você verá usar a configuração dos parâmetros básicos necessários para que o módulo funcione:
 

| 1
2
3


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


 
Como você pode ver acima, isso inclui o arquivo dispatcher.any de nível superior para que o módulo Dispatcher selecione os arquivos de configuração de /etc/httpd/conf.dispatcher.d/dispatcher.any

Preste atenção ao conteúdo deste arquivo:

 


| 1
2
3 | /farms {      $include "enabled_farms/*_farm.any" } |
| — | — |


 
O arquivo dispatcher.any de nível superior inclui todos os arquivos farm habilitados que estão ativos no /etc/httpd/conf.dispatcher.d/enabled_farms/ com o nome de arquivo de FILENAME_farm.any que segue nossa convenção de nomenclatura padrão.

Mais tarde no dispatcher_vhost.conf arquivo mencionado anteriormente, também fazemos uma instrução include para habilitar cada arquivo de host virtual habilitado que esteja ativo em /etc/httpd/conf.d/enabled_vhosts/ com o nome do arquivo de FILENAME.vhost que segue nossa convenção de nomenclatura padrão.



 


| 1 | IncludeOptional /etc/httpd/conf.d/enabled_vhosts/*.vhost |
| — | — |


 
Em cada um de nossos arquivos .vhost, você observará que o módulo Dispatcher é inicializado como um manipulador de arquivos padrão para um diretório.  Este é um exemplo de arquivo .vhost para mostrar a sintaxe:

 


| 1
2
3
4
5
6
7
8
9
10
11
12 | VirtualHost *:80      ServerName    "weretail"      ServerAlias www.weretail.com weretail.com      Directory /          IfModule disp_apache2.c              ....SNIP....              SetHandler dispatcher-handler          /IfModule          ....SNIP....      /Directory      ....SNIP.... /VirtualHost |
| — | — |


 
Depois que as inclusões de nível superior são resolvidas, elas têm outras subinclusões que valem a pena mencionar.  Este é um diagrama de alto nível sobre como os arquivos farms e vhosts incluem outros subelementos

 Inclusões de host virtual do AMS
Subitens de inclusão de hosts virtuais do AMS.  Esta imagem mostra como um arquivo .vhost inclui arquivos de variáveis, listas de permissões e pastas de regravação
 
Quando qualquer arquivo .vhost de /etc/httpd/conf.d/available_vhosts/ o diretório é vinculado simbólico à /etc/httpd/conf.d/enabled_vhosts/ diretory serão usados na configuração em execução.

Os arquivos .vhost têm subinclusões com base em partes comuns que encontramos.  Coisas como variáveis, listas de permissões e regras de regravação.

O arquivo .vhost terá instruções de inclusão para cada arquivo com base no local em que precisam ser incluídas no arquivo .vhost.  Este é um exemplo de sintaxe de um arquivo .vhost como uma boa referência:


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


 
Como você pode ver no exemplo acima, há uma inclusão para as variáveis necessárias neste arquivo de configuração que são usadas posteriormente.

Dentro do arquivo /etc/httpd/conf.d/variables/weretail.vars podemos ver quais variáveis são definidas:



 


| 1 | Define MAIN_DOMAIN dev.weretail.com |
| — | — |


 
Você também pode ver uma linha que inclui uma lista de arquivos whitelist.rules que restringem quem pode visualizar esse conteúdo com base em diferentes critérios da lista de permissões.  Vamos analisar o conteúdo de um dos arquivos da lista branca /etc/httpd/conf.d/whitelists/weretail_mainoffice_whitelist.rules:

 


| 1
2
3 | RequireAny    Require ip 192.150.16.0/23 /RequireAny |
| — | — |


 
Você também pode ver uma linha que inclui um conjunto de regras de regravação.  Vamos analisar o conteúdo da variável weretail_rewrite.rules arquivo:

 


| 1
2
3
4
5
6 | 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 |
| — | — |


 Inclusões do farm do AMS
<FILENAME>_farms.any incluirá arquivos sub.any para concluir uma configuração de farm.  Nesta imagem, você pode ver que um farm incluirá cada cache de arquivos de seção de nível superior, cabeçalhos de clientes, filtros, renderizações e arquivos vhosts .any
 
Quando qualquer arquivo FILENAME_farm.any de /etc/httpd/conf.dispatcher.d/available_farms/ o diretório é vinculado simbólico à /etc/httpd/conf.dispatcher.d/enabled_farms/ diretory serão usados na configuração em execução.

Os arquivos farm têm subinclusões com base em seções de nível superior da exploração como cache, cabeçalhos de clientes, filtros, renderizações e vhosts.

Os arquivos FILENAME_farm.any terão instruções de inclusão para cada arquivo com base no local em que precisam ser incluídas no arquivo farm.  Este é um exemplo de sintaxe de um arquivo FILENAME_farm.any como uma boa referência:

 


| 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32 | /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 você pode ver cada seção do weretail farm em vez de ter toda a sintaxe necessária, ela está usando uma instrução include.

Vamos analisar a sintaxe de algumas dessas inclusões para ter uma ideia de como cada subinclusão seria

/etc/httpd/conf.dispatcher.d/vhosts/weretail_publish_vhosts.any:

 


| 1
2
3 | "brand1.weretail.com" "brand2.weretail.com" "www.weretail.comf" |
| — | — |


Como você pode ver, é uma lista separada por uma nova linha de nomes de domínio que devem ser renderizados deste farm em relação aos outros.

Em seguida, vamos olhar para o /etc/httpd/conf.dispatcher.d/filters/weretail_search_filters.any:

 


| 1
2 | /400 { /type "allow" /method "GET" /path "/bin/weretail/lists/*" /extension "json" } /401 { /type "allow" /method "POST" /path "/bin/weretail/search/' /extension "html" } |
| — | — |

|
| — |

Nesta página