46.5. Moduli Apache

Il software Apache è basato su moduli: tutte le funzionalità eccetto alcuni task core sono gestite da moduli. Il software si è evoluto a tal punto che, anche l'HTTP viene elaborato da un modulo (http_core).

I moduli Apache possono essere compilati nel binario Apache al momento del build oppure caricati in modo dinamico al runtime. Per il caricamento al momento dell'esecuzione, consultare Sezione 46.3.2.2.1, «LoadModule module_identifier /path/to/module » per il caricamento manuale dei moduli e Moduli per utilizzare YaST.

Apache in SUSE Linux viene fornito con i seguenti moduli disponibili in apache2 RPM (prefix "mod_" omesso in questa sede): access, actions, alias, asis, auth, auth_anon, auth_dbm, auth_digest, auth_ldap, autoindex, cache, case_filter, case_filter_in, cern_meta, cgi, charset_lite, dav, dav_fs, deflate, dir, disk_cache, dumpio, echo, env, expires, ext_filter, file_cache, headers, imap, include, info, ldap, log_config, log_forensic, logio, mem_cache, mime, mime_magic, negotiation, proxy, proxy_connect, proxy_ftp, proxy_http, rewrite, setenvif, speling, ssl, status, suexec, unique_id, userdir, usertrack, and vhost_alias. Inoltre, SUSE Linux fornisce i seguenti moduli Apache come pacchetti RPM che devono essere installati separatamente: apache2-mod_auth_mysql, apache2-mod_fastcgi, apache2-mod_macro, apache2-mod_murka, apache2-mod_perl, apache2-mod_php4, apache2-mod_php5, apache2-mod_python, and apache2-mod_ruby.

Alcuni di questi moduli sono documentati in modo più dettagliato in questa sezione. Per una descrizione degli altri moduli presenti nella distribuzione di base, visitare il sito web Apache Modules Web all'indirizzo http://httpd.apache.org/docs-2.0/mod/. Per i moduli di terzi, consultare http://modules.apache.org/.

I moduli Apache possono essere suddivisi in tre diverse categorie: moduli base, moduli di estensione e moduli esterni.

46.5.1. Moduli di base

I moduli di base vengono compilati in Apache per impostazione predefinita. Questi sono disponibili a meno che non altrimenti specificato in modo esplicito in fase di generazione. In SUSE Linux Apache dispone solo dei moduli di base minimi compilati. Tuttavia, sono tutti disponibili come oggetti condivisi: anzichè essere inclusi nel binario stesso /usr/sbin/httpd2, è possibile includerli in fase di esecuzione configurando APACHE_MODULES in /etc/sysconfig/apache2.

46.5.1.1. Server-Side Includes con mod_include

mod_include fornisce uno strumento per l'elaborazione dei file prima che i dati vengano inviati al client. Generalmente, mod_include viene utilizzato per includere in un documento i file che vengono analizzati nel formato HTML prima di raggiungere il client. Questo è il motivo per cui allo strumento è stato assegnato il nome Server-Side Includes (SSI).

Con gli SSI vengono eseguiti speciali comandi sul server, attivati da commenti SGML formattati. Questi comandi SGML sono caratterizzati dalla sintassi seguente:

<!--#element attribute=value -->
        

Per un elenco dei valori di un elemento e un attributo, vedere la documentazione di mod_include in http://httpd.apache.org/docs-2.0/mod/mod_include.html.

Per utilizzare mod_include in SUSE Linux, aggiungere include a APACHE_MODULES in /etc/sysconfig/apache2 oppure utilizzare YaST come descritto in Moduli.

[Tip]Suggerimento

Utilizzare la direttiva XBitHack (http://httpd.apache.org/docs-2.0/mod/mod_include.html#xbithack) per indicare ad Apache di analizzare i file con il set di bit execute per le direttive SSI.

Ciò significa che anzichè dover cambiare l'estensione di un file per contrassegnarlo come elemento SSI (.shtml nell'esempio sopra menzionato), è possibile utilizzare un file .html normale ed eseguire chmod +x myfile.html.

46.5.1.2. CGI (Common Gateway Interface): mod_cgi

mod_cgi consente ad Apache di inviare il contenuto creato da programmi o script CGI ("Common Gateway Interface") esterni. Agisce ad esempio tra un linguaggio di programmazione disponibile sul computer fisico e il server Web Apache. Gli script CGI sono supportati in teoria da tutti i linguaggi di programmazione. Tuttavia, vengono generalmente utilizzati linguaggi quali Perl o C. mod_cgi è il metodo più utilizzato per includere contenuto dinamico in un sito Web.

Nella programmazione CGI, a differenza di quella "normale", i programmi e gli script CGI devono essere in grado di generare un tipo MIME Content-type: text/html per produrre l'output in HTML.

Esempio 46.11. Semplice script CGI in Perl

#!/path/to/perl
print "Content-type: text/html\n\n";
print "Hello, World.";
            

La differenza tra i moduli associati specificamente a un linguaggio di programmazione, ad esempio mod_php5) e mod_cgi consiste nella possibilità di combinare mod_cgi con mod_suexec (vedere la Sezione 46.5.2.1, «Esecuzione di CGI come altro utente con mod_suexec »). Questa combinazione consente di eseguire gli script CGI con uno specifico ID utente. Generalmente, gli script che utilizzano mod_cgi da solo oppure mod_php5 vengono eseguiti con l'ID utente di Apache (di default in SUSE Linux: wwwrun). I moduli progettati per un determinato linguaggio di programmazione (ad esempio mod_php5 o mod_ruby) integrano un interprete persistente in Apache per l'esecuzione degli script con l'utente ID di Apache.

Di conseguenza, l'utilizzo dei CGI con mod_suexec semplifica le operazioni di amministrazione dal momento che i processi CGI possono essere assegnati a singoli utenti anzichè al server Web stesso. Questa combinazione garantisce inoltre una maggiore sicurezza del file system: lo script eredita solo i diritti del file system dell'utente. Nel caso dei moduli, invece, allo script vengono assegnati i permessi per i file relativi all'utente del server Web, con il rischio che vengano accidentalmente visualizzati i dati nel file system.

I processi CGI vengono conclusi al termine della richiesta di un client sul server Web. Pertanto, i CGI non sono persistenti e, una volta conclusi, rilasciano tutte le risorse occupate. Ciò rappresenta un vantaggio soprattutto in caso di errori di programmazione. Nei moduli l'interprete è persistente, quindi gli effetti degli errori possono accumularsi con il rischio che non sia più possibile rilasciare risorse quali le connessioni a un database. Potrebbe anche essere necessario riavviare Apache.

Per utilizzare mod_cgi in SUSE Linux, aggiungere cgi ad APACHE_MODULES in /etc/sysconfig/apache2 oppure utilizzare YaST come descritto in Moduli. In SUSE Linux la directory predefinita per gli elementi CGI è /srv/www/cgi-bin/.

Se si desidera modificare manualmente un file di configurazione Apache, utilizzare l'esempio seguente come linea guida per la configurazione di mod_cgi.

Esempio 46.12. Attivazione manuale di mod_cgi

# Global Environment
LoadModule cgi_module /path/to/mod_cgi.so

# Main Server and/or Virtual Host and/or 
# Directory and/or .htaccess context
AddHandler cgi-script .cgi .pl

# Main Server and/or Virtual Host context
ScriptAlias /cgi-bin/ /srv/www/cgi-bin/

# Alternatively, explicitly allow CGI scripts in a directory
# Main Server and/or Virtual Host context
<Directory /srv/www/some/dir>
    Options +ExecCGI
<Directory>
            

46.5.2. Moduli di estensione

I moduli etichettati come estensioni sono inclusi nel pacchetto di programmi Apache ma non vengono generalmente compilati staticamente sul server. In SUSE Linux queste estensioni sono disponibili come oggetti condivisi caricabili in Apache in fase di esecuzione.

46.5.2.1. Esecuzione di CGI come altro utente con mod_suexec

mod_suexec consente, insieme a mod_cgi (Sezione 46.5.1.2, «CGI (Common Gateway Interface): mod_cgi »), di eseguire gli script CGI come un utente e un gruppo specificati. A questo scopo, viene utilizzato il programma suEXEC in /usr/sbin/suexec2. Si tratta di un wrapper chiamato da Apache a ogni esecuzione di un programma o di uno script CGI. Sia il wrapper che il programma ricevono l'ID assegnato all'utente e al gruppo configurati. Tale ID vene quindi eseguito come utente o gruppo configurato.

Benché questo metodo riduca significativamente i rischi di sicurezza tipici degli script CGI generati dagli utenti, occorre tenere in considerazione alcuni importanti fattori illustrati di seguito.

Considerazioni sull'utilizzo di suEXEC

  • suEXEC docroot: tutti gli script vengono eseguiti solo in questa directory di base. Pertanto, l'esecuzione degli script con suexec all'esterno della directory docroot non è consentita e genera un errore. docroot viene impostato durante la compilazione di suEXEC e non può essere modificato nella fase di esecuzione. In SUSE Linux la directory predefinita è /srv/www.

  • uidmin rappresenta l'ID minimo che deve essere assegnato a un utente affinché quest'ultimo possa essere utilizzato per eseguire gli script con suEXEC. Ciò impedisce che gli script possano essere eseguiti come utenti di sistema, ad esempio come utente root. Non creare utenti con ID inferiori ai valori di uidmin se tali utenti dovranno essere utilizzati con mod_suexec. In SUSE Linux il valore uidmin predefinito è pari a 96.

  • gidmin: equivale a uidmin ma per l'ID di gruppo. In SUSE Linux il valore gidmin predefinito corrisponde a 96.

  • Permessi per file e directory. Lo script in questione deve appartenere allo stesso utente e allo stesso gruppo così come specificato per l'utente e il gruppo suEXEC. Inoltre, sia il file che la directory di residenza devono poter essere scritti solo dal proprietario.

  • suEXEC safepath. Tutti i programmi utilizzati in uno script, quale Perl, devono risiedere nei percorsi contrassegnati come sicuri per suexec. safepath viene impostato a livello di compilazione suEXEC e non può essere modificato in fase di esecuzione. In SUSE Linux il percorso safepath predefinito è /usr/local/bin:/usr/bin:/bin.

In caso di errori provocati da mod_suexec, consultare il file di log suexec in /var/log/apache2/suexec.log.

Per utilizzare mod_suexec in SUSE Linux, aggiungere suexec a APACHE_MODULES in /etc/sysconfig/apache2 oppure utilizzare YaST come descritto in Moduli. Non dimenticare che per eseguire suexec, è necessario mod_cgi.

mod_suexec è più utile in un ambiente host virtuale come descritto nella Sezione 46.4, «Host virtuali». Per specificare un gruppo e un utente specifici per l'esecuzione degli script CGI, immettere la sintassi seguente nel file che contiene le dichiarazione dell'host virtuale (in SUSE Linux il file predefinito è /etc/apache2/vhosts.d/*):

Esempio 46.13. mod_suexec Configurazione

<VirtualHost 192.168.0>
# ...
ScriptAlias /cgi-bin/ /srv/www/vhosts/www.example.com/cgi-bin/
SuexecUserGroup tux users
# ...
</VirtualHost>
            

La sintassi SuexecUserGroup username group dell'esempio assegna a tutti gli script che risiedono in /srv/www/vhosts/www.example.com/cgi-bin/ l'ID utente del pinguino Tux e all'ID del gruppo di utenti.

46.5.2.2. Secure Sockets Layer e Apache: mod_ssl

mod_ssl fornisce una cifratura avanzata mediante l'utilizzo dei protocolli Secure Sockets Layer (SSL) e Transport Layer Security (TLS) per le comunicazioni HTTP tra un client e il server Web. A questo scopo, prima di rispondere a una richiesta di un URL, il server invia un certificato SSL con le informazioni che dimostrano la validità dell'identità del server. Ciò garantisce anche che il server rappresenti esclusivamente il punto finale corretto per la comunicazione. Inoltre, il certificato genera una connessione cifrata tra il client e il server che può trasportare le informazioni senza il rischio di esporre il contenuto in testo normale riservato. L'effetto più visibile derivante dall'utilizzo di mod_ssl con Apache è che gli URL presentano il prefisso https:// anzichè http://.

La porta predefinita per le richieste SSL e TLS sul server Web è la 443. I dati possono essere ricevuti sia sulla porta «normale» 80, che sulla porta SSL/TLS 443, senza il rischio di conflitti. Infatti è possibile eseguire connessioni HTTP e HTTPS nella stessa istanza di Apache. Per inviare le richieste alle porte 80 e 443 su server virtuali separati, viene generalmente utilizzato un host virtuale (vedere la Sezione 46.4, «Host virtuali».

[Important]SSL e host virtuali basati sui nomi

Non è possibile eseguire più host virtuali SSL su un server con un solo indirizzo IP. Gli utenti che tentano di collegarsi al server riceveranno un messaggio di avviso che indica che il certificato non corrisponde al nome del server ogni volta che visitano l'URL. Per il buon esito di una comunicazione basata su un certificato SSL valido, è necessaria una porta o un indirizzo IP distinto per ciascun dominio SSL.

In questo questo caso, anzichè un messaggio di avviso si otterrà lo stesso livello di cifratura di un sito SSL valido. Ciò significa che finché il messaggio di avviso è soddisfacente, la comunicazione tra il server Web e il client è ancora sicura. Non è quindi più necessario conoscere in maniera esclusiva l'identità del server, la quale è garantita da un certificato SSL valido.

Per attivare mod_ssl in SUSE Linux, aggiungere ssl a APACHE_MODULES in /etc/sysconfig/apache2 oppure utilizzare YaST come descritto in Moduli. Inoltre, è necessario configurare il server Web in modo che riceva i dati sulla porta HTTPS standard 443. È possibile eseguire questa operazione manualmente in /etc/apache2/listen.conf oppure in YaST mediante la voce di menu Listen (Ascolta) (vedere Selezione dispositivo di rete).

È possibile creare un certificato SSL di verifica immettendo cd /usr/share/doc/packages/apache2; ./certificate.sh come utente root. Per creare il certificato SSL, seguire le istruzioni visualizzate sullo schermo. I file di certificato risultanti vengono archiviati nelle directory /etc/apache2/ssl*.

Per ottenere un certificato «effettivo» con validità globale, contattare gli appositi fornitori, tra cui Thawte (http://www.thawte.com/ o Verisign (www.verisign.com).

Se si desidera modificare manualmente un file di configurazione Apache, utilizzare l'esempio seguente come linea guida per la configurazione di mod_ssl.

Esempio 46.14. Configurazione manuale di mod_ssl

# Global Environment
# listen on the standard SSL port
Listen 443
# load module only if rcapache2 start-ssl was issued
<IfDefine SSL>
LoadModule ssl_module /path/to/mod_ssl.so
</IfDefine>

# Main Server context
# include global (server-wide) SSL configuration 
# that is not specific to any virtual host
# only if ssl_module was loaded
<IfModule mod_ssl.c>
Include /etc/apache2/ssl-global.conf
</IfModule>
            
[Tip]Suggerimento

Non dimenticare di aprire il firewall per la connessione Apache SSL sulla porta 443. Questa operazione può essere esegua mediante YaST selezionando Security and Users (Sicurezza e utenti)+Firewall (Firewall)+Allowed Services (Servizi consentiti). Quindi aggiungere HTTPS Server (Server HTTPS) all'elenco dei Allowed Services (Servizi consentiti).

46.5.3. Moduli esterni

Ufficialmente, i moduli marcati come esterni non sono compresi nella distribuzione Apache. In ogni caso, SUSE Linux ne fornisce diversi disponibili per l'uso. Questo capitolo riporta una breve spiegazione dei moduli esterni e delle loro funzionalità.

46.5.3.1. Uso di Perl per gestire Apache: mod_perl

mod_perl ha un interprete Perl permanente incorporato in Apache. Questo evita l'overhead provocato damod_cgi che chiama un eseguibile esterno su ogni richiesta a un CGI. mod_perl consente inoltre di controllare molti aspetti della funzionalità Apache con l'ausilio del linguaggio di programmazione Perl.

Per utilizzare mod_perl in SUSE Linux, installare l'RPM apache2-mod_perl e attivare il modulo tramite YaST (Moduli) o manualmente in/etc/sysconfig/apache2. Dopo l'installazione e l'attivazione, un file di configurazione separato, mod_perl.conf, viene messo in/etc/apache2/conf.d/. Inoltre, lo script di avvio mod_perl viene installato come mod_perl-startup.pl. Per ulteriori informazioni sull'utilizzo del modulo, consultare la documentazione disponibile sul sito Web di mod_perl (http://perl.apache.org/).

46.5.3.2. PHP: mod_php4, mod_php5

PHP è un linguaggio di programmazione noto originariamente predisposto per l'utilizzo sul Web. Esiste nelle versioni PHP4 e PHP5. Mentre PHP4 rappresenta il classico concetto di PHP e l'approccio a quest'ultimo, PHP5 ha introdotto nuove possibilità di programmazione orientate agli oggetti e molte altre caratteristiche avanzate. mod_php4 e mod_php5 sono entrambi disponibili in SUSE Linux. Hanno un interprete PHP incorporato in Apache come modulo permanente.

Per utilizzaremod_php4 o mod_php5 in SUSE Linux, installare il rispettivo RPM (apache2-mod_php4, apache2-mod_php5) e attivare il modulo tramite YaST (Moduli) o manualmente in /etc/sysconfig/apache2.

Dopo l'installazione e l'attivazione, un file di configurazione separato per il rispettivo modulo (php4.conf o php5.conf) viene collocato in /etc/apache2/conf.d/. Il sito Web di PHP (http://www.php.net) è una risorsa eccellente per l'utilizzo di Apache con PHP.

46.5.3.3. Python e Apache: mod_python

mod_python ha un interprete Python permanente incorporato in Apache. Python è un linguaggio di programmazione orientato agli oggetti con una sintassi molto chiara e leggibile. Una caratteristica insolita ma conveniente è data dal fatto che la struttura del programma dipende dal rientro del codice sorgente anziché dagli elementi di demarcazione regolari come begin ed end.

Per utilizzare mod_python in SUSE Linux, installare l'RPM apache2-mod_python e attivare il modulo tramite YaST (Moduli) o manualmente in /etc/sysconfig/apache2. Per ulteriori informazioni sull'utilizzo del modulo, consultare la documentazione disponibile sul sito Web di mod_python (http://www.modpython.org/).

46.5.3.4. L'interprete Ruby in Apache: mod_ruby

mod_ruby ha l'interprete Ruby incorporato nel server Web Apache e consente l'esecuzione degli script CGI Ruby in modo nativo. Ruby è un linguaggio di programmazione orientato agli oggetti relativamente nuovo e di livello elevato che, per certi aspetti, assomiglia a Perl e a Python. Come Python, ha una sintassi pulita e trasparente. Ruby ha però adottato abbreviazioni (ad esempio $.r come numero dell'ultima riga letta nel file di input) apprezzate da alcuni programmatori e malviste da altri. Il concetto di base di Ruby assomiglia molto a quello di Smalltalk.

Per utilizzare mod_ruby in SUSE Linux, installare l'RPMapache2-mod_ruby e attivare il modulo tramite YaST (Moduli) o manualmente in/etc/sysconfig/apache2. Per ulteriori informazioni sull'utilizzo del modulo, consultare la documentazione disponibile sul sito Web di mod_ruby(http://www.modruby.net/en/index.rbx).

46.5.3.5. Accesso a file system nativi: mod_dav

mod_dav fornisce la funzioanlità WebDAV (Web-Based Distributed Authoring and Versioning) per Apache. WebDAV è un'estensione del protocollo HTTP che consente agli utenti di modificare e gestire in modo collaborativo file su server remoti. Le capacità di WebDAV sono analoghe a quelle di FTP con la differenza principale che HTTP viene utilizzato come protocollo sottostante per l'accesso al server. In effetti, mod_dav rende un server Web Apache un file system remoto avanzato.

È buona norma, se non richiesto, limitare l'accesso alle directory disponibili tramite WebDAV. Le precauzioni minime da prendere consistono nell'impostazione dell'autenticazione di base HTTP per la risorsa WebDAV, insieme alle clausole Limite all'interno della direttivaLocation.

Per accedere a una risorsa WebDAV, deve essere presente un software WebDAV sul lato client. SUSE Linux è già dotato delle capacità WebDAV: Per il collegamento a un file system WebDAV Apache, è possibile utilizzareKonqueror con il prefissowebdav:// owebdavs:// (per WebDAV tramite connessioni SSL).

Per mod_dav è necessario disporre del modulo mod_dav_fs, che fornisce l'accesso per WebDAV al file system effettivo. Per utilizzaremod_dav in SUSE Linux, attivare il modulo tramite YaST (Moduli) o manualmente in/etc/sysconfig/apache2. Eseguire la stessa operazione per mod_dav_fs. Per ulteriori informazioni sull'utilizzo del modulo, consultare la documentazione disponibile sul sito Web di mod_dav(http://httpd.apache.org/docs-2.0/mod/mod_dav.html).

46.5.3.6. Offerta di pagine home utente: mod_userdir

mod_userdir in SUSE Linux non prevede l'offerta dei contenuti della cartella ~/public_html di ciascun utente come pagine Web pubbliche. L'URL per accedere a queste pagine si trova quindi in http://www.example.com/~nome utente/.

[Tip]Suggerimento

Per motivi di sicurezza mod_userdir in SUSE Linux proibisce l'accesso a qualsiasi directory della directory home dell'utente root. È possibile inoltre consentire a certi utenti in particolare di avere home page pubbliche con:

# Main server context
UserDir disabled
UserDir enabled tux
				wilber
			

Per utilizzare mod_userdir in SUSE Linux, attivare il modulo tramite YaST (Moduli) o manualmente in/etc/sysconfig/apache2. Per ulteriori informazioni sull'utilizzo del modulo, consultare la documentazione disponibile sul sito Web di mod_userdir(http://httpd.apache.org/docs-2.0/mod/mod_userdir.html).

46.5.3.7. Modifica del layout dell'URL: mod_rewrite

mod_rewrite viene spesso definito «il coltellino svizzero della manipolazione dell' URL.» mod_rewrite riscrive immediatamente gli URL richiesti in base a una specifica regola impostata. Generalmente il risultato è analogo ahttp://www.example.com/2/1/de per http://www.example.com/display.php?cat=2&article=1&lang=de.

L' URL Rewriting Guide spiega i vantaggi e gli svantaggi di questo modulo potente, ma complesso:

«Con mod_rewrite o ci si tira la zappa sui piedi la prima volta che lo si usa e poi mai più, o lo si ama per sempre data la sua potenza. »

I set diRewriteRulepossono essere impostati in tutti i contesti di configurazione: per il server principale, per gli host virtuali, per le directory e per i file .htaccess. Un buon punto di partenza per la riscrittura degli URL conmod_rewrite è la URL Rewriting Guide sul sito http://httpd.apache.org/docs-2.0/misc/rewriteguide.html.

Per utilizzare mod_rewrite in SUSE Linux, attivare il modulo tramite YaST (Moduli) o manualmente in/etc/sysconfig/apache2.