8.1.1. Struttura del web

Nel pensare la configurazione dei vari server web sulle diverse macchine, è stato necessario anche ripensare all'organizzazione dei domini "infrastrutturali" che serviamo, particolarmente in relazione al protocollo https, che dà in effetti alcuni problemi se gestito nel modo in cui abbiamo fatto per anni: cioè fornendo i vari servizi privati (webmail, servizio di cambio della password, "gatti" per le password perdute, accessi mysql, etc...) su domini di secondo livello differenti: webmail.dominio.org, squirrel.dominio.org, passwd.dominio.org e molti altri.

Sfortunatamente il certificato SSL che il server web utilizza contiene un solo hostname (nell'attributo CN), con cui il browser confronta la URL e in caso siano differenti visualizza un messaggio allarmante di avviso all'utente, anche se questo ha installato il certificato della CA. Questo vanifica in un certo modo il fatto stesso di spingere gli utenti ad installare la chiave della CA e ad utilizzare la struttura di PKI in modo corretto.

Questo problema si può risolvere in almeno due modi: il primo comporta l'utilizzo dei cosiddetti certificati wildcard, ovvero ad esempio un certificato per *.dominio.org, che sarà valido per tutti gli host compresi in dominio.org. Questo trucco, benché paia godere di uno status un po' oscuro negli RFC, funziona con la stragrande maggioranza dei browser.

Noi però, anche per approfittare di questa occasione per fare ordine nell'organizzazione stessa dei siti, abbiamo preferito un altro approccio: si è infatti deciso di accorpare i vari sottodomini su di un unico dominio, www.dominio.org. Inoltre, dato che è necessario comunque raggiungere ciascuna singola macchina in modo indipendente, ogni macchina risponde anche ad un indirizzo wwwN.dominio.org, dove N è un numero. Fortunatamente un'estensione molto popolare delle specifiche X509 (subjectAltNames) ci permette di aggiungere, nel certificato del web server, qualche (il numero è limitato) altro nome di dominio, per cui si può creare un certificato, ad esempio per www.dominio.org, www1.dominio.org, www2.dominio.org eccetera, in modo che in ogni caso tutte le transazioni su protocollo HTTPS possano essere correttamente validate con la semplice installazione del certificato della CA.

8.1.2. Configurazione

La configurazione di Apache 2 è stata progettata per inserirsi nello schema modulare utilizzato da Debian: dunque è strutturata in questo modo: (la directory apache2 qua sotto è quella che si trova in /configfiles/ring0/common)

• apache2/apache2.conf - file di configurazione principale di apache2, direttive generiche sul funzionamento del server

• apache2/virtualhost-template - questo file serve da modello per la generazione automatica della configurazione dei virtual host: tutti i siti presenti nel database vengono generati sostituendo alcuni valori specifici in questo file (il nome dell'host ed il percorso del file di log, ad esempio) ed eventualmente integrando i relativi frammenti di configurazione dai files in apache2/conf.d/extra.

• apache2/include/ - pezzetti di configurazione ripetuti molto spesso, che fa comodo raggruppare autonomamente: per esempio le direttive per configurare PHP per un sito, oppure per bloccare i robot rompiballe, etc:

  • include/dominio-auth.conf - limita l'accesso agli utenti del dominio dominio.org, includendo questo file nelle parti di configurazione desiderate è possibile restringere l'accesso a parti del sito (preferibilmente sotto https) ai soli amministratori:

             <Location "blahblah">
               Include /etc/apache2/include/dominio-auth.conf
             </Location>

  • include/cache.conf - abilita la cache dei contenuti (per le location dove uno dovesse fare da reverse proxy)

  • include/coral.conf - pezzo di configurazione da abilitare quando eventualmente dovessimo morire di eccessive richieste, redirige tutto sulla cache distribuita Coral

  • include/php-common.conf - configurazione standard di PHP

  • include/stop-robots.conf - blocca alcuni robots particolarmente rompicoglioni

• apache2/mods-enabled/ - pezzi di configurazione che abilitano i vari moduli da caricare (.load) e eventualmente ne configurano le caratteristiche generali (.conf): invece di manipolarli con a2enmod questi li gestiamo con CFengine

• apache2/sites-available/ - configurazione dei virtualhost strutturali, questi vanno poi abilitati sulle varie macchine con il comando a2ensite (questo a mano, che può darsi che non su tutte le macchine debbano andare gli stessi virtualhost): il che equivale semplicemente a fare un link al file relativo nella directory sites-enabled

• apache2/conf.d/ - roba che viene inclusa dagli altri file nei posti opportuni

  • conf.d/ssl/ - vari moduli di configurazione per i vari servizi che girano sotto https su questa macchina (cioè su wwwN.dominio.org)

  • conf.d/virtualhosts/ - virtualhost degli utenti (generati automaticamente)

  • conf.d/subsites-dominio/ - sottositi di dominio.org (generati automaticamente)

  • conf.d/subsites-public/ - sottositi di public.org (generati automaticamente)

  • conf.d/extra/ - in questa directory stanno files con eventuali direttive di configurazione che si vogliono aggiungere a mano per qualche sito particolare (il file deve avere il nome del dominio per i virtualhost, e il nome dell'alias per i sottositi, più l'estensione .conf; verrà inserito in un punto opportuno del file di configurazione)

L'obbiettivo che si è cercato di raggiungere era di avere una distribuzione approssimativamente uniforme delle richieste degli utenti sui vari server utilizzando il round-robin DNS (cioè la possibilità di fornire al client gli indirizzi IP in un ordine casuale all'atto della risoluzione). Questo approccio va bene per il contenuto statico, o comunque in sola lettura, perché per quanto riguarda le applicazioni web, nel momento in cui si effettua un login e si genera una sessione è auspicabile che l'utente venga indirizzato sempre verso la stessa macchina (anche se in genere può non avere importanza quale), così che l'accesso ai dati di sessione sia sempre locale (dunque veloce).

Per fare questo, dopo il round-robin DNS si utilizzano delle redirezioni HTTP, strutturate in questo modo:

• Un file /etc/apache2/servers_map definisce l'insieme dei server su cui è disponibile una certa applicazione. Contiene linee del genere (una per ciascun differente insieme di server che si vuole definire):

        pool    www1|www2|www3
  	    

• Nella configurazione del virtual host principale (www.dominio.org) sono presenti queste direttive:

        RewriteEngine On
        RewriteMap servers rnd:/etc/apache2/servers_map
        RewriteRule ^(/app.*)$ https://${servers:pool}.dominio.org$1 [R,L]
  	    

  che hanno l'effetto di redirigere su un server a caso (preso dall'insieme denominato pool) tutte le richieste per /app. In questo modo l'utente viene rediretto ad un server specifico per tutto il resto dell'interazione con l'applicazione.

8.1.3. Applicazioni distribuite

Vista la possibilità, abbiamo considerato senz'altro interessante installare alcuni applicativi (ad esempio il pannello di controllo per gli utenti, essenzialmente un'interfaccia al database LDAP, oppure il blog) contemporaneamente su tutti i server, per garantirne la funzionalità anche in caso una macchina non dovesse essere raggiungibile per brevi periodi.

Il software "normale", per essere utilizzato in questo modo, ha bisogno di alcune modifiche, principalmente la separazione delle query di scrittura e di lettura sui database MySQL (supponendo che il database sia replicato in modalità single-master), e la possibilità di "trasferire" le sessioni da una macchina all'altra, necessità questa dovuta al fatto che in ogni caso alcuni servizi devono essere localizzati con precisione su una specifica macchina che può essere diversa da quella su cui l'utente effettua il login iniziale.

Per questo secondo problema, la soluzione più comune (un database SQL centralizzato, o replicato) non ci avrebbe soddisfatto per via dell'elevato consumo di banda interno (non è pensabile che nelle condizioni date si possa effettuare una query mysql remota ad ogni accesso ad una pagina web), dunque è stato sviluppato un meccanismo apposito, che utilizza dei cookie di autenticazione che vengono consultati, come un meccanismo di autenticazione "trasparente", solo nel passaggio da una macchina all'altra. Intercettando le funzioni di login delle varie applicazioni, quando si riscontra un cookie di autenticazione valido viene ricreata una nuova sessione sul server di destinazione.