Category Archives: Apache

Limitare l’upload dei file in Apache

Apache mette a disposizione la direttiva LimitRequestBody tramite cui è possibile impostare una dimensione massima ai file che possono essere caricati.

Se il client esegue l’upload di un file che supera la dimensione specificata, viene generato un errore.

Il valore di LimitRequestBody può essere compreso tra 0, che significa che non vengono impostati limiti, e 2147483647, che limita la dimensione dei file a 2gb.

Vediamo ora un esempio relativo all’utilizzo di questa direttiva.
<Directory “/var/www/html/upload”>
LimitRequestBody 102400
</Directory>

Queste righe possono essere aggiunte all’interno del file httpd.conf o all’interno di un file .htaccess e specificano che la dimensione massima dei file per cui può essere fatto l’upload all’interno della cartella /var/www/html/upload è 100kb.

ModSecurity – Permettere l’accesso a GoogleBot

Alcuni amministratori disabilitano ModSecurity sul proprio server web quando nei log vedono che Googlebot viene bloccato.

Ovviamente il mancato accesso di Googlebot al proprio sito rappresenta un problema, non è però necessario disabilitare ModSecurity, basta creare una regola per permettere l’accesso al proprio sito.

La souluzione è quindi molto semplice, basta creare la seguente regola nel file modsecurity_crs_15_customrules.conf.

SecRule REQUEST_HEADERS:User-Agent “Googlebot” “allow”

In questo modo Googlebot potrà accedere al proprio sito e sarà possibile continuare a utilizzare ModSecurity con il proprio server web Apache.

Apache e la compressione – mod_deflate

In un precedente articolo abbiamo parlato della compressione http in IIS 7, oggi vediamo come abilitare la compressione in Apache.
Questo è possibile attraverso il modulo mod_deflate.

Per quanto riguarda il funzionamento generale della compressione http vi rimandiamo al precedente articolo, vediamo ora più nel dettaglio come velocizzare apache utilizzando mod_deflate.

Come prima cosa bisogna verificare che il modulo sia installato in Apache, di default è installato con tutte le principali distribuzioni.
Se il modulo è installato, nel file di configurazione di Apache, http.conf, troveremo una riga simile alla seguente.

LoadModule deflate_module modules/mod_deflate.so

La configurazione della compressione può essere fatta in due modalità diverse, specificando in modo esplicito i tipi di file da escludere in base all’estensione o specificando in modo esplicito i tipi file da includere in base al mime type.
Bisogna inoltre considerare che è possibile abilitare la compressione per l’intero server o per un virtual host specifico.

Inclusione dei file in base al mime type

L’inclusione dei file in base al mime type avviene utilizzando una riga di configurazione simile alla seguente nel file http.conf

AddOutputFilterByType DEFLATE text/html text/plain text/xml

In questo caso si specifica che si vogliono comprimere solamente file di testo, html e xml.
Ovviamente è possibile specificare qualsiasi mime type che si vuole includere tra i file da comprimere.

Una configurazione più completa potrebbe essere quindi la seguente.

AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/atom_xml
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/x-httpd-php
AddOutputFilterByType DEFLATE application/x-httpd-fastphp
AddOutputFilterByType DEFLATE application/x-httpd-eruby
AddOutputFilterByType DEFLATE text/html

Risulta anche possibile abilitare la compressione per specifiche directory

<Directory “/web/guida”>
AddOutputFilterByType DEFLATE text/html
</Directory>

Esclusione esplicita dei file in base all’estensione
Se si vogliono comprimere tutti i tipi di file e escluderne solo alcuni, è possibile utilizzare una configurazione simile alla seguente.

SetOutputFilter DEFLATE
SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png)$
no-gzip dont-vary
SetEnvIfNoCase Request_URI
.(?:exe|t?gz|zip|bz2|sit|rar)$
no-gzip dont-vary
SetEnvIfNoCase Request_URI .pdf$ no-gzip dont-vary

In questo caso viene specificato che non bisogna comprimere i file gif, jpg, png, i file compressi e i file pdf.

Una novità interessante, introdotta a partire da Apache 2.0.45, è costituita dalla direttiva DeflateCompressionLevel tramite la quale è possibile impostare il livello di compressione di mod_deflate.
La direttiva accetta valori tra 1 e 9 e può essere specificata nel file di configurazione di apache usando la seguente riga.

DeflateCompressionLevel 9

Aumentando il livello di compressione si ottengono file di minore dimensioni da trasferire sulla rete, il processore è però sottoposto a un carico di lavoro superiore.

Al termine della configurazione è necessario riavviare apache per rendere effettive le modifiche.

Utilizzando mod_deflate è possibile comprimere i file html e di testo intorno al 20% della dimensione originale.
Bisogna considerare comunque il maggiore carico sul processore causato dal processo di compressione, è bene quindi effettuare dei test prima di abilitare queste impostazioni in produzione.

I dettagli su mod_deflate sono disponibili sul sito ufficiale di Apache.

Utilizzare Php con mod_fcgid

Mod_fcgid è un modulo di Apache che permette l’esecuzione di applicazioni esterne che creano documenti web come output.

Utilizzare Php con mod_fcgid ha come conseguenza alcuni vantaggi rispetto al normale modo di eseguire Php su un server web, risulta infatti possibile eseguire versioni diverse di Php sullo stesso server e di utilizzare utenti diversi per l’esecuzione.

Inoltre mod_fcgid può essere eseguito su un server web Apache multi thread e garantisce quindi ottime prestazioni.

Vediamo quindi come installare mod_fcgid su un server Debian con Apache.
I pacchetti necessari sono php5-cgi, libapache2-mod-fcgid e apache2-mpm-worker.
Apache2-mpm-worker è il modulo multi processing multi thread per Apache, sostituisce apache2-mpm-prefork che è il modulo multi processing single thread richiesto da mod_php4 e mod_php5.
apt-get -u install php5-cgi libapache2-mod-fcgid apache2-mpm-worker

A questo punto è possibile eliminare mod_php4 e mod_php5
a2dismod php4
a2dismod php5

Abilitare mod_actions e mod_fcgid
a2enmod actions
a2enmod fcgid

Aumentare il valore relativo al tempo massimo di esecuzioni per le applicazioni FCGI, per fare questo è necessario modificare il file /etc/apache2/mods-enabled/fcgid.conf aggiungendo la direttivaIPCCommTimeout

<IfModule mod_fcgid.c>
AddHandler fcgid-script .fcgi
SocketPath /var/lib/apache2/fcgid/sock
IPCCommTimeout 60
#IPCConnectTimeout 3
</IfModule>

Creare il file /etc/apache2/conf.d/php-fcgid.conf con il seguente contenuto.
<IfModule !mod_php4.c>
<IfModule !mod_php4_filter.c>
<IfModule !mod_php5.c>
<IfModule !mod_php5_filter.c>
<IfModule !mod_php5_hooks.c>
<IfModule mod_actions.c>
<IfModule mod_alias.c>
<IfModule mod_mime.c>
<IfModule mod_fcgid.c>
# Path to php.ini – defaults to /etc/phpX/cgi
DefaultInitEnv PHPRC=/etc/php5/cgi

# Number of PHP childs that will be launched. Leave undefined to let PHP decide. 
#DefaultInitEnv PHP_FCGI_CHILDREN 3

# Maximum requests before a process is stopped and a new one is launched 
#DefaultInitEnv PHP_FCGI_MAX_REQUESTS 5000

# Define a new handler “php-fcgi” for “.php” files, plus the action that must follow 
AddHandler php-fcgi .php
Action php-fcgi /fcgi-bin/php-fcgi-wrapper

# Define the MIME-Type for “.php” files 
AddType application/x-httpd-php .php

# Define alias “/fcgi-bin/”. The action above is using this value, which means that 
# you could run another “php5-cgi” command by just changing this alias
Alias /fcgi-bin/ /var/www/fcgi-bin.d/php5-default/

# Turn on the fcgid-script handler for all files within the alias “/fcgi-bin/” 
<Location /fcgi-bin/>
SetHandler fcgid-script
Options +ExecCGI
</Location>
</IfModule>
</IfModule>
</IfModule>
</IfModule>
</IfModule>
</IfModule>
</IfModule>
</IfModule>
</IfModule>

A questo punto è possibile creare la directory specificata nella direttiva alias nel file di configurazione e creare un link simbolico a php5-cgi
mkdir /var/www/fcgi-bin.d/php5-default
ln -s /usr/bin/php5-cgi /var/www/fcgi-bin.d/php5-default/php-fcgi-wrapper

Riavviare Apache
/etc/init.d/apache2 restart

Risolvere l’errore subsys locked

Quando si riavvia Apache è possibile che si verifichi l’errore  subsys locked e che il server web non possa quindi essere fatto partire.

L’errore è relativo al metodo utilizzato da diverse applicazioni per verificare che solo un processo sia in esecuzione.

Quando il programma si avvia, crea un particolare tipo di file, chiamato file di lock.
L’applicazione non può essere avviata se esiste già un file di lock.

Il file dovrebbe essere eliminato quando l’applicazione viene chiusa, in alcuni casi però questo non succede e si ottiene l’errore indicato in precedenza.

Per risolvere l’errore subsys locked è quindi necessario cancellare il file httpd presente nella cartella /var/lock.
Dopo che si è fatto questo, dovrebbe essere possibile avviare Apache.

Apache – Configurare MPM prefork

Apache mette a disposizione due Multi Processing Module, MPM Worker e MPM Prefork.
I multi Processing Module si occupano di gestire l’avvio dei processi di apache e specificano il modo in cui devono essere gestile le connessioni.

I due MPM disponibili in Apache funzionano in modo differente.

Utilizzando MPM Worker vengono creati diversi processi figli di Apache e ognuno di questi processi può contenere più thread, e gestire quindi più connessioni.
Anche utilizzando MPM Prefork vengono creati diversi processi figli di Apache ma oguno di questi può contenere un solo thread e gestire una sola connessione.

La conseguenza del diverso funzionamento è che MPM Worker permette un minore consumo di risorse, i thread consumano meno meno memoria dei processi,  ma può comportare alcuni problemi di compatibilità con altre applicazioni.
In particolare se si vuole eseguire PHP risulta necessario utilizza FastCGI.

In questo articolo analizziamo la configurazione di prefork e vediamo come ottimizzare Apache.

Nel file di configurazione httpd.conf i parametri relativi a prefork sono definiti in questa sezione.

<IfModule prefork.c>
StartServers       8
MinSpareServers    5
MaxSpareServers   20
ServerLimit      256
MaxClients       256
MaxRequestsPerChild  4000
</IfModule>

Vediamo quindi il significato dei vari parametri.
StartServers specifica il numero di processi figli che devono essere creati all’avvio di Apache.
La creazione di un processo richiede un certo quantitativo di risorse, se questo valore è troppo basso e il server riceve un numero elevato di richieste, si possono avere rallentamenti quando si riavvia Apache.
MinSpareServers specifica il numero minimo di processi figli che devono essere creati e essere in attessa di connessioni. Risulta consigliabile non impostare un valore troppo basso per evitare di avere problemi nel caso si verifichi un aumento improvviso del traffico.
MaxSpareServers specifica il numero massimo di processi figli che devono essere creati e essere in attesa di connessioni. Se il valore è troppo basso c’è il rischio che per alcuni utenti il sito risulti irraggiungibile.
MaxClients specifica il numero massimo di richieste simultanee che il server è in grado di servire, tutte le connessioni oltre il limite definito da questo parametro vengono messe in coda.
Risulta importante notare che il parametro indica il numero massimo di richieste http che possono essere servite contemporaneamente e non il numero massimo di connessioni, una volta che una richiesta è stata servita, e la connessione al sito stabilita, la richiesta è considerata idle e può esserne servita un’altra.

Come trovare il valore da assegnare a MaxClients?
Assegnare il valore corretto a MaxClients è importante, un valore troppo basso può avere come conseguenza l’irraggiungibilità del sito da parte degli utenti durante momenti in cui il traffico è elevato, un valore troppo elevato può invece portare al consumo di tutta la memoria del sistema e al blocco del server.

Per calcolare il valore da assegnare a MaxClients, e anche a ServerLimit, è possibile analizzare la memoria disponibile sul server e il consumo di un singolo processo httpd.
Come prima cosa verifichiamo quanta memoria libera è presente sul server quando apache non è in esecuzione.
free -m
total       used       free     shared    buffers     cached
Mem:          2048        753       1294          0         48        499

A questo punto avviamo apache e controlliamo il consumo medio di memoria di un processore httpd.
top -b -c -n 1 | grep httpd | awk ‘{print $6}’
18m
18m
18m
18m
21m
18m
19m
18m
18m

In questo caso vediamo come  ogni processo consumi circa 18 mb di memoria.
A questo punto possiamo calcolare il valore da assegnare a MaxClients dividendo 1270, teniamo conto di volere almeno 20 mb liberi quando Apache è utilizzato al massimo, per 18.

Apache e virtual host

I virtual host sono una funzionalità presente in quasi tutti i server web di oggi, e anche in Apache, tramite la quale è possibile utilizzare un’unica istanza di un server per più siti.
La conseguenza di questo è una semplificazione dell’amministrazione e un utilizzo più efficiente delle risorse di sistema.

In Apache troviamo due tipologie di virtual host, quelli basati su Ip e quelli basati su Nome.

Virtual Host basati su Ip
Apache permette di utilizzare la combinazione di indirizzo ip e porta che il client utilizza per connettersi a un sito per creare dei virtual host.
Questi vengono definiti utilizzando le sezioni <VirtualHost>. Ogni sezione <VirtualHost> contiene i parametri di configurazione che devono essere applicati quando il server riceve una richiesta per l’ip e la porta specificati nella riga iniziale.

Vediamo ora un esempio in cui vengono configurati due diversi virtual host basati sull’indirizzo ip, il primo per il sito www.prova1.com e il secondo per il sito www.prova2.com.
Prima delle sezioni <VirtualHost> è necessario specificare le porte su cui Apache è in ascolo utilizzando la direttiva Listen.

Listen 8080
Listen 80

La riga iniziale delle sezioni <VirtualHost> specifica l’indirizzo ip e, se è necessario, la porta del virtual host.

<VirtualHost 192.168.1.2:8080>

All’interno della sezione troviamo poi la direttiva ServerName che specifica l’indirizzo del sito web relativo al virtual host e la direttiva DocumentRoot tramite la quale è possibile indicare in quale directory si trova il contenuto di ogni virtual host.

ServerName www.prova2.com
DocumentRoot /usr/local/apache/sites/prova2

Il risultato finale sarà quindi simile al seguente.

Listen 8080
Listen 80
<VirtualHost 192.168.1.1>
ServerName www.prova1.com
DocumentRoot /usr/local/apache/sites/prova1
</VirtualHost>

<VirtualHost 192.168.1.2:8080>
ServerName www.prova2.com
DocumentRoot /usr/local/apache/sites/prova2
</VirtualHost>

I virtual host basati su indirizzo ip sono quindi molto semplici da configurare, lo svantaggio è che è necessario che il server disponga di più indirizzi ip o utilizzare porte non standard.

Virtual Host basati su Nome
Se si ha la necessità di ospitare più siti su un server che dispone di un solo indirizzo ip, la soluzione consiste nell’utilizzare i virtual host basati su nome.

Questo tipo di virtual host utilizza una caratteristica dei browser, questi infatti trasmettono un header Host: quando inviano una richiesta http.
Risulta quindi possibile configurare Apache in modo che venga visualizzato un contenuto diverso a seconda delle informazioni contenute nell’header della richiesta http.

La configurazione dei virtual host basati su nome è simile a quella vista in precedenza.
In questo esempio il sito www.prova1.com e il sito www.prova2.com utilizzano lo stesso indirizzo ip.
Quando Apache riceve una richiesta da un browser, il server confronta il valore dell’header Host: con il nome specificato dalle direttive ServerName e ServerAlias.

NameVirtualHost 192.168.1.1
<VirtualHost 192.168.1.1>
ServerName www.prova1.com
ServerAlias prova.com test.prova.com
DocumentRoot /usr/local/apache/sites/prova1.com
</VirtualHost>

<VirtualHost 192.168.1.1>
ServerName www.prova2.net
DocumentRoot /usr/local/apache/sites/prova2.net
</VirtualHost>

La direttiva NameVirtualHost specifica che un determinato indirizzo Ip viene utilizzato per virtual host basati sul nome.
Utilizzando la direttiva NameVirtualHost * è possibile specificare che tutti gli indirizzi ip vengono utilizzati per virtual host basati sul nome.

Cosa succede se una richiesta non corrisponde a nessuno dei virtual host specificati nel file di configurazione?
In questo caso viene utilizzato il primo virtual host basato sul nome presente nel file di configurazione.

Ottimizzare Apache per WordPress

WordPress è una delle applicazioni più utilizzate online, se si passa da un hosting condiviso a un VPS, risulta importante ottimizzare Apache per ottenere prestazioni migliori con WordPress.

In questa breve guida vediamo come configurare Apache su un VPS con risorse limitate in modo da migliorare le prestazioni di WordPress.

Moduli
Il primo elemento da considerare è il numero di moduli attivi, nella configurazione di default di Apache sono presenti infatti molti moduli che non risultano necessari e che causano un maggiore consumo di risorse.
Risulta importante quindi disabilitare i moduli di Apache non utilizzati, per fare questo basta aprire il file di configurazione httpd.conf e inserire il simbolo # all’inizio della riga LoadModule in cui viene caricato il modulo che si vuole disabilitare.

#LoadModule auth_basic_module modules/mod_auth_basic.so

In un sito basato su WordPress generalmente basta che siano abilitati i seguenti moduli.
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule expires_module modules/mod_expires.so
LoadModule deflate_module modules/mod_deflate.so
LoadModule headers_module modules/mod_headers.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule mime_module modules/mod_mime.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule dir_module modules/mod_dir.so
LoadModule alias_module modules/mod_alias.so
LoadModule rewrite_module modules/mod_rewrite.so

In questo casosi  è quindi anche commentata la riga
#LoadModule negotiation_module modules/mod_negotiation.so
Il modulo negotiation_module viene utilizzato pagine multilingua, se si disabilita questo modulo, è necessario eseguire delle operazioni aggiuntive.
Bisogna infatti commentare anche le seguenti righe presenti nel file httpd.conf
#LanguagePriority en ca cs da de el eo es et fr he hr it ja ko ltz nl nn no pl pt pt-BR ru sv zh-CN zh-TW
#ForceLanguagePriority Prefer Fallback

Prima di disabilitare i moduli è sempre consigliabile fare un backup del file di configurazione per poterlo ripristinare in caso di necessità, è infatti possibile che alcuni plugin di WordPress richiedano moduli che sono stati disattivati.

MPM Prefork
Il modulo MPM Prefork gestisce il numero di processi avviati da Apache, su un VPS con risorse limitata risulta importante configurare in modo corretto il modulo per migliorare le prestazioni del server.

Nel file httpd.con sono presenti le seguenti righe.
<IfModule prefork.c>
StartServers       8
MinSpareServers    5
MaxSpareServers   20
ServerLimit      256
MaxClients       256
MaxRequestsPerChild  4000
</IfModule>

MinSpareServers e MaxSpareServers specificano il numero minimo e il numero massimo di processi in attesa di richieste che il server può eseguire mentre StartServers indica il numero di processi avviati di default.
MaxClient specifica il numero massimo di richieste che possono essere gestite dal server, si tratta di un parametro molto importante.
Se si ha un aumento improvviso del traffico e MaxClients ha un valore troppo elevato, viene consumata tutta la memoria con il conseguente rischio di blocco di Apache.
Per calcolare il valore da assegnare a MaxClients, bisogna dividere il totale della memoria disponibile del server per la quantità di memoria consumata da un processo di Apache.
Se sul server sono disponibili 500mb di Ram per Apache e ogni processo consuma 10mb, il valore da impostare è 50.

I valori per il modulo MPM Prefork devono quindi essere modificati in base alle risorse disponibili sul proprio server.
<IfModule prefork.c>
StartServers       3
MinSpareServers    3
MaxSpareServers   10
ServerLimit      50
MaxClients       50
MaxRequestsPerChild  2000
</IfModule>

Ottimizzare KeepAlive
KeepAlive permette ai visitatori di utilizzare la stessa connessione TCP per inviare richieste multiple, questo dovrebbe permettere di ridurre la latenza per i documenti HTML con molte immagini.
Bisogna però considerare che Apache utilizza un processo per ogni richiesta, abilitando KeepAplive un processo rimane attivo per quindici secondi di default, questo anche non è più utilizzato, la conseguenza è che vengono utilizzate molte risorse di sistema.
Generalmente su un VPS con risorse limitate, è consigliabile disabilitare KeepAlive nel file di configurazione httpd.conf
KeepAlive Off

Se si ha un sito con molte immagini, può risultare utile avere KeepAlive attivato.
In questo caso è però importante cambiare il valore KeepAliveTimeout che stabilisce per quanti secondi devono rimanere aperte le connessioni.
KeepAliveTimeout 2

Timeout
Un ultimo parametro che è possibile modificare per ottimizzare Apache per WordPress, è Timeout.
Questo parametro stabilisce il numero di secondi per cui Apache deve aspettare quando riceve una richiesta e la elabora.
Il vaore di default è 120 e può essere abbassato.
Timeout 40

Modificando il file di configurazione httpd.conf risulta quindi possibile ottimizzare Apache per WordPress.

Configurazione di ModSecurity

Una vota compilato e installato ModSecurity, è possibile effettuare la configurazione iniziale creando un file modsecurity.conf nella cartella /etc/httpd/conf.d

<IfModule security2_module>
SecRuleEngine On
SecDefaultAction “phase:2,deny,log,status:403″
SecRequestBodyAccess On
SecDebugLog logs/modsec_debug.log
SecDebugLogLevel 0
</IfModule>

SecRuleEngine On attiva l’elaborazione delle regole di ModSecurity, l’elaborazione viene disattivata impostando off come valore mentre usando DetectionOnly come valore è possibile fare in modo che le regole vengano processate senza che vengano eseguite operazioni, una modalità utile per verificare il funzionamento.
SecDefaultAction specifica cosa deve essere fatto quando una richiesta http corrisponde a una regola presente.
In questo caso è stato specificato che la richiesta viene rifiutata con un errore 403 e viene registrata nel file di log.
Le azioni possibili sono le seguenti
pass – La richiesta viene autorizzata e viene continuato il controllo delle altre regole.
allow – In questo caso la richiesta viene accettata e inoltrata al server web, non vengono verificate altre regole.
deny – Interrompe l’elaborazione della richiesta. Viene restituito il valore specificato da status.
status – Specifica il codice da restituire quando una richiesta viene rifiutata.
exec – Esegue un file binario quando la regola corrisponde alla richiesta.
log – Scrive nel file di log.
nolog – Non salva l’informazione nel file di log.
chain – Permette la concatenazione di più regole.
auditlog – L’informazione viene salvata nel file di audit.
noauditlog – L’informazione non viene salvata nel file di audit.

Il valore phase:2 specifica la fase di default in cui vengono processate le regole, ModSecurity divide infatti l’elaborazione delle richieste http in cinque fasi.
1 – REQUEST_HEADERS – Dopo che Apache ha letto gli header della richiesta.
2 – REQUEST_BODY – Dopo che il body è stato letto.
3 – RESPONSE_HEADERS – Dopo che i response header sono stati inviati al client.
4 – RESPONSE_BODY – Dopo che il response body è stato inviato al client.
5 – LOGGING – Prima della registrazione dei log.

La direttiva SecRequestBodyAccess on attiva l’elaborazione del body delle richieste http in modo da permettere l’analisi degli upload effettuati attraverso le richieste POST.
Attivando questa direttiva, ModSecurity salva la richiesta in memoria e l’analizza prima di inoltrarla al server web.
SecDebugLogLevel 0 indica che non vengono salvate informazioni di debug mentre SecDebugLog specifica il file in sui salvare le informazioni di debug quando l’opzione è attiva.

Reinstallare Apache

In un ambiente di test, è frequente che vengano provate nuove configurazioni di Apache e degli altri componenti del sistema operativo.
Può quindi anche succedere di trovarsi nella situazione in cui il servizio non si avvia più e non si riesce a trovare la soluzione al problema.

In assenza di alternative, si potrebbe quindi essere costretti a reinstallare Apache.
La reinstallazione di Apache su Linux risulta essere piuttosto rapida e semplice.

Come prima cosa bisogna rimuovere il server web utilizando il seguente comando
sudo apt-get remove –purge apache2 apache2-utils
In questo modo vengono cancellati tutti i file di configurazione e le directory.

L’operazione successiva consiste nell’installazione.
sudo apt-get install apache2
Con questo comando vengono create le directory e i file di configurazione con i valori di default.