NoMachine Support

Your questions answered

Knowledge Base

Searching in: Articles & FAQs
Filter the search results
Applies to:
Last update:
Searching in: Articles & FAQs
ID: AR11O00943
Applies to: NoMachine Software
Added on: 2017-11-08
Last update: 2020-12-16
How to use NoMachine v. 6 or later to access legacy unix-based systems (Foreign X Servers)

Starting from version 6, NoMachine Cloud Server permits to create multi-level infrastructures with a single access point - the Cloud Server - to multiple hosts running a NoMachine server or not. In this last case, we speak about Foreign X Servers (previously called Foreign nodes in v. 5), which are Unix-like workstations or servers with an X Window System (i.e. a graphical user interface based on X) but without NoMachine installed. They can be for example Solaris, HP-UX, AIX, BSD hosts etc for which a NoMachine server or node package is not available.

Adding (or 'federating') a Foreign X Server under a Cloud Server can be done via the GUI (a) or via the command line (b).


Pre-requisites to integrate a Foreign X Server into a NoMachine multi-server environment

Pre-requisites to federate a Foreign X server to a NoMachine Cloud Server are:

1. A Unix-based operating system is running on the Foreign X Server host, e.g. Solaris X86 , HP-UX, AIX, BSD etc ...
2. An X server is up and running on the Foreign X Server host.
3. The X server listens for TCP connections.
4. A desktop environment (e.g. GNOME) is installed on the Foreign X Server host.
5. A system account is present for each user who will need to log-in from remote to the Foreign X Server.
6. The xauth command is installed on the Foreign X Server host.
7. The .Xauthority file for the user specified at point 5. contains the cookie that is valid for accessing the X server. This may be confirmed by using xauth tool.
Run from a console the following command: xauth -ni list

8. 'Login as a guest' is not supported on Foreign X Servers.

Key points about accessing Foreign X Servers with NoMachine

a Only connections to the physical desktop are possible on Foreign X Servers.
b. Sessions on Foreign X Servers cannot be load-balanced.

c. Connections to Foreign X Servers must use the SSH protocol.

d. Client connection is forwarded from the Cloud Server to the Foreign X Server with the tunnel method, which means that the traffic is relayed through the parent server.


How to add a Foreign X Server to the Cloud Server via UI (a)

In order to be able to add a server via UI you need to be either a system administrator on the Cloud Server host, or a NoMachine administrator.

To add a NoMachine administrator, run from a console on the Cloud Server host:

nxserver --useradd <username> --administrator yes

This command assumes that the account already exists on the system, run the same command with the --system option if the system account doesn't exists yet.


Then log-in as administrator from the client GUI to the Cloud Server and choose 'New server' for entering the panel to add a server.

For a step-by-step tutorial:


How to add a Foreign X Server to the Cloud Server via command line (b)

To add a Foreign X Server, use the 'nxserver --serveradd' command on the Cloud Server host and specify the '--foreign' option:

nxserver --serveradd <foreign server IP or hostname> --foreign

For further options, please refer to the Cloud Server - Installation and Configuration Guide .



Troubleshooting: the most common reasons why connections to the Foreign X Server host are not  possible

- Verify that all pre-requisites listed above are met.

- Regarding the X server, consider that on some operating systems the X server is started with the '-nolisten tcp' . If this is the case, restart the X server after enabling TCP listening (please refer to the official documentation of your distribution).

- Connections to the Foreign X Server are no longer possible when the fingerprint on the Foreign X Server is changed.

In this case, run on the NoMachine Cloud Server host the following command, accept the new fingerprint and add it to the known_hosts file:

nxserver ---serverupdate <server:port> | <uuid> [--strict-host-key-checking yes|no]

- Regarding the X server authorization cookie, bear in mind that it should be in a format recognizable by the operating system of the server host machine. For example, if the cookie is in the 'hostname/unix:display' format, the system must be able to resolve the hostname to the correspondent IP address.

- The target machine needs to be accessible from the main server.

For example if xauth returns:

username@Sandwitch-Ubuntu-15:~$ xauth -ni list
Sandwitch-Ubuntu-15/unix:0  MIT-MAGIC-COOKIE-1 d5a6a07f068ad1be5543df72ef046994

the main server must be able to resolve the "Sandwitch-Ubuntu-15" hostname. The check that, run on the main server:

ssh username@Sandwitch-Ubuntu-15

If an error is returned, for example "ssh: Could not resolve hostname sandwitch-ubuntu-15: Name or service not known", It is necessary to ensure that the main server is able to resolve the target hostname. This can be done by enabling DNS hostname resolving or by adding hostname-IP translation in /etc/hosts (not recommended when the IP may change often).