Un’approfondita analisi condotta da Giulio Destri su come affrontare le problematiche di gestione di infrastrutture IT basate su software open source

[section_title title=La soluzione è open source? Parte 6]

Un case study: Web server Internet

Consideriamo il caso di un server Web di produzione che deve fornire l’infrastruttura per applicazioni PHP/CMS e Java con DBMS MySQL e/o Postgres. I componenti esterni, esposti alla rete, devono essere aggiornati di frequente in base ai bollettini di sicurezza ed alle patch rilasciate dai produttori. La piattaforma di base è la distribuzione standard CentOS, in quanto la creazione da zero di un’intera distribuzione è molto dispendiosa e non aggiunge vantaggi a quanto si fa col resto del metodo. Il firewall è IPTables, legato al kernel della distribuzione.

Essendo presenti dei bug in uno dei componenti necessari per Java, è stato scelto di procedere all’installazione di componenti compilati direttamente da sorgenti dove necessario. Si suddividono i componenti dell’infrastruttura in due: quelli relativi ai servizi interni, non accessibili direttamente dalla rete, per i quali si tengono i componenti della distribuzione, e quelli dei servizi accessibili dall’esterno, che vengono installati a partire dai sorgenti ed aggiornati periodicamente in base a segnalazioni dei bollettini di sicurezza o per altre necessità.

Riassumendo quindi, il dettaglio degli strati, rappresentato in figura 8, prevede:

  • Elementi interni
    –       Kernel (e IP Tables): aggiornamenti in base alla distribuzione
    –       Compilatori e librerie: aggiornamenti in base alla distribuzione
    –       DBMS: si seguono bollettini ed annunci e si segue la distribuzione
  • Elementi accessibili dall’esterno
    –       Librerie (ZLib, OpenSSL…): usate dagli applicativi Web, SSH, PHP dovrebbero essere compilate dai sorgenti ed aggiornate in base alle segnalazioni dei produttori
    –       SSH/SFTP e FTP: SSH è la chiave di accesso al sistema in quanto il protocollo SSH/SFTP permette di usare accesso crittato e basato su gestione chiavi per l’autenticazione; viene aggiornato di frequente dal produttore, molto meno nelle distribuzioni, per cui deve essere aggiornato compilando dai sorgenti;
    –       Lo stesso, più raramente, vale per FTP;
    –       Server Web Apache: è il punto principale visibile dall’esterno per il sistema e deve essere sempre sicuro; gli aggiornamenti, forniti dal consorzio Apache, sono frequenti e molto rapide sono le risposte a segnalazioni di vulnerabilità, mentre sono non molto frequenti nella distribuzione; si fa quindi la compilazione da sorgenti con attivazione dei moduli che servono, in particolare per la connessione a Java (mod_jk);
    –       PHP: è il motore run-time per le applicazioni PHP, altro punto critico per il sistema; è robusto, aggiornato frequentemente, in evoluzione tecnica frequente; viene aggiornato molto di rado nelle distribuzioni e quindi deve essere compilato da sorgenti o prelevato come package RPM extra-distribuzione; la sua compilazione dipende da molte librerie, che dovranno essere opportunamente gestite anch’esse;
    –       Java: la versione ufficiale Oracle non fa parte delle distribuzioni e deve essere prelevata ed aggiornata a parte; esiste sia il package rpm sia il file auto espandente;
    –       Tomcat: è il contenitore infrastrutturale per gli applicativi Web Java e viene aggiornato di frequente dal Consorzio Apache che lo gestisce; viene invece aggiornato molto di rado nelle distribuzioni ed è bene gestirlo manualmente.

Soluzione open source 8

Figura 8: Schema logico dei componenti software per una piattaforma Web di produzione per applicativi realizzati con Java su Tomcat e PHP. Gli strati indicati in azzurro (compilatori, librerie di base e kernel) sono quelli originali della distribuzione e gestiti con i meccanismi della distribuzione, gli strati superiori sono gestiti tramite script.

Come si può organizzare la gestione? Un aggiornamento di package a partire da file RPM sovrascriverebbe le installazioni standard della distribuzione, con qualche rischio per la parte di applicativi che vogliamo conservare.

Pertanto è preferibile realizzare una sovrastruttura ad hoc per gli strati superiori della figura 8, quelli che riguardano i servizi accessibili dalla rete pubblica. Per farlo si sfrutta la cartella di sistema “/opt”, nata appunto per le installazioni “opzionali” (si veda [8] per tutti i dettagli):

  • L’installazione di tutti i package mantenuti “a mano” non viene fatta in /usr né in /usr/local, ma entro la cartella /opt.
  • Ogni applicazione viene installata in un proprio albero di cartelle, indipendente dalle altre e da eventuali altre versioni, ottenuto dalla configurazione, dalla compilazione e dal make install, ove presente nel pacchetto dei sorgenti.
  • Per ogni applicazione individuata come necessaria per il server Web, viene creata la seguente struttura in /opt:/opt/<nome applicazione>/<versione>/<insieme di cartelle dell’applicazione>
    Ad esempio, per il server web apache, se la versione usata è la 2.2.25, la struttura diventa, per la cartella iniziale o radice di Apache /opt/apache/2.2.25
    Entro la quale poi stanno le sottocartelle bin, conf ecc…
    Analogamente, per PHP versione 5.3.9, la cartella iniziale diventa/opt/php/5.3.9
    Qualora sia necessaria la visibilità degli eseguibili così installati a livello globale, si crea un link ad essi entro la cartella /usr/local/bin o /usr/local/sbin
    Si modificano e/o creano gli script dei servizi inserendo in essi i riferimenti ai link e/o alle cartelle reali dell’applicazione che viene da essi controllata.

Conclusioni

La metodologia presentata è stata impiegata su server Web di produzione dal 2004 in poi e in varie occasioni per server intranet. E’ stata applicata anche per installazioni “molto particolari” come .NET per Linux (MONO, non supportato come package nella distribuzione RedHat/CentOS).

La metodologia porta diversi vantaggi: una volta costruite le matrici di compatibilità e noti applicativi e librerie è prevedibile il tempo di manutenzione ed aggiornamento e una volta costruiti script di compilazione il procedimento è automatizzabile; è possibile la coesistenza di vecchia e nuova versione e la verifica del software applicativo soprastante, mantenendo il sistema sempre sotto controllo.

Ma partire dai sorgenti presenta anche alcuni svantaggi: è necessaria la verifica della compilazione ad ogni aggiornamento di major version dei moduli coinvolti e la costruzione iniziale o il rifacimento degli script di compilazione per ogni modulo richiede tempo. Cambiamenti “epocali” (ad esempio, passaggio a 64 bit) possono dover richiedere la ricostruzione di ambiente e script.

Bibliografia

[1] Lo standard COBIT5 – http://www.isaca.org/COBIT/Pages/default.aspx

[2] ITIL Service Strategy v.3/2011 – Ed. TSO, 2011

[3] Lo standard TOGAF – http://www.opengroup.org/togaf/

[4] G. Destri – Sistemi Informativi. Il pilastro digitale di servizi ed organizzazioni – Ed. Franco Angeli, 2013

[5] Ciclo di vita del software open source http://en.wikipedia.org/wiki/Open-source_software_development

[6] W3Techs Web Technology Survey http://w3techs.com/technologies/overview/content_management/all

[7] Water & Stone: 2011 Open Source CMS Survey http://www.waterandstone.com/book/2011-open-source-cms-market-share-report

[8] G. Destri: “Apache from source: Il server Web PHP, Java e Mono, SSH/SFTP” http://www.areaprofessional.net/documenti/websoftwarefromsource.pdf