NetXMS Support Forum

Hi,

Looks to me like negative lookahead regular expressions are not working (I tested a bit and got the same result you did).
Not sure if there's some syntax difference or if the ?! is being interpreted by something else.

You could change your
if ($1 ~= "^([0-9]+) .*")
to this
if ( ($1 ~= "^([0-9]+) .*") && ( ! ( $1 ~= "^[0-9]+ (127|::1|fe80).*" ) ) ) {
It should work and remove the need for the additional if statement you added, but in the end, it's still just a workaround for the negative lookahead not working properly.

Cheers

Hi,

You do not need need or want a standard 3rd party CA certificate for NetXMS Agent Tunnels.

My guess is your certificate has the same problem I had with my initial certificate attempts:
[..] The latter is presumably meant to sign additional certificates, but my server certificate was not authorised to do that. [..]

I've run into a few issues of my own while setting this up (it's all running smooth now) and posted my progress notes on the forum here:
https://www.netxms.org/forum/configuration/agent-to-server-connections/msg22308/#msg22308

The certificate on the server is used to sign new certificates for the agents, so they can authenticate to the server.
A standard GoDaddy certificate wouldn't be authorised to do that. There is a link in my post above which points to a guide on how to setup a CA. Together with the remaining notes in the thread, you should be able to get this up and running.

Cheers

Hi,

You can do some inline debugging by using the trace command, e.g.
trace(0,interface->speed);
That would log interface->speed in the server's log at debug level 0. Standard string concatenation rules apply.

You may also want to do $1 * 8 prior to the speed comparison.
For all I recall $1 is Bytes, but interface speed is Bits.

Cheers

Hi,

Just a FYI: The issue persisted with the release of 2.1, but has now been resolved in the latest development build.

A huge thank you to Victor for logging into our system, determining the underlying cause (related to Active Agent Tunnels) and fixing it.

Cheers

Hi,

Once you create a Layer 2 map, you can enter the map's properties and add more seed nodes (at least in 2.1 you can, I don't recall if that's a new feature or not).
You can also configure a custom discovery radius for the map.

Cheers

Hi,

Things I'd check in such a case:
- Ensure port 4700 on your Ubuntu server is indeed reachable from the NetXMS server, i.e. there is no firewall in between or on the Ubuntu server blocking access. A simple telnet test to port 4700 should do.
- Check if Agent Polls are disabled on the node.
- Run a Full(!) Configuration Poll against the node.
- Enable some debug logging on the server and/or agent. Run polls and check the logs for potential issues.

Cheers

Hi,

I use containers with auto-apply templates. Something like this:
if ( ( $node->isAgent ) && ($node->platformNAme == "windows-i386" ) ) return true;
and the matching
if ( ( $node->isAgent ) && ($node->platformNAme == "windows-x64" ) ) return true;
Then simply apply the correct packages to those containers.

That won't fix your "Unable to start upgrade process" though.
I've seen that a few times when the upgrade does go through, but the agent version in the Console doesn't update until the next configuration poll.

Cheers

Hi,

If you have a lot of data, slow database or slow network connection to the server and you are using the management console, that can happen.
The request from a Console results in all relevant data being sent to the client, which then generates the graph (i.e. the server does not generate the graph and sends the image down).
Using the web management console, if installed on the same system as the NetXMS server is usually a lot faster for graphs for that reason.

I haven't had this for a 4 hour time period, but certainly if I request data for a couple of weeks or a month. Simply clicking the refresh button on the graph usually works - possibly because the client cached what it already received?

Cheers

Hi,

Passive Network Discovery works via agent. So if the network you're trying to discover has managed switches with LLDP/CDP and no unmanaged devices in the mix, it should provide some results.
Ensure to set the correct zone ID in the proxy agent's configuration.
Active Discovery via agent still does not work (for all I know).

Cheers

Hi,

Looking forward to upgrading to 2.1 once the repositories are updated.

Cheers

Your example should be ok to exclude anything with "DWL" in it.
I have to assume there is a "return true;" somewhere in your script as well? Otherwise the result will be "false" anyway and the exclusion is unnecessary - as the filter will never return true.
For your exclusion, you may also want to make sure that your node name is in fact using capitalised "DWL". If not, maybe use "ilike" instead of "like".

This should be enough to exclude anything with "DWL" (capitalised or not) in it and include everything else:

if ($node->name ilike "*DWL*") return false;
return true;


You can always run this against a node via "Execute server script" to confirm that it returns the result you are expecting.

Hi,

Just wanted to check in to see if there is a new ETA for the next release? Maybe a 2.1-RC2 as an in between step?
I'm mostly asking as our server is crashing pretty much every hour by now and the fix (agent tunnel related) is in the next version.

Cheers

It looks to me as if what you are trying to do should probably be done in the instance discovery filter script, rather than via attempting to call a script within the DCI description?

The following should work:

Create a script called "MyScript" with the following code:
node1 = FindNodeObject($node,"NODE1_NAME");
node2 = FindNodeObject($node,"NODE2_NAME");
dci1 = GetDCIValueByDescription(node1,"DCI1_DESCRIPTION");
dci2 = GetDCIValueByDescription(node2,"DCI2_DESCRIPTION");
return dci1 + dci2;

Replace NODE1_NAME and NODE2_NAME with the object names of the nodes holding your data.
Replace DCI1_DESCRIPTION and DCI2_DESCRIPTION with the DCI descriptions.

Create a new DCI on a node, select type "Script" and select the "MyScript" you created earlier.
You do not need to use a delta transform for this, as you already transformed the other two DCIs.

If you do not get any result, there may be a typo in one of the node names or DCI descriptions or you may have the trusted node check enabled (that's the default) and NODE1_NAME and/or NODE2_NAME do not contain the node you're running the script on in the list of trusted nodes. You can confirm if that's the issue by setting the server configuration variable CheckTrustedNodes to 0 and restarting the NetXMS server.
You can always just right-click on a node and "Execute Server Script" and select "MyScript" to see what's happening when you execute it.

Documentation references:
https://wiki.netxms.org/wiki/NXSL:FindNodeObject
https://wiki.netxms.org/wiki/NXSL:GetDCIValueByDescription
https://wiki.netxms.org/wiki/SG:Security_Issues

Cheers

Hi Adrian,

Your result being RStatus(, 172.20.4.254) makes it look like the script is not returning any result or you have a typo in the script name.

I dug out the old script/DCI I used and confirmed this still works:
Script Name: Attribute::Get::VeeamGuestName
Script: return VeeamGuestName@$node;
DCI Parameter: Software.Veeam.BackupStatus('%{script:Attribute::Get::VeeamGuestName}','Backup','Status')

That results in the actual DCI on nodes matching the template to look like this (with ATTRIBUTE being the content of the custom attribute):
Software.Veeam.BackupStatus('ATTRIBUTE','Backup','Status')

Hope that helps somewhat.

Cheers