Expect there are a lot of different approaches. What we do here is build each version into a release tree and have some symlinks to ease the transition.
Assuming /opt is the overall installation directory, would have
/opt/xymon4.3.12 (current version) /opt/xymon4.3.17 (new version)
/opt/xymon which is a symlink to whichever version want to have active. This symlink value is what is used in any Xymon state jobs and in the web server configuration.
/opt/data is the Xymon data directory - the /opt/xymon4.3.12/data and /opt/xymon.4.3.17/data are symlinks to /opt/data.
The point is by stopping a particular Xymon version and rebuilding the /opt/xymon link to a version, the new version can be started up with possibly no change required in the web server configuration files (assuming no new/changed web content). The data directory under either directory is a symlink over to the actual data directory so no changes are required there.
If the xymon4.3.17 goes off the rails for something, shut down the web instance and the xymon instance, relink back to the older xymon version and restart the xymon and web instance. Assumption is that there is web configuration is the same for both Xymon versions - may need different web configurations to be instantiated for each Xymon release.
We ~typically (is there ever such a case....) build the new release in an adjacent directory tree and then run a check script in the directories of interest that checks for files missing in the new release and differences in the non-binary files between the releases. The check script is run in directories such as server/bin, server/etc, server/ext to see what old components need to be brought over into the new release, what changes may need to be added into the new components. The check script is not meant to handle changes required in the C sourcecode to maintain some site specific setting that is not part of the Xymon code baseline. The check script is mainly to identify missing binaries and missing scripts/changes in configuration files.
You really need some kind of check tool that can scan the sensitive directories for your site specific changes to make sure they don't get missed in being incorporated under the new Xymon release. You may want to add perm/ownership checking too between the versions. Have been caught out with a installation umask resulting in too restrictive an access on a new release.
From: Xymon [xymon-bounces at xymon.com] on behalf of Kris Springer [kspringer at innovateteam.com] Sent: Tuesday, May 27, 2014 11:09 AM To: Xymon MailingList Subject: [Xymon] how to upgrade
Maybe I’m missing something but I can’t seem to find any info on how to actually perform an upgrade on the xymon server. I’m using v4.3.12 and would like to use the latest version so I can have more customization on the info and trends icons. I’ve never actually done an upgrade before, just fresh builds. What are the steps?
Thank you.
Kris Springer