No description
Find a file
2018-01-04 12:20:50 -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
code-of-conduct.md update CoC 2018-01-04 12:20:50 -08: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
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
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 readme: add instructions for a manual update 2017-12-19 11:22:59 -08:00

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.

serve-package

This project includes a very simple program designed to serve a single Container Linux package on the local host. It is intended to be used as a manual updater for a machine that is not able to use a full-fledged CoreUpdate instance. Binaries are available for each released version on the releases page. serve-package can also be built from source using the provided Makefile:

make

The binary will be available in the bin/ folder.

It is recommended that the server be run directly on the machine you intend to update. Go to the Container Linux release notes and find the version number for the release you would like to update to. The update payload can be retrieved from

https://update.release.core-os.net/amd64-usr/<version>/update.gz

where <version> is the version number you retrieved from the releases page. For example, https://update.release.core-os.net/amd64-usr/1576.4.0/update.gz is the payload required to update to Container Linux version 1576.4.0.

Copy the update payload and the serve-package binary to the server you would like to update. serve-package can be run as follows:

./serve-package --package-file update.gz --package-version <version>

By default, the server listens on localhost:8000. This can be modified using the --listen-address option.

Next, update_engine needs to be configured to use the local server that was just set up:

echo "SERVER=http://localhost:8000/v1/update" | sudo tee -a /etc/coreos/update.conf

Restart update_engine and tell it to check for an update:

sudo systemctl restart update-engine.service
update_engine_client -check_for_update

If locksmithd.service is running, the machine will restart once it has updated to the latest version. Otherwise, watch the logs from update-engine.service to determine when the update is complete and the machine is ready to restart:

journalctl -u update-engine.service -f
# wait for a line that says "Update successfully applied, waiting for reboot"
sudo systemctl reboot