NetXMS Support Forum

Hello, Victor!

I've read in manual about centralized agent upgrade feature, but I cannot find any reference to how exactly it can be done?
Also, it would be very helpful if such features as Agent Packages and Agent Configurations were documented.

Hi Victor,

Need some inputs here. I need to use the feature of Centralized Upgrade as manually upgrading the agents would be a pain.

Hi, I use this feature as well so maybe I can be of some assistance.

1) Download "NetXMS agent installer" from https://www.netxms.org/download/
2) Download the appropriate NPI file for your agent installer
3) Go to Control Panel - "agent packages"
4) Right click, choose "install"
5) Browse for appropriate NPI file
6) Agent package should be added to package manager now
7) Right click on the package you want to distribute
choose "deploy"
9) Select the nodes you want to upgrade by holding CTRL key

That should do the trick 

Thanks Xenth. When I try to do that it give me Input/Output Error after selecting the NPI file. I've download the latest one.

Hi!

NPI file is just a reference to actual package file. You should have it as well in the same directory as NPI file. Open NPI with any text editor and see what package file is required.

Best regards,
Victor

Victor,

Thanks for the speedy reply. That solved the issue :-)

I have a differentissue, but related to this.

When I go into pacjage manager (empty) I go to Install, choose the latest version , click ok, then get
"Unable to Install package: Package already exist on server"
But the Package manager is blank, so cannot deploy.

Any ideas?

Try to remove all files from <install_prefix>/share/netxms/packages

Best regards,
Victor

Thanks that worked a treat.

Stu..

I have did as written in an instruction provided at this topic, but did not succeed

1. Took this:

UNIX source package
nxagent-0.2.31.apkg
nxagent-0.2.31.npi


2. Agent, tried to upgrade:

NetXMS agent 0.2.16
Linux-i686
Linux $hostname 2.6.20-1.2952.fc6 #1 SMP Wed May 16 17:59:13 EDT 2007 i686

I have seen deployment and even installing process (I mean, green play button and word "installing" in a status column). And then an error:
"Agent`s version doesn`t match package version after upgrade"



In the same time, I was able to update another one agent with a version 0.2.26. Does it mean, there is some "too old to be upgraded centralised" agent versions, which need to be recompiled manually, or described problem has some other nature? in case it is, which version of agent starts to be too old?

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

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

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.
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.

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

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