Difference between revisions of "4.2.4 Upgrade"
m (Formatting fixes)
|Line 48:||Line 48:|
Latest revision as of 15:43, 21 November 2013
Upgrading to Zenoss 4.2.4
I found the instructions for performing an upgrade to 4.2.4 were rather diffuse.
There are some comments on the wiki page here - Install Zenoss
The main instructions are in the installation guide which you can get which is referenced on the above page - Zenoss Core 4 Installation Guide
These instructions say you need to install the new utility called ZenUp (which I believe is still beta code at August 9th 2013). It references the Zenoss Service Dynamics ZenUp Installation and Administration manual (and this is not a hyperlink) and obviously is less than appropriate for Core users; however, there is a good ZenUp reference here on the wiki at ZenUp.
I started from a community script installation of Zenoss 4.2.3 on CentOs 6.3. Start from Chapter 5 of the installation Guide. These are my comments / updates on those instructions.
- The upgrading instructions in Chapter 5 start with "Remove all ZenPacks not developed by Zenoss"! Core installations will almost certainly have non-Zenoss ZenPacks installed. I understand that Zenoss cannot test all the community ZenPacks but simply removing such is not acceptable. For a ZenPack that introduces new object classes and device classes, its removal will also remove any device instances in those classes - this should at least be made clear. Perhaps we (the community) should build a list of those ZenPacks that DO survive an upgrade - I have started one here ZenPacks and upgrading to 4.2.4 - please add to it. I suggest starting with a well-backed-up system and attempting the upgrade without removing ZenPacks.
- You should definitely have taken a Zenoss backup before you get to upgrading but..... there is a bug with 4.2.3 that prevents zenbackup from running cleanly. The fix (as the zenoss user) is:
- mysql -u root
- GRANT SELECT ON mysql.proc to zenoss;
- additional notes to the ZenUp wiki item:
- Installing ZenUp creates a zenup user with a home directory of /home/zenup
- The zenup utility is installed under /opt/zenup/ under the bin directory so any zenup command run as the zenoss user needs to be:
- /opt/zenup/bin/zenup <parameter>
- rpm commands all have the --nodeps parameter which I feel is dangerous. Omitting this shows what will be broken. In my case, it was only the installed Zenoss so went ahead with the --nodeps override
- Note that I had postfix installed which ended up broken but before the second upgrade I did, I found that postfix was already broken before starting!
- On checking for installed java, I had jre-1.6.0_31-fcs.x86_64 (which I assume is not correct?? so I removed it)
- Accessing both the Java code and MySQL requires an Oracle login id
- The Installation Guide says to get MySQL components at the 5.5.31 version. I couldn't find these and ended up with 5.5.33. It seems OK. The link that you actually need is mysql download. Make sure that you get the correct OS version. I found it a rather quirky site.
- One of my 4.2.3 installations did not stop the mysql processes with "service mysql stop". I finally killed them all, as root, with kill -9 <process id>
- All the chkconfig commands didn't need doing - the correct values were there from the previous installation. Use "chkconfig --list" to check
- I have no idea what "Redis" is that you need to install
- redis can be found in EPEL. It isn't used by core 4.2.4... yet, there's a feature coming in an RPS, we're using it for a new flap detection system in 4.2.5 and it'll be used heavily in the event processing system in 5.x. You can install redis by:
# yum --enablerepo=epel install redis
- When you finally run "service zenoss start" it finds a migration flag and runs a load of extra stuff.
- This includes installing all the zenoss ZenPacks - which is really annoying if you are starting from a 4.2.3 script installation which allowed you NOT to have all the standard ZenPacks
- If you are starting from a 4.2.3 script install then you probably have 'good' passwords in $ZENHOME /etc files - global.conf, hubpasswd, some collector .conf files.
- The upgrade will set the hubpasswd file to admin:zenoss which will conflict with everything else
- Symptoms of problems are that no performance data is collected and there are error messages in many of your collector log files
- No service named 'EventService': ZenHub may be disconnected
- - even though all daemons are running, they are not talking to each other!
- There is a reference to this on this wiki install page but the instructions here seem backwards. It suggests you make everything match your stupidly simple password in hubpasswd
- The better solution is to modify $ZENHOME/etc/hubpasswd to match the good password you have in global.conf
- Any directories that you have created under $ZENHOME WILL be preserved
- Any Zenoss Core files that you have modified will NOT be preserved (I had modified 4 files to fix the MIB Browser ZenPack. My backups of these files were still there though).
Other than that, it all worked a treat!