Description

Installs and configures a Zenoss server with the zenoss::server recipe.

LWRPs are available for installing ZenPacks, zenpatches, loading devices and users and running zendmd commands.

Requirements

Core 4 is not available in a 32 bit distribution. You will need to ensure you are running on a 64 bit machine

Important Information

CAUTION. Version 2.0.0 of this cookbook represents a large number of changes. Please refer to the change log of a list of breaking changes. You should not run 2.0.0 of this cookbook against an existing Zenoss installation without careful planning, and lots of TESTING, TESTING AND MORE TESTING

Core 4 is now the default version that will be installed. If are currently using an older version of this cookbook to manage a Core 3 installation please refer to the upgrading section below.

Core 4 introduces alot of new dependencies. In an attempt to keep all Zenoss clients from needing to carrying the burden of all these dependencies the zenoss::client recipe code has been moved to a a new dedicated zenoss_client cookbook cookbook. In an attempt to reduce the impact the zenoss::client recipe still exists however it is simpler a wrapper that will call zenoss_client::default

Attempts were made to preserve the Core 3 code base with as few alterations as possible. Very few changes were made to any of the supporting LWRPs. The goal is that with a few run_list changes existing users should be able to continue managing their 3.x installations, however it will require care, planning, and testing. Please refer to the section on upgrading below.

Upgrading

Every upgrade scenario is unique in it is own way so your mileage may vary, and you should test your upgrade on a pre-production configuration first.

If you intend to continue to manage your existing Core 3 installation using this new version, you should take the following steps:

• Set node['zenoss']['server']['version'] to "3.2.1-0" using a normal or override level. Don't set it in any of the default levels
• The server recipe now contains a small bit of new logic to dispatch execution to the proper version specific recipe. This should continue to be backward compatible however if you'd like to steer clear of this logic, you can replace zenoss::server with zenoss::server3 in your node's run_list.

Roles

The example roles in the zenoss/roles directory should be loaded for use, refer to the Roles subsection.

Support Matrix

With the release of Core 4 came a reduction in the number of support platforms that Zenoss will on. As its made available on other platforms this cookbook will hopefully keep up. To make things a little easier the following table should help to Identify what versions are supported on which platforms

>

	Core 4	Core3
Ubuntu 10.04		X
RHEL/Centos 5	X	X
RHEL/Centos 6	X

Attributes

Attributes are under the zenoss namespace. The number of attributes are starting to grow, so they are getting sub divided and in some cases getting put into a separate file where it makes sense. The attribute files themselves are self documented and rather than try and keep a large amount of attribute documentation in sync, please refer directly to the attribute files.

Attributes that independent of the Zenoss version are in the default.rb file. Attributes that are specific to Core 4 are stored are in the core4.rb file

Resources/Providers

zenbatchload

This LWRP builds a list of devices, their Device Classes, Systems, Groups, Locations and their properties and populates the zenoss::server with them.

zendmd

This LWRP takes a command to be executed by the zendmd command on the Zenoss server. Examples include setting passwords and other changes to the Zope object database.

zenpack

Installs ZenPacks on the zenoss::server for use for extending the base functionality.

zenpatch

Installs patches on the zenoss::server based on the number referenced in the ticket.

Recipes

Default (default.rb)

The default recipe is essentially unused, but it is intended to handle setting up things that might be required to leverage the LWRPs this cookbook provide. If you are not using this cookbook to manage a server installation, then you should add this cookbook to your nodes run_list to ensure in future versions you'll continue be able to leverage the LWRPs.

Client (client.rb)

Usage of this recipe is deprecated. The recipe exists for backward compatibility. You should replace references to this recipe with zenoss_client::default

Server (server.rb)

The server recipe should be considered your main entry point into this cookbook. It will make some decisions based on your configuration and dispatch execution to the necessary recipes in the cookbook. For the most part the rest of the recipes in this cookbook shouldn't get added directly to your node's run_list unless you have a very compelling reason to do so.

Configure Admin User (configure_admin_user.rb)

This recipe is used to set some meta data around your admin user.

Warning: This recipe is currently not idempotent due to its usage of the zenoss_zendmd resource. A future release to aim to make this idempotent.

Configure SMTP Settings (configure_smtp_settings.rb)

This recipe is used to configure SMTP settings in your Zenoss server installation allowing your Zenoss server to send email notifications.

Warning: This recipe is currently not idempotent due to its usage of the zenoss_zendmd resource. A future release to aim to make this idempotent.

Core 4 (core4.rb)

This is the work horse recipe for installing Core 4 on a node. This recipe is automatically invoked when you request a Zenoss version of 4.x be installed

Core 4 Performance Tweaks (core4_performance_tweaks.rb)

NOT USED. This recipe is currently not used, but exists to express intent. The current code inside relies on some direct file edit nastiness. Future versions of this cookbook intend to make this a usable and idempotent recipe

Java (java.rb)

This recipe wraps the java::default recipe. It will setup some node attributes used by the Java cookbook and then call it.

MySQL 5.5 (mysql55.rb)

At the time of this writing the community MySQL cookbook didn't handle installing MySQL 5.5 on RHEL. This recipe will ensure a version of MySQL gets installed that is compatible with Zenoss Core 4. NOTE On some RHEL systems postfix is installed and depends on an early version of mysql which will get removed which results in postfix getting removed as well. If want to keep postfix on the node you will need to install it after mysql has been upgraded.

Post Installation (post_install.rb)

This recipe will run any post installation tasks that will make installing Zenoss Core 4 a little easier. Right now this simply sets a flag so you can skip the new setup wizard the first time you access the Zenoss UI.

Redis (redis.rb)

With the release of 4.2.4 Zenoss Core now requires Redis. This recipe performs a simple check to determine what version you are installing and if its needed Redis will be installed via the redisio cookbook.

RRD Tool (rrdtool.rb)

Zenoss is pretty particular around the version of RRD Tool that it needs. This recipe ensures you get the exact version that Zenoss wants to have.

Server 3 (server3.rb)

This is for the most part the unaltered code of the server recipe before this cookbook was updated to support Core 4. The server recipe will call this recipe if you have requested a 3.x installation.

SSH Key Configuration (ssh_key_config.rb)

This recipe will handle setting up an SSH Key pair for your Zenoss server.

Data Bags

Create a users data bag that will contain the users that will be able to log into the Zenoss server (members of the 'sysadmin' group). The admin user is automatically provided. Zenoss-specific information is stored in the zenoss hash. Passwords may be set or left out. Multiple roles may be set; the choices with Zenoss Core are Manager, ZenManager, ZenUser or empty. Users may belong to User Groups within Zenoss (listing them here will create them). Example user data bag item:

{
"id": "zenossadmin",
"groups": "sysadmin",
"zenoss": {
  "password": "abc",
  "roles": ["Manager", "ZenUser"],
  "user_groups": ["managers"],
  "pager": "zpager@example.com",
  "email": "zemail@example.com"
  }
}

Two example data bags are provided and may be loaded like this:

knife data bag create users
knife data bag from file users cookbooks/zenoss/data_bags/Zenoss_User.json
knife data bag from file users cookbooks/zenoss/data_bags/Zenoss_Readonly_User.json

Roles

This cookbook provides a number of example roles for mapping attributes to Zenoss Device Classes, Groups and Locations. There is also a role called "ZenossServer" that may be used to configure the Zenoss server for convenience. These roles may be loaded like this:

knife role from file cookbooks/zenoss/roles/Class_Server-SSH-Linux.rb

Device Class Roles

• Roles intended to map to Device Classes set the attribute [:zenoss][:device][:device_class]. This is an override_attribute on the role.
• Roles may set default attributes for [:zenoss][:device][:modeler_plugins], [:zenoss][:device][:templates] and [:zenoss][:device][:properties] to be applied to the Device Class.
• The name for the role is unused by Zenoss.
• Nodes may only belong to a single Device Class, nodes that belong to multiple Device Class roles will have non-determinant membership in a single Device Class.

Location Roles

• Roles intended to map to Locations set the attribute [:zenoss][:device][:location]. This is an override_attribute on the role.
• Location roles may set the have [:zenoss][:device][:address] attribute for the Google map address. If you are using a newline, make sure it is entered as \\n in the role. This is an override_attribute on the role.
• The name and the description for the role map to the name and description of the Location.
• Nodes may only belong to a single Location, nodes that belong to multiple Location roles will have non-determinant membership in a single Location.

Group Roles

• The roles in organization will populate the Groups on the Zenoss server.
• The Device Class and Location roles will not be added to Groups.

Usage

IMPORTANT Zenoss relies on Oracle's Flavor of Java. This requires you to accept the license agreement but setting a value of true for the node attribute ['java']['oracle']['accept_oracle_download_terms']. You can read a bit more about this in the details of the Java cookbook

For a Zenoss server add the following recipe to the run_list:

recipe[zenoss::server]

This will allow device nodes to search for the server by this role. Devices are currently added by their external IP addresses, which is effective in hybrid clouds but you may want to modify this for environments in a single platform (ie. EC2-only). Check the providers/zenbatchload.rb for this setting. Running chef-client --log_level debug on the server node will show the calls for zendmd and zenbatchload commands.

To register a device for monitoring with Zenoss on a client node:

include_recipe "zenoss::client"

Any Properties that need to be set are exposed as attributes on the node and the Roles used by this cookbook.

Zenoss has the concept of Devices, which belong to a single Device Class and Location. Chef nodes implementing the zenoss::client recipe become Zenoss Devices and the Device Class and Location roles may be used for placing in the proper organizers. Zenoss also has Groups and Systems which are essentially ways of tagging and organizing devices (and devices may belong to multiple Groups and Systems). Searches for nodes that belong to other roles will populate the Groups. Searches for nodes applying recipes are used to populate the Systems.

If you are monitoring devices running on Amazon's EC2 with Zenoss, you will need to allow ICMP ping from your Zenoss server.

Because of limitations in zenbatchload, changing settings after initial configuration may not persist. This will be revisited with the upcoming Zenoss 4.x release (COO-895).

License and Author

Author:: Matt Ray matt@opscode.com
Author:: David Petzel davidpetzel@gmail.com Contributor:: Stephen Figggins stephen.figgins@gmail.com

Copyright:: 2010, Zenoss, Inc
Copyright:: 2010, 2011 Opscode, Inc

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.