WSMAN est l’API de gestion choisie pour l’iDRAC Dell et des efforts considérables sont en cours pour rendre la gestion du système à distance aussi complète et facile que possible. J’ai récemment passé du temps à étudier le protocole WSMAN pour mettre en œuvre un plug-in ; or, après l’action d’énumération wsman initiale, le protocole WSMAN devient relativement complexe. Il n’existe aucune documentation et aucun exemple simple sur le mode d’appel des actions get/put/create/delete/custom avec les propriétés clés appropriées. La principale source de ces informations est la spécification WSMAN de DMTF et la spécification de liaison WSMAN-CIM qui sont extrêmement longues à suivre. Là encore, la plupart du contenu de cet article provient des documents de spécification DMTF. Il s’agit d’une tentative visant à faciliter l’assimilation de ces informations avec certains exemples (sous Linux).
J’ai déjà publié un livre blanc sur la façon de commencer avec SFCB et openwsman à l’adresse
https://linux.dell.com/files/whitepapers/WBEM_based_management_in_Linux.pdf. Si vous découvrez WSMAN/SFCB, le PDF constitue un meilleur point de départ que cet article. Comme dans le livre blanc ci-dessus, nous nous intéresserons principalement aux implémentations d’Openwsman et de SFCB CIMOM dans cet article.
Maintenant, avec un serveur WSMAN, existe-t-il un moyen de répertorier tous les composants qui sont gérables par l’API wsman ? La plupart des serveurs WSMAN communiquent avec un CIMOM sur le back-end et présentent les fonctionnalités de gestion des CIMOM. Cela signifie que les capacités de gestion d’un serveur WSMAN dépendent des fournisseurs CIM qui sont enregistrés sur le CIMOM qui se trouve sur le back-end. Le CIMOM a une fonction intrinsèque du nom
EnumerateClassNames qui peut être appelée pour répertorier toutes les classes enregistrées sur CIMOM.
La fonction
EnumerateClassNames intrinsèque de CIMOM peut être appelée comme suit avec 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>...................
Le résultat se présente comme ci-dessus, indiquant que dans l’espace de noms root/cimv2, Linux_Processor est l’une des classes enregistrées. Un certain nombre de classes CIM sont héritées lorsque de nouvelles classes sont enregistrées dans l’espace de noms root/cimv2 et la commande ci-dessus répertorie également tous ces noms de classes. En règle générale, vous pouvez ignorer toutes les classes avec le préfixe
CIM_. Toutes les classes avec le préfixe
Linux_ sont les classes enregistrées par les fournisseurs installés sur un système Linux. Lorsque vous utilisez l’iDRAC de Dell, les principales classes qui vous intéressent portent le préfixe
DCIM_.
Maintenant que vous disposez d’une liste de tous les noms de classes, vous pouvez utiliser la fonction intrinsèque
getClass pour extraire la définition de la classe
Linux_Processor comme suit :
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
La commande ci-dessus répertorie toutes les propriétés définies localement dans
Linux_Processor. Cela signifie que les propriétés héritées d’autres classes
CIM_* ne sont pas répertoriées avec l’implémentation actuelle. Généralement, à partir de la définition d’une classe, vous pouvez déterminer quelles méthodes sont définies dans la classe, quels paramètres doivent être transmis à ces méthodes et quelles propriétés de la classe sont des propriétés clés, etc. Cependant, étant donné que la commande ci-dessus renvoie uniquement les propriétés locales, les propriétés clés de la classe ne peuvent pas être identifiées. Là encore, il s’agit actuellement d’une limite d’implémentation dans wsmancli.
Ainsi, bien que la fonction GetClass soit un bon point de départ, son résultat n’est pas suffisant pour déterminer les propriétés de la classe pouvant être utilisées comme propriétés clés en vue d’appeler l’action get/put/create/custom. Quelles autres techniques peuvent donc être utilisées pour y parvenir ? C’est là que les EPR peuvent vous aider.
Un EPR (End point Reference, ou référence de point de terminaison) est un pointeur vers une instance contenant deux informations : ResourceURI et un ensemble de sélecteurs. ResourceURI porte le nom de la classe à partir de laquelle l’instance est créée et l’ensemble de sélecteurs répertorie les propriétés qui permettent d’identifier une instance de manière unique. Les EPR d’une classe particulière peuvent être énumérés à l’aide d’une commande similaire à :
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>
Parmi tous les processeurs du système cible, la sortie ci-dessus ne concerne qu’un seul processeur. Dans la sortie, ResourceURI est répertorié comme http://sblim.sf.net/wbem/wscim/1/cim-schema/2/Linux_Processor et SelectorSet répertorie les valeurs de __cimnamespace, SystemCreationClassName, SystemName, CreationClassName and DeviceID. Cela signifie que toutes les propriétés de la classe Linux_Processor (héritées et définies localement) peuvent être utilisées pour identifier une instance de manière unique.
Vous pouvez donc vous attendre à une réponse valide d’une commande telle que :
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
Si d’autres propriétés sont utilisées dans la demande ci-dessus, le CIMOM dans le back-end ne pourra pas identifier une instance de manière unique. De même, si certaines méthodes personnalisées doivent être exécutées sur une instance, il est possible d’utiliser l’EPR de la classe pour identifier les propriétés clés avec lesquelles appeler une méthode.
Vous pouvez également énumérer les EPR d’une association. Pour un nom de classe donné, il n’est pas possible de savoir s’il s’agit d’un nom de classe standard ou d’association. Étant donné qu’une instance d’une association comporte des pointeurs vers deux instances, l’EPR d’une association dispose des EPR des instances/objets auxquels l’association fait référence. Voici un exemple :
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 est une association entre les classes
Linux_ComputerSystem et
Linux_Processor qui indique que les processeurs sont contenus dans les systèmes informatiques et que, par conséquent, les sections GroupComponent et PartComponent le sont aussi.
J’ai mis du temps à comprendre les EPR et à apprendre à les utiliser pour accéder à des instances individuelles ce qui, je pense, peut être utile à d’autres utilisateurs. N’hésitez pas à me laisser vos commentaires/suggestions ci-dessous.
Clause de non-responsabilité :
l’article ci-dessus est fourni à titre d’information uniquement. Le contenu provient de mon interprétation des technologies/terminologies mentionnées. Ces informations sont fournies telles qu’elles et peuvent contenir des erreurs typographiques et/ou des inexactitudes techniques.