WSMAN es la API de administración elegida para Dell iDRAC y se están realizando grandes esfuerzos para que la administración remota del sistema sea lo más completa y sencilla posible. Recientemente, me dediqué a entender el protocolo WSMAN para implementar un plug-in y, después de la acción inicial de enumeración de wsman, el protocolo WSMAN se vuelve un poco complicado. No existen documentos/ejemplos sencillos sobre cómo invocar acciones get/put/create/delete/custom con las propiedades clave correctas. La fuente principal de esta información es la especificación WSMAN de DMTF y la especificación de vinculación WSMAN-CIM, que son extremadamente largas de seguir. Como mencioné, la mayor parte del contenido de este artículo proviene de los documentos de especificación de DMTF. Este es un intento de hacer que esa información sea fácil de comprender con algunos ejemplos (en Linux).
Ya publiqué una documentación técnica sobre cómo comenzar con SFCB y openwsman en
https://linux.dell.com/files/whitepapers/WBEM_based_management_in_Linux.pdf. Si es la primera vez que usa WSMAN/SFCB, el PDF sería un mejor punto de partida que este artículo. Al igual que en la documentación técnica anterior, en este artículo nos ocuparemos principalmente de las implementaciones de openwsman y SFCB CIMOM.
Ahora, con un servidor de WSMAN, ¿hay alguna manera de enumerar todos los componentes que se pueden administrar mediante la API de wsman? La mayoría de los servidores de WSMAN se comunican con un CIMOM en el back-end y exponen las funcionalidades de administración de los CIMOM, es decir, las funcionalidades de administración de un servidor WSMAN dependen de los proveedores de CIM registrados en el CIMOM en el backend. CIMOM tiene una función intrínseca con el nombre
EnumerateClassNames definida a la que se puede llamar para enumerar todas las clases registradas en CIMOM.
La función intrínseca
EnumerateClassNames de CIMOM se puede llamar de la siguiente manera con 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>...................
El resultado es parecido al anterior, lo que indica que Linux_Processor es una de las clases registradas en el espacio de nombres root/cimv2. Hay una serie de clases CIM que se heredan cuando se registran nuevas clases en el espacio de nombres root/cimv2 y el comando anterior también enumera todos esos nombres de clase. Como regla general, puede ignorar todas las clases con el prefijo
CIM_. Todas las clases con el prefijo
Linux_ son las clases registradas por los proveedores instalados en un sistema Linux. Cuando trabaje con iDRAC de Dell, le interesarán principalmente las clases con el prefijo
DCIM_.
Ahora que tiene una lista de todos los nombres de clase, puede usar la función intrínseca
getClass para extraer la definición de la clase
Linux_Processor de la siguiente manera:
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
El comando anterior enumera todas las propiedades que se definen en
Linux_Processor localmente, lo que significa que cualquiera de las propiedades heredadas de otras clases
CIM_* no se muestran con la implementación actual. Por lo general, a partir de la definición de una clase, puede averiguar qué métodos se definen en la clase, qué parámetros deben pasarse a esos métodos y qué propiedades de la clase son clave, etc. Sin embargo, dado que el comando anterior solo devuelve las propiedades locales, no se pueden identificar las propiedades clave de la clase. Como ya se explicó, esta es actualmente una limitación de implementación en wsmancli.
Por lo tanto, aunque la función GetClass es un buen punto de partida, su resultado no es suficiente para determinar qué propiedades de la clase se pueden usar como propiedades clave para que se pueda invocar la acción get/put/create/custom. Entonces, ¿qué otras técnicas se pueden utilizar para lograr esto? Aquí es donde las EPR pueden ayudar.
La EPR (referencia de punto final) es un puntero a una instancia con dos datos: ResourceURI y SelectorSet. ResourceURI tiene el nombre de clase a partir del cual se crea la instancia y SelectorSet enumera las propiedades con las que se puede identificar de forma única una instancia. Las EPR de una clase específica se pueden enumerar con un comando similar al siguiente:
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>
De todos los procesadores en el sistema de destino, el resultado anterior es solo de un procesador. En la salida, resourceURI se muestra como http://sblim.sf.net/wbem/wscim/1/cim-schema/2/Linux_Processor y SelectorSet enumera los valores de __cimnamespace, SystemCreationClassName, SystemName, CreationClassName y DeviceID. Esto significa que, de todas las propiedades de la clase Linux_Processor (heredadas y definidas localmente), estas se pueden usar para identificar de forma única una instancia.
Por lo tanto, puede esperar una respuesta válida de un comando como el siguiente:
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 se utiliza cualquier otra propiedad en la solicitud anterior, el CIMOM en el back-end no podrá identificar una instancia de manera única. Del mismo modo, si es necesario ejecutar algunos métodos personalizados en una instancia, la EPR de la clase se puede usar para identificar las propiedades clave con las que invocar un método.
También puede enumerar las EPR de una asociación. Con el nombre de clase, no se puede averiguar si se trata de un nombre de clase estándar o de una clase de asociación. Dado que la instancia de una asociación tiene punteros a dos instancias, la EPR de una asociación tendrá las EPR de las instancias/objetos a los que hace referencia la asociación. A continuación, se muestra un ejemplo de esto:
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 es una asociación entre las clases
Linux_ComputerSystem y
Linux_Processor que establece la relación de que los procesadores están contenidos en los sistemas informáticos y, por lo tanto, las secciones GroupComponent y PartComponent.
Tuve que dedicar un momento a analizar las EPR y cómo se pueden usar para acceder a instancias individuales. Me imaginé que podría ser útil para otras personas. No dude en dejarme sus comentarios/sugerencias a continuación.
Descargo de responsabilidad:
El artículo anterior se redactó solo con fines informativos. El contenido se basa en mi interpretación de las tecnologías/terminologías mencionadas. Esta información se proporciona tal cual y puede contener errores tipográficos o imprecisiones técnicas.