o modo CGI do Apache permite que os webmasters reduzam o uso de memória. É a maneira preferida de executar muitos sites de baixo tráfego.
mas o modo CGI é bastante sensível a coisas como permissões e codificação de arquivos, o que leva a 500 erros internos do servidor.
em nossa função de engenheiros de suporte para hosts da web, vimos uma ampla gama de causas para esse erro.
algumas causas comuns e suas correções são:
- Permissões de arquivo ou pasta erradas – Arquivos de Script e diretórios devem ter exatamente 755 permissões. Em alguns servidores, os diretórios podem precisar de 750 permissões.
- propriedade errada (problemas de grupo do Usuário &) – a propriedade do arquivo deve ser definida como “usuário : ApacheUser” ou “usuário : usuário”, dependendo da configuração do Apache.
- codificação incorreta-os arquivos carregados no modo binário falharão na execução e devem ser re-carregados como ASCII.
quase 80% dos problemas do erro 500 seriam resolvidos por essas correções.
este artigo é sobre o resto 20% das causas que são difíceis de encontrar e corrigir.
causas incomuns para o erro do Servidor Interno Apache CGI
500 o erro do servidor interno é a maneira de um servidor da web dizer: “algo deu errado quando tentei exibir a página. Não sei o quê.”
se não houver problemas de permissão ou propriedade, pode ser qualquer coisa, desde bugs de aplicativos & configurações incorretas do Apache a blocos de firewall & erros do sistema de arquivos.
Aqui estão os 10 principais problemas incomuns que vimos em nosso curso de trabalho.
Módulos ausentes
os aplicativos da Web dependem de muitos “módulos” PHP ou Perl para funções específicas.
alguns desses módulos fazem parte de uma configuração de servidor padrão, mas muitos não.
vimos que, após uma migração ou um durante uma nova configuração do site, os scripts geralmente falham porque todos os módulos necessários não estão presentes.
o log de erros dirá que não existem funções” indefinidas “ou” métodos”.
para corrigir isso, passamos pelas especificações dos requisitos do aplicativo e instalamos todos os módulos ausentes.
tempos limite de rede (de chamadas de API, scripts remotos, etc.)
alguns aplicativos da web obtêm dados de servidores remotos (por exemplo. dados meteorológicos).
se por algum motivo essa conexão com o servidor remoto for interrompida, o aplicativo da web aguardará um pouco e mostrará um erro de tempo limite.
Apache então relata esse status como um erro 500.
este problema pode ser difícil de solucionar, pois pode não deixar uma entrada de log.
detectamos problemas de tempo limite inspecionando conexões de saída pendentes longas e corrigimos desativando o recurso do aplicativo que requer as conexões de saída.
caminhos antigos do programa (compilador)
a primeira linha em cada aplicativo CGI (chamado Shebang) contém o caminho para o programa que deve executá-lo.
por exemplo. Os scripts Perl têm esse caminho:
#!/usr/bin/perl
mas esse caminho pode diferir com base nos fornecedores do sistema operacional e nas configurações de compilação personalizadas.
portanto, o script procurará o arquivo do programa em um local específico e, se não for encontrado lá, o script mostrará um erro 500.
Dois métodos eficazes são:
- Use os caminhos definidos no ambiente de servidor – os caminhos de todos Os programas são armazenados no servidor do “ambiente” da variável. Então, mudamos a primeira linha chamando o ambiente, assim:
#!/usr/bin/env perl- Isso garantirá que, não importa onde o Perl esteja configurado, o caminho estará disponível para o script.
- defina os caminhos do programa no Apache config-Use as diretivas” AddHandler “e” Action ” do Apache para executar todos os arquivos com o programa certo. Por exemplo. veja como configurar o PHP como um CGI:
AddHandler application/x-httpd-php5 phpAction application/x-httpd-php5 /local-bin/php-cgi
Erros no código da aplicação
os proprietários de sites podem fazer pequenos erros, como a exclusão de um “;” ou a inserção de um vadios personagem enquanto o aplicativo de edição ou configuração de arquivos.
isso resultará na falha na execução do aplicativo, mas o Apache cuspirá apenas a mensagem enigmática de “erro interno do servidor”.Detectamos esses problemas analisando os arquivos de log e os resolvemos corrigindo o erro de código ou desativando o plugin / addon / tema que está causando o erro.
arquivos de configuração antigos com caminhos de Módulo errados
os sites geralmente são personalizados para os caminhos de ambiente e programa do servidor.
quando os sites são migrados, seus arquivos de configuração conterão esses caminhos antigos que podem não ser compatíveis com o novo servidor.
vimos casos em que aplicativos da web usam arquivos de configuração personalizados (digamos php.ini) para carregar funções de biblioteca. Isso falhará quando o caminho mudar em um novo servidor.
nesses casos, removemos os caminhos do programa codificados e, em vez disso, usamos variáveis de ambiente para adquirir automaticamente os locais do programa.
restrições de Segurança (firewall de aplicativos da Web, SELinux, etc.)
a maioria dos servidores atualmente tem Firewalls de aplicativos da Web, como mod_security ou ComodoWAF.
esses firewalls podem causar um erro 500 se interpretarem uma solicitação de página como um ataque.
por exemplo. vimos aplicativos da web falhando porque uma chamada de arquivo externo foi interpretada como um ataque de inclusão de arquivo remoto por mod_security.
nesses casos, criamos regras de exclusão de firewall personalizadas para que o aplicativo não seja mais bloqueado, enquanto a segurança do servidor não é afetada.
alterar a configuração do SELinux de” aplicar “para” permissivo ” também nos ajudou a corrigir esse erro.
nenhuma restrição Exec (sem execução) na partição
os aplicativos CGI são executados como programas.
para isso, ele precisa de algo chamado de privilégio “executar”.
este privilégio “Executar” está desativado para partições acessíveis ao público, como “/tmp” e partições de armazenamento de dados, como “/backup”, para evitar a execução de malware.
vimos casos em que esse bit de” execução ” é desativado para casas do site, fazendo com que a execução do script falhe.
nós restauramos exec por:
# mount -o remount,exec /home
Apache & .configuração incorreta do htaccess (sem ExecCGI, sem AllowOverride, etc.)
Apache precisa saber quais diretórios contêm scripts CGI.
que é denotado usando a diretiva “ExecCGI”.
por exemplo. para denotar /cgi-bin/ como um diretório CGI, o Apache deve ser configurado com:
<Directory /path/to/cgi-bin>
Options +ExecCGI
</Directory>
Em alguns servidores que vimos “ExecCGI” desativado em cgi-bin devido a erros de configuração no Apache conf arquivo ou uma .htaccess no diretório pai.
da mesma forma, vimos diretivas relacionadas ao CGI em .htaccess tornando-se ineficaz porque .o htaccess não foi ativado por meio de uma diretiva “AllowOverride” na configuração do Apache.
tudo isso pode resultar em uma execução de script com falha e, consequentemente, em um erro 500.
permissões erradas no diretório inicial
os diretórios CGI geralmente são colocados no diretório inicial. Por exemplo. o caminho para um cgi-bin em servidores cPanel é:
/home/username/public_html/cgi-bin/
muitos webmasters têm o cuidado de alterar a permissão do diretório cgi-bin e os diretórios de aplicativos da web para 755, mas esqueça de verificar as permissões do diretório inicial.
em algumas configurações do Apache (por exemplo. ao usar SuExec), o diretório inicial também deve ter 755 permissões. Qualquer outra coisa além disso (eg. 777), fará com que a execução do script falhe.Portanto, uma das primeiras coisas que verificamos junto com as permissões do arquivo de script é verificar as permissões de todos os diretórios no caminho do arquivo.
definimos tudo corretamente para garantir que o script seja executado sem erros.
erros relacionados ao Chroot que quebram o caminho do arquivo
em alguns servidores compartilhados, a segurança é imposta confinando cada usuário a um ambiente preso.
isso impede que um usuário acesse os arquivos de qualquer outro usuário.
mas esses ambientes podem quebrar softlinks para arquivos de programas.
por exemplo. se os programas forem armazenados em” /opt/php/bin/ “e estiverem vinculados a” /usr/bin/php/”, essas referências podem ser quebradas.
estes são casos muito raros, e nós corrigi-lo por reconfigurar o servidor (ou site) para usar o caminho certo em vez de softlinks.