[FrontPage] [TitleIndex] [WordIndex

This is a read-only archived version of wiki.centos.org

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

[INFO]

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


opennx2.png


opennx3.png



opennx5.png


opennx6.png opennx7.png


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.


nxclient1new.jpg


nxclient2new.jpg


nxclient3new.jpg


nxclient4new.jpg nxclient5new.jpg


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.


2023-09-11 07:22