NetXMS Support Forum

You can setup a password input field.
That way, your users would have to input their password when executing the object tool.

Look in the Object tools config, under Input fields.

Here is a link that explains how they can be used:
https://www.netxms.org/documentation/adminguide/object-management.html#object-tools-macro

Here is an example of a transform script:

// $1 will be inserted into the Transform Script (see Transform Script hints)

// here we do a regex capture of numbers
$1 ~= "(\\d+).*";

// first capture group will be $1, so we return that
return $1;


This will return a number.
So just set DCI to unsigned integer type.

Then setup a threshold like normal to have alarms.

Zone proxies should also be in the zone which they belong to.
System automatically knows that if a node is set as a proxy for a zone, it will be polled directly from the server.

(make sure you are running at least 2.0.5+, since this was added only recently)

Its a bug in NCMX (client), that is already fixed in develop.

Quote from: starkiller on August 04, 2017, 05:06:45 AM
In any case I am just one user expressing and issue with the on part of the design of netxms which causes confusion compared to other NMS systems and hoping it would recognized as and issue and be fixed by the author.

I just read through this entire thread.

Actually, you are one user that is fighting the system, instead of trying to understand how it works.

NetXMS make NO assumption, it does NOT show what could be. It shows what is.
You seem to completely misunderstand the concept that one node is one object, and it's linked to (it's bound) to many places around the system.

It's consistency.

The way you are proposing would be way too confusing to existing and new users.
One object, with the same Object ID would show different children (be that interfaces, or VPN connectors, or wireless interfaces, etc.) across different parts of the system.

I REALLY suggest trying to see how the system works and why it works that way instead of arguing why the way that works for thousands of NetXMS users is wrong.

You make 0 attempts to ask questions, to see why the system behaves how it does, or to understand NetXMS philosophy.
So you will have to accept my post doing the same.

Both of these are possible.

1) You have to enable zoning in NetXMS.
Then create a separate zone for each network.

For the remote zone, you can proxy all communication to the zone through a proxying Agent (just normal NetXMS Agent with proxying enabled).

2) This actually happens completly automatically when NetXMS has enough information about the network.
NetXMS internally builds topology, and uses that for outage correlation.

So if all devices properly expose topology information to NetXMS, it will just work.
You can check by creating an L2 map with the AP as the root node.

If the map properly shows the entire topology, then network correlation will work.

The filter box is bigger because of the new 'Clear' an 'Info' buttons.
I was also made bigger and made to show by default in almost all views where it is available.

This is because most people didn't know the filter box was available in DCI 'Last Values' views, or in EPP, or server configuration view, etc.
So it was an UX change to make the search/filter box more available to people everywhere across the system.

I personally think it's good it's being bigger, since it provides new as well as existing users with easier access to it.
But that's of course just my opinion

There is a ticket for MikroTik LLDP, however work on it has not started yet.
https://track.radensolutions.com/issue/NX-1189

2.1-RC1 netxms-client was not uploaded to Maven Central yet, that is why install fails.

Alex will have to do that, and it should install fine.

You can use scheduled maintenance mode.

You can do this for whole containers if needed.

There is a feature request for this for some time, however the amount of work to implement it is quite large.
Also the information on current link speed / max link speed is actually not easily found in SNMP, and not all devices expose that information.

https://track.radensolutions.com/issue/NX-753

As mentioned previously, agent and server need cleartext key to communicate.

You can encrypt the cleartext key in Agent, or on Server, thats OK.
Or you can only encrypt the key on one side, thats also OK.

Since encryption is a reversable process, as long as both parties can get the cleartext key (either have it input directly, or decrypt it when provided as encrypted using nxencpasswd), then communication can happen.

After both parties have the cleartext key, they can use hashing crypto functions to assure that communication is authenticated and secured.

I hope that better explains it

Maybe its best to exactly describe a scenario that you think should not work, and we can see whats happening

In which case should communication not be possible?

As I posted above, even if you put a secret that is a hash itself into the configs, NetXMS doesnt treat it as a hash, but as a clear-text shared secret.

Quoten your example 2, its actually the same, but the shared secret '01b307acba4f54f55aafc33bb06bbbf6ca803e9a' is hashed using SHA1.
That means, that while you input a shared secret that is theoretically a SHA1 hash in itself, Agent and server still hashed it.

You dont put a hash into the config, you put the shared secret in there.
The agent and server then hash it internally to communicate.

So in your example 1, agent hashed '1234567890' into a SHA1 hash, sent data to server.
Server checked data by checking if its configured secret matches the SHA1 hash.

In your example 2, its actually the same, but the shared secret '01b307acba4f54f55aafc33bb06bbbf6ca803e9a' is hashed using SHA1.
That means, that while you input a shared secret that is theoretically a SHA1 hash in itself, Agent and server still hashed it.

Communication would not be possible if both sides only knew the hash, thats not how cryptography works.
Both sides need to know the clear-text secret in order to create hashes and validate the payload.

In case 3, you input an encrypted shared key.
Agent decrypts it, then hashes the cleartext value and sends data to server.
Server also decrypts the shared key, and again checks if the hash of the received data matches its cleartext shared secret.

The encryption only serves the purpose of both parties not exposing the shared secret directly in cleartext in configuration files / database.

You didnt get an answer because your question was not clear enough.

Quoteactions/parameters and other fields are blank

What actions, what parameters?
Is this in DCI configuration, in Event Processing Policy, in Event configuration?

Please include some screenshots or a more details description next time, and the community will be happy to help