NetXMS Scripting Language

Table of Contents

About This Document
Introduction
Script Security
Getting Started
Working with NetXMS
Language Syntax
Function Reference
Class Reference
Global Constants
Formal Grammar
Examples
Deprecated Functions
Alphabetical Index

About This Document

This is the official documentation for NXSL (NetXMS Scripting Language), the embedded scripting language for the NetXMS network monitoring system.

The documentation is organized into the following main sections:

Language Guide - Introduction, script security, getting started, working with NetXMS, and language syntax
Function Reference - Complete reference of all NXSL functions organized by category
Class Reference - Complete reference of all NXSL classes organized by domain
Alphabetical Index - Quick-reference of all functions and classes in alphabetical order
Appendices - Global constants, formal grammar, examples, and deprecated functions

Note	This documentation is maintained at https://github.com/netxms/nxsl-doc/ If you find any errors or issues in this documentation, please report them on GitHub: https://github.com/netxms/nxsl-doc/issues

Introduction

In many parts of the system, fine tuning can be done by using NetXMS built-in scripting language called NXSL (stands for NetXMS Scripting Language). NXSL was designed specifically to be used as embedded scripting language within NetXMS, and because of this has some specific features and limitations. Most notable is very limited access to data outside script boundaries – for example, from NXSL script you cannot access files on server without explicit permission, nor call external programs, nor even access data of the node object other than script is running for without explicit permission. NXSL is interpreted language – scripts first compiled into internal representation (similar to byte code in Java), which than executed inside NXSL VM.

Script Security

Because NXSL provides functions for searching objects, and because all scripts are executed on management server, user with write access to only one node can potentially acquire information about nodes to which he normally does not have access. For example, without additional security checks user with write access to node A and no access to node B can create transformation script for DCI on node A and use FindNodeObject function to access node B and get information about it, thus breaking security settings.

To prevent such scenario, all NXSL functions capable of accessing NetXMS objects requires "current node" object to be provided. Reference to object being searched will only be returned if node object supplied as "current node" is in trusted nodes list of target object. For example, if variable $node in script refers to NODE1, and FindNodeObject($node, "NODE2") called, NODE1 must be added to list of trusted nodes for NODE2. In most places (transformation script, event processing policy, etc.) predefined variable $node exists, which refers to node object on behalf of which script is being executed. It will be event source for event processing policy script, DCI owner for transformation script, and so on.

For environments where strict security checks are required, they can be enabled via server configuration. Enforcement of trusted nodes checking is controlled by server’s configuration variable Objects.Security.CheckTrustedObjects. By default it is set to 0 and check of trusted nodes is not enforced. To enable it, server’s configuration variable Objects.Security.CheckTrustedObjects must be set to 1. The server restart is required to make this change effective.