Xorg & ssh, altro che desktop remoto

gnome-system-monitor in esecuzione in locale e in remoto

Personalmente non mi piacciono i desktop remoti.  Li trovo troppo slegati dall’ambiente dove opero perché pensati per riprodurre l’intero desktop del computer remoto, perdendo così in velocità e in integrazione con il sistema locale. Una soluzione non ottimale in molti casi. Ma soprattutto provo un certo disagio nel dover usare un programma particolare per fare qualcosa che, come vedremo, è già svolto egregiamente dal sistema stesso.

Su un sistema Unix in genere non c’è bisogno di usare una GUI per controllare un sistema remoto, basta una shell testuale. A volte però può essere molto utile usare un’applicazione grafica presente sul computer remoto. Ad esempio io non saprei fare a meno di synaptic e di un client grafico ftp. Certo potrei usare apt da terminale e un ftp testuale ma… non mi va.

L’ideale sarebbe quindi poter lanciare un’applicazione che gira sul PC remoto, ma viene visualizzata in quello che uso materialmente. Magari in modo trasparente, senza avere di mezzo un intero desktop che mi rallenta. E magari potrei desiderare di far interagire applicazioni locali e applicazioni remote, banalmente con semplici copia e incolla dagli appunti, ad esempio.

La storia

Tanti tanti anni fa non esistevano i personal computer. Nelle Università americane, come anche nelle pubbliche amministrazioni e nelle grandi corporation, c’erano uno o più grandi elaboratori su cui girava Unix e tante telescriventi collegate ad esso. Si scriveva su una tastiera e si riceveva l’output su un foglio di carta o su un piccolo schermo simile a quelli delle vecchie calcolatrici. Ancora oggi i terminali virtuali cui accediamo su GNU/Linux premendo ctrl+alf+f1, f2, ecc. si chiamano tty che sta per teletype cioè appunto telescrivente. Ben presto però arrivarono gli schermi a tubo catodico e anche il mouse. I terminali divennero così più user-friendly. Ma si trattava pur sempre di terminali e non di computer con proprie capacità elaborative. I programmi continuavano ad essere eseguiti in remoto.

Le Università però avevano bisogno di qualcosa di più che visualizzare dati testuali. In molti campi della matematica e della fisica abbiamo bisogno di grafici e di animazioni simulate. Unix aveva quindi necessità di un’interfaccia grafica, ma un po’ particolare: doveva infatti funzionare in rete, in modo da permettere di vedere i grafici, elaborati da un grande computer, sui “thinclient” dell’epoca. E fu così che, anticipando lo slogan di SUN “la rete è il computer” nacque il sistema a finestre X che vide la luce nei laboratori del famoso MIT (Massachusetts Institute of Technology). Il nome bizzarro è dovuto al fatto che è derivato da un sistema precedente, usato su un altro sistema operativo, chiamato W (il sistema operativo invece si chiamava V) dove la W stava appunto per Windows, finestre (nulla a che vedere con Microsoft Windows però). Poiché la X viene dopo la W, quale nome migliore per il successore di un programma che si chiama così? X ha una lunga storia e ne esistono molte versioni, anche per Windows. A noi basta sapere che  il server utilizzato da praticamente tutte le distribuzioni GNU/Linux è “X.org”

Come funziona

X è nato nei primi anni ’80, più o meno nello stesso periodo in cui nasceva il primo Machintosh e la IBM lanciava il PC con MS DOS. Come già detto, però, Unix era un sistema concepito per funzionare in rete e il suo sistema grafico non poteva lavorare solo sulla macchina principale, ma doveva essere distribuito nel network. Gli sviluppatori del MIT pensarono quindi di creare un software che girasse su macchine dalle basse capacità computazionali ma dotate di hardware grafico, un software concepito per ricevere i dati da visualizzare dalla rete. Scrissero quindi un protocollo di rete (che si chiamava sempre X) e un programma server che ricevesse i dati dal computer principale e li visualizzasse dentro delle finestre nel computer dove veniva eseguito X. Il protocollo di comunicazione in uso ormai dal lontano 1987 è la versione 11 (quindi ci si riferisce ad esso chiamandolo X11).

E’ importante capire questo particolare: è il computer-terminale che esegue il server X. Le applicazioni che invece sono in esecuzione sul computer principale si comportano come client, in quanto richiedono a X un servizio, ovvero visualizzare il loro output. Insomma funziona un po’ al contrario della coppia server web/browser dove apache elabora e firefox visualizza.

Quindi, riassumendo, quando facciamo partire una qualsiasi applicazione grafica, ad esempio il file manager Nautilus, essa è il client mentre il server X è appunto il server. E non è detto che X e Nautilus siano sulla stessa macchina: uno potrebbe stare in Australia e l’altro in Italia e comunicare attraverso Internet.

Questa immagine tratta da Wikipedia schematizza il funzionamento di X, con due applicazioni “locali” in esecuzione e una “remota”.

In pratica

Le istruzioni che seguono presuppongono che abbiate due computer, uno che chiameremo PC_DESKTOP e l’altro PC_PORTATILE. In entrambi gira una qualsiasi distribuzione GNU/Linux per Desktop (quindi non server). Il nostro scopo è vedere sul PC_PORTATILE le applicazioni che girano sul PC_DESKTOP all’interno di una rete locale casalinga, protetta dall’esterno con un firewall (che tipicamente già è attivato nel router). Qualora la vostra configurazione di rete sia differente vanno prese delle precauzioni di sicurezza. Inoltre se su PC_DESKTOP gira un sistema senza interfaccia grafica (ad esempio Ubuntu Server), probabilmente non avrete installate applicazioni grafiche. E’ però possibile installarle ugualmente senza installare tutto Xorg. Infatti a noi serve Xorg su PC_PORTATILE, non su PC_DESKTOP! Vi consiglio di chiedere su LinuxQualityHelp.it istruzioni su come configurare al meglio il tutto, indicando precisamente come è composta la rete e quali applicazioni desiderate eseguire in rete.

Esistono diversi modi per sfruttare le capacità di rete di X, sia per singole applicazioni che per l’intero desktop, qui presenteremo il più comune, che fa uso di ssh (secure shell). OpenSSH è un sistema per trasmettere la shell di un computer remoto al computer locale. Nato su OpenBSD, è da anni ormai lo standard di fatto perché è molto sicuro: è in grado di criptare i dati trasmessi e possiede sofisticati sistemi di autenticazione. A noi però tutto ciò non interessa affatto. Ciò che ci serve è poter accedere alla shell di PC_DESKTOP per lanciare dei programmi e che attraverso in canale di comunicazione passino anche i dati di Xorg. Questo meccanismo si chiama X forwarding, cioè “inoltro di X” perché il protocollo di rete X11 viene inoltrato attraverso la connessione di ssh (in gergo si dice che passa attraverso un “tunnel” ssh.)

Il client ssh è installato di default in tutte le distribuzioni. Su PC_DESKTOP abbiamo però bisogno del server ssh. Per far ciò installiamo il pacchetto openssh-server. Su Ubuntu:

sudo apt-get install openssh-server

Ora abbiamo bisogno di sapere l’indirizzo IP di PC_DESKTOP. Possiamo tranquillamente controllare dal network-manager (tasto destro sull’icona nel pannello > informazioni connessione) oppure digitando il comando

ifconfig

e leggendo la parte riguardante la scheda di rete (ad esempio eth0) dove leggeremo qualcosa del genere

indirizzo inet:192.168.1.3

ora su PC_PORTATILE apriamo il terminale e diamo il comando:

ssh nome_utente_remoto@ip_del_pc_desktop

ad esempio:

ssh mario@192.168.1.3

Ci verrà chiesto se memorizzare la connessione come fidata, diciamo di sì e poi la inseriamo la password dell’utente remoto. Fatto ciò, il prompt dei comandi apparirà diverso. Invece di

giuseppe@ubuntu-laptop:~$

vedremo

mario@ubuntu-desktop:~$

e ciò è ovvio: non siamo più sul nostro PC_PORTATILE, ma siamo su PC_DESKTOP 🙂

da questa shell possiamo fare un po’ tutto ciò che faremmo se fossimo davanti al terminale di PC_DESKTOP. Tranne che eseguire applicazioni grafiche però. Se ci provassimo, esse funzionerebbero sì, ma verrebbero visualizzate sullo schermo di PC_DESKTOP.

Abbiamo bisogno di attivare il già citato X forwarding (inoltro di X) attraverso ssh. Apriamo il file di configurazione del server ssh sul PC_DESKTOP con

sudo gedit /etc/ssh/sshd_config

(se usate KDE mettete kate al posto di gedit, se usate xfce mettere mousepad, se operate nella shell testuale mettete nano). Assicuriamoci che vi sia una riga configurata così:

X11Forwarding yes

In questo modo è attivato il forwarding di X. Su Ubuntu dovreste trovarla di default.

Se invece abbiamo dovuto modificare il file, sarà necessario riavviare ssh server su PC_DESKTOP con:

sudo /etc/init.d/ssh restart

mentre sul PC_PORTATILE digitiamo exit per uscire dalla sessione ssh precedentemente avviata.

Dal PC_PORTATILE ora riconnettiamoci ma abilitando l’X forwarding. La forma canonica è:

ssh -X nome_utente_remoto@ip_pc_desktop

Ma noi preferiremo questa forma:

ssh -Y -C nome_utente_remoto@ip_pc_desktop

che fa uso del forwarding “fidato” di X  (opzione -Y invece che -X) e comprime i dati scambiati tra le due macchine (opzione -C).

E adesso lanciamo una applicazione grafica:

gnome-system-monitor

andate a controllare la scheda sistema e vedrete i dati del PC DESKTOP 🙂

Cose da sapere

Quando lanciate una applicazione GNOME è opportuno farlo con questa sintassi

dbus-launch programma

esempio:

dbus-launch nautilus

Potete usare applicazioni 3D, ma non aspettatevi ovviamente grandi prestazioni, per cui niente giochi o googleearth. Per fare un test, lanciate uno screensaver:

/usr/lib/xscreensaver/glschool

Le applicazioni OpenGL però non funzionano se uno dei due computer usa driver proprietari Nvidia o Ati e l’altro no, oppure se uno usa Nvidia e l’altro i driver proprietari Ati, questo a causa delle differenti librerie grafiche OpenGL.

Potete comunque provare con il rendering indiretto, lanciando i programmi così:

LIBGL_ALWAYS_INDIRECT=yes programma

Riguardo i video, l’estensione XV non sembra funzionare in rete, per cui il lettore multimediale va configurato per non usarla. Ad esempio per totem, lanciate gstreamer-properties (quello della macchina remota) e selezionate X senza XV nella tab video. Ovviamente, come per OpenGL, non aspettatevi grandi prestazioni, al limite potete guardare piccoli video. Tutto dipende dal vostro collegamento però, se avete una gigalan è ben diverso da una rete 10/100 Mbit.

L’audio non viene reindirizzato, per il semplice motivo che Xorg non gestisce l’audio. Vedremo in un prossimo post come usare pulseaudio per usare la scheda sonora di un PC con i programmi di un altro PC.

Se il PC remoto non ha Xorg, perché ad esempio è Ubuntu Server , questo non importa, perché come ho spiegato lo Xorg che viene usato è quello locale. Si possono installare le applicazioni grafiche ugualmente senza la presenza del server X, avendo magari cura di non installare quelle pesantemente dipendenti da un ambiente desktop, ma gli equivalenti più leggeri. Per evitare che l’installazione del pacchetto si porti dietro anche Xorg, che non vi serve, in genere basta usare l’opzione –no-install-recommends di apt-get. Chiedete consiglio su LQH in caso di dubbio.

Il drag and drop di file non funziona. Ovviamente, visto che parliamo solo di trasferimento di dati grafici. Potete però usare SSH per vedere i file remoti tramite Nautilus, premendo ctrl+L e scrivendo ssh://ip_pc_remoto.

Funziona però il copia e incolla tra applicazioni remote e locali di testi e immagini.

Infine

Ci sono altri modi per usare Xorg in rete, ma questo è quello che preferisco. Volendo però si può aprire l’intero desktop come per VNC, oppure si possono migliorare le prestazioni, soprattutto su un collegamento via Internet, tramite NX, un software italiano nato proprio per usare X su connessioni lente. NX è proprietario, comunque la versione per Linux è gratuita. Le librerie sono open source, per cui esiste una versione libera chiamata FreeNX.