4.2.4 Upgrade

From Zenoss Wiki
This is the approved revision of this page, as well as being the most recent.
Jump to: navigation, search

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!
      • if you specify a remote mail server postfix isn't needed, that said if your remote mail server goes down, how would you know Trelane (talk) 19:29, 14 August 2013 (UTC)
  • 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
      • this should not be the behavior, as long as zenpack_actions.txt is where it should be only those zenpacks should be processed/installed, if you can test/prove that this is not the behavior file a bug and CC me. Trelane (talk) 13:58, 15 August 2013 (UTC)
  • 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!