WSMAN to wybrany interfejs API zarządzania dla kontrolera iDRAC firmy Dell. Trwają intensywne prace, których celem jest sprawienie, aby zdalne zarządzanie systemem było możliwie wszechstronne i łatwe. Ostatnio poświeciłem trochę czasu na zrozumienie protokołu WSMAN, aby zaimplementować wtyczkę i po początkowej akcji wyliczenia wsman, protokół WSMAN stał się nieco zagmatwany. Nie istnieje przystępna dokumentacja lub przykłady dotyczące wywołania akcji get/put/create/delete/custom z odpowiednimi właściwościami klucza. Podstawowym źródłem tych informacji jest specyfikacja WSMAN DMTF i specyfikacja powiązania WSMAN-CIM, które są boleśnie długie. Ponownie, większość treści tego artykułu pochodzi ze specyfikacji DMTF. Jest to próba uproszczenia tych informacji za pomocą kilku przykładów (w systemie Linux).
Opracowanie na temat sposobu rozpoczęcia pracy z SFCB i openwsman zostało przeze mnie opublikowane pod adresem
https://linux.dell.com/files/whitepapers/WBEM_based_management_in_Linux.pdf. Jeśli dopiero zaczynasz korzystać z WSMAN/SFCB, ten plik pdf będzie lepszym punktem wyjścia niż ten artykuł. Podobnie jak w powyższym opracowaniu, w tym artykule zajmiemy się przede wszystkim implementacjami openwsman i SFCB CIMOM.
Teraz, biorąc pod uwagę serwer WSMAN, czy istnieje sposób na wyświetlenie listy wszystkich komponentów, którymi można zarządzać za pomocą interfejsu API wsman? Większość serwerów WSMAN komunikuje się z CIMOM w backendzie i udostępnia funkcje zarządzania CIMOM. Oznacza to, że możliwości zarządzania serwera WSMAN zależą od dostawców CIM zarejestrowanych dla CIMOM w backendzie. CIMOM ma funkcję wewnętrzną o zdefiniowanej nazwie
EnumerateClassNames, która może zostać wywoływana w celu wyświetlenia listy wszystkich klas zarejestrowanych w CIMOM.
Wewnętrzną funkcję
EnumerateClassNames CIMOM można wywołać w następujący sposób za pomocą narzędzia 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>...................
Dane wyjściowe będą wyglądać jak powyżej, wskazując, że w przestrzeni nazw root/cimv2 Linux_Processor jest jedną z zarejestrowanych klas. Istnieje pewna liczba klas CIM, które są dziedziczone, gdy nowe klasy są rejestrowane w przestrzeni nazw root/cimv2, a powyższe polecenie również wyświetli wszystkie te nazwy klas. Wszystkie klasy z prefiksem
CIM_ można, ogólnie rzecz biorąc, zignorować. Wszystkie klasy z prefiksem
Linux_ są klasami zarejestrowanymi przez dostawców zainstalowanych w systemie Linux. Podczas pracy z kontrolerem iDRAC firmy Dell użytkownik będzie najbardziej zainteresowana klasami z prefiksem
DCIM_.
Teraz gdy dysponujesz już listą wszystkich nazw klas, możesz użyć funkcji wewnętrznej
getClass, aby wyodrębnić definicję klasy
Linux_Processor w następujący sposób:
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
Powyższe polecenie powoduje wyświetlenie listy wszystkich właściwości zdefiniowanych lokalnie w klasie
Linux_Processor. Oznacza to, że żadna z właściwości, które są dziedziczone z innych klas
CIM_* nie jest wymieniana w bieżącej implementacji. Zazwyczaj z definicji klasy można dowiedzieć się, jakie metody są zdefiniowane w klasie, jakie parametry należy przekazać do tych metod i jakie właściwości klasy są właściwościami kluczowymi itp. Ponieważ jednak powyższe polecenie zwraca tylko właściwości lokalne, nie można zidentyfikować kluczowych właściwości w klasie. Jest to obecnie ograniczenie implementacji w narzędziu wsmancli.
Tak więc, mimo że funkcja GetClass jest dobrym punktem wyjścia, jej dane wyjściowe nie są wystarczające, aby określić, jakie właściwości klasy mogą być używane jako właściwości klucza, aby można było wywołać akcję get/put/create/custom. Jakie więc inne techniki można wykorzystać, aby to osiągnąć? W tym mogą pomóc wskaźniki EPR.
EPR (End Point Reference) to wskaźnik do instancji z dwoma informacjami: ResourceURI i Selector Set. ResourceURI ma nazwę klasy, na podstawie której jest tworzone wystąpienie, a Selector Set zawiera wykaz właściwości, z którymi wystąpienie może być jednoznacznie identyfikowane. EPR danej klasy można wyliczyć za pomocą polecenia podobnego do:
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>
Pośród wszystkich procesorów w systemie docelowym powyższe dane wyjściowe dotyczą tylko jednego procesora. W danych wyjściowych klasa resourceURI jest wymieniona jako http://sblim.sf.net/wbem/wscim/1/cim-schema/2/Linux_Processor, a SelectorSet zawiera listę wartości __cimnamespace, SystemCreationClassName, SystemName, CreationClassName i DeviceID. Oznacza to, że spośród wszystkich właściwości w klasie Linux_Processor (dziedziczonych i zdefiniowanych lokalnie) te właściwości mogą być używane do jednoznacznej identyfikacji wystąpienia.
Możesz więc oczekiwać prawidłowej odpowiedzi na polecenie, takie jak:
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
Jeśli w powyższym żądaniu zostaną użyte jakiekolwiek inne właściwości, CIMOM w backendzie nie będzie w stanie jednoznacznie zidentyfikować instancji. Podobnie, jeśli istnieją pewne metody niestandardowe, których wystąpienie należy uruchomić, EPR klasy może służyć do identyfikowania kluczowych właściwości do wywołania metody.
Można również wyliczyć EPR skojarzenia. Biorąc pod uwagę nazwę klasy, nie można stwierdzić, czy jest to standardowa nazwa klasy, czy klasa skojarzenia. Ponieważ instancja skojarzenia ma wskaźniki do dwóch instancji, wskaźnik EPR skojarzenia będzie miał wskaźniki EPR instancji/obiektów, do których odwołuje się skojarzenie. Przykład tego jest następujący:
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 jest skojarzeniem między klasami
Linux_ComputerSystem i
Linux_Processor ustanawiającym relację, w której procesory są zawarte w systemach komputerowych, a więc w sekcjach GroupComponent i PartComponent.
Trochę czasu zajęło mi zrozumienie EPR i sposobu ich wykorzystania do uzyskania dostępu do poszczególnych instancji, przyszło mi do głowy, że może się to przydać innym. Zapraszam do pozostawienia poniżej komentarzy/sugestii.
Zastrzeżenie:
Powyższy artykuł służy wyłącznie celom informacyjnym. Treść została opracowana na podstawie mojej interpretacji wspomnianych technologii/terminologii. Informacje te są dostarczane w stanie, w jakim się znajdują i mogą zawierać pewne błędy typograficzne i/lub nieścisłości techniczne.