Setting up a VNC remote desktop in Enterprise Linux 4, 5, and 6

This is something that is terribly useful, and there are lots of how-to articles running around. Unfortunately, I've not found one that was quite complete, especially for someone who is only just getting familiar with Linux (which is precisely when you most need a GUI!). So this is a step-by-step instruction list on getting a remote X Windows session set up on enterprise linux 4, 5, and 6 (RHEL and CENTOS) that can be accessed with VNC viewer software (do a quick search on VNC if you're not familiar with it). In some set-ups, people create a VNCSERVER process that runs all the time. This does allow for persistent sessions (sessions that survive a disconnect), but it's not really what most of us need most of the time. What we're doing here is using xinetd, which will spin up Xvnc on an as-needed basis. Much cooler. Please note: vnc is not a secure protocol. What this means is that any traffic that VNC sends over the wire is *not* encrypted. Do make sure that your use of this doesn't put you at risk for having sensitive data (passwords, for instance) compromised.

Change the RunLevel

Change the runlevel to 3. This will stop GDM (which is what we're using in this example), or whatever your GUI front-end is.

init 3

Enable XDMCP

Since we want to use Gnome, we'll make sure it's the default desktop manager. Edit /etc/sysconfig/desktop and make sure it includes the following line:

DESKTOP="GNOME"
DISPLAYMANAGER=GNOME

Now activate xdmcp: edit the /etc/gdm/custom.conf file and find the following lines (NOTE: in RHEL 4 and CentOS 4, this is in /etc/X11/gdm/gdm.conf).

[xdmcp]
# Distributions: Ship with this off. It is never a safe thing to leave
# out on the net. Alternatively you can set up /etc/hosts.allow and
# /etc/hosts.deny to only allow say local access.
Enable=false
# Honour indirect queries, we run a chooser for these, and then redirect
# the user to the chosen host. Otherwise we just log the user in locally.

change it to Enable=true

Install VNC

If you're running a stock EL 5 system, you most likely already have vncserver installed. If you are running EL6, however, you'll need to install it:

yum install tigervnc-server

Create Xinetd startup file

Make sure xinetd is installed. The easiest way is to install it:

yum install xinetd

Create a file called vncserver in /etc/xinetd.d/ with the following content. This will tell xinetd to listen on 5908 and 5910 for a desktop of 800x600 and 1024x768 respectively (I like to have the option of using a lower resolution if necessary).
Note that the service names aren't important; feel free to change them. Likewise the resolution ("geometry") can be changed to fit your needs. The server_args line is what gets passed to the Xvnc application.
 Change 'localhost' to the fully qualified domain name of your system.
 If you would like a descriptive title on the title bar of the viewer, put that text after the -desktop= piece. Heads-up: the spaces around the equals signs are important. Xinetd won't read this if you omit them.

service vnc10 {
protocol = tcp
socket_type = stream
wait = no
user = nobody
server = usr/bin/Xvnc
server_args = -inetd -query localhost -once -geometry 1024x768 -depth 16 SecurityTypes=None –desktop=<Window_Name_Here>
port = 5910
type = unlisted
}

service vnc8 {
protocol = tcp
socket_type = stream
wait = no
user = nobody
server = /usr/bin/Xvnc
server_args = -inetd -query localhost -once -geometry 800x600 -depth 16 SecurityTypes=None –desktop=<Window_Name_Here>
port = 5908
type = unlisted }

Reload the xinetd settings with service xinetd restart

Enable the service

Set up the service to start on boot Turn on xinetd

chkconfig xinetd on

Set X Permissions

You have to allow X to display for various users on the ports you've allowed. The best way to do this is to use the Xn.hosts file, where n is the display number you're using. In our case, we're using 8 and 10, so we'll create two files: /etc/X8.hosts and /etc/X10.hosts. They'll contain just one line, that is the fully qualified domain name of the server.

Go back to runlevel 5

init 5

Configure your firewall

We have to allow traffic to come in to your computer on the two ports we configured in the vncserver xinetd file. In our example, we're using TCP ports 5908 and 5910, so we'll add lines to our iptables file to allow that incoming traffic:

vim /etc/sysconfig/iptables

Having opened the firewall file, we'll add the appropriate lines:

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 5908 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 5910 -j ACCEPT

These two lines tell the firewall to accept TCP traffic from any source to the ports 5908 and 5910. Save your changes to the file, and then restart the firewall to pick up the additional ports:

service iptables restart

We now should be able to connect to the server using 5908 and 5910. Use the stand-alone vncviewer application to connect. VNC works by specifying ports at the end of the computer domain name (e.g., hostname:10, to connect on port 5910). Once you are connected you should have the usual graphical login screen from gnome.

Set up clipboard functionality

Xvnc doesn’t do copy/paste to the client by default; it needs a helper app to do that. This is called vncconfig.

1. To set it up so that it runs at login, first log in (this must be done for each user who would use the system).
2. Click on Applications (SYSTEM in CentOS and RHEL v5) and select Preferences -> More preferences -> Sessions.
3. Click on the Startup Programs tab and click the Add button.
4. Type /usr/bin/vncconfig -nowin in the startup command field.

The next time that user logs in, copy and paste will be supported.

Troubleshooting

Connection Closed Unexpectedly or a Black Screen

If, after doing the above, you get a “the connection closed unexpectedly” error when trying to connect, try changing the -query localhost to -query in the file in the /etc/xinetd.d dir. The safest thing, if you run into this problem (or a black screen) is to replace ‘localhost’ with the output of hostname –f on the server. It could also indicate a typo in the vncserver file in /etc/xinetd.d, so check that file closely.

Client is not authorized to connect error

If you see something like the error below, it indicates that you need to create the Xn.hosts file as referenced above. Create the file with the number indicated in the display: piece of the error. In the case below, it'd be X0.hosts file that needs to be created. You'll have to log out and back in for this change to take place (or do an init 3, init 5).

Xlib: connection to ":0.0" refused by serverXlib: server.example.com is not authorized to connect to serverError: can't open display: :0

Blank Screen after Login

If you run into a blank (usually background-colored) screen after entering your username and password, this indicates some Gnome (XWindows) session data has gotten corrupted. The easiest way to test this is to try logging in as another user. If you can do so without getting this error, here's how to fix it:

1. Delete all files and directories beloning to the affected user in /tmp. You can focus that a little more by first deleting any file/directories that appear with the name "gnome" or "X" in them. After doing this, try logging in again. It probably will work.
2. If #1 doesn't get things going, you may also have to delete the following files and directories from the user's home directory (typically /home/username):

.esd_auth	.gconfd	.gnome2_private	.nautilus
.dmrc	.gconf	.gnome-desktop	.metacity
.fonts.cache*	.gnome	.gnome2
.ICEauthority	.gtkrc*

Gray screen only

A gray screen with no login prompt probably means you forgot to edit the desktop file at the top. It also could be an error in the gdm.conf file. Take a look at the gdm.conf (or custom.conf) file that you edited at the top and make sure the remote (or xdmcp) greeter in the [daemon] section is blank or commented out.

DBus Problems - DROM Access Denied

If you receive a message stating something like this:

A security policy in place prevents this sender from sending this message to this recipient, see message bus configuration file (rejected message had interface “org.freedesktop.Hal.Device.Volume” member “Mount” error name “(unset)” destination “org.freedesktop.Hal”)

Then you've run into this problem. The problem is corrected by adding the following lines to the end of /etc/dbus-1/system.d/hal.conf:

<policy group=" users=">
<allow send_interface="org.freedesktop.Hal.Device.SystemPowerManagement" />
<allow send_interface="org.freedesktop.Hal.Device.VideoAdapterPM" />
<allow send_interface="org.freedesktop.Hal.Device.LaptopPanel" />
<allow send_interface="org.freedesktop.Hal.Device.Volume" />
<allow send_interface="org.freedesktop.Hal.Device.Volume.Crypto" />
</policy>