yahoo-eng-team team mailing list archive

[Launchpad Bug Tracker <1944946@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package open-vm-tools -
2:11.3.0-2ubuntu0~ubuntu21.04.2

---------------
open-vm-tools (2:11.3.0-2ubuntu0~ubuntu21.04.2) hirsute; urgency=medium

  * d/rules: provide a compat link for the old open-vm-tools
    library/plugin paths (LP: #1944946)
    - d/open-vm-tools.postinst: handle upgrades from <11.3.0-2 in regard
      to the symlink

 -- Christian Ehrhardt <christian.ehrhardt@xxxxxxxxxxxxx>  Tue, 12 Oct
2021 07:50:08 +0200

** Changed in: open-vm-tools (Ubuntu Hirsute)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1944946

Title:
  Path of open-vm-tools libdeployPkgPlugin.so is now multi-arch
  compliant breaking cloud-init

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Triaged
Status in open-vm-tools package in Ubuntu:
  Fix Released
Status in cloud-init source package in Focal:
  New
Status in open-vm-tools source package in Focal:
  Fix Committed
Status in cloud-init source package in Hirsute:
  New
Status in open-vm-tools source package in Hirsute:
  Fix Released

Bug description:
  [Impact]

   * The package correctly fixed a non multiarch path, but we missed
     that some depending SW might have mad assumptions on the old paths.
     One such SW is cloud-init which in certain cases now fails to detect
     and configure vmware correctly.

   * In the long run (next Debian and 22.04) we will keep only the new
     paths. But for 21.10 time is too short and even more so for the SRUs
     that we regularly do back to at least the last LTS.
     There we want to mitigate the impact by adding a compat link on the
     old path.

  [Test Plan]

   * We need to configure cloud-init to check for VMware IVMF data and we
     will see that without the fix it is failing to be detected.

   * Set up Ubuntu in VMWare if you do not ahve any ESXi then VMWare
  Workstation player 16 for Ubuntu as trial from
  https://www.vmware.com/products/workstation-player/workstation-player-
  evaluation.html is enough.

  # Reduce the ouput a bit for readability and make it not skip vmware
  $ echo "datasource_list: [NoCloud, OVF]" < sudo tee /etc/cloud/cloud.cfg.d/99_test.cfg
  $ echo "disable_vmware_customization: false" | sudo tee -a /etc/cloud/cloud.cfg.d/99_test.cfg
  # Run ds-dentify with debug on
  $ sudo DEBUG_LEVEL=5 DI_LOG=stderr /usr/lib/cloud-init/ds-identify --force
  # Check the result
  $ cat /run/cloud-init/cloud.cfg

  Bad case example:
  ...
  Checking for datasource 'OVF' via 'dscheck_OVF'
  Running on vmware but rpctool query returned 1: No value found
  check for 'OVF' returned not-found[1]
  found= maybe=
  No ds found [mode=search, notfound=disabled]. Disabled cloud-init [1]
  [up 3554.80s] returning 1

  And the result is:
  $ cat /run/cloud-init/cloud.cfg
  di_report:
    datasource_list: [ ]
    # reporting not found result. notfound=disabled.

  Good case example:
  ...
  Checking for datasource 'OVF' via 'dscheck_OVF'
  Running on vmware but rpctool query returned 1: No value found
  /etc/cloud/cloud.cfg.d/99_test.cfg set disable_vmware_customization to false
  check for 'OVF' returned found
  found=OVF maybe=
  Found single datasource: OVF
  [up 3357.93s] returning 0

  And the result is:
  $ cat /run/cloud-init/cloud.cfg
  datasource_list: [ OVF, None ]

  Note: VMware who spotted this will do a verification as well on this
  case.

  [Where problems could occur]

   * Since we do not remove, but add a link (that exactly matches the
     formerly used path) I'm not too concerned. The issue I can think of
     would be e.g. security policies that prevent .so files to load through
     symlinks or anything like that. But in that case still the upload
     would not further degrade things, it would just not fix it.
     Test wise this is all about guest customizations and VMware plugin and
     VMware as usual will do checks for that when this is in verification.

  [Other Info]

   * Down the road we still want to drop that path, it is only added now to
     temporarily mitigate such issues. Therefore we do NOT want to have that
     in 22.04 for a long time, and will most likely drop it there soon to
     spot further issues with it.
   * For the same reason I'm also not uploading it to Debian via
     https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/merge_requests/11 there the active release isn't affected yet
     and the next one shall go without (like 22.04)
   * But for active Ubuntu release which got the backport I'd want to
     SRU fix it despite also having the cloud-init fix later on, since we do
     not know which other SW might rely on that path.

  ------

  Problem:
  the path of plugin libdeployPkgPlugin.so of open-vm-tools is changed and guest customization will fail for ubuntu 21.10 beta image

  Description:
  Ubuntu 21.10 have new open-vm-tools 11.3.0. with this new open-vm-tools, the plugin libdeployPkgPlugin.so is put to directory /usr/lib/x86_64-linux-gnu/open-vm-tools/plugins/vmsvc/.

  In previous open-vm-tools version (such as 11.2.5), the the plugin
  libdeployPkgPlugin.so is put to directory /usr/lib/open-vm-
  tools/plugins/vmsvc/

  The path change of plugin libdeployPkgPlugin.so will cause the guest
  customization failure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1944946/+subscriptions