ZenUp

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

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:

  • Current ZenUp 1.1 EL5 or EL6
  • Old (use for 4.2.3 and 4.2.4) EL5 or EL6

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

Pristine Copy: EL5 or EL6

Bulbgraph.png Note: use Zenup 1.1 above

  • SP671 ZUP File Feb 26, 2016 (USE ZENUP 1.1 ABOVE! - latest SUP as of April 25th, 2016)

Zenoss 4.2.4

Pristine Copy: EL5 or EL6

ZUP: (Note, ZUPs are cumulative, you do not need to install each one in order)

Broken:

  • SP174 November 13, 2013
  • SP163 October 29, 2013
  • SP154 October 15, 2013

Bulbgraph.png 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

Pristine Copy: EL5 or EL6

ZUP:

SP254 ZUP File Aug 9, 2013 (Current)

Older:

SP248 ZUP File Aug 9, 2013 (Historical)

SP153 ZUP File (Historical)

Bulbgraph.png 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.