Newsgroup: it.comp.os.linux.sys
Titolo: $DISPLAY e ssh su diverse sessioni grafiche

Ciao a tutti,
nella mia piccola lan casalinga spesso mi capita di accedere da un pc 
all'altro tramite ssh, e di voler pure lanciare applicazioni grafiche.
I server X sono configurati per consentire connessioni tcp solo ai pc 
della mia lan con uno script che lancia:
/usr/bin/xhost + 192.168.0.
mentre dai client mi collego sempre con l'opzione -X di ssh.
Per impostare la variabile $DISPLAY sui client ho utilizzato due altre 
variabili già presenti sulla mia Debian Squeeze, che sono
SSH_CLIENT (indica l'indirizzo IP da cui parte una sessione, ed esiste 
solo se e' attiva una sessione ssh);
WINDOWPATH (e' settata a 7 con una sola sessione grafica, per diventare 8 
avviandone una nuova con startx -- :1)
Cosi' in /etc/bash.bashrc ho inserito:
let WHERE_WE_ARE=$WINDOWPATH-7
export DISPLAY=`echo ${SSH_CLIENT} | cut -d ' ' -f '1'`:$WHERE_WE_ARE.0
Il problema e' che la variabile $WINDOWPATH esiste solo nell'ambiente 
bash "normale" e non nelle sessioni ssh, cosi' mi ritrovo con una 
variabile $DISPLAY settata a -7:0.
Senza la parte relativa a $WINDOWPATH tutto funziona egregiamente, ma da 
una eventuale seconda sessione grafica (startx -- :1) mi ritrovo con 
$DISPLAY settata sempre a 0:0 e le applicazioni grafiche mi mandano il 
loro output sulla prima sessione grafica...
Qualcuno avrebbe qualche consiglio da darmi?
Grazie in anticipo a chi mi aiuta.
-- 
toglimi....@toglimi.quipo.it
ANTI-SPAM: please cut "toglimi." for my real e-mail address.
p8400 Core2, Linux 2.6.35.2-1-x86_64, Debian GNU/Linux squeeze/sid
Registered Linux user #291116 
http://counter.li.org

 aiuta.
man ssh (come al solito, direi)
If the ForwardX11 variable is set to “yes” (or see the description of the 
-X, -x, and -Y options above) and the user is using X11 (the DISPLAY 
environment variable is set), the connection to the X11 display is 
automatically forwarded to the remote side in such a way that any X11 
programs started from the shell (or command) will go through the 
encrypted channel, and the connection to the real X server will be made 
from the local machine.  
*** The user should not manually set DISPLAY. *** <------------------
Forwarding of X11 connections can be configured on the command line or in 
configuration files.
------------- TEST 1
/tmp$ ssh -X 
ro...@10.10.10.240
Last login: Wed Sep  8 19:18:59 2010 from 10.10.10.101
sviluppo:~# echo $DISPLAY
sviluppo:~# 
------------- TEST 2
/tmp$ ssh -X 
ro...@10.10.10.240
Last login: Wed Sep  8 19:19:03 2010 from 10.10.10.101
sviluppo:~# echo $DISPLAY
localhost:10.0
sviluppo:~# 
------------- CONCLUSIONE
Perchè non utilizzi la variabile DISPLAY che ssh imposta per te e di cui 
fa già il tunnelling ??
Perchè prima non ti leggi il manuale visto che è tutto documentato ?

 Perchè prima non ti leggi il manuale visto che è tutto documentato ?
Quanto sopra forse dimostra che non avresti dovuto trarre queste facili 
conclusioni, ma apprezzo comunque il tuo aiuto e ti ringrazio per aver 
risposto.
Forse pero' qualcuno potrebbe dirmi di pretendere un po' troppo nel voler 
fare funzionare proprio *tutto* in *tutte* le possibili combinazioni...
Io ci provo, e' per questo che ho postato, se si puo' bene, altrimenti 
pazienza.
-- 
toglimi....@toglimi.quipo.it
ANTI-SPAM: please cut "toglimi." for my real e-mail address.
Core2 E8400 3.00GHz, Linux 2.6.35.4-1-x86_64, Debian GNU/Linux squeeze/sid


 
beh, mi pare ovvio.
Toglimi una curiosità: hai mai provato a fare "echo $DISPLAY" dopo
essere entrato con "ssh -X" ?
non hai mai notato un "localhost:10.0", o giù di lì?
-- 
Wikipedia Admin: "wikipedia non è un blog"
Iosif Stalin: "i compagni hanno scambiato il partito per un circolo di
discussione"

 non hai mai notato un "localhost:10.0", o giù di lì?
Certamente.
Questa e' la variabile $DISPLAY correttamente impostata da ssh -X, che 
pero' viene sovrascritta da quella impostata nei file di inizializzazione 
della shell.
Non a caso la pagina man di ssh, come giustamente evidenziato anche da 
CtRiX, dice di *non* impostare la variabile $DISPLAY.
Ma il pc non viene usato esclusivamente per connessioni ssh, e dovrebbe 
esserci la possibilita' di lanciare applicazioni grafiche dai terminali. 
Applicazioni che richiedono la variabile $DISPLAY, e senza di essa non 
sanno dove inviare il loro output.
Spero di essere riuscito ad esporre il problema...
-- 
hamr...@toglimi.quipo.it
ANTI-SPAM: please cut "toglimi." for my real e-mail address.
AMD Athlon64 3200+ Linux 2.6.32-5-amd64 on Debian GNU/Linux squeeze/sid


 della mia lan con uno script che lancia: /usr/bin/xhost + 192.168.0.
Come ti hanno gia' detto, se ti colleghi tramite ssh -X non hai bisogno 
di settare alcuna variabile DISPLAY. Io lavoro in remoto e tutte le 
applicazioni grafiche mi si aprono sulla macchina locale senza nessun 
problema (a parte eventuale lentezza della linea)
Di default sulla macchina a cui mi collego il DISPLAY viene messo a
localhost:10.0
Ricordo che avevo questi problemi quando lavoravo su delle macchine Alpha 
della DIGITAL: in quel caso dovevo settare i vari DISPLAY, ma si parla di 
15 anni fa...
Ciao, Mauro

 sanno dove inviare il loro output.
allora ti sei spiegato veramente male.

 allora ti sei spiegato veramente male.
Riassumendo:
premesso che i ruoli di client e server devono essere tra loro 
intercambiabili, dato che si deve poter accedere da una postazione 
all'altra indifferentemente, alla luce di quanto gia' scritto nei 
precedenti post si verificano le seguenti due situazioni:
1)- se $DISPLAY e' impostata le applicazioni grafiche funzionano 
localmente ma collegandomi a questo pc via ssh le applicazioni grafiche 
non posso lanciarle;
2)- se $DISPLAY non e' impostata le applicazioni grafiche non funzionano 
localmente pero' posso lanciarle da una sessione ssh remota.
Piu' chiaro di cosi' non potrei essere...
-- 
toglimi....@toglimi.quipo.it
ANTI-SPAM: please cut "toglimi." for my real e-mail address.
p8400 Core2, Linux 2.6.35.2-1-x86_64, Debian GNU/Linux squeeze/sid


 localmente pero' posso lanciarle da una sessione ssh remota.
Hai provato a NON dare xhost e a NON impostare DISPLAY? Se cosi' funziona 
tutto, puoi gestire le autirizzazioni di accesso via firewall.
Mauro

 localmente pero' posso lanciarle da una sessione ssh remota.
Forse dico la cazzata di oggi, ma fammi vedere se ho capito bene.
L'utente pippo si siede alla macchina A, apre una sessione in locale e
lancia i suoi programmi, aspettandosi di vederli sul display locale.
Contemporaneamente, l'utente pluto si siede alla macchina B, si
collega ad A con "ssh -X" e lancia (su A) i suoi programmi, aspettando
di vederli sul display di B, che è remoto ad A.
Per quanto ne so io non c'è alcun bisogno di configurare niente: nel
primo caso l'utente pippo accede al display :0 di A, quindi per lui la
variabile DISPLAY vale :0.0 ; l'utente pluto si collega da remoto,
quindi per lui (su A) la variabile DISPLAY vale localhost:10.0 (o quel
che è, il valore 10 è configurabile). Se poi altri utenti si collegano
da remoto, da B o altre stazioni, A assegnerà loro ulteriori display
virtuali.
Per quanto ne so io la possibità di cambiare il "Display Offset" serve
per consentire l'uso di più display virtuali qualora A avesse più
terminali.
Se ho capito bene e la tua situazione corrisponde a quanto ho
descritto sopra, a mio parere non hai bisogno di alcuna
configurazione; anche il discorso relativo alla limitazione
dell'accesso ad X11 agli indirizzi della tua LAN viene a cadere, dato
che in realtà ciascun nodo (A, B ed eventuali altri) "parla X11" solo
con se' stesso (localhost), mentre tutti gli scambi tra un nodo e
l'altro avvengono via ssh.
C'ho azzeccato oppure ho detto la minchiata del giorno?
Manuel

 di vederli sul display di B, che è remoto ad A.
non c'è niente da configurare perché ci pensa il sistema a configurare 
opportunamente le variabili d'ambiente, e quando parte la sessione X11 
setta pure quella alla login shell.
Stesa cosa fa' il demone SSHd quando arriva la connessione remota 
d'accesso (e c'è il X11Forwarding attivo..)
non avrà bisogno di alcuna configurazione ... ma forse gli mancano delle 
utility di contorno, tipo xauth, etc...
