Manovrare X da remoto: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
m (verificata)
 
(27 versioni intermedie di 7 utenti non mostrate)
Riga 1: Riga 1:
=Premessa=
{{Versioni compatibili|Jessie|Stretch|Buster}}
A volte si ha la necessit� o il desiderio di poter sfruttare un kernel della serie 2.6.x sulla versione Woody (la stable al momento in cui scrivo).
== Introduzione ==
Niente di pi� facile usando i backports!
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.


=Preparare il sistema=
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 (<code>xdm</code>, <code>gdm</code>, <code>kdm</code>, <code>lightdm</code>, ecc...) per accedere al server X locale attraverso ''XDMCP'' ('''''X''' '''D'''isplay '''M'''anager '''C'''ontrol '''P'''rotocol'').
Editiamo il nostro '''/etc/apt/sources.list''' e aggingiamo la riga:
<pre>deb http://www.backports.org/debian woody kernel-2.6</pre>
che mette a disposizioni i nuovi pacchetti '''modutils''', '''module-init-tools''' e '''sysfsutils'''.


=Scegliere il kernel=
Per semplicità di configurazione, e per la stabilità dimostrata attraverso i passaggi di versione di Debian, in questa guida si considera unicamente '''<code>xdm</code>'''.
A questo punto � necessario indicare esplicitamente nel sources.list il pacchetto che vogliamo utilizzare per il nuovo kernel. Questo pu� essere l' immagine di un kernel o i sorgenti di un kernel debianizzato a scelta tra quelli disponibili nei [http://www.backports.org/debian/dists/stable Backports]
e costruendo una riga del sources.list cos� fatta:
<pre>deb http://www.backports.org/debian woody nome_directory</pre>


=Installazione=
{{Warningbox | Ogni comunicazione da e verso il server X avverrebbe in chiaro, e sarebbe pertanto manipolabile e/o ascoltabile sulla rete. '''Questo rappresenta un <u>enorme rischio</u> per la sicurezza del sistema!'''
A questo punto sono sufficienti i classici:
<pre># apt-get update
# apt-get upgrade</pre>
per poter sfruttare la nuova serie di kernels.


{{box|Nota Bene:|In alternativa ai kernels debianizzati disponibili su Backports.org, � anche possibile utilizzare i sorgenti ufficiali 'vanilla', a patto di aver seguito il punto "'''Preparare il sistema'''"}}
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.}}


=Conclusioni=
== Lato server ==
Solo una piccola precisazione per finire: alcuni programmi/demoni/tools installati sul sistema potrebbero mostrare anomalie, una volta installato un kernel della serie 2.6.x: questo perch� fanno ricorso a funzioni non pi� disponibili o disponibili sotto nomi diversi rispetto ai kernels 2.4.x. Chi scrive ha ad esempio notato questo comportamento nei pacchetti "snmp" e "snmpd".<br>
=== Installazione ===
In questa situazione si deve disinstallare il pacchetto "ribelle" e provveredere ad installarne la versione aggiornata sfruttando i backports (se disponibili), i sorgenti aggiornati o un repository debian alternativo.
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]] basta:
<pre>
# apt install xdm xorg
</pre>


Happy hacking!
=== 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]]:
Autore: [[User:Keltik|Keltik]]
<pre>
# nano /etc/X11/xdm/xdm-config
</pre>
 
In <code>/etc/X11/xdm/xdm-config</code> commenta:
<pre>
DisplayManager.requestPort:  0
</pre>
che diventa:
<pre>
!DisplayManager.requestPort:  0
</pre>
 
Salva il file (con <code>nano</code> premi <code>Ctrl-o</code> e per uscire <code>Ctrl-x</code>).
 
In modo analogo, apri il file <code>/etc/X11/xdm/Xaccess</code> e togli il comento a:
<pre>
#*        #any host can get a login window
</pre>
che diventerà:
<pre> 
*        #any host can get a login window
</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>
192.168.0.*
</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>
:0 local /usr/bin/X :0 vt8 -nolisten tcp
</pre>
che diventerà:
<pre>
:0 local /usr/bin/X :0 vt8
</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>
# service xdm restart
</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>
# apt install xorg
</pre>
 
=== Utilizzo ===
Se l'indirizzo IP del server è <code>192.168.0.2</code>, dal client sarà sufficiente il comando:
<pre>
# X -query 192.168.0.2 :0 vt8
</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>
# X -broadcast :0 vt8
</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.
 
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.
 
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 né alcun tipo di funzionalità "trasmetto solo cosa è cambiato".
 
== Link ==
<!-- link commentato: * [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]
 
{{Autori
|Autore = [[Utente:HAL 9000|HAL 9000]] 17:50, 8 set 2019 (CEST) <br/>(guida originariamente scritta da [[Utente:MaXeR|MaXeR]])
|Estesa_da =
|Verificata_da =
|Numero_revisori = 0
}}
 
[[Categoria:Xorg]][[Categoria:Altri servizi di rete]]

Versione attuale delle 15:50, 8 set 2019

Debian-swirl.png Versioni Compatibili

Debian 8 "jessie"
Debian 9 "stretch"
Debian 10 "buster"

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.

Warning.png 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 basta:

# apt 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 con Ctrl-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.

Warning.png 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 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.

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

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 né alcun tipo di funzionalità "trasmetto solo cosa è cambiato".

Link




Guida scritta da: HAL 9000 17:50, 8 set 2019 (CEST)
(guida originariamente scritta da MaXeR)
Swirl-auth20.png Debianized 20%
Estesa da:
Verificata da:

Verificare ed estendere la guida | Cos'è una guida Debianized