How To: VNCServer on Fedora

Virtual Network Computing (VNC) is a desktop protocol to remotely control another computer. It transmits the keyboard presses and mouse clicks from one computer to another relaying the screen updates back in the other direction, over a network.” -WikiPedia-

This article describes in brief how to configure VNC server instances for one or multiple users on a remote machine, how to use VNC to start graphical applications on boot and finally how to enhance security by connecting to the server through encrypted SSH tunnels.

Prerequisites

A user account should exist on the remote machine.
The RPM packages xorg-x11-xauth, vnc-server and vnc should be installed on the remote machine and your workstation respectively.

yum install -y xorg-x11-xauth vnc-server vnc xsetroot xterm 

Setting up the server

I assume that we have setup a remote user account, named “Tyler” and we want to start an X session through VNC for this user.

In Red Hat based distros in general, all we have to do is define the VNC server instances in /etc/sysconfig/vncservers. These will be started by the vncserver initscript. This has to be done as root. Edit this file so that it contains the following:

VNCSERVERS="1:tyler"
VNCSERVERARGS[1]="-geometry 1024x768 -depth 16"

With these we define that a vnc server instance should be started as user Tyler on display 1 and we also set some options for this server such as resolution and color depth. Each VNC server instance listens on port 5900 plus the display number on which the server runs. In our case, Tylers’s vnc server would listen on port 5901.

For multiple vnc instances /etc/sysconfig/vncservers would look like this:

VNCSERVERS="1:tyler 2:albatros 3:leopard"
VNCSERVERARGS[1]="-geometry 1024x768 -depth 16"
VNCSERVERARGS[2]="-geometry 800x600 -depth 8"
VNCSERVERARGS[3]="-geometry 1024x768 -depth 16"

These would listen on ports 5901, 5902, 5903 respectively.

User Configuration

There is one more thing that needs to be done on the remote machine. User Tyler’s vnc password needs to be set. So, as user Tyler give the command:

# su -l Tyler
# vncpasswd
# exit

We are prompted for a password. This is the password that we will use when we connect to Tyler’s vnc server instance. This password is saved in /home/Tyler/.vnc/passwd.

Start the VNC server

After the initial configuration is done we restart the vnc service. As root:

# service vncserver restart

To make VNC server to start on boot:

# chkconfig vncserver on

More User Configuration

After the VNC service is started, some new files are created in /home/Tyler/.vnc/ directory. These include Tyler’s vnc server log file, pid file and an X startup script. As user Tyler we edit the script in order to customize some settings. The default /home/Tyler/.vnc/xstartup script contains some commands that are executed when the VNC server is started. These include:

xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
twm &

xsetroot in this case sets the background color.
vncconfig is a supplementary program that can be used to control the vnc server. Apart from this, when run without arguments it acts as a helper application and its main purpose is to provide support for clipboard transfers between the client (vncviewer) and the vnc server.
xterm starts an xterm terminal.
twm starts the X server’s default window manager. We probably want to change that to a more user friendly window manager, eg fluxbox.

The VNC server, apart from letting us control a remote machine using a graphical interface, it serves as a way to start graphical applications on boot. For example, I want my favourite p2p program, amule, to start on boot. So, I add this to the /home/Tyler/.vnc/xstartup script. This is how my xstartup file looks like:

xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" -e ./menu &
amule &
fluxbox &

menu is a script of mine that is executed when xterm is started.
Remember to put the “&” symbol after each command, so that it goes to the background and the xstartup script continues on.

Restart the VNC service for the changes to take effect. As root:

# service vncserver restart

Connect to the VNC server

In our example, Tyler’s vnc server listens for connections on port 5903. So, open this port in the remote machine’s firewall.

We connect to the remote machine using a vnc viewer. Having installed the vnc package, connect to to the server with the following command:

# vncviewer 192.168.0.1:5903:3

The general usage is :

vncviewer [Server's IP]:[Port]:[Display]

We are prompted for the password and eventually connect to the server. Closing the vncviewer’s window, does not affect the server or the programs we run on it. If we reconnect everything will be there.

Special Note: There is no need, actually it’s pointless and could give you some trouble, to logoff from your remote X session. If this happens, generally you need to restart the VNC service on the remote machine to get your remote desktop back. If you want to stop working on your remote desktop, just close the vncviewer’s window and you are done.

Security

The VNC protocol is not a secure communication protocol. The use of a vnc password provides security at the level of server access (it’s vulnerable to brute-force attacks though), but the whole VNC session is transmitted in the clear, without encryption. The easiest, but most effective, way to secure our connection to the VNC server is to connect through an encrypted SSH tunnel. This way the whole session will be encrypted.

The rest assume that you have the SSH server up and running on your remote machine (server.example.com) and you know what SSH tunnels are.

So, what we are going to do is to create an encrypted tunnel, and connect to our VNC server through it. We also want this tunnel to be automatically closed as soon as we shut down vncviewer. All this is done with the following command:

# ssh -f -L 25903:127.0.0.1:5903 [email protected] sleep 10; vncviewer 127.0.0.1:25903:3

This is what it does:

  • -L 25903:127.0.0.1:5903 forwards our local port 25903 to port 5903 on the remote machine. In other words, it creates the tunnel.
  • -f forks the SSH session to the background, while sleep is being executed on the remote machine. This ssh option is needed because we want to execute the following command (vncviewer) in the same local machine’s terminal.
  • vncviewer connects to the forwarded local port 25903 in order to connect to the VNC server through the encrypted tunnel.

The sleep command is of major importance in the above line as it keeps the encrypted tunnel open for 10 seconds. If no application uses it during this period of time, then it’s closed. Contrariwise, if an application uses it during the 10 sec period, then the tunnel remains open until this application is shut down. This way the tunnel is automatically closed at the time we close vncviewer’s window, without leaving any SSH processes running on our workstation. This is pure convenience! More information can be found at the Auto-closing SSH Tunnels article.

Using SSH tunnels to conect to your VNC server has two advantages:

  1. The whole session is encrypted.
  2. Keeping port 5903 open on your remote machine is no longer needed, since all take place through the SSH tunnel. So, noone will know that you run a VNC server on the remote machine.

Further Reading

I recommend that you read the man pages. Everything is in there:

# man vncserver
# man Xvnc
# man vncconfig
# man vncviewer
# man ssh

Optimizing a Server: prelink

When most people think about server optimization, it’s almost always a question of tuning MySQL, deciding how many HTTPD processes should be running, limiting the maximum connections to the server, and installing a caching proxy like Varnish or Squid.

While all of these optimizations should be performed, they’re not the only optimizations we can perform on a server. In fact, there’s something simple that can improve performance of the system globally, without any configuration!

When a program is run, there are a few things that have to happen before it can actually start doing work. First, the program is loaded into server memory. Next, ld.so processes the binary, loading all of the libraries (.so files, shared objects) that it needs–a step called dynamic linking. Finally, the program will start running from its main() function.

While there’s not much that can be done to speed up loading the binary into memory, other than getting faster disks, the dynamic linking step can be made faster. How? With prelink.

prelink is run on every binary and library on the system, pre-computing the locations of all of the libraries, so that they can be loaded into the same place in memory (barring no conflicts) every time a program starts. This significantly reduces the amount of time needed for the dynamic linking step of the program loading process, allowing programs to reach execution much faster.

To install prelink, run:

yum install prelink

Next, force prelink to pre-link all binaries on the system right now by running:

/usr/sbin/prelink --all

All programs on the system are now prelink'd. The prelink package adds a cron job that runs daily to check for any binaries that may have changed since the last prelink run, and updates them as needed.

Enjoy faster process start up times, thanks to prelink.