Differenze tra le versioni di "LTSP"
(→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 00:37, 4 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
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".