Once a piece of software is installed on a user's system, how do you keep it updated? While Linux users typically have a package management system to pull latest versions from a repository of their choice, users of other systems aren't so lucky. We have developed an open source tool to assist in this process, based on an open source protocol from Google know as Omaha.
Several years ago Google released an open source protocol called Omaha (otherwise known as Google Update) as a part of its Chromium project. The protocol is intended to make the updating process of complicated desktop software easier.
So far, Omaha is used primarily in Google products, like Google Chrome or Google Earth. The Google Update system is used mainly by Windows software for the implementation of the auto-update process; Linux builds of Google's software rely on the package managers included in the Linux distribution. The main advantage of Google Update is that the framework can be integrated with any software that needs to support an auto-update functionality and the ability to manage new patches and updates from a single place (as well as gather error reports).
There is a publicly available implementation of a client by Google that supports an Omaha protocol. The server's implementation wasn't released and any intention to integrate Google Update into the user’s own software required implementing a basic version with at least general commands support. Because the company I work for helps to develop customized Chromium based browsers, we developed and released an open source version of the server so the prospective users of the Google Update system will have an access to the full chain and be able to integrate one into their software with no hassles.
Apart from the Omaha protocol, our implementation contains a support of Sparkle which is a well-known update framework for Mac OS X software. In addition, we have combined our implementation with an admin panel for easy version management, partial upgrade for the alpha and beta versions, and error report tools.
We paid close attention to the deployment process, which was conceived as several commands to set-up either a production or development environment. Ultimately, we picked the open Docker platform which makes distributing much more portable and allows running the image within an isolated environment on any given server. It could be easily deployed to any cloud environment.
To share more about Omaha server, we've developed a slide deck which goes into futher detail, and complete documentation and samples are kept on GitHub, where pull requests from the community are accepted.
With regards to the client, we forked the Google's implementation to maintain its compatibility with the modern versions of Visual Studio and improved user's experience while an integration process. According to the Chromium mailing list, the Google’s client is still being developed inside the organization, however, due to the build system being used internally, the latest patches cannot be published by them for a couple of years. There are some protocol features which aren't supported by the current client yet, like CodeRed (allows recovering to the previous version in case of an unsuccessful installation). The client's version is also located on GitHub in a separate repository. All the sources are released under the Apache 2.0 license.
We hope that our implementation will ease the work of open source enthusiasts and businesses that build its own infrastructure on top of either Chromium OS or Chromium browser providing them with a production ready update server/client chain. Furthermore, it's worth considering this system as an efficient update solution for the projects with complicated requirements to this process.
Comments are closed.