NetXMS Support Forum

Channel configuration looks fine.

The Utelred_bot that you specify as recipient - is it the same bot that you use for notification sending (the AuthToken is from that bot?).

If it's a different bot, I am not sure, if one bot can send messages to another. But generally recipient should be a name of either a group, channel or username. Or, second option, recipient could be numeric ID of group, channel or chat.

Try to send a message to your telegram account. For this in your telegram profile you need to set a username. Then you need to send a message from yourself to the bot (bots can not initiate dialogs). And then try to send notification to your username (without @) from NetXMS.

In Driver configuration we should only have configuration parameters for the driver in name=value format. So for Telegram only these parameters are allowed:

• AuthToken
• DisableIPv4 - true to disable IPv4 usage
• DisableIPv6 - true to disable IPv6 usage
• ParseMode - Text formatting style: Markdown, HTML or MarkdownV2. See Telegram API documentation on formatting syntax: https://core.telegram.org/bots/api#formatting-options
• Proxy - proxy url or ip or full configuration if format [scheme]://[login:password]@IP:[PORT]
• ProxyPort - proxy port
• ProxyType - proxy type: http, https, socks4, socks4a, socks5 or socks5h
• ProxyUser - proxy user name
• ProxyPassword - proxy user password

So just remove
Utelred_bot
Hi.
lines and it should work.
The text of the message is defined in properties of specific action that is used for notification.

Давайте начнем потихнечку. Судя по скриншотам ноды в системе у вас уже заведены (ну там SRV003 и все остальные).
На ноде нажимаем правую кнопку мыши, там есть Data Collection Configuration. Заходим. Это место, где конфигурируется сбор данных с ноды. Там список, каждая строка в этом списке это Data Collection Item - элемент сбора данных.
На списке правую кнопку мыши - New parameter. Там-то и ставим Origin "Internal", Parameter "Dummy". Dummy - это просто штука, которая всегда возвращает 0 - здесь значение нам не нужно, потому что мы его будет в transformation script добывать.
Слева в этом диалоге выбираем Transformation (третий пункт сверху). Там пишем код:

list = $node->readAgentList("System.ActiveUserSessions");
currentlyLoggedUser = SplitString(list[0], "\"")[1];
$node->setCustomAttribute("currentlyLoggedUser", currentlyLoggedUser);

Код получает с агента на ноде список залогиненных юзеров. Из этого списка мы просто берем первого. И сохраняем в custom attribute на ноде.
Нажимаем Apply and Close. Ждем пока данные соберутся.
На ноде нажимаем правую кнопку мыши, Properties, там слева Custom attributes. Если все хорошо, то там в списке должен быть currentlyLoggedUser с именем юзера.

Пишите, что получилось, что нет.

Can you show screenshot of notification driver properties (specifically Driver Configuration there).

Forced poll is described here: https://www.netxms.org/documentation/javadoc/stable/org/netxms/client/NXCSession.html#pollObject(long,org.netxms.client.constants.ObjectPollType,org.netxms.client.TextOutputListener)

For Cambium - the fastest way to debug might be if you can provide remote access to a Cambium device for our developers. Is it possible?

There was a bug related to use of case operator. It's now fixed, will be included in next release which is planned next week.

Ну если на машине, откуда посылаются запросы, несколько интерфейсов, то может с разных адресов запросы идут. IPv6 тут не должно быть - указан IPv4 адрес.

Я бы начал с дампа пакетов с помощью tcpdump или wireshark чтоб понять чем отличаются пакеты snmpwalk и nxsnmpwalk

There is EnableTCPProxy parameter in agent config file.
And there's a demo java app that uses this functionality: https://github.com/netxms/netxms/blob/master/src/client/nxtcpproxy/src/main/java/org/netxms/tcpproxy/TcpProxyApp.java

The idea is that this java app connects to the server using same protocol that nxmc uses. Then this app can establish tcp tunnel via the agent. And if I remember correctly, the test app just opens a tcp port locally that corresponds to the tunneled port.

There's a forum post with more details: https://www.netxms.org/forum/general-support/tcp-proxy-functionality/

There was an issue that when users that were synchronized by ldap tried to login with wrong password, this error was put in the log. Looks like it was fixed today, so should be in next patch release
https://track.radensolutions.com/issue/NX-2254

Just to mention - agent log parser policies (this stuff in configured in templates) can execute actions directly on agent, even without communication to the server. So theoretically agent can watch some log file of ssh client and call some script to reestablish connection. I doubt that this is the best way, but might be convenient from deployment standpoint.

Hi!

Actually, there is no write access to mapping tables from NXSL. We can use either persistent storage or custom attributes. Persistent storage record length is limited to 2000 chars and unlimited for custom attributes, so let's use them.

There are two scripts, first one should be set as EPP filter script so it will be executed when event comes:

s = GetCustomAttribute($node, "EventTimestamps");
if (s != NULL and s != "")
{
  a = s->split(",");
}
else
{
  a = %();
}
if (a->size < 2000) a->append(time());
SetCustomAttribute($node, "EventTimestamps", ArrayToString(a,","));
return true;
Every time when event comes, this script will add unixtime to the custom attribute on the node. There's a limit of 2000 records so that the string won't grow endlessly.

The second script should be executed periodically - we can use script DCI with needed interval, e.g. 1 hour or 24 hours. You can just use interval or you can set cron schedule so that this DCI get's collected at exact moment:

period = 3600 * 24; // in seconds

s = GetCustomAttribute($node, "EventTimestamps");
a2 = %();
now = time();

if (s != NULL and s != "")
{
  a = s->split(",");
  for (i = a->minIndex; i <= a->maxIndex; i++)
  {
    if (a[i] > now - period) a2->append(a[i]);
  }
}

SetCustomAttribute($node, "EventTimestamps", ArrayToString(a2,","));
return a2->size;

The script goes through all recorded timestamps, throws away those that are older then specified period, saves updated custom attribute and counts the number of records.

Hi!

Currently server uses one certificate for TLS connection and to issue agent certificates. To use this workflow you'd need a certificate from Certificate Authority with CA flag set - this might be problematic or expensive.

I've created an issue in our bug tracker with the idea to have two separate certificates on the server: https://track.radensolutions.com/issue/NX-2256
Until this is implemented, you theoretically can just obtain a certificate without CA flag and put it as ServerCertificate in server config. And you can put your current server certificate into TrustedCertificate parameter. This way your current agents would be able to connect and work, but server won't be able to issue new agent certificates when they expire.

The other approach could be some sort of VPN between agent and server.

By the way, do you have some information on how exactly this firewall does the checking - it works as man-in-the-middle or establishes a second connection to the server to get the certificate?

This looks strange. I suggest you to minimize the code to get it as short as possible with this bug replicating.

Does it acts the same if you do "Execute server script" on any node and put the code there?

For debugging you can also trace the number of elements of array, it's size attribute, e.g. retval->size

Log parser policy is probably a nicer approach as there's no need to maintain any scripts on agents. With this there are two approaches:

1) You can use repeat interval functionality of log parser. E.g. you can set Repeat interval to 24 hours. Repeat count should be set to 1 (if it's 0, this functionality is disabled). Reset repeat count should be unchecked.
So now we have a 24-hour long rolling window and on each new match generated event will have the number of matches happened within this window.

Now the question comes - how can we save the value from event processing policy rule. We can create a DCI with origin "push". To this DCI we can send values from NXSL script (and also from command line utilities nxpush or nxapush (this one comes with the agent).

So imagine that on the node where log monitoring is set up we have push DCI with parameter "log_stats". In the EPP rule that reacts to our log monitoring event we can have the following filter script:
dci_id = FindDCIByName($node, "log_stats");
if (dci_id > 0) PushDCIData($node, dci_id, $event->$1);


It's called "filter scrip" as original idea is that EPP rule is processed or not depending on what that script returns. But we can just use this script to do some operations that we need. What we do - we just send the value from first parameter of the event into that push DCI. So we now have some historic data in this DCI.

There is a flaw in this approach - the values are only updated when log file has new matches. If there are no new matches, the DCI will get stuck with the last value. We can fix this by scheduling some action that would send 0 into our push DCI after 24 hours - but this won't be exactly correct - e.g. if we had one match 12 hours ago and another just now, then after 12 hours the value should drop from 2 to 1.

2) The other approach is to do the same job that agent does, when counting matches within specified time window, on the server. For this we need to store a list of unix timestamps when new events come (again from script in EPP rule). Then periodically (can just use a script DCI) we need to count timestamps that fit within 24 hour time window and delete older timestamps from the list. The list could be stored in a mapping table (it's a global place to store things) or just in custom attribute on the node as comma-separated string with unix timestamps.

I can give more detailed instructions if you decide to use this approach.
Feel free to ask if you need more detailed explanations on the above.