[How-To] X11VNC Server that starts at bootup

Write tutorials and howtos in here
There are more tutorials here http://community.linuxmint.com/tutorial/welcome
Forum rules
Do not start a support topic here please. Before you post please read this

[How-To] X11VNC Server that starts at bootup

Postby 9999 on Tue Aug 06, 2013 12:48 pm

* Linux Mint comes with Vino pre-installed, which is a nice VNC server but quite bare-bones and requires Gnome. Worst of all, it's incapable of renaming the exported Avahi service name, meaning that Mac OS clients will see duplicate entries for the machine in their sidebar (one for file shares and one for the desktop share). Therefore I uninstalled Vino and experimented with x11vnc until I had a perfect setup that works beautifully together with Macs on the network. Here is the guide for what I did.

* First, let's install x11vnc, an extremely light-weight, powerful, fast and secure VNC server, which (like Vino) is intended for connecting to the local display/keyboard/mouse and allowing complete control over the machine as if you sat at the console. But unlike Vino, we can actually configure this thing to do what we want! In this case, we'll be setting it up to run a single server that controls the entire machine as if we sat at the console.
# apt-get update
# apt-get install x11vnc


* Now create a hashed password file only readable by root. Only the first 8 characters of the password will be used due to VNC protocol limitations!
# x11vnc -storepasswd /etc/x11vnc.pwd
# chmod 600 /etc/x11vnc.pwd


* We want the x11vnc server to start at the same time as Linux Mint's MDM login manager, which is when we can be sure that the desktop X server has been started. This also allows the VNC user to connect during the login stage and actually log in without physically being at the console. In fact, the user can even log out and log back in as another user, since the x11vnc server continues running as root at all times.

* Alright, so to make it launch as root in conjunction with MDM, you need to edit the MDM Init script.
# vi /etc/mdm/Init/Default

* Go down to the bottom of the file and insert the following right before the last "exit 0" line:
if [ -z "$(pidof x11vnc)" ]; then nohup x11vnc -norc -forever -shared -rfbauth /etc/x11vnc.pwd -allow 192.168.0. -autoport 5900 -avahi -env X11VNC_AVAHI_NAME=`hostname` -desktop "`hostname`'s Remote Desktop" -scale_cursor 0.5 -repeat -bg -o /var/log/x11vnc.log 2>/dev/null 1>&2; fi

Warning: Change 192.168.0. to whatever your local network prefix is if that's not your prefix. For instance, you might be on 192.168.1. or 10.0.0. so just change it to whatever your network is. This option basically prevents unauthorized internet connections since by only accepting local-network connections. If you don't want that security, you can remove the whole "-allow 192.168.0." part.

* That's it. Reboot to start the VNC server. Here's an explanation of what all of the options above are doing:
if [ -z "$(pidof x11vnc)" ]; then ...; fi (the mdm-Init script is executed twice on boot, so this statement ensures that we don't launch x11vnc twice if it's already running)
nohup x11vnc (executes the server process without listening to the "HUP" hangup signal; this ensures that the process keeps running even when the launching "terminal" shuts down (this simply protects against the MDM process dying and taking x11vnc down with it, but is actually useless because MDM never dies on a normal system even when switching users, and may even be harmful because IF MDM somehow died then we'd probably want the VNC server to die too, but oh well). note that some people think that "nohup" protects it from dying when you log out from one user and return to the login screen; that's not true. like I said, it has to do with the actual MDM process itself dying (which should never happen). and just to clarify; the x11vnc process will of course never die just because you log out of the current user. however, x11vnc WILL do some weird stuff internally when it switches active X session, including stopping the mDNS service, starting it again, and wiping the output log file, but it all takes place within the exact same x11vnc process; no process spawning is going on (I verified with both -bg and & to see that it was indeed the same process still running))
-norc (don't search for a config file on the disk; take all options from the command line instead)
-forever (keep listening even after the first client disconnects; extremely important otherwise the server quits when the first client disconnects)
-shared (allow more than one viewer to connect at the same time; extremely important because the Mac OS VNC client makes multiple connections per session)
-rfbauth /etc/x11vnc.pwd (tell it to use the password file we created earlier (only readable if process is spawned as root, which it is since MDM runs as root))
-allow 192.168.0. (only allow clients on the same local IPv4 subnet, this also blocks ipv6 clients since we aren't adding any v6 addresses)
-autoport 5900 (try to listen on port 5900, otherwise keep incrementing until we find a free port)
-avahi (use mDNS service discovery to announce the VNC server address and port to the network)
-env X11VNC_AVAHI_NAME=`hostname` (if your computer is called "MediaCenter" for instance, then the automatic mDNS service name would be MediaCenter:0, so we force it to just plain "MediaCenter" (hostname) to merge it neatly into the Finder sidebar so that it merges itself with any exported file shares from the same machine and doesn't take up two sidebar entries)
-desktop "`hostname`'s Remote Desktop" (replaces the default "MediaCenter:0" desktop name shown as the title bar inside your VNC viewer, with a nicer title)
[[-display :0 (the physical X server display we want to share; we could also have used -find to autodetect the display) <-- not needed because MDM has already set the correct "main screen" DISPLAY environment variable in the Init script
[[-auth guess -env FD_XDM=1 (these two commands will try to find the X authority file for the login manager/current X session) <-- not needed because MDM has already set the XAUTHORITY environment variable in the Init script
[[-reopen (avoids issues with being killed by the login manager, but shouldn't be needed; in fact, the readme says that many login managers kill x11vnc as soon as the user logs in, but that it should be fine to leave this option out as long as you log in within 45 seconds - so, I tried leaving it out and waited for about a minute and a half, and had no issues with the process being killed, so I can only assume it's not needed at all when using MDM)
-scale_cursor 0.5 (this reduces the scale of the mouse pointer to half, which is useful for turning larger-than-normal HTPC cursors back to normal desktop size over VNC, but most people probably do not want this option)
-repeat (this is used for compatibility with Mac OS X's built-in VNC viewer. first some backstory: all keystrokes received by x11vnc are simply forwarded to the X server, which in turn works by looking at the time that it received the key-down event, and then waiting for a key-up event. while waiting, it will apply auto-repeats at regular intervals until it gets the key-up event. the issue with this is that x11vnc might receive a key-down event, forward it to the X server, and then become busy with a heavy screen refresh, and as a result it might not get to forwarding the key-up event in time. the X server will then think that the key has been held down for all this time, and will repeat it. this means that over high-latency connections and in certain heavy-screen-refresh situations, it might be near impossible to type over VNC. the chosen workaround was for x11vnc to default to the -norepeat flag, which tells the X server to disable all autorepeating for as long as anyone is connected over VNC. you can then use specially implemented VNC clients that do different client-side autorepeating by sending alternating down/up/down/up events for as long as the key is being held down, rather than just sending down/down/down/up. this workaround works perfectly if your client uses the down/up/down/up pattern, and supports viewer-side autorepeat while avoiding all of the latency repeat issues. however, the issue with this is that the Mac OS X VNC viewer sends repeats using the regular down/down/down/up pattern. therefore, we must tell x11vnc to keep the X server's autorepeat enabled in order for it to interpret repeated keys properly from Mac clients. however, even when load was so high that the screen refreshes hung and all keypresses became queued for seconds at a time, I never ever encountered issues with characters becoming repeated, suggesting that the -norepeat default is no longer needed for libvncserver and that the back-end queue in the latter has been fixed (x11vnc is mainly a wrapper around libvncserver and the author isn't a god; he makes mistakes with his libvncserver usage like any other human))
-bg (takes all of our given command line parameters and spawns a background process, then exits the main process, thus allowing the MDM Init script to proceed; could also have been solved with a regular "&" to spawn a background process, but I suppose it looks neater to use the built-in function)
-o /var/log/x11vnc.log (clears any existing log contents and then sends all status messages here, thereby giving us per-reboot logfiles)
2>/dev/null 1>&2 (redirects stderr to /dev/null and stdout to stderr, thus removing all nohup and x11vnc terminal output during our initial launch (the log file will still be populated by the background child process of course); this redirection also ensures that nohup won't be writing stdout of the spawned process to nohup.out, which it would otherwise have done)

* Alright, now enjoy the near-flawless VNC server! Performance and reliability is great, and it even supports clipboard sharing!
- The only known issue is that anything that triggers massive amounts of screen redraws (such as a terminal window scrolling text like crazy) can break the ability to send further input (clicks/text). The solution is to disconnect and reconnect from the VNC server.

* Sidenote: Don't be tempted to try the -inetd mode, because that is a special socket mode which spawns one process per connection and doesn't support mDNS, etc; it's useless. Also, don't try to launch this from anywhere but the mdm-Init script, because it's the best possible place for hooking into the same DISPLAY/XAUTHORITY as the main window manager.

* The only area where we could improve things is if we could somehow set it to automatically re-launch the daemon if it dies for some reason. I guess we could do that using the -loopbg option but I don't care enough to get into testing that setup.

* Oh and Linux Mint's "New Login" menu item ("log in as a new user without logging out") should be avoided at all costs, since this action launches a separate X server for the new user while pausing your old X server in the background, thereby preventing you from controlling the computer via VNC again until you either reboot or log out from the new user. The same thing happens if you hit the regular "Logout" menu item and then click "Switch User," and should be avoided as well. If you want to switch user the proper way, you must completely log out from the current user via the regular Logout action.
9999
Level 1
Level 1
 
Posts: 21
Joined: Mon Jun 03, 2013 3:54 pm

Linux Mint is funded by ads and donations.
 

Re: [How-To] X11VNC Server that starts at bootup

Postby trapperjohn on Tue Aug 06, 2013 5:47 pm

Nice. One enhancement; make the connection by tunneling port 5900 over ssh. If x11vnc crashes, then it can be restarted from the ssh session.
trapperjohn
Level 5
Level 5
 
Posts: 686
Joined: Wed Jul 11, 2012 4:10 pm

Re: [How-To] X11VNC Server that starts at bootup

Postby 9999 on Wed Aug 07, 2013 6:20 pm

Thanks. Yeah, tunneling VNC over SSH adds encryption to what's otherwise a plaintext protocol.

But the reasons I didn't do that were 1) The built-in Mac VNC viewer needs annoying tricks to connect to an SSH-tunneled VNC server, 2) I only use VNC over the local network so there is no need to encrypt the data, and 3) It's a bit slower.

If I was going to use VNC over the internet then SSH tunneling is an absolute requirement for privacy, though!

Finally: I think that everyone should always have OpenSSH Server installed so that they can log in via the terminal to kill crashed processes, reboot, etc. I can't count the number of times I have been able to log in via SSH to kill XBMC when it has frozen. ;) SSH Is great. And it could also be used to restart x11vnc, like you say (although I do not remember it ever crashing for me in a year of use so far). Just note that manually restarting x11vnc over SSH would be slightly hard because you would have to read the /proc entry belongin to MDM, read its "env" (environment variables) file, get the DISPLAY and XAUTHORITY env variables, and pass those to x11vnc when you want to start it from SSH. Otherwise it would not be able to connect to the currently active desktop session, because X protects each running desktop with a password (the Xauthority). It's not hard to get those env variables but newbies would definitely find it difficult. Luckily reboots should not be necessary.
9999
Level 1
Level 1
 
Posts: 21
Joined: Mon Jun 03, 2013 3:54 pm

Re: [How-To] X11VNC Server that starts at bootup

Postby jasminj on Mon Dec 09, 2013 6:21 pm

THX for this HowTo, it helped me really to get it working.
But then I discovered sometimes problems when rebooting my machine. I got a little window telling me, that the mini login (or something similar, I can't remember) couldn't be started. After the next reboot it worked.
I discovered the problem happened 3 out of 10 reboots.

So I tried another solution and this solved the issue, so far.
Moreover, it doesn't touch existing files and is therefore update friendly.

My system is Linux Mint 15 (Olivia) 64Bit.
I did all from the above HowTo, but did not start x11vnc from /etc/mdm/Init/Default. Instead I used an upstart script to launch it, when the Login screen is displayed.
MDM (Linux Mint version of GDM) fires an Upstart event, if the Login screen is already displayed. Better it should. The Linux Mint MDM maintainer forgot to add the event firing, so I added it with a patch (see Bugreport: https://bugs.launchpad.net/linuxmint/+bug/1258940).

Now it is time to write the upstart script. I found a tutorial here: http://www.matrix44.net/blog/?p=1106, which I slightly modified for my needs.
My /etc/init/x11vnc.conf version:
Code: Select all
description "VNC Server"
author      "Egon A. Rath modified by Jasmin Jessich"

start on (login-session-start or desktop-session-start)
stop on desktop-shutdown

respawn
 
emits vnc-server-start
 
script
   x11vnc -v -norc -forever -shared -nolookup \
          -auth /var/lib/mdm/:0.Xauth -display WAIT:0 \
          -rfbauth /etc/x11vnc.pwd \
          -allow 192.168.55.,127. -rfbport 5900  \
          -desktop "`hostname`'s Remote Desktop" \
          -scale_cursor 0.5 -repeat -reopen \
          -o /var/log/x11vnc.log 2>/dev/null 1>&2

   initctl emit vnc-server-start
end script

I added respawn to have x11vnc restarted whenever it terminates and I added the DISPLAY and XAUTHORITY data. WAIT means here, that x11vnc waits for a connection, before it tries to open the X display. I added the localhost IPs (127.*) to allow connections from the local machine, which I need for SSH tunneling.

You can start the upstart script manually for testing with:
# start x11vnc

Stop it with:
# stop x11vnc

I used several different VNC clients to test it. Locally in my network and with SSH tunnels.
Android: bVNC
Windows: TightVNC+putty (was not able to get ssvnc to work)
Linux: Remmina

bVNC and Remmina have built in support for SSH tunneling. They use localhost for the tunnel similar to:
$ ssh -L5900:localhost:5900 janedoh@195.212.55.100
Please note, that localhost is the view of the SSH sever, which runs on the remote machine.
That's the reason to add 127. to the -allow configuration.

To obscure the SSH port over internet, I configured the router to forward the external port (e.g. 12110) to port 22 on my Machine. In some hotels or public hotspots many ports are blocked. For this locations I added a forward rule from port 80 to port 22 on my machine, too.

Hint: Configure your router for WakeOnLan packet forwarding and activate WOL on your machine. This allows you to remotely wakeup it on demand.
jasminj
Level 1
Level 1
 
Posts: 3
Joined: Sun Dec 08, 2013 12:28 pm
Location: Vienna

Re: [How-To] X11VNC Server that starts at bootup

Postby hcfbollen on Fri Mar 07, 2014 9:39 am

Thanks for this how-to; I am new to Linux but how-to's like this really help me. So thanks.

But: I ran into a problem. Installed X11VNC and had it up-and-running for some months now. Then I had to hard-reboot my machine (pressing the powerbutton for ten seconds - it was a XBMC hangup if I'm not mistaking), and since then X11VNC will not start. It reports that another program/server seems to be listening to port 5900. So now I'm stuck. I have no idea how to verify if there is another vnc-server running (Vino?) or if there is something broken as a result of the hard-reboot.

All help really welcome!
hcfbollen
Level 1
Level 1
 
Posts: 4
Joined: Mon Aug 19, 2013 5:28 pm

Re: [How-To] X11VNC Server that starts at bootup

Postby jasminj on Fri Mar 07, 2014 2:22 pm

You can try
Code: Select all
$ sudo netstat -l -p

to get this list:
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 *:5900 *:* LISTEN 1839/x11vnc
tcp 0 0 *:sunrpc *:* LISTEN 669/rpcbind
tcp 0 0 *:49108 *:* LISTEN 1644/rpc.mountd
...
As you can see, port 5900 is opened by x11vnc.
On your machine, this might be another program.
jasminj
Level 1
Level 1
 
Posts: 3
Joined: Sun Dec 08, 2013 12:28 pm
Location: Vienna


Return to Tutorials / Howtos

Who is online

Users browsing this forum: No registered users and 5 guests