NetXMS Support Forum

I've been labouring under the misapprehension that the jar files are just some files I need to get from somewhere in order to get the report server running, but no. The jar files represent reports I have to build specific to my environment, so that's why they don't just exist ready for installation.

Seems like Luis Montaño might have the answer, will test it:

https://www.netxms.org/forum/installation/installing-reporting-server-on-windows-server/

Same issue here. Is the reporting component still maintained?

Obviously I would rather send you the output of whatever snmpcommand you specify but if remote access is definitely what you need, PM me.

With Cisco SB "SG550XG-8F8T 16-Port 10G Stackable Managed Switch" [OID .1.3.6.1.4.1.9.6.1.90.16.9] the automatically selected network driver is GENERIC. Everything seems to work OK except the Ports tab which is empty. System consists of a pair of these in a stack.

Followed instructions at https://www.netxms.org/forum/general-support/network-driver-type-incorrect/msg19491/#msg19491 to change driver to CISCO-SB. Ports tab is now populated but shows all ports in "Slot 1". The Components tab looks good - shows each stack member with one "slot" [these aren't modular switches] per stack.
I am not sure if the appearance of the Ports tab is what is expected in a stacked switch.
Assuming that the CISCO-SB driver is correct for this switch, what is required to get this type of device always to be detected as CISCO-SB?

I guess this thread is pretty much an "FYI" now, because I've sorted it. I renamed the index to .old and the upgrade has succeeded. I don't really know enough about databases to know what terrible consequences this will have, but I guess I'll find out.
The reason it spent so long on that upgrade step is that the syslog table is 7GB.

Of course, starting moving as soon as I posted this. So we're here now:

SQL query failed (Duplicate key name 'idx_syslog_source'):
CREATE INDEX idx_syslog_source ON syslog(source_object_id)
Rolling back last stage due to upgrade errors...
Database upgrade failed


Running with trace:


# nxdbmgr upgrade -t
NetXMS Database Manager Version 2.1 Build 9012 (2.1-RELEASE) (UNICODE)

Upgrading database...
Upgrading from version 431 to 432
>>> CREATE INDEX idx_syslog_source ON syslog(source_object_id)
SQL query failed (Duplicate key name 'idx_syslog_source'):
CREATE INDEX idx_syslog_source ON syslog(source_object_id)
Rolling back last stage due to upgrade errors...
Database upgrade failed


Inspecting with phpmyadmin, I can see this index already exists on this column.

Upgrading to 2.1 today. Post-install scripts in package trigger a database upgrade, and all  updates succeed up to:

Setting up netxms-server:amd64 (2.1.0-1) ...
NetXMS Database Manager Version 2.1 Build 9012 (2.1-RELEASE) (UNICODE)

Upgrading database...
Upgrading from version 404 to 405
Upgrading from version 405 to 406
Upgrading from version 406 to 407
Upgrading from version 407 to 408
Upgrading from version 408 to 409
Upgrading from version 409 to 410
Upgrading from version 410 to 411
Converting table tdata_100: done
Converting table tdata_938: done
Converting table tdata_945: done
Converting table tdata_1053: done
Converting table tdata_1054: done
Converting table tdata_1249: done
Converting table tdata_1451: done
Converting table tdata_1458: done
Converting table tdata_1465: done
Converting table tdata_1468: done
Converting table tdata_1470: done
Converting table tdata_1474: done
Converting table tdata_1487: done
Converting table tdata_1496: done
Converting table tdata_1501: done
Converting table tdata_1553: done
Converting table tdata_1586: done
Converting table tdata_1588: done
Converting table tdata_1595: done
Converting table tdata_1597: done
Converting table tdata_1599: done
Converting table tdata_1623: done
Converting table tdata_1628: done
Converting table tdata_1639: done
Converting table tdata_1652: done
Converting table tdata_1660: done
Converting table tdata_1668: done
Converting table tdata_1670: done
Converting table tdata_1702: done
Converting table tdata_1704: done
Converting table tdata_1706: done
Converting table tdata_1708: done
Converting table tdata_1710: done
Converting table tdata_1712: done
Converting table tdata_1714: done
Converting table tdata_1716: done
Converting table tdata_1718: done
Converting table tdata_1720: done
Converting table tdata_1722: done
Converting table tdata_1724: done
Converting table tdata_1726: done
Converting table tdata_1728: done
Converting table tdata_1730: done
Converting table tdata_1732: done
Converting table tdata_1773: done
Converting table tdata_1816: done
Converting table tdata_1823: done
Converting table tdata_1970: done
Converting table tdata_5662: done
Converting table tdata_5706: done
Converting table tdata_5746: done
Converting table tdata_5748: done
Converting table tdata_5750: done
Converting table tdata_5752: done
Converting table tdata_5755: done
Converting table tdata_5757: done
Converting table tdata_5770: done
Converting table tdata_5776: done
Converting table tdata_5796: done
Converting table tdata_5801: done
Converting table tdata_5803: done
Converting table tdata_5805: done
Converting table tdata_5807: done
Converting table tdata_5811: done
Converting table tdata_5845: done
Converting table tdata_5879: done
Converting table tdata_5880: done
Converting table tdata_5915: done
Converting table tdata_5927: done
Converting table tdata_5653: done
Converting table tdata_5655: done
Converting table tdata_5656: done
Converting table tdata_5657: done
Converting table tdata_5658: done
Converting table tdata_5660: done
Converting table tdata_5779: done
Upgrading from version 411 to 412
Upgrading from version 412 to 413
Upgrading from version 413 to 414
Upgrading from version 414 to 415
Upgrading from version 415 to 416
Upgrading from version 416 to 417
Upgrading from version 417 to 418
Upgrading from version 418 to 419
Upgrading from version 419 to 420
Upgrading from version 420 to 421
Upgrading from version 421 to 422
Upgrading from version 422 to 423
Upgrading from version 423 to 424
Upgrading from version 424 to 425
Upgrading from version 425 to 426
Upgrading from version 426 to 427
Upgrading from version 427 to 428
Upgrading from version 428 to 429
Upgrading from version 429 to 430
Upgrading from version 430 to 431
Upgrading from version 431 to 432


Been sat at 431 to 432 for 30 minutes. Server load average is 1.2 so not heavily loaded. Mysql is working fine. 

I think it would be helpful if nxmc indicated which version of nxmc was required rather than just saying "incompatible version".

This thread is first hit on google for "netxms format string" and I was interested in this also. Further digging reveals this:

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

where Victor K advises to use format string %*d and it works as expected - values collected as "... traffic (bits) Delta value" are displayed as k/m/g as appropriate

Quote from: tomaskir on October 14, 2016, 12:39:11 PM
1) Network discovery over agents is not supported, currently network discovery works only directly from the server.

If an SNMP agent were to send traps to a NetXMS agent, would that type of "passive discovery" work?

Quote from: radw on June 15, 2016, 09:29:59 AM
I'm wondering if its possible only with apt update and upgrade netxms , for not install all other Debian packages.

apt-get install <packagename> will update just <packagename> if there are updates available for it [and any necessary dependencies also].

Has been a while since I looked at this [still no "active discovery check" lines in 2.7M lines of log files] so I will upgrade to newer version before troubleshooting further.

Quote from: hkusulja on June 06, 2016, 08:44:31 PM
I hoped for native NetXMS solution

Site-to-site VPN? TBH the cheapest VPN-capable router will be about the same price as an SBC to run nxagent on, so not much difference either way.

Can you fool NetXMS with multiple DNS/hosts entries pointed at the same IP address?

I have posted the same graph twice, one with stack enabled, one without and I think it demonstrates two distinct issues.

1) Negative is not stacked.

2) A DCI that I have specified to be inverted but in this dataset happens to be 0 for the entire series [WAN link is down so throughput is 0] is rendered above the positive values rather than at x=0. See the thin green line on the top of nxwanstack.png. Is this worth opening a separate bug for?