WSMAN is the chosen management API for Dell iDRAC and extensive efforts are underway to make remote system management as comprehensive & easy as possible. I recently spent some time understanding WSMAN protocol to implement a plugin and after the initial wsman enumeration action, WSMAN protocol gets a bit hairy. There is no easy documentation/examples on how to invoke get/put/create/delete/custom Actions with the right key properties. The primary source for this information is the DMTF's WSMAN specification and WSMAN-CIM binding specification which are painfully lengthy to follow. Again, most of the content of this article is from the DMTF specification documents. This is an attempt to make that information easy to digest with some examples (on Linux).
I already posted a whitepaper on how to get started with SFCB and openwsman at
https://linux.dell.com/files/whitepapers/WBEM_based_management_in_Linux.pdf. If you are new to WSMAN/SFCB, the pdf would be a better starting point than this article. As in the above whitepaper we will primarily deal with openwsman and SFCB CIMOM implementations in this article.
Now, given a WSMAN server, is there a way to list all the components that are manageable by wsman API? Most of the WSMAN servers talk to a CIMOM on the back-end and expose the management functionalities of the CIMOMs. Meaning, the management capabilities of a WSMAN server depend on the CIM providers registered to the CIMOM on the backend. The CIMOM has an intrinsic function by the name
EnumerateClassNames defined that can be called to list all the classes that are registered to CIMOM.
Since there is no one-to-one mapping for
EnumerateClassNames in WSMAN specification, this method is invoked like any other custom function in WSMAN. Please note, this is implementation specific and applies to wsmancli implementation. This could be different or updated in future releases.
CIMOM's intrinsic
EnumerateClassNames function can be called as follows with wsmancli:
wsman invoke -a EnumerateClassNames --hostname=test_host --port=5985 --username=abc --password=password
http://schemas.openwsman.org/wbem/wscim/1/instrinsic --namespace=root/cimv2
<s:Body>
<n1:EnumerateClassNames>
<n1:name>root/cimv2:CIM_Service</n1:name>
<n1:name>root/cimv2:Syslog_RecordInLog</n1:name>
<n1:name>root/cimv2:Linux_SambaValidUsersForShare</n1:name>
<n1:name>root/cimv2:Linux_BaseBoard</n1:name>
<n1:name>root/cimv2:Linux_SambaForceUserForShare</n1:name>
<n1:name>root/cimv2:Linux_Processor</n1:name>
<n1:name>root/cimv2:CIM_RecordForLog</n1:name>
<n1:name>root/cimv2:Linux_SambaShareForService</n1:name>
<n1:name>root/cimv2:Linux_SambaServiceConfigurationForService</n1:name>
<n1:name>root/cimv2:Linux_SambaHostsForService</n1:name>
<n1:name>root/cimv2:Linux_SambaForceUserForGlobal</n1:name>
<n1:name>root/cimv2:CIM_OSProcess</n1:name>
<n1:name>root/cimv2:CIM_RunningOS</n1:name>...................
The output will look like above, indicating that in the namespace root/cimv2, Linux_Processor is one of the classes registered. There are a number of CIM classes that are inherited when new classes are registered in the root/cimv2 namespace and the above command will list all those class names too. As a general rule, you can ignore all the classes with
CIM_ prefix. All the classes with
Linux_ prefix are the classes that are registered by providers installed on a Linux system. While working with Dell's idrac, you will mostly be interested in classes with
DCIM_ prefix.
Now that you have a list of all the class names, you could use
getClass intrinsic function to extract the definition of the
Linux_Processor class as follows:
wsman invoke -a GetClass --hostname=test_host --port=5985 --username=abc --password=password http://schemas.openwsman.org/wbem/wscim/1/intrinsic/Linux_Processor --namespace=root/cimv2
The above command will list all the properties that are defined in the
Linux_Processor locally. Meaning any of the properties that are inherited from other
CIM_* classes are not listed with the current implementation. Usually from a Class's definition you can figure out what methods are defined in the class, what parameters need to be passed to those methods and what properties of the class are key properties etc. But, since the above command only returns the Local properties, the key properties in the class cannot be identified. Again, this is currently an implementation limitation in wsmancli.
So, although the GetClass function is a good starting point, the output of it is not sufficient enough to determine what properties of the class can be used as key properties so that get/put/create/custom action can be invoked. So, what other techniques can be used to accomplish this? This is where EPRs can help.
EPR (End Point Reference) is a pointer to an instance with two pieces of information: the ResourceURI and a Selector Set. The ResourceURI has the class name the instance is created from and the Selector Set lists the properties an instance can be uniquely identified with. EPRs of particular class can be enumerated with a command similar to:
wsman enumerate -M epr http://sblim.sf.net/wbem/wscim/1/cim-schema/2/Linux_Processor -h test_host-P 5985 -u abc -p password -O out
<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsen="http://schemas.xmlsoap.org/ws/2004/09/enumeration" xmlns:wsman="http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd">
<s:Header>
<wsa:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To>
<wsa:Action>http://schemas.xmlsoap.org/ws/2004/09/enumeration/PullResponse</wsa:Action>
<wsa:RelatesTo>uuid:ca52c9e9-cd47-1d47-8003-a52924d9bed4</wsa:RelatesTo>
<wsa:MessageID>uuid:ca622bb3-cd47-1d47-8097-a52924d9bed4</wsa:MessageID>
</s:Header>
<s:Body>
<wsen:PullResponse>
<wsen:EnumerationContext>ca4fdd21-cd47-1d47-8095-a52924d9bed4</wsen:EnumerationContext>
<wsen:Items>
<wsa:EndpointReference>
<wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
<wsa:ReferenceParameters>
<wsman:ResourceURI>http://sblim.sf.net/wbem/wscim/1/cim-schema/2/Linux_Processor</wsman:ResourceURI>
<wsman:SelectorSet>
<wsman:Selector Name="
__cimnamespace">root/cimv2</wsman:Selector>
<wsman:Selector Name="
SystemCreationClassName">Linux_ComputerSystem</wsman:Selector>
<wsman:Selector Name="
SystemName">localhost.localdomain</wsman:Selector>
<wsman:Selector Name="
CreationClassName">Linux_Processor</wsman:Selector>
<wsman:Selector Name="
DeviceID">0</wsman:Selector>
</wsman:SelectorSet>
</wsa:ReferenceParameters>
</wsa:EndpointReference>
</wsen:Items>
</wsen:PullResponse>
</s:Body>
</s:Envelope>
Of all the processors in the target system the above output is just of one processor. In the output the resourceURI is listed as http://sblim.sf.net/wbem/wscim/1/cim-schema/2/Linux_Processor and the SelectorSet lists the values of __cimnamespace, SystemCreationClassName, SystemName , CreationClassName and DeviceID. This means of all the properties in the Linux_Processor class (inherited and locally defined) these properties can be used to uniquely identify an instance.
So, you can expect a valid response from a command like:
wsman get http://sblim.sf.net/wbem/wscim/1/cim-schema/2/Linux_Processor?SystemCreationClassName="Linux_ComputerSystem",SystemName="localhost.localdomain",CreationClassName="Linux_Processor",DeviceID="3",__cimnamespace="root/cimv2" -h test_host -P 5985 -u abc -p password -O get
If any other properties are used in the above request, the CIMOM in the back-end will not be able to identify an instance uniquely. Similarly if there are some custom methods that need to be run an instance, the EPR of the class can be used to identify the key properties to invoke a method with.
You can enumerate the EPRs of an association as well. Given a class name one cannot figure out if it is a standard Class name or an association class. Since an instance of an association has pointers to two instances, an EPR of an association will have the EPRs of the instances/objects the association is referring to. Following is an example of the same:
wsman enumerate -M epr http://sblim.sf.net/wbem/wscim/1/cim-schema/2/Linux_CSProcessor -h test_host -P 5985 -u abc -p password -O out
<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsen="http://schemas.xmlsoap.org/ws/2004/09/enumeration" xmlns:wsman="http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd">
<s:Header>
<wsa:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To>
<wsa:Action>http://schemas.xmlsoap.org/ws/2004/09/enumeration/PullResponse</wsa:Action>
<wsa:RelatesTo>uuid:2efbfcad-cd4b-1d4b-8003-a52924d9bed4</wsa:RelatesTo>
<wsa:MessageID>uuid:2efc1c6f-cd4b-1d4b-80b3-a52924d9bed4</wsa:MessageID>
</s:Header>
<s:Body>
<wsen:PullResponse>
<wsen:EnumerationContext>2ef7f6f5-cd4b-1d4b-80b1-a52924d9bed4</wsen:EnumerationContext>
<wsen:Items>
<wsa:EndpointReference>
<wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
<wsa:ReferenceParameters>
<wsman:ResourceURI>http://sblim.sf.net/wbem/wscim/1/cim-schema/2/Linux_CSProcessor</wsman:ResourceURI>
<wsman:SelectorSet>
<wsman:Selector Name="__cimnamespace">root/cimv2</wsman:Selector>
<wsman:Selector Name="GroupComponent">
<wsa:EndpointReference>
<wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
<wsa:ReferenceParameters>
<wsman:ResourceURI>http://sblim.sf.net/wbem/wscim/1/cim-schema/2/
Linux_ComputerSystem</wsman:ResourceURI>
<wsman:SelectorSet>
<wsman:Selector Name="
CreationClassName">Linux_ComputerSystem</wsman:Selector>
<wsman:Selector Name="
Name">localhost.localdomain</wsman:Selector>
<wsman:Selector Name="
__cimnamespace">root/cimv2</wsman:Selector>
</wsman:SelectorSet>
</wsa:ReferenceParameters>
</wsa:EndpointReference>
</wsman:Selector>
<wsman:Selector Name="PartComponent">
<wsa:EndpointReference>
<wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
<wsa:ReferenceParameters>
<wsman:ResourceURI>http://sblim.sf.net/wbem/wscim/1/cim-schema/2/Linux_Processor</wsman:ResourceURI>
<wsman:SelectorSet>
<wsman:Selector Name="
SystemCreationClassName">Linux_ComputerSystem</wsman:Selector>
<wsman:Selector Name="
SystemName">localhost.localdomain</wsman:Selector>
<wsman:Selector Name="
CreationClassName">Linux_Processor</wsman:Selector>
<wsman:Selector Name="
DeviceID">0</wsman:Selector>
<wsman:Selector Name="
__cimnamespace">root/cimv2</wsman:Selector>
</wsman:SelectorSet>
</wsa:ReferenceParameters>
</wsa:EndpointReference>
</wsman:Selector>
</wsman:SelectorSet>
</wsa:ReferenceParameters>
</wsa:EndpointReference>
</wsen:Items>
</wsen:PullResponse>
</s:Body>
</s:Envelope>
Linux_CSProcessor is an association between the
Linux_ComputerSystem and
Linux_Processor classes establishing the relation that the Processors are contained in Computer Systems, and so the GroupComponent and PartComponent sections.
I had to spend some time figuring out the EPRs and how they can be used to access individual instances, thought it might come in handy for others. Feel free to leave me your comments/suggestions below.
Disclaimer:
Above article is for informational purposes only. The content is from my interpretation of the technologies/terminologies mentioned. This information is provided as is and may contain some typographical errors and/or technical inaccuracies.