© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
[Impact]
VMware Horizon is a VDI product that runs atop of VMware's normal virtualisation stack, and it supports SSO authentication for login.
In the past, the VMware Horizon agent has been pretty buggy, and requires SSO patches to be present to function, otherwise it breaks and causes entire outages for anyone trying to use the VDI.
To solve this, VMware had been custom compiling their own libgnome-shell.so libraries with their SSO patches, which are based on oVirt's SSO implementation. When you install VMware Horizon agent to the instance, it overwrites Ubuntu's libgnome-shell.so with their custom compiled one.
VMware don't keep their custom compiled libgnome-shell.so library up to date, so bugs that have already been fixed still live on in their library. Also, when Ubuntu updates our gnome-shell packages, it overwrites the custom libgnome-shell.so library, which then causes the Horizon agent to break, and causes outages for anyone using the VDI, which have to be solved by manually copying the custom library back.
This situation is untenable for VMware Horizon users, so I have asked VMware to upstream their SSO patches. After a long painful process, they have landed in gnome-shell master.
This SRU will significantly improve the quality of life for VMware Horizon users, and will remove the need for VMware to distribute custom libraries.
[Testcase]
You need an instance that runs on VMware Horizon, and the Horizon agent needs to be installed and running. Ideally, SSO authentication should be enabled to test all features, but it is not necessary to partially test.
Test packages are available in this ppa:
https:/
If you install the test package in a VMware Horizon VDI, the instance should come up cleanly after reboot and function properly, especially with SSO login.
The instance should be able to function without custom libgnome-shell.so libraries provided by VMware.
[Regression Potential]
The code refactors the oVirt SSO implementation into a more generalised interface, which other virtualisation platforms can use. oVirt has been transitioned to this interface as part of the refactoring, which means that any if the new oVirt SSO implementation is broken, it could break users running in oVirt.
VMware's patches also use the new generalised interface, which is much simpler than before, and it has been tested internally by VMware. There was a very long review process with upstream GNOME, which ironed out all of their concerns.
I have been reviewing the code along the way, and I am confident that it will not cause any regressions. If a regression did occur, then it would break SSO functionality only.
[Other Information]
Upstream Issue: https:/
Upstream merge-request: https:/
Commits:
commit 809f820cd4a4eeb
Author: yun341 <email address hidden>
Date: Sat, 4 Jan 2020 00:31:15 +0800
Subject: gdm: Refactor oVirt to a generic CredentialManager interface
Link: https:/
commit 4ea0fca4fc09ffd
Author: yun341 <email address hidden>
Date: Thu, 2 Jul 2020 06:54:55 +0800
Subject: gdm: Introduce vmware credential manager for pre-authenticated logins
Link: https:/