vbatts
/
go-omaha
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
117 Commits 2 Branches 0 Tags 204 KiB
Go 99.6%
Makefile 0.4%
Go to file
Michael Marineau 03222d488c client: support sending events asynchronously 
Makes blocking and waiting for success/error optional, also allows
concurrent use of the rest of the client while events are sent.
 		2017-06-09 18:40:25 -07:00
fixtures feat(omaha): add a machineid field 2014-03-17 14:29:04 -07:00
omaha client: support sending events asynchronously 2017-06-09 18:40:25 -07:00
.gitignore Initial commit 2013-03-27 16:59:16 -07: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
NOTICE NOTICE: Bump copyright year 2017-02-10 09:36:49 -08:00
README.md README: explain implementation status in more detail 2017-05-25 14:29:35 -07:00
code-of-conduct.md update code of conduct copy 2016-08-09 13:19:44 -07: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. Each check in should include a ping and optionally an update check.

  • 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.