NetXMS Support Forum

I have created this:
https://github.com/eclipse-rap/org.eclipse.rap/issues/398

Has working code, minimal atomic changes, detailed explanations, etc.

I will develop & submit further and probably submit a PR in the very near future.

I am hoping NetXMS will use this to enable the content within panes in the UI to respond to touch nicely with Apple devices (especially the network topology diagram maps).

Nice project. I'm really glad I found NetXMS here on the other side of the pond.
:-)

Many thanks for the info Alex.

This Build still has the issue of being unable to log in if MFA is enabled will this be resolved in a future build

Thanks for the reply and information

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).

Test flight is still saying build removed is there a new link ?

is there the possibility of having Sub Zones the use case is you can have a zone per customer with sub zones for each of there sites this would allow for easy management of which subnets are for which site but should allow for full map generation across the sub zones

Замена 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.