ZenUp

From Zenoss Wiki
Revision as of 21:46, 2 January 2014 by Hydruid (Talk | contribs)$7

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.

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-dependant Pristine Copy (used as a basis for patch calculations) and ZUP update file.

Step 1

First download the ZenUp package as the root user:

ZenUp: EL5 or EL6

Step 2

Now as the zenoss user download the Pristine Copy and ZUP update file relevent to your version of Zenoss:

Zenoss 4.2.4

Pristine Copy: EL5 or EL6

ZUP:

this fixes the bug referenced below, if you installed SP154 or SP163, PLEASE UPGRADE IMMEDIATELY!

Be Careful! SP174 has a new bug, when a network object is about to be removed a new function is called getMacAddressCache() that gives a NoneType attribute error, because of this objects can not be reclassified, deleted, and sometimes modeling. Confirmed as it was tested on clean Zenoss install also.

Broken:

SP163 October 29, 2013

SP154 October 15, 2013

Bulbgraph.png Note: SP154 and SP163 are not cumulative and assume that you have SP71.

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
# tar --exclude backups --exclude perf --exclude log -czf zenoss_core-4.2.X-SPXXX_backup.[TIMESTAMP].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</console>
$ 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.