marionnet-dev team mailing list archive
-
marionnet-dev team
-
Mailing list archive
-
Message #00615
Re: Marionnet in LTSP
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 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
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 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
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 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
-----------------8<----------
Same for :11. When re-defined and exported DISPLAY=172.23.0.254:7 with :0,
:10, and 168.18.104.251:7 I had he following error message:
-----------------8<----------
m1:~# xeyes
Error: Can't open display: 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 on the thin
client leads to the need of using 172.23.0.254:7 but not 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> 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>" 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> 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>
>>
>> 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> 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> and using corresponding
>> cookie:
>>
>> -----------------8<----------
>> m2:~# echo $DISPLAY
>> 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>
>>
>> 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> MIT-MAGIC-COOKIE-1
>> 7a70850220f80c6ee6b3419c9f8c85**2c
>> m2:~# xeyes
>> Error: Can't open display: 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>
>>
>> m3:~# xauth list
>> xauth: creating new authority file /root/.Xauthority
>> m3:~# export DISPLAY=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> MIT-MAGIC-COOKIE-1
>> d8cbbc217e8ba13aa429855c55928a**1a
>> m3:~# xeyes
>> Error: Can't open display: 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>
>>
>> -----------------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 <Jean-vincent.Loddo@xxxxxxxxxxxxxxxxxxxx>
>> <mailto:Jean-vincent.Loddo@**lipn.univ-paris13.fr<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> 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>
>>
>>
>>
>> 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>
>>
>> server# ssh 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>'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> [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>>
>> [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> [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<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>
>>
>>
>
Follow ups
References
