NetXMS 3.0 released
-
Just upgraded and have found an issue with SMS.
It created the migrated notification channel but did not work.
I tried to create a new notification channel, but there is nothing to select in the Driver name drop down.
Thanks, Brett.
-
@normalcy said in NetXMS 3.0 released:
In the console, when deploying agent packages with the package manager I'm getting an error status "failed" "Agent's version doesn't match package version after upgrade".
The 3.0 agents seem to be installed on the clients and look to be working (polls work and send back 3.0 agent version) but summary tables show 3.0-2258-gc5516133f2 agent verison, would that be cause of error if 'package version' is something like 3.0-2258 only?
Yes, that is correct.
The next agent release is going to fix that. The hash shouldn't be in the version name anymore.
Alternatively, you can remove the package from package manager, edit your NPI file and re-import it.
In the NPI file, change the "VERSION" line to match the one you're seeing on the agents right now. That way when NetXMS checks post-upgrade, it will find that the version matches what it expects to see. -
@tomaskir said in NetXMS 3.0 released:
@tursiops said in NetXMS 3.0 released:
Just a practical note on this one:
- We have switched from TRE to PCRE as regular expression engine. In most cases this should go unnoticed, but in certain cases regular expressions may stop working or produce unexpected results.
A side effect of this change is that if you are matching a regular expression, even without a capture group, $1, $2, etc. will be reset to null values.
An transform script example of where that might cause an issue:if ( $1 ~= "^Hello\s+World" ) { return $1; } else { return "Something Else"; }In prior versions of NetXMS, if the DCI returned "Hello World", the transform script would have returned exactly that.
With version 3, the transform script will return null.You will need to change your script to something like this:
value = $1; if ( value ~= "^Hello\s+World" ) { return value; } else { return "Something Else"; }Is this a known and expected change or a bug?
This will break A LOT of my NXSL scripts...That was an expected change at the time (we were running the beta) and broke several scripts in our system, hence I thought I'd point this out by giving an example.
I'd recommend going through the scripts prior to upgrading. -
-
@brettmilfos said in NetXMS 3.0 released:
Just upgraded and have found an issue with SMS.
It created the migrated notification channel but did not work.
I tried to create a new notification channel, but there is nothing to select in the Driver name drop down.
Thanks, Brett.
How did you install server? On what platform?
Best regards,
Victor -
-
@tomaskir said in NetXMS 3.0 released:
@tursiops said in NetXMS 3.0 released:
Just a practical note on this one:
- We have switched from TRE to PCRE as regular expression engine. In most cases this should go unnoticed, but in certain cases regular expressions may stop working or produce unexpected results.
A side effect of this change is that if you are matching a regular expression, even without a capture group, $1, $2, etc. will be reset to null values.
An transform script example of where that might cause an issue:if ( $1 ~= "^Hello\s+World" ) { return $1; } else { return "Something Else"; }In prior versions of NetXMS, if the DCI returned "Hello World", the transform script would have returned exactly that.
With version 3, the transform script will return null.You will need to change your script to something like this:
value = $1; if ( value ~= "^Hello\s+World" ) { return value; } else { return "Something Else"; }Is this a known and expected change or a bug?
This will break A LOT of my NXSL scripts...That's complicated issue. Current implementation is a bit messy with $n variables after matching. Consider the following code:
v = "error 43"; if (v ~= "(error|warning) ([0-9]+)") println("Step 1: $1=".$1." $2=".$2); if (v ~= "(error .*|info ([0-9]+))") println("Step 2: $1=".$1." $2=".$2);In NetXMS 2.2 $2 will be equal "43" on step 2, which is kind of misleading. It was because implementation in 2.2 silently skipping unmatched capture groups. Implementation in 3.0 resets all unused $n variables, which has side effect of clearing $1 if there were no capture groups at all. Looks like it was bad decision to use same names for capture groups and script arguments.
I want to gradually clean up inconsistencies in NXSL, and that could lead to break up of some things. I think that for now I can introduce server configuration variable (off by default) that will prevent resetting of unused capture group variables. Also I will introduce separated naming for script arguments and capture groups so scripts could be migrated over time to non-overlapping variable naming. Also for transformation scripts I think it is worth passing raw value not only as first argument to the script but also as global variable, like $rawValue.
Best regards,
Victor -
Good morning.
just upraded to 3.0: more or less all hosts reports this alarm: Status of DCI xxxx (NetXMS Agent: sqlite-hosts) changed to UNSUPPORTED. (seems it comes from "Local Database" template)
just the server itself reports:
- Status of DCI 697 (Internal: Server.ThreadPool.Usage(SYNCER)) changed to UNSUPPORTED
- Status of DCI 696 (Internal: Server.ThreadPool.LoadAverage(SYNCER,1)) changed to UNSUPPORTED
- Status of DCI 695 (Internal: Server.ThreadPool.CurrSize(SYNCER)) changed to UNSUPPORTED
- Status of DCI 694 (Internal: Server.ThreadPool.Load(SYNCER)) changed to UNSUPPORTED
looking at Data Collection Configuration, those DCIs doesn't exists.
Also tried to delete the database (PGSQL) and have a fresh start, but the results is the same.
How can I solve?
thanks alot and best regards
-
@victor said in NetXMS 3.0 released:
That's complicated issue. Current implementation is a bit messy with $n variables after matching. Consider the following code:
v = "error 43"; if (v ~= "(error|warning) ([0-9]+)") println("Step 1: $1=".$1." $2=".$2); if (v ~= "(error .*|info ([0-9]+))") println("Step 2: $1=".$1." $2=".$2);In NetXMS 2.2 $2 will be equal "43" on step 2, which is kind of misleading. It was because implementation in 2.2 silently skipping unmatched capture groups. Implementation in 3.0 resets all unused $n variables, which has side effect of clearing $1 if there were no capture groups at all. Looks like it was bad decision to use same names for capture groups and script arguments.
I want to gradually clean up inconsistencies in NXSL, and that could lead to break up of some things. I think that for now I can introduce server configuration variable (off by default) that will prevent resetting of unused capture group variables. Also I will introduce separated naming for script arguments and capture groups so scripts could be migrated over time to non-overlapping variable naming. Also for transformation scripts I think it is worth passing raw value not only as first argument to the script but also as global variable, like $rawValue.
Best regards,
VictorThe problem here is that there are likely thousands of scripts all around the Forums, Wiki and the internet that this change breaks.
Every single one would have to be updated - which is unrealistic.
For new users who find some regex-based scripts on the internet, they will not work, and they don't know why.Existing implementations (scripts) will start working differently upon upgrade, without any knowledge of the system operators
This will be VERY difficult to track down, as this will not produce script errors, rather things will just work differently.
This means there can be a threshold script which will "pretend" to still work, but in reality will not work.
It puts burden on system operators to review every script they have upon upgrade to check if it still works properlyWhat I personally would propose:
There are far less scripts using regex capture groups than just regex.
So if a change is needed, only regex capture group should be changed, without affecting regex operations without capture groups (as is the case now).What about capturing regex returning arrays with captures?
matchArrray = "test" ~= "t(e)(s)t"; println(matchArrray [0] . matchArrray [1]); for (match : matchArrray) { print(match); }This would clean up the reuse of $1, $2, etc. without breaking ALL regex handling.
The change would only affect a smaller part of community, so less impact. -
@vir_db said in NetXMS 3.0 released:
Good morning.
just upraded to 3.0: more or less all hosts reports this alarm: Status of DCI xxxx (NetXMS Agent: sqlite-hosts) changed to UNSUPPORTED. (seems it comes from "Local Database" template)
just the server itself reports:
- Status of DCI 697 (Internal: Server.ThreadPool.Usage(SYNCER)) changed to UNSUPPORTED
- Status of DCI 696 (Internal: Server.ThreadPool.LoadAverage(SYNCER,1)) changed to UNSUPPORTED
- Status of DCI 695 (Internal: Server.ThreadPool.CurrSize(SYNCER)) changed to UNSUPPORTED
- Status of DCI 694 (Internal: Server.ThreadPool.Load(SYNCER)) changed to UNSUPPORTED
looking at Data Collection Configuration, those DCIs doesn't exists.
Also tried to delete the database (PGSQL) and have a fresh start, but the results is the same.
How can I solve?
thanks alot and best regards
You van safely ignore them. It is cosmetic issue in default templates, we will fix that in next patch release.
Best regards,
Victor -
-
Plugin in grafana repo will be updated shortly.
In a meantime you can update it directly from git.@vir_db said in NetXMS 3.0 released:
Thanks Viktor,
just another issue: seems that the upgrade brok the grafana plugin. I can get alerts, but I cannot collect any graphs (for ex. CPU Usage)
-
Hi Alex,
do you mean this git? https://github.com/netxms/grafanaseems last commit was in june:
Commits · netxms/grafana
Grafana integration module for NetXMS. Contribute to netxms/grafana development by creating an account on GitHub.
GitHub (github.com)
-
-
@tomaskir said in NetXMS 3.0 released:
@victor said in NetXMS 3.0 released:
That's complicated issue. Current implementation is a bit messy with $n variables after matching. Consider the following code:
v = "error 43"; if (v ~= "(error|warning) ([0-9]+)") println("Step 1: $1=".$1." $2=".$2); if (v ~= "(error .*|info ([0-9]+))") println("Step 2: $1=".$1." $2=".$2);In NetXMS 2.2 $2 will be equal "43" on step 2, which is kind of misleading. It was because implementation in 2.2 silently skipping unmatched capture groups. Implementation in 3.0 resets all unused $n variables, which has side effect of clearing $1 if there were no capture groups at all. Looks like it was bad decision to use same names for capture groups and script arguments.
I want to gradually clean up inconsistencies in NXSL, and that could lead to break up of some things. I think that for now I can introduce server configuration variable (off by default) that will prevent resetting of unused capture group variables. Also I will introduce separated naming for script arguments and capture groups so scripts could be migrated over time to non-overlapping variable naming. Also for transformation scripts I think it is worth passing raw value not only as first argument to the script but also as global variable, like $rawValue.
Best regards,
VictorThe problem here is that there are likely thousands of scripts all around the Forums, Wiki and the internet that this change breaks.
Every single one would have to be updated - which is unrealistic.
For new users who find some regex-based scripts on the internet, they will not work, and they don't know why.Existing implementations (scripts) will start working differently upon upgrade, without any knowledge of the system operators
This will be VERY difficult to track down, as this will not produce script errors, rather things will just work differently.
This means there can be a threshold script which will "pretend" to still work, but in reality will not work.
It puts burden on system operators to review every script they have upon upgrade to check if it still works properlyWhat I personally would propose:
There are far less scripts using regex capture groups than just regex.
So if a change is needed, only regex capture group should be changed, without affecting regex operations without capture groups (as is the case now).What about capturing regex returning arrays with captures?
matchArrray = "test" ~= "t(e)(s)t"; println(matchArrray [0] . matchArrray [1]); for (match : matchArrray) { print(match); }This would clean up the reuse of $1, $2, etc. without breaking ALL regex handling.
The change would only affect a smaller part of community, so less impact.I've changed regexp expressions to return array with capture groups instead of boolean value. It still sets $n variables for compatibility but does not erase unused variables (so if there is no capture groups in regexp $1 will be left intact). As a side effect it is now possible do directly access capture group from regexp. For example the following code
text = "error 43"; errorCode = (text ~= "error ([0-9]+)")[1]; println(errorCode);will print 43.
Best regards,
Victor -
@vir_db said in NetXMS 3.0 released:
Hi Alex,
do you mean this git? https://github.com/netxms/grafanaseems last commit was in june:
Commits · netxms/grafana
Grafana integration module for NetXMS. Contribute to netxms/grafana development by creating an account on GitHub.
GitHub (github.com)
I reported an issue on GitHub https://github.com/netxms/grafana/issues/3
-
@victor said in NetXMS 3.0 released:
@brettmilfos said in NetXMS 3.0 released:
Just upgraded and have found an issue with SMS.
It created the migrated notification channel but did not work.
I tried to create a new notification channel, but there is nothing to select in the Driver name drop down.
Thanks, Brett.
How did you install server? On what platform?
Best regards,
VictorHi Victor,
Updated from 2.2.17 server 2k8r2 with existing generic SMS.
Cheers, Brett.
-
Hi,
I've found bug in Windows installer. Try to rename directory C:\NetXMS\lib\ncd to C:\NetXMS\lib\ncdrv and restart NetXMS Core service.
Best regards,
Victor -
@victor said in NetXMS 3.0 released:
Hi,
I've found bug in Windows installer. Try to rename directory C:\NetXMS\lib\ncd to C:\NetXMS\lib\ncdrv and restart NetXMS Core service.
Best regards,
VictorHi,
That fixed the issue of not finding the DriverName.
Checking the logs the generic driver finds the device OK, but when I try to send a notification it says it cannot send the notification as there is no such channel name.
Cheers, Brett.
-
Hello,
I am using the debian repository, (http://packages.netxms.org jessie/main amd64 packages ) but it is not pickup version 3.0 .. is this not push jet ?
or is there a other repository ?
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login