NetXMS Support Forum

Quote from: Egert143 on February 23, 2022, 01:52:05 PM

Quote from: Victor Kirhenshtein on February 22, 2022, 10:34:17 PM

Quote from: Watchman on February 22, 2022, 05:15:21 PM
Hi!

I'm facing some problems with package deployment.

For example: msi-Package "A" is successfully deployed to most nodes but for some the message "file transfer failed" appears.
msi-Package "B,C,D" are successfully deployed to nodes where Package "A" fails.

Another case: Message "timeout" appears - in fact package has been successfully deployed (not really a problem)

Best regards.

Hi,

could you provide logs from problematic agents (preferably on high debug level, 5 or 6)?

Best regards,
Victor

Possibly related: https://www.netxms.org/forum/general-support/agent-upgrade-via-package-manager-fails/

Hi!
some additional info

- there are no "part-files"
- the files are merged - setup can be started with the transfered file

Regards

Hi!

I'm facing some problems with package deployment.

For example: msi-Package "A" is successfully deployed to most nodes but for some the message "file transfer failed" appears.
msi-Package "B,C,D" are successfully deployed to nodes where Package "A" fails.

Another case: Message "timeout" appears - in fact package has been successfully deployed (not really a problem)

Best regards.

Hi.
I'm trying to use getValue on Octet-String within scripting, but it returns an empty string.

transport = $node->createSNMPTransport();
if (transport != null)
{
  testStr = transport->getValue(".1.3.6.1.4.1.4196.1.1.5.2.100.2.1.4.0");
  if (testStr == "") println "huh ?";
}

The MIB-Browser shows Type Hex-String with Value "00 00 02 00 00"
The DCI with DataType String and no conversion collects the same value.
The code from above returns an empty string   

NetXMS version 3.9.156

Any hints?

Thanks in advance.

Hi,
updating from 3.8.366 to 3.9.156 works fine here (updated Windows package from 28-07-2021, 10:35).

Many Thanks for ongoing improvements.

But there are 2 'Problems':

• The SMTP check via Network service is not longer working.
• Trying to install any Agent-Version over version 3.9.156, via Package Deployment, fails with 'File transfer failed' 
  This might be a little desaster, when a new version has to be installed ..

Values in Server Configuration are
  StatusPropagationAlgorithm: Unchanged
  StatusCalculationAlgorithm: Most critical

I'll try to describe the 'issue' in other words:

The 'port down' event (minor) leads into 'port status' critical > minor ≠ critical
The 'port unexpected up' event (major) leads into 'port status' critical > major ≠ critical

A change within StatusPropagationAlgorithm and StatusCalculationAlgorithm won't fix it.
It's a decision of development or a bug.

Greetings

In general I like this Feature. 

Since every source can theoretically generate events with ID 0-65535, it should be possible to include/exclude a combination of source, level and ID (similar to Logwatch).
For example: A search for ID 1 on www.eventid.net shows a list of many different sources with different level.

I tried some keywords, but with version 3.8.266 level or severity is not supported?

My first and most important step would be to exclude level 4 (information).
That would greatly relieve the database.

I'm looking forward to new filter options. 

Thanks in advance.

>>> Which version are you using?
Version 3.8.266, but I think the behavior has always been like that.

>>> Just tried recent one, unexpected interface up is critical on an interface and changes node to critical. Same for interface down.
.. and I think it's not correct.
Why are events with the status minor or major processed as critical?

• Event 'Interface down' with severity 'minor'
• > Alarm 'Interface down' with severity 'minor'
• > Status 'Interface' gets 'critical'? 

>>> What about status calculation settings on the interfaces, not on the node, are they set to default?
All status calculation settings are default (server-configuration, interfaces, nodes, container).

Greetings

Hello.
While DCI-status is propagated to parent objects with the original status (warning, minor, major, critical),
the status for 'unexpected interface up' (major) or 'interface down' (minor) is always propagated with severity critical.

As the the interface in object tree shows the status critical, it may be intentionally.
But I would like to have the original interface severity propagated.

Status calculation is set to default.
Is there a setting to change this behavior?

Thanks in advance.

Hi,
a short description of what I'm doing:
- I create a dump of the netxms_db
- restore it on a test system
- and start NetXMS

On the test system all nodes are unreachable.
After a short time the network map looses allmost every information, as you can see in the pictures below.
On each restored database it is different which elements are removed and which remains on the map. 

It would be better when elements and links with their actual status remain on the map.

Changing "TopologyExpirationTime" seems to make no difference.

Best regards.

Quote from: Victor Kirhenshtein on March 30, 2016, 06:43:10 PM
...
- Management console:
...
        - Fixed object selection issues in network maps
...

In Release 2.0.2 I recognized no issues with the selection of network elements. 
In Release 2.0.3 a selection is only possible when the network map is shown at "zoom level 0" (pressing Ctrl-0) - when scrollbars are shown, they have to be moved to the most upper and most left position.
On other zoom levels (+ or - button) or scrollbar positions the selection points are not below the elements.

I am using nxmc-2.0.3-win32-x86.

Many thanks for your answers.

Quote from: Victor Kirhenshtein on October 19, 2015, 11:23:25 AM
..
GetDCIValueByDescription reads last value from cache. It can happen that it was called faster then cache for queried DCI was populated (either by poll or from database). I'll think what I can do with that.
..

It would be nice if the behavior could be changed.
(Although a restart is a special situation ..)

Best Regards.

I set up an DCI with: origin-script, data type-string, polling intervall-300
The script returns possible node problems as string - amongst other things using the function GetDCIValueByDescription.
While NetXMS is constantly running, I get the last value (not empty as expected).
If the Core Server has been restarted, the function GetDCIValueByDescription returns (once) an empty string. 
I checked in the history that the last value was not empty.

I would call it a bug , observed in version 2.0-RC1 and 2.0-RC2.

Best Regards.

Hi @all.
Up to now we use 'The Dude' from Mikrotik - but development is stopped for years.
I am testing NetXMS from version 1.2.12 up to 2.0-RC1.
It is a nice software with great potential - functions like autodiscover, automatic map layout, usage of scripts, templates etc. are very welcome.
But I have also some ideas for improvements - here is my first

Automatic cyclic reconnect-attempt of the Management Console, if the connection is lost.
In an multi-user-environment all users have to reconnect manually if one user decides to restart the core server (ex: Windows Updates).
It would be also helpful when a short network problem occurs or if the server temporarily is too busy.

Best Regards.