technovelty

weblog of Ian Wienand

RSS  |  technovelty home  |  page of ian  |  ian@wienand.org

NoMachine NX - the missing non-manual

I've been meaning to try NoMachine NX for a while. Its promise of fast remote X11 sessions sounded exactly like what I wanted to log into my work desktop remotely (I really like having a remote desktop with saved state you can just pick up from when using remote access). That was pretty much all I knew about the software, so I was a completely blank slate.

The getting started guide is the perfect example of how not to write a getting started guide.

Firstly, Section 1 - "Getting started" - gives me a full history of the product, goes into significant depth about the challenges of forwarding X11 requests, talks about the caching and compression implementation, round-trip latency measurement, the details of two-way proxying system and discusses every other feature of the software.

My eyes glazed over after about the first paragraph. That's all great -- I just want to know what to do!

At this point, I assume that I'm required to run some sort of daemon at the remote end. I download and install the server package (it is explained that the server package requires the client and agent packages as well, fine).

I'm paging down, looking for something to get me started. I'm happy to see Section 7 - "Set up your NX Server environment" (remember, at this point I though I needed some daemon running in the background constantly). It even has some commands commands to type, so I tap away, running nxserver --useradd nxtest --system. My server binary doesn't even seem to recognise these options. I give up, assuming that the server isn't running and nothing will work. The getting started guide has abruptly ended and I have no idea what to do.

As it turns out, it's all completely trivial. Here's the missing "getting started guide".

Additional tips:

Other than the documentation, it really works as promised, making remote X11 usable. One really nice feature is that it is smart about the resolution of the remote desktop, filling up your local screen. Add to that you don't need anything setup but your normal ssh connection, and it's a great remote desktop solution.

posted at: Wed, 04 Feb 2009 15:10 | in /linux/tips | permalink | add comment (11 others)

Posted by alex at Fri Feb 6 03:21:00 2009

Cool! I don't want to sound like a zealot, but are those packages OSS? I've toyed around with the packages in main but I've never gotten them to work.

But using those packages I've been able to run an ultrasmooth xterm from my Windows box at work, and run a few very-usable X11 apps.

I hope we can apt-get this goodness soon :)

Posted by Mick T. at Fri Feb 6 04:39:05 2009

The packages from NX at http://www.nomachine.com/ aren't OSS, it's a commercial product. There are FreeNX packages available, see the Wiki page at:
http://wiki.debian.org/freenx

Either way, NX is a great tool. And I've been able to to use it to connect to and run my home desktop (on a slow DSL line) from remote locations.

Mick

Posted by Djadala at Fri Feb 13 03:16:20 2009

does any know, using NX, how to run single remote  application, not DE (like 'ssh -X user@remote application') ?

Djadala

Posted by Paul D at Fri Feb 20 15:37:45 2009

Thanks so much for this; I've struggled with NX's terrible documentation in the past, and gave up. Now, I finally have it working.

Cheers,

Paul.

Posted by Alex at Mon Jun 22 02:47:52 2009

Hello, do u understand this technology?

I can't understand, what NX Nodes are!!!
The Server, is where your Terminal, which you are sitting at, while you remote controling some PC.

The Client, is the PC that is beeing remote controlled somewhere, through LAN or Internet. Client is (normally) separated by physicall space from you, and your controll station.

What are Nodes in the sheme?

Posted by -O-uknow at Sun Jul 12 01:58:35 2009

There is an association between node and server. Only one node per server with the free edition. Client is where you are sitting. The Server is the box sending the remote display that you control. The node in the client must be able to communicate and authenticate with the remote server for it all to work.

Posted by -O-uknow at Sun Jul 12 02:22:44 2009

Download from <a href="http://www.nomachine.com/select-package.php?os=linux&id=1">http://www.nomachine.com/select-package.php?os=linux&id=1</a> and install the client, agent and server packages on both ends.
******************************************************************************
A.Files you will need to config. Files beginning with "." are hidden.
******************************************************************************
1./usr/NX/etc/node.cfg (configure using node sample)
2./usr/NX/etc/server.cfg (configure using server sample)
3./usr/NX/etc/keys/node.localhost.id_dsa.pub = client's /tmp/node.localhost.id_dsa.pub
4./tmp/node.localhost.id_dsa.pub = server's /usr/NX/etc/keys/node.localhost.id_dsa.pub
5./etc/ssh = ssh keys (put in clients known hosts file)
6./home/(name)/.ssh/known_hosts = server address key files (exam. localhost key file)
7./home/(name)/.ssh/authorized_keys2 = client and server's ssh dss key files ending with root@(name)
8./usr/NX/share/keys/server.id_dsa.key = connection key file (client/host must match)
9./usr/NX/home/nx/.ssh/authorized_keys2 = clients rsa and dsa private and public keys from /etc/ssh
10./usr/NX/home/nx/.ssh/known_hosts = server's /etc/ssh keys
11./usr/NX/home/nx/.ssh/default.id_dsa.pub = same as /usr/NX/home/nx/.ssh/authorized_keys2

Getting the Node to Authenticate the Server

The NX Server public DSA Key must be added to the node to allow this server to connect to the node running on the remote host. Please note that in the current implementation, each node can be associated only to one server.

Copy the server public DSA key on the node host, for example:

# scp /usr/NX/etc/keys/node.localhost.id_dsa.pub root@node_host:/tmp


The general form of the command to add the server public DSA key is:

nxnode --keyadd KEY

KEY is the path to the server public DSA key.

For example:

nxnode --keyadd  /tmp/node.localhost.id_dsa.pub

Add user

nxserver --useradd (name) --system --administrator

B.Add server IP address to client network and vice versa also open media ports in firewall.

Posted by John Watts at Fri Sep 11 13:10:40 2009

Sorry I just found this post now.

Server = traffic cop
Node = heavy lifter or where user sessions are run

In the bulk of our product range, NX Free Edition, Enterprise Desktop Server, Small Business Server, Enterprise Server both Server and Node exist on the same box.

In our Advanced Server line we break that relationship apart.  Now you have a Adv. Svr. which is the traffic cop while you have machines behind it that provide the heavy-lifting "full session" capability.

The Adv. Server becomes the "brain" if you will while the Nodes become the "arms/legs" of the scenario.

/John

Posted by Carlie Coats at Thu Nov 11 03:45:20 2010

DUMB QUESTION:
I currently script non-NX access to a lot of remote hosts (using ssh authorized-key access) via a script that takes host and user as command-line arguments, and basically executes

  xterm <stuff> -e "ssh -X user@host" &

--which cleanly goes as a menu-item on my window-manager's window system, giving me "two-click" access to an X-enabled xterm logged on to any of about 70 "user@host" combinations.

Can I script this sort of thing (using nxssh?), or am I always going to have to go through the (non-scriptable) GUI route?

Posted by Lifeboy at Fri Feb 25 18:21:26 2011

The point you make under Additional Tips:
Do something like /usr/NX/bin/nxssh -o 'Compression=no' -L 2022:remote.host:22 -f -N user@sshgateway.company.com

I don't get this working and nxssh manpage is non-existent.  I get the =o and -L parts, but what does -f and -N do.

I want to do connect from client a.com via machine b.com to server c.com which has a nx server installed.  a.com is the client.  b.com only has sshd running but no X server.

Posted by BitterFan at Thu Aug 11 05:05:07 2011

I am totally appreciative of this tutorial, and it is much better than the standard one from NoMachine. I think it is ironic, though, that this document expresses frustration about the way NoMachine's document starts out with irrelevant history about the growing pains of making their product. This very article suffers the exact same issue! This article claims that NoMachine's article is a bad example of a tech guide, and in doing so, suffers the exact same problems with NoMachine that it is complaining about. I just found it amusing and very recursive.

Add a comment
*Name
*Email (not shown)
Website
*Comment:
Anti-spam:
* denotes required field

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 2.5 License.