NX server using FreeNX
<<TableOfContents: execution failed [Argument "maxdepth" must be an integer value, not "[1]"] (see also the log)>>
NX is a Terminal Server and Remote Access solution based on enterprise class open source technologies by NoMachine. Thanks to the outstanding compression, session resilience and resource management developed on top of the X-Window system, along with the integration of powerful resource sharing capabilities, printing and audio of the Linux / Unix world, NX makes it possible to run any graphical application across any network connection as if you were sitting in front of your CentOS (server) computer.
When making a connection, you have the server computer (the computer to which you will connect & upon which you will open the desktop) and the client computer (the computer from which you will make the connection to the server).
1. Installing NX / FreeNX on the server
Currently there is a version of NX and FreeNX in the EPEL + nux-dextop repositories for CentOS 6.
First, install both repositories:
[root@server ~]# rpm -Uvh https://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm [root@server ~]# rpm -Uvh http://li.nux.ro/download/nux/dextop/el6/x86_64/nux-dextop-release-0-2.el6.nux.noarch.rpm
To install the stable version of NX / FreeNX, issue this command from the server:
[root@server ~]# yum install freenx-server nxagent
A number of other packages will be installed for dependency.
Note: Sometimes, there are issues that require the No Machine Client to also be installed on your NX server. If you are having issues such as the inability to close the client, please download the latest No Machine Linux Client RPM (see the Linux link below) and install it on your NX server. These issues are much less prevalent in the current versions of NX ( i.e NX > 3 and freenx > 0.7. ) |
2. Setup
NX uses the ssh protocol to connect to the remote service. If you use a key-based authentication, you need to add your username to the NX userlist as follows:
Ensure that /etc/nxserver/node.conf file contains the following line (make sure that the line is not commented out) :
ENABLE_PASSDB_AUTHENTICATION="1"
Add yourself to the nxserver database. Suppose your username is bob, run this command as the root user:
[root@server ~]# /usr/libexec/nx/nxserver --adduser bob
Which should give you something similar to :
NX> 100 NXSERVER - Version 3.2.0-74-SVN OS (GPL, using backend: not detected) NX> 1000 NXNODE - Version 3.2.0-74-SVN OS (GPL, using backend: not detected) NX> 716 Public key added to: /home/bob/.ssh/authorized_keys2 NX> 1001 Bye. NX> 999 Bye
When the above command was run for the first time, you may see a message, "No such file or directory". This is expected, not a problem.
Assign a password for bob:
[root@server ~]# /usr/libexec/nx/nxserver --passwd bob
And this should output something like this, asking for the password only once:
NX> 100 NXSERVER - Version 3.2.0-74-SVN OS (GPL, using backend: not detected) New password: Password changed. NX> 999 Bye
Check the /etc/ssh/sshd_config file. If you have previously defined AllowUsers, then you'd need to add users nx and bob to that line :
AllowUsers nx bob
That's it, all done. Your remote machine is now ready to accept NX clients for your login.
3. Installing the NX Client
You can install either opennx or nxclient from NoMachine. |
3.1. Installation of opennx
Note: If you have already installed NoMachine's nxclient, you need to uninstall it before installing opennx. Existing setup for the clients should become available to opennx. |
Opennx is available for CentOS-6 from the centos-extras repository. To install it, issue this command on the client machine:
[root@client ~]# yum install opennx
Open the NX Connection Wizard. Enter a Session name, a hostname (or ip address), a Port number and select your Type of Internet Connection and select Next.
Select the connection type, the desktop system you want to use, and the size of the desktop. Select Next when finished.
In the next dialog window, make sure "Enable SSL encryption of all traffic" is checked and then select Next.
Choose if you want to Create shortcut on desktop and then Select Show the Advanced Configuration dialog box and then select Finish.
In the advanced dialog window under the General Tab, you should see the items you have already entered and a Key... button. You will need to ssh into the server which you are trying to connect and go to the /etc/nxserver/ directory and open the file client.id_dsa.key (you must be the root user to open this file). Copy all the text (including the BEGIN DSA PRIVATE KEY and END DSA PRIVATE KEY lines. Press the Key... button, delete the text that is in there, and paste the client.id_dsa.key information from the server into the Key Management text box, then select Save. You will be back in the Session properties dialog box. Select OK and you are all set.
- You should now be able to connect to the Server machine and open your desktop from the client.
3.2. Installation of NoMachine's nxclient
NoMachine does not allow the distribution of their client, so it must be downloaded from their website. There are clients for Linux, Mac OSX, Solaris, and Windows.
Note: The 3.5.x, 3.1.x and 3.0.x versions of the Nomachine clients work fine with the CentOS supplied FreeNX/NX solution. |
Pick the client for your OS and install it on your OS per the instructions on the No Machine site, then use the below instructions to connect to your NX server.
Open the NX Connection Wizard. Enter a Session name, a hostname (or ip address), a Port number and select your Type of Internet Connection and select Next.
Select the connection type, the desktop system you want to use, and the size of the desktop. Do not check the disable encryption box if you want SSL encryption. If you use SSL, not only is the traffic encrypted, but it uses only the SSL port you list to make the connection. This means only the SSL port needs to be open to inbound traffic if you are connecting from outside a firewall. Select Next when finished.
Choose if you want to Create shortcut on desktop and then Select Show the Advanced Configuration dialog box and then select Finish.
In the advanced dialog window under the General Tab, you should see the items you have already entered and a Key... button. You will need to ssh into the server which you are trying to connect and go to the /etc/nxserver/ directory and open the file client.id_dsa.key (you must be the root user to open this file). Copy all the text (including the BEGIN DSA PRIVATE KEY and END DSA PRIVATE KEY lines. Press the Key... button, delete the text that is in there, and paste the client.id_dsa.key information from the server into the Key Management text box, then select Save.
You should now be able to connect to the Server machine and open your desktop from the client. Please see NoMachine Support for more information.
4. Troubleshooting
There seem to be problems with connecting the current NX client for Windows to the NX-Server (version 0.5.0-8) in CentOS. This problem seems to be known as the "backingstore" problem.
This issue is now fixed in the 0.5.0-9 version (or greater) of the CentOS package. Which can be found in the Extras Repository. It should no longer be an issue, however we will leave the information as a reference for people still using the older versions.
From the FreeNX-FAQ:
Backingstore problem:
Thorsten Sandfuchs found some issues concerning backingstore. Problem arouse as you try to connect to a 0.5.0 installation with no 2.0.0 backend support and a 2.0.0-client. As Nomachine changed the behaviour of the backingstore-option. In 1.5.0-clients the client sends "always, when_requested" et all and freenx just passed this string to the nxagent-call. The new client now sends "backingstore=1" and the 1.5.0-nxagent issues a warning and an error with "no argument requiered for -bs" or with "Error: NX Agent exited with exit status 1.". You can read all his message here: Backingstore or 2.0.0-client and 1.5.0 backend and freenx-0.5
Look at nxnode and in function 'node_start_agent()' after this line
[ -n "$backingstore" ] && B="-bs $backingstore"
add these lines:
# backingstore = { "when_requested", "always", ... } [ -n "$backingstore" -a "$ENABLE_2_0_0_BACKEND" != "1" -a "$backingstore" != "1" ] && B="-bs $backingstore" # backingstore = 1 (new nxclient 2.0.0 doesn't send any strings in the option-string for backingstore anymore) [ -n "$backingstore" -a "$ENABLE_2_0_0_BACKEND" != "1" -a "$backingstore" = "1" ] && B="+bs" # backingstore = 1 and 2.0.0-Backend EXPERIMENTAL [ -n "$backingstore" -a "$ENABLE_2_0_0_BACKEND" = "1" ] && B="-bs $backingstore"
This works using nxclient version 2.0.0-98.
--Predseda3D 15:12 Aug 2, 2006 (BST)
Heavy (100%) CPU load on Windows Vista NX Client:
Some users have reported heavy (100%) CPU loads on the NoMachine NX Windows client when running on Windows Vista. Disabling DirectDraw in the NX client is reported to fix the problem. See here for a discussion: https://www.centos.org/forums/viewtopic.php?t=19396
$HOSTNAME in $DISPLAY:
If the $DISPLAY value contains a hostname like "myhost:1000.0" , then running xhost + will fail:
$ xhost + xhost: unable to open display "myhost:1000.0"
Solution: Edit /etc/nxserver/node.conf and change the line:
#AGENT_EXTRA_OPTIONS_X="-nolisten tcp"
to:
AGENT_EXTRA_OPTIONS_X=""
https://www.centos.org/forums/viewtopic.php?t=16677
Connection failure:
If nx connection fails at the very end and just sits there, look in your home directory on the server. Remove all .Xauthority* files (or move them somewhere else) and try again. If that does not do the job, also try removing /tmp/.X11-unix.
ESXi5/VMTools and FreeNX:
When installing CentOS6.x on a ESXi5 host, after installing the VMTools it is possible that the NX-Session refuses to work anymore. The desktop does pop up, but the busy circle stays on screen indefinitely. According to NoMachine this is a bug in the VMTools build 8.6.0. See this link for a solution.
Updating C6 with FreeNX to a ESXi5 Host:
Updating the VMTools of virtual machines runing C6 from ESX4 to ESXi5 may also cause problems running the GNOME-Desktop. Again the desktop does pop up, but the busy circle stays on screen indefinitely. It seems removing the VMTools of ESX4 does not restore vmwlegacy_drv.so correctly. Creating the following symbolic link solves the problem:
On x64:
ln -s /usr/lib64/xorg/modules/drivers/vmwlegacy_drv.so.old.0 /usr/lib64/xorg/modules/drivers/vmwlegacy_drv.so
On i386:
ln -s /usr/lib/xorg/modules/drivers/vmwlegacy_drv.so.old.0 /usr/lib/xorg/modules/drivers/vmwlegacy_drv.so
5. Misc Notes
GUI Considerations
If you are installing FreeNX on a remote server, you will also need to install a Desktop environment on the machine in order to run the remote session. An easy way to do that for Gnome is to run this command :
CentOS 5:
yum groupinstall 'GNOME Desktop Environment' 'X Window System'
CentOS 6:
yum groupinstall 'Desktop' 'X Window System'
Note: If you are running CentOS 5, yum groupinstall "GNOME Desktop Environment" may complain about a missing libgaim.so.0. This is a known bug. Please see CentOS-5 FAQ for details.
You will also need to install the relevant fonts and make sure the font service is running ( on CentOS 5 )
SSH Considerations
The information below is for CentOS 5.x. On later versions of CentOS 6.x do NOT do this, it can make the machine unreachable by ssh.
FreeNX expects to make an ssh connection at 127.0.0.1, i.e., at the local host address. If you haven't changed your default sshd_config, the sshd daemon will be available at that IP address.
However, if you have modified the ListenAddress lines in /etc/ssh/sshd_config, this can cause a problem. Make sure that sshd is available at 127.0.0.1. This can be checked with
netstat -an |grep 22
The result should be similar to
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 :::22 0.0.0.0:* LISTEN
(The above assumes that you use the default port 22 for ssh connections.) This output indicates that sshd is listening on all addresses.
For various reasons, people sometimes modify sshd_config to listen on a specific address. If you see something like
tcp 192.168.1.20:22 0.0.0.0:* LISTEN
it means the sshd is only listening for connections at the address of 192.168.1.20. This will cause FreeNX connections to fail when they try to connect at 127.0.0.1
To fix this, add another ListenAddress line to /etc/ssh/sshd_config. It should read
ListenAddress 127.0.0.1
(It should be on a separate line from any other ListenAddress entries.)
If remotely connected, use the screen command. You are about to restart sshd which will disconnect a remote ssh session. (There are other ways to restart the sshd daemon without disconnecting yourself, but screen is one of the easiest ones. If it is not installed, install it first using "yum install screen".)
screen
This should give you a command prompt. Restart sshd.
/etc/init.d/sshd restart
Use netstat -an again to check that it is now listening at 127.0.0.1.
netstat -an
You should now see something like
tcp 192.168.1.20:22 0.0.0.0:* LISTEN tcp 127.0.0.1:22 0.0.0.0:* LISTEN
FreeNX will now be able to connect.
To repeat, the step of adding a listen address of 127.0.0.1 should only be an issue with CentOS 5.x. DO NOT do it with CentOS 6.x
Also remember, (for all versions of CentOS), if you use AllowUsers in sshd_config, or any other access control system to manage who can login to the machine, make sure that you add the 'nx' user to that list.
Downloading FreeNX rpms without yum
You may also download the RPMS from:
CentOS5: i386 : http://mirror.centos.org/centos/5/extras/i386/RPMS/ x86_64 : http://mirror.centos.org/centos/5/extras/x86_64/RPMS/
CentOS6: i386: http://mirror.centos.org/centos/6/extras/i386/Packages/ x86_64: http://mirror.centos.org/centos/6/extras/x86_64/Packages/
Another option for accessing KVM guests
If you are connecting to a QEMU virtual machine (KVM guest), you can use spice as detailed in Spice-libvirt.