LTSP

Da RELug :: Reggio Emilia Linux User Group.
(Differenze fra le revisioni)
(Client)
(Personalizzazioni)
Riga 196: Riga 196:
  
 
== Personalizzazioni ==
 
== Personalizzazioni ==
 +
 +
Ad oggi (4 Aprile 2012) e` stato aggiunto un solo utente (relug) e non e stato preparato nessun "lts.conf".
  
 
== Approfondimenti ==
 
== Approfondimenti ==

Versione delle 23:37, 3 apr 2012

Indice

Linux Terminal Server Project

Pagina provvisoria, da qualche aprte si deve pur partire :) --Davide 07:24, 22 mar 2012 (UTC)

Grandi correzioni, che dimostrano quanto poco avessi capito :) --Davide 22:21, 3 apr 2012 (UTC)


LTSP in breve (in entrambi i sensi, per l'abbreviato e per la descrizione):

Sistema di rete formato da uno o piu` Server che si prendono in carico un numero imprecisato (dipende dalla potenza del server) di macchine (stupide) dette comunemente "Thin Client".

In rete e` possibile reperire una miriade di informazioni, e` sufficiente inserire "ltsp" in un qualsiasi motore di ricerca. Vi consiglio di leggere molto attentamente il manuale in pdf che troverete proprio nel sito ufficiale, chiarira` molti dubbi. Quello che troverete scritto qua e` solo una sintesi con l'aggiunta di qualche appunto.

Funzionamento

Server LTSP, fornisce i servizi necessari affinche` il Client, possa avviarsi e caricare in memoria il sistema operativo. Per fare questo occorrono alcuni servizi "essenziali", NBD (o il vecchio NFS), TFTP e DHCP.

A grandi linee, ecco quel che succede (ho provato a schematizzarlo in un disegno o una tabella, ma e` un po` difficile, portate pazienza e nel frattempo cercate di capirlo con questa descrizione):

Dato per scontato che il Server sia gia` configurato, funzionante ed acceso, avviando una prima macchina client, preconfigurata per il boot da scheda di rete, questa si mette in cerca del servizio che possa risponderle, il DHCP.

DHCP che invia le informazioni necessarie (il servizio TFTP), affinche` il Client possa scaricare ed avviare il kernel Linux, che, opportunamente parametrizzato, andra` a caricare l'immagine di base del sistema operativo (dicamo opportunamente scheletrizzato), tramite NBD.

Come ultima fase, questa immagine contiene i comandi per LDM, col quale il client si "aggancia" al server X del server LTSP.

Pre-Configurazione

E` stato predisposto un ambiente virtualizzato su di una macchina client facente parte di una rete (col suo server, la connessione internet, ecc.ecc.).

Le macchine virtualizzate:

Server (64bit)
RAM = 1024M
Processori = 2
HDD1 = 40G SCSI
HDD2 = 2G SCSI (swap)
ETH = 2 schede
Audio
ecc.ecc. ..
Client (32 e 64)
RAM = 512M
Processori = 1
Nessun HDD
ETH = 1 scheda configurata per il boot
Audio
ecc.ecc. ..

Nella virtualizzazione e` stata preparata una sottorete (virtuale) con un indirizzamento fasullo e senza DHCP, per collegare i thin clients al server senza interferire con altre reti.

Installazione

Molte fra le attuali distribuzioni semplificano molto l'installazione.

Nella Ubuntu per esempio, e` sufficiente utilizzare la versione "alternate", premere il tasto F4 in avvio selezionando installazione LTSP.

Debian

E` la distribuzione che ho scelto per questo primo approccio al sistema.

Una volta installato il sistema di default (sul pc Server, base + desktop) bastano pochi comandi per installare il server LTSP:

apt-get install ltsp-server-standalone
ltsp-build-client
ltsp-build-client --arch i386

L'ultimo per predisporre anche l'immagine del 386, visto che l'installazione server e` "amd64".


Configurazione

Minimo indispensabile

eth1

Dopo il login sul server configurate la seconda scheda di rete (la prima s'e` beccata l'indirizzo DHCP durante l'installazione ed e` gia` configurata, collegata e funzionante), ho scelto:

Address = Gateway = DNS = 192.168.11.1
Netmask = 255.255.255.0
Configurazione del DHCP

Modifiche al file "/etc/dhcp/dhcpd.conf", riporto sol alcune delle righe modificate, le altre non sono state variate:

# option definitions common to all supported networks...
option domain-name "ltsp.local";
option domain-name-servers 192.168.11.1, ltsp.ltsp.local;
#option ntp-servers 192.168.11.1;
option routers 192.168.11.1;
option broadcast-address 192.168.11.255;
option subnet-mask 255.255.255.0;

default-lease-time 600;
max-lease-time 7200;

#Aggiunta alla fine del file
include "/etc/ltsp/dhcpd.conf";

Si puo` notare che ho assegnato il nome della macchina "ltsp" e della rete "ltsp.local", oltre che questo server fara` da gateway/router/dns.

Ora tocca alla parte DHCP del nostro sistema LTSP, ho modificato cosi` il file "/etc/ltsp/dhcpd.conf":

#
# Default LTSP dhcpd.conf config file.
#

authoritative;

subnet 192.168.11.0 netmask 255.255.255.0 {
    range 192.168.11.20 192.168.11.250;
    option domain-name "ltsp.local";
    option domain-name-servers 192.168.11.1;
    option broadcast-address 192.168.11.255;
    option routers 192.168.11.1;
    next-server 192.168.11.1;
#    get-lease-hostnames true;
    option subnet-mask 255.255.255.0;
    option root-path "/opt/ltsp/amd64";
#    if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" {
        filename "/ltsp/amd64/pxelinux.0";
#    option root-path "/opt/ltsp/i386";
##    if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" {
#        filename "/ltsp/i386/pxelinux.0";
#    } else {
#        filename "/ltsp/i386/nbi.img";
#    }
}

Ho lasciato attivo solo per Thin Clients a 64bit, ho disattivato tutti gli "if" perche` i clients caricavano il file errato.

Mi sembra che non ci sia nient'altro, non per una configurazione di base perlomeno.

Ok, riavviamo tutto:

invoke-rc.d isc-dhcp-server restart
invoke-rc.d openbsd-inetd restart

E avviamo il nostro client ..

Upgrade

Server

Per l'upgrade del server si procede nel solito modo:

apt-get update
apt-get upgrade

Client (immagine)

Per le macchine client, o meglio, per lo scheletro di sistema che devono caricare in avvio, nessuna macchina deve essere collegata al server e si procede effettuando il cambio della root del filesystem:

chroot /opt/ltsp/<arch>

Dove <arch> corrisponde alla tipologia dell'architettura della macchina, esempio: i386.

Ora, il filesystem sarebbe "spento", per l'aggiornamento, il sistema deve credere che invece sia funzionante, quindi avere una "/proc" in funzione:

mount -t proc proc /proc

Adesso la procedura e` sempre uguale:

apt-get update
apt-get upgrade

Prima di uscire dal cambio root (chroot), ricordate di smontare (anche di uscire :) ):

umount /proc
exit

Importante

Se nell'upgrade e` stato aggiornato anche il kernel, dopo essere usciti e` necessario informare il server:

ltsp-update-kernels

Per il medesimo motivo, si devono aggiornare le immagini (si proprio le immagini scheletro che vengono caricate dai client, quelle col nome <arch>.img per intenderci) della "chroot", il comando e` (da ripetere per ogni architettura):

ltsp-update-image --arch=<arch>

Personalizzazioni

Ad oggi (4 Aprile 2012) e` stato aggiunto un solo utente (relug) e non e stato preparato nessun "lts.conf".

Approfondimenti

Terminata l'installazione standard, nel caso di Debian, e` possibile loggarsi dal client LTSP con lo username inserito durante l'installazione ed anche come root. Da notare che ci si trova loggati nella macchina "server".

Nell'installazione Ubuntu, non sembra essere possibile.


Al termine di un aggiornamento "client", le directory "/opt/ltsp/<arch>/boot" e "/srv/tftp/ltsp/<arch>" appaiono disallineate. Sono di nuovo "sincronizzate" dopo il comando:

ltsp-update-kernels

Da chiarire il comando che aggiorna le immagini delle chroot:

ltsp-update-image

Probabilmente non ho visto niente perche` ricrea le configurazioni "initrd" e "pxe", ma su un kernel che ha il medesimo nome del precedente, in effetti sono gli unici che hanno l'ora piu` recente.


Debian "squeeze" utilizza gia` "nbd" invece di "nfs".


Strumenti personali