NetXMS Support Forum

I had to remove java 8 for java 15 to be the default.  This was on windows. 

Just upgraded to 3.8.120 and still the same issue.

The only workarounds so far are:

1)

- Enable SNMP on the same machine that's running the agent.  It will detect the node, add it, and then also discover that it has a NetXMS agent installed.

2)

- Turn on "Active Only" network discovery.
- Turn off all filters.
- Add ONLY the IP(s) of the agent(s) you want to add, and do a scan.
- Once added, remove the IP's from the active list.
- Turn SNMP and NetXMS Agent filter back on.
- Set network discovery back to "Passive Only".

-zeb

Quote from: Filipp Sudanov on February 09, 2021, 02:56:56 PM
netsvc should not be required for web services. It should be present in netxms-agent package, please check output of
dpkg-query -L netxms-agent
If its not there, what is the version of OS?

No, nxget, nxaction, nxwsget do not support tunnel connection - they attempt to connect to agent directly.

Hi Filipp,

We're running mostly on CentOS so we use the tar/APKG packages and there isn't a "netxms-agent" package installed per se.

If I do a nxwsget from the server to one of these agents, I get a "501: Not implemented" error.

I'm not sure what I'm missing.

I did get web services to work on this agent though, just not using nxwsget and the example you provided (nxwsget <ip of agent> http://api.open-notify.org/astros.json number)

-zeb

Quote from: Victor Kirhenshtein on February 09, 2021, 01:59:04 PM

Quote from: Zebble on February 05, 2021, 11:12:17 PM
Finally, slightly related but is the asterisk.nsm subagent available anymore?  It appears that the libosip2/libXosip2 library dependency is really old and unsupported with newer version of openssl, so is difficult to build on more modern build environments.

Asterisk subagent is supported. We provide binary builds for all supported Debian and Ubuntu versions. Ubuntu 20 does not have libexosip2 package, but when you install Asterisk subagent from our repository it will bring our build of libexosip2. If you build from sources, you can download and build libosip2 and libexosip2 version 5.2.0 - they are fairly new and seems to be building without issues on modern distributions.

Best regards,
Victor

For the most part, we're using CentOS so we use the linux x86_64 tar for installation, and the APKG packages and the Package Manager for subsequent updates.  The APKG doesn't appear to have the SSH or Asterisk (or some other subagents) installed.  Any chance these will get added to the APKG and tar installation/update methods?

I was able to build the Asterisk subagent finally after searching for libosip2 and libexosip2 version 5.2.0 as you noted.  Not very easy to find!   The subagent works really, really well so far.  Gives us a lot of metrics that often require very expensive tools to monitor.  Nice work!

-zeb

I agree with that.  I seem to remember Java 8 working for early versions of 3.7 and then stopped working for newer versions.  Not sure at which version this changed, nor did I see any notes on the download page that Java 11+ was required, so it was a bit confusing.

You'll need at least Java 11 for 3.7 or higher.  I use Java 15 and it works just fine:

https://www.oracle.com/java/technologies/javase/jdk15-archive-downloads.html

-zeb

Thanks Filipp, this definitely helped narrow down the problem.

It looks like Web Services require the netsvc.nsm subagent.  netsvc.nsm doesn't appear to be included in the pre-packaged agents, so needs to be built from source.  Any chance of having this included in the pre-packaged agents so this can be easily installed and centrally updated through the standard methods?

A question on nxwsget.  Can it also use a proxy agent to make the call, if that proxy agent is connected via a tunnel (ie. agent -> server tunnel)?

Finally, slightly related but is the asterisk.nsm subagent available anymore?  It appears that the libosip2/libXosip2 library dependency is really old and unsupported with newer version of openssl, so is difficult to build on more modern build environments.

-wade

I can't seem to get an agent to execute a web service check.  It seems fairly simple:  Define the Web Service Definition, then add it as a DCI for a specific agent, including the additional web service path (ie. webservice:/path) as the URL.

It seems to add the DCI and mark it as greent, but never does anything on the agent side if I enable debugging.

I'm using 3.7.145 on the server, 3.7.130 on the agent.

-Zeb

Good question.  Didn't realize this existed, and I see no other reference to it other than the nxagent sourcecode.  Might not be fully implemented?

Great idea, and something we were just reviewing.  We use Mikrotik's exclusively, and we standardize interface names so should be able to base discovery on that.  Still makes it a bit "manual" but should keep us honest with proper alerts and monitoring.

Thanks!

That's great news!  Thanks Victor.

Log attached in passworded ZIP.  I've sent you the password as a PM.

You'll see that the server discovers and successfully adds a NetXMS agent on its local network (206.xxx.xxx.25).

The proxy agent won't add a NetXMS agent on it's local network (192.168.223.250), even when I add it manually and start an active scan.

Hope this helps!

-Zeb

Thanks guys!

Just did a quick test and as per Filipp's request, the auto-discovery of NetXMS agents does work on the the server's network, but not on any proxy networks.

I'll capture the logs at debug level 4 on both the server and proxy agent if you still need it?

Is there an easy way to identify uplink ports on switching devices?  We'd like to automatically set the expected state on these interfaces to "UP" and all other ports to "IGNORE", as well as potentially add DCI automatically to these same "UP" ports.

I've started working through a server side script to add during polling, but thought I'd ask if there's an easier way I'm missing?

Thanks!

-Zeb

Everything we use we now mandate to have some sort of Multifactor authentication.  Simple TOTP would be great.  Cisco Duo integration would be even better for us, but not necessary.