La modalità CGI di Apache consente ai webmaster di ridurre l’utilizzo della memoria. È il modo preferito per eseguire molti siti Web a basso traffico.
Ma la modalità CGI è piuttosto sensibile a cose come le autorizzazioni e la codifica dei file, che porta a 500 Errore interno del server.
Nel nostro ruolo di ingegneri di supporto per gli host Web, abbiamo visto una vasta gamma di cause di questo errore.
Alcune cause comuni e le loro correzioni sono:
- Autorizzazioni errate per file o cartelle: i file e le directory di script devono avere ESATTAMENTE 755 autorizzazioni. In alcuni server, le directory potrebbero aver bisogno di autorizzazioni 750.
- Proprietà errata (utente & problemi di gruppo) – La proprietà del file deve essere impostata su “USER : ApacheUser” o “USER : USER” a seconda della configurazione di Apache.
- Codifica errata: i file caricati in modalità binaria falliranno l’esecuzione e dovrebbero essere caricati nuovamente come ASCII.
Quasi l ‘ 80% dei problemi di errore 500 sarebbe risolto da queste correzioni.
Questo articolo riguarda il resto 20% delle cause che sono difficili da trovare e risolvere.
Cause non comuni per Apache CGI Internal Server Error
500 Internal Server Error è il modo in cui un server Web dice: “Qualcosa è andato storto quando ho provato a visualizzare la pagina. Non so cosa.”
Se non si tratta di problemi di autorizzazione o proprietà, potrebbe essere qualsiasi cosa, dai bug delle applicazioni & Errori di configurazione di Apache ai blocchi del firewall & errori del file system.
Ecco i primi 10 problemi non comuni che abbiamo visto nel nostro corso di lavoro.
Moduli mancanti
Le applicazioni Web si basano su molti “moduli” PHP o Perl per funzioni specifiche.
Alcuni di questi moduli fanno parte di una configurazione standard del server, ma molti non lo sono.
Abbiamo visto che dopo una migrazione o durante una nuova configurazione del sito Web, gli script spesso falliscono perché non sono presenti tutti i moduli richiesti.
Il log degli errori dirà che ci sono funzioni “non definite” o “metodi” non esistono.
Per risolvere questo problema, passiamo attraverso le specifiche dei requisiti dell’app e installiamo tutti i moduli mancanti.
Timeout di rete (di chiamate API, script remoti, ecc.)
Alcune applicazioni web ottenere dati da server remoti(ad es. dati meteo).
Se per qualche motivo questa connessione al server remoto viene interrotta, l’app Web attenderà un po ‘ e mostrerà un errore di timeout.
Apache segnala quindi questo stato come Errore 500.
Questo problema può essere difficile da risolvere in quanto potrebbe non lasciare una voce di registro.
Rileviamo problemi di timeout ispezionando le connessioni in uscita a lungo in sospeso e risolviamo il problema disabilitando la funzionalità dell’app che richiede le connessioni in uscita.
Vecchi percorsi del programma (compilatore)
La prima riga di ogni app CGI (chiamata Shebang) contiene il percorso del programma che dovrebbe eseguirlo.
Per es. Gli script Perl hanno questo percorso:
#!/usr/bin/perl
Ma questo percorso può differire in base ai fornitori del sistema operativo e alle impostazioni di compilazione personalizzate.
Quindi, lo script cercherà il file di programma in una posizione particolare e, se non viene trovato lì, lo script mostrerà un errore 500.
Due metodi efficaci sono:
- Utilizzare i percorsi definiti nell’ambiente server – I percorsi di tutti i programmi sono memorizzati nella variabile “ambiente” del server. Quindi, cambiamo la prima riga chiamando l’ambiente, in questo modo:
#!/usr/bin/env perl- Questo farà in modo che non importa dove Perl è impostato, il percorso sarà disponibile per lo script.
- Definisci i percorsi del programma in Apache config-Usa le direttive” AddHandler “e” Action ” di Apache per eseguire tutti i file con il programma giusto. Per es. ecco come configurare il PHP come CGI:
AddHandler application/x-httpd-php5 phpAction application/x-httpd-php5 /local-bin/php-cgi
Errori nel codice dell’applicazione
proprietari di siti Web possono fare dei piccoli errori, come l’eliminazione di un “;” o l’inserimento di un randagio personaggio durante la modifica di applicazione o file di configurazione.
Ciò comporterà l’esecuzione dell’applicazione, ma Apache sputerà solo il criptico messaggio “Errore interno del server”.
Rileviamo tali problemi analizzando i file di registro e risolvendoli riparando l’errore del codice o disabilitando il plugin / addon / tema che sta causando l’errore.
Vecchi file di configurazione con percorsi modulo errati
I siti Web sono spesso personalizzati per l’ambiente del server e i percorsi del programma.
Quando i siti vengono migrati, i loro file di configurazione conterranno questi vecchi percorsi che potrebbero non essere compatibili con il nuovo server.
Abbiamo visto casi in cui le applicazioni web utilizzano file di configurazione personalizzati (ad esempio php.ini) per caricare le funzioni della libreria. Questo fallirà quando il percorso cambia in un nuovo server.
In questi casi rimuoviamo i percorsi del programma hard-coded e usiamo invece le variabili di ambiente per acquisire automaticamente le posizioni del programma.
Restrizioni di sicurezza (Web application firewall, SELinux, ecc.)
La maggior parte dei server in questi giorni ha firewall per applicazioni Web come mod_security o ComodoWAF.
Questi firewall possono causare un errore 500 se interpreta una richiesta di pagina come un attacco.
Per es. abbiamo visto le app Web fallire perché le chiamate di un file esterno sono state interpretate come un attacco di inclusione di file remoto da mod_security.
In questi casi, creiamo regole di esclusione del firewall personalizzate in modo che l’app non venga più bloccata, mentre la sicurezza del server non è interessata.
La modifica dell’impostazione di SELinux da “Enforcing” a “Permissive” ci ha anche aiutato a correggere questo errore.
Nessuna restrizione Exec (nessuna esecuzione) sulla partizione
Le app CGI vengono eseguite come programmi.
Per questo ha bisogno di qualcosa chiamato privilegio “Execute”.
Questo privilegio “Execute” è disattivato per le partizioni pubbliche accessibili come “/tmp” e le partizioni data-store come “/backup” per impedire l’esecuzione di malware.
Abbiamo visto casi in cui questo bit “Execute” è disattivato per le case dei siti Web, causando il fallimento dell’esecuzione dello script.
Ripristiniamo exec da:
# mount -o remount,exec /home
Apache &.htaccess configurazione errata (no ExecCGI, no AllowOverride, ecc.)
Apache ha bisogno di sapere quali directory contengono script CGI.
Che viene indicato utilizzando la direttiva “ExecCGI”.
Per es. per indicare /cgi-bin/ come una directory CGI, Apache dovrebbe essere configurato con:
<Directory /path/to/cgi-bin>
Options +ExecCGI
</Directory>
In alcuni server abbiamo visto” ExecCGI ” disabilitato in cgi-bin a causa di una configurazione errata nel file Apache conf o in an .htaccess nella directory principale.
Allo stesso modo, abbiamo visto le direttive relative a CGI in .htaccess diventare inefficace perché .htaccess non è stato abilitato tramite una direttiva “AllowOverride” in Apache config.
Tutto ciò può comportare un’esecuzione dello script non riuscita e, di conseguenza, un errore 500.
Permessi errati sulla home directory
Le directory CGI sono solitamente collocate all’interno della home directory. Per es. il percorso di un cgi-bin nei server cPanel è:
/home/username/public_html/cgi-bin/
Molti webmaster si prendono cura di cambiare il permesso della directory cgi-bin e le directory delle applicazioni web a 755, ma dimenticare di controllare le autorizzazioni della directory home.
In alcune configurazioni Apache (ad es. quando si utilizza SuExec), la directory home dovrebbe avere anche i permessi 755. Qualcosa di diverso da quello (ad es. 777), causerà il fallimento dell’esecuzione dello script.
Quindi, una delle prime cose che controlliamo insieme ai permessi dei file di script è controllare i permessi di tutte le directory nel percorso del file.
Abbiamo impostato tutto giusto per assicurarci che lo script venga eseguito senza errori.
Errori relativi a Chroot che interrompono il percorso del file
In alcuni server condivisi, la sicurezza viene applicata limitando ogni utente a un ambiente incarcerato.
Ciò impedisce a un utente di accedere ai file di qualsiasi altro utente.
Ma tali ambienti possono interrompere i softlink ai file di programma.
Per es. se i programmi sono memorizzati in ” / opt / php / bin /”ed è collegato a da”/usr/bin/ php/”, tali riferimenti possono essere interrotti.
Questi sono casi piuttosto rari e lo risolviamo riconfigurando il server (o il sito) per utilizzare il percorso corretto invece dei softlink.