(pagina 2 di 3)

DNS e file Hosts in breve

Il file /etc/hosts, come e perché verrà modificato
Ormai è risaputo che tutte le macchine connesse ad Internet sono identificate da un numero univoco detto indirizzo IP; per semplificare la vita agli utenti che vogliono contattare un certo server si è pensato di associare gli indirizzi IP a dei nomi che risultano più semplici da ricordare. Risolvere i nomi dei domini, cioè “tradurli” in indirizzi IP, è compito dei server DNS ma, agli albori di Internet, il problema era stato approcciato in modo più semplice: ogni macchina copiava da un server del NIC (Network Information Center) un file chiamato HOSTS.TXT che conteneva un elenco di tutti i server e dei relativi indirizzi IP. Una traccia di questo meccanismo è rimasta ancora oggi nelle macchine equipaggiate con GNU/ Linux ed è riscontrabile nel file /etc/hosts. Questo file viene tuttora consultato quando qualche programma deve risolvere un nome: solo se l’informazione necessaria non è presente nel file /etc/hosts allora verrà “scomodato” uno dei server DNS elencati nel file /etc/resolv.conf.

Configurazione del server

Offrire il servizio di pseudo-DDNS ai propri colleghi di lavoro o amici è davvero semplice: basta avere a disposizione un classico server LAMP (Linux + Apache + MySQL + PHP). Vediamo come procedere prendendo come riferimento la distribuzione Ubuntu 8.04; tutto il software necessario può essere scaricato dai repository della distribuzione e installato impartendo da un terminale il seguente comando:

sudo apt-get install apache2 \

mysql-client mysql-server \

php5 libapache2-mod-php5 php5-mysql

Per chiarezza il comando è stato riportato su tre righe mettendo così in evidenza le tre componenti fondamentali; naturalmente è possibile anche digitarlo tutto di seguito eliminando però i caratteri “\”. Durante l’installazione verrà chiesto di specificare la password da impostare per l’utente amministratore (root) del database server MySQL. Per verificare il funzionamento del server possiamo creare una nuova pagina PHP nella “DocumentRoot” di Apache (/var/www) eliminando l’eventuale pagina di test (index.html):

sudo su

rm /var/www/index.html

echo “” > /var/www/index.php

Apriamo un qualsiasi web browser e puntiamolo su http://localhost: dovremmo vedere la classica pagina che riepiloga le informazioni su PHP e che quindi ne testimonia il corretto funzionamento. Nel caso qualcosa non andasse si dovrebbe innanzitutto verificare che il modulo PHP sia abilitato in Apache usando il comando sudo a2enmod php5 ed eventualmente riavviare il web server:

sudo /etc/init.d/apache2 restart

Adesso non ci resta che predisporre il database: tra i vari pacchetti che abbiamo installato c’era il server MySQL ed il client a riga di comando che risulterà più che sufficiente per le nostre esigenze di amministrazione:

mysql --user=root --password=miapassword

--host=localhost

Al prompt di MySQL, iniziamo subito creando un nuovo database che,con un discreto sforzo di fantasia, chiameremo ddns:

mysql> CREATE DATABASE ddns;

Selezioniamo il database:

mysql> USE ddns;

Infine creiamo una nuova tabella:

mysql> CREATE TABLE utenti (

username varchar(50),

password varchar(32),

ipaddress varchar(15),

PRIMARY KEY (username)

) ;

Anche chi è completamente a digiuno di SQL può intuire che in questo modo si crea una tabella chiamata utenti con tre campi: username, password e ipaddress; fra parentesi compare il numero massimo di caratteri consentito per ogni campo; il campo username verrà usato come chiave primaria in quanto non potranno esistere due utenti con lo stesso nome. Per uscire dal modo interattivo basta digitare il comando quit. Bene, non resta che copiare gli script PHP  in /var/ www impostando come proprietario l’utente di Apache (wwwdata):sudo su

cd /media/cdrom

cd plus/Dinamycdns/server

cp index.php database.php registrazione.php

/var/www

cd /var/www

chown www-data:www-data *

L’ultimo passo consiste nell’aprire il file database.php con un qualsiasi editor e verificare le impostazioni per la connessione al server MySQL; le righe interessate sono facilmente individuabili e sono autoesplicative:

define (‘DB_HOST’, ‘localhost’);

define (‘DB_USER’, ‘root’);

define (‘DB_PASS’, ‘miapassword’);

define (‘DB_NAME’, ‘ddns’);

Una volta testato il server dovremo renderlo accessibile ai diversi client: se operiamo in una rete locale non ci dovrebbero essere problemi mentre, se volessimo estendere il campo d’applicazione all’intera Internet, dovremmo fare in modo che il server abbia un indirizzo IP pubblico di tipo statico e, meglio ancora, un FQDN. Avere un server sempre on-line e registrare un nome a dominio può risultare un po’ eccessivo per un servizio come quello illustrato che vuole essere un’alternativa semplice ed immediata ai servizi DDNS. Allora perché non usare un qualsiasi servizio di hosting? Ormai è facile trovare dei Provider che offrono dello spazio web con tanto di supporto PHP e MySQL in modo completamente gratuito; giusto per fare qualche nome possiamo citarne un paio abbastanza famosi dalle nostre parti: www.altervista.org e www. netsons.org.

Uno sguardo “sotto il cofano”

Vediamo a grandi linee il meccanismo di funzionamento degli script PHP che danno vita al nostro server pseudo-DDNS.  Lo script index. php inizia con l’inclusione del file database.php che si occupa di stabilire una connessione al database server MySQL dopodiché si verifica l’esistenza delle variabili $_POST[‘username’] e $_POST[‘password’]: la prima volta che questa pagina viene visualizzata in un web browser le due variabili non risultano settate quindi verrà richiamata la funzione formLogin (riga 8). Questa funzione non fa altro che visualizzare un modulo composto da due campi (username e password) e da un tasto per l’invio. I valori che l’utente scriverà in questi campi saranno inviati con il metodo POST al medesimo script index.php. Dopo la compilazione del modulo le due variabili $_POST[‘username’] e $_ POST[‘password’] risulteranno impostate ed il codice eseguito sarà quello che inizia alla riga 11. Qui viene richiamata la funzione verificaLogin che ha il compito di verificare se lo username e la password sono presenti nel database. Altri parametri della funzione sono le variabili $ipaddress e $msgErrore che vengono passate per riferimento (notare il simbolo “&”) e che quindi potranno essere modificate dalla funzione verificaLogin. Effettivamente $msgErrore conterrà gli eventuali messaggi di errore che dovranno essere notificati all’utente (ad esempio se lo username non è presente nel database) mentre $ipaddress verrà impostato dalla funzione verificaLogin con l’indirizzo IP che nel database risulta appartenere all’utente. La funzione verificaLogin restituisce il valore 0 se l’autenticazione dell’utente viene eseguita correttamente mentre restituisce 1 in caso di insuccesso; in quest’ultimo caso dalla riga 11 si salta alla riga 37: viene richiamata nuovamente la funzione formLogin e quindi all’utente sarà riproposto il modulo per l’accesso con in evidenza il messaggio di errore $msgErrore. Se il login ha successo viene eseguito il blocco di codice che va dalla riga 14 alla riga 34 che prevede innanzitutto il confronto tra l’indirizzo IP memorizzato nel database ($ipaddress) e quello rilevato dal server ($_SERVER[‘REMOTE_ADDR’]): se c’è stata una modifica dell’indirizzo rispetto all’ultimo valore registrato viene eseguito un aggiornamento al database (righe 15-16). Alla riga 21 si verifica se la form di login è stata compilata dall’utente usando un comune web browser oppure dal client ddns.sh che analizzeremo in seguito: la verifica si basa su un campo nascosto della form ($_POST[‘interattivo’]) che viene impostato solo dal web browser mentre non viene affatto considerato dallo script Bash. In pratica, quindi, se la pagina viene visualizzata in modo interattivo dall’utente a questo punto comparirà un messaggio di conferma (righe 23-27) mentre in caso contrario (righe 30-33) per ogni account presente nel database viene creata una riga che contiene la stringa “<<>>” (vedremo in seguito a cosa serve), il nome dell’utente, una tabulazione orizzontale e, infine, l’indirizzo IP attualmente associato. L’output ottenuto sarà simile al seguente:

<<>>pippo 192.168.1.12

<<>>pluto 10.0.1.13

<<>>paperino 172.16.1.23

Configurare la parte client

Il tool per il servizio di Dynamic DNS comunica l’indirizzo IP della macchina al server.

Pagina di login

Accedendo alla pagina principale del server con un qualsiasi browser si ha la possibilità di autenticarsi ma, per i nuovi utenti che non dispongono ancora di nome utente e password, l’unica possibilità è quella di cliccare sul link in basso per arrivare alla pagina di registrazione al servizio (script registrazione.php).

 Registrazione

In questa pagina i nuovi utenti hanno la possibilità di scegliere il proprio username e una password. Allo stato attuale lo script non esegue controlli particolari, ma accetta qualsiasi username e password che contengano almeno tre caratteri alfanumerici; naturalmente non saranno accettati dei “doppioni” tra gli username.

 Setup del client

A questo punto l’utente può copiare lo script e con un editor di testi, specificare nelle prime righe il proprio username, la password e l’indirizzo del server. Una volta salvato lo script è necessario abilitarne l’esecuzione con il comando: chmod +x ddns.sh.

Passiamo al client

Abbiamo visto che, per tenere aggiornate le informazioni sugli indirizzi IP delle varie macchine client, gli utenti si dovrebbero caricare periodicamente l’home page del web server ed eseguire l’autenticazione. Questo modo d’uso non è proponibile ma naturalmente possiamo automatizzare queste operazioni usando il semplice script Bash ddns.sh. Vediamo come è strutturato: nelle prime righe vengono definite delle variabili che contengono le credenziali per la connessione al server e che andranno personalizzate con i dati ottenuti dalla registrazione al servizio (vedi tutorial “Configurare la parte client”). A questo punto vengono eseguiti due controlli: il primo, compreso tra le righe 9 e 13, serve a verificare con il comando whoami che l’utente che ha lanciato lo script è root; la seconda verifica (righe 15-19) serve per accertarsi che il pacchetto curl sia installato (vedi tutorial “Il client all’opera”). Con le successive righe 21-24 si controlla l’esistenza di una copia di backup del file /etc/hosts: se la copia di riserva /etc/hosts.bak non esiste allora viene creata. Siamo infine arrivati al punto nevralgico dello script: il file hosts viene ricreato copiandolo dal backup (riga 25) e poi gli viene accodato il risultato dei comandi riportati nelle righe 26 e 27: vediamoli in dettaglio. Viene invocato innanzitutto curl passandogli come parametri le credenziali per l’accesso e l’indirizzo del server; curl non farà altro che caricare la pagina index.php del server e compilare la form di accesso. In questo modo il server aggiornerà se necessario il database con l’indirizzo IP del client e poi, come abbiamo visto nel paragrafo precedente, invierà in output l’elenco degli altri account e dei relativi indirizzi IP. Queste informazioni vengono passate con la pipe (|) da curl a grep che filtrerà le sole righe che contengono la stringa <<>> scartando di fatto i possibili messaggi di errore generati dal web server. Di nuovo queste informazioni vengono passate al programma successivo, sed, che provvede ad eliminare da ogni riga la stringa <<>>. Il testo ottenuto rispetta la formattazione tipica del file hosts (nome host seguito da una tabulazione e poi dal relativo indirizzo IP) e quindi può essere tranquillamente aggiunto alla fine del file usando il simbolo della redirezione (>>). Questo è tutto: le macchine in cui lo script viene installato come illustrato nei tutorial potranno “contattarsi” fra loro usando al posto degli indirizzi IP semplicemente lo username specificato dall’utente durante la registrazione.

Consigli utili per aumentare il livello di sicurezza

 Il sistema che abbiamo appena illustrato in queste pagine offre un servizio di DynamicDNS piuttosto interessante, ma occorre precisare che si tratta pur sempre di un primo approccio al problema e necessita di ulteriori affi namenti: innanzitutto, occorre prestare molta più attenzione all’aspetto sicurezza. Ad esempio facciamo presente che le password, benché siano memorizzate in modo “cifrato” nel database, vengono inviate in chiaro dal client al server durane la richiesta dell’IP; una prima misura da prendere in considerazione potrebbe essere l’abilitazione nel server web Apache del supporto al protocollo HTTPS, molto più sicuro. Una funzionalità da sviluppare quanto prima negli script lato server è quella che consentirebbe agli utenti di far conoscere il proprio indirizzo IP solo a determinati altri utenti e non a tutti. Ricordiamo infi ne che il sistema descritto non è un vero DDNS: il nome delle macchine su cui gira il nostro client può essere risolto solo dagli altri utenti del servizio. Se questa limitazione fosse inaccettabile dovremo per forza di cose configurare un vero server DDNS come ad esempio TinyDYN (www.technocage. com/~caskey/tinydyn) o tinyddns (http://sourceforge.net/projects/ tinyddns).

Il client all’opera

A questo punto proviamo se funziona e pianifichiamo la sua esecuzione con cron

Requisiti minimi

Lo script ha due requisiti fondamentali: deve essere eseguito daroot per poter modificare il file /etc/hosts e ha bisogno del programma curl (http://curl. haxx.se) per accedere al server web. Questo pacchetto potrebbe essere già installato nella vostra macchina ma se così non fosse lo troverete nel repository della distro.

Adesso proviamolo!

 Per provare lo script visualizziamo il contenuto del file hosts (cat /etc/hosts) quindi eseguiamo da root ./ddns. sh e visualizziamo nuovamente il file hosts alla ricerca delle differenze: se tutto funziona a dovere nel file dovreste trovare gli indirizzi IP di tutti gli utenti attualmente registrati al servizio di pseudo DDNS.

Automatizziamolo

Per eseguire lo script ogni cinque minuti, usando l’account di root, possiamo digitare il comando crontab -e che aprirà l’editor di testi predefinito: dovremo aggiungere la seguente riga: */5 * * * * /opt/ ddns.sh e salvare il file. Usando magari il centro di controllo di KDE conviene accertarsi che il demone cron sia eseguito all’avvio.

Pagina 2/3