NetXMS Support Forum

Hi!

It's really difficult to estimate release time for this feature. We start working on it some time ago (it's called "zoning" in NetXMS), but then development was suspended. In a short time we plan to release stable version 1.0 and focus on developing 1.1 branch. This feature definitely will appear only in 1.1, if I will have enough resources - withing 6 month.

Best regards,
Victor

During some polls server may not close connection to agent gracefully, which cause this error on agent side. We will fix this in next version. For now, you can safely ignore these errors.

Best regards,
Victor

Yes, it could be encrypted, and in that case you should provide correct encryption context. However, if you are not using encryption, you can simple pass NULL.

Best regards,
Victor

CSCP is an old name for NXCP, and it's partially replaces in the code. In latest versions, there are no RecvCSCPMessage() function, only RecvNXCPMessage() - but it's the same function anyway.

Best regards,
Victor

Явно выраженного перекоса в сторону одной из таблиц нет. Можно почистить event log, но это всего лишь 34MB, не думаю что это решит проблему. Попробуйте включить slow query log в MySQL (http://dev.mysql.com/doc/refman/5.1/en/slow-query-log.html) - попробуем посмотреть, какие именно запросы тормозят, и будем их оптимизировать.

Hi!

You should create CSCPMessage object from CSCP_MESSAGE structure filled by RecvNXCPMessage function. After that, you can access to variables inside message via GetVariableXxx methods of class CSCPMessage. If you getting parameter's value from agent, you should be interested in variables VID_RCC - DWORD holding response code, and VID_VALUE - received value as string.

Best regards,
Victor

Hi!

No, it's not possible. We are planning to add this feature in future versions.

Best regards,
Victor

Currently it is not possible. Most likely such feature will be added in one of the next versions.

Best regards,
Victor

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