Explicação dos arquivos de configuração

Índice

<- Anterior: Layout básico do arquivo

Este documento detalha e explica cada um dos arquivos de configuração implantados em um servidor Dispatcher padrão criado no Adobe Managed Services. Seu uso, convenção de nomenclatura etc…

Convenção de nomeação

Na verdade, o Apache Web Server não se importa com a extensão do arquivo ao direcioná-lo com um Include ou IncludeOptional declaração.  A nomenclatura correta com nomes que eliminam conflitos e confusão ajuda a ton. Os nomes usados descreverão o escopo de aplicação do arquivo, facilitando a vida. Se tudo for nomeado .conf isso fica muito 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 para AMS.

Arquivos contidos em conf.d/

Arquivos contidos em conf.dispatcher.d/

Problemas evitados

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

Exemplo de problema

Como um exemplo de site para ExampleCo, dois arquivos de configuração foram criados pelos desenvolvedores das configurações do 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]

POTENTIAL DANGER - The file names are the same

Se a variável vhost arquivo for colocado acidentalmente no rewrites e a rewrites file é colocado na vhosts pasta.  Parece ser implantado pelo nome de arquivo corretamente, mas o Apache lançará um ERRO e o problema não será imediatamente aparente.

Como isso normalmente se torna um problema

Se a variável two files são baixados para o same local em que eles podem overwrite themselves ou torná-lo indistinguível, tornando o processo de implantação um pesadelo.

As extensões de arquivo são as mesmas e são susceptíveis de inclusão automática

As extensões de arquivo são as mesmas e usam a extensão incluída automaticamente que o Apache auto include qualquer .conf em muitas pastas padrão.

Como isso normalmente se torna um problema

Se o arquivo vhost com a extensão de .conf é colocado no /etc/httpd/conf.d/ pasta ele tentará carregá-lo na memória no Apache, o que geralmente é ok, mas se o arquivo de regras de regravação com a extensão de .conf é colocado no /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 sufixo e extensão. Essa convenção de nomenclatura deixará claro para qual site é destinado e que é um conjunto de regras de regravação.

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

Usar essas 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, .anyou .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 informar "implante exampleco_rewrite.rules nos Dispatchers de produção", a pessoa que implanta as alterações já poderá saber que não está adicionando um novo site, mas apenas atualiza as regras de regravação conforme indicado pelo nome do arquivo.

Incluir pedido

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

Inclusões da linha de base do Apache

Como visto no diagrama acima, o binário httpd procura somente o arquivo httpd.conf como seu arquivo de configuração.  Esse arquivo contém as seguintes declaraçõ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 arquivos adicionais e inclusões próprias.

Estes são os diretórios da linha de base do AMS e os inclusões de nível superior

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

Quando o Apache for carregado, ele extrairá o /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.

LoadModule dispatcher_module modules /mod_dispatcher .so

Para usar o módulo em nossa <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:

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

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

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

/farms {
    $include "enabled_farms/*_farm.any"
}

O nível superior dispatcher.any arquivo inclui todos os arquivos do farm habilitados que residem /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 /etc/httpd/conf.d/enabled_vhosts/ com o nome de arquivo de FILENAME.vhost que segue nossa convenção de nomenclatura padrão.

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 arquivo padrão para um diretório.  Este é um exemplo de arquivo .vhost para mostrar a sintaxe:

<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 o nível superior inclui resolver eles têm outras sub-inclusões que valem a pena mencionar.  Este é um diagrama de alto nível sobre como os arquivos farms e vhosts incluem outros elementos secundários

O host virtual do AMS inclui

Quando houver .vhost arquivos de /etc/httpd/conf.d/availabled_vhosts/ o diretório é vinculado ao /etc/httpd/conf.d/enabled_vhosts/ diretório em que serão usados na configuração em execução.

A variável .vhost os arquivos têm sub-inclusões com base em partes comuns encontradas.  Coisas como variáveis, listas de permissões e regras de regravação.

A variável .vhost arquivo terá instruções de inclusão para cada arquivo com base em onde eles precisam ser incluídos no .vhost arquivo.  Este é um exemplo de sintaxe de .vhost arquivar como uma boa referência:

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 você pode ver no exemplo acima, há uma inclusão para as variáveis necessárias nesse arquivo de configuração que serão usadas posteriormente.

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

Define MAIN_DOMAIN dev.weretail.com

Você também pode ver uma linha que inclui uma lista de _whitelist.rules arquivos que restringem quem pode exibir esse conteúdo com base em diferentes critérios de 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:

<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 weretail_rewrite.rules arquivo:

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]

AMS Farm Inclui

Quando qualquer arquivo FILENAME_farm.any de /etc/httpd/conf.dispatcher.d/available_farms/ o diretório é vinculado ao /etc/httpd/conf.dispatcher.d/enabled_farms/ diretório em que serão usados na configuração em execução.

Os arquivos do farm têm subinclusões com base em seções de nível superior do farm como cache, clientheaders, filtros, renderizações e vhosts.

A variável FILENAME_farm.any os arquivos terão instruções include para cada arquivo com base em onde eles precisam ser incluídos no arquivo farm.  Este é um exemplo de sintaxe de FILENAME_farm.any arquivar como uma boa referência:

/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 farm weretail em vez de ter toda a sintaxe necessária, ela usará uma instrução include.

Vamos analisar a sintaxe de alguns desses includes para ter a ideia de como cada sub-include seria

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

"brand1.weretail.com"
"brand2.weretail.com"
"www.weretail.comf"

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

A seguir, vejamos o /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" }

Próximo -> Noções básicas sobre cache