Managing Linux via OMI: Installation

This is second part of the series, first one that actually explains anything. You can find outline of the whole series here. Before we start to play with Open Management Infrastructure (OMI) on Linux box we need to have two things: Linux box (obviously) and OMI installed on it (tell me something I don’t know!) First part is easy these days, so I will mention it briefly. Next part is also very natural to anybody who installed anything on Linux (outside of “normal” packaging mechanism, that – to me knowledge – is not supported for OMI yet). Finally we will change our system to run OMI server every time we boot. My way is probably far from best practices for Linux, so feel free to jump in and correct me there.  

Linux on my box

There are plenty different distributions of Linux available, but I decided to try CentOS. This one of distributions that didn’t exist when I last played with Linux. It’s also mentioned as supported on Hyper-V that runs on my primary Windows 8 laptop, so I felt confident that I won’t walk into some strange compatibility issues. I wanted to focus on OMI, not on fixing issues, or walking around them.

During installation you have several options to pick up from. I went with Minam Desktop option, and added development tools required by OMI installation:

To be honest – I was guessing here what I needed. That’s what you get for ten years of exile. It’s not like you can’t change it later, but luckily, I managed to cover all requirements:

• GNU make
• Native C and C++ compiler
• OpenSSL headers and libraries
• PAM headers and libraries

Once installation was complete – I’ve added “normal” account, configured network (thank you God for DHCP!) and went straight to OMI page to download tarball. But before I did anything with it I installed of Hyper-V tools, to make transition between VM and own desktop more convenient:

OMI – here I come!

Once you have tar.gz with sources, next thing you will want to is to decompress it and run configuration script. You can either rely on defaults, or change few things. I decided that I want to change general prefix (/opt/omi) and path, where installer will (eventually) put binaries (/usr/local/bin):

So far – so good. Now we can make something, literally… First make as regular user, and than, as a root – make install:

Autostart

Final piece of setup was adding two things to automatically launched at boot time. First of all – DHCP client. It was not my intention to set static IP on that VM, so DHCP was a perfect solution for me. Second element was OMI server, that has special option (-d) to run it as a background process. I had no idea what the “correct” way to do that would be, so I simply added it to rc.local script. It’s usually almost empty, so it should not be hard to find it later and change/ remove it, if needed:

Running this script manually first is probably good idea – if you wouldn’t see either of processes in ps output – you should probably double check if you haven’t done any mistake (e.g. configured OMI to store it binaries in folder that is not in $PATH as it is defined at this point). If all is good, you can reboot and see if omicli can connect to your server. In my case I needed to add symlink to make it work after reboot (/sbin/omiserver), but eventually it worked as expected:

If you want to know other options that OMI client supports, just ask for help (omicli -h) – it doesn’t have many options, but it’s perfect to test your OMI server as you go (e.g. check if class you’ve designed work as expected). Output is not the best you can get, so eventually you will want to use CIM cmdlets instead. But before you do, you need to configure your network to support it. We will take care of it in the next post.

Advertisement