63

Google has open-sourced the auto update mechanism used in Google Chrome as Omaha.

It seems quite complicated and difficult to configure for anybody who isn't Google. What is the experience using Omaha in projects? Can it be recommended?

Elliot Cameron
  • 5,235
  • 2
  • 27
  • 34
Mark
  • 4,749
  • 7
  • 44
  • 53
  • Notes: It's used for google chrome auto software update, and it's windows specific for now! – Omar Al-Ithawi Sep 26 '10 at 00:11
  • 4
    I tried using Google Omaha but found it to complicated to work with. Instead we choose to use WyUpdate instead and have been quite happy with it. – Lars Tackmann May 16 '11 at 09:16
  • 4
    I just published a [tutorial](https://fman.io/blog/google-omaha-tutorial/) about Omaha. The official docs are good, but require you to figure out a lot of things on your own. I'm hoping the tutorial will make it easier for others to get started. – Michael Herrmann Aug 01 '16 at 09:35

6 Answers6

31

We use Omaha for our products. Initially there was quite a bit of work to change hardcoded URLs and strings. We also had to implement the server ourselves, because there was not yet an open source implementation. Today, I would use omaha-server.

There are no regrets with ditching our old client update solution and going with Omaha.

Michael Herrmann
  • 4,832
  • 3
  • 38
  • 53
Bevan Collins
  • 1,531
  • 16
  • 25
  • 5
    Now a year later, do you have additional experience to share? – Thorbjørn Ravn Andersen Jun 05 '12 at 19:30
  • 2
    Not really. The update system is still running well with no required maintenance for the past year. The server gets almost a request a second at peak times... Omaha checks for updates every 5 hours. If the version that the client has doesn't match what is published it sends a URL (hosted by Rackspace) of the updater. Omaha downloads, verifies, and runs the updater. – Bevan Collins Jun 06 '12 at 01:31
  • 2
    @Bevan: hi, would you mind sharing with us how the customization of Omaha is done? I am trying to use it as our updater. However, the documents on http://code.google.com/p/omaha/wiki/CustomizingOmaha isn't very helpful... – exklamationmark Jun 15 '12 at 06:09
  • 1
    @TongHuuKhiem That is basically what you need to do, just grep the source code for "Google", and GUIDs. It would be nice if it was all contained in a single header file, but it's not. – Bevan Collins Jun 19 '12 at 00:20
  • 1
    @Bevan: i see. I found a bunch of variables in omaha\main.scons that is also related to customizing. I 'll try your suggestion. Thanks :D – exklamationmark Jun 19 '12 at 17:25
  • 1
    @TongHuuKhiem were you able to customize it? I'm trying to do it now, but have also run into some road bumps. – funseiki Aug 24 '12 at 18:13
  • 2
    @funseiki I just went through the customisation process and wrote a [tutorial](https://fman.io/blog/google-omaha-tutorial/) about it. See also my answer below. – Michael Herrmann Aug 01 '16 at 09:23
  • How do you create patches for installation so that Omaha will automatically patch via updates? Any idea? I am working on auto update but rather than downloading the full installer, we are also planning to create installer for the diffs generated via courgette for our Chromium fork – Asesh Dec 09 '16 at 07:38
  • 1
    @Asesh we have kept it simple and just send out the full install for updates. In fact the same install file handles fresh installs as well as upgrades from the previous version. For updates, the Omaha server includes an additional command line argument when launching the installer so that it runs in silent mode. – Bevan Collins Dec 11 '16 at 20:11
17

Perhaps, you can leverage the courgette algorithm, which is the update mechanism that is used in Google Chrome. It is really easy to use and apply to your infrastructure. Currently, it just works for Windows operating systems. Windows users of Chrome receive updates in small chunks, unlike Mac and Linux users who still receive the chunks in total size.

You can find the source code here in the Chromium SVN repository. It is a compression algorithm to apply small updates to Google Chrome instead of sending the whole distribution all the time. Rather than push the whole 10 MB to the user, you can push just the diff of the changes.

More information on how Courgette works can be found here and the official blog post about it here.

It works like this:

server:
    hint = make_hint(original, update)
    guess = make_guess(original, hint)
    diff = bsdiff(concat(original, guess), update)
    transmit hint, diff

client
    receive hint, diff
    guess = make_guess(original, hint)
    update = bspatch(concat(original, guess), diff)

When you check out the source, you can compile it as an executable (right click compile in Visual Studio) and you can use the application in that form for testing:

Usage:

  courgette -dis <executable_file> <binary_assembly_file>
  courgette -asm <binary_assembly_file> <executable_file>
  courgette -disadj <executable_file> <reference> <binary_assembly_file>
  courgette -gen <v1> <v2> <patch>
  courgette -apply <v1> <patch> <v2>

Or, you can include that within your application and do the updates from there. You can imitate the Omaha auto update environment by creating your own service that you periodically check and run Courgette.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Mohamed Mansour
  • 39,445
  • 10
  • 116
  • 90
  • 5
    Hi Mohamed - thanks - that sounds like a good way to reduce the size of the updates. However, it seems Courgette still needs an 'update framework' (whether Omama or a DIY framework). – Mark Oct 15 '10 at 14:42
  • 8
    unrelated to the question. – kerem Apr 05 '12 at 15:10
  • 1
    Can you expand a little on how to compile Google Courgette? I tried VS and GYP but still no luck. Thanks! – Nikolai Samteladze Sep 22 '12 at 09:04
10

I've been using Omaha in various projects since 2016. The projects had between a handful and millions of update clients. Target operating systems were mostly Windows, but also some Linux devices and (via Sparkle) macOS.

Omaha is difficult to set up because it requires you to edit Google's C++ implementation. You also need a corresponding server. The standard implementation is omaha-server and does not come from Google. However, in return it also supports Sparkle for automatic updates on Mac (hence why I mentioned Sparkle above).

While setting up the above components is difficult, once they are configured they are work extremely well. This is perhaps not surprising given that Google use Omaha to update millions (billions?) of devices.

To help others get started with Omaha, I wrote a tutorial that gives a quick overview of how it works.

Michael Herrmann
  • 4,832
  • 3
  • 38
  • 53
  • Have you experience enough to comment now? – Alexander Apr 02 '17 at 01:59
  • Yes - I've been using Omaha in production for about 8 months now. It works very well. – Michael Herrmann Apr 02 '17 at 13:31
  • Sorry for jumping onto this answer, but I'm finding lots of gaps in the docco regarding making an actual installer exe, and support for the full application lifecycle, especially wrt uninstalling an app. Currently we use an MSI built using WiX, and this is straightforward. OCXs are registered, MSM merge modules incorporated, and uninstall works fine too. I don't see any help on how to implement these tasks within an Omaha framework. Can you point me to any resources that cover implementing these tasks, please? – Neil Moss Mar 09 '20 at 14:09
  • Hi Neil, I've now founded a consulting agency for Omaha. You can get in touch via https://omaha-consulting.com/contact and we'll be happy to help. – Michael Herrmann Mar 10 '20 at 08:07
2

UPDATE

  • Customizing google omaha isn't that easy espacialy if you have no knowledge about c++, python or com.
  • Updates aren't published that frequently
  • To implement manual updates in any language you can use the com classes

Resume

  • google omaha is still alive but in a lazy way
  • bugs are fixed but do not expect hotfixes
  • google omaha fits for windows client apps supported from windows vista and upwards
  • the server side I'm using supports also sparkle for crossplatform support
  • feedbacks and crashes are also supported on the server
    • feedbacks are sent with the google protocol buffers
    • crash handling is done with breakpad

I personaly would go for google omaha instead of implementing my own solution. However we will discuss this internal.

NtFreX
  • 10,379
  • 2
  • 43
  • 63
1

An auto-update mechanism is something I'd personally code myself, and always have in the past. Unless you have a multi-gigabyte application and want to upload bits and pieces only, just rely on your own code/installer. That said, I've not looked at Google's open source library at all.. and didn't even know it existed. I can't imagine it offering anything superior to what you could code yourself, and with your own code you aren't bound by any licensing restrictions.

dyasta
  • 2,056
  • 17
  • 23
  • 11
    Personally, I find third-party auto-update frameworks a big plus. At least in the Mac dev world, [Sparkle](http://sparkle.andymatuschak.org/) is a frequently-used option; clearly plenty of devs are opting for prefab. – Matt Ball Sep 29 '10 at 00:53
  • 3
    Correct me if I'm wrong but since I've installed Chrome I've never needed to "update", it's all transparent in the background and does so without me needing to do anything. IIRC when this first came out they spoke of being able to just update the actual binary distribution via some process akin to binary diffs etc. which makes this very cool and much different than coding your own where you just prompt the user to download and re-install the new version – dstarh Oct 08 '10 at 13:17
  • 1
    Yes, you are right. I also use Chrome and it self-updates without even telling ya. I like it and have started adopting a similar mechanism in my own software (for optional use). – dyasta Apr 23 '11 at 18:45
1

In the .NET world you might want to take a look at ClickOnce deployment.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Jakub Konecki
  • 45,581
  • 7
  • 87
  • 126