search

Seitanas / kvm-vdi

linux-kvm based VDI solution
MIT License
217 stars 82 forks source link

spice html5 client not working #35

Closed henickr closed 8 years ago

henickr commented 8 years ago

Hi, trying to use the new html5 web sockets client but after cloning websockify and starting it ./run --token-plugin TokenFile --token-source /tmp/kvm-vdi 5959...

root@titan:~/henick/websockify# lsof -i:5959 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME python 30666 root 3u IPv4 2750944 0t0 TCP *:5959 (LISTEN)

then... visiting the url /kvm-vdi/client_pools.php

I am kicked to a login page to which I login with valid credentials to be allowed through only to receive the message LOGIN_FAILURE on the following page.

I haven't configured or installed anything so I assume that is the issue but the directions simply say run using that command and don't provide much else. Should I be building websockify from source or running it in some other way than I have said here?

i am posting this because i did not expect a problem with authentication ...

Thanks.

edit: i've since done an easy_install numpy and 'python setup.py build' then install on websockify in an attempt to omit usage of the provided copy in lieu of one built by this system. end result same.

henickr commented 8 years ago

nope.

henickr commented 8 years ago

Aha! ok, this just popped up when i clicked it this time. not sure why not before. error: [Errno 113] No route to host

Seitanas commented 8 years ago

Also check if token files contain correct data. It should be: tokenname: server_address:port

henickr commented 8 years ago

yes token contents are correct.

Seitanas commented 8 years ago

Have no idea, how this could be related. We are running our production on 3 blade servers.

henickr commented 8 years ago

no i spoke too quickly, any server would be identical to this blade considering how it works with the hypervisors being ssh accessible. blade server makes no difference...

Seitanas commented 8 years ago

ValueError: need more than 1 value to unpack is really an error, which tells, that contents of a token file does not have : symbols in it. Perhaps there is one file inside /tmp/kvm-vdi that does not?

henickr commented 8 years ago

is there some specific type of traffic that maybe my router isn't forwarding?

henickr commented 8 years ago

these are internal addresses anyway i will post the contents as they are inaccessible to the world.

fcs-virtuallab-win1010: titanblade03.cs.lan:5901

Seitanas commented 8 years ago

Nope, this is not a network related. Plugin just scans all files inside /tmp/kvm-vdi directory, reads contents and exlpodes with : (note space)

henickr commented 8 years ago

another interesting note is.... the no route to host error did not appear until i cloned their copy from git...

Seitanas commented 8 years ago

You need to have your dashboard server to be able to access hypervisor by titanblade03.cs.lan address

henickr commented 8 years ago

yes access is fine..

root@titan:~/henick/git-websockify/websockify# su VDI
Aug 12 14:14:43 titan su: (to VDI) root on pts/0
VDI@titan:/root/henick/git-websockify/websockify$ ssh titanblade03.cs.lan
Last login: Thu Jul 28 15:18:45 2016
VDI@titanblade03:~$
Seitanas commented 8 years ago

Just tried accessing your token and it woks fine: ./run --token-plugin TokenFile --token-source /tmp/kvm-vdi 5959 WARNING: no 'numpy' module, HyBi protocol will be slower WebSocket server settings: - Listen on :5959 - Flash security policy server - No SSL/TLS support (no cert file) - proxying from :5959 to targets generated by TokenFile /?password=TDIrNM9QRmdhdzuMpgSfUXyo7i&token=fcs-virtuallab-win1010 192.168.0.181 - - [12/Aug/2016 17:12:19] 192.168.0.181: Plain non-SSL (ws://) WebSocket connection 192.168.0.181 - - [12/Aug/2016 17:12:19] 192.168.0.181: Version hybi-13, base64: 'False' 192.168.0.181 - - [12/Aug/2016 17:12:19] 192.168.0.181: Path: '/?password=TDIrNM9QRmdhdzuMpgSfUXyo7i&token=fcs-virtuallab-win1010' 192.168.0.181 - - [12/Aug/2016 17:12:19] connecting to: titanblade03.cs.lan:5901 handler exception: [Errno -2] Name or service not known Last line is expected, because there are no dns entries for that address.

henickr commented 8 years ago

I get this:

x.x.x.x: new handler Process
mydesktop.research.cs.dal.ca - - [12/Aug/2016 14:18:48] "GET /?password=mVcEwmJWnlL2yaqYEN2Q0mMahS&token=fcs-virtuallab-win1002 HTTP/1.1" 101 -
mydesktop.research.cs.dal.ca - - [12/Aug/2016 14:18:48] x.x.x.x: Plain non-SSL (ws://) WebSocket connection
mydesktop.research.cs.dal.ca - - [12/Aug/2016 14:18:48] x.x.x.x: Version hybi-13, base64: 'False'
mydesktop.research.cs.dal.ca - - [12/Aug/2016 14:18:48] x.x.x.x: Path: '/?password=mVcEwmJWnlL2yaqYEN2Q0mMahS&token=fcs-virtuallab-win1002'
mydesktop.research.cs.dal.ca - - [12/Aug/2016 14:18:48] connecting to: titanblade03.cs.lan:5901
handler exception: [Errno 113] No route to host
exception
Traceback (most recent call last):
  File "/root/henick/git-websockify/websockify/websockify/websocket.py", line 930, in top_new_client
    client = self.do_handshake(startsock, address)
  File "/root/henick/git-websockify/websockify/websockify/websocket.py", line 860, in do_handshake
    self.RequestHandlerClass(retsock, address, self)
  File "/root/henick/git-websockify/websockify/websockify/websocket.py", line 114, in __init__
    SimpleHTTPRequestHandler.__init__(self, req, addr, server)
  File "/usr/lib64/python2.7/SocketServer.py", line 649, in __init__
    self.handle()
  File "/root/henick/git-websockify/websockify/websockify/websocket.py", line 581, in handle
    SimpleHTTPRequestHandler.handle(self)
  File "/usr/lib64/python2.7/BaseHTTPServer.py", line 340, in handle
    self.handle_one_request()
  File "/usr/lib64/python2.7/BaseHTTPServer.py", line 328, in handle_one_request
    method()
  File "/root/henick/git-websockify/websockify/websockify/websocket.py", line 543, in do_GET
    if not self.handle_websocket():
  File "/root/henick/git-websockify/websockify/websockify/websocket.py", line 531, in handle_websocket
    self.new_websocket_client()
  File "/root/henick/git-websockify/websockify/websockify/websocketproxy.py", line 91, in new_websocket_client
    connect=True, use_ssl=self.server.ssl_target, unix_socket=self.server.unix_target)
  File "/root/henick/git-websockify/websockify/websockify/websocket.py", line 736, in socket
    sock.connect(addrs[0][4])
  File "/usr/lib64/python2.7/socket.py", line 224, in meth
    return getattr(self._sock,name)(*args)
error: [Errno 113] No route to host
Ignoring interrupted syscall
Seitanas commented 8 years ago

Okay, so token files are read correctly now. There is a new problem, that websockify cannot access titanblade03.cs.lan. Are you using multiple gateways on your dashboard server?

henickr commented 8 years ago

nope just our main router... (that has a gateway for each of our internal subnets and a firewall that forwards to each but most traffic is allowed through 

default via x.x.x.x dev eno1  proto static  metric 100 
192.168.122.0/24 dev virbr0  proto kernel  scope link  src 192.168.122.1 ****

I do see the virtual bridge created another gateway somehow though that appears to be alive... 192.168.122.1.... I didn't make that... I vaguely remember it in the dhcp configs of either kvm-vdi or qemu as the pool that is issued to the dhcp clients... 122.0/24

it looks like it is trying to use my router as the default gateway which is typical for my environment here but instead should be using 192 to get to the address that was dhcp'd by the vm... maybe i'm wrong..

Seitanas commented 8 years ago

192.168.122.1 is default gw for libvirt virtual network. It is created automatically, when you install libvirt. you can disable it - it will not affect anything.

Seitanas commented 8 years ago

one last idea - perhaps you have somekind of firewall, that does not allow you to connect to 59xx ports from dashboard server. try telnet titanblade03.cs.lan 5901

henickr commented 8 years ago

yep thats it. that is exactly why i suspected network issue earlier in the thread... because its happened before... this firewall is pretty restrictive and partially the reason i don't mind posting so much information for people to openly follow on the internet...

i'll get back to you in a sec...

Seitanas commented 8 years ago

Just disable firewall rules from dashboard server. I can see no security issues here. Let dashboard server to be able access everything

henickr commented 8 years ago

ok after 2 hours poking around on the router firewall i learned another lesson about centos 7's newest release. firewalld will happily run in the background blocking things while you think iptables is in charge..... duh. ok. nice. ok this one was my fault :( testing time.

it works now.... seems to be having trouble capturing keyboard input... mouse input works fine but i'm walking away for a few minutes lol

Seitanas commented 8 years ago

Well, I use HTML5 client from another project: https://github.com/eyeos/spice-web-client It has lots of optimizations and features, that are vital for KVM-VDI. The project is somewhat passive now. Will look into keyboard issues monday - perhaps this is not client issue after all.

henickr commented 8 years ago

no it appears to be an eyeos issue where if you click out of the browser pane then back in it somehow loses capture... if you never click outside the window it works.... i think when i fix the resolution to come up correctly it will reduce the risk of it happening.

Seitanas commented 8 years ago

Nope, have no issues with keyboard. Having said that, we had issues with keyboard input on normal spice client, when hypervisor ran on Debian stable (autorepeat didn't work). After moving hypervisor to unstable everything began to work fine. Not sure, but perhaps there was some issues with old libspice.

henickr commented 8 years ago

oh, one issue appears to be when i tried to show it to someone in the next office that also opened up an instance by clicking on the pool... only a single token generated so we are back and forth stealing each others vm when it should be making 2 tokens for each of us... but that is a separate issue... this one can probably be closed and i'll open a new one after i poke around a bit and see if any real issues persist.

as for this particular issue.. the answer is.....

make sure centos 7 isn't using private tmp space.... and make sure firewalld is not working when you think iptables is working.

Seitanas commented 8 years ago

This is intended. you are hardwired with your username. so one user has only one session. it is useful, when you need to change your client computer/thin client and want to have your session follow you. By default session is reserved for 5 minutes (can be changed in config.php).

henickr commented 8 years ago

ok great, good info. yeah we used the same login

henickr commented 8 years ago

this thing is fantastic.

Seitanas commented 8 years ago

I assume everything works then? :)

henickr commented 8 years ago

yeah more or less. i'd like to know how to change the resolution to scale the available browser space... their documentation suggests...

You can do it permanently editing run.js or through the URL using the parameters:
http://example.com/spice-web-client/index.html?host=IP_ADDRESS_OF_WEBSOCKIFY&port=TCP_PORT_OF_WEBSOCKIFY

but it looks like you already do that with parameters and run.js i'm looking around a bit but it definitely doesn't appear as simple as just a variable or setting. it'd be an exercise

henickr commented 8 years ago

its really fast. way better than virt-viewer on mac and windows (3.0.... 4.0 is completely broken)

Seitanas commented 8 years ago

Do you have spice-agent running on your guest? Because my screen always takes resolution of my window. virt-viewer should not be slower, unless computer you are running it on has slow CPU. virt-viewer still is best solution for thin clients, since it has kiosk mode and usb redirection.

henickr commented 8 years ago

do you use 3.0 or do you have 4.0 working? its most likely caused by me using an old version...

Seitanas commented 8 years ago

I'm using 4.0, but as I've realized, - client version has little impact on performance. It's the hypervisor side that matters. This is why we moved hypervisors to unstable distribution.

henickr commented 8 years ago

oh and no i don't have spice-agent running yet because i haven't quite figured out the nat on the dashboard node so the guests on the libvirt network can get internet access... they can ping the dashboard node but that is all. so as soon as the nat is done they should work.

Seitanas commented 8 years ago

spice-agent (also ovirt-agent) are network independent - they will work even if no network is attached. They are using sockets between hypervisor and guest.

henickr commented 8 years ago

dhcp on the guests works fine to get to 192.168.122.0/24 ... i don't see external traffic ... maybe the bond is different on redhat or broken. never turned ip_forwarding on is likely the cause.

oh i'm sure the spice-agent is independent i just can't download it on the client without internet and i have done much work to customize an iso yet ..

i think i know why the guests are slow i just realized.... the disk is full. i ran the windows assessment tool and it says 7.85/10G is reserved for system files. haven't dug much deeper yet.

i only got them running the way i want recently so there is quite a bit of little cleanups to do.

henickr commented 8 years ago

oh sorry a quick comment about the internet not working thing is that everything is fine in linux... just windows is the issue... and all of the drivers have been installed... gateway pings.. hm... forgot the linux side worked... now i'm more curious :)

Seitanas commented 8 years ago

This is known issue with windows guest + virtio network adapter, when dhcp server vm is on same hypervisor. You should try using newer dhcp server (this is fixed in newer isc-dhcpd), or use differnent netwrork card for dhcp or guest vm (one of them will do).

On August 13, 2016 2:46:53 AM GMT+03:00, henickr notifications@github.com wrote:

oh sorry a quick comment about the internet not working thing is that everything is fine in linux... just windows is the issue... and all of the drivers have been installed... gateway pings.. hm... forgot the linux side worked... now i'm more curious :)

You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/Seitanas/kvm-vdi/issues/35#issuecomment-239585537

henickr commented 8 years ago

excellent. you're full of good information aren't you :) ... tyvm.

ps. do you ever sleep? I know i work a lot but man.

henickr commented 8 years ago

and the full drive thing is just me not paying attention to what iso i used... to clarify... that was less of an oversight and more of a troubleshooting step at the time. i was not able to get the hypervisor to run windows 10 because of the ev package missing on centos 7 so i wanted to use the most 'normal' iso that i could from msdn.

i'm trying this thin client one now that i am sure it works ok... despite the fact my research says it works great except maybe it can't install office... we use o365 here anyway so i can live with that. https://blogs.windows.com/business/2011/07/01/heres-the-skinny-windows-thin-pc-available-for-download-today/

edit: i found a direct link to an x86 version of their iso that still works http://download.microsoft.com/download/C/D/7/CD789C98-6C1A-43D6-87E9-F7FDE3806950/ThinPC_110415_EVAL_x86fre.iso

and... an update.. https://www.microsoft.com/en-us/download/details.aspx?id=29238

edit again... image iostor/w10/x86 loads the driver but then fails saying contact vendor for an updated driver.

too bad. i'll look around and see if i can get it to accept another one.. i'd like to see it run.

edit again... used attach-disk virtio-win-latest from the repo and used iostor/w7/x86 and it seems to work.

henickr commented 8 years ago

seems really good... very light.. copy of win7 with all the io intensive stuff turned off already... 10 worked fine but this is a lightweight option for anyone looking for one or using old hardware or whatever the use case may be...

quick question about customizing iso... i read if you press shift+ctrl+f3 at the create account screen it puts the system in 'audit' mode and allows you to do some customizations before running sysprep to finalize it for deployment... i wasn't able to make that happen--possibly due to keyboard not sending keys, tried onscreen-- so i took a snapshot in case i wanted to do it later... i know about ntlite and was planning on doing it that way previously... then i stumbled across this..

henickr commented 8 years ago

i think this is a patch to the dhcp issue http://pkgs.fedoraproject.org/cgit/rpms/dhcp.git/tree/dhcp-4.2.2-xen-checksum.patch?id=038d346d726e131f1ab2579fe015a72b49733a0d;id2=HEAD

context is udp packets dropped because of bad chksums... causes odd behavior with kvm and virtio https://lists.ubuntu.com/archives/foundations-bugs/2014-August/204384.html

Seitanas commented 8 years ago

Yes, this is the one. Easiest way is to change network device type of DHCP server to e1000. I've went to slightly different approach on our production server - I've installed isc-dhcp server packet from unstable distribution, which already has the patch.

henickr commented 8 years ago

2 quick comments for anyone reading the thread later... you also need port 5959 along with 80 allowed through ... i noticed this when trying to use it from home... we have firewall rules that work differently fromInside or fromOutside so the websockets traffic had to be routed out to use the web client externally, although it worked fine in the building because inside traffic is more lax. that's specific to me but may give others ideas as to what they need to do.

and the customizing iso thing... ctrl+shift+f3 works to get you into audit mode where you can install whatever you want then run sysprep so your users get the welcome experience if you want. a snapshot at the enter new username screen after a fresh install is good.

henickr commented 8 years ago

sorry another comment for anybody reading here.... on centos 7 it doesn't look like libvirt sets up the bonded interface as expected. after poking around the dhcp server and looking for presence of the bug we talked about previously.... nothing to indicate this was happening was found.

I set up a source nat and everything works perfectly on the windows guests as well as linux.

so a SNAT will be required on centos 7 on each hypervisor to translate traffic from the libvirt network to whatever network you have your hypervisor configured on. i am not sure if the bond came broken but my install is a default libvirt install.

Seitanas commented 8 years ago

Hello, I really doubt if there's problem with bonding drivers on centos. Perhaps you are using non bridged bond interface? It should go like this: physical interfaces==>bond==>bridge=>VM. What type of bond do you use?

henickr commented 8 years ago

no not drivers, and bonding works perfectly when configured... i thought you said it was automatically configured by libvirt... i didn't configure a bond at all.... maybe i misunderstood what you said. i expected from your comments that it would work out of the box because the libvirt install did it. it doesn't.

the reason i clarified this is because anybody who installs the software on centos will face the same problem. either set up a nat or set up a bond. either way, don't expect it to work unless you do it yourself.

what you end up with after installing libvirt on centos is the 192.168.122.0/24 libvirt network, what you choose to do with the traffic from there is completely up to you. in my case, i turned on ip_forward... set up a nat on each hypervisor and everything works flawlessly. a bond would have done the trick also... but for centos i'm assuming there should be something said to that effect in instructions.

hope that helps someone.