NetXMS Support Forum

Thank you for pointing me in the right direction, I had not created the webhook correctly.

Hi,

Not fixed - I've reopened https://github.com/netxms/netxms/issues/3137. It was closed against a different fix (#3240) that only covered part of the problem.

Your combination is not the version mismatch Filipp mentioned - agent 6.2.3 and server 6.2.2 both contain everything from that work, so the "server must also be 6.2" note does not apply to you.

What is left: the agent can still change the reported user name, and sometimes the display name, for the same Store package between two polls, without signalling that the data is incomplete. Since 6.1 the server treats package name plus user as the package identity, so any such change comes out as a remove plus an install. Most likely triggers are a user profile whose registry hive is not on disk while the user is logged off (roaming profiles, FSLogix, UPD), and a failed SID-to-username lookup.

To tell which one you are hitting, please post:

• nxagentd log with debug level 6 for tag "winnt", covering a full logon and logoff
• System.InstalledProducts table taken twice - once with a user logged on, once without
• whether these are RDS/terminal servers, and whether profiles are roaming, FSLogix or UPD

Workaround is poor. There is no way to exclude Store packages from the inventory, and the inventory is collected on every configuration poll. Since 6.1 SYS_PACKAGE_INSTALLED and SYS_PACKAGE_REMOVED carry the user name as an event parameter, but filtering on it only removes half of each pair - the other half is reported as a system-wide package with empty user.

Hi,

"Driver Error" is as generic as it looks - it only means the driver loaded, your config parsed, and the POST to the webhook came back with something other than HTTP 200 and a body of exactly "ok". A transport failure, a non-200 code and an error string from Slack all end up as that same message. (If the driver itself were missing or unloadable you'd get "Driver not initialized" instead, so that part is fine.)

To get the actual error, in Tools -> Server Debug Console:

debug ncd.slack 7
debug nc 7

then send again and look in the server log (path is set by LogFile in netxmsd.conf, /var/log/netxmsd by default). It will be one of:

• Call to curl_easy_perform() failed - transport level: DNS, TLS, firewall. Note the Slack driver has no proxy option, so if this server reaches the internet through a proxy, that alone will stop it.
• Error response from webhook: HTTP response code is N
• Error response from webhook: <text> - Slack's own error, e.g. channel_not_found or invalid_payload.

Two things worth checking before you do that:

• url must be a classic incoming webhook - https://hooks.slack.com/services/T.../B.../... - which replies with the literal string "ok". A Workflow Builder trigger URL (https://hooks.slack.com/triggers/...) replies with JSON instead, and the driver will report Driver Error even though Slack accepted the message. This is the easiest one to get wrong right now, since Slack pushes you towards Workflow Builder.
• Recipient is mandatory for this driver and goes out as the Slack channel override. If it names a channel that doesn't exist you get channel_not_found back.

Your post shows url= with nothing after it - assuming that's just removed for the forum, but worth confirming the value actually saved.

Hi,

Not your script - 6.2 added a server configuration parameter Scripts.RestrictWriteAccess, enabled by default on new installations and on in-place upgrades. With it on, script-origin DCIs run under a read-only security context, and executeAgentCommandWithOutput() is one of the denied operations: https://netxms.org/documentation/adminguide/scripting.html#script-write-access-restrictions

Here's what's actually happening: the denied call does not raise an error. It returns null, the script keeps running, and it dies one line later where res.length hits that null - which is why the error points at line 8 and says "argument is not an object" instead of naming the restriction. In the Script Executor the same script runs under your user's rights, which include the control permission, so it works there and only there.

To confirm, enable debug tag nxsl.security at level 7 - the denial logs "Read-only script access denied" with the object name and id. Nothing appears at default levels.

Two ways out:

• Turn the restriction off: Server Configuration -> Scripts.RestrictWriteAccess -> 0. Takes effect immediately, no restart. It's a global switch though - it re-enables writes for every restricted script type, not just your DCI.
• Move the ping to the agent. Better fit here, since you're collecting a value rather than modifying anything. In nxagentd.conf, pointing at the same commands your ping-suli / ping-voda actions run:

ExternalMetric = PingSuli(*):["/path/to/ping-suli", "$1"]
ExternalMetric = PingVoda(*):["/path/to/ping-voda", "$1"]
Then two Agent-origin DCIs with metrics PingSuli(1.1.1.1) and PingVoda(1.1.1.1). No NXSL, so the restriction doesn't apply - and the if ($2) switch disappears, since you had two DCIs anyway.

I've opened https://github.com/netxms/netxms/issues/3619 on whether script-origin DCIs should be restricted at all - they're a data source, not an analysis script - and https://github.com/netxms/netxms/issues/3620 on the denial being invisible and surfacing as an unrelated error.

Your fresh install working is the useful data point - this is something about that specific server, not the pinboard code.

Here's what's actually happening: all web UI settings live in a single properties file on the machine running the web UI, under the servlet container's work directory, named nxmc.preferences.<uuid>. The uuid comes from a cookie called nxmcStoreId in your browser. If that cookie doesn't come back on the next login, the web UI generates a new uuid and opens an empty file - and the old one stays on disk with all your settings still in it. Pinboard, the "Show server clock" checkbox and column widths all live in that one file, which is why they go together.

Three things to check, and they split the problem cleanly:

• How many contexts are deployed. Look at /var/lib/tomcat10/work/Catalina/localhost/ - if more than one nxmc context is there (nxmc and nxmc-6.2.4, say), each has its own state directory, and the files you find may belong to a context you are no longer using. The web UI logs a line "State directory:" at every startup naming the one actually in use.
• Whether a new file appears per login. List the state directory, log in again, list it again. A new nxmc.preferences.<uuid> each time means the cookie is not coming back. The same file with a new timestamp means it is, and the problem is elsewhere.
• The cookie itself. Browser dev tools, Application - Cookies, look for nxmcStoreId. It is set with a 90 day lifetime, so it should survive a logout. If your nginx config caches or strips Set-Cookie on the proxied responses, it won't.

If you already have a file there containing pinboard$<number> entries, that settles most of it on its own: saving works, and the session that comes up empty is reading a different file.

The web UI log goes to catalina.out on a Tomcat install - grep it for "State directory", "local preferences" and "Invalid store ID". (-Dnxmc.logfile is only set in our Jetty instructions, so on Tomcat everything lands in the console log.)

Note: even once this works, that directory is Tomcat's per-context work directory and it is cleared on war redeploy. So web UI settings are lost on every web UI upgrade by design - that is likely part of what you saw across the three version upgrades.

I recently upgraded our NetXMS server (and agent) listed below:
netxms-agent:amd64 (6.0.1-1+bookworm, 6.2.3-1+bookworm)
netxms-server:amd64 (6.0.1-1+bookworm, 6.2.3-1+bookworm)
and later (due to this issue)
netxms-agent:amd64 (6.2.3-1+bookworm, 6.2.4-1+bookworm)
netxms-server:amd64 (6.2.3-1+bookworm, 6.2.4-1+bookworm).

I had two similar DCIs like this: origin: script, metric: Ping("1.1.1.1",1)

And the following script behind:

if ($2) {
cmd = "ping-suli";
} else {
cmd = "ping-voda";
}
println("Using: " .. cmd);
res = $node.executeAgentCommandWithOutput(cmd, $1);
if (res.length == 0) return null;
return res;
Both DCIs error with the following: Script (Ping) execution error: Error 14 in line 8: Function or operation argument is not an object

But if I use the execute script function with params: "1.1.1.1",1 to run the ping on the same node I get the expected result:

Using: ping-suli


*** FINISHED ***

Result: 25.2
This issue started after the first upgrade and persisted after the second.

I have installed a new NetXMS system on an Ubuntu server to test the newest release and some new ideas for our existing install.

Previously we had used email for our alerting platform, but it has some issues, and we would like to attempt to use Slack as a possible alterantive, however when I configure the Notification Channel for Slack I am not getting anywhere and the error on the Notification Channel setup is Status: failure, Error Message: Driver Error

It is a brand new base install of NetXMS with the WebGui added... and a few nodes monitored.

I have configured a webhook for slack, and added the following configuration in the Notification Channel setup for Slack:

username=monitor
url=[https://hooks.slack.com/services/***** private info here *****]

I am not sure what I am doing wrong?

Thank you.
 

On a different server, I performed a fresh installation of nginx+tomcat+nxmc-6.2.4.war, and when I tested it, Pinview started working normally.

Im still seeing this after installing  6.2.3 agent from 5.2.8 server is 6.2.2  windows agents repeatedly update installed packages.

Thank you for your feedback. I have tried the following possibilities:

• I tried different NETXMS versions, currently 6.2.4 (the problem has persisted since the last 3 version upgrades).
• I recently installed TomCat 10 and re-uploaded the war file
• I tried with different browsers (Chrome, Opera, Firefox), but the result was the same.
• I select "Show server clock" in Client Preferences, save, and exit, but when I re-enter, it's still not set.
• I set the Alarms page using PinView F7, but the situation remains the same even after closing the browser or logging out.