Apache – File di Log

Per poter gestire un web-server, ed in modo più generale per manipolare qualsiasi servizio è necessario saper trarre dati rilevanti dai file di Log. Apache fornisce vari strumenti e possibilità di configurazione dei file di log.

Immediatamente una considerazione sulla sicurezza. E’ importante non concedere ad utenti alcuni la possibilità di scrivere all’interno della cartella che detiene i file di log del web-server, potrebbe arrivare ad ottenere i privilegi dell’utente che esegue il primo avvio del demone (solitamente root). Altra considerazione all’interno dei file di log potrebbero essere presenti anche informazioni confidenziali, è bene valutare anche l’accesso in lettura.

Error Log, questo tipo di log raccoglie tutti gli errori che vengono generati dal web server. Il nome e la locazione di tale file di log viene indicata dalla direttiva ErrorLog, e di norma il file di riferimento è error_log, all’interno della cartella dei log di apache. Tale file di log non è personalizzabile, il formato è standard. Ecco un esempio:

[Sun Nov 15 07:31:45 2009] [error] [client 66.249.65.251] File does not exist: /var/www/default/components

Access Log, questo tipo di file raccoglie invece tutte le richieste processate dal web server. La locazione del file di log e il suo formato vengono controllati dalla direttiva CustomLog. L’utilizzo dei file di log solitamente non è mai fine a se stessa, ma o è utile per ritrovare errori o malfunzionamenti nel servizio oppure con programmi appositi si possono generare delle statistiche per capire:

• carico del web server
• tipi di client web che si connettono
• quante connessioni sono attive in un determinato lasso temporale
• etc…

La creazione di statistiche in relazione al server web esula da questa trattazione, è comunque utile ricordare come un buon formato di file di log aiuta i programmi automatici di generazione delle statistiche, come per esempio awstats (http://awstats.sourceforge.net/)

Analizzeremo ora due formati di Log:

• Common Log Format
• Combined Log Format

Il primo si indica nel modo seguente:

LogFormat “%h %l %u %t \”%r\” %>s %b” common
CustomLog logs/access_log common

e produce un output simile:

127.0.0.1 – frank [10/Oct/2000:13:55:36 -0700] “GET /apache_pb.gif HTTP/1.0″ 200 2326

Analizziamo nel dettaglio le voci:

• 127.0.0.1 (%h) → Indirizzo IP del client che ha effettuato la richiesta
• - (%1) → il meno indica che l’informazione richiesta non è disponibile. La risorsa non disponibile in questo caso è l’identità del client (RFC 1413) determinata da identd
• frank (%u) → corrisponde allo userid dell’utente che ha effettuato la richiesta dopo una autenticazione http. Nel caso in cui non ci fosse stata autenticazione il valore assegnato sarebbe stato -
• [10/Oct/2000:13:55:36 -0700] (%t) → la data in cui la richiesta è arrivata
• “GET /apache_pb.gif HTTP/1.0″ (\”%r\”) → ciò che il client ha fatto, in questo caso ha richiesto l’immagine apache_pb.gif
• 200 (%>s) → Il codice di stato del server web in risposta alla richiesta del client. Ricordo che i codici si differenziano a grandi linee i 4 modi:
  • codici che cominciano con 2 → risposta data con successo
  • codici che cominciano con 3 → redirect
  • codici che cominciano con 4 → errore causato dal client
  • codici che cominciano con 5 → errore nel server
• 2326(%b) → indica la dimensione dell’oggetto restituito al client

Il Combined Log Format, è molto simile al formato appena affrontato, con l’aggiunta di due opzioni; ecco di seguito come viene espresso:

LogFormat “%h %l %u %t \”%r\” %>s %b \”%{Referer}i\” \”%{User-agent}i\”" combined
CustomLog log/access_log combined

e cosa produce:

127.0.0.1 – frank [10/Oct/2000:13:55:36 -0700] “GET /apache_pb.gif HTTP/1.0″ 200 2326 “http://www.example.com/start.html” “Mozilla/4.08 [en] (Win98; I ;Nav)”

Analizziamo nel dettaglio le voci aggiuntive:

• “http://www.example.com/start.html” (\”%{Referer}i\”) → si riferisce alla pagina dalla quale è avvenuta la richiesta del client
• “Mozilla/4.08 [en] (Win98; I ;Nav)” (\”%{User-agent}i\”) → dettagli del client

Rotazione dei Log – La dimensione dei file di log di apache cresce molto velocemente. Dato il numero di informazioni salvate il file di accesso cresce in media di 1 MB per 10.000 richieste. E’ bene quindi adottare un metodo di rotazione per eliminare i vecchi file di log con una accortezza, dato che apache continuerà a scrivere sul vecchio file di log finché non sarà riavviato.

La politica corretta da adottare durante la rotazione dei log e quella di effettuare la rotazione rinominando il vecchio file di log in access_log.1, creando il nuovo file access_log e riavviare in modo leggero apache (per esempio il comando apache2ctl graceful o apache2 reload).

In questo caso tutte le operazioni pendenti verranno concluse loggando le attività sul vecchio file di log, mentre le nuove istanze scriveranno sul nuovo file di log.

Va considerato per il metodo di rotazione un demone molto ben costruito come logrotate, che per sistemi debian ha già una configurazione ottimale (gestisce il riavvio dolce di apache durante la rotazione).

Piped log – L’espressione piped Log si utilizza quando apache fornisce i dati di accesso e di errore ad un programma terzo, che in base alla propria configurazione gestisce i dati in input.

L’utilizzo di questa procedura incrementa in modo notevole la flessibilità dei file di log e scarica il server web dalla gestione dei medesimi file. Come contro però si deve gestire un altro programma che sia in grado di intercettare i dati di apache.

Per quanto riguarda i virtual host invece

Virtual Host – Ci sono vari modi per gestire il logging dei virtual host. E’ possibile inserire tutte le informazioni di log degli host virtuali all’interno del file principale, oppure è possibile indicare per ogni virtual host uno specifico file di log. In questo ultimo caso è molto più semplice ricavare statistiche in relazione al singolo sito.

L’utilizzo di molti Virtual Host con assegnati specifici log può andare incontro ad un problema, ovvero si rischia di raggiungere il limite massimo di file descriptor aperti.

In sistemi Linux per ogni processo vengono allocati un massimo di 64 file descriptor, apache ne occupa una decina per uso interno e uno per ogni file di log. Con una trentina di virual host si potrebbe essere al limite delle risorse. Le soluzioni sono due:

• limitare il numero di file di log (inserenti in un unico file tutte le informazioni manipolando la scrittura dei dati in modo da taggate quelli che provengono da un tale VirtualHost)
• Incrementare il numero di file descriptor per processo