WSMAN er den valgte administrations-API til Dell iDRAC, og der arbejdes på en omfattende indsats for at gøre fjernsystemadministration så omfattende og nem som muligt. Jeg har for nylig brugt lidt tid på at forstå WSMAN-protokollen til at implementere et plugin, og efter den indledende wsman-optællingshandling bliver WSMAN-protokollen lidt behåret. Der er ingen nem dokumentation/eksempler på, hvordan man aktiverer get/put/create/delete/custom Actions med de rigtige nøgleegenskaber. Den primære kilde til disse oplysninger er DMTF's WSMAN-specifikation og WSMAN-CIM-bindingsspecifikation, som er smerteligt langvarige at følge. Igen er det meste af indholdet i denne artikel fra DMTF-specifikationsdokumenterne. Dette er et forsøg på at gøre disse oplysninger lette at fordøje med nogle eksempler (på Linux).
Jeg har allerede sendt en hvidbog om, hvordan man kommer i gang med SFCB og openwsman på
https://linux.dell.com/files/whitepapers/WBEM_based_management_in_Linux.pdf. Hvis du er ny til WSMAN / SFCB, ville pdf'en være et bedre udgangspunkt end denne artikel. Som i ovenstående hvidbog vil vi primært beskæftige os med openwsman- og SFCB CIMOM-implementeringer i denne artikel.
Nu, givet en WSMAN-server, er der en måde at liste alle de komponenter, der kan administreres af wsman API? De fleste af WSMAN-serverne taler med en CIMOM på back-end og afslører CIMOM'ernes administrationsfunktioner. Det betyder, at administrationsfunktionerne på en WSMAN-server afhænger af de CIM-udbydere, der er registreret til CIMOM på backend. CIMOM har en iboende funktion ved navnet
EnumerateClassNames defineret, der kan kaldes for at liste alle de klasser, der er registreret til CIMOM.
CIMOM's iboende
EnumerateClassNames-funktion kan kaldes som følger 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>...................
Outputtet vil se ud som ovenfor, hvilket indikerer, at Linux_Processor i navneområdet root/cimv2 er en af de registrerede klasser. Der er et antal CIM-klasser, der nedarves, når nye klasser registreres i root/cimv2-navneområdet, og ovenstående kommando viser også alle disse klassenavne. Som hovedregel kan du ignorere alle klasser med
CIM_ præfiks. Alle klasser med
Linux_ præfiks er de klasser, der er registreret af udbydere installeret på et Linux-system. Mens du arbejder med Dells idrac, vil du mest være interesseret i klasser med
DCIM_ præfiks.
Nu hvor du har en liste over alle klassenavnene, kan du bruge
getClass iboende funktion til at udtrække definitionen af
den Linux_Processor klasse som følger:
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
Ovenstående kommando viser alle de egenskaber, der er defineret i
Linux_Processor lokalt. Det betyder, at nogen af de egenskaber, der er arvet fra andre
CIM_* -klasser, ikke vises med den aktuelle implementering. Normalt kan du ud fra en klasses definition finde ud af, hvilke metoder der er defineret i klassen, hvilke parametre der skal overføres til disse metoder, og hvilke egenskaber i klassen der er nøgleegenskaber osv. Men da ovenstående kommando kun returnerer de lokale egenskaber, kan nøgleegenskaberne i klassen ikke identificeres. Igen er dette i øjeblikket en implementeringsbegrænsning i wsmancli.
Så selvom funktionen GetClass er et godt udgangspunkt, er outputtet af den ikke tilstrækkeligt til at bestemme, hvilke egenskaber for klassen der kan bruges som nøgleegenskaber, så hent/put/create/custom handling kan påberåbes. Så hvilke andre teknikker kan bruges til at opnå dette? Det er her, EPR'er kan hjælpe.
EPR (End Point Reference) er en markør til en forekomst med to oplysninger: ResourceURI og et vælgersæt. ResourceURI har det klassenavn, som forekomsten er oprettet ud fra, og vælgersættet viser de egenskaber, som en forekomst kan identificeres entydigt med. EPR'er af en bestemt klasse kan optælles med en kommando, der ligner:
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>
Af alle processorer i målsystemet er ovenstående output kun af en processor. I outputtet vises resourceURI'en som http://sblim.sf.net/wbem/wscim/1/cim-schema/2/Linux_Processor, og SelectorSet viser værdierne for __cimnamespace, SystemCreationClassName, SystemName , CreationClassName og DeviceID. Det betyder, at af alle egenskaberne i Linux_Processor-klassen (nedarvet og lokalt defineret) kan disse egenskaber bruges til entydigt at identificere en forekomst.
Så du kan forvente et gyldigt svar fra en 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
Hvis der bruges andre egenskaber i ovenstående anmodning, vil CIMOM i back-end ikke være i stand til at identificere en forekomst entydigt. Tilsvarende, hvis der er nogle brugerdefinerede metoder, der skal køres en forekomst, kan klassens EPR bruges til at identificere de nøgleegenskaber, der skal aktiveres en metode med.
Du kan også opregne en forenings EPR'er. Givet et klassenavn kan man ikke finde ud af, om det er et standard klassenavn eller en foreningsklasse. Da en forekomst af en forening har henvisninger til to forekomster, vil en EPR for en forening have EPR'erne for de forekomster / objekter, som foreningen henviser til. Følgende er et eksempel på det samme:
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 er en forbindelse mellem
Linux_ComputerSystem - og
Linux_Processor-klasserne , der etablerer relationen til, at processorerne er indeholdt i computersystemer, og dermed afsnittene GroupComponent og PartComponent.
Jeg var nødt til at bruge lidt tid på at finde ud af EPR'erne, og hvordan de kan bruges til at få adgang til individuelle tilfælde, tænkte det kunne være nyttigt for andre. Du er velkommen til at efterlade mig dine kommentarer / forslag nedenfor.
Ansvarsfraskrivelse:
Ovenstående artikel er kun til orientering. Indholdet er fra min fortolkning af de nævnte teknologier/terminologier. Disse oplysninger gives, som de er, og kan indeholde nogle typografiske fejl og/eller tekniske unøjagtigheder.