Package Deployment with OpsCenter

There has been some discussion on Constantins blog about working around IPS' scripting limitations.

I don't want to talk about the reasons, why IPS does not have classical pre/postinstall-scripts, but I want to demonstrate how this functionality could be achieved with Oracle's Enterprise Manager OpsCenter.

If you don't know OpsCenter, it's _the_ management tool from Oracle for Solaris, Unbreakable Linux and OracleVM.


OS Updates

In OpsCenter terminology Package deployments are called "OS Updates". OS Updates consist of Update Components (Packages, Patches and Configurations), Update Policies and Update Profiles. If an OS is to be updated, so called "Update Profile"-jobs will be sent to hosts run.

Update Profiles

There are two types of Update Profiles, System-defined and User-defined. What we're looking for are user defined profiles. A user-defined profile contains components. These components can be Packages, Pre/Postinstall-Scripts and Configuration files.

They can also contain macros to be run on the target system to return information about the system. This information can then be used to dynamically create a configuration file. 

It is also possible to run probes, to check if pre-requisites are met.

Update Profiles can also contain other update profiles. (e.g. to create a Mail-Server profile or Web-Server profile)

In the picture we can see two Splunk Profiles. Below you can see some components, like the SMF Manifest or a postinstall script.




















Update Components

Update components are organised into folders:










Configuration Files carry a version number.

Uploading configuration file (-templates) or scripts is simple:
















Running OS Update Job

It is easy to run update jobs on one or several hosts. There are different options that can be set how to run the jobs...























While the job is running and after it's finished the job details can be monitored. Of course it makes sense to have good error handling in the pre/postscript.



















Summary

The examples shown are with SysV packages, as OpsCenter for obvious reasons lacks IPS support at the moment. But it shows how scripts can be run before and after package installation. As an alternative to OpsCenter, the same can be achieved using e.g. Puppet, bcfg2 or cfenginge.

The nice thing about using a management tool is, to compare different systems, find differences and keep them standardized.

Comments

Nico said…
Hab gesehen du kommst aus der Schweiz - hätte paar Fragen zu Solaris - wäre nett wenn dich bei mir melden könntest :)

Gruß
April 4, 2011 at 4:46 PM
Unknown said…
Hallo Nico

Kannst Du mir noch Deine Kontaktdaten im Kommentar zukommen lassen?

(Werde den Kommentar nicht veröffentlichen)
April 5, 2011 at 8:35 AM
Post a Comment

Popular posts from this blog

Heating up the Data Pipeline (Part 1)

Image
Pre-Processing Data I often hear the question from our customers, how data can be transformed prior to indexing in Splunk. Damien from  Baboonbones  has done a tremendous job in creating add-ons   providing custom inputs for Splunk. Most of his custom inputs provide the means to pre-process data by allowing custom event handlers to be written. Sometimes you still want to pre-process data that gets collected from Splunk's standard input types, like file monitors, Windows EventLogs, scripted inputs etc. Also, not everyone is capable of writing custom event handlers. A requirement these customers have, is that they have rolled out a large number of Splunk Universal Forwarders and they do not want to install another agent. To summarize, the solution capable of pre-processing data, should be easy to use, be easily integrated and be build on top of their existing architecture. How to plumb Splunk Pipelines Splunk has its own fittings to connect a Universal Forwar
Read more

Heating up the Data Pipeline (Part 3)

Image
Welcome back to the "Heating up the Data Pipeline" blog series. In part 1 we talked about how to route data from Splunk to a 3rd party system. In part 2 walked through a simple data flow that passes data collected from Splunk Forwarders through Apache NiFi back to Splunk over the HTTP Event Collector. In this part, we will look at a more complex use case, where we route events to an index, based on the sending host's classification. The classification will be looked up from a CSV file. We will make use of Apache NiFi's new Record-Oriented  data handling capabilities, which will look initially a bit more complicated, but once you grasp it, it will make further Use Cases easier and faster to build. High-Level Dataflow We will again start with our ListentTCP input, but this time we will send the data to another Processor Group. The Processor Group will again emit events suitable for Splunk HEC. Note that we have increased the Max Batch Size from 1
Read more

SLOG Latency

Image
After reading Brendan's newest blog entry, I was curious about what kind of slog latency we can see for our data migration load. To remind you, only synchronous writes go into the slog SSD devices. As this is a migration running, we can see mostly NFS write operations: In our configuration the SSD slog is mirrored (HDD4 and HDD8). Hence the same number of IOPS: The next picture shows us the latency for our SDD SLOG Device HDD 4. We can see here that latencies start at 79 us and are mostly under 200 us. There are some outliers, but approx. 95% are under 500 us: This matches quite well with the values Brendan blogged about (137-181 us), which includes NFSv3 latency. For reference (no picture here), we can see latencies of about 170-500 us mostly for NFSv4. By the way. SLOG Devices are mostly one way devices, as shown here. Only if things go really bad, they are read from...
Read more