Figura 307.8. Selezione dell'interfaccia RTL8139 118616:130016 da <http://www.rom-o-matic.net>.
|
|
[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico] [volume] [parte]
Esistono diversi modi per avviare un terminale LTSP; principalmente si possono considerare Etherboot e PXE.
Una volta compreso il meccanismo dell'avvio del terminale, può essere utile considerare la possibilità di adattare in qualche modo il sistema LTSP, per i propri scopi particolari.
Il nome PXE è acronimo di Pre-boot execution environment, che identifica un procedimento per il caricamento di un piccolo file eseguibile attraverso l'interfaccia di rete, per avviare il sistema operativo.
Quando l'interfaccia di rete è predisposta per questo tipo di procedimento, il caricamento del sistema attraverso PXE diventa il metodo più semplice, perché è sufficiente configurare il firmware dell'elaboratore (il BIOS) e non servono altri dispositivi a disco, nemmeno l'unità a dischetti.
Utilizzando questo metodo, il servente DHCP deve pubblicizzare il file /lts/.../pxelinux.0. Per esempio, trattandosi del servente DHCP di ISC, il file /etc/dhcp3/dhcpd.conf dovrebbe contenere una direttiva simile a quella seguente:
|
Considerato che il servente TFTP funzioni con l'opzione -s, si sta facendo riferimento al file /tftpboot/lts/2.6.9-ltsp-3/pxelinux.0. Nella directory che contiene il file pxelinux.0, devono essere presenti altri file, con i nomi previsti; in questo caso si tratta di:
In base a questo esempio, il file pxelinux.cfg/default ha il contenuto seguente:
|
Perché il terminale possa caricare il sistema attraverso il metodo PXE, è necessario che il servente TFTP sia in grado di accettare l'opzione tsize, altrimenti, il caricamento dei file successivi a pxelinux.0 fallisce.
Etherboot è un programma da compilare specificatamente per il tipo di interfaccia di rete di cui si dispone, fatto per essere inserito in una memoria ROM da montare nell'interfaccia stessa. Questo programma è in grado di utilizzare il protocollo DHCP e TFTP per caricare un file contenente il kernel, modificato in modo da avere alla fine anche il disco RAM iniziale. Etherboot può essere usato anche attraverso un dischetto, senza la necessità di predisporre una memoria ROM ed è questo il metodo che viene descritto qui.
Per l'avvio con Etherboot, il servizio DHCP può pubblicare il kernel modificato che si trova nella directory /tftpboot/lts/vmlinux-n.n.n-ltsp-3. Nel caso del servente DHCP di ISC, il file /etc/dhcp3/dhcpd.conf dovrebbe contenere una direttiva simile a quella seguente, dove n.n.n rappresenta la versione del kernel:
|
Tuttavia, il codice contenuto in Etherboot è in grado di avviare il sistema anche a partire da un file adatto per il metodo di avvio PXE; pertanto, questo secondo modo diventa quello preferibile in generale. L'esempio di configurazione del file /etc/dhcp3/dhcpd.conf va modificato nel modo seguente:
|
Qualunque sia la scelta nel modo di raggiungere il kernel, occorre produrre o procurarsi il file necessario ad avviare il terminale con Etherboot. Per le interfacce di rete da inserire in un bus ISA, occorre conoscere il modello; per quelle fatte per bus PCI (anche se integrate nella scheda madre), occorre risalire al numero identificativo del produttore e del dispositivo.
Disponendo di un sistema GNU/Linux, anche se avviato provvisoriamente, è possibile leggere le informazioni sul bus PCI con il programma lspci; inizialmente bisogna individuare l'interfaccia:
# lspci[Invio]
0000:00:00.0 Host bridge: ATI Technologies Inc: Unknown device 5833 (rev 02) 0000:00:01.0 PCI bridge: ATI Technologies Inc: Unknown device 5838 0000:00:13.0 USB Controller: ATI Technologies Inc: Unknown device 4347 (rev 01) 0000:00:13.1 USB Controller: ATI Technologies Inc: Unknown device 4348 (rev 01) 0000:00:13.2 USB Controller: ATI Technologies Inc: Unknown device 4345 (rev 01) 0000:00:14.0 SMBus: ATI Technologies Inc ATI SMBus (rev 17) 0000:00:14.1 IDE interface: ATI Technologies Inc: Unknown device 4349 0000:00:14.3 ISA bridge: ATI Technologies Inc: Unknown device 434c 0000:00:14.4 PCI bridge: ATI Technologies Inc: Unknown device 4342 0000:00:14.5 Multimedia audio controller: ATI Technologies Inc \ |
La riga che appare evidenziata corrisponde all'interfaccia di rete di cui occorre trovare il numero di identificazione:
# lspci -n[Invio]
0000:00:00.0 0600: 1002:5833 (rev 02) 0000:00:01.0 0604: 1002:5838 0000:00:13.0 0c03: 1002:4347 (rev 01) 0000:00:13.1 0c03: 1002:4348 (rev 01) 0000:00:13.2 0c03: 1002:4345 (rev 01) 0000:00:14.0 0c05: 1002:4353 (rev 17) 0000:00:14.1 0101: 1002:4349 0000:00:14.3 0601: 1002:434c 0000:00:14.4 0604: 1002:4342 0000:00:14.5 0401: 1002:4341 0000:01:05.0 0300: 1002:5834 0000:02:07.0 0200: 1186:1300 (rev 10) |
Si individua così che si tratta del numero 1186:1300, oltre al fatto che si tratta di un'interfaccia RTL8139.
A questo punto occorrerebbe disporre del pacchetto Etherboot per produrre il file necessario; tuttavia la descrizione di questo procedimento viene omessa, perché è possibile ottenere facilmente il file adatto alla propria interfaccia di rete attraverso <http://www.rom-o-matic.net>.
Se si utilizza <http://www.rom-o-matic.net>, occorre selezionare la versione di Etherboot, quindi si passa a una pagina interattiva dove si deve selezionare il modello dell'interfaccia di rete. Alla voce Choose ROM output format occorre scegliere: Floppy bootable ROM image (.zdsk).
|
Figura 307.8. Selezione dell'interfaccia RTL8139 118616:130016 da <http://www.rom-o-matic.net>.
|
In questo caso si ottiene il file eb-5.4.0-rtl8139.zdsk, che va copiato nel dischetto senza alcun file system:
# cat eb-5.4.0-rtl8139.zdsk > /dev/fd0[Invio]
A questo punto, il dischetto è pronto per essere usato per avviare il terminale che dispone di quella scheda.
Il terminale avviato con un dischetto contenente il codice Etherboot o attraverso PXE, dopo il caricamento del kernel, dopo l'esecuzione di /linuxrc nel disco RAM iniziale, innesta il file system principale con il protocollo NFS e avvia il sistema LTSP.
Ciò che si ottiene dipende in modo particolare dal file /etc/lts.conf (presso il servente NFS si tratta di /opt/ltsp/i386/etc/lts.conf), dove le direttive SCREEN_0n descrivono cosa avviare presso ogni console virtuale del terminale. Si può supporre che questo file contenga le righe seguenti:
|
In questo caso, nella prima console virtuale viene avviata una sessione grafica; nella seconda viene avviato un collegamento con il protocollo TELNET; nella terza viene avviata una shell locale (con i privilegi dell'utente root).
L'avvio della sessione grafica implica la disponibilità del servente XDMCP di accettare un accesso:
|
Naturalmente, tutto ciò che si fa utilizzando la sessione grafica o il collegamento con TELNET, si attua presso l'elaboratore remoto.
In condizioni normali, presso il terminale è disponibile soltanto l'utente root, dato che il lavoro viene svolto presso un elaboratore remoto che richiede una forma di autenticazione (attraverso XDMCP o TELNET).
Il fatto di disporre localmente dell'utenza root, a cui si accede senza fornire alcuna parola d'ordine, non porta ad alcun inconveniente, considerato che il file system di rete viene ottenuto in sola lettura.
Esiste comunque la possibilità di inserire nel file /opt/ltsp/i386/etc/lts.conf (presso il servente) delle direttive per fare in modo che il terminale utilizzi il protocollo NIS, allo scopo di riconoscere gli utenti. Tuttavia, non è prevista la possibilità di accedere al sistema localmente utilizzando le utenze remote. L'esempio seguente mostra le direttive in questione, ipotizzando il servizio NIS presso 172.17.1.254, con il nome del dominio NIS mio.nis:
|
La direttiva LOCAL_APPS = Y fa sì che presso il terminale, in corrispondenza della directory /home/, venga innestata la directory /home/ presso il servente NFS, già usato per il file system principale (naturalmente, è necessario che il servente NFS offra in condivisione tale directory). Le direttive NIS_* fanno sì che venga utilizzato il NIS per individuare le utenze (l'associazione tra numeri UID e nomi, così come l'individuazione delle directory personali).
Nel file /etc/lts.conf (ovvero il file /opt/ltsp/i386/etc/lts.conf presso il servente NFS), le direttive SCREEN_0n consentono di attribuire alla console virtuale 0n l'esecuzione di un certo script contenuto nella directory /etc/screen.d/.
|
A titolo di esempio, ci si può porre come obiettivo di modificare l'aspetto dell'invito (prompt) quando si avvia una shell locale. Per fare questo occorre intervenire nel file /etc/screen.d/shell (/opt/ltsp/i386/etc/screen.d/shell presso il servente NFS), che inizialmente potrebbe risultare essere quello seguente:
|
Si intende realizzare un invito contenente l'indirizzo IPv4 locale del terminale. Ecco come si potrebbe modificare lo script:
|
Il sistema LTSP è fatto principalmente per consentire l'accesso ad altri elaboratori, sia attraverso il protocollo XDMCP (per la grafica), sia attraverso TELNET o SSH (il secondo avviando il programma ssh da una shell locale). Eventualmente, si potrebbe considerare la possibilità di aggiungere altri programmi al sistema LTSP, in modo da consentirne l'uso locale presso i terminali.
Per aggiungere un programma, dovrebbe essere possibile prelevare il file eseguibile di un sistema GNU/Linux, fatto per lo stesso tipo di architettura, raccogliendo anche i file delle librerie che possono mancare nel sistema LTSP esistente. Per scoprire quali sono i file delle librerie da cui dipende un programma già compilato, si usa normalmente ldd:
$ ldd kbd_mode[Invio]
libctutils.so.0 => /lib/libctutils.so.0 (0xb7fd5000)
libconsole.so.0 => /lib/libconsole.so.0 (0xb7fc2000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7e8e000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fea000)
|
Eventualmente, per installare un programma del genere, senza mescolarlo con il resto del sistema LTSP, si può usare una directory che discende da /opt/ (/opt/ltsp/i386/opt/ presso il servente NFS), utilizzando poi uno script che imposta la variabile di ambiente LD_LIBRARY_PATH per consentire al programma di trovare le sue librerie.
La gestione del terminale a caratteri di LTSP è essenziale; questo significa che la mappa della tastiera è quella statunitense e che la codifica prevista è a soli 8 bit.
Quando si utilizza LTSP come terminale TELNET o SSH, se ci si deve collegare a un elaboratore presso il quale si prevede l'utilizzo della codifica UTF-8, il lavoro diventa complicato; pertanto è bene cercare di rimediare a questa mancanza di LTSP.
In questa sezione viene proposto un lavoro realizzato per nanoLinux IV, che include LTSP. In pratica sono stati copiati alcuni programmi, già compilati, da una distribuzione GNU/Linux Debian, individuando i file delle librerie mancanti, mettendo tutto nella directory /opt/nanoLinux/ (/opt/ltsp/i386/opt/nanoLinux/ presso il servente NFS):
$ tree opt/nanoLinux[Invio]
|
Si può osservare che: nella directory /opt/nanoLinux/bin/ sono stati copiati i programmi consolechars, kbd_mode e loadkeys; nella directory /opt/nanoLinux/lib/ sono stati collocati i file delle librerie che mancano nel sistema LTSP standard; nella directory /opt/nanoLinux/share/ sono stati messi dei file che generalmente si trovano all'interno di /usr/share/ di un sistema normale.
Tutta questa struttura serve per consentire allo script /opt/nanoLinux/bin/console-setup di configurare la tastiera e lo schermo in modo da gestire la codifica UTF-8:
|
Questo script deve essere incorporato da /etc/screen.d/telnet e da /etc/screen.d/shell. Ecco l'esempio più semplice di /etc/screen.d/shell:
|
Ciò che si ottiene è di configurare ogni volta la tastiera in modo molto semplice, attribuendo allo schermo un insieme di caratteri abbastanza generalizzato.
Linux terminal server project
Installation de Linux Terminal Server (LTSP 4.1) sur une Debian Testing
Appunti di informatica libera 2007.02 --- Copyright © 2000-2007 Daniele Giacomini -- <daniele (ad) swlibero·org>
Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome gestione_e_personalizzazione_dei_terminali_ltsp.htm
[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico]
