NXServer Admin Guide

NX 4 Server and Node System Administrator’s Guide

Prepared by:Silvia Regis

N°:D-010_001-NXS-DMN

Approved by:Sarah Dryell

Signature: Date:07/11/2011

Amended: A


D-010_001-NXS-DMN - Page1of51






Amended: A

Table of Contents1. NX Server and Node Administrator's Guide.....................................................5

1.1. About This Guide.......................................................................................61.2 Document Convention and Important Notices..........................................61.3 Resources on the Web..............................................................................6

2. The NX Installation and the Back End..............................................................82.1. An Overview of the Data Back End...........................................................82.2. The NX Server and NX Node Configuration Files ....................................9

4. NX Service Management................................................................................124.1. Server and Node Usage..........................................................................124.2. Server and Node Version .......................................................................124.4. Server Status ..........................................................................................124.5. Enabling and Disabling the NX Service..................................................124.6. Sending Messages..................................................................................134.7. Greeting Messages.................................................................................134.8. Information about the Hosting Operating System...................................134.9. List of Resources Available on NX Server ..............................................14

5. User Login Management ...............................................................................155.1. Configuring NX Server to Rely on System Password ............................165.2. Configuring NX Server to Rely on NX Password ...................................165.3. Enabling or Disabling the Use of NX Users DB......................................165.4. Replacing the Default SSH Key Pair with Keys Generated for Your Server.............................................................................................................175.5. Restoring the Default SSH Key Pair........................................................185.6. Configuring NX to Contact the Remote SSHD Daemon on a Port Different from Default 22 ...............................................................................195.7. Specifying the Remote SSHD Daemon ................................................20

6. NX Users Management on the Server Host...................................................206.1. Creating a System Account ....................................................................206.2. Creating an NX Account .........................................................................216.3. Enabling and Disabling an NX User........................................................216.4. Verifying an NX User...............................................................................226.5. Retrieving the NX User Authentication Type...........................................226.6. Modifying the System Password.............................................................236.7. Modifying the NX Password....................................................................236.8. Listing the NX Users................................................................................236.9. Removing a System Account .................................................................246.10. Removing an NX User...........................................................................246.11. Removing Administrator Privileges........................................................24







Amended: A

6.12. Configuring the User NX Directory on the Node...................................257. NX Sessions Management ............................................................................25

7.1. Listing Connected and Disconnected Sessions .....................................267.2. Listing Session History............................................................................277.3. Clearing Session History ........................................................................277.4. Configuring the NX Sessions History Backlog........................................277.5. Disconnecting the NX Session ...............................................................287.6. Terminating the NX Session ...................................................................287.7. Killing the NX Session ............................................................................287.8. Enabling the Automatic Disconnection of the Session ...........................297.9. Configuring the Maximum Number of Concurrent Sessions for a Single User ...............................................................................................................297.10. Configuring the Maximum Number of Concurrent Sessions.................307.11. Making Room for New Sessions on New Logins .................................307.12. Running the Session as Root User ......................................................307.13. Make Available a New Session Type....................................................30

8. Redirecting the NX Session ...........................................................................318.1. Redirecting on a Per-Client Basis...........................................................318.2. Specifying a Family of Client IPs or Hostnames to be Redirected ........328.3. Listing Per-Client Redirection Directives ................................................328.4. Modifying Per-Client Redirection Directives ...........................................328.5. Removing Per-Client Redirection Directives ..........................................338.6. Redirecting on a Per-User Basis.............................................................338.7. Listing Redirections Directives for the Users .........................................348.8. Editing per-User Redirection Directives .................................................348.9. Removing Per-User Redirection Directives ............................................34

9. Customizing NX Sessions .............................................................................359.1. Setting Size of Fonts when Run Inside the NX Session.........................359.2. Using a Different Graphical Client to Issue NX Dialogue Boxes and Messages.......................................................................................................359.3. Controlling Copy & Paste Operations......................................................359.4. Limiting the Clipboard Buffer...................................................................369.5. Starting or Resuming a Session by SSH -X............................................369.6. Run a Session on an Unsupported Platform...........................................379.7. Executing Custom Scripts on NX Server Events....................................379.8. Executing Custom Scripts on NX Node Events......................................39

10. Connections to Desktops and Collaborative Sessions ................................3910.1. Disabling Connections to the Physical Desktop....................................4010.2. Configuring Interaction Level to the Physical Display...........................4010.3. Enabling Authorization Requirement to Share the Physical Desktop.. .40







Amended: A

10.4. Disabling Connections to the Virtual Desktop.......................................4010.5. Configuring Interaction Level to the Virtual Desktop.............................4010.6. Requiring Authorization for Connecting to a Virtual Desktop ...............4110.7. The Connection Monitor........................................................................41

11. The NX Web Applications ............................................................................4111.1. Administering the Server: NX Server Manager ....................................4211.2. Enabling the NX Statistics.....................................................................4211.3. Starting and Stopping the NX Web Server ...........................................4311.4. Disabling the Automatic Starting of the NX Web Server.......................4311.5. How to Disable Access to the NX Web Applications.............................43

12. Sharing Resources and Printing with NX ....................................................4312.1. Sharing Files ........................................................................................4412.2. Disabling File Sharing...........................................................................4412.3. Configuring the Share Mount Point ......................................................4412.4. Disabling a File Sharing Protocol ........................................................4512.6. Sharing Printers.....................................................................................4512.7. Disabling CUPS Support .....................................................................4612.8. Configuring CUPS Back End.................................................................4612.12. Sharing USB Devices..........................................................................4812.13. Two-way File Transfer ........................................................................48

13. Supporting Audio and Microphone...............................................................4813.1. Enabling Audio ......................................................................................49

13.2. Checking and Updating the Audio Infrastructure...................................4914. Logging Facilities.........................................................................................49

14.1. Enabling Debug Level...........................................................................4914.2. Redirecting Logs to a Custom File .......................................................5014.3. Disabling the Logging of X Clients........................................................5014.4. Setting the Log Maximum Size..............................................................50







Amended: A

1. NX Server and Node Administrator's GuideWelcome to the System Administrator's guide for NX Server and NX Node 4. This

document is intended to be an overview of the NX server functionalities, an aid to administrators tuning the NX system behaviour to fit specific environments, and a guide to server and node command line tools.

NX Server Functionalities NoMachine offers a range of server products to meet different needs, which can vary from personal to business use. Basic functionalities are common to all the NX Server products. Additionally, there is a set of advanced functionalities, such as multi-node capabilities and profiles, which are supported only by some types of NX Server. A specific guide deals with such advanced functionalities.

Tuning the NX Server BehaviourOnce installed, NX Server is fully operative without the need to start services or configure the application. However, it is possible for the administrator to tune the NX system to fit specific scenarios. For example, the port on which the SSH server is listening can be customized to accept connections (by default, port is 22 for the SSHD). In this case, the behaviour of the NX Server can also be modified to gain control over certain functionalities such as the ability of executing copy and paste operations between local and remote desktop and vice-versa or the ability to log in as a root user.

The NX Server and NX Node Command Line ToolsBoth NX Server and NX Node put at the administrator's disposal a command line interface to execute operations such as add/delete users or list sessions. To access all these functionalities, it is necessary to be the root user. The complete list of available commands is provided by the nxserver and nxnode help.

The NX Web Applications The NX Server package includes a small Apache web server, nxhtd, the NX Server Manager, and the NX Web Player to administer the server and run sessions, respectively, via the Web. Once that the installation has been successfully completed, these applications should be up and running without the need for any further configuration.







Amended: A

1.1. About This GuideThis guide is organized in the following macro-sections:

NX BackendOverview on the NX Server backend, configuration files, and subscription files.

Management of the NX Services Retrieve information about NX Server, Node, and the hosting operating system, enable and disable the NX service, send communications to the end users.

Authentication Management NX Server authentication methods, replace the default DSA keys, tune NX to fit a custom SSHD daemon configuration, allow sessions to run as a privileged user (root).

NX User ManagementCreate and remove NX and system users, get information about the users, enable and disable the ability to start a session, give privileges to administer NX Server through the NX Server Manager Web interface.

NX Session ManagementGet information about sessions, disconnect and terminate sessions, tune the NX server behaviour to control functionalities such as use of clipboard and persistence of sessions. (Note that session persistence applies only to virtual desktop sessions.)

Custom ScriptsInstruct the server and/or the node to execute custom scripts triggered on server/node events.

Collaborative SessionsTune the behaviour of sessions connecting to either a physical or virtual desktop (e.g., the requesting of the owner's authorization before connecting to the desktop).

Resource Sharing, PrintingShare resources, transfer file from local to remote desktops and vice-versa, configure printing support, forward USB devices over the network.

Audio SupportManage audio and microphone support.







Amended: A

Logging FacilitiesManage log levels and log files.

1.2. Document Convention and Important Notices

The following conventions are used in this guide:

● BaseDirectory indicates the base directory where the NX binaries and libraries are installed. By default, the BaseDirectory is the /usr directory on Linux and /opt on Solaris.

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

● Commands are intended to be run from xterm or similar on the NX Server and NX Node host machine and to be executed as root user if not otherwise specified.

● Full path o the nxserver and nxnode programs is respectively: BaseDirectory/NX/bin/nxserver and BaseDirectory/NX/bin/nxnode.

● Server and node configuration files are server.cfg and node.cfg, respectively. They are placed in the BaseDirectory/NX/etc directory.

● A server or node configuration key must be uncommented to set a value different from the default, i.e., the '#' pre-pended to the configuration key name must be removed.

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

● Server and Node subscription files are server.lic and node.lic, respectively. They are placed in the BaseDirectory/NX/etc directory.

1.3. 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 NX PackagesThe latest version of the NX packages is available at: http://www.nomachine.com/download

Latest NewsTo stay updated with the most recent releases of the NX software, as well as the latest news, please subscribe to the NX mailing list: http://www.nomachine.com/mailinglist.php


http://www.nomachine.com/mailinglist.php

http://www.nomachine.com/download

http://www.nomachine.com/






Amended: A

The Installation Guides For detailed information about how to install and upgrade your NX installation, view the guides available at: http://www.nomachine.com/installation.php

The Knowledge BaseThe NoMachine Knowledge Base, http://www.nomachine.com/kb, provides technical documents especially for administrators as well as end-user guides, articles, and “how-to's.”

Leave Feedback About This GuideOur 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 http://www.nomachine.com/contactus.php, selecting Web Quality Feedback as your option.

2. The NX Installation and the Back End Installation of the NX software is made up of two parts: a set of configuration files and scripts and the binaries and libraries themselves provided as a compressed tar archive, which is extracted during the installation or update procedure.

2.1. An Overview of the Data Back EndThe back end to store data for managing NX users, nodes and sessions is made up

of the following data back ends (DBs). Those DBs are plain text files that are not intended to be edited manually:

BaseDirectory / NX/etc/administrators.db To manage users with administrative privileges, i.e., users who can run the NX Server Manager Web interface for administering the server, users, and sessions.

BaseDirectory / NX /etc/guests.db To manage all the information related to guest accounts on the server when support for automatic generation of accounts is available on the server.

BaseDirectory / NX /etc/ hosts.db To store the list of clients that have to be redirected to a different server.

BaseDirectory / NX/etc/nodes.db To manage information about NX Nodes when multi-node support is available.


http://www.nomachine.com/contactus.php

http://www.nomachine.com/kb

http://www.nomachine.com/installation.php






Amended: A

BaseDirectory / NX/etc/passwords.db To manage authentication to the server when the NX password DB is enabled.

BaseDirectory / NX/etc/profiles.db To manage all the rules set on a per-user and/or per-system basis when support for Profiles is available.

BaseDirectory / NX/etc/users.db To manage users who try to access the NX system.

The following DBs are used for storing information about sessions and their status:

● BaseDirectory/NX/var/db/closed/● BaseDirectory/NX/var/db/failed/● BaseDirectory/NX/var/db/running/

The other DBs, BaseDirectory/NX/var/db/stat and BaseDirectory/NX/var/db/nxmanager, are used by the NX Server Manager application. In particular, the stat db is where the nxstat daemon stores statistics data to be then queried and displayed via the Server Manager. Broadcast messages are temporarily stored to the following DB, until they have been sent to all the sessions:

● BaseDirectory/NX/var/db/broadcast

2.2. The NX Server and NX Node Configuration Files The configuration files for server and node are the server.cfg and node.cfg files,

respectively, placed in the BaseDirectory/NX/etc directory. For example, if the software is installed in the default location on Linux, it is:

● /usr/NX/etc/node.cfg● /usr/NX/etc/server.cfg

On Solaris:

● /opt/NX/etc/node.cfg● /opt/NX/etc/server.cfg







Amended: A

Format of the Configuration FilesStarting from NX Version 4, all the configuration files use a new format without the need for specifying additional separators such as equals and quotes. Quotes are necessary only if the specified value contains multiple parameters.

The Default ConfigurationNX Server and Node come with a default configuration that is sufficient to grant a working setup in the greatest majority of environments. It will be up to the NX administrators to tune the installation according to their specific needs by setting the related configuration keys.

In general, the server.cfg file allows the NX administrator to manage all the configurations for NX Server, such as authentication mechanisms, session management, and tuning of collaborative sessions.

The node.cfg file lets the administrator define specific behaviour for the node, such as logging the X clients stderr, specifying where to create the user's NX directory, or customizing the required paths according to the configuration of the machine where the node is running.

Both server and node configuration files include a number of keys, which allow the execution of custom scripts triggered on server and node events, respectively.

The NX Web Player and NX Server Manager Web applications included in the server package also come with a configuration file, manager.cfg, and webplayer.cfg file.

Make Changes to the Default Configuration Effective NX Server and Node configuration files are text files made up of a number of key-value pairs. A detailed description for each key, included accepted values, is available in the configuration files themselves. These files can be edited manually by means of a text editor such as "vi." In order for the setting of a key value to become effective, that key must be uncommented. There is no need to restart the NX services to make changes to configuration keys effective. Changes will be effective with the start of the next new session.

2.3. The NX Server and NX Node Subscription FilesNX Server and NX Node rely on, respectively, the server.lic and node.lic files to be

operative. These files are placed in the BaseDirectory/NX/etc directory. In the default installation on Linux, this is:







Amended: A

● /usr/NX/etc/server.lic● /usr/NX/etc/node.lic

On Solaris:

● /opt/NX/etc/server.lic● /opt/NX/etc/node.lic

The Evaluation PeriodNX Server and Node packages, which are available on the NoMachine website for evaluation, provide subscription files that are activated during the installation of the software and allow the use of this software for the evaluation period (30 days from the date of installation). Preview versions have a 60-day evaluation period starting from the date of build of these packages. Evaluation versions do not include access to the NoMachine Support Services and Technical Assistance. Feedback can be sent to the NoMachine Team online at http://www.nomachine.com/contactus.php

3. Set Up NX on Server and Client Side

In order to set up your NX Server, you need to perform the following steps: 1. Download the server package from the NoMachine website on your server host

machine and install it.2. Ensure that the remote SSHD daemon is up and running on the server host.3. Ensure that a system account is present on server host for allowing this user run

NX sessions there.4. Download and install the NX Player on your end-user's machine to run a session

via the local GUI. 5. As an alternative to run the session, point your browser at the following URL:

https://serverHost:4080 where server Host is either the IP or host name of the machine where you have installed the NX package. Please note that the installation comes with a self-signed SSL certificate intended to be a sample. This doesn't grant a secure connection. In order to secure your web application, please replace the SSL Certificate File, namely /usr/NX/etc/htd.crt and the SSL Certificate Key File /usr/NX/etc/htd.key with your own.


http://www.nomachine.com/contactus.php






Amended: A

4. NX Service ManagementNX Server and NX Node make available a set of command line tools to: retrieve

information related to the NX software and the system; manage the NX service; and perform operations that can vary from retrieving information to creating user accounts or managing NX sessions. For a complete list of the available commands, refer to the server and node usage below.

4.1. Server and Node UsageTo retrieve the list of available commands and their description:

nxserver --helpnxnode --help

4.2. Server and Node Version To retrieve the version of the running software:

nxserver --versionnxnode --version

4.3. Subscription InformationTo get relevant information about the subscription, such as subscription type and

the expiration date:nxserver --subscriptionnxnode --subscription

4.4. Server Status To retrieve the status of NX Server:

nxserver --status

4.5. Enabling and Disabling the NX ServiceThe general form of the command is:

nxserver --start | --stop | --restart | --shutdown

--start: allow sessions to start--restart: terminate all running sessions and perform a clean restart--stop: forbid sessions from starting







Amended: A

--shutdown: forbid sessions from starting and terminate all running sessions

Stopping the NX Server will stop also the other NX services such as the NX web server, nxhtd.

4.6. Sending MessagesThe general form of the command is:

nxserver --broadcast MESSAGE nxserver --message SESSIONID MESSAGE

MESSAGE is the the text of your message between quotes. The message can be sent to either a running or a disconnected session. In this case, users will get the message when they reconnect the session. For example: nxserver --broadcast “Text of your message“nxserver --message F46653240EA3A9C8DE6EFA2D4E947EF4 “Text of your message“

4.7. Greeting MessagesThe following keys available in the NX Node configuration file allow you to

personalize a greeting message that is displayed when a new session is started. (By default, no greeting messages are issued at session startup.) Uncomment these keys and edit the text of the message, for example:

NodeFirstLoginGreeting "Welcome to your first NX session"

NodeLoginGreeting "Welcome back to your NX session"

Message specified in the NodeFirstLoginGreeting key is displayed only the first time a user runs a session on that node. Message specified in the NodeLoginGreeting key is shown each time a user starts a new session.

4.8. Information about the Hosting Operating SystemTo retrieve information about the version and operating system of the host machine:

nxserver --osquerynxnode --osquery

To retrieve which type of desktop sessions are available on the host machine:







Amended: A

nxserver --desktoplistnxnode --desktoplist

To retrieve information about the version of any of the available desktop types on the node host:

nxnode --desktopquery [--type=TYPE]

where TYPE can be for example unix-gnome or unix-kde if the Gnome or the KDE desktop is available. List of TYPES available on that machine can be retrieved by running the previous command, nxnode --desktoplist.

4.9. List of Resources Available on NX Server The general form of the command to retrieve information about resources available

on the server is:

--resourcelist [CLASS] [ --value=[ yes | no ] ] [ --user[= USERNAME ] | --guest ]

where CLASS is:

--session --service --feature

To retrieve the list of all session types that can be run on the server:

nxserver --resourcelist --session --value=yes

In the sample above, the list of session types is compared against the available desktop types as retrieved by the --desktoplist command. If NX Server supports profiles and has rules set, the resource list is compared also against the rule list.

You can find below a list of all types available for each CLASS:

Class Type

session unix-kde session unix-default







Amended: A

session shadow session unix-xdm session windows session unix-cde session unix-gnome session unix-application session unix-desktop session vnc session unix-console session unix-script service shares service audio service server-file-transfer service server-printing service microphone service client-file-transfer service session-recording service client-printing feature manual-node-selection feature server-clipboard feature enable-profiles feature enable-guest feature enable-load-balancing feature client-clipboard feature bandwidth

5. User Login Management NX Server supports all the login methods listed below. Users can select the login

method via the client GUI or it can be set by the NX administrator in the pre-configured session files.

Use the SSH S ervice and the NX L ogin The NX login is based on the initial authentication of the client as nx user. The nx user is created on the server machine during the package installation. This initial login is implemented by using a customizable DSA key-pairs. Users must then authenticate against the SSH subsystem by providing their system credentials. As an alternative, it is possible to enable the NX Password data back end (DB) so that the user has to provide the NX credentials to be able to start a session on that server. In this way, it is possible to forbid remote access to the system by any other means except NX .







Amended: A

Use the SSH Service and the System LoginThe user authenticates against the SSH subsystem: password-based and key-based authentication are both supported. This configuration easily integrates with different system authentication mechanism such as kerberos tickets or smart card. If the authentication based on the NX Password DB is enabled, user will be asked to provide their credentials twice: the first time to authenticate against the SSH subsystem and the second time to authenticate against the NX password DB.

Enabling or D isabling NX U sers A further level of control, relying on the NX Users DB, can be achieved by enabling only a restricted group of users to connect to NX Server. This configuration can be applied either combined with the system or NX authentication. When the use of NX Users DB is activated, each user can be enabled or disabled, i.e., he or she is allowed or forbidden to start sessions on that NX server.

5.1. Configuring NX Server to Rely on System Password By default, NX Server is configured to rely on the system password, i.e., the

EnablePasswordDB key is disabled in the server configuration file:

EnablePasswordDB 0

5.2. Configuring NX Server to Rely on NX Password To activate authentication based on the NX password DB, the following key has to

be enabled in the server configuration file:

EnablePasswordDB 1

5.3. Enabling or Disabling the Use of NX Users DBBy default, the use of NX Users DB is disabled. To activate it, the following key has

to be enabled in the server configuration file:

EnableUserDB 1

To disable the use of NX Users DB, deactivate the key:

EnableUserDB 0







Amended: A

Every time a new account is created via NX Server or an already existing systemuser runs the session for the first time, the user is added to the NX Users

DB, even when the use of NX Users DB is disabled. A list of all NX users included in the NX Users DB can be retrieved by running the nxserver --userlist command.

5.4. Replacing the Default SSH Key Pair with Keys Generated for Your ServerThe authentication between client and server, when the nx key is used, happens

through a DSA key pair. The public part is provided during the installation of the server, while the private part is distributed together with the NX Player or any of the the other client applications (such as NX Server Manager and NX Web Player). In order to replace the default keys used by clients, a new DSA key pair needs to be generated on the server and the private part must be distributed to the clients who want to get connected to that NX Server.

Generating a N ew DSA K ey P air Log in as root user on the NX Server host machine and run: nxserver --keygen

Distributing the New SSH Private Key to the ClientsGeneral steps to be made on server side are:

● Change the ownership and permissions on the authorized_keys file. Depending on which O.S. the NX is running on, you may need to execute:

chown nx:root BaseDirectory/NX/home/nx/.ssh/authorized_keys2chmod 0644 BaseDirectory/NX/home/nx/.ssh/authorized_keys2

Or:

chown nx:root BaseDirectory/NX/home/nx/.ssh/authorized_keyschmod 0644 BaseDirectory/NX/home/nx/.ssh/authorized_keys

● Change the ownership and permissions on the following file:chown nx:root BaseDirectory/NX/home/nx/.ssh/default.id_dsa.pubchmod 0644 BaseDirectory/NX/home/nx/.ssh/default.id_dsa.pub







Amended: A

● The private part from the newly generated pair of keys is: BaseDirectory/NX/share/keys/default.id_dsa.key This private key has to be distributed to all clients that have to be granted access to the specific NX Server host.

General step to be made on client side is:

● Place the new key under the subdirectory 'share/keys' of the client installation tree reserved to this purpose.

Enabling NX Player to Use the New SSH Private Key ● In the case of NX Player, place the new key default.id_dsa.key under the

subdirectory 'share/keys' of the NX Player installation tree reserved to this purpose. ● To use the new key for a certain session, open the connection settings in the NX

Player GUI and select "Use the NX Login." Click on the correspondent button to open the "NX login panel," where you can specify the alternative key to be used for that session only.

● In order to use the new SSH key for all the NX sessions (except those sessions that have been previously configured to use a specific key), rename the original private key (i.e., BaseDirectory/NX/share/keys/server.id_dsa.key) to preserve it and rename the new private key from: BaseDirectory/NX/share/keys/default.id_dsa.key to: BaseDirectory/NX/share/keys/server.id_dsa.key

Enabling NX Server Manager and NX Web Player to U se the N ew SSH P rivate K ey When a new SSH key has to be used, the location and file name of the DSA key need to be specified in the NX Server Manager configuration file.

Edit the BaseDirectory/NX/etc/manager.cfg file and set a proper value for the SSHKey configuration key.

In a similar way for NX Web Player, edit the BaseDirectory/NX/etc/webplayer.cfg file and set a proper value for the SSHKey configuration key.

5.5. Restoring the Default SSH Key PairThe --keyrestore server command lets you restore the SSH key-pair provided with

the server package. The current public key will be moved to default.id_dsa.pub.backup file, while the current private key will be moved to the following file:







Amended: A

BaseDirectory/NX/share/keys/default.id_dsa.key.backup

Run the following command to use the default SSH key-pair:

nxserver --keyrestore

In order to restore the default SSH key in the NX Player, use the key management facilities provided by the NX Player GUI: access the connection settings, select "Use the NX Login" and click on the correspondent button to open the "NX login panel." Finally uncheck the checkbox that reads "Use an alternate server key."

To restore the default SSH key in the NX Server Manager and NX Web Player, edit the BaseDirectory/NX/etc/manager.cfg and BaseDirectory/NX/etc/webplayer.cfg files respectively and restore the original value for the SSHKey configuration key.

Default value for NX Server Manager: SSHKey /usr/NX/share/htdocs/nxmanager/keys/server.id_dsa.key

Default value for NX Web Player: SSHKey /usr/NX/share/htdocs/nxwebplayer/keys/server.id_dsa.key

5.6. Configuring NX to Contact the Remote SSHD Daemon on a Port Different from Default 22

If you have configured the SSHD daemon to use a port different from the default 22, you need to configure both server and node accordingly. That port value also has to be specified when trying to connect to the server by any of the clients (NX Player, NX Server Manager, and NX Web Player).

Configure NX ServerUncomment and set the proper SSH port number in the SSHDPort and SSHDAuthPort keys in the server configuration file. The SSHDPort allows to specify the TCP port where the NX server SSHD daemon is running. For example:

SSHDPort 2222

where the SSHDAuthPort key is to specify the TCP port where the SSHD daemon is







Amended: A

running on the NX SSH authentication server, e.g., SSHDAuthPort 2222

Configure NX NodeUncomment and set the proper SSH port number in the SSHDPort key in the node configuration file to specify the TCP port where the NX node SSHD daemon is running. For example:

SSHDPort 2222

5.7. Specifying the Remote SSHD Daemon By default, the NX Server configuration specifies that the SSHD daemon to be

contacted for the SSH authentication is running on localhost:

SSHDAuthServer 127.0.0.1

A remote SSHD daemon can be specified by uncommenting and setting a proper value for the SSHDAuthServer key in the server configuration file.

6. NX Users Management on the Server Host

6.1. Creating a System Account The general form of the server command is:

nxserver --useradd USERNAME --system OPTIONS [--administrator]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 user's home. The value specified by command

line overrides the value set in the server UserHome configuration key.

--nohome Don't create the user's home.--gid=gid Specify the user's Group ID. The value specified by command

line overrides the value set in the server UserGroupconfiguration key.

--uid=uid Specify the user's User ID. The value specified by command line overrides the value set in the server UserId configuration







Amended: A

key.--redirect SERVER:PORT Specify IP and port of the server where sessions run by that

user will be redirected.The --administrator option must be specified when you want to grant NX administrator privileges to the user. This is needed, in particular, when you want to manage your NX Server via the NX Server Manager web tool. When this option is specified, the user is added to the NX Administrators DB.

For example:

nxserver --useradd test_user --system nxserver --useradd test_user1 --system --administratornxserver --useradd test_user2 --system --home=/tmp/test_user --gid=tests

6.2. Creating an NX Account Creating an NX account is necessary when authentication is based on NX

Password DB. In this case, a NX account has to be created for each of the system user who will run sessions on that server: information for the NX account is stored in the NX Password DB. The general format of the command is:nxserver --useradd USERNAME [--administrator]

The --administrator option allows to assign administrative privileges to that NX Account and can be issued either when creating the account or later. These privileges are necessary if the user needs to be entitled of administering NX server, NX users, and sessions via NX Server Manager.

For example:

Create an NX account for system user nxtest01:nxserver --useradd test_user

Give privileges to user nxtest01 to administer NX via NX Server Manager: nxserver --useradd nxtest01 – administrator

6.3. Enabling and Disabling an NX UserThe following key has to be uncommented and activated in the server configuration

file to make NX Server rely on the NX Users DB and verify if the user is enabled or not to run sessions on that server:







Amended: A

EnableUserDB 1

The general form of the command to allow the user to start sessions on this server: nxserver --userenable USERNAME

and to forbid the user to start sessions:

nxserver --userdisable USERNAME

For example:

Disable user nxtest01:nxserver --userdisable nxtest01

Re-enable user nxtest01:nxserver --userenable test_user

6.4. Verifying an NX UserThe general form of the command is:

nxserver --usercheck USERNAME

It verifies the user's public key authentication and adds it, if necessary. If the use of NX Users DB is enabled in the server configuration file, it prints the status of the user, i.e., if the user is/is not allowed to start sessions on that server.

For example:

nxserver --usercheck user_test

6.5. Retrieving the NX User Authentication TypeThe general form of the command is:

nxserver --userauth USERNAME

It provides information about the authentication method in use, system authentication or NX Passwords DB, and whether the use of NX Users DB is enabled or not.







Amended: A

For example:

nxserver --userauth user_test

6.6. Modifying the System PasswordThe general form of the command is:

nxserver --passwd USERNAME --system

For example:

nxserver --passwd nxuser_test --system

The user can modify his or her own system password once they are logged to the server host by running:

nxserver --passwd --system

6.7. Modifying the NX PasswordWhen NX Passwords DB is enabled, the general form of the command is:

nxserver --passwd USERNAME

For example:

nxserver --passwd user_test

The user can modify his or her own password once they are logged to the server host by running:

nxserver --passwd

6.8. Listing the NX UsersThe general form of the command is:

nxserver --userlist

In the default server configuration, this command lists all the users stored in the NX







Amended: A

Users DB, which correspond to system accounts created via NX Server or to those users who have run at least one NX session. If the use of NX Users is enabled, this command provides the list of only those users who are enabled to start sessions on that server.

6.9. Removing a System Account The general form of the command is:

nxserver --userdel USERNAME --system OPTION

OPTION is any of the following:

--home Remove the user's home.--nohome Don't remove the user's home. This is the server default

behavior.For example:

Delete user nxuser01 from the system and remove its home:nxserver --userdel nxuser_test –system --home

6.10. Removing an NX UserTo remove an NX user from the NX Users DB and from NX Password DB (when

enabled), the general form of the command is:

nxserver --userdel USERNAME

For example:

Remove user nxuser01 from the NX DBs:nxserver --userdel nxuser_test

6.11. Removing Administrator PrivilegesIf the --administrator option is specified for the --userdel command, it revokes

administrative privileges for that user and removes it from the NX Administrators DB:

nxserver --userdel USERNAME --administrator

For example:







Amended: A

Revoke NX administrative privileges for user nxtest01nxserver --userdel nxuser01 --administrator

6.12. Configuring the User NX Directory on the NodeThe UserNXDirectoryPath key available in the node configuration file allows the NX

administrator to specify the path where the .nx directory (the directory where all the session files will be written) has to be created on the node. By default, the node creates the User NX directory (.nx) in the user's home. If this key is uncommented and activated, NX node will try to create (if it doesn't already exist) a directory named as username in the specified path, and the .nx directory will be created there.

For example, if this key is set to /tmp/nxdir/, the node will try to create the /tmp/nxdir/nxtest/ directory once user nxtest is running its first session and the .nx directory will be created there as: /tmp/nxdir/nxtest/.nx/.

Please note that the directory specified in the UserNXDirectoryPath key needs to have the proper ownership and permissions to ensure that the node, running as the user, can access it. Alternatively, the administrator could create a directory under the UserNXDirectoryPath with proper attributes for each of the users and named as username.

For example:

UserNXDirectoryPath /tmp/nxdir/

7. NX Sessions Management Each virtual desktop and remote desktop session is uniquely identified by its

session ID and display number (the number of display to which the nxagent process is connected). An NX session can be in any of the following statuses: ConnectedThe x11 agent process (nxagent) is running and it is connected to the remote display.

DisconnectedThe x11 agent process is running but it is disconnected from the remote display.

TerminatedThe X11 agent process has been cleanly terminated.







Amended: A

FailedThe X11 agent has failed to start or it has been "un-cleanly" terminated.

Transitional statuses are "Connecting," "Disconnecting," and "Terminating."

Virtual Desktop Sessions Connected and Disconnected When a virtual desktop session is in status "Connected," the default configuration of the server allows whichever user to connect to that session. Once a user is connected to the virtual desktop session, the NX Connection Monitor program is started to allow tracking of the connected users, send them messages, or disconnect them.

When a virtual desktop session is in "Disconnected" status, it can be reconnected at any time even from a different machine (migration). Disconnecting a session means disconnecting the nxagent from the remote display, and this doesn't have any implication on remote applications that stay running. Sessions in disconnected status are considered as running sessions, and they are enumerated by the server to determine the maximum number of concurrent sessions.

7.1. Listing Connected and Disconnected Sessions The general form of the command is:

nxserver --list [ USERNAME | SESSIONID ]

List all sessions in status "Connected" or "Disconnected." If USERNAME is given, the server will list only those sessions run by the given user. If the SESSIONID is provided, the server will show information available for the selected session.

For example:

List all the running sessions of user nxuser01:nxserver --list nxuser01

Retrieve information for the specified running session:nxserver --list F46653240EA3A9C8DE6EFA2D4E947EF4







Amended: A

7.2. Listing Session HistoryThe general form of the command is:

nxserver --history [ SESSIONID | USERNAME | clear ]

This shows the session history, including sessions that are terminated and sessions failed. If the option 'clear' is given, the history DB is reset. If SESSIONID is given, the server will show the complete set of information about the selected session. In the case of a failed session, the reason of the failure is provided. If USERNAME is specified, NX Server will list only the sessions run by the given user. The history backlog will last for the amount of seconds specified in the server configuration. By default, NX Server keeps session data for 30 days.

For example:

Retrieve session history for user nxtest01:nxserver --history nxtest01

Retrieve information for the specified session:nxserver --history F46653240EA3A9C8DE6EFA2D4E947EF4

7.3. Clearing Session History To clear the history run:

nxserver --history clear

7.4. Configuring the NX Sessions History BacklogTo set how long the NX Server will retain data related to NX sessions, the following

key has to be uncommented and properly set in the server configuration file:SessionHistory 2592000

This key accepts the following values: <0: Never delete data from NX session history. 0: Disable NX sessions history. >0: Keep data in session history for this amount of seconds.







Amended: A

7.5. Disconnecting the NX Session The general form of the command is:

nxserver --disconnect [ SESSIONID | DISPLAY | USERNAME ]

Disconnect the given session, identified by its session ID or display number, i.e., disconnect the nxagent from the remote display. If USERNAME is provided, NX Server will disconnect all the sessions run by the given user.

For example, if session has ID F46653240EA3A9C8DE6EFA2D4E947EF4 runs on display 1002 and is owned by user_test, it can be disconnected by running one of these commands:

nxserver -- disconnect F46653240EA3A9C8DE6EFA2D4E947EF4nxserver --disconnect 1002nxserver -- disconnect user_test

The nxserver --disconnect command replaces the obsolete --suspend command, still supported but deprecated.

7.6. Terminating the NX Session The general form of the command is:

nxserver --terminate [ SESSIONID | DISPLAY | USERNAME ]

Terminate the given session identified by its session ID or display number. If USERNAME is provided, NX Server will terminate all the sessions run by the given user.

For example:

nxserver --terminate F46653240EA3A9C8DE6EFA2D4E947EF4nxserver --terminate 1002nxserver --terminate user_test

7.7. Killing the NX Session The general form of the command is:

nxserver --kill [ SESSIONID | DISPLAY | USERNAME ]

Kill the given session, identified by its session ID or display number. If USERNAME







Amended: A

is provided, the NX Server will kill -9 all the sessions run by the given user. It is suggested to use this command only after having tried to terminate the session by means of the nxserver --terminate command which tries to first terminate nxagent cleanly.

For example, if session has ID F46653240EA3A9C8DE6EFA2D4E947EF4, runs on display 1002 and is owned by nxuser01, it can be killed by running one of these commands:

nxserver -- kill F46653240EA3A9C8DE6EFA2D4E947EF4nxserver -- kill 1002nxserver -- kill nxuser01

7.8. Enabling the Automatic Disconnection of the Session The nxagent's auto-disconnect feature can be activated by adding the " -timeout s"

option to the AgentExtraOptions key in the NX Node configuration file with s being the timeout in seconds. The minimum allowed timeout is 60 seconds.

For example, to terminate all sessions after 10 minutes of inactivity, uncomment the key and set:

AgentExtraOptions "-timeout 600"

If the agent doesn't receive any input from the user in the given timeout, it will terminate if the session is not persistent or no X application is connected to the display. Otherwise the agent will disconnect the session so that the X applications will be left running. (This last case applies to virtual desktop sessions only.)

7.9. Configuring the Maximum Number of Concurrent Sessions for a Single User Given the number of concurrent sessions allowed by the NX Server subscription

file, it is possible to define the number of allowed sessions for a single user by uncommenting and editing the SessionUserLimit key in the server configuration file.

For example:

SessionUserLimit 2

Note that custom value set for the SessionUserLimit can't be higher than number of concurrent sessions allowed by the server subscription file (the 'Connections' field in the server.lic file).







Amended: A

By setting SessionUserLimit to 1, the system administrator can force the user to terminate any disconnected session before starting a new one.

7.10. Configuring the Maximum Number of Concurrent SessionsThe number of sessions that can be run at the same time depends on how many

connections are allowed on the server. This value can be retrieved from the 'Connections' field in the subscription file, namely server.lic. In case of NX Server supporting unlimited connections, the default number of allowed sessions is 20. This value can be changed by uncommenting and updating the SessionLimit key in the server configuration file.

For example:

SessionLimit 30

The maximum per user/per total sessions depends on the power of the NX Server host machine, memory, and disk space. Consult the website for further details on server sizing and host requirements.

7.11. Making Room for New Sessions on New Logins When the following key is uncommented and enabled in the server configuration

file, the server will kill the oldest disconnected sessions to make room for the new ones as soon as the server capacity has been reached (i.e., the maximum number of concurrent sessions is going to be exceeded):

EnableAutokillSessions 1

7.12. Running the Session as Root User By default, NX prevents the running of sessions as root user. To enable this,

uncomment and activate the following key in the server configuration file:

EnableAdministratorLogin 1

7.13. Make Available a New Session TypeDuring the installation, the setup procedures verifies which session types are

available on that machine among: UNIX KDE, UNIX GNOME, Windows (RDP), and VNC. For example, if KDE is not already present on the system when installing NX, it can be







Amended: A

installed later. Then, the UNIX KDE session type can be made available to NX by adding it to list of values in the AvailableSessionTypes configuration key in both the node and server configuration file.

For example:

AvailableSessionTypes unix-gnome,unix-kde

8. Redirecting the NX Session Similarly to the concept of Web Server Redirection, when NX Server (for example,

NX Server A) receives a request to start a session, it does not actually serve that request, but instead redirects the client to another NX Server (for example, 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 NX Server A host machine. If based on username instead, redirection will always be done after the user has authenticated on host machine A.

Note: When redirection occurs after user authentication, once the client is redirected, the user will be requested to provide their credentials to authenticate on the NX Server B host machine again.

8.1. Redirecting on a Per-Client BasisIf 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, NX Server assumes that the redirection has to be done before the user's authentication on the system.







Amended: A

For example:

Redirect client with IP 152.4.56.2 to NX Server on testdrive.nomachine.com:nxserver --hostadd 152.4.56.2 --redirect testdrive.nomachine.com:22

8.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. For example, the following directives are not allowed:

Client IP Redirected to192.168.1.1 server a192.168.1.1 server b

The following directives are accepted:

Client IP Redirected to192.168.1.1 server a192.168.1.* server b192.168.*.* server c

The star wildcard can also be used when specifying hostnames.

For example:

*.nomachine.com.

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







Amended: A

8.4. Modifying Per-Client Redirection Directives


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.

For example:

Modify settings to redirect client with IP 152.4.56.2 after which it authenticates:nxserver --hostedit 152.4.56.2 --redirect testdrive.nomachine.com:22 --switch afterauthentication

8.5. Removing Per-Client Redirection Directives


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:

nxserver --hostdel 152.4.56.2

8.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 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 any time.







Amended: A

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

Use the --redirect option to specify IP and port of the server where sessions run by that user will be redirected.

For example:

Create a new system user and redirect him/her to testdrive:nxserver --useradd nxtest_01 --system --redirect testdrive.nomachine.com:22

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

8.7. Listing Redirections Directives for the 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

8.8. Editing per-User Redirection Directives The general format of the server command is:

nxserver --useredit USERNAME --redirect SERVER:PORT

Allow modification of IP and port of the server where sessions run by that user will be redirected. Specify --redirect none to disable redirection for that user.

For example:

nxserver --useredit nxtest_01 --redirect testdrive.nomachine.com:22

8.9. Removing Per-User Redirection Directives The general format of the server command is:

nxserver --useredit USERNAME --redirect none







Amended: A

nxserver --useredit nxtest_01 --redirect none

9. Customizing NX Sessions

9.1. Setting Size of Fonts when Run Inside the NX SessionIn some cases, font sizes displayed inside the NX session are smaller than size of

fonts displayed on the local display, even if the DPI reported by nxagent to its clients always matches the DPI reported by the real X server.

By uncommenting and updating value for the following key in the node configuration file, it is possible to set a different default value for the X server DPI:

DefaultXDPI 96

9.2. Using a Different Graphical Client to Issue NX Dialogue Boxes and Messages

In the NX Node configuration file, it is possible to specify a different program to show dialogue messages instead of nxclient, or to specify a different location for the nxclient binary instead of the default one (BaseDirectory/NX/bin).

Uncomment and edit the node configuration file to set a proper value for the following key:

CommandClient BaseDirectory/NX/bin/nxclient

If this key is enabled, NX Node sets the NX_CLIENT environment variable when running the nxagent process accordingly. In this way, when the agent needs to display a dialog box, it will use the program specified there. Furthermore, NX Node will run the command specified in this key every time it needs to launch the client.

Note: The alternative client should support all the options currently implemented by nxclient to ensure the same level of operation. For example, in case of remote desktop sessions, NX node runs nxclient with the --monitor option to start the NX Connection Monitor once the user is connected to the desktop. If the program specified in the CommandClient key doesn't support the --monitor option, the Connection Monitor will not be available.

9.3. Controlling Copy & Paste OperationsCopy and paste operations between the end-user local desktop and the NX session







Amended: A

(and vice-versa) can be allowed or forbidden by uncommenting and setting the proper value for the EnableClipboard key in the server configuration file.

By default, copy and paste is allowed both from the local desktop to the NX session and vice versa:

EnableClipboard both

This key accepts the following values:

clientThe content copied on the client can be pasted inside the NX session.

serverThe content copied inside the NX session can be pasted on the client.

bothThe copy and paste operations are allowed between both the client and the NX session and vice versa.

noneThe copy and paste operations between the client and the NX session are never allowed.

9.4. Limiting the Clipboard BufferBy default, the clipboard buffer is unlimited. The maximum amount of data, specified

in bytes, that can be copied from within the NX session to the client can be set by uncommenting and updating the ClipboardBufferLimit key in the node configuration file.

For example, to set the limit to 4MB:ClipboardBufferLimit 4194304

9.5. Starting or Resuming a Session by SSH -XThe general form of the command to allow the forwarding of the NX session, via

SSH, to any machine that has exported its X display for connection is:

nxserver --startsession OPTIONS [--display host:port]

OPTIONS is the list of options that can be specified for configuring the session and should be passed in the format –optionName=value. If no option is specified, the server







Amended: A

will assume the session is unix-default and will start it according to the user's ~/.xsession file.

In order to forward the NX session:

● Access the NX server host machine via SSH -X enabling X11 forwarding: # ssh -X username @ nxserverHost

● Run the nxserver --startsession command. For example:

● Start the default unix-default application:BaseDirectory/NX/bin/nxserver –startsession

● Start a console in floating-window mode:● BaseDirectory/NX/bin/nxserver --startsession –type=unix-application

--application=xterm --rootless=1 ● Start a KDE desktop● BaseDirectory/NX/bin/nxserver --startsession --link="modem" type="unix-kde"

--geometry="800x600" ● Start a GNOME desktop● BaseDirectory/NX/bin/nxserver --startsession --link="adsl" --type="unix-gnome”

--geometry="1024x768"--keyboard="pc102\057us"

9.6. Run a Session on an Unsupported PlatformIn order to access remotely a machine with an unsupported platform, it is possible

to get the X application to securely forward its display to the NX session by X11 forwarding over SSH. This can be done by means of a shell script to be executed on demand at session start-up.

Samples are available in the 'Articles' section of the NoMachine Knowledge Base:http://www.nomachine.com/ar/view.php?ar_id=AR01F00498

9.7. Executing Custom Scripts on NX Server EventsThe following keys (available in the server configuration file) allow the specification

of a custom script, which has to be executed on an nxserver event. According to the event, a number of parameters can be specified for each script. These scripts will be executed on the NX Server and are common to all the users who are accessing the server. They can't


http://www.nomachine.com/ar

mailto:username@nxserverHost








Amended: A

be specific for each user, since the server is not running as the logged user, but as the nx user.

For example, if you want to run a script to log the remote IP of the connecting user, you need to ensure that the output can be written in a directory on the server host accessible by the nx user.

Samples scripts are available in the "Articles" section of the NoMachine Knowledge Base:http://www.nomachine.com/ar/view.php?ar_id=AR01F00498

The available server configuration keys and the accepted parameter(s), are

UserScriptBeforeLogin “” Parameter: remote ip.UserScriptAfterLogin “” Parameter: username.UserScriptBeforeSessionStart ”” Parameters: session id, username, node host,

node port.UserScriptAfterSessionStart ”” Parameters: session id, username, node host,

node port.UserScriptBeforeSessionSuspend ”” Parameters: session id, username, node host,

node port.UserScriptAfterSessionSuspend ”” Parameters: session id, username, node host,

node port.UserScriptBeforeSessionClose ”” Parameters: session id, username, node host,

node port.UserScriptAfterSessionClose ”” Parameters: session id, username, node host,

node port.UserScriptBeforeSessionReconnect ”” Parameters: session id, username, node host,

node port.UserScriptAfterSessionReconnect ”” Parameters: session id, username, node host,

node port. UserScriptBeforeSessionFailure “” Parameters: session id, username, node host,

node port.UserScriptAfterSessionFailure “” Parameters: session id, username, node host,

node port.UserScriptBeforeCreateUser “” Parameter: usernameUserScriptAfterCreateUser “” Parameter: username.UserScriptBeforeDeleteUser “” Parameter: username.UserScriptAfterDeleteUser “” Parameter: username.UserScriptBeforeEnableUser “” Parameter: username.








Amended: A

UserScriptAfterEnableUser “” Parameter: username.UserScriptBeforeDisableUser “” Parameter: username.UserScriptAfterDisableUser “” Parameter: username.

If the execution of the script fails, the server will terminate. The NX Administrator would need to override this behavior and could force exit 0 inside the custom

script.

9.8. Executing Custom Scripts on NX Node EventsThe following keys (available in the node configuration file) allow the specification of

a custom script, which has to be executed on an NX Node event. According to the event, a number of parameters can be specified for each script.

Samples scripts are available in the "Articles" section of the NoMachine Knowledge Base:http://www.nomachine.com/ar/view.php?ar_id=AR01E00441

The available node configuration keys and the accepted parameter(s), are

UserScriptBeforeSessionStart “” Parameters: username, session id, session type, display.UserScriptAfterSessionStart “” Parameters: username, session id, session type, display.UserScriptBeforeSessionSuspend “” Parameters: username, session id, display.UserScriptAfterSessionSuspend “” Parameters: username, session id, display.UserScriptBeforeSessionClose “” Parameters: username, session id, display.UserScriptAfterSessionClose “” Parameters: username, session id, display.UserScriptBeforeSessionReconnect “” Parameters: username, session id, display.UserScriptAfterSessionReconnect “” Parameters: username, session id, display.UserScriptAfterSessionFailure “” Parameters: username, session id, session type display.

If the execution of the script fails, the node will terminate. The NX Administrator would need to override this behavior and could force exit 0 inside the custom

script.

10. Connections to Desktops and Collaborative Sessions Connections to either physical or virtual desktops, which allow for application








Amended: A

sharing and white board-based collaboration, are enabled by default in interactive mode and don't require the owner's authorization for being able to connect to the desktop.

10.1. Disabling Connections to the Physical DesktopBy default, the NX user can connect to the physical desktop without the need for

authorization from the desktop's owner. To forbid this capability, the PhysicalDesktopSharing key must be uncommented and disabled in the server configuration file:

PhysicalDesktopSharing 0

10.2. Configuring Interaction Level to the Physical DisplayThe EnableInteractiveDesktopSharing key in the server configuration file allows to

define the interaction level for the user attaching to the native display. By default, the connected user can interact with the physical desktop, i.e., the PhysicalDesktopMode key is set to 1. To disable interaction with the physical desktop, uncomment and disable that key:

PhysicalDesktopMode 0

In such way, the connected user will access the physical desktop in view-only mode.

10.3. Enabling Authorization Requirement to Share the Physical DesktopThe PhysicalDesktopAuthorization key in the server configuration file enables and

disables the explicit authorization of the physical desktop owner to accept sharing of the display. To enable, uncomment and activate the following key:

PhysicalDesktopAuthorization 1

10.4. Disabling Connections to the Virtual DesktopBy default, the NX user can connect to virtual desktop sessions without the need for

authorization of the desktop's owner. To forbid this capability, the VirtualDesktopSharing key must be uncommented and disabled in the server configuration file:

VirtualDesktopSharing 0

10.5. Configuring Interaction Level to the Virtual DesktopA session connected to a Virtual Desktop can interact with this desktop in the







Amended: A

following modes:

0: View-only. User connected to the virtual desktop can't interact with the desktop.

1: Restricted. User connected to the virtual desktop can interact with the desktop but resize operations on the virtual desktop session are forbidden.

2: Interactive. User connected to the virtual desktop can fully interact with the desktop.

By default, mode 2 is enabled. This mode can be changed by uncommenting and setting the proper value for the VirtualDesktopMode key in the server configuration file.

For example, to connect to the desktop in view-only mode:

VirtualDesktopMode 0

10.6. Requiring Authorization for Connecting to a Virtual Desktop The VirtualDesktopAuthorization key in the server configuration file enables or

disables the explicit authorization of the virtual desktop owner to connect to the desktop.

To enable the request for explicit authorization of the virtual desktop owner, uncomment and enable the VirtualDesktopAuthorization key:

VirtualDesktopAuthorization 1

10.7. The Connection MonitorWhen one or more users are connected to either a virtual or a physical desktop, a

draggable window-application, NX Connection monitor, is issued on the desktop. This application monitors who is currently connected to the desktop and enables a message to be sent to the selected user to disconnect him or her.

11. The NX Web Applications The NX Server package includes NX Server Manager, NX Web Player, a small web

server (nxhtd), and all the configurations to have these web applications up and running after the installation at the following URL: https:// serverHost :4080 . serverHost is either the IP or hostname of the machine where the NX Server package has been installed.

Note: The installation comes with a self-signed SSL certificate intended to be a sample. This doesn't grant a secure connection. In order to secure your NX web


https://serverHost:4080/








Amended: A

applications, please replace the SSL Certificate File, namely BaseDirectory/NX/etc/htd.crt and the SSL Certificate Key File /usr/NX/etc/htd.key with your own.

11.1. Administering the Server: NX Server Manager NX Server Manager is the graphical interface that allows to administer servers,

nodes, users, and sessions via the Web. It is included in the NX Server package together with the nxhtd service, a small web server to deploy the NX Web applications on the Web.

Among the other functionalities, NX Server Manager provides statistics concerning the load of NX Server and statistics related to system performances and to NX sessions.

11.2. Enabling the NX StatisticsNX Server Manager visualizes real-time graphics about both systems (e.g., CPU

usage, free memory, network traffic) and about NX sessions (e.g., number of sessions running). All graphics are available on an hourly, weekly, monthly, and yearly basis. In order to generate these statistics, NX Server and Node(s) should be configured to start the NX Sensor Daemon (nxsensor) on each node host machine, as well as start the NX Statistics Daemon (nxstat) on the server host machine. The nxsensor daemon is in charge of producing data that is then elaborated by nxstat and provided to the Manager.

How to Start the NX Sensor DaemonUncomment and enable the EnableSensor key in the node.cfg file:

EnableSensor 1

Then start the service by running the following command: nxnode --sensor start

How to Start the NX Statistics DaemonThe EnableStatistics key has to be uncommented and enabled in the server configuration file:

EnableStatistics 1

To start the service, run the following command:

nxserver --statistics start

How to Generate Statistics for Remote Nodes







Amended: A

If a node is remote, it is necessary to also configure the StatisticsHost key in the node configuration. This key has to point to the NX Server host where nxstat is running.

For example, if NX Server and nxstat is running on testdrive:

StatisticsHost testdrive.nomachine.com

11.3. Starting and Stopping the NX Web Server The NX Web Server automatically starts during the installation of the NX Server

package and is stopped, started, or restarted together with the server (e.g., during the reboot of the host machine). The nxhtd service can be started and stopped independently from the server by running, respectively: nxserver --htd start nxserver --htd stop

11.4. Disabling the Automatic Starting of the NX Web ServerIn order to prevent the automatic starting of the nxhtd service, the following key has

to be uncommented and disabled in the server configuration file:

EnableHtd 0

11.5. How to Disable Access to the NX Web ApplicationsIt is possible to forbid access to the NX Server Manager by un-commenting and

disabling the following key in the manager configuration file (manager.cfg):

EnableServerManager 0

In this way, the nxhtd service is forbidden to serve content of the NX Server Manager web application.

In a similar way, to forbid access to the Web Player, it is necessary to uncomment and disable the following key in the web player configuration file (webplayer.cfg):

EnableWebPlayer 0

12. Sharing Resources and Printing with NX NX relies on third-party tools to support resource sharing, namely on a SMB and







Amended: A

CUPS back end. If these tools are available at the time NX Server is installed, all services related to the sharing of resources are enabled by default. The installation setup takes care of configuring the related keys according to the settings present on the system. For example, it retrieves from the system the command for configuring the CUPS server and specifies it in the proper node configuration key.

These settings should grant all services to work out of the box, without the need of any additional changes. The necessary third-party tools can be installed at any time; however, it is necessary to update the NX infrastructure accordingly. NX Node puts at disposal a number of commands to do that.

12.1. Sharing Files The NX Server allows access to the filesystem from clients with the help of two

protocols: SMBFS and SSHFS. NX Server tries to mount the SMBFS shares by running the mount command using the NX privileged scripts. The SSHFS shares are mounted by using the FUSE technology, and no privileged scripts are necessary.

The end user can decide to share and configure a local filesystem at any time by means of the NX Player GUI. Folders already shared can be disconnected during the life of the session or left as they are. In this case, they are automatically shared at the next session start-up.

12.2. Disabling File SharingFile sharing is activated by default. It can be disabled by uncommenting the

EnableFileSharing key in the node configuration file and by setting it to 0:

EnableFileSharing 0

Set value to 1 to enable file sharing.

12.3. Configuring the Share Mount Point To specify the target directory where the local filesystem has to be mounted on the

server side, uncomment and set a proper value for the following key in the node configuration file:

ShareBasePath $(HOME)/MyShares

For example:







Amended: A

To mount the shares in a directory placed under /mnt and named as the connecting user: ShareBasePath /mnt/$(USER)/MyShares

12.4. Disabling a File Sharing Protocol SMBFS and SSHFS protocols can be available only if third-party binaries necessary

for supporting these protocols are available. If they are available, both SMBFS and SSHFS are enabled by default during the installation. To forbid the use of any of these protocol it is necessary to uncomment and set value of the corresponding key to 0:

EnableMountShareSMB 0

EnableMountShareSSHFS 0

To enable any of these protocols, set value of the correspondent key to 1.

12.5. Checking and Updating the Sharing InfrastructureThe following NX Node command examines if the back end needed to support

resource sharing with SMBFS and/or SSHFS is available:

nxnode --sharingsetup [<path>]

If <path> is given, NX Node looks for third-party tools in the specified path.

This command is also in charge of updating the NX sharing infrastructure. If the missing tools have been installed, run it to make NX aware that the necessary tools are now available.

12.6. Sharing PrintersThe printers sharing infrastructure integrates client-side printers with the server-side

printing subsystem. Printers available on the client machine can be shared and used within the NX session. The end user can decide to share and configure a local printer at any time by means of the NX Player GUI. Printers already shared can be disconnected during the life of the session or left as they are. In this case, they are automatically shared at the next session start-up.

NX supports three protocols to carry print jobs from server side to client side:

IPP - available for Linux and Mac OS X clients. All user's printers available on local IPP







Amended: A

server (currently only CUPS subsystem is supported) can be shared on server side.

SMB - available for Windows, Linux, and Mac OS X clients. All the user's printers shared locally with SMB can be made available on the server side.

Virtual - available for Windows, Linux, and Mac OS X clients. All the user's printers available locally are duplicated as virtual printers on the server side. Print jobs are converted to PDF files, transferred from server to client through a NX channel, and printed on real hardware.

12.7. Disabling CUPS Support CUPS support is enabled on the server by default. It is necessary for mounting

printers by using the IPP protocol. To disable CUPS, the EnableCUPSSupport key must be uncommented and its value set to 0 in the node configuration file:

EnableCUPSSupport 0

Set the value to 1 to enable CUPS support.

12.8. Configuring CUPS Back End The keys listed below are used to configure the CUPS back end in the node

configuration file. Their value is automatically set during the installation procedure to fit the host environment.

T o specify the directory holding CUPS programs and CUPS back end

CUPSBackendPath /usr/lib/cups/backendCUPSBinPath /usr/binCUPSSbinPath /usr/sbin

To specify how the node has to add shared printers, depending on the CUPS ver s ion

CUPSAddPrinterMode localhost

Note: The key above can be set to localhost when CUPS version is greater than 1.2. Otherwise, the IP has to be specified.

12.9. Checking and Updating the Printing Infrastructure







Amended: A

The following NX Node command examines the back end to determine if support for the NX printers sharing infrastructure is available:

nxnode --printingsetup [<path>]


This command is also in charge of updating the NX printing infrastructure. If the missing tools have been installed, run it to make NX aware that the necessary tools are now available.

12.10. Making Available New Printer Drivers

Run the following NX Node command to make available additional printer drivers available to the NX Printing infrastructure:

nxnode --cupsdriversupdate

This updates the list of CUPS drivers provided to the client to allow users to configure server-side printers within the session.

12.11. Bi-directional File Printing

Bi-directional file printing is managed entirely by NX. Since it is for printers sharing an infrastructure, it doesn't depend on any server-side printing subsystem. The current implementation allows for the printing of any of the supported file types from client to server side or vice-versa: the selected file is converted to PDF format and transported by NX to the remote side and printed there to local hardware.

File types supported by default are:• PDF files without conversion • Plain text files convertible with 'enscript' program• Postscript files convertible with 'ps2pdf' program• GIF/PNG/JPEG images convertible with 'ImageMagick' program• OpenOffice files convertible with 'OpenOffice' program

In order to support a file type, a proper converter must be present on the server side. Administrators can easily add and configure other converters for a wider set of supported file types. In order to do that, it is necessary to edit the BaseDirectory/NX/share/print.ini file







Amended: A

and add the new converter according to the format specified in the printer.ini file:

# Format:# mime extension converter# Where:# mime - a mime type of file to print# extension - a extension of file to print, failback option if mime # cannot be recognized# converter - a command (or commands) used to convert a file to print # into pdf file# Variables:# 1$ - input file, 2$ - output file

Sample of definitions of converters are:

# Basic convertersapplication/postscript .ps ps2pdf $1 $2image/gif .gif convert $1 $2

12.12. Sharing USB DevicesNX implements the USB tunneling to forward over the network and share devices

such as hard disk, web cams, barcode readers, and pen drives from local to remote desktops and vice-versa. It requires that the nxusb package is installed on both the NX Server host and the end-user's machine where NX Player is running. The nxusb package provides aal components necessary for managing the service, namely NX USB daemon, NX USB library, and NX USB kernel module. No additional configurations are necessary on server side.

12.13. Two-way File Transfer NX 4 supports the file transfer functionality to transfer a file from within the session

to the local desktop and vice-versa. with the possibility of suspending and resuming that operation. It requires NX Player Version 4 or higher on client side. This functionality is available also in the case of Web sessions running via NX Web Player. No additional configurations are necessary on the server side.

13. Supporting Audio and MicrophoneNX audio frameworks is integrated with PulseAudio sound server. If PulseAudio is

not available on the Linux system, NX is able to use ALSA (Advanced Linux Sound Architecture). This is automatically managed by the NX Server, depending on which audio







Amended: A

server is available on the host machine. If both are available, the administrator can manually edit the node configuration file to specify which sound server has to be used.

Note: In case of connections from clients earlier to version 4, the NX Server will try to use its support for ESD (Enlightened Sound Daemon) if this sound server is present on the system.

Support for audio and microphone is enabled by default. The installation setup takes care of configuring the related keys according to the settings present on the system. For example, it specifies command for starting the PulseAudio server. These settings ensure that the audio framework works out of the box without the need of any additional changes.

13.1. Enabling Audio The AudioInterface key in the node configuration file specifies on which audio

infrastructure the NX audio framework has to rely. Possible values are: pulseaudio, oss and alsa. If pulseaudio is specified, the PulseAudio server is started with the command defined in the CommandStartPulseAudio key.

Set the AudioInterface key to disabled to de-activate audio support. This disables also the microphone support.

13.2. Checking and Updating the Audio InfrastructureThe following NX Node command examines the back end to see if it will support the

NX audio infrastructure:

nxnode --audiosetup [<path>]


This command is also in charge of updating the NX audio infrastructure. If the missing tools have been installed, run it to make NX aware that the necessary tools are now available.







Amended: A

14. Logging Facilities

14.1. Enabling Debug LevelTo enable the debug log level, the SessionLogLevel key must be uncommented

and set to value 7 both in the node and server configuration files. This key is available also in the NX Server Manager and NX Web Player configuration files.

SessionLogLevel 7

14.2. Redirecting Logs to a Custom File The NX Server and NX Node, as well as the NX Server Manager and NX Web

Player, logs are printed by default to the system log file. In order to redirect logs of any of the NX application to a custom file, uncomment and set the path to the file in the following configuration key available in their configuration file:

SystemLogFile /tmp/NX.log

Note: It is necessary that the custom file exists and that the NX Application can write to that file, otherwise the log will be written to syslog.

14.3. Disabling the Logging of X ClientsIn the default configuration, logs of X clients are redirected to the user's

home/.nx/SessionDirectory/clients file. In order to disable the logging of X Clients, the following key must be deactivated in the node configuration file:

ClientLog 0

14.4. Setting the Log Maximum SizeSet the maximum size allowed for both session and X clients log files by

uncommenting and modifying the following keys in the node configuration file. When the maximum size is exceeded, the node terminates the session.

For example, to set the maximum size at 4 MB: SessionLogLimit 4194304

ClientLogLimit 4194304







Amended: A

14.5. Enabling and Disabling Automatic Clean-up of Session Directories

In its default configuration, NX Server removes the NX session directory from the user's home/.nx directory once the session has been correctly terminated. To preserve it, the following key has to be uncommented and disabled in the server configuration file:

SessionLogClean 0


NXServer Admin Guide

Documents

Transcript of NXServer Admin Guide