Installing FreeNX on OpenSuSE 11.4

After reading an article in one of my favourite computer magazines about FreeNX and NoMashine’s NX I was very interested to get this to work. Also, google are using NX for some developers-and if a technology is good enough for google than it can only be good enough for me as well.

Unfortunately there wasn’t an awful lot of documentation around for openSuSE 11.4 but by making best use of search engines I finally got it to work. Again, this is looking rather trivial in the post but was a lot of work finding out! Now here’s what I did.

Installing FreeNX

I found the RPMs for FreeNX in the standard SuSE repositories, but there are probably newer builds to be found here:

It seems to be sufficient to install these packages on the server:

#  rpm -qa|grep -i nx

Instead of a post-install action as part of the RPM installation you have to take action to configure the nx server. First, you need to create this directory tree if you haven’t got cups installed on the server (FreeNX makes use of CUPS for printer sharing).

# mkdir -p /usr/lib64/cups/backend/ipp

Now you should be able to run the configuration. One thing you will notice is a prompt to generate a SSH key. I would suggest you let it generate the key rather than using the very well-known NoMachine key. Since FreeNX relies on SSH to get access to the box it’s quite secure, theoretically. The key generated during the installation will be used to authenticate client sessions. Here is the output from the configuration session on my host with some detail removed:

nxhost:~ # nxsetup --install  --clean --purge
------> It is recommended that you use the NoMachine key for
easier setup. If you answer "y", FreeNX creates a custom
KeyPair and expects you to setup your clients manually.
"N" is default and uses the NoMachine key for installation.

Do you want to use your own custom KeyPair? [y/N] y
Removing special user "nx" crontab for nx
Removing session database ...done
Removing logfile ...done
Removing home directory of special user "nx" ...done
Removing configuration files ...done
Setting up /etc/nxserver ...done
Generating public/private dsa key pair.
Your identification has been saved in /etc/nxserver/users.id_dsa.
Your public key has been saved in /etc/nxserver/
The key fingerprint is:
f0:70:91:36:ed:asdsadsadsadsad9:21:7e:d1:9a root@nxhost
The key's randomart image is:
+--[ DSA 1024]----+
|o+.. o  .o       |
|                 |
Setting up /var/lib/nxserver/db ...done
Setting up /var/log/nxserver.log ...done
Setting up special user "nx" ...done
Adding user "nx" to group "utmp" ...done
Setting up known_hosts and authorized_keys2 ...Unique key generated; your users must install


on their computers.
Setting up permissions ...done
Setting up cups nxipp backend ...done

----> Testing your nxserver configuration ...
Warning: Invalid value "COMMAND_FOOMATIC=/usr/lib64/cups/driver/foomatic-ppdfile"
Users will not be able to use foomatic.
Warning: "/usr/lib64/cups/backend/smb" is not executable.
Users will not be able to enable printing.
Warning: Invalid value "CUPS_ETC=/etc/cups/"
Users will not be able to enable printing.
Warning: Invalid value "COMMAND_START_KDE=startkde"
Users will not be able to request a KDE session.
Warning: Invalid value "COMMAND_START_CDE=cdwm"
Users will not be able to request a CDE session.
Warning: Invalid value "COMMAND_SMBMOUNT=smbmount". You'll not be able to use SAMBA.
Warning: Invalid value "COMMAND_SMBUMOUNT=smbumount". You'll not be able to use SAMBA.
Warning: Invalid cupsd version of "/usr/sbin/cupsd". Need version 1.2.
Users will not be able to enable printing.

Warnings occured during config check.
To enable these features please correct the configuration file.

<---- done

----> Testing your nxserver connection ...
HELLO NXSERVER - Version 2.1.0-72 OS (GPL, using backend: 3.4.0)
<--- done

Ok, nxserver is ready.

PAM authentication enabled:
All users will be able to login with their normal passwords.

PAM authentication will be done through SSH.
Please ensure that SSHD on localhost accepts password authentication.

You can change this behaviour in the /etc/nxserver/node.conf file.

Warning: Clients will not be able to login to this server with the standard key.
Please replace /usr/NX/share/client.id_dsa.key on all clients you want
to use with /var/lib/nxserver/home/.ssh/client.id_dsa.key
and protect it accordingly.

Since 1.5.0 you need to import the correct key via the GUI.

If you really want to use the NoMachine key please remove
and then run this script with the --setup-nomachine-key parameter.
Have Fun!

Now this looked promising! If problems are reported at this stage they are usually a) related to missing CUPS and b) due to sshd not listening at

Configuring the node

All configuration work is done in /etc/nxserver/node.conf. I had to experiment quite a while to get this right and more or less secure. All users I allow in (really myself!) have to authenticate via username and password. I haven’t moved the SSH port to <> 22 but secured SSH so that I can only get in with a key file or openVPN. That should be enough I think, and except for a number of boring VMs for Oracle RAC there isn’t anything on the box anyway. To add users to the NX database, you can use these commands:

nxserver --adduser username
nxserver --passwd username

Replace username with the real username (obviously). Oh and you need to ensure that the keys are in authorized_keys2 in sshd_config such as shown here:

# grep authorized_keys2 /etc/ssh/sshd_config
AuthorizedKeysFile     .ssh/authorized_keys2

It’s a good idea a this point to rename any $HOME/.ssh/authorized_keys file to $HOME/.ssh/authorized_keys2 and test that you can get in before continuing. Whenever a change is made to the sshd_config, you need to reload the SSH daemon to make them active.

Next, edit node.conf and set these variables (some might need commenting out)

  • NX_LOGFILE=/var/log/nxserver.log

Refer to the comments right above the variable for their meaning. The last 4 variables only need to be set temorarily for debugging. Note that this is only an example for authentication, other uses might be more appropriate for you-this one just worked.

To allow SU authentication, the nx user must be in group “users”. The easiest way to do so is via yast, but a usermod does the same. I have run into a rather nasty problem initially related to fonts. From the client log file I got this output:

# cat

NXAGENT - Version 3.4.0

Copyright (C) 2001, 2010 NoMachine.
See for more information.

Info: Agent running with pid '16169'.
Session: Starting session at 'Thu Nov  3 16:17:26 2011'.
Info: Proxy running in server mode with pid '16169'.
Info: Waiting for connection from '' on port '5001'.
Info: Accepted connection from ''.
Warning: Connected to remote version 3.5.0 with local version 3.4.0.
Warning: Consider checking for updates.
Info: Connection with remote proxy completed.
Info: Using ADSL link parameters 512/24/1/0.
Info: Using agent parameters 5000/10/50/0/0.
Info: Using cache parameters 4/4096KB/16384KB/16384KB.
Info: Using pack method 'adaptive-7' with session 'unix-gnome'.
Info: Using ZLIB data compression 1/1/32.
Info: Using ZLIB stream compression 4/4.
Info: No suitable cache file found.
Info: Listening to X11 connections on display ':1001'.
Info: Established X client connection.
Info: Using shared memory parameters 1/1/1/4096K.
Info: Using alpha channel in render extension.
Info: Not using local device configuration changes.
Error: Aborting session with 'Could not open default font 'fixed''.
Session: Aborting session at 'Thu Nov  3 16:17:28 2011'.
Session: Session aborted at 'Thu Nov  3 16:17:28 2011'.
Warning: Signals were not blocked in process with pid '16169'.
Info: Watchdog running with pid '16186'.
Info: Waiting the watchdog process to complete.
xrdb: Connection refused
xrdb: Can't open display ':1001'

It appeared to me that the problem was related to the “fixed” font package. I could solve this only by trial and eror, until I found the terminus-font package, installed it and got running. I think I could have installed the nx client on the server as well as it seems to have gone through it’s installation directories but didn’t have to in the end. The SuSE SDB entry for FreeNX recommends the following permission change:

# chown nx /var/lib/nxserver

I can’t comment on the other items in “Setting up things” from, I haven’t set up any of these and didn’t run into problems.

Installing and configuring the client

I tried the qtnx client but it repeatedly failed on me so reverted back to the official 3.5 client from the nomachine website. This works as a treat and is available for all major platforms, including deb and rpm packages. The client is installed in /usr/NX/-and this is the reason I went for FreeNX, as it adheres more to the LSB.

One thing to remember is to get the key you generated during the nxerver setup and copy it into your client session-otherwise you will never be able to connect to your host. You need to copy everything in BEGIN … to … END (including these lines) from the key (/var/lib/nxserver/home/.ssh/client.id_dsa.key) into the key field accessible in the general settings once the wizard completed. I don’t want to reproduce the client setup here, a good introduction is found in reference [4].

Before hitting the “connect” button I suggest that you tail -f /var/log/nxserver to troubleshoot the connection. Item [3] in the reference sections answers a number of FAQs around the troubleshooting, and I also found other distribution’s documentation (like ubuntu) very useful. FreeNX really is distribution agnostic which in this case is great.

I ran into a problem where gnome wasn’t installed correctly on my NX server, a call to zypper to install the gnome pattern solved the problem. I was truly amazed with the usability of the software, it was great fun working with it.


When you have been able to create sessions without any problems, change the log level for NX server to 0 or 1set session_log_clean to 1 again to avoid your hard disk from filling up with log information you are not interested in anyway.