Apache2

Apache 2.x - Appunti di gestione/configurazione

Duplicare l'istanza di Apache

Per la duplicazione dell'istanza di Apache, fare riferimento al tutorial specifico.

Server virtuali

SSL: Configurazione certificato

Per la parte relativa alla richiesta del certificato, fare riferimento alla sezione apposita nel Wiki Sitech.

Per l'installazione del certificato ipotizziamo di avere i certificati emessi e firmati disponibili nella cartella /tmp/holdcerts e i file di configurazione di apache 2 (SuSe) installati nella cartella /etc/apache2. Negli esempi che seguono, [host_domain_tld] va sostituito con il nome dell'host di dominio virtuale (Es: webmail.netsitech.com).

• Installazione della key nel host virtuale

cd /tmp/holdcerts
mv server.csr /etc/apache2/ssl.csr/[host_domain_tld].csr
mv server.crt /etc/apache2/ssl.crt/[host_domain_tld].crt
mv server.key /etc/apache2/ssl.key/[host_domain_tld].key
mv server.key.secure /etc/apache2/[host_domain_tld].key.secure

chmod 400 /etc/apache2/ssl.csr/[host_domain_tld].csr
chmod 400 /etc/apache2/ssl.crt/[host_domain_tld].crt
chmod 400 /etc/apache2/ssl.key/[host_domain_tld].key
chmod 400 /etc/apache2/[host_domain_tld].key.secure

• Modifiche da apportare al file di configurazione del VirtualHost specifico

SSLCertificateFile /etc/apache2/ssl.crt/[host_domain_tld].crt SSLCertificateKeyFile /etc/apache2/ssl.key/[host_domain_tld].key

Configurazione di un proxy (http front-end processor)

Definizione sul server di front-end

Esempio di definizione di un server virtuale di front-end che risponde all'indirizzo http://wiki.netsitech.com o http://wiki.sede.netsitech.com che inoltra le richieste al server di back-end http://wiki.dmz.sede.netsitech.com
<VirtualHost *:80>

   ServerAdmin webmaster@netsitech.com

   ServerName wiki.netsitech.com
   ServerAlias wiki.sede.netsitech.com

   ProxyPass / http://wiki.dmz.sede.netsitech.com/
   ProxyPassReverse / http://wiki.dmz.sede.netsitech.com/

</VirtualHost>

Definizione sul server di back-end

Il problema principale da risolvere è quello degli indirizzi IP del client, che in condizoni normali non vengono memorizzati nei log di accesso in quanto le chiamate vengono loggate come effettuate da un indirizzo client corrispondente al server di front-end.

Warnings:

   * There is a solution which replaces the client IP used everywhere in apache with the X-Forwarded-For value if it exists. But this solution is to use just with trusted proxy, else it would be a security hole.
   * X-Forwarded-For is a header field and then can be forged, don't use it for legal or security reason.

Solution:

1. Definire due LogFormat, uno con l'IP dell'host che genera la chiamata, un altro con l'IP contenuto nel tag X-Forwarded-For inserito dal proxy:

LogFormat "%h %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-agent}i\"" combined
LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-agent}i\"" combined_forwarded

1. Definire una variabile di ambiente nel caso in cui il proxy sia stato utilizzato:

# Log the originating ip if use a proxy
SetEnvIfNoCase X-Forwarded-For "." from_proxy=1

1. Utilizzare un log differente a seconda del valore di from_proxy:

CustomLog /var/log/wiki/apache-access.log combined env=!from_proxy
CustomLog /var/log/wiki/apache-access.log combined_forwarded env=from_proxy

1. Riavviare il server

apachectl restart

La configurazione finale assomiglierà a questa:

<VirtualHost *:80>
    ServerName wiki.netsitech.com
    ServerAlias wiki.dmz.sede.netsitech.com
    ServerAlias wiki.sede.netsitech.com
    ...
    LogFormat "%h %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-agent}i\"" combined
    LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-agent}i\"" combined_forwarded

    SetEnvIfNoCase X-Forwarded-For "." from_proxy=1

    CustomLog /var/log/wiki/apache-access.log combined env=!from_proxy
    CustomLog /var/log/wiki/apache-access.log combined_forwarded env=from_proxy
    ...
</VirtualHost>

Workaround

Nella configurazione di Apache ocn MOD_DBD e MOD_AXIS con autenticazione LDAP, nel caso in cui si verifichi anche solo uno dei seguenti errori, fare attenzione all'ordine di caricamento dei moduli dbd e axis Internal error: DBD: Can't connect to freetds Internal error: DBD: failed to initialise Internal error: DBD: child init failed! oppure

 require directives present and no Authoritative handler.

L'ordine (apparentemente) funzionante sembra essere il seguente: Include /etc/apache2/mod_axis2.conf Include /etc/apache2/mod_dbd.conf AL CONTRARIO se invece non è stata abilitata alcuna autenticazione, può essere necessario avere le righe in questo ordine:

Include /etc/apache2/mod_dbd.conf Include /etc/apache2/mod_axis2.conf Grazie a chi ci ha omaggiato di questo bellissimo comportamento!!!!