NetXMS Support Forum

Looks like a bug in libtre, we'll look into it.

In meantime you can use this regexp: "^([0-9]+)\s([0-9./]+)\s([0-9]+)\s([0-9A-F]+)\s(.+)$", or a bit more generic: "^([^\s]+)\s([^\s]+)\s([^\s]+)\s([^\s]+)\s(.+)$"

It will disabled build of lm_sensors subagent. System itself will work perfectly well, but you will not be able to collect hardware metrics like temperature and voltages.

There are two options:
1) upgrade lm_sensors to version 3 (API was changed since v2)
2) disabled this subagent using "--disable-lmsensors" argument for configure.

You have incompatible version of lmsensors-dev. Please show output of "rpm -qa | grep sensors"

Migration process is really easy:

1) stop server
2) copy existing netxmsd.conf into netxmsd.conf.old
3) create user and database in new DBMS
4) edit netxmsd.conf – change DBDriver and all other DB* parameters
5) run "nxdbmgr migrate /etc/netxmsd.conf.old"

Quote from: volkoff on January 24, 2015, 09:10:08 PM

Quote from: Alex Kirhenshtein on January 24, 2015, 08:52:45 PM
SQLite never was intended for use in production environment, and we will probably remove support in future altogether.

Well, that's the answer Ok, I'll use other DBMS.

Proper solution is to migrate to any sane DBMS – you can do it using "nxdbmgr" tool, there is special "nxdbmgr migrate" mode.
SQLite never was intended for use in production environment, and we will probably remove support in future altogether.
Main reason for that – a lot of features are not supported in SQLite (lack of ALTER TABLE DROP COLUMN is perfect example) or implemented poorly – and while it's possible to add workarounds, it require time, which we prefer to spend on more critical tasks.

Quote from: volkoff on January 24, 2015, 08:14:29 PM

Quote from: tomaskir on January 24, 2015, 08:00:39 PM
DCI tables do not work with SQLite.
This is a known issue.
As a workaround for now, you can use a different DB.

How terrible I didn't know about that.
But as a guy who do some programming, I'm aware of the fact, that if there is some issue that prevents using of the product you should provide some bugfix rather than "it's a known issue" even for free and open source product
And since I have this particular bug isolated I can provide some (or even all in my case) data to fix it.

Nice catch!
Fixed, will be released in upcoming 2.0-M2.

Quote from: volkoff on January 23, 2015, 06:19:24 PM
Funny bug:
configuration parameter in nxagent ListenAddress actually read backwards.
So instead of 192.168.1.2 you should write 2.1.168.192

У нас сейчас нет свободных ресурсов на бекпорт из 2.0 - насколько это критично?

That's a bug. Filtered indexes (with "WHERE ..." clause) are introduced in SQL Sever 2008.

https://dev.raden.solutions/issues/747

As a workaround - uncheck "initialise database", edit file C:\NetXMS\lib\sql\dbinit_mssql.sql: remove "WHERE ..." part from this "CREATE INDEX" and initialise database by hand:
1) open "cmd" window
2) cd c:\netxms\bin
3) nxdbmgr init C:\NetXMS\lib\sql\dbinit_mssql.sql
4) net start "NetXMS Core"

В скрипте точно нет ошибок? Только что проверил такую конфигурацию:

https://www.dropbox.com/s/ln8ozbzr0wmsoj5/Screenshot%202015-01-20%2023.59.33.png?dl=0
https://www.dropbox.com/s/wbno0ratkx7utqe/Screenshot%202015-01-21%2000.00.16.png?dl=0
https://www.dropbox.com/s/v32zkt9ic7tad4f/Screenshot%202015-01-21%2000.00.59.png?dl=0

А вот если в скрипте сделать ошибку:
https://www.dropbox.com/s/ispi1xg2nsu6lyr/Screenshot%202015-01-21%2000.02.00.png?dl=0

Yep, that's a bug. You can extract these libs from netxms-server package or wait for upcoming 2.0-M2.

https://dev.raden.solutions/issues/744

General answer is "no" - nxsl do not provide any way to do a back resolve. We can add function for that and then it can be implemented quite easily: in EPP, in create alarm /  send notification section – you use %{scriptName} instead of the message (%m, usually), and in this "scriptName"  (from Script Library) you do any transformation you like (extract IP, resolve and combine message back together). You can register feature request in our bug tracker: https://dev.raden.solutions/projects/netxms/.

Right now you can do this kind of a hack:
1) in EPP add "execute external application" as action
2) write script (shell, python, application - anything), which split message, extract IP, do back resolve, compose new message
3) push it back to NetXMS using "nxevent" command line utility. Note, you should use different event for that – or you'll create infinite loop.

Check this section of the guide: https://www.netxms.org/documentation/adminguide/subagents.html#dbquery

User "admin" with id=0 (name doesn't matter, actually – you can change it after installation) is a special case, it have all permissions by default – and it's enforced by the server. This user also can't be deleted. However, you can disable it.

That's weird, you can try to undeploy, stop servlet container, remove working/temp directory and start deploy war file again.