NetXMS Support Forum

If I wanted to use this within Object Tools, is there a variable or other way to push the connected user's NetXMS Server/Login/Password connection details straight through to that command?

I was thinking of something along the lines of right-click on node to start the proxy process, followed by opening a Putty connection through that SSH tunnel.
Though that'd require two local commands and for the sake of usability (nobody would want to run it that way and enter half a dozen variables every time) would need to be wrapped in a script - but NXSL doesn't seem to include ways to run local commands.
Guess the above might work for RDP or for accessing web interfaces internal to a network, too.

An obvious concern would be the ability by an admin to log usernames and passwords. If nxtcpproxy was more integrated that step probably wouldn't be necessary?

Edit: I also just noticed, the proxy node is identified by name, not ID?

Ubiquiti UniFi SNMP Template

Applies to:
- A range of devices with Ubiquiti-style messy OIDs depending on firmware versions (things changed with firmware version 3.9.19):
  - Devices with SNMP Object ID .1.3.6.1.4.1.10002.1 or SNMP Object ID like .1.3.6.1.4.1.41112.* if a valid result is returned for OID .1.3.6.1.4.1.41112.1.6.3.1.
  - Devices with SNMP Object ID .1.3.6.1.4.1.8072.3.2.10 if a valid result is return for OI .1.3.6.1.4.1.41112.1.6.3.1.0.
  - The Ubiquiti template applies to anything with either 10002 or 41112 match as well as 8072. In case of the latter, the system description also needs to start with UAP.

Notes:
- The pre/post 3.9.19 UniFi templates included in the XML both collect the exact same data. They only cater for the fact that Ubiquiti decided to change the OIDs used.

Ubiquiti AirMAX SNMP Template

Applies to:
- Devices with SNMP Object ID .1.3.6.1.4.1.10002.1 (Frogfoot MIB, which Ubiquiti at some point decided to use before they got their own Enterprise OID) or SNMP Object ID like .1.3.6.1.4.1.41112.* (Ubiquiti's own OID). Devices must also have a valid entry for OID .1.3.6.1.4.1.41112.1.4.1.1.9.1 (i.e. must have an antenna registered)

Notes:
- Just to avoid potential disappointment: This is not a template for Unifi Access Points. It is for AirMAX wireless bridges.

Ruckus ZoneDirector SNMP Template

Applies to:
- Systems with SNMP Object ID .1.3.6.1.4.1.25053.3.1.5.*

Note:
- Unnamed WAPs in ZoneDirector will show up with the same instance name, making it difficult to tell them apart. It is recommended to ensure they all have proper names.

Xirrus Access Point SNMP Template

Applies to:
- Systems with SNMP Object ID .1.3.6.1.4.1.21013.1.*

Notes:
- Default SNMP Community for Xirrus access points is xirrus.

Cisco 3/4G SNMP Template

Applies to:
- Systems with SNMP Object ID .1.3.6.1.4.1.9.1.* and a valid entry in the .1.3.6.1.4.1.9.9.661.1.1.1.1 table.

We went with the packages for the community edition. Enterprise is not something we're considering at our end at this stage, but other NetXMS users might?

The NetXMS database schema is different for TimescaleDB (even from Postgres -> TimescaleDB), so you'd have to use nxdbmgr for the migration. It's meant to support migration to TimescaleDB from 2.2.14 onwards (haven't tried it yet, we're still running load tests and comparisons between TimescaleDB and Postgres, feeding 50-60GB of live data into each system per day to compare performance).
One thing to note on TimescaleDB use, from what I can tell NetXMS configures the Hypertables with a 1 week chunk interval by default. Depending on your data ingestion rate, you may want to change that before you go live (e.g. for our test, I changed it to 1 day).

Unmanaged is for nodes that really are unmanaged. They are not polled for anything and don't change status.
Unreachable nodes do run status polls, that's how they change back to being reachable. If yours don't, that'd be a bug that needs to be investigated/reported.
However, unreachable nodes will not run configuration or instance discovery polls until status polls show that a node is reachable again.
How many status polls need to be successful for a node to be considered reachable as well as the time between status polls can be configured.

There are server-side settings which get pushed to clients as defaults and you can override them on the client itself as well.
See screenshots.

For Client Configuration, go to File -> Preferences -> Object Browser. Even with different server side settings configured, I'm pretty sure it'll show filter delay as 300 (ms) and filter minimal length as 1 which are client defaults (but don't apply if you have "use server settings for object filter" checked).

I recall seeing that a while ago and opening a bug report for it: https://track.radensolutions.com/issue/NX-1502
While the issue is marked as resolved as a feature was added to prevent automatic SNMP version changes during configuration polls, Victor's comment might shed some light as to when this change can happen. Basically, if the device doesn't respond to an SNMPv2 request, it'll try SNMPv1. I guess if the device is slow in responding (Lenovo/IBM Integrated Management Modules come to mind), it might switch back to v1 simply because the device doesn't respond to the v2c request in time. Increasing the default SNMP timeout might work around that?

Based on your other post, I'm assuming you're trying to run this on CentOS, built it from source and are a Linux novice. Feel free to torch me in a response, but that is probably not the best combination for testing NetXMS and is likely to lead to the frustration you've shown in your subject. This isn't a NetXMS server problem.

Having said that, for older CentOS there was a startup script in the sources, as mentioned in this post: https://www.netxms.org/forum/installation/start-services-on-boot/
That may still work in CentOS 7, though it is using systemctl. You could also write your own startup script, similar to what's mentioned here (more generic CentOS, definitely not NetXMS specific): https://unix.stackexchange.com/questions/368368/how-to-make-a-service-that-starts-on-boot-in-centos

Otherwise, it may be simpler to just run this on Windows or install a Ubuntu/Debian Linux (where you can install from the repository and everything "just works"). We're doing the latter, so unfortunately I'm not in a position to provide step by step guides to a CentOS setup from source style install.

Oops. That's because I misspelled it. It's raspbian, not raspian.
You can browse through the repository: https://packages.netxms.org/

The below example is not related to your specific issue. It is just an example of using Hashes as part of alert keys (in this case related to our StorageCraft ImageManager Windows Event Log monitoring, so not SNMP Traps). The actual processing policy is a bit of a catch-all for a lot of events, so we have logic in there to to identify the event source, etc.

Some notes for this specific example:
parameters[1] is the full path of the backup file
parameters[2] is the event source
parameters[3] is the event ID.
d2x is to convert the decimal node ID into a hex. That's done to build a matching alarm key, as the key is making use of the %i macro (which is the node ID in hex).
The hash function is used to convert the file name into a short hash value. To ensure there's no other random alarm that might reference exactly the same filename, I'm adding a pre-defined text ("ImageManager Consolidation"), so this hash will be unique to those types of alerts with that file name.

// ImageManager Alerts [for 1-parameter event log entries]
if ( $event->parameters[2] == "StorageCraft ImageManager" ) {
// Event Description: ImageManager Successful Consolidation
if ( $event->parameters[3] == "1120" ) {
consolidatedFile = $event->parameters[1];
// Checking if a matching alarm exists.
alarmHash=sha1("ImageManager Consolidation".consolidatedFile);
alarmKey="EVENTLOG_0x".d2x($node->id,8)."_".alarmHash;
if ( FindAlarmByKey(alarmKey) == null ) {
// No standard alarm exists, checking for alarms against SPF Consolidation failures.
consolidatedFile ~= "(.*-b[0-9]+)-i[0-9]+.*.spi";
alarmHashSPF=sha1("ImageManager Consolidation".$1);
alarmKey="EVENTLOG_0x".d2x($node->id,8)."_".alarmHashSPF;
if ( FindAlarmByKey(alarmKey) == null ) {
// No alarm found at all. We'll log this as a standard message and do not trigger any action.
$event->setMessage("ImageManager Consolidation Successful. Filename: ".consolidatedFile);
return false;
} else {
// A Consolidation alert referencing an SPF file was found and should be terminated.
$event->setMessage("\"ImageManager - Consolidation - Status\" is in state \"NORMAL\" - (".eventMessage.")");
CUSTOM_MESSAGE=alarmHashSPF;
return true;
}
The above is taken from a policy that terminates alarms. It is also not the complete code. But it should give you an idea how this can work.
The Alarms terminated have the following key:
EVENTLOG_%i_%M
%M is the macro for the CUSTOM_MESSAGE variable set in the filtering script.

If you return false, the alarm termination/actions won't be triggered.
If you return true, they are.

For the sake of usage of sha1(), it's really that simple: return sha1('string'); will return the sha1 hash of that string. Same with the other two hash functions.

Can you confirm that DeleteEventsOfDeletedObject is set to 1?
Have you tried shutting NetXMS down and running "nxdbmgr check" on your server?
Just in case your problem is related to inconsistencies in your database.