Bump version to 18.0 and fix master references18.0

Fix more URLs to point to main.

Signed-off-by: Tim Smith <tsmith@chef.io>

19 files changed, 64 insertions, 62 deletions

diff --git a/.github/workflows/unit_specs.yml b/.github/workflows/unit_specs.yml
index fd0be0991f..38b884b5df 100644
--- a/.github/workflows/unit_specs.yml
+++ b/.github/workflows/unit_specs.yml
@@ -5,7 +5,7 @@ name: unit_specs
   pull_request:
   push:
     branches:
-      - master
+      - main
 
 jobs:
   unit:
diff --git a/CLA_ARCHIVE.md b/CLA_ARCHIVE.md
index 640277d354..1bfa1a0b31 100644
--- a/CLA_ARCHIVE.md
+++ b/CLA_ARCHIVE.md
@@ -657,7 +657,7 @@ Many organizations signed the CCLA again in Supermarket.
 The list of allowed contributors from 2009 through 3 October, 2016 prior to Chef
 projects [moving to a Developer Certificate of Origin
 process](https://blog.chef.io/2016/09/19/introducing-developer-certificate-of-origin/).
-See [CONTRIBUTING](https://github.com/chef/chef/blob/master/CONTRIBUTING.md) for
+See [CONTRIBUTING](https://github.com/chef/chef/blob/main/CONTRIBUTING.md) for
 how to contribute to Chef today.
 
 Persons listed as associated with a company may also be individual contributors
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 2ccfb550ba..16e675929e 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -33,8 +33,8 @@ Code review takes place in GitHub pull requests. See [this article](https://help
 
 Once you open a pull request, project maintainers will review your code and respond to your pull request with any feedback they might have. The process at this point is as follows:
 
-1. Two or more members of the owners, approvers, or reviewers groups must approve your PR. See the [Chef Infra OSS Project](https://github.com/chef/chef-oss-practices/blob/master/projects/chef-infra.md) for a list of all members.
-2. Your change will be merged into the project's `master` branch
+1. Two or more members of the owners, approvers, or reviewers groups must approve your PR. See the [Chef Infra OSS Project](https://github.com/chef/chef-oss-practices/blob/main/projects/chef-infra.md) for a list of all members.
+2. Your change will be merged into the project's `main` branch
 3. Our Expeditor bot will automatically increment the version and update the project's changelog with your contribution. For projects that ship as a package, Expeditor will kick off a build which will publish the package to the project's `current` channel.
 
 If you would like to learn about when your code will be available in a release of Chef, read more about [Chef Release Cycles](#release-cycles).
@@ -43,7 +43,7 @@ If you would like to learn about when your code will be available in a release o
 
 Licensing is very important to open source projects. It helps ensure the software continues to be available under the terms that the author desired.
 
-Chef uses [the Apache 2.0 license](https://github.com/chef/chef/blob/master/LICENSE) to strike a balance between open contribution and allowing you to use the software however you would like to.
+Chef uses [the Apache 2.0 license](https://github.com/chef/chef/blob/main/LICENSE) to strike a balance between open contribution and allowing you to use the software however you would like to.
 
 The license tells you what rights you have that are provided by the copyright holder. It is important that the contributor fully understands what rights they are licensing and agrees to them. Sometimes the copyright holder isn't the contributor, such as when the contributor is doing work on behalf of a company.
 
@@ -133,7 +133,7 @@ Our version numbering roughly follows [Semantic Versioning](http://semver.org/)
 - Y is a minor release, which adds both new features and bug fixes
 - Z is a patch release, which adds just bug fixes
 
-After shipping a release of Chef we bump the `Minor` version by one to start development of the next minor release. All merges to master trigger an increment of the `Patch` version, and a build through our internal testing pipeline. We do a `Minor` release approximately every month, which consist of shipping one of the already auto-incremented and tested `Patch` versions. For example after shipping 12.10.24, we incremented Chef to 12.11.0\. From there 18 commits where merged bringing the version to 12.11.18, which we shipped as an omnibus package.
+After shipping a release of Chef we bump the `Minor` version by one to start development of the next minor release. All merges to `main` trigger an increment of the `Patch` version, and a build through our internal testing pipeline. We do a `Minor` release approximately every month, which consist of shipping one of the already auto-incremented and tested `Patch` versions. For example after shipping 12.10.24, we incremented Chef to 12.11.0\. From there 18 commits where merged bringing the version to 12.11.18, which we shipped as an omnibus package.
 
 Announcements of releases are made to the [chef mailing list](https://discourse.chef.io/c/chef-release) when they are available and are mirrored to the #announcements channel on the [Chef Community Slack](https://community-slack.chef.io/).
 
diff --git a/Gemfile.lock b/Gemfile.lock
index aaeac240a0..3a2ad1c464 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -8,12 +8,12 @@ GIT
 
 GIT
   remote: https://github.com/chef/ohai.git
-  revision: bddccd3bb3b3ce79c48ee9a05d1bb4488938bfc5
+  revision: d3767223cc4c236967550c16d3e519bbfcb8ea4c
   branch: main
   specs:
-    ohai (17.9.2)
-      chef-config (>= 14.12, < 18)
-      chef-utils (>= 16.0, < 18)
+    ohai (18.0.1)
+      chef-config (>= 14.12, < 19)
+      chef-utils (>= 16.0, < 19)
       ffi (~> 1.9)
       ffi-yajl (~> 2.2)
       ipaddress
@@ -58,7 +58,7 @@ PATH
       mixlib-log (>= 2.0.3, < 4.0)
       mixlib-shellout (>= 3.1.1, < 4.0)
       net-sftp (>= 2.1.2, < 4.0)
-      ohai (~> 17.0)
+      ohai (~> 18.0)
       plist (~> 3.2)
       proxifier (~> 1.0)
       syslog-logger (~> 1.6)
@@ -90,7 +90,7 @@ PATH
       mixlib-log (>= 2.0.3, < 4.0)
       mixlib-shellout (>= 3.1.1, < 4.0)
       net-sftp (>= 2.1.2, < 4.0)
-      ohai (~> 17.0)
+      ohai (~> 18.0)
       plist (~> 3.2)
       proxifier (~> 1.0)
       syslog-logger (~> 1.6)
diff --git a/README.md b/README.md
index 6c3373a2af..1c7361c2b6 100644
--- a/README.md
+++ b/README.md
@@ -1,16 +1,16 @@
 # Chef Infra
 [![Code Climate](https://codeclimate.com/github/chef/chef.svg)](https://codeclimate.com/github/chef/chef)
-[![Build Status](https://badge.buildkite.com/c82093430ceec7d27af05febb9dcafe3aa331fff9d74c0ab9d.svg?branch=master)](https://buildkite.com/chef-oss/chef-chef-master-verify)
+[![Build Status](https://badge.buildkite.com/c82093430ceec7d27af05febb9dcafe3aa331fff9d74c0ab9d.svg?branch=main)](https://buildkite.com/chef-oss/chef-chef-main-verify)
 [![Gem Version](https://badge.fury.io/rb/chef.svg)](https://badge.fury.io/rb/chef)
-[![](https://img.shields.io/badge/Release%20Policy-Cadence%20Release-brightgreen.svg)](https://github.com/chef/chef/blob/master/docs/dev/design_documents/client_release_cadence.md)
+[![](https://img.shields.io/badge/Release%20Policy-Cadence%20Release-brightgreen.svg)](https://github.com/chef/chef/blob/main/docs/dev/design_documents/client_release_cadence.md)
 
-**Umbrella Project**: [Chef Infra](https://github.com/chef/chef-oss-practices/blob/master/projects/chef-infra.md)
+**Umbrella Project**: [Chef Infra](https://github.com/chef/chef-oss-practices/blob/main/projects/chef-infra.md)
 
-**Project State**: [Active](https://github.com/chef/chef-oss-practices/blob/master/repo-management/repo-states.md#active)
+**Project State**: [Active](https://github.com/chef/chef-oss-practices/blob/main/repo-management/repo-states.md#active)
 
-**Issues [Response Time Maximum](https://github.com/chef/chef-oss-practices/blob/master/repo-management/repo-states.md)**: 14 days
+**Issues [Response Time Maximum](https://github.com/chef/chef-oss-practices/blob/main/repo-management/repo-states.md)**: 14 days
 
-**Pull Request [Response Time Maximum](https://github.com/chef/chef-oss-practices/blob/master/repo-management/repo-states.md)**: 14 days
+**Pull Request [Response Time Maximum](https://github.com/chef/chef-oss-practices/blob/main/repo-management/repo-states.md)**: 14 days
 
 ## Getting Started
 
@@ -23,7 +23,7 @@ For Chef Infra usage, please refer to [Learn Chef](https://learn.chef.io/), our
 Other useful resources for Chef Infra users:
 
 - Documentation: <https://docs.chef.io/>
-- Source: <https://github.com/chef/chef/tree/master>
+- Source: <https://github.com/chef/chef/tree/main>
 - Tickets/Issues: <https://github.com/chef/chef/issues>
 - Slack: [Chef Community Slack](https://community-slack.chef.io/)
 - Mailing list/Forum: <https://discourse.chef.io>
diff --git a/VERSION b/VERSION
index c23ae96e58..03191c968c 100644
--- a/VERSION
+++ b/VERSION
@@ -1 +1 @@
-17.9.32
\ No newline at end of file
+18.0.0
\ No newline at end of file
diff --git a/chef.gemspec b/chef.gemspec
index cd815b2535..8b36cef57a 100644
--- a/chef.gemspec
+++ b/chef.gemspec
@@ -35,7 +35,7 @@ Gem::Specification.new do |s|
   s.add_dependency "mixlib-authentication", ">= 2.1", "< 4"
   s.add_dependency "mixlib-shellout", ">= 3.1.1", "< 4.0"
   s.add_dependency "mixlib-archive", ">= 0.4", "< 2.0"
-  s.add_dependency "ohai", "~> 17.0"
+  s.add_dependency "ohai", "~> 18.0"
   s.add_dependency "inspec-core", "~> 4.23"
 
   s.add_dependency "ffi", ">= 1.5.0"
@@ -70,7 +70,7 @@ Gem::Specification.new do |s|
 
   s.metadata = {
     "bug_tracker_uri"   => "https://github.com/chef/chef/issues",
-    "changelog_uri"     => "https://github.com/chef/chef/blob/master/CHANGELOG.md",
+    "changelog_uri"     => "https://github.com/chef/chef/blob/main/CHANGELOG.md",
     "documentation_uri" => "https://docs.chef.io/",
     "homepage_uri"      => "https://www.chef.io",
     "mailing_list_uri"  => "https://discourse.chef.io/",
diff --git a/docs/dev/design_documents/event_handler_recipe_dsl.md b/docs/dev/design_documents/event_handler_recipe_dsl.md
index ec6adbc165..da9d2b09d6 100644
--- a/docs/dev/design_documents/event_handler_recipe_dsl.md
+++ b/docs/dev/design_documents/event_handler_recipe_dsl.md
@@ -4,7 +4,7 @@ Allow cookbook authors to easily add custom logic on Chef events.
 
 ## Motivation
 
-Chef has an extensive [event dispatch mechanism](https://github.com/chef/chef/blob/master/lib/chef/event_dispatch/base.rb).
+Chef has an extensive [event dispatch mechanism](https://github.com/chef/chef/blob/main/lib/chef/event_dispatch/base.rb).
 But incorporating some custom logic against any of the events is an onerous process, which involves
 subclassing the based event handler and adding it via the config. This RFC
 proposes a recipe DSL method to ease this. For new Chef users, this will reduce
diff --git a/docs/dev/design_documents/how_chef_is_tested_and_built.md b/docs/dev/design_documents/how_chef_is_tested_and_built.md
index fda2ac6156..edd0aefbad 100644
--- a/docs/dev/design_documents/how_chef_is_tested_and_built.md
+++ b/docs/dev/design_documents/how_chef_is_tested_and_built.md
@@ -15,14 +15,14 @@ We can't just merge any old change, so we run various checks against your submit
     - Unit, functional, and integration tests on all supported Ruby releases. These run on Ubuntu, CentOS and openSUSE so we can make sure our functional / integration tests run on the platforms where users consume Chef Infra.
     - Chefstyle Ruby linting
     - Unit tests from chef-sugar, chef-zero, cheffish, chefspec, and knife-windows against the chef code in your PR
-    - Full Test Kitchen integration tests that covers common Chef usage on various different Linux Distros. Those integration tests run using the kitchen-dokken plugin and the dokken-images Docker containers, which do their best to replicate a real Linux system. You can see exactly what we test here: https://github.com/chef/chef/blob/master/kitchen-tests/cookbooks/end_to_end/recipes/default.rb
+    - Full Test Kitchen integration tests that covers common Chef usage on various different Linux Distros. Those integration tests run using the kitchen-dokken plugin and the dokken-images Docker containers, which do their best to replicate a real Linux system. You can see exactly what we test here: https://github.com/chef/chef/blob/main/kitchen-tests/cookbooks/end_to_end/recipes/default.rb
   - **Appveyor**: Buildkite does a great job of testing PRs against Linux hosts, but many rspec tests require a Windows system to run, and for this, we test in Appveyor. In Appveyor, we run our unit, integration, and functional specs against our supported Ruby releases, but this time, we do it on Windows.
 
 ## PR is Reviewed and Merged
 
-Once your pull request passes the above tests, it will need to be reviewed by at least two members of the Chef Infra project owners, approvers, or reviewers groups. For a list of owners, approvers, and reviewers, see https://github.com/chef/chef-oss-practices/blob/master/projects/chef-infra.md. GitHub will automatically assign these groups as reviewers. Reviews will happen ad hoc as members in those groups have time, or during our weekly issue triage. Check the above team doc link for information on when that review takes place.
+Once your pull request passes the above tests, it will need to be reviewed by at least two members of the Chef Infra project owners, approvers, or reviewers groups. For a list of owners, approvers, and reviewers, see https://github.com/chef/chef-oss-practices/blob/main/projects/chef-infra.md. GitHub will automatically assign these groups as reviewers. Reviews will happen ad hoc as members in those groups have time, or during our weekly issue triage. Check the above team doc link for information on when that review takes place.
 
-Your PR will be reviewed for Chef and Ruby correctness, overall design, and likelihood of impact on the community. We do our best to make sure all the changes made to Chef are high quality and easy to maintain going forward, while also having the lowest chance of negatively impacting our end users. If your PR meets that criteria, we'll merge the change into our master branch.
+Your PR will be reviewed for Chef and Ruby correctness, overall design, and likelihood of impact on the community. We do our best to make sure all the changes made to Chef are high quality and easy to maintain going forward, while also having the lowest chance of negatively impacting our end users. If your PR meets that criteria, we'll merge the change into our main branch.
 
 ## Version Bump and Changelog Update
 
diff --git a/docs/dev/how_to/adding_new_platforms_to_infra.md b/docs/dev/how_to/adding_new_platforms_to_infra.md
index 99a2544710..a2a8e4a01b 100644
--- a/docs/dev/how_to/adding_new_platforms_to_infra.md
+++ b/docs/dev/how_to/adding_new_platforms_to_infra.md
@@ -16,13 +16,13 @@ For major new Linux or Windows distribution releases, you'll want to add these t
 
 Note: Windows builds can't be built on DockerHub and have to be pushed manually from your workstation instead.
 
-Once you've added the distro to RubyDistros and the image is pushed to DockerHub, you can add that new distro to the `chef/chef` [verify.pipeline.yml](https://github.com/chef/chef/blob/master/.expeditor/verify.pipeline.yml).
+Once you've added the distro to RubyDistros and the image is pushed to DockerHub, you can add that new distro to the `chef/chef` [verify.pipeline.yml](https://github.com/chef/chef/blob/main/.expeditor/verify.pipeline.yml).
 
 #### Kitchen Dokken Images
 
 We utilize the kitchen-dokken Test Kitchen plugin to test the contents of `chef/chef` against various Linux distributions. This works best when run against containers that look more like VMs and less like slim containers. The [dokken-images](https://github.com/test-kitchen/dokken-images) repository defines many Docker images for common Linux distributions. These are all based on the official distro Docker images but contain additional packages to make them behave more like full systems.
 
-Similar to the RubyDistros setup, these are defined in GitHub and built-in DockerHub. You'll need to be a member of the [dokken DockerHub organization](https://hub.docker.com/orgs/dokken). If you don't have access to that please ask #releng-support to add you. Once you've added a distro to the GitHub repo you can add a new repository to that DockerHub Organization. Make sure to copy the automated builds settings and specify the correct path to the Dockerfile. Once that is complete and the image is pushed to DockerHub you can add the new test to `chef/chef`. You'll need to edit the [kitchen-test/kitchen.yml](https://github.com/chef/chef/blob/master/kitchen-tests/kitchen.yml) file and then add that new platform to the [verify.pipeline.yml](https://github.com/chef/chef/blob/master/.expeditor/verify.pipeline.yml) config.
+Similar to the RubyDistros setup, these are defined in GitHub and built-in DockerHub. You'll need to be a member of the [dokken DockerHub organization](https://hub.docker.com/orgs/dokken). If you don't have access to that please ask #releng-support to add you. Once you've added a distro to the GitHub repo you can add a new repository to that DockerHub Organization. Make sure to copy the automated builds settings and specify the correct path to the Dockerfile. Once that is complete and the image is pushed to DockerHub you can add the new test to `chef/chef`. You'll need to edit the [kitchen-test/kitchen.yml](https://github.com/chef/chef/blob/main/kitchen-tests/kitchen.yml) file and then add that new platform to the [verify.pipeline.yml](https://github.com/chef/chef/blob/main/.expeditor/verify.pipeline.yml) config.
 
 #### Azure Pipelines tests
 
@@ -40,17 +40,17 @@ With builds in place, we also want to make sure we support this new platform wit
 
 #### chef-utils
 
-chef-utils provides a large number of helpers for making cookbook authoring simpler. One of the most useful sets of helpers is helpers for platforms and platform families, which will need to be updated if we added new distros. Make sure new platform are supported in `platform.rb` / `platform_family.rb` files in [chef-utils/lib/chef-utils/dsl](https://github.com/chef/chef/tree/master/chef-utils/lib/chef-utils/dsl). In order to test these changes you'll most likely need to update the Fauxhai data. See the section below for instructions on updating that data.
+chef-utils provides a large number of helpers for making cookbook authoring simpler. One of the most useful sets of helpers is helpers for platforms and platform families, which will need to be updated if we added new distros. Make sure new platform are supported in `platform.rb` / `platform_family.rb` files in [chef-utils/lib/chef-utils/dsl](https://github.com/chef/chef/tree/main/chef-utils/lib/chef-utils/dsl). In order to test these changes you'll most likely need to update the Fauxhai data. See the section below for instructions on updating that data.
 
 #### Ohai
 
-Ohai powers all system configuration detection for Chef Infra Client. New distributions have pretty far-reaching impacts on Ohai and should be evaluated carefully. The most basic task when adding a new distro is to make sure that the platform is properly mapped to the appropriate platform_family value. On Linux systems this is performed in the [Linux Platform Plugin](https://github.com/chef/ohai/blob/master/lib/ohai/plugins/linux/platform.rb).
+Ohai powers all system configuration detection for Chef Infra Client. New distributions have pretty far-reaching impacts on Ohai and should be evaluated carefully. The most basic task when adding a new distro is to make sure that the platform is properly mapped to the appropriate platform_family value. On Linux systems this is performed in the [Linux Platform Plugin](https://github.com/chef/ohai/blob/main/lib/ohai/plugins/linux/platform.rb).
 
 ## Additional Ecosystem Updates
 
 ### Bento Boxes
 
-Bento boxes are used by the kitchen-vagrant driver by customers for cookbook testing. When we add a new platform we need to make sure that customers can use it in their testing processes. The [bento repository](https://github.com/chef/bento/) contains packer templates for each platform / platform version, a [builds.yml](https://github.com/chef/bento/blob/master/builds.yml) file which defines the systems to build, and a ruby application which helps with building systems. Bento boxes are generally build for VirtualBox, VMware Fusion, Parallels Desktop, and Hyper-V so you will need both a macOS and Windows system to build all the systems. Once this is complete you can use the `bento upload` command to push these to Vagrant Cloud. You'll need to be added to the Bento Vagrant Cloud org, which #releng-support can assist you with.
+Bento boxes are used by the kitchen-vagrant driver by customers for cookbook testing. When we add a new platform we need to make sure that customers can use it in their testing processes. The [bento repository](https://github.com/chef/bento/) contains packer templates for each platform / platform version, a [builds.yml](https://github.com/chef/bento/blob/main/builds.yml) file which defines the systems to build, and a ruby application which helps with building systems. Bento boxes are generally build for VirtualBox, VMware Fusion, Parallels Desktop, and Hyper-V so you will need both a macOS and Windows system to build all the systems. Once this is complete you can use the `bento upload` command to push these to Vagrant Cloud. You'll need to be added to the Bento Vagrant Cloud org, which #releng-support can assist you with.
 
 ### Fauxhai Dumps
 
diff --git a/docs/dev/how_to/branching_and_backporting.md b/docs/dev/how_to/branching_and_backporting.md
index 8929c926e9..ab601cadba 100644
--- a/docs/dev/how_to/branching_and_backporting.md
+++ b/docs/dev/how_to/branching_and_backporting.md
@@ -2,16 +2,16 @@
 
 ## Branch Structure
 
-We develop and ship the current release of Chef off the master branch of this repository. Our goal is that `master` should always be in a shippable state. Previous stable releases of Chef are developed on their own branches named by the major version (ex: chef-14 or chef-13). We do not perform direct development on these stable branches, except to resolve build failures. Instead, we backport fixes from our master branch to these stable branches. Stable branches receive critical bugfixes and security releases, and stable Chef releases are made as necessary for security purposes.
+We develop and ship the current release of Chef off the `main` branch of this repository. Our goal is that `main` should always be in a shippable state. Previous stable releases of Chef are developed on their own branches named by the major version (ex: chef-16 or chef-15). We do not perform direct development on these stable branches, except to resolve build failures. Instead, we backport fixes from our main branch to these stable branches. Stable branches receive critical bugfixes and security releases, and stable Chef releases are made as necessary for security purposes.
 
 ## Backporting Fixes to Stable Releases
 
-If there is a critical fix that you believe should be backported from master to a stable branch, please follow these steps to backport your change:
+If there is a critical fix that you believe should be backported from main to a stable branch, please follow these steps to backport your change:
 
 1. Ask in the #chef-dev channel on [Chef Community Slack](https://community-slack.chef.io/) if this is an appropriate change to backport.
 3. Inspect the Git history and find the `SHA`(s) associated with the fix.
 4. Backport the fix to a branch via cherry-pick:
-    1. Check out the stable release branch: `git checkout chef-14`
+    1. Check out the stable release branch: `git checkout chef-16`
     2. Create a branch for your backport: `git checkout -b my_great_bug_backport`
     3. Cherry Pick the SHA with the fix: `git cherry-pick SHA`
     4. Address any conflicts (if necessary)
diff --git a/docs/dev/how_to/bumping_minor_or_major_versions.md b/docs/dev/how_to/bumping_minor_or_major_versions.md
index 79cfa9075e..b8164ea1bf 100644
--- a/docs/dev/how_to/bumping_minor_or_major_versions.md
+++ b/docs/dev/how_to/bumping_minor_or_major_versions.md
@@ -4,7 +4,7 @@
 
 After performing the monthly minor release of Chef, we should wait several days, and then bump the version for the next month's release. Why wait? We don't want to bump the version until we are sure we do not need to perform an emergency release for a regression. Once we're fairly confident we won't be performing a regression release, we want all new builds for the current channel to have the next month's version. This makes it very clear what version of Chef users are testing within the current channel.
 
-Bumping for the yearly major release is a bit different. We can bump for the new major release once we create a stable branch for the current major version number. Once this branch and version bump occurs, all development on master will be for the upcoming major release, and anything going into the stable release will need to be backported. See [Branching and Backporting](branching_and_backporting.md) for more information on how we branch and backport to stable.
+Bumping for the yearly major release is a bit different. We can bump for the new major release once we create a stable branch for the current major version number. Once this branch and version bump occurs, all development on main will be for the upcoming major release, and anything going into the stable release will need to be backported. See [Branching and Backporting](branching_and_backporting.md) for more information on how we branch and backport to stable.
 
 See [Bumping The Major Version](bumping_the_major_version.md) for the major version bump process.
 
diff --git a/docs/dev/how_to/bumping_the_major_version.md b/docs/dev/how_to/bumping_the_major_version.md
index 32d0498153..12d7435dbb 100644
--- a/docs/dev/how_to/bumping_the_major_version.md
+++ b/docs/dev/how_to/bumping_the_major_version.md
@@ -29,25 +29,27 @@ Starting from the main branch create a PR which:
 
 ### Prep main branch for forking
 
-- In ./expeditor/config.yml add the version_constraint for the new branch, update the version_constraint for main to match the new planned major version and add a constraint for the new stable version / branch. Make sure to commit this before moving on.
+- In ./expeditor/config.yml add the version_constraint for the new branch, update the version_constraint for main to match the new planned major version and add a constraint for the new stable version / branch.
 
 ### Fork Chef main to a stable branch
 
 Before bumping the major version of Chef Infra we want to fork off the current main to a new stable branch, which will be used to build hotfix releases. We support the N-1 version of Chef Infra Client for a year after the release of a new major version. For example Chef Infra Client 17 was released in April 2021, at which point Chef Infra Client 16 became the N-1 release. Chef Infra Client 16 will then be maintained with critical bug and security fixes until April 2022.
 
-On your local machine fork the current main branch to a new stable branch. For example: `git checkout -b chef-16` and `git push --set-upstream origin chef-16`, which can then be pushed up to GitHub.
+On your local machine fork the current main branch to a new stable branch. For example: `git checkout -b chef-17` and `git push --set-upstream origin chef-17`, which can then be pushed up to GitHub.
 
 ### Create a branch to fixup your new stable branch for release
 
-Once you've forked to a new stable branch such as `chef-15` you'll want to create a new branch so you can build a PR, which will get this branch ready for release:
+Once you've forked to a new stable branch such as `chef-17` you'll want to create a new branch so you can build a PR, which will get this branch ready for release:
 
-- In ./expeditor/config.yml remove all the update_dep.sh subscriptions which don't work against stable branches.
+- In ./expeditor/config.yml remove the update_dep.sh subscriptions which don't work against stable branches such as chefstyle and ohai.
 - In readme.md update the buildkite badge to point to the new stable branch image and link instead of pointing to main.
 - In kitchen-tests/Gemfile update the Ohai branch to point to the new Ohai stable
 - In kitchen-tests/kitchen.yml update chef_version to be your new stable version and not current. Ex: 15
 - In tasks/bin/run_external_test update the ohai branch to point to your new stable ohai branch
 - In Gemfile set ohai to pull from the ohai stable branch
-- Run `rake dependencies:update`
+- In Gemfile set cheffish to match the stable release of chef
+- Update .github/dependabot.yml with the new branch
+- Run `rake dependencies:update` to generate a new gemfile.lock
 
 Example PR for Chef 15: https://github.com/chef/chef/pull/9236
 
@@ -58,7 +60,7 @@ Note: Make sure you're making this PR against the new stable branch and not main
 Create a PR that performs the following:
 
 - Update the version in the VERSION file
-- Update chef.gemspec to point to the new ohai major release
+- Update `chef.gemspec` and `knife.gemspec` to point to the new ohai major release
 - run `rake dependencies:update`
 
 ## Update Ohai stable for the Chef stable branch
diff --git a/docs/dev/how_to/releasing_chef_infra.md b/docs/dev/how_to/releasing_chef_infra.md
index b0db85432e..6e6f926395 100644
--- a/docs/dev/how_to/releasing_chef_infra.md
+++ b/docs/dev/how_to/releasing_chef_infra.md
@@ -37,7 +37,7 @@ If there are any new or updated resources, the docs site will need to be updated
 
 Chef employees can promote a build to stable from Slack. This is done with expeditor using a chatops command in the following format:
 
-`/expeditor promote chef/chef:master 17.1.9`
+`/expeditor promote chef/chef:main 17.1.9`
 
 or for a previous release branch:
 
diff --git a/docs/dev/license_acceptance.md b/docs/dev/license_acceptance.md
index bb6e8a4e07..6e295c090b 100644
--- a/docs/dev/license_acceptance.md
+++ b/docs/dev/license_acceptance.md
@@ -8,6 +8,6 @@ The overall goal is that the license acceptance flow is invoked as early as poss
 execution. Failure to accept the license causes the binary to immediately exit with code `172`.
 
 For an explanation of how this is achieved please see the [Ruby
-README](https://github.com/chef/license-acceptance/tree/master/components/ruby) in the license-acceptance repo. For an
+README](https://github.com/chef/license-acceptance/tree/main/components/ruby) in the license-acceptance repo. For an
 overall view of how the license-acceptance gem works, its specification, how marker files are stored, etc. please see
 the [repo README](https://github.com/chef/license-acceptance).
diff --git a/knife/knife.gemspec b/knife/knife.gemspec
index d121343211..445ab92b44 100644
--- a/knife/knife.gemspec
+++ b/knife/knife.gemspec
@@ -23,7 +23,7 @@ Gem::Specification.new do |s|
   s.add_dependency "license-acceptance", ">= 1.0.5", "< 3"
   s.add_dependency "mixlib-cli", ">= 2.1.1", "< 3.0"
   s.add_dependency "mixlib-archive", ">= 0.4", "< 2.0"
-  s.add_dependency "ohai", "~> 17.0"
+  s.add_dependency "ohai", ">= 17.0", "< 19"
   s.add_dependency "ffi", ">= 1.15" # 1.14 versions are broken on i386 windows
   s.add_dependency "ffi-yajl", "~> 2.2"
   s.add_dependency "net-ssh", ">= 5.1", "< 7"
diff --git a/knife/lib/chef/knife/bootstrap.rb b/knife/lib/chef/knife/bootstrap.rb
index e2b9993e60..01825132b1 100644
--- a/knife/lib/chef/knife/bootstrap.rb
+++ b/knife/lib/chef/knife/bootstrap.rb
@@ -973,7 +973,7 @@ class Chef
           # for this. We will also set keys_only to false only if there are keys
           # and no password.
           # If both are present, train(via net/ssh)  will prefer keys, falling back to password.
-          # Reference: https://github.com/chef/chef/blob/master/lib/chef/knife/ssh.rb#L272
+          # Reference: https://github.com/chef/chef/blob/main/lib/chef/knife/ssh.rb#L272
           opts[:keys_only] = config.key?(:connection_password) == false
         else
           opts[:key_files] = []
diff --git a/lib/chef/application/exit_code.rb b/lib/chef/application/exit_code.rb
index 4cc579e83a..b912c1d8f6 100644
--- a/lib/chef/application/exit_code.rb
+++ b/lib/chef/application/exit_code.rb
@@ -19,8 +19,8 @@
 class Chef
   class Application
 
-    # These are the exit codes defined in Chef RFC 062
-    # https://github.com/chef/chef-rfc/blob/master/rfc062-exit-status.md
+    # These are the exit codes defined in the exit codes design document
+    # https://github.com/chef/chef/blob/main/docs/dev/design_documents/client_exit_codes.md
     class ExitCode
       require "chef-utils/dist" unless defined?(ChefUtils::Dist)
 
@@ -140,7 +140,7 @@ class Chef
 
         def non_standard_exit_code_warning(exit_code)
           "#{ChefUtils::Dist::Infra::CLIENT} attempted to exit with a non-standard exit code of #{exit_code}." \
-          " The #{ChefUtils::Dist::Infra::PRODUCT} Exit Codes design document (https://github.com/chef/chef-rfc/blob/master/rfc062-exit-status.md)" \
+          " The #{ChefUtils::Dist::Infra::PRODUCT} Exit Codes design document (https://github.com/chef/chef/blob/main/docs/dev/design_documents/client_exit_codes.md)" \
           " defines the exit codes that should be used with #{ChefUtils::Dist::Infra::CLIENT}. Chef::Application::ExitCode defines"  \
           " valid exit codes Non-standard exit codes are redefined as GENERIC_FAILURE."
         end
diff --git a/omnibus/Gemfile.lock b/omnibus/Gemfile.lock
index 6c0bf01ad5..52f4f9dbfb 100644
--- a/omnibus/Gemfile.lock
+++ b/omnibus/Gemfile.lock
@@ -33,7 +33,7 @@ GEM
     artifactory (3.0.15)
     awesome_print (1.9.2)
     aws-eventstream (1.2.0)
-    aws-partitions (1.545.0)
+    aws-partitions (1.546.0)
     aws-sdk-core (3.125.1)
       aws-eventstream (~> 1, >= 1.0.2)
       aws-partitions (~> 1, >= 1.525.0)
@@ -42,12 +42,12 @@ GEM
     aws-sdk-kms (1.53.0)
       aws-sdk-core (~> 3, >= 3.125.0)
       aws-sigv4 (~> 1.1)
-    aws-sdk-s3 (1.111.0)
+    aws-sdk-s3 (1.111.1)
       aws-sdk-core (~> 3, >= 3.125.0)
       aws-sdk-kms (~> 1)
       aws-sigv4 (~> 1.4)
-    aws-sdk-secretsmanager (1.54.0)
-      aws-sdk-core (~> 3, >= 3.122.0)
+    aws-sdk-secretsmanager (1.55.0)
+      aws-sdk-core (~> 3, >= 3.125.0)
       aws-sigv4 (~> 1.1)
     aws-sigv4 (1.4.0)
       aws-eventstream (~> 1, >= 1.0.2)
@@ -68,12 +68,12 @@ GEM
       solve (~> 4.0)
       thor (>= 0.20)
     builder (3.2.4)
-    chef (17.8.25)
+    chef (17.9.26)
       addressable
       aws-sdk-s3 (~> 1.91)
       aws-sdk-secretsmanager (~> 1.46)
-      chef-config (= 17.8.25)
-      chef-utils (= 17.8.25)
+      chef-config (= 17.9.26)
+      chef-utils (= 17.9.26)
       chef-vault
       chef-zero (>= 14.0.11)
       corefoundation (~> 0.3.4)
@@ -99,12 +99,12 @@ GEM
       train-winrm (>= 0.2.5)
       uuidtools (>= 2.1.5, < 3.0)
       vault (~> 0.16)
-    chef (17.8.25-universal-mingw32)
+    chef (17.9.26-universal-mingw32)
       addressable
       aws-sdk-s3 (~> 1.91)
       aws-sdk-secretsmanager (~> 1.46)
-      chef-config (= 17.8.25)
-      chef-utils (= 17.8.25)
+      chef-config (= 17.9.26)
+      chef-utils (= 17.9.26)
       chef-vault
       chef-zero (>= 14.0.11)
       corefoundation (~> 0.3.4)
@@ -142,9 +142,9 @@ GEM
       win32-taskscheduler (~> 2.0)
       wmi-lite (~> 1.0)
     chef-cleanroom (1.0.4)
-    chef-config (17.8.25)
+    chef-config (17.9.26)
       addressable
-      chef-utils (= 17.8.25)
+      chef-utils (= 17.9.26)
       fuzzyurl
       mixlib-config (>= 2.2.12, < 4.0)
       mixlib-shellout (>= 2.0, < 4.0)
@@ -152,7 +152,7 @@ GEM
     chef-telemetry (1.1.1)
       chef-config
       concurrent-ruby (~> 1.0)
-    chef-utils (17.8.25)
+    chef-utils (17.9.26)
       concurrent-ruby
     chef-vault (4.1.5)
     chef-zero (15.0.11)
@@ -205,7 +205,7 @@ GEM
     hashie (4.1.0)
     httpclient (2.8.3)
     iniparse (1.5.0)
-    inspec-core (4.50.3)
+    inspec-core (4.52.9)
       addressable (~> 2.4)
       chef-telemetry (~> 1.0, >= 1.0.8)
       faraday (>= 0.9.0, < 1.5)