** Summary changed:
- [SRU] Backport wsl-pro-service to Jammy
+ [SRU] Backport wsl-pro-service to Jammy and Focal
** Also affects: wsl-pro-service (Ubuntu Focal)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to wsl-pro-service in Ubuntu.
https://bugs.launchpad.net/bugs/2107145
Title:
[SRU] Backport wsl-pro-service to Jammy and Focal
Status in wsl-pro-service package in Ubuntu:
New
Status in wsl-pro-service source package in Focal:
New
Status in wsl-pro-service source package in Jammy:
Incomplete
Bug description:
As part of our offerings to bring Ubuntu Pro to wider audiences we
need to backport this service to Ubuntu 22.04 LTS, so users can
benefit of the upcoming GA of Ubuntu Pro for WSL, as Windows system
that allows more easily secure and manage WSL instances, by
automatically pro-attaching Ubuntu on WSL instances and even register
with and manage them via Lansdcape.
wsl-pro-service is our bridge to the Windows application that performs
key post-provisioning actions on an instance, such as updating a Pro
token and Landscape configuration data if that changes on the Windows
side.
As this service is only applicable for Ubuntu on WSL, its systemd unit is
contained to not even start
if the condition `ConditionVirtualization=wsl` is unmet. systemd confinement
options were validated to work on Jammy as of wsl-pro-service version 0.1.18
(the one being proposed via this SRU).
[Impact]
* wsl-pro-service is a new package for Jammy and Focal
* It depends on golang-1.23-go at build time, which is available on
jammy-updates.
* A certain level of downgrades was necessary for focal, that requires
golang-1.22-go.
* Ubuntu Pro for WSL relies on this service being seeded on the Ubuntu
instances.
* That system is not yet generally available, but planned for later this year.
* At minimum Jammy and Noble must be supported, but Focal is planned.
* Beta customers were already provided with custom images of 22.04 and 24.04
from the get-go.
* As a new daemon, more often inert if the Windows side is not present, this
should not affect users experience.
* Boot time measurements reveals negligible impact.
* The systemd unit is carefully and purposefully confined to allow only
minimum requirements of our application while remaining compatible with systemd
v245 (thus, compatible with Jammy and Focal).
[ Test plan ]
== 1. Less loging:
* Make sure the Ubuntu Pro for WSL Windows agent is not running:
- On Windows run `taskkill /f /im ubuntu-pro-agent.exe`
- Depending on the OS settings elevated permissions might be required.
* Install wsl-pro-service version 0.1.18 on Ubuntu 22.04 on WSL.
* Follow it's journal with `journalctl -f -u wsl-pro.service`
* Notice that it starts logging connection attempts too often, backing off
exponentially up to 1min interval.
Approximately 10 minutes after attempting to connect without success, it
silents.
* systemd should take approximately 20 min to attempt to restart the unit.
== 2. Pro attachment works under systemd restrictions and without
livepatch being installed.
(Most of this test case would be testing ubuntu-pro-client v35 indeed, but we
must verify that our integration
is not harmed with the changes in wsl-pro-service systemd confinement)
* Create a fresh instance of Ubuntu on WSL:
- On Windows run `wsl.exe --install -d Ubuntu-22.04`
* Install ubuntu-pro-agent v35 (currently available via the `-proposed`
repository)
* Make sure livepatch is not installed: `sudo snap remove canonical-livepatch`
* Make sure the Ubuntu on WSL instance is not pro attached: `pro status`
(`pro detach` if needed).
* Install wsl-pro-service version 0.1.18 on Ubuntu on WSL (Noble, Oracular
and Plucky should behave exactly
the same)
* Install Ubuntu Pro for WSL (download the latest production build from
https://github.com/canonical/ubuntu-pro-for-wsl/actions/runs/14386282882/artifacts/2921576467)
* Follow this guide to attach your Pro token:
https://documentation.ubuntu.com/wsl/en/stable/tutorials/getting-started-with-up4w/#set-up-ubuntu-pro-for-wsl
* Follow it's journal with `journalctl -f -u wsl-pro.service`:
- If pro-attaching fails because of systemd restrictions we should see some
"permission denied" or "bad system
call" errors in the journal.
- If the livepatch fix was not correct, we should see mentions to
`canonical-livepatch` in the journal.
- Both conditions should be considered a failure. Otherwise, proceed.
* Confirm pro attachment `pro status` inside the Ubuntu instance.
* Finally assert that canonical-livepatch remains not installed on this
machine.
== 3. wsl-pro-service outside of WSL
(Ensures the unit does nothing outside of WSL)
* Install wsl-pro-service on an instance of Ubuntu 22.04 on any platform
other than WSL (Desktop,
Server bare-metal or VM, OCI containers).
* Verify that the unit is disabled due unmet condition: `systemctl status
wsl-pro.service`
== 4. Boot time
(Ensures the unit does not significantly impact the boot time duration)
* Install wsl-pro-service on an Ubuntu 22.04 instance on WSL.
* Modify the default user's .bashrc to just exit (by appending `exit` as the
last line of that script)
* On Windows PowerShell run `wsl --terminate Ubuntu-22.04; Measure-Command
{wsl -d Ubuntu-22.04}` a few times and take notes of the duration that command
takes to finish
* Start the WSL instance as root `wsl -d Ubuntu-22.04 -u root`
* Remove wsl-pro-service
* Repeat the measurement step
* Compare the results.
Spot differences are expected, because of the many layers involved,
but there should not be more than 2% difference in **median** between
boot times with and without that service enabled, per recent
measurements taken by our team.
[ Where problems could occur ]
The few beta customers we have might have noticed that up until now,
wsl-pro-service remains running all the time the unit is alive, thus anytime a
user installs the
Ubuntu Pro for WSL application on Windows they could expect the communication
with the Windows agents to start
briefly. That's also the case for the custom 22.04 images they've been
playing with, which come with wsl-pro-service 0.1.5.
With the behaviour changes in v0.1.18, that won't be the case always, as the
service could just had quit seconds before
and systemd will take about 20min to restart it. Users can always `sudo
systemctl restart wsl-pro.service`.
Since the entire system is not yet generally available the number of users
affected by this behaviour change
is very minimal, comprising of a handful of beta testers and internal
collaborators (such as the
Landscape team).
[ Other Info ]
I intentionally skipped testing the changes related to Landscape because it's
too complex to set up a server
just for this purpose.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/wsl-pro-service/+bug/2107145/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
