NetXMS Support Forum

1. I've added support for long-living tokens in build 36. Optionally you can enable Face ID, if you want to. You need server 6.2.2. or newer for that to work properly.
2. What do you mean by network view?
3. Yes, since webapi itself is purely http-only, you need any kind of reverse proxy (reproxy, nginx, etc.), which will do SSL offloading.

Добрый день,

6.2.2 не требует TimescaleDB 2.26.3 — апгрейд вообще не привязан ни к какой конкретной версии расширения. Единственное требование во всей ветке 62.x — TimescaleDB не ниже 2.10, оно проверяется на более позднем шаге, где создаются continuous aggregates, и 2.27.2 его закрывает. Ошибка приходит не из NetXMS: PostgreSQL пытается загрузить библиотеку расширения timescaledb версии 2.26.3, потому что именно эта версия записана в каталоге базы, а на диске после обновления пакета осталась только 2.27.2. Пакет обновили, а расширение внутри базы — нет.

Почему упало именно здесь: ALTER TABLE object_tools ADD applicable_classes — первый DDL за весь апгрейд. Шаги с 61.36 до 62.1 только пишут строки в metadata и config, а на DDL PostgreSQL обязан загрузить код расширения, потому что timescaledb вешает на DDL свои event triggers. Сам шаг 62.1 → 62.2 к TimescaleDB отношения не имеет, object_tools — обычная таблица, не hypertable.

Сначала стоит убедиться, что картина именно такая:

psql -X -d netxms -c "SELECT extname, extversion FROM pg_extension WHERE extname='timescaledb'"
ls $(pg_config --pkglibdir)/timescaledb*

Если extversion показывает 2.26.3, а на диске лежит только timescaledb-2.27.2.so — причина в этом.

Порядок действий:

systemctl restart postgresql          # имя юнита зависит от сборки пакета
psql -X -d netxms                     # -X обязателен
ALTER EXTENSION timescaledb UPDATE;   # первой же командой в сессии
\dx timescaledb

Два момента, из-за которых это часто не проходит с первого раза: ALTER EXTENSION должен быть первой командой в сессии — после любого другого запроса библиотека старой версии уже пытается загрузиться, и апдейт падает с той же ошибкой (отсюда и -X, чтобы .psqlrc ничего не выполнил до этого). И выполнить его нужно в каждой базе, где установлено расширение, а не только в базе NetXMS.

Если ALTER EXTENSION всё же падает с той же ошибкой — поставить обратно пакет с 2.26.3, выполнить ALTER EXTENSION timescaledb UPDATE при живой старой библиотеке, затем снова обновить пакет до 2.27.2.

После этого повторить nxdbmgr upgrade. По состоянию базы: каждый шаг апгрейда выполняется в отдельной транзакции, DDL в PostgreSQL транзакционный, поэтому откат снял шаг 62.2 целиком — недоприменённых изменений не осталось, база консистентна и стоит на схеме 62.1. Повторный запуск безопасен, но dump перед ним сделать стоит.

Важное следствие: схема уже 62.1, а сервер требует точного совпадения версии схемы, поэтому сейчас не стартует ни 6.2.2 (ждёт 62.35), ни 6.1.2 (ждёт 61.36) — в логе будет "Your database has format version ...". Путь только вперёд, откат назад — это восстановление из бэкапа.

На то, что nxdbmgr показывает это состояние ошибкой, по которой причину не видно, завёл тикет: https://github.com/netxms/netxms/issues/3540. И отдельно на документацию, https://github.com/netxms/netxms-doc/issues/65 — в разделе про апгрейд про обновление расширения не сказано ничего.

И раз апгрейд всё равно не завершён: сегодня вышла 6.2.3, https://www.netxms.org/forum/announcements/netxms-6-2-patch-release-3/ — имеет смысл ставить сразу её. На эту ошибку она не влияет, шаг 62.1 → 62.2 в ней тот же самый, добавлены только шаги после него (схема 62.38 вместо 62.35).

Если extversion в базе окажется уже 2.27.2 — тогда картина другая, покажите вывод запроса и полный вывод nxdbmgr upgrade.

Нет, скрипт на правиле 31 ничего не изменит — правило 31 в этот раз вообще не срабатывало. Уведомления пришли от правила 32.

В логе уведомлений сервера это видно напрямую: строки 459–463 за 19:01:33–19:01:39, событие SYS_NODE_UP, Rule ID e8f2ab80-3472-4631-a7a6-e501149eb086, описание правила "Terminate mail alarms when node connected by tunnel / proxy node is up in 300 sec" — это правило 32. Пять уведомлений, все "Node up", ни одного "down".

Режим обслуживания ничего не подавляет на этапе генерации событий. События создаются, пишутся в event log и попадают в EPP как обычно; единственное, что делает maintenance — проставляет каждому событию объекта Root ID, равный ID события входа в обслуживание. Дальше решает флаг "Accept correlated events" на правилах.

В вашем логе событий: SYS_MAINTENANCE_MODE_ENTERED в 18:38:27 с Root ID = 0, а всё последующее — SYS_TUNNEL_CLOSED 18:58:20, SYS_AGENT_UNREACHABLE и SYS_NODE_UNREACHABLE 19:00:23, SYS_TUNNEL_OPEN 19:00:45, SYS_NODE_UP и SYS_AGENT_OK 19:01:33 — с Root ID = 11094369. Все коррелированные.

Отсюда цепочка:

• SYS_NODE_UNREACHABLE коррелированное, у правила 31 флаг выключен — правило его пропустило. Ни аларм, ни таймер NODE_BY_TUNNEL_DOWN_%n_%i не создались.
• SYS_NODE_UP тоже коррелированное, но у правила 32 флаг включён — правило сработало.
• У действия Normal MailAlarm в правиле 32 стоит блокировка "Do not run if timer NODE_BY_TUNNEL_DOWN_%n_%i is active". Таймера нет, потому что его никто не создавал — блокировка не сработала, письмо ушло.

Что сделать: выключить "Accept correlated events" на правилах 32 и 34. Скрипт с проверкой maintenance добавлять никуда не нужно — он дал бы тот же результат, но флаг проще.

Здесь нужно поправить то, что я писал 21.07. Флаг на up-правилах рекомендовался ради сценария "нода упала (таймеры заведены) → её перевели в обслуживание → она поднялась в обслуживании → аларм не закрылся, и через 8 часов пришло письмо". Этот сценарий сервер закрывает сам: при выходе из обслуживания состояние ноды восстанавливается на то, каким оно было до входа, и если оно разошлось с фактическим — принудительно запускается status poll. В этом сценарии состояния разойдутся, поллинг отработает и сгенерируется новое, уже некоррелированное SYS_NODE_UP: правило 32 на нём сработает, аларм закроется, таймеры снимутся. Флаг для этого не нужен, а его единственный реальный эффект — ровно то, что вы получили 06.08.

Два соседних случая, чтобы было понятно, чего ждать после выключения флага:

• Нода и упала, и поднялась внутри окна обслуживания (ваш случай 06.08). Состояние на выходе совпадает с исходным, поллинг не форсируется, после выхода из обслуживания ничего не приходит. Аларма и таймеров при этом не создавалось — закрывать нечего.
• Нода упала в обслуживании и осталась лежать. Состояния разойдутся, форсированный поллинг отработает, и SYS_NODE_UNREACHABLE придёт уже некоррелированным — реальную аварию за окном обслуживания вы не потеряете.

Вне обслуживания SYS_NODE_UP не коррелируется никогда, поэтому на обычную работу правил 32/34 выключенный флаг не влияет.

Правила 31 и 33 трогать не нужно. У 31 флаг выключен, у 33 включён вместе со скриптом проверки maintenance — оба во время обслуживания молчат.

Note: одна дырка остаётся. Отложенные действия, заведённые до входа в обслуживание, во время обслуживания не отменяются и не проверяют maintenance при срабатывании — их снимет только SYS_NODE_UP после выхода. У вас Critical MailAlarm стоит с задержкой 5 минут, поэтому сценарий "нода упала, её в течение 5 минут перевели в обслуживание, и там же она поднялась" всё равно даст письмо о недоступности. Задержки 8h/1d/3d сработают только если окно обслуживания окажется длиннее них.

Отдельно: в моём ответе от 28.07 было сказано, что асимметрия между правилами 31 и 32 проявится только если в группу добавить ноду за маршрутизатором или коммутатором, и что для нод без primary IP этого не случится. Это неверно — режим обслуживания коррелирует все события объекта независимо от primary IP и от топологии, поэтому асимметрия проявляется в любое окно обслуживания. Ровно это 06.08 и произошло.

То, что maintenance подавляет события через корреляцию, а не отдельным механизмом, в трекере уже разбиралось: https://github.com/netxms/netxms/issues/2571 — закрыто как expected behavior, с тем же обходным путём через скрипт. В документации раздел про maintenance mode при этом сформулирован неверно: там сказано, что события не генерируются, тогда как они генерируются и коррелируются. Завёл тикет: https://github.com/netxms/netxms-doc/issues/63

Hi,

setCustomAttribute is not broken, it is blocked on purpose. 6.2 added a server configuration parameter Scripts.RestrictWriteAccess, enabled by default on both new installations and in-place upgrades. With it enabled, transformation, threshold, filter and other "analysis" scripts run under a read-only security context and cannot modify objects.

Here's what's actually happening: the call is not rejected with a script error. setCustomAttribute just returns false and does nothing, so the script keeps running and returns its value as usual - that is why it looks like the function silently stopped working. Reading is not affected, getCustomAttribute in the same script still works. The integer value in your example is fine, numbers are accepted.

The restriction covers transformation scripts for both single-value and table DCIs, threshold scripts, script-type DCIs, macro expansion in DCI and object text, autobind filters, conditions, business service checks and prototype instance discovery, EPP filter and RCA scripts, asset property autofill, network map filter and link styling scripts, and SNMP trap transformation.

Simplest approach is to turn it off: Server Configuration -> Scripts.RestrictWriteAccess -> 0. It takes effect immediately, no server restart needed. Note that it is a global switch - it re-enables writes for every script type listed above, not just for your DCI.

If you prefer to keep the restriction on, move the write out of the transformation script. Server actions of type "execute server-side script" and poll hook scripts are not restricted, so a script invoked from an EPP rule can still set custom attributes.

To confirm this is what you are hitting, enable debug tag nxsl.security at level 7 - every blocked call logs "Read-only script access denied" with the object name and id.

2fa added in build 34

Hi,

Thank you for the effort. I'm not sure you'll be able to push it (judging by other pending issues in RCP/RAP), but there is good news as well - we'll migrate away from RAP in the near future. The new web is built from scratch and not Java-based. It currently exists as an internal beta.

Hi,

Sub zones aren't planned, and in practice you don't need them - a zone already carries its own ACL, so one zone per customer is your tenant boundary. Everything below it inherits those rights, so a user granted access to that zone sees that customer's subnets and nodes and nothing else.

What a zone isn't is a grouping level. It's an address space: it exists so two customers can both use 10.0.0.0/8 without colliding, and it carries the proxy set through which everything inside it is reached. Every node, interface and subnet stores a single zone UIN, not a path, so there is nowhere for a hierarchy to live. Nesting wouldn't mean anything either - an address is either unique within a space or it isn't.

So the two halves of what you're describing are handled separately.

Address space separation. One zone per customer is correct as long as that customer's own sites don't reuse addresses between themselves. If they do - every site running 192.168.1.0/24 - then you need a zone per site instead. Zones are flat, but nothing limits how many you create, and each one gets its own ACL.

Site organisation. That belongs in the Infrastructure Services tree: a container per customer, a container per site inside it, nodes placed by an auto-bind NXSL filter (by address range, sysLocation, custom attribute - whatever identifies the site). Use Collector instead of Container at the site level if you also want site-level data collection - it's a container that is itself a data collection target, so you can put aggregate DCIs and thresholds on it.

Important detail if you build that tree: access rights are OR-ed across all parents of an object. A node inside a customer zone that also sits in a shared container becomes visible to anyone who can read that container, zone ACL notwithstanding. Keep the customer's container subtree access-restricted the same way the zone is.

Note: auto-bind handles nodes always, and access points, clusters, collectors, mobile devices and sensors only when the matching Objects.<Class>.ContainerAutoBind server config is enabled - all of those are off by default. It never picks up Subnet objects. Subnets can be bound into a container, and binding is additive so the subnet stays in its zone tree as well, but you would do it by hand or from a scheduled NXSL script calling BindObject() on subnets by address range.

Maps already work across zones. Map content isn't zone-scoped anywhere. A map takes a list of seed objects, and a seed can be a container or collector - in that case every node underneath it becomes a seed. So one map per customer, seeded with that customer's container, covers all their sites no matter how many zones they are spread over. A zone itself is not a valid seed, so seed with containers or nodes.

Two details on how links get built on such a map. IP topology expansion from a single seed stays inside that seed's zone, because it walks the parent subnet tree and subnets are per-zone by definition. On L2, only LLDP resolves the neighbour globally (by LLDP node id, then MAC, then sysName) - CDP, NDP and OSPF look up the IP the neighbour reported inside the local node's zone. Neither is normally a problem, since two directly connected devices sit in the same zone anyway, and the map still spans zones through its other seeds and through VPN connectors.

Check now, build 33 should be accessible (https://testflight.apple.com/join/B677yBU2).

Замена contains на like проблему не решила — оба регистрозависимы. В текущем виде фильтр не сработает ни на одной записи с кириллицей, а ASCII-записи ("7-zip", "adobe reader") это маскируют.

Проверено на nxscript 6.2.0:

s = "Средства Проверки Microsoft Edge";

s like "*Средства Проверки*"     // true  - регистр совпадает
s like "*средства проверки*"     // false - регистр не совпадает
s.contains("Средства Проверки")  // true
s ilike "*средства проверки*"    // true  - ilike регистронезависим
Регистронезависимый оператор — ilike, а не like. Среди методов строки аналога contains без учёта регистра нет, equalsIgnoreCase сравнивает строку целиком.

Почему исходный вариант с contains выглядел нерабочим: по приложенному логу toLowerCase на вашем сервере отработал корректно — "агент администрирования kaspersky security center". Значит и contains работал, а пакеты из трейса (Kaspersky Security Center, Microsoft Edge) просто не входили в список из 60 записей, и правило отфильтровало их правильно. Исходный скрипт был в порядке.

Деталь, которая здесь важнее: toLowerCase, toUpperCase, ilike и equalsIgnoreCase для не-ASCII зависят от локали процесса. LC_CTYPE подхватывается только если он есть в окружении, а systemd-юнит его не задаёт — при запуске из пакета netxmsd может работать в локали C. Тогда toLowerCase молча оставляет кириллицу без изменений, а ilike и equalsIgnoreCase на кириллице возвращают false, без записи в лог. Тикет на это: https://github.com/netxms/netxms/issues/3483

Проверка:

println("Средства".toLowerCase());   // ожидается "средства"
Если вывод пустой или регистр не изменился, локали нет — задаётся через LANG=C.UTF-8 в /etc/default/netxmsd.

Для списка из 60 наименований надёжнее не приводить регистр вручную: либо сравнивать через ilike при рабочей локали, либо сопоставлять точным регистром через contains — второй вариант от локали не зависит вообще. Вариант с Mapping tables, предложенный выше, здесь удобнее обоих: список правится в Configuration без редактирования скрипта, GetMappingTableKeys() отдаёт его массивом.

You are right, and the documentation is what failed you here. vmgr reaches hypervisors only through libvirt, so a Proxmox host is out of scope regardless of configuration — PVE does not use libvirt, and Proxmox advise against installing it on a node, so nothing ever answers on qemu:///system. Filed as https://github.com/netxms/netxms-doc/issues/59 so the hypervisor monitoring page says this instead of leaving it to be found in the agent log.

The PVE REST API is the route that works today, with no new code needed. Create a web service definition against

https://pve01:8006/api2/json/cluster/resources?type=vm
That returns every VM and LXC container in the cluster in one response, each with status, cpu, mem, maxmem, disk and maxdisk, so a single definition plus instance discovery over vmid covers all guests. For the host itself use /nodes/{node}/status, and /nodes/{node}/rrddata if you want the same series the GUI graphs draw from.

One non-obvious detail on authentication: do not use the Bearer authentication type. It sends Authorization: Bearer <token>, and Proxmox uses its own scheme. Set authentication to None and add the header explicitly instead:

Authorization: PVEAPIToken=monitoring@pve!netxms=<uuid>
Create the token under Datacenter - Permissions - API Tokens and give it a read-only role; PVEAuditor is enough.

There is a second route worth knowing about that does not work yet. PVE 9 can push metrics on its own — Datacenter - Metric Server - OpenTelemetry, sent by pvestatd every 10 seconds — and NetXMS has had OTLP metric ingestion since 6.1. The two do not meet at the moment: PVE sends OTLP encoded as JSON, our receiver accepts protobuf only. Filed as https://github.com/netxms/netxms/issues/3482. An OpenTelemetry Collector in between will transcode it if you want that shape now, but for the same data the REST API above is far less machinery.

On the Xen subagent you spotted: it exists, but it is built on Xen's own libxl, so it is no help for Proxmox either.

Filed as https://github.com/netxms/netxms/issues/3480 for design discussion.

Option 3 is the right shape, but one thing needs settling before you build on it: user custom attributes will not work as a backing store for ordinary users. CMD_UPDATE_USER is handled by ClientSession::updateUser() and requires SYSTEM_ACCESS_MANAGE_USERS, with no exemption for modifying your own account — password change and 2FA binding both special-case userId == m_userId, custom attributes do not. A non-admin operator saving their own date format gets access denied.

So the per-user store needs a server-side change either way: a self-update path restricted to own custom attributes, or a separate per-user key/value store with its own command and access check. That choice determines the client API, so it should come before more work on the merge logic.

Beyond that, option 3 needs an explicit rule for which preferences are machine-local and which are per-user. Without one, every preference added later is a judgement call and the split rots — your HTTP_* and window geometry cases are exactly what such a rule has to answer.

Your points 3 and 4 are a separate problem, worth splitting off: the RWT store sits in the servlet container state directory, so it is lost on container restart and on .war update. Persisting that directory, or moving the store out of it, fixes preference loss in the web client on its own, with none of the per-user work — and it covers theme files, map tile cache and MIB downloads at the same time.

Тикет закрыт, метрики доступны с 6.1.2: SmartAttrRaw, SmartAttrRawString, SmartAttrWorst, SmartAttrThreshold. Подробности в соседней теме: https://www.netxms.org/forum/oe-oo/parametr-physicaldisk-smartattr/

По исходному вопросу темы — error или пустое значение у PhysicalDisk.* при том, что smartctl из шелла работает — это отдельная проблема, обновлением не решается. Агент выполняет:

smartctl --all -j <device>
и отбрасывает результат, если вывод не разбирается как JSON или в нём отсутствует секция device. Типичные причины: smartctl отсутствует в PATH сервиса либо устройство недоступно с правами, под которыми запущен nxagentd. Причина фиксируется в логе агента при

DebugTags=smartctl:6
— в лог попадают команда, messages от smartctl и конкретный отказ: invalid device name, failed to execute, timed out, error parsing JSON, device section missing.

Note: PhysicalDisk.Devices использует smartctl --scan, поэтому пустая таблица — тот же симптом, а не отдельная проблема.

Реализовано в 6.1.2. Нужная метрика:

PhysicalDisk.SmartAttrRaw(/dev/pd1, Current_Pending_Sector)
По тикету https://github.com/netxms/netxms/issues/3199 добавлены четыре метрики с тем же набором аргументов, что у SmartAttr: SmartAttrRaw (raw/value), SmartAttrRawString (raw/string, для составных raw вида "8 177 10"), SmartAttrWorst (worst), SmartAttrThreshold (thresh).

SmartAttr не изменялся и возвращает нормализованное value — это и есть 200. Нормализованное значение вычисляется по формуле производителя, у Current_Pending_Sector база 200, и оно остаётся неизменным, пока атрибут не приблизится к threshold. Для трендов и thresholds следует использовать SmartAttrRaw.

Note: worst, thresh и raw присутствуют только в секции ata_smart_attributes, то есть для ATA/SATA. В выводе smartctl для NVMe этих полей нет — доступен только SmartAttr с именами полей из nvme_smart_health_information_log.

Указание атрибута по числовому SMART ID (197 вместо Current_Pending_Sector) доступно начиная с 6.2.0, в 6.1.x работает только имя.

Hi,

Yes, it's on the roadmap, but it might end up in the enterprise build -- we are not sure yet.

Да, SYS_NODE_UNREACHABLE в правило 31 нужно вернуть. Моё замечание от 23.07 было неверным: у нод, подключённых через тоннель, приходит именно SYS_NODE_UNREACHABLE, а не SYS_NODE_DOWN. После того как вы убрали это событие из правила 31, срабатывать ему стало не на чем.

Выбор события определяет не тоннель сам по себе, а наличие у ноды primary IP address:

• Нода без primary IP (связь только через тоннель агента). Проверка «весь узел недоступен» для неё при отвалившемся агенте не выполняется вообще. Вместо этого сервер отдельно смотрит, остался ли тоннель, и если тоннеля нет — публикует SYS_NODE_UNREACHABLE с параметром reason = "Agent tunnel disconnected". SYS_NODE_DOWN для такой ноды не возникает никогда.
• Нода с primary IP — обычная логика: SYS_NODE_DOWN, если причина в самой ноде, и SYS_NODE_UNREACHABLE с reason "Router down" / "Switch down" / "Proxy node down", если сервер нашёл причину выше по пути.

Восстановление в обоих случаях — SYS_NODE_UP. Отсюда и картина: up-уведомления приходили, down — нет.

В ваших логах это видно напрямую:

• ТРК сервер офис, 26.07: 17:25:05 SYS_AGENT_UNREACHABLE, 17:25:49 SYS_TUNNEL_CLOSED, 17:26:37 SYS_NODE_UNREACHABLE, 18:27:15 SYS_NODE_UP. SYS_NODE_DOWN нет ни одного.
• Смарт сервер 1С, 27.07 03:31:58 — ровно то же самое, и 25.07 09:39:34 тоже. Так что ночное одинокое «Node up» — не отдельная аномалия, а тот же самый случай.

Что сделать: добавить SYS_NODE_UNREACHABLE в правило 31, рядом с SYS_NODE_DOWN. Больше ничего менять не нужно. Флаг "Accept correlated events" и скрипт с maintenance на правиле 31 по-прежнему не нужны: SYS_NODE_UNREACHABLE с reason "Agent tunnel disconnected" не коррелируется (у этих событий в вашем логе Root ID = 0), а в режиме обслуживания события станут коррелированными и правило пропустит их само.

Перечислять оба события в правилах «нода недоступна» стоит всегда — стандартное правило Start downtime устроено именно так, в нём указаны и SYS_NODE_DOWN, и SYS_NODE_UNREACHABLE. Документация тоже говорит, что генерируется одно из двух, в зависимости от причины: https://netxms.org/documentation/adminguide/topology.html

Проверить, какая ветка сработала у вас: откройте SYS_NODE_UNREACHABLE в event log и посмотрите параметр reason. "Agent tunnel disconnected" — нода без primary IP, событие некоррелированное. Любой другой reason означает, что сервер нашёл причину выше по пути; из них коррелируются "Router down", "Switch down", "Proxy node down" и "Proxy agent unreachable" — эти правило 31 без флага пропустит.

Note: асимметрия между правилами 31 и 32 из-за этого остаётся. У 32 флаг включён, у 31 — нет, поэтому коррелированное событие недоступности правило 31 пропустит, а «Node up» при восстановлении придёт всё равно. Для нод без primary IP этого не случится, но если позже добавите в группу ноду за маршрутизатором или коммутатором — одинокое «Node up» вернётся.