Fumetto's Blog

In questo articolo viene analizzato il sistema di creazione e gestione del master-database di SME Server e come questo database viene modificato opportunamente tramite il sistema di scripting interno al server stesso, costituito in parte da una serie di azioni singole concatenate in appositi eventi che le richiamano alla bisogna. Visto che il mio modo di imparare è scrivere pubblico questi appunti sperando magari che siano utili a qualcuno. Se trovate inesattezze non esitate a farmele notare… 🙂

La ricerca di nuovi orizzonti mi porta a studiare nei limite delle mie possibilità gli internals (il sistema di gestione e configurazione) di SME Server. NON prendete per oro colato ciò che scrivo… tenterò di aggiornare gli appunti quando mi accorgerò che non sono esatti…

Tutti i parametri modificabili di SME Server risiedono sul db. Questi parametri vengono utilizzati per ricreare i file di configurazione (residenti in /etc/…) quando questo si rende necessario. La modifica di questi parametri può avvenire in diversi modi; dal pannello web di gestione, dalla concole, tramite script ad hoc…

I parametri possono essere costituiti da una coppia key/valore o da una key che racchiude vari parametri e i relativi valori. Il comando per vedere le chiavi è config show key

[root@gsxdev1 ~]# config show AccessType
AccessType=dedicated
[root@gsxdev1 ~]# config show ConsoleMode
ConsoleMode=login
[root@gsxdev1 ~]# config show TimeZone
TimeZone=Australia/NSW
[root@gsxdev1 ~]# config show atalk
atalk=service
    MaxClients=20
    status=enabled

[root@gsxdev1 ~]# config show dhcpd
dhcpd=service
    end=192.168.1.250
    start=192.168.1.65
    status=disabled

Le configurazioni vengono quindi ad essere semplici valori di database, per tale motivo il comando config è nella pratica il sostituto di db configuration.

[root@gsxdev1 ~]# config show LocalIP
LocalIP=192.168.1.100

[root@gsxdev1 ~]# db configuration show LocalIP
LocalIP=192.168.1.100

Il comando principale resta però “db” in quanto (prendendo l’ultimo esempio) il “configuration” specifica su quale database cercare la chiave (LocalIP) da mostrare (show). Per questo motivo volendo ad esempio visualizzare i valori associati all’account di amministrazione il comando corretto sarà

[root@gsxdev1 ~]# db accounts show admin
    admin=system
    EmailForward=local
    FirstName=Local
    ForwardAddress=
    LastName=Administrator
    Lockable=no
    PasswordSet=yes
    Removable=no
    Shell=/sbin/e-smith/console
    VPNClientAccess=no

Abbiamo praticamente chiesto di mostrare i valori della chiave “admin” del database “accounts”.
I database principali sono

• Configuration (che contiene i valori utilizzati per la configurazione della macchina server quali il tipo di accesso ad internet, il tipo di elaborazione a cui saranno sottoposte le caselle di posta elettronica e altro…)
• Accounts (che contiene le informazioni sui gruppi, gli utenti, le i-bay, le stampanti “sharate”, gli pseudonimi/alias, gli account di sistema e i redirect web come ad esempio server-manager)
• Domains (che contiene le informazioni sui domini gestiti e su come gestirli)
• Networks (che contiene i dati su quali network sono considerati locali; se infatti l’accesso al server avviene da network non locali solitamente, se non diversamente programmato, il server non caga niente e nessuno… :-P)
• Hosts (contiene i dati utilizzati dal DNS server e dal DHCP server interni a SME)
• backups
• spamassassin
• mailpatterns
• yum_installed
• yum_repositories
• yum_available
• yum_updates

I database vengono creati, modificati e aggiornati tramite il contenuto di /etc/e-smith/db; il contenuto è costituito da directory con il nome del database con all’interno altre 3 directory utilizzate per i processi di inizializzazione, aggiornamento e migrazione (defaults/, force/ e migrate/). All’interno di defaults/ ci sono delle directory che hanno per nome le key del database e all’interno di queste ultime dei file di testo con per nome i parametri e per contenuto il valore di default del parametro.

[root@gsxdev1 db]# cd /etc/e-smith/db
[root@gsxdev1 db]# ls
accounts       domains       networks       yum_installed
backups        hosts         spamassassin   yum_repositories
configuration  mailpatterns  yum_available  yum_updates
[root@gsxdev1 db]# ls configuration/
defaults  force  migrate
[root@gsxdev1 db]# cd /etc/e-smith/db/accounts/defaults/admin
[root@gsxdev1 admin]# ls
FirstName  LastName  Lockable  Removable  Shell  type  VPNClientAccess
[root@gsxdev1 admin]# cat type
system

le cartelle force/ e migrate/ vengono utilizzate per forzare un parametro ad uno specifico valore e per i processi di aggiornamento/migrazione. Quest’ultima cartella in particolare, al contrario delle altre due, contiene i file in Perl necessari per le migrazioni “complesse” dei parametri del database.

L’inizializzazione del database prevede quindi, in sequenza, l’importazione dei valori tramite gli script Perl, il caricamento dei valori di default (che vengono applicati solo se la key o il parametro non sono ancora presenti perchè creati dagli script) e l’applicazione dei parametri della cartella force/.

Il lavoro di gestione di tutti i parametri e della creazione delle configurazioni per i diversi servizi viene quindi fatto appoggiandosi ai valori del db. Per la modifica in gruppo di una serie di parametri viene utilizzato un meccanismo basato su applicazioni (action, residenti in /etc/e-smith/events/actions/nome_azione) costituite solitamente da script che possono essere inserite in dei compiti (task) semiautomatici da eseguire in presenza di particolari condizioni. Il richiamo di questi gruppi di applicazioni avviene tramite gli eventi (event).

Nella pratica l’invio della segnalazione di evento

[root@gsxdev1 admin]# signal-event ibay-modify

andrà a richiamare le azioni contenute in

[root@gsxdev1 admin]# cd etc/e-smith/events/ibay-modify
[root@gsxdev1 ibay-modify]# ls
S15ibay-modify  S90atalk-reload  services2adjust  templates2expand

S15… ed S90… sono link simbolici a delle action già impostate, l’ordine di esecuzione è dato dal valore dopo la “S”.
Le cartelle services2adjust e templates2expand contengono rispettivamente i comandi da inviare ai servizi attivi e interessati dall’evento e l’eventuale frammento di template da espandere per ricreare i file di configurazione interessati dall’operazione effettuata.

[root@gsxdev1 ibay-modify]# cd services2adjust/
[root@gsxdev1 services2adjust]# ls -l
totale 0
lrwxrwxrwx  1 root root 7  5 mar 22:54 httpd-e-smith -> sigusr1
lrwxrwxrwx  1 root root 6  5 mar 22:53 smbd -> sighup
[root@gsxdev1 services2adjust]# cd../templates2expand/etc/
[root@gsxdev1 etc]# ls -l
totale 12
drwxr-xr-x  2 root root 4096  5 mar 23:12 atalk
-rw-r--r--  1 root root    0 23 nov 20:03 hosts.allow
-rw-r--r--  1 root root    0 23 nov 20:03 hosts.deny
drwxr-xr-x  3 root root 4096 26 apr  2009 httpd
-rw-r--r--  1 root root    0  7 ott  2008 proftpd.conf
drwxr-xr-x  2 root root 4096  5 mar 22:53 samba
-rw-r--r--  1 root root    0 23 nov 20:03 securetty
-rw-r--r--  1 root root    0 23 nov 20:03 services
-rw-r--r--  1 root root    0 23 nov 20:03 shells

Le operazioni eseguite con il comando/programma signal-event verranno registrate sui log di sistema per una eventuale consultazione a posteriori. La lista degli argomenti validi da passare al comando precedente si trova qui.