Csak gyorsan: még egy példa hiányzott az IRF segédletünkből, mégpedig az, amikor Linux platformon az openwsman+sfcb programoktól kapcsolódó osztályokat kérdezünk le WS-Management segítségével. PowerShellben ez ment, sőt a linuxos wsman kliens is le tudott kérdezni távoli Windows gépet.
Viszont amikor wsman klienssel kérdeztem le az openwsman szervert, nem akart összejönni:
wsman -d 6 -R -h localhost -u meres -p LaborImage associators 'http://schemas.dmtf.org/wbem/wscim/1/*' --filter=http://schemas.dmtf.org/wbem/wscim/1/CIM_ComputerSystem Segmentation fault (core dumped)
Itt nem voltak kiválasztók (selector) megadva, és az epr_from_string metódusban, ami ezt feldolgozza, nincs hibakezelés. Ezért lett segmentation fault.
Próbáljuk megadni konkrét példányt:
wsman -R -h localhost -u root -p LaborImage associators 'http://schemas.dmtf.org/wbem/wscim/1/*' --filter='http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ComputerSystem?CreationClassName="CIM_ComputerSystem",Name="irfserver.irf.local"'
Ekkor meg a következő hibát dobta:
<s:Value>wsa:DestinationUnreachable</s:Value> <s:Text xml:lang="en">Provider not found or not loadable</s:Text>
Gondoltam az elnevezéssel lesz gond. WinRM esetén ez a helyes:
Get-WSManInstance -ComputerName 192.168.21.151 -ResourceURI wmicimv2/* -Dialect Association -Filter "{object=Win32_LogicalDisk?deviceid=C:}" -Enumerate -Credential meres -Associations
Viszont, hogy wsmancli+openwsman esetén mi a jó, azt nem olyan egyszerű megtudni. Egy régi levél van ilyen témában (How to get association instance using wsmancli), viszont az ott leírtak nekem nem működtek most a wsman 2.2.7.1 és openwsman 2.3 esetén.
Ilyen kor jön akkor, hogy a DMTF és SBLIM névterek tetszőleges kombinációját végigpróbálja az ember. Elég frusztráló volt, mert a wsman get művelet ment egy adott kombinációval, viszont az associators meg nem:(
Volt a végén ilyen elkeseredett próbálkozás is:
wsman -R -h localhost -u root -p LaborImage associators 'http://sblim.sf.net/wbem/wscim/1/*' --filter='http://sblim.sf.net/wbem/wscim/1/cim-schema/2/Linux_ComputerSystem?CreationClassName="Linux_ComputerSystem",Name="irfserver.irf.local"' Connection failed. response code = 503
Ez nyilván nem jó, mert sblim-es all class URI nincs (a /* az all class).
A wsman által összeállított XML látszólag jó volt, a WS-Management CIM Binding specifikációban leírtaknak megfelelt. Az openwsman ezt írta ki (ez már egy megint másik próbálkozás, kerestem olyan osztályt, ahol nem kulcs a CreationClassName):
Apr 2 22:13:03 [7436] ObjectPath: root/cimv2:Linux_RpmPackage.SoftwareElementState="2",Name="matahari-broker",TargetOperatingSystem="36",Version="0.4.4",SoftwareElementID="matahari-broker" Apr 2 22:13:03 [7436] enumInstances() rc=6, msg=Provider not found or not loadable Apr 2 22:13:03 [7436] *** CMCIClient enumInstances() failed
Irány a gdb, meddig jut el. A gond az volt, hogy szépen végigment a cim_enum_instances metóduson (ahol korábban probléma volt), és el is küldte az sfcc segítségével a CIMOM-nak az üzenetet.
Nézzük akkor a CIMOM-ot. Előtérben elindítva az sfcbd-t végre volt egy értelmes hibaüzenet:
--- Caching ClassProvider for /var/lib/sfcb/registration/repository/root/cimv2/classSchemas (1.0-3) using 7756 bytes --- Caching ClassProvider for /var/lib/sfcb/registration/repository/root/interop/classSchemas (1.0-3) using 1204 bytes loading libcimrpmv4.so *** dlopen: /usr/lib/cmpi/libcmpiLinux_SambaAdminUsersForGlobal.so error: /usr/lib/cmpi/libcmpiLinux_SambaUser.so: undefined symbol: _ZN12CmpiInstance16getPropertyCountEv *** Failed to load libcmpiLinux_SambaAdminUsersForGlobal.so for CmpiLinux_SambaAdminUsersForGlobalProvider --- closeProviderContext not touching sem 53; already zero
Tehát nem a wsman-ban, nem az openwsman-ban van a hiba, hanem maga a CIMOM a rossz! De miért zavar minket a Samba provider, és ez eddig miért nem jött elő? Jobban belegondolva jogos, hisz eddig nem kérdeztem le a SambaAdminUsersForGlobal osztály példányait, viszont a kapcsolatok lekérdezésekor az összes kapcsolóosztályt be kell járni, többek között ezt is. A rendszerben viszont voltak hibás kapcsolóosztályok, így a CIMOM hibát jelzett.
Megoldás: nem volt kedvem már sblim-cmpi providereket debuggolni, úgyhogy kiszedtem a CIMOM-ból ezeket (az sfcb repository-ból kell kitörölni a kapcsolódó MOF fájlokat és provider regisztrációs állományokat, majd újraépíteni a repositoryt). Ezután már az Rpm provider volt a hibás. Kitöröltem. Utána a Dhcp. Kitöröltem. Utána a DNS. Kitöröltem. Ezután végre ment a lekérdezés. A fura az, hogy ezek a providereket a hivatalos yum repositoryból raktuk fel, ez van elvileg CentOS 6.2-höz. Jó lenne megnézni, hogy mi volt a gond velük, de már így is sokkal több idő elment ezzel, mint kellett volna.
Akkor a helyes lekérdezés:
# this is working and it should be wsman -h localhost -u meres -p LaborImage associators 'http://schemas.dmtf.org/wbem/wscim/1/*' --filter 'http://sblim.sf.net/wbem/wscim/1/cim-schema/2/Linux_ComputerSystem?Name="irfserver.irf.local",CreationClassName=Linux_ComputerSystem'
Jó lenne csak DMTF névtereket használni, mint a fenti levélben is van, viszont az nem ment nekem:
# this should work, but it returns actually an empty sequence of items wsman -R -h localhost -u root -p LaborImage associators 'http://schemas.dmtf.org/wbem/wscim/1/*' --filter='http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ComputerSystem?CreationClassName="Linux_ComputerSystem",Name="irfserver.irf.local"'
Ez lefut, viszont üres eredményhalmazzal tér vissza. Pedig a get megy erre a ResourceURI-ra.
Ami viszont még meglepőbb:
# this works currently, altough it should not be, because there is a namespace mismatch in it wsman -R -h localhost -u root -p LaborImage associators 'http://schemas.dmtf.org/wbem/wscim/1/*' --filter='http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/Linux_ComputerSystem?CreationClassName="Linux_ComputerSystem",Name="irfserver.irf.local"'
Ennek viszont nem kéne menni, mert DMTF névtérben hivatkozunk Linux sémájú osztályra. Nem is megy a get ezzel az URI-val (eredmény: InvalidResourceURI).
Viszont legalább annyival zárhatom a napot, hogy most már volt sikeresen lefutó associators lekérdezés.
SUMMARY: If you get the ‘Provider not found or not loadable‘ error with an associators query, then check your CIMOM, maybe the error is there and not in openwsman (as in my case: some association classes and providers were not working in sfcbd).