marionnet-dev team mailing list archive
-
marionnet-dev team
-
Mailing list archive
-
Message #00616
Re: Marionnet in LTSP
Hi Simon,
I don't know what you could try again... I think only about a desperate
attempt, related to a strategy that I wrote in a previous mail:
> Another way, is to observe the server (xauth list) before and after
> the xdmcp connection of the client. If you observe the creation of a
> new display and cookie, it's the good one!
In other words, I would try to connect to the server (S) before starting
a thin client (C), then:
S# xauth list
Then I would launch the client (C), and repeat:
S# xauth list
to determine the display allocated by the server S in order to serve C.
At this point I assume that I know the relationship:
(client, 7) <-> (server, 42) <-> (M1, 0)
And I assume also that the DISPLAY for C is 42 and it is a *Unix
socket*. In other words, I assume that:
(client, 7, TCP) <-> (server, 42, UNIX) <-> (m1, 0, TCP)
This hypothesis may explain the failures that you describe in your messages.
So, if it is the case, we can start a process (socat, you have to
install it on the server) which convert request to TCP:42 into request
to UNIX:42
S# UNIX_SOCKET=$(netstat -a -x | grep -o "/tmp/X11-unix/X42[.]" | uniq)
S# socat TCP-LISTEN:6042,reuseaddr,fork UNIX-CLIENT:$UNIX_SOCKET &
(we create a pseudo TCP X-server listening on port 42, which is the port
addressed by virtual machines started from C). Now, I would launch
Marionnet from C, then I would launch a virtual machine "m1" with
Marionnet and I would transfer the related cookie to m1 (which address
should be 172.23.0.1):
S# ssh root@172.23.0.1 xauth add 172.23.0.254:42 . COOKIE
finally, I would try "xeyes" on m1:
m1 # export DISPLAY=172.23.0.254:42
m1 # xeyes
---
About your questions:
> a) Could the fact of not assigning IP to eth0 of VMs affect the
situation?
No, in any case. Each VM has an hidden ("ghostified") interface named
"eth42" assigned to 172.23.0.1 in a point-to-point link with host (which
has, as you imagine, the IP 172.23.0.254). We have patched the Linux
kernel in order to "ghostify" this interface (for pedagogical reasons).
> b) Does the fact of having $DISPLAY set to 168.18.104.251:7
> <http://168..18.104.251:7> on the thin client leads to the need of
> using 172.23.0.254:7 <http://172.23.0.254:7> but not 172.23.0.254:0
> <http://172.23.0.254:0> on Marionnet's VMs?
It's not clear because there are three actors C,S and VM, and the type
of the S socket may be not of the family INET, but Unix. I can only
answer that if the VM has the variable DISPLAY set to 172.23.0.254:N,
the server must have an corresponding server (daemon) listening on TCP
port 6000+N.
> c) I cannot identify IP of VMs which is associated to tunnel where
> 172.23.0.254 is on the other side, since "ifconfig -a" (ran on the
VM) is of no help. Once you've mentioned that I can ssh to M1 by means
> of using 172.23.0.1 and I successfully did this. I also tried to
> reach M2 via 172.23.0.2 and it also worked. So my question: what is
> the common rule to identify IP address of VMs including ones with
> multiple NICs, i.e. routers?
With:
S# route
you can see the point-to-point links to active but "ghostified"
interfaces on VMs.
Hope this helps,
Jean-Vincent
Le 09/04/2013 19:23, Simon Baev a écrit :
Hi Jean-Vincent,
I tried the following approach.
1. I removed ".Xauthirity" file from within my home directory on the
LTSP server and rebooted it.
2. I tried to login on the server console (without starting any tin
terminal) and straight on the thin terminal (without activating server
console). Result is the same: I can see 4 cookies in the output of
"xauth list" and it doesn't mater where I run this command (server
console or thin terminal):
simon.baev@LTSP2:~$ xauth list
LTSP2/unix:0 MIT-MAGIC-COOKIE-1 d6483431acf10388c44ec0f31ae54071
LTSP2/unix:10 MIT-MAGIC-COOKIE-1 11e1f1670e4ff8a9f175d697b0d33c00
168.18.104.251:7 <http://168.18.104.251:7> MIT-MAGIC-COOKIE-1
8fac737e10facea29739b8f668eb9ec0
LTSP2/unix:11 MIT-MAGIC-COOKIE-1 11e1f1670e4ff8a9f175d697b0d33c00
PS: I observed that 2nd and 4th cookies are the same which I don't
understand.
3. In any case there is a :0 cookie which for some reason is no longer
"good" as I cannot use it to display "xeyes" on the server console. I
tried exact same approach as in Step 4 (from the previous email) but it
didn't work. I suspect that this could happen because I did my
experiment while running Marionnet from a thin client while having no
login session on the server console. But unfortunately, logging in on
the server console doesn't fix the problem, so I got the following
-----------------8<----------
m3:~# echo $DISPLAY
172.23..0.254:0 <http://172.23.0.254:0>
m3:~# rm .Xauthority
rm: remove regular file `.Xauthority'? y
m3:~# xauth list
xauth: creating new authority file /root/.Xauthority
m3:~# xauth add $DISPLAY . d6483431acf10388c44ec0f31ae54071
xauth: creating new authority file /root/.Xauthority
m3:~# xauth list
172.23.0.254:0 <http://172.23.0.254:0> MIT-MAGIC-COOKIE-1
d6483431acf10388c44ec0f31ae54071
m3:~# xeyes
Xlib: connection to "172.23.0.254:0.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
Error: Can't open display: 172.23.0.254:0 <http://172.23.0.254:0>
m3:~#
-----------------8<----------
Would it be a requirement to re-login after removing and re-creating
.Xauthority?
4. Having disappointed with the fact of non-working Step 4 (in my
previous email) I tried to use all other cookies from listing in Step 2
but none of them worked. For example, using :10 results in
-----------------8<----------
m1:~# xauth add $DISPLAY . 11e1f1670e4ff8a9f175d697b0d33c00
xauth: creating new authority file /root/.Xauthority
m1:~# xauth list
172.23.0.254:0 <http://172.23.0.254:0> MIT-MAGIC-COOKIE-1
11e1f1670e4ff8a9f175d697b0d33c00
m1:~# xeyes
Xlib: connection to "172.23.0.254:0.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
Error: Can't open display: 172.23.0.254:0 <http://172.23.0.254:0>
-----------------8<----------
Same for :11. When re-defined and exported DISPLAY=172.23.0.254:7
<http://172.23.0.254:7> with :0, :10, and 168.18.104.251:7
<http://168.18.104.251:7> I had he following error message:
-----------------8<----------
m1:~# xeyes
Error: Can't open display: 172.23.0.254:0 <http://172.23.0.254:0>
m1:~#
-----------------8<----------
I have some other doubts/questions:
a) Could the fact of not assigning IP to eth0 of VMs affect the situation?
b) Does the fact of having $DISPLAY set to 168.18.104.251:7
<http://168..18.104.251:7> on the thin client leads to the need of using
172.23.0.254:7 <http://172.23.0.254:7> but not 172.23.0.254:0
<http://172.23.0.254:0> on Marionnet's VMs?
c) I cannot identify IP of VMs which is associated to tunnel where
172.23.0.254 is on the other side, since "ifconfig -a" (ran on the VM)
is of no help. Once you've mentioned that I can ssh to M1 by means of
using 172.23.0.1 and I successfully did this. I also tried to reach M2
via 172.23.0.2 and it also worked. So my question: what is the common
rule to identify IP address of VMs including ones with multiple NICs,
i.e. routers?
Thanks.
--
Simon
On Mon, Apr 8, 2013 at 11:09 AM, Jean-Vincent Loddo
<Jean-vincent.Loddo@xxxxxxxxxxxxxxxxxxxx
<mailto:Jean-vincent.Loddo@xxxxxxxxxxxxxxxxxxxx>> wrote:
Hi Simon,
It's possible that you was not so far from the solution. I'm totally
agree with the actions described in Step 4 (and in PS) excepting for
the selected cookie:
- in Step 4 you try with the cookie of (server:0)
- in PS. you try with the cookie of (client:7)
but the cookie you need is the cookie of (server:???), i.e. the
cookie of the server display related to (client:7) by the xdmcp
connection. I don't know the details of the xdmcp protocol, but
there are chances that such display exists:
(client,7) <-> (server,???) <-> (m1,0)
In order to confirm or refuse this conjecture, could you try to list
all the existing displays and related cookies on server:
server# xauth list
....
server/unix:10 MIT-MAGIC-COOKIE-1 ad11ddaa9cd94696ce3619e6a1a83e__94
server/unix:11 MIT-MAGIC-COOKIE-1 604b67d03684f9e7282936dca32c1c__d9
server/unix:12 MIT-MAGIC-COOKIE-1 fa72fc3509f63274fbb27b04106f8d__5f
....
then repeat the Step 4 until you will find the good cookie among
this list.
Another way, is to observe the server (xauth list) before and after
the xdmcp connection of the client. If you observe the creation of a
new display and cookie, it's the good one!
Hope this helps,
Jean-Vincent
> PS: I also tried to modify Step 4 while using cookie of thin
client, > but it also failed with messages:
Le 07/04/2013 21:52, Simon Baev a écrit :
Hi Jean-Vincent,
Thank you for the help but this approach doesn't seem to solve the
problem. Here are some more details:
1. First I ran "echo $DISPLAY" on server (IP is set to
168.18.104..142)
console (which I normally cannot access since LSTP server is
headless,
i.e. virtualized with VMware ESXi) and I got ":0.0" which is not
"localhost:7.0" as in your reply.
2. I ran the same command, i.e. "echo $DISPLAY" on thin client
(IP is
set to 168.18.104.251) which returned "168.18.104.251:7
<http://168.18.104.251:7>
<http://168.18.104..251:7 <http://168.18.104.251:7>>" so I
concluded that thin client utilizes 7th
display port of X11 server running on LTSP server... BTW is this
correct
assumption?
3. I listed magic cookies by running "xauth list". On both (LSTP
server
and thin client) result is the same. It lists for example:
-----------------8<----------
168.18.104.251:7 <http://168.18.104.251:7>
<http://168.18.104.251:7> MIT-MAGIC-COOKIE-1
7a70850220f80c6ee6b3419c9f8c85__2c
LTSP2/unix:0 MIT-MAGIC-COOKIE-1 d8cbbc217e8ba13aa429855c55928a__1a
-----------------8<----------
among other similar records
4. I started Marionnet and created a project with one VM. Then I
started
the project and waited for VM to boot up. Then I logged in and
ran the
following commands:
-----------------8<----------
m1:~# echo $DISPLAY
172.23.0.254:0 <http://172.23.0.254:0> <http://172.23.0.254:0>
m1:~# xauth list
xauth: creating new authority file /root/.Xauthority
m1:~# xauth add $DISPLAY . d8cbbc217e8ba13aa429855c55928a__1a
xauth: creating new authority file /root/.Xauthority
m1:~# xauth list
172.23.0.254:0 <http://172.23.0.254:0> <http://172.23.0.254:0>
MIT-MAGIC-COOKIE-1
d8cbbc217e8ba13aa429855c55928a__1a
m1:~# xeyes
(window is shown on the virtual console of headless LSTP server,
but not
on the screen attached to thin client)
-----------------8<----------
5. I created, started and logged in another VM, i.e. "m2" and
ran the
same scenario while changing value of the $DISPLAY variable to
168.18.104.251:7 <http://168.18.104.251:7>
<http://168.18.104.251:7> and using corresponding cookie:
-----------------8<----------
m2:~# echo $DISPLAY
172.23.0.254:0 <http://172.23.0.254:0> <http://172.23.0.254:0>
m2:~# xauth list
xauth: creating new authority file /root/.Xauthority
m2:~# export DISPLAY=172.23.0.254:7 <http://172.23.0.254:7>
<http://172.23.0.254:7>
m2:~# xauth add $DISPLAY . 7a70850220f80c6ee6b3419c9f8c85__2c
xauth: creating new authority file /root/.Xauthority
m2:~# xauth list
172.23.0.254:7 <http://172.23.0.254:7> <http://172.23.0.254:7>
MIT-MAGIC-COOKIE-1
7a70850220f80c6ee6b3419c9f8c85__2c
m2:~# xeyes
Error: Can't open display: 172.23.0.254:7
<http://172.23.0.254:7> <http://172.23..0.254:7>
-----------------8<----------
6. Finally I attempted to replicate Step 5 while creating VM
named "m3"
but this time I used cookie from LTSP server:
-----------------8<----------
m3:~# echo $DISPLAY
172.23.0.254:0 <http://172.23.0.254:0> <http://172.23.0.254:0>
m3:~# xauth list
xauth: creating new authority file /root/.Xauthority
m3:~# export DISPLAY=172.23.0.254:7 <http://172.23.0.254:7>
<http://172.23.0.254:7>
m3:~# xauth add $DISPLAY . d8cbbc217e8ba13aa429855c55928a__1a
xauth: creating new authority file /root/.Xauthority
m3:~# xauth list
172.23.0.254:7 <http://172.23.0.254:7> <http://172.23.0.254:7>
MIT-MAGIC-COOKIE-1
d8cbbc217e8ba13aa429855c55928a__1a
m3:~# xeyes
Error: Can't open display: 172.23.0.254:7
<http://172.23.0.254:7> <http://172.23.0.254:7>
-----------------8<----------
So it seems that exporting magic cookie doesn't solve the
problem... Am
I missing something?
PS: I also tried to modify Step 4 while using cookie of thin
client, but
it also failed with messages:
-----------------8<----------
Xlib: connection to "172.23.0..254:0.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
Error: Can't open display: 172.23.0.254:0
<http://172.23.0.254:0> <http://172.23.0.254:0>
-----------------8<----------
Looking forward to reed your response. Thank you.
--
Simon
On Wed, Apr 3, 2013 at 7:59 AM,
<Jean-vincent.Loddo@xxxxxxxxx-__paris13.fr
<mailto:Jean-vincent.Loddo@xxxxxxxxxxxxxxxxxxxx>
<mailto:Jean-vincent.Loddo@__lipn.univ-paris13.fr
<mailto:Jean-vincent.Loddo@xxxxxxxxxxxxxxxxxxxx>>> wrote:
Hi Simon,
It's a pleasure to answer to a well detailed question, even
if the
solution is not simple.
7. I assumed that having DISPLAY set to <IP of
thin-terminal>:7 on
hosting site may require setting DISPLAY from within
Marionnet's
host
to 172.23.0.254:7 <http://172.23.0.254:7>
<http://172.23.0.254:7> but it doesn't fix the
problem. Actually it fixes
(removes) the first part of the error message related
to refused
connection, so the new error message looks like:
-----------8<----------
(wireshark:5076) Gtk-WARNING **:cannot open display:
172.23.0.254:7 <http://172.23.0.254:7> <http://172.23.0.254:7>
This is reasonable, but it doesn't work. (I think that if
it had
been enough, we would have introduced it in Marionnet).
Actually, I
think that you have to transmit the server's X11 cookie to all
virtual machines... Suppose that you start an ssh
connection from
the (thin) client to the server. In this connection, your
$DISPLAY
doesn't correspond to a real X11 server (it's the ssh -X
tunneling):
server# echo $DISPLAY
localhost:7.0
However, this information is useful to get the related cookie:
server# xauth list :7
server/unix:7 MIT-MAGIC-COOKIE-1
34409ca90323311c437495112c060b____da
Now you have to send this cookie to the virtual machine (for
instance "m1", with IP 172.23.0.1):
m1# echo $DISPLAY
172.23.0.254:0 <http://172.23.0.254:0> <http://172.23.0.254:0>
server# ssh root@172.23.0.1 <mailto:root@172.23.0.1>
<mailto:root@172.23.0.1 <mailto:root@172.23.0.1>> xauth add
172..23.0.254:0 <http://172.23.0.254:0> .
34409ca90323311c437495112c060b____da
root@172..23.0.1 <mailto:root@172.23.0.1>
<mailto:root@172.23.0.1 <mailto:root@172.23.0.1>>'s password:
or directly in your virtual machine:
m1# xauth add $DISPLAY . 34409ca90323311c437495112c060b____da
xauth: creating new authority file /root/.Xauthority
m1# xeyes # should appear on your thin client
Best regards,
Jean-Vincent
On Tue, 2 Apr 2013 11:55:28 -0400, Simon Baev wrote:
Hello All,
Background:
--
I'm trying to run Marionnet in LTSP environment
(ltsp.org <http://ltsp.org>
<http://ltsp.org> [1])
installed
on top of Lubuntu 12.10 (Ubuntu + LXDE) with several
thin-terminals
(http://www.__disklessworkstat__ions.com/1700-__series-thin-__clients.html
<http://disklessworkstations.com/1700-__series-thin-clients.html> <http://www.__disklessworkstations.com/1700-__series-thin-clients.html
<http://www.disklessworkstations.com/1700-series-thin-clients.html>>
[2]).
This LTSP server is virtualized in VMware ESXi but it
should
play any
difference.
Setup:
--
1. The LTSP server has IP 168.18.104.142 and latest
version of
Marionnet installed using the script.
2. A thin-terminal utilizes PXE boot, gets IP address
from the
same
LAN, i.e. 168.18.104..128/25 [3] and starts LDM
session to LTSP
server
3. As soon as LDM session gets authenticated on LSP
server it
(thin-terminal) starts X session so I can run
Marionnet on it. In
console of the thin-terminal I can see the value of
DISPLAY
which is
set to :7
4. When I create new project in Marionnet with at
least one
host and
start up the project, it adds a NIC (one per each
Marionnet's
host)
with IP address set to 172.23.0.254/255.255.255.255
<http://172.23.0.254/255.255.255.255>
<http://172.23.0.254/255.255.__255.255
<http://172.23.0.254/255.255.255.255>> [4] so I assume
it is
sort of P2P tunnel between hosting machine and a host
within
Marionnet
environment.
5. Once Marionnet's host started I can check the
value of its
DISPLAY
which is set to 172.23.0.254:0
<http://172.23..0.254:0> <http://172.23.0.254:0
<http://172.23..0.254:0>> [5]
6. When I try to start wireshark in Marionnet's host
I'm getting
error:
-----------8
Links:
------
[1] http://ltsp..org
[2]
http://www.__disklessworkstati__ons.com/1700-__series-thin-__clients.html
<http://disklessworkstations.com/1700-__series-thin-clients.html>
<http://www.__disklessworkstations.com/1700-__series-thin-clients..html
<http://www.disklessworkstations.com/1700-series-thin-clients..html>>
[3] http://168.18.104.128/25
[4] http://172.23.0.254/255.255.____255.255
<http://172.23.0.254/255.255.__255.255>
<http://172.23.0.254/255.255.__255.255
<http://172.23.0.254/255.255.255.255>>
[5] http://172.23.0.254:0
[6] http://172.23.0.254:0
[7] http://172.23.0.254:7
[8] http://172.23.0.254:7
_________________________________________________
Mailing list: https://launchpad.net/~__marionnet-dev
<https://launchpad.net/~marionnet-dev>
Post to : marionnet-dev@lists.launchpad.__net
<mailto:marionnet-dev@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~__marionnet-dev
<https://launchpad.net/~marionnet-dev>
More help : https://help.launchpad.net/__ListHelp
<https://help.launchpad.net/ListHelp>
_______________________________________________
Mailing list: https://launchpad.net/~marionnet-dev
Post to : marionnet-dev@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~marionnet-dev
More help : https://help.launchpad.net/ListHelp
References
