NetXMS Support Forum

Hello!

You can monitor status of Windows services via agent's parameter System.ServiceState. It should be used as

System.ServiceState(service name)

You can also found discussion about it here: https://www.netxms.org/forum/index.php/topic,166.0.html

Best regards,
Victor

This define is required for porting code to Windows. On Windows, if you want to export function or class from DLL, you should add __declspec(dllexport) to it's declaration. So, on Windows we define LIBNETXMS_EXPORTABLE as __declspec(dllexport) when building DLL, and on other platforms it simply defines to nothing. So, if you are not writing your code for Windows or not writing a Windows DLL you can simply remove this or define to nothing.

Best regards,
Victor

Hello!

I see the following errors:

1. when you sending message to the agent, you give the wrong message size - instead of


send(socketId,&pRawMsg,sizeof(msg),0)


you should use


send(socketId,&pRawMsg,ntohl(pRawMsg->dwSize),0);


2. You use very small receive buffer - sizeof(CSCP_MESSAGE) will be something like 24 to 32 bytes, but incoming message could be much larger. You should use at least 1024 bytes buffer for receiving messages with single parameter's value and much larger if you wish to get lists from agent. We typically use buffers of 256KB. Other option is to receive message header first, check message size, and allocate buffer for received message dynamically.

3. Protocol messages use binary representation of data, so debugging with printf("%s") will not help much. You should print individual fields.

4. For header - there are many errors on different levels. I suggest you to use same declarations as in nms_cscp.h, especially for CSCP_MESSAGE and CSCP_DF structures, because they represents actual data positions in transmission stream. Don't forget to use #pragma pack or you will get incorrect results on some platforms or compilers.


And why you not using already written communication code in libnetxms and libnxsrv? libnxsrv contains ready to use C++ API for communicating with agents, which handles all communication and protocol things and gives you high level API.

Best regards,
Victor

Quite strange - from configure output looks like it was unable to find dlopen. Could you please provide config.log and detailed information about operating system?

Best regards,
Victor

Togda bol'she pohoze na bug. A esli acknowledge ne delat', to terminate srabativaet, ili toze net?

All ServiceCheck.xxx parameters has the same response codes:

0 - success (server was connected and return expected response)
1 - invalid arguments was passed
2 - cannot connect to server
3 - bad server's response

Best regards,
Victor

Quote from: CTXM on November 17, 2009, 04:24:02 PM
As I understand, update procedure sends sourceball, then configures and automakes it on the host. installs it in the same directory where current netxms operates.

Yes, exactly.

Quote from: CTXM on November 17, 2009, 04:24:02 PM
It would be nice to tune/control more this process, because
1. many of admin crews organizes directory structure and compiled soft differently in their environments.
2. configure, make logs could be retreived from server in the same way as nxagent.conf file does

Real example:
We store every compiled soft in form of: /opt/$software_brand-$version
Then we create softlink in form of: /opt/$software_brand-$version <- /opt/$software_brand
So, it just need to be done "ls /opt/" on a server to know main applications or software installed manually.

In case netxms-agent update proceeds remotely, form of $software_brand-$version becomes misleading.

It doesn`t scares us much, but it makes a little hole in our logic. So - it possibly can unsatisfy other teams with larger or more specific or more beurocratic IT organisations.
Even more: in case of tests there could be specially different agent versions keeped. And not only on one single server. I do so, for example.
I have even quickfixed init script to understand version of agent I want to start via second variable passed (/etc/init./netxms start 0.2.26):
...
[ -z "$2" ] || netxmsExec="/opt/netxms-$netxmsVer/bin/nxagentd -c /opt/netxms$netxmsVer/etc/nxagentd.conf -d"
[ -n "$2" ] || netxmsExec="/opt/netxms/bin/nxagentd -c /opt/netxms/etc/nxagentd.conf -d"
...

That`s why I suggest to invent more control in auto-deployment.

There is no difficulty to implement unified control for many different store conventions we can emagine.
Autodeploy destination directory need to be configurable, possibility to retrieve logs, older ver move configurable (some kind of automatic logical or manual suffix addon). Softlink of new location to old location could be created for linux systems because of init scripts.

Yes, there are some room for improvement Thank you for interesting suggestions, I'll take them into consideration.

Best regards,
Victor

Quote from: CTXM on November 17, 2009, 04:17:31 PM
Small addon to instruction:
InstallationServers instruction need to be set in nxagent.conf to be able to deploy package onto agent`s OS using centralised deployment

But in case when there was no InstallationServers instruction provided, I wasn`t able even to EDIT agent`s configuration file from NetXMS server. So, I did this via standart ssh session Is it normal behavior?

Only after I have added meaned parameter pointed the same as MasterServers (is MasterServers same instruction as Servers, or there is some difference?) I was able to edit agent`s configuration

Yes, I forgot to mention that. Agent will accept upgrade packages only from server(s) listed under MasterServers parameter. And InstallationServers is a deprecated synonim for MasterServers.

Agent has three access levels for servers. To gain specific access level, server should be listed under one of thee parameters: Servers, ControlServers, or MasterServers.

Servers - gives read-only access (can get parameters)
ControlServers - read parameters and execute preconfigured actions
MasterServers - full control

Unless your setup has specific security needs, it is recommended to list your NetXMS server under MasterServers.

Best regards,
Victor

Nuzno v pravile, kotoroe sozdaet alarm iz sobitija SYS_IF_DOWN, dobavit' alarm key, skazem IF_DOWN_%i_%1, i dobavit' pravilo na sobitie SYS_IF_UP, gde v pole "alarm" vistavit' "terminate alarm with key" i kak key ukazat' IF_DOWN_%i_%1.

Best regards,
Victor

Hello!

Usually you should be able to upgrade any version of agent. Most likely there are a problem with specific system. Agent installer should left logs in /tmp on target machine - could you please provide them?

Best regards,
Victor

Hello!

Quote from: Aron Schneider on November 17, 2009, 12:17:25 AM
1. How do we disable alerts and notifications of a sys_node_down\sys_node_up status during a set time period?  For example, during the 12am to 4am hours, the majority of our servers go through a restart process.  How do we configure the scheduling so that the email notification of sys_node_down and sys_node_up are not captured over a certain time period?

You can achieve this by adding additional filtering script to the rule. Script for checking if current time is not between 00:00 and 04:00 (04:00 not included) may look like following:


sub main()
{
   now = localtime();
   return now->hour >= 4;
}


Quote from: Aron Schneider on November 17, 2009, 12:17:25 AM
2. How do we configure the email alerts to only send once email every 5 minutes and stop after 4 emails when a sys_node_down event occurs.  In other words, we've created an event processing policy for sys_node_up and sys_node_down for sending an email notification once when an event occurs.  How do we create an email event so that we are notified once every 5 minutes with a max of 4 emails?

There are no easy way to achieve this. However, you can try the following:

1. Create custom event, like NODE_STILL_DOWN;
2. In processing policy, add action that runs a script on server; this script should run nxevent tool four times to post NODE_STILL_DOWN event to server four times with 5 minutes interval, and then exit;
3. Add event processing policy rule for NODE_STILL_DOWN event - it should check if node is still down and if yes, send additional email.

Hope this helps!

Best regards,
Victor

Hello!

It's a bug in configure. I'll fix it and put updated version on web site.

Best regards,
Victor

Сделал очередное теоретическое исправление, NetWare сервера для тестов пока нет. Попробуйте заменить libnxlp.nlm на приложенный - теоретически проблема должна пропасть.

Hello!

In this topic you could find some information about custom trap configuration: https://www.netxms.org/forum/index.php/topic,9.0.html.

As first step in troubleshooting, set server's variable LogAllSNMPTraps to 1 and check if traps are received by server at all.

Best regards,
Victor

Yes, it should work on OpenBSD.

Best regards,
Victor