Table of Contents

Introduction

1. NoMachine Cloud Server Installation and Configuration Guide

1.1. About This Guide

How to set-up the Cloud Server

2. Install the Cloud Server

2.1. Prerequisites

2.2. Windows Installations

2.3. Mac Installations

2.4. Linux Installations

2.5. RPM Packages

2.6. DEB Packages

2.7. TAR.GZ Packages

2.8. Installing the License (for Customers)

Building a Scalable Multi-tier Infrastructure with Centralized Access to Remote Hosts

3. Use the Cloud Server to Provide a Single Point of Access to Remote Computers

3.1. Adding NoMachine Servers as Nodes of the Cloud Server

3.2. Creating Multiple Levels of NoMachine Servers

3.3. Advanced Configurations for Multiple Levels of NoMachine Servers

3.4. Using the 'token' Forwarding Method for Client Connections by SSH (Advanced)

3.5. Adding 'Foreign X Servers' to the Cloud Server

3.6. Assigning Users to a Specific Node (optional)

3.7. Assigning Users to a Group of Nodes (optional)

3.8. Assigning Users to the First Available Enterprise Desktop

3.9. Propagating Profile Rules from the Cloud Server to the Nodes (optional)

3.10. Setting-up a Failover Cluster with a Second Cloud Server for High Availability (optional)

3.11. Tuning the Failover Cluster Parameters

3.12. Administering the Failover Cluster

Connect to the Cloud Server

4. Initiating a NoMachine Connection (end-user's side)

4.1. Connecting by Browsers Via Cloud Server Web Tools

4.2. Connecting by NoMachine Client

4.3. Preventing Users from Storing their Credentials

Configurations and Optimizations for Web Sessions

5. Configuring NoMachine Cloud Server

5.1. Configuring Web Sessions

5.2. Managing Cloud Server Web Services

5.3. Using an Alternative Apache Web Server

5.4. Web Optimizations: Using WebRTC (Real-Time Web Communication)

Cloud Server Administration

6. Cloud Server Configuration

6.1. Configuration Files

7. Services Management

7.1. Accepting Connections

7.2. Stopping and Starting Cloud Server and Services

7.3. Stopping and Starting Network Services

7.4. Handling with Discovering of this Server on LAN

8. Users Management

8.1. Managing Users on the Cloud Server Host

8.2. Managing Groups of Users

8.3. Special Users with Permisssion to connect to the Cloud Server Physical Desktop

8.4. Guest Users (Automatic Generation of System Accounts)

8.5. Profile rules

9. Updates

9.1. Updating Cloud Server and Nodes (v. 7)

9.2. Automatic Updates

9.3. Upgrading from v. 6 to v. 7.2 or Later

10. Logging Facilities

Introduction 1. NoMachine Cloud Server Installation and Configuration Guide Welcome to the NoMachine Cloud Server - Installation and Configuration Guide v. 7.2 or later. What is NoMachine Cloud Server for? NoMachine Cloud Server works as a single point of access to multiple subsystems globally distributed and running NoMachine server installations or Unix-like operating systems for which we don't build a native package ('Foreign X Servers'). It can create a scalable infrastructure with multi-level nodes. Available for Linux, Mac and Windows, the Cloud Server provides access to its nodes, (previously called 'child servers') via a browser (thanks to its built-in web server) or via NoMachine client. TIP The Cloud Server is not intended for providing access to desktops on his host machine. Only specific users are allowed to connect to the physical desktop of the Cloud Server, mainly for maintenance or administrative operations on this host. Building your centralized NoMachine architecture NoMachine Cloud Server is fully operative once installation is completed. Then add your node(s) to the Cloud Server. These nodes can be: - Any of the standalone NoMachine servers like Enterprise Desktop, Workstation, Small Business Server and Terminal Server. - A NoMachine Enterprise Terminal Server which in turn manages a multi-node environment made of NoMachine Terminal Server Nodes. - Another NoMachine Cloud Server which in turns rules its own nodes (multi-level infrastructure). - A Foreign X Server, i.e. a Unix-like host running an unsupported O.S. for which we don't build native packages. NoMachine servers added to the main Cloud Server are first-level nodes. High-Availability Two NoMachine Cloud Servers can be set-up in a high-availability failover cluster (active/passive cluster) to grant continuous access availability to the nodes. A Graphical Interface The Cloud Server package includes the NoMachine User Interface which provides the graphical interface (Server Settings) for administering the server and its services. Most common operations detailed in this guide can be performed by the NoMachine UI and the Server settings panel running on the local installation of the server. The Cloud Server comes also with a client UI for running sessions and connecting to other remote NoMachine servers. The same UI can be used also to add, modify and remove nodes. How to manage the server from the graphical tools: https://www.nomachine.com/DT11R00180 How to add nodes to the Cloud Server via UI: https://www.nomachine.com/adding-servers-to-nomachine-cloud-server-via-the-user-interface 1.1. About This Guide Document Conventions and Important Notices The following conventions are used in this guide: BaseDirectory is the base directory where the NoMachine binaries and libraries are installed. By default, BaseDirectory is: /usr on Linux, C:\'Program files (x86)' on 64bit systems and 'C:\Program file' on 32bits machines and /Applications on Mac. InstallationDirectory is: BaseDirectory/NX on Linux, BaseDirectory/NoMachine on Windows and BaseDirectory/NoMachine.app on Mac. The command line interface NoMachine server and node programs have a command line interface to execute operations. You need to be a privileged system user to access all these functionalities. Run these commands from an xterm or similar on Linux and macOS using the sudo utility or as root. On Windows, run them from a command prompt (cmd.exe) executed as administrator. On Linux and Mac, invoke the 'nxserver' and 'nxnode' programs from /etc/NX, for example: $ /etc/NX/nxserver --help $ /etc/NX/nxnode --help on Windows open a CMD console as administrator, then move to the 'NoMachine' installation directory, by default it's under C:\'Program files (x86)' on 64bit systems and 'C:\Program file' on 32bits machines and go to the 'bin' subdirectory to execute the command: > cd C:\PROGRA~1 C:\Program Files (x86)> cd NoMachine\bin C:\Program Files (x86)\NoMachine\bin>nxserver --help C:\Program Files (x86)\NoMachine\bin>nxnode --help The 'nxserver --help' and 'nxnode --help' display the list of all the available commands and options and their description. Online Resources Visit the NoMachine Support Area to access a variety of online resources included the NoMachine Forums, tutorials and FAQs: https://www.nomachine.com/support Find a list of all documents and tutorials for v. 7: https://www.nomachine.com/all-documents Use the Knowledge Base search engine to access articles, FAQs and self-help information: https://kb.nomachine.com Leave Feedback About This Guide Our goal is to provide comprehensive and clear documentation for all NoMachine products. If you would like to send us your comments and suggestions, you can use the contact tool available at https://www.nomachine.com/contact-request, selecting Web Quality Feedback as your option. 2. How to Set-up the Cloud Sever 2.1. Install the Cloud Server Supported Operating Systems Windows 32-bit/64-bit XP/Vista/7/8/8.1/10 Windows Server 2008/2012/2016/2019 Mac OS X Intel 64-bit 10.7 to 10.15 Linux 32-bit and 64-bit RHEL 4 to RHEL 8 SLED 10 to SLED 15 SLES 10 to SLES 15 openSUSE 10.x to openSUSE 15.x Mandriva 2009 to Mandriva 2011 Fedora 10 to Fedora 33 Debian 4.0 to Debian 10 Ubuntu 8.04 to Ubuntu 20.10 Hardware requirements Intel Core2 Duo or AMD Athlon Dual-Core or equivalent 1 GB RAM Network connection (either a LAN, or Internet link: broadband, cable, DSL, etc...) Size required on disk: Windows 210 MB Linux 195 MB Mac 180 MB Software requirements Cloud Server v. 7 cannot connect to nodes v. 6, message 'Invalid version' will be displayed. Be sure to update the nodes before upgrading the Cloud Server. Instructions are provided at Chapter 9. Updates. Even if server-client compatibility with version 6 and 5 is preserved, it's preferable to use NoMachine client v. 7 to connect to Cloud Server v. 7. In order to connect by NoMachine to the physical desktop of a Linux Cloud Server host, a desktop environment must already be installed. This applies also to headless Linux machines. 2.2. Windows Installations INSTALL Download the package for Windows from the NoMachine web site and install it by double-clicking on the icon of the executable: a setup wizard will take you through the installation. Accept to reboot the machine, this is mandatory for completing the installation. If you own a customer license we recommend to download the package from your Customer Area: https://www.nomachine.com/support#login. TIP To install the package in silent or very silent mode from a CMD console, run respectively: >nomachine-packageName_packageVersion.exe /silent or: >nomachine-packageName_packageVersion.exe /verysilent Then reboot the machine: >SHUTDOWN -r -t 10 -c " your comments here" To specify a non-default installation directory, use: >nomachine-packageName_packageVersion.exe /SILENT /DIR="X:Target_directory" or: >nomachine-packageName_packageVersion.exe /VERYSILENT /DIR="X:Target_directory" Note for Windows XP: the NoMachine server will not start until the machine is rebooted. UPDATE The update procedure for server and node installations requires to stop all NoMachine services in order to correctly replace libraries and binaries. While updating the Cloud Server, users will be not able to access the nodes. Users can connect later to recover their sessions on any of the nodes. There are two ways to update your current installation: I Automatic updates You can update your installation from our repositories. Just run the NoMachine UI from your Programs Menu and access the Server -> Settings -> Updates panel and click on the 'Check now' button NoMachine has the automatic check for updates enabled: it will check by default our repositories every two days to verify if updates are available. In this case, the server will prompt a dialog informing that a new version is available but it will never automatically update the current installation. Checking for updates can be disabled from that dialog by selecting the 'Don't ask again for this version' option or in the Updates panel by unchecking the 'Automatically check for updates' option. Detailed instructions for configuring the Automatic Updates are available in a separate document in the 'Configuration' section at: https://www.nomachine.com/all-documents . II Update with NoMachine packages Alternatively, download the latest available package from the NoMachine web site and click on the executable file to launch Setup. As for the installation, Setup will guide you through all steps necessary for updating your installation. If you own a customer license we recommend to download the package from your Customer Area: https://www.nomachine.com/support#login. UNINSTALL You can uninstall NoMachine Cloud Server from the Windows Control Panel and the 'Add or Remove Programs' in Windows XP or 'Program and Features' in Windows Vista, 7, 8 or 10. Find the NoMachine program in the list of installed programs and choose to uninstall it. On Windows 8 or later you can use the Search box from the Charms bar on the right side of the screen: type Control Panel to open it. Then access the Programs - 'Uninstall a program' panel. On Windows 7, Vista and XP, click on the Start button and click to open the Control panel from the Start menu. Then access panel 'Programs and Features' or 'Add or Remove Programs', depending on your Windows version. Reboot is mandatory to complete the uninstalling process. TIP To uninstall from a CMD console, move to C:/ProgramData/NoMachine/var/uninstall/ (if you are on Vista/7/8/10) or to C:/Documents and Settings/All Users/NoMachine/var/uninstall/ (if you are on XP). Then run: > unins000.exe /silent or: > unins000.exe /verysilent Uninstalling is completed when your command prompt is back. Then, your computer will restart automatically.

INSTALL
Download the DMG package from the NoMachine web site. Double-click on the disk Image to open it and see the package icon. Then double-click on the package icon to install the program: the installer will take you through the installation.

If you own a customer license we recommend to download the package from your Customer Area: https://www.nomachine.com/support#login.

TIP

To install from the command line, run:

$ NXMOUNTDIR=$(echo `hdiutil mount nomachine-cloud-server_version.dmg | tail -1 | awk '{$1=$2=""; print $0}'` | xargs -0 echo) $ sudo installer -pkg "${NXMOUNTDIR}/NoMachine.pkg" -target /

UPDATE
The update procedure for server and node installations requires to stop all NoMachine services in order to correctly replace libraries and binaries. The update procedure for server and node installations requires to stop all NoMachine services in order to correctly replace libraries and binaries. While updating the Cloud Server, users will be not able to access the nodes. Users can connect later to recover their sessions on any of the nodes.

There are two ways to update your current installation:

UNINSTALL
To uninstall the Cloud Server drag and drop NoMachine from Applications to trash or select 'Move to trash' from the mouse button menu. This will uninstall all the NoMachine software.

TIP

To uninstall from command line, it's enough you remove the NoMachine application directory:

$ sudo rm -rf /Applications/NoMachine.app

Installing for the first time
You can install, update and uninstall using the graphical package manager of your Linux distribution or from command line by running commands from an xterm or similar with the sudo utility, or as root user if you don't have sudo installed. Instructions below refer to installation by command line.

If you own a customer license we recommend to download the package from your Customer Area: https://www.nomachine.com/support#login.

Successive updates
The update procedure for server and node installations requires to stop all NoMachine services in order to correctly replace libraries and binaries. This implies that all running sessions are terminated during the update procedure and cannot be recovered later. This applies to updates made by using NoMachine packages and to automatic updates from NoMachine repositories.

There are two ways to update your current installation:

If you want to install to default location, namely /usr/NX/:

INSTALL

UPDATE

UNINSTALL

TIP

For non-default locations, for example /opt/NX:

INSTALL # rpm -ivh <pkgName>_<pkgVersion>_<arch>.rpm --prefix /opt UPDATE # rpm -Uvh <pkgName>_<pkgVersion>_<arch>.rpm --prefix /opt UNINSTALL # rpm -e nomachine-cloud-server

If you want to install to default location, namely /usr/NX/:

INSTALL

UPDATE

UNINSTALL

TIP

For non-default locations, for example /opt/NX:

INSTALL $ sudo NX_INSTALL_PREFIX=/opt dpkg -i <pkgName>_<pkgVersion>_<arch>.deb UPDATE $ sudo NX_INSTALL_PREFIX=/opt dpkg -i <pkgName>_<pkgVersion>_<arch>.deb UNINSTALL $ sudo dpkg -r nomachine-cloud-server

If you want to install to default location, namely /usr/NX/, ensure that package is placed there.

INSTALL

UPDATE

UNINSTALL

TIP

For non-default locations, for example /opt/NX:

INSTALL $ sudo NX_INSTALL_PREFIX=/opt /usr/NX/nxserver --install UPDATE $ sudo NX_INSTALL_PREFIX=/opt /usr/NX/nxserver --update UNINSTALL $ sudo /opt/NX/scripts/setup/nxserver --uninstall $ sudo rm -rf /opt/NX

Customers' packages
include a temporary (30 days) node.lic and server.lic files for evaluation.
Such license files have to be replaced with the customer's license files acquired from NoMachine. This can be done via the NoMachine UI in Settings -> Server -> Updates panel: click on 'Server subscription' and 'Node subscription' to read the current license file. Click on 'Replace' button to activate a new license file. You will be requested to log-in with a privileged account (administrator).

TIP

Starting from version 7, the server will cease to work once the license is expired. Please contact your NoMachine provider or the Support Team for license renewal options.

To verify from command line that server.lic and node.lic are correctly in place and check their validity, you may run the nxserver/nxnode --subscription and --version commands. On Linux and macOS:

on Windows, open a CMD console as administrator and:

NoMachine Cloud Server allows to centralize the access to server subsystems, which are independent and globally located. These subsystems can be NoMachine servers or the so called 'Foreign X Servers', i.e. Unix servers which offer SSH connectivity and a X-windows based environment but don't have the NoMachine software installed on.

The Cloud Server, we can call it the main server, can add a new server (node) to the multi-host infrastructure at any moment and without business discontinuity.

For practical cases, included setup instructions, and most common questions please consult to the following article: https://www.nomachine.com/AR05R01090

One of the most common scenarios, suitable for example for Universities or companies smartworking, is to use the Cloud Server to provide access to computers running the Enterprise Desktop so that users can have access to their desktops, as if they are sit in front of that computer.

Nevertheless, whichever kind of server (except NoMachine free) can be added to the Cloud Server, e.g. the Workstation or the Terminal Server.

It's also possible to add multiple NoMachine Cloud Servers to the main server, building in this way a multi-level infrastructure (hierarchy) for more complex architectures. The main server is the top-level server which rules the whole hierarchy, the other Cloud Servers are multi-tier subsystems, which in turn can be parent servers of other nodes.

We call first-level nodes those servers that are directly added to the main Cloud Server, second-level nodes are added to first-level nodes and so on. All servers are structured in a hierarchy. Servers' hierarchies can be built from the main Cloud Server.

This is an example of multi-level hierarchical infrastructure, which includes also Foreign X Servers. Note that the main Cloud Server is in failover cluster with a second Cloud Server to grant high available access to the system:

How to add a NoMachine server to the main Cloud Server
Nodes can be added to the Cloud Server in two ways: via (i) the NoMachine UI or (ii) from command line in a console opened on the Cloud Server host.

To add nodes via NoMachine UI: refer to the step-by-step tutorial here: https://www.nomachine.com/adding-servers-to-nomachine-cloud-server-via-the-user-interface. Note that you will have to log-in with an account that is a 'NoMachine administrator'.

Default settings will suffice for the majority of environments. It is possible to configure extra details, always via the UI.

Server's commands explained in the next sections correspond to the same configuration options available in the UI.

TIP

A NoMachine administrator is a valid account on the Cloud Server (CS) host having special rights for NoMachine. Being a NoMachine administrator doesn't affect system privileges of that user. To assign such NoMachine privileges to a system user, execute on the CS host:

nxserver --useredit USERNAME --administrator yes

As an alternative to the UI, it's possible to add the node also from command line.

On the main Cloud Server host, execute the 'nxserver --serveradd' command to add a NoMachine server as a node, you need to be a system privileged user for doing that:

Once the node is added, it is assigned with a unique string identifier (UUID). Use it to identify the node and, when necessary, its parent when executing commands to manage it.

You can also add a Cloud Server under the main Cloud Server and add a node to it.

To add a node to a sub-level Cloud Server, you need to know the UUID of this sub-level Cloud Server. The general format of the command, to be executed on the main Cloud Server is:

How to build a multi-level infrastructure is however dealt in detail in the paragraph dedicated to creating multiple levels of NoMachine servers.

TIP

Server commands to operate on first-level servers (edit, remove etc ...) can be run by specifying the node name in the SERVER:PORT format or its UUID. When nodes are not first-level nodes, it's necessary to provide their UUID and also the UUID of their parent. In practice the command action would look like:perform this operation on node XXX which parent UUID is... The uuid of the parent is always specified by the --target option.

By default the node is added with the following settings which are suitable for most cases.

1) Connection between this Cloud Server and its node uses the NX protocol on port 4000.

2) NoMachine clients' connections by NX protocol are forwarded to the Cloud Server nodes on port 4000. Starting from v. 7.2, the connection is forwarded by default with the tunnel method, which means that the traffic is relayed through the Cloud Server with the protocol specified for the Cloud Server-to-node communication.

If the client can connect directly to the node, because they are part of the same LAN or VPN, administrators can set token as alternative method. In this way, the client authenticates to the node with an OTP (One Time Password) token which uniquely identifies that client.

Forwarding method system is also supported, which means that the client will be authenticated to the node by using the same credentials already used for authenticating it on the Cloud Server.

Use option: --forward-nx-methods to specify the forward method while adding the node (nxserver --serveradd ) or by editing it later (nxserver --servereedit )

3) NoMachine clients' connections by SSH protocol are forwarded to the Cloud Server nodes on port 22. Starting from v. 7.2, the connection is forwarded by default with the tunnel method, which means that the traffic is relayed through the Cloud Server with the protocol specified for the Cloud Server-to-node communication.

If the client can connect directly to the node, because they are part of the same LAN or VPN, administrators can set system as alternative method.

For client's SSH connections, OTP token is supported on Mac/Linux Cloud Server and nodes, but it requires to manually configure the system.

Use option: --forward-ssh-methods to specify the forward method while adding the node (nxserver --serveradd ) or by editing it later (nxserver --servereedit )

4) Users cannot connect directly to the IP or hostname of the node, i.e. direct access to NoMachine server installed on the node is disabled. This is the default since v. 7.2.

5) Once connected to the main Cloud Server, users can manually select to which node connect. The UI can list first-level nodes or all levels.

TIP

Default behaviours listed above can be modified by setting the necessary parameter(s). For sake of clarity they are treated separately but multiple custom configurations can be specified on the same command line while executing 'nxserver --serveradd'. Some of these parameters can be changed later via the 'nxserver --serveredit' command.

Setting protocol and port for Cloud Server-to-node communication

Some examples for Linux or macOS:

Qualifying the node with a label and/or a comment
Label is a short string (max 80 chars) that can be used to qualify the node for identifying it in a more userfriendly way. Label is shown to end-users. Comment is a longer text (max 1024 chars) that is not shown to end-users but it's visible to administrators in the output of the 'nxserver --serverlist' command. The general format of the command to add the node and specify label and comment is:

Listing the nodes
To list all first-level nodes of the Cloud Server:

Changing settings
In order to change settings for any of the nodes, use the following command:

Removing a node

Stopping/starting a node
Stopping any of the nodes means that it will no longer accept new connections. Current connections will stay running.

Allow direct connections to the nodes
Since v. 7.2, by default the node doesn't accept connections to its IP. To allow users connecting directly to the node, you can enable direct access:

How to remove a node from the list of nodes displayed to users
By default all nodes are available for the manual selection and are listed in the client UI once users are connected to the main Cloud Server. The All servers/Child servers switch in the UI allows to show all nodes or only the first-level ones. To hide a node from the list presented to users, disable the manual selection option for the given node:

The node with 'manual selection' disabled is not listed among the available node in the client UI. You then need to assign users to the node by means of 'nxserver --useradd' or 'nxserver --useredit' commands if you want to let users access it.

There are two ways for adding nodes to a sub-level Cloud Server:

A practical example for building a multi-level infrastructure from command line
Let's assume to have the following three NoMachine server installations:
Cloud Server 1, CS1
Cloud Server 2, CS2
Enterprise Desktop, ED.
CS1 is the main server which will rule the whole infrastructure, we want to add CS2 to CS1 and ED to CS2.

The same server can be a node of more than one Cloud Servers. For example, let's say that we have a fourth NoMachine server, Workstation WS, and that we want to add it to both CS1 and CS2:

TIP

Server commands to operate on first-level nodes (edit, remove etc ...) can be run by specifying the node name in the SERVER:PORT format or its UUID. When nodes are not first-level nodes, it's necessary to provide their UUID and also the UUID of their parent. In practice the command action would look like:perform this operation on node XXX which parent UUID is... The uuid of the parent is always specified by the --target option.

Default settings for Cloud Server-to-node communication are suitable in most cases. In some environments, howewer, it may be necessary to apply custom settings, for example for forwarding the connection on a specific network interface and/or port.

Setting how client connections have to be routed to the node
Since v. 7.2, client connections are always forwarded with the tunnel method to the nodes. Alternative methods are possible only when the client can connect to the node, e.g. it's in the same LAN or VPN.

The alternative forward methods are 'token' and 'system'. Note that a comma-separated list of methods is accepted, they are executed in a positional order.

TIPS
I	The --forward-nx-methods and --forward-ssh-methods options accept a single value or a comma-separated list of values. Values are positional, i.e. the first item in the list is also the first method attempted. Accepted values are: token system tunnel
II	A manual configuration is necessary to use the token forwarding method for client connections by SSH protocol.

Some examples for Linux or macOS

Forwarding client connections to the node on a specific network interface and port
When the client connection is not tunneled, it's possible to specify the network interface and port to be used for the client-node connection. This can be useful when the server host has multiple NICs and you prefer to have a separate network for Cloud Server and client connections.

TIP

In case of non-first level nodes and Foreign X Servers, client connections are always tunneled.

The token forwarding method for client connections by NX protocol is the default method and doesn't require any additional system configuration. NoMachine provides a built-in mechanism to generate the One Time Password and to use it for identifying the client.

In case of client connections by SSH protocol, instead, it relies on PAM-SSH for authenticating the token. NoMachine provides a specific module, pam_nxtoken.so for this purpose and this module has to be added to the system PAM SSH configuration. The token forwarding method can be used only if the node is Linux or Mac.

On Linux systems with SELinux enabled and not running in permissive mode, it's also necessary to add a policy to the SELinux configuration to permit the communication between SSHD and NoMachine in order to allow to authenticate the client with the OTP token.

Configuring Mac for using the pam_nxtoken.so module
Identify the sshd_config and sshd configuration files on your system:
Mac 10.11 and higher
/etc/ssh/sshd_config
/etc/pam.d/sshd
Mac versions up to 10.10
/etc/sshd_config
/etc/pam.d/sshd

Add the following entries to the sshd_config file:
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication yes
UsePAM yes

Add the following entries to the beginning of the sshd file
auth sufficient /Applications/NoMachine.app/Contents/Frameworks/lib/pam_nxtoken.so

Finally, restart SSHD.

Configuring Linux for using the pam_nxtoken.so module
Identify the sshd_config and sshd configuration files on your system, namely:
/etc/ssh/sshd_config
/etc/pam.d/sshd

Add the following entries to the sshd_config file:
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication yes
UsePAM yes

Add the following entry to the beginning of the sshd file:
auth sufficient /usr/NX/lib/pam_nxtoken.so

If it's a Debian-based system, add instead:
auth sufficient /usr/NX/lib/pam_nxtoken.so
auth [success=done default=ignore] pam_unix.so try_first_pass use_authtok

If the second entry is no added, users may be asked twice for password.

Finally, restart SSHD.

TIPS
I	In some cases, SSHD is not able to authorize the client to the federated server. This might be caused by permissions set for the user's ~/.ssh directory and files. Proper permissions are: ~/.ssh: 0700/drwx------ ~/.ssh/authorized_keys: 0600/-rw------- ~/.ssh/authorized_keys2: 0600/-rw------- ~/.ssh/known_hosts: 0600/-rw-------
II	The 'nxserver --serveradd' command can hang on Linux when LDAP or Active Directory is used. To solve that, edit the sshd file and modify it as it follows. For LDAP users remove the common-auth entry and add these lines (the first entry should be already present if you have applied instructions above): auth sufficient /usr/NX/lib/pam_nxtoken.so auth [success=2 default=ignore] pam_unix.so nullok_secure try_first_pass use_authtok auth [success=1 default=ignore] pam_ldap.so use_first_pass auth [success=2 default=ignore] pam_unix.so nullok_secure try_first_pass use_authtok auth [success=1 default=ignore] pam_ldap.so use_first_pass auth [success=2 default=ignore] pam_unix.so nullok_secure try_first_pass use_authtok auth [success=1 default=ignore] pam_ldap.so use_first_pass For Active Directory users add instead these lines (the first entry should be already present if you have applied instructions above): auth sufficient /usr/NX/lib/pam_nxtoken.so auth sufficient pam_centrifydc.so try_first_pass use_authtok

Additional instructions for SELinux configuration

In order to add the necessary SELinux policy, NoMachine will use a script which is able to retrieve the port on which the 'nxserver --daemon' process is listening and opening it in the SELinux configuration. Other two scripts will be also necessary to clean-up possible left-over policies and remove the current policy once NoMachine is shutdown.

These scripts will be executed as 'nx' user and require that the nx user can use 'sudo' without password. To ensure that, add the following line to the /etc/sudoers file:
nx ALL=(ALL) NOPASSWD: ALL

Scripts to configure SELinux will be executed when the 'nxserver --daemon' process is started (e.g. at reboot or when the 'nxserver --restart' command is given) and stopped. They must be placed in a directory accessible by the nx user and have read,write and executable permissions (744 or 700).

To instruct NoMachine to execute such scripts, edit the /usr/NX/etc/server.cfg file, uncomment and provide path to the correspondent script into the following keys: ScriptBeforeServerDaemonStop ScriptAfterServerDaemonStart
ScriptBeforeServerDaemonStart

Provide in ScriptBeforeServerDaemonStop the script to clean-up the SELinux policy if it already exists.
Configure ScriptAfterServerDaemonStart to execute the script for adding the SELinux policy.
In the ScriptBeforeServerDaemonStart key set instead the script to remove the policy when NoMachine is shutdown.

We prepared the following scripts as an example, they were made for Fedora 26 but can be easily modified to fit different systems.

In particular since path to 'semanage' can be different, you may verify that by running:

and change the path used in the following scripts accordingly.

clean_up_token_policy.sh

add_token_policy.sh

remove_token_policy.sh

We placed these scripts in the home directory of the nx user: /var/NX/nx/ and set permissions 740.

Then we configured the server accordingly:
ScriptBeforeServerDaemonStop "/var/NX/nx/clean_up_token_policy.sh"
ScriptAfterServerDaemonStart "/var/NX/nx/add_token_policy.sh"
ScriptBeforeServerDaemonStart "/var/NX/nx/remove_token_policy.sh"

Finally we restarted NoMachine in order to execute the script for adding the necessary SELinux policy.

NoMachine Cloud Server allows also to add the so called 'Foreign X Servers', which are Unix-like hosts running an unsupported Operating System for which we don't build native packages.

Pre-requisites to integrate a Foreign X Server in the NoMachine hierarchical infrastructure 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.

This is necessary to let the X server listen to remote connections from clients and enables the X11 forwarding from an external host. Please consult the official documentation of your Linux distribution for instructions and advices.

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

6. The xauth command is installed on the Foreign X Server host.

7. The Foreign X Server has SSH connectivity.

To add the Foreign X Server to the main Cloud Server, on the Cloud Server host execute the following command:

In the default configuration, all the available nodes are listed to users, which will then be able to choose any of them. If the 'manual selection' is disabled for a node, this node will be not listed to users. In this case, users will be able to connect to such node only if they have been explicitly redirected or assigned.

Assigning the user to a node is not mandatory but if this is set, the user's connection will be transparently routed to the specific node, even if it doesn't have the manual selection disabled.

User's assignment can be modified, set and unset at any moment.

A practical example

The --forward-connection option can be set also on a per-group of users basis:

The group of users can be a system group, or a NoMachine group. To create a NoMachine group of users:

TIP

The server's UUID is the unique string identifier of the node. Run 'nxserver --serverlist --extended' to retrieve it.

Listing forwarding directives
The forwarding directive is displayed as output of the 'nxserver --userlist' command used to list all the users:

Removing the forwarding

The Cloud Server allows administrators to assign the user or the group of users to a pool of nodes. In this way, when the user connects to the Cloud Server, he/she will see only a subset of nodes and will be able to choose to which one to connect among them.

For example if nodes of the Cloud Server are ED1, ED2, WS1, WS2 and WS3, administrator can configure the Cloud Server to make ED1 and ED2 visible to userA (but not to userB) and WS1, WS2 and WS3 visible to userB (but not to userA).

The general format of the command to allow/deny a node is:

To remove rules:

This feature applies only to a multi-server setup made of a Cloud Server + a pool of Enterprise Desktops nodes. When the Enteprise Desktop nodes are organized in one or more groups, the Cloud Server can be configured to assign the first available desktop to the incoming user.

When the automatic assignment of the Enterprise Desktop is enabled, the algorithm firstly checks if the connecting user is already logged-in to a desktop. In this case, that Enterprise Desktop is chosen.
If not, it looks for the first available desktop in the group, the desktop is considered available when it's in login window mode and nobody is logged-in to.
If there is not an available desktop, a message informs the user that all the desktops are already in use.

To enable the automatic assignment of the Enterprise Desktop, on the Cloud Server host execute the following.

It's possible to create any of the available profile rules on the Cloud Server host and propagate it to all nodes or to a given one.

TIP

Profile rules are then applied also when the server type installed on the node host doesn't support profiles (e.g. the Enterprise Desktop or the Workstation).

Profile rules are grouped in classes: 'session', 'service','feature' and 'node'. Each class includes a number of 'types' of rules. In case of profiles created on the Cloud Server a further class, called 'propagation' exists. Always specify 'propagation' as class and provide the appropriate type of rule with the --type option.

Profiles are available for the following types of rules:

A NoMachine failover cluster is a group of two Cloud Servers that work together to maintain high available access to the centralized infrastructure. This is an active/passive cluster where the primary server is at the beginning active and ready to accept users' connections, while the secondary server is passive, its task is to constantly monitor the primary server.

When the secondary server loses contact with the primary server, the cluster failover occurs: the secondary server takes place of the primary server to grant the continuity of services. Sessions running on the remote nodes continue to stay connected, management of server-node connections is passed from the primary to the secondary server, the virtual IP of the cluster is taken by the secondary server, an ARP notification is sent to local network devices to update their ARP cache entries (Ethernet MAC to IP address link associations).

It's important that custom keys in server.cfg and node.cfg are set to the same value both on the primary and on the secondary server. For example if 'NXGSSAPIStrictAcceptorCheck 0' is set on the primary server in server.cfg, it must be set to the same value also on the secondary server.

TIPS
I	If the Cloud Server has already a number of nodes and you want to set it in a failover cluster, just create the cluster. The multi-server environment doesn't need further configurations. Please note that when the failover cluster is set, the uuid of the main Cloud Server will be different. Additionally, users will then have to connect to the shared IP of the cluster server, not to the IP of the main Cloud Server as before.
II	If the Cloud Server is instead a federated server, it's necessary to remove it from the multi-host environment before setting it in a failover cluster. Then create the failover cluster. Finally add it again to its parent Cloud Server by specifying the shared IP of the failover cluster, not the IP of the single Cloud Server.

Set-up the failover cluster

STEP 1: Identify which Cloud Server host will be the primary server (CS1) and which will be the secondary server (CS2).

STEP 2: Ensure that CS1 is already configured as federation server, i.e. all the required servers subsystems have been already added to this Cloud Server.

STEP 3: Set-up the 'primary server' role to CS1.

On CS1 execute:

Optionally you may specify the following parameters to the 'nxserver --clusteradd' command:

STEP 4:
Set-up the 'secondary server' role to CS2

Always on CS1 execute:

STEP 5:
Restart CS1 and CS2

Firstly on CS1, then on CS2 execute:

TIP

It's mandatory to restart both the primary and the secondary server.

A practical example
Target is to set-up the failover cluster between 2 NoMachine Cloud Servers hosts, Cloud1 and Cloud2. This example assumes that they are both Linux hosts.

1. Install your Cloud Server on Cloud1.

2. Federate the necessary servers under Cloud1 via:

3. Install your second Cloud Server on Cloud2.

4. Assign to Cloud1 the active role (execute the command on Cloud1)

5. Associate the second Cloud Server to the cluster with the following command (execute the command on Cloud1):

6. Restart nxserver on Cloud1:

7. Restart nxserver on Cloud2:

8. Connect via NoMachine client or browser to virtual IP (172.17.10.100)

Finally, you can then verify that high-availability works as expected.

9. Kill Cloud1: you will be disconnected.

10. Reconnect to virtual IP (172.17.10.100) while leaving Cloud1 down and you should be given the option connect again as Cloud2 should have now taken over duty.

Default settings apply to the most common cases. It may be necessary, however, to tune some parameters to fit some specific business requirements or network conditions. These are the default settings which define the cluster's heartbeat and rule health detection between the two NoMachine servers in the cluster.

The global failover time depends on:

global failover time = grace period + timeout + router's convergence time

Replacing the RSA key pair for the Failover Cluster (optional)
The primary and secondary Cloud Servers use a RSA key pair to connect and synchronize information between their databases. This key pair is valid only for the nx user. You may replace the default RSA key-pair provided with the installation by generating your own key-pair.

See https://www.nomachine.com/DT03O00127 for detailed instructions about how to replace the default RSA key-pair for the Cluster.

Once replaced, remember to update the cluster configuration by running on the primary Cloud Server or on the secondary Cloud Server (configurations will be propagated to the other server in the cluster) the following command:

Changing network interface and/or subnet mask for the given Cloud Server machine

Changing IP of localhost, primary server and/or failover cluster

Changing Failover Cluster Parameters (heartbeats)

Removing a Cloud Server from the Failover Cluster

Federating a new server to the primary Cloud Server CS1 and updating the Failover Cluster accordingly
Execute on CS1:

Removing any of the federated servers from Cloud Server CS1 and updating the Failover Cluster accordingly
Execute on CS1:

First of all, ensure that the user has a system account on the Cloud Server and on each of the federated servers he/she needs to acces. Username must be the same on all machines, password can be different.

TIP

If you have two Cloud Servers in a failover cluster the same system user's account (username and password) has to be created on both server hosts.

Once installation is complete, Cloud Server is ready to go.

The end-user should point the browser on his/her device to:

http://SERVER:4080

Where SERVER is either the name or IP address of the host you want to reach.

E.g., if Cloud Server is installed on a host named 'myserver.com', the URL will look like this:

http://myserver.com:4080

Connection will be automatically switched to HTTPS protocol:

https://myserver.com:4443/nxwebplayer

In the login form, the end-user has to provide username and password of his/her system account on the Cloud Server host and connect.

Depending on how the Cloud Server is configured, the end-user will:
i) be re-directed to a specific server federated under this Cloud Server

ii) or will access the list of all federated servers with the possibility to choose any of them.

Install NoMachine Enterprise Client on your device. You can use also NoMachine free or whichever other server type, they all provide the client UI for connecting to remote computers. In the 'Machines' panel you can create a new connection by clicking on 'Add': just provide the IP address of the Cloud Server you want to connect to and port number.

Note that IPv6 is supported: specify the IP address of the server host in IPv6 format (e.g. 2001:0:5ef5:79fb:30c6:1516:3ca1:5695) if you want to use it instead of IPv4.

See also the NoMachine Enterprise Client - Installation and Configuration Guide, https://www.nomachine.com/DT10R00170

TIP

If you're connecting to a NoMachine server which supports web sessions, you can create web-based sessions in the same way as a traditional connection, just select HTTPS as the protocol to be used. For more details, please read here: https://www.nomachine.com/getting-started-with-web-based-access-using-nomachine-player

To prevent NoMachine client users from storing their credentials, use the EnableClientCredentialsStoring key in the server configuration file. The accepted values are:
player Only users connected via NoMachine client are enabled to save username and password in the connection file stored on their devices (computer, tablet etc ...)
webplayer Only users connected via browser can choose to save their access credentials. They are stored in the browser's cookie, given that the user's browser has cookies enabled.
both All users, regardless if connected via NoMachine client or via web, can store their credentials.
none Users cannot save their username and password. They will be requested to provide their log-in credentials at each connection.

For example, to allow only users connecting via NoMachine client to store credentials, set in the server configuration file:
EnableClientCredentialsStoring player

The configuration file for the web player program (which provides the graphical front-end) and the web client program (which manages web sessions) is server.cfg, located in the BaseDirectory/NX/etc directory on Linux, BaseDirectory/NoMachine/etc directory on Windows and /Applications/NoMachine.app/Contents/Frameworks/etc on Mac.

For example on Linux: /usr/NX/etc/server.cfg.

Default settings
The Section directive defines settings for the NoMachine server(s) where the web player application will connect. This directive, by default, points to localhost and looks like:

Section "Server"

Name "Connection to localhost"
Host localhost
Protocol NX
Port 4000
Authentication password

EndSection

Name is a label that can be displayed as an alternative to show hostname of the server.
Host is IP or hostname of the NoMachine server host.
Protocol and Port indicates protocol and port that web player will use to connect to the NoMachine server.
Authentication defines the authentication method to be used when connecting by the web: 'password' for password-based authentication (default) or 'private-key' for key-based authentication.

Changing protocol and port
By default when users connect via web, they will use the NX protocol on port 4000. Supported protocols are NX and SSH with system login

To use the NX protocol (this is the default), set:
Protocol NX
Port 4000

To use SSH protocol and system login, set for Linux and Mac:
Protocol system
Port 22

and for Windows:
Protocol system
Port 4022

Define the authentication method
When connecting by the web and since v. 6.6.8, it's possible to use password-based authentication or key-based authentication (available at the moment only for the NX protocol).

To use password-based authentication (this is the default), set:

Authentication password

To use SSH key-based authentication, set:
Protocol NX

Authentication private-key

TIP

NoMachine uses by default port 22 for SSH protocol on Linux and Mac, and port 4022 on Windows. The default port for NX protocol is 4000. In order to change the port for NX protocol, change the port for the nxd service and restart it. See the paragraph 'Connecting by NX Protocol'. To change the port for connections by SSH to Linux and Mac hosts it's necessary to modify the listen port for the SSH server on the system. On Windows instead, change the port for the nxsshd service.

Showing hostname or a custom label
To display hostname or IP of the Cloud Server host when connecting by the web, set the following key. This is the default:

EnableWebConnectionName 0

To display the label set in the 'Name' field of Section "Server" set:

EnableWebConnectionName 1

Hiding the tutorial wizard at web session startup
To not display the tutorial wizard for the menu panel at session startup, set:

EnableWebMenuTutorial 0

and to show it (this is the default):

EnableWebMenuTutorial 1

Allowing to log-in as a guest
If the Cloud Server has support for guest accounts enabled, set the following key if you need that users connect by the web always as guest users:

EnableWebGuest 1
If this key is disabled, users will have the possibility to choose if log-in with their credentials or as a guest.

You can start and stop the NoMachine HTTP server (nxhtd) from the Server preferences UI -> Services panel. From the NoMachine UI you can also change the port where the web server will be listening (by default 4080 and 4443 for secure connections).

From command line instead it's possible to do the following.

Stop, start or restart nxhtd

Automatic restart of the nxhtd service
Each service is automatically restarted at the next boot. You can change the default behavior for the nxhtd service by setting:

The nxserver --startmode command operates on the StartHTTPDaemon server configuration key:

StartHTTPDaemon Automatic

and:

StartHTTPDaemon Manual

Disabling the starting of the NoMachine HTTP server
Edit the server configuration file and remove HTTP from the ClientConnectionMethods key. It should then look like:

Then restart NoMachine server to make this change effective:

NoMachine Cloud Server is designed to provide a fully integrated service to deploy sessions on the web which doesn't require additional software to be installed or manual configuration. The minimal Apache web server, nxhtd, provides the necessary modules and is pre-configured to work with the web player application.

However, it is possible to run the web player application with an alternative Apache web server. This requires the configuration of Apache and the web player.

Instructions are available at: https://www.nomachine.com/DT03O00128

The implementation of WebRTC support in browser-based remote desktop sessions has inititally been released as beta and must be enabled explicitly by the administrator by editing the server.cfg file.

With the help of a STUN/TURN server for negotiating NAT traversal, peer-to-peer WebRTC communication can be established also when the web session has to be run behind a NAT.

STEP 1: Uncomment and set the AcceptedWebMethods key as follows to enable the use of WebRTC:

AcceptedWebMethods webrtc

STEP 2: If the node machine where the web session will be started is behind a NAT, you need to uncomment the following section in server.cfg:

Section "STUN"

Host hostname
Port portnumber
User username
Password password

EndSection

and provide relevant information to contact a STUN or TURN server. In this last case change Section name to "TURN".

See also: https://www.nomachine.com/AR07N00892 for further intructions about the configuration and: https://www.nomachine.com/AR07N00894 for an example about how to set up your own STUN/TURN server and configure the Cloud Server accordingly.

The configuration files for the nxserver and nxweplayer/nxwebclient programs is server.cfg. The configuration file for the nxnode program is node.cfg.

They are placed in the:
BaseDirectory/NX/etc directory on Linux

BaseDirectory/NoMachine/etc directory on Windows

/Applications/NoMachine.app/Contents/Frameworks/etc/ directory on Mac.

For example on Linux:
/usr/NX/etc/server.cfg
/usr/NX/etc/node.cfg

The Default Configuration
NoMachine Cloud Server comes with a default configuration that is sufficient to grant a working setup in the majority of environments. NoMachine administrators can tune their installation at any moment and according to their specific needs by setting the related configuration keys. In some cases this will require to restart all NoMachine services.

Edit the Configuration Files
NoMachine configuration files are text files made up of a number of key-value pairs. All the configuration files can be edited manually by a text editor. For example 'vi' can be used on Linux and Mac, and 'notepad' on Windows. On Windows it can be necessary that you copy the cfg file in a different place, edit it and move it to the etc directory.

Be sure to uncomment the configuration key (i.e., remove the '#' pre-pended to the key) to set a value different from the default.

When a configuration key supports an on/off status, set value to '0' to disable it and to '1' to enable it.

Make Changes to the Default Configuration Effective
Changes will be effective with the next new connection without the need to restart the server if not otherwise specified.

TIP

Configuration settings apply only to this Cloud Server, they aren't propagated to any of the federated servers (which in turn need to be configured via their configuration files). Additionally, please consider that the Cloud Server doesn't run sessions on its host (except for connections to the physical display made by authorized users like administrators).

Installation and upgrade procedures take care of configuring and starting all the necessary services to make NoMachine Cloud Server ready to accept connections. The necessary services are configured to be restarted at each reboot of the host machine.

You can stop and start accepting new connections via:

the UI
from the Server status UI click on 'Stop the server' and 'Start the server' respectively: this will prevent users from running new connections

or from command line
to disable accepting new connections from the command line, run:

All NoMachine services can be stopped via:

the UI
all NoMachine services can be stopped by the Server status UI ('Shutdown the server'). When doing so, you will be asked if services must be started at the next reboot or not. You can restart services also from the Server status UI ('Start the server').

or from command line.

Stopping all the NoMachine services

Starting NoMachine server and services

Specifying the start mode
It's possible to set the 'start mode' (if services will be started automatically at boot or not) by using:

Stopping and restarting NoMachine server and services

The NoMachine networks services available for NoMachine Cloud Server are nxd, nxhtd (both installed on all platforms) and nxsshd (installed on Windows only):

You can stop a single service:

via the UI
in the Server status -> Server preferences -> Network services UI. You can choose there also the start mode: if the service must be started automatically at the next boot or not.

or from command line.

Stopping a service

where SERVICE can be:
nxd, the Network Server for accepting connection by NX protocol

nxhtd, the NoMachine web server for web sessions

nxsshd, the SSH server for Windows

Starting or restarting a service

Specifying the start mode
By default each service is automatically restarted at the next boot. You can configure that on a per-service basis by running:

Commands above operate on the configuration keys listed below. You can change them manually in the server configuration.

By default NoMachine Cloud Server broadcasts information to let other NoMachine computers to discover it on the local network. You can disable this feature via:

the UI
in the Server status -> Server preferences -> "Network services" UI

or in the server configuration file
set the following key in the server configuration:

EnableNetworkBroadcast 0

Then restart the server to make changes effective:

TIP

By default, also each of the NoMachine servers federated under the Cloud Server broadcast their information over the LAN. If they are configured to be directly accessible by the user (i.e. they accept connections to their IP), users will be able to see them and connect. If they are configured to accept connections via the Cloud Server only, their information is not broadcasted and they cannot be visible to users.

You can manage (create, delete and modify) user accounts by using tools provided by your Operating System or the NoMachine server commands as explained below.

Creating Accounts
The Cloud Server is able to handle two types of accounts: system accounts and NoMachine accounts. The latter allows to separate the system password from the NoMachine password.

Creating a System Account
The system account will be created with the default system settings. The new user will be also added to the NoMachine Users db:

Creating a NoMachine Account
Use this command when the user already has a system account:

TIPS
I	To assign a password different from system password to a system user, enable NoMachine Password DB EnablePasswordDB 1
II	To verify if the user's authentication is based or not on NoMachine Password db:
nxserver --userauth USERNAME
III	Each user must have the same system account on the Cloud Server host and on each of the federated server hosts he needs to be able to connect to. Password can be different.

Enabling and Disabling access for a NoMachine User
Prerequisites are:

(i)The user has run at least one session or have been added to NoMachine dbs by means of 'nxserver --useradd' command.

(ii) NoMachine Users DB is enabled (EnableUsersDB 1 is set in server.cfg)

You can enable/disable a user and allow/forbid his access to the Cloud Server by running:

Modifying the User's Password
You can modify user's system password by running:

Listing the NoMachine Users
All users who have run at least one session or have been added to NoMachine dbs are stored in the Users db. You can retrieve the complete list by running:

The output of this command provides the following fields:
Redirected to: IP/hostname of the server to which the user's connection is redirected (by means of the 'nxserver --redirect' command)..

Trusted for: it shows if the user is trusted and therefore allowed to connect to the physical desktop of this host (only specific user are permitted to do that).

Screen Sharing: it shows which user has the sharing of their physical screen disabled.

Access: it shows if the user is enabled or not to access the NoMachine system. This works in conjuction with the use of the NoMachine Users DB: when enabled (EnableUserDB 1 in the server configuration), it's possible to enable/disable user's access to the whole NoMachine system.

Forwarded to: it indicates to which federated server, if any, the user will be forwarded when connecting to the Cloud Server.

Removing Accounts
To remove an account from the system:

For removing a NoMachine user and delete his account from the NoMachine dbs

Redirecting the user to a specific NoMachine server
To create a new system user and set-up a redirect directive to forward the user's connection to the given server:

Forwarding the user to a specific NoMachine server (federated under this Cloud Server)
To create a new system user and set-up a directive to forward the user's connection to the given server:

The Cloud Server supports system groups of users and the creation of NoMachine groups of users. It's possible to redirect groups of users to a specific node or create profile rules on per-group basis.

Creating NoMachine groups of users

TIPS
I	When there are multiple groups with different rules associated and the same user belongs to more than one group, it is possible to associate a priority level to the group. This can be done when creating the group by using the --priority <priority> option or later by editing the group settings. For example (on Linux or Mac):
$ sudo /etc/NX/nxserver --groupadd testers --priority 2
II	When the user belongs to one or more groups having all the same priority level, the most permissive settings of any of these groups are applied. For example if group A is trusted for accessing the physical desktop and group B is not trusted, users who belongs to both grou A and B are permitted to connect to the physical desktop.

Assigning a user to a group
To assign an existent user to a group:

If the user doesn't yet have a system account, it's possible to assign it to a group while creating the system account:

Redirecting all users of the given group to a specific NoMachine server
It's possible to set-up a redirect directive to forward all users belonging to this group to a different NoMachine server by using the --redirect SERVER:PORT option:

Forwarding all users of the given group to a specific NoMachine server (federated under this Cloud Server)
To create a new group and set-up a directive to forward the users' connection to the given server:

Changing the group of a given user

Deleting a user from the group

Listing groups
The following command lists all users on a per-group basis and shows options set for the group like priority, redirection rules etc...

Only specific users are allowed to connect to the physical desktop of this Cloud Server host, mainly for maintenance operations. These specific users are:

a) Privileged system users (root or 'sudo' users on Linux and Mac, administrator users on Windows).

b) NoMachine administrators.

c) NoMachine users trusted for connections to the physical desktop.

a) Privileged system users
A privileged system account has to be defined by means of system tools.

The Cloud Server allows by default administrative users to connect. You can disable it by setting in the server configuration:

EnableAdministratorLogin 0

To re-enable the possibility to log in as root or administrator, set:

EnableAdministratorLogin 1

b) NoMachine administrators

To create a new user on the system with NoMachine administrative permissions, execute:

TIP

Only NoMachine administrators can add servers to a Cloud Server or add Terminal Server Nodes to an Enteprise Terminal Server via the UI.

c) NoMachine users trusted for connections to the physical desktop
To create a new user on the system and make him trusted for connections to the physical desktop, run:

The Cloud Server supports the possibility to generate temporary guest accounts on demand. The automatic generation of guests accounts is available on all platforms, i.e. Linux, Windows and Mac. This feature however is not enabled by default and must be activated via profile rules.

Once enabled, the Cloud Server will accept the request to log-in as a guest and forward it to any of its federated servers. The target server has to support guest users and have them enabled. Guests are supported by Enterprise Desktop, Terminal Server and Enteprise Server.

Note also that a system account will not be created on the Cloud Server host: the login as a guest is temporary and valid only once. On the target server, instead, a system account is created for each guest user. Time of validity and other features can be set for guest users by editing the server configuration on the target host. See the guide for your Enterprise Desktop, Terminal Server or Enteprise Server for more details.

TIP

Guest users don't know their username and password and cannot therefore unlock the remote screen if screen locking is enabled. It's therefore necessary to disable it on the system.

To enable guest accounts

How guest accounts work

When the user connects to the Cloud Server and chooses to 'Login using a guest account option', the Cloud Server will set-up a kind of virtual account. The user will be able to choose a server the list of all federated servers(only those which support guest login will be listed), or will be automatically forwarded to the target server. The Cloud Server will then contact the target server and request to create the guest account. On the target host, the NoMachine server installed there will create a system account according to settings in its configuration file. Login as a guest is not supported in case of Foreign X Servers.

It's possible to create profile rules on the Cloud Server and propagate them to all nodes or to a specific group of nodes or to a single node only even when the server type doesn't support profiles. See paragraph 'Propagating Profile Rules from the Cloud Server to Nodes (optional)' in this guide. On the Cloud Server only, it's possible to enable support for the login as a guest user (automatic generation of guest accounts).

Updating the NoMachine installation requires the termination of all the running sessions on that host. These sessions cannot be recovered later. This is necessary for installing the new libraries and binaries. Processes already loaded in the system memory lock down the corresponding binaries and libraries that cannot be otherwise replaced.

The procedure implies a shutdown of all services. They are automatically restarted once the update procedure is completed.

The cleanest way to upgrade the Cloud Server and its nodes is to:

As a precaution, we suggest to do the following before proceeding with the upgrade.

Step 1- Stop the node(s) you're going to update.
This will prevent new connections to the node(s) but will not terminate sessions there. You can stop access to the node(s) from the Cloud Server host as explained below.

On Linux and macOS, execute the command as 'sudo' user or as 'root' and without'sudo':

On Windows, open a CMD console as administrator and execute:

Step 2- Then, proceed to update the node. You can do that by installing a new package or via UI by means of the automatic updates from the NoMachine repositories. (See next paragraph for more details).

Step 3- Finally, re-enable accepting connections on the nodes by running the following commands on the Cloud Server host.

On Linux and macOS:

On Windows, open a CMD console as administrator and execute:

TIP

The 'nxserver --serverstop' and 'nxserver --serverstart' commands accept a comma-separated list of servers in the format of: <server1:port>,<server2:port>... where <server1:port> is the name of the node as it appears in the output of 'nxserver --serverlist'.

Step 4- Once all nodes have been updated, update the Cloud Server. let's distinguish two cases, a single Cloud Server (Case I) or two Cloud Servers in a failover cluster (Case II).

Stop accepting connections on the Cloud Server by executing the following commands.

On Linux and macOS:

On Windows, open a CMD console as administrator and execute:

Update the Cloud Server. The update procedure will restart automatically all the necessary services.

Step 1- Shutdown the Cloud Server on the secondary server host to avoid to activate the failover procedure when stopping Cloud Server on the primary server host.
To do that, execute the following command on the secondary server host.

On Linux and macOS:

On Windows, open a CMD console as administrator and execute:

Step 2- Then stop accepting connections on the active Cloud Server by executing the following commands.

On Linux and macOS:

On Windows, open a CMD console as administrator and execute:

Step 3- Now update the primary Cloud Server and the secondary Cloud Server. Order of update is not relevant.

Step 4- Finally restart both Cloud Servers after the update to make sure that the cluster interface is created on the primary server. Execute firstly on the primary CS host then on the secondary CS host the following command.

On Linux and macOS:

On Windows, open a CMD console as administrator and execute:

The Cloud Server, as well as the other NoMachine client and server products, periodically checks NoMachine repositories (by default every two days) to verify if updates are available and will prompt a dialog informing the user that a new version is available.

It will never automatically update the current installation. Also the download in background of a new software version will not lead to an automatic update of the current installation.

A separate guide deals specifically with all the possible options for the automatic software updates:

https://www.nomachine.com/DT10O00149

Since Cloud Server v. 7.2, it's possible to upgrade gradually a Cloud Server environment from v. 6 to v. 7 . Upgrade before the nodes and finally the Cloud Server. The detailed procedure is explained at paragraph 9.1.

To retrieve logs by using the NoMachine tools, please refer to guides in the Configuration section at: https://www.nomachine.com/all-documents or collect them manually according to instructions here: https://www.nomachine.com/DT10O00163

TIP

When debug mode is enabled, server logs may increase consistently. It's suggested to keep debug level only for the time necessary to reproduce the problem and collect logs.