Public bug reported: 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 * It depends on golang-1.23-go at build time, which is available on jammy-updates. * 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 (provided the toolchain is also backported, see and LP: #2103997 and LP: #2085834). * 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 on Jammy. * 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). [ 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. (Optional) 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. (Optional) 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). If the changes in wsl-pro-service landed before ubuntu-pro-client v35, we'd have issues with livepatch already described. I judge that as almost impossible since the SRU bug LP: #2083973 is older and is very likely to handle any regressions in time. [ 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. ** Affects: wsl-pro-service (Ubuntu) Importance: Undecided Status: New ** Affects: wsl-pro-service (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: wsl-pro-service (Ubuntu Jammy) 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 Status in wsl-pro-service package in Ubuntu: New Status in wsl-pro-service source package in Jammy: New 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 * It depends on golang-1.23-go at build time, which is available on jammy-updates. * 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 (provided the toolchain is also backported, see and LP: #2103997 and LP: #2085834). * 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 on Jammy. * 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). [ 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. (Optional) 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. (Optional) 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). If the changes in wsl-pro-service landed before ubuntu-pro-client v35, we'd have issues with livepatch already described. I judge that as almost impossible since the SRU bug LP: #2083973 is older and is very likely to handle any regressions in time. [ 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 : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
