NoMachine Enterprise Products v. 4 - Server Guide - Advanced Functions

Added on: 2013-09-24 Last Modified: 2015-09-03

Table of Contents

1. NoMachine Administrator's Guide - Advanced Functions

1.1. Feature Comparision

1.2. Advanced Functions and the Default Behavior

1.3. Document Convention

1.4. Resources on the Web
2. Groups of Users

2.1. Creating a Group

2.2. Adding a User to a Group

2.3. Updating a Group

2.4. Listing Groups

2.5. Deleting a Group
3. Profiles

3.1. Resources Availability vs. Profiles

3.2. Disabling Profiles

3.3. Listing Profiles

3.4. Creating Rules

3.5. Updating Rules

3.6. Removing Rules
4. Profile Rules to Manage Sessions

4.1. Allowing or Forbidding Session Types

4.2. Rules for Sessions on the Remote Node

4.3. Limiting the Number of Connections on the Remote Node

4.4. Allowing or Forbidding Sessions on the Remote Node
5. Profile Rules to Manage Services

5.1. Allowing or Forbidding Services
6. Profile Rules to Manage Features

6.1. Managing Features

6.2. Limiting Bandwidth

6.3. Controlling Clipboard Functionalities

6.4. Enabling or Disabling Manual Node Selection

6.5. Enabling or Disabling Support for Guest Users

6.6. Enabling or Disabling Multi-node Support
7. Introducing Multi-Node Concepts
8. NoMachine User Administration on the Node Host

8.1. Adding a System Account

8.2. Removing a System account
9. Setting-up the Multi-Node Environment

9.1. Adding the Node to the Server
10. Configuring the Multi-Node Environment

10.1. Enabling or Disabling the Manual Selection of the Node

10.2. Limiting Number of Concurrent Connections on the Node

10.3. Creating a Pool of Nodes for Specific User(s)
11. Managing Nodes in the Multi-Node Environment

11.1. Listing the Available Nodes

11.2. Modifying Values Set for the Node

11.3. Keeping Node Resource List Up-to-Date

11.4. Using a Custom Algorithm for Load-Balancing Virtual Desktops

11.5. Using the Node Load Average for Load-Balancing Virtual Desktops
12. Managing Access to the Nodes

12.1. Enabling and Disabling Connections to the Node

12.2. Removing the Node from the Multi-Node Environment

12.3. Disabling Direct Access to the Node

12.4. Difference between Terminal Server and Terminal Server Node

12.5. Disabling Multi-Node Support
13. Activating Failover Cluster (High Availability) in a Multi-Node Environment

13.1. Prerequisites

13.2. Setting-up and Configuring the Cluster

13.3. Removing Localhost from the List of Available Nodes

13.4. Adding the Master Server to the Cluster

13.5. Adding the Secondary Server to the Cluster

13.6. Updating the Cluster Configuration

13.7. How to replace the DSA key pair for the Cluster

13.8. When is it Necessary to Update the Cluster?

13.9. Removing a Server Machine from the Cluster

13.10. A Practical Example
14. Using NoMachine 5 or Later to Access Unsupported Unix-based Systems (Foreign Nodes)

14.1. Adding a Foreign Node to the NoMachine Server

14.2. Listing Foreign Nodes

14.3. Editing a Foreign Node

14.4. Updating Resources for a Foreign Node

14.5. Removing a Foreign Node
15. Guest Accounts

15.1. Enabling the Automatic Generation of Guest Accounts

15.2. Configuring the Automatic Generation of Guest Accounts

15.3. Setting Disk Quota for Guest Accounts on Linux

15.4. Configuring Guest Sessions

15.5. Creating Profiles for Guest Accounts

15.6. Creating a Guest Account Manually

15.7. Listing Guest Accounts

15.8. Removing a Guest Account
16. Redirecting the Session

16.1. Redirecting on a Per-Client Basis

16.2. Specifying a Family of Client IPs or Hostnames to be Redirected

16.3. Listing Per-Client Redirection Directives

16.4. Modifying Per-Client Redirection Directives

16.5. Removing Per-Client Redirection Directives

16.6. Redirecting on a Per-User Basis

16.7. Listing Redirection Directives for Users

16.8. Editing the per-User Redirection Directives

16.9. Disabling Per-User Redirection Directives
17. Access Remote Desktops by RDP and VNC

17.1. Enabling RDP and VNC (RFB) Sessions
18. Administering the Server via GUI Tools with NoMachine 5 or Later

18.1. Giving NoMachine Aministrative Privileges to the User

18.2. Removing NoMachine privileges from the User's Account

 

 


1. NoMachine Administrator's Guide - Advanced Functions

Welcome to the System Administrator's guide for NoMachine version 4. This guide deals with the following advanced functionalities:

1) User and System Profiles.

2) Multi-node support.

3) Automatic generation of guest accounts

4) Session redirection on a per-client or per-user basis.

5) Access Remote Desktops by RDP and VNC

and applies to all the supported platforms.

 

1.1. Feature Comparision

NoMachine offers a range of products suitable for the Enterprise which are differentiated by the functionalities included. You can consult the up-to-date list of functionalities available for each server typology on the NoMachine web site, for the enterprise family here and for the terminal server products here.

 

1.2. Advanced Functions and the Default Behavior

Multi-node capabilities are enabled by default. A proper package must be installed on the node host, and the remote node must be added to the server. Cluster services, instead, are not activated by default. They require two servers for high availability (when the primary server goes down, the secondary server will take its place) and possibly a number of nodes associated to the primary server.

Profiles are enabled by default. The automatic provision of guest accounts has to be explicitly activated by setting the proper profile rule. In the same way, multi-node capabilities and profiles can be disabled/enabled by means of profile rules.


Disabling profiles implies that the server doesn't rely on any of the rules that may have been set to tune its behaviour. This means that if you want to make effective, for example the disabling of the multi-node support or the enabling of automatic generation of guest accounts, you need to have profiles enabled.


Redirect capabilities are always available but ineffective until you instruct the server to redirect connecting clients or users.


Support for RDP and VNC sessions is disabled by default. You need to configure NoMachine for activating it. It's necessary that you have the RDP and VNC client installed on the NoMachine server host.

 

1.3. Document Convention

The following conventions are used in this guide:

BaseDirectory indicates the base directory where the NoMachine binaries and libraries are installed. By default, BaseDirectory is "/usr" on Linux, "C:\Program Files\" on Windows and "/Applications" on Mac OS X.

Samples included in this guide refer to the the default location for the NX installation.


Notices:

1) Operations such as start/stop a service, create/remove users and similar are intended to be executed by a privileged user, even when done via the administrative UI.

2) Server and node commands are intended to be run from xterm or similar and from CMD console on Windows. They require administrative privileges.

3) For a complete list of all server and node commands, run respectively 'nxserver --help' and 'nxnode --help' from xterm or similar.

4) Server and node configuration files are server.cfg and node.cfg, respectively. They are placed in the BaseDirectory/NX/etc directory on Linux, BaseDirectory/NoMachine/etc directory and Windows and BaseDirectory/NoMachine.app/Contents/Frameworks/etc on Mac OS X.

5) Cloud Server includes the web player application. Its configuration file, cloud.cfg is stored in the same etc directory.

6) All the configuration files can be edited via a text editor, e.g. 'vi' on Linux and Mac OS X and 'notepad' on Windows.

7) To set a value different from the default the configuration key must be uncommented, i.e., the '#' pre-pended to the configuration key name must be removed.

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

9) Changes to configuration files become effective at the next session startup, without the need to restart the server if not otherwise specified.

1.4. Resources on the Web

The NoMachine website, http://www.nomachine.com provides a variety of online resources in conjunction with the software and its usage:


The NoMachine Packages
The latest version of the NoMachine packages is available at: http://www.nomachine.com/download


The Installation Guides

For detailed information about how to install and upgrade your NoMachine installation, view the guides available at: https://www.nomachine.com/documents


The Knowledge Base
The NoMachine Knowledge Base, https://www.nomachine.com/support, provides technical documents especially for administrators as well as end-user guides, articles, and “howto's.”


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. Groups of Users

NoMachine Server allows to define groups of users. Each user can be assigned to a group so that profile rules or specific settings (like for example redirection) can be defined on a per-group basis and applied to all users belonging to such group.

 

2.1. Creating a Group

The general form of the command to create a group is:

nxserver --groupadd GROUP OPTION

where GROUP is the name of the group and OPTION can be:

--redirect <server:port>
redirect the user's connection to the specified server
--priority <priority>
assign a priority level to the group. The same user can belong to different groups. If a rule is set for multiple groups, the groups with high priority overrides the other settings


Example:

Create the 'Developers' group with priority '2' and redirect it to testdrive.nomachine.com

nxserver --groupadd Developers --priority 2 --redirect testdrive.nomachine.com

 

2.2. Adding an User to a Group

The general form of the command to add an already existing user to a group is:


nxserver --useradd USERNAME --group GROUP


where USERNAME and GROUP are respectively the name of the user and of the 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:


nxserver --useradd USERNAME --group GROUP --system


Some examples:


Add user nxtest01 to group 'testers'


nxserver --useradd nxtest01 --group testers


Create user developer01 and add it to group 'developers'


nxserver --useradd developer01 --group developers --system

 

2.3. Updating a Group

The general form of the command to change settings for a group is:


nxserver --groupedit GROUP OPTION


where OPTION can be:

--redirect <server:port>
redirect the user's connection to the specified server
--priority <priority>
assign a priority level to the group. The same user can belong to different groups. If a rule is set for multiple groups, the groups with high priority overrides the other settings

 

2.4. Listing Groups

The general form of the command to list groups and their attributes is:

nxserver --grouplist

This command lists all users divided on a per-group basis

 

2.5. Deleting a Group

The general form of the command is:

nxserver --groupdel GROUP

where GROUP is the name of the group

 

3. Profiles

In the default configuration, NoMachine server has support for profiles enabled. A profile is defined by a set of rules applied by default on a per-server basis. Rules on per-server basis apply to all users which log-in to that server and to all nodes added to that server.


Some definitions for the profile behaviour:

1) Rules scope is on a per-system basis, if not otherwise specified. It can be also on a per-user, per group, per-guest and per-node basis, when applicable.

2) Rules are grouped into classes. Each of them is made of a number of class types.

3) For each rule it is necessary to define the following items: class, class type, value and option. Option indicates on which basis the rule has to be applied (e.g. per-system, per-user etc...).

4) Rules concerning the server behaviour (enable/disable use of profiles, multi-node support and automatic generation of guest accounts) can be applied only on a per-system basis.

5) Rules enabling/disabling the manual selection of the node can be set on a per-system or per-user basis.

6) Rules set for guest accounts apply to all guest users and do not affect other users. Support for the automatic generation of guest accounts must be enabled in profiles. This feature is available only on Linux.

Default profile of NoMachine server
Until the administrator explicitly defines a set of rules, the server relies on its default profile, which allows all the supported functionalities, except for automatic generation of guest accounts and the manual selection of the remote node.


Allow and deny class types
A rule to allow or deny a class type (e.g. forbid a session type) or set a behavior (e.g. limit the bandwidth usage) has to be explicitly set, otherwise the server continues to rely on its default behaviour.


Modify rules
You can change value set for a rule by simply re-adding it and specifying its new value.


Rules and profiles disabled
If profiles are disabled, you may still create and/or delete rules, but the server doesn't rely on any of these rules until profiles are enabled again.


NoMachine server tools to manage profiles

NoMachine server provides a command line interface to create rules for setting profiles and retrieve information.

 

3.1. Resources Availability vs. Profiles

NoMachine server and each of the nodes are able to provide a list of their resources. When the node is local, its list corresponds to the one of the server. Resource list reports what is available on that host, for example which session type can be run or which service (audio, printing etc...) is supported. The default profile of the server is based on that list and can be modified by setting profile rules.


The general form of the command to retrieve a complete list of all resources is:


nxserver --resourcelist OPTION


where OPTION can be:

--class <class> filter results by class. Classes are: session, service, feature and node
--value yes|no filter results by value
--user USERNAME show resources for the specified user
--guest show resources available for guest accounts (available on Linux only)
--node NODE list all resources available on the node

The availability of some resources strictly depends on the system: this is the case of services like audio, microphone, sharing and printing which can rely on a third party software for example on Linux.


Some examples:

Retrieve a complete list of all resources
nxserver --resourcelist

Retrieve resources for the class feature
nxserver --resourcelist --class feature

Retrieve resources available for user: nxtest01
nxserver --resourcelist --user nxtest01 --value yes

Retrieve resources not available for guest users
nxserver --resourcelist --guest --value no

Retrieve which kind of sessions are available on that server
nxserver --resourcelist --class session --value yes

Retrieve list of resources available on the remote node testdrive.nomachine.com
nxserver --resourcelist --node testdrive.nomachine.com:4000


Setting profile rules is like creating a subset of available resources. When the user logs in to the system, NoMachine Server verifies what is allowed for that user by comparing available resources and set of profile rules.

 

3.2. Disabling Profiles

Support for Profiles is enabled by default. The general form of the command to enable or disable use of profiles is:


nxserver --ruleadd --class feature --type enable-profiles --value yes|no --system


Some examples:

Disable profiles:
nxserver --ruleadd --class feature --type enable-profiles --value no --system

Enable profiles:
nxserver --ruleadd --class feature --type enable-profiles --value yes --system

 

3.3. Listing Profiles

The general format of the command is:


nxserver --rulelist OPTION


OPTION can be any of the following:

--system list only the rules defined for the server
--user USERNAME list all the rules set for the specified user
--guest list all rules defined for guest accounts
--node NODE list all the rules set for the specified node
--class CLASS list all the rules set for the specified class
--group GROUP list all the rules set for the specified group

If no option is provided, list all the rules set in the NX Profile DB. Note that this command will show only rules that are effectively set.


Some examples:

List all the rules set for the system
nxserver --rulelist --system

List all the rules set for user: nxtest
nxserver --rulelist --user nxtest

List all the rules set for class: service
nxserver --rulelist --class service

List all the rules set for class:service for node: testdrive.nomachine.com
nxserver --rulelist --class service --node testdrive.nomachine.com:4000

List all the rules set for group: Developers
nxserver --rulelist --group developers

 

3.4. Creating Rules

The general format of the command is:

nxserver --ruleadd --class CLASS --type TYPE --value yes|no|value OPTION

CLASS can be any of the following classes:


--session
--service
--feature
--node


For each class there is a number of available types, which are listed in detail in the following paragraphs.

Depending on TYPE, value could need to be specified as 'yes' or 'no', or as value.


OPTION can be any of the following options, depending on the type of rule:

--system
set the rule on a per-server basis. The rule will be applied to the whole NX System and to every user accessing it
--user USERNAME
set the rule on a per-user basis. The rule will be applied to the specified user only
--guest
the rule will be applied to all guest users and will not affect other users. Guest accounts are available only on Linux.
--node NODE
set the rule for the specified NODE only
--group GROUP
set the rule for the specified GROUP.


Tip
You can always omit the --system parameter, the server assumes that query is per-server if not otherwise specified.

 

3.5. Updating Rules

To modify the value set for a rule it is enough to add the same rule by specifying the new value in the --value option.

 

3.6. Removing Rules

The general format of the command is:


nxserver --ruledel OPTIONS


OPTIONS can be any of the following options:

--system
remove all the rules set for the server
--user USERNAME
remove all the rules set for the specified user
--guest
remove all the rules set for guest accounts
--node NODE
remove all the rules set for the specified group
--group GROUP
set the rule for the specified GROUP.


Some examples:

Remove all the rules set on a per-server basis (it removes also rules set for the nodes)
nxserver --ruledel --system

Remove all the rules set for node: testdrive.nomachine.com
nxserver --ruledel --node testdrive.nomachine.com:4000

Remove rules set for user nxtest only
nxserver --ruledel --user nxtest

Remove all the rules set for guests
nxserver --ruledel --guest

Remove all the rules set for group: Developers
nxserver --ruledel --group developers

 

4. Profile Rules to Manage Sessions

 

4.1. Allowing or Forbidding Session Types

The general form of the command is:

nxserver --ruleadd --class session --type TYPE --value yes|no OPTION

Where TYPE can be any of the available session types listed below.

Note that creating rules for session types from 6 to 13 work only if server has the ConnectPolicy key enabled with the desktop=1 option set. Please consult the NoMachine Server Administrator's Guide for the Enterprise for more details.

Available on TYPE Possible Values Description
Windows, Mac OS X, Linux 1 physical-desktop yes|no Connect to a remote desktop session.
Linux 2 unix-xsession-default yes|no Run the default virtual desktop as set on the system
Linux 3 shadow yes|no Connect to a virtual desktop session (desktop sharing/collaboration)
Linux 4 windows yes|no Run a RDP session encapsulated into a virtual session
Linux 5 vnc yes|no Run a VNC session encapsulated into a virtual session
Linux 6 unix-console yes|no
Run a virtual Unix console application. It can be embedded into the player session window or be a floating window console depending on the user's choice: run or not the command in a virtual desktop
Linux 7 unix-desktop yes|no Run a virtual custom application embedded into the player session window
Linux 8 unix-application yes|no Run a virtual custom application. It can be embedded into the player session window or be a floating window application depending on the user's choice: run or not the command in a virtual desktop
Linux 9 unix-gnome yes|no Run a virtual GNOME desktop
Linux 10 unix-kde yes|no Run a virtual KDE desktop
Linux 11 unix-xdm yes|no Run a virtual desktop through the X Desktop Manager
Linux 12 unix-default yes|no Run a virtual session by using the default X client script on server
Linux 13 unix-script path to the script Run a virtual session by using the X client script on server as specified by path
Windows, Mac OS X, Linux 14 vms yes|no Connect to a VMware virtual machine configured for being available via VNC

Unix-based systems (requires NoMachine version 5 or later)

15 unix-remote yes|no Connect to the physical desktop of a Foreign node
Solaris Sparc
(obsolete)
16 unix-cde yes|no Run a virtual Solaris Common Desktop Environment. This session type is dismissed since v. 4.0

OPTION can be:
--system
--user USERNAME
--guest
–node NODE
--group GROUP


Some examples:

Forbid use: nxtest to connect to virtual desktops running on that host
nxserver --ruleadd --class session --type shadow --value no --user nxtest

Forbid guest users to connect to physical desktop of server host machine:
nxserver --ruleadd --class session --type physical-desktop --value no --guest

Forbid user nxtest to run RDP sessions
nxserver --ruleadd --class session --type windows --value no --user nxtest

Forbid all users to run VNC sessions on node testdrive.nomachine.com
nxserver --ruleadd --class session --type vnc --value no --node testdrive.nomachine.com:22

Forbid user nxtest to run a KDE session
nxserver --ruleadd --class session --type unix-kde --value no --user nxtest


Tip
If your server supports only connections to the physical desktop, do not forbid physical-desktop type on per-system basis or you will be no longer be able to connect by NoMachine to that host.

4.2. Rules for Sessions on the Remote Node

The general form of the command is:

nxserver --ruleadd --class node --type TYPE --value yes|no OPTION


TYPE is:

TYPE Possible Values Description
limit numeric value Limit the maximum number of concurrent sessions on the node
<node:port> yes|no Manage access to the specified node

where <node:port> is the name of the node as listed by the nxserver --nodelist command.


Name of the remote node is made of a hostname(or IP):port pair, as it appears in the list of nodes.


OPTION for the rule to limit the number of concurrent sessions on the node is:

--system
--node <node:port>


OPTION in case of rule for limiting access to the remote nodes is:

--system
--user USERNAME
--guest
--group GROUP

 

4.3. Limiting the Number of Connections on the Remote Node

The number of connections allowed on the remote node can be limited on a per-node basis or for all the nodes.

The general form of the command is:

nxserver --ruleadd --class node --type limit --value <value> OPTION

OPTION is:

--system
--node <node:port>


Some examples:

Limit the number of connections to 15 on node: testdrive.nomachine.com
nxserver --ruleadd --class node --type limit --value 15 --node testdrive.nomachine.com:4000

Limit the number of connections to 10 on all nodes
nxserver --ruleadd --class node --type limit --value 10 --system

 

4.4. Allowing or Forbidding Sessions on the Remote Node

The general form of the command is:


nxserver --ruleadd --class node --type <node:port> --value yes|no OPTION


OPTION is:

--system
--user USERNAME
--guest
--group GROUP


Some examples:

Forbid guest users to run sessions on node: testdrive.nomachine.com
nxserver --ruleadd --class node --type testdrive.nomachine.com:4000 --value no --guest

Forbid user: nxtest01 to run sessions on node: testdrive.nomachine.com
nxserver --ruleadd --class node --type testdrive.nomachine.com:22 --value no --user nxtest01

 

5. Profile Rules to Manage Services

 

5.1. Allowing or Forbidding Services

The general form of the command is

nxserver --ruleadd --class service --type TYPE --value yes|no OPTION


TYPE is:

TYPE Possible Values Description
audio yes|no Manage support for audio streaming from server to user's pc

microphone yes|no Manage support for voice input streaming from user's pc to server side
client-printer-sharing yes|no Manage connecting printers user's pc to the server side
server-printer-sharing yes|no Manage connecting printers from server to user's pc
client-disk-sharing yes|no Manage connecting disks and folders from user's pc to server side
server-disk-sharing yes|no Manage connecting disks and folder from server to user's pc
client-file-transfer yes|no Manage the ability of transferring files from user's pc to the server
server-file-transfer yes|no Manage the ability of sending files from server side to a specific user or to all users
client-network-sharing yes|no Manage connecting network ports (SMB, CUPS, ...) from user's pc to server side
server-network-sharing yes|no Manage connecting network ports (SMB, CUPS, ...) forwarding from server to user's pc
session-recording yes|no Manage creating and saving a video of the session
client-usb-sharing yes|no Manage forwarding of a USB device from user's pc to server side
server-usb-sharing yes|no Manage forwarding of a USB device from server to user's pc
client-smartcard-sharing yes|no Manage forwarding of smartcard from user's pc to server side

OPTION is:
--system
--user USERNAME
--guest
--node NODE
--group GROUP


Tip
Two-way services such as printer sharing or USB forwarding can be disabled or enabled on one side only, or on both. To disable or enable the service from client to server, set the rule named as client-servicename (e.g. client-printer-sharing). To completely disable the service, set the rules for both client and server side.


Some examples:

Forbid connecting disks
nxserver --ruleadd --class service --type server-disk-sharing --value no –system
nxserver --ruleadd --class service --type client-disk-sharing --value no –system

Disable audio support for guest users
nxserver --ruleadd --class service --type audio --value no --guest

Forbid file printing from local to remote for all users
nxserver --ruleadd --class service --type client-printer-sharing --value no

Disable USB forwarding for all users
nxserver --ruleadd --class service --type client-usb-sharing --value no –system
nxserver --ruleadd --class service --type server-usb-sharing --value no --system

Disable microphone on node testdrive.nomachine.com
nxserver --ruleadd --class service --type microphone --value no --node testdrive.nomachine.com:22

 

6. Profile Rules to Manage Features

 

6.1. Managing Features

The general form of the command is:

nxserver --ruleadd --class feature --type TYPE --value yes|no|value OPTION


TYPE is:

TYPE Possible Values Description
bandwidth value Set limit on bandwidth usage
client-clipboard yes|no Manage copy and paste from user's pc to server side
server-clipboard yes|no Manage copy and paste from server side to user's pc
manual-node-selection
yes|no Manage the ability for the user to select the node where the new virtual desktop session will be started instead of letting the server decide (load balancing).
enable-guest yes|no Manage the automatic provisioning of guest accounts. This is available on Linux only.
enable-multinode yes|no Manage support for multi-node. If the nodes are supporting virtual desktop sessions, apply by default the automatic selection of the node where the session has to be started (load balancing)
enable-profiles
yes|no Manage support for profiles

OPTION can be, depending on the feature type:


--system
--user USERNAME
--guest
--node NODE
--group GROUP

Tips
Rules for enabling/disabling multi-node support, the automatic generation of guests accounts and use of profiles can be applied only on a per-server basis.
Rules for enabling/disabling the manual selection of the node can be applied instead on a per-server or per-user basis.

Some examples:

Enable support for guest users
nxserver --ruleadd --class feature --type enable-guest --value yes --system

Forbid copy&paste operations for user: nxtest
nxserver --ruleadd --class feature --type client-clipboard --value no --user nxtest
nxserver --ruleadd --class feature --type server-clipboard --value no --user nxtest

Allow user: nxtest to choose the remote node where the session has to be started
nxserver --ruleadd --class feature --type manual-node-selection --value yes --user nxtest


Set limit on bandwidth usage on node testdrive.nomachine.com
nxserver --ruleadd --class feature --type bandwidth --value 1G --node --user nxtest testdrive.nomachine.com:22

 

6.2. Limiting Bandwidth

The general form of the command is:

nxserver --ruleadd --class feature --type bandwidth --value VALUE OPTION

VALUE is the value to be assigned to bandwidth, expressed in byte, kilobyte, megabyte or gigabyte. The unit of measure has to be specified as it follows:


byte -> B or b
kilobyte -> K or k
megabyte -> M or m
gigabyte -> G or g


OPTION is:
--system
--user USERNAME
--guest
--node NODE


Some examples:

Limit the bandwidth to 256K for each the guest users
nxserver --ruleadd --class feature --type bandwidth --value 256k --guest

Limit the bandwidth to 1G for user: nxtest
nxserver --ruleadd --class feature --type bandwidth --value 1G --user nxtest

Limit the bandwidth to 1G when a user runs sessions on node: testdrive.nomachine.com
nxserver --ruleadd --class feature --type bandwidth --value 1G --node testdrive.nomachine.com:4000

 

6.3. Controlling Clipboard Functionalities

The general form of the command is:


nxserver --ruleadd --class feature --type TYPE --value yes|no OPTION


TYPE can be: client-clipboard or server-clipboard.


OPTION is:
--system
--user USERNAME
--guest
--node NODE
--group GROUP


Some examples:

Disable copy&paste operations from within the NX session to local for all users
nxserver --ruleadd --class feature --type server-clipboard --value no --system

Disable copy&paste operations for guests
nxserver --ruleadd --class feature --type client-clipboard --value no –guest
nxserver --ruleadd --class feature --type server-clipboard --value no –guest

Disable copy&paste operations on node testdrive.nomachine.com
nxserver --ruleadd --class feature --type client-clipboard --value no --node testdrive.nomachine.com:4000
nxserver --ruleadd --class feature --type server-clipboard --value no --node testdrive.nomachine.com:4000

 

6.4. Enabling or Disabling Manual Node Selection

This applies only to Linux Nodes supporting virtual desktop sessions.

The manual node selection is disabled by default, i.e. it is up to the server to automatically select the node where the new session has to be started. The general form of the command to enable or disable the manual node selection is:

nxserver --ruleadd --class feature --type manual-node-selection --value yes|no OPTION


OPTION is:

--system
--user USERNAME
--guest
--group GROUP


Some examples:

Allow user: nxtest to select the node where to start the NX session
nxserver --ruleadd --class feature --type manual-node-selection --value yes --user nxtest


Allow all users to select the node where to start the session
nxserver --ruleadd --class feature --type manual-node-selection --value yes --system


Disable the manual node selection
nxserver --ruleadd --class feature --type manual-node-selection --value no --system

 

6.5. Enabling or Disabling Support for Guest Users

The automatic generation of guest accounts is available on Windows, Mac OS X and Linux starting from version 4.1. Previous versions were supporting guests on Linux only. The automatic creation of guests is disabled by default. The general form of the command to enable or disable support for guest users is:

nxserver --ruleadd --class feature --type enable-guest --value yes|no --system


Some examples:


Enable the automatic provisioning of guest accounts
nxserver --ruleadd --class feature --type enable-guest --value yes --system


Disable the automatic provisioning of guest accounts
nxserver --ruleadd --class feature --type enable-guest --value no --system

6.6. Enabling or Disabling Multi-node Support

The general form of the command to enable or disable multi-node is:

nxserver --ruleadd --class feature --type enable-multinode --value yes|no --system

If the node is a Linux host and virtual desktop sessions are available, the server adds this node automatically to the list of nodes available for load-balancing if not otherwise specified.


Tip
In the case of Linux nodes with support for virtual desktop sessions, if you have disabled load balancing, you can still have access to the remote nodes by enabling the manual selection of the nodes.


Some examples:

Disabling Multi-node
nxserver --ruleadd --class feature --type enable-multinode --value no --system

Enabling Multi-node
nxserver --ruleadd --class feature --type enable-multinode --value yes --system

 

7. Introducing Multi-Node Concepts

A multi-node set-up with NoMachine is basically constituted by:

1) A NoMachine host that acts as a gateway to let users access multiple machines from a unique IP. This host is generally called 'the server'.

2) A number of other NoMachine hosts that are 'behind' the server and are called 'the nodes' or 'the remote nodes'.

3) If high availability is necessary, consider adding a second server to the multi-node environment. This is a 'cluster'.

How sessions work in a multi-node environment

Until you add the remote nodes to the server, the session always starts on the server host machine.So, first of all you have to make the server aware of the remote nodes by adding them to the server. You can add or remove a node at any moment, as well as you can stop access to a specific node when needed. Nodes can be running different platforms: you can Windows nodes as well as Linux and Mac OS X nodes.

When users connect to the server, they will see the physical desktop of all nodes listed in the connection list. If remote nodes support also virtual desktop sessions, they will be automatically part of the load-balancing list and it will be up to the server to choose on which node the session will be started. The server selects the node according to a round-robin mechanism, but it's also possible to configure the server to use a weighted round-robin algorithm. As a further option, you can configure the server to allow a specific user or all users to choose the node for the virtual desktop session. This is called 'manual node selection' and can be activated via profile rules.

Virtual Desktop sessions started on a node are persistent: user can disconnect and reconnect their virtual sessions and leave applications running unless the server is configured to disable reconnection capabilities.

Once you have prepared your multi-node setup, you can evaluate the possibility to set up high availability by putting two servers in cluster. In such environment, the secondary server becomes operative when the main server goes down. This mechanism permits to keep sessions alive.


How to set-up a multi-node environment

In order to set up a multi-node environment, it is necessary to install the NoMachine Enterprise Server (or the Cloud Server) on the machine which acts as single entry point (the server).

On the nodes, install an Enterprise Desktop or if the node is Linux any of the following packages:

Enterprise Desktop
Terminal Server Nodes
NoMachine Workstation
Terminal Server

Enterprise Server and Cloud Server installations can be also used as nodes.

If you want to activate the cluster, you need to have two installations of Cloud or Enterprise Server.

To let users to connect to remote nodes, it's necessary that they have a valid system account on each node.

 

8. NoMachine User Administration on the Node Host

 

8.1. Adding a System Account

The general form of the command is:

nxserver --useradd USERNAME --system

For example:

Create a system account for user: nxtest
nxserver --useradd nxtest --system

 

8.2. Removing a System account

The general form of the command is:

nxserver --userdel USERNAME --system

For example:

Delete system account for user: nxtest
nxserver --userdel nxtest --system --home

 

9. Setting-up the Multi-Node Environment

These are steps necessary to set-up a multi-node environment:


Step 1 - Ensure that users have a valid system account on the server host and on the nodes. Username must be the same on all machines but password can be different. You can create accounts by using the system tool or the NoMachine server command.


Step 2
- Add the node to the server. You have to execute such operation on the server host.

 

IMPORTANT

Starting from version 5, whichever Unix-like workstation or server with an X Window System (i.e. a graphical user interface based on X) can be integrated in a NoMachine multi-node environment without the need to install the NoMachine software on such host.

In a NoMachine server multi-node environment these Unix-like hosts are named Foreign nodes to distinguish them from NoMachine nodes which Linux hosts with a proper NoMachine product installed (for example the Terminal Server Node).

Commands to manage Foreign nodes specifically are handled at paragraph: 14. Using NoMachine 5 or later to access unsupported Unix-based systems (foreign nodes).

9.1. Adding the Node to the Server

This operation has to be done on the server host. The general form of the command is:


nxserver --nodeadd NODE OPTIONS


OPTIONS are any of the following:

--protocol NX|SSH|HTTP        
Connection to the node uses by default NX protocol and port 4000. Use the --protocol option to set a different protocol. HTTP is not supported yet.
--port <port>
Specify port for the selected protocol. Default is 4000 for NX and 22 for SSH.
--load-balancing yes|no         
Add or remove a node from the list of nodes available for load balancing
--label LABEL Allow to specify a short note (80 characters) for the node.
--comment            COMMENT                             
Allow to specify a longer note (1024 characters) for the node.
--weight WEIGHT                                  
Specify a weight for the node. Weight is used when the server is configured to use a custom algorithm for load-balancing virtual sessions. This value is used by the NoMachine custom script for weighted round-robin.
--limit  LIMIT                                                    
Set the maximum number of concurrent connections allowed on that node. This value is used by the Nomachine custom script for weighted round-robin.

When running the --nodeadd command, NoMachine Server tries to connect to the node. If it cannot authenticate using NoMachine servers public key, it will ask you to login as a privileged user to that node and will try to add the server public key there.


If connecting completes succesfully, server will retrieve information from the node, including a list of resources available there.


If connecting fails, the server will add the node to its NX Nodes db, but will not be able to store information. In this case, it 's mandatory to update node info as soon as connection with that host can be established.

Tip
You need to specify --protocol only if you want to use SSH between the server and the node.

Some examples:

Add node: testdrive.nomachine.com and specify a label
nxserver --nodeadd testdrive.nomachine.com --label "Test Drive machine"


Add the Terminal Server Node testdrive, but exclude it from the load balancing list
nxserver --nodeadd testdrive --load-balancing no


Add an Enterprise Desktop, testdrive2, and assign a weight and a limit for connections
nxserver --nodeadd testdrive2 --weight 2 --limit 3

 

10. Configuring the Multi-Node Environment

 

10.1. Enabling or Disabling the Manual Selection of the Node

Manual Selection applies only to nodes that support virtual desktop sessions. By default, when user chooses to create a new virtual desktop, the server chooses automatically on which node to start that desktop. The choice is made according to a round-robin mechanism.

Instead of letting the server decide, it's possible to enable the manual node selection. In this case the user will be provided with the list of all nodes and will be able to choose one.

To enable the manual node selection, you have to create a profile rule. For example the following rule gives all users the possibility to decide where to start their virtual desktops:

nxserver --ruleadd --class feature --type manual-node-selection --value yes

 

10.2. Limiting Number of Concurrent Connections on the Node

When multi-node support is enabled, it is possible to limit the number of concurrent sessions on the nodes by means of profile rules. For example to allow only 10 virtual desktops on each nodes:

nxserver --ruleadd --class node --type limit --value 10

10.3. Creating a Pool of Nodes for Specific User(s)

Support for profiles allows to create rules for allowing or forbidding to start sessions on the specified node(s). This set of rules can be applied to all users, to a specified user, to a group or to guest users. For example, to forbid group 'developers' to access node host with IP 192.168.2.145:

nxserver --ruleadd --class node --type 192.168.2.145:4000 --value no --group developers

 

11. Managing Nodes in the Multi-Node Environment

 

11.1. Listing the Available Nodes

The general form of the command is:


nxserver --nodelist [ NODE] [OPTIONS]


If NODE is specified, it displays details only about this particular node.


OPTIONS can be:

--comment Display also comment for each of the listed nodes, if present
--resource Display also list of resources available on each of the nodes


Some examples:

List all the available nodes
nxserver --nodelist

Retrieve information about node: testdrive.nomachine.com
nxserver --nodelist testdrive.nomachine.com:4000

Retrieve the comment, if present
nxserver --nodelist testdrive.nomachine.com:4000 --comment

Retrieve information about resources available on the node:
nxserver --nodelist testdrive.nomachine.com:4000 --resource

 

11.2. Modifying Values Set for the Node

It is possible to modify some of the information stored for the node by using the following command:

nxserver --nodeedit NODE:PORT OPTIONS

NODE is the hostname or the IP of the machine as specified when the node has been added to the server.

PORT is the port as specified when the node has been added to the server. By default it is 4000.

OPTIONS are any of the following:

--load-balancing yes|no If not provided, the node is added to the load-balancing list (only for nodes supporting virtual desktop sessions)
--label LABEL
Specify or modify the short note (80 characters) for the node.
--comment COMMENT
Specify or modify the longer note (1024 characters) for the node.
--weight WEIGHT          
Set or update weight for the node. This value is used by the NoMachine custom script for weighted round-robin.
--limit LIMIT                             
Set or update maximum number of connections allowed on that node. This value is used by the NoMachine custom script for weighted round-robin.

 

Tip
To modify name of the node, remove it and add it again by specifying the new IP or hostname.

Some examples:

Exclude node testdrive.nomachine.com:4000 from load-balancing list
nxserver --node edit testdrive.nomachine.com:4000 --load-balancing no

Modify comment for the node testdrive.nomachine.com:4000
nxserver --node edit testdrive.nomachine.com:4000 --comment "NoMachine Test Drive is installed on this host"

 

11.3. Keeping Node Resource List Up-to-Date

When a new resource is made available on the node, it is necessary to synchronize information on server side accordingly. The general format of the server command to do that is:

nxserver --nodeupdate NODE:PORT

NODE is the hostname or the IP of the machine as specified when the node has been added to the server.

PORT is the port as specified when the node has been added to the server. By default it is 4000.

Tip
If server was not able to connect to the node during the 'nodeadd' operation, ensure that the node machine is reachable and try to run the nxserver --nodeupdate command.


For example:

Update list of resources available for node testdrive.nomachine.com
nxserver --nodeupdate testdrive.nomachine.com:4000

 

11.4. Using a Custom Algorithm for Load-Balancing Virtual Desktops

The Server allows to use a custom script to define a weighted round-robin algorithm for load-balancing virtual desktops.

NoMachine comes with a default custom script, written in perl which implements a basic weighted round-robin algorithm for the selection of the node. You can modify such algorithm or replace the custom script with your own.

This script is nxweightedroundrobin.pl placed in the /usr/NX/scripts/lb/ directory.

In the default script, intended to be just an example, given a weight for each node and a limit of connections for that node, the algorithm selects the node with an higher weight counted as:

weight = [weight of node] - [number of sessions connected to the node]


The node with the higher weight is the node where the session will be started.


If limit for connections on the node is reached, the algorithm falls back to choose the first node provided by the server list.


Weight of the node can be set when adding the node.


By default, the server uses the plain round-robin algorithm. You can configure the server to use a custom script by editing the server configuration file and set:

LoadBalancingAlgorithm custom

If you want to use a script different from the default one provided with the installation of NoMachine, specify path and name of the custom script in NodeSelectionScript key in the server configuration file.


Tip
You can add or modify weight assigned to a node by using the 'nxserver --nodeedit' command.

 

11.5. Using the Node Load Average for Load-Balancing Virtual Desktops

The Server can be configured to choose the node with the minimum load average. Edit the server configuration and set:

LoadBalancingAlgorithm load-average

 

12. Managing Access to the Nodes

 

12.1 Enabling and Disabling Connections to the Node

The general form of the command to enable and disable starting new connections to the node is:


nxserver --nodestart NODE:PORT

nxserver --nodestop NODE:PORT


NODE is the hostname or the IP of the machine as specified when the node has been added to the server.

PORT is the port as specified when the node has been added to the server. By default it is 4000.


To check the status of a specified node:

nxserver --nodestatus NODE:PORT


Some examples:

Disable starting connections to testdrive1 and testdrive2
nxserver --nodestop testdrive1:4000,testdrive2:22


Enable starting of sessions on testdrive2
nxserver --nodestart testdrive2:22

 

12.2. Removing the Node from the Multi-Node Environment

The general form of the command is:

nxserver --nodedel NODE:PORT

NODE:PORT


NODE is the hostname or the IP of the machine as specified when the node has been added to the server.

PORT is the port as specified when the node has been added to the server. By default it is 4000.


For example:

To remove node testdrive.nomachine.com
nxserver --nodedel testdrive.nomachine.com:4000

 

12.3. Disabling Direct Access to the Node

If you have a multi-node environment with Enterprise Desktop, Workstation or Terminal Server as nodes, you might want to disable direct access to such node machines.

To do that, disable accepting connections by running on the node machine:

nxserver --stop

The Enterprise Desktop, Workstation and Terminal Server products are server products to give access to the host machine. They can be federated under an Enterprise Server or Cloud Server to be part of a multi-node environment.

 

12.4. Difference Between Terminal Server and Terminal Server Node

The main difference between using a Terminal Server or a Terminal Server Node in a multi-node environment is that the Terminal Server is a server able to accept direct connections to its host. The Terminal Server Node, instead, refuses all direct connections.

 

12.5. Disabling Multi-Node Support

Multi-node support can be disabled via profile rules. When multi-node capabilities are disabled, the session will always start on the NoMachine server host machine. To disable multi-node, run on the server:

nxserver --ruleadd --class feature --type enable-multinode --value no

13. Activating Failover Cluster (High Availability) in a Multi-Node Environment

 

13.1. Prerequisites

Pre-requisites for creating the cluster are:

1) You have 2 machines with NoMachine Enterprise Server (or Cloud Server) installed, let's call them ES1 and ES2.

2) You have Enterprise Desktop, Workstation, Terminal Server and/or Terminal Server Node installed on the nodes.

3) You have already configured your multi-node environment by adding nodes to one server ES1, the main server.

IMPORTANT:

The main server will become the master server in the cluster and you have to make all configurations for the cluster on that server ES1 (i.e. on the master server).

The second server (ES2) will be the passive server, ready to replace the master server in case of failure.

 

Please refer also to this document about prerequisites for a Multinode Environment with Load Balancing of Virtual Desktops and Failover Cluster:

https://www.nomachine.com/DT03L00066

 

Important note for versions prior to 4.1:

Until automatic synchronization of SSHD keys between cluster units is implemented, it's necessary that you synchronize such keys manually before creating the cluster.

This is necessary if SSH protocol will be used in cluster, SSHD host keys have to be synchronized across the cluster.

The default locations of private keys is:

Linux
/etc/ssh/ssh_host_dsa_key
/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_rsa_key

MacOSX
/etc/ssh_host_dsa_key
/etc/ssh_host_ecdsa_key
/etc/ssh_host_rsa_key

Windows
<install_dir>/NoMachine/etc/keys/host/ssh_host_dsa_key
<install_dir>/NoMachine/etc/keys/host/ssh_host_rsa_key

 

13.2. Setting-up and Configuring the Cluster

In order to enable cluster functionalities you have to add 2 servers to the cluster: the main server  (master server) and the secondary server (slave server) which acts as a backup of the master server in case of failure:

Steps:

- Identify which server host will be the master server (ES1) and which will be the secondary server (ES2)

- Remove the master and the secondary server from the list of nodes available for load-balancing (Par. 13.3)

- Set-up the master server for the cluster (Par. 13.4)

- Set-up the secondary server for the cluster (Par. 13.5)

 

IMPORTANT:

Remember to restart the master server and the secondary server once you have added both of them to the cluster as explained in the next 2 paragraphs.

Additionally, when the cluster has activated the failover procedure because the master server has become unreachable, it will not switch back automatically to the original configuration once that machine is up and running again. To do that, it's necessary to restart both servers in the cluster.

 

13.3. Removing Localhost from the List of Available Nodes

To have an efficient failover cluster, it's necessary that 'localhost' is removed from the list of nodes available for the load-balancing of sessions. Otherwise if sessions are started on the node locale to the server, there will be no way to recover them in case of server failure.

To remove the localhost node:

1) Identify the node locale to the server by running:

nxserver --nodelist

2) Remove the local node:

nxserver --nodedel NODE:PORT

e.g.

nxserver --nodedel localhost:22

 

13.4. Adding the Master Server to the Cluster

Given that ES1 is the server already configured for the multi-node environment. It will become the master server. On this server you have to execute:

nxserver --clusteradd --local <local IP of ES1> --shared <IP of the cluster host>

Command above adds the ES1 machine to the cluster and set it as master server.

IMPORTANT: Remember to restart the master server once you have added also the secondary server.

You can also configure cluster options at this stage. The general form of the command is:

nxserver --clusteradd --local <server> --shared <cluster> OPTIONS

OPTIONS can be:

--master <server>
--proto <protocol:port>
--interface <interface>
--netmask <mask>
--grace <time>
--retry <number>
--probe <time>
--interval <number>]
--timeout <number>

They allow to specify the following:

1) If you want to specify a master server different from ES1, use the --master option. We strongly advise for sake of simplicity, to set-up the cluster from the master server host.

2) The supported protocols are NX and SSH which uses port 4000 and 22 respectively. Protocols and ports can be specified as a comma-separated list by using the --proto options, e.g. proto nx:4000,ssh:22

3) --interface and --netmask parameters allow to a network interface and subnet mask for the cluster different from the default 'eth0:0' and '255.255.255.0'.

The virtual network interface (by default eth0:0) is always created on the master server. It's created on the secondry server only when it's detected that connection with the master server is lost.

4) Grace period is time to be elapsed at cluster startup before initiating the failover procedure and is set by default to 30 seconds while retry interval is 10 seconds. Change them by using the --grace and --retry options respectively.

5) Probe timeout indicates for how long cluster monitor must stay connected to a cluster machine and interval for probing specify how often the monitor must probe status of cluster machines. They are set to 60 and 5 seconds. Provide --probe and --interval to modify these values.

6) Cluster timeout is for how long cluster monitor has to wait before considering the machine as faulty. It is set to 10 seconds. It can be modified by issuing the --timeout parameter.

 

13.5. Adding the Secondary Server to the Cluster

Given that ES2 is the secondary server, it will become the passive server in the cluster. You have to run the following command on the master server (the ES1 machine) to add ES2 to the cluster:

nxserver --clusteradd <local IP of ES2>

 

Syntax of command to add a machine to the cluster is:

nxserver --clusteradd <server> OPTIONS

where OPTIONS can be:

--interface <interface>
--netmask <mask>

Options --interface and --netmask are available to specify a network interface and subnet mask different from default 'eth0:0' and '255.255.255.0'.

IMPORTANT

Remember to restart nxserver on both the master and the secondary server:

nxserver --restart

 

13.6. Updating the Cluster Configuration

The following command allows to synchronize configurations of the cluster machine. You can run it on the master server ES1 or the passive server ES2 indifferently. Configurations will be propagated to all machines in the cluster.

You can use command below also to set a different network interface and/or subnet mask for the specified machine (<server> is the IP of that machine).

It allows to specify a different IP for the local host, the master host and the cluster host. Grace period, retry interval, probe timeout, probe interval and cluster timeout can be modified too.

The general format of the command is:

nxserver --clusterupdate OPTIONS

where OPTIONS can be:

<server> --interface <interface> --netmask <mask>
--local <server>
--master <server>
--shared <server>
--grace <time>
--retry <number>
--probe <time>
--interval <number>
--timeout <number>

 

13.7. How to replace the DSA key pair for the Cluster

Master and secondary server use a DSA key pair to connect and synchronize information between their databases. This key pair is valid only for the nx user.

You can generate a new SSH key pair for the cluster by running from console on the server host:

<path to>/bin/nxkeygen -k <path to>/etc/keys/cluster.id_dsa -p <path to>/etc/keys/cluster.localhost.id_dsa.pub -t dsa

Or by using standard ssh-keygen command from openssh.

Important:

If you are using NoMachine tools on Linux or Mac OS X, you have to set the LD_LIBRARY_PATH before running the nxkeygen tool. For example on Linux:

# export LD_LIBRARY_PATH=/usr/NX/lib
# /usr/NX/bin/nxkeygen -k /usr/NX/etc/keys/cluster.localhost.id_dsa -p /usr/NX/etc/keys/cluster.localhost.id_dsa.pub -t dsa

Then be sure that the new keys have the same name of the original ones and proper permissions and ownership. For example on Linux:

# chmod 600 /usr/NX/etc/keys/cluster.localhost.id_dsa
# chown nx:root /usr/NX/etc/keys/cluster.localhost.id_dsa
# chmod 644 /usr/NX/etc/keys/cluster.localhost.id_dsa.pub
# chown nx:root /usr/NX/etc/keys/cluster.localhost.id_dsa.pub



How to use the new key-pair

Propagate the new key to the secondary server by running on the master server the following command:

<path to>/bin/nxserver --clusterupdate

 

 

13.8. When is it Necessary to Update the Cluster?

Updating the cluster servers is necessary when:

a) The nodes database (/usr/NX/etc/nodes.db) has been changed, e.g. one or more nodes have been added or removed.

b) The host certificate has been changed on one or more remote nodes. This happens when the NoMachine software has been re-installed on the remote node.

c) A new key pair to access remote nodes has been generated

d) A new key pair to access cluster hosts has been generated.

 

To update the cluster configuration, run on the master or on the secondary server the following command:

nxserver --clusterupdate

 

13.9. Removing a Server Machine from the Cluster

Syntax of command to remove a server from the cluster is:

nxserver --clusterdel <server>

where <server> is IP of of the machine that must be removed.

 

13.10. A Practical Example

Let's assume that target is to federate 2 Cloud Servers into a cluster. The same procedure applies also to 2 Enterprise Servers.

Basic steps toward high availability:

1. Install your Cloud Server on let's say Cloud1

2. Install your nodes and associate with Cloud1 via:

# /usr/NX/bin/nxserver --nodeadd <ip of node>

For example:

# /usr/NX/bin/nxserver --nodeadd 172.17.10.12


3. Install your second Cloud Server on let's say Cloud2

4. Assign Cloud1 to be the master cluster server (execute the command on the master server):

# /usr/NX/bin/nxserver --clusteradd --local <ip of Cloud1> --shared <virtual IP to be shared across both Cloud Servers> --netmask (only needed if different than 255.255.255.0)

For example:

# /usr/NX/bin/nxserver --clusteradd --local 172.17.10.10 --shared 172.17.10.100 --netmask 255.255.0.0

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

# /usr/NX/bin/nxserver --clusteradd <IP of second Cloud Server, Cloud2> --netmask 255.255.0.0

For example:

# /usr/NX/bin/nxserver --clusteradd 172.17.10.11 --netmask 255.255.0.0

 

6. Restart nxserver on both the master cluster server and the secondary server:

# /usr/NX/bin/nxserver --restart

 

7. Connect via NoMachine client to virtual IP (172.17.10.100)


You can then verify that high-availability works as expected:

8. Kill Cloud1 and you will be disconnected

9. Reconnect to virtual IP (172.17.10.100) while leaving Cloud1 down and you should be given the option to reconnect to your existing session as Cloud2 should have now taken over duty.

 

14. Using NoMachine 5 or Later to Access Unsupported Unix-based Systems (Foreign Nodes)

Starting from version 5, whichever Unix-like workstation or server with an X Window System (i.e. a graphical user interface based on X) can be integrated in a NoMachine multi-node environment without the need to install the NoMachine software on such host.

In a NoMachine server multi-node environment these Unix-like hosts are named Foreign nodes to distinguish them from NoMachine nodes. A NoMachine node has a NoMachine server or node package installed.

Pre-requisites to integrate a Foreign node into a NoMachine multinode environment are:

1. A Unix-based operating system is running on the Foreign node, e.g. Solaris X86 , HP-UX, AIX, BSD etc ...

2. An X server is up and running on the Foreign node.

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

5. A system account is present for each user who will need to log-in from remote to the Foreign node.

6. The xauth command is installed on the Foreign node.

7. A system account with administrative privileges. It's preferable (but not mandatory) to use a privileged account for adding the Foreign node to the NoMachine multinode environment.

8. If NoMachine guest users are enabled, it's necessary to disable the screen lock on the Foreign node or guest users will be not able to log-in. This applies also to connections to NoMachine nodes.

Main differences between NoMachine and Foreign nodes are:

a. Users can run virtual desktops (multiple individual instances of the node desktop)  on the NoMachine Linux nodes while only connections to the physical desktop are possible on Foreign nodes.

b. Virtual desktop sessions can be load-balanced by the server automatically among the NoMachine nodes. Sessions on Foreign nodes cannot be load-balanced.

c. Connections to NoMachine nodes can use the NX or the SSH protocol. Connections to Foreign nodes must use  necessarily the SSH protocol.

d. NoMachine (Linux) nodes in load-balancing can be stopped and started, Foreign nodes cannot.

 

IMPORTANT:

All commands in the next paragraphs are intended to be run on the Enterprise Server or Cloud Server host where the multi-node environment is set-up.

14.1. Adding a Foreign Node to the NoMachine Server

The general form of the command to create to add a Foreign node is:

nxserver --nodeadd <node>  [--port <port>] [--label <label>] [--comment <comment>]  [--strict-host-key-checking yes|no] --foreign

where <node> is the IP or hostname of the foreign node.

The --port parameter allows to specify an SSH port different from the default 22.

Providing '--strict-host-key-checking no' will let the server to add the  automatically the host key to the known_hosts file.


For example:

nxserver --nodeadd 175.17.10.12 --label "This is a Foreign Node"  --foreign

 

During the nodeadd procedure, administrators will be requested to provide username and password of a system account on the Foreign node. Using a privileged account is not mandatory, but it could be preferable.

 

14.2.  Listing Foreign Nodes

Foreign nodes are listed in the output of the following command:

nxserver --nodelist  [--comment]

and are qualified by the 'foreign' attribute. NoMachine nodes are instead marked as 'NX'.

Provide the --comment option to display comments associated to the nodes, if any.

 

14.3.  Editing a Foreign Node

Label and comment of the Foreign node can be modified by using the correspondent option:

nxserver --nodeedit <node:port>   [--label <label>]   [--comment <comment>]

where <node:port> is the name of the node as it appears in the 'nxserver --nodelist' output.


To modify the port for SSH connections it's necessary to remove the node and add it again by specifying the new port using the --port parameter.

 

14.4. Updating  Resources for a Foreign Node

Updating resources for a Foreign node is necessary when the fingerpring of the node is changed for some reasons and the known_hosts file on the server host has to be updated accordingly.

The server command is:

nxserver --nodeupdate <node:port> [--strict-host-key-checking yes|no]

where <node:port> is the name of the node as it appears in the 'nxserver --nodelist' output.


Providing '--strict-host-key-checking no' will let the server to add the  automatically the host key to the known_hosts file.

 

14.5. Removing a Foreign Node

Command to remove a Foreign node is:

nxserver --nodedel <node:port>

where <node:port> is the name of the node as it appears in the 'nxserver --nodelist' output.

 

 

15. Guest Accounts

The automatic generation of guests accounts is available on all platforms since version 4.1. Previous versions support it only on Linux. This feature is not enabled by default and must be activated via profile rules.

Tuning of guest management can be done by editing the NoMachine server configuration file by keeping in mind that some advanced configurations related to disk quota settings are not applicable on Windows.

Regarding configuratins specific for guests, it is also possible to define a set of profile rules on a per-guest basis only. such rules will not apply to other users.

IMPORTANT

Guest users don't know their username and password and cannot unlock the screen if it's enabled.


Some notes for versions prior to 4.1:

To connect as Guest, it is necessary to select protocol SSH and 'Use NoMachine login' in the NoMachine player GUI.

Guest accounts cannot be created on the remote nodes.

15.1. Enabling the Automatic Generation of Guest Accounts

The general form of the command to create the rule for enabling/disabling support for guest accounts is:

nxserver --ruleadd --class feature --type  enable-guest  --value yes|no --system

The Server tries to create guest account with group 'guest'. The guest group must exist on the system. You can configure the server to use a different group already present on the system.

 

15.2. Configuring the Automatic Generation of Guest Accounts

The following server configuration keys allow to tune guest management:


Define range of names for guest accounts
The server creates guest accounts by adding a progressive number as a postfix to the base guest name. The range used for incrementing the postfix varies from a minimum and a maximum value. Base name and range for the postfix are configurable:


GuestName guest
BaseGuestUserId 10
GuestUserIdLimit 200


Define group for guest accounts
GuestUserGroup guest


Define where the server has to create the guest accounts' homes
GuestUserHome /home (e.g. for Linux)

Define for how long a guest account has to be kept before being expired
GuestUserAccountExpiry 2592000 (This value has to be set in seconds)


Define if guest accounts have to be deleted once expired

EnableGuestWipeout 1

 

15.3. Setting Disk Quota for Guest Accounts on Linux

The following server configuration keys allow to set disk quota for guest accounts:


EnableGuestQuota 0
GuestQuotaProtoname protoguest
GuestQuotaInodeSoftlimit 0
GuestQuotaInodeHardlimit 0
GuestQuotaBlockSoftlimit 0
GuestQuotaBlockHardlimit 0
GuestQuotaInodeGracePeriod 0
GuestQuotaBlockGracePeriod 0
GuestQuotaFilesystems all

 

15.4. Configuring Guest Sessions

Server configuration keys above define guest sessions management:


Define the maximum number of guests allowed to be created on this server
GuestUserLimit 10


Define the maximum number of sessions a guest can run on this server before the account expires

GuestUserConnectionLimit 5


Define for how long (in seconds) a guest can run the session before the account expires

GuestConnectionExpiry 0 (If value is set to 0, a guest's session is never terminated.)


Enable/disable persistence of virtual sessions for guest users
GuestUserAllowSuspend 1

 

15.5. Creating Profiles for Guest Accounts

Please refer to the section dealing with profiles.

 

15.6. Creating a Guest Account Manually

The general form of the command is:


--useradd --guest --system OPTIONS


OPTIONS can be any of the following options, if no option is specified, the server will create the account using the default settings configured for the useradd system command:

--home HOMEDIR
specify the Guest User's home. The value specified by command line overrides the value set in the server GuestUserHome configuration key.
--nohome don't create the Guest User's home.
--gid GID specify the Guest User's Group ID. The value specified by command line overrides the value set in the server GuestUserGroup configuration key.
--uid UID specify the user's User ID. The value specified by command line overrides the range of values defined by the server BaseGuestUserId and GuestUserIdLimit configuration keys.

Some examples:

Create a guest user account
--useradd --guest --system

Create a guest user account on Linux and specify where to create its home directory
--useradd --guest --system --home /tmp

 

15.7. Listing Guest Accounts

Guest accounts are not listed in the user list by default. To retrieve them, the general form of the command is:


nxserver --userlist --guest OPTION


OPTION is:

--home
list the guest users already expired but still having their home on the system

Some examples

List all the guest users
nxserver --userlist --guest


List all the guest users already expired and with a home on the system
nxserver --userlist --guest --home

 

15.8. Removing a Guest Account

The general form of the command is:


nxserver --userdel USERNAME --system OPTION


OPTION can be any of the following:

--home remove the Guest User's home.
--nohome don't remove the Guest User's home. This is the server default behavior


Some examples:

Delete a guest account from the system without removing its home
nxserver --userdel guest0010 --system


Delete a guest account from the system and remove its home
nxserver --userdel guest0010 --system --home

 

16. Redirecting the Session

Similarly to the concept of Web Server Redirection, session redirection works in this way: when NoMachine Server (let's call it Server A) receives a request to start a session, it does not actually serve that request, but instead redirects the client to another NoMachine Server (let's call it Server B).


Redirection may be triggered on the client IP address (or hostname) or on the username. If based on client IP or hostname, redirection can be made either before or after the user has authenticated on the NoMachine Server A host machine. If based on username instead, redirection will always be done after the user has authenticated on host machine A.


Note that when redirection occurs, users will be requested to provide their credentials to authenticate on NoMachine Server B.


Note that only NoMachine 4 supports redirect capabilities: if user is still using an older version of the client, they will be asked to upgrade the installation.

 

16.1. Redirecting on a Per-Client Basis

If based on client IP or hostname, redirection can be made either before or after the user has authenticated on the NX Server A host machine. The general format of the server command to manage the list of clients to be redirected is:


nxserver --hostadd CLIENT --redirect SERVER:PORT [--switch beforeauthentication |afterauthentication]


Where CLIENT can be hostname or IP address. A family of IP addresses can be set by using the star wildcard.

SERVER is the hostname or IP address of the server where the client will be redirected and PORT is the port where the client will contact that server.


If the --switch option is not provided, the server assumes that the redirection has to be done before the user's authentication on the system.


For example:

Redirect client 152.4.56.2 to testdrive.nomachine.com
nxserver --hostadd 152.4.56.2 --redirect testdrive.nomachine.com:4000

 

16.2. Specifying a Family of Client IPs or Hostnames to be Redirected

Multiple directives to redirect the same client IPs or hostnames to different servers are disallowed.

Some examples:

The following directives are not allowed:
Client IP Redirected to
192.168.1.1 server a
192.168.1.1 server b

The following directives, instead, are accepted:

Client IP Redirected to:
192.168.1.1 server a
192.168.1.* server b
192.168.*.* server c


The star wildcard can also be used when specifying hostnames. For example: *.nomachine.com.

 

16.3. Listing Per-Client Redirection Directives

The general format of the server command is:


nxserver --hostlist [CLIENT]


List the redirect directives specified for clients. If CLIENT is provided as hostname or IP address, display details only about this particular client. Specify CLIENT as IP address family by using the star wildcard to list all the available directives for that family.

 

16.4. Modifying Per-Client Redirection Directives

The general format of the server command is:


nxserver --hostedit CLIENT --redirect SERVER:PORT [--switch beforeauthentication |afterauthentication]


Allow to modify any of the parameter values set for the specified client, where CLIENT is the hostname or IP address of the client or a family of IP Address specified by using the star wildcard.


Some examples:


Modify redirection settings to redirect client 192.168.2.222 after the authentication

nxserver --hostedit 192.168.2.222 --redirect testdrive.nomachine.com:4000 --switch afterauthentication


Change redirection settings to redirect client 192.168.2.222 to a new server, nxhost.nomachine.com:
nxserver --hostedit 192.168.2.222 --redirect nxhost.nomachine.com:4000

 

16.5. Removing Per-Client Redirection Directives

The general format of the server command is:


nxserver --hostdel CLIENT


Delete from the NX databases the redirect directive to be applied to that client specified as hostname, IP address, or family of IP address.


For example:

Remove redirection settings for client 192.168.2.222
nxserver --hostde 192.168.2.222

 

16.6. Redirecting on a Per-User Basis

If based on username, redirection will always be done after the user has authenticated on host machine A.


If the user has to be created on the system or to be added to the NX password DB, the redirection directive can be specified when creating the user. Redirection directives for the user can then be edited at whichever moment.

The general format of the server command to create the user and redirect the session request based on the username is:


nxserver --useradd USERNAME OPTION


OPTION is, in this case:

--redirect
specify IP or hostname and port of the server where sessions run by that user will be redirected.


Some examples:


Create a new system user and redirect him/her to server testdrive.nomachine.com
nxserver --useradd nxtest01 --system --redirect testdrive.nomachine.com:4000


Add the user to the NX Users DB and redirect him/her to testdrive (the user must already exist on the system)
nxserver --useradd nxtest02 --redirect testdrive.nomachine.com:4000

 

16.7. Listing Redirection Directives for Users

The redirection directive, if set for the user, is displayed as output of the nxserver --userlist command used to list all the users. The general format of the command is:


nxserver --userlist

 

16.8. Editing the Per-User Redirection Directives

The general format of the server command to update a redirect directive is:


nxserver --useredit USERNAME --redirect SERVER:PORT


Modify IP or hostname and port of the server where sessions run by that user will be redirected.

For example:

Redirect system user nxtest01 to testdrive
nxserver --useredit nxtest01 --redirect testdrive.nomachine.com:4000

 

16.9. Disabling Per-User Redirection Directives

Specify --redirect none to disable redirection for that user. The general format of the server command is:

nxserver --useredit USERNAME --redirect none


For example:

Disable redirect directive for user nxtest
nxserver --useredit nxtest --redirect none

 

17. Access Remote Desktops by RDP and VNC

RDP and RFB sessions are available only on Linux because they are encapsulated inside a virtual desktop session. They use use the RDP and VNC clients respectively. So, prerequisite is that these RDP and VNC clients (by default rdesktop and vncviewer) are installed on the node host machine.

Support for RDP and VNC sessions is not enabled by default.

 

17.1. Enabling RDP and VNC (RFB) Sessions

Note that behaviour of RDP and RFB sessions is strictly related to features supported by the RDP and VNC clients. For example, running a Windows application as a single application is possible only if the version of the RDP client supports it.


To allow RDP sessions, it's necessary to perform the following operations on each of the NoMachine node machines you want to use for starting RDP sessions. A similar procedure can be followed to enable support for VNC sessions.

Step 1: Be sure you have an RDP client and a VNC client

Ensure that the RDP client is installed on the node host. NoMachine supports 'rdesktop' :

http://www.rdesktop.org/.

For VNC sessions you need to have the VNC client installed.


Step 2: Instruct NoMachine to launch the RDP client and the VNC client

Specify path and name of the command to launch the RDP client in the node configuration file, node.cfg.

To do that, ensure that the CommandStartRDP key is commented out and set a proper value. Some examples:

CommandStartRDP "rdesktop -f"

In a similar way for the VNC sessions, uncomment and edit the following key:

CommandStartRFB "vncviewer -fullscreen"


Step 3: Add RDP and VNC to the list of available session types on the node

Uncomment and edit the AvailableSessionTypes key in the node configuration file to add value 'windows'. Add 'vnc' for supporting VNC sessions. Depending on which desktop environment is available on the NoMachine Linux host, this key can look like:

AvailableSessionTypes physical-desktop,unix-gnome,unix-xdm,windows,vnc


Step 4: Add RDP and VNC to the list of available session types on the server

Do the same as for step 3 in the server configuration file.

Step 5: Inform NoMachine Server about the new session types on remote node

if the node is remote, update its resource list in the NX Nodes db on the server by running the 'nxserver --nodeupdate' command.


Tip
Enable RDP and/or VNC on the remote node before adding it to the server: you can then skip Step 4.

 

18. Administering the Server via GUI Tools with NoMachine 5 or Later

Starting from version 5, NoMachine client GUIs allow to perform some administrative operations on the server once the user is connected.

In the initial stage, only adding or removing nodes in a multi-node environment is supported. It's possible to add either nodes where the NoMachine server or node software is installed and Foreign nodes. (See par. 14. Using NoMachine 5 or later to access unsupported Unix-based systems)


Pre-requisites for managing the nodes via the GUI are:

1. The server supports a multi-node environment.

2. The logged user is a NoMachine administrator.

18.1. Giving NoMachine Administrative Privileges to the User

To give NoMachine privileges to an already existent system account, use the following command:

nxserver --useradd <username> --administrator

To create a new system account with NoMachine privileges, run the previous command with the --system option:

nxserver --useradd <username> --administrator --system



IMPORTANT:

NoMachine privileges allow the user to perform operations on NoMachine server and nodes but doesn't modify the system privileges of this user.

This implies that the NoMachine administrator can for example add nodes via the client GUI, but he/she will be forbidden to run the 'nxserver --nodeadd' from command line on a console on the server host.

 

18.2. Removing NoMachine privileges from the User's Account

To remove NoMachine privileges but preserve the account, use:

nxserver --userdel <username> --administrator