NetXMS Support Forum

Hello, dear NetXMSers!

It's that moment when we ask something from you. Please, tell more people just about how powerful and flexible NetXMS system is and leave your review (big or small — anything counts) on Trustpilot and G2.

We hope it's not much and we also hope you can do it with pleasure, as NetXMS really deserves it!
>>> Stay cool and thank you so much in advance.

Sincerely,
Team NetXMS

try node #2277 (you can search by node id in object browser)

Latest (also a bit outdated) is here: https://www.netxms.org/documentation/datadictionary/ (https://www.netxms.org/documentation/datadictionary/netxms-data-dictionary.pdf)

On start agent reports list of protocols supported by libcurl (on debug level 3, I think):

2022.04.21 11:52:37.320 *D* [init.curl          ] cURL supported protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp

Check that you have pop3 available in this list.

nxmc is the webui package, you need this one instead

Check output of "apt-key list", most likely you have old key imported into another keystore.

Quote from: normalcy on April 06, 2022, 02:50:09 PM
Hi, I tried updating using the package, and using the netxms-keyring.gpg however I found I still got the old version expiring on the 24/3 with those.

As some of you already noticed – our signing key for deb repository is expired.
Normally we update the key and ship updated version of the netxms-release package, which transparently install correct version into trusted keys. This time we missed it and now most of you have expired key, which prevent further upgrades.

Error looks something like this:
...
Err:4 http://packages.netxms.org/debian bullseye InRelease
  The following signatures were invalid: EXPKEYSIG 179C0A80CDFADDB1 NetXMS Automatic Signing Key <[email protected]>
Reading package lists... Done
W: GPG error: http://packages.netxms.org/debian bullseye InRelease: The following signatures were invalid: EXPKEYSIG 179C0A80CDFADDB1 NetXMS Automatic Signing Key <[email protected]>
E: The repository 'http://packages.netxms.org/debian bullseye InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.


How to fix it:

1) If source and key was added by "netxms-release" package (recommended way), it's simple:


curl --proto '=https' --tlsv1.2 -O https://packages.netxms.org/netxms-release_1.10_all.deb
dpkg -i netxms-release_1.10_all.deb
apt update


2) If key was manually added to trusted.gpg.d


curl --proto '=https' --tlsv1.2 -o /etc/apt/trusted.gpg.d/netxms-keyring.gpg https://packages.netxms.org/netxms-keyring.gpg # adjust file location
apt update


I highly recommend you to migrate to netxms-release package.

3) If key was added with "apt-key add" command

apt-key del 179C0A80CDFADDB11 # repease until apt-key list shows no key
curl --proto '=https' --tlsv1.2 -sSf https://packages.netxms.org/netxms.gpg | apt-key add -


Again, I highly recommend you to migrate to netxms-release package.

Hello.

Yes, it in the works.

Jython is used by nxshell.

However, the only mentions of log4j I've found in the jython is adapters to different logging frameworks (in org.python.netty.util.internal.logging), not the log4j runtime itself.

Quote from: lweidig on December 15, 2021, 03:42:23 PM
A recent scan of our NetXMS VM shows the following:

Code Select Expand

[WARNING] /usr/lib/x86_64-linux-gnu/netxms/java/jython-standalone-2.7.2.jar contains log4j files

Curious where this is all used and what the solution might be if this is an issue.  We are running the latest version of NetXMS and also do run the web console.  Thanks!

You can verify yourself, that there are no JndiLookup (which is affected piece of log4j2):


~
❯ unzip -t ~/.m2/repository/org/python/jython-standalone/2.7.2/jython-standalone-2.7.2.jar | grep JndiLookup
~
❯ echo $status
1
~
❯


Hello.

These metrics are provided by the netxmsd itself, and they are from the template System/NetXMS Server/Thread pools.
Template is applied based on the $node->isLocalManagement flag, which is always set by the monitoring server.

So the only possible cause for this I can imagine is that this node was server's node for some time, then server was started on different node (e.g. high availability setup with active/passive nodes).
Template is removed on the configuration poll, so it will remain active for a while - hence the alarms (which should be automatically terminated, if I recall correctly).

Check following:

1) is this node your active netxms server?
2) does it have isLocalManagement flag set? (right click on the node -> Execute server script -> "println($node->isLocalManagement);")
3) what happens with these metrics if you force configuration poll on this node?

Hello.

NetXMS does not use log4j (neither jetty9).

Test, which shows that on the clean system there are no log4j jars:

❯ docker run --rm -it debian:11 bash
root@f7dddcf8abfe:/# apt-get update
...
root@f7dddcf8abfe:/# apt-get install -y curl
...
root@f7dddcf8abfe:/# curl https://packages.netxms.org/install | sh
...
root@f7dddcf8abfe:/# apt-get install -fy
...
root@f7dddcf8abfe:/# apt-get update
...
root@f7dddcf8abfe:/# apt-get install -y netxms-\* jetty9
...
root@f7dddcf8abfe:/# find / -name \*log4j\*
/usr/share/jetty9/modules/logging-log4j.mod
/usr/share/jetty9/modules/logging-log4j2.mod
/usr/share/jetty9/modules/log4j2-impl.mod
/usr/share/jetty9/modules/log4j-impl
/usr/share/jetty9/modules/log4j-impl/resources/log4j.xml
/usr/share/jetty9/modules/slf4j-log4j2.mod
/usr/share/jetty9/modules/log4j2-api.mod
/usr/share/jetty9/modules/log4j2-slf4j.mod
/usr/share/jetty9/modules/log4j2-impl
/usr/share/jetty9/modules/log4j2-impl/resources/log4j2.xml
/usr/share/jetty9/modules/log4j-impl.mod
/usr/share/jetty9/modules/slf4j-log4j.mod
root@f7dddcf8abfe:/#


So it's not that easy after all. Ubuntu changed compression inside deb files to zst, which is not (yet?) supported by Debian tools (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892664). As a result I can't publish using existing tools (we run Debian for that). I will take another look at the problem later.

DEBs temporary available here: https://netxms.org/tmp/impish/

They are currently not packaged. I'll add them to CI build.

Hello.

First of all, thank you for your guide!

I have some suggestions which might be useful:

Pre-requisites:
- Java8 still works, but I highly recommend to use JRE11 or newer.
- Maven is required only for the development process, you don't need it for the deployment

NetXMS Reporting Concepts:

report template (.jar file) is just a zip archive with the following structure:
├── META-INF
│   ├── MANIFEST.MF
├── i18n.properties
└── main.jrxml

where "main.jrxml" is report entry point, you can add additional files (e.g. subreports or images) to the archive and reference them via $P{SUBREPORT_DIR}.

For example:
<subreport>
  <subreportExpression><![CDATA[$P{SUBREPORT_DIR} + "sub_report.jasper"]]></subreportExpression>
  ...


i18n.properties is a translation file for the report parameters, for example:

jrxml:
<parameter name="PERIOD_START" class="java.lang.Long">
      <property name="logicalType" value="START_DATE"/>
      <parameterDescription><![CDATA[Start of the Period]]></parameterDescription>
      <defaultValueExpression><![CDATA[1489356000L]]></defaultValueExpression>
   </parameter>


properties:
PERIOD_START = Start of the Period

META-INF/MANIFEST.MF contains 1 important attribute - "Build-Id" (GUID). This attribute is used to distinguish between deployed reports, so each deployed report should have unique ID (but report updates, usually have the same ID as previous version - this way you'll have all you history intact). Name might be misleading, now I'd call that report-id or something similar - but historical reasons.


Install Procedure:

You don't need to reboot server, just run "systemctl start nxreportd" or in previous stem run "systemctl enable --now nxreportd", this should be enough


Creating and Installing report templates:

Instead of using using groovy in pom.xml to generate random Build-Id on every invocation, I suggest to use static field and just update it if you are creating new report.
This was you'll have report history even if you have updated report definition. Sample: https://github.com/netxms/sample-report/blob/main/pom.xml

Source files (images, subreports, etc.) should be in src/main/resources or maven will not pick them up.


When (re)deploying report, you don't need to restart netxmsd, nxreportd will be sufficient.

Ноды автоматически не удаляются.
При смене адреса можно руками поменять на ноде communication IP (или, как вариант - настроить туннели, чтоб агенты подключались к серверу)