Capitolo 6. Configurazione
La gestione centralizzata della configurazione di più macchine non è un problema banale, se implementata in modo sbagliato può dare l'impressione di "perdere" il controllo delle macchine e di quello che fanno: se gli automatismi sono mal definiti ed eccessivamente opachi c'è il rischio che prendano il sopravvento e frustrino i tentativi di comprensione da parte degli amministratori. D'altra parte però è anche un'ottima possibilità per gestire una struttura complessa impegnando le energie (che sono in quantità finita) in modo intelligente.
Questo capitolo illustra la soluzione che abbiamo implementato, e in che modo questa interagisca col sistema. Sapere questo è fondamentale per capire in che modo modificare la configurazione per ottenere i risultati voluti.
6.1. Overview
La configurazione dei vari server è centralizzata, prevedendo più di un meccanismo per le customizzazioni specifiche. In particolare, si è utilizzato CFengine per gestire i files di configurazione "semplici", cioè quelli che non dipendono dai dati presenti nel database delle utenze, e degli script customizzati (i binding LDAP per i vari linguaggi di scripting sono piuttosto semplici da usare) per gestire tutto il resto.
6.1.1. Configurazioni che non dipendono dal database
CFengine si è rivelato uno strumento molto utile, permettendo di realizzare un modello di gestione basato sul principio della minima differenziazione: le configurazioni sono uniche, fin dove possibile, dopodiché si procede ad editarle per semplici sostituzioni, eventualmente se necessario si possono mantenere files completamente differenti per una o tutte le macchine (vedremo più sotto in dettaglio come ciò viene realizzato). Questo modello rende molto conveniente gestire, ad esempio, files molto grandi con opzioni identiche tranne poche, che dipendono dalla macchina specifica, come può essere un indirizzo IP per il binding di un servizio o un hostname.
La gestione centralizzata dei files di configurazione deve inoltre permettere di tener traccia delle varie modifiche e di chi le abbia effettuate, in modo reversibile.
Per questo abbiamo deciso di combinare un sistema di controllo di versioni (come CVS, nel nostro caso usiamo Subversion) con cui gestiamo un repository che viene poi a sua volta replicato su tutte le macchine: questo significa che è necessario effettuare le modifiche in un unico luogo; le modifiche si propagheranno poi automaticamente fino alla destinazione corretta, in modo determinato dalla configurazione di CFengine. Allo stesso tempo, una copia della configurazione originale completa rimane su ciascuna macchina, così che sia possibile, in caso di necessità, cambiare molto rapidamente la macchina che svolge il ruolo di server principale. Come ulteriore forma di backup, il server Subversion si trova su di un'altra macchina ancora.
L'illustrazione qua sotto spiega, con un diagramma, qual è il punto adatto alla modifica dei files, e con quali differenti meccanismi questi vengano distribuiti verso le varie destinazioni.
Flusso dei dati di configurazione.
Conviene che i files che vengono gestiti in questo modo siano solamente quelli che in qualche modo sono diversi rispetto ad un'installazione standard Debian, non è ovviamente necessario gestire l'intero albero /etc.
Una spiegazione dettagliata del contenuto della directory /configfiles è compresa nel la Sezione 6.2.1>.
6.1.2. Configurazioni che dipendono dal database
Alcuni servizi hanno una configurazione che dipende dal contenuto del database degli utenti (quello in LDAP), in genere perché è impossibile o poco pratico far sì che leggano dinamicamente la loro configurazione dal database. Un esempio è il server web: in questo caso si è scelto di semplificare la struttura dei dati dentro il database (evitando soluzioni tipo mod_config_ldap, che leggessero direttamente le direttive di Apache dentro complessi oggetti LDAP) per facilitarne la gestione, rendendo però necessaria la creazione del file di configurazione in qualche altro modo.
Questi files vengono dunque generati automaticamente con degli script, presenti su ciascuna macchina in /configfiles/scripts (che possiamo spostare in un posto più furbo se ci viene in mente qualcosa di pratico). Questi script leggono i dati presenti nel database LDAP e generano i file di configurazione necessari. Anche altre azioni sono possibili, come per esempio controllare la presenza e i permessi sul filesystem delle directory delle caselle di posta, o altri compiti amministrativi di questo tipo.
L'idea di fondo è che il database LDAP sia la fonte autoritativa per la configurazione del sistema, e che il ruolo degli script sia dunque di plasmare la configurazione effettiva in modo da renderla conforme ai dati contenuti nel database. Questo implica che per ottenere delle modifiche alla configurazione dovrò necessariamente modificare il database LDAP (si vedrà poi con quali strumenti ciò è possibile).