Ltsp MueKow

Ltsp Mue Cow è l'evoluzione di ltsp 4.2 del quale vi avevo parlato nel post precedente dove troverete anche una descrizione di cosa è ltsp (La lettura del post è consigliata prima di procedere a leggere ciò che segue). Questa versione è quella presente nei repository ubuntu.

Installazione

Per l'installazione su ubuntu basta installare i pacchetti ltsp-server e ltsp-server-standalone. A questo punto da terminale digitiamo il comando:

sudo ltsp-build-client

Questo comando scaricherà da internet i pacchetti necessari alla costruzione dell'ambiente chroot.

Differenza con la versione 4.2: I pacchetti verranno scaricati direttamente dai repository ubuntu e fanno parte della distribuzione ubuntu e non sono creati appositamente come accadeva nella versione 4.2.

Note e differenze con la versione 4.2.

Importante: per default (per come è programmato il client) appena installiamo l'ambiente chroot il thin client non si avvia se non viene utilizzata come scheda di rete di avvio la eth0. Quindi se il thin client ha più schede di rete, ricordarsi di utilizzare la prima. Inoltre, oltre ai servizi già necessari per la versione 4.2, è necessario che il server ssh sia attivo ed è necessario verficare che nella directory etc/ssh dell'ambiente chroot (/opt/ltsp/i386/etc/ssh) nel file contente gli host conosiuti, la prima riga sia qualcosa di simile a nomeserver, indirizzo_ip_server ssh-rsa AAA... Se manca l'ip del server provvedere ad aggiugerlo a mano.

Appena installato l'ambiente chroot è privo di file di configurazione in /etc/lts.conf e utilizza le opzioni di default che includono l'uso del display manager ldm presente nel pacchetto ltsp-client. Ldm è scritto in python e utilizza un greeter sempre scritto in python. Il greeter è molto simile a gdm dal punto di vista dell'interfaccia. Esso viene lanciato dallo stesso ldm. Quando inseriamo l'usenrame e la password, il greeter le stampa sullo stdout che viene letto da ldm il quale procede ad avviare una sessione X attraverso un tunnel ssh. Viene così avviato l'ambiente desktop di default scelto dall'utente.

Volendo usare xdmcp occorre scrivere il file /etc/lts.conf (nell'ambiente chroot) in modo simile a:

[Default]
SCREEN_06=shell
SCREEN_07=startx

In questo modo nella console virtuale 7 viene avviato lo script startx presente sempre nel pacchetto ltsp-client. Nello sceen 6 ho attivato invece una shell.

Ltsp 4.2

Ltsp (linux terminal server project) è un progetto che permette di utilizzare vecchi computer anche senza disco e con poca ram come terminali in grado di connettersi ad un server (terminal server) e di avviarsi via rete. Il server compie tutte le operazioni "costose " in termini di processore e di ram ed il client semplicemene visualizza il risultato. E' possibile avviare intere sessioni di X compreso gnome, openoffice, firefox e tutto il resto utilizzando questo sistema. In questo post spiegherò passo passo come fare ad installare un terminal server utilizzando la versione 4.2 di ltsp. In un prossimo post vi spiegherò come installare la nuova versione presente anche nei repository ubuntu e le differenze con la 4.2.

Di cosa ho bisogno?

Prima di procedere è necessario scaricare dal sito ufficiale di ltsp http://wiki.ltsp.org/twiki/bin/view/Ltsp/LTSP-42 il pacchetto ltsp-utils_0.25_all.deb che è l'ultima versione nel momento in cui sto scrivendo questo post. Installiamo il pacchetto con:

sudo dpkg -i ltsp-utils_0.25_all.deb

Quindi installiamo tutti gli altri pacchetti necessari direttamente dal repository ubuntu:

• dhcp3-server
• dhcp3-common
• tftpd-hpa
• nfs-kernel-server
• xinetd
• libwww-perl

Installazione

Dopo aver installato tutti i pacchetti necessari, lanciamo da root il comando ltspadmin Seguiamo il wizard fino alla fine. Un altro comando utile è ltspcfg che ci permette do controllare lo stato dei servizi necessari e di impostare la configurazione di base. Assicuriamoci che le impostazioni della rete e i percorsi siano corretti nel file di configurazione del server dhcp /etc/dhcp3/dhcpd.conf. A questo punto dobbiamo assicurarci che tutti i servizi siano attivi. Quindi attiviamo il server dhcp, il servizio portmap necessario ad nfs, nfs. Per abilitare il servizio tftp creiamo il file /etc/xinet.d/tftp con questo contenuto:

service tftp
{
   disable         = no
   socket_type     = dgram
   protocol        = udp
   wait            = yes
   user            = root
   server          = /usr/sbin/in.tftpd
   server_args     =  -s /tftpboot
}

e riaviamo il servizio xinet.
Dobbiamo abilitare inoltre il servizio xdmcp. Per farlo se usiamo gdm dobbiamo editare il file /etc/gdm/gdm.conf cercare la sezione [xdmcp] e impostare enable su true. Quindi riavviamo gdm.

Come avviene il boot?

Di seguito spiegherò come avviene il boot usando il PXEclient della scheda di rete. Il client cerca un server dhcp nella rete. Il server dhcp oltre a fornire un ip al client, gli fornisce alcuni parametri necessari per effettuare il boot. Tra questi c'è un root-path che vedremo dopo a cosa serve, e il percorso al linux loader pxelinux. A questo punto il client carica il piccolo loader il quale a sua volta carica il kernel linux. I parametri del loader si trovano nel file /tftpboot/lts/[versione-kernel]/pxelinux.cfg/default Tra i parametri abbiamo root=/dev/ram0 e initrd=initramfs.gz. Ciò significa che non appena il kernel ha finito di avviarsi carica il il file initramfs.gz in ram, lo decomprime (è un archivio cpio compresso con gzip) e lancia il file linuxrc o init. In questo caso non essendo presente il file linuxrc lancia init che è uno script shell. Per vedere il contenuto di questo script bisogna decomprimere l'archivio in questo modo:

* gunzip initramfs.gz
* cpio -i -d -I initramfs

L'ultimo comando ricostrurà un albero delle directory stile unix. Lo script init presente nella radice dell'albero oltre ad altre operazioni, cerca per vedere se l'opzione root-path è stata fornita dal server dhcp, dando un errore altrimenti. Se l'opzione è presente e sia ad esempio:

option root-path              "192.168.50.1:/opt/ltsp/i386";

il percorso specificato verrà montato via nfs e dopo qualche altro comando, la directory sulla quale è stato montato diventerà la nuova root.

A questo punto il file importante è /opt/ltsp/i386/etc/lts.conf che nel mio caso è sotto la forma:

[Default]
    SERVER             = 192.168.50.1
    XSERVER            = auto
    X_MOUSE_PROTOCOL   = "PS/2"
    X_MOUSE_DEVICE     = "/dev/psaux"
    X_MOUSE_RESOLUTION = 400
    X_MOUSE_BUTTONS    = 3
    USE_XFS            = N
    SCREEN_01          = startx
    SCREEN_02          = shell

In pratica questo file viene utilizzato dallo script /opt/ltsp/i386/etc/rc.sysinit per lanciare il server X (client per l'xdmcp che gira sul terminal server) o una sessione telnet o altro. Nel mio caso ho aggiunto la variabile SCREEN_02 = shell che lancia una shell (busybox) direttamente sul thin client (non associata in alcun modo al terminal server). In questo modo su un terminale virutale ho la shell e sull'altro il server x
I valori associati alle variabili SCREEN sono degli script presenti nella directory /opt/ltsp/i386/etc/screen.d/

Google web toolkit sotto licenza Apache 2.0

La nuova versione 1.3 RC del gwt (google web toolkit) è stata rilasciata sotto la licenza open Apache 2.0. Il google web toolkit è un software che ci permette di scrivere in modo semplice applicazioni Ajax direttamente in java. Il compilatore gwt si preoccuperà di tradurre il nostro codice java in JavaScript ed Html compatibile con i maggiori browser (firefox, ie, safari, opera). La cosa bella è che non ci si deve preoccupare delle incompatibilità tra i vari browser. In teoria si potrebbe anche non conscere JavaScript affatto. Riporto un piccolo esempio direttamente dal sito per mostrare il modo di operare di gwt:

public class Hello implements EntryPoint {
public void onModuleLoad() {
 Button b = new Button("Click me", new ClickListener(){
   public void onClick(Widget sender) {
     Window.alert("Hello, AJAX");
   }
 });
 RootPanel.get().add(b);
}
}

Come si può vedere viene utilizzato un modo di programmare molto simile al modo classico utilizzato di solito in Java. I concetti sono gli stessi: pannelli, widgets, pulsanti etc. Insomma gwt appare come una astrazione al browser e alle sue teconologie riportando lo sviluppatore java ad un livello più familiare e semplice. Dal mio canto non sono mai stato un amante di java. Qualcuno di voi saprà che il mio linguaggio preferito resta quello del pitone, ma nonostante ciò trovo molto più semplice mettersi a programmare una applicazione web utilizzando il classico paradigma dei widgets piuttosto che impazzire con java script. Ancora non ho avuto purtroppo modo di testarlo (mancanza di tempo) Spero di poterlo fare presto per dirvi qualcosa in più.

Tip: bash e la storia dei comandi

Una funzione della shell bash che può risultare molto comoda è la ricerca nella storia dei comandi. Io l'ho scoperta da poco. In pratica basta premere Ctrl-R durante una sessione bash e vi apparirà questa riga:

(reverse-i-search)`':

Digitando qualche lettera bash inizia ad effettuare la ricerca stampandovi a video il comando che ha trovato. Premendo invio il comando viene eseguito. Premendo Ctrl-C la ricerca viene interrotta senza eseguire alcun comando.
Questa funzione è comodissima se avete digitato lunghi comandi tediosi da riscrivere e ricordare.

Un modulo portabile per suoni in python

Il modulo che vi riporterò di seguito serve per poter far emettere un suono al vostro programma python (in genere suoni brevi associati a particolari eventi) senza preoccuparvi se vi trovate su piattaforma windows o su linux chiamando una semplice funzione con parametro il nome del file da suonare.
Ecco un basilare esempio di utilizzo:

import sndplay

sndplay.play("percorso_del_file.wav")

Come avrete notato è molto semplice da usare. Se vi trovate su una piattaforma diversa dalle due supportate la funzione non fa nulla. Come parametro ho inserito un file wav. In realtà su linux viene accettato come parametro un qualsiasi formato supportato dalle librerie gstreamer ma se mettiamo un file diverso dal wav perdiamo la portabilità perché (almeno per ora) su windows è supportato solo il formato wav.

Passiamo ora al codice:

import threading
import os

(
    GSTPLAY,
    WINPLAY,
    NOENGINE
) = range(3)

try:
    import gst
    import gobject
    ENGINE = GSTPLAY
except ImportError:
    try:
            import winsound
            ENGINE = WINPLAY
    except ImportError:
            ENGINE = NOENGINE

class __GstPlayThread(threading.Thread):
    def __init__(self, ply):
            self.ply = ply
            threading.Thread.__init__(self)
    def run(self):
            self.ply.set_state(gst.STATE_PLAYING)
            def bus_event(bus, message):
                    t = message.type
                    if t == gst.MESSAGE_EOS:
                         self.ply.set_state(gst.STATE_NULL)
                    return True
            self.ply.get_bus().add_watch(bus_event)


def __gstplay(filename):
    cwd = os.getcwd()
    location = os.path.join(cwd, filename)
    ply = gst.element_factory_make("playbin", "player")
    ply.set_property("uri", "file://" + location)
    pt = __GstPlayThread(ply)
    pt.start()

def __winplay(filename):
    cwd = os.getcwd()
    location = os.path.join(cwd, filename)
    import thread
    def wplay():
            winsound.PlaySound(location,
 winsound.SND_FILENAME)
    thread.start_new_thread(wplay, ())

if ENGINE == GSTPLAY:
    play = __gstplay
    pass
elif ENGINE == WINPLAY:
    play = __winplay
else:
    def play(filename):
            pass

Attenzione: su linux è supportata solo la versione 0.10 delle pygst!!!

Come si può notare l'effettivo playing del file viene eseguito da un thread in modo che la play non sia bloccante. Cio vuol dire che mentre il suono viene riprodotto in background, il nostro codice può continuare ad essere eseguito ;)

Questo modulo l'ho scritto inizialmente per planimo ma ho pensato che sarebbe stato utile postarlo a parte con qualche spiegazione a contorno

Alice adsl e ubuntu

Vi è capitato di connettervi con alice adsl e avete avuto problemi?
Avete seguito la classica procedura con pppoeconf da console impostando correttamente i vostri dati, ma in seguito lanciando pon per andare online non riuscite a navigare? Se è questo il problema, controllate prima di tutto che l'interfaccia ppp0 sia stata creata correttamente lanciando da console il comando ifconfig (controllate che nell'output ci sia la voce ppp0). Se così non è questa guida non fa per voi. Se invece è così bisogna solo impostare il routing correttamente con:

sudo route add default dev ppp0