I needed to get myself an OOB license for the BIOS update over the IPMI console or SUM (Supermicro Update Manager). An IPMI update can be done without an OOB license from the IPMI console, but the BIOS requires a license.
Links that initially helped me with that to get a feel for what I needed:
Obtain the license code from your IPMI BMC MAC address
But then I found out the below links on reverse engineering.
From those links, I checked both the Perl and Linux OpenSSL versions. Only the Perl version works on MacOS.
Then I fiddled with the bash version: unlike the OpenSSL version above, this one printed output. It wrongly printed the last groups of hex digits instead of the first groups of hex digits that the Perl script prints.
Here is the corrected bash script printing the first groups of hex digits (on my systems, I have an alias supermicro_hash_IPMI_BMC_MAC_address_to_get_OOB_license_for_BIOS_update for it):
Web app offering modular conversion, encoding and encryption online. Translations are done in the browser without any server interaction. This is an Open Source project, code licensed MIT.
Steps:
In the left pane, select the “View” drop-down to be “Bytes”, then paste the HEX bytes of your IPMI MAC address there (like 00 25 90 7d 9c 25)
In the middle pane, select the drop-down to become “HMAC” followed by the radio-group to be “SHA1“, then paste these bytes into the “Key” field: 85 44 E3 B4 7E CA 58 F9 58 30 43 F8
In the right pane, select the drop-down to become “Bytes”, then the “Group by” to become “2 bytes”, which will you give the output (where the bold part is the license key: 6 groups of 2 bytes): a7d5 2201 4eee 667d dbd2 5106 9595 2ff7 67b8 fb59
The problem manifests itself when the WSDL file includes one or more XSD files. The generated code will contain a section like this:
// ************************************************************************ //
// The following types, referred to in the WSDL document are not being represented
// in this file. They are either aliases[@] of other types represented or were referred
// to but never[!] declared in the document. The types from the latter category
// typically map to predefined/known XML or Embarcadero types; however, they could also
// indicate incorrect WSDL documents that failed to declare or import a schema type.
// ************************************************************************ //
Further below is a series of commented out types, all starting with a ! end ending in a column with the namespace of those types.
Based on those, I think the reason is that the WSDL importer fails on <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" /> which is quite common in the real world.
I did not want to pursue manually modifying the WSDL file, or manually generating the types as the WSDL and XSD files were prone to changes and manual steps would make the re-import process more tedious. If you do want to do that, these link might help:
Cool presentation on avoiding data races and race conditions when doing file system operations. It includes lots of conceptual and API suggestions on many operating systems (explaining what works where and why not), plus locking tips.
Biggest takeaway for me: always use handles to any object, and avoid static paths like a bad flue.
The Wiert Corner - irregular stream of stuff 