Manovrare X da remoto: differenze tra le versioni
(configurazione lato server e utilizzo lato client (lanciando X direttamente)) |
|||
| Riga 11: | Riga 11: | ||
Se è possibile, si raccomanda caldamente invece di configurare una connessione [[SSH]] e di abilitare l'[[OpenSSH: X11 forwarding|X11 forwarding]] per avviare un'applicazione grafica o anche un'intera sessione.}} | Se è possibile, si raccomanda caldamente invece di configurare una connessione [[SSH]] e di abilitare l'[[OpenSSH: X11 forwarding|X11 forwarding]] per avviare un'applicazione grafica o anche un'intera sessione.}} | ||
== Installazione == | == Lato server == | ||
Con [[privilegi di amministrazione]] è necessario installare <code>xdm</code>, se ancora non presente. Per esempio con [[apt-get]] basta: | === Installazione === | ||
Con [[privilegi di amministrazione]] è necessario installare <code>xdm</code>, oltre ovviamente al server [[Xorg]], se ancora non presente nella macchina che farà da server. Per esempio con [[apt-get]] basta: | |||
<pre> | <pre> | ||
# apt-get install xdm | # apt-get install xdm xorg | ||
</pre> | </pre> | ||
== Configurazione di xdm == | === Configurazione di xdm === | ||
Sempre con [[privilegi di amministrazione]], è sufficiente modificare i file di configurazione indicati in questa sezione con un editor di testo, per esempio [[nano]]: | |||
<pre> | <pre> | ||
# nano /etc/X11/xdm/xdm-config | # nano /etc/X11/xdm/xdm-config | ||
| Riga 42: | Riga 43: | ||
* #any host can get a login window | * #any host can get a login window | ||
</pre> | </pre> | ||
Al posto di <code>*</code> è possibile anche specificare, uno a uno, gli [[host]] da cui si intende accettare la connessione, anche con uso di pattern. Per esempio basta scrivere (al posto di <code>*</code>): | |||
<pre> | <pre> | ||
192.168.0.* | |||
</pre> | </pre> | ||
per accettare connessioni dagli host appartenenti alla rete <code>192.168.0.0/24</code>, ossia tutti gli indirizzi compresi da <code>192.168.0.1</code> a <code>192.168.0.254</code>. Sono permessi anche [[hostname]], per esempio se definiti in <code>/etc/hosts</code>, e l'uso di indirizzi multicast a cui limitare l'ascolto. Per maggiori informazioni si consultino gli esempi scritti nel file. | |||
Per finire è necessario specificare di restare in ascolto sulla porta TCP, modificando il file <code>/etc/X11/xdm/Xservers</code>: | |||
<pre> | <pre> | ||
:0 local /usr/bin/X :0 vt8 -nolisten tcp | |||
</pre> | </pre> | ||
che diventerà: | |||
<pre> | <pre> | ||
:0 local /usr/bin/X :0 vt8 | |||
</pre> | </pre> | ||
dove: | |||
* '''<code>:0</code>''' è l'identificativo del server X che sarà avviato e dev'essere libero; se ce n'è già uno in esecuzione, utilizzarne un altro (<code>:1</code>, <code>:2</code>, ecc...); | |||
* '''vt8''' è il terminale virtuale da utilizzare, in questo caso <code>tty8</code> (accessibile con <code>Ctrl-Alt-F8</code>). Sceglierne uno qualsiasi libero (<code>vt9</code>, <code>vt10</code>, ecc...). | |||
È possibile anche specificare più linee, se si intendono avviare più server X simultaneamente. In tal caso è consigliabile lasciare l'opzione '''<code>-nolisten tcp</code>''' su quelli per cui non è previsto l'accesso remoto, come misura di sicurezza. | |||
{{Warningbox | Si ricorda nuovamente che, anche se l'accesso deve essere autenticato, la comunicazione non è criptata. Per cui chiunque nella rete potrebbe ascoltare le credenziali di accesso e il suo uso è '''altamente sconsigliato''' al di fuori della LAN, e anche in questo caso esclusivamente se tutti gli host e gli utenti connessi alla LAN possono sempre essere considerati fidati.}} | |||
Per rendere effettive le modifiche, è necessario riavviare il display manager: | |||
<pre> | <pre> | ||
# service xdm restart | |||
</pre> | </pre> | ||
e questo conclude la configurazione lato server. <code>xdm</code> resterà in ascolto sulla porta 177 del protocollo UDP per ricevere richieste di autenticazione, secondo il protocollo XDMCP, dagli host specificati nel file <code>Xaccess</code>. Il server <code>Xorg</code> resta invece in ascolto sulla porta 6000 del protocollo TCP e successive, in base al display utilizzato, e permetterà l'accesso soltanto previa autenticazione, di default in base alla conoscenza di una sequenza casuale generata in precedenza: il ''magic cookie'' (per maggiori informazioni si rimanda alla lettura del manuale di <code>xauth</code>), comunicato da <code>xdm</code> per permettere l'autenticazione. | |||
== Lato client == | |||
=== Installazione === | |||
È necessario il solo pacchetto <code>xorg</code>, per cui se non fosse installato, con [[privilegi di amministrazione]]: | |||
<pre> | <pre> | ||
# apt-get install xorg | |||
</pre> | </pre> | ||
=== Utilizzo === | |||
Se l'indirizzo IP del server è <code>192.168.0.2</code>, dal client sarà sufficiente il comando: | |||
<pre> | <pre> | ||
# X -query 192.168.0.2 :0 vt8 | |||
</pre> | </pre> | ||
per connettersi a <code>xdm</code> sulla macchina server. Si noti che il display e il terminale virtuale non devono combaciare per forza con quelli scelti sul server, l'unica cosa importante è che siano entrambi liberi sul client, in maniera analoga a quanto visto in precedenza per il server. | |||
In alternativa, se si è nella stessa rete locale del server, è anche possibile: | |||
<pre> | <pre> | ||
# X -broadcast :0 vt8 | |||
</pre> | </pre> | ||
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. | |||
== Altro == | |||
TODO: da sistemare (per ora commentato) | |||
Riguardo la sicurezza il protocollo X è | <!-- | ||
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 | * 6000 per il display :0 | ||
| Riga 133: | Riga 133: | ||
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. | 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.'' | ''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 == | ||
* [http://www.freesoftwaremagazine.com/articles/what_is_x/ What is X?]: | * [http://www.freesoftwaremagazine.com/articles/what_is_x/ What is X?]: interessante articolo che parte dalle basi del funzionamento fino agli utilizzi più avanzati del server X in remoto; | ||
* [http://www.tldp.org/HOWTO/XDMCP-HOWTO Linux XDMCP HOWTO] | * [http://www.tldp.org/HOWTO/XDMCP-HOWTO Linux XDMCP HOWTO] | ||
[[Categoria:Xorg]] | [[Categoria:Xorg]] | ||
Versione delle 15:20, 5 dic 2015
Guida adottata da HAL 9000 
|
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.
Le richieste dai client X di gestire le finestre avvengono di solito localmente, ma nulla impedisce di gestire le finestre attraverso la rete, permettendo a utenti remoti di effettuare il login sul display manager (xdm, gdm, kdm, lightdm, ecc...) per accedere al server X locale attraverso XDMCP (X Display Manager Control Protocol).
Per semplicità di configurazione, e per la stabilità dimostrata attraverso i passaggi di versione di Debian, in questa guida si considera unicamente xdm.
|
ATTENZIONE Ogni comunicazione da e verso il server X avverrebbe in chiaro, e sarebbe pertanto manipolabile e/o ascoltabile sulla rete. Questo rappresenta un enorme rischio per la sicurezza del sistema! Se è possibile, si raccomanda caldamente invece di configurare una connessione SSH e di abilitare l'X11 forwarding per avviare un'applicazione grafica o anche un'intera sessione. |
Lato server
Installazione
Con privilegi di amministrazione è necessario installare xdm, oltre ovviamente al server Xorg, se ancora non presente nella macchina che farà da server. Per esempio con apt-get basta:
# apt-get install xdm xorg
Configurazione di xdm
Sempre con privilegi di amministrazione, è sufficiente modificare i file di configurazione indicati in questa sezione con un editor di testo, per esempio nano:
# nano /etc/X11/xdm/xdm-config
In /etc/X11/xdm/xdm-config commenta:
DisplayManager.requestPort: 0
che diventa:
!DisplayManager.requestPort: 0
Salva il file (con nano premi Ctrl-o e per uscire Ctrl-x).
In modo analogo, apri il file /etc/X11/xdm/Xaccess e togli il comento a:
#* #any host can get a login window
che diventerà:
* #any host can get a login window
Al posto di * è possibile anche specificare, uno a uno, gli host da cui si intende accettare la connessione, anche con uso di pattern. Per esempio basta scrivere (al posto di *):
192.168.0.*
per accettare connessioni dagli host appartenenti alla rete 192.168.0.0/24, ossia tutti gli indirizzi compresi da 192.168.0.1 a 192.168.0.254. Sono permessi anche hostname, per esempio se definiti in /etc/hosts, e l'uso di indirizzi multicast a cui limitare l'ascolto. Per maggiori informazioni si consultino gli esempi scritti nel file.
Per finire è necessario specificare di restare in ascolto sulla porta TCP, modificando il file /etc/X11/xdm/Xservers:
:0 local /usr/bin/X :0 vt8 -nolisten tcp
che diventerà:
:0 local /usr/bin/X :0 vt8
dove:
:0è l'identificativo del server X che sarà avviato e dev'essere libero; se ce n'è già uno in esecuzione, utilizzarne un altro (:1,:2, ecc...);- vt8 è il terminale virtuale da utilizzare, in questo caso
tty8(accessibile conCtrl-Alt-F8). Sceglierne uno qualsiasi libero (vt9,vt10, ecc...).
È possibile anche specificare più linee, se si intendono avviare più server X simultaneamente. In tal caso è consigliabile lasciare l'opzione -nolisten tcp su quelli per cui non è previsto l'accesso remoto, come misura di sicurezza.
|
|
ATTENZIONE Si ricorda nuovamente che, anche se l'accesso deve essere autenticato, la comunicazione non è criptata. Per cui chiunque nella rete potrebbe ascoltare le credenziali di accesso e il suo uso è altamente sconsigliato al di fuori della LAN, e anche in questo caso esclusivamente se tutti gli host e gli utenti connessi alla LAN possono sempre essere considerati fidati. |
Per rendere effettive le modifiche, è necessario riavviare il display manager:
# service xdm restart
e questo conclude la configurazione lato server. xdm resterà in ascolto sulla porta 177 del protocollo UDP per ricevere richieste di autenticazione, secondo il protocollo XDMCP, dagli host specificati nel file Xaccess. Il server Xorg resta invece in ascolto sulla porta 6000 del protocollo TCP e successive, in base al display utilizzato, e permetterà l'accesso soltanto previa autenticazione, di default in base alla conoscenza di una sequenza casuale generata in precedenza: il magic cookie (per maggiori informazioni si rimanda alla lettura del manuale di xauth), comunicato da xdm per permettere l'autenticazione.
Lato client
Installazione
È necessario il solo pacchetto xorg, per cui se non fosse installato, con privilegi di amministrazione:
# apt-get install xorg
Utilizzo
Se l'indirizzo IP del server è 192.168.0.2, dal client sarà sufficiente il comando:
# X -query 192.168.0.2 :0 vt8
per connettersi a xdm sulla macchina server. Si noti che il display e il terminale virtuale non devono combaciare per forza con quelli scelti sul server, l'unica cosa importante è che siano entrambi liberi sul client, in maniera analoga a quanto visto in precedenza per il server.
In alternativa, se si è nella stessa rete locale del server, è anche possibile:
# X -broadcast :0 vt8
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.
Altro
TODO: da sistemare (per ora commentato)
Link
- What is X?: interessante articolo che parte dalle basi del funzionamento fino agli utilizzi più avanzati del server X in remoto;
- Linux XDMCP HOWTO