Per chi vuole approfondire le proprie conoscenze sul mondo dei server GNU/Linux può essere un eccellente strumento, grazie alla sua versatilità, gratuità, stabilità e ampia disponibilità di programmi. Dopo poco averlo installato però ci si scontra inevitabilmente con il "superdemone": non si tratta di un'entità malefica da combattere con un esorcismo, ma di un servizio in grado di gestire il caricamento di più server.
L'utilità è molteplice: dal consentire l'avvio di un server solo quando viene richiesto da un client all'avere un unico file di configurazione che include i server avviati. In questo modo è possibile risparmiare preziose risorse evitando di tenere in esecuzione i server anche quando in realtà non vengono utilizzati da nessun client.
Storicamente il superdemone più conosciuto è inetd. Spesso però inetd è stato accusato di essere poco sicuro, cosa fondamentale per un programma di questo tipo. Per cercare di risolvere (anche) questo problema è stato sviluppato xinetd, che consente anche di dare una configurazione più fine rispetto a inetd. Con il passare del tempo xinetd ha sempre più preso piede e ora è la soluzione adottata di default sulla maggior parte delle distribuzioni.
Inetd
Uno dei maggiori pregi di inetd risiedeva proprio nella semplicità del file di configurazione, /etc/inetd.conf. In genere per attivare un server bastava semplicemente togliere il # di commento davanti la riga corrispondente. Ad esempio abilitando al suo interno:
ftp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/proftpd
Si specificava di voler utilizzare per il servizio ftp (ftp) del protocollo tcp (stream) proftpd (oppure vsftpd, dipende dal server utilizzato), da eseguire come utente root (root).
Un'ulteriore possibilità di configurazione veniva data dai file /etc/hosts.allow e /etc/hosts.deny, attraverso i quali era possibile specificare alcune limitazioni sull'accesso. Ad esempio una riga del tipo ftp: ALL in /etc/hosts.allow darebbe il permesso a chiunque di accedere al nostro server ftp, se abilitato su inetd. Xinetd tra le altre cose consente di semplificare questo approccio dando la possibilità di specificare questo genere di cose direttamente all'interno del proprio file di configurazione, /etc/xinetd.conf.
Xinetd
Come detto prima xinetd viene utilizzato di default ormai sulla maggior parte delle distribuzioni, quindi è altamente probabile che sia già presente sui CD della vostra distribuzione preferita. Installatelo con APT oppure rpm e assicuratevi di scaricare da Internet eventuali versioni aggiornate. Una volta installato dovremo configurare il file /etc/xinetd.conf. Come prima cosa è possibile fare una conversione diretta tra la configurazione di inetd e quella nuova di xinetd. Se disponiamo quindi di un inetd.conf già pronto per il nostro PC, con il comando:
xconv.pl < /etc/inetd.conf > /etc/xinetd.conf
possiamo con facilità ottenere la configurazione equivalente per xinetd (a seconda della distribuzione xconv.pl potrebbe non essere nel path).
Supponiamo ora che inetd gestisca sul nostro computer solo il server ftp, attraverso la riga specificata prima. L'equivalente per xinetd.conf sarà:
defaults {
instances = 25
log_type = FILE /var/log/servicelog
log_on_success = HOST PID
log_on_failure = HOST
per_source = 5
}
service ftp {
flags = NAMEINARGS
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/tcpd
server_args = /usr/sbin/proftpd
}
Come possiamo vedere una prima (e fondamentale) differenza risiede proprio nel formato del file: xinetd.conf è diviso infatti per sezioni, una di default più altre in base a quello che vogliamo fargli gestire, specificate da "service nomeprotocollo". In questo caso il file di configurazione di inetd.conf è stato semplicemente tradotto senza aggiungere nulla.
In genere però si preferisce evitare di avere un unico file di configurazione in /etc/xinetd.conf, che rischia di essere poco pratico. Sfruttando una possibilità offerta da xinetd, è possibile creare una serie di file all'interno della directory /etc/xinetd.d contenenti le indicazioni specifiche per ogni server, aggiungendo in /etc/xinetd.conf l'istruzione:
includedir /etc/xinetd.d
Non ci resta che esaminare le varie opzioni del file di configurazione di xinetd, per capire a fondo le possibilità offerte.
Nella prima parte di questo tutorial, abbiamo visto quali sono alcuni dei vantaggi dell'utilizzo di xinetd, lasciandovi a un file di configurazione di esempio in grado di avviare il server ftp a ogni richiesta sulla porta 21. Oggi analizzeremo quali sono le possibilità offerte da xinetd analizzando le opzioni del file di configurazione. Prenderemo come esempio sempre il server FTP. Il file /etc/xinetd.conf conterrà quindi una sezione riguardante i parametri di default più un riferimento alla directory /etc/xinetd.d che conterrà il file /etc/xinetd.d/ftp con una sezione relativa al proprio servizio. La sezione default sarà del tipo:
defaults {
instances = 25
log_type = FILE /var/log/servicelog
log_on_success = HOST PID
log_on_failure = HOST
per_source = 5
}
dove "instances" indica il numero di accessi contemporanei che vogliamo far accettare al servizio, "log_type" specifica la modalità di logging specifiche di xinetd (non quelle relative a ogni singolo server); in particolare FILE /var/log/servicelog farà utilizzare appunto il file /var/log/servicelog (altre possibilità sono ad esempio SYSLOG per l'interfacciamento con syslog, il demone dei log). "log_on_success" e "log_on_failure" specificano quali sono le informazioni da allegare al log in caso di successo o di fallimento (possibili opzioni sono HOST, PID, DURATION, EXIT, USERID per "log_on_success" e HOST, USERID e ATTEMPT per "log_on_failure"). Infine "per_source" fissa un limite al numero di accessi simultanei consentiti per ogni indirizzo.
Per quanto riguarda invece i file relativi a ftp analizziamo il seguente file di esempio (/etc/xinetd.d/ftp):
service ftp {
socket_type = stream
wait = no
user = root
server = /usr/sbin/proftpd
}
Dove socket_type = stream specifica che si tratta di un server che utilizza il protocollo TCP, wait = no è utilizzato tipicamente per il TCP, user = root specifica che il server verrà lanciato come utente root, e server = /usr/sbin/proftpd specifica il percorso del server (che dovrà essere comunque già funzionante).
Nel caso di connessioni UDP al posto di
socket_type = stream wait = no
metteremo
socket_type = dgram
wait = yes
Altre opzioni particolarmente interessanti sono:
disable, con parametri yes o no, che consente di disabilitare il server (per evitare di commentare un'intera sezione);
only_from, in grado di specificare gli indirizzi che possono collegarsi al nostro server (molto utile ad esempio per un server NTTP con leafnode);
no_access, che al contrario di only_from permette di indicare gli indirizzi che non possono accedere al server in questione;
bind che consente di mettere in ascolto un server solo su una determinata interfaccia rendendolo disponibile solo per la rete relativa;
nice per impostare la priorità del server nell'esecuzione dei processi (sconsiglio comunque il suo utilizzo se non se ne ha veramente bisogno);
redirect per specificare un indirizzo al quale inoltrare ogni richiesta per quel determinato server;
banner_success consente di visualizzare un messaggio di benvenuto per ogni login avvenuto con successo;
banner_fail analogamente a banner_success imposta un messaggio di errore da inviare per ogni richiesta di connessione che non è stata accettata;
cps (accetta come parametro due interi) per impostare quanti tentativi di connessione soddisfare per secondo e dopo quanti secondi rendere nuovamente disponibile il server se è stato superato questo limite.
Una volta sistemato il file di configurazione non vi resterà altro che riavviare xinetd con /etc/init.d/xinetd restart per rendere effettive le modifiche.
