Centralized agent upgrade feature
-
-
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 -
-
I have did as written in an instruction provided at this topic, but did not succeed
- Took this:
UNIX source package
nxagent-0.2.31.apkg
nxagent-0.2.31.npi- 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 i686I 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 deploymentBut 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- many of admin crews organizes directory structure and compiled soft differently in their environments.
- 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. -
@ctxm said in Centralized agent upgrade feature:
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 deploymentBut 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 controlUnless your setup has specific security needs, it is recommended to list your NetXMS server under MasterServers.
Best regards,
Victor -
@ctxm said in Centralized agent upgrade feature:
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
- many of admin crews organizes directory structure and compiled soft differently in their environments.
- 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 -
@victor said in Centralized agent upgrade feature:
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,
VictorMM.. 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 helpedThis 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!
-
-
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 aboutzipped config.log attached (zipped because vanilla txt larger than 256kb)
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