Installing FreeNX on Fedora Core 2.

Remote Connectivity

Tested on Fedora Core 2 server and Windows XP client

Date Submitted: June 9, 2005

I recently read an article on linuxjournal.com regarding FreeNX and it really piqued my interest. I've tried to run GUI programs from my home server via ssh before and it's painfully slow. The article unabashedly praised FreeNX's speed, so I figured to give it a shot.

Of course, there were no FC2 binaries available on the apt repositories I use, but that didn't deter me. There were source RPMs available on the net. I found mine on Fedora News, on a fine article by Rick Stout.

This is what I did:

Getting It

First, I downloaded the SPRMs to my favorite SRPM download directory on my home server.

$ wget http://fedoranews.org/contributors/rick_stout/freenx/freenx-0.4.0-0.rh.1.src.rpm
$ wget http://fedoranews.org/contributors/rick_stout/freenx/nx-1.4.0-0.rh.4.src.rpm
(as user, of course, because that's just the way I do things.)

Unfortunately, that didn't work out as planned. For whatever reason, the SRPMs need to be built as root. Now, I could've poured through the spec files and found out why and wherefore, but it was easy enough just to su to root and execute the rpmbuild --rebuild command as follows:

# rpmbuild --rebuild nx-1.4.0-0.rh.4.src.rpm
# rpmbuild --rebuild freenx-0.4.0-0.rh.1.src.rpm

Installing it on the Server (and client)

Well, that was easy enough, 'til I tried installing them and failed. The RPMs depended on XFree86. Now you and I know that FC2 came with Xorg, not XFree86, so I was back to square one. Turns out I grabbed the wrong SRPMs. I needed the .fdr SRPMs. They're here:

$ wget http://fedoranews.org/contributors/rick_stout/freenx/freenx-0.4.0-0.fdr.1.src.rpm
$ wget http://fedoranews.org/contributors/rick_stout/freenx/nx-1.4.0-0.fdr.4.src.rpm

OK, that said, I didn't realize I'd grabbed the wrong SRPMs 'til I started writing this SxS. What I actually did was install the FC3 RPMs as follows:

# rpm -ivh http://fedoranews.org/contributors/rick_stout/freenx/nx-1.4.0-0.fdr.4.i386.rpm
# rpm -ivh http://fedoranews.org/contributors/rick_stout/freenx/freenx-0.4.0-0.fdr.1.noarch.rpm
(that's right, RPMs don't need to be local in order to install them).

and they happened to work swimmingly.

Next, I needed to install a FreeNX client. Fortunately, NoMachine.com offers a Free Version.
I just downloaded the Windows binary install and installed it.

The Key to Connecting

Because FreeNX uses ssh to handle the connection securely, the client needs to have a key to access the server. That key is installed here:

/var/lib/nxserver/home/.ssh/client.id_dsa.key

Just copy that key to the C:\Program Files\NX Client for Windows\share directory on Windows.

It's Not So Simple

Ordinarily, given an already working ssh setup (which I had), connecting using FreeNX is as easy as following the instructions in the Wizard. Unfortunately, I outsmarted myself once again. I've edited my /etc/ssh/sshd_config file to restrict access using AllowUsers setting. If you do this, you need to allow for the user nx to connect. You also need to allow your own user code to connect from localhost (127.0.0.1). Otherwise, you won't be able to connect.
I had:

AllowUsers <my user>@<work IP address> *@10.0.0.*

and had to change it to:

AllowUsers <my user>@<work IP address> <my user>@127.0.0.1 *@10.0.0.* nx

You know, replacing the above with what makes sense.

How's it work?

Well, the difference between running an X app through plain old ssh and FreeNX is night and day. While it's painful to run KMail over an ordinary ssh link, it was perfectly usable running my entire KDE desktop remotely via FreeNX. All the flower praise in the Linux Journal article is well deserved, in my opinion. Don't believe me? Try it. You'll see.
For grins, I put up a screenshot of FreeNX in action. You can find it here.

Still undiscovered

What I'm still looking for a way to do, is to configure the FreeNX client to access multiple servers. That would require multiple keys. Unfortunately, the client I'm using expects a single specific filename for the key. Sure, you can work around that by copying and renaming keys, but that's hardly elegant.