← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1944946] Re: Path of open-vm-tools libdeployPkgPlugin.so is now multi-arch compliant breaking cloud-init

 

cloud-init fix has been committed upstream via
https://github.com/canonical/cloud-init/pull/1061

** Also affects: cloud-init
   Importance: Undecided
       Status: New

** Changed in: cloud-init
       Status: New => Fix Committed

-- 
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:
  Triaged
Status in cloud-init source package in Hirsute:
  New
Status in open-vm-tools source package in Hirsute:
  Triaged

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

  ------

  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