Enable support for trusty ESM
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ubuntu-advantage-tools (Ubuntu) |
Fix Released
|
Critical
|
Andreas Hasenack | ||
Trusty |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Impact]
Trusty is about to enter ESM (Extended Security Maintenance). While a new ubuntu-
[Test Case]
* Install ubuntu-
sudo apt install ubuntu-
* Verify that it says esm is not avaiable:
$ ubuntu-advantage status
livepatch: disabled
esm: disabled (not available)
fips: disabled (not available)
* Update the client to the version in proposed and run status again. This time it should have no remark about esm being not available:
$ ubuntu-advantage status
livepatch: disabled
esm: disabled
fips: disabled (not available)
[Regression Potential]
The existing trusty ubuntu-
[Other Info]
There will be a new update soon, that completely revamps the package. That will be subject to a new, different, SRU.
Xenial and later are not being updated with these changes because there is no ESM for those releases.
Finally, I re-enabled the test suite at package build time, which had been disabled in a previous upload.
Changed in ubuntu-advantage-tools (Ubuntu): | |
assignee: | nobody → Andreas Hasenack (ahasenack) |
importance: | Undecided → Critical |
status: | New → In Progress |
description: | updated |
description: | updated |
description: | updated |
tags: |
added: verification-done removed: verification-needed |
Changed in ubuntu-advantage-tools (Ubuntu): | |
status: | In Progress → Fix Released |
Thanks, questions about this upload:
How do I know that keyrings/ ubuntu- esm-v2- keyring. gpg is authentic? Not that I don't trust you, but when dealing with the installation of gpg keys that will be trusted by apt, it is useful to have a trust path that can be independently verified by someone other than the uploader (even if the set of people that can verify it is still limited, e.g. archive admins etc).
--- ubuntu- advantage- tools-10ubuntu0 .14.04. 2/apt.conf. d/51ubuntu- advantage- esm advantage- tools-10ubuntu0 .14.04. 3/apt.conf. d/51ubuntu- advantage- esm Upgrade: :Allowed- Origins { id}ESM: ${distro_ codename} -security" ;
1970-01-01 00:00:00.000000000 +0000
+++ ubuntu-
2019-04-18 17:24:38.000000000 +0000
@@ -0,0 +1,3 @@
+Unattended-
+ "${distro_
+};
I think this is worth calling out in the changelog, since it changes the configuration of the system for all users even if the user does not enable esm.
+_apt_add_auth() {
+ local repo_host="$1"
+ local credentials="$2"
+
+ local login password
+ login=$(echo "$credentials" | cut -d: -f1)
+ password=$(echo "$credentials" | cut -d: -f2)
+ [ -d "$APT_AUTH_DIR" ] || mkdir -p "$APT_AUTH_DIR"
+ [ -f "$APT_AUTH_FILE" ] || touch "$APT_AUTH_FILE"
+ chmod 600 "$APT_AUTH_FILE"
+ echo "machine ${repo_host}/ login ${login} password ${password}" \
+ >>"$APT_AUTH_FILE"
+}
Does this mean that if I run 'ua enable-esm' twice, the file gets two entries? (Should this instead be > instead of >> so that it's idempotent?)
+_apt_remove_auth() {
+ local repo_host="$1"
+
+ sed -i "/^machine ${repo_host}\/ login/d" "$APT_AUTH_FILE"
+}
Given that this file is /etc/apt/ auth.conf. d/90ubuntu- advantage which is exclusive to ESM, why sedding this out instead of deleting the file?
+deb https:/ /${ESM_REPO_ HOST}/ubuntu ${SERIES}-updates main /${ESM_REPO_ HOST}/ubuntu ${SERIES}-updates main
+# deb-src https:/
+EOF
I would suggest that we don't enable -updates at this stage, and defer that until the new client lands.