Atualizando da versão 2.2 para 2.4

Para auxiliar os usuários na atualização, mantemos um documento que descreve informações essenciais para usuários existentes do Servidor HTTP Apache. Estas notas são breves e você poderá encontrar mais informações no documento Novas Funcionalidades ou no arquivo src/CHANGES. Desenvolvedores de aplicações e módulos podem encontrar um resumo das alterações da API na Visão geral de atualizações da API.

Este documento descreve alterações no comportamento do servidor que podem exigir que você altere sua configuração ou a forma como usa o servidor para continuar usando a versão 2.4 da mesma forma que usa a versão 2.2. Para aproveitar os novos recursos da versão 2.4, consulte o documento sobre Novas Funcionalidades.

Este documento descreve apenas as alterações da versão 2.2 para a 2.4. Se você estiver atualizando da versão 2.0, também deverá consultar o Documento de Atualização da versão 2.0 para 2.2.

• Alterações na Configuração no Momento da Compilação
• Alterações na Configuração no Momento da Execução
• Alterações Miscelâneas
• Módulos de Terceiros
• Problemas comuns ao atualizar

Veja também

• Visão geral das novas funcionalidades no Servidor HTTP Apache 2.4

Alterações na Configuração no Momento da Compilação ¶

O processo de compilação é muito semelhante ao usado na versão 2.2. Sua antiga linha de comando configure (encontrada em build/config.nice no diretório do servidor instalado) pode ser usada na maioria dos casos. Há algumas alterações nas configurações padrão. Alguns detalhes das alterações:

• Estes módulos foram removidos: mod_authn_default, mod_authz_default, mod_mem_cache. Se você estava usando mod_mem_cache na versão 2.2, consulte mod_cache_disk na versão 2.4.
• Todas as implementações de balanceamento de carga foram movidas para submódulos individuais e independentes do mod_proxy, por exemplo: mod_lbmethod_bybusyness . Você pode precisar compilar e carregar qualquer um desses que sua configuração utiliza.
• O suporte à plataforma foi removido para BeOS, TPF e até mesmo plataformas mais antigas, como A/UX, Next e Tandem. Acredita-se que estas já não estivessem funcionando corretamente.
• configure: módulos dinâmicos (DSO) são compilados por padrão.
• configure: por padrão, apenas um conjunto básico de módulos é carregado. As outras diretivas LoadModule estão comentadas no arquivo de configuração.
• configure: o conjunto de módulos "most" ("maioria") é compilado por padrão
• configure: o conjunto de módutos "reallyall" ("realmente todos") adiciona os módulos de desenvolvedor ao conjunto "all" ("todos")

Alterações na Configuração no Momento da Execução ¶

Houve mudanças significativas na configuração de autorização e outras pequenas alterações de configuração que podem exigir alterações em seus arquivos de configuração da versão 2.2 antes de usá-los na versão 2.4.

Autorização

Qualquer arquivo de configuração que utilize autorização provavelmente precisará de alterações.

Você deve revisar a seção Como Fazer: Autenticação, Autorização e Controle de Acesso, especialmente a parte Além da simples autorização que explica os novos mecanismos para controlar a ordem em que as diretivas de autorização são aplicadas.

As diretivas que controlam como os módulos de autorização respondem quando não correspondem ao usuário autenticado foram removidas: Isso inclui AuthzLDAPAuthoritative, AuthzDBDAuthoritative, AuthzDBMAuthoritative, AuthzGroupFileAuthoritative, AuthzUserAuthoritative, e AuthzOwnerAuthoritative. Essas diretivas foram substituídas pelas diretivas mais expressivas RequireAny , RequireNone e RequireAll .

Se você usa mod_authz_dbm , você deve migrar sua configuração para usar Require dbm-group ... em vez de Require group ....

Controle de acesso

Na versão 2.2, o controle de acesso baseado no nome do host do cliente, no endereço IP, e em outras características das solicitações do cliente era feito usando as diretivas Order , Allow , Deny e Satisfy .

Na versão 2.4, esse controle de acesso é feito da mesma forma que outras verificações de autorização, usando o novo módulo mod_authz_host . Os antigos padrões de controle de acesso devem ser substituídos pelos novos mecanismos de autenticação, embora, para compatibilidade com configurações antigas, o novo módulo mod_access_compat seja fornecido.

Aqui estão alguns exemplos de maneiras antigas e novas de fazer o mesmo controle de acesso.

Neste exemplo, não há autenticação e todas as solicitações são negadas.

Order deny,allow
Deny from all

Require all denied

Neste exemplo, não há autenticação e todas as solicitações são permitidas.

Order allow,deny
Allow from all

Require all granted

No exemplo a seguir, não há autenticação e todos os hosts no domínio example.org têm acesso permitido; todos os outros têm acesso negado.

Order Deny,Allow
Deny from all
Allow from example.org

Require host example.org

No exemplo a seguir, misturar diretivas antigas e novas leva a resultados inesperados.

DocumentRoot "/var/www/html"
<Directory "/">
 AllowOverride None
 Order deny,allow
 Deny from all
</Directory>
<Location "/server-status">
 SetHandler server-status
 Require local
</Location>
access.log - GET /server-status 403 127.0.0.1
error.log - AH01797: client denied by server configuration: /var/www/html/server-status

Por que o httpd nega acesso a server-status mesmo quando a configuração parece permitir? Porque as diretivas mod_access_compat tem precedência sobre as mod_authz_host neste cenário de mesclagem de configurações.

Este exemplo, por outro lado, funciona como esperado:

DocumentRoot "/var/www/html"
<Directory "/">
 AllowOverride None
 Require all denied
</Directory>
<Location "/server-status">
 SetHandler server-status
 Order deny,allow
 Deny from all
 Allow From 127.0.0.1
</Location>
access.log - GET /server-status 200 127.0.0.1

Portanto, mesmo se a mistura de configurações ainda seja possível, tente evitar na atualizaçao: mantenha diretivas antigas e somente migre para as novas em um estágio posterior ou migre tudo de uma vez.

Em muitas configurações com autenticação, onde o valor de Satisfy tinha o padrão de ALL, trechos que simplesmente desligavam o controle de acesso baseado em host são omitidos:

# configuração na versão 2.2 que desliga o controle de acesso baseado em host e usa somente autenticação
Order Deny,Allow
Allow from all
AuthType Basic
AuthBasicProvider file
AuthUserFile /example.com/conf/users.passwd
AuthName secure
Require valid-user

# Não é necessário substituir o controle de acesso baseado em host
AuthType Basic
AuthBasicProvider file
AuthUserFile /example.com/conf/users.passwd
AuthName secure
Require valid-user

Em configurações onde a autenticação e o controle de acesso eram adequadamente combinados, as diretivas de controle de acesso devem ser migradas. Este exemplo permite que as solicitações atendam a ambos os critérios:

Order allow,deny
Deny from all
# Satisfy ALL is the default
Satisfy ALL
Allow from 127.0.0.1
AuthType Basic
AuthBasicProvider file
AuthUserFile /example.com/conf/users.passwd
AuthName secure
Require valid-user

AuthType Basic
AuthBasicProvider file
AuthUserFile /example.com/conf/users.passwd
AuthName secure
<RequireAll>
 Require valid-user
 Require ip 127.0.0.1
</RequireAll>

Em configurações onde a autenticação e o controle de acesso eram adequadamente combinados, as diretivas de controle de acesso devem ser migradas. Este exemplo permite que as solicitações atendam a qualquer um dos critérios:

Order allow,deny
Deny from all
Satisfy any
Allow from 127.0.0.1
AuthType Basic
AuthBasicProvider file
AuthUserFile /example.com/conf/users.passwd
AuthName secure
Require valid-user

AuthType Basic
AuthBasicProvider file
AuthUserFile /example.com/conf/users.passwd
AuthName secure
# <RequireAny> (implícito)
Require valid-user
Require ip 127.0.0.1

Outras mudanças na configuração

Alguns outros pequenos ajustes podem ser necessários para configurações em particular como discutido abaixo.

• MaxRequestsPerChild foi renomeada para MaxConnectionsPerChild , descrevendo com maior precisão o que ela faz. O nome antigo ainda é suportado.
• MaxClients foi renomeada para MaxRequestWorkers , que descreve melhor o que ela faz. Para MPMs assíncronos, como event , o número máximo de clientes não é equivalente ao número de threads. O nome antigo ainda é suportado.
• A diretiva DefaultType não tem mais nenhum efeito além de emitir um alerta se for usada com algum valor diferente de none. É necessário usar outras configurações para substituí-la na versão 2.4.
• O padrão para AllowOverride agora é None.
• O padrão para EnableSendfile agora é Off.
• O padrão para FileETag agora é "MTime Size" (sem INode).
• mod_dav_fs : O formato do arquivo de DavLockDB foi alterado para sistemas com inodes. o arquivos antigo de DavLockDB precisa ser apagado na atualização.
• KeepAlive somente aceita valores de On ou Off. Anteriormente, qualquer valor diferente de "Off" ou "0" era tratado como "On".
• As diretivas AcceptMutex, LockFile, RewriteLock, SSLMutex, SSLStaplingMutex e WatchdogMutexPath foram substituídas por uma única diretiva Mutex . É necessário avaliar o uso dessas diretivas removidas na configuração 2.2 para determinar se elas podem ser apenas removidas ou se precisam ser substituídas usando Mutex .
• mod_cache : CacheIgnoreURLSessionIdentifiers agora faz uma correspondência exata com a string de consulta em vez de um correspondência parcial. Se a configuração estava usando strings parciais, por exemplo, usando sessionid para corresponder a /someapplication/image.gif;jsessionid=123456789, então será necessário alterar para a string completa jsessionid.
• mod_cache : O segundo parâmetro para CacheEnable somente corresponde ao conteúdo do proxy direto se ele começar com o protocolo correto. Na versão 2.2 e anteriores, um parâmetro de '/' correspondia a todo o conteúdo.
• mod_ldap : LDAPTrustedClientCert agora é, consistentemente, uma configuração apenas por diretório. Se esta diretiva for usada, revise a configuração para garantir que ela está presente em todos os contextos de diretório necessários.
• mod_filter : a sintaxe de FilterProvider foi alterada e agora usa uma expressão booleana para determinar se um filtro está aplicado.
• mod_include :
  • O elemento #if expr agora usa o novo analisador de expressões. A sintaxe antiga pode ser restaurada com a nova diretiva SSILegacyExprParser .
  • Uma diretiva de configuração SSI* em escopo de diretório não faz mais com que todas as outras diretivas SSI* por diretório sejam redefinidas para seus valores padrão.
• mod_charset_lite : A opção DebugLevel foi removida em favor da configuração LogLevel por módulo.
• mod_ext_filter : A opção DebugLevel foi removida em favor da configuração LogLevel por módulo.
• mod_proxy_scgi : A configuração padrão para PATH_INFO foi alterada em relação à versão 2.2 e algumas aplicações web não irão mais operar adequadamente com a nova configuração de PATH_INFO. A configuração anterior pode ser restaurada através da configuração da variável proxy-scgi-pathinfo.
• mod_ssl : A verificação de revogação baseada em CRL agora precisa ser configurada explicitamente através de SSLCARevocationCheck .
• mod_substitute : O comprimento máximo de linha agora é limitado a 1MB.
• mod_reqtimeout : Se o módulo for carregado, ele agora definirá alguns limites de tempo padrões.
• mod_dumpio : DumpIOLogLevel não é mais suportado. Os dados são sempre registrados com LogLevel no nível trace7.
• Em plataformas Unix, comandos de registro encadeados configurados com ErrorLog ou CustomLog eram chamados usando /bin/sh -c na versão 2.2 e anteriores. Na versão 2.4 e posteriores, comandos de registro encadeados são executados diretamente. Para restaurar o comportamento antigo, consulte a documentação sobre registros encadeados.

Alterações Miscelâneas ¶

• mod_autoindex : agora extrai títulos e exibe descrições para arquivos .xhtml, que antes eram ignorados.
• mod_ssl : O formato padrão das variáveis ​​*_DN foi alterado. O formato antigo ainda pode ser usado com o novo argumento LegacyDNStringFormat da diretiva SSLOptions . O protocolo SSLv2 não é mais suportado. SSLProxyCheckPeerCN e SSLProxyCheckPeerExpire agora são ativadas por padrão, fazendo com que as solicitações de proxy para hosts HTTPS com certificados inválidos ou desatualizados falhem com código de status 502 (Bad gateway)
• htpasswd agora usa hash MD5 por padrão em todas as plataformas.
• A diretiva NameVirtualHost não tem mais efeito, além de emitir um alerta. Qualquer combinação de endereço/porta que apareça em vários hosts virtuais é implicitamente tratada como um host virtual baseado em nome.
• mod_deflate agora irá ignorar a compressão se souber que a sobrecarga de tamanho adicionada pela compressão será maior que os dados a serem comprimidos.
• Documentos de erro multilíngues da versão 2.2.x podem não funcionar a menos que sejam ajustados à nova sintaxe do elemento #if expr= do módulo mod_include ou que a diretiva SSILegacyExprParser esteja habilitada para o diretório que contém os documentos de erro.
• A funcionalidade fornecida por mod_authn_alias em versões anteriores (ou seja, a diretiva AuthnProviderAlias ) foi movida para mod_authn_core .
• As diretivas RewriteLog e RewriteLogLevel foram removidas. Esta funcionalidade agora é disponibilizada configurando o nível adequado de registro para o módulo mod_rewrite usando a diretiva LogLevel . Consulte também a seção sobre registros de mod_rewrite.
• A etiqueta <set> do módulo mod_include não realiza mais a decodificação de entidades no valor que está sendo definido.

Módulos de Terceiros ¶

Todos os módulos devem ser recompilados para a versão 2.4 antes de serem carregados.

Muitos módulos de terceiros projetados para a versão 2.2 funcionarão sem alterações com a versão 2.4 do Apache HTTP Server. Alguns exigirão alterações; consulte a Visão geral da atualização da API.

Problemas comuns ao atualizar ¶

• Erros na inicialização:
  • Invalid command 'User', perhaps misspelled or defined by a module not included in the server configuration - carregue o módulo mod_unixd
  • Invalid command 'Require', perhaps misspelled or defined by a module not included in the server configuration, ou Invalid command 'Order', perhaps misspelled or defined by a module not included in the server configuration - carregue o módulo mod_access_compat ou atualize a configuração para as diretivas de autorização da versão 2.4.
  • Ignoring deprecated use of DefaultType in line NN of /path/to/httpd.conf - remova a diretiva DefaultType e substitua por outra configuração.
  • Invalid command 'AddOutputFilterByType', perhaps misspelled or defined by a module not included in the server configuration - AddOutputFilterByType foi movida do núcleo para o módulo mod_filter, que precisa ser carregado.
• Erros ao servir requisições:
  • configuration error: couldn't check user: /path - carregue o módulo mod_authn_core .
  • arquivos .htaccess são estão sendo processados - Verifique uma diretiva AllowOverride apropriada; o padrão mudou para None na versão 2.4.