News:

We really need your input in this questionnaire

Main Menu

NetXMS 4.3 released

Started by Victor Kirhenshtein, January 26, 2023, 08:05:10 PM

Previous topic - Next topic

Victor Kirhenshtein

We're excited to announce the release of version 4.3 of NetXMS! This new version brings a bunch of new features and improvements, including:

- Python-style format strings in NXSL;
- Inline action scripts in EPP;
- The ability to set and delete custom attributes in EPP rules;
- Column display names in object queries can be set using column metadata;
- New agent metrics for file type and file content;
- A brand new "File Monitor" dashboard element.

We've also fixed bunch of bugs and made several other improvements, like correctly reading LLDP information from devices that only support LLDP-V2 MIB and improving object queries.

We've also made a slight change to our versioning system. Similar to before, releases are defined by a major and minor version (like 4.3 in this case) and all components with the same major.minor version number are guaranteed to work together. However, we're now hiding the build number for regular releases. The third number in the version will indicate an official patch release, with 0 being the initial release for that version. Any builds in between official releases will be denoted by a fourth number, which indicates the build number after the patch release.

Full change log can be found here: https://netxms.com/release-notes

Thanks,
The NetXMS Team

2b2bff

Thanks a lot. 

Sadly the DB upgrade for MSSQL fails because event_cfg.description is a TEXT column and the upgrade script compares it with VARCHAR in the WHERE clause.
Simple fix - please change all TEXT columns to VARCHAR(MAX). TEXT has been deprecated long time ago...
https://learn.microsoft.com/en-us/sql/t-sql/data-types/ntext-text-and-image-transact-sql

Cheers

adrian69

Hello and thanks for the update!

Having issue with some of my network service monitors (different ports and protocols) after upgrading to 4.3. Nothing actually works, except for HTTP checks. Neither HTTPS nor Telnet. 
How can configure a custom network service monitor (not DCI, and obviously using netsvc)? Is there any recent documentation that would possibly clarify this for me?

Example debug log HTTPS request:

  ** 000000: [    8] INETADDR    X.X.X.X
  ** 000020: [  130] INT16      6
  ** 000028: [  132] INT16      443
  ** 000030: [  131] INT16      6
  ** 000038: [  133] UTF8-STRING "my.host/api/satus"
  ** 000070: [  134] UTF8-STRING "200"
2023.01.31 08:44:33.938 *D* [comm.cs.171        ] Received message CMD_CHECK_NETWORK_SERVICE (3)
2023.01.31 08:44:33.939 *D* [comm.cs.171        ] Command processed by sub-agent NETSVC
2023.01.31 08:44:33.939 *D* [comm.cs.171        ] Sending message CMD_REQUEST_COMPLETED (ID 3; size 64; uncompressed)
2023.01.31 08:44:33.939 *D* [comm.cs.171        ] Outgoing message dump:
2023.01.31 08:44:33.942 *D* [netsvc            ] NetworkServiceStatus_HTTP(https://X.X.X.X:443/api/status): call to curl_easy_perform failed
2023.01.31 08:44:33.943 *D* [comm.cs.170        ] Command processed by sub-agent NETSVC
2023.01.31 08:44:33.943 *D* [comm.cs.170        ] Sending message CMD_REQUEST_COMPLETED (ID 3; size 64; uncompressed)

Example debug log - custom (Telnet) TCP port check:

 ** 000000: [    8] INETADDR    X.X.X.X
 ** 000020: [  130] INT16      7
 ** 000028: [  132] INT16      23
 ** 000030: [  131] INT16      6
 ** 000060: [  134] UTF8-STRING ""Connected""

2023.01.31 08:44:30.488 *D* [comm.cs.158        ] Received message CMD_CHECK_NETWORK_SERVICE (3)
2023.01.31 08:44:30.518 *D* [comm.cs.158        ] Command processed by sub-agent NETSVC
2023.01.31 08:44:30.518 *D* [comm.cs.158        ] Sending message CMD_REQUEST_COMPLETED (ID 3; size 64; uncompressed)
2023.01.31 08:44:30.518 *D* [comm.cs.158        ] Outgoing message dump:
  ** 000000 | 00 1D 50 00 00 00 00 40 00 00 00 03 00 00 00 03 | ..P....@........
  ** 000010 | 00 00 00 1C 00 00 00 00 00 00 00 00 00 00 00 00 | ................
  ** 000020 | 00 00 00 88 00 00 00 00 00 00 00 02 00 00 00 00 | ................
  ** 000030 | 00 00 01 EB 00 00 00 00 00 00 00 1E 00 00 00 00 | ................
  ** code=0x001D (CMD_REQUEST_COMPLETED) version=5 flags=0x0000 id=3 size=64 numFields=3
  ** 000000: [    28] INT32      0
  ** 000010: [  136] INT32      2
  ** 000020: [  491] INT32      30

Thank you!

Victor Kirhenshtein

Hi!

I was unable to reproduce telnet service check issue. "[  136] INT32      2" in response indicates connection problem, so agent was unable to connect to given address and port. Could it be that address is a loopback?

For HTTPS checks - it could be certificate issue. Unfortunately agent do not log exact failure reason (I fixed it already in development branch). Try to do same request with curl from command line (using URL exactly as logged - https://x.x.x.x:443/api/status) - will you get any errors?

Best regards,
Victor

Victor Kirhenshtein

Quote from: 2b2bff on January 27, 2023, 11:38:36 AMThanks a lot.

Sadly the DB upgrade for MSSQL fails because event_cfg.description is a TEXT column and the upgrade script compares it with VARCHAR in the WHERE clause.
Simple fix - please change all TEXT columns to VARCHAR(MAX). TEXT has been deprecated long time ago...
https://learn.microsoft.com/en-us/sql/t-sql/data-types/ntext-text-and-image-transact-sql

Cheers
Upgrade procedure is fixed in development branch, fix will be part of upcoming patch release 4.3.1. In version 4.4 we will also switch to varchar(max) from text.

Best regards,
Victor


adrian69

Quote from: Victor Kirhenshtein on January 31, 2023, 06:03:16 PMHi!

I was unable to reproduce telnet service check issue. "[  136] INT32      2" in response indicates connection problem, so agent was unable to connect to given address and port. Could it be that address is a loopback?

For HTTPS checks - it could be certificate issue. Unfortunately agent do not log exact failure reason (I fixed it already in development branch). Try to do same request with curl from command line (using URL exactly as logged - https://x.x.x.x:443/api/status) - will you get any errors?

Best regards,
Victor

Thank you for your prompt response!
Regarding HTTPS check, the thing is netsvc does the check against the IP address, instead of the URL that i have in my request field, so naturally the SSL certificate check would fail. (e.g sending to https://$IP_ADDRESS:443/api/status instead of https://my.host/api/status). As about the telnet check it does say it sends it to the public ip address. ( ** 000000: [    8] INETADDR    $REMOTE_PUBLIC_IP_ADDR). Note that all of the tests were working fine with previous version 4.2 (portcheck). 

Victor Kirhenshtein

Correct, old subagent (portcheck) set host header and SNI separately. I just fixed netsvc in development branch so it use correct host name when called for network service object poll or via compatibility metrics, next patch release will contain fix.

Best regards,
Victor

richard21

We have had issues in 4.3 with using ConfigurableQuery after upgrading the agent the defined ConfigurableQuery wasn't available in the Tables selection having rolled the agent back to 4.2 the defined ConfigurableQuery is available in the table selection when creating a DCI

Victor Kirhenshtein

Yes, there is a bug in configuration parser introduced in 4.3.0. I just fixed it, fix will be included into release 4.3.1.

Best regards,
Victor