Managing Linux via OMI: Configuration

This is third part of the series. You can find outline of the whole series here. We already have OMI server up and running, but so far it’s not accessible from outside. Our plan is to perform operations inside PowerShell, so remote access is necessary. Next, we will create static, example provider and try to access data from it remotely. Once we understand some basic concepts and code structure – we will be able to start implementing something for real.

Let me in!

Open Management Infrastructure, same as CIM on Windows, can be contacted using WS-Man. Our goal is to enable port on which WS-Man operates (5985). CentOS is using iptables, so we need to modify configuration for iptables to match desired one. This can be done in two ways: either using GUI (system-config-firewall) or in more direct fashion, by editing /etc/sysconfig/iptables:

This way or the other – you need to make sure, that port 5985 is open. Once this is done, you can (drum roll) try to connect to the box from PowerShell for the very first time:

$Cred = Get-Credential root            
$Session = New-CimSession -ComputerName OMI -Authentication Basic -Credential $Cred            
Get-CimInstance -CimSession $Session -ClassName OMI_Identify -Namespace root/omi

As a result we get object, that is almost the same as the output we’ve seen from omicli id – this is the same class, just displayed in a way we are used to. As you can see – the class is in the namespace that was specially created for OMI related information. Unfortunately, it’s not possible to list other classes present in this namespace, Get-CimClass does not work when you try to use wildcards (at least: not in current version).

My little pony

Now that we have our server available remotely, let’s try to build something. Getting started document describes creating two providers, sample code can be also found in folder with source code. It’s a way to look at code that actually works, so that you can start from there and (eventually) build something that does something:

We will try to do something else though. Build provider on our own, one step at a time. First step is to define the schema. This schema is later used by omigen command to create all necessary header/ code files. Examples provided with OMI tarball are about frogs, but I will use ponies instead (my daughter is in love with those creatures, so I became expert in this area and have a lot of examples to play with). Our CIM_Pony class has following definition:

class CIM_Pony
{
    [Key] String Name;
    String Colour;
    String Sign;
    Boolean Horn;
    Boolean Wings;
};

Next thing – omigen, unfortunately it will work only from root account (I suspect changing rights somewhere might help, but haven’t figured out yet – where). I’m not as fluent in c as I’m in c++, so I add switch to use this language. I also need to specify provider name, path to schema file and class name (here with optional alias name):

As you can see I’m also changing owner of the files generated: I want to modify them as regular user (bielawb), so I just make him owner. Next thing you have to do is to modify <ClassAlias>_Class_Provider.cpp file that contains actual implementation. It contains all methods necessary, without code that “makes it happen”. If you would compile provider at this point it wouldn’t do anything other than returning errors. To get very basic provider we need to implement at least one class: EnumInstances. It’s useful to have also GetInstance implemented. In this first attempt we will make data static so methods like CreateInstance simply wouldn’t work. Implementation is simple: first you create new instance of class you are working with, than you fill in the blanks and finally use context.Post() to send it to requestor. One thing to keep in mind: once you are done you have to send MI_* info back, otherwise client will wait for response (forever):

So first: EnumerateInstances. This one should return all instances, for example:

void Pony_Class_Provider::EnumerateInstances(
    Context& context,
    const String& nameSpace,
    const PropertySet& propertySet,
    bool keysOnly,
    const MI_Filter* filter)
{
    Pony_Class pony;

    pony.Name_value("Twilight Sparkle");
    pony.Colour_value("Lilac");
    pony.Sign_value("Star and sparkles");
    pony.Horn(true);
    pony.Wings(false);
    context.Post(pony);

    pony.Name_value("Rainbow Dash");
    pony.Colour_value("Blue");
    pony.Sign_value("Cloud and lightning");
    pony.Horn(false);
    pony.Wings(true);
    context.Post(pony);

    context.Post(MI_RESULT_OK);
}

GetInstance is almost the same, but it will return only one instance (if any found) or none:

void Pony_Class_Provider::GetInstance(
    Context& context,
    const String& nameSpace,
    const Pony_Class& instanceName,
    const PropertySet& propertySet)
{
    if (instanceName.Name_value() == "Twilight Sparkle")
    {
        Pony_Class pony;
        pony.Name_value("Twilight Sparkle");
        pony.Colour_value("Lilac");
        pony.Sign_value("Star and sparkles");
        pony.Horn(true);
        pony.Wings(false);
        context.Post(pony);
        context.Post(MI_RESULT_OK);
    }
    else if (instanceName.Name_value() == "Rainbow Dash")
    {
        Pony_Class pony;
        pony.Name_value("Rainbow Dash");
        pony.Colour_value("Blue");
        pony.Sign_value("Cloud and lightning");
        pony.Horn(false);
        pony.Wings(true);
        context.Post(pony);
        context.Post(MI_RESULT_OK);
    }
    else
    {
        context.Post(MI_RESULT_NOT_FOUND);
    }
}

Once we are happy with our implementation, we can try to compile it (make) and register our provider on the server (make reg) – again, with root access:

No errors, so we should be able to read this data remotely from PowerShell. It works very well, including filters:

Looks like we are ready to make something dynamic, that reflects remote configuration. Something we will start to implement in next part of this series.

Advertisement