zipped config.log attached (zipped because vanilla txt larger than 256kb)

config.zip

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

MM.. seems so.Added to attachment.
Configure goes with OK, but make messes. Undefined references in libnetxms.so
I googled a bit and installed glibc-devel. Then I tried export LIBS=-ldl && ./configure... - both did not helped

This log is from another one machine (agent - 0.2.15 ). So, at this moment I have 2 machines with same error NetXMS console shows.

Heelp!

nxagentupdate.log

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.

@ctxm said in Centralized agent upgrade feature:

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

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

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.

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

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

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?

Stu..

Best regards,
Victor

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?

Thanks for the speedy reply. That solved the issue

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

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
8. choose "deploy"
9. Select the nodes you want to upgrade by holding CTRL key

That should do the trick 

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