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