At the end of November 2019, we quietly released v1.13 of our On-Prem Meta appliance.
This release contains a few security fixes, minor bug fixes, and a major OS upgrade from TinyCore 7.x to 10.x.
Some notable changes below:
One feature which we quickly implemented in the Jidoteki Admin API was the ability to configure the initial API token on first-use. Unfortunately this has some important security implications for those deploying an OVA in a hostile network (or on a public network).
To fix this, we’ve enabled the ability to optionally enable our “first-run” feature (disabled by default). This generates a random passphrase as an API token when the OVA is first launched. The random passphrase can only be seen from the console (ex: by an infrastructure admin), or programmatically by an app running on the OVA appliance.
This initial passphrase must then be used to reset the API token and complete the “first-run” process.
Our GitHub integration was broken since the day we launched it. Although it worked on our test appliance because we weren’t testing it correctly. Oops. This is fixed, and the Meta OVA can now receive GitHub push webhook events and automatically pull the latest code changes.
We’re often adding new input/output parameters to API calls to provide more functionality for our customers without breaking existing functionality. A favourite of mine is the builddate, which is central to pretty much every API call. Certain API endpoints required you to parse the reply to determine the builddate, so for those endpoints we now return that value directly at the top level of the JSON response, to facilitate chaining API calls which depend on the builddate.
We’ve also added the ability to suppress the log output when polling for a build’s status. The log output could easily reach a few hundred KB, and polling that much data every 5 seconds was not efficient. Now it can be disabled and the status output reduced to just a few KB instead.
Finally, for our customers building multiple flavours of the same appliance (ex: small, medium, large), it is now possible to only build the small OVA, or any combination of flavours through the ova_files parameter on the POST /builds endpoint. This is good for testing when you only need to test one OVA (since technically, the only difference between various flavours are the disk sizes). For production builds, the ova_files parameter can simply be omitted.
Ths year we’ve begun working on Meta OVA v20 (v2.x) which is so far quite a significant improvement.
Our focus has always been to help our customers deploy Enterprise on-prem virtual appliances, so with that in mind, our next OVA will contain many more enterprise features which can also be integrated into customer appliances.
We’ve also recently launched a new set of Open Source tools for working with the Meta OVA, so make sure to read our next blog post for details on that.
As usual, feel free to contact us and tell us your story. We’ll be happy to help you get up and running with On-Prem Meta so you can start building and deploying your own on-prem appliances.