Author: Rob Reilly
NX had some advantages over the alternatives. I thought about using the Linux Terminal Server Project (LTSP) and straight SSH, but they give the user a remote desktop or command line, and my desktop had to be visible to the networked user. VNC and x0rfbserver were also obvious choices. They provided the right functionality but weren’t very strong on security. I’d also have had to open various ports on my firewall, posing potential security problems.
The NoMachine system has two modes of operation. One mode allows a user to display a desktop (such as KDE) locally from a remote Linux machine, much like the LTSP. The user has a KDE desktop on his local machine, served by the NX Server. The other mode lets a user see another user’s desktop(who happens to be on the NX Server machine) using VNC functionality. The NoMachine system adds compression and a wrapper of security around the whole data stream.
I downloaded the evaluation version of the server from the NoMachine Web site. The company offers personal, business, and enterprise-level server evaluation programs for various flavors of Linux and Solaris. The client is available for Windows, Linux, Mac OS X, and Solaris. While NoMachine has released the core NX technology under the GPL, the NX server is a commercial product and can be purchased online. NoMachine also has support packages available.
I downloaded the standard client (about 1MB) and the personal server version (about 6MB). I also downloaded a Windows version to run on my clanky old Windows 98 desktop. I planned to put the client software on the two desktop machines for a speed comparison. The NoMachine server would reside on my AMD Athlon 64 Linux laptop.
Installation tricks
The Linux client installed with a simple rpm -ivh filename. The Windows client installed with a simple .exe file. Putting the NX Server program on my Athlon 64/SUSE 9.3 Linux laptop was a different story.
At the start of this project, I downloaded and tried to install both the personal and small business versions. The program key apparently works with only one version at a time. I chased my tail for a few hours before figuring out how to remove the first server package I installed (small business) and getting the one that matched the key (personal) working right. Moral of the story: carefully pick which version you want to try and install only that one. NoMachine does provide a complete guide to installing the NX server software.
Then there was the problem of trying to run the server from the command line as root. If you just type nxserver from the command line, you’ll receive an error. You need to type the entire string /usr/NX/bin/nxserver. You must also set your server’s (in my case, the my Athlon 64 laptop) software firewall to allow SSH connections. For WAN access I also opened SSH on my IPCop firewall and established a connection right to my NX Server machine.
On the NX Client side, you should check the SSL encryption box on the Advanced tab so that it will work going through the firewall.
Before you can log in from a client, you’ll need a Linux username and password set up on the NX Server machine, and also a username and password in the NX Server database. It’s best to just make the NX Server username and password the same as the Linux username and password (on the NX Server machine). You can add those with the commands:
root# /usr/NX/bin/nxserver --adduser
androot# /usr/NX/bin/nxserver --passwd
Logging in and letting it rip
My evaluation server machine was an Athlon 64 laptop with 1GB of memory, an 80GB drive, Broadcom 802.11b/g chip, and RealTec 100 Mbps NIC. The system was running 64-bit SUSE 9.3 Linux in a configuration suitable for personal or small business use.
I used two machines for the clients. Both were ancient 133MHz Pentium desktop machines with 128MB of memory and 3GB disks. The Windows machine had a D-Link 802.11b card and ran Windows 98. The Linux client had a generic 100Mbps NIC and was running SUSE 9.3 Linux.
My most successful test was connecting to the server via the wired NIC on the Linux client. To start the client I logged in as a regular user and typed nxclient at the command line. Users can change any necessary parameters, such as the NXerver IP address and desktop choice.
Once the client information is set, it’s a simple matter of logging in with the username and password. You may have to answer “yes” to an SSH prompt; the connection runs through the SSH port (22) and tunnels all of its traffic.
The performance over my wired LAN was quite acceptable. The KDE desktop opened in about 15 seconds and without problems. I never experienced a crash or any odd behavior. Screen repaints were slightly noticable, which wasn’t bad, considering the limited capabilities of the client machine.
I also wanted to see if I could break the client KDE desktop. Throwing caution to the wind, I started a vintage 1998 Windows version of DesignCad Pro 2000 under Wine on my Athlon 64 NX Server machine. Although I only experimented with a few 3-D spheres, several planes, and some lines, the application was quite responsive. I was able to render the surfaces and the result showed up quickly and without a hitch, over my LAN between the NoMachine client and server.
While the performance across a wired connection was good, my worst test came when I connected to the server wirelessly via 802.11b on a Windows client. The Windows installation put a little NX startup icon on my desktop. After logging into the Athlon NX Server, KDE took about a minute to load. Screen repaints sometimes took up to a minute and a half to complete.
I also managed to crash the NX Client application once with an “Illegal Operation” error. I couldn’t tell whether it was the NX Client or Windows 98 that was at fault.
Overall, the NX Server worked well when I accessed it from an older Linux desktop with a fast connection to the server. With a sufficiently powerful server machine, I think most users would be satisfied with the performance and response.
Out into the wild
Next, I enlisted the help of a colleague, who succeeded in starting up a remote KDE desktop over the Internet. He said the speed was acceptable. While we were not able to get a VNC session going over the Internet, I was able to connect by going from my LAN out to my Internet-facing firewall IP address. Both the NX Server (Athlon laptop) and my Linux desktop were behind my IPCop firewall. I ran x0rfbserver on the NX Server machine to stream the screens. You have to really pay attention to the host names, usernames, and passwords. My NX username and password were different from the VNC username and password. Make sure you put the right ones in the right spots in the NX Client screens.
On the NX-VNC settings screen make sure that you’re pointing at the NX Server/VNC box’s internal LAN IP address, such as 192.168.5.19 and not the Internet-facing firewall IP. Don’t forget that the firewall IP address equals the server host address, under the General tab on the main NX Client config screen.
Wrapup
The NX Server/NX Client combination worked fine behind my firewall. It also worked going out of, and then back into, my firewall through my ISP-provided Internet connection. It may take a little time to get everything working if you aren’t familiar with setting up firewalls, remote desktops, and VNC configurations.
The NX Server and NX Client programs are available for free evaluation before you buy. If you need a remote desktop or secure VNC session, you should give NoMachine a try.
Rob Reilly is a consultant, writer, and commentator who advises clients on business and technology projects. His Linux, personal branding, and public speaking skills-related articles regularly appear in various high-end Linux and business media outlets.
