macOS packaged release unable to flashfwpkg

[apavely]

Since release v3.1.0 of the packaged binaries for macOS, I have been unable to run flashfwpkg due to a missing "iLOrest Chif dll".

$ ilorest-3.2.2 flashfwpkg U34_2.52_07_08_2021.fwpkg --url testhost-ilo5.domain.local -u admin -p 'XXXXXXXXXXXX'
iLOrest : RESTful Interface Tool version 3.2.2
Copyright (c) 2014-2021 Hewlett Packard Enterprise Development LP
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Discovering data...Done
iLOrest Chif dll not found, please check that the chif dll is present.

$ ilorest-3.1.1 flashfwpkg U34_2.52_07_08_2021.fwpkg --url testhost-ilo5.domain.local -u admin -p 'XXXXXXXXXXXX'
iLOrest : RESTful Interface Tool version 3.1.1
Copyright (c) 2014-2020 Hewlett Packard Enterprise Development LP
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Discovering data...Done
WARNING: Cache is activated. Session keys are stored in plaintext.
iLOrest Chif dll not found, please check that the chif dll is present.

$ ilorest-3.1.0 flashfwpkg U34_2.52_07_08_2021.fwpkg --url testhost-ilo5.domain.local -u admin -p 'XXXXXXXXXXXX'
iLOrest : RESTful Interface Tool version 3.1
Copyright (c) 2014-2020 Hewlett Packard Enterprise Development LP
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Discovering data...Done
WARNING: Cache is activated. Session keys are stored in plaintext.
iLOrest Chif dll not found, please check that the chif dll is present.

It last ran successfully using v3.0.1.

$ ilorest-3.0.1 flashfwpkg U34_2.52_07_08_2021.fwpkg --url testhost-ilo5.domain.local -u admin -p 'XXXXXXXXXXXX'
iLOrest : RESTful Interface Tool version 3.0.1
Copyright (c) 2014, 2019 Hewlett Packard Enterprise Development LP
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Discovering data...Done
WARNING: Cache is activated. Session keys are stored in plaintext.
Uploading firmware: U34_2.52_07_08_2021.signed.flash
[200] The operation completed successfully.
Component U34_2.52_07_08_2021.signed.flash uploaded successfully
Waiting for iLO UpdateService to finish processing the component
0 hour(s) 1 minute(s) 40 second(s)
Firmware has successfully been flashed and a reboot is required for this firmware to take effect.

As I understand it, CHIF is the local iLO channel interface, and accessible only locally, so is there a reason we're triggering the CHIF code path for remote (HTTP) connections?

[rajeevkallur]

Does it work if IP address used instead of system name? Tested with latest code, it seems to work fine.

[rajeevkallur]

Please let us know if it is still an issue.

[apavely]

Still an issue.

It makes no difference whether I specify an IP address or a DNS hostname, or whether or not I include the full URI prefix. I have tried multiple iterations without success, with and without various flags, even mimicking yours above:

$ ilorest-3.2.2 -v flashfwpkg U34_2.52_07_08_2021.fwpkg --forceupload --tpmover --url 172.16.0.10 -u admin -p 'XXXXXXXXXXXX'
iLOrest : RESTful Interface Tool version 3.2.2
Copyright (c) 2014-2021 Hewlett Packard Enterprise Development LP
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Discovering data...Done
iLOrest Chif dll not found, please check that the chif dll is present.
ILOREST return code: 35

Just to be clear, it's not just the released binaries for macOS ... it's also present with the latest HEAD:

$ which python3
/usr/local/bin/python3
$ python3 -V
Python 3.9.6
$ python3 rdmc.py -v flashfwpkg ~/Downloads/fwpkg/U34_2.52_07_08_2021.fwpkg --forceupload --tpmover --url 172.16.0.10 -u admin -p 'XXXXXXXXXXXX'
iLOrest : RESTful Interface Tool version 3.2.2
Copyright (c) 2014-2021 Hewlett Packard Enterprise Development LP
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Discovering data...Done
iLOrest Chif dll not found, please check that the chif dll is present.
ILOREST return code: 35

This is a problem that appears to be specific to the macOS versions released due to the lack of a CHIF library for the macOS platform (I am running macOS 10.15.7 Catalina on Intel). I can understand why there's no CHIF library available for macOS, as no HPE hardware is designed to run macOS. As a remote client platform, though, I regularly use macOS to script firmware updates to our iLO5-based HPE Gen10 servers.

In other words, if we're using Redfish over HTTPS for connectivity, why are we breaking on a CHIF requirement? It shouldn't matter what platform you are on. Are there any code paths that explicitly depend on CHIF being present for remote connections (Redfish over HTTPS)?

[rajeevkallur]

Does this sequence work? (explicit logging initially) python3 rdmc.py login 172.16.0.10 -u admin -p 'XXXXXXXXXXXX' python3 rdmc.py -v flashfwpkg ~/Downloads/fwpkg/U34_2.52_07_08_2021.fwpkg --forceupload --tpmover

[apavely]

The above didn't work, either, but I did some tracing and found that there was a call to redfish.hpilo.risblobstore2.gethprestchifhandle() that was the culprit.

https://github.com/HewlettPackard/python-redfish-utility/blob/8c398807857dffecfe1045fd3265165f32063026/src/extensions/iLO%20REPOSITORY%20COMMANDS/FwpkgCommand.py#L236-L246

I did this quick hack as a workaround, and it worked for my purposes (though I am not suggesting this is a proper solution):

diff --git a/src/extensions/iLO REPOSITORY COMMANDS/FwpkgCommand.py b/src/extensions/iLO REPOSITORY COMMANDS/FwpkgCommand.py
index cc3c984..45e7f62 100644
--- a/src/extensions/iLO REPOSITORY COMMANDS/FwpkgCommand.py
+++ b/src/extensions/iLO REPOSITORY COMMANDS/FwpkgCommand.py
@@ -233,17 +233,17 @@ class FwpkgCommand():

         if comptype in ['A','B'] and results and 'UpdateFWPKG' in results[0]['Oem']['Hpe']\
                                                                                 ['Capabilities']:
-            dll = BlobStore2.gethprestchifhandle()
-            dll.isFwpkg20.argtypes = [c_char_p, c_int]
-            dll.isFwpkg20.restype = c_bool
+#            dll = BlobStore2.gethprestchifhandle()
+#            dll.isFwpkg20.argtypes = [c_char_p, c_int]
+#            dll.isFwpkg20.restype = c_bool

             with open(pkgfile, 'rb') as fwpkgfile:
                 fwpkgdata = fwpkgfile.read()

             fwpkg_buffer = ctypes.create_string_buffer(fwpkgdata)
-            if dll.isFwpkg20(fwpkg_buffer, 2048):
-                imagefiles = [pkgfile]
-                tempdir = ''
+#            if dll.isFwpkg20(fwpkg_buffer, 2048):
+#                imagefiles = [pkgfile]
+#                tempdir = ''

         return imagefiles, tempdir, comptype

IMHO, there needs to be better gating around CHIF calls to limit them to only if there's a local connection.

[rajeevkallur]

The above condition already has the check to local connection in the new code. But looks like this code is not yet released outside.

if "blobstore" in self.rdmc.app.redfishinst.base_url and comptype in ['A','B'] and results and \ 'UpdateFWPKG' in results[0]['Oem']['Hpe']['Capabilities']:

Anyway, thanks for bringing it up.

[apavely]

Confirmed that the aforementioned change does correct the issue. Closing.