1 |
On Thu, Jun 23, 2011 at 11:31:29AM -0700, Mark Knecht wrote: |
2 |
> On Thu, Jun 23, 2011 at 10:39 AM, YoYo Siska <yoyo@××××××.sk> wrote: |
3 |
> > On Thu, Jun 23, 2011 at 05:21:07PM +0100, Neil Bothwick wrote: |
4 |
> >> On Thu, 23 Jun 2011 08:54:01 -0700, Mark Knecht wrote: |
5 |
> >> |
6 |
> >> > My question is about running nvidia-settings. I'm finding that if I |
7 |
> >> > shell into his machine using |
8 |
> >> > |
9 |
> >> > ssh -X -Y -C IP-address |
10 |
> >> > |
11 |
> >> > and run nvidia-settings I get it displayed here, as it should be. The |
12 |
> >> > problem is it is seeing my GTX 465 and not his 8400GS. |
13 |
> >> |
14 |
> >> Looking at the man page, it appears you need to use the -ctrl-display |
15 |
> >> parameter or the $DISPLAY env var. The man page mentions that |
16 |
> >> nvidia-settings queries the X server, which is running locally. It looks |
17 |
> >> like this setting may force it to use another. |
18 |
> > |
19 |
> > |
20 |
> > as neil wrote, it is |
21 |
> > nvidia-settings -c :0 |
22 |
> > |
23 |
> > nvidia-settings connects to the remote xserver to communicate |
24 |
> > with the graphics card (through a special nvidia xtenstion to the x |
25 |
> > protocol), so you need to be able to access the remote xserver, if you |
26 |
> > are logged in as the user running the xserver, you should be ok |
27 |
> > |
28 |
> > yoy |
29 |
> |
30 |
> Yeah, I've been tripping over doing this right since Neil pointed me |
31 |
> toward the -c command. I think the problem is that I don't have the |
32 |
> permissions set correctly to allow this to work right. The owner of |
33 |
> the remote machine is logged in and possibly using X. I'm not sure |
34 |
> about that but I'm not 'running the X server' in any meaningful way. |
35 |
> I'm just remotely trying to access his GPU with nvidia-settings but |
36 |
> display the GUI here. The problem seems to be getting the right number |
37 |
> of his server or else permissions. |
38 |
> |
39 |
> This page is one of the better ones I've found about running |
40 |
> nvidia-settings remotely, specifically section 6 which gives this |
41 |
> example: |
42 |
> http://www.makelinux.com/man/1/A/alt-nvidia-173-settings |
43 |
> |
44 |
> (issued from bartok.nvidia.com) |
45 |
> xhost +stravinsky.nvidia.com |
46 |
> |
47 |
> (issued from schoenberg.nvidia.com) |
48 |
> xhost +stravinsky.nvidia.com |
49 |
> |
50 |
> nvidia-settings --display=bartok.nvidia.com:0 |
51 |
> --ctrl-display=schoenberg.nvidia.com:0 |
52 |
> |
53 |
> which "allows all X clients run on stravinsky.nvidia.com to connect |
54 |
> and display on bartok.nvidia.com's X server and configure |
55 |
> schoenberg.nvidia.com's X server." |
56 |
|
57 |
|
58 |
this seems pretty old... defaults on most distros these days are that X |
59 |
server does not listen on tcp/ip (ip-address:0) only on a local unix sockets |
60 |
(:0), see below for more |
61 |
|
62 |
> |
63 |
> It seems this program allows you to run it from machine1, display it |
64 |
> on machine2 which controlling machine3? |
65 |
> |
66 |
> So, locally I ran |
67 |
> |
68 |
> mark@c2stable ~ $ xhost |
69 |
> access control enabled, only authorized clients can connect |
70 |
> mark@c2stable ~ $ xhost +DWP-Linux |
71 |
> DWP-Linux being added to access control list |
72 |
> mark@c2stable ~ $ xhost |
73 |
> access control enabled, only authorized clients can connect |
74 |
> INET:DWP-Linux |
75 |
> mark@c2stable ~ $ |
76 |
> |
77 |
> which I think allows the remote machine access here in my server. I |
78 |
> then log in which creates the .Xauthority file: |
79 |
> |
80 |
> mark@c2stable ~ $ ssh -XYC DWP-Linux |
81 |
> Password: |
82 |
> Last login: Thu Jun 23 14:11:33 EDT 2011 from |
83 |
> c-67-161-57-1.hsd1.ca.comcast.net on pts/3 |
84 |
> /usr/bin/xauth: file /home/mark/.Xauthority does not exist |
85 |
> mark@DWP-Linux ~ $ ls -al .Xauthority |
86 |
> -rw------- 1 mark mark 55 Jun 23 14:21 .Xauthority |
87 |
> mark@DWP-Linux ~ $ cat .Xauthority |
88 |
> DWP-Linux11MIT-MAGIC-COOKIE-1��:��T'6�@R��mark@DWP-Linux ~ $ |
89 |
> mark@DWP-Linux ~ $ |
90 |
> |
91 |
> On that machine I see this $DISPLAY: |
92 |
> |
93 |
> mark@DWP-Linux ~ $ echo $DISPLAY |
94 |
> localhost:11.0 |
95 |
> mark@DWP-Linux ~ $ |
96 |
> |
97 |
> so I run |
98 |
> |
99 |
> mark@DWP-Linux ~ $ nvidia-settings -c :11 |
100 |
> |
101 |
> which sees my GPU, not his, presumably because I said to control my |
102 |
> system with -c :11. However if I try something like |
103 |
> |
104 |
> mark@DWP-Linux ~ $ nvidia-settings -c :0 |
105 |
> |
106 |
> I get a bunch of stuff ending with |
107 |
> |
108 |
> |
109 |
> ERROR: Unable to assign attribute XVideoSyncToDisplay specified on |
110 |
> line 62 of configuration file |
111 |
> '/home/mark/.nvidia-settings-rc' (no Display connection). |
112 |
> |
113 |
> No protocol specified |
114 |
> |
115 |
> ERROR: Cannot open display ':0'. |
116 |
> |
117 |
> mark@DWP-Linux ~ $ |
118 |
> |
119 |
> I'm a bit lost at this point. (OBVIOUSLY!) :-) |
120 |
|
121 |
|
122 |
To connect to an Xserver, you need to know its "address", which is |
123 |
something like machine_or_ip:NUMNER for tcp/ip connection or just |
124 |
:NUMBER for (local) unix socket connection. |
125 |
|
126 |
When you do a ssh -X , ssh creates a tunnel from the remote computer to |
127 |
your local Xserver (:0 at your side), and creates a new "address", |
128 |
usually localhost:10 (or 11, 12, which on is free) |
129 |
|
130 |
if i'm behing a laptop named 'tabletka' and there is also a desktop |
131 |
named 'yoyo' (its the same as my username... on both), you could do: |
132 |
|
133 |
yoyo@tabletka ~ $ DISPLAY=:0 xterm |
134 |
which runs xterm here (tabletka), displays it here |
135 |
|
136 |
yoyo@tabletka ~ $ DISPLAY=yoyo:0 xterm |
137 |
runs xterm here, displays it on yoyo |
138 |
|
139 |
however as i said, most distributions don't allow Xservers to listen on |
140 |
tcp/ip and only allow it to listen on local sockets... you can however |
141 |
use ssh to tunnel X traffic, so you could do: |
142 |
|
143 |
yoyo@tabletka ~ $ echo $DISPLAY |
144 |
:0.0 |
145 |
yoyo@tabletka ~ $ ssh -X yoyo |
146 |
yoyo@yoyo:~$ echo $DISPLAY |
147 |
localhost:10.0 |
148 |
|
149 |
|
150 |
|
151 |
now if you run an X application, it would connect to localhost:10.0 |
152 |
which would be transfere by ssh to your local :0.0 (on tabletka) |
153 |
|
154 |
but you could also do (still in the ssh session) |
155 |
yoyo@yoyo:~$ DISPLAY=:0.0 xterm |
156 |
|
157 |
which would run xterm on the xserver on that remote desktop computer... |
158 |
|
159 |
(note that apps use the DISPLAY variable, but usually also have a |
160 |
command line option to specify the Xserver on which they should display |
161 |
things, that is the --display option from nvidia-settings) |
162 |
|
163 |
|
164 |
however the example above most probably won't work, because the Xserver |
165 |
uses authentication to only allow authorized clients/applications to |
166 |
display things on it... the xhost commands in the example you found |
167 |
basically allow access to all applications from a certain ip, but this |
168 |
only works for the tcp/ip connections, which are not used... |
169 |
|
170 |
Xserver uses xauth "cookies" to authenticate a user... so if you can get |
171 |
a hold a "cookie" for that remote Xserver, you can connect to it / |
172 |
control it. If a user is logged on the remote Xserver, he most probably |
173 |
has a ~/.Xauthority file in his home (or a file pointed to by |
174 |
$XAUTHORITY variable), which contains the cookie, so if |
175 |
you can read his files (it is of course only readable by him, but if |
176 |
have root on that machine...) you can run |
177 |
|
178 |
xauth merge /home/LOGGED_USER/.Xauthority |
179 |
|
180 |
of course, if you log in as that user, it is not needed... |
181 |
|
182 |
if there is no-one logged in, it is a bit more problematic, because the |
183 |
login manager takes care of the auth cookies, but for KDM the cookies |
184 |
are in /var/run/xauth/ (readable only by root), so you could either do |
185 |
|
186 |
xauth merge /var/run/xauth/* |
187 |
|
188 |
or set XAUTHORITY to the path of the file corresponding to :0 (kdm names |
189 |
them A:0-somethingrandom, so it si /var/run/xauth/A:0* ), but that might |
190 |
override any XAUTHORITY file ssh might have set up for the -X tunnel to |
191 |
your local Xserver ;) |
192 |
|
193 |
the kdm xauth cookie should work even if a user is logged in, of |
194 |
course... |
195 |
|
196 |
|
197 |
note that if you do a ssh -X othermachine, and then su in that ssh |
198 |
session, the DISPLAY and XAUTHORITY vars might get reset... |
199 |
|
200 |
|
201 |
so in short, if there is kdm on the remote machine: |
202 |
ssh -X othermachine |
203 |
(now $DISPLAY should be something like localhost:10) |
204 |
sudo chmod 644 /var/run/xauth/A:0* |
205 |
xauth merge /var/run/xauth/A:0* |
206 |
(now your xauthority file should have cookies fot both |
207 |
yor tunneled local xserver (if ssh created it) and also for |
208 |
the :0 xserver on the remote machine) |
209 |
nvidia-settings -c :0 |
210 |
(nvidia-settings uses $DISPLAY to select where to display it's ui -> |
211 |
i.e. your ssh tunel to your local display, and "controls" the graphics |
212 |
card on the :0 display) |
213 |
|
214 |
|
215 |
yoyo |