ZenUp
Contents
About Zenup
Zenup is the new Zenoss patch manager. New patches are provided for both the Core, and Commercial products at intervals that fix bugs which don't require large internal fixes in Zenoss. Larger internal fixes will wait for a subsequent release.
You can see the patch level of your install with the following command:
$ zenup status Home: /opt/zenoss Revision: 0 Upgrading: 457 Last Attempted Step: post/install_mibs Updated On: Wed Sep 9 14:23:06 2015
Getting ZenUp and patches
As the users listed below download the appropriate files for your version of RedHat/CentOS. You will need to download the ZenUp package and version-dependent Pristine Copy (used as a basis for patch calculations) and ZUP update file.
To see changes introduced by a ZenUp package, use the zenup command. For example:
$ zenup info --showall zenoss_core-4.2.5-SP457-zenup11.zup $ zenup info --showall zenoss_core-4.2.5-SP457-zenup11.zup | grep +++ $ zenup info --showall zenoss_core-4.2.5-SP457-zenup11.zup | egrep -A3 "^.ZEN-"
Step 1
First download the ZenUp package as the root user:
Note, you can check the version of zenoss you are using by going to Settings --> Versions
Step 2
Now as the zenoss user download the Pristine Copy and ZUP update file relevant to your version of Zenoss:
Zenoss 4.2.5
Note that the Zenoss updates page at SourceForge is at Zenoss Updates
Note: use Zenup 1.1 above
- SP671 ZUP File Feb 26, 2016 (USE ZENUP 1.1 ABOVE! - latest SUP as of April 25th, 2016)
- SP457 ZUP File Apr 4, 2015 (USE ZENUP 1.1 ABOVE!)
- SP203 ZUP File Aug 6, 2014 (USE ZENUP 1.1 ABOVE!)
- SP167 ZUP File June 19, 2014 (USE ZENUP 1.1 ABOVE!)
- SP150 ZUP File March 21, 2014 (USE ZENUP 1.1 ABOVE!)
- SP136 ZUP File May 22, 2014
- SP105 ZUP File April 29, 2014
Zenoss 4.2.4
ZUP: (Note, ZUPs are cumulative, you do not need to install each one in order)
- SP464 ZUP File April 3, 2014 (Current)
- SP445 ZUP File March 21, 2014
- SP409 ZUP File March 4, 2014
- SP405 ZUP File February 26, 2014
- SP383 ZUP File February 7, 2014
- SP367 ZUP File January 23, 2014
- SP336 ZUP File January 8, 2014
Broken:
- SP174 November 13, 2013
- SP163 October 29, 2013
- SP154 October 15, 2013
Note: For more information see ZUP SP163 breaks zeneventd processing., also confirmed for 154, and ZenUp patching and flapping_interval_seconds.Zenoss Admin Guide.
Older: SP71 ZUP File August 28, 2013 (Historical) SP12 ZUP File July 29, 2013 (Historical)
Zenoss 4.2.3
ZUP:
SP254 ZUP File Aug 9, 2013 (Current)
Older:
SP248 ZUP File Aug 9, 2013 (Historical)
SP153 ZUP File (Historical)
Note: SP153 is considered beta and probably should not be installed in production at all.
Reporting Bugs
To report ZenUp or RPS bugs, please use the process outlined in the Bug_FAQ. Note specifically the version of Zenoss, the version of ZenUp, and the specific RPS that you're applying in any bug reports you file against a system running ZenUp.
Using ZenUp to read a patch
To see the list of fixes in an RPS, run the following
$ zenup info zenoss_core-4.2.3-SP153.zup
Using ZenUp to apply a patch
- Install the ZenUp RPM (as root user)
# yum install zenup-XXX.rpm -y --nogpgcheck
- Create backup of Zenoss Directory (date here uses unix timestamp, to use another date format see 'man date')
# tar --exclude backups --exclude perf --exclude log -czvf zenoss_core-4.2.X-SPXXX_backup.$(date +%s).tgz /opt/zenoss
- Switch to the Zenoss User
# su - zenoss
- Tell Zenup to manage Zenoss Patching
$ zenup init zenoss_core-XXX-pristine-XXX.tgz $ZENHOME
- Confirm that Zenoss is managed by ZenUp
$ zenup status
- Examine differences between Zenoss Folder and a pristine installation (should always be 0 files)
$ zenup diff
- Test run of the patch install
$ zenup install zenoss_core-XXX.zup --dry-run
- Install the patch
$ zenup install zenoss_core-XXX.zup
- This will show you're on the new RPS and will list all the fixes
$ zenup status --verbose
- This should show 0 files modified since the patch. However if you have added any customised files yourself, they may show up here.
$ zenup diff
Troubleshooting
If you run:
$ zenup install --dry-run zenoss_core-4.2.4-SPXXX.zup
And get an error like:
Looking for new migrate scripts to load...
Traceback (most recent call last):
File "/tmp/zenoss-core-4.2.4_he022p/new_zup/generate_script_list", line 116, in <module>
generator.generate()
File "/tmp/zenoss-core-4.2.4_he022p/new_zup/generate_script_list", line 50, in generate
self._openStatusYaml()
File "/tmp/zenoss-core-4.2.4_he022p/new_zup/generate_script_list", line 99, in _openStatusYaml
self.statusYaml = yaml.load(fp)
File "/opt/zenup/python/yaml/__init__.py", line 71, in load
return loader.get_single_data()
File "/opt/zenup/python/yaml/constructor.py", line 37, in get_single_data
node = self.get_single_node()
File "/opt/zenup/python/yaml/composer.py", line 43, in get_single_node
event.start_mark)
yaml.composer.ComposerError: expected a single document in the stream
in "/opt/zenup/var/status.yaml", line 2, column 1
but found another document
in "/opt/zenup/var/status.yaml", line 22, column 1
ERROR: /tmp/zenoss-core-4.2.4_he022p/new_zup/check returned a non-zero exit code: 1.
No changes have been applied to your system
Edit your /opt/zenup/var/status.yaml file and remove the top section that references the older version:
--- !!map { ? !!str "created" : !!str "Tue Nov 12 08:07:07 2013", ? !!str "home" : !!str "/opt/zenoss", ? !!str "id_" : !!str "zenoss-core-4.2.3", ? !!str "lastupdate" : !!str "Tue Nov 12 08:07:07 2013", ? !!str "name" : !!str "zenoss-core-4.2.3", ? !!str "path" : !!str "/opt/zenup/var/zenoss-core-4.2.3", ? !!str "revision" : !!str "", ? !!str "verbose" : !!bool "false", ? !!str "zupfile" : !!str "", }--- !!map { ? !!str "created" : !!str "Thu Nov 14 08:51:55 2013", ? !!str "home" : !!str "/opt/zenoss", ? !!str "id_" : !!str "zenoss-core-4.2.4", ? !!str "lastupdate" : !!str "Thu Nov 14 08:51:55 2013", ? !!str "name" : !!str "zenoss-core-4.2.4", ? !!str "path" : !!str "/opt/zenup/var/zenoss-core-4.2.4", ? !!str "revision" : !!str "", ? !!str "verbose" : !!bool "false", ? !!str "zupfile" : !!str "", }
Run the command again and it should succeed. This seems to happen when an in-place upgrade is performed and it does not clean up status.yaml properly.
