[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico] [volume] [parte]
L'inoltro dei pacchetti da un'interfaccia di rete a un'altra, in un router, è compito del kernel: è sufficiente che gli venga fornita la configurazione delle interfacce e la tabella di instradamento.
Teoricamente dovrebbe essere possibile compilare un kernel con questi valori già registrati al suo interno, in pratica conviene utilizzare il modo tradizionale di configurazione attraverso i programmi ifconfig e route.
Un dischetto di emergenza, in grado di accedere alle interfacce di rete, con un kernel adatto e con questi due programmi, è in grado di funzionare come router. Ciò vale quindi sia per nanoLinux che per i dischetti di emergenza della distribuzione Slackware.
In questo capitolo si descrive in che modo ottenere un sistema estremamente ridotto in grado di eseguire l'inoltro di pacchetti da un'interfaccia di rete a un'altra.
Come già accennato, il kernel deve consentire l'inoltro dei pacchetti. Per le altre caratteristiche valgono tutte le considerazioni già fatte al riguardo dei dischetti di emergenza.
La funzione di inoltro è svolta dal kernel e, a meno di essere abili programmatori, è necessario utilizzare ifconfig e route per configurare le interfacce e definire gli instradamenti. Questi programmi, a loro volta, hanno bisogno di librerie. I programmi, per essere avviati hanno bisogno dell'eseguibile init, oppure, in alternativa, di una shell che possa eseguire uno script.
Nell'esempio proposto non si fa uso di init: con un piccolo trucco si avvia direttamente la shell ash in modo interattivo, così da leggere ed eseguire il file /etc/profile contenente le istruzioni per la configurazione delle interfacce e la definizione degli instradamenti.
Rispetto ai dischetti di emergenza normali si pone un nuovo problema: l'identificazione delle interfacce di rete quando queste sono più di una. Infatti, il kernel smette di cercare altre interfacce dopo che ne ha trovata una. Ciò costringe in pratica a utilizzare LILO, attraverso il quale si possono definire le istruzioni che il kernel deve ricevere all'avvio (attraverso queste istruzioni può essere informato della presenza di altre schede di rete).
Il dischetto nanoRouter si ottiene partendo da nanoLinux I eliminando molte cose e aggiungendone poche altre. In particolare, si nota subito l'utilizzo di ash al posto di bash e la totale assenza della procedura di inizializzazione del sistema.
Il programma /sbin/init è scomparso, al suo posto c'è un collegamento simbolico speciale che avvia ash con l'opzione -i: in questo modo, quando il kernel tenta di avviare init, avvia invece una shell interattiva che, come tale, esegue il contenuto di /etc/profile.
Anche /sbin/ldconfig è un collegamento simbolico: avvia uno script che restituisce semplicemente il valore Vero. Questo programma viene avviato automaticamente e non può mancare (anche se di fatto non serve).
I file di dispositivo contenuti all'interno di /dev/ sono ridotti al minimo, in pratica ci sono i dispositivi di gestione della console e poco altro.
L'ultima cosa da notare è la presenza della directory /boot/ contenente il kernel e i file di avvio di LILO.
/ |-- bin | |-- ash | |-- ping | |-- sh -> ash | `-- sync |-- boot | |-- .config | |-- boot.0200 | |-- boot.b | |-- map | `-- vmlinuz |-- dev | |-- log | |-- null | |-- systty | |-- tty | |-- tty0 | |-- tty1 | |-- tty2 | |-- tty3 | |-- tty4 | `-- zero |-- etc | |-- ld.so.cache | |-- lilo.conf | |-- profile | `-- protocols |-- lib | |-- ld-linux.so -> ld-linux.so.1 | |-- ld-linux.so.1 -> ld-linux.so.1.8.2 | |-- ld-linux.so.1.8.2 | |-- libc.so.5 -> libc.so.5.3.12 | |-- libc.so.5.3.12 | |-- libcom_err.so.2 -> libcom_err.so.2.0 | |-- libcom_err.so.2.0 | |-- libtermcap.so.2 -> libtermcap.so.2.0.8 | `-- libtermcap.so.2.0.8 |-- mnt |-- proc |-- sbin | |-- ifconfig | |-- init -> ../bin/ash -i | |-- ldconfig -> true | |-- route | |-- true | `-- update |-- tmp |-- usr `-- var
Creare un collegamento simbolico con un argomento non è possibile attraverso il solito programma ln. Se non si riesce, si può creare un collegamento simbolico normale, ma poi, occorre avviare manualmente l'esecuzione del file profile.
Attraverso mc (Midnight Commander) è possibile modificare un collegamento simbolico scrivendoci quello che si vuole. Basta richiamare la voce {edit sYmlink} dal menù {File}, oppure utilizzare la sequenza [Ctrl+x][Ctrl+s].
Il file /etc/profile, in questo tipo di impostazione, è l'unico mezzo di configurazione. La configurazione delle interfacce di rete e la definizione degli instradamenti avvengono all'interno di questo file.
PATH="/sbin:/bin:." TERM=linux PS1='# ' PS2='> ' ignoreeof=10 export PATH TERM PS1 PS2 ignoreeof umask 022 /sbin/ifconfig eth0 192.168.1.254 netmask 255.255.255.0 /sbin/ifconfig plip1 192.168.2.254 pointopoint 192.168.2.1 /sbin/route add -net 192.168.1.0 netmask 255.255.255.0 dev eth0 /sbin/route add -host 192.168.2.1 dev plip1 ifconfig
Come già accennato, esiste l'esigenza di comunicare al kernel l'esistenza di diverse schede di rete (altrimenti si può forse usare solo la porta parallela come seconda interfaccia di rete). Serve quindi il sistema di avvio LILO. Il modo con cui è possibile ottenere un dischetto contenente LILO è descritto nella sezione 18.4.
Il contenuto del file di esempio si riferisce in particolare ai parametri delle schede NE2000.
# /etc/lilo.conf
boot=/dev/fd0
map=/boot/map
install=/boot/boot.b
image=/boot/vmlinuz
label=router
root=/dev/fd0
read-only
append="ether=0,0x300,eth0 ether=0,0x320,eth1 ether=0,0x340,eth2"
Vale la pena di notare che il file system principale viene attivato in sola lettura e non viene mai riportato in lettura-scrittura.
Tutto quanto, compreso il kernel, dovrebbe essere contenibile all'interno di un dischetto da 1 440 Kibyte, senza alcuna compressione. In questo modo non c'è la necessità di utilizzare un disco RAM e anche un elaboratore con poca memoria potrebbe svolgere degnamente questo compito (senza bisogno di una laboriosa configurazione).
Il fatto che si riesca a operare senza eseguire scritture sul disco, pur non utilizzando un disco RAM, permette di non dover temere cadute di tensione o errori umani: Quando non serve più, basta spegnere.
Resta un problema dovuto al fatto che il kernel, una volta caricato in memoria, richiede la pressione del tasto [Invio] prima di attivare il file system principale. Ciò impedisce un avvio automatico. Utilizzando una piccola partizione di un disco fisso, la richiesta di scambiare i dischetti non viene più fatta.
Il fatto di utilizzare il dischetto in sola lettura impedisce il montaggio del file system /proc/ e di conseguenza i programmi ne risentono. Questo è il motivo principale per cui non si riesce a realizzare questo dischetto con programmi derivanti da distribuzioni GNU/Linux recenti.
daniele @ swlibero.orgDovrebbe essere possibile fare riferimento a questa pagina anche con il nome nanorouter.html
[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico]