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
8) 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
Quote from: Victor Kirhenshtein on November 17, 2009, 01:06:53 PM
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! :)
Sorry about last paragraph (where agent version mentioned), it could mislead
it is obvious, agent version does not makes any sense - problem is in OS environemnt, for sure
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
Uff, sorry - i was busy with some other tasks...
I have cured another one machine (gcc-c++ wasn`t installed), so there is only one left. Right the one we are talking about :)
zipped config.log attached (zipped because vanilla txt larger than 256kb)