NX server using FreeNX

NX and FreeNX server are only available for CentOS-4 and CentOS-5 i386

NX is a Terminal Server and Remote Access solution based on a comprising set of 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, and the integration with the powerful audio, printing and resource sharing capabilities of the Unix world, NX makes it possible to run any graphical application on any operating system across any network connection as if you were sitting in front of your CentOS computer.

When making a connection, you have the server computer (the computer you will connect to and open the desktop from) and the client computer (the computer you are using to make the connection to the server).

1. Installing NX /FreeNX on the server

Currently there is a version of nx and freenx in the CentOS Extras repository.

To install the stable version of NX / FreeNX server, issue this command from the server:

yum install nx freenx

There _MAY_ also be a test version of NX / FreeNX in the Testing repository.

Look at the testing links below to see if there are newer RPMS in testing, and setup the testing repository if there are files you wat to try from there. After setting up the testing repository, you can install via the command (from your server machine):

yum --enablerepo c4-testing install nx freenx

(you can replace c4 with c5 if you are using the c5 testing repo)

You may also download the RPMS manually from:

Stable

http://mirror.centos.org/centos/4/extras/i386/RPMS/

http://mirror.centos.org/centos/5/extras/i386/RPMS/

Testing

http://dev.centos.org/centos/4/testing/i386/RPMS/

http://dev.centos.org/centos/5/testing/i386/RPMS/

and the Source RPMS from:

Stable

http://mirror.centos.org/centos/4/extras/SRPMS/

http://mirror.centos.org/centos/5/extras/SRPMS/

Testing

http://dev.centos.org/centos/4/testing/SRPMS/

http://dev.centos.org/centos/5/testing/SRPMS/

Note: There are sometimes issues that require the No Machine Client to also be installed on your NX server. If you are having issues like 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 machine. These issues are much less prevalent in versions of NX > 3 and freenx > 0.7.

2. Key-based authentication

[Note: This section is optional although it is recommended that key-based authentication be implemented.]

Copy a minimal config file for nxserver :

cd /etc/nxserver ; cp node.conf.sample node.conf

If your machine is connected to the wild Internet you'll probably want to disallow ssh password authentication (which is advised but not mandatory). Edit the /etc/ssh/sshd_config and change/add the following lines :

PasswordAuthentication no
        AllowUsers nx 

Don't forget to restart the sshd daemon after that

service sshd restart

By default, if you try to connect to the NX server, it will use the nx account for the ssh connection (with key authentication), but it will try also to connect in ssh with your own username/password to the host you're trying to reach. Because we've disabled the PasswordAuthentication (adviced method), we have to use the NX Database to allow pass-through authentication : be sure that /etc/nxserver/node.conf contains the following line :

ENABLE_PASSDB_AUTHENTICATION="1"

Then create yourself a posix account (with useradd/passwd if not already done) Add this newly created user to the nxserver db :

nxserver --adduser myuser
NX> 100 NXSERVER - Version 1.5.0-60 OS (GPL)
NX> 1000 NXNODE - Version 1.5.0-60 OS (GPL)
NX> 716 Public key added to: /home/myuser/.ssh/authorized_keys2
NX> 1001 Bye.
NX> 999 Bye

Assign a password for this user :

nxserver --passwd myuser
NX> 100 NXSERVER - Version 1.5.0-60 OS (GPL)
New password:
Password changed.
NX> 999 Bye

! Don't forget to add this newly user on the AllowUsers line in sshd_config and reload sshd (service sshd reload)

[End of the key-based authentication setup]


3. Installing the NoMachine Client

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.1.x and 3.0.x versions of the Nomachine clients have been tested and seem to work OK with the CentOS supplied FreeNX/NX solution. If you are having problems, here is a link to the latest 2.1.0 i386 client from no machine, which also does work.

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.



Note: On newer NX clients (> 3.0.0), the check box is to disable SSL traffic, so do not check the box in that case if you want SSL encryption





4. Troubleshooting

There seem to be problems with connecting the current NX client for Windows to the current (0.5.0-8) NX-Server 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:

http://www.centos.org/modules/newbb/viewtopic.php?topic_id=14363&forum=38

5. Misc Notes

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 to do that for Gnome is to run this command :

yum groupinstall 'GNOME Desktop Environment' '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.

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.).

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.

HowTos/FreeNX (last edited 2008-08-08 20:29:34 by AkemiYagi)