## Bug Fixes - Resolved a failure in the `windows_feature_powershell` resource introduced in Chef Infra Client 17.8. ## Compliance Phase ### InSpec 4.52.9 Updated InSpec from 4.50.3 to 4.52.9 with the following improvements: - Added remote target support for Alpine Linux. - Added the ability to specify a proxy as a parameter in the http resource. - Added support for TLS 1.3 to the ssl resource. - Fixed an edge case in the service resource where InSpec may falsely detect services as enabled on FreeBSD if that service is the suffix of another enabled service. - Fixed the ibmdb2_session resource so that it now correctly accepts queries with clauses. - Fixed the oracledb_session resource to properly handle nil in the query output. - Fixed the packages resource to correctly list only installed packages on Alpine Linux. ## Secrets Manager Integrations ### HashiCorp Vault AppRole Support The `secrets` helper now supports fetching secrets from HashiCorp Vault using AppRole authentication. Fetching secret data using an AppRole ID and an associated AppRole Secret ID: ```ruby secret(name: 'secret/example', service: :hashi_vault, config: { vault_addr: 'vault.example.com', auth_method: :approle, approle_id: "11111111-abcd-1111-abcd-111111111111", approle_secret_id: "22222222-abcd-2222-abcd-222222222222" }) ``` Fetching secret data using a token and an AppRole name creates a SecretID associated with that AppRole: ```ruby secret(name: 'secret/example', service: :hashi_vault, config: { vault_addr: 'vault.example.com', auth_method: :approle, approle_name: "my-approle", token: '123456' }) ``` ## Resource Updates ### homebrew_tap Updated the `homebrew_tap` resource to remove the `full` property. Homebrew no longer supports the `--full` option, and attempting to use it causes Homebrew to fail. ### yum_package The `yum_package` resource has received extensive refactoring to align its functionality with the `dnf_package` resource and expand how package names and versions can be provided. The following ways of calling `yum_package` with a single name argument have been fixed and are now supported: ```ruby yum_package "ypbind-3:1.37.1" yum_package "ypbind-3:1.37.1-9.el7" ``` The following ways of calling `yum_package` with a single named argument are still supported: ```ruby yum_package "ypbind-1.37.1" yum_package "ypbind-1.37*" yum_package "ypbind-1.37.1-*" yum_package "ypbind-1.37*-*" yum_package "ypbind-*:1.37.1-*" yum_package "ypbind-*:1.37*-*" yum_package "ypbind-1.37.1-9.el7" yum_package "ypbind-1.37*-9.el7" yum_package "ypbind-1.37.1-9.*" ``` The following ways of calling `yum_package` with a single named argument do not properly match candidate versions (due to support in the underlying YUM libraries) and will fail: ```ruby yum_package "ypbind-3:1.37*-9.el7" yum_package "ypbind-3:1.37.*" yum_package "ypbind-3:1.37.1-9.*" ``` The following ways of calling `yum_package` with a version property have been fixed and are now supported: ```ruby yum_package "ypbind" do version "1.37*" end yum_package "ypbind" do version "1.37.1-*" end yum_package "ypbind" do version "1.37*-*" end yum_package "ypbind" do version "3:1.37.1-9.el7" end yum_package "ypbind" do version "*:1.37.1-*" end yum_package "ypbind" do version "*:1.37*-*" end yum_package "ypbind" do version "1.37.1-9.el7" end yum_package "ypbind" do version "1.37*-9.el7" end yum_package "ypbind" do version "1.37.1-9.*" end ``` The following ways of calling `yum_package` with a version property were not idempotent and that has been fixed (there was previously no way to correctly use the version property of the `yum_package` resource and have it behave idempotently): ```ruby yum_package "ypbind" do version "1.37.1" end yum_package "ypbind" do version "3:1.37.1" end ``` The following ways of calling `yum_package` with a version property do not properly match candidate versions (due to support in the underlying yum libraries) and will fail: ```ruby yum_package "ypbind" do version "3:1.37*-9.el7" end yum_package "ypbind" do version "3:1.37.*" end yum_package "ypbind" do version "3:1.37.1-9.*" end ``` We strongly encourage users to always provide the full epoch, version, and release (EVR) of an RPM since omitting the epoch is ambiguous and the RPM, YUM, and DNF libraries tend to assume zero when the epoch is omitted. Omitting the release is also not a best practice, but may be required due to the convention of embedding the distribution string in the release. The same fixes apply to the `:upgrade` action. The `:remove` action may have been similarly fixed, and we have added many additional tests to the test suite around idempotency and correctness. ## System Detection ### Improved VMware detection Ohai now collects hypervisor information on Windows guests and provides more information in the `node['vmware']` attribute. The properties `node['vmware']['host']` and `node['vmware']['guest']` provide more information about the hypervisor and the running version of the VMware Tools package. For example, you can use `node['vmware'] to get information about VM running on VMware vSphere: ```json { "host": { "type": "vmware_vsphere", "version": "VMware ESX 7.0.0 build-15843807" }, "guest": { "vmware_tools_version": "11.0.5.17716" }, "hosttime": "09 Dec 2021 12:16:55", "speed": "1992 MHz", "sessionid": "0x5ff24c6ec541d5ac", "balloon": "0 MB", "swap": "0 MB", "memlimit": "4294967295 MB", "memres": "0 MB", "cpures": "0 MHz", "cpulimit": "4294967295 MHz", "upgrade": "", "timesync": "Disabled" } ``` The Chef Infra language also has two new helpers for detecting the guest VMware hypervisor: * `vmware_desktop?`: Determines if the current node is virtualized on VMware Desktop (Fusion/Player/Workstation). * `vmware_vsphere?`: Determines if the current node is virtualized on VMware vSphere (ESX). Thanks for this new functionality [@tecracer-theinen](https://github.com/tecracer-theinen)! ## Packaging ### RHEL 8 Build ID Chef Infra Client packages no longer install a build ID file that prevents installing other Chef packages such as Infra Server or Workstation.