Evolve OM Unix to OBM: Simple Command Line Tools admins need to know

Super Contributor.
Super Contributor.
2 0 5,236

Guest post written by Martin Recker, Operations Bridge R&D, Micro Focus

 The following is a hypothetical conversation with an admin user of Operations Manager for Unix, as imagined by Martin Recker, former OMU developer.


“I’m an OMU admin and if I assume that sooner or later OBM is going to succeed my good old UNIX tool. So how should I start the journey? I’m up to the challenge, but time and money is really low. Can you give me some ways to quickly build on my OMU know-how? Any memory aids are welcome…”


You’re not alone! Previous posts have explained why it makes sense for admins using Operations Manager (HPOM) for Windows, UNIX, Solaris or Linux to move to Operations Bridge Manager  (previously called OBM),

and the complete story is documented in the Operations Bridge Evolution Guide.

But in this article, let’s concentrate on a few OBM basics for OMU veterans. I will simplify things even more and talk only about nodes, node groups, policies and policy group. The vehicle for our short tour will be the corresponding command line utilities dealing with such artefacts.

“Hang on a second, what is an ‘artefact’ anyway? The OBM doc is full of the word.”

You can translate it to “object” or “item”—it’s nothing special, just a different term.


“And did you just use the words ‘node’, ‘node group’, ‘policy’ and ‘policy group’, even though we’re in the OBM world?”

Yes you’re right. I used these words so you would feel more at home. In OBM, a node is a node configuration item, and a node group is now a view, a policy is a policy template, and a policy group is now called an aspect.


“Okay, so in OMU a node is defined by its nodename. Different nodename means different node. How does it work in OBM?”

Well, it’s quite so easy as in OMU, but look at it this way: your nodebank is now the RTSM (runtime service model), while a node CI is identified by its long fully qualified DNS hostname (primary_dns_name), short hostname (CI name), and its IP addresses. And from OBM 10.01 onwards you get back your opcnode command, now called opr-node. You can add, modify and delete nodes, add or delete its IP addresses, and maybe simpler than with OMU: you can work over node IDs: e.g. when to clean a duplicate node CI:

          opr-node –user user –password password –del_node –ci ciId

And there are many ways that opr-node can filter on nodes in the RTSM. You can even setup your own filters in the OBM UI and run them with opr-node:

         opr-node –user user –password password –list_nodes –filter_name myLinuxBoxes

“You said a nodegroup is now called ‘view’. I have some doubts about that.”

 You’re right. The truth is, a nodegroup is a fixed set of nodes, while a view delivers a group of CIs you get when applying the view’s filter query on the RTSM. For an example, look at the command line tool opr-agt, which should remind you of OMU’s opcragt.
So when typing
       opcragt –status –all,
you now say:

       opr-agt –user user –password password –status –all

     It is identical to:

      opr-agt –user user –password password –status –query_name All_CIs_with_OM_Agents


“Just saw that commands opr-agt as well as opr-node also both have an option –node_group. Why do you then say a node group is like a view, and not a node group is a node group?”

In fact, an OMU node group is also reflected in OBM as a fix set of nodes, a CI collection of nodes. You can use it to control the agents like this:

      opr-agt –user user –password password –stop –node_group myGroup

Or list them using:

      opr-agt –user user –password password –list_agent_nodenames –node_group myGroup

With OBM, you assign configuration to nodes selected through a view. Assignment via node groups is on the enhancement list and may come with a future release.

Therefore from that angle an OMU node group is more like an OBM view still.

“Okay, I’ve got it. So now we’re at policies. For me, as a long time OMU admin, it’s a funny transition from OMU 7 templates to OMU 9 policies and now to OBM policy templates.” 

The difference between an OMU 9 policy and OBM policy template is easy: a policy template is like a form feed in that you fill in some values, leave others with their default. A policy template has editable fields, called parameters, while an OMU 9 policy has none, and OMU 7 templates don’t even have versioning. Parameters and versioning are the central mechanisms to simplify config maintenance. 

“I agree, that’s a big step forward. But how do I get my really valuable policies from OMU to OBM?”

On the OMU side, use command opcpolicy –download –pol_group to download any policy group, or just do a complete download using opccfgdwn. Copy the download directory to OBM and call

      ConfigExchange -user user –pw password -uploadOM -input myDownloadDir

The tool will upload everything it understands — policies, policy groups and instrumentation. It’s best you verify whether the policies should be adapted when used with OBM. For that, call

      ConfigExchange -user user –pw password -check –pf myDownloadDir –logfile myAdaptationHints

“Sounds good, but what about the policy groups? You said a policy group is an aspect. Are you sure?”

Maybe I’ve simplified it a bit too much. An aspect has versioning, also you can set policy parameters on the aspect level, and an aspect has a CI-type dependency. But similar to OMU policy groups, you can link policies and instrumentation to it, it can be hierarchical, and you can assign and deploy it to nodes.

“So why not automatically convert a policy group into an aspect when uploading from OMU to OBM?”

The policy groups are uploaded, just look in the OBM template group UI. But an auto-conversion sounds like too much magic behind the scenes. It’s unlikely that you’d organize your aspects exactly like your policy groups, not with the new possibilities you get with policy and aspect parameters, similar to adjusting to the new paradigm of working CI-centric instead of node-centric. Unlike with OMU, you now can assign config to CI types like databases, instead of being forced to assign it to the node the database is hosted on.

Anyway, starting to work in OMU style is not a bad idea. Over time, you’ll find out where parameters can simplify matters and thereby reduce the number of required policies. Whether to work CI-centric or node-centric is often a question of taste. The more you model your IT environment in the RTSM, the more a CI-centric approach makes sense.

 “I see, but what about task automation – command-line tools to do config assignments? Thinking about OMU’s opcnode —assign_pol_group or opcpolicy –list_pol_assigns?”

We’re not yet there, but working on it. Have a look on the OBM command ConfigWsTool which can do certain assignments, and there will be more to come.


“Ok, so far so good. Now what about the link to the agent. How does one transform assignments into policy deployments?”

First of all, the command line tools ovpolicy and ovdeploy are the same as on OMU. OBM server also has an Operations agent installed, delivering such utilities. Secondly, OBM has a command to deploy the configuration, like OMU’s opcragt –distrib. For example, call:

      opr-agt –user user –password password –deploy -force –node_group myGroup

Besides that, there is only one more thing to keep in mind: Config assignment and config deployment are executed immediately one after the other — at least if you don’t change the default behavior to suspend-mode. And in case of failed or suspended deployment jobs, OBM has another command line utility. For instance, you can run suspended jobs within a maintenance window at the weekend using:

      opr-jobs –user user –password password –start –suspended –node_group myGroup


That’s all for now. I think we’re done with our little tour.

“Thank you. I think I’ll give OBM a try.”


Learn more about Operations Manager and Operations Bridge Manager here.

You can also download trials of the software to experience them for yourself.

Search for blogs containing tag OBM10F for other topics similar to this one

The OM-to-OpsBridge evolution program including license exchange details is now live. Search on the tag OM2OpsBridge to find blogs discussing this program and evolution to OpsBridge. Search on OBM Content for other blogs on management packs and connectors.

You can meet and discuss with your fellow peers and mingle with OpsBridge experts at our next events


For more information on this release and how customers are using Operations Bridge, we are happy to announce the following events:

 Click on the image to registerClick on the image to register
Register here

 Read all our news at the Operations Bridge blog.

Related Items

Explore all Operations Bridge capabilities and technology integrations by visiting these sites:

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.