Manovrare X da remoto: differenze tra le versioni

terminata
m (aggiunta categoria e template)
(terminata)
Riga 1: Riga 1:
{{Guida da adottare|[[Utente:HAL 9000|HAL 9000]]}}{{Versioni compatibili|Wheezy|Jessie}}
{{Versioni compatibili|Wheezy|Jessie}}
== Introduzione ==
== Introduzione ==
Nelle distribuzioni GNU/Linux e in generale nei sistemi UNIX e Unix-like l'interfaccia grafica (''GUI'') non è parte del kernel ma gestita da un programma a parte: l' ''X window system'' o semplicemente server '''X''', di cui [[Xorg]] rappresenta l'implementazione attualmente più diffusa.
Nelle distribuzioni GNU/Linux e in generale nei sistemi UNIX e Unix-like l'interfaccia grafica (''GUI'') non è parte del kernel ma gestita da un programma a parte: l' ''X window system'' o semplicemente server '''X''', di cui [[Xorg]] rappresenta l'implementazione attualmente più diffusa.
Riga 92: Riga 92:
per mandare il messaggio di richiesta in ''broadcast'' (ossia a tutti gli [[host]] della rete), per effettuare la connessione al server X del primo ''host'' che risponde.
per mandare il messaggio di richiesta in ''broadcast'' (ossia a tutti gli [[host]] della rete), per effettuare la connessione al server X del primo ''host'' che risponde.


Si visualizzerà <code>xdm</code> in esecuzione sul server, che si potrà utilizzare per autenticarsi, utilizzando le credenziali di accesso di un utente che ha accesso alla macchina remota.


== Altro ==
Si avrà così accesso a un'intera sessione grafica, anche se con qualche limitazione di performance. Si noti infatti che il protocollo X11 trasmetterà tutto lo schermo, comprese le aree non necessarie perché non cambiate: non c'è una cache alcun tipo di funzionalità "trasmetto solo cosa è cambiato".
TODO: da sistemare (per ora commentato)
 
<!--
Riguardo la sicurezza il protocollo X è applicabile solo in ambienti fidati Lan e non è cosigliabile avere sessioni X attraverso la grande rete. Se vuoi utilizzare X attraverso la rete è consigliabile incanalare il protocollo X in un protocollo sicuro come ssh. In ogni caso ci sono anche altri modi in aggiunta ad ssh che puoi utilizzare per proteggere le tue macchine uno di questi è xhost ma anche meglio con un programma xauth utilizzato per autenticare i clients: ''Xauth'' può funzionare in vari modi: uno di essi è attraverso l'utilizzo di un cookie. Un X-client per collegarsi ad un X-server ha bisogno di conoscere una sequenza di dati casuali generati dal server conosciuto come cookie che funziona in maniera molto simile ad un session password: se il cookie trasmesso dal client non corrisponde a quello del server, Xserver rifiuterà la connessione. Xserver di default è in ascolto sulla porta
 
* 6000 per il display :0
* 6001 per display:01 
''ecc.''
 
Programmi come xdm , gdm o kdm sono demoni che vanno in background, sono soliti essere iniziati da init al boot e sono sempre in attività. Si occupano di iniziare sessioni X-server se necessario, del login grafico, preparano i cookies di xauth che servono per autenticare i clients e fanno partire il programma adatto per ciascun desktop e così via.
 
Xdm può essere configurato per accettare richieste XDMCP dal network. Questi sono speciali pacchetti UDP che un xserver trasmette da porta 177 per richiedere login remoti. Quando un Xserver richiede di collegarsi ad un altra macchia con xdm allora bisogna lanciare l'X-server con opzioni "-query" o "-broadcast". L'opzione "-query" viene usata quando X-server deve lanciare un richiesta XDMCP ad una macchina in particolare, invece "-broadcast" la trasmette a tutte le macchine nel network.
<pre>
X -query 192.168.1.2
</pre>
o
<pre>
X -broadcast
</pre>
 
L'uso di X attraverso la rete può delle volte causare dei problemi di rendimento e performance. Il protocollo X trasmetterà tutte le righe, tutte le aree anche non necessarie, non c'è una cache alcun tipo di funzionalità "trasmetto solo cosa è cambiato".Significa che se un' area è stata ridisegnata tre volte il protocollo X trasmetterà tutte le volte che quell'area è stata cambiata mentre basterebbe trasmettere solo l'ultima delle tre e questo potrebbe risultare un pò dannoso su connessioni lente. Il protocollo VNC è consapevole di questo aspetto infatti il VNC server aspetta connessioni dai VNC clients e quando il client si connette VNC trasmette l'intero desktop al client. VNC è sia un vncserver che un x-server. Quando parte si mette in ascolto sulla sua porta tcp la 5900 (+ il numero di display :0.1 x 5901, :02 x 5092 ecc.) in attesa di VNC clients che si collegano. Rimane in ascolto anche sulla socket del display proprio come un X-server ma, invece di trasmettere la richiesta su un monitor, la tiene in memoria per trasmetterla al client. Per configurare VNC c'è bisogno della presenza di un vncserver da essere lanciato manualmente. Per prima cosa bisogna impostare una vncpasswd che poi verrà usata per il login. Ci si collega con ssh senza l'opzione ''-X'':
<pre>
ssh username@hostremoto
</pre>
Poi una volta collegato lanci ''vncserver :1'' che in pratica mette vncserver in ascolto sul display 1 cioè tcp port 5901.Dopo puoi lanciare il vnc client come per esempio tightvncviewer o vncviewer o svncviewer in questo modo :
<pre>
vncviewer hostremoto:1
</pre>
Poi ti verrà chiesta la password e tu introdurrai quella stabilita in precedenza et voilà eccoti il desktop remoto in locale in tutto il suo splendore.
Questa configurazione presenta dei rischi, porta 5900 e 5800 deve essere aperta nel firewall e la comunicazione è in chiara. Per criptarla c'è bisogno di un tunnel ssh. Ancora una volta l'amico ssh ci viene incontro:
<pre>
ssh -C -L 5901:127.0.0.1:5901 user@remotehost
</pre>
questo comando metterà ssh in ascolto sulla porta locale 5901 fino alla porta remota 5901 quella del server vnc. Una volta loggati sulla macchina remota, sulla macchina locale apri vncviewer (un qualsiasi client vnc,o addirittura il browser con java) e lo punti a ''localhost:5901'' vncviewer questo comando ti permetterà di criptare la tua connessione verso il server vnc attraverso un tunnel ssh.
 
== X su altri sistemi operativi ==
Molte persone credono che X sia stato progettato solo per GNULinux e unix-like ma in realtà come ogni prodotto unix il primo intento è la portabilità verso quanti più OS è possibile .
Altri ottimi progetti sono il [http://www.ltsp.org Linux terminal Server project] che usa tutte le potenzialità di X in scenari dove gli utenti sono collegati ad un X server centrale attraverso dei thin client o diskless machine con un grosso abbatimento sui costi e in questo senso come non menzionare il progetto [http://www.progettolazzaro.it/ProgettoLazzaro.htm LazarusNX] che ha come obbiettivo il recupero di hardware obsoleto specialmente nelle scuole italiane,creazione di reti didattiche e laboratori informatici ad alte prestazioni e costi contenuti.
''C'è una crescente sensibilità verso il reimpiego dell'hardware obsoleto, del suo riutilizzo con finalità sociali, accademiche ma anche di business - si legge in una nota - Immaginiamo una scuola (ma potrebbe essere una qualsiasi organizzazione statale o privata) che abbia un parco computer obsoleto. Con Lazarus-NX queste macchine possono essere riutilizzate su piattaforma Open Source, svincolando l'organizzazione anche dalle spese di licenza tipiche del software proprietario.'' -->


== Link ==
== Link ==
Riga 140: Riga 101:


{{Autori
{{Autori
|Autore = [[Utente:HAL 9000|HAL 9000]] 16:36, 5 dic 2015 (CET) <br/>(guida originariamente scritta da [[Utente:MaXeR|MaXeR]])
|Autore = [[Utente:HAL 9000|HAL 9000]] 15:39, 12 dic 2015 (CET) <br/>(guida originariamente scritta da [[Utente:MaXeR|MaXeR]])
|Estesa_da =
|Verificata_da =
|Numero_revisori = 0
}}
}}


[[Categoria:Xorg]][[Categoria:Altri servizi di rete]]
[[Categoria:Xorg]][[Categoria:Altri servizi di rete]]
3 581

contributi