NetXMS Support Forum

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 (или, как вариант - настроить туннели, чтоб агенты подключались к серверу)

Вот пример, что можно сделать:

trace(0, "Calculating link color for " . $endpoint1->name . " -> " . $endpoint2->name);

match1 = $endpoint1->name match ".*ASA-(.*)$";
match2 = $endpoint2->name match ".*ASA-(.*)$";

if (match1 and match2) {
key = "Dummy(ipsec-uptime-" . lower(match1[1]) . "-" . lower(match2[1]) . ")";
trace(0, "Searching for " . key . " on " . $endpoint1->name);
value = GetDCIValueByName($endpoint1, key);
if (not value) {
key = "Dummy(ipsec-uptime-" . lower(match2[1]) . "-" . lower(match1[1]) . ")";
trace(0, "Searching for " . key . " on " . $endpoint2->name);
value = GetDCIValueByName($endpoint2, key);
}

if (value != null) {
trace(0, "Got value " . value);
if (value > 0) {
return "green";
}
}
}

return "red";


Эти 20 линков будут на одной циске? Или линк будет между уникальными парами устройств?

EDIT: хотя полюбому, можно же сматчить линк по обеим нодам. Как еще один вариант - если имена нод похожие, то можно просто брать конец имени, и собирать название DCI (e.g. MSK-APR")

Это зависит уже от конкретных метрик. Скрипт может взять данные с любой ноды (как через $endpoint1/$endpoint2, так и через FindNodeObject(null, "server1")), дальше уже вопрос поиска нужного DCI на ноде.
Если DCI никак не определить из скрипта, можно прописать его ID в custom attribute на ноде и доставать таким образом - вариантов много, надо знать детальные требования, чтоб предложить оптимальный путь.

Самое простое решение - в настройках линка выбрать Color -> Script выбрать скрипт, который будет возвращать цвет на основе DCI (при помощи одной из GetDCIValue* функций - https://www.netxms.org/documentation/nxsl-latest/#func-getdcivalue).
Скрипт берется из Scripting Library и должен возвращать цвет - в виде строки или числа.
Строка - как в CSS, название цвета или любой из вариантов "#RRGGBB", "0xRRGGBB", "rgb(R, G, B)", где R, G и B - компоненты цвета красный-зеленый-синий. Список цветов можно посмотреть тут: https://github.com/netxms/netxms/blob/master/src/libnetxms/tools.cpp#L4292
Так же можно вернуть число, с цветом побайтно - 0xRRGGBB (например красный - 0xFF0000, эквивалентно 16711680).

Кроме обычных функций и глобальных переменных, в скрипте так же доступны две переменные "$endpoint1" и "$endpoint2", которые указывают на ноды линка.

Второй вариант - сделать ноду с IP=0.0.0.0, на ней сделать dummy DCI с флагом "Use this DCI for node status calculation" и скриптом, который будет возвращать статус 0-6 (normal, warning, minor, major, etc.)

На данный момент нет. В принципе штука полезная, сделаем.

Прямо сейчас можно сделать некотрое подобие на основе object tool  c скриптом:
1) сделать событие, что-то типа MAINTENANCE_RECORD
2) настроить object tool с текстовым input field, который запускает nxsl скрипт
3) из скрипта посылать событие MAINTENANCE_RECORD (https://www.netxms.org/documentation/nxsl-latest/#func-postevent), в параметры сложить текст из поля ввода

Просмотрел - в event log.

Добрый день.

Да, конечно, можете спокойно использовать. Лицензия - GPLv2, основное требование, которое потенциально может мешать коммерческому использованию - если вы вносите изменения в исходный код продукта (это не относится к вашей конфигурации / скриптам / etc.), то по запросу вы должны предоставить эти изменения кода.