Replacments for NX and FreeNX

The NX server provides a secure connection between the server and client, and seems much faster than the more commonly used VNC. However, the newer nxclient seems to be somewhat unpopular. Many, including myself, found that it didn't work as desired. In addition, I think that FreeNX has become old and unmaintained. Therefore, I began looking for substitutions. If you like NX, that's fine, there's still a CentOS wiki article and one of its authors is active on CentOS forums. I think, but am not sure, however, that the article still refers to the older, and in my admittedly biased opinion, better, nxclient.

X2go

The closest replacement I've found is x2go. On CentOS 6.x, one installs the x2goserver and x2go-xession rpms. There is no need to configure anything or even to start the service. Once these two are installed, X doesn't even have to be running. On the client machine, install x2goclient, and when you wish to connect, open it.

Click the Session menu, and a dialog opens. Give it a name. Then, fill in the host and login. The default ssh port is 22, you can change that if you wish. There is also an option to use an RSA/DSA key if desired. Next is session type. The default is KDE, I think, but there are several options, including Windows Terminal Server. There is also an option for a single application (I haven't used that, for that I use xpra, described below), and custom. Personally, I find that openbox is convenient for me. I choose custom and for the command I use /usr/bin/openbox-session. On the right of the application, you should now see your session. You can click it, or on the right, where it says Session:, enter the name after the colon. (Tab completion should work once you hit the first letter or two of the session name). Hit enter and you should see a dialog box describing the session, giving the username (Login) that you defined when first setting up the session and asking for a password. Put in the password, and after a few moments another dialog opens giving status. You also first see a black screen saying X2go on it and then your session should open up.

As mentioned I use openbox rather than my preferred dwm tilling window manager, because keyboard shortcuts don't work for me in an x2go session. Once I've opened a terminal or browser in the session, it accepts keyboard input, but if I have, for example, a keyboard shortcut of Mod4+t to open a terminal and hit it in the session, it doesn't work. If I have the same keyboard shortcut locally, it will open a terminal on the local machine rather than the remote session, otherwise, it just has no effect.

When done with my remote session, when I was using CentOS-6.x, I ccould right click on the openbox desktop session and choose Logout. This would close the session.

With CentOS-7.x, when I clicked logout, it no longer completely closed the session. Once I did that, the session was unresponsive, but if I close x2go, then try to log in again, while I see a desktop, it is completely unresponsive to keyboard and mouse.

To work around this, , before ending a session, I first list /tmp/.X11-unix, which almost always shows that I have an X0 and an X50 session. X50 is the x2go session.

Run fuser /tmp/.X11-unix/X50 and get the PID for the session. Kill it by PID, which closes the session, then close the x2goclient. So before closing a session, I run
fuser /tmp/.X11-unix/X50

This gives me back a number, e.g., 15730. I then run
kill 15730

This kills the session.

Another issue I ran into was firefox, or sometimes palemoon, freezing up. Some googling brought me to this page on thescriptingadminblogspot.com site. The author mentioned that they had had a similar problem and fixed it by unchecking audio support. As I don't use it for audio, disabling it wasn't a problem for me.

xpra

Using xpra might be useful when only opening one application. I haven't found it as convenient as x2go but it's fairly simple to set up and use. Most systems have a package or port for it. It will pull in various dependencies. Again, you shouldn't need to have X running, and you will be using a non-used display. Generally, all you should have to do, assuming that xpra is installed on the remote host is first start a session on the server, then attach with the client. On the server
xpra start :100 

You can then start the desired application.
DISPLAY=:100 firefox

Or do it in one shot
xpra start :100 --start-child=firefox

Now, on the client
xpra attach ssh:myusername@myremotehost:100

You should now have a remote firefox session. As I've said, this hasn't been all that reliable for me yet but I haven't used it that often. Their main page has a Get started section. It has a link to a another section with usage examples. The ArchLinux wiki also has an article. The reader may find it more reliable, perhaps depending upon their systems, than I have.

If using a non-standard ssh port, you can define it on the client with
xpra --ssh="ssh -p 1222" attach ssh:myusername@myremotehost:100

In theory, one can then disconnect with ctl+c, then reconnect with the attach command again.
xpra attach ssh:myusername@myremotehost:100

but this hasn't always worked properly for me.

I tend to use x2go, as I've had various issues with xpra, but I haven't done any serious investigation. For example, sometimes I can't reattach to an xpra session, or after killing it, I can no longer use that dispay. I haven't spent much effort in trying to solve this though. So, though I tend to prefer x2go over xpra, either or both may suit the reader's needs.

Samuel Leathers was kind enough to drop me a line, mentioning that if you run xpra start and any commands within tmux or screen (or using nohup) you can easily detach and reattach xpra sessions at will. Thanks Samuel. :)