Go to file
Stephen Demos af61458371 cmd: add very simple cmdline omaha server
this implementation uses the TrivialServer that is already provided by
the go-omaha library. it is a very simple wrapper, simply asking for the
file, version, and listening address on the command line. it can only
handle one package at a time, naming the payload from the server
"update.gz", which is the standard filename for the update payload. the
additional metadata required for package creation is generated based on
the provided file. when the server is setup, update_engine can be
pointed at it by setting the SERVER variable in /etc/coreos/update.conf
2017-12-07 16:16:34 -08:00
cmd/serve-package cmd: add very simple cmdline omaha server 2017-12-07 16:16:34 -08:00
fixtures feat(omaha): add a machineid field 2014-03-17 14:29:04 -07:00
omaha Revert "update_engine_events.go: Add a custom "InstallStarted" event." 2017-08-07 13:19:09 -07:00
vendor/github.com vendor: vendor glide dependencies 2017-12-05 14:46:15 -08:00
.gitignore cmd: add very simple cmdline omaha server 2017-12-07 16:16:34 -08:00
.travis.yml travis: test against go 1.7 and 1.8 2017-04-21 14:12:44 -07:00
CONTRIBUTING.md CONTRIBUTING: fix line wrapping 2015-10-14 08:48:41 -07:00
DCO chore(contributing): clean up CONTRIBUTING.md and split out DCO 2014-04-04 10:40:37 -07:00
LICENSE feat(*): initial commit 2014-01-19 12:25:11 -08:00
Makefile cmd: add very simple cmdline omaha server 2017-12-07 16:16:34 -08:00
NOTICE NOTICE: Bump copyright year 2017-02-10 09:36:49 -08:00
README.md client: send "Complete" event in update checks 2017-06-09 18:40:25 -07:00
code-of-conduct.md update code of conduct copy 2016-08-09 13:19:44 -07:00
glide.lock glide: add glide yaml files 2017-12-05 14:45:21 -08:00
glide.yaml glide: add glide yaml files 2017-12-05 14:45:21 -08:00

README.md

Go Omaha

Build Status GoDoc

Implementation of the omaha update protocol in Go.

Status

This code is targeted for use with CoreOS's CoreUpdate product and the Container Linux update_engine. As a result this is not a complete implementation of the protocol and inherits a number of quirks from update_engine. These differences include:

  • No offline activity tracking. The protocol's ping mechanism allows for tracking application usage, reporting the number of days since the last ping and how many of those days saw active usage. CoreUpdate does not use this, instead assuming update clients are always online and checking in once every ~45-50 minutes. Clients not actively updating should send only a ping, indicating CoreUpdate's "Instance-Hold" state. Clients requesting an update should send a ping, update check, and an UpdateComplete:SuccessReboot event indicating CoreUpdate's "Complete" state.

  • Various protocol extensions/abuses. update_engine, likely due to earlier limitations of the protocol and Google's server implementation, uses a number of non-standard fields. For example, packing a lot of extra attributes such as the package's SHA-256 hash into a "postinstall" action. As much as possible the code includes comments about these extensions.

  • Many data fields not used by CoreUpdate are omitted.