Friday, 22 June 2012

Very Non Cooperative (really)

The powers that be at my work have decided to revisit the issue of BYOD / external access. I'd previously implemented solutions at two previous employers so thought I'd be able to come up with something suitable here.

In both the previous exercises, I'd arrived at the conclusion that the easiest way to implement this was in terms of services - and relying on open protocols such as HTTP, SMTP, telnet etc (before you reach for your guns, the telnet thing was due to a requirement for dg200 terminal emulation- and I couldn't get a client which would run over ssh - so the telnet was encapsulated in SSL using stunnel). However this project is a bit different for various reasons - not least a very real concerns that the users will leave their computers on trains and park benches. While others in the office had previously come up with horribly complicated encryption schemes - this is a nightmare to support. So after a good deal of thought I realized I could solve a whole load of problems at one stroke by using a remote window / desktop protocol. VNC was the obvious choice due to the wide availability of clients. And I'd previously implemented lots of VNC servers on Linux and on MSWindows - it was always a no-brainer. I did have cunning plans for dealing with small screen real estate, keyboard-less devices etc - but best to start with little steps.

So I fired up synaptic on my PCLinuxOS desktop and installed TightVNC server and a client. Running the server from the command line, it works (but obviously no window manager, and the simple standalone VNC auth). So I set it ll up to run through xinetd (similar to this), re-configure kdm and xfs, fire up a client, enter my username and password - "the server has closed the connection". Check firewall - no problem. Check logs - nothing there. Double check my config changes - all OK. Just to make sure I do clean reboot. Still not working. Check the man page - what's happenned to all the X integration stuff? Gone! No xdm support!

Next I tried RealVNC direct from the RealVNC website - got a licence - read the docs....no more inetd support? WTF? The only logical reason I can think of for this is that they want to enforce their licence terms. Still, I could live with that for the POC - who knows, we might even end up paying for licences for the service - in return for support. But every time I connected to localhost, I got "user not recognised or password was blank". RealVNC do say on their website that this can be an issue on some versions of Linux - and the solution is to disable PAM authentication (a bit weird since they say elsewhere that it is not available in the 'free' version). So I updated the configs, restart the server, to no avail. Tried various tweaks and fettling. Checked the firewall. Nothing. Oh, and there's no 'uninstall' functionality - so had to reverse engineer the installation to clean it up.

Have I got dumber with old age or is this another case where a good product has turned into bloatware?

Aaaaarrrrghhhh!

(some updates added as comments)

2 comments:

  1. Found the problem with tightvnc (actually lots of problems). First is that the man page for Xvnc has very little to do with version of Xvnc shipped - try 'Xvnc --help' to find out how it really works.
    Then there's xfs - the version that ships in PCLinuxOS has a startup config file in /etc/sysconfig/xfs which overrides *some* of the settings in /etc/X11/fs/config so even though I had configured the latter to listen on port 7100, the former was changing this to try to listen on port -1 (which obviously fails, though it still starts without logging anything.
    So the authentication messages being reported in RealVNC were probably complete red herrings.

    ReplyDelete
  2. Another update - have since discovered noVnc - a HTML5 tightvnc client - runs in a browser - and works really well!

    It's not always a struggle :)

    ReplyDelete