[MIR] open-vm-tools

Hm..
It seems this may not be necessary even as soon as 13.10 (kernel 3.11).

https://lkml.org/lkml/2012/11/5/502
and
https://lkml.org/lkml/2013/1/8/552

The vmw_vmci driver is in the Saucy (3.11) kernel tree and is configured as a kernel module.

I have heard rumor that "vmblock and vmxnet are going to be carried in the kernel for 13.10".

If we have disk and network drivers, and 'vmw_vmci', what do we get out of open-vm-tools ? Are those things necessary?

Hm.. I've read more of your info there. I without fully reading I was thinking that the primary motivation for this was -dkms. sorry for the noise. But what would the tools get us in a cloud image if we have disk, net and vmci drivers?

All drivers supported by vSphere/ESXi have been accepted upstream as of the 3.9 kernel, these are:
- vmxnet3 (our virtual NIC) = Accepted in the 2.6.32 kernel and began shipping in the Ubuntu 10.04 release
- vmw_pvscsi (our virtual HBA) = Acceted in the 2.6.33 kernel and began shipping in the Ubuntu 10.04 release
- vmware_balloon (memory balloon driver) = Accepted in the 2.6.34 kernel and began shipping in the Ubuntu 10.10 release
- vmwgfx (virtual graphics driver) = Accepted in the 3.2 kernel and began shipping in the Ubuntu 12.04 release.
- vsock and vmw_vmci (virtual socket interface and virtual communication channel) = Accepted in the 3.9 release and appears to be included in the latest Ubuntu 13.10 Alpha

vmxnet and vmblock are obsolete, so don't worry about those drivers.

VMware personal desktop products, Workstation and Fusion, have one more driver called hgfs. This driver has not been contributed upstream, but we are looking into obsoleting the need for this driver by using FUSE if we get the performance required.

Going forward, Open-VM-Tools project will only consist of user-space apps.

Regarding the question: what would the tools get us in a cloud image, here is some more details for you:

Open-VM-Tools is a suite of open source virtualization utilities that improves the functionality, administration and management of virtual machines on VMware hypervisors.

Benefits of bundling Open-VM-Tools with the guest operating system:

- When Open-VM-Tools is bundled with the operating system, users get the best out-of-box experience to efficiently deploy virtual machines on VMware virtual infrastructure.
- Eliminates the need to separately install VMware Tools when Open-VM-Tools is bundled with the operating system because Open-VM-Tools is a fully supported open source implementation of VMware Tools.
- Reduces operational expenses and virtual machine downtime because updates to Open-VM-Tools packages are provided with the operating system maintenance updates and patches. This eliminates separate maintenance cycles for VMware Tools updates.
- No compatibility matrix checking required for Open-VM-Tools. Adhering to vSphere compatibility matrix for the guest OS release is sufficient.
- Open-VM-Tools bundled with the operating system provides a compact foot-print optimized for each OS release.

Open-VM-Tools consist of the following three packages:

open-vm-tools package

This package contains the core Open-VM-Tools user-space programs and libraries, including vmtoolsd, that provide the following features:

- Synchronization of the guest OS clock with the virtualization platform
- Enables the virtual infrastructure to perform graceful power operations (shut down) and file system quiescing of the virtual machine
- Provides a heartbeat from guest to the virtualization infrastructure to support vSphere High Availability (HA)
- Publishes information about the guest OS to the virtualization platform, including resource utilization and networking information
- Provides a secure and authenticated mechanism to perform various operations within the guest OS from the virtualization infrastructure
- Accepts additional plug-ins that can extend or customize Open-VM-Tools functionality

open-vm-tools-desktop package

This optional package extends Open-VM-Tools with additional user-space programs and libraries to improve interactive functionality of virtual machines when hosted on VMware's Workstation or Fusion products. The following features are enabled by this package:
- Enables text copy and paste operation between host and guest (either direction)
- Enables drag and drop operation between host and guest (either direction)
- Enables guest screen resizing

open-vm-tools-devel package

This optional package extends Open-VM-Tools with additional user-space libraries for developers and contains:
- Libraries for developing vmtoolsd plug-ins
- Documentation for the libraries

Just added my Saucy Prep branch. I'm waiting for new upstream release to create the proposal, should be any day now (they just released VMware Player 6 today).

So the -dkms part is not nessasary for Saucy. The package that we need is really open-vm-tools which is the cli tools for the images and guest information which is reported to the hypervisor. For ESXi and clouds based on VMware, this will give the hypervisor the ability to modfiy the guest.

I'm generally ignorant on open-vm-tools and vmware as a hypervisor, so please forgive me for asking questions that may seem obvious.

There are really 2 things that are being raised here in this bug, and
I'd like for them to be addressed separately.
a.) Inclusion in Ubuntu main (moving from multiverse).
   This brings maintenance cost to ubuntu with respect to security
   updates to open-vm-tools, and increases the support lifetime of this
   package for Ubuntu.

   Note also that typically packages move from universe to main.
   Why was this package in multiverse originally? That is normally
   an indication of unsupportability due to licensing.

   Other than increased burden on Ubuntu developers for support,
   there is very little difference between main and Universe to a user.

b.) Inclusion in the cloud image
   This increases the footprint of the cloud image by ~ 3MB for the
   package itself. As it is packaged in saucy right now, it also
   carries significant dependencies due to its 'recommends' that result
   in 28M of footprint. Installed with '--no-install-recommends'
   would change that to only 'zerofree' as the additional dependency.
   If that is a true dependency, you will also have to file a MIR for
   that package.

   Additionally, the inclusion in the cloud image means that users of
   this cloud image on other hypervisors are:
    - possibly vulnerable to security issues found in this package or its
      dependencies.
    - have increased memory footprint if any persistent processes are
      run by the package.
    - have unnecessary disk and network IO as a result of 'apt-get
      upgrade' for updates to these unecessary packages.

Above I see the following statements from John and Ben:

> - When Open-VM-Tools is bundled with the operating system, users get
> the best out-of-box experience to efficiently deploy virtual machines
> on VMware virtual infrastructure.

"best out of box experience" doesn't really tell me anything.

> - Eliminates the need to separately install VMware Tools when
> Open-VM-Tools is bundled with the operating system because
> Open-VM-Tools is a fully supported open source implementation of
> VMware Tools.

What I asked was why would we want them in the images. Clearly if the
user is going to install a package and that package is already
installed, its a win for that user. That argument applies to Xorg or
libre-office though, and I'm not going to include them in the cloud
images based on that argument.

> - Reduces operational expenses and virtual machine downtime because
> updates to Open-VM-Tools packages are provided with the operating
> system maintenance updates and patches. This eliminates separate
> maintenance cycles for VMware Tools updates.

We already have this through our security updates and SRU process, and
the fact that the open-vm-tools are in universe. Nothing here changes
if we include the tools in main or in the cloud image.

> - No compatibility matrix checking required for Open-VM-Tools.
> Adhering to vSphere compatibility matrix for the guest OS release is
> sufficient.

I'm sorry, but I really dont know what that means. How does inclusion
in ...

Thank you Scott for a list of concerns. I'll try to address them.

Regading installing them by default in the cloud images.

Concerns from Scott's comment #7

a.) Inclusion in Ubuntu main (moving from multiverse).

Actually, it is in multiverse. It was moved on the 2013-09-04 owing to the fact that there was no reason that it should be in multiverse. It is also in Debian Main right now.

b.) Inclusion in the cloud image

Dropped for the default cloud-image. After a rather lengthy offline conversations, the use case of open-vm-tools in the default cloud images is pretty weak. As a justification of this MIR, the default cloud images are tangential. However we will be delivering cloud images to vCHS that _will_ need open-vm-tools. See ( http://arstechnica.com/information-technology/2013/08/ubuntu-joins-windows-and-centos-but-not-red-hat-on-vmware-public-cloud/ )

For delivery of images to vCHS, it is a grey area, howerver, delivering a fully-main image is better than the alternatives; I'll freely admit that this is a weak argument.

> I explicitly do not like "the ability to modify the guest". I'm very
> much adverse to Microsoft's attempt at the same thing in walinux-agent,
> giving their hypervisor the ability to run arbitrary code as root inside
> the instance. I think this is unsupportable design and do not want to
> facilitate it.

I agree with this concern fully, however, the fact remains that for VMware based server and clouds, there is no concept of meta-data sources (AFAIK). Well the cloud-init method of provisioning is our best-practice position, for clouds that are based on VMware, the agent configures the machine. For cloned images, the tools are the method of configuring a new identity. And it has been the way that things are done for a long time in the VMware world.

> open-vm-tools is already bundled for the Ubuntu operating system. It is available in universe. Nothing really changes here by including in main or in the image itself.

Well, from a support stand point, yes things do change. The general axoim for cloud-images is that we shouldn't ship any image that does not include something that is not from main.

Also, inclusion in main means that open-vm-tools can be included on the CD Image for people doing manual installation -- that question is out of scope for this MIR, but it is worth considering.

However, things do change by it being promoted to main. The biggest is that by definition, something is main is officially supported, while universe is community supported. So by adding the package to main, it becomes the official Ubuntu package for VMware users. If your argument is that promotion from universe to main offers no value or no change, then the definition of a universe or main package is meaningless.

The most compelling reason I see to add it is that the VMware propriteary tools are not managed. By having an Ubuntu officially recognized package for VMware hypervisors, users who seek commericial support from Canonical will have it supported.

> I explicitly do not like "the ability to modify the guest". I'm very much adverse to Microsoft's attempt at the same thing in
> walinux-agent, giving their hypervisor ...

Seems like it has a security surface, so I'll assign to Jamie to look at.

Is the Canonical server team looking after this package?

>> I explicitly do not like "the ability to modify the guest". I'm very
>> much adverse to Microsoft's attempt at the same thing in
>> walinux-agent, giving their hypervisor the ability to run arbitrary code
>> as root inside the instance. I think this is unsupportable design and do
>> not want to facilitate it.

> This concern is really about the images, not about the fitness of the
> package for main.

Only "sort of".

> I also think that the concern is valid for systems where there is a
> facility for first boot provisioning, but invalid on systems where agent
> provisioning is needed. And I think that this is really an ideological
> one. To say that we don't want to facilitate it means that we are
> leaving users that use or run on first-bootless hypervisors. But the
> same could be said for chef and puppet, and other configuration
> management suites; the difference here is who is running the code.

Yes. That is the important difference. If a user changes something in
their "first boot" code, and it breaks, its their fault, or at very least
they have control to fix it, because they (should) know exactly what they
changed, and can update or address it.

If the hypervisor changes the code that *it* chooses to execute on the
users' behalf from inside their VMs, and *that* breaks, whose fault is it?

My issue with this is not hypervisor vendor nor hypervisor specific. The
issue is that some party other than the user is going to attempt to
execute code inside the instance, and that Ubuntu cannot know what that
code is, nor control its behavior or release process. In order to be
"cross distro", this code is quite likely to do things like check
/etc/lsb_release or /etc/issue, and try to derive information from other
files in /etc/ (/etc/udev.d, /etc/shadow ..). It also possibly does
things that Ubuntu would not certify as "supported". Perhaps it enables
additional repositories or loads additional kernel modules.

There is no sane way in which Ubuntu could hope to keep our code working
across releases or even within an SRU. Any change Ubuntu makes can
potentially break this code.

There is essentialy no difference here between *user* written code that
does that and hypervisor-vendor written code, other than who can fix the
code. If the change comes from the hypervisor, then the user quite
possibly has no way to fix, and Ubuntu quite possibly has no way to fix.
This leaves the user and ubuntu dependent on the hypervisor to never break
anything.

There is a shift here from the "platform" that code ran on being bios and
hardware to being some all knowing entity that changes from day to day.
From the OS perspective, this is very difficult to support.
That is what scares me.

>> Arguably, in a cloud scenerio, a user has to inherently trust the
>> vendor..

>> If our goal is to be the best operating system in the cloud, then
>> providing for a supported, official way to provision on systems like
>> WIndows Azure and VMware just make sesne. Ideology asside, the question
>> should be whether the package meets the contraints of main inclusion
>> and if the package is useful.

Its not just idealogy. By putting this in main, we're essentially
pro...

In response to Smoser's comment #10
> My issue with this is not hypervisor vendor nor hypervisor specific. The
> issue is that some party other than the user is going to attempt to
> execute code inside the instance, and that Ubuntu cannot know what that
> code is, nor control its behavior or release process. In order to be
> "cross distro", this code is quite likely to do things like check
> /etc/lsb_release or /etc/issue, and try to derive information from other
> files in /etc/ (/etc/udev.d, /etc/shadow ..). It also possibly does
> things that Ubuntu would not certify as "supported". Perhaps it enables
> additional repositories or loads additional kernel modules.

Have you read the code? Rather than beating up some academic concern, which may or may not have any basis in fact, it would be more constructive to identify specific areas of concern. Saying that it "possibly does things that Ubuntu would certify" with out supporting it is to make an unwarranted accusation.

> There is no sane way in which Ubuntu could hope to keep our code working
> across releases or even within an SRU. Any change Ubuntu makes can
> potentially break this code.

Are you actually implying that we should not include things in main which might get broken between releases? Looking over the bug this,

This is a Red Herring. Changes to the base of Ubuntu happen with each releases, and with each release things are broken and fixed. Open-vm-tools has been around since Lucid in Ubuntu, and the package was first created in 2007. If the criteria to exclude something from main is because it might break with a future upgrade, then nothing should be included in main -- including Cloud-init and other packages.

Essentially you are arguing the "who's going to maintain this code," question. And the answer here is that upstream source pro-actively considers the needs of Ubuntu. Ubuntu is treated as a first-class citizen in the VMWare world.

> There is essentially no difference here between *user* written code that
> does that and hypervisor-vendor written code, other than who can fix the
> code. If the change comes from the hypervisor, then the user quite
> possibly has no way to fix, and Ubuntu quite possibly has no way to fix.
> This leaves the user and ubuntu dependent on the hypervisor to never break
> anything.
If I am understanding the code properly, the auto-upgrade functionality is _not_ implemented in the open-vm-tools. The only reference to the ability to upgrade is in lib/include/vmware/guestrpc/tclodefs.h, where a constant is defined. However, I can find no code that actually handles that upgrade. This would mean that there is a difference between the proprietary tools and the open-vm-tools. It also means that this concern is moot. Please feel free to examine the code and prove me wrong on this point.

However, there is an ability to run scripts on the machine. This functionality is exposed services/plugins/vix/vixTools.c. What this allows is for an authenticated user to run an arbitrary script. I would note that there are many tools that allow a user to run arbitrary scripts, with SSH being perhaps the most famous. Just because the trigger for running the...

Adding a comment to try to summarize the current state of the bug.

It looks like Ben has addressed or at least replied to Scott's comments.

The other open questions are from comment 9:
> Seems like it has a security surface, so I'll assign to Jamie to look at.
> Is the Canonical server team looking after this package?

I can say Canonical Ubuntu Cloud Ecosystem team will look after the packaging. open-vm-tools is in Debian main, and we will submit bugs directly to the upstream when not addressed by Debian, and work to get those fixes into Debina for subsequent syncing. Does this address the remaining issues with open-vm-tools or are there outstanding issues?

Thanks for everyone's time in reviewing this package.
-Antonio

I reviewed open-vm-tools version 2013.04.16-1098359-0ubuntu2 as checked
into saucy. This should not be considered a full security review, but
rather a quick gauge of code maintainability.

There are a lot of moving pieces in this package; I certainly cannot claim
to have studied much of it, but I aimed primarily for finding rough edges
around the backdoor execution mechanisms. Scott Moser raises many good
points about the difficulty of reasoning about a system's sanity from
within the system when a 'backdoor' is so readily available, but I do not
believe this package significantly changes the problem. The hypervisor is
necessarily completely trusted and it is at the whim of the hypervisor
administrators to destroy, damage, or degrade service within a guest.

The backdoor communication channel exists without this package and can be
used by a variety of third-party tools regardless of the presence of this
package. The hypervisor already has the feature and (as I understand) it
cannot be disabled -- though portions of it can be administratively
controlled from the hypervisor itself.

I further understand that access can be limited within the guest by
restricting the CAP_SYS_RAWIO capability or denying iopl(2) and ioperm(2)
systemcalls via seccomp2 filters. (None of which is helped nor hindered by
this package.)

So I do not worry about this package providing a less visible
administrative interface: this issue already largely exists through
less convenient mechanisms with all hypervisors. (And, one could argue,
through the firmwares of physical hardware devices, absent hypervisors.)

- open-vm-tools provides a variety of guest services for use with the
  VMware family of hypervisors, including host-guest filesystems, shared
  copy-and-paste facilities, environment control, and ability to execute
  code within the guest.
- Build-deps autotools, doxygen, libcunit, libdumbnet, libfuse, libgtk2.0,
  libgtkmm-2.4, libicu, libnotify, libpam0g, libprocps0, libx11,
  libxinerama, libxss, libxtst, gcc-4.7
- Depends on ethtool, zerofree, xauth, xdg-utils
- SSL stubs exist to disable SSL, go figure...
- Provides variety of services, some via daemons, some via loadable kernel
  modules. vmtoolsd at least properly daemonizes.
- Initscripts looked fine
- No dbus
- One setuid executable, vmware-user-suid-wrapper, looked safe
- No sudo fragments
- No cronjobs
- Udev file looked safe
- Tests look built during build, but don't appear to be run during build
- Build looks clean; uses -Werror

Many lintian warnings and errors:
- hardening-no-fortify-functions
- latest-debian-changelog-entry-without-new-version
- manpage-has-errors-from-man
- binary-without-manpage
- malformed-override

The hardening-no-fortify-functions warning may be a spurious warning; I see
-D_FORTIFY_SOURCE=2 throughout the build logs.

- open-vm-tools does spawn programs. The interfaces look overly
  complicated to try to support multiple operating systems from one
  codebase, the environment handling routines are quite complicated, and
  there's some surprising double-encoding of filenames, arguments. I'm
  skeptical of some of the quoted argument handling though I couldn't
  find flaws in it.
...

This is going to need MIRs for zerofree and libdumbnet. Can you please add MIR information for them to this bug's description?

Added dependency information for zerofree and libdumbnet.

zerofree looks mostly good. Very small, no important bugs, mostly in sync with Debian. But it needs a team bug subscriber for whomever is going to look after it in Ubuntu.

What's the maintenance story with libdumbnet? It is orphaned in Debian and seems slightly bitrotten. For example, the configure check for libcheck doesn't look in a multiarch directory (not that it matters, we disregard test results, but it's a sign of negelect).

Ben, zerofree still needs a team bug subscriber.

Added Canonical Cloudware team bug subscriptions for Zerofree and libdumnet.

I'm still curious about a statement of maintenance intent for libdumbnet. Being orphaned in Debian is troubling and implies Ubuntu would be doing more heavy lifting than usual for it.

Override component to main
zerofree 1.0.2-1ubuntu1 in trusty: universe/admin -> main
zerofree 1.0.2-1ubuntu1 in trusty amd64: universe/admin/extra/100% -> main
zerofree 1.0.2-1ubuntu1 in trusty arm64: universe/admin/extra/100% -> main
zerofree 1.0.2-1ubuntu1 in trusty armhf: universe/admin/extra/100% -> main
zerofree 1.0.2-1ubuntu1 in trusty i386: universe/admin/extra/100% -> main
zerofree 1.0.2-1ubuntu1 in trusty powerpc: universe/admin/extra/100% -> main
zerofree 1.0.2-1ubuntu1 in trusty ppc64el: universe/admin/extra/100% -> main
7 publications overridden.

The version of open-vm-tools that we are carrying in Ubuntu is based on a development snapshot. VMware has indicated that we should cary the current supported version (9.4, released on 2013.10.02). We should sync Debian here-on out.

The version in 14.04 is now based on the 9.4 release; we are no longer shipping the development snapshot.

OK, open-vm-tools itself looks fine. Seth reviewed it, and I looked at the packaging a bit.

Archive admins: when you promote this, I believe we just need open-vm-tools and open-vm-tools-dkms.

open-vm-tools is neither seeded nor required by another package. waiting until the libdumbnet MIR is complete and approved

Canonical's Cloudware team is confident that we can support libdumbnet. While it may have some rough edges, we have evaluated the package extensively. We will take ownership for issues related to this package.

Additionally, libdumbnet is know at libdnet for SuSE/SLES and Fedora/Red Hat/Centos. For both all of those distributions, libdnet is a supported package; Fedora 19 and RHEL 7 beta include the libdnet as part of shipping open-vm-tools as a default.

Alright, good enough for libdumbnet. I'd still like to see its test suite fixed up and enabled. But if the cloud team is on top of things (and they are subbed to bugs), we'll be able to fix any problems.

Override component to main
libdumbnet 1.12-4 in trusty: universe/libs -> main
libdumbnet-dev 1.12-4 in trusty amd64: universe/libdevel/optional/100% -> main
libdumbnet-dev 1.12-4 in trusty arm64: universe/libdevel/optional/100% -> main
libdumbnet-dev 1.12-4 in trusty armhf: universe/libdevel/optional/100% -> main
libdumbnet-dev 1.12-4 in trusty i386: universe/libdevel/optional/100% -> main
libdumbnet-dev 1.12-4 in trusty powerpc: universe/libdevel/optional/100% -> main
libdumbnet-dev 1.12-4 in trusty ppc64el: universe/libdevel/optional/100% -> main
libdumbnet1 1.12-4 in trusty amd64: universe/libs/optional/100% -> main
libdumbnet1 1.12-4 in trusty arm64: universe/libs/optional/100% -> main
libdumbnet1 1.12-4 in trusty armhf: universe/libs/optional/100% -> main
libdumbnet1 1.12-4 in trusty i386: universe/libs/optional/100% -> main
libdumbnet1 1.12-4 in trusty powerpc: universe/libs/optional/100% -> main
libdumbnet1 1.12-4 in trusty ppc64el: universe/libs/optional/100% -> main
python-dumbnet 1.12-4 in trusty amd64: universe/python/optional/100% -> main
python-dumbnet 1.12-4 in trusty arm64: universe/python/optional/100% -> main
python-dumbnet 1.12-4 in trusty armhf: universe/python/optional/100% -> main
python-dumbnet 1.12-4 in trusty i386: universe/python/optional/100% -> main
python-dumbnet 1.12-4 in trusty powerpc: universe/python/optional/100% -> main
python-dumbnet 1.12-4 in trusty ppc64el: universe/python/optional/100% -> main
19 publications overridden.

Override component to main
open-vm-tools 2:9.4.0-1280544-5ubuntu2 in trusty: universe/admin -> main
open-vm-dkms 2:9.4.0-1280544-5ubuntu2 in trusty amd64: universe/admin/extra/100% -> main
open-vm-dkms 2:9.4.0-1280544-5ubuntu2 in trusty arm64: universe/admin/extra/100% -> main
open-vm-dkms 2:9.4.0-1280544-5ubuntu2 in trusty armhf: universe/admin/extra/100% -> main
open-vm-dkms 2:9.4.0-1280544-5ubuntu2 in trusty i386: universe/admin/extra/100% -> main
open-vm-dkms 2:9.4.0-1280544-5ubuntu2 in trusty powerpc: universe/admin/extra/100% -> main
open-vm-dkms 2:9.4.0-1280544-5ubuntu2 in trusty ppc64el: universe/admin/extra/100% -> main
open-vm-toolbox 2:9.4.0-1280544-5ubuntu2 in trusty amd64: universe/admin/extra/100% -> main
open-vm-toolbox 2:9.4.0-1280544-5ubuntu2 in trusty arm64: universe/admin/extra/100% -> main
open-vm-toolbox 2:9.4.0-1280544-5ubuntu2 in trusty armhf: universe/admin/extra/100% -> main
open-vm-toolbox 2:9.4.0-1280544-5ubuntu2 in trusty i386: universe/admin/extra/100% -> main
open-vm-toolbox 2:9.4.0-1280544-5ubuntu2 in trusty powerpc: universe/admin/extra/100% -> main
open-vm-toolbox 2:9.4.0-1280544-5ubuntu2 in trusty ppc64el: universe/admin/extra/100% -> main
open-vm-tools 2:9.4.0-1280544-5ubuntu2 in trusty amd64: universe/admin/extra/100% -> main
open-vm-tools 2:9.4.0-1280544-5ubuntu2 in trusty i386: universe/admin/extra/100% -> main
open-vm-tools-dbg 2:9.4.0-1280544-5ubuntu2 in trusty amd64: universe/devel/extra/100% -> main
open-vm-tools-dbg 2:9.4.0-1280544-5ubuntu2 in trusty i386: universe/devel/extra/100% -> main
open-vm-tools-desktop 2:9.4.0-1280544-5ubuntu2 in trusty amd64: universe/admin/extra/100% -> main
open-vm-tools-desktop 2:9.4.0-1280544-5ubuntu2 in trusty i386: universe/admin/extra/100% -> main
open-vm-tools-dev 2:9.4.0-1280544-5ubuntu2 in trusty amd64: universe/devel/extra/100% -> main
open-vm-tools-dev 2:9.4.0-1280544-5ubuntu2 in trusty arm64: universe/devel/extra/100% -> main
open-vm-tools-dev 2:9.4.0-1280544-5ubuntu2 in trusty armhf: universe/devel/extra/100% -> main
open-vm-tools-dev 2:9.4.0-1280544-5ubuntu2 in trusty i386: universe/devel/extra/100% -> main
open-vm-tools-dev 2:9.4.0-1280544-5ubuntu2 in trusty powerpc: universe/devel/extra/100% -> main
open-vm-tools-dev 2:9.4.0-1280544-5ubuntu2 in trusty ppc64el: universe/devel/extra/100% -> main
open-vm-tools-dkms 2:9.4.0-1280544-5ubuntu2 in trusty amd64: universe/kernel/extra/100% -> main
open-vm-tools-dkms 2:9.4.0-1280544-5ubuntu2 in trusty arm64: universe/kernel/extra/100% -> main
open-vm-tools-dkms 2:9.4.0-1280544-5ubuntu2 in trusty armhf: universe/kernel/extra/100% -> main
open-vm-tools-dkms 2:9.4.0-1280544-5ubuntu2 in trusty i386: universe/kernel/extra/100% -> main
open-vm-tools-dkms 2:9.4.0-1280544-5ubuntu2 in trusty powerpc: universe/kernel/extra/100% -> main
open-vm-tools-dkms 2:9.4.0-1280544-5ubuntu2 in trusty ppc64el: universe/kernel/extra/100% -> main
31 publications overridden.

$ ./change-override -c main open-vm-tools-desktop
Override component to main
open-vm-tools-desktop 2:10.3.5-8 in disco amd64: universe/admin/extra/100% -> main
open-vm-tools-desktop 2:10.3.5-8 in disco i386: universe/admin/extra/100% -> main
Override [y|N]? y
2 publications overridden.

https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/commit/?id=5353c36718d103c8f8939a54a027104cadc1c8d5