WSMAN är det valda hanterings-API:et för Dell iDRAC och omfattande arbete pågår för att göra fjärrsystemhantering så omfattande och enkel som möjligt. Jag tillbringade nyligen lite tid med att förstå WSMAN-protokollet för att implementera ett plugin och efter den första wsman-uppräkningsåtgärden blir WSMAN-protokollet lite hårigt. Det finns ingen enkel dokumentation/exempel på hur du anropar get/put/create/delete/custom Actions med rätt nyckelegenskaper. Den primära källan för denna information är DMTF:s WSMAN-specifikation och WSMAN-CIM-bindningsspecifikation som är smärtsamt långa att följa. Återigen kommer det mesta av innehållet i den här artikeln från DMTF-specifikationsdokumenten. Detta är ett försök att göra den informationen lätt att smälta med några exempel (på Linux).
Jag har redan postat ett whitepaper om hur man kommer igång med SFCB och openwsman på
https://linux.dell.com/files/whitepapers/WBEM_based_management_in_Linux.pdf. Om du är ny på WSMAN/SFCB skulle pdf:en vara en bättre utgångspunkt än den här artikeln. Som i ovanstående whitepaper kommer vi främst att behandla openwsman- och SFCB CIMOM-implementeringar i den här artikeln.
Nu, med tanke på en WSMAN-server, finns det något sätt att lista alla komponenter som kan hanteras av wsman API? De flesta WSMAN-servrarna pratar med en CIMOM på baksidan och exponerar CIMOM:ernas hanteringsfunktioner. Det innebär att hanteringsfunktionerna för en WSMAN-server beror på de CIM-leverantörer som är registrerade i CIMOM på serverdelen. CIMOM har en inbyggd funktion med namnet
EnumerateClassNames definierad som kan anropas för att lista alla klasser som är registrerade i CIMOM.
CIMOM:s inbyggda
EnumerateClassNames-funktion kan anropas på följande sätt med 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>...................
Utdata ser ut som ovan, vilket indikerar att Linux_Processor är en av de registrerade klasserna i namnrymdens root/cimv2. Det finns ett antal CIM-klasser som ärvs när nya klasser registreras i root/cimv2-namnområdet och kommandot ovan listar också alla dessa klassnamn. Som en allmän regel kan du ignorera alla klasser med
CIM_ prefix. Alla klasser med
Linux_ prefix är de klasser som registreras av providers som är installerade på ett Linux-system. När du arbetar med Dells iDRAC är du främst intresserad av klasser med
DCIM_ prefix.
Nu när du har en lista över alla klassnamn kan du använda den inbyggda funktionen
getClass för att extrahera definitionen av
den Linux_Processor klassen på följande sätt:
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
Kommandot ovan visar en lista över alla egenskaper som har definierats i
Linux_Processor lokalt. Det innebär att någon av de egenskaper som ärvs från andra
CIM_*- klasser inte visas med den aktuella implementeringen. Vanligtvis kan du utifrån en klasss definition ta reda på vilka metoder som definieras i klassen, vilka parametrar som måste skickas till dessa metoder och vilka egenskaper för klassen som är nyckelegenskaper osv. Men eftersom kommandot ovan bara returnerar de lokala egenskaperna går det inte att identifiera nyckelegenskaperna i klassen. Återigen är detta för närvarande en implementeringsbegränsning i wsmancli.
Så även om GetClass funktionen är en bra utgångspunkt är utdata från den inte tillräckliga för att avgöra vilka egenskaper för klassen som kan användas som nyckelegenskaper så att get/put/create/custom åtgärden kan anropas. Så, vilka andra tekniker kan användas för att åstadkomma detta? Det är här EPR kan vara till hjälp.
EPR (End Point Reference) är en pekare till en instans med två typer av information: ResourceURI och en väljaruppsättning. ResourceURI har det klassnamn som instansen skapas från och väljaruppsättningen visar de egenskaper som en instans kan identifieras unikt med. EPR:er av en viss klass kan räknas upp med ett kommando som liknar:
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>
Av alla processorer i målsystemet är ovanstående utdata bara en processor. I utdata resourceURI visas som http://sblim.sf.net/wbem/wscim/1/cim-schema/2/Linux_Processor och SelectorSet visas värdena för __cimnamespace, SystemCreationClassName, SystemName, CreationClassName och DeviceID. Det innebär att av alla egenskaper i Linux_Processor-klassen (ärvd och lokalt definierad) kan dessa egenskaper användas för att unikt identifiera en instans.
Så du kan förvänta dig ett giltigt svar från ett kommando som:
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
Om andra egenskaper används i ovanstående begäran kommer CIMOM i serverdelen inte att kunna identifiera en instans unikt. På samma sätt, om det finns några anpassade metoder som behöver köras en instans, kan klassens EPR användas för att identifiera de nyckelegenskaper som en metod ska anropas med.
Du kan också räkna upp EPR:er för en förening. Givet ett klassnamn kan man inte räkna ut om det är ett standardklassnamn eller en associationsklass. Eftersom en instans av en association har pekare till två instanser, kommer en EPR för en association att ha EPR:erna för de instanser/objekt som associationen refererar till. Följande är ett exempel på samma sak:
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 är en association mellan
klasserna Linux_ComputerSystem och
Linux_Processor som etablerar förhållandet att processorerna finns i datorsystem, och därmed avsnitten GroupComponent och PartComponent.
Jag var tvungen att lägga lite tid på att ta reda på EPR:erna och hur de kan användas för att komma åt enskilda instanser, tänkte att det kunde komma väl till pass för andra. Lämna gärna dina kommentarer/förslag nedan.
Ansvarsfriskrivning:
Ovanstående artikel är endast i informationssyfte. Innehållet är från min tolkning av de nämnda teknikerna/terminologierna. Denna information tillhandahålls i befintligt skick och kan innehålla vissa typografiska fel och/eller tekniska felaktigheter.