Geneos


Starting Geneos version 5.1.x, the Netprobe has a new set of documentation. To access it, see Netprobe Documentation Home.

Netprobe User Guide

Introduction

A Netprobe is a lightweight monitoring agent which is deployed on every node to be managed. As the active agent in the Geneos framework, there must be at least one Netprobe running somewhere in the environment. Plug-ins are run locally by the Netprobe to collect data. Sampled data and updates are passed from the Netprobe to the connected Gateway. The protocol used is designed to minimize network traffic. Netprobes can execute control-type functions upon receiving commands from Gateways.

Refer to the Introduction of the Gateway 2 Reference Guide for more information on the architecture of the Netprobe and the other Geneos components.

Note: This user guide is written on the assumption that the Netprobes are being used with Gateway 2. If Gateway 1 is being used then, for information on installing and setting up a Netprobe, please refer to the Gateway 1 Installation and Technical Reference Manual.

There are essentially four types of Netprobe, as shown in the table below. The first three of these all use the same Netprobe software; they are just different modes of operation.

Netprobe Type Description
Normal In Normal Netprobe mode, the Netprobe passively waits for an incoming Gateway connection to provide it with the configuration it needs to start monitoring. This means that every Netprobe needs to be separately specified in the Gateway Setup File, and that the set-up needs to be manually updated if the Netprobe is migrated to a different server.
Floating In Floating mode, a Netprobe and Managed Entity will already be configured on the Gateway but without connection details. On starting, the Netprobe will inform the Gateway of its hostname and its listen port and the Gateway will then connect as normal. This allows a Netprobe to automatically follow an application that migrates between servers. To use Floating mode, it is necessary to create a Netprobe Setup File and then start the Netprobe using the -setup parameter - see Command Line Options.

Note: Floating Netprobes are only supported if the version of both Gateway and Netprobe used is 2011.2 or later.

Self-Announcing For a Self-Announcing Netprobe, no Netprobe or Managed Entity need be configured on the Gateway. Instead, the Netprobe Setup File specifies both the Netprobe name and Managed Entity name along with one or more type names that correspond to types in the Gateway Setup File. This allows Netprobes to start up on any hosts and immediately be configured with default monitoring. In addition the Netprobe setup file can specify zero or more Managed Entity Attribute name-value pairs. These can be used by ActiveConsole for searching and sorting purposes. Attributes are typically used with the logical mode of the ActiveConsole State Tree. Netprobe setup file can also set variables on a Managed Entity. Netprobe setup file can also specify zero or more variables to be set on the Managed Entity. There is an option in the Gateway Setup Editor to add one or more Self-Announcing Netprobes to the Gateway Setup File permanently. To use Self-Announcing mode, it is necessary to create a Netprobe Setup File and then start the Netprobe using the -setup parameter - see Command Line Options.

Note: Self-Announcing Netprobes are only supported if the version of both Gateway and Netprobe used is 2011.2 or later.

Virtual No Netprobe software needs to be installed to be able to use a Virtual Netprobe. Virtual Netprobes appear in the Gateway directory structure as regular Netprobes but do not make a TCP connection to an external Netprobe process. Virtual Netprobes are intended to be used to configure Gateway Plug-ins and for creating user defined dataviews using Compute Engine.

QuickStart Guide to Installing a Netprobe

List of Supported Platforms

Please refer to the Geneos Compatibility Matrix for the list of supported platforms.

System Requirements

The type of information collected by the Netprobe is determined by the Plug-ins that are activated. For the majority of cases, the Netprobe needs to be installed onto the server to be monitored. For some Plug-ins the Netprobe can be installed onto any server that has access to the required information. E.g. for the MIBMON (SNMP MIB monitoring) Plug-in, the Netprobe can be installed onto any server.

Prerequisite Description
Netprobe machines

OS: Windows, SuSE Linux, RedHat Linux, Solaris (x86 and Sparc), AIX

CPU: Multi-Core

Memory: 2GB (32bit), 4GB (64bit)

Network: 1 Network Card (100 mbps) Disk: 200MB

Java: Required to run Java-based plug-ins. For information on supported versions, see Application and plug-in specific information in Geneos Compatibility Matrix.

Port 7036 A port must be open on any system running a Netprobe. The default Netprobe port is 7036. Each system should be visible to the Gateway.
SCP Access The Geneos software will be installed in a nominated directory (/opt/geneos) or a user's home directory. This should be a common directory across all machines. Will require SCP access to each server and directory to copy the Netprobe binaries. On Unix/Linux systems the Netprobe can run as any user, subject to access constraints on the application and data to be monitored. On Windows systems the Netprobes will run as a native service, BUILTIN\ system, and requires Administrator access to install.

Downloading and Installing (Solaris, Linux and AIX)

To download the Netprobe software, go to the ITRS website https://www.itrsgroup.com and log in using the client login field. If you do not already have a client login, then click on the "New User" link. Having logged in, select the "Downloads" client option. Then select the appropriate Netprobe download and save the downloaded file.

When Security-Enhanced Linux (SELinux) is running in Enforcing mode, it may deny certain functions of Geneos depending on the implemented configurations and policies. To see which functions SELinux denies, check the audit log. The log is typically located in /var/log/audit.log, where the log type entry is AVC. The audit log provides the details of any denied access. For example, denied connection to the TCP port. If you experience issues related to this mode, you may opt to disable SELinux, or create policy modules to grant the required access. Please contact your administrator or security team for assistance.

A single file with a name of the form <main body of name>.tar.gz is downloaded. This contains a number of files which have been tarred and zipped. They can be unpacked by using the commands:

gunzip <main body of name>.tar.gz
tar -xvf <main body of name>.tar

Once unpacked the tar file is no longer needed and can be removed.

If this is a new installation of the Netprobe, simply place the unpacked files in the directory from which Netprobe is to be launched.

If upgrading from an earlier version then stop the Netprobe, replace all of the files with those from the new version, and then restart the Netprobe.

RPM Package (Linux)

A Netprobe RPM package is also available for download and installation on Linux platforms. You can use YUM to deploy the RPM package. See the following steps for sample commands on how to deploy the RPM package to a local YUM repository.

  1. Create or update the local YUM repository.
  2. [root@server1 ~]# mv <rpm-dir>/* <repo-dir>/
    [root@server1 ~]# chown -R root.root <repo-dir>/
    [root@server1 ~]# createrepo <repo-dir>/
    [root@server1 ~]# chmod -R o-w+r <repo-dir>/							

    The <rpm-dir> contains the RPM package to be added to the local YUM repository.

  3. Create or update the /etc/yum.repos.d/local/repo folder.
  4. [local]
    name=<repo-name>
    baseurl=file://<repo-dir>
    enabled=1
    gpgcheck=0												
  5. Install or upgrade the Netprobe.
  6. yum install geneos-netprobe							
  7. Uninstall the Netprobe.
  8. yum remove geneos-netprobe							

Linux Library Dependencies

The Linux version of the Netprobe depends on certain libraries to run. All these libraries are usually present on 32-bit versions. The 64-bit versions often do not have them installed, and the user is therefore required to install them. To make this process easier, the libraries and the packages that they belong to for two common 64-bit Linux operating systems have been listed below. The utility yum was used on CentOS and yast on Suse to match library to package.

CentOS (64-bit)

Library Name Package Name
libstdc++.so.5 compat-libstdc++-33-3.2.3-61.i386
libutil.so.1 glibc-2.5-34.el5_3.1.i686
libnsl.so.1 glibc-2.5-34.i686
libpthread.so.0 glibc-2.5-34.i6826
libdl.so.2 glibc-2.5-34.i686
libcrypt.so.1 glibc-2.5-34.i686
libz.so.1 zlib-1.2.3-3.i386
libm.so.6 glibc-2.5-34.i686
libgcc_s.so.1 libgcc-4.1.2-44.el5.i386
libc.so.6 glibc-2.5-34.i686
ld-linux.so.2 glibc-2.5-34.i686

Suse (64-bit)

Library Name Package Name
libstdc++.so.5 compat-libstdc++-5.0.7-22.2
libutil.so.1 glibc-32bit-2.4-31.2
libnsl.so.1 glibc-32bit-2.4-31.2
libpthread.so.0 glibc-32bit-2.4-31.2
libdl.so.2 glibc-32bit-2.4-31.2
libcrypt.so.1 glibc-32bit-2.4-31.2
libz.so.1 zlib-32bit-1.2.3-15.2
libm.so.6 glibc-32bit-2.4-31.2
libgcc_s.so.1 libgcc-4.1.0-28.4
libc.so.6 glibc-32bit-2.4-31.2
ld-linux.so.2 glibc-32bit-2.4-31.2

Downloading and Installing (Windows)

For Windows there is a choice of two packages to download:

  • an executable installer (named geneos-netprobe-*<version>*.windows-<platform>.setup.exe). This is an installer for the Windows Netprobe Package.

  • a zip file (named geneos-netprobe-*<version>*.windows-<platform>.zip). This can only be used when upgrading a previous installation.

Note: <platform> is x86 for 32-bit and x64 for 64-bit.

New installation on a Windows machine

Download the executable installer (geneos-netprobe-*<version>*.windows-<platform>.setup.exe).

Run the installer on the machine on which the Netprobe is to be installed. Answer the self-explanatory questions displayed during installation. Each question offers a suitable default.

See installer and binary command line options for Windows. For a complete list of command line options, see Command Line Options.

Service installed on the Windows machine

A service will have been installed on the Windows machine. Unless a non-default name was specified for this service during installation, it will be called “NetprobeNT” for 32-bit and “NetprobeNT_64” for 64-bit. If at any time it is necessary to stop or start the Netprobe service, or to change any of its properties, then this should be done using the services management tool in the Windows installation (the location of this tool varies in different versions of Windows, if in doubt it can usually be found it by clicking on the Windows Start icon in the bottom left of the screen and typing “Services” into the search function).

Upgrade on a Windows machine

To upgrade an existing installation, either use the installer exe file (which can also be used to do the upgrade) or the zip file (using which the files in the installation can be manually replaced).

In either case, the first step in the upgrade process is to stop the Netprobe service. Then do one of the following options.

Upgrading Using the Executable Installer

Download the executable installer (geneos-netprobe-*<version>*.windows-<platform>.setup.exe).

Run the executable installer on the machine on which the Netprobe is to be upgraded. Answer the self-explanatory questions displayed during installation, giving the same answers as for the previous installation. On completion, the Netprobe will have been upgraded and the service will have been automatically restarted as part of the process.

Upgrading Using the zip file

Download and unzip the geneos-netprobe-*<version>*.windows-<platform>.zip file. This will provide a set of files.

Overwrite the files in the Netprobe installation directory with those that have just been unzipped. By default, this will be called NetprobeNT.exe for 32-bit or NetprobeNT_64.exe for 64-bit. However, if a non-default service name was supplied during the previous installation then this binary will be called *<service name>*.exe. Overwrite it using the file netprobe.windows.exe/netprobe.windows_64.exe from the unzipped download. The name of the overwritten file should be the same as before, i.e. NetprobeNT*.exe or *<service name>*.exe.

Manually restart the service.

Differences to be aware of when configuring Probes and Samplers to run on Windows

When configuring the Probe and Samplers in the Gateway Setup Settings, there are a number of things to bear in mind when using a Netprobe on Windows:

  • When a full path is specified, this must include the drive letter (e.g. C:\temp\test.txt).
  • When specifying a file or folder location, use backward slash in folder paths (\) rather than the forward slash (/).
  • Filenames are case insensitive.
  • To specify free disk monitoring with a Disk Sampler, use the disk drive letter and a colon (e.g. C:).
  • To specify a process to monitor with a Processes Sampler, set the search string as it appears in the Windows Task Manager "Processes" tab but without the .EXE extension. This search string is case insensitive.

Using a Shared Drive

It is possible to install a Netprobe on a shared drive and then run it on multiple nodes. However, there are a couple of things to be aware of if a Netprobe installation on a shared drive is going to be used by multiple nodes simultaneously:

  1. If the Netprobes record their log output to file and they are writing their logs to the shared drive, then it is necessary to make sure that they each one is writing to a unique file. The Netprobes may crash if more than one Netprobe attempts to write to the same file. This is a problem that can be encountered, for example, if a shared script is being used to set up the environment and launch the Netprobe on a set of UNIX machines, and this script is setting LOG_FILENAME to the same file on the shared drive. In this example, one can work around the problem by changing the script to set it to something like

    setenv LOG_FILENAME netprobe.out.`hostname`

    This will generate a log file which includes the hostname as a suffix to the log file name, thus giving the Netprobe running on each machine a separate log file.

  2. If the Message Tracker plug-in is being used, this writes a file in the Netprobe directory which ensures that no data is lost if the probe stops. If two Netprobe instances are using the same shared drive installation and both using Message Tracker plug-ins, there is the potential for these both to using the same name for this file and therefore overwrite each other's data. By default this file is called <Managed Entity Name>.<Sampler Name>.cache, but the name can be set by using the Message Tracker configuration setting persistenceFile.

    If multiple Netprobe instances are being run which use the same shared drive installation, more than one of which is running a Message Tracker sampler, it should therefore be ensured that each Message Tracker sampler has the persistenceFile setting defined and set to a name unique to that Netprobe and sampler.

Running a Netprobe

For all Netprobe settings configured in the Gateway Setup Editor, see Probes.

Variables

The following variables fine-tune Netprobe operation or override the defaults. On non-Windows platforms these should be set as environment variables in the shell from which the Netprobe is launched. On Windows they should be set in the registry - see Setting Variables for Netprobe on Windows Platforms.

Where these variables are described as an equivalent of an advanced Gateway Setup File setting, more details on the Gateway Setup File setting can be found in Probes.

For Normal Netprobes, see Probe settings - Advanced tab.

For Floating Netprobes, see Floating Probe settings - Advanced tab

For Self-Announcing Netprobes, these settings cannot be defined in the Gateway Setup File - they have to be set by using the variable on the Netprobe.

 

Name Use
LOG_FILENAME The Netprobe error and log file. If the filename is not defined, the errors and messages are sent to standard out. Ensure that the directory where the log file resides is writeable, so that the Netprobe can create and write to the file.
Note:
  • This parameter is ignored if the Netprobe executable is run with '-nolog' command line parameter.
  • If the Netprobe software has been installed on a shared drive and is being run on more than one machine at thesame time, see Using a Shared Drive for important information regarding the setting of this variable.
  • A full path can be specified in this variable if the user wishes to place this log file in a specific directory. If only the name is specified then it will be created in the directory where the Netprobe is running.
MAX_LOG_FILE_SIZE_MB The Netprobe error and log file can be setup to roll over to a new log file when it gets bigger than MAX_LOG_FILE_SIZE_MB. The maximum value that can be set is 4096Mb and the minimum is 1Mb. If the value is outside of these ranges or the input is invalid, then the default of 10Mb will be used. This is the equivalent of the advanced Gateway Setup File setting maxLogFileSize.
LOG_ARCHIVE_SCRIPT The log file generated by Netprobe will grow up to 1 Mb. Netprobe will then rename the file by adding a .old extension and will open a new log file. If the LOG_ARCHIVE_SCRIPT is set, the UNIX script defined by the environment variable will be called after the log file has been renamed. The script is passed the name of the .old file as a parameter. This script can be used to archive the log files into an archive area. By default the script is not called.
NET_PORT The TCP/IP port number that the Gateway uses to connect to Netprobes. To avoid confusion it is recommended that this setting is the same for all the Gateways and Netprobes. The default port number is 7036.
ENCODED_PASSWORD
ALLOW_ENCODED_PASSWORD_DOWNLOAD
These two variables are used to control the use of passwords in relation to Netprobe commands. For more information on using these variables, see Setting Passwords on Netprobe Commands, which also explains the alternative method of setting the password via the Gateway Setup.
TRUSTED_GATEWAY_HOSTS
TRUSTED_GATEWAY_NAMES
These variables can be used to control which Gateways can connect to this Netprobe. For further details of how to use these variables see Restricting Gateway Hosts.
TRUSTED_DEBUG_HOSTS A host is a trusted debug host if it is in the list of TRUSTED_DEBUG_HOSTS. If TRUSTED_DEBUG_HOSTS is not set, it will default to 127.0.0.1.

If a non-trusted debug host is rejected by the Netprobe, a log similar to the one below appears:

WARN: ORB Non-trusted host itrslp003 rejected. Trusting only (127.0.0.1) for HTTP Debug components.
PERMISSIONS
This variable can be used to control which RMS commands can be executed on the Netprobe. Possible values are:
  • RMSPUT to enable PUT
  • RMSGET to enable GET
  • RMSEXEC to enable EXEC

Permissions can be combined using a plus sign. So, for example, to enable PUT and EXEC, set PERMISSIONS to RMSPUT+RMSEXEC.

Alternatively, PERMISSIONS can be set to RMSALL to enable all.

This is the equivalent of the advanced Gateway Setup File setting permissions.

TRUSTED_API_HOSTS Specifies an optional list of hostnames which are permitted to the API plug-in on this Netprobe. If specified, hosts not in this list will be rejected. If unspecified, all hosts can connect to the API plug-in. See the API plug-in documentation for more details. This is the equivalent of the advanced Gateway Setup File setting trustedAPIHosts.
PROCESS_LIST_COMMAND A probe-wide setting which affects all PROCESSES plug-ins for legacy Netprobes. This setting specifies a command to obtain process details for a legacy Netprobe. The default varies according to target operating system, but is typically "ps -ef". This is the equivalent of the advanced Gateway Setup File setting processListCommand.
WIDE_ PROCESS_LIST_COMMAND A probe-wide setting which affects all PROCESSES plug-ins running on a Solaris Netprobe. This setting specifies the command to obtain the full process name for processes with names longer than 75 characters. The default is "/usr/ucb/ps -axww". This is the equivalent of the advanced Gateway Setup File setting wideProcessListCommand.
CACHE_PROCESS_NAMES A Boolean value specifying whether to cache process names on Linux. This should be set to "false" if process names can change during execution. The default is "true". This is the equivalent of the advanced Gateway Setup File setting cacheProcessNames.
HEARTBEAT_INTERVAL When Netprobe does not receive any communication from a connected component within this number of seconds, it sends a heartbeat message to the component. Netprobe will then expect a reply within the number of seconds specified by the CONNECT_WAIT setting (see below). If the reply is not received within this time, the connection is terminated and re-established. The value supplied is in seconds, within the range 1 to 300, and defaults to 70. This is the equivalent of the advanced Gateway Setup File setting heartbeatInterval.
CONNECT_WAIT The time to wait for a connection to be established. The value supplied is in seconds, within the range 1 to 300, and defaults to 15. This is the equivalent of the advanced Gateway Setup File setting connectWait.
MAX_DATABASE_CONNECTIONS This sets the maximum amount of connections that a Netprobe can make to any database e.g. if managed_entity_1 belonging to probe_1 uses 3 SQL-TOOLKIT plug-ins, 1 Sybase plug-in and 1 Oracle plug-in and managed_entity_2 belonging to probe_1 uses the same, then they will have used 10 database connections in total. If probe_1 is using the default value then this means no more database connections could be made. The default is 10. This is the equivalent of the advanced Gateway Setup File setting maxDatabaseConnections.
PUBLISH_SCHEMA Set this variable to "false" to disable publishing of the schema file. This is the equivalent of starting the Netprobe with the -noschema Command Line Options.
REJECT_TIMEOUT_INTERVAL Time for which a "bad" connection from a Gateway should be blocked before allowing it to retry.
MAIN_BUFFER_MAX The maximum amount of outgoing comms data to store for the whole process. The value is in MB and in the range 25 to 250 inclusive. The default is 60.
CONNECTION_BUFFER_MAX The maximum amount of outgoing communication data to store for a single connection. The value is in MB and in the range 10–600 MB inclusive. The default is 60 MB.
FLUSH_DNS_PERIOD The time to cache the result of a DNS lookup (this variable is more used in relation with Gateway, but can be used with Netprobe as well). The value is in seconds and is a positive integer amount. The default is 0, i.e. no flush.
DISABLE_CORE_DUMP Set this variable to "true" to disable the creation of core dump files if Netprobe crashes. The default is "false".
LISTEN_IP Sets a specific IP address where the Netprobe will listen to incoming connections.

This argument can be used to force Self-Announcing Netprobes not to listen for incoming connections. See Disable listening.

Note: There are a number of other variables which can be set for debug or diagnostic purposes. These should only be used when requested or advised to do so by ITRS. These include DEBUG, GENERAL_DEBUG, GL_DEBUG, ISFS_SAMPLE_DEBUG, FKM_DEBUG, PROCESS_SAMPLE_DEBUG, SERVICE_SAMPLE_DEBUG, PROBE_MEM_TIME_INTERVAL, MAX_MEM_SIZE, DISABLE_MEM_PROTECTION and LEAK_MEMORY.

Setting Variables for Netprobe on Windows Platforms

For Windows platforms, the Netprobe does not read the above variables from the environment variables. Instead, these values need to be set in the registry. The Windows Netprobe Installer will have created a set of registry keys under HKEY_LOCAL_MACHINE\SOFTWARE\NetAgent\NetprobeNT* (if a non-default service name was specified when the Netprobe was installed, that name will replace "NetprobeNT" in this key name).

Use the utility regedt32.exe on the Windows platform (supplied as part of the operating system) to edit the values or add new name-value pairs in this set of registry keys.

Alternatively, it is possible to get or set Netprobe registry keys using the utilities na_getenv.exe and na_setenv.exe which are installed as part of the Windows Netprobe package.

Utility Use Example
na_getenv.exe Extracts the value of a Netprobe registry key Using a default Netprobe installation (i.e. where the service name is "NetprobeNT"), the command na_getenv.exe NetprobeNT NET_PORT will return the default port value of 7036.
na_setenv.exe Sets the value of a Netprobe registry key Again using a default Netprobe installation, the command na_setenv.exe NetprobeNT NET_PORT 12345 will change the listen port for the service NetprobeNT to port 12345.

See binary command line options for Windows and other platforms. For a complete list of command line options, see Command Line Options.

Location of Windows registry files for Netprobe

Go to the Registry Editor to locate the registry path of the Netprobe. The default registry path of Netprobe is:

HKEY_LOCAL_MACHINE \SOFTWARE : \system32\config\software
OS Bit Platform Registry Path
32-bit HKEY_LOCAL_MACHINE \SOFTWARE\Wow6432Node\NetAgent\
64-bit HKEY_LOCAL_MACHINE \SOFTWARE\NetAgent\

 

Starting the Netprobe

Starting on Solaris, Linux or AIX

Change directory to the directory containing the Netprobe. The executable file is the file with a name starting "netprobe.", with an operating system dependant suffix.

Set environment variables to define any of the Variables described above that are required. Then run the executable, specifying any of the Binary command-line options that are required.

Starting on Windows

By default it is not necessary to start the Netprobe on Windows. The installer will have started it running as a service at the end of installation. By default this service will automatically start each time that the machine is subsequently rebooted. To manually stop or start the service, the services management tool in the Windows installation should be used (the location of this tool varies in different versions of Windows, if in doubt it can usually be found it by clicking on the Windows Start icon in the bottom left of the screen and typing "Services" into the search function). The service will either be named as was specified during installation or, by default, will be called "NetprobeNT" or "NetprobeNT_64". If the user does not want the service to automatically start whenever the machine is rebooted, then this can be prevented by going into the Properties for the service in the services management tool and change the Startup type from "Automatic" to "Manual".

When NetprobeNT is running as a service, one can still set persistent command line options via registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NetprobeNT*\ImagePath
../../Resources/Images/active-console/legacy-images/image0_netprobe_user_guide.jpg

The user may prefer to run the Netprobe from the command line rather than as a service. If the same port or Netprobe log are going to be used, then it is necessary to first stop the service. To launch the Netprobe from the command line, first change folder to the folder containing the Netprobe. Then run the executable, specifying any Command Line Options that are required.

Note: This must include the -cmd command line option, which indicates that the Netprobe is to be run in the foreground (i.e. from the command line) rather than as a service.

Whether running as a service or from the command line, any Variables that are required should be set in the registry - see Setting Variables for Netprobe on Windows Platforms.

Gateway Setup Settings for Netprobe

For Normal, Virtual, and Floating Netprobes, various properties related to the Netprobe need to be configured in the Gateway File. These settings determine the relationship of Gateway with the Netprobe. Some of these properties are also downloaded to the Netprobe when it connects to the Gateway, controlling the Netprobe's behaviour. For information on Netprobe configuration settings in the Gateway Setup File, see Probes.

For Self-Announcing Netprobes, the Netprobe itself does not need to be configured in the GatewaySetup File . However, there are settings which still need to be set in the Gateway Setup File. These settings control the Gateway's behaviour with respect to Self-Announcing Netprobes. For example, controlling whether the Gateway will accept Self-Announcing Netprobes at all and, if so, which ones. For more information on the Gateway Setup File settings which relate to Self-Announcing Netprobes, see Self-Announcing Netprobes Technical Reference.

Note: Certain plug-ins run on the Gateway, instead of an external Netprobe process. For more information on these plug-ins, see Gateway Plug-Ins.

Once a connection is established, the Gateway can determine the state of a Netprobe as follows:

  • Down — the machine is up, but no active port is detected.
  • Unreachable — the host is unreachable; alternatively, there is a detected Netprobe process, but it is unresponsive or has a port issue.

For more information about probe connection status, see samplers > sampler > plugin > Gateway-probeData in Gateway Plug-Ins.

Running Netprobe under Elevated Privileges in Linux

When the privileges of netprobe is raised (e.g. via setcap/setuid), the runtime loader of Linux (ld.so) will not be able to load the libraries from the <netprobe directory>/lib64, as it will ignore RPATH and LD_LIBRARY_PATH. This is the way ld.so has been designed.

In order for the libraries to be loaded, the path to the lib64 folder has to be added to the trusted paths of ld.so. This can be done by doing the steps below, as root user.

  1. Create a conf file in /etc/ld.so.conf.d/. The conf file should contain the path to the lib64 folder inside your netprobe directory.
[root@localhost netprobe]# echo /home/inbound/binaries/netprobe/geneos-netprobe-4.0.0.linux-x64/netprobe/lib64/ > /etc/ld.so.conf.d/netprobe.linux_64.conf
  1. Rebuild the ld runtime cache by executing ldconfig.
[root@localhost netprobe]# ldconfig

After these steps, the netprobe can be run using the desired user and can load the runtime libraries without issues.

Plug-ins that require root access

In general, the Netprobe should be run as a regular user on your platform. However, there are plug-ins in Geneos that require the Netprobe to run with root permissions on Unix or as local administrator on Windows to run properly.

This section lists the plug-ins that require root access:

Plug-in Details
Network

Only requires root access if the Linux kernel version is below 2.6.33, and the Linux Netprobe version is prior to GA3.1.0-150223.

For more information, see Network Plug-in in Network Plug-in - Technical Reference.

Hardware

The vendor metric added in Netprobe GA4.5 requires root permission. Otherwise, it displays as "NA".

This metric is only available for Linux, but not other Unix platforms. For more information, see Hardware Plug-in in Hardware Plug-in - Technical Reference.

Trapmon

Only requires root access if the sampler uses the default SNMP port.

For more information, see SNMP Trapmon Plug-in - Technical Reference.

X Broadcast

Does not require root access if the Linux kernel version is 2.6.24 and higher, and the CAP_NET_RAW and CAP_NET_ADMIN of the Netprobe is enabled.

For more information, see Permissions in X Broadcast Plug-in - Technical Reference.

X Mcast

Does not require root access if the Linux kernel version is 2.6.24 and higher, and the CAP_NET_RAW and CAP_NET_ADMIN of the Netprobe is enabled.

For more information, see X Mcast Plug-in - Technical Reference in X Mcast Plug-in - Technical Reference.

X Ping

Does not require root access if the Linux kernel version is 2.6.24 and higher, and the CAP_NET_RAW and CAP_NET_ADMIN of the Netprobe is enabled.

For more information, see Permissions in X Ping Plug-in - Technical Reference.

X Route

Does not require root access if the Linux kernel version is 2.6.24 and higher, and the CAP_NET_RAW and CAP_NET_ADMIN of the Netprobe is enabled.

For more information, see Permissions in X Route Plug-in - Technical Reference.

X Services

Does not require root access if the Linux kernel version is 2.6.24 and higher, and the CAP_NET_RAW and CAP_NET_ADMIN of the Netprobe is enabled.

For more information, see X Services Plug-in in X Services Plug-in - Technical Reference

X Top

Does not require root access if the Linux kernel version is 2.6.24 and higher, and the CAP_NET_RAW and CAP_NET_ADMIN of the Netprobe is enabled.

For more information, see Permissions in X Top Plug-in - Technical Reference.

X Traffic

Does not require root access if the Linux kernel version is 2.6.24 and higher, and the CAP_NET_RAW and CAP_NET_ADMIN of the Netprobe is enabled.

For more information, see Permissions in X Traffic Plug-in - Technical Reference

SU

Requires root access due to the nature of the plug-in.

For more information, see SU Plug-in - Technical Reference.

Veritas Cluster Server

Only requires root access if the commands lltconfig and gabconfig are required.

For more information, see Handling Authentication in Veritas Cluster Server Plug-in.

Reload Netprobe configurations

Netprobe configuration files can be reloaded using a USR1 signal. For example:

kill -USR1 <pid>

Command-line options

Command line options can either be passed to the Netprobe installer (see Installer Command Line Options - Windows only), or directly to the Netprobe binary (Binary Command Line Options).

Installer command line options

The installer command line options are available only to Windows platforms.

Option Use
/netport Sets the Netprobe listening port. Default: 7036
/servicename=<servicename> Sets the Netprobe service name. Default: NetprobeNT
/nopassword Allows commands to run on the Netprobe without any prompting for a password. See Setting Passwords on Netprobe Commands.
/pass=<password> Sets a Netprobe password.
/listenip Sets a specific IP address where the Netprobe will listen to incoming connections.

This argument can be used to force Self-Announcing Netprobe not to listen for incoming connections. See Disable listening.
/listenoverride Used in conjunction with /listenip, overrides the previous value of /listenip if it exists.
/setup=<full path or URL to file>

Sets the setup file for a self-announcing or floating Netprobe. By default, the full path is <directory of installer>\\setup.netprobe.xml.

If you use the default setup file, then this will be copied into the installation directory (for example, C:\\Program Files (x86)\\NetprobeNT). This new path then becomes the value of the -setup argument of the Netprobe imagePath registry.

If you specify your own setup file, the file will be used in its respective directory. It will not be copied into the installation directory.

If you specify a remote file (<url> ), the Netprobe saves a copy of this in the installation directory as netprobe.setup.xml. This overwrites the existing netprobe.setup.xml file in the installation directory. In this case, any local changes to the netprobe.setup.xml configuration are ignored as the Netprobe retrieves the configuration from the remote file every /setup-interval=<minutes>.

If you specify an invalid file from the <url>, or the <url> becomes inaccessible, then the Netprobe uses the existing netprobe.setup.xml file.

Note: /setup=<url> only supports HTTP links by default. If you need to set up an HTTPS connection, see the /setup-server-verify option.

When using /setup=<url> with multiple instances of the Netprobe, check that you install each probe in its own directory. Otherwise, the setup for each probe may interfere with one another.

Do not use proxy servers for /setup=<url>. Proxy servers are not supported.

/setup-interval=<minutes>

Used in conjunction with /setup=<url>. If /setup=<url> is not defined, then this option is ignored.

Defines the time interval before the floating or Self-Announcing Netprobe requests another configuration file and restarts the announcement process. If no new or valid file is discovered, then the Netprobe neither reloads the configuration file nor restarts the configuration process.

If no -setup-interval is defined, the Netprobe makes the request every 360 minutes (or 6 hours), by default.

/setup-server-verify

Used in conjunction with /setup=<url>. This option only takes effect when an HTTPS <url> is specified. Otherwise, this option is ignored.

When this option is invoked, the Netprobe verifies the remote server against the operating system's Certificate Authority (CA) bundle. For these cases, the required certificates must be installed in the appropriate certificate stores.

/secure

If set, the Netprobe listens on a secure port rather than an insecure port.

When you run the Netprobe in secure mode, you need to specify the SSL certificate and key, as well.

/ssl-certificate=<full path to file>

Sets the SSL certificate file for use, where needed. The file must be in PEM format.

Default: <directory of installer>\\cert.netprobe.pem

If the default SSL certificate file is not used, then the file specified will be used within its directory. It will not be copied into the installation destination.

If the default SSL certificate file is used then it will be copied to the installation destination (for example, C:\\Program Files (x86)\\NetprobeNT) and this new path will be set as the value of -ssl-certificate argument of Netprobe's imagePath in registry.

/ssl-certificate-chain=<filename>

Sets the SSL certificate chain file used by the Netprobe to check the certificate of the Gateway when a connection is made.

Default: *<directory of installer>\\cert-chain.netprobe.pem*

If the default SSL certificate chain file is not used, then the file specified will be used within its directory. It will not be copied into the installation destination.

If the default SSL certificate chain file is used then it will be copied to the installation destination (for example, C:\\Program Files (x86)\\NetprobeNT) and this new path will be set as the value of *-ssl-certificate-chain* argument of Netprobe's imagePath in registry.

/ssl-certificate-key=<full path to file>

Sets the SSL certificate key used by the Netprobe in secure mode, or for REST API plug-in HTTPS connections. The file must be in PEM format.

If this is option not specified, but the certificate is, then the Netprobe looks for the key in the same file as the SSL certificate.

Default: <directory of installer>\\key.netprobe.pem

If the default SSL certificate key is not used, then the file specified will be used within its directory. It will not be copied into the installation destination.

If the default SSL certificate key is used, then it will be copied to the installation destination (for example, C:\\Program Files (x86)\\NetprobeNT) and this new path will be set as the value of -ssl-certificate-key argument of Netprobe's imagePath in registry.

/dir=<install\_dir> Sets the Netprobe installation path.
/log=<filename> Sets the Netprobe log filename.
/silent Runs the install with no user interaction, but you can see the installation progress.
/verysilent Does the same as /silent but it does not show the installer files being extracted.
/require-ssl-certificate-for This forces the Netprobe to require certain components connecting to the Netprobe port to provide a valid SSL certificate. If no certificate is provided or the certificate cannot be vaildated using the certificate authority provided by the -ssl-certificate-chain option, the connection will be rejected. Currently, this does not require any additional parameter as only the connection type EMF2 is supported.

The /nopassword option will override /pass option but ENCODED_PASSWORD will still be set in the registry.

To set up a Self-Announcing or Floating Netprobe from the installer wizard, check the "Install as Self-Announcing or Floating Netprobe" checkbox from the "Configure Self-Announcing or Floating Netprobe" screen. Select a configuration file from that screen.

You can also specify the Self-Announcing or Floating Netprobe configuration file through installer command-line switch. To do this, start a new Administrator command-line window and run geneos-netprobe-<version>.windows-<platform>.setup.exe.windows-x64.setup.exe /setup=<setup xml filename>, where <setup xml filename> specifies the full path to the Self-Announcing or Floating Netprobe configuration file:

geneos-netprobe-*<version>*.windows-<platform>.setup.exeExample: geneos-netprobe-*<version>*.windows-<platform>.setup.exe. 

For more information, see Self-Announce Settings .

To setup a secure Netprobe from the installer wizard, check the "Run probe in Secure Mode" checkbox from the "Configure Netprobe Secure Connections" screen. Select a PEM file that contains both the secure key and the secure certificate that the probe will use. This can also be done on the command line by using the /ssl-certificate flag. The flag followed by the name of the PEM file to use.

The certificate chain that is used to verify the certificates presented to the Netprobe can also be set either by using the wizard and setting the file on the "Configure Netprobe Secure Chain" page, or by using the /ssl-certificate-chain command flag. In both cases a file containing the certificates with which the presented certificates have been signed must be provided.

If you're doing a silent mode install using either /silent or /verysilent option then the /setup= switch should be used if a the probe is to run as a Self-Announcing or Floating Netprobe. The /ssl-certificate= flag should be used if the Netprobe is to run in a secure mode and only accept secure (TLS) connections from the gateway. The /ssl-certificate-chain= switch should be used if the Netprobe is to validate the gateway certificates prior to allowing the gateway to connect to the probe. If any of the files specified do not exist then the installer will fail silently and an 'Install Failed' line will be logged in the setup log. You can specify the log file with the /log=<log file> switch in the installer.

On completion, the Netprobe will have been installed and started running as a service. The relevant registry settings will also have been set up.

Note: If the Windows Win Apps Plug-in is to be run on a Windows 2008 Server, then it is necessary to alter the properties of the service to "Allow service to interact with desktop". See the Windows Win Apps plug-in documentation for further information.

Binary command-line options

The binary command line options are applicable to all platforms, unless otherwise stated.

Binary command line option Description
-help Displays a list of command line options and exits.

-version

-ver

-v

Displays version information and exits.
-port Sets the listening port for the Gateway connection.
-nolog Ignores any setting from the LOG_FILENAME variable and logs to the terminal instead.
-extract <key> <filename>

Extracts data embedded in the binary, writing it to the <filename> specified.

There are two supported values for <key>:

  • schema — extracts the Gateway Setup File schema embedded in the Netprobe binary.
  • npschema — extracts the Netprobe Setup File schema embedded in the Netprobe binary.
-noschema If invoked, the Netprobe does not publish the schema to the Gateway.

-setup

-setup <filename>

-setup <url>

Used when running the Netprobe in Floating or Self-Announcing mode. Specifies the Netprobe Setup File to use.

The Netprobe Setup File can be specified as a local file (<filename>) or a remote file (<url>).

If no <filename>or <url>is specified, then the Netprobe defaults to the netprobe.setup.xml file in the current working directory. The Netprobe Setup File needs to specify the connection details of one or more Gateways.

If you specify a remote file (<url> ), the Netprobe saves a copy of this in the current working directory as netprobe.setup.xml. This overwrites the default Netprobe configuration. In this case, any local changes to the netprobe.setup.xml configuration are ignored as the Netprobe retrieves the configuration from the remote file every -setup-interval <minutes>.

If you specify an invalid file from the <url>, or the <url> becomes inaccessible, then the Netprobe uses the default configuration.

Note: -setup <url> only supports HTTP links by default. If you need to set up an HTTPS connection, see the -setup-server-verify option.

When using -setup <url> with multiple instances of the Netprobe, check that you run each probe in its own directory. Otherwise, the setup for each probe may interfere with one another.

Do not use proxy servers for -setup <url>. Proxy servers are not supported.

The -setup <url> option is not supported for IBM AIX platforms.

-setup-interval <minutes>

Used in conjunction with -setup <url>. If -setup <url> is not defined, then this option is ignored.

Defines the time interval before the floating or Self-Announcing Netprobe requests another configuration file and restarts the announcement process. If no new or valid file is discovered, then the Netprobe neither reloads the configuration file nor restarts the configuration process.

If no -setup-interval is defined, the Netprobe makes the request every 360 minutes (or 6 hours), by default.

Note: This option is not supported for IBM AIX platforms.

-setup-server-verify <file>

Used in conjunction with -setup <url>. This option only takes effect when an HTTPS <url> is specified. Otherwise, this option is ignored.

When this option is invoked, the Netprobe verifies the remote server on the -setup <url> against the Certificate Authority (CA) bundle specified.

You can specify a CA bundle on the <file> argument in PEM format.

If no <file> is specified, then the Netprobe verifies the remote server against the operating system's Certificate Authority (CA) bundle. For these cases, the required certificates must be installed in the appropriate certificate stores.

Note: The <file> argument is not supported for Windows platforms.

For all Linux platforms, the Netprobe searches for the default ca-bundle file at </etc/pki/tls/certs/ca-bundle.crt>. However, in SLES platforms, the default ca-bundle is not at this path. For SLES platforms, we recommended that you specify a ca-bundle file for this option or create a symbolic link at </etc/pki/tls/certs/ca-bundle.crt> to the default ca-bundle file of SLES platform.

This option is not supported for AIX platforms.

-mdmtest <lua_script> [params]

Test utility for Market Data Monitor Lua script prior to deployment.

Example:

$./netprobe.linux -mdmtest test.lua param1 param2

-listenip

Sets a specific IP address where the Netprobe will listen to incoming connections.

This argument can be used to force Self-Announcing Netprobes not to listen for incoming connections. See Disable listening.

-ssl-certificate This is the file that contains the signed SSL server certificate in PEM format.
-ssl-certificate-key

This is the file that contains the signed SSL server private key in PEM format.

If this is option not specified, but the certificate is, then the Netprobe will look for the private key in the same file as the server certificate.

-ssl-certificate-chain This is the file that contains the trusted certificate authority.
-require-ssl-certificate-for

This forces the Netprobe to require certain components connecting to the Netprobe port to provide a valid SSL certificate.

If no certificate is provided, or the certificate cannot be vaildated using the certificate authority provided by the -ssl-certificate-chain option, the connection will be rejected. The connection type of the connections to check must be provided.

This command line option only supports the following argument:

  • emf2 — covers all Geneos components connecting using the Geneos EMF2 protocol.
-secure

If this option is present, the Netprobe will listen on a secure port rather than an insecure port.

If -secure is specified, then an SSL server certificate and an server private key also need to be specified.

-nopassword Run commands on the Netprobe's host, see Setting Passwords on Netprobe Commands.
-mq QM=<qm_name> MQSERVER=<conn_string> CHANTAB=<chan_table> KEYREPO=<ssl_keyrepo> CIPHER=<cipher_spec> Test MQ connection
  • QM — queue manager, e.g. qm.test
  • MQSERVER — server connection string, e.g. CHAN/TCP/host(port)
  • CHANTAB — full path to the channel table file, e.g. /var/mqm/AMQCLCHL.TAB
  • KEYREPO — full path to SSL key repository, e.g. /var/mqm/ssl/key(.kdb)
  • CIPHER — SSL cipher specification, e.g. TRIPLE_DES_SHA_US

Example value:
netprobe-mqQM=qm.testMQSERVER=CHAN/TCP/host

-minTLSversion Specifies the minimum TLS version. The accepted values are:
  • 1
  • 1.0
  • 1.1
  • 1.2
For more details, see Secure Communications.
-json2XML <filename>

Converts JSON document specified by <filename> to XML and displays result to the console.

Applicable to Windows platforms only.

-jvm-libpath <path>

Specifies <path> of the JVM library to use.

If this option is invoked, the Netprobe does not attempt to locate the library in the PATH or LD_LIBRARY_PATH environment variable. In Windows, the JVM_LIBPATH registry key is ignored.

Example value:
-jvm-libpath /usr/java/jdk/jre/lib/amd64/server/libjvm.so

Applicable to Windows platforms only.

-java-home <path>

Specifies the <path> of the JRE to use. Overrides the JAVA_HOME environment variable.

Applicable to Windows platforms only.

-perf

Show available performance monitor counters.

Applicable to Windows platforms only.

-cmd

Run in the foreground, rather than as a service.

Applicable to Windows platforms only.

-install

Installs the probe as a service.

Applicable to Windows platforms only.

-uninstall

Uninstalls the probe as a service.

Applicable to Windows platforms only.

-showcpus

Shows detected CPU information for this machine.

Applicable to Windows platforms only.

-disable-core-dump

Disables creation of core dump files.

Applicable to Windows platforms only.

-ifconfig, -if

Lists down the NICs present in the Windows machine. This should be used in configuring X-plugins send / recv interfaces.

Applicable to Windows platforms only.

-perfdebug

Dumps performance counter data into a file (i.e. perfout.dat).

Applicable to Windows platforms only.

-json2XML <filename>

Converts JSON document specified by <filename> to XML and displays result to the console.

Applicable to Windows platforms only.

Netprobe Security

Restricting Gateway Hosts

In order to provide an extra level of security, it is possible to configure a Netprobe to only accept connections from a nominated 'trusted' list of Gateway hosts.

This is done by setting the TRUSTED_GATEWAY_HOSTS variable, either as an environment variable on UNIX or in the registry on Windows (see Setting Variables for Netprobe on Windows Platforms). The variable should be set to the names of the trusted hosts, separated by commas.

TRUSTED_GATEWAY_HOSTS may contain a host alias as defined in /etc/hosts file. If TRUSTED_GATEWAY_HOSTS is set to "+", then any Gateway is trusted - this is equivalent to not setting the TRUSTED_GATEWAY_HOSTS variable.

Non-trusted hosts attempting to connect will cause a warning message to be logged on the Netprobe and to all connected Gateway and ActiveConsole Event Tickers.

For security reasons the TRUSTED_GATEWAY_HOSTS setting can only be set as a variable on the machine running the Netprobe - it is not possible to set it as part of the probe configuration on the Gateway.

Note: Only one Gateway should attempt to connect to each Netprobe. If multiple Gateways connect to a single Netprobe, only the first connection attempt will get a successful connection. The succeeding connection attempts will be rejected.

A similar setting TRUSTED_GATEWAY_NAMES can be configured to restrict Gateways connecting to Netprobe in the same manner as TRUSTED_GATEWAY_HOSTS above. This setting checks the Gateway name rather than the host.

Restricting HTTP Hosts

It is also possible to configure a Netprobe to only accept HTTP connections from a nominated 'trusted' list of HTTP hosts.

This is done by setting the TRUSTED_HTTP_HOSTS variable, either as an environment variable on UNIX or in the registry on Windows (see Setting Variables for Netprobe on Windows Platforms). The variable should be set to the names of the trusted hosts, separated by commas.

TRUSTED_HTTP_HOSTS may contain a host alias as defined in /etc/hosts file. If TRUSTED_HTTP_HOSTS is set to "+", then any HTTP host is trusted - this is equivalent to not setting the TRUSTED_HTTP_HOSTS variable.

Non-trusted hosts attempting to connect via HTTP will cause a warning message to be logged on the Netprobe and to all connected Gateway and ActiveConsole Event Tickers.

Setting Passwords on Netprobe Commands

The user can configure commands in their Gateway which will be executed by the machine running one of the Netprobes to which it is connected. Because there are clearly some security implications in permitting one machine to run a command on a different machine, this functionality is by default password controlled, i.e. the user will be prompted for a password when running such a command. There are several options open when setting this up.

Running with No Password

The user may choose to allow commands to be able to run on the Netprobe without any prompting for a password. To do this, the Netprobe executable should be launched with the command line option -nopassword

Note: For security reasons, it is NOT recommended to allow commands to be run on the Netprobe without password protection. The user may, however, find this option useful for trying things out while initially creating a setup.

If running with no password then, in the configuration of the command itself in the Gateway Setup, the field "Enable Password" should be unticked (which is its default state).

When running as a service on Windows, no password mode can be enabled by any of the following:

  • Checking the [Run Netprobe commands with no password] option during the Netprobe Setup Wizard installation,
  • Adding the '/nopassword' option during command line installation, or
  • Setting: NOPASSWORDtrue in the registry. See Setting Variables for Netprobe on Windows Platforms for details on how to do this.

Configuring the Command to prompt for a Password

If a password is going to be used with a Netprobe command then, in the configuration of the command itself in the Gateway Setup, the field "Enable Password" should be ticked. This will cause a dialogue to be displayed when the command is run, to allow the user to supply the password. If the command already asks for user input to the command, then the input box for the password will be an additional field in the dialogue displayed for the rest of the user input. Having ticked this field, the user now needs to define the password by one of the methods explained in the two sections below.

Setting the Password from the Gateway Configuration

A password can be specified in the Gateway Setup File configuration (see probes > probe > encodedPassword). The user enters the plain text version of the password that they wish to use into a dialogue in the Gateway Setup Editor. An encoded version of the password is stored in the configuration file generated by the Gateway Setup Editor. When the Gateway connects to the Netprobe, it downloads this password to the Netprobe. Whenever a command to run on the Netprobe is subsequently initiated, the user will be prompted to input the plain text version of the password.

Note: The option to set a password via the configuration is not available with Self-Announcing Netprobes; for these the password must be set on the Netprobe itself.

Setting the Password on the Netprobe

Alternatively, the password can be set on the Netprobe itself by setting a variable ENCODED_PASSWORD (see Variables for more information on setting variables).

To use this method, firstly the user needs to generate an encoded password. This is done using the Gateway executable. So on a machine where the Gateway software has been installed, run the command <gatewayexecutable>-pw<password><salt> where <gateway executable> is the name of the executable. This is "gateway2." followed by an operating-system dependant suffix.

<password> is the password, in plain text, which the user wishes to use.

<salt> is any two character string that the user chooses. This is used to introduce a random element to the password encoding algorithm.

So, for example, to generate the encoded version of the password for the plain text password "fred", using a salt string of "ab", on a Solaris X86 Gateway machine, run the command gateway.sunx86-pwfred ab

Running this command will return the encrypted password string to standard out.

The encrypted password value should then be set in the ENCODED_PASSWORD variable before then starting up the Netprobe. Whenever a command to run on the Netprobe is subsequently initiated, the user will be prompted to input the plain text version of the password.

Only Allowing a Password to be Set on the Netprobe

A user may wish to have a security policy on the Netprobe where the password cannot be set via the Gateway configuration, it can only be set by using the ENCODED_PASSWORD variable on the Netprobe. This policy can be enforced by setting the variable ALLOW_ENCODED_PASSWORD_DOWNLOAD to false (see Variables for more information on setting variables) before starting the Netprobe. If this is set to false and the Gateway is configured to download a password, then a message appears in the Netprobe log telling the user that the downloaded password has been ignored. If this variable is not set then by default the password can be downloaded from the Gateway.

Using Transport Layer Security (TLS) 

Geneos components can communicate using Transport Layer Security (TLS) as well as TCP/IP. This is configured using command line options for a listening gateway and using the xml setup file for Floating and Self-Announcing Netprobes. See Secure Communications.

Netprobe Internal Commands

Commands are the primary method of interaction between the Gateway and connected users. Commands are invoked by users through a controlling process (such as ActiveConsole) which prompts Gateway to perform a given operation. For more information on Commands in general, see the chapter in the Gateway 2 Reference Guide entitled "Commands". Internal commands are commands which are provided and which affect the internal operations of the system. Internal Commands fall into two types, System Commands (Commands which allow control of the System) and Legacy Commands (Commands which are provided for use with legacy Netprobes which do not export their own Commands).

There are a couple of internal commands available which directly relate to Netprobes.

/PROBE:disableSelfAnnouncing  
Name /PROBE:disableSelfAnnouncing
Type (System or Legacy) System
Brief Description Disables Self-Announcing mode and updates the Netprobe Commands
More Information See Netprobe Commands in Appendix A: Internal Commands, System commands section of the Gateway2 Reference Guide.

/PROBE:viewLog  
Name /PROBE:viewLog
Type (System or Legacy) Legacy
Brief Description View the Netprobe log file
More Information See Netprobe Commands in Appendix A: Internal Commands, Legacy commands section of the Gateway2 Reference Guide.

Floating and Self-Announcing Netprobes

Floating Netprobes

In Floating mode, a Netprobe and Managed Entity will already be configured on the Gateway but without connection details. On starting, the Netprobe will inform the Gateway of its hostname and its listen port, and the Gateway will then connect as normal. This allows a Netprobe to automatically follow an application that migrates between servers.

Self-Announcing Netprobes

For a Self-Announcing Netprobe, no Netprobe or Managed Entity need be configured on the Gateway. Instead the Netprobe Setup File specifies both the Probe name and Managed Entity name along with one or more type names that correspond to types in the Gateway Setup File. This allows Netprobes to start up on any hosts and immediately be configured with default monitoring.

In addition, the Netprobe Setup File can specify zero or more Managed Entity Attribute name-value pairs. These can be used by ActiveConsole for searching and sorting purposes. Attributes are typically used with the logical mode of the ActiveConsole State Tree.

Netprobe Setup File can also set user defined variables that will be set on the created Managed Entity. Managed Entities can contain any number of variables. The variables section is not parsed by the probe, it is passed to the gateway to be checked. All variable types that can be entered on in the gateway setup are accepted except for activeTime and any passwords.

Load Balancing

In Self-Announcing mode, the Netprobe Setup File must specify one or more Gateways to announce to.

When more than one Gateway is specified, the following occurs:

  1. The Netprobe attempts to contact each Gateway.
  2. The Gateways respond, indicating if they are willing to accept the Netprobe. Each Gateway provides its score, indicating how highly loaded it is. See Score.
  3. The Netprobe picks the least loaded Gateway to announce to, and listens for a connection in the normal way.
  4. If there is a tie, the Netprobe picks the first of the least loaded Gateways, in the order specified in the Netprobe Setup File.

Score

Self-announcing Netprobes use the Gateway score to determine what Gateway to connect to.

Each Netprobe gives an individual score which represents the load it puts on a Gateway. The Gateway score is the total of the scores from every Netprobe on a Gateway. The score is a measure of how loaded a Gateway is. Currently, the score is the number of samplers configured on a Netprobe.

You can use the Probe Data plugin to see the score from each Netprobe. See Probe data.

Rebalance self-announcing Netprobes

You can redistribute SANs across your Gateways using the Rebalance Self-Announcing Netprobes command. This command removes SANs from a Gateway to either reach a target number of SANs or to reach a target Gateway score.

You may want to use this command to redistribute SANs to a recently restored Gateway from other Gateways across your cluster.

See Gateway Commands.

Disable listening

There are two ways to configure self-announcing Netprobes not to listen for incoming connections on their configured port:

  • Use the command line argument -listenipwith the value none.
  • Set the environment variable LISTEN_IP to none.

Either method does not remove the configured port from the Netprobe, and the port is still used by Gateway to identify its connection with the Netprobe.

Snooze and user assignment information on self-announcing probes

Self-announcing Netprobes (SANs) store snooze and user assignment information in files in the Netprobe directory. The files have the following filenames, where <probename> is the name of the SAN configured in the Netprobe setup file:

  • <probename>.snooze — contains snooze information.
  • <probename>.user_assignment — contains user assignment information.

Netprobe Setup File

File format

The Netprobe Setup File is formatted as an XML document, as described by the XML 1.0 specification. This format is both strict and extensible, and was chosen to allow for better validation of the configuration.

In particular, the contents of a valid XML document can be described by a set of rules called the schema. This schema is distributed with the Netprobe and can be used by any schema-aware XML editor to ensure that the Setup File is well-formed XML, and that the contents are valid. A copy of the Netprobe schema can be extracted from the Netprobe using the command:

<netprobe executable> -extract npschema <filename>

File contents

The Netprobe Setup File has a single top-level Netprobe element under which it can have either a selfAnnounce or floating element.

Self-Announce Settings

selfAnnounce

Setup values for Self-Announcing Netprobe mode.

Mandatory: No

selfAnnounce > enabled

Enables or disables Self-Announcing Netprobe mode.

Mandatory: Yes

selfAnnounce > retryInterval

Specifies the time in seconds that the Netprobe will wait after failing to find a suitable Gateway to announce to, or after the master connection is dropped, before restarting the polling process.

Mandatory: No
Default: 60
selfAnnounce > requireReverseConnection

Optional setting that can be set to indicate that the Netprobe can only make a netprobe-to-gateway connection (for example, because it is behind a firewall). Self-announcing probes will make netprobe-to-gateway connections by default where both components support it, this setting ensure that the probe will not select a gateway that does not support reverse connections and will prevent the gateway from publishing the 'Disable Self Announcing' command for the probe.

The default value for this depends upon whether the Netprobe is configured to connect to a secure gateway. If any of the gateway connections have the secure flag set to true, then the default value for this setting is true, and it cannot be overridden. This is because gateway-to-netprobe are not supported secure self announcing probe connections. If all the gateways connected to are insecure then the default value of this setting is false, but it can be set to true to ensure that all connections are netprobe-to-gateway.

Mandatory: No
Default: Dependent on other settings (see above)
selfAnnounce > probeName

The name of the probe to create on the Gateway. This name must not already be in use in the Gateway configuration, or be used by other Self-Announcing Netprobes.

The probe name can be composed of any number of data elements containing raw text and special macro elements that resolve to installation-specific strings such as hostname. This allows a single Setup File to be used for Self-Announcing Netprobes on many different servers.

The following macro elements are supported:

Setting Description
hostname The server hostname
port The Netprobe listen port

e.g. To create a probe name of "hostname port", where the correct values are automatically inserted for hostname and port, the following should be specified in the xml:

<probeName><hostname/><data>_</data><port/></probeName>

Mandatory: Yes

selfAnnounce > probeName > data

Raw text element of probe name.

Mandatory: No

selfAnnounce > probeName > hostname

Hostname element of probe name.

Mandatory: No

selfAnnounce > probeName > port

Netprobe Listen Port element of probe name.

Mandatory: No

selfAnnounce > restApiHttpPort

Insecure port where content is ingested by the REST API plug-in. This port is used by all REST API samplers running on the probe.

By default, the REST API plug-in listens only on this port. If you create a REST API sampler without configuring any listening port, then this default behaviour applies.

If you configure both insecure and secure ports, then the REST API sampler listens on both ports concurrently.

Caution: If you set the same value for both HTTP and HTTPS ports, then the Netprobe only starts the REST API HTTPS server. If the SSL certificate or key is invalid for the server, then the Netprobe does not start the HTTP server.

Note: Updating the port causes all REST API samplers on the probe to reload.

If you do not configure this setting, but there exists a REST API sampler under the type specified in selfAnnounce > managedEntities > managedEntity > types, then the Self-Announcing Netprobe starts a REST API HTTP server with the default port 7136.

Mandatory: No

Default: 7136

selfAnnounce > restApiHttpsPort

Secure port where content is ingested by the REST API plug-in. This port is used by all REST API samplers running on the probe.

This setting requires an SSL certificate and SSL certificate key.

If you configure this port without configuring the insecure port, then the REST API sampler listens only on the secure port.

If you configure both insecure and secure ports, then the REST API sampler listens on both ports concurrently.

Caution: If you set the same value for both HTTP and HTTPS ports, then the Netprobe only starts the REST API HTTPS server. If the SSL certificate or key is invalid for the server, then the Netprobe does not start the HTTP server.

When you use HTTPS for the REST API plug-in, follow these guidelines:

  • The common name must be the REST API server host name associated with the SSL certificate.
  • As a best practice, use the same certificate authority (CA) as is used for other Netprobe certificates.
  • The certificate created is used by the REST API plug-in as well as the Netprobe to communicate with the Gateway. The Netprobe only uses the certificate if it is in secure mode.

Note: Updating the port causes all REST API samplers on the probe to reload.

Note: If this option is set, then the REST API plug-in uses the SSL certificate and SSL certificate key as specified in the -ssl-certificate and -ssl-certificate-key command-line parameters, respectively. For more information, see Netprobe Command-line Options.

If you do not configure this setting, but there exists a REST API sampler under the type specified in selfAnnounce > managedEntities > managedEntity > types, then the Self-Announcing Netprobe starts a REST API HTTP server with the default port 7136.

Mandatory: No

selfAnnounce > managedEntities

List of managedEntity sections.

Mandatory: Yes

selfAnnounce > managedEntities > managedEntity

Specifies the configuration details for the Managed Entity to be created on the Gateway.

Mandatory: Yes

selfAnnounce > managedEntities > managedEntity > name

The name of the Managed Entity to create on the Gateway. This name must not already be in use in the Gateway configuration or be used for other Self-Announcing Netprobes. The Managed Entity name is case sensitive.

Mandatory: Yes

selfAnnounce > managedEntities > managedEntity > attributes

A list of user defined attributes that will be applied to the created Managed Entity. Managed Entities can contain any number of attributes. Each attribute is specified as a name-value pair containing a textual value. These attributes can then be used for searching and sorting in ActiveConsole. Mandatory: No

selfAnnounce > managedEntities > managedEntity > variables

A list of user defined variables that will be set on the created Managed Entity. Managed Entities can contain any number of variables. The variables section is not parsed by the probe, it is passed to the gateway to be checked. Variables setting can be copied from XML Section of Gateway > ManagedEntity > Advanced tab > Var in Gateway Setup Editor or from gateway setup file. Mandatory: No

Variables reject reason

Gateway will ignore these variables reporting an error in both gateway and probe logs.

1. If a variable of activeTime or any password type is set in Netprobe Set-Up file.

Example:

<var name="var_ActiveTime"> 
	<activeTime>
		<activeTime ref="ABC"> </activeTime>
	</activeTime>
</var>

Error:

In Netprobe Log:

ERROR: SelfAnnouncing Message from gateway '<PROBENAME>' (<HOST:PORT>): Variable var_ActiveTime ignored, as Self Announcing Probes do not support activeTime variable type.

In Gateway Log:

ERROR: DirectoryManager Variable var_ActiveTime ignored, as Self Announcing Probes do not support activeTime variable type. [/variables[@disabled!="true"][1]/var[@disabled!="true"]

If there is a parse error for the variable section gateway and probe will report the error and ignore the variable and not set it.

Example:

<var name=""> <double>10.1</double> </var>

Error:

In Netprobe Log:

ERROR: SelfAnnouncing Message from gateway '<PROBENAME>' (<HOST:PORT>): Environment variable defined without a name.

In Gateway Log:

ERROR: DirectoryManager Environment variable defined without a name. [/variables[@disabled!="true"][1]/var[@disabled!="true"

selfAnnounce > managedEntities > managedEntity > types

A list of referenced types that will be applied to the created Managed Entity. These types refer to the named types in the Gateway configuration. These types (and the associated samplers) will be loaded into the created Managed Entity when the Netprobe connects to a Gateway. Duplicate types will be ignored.

Mandatory: No

selfAnnounce > managedEntity

Deprecated. A managedEntity must now be inside the managedEntities section. See selfAnnounce > managedEntities > managedEntity.

selfAnnounce > managedEntity > name

Deprecated. See selfAnnounce > managedEntities > managedEntity > name.

selfAnnounce > managedEntity > attributes

Deprecated. See selfAnnounce > managedEntities > managedEntity > attributes.

selfAnnounce > managedEntity > variables

Deprecated. See selfAnnounce > managedEntities > managedEntity > variables.

selfAnnounce > managedEntity > types

Deprecated. See selfAnnounce > managedEntities > managedEntity > types.

selfAnnounce > gateways

A list of candidate Gateways that the Netprobe attempts to connect to. The order of the list determines which Gateway the Netprobe connects to if there is a tie.

See Load Balancing.

Mandatory: Yes, at least 1 Gateway must be configured

selfAnnounce > gateways > gateway > hostname

The hostname of a candidate Gateway, to which the Netprobe will connect.

Mandatory: Yes

selfAnnounce > gateways > gateway > port

The listen port of a candidate Gateway, to which the Netprobe will connect.

Mandatory: Yes

selfAnnounce > gateways > gateway > secure

Flag to indicate if the probe should use a secure or an insecure protocol when connecting to the gateway.

Mandatory: No
Default: False

Floating Settings

floatingProbe

Setup values for Floating Netprobe mode.

Mandatory: No

floatingProbe > enabled

Enables or disables Floating Netprobe mode.

Mandatory: Yes

floatingProbe > retryInterval

Specifies the time in seconds that the Netprobe will wait after failing to announce itself to a Gateway, or after the master connection is dropped, before restarting the announcing process.

Mandatory: No
Default: 60
floatingProbe > requireReverseConnection

Optional setting that can be set to indicate that the Netprobe can only make a netprobe-to-gateway connection (for example, because it is behind a firewall). Floating probes will make netprobe-to-gateway connections by default where both components support it, this setting ensures that the probe will not negotiate a connection to a gateway that does not support reverse connections.

The default value for this depends upon whether the Netprobe is configured to connect to a secure gateway. If any of the gateway connections have the secure flag set to true, then the default value for this setting is true, and it cannot be overridden. This is because gateway-to-netprobe are not supported secure self announcing probe connections. If all the gateways connected to are insecure then the default value of this setting is false, but it can be set to true to ensure that all connections are netprobe-to-gateway.

Mandatory: No
Default: Dependent on other settings (see above)
floatingProbe > probeName

Specifies the name of this Netprobe. The probe must already have been configured as a floatingProbe on the Gateway being contacted.

Mandatory: Yes

floatingProbe > gateways

The Gateway or Gateways to which the Floating Netprobe should connect. Up to two Gateways are allowed. If two are set then they must be a hot-standby pair.

Mandatory: Yes, at least one Gateway must be configured.

floatingProbe > gateways > gateway > hostname

The hostname of the Gateway to which the Netprobe should connect.

Mandatory: Yes

floatingProbe > gateways > gateway > port

The listen port of the Gateway to which the Netprobe should connect.

Mandatory: Yes

floatingProbe > gateways > gateway > secure

Flag to indicate if the probe should use a secure or an insecure protocol when connecting to the gateway.

Mandatory: No
Default: false

Example Netprobe Setup Configurations

Self-Announcing

<?xml version="1.0" encoding="ISO-8859-1"?>
<netprobe
        compatibility="1"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="http://schema.itrsgroup.com/GA2011.2-110303/netprobe.xsd">
        <selfAnnounce>
                <enabled>true</enabled>
                <retryInterval>60</retryInterval>
                <requireReverseConnection>false</requireReverseConnection>
                <probeName>myProbe</probeName>
                <managedEntities>
	                <managedEntity>
	                        <name>myEntity</name>
	                        <attributes>
	                                <attribute name="COUNTRY">USA</attribute>
	                                <attribute name="CITY">CHICAGO</attribute>
	                                <attribute name="ENVIRONMENT">PROD</attribute>
	                        </attributes>
	                        <variables>
	                                <var name="var_string">
	                                        <string>selfProbe</string>
	                                </var>
	                                <var name="var_double">
	                                        <double>10.1</double>
	                                </var>
	                        </variables>
	                        <types>
	                                <type>Linux</type>
	                                <type>Fidessa</type>
	                                <type>ProdShare</type>
	                        </types>
	                </managedEntity>
                </managedEntities>			
                <gateways>
                        <gateway>
                                <hostname>chimx165</hostname>
                                <port>17101</port>
                                <secure>true</secure>
                        </gateway>
                        <gateway>
                                <hostname>chimx165</hostname>
                                <port>17102</port>
                        </gateway>
                        <gateway>
                                <hostname>chimx165</hostname>
                                <port>17103</port>
                                <secure>false</secure>
                        </gateway>
                </gateways>
        </selfAnnounce>
</netprobe>

Floating

<?xml version="1.0" encoding="ISO-8859-1"?>
<netprobe
        compatibility="1"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="http://schema.itrsgroup.com/GA2011.2-110303/netprobe.xsd">
        <floatingProbe>
                <enabled>true</enabled>
                <retryInterval>60</retryInterval>
                <requireReverseConnection>false</requireReverseConnection>
                <probeName>myFloatingProbe</probeName>
                <gateways>
                        <gateway>
                                <hostname>chimx158</hostname>
                                <port>17101</port>
                                <secure>false</secure>
                        </gateway>
                </gateways>
        </floatingProbe>
</netprobe>

Gateway Setup

For references to Gateway Setup requirements when using Floating and Self-Announcing Netprobes, see Gateway Setup Settings for Netprobe.

Rejection Reasons

Floating

Gateways may refuse to accept a Floating Netprobe for the following reasons:

  • The probe name is not configured as a floatingProbe in the Gateway setup.
  • A probe under the required name is currently connected to the Gateway.
  • Probe has been configured to require a reverse connection but the Gateway does not support that feature.
  • Probe is trying to connect insecurely on a secure Gateway Port.
  • Probe is trying to connect securely on an insecure Gateway Port.

Self-Announcing

Gateways may refuse to accept a Self-Announcing Netprobe for the following reasons:

  • The probe name specified in the Netprobe Setup File is already in use by a Netprobe specified in the Gateway Setup File.
  • The Managed Entity name specified in the Netprobe Setup File is already in use by a Managed Entity specified in the Gateway Setup File.
  • The Gateway is an inactive (secondary) Gateway in a hot-standby pair.
  • Self-Announcing is disabled on the Gateway.
  • The Gateway has reached its Self-Announcing Netprobe limit.
  • The Gateway is configured to reject the Self-Announcing Netprobe's Managed Entity attributes.
  • Probe has been configured to require a reverse connection but the Gateway does not support that feature.
  • Probe is trying to connect insecurely on a secure Gateway Port.
  • Probe is trying to connect securely on an insecure Gateway Port.

Potential Configuration Conflicts

Gateway Behaviour

When a Self-Announcing Netprobe is accepted by a Gateway, it is added to the Gateway's live directory (as displayed in the State Tree of the ActiveConsole) but not to the Gateway's Setup File. Future edits to the Gateway Setup File can conflict with the Self-Announcing Netprobe, in which case they are resolved using the following rules:

  • In general, the Gateway Setup File always wins.
  • If a setup conflicts with the probe name of a Self-Announcing Netprobe, then the Self-Announcing Netprobe is dropped by the Gateway.
  • If a setup conflicts with the Managed Entity name of a Self-Announcing Netprobe, then the Self-Announcing Netprobe is dropped by the Gateway.
  • If a setup conflicts with the connection details of a Self-Announcing Netprobe, then the Self-Announcing Netprobe is dropped by the Gateway.

Netprobe Behaviour

The initial connection made to a Self-Announcing Netprobe is marked as temporary by the Netprobe. If another Gateway connects with a permanent connection (i.e. one configured in its Setup File) then the Netprobe will drop the temporary connection in favour of the permanent one.

Once a Netprobe has a permanent connection from a Gateway it behaves as a Normal Netprobe and will never drop the connection, and will refuse all other Gateway connections.

Disconnection Behaviour

If a Gateway to self-announcing Netprobe (SAN) connection is disconnected, either due to network failure or one party dropping the connection for one of the reasons stated above, then the following rules apply:

  • The Netprobe waits a configurable timeout for the Gateway (or a hot-standby Gateway) to reconnect. Once this timeout is exceeded, the SAN reverts to polling all the Gateways specified in its Setup File and look for another Gateway to announce itself to.
  • If a connection is disconnected, then the Gateway keeps the SAN in its directory for a configurable timeout, and attempts to reconnect. Once this timeout is exceeded, the Gateway removes the SAN from the live directory and ceases attempting to connect to it.
  • If a connection is rejected by the Netprobe, then the Gateway immediately removes the Netprobe from the live directory and ceases attempting to connect to it.

Disassociate Probe Command

The Disassociate Probe command can be used to remove a SAN from a Gateway. This command is available on SANs with a connection status that is not Up or WaitingForProbe.

Only use this command when a SAN has failed, or has moved to another Gateway but the original Gateway was not notified. This can happen when there is a load-balancer between the SAN and the Gateway, or the connection was suspended.

Caution: If the SAN is up when this command is used, it may connect to a different Gateway. If the SAN does connect to a different Gateway, any snooze or user assignment information is lost.

This command is not available on imported SANs.

Hot Standby Gateways

Where Hot Standby Gateway pairs are used, both should be specified in the Netprobe Setup File. A non-active Gateway will refuse to accept the Netprobe so there is no risk of the Netprobe choosing a secondary Gateway while the primary is still up.

Netprobe Plug-In Whitelist

Plug-In Whitelist

The Plug-In Whitelist is a list of plug-in names that determine is a plug-in can be used by the Netprobe for sampling. If a plug-in is not specified in the whitelist, then the sampler associated with the plug-in cannot perform sampling during runtime.

The whitelist is specified in the Netprobe Setup File.

Note: If no setup file is specified, or if the whitelist does not contain any valid plug-in names, then all plug-ins are allowed by default.

Plug-in names that can be used follow the ones specified in the Gateway Setup Editor.

Below is a screenshot of a disabled sampler:

../../Resources/Images/active-console/legacy-images/image1_netprobe_user_guide.png

Netprobe Setup File

File Format

This follows the same XML format specified in Netprobe Setup File Format.

File Contents

Aside from the elements specified in Netprobe Setup File Contents, the Netprobe setup file can also have a pluginWhiteList element.

Plug-in Whitelist Settings

pluginWhiteList

Contains the list of plug-in names to be enabled Mandatory: No

pluginWhiteList > data

Specifies a plug-in name to be enabled.

Mandatory: No

Example Netprobe Setup Configurations for whitelist

Plug-in Whitelist (Enables CPU and TOP plug-ins)

<netprobe>
        <pluginWhiteList>
                <data>cpu</data>
                <data>top</data>
        </pluginWhiteList>
</netprobe>

Netprobe Command Whitelist

Command Whitelist

The Command Whitelist is a list of shell commands that can be used by the Netprobe for sampling. If a shell command is not specified in the whitelist, then an error will be shown in the dataview.

Affected commands are configurable plug-in shell commands that are invoked by the plug-ins themselves, as well as user commands specified via the gateway setup editor and are invoked by the user in the active console.

The whitelist is specified in the Netprobe Setup File.

Note: If no setup file is specified, or if the whitelist does not contain any shell commands, then all shell commands are allowed by default.

The command white list makes use of regular expressions to specify the allowed commands. Syntax is based on Perl-Compatible Regular Expressions (PCRE).

When matching for exact strings, always terminate your regular expressions (b).

Below are screenshots of error messages:

../../Resources/Images/active-console/legacy-images/image2_netprobe_user_guide.png ../../Resources/Images/active-console/legacy-images/image3_netprobe_user_guide.png

Affected Plugins and Features

Below is the list of plug-ins and features that have user-configurable shell commands that are affected by the command whitelist:

Caution: In Toolkit plug-in, you can use the Advanced functionality to write the script to the server. Unless the Toolkit Advanced tab is secured by a Gateway hook validation, it is possible to workaround the restriction set in the command whitelist.

  • cpu
  • toolkit
  • network
  • processes
  • gl-orderbook
  • fidessa
  • flm
  • gl-lostorders
  • informix
  • ipc
  • market-data-monitor
  • net-ping
  • tcp-links
  • unix-users
  • veritas-cluster-server

Netprobe Setup File

File format

This follows the same XML format specified in Netprobe Setup File Format.

File contents

Aside from the elements specified in Netprobe Setup File Contents, the Netprobe setup file can also have a commandWhiteList element.

Command Whitelist Settings

commandWhiteList

Contains the list of shell commands to be enabled

Mandatory: No

commandWhiteList > data

Specifies a shell command to be enabled.

Mandatory: No

Example Netprobe Setup Configurations for whitelist

Command Whitelist (Enables "echo test" command and "cat <anything>" command)

<netprobe>
        <commandWhiteList>
                <data>echo test\b</data>
                <data>^cat.*</data>
        </commandWhiteList>
</netprobe>

Files Included in the Netprobe Package

Some users like to know a breakdown of what each of the files in the Netprobe package does, so that they can decide to remove files that they don't feel they need, or to only update those files that they feel they need when doing an upgrade. If in any doubt, users are strongly recommended to keep all the files in their installation and to update all the files when doing an upgrade.

For a comprehensive list of files included in the Netprobe binary for all platforms, see Files included in the Netprobe package.

Sample Toolkit plug-in scripts in Windows

wgetenv3.exe

Running wgetenv3.exe reg.txt, for example, where the file reg.txt contains:

[H] logPixelsHEX hkey_current_config\software\fonts\logpixels    [HEX]
[H] logPixelsDEC hkey_current_config\software\fonts\logpixels [DEC]
[L] sysID HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\identifier [STR]
[L] sysBIOSDate HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\SystemBiosDate [STR]
[L] videoBIOSDate HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\VideoBiosDate [STR]
[L] videoBIOSVersion HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\VideoBiosVersion [STR]

generates the following input to a toolkit sampler:

name,value
<!>logPixelsHEX,60
<!>logPixelsDEC,96
sysID,AT/AT COMPATIBLE
sysBIOSDate,06/23/08
videoBIOSDate,03/26/09
videoBIOSVersion,HWEAASUS EN9400GT VBIOS Ver 62.94.71.00.AS01 HWEAASUS
EN9400GT VBIOS Ver 62.94.71.00.AS01 HWEAASUS EN9400GT VBIOS Ver
62.94.71.00.AS01 Version 62.94.71.00.13  Version 62.94.71.00.13  Version
62.94.71.00.13  Version 62.94.71.00.13
W3C XML 1.0 (Fourth Edition) Specification - http://www.w3.org/TR/2006/REC-xml-20060816