As more and more management functionalities are being added into iDRAC (Service Processor), there is a lesser and lesser need for fat proprietary agents to be running in the Operating Systems to enable system management/monitoring. In pursuit of this idea, multiple management capabilities are pushed to iDRAC and Dell has started working on enabling system management with thinner and thinner agents in the OS. https://fedoraproject.org/wiki/Features/AgentFreeManagement describes some of these initiatives and one of them is Wsman Request redirection.
Recently a new plugin was pushed to openwsman which enables the redirection of wsman requests from the host to iDRAC(or any remote wsman server). Essentially, the openwsman service running in the host will act as a proxy, filters the incoming requests based on the ResourceUri and forwards the right requests to iDRAC. The host's openwsman daemon (the proxy) eventually captures the response from iDRAC(or the remote server) and forwards the same to primary client. This setup will enable system management and monitoring without having to install any proprietary management agents in the OSes.
NOTE: the redirection plugin is only available in 2.3.6 and higher versions of openwsman.
To enable the WSMAN request redirection to idrac, the following section has to be added to openwsman.conf file:
[redirect]
#mandatory fields
server='192.168.1.120'
resource='http://schemas.dell.com/wbem/wscim/1/cim-schema/2'
port=443
cacert='/etc/idrac.cert'
username='root'
password='calvin'
#optional Fields
#default is /wsman
url_path='/wsman'
#default is basic
authentication_method='basic'
#default is root/cimv2
cim_namespace='root/cimv2'
#default is 0
noverifypeer=0
#default is 0
noverifyhost=0
#default is NULL
sslkey=NULL
#default is NULL
cl_cert=NULL
With the above configuraiton section added to opewsman.conf any WSMAN requests coming to the host with ResourceURI http://schemas.dell.com/wbem/wscim/1/cim-schema/2/* will be redirected to iDRAC and all the other requests will be handled by one of the other openwsman plugins in the host. In the above example 192.168.1.120 is the ip address of iDRAC, listening at port 443.
iDRAC has SSL enabled by default. So, the server's identify certificate has to be provided to the redirect plugin. Please note, even in the case noverifypeer is set to 1 (where the servercert is not verified), a dummy cert has to be provided in the redirect section. For production servers, it is always recommended to have noverifypeer=0 and noverifyhost=0.
The username and password values will be imported from the primary wsman request if none are provided in the redirect. The rest of the values pick up default values as shown above configuraiton. Now an example:
wsman enumerate http://schemas.dell.com/wbem/wscim/1/cim-schema/2/root/dcim/DCIM_ComputerSystem -h host_ip -V -v -c dummy.cert -P 5986 -u root -p password -y -O out
NOTE: The username, password, cert provided in the primary wsman command are to autheticate to the host. The details captured in the openwsman.conf file are to authenticate to iDRAC.
Sending the above request to a host, output similar to the following will be noticed:
<?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:wsman="http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd" xmlns:wsen="http://schemas.xmlsoap.org/ws/2004/09/enumeration" xmlns:n1="http://schemas.dell.com/wbem/wscim/1/cim-schema/2/DCIM_ComputerSystem">
<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/EnumerateResponse</wsa:Action>
<wsa:RelatesTo>uuid:c987c6d4-d8c4-18c4-8002-a52924d9bed4</wsa:RelatesTo>
<wsman:TotalItemsCountEstimate>1</wsman:TotalItemsCountEstimate>
<wsa:MessageID>uuid:c4910753-d8c9-18c9-8258-b12ca052aed4</wsa:MessageID>
<wsman:TotalItemsCountEstimate>1</wsman:TotalItemsCountEstimate>
</s:Header>
<s:Body>
<wsen:EnumerateResponse>
<wsman:Items>
<n1:DCIM_ComputerSystem>
<n1:CreationClassName>DCIM_ComputerSystem</n1:CreationClassName>
<n1:Dedicated>0</n1:Dedicated>
<n1:ElementName>host-8-23.lab</n1:ElementName>
<n1:EnabledState>5</n1:EnabledState>
<n1:HealthState>25</n1:HealthState>
<n1:IdentifyingDescriptions>CIM:GUID</n1:IdentifyingDescriptions>
<n1:IdentifyingDescriptions>CIM:Tag</n1:IdentifyingDescriptions>
<n1:IdentifyingDescriptions>DCIM:ServiceTag</n1:IdentifyingDescriptions>
<n1:Name>srv:system</n1:Name>
<n1:OperationalStatus>6</n1:OperationalStatus>
<n1:OtherIdentifyingInfo>4c4c4544-0036-4710-8046-c3c04f515631</n1:OtherIdentifyingInfo>
<n1:OtherIdentifyingInfo>mainsystemchassis</n1:OtherIdentifyingInfo>
<n1:OtherIdentifyingInfo>ABCDEFG</n1:OtherIdentifyingInfo>
<n1:PrimaryStatus>3</n1:PrimaryStatus>
<n1:RequestedState>0</n1:RequestedState>
</n1:DCIM_ComputerSystem>
</wsman:Items>
<wsen:EnumerationContext/>
<wsman:EndOfSequence/>
<wsen:EnumerationContext/>
<wsman:EndOfSequence/>
</wsen:EnumerateResponse>
</s:Body>
</s:Envelope>
The wsman redirection works with the standard Actions like enumerate, get, put, create, delete and invoke. The requests for associations on iDRAC CANNOT be redirected. Also, redirection for WSMAN indications is not enabled yet.
On a side note, OpenLMI( https://fedorahosted.org/openlmi/ ) is an initiative to provide common infrastructure to enable Management of Linux Systems. This project provides low level interfaces to server hardware and software management in the form of CIMOM providers. The target of this effort are the in-band components like Services, Network, Storage, etc. After registering these providers/APIs to a CIMOM they can be accessed via WSMAN too.
Having the wsman redirection enabled to iDRAC and openlmi providers setup, will enable the Admins to have a single interface for managing both in-band and out-of-band components via WSMAN.
Image may be NSFW.Clik here to view.