[xymon] Thinking of updating my existing "Hobbit" install to latest "Xymon" 4.3.0... Any gotchas?

[Henrik Størner]

In <331017F712744D868DFB84F70E739435 at sebdev> "SebA" <spa at syntec.co.uk> writes:

>I hear a new Xymon beta of 4.3.0 is not far away 

Correct, the code currently in the Subversion archive is very close to
what will be the next beta release, with one possible (large) exception - 
see below.

>so I'm thinking of updating
>my existing "Hobbit" install (running old "Hobbit Monitor 4.3.0-0.20080929"
>from subversion) to latest "Xymon" 4.3.0 from subversion...  Any there any
>known gotchas relating to:

>1.	updating an existing install (done that before, but it's been a
>while)
I don't think you should have any major problems upgrading to the current
SVN code. The menu system has changed, so if you are using non-standard
entries in your menu, then these will have to be ported over to the new
menu-definition in ~xymon/server/etc/xymonmenu.cfg

>2.	the name change from Hobbit to Xymon
Should be transparent, but see below.

>3.	changes that have been made between these two releases
See the Changes and RELEASENOTES file.

>4.	anything else
I am currently pondering whether to do the complete change from the
old BigBrother/bbgen/hobbit names spread around the code to Xymon.
I think now is a good time to do it, because it has been so long
since the last beta-release. So the next release will have some
major changes, and we might as well go all the way and get this
done now.

But it means a lot of renaming and shuffling around. Configuration
files, programs, web templates, configuration settings ... almost 
everything gets renamed. So it is going to be somewhat painful,
even though it would be possible to automate much of the porting
over of the old settings.

I have a test-area at 
https://xymon.svn.sourceforge.net/svnroot/xymon/sandbox/henrik/renaming
where this is currently underway - this has the same code as the
current 4.3.0 branch, but with quite a bit of the renaming implemented.

>And what gotchas are there likely to be, what do I need to look out for,
>test, etc.?  Is it wise to backup my existing install first 

I would always recommend having a backup of your system before doing
an upgrade. Not necessarily the data-directory, but everything else.
It fits into a tar.gz file nicely, and makes restoring much simpler.

You don't have to backup all of the histlogs- or hostdata-files.

>If there are likely to be a lot of update issues, are there any plans to
>document the update process, and/or produce an update script to help the
>process?  
It will be documented. Some automation of carrying over the old config
into the new names for all of the config settings will be needed, and
the file renaming can also be automated. So I will probably do that,
if we decide to do the full renaming now.

>I'm also aware that filing bug reports (or feature requests on features that
>don't quite work as they should in my book, but are not really bugs either)
>on a 2 year old version is less than ideal!

I would much rather have bug reports on the current code :-)


Regards,
Henrik