NetXMS Support Forum

Hi,

it seems to be some strange mix of different library versions (*.so.1 and *.so.2). Try to delete all libraries from /opt/netxms/lib, run make clean and then make and make install again.

Best regards,
Victor

Hi,

it's a bug in console. I'll fix in till next release.

Best regards,
Victor

Hi,

currently it's not possible to change column order. You can "hide" column by resizing it to zero - console should remember column width settings.

Best regards,
Victor

When you run configure it will create config.log in same directory. Yes, I need it from M5.

Best regards,
Victor

There is issue after upgrade with incorrectly configured agent cache mode. Check that server's configuration parameter DefaultAgentCacheMode set to 2, and restart server (you may need to restart server even if it is set to 2).

Best regards,
Victor

Hi,

templates may be configured not override "disabled" flag on node DCIs. This is done to allow to disable unsupported/unwanted items on some nodes and not re-disable them after each template change. You can turn this off by setting ApplyDCIFromTemplateToDisabledDCI to 1.

Best regards,
Victor

Hi,

it could be like this:


if ($object->type == 1)
   return true;  // allow all subnets

parents = GetObjectParents($object);
//if (parents == null) return false;
foreach(p : parents)
{
   if ((p->type == 5) && (p->name == "containerA" || p->name == "ContainerB")) return true;
}
return false;


You can also add additional contraints on subnet names as usual using $object->name.

Best regards,
Victor

Line like this:


table = AgentReadTable($node, "System.Processes");


will read agent table (System.Processes in this example) into variable. It will be object variable of class Table. Then you can walk through table using it's methods. For example, to read value of column "NAME" in first row you can use the following code:


colIndex = table->getColumnIndex("NAME");
value = table->get(0, colIndex);


You can iterate through table using rowCount attribute as stop indicator:


for(row = 0; row < table->rowCount; row++)
{
   value = table->get(row, colIndex);
}


Best regards,
Victor

P.S. If you meant transformation script of a table DCI, then you don't need to read table - variable $1 will hold table object.

Just fixed it. Fix will be included in 2.0-RC1.

Best regards,
Victor

I probably understand it - nodes on L3 map re connected via subnet objects, not directly - and you filtered out subnet objects. You should change your filter to allow subnets or add relevant subnet objects to your container.

Best regards,
Victor

Did you check connector color in map properties? By objects' locations it seems that they are connected but connectors are invisible.

Best regards,
Victor

currently all scripts are handled equally - so it doesn't matter if script is a network map filter or DCI transformation script for example. Reason is the same - imagine you have access only to network map object - if script do not have access checks you'll be able to access data for nodes you don't have access to. I thinking for some time already about more sophisticated access control within scripts, but don't have better solution yet.

Best regards,
Victor

Hi,

links are not affected by map filter. Did you layout nodes by hand? If not, it seems as if links are there but just invisible. Just in case - check link color in map properties.

Best regards,
Victor

Hi,

these DCIs are not supported anymore because of recent changes in server internals. There are no more separate queues for status and configuration pollers - from 2.0-M5 we are using dedicated thread pool with task queue instead. You can safely delete these DCIs. If you are interested in monitoring poller thread pool, you can configure the following internal DCIs on server node:

Name: Server.ThreadPool.LoadAverage(POLLERS)
Description: Thread pool POLLERS: load average 1 minute

Name: Server.ThreadPool.Load(POLLERS)
Description: Thread pool POLLERS: current load

Name: Server.ThreadPool.CurrSize(POLLERS)
Description: Thread pool POLLERS: current size

Best regards,
Victor

Hi,

you can use scripting to store timestamp of first event in node's custom attributes, and for each subsequent event chech if it is too close to original one and only pass through if interval between them is sufficiently large.

Best regards,
Victor