Adding the nxserver --check command to self-test the system

ID: FR09E01868 Priority: Low
Products: NoMachine Server Target: 7
Status: Dismissed  

---

FR dismissed. NoMachine  team stopped development activities in this direction because of the vast amount of functionalities and capabilities present in all NoMachine Enterprise products. Only one command will not be enough to check the complete amount of available features.

---

 

Diagnostic functionalities to self-test the system for common configuration mistakes are already available, but , rather than being implemented in a single tool, they are scattered in different places in the server and in the setup.

A nxserver --check command can be added to do all the possible tests (system configuration, installed packages, server configuration, connectivity, etc.) using a single command.

The tool will give a nicely-formatted report in output, that, for example, could be fed to the support team to simplify the problem determination.

Rather than a monolitic program, the tool will be built as a framework, able to accomodate different tests, also written by the user. For this purpose, the directory 'test'  can be added to /usr/NX/scripts and the directories tree can be organized as follows:

nxtest@machine:~/NX/t> ls -lR scripts/test/
scripts/test/:
total 0
drwxr-xr-x+ 5 nxtest None 0 Sep 13 10:16 .
drwxr-xr-x+ 3 nxtest None 0 Sep 13 10:16 ..
drwxr-xr-x+ 2 nxtest None 0 Sep 13 10:16 nxnode
drwxr-xr-x+ 2 nxtest None 0 Sep 13 10:16 nxsensor
drwxr-xr-x+ 2 nxtest None 0 Sep 13 10:16 nxserver

scripts/test/nxnode:
total 0
drwxr-xr-x+ 2 nxtest None 0 Sep 13 10:16 .
drwxr-xr-x+ 5 nxtest None 0 Sep 13 10:16 ..

scripts/test/nxsensor:
total 0
drwxr-xr-x+ 2 nxtest None 0 Sep 13 10:16 .
drwxr-xr-x+ 5 nxtest None 0 Sep 13 10:16 ..

scripts/test/nxserver:
total 0
drwxr-xr-x+ 2 nxtest None 0 Sep 13 10:16 .
drwxr-xr-x+ 5 nxtest None 0 Sep 13 10:16 ..

Each directory will contain a set of scripts, organized similarly to the rc.d directories on a Unix machine. This will tell the server or the node the order by which it will have execute the tests:

nxtest@machine:~/NX/t/scripts/test> ls -lR nxserver/
nxserver/:
total 4
drwxr-xr-x+ 2 nxtest None 4096 Sep 13 10:33 .
drwxr-xr-x+ 5 nxtest None    0 Sep 13 10:16 ..
-rw-r--r--  1 nxtest None    0 Sep 13 10:21 00-network.sh
-rw-r--r--  1 nxtest None    0 Sep 13 10:21 01-resolv.sh
-rw-r--r--  1 nxtest None    0 Sep 13 10:30 02-system.sh
-rw-r--r--  1 nxtest None    0 Sep 13 10:30 03-packages.sh
-rw-r--r--  1 nxtest None    0 Sep 13 10:25 04-ssh.sh
-rw-r--r--  1 nxtest None    0 Sep 13 10:25 05-sshd.sh
-rw-r--r--  1 nxtest None    0 Sep 13 10:30 06-keys.sh
-rw-r--r--  1 nxtest None    0 Sep 13 10:30 07-nodes.sh
-rw-r--r--  1 nxtest None    0 Sep 13 10:21 08-x11.sh
-rw-r--r--  1 nxtest None    0 Sep 13 10:21 09-cups.sh
-rw-r--r--  1 nxtest None    0 Sep 13 10:22 10-sound.sh

Users will be able to insert their own tests in-order by using the NN-NN-test.sh naming convention. For example:

nxtest@machine:~/NX/t/scripts/test> ls -lR nxserver/
nxserver/:
total 4
drwxr-xr-x+ 2 nxtest None 4096 Sep 13 10:33 .
drwxr-xr-x+ 5 nxtest None    0 Sep 13 10:16 ..
-rw-r--r--  1 nxtest None    0 Sep 13 10:21 00-network.sh
-rw-r--r--  1 nxtest None    0 Sep 13 10:24 00-01-lan.sh
-rw-r--r--  1 nxtest None    0 Sep 13 10:24 00-02-dsl.sh
-rw-r--r--  1 nxtest None    0 Sep 13 10:24 00-03-dialup.sh
-rw-r--r--  1 nxtest None    0 Sep 13 10:21 01-resolv.sh
-rw-r--r--  1 nxtest None    0 Sep 13 10:30 02-system.sh
-rw-r--r--  1 nxtest None    0 Sep 13 10:30 03-packages.sh
-rw-r--r--  1 nxtest None    0 Sep 13 10:25 04-ssh.sh
-rw-r--r--  1 nxtest None    0 Sep 13 10:25 05-sshd.sh
-rw-r--r--  1 nxtest None    0 Sep 13 10:30 06-keys.sh
-rw-r--r--  1 nxtest None    0 Sep 13 10:30 07-nodes.sh
-rw-r--r--  1 nxtest None    0 Sep 13 10:21 08-x11.sh
-rw-r--r--  1 nxtest None    0 Sep 13 10:21 09-cups.sh
-rw-r--r--  1 nxtest None    0 Sep 13 10:22 10-sound.sh

By using this simple convention, it will be easy for the server to detect trivial naming errors (like tests having the same numbering or not following the NN-[NN]-name.sh convention) and point the user at the infringing script.

This functionality can be very useful in a lot of scenarios, not only for trouble-shooting the system. Think for example at a 'test' button in the server manager or at a server 'testing' a remote node upon insertion in the NX network.

The use of this functionality should be restricted only to people logging to NX as administrators or when running on the console. That said, all tests should be able to run as user nx, without the need for a specific 'privileged' directory or an administrative login, except if there is any test that might require 'root' capabilities.