Differences

This shows you the differences between two versions of the page.

--- doc:appunti:linux:tux:remote_desktop [2017/05/31 12:46] – [X11 forward] niccolo
+++ doc:appunti:linux:tux:remote_desktop [2022/01/31 16:25] (current) – [x11vnc] niccolo
@@ Line 21: / Line 21: @@
 ===== x11vnc =====
-L'utente proprietario della sessione X lancia ''**x11vnc -display :0**'', l'utente remoto esegue ''**xvncviewer -fullscreen host:0**''. Il passaggio dalla modalità finestra a quella full-screen (F8 per attivare il pop-up), non funziona sul PC provato, bisogna partire direttamente full-screen. Sembra che sia un bug di ''**xvncviewer**'', utilizzare ''**krdc**'' al suo posto.
+Il programma **x11vnc** consente di **condividere** tramite protocollo di rete **VNC** uno **schermo X11 esistente**, cioè una **sessione già iniziata** oppure la **schermata di login** del display manager.
-Con ''x11vnc'' è possibile anche prendere possesso remoto dello schermo dove sta girando il display manager (la richiesta di login di ''kdm'', ad esempio). Bisogna anzitutto scoprire quale **//X authority file//** sta utilizzando il server X, ed utilizzarlo con ''x11vnc'':
+Sulla postazione che vuole **condividere lo schermo X11** (il server) si installa il pacchetto **x11vnc**, sul client remoto si installa un client VNC, ad esempio **xtightvncviewer** contenuto nell'omonimo pacchetto Debian (es. Debian 10 Buster).
+Esaminando il contenuto della variabile d'ambiente **DISPLAY** si determina qual'è lo schermo X11 utilizzato che si intende condividere, di solito si tratta di **:0.0**. Il primo zero indica il //display// e il secondo lo //schermo// (uno stesso display può avere più di uno schermo). L'utente **proprietario della sessione** lancia il comando (può omettere l'indicazione dello //schermo//):
+<code>
+x11vnc -display :0
+</code>
+L'utente remoto esegue invece:
+<code>
+xtightvncviewer <ip_address>:0
+</code>
+In alternativa a **xtightvncviewer** si può utilizzare **krdc**.
+Con ''x11vnc'' è possibile anche prendere possesso remoto dello schermo dove sta girando il display manager (la richiesta di login di **lightdm**, ad esempio). Ovviamente si deve avere i permessi sul file auth, cioè si dovrà essere **root**:
 <code>
-# ps uax | grep X | grep auth
+x11vnc -auth guess -display :0 -noxdamage
-root      1839  0.2  3.8 19572 9880 ?        S<   18:59   0:28 /usr/X11R6/bin/X -nolisten tcp -auth /var/run/xauth/A:0-SZUARw vt7
-x11vnc -auth /var/run/xauth/A:0-SZUARw -display :0
 </code>
-Quindi ci si connette con un client VNC alla porta opportuna (default 5900). La sessione termina al logout dell'utente. Ulteriori dettagli in [[http://www.karlrunge.com/x11vnc/|x11vnc: a VNC server for real X displays]].
+Il parametro **guess** tenta di indovinare automaticamente qual'è l'**X authority file** che sta utilizzando il server Xorg. Se l'operazione guess dovesse fallire è possibile scoprirlo vedendo il processo Xorg in esecuzione (nell'esempio sotto si tratta del file **/var/run/lightdm/root/:0**):
-Anche ''x11vnc'' supporta il viewer Java tramite http, dopo aver installato il pacchetto **vnc-java** si esegue ''x11vnc'' con la sintassi:
+Il parametro **-noxdamage** disabilita una estensione del protocollo che dovrebbe ottimizzare la ritrasmissione solo delle porzioni dello schermo che cambiano, purtroppo nel nostro caso (Debian 11) causava continui problemi di tipo **caught XIO error**.
 <code>
-x11vnc -httpdir /usr/share/vnc-java
+ps uax | grep Xorg | grep auth
+... /usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
 </code>
@@ Line 139: / Line 154: @@
 Quando da un client si lancia ssh si può specificare su riga di comando che vogliamo il forward di X11, con l'opzione ''**-X**'', altrimenti viene consultato il file ''**/etc/ssh/ssh_config**'', qui l'opzione ForwardX11 puo' essere impostata a yes per nessuno, per tutti o solo per specifici host.
-Si potrebbe incappare nell'errore:
+Si potrebbe incappare nell'**errore**:
 <code>
@@ Line 145: / Line 160: @@
 </code>
-mostrato subito dopo il login sull'host remoto. Potrebbe essere causato dal tentativo di utilizzare IPv6 da parte di **sshd**. In questo caso una soluzione è restringere sshd all'uso di IPv4, impostando in /etc/ssh/sshd_config
+mostrato subito dopo il login sull'host remoto. Potrebbe essere causato dal tentativo di utilizzare **IPv6** da parte di **sshd**. In questo caso una soluzione è restringere sshd all'uso di IPv4, impostando in /etc/ssh/sshd_config
 <file>