+
+## Chef Product Names for Omnibus
+
+See the [Supported Versions]({{< relref "versions" >}}) documentation for information about the support status of individual products.
+
+This is a list of currently supported products that you can install with the Omnibus API.
+
+| Product | Product Key |
+| ------- | ------------ |
+| Chef Infra Client | chef |
+| Chef Backend | chef-backend |
+| Chef Infra Server | chef-server |
+| Chef Workstation | chef-workstation |
+| Chef InSpec | inspec |
+| Management Console | manage |
+| Supermarket | supermarket |
+
+### Examples
+
+#### Get the Latest Build
+
+To get the latest supported build for Ubuntu 20.04, enter the following:
+
+```plain
+https://omnitruck.chef.io/stable/chef/metadata?p=ubuntu&pv=20.04&m=x86_64
+```
+
+to return something like:
+
+```plain
+sha1 3fe8e8a2f443675f9b82e876cdac8200104451f2
+sha256 9f1c1a2c0b1f4e8494664386437bf32f0cb5cbfbd4cb9d23e327767fc65581dc
+url https://packages.chef.io/files/stable/chef/17.7.29/ubuntu/20.04/chef_17.7.29-1_amd64.deb
+version 17.7.29
+```
+
+#### Download Directly
+
+To use cURL to download a package directly, enter the following:
+
+```bash
+curl -LOJ 'https://omnitruck.chef.io///download?p=debian&pv=10&m=x86_64'
+```
+
+To use GNU Wget to download a package directly, enter the following:
+
+```bash
+wget --content-disposition https://omnitruck.chef.io///download?p=debian&pv=10&m=x86_64
+```
diff --git a/content/attribute_arrays.md b/content/attribute_arrays.md
new file mode 100644
index 0000000..557fed4
--- /dev/null
+++ b/content/attribute_arrays.md
@@ -0,0 +1,199 @@
++++
+title = "Attribute Arrays"
+description = "Define multiple attributes in an array or hash and deep merge"
+draft = false
+aliases = ["/essentials_node_object_deep_merge"]
+gh_repo = "chef-web-docs"
+
+[menu]
+ [menu.infra]
+ title = "Attributes Arrays"
+ identifier = "chef_infra/cookbook_reference/attributes/attribute_arrays Attribute Arrays"
+ parent = "chef_infra/cookbook_reference/attributes"
++++
+
+Attributes are typically defined in cookbooks, recipes, roles, and environments. These attributes are rolled-up to the node level during a Chef Infra Client run. A recipe can store attribute values using a multi-level hash or array.
+
+For example, a group of attributes for web servers might be:
+
+```ruby
+override_attributes(
+ :apache => {
+ :listen_ports => [ 80 ],
+ :prefork => {
+ :startservers => 20,
+ :minspareservers => 20,
+ :maxspareservers => 40
+ }
+ }
+)
+```
+
+But what if all of the web servers aren't the same? What if some of the web servers required a single attribute to have a different value? You could store these settings in two locations, once just like the preceding example and once just like the following:
+
+```ruby
+override_attributes(
+ :apache => {
+ :listen_ports => [ 80 ],
+ :prefork => {
+ :startservers => 30,
+ :minspareservers => 20,
+ :maxspareservers => 40
+ }
+ }
+)
+```
+
+But that isn't efficient, especially because most of them are identical. The deep merge capabilities of Chef Infra Client allows attributes to be layered across cookbooks, recipes, roles, and environments. This allows an attribute to be reused across nodes, making use of default attributes set at the cookbook level, but also providing a way for certain attributes (with a higher attribute precedence) to be applied only when they're supposed to be.
+
+For example, a role named `baseline.rb`:
+
+```ruby
+name "baseline"
+description "The most basic role for all configurations"
+run_list "recipe[baseline]"
+
+override_attributes(
+ :apache => {
+ :listen_ports => [ 80 ],
+ :prefork => {
+ :startservers => 20,
+ :minspareservers => 20,
+ :maxspareservers => 40
+ }
+ }
+)
+```
+
+and then a role named `web.rb`:
+
+```ruby
+name 'web'
+description 'Web server config'
+run_list 'role[baseline]'
+
+override_attributes(
+ :apache => {
+ :prefork => {
+ :startservers => 30
+ }
+ }
+)
+```
+
+Both of these files are similar because they share the same structure. When an attribute value is a hash, that data is merged. When an attribute value is an array, if the attribute precedence levels are the same, then that data is merged. If the attribute value precedence levels in an array are different, then that data is replaced. For all other value types (such as strings, integers, etc.), that data is replaced.
+
+For example, the `web.rb` references the `baseline.rb` role. The `web.rb` file only provides a value for one attribute: `:startservers`. When Chef Infra Client compares these attributes, the deep merge feature will ensure that `:startservers` (and its value of `30`) will be applied to any node for which the `web.rb` attribute structure should be applied.
+
+This approach will allow a recipe like this:
+
+```ruby
+include_recipe 'apache2'
+Chef::Log.info(node['apache']['prefork'].to_hash)
+```
+
+and a `run_list` like this:
+
+```ruby
+run_list/web.json
+{
+ "run_list": [ "role[web]" ]
+}
+```
+
+to produce results like this:
+
+```ruby
+[Tue, 16 Aug 2011 14:44:26 -0700] INFO:
+ {
+ "startservers"=>30,
+ "minspareservers"=>20,
+ "maxspareservers"=>40,
+ "serverlimit"=>400,
+ "maxclients"=>400,
+ "maxrequestsperchild"=>10000
+ }
+```
+
+Even though the `web.rb` file doesn't contain attributes and values for `minspareservers`, `maxspareservers`, `serverlimit`, `maxclients`, and `maxrequestsperchild`, the deep merge capabilities pulled them in.
+
+## Attribute Array Logic
+
+The following sections show how the logic works for using deep merge to perform substitutions and additions of attributes.
+
+### Substitution
+
+The following examples show how the logic works for substituting an existing string using a hash:
+
+```text
+role_or_environment 1 { :x => '1', :y => '2' }
++
+role_or_environment 2 { :y => '3' }
+=
+{ :x => '1', :y => '3' }
+```
+
+For substituting an existing boolean using a hash:
+
+```text
+role_or_environment 1 { :x => true, :y => false }
++
+role_or_environment 2 { :y => true }
+=
+{ :x => true, :y => true }
+```
+
+For substituting an array with a hash:
+
+```text
+role_or_environment 1 [ '1', '2', '3' ]
++
+role_or_environment 2 { :x => '1' , :y => '2' }
+=
+{ :x => '1', :y => '2' }
+```
+
+When items can't be merged through substitution, the original data is overwritten.
+
+### Addition
+
+The following examples show how the logic works for adding a string
+using a hash:
+
+```text
+role_or_environment 1 { :x => '1', :y => '2' }
++
+role_or_environment 2 { :z => '3' }
+=
+{ :x => '1', :y => '2', :z => '3' }
+```
+
+For adding a string using an array:
+
+```text
+role_or_environment 1 [ '1', '2' ]
++
+role_or_environment 2 [ '3' ]
+=
+[ '1', '2', '3' ]
+```
+
+For adding a string using a multi-level hash:
+
+```text
+role_or_environment 1 { :x => { :y => '2' } }
++
+role_or_environment 2 { :x => { :z => '3' } }
+=
+{ :x => { :y => '2', :z => '3' } }
+```
+
+For adding a string using a multi-level array:
+
+```text
+role_or_environment 1 [ [ 1, 2 ] ]
++
+role_or_environment 2 [ [ 3 ] ]
+=
+[ [ 1, 2 ], [ 3 ] ]
+```
diff --git a/content/attribute_persistence.md b/content/attribute_persistence.md
new file mode 100644
index 0000000..e3e175d
--- /dev/null
+++ b/content/attribute_persistence.md
@@ -0,0 +1,116 @@
++++
+title = "Attribute Persistence"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+[menu]
+ [menu.infra]
+ title = "Attribute Persistence"
+ identifier = "chef_infra/cookbook_reference/attributes/attribute_persistence.md Attributes"
+ parent = "chef_infra/cookbook_reference/attributes"
++++
+
+All attributes, except for normal attributes, are reset at the beginning of a Chef Infra Client run.
+Attributes set using `chef-client -j` with a JSON file have normal precedence and are persisted between Chef Infra Client runs.
+Chef Infra Client rebuilds these attributes using automatic attributes collected by Ohai at the beginning of each Chef Infra Client
+run, and then uses default and override attributes that are specified in cookbooks, roles, environments, and Policyfiles.
+All attributes are then merged and applied to the node according to attribute precedence.
+The attributes that were applied to the node are saved to the Chef Infra Server as part of the node object at the conclusion of each Chef Infra Client run.
+
+## Limiting Attribute Persistence
+
+Some organizations find it helpful to control attribute data stored by the Chef Infra Server, whether to limit the disk and CPU resources used when processing unused attributes, or to keep secrets like API keys from being submitted to the server.
+For example, your organization may find the data from the Ohai `Package` plugin useful when writing cookbooks, but don't see the need in saving ~100kB of package information for each Chef Infra Client run.
+Attribute data will still be available on the node within cookbooks, but any information you limit won't be saved to the Chef Infra Server for use in searches.
+
+You can block or allow the saving of specific key using the [`client.rb`](/config_rb_client/) file.
+Each setting is an array of keys specifying each attribute to be filtered out or allowed. Use a "/" to separate subkeys, for example `network/interfaces`.
+
+For attributes containing slashes (`/`) within the attribute value, such as the `filesystem` attribute, use a nested array. For example:
+
+```ruby
+blocked_automatic_attributes [['filesystem', '/dev/diskos2']]
+```
+
+{{< note >}}
+
+In **Chef Infra Client 16.3**, the node Blacklist and Whitelist features were deprecated and renamed to Blocklist and Allowlist.
+In **Chef Infra Client 18.4.12** these features became EOL.
+For backwards compatibility, the old configuration values will continue to work through Chef Infra Client 17.x
+
+See each section below for the appropriate legacy configuration values if you are running legacy clients in your organization.
+
+Legacy attribute config mapping:
+
+- automatic_attribute_blacklist -> blocked_automatic_attributes
+- default_attribute_blacklist -> blocked_default_attributes
+- normal_attribute_blacklist -> blocked_normal_attributes
+- override_attribute_blacklist -> blocked_override_attributes
+- automatic_attribute_whitelist -> allowed_automatic_attributes
+- default_attribute_whitelist -> allowed_default_attributes
+- normal_attribute_whitelist -> allowed_normal_attributes
+- override_attribute_whitelist -> allowed_override_attributes
+
+{{< /note >}}
+
+### Attribute Blocklist
+
+{{< warning >}}
+
+{{< readfile file="content/reusable/md/node_attribute_blocklist_warning.md" >}}
+
+{{< /warning >}}
+
+{{< readfile file="content/reusable/md/node_attribute_blocklist.md" >}}
+
+### Attribute Allowlist
+
+{{< warning >}}
+
+{{< readfile file="content/reusable/md/node_attribute_allowlist_warning.md" >}}
+
+{{< /warning >}}
+
+Attributes are allowlisted by attribute type, with each attribute type being allowlisted independently in the `client.rb` file.
+
+The four attribute types are:
+
+- `automatic`
+- `default`
+- `normal`
+- `override`
+
+The allowlist settings are:
+
+`allowed_automatic_attributes`
+
+: An array that allows saving specific `automatic` attributes. For example: `['network/interfaces/eth0']`.
+
+ Default value: `nil`, all attributes are saved.
+
+ If the array is empty, no attributes are saved.
+
+`allowed_default_attributes`
+
+: An array that allows saving specific `default` attributes. For example: `['filesystem/dev/disk0s2/size']`.
+
+ Default value: `nil`, all attributes are saved.
+
+ If the array is empty, no attributes are saved.
+
+`allowed_normal_attributes`
+
+: An array that allows saving specific `normal` attributes. For example: `['filesystem/dev/disk0s2/size']`.
+
+ Default value: `nil`, all attributes are saved.
+
+ If the array is empty, no attributes are saved.
+
+`allowed_override_attributes`
+
+: An array that allows specific `override` attributes, preventing blocklisted attributes from being saved. For example: `['map - autohome/size']`.
+
+ Default value: `nil`, all attributes are saved.
+
+ If the array is empty, no attributes are saved.
diff --git a/content/attribute_precedence.md b/content/attribute_precedence.md
new file mode 100644
index 0000000..014af9a
--- /dev/null
+++ b/content/attribute_precedence.md
@@ -0,0 +1,517 @@
++++
+title = "Attribute Precedence"
+draft = false
+gh_repo = "chef-web-docs"
+
+[menu]
+ [menu.infra]
+ title = "Attribute Precedence"
+ identifier = "chef_infra/cookbook_reference/attributes/attribute_precedence"
+ parent = "chef_infra/cookbook_reference/attributes"
++++
+
+Chef Infra Client applies attributes in the following
+order:
+
+| Application Order (Last One Wins) | Attribute Type | Source Order |
+|-----------------------------------|------------------|---------------------------------------------------------------------|
+| 1 | `default` | Cookbook attribute fileRecipeEnvironmentRole |
+| 2 | `force_default` | Cookbook attribute fileRecipe |
+| 3 | `normal` | JSON file passed with `chef-client -j`Cookbook attribute fileRecipe |
+| 4 | `override` | Cookbook attribute fileRecipeRoleEnvironment |
+| 5 | `force_override` | Cookbook attribute fileRecipe |
+| 6 | `automatic` | Identified by Ohai at the start of a Chef Infra Client Run |
+
+{{< note >}}
+
+The attribute precedence order for the sources "roles" and "environments" are opposite in the `default` and `override`. The `default` order is **environment** then **role**. The `override` order is **role** then **environment**
+
+Applying the role `override` first lets you use the same role in a set of environments.
+Applying the environment `override` on top of the role `override` lets you define a subset of these with environment-specific settings.
+
+This is useful if you have an environment that's different within a sub-set of a role. For example, the role for an application server may exist in all environments, but one environment may use a different database server.
+
+{{< /note >}}
+
+Attribute precedence, viewed from the same perspective as the overview
+diagram, where the numbers in the diagram match the order of attribute
+precedence:
+
+
+
+Attribute precedence, when viewed as a table:
+
+| | Attribute Files | Node/Recipe | Environment | Role | Ohai Data |
+|----------------|-----------------|-------------|-------------|------|-----------|
+| default | 1 | 2 | 3 | 4 | |
+| force_default | 5 | 6 | | | |
+| normal | 7 | 8 | | | |
+| override | 9 | 10 | 12 | 11 | |
+| force_override | 13 | 14 | | | |
+| automatic | | | | | 15 |
+
+## Examples
+
+The following examples are listed from low to high precedence.
+
+**Default attribute in /attributes/default.rb**
+
+```ruby
+default['apache']['dir'] = '/etc/apache2'
+```
+
+**Default attribute in node object in recipe**
+
+```ruby
+node.default['apache']['dir'] = '/etc/apache2'
+```
+
+**Default attribute in /environments/environment_name.rb**
+
+```ruby
+default_attributes({ 'apache' => {'dir' => '/etc/apache2'}})
+```
+
+**Default attribute in /roles/role_name.rb**
+
+```ruby
+default_attributes({ 'apache' => {'dir' => '/etc/apache2'}})
+```
+
+**Normal attribute set as a cookbook attribute**
+
+```ruby
+normal['apache']['dir'] = '/etc/apache2'
+```
+
+**Normal attribute set in a recipe**
+
+```ruby
+node.normal['apache']['dir'] = '/etc/apache2'
+```
+
+**Override attribute in /attributes/default.rb**
+
+```ruby
+override['apache']['dir'] = '/etc/apache2'
+```
+
+**Override attribute in /roles/role_name.rb**
+
+```ruby
+override_attributes({ 'apache' => {'dir' => '/etc/apache2'}})
+```
+
+**Override attribute in /environments/environment_name.rb**
+
+```ruby
+override_attributes({ 'apache' => {'dir' => '/etc/apache2'}})
+```
+
+**Override attribute in a node object (from a recipe)**
+
+```ruby
+node.override['apache']['dir'] = '/etc/apache2'
+```
+
+**Ensure that a default attribute has precedence over other attributes**
+
+When a default attribute is set like this:
+
+```ruby
+default['attribute'] = 'value'
+```
+
+any value set by a role or an environment will replace it. To prevent
+this value from being replaced, use the `force_default` attribute
+precedence:
+
+```ruby
+force_default['attribute'] = 'I will crush you, role or environment attribute'
+```
+
+or:
+
+```ruby
+default!['attribute'] = "The '!' means I win!"
+```
+
+**Ensure that an override attribute has precedence over other
+attributes**
+
+When an override attribute is set like this:
+
+```ruby
+override['attribute'] = 'value'
+```
+
+any value set by a role or an environment will replace it. To prevent
+this value from being replaced, use the `force_override` attribute
+precedence:
+
+```ruby
+force_override['attribute'] = 'I will crush you, role or environment attribute'
+```
+
+or:
+
+```ruby
+override!['attribute'] = "The '!' means I win!"
+```
+
+## Change Attributes
+
+Attribute precedence levels may be:
+
+- Removed for a specific, named attribute precedence level.
+- Removed for all attribute precedence levels.
+- Fully assigned attributes.
+
+### Remove Precedence Level
+
+A specific attribute precedence level for default, normal, and override
+attributes may be removed by using one of the following syntax patterns.
+
+For default attributes:
+
+- `node.rm_default('foo', 'bar')`
+
+For normal attributes:
+
+- `node.rm_normal('foo', 'bar')`
+
+For override attributes:
+
+- `node.rm_override('foo', 'bar')`
+
+These patterns return the computed value of the key being deleted for
+the specified precedence level.
+
+#### Examples
+
+The following examples show how to remove a specific, named attribute
+precedence level.
+
+**Delete a default value when only default values exist**
+
+Given the following code structure under `'foo'`:
+
+```ruby
+node.default['foo'] = {
+ 'bar' => {
+ 'baz' => 52,
+ 'thing' => 'stuff',
+ },
+ 'bat' => {
+ 'things' => [5, 6],
+ },
+}
+```
+
+And some role attributes:
+
+```ruby
+# Please don't ever do this in real code :)
+node.role_default['foo']['bar']['thing'] = 'otherstuff'
+```
+
+And a force attribute:
+
+```ruby
+node.force_default['foo']['bar']['thing'] = 'allthestuff'
+```
+
+When the default attribute precedence `node['foo']['bar']` is removed:
+
+```ruby
+node.rm_default('foo', 'bar') #=> {'baz' => 52, 'thing' => 'allthestuff'}
+```
+
+What's left under `'foo'` is only `'bat'`:
+
+```ruby
+node.attributes.combined_default['foo'] #=> {'bat' => { 'things' => [5,6] } }
+```
+
+**Delete default without touching higher precedence attributes**
+
+Given the following code structure:
+
+```ruby
+node.default['foo'] = {
+ 'bar' => {
+ 'baz' => 52,
+ 'thing' => 'stuff',
+ },
+ 'bat' => {
+ 'things' => [5, 6],
+ },
+}
+```
+
+And some role attributes:
+
+```ruby
+# Please don't ever do this in real code :)
+node.role_default['foo']['bar']['thing'] = 'otherstuff'
+```
+
+And a force attribute:
+
+```ruby
+node.force_default['foo']['bar']['thing'] = 'allthestuff'
+```
+
+And also some override attributes:
+
+```ruby
+node.override['foo']['bar']['baz'] = 99
+```
+
+Same delete as before:
+
+```ruby
+node.rm_default('foo', 'bar') #=> { 'baz' => 52, 'thing' => 'allthestuff' }
+```
+
+The other attribute precedence levels are unaffected:
+
+```ruby
+node.attributes.combined_override['foo'] #=> { 'bar' => {'baz' => 99} }
+node['foo'] #=> { 'bar' => {'baz' => 99}, 'bat' => { 'things' => [5,6] }
+```
+
+**Delete override without touching lower precedence attributes**
+
+Given the following code structure, which has an override attribute:
+
+```ruby
+node.override['foo'] = {
+ 'bar' => {
+ 'baz' => 52,
+ 'thing' => 'stuff',
+ },
+ 'bat' => {
+ 'things' => [5, 6],
+ },
+}
+```
+
+with a single default value:
+
+```ruby
+node.default['foo']['bar']['baz'] = 11
+```
+
+and a force at each attribute precedence:
+
+```ruby
+node.force_default['foo']['bar']['baz'] = 55
+node.force_override['foo']['bar']['baz'] = 99
+```
+
+Delete the override:
+
+```ruby
+node.rm_override('foo', 'bar') #=> { 'baz' => 99, 'thing' => 'stuff' }
+```
+
+The other attribute precedence levels are unaffected:
+
+```ruby
+node.attributes.combined_default['foo'] #=> { 'bar' => {'baz' => 55} }
+```
+
+**Non-existent key deletes return nil**
+
+```ruby
+node.rm_default("no", "such", "thing") #=> nil
+```
+
+### Remove All Levels
+
+All attribute precedence levels may be removed by using the following
+syntax pattern:
+
+- `node.rm('foo', 'bar')`
+
+{{< note >}}
+
+Using `node['foo'].delete('bar')` will throw an exception that points to
+the new API.
+
+{{< /note >}}
+
+#### Examples
+
+The following examples show how to remove all attribute precedence
+levels.
+
+**Delete all attribute precedence levels**
+
+Given the following code structure:
+
+```ruby
+node.default['foo'] = {
+ 'bar' => {
+ 'baz' => 52,
+ 'thing' => 'stuff',
+ },
+ 'bat' => {
+ 'things' => [5, 6],
+ },
+}
+```
+
+With override attributes:
+
+```ruby
+node.override['foo']['bar']['baz'] = 999
+```
+
+Removing the `'bar'` key returns the computed value:
+
+```ruby
+node.rm('foo', 'bar') #=> {'baz' => 999, 'thing' => 'stuff'}
+```
+
+Looking at `'foo'`, all that's left is the `'bat'` entry:
+
+```ruby
+node['foo'] #=> {'bat' => { 'things' => [5,6] } }
+```
+
+**Non-existent key deletes return nil**
+
+```ruby
+node.rm_default("no", "such", "thing") #=> nil
+```
+
+### Full Assignment
+
+Use `!` to clear out the key for the named attribute precedence level,
+and then complete the write by using one of the following syntax
+patterns:
+
+- `node.default!['foo']['bar'] = {...}`
+- `node.force_default!['foo']['bar'] = {...}`
+- `node.normal!['foo']['bar'] = {...}`
+- `node.override!['foo']['bar'] = {...}`
+- `node.force_override!['foo']['bar'] = {...}`
+
+#### Examples
+
+The following examples show how to remove all attribute precedence
+levels.
+
+**Just one component**
+
+Given the following code structure:
+
+```ruby
+node.default['foo']['bar'] = {'a' => 'b'}
+node.default!['foo']['bar'] = {'c' => 'd'}
+```
+
+The `'!'` caused the entire 'bar' key to be overwritten:
+
+```ruby
+node['foo'] #=> {'bar' => {'c' => 'd'}
+```
+
+**Multiple components; one "after"**
+
+Given the following code structure:
+
+```ruby
+node.default['foo']['bar'] = {'a' => 'b'}
+# Please don't ever do this in real code :)
+node.role_default['foo']['bar'] = {'c' => 'd'}
+node.default!['foo']['bar'] = {'d' => 'e'}
+```
+
+The `'!'` write overwrote the "cookbook-default" value of `'bar'`, but
+since role data is later in the resolution list, it was unaffected:
+
+```ruby
+node['foo'] #=> {'bar' => {'c' => 'd', 'd' => 'e'}
+```
+
+**Multiple components; all "before"**
+
+Given the following code structure:
+
+```ruby
+node.default['foo']['bar'] = {'a' => 'b'}
+# Please don't ever do this in real code :)
+node.role_default['foo']['bar'] = {'c' => 'd'}
+node.force_default!['foo']['bar'] = {'d' => 'e'}
+```
+
+With `force_default!` there is no other data under `'bar'`:
+
+```ruby
+node['foo'] #=> {'bar' => {'d' => 'e'}
+```
+
+**Multiple precedence levels**
+
+Given the following code structure:
+
+```ruby
+node.default['foo'] = {
+ 'bar' => {
+ 'baz' => 52,
+ 'thing' => 'stuff',
+ },
+ 'bat' => {
+ 'things' => [5, 6],
+ },
+}
+```
+
+And some attributes:
+
+```ruby
+# Please don't ever do this in real code :)
+node.role_default['foo']['bar']['baz'] = 55
+node.force_default['foo']['bar']['baz'] = 66
+```
+
+And other precedence levels:
+
+```ruby
+node.normal['foo']['bar']['baz'] = 88
+node.override['foo']['bar']['baz'] = 99
+```
+
+With a full assignment:
+
+```ruby
+node.default!['foo']['bar'] = {}
+```
+
+Role default and force default are left in default, plus other
+precedence levels:
+
+```ruby
+node.attributes.combined_default['foo'] #=> {'bar' => {'baz' => 66}, 'bat'=>{'things'=>[5, 6]}}
+node.attributes.normal['foo'] #=> {'bar' => {'baz' => 88}}
+node.attributes.combined_override['foo'] #=> {'bar' => {'baz' => 99}}
+node['foo']['bar'] #=> {'baz' => 99}
+```
+
+If `force_default!` is written:
+
+```ruby
+node.force_default!['foo']['bar'] = {}
+```
+
+the difference is:
+
+```ruby
+node.attributes.combined_default['foo'] #=> {'bat'=>{'things'=>[5, 6]}, 'bar' => {}}
+node.attributes.normal['foo'] #=> {'bar' => {'baz' => 88}}
+node.attributes.combined_override['foo'] #=> {'bar' => {'baz' => 99}}
+node['foo']['bar'] #=> {'baz' => 99}
+```
diff --git a/content/attribute_sources.md b/content/attribute_sources.md
new file mode 100644
index 0000000..f0de233
--- /dev/null
+++ b/content/attribute_sources.md
@@ -0,0 +1,144 @@
++++
+title = "Attribute Sources"
+draft = false
+
+[menu]
+ [menu.infra]
+ title = "Attribute Sources"
+ identifier = "chef_infra/cookbook_reference/attributes/attribute_sources Attributes"
+ parent = "chef_infra/cookbook_reference/attributes"
++++
+
+
+Chef Infra Client evaluates attributes in the order that they're defined in the
+run-list, including any attributes that are in the run-list as
+cookbook dependencies.
+
+Attributes are provided to Chef Infra Client from the following
+locations:
+
+- JSON files passed using the `chef-client -j`
+- Nodes (collected by Ohai at the start of each Chef Infra Client run)
+- Attribute files (in cookbooks)
+- Recipes (in cookbooks)
+- Environments
+- Roles
+- Policyfiles
+
+Notes:
+
+- Many attributes are maintained in the chef-repo for Policyfiles,
+ environments, roles, and cookbooks (attribute files and recipes)
+- Many attributes are collected by Ohai on each individual node at the
+ start of every Chef Infra Client run
+- The attributes that are maintained in the chef-repo are uploaded to
+ the Chef Infra Server from the workstation, periodically
+- Chef Infra Client will pull down the node object from the Chef Infra
+ Server and then reset all the attributes except `normal`. The node
+ object will contain the attribute data from the previous Chef Infra
+ Client run including attributes set with JSON files using `-j`.
+- Chef Infra Client will update the cookbooks on the node (if
+ required), which updates the attributes contained in attribute files
+ and recipes
+- Chef Infra Client will update the role and environment data (if
+ required)
+- Chef Infra Client will rebuild the attribute list and apply
+ attribute precedence while configuring the node
+- Chef Infra Client pushes the node object to the Chef Infra Server at
+ the end of a Chef Infra Client run; the updated node object on the
+ Chef Infra Server is then indexed for search and is stored until the
+ next Chef Infra Client run
+
+## Automatic Attributes (Ohai)
+
+{{< readfile file="content/reusable/md/ohai_automatic_attribute.md" >}}
+
+{{< readfile file="content/reusable/md/ohai_attribute_list.md" >}}
+
+## Attribute Files
+
+An attribute file is located in the `attributes/` sub-directory for a
+cookbook. When a cookbook is run against a node, the attributes
+contained in all attribute files are evaluated in the context of the
+node object. Node methods (when present) are used to set attribute
+values on a node. For example, the `apache2` cookbook contains an
+attribute file called `default.rb`, which contains the following
+attributes:
+
+```ruby
+default['apache']['dir'] = '/etc/apache2'
+default['apache']['listen_ports'] = [ '80','443' ]
+```
+
+The use of the node object (`node`) is implicit in the previous example;
+the following example defines the node object itself as part of the
+attribute:
+
+```ruby
+node.default['apache']['dir'] = '/etc/apache2'
+node.default['apache']['listen_ports'] = [ '80','443' ]
+```
+
+Another (much less common) approach is to set a value only if an
+attribute has no value. This can be done by using the `_unless` variants
+of the attribute priority methods:
+
+- `default_unless`
+- `normal_unless`
+
+Use the `_unless` variants carefully (and only when necessary) because
+when they're used, attributes applied to nodes may become out of sync
+with the values in the cookbooks as these cookbooks are updated. This
+approach can create situations where two otherwise identical nodes end
+up having slightly different configurations and can also be a challenge
+to debug.
+
+### File Methods
+
+Use the following methods within the attributes file for a cookbook or within a recipe. These methods correspond to the attribute type of the same name:
+
+- `override`
+- `default`
+- `normal`
+- `_unless`
+
+### attribute?
+
+A useful method that's related to attributes is the `attribute?`
+method. This method will check for the existence of an attribute, so
+that processing can be done in an attributes file or recipe, but only if
+a specific attribute exists.
+
+Using `attribute?()` in an attributes file:
+
+```ruby
+if attribute?('ec2')
+ # ... set stuff related to EC2
+end
+```
+
+Using `attribute?()` in a recipe:
+
+```ruby
+if node.attribute?('ec2')
+ # ... do stuff on EC2 nodes
+end
+```
+
+## Attributes from Recipes
+
+{{< readfile file="content/reusable/md/cookbooks_recipe.md" >}}
+
+{{< readfile file="content/reusable/md/cookbooks_attribute.md" >}}
+
+## Attributes from Roles
+
+{{< readfile file="content/reusable/md/role.md" >}}
+
+{{< readfile file="content/reusable/md/role_attribute.md" >}}
+
+## Attributes from Environments
+
+{{< readfile file="content/reusable/md/environment.md" >}}
+
+{{< readfile file="content/reusable/md/environment_attribute.md" >}}
diff --git a/content/attribute_types.md b/content/attribute_types.md
new file mode 100644
index 0000000..fab3b6a
--- /dev/null
+++ b/content/attribute_types.md
@@ -0,0 +1,36 @@
++++
+title = "Attribute Types"
+draft = false
+aliases = ["/essentials_cookbook_attribute_files_attribute_automatic"]
+gh_repo = "chef-web-docs"
+
+[menu]
+ [menu.infra]
+ title = "Attribute Types"
+ identifier = "chef_infra/cookbook_reference/attributes/attributes_types.md Attributes"
+ parent = "chef_infra/cookbook_reference/attributes"
++++
+
+Chef Infra Client uses six types of attributes to determine the value that's applied to a node during a Chef Infra Client run.
+In addition, Chef Infra Client gathers attribute values from up to five locations.
+The combination of attribute types and sources makes up to 15 different competing values available during a Chef Infra Client run.
+
+The attribute types are:
+
+`default`
+: {{< readfile file="content/reusable/md/node_attribute_type_default.md" >}}
+
+`force_default`
+: Use the force_default attribute to ensure that an attribute defined in a cookbook (by an attribute file or by a recipe) takes precedence over a default attribute set by a role or an environment.
+
+`normal`
+: {{< readfile file="content/reusable/md/node_attribute_type_normal.md" >}}
+
+`override`
+: {{< readfile file="content/reusable/md/node_attribute_type_override.md" >}}
+
+`force_override`
+: Use the force_override attribute to ensure that an attribute defined in a cookbook (by an attribute file or by a recipe) takes precedence over an override attribute set by a role or an environment.
+
+`automatic`
+: {{< readfile file="content/reusable/md/node_attribute_type_automatic.md" >}}
diff --git a/content/attributes.md b/content/attributes.md
new file mode 100644
index 0000000..e89dcbe
--- /dev/null
+++ b/content/attributes.md
@@ -0,0 +1,17 @@
++++
+title = "About Attributes"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+aliases = ["/attributes.html", "essentials_cookbook_attribute_files.html", "chef_overview_attributes.html", ]
+
+[menu]
+ [menu.infra]
+ title = "Attributes"
+ identifier = "chef_infra/cookbook_reference/attributes/attributes.md Attributes"
+ parent = "chef_infra/cookbook_reference/attributes"
+ weight = 10
++++
+
+{{< readfile file="content/reusable/md/node_attribute.md" >}}
diff --git a/content/aws_marketplace.md b/content/aws_marketplace.md
new file mode 100644
index 0000000..d577611
--- /dev/null
+++ b/content/aws_marketplace.md
@@ -0,0 +1,188 @@
++++
+title = "AWS Marketplace"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+aliases = ["/aws_marketplace.html", "/aws_ami.html"]
+
+product = ["client", "workstation", "automate"]
+
+[menu]
+ [menu.infra]
+ title = "AWS Marketplace"
+ identifier = "chef_infra/integrations/aws_marketplace.md AWS Marketplace"
+ parent = "chef_infra/integrations"
+ weight = 10
++++
+
+Chef Automate is an enterprise platform that allows developers, operations, and security engineers to collaborate on application and infrastructure changes with speed and at scale. Chef Automate provides actionable insights across data centers and cloud providers, wherever your nodes live.
+
+Chef Automate is the center of the modern Chef platform, providing users with a single source of truth for infrastructure, security, and application automation. The comprehensive dashboard offers real-time views of your configuration management activity. Chef Automate comes bundled with the latest Chef Infra Server, providing the core tools you need to manage your enterprise infrastructure. Data collection is enabled by default, allowing your nodes to report activity in real time. This instance is free for 60 days, or you can bring your own license (BYOL).
+
+Use this instance with Chef Workstation installed on your laptop or a separate AWS instance.
+
+{{< readfile file="content/reusable/md/workstation.md" >}}
+
+{{< readfile file="content/reusable/md/automate_ha_support.md" >}}
+
+## Installation
+
+Select [Chef Automate](https://aws.amazon.com/marketplace/pp/prodview-r26bs6uknftps?) in the AWS Marketplace.
+
+The Chef Automate AWS deployment uses [CloudFormation](https://aws.amazon.com/cloudformation/). [Download the CloudFormation template](https://aws-ami-chef-automate-v2.s3.amazonaws.com/cloudformation_template.yaml) or use the [view the template in CloudFormation Designer](https://us-east-1.console.aws.amazon.com/cloudformation/designer/home?region=us-east-1&templateURL=https://s3.amazonaws.com/awsmp-fulfillment-cf-templates-prod/658820ac-955d-4f73-bbcd-ab19b598d852.caadc0d6-b62a-4b83-d9b0-ec685d27c0bc.template)
+
+Every CloudFormation Stack deployment creates a new [Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) (VPC).
+
+{{< note >}}
+AWS provides five VPCs for each region. If you require more VPCs, please contact [AWS Support](https://aws.amazon.com/contact-us/).
+{{< /note >}}
+
+### Start Chef Automate with CloudFormation
+
+1. Enter the following values for your deployment:
+
+ Stack Name
+ : `Chef-Automate`
+
+ EC2RootVolumeSize
+ : `Default: 40`
+
+ Instance Type
+ : `Default: t2.xlarge`
+
+ KeyName
+ : _Enter your existing keypair._
+
+ SecurityGroupCidrIp
+ : `0.0.0.0/0`
+
+ SubnetCIDR
+ : `10.0.0.0/24`
+
+ VpcCIDR
+ : `10.0.0.0/16`
+
+1. Select **Next** after entering these values.
+
+1. Configure the CloudFormation stack options:
+
+ 1. Create a tag for your stack with **Key** set to `Name` and **Value** to `Chef-automate-stack`.
+
+ 1. Set permissions for your stack:
+
+ 1. Create an IAM role with `AmazonEC2FullAccess` to enable resource creation using the CloudFormation template.
+ 1. Once that role is created, select the IAM role from the dropdown menu.
+
+ 1. Configure stack failure options:
+
+ AWS provides two stack-failure options:
+
+ Roll back all stack resources
+ : In case of failure, it should rollback all created resources (`Default: Roll back all stack resources`).
+
+ Preserve successfully provisioned resources
+ : In case of failure, it will rollback only failed resources.
+
+ 1. Configure advanced options:
+
+ 1. Set the stack policy.
+
+ The stack policy defines the update actions that can be performed on resources.`Default: No stack policy`.
+
+ 1. Set the rollback configuration.
+
+ AWS CloudFormation will monitor the state of your application during stack creation and updating. For more information, see [Amazon's documentation on rollback triggers](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-rollback-triggers.html).
+
+ 1. Configure notification options:
+
+ Create or attach an AWS Simple Notification Service (SNS) which will send email notifications about the stack creation process.
+
+ 1. Set the stack creation options:
+
+ Timeout
+ : If specified and stack creation isn't completed in that time, CloudFormation will roll back the stack.
+
+ Termination Protection
+ : Termination protection prevents a user from deleting a stack.
+
+1. Select **Next** to create your Chef Automate deployment. This process can take several minutes.
+
+For additional information about these options, see [Amazon's documentation on CloudFormation stack options](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-add-tags.html).
+
+## Post-Installation
+
+1. Navigate to the AWS deployment **Outputs** tab and locate the Chef Automate URL, user name, and password. You will need these in the next steps.
+
+
+1. Open your browser and paste the Chef Automate URL, which will open an alert page.
+
+1. Select **Advanced** and continue.
+.
+
+1. Enter your **Username** and **Password** and select **Sign In**.
+
+
+1. Fill out the registration form and [Accept the Chef License](/licensing/accept/).
+
+1. Select **Register** to enter Chef Automate.
+
+
+1. Congratulations! You've started Chef Automate!
+
+
+## Add Chef Servers
+
+1. Add Chef-Server Details, select the Add Chef Infra Server Button.
+
+
+1. Enter the server name, FQDN, and IP address. Then select **Add Chef Infra Server** to create the server.
+
+ Name
+ : Add the name of the Chef Infra Server.
+
+ FQDN
+ : Enter the same as the Chef Automate FQDN.
+
+ IP Address
+ : Public IP address of the EC2 instance.
+
+ {{< figure src="/images/automate/add-chef-server-popup-menu.png" alt="Add Chef Infra Server Form" width="500" >}}
+
+1. The Chef Infra Server will appear in the list of servers. Selecting the server allows you to view information about it.
+
+
+1. Select **Add Chef Organization**.
+{{< figure src="/images/chef_automate_add_org_page.png" style="width: 30%;" >}}
+
+1. Enter the following information:
+
+ Name
+ : demo
+
+ Admin User
+ : admin
+
+ Admin Key
+ : _copy the key from starter kit_
+
+1. Select **Add Chef Organization**.
+{{< figure src="/images/OrgPageDetails.png" alt="Select the Add Chef Organization button to complete this actio" width="500" >}}
+
+## AWS Deployment Security
+
+Update the AWS Deployment **Security Group** to require source IP addresses for a secure SSH connection.
+
+1. Select the **Instance Security** group in the **Resources** tab of your AWS Chef Automate deployment.
+
+
+1. Select the **Security Group ID** for your Chef Automate deployment.
+
+
+1. Select **Edit inbound rules**.
+
+
+1. Select **Add rule** and then **SSH** and enter the source IP.
+
+1. Select **Save rules** to finish.
+
diff --git a/content/azure_chef_cli.md b/content/azure_chef_cli.md
new file mode 100644
index 0000000..53fe0e3
--- /dev/null
+++ b/content/azure_chef_cli.md
@@ -0,0 +1,336 @@
++++
+title = "Microsoft Azure CLI"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+aliases = ["/azure_chef_cli.html"]
+
+[menu]
+ [menu.infra]
+ title = "Microsoft Azure Chef Extension"
+ identifier = "chef_infra/integrations/azure/azure_chef_cli.md Microsoft Azure Chef Extension"
+ parent = "chef_infra/integrations/azure"
+ weight = 40
++++
+
+The Azure Chef Extension is an extension for Microsoft Azure to enable
+Chef on virtual machine instances. The extension makes available two
+Windows PowerShell cmdlets and two Microsoft Azure CLI commands.
+
+## Azure CLI
+
+If the Microsoft Azure [cross-platform command line tool
+(Xplat-CLI)](https://github.com/Azure/azure-xplat-cli) is installed on
+the workstation along with the Azure Chef Extension, you can use the `get-chef` and
+`set-chef` extensions to manage Chef running on virtual
+machines in Microsoft Azure.
+
+### get-chef
+
+Use the `get-chef` command to get the details for the Azure Chef
+Extension that's running on the named virtual machine.
+
+#### Syntax
+
+This command has the following syntax:
+
+```bash
+azure vm extension get-chef VM_NAME
+```
+
+### set-chef
+
+Use the `set-chef` command to enable Chef on any virtual machine running
+on Microsoft Azure.
+
+#### Syntax
+
+This command has the following syntax:
+
+```bash
+azure vm extension set-chef VM_NAME (options)
+```
+
+#### Options
+
+This command has the following options:
+
+`-a`, `--auto-update-client`
+
+: Automatically update Chef Infra Client. Set to `true` to automatically update the version of the Azure Chef Extension when the virtual machine is restarted. For example, if this option is enabled, a virtual machine that has version `1205.12.2.0` will be updated automatically to `1205.12.2.1` when it's published. Default value: `false`.
+
+`-b`, `--disable`
+
+: Disable the Azure Chef Extension extension.
+
+`-c PATH_TO_CONFIG`, `--client-config PATH_TO_CONFIG`
+
+: The path to the `client.rb` file.
+
+`-C CLIENT_PEM`, `--client-pem CLIENT_PEM`
+
+: The location of the file that contains the client key. Default value: `/etc/chef/client.pem`.
+
+`-D`, `--delete-chef-config`
+
+: Disable the Azure Chef Extension extension.
+
+`-j JSON`, `--bootstrap-options JSON`
+
+: A JSON string that's added to the first run of a Chef Infra Client.
+ For example:
+
+ ```bash
+ -j '{"chef_node_name":"test_node"}'
+ ```
+
+ Supported options: `"chef_node_name"`, `"chef_server_url"`(required), `"environment"`, `"secret"`, and `"validation_client_name"` (required).
+
+`-O VALIDATOR_PEM`, `--validation-pem VALIDATOR_PEM`
+
+: The location of the file that contains the key used when a Chef Infra Client is registered with a Chef Infra Server. A validation key is signed using the `validation_client_name` for authentication. Default value: `/etc/chef/validation.pem`.
+
+`-R RUN_LIST`, `--run-list RUN_LIST`
+
+: A comma-separated list of roles and/or recipes to be applied.
+
+`-u`, `--uninstall`
+
+: Uninstall the Azure Chef Extension.
+
+`-V NUMBER`, `--version NUMBER`
+
+: Specify the version number for the Azure Chef Extension extension. Default is to use the latest extension's version number.
+
+#### Examples
+
+The following examples show how to use this knife subcommand:
+
+##### Create a virtual machine
+
+```bash
+azure vm create your-vm-name MSFT__Windows-Server-2012 yourusername yourpassword --location "West US" -r
+```
+
+##### Set the Chef extension without a run-list
+
+```bash
+azure vm extension set-chef your-vm-name --validation-pem ~/chef-repo/.chef/testorg-validator.pem --client-config ~/chef-repo/.chef/client.rb --version "1201.12"
+```
+
+##### Set the Chef extension with a run-list
+
+```bash
+azure vm extension set-chef your-vm-name --validation-pem ~/chef-repo/.chef/testorg-validator.pem --client-config ~/chef-repo/.chef/client.rb --version "1201.12" -R 'recipe[your_cookbook_name::your_recipe_name]'
+```
+
+##### Azure Resource Manager (ARM) templates
+
+If you are using Azure Resource Manager templates to create your infrastructure you can use the Chef extension to have Azure handle the bootstrapping/configuration of your node to your Chef Infra Server.
+
+### Options
+
+The extension has the following options that can be provided in the
+**settings** hash.
+
+`runlist`
+
+: A comma-separated list of roles and/or recipes to be applied.
+
+`client_rb`
+
+: A JSON escaped string containing the content of your `client.rb` file.
+
+`validation_key_format`
+
+: Tells the extension whether the supplied validation key is `plaintext` or `base64encoded`.
+
+ {{< note >}}
+
+ If using the Chef extension in an ARM template, it's recommended that you base64 encode your validation key and set this option to `base64encoded`
+
+ {{< /note >}}
+
+`bootstrap_version`
+
+: The version of Chef Infra Client that will be installed on the system. **Linux only**
+
+ {{< note >}}
+ Due to constraints in Azure, the `bootstrap_version` option is only available on the `LinuxChefClient` extension.
+ {{< /note >}}
+
+`bootstrap_channel`
+
+: Specify the [channel](/packages/) for installing the Chef Infra Client version. Options are `stable`, `current` or `unstable` release channels.
+
+`chef_package_path`
+
+: Specifies a local path to install Chef Infra Client from. This feature is mainly used for cases where there are restrictions on internet access.
+
+ {{< note >}}
+ Azure extensions have network access limitations. See the [Azure documentation](https://docs.microsoft.com/en-us/azure/virtual-machines/extensions/features-linux#network-access) for more information.
+ {{< /note >}}
+
+`CHEF_LICENSE`
+
+: Chef Infra Client 15+ requires accepting the CHEF EULA license. Set `CHEF_LICENSE` to one of these values `accept`, `accept-silent` or `accept-no-persist`. Refer to [CHEF EULA license](/chef_license_accept/#accept-the-chef-eula)
+
+`hints`
+
+: Specifies the [Ohai Hints](/ohai/#hints) to be set in the Ohai configuration of the target node.
+
+`chef_package_url`
+
+: Specifies a URL to download and install the Chef Infra Client package (.msi .rpm .deb) from.
+
+`bootstrap_options`
+
+: A hash of the following options: `chef_node_name`, `chef_server_url`, `environment`, `secret`, and `validation_client_name`.
+
+ {{< note >}}
+
+ Options that are supplied in the bootstrap items will take precedence over any conflicts found in the `client.rb` file.
+
+ {{< /note >}}
+
+`chef_node_name`
+
+: Determines which configuration should be applied and sets the `client_name`, which is the name used when authenticating to a Chef Infra Server. The default value is the Chef Infra Client FQDN, as detected by Ohai. In general, Chef recommends that you leave this setting blank and let Ohai assign the FQDN of the node as the `node_name` during each Chef Infra Client run.
+
+`chef_server_url`
+
+: The URL for the Chef Infra Server.
+
+`environment`
+
+: The environment this machine will be placed in on your Chef Infra Server.
+
+`secret`
+
+: The encryption key that's used for values contained within a data bag item.
+
+`validation_client_name`
+
+: The name of the chef-validator key that Chef Infra Client uses to access the Chef Infra Server during the initial Chef Infra Client run.
+
+`node_ssl_verify_mode`
+
+: Set the verify mode for HTTPS requests.
+
+`node_verify_api_cert`
+
+: Verify the SSL certificate on the Chef Infra Server. When `true`, Chef Infra Client always verifies the SSL certificate. When `false`, Chef Infra Client uses the value of `ssl_verify_mode` to determine if the SSL certificate requires verification.
+
+#### Protected settings
+
+The following options can be provided to the extension through the `protectedSettings` hash:
+
+`validation_key`
+
+: The contents of your organization validator key, the format is dependent on `validation_key_format`.
+
+`chef_server_crt`
+
+: The SSL certificate of your Chef Infra Server that will be added to the trusted certificates.
+
+`client_pem`
+
+: A client key that will be used to communication with the Chef Infra Server.
+
+### Examples
+
+The following examples show how you can install and configure Chef Infra Client from an ARM template.
+
+#### Install the Azure Chef extension on a Linux system
+
+```json
+{
+ "type": "Microsoft.Compute/virtualMachines/extensions",
+ "name": "myVirtualMachine/LinuxChefClient",
+ "apiVersion": "2015-05-01-preview",
+ "location": "westus",
+ "properties": {
+ "publisher": "Chef.Bootstrap.WindowsAzure",
+ "type": "LinuxChefClient",
+ "typeHandlerVersion": "1210.12",
+ "settings": {
+ "bootstrap_options": {
+ "chef_node_name": "node1",
+ "chef_server_url": "https://api.chef.io/organizations/my-chef-organization",
+ "validation_client_name": "my-chef-organization-validator"
+ },
+ "runlist": "recipe[awesome_customers_rhel],recipe[yum],role[base]",
+ "validation_key_format": "plaintext"
+ },
+ "protectedSettings": {
+ "validation_key": "-----BEGIN RSA PRIVATE KEY-----\nMIIEpQIB..\n67VT3Dg=\n-----END RSA PRIVATE KEY-----"
+ }
+ }
+ }
+```
+
+#### Install the Azure Chef extension on a Windows system
+
+```json
+{
+ "type": "Microsoft.Compute/virtualMachines/extensions",
+ "name": "myVirtualMachine/ChefClient",
+ "apiVersion": "2015-05-01-preview",
+ "location": "westus",
+ "properties": {
+ "publisher": "Chef.Bootstrap.WindowsAzure",
+ "type": "ChefClient",
+ "typeHandlerVersion": "1210.12",
+ "settings": {
+ "bootstrap_options": {
+ "chef_node_name": "node12",
+ "chef_server_url": "https://api.chef.io/organizations/my-chef-organization",
+ "validation_client_name": "my-chef-organization-validator"
+ },
+ "runlist": "recipe[awesome_customers_windows],recipe[iis],role[windows_base]",
+ "chef_package_url" : "https://download.example.com/chef-client-15.11.8-1-x64.msi",
+ "validation_key_format": "plaintext"
+ },
+ "protectedSettings": {
+ "validation_key": "-----BEGIN RSA PRIVATE KEY-----\nMIIEpQIB..\n67VT3Dg=\n-----END RSA PRIVATE KEY-----"
+ }
+ }
+}
+```
+
+#### Install the Azure Chef extension on a Linux system with SSL peer verification turned off and given a data bag secret
+
+```json
+{
+ "type": "Microsoft.Compute/virtualMachines/extensions",
+ "name": "myVirtualMachine/LinuxChefClient",
+ "apiVersion": "2015-05-01-preview",
+ "location": "westus",
+ "properties": {
+ "publisher": "Chef.Bootstrap.WindowsAzure",
+ "type": "LinuxChefClient",
+ "typeHandlerVersion": "1210.12",
+ "settings": {
+ "bootstrap_options": {
+ "chef_node_name": "node1",
+ "chef_server_url": "https://api.chef.io/organizations/my-chef-organization",
+ "validation_client_name": "my-chef-organization-validator",
+ "node_ssl_verify_mode": "none",
+ "secret": "KCYWGXxSrkgR..."
+ },
+ "runlist": "recipe[awesome_customers_rhel],recipe[yum],role[base]",
+ "validation_key_format": "base64encoded"
+ },
+ "protectedSettings": {
+ "validation_key": "LS0tLS1CRUdJTiBSU0EgUFJ...FIEtFWS0tLS0t"
+ }
+ }
+ }
+```
+
+{{< note >}}
+
+In this example the validator key is base64 encoded, which is a recommended approach when using the Azure Chef extension in an ARM template.
+
+{{< /note >}}
diff --git a/content/azure_cwa_cloud_shell.md b/content/azure_cwa_cloud_shell.md
new file mode 100644
index 0000000..d7587f0
--- /dev/null
+++ b/content/azure_cwa_cloud_shell.md
@@ -0,0 +1,43 @@
++++
+title = "Chef Workstation in Azure Cloud Shell"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/azure_cwa_cloud_shell.html"]
+
+product = ["client", "workstation"]
+
+[menu]
+ [menu.infra]
+ title = "Chef Workstation in Azure Cloud Shell"
+ identifier = "chef_infra/integrations/azure/azure_cwa_cloud_shell.md Chef Workstation in Azure Cloud Shell"
+ parent = "chef_infra/integrations/azure"
+ weight = 20
++++
+
+Chef Workstation is available in Azure Cloud Shell, allowing users to
+run ad-hoc configurations on target systems and any other Chef command
+when connected to an Azure subscription. This makes all of the Chef
+command line tools available, without installing software on a local
+machine.
+
+Chef Workstation on Azure Cloud Shell lets you use:
+
+- [chef](/ctl_chef/)
+- [kitchen](/workstation/ctl_kitchen/)
+- [inspec](/inspec/cli/)
+- [knife](/workstation/knife/)
+- [cookstyle](/workstation/cookstyle/)
+- [chef-run](/workstation/chef_run/)
+
+Combine the Chef Workstation command utilities with the other tools
+available in Cloud Shell, such as git, az-cli, terraform to write your
+infrastructure and compliance automation from the browser--without the
+need for a local shell.
+
+## Azure Cloud Shell Installation
+
+Ensure you have an accessible Azure Cloud Shell instance. You may need
+to create a storage account to use Azure Cloud Shell if you haven't used
+it before in this tenant. For more information on accessing, setting up,
+and using Azure Cloud Shell, see the [Cloud Shell
+Documentation](https://docs.microsoft.com/en-us/azure/cloud-shell/quickstart).
diff --git a/content/azure_powershell.md b/content/azure_powershell.md
new file mode 100644
index 0000000..d47931f
--- /dev/null
+++ b/content/azure_powershell.md
@@ -0,0 +1,194 @@
++++
+title = "Microsoft Azure PowerShell"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+aliases = ["/azure_powershell.html"]
+
+[menu]
+ [menu.infra]
+title = "Microsoft Azure PowerShell"
+identifier = "chef_infra/integrations/azure/azure_powershell.md Microsoft Azure PowerShell"
+parent = "chef_infra/integrations/azure"
+weight = 30
++++
+
+## PowerShell Cmdlets
+
+If Windows PowerShell is installed on the workstation, along with the Azure Chef Extension, the `Get-AzureVMChefExtension` and `Set-AzureVMChefExtension` extensions may be used to manage Chef running
+on virtual machines in Microsoft Azure.
+
+### Get-AzureVMChefExtension
+
+Use the `Get-AzureVMChefExtension` cmdlet to get the details for the
+Azure Chef Extension that's running on the named virtual machine.
+
+#### Syntax
+
+This cmdlet has the following syntax:
+
+```bash
+Get-AzureVMChefExtension -VM
+```
+
+#### Example
+
+The following examples show how to use the `Get-AzureVMChefExtension`
+cmdlet:
+
+##### Get details for a virtual machine
+
+```bash
+Get-AzureVM -ServiceName cloudservice1 -Name azurevm1 | Get-AzureVMExtension
+```
+
+### Set-AzureVMChefExtension
+
+Use the `Set-AzureVMChefExtension` cmdlet to enable Chef on any virtual
+machine running on Microsoft Azure.
+
+#### Syntax
+
+This cmdlet has the following syntax.
+
+For Windows:
+
+```bash
+Set-AzureVMChefExtension -ValidationPem -VM -Windows [-ChefServerUrl ] [-ClientRb ] [-OrganizationName ] [-RunList ] [-ValidationClientName ] [-Version ] [ ]
+```
+
+For Linux:
+
+```bash
+Set-AzureVMChefExtension -Linux -ValidationPem -VM [-ChefServerUrl ] [-ClientRb ] [-OrganizationName ] [-RunList ] [-ValidationClientName ] [-Version ] [ ]
+```
+
+#### Options
+
+This cmdlet has the following options:
+
+`-AutoUpdateChefClient`
+
+: Automatically update . Set to `true` to automatically update the version of the Azure Chef Extension when the virtual machine is restarted. For example, if this option is enabled, a virtual machine that has version `1205.12.2.0` will be updated automatically to `1205.12.2.1` when it's published.
+
+`-BootstrapOptions `
+
+: A JSON string that's added to the first run of a Chef Infra Client.
+
+ For example:
+
+ ```bash
+ -BootstrapOptions '{"chef_node_name":"test_node"}'
+ ```
+
+ Supported options: `"chef_node_name"`, `"chef_server_url"` (required), `"environment"`, `"secret"`, and `"validation_client_name"` (required).
+
+`-ChefServerUrl `
+
+: The URL for the Chef Infra Server.
+
+`-ClientRb `
+
+: The path to the `client.rb` file.
+
+`-DeleteChefConfig`
+
+: Disable the Azure Chef Extension extension.
+
+`-Linux`
+
+: Sets the Azure Chef Extension to run Linux.
+
+`-OrganizationName `
+
+: The name of the organization on the Chef Infra Server.
+
+`-RunList `
+
+: A comma-separated list of roles and/or recipes to be applied.
+
+`-ValidationClientName `
+
+: The name of the chef-validator key Chef Infra Client uses to access the Chef Infra Server during the initial Chef Infra Client run.
+
+`-ValidationPem `
+
+: The location of the file that contains the key used when a Chef Infra Client is registered with a Chef Infra Server. A validation key is signed using the `validation_client_name` for authentication. Default value: `/etc/chef/validation.pem`.
+
+`-Version `
+
+: Specify the version number for the Azure Chef Extension extension. Default is to use the latest extension's version number.
+
+`-Windows`
+
+: Sets the Azure Chef Extension to run Windows.
+
+#### Examples
+
+The following examples show how to use the `Set-AzureVMChefExtension`
+cmdlet:
+
+##### Create Windows virtual machine
+
+```bash
+$vm1 = "azurechefwin"
+$svc = "azurechefwin"
+$username = 'azure'
+$password = 'azure@123'
+
+$img = "a699494373c04fc0bc8f2bb1389d6106__Windows-Server-2012-R2-201406.01-en.us-127GB.vhd"
+
+$vmObj1 = New-AzureVMConfig -Name $vm1 -InstanceSize Small -ImageName $img
+
+$vmObj1 = Add-AzureProvisioningConfig -VM $vmObj1 -Password $password -AdminUsername $username -Windows
+
+# set azure chef extension
+$vmObj1 = Set-AzureVMChefExtension -VM $vmObj1 -ValidationPem "C:\\users\\azure\\msazurechef-validator.pem" -ClientRb
+"C:\\users\\azure\\client.rb" -RunList "getting-started" -Windows
+
+New-AzureVM -Location 'West US' -ServiceName $svc -VM $vmObj1
+```
+
+##### Create CentOS virtual machine
+
+```bash
+$vm1 = "azurecheflnx"
+$svc = "azurecheflnx"
+$username = 'azure'
+$password = 'azure@123'
+
+# CentOS image id
+$img = "5112500ae3b842c8b9c604889f8753c3__OpenLogic-CentOS-71-20150605"
+
+$vmObj1 = New-AzureVMConfig -Name $vm1 -InstanceSize Small -ImageName $img
+
+$vmObj1 = Add-AzureProvisioningConfig -VM $vmObj1 -Password $password -Linux -LinuxUser $username
+
+# set azure chef extension
+$vmObj1 = Set-AzureVMChefExtension -VM $vmObj1 -ValidationPem "C:\\users\\azure\\msazurechef-validator.pem" -ClientRb
+"C:\\users\\azure\\client.rb" -RunList "getting-started" -Linux
+
+New-AzureVM -Location 'West US' -ServiceName $svc -VM $vmObj1
+```
+
+##### Create Ubuntu virtual machine
+
+```bash
+$vm1 = "azurecheflnx"
+$svc = "azurecheflnx"
+$username = 'azure'
+$password = 'azure@123'
+
+$img = "b39f27a8b8c64d52b05eac6a62ebad85__ubuntu-20_04_5-LTS-amd64-server-20150127-en-us-30GB"
+
+$vmObj1 = New-AzureVMConfig -Name $vm1 -InstanceSize Small -ImageName $img
+
+$vmObj1 = Add-AzureProvisioningConfig -VM $vmObj1 -Password $password -Linux -LinuxUser $username
+
+# set azure chef extension
+$vmObj1 = Set-AzureVMChefExtension -VM $vmObj1 -ValidationPem "C:\\users\\azure\\msazurechef-validator.pem" -ClientRb
+"C:\\users\\azure\\client.rb" -RunList "getting-started" -Linux
+
+New-AzureVM -Location 'West US' -ServiceName $svc -VM $vmObj1
+```
diff --git a/content/chef_client_overview.md b/content/chef_client_overview.md
new file mode 100644
index 0000000..3d2bdee
--- /dev/null
+++ b/content/chef_client_overview.md
@@ -0,0 +1,89 @@
++++
+title = "Chef Infra Client Overview"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+aliases = ["/chef_client_overview.html", "/chef_client.html", "/essentials_nodes_chef_run.html"]
+
+[menu]
+ [menu.infra]
+ title = "Chef Infra Client Overview"
+ identifier = "chef_infra/overview/chef_client_overview.md Chef Infra Client Overview"
+ parent = "chef_infra/overview"
+ weight = 20
++++
+
+Chef Infra Client is an agent that runs locally on every node that's under management by Chef Infra Server.
+Chef Infra Client transforms your infrastructure into code by automatically configuring systems to match your desired state.
+
+When Chef Infra Client runs, it performs all the steps required to bring a node into the expected state, including:
+
+- Registering and authenticating the node with Chef Infra Server
+- Synchronizing cookbooks from Chef Infra Server to the node
+- Compiling the resource collection by loading each of the required cookbooks, including recipes, attributes, and all other dependencies
+- Taking the appropriate and required actions to configure the node based on recipes and attributes
+- Reporting summary information on the run to Chef Automate
+
+## Chef Infra Client components
+
+Chef Infra Client works with key components to manage your infrastructure:
+
+### Compliance Phase
+
+The Compliance Phase is an integrated security and compliance feature that runs Chef InSpec profiles automatically as part of every Chef Infra Client run.
+This phase allows you to continuously audit your infrastructure for compliance with security policies and regulatory requirements without managing separate tools or processes.
+
+For detailed information, see [About the Compliance Phase](/chef_compliance_phase/).
+
+### Node
+
+A node represents any system that Chef Infra Client manages - whether it's a virtual machine, container instance, or physical server.
+Every node runs Chef Infra Client and maintains its configuration state according to the policies you define.
+
+### Cookbooks and recipes
+
+Cookbooks contain the instructions (recipes) that tell Chef Infra Client how to configure your systems.
+Recipes use resources to describe the desired state of system components like packages, files, and services.
+
+### Run list
+
+The run list defines which cookbooks and recipes Chef Infra Client should execute on a node and in what order.
+You can customize run lists for different node types or environments.
+
+### Ohai
+
+Ohai is a system profiling tool that collects detailed information about your nodes, including hardware details, network configuration, and operating system data.
+Chef Infra Client uses this information to make intelligent configuration decisions.
+
+## How Chef Infra Client works
+
+Chef Infra Client operates on a pull-based model where nodes periodically contact Chef Infra Server to retrieve their configuration policies.
+This approach ensures that your infrastructure remains in the desired state even if individual nodes experience temporary disconnections or issues.
+
+## Common use cases
+
+You can use Chef Infra Client to automate infrastructure management tasks:
+
+- **Server provisioning**: Automatically configure new servers with required software and settings
+- **Application deployment**: Deploy and configure applications across different environments
+- **Security compliance**: Enforce security policies and compliance requirements
+- **Configuration drift prevention**: Continuously check and correct configuration changes
+- **Environment management**: Maintain consistent configurations across development, staging, and production environments
+
+## The Chef Infra Client run
+
+{{< readfile file="content/reusable/md/chef_client_run.md" >}}
+
+## Related content
+
+- [Chef Infra Client (executable)](/ctl_chef_client/)
+- [Chef Infra Server](/server/)
+- [Cookbooks](/cookbooks/)
+- [Nodes](/nodes/)
+- [Run Lists](/run_lists/)
+
+## Next steps
+
+- [Install Chef Workstation](/workstation/install_workstation/)
+- [Bootstrap Nodes](/install_bootstrap/)
diff --git a/content/chef_client_security.md b/content/chef_client_security.md
new file mode 100644
index 0000000..004500c
--- /dev/null
+++ b/content/chef_client_security.md
@@ -0,0 +1,145 @@
++++
+title = "Chef Infra Client security"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+aliases = ["/chef_client_security.html", "/auth.html"]
+
+[menu]
+ [menu.infra]
+ title = "Chef Infra Client security"
+ identifier = "chef_infra/security/chef_client_security.md Security"
+ parent = "chef_infra/security"
+ weight = 10
++++
+
+
+{{< readfile file="content/server/reusable/md/chef_auth.md" >}}
+
+## Authentication
+
+{{< readfile file="content/server/reusable/md/chef_auth_authentication.md" >}}
+
+### chef-validator
+
+{{< readfile file="content/reusable/md/security_chef_validator.md" >}}
+
+{{< readfile file="content/reusable/md/security_chef_validator_context.md" >}}
+
+## SSL certificates
+
+{{< readfile file="content/server/reusable/md/server_security_ssl_cert_client.md" >}}
+
+### trusted_certs directory
+
+You can use use a private certificate authority (CA) to generate SSL certificates or they may create self-signed SSL certificates to use on internal networks or during software development and testing.
+
+The `trusted_certs` directory on Chef Workstation and in Chef Infra Client works as a trusted certificate store for all communication in the Chef Infra system. Chef Infra trusts all SSL certificates stored in this directory---including certificates that aren't issued by a trusted certificate authority (CA).
+
+Place private and self-signed certificates in the `trusted_certs` directory to use them within Chef Infra Client and Workstation tools.
+
+Use the [`chef_client_trusted_certificate`]({{< relref "/resources/chef_client_trusted_certificate" >}}) Chef Infra Client resource to manage these certificates continuously.
+
+#### trusted_certs directory locations
+
+##### Chef Workstation
+
+When you install Chef Workstation, it creates a `trusted_certs` directory located at:.
+
+- Windows: `C:\.chef\trusted_certs`
+- All other systems: `~/.chef/trusted_certs`
+
+##### Chef Infra Client nodes
+
+When you bootstrap a node, the Chef Infra Client copies the SSL certificates for the Chef Infra Server onto the node. The `trusted_certs` directory on the node is located at:
+
+- Windows: `C:\chef\trusted_certs`
+- All other systems: `/etc/chef/trusted_certs`
+
+### SSL_CERT_FILE
+
+Use the `SSL_CERT_FILE` environment variable to specify the location for the SSL certificate authority (CA) bundle for Chef Infra Client.
+
+A value for `SSL_CERT_FILE` isn't set by default. Unless updated, the locations in which Chef Infra will look for SSL certificates are:
+
+- Chef Infra Client: `/opt/chef/embedded/ssl/certs/cacert.pem`
+- Chef Workstation: `/opt/chef-workstation/embedded/ssl/certs/cacert.pem`
+
+To use a custom CA bundle, update the environment variable to specify the path to the custom CA bundle. The first step to troubleshoot a failing SSL certificate is to verify the location of the `SSL_CERT_FILE`.
+
+### client.rb file settings
+
+
+
+Use following [`client.rb` file]({{< relref "config_rb_client" >}}) settings to manage SSL certificate preferences:
+
+`local_key_generation`
+: Whether the Chef Infra Server or Chef Infra Client generates the private/public key pair.
+ When `true`, Chef Infra Client generates the key pair and then sends the public key to the Chef Infra Server.
+
+ Default value: `true`.
+
+`ssl_ca_file`
+: The file for the OpenSSL key. Chef Infra Client generates this setting automatically.
+
+`ssl_ca_path`
+: The location of the OpenSSL key file. Chef Infra Client generates this setting automatically.
+
+`ssl_client_cert`
+: The OpenSSL X.509 certificate for mutual certificate validation. Required for mutual certificate validation on the Chef Infra Server.
+
+ Default value: `nil`.
+
+`ssl_client_key`
+: The OpenSSL X.509 key used for mutual certificate validation. Required for mutual certificate validation on the Chef Infra Server.
+
+ Default value: `nil`.
+
+`ssl_verify_mode`
+: Set the verification mode for HTTPS requests. The recommended setting is `:verify_peer`. Depending on your OpenSSL configuration, you may need to set the `ssl_ca_path`.
+
+ Allowed values:
+
+ - Use `:verify_none` to run without validating any SSL certificates.
+ - Use `:verify_peer` to validate all SSL certificates, including the Chef Infra Server connections, S3 connections, and any HTTPS `remote_file` resource URLs used in a Chef Infra Client run.
+
+ Default value: `:verify_peer`.
+
+`verify_api_cert`
+: Verify the SSL certificate on the Chef Infra Server.
+
+ If `true`, Chef Infra Client always verifies the SSL certificate. If `false`, Chef Infra Client uses `ssl_verify_mode` to determine if the SSL certificate requires verification.
+
+ Default value: `false`.
+
+
+
+### knife CLI subcommands
+
+The Chef Infra Client includes two knife commands for managing SSL certificates:
+
+- Use [knife ssl check](/workstation/knife_ssl_check/) to troubleshoot SSL certificate issues.
+- Use [knife ssl fetch](/workstation/knife_ssl_fetch/) to pull down a certificate from the Chef Infra Server to the `/.chef/trusted_certs` directory on the workstation.
+
+After the workstation has the correct SSL certificate, bootstrap operations from that workstation uses the certificate in the `/.chef/trusted_certs` directory during the bootstrap operation.
+
+#### knife ssl check
+
+Run [`knife ssl check`]({{< relref "/workstation/knife_ssl_check/" >}}) to verify the state of the SSL certificate, and then use the response to help troubleshoot any issues.
+
+##### Verified
+
+{{< readfile file="content/workstation/reusable/md/knife_ssl_check_verify_server_config.md" >}}
+
+##### Unverified
+
+{{< readfile file="content/workstation/reusable/md/knife_ssl_check_bad_ssl_certificate.md" >}}
+
+#### knife ssl fetch
+
+Run [`knife ssl fetch`]({{< relref "/workstation/knife_ssl_fetch/" >}}) to download the self-signed certificate from the Chef Infra Server to the `/.chef/trusted_certs` directory on a workstation.
+
+##### Verify checksums
+
+{{< readfile file="content/workstation/reusable/md/knife_ssl_fetch_verify_certificate.md" >}}
diff --git a/content/chef_compliance_phase.md b/content/chef_compliance_phase.md
new file mode 100644
index 0000000..212285a
--- /dev/null
+++ b/content/chef_compliance_phase.md
@@ -0,0 +1,668 @@
++++
+title = "About the Compliance Phase"
+draft = false
+gh_repo = "chef-web-docs"
+
+[menu]
+ [menu.infra]
+ title = "Compliance Phase"
+ identifier = "chef_infra/features/chef_compliance_phase.md Compliance Phase"
+ parent = "chef_infra/features"
+ weight = 15
+
++++
+
+
+Chef Infra Client's Compliance Phase lets you automatically execute compliance audits and view the results as part of any Chef Infra Client run. The Compliance Phase of the Chef Infra Client run replaces the legacy [audit cookbook](https://supermarket.chef.io/cookbooks/audit) and works with your existing audit cookbook attributes, and you can also set it up for new cookbooks. This additional phase gives you the latest compliance capabilities without having to manage cookbook dependencies or juggle versions during Chef Infra Client updates.
+
+Existing audit cookbook users can migrate to the new Compliance Phase by removing the audit cookbook from their run_list and setting the `node['audit']['compliance_phase']` attribute to `true`.
+
+The Compliance Phase replaces the `audit cookbook` by integrating Chef InSpec compliance checks into the [Chef Infra Client run]({{< relref "chef_client_overview.md" >}})
+The Compliance Phase is designed to run on any node in your system that's set up--or [bootstrapped]({{< relref "install_bootstrap" >}})--for a `chef-client` run.
+
+**New in Chef Infra Client 17.8**
+
+Once turned on, the Compliance Phase always outputs its results in the CLI on manual runs. The output for automated runs is handled by [reporters]({{< relref "#reporters" >}}).
+
+## Upgrade to Compliance Phase from Audit Cookbook
+
+The Compliance Phase requires Chef Infra Client 17 or higher.
+
+If your system is configured to use the `audit cookbook`, make these changes to switch to the Compliance Phase:
+
+1. Set the `node['audit']['compliance_phase']` attribute to `true` through a Policyfile or cookbook attributes file.
+1. Remove the `audit cookbook` from your [run-list]({{< relref "run_lists.md" >}}).
+
+1. On your next Chef Infra Client run, you should see the Compliance Phase results.
+
+## Set up the Compliance Phase in new Cookbooks
+
+### Turn on the Compliance Phase
+
+Turn on the Compliance Phase by setting the `node['audit']['compliance_phase']` attribute to `true` through cookbook attributes or Policyfiles. To turn on Compliance Phase using cookbook attributes add the following line to the `attributes/default.rb` file in your cookbook.
+
+```ruby
+default['audit']['compliance_phase'] = true
+```
+
+### Set Chef InSpec Profiles
+
+Setting one or more Chef InSpec profiles turns on the Compliance Phase in a Chef Infra Client run. The presence of this configuration in your attributes file instructs Chef Infra Client to fetch and execute the specific Chef InSpec profiles and write the results to disk using the default `cli` and `json-file` reporters.
+
+Retrieve [Chef InSpec profiles]({{< relref "inspec/profiles/" >}}) from Chef Automate, Supermarket, a local file, GitHub, or over HTTP with the `node['audit']['profiles']` attribute.
+
+The following examples:
+
+- Retrieve profiles from Chef Automate, Supermarket, a local file, GitHub, or over HTTP.
+- Display the results on the command line using the default `cli` reporter.
+- Write the results to disk using the default `json-file` reporter to `/compliance_reports/compliance-.json`.
+
+
+
+{{< foundation_tabs tabs-id="compliance-phase-profile-panel" >}}
+ {{< foundation_tab active="true" panel-link="automate-panel" tab-text="Automate">}}
+ {{< foundation_tab panel-link="supermarket-panel" tab-text="Supermarket" >}}
+ {{< foundation_tab panel-link="local-path-panel" tab-text="File" >}}
+ {{< foundation_tab panel-link="git-panel" tab-text="GitHub" >}}
+ {{< foundation_tab panel-link="http-panel" tab-text="HTTP" >}}
+{{< /foundation_tabs >}}
+{{< foundation_tabs_panels tabs-id="compliance-phase-profile-panel" >}}
+ {{< foundation_tabs_panel active="true" panel-id="automate-panel" >}}
+ ```ruby
+ # Invoke the Compliance Phase
+ default['audit']['compliance_phase'] = true
+ # Set profile locations
+ default['audit']['profiles']['linux-baseline'] = {
+ 'compliance': 'user/linux-baseline',
+ 'version': '2.1.0'
+ }
+ ```
+ {{< warning >}}
+ Fetching profiles from Chef Automate requires setting `data_collector.server_url` and `data_collector.token` in your `client.rb` to fetch profiles from Chef Automate. This configuration is described in more detail in the Chef Automate [data collector documentation]({{< relref "automate/data_collection/" >}}).
+ {{< /warning >}}
+ {{< /foundation_tabs_panel >}}
+ {{< foundation_tabs_panel panel-id="supermarket-panel" >}}
+ ```ruby
+ # Invoke the Compliance Phase
+ default['audit']['compliance_phase'] = true
+ # Set profile locations
+ default['audit']['profiles']['ssh'] = {
+ 'supermarket': 'hardening/ssh-hardening'
+ }
+ ```
+ {{< /foundation_tabs_panel >}}
+ {{< foundation_tabs_panel panel-id="local-path-panel" >}}
+ ```ruby
+ # Invoke the Compliance Phase
+ default['audit']['compliance_phase'] = true
+ # Set profile locations
+ default['audit']['profiles']['4thcafe/win2012_audit'] = {
+ 'path': 'E:/profiles/win2012_audit'
+ }
+ ```
+ {{< /foundation_tabs_panel >}}
+ {{< foundation_tabs_panel panel-id="git-panel" >}}
+ ```ruby
+ # Invoke the Compliance Phase
+ default['audit']['compliance_phase'] = true
+ # Set profile locations
+ default['audit']['profiles']['ssl'] = {
+ 'git': 'https://github.com/dev-sec/ssl-benchmark.git'
+ }
+ ```
+ {{< /foundation_tabs_panel >}}
+ {{< foundation_tabs_panel panel-id="http-panel" >}}
+ ```ruby
+ # Invoke the Compliance Phase
+ default['audit']['compliance_phase'] = true
+ # Set profile locations
+ default['audit']['profiles']['ssh2'] = {
+ 'url': 'https://github.com/dev-sec/tests-ssh-hardening/archive/master.zip'
+ }
+ ```
+ {{< /foundation_tabs_panel >}}
+{{< /foundation_tabs_panels >}}
+
+
+
+### Fetch Profiles
+
+Set the fetcher attribute with `default['audit']['fetcher']` to retrieve Chef InSpec compliance profiles from either Chef Automate or Chef Infra Server in addition to the location defined by `default ['audit']['profile']`. Left unset, the Compliance Phase defaults to the [fetchers included in Chef InSpec]({{< relref "/inspec/profiles#profile-dependencies" >}}). Chef Infra and Chef InSpec fetchers are mutually exclusive so, you can only use one of these configurations.
+
+The following examples:
+
+- Retrieve the 'ssh' profile from Chef Supermarket.
+- Fetch additional profiles from Chef Automate or Chef Infra Server.
+- Display the results on the command line using the default `cli` reporter.
+- Write the results to disk using the default `json-file` reporter to `/compliance_reports/compliance-.json`.
+
+
+
+{{< foundation_tabs tabs-id="compliance-phase-fetcher-panel" >}}
+ {{< foundation_tab active="true" panel-link="automate-fetcher" tab-text="Automate">}}
+ {{< foundation_tab panel-link="server-fetcher" tab-text="Infra Server" >}}
+{{< /foundation_tabs >}}
+{{< foundation_tabs_panels tabs-id="compliance-phase-fetcher-panel" >}}
+ {{< foundation_tabs_panel active="true" panel-id="automate-fetcher" >}}
+ ```ruby
+ # Invoke the Compliance Phase
+ default['audit']['compliance_phase'] = true
+ # Set profile location
+ default['audit']['profiles']['ssh'] = {
+ 'supermarket': 'hardening/ssh-hardening'
+ }
+ # Fetch additional profiles
+ default['audit']['fetcher'] = 'chef-automate'
+ ```
+ {{< warning >}}
+ Fetching profiles from Chef Automate requires setting `data_collector.server_url` and `data_collector.token` in your `client.rb` to fetch profiles from Chef Automate. This configuration is described in more detail in the Chef Automate [data collector documentation]({{< relref "automate/data_collection/" >}}).
+ {{< /warning >}}
+ {{< /foundation_tabs_panel >}}
+ {{< foundation_tabs_panel panel-id="server-fetcher" >}}
+ ```ruby
+ # Invoke the Compliance Phase
+ default['audit']['compliance_phase'] = true
+ # Set profile location
+ default['audit']['profiles']['ssh'] = {
+ 'supermarket': 'hardening/ssh-hardening'
+ }
+ # Fetch additional profiles
+ default['audit']['fetcher'] = 'chef-server'
+ ```
+ {{< /foundation_tabs_panel >}}
+{{< /foundation_tabs_panels >}}
+
+
+
+### Reporters
+
+Reporters control what's done with the resulting report after the Chef InSpec run. Either a single value or a list of multiple values is supported. The default is the `cli` and `json-file` reporters.
+
+Reporters can send Compliance Phase results to:
+
+- Chef Automate proxied by Chef Infra Server.
+- Directly to Chef Automate (requires additional authentication).
+- The terminal if Chef Infra Client is run interactively by a user.
+- A file on disk.
+
+The following examples:
+
+- Retrieve the 'ssh' profile from Chef Supermarket
+- Fetch additional profiles from Chef Automate
+- Send the results to Chef Automate, Chef Automate proxied by Chef Infra Server, or to a file on disk.
+
+
+
+{{< foundation_tabs tabs-id="compliance-phase-reporter-panel" >}}
+ {{< foundation_tab active="true" panel-link="automate-reporter" tab-text="Automate">}}
+ {{< foundation_tab panel-link="server-reporter" tab-text="Automate using Infra Server" >}}
+ {{< foundation_tab panel-link="local-reporter" tab-text="File" >}}
+{{< /foundation_tabs >}}
+{{< foundation_tabs_panels tabs-id="compliance-phase-reporter-panel" >}}
+ {{< foundation_tabs_panel active="true" panel-id="automate-reporter" >}}
+ ```ruby
+ # Invoke the Compliance Phase
+ default['audit']['compliance_phase'] = true
+ # Set profile location
+ default['audit']['profiles']['ssh'] = {
+ 'supermarket': 'hardening/ssh-hardening'
+ }
+ # Fetch additional profiles
+ default['audit']['fetcher'] = 'chef-automate'
+ # Set reporter
+ default['audit']['reporter'] = 'chef-automate'
+ ```
+ {{< warning >}}
+ Reporting Compliance Phase results directly to Chef Automate requires setting `data_collector.server_url` and `data_collector.token` in your `client.rb` to fetch profiles from Chef Automate. This configuration is described in more detail in the Chef Automate [data collector documentation]({{< relref "automate/data_collection/" >}}).
+ {{< /warning >}}
+ {{< /foundation_tabs_panel >}}
+ {{< foundation_tabs_panel panel-id="server-reporter" >}}
+ ```ruby
+ # Invoke the Compliance Phase
+ default['audit']['compliance_phase'] = true
+ # Set profile location
+ default['audit']['profiles']['ssh'] = {
+ 'supermarket': 'hardening/ssh-hardening'
+ }
+ # Fetch additional profiles
+ default['audit']['fetcher'] = 'chef-server'
+ # Set reporter
+ default['audit']['reporter'] = 'chef-server-automate'
+ ```
+
+ {{< /foundation_tabs_panel >}}
+ {{< foundation_tabs_panel panel-id="local-reporter" >}}
+ ```ruby
+ # Invoke the Compliance Phase
+ default['audit']['compliance_phase'] = true
+ # Set profile location
+ default['audit']['profiles']['ssh'] = {
+ 'supermarket': 'hardening/ssh-hardening'
+ }
+ # Fetch additional profiles
+ default['audit']['fetcher'] = 'chef-automate'
+ # Set two reporters
+ default['audit']['reporter'] = 'json-file', 'cli'
+ # Set the location of the json-file output
+ # Note that the location attribute uses json_file
+ default['audit']['json_file']['location'] = '/file/path/report.json'
+ ```
+
+ The default `json-file` path is: `/compliance_reports/compliance-.json`.
+
+ The path will also be output to the Chef Infra Client log:
+
+ ```bash
+ ['2017-08-29T00:22:10+00:00'] INFO: Reporting to json-file
+ ['2017-08-29T00:22:10+00:00'] INFO: Writing report to /opt/kitchen/cache/compliance-reports/compliance-20170829002210.json
+ ['2017-08-29T00:22:10+00:00'] INFO: Report handlers complete
+ ```
+
+ {{< /foundation_tabs_panel >}}
+{{< /foundation_tabs_panels >}}
+
+
+
+## Customize Profiles
+
+You can upload profiles to Chef Automate using the [Chef Automate API](/automate/api/#operation/Create) or the `inspec compliance` command.
+
+### Waivers
+
+Use [waivers]({{< relref "/inspec/waivers" >}}) to mark individual failing controls as administratively accepted, either on a temporary or permanent basis.
+
+To use waivers:
+
+1. Prepare a YAML waiver file.
+1. Deliver the waiver file to the node in a [cookbook_file]({{< relref "/resources/cookbook_file" >}}) or [remote_file]({{< relref "/resources/remote_file" >}}).
+1. Set the `waiver_file` attribute for the Compliance Phase to that location. For example:
+
+```ruby
+default['audit']['waiver_file'] = "waivers.yaml"
+```
+
+### External Data
+
+Chef InSpec profiles should be self-contained and independent from external data. Sometimes, a profile's test may exhibit different behavior depending on aspects of the node being tested and in these cases, you may want to use external data. Chef InSpec profiles accept [inputs]({{< relref "/inspec/inputs" >}}) that let you customize the test.
+
+#### Chef InSpec Input
+
+You can pass [Chef InSpec inputs]({{< relref "/inspec/inputs" >}}) to the Chef InSpec runner. Chef InSpec inputs were previously called `attributes` and you will set them in an `['audit']['attributes']` hash in your attributes file.
+Any data added to `['audit']['attributes']` as a hash is passed to Chef InSpec as individual attributes.
+
+ ```ruby
+ default['audit']['attributes'] = {
+ first_input: 'some value',
+ second_input: 'another value',
+ }
+ ```
+
+#### Chef Node Data
+
+There are two primary ways to pass Chef Infra node data to Chef InSpec run during the Compliance Phase.
+
+##### Explicitly pass necessary data (recommended)
+
+Any data added to the `node['audit']['attributes']` hash will be passed as individual Chef InSpec attributes. This provides a clean interface between the Chef Infra client run and Chef InSpec profile, allowing for easy assignment of default values in the Chef InSpec profile. This method is especially recommended if the Chef InSpec profile is expected to be used outside of the context of Compliance Phase so it's made explicit to profile consumers what attributes are necessary. Set the attributes in your cookbook attributes file and then use them in your Chef InSpec profile.
+
+Set the attributes in a cookbook attributes file:
+
+```ruby
+node['audit']['attributes']{
+ 'key1' = 'value1',
+ 'debug_enabled' = node['my_cookbook']['debug_enabled'],
+ 'environment' = node.chef_environment
+}
+```
+
+Use the attributes in a Chef InSpec profile:
+
+```ruby
+environment = attribute('environment', description: 'The Chef Infra environment for the node', default: 'dev')
+
+control 'debug-disabled-in-production' do
+ title 'Debug logs disabled in production'
+ desc 'Debug logs contain potentially sensitive information and shouldn't be on in production.'
+ impact 1.0
+
+ describe file('/path/to/my/app/config') do
+ its('content') { should_not include "debug=true" }
+ end
+
+ only_if { environment == 'production' }
+end
+```
+
+#### Use the Chef Infra Node Object
+
+Compliance Phase can be configured to pass the Chef Infra node object as a Chef InSpec attribute named `chef_node`.
+
+While using the `chef_node` object provides the ability to write more flexible profiles, it's difficult to reuse these profiles outside of the Compliance Phase. To reuse these profiles, you will need to understand how to pass in a single attribute containing Chef Infra-like data. Pass external data explicitly whenever possible.
+
+To use this option, first set it in a wrapper cookbook:
+
+```ruby
+node.override['audit']['chef_node_attribute_enabled'] = true
+```
+
+And then use it in your profile:
+
+```ruby
+chef_node = attribute('chef_node', description: 'Chef Node')
+
+control 'no-password-auth-in-prod' do
+ title 'No Password Authentication in Production'
+ desc 'Password authentication is allowed in all environments except production'
+ impact 1.0
+
+ describe sshd_config do
+ its('PasswordAuthentication') { should cmp 'No' }
+ end
+
+ only_if { chef_node['chef_environment'] == 'production' }
+end
+```
+
+## Useful Compliance Phase Attributes
+
+### audit-enforcer
+
+A special reporter that causes the compliance run to raise an error and immediately terminates the Chef Infra Client run if any control of any Chef InSpec profile fails. If you specify multiple reporters, place the `audit-enforcer` at the end of the list, allowing the other reporters to generate their output before run termination. Example:
+
+```ruby
+# fail on error
+default['audit']['reporter'] = 'audit-enforcer'.
+```
+
+### chef_node_attribute_enabled
+
+If set, a hash representation of the Chef Infra node object will be sent to an input named `chef_node`. Default: false
+
+```ruby
+# send a hash representation of the Chef Infra node object
+default['audit']['chef_node_attribute_enabled'] = true
+```
+
+### compliance_phase
+
+Turn on the built-in Compliance Phase run. Possible values: true, false, nil
+
+```ruby
+# Turn on Compliance Phase
+default['audit']['compliance_phase] = true
+```
+
+### control_results_limit
+
+The list of results for each control will be truncated to this amount to reduce the size of reports. A summary of removed results will be sent with each impacted control. Defaults to `50`.
+
+```ruby
+# allow 100 results
+ default['audit']['control_results_limit'] = 100
+```
+
+### fetcher
+
+Controls the location for additional profile locations for Chef InSpec profiles default fetch locations provided through the `[audit][profiles]` attribute. Accepted values: nil, 'chef-server', 'chef-automate'.
+
+```ruby
+# fetch additional profiles from Chef Server
+default[audit][fetcher] = 'chef-server'
+```
+
+### insecure
+
+Setting the attribute `default['audit']['insecure']` to `true` will skip SSL certificate verification for the `chef-automate` and `chef-server-automate` reporters. This allows connections to HTTPS endpoints with self-signed ssl certificates. Default is `false`
+
+```ruby
+# allow self-signed certificates
+default['audit']['insecure'] = true
+```
+
+### interval
+
+**New in Chef Infra Client 17.8**
+
+You can control the frequency of Compliance Phase scans with the `default['audit']['interval']`, which means that control the frequency that the Compliance Phase runs with a Chef Infra Client run. This helps you control the impact of compliance scans on system performance in business environments that require compliance scans less frequently than Chef Infra Client Runs.
+
+`default['audit']['interval']['enabled']`
+: Set to true to turn on interval runs.
+
+ ```ruby
+ # Set independent Compliance Phase scans
+ default['audit']['interval']['enabled'] = true
+ ```
+
+`default['audit']['interval']['time']`
+: The time in minutes between Compliance Phase execution. Default: 1440 (once a day).
+
+ ```ruby
+ # Define the timing of independent Compliance Phase scans
+ # Sets scan to twice daily
+ default['audit']['interval']['time'] = 1220
+ ```
+
+### json_file
+
+The location on disk that Chef InSpec's json reports are saved to when using the 'json-file' reporter. Defaults to: `/compliance_reports/compliance-.json`
+
+```ruby
+default['audit']['reporter'] = 'json-file'
+default['audit']['json_file']['location'] = '/path/to/file.json'
+```
+
+### inspec_backend_cache
+
+Chef InSpec caches the results of commands executed on the node during the Compliance Phase. Caching improves the Compliance Phase performance when slower-running commands are executed multiple times during a Chef Infra Client run. Disable this feature if your Chef InSpec profile runs a command multiple times expecting different output during the run. Default: true. Example:
+
+```ruby
+# Disable caching of commands
+default['audit']['inspec_backend_cache'] = false
+```
+
+### profiles
+
+Chef InSpec Compliance profiles to be used for scanning nodes.
+
+```ruby
+# use the ssh-hardening profile from Supermarket
+default['audit']['profiles']['ssh'] = {
+ 'supermarket': 'hardening/ssh-hardening'
+ }
+```
+
+### quiet
+
+Starting in Chef Infra Client 18.7, use `quiet` to suppress output of the Chef InSpec runner. Defaults to `false`.
+
+To suppress InSpec runner output, set to `true`:
+
+```ruby
+# verbose
+default['audit']['quiet'] = true
+```
+
+### reporter
+
+Controls what's done with the resulting report after the Chef InSpec run. Accepts a single string value or an array of multiple values. The 'cli' reporter mimics the Chef InSpec command line output in your terminal, which lets you see your system's compliance status at the end of the Compliance Phase. Accepted values: 'chef-server-automate', 'chef-automate', 'json-file', 'audit-enforcer', 'cli'
+
+```ruby
+# set the reporter to Chef Automate
+default['audit']['reporter'] = 'chef-automate', 'cli'
+```
+
+### run_time_limit
+
+Control results that have a `run_time` below this limit will be stripped of the `start_time` and `run_time` fields to reduce the size of reports. Defaults to `1.0`. Set this attribute with `default['audit']['run_time_limit']`.
+
+```ruby
+# allow 5 minutes run time
+default['audit']['run_time_limit'] = 5.0
+```
+
+### result_include_backtrace
+
+When a Chef InSpec resource throws an exception, results contain a short error message and a detailed ruby stacktrace of the error. Default: false (doesn't send backtrace). Example:
+
+```ruby
+# include backtrace
+default['audit']['result_include_backtrace'] = true
+```
+
+### result_message_limit
+
+Truncates any control result messages exceeding this character limit. Chef Automate has a 4 MB report size limit and can't ingest reports exceeding this limitation. Chef InSpec will append this text at the end of any truncated messages: `[Truncated to 10000 characters]` Default: 10000.
+
+```ruby
+default['audit']['result_message_limit] = 10000
+```
+
+### server
+
+When reporting to a Chef Automate instance proxied over Chef Infra Server, the Compliance Phase can be configured to use a different URL than the `chef_server_url` configured in `client.rb`. Turn on with the attribute `default['audit']['server']`.
+
+```ruby
+default['audit']['server'] = 'https://server.4thcafe.com'.
+```
+
+### waiver_file
+
+A string path or an array of paths to Chef InSpec waiver files.
+
+```ruby
+default['audit']['waiver_file'] = 'path/to/waiver.yml'.
+```
+
+## Errors and Troubleshooting
+
+### Cache Results
+
+Chef InSpec caches the results of commands executed on the node during the Compliance Phase. Caching improves the Compliance Phase performance when slower-running commands are executed multiple times during a Chef Infra Client run. Disable this feature if your Chef InSpec profile runs a command multiple times expecting different output during the run. Default: true. Example:
+
+```ruby
+# Disable caching of commands
+default['audit']['inspec_backend_cache'] = false
+```
+
+### Chef InSpec Report Size Limits
+
+The size of the report being generated from running the Compliance Phase is influenced by a few factors like:
+
+- number of controls and tests in a profile
+- number of profile failures for the node
+- controls metadata (title, description, tags, etc)
+- number of resources (users, processes, etc) that are being tested
+
+Depending on your setup, there are some limits you need to be aware of. A common one is Chef Infra Server default (1MB) request size. Exceeding this limit will reject the report with `ERROR: 413 "Request Entity Too Large"`. For more details about these limits, please refer to [the documentation on troubleshooting 413 errors](#413-request-entity-too-large).
+
+### HTTP Errors
+
+#### 401, 403 Unauthorized - bad clock
+
+Occasionally, the system date/time will drift between client and server. If this drift is greater than a couple of minutes, the Chef Infra Server will throw a 401 unauthorized and the request won't be forwarded to the Chef Automate server.
+
+On the Chef Infra Server you can see this in the following logs:
+
+```text
+# chef-server-ctl tail
+
+==> /var/log/opscode/nginx/access.log <==
+192.168.200.102 - - ['28/Aug/2016:14:57:36 +0000'] "GET /organizations/4thcafe/nodes/vagrant-c0971990 HTTP/1.1" 401 "0.004" 93 "-" "Chef Infra Client/12.14.38 (ruby-2.3.1-p112; ohai-8.19.2; x86_64-linux; +https://chef.io)" "127.0.0.1:8000" "401" "0.003" "12.14.38" "algorithm=sha1;version=1.1;" "vagrant-c0971990" "2013-09-25T15:00:14Z" "2jmj7l5rSw0yVb/vlWAYkK/YBwk=" 1060
+
+==> /var/log/opscode/opscode-erchef/crash.log <==
+2016-08-28 14:57:36 =ERROR REPORT====
+{<<"method=GET; path=/organizations/4thcafe/nodes/vagrant-c0971990; status=401; ">>,"Unauthorized"}
+
+==> /var/log/opscode/opscode-erchef/erchef.log <==
+2016-08-28 14:57:36.521 ['error'] {<<"method=GET; path=/organizations/4thcafe/nodes/vagrant-c0971990; status=401; ">>,"Unauthorized"}
+
+==> /var/log/opscode/opscode-erchef/current <==
+2016-08-28_14:57:36.52659 ['error'] {<<"method=GET; path=/organizations/4thcafe/nodes/vagrant-c0971990; status=401; ">>,"Unauthorized"}
+
+==> /var/log/opscode/opscode-erchef/requests.log.1 <==
+2016-08-28T14:57:36Z erchef@127.0.0.1 method=GET; path=/organizations/4thcafe/nodes/vagrant-c0971990; status=401; req_id=g3IAA2QAEGVyY2hlZkAxMjcuMC4wLjEBAAOFrgAAAAAAAAAA; org_name=4thcafe; msg=bad_clock; couchdb_groups=false; couchdb_organizations=false; couchdb_containers=false; couchdb_acls=false; 503_mode=false; couchdb_associations=false; couchdb_association_requests=false; req_time=1; user=vagrant-c0971990; req_api_version=1;
+```
+
+Additionally, the chef_gate log will contain a similar message:
+
+```text
+# /var/log/opscode/chef_gate/current
+2016-08-28_15:01:34.88702 ['GIN'] 2016/08/28 - 15:01:34 | 401 | 13.650403ms | 192.168.200.102 | POST /compliance/organizations/4thcafe/inspec
+2016-08-28_15:01:34.88704 Error #01: Authentication failed. Please check your system's clock.
+```
+
+#### 401 Token and Refresh Token Authentication
+
+In the event of a malformed or unset token, the Chef Automate server will log the token error:
+
+```text
+==> /var/log/chef-compliance/core/current <==
+2016-08-28_20:41:46.17496 20:41:46.174 ERR => Token authentication: %!(EXTRA *errors.errorString=malformed JWS, only 1 segments)
+2016-08-28_20:41:46.17498 ['GIN'] 2016/08/28 - 20:41:46 | 401 | 53.824us | 192.168.200.102 | GET /owners/base/compliance/linux/tar
+
+==> /var/log/chef-compliance/nginx/compliance.access.log <==
+192.168.200.102 - - ['28/Aug/2016:21:23:46 +0000'] "GET /api/owners/base/compliance/linux/tar HTTP/1.1" 401 0 "-" "Ruby"
+```
+
+#### 413 Request Entity Too Large
+
+This error indicates that you have exceeded limit the `erchef` request size in Chef Infra Server. The default for versions before 13.0 was 1MB. Starting with version 13.0 the default is 2MB.
+
+To resolve this error, set the `opscode_erchef['max_request_size']` in Chef Infra Server's `/etc/opscode/chef-server.rb` to a larger amount. This example sets the limit to 3MB:
+
+```ruby
+opscode_erchef['max_request_size'] = 3000000
+```
+
+Then run `chef-server-ctl reconfigure` to apply this change.
+
+##### 413 Error Logs
+
+The 413 "Request Entity Too Large" error appears in both the stacktrace and the Chef Infra Server Nginx logs.
+
+
+
+{{< foundation_tabs tabs-id="compliance-413-panel" >}}
+ {{< foundation_tab active="true" panel-link="413-stacktrace" tab-text="Stacktrace">}}
+ {{< foundation_tab panel-link="413-server-nginx" tab-text="Nginx logs" >}}
+{{< /foundation_tabs >}}
+{{< foundation_tabs_panels tabs-id="compliance-413-panel" >}}
+ {{< foundation_tabs_panel active="true" panel-id="413-stacktrace" >}}
+ The stacktrace shows the 413 error:
+ ```text
+ Running handlers:
+ ['2017-12-21T16:21:15+00:00'] WARN: Compliance report size is 1.71 MB.
+ ['2017-12-21T16:21:15+00:00'] ERROR: 413 "Request Entity Too Large" (Net::HTTPServerException)
+ /opt/chef/embedded/lib/ruby/2.4.0/net/http/response.rb:122:in `error!'
+ /opt/chef/embedded/lib/ruby/gems/2.4.0/gems/chef-13.6.4/lib/chef/http.rb:152:in `request'
+ /opt/chef/embedded/lib/ruby/gems/2.4.0/gems/chef-13.6.4/lib/chef/http.rb:131:in `post'
+ /var/chef/cache/cookbooks/audit/libraries/reporters/cs_automate.rb:37:in `block in send_report'
+ ...
+ ```
+ {{< /foundation_tabs_panel >}}
+ {{< foundation_tabs_panel panel-id="413-server-nginx" >}}
+ The Chef Infra Server Nginx log confirms the `413` error:
+ ```text
+ ==> /var/log/opscode/nginx/access.log <==
+ 192.168.56.40 - - ['21/Dec/2017:11:35:30 +0000'] "POST /organizations/eu_org/data-collector HTTP/1.1" 413 "0.803" 64 "-" "Chef Infra Client/13.6.4 (ruby-2.4.2-p198; ohai-13.6.0; x86_64-linux; +https://chef.io)" "-" "-" "-" "13.6.4" "algorithm=sha1;version=1.1;" "bootstrapped-node" "2017-12-21T11:35:31Z" "GR6RyPvKkZDaGyQDYCPfoQGS8G4=" 1793064
+ ```
+ {{< /foundation_tabs_panel >}}
+
+{{< /foundation_tabs_panels >}}
+
+
+
+## Troubleshooting
+
+Chef Automate sets the `logstash` limit to 10% of the system memory automatically as part of the `automate-ctl reconfigure` command execution. You have reached the java heap size(`-Xmx`) limit of `logstash` if a Chef InSpec report doesn't become available in Chef Automate and this error is in the `logstash` logs:
+
+```text
+/var/log/delivery/logstash/current
+2017-12-21_13:59:54.69949 DEBUG: Ruby filter is processing an 'inspec_profile' event
+2017-12-21_14:00:16.51553 java.lang.OutOfMemoryError: Java heap space
+2017-12-21_14:00:16.51556 Dumping heap to /opt/delivery/embedded/logstash/heapdump.hprof ...
+2017-12-21_14:00:16.51556 Unable to create /opt/delivery/embedded/logstash/heapdump.hprof: File exists
+2017-12-21_14:00:18.50676 Error: Your application used more memory than the safety cap of 383M.
+2017-12-21_14:00:18.50694 Specify -J-Xmx####m to increase it (#### = cap size in MB).
+2017-12-21_14:00:18.50703 Specify -w for full OutOfMemoryError stack trace
+```
diff --git a/content/chef_deprecations_client.md b/content/chef_deprecations_client.md
new file mode 100644
index 0000000..151329f
--- /dev/null
+++ b/content/chef_deprecations_client.md
@@ -0,0 +1,367 @@
++++
+title = "Chef Deprecation Warnings"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+aliases = ["/chef_deprecations_client.html"]
+
+[menu]
+ [menu.infra]
+ title = "Deprecations"
+ identifier = "chef_infra/reference/chef_deprecations_client.md Deprecations"
+ parent = "chef_infra/reference"
+ weight = 90
++++
+
+
+
+When we wish to remove a feature or an API in Chef, we try to first mark
+it with a deprecation warning that contains a link to a description of
+the change and how to fix it. For example:
+
+```ruby
+Deprecated features used!
+ JSON auto inflation isn't supported (CHEF-1) at (irb):7:in `irb_binding`.
+ Please see /chef-client/deprecations/json_auto_inflate.html for further details and information on how to correct this problem.
+```
+
+## Testing for Deprecations
+
+To test your code for deprecations, you can put Test Kitchen in a mode
+where any deprecations cause the chef run to fail. Ensure your
+`kitchen.yml` includes:
+
+```yaml
+provisioner:
+ deprecations_as_errors: true
+```
+
+and then run Test Kitchen as usual. Test Kitchen will fail if any
+deprecation errors are issued.
+
+## Silencing deprecation warnings
+
+Deprecation warnings are great for ensuring cookbooks are kept
+up-to-date and to prepare for major version upgrades, sometimes you just
+can't fix a deprecation right away. Enabling
+`treat_deprecation_warnings_as_errors` mode in Test Kitchen integration
+tests often compounds the problem because it doesn't distinguish
+between deprecations from community cookbooks and those in your own
+code.
+
+Two new options are provided for silencing deprecation warnings:
+`silence_deprecation_warnings` and inline `chef:silence_deprecation`
+comments.
+
+The `silence_deprecation_warnings` configuration value can be set in
+your `client.rb` or `solo.rb` config file, either to `true` to silence
+all deprecation warnings or to an array of deprecations to silence. You
+can specify which to silence either by the deprecation key name (for example,
+`"internal_api"`), the numeric deprecation ID (for example, `25` or "CHEF-25"), or by specifying the filename and
+line number where the deprecation is being raised from (for example,
+`"default.rb:67"`).
+
+An example of setting the `silence_deprecation_warnings` option in your
+`client.rb` or `solo.rb`:
+
+```ruby
+silence_deprecation_warnings %w{deploy_resource chef-23 recipes/install.rb:22}
+```
+
+or in your \`kitchen.yml\`:
+
+```yaml
+provisioner:
+ name: chef_solo
+ solo_rb:
+ treat_deprecation_warnings_as_errors: true
+ silence_deprecation_warnings:
+ - deploy_resource
+ - chef-23
+ - recipes/install.rb:22
+```
+
+You can also silence deprecations using a comment on the line that's
+raising the warning:
+
+```ruby
+erl_call 'something' do # chef:silence_deprecation
+```
+
+We advise caution in the use of this feature, as excessive or prolonged
+silencing can lead to difficulty upgrading when the next major release
+of Chef comes out.
+
+## All Deprecations
+
+
diff --git a/content/chef_install_script.md b/content/chef_install_script.md
new file mode 100644
index 0000000..e9c7309
--- /dev/null
+++ b/content/chef_install_script.md
@@ -0,0 +1,203 @@
++++
+title = "Chef Software install script"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/install_omnibus.html", "/install_omnibus/"]
+product = ["automate", "client", "server", "habitat", "inspec", "supermarket", "workstation"]
+
+[menu]
+ [menu.overview]
+ title = "Install script"
+ identifier = "overview/packages_&_platforms/Install Script"
+ parent = "overview/packages_&_platforms"
+ weight = 30
++++
+
+You can use the Chef Software install script to install
+any Chef software---including Chef Infra Client, Chef Infra Server, and Chef InSpec---on UNIX, Linux, and Windows platforms.
+
+This script does the following:
+
+- Detects the platform, version, and architecture of the machine on which the installer is being executed.
+- Fetches the appropriate package, for the requested product and version.
+- Validates the package content by comparing SHA-256 checksums.
+- Installs the package.
+
+## Install using the Commercial API
+
+Commercial users can use the install script from the [Chef Commercial API](/download/commercial/) to install Chef software.
+
+### Prerequisites
+
+You must have a license ID to use the install script from the Chef Commercial API. You can get your license ID from the [Chef Downloads portal](https://chef.io/downloads).
+
+### UNIX, Linux, and macOS
+
+Use the Chef install script to install packages on UNIX, Linux, and macOS systems:
+
+By default the script installs the latest version of Chef Infra Client:
+
+```bash
+curl -L https://chefdownload-commercial.chef.io/install.sh?license_id= | sudo bash
+```
+
+Replace `` with your license ID.
+
+Use the `-P` option to specify a Chef software application to install:
+
+```bash
+curl -L https://chefdownload-commercial.chef.io/install.sh?license_id= | sudo bash -s -- -P
+```
+
+Replace:
+
+- `` with your license ID
+- `` with the application you want to install
+
+For additional script install options, see the [script options](#script-options).
+
+### Windows
+
+On Windows systems, you can install Chef software using the Powershell install script.
+
+By default the script installs the latest version of Chef Infra Client:
+
+```powershell
+. { iwr -useb https://chefdownload-commercial.chef.io/install.ps1?license_id= } | iex; install
+```
+
+Replace `` with your license ID.
+
+Use the `-project` option to specify a Chef software application to install:
+
+```powershell
+. { iwr -useb https://chefdownload-commercial.chef.io/install.ps1?license_id= } | iex; install -project
+```
+
+Replace:
+
+- `` with your license ID
+- `` with the application you want to install
+
+For additional script install options, see the [script options](#script-options).
+
+## Install using the Community API
+
+Community users can use the install script from the [Chef Community API](/download/community/) to install Chef software.
+
+### UNIX, Linux, and macOS
+
+Use the Chef install script to install packages on UNIX, Linux, and macOS systems.
+
+By default the script installs the latest available version of Chef Infra Client:
+
+```bash
+curl -L https://chefdownload-community.chef.io/install.sh | sudo bash
+```
+
+Use the `-P` option to specify a Chef application to install:
+
+```bash
+curl -L https://chefdownload-community.chef.io/install.sh | sudo bash -s -- -P
+```
+
+Replace `` with the application you want to install.
+
+For additional script install options, see the [script options](#script-options).
+
+### Windows
+
+On Windows systems, you can install Chef software using the Powershell install script.
+
+By default the script installs the latest available version of Chef Infra Client:
+
+```powershell
+. { iwr -useb https://chefdownload-community.chef.io/install.ps1 } | iex; install
+```
+
+Use the `-project` option to specify a Chef application to install:
+
+```powershell
+. { iwr -useb https://chefdownload-community.chef.io/install.ps1 } | iex; install -project
+```
+
+For additional script install options, see the [script options](#script-options).
+
+## Script options
+
+In addition to the default install behavior, the Chef Software install script supports the following options:
+
+`-c` (`-channel` on Windows)
+
+: The [release channel](#release-channels) from which a package is pulled.
+
+ The Commercial Download API supports the `current` or `stable` channels.
+ The Community Download API only supports the `stable` channel.
+
+ Default value: `stable`.
+
+`-d` (`-download_directory` on Windows)
+
+: The directory into which a package is downloaded. When a package
+ already exists in this directory and the checksum matches, the
+ package isn't re-downloaded. When `-d` and `-f` aren't specified,
+ a package is downloaded to a temporary directory.
+
+`-f` (`-filename` on Windows)
+
+: The name of the file and the path at which that file is located.
+ When a filename already exists at this path and the checksum
+ matches, the package isn't re-downloaded. When `-d` and `-f` are
+ not specified, a package is downloaded to a temporary directory.
+
+`-P` (`-project` on Windows)
+
+: The product name to install. Supported versions of Chef products are
+ `chef`,`chef-backend`,`chef-server`,`inspec`,`chef-workstation`,`manage` and
+ `supermarket`. Default value: `chef`.
+
+`-s` (`-install_strategy` on Windows)
+
+: The method of package installations. The default strategy is to
+ always install when the install.sh script runs. Set to "once" to
+ skip installation if the product is already installed on the node.
+
+`-l` (`-download_url_override` on Windows)
+
+: Install package downloaded from a direct URL.
+
+`-a` (`-checksum` on Windows)
+
+: The SHA256 for download_url_override
+
+`-v` (`-version` on Windows)
+
+: The version of the package to be installed. A version always takes
+ the form x.y.z, where x, y, and z are decimal numbers that are used
+ to represent major (x), minor (y), and patch (z) versions. A
+ two-part version (x.y) is also allowed. For more information about
+ application versioning, see [semver.org](https://semver.org/).
+
+## Release channels
+
+{{< readfile file="content/reusable/md/release_channels.md" >}}
+
+## Examples
+
+The following examples show how to use the Chef Software install script.
+
+Use the `-v` option to install Chef Infra Client 15.8.23 on Unix, Linux, or macOS hosts:
+
+```bash
+curl -L https://chefdownload-commercial.chef.io/install.sh?license_id= | sudo bash -s -- -v 15.8.23
+```
+
+Replace `` with your license ID.
+
+To install the latest version of Chef Workstation on Windows from the `current` channel:
+
+```powershell
+. { iwr -useb https://chefdownload-commercial.chef.io/install.ps1?license_id= } | iex; install -channel current -project chef-workstation
+```
+
+Replace `` with your license ID.
diff --git a/content/chef_license.md b/content/chef_license.md
new file mode 100644
index 0000000..a9753b3
--- /dev/null
+++ b/content/chef_license.md
@@ -0,0 +1,7 @@
++++
+title = "About Chef Licenses"
+draft = false
+gh_repo = "chef-web-docs"
+layout="redirect"
+redirect_url="/licensing/"
++++
diff --git a/content/chef_license_accept.md b/content/chef_license_accept.md
new file mode 100644
index 0000000..4998f0f
--- /dev/null
+++ b/content/chef_license_accept.md
@@ -0,0 +1,7 @@
++++
+title = "Accepting the Chef License"
+draft = false
+gh_repo = "chef-web-docs"
+layout="redirect"
+redirect_url="/licensing/accept/"
++++
diff --git a/content/chef_repo.md b/content/chef_repo.md
new file mode 100644
index 0000000..5d99e2a
--- /dev/null
+++ b/content/chef_repo.md
@@ -0,0 +1,118 @@
++++
+title = "About chef-repo"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/chef_repo.html"]
+
+[menu]
+ [menu.infra]
+ title = "About chef-repo"
+ identifier = "chef_infra/cookbooks_reference/chef_repo.md"
+ parent = "chef_infra/cookbook_reference"
+ weight = 15
++++
+
+{{< readfile file="content/reusable/md/chef_repo_description.md" >}}
+
+## Generate the chef-repo
+
+Use the [chef generate repo command](/ctl_chef/#chef-generate-repo) to create your chef-repo directory along with the base folder structure. This command uses the `chef` command-line tool that's packaged as part of Chef Workstation to create a chef-repo.
+
+```bash
+chef generate repo REPO_NAME
+```
+
+{{< note >}}
+
+`chef generate repo` generates a chef-repo that's configured for Policyfiles by default. To create a repository that's setup for Roles and Environments use the `--roles` flag when running the command.
+
+{{< /note >}}
+
+## Directory structure
+
+The chef-repo contains several directories, each with a README file that describes what it's for and how to use that directory when managing systems.
+
+The default structure of a new chef-repo is:
+
+```plain
+. chef-repo
+├── LICENSE
+├── README.md
+├── chefignore
+├── cookbooks
+│ ├── README.md
+│ └── example
+│ ├── README.md
+│ ├── attributes
+│ │ ├── README.md
+│ │ └── default.rb
+│ ├── metadata.rb
+│ └── recipes
+│ ├── README.md
+│ └── default.rb
+├── data_bags
+│ ├── README.md
+│ └── example
+│ ├── README.md
+│ └── example_item.json
+└── policyfiles
+ └── README.md
+```
+
+### cookbooks
+
+The `cookbooks` directory contains cookbooks that configure systems in the infrastructure which are are downloaded from the [Chef Supermarket](https://supermarket.chef.io/) or created locally. The Chef Infra Client uses cookbooks to configuring the systems in the organization. Each cookbook can be configured to contain cookbook-specific copyright, email, and license data.
+
+### data_bags
+
+The `data_bags` directory is used to store all the data bags that exist for an organization. Each sub-directory corresponds to a single data bag on the Chef Infra Server and contains a JSON file corresponding to each data bag item.
+
+### policyfiles
+
+The `policyfiles` directory is used to store Policyfiles in the `.rb` format that define the set of cookbooks and attributes to apply to specific systems managed by the Chef Infra Server.
+
+### chefignore
+
+A `chefignore` file tells knife which cookbook files in the chef-repo it should ignore when uploading data to the Chef Infra Server.
+Include swap files, version control data, and build output data in a `chefignore` file.
+
+The `chefignore` file has the following rules:
+
+- Patterns use `*`, `**`, and `?` wildcards to match files and directories as defined by the `File.fnmatch` Ruby method.
+- A pattern is relative to the directory it's included in.
+- A pattern may contain relative directory names.
+- A pattern may match all files in a directory.
+- You can add a `chefignore` file to any subdirectory of a chef-repo. For example, `/`, `/cookbooks`, `/cookbooks/COOKBOOK_NAME/`, etc.
+- Lines that start with `#` are comments.
+
+Group types of ignored files in sections similar to the following:
+
+```plain
+## OS generated files
+*ignore_pattern
+
+## Editors
+another_ignore_pattern*
+```
+
+See Ruby's [`File.fnmatch` documentation](https://ruby-doc.org/core-2.5.1/File.html#method-c-fnmatch) for information on creating matching file patterns.
+
+#### Examples
+
+Many text editors leave files behind. To prevent knife from uploading these files to the Chef Infra Server, add an entry to the `chefignore` file.
+
+For Emacs backup files:
+
+```plain
+*~
+```
+
+and for Vim swap files:
+
+```plain
+*.sw[a-z]
+```
+
+## Many Users, Same Repo
+
+{{< readfile file="content/reusable/md/chef_repo_many_users_same_knife.md" >}}
diff --git a/content/chef_search.md b/content/chef_search.md
new file mode 100644
index 0000000..f6bbfc3
--- /dev/null
+++ b/content/chef_search.md
@@ -0,0 +1,387 @@
++++
+title = "About Search"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/chef_search.html", "essentials_search.html"]
+product = ["client", "server", "workstation"]
+
+[menu]
+ [menu.infra]
+ title = "Search"
+ identifier = "chef_infra/features/chef_search.md Search"
+ parent = "chef_infra/features"
+ weight = 70
++++
+
+{{< readfile file="content/reusable/md/search.md" >}}
+
+Many of the examples in this section use knife, but the search indexes
+and search query syntax can be used in many locations, including from
+within recipes and when using the Chef Infra Server API.
+
+## Search Indexes
+
+A search index is a full-text list of objects that are stored on the
+Chef Infra Server, against which search queries can be made. The
+following search indexes are built:
+
+
+
+
+
+
+
+
+
Search Index Name
+
Description
+
+
+
+
+
client
+
API client
+
+
+
DATA_BAG_NAME
+
A data bag is a global variable that's stored as JSON data and is accessible from a Chef Infra Server. The name of the search index is the name of the data bag. For example, if the name of the data bag was "admins" then a corresponding search query might look something like search(:admins, "*:*").
+
+
+
environment
+
An environment is a way to map an organization's real-life workflow to what can be configured and managed when using Chef Infra Server.
+
+
+
node
+
A node is any server or virtual server that's configured to be maintained by a Chef Infra Client.
+
+
+
role
+
A role is a way to define certain patterns and processes that exist across nodes in an organization as belonging to a single job function.
+
+
+
+
+### Using Knife
+
+{{< readfile file="content/workstation/reusable/md/knife_search_summary.md" >}}
+
+#### Search by platform ID
+
+{{< readfile file="content/workstation/reusable/md/knife_search_by_platform_ids.md" >}}
+
+#### Search by instance type
+
+{{< readfile file="content/workstation/reusable/md/knife_search_by_platform_instance_type.md" >}}
+
+#### Search by recipe
+
+{{< readfile file="content/workstation/reusable/md/knife_search_by_recipe.md" >}}
+
+#### Search by cookbook, then recipe
+
+{{< readfile file="content/workstation/reusable/md/knife_search_by_cookbook.md" >}}
+
+#### Search by node
+
+{{< readfile file="content/workstation/reusable/md/knife_search_by_node.md" >}}
+
+#### Search by node and environment
+
+{{< readfile file="content/workstation/reusable/md/knife_search_by_node_and_environment.md" >}}
+
+#### Search for nested attributes
+
+{{< readfile file="content/workstation/reusable/md/knife_search_by_nested_attribute.md" >}}
+
+#### Search for multiple attributes
+
+{{< readfile file="content/workstation/reusable/md/knife_search_by_query_for_many_attributes.md" >}}
+
+#### Search for nested attributes using a search query
+
+{{< readfile file="content/workstation/reusable/md/knife_search_by_query_for_nested_attribute.md" >}}
+
+#### Use a test query
+
+{{< readfile file="content/workstation/reusable/md/knife_search_test_query_for_ssh.md" >}}
+
+## Query Syntax
+
+{{< readfile file="content/reusable/md/search_query_syntax.md" >}}
+
+{{< note >}}
+
+Search queries may not contain newlines.
+
+{{< /note >}}
+
+## Filter Search Results
+
+{{< readfile file="content/reusable/md/infra_lang_method_search_filter_result.md" >}}
+
+## Keys
+
+{{< readfile file="content/reusable/md/search_key.md" >}}
+
+### Nested Fields
+
+{{< readfile file="content/reusable/md/search_key_nested.md" >}}
+
+### Examples
+
+{{< readfile file="content/reusable/md/search_key_name.md" >}}
+
+{{< readfile file="content/reusable/md/search_key_wildcard_question_mark.md" >}}
+
+{{< readfile file="content/reusable/md/search_key_wildcard_asterisk.md" >}}
+
+{{< readfile file="content/reusable/md/search_key_nested_starting_with.md" >}}
+
+{{< readfile file="content/reusable/md/search_key_nested_range.md" >}}
+
+## Patterns
+
+{{< readfile file="content/reusable/md/search_pattern.md" >}}
+
+### Exact Matching
+
+{{< readfile file="content/reusable/md/search_pattern_exact.md" >}}
+
+{{< readfile file="content/reusable/md/search_pattern_exact_key_and_item.md" >}}
+
+{{< readfile file="content/reusable/md/search_pattern_exact_key_and_item_string.md" >}}
+
+### Wildcard Matching
+
+{{< readfile file="content/reusable/md/search_pattern_wildcard.md" >}}
+
+{{< readfile file="content/reusable/md/search_pattern_wildcard_any_node.md" >}}
+
+{{< readfile file="content/reusable/md/search_pattern_wildcard_node_contains.md" >}}
+
+### Range Matching
+
+{{< readfile file="content/reusable/md/search_pattern_range.md" >}}
+
+{{< readfile file="content/reusable/md/search_pattern_range_in_between.md" >}}
+
+{{< readfile file="content/reusable/md/search_pattern_range_exclusive.md" >}}
+
+### Fuzzy Matching
+
+{{< readfile file="content/reusable/md/search_pattern_fuzzy.md" >}}
+
+{{< readfile file="content/reusable/md/search_pattern_fuzzy_summary.md" >}}
+
+## Operators
+
+{{< readfile file="content/reusable/md/search_boolean_operators.md" >}}
+
+{{< readfile file="content/reusable/md/search_boolean_operators_andnot.md" >}}
+
+### AND
+
+{{< readfile file="content/reusable/md/search_boolean_and.md" >}}
+
+### NOT
+
+{{< readfile file="content/reusable/md/search_boolean_not.md" >}}
+
+### OR
+
+{{< readfile file="content/reusable/md/search_boolean_or.md" >}}
+
+## Special Characters
+
+{{< readfile file="content/reusable/md/search_special_characters.md" >}}
+
+## Targets
+
+A search target is any object that has been indexed on the Chef Infra
+Server, including roles (and run-lists), nodes, environments, data bags,
+and any API client.
+
+### Roles in Run-lists
+
+A search query can be made for roles that are at the top-level of a
+run-list and also for a role that's part of an expanded run-list.
+
+{{< note >}}
+
+The `roles` field is updated with each Chef Infra Client run; changes to
+a run-list won't affect `roles` until the next Chef Infra Client run
+on the node.
+
+{{< /note >}}
+
+
+
+
+
+
+
+
+
Role Location
+
Description
+
+
+
+
+
Top-level
+
To find a node with a role in the top-level of its run-list, search within the role field (and escaping any special characters with the slash symbol) using the following syntax:
+
role:ROLE_NAME
+
where role (singular!) indicates the top-level run-list.
+
+
+
Expanded
+
To find a node with a role in an expanded run-list, search within the roles field (and escaping any special characters with the slash symbol) using the following syntax:
+
roles:ROLE_NAME
+
where roles (plural!) indicates the expanded run-list.
+
+
+
+
+To search a top-level run-list for a role named `load_balancer` use the
+`knife search` subcommand from the command line or the `search` method
+in a recipe. For example:
+
+```bash
+knife search node role:load_balancer
+```
+
+and from within a recipe:
+
+```ruby
+search(:node, 'role:load_balancer')
+```
+
+To search an expanded run-list for all nodes with the role
+`load_balancer` use the `knife search` subcommand from the command line
+or the `search` method in a recipe. For example:
+
+```bash
+knife search node roles:load_balancer
+```
+
+and from within a recipe:
+
+```ruby
+search(:node, 'roles:load_balancer')
+```
+
+### Nodes
+
+A node can be searched from a recipe by using the following syntax:
+
+```ruby
+search(:node, "key:attribute")
+```
+
+A wildcard can be used to replace characters within the search query.
+
+Expanded lists of roles (all of the roles that apply to a node,
+including nested roles) and recipes to the role and recipe attributes on
+a node are saved on the Chef Infra Server. The expanded lists of roles
+allows for searching within nodes that run a given recipe, even if that
+recipe is included by a role.
+
+{{< note >}}
+
+The `recipes` field is with each Chef Infra Client run; changes to a
+run-list won't affect `recipes` until the next Chef Infra Client run
+on the node.
+
+{{< /note >}}
+
+
+
+
+
+
+
+
+
Node Location
+
Description
+
+
+
+
+
In a specified recipe
+
To find a node with a specified recipe in the run-list, search within the run_list field (and escaping any special characters with the slash symbol) using the following syntax:
+
search(:node, 'run_list:recipe\[foo\:\:bar\]')
+
where recipe (singular!) indicates the top-level run-list. Variables can be interpolated into search strings using the Ruby alternate quoting syntax:
To find a node with a recipe in an expanded run-list, search within the recipes field (and escaping any special characters with the slash symbol) using the following syntax:
+
recipes:RECIPE_NAME
+
where recipes (plural!) indicates to search within an expanded run-list.
+
+
+
+
+If you just want to use each result of the search and don't care about
+the aggregate result you can provide a code block to the search method.
+Each result is then passed to the block:
+
+```ruby
+# Print every node matching the search pattern
+search(:node, "*:*").each do |matching_node|
+ puts matching_node.to_s
+end
+```
+
+### API Clients
+
+An API client is any machine that has permission to use the Chef Infra
+Server API to communicate with the Chef Infra Server. An API client is
+typically a node (that runs Chef Infra Client) or a workstation (that
+runs knife), but can also be any other machine configured to use the
+Chef Infra Server API.
+
+Sometimes when a role isn't fully defined (or implemented), it may be
+necessary for a machine to connect to a database, search engine, or some
+other service within an environment by using the settings located on
+another machine, such as a host name, IP address, or private IP address.
+The following example shows a simplified settings file:
+
+```ruby
+username: "mysql"
+password: "MoveAlong"
+host: "10.40.64.202"
+port: "3306"
+```
+
+where `host` is the private IP address of the database server. Use the
+following knife query to view information about the node:
+
+```bash
+knife search node "name:name_of_database_server" --long
+```
+
+To access these settings as part of a recipe that's run on the web
+server, use code similar to:
+
+```ruby
+db_server = search(:node, "name:name_of_database_server")
+private_ip = "#{db_server[0][:rackspace][:private_ip]}"
+puts private_ip
+```
+
+where the "\[0\]" is the 0 (zero) index for the `db_server` identifier.
+A single document is returned because the node is being searched on its
+unique name. The identifier `private_ip` will now have the value of the
+private IP address of the database server (`10.40.64.202`) and can then
+be used in templates as a variable, among other possible uses.
+
+### Environments
+
+{{< readfile file="content/reusable/md/environment.md" >}}
+
+{{< readfile file="content/reusable/md/search_environment.md" >}}
+
+### Data Bags
+
+{{< readfile file="content/reusable/md/data_bag.md" >}}
+
+{{< readfile file="content/reusable/md/search_data_bag.md" >}}
diff --git a/content/chef_solo.md b/content/chef_solo.md
new file mode 100644
index 0000000..7965c4d
--- /dev/null
+++ b/content/chef_solo.md
@@ -0,0 +1,164 @@
++++
+title = "chef-solo"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/chef_solo.html"]
+
+[menu]
+ [menu.infra]
+ title = "About Chef Solo"
+ identifier = "chef_infra/features/chef_solo/chef_solo.md About Chef Solo"
+ parent = "chef_infra/features/chef_solo"
+ weight = 10
++++
+
+{{< readfile file="content/reusable/md/chef_solo_summary.md" >}}
+
+## Cookbooks
+
+chef-solo supports two locations from which cookbooks can be run:
+
+- A local directory.
+- A URL at which a tar.gz archive is located.
+
+Using a tar.gz archive is the more common approach, but requires that
+cookbooks be added to an archive. For example:
+
+```bash
+tar zcvf chef-solo.tar.gz ./cookbooks
+```
+
+If you use multiple cookbook directories, chef-solo expects the
+tar.gz archive to have a directory structure similar to the following:
+
+```text
+. cookbooks
+├── cookbook-name-1
+│ └── attributes
+└── cookbook-name-2
+ └── attributes
+```
+
+The `cookbook_path` variable in the solo.rb file must include both
+directories. For example:
+
+```bash
+tar zcvf chef-solo.tar.gz ./cookbooks ./site-cookbooks
+```
+
+When the tar.gz archive contains all of the cookbooks required by
+chef-solo, upload it to the web server from which chef-solo will access
+the archive.
+
+## Nodes
+
+Unlike Chef Infra Client, where the node object is stored on the Chef
+Infra Server, chef-solo stores its node objects as JSON files on local
+disk. By default, chef-solo stores these files in a `nodes` folder in
+the same directory as your `cookbooks` directory. You can control the
+location of this directory using the `node_path` value in your
+configuration file.
+
+## Attributes
+
+chef-solo doesn't interact with the Chef Infra Server. Consequently,
+node-specific attributes must be located in a JSON file on the target
+system, a remote location (such as Amazon Simple Storage Service (S3)),
+or a web server on the local network.
+
+The JSON file must also specify the recipes that are part of the
+run-list. For example:
+
+```json
+{
+ "resolver": {
+ "nameservers": [ "10.0.0.1" ],
+ "search":"int.example.com"
+ },
+ "run_list": [ "recipe[resolver]" ]
+}
+```
+
+## Data bags
+
+A data bag is defined using JSON. chef-solo will look for data bags in
+`/var/chef/data_bags`, but this location can be modified by changing the
+setting in solo.rb. For example, the following setting in solo.rb:
+
+```ruby
+data_bag_path '/var/chef-solo/data_bags'
+```
+
+Create a data bag by creating folders. For example:
+
+```bash
+mkdir /var/chef-solo/data_bags
+```
+
+and:
+
+```bash
+mkdir /var/chef-solo/data_bags/admins
+```
+
+and then create a JSON file in that location:
+
+```json
+{
+ "id": "ITEM_NAME"
+}
+```
+
+where the name of the file is the `ITEM_NAME`, for example:
+
+```ruby
+/var/chef-solo/data_bags/admins/ITEM_NAME.json
+```
+
+## Roles
+
+A role is defined using JSON or the Ruby DSL. chef-solo will look for
+roles in `/var/chef/roles`, but this location can be modified by
+changing the setting for `role_path` in solo.rb. For example, the
+following setting in solo.rb:
+
+```ruby
+role_path '/var/chef-solo/roles'
+```
+
+Role data looks like the following in JSON:
+
+```json
+{
+ "name": "test",
+ "default_attributes": { },
+ "override_attributes": { },
+ "json_class": "Chef::Role",
+ "description": "This is just a test role, no big deal.",
+ "chef_type": "role",
+ "run_list": [ "recipe[test]" ]
+}
+```
+
+and like the following in the Ruby DSL:
+
+```ruby
+name 'test'
+description 'This is just a test role, no big deal.'
+run_list 'recipe[test]'
+```
+
+and finally, JSON data passed to chef-solo:
+
+```ruby
+{ 'run_list': 'role[test]' }
+```
+
+## Environments
+
+{{< readfile file="content/reusable/md/chef_solo_environments.md" >}}
+
+## chef-solo (executable)
+
+See [chef-solo (executable)](/ctl_chef_solo/) for complete CTL
+documentation.
diff --git a/content/chef_system_requirements.md b/content/chef_system_requirements.md
new file mode 100644
index 0000000..1baa4d5
--- /dev/null
+++ b/content/chef_system_requirements.md
@@ -0,0 +1,68 @@
++++
+title = "System Requirements"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/chef_system_requirements.html"]
+product = ["client", "server", "workstation"]
+
+[menu]
+ [menu.infra]
+ title = "System Requirements"
+ identifier = "chef_infra/install/chef_system_requirements.md System Requirements"
+ parent = "chef_infra/install"
+ weight = 5
++++
+
+Before installing Chef Infra:
+
+- Ensure that each system you will be managing is running a [supported
+ platform](/platforms/)
+- Ensure that the machine that will run the Chef Infra Server is
+ sufficiently powerful
+- Ensure that any network and firewall settings are configured
+ correctly
+
+Install and configure the Chef Infra Server, then install and configure
+Chef Workstation, and then run the bootstrap command from Chef
+Workstation to install Chef Infra Client on each node.
+
+## Chef Infra Server
+
+### Hardware requirements
+
+Chef Infra Server has the following hardware requirements:
+
+{{< readfile file="content/server/reusable/md/system_requirements_server_hardware.md" >}}
+
+### Software requirements
+
+Chef Infra Server has the following software requirements:
+
+{{< readfile file="content/server/reusable/md/system_requirements_server_software.md" >}}
+
+## Chef Infra Client
+
+- The recommended amount of RAM available to Chef Infra Client during
+ a Chef Infra Client run is 512MB
+- The Chef Infra Client binaries are stored in the `/opt/chef`
+ directory, which requires a minimum of 200MB of disk space. On
+ Windows, the Chef Infra Client binaries can be found in
+ `C:\opscode\`, and they require a minimum of 600MB of disk space.
+- The processor must be [supported](/platforms/). We recommend
+ a 1 gigahertz (GHz) or faster processor, but the processor speed
+ should be based on the other system loads.
+- Chef Infra Client caches to `/var/chef/cache` during a Chef Infra
+ Client run. This is the location in which downloaded cookbooks,
+ packages required by those cookbooks, and other large files are
+ stored. This directory requires enough space to save all of this
+ data and should be generously sized. 5GB is a safe number as a
+ starting point, but tune the size of `/var/chef/cache` as necessary.
+ This location is tunable in a node's
+ [client.rb](/config_rb_client/) file using the
+ `file_cache_path` setting.
+
+## Chef Workstation
+
+- 64-bit architecture
+- 4 GB of RAM or more
+- 2 GB of free disk space
diff --git a/content/config_rb_client.md b/content/config_rb_client.md
new file mode 100644
index 0000000..b2b86a0
--- /dev/null
+++ b/content/config_rb_client.md
@@ -0,0 +1,595 @@
++++
+title = "client.rb"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+aliases = ["/config_rb_client.html"]
+
+[menu]
+ [menu.infra]
+ title = "client.rb"
+ identifier = "chef_infra/install/config_rb_client.md client.rb Configuration"
+ parent = "chef_infra/install"
+ weight = 40
++++
+
+
+
+{{< readfile file="content/reusable/md/config_rb_client_summary.md" >}}
+
+## Settings
+
+This configuration file has the following settings:
+
+`add_formatter`
+: A 3rd-party formatter. (See [nyan-cat](https://github.com/andreacampi/nyan-cat-chef-formatter) for an example of a 3rd-party formatter.) Each formatter requires its own entry.
+
+`allowed_automatic_attributes`
+: An array that allows `automatic` attributes, preventing non-allowed attributes from being saved.
+
+ For more information, see [Attribute Persistence]({{< relref "/attribute_persistence#attribute-allowlist" >}}).
+
+`allowed_default_attributes`
+: An array that allows `default` attributes, preventing non-allowed attributes from being saved.
+
+ For more information, see [Attribute Persistence]({{< relref "/attribute_persistence#attribute-allowlist" >}}).
+
+`allowed_normal_attributes`
+: An array that allows `normal` attributes, preventing non-allowed attributes from being saved.
+
+ For more information, see [Attribute Persistence]({{< relref "/attribute_persistence#attribute-allowlist" >}}).
+
+`allowed_override_attributes`
+: An array that allows `override` attributes, preventing non-allowed attributes from being saved.
+
+ For more information, see [Attribute Persistence]({{< relref "/attribute_persistence#attribute-allowlist" >}}).
+
+`authentication_protocol_version`
+: Sets the authentication protocol that's used to communicate with Chef Infra Server. For example, specify protocol version 1.3 to enable support for SHA-256 algorithms:
+
+ ```ruby
+ knife[:authentication_protocol_version] = '1.3'
+ ```
+
+ {{< note >}}
+
+ Authentication protocol 1.3 is only supported on Chef Server versions 12.4.0 and above.
+
+ {{< /note >}}
+
+`automatic_attribute_blacklist`
+: **EOL in Chef Infra Client 18**. Use `blocked_automatic_attributes`.
+: An array that blocks `automatic` attributes, preventing blocked attributes from being saved.
+
+`automatic_attribute_whitelist`
+: **EOL in Chef Infra Client 18**. Use `allowed_automatic_attributes`.
+: An array that allows `automatic` attributes, preventing non-allowed attributes from being saved.
+
+`blocked_automatic_attributes`
+: An array that blocks `automatic` attributes, preventing blocked attributes from being saved.
+
+ For more information, see [Attribute Persistence]({{< relref "/attribute_persistence#attribute-blocklist" >}}).
+
+`blocked_default_attributes`
+: An array that blocks `default` attributes, preventing block attributes from being saved.
+
+ For more information, see [Attribute Persistence]({{< relref "/attribute_persistence#attribute-blocklist" >}}).
+
+`blocked_normal_attributes`
+: An array allows `normal` attributes, preventing non-allowed attributes from being saved.
+
+ For more information, see [Attribute Persistence]({{< relref "/attribute_persistence#attribute-blocklist" >}}).
+
+`blocked_override_attributes`
+: An array blocks `override` attributes, preventing blocked attributes from being saved.
+
+ For more information, see [Attribute Persistence]({{< relref "/attribute_persistence#attribute-blocklist" >}}).
+
+`cache_path`
+: The home directory for the user that runs Chef Infra Client as a non-root user.
+
+`checksum_path`
+: The location in which checksum files are stored. These are used to validate individual cookbook files, such as recipes. The checksum itself is stored in the Chef Infra Server database and is then compared to a file in the checksum path that has a filename identical to the checksum.
+
+`chef_guid`
+: The node UUID used by Chef Automate. Setting this allows the node UUID to be specified, and can be carried across instances of a node.
+
+`chef_license`
+: Used to accept the Chef license. Can be set to `accept` or `accept-no-persist`, which persists the license acceptance to disk. If passed to versions where the license isn't required this configuration option is a no-op.
+
+`chef_repo_path`
+: The path to the chef-repo containing cookbooks and other files, such as environments or data bags, when running Chef Infra Client in local mode.
+
+`chef_server_url`
+: The URL of the Chef Infra Server. For example:
+
+ ```ruby
+ https://localhost/organizations/ORG_NAME
+ ```
+
+`chef_zero.enabled`
+: Enable chef-zero. This setting requires `local_mode` to be set to `true`.
+
+ Default value: `true` if running in local-mode, otherwise `false`.
+
+`chef_zero.port`
+: The port on which chef-zero is to listen. If specified as a range, Chef Infra Client will take the first available port in the range. For example `10,20,30` or `10000-20000`.
+
+ Default value: `8889-9999`.
+
+`clear_gem_sources`
+: Globally sets the default of the `clear_sources` property on the `gem_package` and `chef_gem` resources.
+
+ Default value: `false`.
+
+`client_fork`
+: Contain Chef Infra Client runs in a secondary process with dedicated RAM. When a Chef Infra Client run is complete, the RAM is returned to the parent process. This setting helps ensure that a Chef Infra Client uses a steady amount of RAM over time because the parent process doesn't run recipes. This setting also helps prevent memory leaks such as those that can be introduced by the code contained within a poorly designed cookbook.
+
+ Default value: `true`. Set to `false` to disable running Chef Infra Client in fork node.
+
+ {{< note >}}
+
+ Must be set to `false` up to Chef Infra Client 13.11.3 to gather the standard return code offered by `exit_status true`. Later versions run as expected without changes to the configuration file.
+
+ {{< /note >}}
+
+`client_key`
+: The location of the file that contains the client key.
+
+ Default value: `/etc/chef/client.pem`.
+
+`client_registration_retries`
+: The number of times a Chef Infra Client will attempt to register with a Chef Infra Server.
+
+ Default value: `5`.
+
+`client_d_dir`
+: A directory that contains additional configuration files for Chef Infra Client.
+
+`cookbook_path`
+: The sub-directory for Chef Infra Client cookbooks. This value can be a string or an array of file system locations, processed in the specified order. The last cookbook is considered to override local modifications.
+
+`cookbook_sync_threads`
+: The number of helper threads available for parallel cookbook synchronization. Increasing this value **may** increase the frequency of gateway errors from the Chef Infra Server (503 and 504 errors). Decreasing this number reduces the frequency of gateway errors, if present.
+
+ Default value: `10`.
+
+`data_bag_decrypt_minimum_version`
+: The minimum required version of data bag encryption. Possible values: `1`, `2`, and `3`.
+ Use the default value of `3` for additional encrypted data bag security.
+
+`data_bag_path`
+: The location from which a data bag is loaded.
+
+ Default value: `/var/chef/data_bags`.
+
+`data_collector.server_url`
+: The fully qualified URL to the data collector server API.
+
+`data_collector.token`
+: The shared data collector security token. When configured, the token will be passed as an HTTP header named `x-data-collector-token` which the server can choose to accept or reject.
+
+`data_collector.mode`
+: The Chef Infra Client mode in which the Data Collector will be enabled. Possible values: `:solo`, `:client`, or `:both`. The `:solo` value is used for Chef Infra Client operating in Chef Solo Mode or Chef Solo Legacy Mode.
+
+ Default value: `both`.
+
+`data_collector.raise_on_failure`
+: When enabled, Chef Infra Client raises an error if it can't successfully POST to the data collector server.
+
+ Default value: `false`.
+
+`default_attribute_blacklist`
+: **EOL in Chef Infra Client 18**. Use `blocked_default_attributes`.
+: Normal that blocks `default` attributes, preventing block attributes from being saved.
+
+`default_attribute_whitelist`
+: **EOL in Chef Infra Client 18**. Use `allowed_default_attributes`.
+: Normal that allows `default` attributes, preventing non-allowed attributes from being saved.
+
+`diff_disabled`
+: Cause Chef Infra Client to create a diff when changes are made to a file.
+
+ Default value: `false`.
+
+`diff_filesize_threshold`
+: The maximum size (in bytes) of a file for which Chef Infra Client can create a diff.
+
+ Default value: `10000000`.
+
+`diff_output_threshold`
+: The maximum size (in bytes) of a diff file Chef Infra Client can create.
+
+ Default value: `1000000`.
+
+`disable_event_logger`
+: Enable or disable sending Chef Infra Client internal state events to the Windows "Application" event log. Set to `false` to send events to the Windows "Application" event log at the start and end of a Chef Infra Client run, and also if a Chef Infra Client run fails. Use `log_location` to set the destination of your Chef Infra Client logs to the Windows event log. Set to `true` to disable event logging.
+
+ Default value: `false`.
+
+`enable_reporting`
+: Cause Chef Infra Client to send run data to Chef Automate server.
+
+ Default value: `true`
+
+`enable_reporting_url_fatals`
+: Cause a Chef Infra Client run to fail when run data can't be sent to the Chef Automate server (for any reason).
+
+ Default value: `false`
+
+`enable_selinux_file_permission_fixup`
+: SELinux environments only. Cause Chef Infra Client to attempt to apply the correct file permissions to an updated file using the `restorecon` command. Set to `false` to prevent Chef Infra Client from attempting this action.
+
+`encrypted_data_bag_secret`
+: The path to a secrets file which can decrypt encrypted data bags.
+
+`enforce_default_paths`
+: Turn on path sanity in resources that shellout so that expected paths like `/sbin` or `/bin` are added to the PATH.
+
+ Disabled by default.
+
+`enforce_path_sanity`
+: **EOL in Chef Infra Client 18**. Use `enforce_default_paths`.
+: Turn on path sanity in resources that shellout so that expected paths like `/sbin` or `/bin` are added to the PATH.
+
+ Disabled by default.
+
+`environment`
+: The name of the Chef Infra environment.
+
+`environment_path`
+: The path to the environment file.
+
+ Default value: `/var/chef/environments`.
+
+`exit_status`
+: When set to `:enabled`, Chef Infra Client will use [standardized exit codes](https://github.com/chef/chef/blob/main/docs/dev/design_documents/client_exit_codes.md#exit-codes-in-use) for the Chef Infra Client run status, and any non-standard exit codes will be converted to `1` or `GENERIC_FAILURE`.
+ This setting can also be set to `:disabled` to use the pre-Chef Infra Client 13 exit code behavior.
+
+ Default value: `nil`.
+
+`file_atomic_update`
+: Apply atomic file updates to all resources. Set to `true` for global atomic file updates. Set to `false` for global non-atomic file updates. (Use the `atomic_update` setting for each resource to override this setting.)
+
+ Default value: `true`.
+
+ {{< warning >}}
+
+ Changing this setting to `false` may cause file corruption, data loss, or instability. Use the `atomic_update` property on the **cookbook_file**, **file**, **remote_file**, and **template** resources to tune this behavior at the recipe level.
+
+ {{< /warning >}}
+
+`file_backup_path`
+: The location in which backup files are stored. If this value is empty, backup files are stored in the directory of the target file.
+
+ Default value: `/var/chef/backup`.
+
+`file_cache_path`
+: The location in which cookbooks (and other transient data) files are stored when they're synchronized. This value can also be used in recipes to download files with the **remote_file** resource.
+
+`file_staging_uses_destdir`
+: How file staging (using temporary files) is done. When `true`, temporary files are created in the directory in which files will reside. When `false`, temporary files are created under `ENV['TMP']`.
+
+ Default value: `true`.
+
+`fips`
+: Allows OpenSSL to enforce FIPS-validated security during a Chef Infra Client run. Set to `true` to enable FIPS-validated security.
+
+`force_formatter`
+: Using `force_formatter` makes Chef Infra Client default to formatter output when STDOUT isn't a TTY.
+
+`force_logger`
+: Using `force_logger` makes Chef Infra Client default to logger output when STDOUT is a TTY.
+
+`ftp_proxy`
+: The proxy server for FTP connections.
+
+`ftp_proxy_pass`
+: The password for the proxy server when the proxy server is using an FTP connection.
+
+ Default value: `nil`.
+
+`ftp_proxy_user`
+: The user name for the proxy server when the proxy server is using an FTP connection.
+
+ Default value: `nil`.
+
+`group`
+: The group that owns a process. This is required when starting any executable as a daemon.
+
+ Default value: `nil`.
+
+`gem_installer_bundler_options`
+: Additional options to pass to bundler when installing metadata for cookbook.
+
+ Default value: `nil`.
+
+ For example:
+
+ ```ruby
+ gem_installer_bundler_options = [
+ "--local", "--clean"
+ ]
+ ```
+
+ or
+
+ ```ruby
+ gem_installer_bundler_options = "--local"
+ ```
+
+`http_proxy`
+: The proxy server for HTTP connections.
+
+ Default value: `nil`.
+
+`http_proxy_pass`
+: The password for the proxy server when the proxy server is using a HTTP connection.
+
+ Default value: `nil`.
+
+`http_proxy_user`
+: The user name for the proxy server when the proxy server is using a HTTP connection.
+
+ Default value: `nil`.
+
+`http_retry_count`
+: The number of retry attempts.
+
+ Default value: `5`.
+
+`http_retry_delay`
+: The delay (in seconds) between retry attempts.
+
+ Default value: `5`.
+
+`https_proxy`
+: The proxy server for HTTPS connections.
+
+ Default value: `nil`.
+
+`https_proxy_pass`
+: The password for the proxy server when the proxy server is using a HTTPS connection.
+
+ Default value: `nil`.
+
+`https_proxy_user`
+: The user name for the proxy server when the proxy server is using a HTTPS connection.
+
+ Default value: `nil`.
+
+`interval`
+: The frequency (in seconds) at which Chef Infra Client runs when running in daemonized mode. We don't recommend running in daemonized mode. Instead you should rely on scheduled execution from system schedulers like systemd timers, cron jobs, or Windows Scheduled Tasks.
+
+ Default value: `1800`.
+
+`json_attribs`
+: The path to a file that contains JSON data.
+
+`listen`
+: Run chef-zero in socketless mode. Set to `false` to disable port binding and HTTP requests on localhost.
+
+`local_key_generation`
+: Whether the Chef Infra Server or Chef Infra Client generates the private/public key pair. When `true`, Chef Infra Client generates the key pair, and then sends the public key to the Chef Infra Server.
+
+ Default value: `true`.
+
+`local_mode`
+: Run Chef Infra Client in local mode. This allows all commands that work against the Chef Infra Server to also work against the local chef-repo.
+
+`lockfile`
+: The location of the Chef Infra Client lock file. This value is typically platform dependent, so it should be a location defined by `file_cache_path`. The default location of a lock file shouldn't be on an NFS mount.
+
+ Default value: a location defined by `file_cache_path`.
+
+`log_level`
+: The level of logging to be stored in a log file. Possible levels: `:auto` (default), `:trace`, `:debug`, `:info`, `:warn`, `:error`, or `:fatal`. The `:auto` level will use `:warn` when a terminal is available or `:info` when a terminal isn't available.
+
+`log_location`
+: The location of the log file. Possible values: `/path/to/log_location`, `STDOUT`, `STDERR`, `:win_evt` (Windows Event Logger), or `:syslog` (writes to the syslog daemon facility with the originator set as `chef-client`). The application log will specify the source as `Chef`.
+
+ Default value: `STDOUT`.
+
+`migrate_key_to_keystore`
+: Set to `true` to tell the Chef Infra Client to create a new key pair in a PFX certificate object and store that in the local machine certificate store. Chef Infra Client will check for the presence of that key when the headers to connect to Chef Infra Server are built and will use it if present. **Windows only.**
+
+`minimal_ohai`
+: Run a minimal set of Ohai plugins providing data necessary for the execution of Chef Infra Client's built-in resources. Setting this to true will skip many large and time consuming plugins such as `cloud` or `packages`. Setting this to true may break cookbooks that assume all Ohai data will be present.
+
+`named_run_list`
+: A specific named runlist defined in the node's applied Policyfile which should be used when running Chef Infra Client.
+
+`no_lazy_load`
+: Download all cookbook files and templates at the beginning of a Chef Infra Client run.
+
+ Default value: `true`.
+
+`no_proxy`
+: A comma-separated list of URLs that don't need a proxy.
+
+ Default value: `nil`.
+
+`node_name`
+: The unique identifier of the node. This determines which configuration should be applied and sets the `client_name`, which is the name used when authenticating to a Chef Infra Server. By default, Chef Infra Client will use the system's FQDN as the node name. In general, Chef recommends that you leave this setting blank and let the client assign the FQDN of the node as the `node_name` during each Chef Infra Client run.
+
+`node_path`
+: The location in which nodes are stored during a Chef Infra Client run in local mode.
+
+ Default value: `/var/chef/node`.
+
+`normal_attribute_blacklist`
+: **EOL in Chef Infra Client 18**. Use `blocked_normal_attributes`.
+: An array that blocks `normal` attributes, preventing blocked attributes from being saved.
+
+`override_attribute_blacklist`
+: **EOL in Chef Infra Client 18**. Use `blocked_override_attributes`.
+: An array that blocks `override` attributes, preventing blocked attributes from being saved.
+
+`normal_attribute_whitelist`
+: **EOL in Chef Infra Client 18**. Use `allowed_normal_attributes`.
+: An array that allows `normal` attributes, preventing non-allowed attributes from being saved.
+
+`override_attribute_whitelist`
+: **EOL in Chef Infra Client 18**. Use `allowed_override_attributes`.
+: An array that allows `override` attributes, preventing non-allowed attributes from being saved.
+
+`pid_file`
+: The location in which a process identification number (pid) is saved. An executable, when started as a daemon, writes the pid to the specified file.
+
+ Default value: `/tmp/name-of-executable.pid`.
+
+`policy_group`
+: The name of a policy group that exists on the Chef Infra Server. `policy_name` must also be specified.
+
+`policy_group_path`
+: The location of policy_groups on disk.
+
+`policy_name`
+: The name of a policy, as identified by the `name` setting in a Policyfile.rb file. `policy_group` must also be specified.
+
+`policy_path`
+: The location of policies on disk.
+
+`recipe_url`
+: A URL to download recipes from when running in local mode.
+
+`rest_timeout`
+: The time (in seconds) after which an HTTP REST request is to time out.
+
+ Default value: `300`.
+
+`role_path`
+: The location in which role files are located.
+
+ Default value: `/var/chef/roles`.
+
+`rubygems_url`
+: The location to source rubygems. It can be set to a string or array of strings for URIs to set as rubygems sources. This allows individuals to setup an internal mirror of rubygems for "airgapped" environments.
+
+ Default value: `https://www.rubygems.org`. If a `source` is specified in either `gem_package` of `chef_gem` resources it will be added to the values provided here.
+
+`run_lock_timeout`
+: The amount of time (in seconds) to wait for a Chef Infra Client lock file to be deleted.
+ A Chef Infra Client run won't start when a lock file is present.
+ If a lock file isn't deleted before this time expires, the pending Chef Infra Client run exits.
+
+ Default value: not set (indefinite). Set to `0` to cause a second Chef Infra Client to exit immediately.
+
+`script_path`
+: An array of paths to search for knife exec scripts if they're not in the current directory
+
+`skip_gem_metadata_installation`
+: when `skip_gem_metadata_installation` is set to true, cookbook gem installation will be skipped.
+
+ Default value: `false`
+
+`splay`
+: A random number between zero and `splay` that's added to `interval`. Use splay to help balance the load on the Chef Infra Server by ensuring that many Chef Infra Client runs aren't occurring at the same interval.
+
+ Default value: `nil`.
+
+`stream_execute_output`
+: Always stream the output of `execute` resources even if the `live_stream` property isn't set to true.
+
+ Default value: `false`
+
+`show_download_progress`
+: Using show_download_progress will display the overall progress of a `remote_file` download.
+
+ Default value: `false`
+
+`download_progress_interval`
+: When `show_download_progress` is set to true this is the interval in seconds to write out download progress.
+
+ Default value: `10`
+
+`ssl_ca_file`
+: The file in which the OpenSSL key is saved. Chef Infra Client generates this setting automatically and most users don't need to modify it.
+
+`ssl_ca_path`
+: The path to where the OpenSSL key is located. Chef Infra Client generates this setting automatically and most users don't need to modify it.
+
+`ssl_client_cert`
+: The OpenSSL X.509 certificate used for mutual certificate validation. This setting is only necessary when mutual certificate validation is configured on the Chef Infra Server.
+
+ Default value:`nil`.
+
+`ssl_client_key`
+: The OpenSSL X.509 key used for mutual certificate validation. This setting is only necessary when mutual certificate validation is configured on the Chef Infra Server.
+
+ Default value: `nil`.
+
+`ssl_verify_mode`
+: Set the verify mode for HTTPS requests.
+
+ - Use `:verify_none` for no validation of SSL certificates.
+ - Use `:verify_peer` for validation of all SSL certificates, including the Chef Infra Server connections, S3 connections, and any HTTPS **remote_file** resource URLs used in Chef Infra Client runs. This is the recommended setting.
+
+ Depending on how OpenSSL is configured, the `ssl_ca_path` may nee to be specified.
+
+ Default value: `:verify_peer`.
+
+`trusted_certs_dir`
+: A directory that contains additional SSL certificates to trust. Any certificates in this directory will be added to whatever CA bundle ruby is using.
+ Use this to add self-signed certs for your Chef Infra Server or local HTTP file servers.
+
+ Default value: `trusted_certs` directory in your chef configuration directory.
+
+`umask`
+: The file mode creation mask, or umask.
+
+ Default value: `0022`.
+
+`use_policyfile`
+: Chef Infra Client automatically checks the configuration, node JSON, and the stored node on the Chef Infra Server to determine if Policyfile files are in use, and then automatically updates this flag.
+
+ Default value: `false`.
+
+`user`
+: The user that owns a process. This is required when starting any executable as a daemon.
+
+ Default value: `nil`.
+
+`validation_client_name`
+: The name of the chef-validator key that Chef Infra Client uses to access the Chef Infra Server during the initial Chef Infra Client run. This is only used by the legacy validator based bootstrapping.
+
+`validation_key`
+: The location of the file that contains the key used when a Chef Infra Client is registered with a Chef Infra Server. A validation key is signed using the `validation_client_name` for authentication.
+
+ Default value: `/etc/chef/validation.pem`. This is only used by the legacy validator based bootstrapping.
+
+`verbose_logging`
+: Set the log level. Options: `true`, `nil`, and `false`. When this is set to `false`, notifications about individual resources being processed are suppressed (and are output at the `:info` logging level). Setting this to `false` can be useful when a Chef Infra Client is run as a daemon.
+
+ Default value: `nil`.
+
+`verify_api_cert`
+: Verify the SSL certificate on the Chef Infra Server. When `true`, Chef Infra Client always verifies the SSL certificate. When `false`, Chef Infra Client uses the value of `ssl_verify_mode` to determine if the SSL certificate requires verification.
+
+ Default value: `false`.
+
+### Automatic Proxy Config
+
+{{< readfile file="content/reusable/md/proxy_env.md" >}}
+
+## .d Directories
+
+{{< readfile file="content/reusable/md/config_rb_client_dot_d_directories.md" >}}
+
+## Ohai Settings
+
+{{< readfile file="content/reusable/md/config_rb_ohai.md" >}}
+
+{{< readfile file="content/reusable/md/config_rb_ohai_settings.md" >}}
+
+## Example
+
+The following `client.rb` file shows the simplest way to connect to Chef Infra Server:
+
+```ruby
+chef_server_url 'https://chef-server.example.com/organizations/ORGANIZATION'
+validation_client_name '-validator'
+validation_key '/etc/chef/validator.pem'
+client_key '/etc/chef/client.pem'
+```
diff --git a/content/config_rb_metadata.md b/content/config_rb_metadata.md
new file mode 100644
index 0000000..bb2bf07
--- /dev/null
+++ b/content/config_rb_metadata.md
@@ -0,0 +1,294 @@
++++
+title = "metadata.rb"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+aliases = ["/config_rb_metadata.html"]
+
+[menu]
+ [menu.infra]
+ title = "metadata.rb"
+ identifier = "chef_infra/cookbook_reference/config_rb_metadata.md metadata.rb Configuration"
+ parent = "chef_infra/cookbook_reference"
+ weight = 60
++++
+
+
+
+{{< readfile file="content/reusable/md/cookbooks_metadata.md" >}}
+
+* Located at the top level of a cookbook's directory structure.
+* Compiled whenever a cookbook is uploaded to the Chef Infra Server or when the `knife cookbook metadata` subcommand is run, and then stored as JSON data.
+* Created automatically by knife whenever the `knife cookbook create` subcommand is run.
+* Edited using a text editor, and then re-uploaded to the Chef Infra Server as part of a cookbook upload.
+
+## Error Messages
+
+The Chef Infra Server will only try to distribute the cookbooks that are needed to configure an individual node. This is determined by identifying the roles and recipes that are assigned directly to that system, and then to expand the list of dependencies, and then to deliver that entire set to the node. In some cases, if the dependency isn't specified in the cookbook's metadata, the Chef Infra Server may not treat that dependency as a requirement, which will result in an error message. If an error message is received from the Chef Infra Server about cookbook distribution, verify the `depends` entries in the `metadata.rb` file, and then try again.
+
+{{< note >}}
+
+A metadata.json file can be edited directly, should temporary changes be required. Any subsequent upload or action that generates metadata will cause the existing metadata.json file to be overwritten with the newly generated metadata. Therefore, any permanent changes to cookbook metadata should be done in the `metadata.rb` file, and then re-uploaded to the Chef Infra Server.
+
+{{< /note >}}
+
+## Version Constraints
+
+Many fields in a cookbook's metadata allow the user to constrain versions. The following operators are common to all fields:
+
+
+
+
+
+
+
+
+
+
Specification
+
Operator
+
+
+
+
+
Pessimistic (see note below)
+
~>
+
+
+
Equal to
+
=
+
+
+
Greater than or equal to
+
>=
+
+
+
Greater than
+
>
+
+
+
Less than
+
<
+
+
+
Less than or equal to
+
<=
+
+
+
+
+
+{{< note >}}
+
+Pessimistic locking is enabled by proper [semantic versioning](https://semver.org) of cookbooks. If we're on version 2.2.3 of a cookbook, we know that the API will be stable until the 3.0.0 release. Using traditional operators, we'd write this as `>= 2.2.0, < 3.0`. Instead, we can write this by combining a tilde "\~" and right angle bracket "\>"--often called a tilde-rocket or "twiddle-wakka"--followed by the major and minor version numbers. For example: `~> 2.2`
+
+{{< /note >}}
+
+## Settings
+
+This configuration file has the following settings:
+
+`chef_version`
+
+: A range of Chef Infra Client versions that are supported by this cookbook. All [version constraint operators](#version-constraints) are applicable to this field.
+
+ For example, to match any 16.x version of the Chef Infra Client, but not 15.x or 17.x:
+
+ ```ruby
+ chef_version '~> 16.0'
+ ```
+
+ A more complex example where you set both a lower and upper bound of the Chef Infra Client version:
+
+ ```ruby
+ chef_version '>= 17.2', '< 17.4'
+ ```
+
+`depends`
+
+: This field requires that a cookbook with a matching name and version exists on the Chef Infra Server. When the match exists, the Chef Infra Server includes the dependency as part of the set of cookbooks that are sent to the node during a Chef Infra Client run. It's important that the `depends` field contain accurate data. If a dependency statement is inaccurate, Chef Infra Client may not be able to complete the configuration of the system. All [version constraint operators](#version-constraints) are applicable to this field.
+
+ For example, to set a dependency a cookbook named `cats`:
+
+ ```ruby
+ depends 'cats'
+ ```
+
+ or, to set a dependency on the same cookbook, but only when the version is less than 1.0:
+
+ ```ruby
+ depends 'cats', '< 1.0'
+ ```
+
+`description`
+
+: A short description of a cookbook and its functionality.
+
+ For example:
+
+ ```ruby
+ description 'A fancy cookbook that manages a herd of cats!'
+ ```
+
+`gem`
+
+: Specifies a gem dependency for installation in Chef Infra Client through bundler. The gem installation occurs after all cookbooks are synchronized but before loading any other cookbooks. Use this attribute one time for each gem dependency. For example:
+
+ ```ruby
+ gem 'loofah'
+ gem 'chef-sugar'
+ ```
+
+ {{< warning >}}
+
+ Use the `gem` setting only for making external chef libraries shipped as gems accessible in a Chef Infra Client run for libraries and attribute files. The `gem` setting in `metadata.rb` allows for the early installation of this specific type of gem, with the fundamental limitation that it can't install native gems.
+
+ Don't install native gems with the `gem` setting in `metadata.rb`. The `gem` setting isn't a general purpose replacement for the [chef_gem resource](/resources/chef_gem/), and doesn't internally re-use the `chef_gem` resource. Native gems require C compilation and must not be installed with `metadata.rb` because `metadata.rb` runs before any recipe code runs. Consequently, Chef Infra Client Linux install the C compilers before the gem installation occurs. Instead, install native gems with the `chef_gem` resource called from the recipe code. You'll also need to use the `build_essential` resource in the recipe code to install the prerequisite compilers onto the system.
+
+ Pure ruby gems can also be installed with `metadata.rb`.
+
+ {{< /warning >}}
+
+`issues_url`
+
+: The URL of the location in which a cookbook's issue tracking is maintained. This setting is also used by Chef Supermarket. In Chef Supermarket, this value is used to define the destination for the "View Issues" link.
+
+ For example:
+
+ ```ruby
+ issues_url 'https://github.com/chef-cookbooks/chef-client/issues'
+ ```
+
+`license`
+
+: The type of license under which a cookbook is distributed: `Apache v2.0`, `GPL v2`, `GPL v3`, `MIT`, or `license 'Proprietary - All Rights Reserved` (default). Please be aware of the licenses for files inside of a cookbook and be sure to follow any restrictions they describe.
+
+ For example:
+
+ ```ruby
+ license 'Apache-2.0'
+ ```
+
+ or:
+
+ ```ruby
+ license 'GPL-3.0'
+ ```
+
+ or:
+
+ ```ruby
+ license 'MIT'
+ ```
+
+ or:
+
+ ```ruby
+ license 'Proprietary - All Rights Reserved'
+ ```
+
+`maintainer`
+
+: The name of the person responsible for maintaining a cookbook, either an individual or an organization.
+
+ For example:
+
+ ```ruby
+ maintainer 'Bob Bobberson'
+ ```
+
+`maintainer_email`
+
+: The email address for the person responsible for maintaining a cookbook. Only one email can be listed here, so if this needs to be forwarded to multiple people consider using an email address that's already setup for mail forwarding.
+
+ For example:
+
+ ```ruby
+ maintainer_email 'bob@example.com'
+ ```
+
+`name`
+
+: Required. The name of the cookbook.
+
+ For example:
+
+ ```ruby
+ name 'cats'
+ ```
+
+`ohai_version`
+
+: A range of Ohai versions that are supported by this cookbook. All [version constraint operators](#version-constraints) are applicable to this field.
+
+ For example, to match any 8.x version of Ohai, but not 7.x or 9.x:
+
+ ```ruby
+ ohai_version '~> 8'
+ ```
+
+ {{< note >}}
+
+ This setting isn't visible in Chef Supermarket.
+
+ {{< /note >}}
+
+`privacy`
+
+: Specify a cookbook as private. This prevents a cookbook from being uploaded to the public Supermarket or any Supermarket where ``ENFORCE_PRIVACY`` has been enabled.
+
+ For example:
+
+ ```ruby
+ privacy true
+ ```
+
+`source_url`
+
+: The URL of the location in which a cookbook's source code is maintained. This setting is also used by Chef Supermarket. In Chef Supermarket, this value is used to define the destination for the "View Source" link.
+
+ For example:
+
+ ```ruby
+ source_url 'https://github.com/chef-cookbooks/chef-client'
+ ```
+
+`supports`
+
+: Show that a cookbook has a supported platform. Use a version constraint to define dependencies for platform versions: `<` (less than), `<=` (less than or equal to), `=` (equal to), `>=` (greater than or equal to), `~>` (approximately greater than), or `>` (greater than). To specify more than one platform, use more than one `supports` field, once for each platform.
+
+ For example, to support every version of Ubuntu:
+
+ ```ruby
+ supports 'ubuntu'
+ ```
+
+ or, to support versions of Ubuntu greater than or equal to 20.04:
+
+ ```ruby
+ supports 'ubuntu', '>= 20.04'
+ ```
+
+ or, to support only Ubuntu 20.04:
+
+ ```ruby
+ supports 'ubuntu', '= 20.04'
+ ```
+
+ Here is a list of all of the supported specific operating systems:
+
+ ```ruby
+ %w( aix amazon centos fedora freebsd debian oracle mac_os_x redhat suse opensuseleap ubuntu windows zlinux ).each do |os|
+ supports os
+ end
+ ```
+
+`version`
+
+: The current version of a cookbook. Version numbers always follow a simple three-number version sequence.
+
+ For example:
+
+ ```ruby
+ version '2.0.0'
+ ```
diff --git a/content/config_rb_policyfile.md b/content/config_rb_policyfile.md
new file mode 100644
index 0000000..72269b7
--- /dev/null
+++ b/content/config_rb_policyfile.md
@@ -0,0 +1,36 @@
++++
+title = "Policyfile.rb"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/config_rb_policyfile.html"]
+product = ["client", "server"]
+
+[menu]
+ [menu.infra]
+ title = "Policyfile.rb"
+ identifier = "chef_infra/policyfiles/config_rb_policyfile.md Policyfile.rb Configuration"
+ parent = "chef_infra/policyfiles"
+ weight = 30
++++
+
+{{< readfile file="content/reusable/md/policyfile_summary.md" >}}
+
+{{< readfile file="content/reusable/md/policyfile_rb.md" >}}
+
+{{< note >}}
+
+For more information, see the [Policyfile documentation](/policyfile/).
+
+{{< /note >}}
+
+## Syntax
+
+{{< readfile file="content/reusable/md/policyfile_rb_syntax.md" >}}
+
+## Settings
+
+{{< readfile file="content/reusable/md/policyfile_rb_settings.md" >}}
+
+## Example
+
+{{< readfile file="content/reusable/md/policyfile_rb_example.md" >}}
diff --git a/content/config_rb_solo.md b/content/config_rb_solo.md
new file mode 100644
index 0000000..ada58ad
--- /dev/null
+++ b/content/config_rb_solo.md
@@ -0,0 +1,175 @@
++++
+title = "solo.rb"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+aliases = ["/config_rb_solo.html"]
+
+[menu]
+ [menu.infra]
+ title = "solo.rb"
+ identifier = "chef_infra/features/chef_solo/config_rb_solo.md solo.rb Configuration"
+ parent = "chef_infra/features/chef_solo"
+ weight = 30
++++
+
+A solo.rb file is used to specify the configuration details for
+chef-solo.
+
+- This file is loaded every time this executable is run
+- The default location in which chef-solo expects to find this file is `/etc/chef/solo.rb`; use the `--config` option from the command line to change this location
+- This file isn't created by default
+- When a `solo.rb` file is present in this directory, the settings contained within that file will override the default configuration settings
+
+## Settings
+
+This configuration file has the following settings:
+
+`add_formatter`
+
+: A 3rd-party formatter. (See [nyan-cat](https://github.com/andreacampi/nyan-cat-chef-formatter) for an example of a 3rd-party formatter.) Each formatter requires its own entry.
+
+`checksum_path`
+
+: The location in which checksum files are stored. These are used to validate individual cookbook files, such as recipes. The checksum itself is stored in the Chef Infra Server database and is then compared to a file in the checksum path that has a filename identical to the checksum.
+
+`cookbook_path`
+
+: The Chef Infra Client sub-directory for cookbooks. This value can be a string or an array of file system locations, processed in the specified order. The last cookbook is considered to override local modifications.
+
+`data_bag_path`
+
+: The location from which a data bag is loaded. Default value: `/var/chef/data_bags`.
+
+`environment`
+
+: The name of the environment.
+
+`environment_path`
+
+: The path to the environment. Default value: `/var/chef/environments`.
+
+`file_backup_path`
+
+: The location in which backup files are stored. If this value is empty, backup files are stored in the directory of the target file. Default value: `/var/chef/backup`.
+
+`file_cache_path`
+
+: The location in which cookbooks (and other transient data) files are stored when they're synchronized. This value can also be used in recipes to download files with the **remote_file** resource.
+
+`json_attribs`
+
+: The path to a file that contains JSON data.
+
+`lockfile`
+
+: The location of the Chef Infra Client lock file. This value is typically platform-dependent, so should be a location defined by `file_cache_path`. The default location of a lock file shouldn't on an NF mount. Default value: a location defined by `file_cache_path`.
+
+`log_level`
+
+: The level of logging to be stored in a log file. Possible levels: `:auto` (default), `debug`, `info`, `warn`, `error`, or `fatal`.
+
+`log_location`
+
+: The location of the log file. Default value: `STDOUT`.
+
+`minimal_ohai`
+
+: Run the Ohai plugins for name detection and resource/provider selection and no other Ohai plugins. Set to `true` during integration testing to speed up test cycles.
+
+`node_name`
+
+: The unique identifier of the node.
+
+`recipe_url`
+
+: The URL location from which a remote cookbook tar.gz is to be downloaded.
+
+`rest_timeout`
+
+: The time (in seconds) after which an HTTP REST request is to time out. Default value: `300`.
+
+`role_path`
+
+: The location in which role files are located. Default value: `/var/chef/roles`.
+
+`run_lock_timeout`
+
+: The amount of time (in seconds) to wait for a Chef Infra Client lock file to be deleted. A Chef Infra Client run won't start when a lock file is present. If a lock file isn't deleted before this time expires, the pending Chef Infra Client run will exit. Default value: not set (indefinite). Set to `0` to cause a second Chef Infra Client to exit immediately.
+
+`sandbox_path`
+
+: The location in which cookbook files are stored (temporarily) during upload.
+
+`solo`
+
+: Run Chef Infra Client in chef-solo mode. This setting determines if Chef Infra Client is to attempt to communicate with the Chef Infra Server. Default value: `false`.
+
+`syntax_check_cache_path`
+
+: All files in a cookbook must contain valid Ruby syntax. Use this setting to specify the location in which knife caches information about files that have been checked for valid Ruby syntax.
+
+`umask`
+
+: The file mode creation mask, or umask. Default value: `0022`.
+
+`verbose_logging`
+
+: Set the log level. Options: `true`, `nil`, and `false`. When this is set to `false`, notifications about individual resources being processed are suppressed (and are output at the `:info` logging level). Setting this to `false` can be useful when a Chef Infra Client is run as a daemon. Default value: `nil`.
+
+## Examples
+
+### Using Chef Automate Data Collector
+
+This example solo.rb file uses the `data_collector` settings to send data to an available Chef Automate system. Since Chef Automate generates a self-signed SSL certificate by default, you will need to add the certificate (located under `/var/opt/delivery/nginx/` on the Chef Automate server) to your `trusted_certs_dir` directory, as seen in this example:
+
+```ruby
+chef_server_url "https://localhost:8989"
+log_location STDOUT
+node_name "YOUR_NODES_FQDN"
+trusted_certs_dir "/etc/chef/trusted_certs"
+
+data_collector.server_url "https://YOUR_AUTOMATE_FQDN/data-collector/v0"
+data_collector.mode :both
+data_collector.token = "YOURTOKEN"
+```
+
+You can run it like this
+
+```ruby
+chef-solo -c solo.rb
+```
+
+### All Options
+
+A sample solo.rb file that contains all possible settings (listed alphabetically):
+
+```ruby
+add_formatter :nyan
+add_formatter :foo
+add_formatter :bar
+checksum_path '/var/chef/checksums'
+cookbook_path [
+ '/var/chef/cookbooks',
+ '/var/chef/site-cookbooks'
+ ]
+data_bag_path '/var/chef/data_bags'
+environment 'production'
+environment_path '/var/chef/environments'
+file_backup_path '/var/chef/backup'
+file_cache_path '/var/chef/cache'
+json_attribs nil
+lockfile nil
+log_level :info
+log_location STDOUT
+node_name 'mynode.example.com'
+recipe_url 'http://path/to/remote/cookbook'
+rest_timeout 300
+role_path '/var/chef/roles'
+sandbox_path 'path_to_folder'
+solo false
+syntax_check_cache_path
+umask 0022
+verbose_logging nil
+```
diff --git a/content/cookbook_repo.md b/content/cookbook_repo.md
new file mode 100644
index 0000000..c8632fe
--- /dev/null
+++ b/content/cookbook_repo.md
@@ -0,0 +1,134 @@
++++
+title = "Get Started"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/cookbook_repo.html"]
+product = ["client", "server", "workstation"]
+
+[menu]
+ [menu.infra]
+ title = "Cookbook Directory"
+ identifier = "chef_infra/cookbook_reference/cookbook_repo.md Cookbook Repo"
+ parent = "chef_infra/cookbook_reference"
+ weight = 20
++++
+
+The `cookbooks/` directory of your Chef Infra repository is used to
+store the cookbooks that Chef Infra Client uses in configuring the
+various systems in the organization.
+
+## Chef Repository
+
+The the `\cookbook` directory is automatically generated as part of your Chef Infra repository.
+
+```bash
+chef generate repo REPO_NAME
+```
+
+### Cookbook Directory Structure
+
+The default structure of the cookbooks directory is:
+
+```plain
+. chef-repo
+└── cookbooks
+ ├── README.md
+ └── example
+ ├── README.md
+ ├── attributes
+ │ ├── README.md
+ │ └── default.rb
+ ├── metadata.rb
+ └── recipes
+ ├── README.md
+ └── default.rb
+```
+
+## Cookbook Commands
+
+Use the following commands to create a cookbook, install a cookbook from Supermarket, and/or download cookbooks.
+
+### Create
+
+Chef Workstation generates the `cookbooks` directory as part of your Chef Infra repository, the `chef-repo`.
+
+Generate a `chef-repo/cookbooks` directory with the command:
+
+```bash
+chef generate template PATH_TO_COOKBOOKS COOKBOOK_NAME
+```
+
+For example, this command generates a `custom_web` cookbook:
+
+```bash
+chef generate cookbook cookbooks/custom_web
+```
+
+The `custom_web` cookbook directory has the structure:
+
+```text
+. cookbooks
+└── custom_web
+ ├── CHANGELOG.md
+ ├── LICENSE
+ ├── Policyfile.rb
+ ├── README.md
+ ├── chefignore
+ ├── compliance
+ │ ├── README.md
+ │ ├── inputs
+ │ ├── profiles
+ │ └── waivers
+ ├── kitchen.yml
+ ├── metadata.rb
+ ├── recipes
+ │ └── default.rb
+ └── test
+ └── integration
+ └── default
+ └── default_test.rb
+```
+
+Any unneeded directory components can be left unused or deleted, if
+preferred.
+
+### Install
+
+To download a cookbook when git is used for version source control, run
+the following command:
+
+```bash
+knife supermarket install COOKBOOK_NAME
+```
+
+where `COOKBOOK_NAME` is the name of a cookbook on [Chef
+Supermarket](https://supermarket.chef.io/). This will start a process
+that:
+
+- downloads the cookbook from [Chef
+ Supermarket](https://supermarket.chef.io/) as a tar.gz archive
+- ensures that its using the git master branch, and then checks out
+ the cookbook from a vendor branch (creating a new vendor branch, if
+ required)
+- removes the old (existing) version
+- expands the tar.gz archive and adds the expanded files to the git
+ index and commits
+- creates a tag for the version that was downloaded
+- checks out the master branch
+- merges the cookbook into the master (to ensure that any local
+ changes or modifications are preserved)
+
+### Download
+
+To download a cookbook when git isn't used for version source control,
+run the following command:
+
+```bash
+knife supermarket download COOKBOOK_NAME
+```
+
+where `COOKBOOK_NAME` is the name of a cookbook on [Chef
+Supermarket](https://supermarket.chef.io/). This will download the
+tar.gz file associated with the cookbook and will create a file named
+`COOKBOOK_NAME.tar.gz` in the current directory (`~/chef-repo`).
+Once downloaded, using a version source control system is recommended.
diff --git a/content/cookbook_versioning.md b/content/cookbook_versioning.md
new file mode 100644
index 0000000..3294285
--- /dev/null
+++ b/content/cookbook_versioning.md
@@ -0,0 +1,323 @@
++++
+title = "About Cookbook Versioning"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/cookbook_versioning.html", "/cookbook_versions.html"]
+product = ["client", "server", "workstation"]
+
+[menu]
+ [menu.infra]
+ title = "Versioning Cookbooks"
+ identifier = "chef_infra/cookbook_reference/cookbook_versioning.md Versioning Cookbooks"
+ parent = "chef_infra/cookbook_reference"
+ weight = 150
++++
+
+{{< readfile file="content/reusable/md/cookbooks_version.md" >}}
+
+## Syntax
+
+A cookbook version always takes the form x.y.z, where x, y, and z are
+decimal numbers that are used to represent major (x), minor (y), and
+patch (z) versions. A two-part version (x.y) is also allowed.
+Alphanumeric version numbers (1.2.a3) and version numbers with more than
+three parts (1.2.3.4) aren't allowed.
+
+## Constraints
+
+A version constraint is a string that combines the cookbook version
+syntax with an operator, in the following format:
+
+```ruby
+operator cookbook_version_syntax
+```
+
+{{< note >}}
+
+Single digit cookbook versions aren't allowed. Cookbook versions must
+specify at least the major and minor version. For example, use `1.0` or
+`1.0.1`; don't use `1`.
+
+{{< /note >}}
+
+{{< readfile file="content/reusable/md/cookbooks_version_constraints_operators.md" >}}
+
+For example, a version constraint for "equals version 1.0.7" is
+expressed like this:
+
+```ruby
+= 1.0.7
+```
+
+A version constraint for "greater than version 1.0.2" is expressed like
+this:
+
+```ruby
+> 1.0.2
+```
+
+An optimistic version constraint is one that looks for versions greater
+than or equal to the specified version. For example:
+
+```ruby
+>= 2.6.5
+```
+
+will match cookbooks greater than or equal to 2.6.5, such as 2.6.5,
+2.6.7 or 3.1.1.
+
+A pessimistic version constraint is one that will find the upper limit
+version number within the range specified by the minor version number or
+patch version number. For example, a pessimistic version constraint for
+minor version numbers:
+
+```ruby
+~> 2.6
+```
+
+will match cookbooks that are greater than or equal to version 2.6, but
+less than version 3.0.
+
+Or, a pessimistic version constraint for patch version numbers:
+
+```ruby
+~> 2.6.5
+```
+
+will match cookbooks that are greater than or equal to version 2.6.5,
+but less than version 2.7.0.
+
+Or, a pessimistic version constraint that matches cookbooks less than a
+version number:
+
+```ruby
+< 2.3.4
+```
+
+or will match cookbooks less than or equal to a specific version number:
+
+```ruby
+<= 2.6.5
+```
+
+## Metadata
+
+{{< readfile file="content/reusable/md/cookbooks_metadata.md" >}}
+
+Versions and version constraints can be specified in a cookbook's
+metadata.rb file by using the following functions. Each function accepts
+a name and an optional version constraint; if a version constraint is
+not provided, `>= 0.0.0` is used as the default.
+
+
+
+
+
+
+
+
+
Function
+
Description
+
+
+
+
+
depends
+
Show that a cookbook has a dependency on another cookbook. Use a version constraint to define dependencies for cookbook versions: < (less than), <= (less than or equal to), = (equal to), >= (greater than or equal to; also known as "optimistically greater than", or "optimistic"), ~> (approximately greater than; also known as "pessimistically greater than", or "pessimistic"), or > (greater than). This field requires that a cookbook with a matching name and version exists on the Chef Infra Server. When the match exists, the Chef Infra Server includes the dependency as part of the set of cookbooks that are sent to the node when Chef Infra Client runs. It's important that the depends field contain accurate data. If a dependency statement is inaccurate, Chef Infra Client may not be able to complete the configuration of the system. For example:
+
depends 'opscode-base'
+
or:
+
depends 'opscode-github', '> 1.0.0'
+
or:
+
depends 'runit', '~> 1.2.3'
+
+
+
provides
+
Add a recipe, definition, or resource that's provided by this cookbook, should the populated list be insufficient.
+
+
+
supports
+
Show that a cookbook has a supported platform. Use a version constraint to define dependencies for platform versions: < (less than), <= (less than or equal to), = (equal to), >= (greater than or equal to), ~> (approximately greater than), or > (greater than). To specify more than one platform, use more than one supports field, once for each platform.
+
+
+
+
+## Environments
+
+An environment can use version constraints to specify a list of allowed
+cookbook versions by specifying the cookbook's name, along with the
+version constraint. For example:
+
+```ruby
+cookbook 'apache2', '~> 1.2.3'
+```
+
+Or:
+
+```ruby
+cookbook 'runit', '= 4.2.0'
+```
+
+If a cookbook isn't explicitly given a version constraint the
+environment will assume the cookbook has no version constraint and will
+use any version of that cookbook with any node in the environment.
+
+## Freeze Versions
+
+A cookbook version can be frozen, which will prevent updates from being
+made to that version of a cookbook. (A user can always upload a new
+version of a cookbook.) Using cookbook versions that are frozen within
+environments is a reliable way to keep a production environment safe
+from accidental updates while testing changes that are made to a
+development infrastructure.
+
+For example, to freeze a cookbook version using knife, enter:
+
+```bash
+knife cookbook upload redis --freeze
+```
+
+To return:
+
+```bash
+Uploading redis...
+Upload completed
+```
+
+Once a cookbook version is frozen, only by using the `--force` option
+can an update be made. For example:
+
+```bash
+knife cookbook upload redis --force
+```
+
+Without the `--force` option specified, an error will be returned
+similar to:
+
+```bash
+Version 0.0.0 of cookbook redis is frozen. Use --force to override
+```
+
+## Managing Many Cookbook Versions
+
+{{< warning >}}
+
+If you continually upload all versions of many cookbooks to your Chef Infra Server, you may overload the Chef Infra Server's dependency solver, causing it to time out and leading to a failed Chef Infra Client run.
+
+There are three solutions to this problem:
+
+- use [Policyfiles](/policyfile/) (recommended)
+- place version constraints on all cookbooks and all dependencies of all cookbooks in any run list you use for a Chef Infra Client run
+- upload only the required cookbook versions to a Chef Infra Server
+
+{{< /warning >}}
+
+In a CI/CD workflow where new cookbook versions are continually uploaded to a Chef Infra Server, the Chef Infra Server dependency solver must look at more and more cookbook versions while trying to solve the constraints given to it from the run list of each Chef Infra Client that starts up. Eventually, it runs out of time to produce a solution, times out, and the Chef Infra Client run fails as a result. The Chef Infra Server may also pick older cookbook versions than the versions that you intended.
+
+The dependency solver workers in a Chef Infra Server have a default timeout of five seconds. The solution isn't to increase their timeout, but to control the problem so that the dependency solvers can solve it in a reasonable amount of time.
+
+### Policyfiles
+
+The current best practice is to control cookbook versions through Policyfiles. In this way, the dependency resolution is shifted left to the cookbook author designing the cookbook, its dependency structure, and the needed versions of all involved cookbooks. See the [Policyfiles](/policyfile/) documentation for more information.
+
+### Version Constraints
+
+In a CI/CD environment where you have many versions of cookbooks, place version constraints on all cookbooks and all dependencies of all cookbooks in any run list you use for a Chef Infra Client run.
+
+The way to control the problem traditionally is by pinning the versions of cookbooks in an environment file or by using a wrapper cookbook that calls out the dependencies AND their versions in its `metadata.rb` file, and the dependencies do the same in their own `metadata.rb` files. See the [Cookbook Metadata Files](/config_rb_metadata/) for more information.
+
+### Minimum Number of Cookbook Versions
+
+The dependency solver will also work properly if you upload the minimum number of cookbook versions needed to the Chef Infra Server.
+
+You can make a start at this by only uploading tested and blessed cookbook versions to your Chef Infra Server. These cookbooks would be ones where each scenario or role for the nodes is considered and that small set of cookbook versions are made available for those sets of nodes. Before Policyfiles, this policy could be implemented by constraining dependency solver access to candidate versions using an [environment]({{< relref "environments" >}}) file.
+
+## Version Source Control
+
+There are two strategies to consider when using version control as part
+of the cookbook management process:
+
+- Use maximum version control when it's important to keep every bit of data within version control
+- Use branch tracking when cookbooks are being managed in separate environments using git branches and the versioning policy information is already stored in a cookbook's metadata.
+
+### Branch Tracking
+
+Using a branch tracking strategy requires that a branch for each
+environment exists in the source control and that each cookbook's
+versioning policy is tracked at the branch level. This approach is
+relatively simple and lightweight: for development environments that
+track the latest cookbooks, just bump the version before a cookbook is
+uploaded for testing. For any cookbooks that require higher levels of
+version control, knife allows cookbooks to be uploaded to specific
+environments and for cookbooks to be frozen (which prevents others from
+being able to make changes to that cookbook).
+
+The typical workflow with a branch tracking version control strategy
+includes:
+
+1. Bumping the version number as appropriate.
+2. Making changes to a cookbook.
+3. Uploading and testing a cookbook.
+4. Moving a tested cookbook to production.
+
+For example, to bump a version number, first make changes to the
+cookbook, and then upload and test it. Repeat this process as required,
+and then upload it using a knife command similar to:
+
+```bash
+knife cookbook upload my-app
+```
+
+When the cookbook is finished, move those changes to the production
+environment and use the `--freeze` option to prevent others from making
+further changes:
+
+```bash
+knife cookbook upload my-app -E production --freeze
+```
+
+### Maximum Versions
+
+Using a maximum version control strategy is required when everything
+needs to be tracked in source control. This approach is similar to
+a branch tracking strategy while the cookbook is in development and
+being tested, but is more complicated and time-consuming (and requires
+file-level editing for environment data) to get the cookbook
+deployed to a production environment.
+
+The typical workflow with a maximum version control strategy includes:
+
+1. Bumping the version number as appropriate.
+2. Making changes to a cookbook.
+3. Uploading and testing a cookbook.
+4. Moving a tested cookbook to production.
+
+For example, to bump a version number, first make changes to the
+cookbook, and then upload and test it. Repeat this process as required,
+and then upload it using a knife command similar to:
+
+```bash
+knife cookbook upload my-app
+```
+
+When the cookbook is finished, move those changes to the production
+environment and use the `--freeze` option to prevent others from making
+further changes:
+
+```bash
+knife cookbook upload my-app -E production --freeze
+```
+
+Then modify the environment so that it prefers the newly uploaded
+version:
+
+```bash
+(vim|emacs|mate|ed) YOUR_REPO/environments/production.rb
+```
+
+Upload the updated environment:
+
+```bash
+knife environment from file production.rb
+```
+
+And then deploy the new cookbook version.
diff --git a/content/cookbooks.md b/content/cookbooks.md
index 59c5262..41f95db 100644
--- a/content/cookbooks.md
+++ b/content/cookbooks.md
@@ -1,8 +1,78 @@
+++
-title = "Sample cookbook"
+title = "About Cookbooks"
+draft = false
-[menu.cookbooks]
-title = "Sample cookbook"
+gh_repo = "chef-web-docs"
+
+aliases = ["/cookbooks.html", "/essentials_cookbooks.html"]
+product = ["client", "server", "workstation"]
+
+[menu]
+ [menu.infra]
+ title = "About Cookbooks"
+ identifier = "chef_infra/cookbook_reference/cookbooks.md About Cookbooks"
+ parent = "chef_infra/cookbook_reference"
+ weight = 10
+++
-You can test Chef Infra Client 19 RC3 using a basic cookbook in the [infra-19-rc1-examples](https://github.com/chef/infra-19-rc1-examples/) repository. This includes a recipe that allows you to test Agentless Mode.
+{{< readfile file="content/reusable/md/cookbooks_summary.md" >}}
+
+{{< readfile file="content/reusable/md/infra_lang_ruby.md" >}}
+
+{{< readfile file="content/reusable/md/infra_lang_summary.md" >}}
+
+Chef Infra Client runs a recipe only when instructed. When Chef Infra Client runs the same recipe more than once, the results will be the same system state each time. When a recipe is run against a system, but nothing has changed on either the system or in the recipe, Chef Infra Client won't change anything.
+
+## Components
+
+A cookbook is comprised of recipes and other optional components as files or directories.
+
+| Component | File/Directory Name | Description |
+|----------------------------------------|---------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| [Recipes](/recipes/) | recipes/ | {{< readfile file="content/reusable/md/cookbooks_recipe.md" >}} |
+| [Attributes](/attributes/) | attributes/ | {{< readfile file="content/reusable/md/cookbooks_attribute.md" >}} |
+| [Files](/files/) | files/ | A file distribution is a specific type of resource that tells a cookbook how to distribute files, including by node, by platform, or by file version. |
+| [Libraries](/libraries/) | libraries/ | A library allows the use of arbitrary Ruby code in a cookbook, either as a way to extend the Chef Infra Client language or to implement a new class. |
+| [Custom Resources](/custom_resources/) | resources/ | A custom resource is an abstract approach for defining a set of actions and (for each action) a set of properties and validation parameters. |
+| [Templates](/templates/) | templates/ | A template is a file written in markup language that uses Ruby statements to solve complex configuration scenarios. |
+| [Ohai Plugins](/ohai_custom/) | ohai/ | Custom Ohai plugins can be written to load additional information about your nodes to be used in recipes. This requires Chef Infra Server 12.18.14 or later. |
+| [Metadata](/config_rb_metadata/) | metadata.rb | This file contains information about the cookbook such as the cookbook name, description, and version. |
+
+## Community Cookbooks
+
+Chef maintains a large collection of cookbooks. In addition, there are thousands of cookbooks created and maintained by the community:
+
+| Components | Description |
+|:------------------------------------------------------------------------------:|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------:|
+| [Cookbooks Maintained by Chef](https://github.com/chef-cookbooks) | Chef maintains a collection of cookbooks that are widely used by the community. |
+| [Cookbooks Maintained by Sous Chefs](https://github.com/sous-chefs) | Sous Chefs is a community organization that collaborates to maintain many of the most used Chef cookbooks. |
+| [Cookbooks Maintained by the Community](https://supermarket.chef.io/cookbooks) | The community has authored thousands of cookbooks, ranging from niche cookbooks that are used by only a few organizations to popular cookbooks used by almost everyone. |
+
+## Generate a Cookbook
+
+Use the [chef generate cookbook subcommand](/workstation/ctl_chef/#chef-generate-cookbook) to generate a cookbook.
+
+A cookbook generated with`chef generate cookbook custom_web` creates a cookbook named `custom_web` with the directory structure:
+
+```text
+. cookbooks
+└── custom_web
+ ├── CHANGELOG.md
+ ├── LICENSE
+ ├── Policyfile.rb
+ ├── README.md
+ ├── chefignore
+ ├── compliance
+ │ ├── README.md
+ │ ├── inputs
+ │ ├── profiles
+ │ └── waivers
+ ├── kitchen.yml
+ ├── metadata.rb
+ ├── recipes
+ │ └── default.rb
+ └── test
+ └── integration
+ └── default
+ └── default_test.rb
+```
diff --git a/content/ctl_chef_client.md b/content/ctl_chef_client.md
new file mode 100644
index 0000000..7afccd6
--- /dev/null
+++ b/content/ctl_chef_client.md
@@ -0,0 +1,898 @@
++++
+title = "Chef Infra Client (executable)"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+aliases = ["/ctl_chef_client.html"]
+
+[menu]
+ [menu.infra]
+ title = "chef-client (executable)"
+ identifier = "chef_infra/reference/ctl_chef_client.md chef-client Commands"
+ parent = "chef_infra/reference"
+ weight = 10
++++
+
+{{< readfile file="content/reusable/md/chef_client_summary.md" >}}
+
+{{< note >}}
+
+The Chef Infra Client executable can be run as a daemon.
+
+{{< /note >}}
+
+The Chef Infra Client executable is run as a command-line tool.
+
+{{< note >}}
+
+{{< readfile file="content/reusable/md/config_rb_client_summary.md" >}}
+
+{{< /note >}}
+
+## Options
+
+This command has the following syntax:
+
+```bash
+chef-client OPTION VALUE OPTION VALUE ...
+```
+
+This command has the following options:
+
+`-A`, `--fatal-windows-admin-check`
+
+: Cause a Chef Infra Client run to fail when the Chef Infra Client doesn't have administrator privileges in Windows.
+
+`-c CONFIG`, `--config CONFIG`
+
+: The configuration file to use.
+
+`--config-option OPTION`
+
+: Overrides a single configuration option. Can be used to override multiple configuration options by adding another `--config-option OPTION`.
+
+`--chef-zero-host HOST`
+
+: The host on which chef-zero is started.
+
+`--chef-zero-port PORT`
+
+: The port on which chef-zero listens. If a port isn't specified---individually, as range of ports, or from the `chef_zero.port` setting in the client.rb file---the Chef Infra Client will scan for ports between 8889-9999 and will pick the first port that's available.
+
+`-d SECONDS`, `--daemonize SECONDS`
+
+: Run the executable as a daemon. Use `SECONDS` to specify the number of seconds to wait before the first daemonized Chef Infra Client run. `SECONDS` is set to `0` by default. Left unset, the daemon uses the default `--interval` an `--splay` values.
+
+ This option is only available on machines that run in UNIX or Linux environments. For machines that are running Windows that require similar functionality, use the `chef-client::service` recipe in the `chef-client` cookbook: . This will install a Chef Infra Client service under Windows using the Windows Service Wrapper.
+
+`--delete-entire-chef-repo`
+
+: This option deletes an entire repository. This option may only be used when running the Chef Infra Client in local mode, (`--local-mode`). This option requires `--recipe-url` to be specified.
+
+`--disable-config`
+
+: Use to run the Chef Infra Client using default settings. This will prevent the normally-associated configuration file from being used. This setting should only be used for testing purposes and should never be used in a production setting.
+
+`-E ENVIRONMENT_NAME`, `--environment ENVIRONMENT_NAME`
+
+: The name of the environment.
+
+`-f`, `--[no-]fork`
+
+: Contain Chef Infra Client runs in a secondary process with dedicated RAM. When a Chef Infra Client run is complete, the RAM is returned to the master process. This option helps ensure that a Chef Infra Client uses a steady amount of RAM over time because the master process doesn't run recipes. This option also helps prevent memory leaks such as those that can be introduced by the code contained within a poorly designed cookbook. Use `--no-fork` to disable running Chef Infra Client in fork node. Default value: `--fork`.
+
+`-F FORMAT`, `--format FORMAT`
+
+: {{< readfile file="content/workstation/reusable/md/ctl_chef_client_options_format.md" >}}
+
+`--force-formatter`
+
+: Show formatter output instead of logger output.
+
+`--force-logger`
+
+: Show logger output instead of formatter output.
+
+`-g GROUP`, `--group GROUP`
+
+: The name of the group that owns a process. This is required when starting any executable as a daemon.
+
+`-h`, `--help`
+
+: Show help for the command.
+
+`-i SECONDS`, `--interval SECONDS`
+
+: The frequency (in seconds) at which Chef Infra Client runs. When running Chef Infra Client at intervals, apply `--splay` and `--interval` values before a Chef Infra Client run. Default value: `1800`.
+
+`-j PATH`, `--json-attributes PATH`
+
+: The path to a file that contains JSON data. Used to setup the first client run. The attributes will persist on the Chef Infra Server for all future runs with option `-j`.
+
+ **Run-lists**
+
+ {{< readfile file="content/reusable/md/node_ctl_run_list.md" >}}
+
+ **Environments**
+
+ Use this option to set the `chef_environment` value for a node.
+
+ {{< note >}}
+
+ Any environment specified for `chef_environment` by a JSON file will take precedence over an environment specified by the `--environment` option when both options are part of the same command.
+
+ {{< /note >}}
+
+ For example, run the following:
+
+ ```bash
+ chef-client -j /path/to/file.json
+ ```
+
+ where `/path/to/file.json` is similar to:
+
+ ```json
+ {
+ "chef_environment": "pre-production"
+ }
+ ```
+
+ This will set the environment for the node to `pre-production`.
+
+ **All attributes are normal attributes**
+
+ {{< readfile file="content/reusable/md/node_ctl_attribute.md" >}}
+
+ {{< note >}}
+
+ This has set the `normal` attribute
+ `node['override_attributes']['apptastic']`.
+
+ {{< /note >}}
+
+ **Specify a policy**
+
+ Use this option to use Policyfiles by specifying a JSON file that
+ contains the following settings:
+
+
+
+
+
+
+
+
+
Setting
+
Description
+
+
+
+
+
policy_group
+
The name of a policy group that exists on the Chef Infra Server.
+
+
+
policy_name
+
The name of a policy, as identified by the name setting in a Policyfile.rb file.
+
+
+
+
+ For example:
+
+ ```json
+ {
+ "policy_name": "appserver",
+ "policy_group": "staging"
+ }
+ ```
+
+`-k KEY_FILE`, `--client_key KEY_FILE`
+
+: The location of the file that contains the client key. Default
+ value: `/etc/chef/client.pem`.
+
+`-K KEY_FILE`, `--validation_key KEY_FILE`
+
+: The location of the file that contains the key used when a Chef
+ Infra Client is registered with a Chef Infra Server. A validation
+ key is signed using the `validation_client_name` for authentication.
+ Default value: `/etc/chef/validation.pem`.
+
+`-l LEVEL`, `--log_level LEVEL`
+
+: The level of logging to be stored in a log file. Possible levels:
+ `auto` (default), `debug`, `error`, `fatal`, `info`, `trace`, or `warn`.
+ Default value: `warn` (when a terminal is available) or `info` (when
+ a terminal isn't available).
+
+`-L LOGLOCATION`, `--logfile LOGLOCATION`
+
+: The location of the log file. This is recommended when starting any
+ executable as a daemon. Default value: `STDOUT`.
+
+`--lockfile LOCATION`
+
+: Use to specify the location of the lock file, which prevents
+ multiple Chef Infra Client processes from converging at the same
+ time.
+
+`--minimal-ohai`
+
+: Run the Ohai plugins for name detection and resource/provider
+ selection and no other Ohai plugins. Set to `true` during
+ integration testing to speed up test cycles.
+
+`--[no-]color`
+
+: View colored output. Default setting: `--color`.
+
+`--[no-]fips`
+
+: Allows OpenSSL to enforce FIPS-validated security during a Chef
+ Infra Client run.
+
+`--[no-]skip-cookbook-sync`
+
+: Not recommended. Use cached cookbooks without overwriting local differences from the server. Useful for patching a set of cookbooks on a machine when iterating during development. This option can cause unanticipated behavior.
+
+`--[no-]listen`
+
+: Run chef-zero in socketless mode. **This is the default behavior on
+ Chef Infra Client 13.1 and above.**
+
+`-n NAME`, `--named-run-list NAME`
+
+: The run-list associated with a Policyfile.
+
+`-N NODE_NAME`, `--node-name NODE_NAME`
+
+: The unique identifier of the node.
+
+`-o RUN_LIST_ITEM`, `--override-runlist RUN_LIST_ITEM`
+
+: Replace the current run-list with the specified items. This option
+ won't clear the list of cookbooks (and related files) that's
+ cached on the node. This option won't persist node data at the
+ end of the client run.
+
+`--once`
+
+: Make only one Chef Infra Client run and cancel `interval` and
+ `splay` options.
+
+`-P PID_FILE`, `--pid PID_FILE`
+
+: The location in which a process identification number (pid) is
+ saved. An executable, when started as a daemon, writes the pid to
+ the specified file. Default value: `/tmp/name-of-executable.pid`.
+
+`--profile-ruby`
+
+: Use the `--profile-ruby` option to dump a (large) profiling graph
+ into `/var/chef/cache/graph_profile.out`. Use the graph output to
+ help identify, and then resolve performance bottlenecks in a Chef
+ Infra Client run. This option:
+
+ - Generates a large amount of data about a Chef Infra Client run.
+ - Has a dependency on the `ruby-prof` gem, which is packaged as
+ part of Chef and Chef Workstation.
+ - Increases the amount of time required to complete a Chef Infra
+ Client run.
+ - Should not be used in a production environment.
+
+`-r RUN_LIST_ITEM`, `--runlist RUN_LIST_ITEM`
+
+: Permanently replace the current run-list with the specified run-list
+ items.
+
+`-R`, `--enable-reporting`
+
+: Enable Reporting, which performs data collection during a Chef Infra
+ Client run.
+
+`RECIPE_FILE`
+
+: The path to a recipe. For example, if a recipe file is in the
+ current directory, use `recipe_file.rb`. This is typically used with
+ the `--local-mode` option.
+
+`--recipe-url=RECIPE_URL`
+
+: The location of a recipe when it exists at a URL. Use this option
+ only when running Chef Infra Client with the `--local-mode` option.
+
+`--run-lock-timeout SECONDS`
+
+: The amount of time (in seconds) to wait for a Chef Infra Client lock
+ file to be deleted. Default value: not set (indefinite). Set to `0`
+ to cause a second Chef Infra Client to exit immediately.
+
+`-s SECONDS`, `--splay SECONDS`
+
+: A random number between zero and `splay` that's added to
+ `interval`. Use splay to help balance the load on the Chef Infra
+ Server by ensuring that many Chef Infra Client runs aren't
+ occurring at the same interval. When running Chef Infra Client at
+ intervals, apply `--splay` and `--interval` values before a Chef
+ Infra Client run.
+
+ Changed in Chef Infra Client 12.0 to be applied before the Chef Infra Client
+ run.
+
+`-S CHEF_SERVER_URL`, `--server CHEF_SERVER_URL`
+
+: The URL for the Chef Infra Server.
+
+`-u USER`, `--user USER`
+
+: The user that owns a process. This is required when starting any
+ executable as a daemon.
+
+`-v`, `--version`
+
+: The Chef Infra Client version.
+
+`-W`, `--why-run`
+
+: Run the executable in why-run mode, which is a type of Chef Infra
+ Client run that does everything except modify the system. Use
+ why-run mode to understand why the Chef Infra Client makes the
+ decisions that it makes and to learn more about the current and
+ proposed state of the system.
+
+`-z`, `--local-mode`
+
+: Run the Chef Infra Client in local mode. This allows all commands
+ that work against the Chef Infra Server to also work against the
+ local chef-repo.
+
+### Chef Infra Client Lock File
+
+The Chef Infra Client uses a lock file to ensure that only one Chef
+Infra Client run is in progress at any time. A lock file is created at
+the start of a Chef Infra Client run and is deleted at the end of a Chef
+Infra Client run. A new Chef Infra Client run looks for the presence of
+a lock file and, if present, will wait for that lock file to be deleted.
+The location of the lock file can vary by platform.
+
+- Use the `lockfile` setting in the client.rb file to specify
+ non-default locations for the lock file. (The default location is
+ typically platform-dependent and is recommended.)
+- Use the `run_lock_timeout` setting in the client.rb file to specify
+ the amount of time (in seconds) to wait for the lock file associated
+ with an in-progress Chef Infra Client run to be deleted.
+
+## Run in Local Mode
+
+Local mode is a way to run the Chef Infra Client against the chef-repo
+on a local machine as if it were running against the Chef Infra Server.
+Local mode relies on chef-zero, which acts as a lightweight
+instance of the Chef Infra Server. chef-zero reads and writes to the
+`chef_repo_path`, which allows all commands that normally work against
+the Chef Infra Server to be used against the local chef-repo.
+
+Local mode doesn't require a configuration file, instead it will look
+for a directory named `/cookbooks` and will set `chef_repo_path` to be
+just above that. (Local mode will honor the settings in a configuration
+file, if desired.) If the client.rb file isn't found and no
+configuration file is specified, local mode will search for a config.rb
+file.
+
+Local mode will store temporary and cache files under the
+`/.cache` directory by default. This allows a normal
+user to run the Chef Infra Client in local mode without requiring root
+access.
+
+### About why-run Mode
+
+why-run mode is a way to see what Chef Infra Client would have
+configured, had an actual Chef Infra Client run occurred. This approach
+is similar to the concept of "no-operation" (or "no-op"): decide what
+should be done, but then don't actually do anything until it's done
+right. This approach to configuration management can help identify where
+complexity exists in the system, where inter-dependencies may be
+located, and to verify that everything will be configured in the desired
+manner.
+
+When why-run mode is enabled, a Chef Infra Client run will occur that
+does everything up to the point at which configuration would normally
+occur. This includes getting the configuration data, authenticating to
+the Chef Infra Server, rebuilding the node object, expanding the
+run-list, getting the necessary cookbook files, resetting node
+attributes, identifying the resources, and building the resource
+collection, but doesn't include mapping each resource to a provider or
+configuring any part of the system.
+
+{{< note >}}
+
+why-run mode isn't a replacement for running cookbooks in a test
+environment that mirrors the production environment. Chef uses why-run
+mode to learn more about what's going on, but also Kitchen on developer
+systems, along with an internal OpenStack cloud and external cloud
+providers for more thorough testing.
+
+{{< /note >}}
+
+When Chef Infra Client is run in why-run mode, certain assumptions are
+made:
+
+- If the **service** resource can't find the appropriate command to
+ verify the status of a service, why-run mode will assume that the
+ command would have been installed by a previous resource and that
+ the service would not be running.
+- For `not_if` and `only_if` properties, why-run mode will assume
+ these are commands or blocks that are safe to run. These conditions
+ aren't designed to be used to change the state of the system, but
+ rather to help facilitate idempotency for the resource itself. That
+ said, it may be possible that these attributes are being used in a
+ way that modifies the system state
+- The closer the current state of the system is to the desired state,
+ the more useful why-run mode will be. For example, if a full
+ run-list is run against a fresh system, that run-list may not be
+ completely correct on the first try, but also that run-list will
+ produce more output than a smaller run-list
+
+For example, the **service** resource can be used to start a service. If
+the action is `:start`, then the service will start if it's not running
+and do nothing if it's running. If a service is installed from a
+package, then Chef Infra Client can't check to see if the service is
+running until after the package is installed. In that case, why-run mode
+will indicate what Chef Infra Client would do about the state of the
+service after installing a package. This is important because service
+actions often trigger notifications to other resources, so it's
+important to know that these notifications are triggered correctly.
+
+### About chef-zero
+
+chef-zero is a lightweight Chef Infra Server that runs in-memory on
+the local machine. This allows the Chef Infra Client to be run against
+the chef-repo as if it were running against the Chef Infra Server.
+chef-zero was [originally a standalone
+tool](https://github.com/chef/chef-zero); it's enabled from within the
+Chef Infra Client by using the `--local-mode` option. chef-zero is
+useful for testing and validating the behavior of the Chef Infra
+Client, cookbooks, recipes, and run-lists before uploading that data to
+the actual Chef Infra Server.
+
+{{< note >}}
+
+chef-zero doesn't save data between restarts. Because it's intended to
+be used locally, chef-zero doesn't perform input validation,
+authentication, or authorization, as these security measures aren't
+necessary for local testing. For these reasons, we strongly recommend
+against using chef-zero as a persistent Chef Infra Server.
+
+{{< /note >}}
+
+Changed in Chef Infra Client 12.8, now chef-zero supports all Chef Server API
+version 12 endpoints, except `/universe`.
+
+### Use Encrypted Data Bags
+
+{{< readfile file="content/reusable/md/data_bag.md" >}}
+
+**Create an encrypted data bag for use with Chef Infra Client local
+mode**
+
+{{< readfile file="content/workstation/reusable/md/knife_data_bag_from_file_create_encrypted_local_mode.md" >}}
+
+## Run in FIPS Mode
+
+{{< readfile file="content/reusable/md/fips_intro_client.md" >}}
+
+**Bootstrap a node using FIPS**
+
+{{< readfile file="content/workstation/reusable/md/knife_bootstrap_node_fips.md" >}}
+
+## Run as a Service
+
+The Chef Infra Client can be run as a daemon. Use the **Chef Infra
+Client** cookbook to configure the Chef Infra Client as a daemon. Add
+the `default` recipe to a node's run-list, and then use attributes in
+that cookbook to configure the behavior of the Chef Infra Client. For
+more information about these configuration options, see the [Chef Infra
+Client cookbook repository on
+github](https://github.com/chef-cookbooks/chef-client/).
+
+When the Chef Infra Client is run as a daemon, the following signals may
+be used:
+
+`HUP`
+
+: Use to reconfigure the Chef Infra Client.
+
+`INT`
+
+: Use to terminate immediately without waiting for the current Chef
+ Infra Client run to finish.
+
+`QUIT`
+
+: Use to dump a stack trace, and continue to run.
+
+`TERM`
+
+: Use to terminate but wait for the current Chef Infra Client run to
+ finish, and then exit.
+
+`USR1`
+
+: Use to wake up sleeping Chef Infra Client and trigger node
+ convergence.
+
+On Windows, both the `HUP` and `QUIT` signals aren't
+supported.
+
+## Run with Elevated Privileges
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_client_elevated_privileges.md" >}}
+
+### Linux
+
+On Linux, the following error sometimes occurs when the permissions used
+to run the Chef Infra Client are incorrect:
+
+```bash
+chef-client
+[Tue, 29 Nov 2015 19:46:17 -0800] INFO: *** Chef 12.X.X ***
+[Tue, 29 Nov 2015 19:46:18 -0800] WARN: Failed to read the private key /etc/chef/client.pem: #
+```
+
+This can be resolved by running the command as root. There are a few
+ways this can be done:
+
+- Log in as root and then run the Chef Infra Client
+
+- Use `su` to become the root user, and then run the Chef Infra
+ Client. For example:
+
+ ```bash
+ su
+ ```
+
+ and then:
+
+ ```bash
+ chef-client
+ ```
+
+- Use the sudo utility
+
+ ```bash
+ sudo chef-client
+ ```
+
+- Give a user access to read `/etc/chef` and also the files accessed
+ by the Chef Infra Client. This requires super user privileges and,
+ as such, isn't a recommended approach
+
+### Windows
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_client_elevated_privileges_windows.md" >}}
+
+## Run as Non-root User
+
+In large, distributed organizations the ability to modify the
+configuration of systems is sometimes segmented across teams, often with
+varying levels of access to those systems. For example, core application
+services may be deployed to systems by a central server provisioning
+team, and then developers on different teams build tooling to support
+specific applications. In this situation, a developer only requires
+limited access to machines and only needs to perform the operations that
+are necessary to deploy tooling for a specific application.
+
+The default configuration of the Chef Infra Client assumes that it's
+run as the root user. This affords the Chef Infra Client the greatest
+flexibility when managing the state of any object. However, the Chef
+Infra Client may be run as a non-root user---that's, "run as a user with
+limited system privileges"---which can be useful when the objects on the
+system are available to other user accounts.
+
+When the Chef Infra Client is run as a non-root user the Chef Infra
+Client can perform any action allowed to that user, as long as that
+action doesn't also require elevated privileges (such as sudo or
+pbrun). Attempts to manage any object that requires elevated privileges
+will result in an error. For example, when the Chef Infra Client is run
+as a non-root user that's unable to create or modify users, the
+**user** resource won't work.
+
+### Set the Cache Path
+
+To run a Chef Infra Client in non-root mode, add the `file_cache_path`
+setting to the client.rb file for the node that will run as the non-root
+user. Set the value of `file_cache_path` to be the home directory for
+the user that's running the Chef Infra Client. For example:
+
+```ruby
+file_cache_path '~/.chef/cache'
+```
+
+or:
+
+```ruby
+file_cache_path File.join(File.expand_path('~'), '.chef', 'cache')
+```
+
+{{< note >}}
+
+When running the Chef Infra Client using the `--local-mode` option,
+`~/.chef/local-mode-cache` is the default value for `file_cache_path`.
+
+{{< /note >}}
+
+### Elevate Commands
+
+Another example of running the Chef Infra Client as a non-root user
+involves using resources to pass sudo commands as as an attribute on the
+resource. For example, the **service** resource uses a series of
+`_command` attributes (like `start_command` or `stop_command`),
+the **package**-based resources use the `options` attribute, and the
+**script**-based resources use the `code` attribute.
+
+A command can be elevated similar to the following:
+
+```ruby
+service 'apache2' do
+ start_command 'sudo /etc/init.d/apache2 start'
+ action :start
+end
+```
+
+This approach can work well on a case-by-case basis. The challenge
+with this approach is often around managing the size of the
+`/etc/sudoers` file.
+
+## Run on IBM AIX
+
+The Chef Infra Client may now be used to configure nodes that are
+running on the AIX platform, versions 7.1 (TL5 SP2 or higher,
+recommended) and 7.2. The **service** resource supports starting,
+stopping, and restarting services that are managed by System Resource
+Controller (SRC), as well as managing all service states with BSD-based
+init systems.
+
+**System Requirements**
+
+The Chef Infra Client has the [same system
+requirements](/chef_system_requirements/#chef-infra-client) on the
+AIX platform as any other platform, with the following notes:
+
+- Expand the file system on the AIX platform using `chfs` or by
+ passing the `-X` flag to `installp` to automatically expand the
+ logical partition (LPAR)
+- The EN_US (UTF-8) character set should be installed on the logical
+ partition before installing the Chef Infra Client
+
+**Install the Chef Infra Client on the AIX platform**
+
+The Chef Infra Client is distributed as a Backup File Format (BFF)
+binary and is installed on the AIX platform using the following command
+run as a root user:
+
+```text
+# installp -aYgd chef-12.0.0-1.powerpc.bff all
+```
+
+**Increase system process limits**
+
+The out-of-the-box system process limits for maximum process memory size
+(RSS) and number of open files are typically too low to run the Chef
+Infra Client on a logical partition (LPAR). When the system process
+limits are too low, the Chef Infra Client won't be able to create
+threads. To increase the system process limits:
+
+1. Validate that the system process limits haven't already been increased.
+
+2. If they haven't been increased, run the following commands as a root user:
+
+ ```bash
+ chsec -f /etc/security/limits -s default -a "rss=-1"
+ ```
+
+ and then:
+
+ ```bash
+ chsec -f /etc/security/limits -s default -a "data=-1"
+ ```
+
+ and then:
+
+ ```bash
+ chsec -f /etc/security/limits -s default -a "nofiles=50000"
+ ```
+
+ {{< note >}}
+
+ The previous commands may be run against the root user, instead of
+ default. For example:
+
+ ```bash
+ chsec -f /etc/security/limits -s root_user -a "rss=-1"
+ ```
+
+ {{< /note >}}
+
+3. Reboot the logical partition (LPAR) to apply the updated system process limits.
+
+When the system process limits are too low, an error is returned similar
+to:
+
+```bash
+Error Syncing Cookbooks:
+==================================================================
+
+Unexpected Error:
+-----------------
+ThreadError: can't create Thread: Resource temporarily unavailable
+```
+
+**Install the UTF-8 character set**
+
+The Chef Infra Client uses the EN_US (UTF-8) character set. By default,
+the AIX base operating system doesn't include the EN_US (UTF-8)
+character set and it must be installed before installing the Chef
+Infra Client. The EN_US (UTF-8) character set may be installed from the
+first disc in the AIX media or may be copied from
+`/installp/ppc/*EN_US*` to a location on the logical partition (LPAR).
+This topic assumes this location to be `/tmp/rte`.
+
+Use `smit` to install the EN_US (UTF-8) character set. This ensures
+that any workload partitions (WPARs) also have UTF-8 applied.
+
+Remember to point `INPUT device/directory` to `/tmp/rte` when not
+installing from CD.
+
+1. From a root shell type:
+
+ ```text
+ # smit lang
+ ```
+
+ A screen similar to the following is returned:
+
+ ```bash
+ Manage Language Environment
+
+ Move cursor to desired item and press Enter.
+
+ Change/Show Primary Language Environment
+ Add Additional Language Environments
+ Remove Language Environments
+ Change/Show Language Hierarchy
+ Set User Languages
+ Change/Show Applications for a Language
+ Convert System Messages and Flat Files
+
+ F1=Help F2=Refresh F3=Cancel F8=Image
+ F9=Shell F10=Exit Enter=Do
+ ```
+
+2. Select `Add Additional Language Environments` and press `Enter`. A screen similar to the following is returned:
+
+ ```bash
+ Add Additional Language Environments
+
+ Type or select values in entry fields. Press Enter AFTER making
+ all desired changes.
+
+ [Entry Fields]
+
+ CULTURAL convention to install + LANGUAGE translation to
+ install + INPUT device/directory for software [/dev/cd0] + EXTEND file
+ systems if space needed? yes + WPAR Management
+
+ Perform Operation in Global Environment yes + Perform
+ Operation on Detached WPARs no + Detached WPAR Names
+ [_all_wpars] + Remount Installation Device in WPARs
+ yes + Alternate WPAR Installation Device []
+
+ F1=Help F2=Refresh F3=Cancel F4=List F5=Reset F6=Command F7=Edit
+ F8=Image F9=Shell F10=Exit Enter=Do
+ ```
+
+3. Cursor over the first two entries---`CULTURAL convention to install` and `LANGUAGE translation to install`---and use `F4` to navigate through the list until `UTF-8 English (United States) [EN_US]` is selected. (EN_US is in capital letters!)
+
+4. Press `Enter` to apply and install the language set.
+
+**Providers**
+
+The **service** resource has the following providers to support the AIX
+platform:
+
+
+
+
+
+
+
+
+
+
Long name
+
Short name
+
Notes
+
+
+
+
+
Chef::Provider::Service::Aix
+
service
+
The provider that's used with the AIX platforms. Use the service short name to start, stop, and restart services with System Resource Controller (SRC).
+
+
+
Chef::Provider::Service::AixInit
+
service
+
The provider that's used to manage BSD-based init services on AIX.
+
+
+
+
+**Enable a service on AIX using the mkitab command**
+
+The **service** resource doesn't support using the `:enable` and
+`:disable` actions with resources that are managed using System Resource
+Controller (SRC). This is because System Resource Controller (SRC) does
+not have a standard mechanism for enabling and disabling services on
+system boot.
+
+One approach for enabling or disabling services that are managed by
+System Resource Controller (SRC) is to use the **execute** resource to
+invoke `mkitab`, and then use that command to enable or disable the
+service.
+
+The following example shows how to install a service:
+
+```ruby
+execute "install #{node['chef_client']['svc_name']} in SRC" do
+ command "mkssys -s #{node['chef_client']['svc_name']}
+ -p #{node['chef_client']['bin']}
+ -u root
+ -S
+ -n 15
+ -f 9
+ -o #{node['chef_client']['log_dir']}/client.log
+ -e #{node['chef_client']['log_dir']}/client.log -a '
+ -i #{node['chef_client']['interval']}
+ -s #{node['chef_client']['splay']}'"
+ not_if "lssrc -s #{node['chef_client']['svc_name']}"
+ action :run
+end
+```
+
+and then enable it using the `mkitab` command:
+
+```ruby
+execute "enable #{node['chef_client']['svc_name']}" do
+ command "mkitab '#{node['chef_client']['svc_name']}:2:once:/usr/bin/startsrc
+ -s #{node['chef_client']['svc_name']} > /dev/console 2>&1'"
+ not_if "lsitab #{node['chef_client']['svc_name']}"
+end
+```
+
+## Configuring a Proxy Server
+
+See the [proxies](/proxies/) documentation for information on how to
+configure Chef Infra Client to use a proxy server.
+
+## Examples
+
+**Run the Chef Infra Client**
+
+```bash
+sudo chef-client
+```
+
+**Start a run when the Chef Infra Client is running as a daemon**
+
+A Chef Infra Client that's running as a daemon can be woken up and
+started by sending the process a `SIGUSR1`. For example, to trigger a
+Chef Infra Client run on a machine running Linux:
+
+```bash
+sudo killall -USR1 chef-client
+```
+
+**Setting the initial run-list using a JSON file**
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_client_bootstrap_initial_run_list.md" >}}
diff --git a/content/ctl_chef_solo.md b/content/ctl_chef_solo.md
new file mode 100644
index 0000000..0334386
--- /dev/null
+++ b/content/ctl_chef_solo.md
@@ -0,0 +1,185 @@
++++
+title = "chef-solo (executable)"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+aliases = ["/ctl_chef_solo.html"]
+
+[menu]
+ [menu.infra]
+ title = "chef-solo (executable)"
+ identifier = "chef_infra/features/chef_solo/ctl_chef_solo.md chef-solo Commands"
+ parent = "chef_infra/features/chef_solo"
+ weight = 20
++++
+
+{{< readfile file="content/reusable/md/chef_solo_summary.md" >}}
+
+## Options
+
+This command has the following syntax:
+
+```bash
+chef-solo OPTION VALUE OPTION VALUE ...
+```
+
+This command has the following options:
+
+`-c CONFIG`, `--config CONFIG`
+
+: The configuration file to use.
+
+`-d`, `--daemonize`
+
+: Run the executable as a daemon. This option may not be used in the same command with the `--[no-]fork` option. This option is only available on machines that run in UNIX or Linux environments. For machines that are running Windows that require similar functionality, use the `chef-client::service` recipe in the `chef-client` cookbook: . This will install a Chef Infra Client service under Windows using the Windows Service Wrapper.
+
+`-E ENVIRONMENT_NAME`, `--environment ENVIRONMENT_NAME`
+
+: The name of the environment.
+
+`-f`, `--[no-]fork`
+
+: Contains Chef Infra Client runs in a secondary process with dedicated RAM. When a Chef Infra Client run is complete, the RAM is returned to the master process. This option helps ensure that a Chef Infra Client uses a steady amount of RAM over time because the master process doesn't run recipes. This option also helps prevent memory leaks such as those that can be introduced by the code contained within a poorly designed cookbook. Use `--no-fork` to disable running Chef Infra Client in fork node. Default value: `--fork`. This option may not be used in the same command with the `--daemonize` and `--interval` options.
+
+`-F FORMAT`, `--format FORMAT`
+
+: {{< readfile file="content/workstation/reusable/md/ctl_chef_client_options_format.md" >}}
+
+`--force-formatter`
+
+: Show formatter output instead of logger output.
+
+`--force-logger`
+
+: Show logger output instead of formatter output.
+
+`-g GROUP`, `--group GROUP`
+
+: The name of the group that owns a process. This is required when starting any executable as a daemon.
+
+`-h`, `--help`
+
+: Show help for the command.
+
+`-i SECONDS`, `--interval SECONDS`
+
+: The frequency (in seconds) at which Chef Infra Client runs. When running Chef Infra Client at intervals, apply `--splay` and `--interval` values before a Chef Infra Client run. This option may not be used in the same command with the `--[no-]fork` option.
+
+`-j PATH`, `--json-attributes PATH`
+
+: The path to a file that contains JSON data.
+
+ {{< readfile file="content/reusable/md/node_ctl_run_list.md" spaces=4 >}}
+
+ {{< warning >}}
+
+ {{< readfile file="content/reusable/md/node_ctl_attribute.md">}}
+
+ {{< /warning >}}
+
+`-l LEVEL`, `--log_level LEVEL`
+
+: The level of logging to be stored in a log file. Possible levels: `auto` (default), `debug`, `error`, `fatal`, `info`, `trace`, or `warn`. Default value: `warn` (when a terminal is available) or `info` (when a terminal isn't available).
+
+`-L LOGLOCATION`, `--logfile c`
+
+: The location of the log file. This is recommended when starting any executable as a daemon.
+
+`--legacy-mode`
+
+: Cause Chef Infra Client to use the original chef-solo mode instead of chef local mode. This isn't recommended. **Removed in Chef Infra Client 14.**
+
+`--minimal-ohai`
+
+: Run the Ohai plugins for name detection and resource/provider selection and no other Ohai plugins. Set to `true` during integration testing to speed up test cycles.
+
+`--[no-]color`
+
+: View colored output. Default setting: `--color`.
+
+`-N NODE_NAME`, `--node-name NODE_NAME`
+
+: The unique identifier of the node.
+
+`-o RUN_LIST_ITEM`, `--override-runlist RUN_LIST_ITEM`
+
+: Replace the current run-list with the specified items.
+
+`-r RECIPE_URL`, `--recipe-url RECIPE_URL`
+
+: The URL of the remote cookbook `tar.gz` file that you want to download.
+
+ In Chef Infra Client 14, the short `-r` form will be removed, as it conflicts with the ability to specify a run list.
+
+`--run-lock-timeout SECONDS`
+
+: The amount of time (in seconds) to wait for a Chef Infra Client lock file to be deleted. Default value: not set (indefinite). Set to `0` to cause a second Chef Infra Client to exit immediately.
+
+`-s SECONDS`, `--splay SECONDS`
+
+: A random number between zero and `splay` that's added to `interval`. Use splay to help balance the load on the Chef Infra Server by ensuring that many Chef Infra Client runs aren't occurring at the same interval. When running Chef Infra Client at intervals, apply `--splay` and `--interval` values before a Chef Infra Client run.
+
+`-u USER`, `--user USER`
+
+: The user that owns a process. This is required when starting any executable as a daemon.
+
+`-v`, `--version`
+
+: The Chef Infra Client version.
+
+`-W`, `--why-run`
+
+: Run the executable in why-run mode, which is a type of Chef Infra Client run that does everything except modify the system. Use why-run mode to understand the decisions that Chef Infra Client makes during a run and to learn more about the current and proposed state of the system.
+
+## Run as Non-root User
+
+{{< warning >}}
+
+This configuration for the `chef` user provides root-level access through Chef script files that call system commands with `sudo` privileges.
+
+Use an alternative approach if your security profile forbids the `chef` user from having built-in root level access.
+
+{{< /warning >}}
+
+chef-solo may be run as a non-root user. For example, you can update the `sudoers` file:
+
+```ruby
+# chef-solo privilege specification
+chef ALL=(ALL) NOPASSWD: /usr/bin/chef-solo
+```
+
+where `chef` is the name of the non-root user. This would allow chef-solo to run any command on the node without requiring a password.
+
+## Examples
+
+### Run chef-solo using solo.rb settings
+
+```bash
+chef-solo -c ~/chef/solo.rb
+```
+
+### Use a URL
+
+```bash
+chef-solo -c ~/solo.rb -j ~/node.json -r http://www.example.com/chef-solo.tar.gz
+```
+
+The tar.gz is archived into the `file_cache_path`, and then extracted to
+`cookbooks_path`.
+
+### Use a directory
+
+```bash
+chef-solo -c ~/solo.rb -j ~/node.json
+```
+
+chef-solo will look in the `solo.rb` file to determine the directory in which cookbooks are located.
+
+### Use a URL for cookbook and JSON data
+
+```bash
+chef-solo -c ~/solo.rb -j http://www.example.com/node.json --recipe-url http://www.example.com/chef-solo.tar.gz
+```
+
+where `--recipe-url` corresponds to `recipe_url` and `-j` corresponds to `json_attribs`, both of which are [configuration options](/config_rb_solo/) in `solo.rb`.
diff --git a/content/ctl_ohai.md b/content/ctl_ohai.md
new file mode 100644
index 0000000..2d17413
--- /dev/null
+++ b/content/ctl_ohai.md
@@ -0,0 +1,128 @@
++++
+title = "ohai (executable)"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+aliases = ["/ctl_ohai.html"]
+
+[menu]
+ [menu.infra]
+ title = "ohai (executable)"
+ identifier = "chef_infra/features/ohai/ctl_ohai.md ohai Commands"
+ parent = "chef_infra/features/ohai"
+ weight = 20
++++
+
+`ohai` is the command-line interface for Ohai, a tool that's used to
+detect attributes on a node, and then provide these attributes to Chef
+Infra Client at the start of every Chef Infra Client run.
+
+## Options
+
+This command has the following syntax:
+
+```bash
+ohai OPTION
+```
+
+This tool has the following options:
+
+`ATTRIBUTE_NAME ATTRIBUTE NAME ...`
+
+: Use to have Ohai show only output for named attributes. To address attributes deeper in the tree, use a `/` delimiter between each level. For example: `memory/free`.
+
+`-c CONFIG`, `--config CONFIG`
+
+: The path to a configuration file to use. For example:
+ `/etc/ohai/config.rb`.
+
+`-d DIRECTORY`, `--directory DIRECTORY`
+
+: The directory in which additional Ohai plugins are located. For
+ example: `/my/extra/plugins`.
+
+`-h`, `--help`
+
+: Show help for the command.
+
+`-l LEVEL`, `--log_level LEVEL`
+
+: The level of logging to be stored in a log file.
+
+`-L LOGLOCATION`, `--logfile LOGLOCATION`
+
+: The location of the log file.
+
+`-v`, `--version`
+
+: The version of Ohai.
+
+## Examples
+
+The following examples show how to use the Ohai command-line tool:
+
+### Query for a specific attribute
+
+Pass an attribute as an argument to `ohai` to get the value of that attribute. For example:
+
+```bash
+ohai os
+```
+
+This fetches the value of Chef Infra's node data at `node['os']` and returns something like:
+
+```json
+[
+ "linux"
+]
+```
+
+To query for an attribute deeper in the tree, use a forward slash (`/`) as a
+delimiter. For example, to query for free memory, run:
+
+```bash
+ohai memory/free
+```
+
+### Run a plugin independently of a Chef Infra Client run
+
+An Ohai plugin can be run independently of a Chef Infra Client run.
+First, ensure that the plugin is located in the `/plugins` directory and
+then use the `-f` option when running Ohai from the command line. For
+example, a plugin named `sl_installed` may look like the following:
+
+```ruby
+Ohai.plugin(:Sl) do
+ provides "sl"
+
+ collect_data(:default) do
+ sl Mash.new
+
+ if ::File.exist?("/usr/games/sl")
+ sl[:installed] = true
+ else
+ sl[:installed] = false
+ end
+
+ # sl[:installed] = ::File.exist?("/usr/games/sl")
+
+ end
+end
+```
+
+To run that plugin from the command line, use the following command:
+
+```bash
+ohai --directory /path/to/directory sl
+```
+
+The command will return something similar to:
+
+```json
+{
+ "sl": {
+ "installed": true
+ }
+}
+```
diff --git a/content/custom_resource_glossary.md b/content/custom_resource_glossary.md
new file mode 100644
index 0000000..dcd557a
--- /dev/null
+++ b/content/custom_resource_glossary.md
@@ -0,0 +1,718 @@
++++
+title = "Custom resources glossary"
+gh_repo = "chef-web-docs"
+aliases = ["/custom_resource_glossary.html"]
+
+product = ["client", "workstation"]
+
+[menu]
+ [menu.infra]
+ title = "Glossary"
+ identifier = "chef_infra/resources/custom_resources/glossary"
+ parent = "chef_infra/resources/custom_resources"
+ weight = 200
++++
+
+The following domain-specific language (DSL) methods are available when writing custom resources.
+
+For further information about how to write custom resources please see [about custom resources]({{< relref "custom_resources.md" >}})
+
+## action_class
+
+`action_class` makes methods available to all actions within a single custom resource.
+
+For example, a template requires `'yes'` or `'no'` written as a string, but you would like the user to use `true` or `false` for convenience.
+To allow both the `:add` and `:remove` actions to have access to this method, place the method in the `action_class` block.
+
+```ruby
+property :example, [true, false], default: true
+
+action :add do
+ template "file.conf" do
+ source 'file.conf.erb'
+ variables(
+ chocolate: bool_to_string(new_resource.example)
+ )
+ action :create
+ end
+end
+
+action :remove do
+ template "file.conf" do
+ source 'file.conf.erb'
+ variables(
+ chocolate: bool_to_string(new_resource.example)
+ )
+ action :delete
+ end
+end
+
+action_class do
+ def bool_to_string(b)
+ b ? 'yes' : 'false'
+ end
+end
+```
+
+## coerce
+
+`coerce` is used to transform user input into a canonical form. The
+value is passed in, and the transformed value returned as output. Lazy
+values will __not__ be passed to this method until after they're
+evaluated.
+
+`coerce` is run in the context of the instance, which gives it access to
+other properties.
+
+Here we transform,`true`/`false` in to `yes`, `no` for a template later on.
+
+```ruby
+property :browseable,
+ [true, false, String],
+ default: true,
+ coerce: proc { |p| p ? 'yes' : 'no' },
+```
+
+If you are modifying the properties type, you will also need to accept that Ruby type as an input.
+
+## converge_if_changed
+
+Use the `converge_if_changed` method inside an `action` block in a
+custom resource to compare the desired property values against the
+current property values (as loaded by the `load_current_value` method).
+Use the `converge_if_changed` method to ensure that updates only occur
+when property values on the system aren't the desired property values
+and to otherwise prevent a resource from being converged.
+
+To use the `converge_if_changed` method, wrap it around the part of a
+recipe or custom resource that should only be converged when the current
+state isn't the desired state:
+
+```ruby
+action :some_action do
+ converge_if_changed do
+ # some property
+ end
+end
+```
+
+The `converge_if_changed` method may be used multiple times. The
+following example shows how to use the `converge_if_changed` method to
+compare the multiple desired property values against the current
+property values (as loaded by the `load_current_value` method).
+
+```ruby
+property :path, String
+property :content, String
+property :mode, String
+
+# Load the current value for content and mode
+load_current_value do |new_resource|
+ if ::File.exist?(new_resource.path)
+ content IO.read(new_resource.path)
+ mode ::File.stat(new_resource.path).mode
+ end
+end
+
+action :create do
+ # If the value of content has changed
+ # write file
+ converge_if_changed :content do
+ IO.write(new_resource.path, new_resource.content)
+ end
+
+ # If the value of mode has changed then
+ # chmod file
+ converge_if_changed :mode do
+ ::File.chmod(new_resource.mode, new_resource.path)
+ end
+end
+```
+
+Chef Infra Client will only update the property values that require
+updates and won't make changes when the property values are already
+in the desired state.
+
+
+
+## current_value_does_not_exist!
+
+
+
+When using the `load_current_value` block, use `current_value_does_not_exist!` to indicate that the value doesn't exist and that `current_resource` should therefore be `nil`.
+
+```ruby
+load_current_value do |new_resource|
+ port_data = powershell_exec(%Q{Get-WmiObject -Class Win32_TCPIPPrinterPort -Filter "Name='#{new_resource.port_name}'"}).result
+
+ if port_data.empty?
+ current_value_does_not_exist!
+ else
+ ipv4_address port_data["HostAddress"]
+ end
+ endo
+end
+```
+
+## default_action
+
+The default action in a custom resource is, by default, the first action
+listed in the custom resource. For example, action `aaaaa` is the
+default resource:
+
+```ruby
+property :property_name, RubyType, default: 'value'
+
+...
+
+action :aaaaa do
+ # the first action listed in the custom resource
+end
+
+action :bbbbb do
+ # the second action listed in the custom resource
+end
+```
+
+The `default_action` method may also be used to specify the default
+action. For example:
+
+```ruby
+property :property_name, RubyType, default: 'value'
+
+# Define bbbbb aas the default action
+default_action :bbbbb
+
+action :aaaaa do
+ # the first action listed in the custom resource
+end
+
+action :bbbbb do
+ # the second action listed in the custom resource
+end
+```
+
+## deprecated
+
+### Deprecating a resource
+
+Deprecate resources that you no longer wish to maintain.
+This allows you make breaking changes to enterprise or community cookbooks with friendly notifications to downstream cookbook consumers directly in the Chef Infra Client run.
+
+Use the `deprecated` method to deprecate a resource in a cookbook. For example:
+
+```ruby
+deprecated 'The foo_bar resource has been deprecated and will be removed in the next major release of this cookbook scheduled for 25/01/2021!'
+
+property :thing, String, name_property: true
+
+action :create do
+ # Chef resource code
+end
+```
+
+### Deprecating a property
+
+Deprecate the `badly_named` property in a resource:
+
+```ruby
+property :badly_named, String, deprecated: 'The badly_named property has been deprecated and will be removed in the next major release of this cookbook scheduled for 12/25/2021!'
+```
+
+## deprecated_property_alias
+
+To rename a property with a deprecation warning for users of the old property name, use `deprecated_property_alias`:
+
+```ruby
+deprecated_property_alias 'badly_named', 'really_well_named', 'The badly_named property was renamed really_well_named in the 2.0 release of this cookbook. Please update your cookbooks to use the new property name.'
+```
+
+## desired_state
+
+Add `desired_state:` to set the desired state property for a resource.
+
+| Allowed values | Default |
+| -------------- | ------- |
+| `true` `false` | `true` |
+
+- When `true`, the state of the property is determined by the state of
+ the system
+- When `false`, the value of the property impacts how the resource
+ executes, but it's not determined by the state of the system.
+
+For example, if you were to write a resource to create volumes on a
+cloud provider you would need define properties such as `volume_name`,
+`volume_size`, and `volume_region`. The state of these properties would
+determine if your resource needed to converge or not. For the resource
+to function you would also need to define properties such as
+`cloud_login` and `cloud_password`. These are necessary properties for
+interacting with the cloud provider, but their state has no impact on
+decision to converge the resource or not, so you would set
+`desired_state` to `false` for these properties.
+
+```ruby
+property :volume_name, String
+property :volume_size, Integer
+property :volume_region, String
+property :cloud_login, String, desired_state: false
+property :cloud_password, String, desired_state: false
+```
+
+## lazy
+
+When setting a node attribute as the default value for a custom resource property, wrap the node attribute in `lazy {}` so that its value is available when the resource executes.
+
+```ruby
+property :thing, String, default: lazy { node['thingy'] }
+```
+
+## load_current_value
+
+Use the `load_current_value` method to load the specified property
+values from the node, and then use those values when the resource is
+converged. This method may take a block argument.
+
+```ruby
+property :path, String
+property :content, String
+property :mode, String
+
+load_current_value do |new_resource|
+ if ::File.exist?(new_resource.path)
+ content IO.read(new_resource.path)
+ mode ::File.stat(new_resource.path).mode
+ end
+end
+```
+
+Use the `load_current_value` method to guard against property value being replaced. For example:
+
+```ruby
+property :homepage, String
+property :page_not_found, String
+
+load_current_value do
+ if ::File.exist?('/var/www/html/index.html')
+ homepage IO.read('/var/www/html/index.html')
+ end
+
+ if ::File.exist?('/var/www/html/404.html')
+ page_not_found IO.read('/var/www/html/404.html')
+ end
+end
+```
+
+This ensures the values for `homepage` and `page_not_found` aren't
+changed to the default values when Chef Infra Client configures the
+node.
+
+## new_resource.property
+
+Custom resources are designed to use resources that are built into Chef Infra and external custom resources.
+To disambiguate from the current resource being used and other resources, `new_resource.property` is required.
+
+For example:
+
+```ruby
+property :command, String, name_property: true
+property :version, String
+
+# Useful properties from the `execute` resource
+property :cwd, String
+property :environment, Hash, default: {}
+property :user, [String, Integer]
+property :sensitive, [true, false], default: false
+
+prefix = '/opt/languages/node'
+
+load_current_value do
+ current_value_does_not_exist! if node.run_state['nodejs'].nil?
+ version node.run_state['nodejs'][:version]
+end
+
+action :run do
+ execute 'execute-node' do
+ cwd cwd
+ environment environment
+ user user
+ sensitive sensitive
+ # gsub replaces 10+ spaces at the beginning of the line with nothing
+ command <<-CODE.gsub(/^ {10}/, '')
+ #{prefix}/#{new_resource.version}/#{command}
+ CODE
+ end
+end
+```
+
+The following properties are identical to the properties in the execute resource, which we're embedding in the custom resource.
+
+- `property :cwd`
+- `property :environment`
+- `property :user`
+- `property :sensitive`
+
+Because both the custom properties and the __execute__ properties are identical, this
+will result in an error message similar to:
+
+```ruby
+ArgumentError
+-------------
+wrong number of arguments (0 for 1)
+```
+
+To prevent this behavior, use `new_resource.` to tell Chef Infra Client
+to process the properties from the core resource instead of the
+properties in the custom resource. For example:
+
+```ruby
+property :command, String, name_property: true
+property :version, String
+
+# Useful properties from the `execute` resource
+property :cwd, String
+property :environment, Hash, default: {}
+property :user, [String, Integer]
+property :sensitive, [true, false], default: false
+
+prefix = '/opt/languages/node'
+
+load_current_value do
+ current_value_does_not_exist! if node.run_state['nodejs'].nil?
+ version node.run_state['nodejs'][:version]
+end
+
+action :run do
+ execute 'execute-node' do
+ cwd new_resource.cwd
+ environment new_resource.environment
+ user new_resource.user
+ sensitive new_resource.sensitive
+ # gsub replaces 10+ spaces at the beginning of the line with nothing
+ command <<-CODE.gsub(/^ {10}/, '')
+ #{prefix}/#{new_resource.version}/#{new_resource.command}
+ CODE
+ end
+end
+```
+
+where:
+
+- `cwd new_resource.cwd`
+- `environment new_resource.environment`
+- `user new_resource.user`
+- `sensitive new_resource.sensitive`
+
+Correctly use the properties of the __execute__ resource and not the identically-named override properties of the custom resource.
+
+## partial
+
+To DRY (don't repeat yourself) up code, custom resources can include partials from common files.
+
+For example, if all of your resources need the `version` property, you can add this to a `partial/_common.rb` file and include that Ruby code in your resource using the `use` directive.
+
+In `resources/partial/_common.rb`, define the `version` property:
+
+```ruby
+# resources/partial/_common.rb
+property :version, String,
+ name_property: true,
+ description: 'Java version to install'
+```
+
+And then in your custom resources, include that code with the `use` directive:
+
+```ruby
+# resources/install_type_a.rb
+provides :adoptopenjdk_install
+unified_mode true
+use 'partial/_common'
+
+property :variant,
+ String,
+ description: 'Install flavour', default: 'openj9'
+```
+
+```ruby
+# resources/openjdk_install.rb
+provides :openjdk_install
+unified_mode true
+use 'partial/_common'
+
+property :install_type,
+ String,
+ default: lazy { default_openjdk_install_method(version) },
+ equal_to: %w( package source ),
+ description: 'Installation type'
+```
+
+## property
+
+Use the `property` method to define properties for the custom resource.
+The syntax is:
+
+```ruby
+property :property_name, ruby_type, default: 'value', parameter: 'value'
+```
+
+where
+
+- `:property_name` is the name of the property
+- `ruby_type` is the optional Ruby type or array of types, such as
+ `String`, `Integer`, `true`, or `false`
+- `default: 'value'` is the optional default value loaded into the
+ resource
+- `parameter: 'value'` optional parameters
+
+For example, the following properties define `username` and `password`
+properties with no default values specified:
+
+```ruby
+property :username, String
+property :password, String
+```
+
+## property_is_set?
+
+Use the `property_is_set?` method to check if the value for a property has been passed into the resource.
+
+The syntax is:
+
+```ruby
+property_is_set?(:property_name)
+```
+
+The `property_is_set?` method will return `true` if the property is set.
+
+For example, the following custom resource creates and/or updates user
+properties, but not their password. The `property_is_set?` method checks
+if the user has specified a password and then tells Chef Infra Client
+what to do if the password isn't identical:
+
+```ruby
+action :create do
+ converge_if_changed do
+ shell_out!("rabbitmqctl create_or_update_user #{username} --prop1 #{prop1} ... ")
+ end
+
+ if property_is_set?(:password)
+ if shell_out("rabbitmqctl authenticate_user #{username} #{password}").error?
+ converge_by "Updating password for user #{username} ..." do
+ shell_out!("rabbitmqctl update_user #{username} --password #{password}")
+ end
+ end
+ end
+end
+```
+
+## provides
+
+Use the `provides` method to associate multiple custom resource files with the same resources name.
+For example:
+
+```ruby
+# Provide custom_resource_name to Red Hat 7 and above
+provides :custom_resource_name, platform: 'redhat' do |node|
+ node['platform_version'].to_i >= 7
+end
+
+# Provide custom_resource_name to all Red Hat platforms
+provides :custom_resource_name, platform: 'redhat'
+
+# Provide custom_resource_name to the Red Hat platform family
+provides :custom_resource_name, platform_family: 'rhel'
+
+# Provide custom_resource_name to all linux machines
+provides :custom_resource_name, os: 'linux'
+
+# Provide custom_resource_name, useful if your resource file isn't named the same as the resource you want to provide
+provides :custom_resource_name
+```
+
+This allows you to use multiple custom resources files that provide the
+same resource to the user, but for different operating systems or
+operation system versions. With this you can eliminate the need for
+platform or platform version logic within your resources.
+
+### Precedence
+
+Use the `provides` method to associate a custom resource with the recipe
+DSL on different operating systems. When multiple custom resources use
+the same DSL, specificity rules are applied to determine the priority,
+from highest to lowest:
+
+1. `provides :custom_resource_name, platform_version: '0.1.2'`
+2. `provides :custom_resource_name, platform: 'platform_name'`
+3. `provides :custom_resource_name, platform_family: 'platform_family'`
+4. `provides :custom_resource_name, os: 'operating_system'`
+5. `provides :custom_resource_name`
+
+## reset_property
+
+Use the `reset_property` method to clear the value for a property as if
+it had never been set, and then use the default value. For example, to
+clear the value for a property named `password`:
+
+```ruby
+reset_property(:password)
+```
+
+## resource_name
+
+{{< note >}}
+
+`resource_name` was deprecated in Chef Infra Client 15 and became EOL in 16.2.44.
+Use the [`provides`](#provides) method instead of `resource_name`.
+
+For resources running on Chef Infra Client from 12.5 through 15, use `resource_name`:
+
+```ruby
+resource_name :foo
+```
+
+For resources running on Chef Infra Client 15.13.8 to 16.1.16, use both methods to maintain backwards compatibility:
+
+```ruby
+resource_name :foo
+provides :foo
+```
+
+{{< /note >}}
+
+Use the `resource_name` method at the top of a custom resource to declare a custom name for that resource. For example:
+
+```ruby
+resource_name :my_resource_name
+```
+
+## ruby_type
+
+The property ruby_type is a positional parameter.
+
+Use to ensure a property value is of a particular ruby class, such as:
+
+- `true`
+- `false`
+- `nil`
+- `String`
+- `Array`
+- `Hash`
+- `Integer`
+- `Symbol`
+
+Use an array of Ruby classes to allow a value to be of more than one type. For example:
+
+```ruby
+property :aaaa, String
+property :bbbb, Integer
+property :cccc, Hash
+property :dddd, [true, false]
+property :eeee, [String, nil]
+property :ffff, [Class, String, Symbol]
+property :gggg, [Array, Hash]
+```
+
+## run_context
+
+Chef loads and tracks the current run in the run context object.
+
+root_context
+
+## sensitive
+
+A property can be marked sensitive by specifying `sensitive: true` on
+the property. This prevents the contents of the property from being
+exported to data collection and sent to an Automate server or shown in the
+logs of the Chef Infra Client run.
+
+## target_mode
+
+{{< readfile file="content/reusable/md/target_mode_summary.md" >}}
+
+{{< readfile file="/reusable/md/target_mode_custom_resource.md" >}}
+
+For more information on Target Mode, see the [Target Mode documentation]({{< relref "/target_mode.md" >}}).
+
+## unified_mode
+
+{{< readfile file="content/reusable/md/unified_mode_overview.md" >}}
+
+To enable Unified Mode in a resource, declare it at the top of the resource. For example:
+
+```ruby
+unified_mode true
+
+provides :resource_name
+
+```
+
+For information, see the [Unified Mode documentation]({{< relref "unified_mode" >}}).
+
+## Validation parameters
+
+Use a validation parameter to add zero (or more) validation parameters to a property.
+
+
+
+
+
+
+
+
+
+
Parameter
+
Description
+
+
+
+
+
:callbacks
+
Use to define a collection of unique keys and values (a ruby hash) for which the key is the error message and the value is a lambda to validate the parameter. For example:
+
callbacks: {
+'should be a valid non-system port' => lambda {
+ |p| p > 1024 && p < 65535
+ }
+ }
+
+
+
:default
+
Use to specify the default value for a property. For example:
+
default: 'a_string_value'
+
default: 123456789
+
default: []
+
default: ()
+
default: {}
+
+
+
:equal_to
+
Use to match a value with ==. Use an array of values to match any of those values with ==. For example:
+
equal_to: [true, false]
+
equal_to: ['php', 'perl']
+
+
+
:regex
+
Use to match a value to a regular expression. For example:
+
regex: [ /^([a-z]|[A-Z]|[0-9]|_|-)+$/, /^\d+$/ ]
+
+
+
:required
+
Indicates that a property is required. For example:
+
required: true
+
+
+
:respond_to
+
Use to ensure that a value has a given method. This can be a single method name or an array of method names. For example:
+
respond_to: valid_encoding?
+
+
+
+
+
+Some examples of combining validation parameters:
+
+```ruby
+property :spool_name, String, regex: /$\w+/
+```
+
+```ruby
+property :enabled, equal_to: [true, false, 'true', 'false'], default: true
+```
diff --git a/content/custom_resources.md b/content/custom_resources.md
new file mode 100644
index 0000000..9d3bbcf
--- /dev/null
+++ b/content/custom_resources.md
@@ -0,0 +1,182 @@
++++
+title = "Custom resource guide"
+gh_repo = "chef-web-docs"
+aliases = ["/custom_resources.html"]
+
+product = ["client", "workstation"]
+
+[menu]
+ [menu.infra]
+ title = "Custom resource guide"
+ identifier = "chef_infra/resources/custom_resources/custom_resources.md custom resources"
+ parent = "chef_infra/resources/custom_resources"
+ weight = 10
++++
+
+Chef Infra Client ships with over 150 [built-in resources](/resources/) for managing system configuration such as `directory`, `remote_file`, and `windows_firewall`.
+With custom resources you can extend the built-in capabilities of Chef Infra Client to create reusable resources for use anywhere in your infrastructure.
+
+Custom resources:
+
+- Ship directly in cookbooks.
+- Leverage Chef Infra Client built-in resources and any additional custom Ruby code (if needed).
+- Behave the same as existing built-in resources in your recipes.
+
+## Write a custom resource
+
+Custom resources are written in Ruby and defined in a cookbook's `/resources` directory.
+
+The custom resource code:
+
+- Declares the properties of the custom resource.
+- Loads the current state of properties for existing resources.
+- Defines each action that the custom resource may take.
+
+Follow these steps to create a new custom resource:
+
+1. Generate a new custom resource.
+
+ The `resources` directory doesn't exist by default in a cookbook.
+ Generate the `resources` directory and a resource file from the `chef-repo/cookbooks` directory with the command:
+
+ ```bash
+ chef generate resource
+ ```
+
+ For example, this command generates a `site` custom resource in the `custom_web` cookbook:
+
+ ```bash
+ chef generate resource cookbooks/custom_web site
+ ```
+
+ The `custom_web` cookbook directory with a custom resource has the following structure:
+
+ ```text
+ . cookbooks
+ └── custom_web
+ ├── CHANGELOG.md
+ ├── LICENSE
+ ├── Policyfile.rb
+ ├── README.md
+ ├── chefignore
+ ├── kitchen.yml
+ ├── metadata.rb
+ ├── recipes
+ │ └── default.rb
+ ├── resources
+ │ └── site.rb
+ └── test
+ └── integration
+ └── default
+ └── default_test.rb
+ ```
+
+1. Define the custom resources.
+
+ The layout for a custom resource is:
+
+ ```ruby
+ provides :resource_name
+
+ property :property_name, RubyType, default: 'value'
+
+ action :an_action_name do
+ # a mix of built-in Chef Infra resources and Ruby
+ end
+
+ action :another_action_name do
+ # a mix of built-in Chef Infra resources and Ruby
+ end
+ ```
+
+ The first action listed is the default action.
+
+ For more details on the contents of a custom resource, see the [custom resource glossary]({{< relref "custom_resource_glossary" >}}).
+
+1. Add the custom resource to a recipe.
+
+ Call a resource in a recipe by its resource name. For example:
+
+ ```ruby
+ resource_name 'foo'
+ ```
+
+## Example custom resource
+
+This example creates a custom resource called `site`, which uses Chef Infra's built-in `file`, `service` and `package` resources, and includes `:create` and `:delete` actions.
+It also assumes the existence of a [custom httpd template]({{< relref "templates.md" >}}).
+The code in this custom resource is similar to a typical recipe because it uses built-in Chef Infra Client resources, with the addition of the property and actions definitions for this custom resource.
+
+```ruby
+provides :site
+
+property :homepage, String, default: '
Hello world!
'
+
+action :create do
+ package 'httpd'
+
+ service 'httpd' do
+ action [:enable, :start]
+ end
+
+ file '/var/www/html/index.html' do
+ content new_resource.homepage
+ end
+end
+
+action :delete do
+ package 'httpd' do
+ action :remove
+ end
+
+ file '/var/www/html/index.html' do
+ action :delete
+ end
+end
+```
+
+where:
+
+- `site` is the name of the custom resource. The `provides` statement makes the custom resource available for use recipes.
+- `homepage` sets the default HTML for the `index.html` file with a default value of `'
Hello world!
'`
+- the `action` block uses the built-in collection of resources to tell Chef Infra Client how to install Apache, start the service, and then create the contents of the file located at `/var/www/html/index.html`
+- `action :create` is the default resource (because it's listed first); `action :delete` must be called specifically (because it's not the default action)
+
+Once written, you can use a custom resource in a recipe with the same syntax as Chef Infra Client built-in resources.
+
+### Syntax
+
+To add a custom resource to a recipe, call it by its resource name. For example, this adds a the `site` resource:
+
+```ruby
+site 'foo'
+```
+
+## Target Mode
+
+{{< readfile file="content/reusable/md/target_mode_summary.md" >}} For more information on Target Mode, see the [Target Mode documentation]({{< relref "/target_mode.md" >}}).
+
+{{< readfile file="/reusable/md/target_mode_custom_resource.md" >}}
+
+### Example
+
+{{< readfile file="/reusable/md/target_mode_custom_resource_example.md" >}}
+
+## Unified Mode
+
+{{< readfile file="content/reusable/md/unified_mode_overview.md" >}}
+
+For more information on Unified Mode, see the [Unified Mode documentation]({{< relref "/unified_mode.md" >}}).
+
+### Enable Unified Mode
+
+{{< readfile file="content/reusable/md/unified_mode_enable.md" >}}
+
+## Learn more
+
+See these resources to learn more about custom resources:
+
+- See the LearnChef interactive tutorial: [Extending Chef Infra: Custom Resources](https://www.chef.io/training/tutorials).
+- For a description of available methods, see the [custom resources glossary]({{< relref "custom_resource_glossary" >}}).
+- For running resources in Target Mode, see the [Target Mode documentation]({{< relref "target_mode" >}}).
+- For running resources in Unified Mode, see the [Unified Mode documentation]({{< relref "unified_mode" >}}).
diff --git a/content/custom_resources_notes.md b/content/custom_resources_notes.md
new file mode 100644
index 0000000..1ddf186
--- /dev/null
+++ b/content/custom_resources_notes.md
@@ -0,0 +1,235 @@
++++
+title = "Custom Resources Notes"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+aliases = ["/custom_resources_notes.html", "resources/custom_resources_notes"]
+
+product = ["client", "workstation"]
+
+[menu]
+ [menu.infra]
+ title = "Migration Notes"
+ identifier = "chef_infra/resources/custom_resources/custom_resources_notes.md Custom Resource Guide"
+ parent = "chef_infra/resources/custom_resources"
+ weight = 70
++++
+
+{{< warning >}}
+
+This page mentions multiple ways of building custom resources. Chef Software recommends you try the approach outlined in the [Custom Resource documentation]({{< relref "custom_resources.md" >}}) first, before trying the resource/provider pair (older approach) or library type (pure Ruby) approaches. If you run into issues while designing 12.5-style custom resources, please ask for help in the [Chef Mailing List](https://discourse.chef.io) or [file a bug](https://github.com/chef/chef/issues/new) for Chef Infra Client.
+
+{{< /warning >}}
+
+## Custom Resources
+
+This is the recommended way of writing resources for all users. There are two gotchas which we're working through:
+
+1. For helper functions that you used to write in your provider code or used to mixin to your provider code, you have to use an `action_class do ... end` block.
+1. You can't subclass, and must use mixins for code-sharing (which is really a best practice anyway -- for example, see languages like rust which don't support sub-classing).
+
+in `resources/whatever.rb`:
+
+```ruby
+resource_name :my_resource
+provides :my_resource
+
+property :foo, String, name_property: true
+extend MyResourceHelperFunctions # probably only used for common properties which is why you extend with class methods
+
+action :run do
+ # helpers must be defined inside the action_class block
+ a_helper()
+ # you will save yourself some pain by referring to properties with `new_resource.foo` and not `foo`
+ # since the latter works most of the time, but will troll you with odd scoping problems, while the
+ # former just works.
+ puts new_resource.foo
+end
+
+action_class do
+ include MyProviderHelperFunctions
+
+ def a_helper
+ end
+end
+```
+
+## "Old school" LWRPS
+
+This method isn't recommended, but is preferable to writing library resources/providers (as described below). It has the same functionality as library providers, only you can't subclass and must use mixins for code sharing (which is good).
+
+in `resources/my_resource.rb`:
+
+```ruby
+resource_name :my_resource
+provides :my_resource
+
+property :foo, String, name_property: true
+extend MyResourceHelperFunctions # probably only used for common properties which is why you extend with class methods
+```
+
+in `providers/my_resource.rb`:
+
+```ruby
+# you have to worry about this
+def whyrun_supported?
+ true
+end
+
+include MyProviderHelperFunctions
+
+def a_helper
+end
+
+action :run do
+ a_helper()
+
+ # here you have to use new_resource.foo
+ puts new_resource.foo
+end
+```
+
+## Library Resources/Providers
+
+Library resources are discouraged since you can shoot yourself in the foot. They used to be encouraged back before Chef Infra Client 12.0 `provides` was introduced since it allowed for renaming the resource so that it didn't have to be prefixed by the cookbook name.
+
+There are many ways to go wrong writing library providers. One of the biggest issues is that internal Chef Infra Client code superficially looks like a library provider, but it's not. Chef internal resources don't inherit from `LWRPBase` and we've had to manually create resources directly through `Chef::Resource::File.new()`, we also haven't been able to `use_inline_resources` and not had access to other niceties that cookbook authors have had access to for years now. We've got some modernization of internal Chef cookbook code now and resources like `apt_update` and `apt_repository` in core have started to be written more like cookbook code should be written, but core resources are actually behind the curve and are bad code examples.
+
+in `libraries/resource_my_resource.rb`:
+
+```ruby
+class MyBaseClass
+ class Resource
+ class MyResource < Chef::Resource::LWRPBase # it's important to inherit from LWRPBase
+ resource_name :my_resource
+ provides :my_resource
+
+ property :foo, String, name_property: true
+ extend MyResourceHelperFunctions # probably only used for common properties which is why you extend with class methods
+ end
+ end
+end
+```
+
+in `libraries/resource_my_resource.rb`:
+
+```ruby
+class MyBaseClass
+ class Resource
+ class MyProvider < Chef::Provider::LWRPBase # it's important to inherit from LWRPBase
+ # you have to worry about this
+ def whyrun_supported?
+ true
+ end
+
+ include MyProviderHelperFunctions
+
+ def a_helper
+ end
+
+ # NEVER use `def action_run` here -- you defeat use_inline_resources and will break notifications if you do
+ # If you don't understand how use_inline_resources is built and why you have to use the `action` method, and what the implications are and how resource notifications
+ # break if use_inline_resources isn't used and/or is broken, then you should really not be using library providers+resources. You might feel "closer to the metal",
+ # but you're now using a chainsaw without any guard...
+ action :run do
+ a_helper()
+
+ # here you have to use new_resource.foo
+ puts new_resource.foo
+ end
+ end
+ end
+end
+```
+
+## updated_by_last_action
+
+Modern Chef Infra Client code (since Chef Infra Client version 11.0.0) should never have provider code which directly sets `updated_by_last_action` itself.
+
+THIS CODE IS WRONG:
+
+```ruby
+action :run do
+ t = file '/tmp/foo' do
+ content 'foo'
+ end
+ t.run_action(:install)
+ # This is Chef Infra Client 10 code which fell through a timewarp into 2016 -- never use updated_by_last_action in modern Chef Infra Client 11.x/12.x code
+ t.new_resource.updated_by_last_action(true) if t.updated_by_last_action?
+end
+```
+
+That used to be kinda-correct-code-with-awful-edge-cases back in Chef Infra Client version 10. If you're not using that version of Chef Infra Client, please stop writing actions this way.
+
+THIS IS CORRECT:
+
+```ruby
+def whyrun_supported?
+ true
+end
+
+action :run do
+ file '/tmp/foo' do
+ content 'foo'
+ end
+end
+```
+
+That's the magic of `use_inline_resources` (and why `use_inline_resources` is turned on by default in Chef Infra Client 12.5 resources) The sub-resources are defined in a sub-resource collection which is compiled and converged as part of the provider executing. Any resources that update in the sub-resource collection cause the resource itself to be updated automatically. Notifications then fire normally off the resource. It also works to arbitrary levels of nesting of sub-sub-sub-resources being updating causing the wrapping resources to update and fire notifications.
+
+This also gets the why-run case correct. If all the work that you do in your resource is done by calling sub-resources, then why-run should work automatically. All your sub-resources will be NO-OP'd and will report what they would have done instead of doing it.
+
+If you do need to write code which mutates the system through pure-Ruby then you should do so like this:
+
+```ruby
+def whyrun_supported?
+ true
+end
+
+action :run do
+ unless ::File.exist?('/tmp/foo')
+ converge_by('touch /tmp/foo') do
+ ::FileUtils.touch '/tmp/foo'
+ end
+ end
+end
+```
+
+When the `converge_by` block is run in why-run mode, it will only log `touch "/tmp/foo"` and won't run the code inside the block.
+
+A `converge_by` block that isn't wrapped in an idempotency check will always cause the resource to be updated, and will always cause notifications to fire. To prevent this, a properly written resource should wrap all `converge_by` checks with an idempotency check. The [`converge_if_changed`]({{< relref "custom_resources.md#converge_if_changed" >}}) block may be used instead which will wrap a `converge_by` block with an idempotency check for you.
+
+```ruby
+action :run do
+ # This code is bad, it lacks an idempotency check here.
+ # It will always be updated
+ # Chef Infra Client runs will always report a resource being updated
+ # It will run the code in the block on every run
+ converge_by('touch /tmp/foo') do
+ ::FileUtils.touch '/tmp/foo'
+ end
+end
+```
+
+Of course it's simpler to just use Chef Infra Client resources when you can. Compare the equivalent implementations:
+
+```ruby
+action :run do
+ file '/tmp/foo'
+end
+```
+
+is basically the same as this:
+
+```ruby
+action :run do
+ unless ::File.exist?('/tmp/foo')
+ converge_by('touch /tmp/foo') do
+ ::FileUtils.touch '/tmp/foo'
+ end
+ end
+end
+```
+
+You may see a lot of `converge_by` and `updated_by_last_action` in the core chef resources. This is because Chef is written as a declarative language with an imperative language, which means someone has to take the first step and write the declarative file resources in imperative Ruby. As such, core Chef resources may not represent ideal code examples of custom resources.
diff --git a/content/data_bags.md b/content/data_bags.md
new file mode 100644
index 0000000..c7f14d4
--- /dev/null
+++ b/content/data_bags.md
@@ -0,0 +1,518 @@
++++
+title = "About Data Bags"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/data_bags.html", "/secrets.html", "/secrets/", "/essentials_data_bags.html"]
+product = ["client", "server"]
+
+[menu]
+ [menu.infra]
+ title = "Data Bags"
+ identifier = "chef_infra/policyfiles/data_bags.md Data Bags"
+ parent = "chef_infra/policyfiles"
+ weight = 40
++++
+
+{{< readfile file="content/reusable/md/data_bag.md" >}}
+
+## Create a data bag
+
+You can create a data bag in two ways: using knife or manually.
+We recommend using knife, but as long as you create the data bag folders and item JSON files correctly,
+either method is safe and effective.
+
+### Create a data bag with knife
+
+Use the `knife data bag create` command to create data bags and data bag items.
+For example:
+
+```bash
+knife data bag create DATA_BAG_NAME (DATA_BAG_ITEM)
+```
+
+Use the `from file` argument to update data bag items:
+
+```bash
+knife data bag from file BAG_NAME ITEM_NAME.json
+```
+
+As long as a file is in the correct directory structure, knife will be
+able to find the data bag and data bag item with only the name of the
+data bag and data bag item. For example:
+
+```bash
+knife data bag from file BAG_NAME ITEM_NAME.json
+```
+
+will load the following file:
+
+```plain
+data_bags/BAG_NAME/ITEM_NAME.json
+```
+
+Continuing the example above, if you are in the "admins" directory and
+make changes to the file charlie.json, then to upload that change to the
+Chef Infra Server use the following command:
+
+```bash
+knife data bag from file admins charlie.json
+```
+
+In some cases, such as when knife isn't being run from the root
+directory for the chef-repo, the full path to the data bag item may be
+required. For example:
+
+```bash
+knife data bag from file BAG_NAME /path/to/file/ITEM_NAME.json
+```
+
+### Manually
+
+One or more data bags and data bag items can be created manually under
+the `data_bags` directory in the chef-repo. Any method can be used to
+create the data bag folders and data bag item JSON files. For example:
+
+```bash
+mkdir data_bags/admins
+```
+
+would create a data bag folder named `admins`. The equivalent command
+for using knife is:
+
+```bash
+knife data bag create admins
+```
+
+A data bag item can be created manually in the same way as the data bag,
+but by also specifying the file name for the data bag item (this example
+is using vi, a visual editor for UNIX):
+
+```bash
+vi data_bags/admins/charlie.json
+```
+
+would create a data bag item named "charlie.json" under the "admins"
+sub-directory in the `data_bags` directory of the chef-repo. The
+equivalent command for using knife is:
+
+```bash
+knife data bag create admins charlie
+```
+
+## Store data in a data bag
+
+When the chef-repo is cloned from GitHub, the following occurs:
+
+- A directory named `data_bags` is created.
+- For each data bag, a sub-directory is created that has the same name
+ as the data bag.
+- For each data bag item, a JSON file is created and placed in the
+ appropriate sub-directory.
+
+The `data_bags` directory can be placed under version source control.
+
+When deploying from a private repository using a data bag, use the
+`deploy_key` option to ensure the private key is present:
+
+```ruby
+{
+ 'id': 'my_app',
+ ... (truncated) ...
+ 'deploy_key': 'ssh_private_key'
+}
+```
+
+where `ssh_private_key` is the same SSH private key as used with a
+private git repository and the new lines converted to `\n`.
+
+### Directory structure
+
+All data bags are stored in the `data_bags` directory of the chef-repo.
+This directory structure is understood by knife so that the full path
+doesn't need to be entered when working with data bags from the command
+line. An example of the `data_bags` directory structure:
+
+```text
+. chef-repo
+└── data_bags
+ ├── README.md
+ ├─── admins
+ │ ├── README.md
+ │ ├── charlie.json
+ │ ├── bob.json
+ │ └── tom.json
+ ├─── db_users
+ │ ├── README.md
+ │ ├── charlie.json
+ │ ├── bob.json
+ │ └── sarah.json
+ └─── db_config
+ ├── README.md
+ ├── small.json
+ ├── medium.json
+ └── large.json
+```
+
+where `admins`, `db_users`, and `db_config` are the names of individual
+data bags and all the files that end with `.json` are the individual
+data bag items.
+
+### Data bag items
+
+{{< readfile file="content/reusable/md/data_bag_item.md" >}}
+
+## Encrypt a data bag item
+
+{{< readfile file="content/reusable/md/data_bag_encryption.md" >}}
+
+### Encryption versions
+
+The manner by which a data bag item is encrypted depends on the Chef
+Infra Client version used. See the following:
+
+|Infra Client version|Encryption v0|Encryption v1|Encryption v2|Encryption v3|
+|:--|:---:|:---:|:---:|:---:|
+|10.x|`R` `W`||||
+|11.0+|`R`|`R` `W`|||
+|11.6+|`R` `D`|`R` `D`|`R` `W`||
+|13.0|`R` `D`|`R` `D`|`R` `D`|`R` `W`|
+
+`R` = read
+`W` = write
+`D` = disable
+
+#### Version 0
+
+Chef Infra Client 0.10+
+
+- Uses YAML serialization format to encrypt data bag items
+- Uses Base64 encoding to preserve special characters
+- Uses AES-256-CBC encryption, as defined by the OpenSSL package in the Ruby Standard Library
+- [Shared secret encryption](https://en.wikipedia.org/wiki/Symmetric-key_algorithm); an encrypted file can only be decrypted by a node or a user with the same shared secret
+- Recipes load encrypted data with access to the shared secret in a file on the node or from a URI path
+- Decrypts only data bag item values. Keys are encrypted but searchable
+- Data bag `id` value is unencrypted for tracking data bag items
+
+#### Version 1
+
+Chef Infra Client 11.0+
+
+- Version 0
+- Uses JSON serialization format _instead of_ YAML to encrypt data bag items
+- Adds random initialization vector encryption for each value to protect against cryptanalysis
+
+#### Version 2
+
+Chef Infra Client 11.6+
+
+- Version 1
+- Option to disable versions 0 and 1
+- Adds Encrypt-then-MAC(EtM) protection
+
+#### Version 3
+
+Chef Infra Client 13.0+
+
+- Option to disable version 0, 1, and 2
+
+### Knife options
+
+knife can encrypt and decrypt data bag items when the `knife data bag`
+subcommand is run with the `create`, `edit`, `from file`, or `show`
+arguments and the following options:
+
+| Option | Description |
+|--------------------|-------------------------------------------------------------|
+| `--secret SECRET` | The encryption key that's used for values contained within a data bag item. If `secret` isn't specified, Chef Infra Client looks for a secret at the path specified by the `encrypted_data_bag_secret` setting in the client.rb file. |
+| `--secret-file FILE` | The path to the file that contains the encryption key. |
+
+### Secret keys
+
+{{< readfile file="content/reusable/md/data_bag_encryption_secret_key.md" >}}
+
+### Encrypt
+
+A data bag item is encrypted using a knife command similar to:
+
+```bash
+knife data bag create passwords mysql --secret-file /tmp/my_data_bag_key
+```
+
+where "passwords" is the name of the data bag, "mysql" is the name of
+the data bag item, and "/tmp/my_data_bag_key" is the path to the
+location in which the file that contains the secret-key is located.
+knife will ask for user credentials before the encrypted data bag item
+is saved.
+
+### Verify encryption
+
+When the contents of a data bag item are encrypted, they won't be
+readable until they're decrypted. Encryption can be verified with a
+knife command similar to:
+
+```bash
+knife data bag show passwords mysql
+```
+
+where "passwords" is the name of the data bag and "mysql" is the name of
+the data bag item. This will return something similar to:
+
+```bash
+id: mysql
+pass:
+cipher: aes-256-cbc
+encrypted_data: JZtwXpuq4Hf5ICcepJ1PGQohIyqjNX6JBc2DGpnL2WApzjAUG9SkSdv75TfKSjX4
+iv: VYY2qx9b4r3j0qZ7+RkKHg==
+version: 1
+user:
+cipher: aes-256-cbc
+encrypted_data: 10BVoNb/plkvkrzVdybPgFFII5GThZ3Op9LNkwVeKpA=
+iv: uIqKHZ9skJlN2gpJoml6rQ==
+version: 1
+```
+
+### Decrypt
+
+An encrypted data bag item is decrypted with a knife command similar to:
+
+```bash
+knife data bag show --secret-file /tmp/my_data_bag_key passwords mysql
+```
+
+that will return JSON output similar to:
+
+```json
+{
+ "id": "mysql",
+ "pass": "thesecret123",
+ "user": "fred"
+}
+```
+
+## Edit a data bag item
+
+A data bag can be edited in two ways: using knife or by using the Chef
+management console.
+
+### Edit a data bag with knife
+
+{{< readfile file="content/workstation/reusable/md/knife_data_bag_edit.md" >}}
+
+{{< readfile file="content/workstation/reusable/md/knife_data_bag_edit_item.md" >}}
+
+## Use data bags
+
+Data bags can be accessed in the following ways:
+
+### Search
+
+{{< readfile file="content/reusable/md/data_bag.md" >}}
+
+{{< readfile file="content/reusable/md/search_data_bag.md" >}}
+
+### Environments
+
+Values that are stored in a data bag are global to the organization and
+are available to any environment. The two main strategies that can
+be used to store shared environment data within a data bag: by using a
+top-level key that corresponds to the environment or by using separate
+items for each environment.
+
+A data bag stores a top-level key for an environment might look
+something like this:
+
+```json
+{
+ "id": "some_data_bag_item",
+ "production" : {
+ # Hash with all your data here
+ },
+ "testing" : {
+ # Hash with all your data here
+ }
+}
+```
+
+When using the data bag in a recipe, that data can be accessed from a
+recipe using code similar to:
+
+```ruby
+data_bag_item[node.chef_environment]['some_other_key']
+```
+
+The other approach is to use separate items for each environment.
+Depending on the amount of data, it may all fit nicely within a single
+item. If this is the case, then creating different items for each
+environment may be a simple approach to providing shared environment values
+within a data bag. However, this approach is more time-consuming and may
+not scale to large environments or when the data must be stored in
+many data bag items.
+
+### Recipes
+
+Data bags can be accessed by a recipe in the following ways:
+
+- Loaded by name when using the Chef Infra Language. Use this approach when a
+ only single, known data bag item is required.
+- Accessed through the search indexes. Use this approach when more
+ than one data bag item is required or when the contents of a data
+ bag are looped through. The search indexes will bulk-load all of the
+ data bag items, which will result in a lower overhead than if each
+ data bag item were loaded by name.
+
+#### Load with Chef Infra Language
+
+The Chef Infra Language provides access to data bags and data bag items
+(including encrypted data bag items) with the following methods:
+
+- `data_bag(bag)`, where `bag` is the name of the data bag.
+- `data_bag_item('bag_name', 'item', 'secret')`, where `bag` is the
+ name of the data bag and `item` is the name of the data bag item. If
+ `'secret'` isn't specified, Chef Infra Client will look for a
+ secret at the path specified by the `encrypted_data_bag_secret`
+ setting in the client.rb file.
+
+The `data_bag` method returns an array with a key for each of the data
+bag items that are found in the data bag.
+
+Some examples:
+
+To load the secret from a file:
+
+```ruby
+data_bag_item('bag', 'item', IO.read('secret_file'))
+```
+
+To load a single data bag item named `admins`:
+
+```ruby
+data_bag('admins')
+```
+
+The contents of a data bag item named `justin`:
+
+```ruby
+data_bag_item('admins', 'justin')
+```
+
+will return something similar to:
+
+```ruby
+# => {'comment'=>'Justin Currie', 'gid'=>1005, 'id'=>'justin', 'uid'=>1005, 'shell'=>'/bin/zsh'}
+```
+
+If `item` is encrypted, `data_bag_item` will automatically decrypt it
+using the key specified above, or (if none is specified) by the
+`Chef::Config[:encrypted_data_bag_secret]` method, which defaults to
+`/etc/chef/encrypted_data_bag_secret`.
+
+#### Create and edit
+
+Creating and editing the contents of a data bag or a data bag item from
+a recipe isn't recommended. The recommended method of updating a data
+bag or a data bag item is to use knife and the `knife data bag`
+subcommand. If this action must be done from a recipe, please note the
+following:
+
+- If two operations concurrently attempt to update the contents of a
+ data bag, the last-written attempt will be the operation to update
+ the contents of the data bag. This situation can lead to data loss,
+ so organizations should take steps to ensure that only one Chef
+ Infra Client is making updates to a data bag at a time.
+- Altering data bags from the node when using the open source Chef
+ Infra Server requires the node's API client to be granted admin
+ privileges. In most cases, this isn't advisable.
+
+and then take steps to ensure that any subsequent actions are done
+carefully. The following examples show how a recipe can be used to
+create and edit the contents of a data bag or a data bag item using the
+`Chef::DataBag` and `Chef::DataBagItem` objects.
+
+To create a data bag from a recipe:
+
+```ruby
+users = Chef::DataBag.new
+users.name('users')
+users.create
+```
+
+To create a data bag item from a recipe:
+
+```ruby
+sam = {
+ 'id' => 'sam',
+ 'Full Name' => 'Sammy',
+ 'shell' => '/bin/zsh',
+}
+databag_item = Chef::DataBagItem.new
+databag_item.data_bag('users')
+databag_item.raw_data = sam
+databag_item.save
+```
+
+To edit the contents of a data bag item from a recipe:
+
+```ruby
+sam = data_bag_item('users', 'sam')
+sam['Full Name'] = 'Samantha'
+sam.save
+```
+
+#### Create users
+
+Chef Infra Client can create users on systems based on the contents of a
+data bag. For example, a data bag named "admins" can contain a data bag
+item for each of the administrators that will manage the various systems
+that each Chef Infra Client is maintaining. A recipe can load the data
+bag items and then create user accounts on the target system with code
+similar to the following:
+
+```ruby
+# Load the keys of the items in the 'admins' data bag
+admins = data_bag('admins')
+
+admins.each do |login|
+ # This causes a round-trip to the server for each admin in the data bag
+ admin = data_bag_item('admins', login)
+ homedir = '/home/#{login}'
+
+ # for each admin in the data bag, make a user resource
+ # to ensure they exist
+ user(login) do
+ uid admin['uid']
+ gid admin['gid']
+ shell admin['shell']
+ comment admin['comment']
+ home homedir
+ manage_home true
+ end
+end
+
+# Create an "admins" group on the system
+# You might use this group in the /etc/sudoers file
+# to provide sudo access to the admins
+group 'admins' do
+ gid '999'
+ members 'admins'
+end
+```
+
+### `chef-solo`
+
+chef-solo can load data from a data bag as long as the contents of that
+data bag are accessible from a directory structure that exists on the
+same machine as chef-solo. The location of this directory is
+configurable using the `data_bag_path` option in the solo.rb file. The
+name of each sub-directory corresponds to a data bag and each JSON file
+within a sub-directory corresponds to a data bag item. Search isn't
+available in recipes when they're run with chef-solo; use the
+`data_bag()` and `data_bag_item()` functions to access data bags and
+data bag items.
+
+{{< note >}}
+
+Use the `chef-solo-search` cookbook library to add data bag search
+capabilities to a chef-solo environment:
+.
+
+{{< /note >}}
diff --git a/content/debug.md b/content/debug.md
new file mode 100644
index 0000000..2694396
--- /dev/null
+++ b/content/debug.md
@@ -0,0 +1,352 @@
++++
+title = "Debug Recipes, Chef Infra Client Runs"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/debug.html"]
+
+[menu]
+ [menu.infra]
+ title = "Debug Recipes, Client Runs"
+ identifier = "chef_infra/cookbook_reference/recipes/debug.md Debug Recipes, Client Runs"
+ parent = "chef_infra/cookbook_reference/recipes"
+ weight = 20
++++
+
+Elements of good approaches to building cookbooks and recipes that are
+reliable include:
+
+* A consistent syntax pattern when constructing recipes
+* Using the same patterns in Ruby
+* Using resources included in Chef Infra Client or community cookbooks before creating custom ones
+
+Ideally, the best way to debug a recipe is to not have to debug it in the first place. That said, the following sections discuss various approaches to debugging recipes and failed Chef Infra Client runs.
+
+## Basic
+
+Some simple ways to identify common issues that can trigger recipe and/or Chef Infra Client run failures include:
+
+* Using an empty run-list
+* Using verbose logging with knife
+* Using logging with Chef Infra Client
+* Using the **log** resource in a recipe to define custom logging
+
+### Empty Run-lists
+
+{{< readfile file="content/reusable/md/node_run_list_empty.md" >}}
+
+### Knife
+
+Use the verbose logging that's built into knife:
+
+`-V`, `--verbose`
+
+: Set for more verbose outputs. Use `-VV` for much more verbose outputs. Use `-VVV` for maximum verbosity, which may provide more information than is actually helpful.
+
+{{< note >}}
+
+Plugins don't always support verbose logging.
+
+{{< /note >}}
+
+### Chef Infra Client
+
+Use the verbose logging that's built into Chef Infra Client:
+
+`-l LEVEL`, `--log_level LEVEL`
+
+: The level of logging to be stored in a log file. Possible levels: `auto` (default), `debug`, `error`, `fatal`, `info`, `trace`, or `warn`. Default value: `warn` (when a terminal is available) or `info` (when a terminal isn't available).
+
+`-L LOGLOCATION`, `--logfile c`
+
+: The location of the log file. This is recommended when starting any executable as a daemon. Default value: `STDOUT`.
+
+### log Resource
+
+Use the **log** resource to create log entries. The **log** resource
+behaves like any other resource: built into the resource collection
+during the compile phase, and then run during the execution phase. (To
+create a log entry that isn't built into the resource collection, use
+`Chef::Log` instead of the **log** resource.)
+
+{{< note >}}
+
+By default, every log resource that executes will count as an updated
+resource in the updated resource count at the end of a Chef run. You can
+disable this behavior by adding `count_log_resource_updates false` to
+your Chef `client.rb` configuration file.
+
+{{< /note >}}
+
+New in 12.0, `-o RUN_LIST_ITEM`. Changed in 12.0 `-f` no longer allows unforked intervals, `-i SECONDS` is applied before a Chef Infra Client run.
+
+#### Syntax
+
+{{< readfile file="content/reusable/md/resource_log_syntax.md" >}}
+
+#### Actions
+
+The log resource has the following actions:
+
+`:nothing`
+
+: {{< readfile file="content/reusable/md/resources_common_actions_nothing.md" >}}
+
+`:write`
+
+: Default. Write to log.
+
+#### Properties
+
+{{< readfile file="content/reusable/md/resource_log_properties.md" >}}
+
+#### Examples
+
+The following examples demonstrate various approaches for using
+resources in recipes:
+
+##### Specify a Log Entry
+
+```ruby
+log 'a string to log'
+```
+
+##### Set debug logging level
+
+{{< readfile file="content/reusable/md/resource_log_set_debug.md" >}}
+
+##### Create log entry when the contents of a data bag are used
+
+{{< readfile file="content/reusable/md/resource_log_set_debug.md" >}}
+
+##### Add a message to a log file
+
+```ruby
+log 'message' do
+ message 'This is the message that will be added to the log.'
+ level :info
+end
+```
+
+## Advanced
+
+Some more complex ways to debug issues with a Chef Infra Client run
+include:
+
+* Using the **chef_handler** resource
+* Using the chef-shell and the **breakpoint** resource to add breakpoints to recipes, and to then step through the recipes using the breakpoints
+* Using the `debug_value` method from chef-shell to identify the locations from which attribute values are being set
+* Using the `ignore_failure` method in a recipe to force Chef Infra Client to move past an error to see what else is going on in the recipe, outside of a known failure
+* Using chef-solo to run targeted Chef Infra Client runs for specific scenarios
+
+### chef_handler
+
+{{< readfile file="content/reusable/md/handler.md" >}}
+
+{{< readfile file="content/reusable/md/handler_types.md" >}}
+
+Read more [about exception, report, and start handlers](/handlers/).
+
+### chef-shell
+
+{{< readfile file="content/reusable/md/chef_shell_summary.md" >}}
+
+{{< readfile file="content/reusable/md/chef_shell_modes.md" >}}
+
+#### Configure
+
+{{< readfile file="content/reusable/md/chef_shell_config.md" >}}
+
+#### chef-shell.rb
+
+{{< readfile file="content/reusable/md/chef_shell_config_rb.md" >}}
+
+#### Run as a Chef Infra Client
+
+{{< readfile file="content/reusable/md/chef_shell_run_as_chef_client.md" >}}
+
+#### Manage
+
+{{< readfile file="content/reusable/md/chef_shell_manage.md" >}}
+
+### breakpoint Resource
+
+{{< readfile file="content/reusable/md/chef_shell_breakpoints.md" >}}
+
+Use the **breakpoint** resource to add breakpoints to recipes. Run the
+chef-shell in Chef Infra Client mode, and then use those breakpoints to
+debug recipes. Breakpoints are ignored by Chef Infra Client during an
+actual Chef Infra Client run. That said, breakpoints are typically used
+to debug recipes only when running them in a non-production environment,
+after which they're removed from those recipes before the parent
+cookbook is uploaded to the Chef Infra Server.
+
+#### Syntax
+
+A **breakpoint** resource block creates a breakpoint in a recipe:
+
+```ruby
+breakpoint 'name' do
+ action :break
+end
+```
+
+where
+
+`:break` will tell Chef Infra Client to stop running a recipe; can
+only be used when Chef Infra Client is being run in chef-shell mode
+
+#### Actions
+
+The breakpoint resource has the following actions:
+
+`:break`
+
+: Use to add a breakpoint to a recipe.
+
+`:nothing`
+
+: {{< readfile file="content/reusable/md/resources_common_actions_nothing.md" >}}
+
+#### Attributes
+
+This resource doesn't have any properties.
+
+#### Examples
+
+The following examples demonstrate various approaches for using resources in recipes:
+
+##### A recipe without a breakpoint
+
+```ruby
+yum_key node['yum']['elrepo']['key'] do
+ url node['yum']['elrepo']['key_url']
+ action :add
+end
+
+yum_repository 'elrepo' do
+ description 'ELRepo.org Community Enterprise Linux Extras Repository'
+ key node['yum']['elrepo']['key']
+ mirrorlist node['yum']['elrepo']['url']
+ includepkgs node['yum']['elrepo']['includepkgs']
+ exclude node['yum']['elrepo']['exclude']
+ action :create
+end
+```
+
+##### The same recipe with breakpoints
+
+```ruby
+breakpoint "before yum_key node['yum']['repo_name']['key']" do
+ action :break
+end
+
+yum_key node['yum']['repo_name']['key'] do
+ url node['yum']['repo_name']['key_url']
+ action :add
+end
+
+breakpoint "after yum_key node['yum']['repo_name']['key']" do
+ action :break
+end
+
+breakpoint "before yum_repository 'repo_name'" do
+ action :break
+end
+
+yum_repository 'repo_name' do
+ description 'description'
+ key node['yum']['repo_name']['key']
+ mirrorlist node['yum']['repo_name']['url']
+ includepkgs node['yum']['repo_name']['includepkgs']
+ exclude node['yum']['repo_name']['exclude']
+ action :create
+end
+
+breakpoint "after yum_repository 'repo_name'" do
+ action :break
+end
+```
+
+where the name of each breakpoint is an arbitrary string. In the
+previous examples, the names are used to indicate if the breakpoint is
+before or after a resource, and then also to specify which resource.
+
+### Step Through Run-list
+
+{{< readfile file="content/reusable/md/chef_shell_step_through_run_list.md" >}}
+
+### Debug Existing Recipe
+
+{{< readfile file="content/reusable/md/chef_shell_debug_existing_recipe.md" >}}
+
+### Advanced Debugging
+
+{{< readfile file="content/reusable/md/chef_shell_advanced_debug.md" >}}
+
+### debug_value
+
+Use the `debug_value` method to discover the location within the attribute precedence hierarchy from which a particular attribute (or sub-attribute) is set. This method is available when running chef-shell in Chef Infra Client mode:
+
+```bash
+chef-shell -z
+```
+
+For example, the following attributes exist in a cookbook. Some are defined in a role file:
+
+```ruby
+default_attributes 'test' => { 'source' => 'role default' }
+override_attributes 'test' => { 'source' => 'role override' }
+```
+
+And others are defined in an attributes file:
+
+```ruby
+default[:test][:source] = 'attributes default'
+normal[:test][:source] = 'attributes normal'
+override[:test][:source] = 'attributes override'
+```
+
+To debug the location in which the value of `node[:test][:source]` is set, use chef-shell and run a command similar to:
+
+```ruby
+pp node.debug_value('test', 'source')
+```
+
+This will pretty-print return all of the attributes and sub-attributes as an array of arrays; `:not_present` is returned for any attribute without a value:
+
+```bash
+[['set_unless_enabled?', false],
+ ['default', 'attributes default'],
+ ['env_default', :not_present],
+ ['role_default', 'role default'],
+ ['force_default', :not_present],
+ ['normal', 'attributes normal'],
+ ['override', 'attributes override'],
+ ['role_override', 'role override'],
+ ['env_override', :not_present],
+ ['force_override', :not_present],
+ ['automatic', :not_present]]
+```
+
+where
+
+* `set_unless_enabled` indicates if the attribute collection is in `set_unless` mode; this typically returns `false`
+* Each attribute type is listed in order of precedence
+* Each attribute value shown is the value that's set for that precedence level
+* `:not_present` is shown for any attribute precedence level that has no attributes
+
+### ignore_failure method
+
+All resources share a set of common actions, attributes, and other properties. Use the following attribute in a resource to help identify where an issue within a recipe may be located:
+
+| Attribute | Description |
+|----------------|---------------------------------------------------------------------------------------|
+| ignore_failure | Continue running a recipe if a resource fails for any reason. Default value: `false`. |
+
+### chef-solo
+
+See [chef-solo (executable)](/ctl_chef_solo/) for complete CTL documentation.
+
+{{< readfile file="content/reusable/md/chef_solo_summary.md" >}}
+
+See [chef-solo (executable)](/ctl_chef_solo/) for complete CTL documentation.
diff --git a/content/definitions_to_custom_resources.md b/content/definitions_to_custom_resources.md
new file mode 100644
index 0000000..5888eac
--- /dev/null
+++ b/content/definitions_to_custom_resources.md
@@ -0,0 +1,174 @@
++++
+title = "Converting Definitions to Custom Resources"
+gh_repo = "chef-web-docs"
+
+product = ["client", "workstation"]
+
+[menu]
+ [menu.infra]
+ title = "Migrating from Definitions"
+ identifier = "chef_infra/resources/custom_resources/definitions.md Migrating from Definitions"
+ parent = "chef_infra/resources/custom_resources"
+ weight = 50
++++
+
+The definitions feature in Chef Infra has been deprecated and will be removed in a future release. Please migrate existing definitions to Custom Resources.
+
+This guide describes how to migrate from an existing Definition to a Custom Resource.
+
+If you are creating a Custom Resource from scratch please see the [Custom Resource Getting Started Guide]({{< relref "custom_resources" >}}) instead.
+
+## Definitions
+
+A definition behaved like a compile-time macro that was reusable across recipes. A definition was typically created by wrapping arbitrary code around Chef Infra resources that were declared as if they were in a recipe. A definition was then used in one (or more) actual recipes as if the definition were a resource.
+
+Though a definition looks like a resource, and at first glance seems like it could be used interchangeably, some important differences exist.
+
+Definitions:
+
+- Aren't true resources
+- Are processed when resource collection is compiled, not when a node
+ is converged
+- Don't support common resource properties, such as `notifies`, `compile_time`,
+ `subscribes`, `only_if`, `not_if`, and `sensitive`
+- Don't support input validation in passed arguments, unlike a
+ resource which supports validation with properties
+- Don't support `why-run` mode
+- Can't report to Chef Automate
+- Can't be tested with ChefSpec
+- Some Definition parameters have known bugs, and won't be fixed
+
+## Syntax
+
+A definition had four components:
+
+- A resource name
+- Zero or more arguments that define parameters and their default values;
+ if a default value wasn't specified, it was assumed to be `nil`
+- A hash that could have been used within a definition's body to
+ provide access to parameters and their values
+- The body of the definition
+
+The basic syntax of a definition was:
+
+```ruby
+define :my_definition_name do
+ body
+end
+```
+
+More commonly, the usage incorporated arguments to the definition:
+
+```ruby
+define :my_definition_name, parameter: :argument, parameter: :argument do
+ body(likely referencing the params hash)
+end
+```
+
+The following simple example shows a definition with no arguments (a parameter-less macro in the truest sense):
+
+```ruby
+define :prime_myfile do
+ file '/etc/myfile' do
+ content 'some content'
+ end
+end
+```
+
+An example showing the use of parameters, with a parameter named `port` that defaults to `4000` rendered into a **template** resource, would look like:
+
+```ruby
+define :prime_myfile, port: 4000 do
+ template '/etc/myfile' do
+ source 'myfile.erb'
+ variables({
+ port: params[:port],
+ })
+ end
+end
+```
+
+Or the following definition, which looks like a resource when used in a recipe, but also contained **directory** and **file** resources that were repeated, but with slightly different parameters:
+
+```ruby
+define :host_porter, port: 4000, hostname: nil do
+ params[:hostname] ||= params[:name]
+
+ directory '/etc/#{params[:hostname]}' do
+ recursive true
+ end
+
+ file '/etc/#{params[:hostname]}/#{params[:port]}' do
+ content 'some content'
+ end
+end
+```
+
+which was then used in a recipe like this:
+
+```ruby
+host_porter node['hostname'] do
+ port 4000
+end
+
+host_porter 'www1' do
+ port 4001
+end
+```
+
+## Migrating to Custom Resources
+
+We highly recommend migrating existing definitions to custom resources to unlock the full feature set of Chef Infra resources. The following example shows a definition and that same definition rewritten as a custom resource.
+
+### Initial Definition Code
+
+The following definition processes unique hostnames and ports, passed on as parameters:
+
+```ruby
+define :host_porter, port: 4000, hostname: nil do
+ params[:hostname] ||= params[:name]
+
+ directory '/etc/#{params[:hostname]}' do
+ recursive true
+ end
+
+ file '/etc/#{params[:hostname]}/#{params[:port]}' do
+ content 'some content'
+ end
+end
+```
+
+### Migrated to a Custom Resource
+
+The definition is improved by rewriting it as a custom resource. This uses properties to accept input and has a single `:create` action:
+
+```ruby
+property :port, Integer, default: 4000
+property :hostname, String, name_property: true
+
+action :create do
+ directory "/etc/#{hostname}" do
+ recursive true
+ end
+
+ file "/etc/#{hostname}/#{port}" do
+ content 'some content'
+ end
+end
+```
+
+Once written, a custom resource may be used in a recipe just like any resource that's built into Chef Infra. A custom resource gets its name from the cookbook and the name of its file in the `/resources` directory with an underscore (`_`) separating them. For example, a cookbook named `host` with a custom resource file named `porter.rb` in the `/resources` directory would be called `host_porter`. Use it in a recipe like this:
+
+```ruby
+host_porter node['hostname'] do
+ port 4000
+end
+```
+
+or:
+
+```ruby
+host_porter 'www1' do
+ port 4001
+end
+```
diff --git a/content/dsl_handler.md b/content/dsl_handler.md
new file mode 100644
index 0000000..5e1371a
--- /dev/null
+++ b/content/dsl_handler.md
@@ -0,0 +1,77 @@
++++
+title = "About the Handler DSL"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+aliases = ["/dsl_handler.html"]
+
+[menu]
+ [menu.infra]
+ title = "Handler DSL"
+ identifier = "chef_infra/extension_apis/handlers/dsl_handler.md Handler DSL"
+ parent = "chef_infra/extension_apis/handlers"
+ weight = 20
++++
+
+{{< readfile file="content/reusable/md/dsl_handler_summary.md" >}}
+
+## on Method
+
+{{< readfile file="content/reusable/md/dsl_handler_method_on.md" >}}
+
+## Event Types
+
+{{< readfile file="content/reusable/md/dsl_handler_event_types.md" >}}
+
+## Examples
+
+The following examples show ways to use the Handler DSL.
+
+### Send Email
+
+{{< readfile file="content/reusable/md/dsl_handler_slide_send_email.md" >}}
+
+#### Define How Email is Sent
+
+{{< readfile file="content/reusable/md/dsl_handler_slide_send_email_library.md" >}}
+
+#### Add the Handler
+
+{{< readfile file="content/reusable/md/dsl_handler_slide_send_email_handler.md" >}}
+
+#### Test the Handler
+
+{{< readfile file="content/reusable/md/dsl_handler_slide_send_email_test.md" >}}
+
+### etcd Locks
+
+{{< readfile file="content/reusable/md/dsl_handler_example_etcd_lock.md" >}}
+
+### HipChat Notifications
+
+{{< readfile file="content/reusable/md/dsl_handler_example_hipchat.md" >}}
+
+### `attribute_changed` event hook
+
+In a cookbook library file, you can add this to print out all
+attribute changes in cookbooks:
+
+```ruby
+Chef.event_handler do
+ on :attribute_changed do |precedence, key, value|
+ puts "setting attribute #{precedence}#{key.map { |n| "[\"#{n}\"]" }.join} = #{value}"
+ end
+end
+```
+
+If you want to setup a policy that override attributes should never be
+used:
+
+```ruby
+Chef.event_handler do
+ on :attribute_changed do |precedence, key, value|
+ raise 'override policy violation' if precedence == :override
+ end
+end
+```
diff --git a/content/enterprise_chef.md b/content/enterprise_chef.md
new file mode 100644
index 0000000..a63fa68
--- /dev/null
+++ b/content/enterprise_chef.md
@@ -0,0 +1,78 @@
++++
+title = "Progress Chef Enterprise Edition"
+
+[menu]
+ [menu.overview]
+ title = "Enterprise Edition"
+ identifier = "overview/enterprise/enterprise edition"
+ parent = "overview/enterprise"
+ weight = 20
++++
+
+The Enterprise edition of Progress Chef expands on the basic functionalities provided by the open-source version of Chef. It incorporates enhanced features and prompt and timely support. It's better tailored to address the demands of large and medium-sized enterprises, irrespective of the domain.
+
+Some of the features and services provided in Enterprise Chef that aren't present in the Community edition are as follows:
+
+## Supply chain integrity of distribution and SLOs
+
+Enterprise Chef distributions have scrupulously verified bundled dependencies that often come with a signatory commitment of authenticity from Progress. Additionally, Enterprise Chef has Service Level Objectives (SLOs) for response and resolution time and any other distribution objectives.
+
+## Public company security standards for customers
+
+Enterprise Chef adheres to multiple compliance standards, such as SOC, PCI, DSS, ISO 90078 and more. Progress, a publicly traded company, reports identified CVEs promptly to Enterprise customers under responsible disclosure norms.
+
+## SLA-based services provided to enterprise customers
+
+Enterprise Customers have SLAs tied to incident response and security fixes on CVEs, including identification, notification, mitigation and resolution. The Chef Professional Services team provides SLA-backed technical support for proactive monitoring and maintenance. Premium customers are provided with Customer Success Managers or Account Managers for regular sync-ups and issue resolutions.
+
+## Cyber insurance and indemnification
+
+Progress has a comprehensive indemnification policy under our agreed Progress Chef EULA, which offers maximum protection to our customers. To understand our indemnification obligation for intellectual property infringement claims against you for using the product, exceptions and other options, see [section 10.1 of the Progress Chef EULA](https://www.chef.io/online-master-agreement).
+
+## Progress Security Operation Centre (SOC) support
+
+Progress SOC verifies and manages compliance with its products, which includes a zero-trust cybersecurity architecture approach, compliance audits and verifications, source-code scanning, external penetration tests, third-party deep-dive code assessments and ongoing coordination with many of the industry's top cybersecurity researchers who assess risk profiles and software exploits.
+
+## Access to Chef premium content
+
+Enterprise users of Chef are provided with [Chef Premium Content](/inspec/profiles/).
+
+Chef Premium Content consists of ready-to-use 100+ curated content for compliance audits, remediation and desktop configuration based on the Center for Internet Security (CIS) certified benchmarks or Defense Information Systems Agency (DISA) and Security Technical Implementation Guides (STIGs).
+
+## Completely managed solution (SaaS)
+
+[Chef SaaS](/saas/) is a cloud-based, completely managed solution for infrastructure, compliance and cloud security automation across entire IT estates. It mirrors all capabilities available on the on-premises version.
+
+## High availability deployment option
+
+Only enterprise customers have access to the high-availability version of Chef through [Chef Automate HA](/automate/ha/) and Chef SaaS. Chef Automate HA supports both on-premises and AWS deployments. Opting for HA will help commercial users with large fleets avoid service and zone failure issues.
+
+## Single pane of visibility with Progress Chef Automate
+
+[Chef Automate](/automate/ha/) has a unified dashboard that provides a consolidated view of an organization's IT estate. It also provides a web-based administration facility, support for compliance, integration with third-party tools, and options for installation in high-availability mode.
+
+## Job orchestration and node management capabilities
+
+Progress Chef Courier is a job orchestration solution that helps you execute and verify Chef actions on any set or subset of nodes and schedule them for immediate, subsequent or period time intervals. Users can access the complete set of job orchestration features, including exceptions, job limits, reports, and notifications, through Chef Courier.
+
+Node management is a feature that will allow users to have a Chef-guided system to perform node enrollment (server/VM/desktop/kiosk/network device/edge), manage skills and gain visibility/insights about nodes.
+
+All information on Chef 360, which hosts Chef Courier, is provided in the [Chef 360 documentation](/360/1.0/). Node Management capabilities are provided in the [Node Management documentation](/360/1.0/node_management/).
+
+## Support for platforms
+
+Enterprise Chef directly [supports 13 platforms](/platforms/#commercial-support-4) commonly used by enterprises and indirectly supports another 18. Commercially supported platforms are extensively tested as part of the development and release process of Chef.
+
+## Integrations
+
+Enterprise Chef guarantees support for issues arising from embedded dependencies or third-party integrations. The commercial version of Chef Automate offers pre-formatted data for integration with other tools like monitoring platforms or ticketing systems. Enterprise Chef offers built-in metrics and APIs for easy access to infrastructure data.
+
+## Useful Chef documentation links
+
+- [About Chef Licenses](/licensing/)
+- [Chef Local License Service Overview](/licensing/local_license_service/)
+- [Progress Chef 360 platform](/360/1.0/)
+- [Chef Automate Overview](/automate/)
+- [Chef SaaS Overview](/saas/)
+- [Chef Automate release Notes](/release_notes_automate/)
+- [Chef Support](https://www.chef.io/support)
diff --git a/content/enterprise_community_chef.md b/content/enterprise_community_chef.md
new file mode 100644
index 0000000..5404019
--- /dev/null
+++ b/content/enterprise_community_chef.md
@@ -0,0 +1,42 @@
++++
+title = "Progress Chef Enterprise vs Community Edition"
+
+
+[menu]
+ [menu.overview]
+ title = "Enterprise vs Community Edition"
+ identifier = "overview/enterprise/enterprise vs community"
+ parent = "overview/enterprise"
+ weight = 10
++++
+
+Enterprise Chef is the commercial offering of the Chef software suite. This version builds upon the core functionalities of open-source Chef, including advanced features, timely support and enhanced capabilities. All of which are designed to meet the needs of larger organizations and complex infrastructures.
+
+Features available in the Enterprise version that can't be availed in the community edition include a GUI (graphical user interface), an analytics dashboard, a bulk grouping tool, customizable views, push functionality, and more.
+
+For enterprises prioritizing scale and technical debt, the commercial version of Chef is the ideal choice. We strongly recommend Enterprise Chef, which provides advanced features, enhanced visibility and exceptional support, giving it an edge over the Community version.
+
+For a detailed list of features and services, see the [Enterprise Chef documentation](/enterprise_chef).
+
+To understand the advantages of Enterprise Chef over Community Chef, see the following table:
+
+| Capabilities | Enterprise Chef | Community Chef |
+| ------------- | --------------- | --------------- |
+| Supply Chain Integrity of Distribution & SLOs. | ✔ | X |
+| Public Company Standards for Managing Customer Environment Security Risks and Incidents | ✔ | X |
+| SLA-based Priority Incident Response and Security Fixes on CVEs | Available with different service tiers | X |
+| Cyber Insurance & Indemnification Hand-holding | ✔ | X |
+| Progress Security Operation Centre (SOC) Support | ✔ | X |
+| Access to Chef Premium Content | ✔ | X |
+| 24/7 Support | ✔ | X |
+| Professional Services | Available with different service tiers | X |
+| Priority Communication on Updated, Releases and New Features | Regular Communications from all customer-facing teams | Communication with the community about new features and releases won't match the frequency of Enterprise users |
+| Access to Beta Releases | Prototype testing, feedback and driving product direction | X |
+| Completely Managed Solution (SaaS) | ✔ | X |
+| HA Deployment Option | Available with Chef Automate and Chef SaaS | X |
+| Dashboard with Insights | ✔ | X |
+| Job Orchestration, Node Management | Users will have access to the entire feature set | Limited features will be available for users |
+| OS Support | Higher number of platforms and OS supported(fit for enterprises with strict guidelines on platforms) | Supports only with platforms (Not meant for large enterprises) |
+| First-Party Integration with Other Products from the Progress Portfolio | ✔ | X |
+| Premium Integrations | ✔ | X |
+| Future Capabilities | Access to facility to upgrade to Chef 260 for all users | Limited Visibility |
diff --git a/content/environments.md b/content/environments.md
new file mode 100644
index 0000000..53b3bf3
--- /dev/null
+++ b/content/environments.md
@@ -0,0 +1,414 @@
++++
+title = "About Environments"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/environments.html"]
+product = ["client", "server"]
+
+[menu]
+ [menu.infra]
+ title = "Environments"
+ identifier = "chef_infra/policyfiles/environments.md Environments"
+ parent = "chef_infra/policyfiles"
+ weight = 60
++++
+
+{{< readfile file="content/reusable/md/environment.md" >}}
+
+## The `_default` environment
+
+Every Chef Infra Server organization must have at least one environment.
+Each organization starts out with a single `_default` environment. The
+`_default` environment can't be modified in any way. Nodes, roles,
+run-lists, cookbooks (and cookbook versions), and attributes specific to
+an organization can only be associated with a custom environment.
+Additional environments can be created to reflect each organization's
+patterns and workflow. For example, creating `production`, `staging`,
+`testing`, and `development` environments.
+
+## Environment attributes
+
+{{< note >}}
+
+{{< readfile file="content/reusable/md/notes_see_attributes_overview.md" >}}
+
+{{< /note >}}
+
+{{< readfile file="content/reusable/md/environment_attribute.md" >}}
+
+### Environment attribute types
+
+There are two types of attributes that can be used with environments:
+
+
+
+## Pinning Cookbooks in environments
+
+Cookbook versions can be pinned in each environment, which allows you to
+control the rollout of new cookbook releases through successive testing
+environments before releasing new cookbook versions into production
+environments. See the environment format examples below for the cookbook
+pinning syntax.
+
+## Environment formats
+
+Environments may be stored on disk (any in source control) in two
+formats:
+
+- As Ruby ( a file that ends with `.rb`); this format isn't available when running Chef Infra Client in local mode
+- As JSON (a file that ends with `.json`)
+
+### Chef language
+
+Each environment is defined as a Ruby file (a file that ends with
+`.rb`). Each environment file should contain the following
+domain-specific attributes:
+
+
+
+
+
+
+
+
+
Setting
+
Description
+
+
+
+
+
cookbook
+
A version constraint for a single cookbook. For example:
+
cookbook 'couchdb', '< 11.0.0'
+
or:
+
cookbook 'my_rails_app', '= 1.2.0'
+
or:
+
cookbook 'gems', '~> 1.4'
+
+
+
cookbook_versions
+
A version constraint for a group of cookbooks. For example:
Optional. A set of attributes to be applied to all nodes, assuming the node doesn't already have a value for the attribute. This is useful for setting global defaults that can then be overridden for specific nodes. If more than one role attempts to set a default value for the same attribute, the last role applied is the role to set the attribute value. When nested attributes are present, they're preserved. For example, to specify that a node that has the attribute apache2 should listen on ports 80 and 443 (unless ports are already specified):
A description of the functionality that's covered. For example:
+
description 'The development environment'
+
+
+
name
+
A unique name within the organization. Each name must be made up of letters (uppercase and lowercase), numbers, underscores, and hyphens: [A-Z][a-z][0-9] and [_-]. Spaces aren't allowed. For example:
+
name 'dev01-24'
+
+
+
override_attributes
+
Optional. A set of attributes to be applied to all nodes, even if the node already has a value for an attribute. This is useful for ensuring that certain attributes always have specific values. If more than one role attempts to set an override value for the same attribute, the last role applied wins. When nested attributes are present, they're preserved. For example:
The parameters in a Ruby file are actually Ruby method calls, so parentheses can be used to provide clarity when specifying numerous or deeply-nested attributes. For example:
+
+A Ruby file for each non-default environment must exist in the
+`environments/` subdirectory of the chef-repo. (If the chef-repo does
+not have this subdirectory, then it should be created.) The complete
+environment has the following syntax:
+
+```ruby
+name 'environment_name'
+description 'environment_description'
+cookbook OR cookbook_versions 'cookbook' OR 'cookbook' => 'cookbook_version'
+default_attributes 'node' => { 'attribute' => [ 'value', 'value', 'etc.' ] }
+override_attributes 'node' => { 'attribute' => [ 'value', 'value', 'etc.' ] }
+```
+
+where both default and override attributes are optional and either a
+cookbook or cookbook versions (one or more) are specified. For example,
+an environment named `dev` that uses the `couchdb` cookbook (version
+11.0.0 or higher) that listens on ports 80 and 443:
+
+```ruby
+name 'dev'
+description 'The development environment'
+cookbook_versions 'couchdb' => '= 11.0.0'
+default_attributes 'apache2' => { 'listen_ports' => %w(80 443) }
+```
+
+Or (using the same scenario) to specify a version constraint for only
+one cookbook:
+
+```ruby
+cookbook 'couchdb', '= 11.0.0'
+```
+
+More than one cookbook version can be specified:
+
+```ruby
+cookbook_versions({
+ 'couchdb' => '= 11.0.0',
+ 'my_rails_app' => '~> 1.2.0'
+})
+```
+
+Attributes are optional and can be set at the default and override
+levels. These will be processed according to attribute precedence. An
+environment attribute will be applied to all nodes within the
+environment, except in places where it's overridden by an attribute
+with higher precedence. For example:
+
+```ruby
+default_attributes 'apache2' => { 'listen_ports' => %w(80 443) }
+```
+
+will have all nodes in the environment (`node[:apache2][:listen_ports]`)
+set to `'80'` and `'443'` unless they were overridden by an attribute
+with higher precedence. For example:
+
+```ruby
+override_attributes 'apache2' => { 'listen_ports' => %w(80 443) }
+```
+
+### JSON
+
+The JSON format for environments maps directly to the domain-specific
+Ruby format: the same settings, attributes, and values, and a similar
+structure and organization, just formatted as JSON. When an environment
+is defined as JSON the file that contains that data must be defined as a
+file that ends with `.json`. For example:
+
+```json
+{
+ "name": "dev",
+ "default_attributes": {
+ "apache2": {
+ "listen_ports": [
+ "80",
+ "443"
+ ]
+ }
+ },
+ "json_class": "Chef::Environment",
+ "description": "",
+ "cookbook_versions": {
+ "couchdb": "= 11.0.0"
+ },
+ "chef_type": "environment"
+}
+```
+
+The JSON format has two additional settings:
+
+
+
+
+
+
+
+
+
Setting
+
Description
+
+
+
+
+
chef_type
+
Always set this to environment. Use this setting for any custom process that consumes environment objects outside of Ruby.
+
+
+
json_class
+
Always set this to Chef::Environment. Chef Infra Client uses this setting to automatically inflate an environment object. If objects are being rebuilt outside of Ruby, ignore it.
+
+
+
+
+## Create environments
+
+An environment can be created in four different ways:
+
+- Create a Ruby file in the environments sub-directory of the
+ chef-repo and then push it to the Chef Infra Server
+- Create a JSON file directly in the chef-repo and then push it
+ to the Chef Infra Server
+- Using knife
+- Using the Chef Infra Server REST API
+
+Once an environment exists on the Chef Infra Server, a node can be
+associated with that environment using the `chef_environment` method.
+
+## Manage environments
+
+Once created, an environment can be managed in several ways:
+
+- By using knife and passing the `-E ENVIRONMENT_NAME` option with
+ `knife cookbook upload`
+- By using Ruby or JSON files that are stored in a version source
+ control system. These files are pushed to the Chef Infra Server
+ using the `knife environment` subcommand and the `from file`
+ argument. This approach allows environment data to be dynamically
+ generated. This approach won't work unless these files are
+ defined in the proper format---Ruby file end with `.rb`; JSON files
+ end with `.json`.
+
+These workflows are mutually exclusive: only the most recent environment
+changes will be kept on the Chef Infra Server, regardless of the source
+of those changes. All previous changes are overwritten when environment
+data is updated.
+
+The settings for environments can be modified and environments can be
+integrated into the larger infrastructure by associating them with nodes
+and by using recipes to call specific environment settings.
+
+### Find environment from recipe
+
+Use the following syntax to find the current environment from a recipe:
+
+```ruby
+node.environment
+```
+
+or:
+
+```ruby
+node.chef_environment
+```
+
+### Save in a data bag
+
+Values that are stored in a data bag are global to the organization and
+are available to any environment. There are two main strategies that can
+be used to store environment data within a data bag: by using a
+top-level key that corresponds to the environment or by using separate
+items for each environment.
+
+A data bag that's storing a top-level key for an environment might look
+something like this:
+
+```json
+{
+ "id": "some_data_bag_item",
+ "production" : {
+ // Hash with all your data here
+ },
+ "testing" : {
+ // Hash with all your data here
+ }
+}
+```
+
+When using the data bag in a recipe, that data can be accessed from a
+recipe using code similar to:
+
+```ruby
+bag_item[node.chef_environment]['some_other_key']
+```
+
+The other approach is to use separate items for each environment.
+Depending on the amount of data, it may all fit nicely within a single
+item. If this is the case, then creating different items for each
+environment may be a simple approach to providing values
+within a data bag for each environment. However, this approach is more time-consuming and may
+not scale to large environments or when the data must be stored in
+many data bag items.
+
+### Override attributes in roles
+
+Environment attributes that are used with roles can be overridden.
+Typically, this is done by using attribute precedence, but sometimes it
+may be necessary to ensure that specific attributes are used based on
+the presence of specific environments. This type of scenario is best
+addressed in using a recipe that relies on a top-level key that's
+stored in a data bag.
+
+For example, to retrieve a value from a data bag based on a specific
+environment:
+
+```ruby
+mything = data_bag_item('things', 'mything')
+attribute_i_want = mything[node.chef_environment]
+```
+
+### Set for a node
+
+A node is considered to be associated with an environment when the
+`chef_environment` attribute is set. The `chef_environment` attribute
+can't be set with normal or override attributes (in a role)
+because it's actually a method. An environment may be set explicitly
+using the following methods:
+
+- By using the `knife edit` and `knife exec` subcommands
+
+- By editing the `environment` configuration details in the client.rb
+ file, and then using `knife bootstrap -e environment_name` to
+ bootstrap the changes to the specified environment
+
+ {{< note >}}
+
+ After the environment has been set using bootstrap, the environment is
+ set in the client.rb file and may not be modified using the `edit` argument of the `knife node`
+ subcommand.
+
+ {{< /note >}}
+
+- By setting the `environment` configuration entry in the client.rb
+ file ; when Chef Infra Client runs, it will pick up the value and
+ then set the `chef_environment` attribute of the node
+
+### Move nodes
+
+Use the `knife exec` subcommand to move nodes between environments, such
+as from a "dev" to a "production" environment. For example:
+
+```bash
+knife exec -E 'nodes.transform("chef_environment:dev") { |n| n.chef_environment("production") }'
+```
+
+### Search environments
+
+{{< readfile file="content/reusable/md/search_environment.md" >}}
+
+## Environments in chef-solo
+
+{{< readfile file="content/reusable/md/chef_solo_environments.md" >}}
diff --git a/content/errors.md b/content/errors.md
new file mode 100644
index 0000000..3be5334
--- /dev/null
+++ b/content/errors.md
@@ -0,0 +1,544 @@
++++
+title = "Troubleshooting"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/errors.html", "/error_messages.html"]
+product = ["client", "server", "workstation"]
+
+[menu]
+ [menu.infra]
+ title = "Troubleshooting"
+ identifier = "chef_infra/reference/errors.md Troubleshooting"
+ parent = "chef_infra/reference"
++++
+
+The following sections describe how to troubleshoot the Chef Infra Server, Chef Infra Client, and Chef Workstation.
+
+## 401 Unauthorized
+
+There are multiple causes of the Chef 401 "Unauthorized" error, so please use the sections below to find the error message that most closely matches your output. If you are unable to find a matching error, or if the provided steps are unhelpful, please [file a help ticket](https://getchef.zendesk.com/hc/en-us).
+
+### Failed to authenticate as ORGANIZATION-validator
+
+If you're receiving an error like the following it most likely means you'll need to regenerate the ORGANIZATION-validator.pem file:
+
+```bash
+INFO: Client key /etc/chef/client.pem isn't present - registering
+INFO: HTTP Request Returned 401 Unauthorized: Failed to authenticate as ORGANIZATION-validator. Ensure that your node_name and client key are correct.
+FATAL: Stacktrace dumped to c:/chef/cache/chef-stacktrace.out
+FATAL: Net::HTTPClientException: 401 "Unauthorized"
+```
+
+#### Troubleshooting steps
+
+1. Check if the ORGANIZATION-validator.pem file exists in one of the following locations:
+
+ ```text
+ ~/.chef
+ ~/projects/current_project/.chef
+ /etc/chef
+ ```
+
+ If one is present, verify that it has the correct read permissions.
+
+2. If there's no ORGANIZATION-validator.pem file, regenerate it.
+
+ Recreate this file by going to the Chef management console web user interface and selecting **Organizations** in the upper right side of the screen.
+
+ You can then select **Reset Validation Key** next to the organization for which the key is to be reset.
+
+## Failed to authenticate to
+
+When the values for certain settings in the client.rb file---`node_name` and `client_key`---are incorrect, it won't be possible to authenticate to the Chef Infra Server. An error similar to the following is shown:
+
+```bash
+ERROR: Failed to authenticate to https://api.opscode.com/organizations/ORGANIZATION as USERNAME with key /path/to/USERNAME.pem
+Response: Failed to authenticate as USERNAME. Ensure that your node_name and client key are correct.
+```
+
+### Troubleshooting steps
+
+- Verify you have the correct values in your config.rb file, especially for the `node_name` and `client_key` settings.
+
+- Check if the file referenced in the `client_key` setting (usually USER.pem) exists. Some common locations include:
+
+ - `~/.chef`
+ - `~/projects/current_project/.chef`
+ - `/etc/chef`
+
+ If one is present, verify that it has the correct read permissions.
+
+- If there's no client.rb file, regenerate it and ensure the values for the `node_name` and `client_key` settings are correct.
+
+### Organization not found
+
+If you see this error when trying to recreate the ORGANIZATION-validator.pem, it's possible that Chef Infra Client itself was deleted. In this situation, the ORGANIZATION-validator.pem will need to be recreated. In these directions, `ORGANIZATION` should be replaced with the name of your organization.
+
+{{< readfile file="content/reusable/md/manage_webui_policy_validation_reset_key.md" >}}
+
+### Synchronize the clock on your host
+
+If the system clock drifts more than 15 minutes from the actual time, the following type of error will be shown:
+
+```bash
+INFO: Client key /etc/chef/client.pem isn't present - registering
+INFO: HTTP Request Returned 401 Unauthorized: Failed to authenticate as ORGANIZATION-validator. Synchronize the clock on your host.
+FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
+FATAL: Net::HTTPClientException: 401 "Unauthorized"
+```
+
+To resolve this error, synchronize the clock with an NTP server.
+
+### All other 401 errors
+
+The general `Net::HTTPClientException: 401 "Unauthorized"` error will usually occur for one of two reasons.
+
+#### Troubleshooting steps
+
+1. Make sure your `client.pem` is valid.
+
+ This can be fixed by deleting `client.pem` in `/etc/chef` and deleting the client and node with knife.
+
+ On a management station:
+
+ ```bash
+ # Dump the current node to JSON
+ knife node show NODE_NAME -fJ > NODE_NAME.json
+
+ knife client delete FQDN -y
+ knife node delete FQDN -y
+ ```
+
+ On an affected node (as root):
+
+ ```bash
+ rm /etc/chef/client.pem
+ chef-client
+ ```
+
+ When Chef Infra Client runs, it will register the API client and generate the correct key.
+
+ After successfully running Chef Infra Client on the node, reload the `run_list` and node attributes:
+
+ ```bash
+ knife node from file NODE_NAME.json
+ ```
+
+2. Make sure to use the same `node_name` as the initial Chef Infra Client run.
+
+ This can happen for a number of reasons. For example, if the
+ client.rb file doesn't specify the correct node name and the
+ system's hostname has changed.
+
+ Running `chef-client -l debug` will identify the node name being
+ used by Chef Infra Client for authentication attempts:
+
+ ```bash
+ DEBUG: Signing the request as SOME_NODE_NAME
+ ```
+
+ This can be fixed by explicitly setting `node_name` in the
+ client.rb file to match the name originally used to register.
+
+ ```ruby
+ node_node 'mynode.mycompany.com'
+ ````
+
+ Alternatively, re-register the node using the method described
+ previously.
+
+## 403 Forbidden
+
+If you're seeing output like this:
+
+```bash
+FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
+FATAL: Net::HTTPClientException: 403 "Forbidden"
+```
+
+this is an indication that there is an issue with permissions on the Chef Infra Server.
+
+### Troubleshooting steps
+
+In Chef, there are two different types of permissions issues, object specific and global permissions. To figure out which type of permission issue you're experiencing, run Chef Infra Client again using the `-l debug` options to see debugging output.
+
+You should see something like this up the stack trace:
+
+```bash
+DEBUG: Sending HTTP Request to https://api.opscode.com/organizations/ORGNAME/nodes
+ERROR: Running exception handlers
+```
+
+The URL will help identify the type of permission issue. If the URL is an index action (that's, operating on a collection of resources, like `/nodes`) then this is a global permission. If the URL is operating on an instance of a collection (`/nodes/NODENAME`) then this is an object permission issue.
+
+To fix the global permissions:
+
+1. Log in to the Chef management console and click on the failing object type (most likely **Nodes**).
+
+2. Click on the **Permissions** sub-tab. Which permission it needs, depends on which request that failed:
+
+ GET - Under the group section, make sure it has the LIST permission checked POST - Under the group section, make sure it has the CREATE permission checked
+
+3. Check the checkboxes needed and save the updates.
+
+To fix object permissions:
+
+1. Log in to the Chef management console and click on the failing object type (most likely **Nodes**).
+
+2. Click on the object in the list that's causing the error.
+
+3. Click on the **Permissions** sub-tab. Which permission it needs, depends on the type of request that failed:
+
+ GET - Make sure it has the READ permission checked PUT - Make sure it has the UPDATE permission checked DELETE - Make sure it has the DELETE permission checked
+
+4. Check the checkboxes needed and save the updates.
+
+## 500 (Unexpected)
+
+HTTP 500 is a non-specific error message. The full error message for the error Chef Infra Client is receiving can be found in one of the following log files:
+
+- `/var/log/opscode/opscode-account/current`
+- `/var/log/opscode/opscode-erchef/current`
+
+The error will likely found in a stacktrace from the application error. In some cases the error message will clearly indicate a problem with another service which can be investigated further. For non-obvious errors, please contact Chef and attach the log files.
+
+## 502 / 504 (Gateway)
+
+Determine which API service is returning 504s using the Nginx access logs. API requests returning 504 can be found with the following command on a frontend:
+
+```bash
+grep 'HTTP/1.1" 504' /var/log/opscode/nginx/access.log
+```
+
+The following will extract the URLs and sort them by `uniq` count:
+
+```bash
+grep 'HTTP/1.1" 504' nginx-access.log | cut -d' ' -f8 | sort | uniq -c | sort
+```
+
+In a large installation, you may need to restrict this to a subset of the requests:
+
+```bash
+tail -10000 nginx-access.log | grep 'HTTP/1.1" 504' | cut -d' ' -f8 | sort | uniq -c | sort
+```
+
+You can also use the `ntail` utility.
+
+If the problematic service is a Ruby-based service and the frontend machines have free RAM or CPU, consider increasing the number of worker processes. If the problematic service is **opscode-erchef**, use the request log to determine whether a particular component of requests is slow.
+
+## Workflow Problems
+
+In working with Chef, you'll most likely encounter issues in your regular workflow. This page is a collection of common errors our users have reported while working with Chef. Please use the accordion below to select the error message that most closely matches your output. If you are unable to find a matching error, or if the provided steps are unhelpful, please [file a help ticket](https://getchef.zendesk.com/hc/en-us).
+
+### No such file or directory
+
+If you're seeing an error like:
+
+```bash
+Client key /etc/chef/client.pem isn'tresent - registering
+WARN: Failed to read the private key /etc/che/validation.pem: #
+FATAL: Stacktrace dumped to /etc/chef/cache/chef-stacktrace.out
+FATAL: Chef::Exceptions::PrivateKeyMissing: I can't read /etc/chef/validation.pem, which you told me to use to sign requests
+```
+
+It means that Chef Infra Client couldn't find your validation.pem.
+
+#### Troubleshooting steps
+
+1. Make sure your `validation.pem` or `ORGANIZATION-validator.pem` is downloaded and accessible by the current user.
+2. Make sure your client.rb points to the location of your validator pem.
+
+### Commit or stash your changes
+
+This isn't an error, but can be confusing to new users. When you try to install a cookbook with changes that you haven't committed to Git, you will get this error:
+
+```bash
+Installing getting-started to /home/jes/chef-repo/.chef/../cookbooks
+ERROR: You have uncommitted changes to your cookbook repo:
+ M cookbooks/getting-started/recipes/default.rb
+ ?? .chef/
+ ?? log
+Commit or stash your changes before importing cookbooks
+```
+
+#### Troubleshooting steps
+
+Solve this by committing the cookbook changes. For example, the following command would commit all new changes with the message "updates".
+
+```bash
+git commit -am "Updating so I can install a site cookbook"
+```
+
+Re-run the `knife supermarket install` subcommand again to install the community cookbook.
+
+### Can't find config file
+
+If you're seeing an error like:
+
+```bash
+WARN: ***************************************
+WARN: Can not find config file: /etc/chef/client.rb, using defaults.
+WARN: No such file or directory - /etc/chef/client.rb
+# ... output truncated ... #
+FATAL: Chef::Exceptions::PrivateKeyMissing: I can't read /etc/chef/validation.pem, which you told me to use to sign requests!
+```
+
+#### Troubleshooting steps
+
+Work around this issue by supplying the full path to the client.rb file:
+
+```bash
+chef-client -c /etc/chef/client.rb
+```
+
+### Pivotal.rb doesn't exist
+
+If you're seeing an error like:
+
+```bash
+ERROR: CONFIGURATION ERROR:Specified config file /etc/opscode/pivotal.rb doesn't exist
+```
+
+#### Troubleshooting steps
+
+Run the following to restart all of the services:
+
+```bash
+chef-server-ctl reconfigure
+```
+
+Because the Chef Infra Server is composed of many different services that work together to create a functioning system, this step may take a few minutes to complete.
+
+## External PostgreSQL
+
+The following error messages may be present when configuring the Chef Infra Server to use a remote PostgreSQL server.
+
+### CSPG001 (changed setting)
+
+#### Reason
+
+The value of `postgresql['external']` has been changed.
+
+#### Possible causes
+
+- This setting must be set before running
+ `chef-server-ctl reconfigure`, and may not be changed after
+
+{{< warning >}}
+
+Upgrading isn't supported at this time.
+
+{{< /warning >}}
+
+#### Resolution
+
+- Back up the data using `knife ec backup`, create a new backend instance, and then restore the data
+- Re-point frontend machines at the new backend instance **or** assign the new backend instance the name/VIP of the old backend instance (including certificates and keys)
+
+### CSPG010 (can't connect)
+
+#### Reason
+
+Can't connect to PostgreSQL on the remote server.
+
+#### Possible causes
+
+- PostgreSQL isn't running on the remote server
+- The port used by PostgreSQL is blocked by a firewall on the remote server
+- Network routing configuration is preventing access to the host
+- When using Amazon Web Services (AWS), rules for security groups are preventing the Chef Infra Server from communicating with PostgreSQL
+
+### CSPG011 (can't authenticate)
+
+#### Reason
+
+Can't authenticate to PostgreSQL on the remote server.
+
+#### Possible causes
+
+- Incorrect password specified for `db_superuser_password`
+- Incorrect user name specified for `db_superuser`
+
+### CSPG012 (incorrect rules)
+
+#### Reason
+
+Can't connect to PostgreSQL on the remote server because rules in
+`pg_hba` are incorrect.
+
+#### Possible causes
+
+- No `pg_hba.conf` rule exists for the `db_superuser` in PostgreSQL
+- A rule exists for the `db_superuser` in `pg_hba.conf`, but it doesn't specify `md5` access
+- A rule in `pg_hba.conf` specifies an incorrect originating address
+
+#### Resolution
+
+Entries in the `pg_hba.conf` file should allow:
+
+- All user names that originate from any Chef Infra Server instance using `md5` authentication.
+- A specific application names: `$db_superuser` (the configured superuser name in the chef-server.rb file), `oc_id`, `oc_id_ro`, `opscode_chef`, `opscode_chef_ro`, `bifrost`, and `bifrost_ro`
+
+##### pg_hba.conf User Names
+
+For example, a `pg_hba.conf` entry for a valid username and password from the 192.0.2.0 subnet:
+
+```bash
+host postgres all 192.0.2.0/24 md5
+```
+
+or, specific named users with a valid password originating from the 192.0.2.0 subnet. A file named `$PGDATA/chef_users` with the following content must be created:
+
+```bash
+opscode_chef
+opscode_chef_ro
+bifrost
+bifrost_ro
+oc_id
+oc_id_ro
+```
+
+where `CHEF-SUPERUSER-NAME` is replaced with the same user name specified by `postgresql['db_superuser']`. The corresponding `pg_hba.conf` entry is similar to:
+
+```bash
+host postgres @chef_users 192.168.93.0/24 md5
+```
+
+or, using the same `$PGDATA/chef_users` file (from the previous example), the following example shows a way to limit connections to specific nodes that are running components of the Chef Infra Server.This approach requires more maintenance because the `pg_hba.conf`file must be updated when machines are added to or removed from theChef Infra Server configuration. For example, a high availability configuration with four nodes: `backend-1` (192.0.2.100),`backend-2` (192.0.2.101), `frontend-1` (192.0.2.110), and`frontend-2` (192.0.2.111).
+
+The corresponding `pg_hba.conf` entry is similar to:
+
+```bash
+host postgres @chef_users 192.0.2.100 md5
+host postgres @chef_users 192.0.2.101 md5
+host postgres @chef_users 192.0.2.110 md5
+host postgres @chef_users 192.0.2.111 md5
+```
+
+These changes also require a configuration reload for PostgreSQL:
+
+```bash
+pg_ctl reload
+```
+
+or:
+
+```bash
+SELECT pg_reload_conf();
+```
+
+##### pg_hba.conf Application names
+
+Rules in the `pg_hba.conf` file should allow only specific application names:
+
+- `$db_superuser` (the configured superuser name in the chef-server.rb file)
+- `oc_id`
+- `oc_id_ro`
+- `opscode_chef`
+- `opscode_chef_ro`
+- `bifrost`
+- `bifrost_ro`
+
+### CSPG013 (incorrect permissions)
+
+#### Reason
+
+The `db_superuser` account has incorrect permissions.
+
+#### Possible causes
+
+- The `db_superuser` account hasn't been granted `SUPERUSER` access
+
+- The `db_superuser` account hasn't been granted `CREATE DATABASE` and `CREATE ROLE` privileges
+
+ ```bash
+ ALTER ROLE "$your_db_superuser_name" WITH SUPERUSER
+ ```
+
+ or:
+
+ ```bash
+ ALTER ROLE "$your_db_superuser_name" WITH CREATEDB CREATEROLE
+ ```
+
+### CSPG014 (incorrect version)
+
+#### Reason
+
+Bad version of PostgreSQL.
+
+#### Possible causes
+
+- The remote server isn't running PostgreSQL version 9.2.x
+
+### CSPG015 (missing database)
+
+#### Reason
+
+The database template `template1` doesn't exist.
+
+#### Possible causes
+
+- The `template1` database template has been removed from the remote
+ server
+
+#### Resolution
+
+- Run the following command (as a superuser):
+
+ ```bash
+ CREATE DATABASE template1 TEMPLATE template0
+ ```
+
+ or:
+
+ ```bash
+ createdb -T template0 template1
+ ```
+
+### CSPG016 (database exists)
+
+#### Reason
+
+One (or more) of the PostgreSQL databases already exists.
+
+#### Possible causes
+
+- The `opscode_chef`, `oc_id`, and/or `bifrost` databases already exist on the remote machine
+- The PostgreSQL database exists for another application
+
+#### Resolution
+
+- Verify that the `opscode_chef`, `oc_id`, and/or `bifrost` databases exist, and then verify that they're not being used by another internal application
+- Back up the PostgreSQL data, remove the existing databases, and reconfigure the Chef server
+
+### CSPG017 (user exists)
+
+#### Reason
+
+One (or more) of the PostgreSQL predefined users already exists.
+
+#### Possible causes
+
+- The `opscode_chef`, `ospcode_chef_ro`, `bifrost`, `bifrost_ro`, `oc_id`, or `oc_id_ro` users already exist on the remote machine
+- The `postgresql['vip']` setting is configured to a remote host, but `postgresql['external']` isn't set to `true`, which causes the `opscode_chef` and `ospcode_chef_ro` users to be created before the machine is reconfigured, which will return a permissions error
+- Existing, valid naming conflicts are present, where the users were created independently of the Chef server
+
+#### Resolution
+
+- Run the following, if it's safe to do so, to update the user name that's specified in the error message:
+
+ ```bash
+ DROP ROLE "name-of-user";
+ ```
+
+ or change the name of the user by updating following settings in the chef-server.rb configuration file:
+
+ ```ruby
+ oc_id['sql_user'] = 'alternative_username'
+ oc_id['sql_ro_user'] = 'alternative_username_for_ro_access'
+ opscode_erchef['sql_user'] = 'alternative_username'
+ opscode_erchef['sql_ro_user'] = 'alternative_username_for_ro_access'
+ oc_bifrost['sql_ro_user'] = 'alternative_username'
+ oc_bifrost['sql_ro_user'] = 'alternative_username_for_ro_access'
+ ```
diff --git a/content/files.md b/content/files.md
new file mode 100644
index 0000000..fe3b75c
--- /dev/null
+++ b/content/files.md
@@ -0,0 +1,19 @@
++++
+title = "Cookbook Files"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+aliases = ["/files.html", "essentials_cookbook_files.html"]
+
+[menu]
+ [menu.infra]
+ title = "Files"
+ identifier = "chef_infra/cookbook_reference/files.md Files"
+ parent = "chef_infra/cookbook_reference"
+ weight = 40
++++
+
+The `files` directory in Chef Infra cookbooks stores files that are used
+in your cookbook with the [cookbook_file](/resources/cookbook_file/)
+resource.
diff --git a/content/fips.md b/content/fips.md
new file mode 100644
index 0000000..8dd0805
--- /dev/null
+++ b/content/fips.md
@@ -0,0 +1,115 @@
++++
+title = "FIPS (Federal Information Processing Standards)"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/fips.html"]
+product = ["client", "server", "workstation"]
+
+[menu]
+ [menu.infra]
+ title = "FIPS"
+ identifier = "chef_infra/security/fips.md FIPS"
+ parent = "chef_infra/security"
+ weight = 30
++++
+
+## What's FIPS?
+
+Federal Information Processing Standards (FIPS) are federal standards
+for computer systems used by contractors of government agencies and
+non-military government agencies.
+
+FIPS 140-2 is a specific federal government security standard used to
+approve cryptographic modules. Chef Automate uses the OpenSSL FIPS
+Object Module, which satisfies the requirements of software
+cryptographic modules under the FIPS 140-2 standard. The OpenSSL Object
+Module provides an API for invoking FIPS approved cryptographic
+functions from calling applications.
+
+### Who should enable FIPS?
+
+You may be legally required to enable FIPS if you are a United States
+non-military government agency, or are contracting with one. If you are
+not sure if you need to enable FIPS, please check with your compliance
+department.
+
+### Who shouldn't enable FIPS?
+
+You will only need to enable FIPS if you are a US non-military
+government agency, or contracting with one, and you are contractually
+obligated to meet federal government security standards. If you aren't
+a US non-military governmental agency, or you aren't contracting with
+one, and you aren't contractually obligated to meet federal government
+security standards, then don't enable FIPS. Chef products have robust
+security standards even without FIPS, and FIPS prevents the use of
+certain hashing algorithms you might want to use, so we only recommend
+enabling FIPS if it's contractually necessary.
+
+## Supported products
+
+**Supported:**
+
+- [Chef Infra Client](/fips/#how-to-enable-fips-mode-for-the-chef-client)
+- [Chef Workstation](/fips/#how-to-enable-fips-mode-for-workstations)
+- [Chef Infra Server](/fips/#how-to-enable-fips-mode-for-the-chef-server)
+
+**Unsupported:**
+
+FIPS mode isn't supported for Chef Infra Server add-ons. This includes Chef Manage.
+
+## How to enable FIPS mode in the operating system
+
+### FIPS kernel settings
+
+Windows and Red Hat Enterprise Linux can both be configured for FIPS
+mode using a kernel-level setting. After FIPS mode is enabled at the
+kernel level, the operating system will only use FIPS approved
+algorithms and keys during operation.
+
+All of the tools Chef produces that have FIPS support read this kernel
+setting and default their mode of operation to match it with the
+exception of the workstation, which requires designating a port in the
+`fips_git_port` setting of the `cli.toml`. For the other Chef Infra tools,
+Chef Infra Client, for example, if `chef-client` is run on an operating
+system configured into FIPS mode and you run, that Chef Infra run will
+automatically be in FIPS mode unless the user disables it.
+
+To enable FIPS on your platform follow these instructions:
+
+- [Red Hat Enterprise Linux 6](https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-Federal_Standards_And_Regulations-Federal_Information_Processing_Standard.html)
+- [Red Hat Enterprise Linux 7](https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/chap-Federal_Standards_and_Regulations.html#sec-Enabling-FIPS-Mode)
+- [Red Hat Enterprise Linux 8](https://www.redhat.com/en/blog/how-rhel-8-designed-fips-140-2-requirements)
+- [Windows](https://technet.microsoft.com/en-us/library/cc750357.aspx)
+- [Ubuntu](https://security-certs.docs.ubuntu.com/en/fips)
+
+## How to enable FIPS mode for Chef Infra Server
+
+### Prerequisites
+
+- Supported Systems - CentOS or Red Hat Enterprise Linux 6 or greater
+- Chef Infra Server version 12.13 or greater
+
+### Configuration
+
+If you have FIPS compliance enabled at the kernel level and install or
+reconfigure Chef Infra Server then it will default to running in
+FIPS mode.
+
+To enable FIPS manually for Chef Infra Server, can add `fips true`
+to the `/etc/opscode/chef-server.rb` and reconfigure. For more
+configuration information see [chef-server.rb Optional Settings](/server/config_rb_server_optional_settings/).
+
+## How to enable FIPS mode for Chef Infra Client
+
+### Prerequisites
+
+- Supported Systems - CentOS, Oracle Linux, Red Hat Enterprise Linux 6 or later, and Ubuntu
+- Chef Infra Client 16.13 or later for Ubuntu systems
+
+### Configuration
+
+If you have FIPS compliance enabled at the kernel level, Chef Infra Client will default to running in FIPS mode. Otherwise, add `fips true` to the `/etc/chef/client.rb` or `C:\\chef\\client.rb`.
+
+#### Bootstrap a node using FIPS
+
+{{< readfile file="content/workstation/reusable/md/knife_bootstrap_node_fips.md" >}}
diff --git a/content/glossary.md b/content/glossary.md
new file mode 100644
index 0000000..1add86f
--- /dev/null
+++ b/content/glossary.md
@@ -0,0 +1,133 @@
++++
+title = "Glossary"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/glossary.html"]
+product = ["automate", "client", "server", "habitat", "inspec", "workstation"]
+
+[menu]
+ [menu.infra]
+ title = "Glossary"
+ identifier = "chef_infra/reference/glossary.md Glossary"
+ parent = "chef_infra/reference"
++++
+
+Berkshelf
+
+: The legacy tool for managing cookbook dependencies. Policyfiles should be used instead.
+
+chef
+
+: `chef` is the Chef Workstation command line tool for managing your Chef development environment including repositories, cookbooks, recipes, attributes, templates, custom resources, and Ruby dependencies.
+
+ChefDK
+
+: The legacy package of tools for developing Chef Infra cookbooks. This product has been superseded by Chef Workstation which should be used instead.
+
+ChefSpec
+
+: ChefSpec is a unit-testing framework for testing Chef Infra cookbooks.
+
+Chef Automate
+
+: A full suite of enterprise capabilities for maintaining continuous visibility into application, infrastructure, and security automation.
+
+Chef Infra Client
+
+: A command-line tool that that runs Chef. Also, the name of Chef as it's installed on a node.
+
+Chef Infra Server
+
+: The Chef Infra Server acts as a hub for configuration data. The Chef Infra Server stores cookbooks, the policies that are applied to nodes, and metadata that describes each registered node that's being managed by Chef Infra Client. Nodes use Chef Infra Client to ask the Chef Infra Server for configuration details, such as recipes, templates, and file distributions.
+
+Chef Workstation
+
+: A collection of tools to aide in development of Chef Infra cookbooks. It uses the full stack installer to give you everything you need to get going in one package. You can download it at [Chef Downloads](https://www.chef.io/downloads).
+
+chef-client
+
+: The `chef-client` is the name for both the command line tool that runs on your local computer and the program that runs on nodes. The `chef-client` allows you to ensure the configuration compliance of your systems through policy code. You use the chef-client command line tool from your local computer to send instructions to the program on the node. You install the chef-client on nodes with the bootstrap process from your computer and then you configure it to run on an interval to ensure continuous configuration compliance.
+
+chef-repo
+
+: The repository structure in which cookbooks are authored, tested, and maintained. View [an example of the](https://github.com/chef/chef-repo) chef-repo.
+
+chef-zero
+
+: A lightweight Chef Infra Server that runs in-memory on the local machine during a Chef Infra Client run. Also known as local mode.
+
+cookbook
+
+: A cookbook is the fundamental unit of configuration and policy distribution in Chef Infra.
+
+Cookstyle
+
+: A linting tool that helps you write better Chef Infra cookbooks by detecting and automatically correcting style, syntax, and logic mistakes in your code.
+
+custom resource
+
+: An extension to Chef Infra Client that allows you to ship your own reusable resources within a cookbook.
+
+data bag
+
+: A data_bag is a global variable that's stored as JSON data and is accessible from a Chef Infra Server.
+
+environment
+
+: An environment is a way to map an organization's real-life workflow to what can be configured and managed when using Chef Infra Server.
+
+Foodcritic
+
+: A legacy linting tool for doing static code analysis on cookbooks. This tool has been replaced with Cookstyle which should be used instead.
+
+knife
+
+: A command-line tool that provides an interface between a local chef-repo and the Chef Infra Server. Use it to manage nodes, cookbooks, recipes, roles, data bags, environments, bootstrapping nodes, searching the Chef Infra Server, and more.
+
+library
+
+: A library allows arbitrary Ruby code to be included in a cookbook, either as a way of extending the classes that are built-in to Chef Infra Client or by implementing entirely new functionality.
+
+node
+
+: A node is any physical, virtual, or cloud device that's configured and maintained by an instance of Chef Infra Client.
+
+node object
+
+: A node object is a history of the attributes, run-lists, and roles that were used to configure a node that's under management by Chef Infra.
+
+ohai
+
+: Ohai is a tool that's used to detect attributes on a node, and then provide these attributes to Chef Infra Client at the start of every run.
+
+organization
+
+: An organization is a single instance of a Chef Infra Server, including all of the nodes that are managed by that Chef Infra Server and each of the workstations that will run knife and access the Chef Infra Server using the Chef Infra Server API.
+
+policy
+
+: Policy settings can be used to map business and operational requirements, such as process and workflow, to settings and objects stored on the Chef Infra Server. See roles, environments, and data bags.
+
+recipe
+
+: A recipe is a collection of resources that tells Chef Infra Client how to configure a node.
+
+resource
+
+: A resource is a statement of configuration policy that describes the desired state of an piece within your infrastructure, along with the steps needed to bring that item to the desired state.
+
+role
+
+: A role is a way to define certain patterns and processes that exist across nodes in an organization as belonging to a single job function.
+
+run-list
+
+: A run-list defines all of the configuration settings that are necessary for a node that's under management by Chef to be put into the desired state and the order in which these configuration settings are applied.
+
+Test Kitchen
+
+: Test Kitchen is an integration framework that's used to automatically test cookbook data across any combination of platforms and test suites. Test Kitchen is packaged in Chef Workstation.
+
+Unified Mode
+
+: Unified mode combines the compile and converge stages of the Chef Infra Client run into one phase. Unified mode means that the Chef Infra Client compiles and applies a custom resource in order, from top to bottom. Unified mode works only on custom resources and doesn't affect other resources or recipes.
diff --git a/content/google.md b/content/google.md
new file mode 100644
index 0000000..eb1f19e
--- /dev/null
+++ b/content/google.md
@@ -0,0 +1,125 @@
++++
+title = "Chef and Google"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/google.html"]
+product = ["client", "server", "workstation"]
+
+[menu]
+ [menu.infra]
+ title = "Google Cloud Platform"
+ identifier = "chef_infra/integrations/google.md Google Cloud Platform"
+ parent = "chef_infra/integrations"
+ weight = 20
++++
+
+Google Cloud Platform is a suite of cloud computing services that run on
+the same infrastructure that Google uses internally for its end-user
+products, such as Google Search and YouTube. Alongside a set of
+management tools, it provides a series of modular cloud services
+including computing, data storage, data analytics, and machine learning.
+This page outlines the different tools that can be used to integrate
+Chef with the Google Cloud Platform.
+
+## knife-google
+
+[\[GitHub\]](https://github.com/chef/knife-google)
+
+This plugin gives knife the ability to create, bootstrap, and manage
+Google Compute Engine (GCE) instances.
+
+### Authentication and Authorization
+
+`knife-google` relies on the Google Auth Library to handle
+authentication to the Google Cloud API. The auth library expects to find
+a JSON credentials file located under
+`~/.config/gcloud/application_default_credentials.json`.
+
+The easiest way to create this is to download and install the [Google
+Cloud SDK](https://cloud.google.com/sdk/) and run the
+`gcloud auth application-default login` command, which will create the
+credentials file for you.
+
+If you already have a file you'd like to use that's in a different
+location, set the `GOOGLE_APPLICATION_CREDENTIALS` environment variable
+with the full path to that file.
+
+These are the necessary settings for your `config.rb` file:
+
+```ruby
+knife[:gce_project] = 'my-test-project'
+knife[:gce_zone] = 'us-east1-b'
+```
+
+### Usage Examples
+
+**Create a server:**
+
+```bash
+knife google server create test-instance-1 --gce-image centos-7-v20160219 \
+--gce-machine-type n1-standard-2 --gce-public-ip ephemeral --connection-user myuser \
+--identity-file /Users/myuser/.ssh/google_compute_engine
+```
+
+**Delete multiple servers:**
+
+```bash
+knife google server delete my-instance-1 my-instance-2 --purge
+```
+
+**List all servers:**
+
+```bash
+knife google server list
+```
+
+## kitchen-google
+
+[\[GitHub\]](https://github.com/test-kitchen/kitchen-google)
+
+A test kitchen driver for Google Cloud Platform.
+
+### Usage Examples
+
+The following is a basic `kitchen.yml` example:
+
+```yaml
+---
+driver:
+ name: gce
+ project: mycompany-test
+ zone: us-east1-c
+ email: me@mycompany.com
+ tags:
+ - devteam
+ - test-kitchen
+ service_account_scopes:
+ - devstorage.read_write
+ - userinfo.email
+
+provisioner:
+ name: chef_zero
+
+transport:
+ username: chefuser
+
+platforms:
+ - name: centos-7
+ driver:
+ image_project: centos-cloud
+ image_name: centos-7-v20170124
+ - name: ubuntu-18.04
+ driver:
+ image_project: ubuntu-os-cloud
+ image_family: ubuntu-1804-lts
+ - name: windows
+ driver:
+ image_project: windows-cloud
+ image_name: windows-server-2012-r2-dc-v20170117
+ disk_size: 50
+suites:
+ - name: default
+ run_list:
+ - recipe[COOKBOOK::default]
+ attributes:
+```
diff --git a/content/handlers.md b/content/handlers.md
new file mode 100644
index 0000000..7643971
--- /dev/null
+++ b/content/handlers.md
@@ -0,0 +1,551 @@
++++
+title = "About Handlers"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+aliases = ["/handlers.html", "essentials_handlers.html"]
+
+[menu]
+ [menu.infra]
+ title = "Handlers"
+ identifier = "chef_infra/features/handlers.md Handlers"
+ parent = "chef_infra/features"
+ weight = 40
++++
+
+{{< readfile file="content/reusable/md/handler.md" >}}
+
+{{< readfile file="content/reusable/md/handler_types.md" >}}
+
+## Exception/Report Handlers
+
+{{< readfile file="content/reusable/md/handler_type_exception_report.md" >}}
+
+### Run from Recipes
+
+{{< readfile file="content/reusable/md/handler_type_exception_report_run_from_recipe.md" >}}
+
+### Run from client.rb
+
+A simple exception or report handler may be installed and configured at run-time. This requires editing of a node's client.rb file to add the appropriate setting and information about that handler to the client.rb or solo.rb files. Depending on the handler type, one (or more) of the following settings must be added:
+
+`exception_handlers`
+
+: A list of exception handlers that are available to Chef Infra Client during a Chef Infra Client run.
+
+`report_handlers`
+
+: A list of report handlers that are available to Chef Infra Client during a Chef Infra Client run.
+
+When this approach is used, the client.rb file must also tell Chef Infra Client how to install and run the handler. There is no default install location for handlers. The simplest way to distribute and install them is using RubyGems, though other methods such as GitHub or HTTP will also work. Once the handler is installed on the system, enable it in the client.rb file by requiring it. After the handler is installed, it may require additional configuration. This will vary from handler to handler. If a handler is a simple handler, it may only require the creation of a new instance. For example, if a handler named `MyOrg::EmailMe` is hardcoded for all of the values required to send email, a new instance is required. And then the custom handler must be associated with each of the handler types for which it will run.
+
+For example:
+
+```ruby
+require '/var/chef/handlers/email_me' # the installation path
+
+email_handler = MyOrg::EmailMe.new # a simple handler
+
+start_handlers << email_handler # run at the start of the run
+report_handlers << email_handler # run at the end of a successful run
+exception_handlers << email_handler # run at the end of a failed run
+```
+
+## Start Handlers
+
+{{< readfile file="content/reusable/md/handler_type_start.md" >}}
+
+### Run from Recipes
+
+{{< readfile file="content/reusable/md/handler_type_start_run_from_recipe.md" >}}
+
+### Run from client.rb
+
+A start handler can be configured in the client.rb file by adding the following setting:
+
+
+
+
+
+
+
+
+
Setting
+
Description
+
+
+
+
+
start_handlers
+
A list of start handlers that are available to Chef Infra Client at the start of a Chef Infra Client run.
+
+
+
+
+For example, the Reporting start handler adds the following code to the
+top of the client.rb file:
+
+```ruby
+begin
+ require 'chef_reporting'
+ start_handlers << Chef::Reporting::StartHandler.new()
+rescue LoadError
+ Chef::Log.warn 'Failed to load #{lib}. This should be resolved after a chef run.'
+end
+```
+
+This ensures that when a Chef Infra Client run begins the `chef_reporting` event handler is enabled. The `chef_reporting` event handler is part of a gem named `chef-reporting`. The **chef_gem** resource is used to install this gem:
+
+```ruby
+chef_gem 'chef-reporting' do
+ action :install
+end
+```
+
+## Event Handlers
+
+{{< readfile file="content/reusable/md/dsl_handler_summary.md" >}}
+
+### on Method
+
+{{< readfile file="content/reusable/md/dsl_handler_method_on.md" >}}
+
+### Event types
+
+{{< readfile file="content/reusable/md/dsl_handler_event_types.md" >}}
+
+### Examples
+
+The following examples show ways to use the Handler DSL.
+
+#### Send Email
+
+{{< readfile file="content/reusable/md/dsl_handler_slide_send_email.md" >}}
+
+##### Define How Email is Sent
+
+{{< readfile file="content/reusable/md/dsl_handler_slide_send_email_library.md" >}}
+
+##### Add the Handler
+
+{{< readfile file="content/reusable/md/dsl_handler_slide_send_email_handler.md" >}}
+
+##### Test the Handler
+
+{{< readfile file="content/reusable/md/dsl_handler_slide_send_email_test.md" >}}
+
+#### etcd Locks
+
+{{< readfile file="content/reusable/md/dsl_handler_example_etcd_lock.md" >}}
+
+#### HipChat Notifications
+
+{{< readfile file="content/reusable/md/dsl_handler_example_hipchat.md" >}}
+
+## Handlers and Cookbooks
+
+The following cookbooks can be used to load handlers during a Chef InfraClient run.
+
+### chef_handler
+
+Exception and report handlers can be distributed using the **chef_handler** resource. This resource is included with Chef 14 and above. It can be used to enable custom handlers from within recipes and to include product-specific handlers from cookbooks.
+
+See the [chef_handler Resource]({{< relref "/resources/chef_handler">}}) documentation for more information.
+
+### Chef Infra Client
+
+Start handlers can be distributed using the **chef-client** cookbook, which will install the handler on the target node during the initial configuration of the node. This ensures that the start handler is always present on the node so that it's available to Chef Infra Client at the start of every run.
+
+## Custom Handlers
+
+A custom handler can be created to support any situation. The easiest way to build a custom handler:
+
+1. Download the **chef_handler** cookbook
+2. Create a custom handler
+3. Write a recipe using the **chef_handler** resource
+4. Add that recipe to a node's run-list, often as the first recipe in
+ that run-list
+
+### Syntax
+
+The syntax for a handler can vary depending on what the situations the handler is being asked to track, for example the handler type being used. All custom exception and report handlers are defined using Ruby and must be a subclass of the `Chef::Handler` class.
+
+```ruby
+require 'chef/log'
+
+module ModuleName
+ class HandlerName < Chef::Handler
+ def report
+ # Ruby code goes here
+ end
+ end
+end
+```
+
+where:
+
+- `require` ensures that the logging functionality of Chef Infra Client is available to the handler
+- `ModuleName` is the name of the module as it exists within the `Chef` library
+- `HandlerName` is the name of the handler as it's used in a recipe
+- `report` is an interface that's used to define the custom handler
+
+For example, the following shows a custom handler that sends an email that contains the exception data when a Chef Infra Client run fails:
+
+```ruby
+require 'net/smtp'
+
+module OrgName
+ class SendEmail < Chef::Handler
+ def report
+ if run_status.failed?
+ message = "From: sender_name \n"
+ message << "To: recipient_address \n"
+ message << "Subject: chef-client Run Failed\n"
+ message << "Date: #{Time.now.rfc2822}\n\n"
+ message << "Chef run failed on #{node.name}\n"
+ message << "#{run_status.formatted_exception}\n"
+ message << Array(backtrace).join('\n')
+ Net::SMTP.start('your.smtp.server', 25) do |smtp|
+ smtp.send_message message, 'sender@example', 'recipient@example'
+ end
+ end
+ end
+ end
+end
+```
+
+and then is used in a recipe like:
+
+```ruby
+send_email 'blah' do
+ # recipe code
+end
+```
+
+### report Interface
+
+The `report` interface is used to define how a handler will behave and is a required part of any custom handler. The syntax for the `report` interface is as follows:
+
+```ruby
+def report
+ # Ruby code
+end
+```
+
+The Ruby code used to define a custom handler will vary significantly from handler to handler. Chef Infra Client includes two default handlers: `error_report` and `json_file`. Their use of the `report` interface is shown below.
+
+The [error_report](https://github.com/chef/chef/blob/main/lib/chef/handler/error_report.rb) handler:
+
+```ruby
+require 'chef/handler'
+require 'chef/resource/directory'
+
+class Chef
+ class Handler
+ class ErrorReport < ::Chef::Handler
+ def report
+ Chef::FileCache.store('failed-run-data.json', Chef::JSONCompat.to_json_pretty(data), 0640)
+ Chef::Log.fatal("Saving node information to #{Chef::FileCache.load('failed-run-data.json', false)}")
+ end
+ end
+ end
+end
+```
+
+The [json_file](https://github.com/chef/chef/blob/main/lib/chef/handler/json_file.rb) handler:
+
+```ruby
+require 'chef/handler'
+require 'chef/resource/directory'
+
+class Chef
+ class Handler
+ class JsonFile < ::Chef::Handler
+ attr_reader :config
+ def initialize(config = {})
+ @config = config
+ @config[:path] ||= '/var/chef/reports'
+ @config
+ end
+
+ def report
+ if exception
+ Chef::Log.error('Creating JSON exception report')
+ else
+ Chef::Log.info('Creating JSON run report')
+ end
+ build_report_dir
+ savetime = Time.now.strftime('%Y%m%d%H%M%S')
+ File.open(File.join(config[:path], 'chef-run-report-#{savetime}.json'), 'w') do |file|
+ run_data = data
+ run_data[:start_time] = run_data[:start_time].to_s
+ run_data[:end_time] = run_data[:end_time].to_s
+ file.puts Chef::JSONCompat.to_json_pretty(run_data)
+ end
+ end
+
+ def build_report_dir
+ unless File.exist?(config[:path])
+ FileUtils.mkdir_p(config[:path])
+ File.chmod(00700, config[:path])
+ end
+ end
+ end
+ end
+end
+```
+
+### Optional Interfaces
+
+The following interfaces may be used in a handler in the same way as the `report` interface to override the default handler behavior in Chef Infra Client. That said, the following interfaces aren't typically used in a handler and, for the most part, are completely unnecessary for a handler to work properly and/or as desired.
+
+#### data
+
+The `data` method is used to return the Hash representation of the `run_status` object. For example:
+
+```ruby
+def data
+ @run_status.to_hash
+end
+```
+
+#### run_report_safely
+
+The `run_report_safely` method is used to run the report handler, rescuing and logging errors that may arise as the handler runs and ensuring that all handlers get a chance to run during a Chef Infra Client run (even if some handlers fail during that run). In general, this method should never be used as an interface in a custom handler unless this default behavior simply must be overridden.
+
+```ruby
+def run_report_safely(run_status)
+ run_report_unsafe(run_status)
+rescue Exception => e
+ Chef::Log.error('Report handler #{self.class.name} raised #{e.inspect}')
+ Array(e.backtrace).each { |line| Chef::Log.error(line) }
+ensure
+ @run_status = nil
+end
+```
+
+#### run_report_unsafe
+
+The `run_report_unsafe` method is used to run the report handler without any error handling. This method should never be used directly in any handler, except during testing of that handler. For example:
+
+```ruby
+def run_report_unsafe(run_status)
+ @run_status = run_status
+ report
+end
+```
+
+### run_status Object
+
+The `run_status` object is initialized by Chef Infra Client before the `report` interface is run for any handler. The `run_status` object keeps track of the status of a Chef Infra Client run and will contain some (or all) of the following properties:
+
+`all_resources`
+
+: A list of all resources that are included in the `resource_collection` property for the current Chef Infra Client run.
+
+`backtrace`
+
+: A backtrace associated with the uncaught exception data that caused a Chef Infra Client run to fail, if present; `nil` for a successful Chef Infra Client run.
+
+`elapsed_time`
+
+: The amount of time between the start (`start_time`) and end (`end_time`) of a Chef Infra Client run.
+
+`end_time`
+
+: The time at which a Chef Infra Client run ended.
+
+`exception`
+
+: The uncaught exception data which caused a Chef Infra Client run to fail; `nil` for a successful Chef Infra Client run.
+
+`failed?`
+
+: Show that a Chef Infra Client run has failed when uncaught exceptions were raised during a Chef Infra Client run. An exception handler runs when the `failed?` indicator is `true`.
+
+`node`
+
+: The node on which a Chef Infra Client run occurred.
+
+`run_context`
+
+: An instance of the `Chef::RunContext` object; used by Chef Infra Client to track the context of the run; provides access to the `cookbook_collection`, `resource_collection`, and `definitions` properties.
+
+`start_time`
+
+: The time at which a Chef Infra Client run started.
+
+`success?`
+
+: Show that a Chef Infra Client run succeeded when uncaught exceptions weren't raised during a Chef Infra Client run. A report handler runs when the `success?` indicator is `true`.
+
+`updated_resources`
+
+: A list of resources that were marked as updated as a result of a Chef Infra Client run.
+
+{{< note >}}
+
+These properties aren't always available. For example, a start handler runs at the beginning of Chef Infra Client run, which means that properties like `end_time` and `elapsed_time` are still unknown and will be unavailable to the `run_status` object.
+
+{{< /note >}}
+
+## Examples
+
+The following sections show examples of handlers.
+
+### Cookbook versions
+
+Community member `juliandunn` created a custom [report handler that logs all of the cookbooks and cookbook versions](https://github.com/juliandunn/cookbook_versions_handler) that were used during a Chef Infra Client run, and then reports after the run is complete. This handler requires the **chef_handler** resource (which is available from the **chef_handler** cookbook).
+
+#### cookbook_versions.rb
+
+The following custom handler defines how cookbooks and cookbook versions that are used during a Chef Infra Client run will be compiled into a report using the `Chef::Log` class in Chef Infra Client:
+
+```ruby
+require 'chef/log'
+
+module Opscode
+ class CookbookVersionsHandler < Chef::Handler
+ def report
+ cookbooks = run_context.cookbook_collection
+ Chef::Log.info('Cookbooks and versions run: #{cookbooks.keys.map {|x| cookbooks[x].name.to_s + ' ' + cookbooks[x].version} }')
+ end
+ end
+end
+```
+
+#### default.rb
+
+The following recipe is added to the run-list for every node on which a list of cookbooks and versions will be generated as report output after every Chef Infra Client run.
+
+```ruby
+include_recipe 'chef_handler'
+
+cookbook_file "#{node['chef_handler']['handler_path']}/cookbook_versions.rb" do
+ source 'cookbook_versions.rb'
+ owner 'root'
+ group 'root'
+ mode '0755'
+ action :create
+end
+
+chef_handler 'Opscode::CookbookVersionsHandler' do
+ source "#{node['chef_handler']['handler_path']}/cookbook_versions.rb"
+ supports :report => true
+ action :enable
+end
+```
+
+This recipe will generate report output similar to the following:
+
+```ruby
+[2013-11-26T03:11:06+00:00] INFO: Chef Run complete in 0.300029878 seconds
+[2013-11-26T03:11:06+00:00] INFO: Running report handlers
+[2013-11-26T03:11:06+00:00] INFO: Cookbooks and versions run: ["chef_handler 1.1.4", "cookbook_versions_handler 1.0.0"]
+[2013-11-26T03:11:06+00:00] INFO: Report handlers complete
+```
+
+### Reporting
+
+Start handler functionality was added when Chef started building add-ons for the Chef Infra Server. The Reporting add-on is designed to create reporting data based on a Chef Infra Client run. And since Reporting needs to be able to collect data for the entire Chef Infra Client run, Reporting needs to be enabled before anything else happens at the start of a Chef Infra Client run.
+
+{{< note >}}
+
+The start handler used by the Reporting add-on for the Chef Infra Server is always installed using the **chef-client** cookbook.
+
+{{< /note >}}
+
+#### start_handler.rb
+
+The following code shows the start handler used by the Reporting add-in for the Chef Infra Server:
+
+```ruby
+require 'chef/handler'
+require 'chef/rest'
+require 'chef/version_constraint'
+
+class Chef
+ class Reporting
+ class StartHandler < ::Chef::Handler
+ attr_reader :config
+
+ def initialize(config = {})
+ @config = config
+ end
+
+ def report
+ version_checker = Chef::VersionConstraint.new('< 11.6.0')
+ if version_checker.include?(Chef::VERSION)
+ Chef::Log.info('Enabling backported resource reporting Handler')
+ rest = Chef::REST.new(Chef::Config[:chef_server_url], @run_status.node.name, Chef::Config[:client_key])
+ resource_reporter = Chef::Reporting::ResourceReporter.new(rest)
+ @run_status.events.register(resource_reporter)
+
+ resource_reporter.run_started(@run_status)
+ else
+ Chef::Log.debug('Chef Version already has new Resource Reporter - skipping startup of backport version')
+ end
+ end
+ end
+ end
+end
+```
+
+### json_file Handler
+
+The [json_file](https://github.com/chef/chef/blob/main/lib/chef/handler/json_file.rb) handler is available from the **chef_handler** cookbook and can be used with exceptions and reports. It serializes run status data to a JSON file. This handler may be enabled in one of the following ways.
+
+By adding the following lines of Ruby code to either the client.rb file or the solo.rb file, depending on how Chef Infra Client is being run:
+
+```ruby
+require 'chef/handler/json_file'
+report_handlers << Chef::Handler::JsonFile.new(:path => '/var/chef/reports')
+exception_handlers << Chef::Handler::JsonFile.new(:path => '/var/chef/reports')
+```
+
+By using the **chef_handler** resource in a recipe, similar to the
+following:
+
+```ruby
+chef_handler 'Chef::Handler::JsonFile' do
+ source 'chef/handler/json_file'
+ arguments :path => '/var/chef/reports'
+ action :enable
+end
+```
+
+After it has run, the run status data can be loaded and inspected using Interactive Ruby (IRb):
+
+```ruby
+irb(main):002:0> require 'json' => true
+irb(main):003:0> require 'chef' => true
+irb(main):004:0> r = JSON.parse(IO.read('/var/chef/reports/chef-run-report-20110322060731.json')) => ... output truncated
+irb(main):005:0> r.keys => ['end_time', 'node', 'updated_resources', 'exception', 'all_resources', 'success', 'elapsed_time', 'start_time', 'backtrace']
+irb(main):006:0> r['elapsed_time'] => 0.00246
+```
+
+### error_report Handler
+
+The [error_report](https://github.com/chef/chef/blob/main/lib/chef/handler/error_report.rb) handler is built into Chef Infra Client and can be used for both exceptions and reports. It serializes error report data to a JSON file. This handler may be enabled in one of the following ways.
+
+By adding the following lines of Ruby code to either the client.rb file or the solo.rb file, depending on how Chef Infra Client is being run:
+
+```ruby
+require 'chef/handler/error_report'
+report_handlers << Chef::Handler::ErrorReport.new()
+exception_handlers << Chef::Handler::ErrorReport.new()
+```
+
+By using the [chef_handler](/resources/chef_handler/) resource in a recipe, similar to the following:
+
+```ruby
+chef_handler 'Chef::Handler::ErrorReport' do
+ source 'chef/handler/error_report'
+ action :enable
+end
+```
+
+### Community Handlers
+
+{{< readfile file="content/reusable/md/handler_community_handlers.md" >}}
diff --git a/content/helpers.md b/content/helpers.md
new file mode 100644
index 0000000..2fa601e
--- /dev/null
+++ b/content/helpers.md
@@ -0,0 +1,42 @@
++++
+title = "Helpers"
+draft = false
+gh_repo = "chef-web-docs"
+
+product = ["client", "workstation"]
+
+[menu]
+ [menu.infra]
+ title = "Helpers"
+ identifier = "chef_infra/resources/custom_resources/helpers Library Helpers"
+ parent = "chef_infra/resources/custom_resources"
+ weight = 30
++++
+
+Helper classes enable users to share code between Custom Resources. Rspec method test are possible when code is abstracted into plain Ruby files.
+
+## Example
+
+To include the following helper from `libraries/helpers.rb`
+
+```ruby
+#libraries/helpers.rb
+module Haproxy
+ module cookbook
+ module ResourceHelpers
+ def haproxy_version
+ version = Mixlib::ShellOut.new("haproxy -v | grep version | awk '{ print $3 }'")
+ version.run_command.stdout.to_f
+ end
+ end
+ end
+end
+```
+
+Within a Custom Resource file, use the include directive in the action_class, to include all methods in the specified module.
+
+```ruby
+action_class do
+ include Haproxy::Cookbook::ResourceHelpers
+end
+```
diff --git a/content/infra_language/_index.md b/content/infra_language/_index.md
new file mode 100644
index 0000000..9c9cbd7
--- /dev/null
+++ b/content/infra_language/_index.md
@@ -0,0 +1,32 @@
++++
+title = "About the Chef Infra Language"
+draft = false
+gh_repo = "chef-web-docs"
+
+aliases = ["/dsl_recipe.html", "/dsl_recipe"]
+
+[cascade]
+ product = ["client"]
+
+[menu]
+ [menu.infra]
+ title = "Language Overview"
+ identifier = "chef_infra/infra_language/ Language Overview"
+ parent = "chef_infra/infra_language"
+ weight = 10
++++
+
+{{< readfile file="content/reusable/md/infra_lang_summary.md" >}}
+
+{{< readfile file="content/reusable/md/infra_lang_ruby.md" >}}
+
+## Resources
+
+Resources are the cornerstone of the Chef Infra Language. Resources define the desired state of an object on a system. A resource can be as simple as a directory or as complex or a complete security policy. Chef Infra Client ships with over 150 resources for configuring components such as packages, files, directories, or firewalls. For more information on resources in Chef Infra Client including a complete list of those included out of the box see [Resources](/resources).
+
+## Helpers Methods
+
+The Chef Infra Language provides support for using attributes, data bags (and
+encrypted data), and search results in a recipe, as well as four helper
+methods that can be used to check for a node's platform from the recipe
+to ensure that specific actions are taken for specific platforms.
diff --git a/content/infra_language/checking_architectures.md b/content/infra_language/checking_architectures.md
new file mode 100644
index 0000000..663612e
--- /dev/null
+++ b/content/infra_language/checking_architectures.md
@@ -0,0 +1,62 @@
++++
+title = "Chef Infra Language: Checking Architectures"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+[menu]
+ [menu.infra]
+ title = "Checking Architectures"
+ identifier = "chef_infra/infra_language/checking_architectures.md Checking Architectures"
+ parent = "chef_infra/infra_language"
++++
+
+Chef Infra Client 15.5 and later include a number of helper methods for checking the processor architecture of systems. These methods can be used in attribute files, recipes, and resources.
+
+## _32_bit?
+
+Determines if the current architecture is 32-bit.
+
+## _64_bit?
+
+Determines if the current architecture is 64-bit.
+
+## arm?
+
+Determines if the current architecture is arm.
+
+## armhf?
+
+Determines if the current architecture is 32-bit ARM hard float.
+
+## i386?
+
+Determines if the current architecture is i386.
+
+## intel?
+
+Determines if the current architecture is Intel.
+
+## powerpc?
+
+Determines if the current architecture is PowerPC.
+
+## ppc64?
+
+Determines if the current architecture is PowerPC 64bit Big Endian.
+
+## ppc64le?
+
+Determines if the current architecture is PowerPC 64bit Little Endian.
+
+## s390?
+
+Determines if the current architecture is s390.
+
+## s390x?
+
+Determines if the current architecture is s390x.
+
+## sparc?
+
+Determines if the current architecture is SPARC.
diff --git a/content/infra_language/checking_clouds.md b/content/infra_language/checking_clouds.md
new file mode 100644
index 0000000..9dc02c4
--- /dev/null
+++ b/content/infra_language/checking_clouds.md
@@ -0,0 +1,54 @@
++++
+title = "Chef Infra Language: Checking Clouds"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+[menu]
+ [menu.infra]
+ title = "Checking Clouds"
+ identifier = "chef_infra/infra_language/checking_clouds.md Checking Clouds"
+ parent = "chef_infra/infra_language"
++++
+
+Chef Infra Client 15.8 and later include a number of helper methods for checking if a node is running in a public or private cloud.
+
+## cloud?
+
+Determine if the current node is running a known public or private cloud.
+
+## ec2?
+
+Determine if the current node is running in AWS EC2.
+
+## gce?
+
+Determine if the current node is running in Google Compute Engine (GCE)
+
+## rackspace?
+
+Determine if the current node is running in Rackspace.
+
+## eucalyptus?
+
+Determine if the current node is running in Eucalyptus.
+
+## linode?
+
+Determine if the current node is running in Linode.
+
+## openstack?
+
+Determine if the current node is running in OpenStack.
+
+## azure?
+
+Determine if the current node is running in Microsoft Azure.
+
+## digital_ocean?
+
+Determine if the current node is running in DigitalOcean.
+
+## softlayer?
+
+Determine if the current node is running in SoftLayer (IBM Cloud).
diff --git a/content/infra_language/checking_hypervisors.md b/content/infra_language/checking_hypervisors.md
new file mode 100644
index 0000000..cc830c4
--- /dev/null
+++ b/content/infra_language/checking_hypervisors.md
@@ -0,0 +1,102 @@
++++
+title = "Chef Infra Language: Checking Hypervisors"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+[menu]
+ [menu.infra]
+ title = "Checking Hypervisors"
+ identifier = "chef_infra/infra_language/checking_hypervisors.md Checking Hypervisors"
+ parent = "chef_infra/infra_language"
++++
+
+Chef Infra Client 15.8 and later include a number of helper methods for checking if a hypervisor host or guest.
+
+## guest?
+
+Determine if the current node is running under any virtualization environment.
+
+## hypervisor?
+
+Determine if the current node supports running guests under any virtualization environment.
+
+## physical?
+
+Determine if the current node isn't running under any virtualization environment (bare-metal or hypervisor on metal).
+
+## hyperv?
+
+Determine if the current node is a Hyper-V guest.
+
+## kvm?
+
+Determine if the current node is a KVM guest.
+
+## kvm_host?
+
+Determine if the current node is a KVM host.
+
+## lxc?
+
+Determine if the current node is a LXC-based container.
+
+## lxc_host?
+
+Determine if the current node is a LXC host.
+
+## parallels?
+
+Determine if the current node is running under Parallels Desktop.
+
+## parallels_host?
+
+Determine if the current node is a Parallels Desktop host.
+
+## vbox?
+
+Determine if the current node is a VirtualBox guest.
+
+## vbox_host?
+
+Determine if the current node is a VirtualBox host.
+
+## vmware?
+
+Determine if the current node is a VMWare guest.
+
+## vmware_host?
+
+Determine if the current node is VMware host.
+
+## vmware_desktop?
+
+Determine if the current node is a guest on VMware desktop products (Fusion, Player, Workstation).
+
+## vmware_vsphere?
+
+Determine if the current node is a guest on VMware vSphere (aka ESXi).
+
+## openvz?
+
+Determine if the current node is an openvz guest.
+
+## openvz_host?
+
+Determine if the current node is an openvz host.
+
+## vagrant?
+
+Determine if the current node is running as a vagrant guest.
+
+## vagrant_key?
+
+Check if the `vagrant` key exists on the +node+ object. Note: This key is no longer populated by vagrant, but it's kept around for legacy purposes.
+
+## vagrant_domain?
+
+Check if `vagrantup.com` is included in the node's domain.
+
+## vagrant_user?
+
+Check if the system contains a `vagrant` user.
diff --git a/content/infra_language/checking_platforms.md b/content/infra_language/checking_platforms.md
new file mode 100644
index 0000000..1081a18
--- /dev/null
+++ b/content/infra_language/checking_platforms.md
@@ -0,0 +1,466 @@
++++
+title = "Chef Infra Language: Checking Platforms"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+[menu]
+ [menu.infra]
+ title = "Checking Platforms"
+ identifier = "chef_infra/infra_language/checking_platforms.md Checking Platforms"
+ parent = "chef_infra/infra_language"
++++
+
+## platform?
+
+Use the `platform?` helper method to ensure that certain actions are run for specific platforms. The `platform?` method will return true if one of the listed parameters matches the `node['platform']` attribute that's detected by [Ohai](/ohai) during every Chef Infra Client run.
+
+The syntax for the `platform?` method is as follows:
+
+```ruby
+platform?('parameter', 'parameter')
+```
+
+where:
+
+- `parameter` is a comma-separated list, each specifying a platform, such as Red Hat, CentOS, or Fedora
+- `platform?` method is typically used with an `if`, `elsif`, or `case` statement that contains Ruby code that's specific for the platform, if detected
+
+### platform Values
+
+
+
+
+
+
+
+
+
Parameter
+
Platforms
+
+
+
+
+
aix
+
IBM AIX
+
+
+
alibabalinux
+
Alibaba Cloud Linux
+
+
+
almalinux
+
AlmaLinux
+
+
+
amazon
+
Amazon Linux
+
+
+
arch
+
Arch Linux
+
+
+
clearos
+
ClearOS
+
+
+
cloudlinux
+
Cloud Linux OS
+
+
+
cumulus
+
NVIDIA Cumulus Linux
+
+
+
debian
+
Debian GNU/Linux
+
+
+
fedora
+
Fedora
+
+
+
freebsd
+
FreeBSD
+
+
+
gentoo
+
Gentoo Linux
+
+
+
linuxmint
+
Linux Mint
+
+
+
mac_os_x
+
macOS
+
+
+
netbsd
+
NetBSD
+
+
+
openbsd
+
OpenBSD
+
+
+
openindiana
+
OpenIndiana
+
+
+
opensuseleap
+
openSUSE leap
+
+
+
pidora
+
Pidora
+
+
+
raspbian
+
Raspberry Pi OS
+
+
+
redhat
+
Red Hat Enterprise Linux
+
+
+
rocky
+
Rocky Linux
+
+
+
sangoma
+
Sangoma Linux
+
+
+
scientific
+
Scientific Linux
+
+
+
solaris2
+
Oracle Solaris
+
+
+
suse
+
SUSE Linux Enterprise Server.
+
+
+
ubuntu
+
Ubuntu Linux
+
+
+
virtuozzo
+
Virtuozzo
+
+
+
windows
+
Windows
+
+
+
xenserver
+
Citrix XenServer
+
+
+
+
+### Examples
+
+#### Installing the cron package on Debian systems
+
+```ruby
+package 'cron' if platform?('debian')
+```
+
+#### Deleting a file on Red Hat and Debian systems
+
+```ruby
+if platform?('redhat', 'debian')
+ file '/etc/some_config' do
+ action :remove
+ end
+end
+```
+
+#### Installing the correct Firefox package
+
+The following example shows how an if statement can be used with the
+`platform?` method in the Chef Infra Language to run code specific to Microsoft
+Windows. The code is defined using the **ruby_block** resource:
+
+```ruby
+if platform?('windows')
+ chocolatey_package 'firefox'
+else
+ package 'firefox'
+end
+```
+
+## platform_family?
+
+Use the `platform_family?` method to ensure that certain actions are run for specific platform families. The `platform_family?` method will return true if one of the listed parameters matches the `node['platform_family']` attribute that are detected by [Ohai](/ohai) during every Chef Infra Client run.
+
+The syntax for the `platform_family?` method is as follows:
+
+```ruby
+platform_family?('parameter', 'parameter')
+```
+
+where:
+
+- `'parameter'` is a comma-separated list, each specifying a platform family, such as Debian, or Red Hat Enterprise Linux
+- `platform_family?` method is typically used with an `if`, `elsif`, or `case` statement that contains Ruby code that's specific for the platform family, if detected
+
+### platform_family Values
+
+
+
+
+
+
+
+
+
Parameter
+
Platforms
+
+
+
+
+
aix
+
aix platform.
+
+
+
alpine
+
alpine platform.
+
+
+
amazon
+
amazon platform.
+
+
+
arch
+
arch, manjaro, and antergos platforms.
+
+
+
debian
+
debian, ubuntu, linuxmint, raspbian, cumulus, kali, sangoma, and pop platforms.
+
+### Examples
+
+For example:
+
+```ruby
+platform_family?('gentoo')
+```
+
+or:
+
+```ruby
+platform_family?('slackware', 'suse', 'arch')
+```
+
+#### Use a Specific Binary For a Specific Platform
+
+The following is an example of using the `platform_family?` method in
+the Chef Infra Language to create a variable that can be used with other
+resources in the same recipe. In this example, `platform_family?` is
+being used to ensure that a specific binary is used for a specific
+platform before using the **remote_file** resource to download a file
+from a remote location, and then using the **execute** resource to
+install that file by running a command.
+
+```ruby
+if platform_family?('rhel')
+ pip_binary = '/usr/bin/pip'
+else
+ pip_binary = '/usr/local/bin/pip'
+end
+
+remote_file "#{Chef::Config[:file_cache_path]}/distribute_setup.py" do
+ source 'http://python-distribute.org/distribute_setup.py'
+ mode '0755'
+ not_if { ::File.exist?(pip_binary) }
+end
+
+execute 'install-pip' do
+ cwd Chef::Config[:file_cache_path]
+ command <<-EOF
+ # command for installing Python goes here
+ EOF
+ not_if { ::File.exist?(pip_binary) }
+end
+```
+
+where a command for installing Python might look something like:
+
+```ruby
+#{node['python']['binary']} distribute_setup.py
+#{::File.dirname(pip_binary)}/easy_install pip
+```
+
+## value_for_platform
+
+Use the `value_for_platform` method in a recipe to select a value based on the `node['platform']` and `node['platform_version']` attributes. These values are detected by Ohai during every Chef Infra Client run.
+
+The syntax for the `value_for_platform` method is as follows:
+
+```ruby
+value_for_platform( ['platform', ...] => { 'version' => 'value' } )
+```
+
+where:
+
+- `'platform', ...` is a comma-separated list of platforms, such as Red Hat, openSUSE, or Fedora
+- `version` specifies the version of that platform
+- Version constraints---`>`, `<`, `>=`, `<=`, `~>`---may be used with `version`; an exception is raised if two version constraints match; an exact match will always take precedence over a match made from a version constraint
+- `value` specifies the value that will be used if the node's platform matches the `value_for_platform` method
+
+When each value only has a single platform, use the following syntax:
+
+```ruby
+value_for_platform(
+ 'platform' => { 'version' => 'value' },
+ 'platform' => { 'version' => 'value' },
+ 'platform' => 'value'
+)
+```
+
+When each value has more than one platform, the syntax changes to:
+
+```ruby
+value_for_platform(
+ ['platform', 'platform', ... ] => {
+ 'version' => 'value'
+ },
+)
+```
+
+### Operators
+
+{{< readfile file="content/reusable/md/cookbooks_version_constraints_operators.md" >}}
+
+### Examples
+
+The following example will set `package_name` to `httpd` for the Red Hat platform and to `apache2` for the Debian platform:
+
+```ruby
+package_name = value_for_platform(
+ ['centos', 'redhat', 'suse', 'fedora' ] => {
+ 'default' => 'httpd'
+ },
+ ['ubuntu', 'debian'] => {
+ 'default' => 'apache2'
+ }
+)
+```
+
+The following example will set `package` to `apache-couchdb` for OpenBSD platforms, `dev-db/couchdb` for Gentoo platforms, and `couchdb` for all other platforms:
+
+```ruby
+package = value_for_platform(
+ 'openbsd' => { 'default' => 'apache-couchdb' },
+ 'gentoo' => { 'default' => 'dev-db/couchdb' },
+ 'default' => 'couchdb'
+)
+```
+
+The following example shows using version constraints to specify a value based on the version:
+
+```ruby
+value_for_platform(
+ 'os1' => { '< 1.0' => 'less than 1.0',
+ '~> 2.0' => 'version 2.x',
+ '>= 3.0' => 'greater than or equal to version 3.0',
+ '3.0.1' => '3.0.1 will always use this value' }
+)
+```
+
+## value_for_platform_family
+
+Use the `value_for_platform_family` method in a recipe to select a value based on the `node['platform_family']` attribute. This value is detected by Ohai during every Chef Infra Client run.
+
+The syntax for the `value_for_platform_family` method is as follows:
+
+```ruby
+value_for_platform_family( 'platform_family' => 'value', ... )
+```
+
+where:
+
+- `'platform_family' => 'value', ...` is a comma-separated list of platforms, such as Fedora, openSUSE, or Red Hat Enterprise Linux
+- `value` specifies the value that will be used if the node's platform family matches the `value_for_platform_family` method
+
+When each value only has a single platform, use the following syntax:
+
+```ruby
+value_for_platform_family(
+ 'platform_family' => 'value',
+ 'platform_family' => 'value',
+ 'platform_family' => 'value'
+)
+```
+
+When each value has more than one platform, the syntax changes to:
+
+```ruby
+value_for_platform_family(
+ ['platform_family', 'platform_family', 'platform_family', 'platform_family' ] => 'value',
+ ['platform_family', 'platform_family'] => 'value',
+ 'default' => 'value'
+)
+```
+
+The following example will set `package` to `httpd-devel` for the Red Hat Enterprise Linux, Fedora, and openSUSE platforms and to `apache2-dev` for the Debian platform:
+
+```ruby
+package = value_for_platform_family(
+ ['rhel', 'fedora', 'suse'] => 'httpd-devel',
+ 'debian' => 'apache2-dev'
+)
+```
diff --git a/content/infra_language/cookbook_execution.md b/content/infra_language/cookbook_execution.md
new file mode 100644
index 0000000..c35aaee
--- /dev/null
+++ b/content/infra_language/cookbook_execution.md
@@ -0,0 +1,162 @@
++++
+title = "Chef Infra Language: Cookbook Execution"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+[menu]
+ [menu.infra]
+ title = "Cookbook Execution"
+ identifier = "chef_infra/infra_language/cookbook_execution.md Cookbook Execution"
+ parent = "chef_infra/infra_language"
++++
+
+The Chef Infra Language includes helper methods for gathering information on the execution of the Chef Infra Client recipe and resource code. This information can be used in recipes and resources to take specific actions.
+
+## Chef Infra Client State
+
+These helpers allow you to understand the state of the node that Chef Infra Client is executing on.
+
+### node
+
+Use the `node` method, often referred to as the node object, to access data collected on the system through [Ohai](/ohai) as well as node attributes set in cookbooks or Policyfiles.
+
+The syntax for the `node` method is as follows:
+
+```ruby
+node['specific_attribute']
+```
+
+### cookbook_name
+
+Use the `cookbook_name` method to return the name of a cookbook.
+
+The syntax for the `cookbook_name` method is as follows:
+
+```ruby
+cookbook_name
+```
+
+This method is often used as part of a log entry. For example:
+
+```ruby
+Chef::Log.info("I am a message from the #{recipe_name} recipe in the #{cookbook_name} cookbook.")
+```
+
+### recipe_name
+
+Use the `recipe_name` method to return the name of a recipe.
+
+The syntax for the `recipe_name` method is as follows:
+
+```ruby
+recipe_name
+```
+
+This method is often used as part of a log entry. For example:
+
+```ruby
+Chef::Log.info("I am a message from the #{recipe_name} recipe in the #{cookbook_name} cookbook.")
+```
+
+### resources
+
+Use the `resources` method to look up a resource in the resource collection. The `resources` method returns the value for the resource that it finds in the resource collection. The preferred syntax for the `resources` method is as follows:
+
+```ruby
+resources('resource_type[resource_name]')
+```
+
+but the following syntax can also be used:
+
+```ruby
+resources(resource_type: 'resource_name')
+```
+
+where in either approach `resource_type` is the name of a resource and `resource_name` is the name of a resource that can be configured by Chef Infra Client.
+
+The `resources` method can be used to modify a resource later on in a recipe. For example:
+
+```ruby
+file '/etc/hosts' do
+ content '127.0.0.1 localhost.localdomain localhost'
+end
+```
+
+and then later in the same recipe, or elsewhere:
+
+```ruby
+f = resources('file[/etc/hosts]')
+f.mode '0644'
+```
+
+where `file` is the type of resource, `/etc/hosts` is the name, and `f.mode` is used to set the `mode` property on the **file** resource.
+
+### attribute?
+
+Use the `attribute?` method to ensure that certain actions only execute in the presence of a particular node attribute. The `attribute?` method will return true if one of the listed node attributes matches a node attribute that's detected by Ohai during every Chef Infra Client run.
+
+The syntax for the `attribute?` method is as follows:
+
+```ruby
+attribute?('name_of_attribute')
+```
+
+For example:
+
+```ruby
+if node.attribute?('ipaddress')
+ # the node has an IP address
+end
+```
+
+### reboot_pending?
+
+Use the `reboot_pending?` method to test if a node needs a reboot, or is expected to reboot. `reboot_pending?` returns `true` when the node needs a reboot.
+
+The syntax for the `reboot_pending?` method is as follows:
+
+```ruby
+reboot_pending?
+```
+
+## Executing Code
+
+These helpers allow you to include recipes and impact how resources run on the system.
+
+### include_recipe
+
+{{< readfile file="content/reusable/md/cookbooks_recipe_include_in_recipe.md" >}}
+
+### with_run_context
+
+Use the `with_run_context` method to define a block that has a pointer to a location in the `run_context` hierarchy. Resources in recipes always run at the root of the `run_context` hierarchy, whereas custom resources and notification blocks always build a child `run_context` which contains their sub-resources.
+
+The syntax for the `with_run_context` method is as follows:
+
+```ruby
+with_run_context :type do
+ # some arbitrary pure Ruby stuff goes here
+end
+```
+
+where `:type` may be one of the following:
+
+- `:root` runs the block as part of the root `run_context` hierarchy
+- `:parent` runs the block as part of the parent process in the `run_context` hierarchy
+
+For example:
+
+```ruby
+action :run do
+ with_run_context :root do
+ edit_resource(:my_thing, "accumulated state") do
+ action :nothing
+ my_array_property << accumulate_some_stuff
+ end
+ end
+ log "kick it off" do
+ notifies :run, "my_thing[accumulated state]", :delayed
+ end
+end
+```
diff --git a/content/infra_language/editing_resources.md b/content/infra_language/editing_resources.md
new file mode 100644
index 0000000..8bbda6e
--- /dev/null
+++ b/content/infra_language/editing_resources.md
@@ -0,0 +1,209 @@
++++
+title = "Chef Infra Language: Editing Resources"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+[menu]
+ [menu.infra]
+ title = "Editing Resources"
+ identifier = "chef_infra/infra_language/editing_resources.md Editing Resources"
+ parent = "chef_infra/infra_language"
++++
+
+## declare_resource
+
+Use the `declare_resource` method to instantiate a resource and then add it to the resource collection.
+
+The syntax for the `declare_resource` method is as follows:
+
+```ruby
+declare_resource(:resource_type, 'resource_name', resource_attrs_block)
+```
+
+where:
+
+- `:resource_type` is the resource type, such as `:file` (for the **file** resource) or `:template` (for the **template** resource). Any resource available to Chef may be declared.
+- `resource_name` the property that's the default name of the resource, typically the string that appears in the `resource 'name' do` block of a resource (but not always); see the Syntax section for the resource to be declared to verify the default name property.
+- `resource_attrs_block` is a block in which properties of the instantiated resource are declared.
+
+For example:
+
+```ruby
+declare_resource(:file, '/x/y.txy', caller[0]) do
+ action :delete
+end
+```
+
+is equivalent to:
+
+```ruby
+file '/x/y.txt' do
+ action :delete
+end
+```
+
+## delete_resource
+
+Use the `delete_resource` method to find a resource in the resource collection, and then delete it.
+
+The syntax for the `delete_resource` method is as follows:
+
+```ruby
+delete_resource(:resource_type, 'resource_name')
+```
+
+where:
+
+- `:resource_type` is the resource type, such as `:file` (for the **file** resource) or `:template` (for the **template** resource). Any resource available to Chef may be declared.
+- `resource_name` the property that's the default name of the resource, typically the string that appears in the `resource 'name' do` block of a resource (but not always); see the Syntax section for the resource to be declared to verify the default name property.
+
+For example:
+
+```ruby
+delete_resource(:template, '/x/y.erb')
+```
+
+## delete_resource!
+
+Use the `delete_resource!` method to find a resource in the resource
+collection, and then delete it. If the resource isn't found, an
+exception is returned.
+
+The syntax for the `delete_resource!` method is as follows:
+
+```ruby
+delete_resource!(:resource_type, 'resource_name')
+```
+
+where:
+
+- `:resource_type` is the resource type, such as `:file` (for the **file** resource) or `:template` (for the **template** resource). Any resource available to Chef Infra may be declared.
+- `resource_name` the property that's the default name of the resource, typically the string that appears in the `resource 'name' do` block of a resource (but not always); see the Syntax section for the resource to be declared to verify the default name property.
+
+For example:
+
+```ruby
+delete_resource!(:file, '/x/file.txt')
+```
+
+## edit_resource
+
+Use the `edit_resource` method to:
+
+- Find a resource in the resource collection, and then edit it.
+- Define a resource block. If a resource block with the same name exists in the resource collection, it will be updated with the contents of the resource block defined by the `edit_resource` method. If a resource block doesn't exist in the resource collection, it will be created.
+
+The syntax for the `edit_resource` method is as follows:
+
+```ruby
+edit_resource(:resource_type, 'resource_name', resource_attrs_block)
+```
+
+where:
+
+- `:resource_type` is the resource type, such as `:file` (for the **file** resource) or `:template` (for the **template** resource). Any resource available to Chef may be declared.
+- `resource_name` the property that's the default name of the resource, typically the string that appears in the `resource 'name' do` block of a resource (but not always); see the Syntax section for the resource to be declared to verify the default name property.
+- `resource_attrs_block` is a block in which properties of the instantiated resource are declared.
+
+For example:
+
+```ruby
+edit_resource(:template, '/x/y.txy') do
+ cookbook 'cookbook_name'
+end
+```
+
+and a resource block:
+
+```ruby
+edit_resource(:template, '/etc/aliases') do
+ source 'aliases.erb'
+ cookbook 'aliases'
+ variables({:aliases => {} })
+ notifies :run, 'execute[newaliases]'
+end
+```
+
+## edit_resource!
+
+Use the `edit_resource!` method to:
+
+- Find a resource in the resource collection, and then edit it.
+- Define a resource block. If a resource with the same name exists in the resource collection, its properties will be updated with the contents of the resource block defined by the `edit_resource` method.
+
+In both cases, if the resource isn't found, an exception is returned.
+
+The syntax for the `edit_resource!` method is as follows:
+
+```ruby
+edit_resource!(:resource_type, 'resource_name')
+```
+
+where:
+
+- `:resource_type` is the resource type, such as `:file` (for the **file** resource) or `:template` (for the **template** resource). Any resource available to Chef may be declared.
+- `resource_name` the property that's the default name of the resource, typically the string that appears in the `resource 'name' do` block of a resource (but not always); see the Syntax section for the resource to be declared to verify the default name property.
+- `resource_attrs_block` is a block in which properties of the instantiated resource are declared.
+
+For example:
+
+```ruby
+edit_resource!(:file, '/x/y.rst')
+```
+
+## find_resource
+
+Use the `find_resource` method to:
+
+- Find a resource in the resource collection.
+- Define a resource block. If a resource block with the same name exists in the resource collection, it will be returned. If a resource block doesn't exist in the resource collection, it will be created.
+
+The syntax for the `find_resource` method is as follows:
+
+```ruby
+find_resource(:resource_type, 'resource_name')
+```
+
+where:
+
+- `:resource_type` is the resource type, such as `:file` (for the **file** resource) or `:template` (for the **template** resource). Any resource available to Chef may be declared.
+- `resource_name` the property that's the default name of the resource, typically the string that appears in the `resource 'name' do` block of a resource (but not always); see the Syntax section for the resource to be declared to verify the default name property.
+
+For example:
+
+```ruby
+find_resource(:template, '/x/y.txy')
+```
+
+and a resource block:
+
+```ruby
+find_resource(:template, '/etc/seapower') do
+ source 'seapower.erb'
+ cookbook 'seapower'
+ variables({:seapower => {} })
+ notifies :run, 'execute[newseapower]'
+end
+```
+
+## find_resource!
+
+Use the `find_resource!` method to find a resource in the resource collection. If the resource isn't found, an exception is returned.
+
+The syntax for the `find_resource!` method is as follows:
+
+```ruby
+find_resource!(:resource_type, 'resource_name')
+```
+
+where:
+
+- `:resource_type` is the resource type, such as `:file` (for the **file** resource) or `:template` (for the **template** resource). Any resource available to Chef may be declared.
+- `resource_name` the property that's the default name of the resource, typically the string that appears in the `resource 'name' do` block of a resource (but not always); see the Syntax section for the resource to be declared to verify the default name property.
+
+For example:
+
+```ruby
+find_resource!(:template, '/x/y.erb')
+```
diff --git a/content/infra_language/logging.md b/content/infra_language/logging.md
new file mode 100644
index 0000000..ea68c76
--- /dev/null
+++ b/content/infra_language/logging.md
@@ -0,0 +1,22 @@
++++
+title = "Chef Infra Language: Logging"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+[menu]
+ [menu.infra]
+ title = "Logging"
+ identifier = "chef_infra/infra_language/logging.md Logging"
+ parent = "chef_infra/infra_language"
++++
+
+## Log Entries
+
+{{< readfile file="content/reusable/md/ruby_style_basics_chef_log.md" >}}
+
+### Examples
+
+{{< readfile file="content/reusable/md/ruby_class_chef_log_fatal.md" >}}
+
+{{< readfile file="content/reusable/md/ruby_class_chef_log_multiple.md" >}}
diff --git a/content/infra_language/node_tags.md b/content/infra_language/node_tags.md
new file mode 100644
index 0000000..91fb62f
--- /dev/null
+++ b/content/infra_language/node_tags.md
@@ -0,0 +1,16 @@
++++
+title = "Chef Infra Language: Node Tags"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+[menu]
+ [menu.infra]
+ title = "Node Tags"
+ identifier = "chef_infra/infra_language/node_tags.md Node Tags"
+ parent = "chef_infra/infra_language"
++++
+
+{{< readfile file="content/reusable/md/chef_tags.md" >}}
+
+{{< readfile file="content/reusable/md/cookbooks_recipe_tags.md" >}}
diff --git a/content/infra_language/reading_data_bags.md b/content/infra_language/reading_data_bags.md
new file mode 100644
index 0000000..524d98c
--- /dev/null
+++ b/content/infra_language/reading_data_bags.md
@@ -0,0 +1,82 @@
++++
+title = "Chef Infra Language: Reading Data Bags"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+[menu]
+ [menu.infra]
+ title = "Reading Data Bags"
+ identifier = "chef_infra/infra_language/reading_data_bags.md Reading Data Bags"
+ parent = "chef_infra/infra_language"
++++
+
+## data_bag
+
+{{< readfile file="content/reusable/md/data_bag.md" >}}
+
+Use the `data_bag` method to get a list of the contents of a data bag.
+
+The syntax for the `data_bag` method is as follows:
+
+```ruby
+data_bag(bag_name)
+```
+
+### Examples
+
+The following example shows how the `data_bag` method can be used in a recipe.
+
+#### Get a data bag, and then iterate through each data bag item
+
+{{< readfile file="content/reusable/md/infra_lang_data_bag.md" >}}
+
+## data_bag_item
+
+{{< readfile file="content/reusable/md/data_bag.md" >}}
+
+The `data_bag_item` method can be used in a recipe to get the contents of a data bag item.
+
+The syntax for the `data_bag_item` method is as follows:
+
+```ruby
+data_bag_item(bag_name, item, secret)
+```
+
+where `secret` is the secret used to load an encrypted data bag. If `secret` isn't specified, Chef Infra Client looks for a secret at the path specified by the `encrypted_data_bag_secret` setting in the `client.rb` file.
+
+### Examples
+
+The following examples show how the `data_bag_item` method can be used in a recipe.
+
+#### Get a data bag, and then iterate through each data bag item
+
+{{< readfile file="content/reusable/md/infra_lang_data_bag.md" >}}
+
+#### Use the contents of a data bag in a recipe
+
+The following example shows how to use the `data_bag` and `data_bag_item` methods in a recipe, also using a data bag named `sea-power`):
+
+```ruby
+package 'sea-power' do
+ action :install
+end
+
+directory node['sea-power']['base_path'] do
+ # attributes for owner, group, mode
+end
+
+gale_warnings = data_bag('sea-power').map do |viking_north|
+ data_bag_item('sea-power', viking_north)['source']
+end
+
+template '/etc/seattle/power.list' do
+ source 'seattle-power.erb'
+ # attributes for owner, group, mode
+ variables(
+ :base_path => node['sea-power']['base_path'],
+ # more variables
+ :repo_location => gale_warnings
+ )
+end
+```
diff --git a/content/infra_language/registry_keys.md b/content/infra_language/registry_keys.md
new file mode 100644
index 0000000..1368d6c
--- /dev/null
+++ b/content/infra_language/registry_keys.md
@@ -0,0 +1,94 @@
++++
+title = "Chef Infra Language: Reading Registry Keys"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+[menu]
+ [menu.infra]
+ title = "Reading Registry Keys"
+ identifier = "chef_infra/infra_language/registry_key.md Reading Registry Keys"
+ parent = "chef_infra/infra_language"
++++
+
+{{< readfile file="content/reusable/md/infra_lang_method_windows_methods.md" >}}
+
+{{< note >}}
+
+The recommended order in which registry key-specific methods should be
+used within a recipe is: `key_exists?`, `value_exists?`, `data_exists?`,
+`get_values`, `has_subkeys?`, and then `get_subkeys`.
+
+{{< /note >}}
+
+## registry_data_exists?
+
+{{< readfile file="content/reusable/md/infra_lang_method_registry_data_exists.md" >}}
+
+{{< note >}}
+
+{{< readfile file="content/reusable/md/notes_registry_key_not_if_only_if.md" >}}
+
+{{< /note >}}
+
+{{< readfile file="content/reusable/md/infra_lang_method_registry_data_exists_syntax.md" >}}
+
+## registry_get_subkeys
+
+{{< readfile file="content/reusable/md/infra_lang_method_registry_get_subkeys.md" >}}
+
+{{< note >}}
+
+{{< readfile file="content/reusable/md/notes_registry_key_not_if_only_if.md" >}}
+
+{{< /note >}}
+
+{{< readfile file="content/reusable/md/infra_lang_method_registry_get_subkeys_syntax.md" >}}
+
+## registry_get_values
+
+{{< readfile file="content/reusable/md/infra_lang_method_registry_get_values.md" >}}
+
+{{< note >}}
+
+{{< readfile file="content/reusable/md/notes_registry_key_not_if_only_if.md" >}}
+
+{{< /note >}}
+
+{{< readfile file="content/reusable/md/infra_lang_method_registry_get_values_syntax.md" >}}
+
+## registry_has_subkeys?
+
+{{< readfile file="content/reusable/md/infra_lang_method_registry_has_subkeys.md" >}}
+
+{{< note >}}
+
+{{< readfile file="content/reusable/md/notes_registry_key_not_if_only_if.md" >}}
+
+{{< /note >}}
+
+{{< readfile file="content/reusable/md/infra_lang_method_registry_has_subkeys_syntax.md" >}}
+
+## registry_key_exists?
+
+{{< readfile file="content/reusable/md/infra_lang_method_registry_key_exists.md" >}}
+
+{{< note >}}
+
+{{< readfile file="content/reusable/md/notes_registry_key_not_if_only_if.md" >}}
+
+{{< /note >}}
+
+{{< readfile file="content/reusable/md/infra_lang_method_registry_key_exists_syntax.md" >}}
+
+## registry_value_exists?
+
+{{< readfile file="content/reusable/md/infra_lang_method_registry_value_exists.md" >}}
+
+{{< note >}}
+
+{{< readfile file="content/reusable/md/notes_registry_key_not_if_only_if.md" >}}
+
+{{< /note >}}
+
+{{< readfile file="content/reusable/md/infra_lang_method_registry_value_exists_syntax.md" >}}
diff --git a/content/infra_language/search.md b/content/infra_language/search.md
new file mode 100644
index 0000000..48783b3
--- /dev/null
+++ b/content/infra_language/search.md
@@ -0,0 +1,149 @@
++++
+title = "Chef Infra Language: Search"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+[menu]
+ [menu.infra]
+ title = "Search"
+ identifier = "chef_infra/infra_language/search.md Search"
+ parent = "chef_infra/infra_language"
++++
+
+## search
+
+{{< readfile file="content/reusable/md/search.md" >}}
+
+Use the `search` method to perform a search query against the Chef Infra Server from within a recipe.
+
+The syntax for the `search` method is as follows:
+
+```ruby
+search(:index, 'query')
+```
+
+where:
+
+- `:index` is of name of the index on the Chef Infra Server against which the search query will run: `:client`, `:data_bag_name`, `:environment`, `:node`, and `:role`
+- `'query'` is a valid search query against an object on the Chef Infra Server (see below for more information about how to build the query)
+
+For example, using the results of a search query within a variable:
+
+```ruby
+webservers = search(:node, 'role:webserver')
+```
+
+and then using the results of that query to populate a template:
+
+```ruby
+template '/tmp/list_of_webservers' do
+ source 'list_of_webservers.erb'
+ variables(:webservers => webservers)
+end
+```
+
+### :filter_result
+
+{{< readfile file="content/reusable/md/infra_lang_method_search_filter_result.md" >}}
+
+### Query Syntax
+
+{{< readfile file="content/reusable/md/search_query_syntax.md" >}}
+
+#### Keys
+
+{{< readfile file="content/reusable/md/search_key.md" >}}
+
+#### Nested Fields
+
+{{< readfile file="content/reusable/md/search_key_nested.md" >}}
+
+#### Patterns
+
+{{< readfile file="content/reusable/md/search_pattern.md" >}}
+
+#### Exact Match
+
+{{< readfile file="content/reusable/md/search_pattern_exact.md" >}}
+
+#### Wildcard Match
+
+{{< readfile file="content/reusable/md/search_pattern_wildcard.md" >}}
+
+#### Range Match
+
+{{< readfile file="content/reusable/md/search_pattern_range.md" >}}
+
+#### Fuzzy Match
+
+{{< readfile file="content/reusable/md/search_pattern_fuzzy.md" >}}
+
+#### Operators
+
+{{< readfile file="content/reusable/md/search_boolean_operators.md" >}}
+
+#### Special Characters
+
+{{< readfile file="content/reusable/md/search_special_characters.md" >}}
+
+### Examples
+
+The following examples show how the `search` method can be used in a recipe.
+
+#### Use the search helper to find users
+
+The following example shows how to use the `search` method in the Recipe
+DSL to search for users:
+
+```ruby
+# the following code sample comes from the openvpn cookbook: https://github.com/chef-cookbooks/openvpn
+
+search("users", "*:*") do |u|
+ execute "generate-openvpn-#{u['id']}" do
+ command "./pkitool #{u['id']}"
+ cwd '/etc/openvpn/easy-rsa'
+ environment(
+ 'EASY_RSA' => '/etc/openvpn/easy-rsa',
+ 'KEY_CONFIG' => '/etc/openvpn/easy-rsa/openssl.cnf',
+ 'KEY_DIR' => node['openvpn']['key_dir'],
+ 'CA_EXPIRE' => node['openvpn']['key']['ca_expire'].to_s,
+ 'KEY_EXPIRE' => node['openvpn']['key']['expire'].to_s,
+ 'KEY_SIZE' => node['openvpn']['key']['size'].to_s,
+ 'KEY_COUNTRY' => node['openvpn']['key']['country'],
+ 'KEY_PROVINCE' => node['openvpn']['key']['province'],
+ 'KEY_CITY' => node['openvpn']['key']['city'],
+ 'KEY_ORG' => node['openvpn']['key']['org'],
+ 'KEY_EMAIL' => node['openvpn']['key']['email']
+ )
+ not_if { File.exist?("#{node['openvpn']['key_dir']}/#{u['id']}.crt") }
+ end
+
+ %w{ conf ovpn }.each do |ext|
+ template "#{node['openvpn']['key_dir']}/#{u['id']}.#{ext}" do
+ source 'client.conf.erb'
+ variables :username => u['id']
+ end
+ end
+
+ execute "create-openvpn-tar-#{u['id']}" do
+ cwd node['openvpn']['key_dir']
+ command <<-EOH
+ tar zcf #{u['id']}.tar.gz \
+ ca.crt #{u['id']}.crt #{u['id']}.key \
+ #{u['id']}.conf #{u['id']}.ovpn \
+ EOH
+ not_if { File.exist?("#{node['openvpn']['key_dir']}/#{u['id']}.tar.gz") }
+ end
+end
+```
+
+where
+
+- the search will use both of the **execute** resources, unless the
+ condition specified by the `not_if` commands are met
+- the `environments` property in the first **execute** resource is
+ being used to define values that appear as variables in the OpenVPN
+ configuration
+- the **template** resource tells Chef Infra Client which template to
+ use
diff --git a/content/infra_language/secrets.md b/content/infra_language/secrets.md
new file mode 100644
index 0000000..318cee5
--- /dev/null
+++ b/content/infra_language/secrets.md
@@ -0,0 +1,225 @@
++++
+title = "Chef Infra Language: Secrets"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+[menu]
+ [menu.infra]
+ title = "Secrets Management Integrations"
+ identifier = "chef_infra/infra_language/secrets.md Secrets Management Integrations"
+ parent = "chef_infra/infra_language"
++++
+
+The Secrets Management Integration helper is a beta feature starting in Chef Infra Client 17.5 and became a fully supported feature in Chef Infra Client 18.
+This helper allows you to access secrets from the following secrets management systems within your Infra recipes or resources:
+
+- AWS Secrets Manager
+- Akeyless Vault
+- Azure Key Vault
+- HashiCorp Vault
+
+## Syntax
+
+Use the following syntax to fetch secrets:
+
+```ruby
+secret(name: '', version: '', service: , config: {key: value})
+```
+
+
+
+Replace the following:
+
+``
+: The identifier or name for this secret.
+
+``
+: The secret version. If a service supports versions and you don't provide a version, the Secrets Management Integration helper fetches the latest version.
+
+ Secret versions supported with:
+
+ - AWS Secrets Manager
+ - Azure Key Vault
+
+``
+: The secret manager.
+
+ Allowed values:
+
+ - `:akeyless_vault`
+ - `:aws_secrets_manager`
+ - `:azure_key_vault`
+ - `:hashi_vault`
+
+`config`
+: Use `config` to set key/value settings passed to a secrets manager. For example, to set the AWS region that a secret is stored in with AWS Secrets Manager, add `config: {region: 'us-west-2'}`.
+
+
+
+### Set defaults
+
+You can set a default service and service configuration and then the Secrets Management Integration helper will use those settings every time you request a secret.
+This is useful if you want to request more than one secret from the same service.
+
+Use the `default_secret_service` and `default_secret_config` to define a default service and service configuration:
+
+```ruby
+default_secret_service()
+default_secret_config(key: "value")
+
+value1 = secret(name: "")
+value2 = secret(name: "")
+value3 = secret(name: "")
+```
+
+Or wrap your secret definitions using `with_secret_service` and `with_secret_config`:
+
+```ruby
+with_secret_service() do
+ with_secret_config(key: "value") do
+ value1 = secret(name: "")
+ value2 = secret(name: "")
+ value3 = secret(name: "")
+ end
+end
+```
+
+Define a default secret service and then fetch secrets with different configs:
+
+```ruby
+default_secret_service()
+
+with_secret_config(key: "") do
+ secret_1 = secret(name: "")
+ secret_2 = secret(name: "")
+end
+
+with_secret_config(key: "") do
+ secret_3 = secret(name: "")
+ secret_4 = secret(name: "")
+end
+```
+
+## Examples
+
+### Akeyless Vault
+
+Fetch secrets from Akeyless Vault using the access key and access ID:
+
+```ruby
+secret(name: '',
+ service: :akeyless_vault,
+ config: {
+ access_key: '',
+ access_id: ''
+ })
+```
+
+### AWS Secrets Manager
+
+Fetch a secret from AWS Secrets Manager:
+
+```ruby
+secret(name: '', service: :aws_secrets_manager)
+```
+
+Specify an AWS region:
+
+```ruby
+secret(name: '', service: :aws_secrets_manager, config: { region: '' })
+```
+
+### Azure Key Vault
+
+Fetch secrets from Azure Key Vault:
+
+```ruby
+secret(name: '', service: :azure_key_vault)
+```
+
+Specify the vault name in the config:
+
+```ruby
+secret(name: '', service: :azure_key_vault, config: { vault: '' })
+```
+
+Fetch a specific version of an Azure Key Vault secret:
+
+```ruby
+secret(name: '', version: 'v1', service: :azure_key_vault)
+```
+
+### HashiCorp Vault
+
+Fetch secrets from HashiCorp Vault using AWS IAM:
+
+```ruby
+secret(name: '',
+ service: :hashi_vault,
+ config: {
+ vault_addr: 'vault.example.com',
+ role_name: ''
+ })
+```
+
+Fetch secrets from HashiCorp Vault using tokens:
+
+```ruby
+secret(name: '',
+ service: :hashi_vault,
+ config: {
+ vault_addr: 'vault.example.com',
+ auth_method: :token,
+ token: ''
+ })
+```
+
+Fetch secrets from HashiCorp Vault using AppRole ID and an associated AppRole Secret ID:
+
+```ruby
+secret(name: '',
+ service: :hashi_vault,
+ config: {
+ vault_addr: 'vault.example.com',
+ auth_method: :approle,
+ approle_id: "",
+ approle_secret_id: ""
+ })
+```
+
+Fetch secrets using a token and an AppRole name creates a Secret ID associated with that AppRole:
+
+```ruby
+secret(name: '',
+ service: :hashi_vault,
+ config: {
+ vault_addr: 'vault.example.com',
+ auth_method: :approle,
+ approle_name: "",
+ token: ''
+ })
+```
+
+### Fetch secrets in cookbooks
+
+The secrets helper returns a text string, so you can use it anywhere in Chef Infra where you might hard code a value or access a value from a data bag.
+
+Write a secret to a file:
+
+```ruby
+file '/home/ubuntu/aws-secret' do
+ content secret(name: '', service: :aws_secrets_manager)
+end
+```
+
+Pass a secret to a template:
+
+```ruby
+template '/etc/my_fancy_service/my_fancy_service.conf' do
+ source 'config.erb'
+ variables(
+ db_token: secret(name: 'db_token', service: :aws_secrets_manager)
+ )
+end
+```
diff --git a/content/infra_language/shelling_out.md b/content/infra_language/shelling_out.md
new file mode 100644
index 0000000..9f8154b
--- /dev/null
+++ b/content/infra_language/shelling_out.md
@@ -0,0 +1,38 @@
++++
+title = "Chef Infra Language: Shelling Out"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+[menu]
+ [menu.infra]
+ title = "Shelling Out"
+ identifier = "chef_infra/infra_language/shelling_out.md Shelling Out"
+ parent = "chef_infra/infra_language"
++++
+
+In most cases when you need to run a particular command in a cookbook, you'll want to use the [execute resource](/resources/execute/). Helper methods for shelling out can be useful when writing custom resources or other more advanced Ruby code.
+
+## shell_out
+
+The `shell_out` method can be used to run a command against the node, and then display the output to the console when the log level is set to `debug`.
+
+The syntax for the `shell_out` method is as follows:
+
+```ruby
+shell_out(command_args)
+```
+
+where `command_args` is the command that's run against the node.
+
+## shell_out!
+
+The `shell_out!` method can be used to run a command against the node, display the output to the console when the log level is set to `debug`, and then raise an error when the method returns `false`.
+
+The syntax for the `shell_out!` method is as follows:
+
+```ruby
+shell_out!(command_args)
+```
+
+where `command_args` is the command that's run against the node. This method will return `true` or `false`.
diff --git a/content/infra_language/windows.md b/content/infra_language/windows.md
new file mode 100644
index 0000000..65130d0
--- /dev/null
+++ b/content/infra_language/windows.md
@@ -0,0 +1,34 @@
++++
+title = "Chef Infra Language: Windows"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+[menu]
+ [menu.infra]
+ title = "Windows"
+ identifier = "chef_infra/infra_language/windows.md Windows"
+ parent = "chef_infra/infra_language"
++++
+
+Chef Infra Client 15.8 and later include Windows-specific helpers for checking platform and package information.
+
+## windows_server_core?
+
+Determine if the current node is Windows Server Core.
+
+## windows_workstation?
+
+Determine if the current node is Windows Workstation.
+
+## windows_server?
+
+Determine if the current node is Windows Server.
+
+## windows_nt_version
+
+Determine the current Windows NT version. The NT version often differs from the marketing version, but offers a good way to find desktop and server releases that are based on the same codebase. For example NT 6.3 corresponds to Windows 8.1 and Windows 2012 R2.
+
+## powershell_version
+
+Determine the installed version of PowerShell.
diff --git a/content/install/_index.md b/content/install/_index.md
deleted file mode 100644
index a0d7255..0000000
--- a/content/install/_index.md
+++ /dev/null
@@ -1,34 +0,0 @@
-+++
-title = "Install Chef Infra Client"
-linkTitle = "Install"
-
-[menu.install]
-title = "Overview"
-parent = "install"
-weight = 10
-+++
-
-Use either a native installer or the Chef Infra Client migration tool to install or upgrade Chef Infra Client.
-
-## Supported platforms
-
-The migration tool and native installers can install and upgrade Chef Infra Client on:
-
-- Linux x86-64
-- Windows x86-64
-
-## Native installers
-
-The [Chef Infra Client native installers](installer) provide an efficient way to install Chef Infra Client on Debian and RPM-based distributions.
-You can download and install the pre-built `.msi`, `.deb`, or `.rpm` packages using your existing package management tools, simplifying the deployment process for managing system configurations.
-
-## Migration tool
-
-The [Chef Infra Client migration tool](migration_tool) (`chef-migrate`) allows you to install or upgrade Chef Infra Client to the latest version in both online and air-gapped environments.
-
-**Key functions:**
-
-- **Fresh installation:** Install Chef Infra Client 19 RC3
-- **Side-by-side installation:** Install Chef Infra Client 19 RC3 and remove or keep the previous Infra Client version. If you keep the previous version in side-by-side mode, the path to the most recent version takes precedence
-- **Omnibus upgrade:** Upgrade from Omnibus-based Chef Infra Client 17.x or 18.x versions
-- **Habitat upgrade:** Upgrade from Habitat-packaged Chef Infra Client 19 RC releases
diff --git a/content/install/installer/_index.md b/content/install/installer/_index.md
deleted file mode 100644
index 875038f..0000000
--- a/content/install/installer/_index.md
+++ /dev/null
@@ -1,146 +0,0 @@
-+++
-title = "Install Chef Infra Client RC3 with a native installer"
-linkTitle = "Native installer"
-
-[menu.install]
-title = "Install"
-identifier = "install/installer/install"
-parent = "install/installer"
-weight = 10
-+++
-
-The Chef Infra Client native installers provide an efficient way to install Chef Infra Client on Windows, Debian, or RPM-based Linux distributions.
-You can download and install the pre-built `.msi`, `.deb`, or `.rpm` packages using your existing package management tools, simplifying the deployment process for managing system configurations.
-
-## Supported platforms
-
-This installation method is supported on Linux and Windows x86-64 systems.
-
-## Prerequisites
-
-This installation process has the following prerequisites:
-
-- Chef Workstation isn't installed on the target system.
-- On Debian-based systems, the dpkg package manager is installed on the target system.
-- On RPM-based systems, the RPM and either the DNF or Yum package managers are installed on the target system.
-
- For Amazon Linux 2, use the RPM and Yum package managers.
-
-- You have a valid Progress Chef license key.
-- The target system is connected to the internet.
-
-## Install Chef Infra Client
-
-To install Chef Infra Client 19, follow these steps:
-
-1. Download the Chef Infra Client installer.
-
- {{< accordion-list data-allow-all-closed="true" >}}
-
- {{< accordion-item accordion-title="Download Debian-based installer" >}}
-
- For Debian-based distributions:
-
- - Using Wget:
-
- ```sh
- wget -O "chef-ice-19.2.rc3-linux.deb" "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/chef-ice/19.2.RC3/linux/x86_64/chef-ice-19.2.rc3-linux.deb?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=9tqCmX%2F576Nrf6bdiZgK%2FRQP7%2BE%3D&Expires=1780533327"
- ```
-
- - Using curl:
-
- ```sh
- curl -o "chef-ice-19.2.rc3-linux.deb" "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/chef-ice/19.2.RC3/linux/x86_64/chef-ice-19.2.rc3-linux.deb?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=9tqCmX%2F576Nrf6bdiZgK%2FRQP7%2BE%3D&Expires=1780533327"
- ```
-
- {{< /accordion-item >}}
- {{< accordion-item accordion-title="Download RPM-based installer" >}}
-
- For RPM-based distributions:
-
- - Using Wget:
-
- ```sh
- wget -O chef-ice-19.2.rc3-linux.rpm "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/chef-ice/19.2.RC3/linux/x86_64/chef-ice-19.2.rc3-linux.rpm?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=gODj1%2BnbpBZ2VYbb3CYjZvU1JXQ%3D&Expires=1780533345"
- ```
-
- - Using curl:
-
- ```sh
- curl -o chef-ice-19.2.rc3-linux.rpm "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/chef-ice/19.2.RC3/linux/x86_64/chef-ice-19.2.rc3-linux.rpm?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=gODj1%2BnbpBZ2VYbb3CYjZvU1JXQ%3D&Expires=1780533345"
- ```
-
- {{< /accordion-item >}}
- {{< accordion-item accordion-title="Download Windows installer" >}}
-
- For Windows:
-
- - Using curl:
-
- ```sh
- curl -o chef-ice-19.2.rc3-windows.msi "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/chef-ice/19.2.RC3/windows/x86_64/chef-ice-19.2.rc3-windows.msi?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=ugQFgpkB1TWtaN1mo4iRGGFtgeQ%3D&Expires=1780533357"
- ```
-
- - Using PowerShell:
-
- ```ps1
- Invoke-WebRequest -Uri "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/chef-ice/19.2.RC3/windows/x86_64/chef-ice-19.2.rc3-windows.msi?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=ugQFgpkB1TWtaN1mo4iRGGFtgeQ%3D&Expires=1780533357" -OutFile "chef-ice-19.2.rc3-windows.msi"
- ```
-
- {{< /accordion-item >}}
- {{< /accordion-list >}}
-
-1. Go to the directory with the installer and install the package.
-
- {{< accordion-list data-allow-all-closed="true" >}}
-
- {{< accordion-item accordion-title="Install on Debian-based distributions" >}}
-
- For Debian-based distributions:
-
- ```sh
- sudo -E dpkg -i chef-ice-19.2.rc3-linux.deb
- ```
-
- {{< /accordion-item >}}
- {{< accordion-item accordion-title="Install on RPM-based distributions" >}}
-
- For RPM-based distributions:
-
- ```sh
- sudo -E dnf install chef-ice-19.2.rc3-linux.rpm -y
- ```
-
- or:
-
- ```sh
- sudo -E rpm -ivh chef-ice-19.2.rc3-linux.rpm
- ```
-
- {{< /accordion-item >}}
- {{< accordion-item accordion-title="Install on Windows" >}}
-
- Install on Windows:
-
- - Double-click on the MSI package and install using Windows Package Manager.
-
- or:
-
- - Using Powershell:
-
- ```sh
- msiexec /i "chef-ice-19.2.rc3-windows.msi"
- ```
-
- {{< /accordion-item >}}
- {{< /accordion-list >}}
-
-1. Verify the installation:
-
- ```sh
- chef-client --version
- ```
-
-## Next steps
-
-After installing Chef Infra Client, you can test it by running an [example cookbook](/cookbooks).
diff --git a/content/install/installer/troubleshooting.md b/content/install/installer/troubleshooting.md
deleted file mode 100644
index 5f2a5f7..0000000
--- a/content/install/installer/troubleshooting.md
+++ /dev/null
@@ -1,131 +0,0 @@
-+++
-title = "Chef Infra Client native installer troubleshooting"
-
-[menu.install]
-title = "Troubleshooting"
-identifier = "install/installer/troubleshooting"
-parent = "install/installer"
-weight = 200
-+++
-
-## Conflicts with Chef Workstation
-
-If the Chef Workstation is already on your system, the installation process fails with a conflict.
-
-- On Debian-based systems, the installer returns the following error:
-
- ```sh
- Selecting previously unselected package chef-infra-client.
- dpkg: regarding chef-ice-19.2.rc3-linux.deb containing chef-infra-client:
- chef-infra-client conflicts with chef-workstation
- chef-workstation (version 0.4.2-1) is present and installed.
-
- dpkg: error processing archive chef-ice-19.2.rc3-linux.deb (--install):
- conflicting packages - not installing chef-infra-client
- Errors were encountered while processing:
- chef-ice-19.2.rc3-linux.deb
- ```
-
-- On RPM-based systems, the installer returns the following error:
-
- ```sh
- Error:
- Problem: package chef-ice-19.2.rc3-linux from @System conflicts with chef-workstation provided by chef-workstation-25.1.1074-1.amazon2023.x86_64 from @commandline
- - conflicting requests
- - problem with installed package chef-ice-19.2.rc3-linux
- (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)
- ```
-
-- On Windows, the Windows Package Manager displays the following error:
-
- ```plain
- Chef Workstation is installed. Please uninstall it before installing Chef Infra (air-gapped).
- ```
-
-To resolve the error:
-
-1. [Uninstall Chef Workstation](https://docs.chef.io/workstation/install_workstation/#uninstalling).
-1. [Reinstall Chef Infra Client](install).
-
-## Error: Invalid license
-
-The installation process requires a valid Progress Chef License key.
-
-The installer returns the following error if you don't add a valid license:
-
-```sh
-Validating chef-client license with https://services.chef.io
-Invalid License Key: ssfree-833b40cf-336a-42ee-b71d-f14a0
-chef-client installation failed. Error: invalid license
-warning: %post(chef-infra-client-19.1.0-1.amzn2.x86_64) scriptlet failed, exit status 1
-
-Error in POSTIN scriptlet in rpm package chef-infra-client
- Verifying : chef-infra-client-19.1.0-1.amzn2.x86_64
-```
-
-To resolve this error:
-
-1. Add a valid Progress Chef License key to your machine's environment:
-
- {{< accordion-list data-multi-expand="true" data-allow-all-closed="true" >}}
- {{< accordion-item accordion-title="Add license key on Linux" accordion-title-link="add-license-key-linux" >}}
-
- Add a Progress Chef license key on Linux:
-
- ```sh
- export CHEF_LICENSE_KEY=
- ```
-
- Replace `` with your Progress Chef license key.
-
- {{< /accordion-item >}}
- {{< accordion-item accordion-title="Add license key on Windows" accordion-title-link="add-license-key-windows" >}}
-
- Add a Progress Chef license key on Windows:
-
- ```ps1
- [System.Environment]::SetEnvironmentVariable("CHEF_LICENSE_KEY", "", "Machine")
- ```
-
- Replace `` with your Progress Chef license key.
-
- {{< /accordion-item >}}
- {{< /accordion-list >}}
-
-2. Install Chef Infra Client:
-
- {{< accordion-list data-multi-expand="false" data-allow-all-closed="true" id="install-infra-client" >}}
- {{< accordion-item accordion-title="Install on Debian distributions" accordion-title-link="install-infra-client-deb" >}}
-
- Install on Debian-based distributions:
-
- ```sh
- sudo -E dpkg -i chef-ice-19.2.rc3-linux.deb
- ```
-
- {{< /accordion-item >}}
- {{< accordion-item accordion-title="Install on RPM distributions" accordion-title-link="install-infra-client-rpm">}}
-
- Install on RPM-based distributions using the `dnf reinstall` command:
-
- ```sh
- sudo -E dnf reinstall chef-ice-19.2.rc3-linux.rpm
- ```
-
- {{< /accordion-item >}}
- {{< accordion-item accordion-title="Install on Windows" accordion-title-link="install-infra-client-windows">}}
-
- Install on Windows:
-
- - Double-click on the MSI package and install using the Windows Package Manager.
-
- or:
-
- - Install the MSI package with Powershell:
-
- ```sh
- msiexec /i "chef-ice-19.2.rc3-windows.msi"
- ```
-
- {{< /accordion-item >}}
- {{< /accordion-list >}}
diff --git a/content/install/migration_tool/_index.md b/content/install/migration_tool/_index.md
deleted file mode 100644
index f668e45..0000000
--- a/content/install/migration_tool/_index.md
+++ /dev/null
@@ -1,32 +0,0 @@
-+++
-title = "Install Chef Infra Client using the migration tool"
-linkTitle = "Migration tool"
-
-[menu.install]
-title = "Overview"
-parent = "install/migration_tool"
-weight = 10
-+++
-
-The Chef Infra Client migration tool (`chef-migrate`) allows you to install or upgrade Chef Infra Client to the latest version in both online and air-gapped environments.
-
-## Key functions
-
-- **Fresh installation:** Install Chef Infra Client 19 RC3
-- **Side-by-side installation:** Install Chef Infra Client 19 RC3 and remove or keep the previous Infra Client version. If you keep the previous version in side-by-side mode, the path to the most recent version takes precedence
-- **Omnibus upgrade:** Upgrade from Omnibus-based Chef Infra Client 17.x or 18.x versions
-- **Habitat upgrade:** Upgrade Habitat-packaged Chef Infra Client 19 RC releases
-
-## Supported platforms
-
-- Linux x86-64
-- Windows x86-64
-
-## Install guides
-
-To install or upgrade Chef Infra Client, see these guides:
-
-- [Install](install)
-- [Online upgrade](upgrade_online)
-- [Air-gapped upgrade](upgrade_airgap)
-- [`chef-migrate` CLI reference](reference)
diff --git a/content/install/migration_tool/install.md b/content/install/migration_tool/install.md
deleted file mode 100644
index d6062f4..0000000
--- a/content/install/migration_tool/install.md
+++ /dev/null
@@ -1,140 +0,0 @@
-+++
-title = "Install Chef Infra Client using the migration tool in an online environment"
-
-[menu.install]
-title = "Online install"
-identifier = "install/migration_tool/install_online"
-parent = "install/migration_tool"
-weight = 20
-+++
-
-This page documents how to install Chef Infra Client RC3 in an online environment.
-
-## Supported platforms
-
-Chef Infra Client 19 RC3 is supported on:
-
-- Linux x86-64
-- Windows x86-64
-
-## Prerequisites
-
-- a valid Chef License key
-
-## Install Chef Infra Client on Linux
-
-To install Chef Infra Client on Linux, follow these steps:
-
-1. Optional: Verify that Chef Infra Client isn't already installed on your system:
-
- ```sh
- chef-client --version
- ```
-
-1. Download the Chef Infra Client migration tool.
-
- The migration tool is available for download as a zipped tar file using a pre-signed URL from an S3 bucket until April 23, 2026.
-
- Using curl:
-
- ```sh
- curl -o migration-tools-1.1.rc3-linux.tar.gz "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/migrate-ice/1.1.RC3/linux/migration-tools-1.1.rc3-linux.tar.gz?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=O8rQUc0jy%2BeP7U1WspJasr7qMTY%3D&Expires=1780533385"
- ```
-
- Using Wget:
-
- ```sh
- wget -O "migration-tools-1.1.rc3-linux.tar.gz" "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/migrate-ice/1.1.RC3/linux/migration-tools-1.1.rc3-linux.tar.gz?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=O8rQUc0jy%2BeP7U1WspJasr7qMTY%3D&Expires=1780533385"
- ```
-
-1. Extract the migration tool and make it executable.
-
- ```sh
- tar -xvf migration-tools-1.1.rc3-linux.tar.gz -C /path/to/temp/folder
- cd /path/to/temp/folder
- chmod +x chef-migrate
- mv chef-migrate /usr/local/bin/
- ```
-
-1. Optional: Verify that the migration tool is installed.
-
- ```sh
- chef-migrate --help
- ```
-
- The migration tool returns available commands and usage guidelines.
-
-1. Install Chef Infra Client using [`chef-migrate apply`](reference):
-
- ```sh
- sudo chef-migrate apply online --fresh-install --download-url "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/chef-ice/19.2.RC3/linux/x86_64/chef-ice-19.2.rc3-linux.tar.gz?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=htVtnPFhoan9wyXixccqDFp0jmU%3D&Expires=1780533226" --license-key ""
- ```
-
- Replace `` with your Progress Chef License key.
-
-1. Verify the Chef Infra Client installation.
-
- ```sh
- chef-client --version
- ```
-
-## Install Chef Infra Client on Windows
-
-To install Chef Infra Client on Windows, follow these steps:
-
-1. Optional: Verify that Chef Infra Client isn't already installed on your system:
-
- ```powershell
- chef-client --version
- ```
-
-1. Download the Chef Infra Client migration tool.
-
- The migration tool is available for download as a ZIP file using a pre-signed address from an S3 bucket until April 23, 2026.
-
- Using curl:
-
- ```powershell
- curl -o migration-tools-1.1.rc3-windows.zip "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/migrate-ice/1.1.RC3/windows/migration-tools-1.1.rc3-windows.zip?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=xyfZ7g7D5jLF5jY%2B8DfBkEedSUA%3D&Expires=1780533399"
- ```
-
- Using PowerShell:
-
- ```powershell
- Invoke-WebRequest -Uri "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/migrate-ice/1.1.RC3/windows/migration-tools-1.1.rc3-windows.zip?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=xyfZ7g7D5jLF5jY%2B8DfBkEedSUA%3D&Expires=1780533399" -OutFile "migration-tools-1.1.rc3-windows.zip"
- ```
-
-1. Extract the migration tool.
-
- ```powershell
- mkdir C:\migrate-tool
- move "migration-tools-1.1.rc3-windows.zip" "C:\migrate-tool\"
- cd C:\migrate-tool
- Expand-Archive -Path "migration-tools-1.1.rc3-windows.zip" -DestinationPath "."
- ```
-
-1. Optional: Verify that the migration tool works.
-
- ```powershell
- .\chef-migrate --help
- ```
-
- The migration tool returns available commands and usage guidelines.
-
-1. Install Chef Infra Client using [`chef-migrate apply`](reference):
-
- ```powershell
- .\chef-migrate apply online --fresh-install --download-url "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/chef-ice/19.2.RC3/windows/x86_64/chef-ice-19.2.rc3-windows.tar.gz?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=2jIjDACxF0EYf8yICEp698kt0xY%3D&Expires=1780533373" --license-key ""
- ```
-
- Replace `` with your Progress Chef License key.
-
-1. Verify the Chef Infra Client installation.
-
- ```powershell
- chef-client --version
- ```
-
-## Next step
-
-- [Add a Chef license](/license)
diff --git a/content/install/migration_tool/install_airgap.md b/content/install/migration_tool/install_airgap.md
deleted file mode 100644
index 1937c0c..0000000
--- a/content/install/migration_tool/install_airgap.md
+++ /dev/null
@@ -1,89 +0,0 @@
-+++
-title = "Install Chef Infra Client using the migration tool in an air-gapped environment"
-draft = true
-
-[menu.install]
-title = "Air-gapped install"
-identifier = "install/migration_tool/install_airgap"
-parent = "install/migration_tool"
-weight = 20
-+++
-
-This page documents how to do a fresh install of Chef Infra Client RC3 in an air-gapped environment.
-
-## Supported platforms
-
-Chef Infra Client 19 RC3 is supported on Linux x86-64 systems.
-
-## Prerequisites
-
-- a valid Chef License key
-
-## Install Chef Infra Client
-
-To install Chef Infra Client, follow these steps:
-
-1. On an internet-connected machine, download the Chef Infra Client 19 RC3 tar file.
-
- Chef Infra Client is available in a zipped tar file using a pre-signed URL from an S3 bucket until April 23, 2026.
-
- Download using curl:
-
- ```sh
- curl -o chef-ice-19.2.rc3-linux.tar.gz "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/chef-ice/19.2.RC3/linux/x86_64/chef-ice-19.2.rc3-linux.tar.gz?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=htVtnPFhoan9wyXixccqDFp0jmU%3D&Expires=1780533226"
- ```
-
- Download using Wget:
-
- ```sh
- wget -O "chef-ice-19.2.rc3-linux.tar.gz" "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/chef-ice/19.2.RC3/linux/x86_64/chef-ice-19.2.rc3-linux.tar.gz?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=htVtnPFhoan9wyXixccqDFp0jmU%3D&Expires=1780533226"
- ```
-
-1. On an internet-connected machine, download the Chef Infra Client migration tool.
-
- The migration tool is available for download as a zipped tar file using a pre-signed URL from an S3 bucket until April 23, 2026.
-
- Using curl:
-
- ```sh
- curl -o migration-tools-1.1.rc3-linux.tar.gz "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/migrate-ice/1.1.RC3/linux/migration-tools-1.1.rc3-linux.tar.gz?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=O8rQUc0jy%2BeP7U1WspJasr7qMTY%3D&Expires=1780533385"
- ```
-
- Using Wget:
-
- ```sh
- wget -O "migration-tools-1.1.rc3-linux.tar.gz" "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/migrate-ice/1.1.RC3/linux/migration-tools-1.1.rc3-linux.tar.gz?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=O8rQUc0jy%2BeP7U1WspJasr7qMTY%3D&Expires=1780533385"
- ```
-
-1. Extract the migration tool and make it executable.
-
- ```sh
- tar -xvf migration-tools-1.1.rc3-linux.tar.gz -C /path/to/temp/folder
- cd /path/to/temp/folder
- chmod +x chef-migrate
- mv chef-migrate /usr/local/bin/
- ```
-
-1. Optional: Verify that the migration tool is installed.
-
- ```sh
- chef-migrate --help
- ```
-
- The migration tool returns available commands and usage guidelines.
-
-1. Install Chef Infra CLient using [`chef-migrate apply`](reference):
-
- ```sh
- sudo chef-migrate apply airgap --fresh-install --license-key ""
- ```
-
-1. Verify that Chef Infra Client is installed.
-
- ```sh
- chef-client --version
- ```
-
-## Next step
-
-- [Add a Chef license](/license)
diff --git a/content/install/migration_tool/reference.md b/content/install/migration_tool/reference.md
deleted file mode 100644
index 23830cb..0000000
--- a/content/install/migration_tool/reference.md
+++ /dev/null
@@ -1,195 +0,0 @@
-+++
-title = "Migration tool CLI reference"
-
-[menu.install]
-title = "CLI reference"
-identifier = "install/migration_tool/reference"
-parent = "install/migration_tool"
-weight = 999
-+++
-
-## Syntax
-
-The `chef-migrate apply` command upgrades or installs Chef Infra Client to version 19.
-
-This command has the following basic syntax:
-
-```sh
-chef-migrate apply {airgap|online} [flags]
-```
-
-It supports two subcommands:
-
-- `airgap`: Uses pre-downloaded air-gapped bundles to install or upgrade Chef Infra Client 19.
-- `online`: Uses network-connected resources to download and install Chef Infra Client 19.
-
-## Flags
-
-
-
-`--debug`
-: Enable debug logs. Logs are available in `/var/log/chef19migrate.log`. Valid values are: `true` or `false`.
-
-`--download-url `
-: Specify the Chef Infra Client download location.
-
-`--fresh-install`
-: Whether to perform a fresh installation. Valid values are: `true` or `false`.
-
- Default value: `false`.
-
-`--fstab --license-key ""
-```
-
-### Manage Omnibus-based Chef Infra Client
-
-Preserve an Omnibus-based Chef Infra Client installation:
-
-```sh
-chef-migrate apply {airgap|online} --license-key "" --preserve-omnibus
-```
-
-Log a warning if the `client.rb` config file references the Omnibus-based Chef Infra Client installation (`/opt/chef`):
-
-```sh
-chef-migrate apply {airgap|online} --license-key "" --process-config warn
-```
-
-Replace the existing Omnibus-based Chef binaries (for example, `ruby`, `chef-client`, and `openssl`) with symbolic links pointing to their Habitat-based equivalents.
-
-```sh
-chef-migrate apply {airgap|online} --license-key "" --preserve-omnibus --symlink
-```
-
-Remount Chef Infra Client from `/opt/chef` to `/hab`:
-
-```sh
-chef-migrate apply {airgap|online} --license-key "" --fstab apply
-```
-
-Abort the migration process if `/opt/chef` is already mounted:
-
-```sh
-chef-migrate apply {airgap|online} --license-key "" --fstab fail
-```
-
-### Manage Chef Habitat
-
-Upgrade Chef Habitat while installing Chef Infra Client:
-
-```sh
-chef-migrate apply {airgap|online} --license-key "" --habitat-upgrade
-```
-
-### SELinux profiles
-
-Install the default SELinux profile:
-
-```sh
-chef-migrate apply {airgap|online} --license-key "" --selinux-profile default --selinux-ignore-warnings
-```
-
-Install a custom SELinux profile:
-
-```sh
-chef-migrate apply {airgap|online} --license-key "" --selinux-profile
-```
diff --git a/content/install/migration_tool/upgrade_airgap.md b/content/install/migration_tool/upgrade_airgap.md
deleted file mode 100644
index 43f6969..0000000
--- a/content/install/migration_tool/upgrade_airgap.md
+++ /dev/null
@@ -1,164 +0,0 @@
-+++
-title = "Upgrade Chef Infra Client to version 19 RC3 using the migration tool in an air-gapped environment"
-
-[menu.install]
-title = "Air-gapped upgrade"
-identifier = "install/migration_tool/upgrade_airgap"
-parent = "install/migration_tool"
-weight = 20
-+++
-
-This page documents how to upgrade Chef Infra Client to version 19 RC3 in an air-gapped environment.
-
-## Supported platforms
-
-Chef Infra Client 19 RC3 is supported on:
-
-- Linux x86-64
-- Windows x86-64
-
-## Prerequisites
-
-- a valid Chef License key
-
-## Upgrade to Chef Infra Client 19 RC3 on Linux
-
-To upgrade Chef Infra Client, follow these steps:
-
-1. On an internet-connected machine, download the Chef Infra Client 19 RC3 tar file.
-
- Chef Infra Client is available in a zipped tar file using a pre-signed URL from an S3 bucket until April 23, 2026.
-
- Download using curl:
-
- ```sh
- curl -o chef-ice-19.2.rc3-linux.tar.gz "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/chef-ice/19.2.RC3/linux/x86_64/chef-ice-19.2.rc3-linux.tar.gz?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=htVtnPFhoan9wyXixccqDFp0jmU%3D&Expires=1780533226"
- ```
-
- Download using Wget:
-
- ```sh
- wget -O "chef-ice-19.2.rc3-linux.tar.gz" "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/chef-ice/19.2.RC3/linux/x86_64/chef-ice-19.2.rc3-linux.tar.gz?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=htVtnPFhoan9wyXixccqDFp0jmU%3D&Expires=1780533226"
- ```
-
-1. On an internet-connected machine, download the Chef Infra Client migration tool.
-
- The migration tool is available for download as a zipped tar file using a pre-signed URL from an S3 bucket until April 23, 2026.
-
- Using curl:
-
- ```sh
- curl -o migration-tools-1.1.rc3-linux.tar.gz "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/migrate-ice/1.1.RC3/linux/migration-tools-1.1.rc3-linux.tar.gz?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=O8rQUc0jy%2BeP7U1WspJasr7qMTY%3D&Expires=1780533385"
- ```
-
- Using Wget:
-
- ```sh
- wget -O "migration-tools-1.1.rc3-linux.tar.gz" "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/migrate-ice/1.1.RC3/linux/migration-tools-1.1.rc3-linux.tar.gz?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=O8rQUc0jy%2BeP7U1WspJasr7qMTY%3D&Expires=1780533385"
- ```
-
-1. Extract the migration tool and make it executable.
-
- ```sh
- tar -xvf migration-tools-1.1.rc3-linux.tar.gz -C /path/to/temp/folder
- cd /path/to/temp/folder
- chmod +x chef-migrate
- mv chef-migrate /usr/local/bin/
- ```
-
-1. Optional: Verify that the migration tool is installed.
-
- ```sh
- chef-migrate --help
- ```
-
- The migration tool returns available commands and usage guidelines.
-
-1. Install Chef Infra Client by specifying the path to the tar file using [`chef-migrate apply`](reference).
-
- ```sh
- sudo chef-migrate apply airgap --license-key ""
- ```
-
- Replace:
-
- - `` with the path to the Chef Infra Client tar file.
- - `` with your Progress Chef License key.
-
-1. Verify that Chef Infra Client is installed.
-
- ```sh
- chef-client --version
- ```
-
-## Upgrade to Chef Infra Client 19 RC3 on Windows
-
-To upgrade Chef Infra Client, follow these steps:
-
-1. On an internet-connected machine, download the Chef Infra Client 19 RC3 tar file.
-
- Chef Infra Client is available in a tar file using a pre-signed address from an S3 bucket until April 23, 2026.
-
- Download using curl:
-
- ```powershell
- curl -o chef-ice-19.2.rc3-windows.tar.gz "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/chef-ice/19.2.RC3/windows/x86_64/chef-ice-19.2.rc3-windows.tar.gz?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=2jIjDACxF0EYf8yICEp698kt0xY%3D&Expires=1780533373"
- ```
-
- Download using PowerShell:
-
- ```powershell
- Invoke-WebRequest -Uri "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/chef-ice/19.2.RC3/windows/x86_64/chef-ice-19.2.rc3-windows.tar.gz?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=2jIjDACxF0EYf8yICEp698kt0xY%3D&Expires=1780533373" -OutFile "chef-ice-19.2.rc3-windows.tar.gz"
- ```
-
-1. On an internet-connected machine, download the Chef Infra Client migration tool.
-
- The migration tool is available for download as a ZIP file using a pre-signed address from an S3 bucket until April 23, 2026.
-
- Using curl:
-
- ```powershell
- curl -o migration-tools-1.1.rc3-windows.zip "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/migrate-ice/1.1.RC3/windows/migration-tools-1.1.rc3-windows.zip?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=xyfZ7g7D5jLF5jY%2B8DfBkEedSUA%3D&Expires=1780533399"
- ```
-
- Using PowerShell:
-
- ```powershell
- Invoke-WebRequest -Uri "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/migrate-ice/1.1.RC3/windows/migration-tools-1.1.rc3-windows.zip?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=xyfZ7g7D5jLF5jY%2B8DfBkEedSUA%3D&Expires=1780533399" -OutFile "migration-tools-1.1.rc3-windows.zip"
- ```
-
-1. Extract the migration tool.
-
- ```powershell
- mkdir C:\migrate-tool
- move "migration-tools-1.1.rc3-windows.zip" "C:\migrate-tool\"
- move "chef-ice-19.2.rc3-windows.tar.gz" "C:\migrate-tool\"
- cd C:\migrate-tool
- Expand-Archive -Path "migration-tools-1.1.rc3-windows.zip" -DestinationPath "."
- ```
-
-1. Optional: Verify that the migration tool works.
-
- ```powershell
- .\chef-migrate --help
- ```
-
- The migration tool returns available commands and usage guidelines.
-
-1. Upgrade Chef Infra Client by specifying the path to the tar file using [`chef-migrate apply`](reference).
-
- ```powershell
- .\chef-migrate apply airgap "C:\migrate-tool\chef-ice-19.2.rc3-windows.tar.gz" --license-key ""
- ```
-
- Replace `` with your Progress Chef License key.
-
-1. Verify the Chef Infra Client upgrade.
-
- ```powershell
- chef-client --version
- ```
-
-## Next step
-
-- [Add a Chef license](/license)
diff --git a/content/install/migration_tool/upgrade_online.md b/content/install/migration_tool/upgrade_online.md
deleted file mode 100644
index 51c5751..0000000
--- a/content/install/migration_tool/upgrade_online.md
+++ /dev/null
@@ -1,128 +0,0 @@
-+++
-title = "Upgrade Chef Infra Client to version 19 RC3 using the migration tool in an online environment"
-
-[menu.install]
-title = "Online upgrade"
-identifier = "install/migration_tool/upgrade_online"
-parent = "install/migration_tool"
-weight = 20
-+++
-
-This page documents how to upgrade Chef Infra Client to version 19 RC3 in an online environment.
-
-## Supported platforms
-
-Chef Infra Client 19 RC3 is supported on:
-
-- Linux x86-64
-- Windows x86-64
-
-## Prerequisites
-
-- a valid Chef License key
-
-## Upgrade Chef Infra Client 19 RC3 on Linux
-
-To upgrade Chef Infra Client, follow these steps:
-
-1. Download the Chef Infra Client migration tool.
-
- The migration tool is available for download as a zipped tar file using a pre-signed URL from an S3 bucket until April 23, 2026.
-
- Using curl:
-
- ```sh
- curl -o migration-tools-1.1.rc3-linux.tar.gz "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/migrate-ice/1.1.RC3/linux/migration-tools-1.1.rc3-linux.tar.gz?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=O8rQUc0jy%2BeP7U1WspJasr7qMTY%3D&Expires=1780533385"
- ```
-
- Using Wget:
-
- ```sh
- wget -O "migration-tools-1.1.rc3-linux.tar.gz" "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/migrate-ice/1.1.RC3/linux/migration-tools-1.1.rc3-linux.tar.gz?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=O8rQUc0jy%2BeP7U1WspJasr7qMTY%3D&Expires=1780533385"
- ```
-
-1. Extract the migration tool and make it executable.
-
- ```sh
- tar -xvf migration-tools-1.1.rc3-linux.tar.gz -C /path/to/temp/folder
- cd /path/to/temp/folder
- chmod +x chef-migrate
- mv chef-migrate /usr/local/bin/
- ```
-
-1. Optional: Verify that the migration tool is installed.
-
- ```sh
- chef-migrate --help
- ```
-
- The migration tool returns available commands and usage guidelines.
-
-1. Install Chef Infra Client using [`chef-migrate apply`](reference).
-
- ```sh
- sudo chef-migrate apply online --download-url "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/chef-ice/19.2.RC3/linux/x86_64/chef-ice-19.2.rc3-linux.tar.gz?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=htVtnPFhoan9wyXixccqDFp0jmU%3D&Expires=1780533226" --license-key ""
- ```
-
- Replace `` with your Progress Chef License key.
-
-1. Verify that Chef Infra Client is installed.
-
- ```sh
- chef-client --version
- ```
-
-## Upgrade Chef Infra Client 19 RC3 on Windows
-
-To upgrade Chef Infra Client, follow these steps:
-
-1. Download the Chef Infra Client migration tool.
-
- The migration tool is available for download as a ZIP file using a pre-signed address from an S3 bucket until April 23, 2026.
-
- Using curl:
-
- ```powershell
- curl -o migration-tools-1.1.rc3-windows.zip "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/migrate-ice/1.1.RC3/windows/migration-tools-1.1.rc3-windows.zip?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=xyfZ7g7D5jLF5jY%2B8DfBkEedSUA%3D&Expires=1780533399"
- ```
-
- Using PowerShell:
-
- ```powershell
- Invoke-WebRequest -Uri "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/migrate-ice/1.1.RC3/windows/migration-tools-1.1.rc3-windows.zip?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=xyfZ7g7D5jLF5jY%2B8DfBkEedSUA%3D&Expires=1780533399" -OutFile "migration-tools-1.1.rc3-windows.zip"
- ```
-
-1. Extract the migration tool.
-
- ```powershell
- mkdir C:\migrate-tool
- move "migration-tools-1.1.rc3-windows.zip" "C:\migrate-tool\"
- cd C:\migrate-tool
- Expand-Archive -Path "migration-tools-1.1.rc3-windows.zip" -DestinationPath "."
- ```
-
-1. Optional: Verify that the migration tool works.
-
- ```powershell
- .\chef-migrate --help
- ```
-
- The migration tool returns available commands and usage guidelines.
-
-1. Upgrade Chef Infra Client using [`chef-migrate apply`](reference).
-
- ```powershell
- .\chef-migrate apply online --download-url "https://chef-hab-migration-tool-bucket.s3.amazonaws.com/Release-Candidate-3/chef-ice/19.2.RC3/windows/x86_64/chef-ice-19.2.rc3-windows.tar.gz?AWSAccessKeyId=AKIAW4FPVFT6PA6EXTHQ&Signature=2jIjDACxF0EYf8yICEp698kt0xY%3D&Expires=1780533373" --license-key ""
- ```
-
- Replace `` with your Progress Chef License key.
-
-1. Verify the Chef Infra Client upgrade.
-
- ```powershell
- chef-client --version
- ```
-
-## Next step
-
-- [Add a Chef license](/license)
diff --git a/content/install_bootstrap.md b/content/install_bootstrap.md
new file mode 100644
index 0000000..aabdae6
--- /dev/null
+++ b/content/install_bootstrap.md
@@ -0,0 +1,460 @@
++++
+title = "Bootstrap a node"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/install_bootstrap.html"]
+product = ["client", "workstation"]
+
+[menu]
+ [menu.infra]
+ title = "Install using Bootstrap"
+ identifier = "chef_infra/install/install_bootstrap.md Install using Bootstrap"
+ parent = "chef_infra/install"
+ weight = 10
++++
+
+{{< readfile file="content/reusable/md/chef_client_bootstrap_node.md" >}}
+
+{{< readfile file="content/reusable/md/chef_client_bootstrap_stages.md" >}}
+
+## knife bootstrap
+
+{{< readfile file="content/reusable/md/install_chef_client.md" >}}
+
+### Run the bootstrap command
+
+The `knife bootstrap` command runs a bootstrap operation that installs Chef Infra Client on a target node. The following steps describe how to bootstrap a node using knife.
+
+1. Identify the FQDN or IP address of the target node. The `knife bootstrap` command requires the FQDN or the IP address for the node to complete the bootstrap operation.
+
+2. Once the workstation machine is configured, it can be used to install Chef Infra Client on one (or more) nodes across the organization using a knife bootstrap operation. The `knife bootstrap` command is used to SSH into the target machine, and then do what's needed to allow Chef Infra Client to run on the node. It will install the Chef Infra Client executable (if necessary), generate keys, and register the node with the Chef Infra Server. The bootstrap operation requires the IP address or FQDN of the target system, the SSH credentials (username, password or identity file) for an account that has root access to the node, and (if the operating system isn't Ubuntu, which is the default distribution used by `knife bootstrap`) the operating system running on the target system.
+
+ In a command window, enter the following:
+
+ ```bash
+ knife bootstrap -U --sudo
+ ```
+
+ Replace:
+
+ - `` the IP address or the FQDN of the node
+ - `` with the username used to connect to the node
+
+ The `--sudo` option elevates privileges using the sudo command on UNIX-based systems.
+
+ While the bootstrap operation is running, the command window returns something similar to the following:
+
+ ```bash
+ Enter password for ubuntu@172.16.1.233:
+
+ Connecting to 172.16.1.233
+ Performing legacy client registration with the validation key at /Users/USERNAME/.chef/validator.pem...
+ Delete your validation key to use your user credentials for client registration instead.
+ Bootstrapping 172.16.1.233
+ [172.16.1.233] -----> Installing Chef Omnibus (stable/16)
+ downloading https://omnitruck.chef.io/chef/install.sh
+ [172.16.1.233] to file /tmp/install.sh.1624/install.sh
+ [172.16.1.233] trying wget...
+ [172.16.1.233] ubuntu 20.04 aarch64
+ [172.16.1.233] Getting information for chef stable 16 for ubuntu...
+ [172.16.1.233] downloading https://omnitruck.chef.io/stable/chef/metadata?v=16&p=ubuntu&pv=20.04&m=aarch64
+ to file /tmp/install.sh.1628/metadata.txt
+ [172.16.1.233] trying wget...
+ [172.16.1.233] sha1 8d89f8ac2e7f52d170be8ec1c2a028a6449d7e3a
+ sha256 85cc73bed06e8d6699fc5c0b26c20d2837bf03831873444febccfc8bfa561f00
+ url https://packages.chef.io/files/stable/chef/16.1.16/ubuntu/20.04/chef_16.1.16-1_arm64.deb
+ version 16.1.16
+ [172.16.1.233]
+ [172.16.1.233] downloaded metadata file looks valid...
+ [172.16.1.233] downloading https://packages.chef.io/files/stable/chef/16.1.16/ubuntu/20.04/chef_16.1.16-1_arm64.deb
+ to file /tmp/install.sh.1628/chef_16.1.16-1_arm64.deb
+ [172.16.1.233] trying wget...
+ [172.16.1.233] Comparing checksum with sha256sum...
+ [172.16.1.233] Installing chef 16
+ installing with dpkg...
+ [172.16.1.233] Selecting previously unselected package chef.
+ [172.16.1.233] (Reading database ... 99114 files and directories currently installed.)
+ [172.16.1.233] Preparing to unpack .../chef_16.1.16-1_arm64.deb ...
+ [172.16.1.233] Unpacking chef (16.1.16-1) ...
+ [172.16.1.233] Setting up chef (16.1.16-1) ...
+ [172.16.1.233] Thank you for installing Chef Infra Client! For help getting started visit https://learn.chef.io
+ [172.16.1.233] Starting the first Chef Infra Client Client run...
+ [172.16.1.233] +---------------------------------------------+
+ ✓ 2 product licenses accepted.
+ +---------------------------------------------+
+ [172.16.1.233] Starting Chef Infra Client, version 16.1.16
+ [172.16.1.233] [2020-06-08T23:49:10+00:00] ERROR: shard_seed: Failed to get dmi property serial_number: is dmidecode installed?
+ [172.16.1.233] Creating a new client identity for name_of_node using the validator key.
+ [172.16.1.233] resolving cookbooks for run list: []
+ [172.16.1.233] Synchronizing Cookbooks:
+ [172.16.1.233] Installing Cookbook Gems:
+ [172.16.1.233] Compiling Cookbooks...
+ [172.16.1.233] [2020-06-08T23:49:17+00:00] WARN: Node name_of_node has an empty run list.
+ [172.16.1.233] Converging 0 resources
+ [172.16.1.233]
+ [172.16.1.233] Running handlers:
+ [172.16.1.233] Running handlers complete
+ [172.16.1.233] Chef Infra Client finished, 0/0 resources updated in 11 seconds
+ ```
+
+3. After the bootstrap operation has finished, verify that the node is recognized by the Chef Infra Server. To show only the node that was just bootstrapped, run the following command:
+
+ ```bash
+ knife client show NAME_OF_NODE
+ ```
+
+ where `NODE_NAME` is the name of the node that was just bootstrapped. The Chef Infra Server will return something similar to:
+
+ ```bash
+ admin: false
+ chef_type: client
+ name: NODE_NAME
+ validator: false
+ ```
+
+ and to show the full list of nodes (and workstations) that are registered with the Chef Infra Server, run the following command:
+
+ ```bash
+ knife client list
+ ```
+
+ The Chef Infra Server will return something similar to:
+
+ ```bash
+ workstation1
+ workstation2
+ ...
+ client1
+ client2
+ ```
+
+## Validatorless and legacy validator bootstraps
+
+We recommended using "validatorless bootstrapping" to authenticate new nodes with the Chef Infra Server.
+
+The legacy Chef Infra validator-based node bootstrapping process depended on using a shared "validatory" key throughout an organization for authenticating new nodes with the Chef Infra Server.
+
+Shortcomings of the legacy validator process are:
+
+- All users share the same key for bootstrapping new systems
+- Key sharing makes key rotation difficult, if it's compromised or if an employee leaves the organization.
+
+The "validatorless bootstrap" generates a key for each node, which is then transferred to the new node and used to authenticate with the Chef Infra Server instead of relying on a shared "validator" key.
+
+The Chef Infra bootstrap process is validatorless by default. If you receive a warning during a bootstrap that a validator key is in use, remove the configuration for this legacy bootstrap mode. Edit your [config.rb (knife.rb)](/workstation/config_rb/) file and remove any `validation_key` or `validation_client_name` entries.
+
+## Bootstrapping with chef-vault
+
+Use the following options with a validatorless bootstrap to specify items that are stored in chef-vault:
+
+`--bootstrap-vault-file VAULT_FILE`
+
+: The path to a JSON file that contains a list of vaults and items to be updated.
+
+`--bootstrap-vault-item VAULT_ITEM`
+
+: A single vault and item to update as `vault:item`.
+
+`--bootstrap-vault-json VAULT_JSON`
+
+: A JSON string that contains a list of vaults and items to be updated. `--bootstrap-vault-json '{ "vault1": \["item1", "item2"\], "vault2": "item2" }'`
+
+## Examples
+
+The `--bootstrap-vault-*` options add the client identify of the bootstrapping node to the permissions list of the specified vault item. This enables the newly-bootstrapped Chef Infra Client to be able to read items from the vault. Only a single client is authorized at a time for access to the vault. (The `-S` search query option with the `knife vault create` subcommand does the same.)
+
+### Recreate a data bag item
+
+The following example shows how to recreate a data bag item:
+
+```bash
+knife vault delete sea power
+Do you really want to delete sea/power? (Y/N) Y
+Deleted chef_vault_item[sea/power]
+
+echo "{\"some\":\"content for them\"}" > sea-power-content.json
+
+cat sea-power-content.json
+{"some":"content for them"}
+
+knife vault create sea power -M client -A sean_horn,angle -J sea-power-content.json
+```
+
+No clients, because the `-S` option wasn't specified while creating the vault.
+
+At this time, only the users `sean_horn` and `angle` are authorized to read and manage the vault.
+
+```bash
+knife vault show sea power --mode client -p all
+admins:
+ sean_horn
+ angle
+clients:
+id: power
+search_query:
+some: content for them
+```
+
+It's definitely an encrypted databag, see?
+
+```bash
+knife data_bag show sea power
+WARNING: Encrypted data bag detected, but no secret provided for decoding. Displaying encrypted data.
+id: power
+some:
+cipher: aes-256-cbc
+encrypted_data: c7Axnyg+1KDxBPOZdYN9QuIYx6dmSmK70unAQbn12Lygvsv2g9DPJJbueXVh
++yxL
+iv: ONoVR7OjPZiAzaqOZ30bjg==
+version: 1
+```
+
+### Use --bootstrap-vault-file
+
+Use the `sea:power` recreation step above first, to follow the difference in the vault permissions.
+
+```bash
+echo "{\"sea\":\"power\"}" > sea-power-bootstrap-vault-file.json
+
+knife bootstrap localhost -p 2200 -N ubuntu-20.04 -r 'role[group1]' --connection-user vagrant --sudo --bootstrap-vault-file sea-power-bootstrap-vault-file.json
+Node ubuntu-20.04 exists, overwrite it? (Y/N) Y
+Client ubuntu-20.04 exists, overwrite it? (Y/N) Y
+Creating new client for ubuntu-20.04
+Creating new node for ubuntu-20.04
+Connecting to localhost
+localhost -----> Existing Chef installation detected
+localhost Starting first Chef Infra Client run...
+localhost Starting Chef Infra Client, version 12.2.1
+localhost resolving cookbooks for run list: ["delay-test-reporting"]
+localhost Synchronizing Cookbooks:
+localhost - delay-test-reporting
+localhost Compiling Cookbooks...
+localhost Converging 1 resources
+localhost Recipe: delay-test-reporting::default
+localhost * execute[sleep 30] action run
+localhost - execute sleep 30
+localhost
+localhost Running handlers:
+localhost Running handlers complete
+localhost Chef Infra Client finished, 1/1 resources updated in 34.307257232 seconds
+```
+
+The client `ubuntu-20.04` was added to the `chef-vault` during the bootstrap.
+
+```bash
+knife vault show sea power --mode client -p all
+admins:
+ sean_horn
+ angle
+clients: ubuntu-20.04
+id: power
+search_query:
+some: content for them
+```
+
+### Use --bootstrap-vault-item
+
+Use the `sea:power` re-creation step above first, to follow the difference in the vault permissions.
+
+```bash
+knife bootstrap localhost -p 2200 -N ubuntu-20.04 -r 'role[group1]' --connection-user vagrant --sudo --bootstrap-vault-item sea:power
+Node ubuntu-20.04 exists, overwrite it? (Y/N) Y
+Client ubuntu-20.04 exists, overwrite it? (Y/N) Y
+Creating new client for ubuntu-20.04
+Creating new node for ubuntu-20.04
+Connecting to localhost
+localhost -----> Existing Chef installation detected
+localhost Starting first Chef Infra Client run...
+localhost Starting Chef Infra Client, version 12.2.1
+localhost resolving cookbooks for run list: ["delay-test-reporting"]
+localhost Synchronizing Cookbooks:
+localhost - delay-test-reporting
+localhost Compiling Cookbooks...
+localhost Converging 1 resources
+localhost Recipe: delay-test-reporting::default
+localhost * execute[sleep 30] action run
+localhost - execute sleep 30
+localhost
+localhost Running handlers:
+localhost Running handlers complete
+localhost Chef Infra Client finished, 1/1 resources updated in 34.322229474
+seconds
+```
+
+During the above run, the `sea:power` vault item was updated with the `ubuntu-20.04` client during the validatorless bootstrap. Previously, it only had the two admins authorized to view the content
+
+```bash
+knife vault show sea power -p all
+admins:
+ sean_horn
+ angle
+clients: ubuntu-20.04
+id: power
+search_query: role:stuff
+some: secret stuff for them
+```
+
+Then, let's check the `ubuntu-20.04` client. The client itself can decrypt and read the encrypted databag contents as well using the embedded knife CLI in the Chef Infra Client package.
+
+```bash
+sudo /opt/chef/bin/knife vault show sea power -c /etc/chef/client.rb -M client -p all
+admins:
+ sean_horn
+ angle
+clients: ubuntu-20.04
+id: power
+search_query: role:group1
+some: secret stuff for them
+```
+
+Success! The client is authorized to view the content of the `sea:power` databag item
+
+### Use --bootstrap-vault-json
+
+Use the `sea:power` re-creation step above first, to follow the difference in the vault permissions.
+
+```bash
+knife bootstrap localhost -p 2200 -N ubuntu-20.04 -r 'role[group1]' --connection-user vagrant --sudo --bootstrap-vault-json '{"sea": "power"}'
+Node ubuntu-20.04 exists, overwrite it? (Y/N) Y
+Client ubuntu-20.04 exists, overwrite it? (Y/N) Y
+Creating new client for ubuntu-.04
+Creating new node for ubuntu-20.04
+Connecting to localhost
+localhost -----> Existing Chef installation detected
+localhost Starting first Chef Infra Client run...
+localhost Starting Chef Infra Client, version 12.2.1
+localhost resolving cookbooks for run list: ["delay-test-reporting"]
+localhost Synchronizing Cookbooks:
+localhost - delay-test-reporting
+localhost Compiling Cookbooks...
+localhost Converging 1 resources
+localhost Recipe: delay-test-reporting::default
+
+localhost * execute[sleep 30] action run
+localhost - execute sleep 30
+localhost
+localhost Running handlers:
+localhost Running handlers complete
+localhost Chef Infra Client finished, 1/1 resources updated in 33.732784033 seconds
+```
+
+```bash
+knife vault show sea power -M client -p all
+admins:
+ sean_horn
+ angle
+clients: ubuntu-20.04
+id: power
+search_query:
+some: content for them
+```
+
+## Unattended installs
+
+Chef Infra Client can be installed using an unattended bootstrap. This allows Chef Infra Client to be installed from itself, without requiring SSH. For example, machines are often created using environments like AWS Auto Scaling, AWS CloudFormation, Rackspace Auto Scale, and PXE. In this scenario, using tooling for attended, single-machine installs like `knife bootstrap` or `knife CLOUD_PLUGIN create` isn't practical because the machines are created automatically and someone can't always be on-hand to initiate the bootstrap process.
+
+When Chef Infra Client is installed using an unattended bootstrap, remember that Chef Infra Client:
+
+- Must be able to authenticate to the Chef Infra Server.
+- Must be able to configure a run-list.
+- May require custom attributes, depending on the cookbooks that are being used.
+- Must be able to access the `chef-validator.pem` file so that it may create a new identity on the Chef Infra Server.
+- Must have a unique node name; Chef Infra Client will use the FQDN for the host system by default.
+
+When Chef Infra Client is installed using an unattended bootstrap, it may be built into an image that starts Chef Infra Client on boot, or installed using User Data or some other kind of post-deployment script. The type of image or User Data used depends on the platform on which the unattended bootstrap will take place.
+
+### Bootstrapping with user data
+
+The method used to inject a user data script into a server varies depending on the infrastructure platform being used.
+For example, on AWS you can pass this data in as a text file using the command line.
+
+The following user data examples demonstrate the process of bootstrapping Windows and Linux nodes.
+
+#### PowerShell user data
+
+```powershell
+## Set host file so the instance knows where to find chef-server
+$hosts = "1.2.3.4 hello.example.com"
+$file = "C:\Windows\System32\drivers\etc\hosts"
+$hosts | Add-Content $file
+
+## Download Chef Infra Client
+$clientURL = "https://chefdownload-commercial.chef.io/stable/client/download?p=windows>&pv=&m=&v=&license_id="
+$clientDestination = "C:\chef-client.msi"
+Invoke-WebRequest $clientURL -OutFile $clientDestination
+
+## Install the Chef Infra Client
+Start-Process msiexec.exe -ArgumentList @('/qn', '/lv C:\Windows\Temp\chef-log.txt', '/i C:\chef-client.msi', 'ADDLOCAL="ChefClientFeature,ChefSchTaskFeature,ChefPSModuleFeature"') -Wait
+
+## Create first-boot.json
+$firstboot = @{
+ "run_list" = @("role[base]")
+}
+Set-Content -Path c:\chef\first-boot.json -Value ($firstboot | ConvertTo-Json -Depth 10)
+
+## Create client.rb
+$nodeName = "lab-win-{0}" -f (-join ((65..90) + (97..122) | Get-Random -Count 4 | % {[char]$_}))
+
+$clientrb = @"
+chef_server_url 'https://chef-server/organizations/my-org'
+validation_client_name 'validator'
+validation_key 'C:\chef\validator.pem'
+node_name '{0}'
+"@ -f $nodeName
+
+Set-Content -Path c:\chef\client.rb -Value $clientrb
+
+## Run Chef
+C:\opscode\chef\bin\chef-client.bat -j C:\chef\first-boot.json
+```
+
+#### Bash user data
+
+```bash
+#!/bin/bash -xev
+
+# Do some chef pre-work
+/bin/mkdir -p /etc/chef
+/bin/mkdir -p /var/lib/chef
+/bin/mkdir -p /var/log/chef
+
+# Setup hosts file correctly
+cat >> "/etc/hosts" << EOF
+10.0.0.5 compliance-server compliance-server.automate.com
+10.0.0.6 infra-server infra-server.automate.com
+10.0.0.7 automate-server automate-server.automate.com
+EOF
+
+cd /etc/chef/
+
+# Install chef
+curl -L https://omnitruck.chef.io/install.sh | bash || error_exit "couldn't install chef"
+
+# Create first-boot.json
+cat > "/etc/chef/first-boot.json" << EOF
+{
+ "run_list" :[
+ "role[base]"
+ ]
+}
+EOF
+
+NODE_NAME=node-$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 4 | head -n 1)
+
+# Create client.rb
+cat > '/etc/chef/client.rb' << EOF
+log_location STDOUT
+chef_server_url 'https://aut-chef-server/organizations/my-org'
+validation_client_name 'my-org-validator'
+validation_key '/etc/chef/my_org_validator.pem'
+node_name "${NODE_NAME}"
+EOF
+
+chef-client -j /etc/chef/first-boot.json
+```
+
+It's important that settings in the [client.rb file](/config_rb_client/)---for example `chef_server_url` and `http_proxy`---are used to ensure that configuration details are built into the unattended bootstrap process.
+
+##### Setting the initial run-list
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_client_bootstrap_initial_run_list.md" >}}
diff --git a/content/install_chef_air_gap.md b/content/install_chef_air_gap.md
new file mode 100644
index 0000000..9352424
--- /dev/null
+++ b/content/install_chef_air_gap.md
@@ -0,0 +1,500 @@
++++
+title = "Install Chef in an air-gapped environment"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/install_chef_air_gap.html"]
+product = ["client", "server", "workstation"]
+
+[menu]
+ [menu.infra]
+ title = "Air-gapped Installation"
+ identifier = "chef_infra/install/install_chef_air_gap.md Air-gapped Installation"
+ parent = "chef_infra/install"
+ weight = 40
++++
+
+This guide will show you how to run a fully functional Chef environment
+within an [air-gapped](https://en.wikipedia.org/wiki/Air_gap_(networking))
+network.
+
+## Prerequisites
+
+Since a variety of different practices are used to create an air-gapped network, this guide focuses solely on the implementation of Chef software - as such, it makes the following assumptions:
+
+
+- You have a way to get packages to your air-gapped machines
+- Machines on your air-gapped network are able to resolve each other using DNS
+- A server's Fully Qualified Domain Name (FQDN) is the name that will be used by other servers to access it
+- You have a private Ruby gem mirror to supply gems as needed
+- You have an artifact store for file downloads. At a minimum, it should have the following packages available:
+
+ - Chef Workstation
+ - Chef Infra Client
+ - Chef Supermarket
+ - An [install script](/install_chef_air_gap/#create-an-install-script) for Chef Infra Client
+
+
+### Required cookbooks
+
+This guide will link to the required cookbooks for each piece of software in that software's respective section, but this is a full list of the cookbooks required to complete the entire guide:
+
+For Chef Supermarket:
+
+- [supermarket-omnibus-cookbook](https://supermarket.chef.io/cookbooks/supermarket-omnibus-cookbook)
+- [chef-ingredient](https://supermarket.chef.io/cookbooks/chef-ingredient)
+- [hostsfile](https://supermarket.chef.io/cookbooks/hostsfile)
+
+### Required gems
+
+The following Ruby gems are required to install private Supermarket using the supermarket-omnibus-cookbook:
+
+- mixlib-install
+- mixlib-shellout
+- mixlib-versioning
+- artifactory
+
+These should be accessible from your Gem mirror.
+
+### Create an install script
+
+An install script is used to install Chef Infra Client when bootstrapping a new node. It simply pulls the Chef Infra Client package from your artifact store, and then installs it. For example, on Debian-based Linux systems, it would look similar to this:
+
+```bash
+#!/bin/bash
+
+cd /tmp/
+wget http://packages.example.com/chef_13.2.20-1_amd64.deb
+dpkg -i chef_13.2.20-1_amd64.deb
+```
+
+The install script should be accessible from your artifact store.
+
+## Chef Infra Server
+
+In this section you'll install the Chef Infra Server, and create your
+organization and user. Note that to configure Supermarket later
+in this guide, you will need a user that's a member of the `admins`
+group.
+
+1. Download the package from [Chef Downloads](https://www.chef.io/downloads).
+
+1. Upload the package to the machine that will run the Chef Infra Server, and then record its location on the file system. The rest of these steps assume this location is in the `/tmp` directory.
+
+1. {{< readfile file="content/server/reusable/md/install_chef_server_install_package.md" >}}
+
+1. Run the following to start all of the services:
+
+ ```bash
+ sudo chef-server-ctl reconfigure
+ ```
+
+ Because the Chef Infra Server is composed of many different services
+ that work together to create a functioning system, this step may
+ take a few minutes to complete.
+
+1. {{< readfile file="content/server/reusable/md/ctl_chef_server_user_create_admin.md">}}
+
+1. {{< readfile file="content/server/reusable/md/ctl_chef_server_org_create_summary.md">}}
+
+## Chef Workstation
+
+### Install Chef Workstation
+
+1. First, install the Chef Workstation [installer
+ package](https://www.chef.io/downloads). Use the
+ appropriate tool to run the installer:
+
+ ```bash
+ dpkg -i chef-workstation_0.14.16-1_amd64.deb
+ ```
+
+1. Use the `chef generate repo` command to generate your Chef repo:
+
+ ```bash
+ chef generate repo chef-repo
+ ```
+
+1. Within your Chef repo, create a `.chef` directory:
+
+ ```bash
+ mkdir /chef-repo/.chef
+ ```
+
+1. Copy the `USER.pem` and `ORGANIZATION.pem` files from the server,
+ and move them into the `.chef` directory.
+
+ ```bash
+ scp ssh-user@chef-server.example.com:/path/to/pem/files /chef-repo/.chef/
+ ```
+
+### Create a bootstrap template
+
+By default, `knife bootstrap` uses the `chef-full` template to bootstrap
+a node. This template contains a number of useful features, but it also
+attempts to pull an installation script from `https://omnitruck.chef.io`. In
+this section, you'll copy the contents of the `chef-full` template to a
+custom template, and then modify the package and Ruby gem sources.
+
+1. Navigate to the `.chef` directory, and create a `bootstrap`
+ directory within it:
+
+ ```bash
+ mkdir bootstrap
+ ```
+
+1. Move to the `bootstrap` directory and create a blank template file;
+ this example will use `airgap.erb` for the template name:
+
+ ```bash
+ touch airgap.erb
+ ```
+
+1. Still in the `bootstrap` directory, issue the following command to copy the `chef-full` configuration to your new template:
+
+ ```bash
+ find /opt/chef-workstation/embedded/lib/ruby -type f -name chef-full.erb -exec cat {} \; > airgap.erb
+ ```
+
+ This command searches for the `chef-full` template file under
+ `/opt/chef-workstation/embedded/lib/ruby`, and then outputs the
+ contents of the file to `airgap.erb`. If you used a different
+ template file name, be sure to replace `airgap.erb` with the
+ template file you created during the last step.
+
+1. Update `airgap.erb` to replace `omnitruck.chef.io` with the URL of `install.sh` on your artifact store:
+
+ ```ruby
+ install_sh="<%= knife_config[:bootstrap_url] ? knife_config[:bootstrap_url] : "http://packages.example.com/install.sh" %>"
+ ```
+
+1. Still in your text editor, locate the following line near the bottom
+ of your `airgap.erb` file:
+
+ ```ruby
+ cat > /etc/chef/client.rb <<'EOP'
+ <%= config_content %>
+ EOP
+ ```
+
+ Beneath it, add the following, replacing `gems.example.com` with the
+ URL of your gem mirror:
+
+ ```ruby
+ cat >> /etc/chef/client.rb <<'EOP'
+ rubygems_url "http://gems.example.com"
+ EOP
+ ```
+
+ This appends the appropriate `rubygems_url` setting to the
+ `/etc/chef/client.rb` file that's created during bootstrap, which
+ ensures that your nodes use your internal gem mirror.
+
+### Configure knife
+
+Within the `.chef` directory, create a `config.rb` file and replace
+`USER` and `ORGANIZATION` with the user and organization that you
+created on your Chef Infra Server; replace `chef-server.example.com`
+with your Chef Infra Server URL:
+
+```ruby
+current_dir = File.dirname(__FILE__)
+node_name 'USER'
+client_key "#{current_dir}/USER.pem"
+validation_client_name 'ORGANIZATION-validator'
+validation_key "#{current_dir}/ORGANIZATION.pem"
+chef_server_url 'https://chef-server.example.com/organizations/ORGANIZATION'
+cookbook_path ["#{current_dir}/../cookbooks"]
+knife[:bootstrap_template] = "#{current_dir}/bootstrap/airgap.erb"
+```
+
+The `knife[:bootstrap_template]` option in this example allows you to
+specify the template that `knife bootstrap` will use by default when
+bootstrapping a node. It should point to your custom template within the
+`bootstrap` directory.
+
+Now that `knife` is configured, copy the SSL certificates from your Chef
+Infra Server to your trusted certificates:
+
+```ruby
+knife ssl fetch
+```
+
+## Private Supermarket
+
+Private Supermarket allows you to host your own internal version of the
+[Chef Supermarket](https://supermarket.chef.io) within your air-gapped
+network.
+
+### Requirements
+
+In this section, you will use a wrapper around the
+[supermarket-omnibus-cookbook](https://supermarket.chef.io/cookbooks/supermarket-omnibus-cookbook)
+to install private Supermarket. The Supermarket cookbook depends upon
+the following cookbooks:
+
+- [chef-ingredient](https://supermarket.chef.io/cookbooks/chef-ingredient)
+- [hostsfile](https://supermarket.chef.io/cookbooks/hostsfile)
+
+The following Gems must be accessible using your Gem mirror:
+
+- mixlib-install
+- mixlib-shellout
+- mixlib-versioning
+- artifactory
+
+Your `cookbooks` directory must have all three of these cookbooks
+installed before you will be able to use the Supermarket cookbook
+wrapper. In addition the necessary cookbooks, a private Chef Supermarket
+has the following requirements:
+
+- An operational Chef Infra Server to act as the OAuth 2.0 provider
+- A user account on the Chef Infra Server with `admins` privileges
+- A key for the user account on the Chef server
+- An x86_64 Ubuntu, RHEL, or Amazon Linux host with at least 1 GB memory
+- System clocks synchronized on the Chef Infra Server and Supermarket hosts
+- Sufficient disk space to meet project cookbook storage capacity or credentials to store cookbooks in an Amazon Simple Storage Service (S3) bucket
+
+### Configure credentials
+
+First, you'll configure Chef Identity credentials for Supermarket. Chef
+Identity is an OAuth 2.0 service packaged with the Chef Infra Server,
+that allows you to use the same credentials to access both server and
+Supermarket.
+
+1. Log on to the Chef Infra Server using SSH and elevate to an
+ admin-level user. If running a multi-node Chef Infra Server cluster,
+ log on to the node acting as the primary node in the cluster.
+
+1. Update the `/etc/opscode/chef-server.rb` configuration file.
+
+ {{< readfile file="content/server/reusable/md/config_ocid_application_hash_supermarket.md" >}}
+
+1. Reconfigure the Chef Infra Server.
+
+ ```bash
+ sudo chef-server-ctl reconfigure
+ ```
+
+1. Retrieve Supermarket's OAuth 2.0 client credentials:
+
+ Depending on your Chef Infra Server version and configuration (see
+ [chef-server.rb](/server/config_rb_server_optional_settings/#config-rb-server-insecure-addon-compat)),
+ this can be retrieved using [chef-server-ctl oc-id-show-app
+ supermarket](/ctl_chef_server/#ctl-chef-server-oc-id-show-app)
+ or is located in `/etc/opscode/oc-id-applications/supermarket.json`:
+
+ ```json
+ {
+ "name": "supermarket",
+ "uid": "0bad0f2eb04e935718e081fb71asdfec3681c81acb9968a8e1e32451d08b",
+ "secret": "17cf1141cc971a10ce307611beda7ffadstr4f1bc98d9f9ca76b9b127879",
+ "redirect_uri": "https://supermarket.mycompany.com/auth/chef_oauth2/callback"
+ }
+ ```
+
+### Create a Wrapper
+
+1. Generate the cookbook:
+
+ ```bash
+ chef generate cookbook my_supermarket_wrapper
+ ```
+
+1. Change directories into that cookbook:
+
+ ```bash
+ cd my_supermarket_wrapper
+ ```
+
+1. Defines the wrapper cookbook's dependency on the
+ `supermarket-omnibus-cookbook` cookbook. Open the `metadata.rb` file
+ of the newly-created cookbook, and then add the following line:
+
+ ```ruby
+ depends 'supermarket-omnibus-cookbook'
+ ```
+
+1. Save and close the `metadata.rb` file.
+
+1. Open the `/recipes/default.rb` recipe located within the
+ newly-generated cookbook and add the following content:
+
+ ```ruby
+ include_recipe 'supermarket-omnibus-cookbook'
+ ```
+
+ This ensures that the `default.rb` file in the
+ `supermarket-omnibus-cookbook` is run.
+
+### Define Attributes
+
+Define the attributes for the Chef Supermarket installation and how it
+connects to the Chef Infra Server. One approach would be to hard-code
+attributes in the wrapper cookbook's `default.rb` recipe. A better
+approach is to place these attributes in a [data bag](/data_bags/),
+and then reference them from the recipe. For example, the data bag could
+be named `apps` and then a data bag item within the data bag could be
+named `supermarket`. The following attributes are required:
+
+- `chef_server_url`: the URL of your Chef Infra Server.
+- `chef_oauth2_app_id`: the Chef Identity UID from
+ `/etc/opscode/oc-id-applications/supermarket.json`
+- `chef_oauth2_secret`: The Chef Identity secret from
+ `/etc/opscode/oc-id-applications/supermarket.json`
+- `package_url`: The location of the Supermarket package on your
+ artifact store
+
+To define these attributes, do the following:
+
+1. Open the `recipes/default.rb` file and add the following, **before**
+ the `include_recipe` line that was added in the previous step. This
+ example uses a data bag named `apps` and a data bag item named
+ `supermarket`:
+
+ ```ruby
+ app = data_bag_item('apps', 'supermarket')
+ ```
+
+1. Set the attributes from the data bag:
+
+ ```ruby
+ node.override['supermarket_omnibus']['chef_server_url'] = app['chef_server_url']
+ node.override['supermarket_omnibus']['chef_oauth2_app_id'] = app['chef_oauth2_app_id']
+ node.override['supermarket_omnibus']['chef_oauth2_secret'] = app['chef_oauth2_secret']
+ node.override['supermarket_omnibus']['package_url'] = app['package_url']
+ ```
+
+ Note that the `['package_url']` setting points to the location of
+ the Supermarket package on your artifact store. When finished, the
+ `/recipes/default.rb` file should have code similar to:
+
+ ```ruby
+ app = data_bag_item('apps', 'supermarket')
+
+ node.override['supermarket_omnibus']['chef_server_url'] = app['chef_server_url']
+ node.override['supermarket_omnibus']['chef_oauth2_app_id'] = app['chef_oauth2_app_id']
+ node.override['supermarket_omnibus']['chef_oauth2_secret'] = app['chef_oauth2_secret']
+
+ include_recipe 'supermarket-omnibus-cookbook'
+ ```
+
+ Alternatively, if you chose not to use a data bag to store these
+ values, your `default.rb` should look similar to this:
+
+ ```ruby
+ node.override['supermarket_omnibus']['chef_server_url'] = 'https://chef-server.example.com:443'
+ node.override['supermarket_omnibus']['chef_oauth2_app_id'] = '0bad0f2eb04e935718e081fb71asdfec3681c81acb9968a8e1e32451d08b'
+ node.override['supermarket_omnibus']['chef_oauth2_secret'] = '17cf1141cc971a10ce307611beda7ffadstr4f1bc98d9f9ca76b9b127879'
+ node.override['supermarket_omnibus']['package_url'] = 'http://packages.example.com/supermarket_3.1.22-1_amd64.deb'
+
+ include_recipe 'supermarket-omnibus-cookbook'
+ ```
+
+1. Save and close the `recipes/default.rb` file.
+
+1. Upload all of your cookbooks to the Chef Infra Server:
+
+ ```ruby
+ knife cookbook upload -a
+ ```
+
+### Bootstrap Supermarket
+
+Bootstrap the node on which Chef Supermarket is to be installed. For
+example, to bootstrap a node running Ubuntu on Amazon Web Services
+(AWS), the command is similar to:
+
+```bash
+knife bootstrap ip_address -N supermarket-node -x ubuntu --sudo
+```
+
+where:
+
+- `-N` defines the name of the Chef Supermarket node:
+ `supermarket-node`
+- `-x` defines the (ssh) user name: `ubuntu`
+- `--sudo` ensures that sudo is used while running commands on the
+ node during the bootstrap operation
+
+When the bootstrap operation is finished, do the following:
+
+1. Add the wrapper cookbook's `/recipes/default.rb` recipe to the
+ run-list:
+
+ ```bash
+ knife node run_list set supermarket-node recipe[my_supermarket_wrapper::default]
+ ```
+
+ where `supermarket-node` is the name of the node that was just
+ bootstrapped.
+
+1. Start Chef Infra Client on the newly-bootstrapped Chef Supermarket
+ node. For example, using SSH:
+
+ ```bash
+ ssh ubuntu@your-supermarket-node-public-dns
+ ```
+
+1. After accessing the Chef Supermarket node, run Chef Infra Client:
+
+ ```bash
+ sudo chef-client
+ ```
+
+### Connect to Supermarket
+
+To reach the newly spun up private Chef Supermarket, the hostname must
+be resolvable from a workstation. For production use, the hostname
+should have a DNS entry in an appropriate domain that's trusted by each
+user's workstation.
+
+1. Visit the Chef Supermarket hostname in the browser. A private Chef
+ Supermarket will generate and use a self-signed certificate, if a
+ certificate isn't supplied as part of the installation process (using
+ the wrapper cookbook).
+1. If an SSL notice is shown due to your self-signed certificate while
+ connecting to Chef Supermarket using a web browser, accept the SSL
+ certificate. A trusted SSL certificate should be used for private
+ Chef Supermarket that's used in production.
+1. After opening Chef Supermarket in a web browser, click the **Create
+ Account** link. A prompt to log in to the Chef Infra Server is
+ shown. Authorize the Chef Supermarket to use the Chef Infra Server
+ account for authentication.
+
+{{< note >}}
+
+The redirect URL specified for Chef Identity **MUST** match the FQDN
+hostname of the Chef Supermarket server. The URI must also be correct:
+`/auth/chef_oauth2/callback`. Otherwise, an error message similar to
+`The redirect uri included isn't valid.` will be shown.
+
+{{< /note >}}
+
+### Configuration updates
+
+#### Knife
+
+Update the `config.rb` file on your workstation to use your private
+Supermarket:
+
+```ruby
+knife[:supermarket_site] = 'https://supermarket.example.com'
+```
+
+#### Berkshelf
+
+If you're using Berkshelf, update your `Berksfile` to replace
+`https://supermarket.chef.io` with the URL of your private Supermarket:
+
+```ruby
+source 'https://supermarket.example.com'
+```
+
+### Upload cookbooks to Supermarket
+
+To upload new cookbooks to your private Supermarket, use the
+`knife supermarket share` command on your workstation:
+
+```ruby
+knife supermarket share chef-ingredient
+```
diff --git a/content/install_windows.md b/content/install_windows.md
new file mode 100644
index 0000000..ef025ca
--- /dev/null
+++ b/content/install_windows.md
@@ -0,0 +1,55 @@
++++
+title = "Install Chef Infra Client on Windows Nodes"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+aliases = ["/install_windows.html"]
+
+[menu]
+ [menu.infra]
+ title = "Windows Installation Guide"
+ identifier = "chef_infra/integrations/windows/install_windows.md Chef Infra Client on Windows"
+ parent = "chef_infra/integrations/windows"
+ weight = 20
++++
+
+## Installation Methods
+
+There are several methods available to install Chef Infra Client depending on the needs of your organization.
+
+{{< readfile file="content/reusable/md/windows_install_overview.md" >}}
+
+### Use knife CLI
+
+{{< readfile file="content/workstation/reusable/md/knife_windows_summary.md" >}}
+
+#### Necessary Ports
+
+{{< readfile file="content/workstation/reusable/md/knife_windows_winrm_ports.md" >}}
+
+### Use MSI Installer
+
+A Microsoft Installer Package (MSI) is available for installing Chef Infra Client on a Windows machine at [Chef Downloads](https://www.chef.io/downloads).
+
+{{< readfile file="content/reusable/md/windows_msiexec.md" >}}
+
+#### ADDLOCAL Options
+
+{{< readfile file="content/reusable/md/windows_msiexec_addlocal.md" >}}
+
+#### Running as a Scheduled Task
+
+On Windows, run Chef Infra Client periodically as a scheduled task. Scheduled tasks provides visibility, configurability, and reliability around log rotation and permissions. You can configure the Chef Infra Client to run as a scheduled task using the [chef_client_scheduled_task](/resources/chef_client_scheduled_task/) resource.
+
+#### Scheduled Task Options
+
+{{< readfile file="content/reusable/md/install_chef_client_windows_as_scheduled_task.md" >}}
+
+### Use an Existing Process
+
+{{< readfile file="content/reusable/md/windows_install_system_center.md" >}}
+
+### PATH System Variable
+
+{{< readfile file="content/reusable/md/windows_environment_variable_path.md" >}}
diff --git a/content/legacy_uninstall.md b/content/legacy_uninstall.md
new file mode 100644
index 0000000..1ddcb2a
--- /dev/null
+++ b/content/legacy_uninstall.md
@@ -0,0 +1,51 @@
++++
+title = "Uninstall Legacy Products"
+draft = false
+gh_repo = "chef-web-docs"
+
+[menu]
+ [menu.legacy]
+ title = "Uninstall"
+ identifier = "legacy/uninstall"
+ parent = "legacy"
+ weight = 999
++++
+
+
+## Chef Analytics
+
+Use the `uninstall` subcommand to remove the Chef Analytics
+application, but without removing any of the data. This subcommand will
+shut down all services (including the `runit` process supervisor).
+
+This subcommand has the following syntax:
+
+```bash
+opscode-analytics-ctl uninstall
+```
+
+{{< note >}}
+
+To revert the `uninstall` subcommand, run the `reconfigure` subcommand
+(because the `start` subcommand is disabled by the `uninstall` command).
+
+{{< /note >}}
+
+## Reporting
+
+Use the `uninstall` subcommand to remove the Reporting add-on to the
+Chef Infra Server, but without removing any of the data. This subcommand
+will shut down all services (including the `runit` process supervisor).
+
+This subcommand has the following syntax:
+
+```bash
+opscode-reporting-ctl uninstall
+```
+
+{{< note >}}
+
+To revert the `uninstall` subcommand, run the `reconfigure` subcommand
+(because the `start` subcommand is disabled by the `uninstall` command).
+
+{{< /note >}}
diff --git a/content/libraries.md b/content/libraries.md
new file mode 100644
index 0000000..9a960af
--- /dev/null
+++ b/content/libraries.md
@@ -0,0 +1,191 @@
++++
+title = "About Libraries"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/libraries.html"]
+
+[menu]
+ [menu.infra]
+ title = "Libraries"
+ identifier = "chef_infra/cookbook_reference/libraries.md Libraries"
+ parent = "chef_infra/cookbook_reference"
+ weight = 50
++++
+
+{{< readfile file="content/reusable/md/libraries_summary.md" >}}
+
+Use a library to:
+
+- Connect to a database
+- Fetch secrets from a cloud provider
+- Talk to an LDAP provider
+- Do anything that can be done with Ruby
+
+## Syntax
+
+The syntax for a library varies because library files are created using
+Ruby and are designed to handle custom situations. See the Examples
+section below for samples.
+
+## Template Helper Modules
+
+{{< readfile file="content/reusable/md/resource_template_library_module.md" >}}
+
+## Examples
+
+The following examples show how to use cookbook libraries.
+
+### Create a Namespace
+
+A database can contain a list of virtual hosts that are used by
+customers. A custom namespace could be created that looks something
+like:
+
+```ruby
+# Sample provided by "Arjuna (fujin)". Thank you!
+
+require 'sequel'
+
+class Chef::Recipe::ISP
+ # We can call this with ISP.vhosts
+ def self.vhosts
+ v = []
+ @db = Sequel.mysql(
+ 'web',
+ user: 'example',
+ password: 'example_pw',
+ host: 'dbserver.example.com'
+ )
+ @db[
+ "SELECT virtualhost.domainname,
+ usertable.userid,
+ usertable.uid,
+ usertable.gid,
+ usertable.homedir
+ FROM usertable, virtualhost
+ WHERE usertable.userid = virtualhost.user_name"
+ ].all do |query|
+ vhost_data = {
+ servername: query[:domainname],
+ documentroot: query[:homedir],
+ uid: query[:uid],
+ gid: query[:gid],
+ }
+ v.push(vhost_data)
+ end
+ Chef::Log.debug('About to provision #{v.length} vhosts')
+ v
+ end
+end
+```
+
+After the custom namespace is created, it could then be used in a
+recipe, like this:
+
+```ruby
+ISP.vhosts.each do |vhost|
+ directory vhost[:documentroot] do
+ owner vhost[:uid]
+ group vhost[:gid]
+ mode '0755'
+ action :create
+ end
+
+ directory "#{vhost[:documentroot]}/#{vhost[:domainname]}" do
+ owner vhost[:uid]
+ group vhost[:gid]
+ mode '0755'
+ action :create
+ end
+end
+```
+
+### Extend a Recipe
+
+A customer record is stored in an attribute file that looks like this:
+
+```ruby
+mycompany_customers({
+ bob: {
+ homedir: '/home/bob',
+ webdir: '/home/bob/web',
+ },
+}
+)
+```
+
+A simple recipe may contain something like this:
+
+```ruby
+directory node["mycompany_customers"]["bob"]["webdir"] do
+ owner 'bob'
+ group 'bob'
+ action :create
+end
+```
+
+Or a less verbose version of the same simple recipe:
+
+```ruby
+directory customer(:bob)[:webdir] do
+ owner 'bob'
+ group 'bob'
+ action :create
+end
+```
+
+A simple library could be created that extends `Chef::Recipe::`, like
+this:
+
+```ruby
+class Chef
+ class Recipe
+ # A shortcut to a customer
+ def customer(name)
+ node["mycompany_customers"][name]
+ end
+ end
+end
+```
+
+### Loop Over a Record
+
+A customer record is stored in an attribute file that looks like this:
+
+```ruby
+mycompany_customers({
+ bob: {
+ homedir: '/home/bob',
+ webdir: '/home/bob/web',
+ },
+}
+)
+```
+
+If there are many customer records in an environment, a simple recipe
+can be used to loop over every customer, like this:
+
+```ruby
+all_customers do |name, info|
+ directory info[:webdir] do
+ owner name
+ group name
+ action :create
+ end
+end
+```
+
+A simple library could be created that extends `Chef::Recipe::`, like
+this:
+
+```ruby
+class Chef
+ class Recipe
+ def all_customers(&block)
+ node["mycompany_customers"].each do |name, info|
+ block.call(name, info)
+ end
+ end
+ end
+end
+```
diff --git a/content/license/_index.md b/content/license/_index.md
deleted file mode 100644
index df5f19e..0000000
--- a/content/license/_index.md
+++ /dev/null
@@ -1,104 +0,0 @@
-+++
-title = "Apply a license in Chef Infra Client"
-linkTitle = "Apply a license"
-
-[menu.licensing]
-title = "Apply a license"
-identifier = "licensing/apply"
-parent = "licensing"
-weight = 11
-+++
-
-This document outlines the licensing requirements and enforcement policies for Chef Infra Client 19.
-
-## Licensing requirements
-
-Chef Infra Client 19 has different licensing requirements depending on the distribution you download.
-
-### No license enforcement
-
-Chef Infra Client doesn't require a license to run if you download an official distribution.
-
-This includes:
-
-- Downloading Infra Client from the customer portal.
-- Installing the Infra Client Habitat package.
-- Installing Infra Client using the migration tool or native installer.
-
-### License required
-
-You need a license key to run Chef Infra Client when you:
-
-- Download it from unofficial sources (public Ruby gem).
-- Use runtime installations and workflows.
-
-## Add a license
-
-You can set a license in Chef Infra Client 19 using one of three methods:
-
-- An environment variable
-- A command line option
-- The command line interactive dialog
-
-If you set a license key, Chef Infra Client validates it with Progress Chef's licensing service.
-
-### Environment variable
-
-To set the license key, add the `CHEF_LICENSE_KEY` environment variable:
-
-```sh
-export CHEF_LICENSE_KEY=
-```
-
-### Command line option
-
-To set the license key, use the `--chef-license-key` CLI option:
-
-```sh
-chef-client --chef-license-key=
-```
-
-### Interactive license dialog
-
-If you run a `chef-client` command and choose to set a license, Chef Infra Client can start an interactive licensing dialog.
-
-To set a license key with the CLI interactive dialog, follow these steps:
-
-1. Verify the version of Chef Infra Client you have installed:
-
- ```sh
- chef-client --version
- ```
-
- This should return version 19.0.54 or greater for Infra Client RC 1.
-
-1. Run `chef-client` in local mode and why-run mode:
-
- ```sh
- chef-client --local-mode --why-run
- ```
-
- Local mode runs Chef Infra Client on your local machine as if it were running against Chef Infra Server.
- Why-run mode shows you what Chef Infra Client would configure during a Chef Infra Client run.
-
-1. At the first prompt, select **I already have a license ID**:
-
- ```text
- Please choose one of the options below (Press ↑/↓ arrow to move and Enter to select)
- ‣ I already have a license ID
- I don't have a license ID and would like to generate a new license ID
- Skip
- ```
-
-1. Enter your license key at the second prompt.
-
- ```text
- Please enter your license ID:
- ✔ [Success] License validated successfully.
- ```
-
- After entering the license key, Chef Infra Client verifies your license and the run completes.
-
-## Next step
-
-After installing Chef Infra Client and adding a license, you can test it by running an [example cookbook](/cookbooks).
diff --git a/content/license/troubleshooting.md b/content/license/troubleshooting.md
deleted file mode 100644
index e909329..0000000
--- a/content/license/troubleshooting.md
+++ /dev/null
@@ -1,78 +0,0 @@
-+++
-title = "Troubleshoot licensing issues"
-
-[menu.licensing]
-title = "Troubleshooting"
-identifier = "licensing/troubleshoot"
-parent = "licensing"
-weight = 20
-+++
-
-
-
-## Support contact
-
-For any licensing issues, contact [Aditya V](mailto:aditya.v@progress.com) or [Ankur Mundhra](mailto:ankur.mundhra@progress.com) with your license details, error logs, and a description of the issue.
diff --git a/content/lwrp_to_custom_resources.md b/content/lwrp_to_custom_resources.md
new file mode 100644
index 0000000..526b1e6
--- /dev/null
+++ b/content/lwrp_to_custom_resources.md
@@ -0,0 +1,123 @@
++++
+title = "Migrating from LWRPs to Custom Resources"
+gh_repo = "chef-web-docs"
+
+product = ["client", "workstation"]
+
+[menu]
+ [menu.infra]
+ title = "Migrating from LWRPs"
+ identifier = "chef_infra/resources/custom_resources/lwrp"
+ parent = "chef_infra/resources/custom_resources"
+ weight = 70
++++
+
+## Overview
+
+It's no longer recommended to write resources in the __Light Weight Resource Provider (LWRP)__ format.
+
+This guide describes how to migrate from an existing LWRP to a Custom Resource.
+
+If you are creating a Custom Resource from scratch please see the [Custom Resource Getting Started Guide]({{< relref "custom_resources.md" >}}) instead.
+
+## Convert files to Custom Resources Layout
+
+LWRPs consist of two library files: a resource and a provider for that resource.
+
+```text
+|- libraries
+ |- provider_rvm_ruby.rb
+ |- resource_rvm_ruby.rb
+```
+
+These files are merged into one, and moved into the resources directory.
+
+```text
+|- resources
+ |- rvm_ruby.rb
+```
+
+## Drop LWRP classes
+
+LWRPs used classes to separate Provider and Resource behaviors, but Custom Resources don't need this distinction. This means that we remove the class definitions in their entirety, as shown in the following example:
+
+```ruby
+#rvm/libraries/resource_rvm_ruby.rb
+require 'chef/resource/lwrp_base'
+
+class Chef
+ class Resource
+ class RvmRuby < Chef::Resource::LWRPBase
+ provides :rvm_ruby
+
+ self.resource_name = :rvm_ruby
+ default_action :install
+ end
+ end
+end
+
+# rvm/libraries/provider_rvm_ruby.rb
+require 'chef/provider/lwrp_base'
+
+class Chef
+ class Provider
+ class RvmRuby < Chef::Provider::LWRPBase
+ provides :rvm_ruby
+
+ action :install do
+ remote_file 'rvm_installer' do
+ path "#{Chef::Config[:file_cache_path]}/rvm_installer.sh"
+ source node['rvm']['installer_url']
+ mode '755'
+ not_if { ::File.exist?("#{Chef::Config[:file_cache_path]}/rvm_installer.sh") }
+ action :create
+ end
+ end
+ end
+ end
+end
+```
+
+Replace the above files with a singular resource:
+
+```ruby
+#rvm/resources/rvm_ruby.rb
+provides :rvm_ruby
+default_action :install
+
+action :install do
+ remote_file 'rvm_installer' do
+ path "#{Chef::Config[:file_cache_path]}/rvm_installer.sh"
+ source node['rvm']['installer_url']
+ mode '755'
+ not_if { ::File.exist?("#{Chef::Config[:file_cache_path]}/rvm_installer.sh") }
+ action :create
+ end
+end
+```
+
+## Remove Attributes
+
+It's best practice to use properties to change the behavior of resources.
+
+In the previous example example we used an attribute to change the `installer_url`.
+
+Instead, we should use a property that we can perform checks on. In this case, we can make sure we only accept a String.
+
+```ruby
+#rvm/resources/rvm_ruby.rb
+provides :rvm_ruby
+default_action :install
+
+property installer_url, String, default: 'https://raw.githubusercontent.com/rvm/rvm/master/binscripts/rvm-installer'
+
+action :install do
+ remote_file 'rvm_installer' do
+ path "#{Chef::Config[:file_cache_path]}/rvm_installer.sh"
+ source new_resource.installer_url
+ mode '755'
+ not_if { ::File.exist?("#{Chef::Config[:file_cache_path]}/rvm_installer.sh") }
+ action :create
+ end
+end
+```
diff --git a/content/nodes.md b/content/nodes.md
new file mode 100644
index 0000000..78445a5
--- /dev/null
+++ b/content/nodes.md
@@ -0,0 +1,131 @@
++++
+title = "About Nodes"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/nodes.html"]
+product = ["client", "server"]
+
+[menu]
+ [menu.infra]
+ title = "Nodes"
+ identifier = "chef_infra/overview/nodes.md Nodes"
+ parent = "chef_infra/overview"
+ weight = 30
++++
+
+{{< readfile file="content/reusable/md/node.md" >}}
+
+{{< readfile file="content/reusable/md/node_types.md" >}}
+
+The key components of nodes that are under management by Chef include:
+
+
+
+## Node Names
+
+The name of a node is required as part of the authentication process to
+the Chef Infra Server. The name of each node must be unique within an
+organization, but otherwise can be any string that matches the following
+regular expression:
+
+```re
+ /^[\-[:alnum:]_:.]+$/
+```
+
+The name of a node can be obtained from the `node_name` attribute in the
+client.rb file or by allowing Ohai to collect this data during a Chef
+Infra Client run. When Ohai collects this data during a Chef Infra
+Client run, it uses the node's FQDN, which is always unique within an
+organization, as the name of the node.
+
+Using the FQDN as the node name, and then allowing Ohai to collect this
+information during each Chef Infra Client run, is the recommended
+approach and the easiest way to ensure that the names of all nodes
+across the organization are unique.
+
+## Node Objects
+
+For Chef Infra Client, two important aspects of nodes are groups of
+attributes and run-lists. An attribute is a specific piece of data about
+the node, such as a network interface, a file system, or the number of
+clients a service running on a node is capable of accepting.
+A run-list is an ordered list of recipes and/or roles that are run in an
+exact order. The node object consists of the run-list and node
+attributes, which is a JSON file that's stored on the Chef Infra
+Server. Chef Infra Client gets a copy of the node object from the Chef
+Infra Server during each Chef Infra Client run and places an updated
+copy on the Chef Infra Server at the end of each Chef Infra Client run.
+
+{{< readfile file="content/reusable/md/node_attribute.md" >}}
+
+### Attributes
+
+An attribute is a specific detail about a node, such as an IP address, a
+host name, a list of loaded kernel modules, the versions of available
+programming languages that are available. An attribute may be
+unique to a specific node or it can be identical across every node in
+the organization. Attributes are most commonly set from a cookbook, by
+using knife, or are retrieved by Ohai from each node before every Chef
+Infra Client run. All attributes are indexed for search on the Chef
+Infra Server. Good candidates for attributes include:
+
+- any cross-platform abstraction for an application, such as the path
+ to a configuration file
+- default values for tunable settings, such as the amount of memory
+ assigned to a process or the number of workers to spawn
+- anything that may need to be persisted in node data between Chef
+ Infra Client runs
+
+In general, attribute precedence is set to enable cookbooks and roles to
+define attribute defaults, for normal attributes to define the values
+that should be specific for a node, and for override attributes to force
+a certain value, even when a node already has that value specified.
+
+One approach is to set attributes at the same precedence level by
+setting attributes in a cookbook's attribute files, and then also
+setting the same default attributes (but with different values) using a
+role. The attributes set in the role will be deep merged on top of the
+attributes from the attribute file, and the attributes set by the role
+will take precedence over the attributes specified in the cookbook's
+attribute files.
+
+See [Attributes](/attributes) for detailed information on the different types of node attributes and how they're used to set policy on nodes.
+
+### Run-lists
+
+{{< readfile file="content/reusable/md/node_run_list.md" >}}
+
+#### Run-list Format
+
+{{< readfile file="content/reusable/md/node_run_list_format.md" >}}
+
+## Managing Nodes
+
+You can manage nodes directly using Knife, Chef Automate, or by using command-line tools that are specific to Chef Infra Client.
+
+- [Knife](/workstation/knife/) can be used to create, edit, view, list, tag, and delete nodes.
+- Knife plug-ins can be used to create, edit, and manage nodes that are located on cloud providers.
+- Chef Infra Client can be used to manage node data using the command line and JSON files. Each JSON file contains a hash, the elements of which are added as node attributes. In addition, the `run_list` setting allows roles and/or recipes to be added to the node.
+- The command line can also be used to edit JSON files and files that are related to third-party services, such as Amazon EC2, where the JSON files can contain metadata fore each instance that's stored in a file on-disk and then read by Chef Infra Client as required.
diff --git a/content/ohai.md b/content/ohai.md
new file mode 100644
index 0000000..a19f530
--- /dev/null
+++ b/content/ohai.md
@@ -0,0 +1,288 @@
++++
+title = "About Ohai"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+aliases = ["/ohai.html"]
+
+[menu]
+ [menu.infra]
+ title = "About Ohai"
+ identifier = "chef_infra/features/ohai/ohai.md About Ohai"
+ parent = "chef_infra/features/ohai"
+ weight = 10
++++
+
+{{< readfile file="content/reusable/md/ohai_summary.md" >}}
+
+Ohai collects data for many platforms, including AIX, macOS, Linux, FreeBSD, Solaris, and any Windows operating systems.
+
+See the [Chef Infra Client release notes](/release_notes_client/) for the latest information on Ohai.
+
+## Automatic Attributes
+
+{{< note >}}
+
+{{< readfile file="content/reusable/md/notes_see_attributes_overview.md" >}}
+
+{{< /note >}}
+
+{{< readfile file="content/reusable/md/ohai_automatic_attribute.md" >}}
+
+### Get a list of automatic attributes for a node
+
+{{< readfile file="content/reusable/md/ohai_attribute_list.md" >}}
+
+### Attributes Blocklist
+
+{{< warning >}}
+
+{{< readfile file="content/reusable/md/node_attribute_blocklist_warning.md" >}}
+
+{{< /warning >}}
+
+{{< readfile file="content/reusable/md/node_attribute_blocklist.md" >}}
+
+### Attribute Allowlist
+
+{{< warning >}}
+
+{{< readfile file="content/reusable/md/node_attribute_allowlist_warning.md" >}}
+
+{{< /warning >}}
+
+## Default Plugins
+
+The following list shows the type of plugins that are included with Ohai. See the `ohai/lib/ohai/plugins` directory in the version of Ohai installed on your system for the full list:
+
+### General Purpose Plugins
+
+```ruby
+azure.rb
+c.rb
+chef.rb
+cloud.rb
+command.rb
+cpu.rb
+digital_ocean.rb
+dmi.rb
+docker.rb
+ec2.rb
+elixir.rb
+erlang.rb
+eucalyptus.rb
+filesystem.rb
+freebsd
+gce.rb
+go.rb
+groovy.rb
+haskell.rb
+hostname.rb
+init_package.rb
+java.rb
+joyent.rb
+kernel.rb
+keys.rb
+languages.rb
+libvirt.rb
+linode.rb
+lua.rb
+mono.rb
+network.rb
+nodejs.rb
+ohai_time.rb
+ohai.rb
+memory.rb
+network.rb
+platform.rb
+openstack.rb
+os.rb
+packages.rb
+perl.rb
+php.rb
+platform.rb
+powershell.rb
+ps.rb
+python.rb
+rackspace.rb
+root_group.rb
+ruby.rb
+rust.rb
+scala.rb
+scaleway.rb
+shard.rb
+shells.rb
+softlayer.rb
+ssh_host_key.rb
+timezone.rb
+uptime.rb
+virtualbox.rb
+vmware.rb
+zpools.rb
+```
+
+### Platform Specific Plugins
+
+```ruby
+aix
+ kernel.rb
+ memory.rb
+ network.rb
+ platform.rb
+ uptime.rb
+ virtualization.rb
+bsd
+ virtualization.rb
+darwin
+ cpu.rb
+ filesystem.rb
+ hardware.rb
+ memory.rb
+ network.rb
+ platform.rb
+ system_profiler.rb
+ virtualization.rb
+dragonflybsd
+ cpu.rb
+ memory.rb
+ network.rb
+ os.rb
+ platform.rb
+freebsd
+ cpu.rb
+ memory.rb
+ network.rb
+ os.rb
+ platform.rb
+linux
+ block_device.rb
+ cpu.rb
+ filesystem.rb
+ fips.rb
+ hostnamectl.rb
+ lsb.rb
+ machineid.rb
+ mdadm.rb
+ memory.rb
+ network.rb
+ platform.rb
+ sessions.rb
+ virtualization.rb
+netbsd
+ cpu.rb
+ memory.rb
+ network.rb
+ platform.rb
+openbsd
+ cpu.rb
+ memory.rb
+ network.rb
+ platform.rb
+solaris2
+ cpu.rb
+ dmi.rb
+ filesystem.rb
+ memory.rb
+ network.rb
+ platform.rb
+ virtualization.rb
+windows
+ cpu.rb
+ drivers.rb
+ filesystem.rb
+ fips.rb
+ memory.rb
+ network.rb
+ platform.rb
+ system_enclosure.rb
+ virtualization.rb
+```
+
+## Optional Plugins
+
+Ohai ships several optional plugins that you can enable in the [client.rb configuration file](/config_rb_client/).
+
+ `:Grub2`
+: Information from the Linux Grub2 bootloader
+
+ `:IPC`
+: SysV IPC shmem information (New in Chef Infra Client 16)
+
+ `:Interupts`
+: Data from /proc/interrupts and /proc/irq (New in Chef Infra Client 16)
+
+ `:Lspci`
+: PCI device information on Linux hosts.
+
+ `:Lsscsi`
+: SCSI device information on Linux hosts.
+
+ `:Passwd`
+: User and Group information. This plugin can result in large node sizes if a system connects to Active Directory or LDAP.
+
+ `:Sessions`
+: Sessions data from loginctl on Linux hosts.
+
+`:Sysctl`
+
+: All sysctl values on Linux hosts.
+
+### Enabling Optional Plugins
+
+Optional plugins can be enabled in the [client.rb configuration file](/config_rb_client/):
+
+```ruby
+ohai.optional_plugins = [
+ :Sessions,
+ :Lspci,
+]
+```
+
+{{< note >}}
+
+The Ohai optional_plugins config array must contain an array of plugin names as Symbols not Strings.
+
+{{< /note >}}
+
+## Ohai Settings in client.rb
+
+{{< readfile file="content/reusable/md/config_rb_ohai.md" >}}
+
+{{< readfile file="content/reusable/md/config_rb_ohai_settings.md" >}}
+
+## Custom Plugins
+
+Custom Ohai plugins can be written to collect additional information from systems as necessary. See the [Ohai Custom Plugins](/ohai_custom/) docs for more information.
+
+## Hints
+
+Ohai hints are used to tell Ohai something about the system that it's running on that it would not be able to discover itself. An Ohai hint exists if a JSON file exists in the hint directory with the same name as the hint. For example, calling `hint?('antarctica')` in an Ohai plugin would return an empty hash if the file `antarctica.json` existed in the hints directory, and return nil if the file doesn't exist.
+
+If the hint file contains JSON content, it will be returned as a hash from the call to `hint?`.
+
+```json
+{
+ "snow": true,
+ "penguins": "many"
+}
+```
+
+```ruby
+antarctica_hint = hint?('antarctica')
+if antarctica_hint['snow']
+ "There are #{antarctica_hint['penguins']} penguins here."
+else
+ 'There is no snow here, and penguins like snow.'
+end
+```
+
+Hint files are located in the `/etc/chef/ohai/hints/` directory by default. Use the `Ohai.config[:hints_path]` setting in the [client.rb configuration file](/config_rb_client/) to customize this location.
+
+## `ohai` Resource
+
+Chef Infra Client includes an `ohai` resource that allows you to reload the Ohai data on a node. This allows recipes or resources that change system attributes (like a recipe that adds a user) to refer to those attributes later on during a Chef Infra Client run. See the [ohai resource](/resources/ohai) for complete usage information.
+
+## ohai Command Line Tool
+
+Ohai can be run on the command line outside of the Chef Infra Client run. See [Ohai (executable)](/ctl_ohai) for more information.
diff --git a/content/ohai_custom.md b/content/ohai_custom.md
new file mode 100644
index 0000000..3c76c6a
--- /dev/null
+++ b/content/ohai_custom.md
@@ -0,0 +1,603 @@
++++
+title = "Writing Ohai Custom Plugins"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+aliases = ["/ohai_custom.html"]
+
+[menu]
+ [menu.infra]
+ title = "Custom Plugins"
+ identifier = "chef_infra/extension_apis/ohai_plugins/ohai_custom.md Custom Plugins"
+ parent = "chef_infra/extension_apis/ohai_plugins"
+ weight = 10
++++
+
+You can write custom Ohai plugins to collect additional configuration attributes with Ohai to provide to Chef Infra Client during runs.
+
+Ohai plugins are written in Ruby with a plugin DSL documented below. Being written in Ruby provides access to all Ruby's built-in functionality, as well as 3rd party gem functionality. Plugins can parse the output of any local command on the node, or they can fetch data from external APIs. Examples of plugins that users have written: - A plugin to gather node information including data center, rack, and rack position from an inventory server - A plugin to gather additional RAID array information from a controller utility - A plugin to gather hardware
+warranty information from a vendor API
+
+See [About Ohai](/ohai/) for information on Ohai configuration and usage.
+
+## Install Ohai Plugins
+
+Install custom Ohai plugins by creating an `ohai` directory in your cookbook and saving your plugin code to this location.
+
+To migrate custom Ohai plugins from the deprecated ohai cookbook:
+
+1. Create an `ohai` directory in your cookbook
+1. Move your plugin into the `ohai` directory
+1. Remove the outdated custom Ohai plugin installation code from your code
+
+Chef Infra Client will move the file into the correct location, load it, and return the data in the next configuration run. Chef Infra Client will provide other cookbooks that depend on the custom Ohai plugin with the correct data.
+
+## Syntax
+
+The syntax for an Ohai plugin is as follows:
+
+```ruby
+Ohai.plugin(:Name) do
+ provides 'attribute', 'attribute/subattribute'
+ depends 'attribute', 'attribute'
+
+ def shared_method
+ # some Ruby code that defines the shared method
+ attribute my_data
+ end
+
+ collect_data(:default) do
+ # some Ruby code
+ attribute my_data
+ end
+
+ collect_data(:platform...) do
+ # some Ruby code that defines platform-specific requirements
+ attribute my_data
+ end
+end
+```
+
+where
+
+- Required. `(:Name)` is used to identify the plugin; when two plugins have the same `(:Name)`, those plugins are joined together and run as if they were a single plugin. This value must be a valid Ruby class name, starting with a capital letter and containing only alphanumeric characters
+- Required. `provides` is a comma-separated list of one (or more) attributes that are defined by this plugin. This attribute will become an automatic attribute (`node['attribute']`) after it's collected by Ohai at the start of a Chef Infra Client run. An attribute can also be defined using an `attribute/subattribute` pattern
+- `depends` is a comma-separated list of one (or more) attributes that are collected by another plugin; as long as the value is collected by another Ohai plugin, it can be used by any plugin
+- `shared_method` defines code that can be shared among one (or more) `collect_data` blocks; for example, instead of defining a mash for each `collect_data` block, the code can be defined as a shared method, and then called from any `collect_data` block
+- `collect_data` is a block of Ruby code that's called by Ohai when it runs; one (or more) `collect_data` blocks can be defined in a plugin, but only a single `collect_data` block is ever run.
+- `collect_data(:default)` is the code block that runs when a node's platform isn't defined by a platform-specific `collect_data` block
+- `collect_data(:platform)` is a platform-specific code block that's run when a match exists between the node's platform and this `collect_data` block; only one `collect_data` block may exist for each platform; possible values: `:aix`, `:darwin`, `:freebsd`, `:linux`, `:openbsd`, `:netbsd`, `:solaris2`, `:windows`, or any other value from `RbConfig::CONFIG['host_os']`
+- `my_data` is string (`a string value`) or an empty mash (`{ :setting_a => 'value_a', :setting_b => 'value_b' }`). This is used to define the data that should be collected by the plugin
+
+For example, the following plugin looks up data on virtual machines hosted in Amazon EC2, Google Compute Engine, Rackspace, Eucalyptus, Linode, OpenStack, and Microsoft Azure:
+
+```ruby
+Ohai.plugin(:Cloud) do
+ provides 'cloud'
+
+ depends 'ec2'
+ depends 'gce'
+ depends 'rackspace'
+ depends 'eucalyptus'
+ depends 'linode'
+ depends 'openstack'
+ depends 'azure'
+
+ def create_objects
+ cloud Mash.new
+ cloud[:public_ips] = []
+ cloud[:private_ips] = []
+ end
+
+ ...
+
+ def on_gce?
+ gce != nil
+ end
+
+ def get_gce_values
+ cloud[:public_ipv4] = []
+ cloud[:local_ipv4] = []
+
+ public_ips = gce['instance']['networkInterfaces'].collect do |interface|
+ if interface.has_key?('accessConfigs')
+ interface['accessConfigs'].collect{|ac| ac['externalIp']}
+ end
+ end.flatten.compact
+
+ private_ips = gce['instance']['networkInterfaces'].collect do |interface|
+ interface['ip']
+ end.compact
+
+ cloud[:public_ips] += public_ips
+ cloud[:private_ips] += private_ips
+ cloud[:public_ipv4] += public_ips
+ cloud[:public_hostname] = nil
+ cloud[:local_ipv4] += private_ips
+ cloud[:local_hostname] = gce['instance']['hostname']
+ cloud[:provider] = 'gce'
+ end
+
+ ...
+
+ # with following similar code blocks for each cloud provider
+```
+
+where
+
+- `provides` defines the `cloud` attribute, which is then turned into an object using the `create_objects` shared method, which then generates a hash based on public or private IP addresses
+- For Google Compute Engine the `cloud` attribute data is populated into a hash based on the IP address for the node
+
+To see the rest of the code in this plugin, go to: .
+
+## Ohai Methods
+
+The Ohai DSL is a Ruby DSL that's used to define an Ohai plugin and to ensure that Ohai collects the right data at the start of every Chef Infra Client run. The Ohai DSL is a small DSL with a single method that's specific to Ohai plugins. Because the Ohai DSL is a Ruby DSL, anything that can be done using Ruby can also be done when defining an Ohai plugin.
+
+### collect_data
+
+The `collect_data` method is a block of Ruby code that's called by Ohai when it runs. One (or more) `collect_data` blocks can be defined in a plugin, but only a single `collect_data` block is ever run. The `collect_data` block that's run is determined by the platform on which the node is running, which is then matched up against the available `collect_data` blocks in the plugin.
+
+- A `collect_data(:default)` block is used when Ohai isn't able to match the platform of the node with a `collect_data(:platform)` block in the plugin
+- A `collect_data(:platform)` block is required for each platform that requires non-default behavior
+
+When Ohai runs, if there isn't a matching `collect_data` block for a platform, the `collect_data(:default)` block is used. The syntax for the `collect_data` method is:
+
+```ruby
+collect_data(:default) do
+ # some Ruby code
+end
+```
+
+or:
+
+```ruby
+collect_data(:platform) do
+ # some Ruby code
+end
+```
+
+where:
+
+- `:default` is the name of the default `collect_data` block
+- `:platform` is the name of a platform, such as `:aix` for AIX or `:windows` for Windows
+
+#### Use a Mash
+
+Use a mash to store data. This is done by creating a new mash, and then setting an attribute to it. For example:
+
+```ruby
+provides 'name_of_mash'
+name_of_mash Mash.new
+name_of_mash[:attribute] = 'value'
+```
+
+#### Examples
+
+The following examples show how to use the `collect_data` block:
+
+```ruby
+Ohai.plugin(:Azure) do
+ provides 'azure'
+
+ collect_data do
+ azure_metadata_from_hints = hint?('azure')
+ if azure_metadata_from_hints
+ Ohai::Log.debug('azure_metadata_from_hints is present.')
+ azure Mash.new
+ azure_metadata_from_hints.each {|k, v| azure[k] = v }
+ else
+ Ohai::Log.debug('No hints present for azure.')
+ false
+ end
+ end
+end
+```
+
+or:
+
+```ruby
+require 'ohai/mixin/ec2_metadata'
+extend Ohai::Mixin::Ec2Metadata
+
+Ohai.plugin do
+ provides 'openstack'
+
+ collect_data do
+ if hint?('openstack') || hint?('hp')
+ Ohai::Log.debug('ohai openstack')
+ openstack Mash.new
+ if can_metadata_connect?(EC2_METADATA_ADDR,80)
+ Ohai::Log.debug('connecting to the OpenStack metadata service')
+ self.fetch_metadata.each {|k, v| openstack[k] = v }
+ case
+ when hint?('hp')
+ openstack['provider'] = 'hp'
+ else
+ openstack['provider'] = 'openstack'
+ end
+ else
+ Ohai::Log.debug('unable to connect to the OpenStack metadata service')
+ end
+ else
+ Ohai::Log.debug('NOT ohai openstack')
+ end
+ end
+end
+```
+
+### require
+
+The `require` method is a standard Ruby method that can be used to list files that may be required by a platform, such as an external class library. As a best practice, even though the `require` method is often used at the top of a Ruby file, it's recommended that the use of the `require` method be used as part of the platform-specific `collect_data` block. For example, the Ruby WMI is required with Windows:
+
+```ruby
+collect_data(:windows) do
+ require 'ruby-wmi'
+ WIN32OLE.codepage = WIN32OLE::CP_UTF8
+
+ kernel Mash.new
+
+ host = WMI::Win32_OperatingSystem.find(:first)
+ kernel[:os_info] = Mash.new
+ host.properties_.each do |p|
+ kernel[:os_info][p.name.wmi_underscore.to_sym] = host.send(p.name)
+ end
+
+ ...
+
+end
+```
+
+Ohai will attempt to fully qualify the name of any class by prepending `Ohai::` to the loaded class. For example both:
+
+```ruby
+require Ohai::Mixin::ShellOut
+```
+
+and:
+
+```ruby
+require Mixin::ShellOut
+```
+
+are both understood by the Ohai in the same way: `Ohai::Mixin::ShellOut`.
+
+When a class is an external class (and therefore shouldn't have `Ohai::` prepended), use `::` to let the Ohai know. For example:
+
+```ruby
+::External::Class::Library
+```
+
+#### /common Directory
+
+The `/common` directory stores code that's used across all Ohai plugins. For example, a file in the `/common` directory named `virtualization.rb` that includes code like the following:
+
+```ruby
+module Ohai
+ module Common
+ module Virtualization
+
+ def host?(virtualization)
+ !virtualization.nil? && virtualization[:role].eql?('host')
+ end
+
+ def open_virtconn(system)
+ begin
+ require 'libvirt'
+ require 'hpricot'
+ rescue LoadError => e
+ Ohai::Log.debug('Cannot load gem: #{e}.')
+ end
+
+ emu = (system.eql?('kvm') ? 'qemu' : system)
+ virtconn = Libvirt::open_read_only('#{emu}:///system')
+ end
+
+ ...
+
+ def networks(virtconn)
+ networks = Mash.new
+ virtconn.list_networks.each do |n|
+ nv = virtconn.lookup_network_by_name n
+ networks[n] = Mash.new
+ networks[n][:xml_desc] = (nv.xml_desc.split('\n').collect {|line| line.strip}).join
+ ['bridge_name','uuid'].each {|a| networks[n][a] = nv.send(a)}
+ #xdoc = Hpricot networks[n][:xml_desc]
+ end
+ networks
+ end
+
+ ...
+
+ end
+ end
+end
+```
+
+can then be leveraged in a plugin by using the `require` method to require the `virtualization.rb` file and then later calling each of the methods in the required module:
+
+```ruby
+require 'ohai/common/virtualization'
+
+Ohai.plugin(:Virtualization) do
+ include Ohai::Common::Virtualization
+
+ provides 'virtualization'
+ %w{ capabilities domains networks storage }.each do |subattr|
+ provides 'virtualization/#{subattr}'
+ end
+
+ collect_data(:linux) do
+ virtualization Mash.new
+
+ ...
+
+ if host?(virtualization)
+ v = open_virtconn(virtualization[:system])
+
+ virtualization[:libvirt_version] = libvirt_version(v)
+ virtualization[:nodeinfo] = nodeinfo(v)
+ virtualization[:uri] = uri(v)
+ virtualization[:capabilities] = capabilities(v)
+ virtualization[:domains] = domains(v)
+ virtualization[:networks] = networks(v)
+ virtualization[:storage] = storage(v)
+
+ close_virtconn(v)
+ end
+```
+
+### Shared Methods
+
+Use shared methods to define objects for use in `collect_data` blocks, such as a data structure, a hash, or a mash. The syntax for a shared method is:
+
+```ruby
+def a_shared_method
+ # some Ruby code that defines the shared method
+end
+```
+
+The following example declares a shared `cloud` method to collect data about cloud providers based on the type of IP address and then uses the `cloud` object to collect data from different cloud providers.
+
+Create `cloud` objects based on the type of IP address:
+
+```ruby
+def create_objects
+ cloud Mash.new
+ cloud[:public_ips] = Array.new
+ cloud[:private_ips] = Array.new
+end
+```
+
+Use `cloud` object to collect Linode data:
+
+```ruby
+def get_linode_values
+ cloud[:public_ips] << linode['public_ip']
+ cloud[:private_ips] << linode['private_ip']
+ cloud[:public_ipv4] = linode['public_ipv4']
+ cloud[:public_hostname] = linode['public_hostname']
+ cloud[:local_ipv4] = linode['local_ipv4']
+ cloud[:local_hostname] = linode['local_hostname']
+ cloud[:provider] = 'linode'
+end
+```
+
+Use the `cloud` object to collect Azure data:
+
+```ruby
+def get_azure_values
+ cloud[:vm_name] = azure['vm_name']
+ cloud[:public_ips] << azure['public_ip']
+ cloud[:public_fqdn] = azure['public_fqdn']
+ cloud[:public_ssh_port] = azure['public_ssh_port'] if azure['public_ssh_port']
+ cloud[:public_winrm_port] = azure['public_winrm_port'] if azure['public_winrm_port']
+ cloud[:provider] = 'azure'
+end
+```
+
+## Logging
+
+Use the `Ohai::Log` class in an Ohai plugin to define log entries that are created by Ohai. The syntax for a log message is as follows:
+
+```ruby
+Ohai::Log.log_type('message')
+```
+
+where
+
+- `log_type` can be `.debug`, `.info`, `.warn`, `.error`, or `.fatal`
+- `'message'` is the message that's logged.
+
+For example:
+
+```ruby
+Ohai.plugin do
+ provides 'openstack'
+
+ collect_data do
+ if hint?('openstack') || hint?('hp')
+ Ohai::Log.debug('ohai openstack')
+ openstack Mash.new
+ if can_metadata_connect?(EC2_METADATA_ADDR,80)
+ Ohai::Log.debug('connecting to the OpenStack metadata service')
+ self.fetch_metadata.each {|k, v| openstack[k] = v }
+ case
+ when hint?('hp')
+ openstack['provider'] = 'hp'
+ else
+ openstack['provider'] = 'openstack'
+ end
+ else
+ Ohai::Log.debug('unable to connect to the OpenStack metadata service')
+ end
+ else
+ Ohai::Log.debug('NOT ohai openstack')
+ end
+ end
+end
+```
+
+### rescue
+
+Use the `rescue` clause to make sure that a log message is always provided. For example:
+
+```ruby
+rescue LoadError => e
+ Ohai::Log.debug('ip_scopes: can't load gem, plugin disabled: #{e}')
+end
+```
+
+## Examples
+
+The following examples show different ways of building Ohai plugins.
+
+### collect_data Blocks
+
+The following Ohai plugin uses multiple `collect_data` blocks and shared methods to define platforms:
+
+```ruby
+Ohai.plugin(:Hostname) do
+ provides 'domain', 'fqdn', 'hostname'
+
+ def from_cmd(cmd)
+ so = shell_out(cmd)
+ so.stdout.split($/)[0]
+ end
+
+ def collect_domain
+ if fqdn
+ fqdn =~ /.+?\.(.*)/
+ domain $1
+ end
+ end
+
+ collect_data(:aix, :hpux) do
+ hostname from_cmd('hostname -s')
+ fqdn from_cmd('hostname')
+ domain collect_domain
+ end
+
+ collect_data(:darwin, :netbsd, :openbsd) do
+ hostname from_cmd('hostname -s')
+ fqdn from_cmd('hostname')
+ domain collect_domain
+ end
+
+ collect_data(:freebsd) do
+ hostname from_cmd('hostname -s')
+ fqdn from_cmd('hostname -f')
+ domain collect_domain
+ end
+
+ collect_data(:linux) do
+ hostname from_cmd('hostname -s')
+ begin
+ fqdn from_cmd('hostname --fqdn')
+ rescue
+ Ohai::Log.debug('hostname -f returned an error, probably no domain is set')
+ end
+ domain collect_domain
+ end
+
+ collect_data(:solaris2) do
+ require 'socket'
+
+ hostname from_cmd('hostname')
+
+ fqdn_lookup = Socket.getaddrinfo(hostname, nil, nil, nil, nil, Socket::AI_CANONNAME).first[2]
+ if fqdn_lookup.split('.').length > 1
+ # we received an fqdn
+ fqdn fqdn_lookup
+ else
+ # default to assembling one
+ h = from_cmd('hostname')
+ d = from_cmd('domainname')
+ fqdn '#{h}.#{d}'
+ end
+
+ domain collect_domain
+ end
+
+ collect_data(:windows) do
+ require 'ruby-wmi'
+ require 'socket'
+
+ host = WMI::Win32_ComputerSystem.find(:first)
+ hostname '#{host.Name}'
+
+ info = Socket.gethostbyname(Socket.gethostname)
+ if info.first =~ /.+?\.(.*)/
+ fqdn info.first
+ else
+ # host isn't in dns. optionally use:
+ # C:\WINDOWS\system32\drivers\etc\hosts
+ fqdn Socket.gethostbyaddr(info.last).first
+ end
+
+ domain collect_domain
+ end
+end
+```
+
+### Use a mixin Library
+
+The following Ohai example shows a plugin can use a `mixin` library and also depend on another plugin:
+
+```ruby
+require 'ohai/mixin/os'
+
+Ohai.plugin(:Os) do
+ provides 'os', 'os_version'
+ depends 'kernel'
+
+ collect_data do
+ os collect_os
+ os_version kernel[:release]
+ end
+end
+```
+
+### Get Kernel Values
+
+The following Ohai example shows part of a file that gets initial kernel attribute values:
+
+```ruby
+Ohai.plugin(:Kernel) do
+ provides 'kernel', 'kernel/modules'
+
+ def init_kernel
+ kernel Mash.new
+ [['uname -s', :name], ['uname -r', :release],
+ ['uname -v', :version], ['uname -m', :machine]].each do |cmd, property|
+ so = shell_out(cmd)
+ kernel[property] = so.stdout.split($/)[0]
+ end
+ kernel
+ end
+
+ ...
+
+ collect_data(:darwin) do
+ kernel init_kernel
+ kernel[:os] = kernel[:name]
+
+ so = shell_out('sysctl -n hw.optional.x86_64')
+ if so.stdout.split($/)[0].to_i == 1
+ kernel[:machine] = 'x86_64'
+ end
+
+ modules = Mash.new
+ so = shell_out('kextstat -k -l')
+ so.stdout.lines do |line|
+ if line =~ /(\d+)\s+(\d+)\s+0x[0-9a-f]+\s+0x([0-9a-f]+)\s+0x[0-9a-f]+\s+([a-zA-Z0-9\.]+) \(([0-9\.]+)\)/
+ kext[$4] = { :version => $5, :size => $3.hex, :index => $1, :refcount => $2 }
+ end
+ end
+
+ kernel[:modules] = modules
+ end
+
+ ...
+```
diff --git a/content/packages.md b/content/packages.md
new file mode 100644
index 0000000..889ea96
--- /dev/null
+++ b/content/packages.md
@@ -0,0 +1,116 @@
++++
+title = "Chef Software Packages"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/packages.html"]
+product = ["automate", "client", "server", "habitat", "inspec", "supermarket", "workstation"]
+
+[menu]
+ [menu.overview]
+ title = "Packages"
+ identifier = "overview/packages_&_platforms/packages.md Packages"
+ parent = "overview/packages_&_platforms"
+ weight = 10
++++
+
+You can install packages for Chef Software products using platform-native package repositories.
+
+## Release channels
+
+{{< readfile file="content/reusable/md/release_channels.md" >}}
+
+## Package repositories
+
+The `stable` and `current` release channels support the following package repositories:
+
+- APT (Debian and Ubuntu platforms)
+- Yum (Enterprise Linux platforms)
+
+You can download Chef Software's GPG public key from [packages.chef.io](https://packages.chef.io/chef.asc).
+
+### Debian / Ubuntu
+
+To set up an APT package repository for Debian and Ubuntu platforms:
+
+1. Enable APT to fetch packages over HTTPS:
+
+ ```bash
+ sudo apt-get install apt-transport-https
+ ```
+
+1. Install the public key for Chef Software:
+
+ ```bash
+ wget -qO - https://packages.chef.io/chef.asc | sudo apt-key add -
+ ```
+
+1. Create the APT repository source file:
+
+ ```bash
+ echo "deb https://packages.chef.io/repos/apt/ main" > chef-.list
+ ```
+
+ Replace:
+
+ - `` with the release channel: `stable` or `current`.
+ - `` with the appropriate distribution name. For example:
+
+ - for Debian 9: `stretch`
+ - for Debian 10: `buster`
+ - for Debian 11: `bullseye`
+ - for Ubuntu 18.04: `bionic`
+ - for Ubuntu 20.04: `focal`
+
+1. Update the package repository list:
+
+ ```bash
+ sudo mv chef-stable.list /etc/apt/sources.list.d/
+ ```
+
+1. Update the cache for the package repository:
+
+ ```bash
+ sudo apt-get update
+ ```
+
+### Enterprise Linux
+
+{{< note >}}
+
+Starting in Chef Infra Client 18.6.2, we upgraded the GPG signing algorithm used to sign RHEL packages from SHA1 to SHA256. RHEL 9 no longer supports the less secure SHA1 hashes.
+
+{{< /note >}}
+
+Before you begin, verify that you have the `yum-utils` package installed.
+
+To set up a Yum package repository for Enterprise Linux platforms, follow these steps:
+
+1. Install the public key for Chef Software:
+
+ ```bash
+ sudo rpm --import https://packages.chef.io/chef.asc
+ ```
+
+1. Create the Yum repository source file:
+
+ ```bash
+ cat >chef-.repo <]
+ name=chef-
+ baseurl=https://packages.chef.io/repos/yum//el//\$basearch/
+ gpgcheck=1
+ # No auto-upgrade, as there are manual steps needed for Chef Infra Server upgrades
+ enabled=0
+ EOL
+ ```
+
+ Replace:
+
+ - `` with the release channel: `stable` or `current`.
+ - `` with the Enterprise Linux version.
+
+1. Update the package repository list:
+
+ ```bash
+ sudo yum-config-manager --add-repo chef-stable.repo
+ ```
diff --git a/content/partials.md b/content/partials.md
new file mode 100644
index 0000000..e664308
--- /dev/null
+++ b/content/partials.md
@@ -0,0 +1,46 @@
++++
+title = "Partials"
+gh_repo = "chef-web-docs"
+
+product = ["client", "workstation"]
+
+[menu]
+ [menu.infra]
+ title = "Partials"
+ identifier = "chef_infra/resources/custom_resources/partials"
+ parent = "chef_infra/resources/custom_resources"
+ weight = 40
++++
+
+[InfoQ article](https://www.infoq.com/news/2020/05/chef-infra-16/)
+
+Resource partials are a way of allowing resources to share common code. We recommend using partials any time you need to share code across three or more resources.
+
+If you have three resources all which require the properties, `user` and `group` to be set. Instead of writing those property definitions in each of those files, you can write the property definition in one file and include it in the three resources.
+
+The `use` method works similarly to the Ruby `require_relative` command.
+
+Write the common properties and place them in a folder within the resources folder. This will stop Chef from considering them to be full resources.
+
+```ruby
+# resources/_partial/_user.rb
+property :user,
+ String,
+ default: 'haproxy'
+
+property :group, String
+ String,
+ default: 'haproxy'
+```
+
+Then include them in each of the three resources with the use directive:
+
+```ruby
+# resources/backend.rb
+use '_partial/_user'
+```
+
+```ruby
+# resources/frontend.rb
+use '_partial/_user'
+```
diff --git a/content/platform_overview.md b/content/platform_overview.md
new file mode 100644
index 0000000..08d85d3
--- /dev/null
+++ b/content/platform_overview.md
@@ -0,0 +1,176 @@
++++
+title = "Platform Overview"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/platform_overview.html"]
+product = ["automate", "client", "server", "habitat", "inspec", "workstation"]
+
+[menu]
+ [menu.overview]
+ title = "Platform Overview"
+ identifier = "overview/platform_overview.md Platform Overview"
+ parent = "overview"
+ weight = 10
++++
+
+Chef is an automation company. Ever since it was founded in 2008, we've
+been bringing together developers and system administrators with our
+namesake product, Chef Infra. Over the years, what we mean by automation
+has expanded. Today, Chef has a complete automation solution for both
+infrastructure and applications that takes you all the way from
+development to production. Here's the complete Chef solution.
+
+{{< figure src="/images/automate_architecture.svg" width=500 alt="Diagram of Chef Automate architecture.">}}
+
+## Chef Infra
+
+{{< readfile file="content/reusable/md/chef.md" >}}
+
+### Using Chef Workstation
+
+[Chef Workstation](/workstation/) allows you to author cookbooks and administer your
+infrastructure. Chef Workstation runs on the computer you use everyday,
+whether it's Linux, macOS, or Windows.
+
+Chef Workstation ships with Cookstyle, ChefSpec, Chef InSpec, and Test
+Kitchen testing tools. With them, you can make sure your Chef Infra code
+does what you intended before you deploy it to environments used by
+others, such as staging or production.
+
+When you write your code, you use resources to describe your
+infrastructure. A resource corresponds to some piece of infrastructure,
+such as a file, a template, or a package. Each resource declares what
+state a part of the system should be in, but not how to get there. Chef
+Infra handles these complexities for you. Chef Infra provides many
+resources that are ready for you to use. You can also utilize resources
+shipped in community cookbooks, or write your own resources specific to
+your infrastructure.
+
+A Chef Infra recipe is a file that groups related resources, such as
+everything needed to configure a web server, database server, or a load
+balancer. A Chef Infra cookbook provides structure to your recipes and,
+in general, helps you stay organized.
+
+The Chef Workstation includes other command line tools for interacting
+with Chef Infra. These include knife for interacting with the Chef Infra
+Server, and chef for interacting with your local chef code repository
+(chef-repo).
+
+### Uploading your code to Chef Infra Server
+
+Once you're done developing and testing code on your local workstation,
+you can upload it to the [Chef Infra Server](/server/). The Chef Infra Server acts
+as a hub for configuration data. It stores cookbooks, the policies that
+are applied to the systems in your infrastructure and metadata that
+describes each system. The knife command lets you communicate with the
+Chef Infra Server from your workstation. For example, you use it to
+upload your cookbooks.
+
+### Configuring nodes with Chef Infra Client
+
+Chef Infra is constructed so that most of the computational effort
+occurs on the nodes rather than on the Chef Infra Server. A node
+represents any system you manage and is typically a virtual machine,
+container instance, or physical server. Basically, it's any compute
+resource in your infrastructure that's managed by Chef Infra. All nodes
+have Chef Infra Client installed on them, and Chef Infra Client is
+available for multiple platforms including Linux, macOS, Windows, AIX,
+and Solaris.
+
+Periodically, Chef Infra Client contacts the Chef Infra Server to
+retrieve the latest cookbooks. If (and only if) the current state of the
+node doesn't conform to what the cookbook says it should be, Chef Infra
+Client executes the cookbook instructions. This iterative process
+ensures that the network as a whole converges to the state envisioned by
+business policy.
+
+## Chef Habitat
+
+[Chef Habitat](/habitat/) offers a new approach to deploying applications called
+application automation. Application automation means that the automation
+is packaged with the application and travels with it, no matter where
+that application is deployed. The unit of deployment becomes the
+application and its associated automation. The runtime environment,
+whether it's a container, bare metal, or PaaS doesn't in any way
+define the application.
+
+Chef Habitat is comprised of a packaging format and a supervisor. The
+format defines Chef Habitat packages, which are isolated, immutable, and
+auditable. The Chef Habitat supervisor knows how to take the packages
+and run them. It's aware of the package's peer relationships, its
+upgrade strategy, and security policies.
+
+## Chef InSpec
+
+[Chef InSpec](/inspec/) is an open-source testing framework with a human- and
+machine-readable language for specifying compliance, security and policy
+requirements. When compliance is expressed as code, you can integrate it
+into your deployment pipeline and automatically test for adherence to
+security policies.
+
+Chef InSpec code can run in multiple platforms. You can execute the same
+set of tests locally, with remote commands that use SSH or WinRM, or
+with external mechanisms such as the Docker API.
+
+With Chef InSpec, you can do more than ensure that your physical servers
+are in compliance. You can, for example, assess data in a database or
+inspect the configuration of virtual resources by using their API.
+
+To get a sense of how the Chef InSpec language works, here are some
+examples. This Chef InSpec rule ensures that insecure services and
+protocols, such as telnet, aren't used.
+
+```ruby
+describe package('telnetd') do
+ it { should_not be_installed }
+end
+
+describe inetd_conf do
+ its('telnet') { should eq nil }
+end
+```
+
+## Chef Automate
+
+[Chef Automate](/automate/) provides a full suite of enterprise capabilities for node
+visibility and compliance. Chef Automate integrates with the open-source
+products Chef Infra Client, Chef InSpec and Chef Habitat. Chef Automate
+comes with comprehensive 24x7 support services for the entire platform,
+including open source components.
+
+Chef Automate gives you a full-stack continuous compliance and security,
+as well as visibility into your applications and infrastructure.
+
+### Nodes
+
+Chef Automate gives you a data warehouse that accepts input from Chef Infra Server, Chef Habitat, and Chef Automate workflow and compliance.
+It provides views into operational and workflow events.
+There is a query language available through the UI and customizable dashboards.
+
+Here is an example of the Chef Automate dashboard.
+
+{{< figure src="/images/automate-dashboard.png" width=700 alt="Chef Automate dashboard showing the status of nodes monitored with Chef Automate." >}}
+
+### Compliance
+
+Chef Automate creates customizable reports that identify compliance
+issues, security risks, and outdated software. You can write your own
+compliance rules in Chef InSpec, or you can get started by using
+built-in profiles, which are predefined rule sets for a variety of
+security frameworks, such as Center for Internet Security (CIS)
+benchmarks, included as part of Chef Automate.
+
+For information on the integrated reporting capabilities in Chef Automate, see [Compliance Overview](/automate/reports/).
+
+### High availability
+
+Chef Automate includes a high-availability Chef Infra Server with fault
+tolerance, immediately consistent search results, and accurate real-time
+data about your infrastructure. Chef Automate also provides a graphical
+management console for the Chef Infra Server.
+
+## Learning More
+
+If you're interested in getting hands-on experience, go to
+the [Learn Chef site](https://learn.chef.io) for tutorials, information about formal
+training classes and community resources.
diff --git a/content/platforms.md b/content/platforms.md
new file mode 100644
index 0000000..e11955a
--- /dev/null
+++ b/content/platforms.md
@@ -0,0 +1,274 @@
++++
+title = "Supported platforms"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/platforms.html", "/supported_platforms.html"]
+product = ["automate", "client", "server", "habitat", "inspec", "workstation"]
+
+[menu]
+ [menu.overview]
+ title = "Supported platforms"
+ identifier = "overview/packages_&_platforms/platforms.md Platforms"
+ parent = "overview/packages_&_platforms"
+ weight = 20
++++
+
+Chef software is supported on the operating systems (platforms)
+listed below. To see which versions of our software we currently
+support, see the [Supported Versions](/versions/) page.
+
+## Support
+
+We offer two levels of support for platforms (operating systems), [Commercial Support]({{< relref "#commercial-support">}}) and [Community Support]({{< relref "#community-support" >}}).
+
+### Commercial support
+
+Commercial support for platforms is part of paid maintenance contracts with Chef Software. Support contracts allow you to open tickets and receive service level agreement (SLA) assistance from our support desk. Commercially supported platforms are extensively tested as part of Chef's development and release process. Commercial support follows the lifecycle of the underlying operating system vendor.
+
+Commercial support is limited to the platforms listed in the "Commercial Support" tables--platforms not listed in these tables are unsupported.
+
+### Community support
+
+Community support for platforms means that members of the Chef community have contributed to these platforms and Chef doesn't actively work to maintain this functionality. Chef doesn't explicitly test community supported platforms as part of the development and release process.
+
+Many of these platforms are forks, clones, or otherwise derivative of platforms that Chef commercially supports. Continued functionality for these platforms is likely, but not guaranteed. Unsupported platforms may have missing or non-operative functionality. As always, we welcome community contributions from anyone looking to expand community support for platforms in Chef products.
+
+### Support for derived platforms
+
+Chef doesn't explicitly test or provide builds for derived distributions other than those in our supported platform list. However, if the derived distribution is a direct rebuild of the originating distribution and hasn't diverged in functionality or packaged dependencies, Chef will support our customers through our normal channels.
+
+## Platforms
+
+The sections below list the platforms that Chef Software supports.
+
+### Chef Automate
+
+#### Commercial support
+
+Commercial support for the [Chef Automate](/automate/system_requirements/) is available for platforms that use:
+
+- a Linux kernel version of 3.2 or greater
+- `systemd` as the init system
+- `useradd`
+- `curl` or `wget`
+
+### Chef Automate HA
+
+#### Commercial support
+
+See the [Chef Automate HA supported platforms](/automate/ha_on_premises_deployment_prerequisites/#software-requirements)
+documentation for a list of supported platforms for Chef Automate HA.
+
+### Chef Backend
+
+#### Commercial support
+
+The following table lists the commercially supported platforms for Chef Backend, which is the high-availability solution for Chef Infra Server.
+
+| Platform | Architecture | Version |
+| --- | --- | --- |
+| CentOS | `x86_64` | `6.x`, `7.x`, `8.x` |
+| Oracle Enterprise Linux | `x86_64` | `7.x`, `8.x` |
+| Red Hat Enterprise Linux | `x86_64` | `6.x`, `7.x`, `8.x` |
+| SUSE Linux Enterprise Server | `x86_64` | `12.x` |
+| Ubuntu (LTS releases) | `x86_64` | `16.04`, `18.04` |
+
+#### Derived platforms
+
+The following table lists supported derived platforms and versions for Chef Infra Server.
+
+See our policy on [support for derived platforms](#support-for-derived-platforms) for more information.
+
+| Platform | Architecture | Version | Parent platform |
+| --- | --- | --- | --- |
+| AlmaLinux | `x86_64` | `8.x` | CentOS |
+| Rocky Linux | `x86_64` | `8.x` | CentOS |
+
+### Chef Infra Client
+
+#### Commercial support
+
+The following table lists the commercially supported platforms and versions for Chef Infra Client.
+
+| Platform | Architecture | Version |
+| --- | --- | --- |
+| AIX | `powerpc` | `7.1` (TL5 SP2 or higher, recommended), `7.2`, `7.3` |
+| Amazon Linux | `x86_64`, `aarch64` | `2.x`, `2023` |
+| CentOS | `x86_64`, `ppc64le`, `ppc64`, `aarch64` | `7.x` |
+| Debian | `x86_64` | `10`, `11` |
+| FreeBSD | `amd64` | `13.x` |
+| macOS | `x86_64` (12.x only), `aarch64` | `12.x`, `13.x`, `14.x` |
+| Oracle Enterprise Linux | `x86_64`, `aarch64` | `7.x`, `8.x` |
+| Red Hat Enterprise Linux | `x86_64`, `ppc64le` (7.x only), `ppc64` (7.x only), `aarch64`, `s390x` (7.x / 8.x only) | `7.x`, `8.x`, `9.x` |
+| Rocky Linux | `x86_64` | `8.x`, `9.x` |
+| Solaris | `sparc`, `i86pc` | `11.3` (16.17.4 and later only), `11.4` |
+| SUSE Linux Enterprise Server | `x86_64`, `aarch64` (15.x only), `s390x` | `12`, `15` |
+| Ubuntu (LTS releases) | `x86_64`,`aarch64` (18.x and above) | `16.04`, `18.04`, `20.04`, `22.04` |
+| Windows | `x86_64` | `2016`, `10` (all channels except "insider" builds), `2019` (Long-term servicing channel (LTSC), both Desktop Experience and Server Core), `11`, `2022` |
+
+#### Derived platforms
+
+The following table lists supported derived platforms and versions for Chef Infra Client.
+
+See our policy on [support for derived platforms](#support-for-derived-platforms) for more information.
+
+| Platform | Architecture | Version | Parent platform |
+| --- | --- | --- | --- |
+| AlmaLinux | `x86_64`, `aarch64` | `8.x` | CentOS |
+
+#### Community support
+
+The following platforms are supported only using the community.
+
+| Platform | Architecture | Version |
+| --- | --- | --- |
+| Alibaba Cloud Linux | `x86_64` | 2.x |
+| Arch Linux | `x86_64` | current version |
+| Arista EOS | `x86_64` | current non-EOL releases |
+| CentOS Stream | `x86_64`, `aarch64` | current non-EOL releases |
+| Clear Linux | `x86_64` | current non-EOL releases |
+| Cumulus Linux | `x86_64` | current non-EOL releases |
+| Fedora | `x86_64`, `aarch64` | current non-EOL releases |
+| Kali Linux | `x86_64` | current non-EOL releases |
+| Linux Mint | `x86_64` | current non-EOL releases |
+| OpenIndiana Hipster | `x86_64` | current non-EOL releases |
+| openSUSE | `x86_64`, `aarch64` | `15.x` |
+| Pop!_OS | `x86_64` | current non-EOL releases |
+| Raspberry Pi OS | `aarch64` | current non-EOL releases |
+| SmartOS | `x86_64` | current non-EOL releases |
+| SUSE Linux Enterprise Desktop | `x86_64`, `aarch64` (15.x only) | `12.x`, `15.x` |
+| Ubuntu | `x86_64`, `aarch64` | Current non-LTS releases |
+| Virtuozzo | `x86_64` | Current non-LTS releases |
+| Windows | `x64` | `Windows Server, Semi-annual channel (SAC) (Server Core only)` |
+| XCP-ng | `x86_64` | 8.x |
+
+### Chef Infra Server
+
+#### Commercial support
+
+{{< readfile file="content/server/reusable/md/adopted_platforms_server.md" >}}
+
+### Chef InSpec
+
+#### Commercial support
+
+The following table lists the commercially supported platforms and versions for Chef InSpec.
+
+{{< readfile file="content/inspec/reusable/md/support_commercial_platforms.md" >}}
+
+#### Derived platforms
+
+The following table lists supported derived platforms and versions for Chef InSpec.
+
+See our policy on [support for derived platforms](#support-for-derived-platforms) for more information.
+
+{{< readfile file="content/inspec/reusable/md/support_derived_platforms.md" >}}
+
+### Chef Manage
+
+#### Commercial support
+
+The following table lists the commercially supported platforms for Chef Manage.
+
+| Platform | Architecture | Version |
+| --- | --- | --- |
+| CentOS | `x86_64` | `7.x` |
+| Oracle Enterprise Linux | `x86_64` | `7.x`, `8.x` |
+| Red Hat Enterprise Linux | `x86_64` | `7.x`, `8.x` |
+| Ubuntu (LTS releases) | `x86_64` | `16.04`, `18.04`, `20.04` |
+
+#### Derived platforms
+
+The following table lists supported derived platforms and versions for Chef Manage.
+
+See our policy on [support for derived platforms](#support-for-derived-platforms) for more information.
+
+| Platform | Architecture | Version | Parent platform |
+| --- | --- | --- | --- |
+| AlmaLinux | `x86_64` | `8.x` | CentOS |
+| Rocky Linux | `x86_64` | `8.x` | CentOS |
+
+### Chef Workstation
+
+#### Commercial support
+
+The following table lists the commercially supported platforms and versions for the Chef Workstation.
+
+{{< readfile file = "content/workstation/reusable/md/workstation_supported_platforms.md" >}}
+
+#### Derived platforms
+
+The following table lists supported derived platforms and versions for Chef Workstation.
+
+See our policy on [support for derived platforms](#support-for-derived-platforms) for more information.
+
+{{< readfile file = "content/workstation/reusable/md/workstation_supported_derived_platforms.md" >}}
+
+## Platform end-of-life policy
+
+Chef's products on particular platforms and versions reach end-of-life on the same date as the vendor EOL milestone for that operating system.
+Because different vendors use different terminology, the following table clarifies when Chef products are end-of-life according to those vendors' terms.
+
+| Platform | Vendor End-of-Life |
+| --- | --- |
+| Amazon Linux | End of Life |
+| Apple macOS | Apple supports the last three macOS releases, for example: 10.15, 11.x, and 12.x. Apple doesn't officially publish EOL dates. |
+| Debian | End of maintenance updates |
+| Enterprise Linux (covers Red Hat Enterprise Linux, CentOS) | End of Production 3 |
+| FreeBSD | End of Life |
+| IBM AIX | IBM End of Support Date |
+| Windows | End of Extended Support |
+| Oracle Enterprise Linux | Premier Support Ends |
+| Oracle Solaris | Premier Support Ends |
+| SUSE Linux Enterprise Server | General Support Ends |
+| Ubuntu Linux | End of maintenance updates |
+
+At Chef's option, additional support may be provided to customers beyond
+the vendor end-of-life in the above table. As such, the following table
+indicates upcoming product end-of-life dates for particular platforms.
+On the Chef end-of-life date, Chef discontinues building software for
+that platform and version.
+
+| Platform and Version | Vendor End-of-Life Date | Chef End-of-Life Date |
+| --- | --- | --- |
+| Amazon Linux 201X | Dec 31st, 2020 | Dec 31st, 2020 |
+| Amazon Linux 2 | Jun 30, 2025 | Jun 30, 2025 |
+| Amazon Linux 2023 | Mar 15, 2028 | Mar 15, 2028 |
+| Apple macOS 11 | Sep 26, 2023 | Sep 26, 2023 |
+| Apple macOS 12 | No current planned EOL date | No current planned EOL date |
+| CentOS 6 | Nov 30, 2020 | Nov 30, 2020 |
+| CentOS 7 | Jun 30, 2024 | Jun 30, 2024 |
+| CentOS 8 | Dec 31, 2021 | Dec 31, 2021 |
+| Debian 7 (Wheezy) | May 31st, 2018 | May 31st, 2018 |
+| Debian 8 (Jessie) | June 6th, 2020 | June 6th, 2020 |
+| Debian 9 (Stretch) | June 30th, 2022 | June 30th, 2022 |
+| Debian 10 (Buster) | June 30th, 2024 | June 30th, 2024 |
+| Debian 11 (Bullseye) | June 30th, 2026 | June 30th, 2026 |
+| FreeBSD 10-STABLE | October 31, 2018 | October 31, 2018 |
+| FreeBSD 11-STABLE | September 30, 2021 | September 30, 2021 |
+| IBM AIX 7.1 | Apr 30, 2023 | Apr 30, 2023 |
+| IBM AIX 7.2 | No current planned EOL date | No current planned EOL date |
+| IBM AIX 7.3 | Nov 30, 2026 | Nov 30, 2026 |
+| Oracle Enterprise Linux 5 | June 30, 2017 | December 31, 2017 |
+| Oracle Enterprise Linux 6 | March 31, 2021 | March 31, 2021 |
+| Oracle Enterprise Linux 7 | December 1, 2024 | December 1, 2024 |
+| Oracle Enterprise Linux 8 | July 1, 2029 | July 1, 2029 |
+| Oracle Solaris 11.3 | January 30, 2021 | No current planned EOL date |
+| Oracle Solaris 11.4 | November 31, 2031 | November 31, 2031 |
+| Red Hat Enterprise Linux 5 | April 30, 2017 | December 31, 2017 |
+| Red Hat Enterprise Linux 6 | November 30, 2020 | November 30, 2020 |
+| Red Hat Enterprise Linux 7 | June 30, 2024 | June 30, 2024 |
+| Red Hat Enterprise Linux 8 | May 31, 2029 | May 31, 2029 |
+| Red Hat Enterprise Linux 9 | May 31, 2032 | May 31, 2032 |
+| SUSE Linux Enterprise Server 11 | March 31, 2019 | March 31, 2019 |
+| SUSE Linux Enterprise Server 12 | October 31, 2024 | October 31, 2024 |
+| Ubuntu Linux 12.04 LTS | April 30, 2017 | April 30, 2017 |
+| Ubuntu Linux 14.04 LTS | April 30, 2019 | April 30, 2019 |
+| Ubuntu Linux 16.04 LTS | April 30, 2021 | April 30, 2021 |
+| Ubuntu Linux 18.04 LTS | May 31, 2023 | May 31, 2023 |
+| Ubuntu Linux 20.04 LTS | Apr 02, 2025 | Apr 02, 2025 |
+| Ubuntu Linux 22.04 LTS | Apr 01, 2027 | Apr 01, 2027 |
+| Windows Server 2008 (SP2)/R2 (SP1) | January 13, 2015 | January 14, 2020 |
+| Windows Server 2012/2012 R2 | October 10, 2023 | October 10, 2023 |
+| Windows Server 2016 | November 11, 2027 | November 11, 2027 |
+| Windows Server 2019 | October 10, 2028 | October 10, 2028 |
diff --git a/content/plugin_community.md b/content/plugin_community.md
new file mode 100644
index 0000000..6e16e34
--- /dev/null
+++ b/content/plugin_community.md
@@ -0,0 +1,104 @@
++++
+title = "Community Plugins"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = "/plugin_community.html"
+
+[menu]
+ [menu.infra]
+ title = "Community Plugins"
+ identifier = "chef_infra/extension_apis/ohai_plugins/Community Plugins"
+ parent = "chef_infra/extension_apis/ohai_plugins"
+ weight = 20
++++
+
+
+This page lists plugins for Ohai plugins and Chef Infra Client handlers
+that are developed and maintained by the Chef community.
+
+## Ohai
+
+{{< readfile file="content/reusable/md/ohai_summary.md" >}}
+
+The following Ohai plugins are available from the open source community:
+
+
Adds some useful Dell server information to Ohai. For example, service tag, express service code, storage info, or RAC info. To use this plugin, OMSA and SMBIOS applications need to be installed.
Adds the ability for Ohai to use Windows Management Instrumentation (WMI) to discover useful information about software that's installed on any node that's running Windows.
Adds the ability for Ohai to query using Windows Management Instrumentation (WMI) to get information about all services that are registered on a node that's running Windows.
+
+
+
+
+## Handlers
+
+{{< readfile file="content/reusable/md/handler.md" >}}
+
+{{< readfile file="content/reusable/md/handler_community_handlers.md" >}}
diff --git a/content/policy.md b/content/policy.md
new file mode 100644
index 0000000..22a2141
--- /dev/null
+++ b/content/policy.md
@@ -0,0 +1,50 @@
++++
+title = "About Policy"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/policy.html"]
+product = ["client", "server"]
+
+[menu]
+ [menu.infra]
+ title = "About Policy"
+ identifier = "chef_infra/policyfiles/policy.md About Policy"
+ parent = "chef_infra/policyfiles"
+ weight = 10
++++
+
+{{< readfile file="content/reusable/md/policy_summary.md" >}}
+
+## Cookbook Versions
+
+{{< readfile file="content/reusable/md/cookbooks_version.md" >}}
+
+For more information about cookbook versioning, see [About Cookbook
+Versioning](/cookbook_versioning/)
+
+## Data Bags (Secrets)
+
+{{< readfile file="content/reusable/md/data_bag.md" >}}
+
+For more information about data bags, see [About Data
+Bags](/data_bags/)
+
+## Environments
+
+{{< readfile file="content/reusable/md/environment.md" >}}
+
+For more information about environments, see [About
+Environments](/environments/)
+
+## Roles
+
+{{< readfile file="content/reusable/md/role.md" >}}
+
+For more information about roles, see [About Roles](/roles/)
+
+## Policyfile
+
+{{< readfile file="content/reusable/md/policyfile_summary.md" >}}
+
+For more information about Policyfile, see [About
+Policyfile](/policyfile/)
diff --git a/content/policyfile.md b/content/policyfile.md
new file mode 100644
index 0000000..6892a90
--- /dev/null
+++ b/content/policyfile.md
@@ -0,0 +1,410 @@
++++
+title = "About Policyfiles"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/policyfile.html"]
+product = ["client", "server"]
+
+[menu]
+ [menu.infra]
+ title = "About Policyfiles"
+ identifier = "chef_infra/policyfiles/policyfile.md About Policyfiles"
+ parent = "chef_infra/policyfiles"
+ weight = 20
++++
+
+{{< readfile file="content/reusable/md/policyfile_summary.md" >}}
+
+## Why Policyfiles?
+
+Policyfiles make it easier to test and promote code safely with a simpler interface. Using a Policyfile improves the user experience and resolves real-world problems that some workflows built around Chef Infra must deal with. The following sections discuss in more detail some of the good reasons to use Policyfile, including:
+
+* Focus the workflow on the entire system
+* Safer development workflows
+* Less expensive computation
+* Code visibility
+* Role mutability
+* Cookbook mutability
+* Replaces Berkshelf and the environment cookbook pattern
+
+### Focused System Workflows
+
+The knife command line tool maps closely to the Chef Infra Server API and the objects defined by it, such as roles, environments, run-lists, cookbooks, data bags, or nodes. Chef Infra Client assembles these pieces at run-time and configures a host to do useful work.
+
+Policyfile focuses that workflow onto the entire system, rather than the individual components. For example, Policyfile describes whole systems, whereas each individual revision of the `Policyfile.lock.json` file uploaded to the Chef Infra Server describes a part of that system, inclusive of roles, environments, cookbooks, and the other Chef Infra Server objects necessary to configure that part of the system.
+
+### Safer Workflows
+
+Policyfile encourages safer workflows by making it easier to publish development versions of cookbooks to the Chef Infra Server without the risk of mutating the production versions and without requiring a complicated versioning scheme to work around cookbook mutability issues. Roles are mutable and those changes are applied only to the nodes specified by the policy. Policyfile doesn't require any changes to your normal workflows. Use the same repositories you are already using, the same cookbooks, and workflows. Policyfile will prevent an updated cookbook or role from being applied immediately to all machines.
+
+### Code Visibility
+
+When running Chef Infra without a Policyfile, the exact set of cookbooks that are applied to a node is defined by:
+
+* The node's `run_list` property
+* Any roles that are present in the node's run-list or recursively included by those roles
+* The environment, which may restrict the set of valid cookbook versions for a node based on a variety of constraint operators
+* Dependencies, as defined by each cookbook's metadata
+* Dependency resolution picks the "best" set of cookbooks that meet dependency and environment criteria
+
+These conditions are re-evaluated every time Chef Infra Client runs, which can make it harder to know which cookbooks will be run by Chef Infra Client or what the effects of updating a role or uploading a new cookbook will be.
+
+Policyfile simplifies this behavior by computing the cookbook set on the workstation, and then producing a readable document of that solution: a `Policyfile.lock.json` file. This pre-computed file is uploaded to the Chef Infra Server, and is then used in each Chef Infra Client run that's managed by that particular policy name and policy group.
+
+### Less Expensive Computation
+
+When running Chef Infra without Policyfile, the Chef Infra Server loads dependency data for all known versions of all known cookbooks, and then runs an expensive computation to determine the correct set.
+
+Policyfile moves this computation to the workstation, where it's done less frequently.
+
+### Role and Environment Mutability
+
+When running Chef Infra without Policyfile roles and environments are global objects. Changes to roles and environments are applied immediately to any node that contains that role in its run-list or belong to a particular environment. This can make it hard to update roles and environments and in some use cases discourages using them at all.
+
+Policyfile effectively replaces roles and environments. Policyfile files are versioned automatically and new versions are applied to systems only when promoted.
+
+### Cookbook Mutability
+
+When running Chef without Policyfile, existing versions of cookbooks are mutable. This is convenient for many use cases, especially if users upload in-development cookbook revisions to the Chef Infra Server. But this sometimes creates issues that are similar to role mutability by allowing those cookbook changes to be applied immediately to nodes that use that cookbook. Users account for this by rigorous testing processes to ensure that only fully integrated cookbooks are ever published. This process does enforce good development habits, but at the same time it shouldn't be a required part of a workflow that ends with publishing an in-development cookbook to the Chef Infra Server for testing against real nodes. Policyfile solves this issue by using a cookbook publishing API for the Chef Infra Server that doesn't provide cookbook mutability. Name collisions are prevented by storing cookbooks by name and an opaque identifier that's computed from the content of the cookbook itself.
+
+For example, name/version collisions can occur when users temporarily fork an upstream cookbook. Even if the user contributes their change and the maintainer is responsive, there may be a period of time where the user needs their fork to make progress. This situation presents a versioning dilemma: if the user doesn't update their own version, they must overwrite the existing copy of that cookbook on the Chef Infra Server, wheres if they do update the version number it might conflict with the version number of the future release of that upstream cookbook.
+
+#### Opaque IDs
+
+The opaque identifier that's computed from the content of a cookbook is the only place where an opaque identifier is necessary. When working with Policyfile, be sure to:
+
+* Use the same names and version constraints as normal in the `Policyfile.rb` file
+* Use the same references to cookbooks pulled from Chef Supermarket
+* Use the same branch, tag, and revision patterns for cookbooks pulled from git
+* Use the same paths for cookbooks pulled from disk
+
+Extra metadata about the cookbook is stored and included in Chef Infra Server API responses and in the `Policyfile.lock.json` file, including the source of a cookbook (Chef Supermarket, git, local disk, etc.), as well as any upstream identifiers, such as git revisions. For cookbooks that are loaded from the local disk that are in a git repo, the upstream URL, current revision ID, and the state of the repo are stored also.
+
+The opaque identifier is mostly behind the scenes and is only visible once published to the Chef Infra Server. Cookbooks that are uploaded to the Chef Infra Server may have extended version numbers such as `1.0.0-dev`.
+
+### Environment Cookbooks
+
+Policyfile replaces the environment cookbook pattern that's often required by Berkshelf, along with a dependency solver and fetcher. That said, Policyfile doesn't replace all Berkshelf scenarios.
+
+## Knife Commands
+
+The following knife commands used to set the policy group and policy name on the Chef Infra Server. For example:
+
+```bash
+knife node policy set test-node 'test-policy-group-name' 'test-policy-name'
+```
+
+## Policyfile.rb
+
+{{< readfile file="content/reusable/md/policyfile_rb.md" >}}
+
+### Syntax
+
+{{< readfile file="content/reusable/md/policyfile_rb_syntax.md" >}}
+
+### Settings
+
+{{< readfile file="content/reusable/md/policyfile_rb_settings.md" >}}
+
+### Example
+
+{{< readfile file="content/reusable/md/policyfile_rb_example.md" >}}
+
+## client.rb Settings
+
+The following settings may be configured in the client.rb file for use with Policyfile:
+
+`named_run_list`
+
+: The run-list associated with a Policyfile.
+
+`policy_group`
+
+: The name of a policy group that exists on the Chef Infra Server. `policy_name` must also be specified.
+
+`policy_name`
+
+: The name of a policy, as identified by the `name` setting in a `Policyfile.rb` file. `policy_group` must also be specified.
+
+`use_policyfile`
+
+: Chef Infra Client automatically checks the configuration, node JSON, and the stored node on the Chef Infra Server to determine if Policyfile files are being used, and then automatically updates this flag. Default value: `false`.
+
+## knife bootstrap
+
+A node may be bootstrapped to use Policyfile files. Use the following options as part of the bootstrap command:
+
+`--policy-group POLICY_GROUP`
+
+: The name of a policy group that exists on the Chef Infra Server.
+
+`--policy-name POLICY_NAME`
+
+: The name of a policy, as identified by the `name` setting in a `Policyfile.rb` file.
+
+For a customized bootstrap process, add `policy_name` and `policy_group` to the first-boot JSON file that's passed to Chef Infra Client.
+
+## knife search
+
+The `policy_name` and `policy_group` settings for a node are stored as searchable attributes and as such are available when using a fuzzy matching search pattern. For example: `knife search dev` will return nodes that are part of the `dev` policy group.
+
+## Test w/Kitchen
+
+Kitchen may be used to test Policyfile files. Add the following to kitchen.yml:
+
+```yaml
+provisioner:
+ name: chef_zero
+```
+
+A named run-list may be used for each suite:
+
+```yaml
+suites:
+ - name: client
+ provisioner:
+ named_run_list: test_client_recipe
+ - name: server
+ provisioner:
+ named_run_list: test_server_recipe
+```
+
+or globally:
+
+```yaml
+provisioner:
+ name: chef_zero
+ named_run_list: integration_test_run_list
+```
+
+or testing with policies for each suite, once the Policyfile files are available in your repo:
+
+```yaml
+suites:
+ - name: defaultmega
+ provisioner:
+ policyfile: policies/default.rb
+ - name: defaultultra
+ provisioner:
+ policyfile: policies/defaulttwo.rb
+```
+
+{{< note >}}
+
+As `chef_zero` explicitly tests outside the context of a Chef Infra Server, the `policy_groups` concept isn't applicable. The value of `policy_group` during a converge will be set to `local`.
+
+{{< /note >}}
+
+## chef Commands
+
+{{< readfile file="content/reusable/md/policyfile_chef_commands.md" >}}
+
+### chef clean-policy-cookbooks
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_clean_policy_cookbooks.md" >}}
+
+#### Syntax
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_clean_policy_cookbooks_syntax.md" >}}
+
+#### Options
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_clean_policy_cookbooks_options.md" >}}
+
+### chef clean-policy-revisions
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_clean_policy_revisions.md" >}}
+
+#### Syntax
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_clean_policy_revisions_syntax.md" >}}
+
+#### Options
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_clean_policy_revisions_options.md" >}}
+
+### chef delete-policy
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_delete_policy.md" >}}
+
+#### Syntax
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_delete_policy_syntax.md" >}}
+
+#### Options
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_delete_policy_options.md" >}}
+
+### chef delete-policy-group
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_delete_policy_group.md" >}}
+
+#### Syntax
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_delete_policy_group_syntax.md" >}}
+
+#### Options
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_delete_policy_group_options.md" >}}
+
+### chef diff
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_diff.md" >}}
+
+#### Syntax
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_diff_syntax.md" >}}
+
+#### Options
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_diff_options.md" >}}
+
+#### Examples
+
+##### Compare current lock to latest commit on latest branch
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_diff_current_lock_latest_branch.md" >}}
+
+##### Compare current lock with latest commit on master branch
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_diff_current_lock_master_branch.md" >}}
+
+##### Compare current lock to specified revision
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_diff_current_lock_specified_revision.md" >}}
+
+##### Compare lock on master branch to lock on revision
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_diff_master_lock_revision_lock.md" >}}
+
+##### Compare lock for version with latest commit on master branch
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_diff_version_lock_master_branch.md" >}}
+
+##### Compare current lock with latest lock for policy group
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_diff_current_lock_policy_group.md" >}}
+
+##### Compare locks for two policy group
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_diff_two_policy_groups.md" >}}
+
+### chef export
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_export.md" >}}
+
+#### Syntax
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_export_syntax.md" >}}
+
+#### Options
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_export_options.md" >}}
+
+### chef generate policyfile
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_generate_policyfile.md" >}}
+
+#### Syntax
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_generate_policyfile_syntax.md" >}}
+
+#### Options
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_generate_policyfile_options.md" >}}
+
+### chef generate repo
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_generate_repo.md" >}}
+
+{{< note >}}
+
+This subcommand requires using one (or more) of the options (below) to support Policyfile files.
+
+{{< /note >}}
+
+#### Syntax
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_generate_repo_syntax.md" >}}
+
+#### Options
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_generate_repo_options.md" >}}
+
+### chef install
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_install.md" >}}
+
+#### Syntax
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_install_syntax.md" >}}
+
+#### Options
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_install_options.md" >}}
+
+#### Policyfile.lock.json
+
+{{< readfile file="content/reusable/md/policyfile_lock_json.md" >}}
+
+{{< readfile file="content/reusable/md/policyfile_lock_json_example.md" >}}
+
+### chef push
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_push.md" >}}
+
+#### Syntax
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_push_syntax.md" >}}
+
+#### Options
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_push_options.md" >}}
+
+### chef push-archive
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_push_archive.md" >}}
+
+#### Syntax
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_push_archive_syntax.md" >}}
+
+#### Options
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_push_archive_options.md" >}}
+
+### chef show-policy
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_show_policy.md" >}}
+
+#### Syntax
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_show_policy_syntax.md" >}}
+
+#### Options
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_show_policy_options.md" >}}
+
+### chef undelete
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_undelete.md" >}}
+
+#### Syntax
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_undelete_syntax.md" >}}
+
+#### Options
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_undelete_options.md" >}}
+
+### chef update
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_update.md" >}}
+
+#### Syntax
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_update_syntax.md" >}}
+
+#### Options
+
+{{< readfile file="content/workstation/reusable/md/ctl_chef_update_options.md" >}}
diff --git a/content/proxies.md b/content/proxies.md
new file mode 100644
index 0000000..1e13895
--- /dev/null
+++ b/content/proxies.md
@@ -0,0 +1,196 @@
++++
+title = "Working with Proxies"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+aliases = ["/proxies.html"]
+
+[menu]
+ [menu.infra]
+ title = "Working with Proxies"
+ identifier = "chef_infra/install/proxies.md Working with Proxies"
+ parent = "chef_infra/install"
+ weight = 30
++++
+
+In an environment that requires proxies to reach the Internet, many Chef
+commands won't work until they're configured correctly. To configure
+Chef to work in an environment that requires proxies, set the
+`http_proxy`, `https_proxy`, `ftp_proxy`, and/or `no_proxy` environment
+variables to specify the proxy settings using a lowercase value.
+
+## Windows
+
+{{< readfile file="content/reusable/md/proxy_windows.md" >}}
+
+## Linux
+
+To determine the current proxy server on the macOS and Linux platforms,
+check the environment variables. Run the following:
+
+```bash
+env | grep -i http_proxy
+```
+
+If an environment variable is set, it **MUST** be lowercase. If it's
+not, add a lowercase version of that proxy variable to the shell (for example
+`~/.bashrc`) using one (or more) the following commands.
+
+For HTTP:
+
+```bash
+export http_proxy=http://myproxy.com:3168
+```
+
+For HTTPS:
+
+```bash
+export https_proxy=http://myproxy.com:3168
+```
+
+For FTP:
+
+```bash
+export ftp_proxy=ftp://myproxy.com:3168
+```
+
+## Proxy Settings
+
+Proxy settings are defined in configuration files for Chef Infra Client
+and for knife and may be specified for HTTP, HTTPS, and FTP.
+
+### HTTP
+
+Use the following settings in the client.rb or config.rb files for
+environments that use an HTTP proxy:
+
+
+
+
+
+
+
+
+
Setting
+
Description
+
+
+
+
+
http_proxy
+
The proxy server for HTTP connections. Default value: nil.
+
+
+
http_proxy_pass
+
The password for the proxy server when the proxy server is using an HTTP connection. Default value: nil.
+
+
+
http_proxy_user
+
The user name for the proxy server when the proxy server is using an HTTP connection. Default value: nil.
+
+
+
+
+### HTTPS
+
+Use the following settings in the client.rb or config.rb files for
+environments that use an HTTPS proxy:
+
+
+
+
+
+
+
+
+
Setting
+
Description
+
+
+
+
+
https_proxy
+
The proxy server for HTTPS connections. Default value: nil.
+
+
+
https_proxy_pass
+
The password for the proxy server when the proxy server is using an HTTPS connection. Default value: nil.
+
+
+
https_proxy_user
+
The user name for the proxy server when the proxy server is using an HTTPS connection. Default value: nil.
+
+
+
+
+### FTP
+
+Use the following settings in the client.rb or config.rb files for
+environments that use an FTP proxy:
+
+
+
+
+
+
+
+
+
Setting
+
Description
+
+
+
+
+
ftp_proxy
+
The proxy server for FTP connections.
+
+
+
ftp_proxy_pass
+
The password for the proxy server when the proxy server is using an FTP connection. Default value: nil.
+
+
+
ftp_proxy_user
+
The user name for the proxy server when the proxy server is using an FTP connection. Default value: nil.
+
+
+
+
+### No Proxy
+
+The `no_proxy` setting is used to specify addresses for which the proxy
+shouldn't be used. This can be a single address or a comma-separated
+list of addresses.
+
+Example:
+
+```ruby
+no_proxy 'test.example.com,test.example2.com,test.example3.com'
+```
+
+{{< note >}}
+
+Wildcard matching may be used in the `no_proxy` list---such as
+`no_proxy '*.*.example.*'`---however, many situations require hostnames
+to be specified explicitly (that's, "without wildcards").
+
+{{< /note >}}
+
+## Environment Variables
+
+Consider the following for situations where environment variables are
+used to set the proxy:
+
+- Proxy settings may not be honored by all applications. For example,
+ proxy settings may be ignored by the underlying application when
+ specifying a `ftp` source with a `remote_file` resource. Consider a
+ workaround. For example, in this situation try doing a `wget` with
+ an `ftp` URL instead.
+- Proxy settings may be honored inconsistently by applications. For
+ example, the behavior of the `no_proxy` setting may not work with
+ certain applications when wildcards are specified. Consider
+ specifying the hostnames without using wildcards.
+
+### ENV
+
+{{< readfile file="content/reusable/md/proxy_env.md" >}}
diff --git a/content/quick_start.md b/content/quick_start.md
new file mode 100644
index 0000000..01fa80d
--- /dev/null
+++ b/content/quick_start.md
@@ -0,0 +1,54 @@
++++
+title = "Quick Start"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/quick_start.html"]
+product = ["client", "server"]
+
+[menu]
+ [menu.infra]
+ title = "Quick Start"
+ identifier = "chef_infra/overview/quick_start.md Quick Start"
+ parent = "chef_infra/overview"
+ weight = 40
++++
+
+The quickest way to get started using Chef Infra is to install Chef Workstation and create your first Chef Infra Cookbook:
+
+1. Install Chef Workstation from [Chef Downloads](https://www.chef.io/downloads).
+
+2. Generate a Chef Infra repository with an example cookbook:
+
+ ```bash
+ chef generate repo my_first_repo
+ ```
+
+ where `my_first_repo` is an arbitrary name for your Chef Infra repository.
+
+3. Navigate to the `cookbooks/example` directory.
+
+4. Update the `cookbooks/example/recipes/default.rb` recipe in
+ the generated cookbook to contain:
+
+ ```ruby
+ file "#{ENV['HOME']}/test.txt" do
+ content 'This file was created by Chef Infra!'
+ end
+ ```
+
+5. Run Chef Infra Client using the `default.rb` recipe:
+
+ ```bash
+ chef-client --local-mode --override-runlist example
+ ```
+
+This creates a file named `test.txt` at the home path on your computer. Open that file and it will say `This file was created by Chef Infra!`.
+
+- Delete the file, run Chef Infra Client again, and Chef Infra will replace the file.
+- Change the string in the file, run Chef Infra Client again, and Chef Infra will make the string in the file the same as the string in the recipe.
+- Change the string in the recipe, run Chef Infra Client again, and Chef Infra will update that string to be the same as the one in the recipe.
+
+There's a lot more that Chef Infra can do, obviously, but that was super easy!
+
+- See for more detailed setup scenarios.
+- Keep reading for more information about setting up a workstation, configuring Test Kitchen to run virtual environments, setting up a more detailed cookbook, resources, and more.
diff --git a/content/recipes.md b/content/recipes.md
new file mode 100644
index 0000000..fd0d838
--- /dev/null
+++ b/content/recipes.md
@@ -0,0 +1,543 @@
++++
+title = "About Recipes"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/recipes.html", "essentials_cookbook_recipes.html"]
+
+[menu]
+ [menu.infra]
+ title = "About Recipes"
+ identifier = "chef_infra/cookbook_reference/recipes/recipes.md About Recipes"
+ parent = "chef_infra/cookbook_reference/recipes"
+ weight = 10
++++
+
+{{< readfile file="content/reusable/md/cookbooks_recipe.md" >}}
+
+## Recipe Attributes
+
+{{< readfile file="content/reusable/md/cookbooks_attribute.md" >}}
+
+{{< note >}}
+
+{{< readfile file="content/reusable/md/notes_see_attributes_overview.md" >}}
+
+{{< /note >}}
+
+## Environment Variables
+
+In UNIX, a process environment is a set of key-value pairs made
+available to a process. Programs expect their environment to contain
+information required for the program to run. The details of how these
+key-value pairs are accessed depends on the API of the language being
+used.
+
+If processes is started by using the **execute** or **script** resources
+(or any of the resources based on those two resources, such as
+**bash**), use the `environment` attribute to alter the environment that
+will be passed to the process.
+
+```bash
+bash 'env_test' do
+ code <<-EOF
+ echo $FOO
+EOF
+ environment ({ 'FOO' => 'bar' })
+end
+```
+
+The only environment being altered is the one being passed to the child
+process that's started by the **bash** resource. This won't affect
+the Chef Infra Client environment or any child processes.
+
+## Work with Recipes
+
+The following sections show approaches to working with recipes.
+
+### Use Data Bags
+
+{{< readfile file="content/reusable/md/data_bag.md" >}}
+
+The contents of a data bag can be loaded into a recipe. For example, a
+data bag named `apps` and a data bag item named `my_app`:
+
+```json
+{
+ "id": "my_app",
+ "repository": "git://github.com/company/my_app.git"
+}
+```
+
+can be accessed in a recipe, like this:
+
+```ruby
+my_bag = data_bag_item('apps', 'my_app')
+```
+
+The data bag item's keys and values can be accessed with a Hash:
+
+```ruby
+my_bag['repository'] #=> 'git://github.com/company/my_app.git'
+```
+
+#### Secret Keys
+
+{{< readfile file="content/reusable/md/data_bag_encryption_secret_key.md" >}}
+
+#### Store Keys on Nodes
+
+An encryption key can also be stored in an alternate file on the nodes
+that need it and specify the path location to the file inside an
+attribute; however, `EncryptedDataBagItem.load` expects to see the
+actual secret as the third argument, rather than a path to the secret
+file. In this case, you can use `EncryptedDataBagItem.load_secret` to
+slurp the secret file contents and then pass them:
+
+```ruby
+# inside your attribute file:
+# default[:mysql][:secretpath] = 'C:\\chef\\any_secret_filename'
+#
+# inside your recipe:
+# look for secret in file pointed to by mysql attribute :secretpath
+mysql_secret = Chef::EncryptedDataBagItem.load_secret('#{node['mysql']['secretpath']}')
+mysql_creds = Chef::EncryptedDataBagItem.load('passwords', 'mysql', mysql_secret)
+mysql_creds['pass'] # will be decrypted
+```
+
+### Assign Dependencies
+
+If a cookbook has a dependency on a recipe that's located in another
+cookbook, that dependency must be declared in the metadata.rb file for
+that cookbook using the `depends` keyword.
+
+{{< note >}}
+
+Declaring cookbook dependencies isn't required with chef-solo.
+
+{{< /note >}}
+
+For example, if the following recipe is included in a cookbook named
+`my_app`:
+
+```ruby
+include_recipe 'apache2::mod_ssl'
+```
+
+Then the metadata.rb file for that cookbook would have:
+
+```ruby
+depends 'apache2'
+```
+
+### Include Recipes
+
+{{< readfile file="content/reusable/md/cookbooks_recipe_include_in_recipe.md" >}}
+
+### Reload Attributes
+
+Attributes sometimes depend on actions taken from within recipes, so it
+may be necessary to reload a given attribute from within a recipe. For
+example:
+
+```ruby
+ruby_block 'some_code' do
+ block do
+ node.from_file(run_context.resolve_attribute('COOKBOOK_NAME', 'ATTR_FILE'))
+ end
+ action :nothing
+end
+```
+
+### Use Ruby
+
+Anything that can be done with Ruby can be used within a recipe, such as
+expressions (if, unless, etc.), case statements, loop statements,
+arrays, hashes, and variables. In Ruby, the conditionals `nil` and
+`false` are false; every other conditional is `true`.
+
+#### Assign a value
+
+A variable uses an equals sign (`=`) to assign a value.
+
+To assign a value to a variable:
+
+```ruby
+package_name = 'apache2'
+```
+
+#### Use Case Statement
+
+A case statement can be used to compare an expression, and then execute
+the code that matches.
+
+To select a package name based on platform:
+
+```ruby
+package 'apache2' do
+ case node['platform']
+ when 'centos', 'redhat', 'fedora', 'suse'
+ package_name 'httpd'
+ when 'debian', 'ubuntu'
+ package_name 'apache2'
+ when 'arch'
+ package_name 'apache'
+ end
+ action :install
+end
+```
+
+#### Check Conditions
+
+An if expression can be used to check for conditions (true or false).
+
+To check for condition only for Debian and Ubuntu platforms:
+
+```ruby
+if platform?('debian', 'ubuntu')
+ # do something if node['platform'] is debian or ubuntu
+else
+ # do other stuff
+end
+```
+
+#### Execute Conditions
+
+An unless expression can be used to execute code when a condition
+returns a false value (effectively, an unless expression is the opposite
+of an if statement).
+
+To use an expression to execute when a condition returns a false value:
+
+```ruby
+unless node['platform_version'] == '5.0'
+ # do stuff on everything but 5.0
+end
+```
+
+#### Loop over Array
+
+A loop statement is used to execute a block of code one (or more) times.
+A loop statement is created when `.each` is added to an expression that
+defines an array or a hash. An array is an integer-indexed collection of
+objects. Each element in an array can be associated with and referred to
+by an index.
+
+To loop over an array of package names by platform:
+
+```ruby
+['apache2', 'apache2-mpm'].each do |p|
+ package p
+end
+```
+
+#### Loop over Hash
+
+A hash is a collection of key-value pairs. Indexing for a hash is done
+using arbitrary keys of any object (as opposed to the indexing done by
+an array). The syntax for a hash is: `key => "value"`.
+
+To loop over a hash of gem package names:
+
+```ruby
+{ 'fog' => '0.6.0', 'highline' => '1.6.0' }.each do |g, v|
+ gem_package g do
+ version v
+ end
+end
+```
+
+### Apply to Run-lists
+
+A recipe must be assigned to a run-list using the appropriate name, as
+defined by the cookbook directory and namespace. For example, a cookbook
+directory has the following structure:
+
+```text
+cookbooks/
+ apache2/
+ recipes/
+ default.rb
+ mod_ssl.rb
+```
+
+There are two recipes: a default recipe (that has the same name as the
+cookbook) and a recipe named `mod_ssl`. The syntax that applies a recipe
+to a run-list is similar to:
+
+```ruby
+{
+ 'run_list': [
+ 'recipe[cookbook_name::default_recipe]',
+ 'recipe[cookbook_name::recipe_name]'
+ ]
+}
+```
+
+where `::default_recipe` is implied (and doesn't need to be specified).
+On a node, these recipes can be assigned to a node's run-list similar
+to:
+
+```ruby
+{
+ 'run_list': [
+ 'recipe[apache2]',
+ 'recipe[apache2::mod_ssl]'
+ ]
+}
+```
+
+#### Chef Infra Server
+
+Use knife to add a recipe to the run-list for a node. For example:
+
+```bash
+knife node run list add NODENAME "recipe[apache2]"
+```
+
+More than one recipe can be added:
+
+```bash
+% knife node run list add NODENAME "recipe[apache2],recipe[mysql],role[ssh]"
+```
+
+which creates a run-list similar to:
+
+```ruby
+run_list:
+ recipe[apache2]
+ recipe[mysql]
+ role[ssh]
+```
+
+#### chef-solo
+
+Use a JSON file to pass run-list details to chef-solo as long as the
+cookbook in which the recipe is located is available to the system on
+which chef-solo is running. For example, a file named `dna.json`
+contains the following details:
+
+```json
+{
+ "run_list": ["recipe[apache2]"]
+}
+```
+
+To add the run-list to the node, enter the following:
+
+```bash
+sudo chef-solo -j /etc/chef/dna.json
+```
+
+### Use Search Results
+
+{{< readfile file="content/reusable/md/search.md" >}}
+
+The results of a search query can be loaded into a recipe. For example,
+a simple search query (in a recipe) might look like this:
+
+```ruby
+search(:node, 'attribute:value')
+```
+
+A search query can be assigned to variables and then used elsewhere in a
+recipe. For example, to search for all nodes that have a role assignment
+named `webserver`, and then render a template which includes those role
+assignments:
+
+```ruby
+webservers = search(:node, 'role:webserver')
+
+template '/tmp/list_of_webservers' do
+ source 'list_of_webservers.erb'
+ variables(webservers: webservers)
+end
+```
+
+### Use Tags
+
+{{< readfile file="content/reusable/md/chef_tags.md" >}}
+
+{{< readfile file="content/reusable/md/cookbooks_recipe_tags.md" >}}
+
+### End Chef Infra Client Run
+
+Sometimes it may be necessary to stop processing a recipe and/or stop
+processing the entire Chef Infra Client run. There are a few ways to do
+this:
+
+- Use the `return` keyword to stop processing a recipe based on a
+ condition, but continue processing a Chef Infra Client run
+- Use the `raise` keyword to stop a Chef Infra Client run by
+ triggering an unhandled exception
+- Use a `rescue` block in Ruby code
+- Use an [exception handler](/handlers/)
+
+The following sections show various approaches to ending a Chef Infra
+Client run.
+
+#### return Keyword
+
+The `return` keyword can be used to stop processing a recipe based on a
+condition, but continue processing a Chef Infra Client run. For example:
+
+```ruby
+file '/tmp/name_of_file' do
+ action :create
+end
+
+return if platform?('windows')
+
+package 'name_of_package' do
+ action :install
+end
+```
+
+where `platform?('windows')` is the condition set on the `return`
+keyword. When the condition is met, stop processing the recipe. This
+approach is useful when there is no need to continue processing, such as
+when a package can't be installed. In this situation, it's OK for a
+recipe to stop processing.
+
+#### raise Keyword
+
+In certain situations it may be useful to stop a Chef Infra Client run
+entirely by using an unhandled exception. The `raise` keyword can be used
+to stop a Chef Infra Client run in both the compile and execute phases.
+
+{{< note >}}
+
+You may also see code that uses the `fail` keyword, which behaves the same
+but is discouraged and will result in Cookstyle warnings.
+
+{{< /note >}}
+
+Use these keywords in a recipe---but outside of any resource blocks---to
+trigger an unhandled exception during the compile phase. For example:
+
+```ruby
+file '/tmp/name_of_file' do
+ action :create
+end
+
+raise "message" if platform?('windows')
+
+package 'name_of_package' do
+ action :install
+end
+```
+
+where `platform?('windows')` is the condition that will trigger the
+unhandled exception.
+
+Use these keywords in the **ruby_block** resource to trigger an
+unhandled exception during the execute phase. For example:
+
+```ruby
+ruby_block "name" do
+ block do
+ # Ruby code with a condition, for example if ::File.exist?(::File.join(path, "/tmp"))
+ raise "message" # for example "Ordering issue with file path, expected foo"
+ end
+end
+```
+
+Use these keywords in a class. For example:
+
+```ruby
+class CustomError < StandardError; end
+```
+
+and then later on:
+
+```ruby
+def custom_error
+ raise CustomError, "error message"
+end
+```
+
+or:
+
+```ruby
+def custom_error
+ raise CustomError, "error message"
+end
+```
+
+#### Rescue Blocks
+
+Since recipes are written in Ruby, they can be written to attempt to
+handle error conditions using the `rescue` block.
+
+For example:
+
+```ruby
+begin
+ dater = data_bag_item(:basket, 'flowers')
+rescue Net::HTTPClientException
+ # maybe some retry code here?
+ raise 'message_to_be_raised'
+end
+```
+
+where `data_bag_item` makes an HTTP request to the Chef Infra Server to
+get a data bag item named `flowers`. If there is a problem, the request
+will return a `Net::HTTPClientException`. The `rescue` block can be used
+to try to retry or otherwise handle the situation. If the `rescue` block
+is unable to handle the situation, then the `raise` keyword is used to
+specify the message to be raised.
+
+### node.run_state
+
+Use `node.run_state` to stash transient data during a Chef Infra Client
+run. This data may be passed between resources, and then evaluated
+during the execution phase. `run_state` is an empty Hash that's always
+discarded at the end of a Chef Infra Client run.
+
+For example, the following recipe will install the Apache web server,
+randomly choose PHP or Perl as the scripting language, and then install
+that scripting language:
+
+```ruby
+package 'httpd' do
+ action :install
+end
+
+ruby_block 'randomly_choose_language' do
+ block do
+ if Random.rand > 0.5
+ node.run_state['scripting_language'] = 'php'
+ else
+ node.run_state['scripting_language'] = 'perl'
+ end
+ end
+end
+
+package 'scripting_language' do
+ package_name lazy { node.run_state['scripting_language'] }
+ action :install
+end
+```
+
+where:
+
+- The **ruby_block** resource declares a `block` of Ruby code that's
+ run during the execution phase of a Chef Infra Client run
+- The `if` statement randomly chooses PHP or Perl, saving the choice
+ to `node.run_state['scripting_language']`
+- When the **package** resource has to install the package for the
+ scripting language, it looks up the scripting language and uses the
+ one defined in `node.run_state['scripting_language']`
+- `lazy {}` ensures that the **package** resource evaluates this
+ during the execution phase of a Chef Infra Client run (as opposed to
+ during the compile phase)
+
+When this recipe runs, Chef Infra Client will print something like the
+following:
+
+```bash
+* ruby_block[randomly_choose_language] action run
+ - execute the ruby block randomly_choose_language
+
+* package[scripting_language] action install
+ - install version 5.3.3-27.el6_5 of package php
+```
diff --git a/content/reference.md b/content/reference.md
deleted file mode 100644
index 421656d..0000000
--- a/content/reference.md
+++ /dev/null
@@ -1,32 +0,0 @@
-+++
-title = "Habitat command reference"
-
-[menu.reference]
-title = "Habitat reference"
-+++
-
-With Habitat-based Chef Infra Client builds, you can use the following common functions for troubleshooting.
-
-## List the gems used with Habitat builds
-
-```sh
-sudo hab pkg exec chef/chef-infra-client gem list
-```
-
-## List all the gems used with Habitat builds
-
-```sh
-sudo hab pkg exec chef/chef-infra-client gem list --all
-```
-
-## Get the install path
-
-```sh
-sudo hab pkg exec chef/chef-infra-client gem env
-```
-
-## Get Ruby version
-
-```sh
-/hab/bin/hab pkg exec core/ruby3_1 ruby -v
-```
diff --git a/content/resources/_index.md b/content/resources/_index.md
new file mode 100644
index 0000000..076013e
--- /dev/null
+++ b/content/resources/_index.md
@@ -0,0 +1,368 @@
++++
+title = "All Infra Resources"
+draft = false
+description = "This reference describes each of the resources available to Chef Infra Client, including a list of actions, properties, and usage examples."
+gh_repo = "chef-web-docs"
+aliases = ["/resource_reference.html", "/resources.html", "resource_examples.html", "/chef/resources.html"]
+data_path = ["infra","resources"]
+layout = "infra_resources_all"
+toc_layout = "infra_resources_all_toc"
+[cascade]
+ product = ["client"]
+
+[menu]
+ [menu.infra]
+ title = "All Resources (Single Page)"
+ identifier = "chef_infra/resources/All Resources"
+ parent = "chef_infra/resources"
+ weight = 60
++++
+
+
+
+
+
+
+
+
+This reference describes each of the resources available to Chef Infra Client, including a list of actions, properties, and usage examples.
+
+## Common Functionality
+
+The properties and actions in this section apply to all resources.
+
+### Actions
+
+The following actions may be used with any resource:
+
+`:nothing`
+
+: {{< readfile file="content/reusable/md/resources_common_actions_nothing.md" >}}
+
+#### Examples
+
+The following examples show how to use common actions in a recipe.
+
+**Use the :nothing action**
+
+{{< readfile file="content/reusable/md/resource_service_use_nothing_action.md" >}}
+
+### Properties
+
+The following properties are common to every resource:
+
+`ignore_failure`
+: **Ruby Type:** true, false | **Default Value:** `false`
+
+ Continue running a recipe if a resource fails for any reason.
+
+`retries`
+: **Ruby Type:** Integer | **Default Value:** `0`
+
+ The number of attempts to catch exceptions and retry the resource.
+
+`retry_delay`
+: **Ruby Type:** Integer | **Default Value:** `2`
+
+ The retry delay (in seconds).
+
+`sensitive`
+: **Ruby Type:** true, false | **Default Value:** `false`
+
+ Ensure that sensitive resource data isn't logged by Chef Infra Client.
+
+#### Examples
+
+The following examples show how to use common properties in a recipe.
+
+**Use the ignore_failure common property**
+
+{{< readfile file="content/reusable/md/resource_package_use_ignore_failure_attribute.md" >}}
+
+**Use the retries and retry_delay common properties**
+
+{{< readfile file="content/reusable/md/resource_service_use_retries_properties.md" >}}
+
+### Guards
+
+{{< readfile file="content/reusable/md/resources_common_guards.md" >}}
+
+#### Properties
+
+{{< readfile file="content/reusable/md/resources_common_guards_properties.md" >}}
+
+#### Arguments
+
+{{< readfile file="content/reusable/md/resources_common_guards_arguments.md" >}}
+
+#### not_if Examples
+
+The following examples show how to use `not_if` as a condition in a recipe:
+
+**Create a file, but not if an attribute has a specific value**
+
+The following example shows how to use the `not_if` condition to create
+a file based on a template and using the presence of an attribute value
+on the node to specify the condition:
+
+```ruby
+template '/tmp/somefile' do
+ mode '0755'
+ source 'somefile.erb'
+ not_if { node['some_value'] }
+end
+```
+
+**Create a file with a Ruby block, but not if "/etc/passwd" exists**
+
+The following example shows how to use the `not_if` condition to create
+a file based on a template and then Ruby code to specify the condition:
+
+```ruby
+template '/tmp/somefile' do
+ mode '0755'
+ source 'somefile.erb'
+ not_if do
+ ::File.exist?('/etc/passwd')
+ end
+end
+```
+
+
+**Create a file with Ruby block that has curly braces, but not if "/etc/passwd" exists**
+
+The following example shows how to use the `not_if` condition to create
+a file based on a template and using a Ruby block (with curly braces) to
+specify the condition:
+
+```ruby
+template '/tmp/somefile' do
+ mode '0755'
+ source 'somefile.erb'
+ not_if { ::File.exist?('/etc/passwd') }
+end
+```
+
+**Create a file using a string, but not if "/etc/passwd" exists**
+
+The following example shows how to use the `not_if` condition to create
+a file based on a template and using a string to specify the condition:
+
+```ruby
+template '/etc/some_config' do
+ mode '0640'
+ source 'some_config.erb'
+ not_if 'some_app --check-config'
+end
+```
+
+#### only_if Examples
+
+The following examples show how to use `only_if` as a condition in a recipe:
+
+**Create a file, but only if an attribute has a specific value**
+
+The following example shows how to use the `only_if` condition to create
+a file based on a template and using the presence of an attribute on the
+node to specify the condition:
+
+```ruby
+template '/tmp/somefile' do
+ mode '0755'
+ source 'somefile.erb'
+ only_if { node['some_value'] }
+end
+```
+
+**Create a file with a Ruby block, but only if "/etc/passwd" doesn't exist**
+
+The following example shows how to use the `only_if` condition to create
+a file based on a template, and then use Ruby to specify a condition:
+
+```ruby
+template '/etc/some_app/some_config' do
+ mode '0640'
+ source 'some_config.erb'
+ only_if { ::File.exist?('/etc/some_app/') }
+end
+```
+
+**Create a file using a string, but only if "/etc/passwd" exists**
+
+The following example shows how to use the `only_if` condition to create
+a file based on a template and using a string to specify the condition:
+
+```ruby
+template '/tmp/somefile' do
+ mode '0755'
+ source 'somefile.erb'
+ only_if 'test -f /etc/passwd'
+end
+```
+
+### Guard Interpreters
+
+{{< readfile file="content/reusable/md/resources_common_guard_interpreter.md" >}}
+
+#### Attributes
+
+{{< readfile file="content/reusable/md/resources_common_guard_interpreter_attributes.md" >}}
+
+#### Inheritance
+
+{{< readfile file="content/reusable/md/resources_common_guard_interpreter_attributes_inherit.md" >}}
+
+#### Examples
+
+{{< readfile file="content/reusable/md/resources_common_guard_interpreter_example_default.md" >}}
+
+### Lazy Evaluation
+
+{{< readfile file="content/reusable/md/resources_common_lazy_evaluation.md" >}}
+
+### Notifications
+
+{{< readfile file="content/reusable/md/resources_common_notification.md" >}}
+
+#### Timers
+
+{{< readfile file="content/reusable/md/resources_common_notification_timers.md" >}}
+
+#### Notifies
+
+{{< readfile file="content/reusable/md/resources_common_notification_notifies.md" >}}
+
+{{< readfile file="content/reusable/md/resources_common_notification_notifies_syntax.md" >}}
+
+##### Examples
+
+The following examples show how to use the `notifies` notification in a recipe.
+
+**Delay notifications**
+
+{{< readfile file="content/reusable/md/resource_template_notifies_delay.md" >}}
+
+**Notify immediately**
+
+{{< readfile file="content/reusable/md/resource_template_notifies_run_immediately.md" >}}
+
+**Notify multiple resources**
+
+{{< readfile file="content/reusable/md/resource_template_notifies_multiple_resources.md" >}}
+
+**Notify in a specific order**
+
+{{< readfile file="content/reusable/md/resource_execute_notifies_specific_order.md" >}}
+
+**Reload a service**
+
+{{< readfile file="content/reusable/md/resource_template_notifies_reload_service.md" >}}
+
+**Restart a service when a template is modified**
+
+{{< readfile file="content/reusable/md/resource_template_notifies_restart_service_when_template_modified.md" >}}
+
+**Send notifications to multiple resources**
+
+{{< readfile file="content/reusable/md/resource_template_notifies_send_notifications_to_multiple_resources.md" >}}
+
+**Execute a command using a template**
+
+{{< readfile file="content/reusable/md/resource_execute_command_from_template.md" >}}
+
+**Restart a service, and then notify a different service**
+
+{{< readfile file="content/reusable/md/resource_service_restart_and_notify.md" >}}
+
+**Restart one service before restarting another**
+
+{{< readfile file="content/reusable/md/resource_before_notification_restart.md" >}}
+
+**Notify when a remote source changes**
+
+{{< readfile file="content/reusable/md/resource_remote_file_transfer_remote_source_changes.md" >}}
+
+#### Subscribes
+
+{{< readfile file="content/reusable/md/resources_common_notification_subscribes.md" >}}
+
+{{< readfile file="content/reusable/md/resources_common_notification_subscribes_syntax.md" >}}
+
+##### Examples
+
+The following examples show how to use the `subscribes` notification in a recipe.
+
+**Prevent restart and reconfigure if configuration is broken**
+
+{{< readfile file="content/reusable/md/resource_execute_subscribes_prevent_restart_and_reconfigure.md" >}}
+
+**Reload a service using a template**
+
+{{< readfile file="content/reusable/md/resource_service_subscribes_reload_using_template.md" >}}
+
+**Stash a file in a data bag**
+
+The following example shows how to use the **ruby_block** resource to
+stash a BitTorrent file in a data bag so that it can be distributed to
+nodes in the organization.
+
+```ruby
+# the following code sample comes from the ``seed`` recipe
+# in the following cookbook: https://github.com/mattray/bittorrent-cookbook
+
+ruby_block 'share the torrent file' do
+ block do
+ f = File.open(node['bittorrent']['torrent'], 'rb')
+ #read the .torrent file and base64 encode it
+ enc = Base64.encode64(f.read)
+ data = {
+ 'id' => bittorrent_item_id(node['bittorrent']['file']),
+ 'seed' => node['ipaddress'],
+ 'torrent' => enc,
+ }
+ item = Chef::DataBagItem.new
+ item.data_bag('bittorrent')
+ item.raw_data = data
+ item.save
+ end
+ action :nothing
+ subscribes :create, "bittorrent_torrent[#{node['bittorrent']['torrent']}]", :immediately
+end
+```
+
+### Relative Paths
+
+{{< readfile file="content/reusable/md/resources_common_relative_paths.md" >}}
+
+#### Examples
+
+{{< readfile file="content/reusable/md/resource_template_use_relative_paths.md" >}}
+
+### Run in Compile Phase
+
+{{< readfile file="content/reusable/md/resources_common_compile.md" >}}
+
+#### run_action
+
+{{< readfile file="content/reusable/md/resources_common_compile_begin.md" >}}
+
+### Atomic File Updates
+
+{{< readfile file="content/reusable/md/resources_common_atomic_update.md" >}}
+
+### Windows File Security
+
+{{< readfile file="content/reusable/md/resources_common_windows_security.md" >}}
+
+**Access Control Lists (ACLs)**
+
+{{< readfile file="content/reusable/md/resources_common_windows_security_acl.md" >}}
+
+**Inheritance**
+
+{{< readfile file="content/reusable/md/resources_common_windows_security_inherits.md" >}}
+
+## Resources
+
+The following resources are built into the Chef Infra Client:
diff --git a/content/resources/alternatives.md b/content/resources/alternatives.md
new file mode 100644
index 0000000..750210d
--- /dev/null
+++ b/content/resources/alternatives.md
@@ -0,0 +1,19 @@
++++
+title = "alternatives Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","alternatives"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "alternatives"
+ identifier = "chef_infra/resources/alternatives"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/apt_package.md b/content/resources/apt_package.md
new file mode 100644
index 0000000..495f6d5
--- /dev/null
+++ b/content/resources/apt_package.md
@@ -0,0 +1,19 @@
++++
+title = "apt_package Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","apt_package"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "apt_package"
+ identifier = "chef_infra/resources/apt_package"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/apt_preference.md b/content/resources/apt_preference.md
new file mode 100644
index 0000000..e39aedb
--- /dev/null
+++ b/content/resources/apt_preference.md
@@ -0,0 +1,19 @@
++++
+title = "apt_preference Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","apt_preference"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "apt_preference"
+ identifier = "chef_infra/resources/apt_preference"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/apt_repository.md b/content/resources/apt_repository.md
new file mode 100644
index 0000000..8ab8743
--- /dev/null
+++ b/content/resources/apt_repository.md
@@ -0,0 +1,19 @@
++++
+title = "apt_repository Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","apt_repository"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "apt_repository"
+ identifier = "chef_infra/resources/apt_repository"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/apt_update.md b/content/resources/apt_update.md
new file mode 100644
index 0000000..95e3767
--- /dev/null
+++ b/content/resources/apt_update.md
@@ -0,0 +1,19 @@
++++
+title = "apt_update Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","apt_update"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "apt_update"
+ identifier = "chef_infra/resources/apt_update"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/archive_file.md b/content/resources/archive_file.md
new file mode 100644
index 0000000..19c7c92
--- /dev/null
+++ b/content/resources/archive_file.md
@@ -0,0 +1,19 @@
++++
+title = "archive_file Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","archive_file"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "archive_file"
+ identifier = "chef_infra/resources/archive_file"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/bash.md b/content/resources/bash.md
new file mode 100644
index 0000000..1fdac85
--- /dev/null
+++ b/content/resources/bash.md
@@ -0,0 +1,19 @@
++++
+title = "bash Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","bash"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "bash"
+ identifier = "chef_infra/resources/bash"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/batch.md b/content/resources/batch.md
new file mode 100644
index 0000000..4418d3e
--- /dev/null
+++ b/content/resources/batch.md
@@ -0,0 +1,19 @@
++++
+title = "batch Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","batch"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "batch"
+ identifier = "chef_infra/resources/batch"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/bff_package.md b/content/resources/bff_package.md
new file mode 100644
index 0000000..15aa18b
--- /dev/null
+++ b/content/resources/bff_package.md
@@ -0,0 +1,19 @@
++++
+title = "bff_package Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","bff_package"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "bff_package"
+ identifier = "chef_infra/resources/bff_package"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/breakpoint.md b/content/resources/breakpoint.md
new file mode 100644
index 0000000..f4d5510
--- /dev/null
+++ b/content/resources/breakpoint.md
@@ -0,0 +1,19 @@
++++
+title = "breakpoint Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","breakpoint"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "breakpoint"
+ identifier = "chef_infra/resources/breakpoint"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/build_essential.md b/content/resources/build_essential.md
new file mode 100644
index 0000000..baf4db3
--- /dev/null
+++ b/content/resources/build_essential.md
@@ -0,0 +1,19 @@
++++
+title = "build_essential Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","build_essential"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "build_essential"
+ identifier = "chef_infra/resources/build_essential"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/cab_package.md b/content/resources/cab_package.md
new file mode 100644
index 0000000..b511059
--- /dev/null
+++ b/content/resources/cab_package.md
@@ -0,0 +1,19 @@
++++
+title = "cab_package Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","cab_package"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "cab_package"
+ identifier = "chef_infra/resources/cab_package"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/chef_acl.md b/content/resources/chef_acl.md
new file mode 100644
index 0000000..db74aa5
--- /dev/null
+++ b/content/resources/chef_acl.md
@@ -0,0 +1,19 @@
++++
+title = "chef_acl Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","chef_acl"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "chef_acl"
+ identifier = "chef_infra/resources/chef_acl"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/chef_client.md b/content/resources/chef_client.md
new file mode 100644
index 0000000..11eb91e
--- /dev/null
+++ b/content/resources/chef_client.md
@@ -0,0 +1,19 @@
++++
+title = "chef_client Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","chef_client"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "chef_client"
+ identifier = "chef_infra/resources/chef_client"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/chef_client_config.md b/content/resources/chef_client_config.md
new file mode 100644
index 0000000..5389c07
--- /dev/null
+++ b/content/resources/chef_client_config.md
@@ -0,0 +1,19 @@
++++
+title = "chef_client_config Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","chef_client_config"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "chef_client_config"
+ identifier = "chef_infra/resources/chef_client_config"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/chef_client_cron.md b/content/resources/chef_client_cron.md
new file mode 100644
index 0000000..ea46a68
--- /dev/null
+++ b/content/resources/chef_client_cron.md
@@ -0,0 +1,19 @@
++++
+title = "chef_client_cron Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","chef_client_cron"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "chef_client_cron"
+ identifier = "chef_infra/resources/chef_client_cron"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/chef_client_launchd.md b/content/resources/chef_client_launchd.md
new file mode 100644
index 0000000..6fa119a
--- /dev/null
+++ b/content/resources/chef_client_launchd.md
@@ -0,0 +1,19 @@
++++
+title = "chef_client_launchd Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","chef_client_launchd"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "chef_client_launchd"
+ identifier = "chef_infra/resources/chef_client_launchd"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/chef_client_scheduled_task.md b/content/resources/chef_client_scheduled_task.md
new file mode 100644
index 0000000..6fce1e7
--- /dev/null
+++ b/content/resources/chef_client_scheduled_task.md
@@ -0,0 +1,19 @@
++++
+title = "chef_client_scheduled_task Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","chef_client_scheduled_task"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "chef_client_scheduled_task"
+ identifier = "chef_infra/resources/chef_client_scheduled_task"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/chef_client_systemd_timer.md b/content/resources/chef_client_systemd_timer.md
new file mode 100644
index 0000000..b65cc56
--- /dev/null
+++ b/content/resources/chef_client_systemd_timer.md
@@ -0,0 +1,19 @@
++++
+title = "chef_client_systemd_timer Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","chef_client_systemd_timer"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "chef_client_systemd_timer"
+ identifier = "chef_infra/resources/chef_client_systemd_timer"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/chef_client_trusted_certificate.md b/content/resources/chef_client_trusted_certificate.md
new file mode 100644
index 0000000..94431a7
--- /dev/null
+++ b/content/resources/chef_client_trusted_certificate.md
@@ -0,0 +1,19 @@
++++
+title = "chef_client_trusted_certificate Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","chef_client_trusted_certificate"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "chef_client_trusted_certificate"
+ identifier = "chef_infra/resources/chef_client_trusted_certificate"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/chef_container.md b/content/resources/chef_container.md
new file mode 100644
index 0000000..073f46d
--- /dev/null
+++ b/content/resources/chef_container.md
@@ -0,0 +1,19 @@
++++
+title = "chef_container Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","chef_container"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "chef_container"
+ identifier = "chef_infra/resources/chef_container"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/chef_data_bag.md b/content/resources/chef_data_bag.md
new file mode 100644
index 0000000..af57c22
--- /dev/null
+++ b/content/resources/chef_data_bag.md
@@ -0,0 +1,19 @@
++++
+title = "chef_data_bag Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","chef_data_bag"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "chef_data_bag"
+ identifier = "chef_infra/resources/chef_data_bag"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/chef_data_bag_item.md b/content/resources/chef_data_bag_item.md
new file mode 100644
index 0000000..ab896b2
--- /dev/null
+++ b/content/resources/chef_data_bag_item.md
@@ -0,0 +1,19 @@
++++
+title = "chef_data_bag_item Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","chef_data_bag_item"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "chef_data_bag_item"
+ identifier = "chef_infra/resources/chef_data_bag_item"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/chef_environment.md b/content/resources/chef_environment.md
new file mode 100644
index 0000000..a9adbdf
--- /dev/null
+++ b/content/resources/chef_environment.md
@@ -0,0 +1,19 @@
++++
+title = "chef_environment Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","chef_environment"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "chef_environment"
+ identifier = "chef_infra/resources/chef_environment"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/chef_gem.md b/content/resources/chef_gem.md
new file mode 100644
index 0000000..c9ac574
--- /dev/null
+++ b/content/resources/chef_gem.md
@@ -0,0 +1,19 @@
++++
+title = "chef_gem Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","chef_gem"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "chef_gem"
+ identifier = "chef_infra/resources/chef_gem"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/chef_group.md b/content/resources/chef_group.md
new file mode 100644
index 0000000..2c0c20f
--- /dev/null
+++ b/content/resources/chef_group.md
@@ -0,0 +1,19 @@
++++
+title = "chef_group Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","chef_group"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "chef_group"
+ identifier = "chef_infra/resources/chef_group"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/chef_handler.md b/content/resources/chef_handler.md
new file mode 100644
index 0000000..93d8aec
--- /dev/null
+++ b/content/resources/chef_handler.md
@@ -0,0 +1,19 @@
++++
+title = "chef_handler Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","chef_handler"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "chef_handler"
+ identifier = "chef_infra/resources/chef_handler"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/chef_node.md b/content/resources/chef_node.md
new file mode 100644
index 0000000..1162b0e
--- /dev/null
+++ b/content/resources/chef_node.md
@@ -0,0 +1,19 @@
++++
+title = "chef_node Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","chef_node"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "chef_node"
+ identifier = "chef_infra/resources/chef_node"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/chef_organization.md b/content/resources/chef_organization.md
new file mode 100644
index 0000000..e7c03f4
--- /dev/null
+++ b/content/resources/chef_organization.md
@@ -0,0 +1,19 @@
++++
+title = "chef_organization Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","chef_organization"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "chef_organization"
+ identifier = "chef_infra/resources/chef_organization"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/chef_role.md b/content/resources/chef_role.md
new file mode 100644
index 0000000..a4eeddf
--- /dev/null
+++ b/content/resources/chef_role.md
@@ -0,0 +1,19 @@
++++
+title = "chef_role Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","chef_role"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "chef_role"
+ identifier = "chef_infra/resources/chef_role"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/chef_sleep.md b/content/resources/chef_sleep.md
new file mode 100644
index 0000000..d632961
--- /dev/null
+++ b/content/resources/chef_sleep.md
@@ -0,0 +1,19 @@
++++
+title = "chef_sleep Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","chef_sleep"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "chef_sleep"
+ identifier = "chef_infra/resources/chef_sleep"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/chef_user.md b/content/resources/chef_user.md
new file mode 100644
index 0000000..3e65895
--- /dev/null
+++ b/content/resources/chef_user.md
@@ -0,0 +1,19 @@
++++
+title = "chef_user Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","chef_user"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "chef_user"
+ identifier = "chef_infra/resources/chef_user"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/chef_vault_secret.md b/content/resources/chef_vault_secret.md
new file mode 100644
index 0000000..dc1b825
--- /dev/null
+++ b/content/resources/chef_vault_secret.md
@@ -0,0 +1,19 @@
++++
+title = "chef_vault_secret Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","chef_vault_secret"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "chef_vault_secret"
+ identifier = "chef_infra/resources/chef_vault_secret"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/chocolatey_config.md b/content/resources/chocolatey_config.md
new file mode 100644
index 0000000..73465c7
--- /dev/null
+++ b/content/resources/chocolatey_config.md
@@ -0,0 +1,19 @@
++++
+title = "chocolatey_config Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","chocolatey_config"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "chocolatey_config"
+ identifier = "chef_infra/resources/chocolatey_config"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/chocolatey_feature.md b/content/resources/chocolatey_feature.md
new file mode 100644
index 0000000..5d8d1d9
--- /dev/null
+++ b/content/resources/chocolatey_feature.md
@@ -0,0 +1,19 @@
++++
+title = "chocolatey_feature Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","chocolatey_feature"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "chocolatey_feature"
+ identifier = "chef_infra/resources/chocolatey_feature"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/chocolatey_installer.md b/content/resources/chocolatey_installer.md
new file mode 100644
index 0000000..c9a91b7
--- /dev/null
+++ b/content/resources/chocolatey_installer.md
@@ -0,0 +1,19 @@
++++
+title = "chocolatey_installer Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","chocolatey_installer"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "chocolatey_installer"
+ identifier = "chef_infra/resources/chocolatey_installer"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/chocolatey_package.md b/content/resources/chocolatey_package.md
new file mode 100644
index 0000000..0a4b993
--- /dev/null
+++ b/content/resources/chocolatey_package.md
@@ -0,0 +1,19 @@
++++
+title = "chocolatey_package Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","chocolatey_package"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "chocolatey_package"
+ identifier = "chef_infra/resources/chocolatey_package"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/chocolatey_source.md b/content/resources/chocolatey_source.md
new file mode 100644
index 0000000..41ae451
--- /dev/null
+++ b/content/resources/chocolatey_source.md
@@ -0,0 +1,19 @@
++++
+title = "chocolatey_source Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","chocolatey_source"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "chocolatey_source"
+ identifier = "chef_infra/resources/chocolatey_source"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/cookbook_file.md b/content/resources/cookbook_file.md
new file mode 100644
index 0000000..979a366
--- /dev/null
+++ b/content/resources/cookbook_file.md
@@ -0,0 +1,19 @@
++++
+title = "cookbook_file Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","cookbook_file"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "cookbook_file"
+ identifier = "chef_infra/resources/cookbook_file"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/cron.md b/content/resources/cron.md
new file mode 100644
index 0000000..8a01ffe
--- /dev/null
+++ b/content/resources/cron.md
@@ -0,0 +1,19 @@
++++
+title = "cron Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","cron"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "cron"
+ identifier = "chef_infra/resources/cron"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/cron_access.md b/content/resources/cron_access.md
new file mode 100644
index 0000000..3423698
--- /dev/null
+++ b/content/resources/cron_access.md
@@ -0,0 +1,19 @@
++++
+title = "cron_access Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","cron_access"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "cron_access"
+ identifier = "chef_infra/resources/cron_access"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/cron_d.md b/content/resources/cron_d.md
new file mode 100644
index 0000000..d972617
--- /dev/null
+++ b/content/resources/cron_d.md
@@ -0,0 +1,19 @@
++++
+title = "cron_d Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","cron_d"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "cron_d"
+ identifier = "chef_infra/resources/cron_d"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/csh.md b/content/resources/csh.md
new file mode 100644
index 0000000..9bcde55
--- /dev/null
+++ b/content/resources/csh.md
@@ -0,0 +1,19 @@
++++
+title = "csh Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","csh"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "csh"
+ identifier = "chef_infra/resources/csh"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/directory.md b/content/resources/directory.md
new file mode 100644
index 0000000..0f733bb
--- /dev/null
+++ b/content/resources/directory.md
@@ -0,0 +1,19 @@
++++
+title = "directory Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","directory"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "directory"
+ identifier = "chef_infra/resources/directory"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/dmg_package.md b/content/resources/dmg_package.md
new file mode 100644
index 0000000..184a737
--- /dev/null
+++ b/content/resources/dmg_package.md
@@ -0,0 +1,19 @@
++++
+title = "dmg_package Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","dmg_package"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "dmg_package"
+ identifier = "chef_infra/resources/dmg_package"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/dnf_package.md b/content/resources/dnf_package.md
new file mode 100644
index 0000000..a6bb8ba
--- /dev/null
+++ b/content/resources/dnf_package.md
@@ -0,0 +1,19 @@
++++
+title = "dnf_package Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","dnf_package"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "dnf_package"
+ identifier = "chef_infra/resources/dnf_package"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/dpkg_package.md b/content/resources/dpkg_package.md
new file mode 100644
index 0000000..f99ce61
--- /dev/null
+++ b/content/resources/dpkg_package.md
@@ -0,0 +1,19 @@
++++
+title = "dpkg_package Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","dpkg_package"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "dpkg_package"
+ identifier = "chef_infra/resources/dpkg_package"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/dsc_resource.md b/content/resources/dsc_resource.md
new file mode 100644
index 0000000..67d7e3d
--- /dev/null
+++ b/content/resources/dsc_resource.md
@@ -0,0 +1,19 @@
++++
+title = "dsc_resource Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","dsc_resource"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "dsc_resource"
+ identifier = "chef_infra/resources/dsc_resource"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/dsc_script.md b/content/resources/dsc_script.md
new file mode 100644
index 0000000..98ea944
--- /dev/null
+++ b/content/resources/dsc_script.md
@@ -0,0 +1,19 @@
++++
+title = "dsc_script Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","dsc_script"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "dsc_script"
+ identifier = "chef_infra/resources/dsc_script"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/execute.md b/content/resources/execute.md
new file mode 100644
index 0000000..9d4182b
--- /dev/null
+++ b/content/resources/execute.md
@@ -0,0 +1,19 @@
++++
+title = "execute Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","execute"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "execute"
+ identifier = "chef_infra/resources/execute"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/file.md b/content/resources/file.md
new file mode 100644
index 0000000..1f1d813
--- /dev/null
+++ b/content/resources/file.md
@@ -0,0 +1,19 @@
++++
+title = "file Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","file"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "file"
+ identifier = "chef_infra/resources/file"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/freebsd_package.md b/content/resources/freebsd_package.md
new file mode 100644
index 0000000..bf1e2cf
--- /dev/null
+++ b/content/resources/freebsd_package.md
@@ -0,0 +1,19 @@
++++
+title = "freebsd_package Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","freebsd_package"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "freebsd_package"
+ identifier = "chef_infra/resources/freebsd_package"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/gem_package.md b/content/resources/gem_package.md
new file mode 100644
index 0000000..b38e5c7
--- /dev/null
+++ b/content/resources/gem_package.md
@@ -0,0 +1,19 @@
++++
+title = "gem_package Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","gem_package"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "gem_package"
+ identifier = "chef_infra/resources/gem_package"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/git.md b/content/resources/git.md
new file mode 100644
index 0000000..cad31a8
--- /dev/null
+++ b/content/resources/git.md
@@ -0,0 +1,19 @@
++++
+title = "git Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","git"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "git"
+ identifier = "chef_infra/resources/git"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/group.md b/content/resources/group.md
new file mode 100644
index 0000000..e89cc05
--- /dev/null
+++ b/content/resources/group.md
@@ -0,0 +1,19 @@
++++
+title = "group Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","group"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "group"
+ identifier = "chef_infra/resources/group"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/habitat_config.md b/content/resources/habitat_config.md
new file mode 100644
index 0000000..f7a64e6
--- /dev/null
+++ b/content/resources/habitat_config.md
@@ -0,0 +1,19 @@
++++
+title = "habitat_config Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","habitat_config"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "habitat_config"
+ identifier = "chef_infra/resources/habitat_config"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/habitat_install.md b/content/resources/habitat_install.md
new file mode 100644
index 0000000..bf63753
--- /dev/null
+++ b/content/resources/habitat_install.md
@@ -0,0 +1,19 @@
++++
+title = "habitat_install Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","habitat_install"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "habitat_install"
+ identifier = "chef_infra/resources/habitat_install"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/habitat_package.md b/content/resources/habitat_package.md
new file mode 100644
index 0000000..4308a3f
--- /dev/null
+++ b/content/resources/habitat_package.md
@@ -0,0 +1,19 @@
++++
+title = "habitat_package Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","habitat_package"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "habitat_package"
+ identifier = "chef_infra/resources/habitat_package"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/habitat_service.md b/content/resources/habitat_service.md
new file mode 100644
index 0000000..4a5eabc
--- /dev/null
+++ b/content/resources/habitat_service.md
@@ -0,0 +1,19 @@
++++
+title = "habitat_service Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","habitat_service"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "habitat_service"
+ identifier = "chef_infra/resources/habitat_service"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/habitat_sup.md b/content/resources/habitat_sup.md
new file mode 100644
index 0000000..80b8aa0
--- /dev/null
+++ b/content/resources/habitat_sup.md
@@ -0,0 +1,19 @@
++++
+title = "habitat_sup Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","habitat_sup"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "habitat_sup"
+ identifier = "chef_infra/resources/habitat_sup"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/habitat_user_toml.md b/content/resources/habitat_user_toml.md
new file mode 100644
index 0000000..6cc32f5
--- /dev/null
+++ b/content/resources/habitat_user_toml.md
@@ -0,0 +1,19 @@
++++
+title = "habitat_user_toml Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","habitat_user_toml"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "habitat_user_toml"
+ identifier = "chef_infra/resources/habitat_user_toml"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/homebrew_cask.md b/content/resources/homebrew_cask.md
new file mode 100644
index 0000000..4911740
--- /dev/null
+++ b/content/resources/homebrew_cask.md
@@ -0,0 +1,19 @@
++++
+title = "homebrew_cask Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","homebrew_cask"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "homebrew_cask"
+ identifier = "chef_infra/resources/homebrew_cask"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/homebrew_package.md b/content/resources/homebrew_package.md
new file mode 100644
index 0000000..da289c5
--- /dev/null
+++ b/content/resources/homebrew_package.md
@@ -0,0 +1,19 @@
++++
+title = "homebrew_package Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","homebrew_package"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "homebrew_package"
+ identifier = "chef_infra/resources/homebrew_package"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/homebrew_tap.md b/content/resources/homebrew_tap.md
new file mode 100644
index 0000000..c2909e9
--- /dev/null
+++ b/content/resources/homebrew_tap.md
@@ -0,0 +1,19 @@
++++
+title = "homebrew_tap Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","homebrew_tap"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "homebrew_tap"
+ identifier = "chef_infra/resources/homebrew_tap"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/homebrew_update.md b/content/resources/homebrew_update.md
new file mode 100644
index 0000000..9b6049e
--- /dev/null
+++ b/content/resources/homebrew_update.md
@@ -0,0 +1,19 @@
++++
+title = "homebrew_update Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","homebrew_update"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "homebrew_update"
+ identifier = "chef_infra/resources/homebrew_update"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/hostname.md b/content/resources/hostname.md
new file mode 100644
index 0000000..a23b317
--- /dev/null
+++ b/content/resources/hostname.md
@@ -0,0 +1,19 @@
++++
+title = "hostname Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","hostname"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "hostname"
+ identifier = "chef_infra/resources/hostname"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/http_request.md b/content/resources/http_request.md
new file mode 100644
index 0000000..c8e2db2
--- /dev/null
+++ b/content/resources/http_request.md
@@ -0,0 +1,19 @@
++++
+title = "http_request Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","http_request"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "http_request"
+ identifier = "chef_infra/resources/http_request"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/ifconfig.md b/content/resources/ifconfig.md
new file mode 100644
index 0000000..aa13de4
--- /dev/null
+++ b/content/resources/ifconfig.md
@@ -0,0 +1,19 @@
++++
+title = "ifconfig Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","ifconfig"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "ifconfig"
+ identifier = "chef_infra/resources/ifconfig"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/inspec_input.md b/content/resources/inspec_input.md
new file mode 100644
index 0000000..70f19fd
--- /dev/null
+++ b/content/resources/inspec_input.md
@@ -0,0 +1,19 @@
++++
+title = "inspec_input Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","inspec_input"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "inspec_input"
+ identifier = "chef_infra/resources/inspec_input"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/inspec_waiver.md b/content/resources/inspec_waiver.md
new file mode 100644
index 0000000..ecaed1c
--- /dev/null
+++ b/content/resources/inspec_waiver.md
@@ -0,0 +1,19 @@
++++
+title = "inspec_waiver Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","inspec_waiver"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "inspec_waiver"
+ identifier = "chef_infra/resources/inspec_waiver"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/inspec_waiver_file_entry.md b/content/resources/inspec_waiver_file_entry.md
new file mode 100644
index 0000000..4122f28
--- /dev/null
+++ b/content/resources/inspec_waiver_file_entry.md
@@ -0,0 +1,19 @@
++++
+title = "inspec_waiver_file_entry Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","inspec_waiver_file_entry"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "inspec_waiver_file_entry"
+ identifier = "chef_infra/resources/inspec_waiver_file_entry"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/ips_package.md b/content/resources/ips_package.md
new file mode 100644
index 0000000..4665e3c
--- /dev/null
+++ b/content/resources/ips_package.md
@@ -0,0 +1,19 @@
++++
+title = "ips_package Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","ips_package"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "ips_package"
+ identifier = "chef_infra/resources/ips_package"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/kernel_module.md b/content/resources/kernel_module.md
new file mode 100644
index 0000000..5f269d3
--- /dev/null
+++ b/content/resources/kernel_module.md
@@ -0,0 +1,19 @@
++++
+title = "kernel_module Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","kernel_module"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "kernel_module"
+ identifier = "chef_infra/resources/kernel_module"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/ksh.md b/content/resources/ksh.md
new file mode 100644
index 0000000..95aa4a5
--- /dev/null
+++ b/content/resources/ksh.md
@@ -0,0 +1,19 @@
++++
+title = "ksh Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","ksh"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "ksh"
+ identifier = "chef_infra/resources/ksh"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/launchd.md b/content/resources/launchd.md
new file mode 100644
index 0000000..7143146
--- /dev/null
+++ b/content/resources/launchd.md
@@ -0,0 +1,19 @@
++++
+title = "launchd Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","launchd"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "launchd"
+ identifier = "chef_infra/resources/launchd"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/link.md b/content/resources/link.md
new file mode 100644
index 0000000..c81a4eb
--- /dev/null
+++ b/content/resources/link.md
@@ -0,0 +1,19 @@
++++
+title = "link Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","link"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "link"
+ identifier = "chef_infra/resources/link"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/locale.md b/content/resources/locale.md
new file mode 100644
index 0000000..64eef88
--- /dev/null
+++ b/content/resources/locale.md
@@ -0,0 +1,19 @@
++++
+title = "locale Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","locale"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "locale"
+ identifier = "chef_infra/resources/locale"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/log.md b/content/resources/log.md
new file mode 100644
index 0000000..6f396db
--- /dev/null
+++ b/content/resources/log.md
@@ -0,0 +1,19 @@
++++
+title = "log Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","log"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "log"
+ identifier = "chef_infra/resources/log"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/macos_userdefaults.md b/content/resources/macos_userdefaults.md
new file mode 100644
index 0000000..10b81df
--- /dev/null
+++ b/content/resources/macos_userdefaults.md
@@ -0,0 +1,19 @@
++++
+title = "macos_userdefaults Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","macos_userdefaults"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "macos_userdefaults"
+ identifier = "chef_infra/resources/macos_userdefaults"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/macosx_service.md b/content/resources/macosx_service.md
new file mode 100644
index 0000000..3e91255
--- /dev/null
+++ b/content/resources/macosx_service.md
@@ -0,0 +1,19 @@
++++
+title = "macosx_service Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","macosx_service"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "macosx_service"
+ identifier = "chef_infra/resources/macosx_service"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/macports_package.md b/content/resources/macports_package.md
new file mode 100644
index 0000000..a7a3017
--- /dev/null
+++ b/content/resources/macports_package.md
@@ -0,0 +1,19 @@
++++
+title = "macports_package Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","macports_package"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "macports_package"
+ identifier = "chef_infra/resources/macports_package"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/mdadm.md b/content/resources/mdadm.md
new file mode 100644
index 0000000..e5d3978
--- /dev/null
+++ b/content/resources/mdadm.md
@@ -0,0 +1,19 @@
++++
+title = "mdadm Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","mdadm"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "mdadm"
+ identifier = "chef_infra/resources/mdadm"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/mount.md b/content/resources/mount.md
new file mode 100644
index 0000000..27412d3
--- /dev/null
+++ b/content/resources/mount.md
@@ -0,0 +1,19 @@
++++
+title = "mount Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","mount"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "mount"
+ identifier = "chef_infra/resources/mount"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/msu_package.md b/content/resources/msu_package.md
new file mode 100644
index 0000000..ed2b495
--- /dev/null
+++ b/content/resources/msu_package.md
@@ -0,0 +1,19 @@
++++
+title = "msu_package Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","msu_package"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "msu_package"
+ identifier = "chef_infra/resources/msu_package"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/notify_group.md b/content/resources/notify_group.md
new file mode 100644
index 0000000..7b5a094
--- /dev/null
+++ b/content/resources/notify_group.md
@@ -0,0 +1,19 @@
++++
+title = "notify_group Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","notify_group"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "notify_group"
+ identifier = "chef_infra/resources/notify_group"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/ohai.md b/content/resources/ohai.md
new file mode 100644
index 0000000..8cc8aa6
--- /dev/null
+++ b/content/resources/ohai.md
@@ -0,0 +1,19 @@
++++
+title = "ohai Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","ohai"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "ohai"
+ identifier = "chef_infra/resources/ohai"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/ohai_hint.md b/content/resources/ohai_hint.md
new file mode 100644
index 0000000..47a8e9f
--- /dev/null
+++ b/content/resources/ohai_hint.md
@@ -0,0 +1,19 @@
++++
+title = "ohai_hint Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","ohai_hint"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "ohai_hint"
+ identifier = "chef_infra/resources/ohai_hint"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/openbsd_package.md b/content/resources/openbsd_package.md
new file mode 100644
index 0000000..018cb13
--- /dev/null
+++ b/content/resources/openbsd_package.md
@@ -0,0 +1,19 @@
++++
+title = "openbsd_package Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","openbsd_package"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "openbsd_package"
+ identifier = "chef_infra/resources/openbsd_package"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/openssl_dhparam.md b/content/resources/openssl_dhparam.md
new file mode 100644
index 0000000..dcfed48
--- /dev/null
+++ b/content/resources/openssl_dhparam.md
@@ -0,0 +1,19 @@
++++
+title = "openssl_dhparam Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","openssl_dhparam"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "openssl_dhparam"
+ identifier = "chef_infra/resources/openssl_dhparam"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/openssl_ec_private_key.md b/content/resources/openssl_ec_private_key.md
new file mode 100644
index 0000000..e82007b
--- /dev/null
+++ b/content/resources/openssl_ec_private_key.md
@@ -0,0 +1,19 @@
++++
+title = "openssl_ec_private_key Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","openssl_ec_private_key"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "openssl_ec_private_key"
+ identifier = "chef_infra/resources/openssl_ec_private_key"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/openssl_ec_public_key.md b/content/resources/openssl_ec_public_key.md
new file mode 100644
index 0000000..15c7f4e
--- /dev/null
+++ b/content/resources/openssl_ec_public_key.md
@@ -0,0 +1,19 @@
++++
+title = "openssl_ec_public_key Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","openssl_ec_public_key"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "openssl_ec_public_key"
+ identifier = "chef_infra/resources/openssl_ec_public_key"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/openssl_rsa_private_key.md b/content/resources/openssl_rsa_private_key.md
new file mode 100644
index 0000000..9b220f0
--- /dev/null
+++ b/content/resources/openssl_rsa_private_key.md
@@ -0,0 +1,19 @@
++++
+title = "openssl_rsa_private_key Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","openssl_rsa_private_key"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "openssl_rsa_private_key"
+ identifier = "chef_infra/resources/openssl_rsa_private_key"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/openssl_rsa_public_key.md b/content/resources/openssl_rsa_public_key.md
new file mode 100644
index 0000000..d429962
--- /dev/null
+++ b/content/resources/openssl_rsa_public_key.md
@@ -0,0 +1,19 @@
++++
+title = "openssl_rsa_public_key Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","openssl_rsa_public_key"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "openssl_rsa_public_key"
+ identifier = "chef_infra/resources/openssl_rsa_public_key"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/openssl_x509_certificate.md b/content/resources/openssl_x509_certificate.md
new file mode 100644
index 0000000..0bf3f0a
--- /dev/null
+++ b/content/resources/openssl_x509_certificate.md
@@ -0,0 +1,19 @@
++++
+title = "openssl_x509_certificate Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","openssl_x509_certificate"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "openssl_x509_certificate"
+ identifier = "chef_infra/resources/openssl_x509_certificate"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/openssl_x509_crl.md b/content/resources/openssl_x509_crl.md
new file mode 100644
index 0000000..9ceafa0
--- /dev/null
+++ b/content/resources/openssl_x509_crl.md
@@ -0,0 +1,19 @@
++++
+title = "openssl_x509_crl Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","openssl_x509_crl"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "openssl_x509_crl"
+ identifier = "chef_infra/resources/openssl_x509_crl"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/openssl_x509_request.md b/content/resources/openssl_x509_request.md
new file mode 100644
index 0000000..ce896aa
--- /dev/null
+++ b/content/resources/openssl_x509_request.md
@@ -0,0 +1,19 @@
++++
+title = "openssl_x509_request Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","openssl_x509_request"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "openssl_x509_request"
+ identifier = "chef_infra/resources/openssl_x509_request"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/osx_profile.md b/content/resources/osx_profile.md
new file mode 100644
index 0000000..d077036
--- /dev/null
+++ b/content/resources/osx_profile.md
@@ -0,0 +1,19 @@
++++
+title = "osx_profile Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","osx_profile"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "osx_profile"
+ identifier = "chef_infra/resources/osx_profile"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/package.md b/content/resources/package.md
new file mode 100644
index 0000000..269a9dd
--- /dev/null
+++ b/content/resources/package.md
@@ -0,0 +1,19 @@
++++
+title = "package Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","package"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "package"
+ identifier = "chef_infra/resources/package"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/pacman_package.md b/content/resources/pacman_package.md
new file mode 100644
index 0000000..8ffea71
--- /dev/null
+++ b/content/resources/pacman_package.md
@@ -0,0 +1,19 @@
++++
+title = "pacman_package Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","pacman_package"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "pacman_package"
+ identifier = "chef_infra/resources/pacman_package"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/paludis_package.md b/content/resources/paludis_package.md
new file mode 100644
index 0000000..98222c7
--- /dev/null
+++ b/content/resources/paludis_package.md
@@ -0,0 +1,19 @@
++++
+title = "paludis_package Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","paludis_package"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "paludis_package"
+ identifier = "chef_infra/resources/paludis_package"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/perl.md b/content/resources/perl.md
new file mode 100644
index 0000000..7df32ff
--- /dev/null
+++ b/content/resources/perl.md
@@ -0,0 +1,19 @@
++++
+title = "perl Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","perl"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "perl"
+ identifier = "chef_infra/resources/perl"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/plist.md b/content/resources/plist.md
new file mode 100644
index 0000000..5ae211d
--- /dev/null
+++ b/content/resources/plist.md
@@ -0,0 +1,19 @@
++++
+title = "plist Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","plist"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "plist"
+ identifier = "chef_infra/resources/plist"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/portage_package.md b/content/resources/portage_package.md
new file mode 100644
index 0000000..0fa20de
--- /dev/null
+++ b/content/resources/portage_package.md
@@ -0,0 +1,19 @@
++++
+title = "portage_package Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","portage_package"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "portage_package"
+ identifier = "chef_infra/resources/portage_package"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/powershell_package.md b/content/resources/powershell_package.md
new file mode 100644
index 0000000..fd60f47
--- /dev/null
+++ b/content/resources/powershell_package.md
@@ -0,0 +1,19 @@
++++
+title = "powershell_package Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","powershell_package"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "powershell_package"
+ identifier = "chef_infra/resources/powershell_package"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/powershell_package_source.md b/content/resources/powershell_package_source.md
new file mode 100644
index 0000000..315c7a4
--- /dev/null
+++ b/content/resources/powershell_package_source.md
@@ -0,0 +1,19 @@
++++
+title = "powershell_package_source Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","powershell_package_source"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "powershell_package_source"
+ identifier = "chef_infra/resources/powershell_package_source"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/powershell_script.md b/content/resources/powershell_script.md
new file mode 100644
index 0000000..b2c6813
--- /dev/null
+++ b/content/resources/powershell_script.md
@@ -0,0 +1,19 @@
++++
+title = "powershell_script Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","powershell_script"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "powershell_script"
+ identifier = "chef_infra/resources/powershell_script"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/python.md b/content/resources/python.md
new file mode 100644
index 0000000..d002423
--- /dev/null
+++ b/content/resources/python.md
@@ -0,0 +1,19 @@
++++
+title = "python Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","python"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "python"
+ identifier = "chef_infra/resources/python"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/reboot.md b/content/resources/reboot.md
new file mode 100644
index 0000000..3701f91
--- /dev/null
+++ b/content/resources/reboot.md
@@ -0,0 +1,19 @@
++++
+title = "reboot Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","reboot"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "reboot"
+ identifier = "chef_infra/resources/reboot"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/registry_key.md b/content/resources/registry_key.md
new file mode 100644
index 0000000..3ab3cb4
--- /dev/null
+++ b/content/resources/registry_key.md
@@ -0,0 +1,19 @@
++++
+title = "registry_key Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","registry_key"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "registry_key"
+ identifier = "chef_infra/resources/registry_key"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/remote_directory.md b/content/resources/remote_directory.md
new file mode 100644
index 0000000..c873902
--- /dev/null
+++ b/content/resources/remote_directory.md
@@ -0,0 +1,19 @@
++++
+title = "remote_directory Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","remote_directory"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "remote_directory"
+ identifier = "chef_infra/resources/remote_directory"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/remote_file.md b/content/resources/remote_file.md
new file mode 100644
index 0000000..2e656e3
--- /dev/null
+++ b/content/resources/remote_file.md
@@ -0,0 +1,19 @@
++++
+title = "remote_file Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","remote_file"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "remote_file"
+ identifier = "chef_infra/resources/remote_file"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/rhsm_errata.md b/content/resources/rhsm_errata.md
new file mode 100644
index 0000000..96df39c
--- /dev/null
+++ b/content/resources/rhsm_errata.md
@@ -0,0 +1,19 @@
++++
+title = "rhsm_errata Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","rhsm_errata"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "rhsm_errata"
+ identifier = "chef_infra/resources/rhsm_errata"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/rhsm_errata_level.md b/content/resources/rhsm_errata_level.md
new file mode 100644
index 0000000..f86c333
--- /dev/null
+++ b/content/resources/rhsm_errata_level.md
@@ -0,0 +1,19 @@
++++
+title = "rhsm_errata_level Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","rhsm_errata_level"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "rhsm_errata_level"
+ identifier = "chef_infra/resources/rhsm_errata_level"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/rhsm_register.md b/content/resources/rhsm_register.md
new file mode 100644
index 0000000..61b7897
--- /dev/null
+++ b/content/resources/rhsm_register.md
@@ -0,0 +1,19 @@
++++
+title = "rhsm_register Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","rhsm_register"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "rhsm_register"
+ identifier = "chef_infra/resources/rhsm_register"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/rhsm_repo.md b/content/resources/rhsm_repo.md
new file mode 100644
index 0000000..631fe06
--- /dev/null
+++ b/content/resources/rhsm_repo.md
@@ -0,0 +1,19 @@
++++
+title = "rhsm_repo Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","rhsm_repo"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "rhsm_repo"
+ identifier = "chef_infra/resources/rhsm_repo"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/rhsm_subscription.md b/content/resources/rhsm_subscription.md
new file mode 100644
index 0000000..e13bba4
--- /dev/null
+++ b/content/resources/rhsm_subscription.md
@@ -0,0 +1,19 @@
++++
+title = "rhsm_subscription Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","rhsm_subscription"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "rhsm_subscription"
+ identifier = "chef_infra/resources/rhsm_subscription"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/route.md b/content/resources/route.md
new file mode 100644
index 0000000..0b5eb6a
--- /dev/null
+++ b/content/resources/route.md
@@ -0,0 +1,19 @@
++++
+title = "route Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","route"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "route"
+ identifier = "chef_infra/resources/route"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/rpm_package.md b/content/resources/rpm_package.md
new file mode 100644
index 0000000..f6b959f
--- /dev/null
+++ b/content/resources/rpm_package.md
@@ -0,0 +1,19 @@
++++
+title = "rpm_package Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","rpm_package"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "rpm_package"
+ identifier = "chef_infra/resources/rpm_package"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/ruby.md b/content/resources/ruby.md
new file mode 100644
index 0000000..dcf8913
--- /dev/null
+++ b/content/resources/ruby.md
@@ -0,0 +1,19 @@
++++
+title = "ruby Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","ruby"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "ruby"
+ identifier = "chef_infra/resources/ruby"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/ruby_block.md b/content/resources/ruby_block.md
new file mode 100644
index 0000000..089701a
--- /dev/null
+++ b/content/resources/ruby_block.md
@@ -0,0 +1,19 @@
++++
+title = "ruby_block Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","ruby_block"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "ruby_block"
+ identifier = "chef_infra/resources/ruby_block"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/script.md b/content/resources/script.md
new file mode 100644
index 0000000..36f2789
--- /dev/null
+++ b/content/resources/script.md
@@ -0,0 +1,19 @@
++++
+title = "script Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","script"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "script"
+ identifier = "chef_infra/resources/script"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/selinux_boolean.md b/content/resources/selinux_boolean.md
new file mode 100644
index 0000000..79b829b
--- /dev/null
+++ b/content/resources/selinux_boolean.md
@@ -0,0 +1,19 @@
++++
+title = "selinux_boolean Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","selinux_boolean"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "selinux_boolean"
+ identifier = "chef_infra/resources/selinux_boolean"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/selinux_fcontext.md b/content/resources/selinux_fcontext.md
new file mode 100644
index 0000000..4e1174c
--- /dev/null
+++ b/content/resources/selinux_fcontext.md
@@ -0,0 +1,19 @@
++++
+title = "selinux_fcontext Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","selinux_fcontext"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "selinux_fcontext"
+ identifier = "chef_infra/resources/selinux_fcontext"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/selinux_install.md b/content/resources/selinux_install.md
new file mode 100644
index 0000000..7ad6817
--- /dev/null
+++ b/content/resources/selinux_install.md
@@ -0,0 +1,19 @@
++++
+title = "selinux_install Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","selinux_install"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "selinux_install"
+ identifier = "chef_infra/resources/selinux_install"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/selinux_login.md b/content/resources/selinux_login.md
new file mode 100644
index 0000000..d9ae890
--- /dev/null
+++ b/content/resources/selinux_login.md
@@ -0,0 +1,19 @@
++++
+title = "selinux_login Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","selinux_login"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "selinux_login"
+ identifier = "chef_infra/resources/selinux_login"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/selinux_module.md b/content/resources/selinux_module.md
new file mode 100644
index 0000000..da08960
--- /dev/null
+++ b/content/resources/selinux_module.md
@@ -0,0 +1,19 @@
++++
+title = "selinux_module Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","selinux_module"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "selinux_module"
+ identifier = "chef_infra/resources/selinux_module"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/selinux_permissive.md b/content/resources/selinux_permissive.md
new file mode 100644
index 0000000..f95f8f5
--- /dev/null
+++ b/content/resources/selinux_permissive.md
@@ -0,0 +1,19 @@
++++
+title = "selinux_permissive Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","selinux_permissive"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "selinux_permissive"
+ identifier = "chef_infra/resources/selinux_permissive"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/selinux_port.md b/content/resources/selinux_port.md
new file mode 100644
index 0000000..12125ff
--- /dev/null
+++ b/content/resources/selinux_port.md
@@ -0,0 +1,19 @@
++++
+title = "selinux_port Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","selinux_port"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "selinux_port"
+ identifier = "chef_infra/resources/selinux_port"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/selinux_state.md b/content/resources/selinux_state.md
new file mode 100644
index 0000000..25b4e3b
--- /dev/null
+++ b/content/resources/selinux_state.md
@@ -0,0 +1,19 @@
++++
+title = "selinux_state Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","selinux_state"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "selinux_state"
+ identifier = "chef_infra/resources/selinux_state"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/selinux_user.md b/content/resources/selinux_user.md
new file mode 100644
index 0000000..bbfa37e
--- /dev/null
+++ b/content/resources/selinux_user.md
@@ -0,0 +1,19 @@
++++
+title = "selinux_user Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","selinux_user"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "selinux_user"
+ identifier = "chef_infra/resources/selinux_user"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/service.md b/content/resources/service.md
new file mode 100644
index 0000000..46ab9e1
--- /dev/null
+++ b/content/resources/service.md
@@ -0,0 +1,19 @@
++++
+title = "service Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","service"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "service"
+ identifier = "chef_infra/resources/service"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/smartos_package.md b/content/resources/smartos_package.md
new file mode 100644
index 0000000..1c8e622
--- /dev/null
+++ b/content/resources/smartos_package.md
@@ -0,0 +1,19 @@
++++
+title = "smartos_package Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","smartos_package"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "smartos_package"
+ identifier = "chef_infra/resources/smartos_package"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/snap_package.md b/content/resources/snap_package.md
new file mode 100644
index 0000000..426c193
--- /dev/null
+++ b/content/resources/snap_package.md
@@ -0,0 +1,19 @@
++++
+title = "snap_package Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","snap_package"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "snap_package"
+ identifier = "chef_infra/resources/snap_package"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/solaris_package.md b/content/resources/solaris_package.md
new file mode 100644
index 0000000..086b34f
--- /dev/null
+++ b/content/resources/solaris_package.md
@@ -0,0 +1,19 @@
++++
+title = "solaris_package Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","solaris_package"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "solaris_package"
+ identifier = "chef_infra/resources/solaris_package"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/ssh_known_hosts_entry.md b/content/resources/ssh_known_hosts_entry.md
new file mode 100644
index 0000000..608f82b
--- /dev/null
+++ b/content/resources/ssh_known_hosts_entry.md
@@ -0,0 +1,19 @@
++++
+title = "ssh_known_hosts_entry Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","ssh_known_hosts_entry"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "ssh_known_hosts_entry"
+ identifier = "chef_infra/resources/ssh_known_hosts_entry"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/subversion.md b/content/resources/subversion.md
new file mode 100644
index 0000000..b508fc1
--- /dev/null
+++ b/content/resources/subversion.md
@@ -0,0 +1,19 @@
++++
+title = "subversion Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","subversion"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "subversion"
+ identifier = "chef_infra/resources/subversion"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/sudo.md b/content/resources/sudo.md
new file mode 100644
index 0000000..13bc053
--- /dev/null
+++ b/content/resources/sudo.md
@@ -0,0 +1,19 @@
++++
+title = "sudo Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","sudo"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "sudo"
+ identifier = "chef_infra/resources/sudo"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/swap_file.md b/content/resources/swap_file.md
new file mode 100644
index 0000000..78aafa0
--- /dev/null
+++ b/content/resources/swap_file.md
@@ -0,0 +1,19 @@
++++
+title = "swap_file Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","swap_file"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "swap_file"
+ identifier = "chef_infra/resources/swap_file"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/sysctl.md b/content/resources/sysctl.md
new file mode 100644
index 0000000..f5f0e87
--- /dev/null
+++ b/content/resources/sysctl.md
@@ -0,0 +1,19 @@
++++
+title = "sysctl Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","sysctl"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "sysctl"
+ identifier = "chef_infra/resources/sysctl"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/systemd_unit.md b/content/resources/systemd_unit.md
new file mode 100644
index 0000000..9836224
--- /dev/null
+++ b/content/resources/systemd_unit.md
@@ -0,0 +1,19 @@
++++
+title = "systemd_unit Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","systemd_unit"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "systemd_unit"
+ identifier = "chef_infra/resources/systemd_unit"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/template.md b/content/resources/template.md
new file mode 100644
index 0000000..673ba5e
--- /dev/null
+++ b/content/resources/template.md
@@ -0,0 +1,19 @@
++++
+title = "template Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","template"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "template"
+ identifier = "chef_infra/resources/template"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/timezone.md b/content/resources/timezone.md
new file mode 100644
index 0000000..fee4960
--- /dev/null
+++ b/content/resources/timezone.md
@@ -0,0 +1,19 @@
++++
+title = "timezone Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","timezone"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "timezone"
+ identifier = "chef_infra/resources/timezone"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/user.md b/content/resources/user.md
new file mode 100644
index 0000000..edde235
--- /dev/null
+++ b/content/resources/user.md
@@ -0,0 +1,19 @@
++++
+title = "user Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","user"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "user"
+ identifier = "chef_infra/resources/user"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/user_ulimit.md b/content/resources/user_ulimit.md
new file mode 100644
index 0000000..cf38349
--- /dev/null
+++ b/content/resources/user_ulimit.md
@@ -0,0 +1,19 @@
++++
+title = "user_ulimit Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","user_ulimit"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "user_ulimit"
+ identifier = "chef_infra/resources/user_ulimit"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_ad_join.md b/content/resources/windows_ad_join.md
new file mode 100644
index 0000000..f932773
--- /dev/null
+++ b/content/resources/windows_ad_join.md
@@ -0,0 +1,19 @@
++++
+title = "windows_ad_join Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_ad_join"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_ad_join"
+ identifier = "chef_infra/resources/windows_ad_join"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_audit_policy.md b/content/resources/windows_audit_policy.md
new file mode 100644
index 0000000..e59aa31
--- /dev/null
+++ b/content/resources/windows_audit_policy.md
@@ -0,0 +1,19 @@
++++
+title = "windows_audit_policy Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_audit_policy"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_audit_policy"
+ identifier = "chef_infra/resources/windows_audit_policy"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_auto_run.md b/content/resources/windows_auto_run.md
new file mode 100644
index 0000000..548fce7
--- /dev/null
+++ b/content/resources/windows_auto_run.md
@@ -0,0 +1,19 @@
++++
+title = "windows_auto_run Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_auto_run"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_auto_run"
+ identifier = "chef_infra/resources/windows_auto_run"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_certificate.md b/content/resources/windows_certificate.md
new file mode 100644
index 0000000..9743e4e
--- /dev/null
+++ b/content/resources/windows_certificate.md
@@ -0,0 +1,19 @@
++++
+title = "windows_certificate Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_certificate"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_certificate"
+ identifier = "chef_infra/resources/windows_certificate"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_defender.md b/content/resources/windows_defender.md
new file mode 100644
index 0000000..60a0555
--- /dev/null
+++ b/content/resources/windows_defender.md
@@ -0,0 +1,19 @@
++++
+title = "windows_defender Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_defender"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_defender"
+ identifier = "chef_infra/resources/windows_defender"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_defender_exclusion.md b/content/resources/windows_defender_exclusion.md
new file mode 100644
index 0000000..c7debdd
--- /dev/null
+++ b/content/resources/windows_defender_exclusion.md
@@ -0,0 +1,19 @@
++++
+title = "windows_defender_exclusion Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_defender_exclusion"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_defender_exclusion"
+ identifier = "chef_infra/resources/windows_defender_exclusion"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_dfs_folder.md b/content/resources/windows_dfs_folder.md
new file mode 100644
index 0000000..050f431
--- /dev/null
+++ b/content/resources/windows_dfs_folder.md
@@ -0,0 +1,19 @@
++++
+title = "windows_dfs_folder Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_dfs_folder"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_dfs_folder"
+ identifier = "chef_infra/resources/windows_dfs_folder"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_dfs_namespace.md b/content/resources/windows_dfs_namespace.md
new file mode 100644
index 0000000..3daf3f3
--- /dev/null
+++ b/content/resources/windows_dfs_namespace.md
@@ -0,0 +1,19 @@
++++
+title = "windows_dfs_namespace Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_dfs_namespace"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_dfs_namespace"
+ identifier = "chef_infra/resources/windows_dfs_namespace"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_dfs_server.md b/content/resources/windows_dfs_server.md
new file mode 100644
index 0000000..a1c79c7
--- /dev/null
+++ b/content/resources/windows_dfs_server.md
@@ -0,0 +1,19 @@
++++
+title = "windows_dfs_server Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_dfs_server"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_dfs_server"
+ identifier = "chef_infra/resources/windows_dfs_server"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_dns_record.md b/content/resources/windows_dns_record.md
new file mode 100644
index 0000000..5e2c4c2
--- /dev/null
+++ b/content/resources/windows_dns_record.md
@@ -0,0 +1,19 @@
++++
+title = "windows_dns_record Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_dns_record"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_dns_record"
+ identifier = "chef_infra/resources/windows_dns_record"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_dns_zone.md b/content/resources/windows_dns_zone.md
new file mode 100644
index 0000000..994e395
--- /dev/null
+++ b/content/resources/windows_dns_zone.md
@@ -0,0 +1,19 @@
++++
+title = "windows_dns_zone Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_dns_zone"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_dns_zone"
+ identifier = "chef_infra/resources/windows_dns_zone"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_env.md b/content/resources/windows_env.md
new file mode 100644
index 0000000..ae6ba84
--- /dev/null
+++ b/content/resources/windows_env.md
@@ -0,0 +1,19 @@
++++
+title = "windows_env Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_env"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_env"
+ identifier = "chef_infra/resources/windows_env"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_feature.md b/content/resources/windows_feature.md
new file mode 100644
index 0000000..42ee426
--- /dev/null
+++ b/content/resources/windows_feature.md
@@ -0,0 +1,19 @@
++++
+title = "windows_feature Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_feature"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_feature"
+ identifier = "chef_infra/resources/windows_feature"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_feature_dism.md b/content/resources/windows_feature_dism.md
new file mode 100644
index 0000000..8c82a7d
--- /dev/null
+++ b/content/resources/windows_feature_dism.md
@@ -0,0 +1,19 @@
++++
+title = "windows_feature_dism Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_feature_dism"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_feature_dism"
+ identifier = "chef_infra/resources/windows_feature_dism"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_feature_powershell.md b/content/resources/windows_feature_powershell.md
new file mode 100644
index 0000000..fcf943d
--- /dev/null
+++ b/content/resources/windows_feature_powershell.md
@@ -0,0 +1,19 @@
++++
+title = "windows_feature_powershell Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_feature_powershell"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_feature_powershell"
+ identifier = "chef_infra/resources/windows_feature_powershell"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_firewall_profile.md b/content/resources/windows_firewall_profile.md
new file mode 100644
index 0000000..2e6ddb0
--- /dev/null
+++ b/content/resources/windows_firewall_profile.md
@@ -0,0 +1,19 @@
++++
+title = "windows_firewall_profile Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_firewall_profile"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_firewall_profile"
+ identifier = "chef_infra/resources/windows_firewall_profile"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_firewall_rule.md b/content/resources/windows_firewall_rule.md
new file mode 100644
index 0000000..513826f
--- /dev/null
+++ b/content/resources/windows_firewall_rule.md
@@ -0,0 +1,19 @@
++++
+title = "windows_firewall_rule Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_firewall_rule"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_firewall_rule"
+ identifier = "chef_infra/resources/windows_firewall_rule"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_font.md b/content/resources/windows_font.md
new file mode 100644
index 0000000..8ff3f6b
--- /dev/null
+++ b/content/resources/windows_font.md
@@ -0,0 +1,19 @@
++++
+title = "windows_font Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_font"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_font"
+ identifier = "chef_infra/resources/windows_font"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_package.md b/content/resources/windows_package.md
new file mode 100644
index 0000000..0f0abb2
--- /dev/null
+++ b/content/resources/windows_package.md
@@ -0,0 +1,19 @@
++++
+title = "windows_package Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_package"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_package"
+ identifier = "chef_infra/resources/windows_package"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_pagefile.md b/content/resources/windows_pagefile.md
new file mode 100644
index 0000000..c128ee8
--- /dev/null
+++ b/content/resources/windows_pagefile.md
@@ -0,0 +1,19 @@
++++
+title = "windows_pagefile Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_pagefile"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_pagefile"
+ identifier = "chef_infra/resources/windows_pagefile"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_path.md b/content/resources/windows_path.md
new file mode 100644
index 0000000..e980c50
--- /dev/null
+++ b/content/resources/windows_path.md
@@ -0,0 +1,19 @@
++++
+title = "windows_path Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_path"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_path"
+ identifier = "chef_infra/resources/windows_path"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_printer.md b/content/resources/windows_printer.md
new file mode 100644
index 0000000..12d27f0
--- /dev/null
+++ b/content/resources/windows_printer.md
@@ -0,0 +1,19 @@
++++
+title = "windows_printer Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_printer"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_printer"
+ identifier = "chef_infra/resources/windows_printer"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_printer_port.md b/content/resources/windows_printer_port.md
new file mode 100644
index 0000000..0b0afb6
--- /dev/null
+++ b/content/resources/windows_printer_port.md
@@ -0,0 +1,19 @@
++++
+title = "windows_printer_port Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_printer_port"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_printer_port"
+ identifier = "chef_infra/resources/windows_printer_port"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_security_policy.md b/content/resources/windows_security_policy.md
new file mode 100644
index 0000000..25f1aef
--- /dev/null
+++ b/content/resources/windows_security_policy.md
@@ -0,0 +1,19 @@
++++
+title = "windows_security_policy Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_security_policy"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_security_policy"
+ identifier = "chef_infra/resources/windows_security_policy"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_service.md b/content/resources/windows_service.md
new file mode 100644
index 0000000..33e7f50
--- /dev/null
+++ b/content/resources/windows_service.md
@@ -0,0 +1,19 @@
++++
+title = "windows_service Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_service"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_service"
+ identifier = "chef_infra/resources/windows_service"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_share.md b/content/resources/windows_share.md
new file mode 100644
index 0000000..9f4474a
--- /dev/null
+++ b/content/resources/windows_share.md
@@ -0,0 +1,19 @@
++++
+title = "windows_share Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_share"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_share"
+ identifier = "chef_infra/resources/windows_share"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_shortcut.md b/content/resources/windows_shortcut.md
new file mode 100644
index 0000000..f5467fd
--- /dev/null
+++ b/content/resources/windows_shortcut.md
@@ -0,0 +1,19 @@
++++
+title = "windows_shortcut Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_shortcut"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_shortcut"
+ identifier = "chef_infra/resources/windows_shortcut"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_task.md b/content/resources/windows_task.md
new file mode 100644
index 0000000..3d51fb6
--- /dev/null
+++ b/content/resources/windows_task.md
@@ -0,0 +1,19 @@
++++
+title = "windows_task Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_task"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_task"
+ identifier = "chef_infra/resources/windows_task"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_uac.md b/content/resources/windows_uac.md
new file mode 100644
index 0000000..2587eb1
--- /dev/null
+++ b/content/resources/windows_uac.md
@@ -0,0 +1,19 @@
++++
+title = "windows_uac Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_uac"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_uac"
+ identifier = "chef_infra/resources/windows_uac"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_update_settings.md b/content/resources/windows_update_settings.md
new file mode 100644
index 0000000..a488e34
--- /dev/null
+++ b/content/resources/windows_update_settings.md
@@ -0,0 +1,19 @@
++++
+title = "windows_update_settings Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_update_settings"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_update_settings"
+ identifier = "chef_infra/resources/windows_update_settings"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_user_privilege.md b/content/resources/windows_user_privilege.md
new file mode 100644
index 0000000..bd6564e
--- /dev/null
+++ b/content/resources/windows_user_privilege.md
@@ -0,0 +1,19 @@
++++
+title = "windows_user_privilege Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_user_privilege"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_user_privilege"
+ identifier = "chef_infra/resources/windows_user_privilege"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/windows_workgroup.md b/content/resources/windows_workgroup.md
new file mode 100644
index 0000000..1ce5d93
--- /dev/null
+++ b/content/resources/windows_workgroup.md
@@ -0,0 +1,19 @@
++++
+title = "windows_workgroup Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","windows_workgroup"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "windows_workgroup"
+ identifier = "chef_infra/resources/windows_workgroup"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/yum_package.md b/content/resources/yum_package.md
new file mode 100644
index 0000000..aaa3618
--- /dev/null
+++ b/content/resources/yum_package.md
@@ -0,0 +1,19 @@
++++
+title = "yum_package Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","yum_package"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "yum_package"
+ identifier = "chef_infra/resources/yum_package"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/yum_repository.md b/content/resources/yum_repository.md
new file mode 100644
index 0000000..6af38b5
--- /dev/null
+++ b/content/resources/yum_repository.md
@@ -0,0 +1,19 @@
++++
+title = "yum_repository Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","yum_repository"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "yum_repository"
+ identifier = "chef_infra/resources/yum_repository"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/zypper_package.md b/content/resources/zypper_package.md
new file mode 100644
index 0000000..be6df4e
--- /dev/null
+++ b/content/resources/zypper_package.md
@@ -0,0 +1,19 @@
++++
+title = "zypper_package Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","zypper_package"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "zypper_package"
+ identifier = "chef_infra/resources/zypper_package"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/resources/zypper_repository.md b/content/resources/zypper_repository.md
new file mode 100644
index 0000000..45cc04a
--- /dev/null
+++ b/content/resources/zypper_repository.md
@@ -0,0 +1,19 @@
++++
+title = "zypper_repository Resource"
+draft = false
+robots = ""
+gh_repo = "chef-web-docs"
+data_path = ["infra","resources","zypper_repository"]
+layout = "infra_resource"
+toc_layout = "infra_resource_toc"
+
+[menu]
+ [menu.infra]
+ title = "zypper_repository"
+ identifier = "chef_infra/resources/zypper_repository"
+ parent = "chef_infra/resources"
++++
+
+
+
+
diff --git a/content/reusable/md/agentless_custom_resource.md b/content/reusable/md/agentless_custom_resource.md
deleted file mode 100644
index f3e9c61..0000000
--- a/content/reusable/md/agentless_custom_resource.md
+++ /dev/null
@@ -1,6 +0,0 @@
-To enable a custom resource to run in Agentless Mode, add `target_mode: true` to the resource definition. For example:
-
-```ruby
-provides :resource_name, target_mode: true
-...
-```
diff --git a/content/reusable/md/agentless_custom_resource_example.md b/content/reusable/md/agentless_custom_resource_example.md
deleted file mode 100644
index 0fdd61e..0000000
--- a/content/reusable/md/agentless_custom_resource_example.md
+++ /dev/null
@@ -1,26 +0,0 @@
-
-The following custom resource example runs in Agentless Mode and updates the content of a file defined by the `path` property.
-
-```ruby
-# Create a new resource that's available in Target Mode
-provides :file_update, target_mode: true
-
-property :path, String, name_property: true
-property :content, String, default: ""
-
-default_action :update
-
-load_current_value do |new_resource|
- # Prefix any IO calls with ::TargetIO to use the IO abstraction
- if ::TargetIO::File.exist?(new_resource.path)
- content ::TargetIO::IO.read(new_resource.path)
- end
-end
-
-action :update do
- converge_if_changed :content do
- TargetIO.write(new_resource.path, new_resource.content)
- # You can also use shell_out() here without any prefix
- end
-end
-```
diff --git a/content/reusable/md/agentless_summary.md b/content/reusable/md/agentless_summary.md
deleted file mode 100644
index de252d7..0000000
--- a/content/reusable/md/agentless_summary.md
+++ /dev/null
@@ -1 +0,0 @@
-Agentless Mode executes Chef Infra Client runs on nodes that don't have Chef Infra Client installed on them.
diff --git a/content/reusable/md/workstation_modularize.md b/content/reusable/md/workstation_modularize.md
deleted file mode 100644
index 7e49793..0000000
--- a/content/reusable/md/workstation_modularize.md
+++ /dev/null
@@ -1,3 +0,0 @@
-Chef Workstation is modularized to improve user experience and simplify interactions with its components.
-This divides Chef Workstation into independent parts, enabling users to install, upgrade, and manage specific components individually using Chef Habitat.
-This approach reduces the complexity of maintaining the entire package.
diff --git a/content/ruby_gem_server.md b/content/ruby_gem_server.md
deleted file mode 100644
index ed893f4..0000000
--- a/content/ruby_gem_server.md
+++ /dev/null
@@ -1,52 +0,0 @@
-+++
-title = "Chef's Ruby gem server"
-draft = true
-
-[menu.chef_gem_server]
-title = "Chef's Ruby gem server"
-+++
-
-Chef's Ruby gem server distributes Chef's commercial and licensed Ruby gems. The server is hosted at .
-
-## Add Chef's gem server as a source
-
-Before you begin, you will need your valid [Progress Chef license key](https://docs.chef.io/licensing/license_key/).
-
-- Add Chef's Ruby gem server using `gem source --add`:
-
- ```sh
- gem sources --add https://v1:@rubygems.chef.io
- ```
-
- It returns a message that `rubygems.chef.io` has been added as a gem source.
-
-## Install a Ruby gem
-
-1. Optional: Verify that you've added Chef's Ruby gem server as a source:
-
- ```sh
- gem sources -l
- ```
-
- This returns a list of Ruby gem servers that should include `rubygems.chef.io`:
-
- ```sh
- *** CURRENT SOURCES ***
-
- https://rubygems.org/
- https://v1:@rubygems.chef.io
- ```
-
-1. Install a gem:
-
- ```sh
- gem install
- ```
-
- This installs the gem and displays a success message.
-
- For testing purposes, you can try installing `chef-test` or 'inspec-test' gem to verify that you can install from Chef's gem server:
-
- ```sh
- gem install chef-test-0.1.0.gem
- ```
diff --git a/content/workstation/_index.md b/content/workstation/_index.md
deleted file mode 100644
index 2ce2f62..0000000
--- a/content/workstation/_index.md
+++ /dev/null
@@ -1,83 +0,0 @@
-+++
-title = "Chef Workstation 26 RC3"
-linkTitle = "Workstation"
-
-[menu.workstation]
-title = "Overview"
-identifier = "workstation/overview"
-parent = "workstation"
-weight = 10
-+++
-
-Chef Workstation 26 RC3 delivers a comprehensive, unified toolkit that empowers developers, operations teams, and system administrators to automate infrastructure management and compliance workflows. This release provides all essential tools required to efficiently build, test, and deploy infrastructure code, ensuring seamless configuration management across diverse environments.
-
-Chef Workstation represents a complete development environment for Chef, consolidating critical tools into a single, cohesive package that streamlines the infrastructure-as-code workflow from development through production deployment.
-
-## What's new in RC3
-
-The RC3 release of Chef Workstation 26 represents a significant architectural evolution, featuring:
-
-- **Habitat-Based Architecture**: All core components have been migrated to Habitat packages, providing improved dependency management, isolation, and cross-platform consistency
-- **Enhanced Knife Integration**: Full Habitat packaging of Knife and associated drivers, enabling more reliable plugin management and execution
-- **InSpec Integration**: InSpec compliance and security testing framework is now included, providing comprehensive infrastructure and application auditing capabilities
-- **Unified Package Distribution**: Consolidated delivery mechanism through Habitat, simplifying installation and updates across enterprise environments
-- **Improved Tool Accessibility**: All included tools are accessible through standardized wrapper scripts for a consistent user experience
-
-This release builds upon the foundation established in Chef Workstation 26 RC2, with continued refinement of the Habitat-based packaging system and expanded tool support.
-
-This release builds upon the foundation established in RC2, with continued refinement of the Habitat-based packaging system and expanded tool support.
-
-## Included tools and components
-
-Chef Workstation RC3 includes the following fully integrated tools:
-
-### Core development tools
-
-- **Chef CLI (**`chef-cli`): Primary command-line interface for Chef development workflows, providing unified access to common Chef operations
-- **Chef Infra Client RC3**: Latest release candidate of the Chef Infra Client, enabling infrastructure automation and configuration management
-- **Knife**: Essential tool for interacting with Chef Infra Server, managing nodes, cookbooks, roles, and other Chef objects
-- **InSpec**: Latest release candidate of InSpec 7, enabling compliance and security testing.
-
-### Testing and quality assurance
-
-- **Chef Test Kitchen Enterprise**: Comprehensive testing framework for validating infrastructure code across multiple platforms and environments
-- **InSpec**: Compliance and security testing framework for auditing infrastructure and applications against security standards and regulations
-- **Cookstyle**: Ruby and Chef cookbook linting tool that enforces style guidelines and best practices
-- **Fauxhai**: Mock Ohai data generator for testing purposes, enabling rapid cookbook testing without requiring actual systems
-
-### Dependency and secret management
-
-- **Berkshelf**: Cookbook dependency manager that streamlines the process of managing and retrieving cookbook dependencies
-- **Chef Vault**: Secure data management tool for encrypting and managing secrets within Chef workflows
-- **Ohai**: System profiling tool that detects and reports system attributes for use in Chef recipes
-
-## Known limitations
-
-### `chef` command deprecation
-
-The legacy `chef` command is deprecated and isn't functional in this release. All users must transition to using `chef-cli` commands instead. This change aligns with Chef's strategic direction toward a more modular and maintainable command structure.
-
-```sh
-# Deprecated (will not work)
-chef generate cookbook my_cookbook
-
-# Correct usage
-chef-cli generate cookbook my_cookbook
-```
-
-## Support and feedback
-
-As this is a release candidate, we actively encourage feedback from the community:
-
-- **Issues and Bugs**: Report issues through the official Chef GitHub repository
-- **Feature Requests**: Submit enhancement requests through Chef's community forums
-- **Documentation**: See the [Chef documentation](https://docs.chef.io) for comprehensive guides and tutorials
-- **Community Support**: Join the [Chef Community Slack](https://community-slack.chef.io/) for real-time assistance
-
-## Additional resources
-
-- [Chef Workstation documentation](https://docs.chef.io/workstation/)
-- [Chef Habitat documentation](https://docs.chef.io/habitat/)
-- [Chef Infra Client documentation](https://docs.chef.io/chef_client_overview/)
-- [Test Kitchen documentation](https://kitchen.ci/)
-- [Cookstyle documentation](https://docs.chef.io/workstation/cookstyle/)
diff --git a/content/workstation/kitchen/_index.md b/content/workstation/kitchen/_index.md
deleted file mode 100644
index 7636dbf..0000000
--- a/content/workstation/kitchen/_index.md
+++ /dev/null
@@ -1,41 +0,0 @@
-+++
-title = "Chef Test Kitchen Enterprise overview"
-linkTitle = "Test Kitchen Enterprise"
-
-[menu.workstation]
-title = "Overview"
-identifier = "workstation/tke/overview"
-parent = "workstation/tke"
-weight = 10
-+++
-
-Use Chef Test Kitchen Enterprise to automatically test cookbooks across any combination of platforms and test suites:
-
-- Test suites are defined in a kitchen.yml file. See the configuration documentation for options and syntax information.
-- Supports cookbook testing across many cloud providers and virtualization technologies.
-- Uses a comprehensive set of operating system base images from Chef's Bento project.
-
-The key concepts in Test Kitchen Enterprise are:
-
-- **Platform**: The operating system or target environment where a cookbook is tested.
-- **Suite**: The Chef Infra Client configuration, including a Policyfile or run-list, and optionally, node attributes.
-- **Instance**: The combination of a specific platform and suite, each with an autogenerated name.
-- **Driver**: Manages the lifecycle actions for an instance, such as creating the instance, converging it (installing Chef Infra Client, uploading cookbooks, running Chef Infra Client, etc.), setting up testing, verifying suites post-converge, and destroying the instance.
-- **Provisioner**: The component that runs the Chef Infra Client code, using either chef-zero or chef-solo with the chef_zero and chef_solo provisioners, respectively.
-
-## What's the difference between Test Kitchen and Chef Test Kitchen Enterprise?
-
-We forked the community version Test Kitchen and rebranded it as Chef Test Kitchen Enterprise starting with version 1.0.0.
-The repository for Test Kitchen Enterprise is [chef/chef-test-kitchen-enterprise](https://github.com/chef/chef-test-kitchen-enterprise).
-
-This update focuses on branding changes and supports passing licenses to Chef Infra Client 19. These changes are only in Chef Test Kitchen Enterprise and aren't backported to the community version of Test Kitchen.
-
-The way you run Test Kitchen Enterprise remains unchanged. The [community Test Kitchen documentation](https://kitchen.ci/docs/getting-started/introduction/) and [Chef-hosted Test Kitchen documentation](https://docs.chef.io/workstation/kitchen/) are still accurate.
-
-We plan to add more drivers and features, which Chef will support, to Chef Test Kitchen Enterprise in future releases.
-
-{{< note >}}
-
-The only supported driver in Chef Infra Client 19 RC3 is the kitchen-dokken driver.
-
-{{< /note >}}
diff --git a/content/workstation/kitchen/install.md b/content/workstation/kitchen/install.md
deleted file mode 100644
index bef2b3b..0000000
--- a/content/workstation/kitchen/install.md
+++ /dev/null
@@ -1,56 +0,0 @@
-+++
-title = "Install Chef Test Kitchen Enterprise"
-
-[menu.workstation]
-title = "Install Test Kitchen Enterprise"
-identifier = "workstation/tke/install"
-parent = "workstation/tke"
-weight = 20
-+++
-
-Chef Test Kitchen Enterprise is a component of Chef Workstation.
-However, you can also install it as a standalone application or install a different version than the one bundled with Workstation.
-
-## Supported platforms
-
-Chef Test Kitchen Enterprise is supported on Linux x86-64 systems.
-
-## Install
-
-If you haven't already installed Chef Habitat, follow these steps to install and set it up.
-For more information, see the [Chef Habitat install documentation](https://docs.chef.io/habitat/install_habitat/).
-
-1. Download and install Chef Habitat:
-
- ```sh
- curl https://raw.githubusercontent.com/habitat-sh/habitat/main/components/hab/install.sh | sudo bash -s -- -c stable
- ```
-
-1. Verify Chef Habitat is installed.
-
- ```sh
- hab --version
- ```
-
- Chef Habitat returns the installed version.
-
-1. Use Chef Habitat to install the Chef Test Kitchen Enterprise package:
-
- ```sh
- sudo hab pkg install --binlink --force chef/chef-test-kitchen-enterprise --channel unstable
- ```
-
- Chef Habitat downloads and installs Chef Test Kitchen Enterprise, it's components, and the `chef-cli` and `kitchen` CLI tools.
-
-1. Verify these tools are installed:
-
- ```sh
- chef-cli --version
- kitchen --version
- ```
-
- You can also verify that the Test Kitchen Enterprise package is installed in `/hab/pkgs/chef/chef-test-kitchen-enterprise/1.0.5`.
-
-## Next steps
-
-After you've installed Chef Test Kitchen Enterprise, add your [Progress Chef license](/workstation/license).
diff --git a/content/workstation/kitchen/run.md b/content/workstation/kitchen/run.md
deleted file mode 100644
index 5d60ba2..0000000
--- a/content/workstation/kitchen/run.md
+++ /dev/null
@@ -1,68 +0,0 @@
-+++
-title = "Run Test Kitchen"
-linkTitle = "Using Test Kitchen"
-
-[menu.workstation]
-title = "Run Test Kitchen"
-identifier = "workstation/tke/using_test_kitchen"
-parent = "workstation/tke"
-weight = 40
-+++
-
-For the Chef Infra Client RC3 release, Chef Test Kitchen Enterprise only supports the kitchen-dokken driver.
-This allows us to create containers, using Podman or Docker Desktop, of various realistic operating systems and configure Chef Infra Client 19 for converge and verify operations.
-By default, this driver uses the chef/chef-hab container volume from Docker Hub to attach the Chef Infra Client 19 and Chef InSpec 7 (the default verifier) to the test container.
-
-## Example `kitchen.yaml` for Chef Infra Client 19
-
-The following `kitchen.yaml` file example defines tests that run in Chef Infra Client 19:
-
-```yaml
----
-driver:
- name: dokken
- privileged: true
- chef_version: unstable
-
-provisioner:
- name: dokken
-
-transport:
- name: dokken
-
-verifier:
- name: inspec
-
-platforms:
- - name: ubuntu-20.04
- - name: centos-8
-
-suites:
- - name: default
- run_list:
- - "cookbook"
- verifier:
- inspec_tests:
- - test/integration/default
-```
-
-## Provision earlier versions of Chef Infra Client
-
-To provision containers to use Chef Infra Client version 18 or earlier, modify the driver configuration in the `kitchen.yml` file as shown below.
-Set `chef_image` to `chef/chef` and set the version of Infra Client in `chef_version`.
-
-```yaml
-driver:
- name: dokken
- privileged: true
- chef_version: 18.3.0
- chef_image: "chef/chef"
-```
-
-## Run converge and verify tests
-
-The [Test Kitchen documentation](https://kitchen.ci/docs/getting-started/creating-cookbook/) describes the process for creating converge and verify tests. The Dokken driver documentation is in the [kitchen-dokken GitHub repository](https://github.com/chef/kitchen-dokken).
-
-## Habitat-based changes
-
-The Chef Infra Client 19 will be accessible using Habitat instead of the public Omnitruck APIs. Consequently, we've updated the provisioner to facilitate the installation of the Habitat-based Chef Infra Client, including passing through the license required from `kitchen.yml` file.
diff --git a/content/workstation/uninstall.md b/content/workstation/uninstall.md
deleted file mode 100644
index 68f048a..0000000
--- a/content/workstation/uninstall.md
+++ /dev/null
@@ -1,52 +0,0 @@
-+++
-title = "Uninstall Chef Workstation and its tools"
-
-[menu.workstation]
-title = "Uninstall"
-identifier = "workstation/uninstall"
-parent = "workstation"
-weight = 50
-+++
-
-The page documents how to uninstall Chef Workstation and its component tools.
-
-## Uninstall Chef Workstation
-
-To uninstall Chef Workstation, use the [`hab pkg uninstall`](https://docs.chef.io/habitat/habitat_cli/#hab-pkg-uninstall) command:
-
-```sh
-sudo hab pkg uninstall chef/chef-workstation
-```
-
-## Uninstall Chef Workstation component packages
-
-To uninstall a Workstation tool, use the [`hab pkg uninstall`](https://docs.chef.io/habitat/habitat_cli/#hab-pkg-uninstall) command:
-
-```sh
-sudo hab pkg uninstall
-```
-
-Replace `` with one of the following packages:
-
-- `chef/berkshelf`
-- `chef/chef-cli`
-- `chef/chef-infra-client`
-- `chef/chef-test-kitchen-enterprise`
-- `chef/chef-vault`
-- `chef/cookstyle`
-- `chef/fauxhai`
-- `chef/knife`
-- `chef/ohai`
-
-## Uninstall a specific package version
-
-You can uninstall a specific package version. For example:
-
-```sh
-sudo hab pkg uninstall
-```
-
-Replace `` with one of the following:
-
-- the package and version, for example `chef//`.
-- the package version and build, for example `chef///`
diff --git a/layouts/partials/infra_resource_data.html b/layouts/partials/infra_resource_data.html
new file mode 100644
index 0000000..f9023b5
--- /dev/null
+++ b/layouts/partials/infra_resource_data.html
@@ -0,0 +1,629 @@
+{{ $yaml_file := .yaml_file }}
+{{ $product := .product }}
+{{ $resource_ID := .resource_ID }}
+{{ $heading_base_level := .heading_base_level }}
+{{ $include_resource_id := .include_resource_id }}
+
+{{ if $include_resource_id }}
+ {{ $resource_ID = printf "%s%s" "-" $resource_ID }}
+{{ end }}
+
+{{ with index $yaml_file "resource_description_list" }}
+ {{ range . }}
+ {{ range $key, $value := . }}
+ {{ if eq $key "markdown" }}
+
{{- $value | markdownify -}}
+ {{ end }}
+ {{ if eq $key "note" }}
+
+
Note
+
+ {{ range $subkey, $subvalue := $value }}
+ {{ if eq $subkey "markdown" }}
+
+ {{ end }}
+ {{ end }}
+ {{ end }}
+{{ end }}
+
+{{ if and ( ne (index $yaml_file "resource_new_in") "" ) ( index $yaml_file "resource_new_in" )}}
+ {{ if eq $product "infra" }}
+
New in Chef Infra Client {{ index $yaml_file "resource_new_in" }}.
+ {{ else if ( eq $product "desktop") }}
+
New in Chef Desktop {{ index $yaml_file "resource_new_in" }}.
+ {{ end }}
+{{ end }}
+
+
+
+Properties
+
+{{ if or (index $yaml_file "properties_shortcode") (index $yaml_file "properties_list") }}
+ {{ with index $yaml_file "properties_list" }}
+
The {{ index $yaml_file "resource" }} resource has the following properties:
+ {{ range . }}
+
+ {{ if and (.property) (ne .property nil) }}
+
+ {{ .property }}
+
+ {{ end }}
+
+
+ {{ if ne .ruby_type nil }}
+ Ruby Type: {{ .ruby_type }} {{ if .default_value }}| Default Value:{{ .default_value }}{{ end }} {{ if .required }}| REQUIRED{{ end }}
+ {{ if .allowed_values }}Allowed Values:{{ .allowed_values }}{{ end }}
+
+ {{ end }}
+
+ {{ range .description_list }}
+ {{ range $key, $value := . }}
+ {{ if eq $key "markdown" }}
+
{{- $value | markdownify -}}
+ {{ end }}
+
+ {{ if eq $key "note" }}
+
+
Note
+
+ {{ range $subkey, $subvalue := $value }}
+ {{ if eq $subkey "markdown" }}
+
-
-## Chef Product Names for Omnibus
-
-See the [Supported Versions]({{< relref "versions" >}}) documentation for information about the support status of individual products.
-
-This is a list of currently supported products that you can install with the Omnibus API.
-
-| Product | Product Key |
-| ------- | ------------ |
-| Chef Infra Client | chef |
-| Chef Backend | chef-backend |
-| Chef Infra Server | chef-server |
-| Chef Workstation | chef-workstation |
-| Chef InSpec | inspec |
-| Management Console | manage |
-| Supermarket | supermarket |
-
-### Examples
-
-#### Get the Latest Build
-
-To get the latest supported build for Ubuntu 20.04, enter the following:
-
-```plain
-https://omnitruck.chef.io/stable/chef/metadata?p=ubuntu&pv=20.04&m=x86_64
-```
-
-to return something like:
-
-```plain
-sha1 3fe8e8a2f443675f9b82e876cdac8200104451f2
-sha256 9f1c1a2c0b1f4e8494664386437bf32f0cb5cbfbd4cb9d23e327767fc65581dc
-url https://packages.chef.io/files/stable/chef/17.7.29/ubuntu/20.04/chef_17.7.29-1_amd64.deb
-version 17.7.29
-```
-
-#### Download Directly
-
-To use cURL to download a package directly, enter the following:
-
-```bash
-curl -LOJ 'https://omnitruck.chef.io///download?p=debian&pv=10&m=x86_64'
-```
-
-To use GNU Wget to download a package directly, enter the following:
-
-```bash
-wget --content-disposition https://omnitruck.chef.io///download?p=debian&pv=10&m=x86_64
-```
diff --git a/content/attribute_persistence.md b/content/attribute_persistence.md
index e3e175d..58de3b6 100644
--- a/content/attribute_persistence.md
+++ b/content/attribute_persistence.md
@@ -16,13 +16,13 @@ Attributes set using `chef-client -j` with a JSON file have normal precedence an
Chef Infra Client rebuilds these attributes using automatic attributes collected by Ohai at the beginning of each Chef Infra Client
run, and then uses default and override attributes that are specified in cookbooks, roles, environments, and Policyfiles.
All attributes are then merged and applied to the node according to attribute precedence.
-The attributes that were applied to the node are saved to the Chef Infra Server as part of the node object at the conclusion of each Chef Infra Client run.
+The attributes that were applied to the node are saved to Chef Infra Server as part of the node object at the conclusion of each Chef Infra Client run.
## Limiting Attribute Persistence
-Some organizations find it helpful to control attribute data stored by the Chef Infra Server, whether to limit the disk and CPU resources used when processing unused attributes, or to keep secrets like API keys from being submitted to the server.
+Some organizations find it helpful to control attribute data stored by Chef Infra Server, whether to limit the disk and CPU resources used when processing unused attributes, or to keep secrets like API keys from being submitted to the server.
For example, your organization may find the data from the Ohai `Package` plugin useful when writing cookbooks, but don't see the need in saving ~100kB of package information for each Chef Infra Client run.
-Attribute data will still be available on the node within cookbooks, but any information you limit won't be saved to the Chef Infra Server for use in searches.
+Attribute data will still be available on the node within cookbooks, but any information you limit won't be saved to Chef Infra Server for use in searches.
You can block or allow the saving of specific key using the [`client.rb`](/config_rb_client/) file.
Each setting is an array of keys specifying each attribute to be filtered out or allowed. Use a "/" to separate subkeys, for example `network/interfaces`.
diff --git a/content/attribute_sources.md b/content/attribute_sources.md
index f0de233..a8e8bdf 100644
--- a/content/attribute_sources.md
+++ b/content/attribute_sources.md
@@ -32,7 +32,7 @@ Notes:
- Many attributes are collected by Ohai on each individual node at the
start of every Chef Infra Client run
- The attributes that are maintained in the chef-repo are uploaded to
- the Chef Infra Server from the workstation, periodically
+ Chef Infra Server from the workstation, periodically
- Chef Infra Client will pull down the node object from the Chef Infra
Server and then reset all the attributes except `normal`. The node
object will contain the attribute data from the previous Chef Infra
@@ -44,7 +44,7 @@ Notes:
required)
- Chef Infra Client will rebuild the attribute list and apply
attribute precedence while configuring the node
-- Chef Infra Client pushes the node object to the Chef Infra Server at
+- Chef Infra Client pushes the node object to Chef Infra Server at
the end of a Chef Infra Client run; the updated node object on the
Chef Infra Server is then indexed for search and is stored until the
next Chef Infra Client run
diff --git a/content/aws_marketplace.md b/content/aws_marketplace.md
deleted file mode 100644
index d577611..0000000
--- a/content/aws_marketplace.md
+++ /dev/null
@@ -1,188 +0,0 @@
-+++
-title = "AWS Marketplace"
-draft = false
-
-gh_repo = "chef-web-docs"
-
-aliases = ["/aws_marketplace.html", "/aws_ami.html"]
-
-product = ["client", "workstation", "automate"]
-
-[menu]
- [menu.infra]
- title = "AWS Marketplace"
- identifier = "chef_infra/integrations/aws_marketplace.md AWS Marketplace"
- parent = "chef_infra/integrations"
- weight = 10
-+++
-
-Chef Automate is an enterprise platform that allows developers, operations, and security engineers to collaborate on application and infrastructure changes with speed and at scale. Chef Automate provides actionable insights across data centers and cloud providers, wherever your nodes live.
-
-Chef Automate is the center of the modern Chef platform, providing users with a single source of truth for infrastructure, security, and application automation. The comprehensive dashboard offers real-time views of your configuration management activity. Chef Automate comes bundled with the latest Chef Infra Server, providing the core tools you need to manage your enterprise infrastructure. Data collection is enabled by default, allowing your nodes to report activity in real time. This instance is free for 60 days, or you can bring your own license (BYOL).
-
-Use this instance with Chef Workstation installed on your laptop or a separate AWS instance.
-
-{{< readfile file="content/reusable/md/workstation.md" >}}
-
-{{< readfile file="content/reusable/md/automate_ha_support.md" >}}
-
-## Installation
-
-Select [Chef Automate](https://aws.amazon.com/marketplace/pp/prodview-r26bs6uknftps?) in the AWS Marketplace.
-
-The Chef Automate AWS deployment uses [CloudFormation](https://aws.amazon.com/cloudformation/). [Download the CloudFormation template](https://aws-ami-chef-automate-v2.s3.amazonaws.com/cloudformation_template.yaml) or use the [view the template in CloudFormation Designer](https://us-east-1.console.aws.amazon.com/cloudformation/designer/home?region=us-east-1&templateURL=https://s3.amazonaws.com/awsmp-fulfillment-cf-templates-prod/658820ac-955d-4f73-bbcd-ab19b598d852.caadc0d6-b62a-4b83-d9b0-ec685d27c0bc.template)
-
-Every CloudFormation Stack deployment creates a new [Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) (VPC).
-
-{{< note >}}
-AWS provides five VPCs for each region. If you require more VPCs, please contact [AWS Support](https://aws.amazon.com/contact-us/).
-{{< /note >}}
-
-### Start Chef Automate with CloudFormation
-
-1. Enter the following values for your deployment:
-
- Stack Name
- : `Chef-Automate`
-
- EC2RootVolumeSize
- : `Default: 40`
-
- Instance Type
- : `Default: t2.xlarge`
-
- KeyName
- : _Enter your existing keypair._
-
- SecurityGroupCidrIp
- : `0.0.0.0/0`
-
- SubnetCIDR
- : `10.0.0.0/24`
-
- VpcCIDR
- : `10.0.0.0/16`
-
-1. Select **Next** after entering these values.
-
-1. Configure the CloudFormation stack options:
-
- 1. Create a tag for your stack with **Key** set to `Name` and **Value** to `Chef-automate-stack`.
-
- 1. Set permissions for your stack:
-
- 1. Create an IAM role with `AmazonEC2FullAccess` to enable resource creation using the CloudFormation template.
- 1. Once that role is created, select the IAM role from the dropdown menu.
-
- 1. Configure stack failure options:
-
- AWS provides two stack-failure options:
-
- Roll back all stack resources
- : In case of failure, it should rollback all created resources (`Default: Roll back all stack resources`).
-
- Preserve successfully provisioned resources
- : In case of failure, it will rollback only failed resources.
-
- 1. Configure advanced options:
-
- 1. Set the stack policy.
-
- The stack policy defines the update actions that can be performed on resources.`Default: No stack policy`.
-
- 1. Set the rollback configuration.
-
- AWS CloudFormation will monitor the state of your application during stack creation and updating. For more information, see [Amazon's documentation on rollback triggers](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-rollback-triggers.html).
-
- 1. Configure notification options:
-
- Create or attach an AWS Simple Notification Service (SNS) which will send email notifications about the stack creation process.
-
- 1. Set the stack creation options:
-
- Timeout
- : If specified and stack creation isn't completed in that time, CloudFormation will roll back the stack.
-
- Termination Protection
- : Termination protection prevents a user from deleting a stack.
-
-1. Select **Next** to create your Chef Automate deployment. This process can take several minutes.
-
-For additional information about these options, see [Amazon's documentation on CloudFormation stack options](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-add-tags.html).
-
-## Post-Installation
-
-1. Navigate to the AWS deployment **Outputs** tab and locate the Chef Automate URL, user name, and password. You will need these in the next steps.
-
-
-1. Open your browser and paste the Chef Automate URL, which will open an alert page.
-
-1. Select **Advanced** and continue.
-.
-
-1. Enter your **Username** and **Password** and select **Sign In**.
-
-
-1. Fill out the registration form and [Accept the Chef License](/licensing/accept/).
-
-1. Select **Register** to enter Chef Automate.
-
-
-1. Congratulations! You've started Chef Automate!
-
-
-## Add Chef Servers
-
-1. Add Chef-Server Details, select the Add Chef Infra Server Button.
-
-
-1. Enter the server name, FQDN, and IP address. Then select **Add Chef Infra Server** to create the server.
-
- Name
- : Add the name of the Chef Infra Server.
-
- FQDN
- : Enter the same as the Chef Automate FQDN.
-
- IP Address
- : Public IP address of the EC2 instance.
-
- {{< figure src="/images/automate/add-chef-server-popup-menu.png" alt="Add Chef Infra Server Form" width="500" >}}
-
-1. The Chef Infra Server will appear in the list of servers. Selecting the server allows you to view information about it.
-
-
-1. Select **Add Chef Organization**.
-{{< figure src="/images/chef_automate_add_org_page.png" style="width: 30%;" >}}
-
-1. Enter the following information:
-
- Name
- : demo
-
- Admin User
- : admin
-
- Admin Key
- : _copy the key from starter kit_
-
-1. Select **Add Chef Organization**.
-{{< figure src="/images/OrgPageDetails.png" alt="Select the Add Chef Organization button to complete this actio" width="500" >}}
-
-## AWS Deployment Security
-
-Update the AWS Deployment **Security Group** to require source IP addresses for a secure SSH connection.
-
-1. Select the **Instance Security** group in the **Resources** tab of your AWS Chef Automate deployment.
-
-
-1. Select the **Security Group ID** for your Chef Automate deployment.
-
-
-1. Select **Edit inbound rules**.
-
-
-1. Select **Add rule** and then **SSH** and enter the source IP.
-
-1. Select **Save rules** to finish.
-
diff --git a/content/azure_chef_cli.md b/content/azure_chef_cli.md
index 53fe0e3..b4f2173 100644
--- a/content/azure_chef_cli.md
+++ b/content/azure_chef_cli.md
@@ -200,7 +200,7 @@ The extension has the following options that can be provided in the
`chef_server_url`
-: The URL for the Chef Infra Server.
+: The URL for Chef Infra Server.
`environment`
@@ -212,7 +212,7 @@ The extension has the following options that can be provided in the
`validation_client_name`
-: The name of the chef-validator key that Chef Infra Client uses to access the Chef Infra Server during the initial Chef Infra Client run.
+: The name of the chef-validator key that Chef Infra Client uses to access Chef Infra Server during the initial Chef Infra Client run.
`node_ssl_verify_mode`
@@ -220,7 +220,7 @@ The extension has the following options that can be provided in the
`node_verify_api_cert`
-: Verify the SSL certificate on the Chef Infra Server. When `true`, Chef Infra Client always verifies the SSL certificate. When `false`, Chef Infra Client uses the value of `ssl_verify_mode` to determine if the SSL certificate requires verification.
+: Verify the SSL certificate on Chef Infra Server. When `true`, Chef Infra Client always verifies the SSL certificate. When `false`, Chef Infra Client uses the value of `ssl_verify_mode` to determine if the SSL certificate requires verification.
#### Protected settings
@@ -236,7 +236,7 @@ The following options can be provided to the extension through the `protectedSet
`client_pem`
-: A client key that will be used to communication with the Chef Infra Server.
+: A client key that will be used to communication with Chef Infra Server.
### Examples
diff --git a/content/azure_powershell.md b/content/azure_powershell.md
index d47931f..dbc3fec 100644
--- a/content/azure_powershell.md
+++ b/content/azure_powershell.md
@@ -86,7 +86,7 @@ This cmdlet has the following options:
`-ChefServerUrl `
-: The URL for the Chef Infra Server.
+: The URL for Chef Infra Server.
`-ClientRb `
@@ -102,7 +102,7 @@ This cmdlet has the following options:
`-OrganizationName `
-: The name of the organization on the Chef Infra Server.
+: The name of the organization on Chef Infra Server.
`-RunList `
@@ -110,7 +110,7 @@ This cmdlet has the following options:
`-ValidationClientName `
-: The name of the chef-validator key Chef Infra Client uses to access the Chef Infra Server during the initial Chef Infra Client run.
+: The name of the chef-validator key Chef Infra Client uses to access Chef Infra Server during the initial Chef Infra Client run.
`-ValidationPem `
diff --git a/content/chef_client_overview.md b/content/chef_client_overview.md
index 3d2bdee..ce7ed54 100644
--- a/content/chef_client_overview.md
+++ b/content/chef_client_overview.md
@@ -56,6 +56,12 @@ You can customize run lists for different node types or environments.
Ohai is a system profiling tool that collects detailed information about your nodes, including hardware details, network configuration, and operating system data.
Chef Infra Client uses this information to make intelligent configuration decisions.
+### Agentless
+
+Agentless allows you to execute Infra Client runs on a target node over SSH without having Chef Infra Client installed on the node.
+
+For more details and setup instructions, see the [Agentless documentation](/target_mode/).
+
## How Chef Infra Client works
Chef Infra Client operates on a pull-based model where nodes periodically contact Chef Infra Server to retrieve their configuration policies.
diff --git a/content/chef_client_security.md b/content/chef_client_security.md
index 004500c..95e7317 100644
--- a/content/chef_client_security.md
+++ b/content/chef_client_security.md
@@ -15,11 +15,11 @@ aliases = ["/chef_client_security.html", "/auth.html"]
+++
-{{< readfile file="content/server/reusable/md/chef_auth.md" >}}
+{{< readfile file="content/reusable/md/server/chef_auth.md" >}}
## Authentication
-{{< readfile file="content/server/reusable/md/chef_auth_authentication.md" >}}
+{{< readfile file="content/reusable/md/server/chef_auth_authentication.md" >}}
### chef-validator
@@ -29,7 +29,7 @@ aliases = ["/chef_client_security.html", "/auth.html"]
## SSL certificates
-{{< readfile file="content/server/reusable/md/server_security_ssl_cert_client.md" >}}
+{{< readfile file="content/reusable/md/server/server_security_ssl_cert_client.md" >}}
### trusted_certs directory
@@ -52,7 +52,7 @@ When you install Chef Workstation, it creates a `trusted_certs` directory locate
##### Chef Infra Client nodes
-When you bootstrap a node, the Chef Infra Client copies the SSL certificates for the Chef Infra Server onto the node. The `trusted_certs` directory on the node is located at:
+When you bootstrap a node, the Chef Infra Client copies the SSL certificates for Chef Infra Server onto the node. The `trusted_certs` directory on the node is located at:
- Windows: `C:\chef\trusted_certs`
- All other systems: `/etc/chef/trusted_certs`
@@ -75,8 +75,8 @@ To use a custom CA bundle, update the environment variable to specify the path t
Use following [`client.rb` file]({{< relref "config_rb_client" >}}) settings to manage SSL certificate preferences:
`local_key_generation`
-: Whether the Chef Infra Server or Chef Infra Client generates the private/public key pair.
- When `true`, Chef Infra Client generates the key pair and then sends the public key to the Chef Infra Server.
+: Whether Chef Infra Server or Chef Infra Client generates the private/public key pair.
+ When `true`, Chef Infra Client generates the key pair and then sends the public key to Chef Infra Server.
Default value: `true`.
@@ -87,12 +87,12 @@ Use following [`client.rb` file]({{< relref "config_rb_client" >}}) settings to
: The location of the OpenSSL key file. Chef Infra Client generates this setting automatically.
`ssl_client_cert`
-: The OpenSSL X.509 certificate for mutual certificate validation. Required for mutual certificate validation on the Chef Infra Server.
+: The OpenSSL X.509 certificate for mutual certificate validation. Required for mutual certificate validation on Chef Infra Server.
Default value: `nil`.
`ssl_client_key`
-: The OpenSSL X.509 key used for mutual certificate validation. Required for mutual certificate validation on the Chef Infra Server.
+: The OpenSSL X.509 key used for mutual certificate validation. Required for mutual certificate validation on Chef Infra Server.
Default value: `nil`.
@@ -102,12 +102,12 @@ Use following [`client.rb` file]({{< relref "config_rb_client" >}}) settings to
Allowed values:
- Use `:verify_none` to run without validating any SSL certificates.
- - Use `:verify_peer` to validate all SSL certificates, including the Chef Infra Server connections, S3 connections, and any HTTPS `remote_file` resource URLs used in a Chef Infra Client run.
+ - Use `:verify_peer` to validate all SSL certificates, including Chef Infra Server connections, S3 connections, and any HTTPS `remote_file` resource URLs used in a Chef Infra Client run.
Default value: `:verify_peer`.
`verify_api_cert`
-: Verify the SSL certificate on the Chef Infra Server.
+: Verify the SSL certificate on Chef Infra Server.
If `true`, Chef Infra Client always verifies the SSL certificate. If `false`, Chef Infra Client uses `ssl_verify_mode` to determine if the SSL certificate requires verification.
@@ -120,26 +120,26 @@ Use following [`client.rb` file]({{< relref "config_rb_client" >}}) settings to
The Chef Infra Client includes two knife commands for managing SSL certificates:
- Use [knife ssl check](/workstation/knife_ssl_check/) to troubleshoot SSL certificate issues.
-- Use [knife ssl fetch](/workstation/knife_ssl_fetch/) to pull down a certificate from the Chef Infra Server to the `/.chef/trusted_certs` directory on the workstation.
+- Use [knife ssl fetch](/workstation/knife_ssl_fetch/) to pull down a certificate from Chef Infra Server to the `/.chef/trusted_certs` directory on the workstation.
After the workstation has the correct SSL certificate, bootstrap operations from that workstation uses the certificate in the `/.chef/trusted_certs` directory during the bootstrap operation.
#### knife ssl check
-Run [`knife ssl check`]({{< relref "/workstation/knife_ssl_check/" >}}) to verify the state of the SSL certificate, and then use the response to help troubleshoot any issues.
+Run [`knife ssl check`](https://docs.chef.io/workstation/knife_ssl_check/) to verify the state of the SSL certificate, and then use the response to help troubleshoot any issues.
##### Verified
-{{< readfile file="content/workstation/reusable/md/knife_ssl_check_verify_server_config.md" >}}
+{{< readfile file="content/reusable/md/workstation/knife_ssl_check_verify_server_config.md" >}}
##### Unverified
-{{< readfile file="content/workstation/reusable/md/knife_ssl_check_bad_ssl_certificate.md" >}}
+{{< readfile file="content/reusable/md/workstation/knife_ssl_check_bad_ssl_certificate.md" >}}
#### knife ssl fetch
-Run [`knife ssl fetch`]({{< relref "/workstation/knife_ssl_fetch/" >}}) to download the self-signed certificate from the Chef Infra Server to the `/.chef/trusted_certs` directory on a workstation.
+Run [`knife ssl fetch`](https://docs.chef.io/workstation/knife_ssl_fetch/) to download the self-signed certificate from Chef Infra Server to the `/.chef/trusted_certs` directory on a workstation.
##### Verify checksums
-{{< readfile file="content/workstation/reusable/md/knife_ssl_fetch_verify_certificate.md" >}}
+{{< readfile file="content/reusable/md/workstation/knife_ssl_fetch_verify_certificate.md" >}}
diff --git a/content/chef_compliance_phase.md b/content/chef_compliance_phase.md
index 212285a..d2bc634 100644
--- a/content/chef_compliance_phase.md
+++ b/content/chef_compliance_phase.md
@@ -49,7 +49,7 @@ default['audit']['compliance_phase'] = true
Setting one or more Chef InSpec profiles turns on the Compliance Phase in a Chef Infra Client run. The presence of this configuration in your attributes file instructs Chef Infra Client to fetch and execute the specific Chef InSpec profiles and write the results to disk using the default `cli` and `json-file` reporters.
-Retrieve [Chef InSpec profiles]({{< relref "inspec/profiles/" >}}) from Chef Automate, Supermarket, a local file, GitHub, or over HTTP with the `node['audit']['profiles']` attribute.
+Retrieve [Chef InSpec profiles](https://docs.chef.io/inspec/profiles/) from Chef Automate, Supermarket, a local file, GitHub, or over HTTP with the `node['audit']['profiles']` attribute.
The following examples:
@@ -78,7 +78,7 @@ The following examples:
}
```
{{< warning >}}
- Fetching profiles from Chef Automate requires setting `data_collector.server_url` and `data_collector.token` in your `client.rb` to fetch profiles from Chef Automate. This configuration is described in more detail in the Chef Automate [data collector documentation]({{< relref "automate/data_collection/" >}}).
+ Fetching profiles from Chef Automate requires setting `data_collector.server_url` and `data_collector.token` in your `client.rb` to fetch profiles from Chef Automate. This configuration is described in more detail in the Chef Automate [data collector documentation](https://docs.chef.io/automate/data_collection/).
{{< /warning >}}
{{< /foundation_tabs_panel >}}
{{< foundation_tabs_panel panel-id="supermarket-panel" >}}
@@ -127,7 +127,7 @@ The following examples:
### Fetch Profiles
-Set the fetcher attribute with `default['audit']['fetcher']` to retrieve Chef InSpec compliance profiles from either Chef Automate or Chef Infra Server in addition to the location defined by `default ['audit']['profile']`. Left unset, the Compliance Phase defaults to the [fetchers included in Chef InSpec]({{< relref "/inspec/profiles#profile-dependencies" >}}). Chef Infra and Chef InSpec fetchers are mutually exclusive so, you can only use one of these configurations.
+Set the fetcher attribute with `default['audit']['fetcher']` to retrieve Chef InSpec compliance profiles from either Chef Automate or Chef Infra Server in addition to the location defined by `default ['audit']['profile']`. Left unset, the Compliance Phase defaults to the [fetchers included in Chef InSpec](https://docs.chef.io/inspec/profiles#profile-dependencies). Chef Infra and Chef InSpec fetchers are mutually exclusive so, you can only use one of these configurations.
The following examples:
@@ -155,7 +155,7 @@ The following examples:
default['audit']['fetcher'] = 'chef-automate'
```
{{< warning >}}
- Fetching profiles from Chef Automate requires setting `data_collector.server_url` and `data_collector.token` in your `client.rb` to fetch profiles from Chef Automate. This configuration is described in more detail in the Chef Automate [data collector documentation]({{< relref "automate/data_collection/" >}}).
+ Fetching profiles from Chef Automate requires setting `data_collector.server_url` and `data_collector.token` in your `client.rb` to fetch profiles from Chef Automate. This configuration is described in more detail in the Chef Automate [data collector documentation](https://docs.chef.io/automate/data_collection/).
{{< /warning >}}
{{< /foundation_tabs_panel >}}
{{< foundation_tabs_panel panel-id="server-fetcher" >}}
@@ -213,7 +213,7 @@ The following examples:
default['audit']['reporter'] = 'chef-automate'
```
{{< warning >}}
- Reporting Compliance Phase results directly to Chef Automate requires setting `data_collector.server_url` and `data_collector.token` in your `client.rb` to fetch profiles from Chef Automate. This configuration is described in more detail in the Chef Automate [data collector documentation]({{< relref "automate/data_collection/" >}}).
+ Reporting Compliance Phase results directly to Chef Automate requires setting `data_collector.server_url` and `data_collector.token` in your `client.rb` to fetch profiles from Chef Automate. This configuration is described in more detail in the Chef Automate [data collector documentation](https://docs.chef.io/automate/data_collection/).
{{< /warning >}}
{{< /foundation_tabs_panel >}}
{{< foundation_tabs_panel panel-id="server-reporter" >}}
@@ -269,7 +269,7 @@ You can upload profiles to Chef Automate using the [Chef Automate API](/automate
### Waivers
-Use [waivers]({{< relref "/inspec/waivers" >}}) to mark individual failing controls as administratively accepted, either on a temporary or permanent basis.
+Use [waivers](https://docs.chef.io/inspec/waivers/) to mark individual failing controls as administratively accepted, either on a temporary or permanent basis.
To use waivers:
@@ -283,11 +283,11 @@ default['audit']['waiver_file'] = "waivers.yaml"
### External Data
-Chef InSpec profiles should be self-contained and independent from external data. Sometimes, a profile's test may exhibit different behavior depending on aspects of the node being tested and in these cases, you may want to use external data. Chef InSpec profiles accept [inputs]({{< relref "/inspec/inputs" >}}) that let you customize the test.
+Chef InSpec profiles should be self-contained and independent from external data. Sometimes, a profile's test may exhibit different behavior depending on aspects of the node being tested and in these cases, you may want to use external data. Chef InSpec profiles accept [inputs](https://docs.chef.io/inspec/inputs/) that let you customize the test.
#### Chef InSpec Input
-You can pass [Chef InSpec inputs]({{< relref "/inspec/inputs" >}}) to the Chef InSpec runner. Chef InSpec inputs were previously called `attributes` and you will set them in an `['audit']['attributes']` hash in your attributes file.
+You can pass [Chef InSpec inputs](https://docs.chef.io/inspec/inputs/) to the Chef InSpec runner. Chef InSpec inputs were previously called `attributes` and you will set them in an `['audit']['attributes']` hash in your attributes file.
Any data added to `['audit']['attributes']` as a hash is passed to Chef InSpec as individual attributes.
```ruby
@@ -559,9 +559,9 @@ Depending on your setup, there are some limits you need to be aware of. A common
#### 401, 403 Unauthorized - bad clock
-Occasionally, the system date/time will drift between client and server. If this drift is greater than a couple of minutes, the Chef Infra Server will throw a 401 unauthorized and the request won't be forwarded to the Chef Automate server.
+Occasionally, the system date/time will drift between client and server. If this drift is greater than a couple of minutes, Chef Infra Server will throw a 401 unauthorized and the request won't be forwarded to the Chef Automate server.
-On the Chef Infra Server you can see this in the following logs:
+On Chef Infra Server you can see this in the following logs:
```text
# chef-server-ctl tail
@@ -618,7 +618,7 @@ Then run `chef-server-ctl reconfigure` to apply this change.
##### 413 Error Logs
-The 413 "Request Entity Too Large" error appears in both the stacktrace and the Chef Infra Server Nginx logs.
+The 413 "Request Entity Too Large" error appears in both the stacktrace and Chef Infra Server Nginx logs.
diff --git a/content/chef_install_script.md b/content/chef_install_script.md
deleted file mode 100644
index e9c7309..0000000
--- a/content/chef_install_script.md
+++ /dev/null
@@ -1,203 +0,0 @@
-+++
-title = "Chef Software install script"
-draft = false
-gh_repo = "chef-web-docs"
-aliases = ["/install_omnibus.html", "/install_omnibus/"]
-product = ["automate", "client", "server", "habitat", "inspec", "supermarket", "workstation"]
-
-[menu]
- [menu.overview]
- title = "Install script"
- identifier = "overview/packages_&_platforms/Install Script"
- parent = "overview/packages_&_platforms"
- weight = 30
-+++
-
-You can use the Chef Software install script to install
-any Chef software---including Chef Infra Client, Chef Infra Server, and Chef InSpec---on UNIX, Linux, and Windows platforms.
-
-This script does the following:
-
-- Detects the platform, version, and architecture of the machine on which the installer is being executed.
-- Fetches the appropriate package, for the requested product and version.
-- Validates the package content by comparing SHA-256 checksums.
-- Installs the package.
-
-## Install using the Commercial API
-
-Commercial users can use the install script from the [Chef Commercial API](/download/commercial/) to install Chef software.
-
-### Prerequisites
-
-You must have a license ID to use the install script from the Chef Commercial API. You can get your license ID from the [Chef Downloads portal](https://chef.io/downloads).
-
-### UNIX, Linux, and macOS
-
-Use the Chef install script to install packages on UNIX, Linux, and macOS systems:
-
-By default the script installs the latest version of Chef Infra Client:
-
-```bash
-curl -L https://chefdownload-commercial.chef.io/install.sh?license_id= | sudo bash
-```
-
-Replace `` with your license ID.
-
-Use the `-P` option to specify a Chef software application to install:
-
-```bash
-curl -L https://chefdownload-commercial.chef.io/install.sh?license_id= | sudo bash -s -- -P
-```
-
-Replace:
-
-- `` with your license ID
-- `` with the application you want to install
-
-For additional script install options, see the [script options](#script-options).
-
-### Windows
-
-On Windows systems, you can install Chef software using the Powershell install script.
-
-By default the script installs the latest version of Chef Infra Client:
-
-```powershell
-. { iwr -useb https://chefdownload-commercial.chef.io/install.ps1?license_id= } | iex; install
-```
-
-Replace `` with your license ID.
-
-Use the `-project` option to specify a Chef software application to install:
-
-```powershell
-. { iwr -useb https://chefdownload-commercial.chef.io/install.ps1?license_id= } | iex; install -project
-```
-
-Replace:
-
-- `` with your license ID
-- `` with the application you want to install
-
-For additional script install options, see the [script options](#script-options).
-
-## Install using the Community API
-
-Community users can use the install script from the [Chef Community API](/download/community/) to install Chef software.
-
-### UNIX, Linux, and macOS
-
-Use the Chef install script to install packages on UNIX, Linux, and macOS systems.
-
-By default the script installs the latest available version of Chef Infra Client:
-
-```bash
-curl -L https://chefdownload-community.chef.io/install.sh | sudo bash
-```
-
-Use the `-P` option to specify a Chef application to install:
-
-```bash
-curl -L https://chefdownload-community.chef.io/install.sh | sudo bash -s -- -P
-```
-
-Replace `` with the application you want to install.
-
-For additional script install options, see the [script options](#script-options).
-
-### Windows
-
-On Windows systems, you can install Chef software using the Powershell install script.
-
-By default the script installs the latest available version of Chef Infra Client:
-
-```powershell
-. { iwr -useb https://chefdownload-community.chef.io/install.ps1 } | iex; install
-```
-
-Use the `-project` option to specify a Chef application to install:
-
-```powershell
-. { iwr -useb https://chefdownload-community.chef.io/install.ps1 } | iex; install -project
-```
-
-For additional script install options, see the [script options](#script-options).
-
-## Script options
-
-In addition to the default install behavior, the Chef Software install script supports the following options:
-
-`-c` (`-channel` on Windows)
-
-: The [release channel](#release-channels) from which a package is pulled.
-
- The Commercial Download API supports the `current` or `stable` channels.
- The Community Download API only supports the `stable` channel.
-
- Default value: `stable`.
-
-`-d` (`-download_directory` on Windows)
-
-: The directory into which a package is downloaded. When a package
- already exists in this directory and the checksum matches, the
- package isn't re-downloaded. When `-d` and `-f` aren't specified,
- a package is downloaded to a temporary directory.
-
-`-f` (`-filename` on Windows)
-
-: The name of the file and the path at which that file is located.
- When a filename already exists at this path and the checksum
- matches, the package isn't re-downloaded. When `-d` and `-f` are
- not specified, a package is downloaded to a temporary directory.
-
-`-P` (`-project` on Windows)
-
-: The product name to install. Supported versions of Chef products are
- `chef`,`chef-backend`,`chef-server`,`inspec`,`chef-workstation`,`manage` and
- `supermarket`. Default value: `chef`.
-
-`-s` (`-install_strategy` on Windows)
-
-: The method of package installations. The default strategy is to
- always install when the install.sh script runs. Set to "once" to
- skip installation if the product is already installed on the node.
-
-`-l` (`-download_url_override` on Windows)
-
-: Install package downloaded from a direct URL.
-
-`-a` (`-checksum` on Windows)
-
-: The SHA256 for download_url_override
-
-`-v` (`-version` on Windows)
-
-: The version of the package to be installed. A version always takes
- the form x.y.z, where x, y, and z are decimal numbers that are used
- to represent major (x), minor (y), and patch (z) versions. A
- two-part version (x.y) is also allowed. For more information about
- application versioning, see [semver.org](https://semver.org/).
-
-## Release channels
-
-{{< readfile file="content/reusable/md/release_channels.md" >}}
-
-## Examples
-
-The following examples show how to use the Chef Software install script.
-
-Use the `-v` option to install Chef Infra Client 15.8.23 on Unix, Linux, or macOS hosts:
-
-```bash
-curl -L https://chefdownload-commercial.chef.io/install.sh?license_id= | sudo bash -s -- -v 15.8.23
-```
-
-Replace `` with your license ID.
-
-To install the latest version of Chef Workstation on Windows from the `current` channel:
-
-```powershell
-. { iwr -useb https://chefdownload-commercial.chef.io/install.ps1?license_id= } | iex; install -channel current -project chef-workstation
-```
-
-Replace `` with your license ID.
diff --git a/content/chef_repo.md b/content/chef_repo.md
index 5d99e2a..f7218b2 100644
--- a/content/chef_repo.md
+++ b/content/chef_repo.md
@@ -65,15 +65,15 @@ The `cookbooks` directory contains cookbooks that configure systems in the infra
### data_bags
-The `data_bags` directory is used to store all the data bags that exist for an organization. Each sub-directory corresponds to a single data bag on the Chef Infra Server and contains a JSON file corresponding to each data bag item.
+The `data_bags` directory is used to store all the data bags that exist for an organization. Each sub-directory corresponds to a single data bag on Chef Infra Server and contains a JSON file corresponding to each data bag item.
### policyfiles
-The `policyfiles` directory is used to store Policyfiles in the `.rb` format that define the set of cookbooks and attributes to apply to specific systems managed by the Chef Infra Server.
+The `policyfiles` directory is used to store Policyfiles in the `.rb` format that define the set of cookbooks and attributes to apply to specific systems managed by Chef Infra Server.
### chefignore
-A `chefignore` file tells knife which cookbook files in the chef-repo it should ignore when uploading data to the Chef Infra Server.
+A `chefignore` file tells knife which cookbook files in the chef-repo it should ignore when uploading data to Chef Infra Server.
Include swap files, version control data, and build output data in a `chefignore` file.
The `chefignore` file has the following rules:
@@ -99,7 +99,7 @@ See Ruby's [`File.fnmatch` documentation](https://ruby-doc.org/core-2.5.1/File.h
#### Examples
-Many text editors leave files behind. To prevent knife from uploading these files to the Chef Infra Server, add an entry to the `chefignore` file.
+Many text editors leave files behind. To prevent knife from uploading these files to Chef Infra Server, add an entry to the `chefignore` file.
For Emacs backup files:
diff --git a/content/chef_search.md b/content/chef_search.md
index f6bbfc3..54c7698 100644
--- a/content/chef_search.md
+++ b/content/chef_search.md
@@ -62,47 +62,47 @@ following search indexes are built:
### Using Knife
-{{< readfile file="content/workstation/reusable/md/knife_search_summary.md" >}}
+{{< readfile file="content/reusable/md/workstation/knife_search_summary.md" >}}
#### Search by platform ID
-{{< readfile file="content/workstation/reusable/md/knife_search_by_platform_ids.md" >}}
+{{< readfile file="content/reusable/md/workstation/knife_search_by_platform_ids.md" >}}
#### Search by instance type
-{{< readfile file="content/workstation/reusable/md/knife_search_by_platform_instance_type.md" >}}
+{{< readfile file="content/reusable/md/workstation/knife_search_by_platform_instance_type.md" >}}
#### Search by recipe
-{{< readfile file="content/workstation/reusable/md/knife_search_by_recipe.md" >}}
+{{< readfile file="content/reusable/md/workstation/knife_search_by_recipe.md" >}}
#### Search by cookbook, then recipe
-{{< readfile file="content/workstation/reusable/md/knife_search_by_cookbook.md" >}}
+{{< readfile file="content/reusable/md/workstation/knife_search_by_cookbook.md" >}}
#### Search by node
-{{< readfile file="content/workstation/reusable/md/knife_search_by_node.md" >}}
+{{< readfile file="content/reusable/md/workstation/knife_search_by_node.md" >}}
#### Search by node and environment
-{{< readfile file="content/workstation/reusable/md/knife_search_by_node_and_environment.md" >}}
+{{< readfile file="content/reusable/md/workstation/knife_search_by_node_and_environment.md" >}}
#### Search for nested attributes
-{{< readfile file="content/workstation/reusable/md/knife_search_by_nested_attribute.md" >}}
+{{< readfile file="content/reusable/md/workstation/knife_search_by_nested_attribute.md" >}}
#### Search for multiple attributes
-{{< readfile file="content/workstation/reusable/md/knife_search_by_query_for_many_attributes.md" >}}
+{{< readfile file="content/reusable/md/workstation/knife_search_by_query_for_many_attributes.md" >}}
#### Search for nested attributes using a search query
-{{< readfile file="content/workstation/reusable/md/knife_search_by_query_for_nested_attribute.md" >}}
+{{< readfile file="content/reusable/md/workstation/knife_search_by_query_for_nested_attribute.md" >}}
#### Use a test query
-{{< readfile file="content/workstation/reusable/md/knife_search_test_query_for_ssh.md" >}}
+{{< readfile file="content/reusable/md/workstation/knife_search_test_query_for_ssh.md" >}}
## Query Syntax
@@ -280,7 +280,7 @@ A wildcard can be used to replace characters within the search query.
Expanded lists of roles (all of the roles that apply to a node,
including nested roles) and recipes to the role and recipe attributes on
-a node are saved on the Chef Infra Server. The expanded lists of roles
+a node are saved on Chef Infra Server. The expanded lists of roles
allows for searching within nodes that run a given recipe, even if that
recipe is included by a role.
@@ -334,7 +334,7 @@ end
### API Clients
An API client is any machine that has permission to use the Chef Infra
-Server API to communicate with the Chef Infra Server. An API client is
+Server API to communicate with Chef Infra Server. An API client is
typically a node (that runs Chef Infra Client) or a workstation (that
runs knife), but can also be any other machine configured to use the
Chef Infra Server API.
diff --git a/content/chef_solo.md b/content/chef_solo.md
index 7965c4d..f06a84e 100644
--- a/content/chef_solo.md
+++ b/content/chef_solo.md
@@ -61,7 +61,7 @@ configuration file.
## Attributes
-chef-solo doesn't interact with the Chef Infra Server. Consequently,
+chef-solo doesn't interact with Chef Infra Server. Consequently,
node-specific attributes must be located in a JSON file on the target
system, a remote location (such as Amazon Simple Storage Service (S3)),
or a web server on the local network.
diff --git a/content/chef_system_requirements.md b/content/chef_system_requirements.md
deleted file mode 100644
index 1baa4d5..0000000
--- a/content/chef_system_requirements.md
+++ /dev/null
@@ -1,68 +0,0 @@
-+++
-title = "System Requirements"
-draft = false
-gh_repo = "chef-web-docs"
-aliases = ["/chef_system_requirements.html"]
-product = ["client", "server", "workstation"]
-
-[menu]
- [menu.infra]
- title = "System Requirements"
- identifier = "chef_infra/install/chef_system_requirements.md System Requirements"
- parent = "chef_infra/install"
- weight = 5
-+++
-
-Before installing Chef Infra:
-
-- Ensure that each system you will be managing is running a [supported
- platform](/platforms/)
-- Ensure that the machine that will run the Chef Infra Server is
- sufficiently powerful
-- Ensure that any network and firewall settings are configured
- correctly
-
-Install and configure the Chef Infra Server, then install and configure
-Chef Workstation, and then run the bootstrap command from Chef
-Workstation to install Chef Infra Client on each node.
-
-## Chef Infra Server
-
-### Hardware requirements
-
-Chef Infra Server has the following hardware requirements:
-
-{{< readfile file="content/server/reusable/md/system_requirements_server_hardware.md" >}}
-
-### Software requirements
-
-Chef Infra Server has the following software requirements:
-
-{{< readfile file="content/server/reusable/md/system_requirements_server_software.md" >}}
-
-## Chef Infra Client
-
-- The recommended amount of RAM available to Chef Infra Client during
- a Chef Infra Client run is 512MB
-- The Chef Infra Client binaries are stored in the `/opt/chef`
- directory, which requires a minimum of 200MB of disk space. On
- Windows, the Chef Infra Client binaries can be found in
- `C:\opscode\`, and they require a minimum of 600MB of disk space.
-- The processor must be [supported](/platforms/). We recommend
- a 1 gigahertz (GHz) or faster processor, but the processor speed
- should be based on the other system loads.
-- Chef Infra Client caches to `/var/chef/cache` during a Chef Infra
- Client run. This is the location in which downloaded cookbooks,
- packages required by those cookbooks, and other large files are
- stored. This directory requires enough space to save all of this
- data and should be generously sized. 5GB is a safe number as a
- starting point, but tune the size of `/var/chef/cache` as necessary.
- This location is tunable in a node's
- [client.rb](/config_rb_client/) file using the
- `file_cache_path` setting.
-
-## Chef Workstation
-
-- 64-bit architecture
-- 4 GB of RAM or more
-- 2 GB of free disk space
diff --git a/content/config_rb_client.md b/content/config_rb_client.md
index b2b86a0..d215267 100644
--- a/content/config_rb_client.md
+++ b/content/config_rb_client.md
@@ -102,7 +102,7 @@ This configuration file has the following settings:
: The path to the chef-repo containing cookbooks and other files, such as environments or data bags, when running Chef Infra Client in local mode.
`chef_server_url`
-: The URL of the Chef Infra Server. For example:
+: The URL of Chef Infra Server. For example:
```ruby
https://localhost/organizations/ORG_NAME
@@ -151,7 +151,7 @@ This configuration file has the following settings:
: The sub-directory for Chef Infra Client cookbooks. This value can be a string or an array of file system locations, processed in the specified order. The last cookbook is considered to override local modifications.
`cookbook_sync_threads`
-: The number of helper threads available for parallel cookbook synchronization. Increasing this value **may** increase the frequency of gateway errors from the Chef Infra Server (503 and 504 errors). Decreasing this number reduces the frequency of gateway errors, if present.
+: The number of helper threads available for parallel cookbook synchronization. Increasing this value **may** increase the frequency of gateway errors from Chef Infra Server (503 and 504 errors). Decreasing this number reduces the frequency of gateway errors, if present.
Default value: `10`.
@@ -371,12 +371,12 @@ This configuration file has the following settings:
: Run chef-zero in socketless mode. Set to `false` to disable port binding and HTTP requests on localhost.
`local_key_generation`
-: Whether the Chef Infra Server or Chef Infra Client generates the private/public key pair. When `true`, Chef Infra Client generates the key pair, and then sends the public key to the Chef Infra Server.
+: Whether Chef Infra Server or Chef Infra Client generates the private/public key pair. When `true`, Chef Infra Client generates the key pair, and then sends the public key to Chef Infra Server.
Default value: `true`.
`local_mode`
-: Run Chef Infra Client in local mode. This allows all commands that work against the Chef Infra Server to also work against the local chef-repo.
+: Run Chef Infra Client in local mode. This allows all commands that work against Chef Infra Server to also work against the local chef-repo.
`lockfile`
: The location of the Chef Infra Client lock file. This value is typically platform dependent, so it should be a location defined by `file_cache_path`. The default location of a lock file shouldn't be on an NFS mount.
@@ -440,7 +440,7 @@ This configuration file has the following settings:
Default value: `/tmp/name-of-executable.pid`.
`policy_group`
-: The name of a policy group that exists on the Chef Infra Server. `policy_name` must also be specified.
+: The name of a policy group that exists on Chef Infra Server. `policy_name` must also be specified.
`policy_group_path`
: The location of policy_groups on disk.
@@ -485,7 +485,7 @@ This configuration file has the following settings:
Default value: `false`
`splay`
-: A random number between zero and `splay` that's added to `interval`. Use splay to help balance the load on the Chef Infra Server by ensuring that many Chef Infra Client runs aren't occurring at the same interval.
+: A random number between zero and `splay` that's added to `interval`. Use splay to help balance the load on Chef Infra Server by ensuring that many Chef Infra Client runs aren't occurring at the same interval.
Default value: `nil`.
@@ -511,12 +511,12 @@ This configuration file has the following settings:
: The path to where the OpenSSL key is located. Chef Infra Client generates this setting automatically and most users don't need to modify it.
`ssl_client_cert`
-: The OpenSSL X.509 certificate used for mutual certificate validation. This setting is only necessary when mutual certificate validation is configured on the Chef Infra Server.
+: The OpenSSL X.509 certificate used for mutual certificate validation. This setting is only necessary when mutual certificate validation is configured on Chef Infra Server.
Default value:`nil`.
`ssl_client_key`
-: The OpenSSL X.509 key used for mutual certificate validation. This setting is only necessary when mutual certificate validation is configured on the Chef Infra Server.
+: The OpenSSL X.509 key used for mutual certificate validation. This setting is only necessary when mutual certificate validation is configured on Chef Infra Server.
Default value: `nil`.
@@ -524,7 +524,7 @@ This configuration file has the following settings:
: Set the verify mode for HTTPS requests.
- Use `:verify_none` for no validation of SSL certificates.
- - Use `:verify_peer` for validation of all SSL certificates, including the Chef Infra Server connections, S3 connections, and any HTTPS **remote_file** resource URLs used in Chef Infra Client runs. This is the recommended setting.
+ - Use `:verify_peer` for validation of all SSL certificates, including Chef Infra Server connections, S3 connections, and any HTTPS **remote_file** resource URLs used in Chef Infra Client runs. This is the recommended setting.
Depending on how OpenSSL is configured, the `ssl_ca_path` may nee to be specified.
@@ -542,7 +542,7 @@ This configuration file has the following settings:
Default value: `0022`.
`use_policyfile`
-: Chef Infra Client automatically checks the configuration, node JSON, and the stored node on the Chef Infra Server to determine if Policyfile files are in use, and then automatically updates this flag.
+: Chef Infra Client automatically checks the configuration, node JSON, and the stored node on Chef Infra Server to determine if Policyfile files are in use, and then automatically updates this flag.
Default value: `false`.
@@ -552,7 +552,7 @@ This configuration file has the following settings:
Default value: `nil`.
`validation_client_name`
-: The name of the chef-validator key that Chef Infra Client uses to access the Chef Infra Server during the initial Chef Infra Client run. This is only used by the legacy validator based bootstrapping.
+: The name of the chef-validator key that Chef Infra Client uses to access Chef Infra Server during the initial Chef Infra Client run. This is only used by the legacy validator based bootstrapping.
`validation_key`
: The location of the file that contains the key used when a Chef Infra Client is registered with a Chef Infra Server. A validation key is signed using the `validation_client_name` for authentication.
@@ -565,7 +565,7 @@ This configuration file has the following settings:
Default value: `nil`.
`verify_api_cert`
-: Verify the SSL certificate on the Chef Infra Server. When `true`, Chef Infra Client always verifies the SSL certificate. When `false`, Chef Infra Client uses the value of `ssl_verify_mode` to determine if the SSL certificate requires verification.
+: Verify the SSL certificate on Chef Infra Server. When `true`, Chef Infra Client always verifies the SSL certificate. When `false`, Chef Infra Client uses the value of `ssl_verify_mode` to determine if the SSL certificate requires verification.
Default value: `false`.
diff --git a/content/config_rb_metadata.md b/content/config_rb_metadata.md
index bb2bf07..8fe59ea 100644
--- a/content/config_rb_metadata.md
+++ b/content/config_rb_metadata.md
@@ -19,17 +19,17 @@ aliases = ["/config_rb_metadata.html"]
{{< readfile file="content/reusable/md/cookbooks_metadata.md" >}}
* Located at the top level of a cookbook's directory structure.
-* Compiled whenever a cookbook is uploaded to the Chef Infra Server or when the `knife cookbook metadata` subcommand is run, and then stored as JSON data.
+* Compiled whenever a cookbook is uploaded to Chef Infra Server or when the `knife cookbook metadata` subcommand is run, and then stored as JSON data.
* Created automatically by knife whenever the `knife cookbook create` subcommand is run.
-* Edited using a text editor, and then re-uploaded to the Chef Infra Server as part of a cookbook upload.
+* Edited using a text editor, and then re-uploaded to Chef Infra Server as part of a cookbook upload.
## Error Messages
-The Chef Infra Server will only try to distribute the cookbooks that are needed to configure an individual node. This is determined by identifying the roles and recipes that are assigned directly to that system, and then to expand the list of dependencies, and then to deliver that entire set to the node. In some cases, if the dependency isn't specified in the cookbook's metadata, the Chef Infra Server may not treat that dependency as a requirement, which will result in an error message. If an error message is received from the Chef Infra Server about cookbook distribution, verify the `depends` entries in the `metadata.rb` file, and then try again.
+Chef Infra Server will only try to distribute the cookbooks that are needed to configure an individual node. This is determined by identifying the roles and recipes that are assigned directly to that system, and then to expand the list of dependencies, and then to deliver that entire set to the node. In some cases, if the dependency isn't specified in the cookbook's metadata, Chef Infra Server may not treat that dependency as a requirement, which will result in an error message. If an error message is received from Chef Infra Server about cookbook distribution, verify the `depends` entries in the `metadata.rb` file, and then try again.
{{< note >}}
-A metadata.json file can be edited directly, should temporary changes be required. Any subsequent upload or action that generates metadata will cause the existing metadata.json file to be overwritten with the newly generated metadata. Therefore, any permanent changes to cookbook metadata should be done in the `metadata.rb` file, and then re-uploaded to the Chef Infra Server.
+A metadata.json file can be edited directly, should temporary changes be required. Any subsequent upload or action that generates metadata will cause the existing metadata.json file to be overwritten with the newly generated metadata. Therefore, any permanent changes to cookbook metadata should be done in the `metadata.rb` file, and then re-uploaded to Chef Infra Server.
{{< /note >}}
@@ -106,7 +106,7 @@ This configuration file has the following settings:
`depends`
-: This field requires that a cookbook with a matching name and version exists on the Chef Infra Server. When the match exists, the Chef Infra Server includes the dependency as part of the set of cookbooks that are sent to the node during a Chef Infra Client run. It's important that the `depends` field contain accurate data. If a dependency statement is inaccurate, Chef Infra Client may not be able to complete the configuration of the system. All [version constraint operators](#version-constraints) are applicable to this field.
+: This field requires that a cookbook with a matching name and version exists on Chef Infra Server. When the match exists, Chef Infra Server includes the dependency as part of the set of cookbooks that are sent to the node during a Chef Infra Client run. It's important that the `depends` field contain accurate data. If a dependency statement is inaccurate, Chef Infra Client may not be able to complete the configuration of the system. All [version constraint operators](#version-constraints) are applicable to this field.
For example, to set a dependency a cookbook named `cats`:
diff --git a/content/config_rb_solo.md b/content/config_rb_solo.md
index ada58ad..6c54e70 100644
--- a/content/config_rb_solo.md
+++ b/content/config_rb_solo.md
@@ -104,7 +104,7 @@ This configuration file has the following settings:
`solo`
-: Run Chef Infra Client in chef-solo mode. This setting determines if Chef Infra Client is to attempt to communicate with the Chef Infra Server. Default value: `false`.
+: Run Chef Infra Client in chef-solo mode. This setting determines if Chef Infra Client is to attempt to communicate with Chef Infra Server. Default value: `false`.
`syntax_check_cache_path`
diff --git a/content/cookbook_versioning.md b/content/cookbook_versioning.md
index 3294285..ee13d58 100644
--- a/content/cookbook_versioning.md
+++ b/content/cookbook_versioning.md
@@ -123,7 +123,7 @@ not provided, `>= 0.0.0` is used as the default.
depends
-
Show that a cookbook has a dependency on another cookbook. Use a version constraint to define dependencies for cookbook versions: < (less than), <= (less than or equal to), = (equal to), >= (greater than or equal to; also known as "optimistically greater than", or "optimistic"), ~> (approximately greater than; also known as "pessimistically greater than", or "pessimistic"), or > (greater than). This field requires that a cookbook with a matching name and version exists on the Chef Infra Server. When the match exists, the Chef Infra Server includes the dependency as part of the set of cookbooks that are sent to the node when Chef Infra Client runs. It's important that the depends field contain accurate data. If a dependency statement is inaccurate, Chef Infra Client may not be able to complete the configuration of the system. For example:
+
Show that a cookbook has a dependency on another cookbook. Use a version constraint to define dependencies for cookbook versions: < (less than), <= (less than or equal to), = (equal to), >= (greater than or equal to; also known as "optimistically greater than", or "optimistic"), ~> (approximately greater than; also known as "pessimistically greater than", or "pessimistic"), or > (greater than). This field requires that a cookbook with a matching name and version exists on Chef Infra Server. When the match exists, Chef Infra Server includes the dependency as part of the set of cookbooks that are sent to the node when Chef Infra Client runs. It's important that the depends field contain accurate data. If a dependency statement is inaccurate, Chef Infra Client may not be able to complete the configuration of the system. For example:
depends 'opscode-base'
or:
depends 'opscode-github', '> 1.0.0'
@@ -201,7 +201,7 @@ Version 0.0.0 of cookbook redis is frozen. Use --force to override
{{< warning >}}
-If you continually upload all versions of many cookbooks to your Chef Infra Server, you may overload the Chef Infra Server's dependency solver, causing it to time out and leading to a failed Chef Infra Client run.
+If you continually upload all versions of many cookbooks to your Chef Infra Server, you may overload Chef Infra Server's dependency solver, causing it to time out and leading to a failed Chef Infra Client run.
There are three solutions to this problem:
@@ -211,7 +211,7 @@ There are three solutions to this problem:
{{< /warning >}}
-In a CI/CD workflow where new cookbook versions are continually uploaded to a Chef Infra Server, the Chef Infra Server dependency solver must look at more and more cookbook versions while trying to solve the constraints given to it from the run list of each Chef Infra Client that starts up. Eventually, it runs out of time to produce a solution, times out, and the Chef Infra Client run fails as a result. The Chef Infra Server may also pick older cookbook versions than the versions that you intended.
+In a CI/CD workflow where new cookbook versions are continually uploaded to a Chef Infra Server, the Chef Infra Server dependency solver must look at more and more cookbook versions while trying to solve the constraints given to it from the run list of each Chef Infra Client that starts up. Eventually, it runs out of time to produce a solution, times out, and the Chef Infra Client run fails as a result. Chef Infra Server may also pick older cookbook versions than the versions that you intended.
The dependency solver workers in a Chef Infra Server have a default timeout of five seconds. The solution isn't to increase their timeout, but to control the problem so that the dependency solvers can solve it in a reasonable amount of time.
@@ -227,7 +227,7 @@ The way to control the problem traditionally is by pinning the versions of cookb
### Minimum Number of Cookbook Versions
-The dependency solver will also work properly if you upload the minimum number of cookbook versions needed to the Chef Infra Server.
+The dependency solver will also work properly if you upload the minimum number of cookbook versions needed to Chef Infra Server.
You can make a start at this by only uploading tested and blessed cookbook versions to your Chef Infra Server. These cookbooks would be ones where each scenario or role for the nodes is considered and that small set of cookbook versions are made available for those sets of nodes. Before Policyfiles, this policy could be implemented by constraining dependency solver access to candidate versions using an [environment]({{< relref "environments" >}}) file.
diff --git a/content/ctl_chef_client.md b/content/ctl_chef_client.md
index 7afccd6..b38da11 100644
--- a/content/ctl_chef_client.md
+++ b/content/ctl_chef_client.md
@@ -84,7 +84,7 @@ This command has the following options:
`-F FORMAT`, `--format FORMAT`
-: {{< readfile file="content/workstation/reusable/md/ctl_chef_client_options_format.md" >}}
+: {{< readfile file="content/reusable/md/workstation/ctl_chef_client_options_format.md" >}}
`--force-formatter`
@@ -108,7 +108,7 @@ This command has the following options:
`-j PATH`, `--json-attributes PATH`
-: The path to a file that contains JSON data. Used to setup the first client run. The attributes will persist on the Chef Infra Server for all future runs with option `-j`.
+: The path to a file that contains JSON data. Used to setup the first client run. The attributes will persist on Chef Infra Server for all future runs with option `-j`.
**Run-lists**
@@ -170,7 +170,7 @@ This command has the following options:
policy_group
-
The name of a policy group that exists on the Chef Infra Server.
+
The name of a policy group that exists on Chef Infra Server.
policy_name
@@ -323,7 +323,7 @@ This command has the following options:
`-S CHEF_SERVER_URL`, `--server CHEF_SERVER_URL`
-: The URL for the Chef Infra Server.
+: The URL for Chef Infra Server.
`-u USER`, `--user USER`
@@ -345,7 +345,7 @@ This command has the following options:
`-z`, `--local-mode`
: Run the Chef Infra Client in local mode. This allows all commands
- that work against the Chef Infra Server to also work against the
+ that work against Chef Infra Server to also work against the
local chef-repo.
### Chef Infra Client Lock File
@@ -367,11 +367,11 @@ The location of the lock file can vary by platform.
## Run in Local Mode
Local mode is a way to run the Chef Infra Client against the chef-repo
-on a local machine as if it were running against the Chef Infra Server.
+on a local machine as if it were running against Chef Infra Server.
Local mode relies on chef-zero, which acts as a lightweight
-instance of the Chef Infra Server. chef-zero reads and writes to the
+instance of Chef Infra Server. chef-zero reads and writes to the
`chef_repo_path`, which allows all commands that normally work against
-the Chef Infra Server to be used against the local chef-repo.
+Chef Infra Server to be used against the local chef-repo.
Local mode doesn't require a configuration file, instead it will look
for a directory named `/cookbooks` and will set `chef_repo_path` to be
@@ -399,7 +399,7 @@ manner.
When why-run mode is enabled, a Chef Infra Client run will occur that
does everything up to the point at which configuration would normally
occur. This includes getting the configuration data, authenticating to
-the Chef Infra Server, rebuilding the node object, expanding the
+Chef Infra Server, rebuilding the node object, expanding the
run-list, getting the necessary cookbook files, resetting node
attributes, identifying the resources, and building the resource
collection, but doesn't include mapping each resource to a provider or
@@ -448,7 +448,7 @@ important to know that these notifications are triggered correctly.
chef-zero is a lightweight Chef Infra Server that runs in-memory on
the local machine. This allows the Chef Infra Client to be run against
-the chef-repo as if it were running against the Chef Infra Server.
+the chef-repo as if it were running against Chef Infra Server.
chef-zero was [originally a standalone
tool](https://github.com/chef/chef-zero); it's enabled from within the
Chef Infra Client by using the `--local-mode` option. chef-zero is
@@ -476,7 +476,7 @@ version 12 endpoints, except `/universe`.
**Create an encrypted data bag for use with Chef Infra Client local
mode**
-{{< readfile file="content/workstation/reusable/md/knife_data_bag_from_file_create_encrypted_local_mode.md" >}}
+{{< readfile file="content/reusable/md/workstation/knife_data_bag_from_file_create_encrypted_local_mode.md" >}}
## Run in FIPS Mode
@@ -484,7 +484,7 @@ mode**
**Bootstrap a node using FIPS**
-{{< readfile file="content/workstation/reusable/md/knife_bootstrap_node_fips.md" >}}
+{{< readfile file="content/reusable/md/workstation/knife_bootstrap_node_fips.md" >}}
## Run as a Service
@@ -527,7 +527,7 @@ supported.
## Run with Elevated Privileges
-{{< readfile file="content/workstation/reusable/md/ctl_chef_client_elevated_privileges.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_client_elevated_privileges.md" >}}
### Linux
@@ -570,7 +570,7 @@ ways this can be done:
### Windows
-{{< readfile file="content/workstation/reusable/md/ctl_chef_client_elevated_privileges_windows.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_client_elevated_privileges_windows.md" >}}
## Run as Non-root User
@@ -895,4 +895,4 @@ sudo killall -USR1 chef-client
**Setting the initial run-list using a JSON file**
-{{< readfile file="content/workstation/reusable/md/ctl_chef_client_bootstrap_initial_run_list.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_client_bootstrap_initial_run_list.md" >}}
diff --git a/content/ctl_chef_solo.md b/content/ctl_chef_solo.md
index 0334386..ade570b 100644
--- a/content/ctl_chef_solo.md
+++ b/content/ctl_chef_solo.md
@@ -44,7 +44,7 @@ This command has the following options:
`-F FORMAT`, `--format FORMAT`
-: {{< readfile file="content/workstation/reusable/md/ctl_chef_client_options_format.md" >}}
+: {{< readfile file="content/reusable/md/workstation/ctl_chef_client_options_format.md" >}}
`--force-formatter`
@@ -118,7 +118,7 @@ This command has the following options:
`-s SECONDS`, `--splay SECONDS`
-: A random number between zero and `splay` that's added to `interval`. Use splay to help balance the load on the Chef Infra Server by ensuring that many Chef Infra Client runs aren't occurring at the same interval. When running Chef Infra Client at intervals, apply `--splay` and `--interval` values before a Chef Infra Client run.
+: A random number between zero and `splay` that's added to `interval`. Use splay to help balance the load on Chef Infra Server by ensuring that many Chef Infra Client runs aren't occurring at the same interval. When running Chef Infra Client at intervals, apply `--splay` and `--interval` values before a Chef Infra Client run.
`-u USER`, `--user USER`
diff --git a/content/custom_resource_glossary.md b/content/custom_resource_glossary.md
index dcd557a..fa9e901 100644
--- a/content/custom_resource_glossary.md
+++ b/content/custom_resource_glossary.md
@@ -626,11 +626,11 @@ logs of the Chef Infra Client run.
## target_mode
-{{< readfile file="content/reusable/md/target_mode_summary.md" >}}
+{{< readfile file="content/reusable/md/agentless_summary.md" >}}
-{{< readfile file="/reusable/md/target_mode_custom_resource.md" >}}
+{{< readfile file="/content/reusable/md/agentless_custom_resource.md" >}}
-For more information on Target Mode, see the [Target Mode documentation]({{< relref "/target_mode.md" >}}).
+For more information on Target Mode, see the [Target Mode documentation]({{< relref "/agentless.md" >}}).
## unified_mode
diff --git a/content/custom_resources.md b/content/custom_resources.md
index 9d3bbcf..3941075 100644
--- a/content/custom_resources.md
+++ b/content/custom_resources.md
@@ -154,13 +154,13 @@ site 'foo'
## Target Mode
-{{< readfile file="content/reusable/md/target_mode_summary.md" >}} For more information on Target Mode, see the [Target Mode documentation]({{< relref "/target_mode.md" >}}).
+{{< readfile file="content/reusable/md/agentless_summary.md" >}} For more information on Target Mode, see the [Target Mode documentation]({{< relref "/agentless.md" >}}).
-{{< readfile file="/reusable/md/target_mode_custom_resource.md" >}}
+{{< readfile file="/content/reusable/md/agentless_custom_resource.md" >}}
### Example
-{{< readfile file="/reusable/md/target_mode_custom_resource_example.md" >}}
+{{< readfile file="/content/reusable/md/agentless_custom_resource_example.md" >}}
## Unified Mode
@@ -178,5 +178,5 @@ See these resources to learn more about custom resources:
- See the LearnChef interactive tutorial: [Extending Chef Infra: Custom Resources](https://www.chef.io/training/tutorials).
- For a description of available methods, see the [custom resources glossary]({{< relref "custom_resource_glossary" >}}).
-- For running resources in Target Mode, see the [Target Mode documentation]({{< relref "target_mode" >}}).
+- For running resources in Target Mode, see the [Target Mode documentation]({{< relref "agentless" >}}).
- For running resources in Unified Mode, see the [Unified Mode documentation]({{< relref "unified_mode" >}}).
diff --git a/content/data_bags.md b/content/data_bags.md
index c7f14d4..ccb690b 100644
--- a/content/data_bags.md
+++ b/content/data_bags.md
@@ -296,9 +296,9 @@ management console.
### Edit a data bag with knife
-{{< readfile file="content/workstation/reusable/md/knife_data_bag_edit.md" >}}
+{{< readfile file="content/reusable/md/workstation/knife_data_bag_edit.md" >}}
-{{< readfile file="content/workstation/reusable/md/knife_data_bag_edit_item.md" >}}
+{{< readfile file="content/reusable/md/workstation/knife_data_bag_edit_item.md" >}}
## Use data bags
diff --git a/content/debug.md b/content/debug.md
index 2694396..ab343f6 100644
--- a/content/debug.md
+++ b/content/debug.md
@@ -178,7 +178,7 @@ debug recipes. Breakpoints are ignored by Chef Infra Client during an
actual Chef Infra Client run. That said, breakpoints are typically used
to debug recipes only when running them in a non-production environment,
after which they're removed from those recipes before the parent
-cookbook is uploaded to the Chef Infra Server.
+cookbook is uploaded to Chef Infra Server.
#### Syntax
diff --git a/content/environments.md b/content/environments.md
index 53b3bf3..97519c5 100644
--- a/content/environments.md
+++ b/content/environments.md
@@ -269,13 +269,13 @@ The JSON format has two additional settings:
An environment can be created in four different ways:
- Create a Ruby file in the environments sub-directory of the
- chef-repo and then push it to the Chef Infra Server
+ chef-repo and then push it to Chef Infra Server
- Create a JSON file directly in the chef-repo and then push it
- to the Chef Infra Server
+ to Chef Infra Server
- Using knife
- Using the Chef Infra Server REST API
-Once an environment exists on the Chef Infra Server, a node can be
+Once an environment exists on Chef Infra Server, a node can be
associated with that environment using the `chef_environment` method.
## Manage environments
@@ -285,7 +285,7 @@ Once created, an environment can be managed in several ways:
- By using knife and passing the `-E ENVIRONMENT_NAME` option with
`knife cookbook upload`
- By using Ruby or JSON files that are stored in a version source
- control system. These files are pushed to the Chef Infra Server
+ control system. These files are pushed to Chef Infra Server
using the `knife environment` subcommand and the `from file`
argument. This approach allows environment data to be dynamically
generated. This approach won't work unless these files are
@@ -293,7 +293,7 @@ Once created, an environment can be managed in several ways:
end with `.json`.
These workflows are mutually exclusive: only the most recent environment
-changes will be kept on the Chef Infra Server, regardless of the source
+changes will be kept on Chef Infra Server, regardless of the source
of those changes. All previous changes are overwritten when environment
data is updated.
diff --git a/content/errors.md b/content/errors.md
index 3be5334..6714ed9 100644
--- a/content/errors.md
+++ b/content/errors.md
@@ -12,7 +12,7 @@ product = ["client", "server", "workstation"]
parent = "chef_infra/reference"
+++
-The following sections describe how to troubleshoot the Chef Infra Server, Chef Infra Client, and Chef Workstation.
+The following sections describe how to troubleshoot Chef Infra Server, Chef Infra Client, and Chef Workstation.
## 401 Unauthorized
@@ -49,7 +49,7 @@ FATAL: Net::HTTPClientException: 401 "Unauthorized"
## Failed to authenticate to
-When the values for certain settings in the client.rb file---`node_name` and `client_key`---are incorrect, it won't be possible to authenticate to the Chef Infra Server. An error similar to the following is shown:
+When the values for certain settings in the client.rb file---`node_name` and `client_key`---are incorrect, it won't be possible to authenticate to Chef Infra Server. An error similar to the following is shown:
```bash
ERROR: Failed to authenticate to https://api.opscode.com/organizations/ORGANIZATION as USERNAME with key /path/to/USERNAME.pem
@@ -156,7 +156,7 @@ FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
FATAL: Net::HTTPClientException: 403 "Forbidden"
```
-this is an indication that there is an issue with permissions on the Chef Infra Server.
+this is an indication that there is an issue with permissions on Chef Infra Server.
### Troubleshooting steps
@@ -307,11 +307,11 @@ Run the following to restart all of the services:
chef-server-ctl reconfigure
```
-Because the Chef Infra Server is composed of many different services that work together to create a functioning system, this step may take a few minutes to complete.
+Because Chef Infra Server is composed of many different services that work together to create a functioning system, this step may take a few minutes to complete.
## External PostgreSQL
-The following error messages may be present when configuring the Chef Infra Server to use a remote PostgreSQL server.
+The following error messages may be present when configuring Chef Infra Server to use a remote PostgreSQL server.
### CSPG001 (changed setting)
@@ -346,7 +346,7 @@ Can't connect to PostgreSQL on the remote server.
- PostgreSQL isn't running on the remote server
- The port used by PostgreSQL is blocked by a firewall on the remote server
- Network routing configuration is preventing access to the host
-- When using Amazon Web Services (AWS), rules for security groups are preventing the Chef Infra Server from communicating with PostgreSQL
+- When using Amazon Web Services (AWS), rules for security groups are preventing Chef Infra Server from communicating with PostgreSQL
### CSPG011 (can't authenticate)
@@ -404,7 +404,7 @@ where `CHEF-SUPERUSER-NAME` is replaced with the same user name specified by `po
host postgres @chef_users 192.168.93.0/24 md5
```
-or, using the same `$PGDATA/chef_users` file (from the previous example), the following example shows a way to limit connections to specific nodes that are running components of the Chef Infra Server.This approach requires more maintenance because the `pg_hba.conf`file must be updated when machines are added to or removed from theChef Infra Server configuration. For example, a high availability configuration with four nodes: `backend-1` (192.0.2.100),`backend-2` (192.0.2.101), `frontend-1` (192.0.2.110), and`frontend-2` (192.0.2.111).
+or, using the same `$PGDATA/chef_users` file (from the previous example), the following example shows a way to limit connections to specific nodes that are running components of Chef Infra Server.This approach requires more maintenance because the `pg_hba.conf`file must be updated when machines are added to or removed from theChef Infra Server configuration. For example, a high availability configuration with four nodes: `backend-1` (192.0.2.100),`backend-2` (192.0.2.101), `frontend-1` (192.0.2.110), and`frontend-2` (192.0.2.111).
The corresponding `pg_hba.conf` entry is similar to:
diff --git a/content/fips.md b/content/fips.md
index 8dd0805..3056737 100644
--- a/content/fips.md
+++ b/content/fips.md
@@ -112,4 +112,4 @@ If you have FIPS compliance enabled at the kernel level, Chef Infra Client will
#### Bootstrap a node using FIPS
-{{< readfile file="content/workstation/reusable/md/knife_bootstrap_node_fips.md" >}}
+{{< readfile file="content/reusable/md/workstation/knife_bootstrap_node_fips.md" >}}
diff --git a/content/glossary.md b/content/glossary.md
index 1add86f..6e737c6 100644
--- a/content/glossary.md
+++ b/content/glossary.md
@@ -38,7 +38,7 @@ Chef Infra Client
Chef Infra Server
-: The Chef Infra Server acts as a hub for configuration data. The Chef Infra Server stores cookbooks, the policies that are applied to nodes, and metadata that describes each registered node that's being managed by Chef Infra Client. Nodes use Chef Infra Client to ask the Chef Infra Server for configuration details, such as recipes, templates, and file distributions.
+: Chef Infra Server acts as a hub for configuration data. Chef Infra Server stores cookbooks, the policies that are applied to nodes, and metadata that describes each registered node that's being managed by Chef Infra Client. Nodes use Chef Infra Client to ask Chef Infra Server for configuration details, such as recipes, templates, and file distributions.
Chef Workstation
@@ -82,7 +82,7 @@ Foodcritic
knife
-: A command-line tool that provides an interface between a local chef-repo and the Chef Infra Server. Use it to manage nodes, cookbooks, recipes, roles, data bags, environments, bootstrapping nodes, searching the Chef Infra Server, and more.
+: A command-line tool that provides an interface between a local chef-repo and Chef Infra Server. Use it to manage nodes, cookbooks, recipes, roles, data bags, environments, bootstrapping nodes, searching Chef Infra Server, and more.
library
@@ -102,11 +102,11 @@ ohai
organization
-: An organization is a single instance of a Chef Infra Server, including all of the nodes that are managed by that Chef Infra Server and each of the workstations that will run knife and access the Chef Infra Server using the Chef Infra Server API.
+: An organization is a single instance of a Chef Infra Server, including all of the nodes that are managed by that Chef Infra Server and each of the workstations that will run knife and access Chef Infra Server using the Chef Infra Server API.
policy
-: Policy settings can be used to map business and operational requirements, such as process and workflow, to settings and objects stored on the Chef Infra Server. See roles, environments, and data bags.
+: Policy settings can be used to map business and operational requirements, such as process and workflow, to settings and objects stored on Chef Infra Server. See roles, environments, and data bags.
recipe
diff --git a/content/handlers.md b/content/handlers.md
index 7643971..5902888 100644
--- a/content/handlers.md
+++ b/content/handlers.md
@@ -448,17 +448,17 @@ This recipe will generate report output similar to the following:
### Reporting
-Start handler functionality was added when Chef started building add-ons for the Chef Infra Server. The Reporting add-on is designed to create reporting data based on a Chef Infra Client run. And since Reporting needs to be able to collect data for the entire Chef Infra Client run, Reporting needs to be enabled before anything else happens at the start of a Chef Infra Client run.
+Start handler functionality was added when Chef started building add-ons for Chef Infra Server. The Reporting add-on is designed to create reporting data based on a Chef Infra Client run. And since Reporting needs to be able to collect data for the entire Chef Infra Client run, Reporting needs to be enabled before anything else happens at the start of a Chef Infra Client run.
{{< note >}}
-The start handler used by the Reporting add-on for the Chef Infra Server is always installed using the **chef-client** cookbook.
+The start handler used by the Reporting add-on for Chef Infra Server is always installed using the **chef-client** cookbook.
{{< /note >}}
#### start_handler.rb
-The following code shows the start handler used by the Reporting add-in for the Chef Infra Server:
+The following code shows the start handler used by the Reporting add-in for Chef Infra Server:
```ruby
require 'chef/handler'
diff --git a/content/infra_language/search.md b/content/infra_language/search.md
index 48783b3..a432827 100644
--- a/content/infra_language/search.md
+++ b/content/infra_language/search.md
@@ -15,7 +15,7 @@ gh_repo = "chef-web-docs"
{{< readfile file="content/reusable/md/search.md" >}}
-Use the `search` method to perform a search query against the Chef Infra Server from within a recipe.
+Use the `search` method to perform a search query against Chef Infra Server from within a recipe.
The syntax for the `search` method is as follows:
@@ -25,8 +25,8 @@ search(:index, 'query')
where:
-- `:index` is of name of the index on the Chef Infra Server against which the search query will run: `:client`, `:data_bag_name`, `:environment`, `:node`, and `:role`
-- `'query'` is a valid search query against an object on the Chef Infra Server (see below for more information about how to build the query)
+- `:index` is of name of the index on Chef Infra Server against which the search query will run: `:client`, `:data_bag_name`, `:environment`, `:node`, and `:role`
+- `'query'` is a valid search query against an object on Chef Infra Server (see below for more information about how to build the query)
For example, using the results of a search query within a variable:
diff --git a/content/install_bootstrap.md b/content/install_bootstrap.md
index aabdae6..2da5f10 100644
--- a/content/install_bootstrap.md
+++ b/content/install_bootstrap.md
@@ -27,7 +27,7 @@ The `knife bootstrap` command runs a bootstrap operation that installs Chef Infr
1. Identify the FQDN or IP address of the target node. The `knife bootstrap` command requires the FQDN or the IP address for the node to complete the bootstrap operation.
-2. Once the workstation machine is configured, it can be used to install Chef Infra Client on one (or more) nodes across the organization using a knife bootstrap operation. The `knife bootstrap` command is used to SSH into the target machine, and then do what's needed to allow Chef Infra Client to run on the node. It will install the Chef Infra Client executable (if necessary), generate keys, and register the node with the Chef Infra Server. The bootstrap operation requires the IP address or FQDN of the target system, the SSH credentials (username, password or identity file) for an account that has root access to the node, and (if the operating system isn't Ubuntu, which is the default distribution used by `knife bootstrap`) the operating system running on the target system.
+2. Once the workstation machine is configured, it can be used to install Chef Infra Client on one (or more) nodes across the organization using a knife bootstrap operation. The `knife bootstrap` command is used to SSH into the target machine, and then do what's needed to allow Chef Infra Client to run on the node. It will install the Chef Infra Client executable (if necessary), generate keys, and register the node with Chef Infra Server. The bootstrap operation requires the IP address or FQDN of the target system, the SSH credentials (username, password or identity file) for an account that has root access to the node, and (if the operating system isn't Ubuntu, which is the default distribution used by `knife bootstrap`) the operating system running on the target system.
In a command window, enter the following:
@@ -97,13 +97,13 @@ The `knife bootstrap` command runs a bootstrap operation that installs Chef Infr
[172.16.1.233] Chef Infra Client finished, 0/0 resources updated in 11 seconds
```
-3. After the bootstrap operation has finished, verify that the node is recognized by the Chef Infra Server. To show only the node that was just bootstrapped, run the following command:
+3. After the bootstrap operation has finished, verify that the node is recognized by Chef Infra Server. To show only the node that was just bootstrapped, run the following command:
```bash
knife client show NAME_OF_NODE
```
- where `NODE_NAME` is the name of the node that was just bootstrapped. The Chef Infra Server will return something similar to:
+ where `NODE_NAME` is the name of the node that was just bootstrapped. Chef Infra Server will return something similar to:
```bash
admin: false
@@ -112,13 +112,13 @@ The `knife bootstrap` command runs a bootstrap operation that installs Chef Infr
validator: false
```
- and to show the full list of nodes (and workstations) that are registered with the Chef Infra Server, run the following command:
+ and to show the full list of nodes (and workstations) that are registered with Chef Infra Server, run the following command:
```bash
knife client list
```
- The Chef Infra Server will return something similar to:
+ Chef Infra Server will return something similar to:
```bash
workstation1
@@ -130,16 +130,16 @@ The `knife bootstrap` command runs a bootstrap operation that installs Chef Infr
## Validatorless and legacy validator bootstraps
-We recommended using "validatorless bootstrapping" to authenticate new nodes with the Chef Infra Server.
+We recommended using "validatorless bootstrapping" to authenticate new nodes with Chef Infra Server.
-The legacy Chef Infra validator-based node bootstrapping process depended on using a shared "validatory" key throughout an organization for authenticating new nodes with the Chef Infra Server.
+The legacy Chef Infra validator-based node bootstrapping process depended on using a shared "validatory" key throughout an organization for authenticating new nodes with Chef Infra Server.
Shortcomings of the legacy validator process are:
- All users share the same key for bootstrapping new systems
- Key sharing makes key rotation difficult, if it's compromised or if an employee leaves the organization.
-The "validatorless bootstrap" generates a key for each node, which is then transferred to the new node and used to authenticate with the Chef Infra Server instead of relying on a shared "validator" key.
+The "validatorless bootstrap" generates a key for each node, which is then transferred to the new node and used to authenticate with Chef Infra Server instead of relying on a shared "validator" key.
The Chef Infra bootstrap process is validatorless by default. If you receive a warning during a bootstrap that a validator key is in use, remove the configuration for this legacy bootstrap mode. Edit your [config.rb (knife.rb)](/workstation/config_rb/) file and remove any `validation_key` or `validation_client_name` entries.
@@ -355,10 +355,10 @@ Chef Infra Client can be installed using an unattended bootstrap. This allows Ch
When Chef Infra Client is installed using an unattended bootstrap, remember that Chef Infra Client:
-- Must be able to authenticate to the Chef Infra Server.
+- Must be able to authenticate to Chef Infra Server.
- Must be able to configure a run-list.
- May require custom attributes, depending on the cookbooks that are being used.
-- Must be able to access the `chef-validator.pem` file so that it may create a new identity on the Chef Infra Server.
+- Must be able to access the `chef-validator.pem` file so that it may create a new identity on Chef Infra Server.
- Must have a unique node name; Chef Infra Client will use the FQDN for the host system by default.
When Chef Infra Client is installed using an unattended bootstrap, it may be built into an image that starts Chef Infra Client on boot, or installed using User Data or some other kind of post-deployment script. The type of image or User Data used depends on the platform on which the unattended bootstrap will take place.
@@ -457,4 +457,4 @@ It's important that settings in the [client.rb file](/config_rb_client/)---for e
##### Setting the initial run-list
-{{< readfile file="content/workstation/reusable/md/ctl_chef_client_bootstrap_initial_run_list.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_client_bootstrap_initial_run_list.md" >}}
diff --git a/content/install_chef_air_gap.md b/content/install_chef_air_gap.md
index 9352424..be15265 100644
--- a/content/install_chef_air_gap.md
+++ b/content/install_chef_air_gap.md
@@ -71,16 +71,16 @@ The install script should be accessible from your artifact store.
## Chef Infra Server
-In this section you'll install the Chef Infra Server, and create your
+In this section you'll install Chef Infra Server, and create your
organization and user. Note that to configure Supermarket later
in this guide, you will need a user that's a member of the `admins`
group.
1. Download the package from [Chef Downloads](https://www.chef.io/downloads).
-1. Upload the package to the machine that will run the Chef Infra Server, and then record its location on the file system. The rest of these steps assume this location is in the `/tmp` directory.
+1. Upload the package to the machine that will run Chef Infra Server, and then record its location on the file system. The rest of these steps assume this location is in the `/tmp` directory.
-1. {{< readfile file="content/server/reusable/md/install_chef_server_install_package.md" >}}
+1. {{< readfile file="content/reusable/md/server/install_chef_server_install_package.md" >}}
1. Run the following to start all of the services:
@@ -88,13 +88,13 @@ group.
sudo chef-server-ctl reconfigure
```
- Because the Chef Infra Server is composed of many different services
+ Because Chef Infra Server is composed of many different services
that work together to create a functioning system, this step may
take a few minutes to complete.
-1. {{< readfile file="content/server/reusable/md/ctl_chef_server_user_create_admin.md">}}
+1. {{< readfile file="content/reusable/md/server/ctl_chef_server_user_create_admin.md">}}
-1. {{< readfile file="content/server/reusable/md/ctl_chef_server_org_create_summary.md">}}
+1. {{< readfile file="content/reusable/md/server/ctl_chef_server_org_create_summary.md">}}
## Chef Workstation
@@ -248,28 +248,28 @@ wrapper. In addition the necessary cookbooks, a private Chef Supermarket
has the following requirements:
- An operational Chef Infra Server to act as the OAuth 2.0 provider
-- A user account on the Chef Infra Server with `admins` privileges
+- A user account on Chef Infra Server with `admins` privileges
- A key for the user account on the Chef server
- An x86_64 Ubuntu, RHEL, or Amazon Linux host with at least 1 GB memory
-- System clocks synchronized on the Chef Infra Server and Supermarket hosts
+- System clocks synchronized on Chef Infra Server and Supermarket hosts
- Sufficient disk space to meet project cookbook storage capacity or credentials to store cookbooks in an Amazon Simple Storage Service (S3) bucket
### Configure credentials
First, you'll configure Chef Identity credentials for Supermarket. Chef
-Identity is an OAuth 2.0 service packaged with the Chef Infra Server,
+Identity is an OAuth 2.0 service packaged with Chef Infra Server,
that allows you to use the same credentials to access both server and
Supermarket.
-1. Log on to the Chef Infra Server using SSH and elevate to an
+1. Log on to Chef Infra Server using SSH and elevate to an
admin-level user. If running a multi-node Chef Infra Server cluster,
log on to the node acting as the primary node in the cluster.
1. Update the `/etc/opscode/chef-server.rb` configuration file.
- {{< readfile file="content/server/reusable/md/config_ocid_application_hash_supermarket.md" >}}
+ {{< readfile file="content/reusable/md/server/config_ocid_application_hash_supermarket.md" >}}
-1. Reconfigure the Chef Infra Server.
+1. Reconfigure Chef Infra Server.
```bash
sudo chef-server-ctl reconfigure
@@ -329,7 +329,7 @@ Supermarket.
### Define Attributes
Define the attributes for the Chef Supermarket installation and how it
-connects to the Chef Infra Server. One approach would be to hard-code
+connects to Chef Infra Server. One approach would be to hard-code
attributes in the wrapper cookbook's `default.rb` recipe. A better
approach is to place these attributes in a [data bag](/data_bags/),
and then reference them from the recipe. For example, the data bag could
@@ -392,7 +392,7 @@ To define these attributes, do the following:
1. Save and close the `recipes/default.rb` file.
-1. Upload all of your cookbooks to the Chef Infra Server:
+1. Upload all of your cookbooks to Chef Infra Server:
```ruby
knife cookbook upload -a
@@ -457,7 +457,7 @@ user's workstation.
certificate. A trusted SSL certificate should be used for private
Chef Supermarket that's used in production.
1. After opening Chef Supermarket in a web browser, click the **Create
- Account** link. A prompt to log in to the Chef Infra Server is
+ Account** link. A prompt to log in to Chef Infra Server is
shown. Authorize the Chef Supermarket to use the Chef Infra Server
account for authentication.
diff --git a/content/install_windows.md b/content/install_windows.md
index ef025ca..92220f1 100644
--- a/content/install_windows.md
+++ b/content/install_windows.md
@@ -22,11 +22,11 @@ There are several methods available to install Chef Infra Client depending on th
### Use knife CLI
-{{< readfile file="content/workstation/reusable/md/knife_windows_summary.md" >}}
+{{< readfile file="content/reusable/md/workstation/knife_windows_summary.md" >}}
#### Necessary Ports
-{{< readfile file="content/workstation/reusable/md/knife_windows_winrm_ports.md" >}}
+{{< readfile file="content/reusable/md/workstation/knife_windows_winrm_ports.md" >}}
### Use MSI Installer
diff --git a/content/legacy_uninstall.md b/content/legacy_uninstall.md
deleted file mode 100644
index 1ddcb2a..0000000
--- a/content/legacy_uninstall.md
+++ /dev/null
@@ -1,51 +0,0 @@
-+++
-title = "Uninstall Legacy Products"
-draft = false
-gh_repo = "chef-web-docs"
-
-[menu]
- [menu.legacy]
- title = "Uninstall"
- identifier = "legacy/uninstall"
- parent = "legacy"
- weight = 999
-+++
-
-
-## Chef Analytics
-
-Use the `uninstall` subcommand to remove the Chef Analytics
-application, but without removing any of the data. This subcommand will
-shut down all services (including the `runit` process supervisor).
-
-This subcommand has the following syntax:
-
-```bash
-opscode-analytics-ctl uninstall
-```
-
-{{< note >}}
-
-To revert the `uninstall` subcommand, run the `reconfigure` subcommand
-(because the `start` subcommand is disabled by the `uninstall` command).
-
-{{< /note >}}
-
-## Reporting
-
-Use the `uninstall` subcommand to remove the Reporting add-on to the
-Chef Infra Server, but without removing any of the data. This subcommand
-will shut down all services (including the `runit` process supervisor).
-
-This subcommand has the following syntax:
-
-```bash
-opscode-reporting-ctl uninstall
-```
-
-{{< note >}}
-
-To revert the `uninstall` subcommand, run the `reconfigure` subcommand
-(because the `start` subcommand is disabled by the `uninstall` command).
-
-{{< /note >}}
diff --git a/content/nodes.md b/content/nodes.md
index 78445a5..4e4267f 100644
--- a/content/nodes.md
+++ b/content/nodes.md
@@ -46,7 +46,7 @@ The key components of nodes that are under management by Chef include:
## Node Names
The name of a node is required as part of the authentication process to
-the Chef Infra Server. The name of each node must be unique within an
+Chef Infra Server. The name of each node must be unique within an
organization, but otherwise can be any string that matches the following
regular expression:
@@ -76,7 +76,7 @@ exact order. The node object consists of the run-list and node
attributes, which is a JSON file that's stored on the Chef Infra
Server. Chef Infra Client gets a copy of the node object from the Chef
Infra Server during each Chef Infra Client run and places an updated
-copy on the Chef Infra Server at the end of each Chef Infra Client run.
+copy on Chef Infra Server at the end of each Chef Infra Client run.
{{< readfile file="content/reusable/md/node_attribute.md" >}}
diff --git a/content/packages.md b/content/packages.md
deleted file mode 100644
index 889ea96..0000000
--- a/content/packages.md
+++ /dev/null
@@ -1,116 +0,0 @@
-+++
-title = "Chef Software Packages"
-draft = false
-gh_repo = "chef-web-docs"
-aliases = ["/packages.html"]
-product = ["automate", "client", "server", "habitat", "inspec", "supermarket", "workstation"]
-
-[menu]
- [menu.overview]
- title = "Packages"
- identifier = "overview/packages_&_platforms/packages.md Packages"
- parent = "overview/packages_&_platforms"
- weight = 10
-+++
-
-You can install packages for Chef Software products using platform-native package repositories.
-
-## Release channels
-
-{{< readfile file="content/reusable/md/release_channels.md" >}}
-
-## Package repositories
-
-The `stable` and `current` release channels support the following package repositories:
-
-- APT (Debian and Ubuntu platforms)
-- Yum (Enterprise Linux platforms)
-
-You can download Chef Software's GPG public key from [packages.chef.io](https://packages.chef.io/chef.asc).
-
-### Debian / Ubuntu
-
-To set up an APT package repository for Debian and Ubuntu platforms:
-
-1. Enable APT to fetch packages over HTTPS:
-
- ```bash
- sudo apt-get install apt-transport-https
- ```
-
-1. Install the public key for Chef Software:
-
- ```bash
- wget -qO - https://packages.chef.io/chef.asc | sudo apt-key add -
- ```
-
-1. Create the APT repository source file:
-
- ```bash
- echo "deb https://packages.chef.io/repos/apt/ main" > chef-.list
- ```
-
- Replace:
-
- - `` with the release channel: `stable` or `current`.
- - `` with the appropriate distribution name. For example:
-
- - for Debian 9: `stretch`
- - for Debian 10: `buster`
- - for Debian 11: `bullseye`
- - for Ubuntu 18.04: `bionic`
- - for Ubuntu 20.04: `focal`
-
-1. Update the package repository list:
-
- ```bash
- sudo mv chef-stable.list /etc/apt/sources.list.d/
- ```
-
-1. Update the cache for the package repository:
-
- ```bash
- sudo apt-get update
- ```
-
-### Enterprise Linux
-
-{{< note >}}
-
-Starting in Chef Infra Client 18.6.2, we upgraded the GPG signing algorithm used to sign RHEL packages from SHA1 to SHA256. RHEL 9 no longer supports the less secure SHA1 hashes.
-
-{{< /note >}}
-
-Before you begin, verify that you have the `yum-utils` package installed.
-
-To set up a Yum package repository for Enterprise Linux platforms, follow these steps:
-
-1. Install the public key for Chef Software:
-
- ```bash
- sudo rpm --import https://packages.chef.io/chef.asc
- ```
-
-1. Create the Yum repository source file:
-
- ```bash
- cat >chef-.repo <]
- name=chef-
- baseurl=https://packages.chef.io/repos/yum//el//\$basearch/
- gpgcheck=1
- # No auto-upgrade, as there are manual steps needed for Chef Infra Server upgrades
- enabled=0
- EOL
- ```
-
- Replace:
-
- - `` with the release channel: `stable` or `current`.
- - `` with the Enterprise Linux version.
-
-1. Update the package repository list:
-
- ```bash
- sudo yum-config-manager --add-repo chef-stable.repo
- ```
diff --git a/content/platform_overview.md b/content/platform_overview.md
index 08d85d3..cd979b6 100644
--- a/content/platform_overview.md
+++ b/content/platform_overview.md
@@ -59,7 +59,7 @@ Server, and chef for interacting with your local chef code repository
### Uploading your code to Chef Infra Server
Once you're done developing and testing code on your local workstation,
-you can upload it to the [Chef Infra Server](/server/). The Chef Infra Server acts
+you can upload it to the [Chef Infra Server](/server/). Chef Infra Server acts
as a hub for configuration data. It stores cookbooks, the policies that
are applied to the systems in your infrastructure and metadata that
describes each system. The knife command lets you communicate with the
@@ -69,7 +69,7 @@ upload your cookbooks.
### Configuring nodes with Chef Infra Client
Chef Infra is constructed so that most of the computational effort
-occurs on the nodes rather than on the Chef Infra Server. A node
+occurs on the nodes rather than on Chef Infra Server. A node
represents any system you manage and is typically a virtual machine,
container instance, or physical server. Basically, it's any compute
resource in your infrastructure that's managed by Chef Infra. All nodes
@@ -77,7 +77,7 @@ have Chef Infra Client installed on them, and Chef Infra Client is
available for multiple platforms including Linux, macOS, Windows, AIX,
and Solaris.
-Periodically, Chef Infra Client contacts the Chef Infra Server to
+Periodically, Chef Infra Client contacts Chef Infra Server to
retrieve the latest cookbooks. If (and only if) the current state of the
node doesn't conform to what the cookbook says it should be, Chef Infra
Client executes the cookbook instructions. This iterative process
@@ -167,7 +167,7 @@ For information on the integrated reporting capabilities in Chef Automate, see [
Chef Automate includes a high-availability Chef Infra Server with fault
tolerance, immediately consistent search results, and accurate real-time
data about your infrastructure. Chef Automate also provides a graphical
-management console for the Chef Infra Server.
+management console for Chef Infra Server.
## Learning More
diff --git a/content/platforms.md b/content/platforms.md
deleted file mode 100644
index e11955a..0000000
--- a/content/platforms.md
+++ /dev/null
@@ -1,274 +0,0 @@
-+++
-title = "Supported platforms"
-draft = false
-gh_repo = "chef-web-docs"
-aliases = ["/platforms.html", "/supported_platforms.html"]
-product = ["automate", "client", "server", "habitat", "inspec", "workstation"]
-
-[menu]
- [menu.overview]
- title = "Supported platforms"
- identifier = "overview/packages_&_platforms/platforms.md Platforms"
- parent = "overview/packages_&_platforms"
- weight = 20
-+++
-
-Chef software is supported on the operating systems (platforms)
-listed below. To see which versions of our software we currently
-support, see the [Supported Versions](/versions/) page.
-
-## Support
-
-We offer two levels of support for platforms (operating systems), [Commercial Support]({{< relref "#commercial-support">}}) and [Community Support]({{< relref "#community-support" >}}).
-
-### Commercial support
-
-Commercial support for platforms is part of paid maintenance contracts with Chef Software. Support contracts allow you to open tickets and receive service level agreement (SLA) assistance from our support desk. Commercially supported platforms are extensively tested as part of Chef's development and release process. Commercial support follows the lifecycle of the underlying operating system vendor.
-
-Commercial support is limited to the platforms listed in the "Commercial Support" tables--platforms not listed in these tables are unsupported.
-
-### Community support
-
-Community support for platforms means that members of the Chef community have contributed to these platforms and Chef doesn't actively work to maintain this functionality. Chef doesn't explicitly test community supported platforms as part of the development and release process.
-
-Many of these platforms are forks, clones, or otherwise derivative of platforms that Chef commercially supports. Continued functionality for these platforms is likely, but not guaranteed. Unsupported platforms may have missing or non-operative functionality. As always, we welcome community contributions from anyone looking to expand community support for platforms in Chef products.
-
-### Support for derived platforms
-
-Chef doesn't explicitly test or provide builds for derived distributions other than those in our supported platform list. However, if the derived distribution is a direct rebuild of the originating distribution and hasn't diverged in functionality or packaged dependencies, Chef will support our customers through our normal channels.
-
-## Platforms
-
-The sections below list the platforms that Chef Software supports.
-
-### Chef Automate
-
-#### Commercial support
-
-Commercial support for the [Chef Automate](/automate/system_requirements/) is available for platforms that use:
-
-- a Linux kernel version of 3.2 or greater
-- `systemd` as the init system
-- `useradd`
-- `curl` or `wget`
-
-### Chef Automate HA
-
-#### Commercial support
-
-See the [Chef Automate HA supported platforms](/automate/ha_on_premises_deployment_prerequisites/#software-requirements)
-documentation for a list of supported platforms for Chef Automate HA.
-
-### Chef Backend
-
-#### Commercial support
-
-The following table lists the commercially supported platforms for Chef Backend, which is the high-availability solution for Chef Infra Server.
-
-| Platform | Architecture | Version |
-| --- | --- | --- |
-| CentOS | `x86_64` | `6.x`, `7.x`, `8.x` |
-| Oracle Enterprise Linux | `x86_64` | `7.x`, `8.x` |
-| Red Hat Enterprise Linux | `x86_64` | `6.x`, `7.x`, `8.x` |
-| SUSE Linux Enterprise Server | `x86_64` | `12.x` |
-| Ubuntu (LTS releases) | `x86_64` | `16.04`, `18.04` |
-
-#### Derived platforms
-
-The following table lists supported derived platforms and versions for Chef Infra Server.
-
-See our policy on [support for derived platforms](#support-for-derived-platforms) for more information.
-
-| Platform | Architecture | Version | Parent platform |
-| --- | --- | --- | --- |
-| AlmaLinux | `x86_64` | `8.x` | CentOS |
-| Rocky Linux | `x86_64` | `8.x` | CentOS |
-
-### Chef Infra Client
-
-#### Commercial support
-
-The following table lists the commercially supported platforms and versions for Chef Infra Client.
-
-| Platform | Architecture | Version |
-| --- | --- | --- |
-| AIX | `powerpc` | `7.1` (TL5 SP2 or higher, recommended), `7.2`, `7.3` |
-| Amazon Linux | `x86_64`, `aarch64` | `2.x`, `2023` |
-| CentOS | `x86_64`, `ppc64le`, `ppc64`, `aarch64` | `7.x` |
-| Debian | `x86_64` | `10`, `11` |
-| FreeBSD | `amd64` | `13.x` |
-| macOS | `x86_64` (12.x only), `aarch64` | `12.x`, `13.x`, `14.x` |
-| Oracle Enterprise Linux | `x86_64`, `aarch64` | `7.x`, `8.x` |
-| Red Hat Enterprise Linux | `x86_64`, `ppc64le` (7.x only), `ppc64` (7.x only), `aarch64`, `s390x` (7.x / 8.x only) | `7.x`, `8.x`, `9.x` |
-| Rocky Linux | `x86_64` | `8.x`, `9.x` |
-| Solaris | `sparc`, `i86pc` | `11.3` (16.17.4 and later only), `11.4` |
-| SUSE Linux Enterprise Server | `x86_64`, `aarch64` (15.x only), `s390x` | `12`, `15` |
-| Ubuntu (LTS releases) | `x86_64`,`aarch64` (18.x and above) | `16.04`, `18.04`, `20.04`, `22.04` |
-| Windows | `x86_64` | `2016`, `10` (all channels except "insider" builds), `2019` (Long-term servicing channel (LTSC), both Desktop Experience and Server Core), `11`, `2022` |
-
-#### Derived platforms
-
-The following table lists supported derived platforms and versions for Chef Infra Client.
-
-See our policy on [support for derived platforms](#support-for-derived-platforms) for more information.
-
-| Platform | Architecture | Version | Parent platform |
-| --- | --- | --- | --- |
-| AlmaLinux | `x86_64`, `aarch64` | `8.x` | CentOS |
-
-#### Community support
-
-The following platforms are supported only using the community.
-
-| Platform | Architecture | Version |
-| --- | --- | --- |
-| Alibaba Cloud Linux | `x86_64` | 2.x |
-| Arch Linux | `x86_64` | current version |
-| Arista EOS | `x86_64` | current non-EOL releases |
-| CentOS Stream | `x86_64`, `aarch64` | current non-EOL releases |
-| Clear Linux | `x86_64` | current non-EOL releases |
-| Cumulus Linux | `x86_64` | current non-EOL releases |
-| Fedora | `x86_64`, `aarch64` | current non-EOL releases |
-| Kali Linux | `x86_64` | current non-EOL releases |
-| Linux Mint | `x86_64` | current non-EOL releases |
-| OpenIndiana Hipster | `x86_64` | current non-EOL releases |
-| openSUSE | `x86_64`, `aarch64` | `15.x` |
-| Pop!_OS | `x86_64` | current non-EOL releases |
-| Raspberry Pi OS | `aarch64` | current non-EOL releases |
-| SmartOS | `x86_64` | current non-EOL releases |
-| SUSE Linux Enterprise Desktop | `x86_64`, `aarch64` (15.x only) | `12.x`, `15.x` |
-| Ubuntu | `x86_64`, `aarch64` | Current non-LTS releases |
-| Virtuozzo | `x86_64` | Current non-LTS releases |
-| Windows | `x64` | `Windows Server, Semi-annual channel (SAC) (Server Core only)` |
-| XCP-ng | `x86_64` | 8.x |
-
-### Chef Infra Server
-
-#### Commercial support
-
-{{< readfile file="content/server/reusable/md/adopted_platforms_server.md" >}}
-
-### Chef InSpec
-
-#### Commercial support
-
-The following table lists the commercially supported platforms and versions for Chef InSpec.
-
-{{< readfile file="content/inspec/reusable/md/support_commercial_platforms.md" >}}
-
-#### Derived platforms
-
-The following table lists supported derived platforms and versions for Chef InSpec.
-
-See our policy on [support for derived platforms](#support-for-derived-platforms) for more information.
-
-{{< readfile file="content/inspec/reusable/md/support_derived_platforms.md" >}}
-
-### Chef Manage
-
-#### Commercial support
-
-The following table lists the commercially supported platforms for Chef Manage.
-
-| Platform | Architecture | Version |
-| --- | --- | --- |
-| CentOS | `x86_64` | `7.x` |
-| Oracle Enterprise Linux | `x86_64` | `7.x`, `8.x` |
-| Red Hat Enterprise Linux | `x86_64` | `7.x`, `8.x` |
-| Ubuntu (LTS releases) | `x86_64` | `16.04`, `18.04`, `20.04` |
-
-#### Derived platforms
-
-The following table lists supported derived platforms and versions for Chef Manage.
-
-See our policy on [support for derived platforms](#support-for-derived-platforms) for more information.
-
-| Platform | Architecture | Version | Parent platform |
-| --- | --- | --- | --- |
-| AlmaLinux | `x86_64` | `8.x` | CentOS |
-| Rocky Linux | `x86_64` | `8.x` | CentOS |
-
-### Chef Workstation
-
-#### Commercial support
-
-The following table lists the commercially supported platforms and versions for the Chef Workstation.
-
-{{< readfile file = "content/workstation/reusable/md/workstation_supported_platforms.md" >}}
-
-#### Derived platforms
-
-The following table lists supported derived platforms and versions for Chef Workstation.
-
-See our policy on [support for derived platforms](#support-for-derived-platforms) for more information.
-
-{{< readfile file = "content/workstation/reusable/md/workstation_supported_derived_platforms.md" >}}
-
-## Platform end-of-life policy
-
-Chef's products on particular platforms and versions reach end-of-life on the same date as the vendor EOL milestone for that operating system.
-Because different vendors use different terminology, the following table clarifies when Chef products are end-of-life according to those vendors' terms.
-
-| Platform | Vendor End-of-Life |
-| --- | --- |
-| Amazon Linux | End of Life |
-| Apple macOS | Apple supports the last three macOS releases, for example: 10.15, 11.x, and 12.x. Apple doesn't officially publish EOL dates. |
-| Debian | End of maintenance updates |
-| Enterprise Linux (covers Red Hat Enterprise Linux, CentOS) | End of Production 3 |
-| FreeBSD | End of Life |
-| IBM AIX | IBM End of Support Date |
-| Windows | End of Extended Support |
-| Oracle Enterprise Linux | Premier Support Ends |
-| Oracle Solaris | Premier Support Ends |
-| SUSE Linux Enterprise Server | General Support Ends |
-| Ubuntu Linux | End of maintenance updates |
-
-At Chef's option, additional support may be provided to customers beyond
-the vendor end-of-life in the above table. As such, the following table
-indicates upcoming product end-of-life dates for particular platforms.
-On the Chef end-of-life date, Chef discontinues building software for
-that platform and version.
-
-| Platform and Version | Vendor End-of-Life Date | Chef End-of-Life Date |
-| --- | --- | --- |
-| Amazon Linux 201X | Dec 31st, 2020 | Dec 31st, 2020 |
-| Amazon Linux 2 | Jun 30, 2025 | Jun 30, 2025 |
-| Amazon Linux 2023 | Mar 15, 2028 | Mar 15, 2028 |
-| Apple macOS 11 | Sep 26, 2023 | Sep 26, 2023 |
-| Apple macOS 12 | No current planned EOL date | No current planned EOL date |
-| CentOS 6 | Nov 30, 2020 | Nov 30, 2020 |
-| CentOS 7 | Jun 30, 2024 | Jun 30, 2024 |
-| CentOS 8 | Dec 31, 2021 | Dec 31, 2021 |
-| Debian 7 (Wheezy) | May 31st, 2018 | May 31st, 2018 |
-| Debian 8 (Jessie) | June 6th, 2020 | June 6th, 2020 |
-| Debian 9 (Stretch) | June 30th, 2022 | June 30th, 2022 |
-| Debian 10 (Buster) | June 30th, 2024 | June 30th, 2024 |
-| Debian 11 (Bullseye) | June 30th, 2026 | June 30th, 2026 |
-| FreeBSD 10-STABLE | October 31, 2018 | October 31, 2018 |
-| FreeBSD 11-STABLE | September 30, 2021 | September 30, 2021 |
-| IBM AIX 7.1 | Apr 30, 2023 | Apr 30, 2023 |
-| IBM AIX 7.2 | No current planned EOL date | No current planned EOL date |
-| IBM AIX 7.3 | Nov 30, 2026 | Nov 30, 2026 |
-| Oracle Enterprise Linux 5 | June 30, 2017 | December 31, 2017 |
-| Oracle Enterprise Linux 6 | March 31, 2021 | March 31, 2021 |
-| Oracle Enterprise Linux 7 | December 1, 2024 | December 1, 2024 |
-| Oracle Enterprise Linux 8 | July 1, 2029 | July 1, 2029 |
-| Oracle Solaris 11.3 | January 30, 2021 | No current planned EOL date |
-| Oracle Solaris 11.4 | November 31, 2031 | November 31, 2031 |
-| Red Hat Enterprise Linux 5 | April 30, 2017 | December 31, 2017 |
-| Red Hat Enterprise Linux 6 | November 30, 2020 | November 30, 2020 |
-| Red Hat Enterprise Linux 7 | June 30, 2024 | June 30, 2024 |
-| Red Hat Enterprise Linux 8 | May 31, 2029 | May 31, 2029 |
-| Red Hat Enterprise Linux 9 | May 31, 2032 | May 31, 2032 |
-| SUSE Linux Enterprise Server 11 | March 31, 2019 | March 31, 2019 |
-| SUSE Linux Enterprise Server 12 | October 31, 2024 | October 31, 2024 |
-| Ubuntu Linux 12.04 LTS | April 30, 2017 | April 30, 2017 |
-| Ubuntu Linux 14.04 LTS | April 30, 2019 | April 30, 2019 |
-| Ubuntu Linux 16.04 LTS | April 30, 2021 | April 30, 2021 |
-| Ubuntu Linux 18.04 LTS | May 31, 2023 | May 31, 2023 |
-| Ubuntu Linux 20.04 LTS | Apr 02, 2025 | Apr 02, 2025 |
-| Ubuntu Linux 22.04 LTS | Apr 01, 2027 | Apr 01, 2027 |
-| Windows Server 2008 (SP2)/R2 (SP1) | January 13, 2015 | January 14, 2020 |
-| Windows Server 2012/2012 R2 | October 10, 2023 | October 10, 2023 |
-| Windows Server 2016 | November 11, 2027 | November 11, 2027 |
-| Windows Server 2019 | October 10, 2028 | October 10, 2028 |
diff --git a/content/policyfile.md b/content/policyfile.md
index 6892a90..be98edf 100644
--- a/content/policyfile.md
+++ b/content/policyfile.md
@@ -31,11 +31,11 @@ Policyfiles make it easier to test and promote code safely with a simpler interf
The knife command line tool maps closely to the Chef Infra Server API and the objects defined by it, such as roles, environments, run-lists, cookbooks, data bags, or nodes. Chef Infra Client assembles these pieces at run-time and configures a host to do useful work.
-Policyfile focuses that workflow onto the entire system, rather than the individual components. For example, Policyfile describes whole systems, whereas each individual revision of the `Policyfile.lock.json` file uploaded to the Chef Infra Server describes a part of that system, inclusive of roles, environments, cookbooks, and the other Chef Infra Server objects necessary to configure that part of the system.
+Policyfile focuses that workflow onto the entire system, rather than the individual components. For example, Policyfile describes whole systems, whereas each individual revision of the `Policyfile.lock.json` file uploaded to Chef Infra Server describes a part of that system, inclusive of roles, environments, cookbooks, and the other Chef Infra Server objects necessary to configure that part of the system.
### Safer Workflows
-Policyfile encourages safer workflows by making it easier to publish development versions of cookbooks to the Chef Infra Server without the risk of mutating the production versions and without requiring a complicated versioning scheme to work around cookbook mutability issues. Roles are mutable and those changes are applied only to the nodes specified by the policy. Policyfile doesn't require any changes to your normal workflows. Use the same repositories you are already using, the same cookbooks, and workflows. Policyfile will prevent an updated cookbook or role from being applied immediately to all machines.
+Policyfile encourages safer workflows by making it easier to publish development versions of cookbooks to Chef Infra Server without the risk of mutating the production versions and without requiring a complicated versioning scheme to work around cookbook mutability issues. Roles are mutable and those changes are applied only to the nodes specified by the policy. Policyfile doesn't require any changes to your normal workflows. Use the same repositories you are already using, the same cookbooks, and workflows. Policyfile will prevent an updated cookbook or role from being applied immediately to all machines.
### Code Visibility
@@ -49,11 +49,11 @@ When running Chef Infra without a Policyfile, the exact set of cookbooks that ar
These conditions are re-evaluated every time Chef Infra Client runs, which can make it harder to know which cookbooks will be run by Chef Infra Client or what the effects of updating a role or uploading a new cookbook will be.
-Policyfile simplifies this behavior by computing the cookbook set on the workstation, and then producing a readable document of that solution: a `Policyfile.lock.json` file. This pre-computed file is uploaded to the Chef Infra Server, and is then used in each Chef Infra Client run that's managed by that particular policy name and policy group.
+Policyfile simplifies this behavior by computing the cookbook set on the workstation, and then producing a readable document of that solution: a `Policyfile.lock.json` file. This pre-computed file is uploaded to Chef Infra Server, and is then used in each Chef Infra Client run that's managed by that particular policy name and policy group.
### Less Expensive Computation
-When running Chef Infra without Policyfile, the Chef Infra Server loads dependency data for all known versions of all known cookbooks, and then runs an expensive computation to determine the correct set.
+When running Chef Infra without Policyfile, Chef Infra Server loads dependency data for all known versions of all known cookbooks, and then runs an expensive computation to determine the correct set.
Policyfile moves this computation to the workstation, where it's done less frequently.
@@ -65,9 +65,9 @@ Policyfile effectively replaces roles and environments. Policyfile files are ver
### Cookbook Mutability
-When running Chef without Policyfile, existing versions of cookbooks are mutable. This is convenient for many use cases, especially if users upload in-development cookbook revisions to the Chef Infra Server. But this sometimes creates issues that are similar to role mutability by allowing those cookbook changes to be applied immediately to nodes that use that cookbook. Users account for this by rigorous testing processes to ensure that only fully integrated cookbooks are ever published. This process does enforce good development habits, but at the same time it shouldn't be a required part of a workflow that ends with publishing an in-development cookbook to the Chef Infra Server for testing against real nodes. Policyfile solves this issue by using a cookbook publishing API for the Chef Infra Server that doesn't provide cookbook mutability. Name collisions are prevented by storing cookbooks by name and an opaque identifier that's computed from the content of the cookbook itself.
+When running Chef without Policyfile, existing versions of cookbooks are mutable. This is convenient for many use cases, especially if users upload in-development cookbook revisions to Chef Infra Server. But this sometimes creates issues that are similar to role mutability by allowing those cookbook changes to be applied immediately to nodes that use that cookbook. Users account for this by rigorous testing processes to ensure that only fully integrated cookbooks are ever published. This process does enforce good development habits, but at the same time it shouldn't be a required part of a workflow that ends with publishing an in-development cookbook to Chef Infra Server for testing against real nodes. Policyfile solves this issue by using a cookbook publishing API for Chef Infra Server that doesn't provide cookbook mutability. Name collisions are prevented by storing cookbooks by name and an opaque identifier that's computed from the content of the cookbook itself.
-For example, name/version collisions can occur when users temporarily fork an upstream cookbook. Even if the user contributes their change and the maintainer is responsive, there may be a period of time where the user needs their fork to make progress. This situation presents a versioning dilemma: if the user doesn't update their own version, they must overwrite the existing copy of that cookbook on the Chef Infra Server, wheres if they do update the version number it might conflict with the version number of the future release of that upstream cookbook.
+For example, name/version collisions can occur when users temporarily fork an upstream cookbook. Even if the user contributes their change and the maintainer is responsive, there may be a period of time where the user needs their fork to make progress. This situation presents a versioning dilemma: if the user doesn't update their own version, they must overwrite the existing copy of that cookbook on Chef Infra Server, wheres if they do update the version number it might conflict with the version number of the future release of that upstream cookbook.
#### Opaque IDs
@@ -80,7 +80,7 @@ The opaque identifier that's computed from the content of a cookbook is the only
Extra metadata about the cookbook is stored and included in Chef Infra Server API responses and in the `Policyfile.lock.json` file, including the source of a cookbook (Chef Supermarket, git, local disk, etc.), as well as any upstream identifiers, such as git revisions. For cookbooks that are loaded from the local disk that are in a git repo, the upstream URL, current revision ID, and the state of the repo are stored also.
-The opaque identifier is mostly behind the scenes and is only visible once published to the Chef Infra Server. Cookbooks that are uploaded to the Chef Infra Server may have extended version numbers such as `1.0.0-dev`.
+The opaque identifier is mostly behind the scenes and is only visible once published to Chef Infra Server. Cookbooks that are uploaded to Chef Infra Server may have extended version numbers such as `1.0.0-dev`.
### Environment Cookbooks
@@ -88,7 +88,7 @@ Policyfile replaces the environment cookbook pattern that's often required by Be
## Knife Commands
-The following knife commands used to set the policy group and policy name on the Chef Infra Server. For example:
+The following knife commands used to set the policy group and policy name on Chef Infra Server. For example:
```bash
knife node policy set test-node 'test-policy-group-name' 'test-policy-name'
@@ -120,7 +120,7 @@ The following settings may be configured in the client.rb file for use with Poli
`policy_group`
-: The name of a policy group that exists on the Chef Infra Server. `policy_name` must also be specified.
+: The name of a policy group that exists on Chef Infra Server. `policy_name` must also be specified.
`policy_name`
@@ -128,7 +128,7 @@ The following settings may be configured in the client.rb file for use with Poli
`use_policyfile`
-: Chef Infra Client automatically checks the configuration, node JSON, and the stored node on the Chef Infra Server to determine if Policyfile files are being used, and then automatically updates this flag. Default value: `false`.
+: Chef Infra Client automatically checks the configuration, node JSON, and the stored node on Chef Infra Server to determine if Policyfile files are being used, and then automatically updates this flag. Default value: `false`.
## knife bootstrap
@@ -136,7 +136,7 @@ A node may be bootstrapped to use Policyfile files. Use the following options as
`--policy-group POLICY_GROUP`
-: The name of a policy group that exists on the Chef Infra Server.
+: The name of a policy group that exists on Chef Infra Server.
`--policy-name POLICY_NAME`
@@ -201,121 +201,121 @@ As `chef_zero` explicitly tests outside the context of a Chef Infra Server, the
### chef clean-policy-cookbooks
-{{< readfile file="content/workstation/reusable/md/ctl_chef_clean_policy_cookbooks.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_clean_policy_cookbooks.md" >}}
#### Syntax
-{{< readfile file="content/workstation/reusable/md/ctl_chef_clean_policy_cookbooks_syntax.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_clean_policy_cookbooks_syntax.md" >}}
#### Options
-{{< readfile file="content/workstation/reusable/md/ctl_chef_clean_policy_cookbooks_options.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_clean_policy_cookbooks_options.md" >}}
### chef clean-policy-revisions
-{{< readfile file="content/workstation/reusable/md/ctl_chef_clean_policy_revisions.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_clean_policy_revisions.md" >}}
#### Syntax
-{{< readfile file="content/workstation/reusable/md/ctl_chef_clean_policy_revisions_syntax.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_clean_policy_revisions_syntax.md" >}}
#### Options
-{{< readfile file="content/workstation/reusable/md/ctl_chef_clean_policy_revisions_options.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_clean_policy_revisions_options.md" >}}
### chef delete-policy
-{{< readfile file="content/workstation/reusable/md/ctl_chef_delete_policy.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_delete_policy.md" >}}
#### Syntax
-{{< readfile file="content/workstation/reusable/md/ctl_chef_delete_policy_syntax.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_delete_policy_syntax.md" >}}
#### Options
-{{< readfile file="content/workstation/reusable/md/ctl_chef_delete_policy_options.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_delete_policy_options.md" >}}
### chef delete-policy-group
-{{< readfile file="content/workstation/reusable/md/ctl_chef_delete_policy_group.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_delete_policy_group.md" >}}
#### Syntax
-{{< readfile file="content/workstation/reusable/md/ctl_chef_delete_policy_group_syntax.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_delete_policy_group_syntax.md" >}}
#### Options
-{{< readfile file="content/workstation/reusable/md/ctl_chef_delete_policy_group_options.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_delete_policy_group_options.md" >}}
### chef diff
-{{< readfile file="content/workstation/reusable/md/ctl_chef_diff.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_diff.md" >}}
#### Syntax
-{{< readfile file="content/workstation/reusable/md/ctl_chef_diff_syntax.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_diff_syntax.md" >}}
#### Options
-{{< readfile file="content/workstation/reusable/md/ctl_chef_diff_options.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_diff_options.md" >}}
#### Examples
##### Compare current lock to latest commit on latest branch
-{{< readfile file="content/workstation/reusable/md/ctl_chef_diff_current_lock_latest_branch.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_diff_current_lock_latest_branch.md" >}}
##### Compare current lock with latest commit on master branch
-{{< readfile file="content/workstation/reusable/md/ctl_chef_diff_current_lock_master_branch.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_diff_current_lock_master_branch.md" >}}
##### Compare current lock to specified revision
-{{< readfile file="content/workstation/reusable/md/ctl_chef_diff_current_lock_specified_revision.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_diff_current_lock_specified_revision.md" >}}
##### Compare lock on master branch to lock on revision
-{{< readfile file="content/workstation/reusable/md/ctl_chef_diff_master_lock_revision_lock.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_diff_master_lock_revision_lock.md" >}}
##### Compare lock for version with latest commit on master branch
-{{< readfile file="content/workstation/reusable/md/ctl_chef_diff_version_lock_master_branch.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_diff_version_lock_master_branch.md" >}}
##### Compare current lock with latest lock for policy group
-{{< readfile file="content/workstation/reusable/md/ctl_chef_diff_current_lock_policy_group.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_diff_current_lock_policy_group.md" >}}
##### Compare locks for two policy group
-{{< readfile file="content/workstation/reusable/md/ctl_chef_diff_two_policy_groups.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_diff_two_policy_groups.md" >}}
### chef export
-{{< readfile file="content/workstation/reusable/md/ctl_chef_export.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_export.md" >}}
#### Syntax
-{{< readfile file="content/workstation/reusable/md/ctl_chef_export_syntax.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_export_syntax.md" >}}
#### Options
-{{< readfile file="content/workstation/reusable/md/ctl_chef_export_options.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_export_options.md" >}}
### chef generate policyfile
-{{< readfile file="content/workstation/reusable/md/ctl_chef_generate_policyfile.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_generate_policyfile.md" >}}
#### Syntax
-{{< readfile file="content/workstation/reusable/md/ctl_chef_generate_policyfile_syntax.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_generate_policyfile_syntax.md" >}}
#### Options
-{{< readfile file="content/workstation/reusable/md/ctl_chef_generate_policyfile_options.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_generate_policyfile_options.md" >}}
### chef generate repo
-{{< readfile file="content/workstation/reusable/md/ctl_chef_generate_repo.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_generate_repo.md" >}}
{{< note >}}
@@ -325,23 +325,23 @@ This subcommand requires using one (or more) of the options (below) to support P
#### Syntax
-{{< readfile file="content/workstation/reusable/md/ctl_chef_generate_repo_syntax.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_generate_repo_syntax.md" >}}
#### Options
-{{< readfile file="content/workstation/reusable/md/ctl_chef_generate_repo_options.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_generate_repo_options.md" >}}
### chef install
-{{< readfile file="content/workstation/reusable/md/ctl_chef_install.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_install.md" >}}
#### Syntax
-{{< readfile file="content/workstation/reusable/md/ctl_chef_install_syntax.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_install_syntax.md" >}}
#### Options
-{{< readfile file="content/workstation/reusable/md/ctl_chef_install_options.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_install_options.md" >}}
#### Policyfile.lock.json
@@ -351,60 +351,60 @@ This subcommand requires using one (or more) of the options (below) to support P
### chef push
-{{< readfile file="content/workstation/reusable/md/ctl_chef_push.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_push.md" >}}
#### Syntax
-{{< readfile file="content/workstation/reusable/md/ctl_chef_push_syntax.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_push_syntax.md" >}}
#### Options
-{{< readfile file="content/workstation/reusable/md/ctl_chef_push_options.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_push_options.md" >}}
### chef push-archive
-{{< readfile file="content/workstation/reusable/md/ctl_chef_push_archive.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_push_archive.md" >}}
#### Syntax
-{{< readfile file="content/workstation/reusable/md/ctl_chef_push_archive_syntax.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_push_archive_syntax.md" >}}
#### Options
-{{< readfile file="content/workstation/reusable/md/ctl_chef_push_archive_options.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_push_archive_options.md" >}}
### chef show-policy
-{{< readfile file="content/workstation/reusable/md/ctl_chef_show_policy.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_show_policy.md" >}}
#### Syntax
-{{< readfile file="content/workstation/reusable/md/ctl_chef_show_policy_syntax.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_show_policy_syntax.md" >}}
#### Options
-{{< readfile file="content/workstation/reusable/md/ctl_chef_show_policy_options.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_show_policy_options.md" >}}
### chef undelete
-{{< readfile file="content/workstation/reusable/md/ctl_chef_undelete.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_undelete.md" >}}
#### Syntax
-{{< readfile file="content/workstation/reusable/md/ctl_chef_undelete_syntax.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_undelete_syntax.md" >}}
#### Options
-{{< readfile file="content/workstation/reusable/md/ctl_chef_undelete_options.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_undelete_options.md" >}}
### chef update
-{{< readfile file="content/workstation/reusable/md/ctl_chef_update.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_update.md" >}}
#### Syntax
-{{< readfile file="content/workstation/reusable/md/ctl_chef_update_syntax.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_update_syntax.md" >}}
#### Options
-{{< readfile file="content/workstation/reusable/md/ctl_chef_update_options.md" >}}
+{{< readfile file="content/reusable/md/workstation/ctl_chef_update_options.md" >}}
diff --git a/content/recipes.md b/content/recipes.md
index fd0d838..92545b4 100644
--- a/content/recipes.md
+++ b/content/recipes.md
@@ -479,7 +479,7 @@ rescue Net::HTTPClientException
end
```
-where `data_bag_item` makes an HTTP request to the Chef Infra Server to
+where `data_bag_item` makes an HTTP request to Chef Infra Server to
get a data bag item named `flowers`. If there is a problem, the request
will return a `Net::HTTPClientException`. The `rescue` block can be used
to try to retry or otherwise handle the situation. If the `rescue` block
diff --git a/content/resource.md b/content/resource.md
new file mode 100644
index 0000000..bf2cea7
--- /dev/null
+++ b/content/resource.md
@@ -0,0 +1,100 @@
++++
+title = "About Resources"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+aliases = ["/resource.html"]
+
+[menu]
+ [menu.infra]
+ title = "About Resources"
+ identifier = "chef_infra/resources/resource.md About Resources"
+ parent = "chef_infra/resources"
+ weight = 10
++++
+
+{{< readfile file="content/reusable/md/resources_common.md" >}}
+
+## Resource Syntax
+
+A resource is a Ruby block with four components: a type, a name, one (or
+more) properties (with values), and one (or more) actions. The syntax
+for a resource is like this:
+
+```ruby
+type 'name' do
+ attribute 'value'
+ action :type_of_action
+end
+```
+
+Every resource has its own set of actions and properties. Most
+properties have default values. Some properties are available to all
+resources, for example those used to send notifications to other
+resources and guards that help ensure that some resources are
+idempotent.
+
+For example, a resource that's used to install a tar.gz package for
+version 1.16.1 may look something like this:
+
+```ruby
+package 'tar' do
+ version '1.16.1'
+ action :install
+end
+```
+
+All actions have a default value. Only non-default behaviors of actions
+and properties need to be specified. For example, the **package**
+resource's default action is `:install` and the name of the package
+defaults to the `name` of the resource. Therefore, it's possible to
+write a resource block that installs the latest tar.gz package like
+this:
+
+```ruby
+package 'tar'
+```
+
+and a resource block that installs a tar.gz package for version 1.6.1
+like this:
+
+```ruby
+package 'tar' do
+ version '1.16.1'
+end
+```
+
+In both cases, Chef Infra Client will use the default action
+(`:install`) to install the `tar` package.
+
+## Additional Information
+
+See these guides for additional information about resources:
+
+
diff --git a/content/resource_common.md b/content/resource_common.md
new file mode 100644
index 0000000..f3fc160
--- /dev/null
+++ b/content/resource_common.md
@@ -0,0 +1,343 @@
++++
+title = "Common Resource Functionality"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+aliases = ["/resource_common.html"]
+
+[menu]
+ [menu.infra]
+ title = "Common Resource Functionality"
+ identifier = "chef_infra/resources/resource_common.md Common Resource Functionality"
+ parent = "chef_infra/resources"
+ weight = 40
++++
+
+
+All resources (including custom resources) share a set of common
+actions, properties, conditional executions, notifications, and relative
+path options.
+
+## Actions
+
+The following actions may be used with any resource:
+
+`:nothing`
+
+: {{< readfile file="content/reusable/md/resources_common_actions_nothing.md" >}}
+
+### Examples
+
+The following examples show how to use common actions in a recipe.
+
+**Use the :nothing action**
+
+{{< readfile file="content/reusable/md/resource_service_use_nothing_action.md" >}}
+
+## Properties
+
+{{< readfile file="content/reusable/md/resources_common_properties.md" >}}
+
+### Examples
+
+The following examples show how to use common properties in a recipe.
+
+**Use the ignore_failure common property**
+
+{{< readfile file="content/reusable/md/resource_package_use_ignore_failure_attribute.md" >}}
+
+**Use the retries and retry_delay common properties**
+
+{{< readfile file="content/reusable/md/resource_service_use_retries_properties.md" >}}
+
+## Guards
+
+{{< readfile file="content/reusable/md/resources_common_guards.md" >}}
+
+{{< note >}}
+
+When using the `not_if` and `only_if` guards with the **execute**
+resource, the guard's environment is inherited from the resource's
+environment. For example:
+
+```ruby
+execute 'bundle install' do
+ cwd '/myapp'
+ not_if 'bundle check' # This is run from /myapp
+end
+```
+
+{{< /note >}}
+
+### Properties
+
+{{< readfile file="content/reusable/md/resources_common_guards_properties.md" >}}
+
+### Arguments
+
+{{< readfile file="content/reusable/md/resources_common_guards_arguments.md" >}}
+
+### not_if Examples
+
+**Update if not already updated**
+
+The following example shows how to use `not_if` to guard against running
+the `apt-get-update` command when a file already exists that's the same
+as the updated file:
+
+```ruby
+execute 'apt-get-update' do
+ command 'apt-get update'
+ ignore_failure true
+ not_if { ::File.exist?('/var/lib/apt/periodic/update-success-stamp') }
+end
+```
+
+**Ensure a node can resolve a host**
+
+The following example shows how to use a custom block of Ruby code to
+ensure that a node can resolve the host. If the node can resolve the
+host, Chef Infra Client will do nothing. If the node can't resolve the
+host, Chef Infra Client will configure the host:
+
+```ruby
+ruby_block 'ensure node can resolve API FQDN' do
+ block do
+ fe = Chef::Util::FileEdit.new('/etc/hosts')
+ fe.insert_line_if_no_match(/#{node['chef-server']['api_fqdn']}/,
+ "127.0.0.1 #{node['chef-server']['api_fqdn']}")
+ fe.write_file
+ end
+ not_if { Resolv.getaddress(node['chef-server']['api_fqdn']) rescue false }
+end
+```
+
+**Prevent installs on older versions**
+
+The following example shows how to use `not_if` to prevent ZeroMQ from
+being installed when the node on which the install is to occur has a
+version of Red Hat Enterprise Linux that's older than version 6.0:
+
+```ruby
+ark 'test_autogen' do
+ url 'https://github.com/zeromq/libzmq/tarball/master'
+ extension 'tar.gz'
+ action :configure
+ not_if { platform_family?('rhel') && node['platform_version'].to_f < 6.0 }
+end
+```
+
+**Set the administrator if not already set**
+
+The following example shows how to set the administrator for Nagios on
+multiple nodes, except when the package already exists on a node:
+
+```ruby
+%w(adminpassword adminpassword-repeat).each do |setting|
+ execute "debconf-set-selections::#{node['nagios']['server']['vname']}-cgi::#{node['nagios']['server']['vname']}/#{setting}" do
+ command "echo #{node['nagios']['server']['vname']}-cgi #{node['nagios']['server']['vname']}/#{setting} password #{random_initial_password} | debconf-set-selections"
+ not_if "dpkg -l #{node['nagios']['server']['vname']}"
+ end
+end
+```
+
+### only_if Examples
+
+**Install packages only when necessary**
+
+The following example shows how to use `only_if` with one (or more)
+cookbook attributes to ensure that packages are only installed when
+necessary. In this case, three attributes exist in the
+`/attributes/default.rb` file: `use_openssl`, `use_pcre`, and
+`use_zlib`. Each of these attributes are defined as `false` by default.
+The `only_if` attributes are used to test for the presence of these
+packages on the target node before then asking Chef Infra Client to
+complete the process of installing these packages. If the packages are
+already present, Chef Infra Client will do nothing.
+
+```ruby
+package 'libpcre3-dev' do
+ only_if { node['haproxy']['source']['use_pcre'] }
+end
+
+package 'libssl-dev' do
+ only_if { node['haproxy']['source']['use_openssl'] }
+end
+
+package 'zlib1g-dev' do
+ only_if { node['haproxy']['source']['use_zlib'] }
+end
+```
+
+**Remove a recipe if it belongs to a specific run-list**
+
+The following example shows how to use `only_if` to only remove a recipe
+named `recipe[ntp::undo]`, but only when that recipe is part of the
+`recipe[ntp::default]` run-list:
+
+```ruby
+ruby_block 'remove ntp::undo from run list' do
+ block do
+ node.run_list.remove('recipe[ntp::undo]')
+ end
+ only_if { node.run_list.include?('recipe[ntp::default]') }
+end
+```
+
+**Re-register ASP.Net if it's already installed**
+
+The following example shows how to use `only_if` to ensure that Chef
+Infra Client will attempt to register ASP.NET only if the executable is
+installed on the system, on both 32- and 64-bit systems:
+
+```ruby
+aspnet_regiis = "#{ENV['WinDir']}\\Microsoft.NET\\Framework\\v4.0.30319\\aspnet_regiis.exe"
+execute 'Register ASP.NET v4' do
+ command "#{aspnet_regiis} -i"
+ only_if { ::File.exist?(aspnet_regiis) }
+ action :nothing
+end
+
+aspnet_regiis64 = "#{ENV['WinDir']}\\Microsoft.NET\\Framework64\\v4.0.30319\\aspnet_regiis.exe"
+execute 'Register ASP.NET v4 (x64)' do
+ command "#{aspnet_regiis64} -i"
+ only_if { ::File.exist?(aspnet_regiis64) }
+ action :nothing
+end
+```
+
+## Guard Interpreters
+
+{{< readfile file="content/reusable/md/resources_common_guard_interpreter.md" >}}
+
+### Attributes
+
+{{< readfile file="content/reusable/md/resources_common_guard_interpreter_attributes.md" >}}
+
+### Inheritance
+
+{{< readfile file="content/reusable/md/resources_common_guard_interpreter_attributes_inherit.md" >}}
+
+### Examples
+
+{{< readfile file="content/reusable/md/resources_common_guard_interpreter_example_default.md" >}}
+
+## Lazy Evaluation
+
+{{< readfile file="content/reusable/md/resources_common_lazy_evaluation.md" >}}
+
+## Notifications
+
+{{< readfile file="content/reusable/md/resources_common_notification.md" >}}
+
+### Timers
+
+{{< readfile file="content/reusable/md/resources_common_notification_timers.md" >}}
+
+### Notifies
+
+{{< readfile file="content/reusable/md/resources_common_notification_notifies.md" >}}
+
+{{< readfile file="content/reusable/md/resources_common_notification_notifies_syntax.md" >}}
+
+Changed in Chef Infra Client 12.6 to use `:before` timer with the `notifies`
+and `subscribes` properties to specify that the action on a notified
+resource should be run before processing the resource block in which the
+notification is located.
+
+#### Examples
+
+The following examples show how to use the `notifies` notification in a
+recipe.
+
+**Delay notifications**
+
+{{< readfile file="content/reusable/md/resource_template_notifies_delay.md" >}}
+
+**Notify immediately**
+
+{{< readfile file="content/reusable/md/resource_template_notifies_run_immediately.md" >}}
+
+**Notify multiple resources**
+
+{{< readfile file="content/reusable/md/resource_template_notifies_multiple_resources.md" >}}
+
+**Notify in a specific order**
+
+{{< readfile file="content/reusable/md/resource_execute_notifies_specific_order.md" >}}
+
+**Reload a service**
+
+{{< readfile file="content/reusable/md/resource_template_notifies_reload_service.md" >}}
+
+**Restart a service when a template is modified**
+
+{{< readfile file="content/reusable/md/resource_template_notifies_restart_service_when_template_modified.md" >}}
+
+**Send notifications to multiple resources**
+
+{{< readfile file="content/reusable/md/resource_template_notifies_send_notifications_to_multiple_resources.md" >}}
+
+**Execute a command using a template**
+
+{{< readfile file="content/reusable/md/resource_execute_command_from_template.md" >}}
+
+**Restart a service, and then notify a different service**
+
+{{< readfile file="content/reusable/md/resource_service_restart_and_notify.md" >}}
+
+**Restart one service before restarting another**
+
+{{< readfile file="content/reusable/md/resource_before_notification_restart.md" >}}
+
+**Notify when a remote source changes**
+
+{{< readfile file="content/reusable/md/resource_remote_file_transfer_remote_source_changes.md" >}}
+
+### Subscribes
+
+{{< readfile file="content/reusable/md/resources_common_notification_subscribes.md" >}}
+
+{{< readfile file="content/reusable/md/resources_common_notification_subscribes_syntax.md" >}}
+
+#### Examples
+
+The following examples show how to use the `subscribes` notification in
+a recipe.
+
+**Verify a configuration update**
+
+{{< readfile file="content/reusable/md/resource_execute_subscribes_prevent_restart_and_reconfigure.md" >}}
+
+**Reload a service when a template is updated**
+
+{{< readfile file="content/reusable/md/resource_service_subscribes_reload_using_template.md" >}}
+
+## Relative Paths
+
+{{< readfile file="content/reusable/md/resources_common_relative_paths.md" >}}
+
+### Examples
+
+{{< readfile file="content/reusable/md/resource_template_use_relative_paths.md" >}}
+
+## Run in Compile Phase
+
+{{< readfile file="content/reusable/md/resources_common_compile.md" >}}
+
+### Using the compile_time property
+
+{{< readfile file="content/reusable/md/resources_common_compile_begin.md" >}}
+
+## Windows File Security
+
+{{< readfile file="content/reusable/md/resources_common_windows_security.md" >}}
+
+### Access Control Lists (ACLs)
+
+{{< readfile file="content/reusable/md/resources_common_windows_security_acl.md" >}}
+
+### Inheritance
+
+{{< readfile file="content/reusable/md/resources_common_windows_security_inherits.md" >}}
diff --git a/content/reusable/README.md b/content/reusable/README.md
new file mode 100644
index 0000000..f12c644
--- /dev/null
+++ b/content/reusable/README.md
@@ -0,0 +1,9 @@
+
+# Directory for reusable files
+
+
+Files in this directory are used in *more than one place* within the Chef docs.
+
+Store all files in subdirectories organized by file type. For example, all Markdown files should be in `content/reusable/md/` and all Ruby files are stored in `content/reusable/rb/`.
+
+Call these files using the [`readfile` shortcode](https://docs.chef.io/style/reuse/#readfile-shortcode).
diff --git a/content/reusable/md/agentless_custom_resource.md b/content/reusable/md/agentless_custom_resource.md
new file mode 100644
index 0000000..9b84cd0
--- /dev/null
+++ b/content/reusable/md/agentless_custom_resource.md
@@ -0,0 +1,6 @@
+To enable a custom resource to run in Agentless, add `target_mode: true` to the resource definition. For example:
+
+```ruby
+provides :resource_name, target_mode: true
+...
+```
diff --git a/content/reusable/md/agentless_custom_resource_example.md b/content/reusable/md/agentless_custom_resource_example.md
new file mode 100644
index 0000000..d3e0b87
--- /dev/null
+++ b/content/reusable/md/agentless_custom_resource_example.md
@@ -0,0 +1,31 @@
+
+The following custom resource example checks for and creates a new directory and runs in Agentless:
+
+```ruby
+provides :example_directory, target_mode: true
+unified_mode true
+
+property: directory, String
+
+load_current_value do |new_resource|
+ dir = new_resource.directory
+ parsed = dir.match(%r{([^/]+$)})
+ path = ''
+ if parsed
+ path = dir[0..(dir.length - parsed[1].length - 1)]
+ dir = parsed[1]
+ end
+
+ tmp = __transport_connection.run_command( sprintf('ls -l %s | grep %s || echo -n', path, dir) )
+
+ if tmp.match(Regexp.new(dir))
+ directory new_resource.directory
+ end
+end
+
+action :create do
+ converge_if_changed do
+ __transport_connection.run_command( sprintf('mkdir %s', new_resource.directory) )
+ end
+end
+```
diff --git a/content/reusable/md/agentless_summary.md b/content/reusable/md/agentless_summary.md
new file mode 100644
index 0000000..8625e9f
--- /dev/null
+++ b/content/reusable/md/agentless_summary.md
@@ -0,0 +1 @@
+Agentless executes Chef Infra Client runs on nodes that don't have Chef Infra Client installed on them.
diff --git a/content/reusable/md/chef.md b/content/reusable/md/chef.md
new file mode 100644
index 0000000..0dfc8b3
--- /dev/null
+++ b/content/reusable/md/chef.md
@@ -0,0 +1,10 @@
+Chef Infra is a powerful automation platform that transforms
+infrastructure into code. Whether you're operating in the cloud,
+on-premises, or in a hybrid environment, Chef Infra automates how
+infrastructure is configured, deployed, and managed across your network,
+no matter its size.
+
+This diagram shows how you develop, test, and deploy your Chef Infra
+code.
+
+
diff --git a/content/reusable/md/chef_client_bootstrap_node.md b/content/reusable/md/chef_client_bootstrap_node.md
new file mode 100644
index 0000000..20621d3
--- /dev/null
+++ b/content/reusable/md/chef_client_bootstrap_node.md
@@ -0,0 +1,9 @@
+A node is any physical, virtual, or cloud device that's configured and
+maintained by an instance of Chef Infra Client. Bootstrapping installs
+Chef Infra Client on a target system so that it can run as a client and
+sets the node up to communicate with a Chef Infra Server. There are two
+ways to do this:
+
+- Run the `knife bootstrap` command from a workstation.
+- Perform an unattended install to bootstrap from the node itself,
+ without requiring SSH or WinRM connectivity.
diff --git a/content/reusable/md/chef_client_bootstrap_stages.md b/content/reusable/md/chef_client_bootstrap_stages.md
new file mode 100644
index 0000000..439be70
--- /dev/null
+++ b/content/reusable/md/chef_client_bootstrap_stages.md
@@ -0,0 +1,36 @@
+The following diagram shows the stages of the bootstrap operation,
+and the list below the diagram describes each of those stages in greater detail.
+
+
+
+When you run `knife bootstrap` on a node for the first time, Chef Workstation, Infra Client, and Infra Server handle the following tasks:
+
+1. **Run `knife bootstrap`**
+
+ Run the [`knife bootstrap`](/workstation/knife_bootstrap/) subcommand from a workstation. Include the hostname, IP address, or FQDN of the target node as part of this command. Knife establishes an SSH or WinRM connection with the target system and runs the bootstrap script.
+
+ By default, the first Chef Infra Client run has an empty run list. You can add a [run list](/run_lists/) to the initial bootstrap operation using the [`--run-list`](/workstation/knife_bootstrap/#node-options) option.
+
+1. **Get the install script**
+
+ A shell script gets the most recent version of the [Chef Infra Client install script](/chef_install_script/) (`install.sh` or `install.ps1`) from Chef.
+
+1. **Get the Chef Infra Client package**
+
+ The install script gathers system-specific information, determines the correct package for Chef Infra Client, and downloads that package from Chef's downloads API.
+
+1. **Install Chef Infra Client**
+
+ Chef Infra Client is installed on the target node using a system native package (.rpm, .msi, etc).
+
+1. **Start a Chef Infra Client run**
+
+ When you first run `knife bootstrap`, Chef Workstation creates a `first-boot.json` file with some initial settings.
+
+ On UNIX and Linux-based machines, the second shell script executes the `chef-client` binary with the `first-boot.json` file on the node.
+
+ On Windows machines, the batch file that's derived from the `windows-chef-client-msi.erb` bootstrap template executes the `chef-client` binary with the `first-boot.json` file on the node.
+
+1. **Complete the Chef Infra Client run**
+
+ The Chef Infra Client run proceeds using HTTPS (port 443) and registers the node with Chef Infra Server.
diff --git a/content/reusable/md/chef_client_run.md b/content/reusable/md/chef_client_run.md
new file mode 100644
index 0000000..91c2243
--- /dev/null
+++ b/content/reusable/md/chef_client_run.md
@@ -0,0 +1,73 @@
+A "Chef Infra Client run" is the term used to describe the steps Chef Infra Client takes to configure a node when the chef-client command is run. The following diagram shows the various stages that occur during a Chef Infra Client run.
+
+
+
+
+
+
+During every Chef Infra Client run, the following happens:
+
+
+
+
+
+
+
+
+
Stages
+
Description
+
+
+
+
+
Get configuration data
+
Chef Infra Client gets process configuration data from the client.rb file on the node, and then gets node configuration data from Ohai. One important piece of configuration data is the name of the node, which is found in the node_name attribute in the client.rb file or is provided by Ohai. If Ohai provides the name of a node, it's typically the FQDN for the node, which is always unique within an organization.
+
+
+
Authenticate to Chef Infra Server
+
Chef Infra Client authenticates to Chef Infra Server using an RSA private key and Chef Infra Server API. The name of the node is required as part of the authentication process to Chef Infra Server. If this is the first Chef Infra Client run for a node, the chef-validator will be used to generate the RSA private key.
+
+
+
Get, rebuild the node object
+
Chef Infra Client pulls down the node object from Chef Infra Server and then rebuilds it. A node object is made up of the system attributes discovered by Ohai, the attributes set in Policyfiles or Cookbooks, and the run list of cookbooks. The first time Chef Infra Client runs on a node, it creates a node object from the default run-list. A node that hasn't yet had a Chef Infra Client run won't have a node object or a Chef Infra Server entry for a node object. On any subsequent Chef Infra Client runs, the rebuilt node object will also contain the run-list from the previous Chef Infra Client run.
+
+
+
Expand the run-list
+
Chef Infra Client expands the run-list from the rebuilt node object and compiles a complete list of recipes in the exact order that they will be applied to the node.
+
+
+
Synchronize cookbooks
+
Chef Infra Client requests all the cookbook files (including recipes, templates, resources, providers, attributes, and libraries) that it needs for every action identified in the run-list from Chef Infra Server. Chef Infra Server responds to Chef Infra Client with the complete list of files. Chef Infra Client compares the list of files to the files that already exist on the node from previous runs, and then downloads a copy of every new or modified file from Chef Infra Server.
+
+
+
Reset node attributes
+
All attributes in the rebuilt node object are reset. All attributes from attribute files, Policyfiles, and Ohai are loaded. Attributes that are defined in attribute files are first loaded according to cookbook order. For each cookbook, attributes in the default.rb file are loaded first, and then additional attribute files (if present) are loaded in lexical sort order. If attribute files are found within any cookbooks that are listed as dependencies in the metadata.rb file, these are loaded as well. All attributes in the rebuilt node object are updated with the attribute data according to attribute precedence. When all the attributes are updated, the rebuilt node object is complete.
+
+
+
Compile the resource collection
+
Chef Infra Client identifies each resource in the node object and builds the resource collection. Libraries are loaded first to ensure that all language extensions and Ruby classes are available to all resources. Next, attributes are loaded, followed by custom resources. Finally, all recipes are loaded in the order specified by the expanded run-list. This is also referred to as the "compile phase".
+
+
+
Converge the node
+
Chef Infra Client configures the system based on the information that has been collected. Each resource is executed in the order identified by the run-list, and then by the order in which each resource is listed in each recipe. Each resource defines an action to run, which configures a specific part of the system. This process is also referred to as convergence. This is also referred to as the "execution phase".
+
+
+
Update the node object, process exception and report handlers
+
When all the actions identified by resources in the resource collection have been done and Chef Infra Client finishes successfully, then Chef Infra Client updates the node object on Chef Infra Server with the node object built during a Chef Infra Client run. (This node object will be pulled down by Chef Infra Client during the next Chef Infra Client run.) This makes the node object (and the data in the node object) available for search.
+
Chef Infra Client always checks the resource collection for the presence of exception and report handlers. If any are present, each one is processed appropriately.
+
+
+
Get, run Chef InSpec Compliance Profiles
+
After the Chef Infra Client run finishes, it begins the Compliance Phase, which is a Chef InSpec run within the Chef Infra Client. Chef InSpec retrieves tests from either a legacy audit cookbook or a current InSpec profile.
+
+
+
Send or Save Compliance Report
+
When all the InSpec tests finish running, Chef InSpec checks the reporting handlers defined in the legacy audit cookbook or in a current InSpec profile and processes them appropriately.
+
+
+
Stop, wait for the next run
+
When everything is configured and the Chef Infra Client run is complete, Chef Infra Client stops and waits until the next time it's asked to run.
+
+
+
+
diff --git a/content/reusable/md/chef_client_summary.md b/content/reusable/md/chef_client_summary.md
new file mode 100644
index 0000000..741ea66
--- /dev/null
+++ b/content/reusable/md/chef_client_summary.md
@@ -0,0 +1,7 @@
+Chef Infra Client is an agent that runs locally on every node that's under management by Chef Infra Server. When Chef Infra Client runs, it performs all of the steps required for bringing a node into the expected state, including:
+
+- Registering and authenticating the node with Chef Infra Server
+- Synchronizing cookbooks from Chef Infra Server to the node
+- Compiling the resource collection by loading each of the required cookbooks, including recipes, attributes, and all other dependencies
+- Taking the appropriate and required actions to configure the node based on recipes and attributes
+- Reporting summary information on the run to Chef Automate
diff --git a/content/reusable/md/chef_repo_description.md b/content/reusable/md/chef_repo_description.md
new file mode 100644
index 0000000..2a6a462
--- /dev/null
+++ b/content/reusable/md/chef_repo_description.md
@@ -0,0 +1,16 @@
+The chef-repo is a directory on your workstation that stores everything
+you need to define your infrastructure with Chef Infra:
+
+- Cookbooks (including recipes, attributes, custom resources, libraries, and templates)
+- Data bags
+- Policyfiles
+
+The chef-repo directory should be synchronized with a version control
+system, such as git. All of the data in the chef-repo should be treated
+like source code.
+
+You'll use the `chef` and `knife` commands to upload data to the Chef
+Infra Server from the chef-repo directory. Once uploaded, Chef Infra
+Client uses that data to manage the nodes registered with the Chef Infra
+Server and to ensure that it applies the right cookbooks, policyfiles,
+and settings to the right nodes in the right order.
diff --git a/content/reusable/md/chef_repo_many_users_same_knife.md b/content/reusable/md/chef_repo_many_users_same_knife.md
new file mode 100644
index 0000000..d26903b
--- /dev/null
+++ b/content/reusable/md/chef_repo_many_users_same_knife.md
@@ -0,0 +1,27 @@
+The config.rb configuration can include arbitrary Ruby code to extend
+configuration beyond static values. This can be used to load
+environmental variables from the workstation. This makes it possible to
+write a single config.rb file that can be used by all users within your
+organization. This single file can also be checked into your chef-repo,
+allowing users to load different config.rb files based on which
+chef-repo they execute the commands from. This can be especially useful
+when each chef-repo points to a different chef server or organization.
+
+Example config.rb:
+
+```ruby
+current_dir = File.dirname(__FILE__)
+ user = ENV['CHEF_USER'] || ENV['USER']
+ node_name user
+ client_key "#{ENV['HOME']}/chef-repo/.chef/#{user}.pem"
+ chef_server_url "https://api.opscode.com/organizations/#{ENV['ORGNAME']}"
+ syntax_check_cache_path "#{ENV['HOME']}/chef-repo/.chef/syntax_check_cache"
+ cookbook_path ["#{current_dir}/../cookbooks"]
+ cookbook_copyright "Your Company, Inc."
+ cookbook_license "Apache-2.0"
+ cookbook_email "cookbooks@yourcompany.com"
+
+ # Amazon AWS
+ knife[:aws_access_key_id] = ENV['AWS_ACCESS_KEY_ID']
+ knife[:aws_secret_access_key] = ENV['AWS_SECRET_ACCESS_KEY']
+```
diff --git a/content/reusable/md/chef_shell_advanced_debug.md b/content/reusable/md/chef_shell_advanced_debug.md
new file mode 100644
index 0000000..992e65b
--- /dev/null
+++ b/content/reusable/md/chef_shell_advanced_debug.md
@@ -0,0 +1,32 @@
+In chef-shell, it's possible to get verbose debugging using the tracing
+feature in Interactive Ruby (IRb). chef-shell provides a shortcut for
+turning tracing on and off. For example:
+
+```bash
+chef > tracing on
+tracing is on
+=> nil
+chef >
+```
+
+and:
+
+```bash
+chef > tracing off
+#0:(irb):2:Object:-: tracing off
+#0:/opt/chef-workstation/embedded/lib/ruby/gems/2.6.0/gems/chef-15.8.23/lib/chef/shell/ext.rb:109:Shell::Extensions::ObjectCoreExtensions:>: def off
+#0:/opt/chef-workstation/embedded/lib/ruby/gems/2.6.0/gems/chef-15.8.23/lib/chef/shell/ext.rb:110:Shell::Extensions::ObjectCoreExtensions:-: :off
+#0:/opt/chef-workstation/embedded/lib/ruby/gems/2.6.0/gems/chef-15.8.23/lib/chef/shell/ext.rb:111:Shell::Extensions::ObjectCoreExtensions:<: end
+#0:/opt/chef-workstation/embedded/lib/ruby/gems/2.6.0/gems/chef-15.8.23/lib/chef/shell/ext.rb:272:main:>: def tracing(on_or_off)
+#0:/opt/chef-workstation/embedded/lib/ruby/gems/2.6.0/gems/chef-15.8.23/lib/chef/shell/ext.rb:273:main:-: conf.use_tracer = on_or_off.on_off_to_bool
+#0:/opt/chef-workstation/embedded/lib/ruby/gems/2.6.0/gems/chef-15.8.23/lib/chef/shell/ext.rb:162:Shell::Extensions::Symbol:>: def on_off_to_bool
+#0:/opt/chef-workstation/embedded/lib/ruby/gems/2.6.0/gems/chef-15.8.23/lib/chef/shell/ext.rb:163:Shell::Extensions::Symbol:-: to_s.on_off_to_bool
+#0:/opt/chef-workstation/embedded/lib/ruby/gems/2.6.0/gems/chef-15.8.23/lib/chef/shell/ext.rb:149:Shell::Extensions::String:>: def on_off_to_bool
+#0:/opt/chef-workstation/embedded/lib/ruby/gems/2.6.0/gems/chef-15.8.23/lib/chef/shell/ext.rb:150:Shell::Extensions::String:-: case self
+#0:/opt/chef-workstation/embedded/lib/ruby/gems/2.6.0/gems/chef-15.8.23/lib/chef/shell/ext.rb:154:Shell::Extensions::String:-: false
+#0:/opt/chef-workstation/embedded/lib/ruby/gems/2.6.0/gems/chef-15.8.23/lib/chef/shell/ext.rb:158:Shell::Extensions::String:<: end
+#0:/opt/chef-workstation/embedded/lib/ruby/gems/2.6.0/gems/chef-15.8.23/lib/chef/shell/ext.rb:164:Shell::Extensions::Symbol:<: end
+tracing is off
+=> nil
+chef >
+```
diff --git a/content/reusable/md/chef_shell_breakpoints.md b/content/reusable/md/chef_shell_breakpoints.md
new file mode 100644
index 0000000..1b631cd
--- /dev/null
+++ b/content/reusable/md/chef_shell_breakpoints.md
@@ -0,0 +1,3 @@
+chef-shell allows the current position in a run-list to be manipulated
+during a Chef Infra Client run. Add breakpoints to a recipe to take
+advantage of this functionality.
diff --git a/content/reusable/md/chef_shell_config.md b/content/reusable/md/chef_shell_config.md
new file mode 100644
index 0000000..e9cec0c
--- /dev/null
+++ b/content/reusable/md/chef_shell_config.md
@@ -0,0 +1,14 @@
+chef-shell determines which configuration file to load based on the
+following:
+
+1. If a configuration file is specified using the `-c` option,
+ chef-shell will use the specified configuration file
+1. If a NAMED_CONF is given, chef-shell will load
+ \~/.chef/NAMED_CONF/chef_shell.rb
+1. If no NAMED_CONF is given chef-shell will load
+ \~/.chef/chef_shell.rb if it exists
+1. If no chef_shell.rb can be found, chef-shell falls back to load:
+ - /etc/chef/client.rb if -z option is given.
+ - /etc/chef/solo.rb if --solo-legacy-mode option is given.
+ - .chef/config.rb if -s option is given.
+ - .chef/knife.rb if -s option is given.
diff --git a/content/reusable/md/chef_shell_config_rb.md b/content/reusable/md/chef_shell_config_rb.md
new file mode 100644
index 0000000..1875a22
--- /dev/null
+++ b/content/reusable/md/chef_shell_config_rb.md
@@ -0,0 +1,16 @@
+The chef-shell.rb file can be used to configure chef-shell in the same
+way as the client.rb file is used to configure Chef Infra Client. For
+example, to configure chef-shell to authenticate to the Chef Infra
+Server, copy the `node_name`, `client_key`, and `chef_server_url`
+settings from the config.rb file:
+
+```ruby
+node_name 'your-knife-clientname'
+client_key File.expand_path('~/.chef/my-client.pem')
+chef_server_url 'https://api.opscode.com/organizations/myorg'
+```
+
+and then add them to the chef-shell.rb file. Other configuration
+possibilities include disabling Ohai plugins (which will speed up the
+chef-shell boot process) or including arbitrary Ruby code in the
+chef-shell.rb file.
diff --git a/content/reusable/md/chef_shell_debug_existing_recipe.md b/content/reusable/md/chef_shell_debug_existing_recipe.md
new file mode 100644
index 0000000..4485d74
--- /dev/null
+++ b/content/reusable/md/chef_shell_debug_existing_recipe.md
@@ -0,0 +1,39 @@
+chef-shell can be used to debug existing recipes. The recipe first needs
+to be added to a run-list for the node, so that it's cached when
+starting chef-shell and then used for debugging. chef-shell will report
+which recipes are being cached when it's started:
+
+```bash
+loading configuration: none (standalone session)
+Session type: standalone
+Loading.............done.
+
+Welcome to the chef-shell 15.8.23
+For usage see https://docs.chef.io/chef_shell.html
+
+run `help' for help, `exit' or ^D to quit.
+
+chef (15.8.23)>
+```
+
+To just load one recipe from the run-list, go into the recipe and use
+the `include_recipe` command. For example:
+
+```bash
+chef > recipe_mode
+ chef:recipe > include_recipe "getting-started"
+ => [#< Chef::Recipe:0x10256f9e8 @cookbook_name="getting-started",
+ ... output truncated ...
+```
+
+To load all of the recipes from a run-list, use code similar to the
+following:
+
+```ruby
+node.run_list.expand(node.chef_environment).recipes.each do |r|
+ include_recipe r
+end
+```
+
+After the recipes that are to be debugged have been loaded, use the
+`run_chef` command to run them.
diff --git a/content/reusable/md/chef_shell_manage.md b/content/reusable/md/chef_shell_manage.md
new file mode 100644
index 0000000..1d47c24
--- /dev/null
+++ b/content/reusable/md/chef_shell_manage.md
@@ -0,0 +1,132 @@
+When chef-shell is configured to access a Chef Infra Server, chef-shell
+can list, show, search for and edit cookbooks, clients, nodes, roles,
+environments, policyfiles, and data bags.
+
+The syntax for managing objects on Chef Infra Server is as follows:
+
+```bash
+chef-shell -z named_configuration
+```
+
+Where:
+
+- `named_configuration` is an existing configuration file in
+ `~/.chef/named_configuration/chef_shell.rb`, such as `production`,
+ `staging`, or `test`.
+
+Once in chef-shell, commands can be run against objects as follows:
+
+```bash
+chef (preprod) > items.command
+```
+
+Where:
+
+- `items` is the type of item to search for: `cookbooks`, `clients`,
+ `nodes`, `roles`, `environments` or a data bag.
+- `command` is the command: `list`, `show`, `find`, or `edit`.
+
+For example, to list all of the nodes in a configuration named
+"preprod", enter:
+
+```bash
+chef (preprod) > nodes.list
+```
+
+Which will return something similar to:
+
+```bash
+=> [node[i-f09a939b], node[i-049a936f], node[i-eaaaa581], node[i-9154b1fb],
+ node[i-6a213101], node[i-c2687aa9], node[i-7abeaa11], node[i-4eb8ac25],
+ node[i-9a2030f1], node[i-a06875cb], node[i-145f457f], node[i-e032398b],
+ node[i-dc8c98b7], node[i-6afdf401], node[i-f49b119c], node[i-5abfab31],
+ node[i-78b8ac13], node[i-d99678b3], node[i-02322269], node[i-feb4a695],
+ node[i-9e2232f5], node[i-6e213105], node[i-cdde3ba7], node[i-e8bfb083],
+ node[i-743c2c1f], node[i-2eaca345], node[i-aa7f74c1], node[i-72fdf419],
+ node[i-140e1e7f], node[i-f9d43193], node[i-bd2dc8d7], node[i-8e7f70e5],
+ node[i-78f2e213], node[i-962232fd], node[i-4c322227], node[i-922232f9],
+ node[i-c02728ab], node[i-f06c7b9b]]
+```
+
+The `list` command can take a code block, which will applied (but not
+saved), to each object that's returned from the server. For example:
+
+```bash
+chef (preprod) > nodes.list {|n| puts "#{n.name}: #{n.run_list}" }
+```
+
+will return something similar to:
+
+```bash
+=> i-f09a939b: role[lb], role[preprod], recipe[aws]
+ i-049a936f: role[lb], role[preprod], recipe[aws]
+ i-9154b1fb: recipe[erlang], role[base], role[couchdb], role[preprod],
+ i-6a213101: role[chef], role[preprod]
+ # more...
+```
+
+The `show` command can be used to display a specific node. For example:
+
+```bash
+chef (preprod) > load_balancer = nodes.show('i-f09a939b')
+```
+
+will return something similar to:
+
+```bash
+=> node[i-f09a939b]
+```
+
+Or:
+
+```bash
+chef (preprod) > load_balancer.ec2.public_hostname
+```
+
+will return something similar to:
+
+```bash
+=> "ec2-111-22-333-44.compute-1.amazonaws.com"
+```
+
+The `find` command can be used to search Chef Infra Server from the
+chef-shell. For example:
+
+```bash
+chef (preprod) > pp nodes.find(:ec2_public_hostname => 'ec2*')
+```
+
+You can also format the results with a code block. For example:
+
+```bash
+chef (preprod) > pp nodes.find(:ec2_public_hostname => 'ec2*') {|n| n.ec2.ami_id } and nil
+```
+
+will return something similar to:
+
+```bash
+=> ["ami-f8927a91",
+ "ami-f8927a91",
+ "ami-a89870c1",
+ "ami-a89870c1",
+ "ami-a89870c1",
+ "ami-a89870c1",
+ "ami-a89870c1"
+ # and more...
+```
+
+Or:
+
+```bash
+chef (preprod) > amis = nodes.find(:ec2_public_hostname => 'ec2*') {|n| n.ec2.ami_id }
+chef (preprod) > puts amis.uniq.sort
+```
+
+will return something similar to:
+
+```bash
+=> ami-4b4ba522
+ ami-a89870c1
+ ami-eef61587
+ ami-f8927a91
+```
diff --git a/content/reusable/md/chef_shell_modes.md b/content/reusable/md/chef_shell_modes.md
new file mode 100644
index 0000000..a2e8f9e
--- /dev/null
+++ b/content/reusable/md/chef_shell_modes.md
@@ -0,0 +1,30 @@
+chef-shell is tool that's run using an Interactive Ruby (IRb) session.
+chef-shell currently supports recipe and attribute file syntax, as well
+as interactive debugging features. chef-shell has three run modes:
+
+
+
+
+
+
+
+
+
Mode
+
Description
+
+
+
+
+
Standalone
+
Default. No cookbooks are loaded, and the run-list is empty.
+
+
+
Solo
+
chef-shell acts as a Chef Solo Client. It attempts to load the chef-solo configuration file at ~/.chef/config.rb and any JSON attributes passed. If the JSON attributes set a run-list, it will be honored. Cookbooks will be loaded in the same way that chef-solo loads them. chef-solo mode is activated with the -s or --solo command line option, and JSON attributes are specified in the same way as for chef-solo, with -j /path/to/chef-solo.json.
+
+
+
Client
+
chef-shell acts as a Chef Infra Client. During startup, it reads the Chef Infra Client configuration file from ~/.chef/client.rb and contacts Chef Infra Server to get the node's run_list, attributes, and cookbooks. Chef Infra Client mode is activated with the -z or --client options. You can also specify the configuration file with -c CONFIG and the server URL with -S SERVER_URL.
+
+
+
diff --git a/content/reusable/md/chef_shell_run_as_chef_client.md b/content/reusable/md/chef_shell_run_as_chef_client.md
new file mode 100644
index 0000000..239c656
--- /dev/null
+++ b/content/reusable/md/chef_shell_run_as_chef_client.md
@@ -0,0 +1,14 @@
+By default, chef-shell loads in standalone mode and doesn't connect to
+Chef Infra Server. The chef-shell can be run as a Chef Infra Client
+to verify functionality that's only available when Chef Infra Client
+connects to Chef Infra Server, such as search functionality or
+accessing data stored in data bags.
+
+chef-shell can use the same credentials as knife when connecting to a
+Chef Infra Server. Make sure that the settings in chef-shell.rb are the
+same as those in config.rb, and then use the `-z` option as part of the
+command. For example:
+
+```bash
+chef-shell -z
+```
diff --git a/content/reusable/md/chef_shell_step_through_run_list.md b/content/reusable/md/chef_shell_step_through_run_list.md
new file mode 100644
index 0000000..4cc6e31
--- /dev/null
+++ b/content/reusable/md/chef_shell_step_through_run_list.md
@@ -0,0 +1,89 @@
+To explore how using the **breakpoint** to manually step through a Chef
+Infra Client run, create a simple recipe in chef-shell:
+
+```bash
+chef > recipe_mode
+ chef:recipe > echo off
+ chef:recipe > file "/tmp/before-breakpoint"
+ chef:recipe > breakpoint "foo"
+ chef:recipe > file "/tmp/after-breakpoint"
+```
+
+and then run Chef Infra Client:
+
+```bash
+chef:recipe > run_chef
+ [Fri, 15 Jan 2020 14:17:49 -0800] DEBUG: Processing file[/tmp/before-breakpoint]
+ [Fri, 15 Jan 2020 14:17:49 -0800] DEBUG: file[/tmp/before-breakpoint] using Chef::Provider::File
+ [Fri, 15 Jan 2020 14:17:49 -0800] INFO: Creating file[/tmp/before-breakpoint] at /tmp/before-breakpoint
+ [Fri, 15 Jan 2020 14:17:49 -0800] DEBUG: Processing [./bin/../lib/chef/mixin/recipe_definition_dsl_core.rb:56:in 'new']
+ [Fri, 15 Jan 2020 14:17:49 -0800] DEBUG: [./bin/../lib/chef/mixin/recipe_definition_dsl_core.rb:56:in 'new'] using Chef::Provider::Breakpoint
+```
+
+Chef Infra Client ran the first resource before the breakpoint
+(`file[/tmp/before-breakpoint]`), but then stopped after execution. Chef
+Infra Client attempted to name the breakpoint after its position in the
+source file, but Chef Infra Client was confused because the resource was
+entered interactively. From here, chef-shell can resume the interrupted
+Chef Infra Client run:
+
+```bash
+chef:recipe > chef_run.resume
+ [Fri, 15 Jan 2020 14:27:08 -0800] INFO: Creating file[/tmp/after-breakpoint] at /tmp/after-breakpoint
+```
+
+A quick view of the `/tmp` directory shows that the following files were
+created:
+
+```bash
+after-breakpoint
+before-breakpoint
+```
+
+You can rewind and step through a Chef Infra Client run:
+
+```bash
+chef:recipe > Chef::Log.level = :debug # debug logging won't turn on automatically in this case
+ => :debug
+ chef:recipe > chef_run.rewind
+ => 0
+ chef:recipe > chef_run.step
+ [Fri, 15 Jan 2020 14:40:52 -0800] DEBUG: Processing file[/tmp/before-breakpoint]
+ [Fri, 15 Jan 2020 14:40:52 -0800] DEBUG: file[/tmp/before-breakpoint] using Chef::Provider::File
+ => 1
+ chef:recipe > chef_run.step
+ [Fri, 15 Jan 2020 14:40:54 -0800] DEBUG: Processing [./bin/../lib/chef/mixin/recipe_definition_dsl_core.rb:56:in 'new']
+ [Fri, 15 Jan 2020 14:40:54 -0800] DEBUG: [./bin/../lib/chef/mixin/recipe_definition_dsl_core.rb:56:in 'new'] using Chef::Provider::Breakpoint
+ => 2
+ chef:recipe > chef_run.step
+ [Fri, 15 Jan 2020 14:40:56 -0800] DEBUG: Processing file[/tmp/after-breakpoint]
+ [Fri, 15 Jan 2020 14:40:56 -0800] DEBUG: file[/tmp/after-breakpoint] using Chef::Provider::File
+ => 3
+```
+
+From the output, the rewound run-list is shown, but when the resources
+are executed again, they will repeat their checks for the existence of
+files. If they exist, Chef Infra Client will skip creating them. If the
+files are deleted, then:
+
+```bash
+chef:recipe > ls("/tmp").grep(/breakpoint/).each {|f| rm "/tmp/#{f}" }
+ => ["after-breakpoint", "before-breakpoint"]
+```
+
+Rewind, and then resume your Chef Infra Client run to get the expected
+results:
+
+```bash
+chef:recipe > chef_run.rewind
+ chef:recipe > chef_run.resume
+ [Fri, 15 Jan 2020 14:48:56 -0800] DEBUG: Processing file[/tmp/before-breakpoint]
+ [Fri, 15 Jan 2020 14:48:56 -0800] DEBUG: file[/tmp/before-breakpoint] using Chef::Provider::File
+ [Fri, 15 Jan 2020 14:48:56 -0800] INFO: Creating file[/tmp/before-breakpoint] at /tmp/before-breakpoint
+ [Fri, 15 Jan 2020 14:48:56 -0800] DEBUG: Processing [./bin/../lib/chef/mixin/recipe_definition_dsl_core.rb:56:in 'new']
+ [Fri, 15 Jan 2020 14:48:56 -0800] DEBUG: [./bin/../lib/chef/mixin/recipe_definition_dsl_core.rb:56:in 'new'] using Chef::Provider::Breakpoint
+ chef:recipe > chef_run.resume
+ [Fri, 15 Jan 2020 14:49:20 -0800] DEBUG: Processing file[/tmp/after-breakpoint]
+ [Fri, 15 Jan 2020 14:49:20 -0800] DEBUG: file[/tmp/after-breakpoint] using Chef::Provider::File
+ [Fri, 15 Jan 2020 14:49:20 -0800] INFO: Creating file[/tmp/after-breakpoint] at /tmp/after-breakpoint
+```
diff --git a/content/reusable/md/chef_shell_summary.md b/content/reusable/md/chef_shell_summary.md
new file mode 100644
index 0000000..6f17c25
--- /dev/null
+++ b/content/reusable/md/chef_shell_summary.md
@@ -0,0 +1,4 @@
+chef-shell is a recipe debugging tool that allows the use of breakpoints
+within recipes. chef-shell runs as an Interactive Ruby (IRb) session.
+chef-shell supports both recipe and attribute file syntax, as well as
+interactive debugging features.
diff --git a/content/reusable/md/chef_solo_environments.md b/content/reusable/md/chef_solo_environments.md
new file mode 100644
index 0000000..a31263c
--- /dev/null
+++ b/content/reusable/md/chef_solo_environments.md
@@ -0,0 +1,40 @@
+An environment is defined using JSON or the Ruby DSL. chef-solo will
+look for environments in `/var/chef/environments`, but this location can
+be modified by changing the setting for `environment_path` in solo.rb.
+For example, the following setting in solo.rb:
+
+```ruby
+environment_path '/var/chef-solo/environments'
+```
+
+Environment data looks like the following in JSON:
+
+```json
+{
+ "name": "dev",
+ "default_attributes": {
+ "apache2": {
+ "listen_ports": [
+ "80",
+ "443"
+ ]
+ }
+ },
+ "json_class": "Chef::Environment",
+ "description": "",
+ "cookbook_versions": {
+ "couchdb": "= 11.0.0"
+ },
+ "chef_type": "environment"
+ }
+```
+
+and like the following in the Ruby DSL:
+
+```ruby
+name 'environment_name'
+description 'environment_description'
+cookbook OR cookbook_versions 'cookbook' OR 'cookbook' => 'cookbook_version'
+default_attributes 'node' => { 'attribute' => %w(value value etc.) }
+override_attributes 'node' => { 'attribute' => %w(value value etc.) }
+```
diff --git a/content/reusable/md/chef_solo_summary.md b/content/reusable/md/chef_solo_summary.md
new file mode 100644
index 0000000..62d82be
--- /dev/null
+++ b/content/reusable/md/chef_solo_summary.md
@@ -0,0 +1,24 @@
+chef-solo is a command that executes Chef Infra Client in a way that
+doesn't require Chef Infra Server to converge cookbooks.
+chef-solo uses Chef Infra Client's [Chef local
+mode](/ctl_chef_client.html#run-in-local-mode), and **doesn't support**
+the following functionality present in Chef Infra Client / server
+configurations:
+
+- Centralized distribution of cookbooks
+- A centralized API that interacts with and integrates infrastructure
+ components
+- Authentication or authorization
+
+
+
+
+
Note
+
+
+chef-solo can be run as a daemon.
+
+
+
+
+The chef-solo executable is run as a command-line tool.
diff --git a/content/reusable/md/chef_tags.md b/content/reusable/md/chef_tags.md
new file mode 100644
index 0000000..7e93a43
--- /dev/null
+++ b/content/reusable/md/chef_tags.md
@@ -0,0 +1,2 @@
+A tag is a custom description that's applied to a node.
+A tag, once applied, can be helpful when managing nodes using knife or when building recipes by providing alternate methods of grouping similar types of information.
diff --git a/content/reusable/md/config_rb_client_dot_d_directories.md b/content/reusable/md/config_rb_client_dot_d_directories.md
new file mode 100644
index 0000000..29f568e
--- /dev/null
+++ b/content/reusable/md/config_rb_client_dot_d_directories.md
@@ -0,0 +1,25 @@
+You can use multiple configuration files by putting them in `.d` configuration directories,
+for example `/etc/chef/client.d`.
+
+To use a `.d` directory, create a directory with the same name as the configuration file but replace the `.rb` suffix with `.d`.
+
+The default locations for `.d` directories in Chef Infra are:
+
+- For Chef Infra Client, use `/etc/chef/client.d`.
+- For Chef development tooling such as knife, use `~/.chef/config.d`.
+- For Chef Solo, use `/etc/chef/solo.d`.
+
+The standard `.rb` configuration file and all configuration `.rb` files in the `.d` directory are merged as one file.
+For example, knife would load and merge the following files:
+
+- `~/.chef/config.rb`
+- `~/.chef/config.d/company_settings.rb`
+- `~/.chef/config.d/ec2_configuration.rb`
+
+Non-`.rb` files in a `.d` directory are ignored, for example `old_settings.rb.bak`.
+
+{{< note >}}
+
+If you have the same setting in multiple configuration files, ensure that it has the same value in all files.
+
+{{< /note >}}
diff --git a/content/reusable/md/config_rb_client_summary.md b/content/reusable/md/config_rb_client_summary.md
new file mode 100644
index 0000000..a74f955
--- /dev/null
+++ b/content/reusable/md/config_rb_client_summary.md
@@ -0,0 +1,9 @@
+The `client.rb` file configures Chef Infra Client on a node and has the following characteristics:
+
+- This file is loaded every time the `chef-client` executable is run.
+- On Windows machines, the default location for this file is
+ `C:\chef\client.rb`. On all other systems the default location for
+ this file is `/etc/chef/client.rb`.
+- Use the `--config` option from the command line to override the
+ default location of the configuration file.
+- This file isn't created by default
diff --git a/content/reusable/md/config_rb_ohai.md b/content/reusable/md/config_rb_ohai.md
new file mode 100644
index 0000000..fde65b8
--- /dev/null
+++ b/content/reusable/md/config_rb_ohai.md
@@ -0,0 +1 @@
+Ohai configuration settings can be added to the client.rb file.
diff --git a/content/reusable/md/config_rb_ohai_settings.md b/content/reusable/md/config_rb_ohai_settings.md
new file mode 100644
index 0000000..05e2cca
--- /dev/null
+++ b/content/reusable/md/config_rb_ohai_settings.md
@@ -0,0 +1,76 @@
+`ohai.directory`
+
+: The directory in which Ohai plugins are located.
+
+`ohai.disabled_plugins`
+
+: An array of Ohai plugins to be disabled on a node. The list of
+ plugins included in Ohai can be found in the [ohai/lib/ohai/plugins](https://github.com/chef/ohai/tree/main/lib/ohai/plugins)
+ source. For example, disabling a single plugin:
+
+ ```ruby
+ ohai.disabled_plugins = [
+ :MyPlugin
+ ]
+ ```
+
+ or disabling multiple plugins:
+
+ ```ruby
+ ohai.disabled_plugins = [
+ :MyPlugin,
+ :MyPlugin2,
+ :MyPlugin3
+ ]
+ ```
+
+ When a plugin is disabled, the Chef Infra Client log file will
+ contain entries similar to:
+
+ ```ruby
+ [2014-06-13T23:49:12+00:00] DEBUG: Skipping disabled plugin MyPlugin
+ ```
+
+`ohai.hints_path`
+
+: The path to the file that contains hints for Ohai.
+
+`ohai.log_level`
+
+: The level of logging to be stored in a log file.
+
+`ohai.log_location`
+
+: The location of the log file.
+
+`ohai.plugin_path`
+
+: An array of paths at which Ohai plugins are located. Default value:
+ `[/ohai-9.9.9/lib/ohai/plugins]`. When custom Ohai
+ plugins are added, the paths must be added to the array. For
+ example, a single plugin:
+
+ ```ruby
+ ohai.plugin_path << '/etc/chef/ohai_plugins'
+ ```
+
+ and for multiple plugins:
+
+ ```ruby
+ ohai.plugin_path += [
+ '/etc/chef/ohai_plugins',
+ '/path/to/other/plugins'
+ ]
+ ```
+
+
+
+
+
Note
+
+
+The Ohai executable ignores settings in the client.rb file when Ohai is
+run independently of Chef Infra Client.
+
+
+
diff --git a/content/reusable/md/cookbooks_attribute.md b/content/reusable/md/cookbooks_attribute.md
new file mode 100644
index 0000000..1151a6e
--- /dev/null
+++ b/content/reusable/md/cookbooks_attribute.md
@@ -0,0 +1,10 @@
+An attribute can be defined in a cookbook (or a recipe) and then used to
+override the default settings on a node. When a cookbook is loaded
+during a Chef Infra Client run, these attributes are compared to the
+attributes that are already present on the node. Attributes that are
+defined in attribute files are first loaded according to cookbook order.
+For each cookbook, attributes in the `default.rb` file are loaded first,
+and then additional attribute files (if present) are loaded in lexical
+sort order. When the cookbook attributes take precedence over the
+default attributes, Chef Infra Client applies those new settings and
+values during a Chef Infra Client run on the node.
diff --git a/content/reusable/md/cookbooks_metadata.md b/content/reusable/md/cookbooks_metadata.md
new file mode 100644
index 0000000..6c06a3e
--- /dev/null
+++ b/content/reusable/md/cookbooks_metadata.md
@@ -0,0 +1,9 @@
+Every cookbook requires a small amount of metadata.
+The contents of the `metadata.rb` file provides information that helps Chef Infra Client and Server correctly deploy cookbooks to each node.
+
+A `metadata.rb` file is:
+
+- Located at the top level of a cookbook's directory structure.
+- Compiled whenever a cookbook is uploaded to Chef Infra Server or when the `knife cookbook metadata` subcommand is run, and then stored as JSON data.
+- Created automatically by knife whenever the `knife cookbook create` subcommand is run.
+- Edited using a text editor, and then re-uploaded to Chef Infra Server as part of a cookbook upload.
diff --git a/content/reusable/md/cookbooks_recipe.md b/content/reusable/md/cookbooks_recipe.md
new file mode 100644
index 0000000..02304ee
--- /dev/null
+++ b/content/reusable/md/cookbooks_recipe.md
@@ -0,0 +1,12 @@
+A recipe is the most fundamental configuration element within the
+organization. A recipe:
+
+- Is authored using Ruby, which is a programming language designed to read and behave in a predictable manner
+- Is mostly a collection of [resources](/resources/), defined using patterns (resource names, attribute-value pairs, and actions); helper code is added around this using Ruby, when needed
+- Must define everything that's required to configure part of a system
+- Must be stored in a cookbook
+- May be included in another recipe
+- May use the results of a search query and read the contents of a data bag (including an encrypted data bag)
+- May have a dependency on one (or more) recipes
+- Must be added to a run-list before it can be used by Chef Infra Client
+- Is always executed in the same order as listed in a run-list
diff --git a/content/reusable/md/cookbooks_recipe_include_in_recipe.md b/content/reusable/md/cookbooks_recipe_include_in_recipe.md
new file mode 100644
index 0000000..ea309c1
--- /dev/null
+++ b/content/reusable/md/cookbooks_recipe_include_in_recipe.md
@@ -0,0 +1,28 @@
+A recipe can include one (or more) recipes from cookbooks by using the
+`include_recipe` method. When a recipe is included, the resources found
+in that recipe will be inserted (in the same exact order) at the point
+where the `include_recipe` keyword is located.
+
+The syntax for including a recipe is like this:
+
+```ruby
+include_recipe 'recipe'
+```
+
+For example:
+
+```ruby
+include_recipe 'apache2::mod_ssl'
+```
+
+Multiple recipes can be included within a recipe. For example:
+
+```ruby
+include_recipe 'cookbook::setup'
+include_recipe 'cookbook::install'
+include_recipe 'cookbook::configure'
+```
+
+If a specific recipe is included more than once with the
+`include_recipe` method or elsewhere in the run_list directly, only the
+first instance is processed and subsequent inclusions are ignored.
diff --git a/content/reusable/md/cookbooks_recipe_tags.md b/content/reusable/md/cookbooks_recipe_tags.md
new file mode 100644
index 0000000..62955f3
--- /dev/null
+++ b/content/reusable/md/cookbooks_recipe_tags.md
@@ -0,0 +1,46 @@
+You can add tags, remove tags, and check if nodes have a specific tag.
+
+To add a tag in your recipe, use `tag` with the tag name you want to apply to a node.
+
+```ruby
+tag('tag-name')
+```
+
+To test if a machine is tagged with a specific tag, use `tagged?` with the tag name.
+
+```ruby
+tagged?('tag-name')
+```
+
+This will return `true` or `false`.
+
+`tagged?` also accepts an array as an argument.
+
+Remove a tag using `untag`.
+
+```ruby
+untag('tag-name')
+```
+
+For example:
+
+```ruby
+tag('test_node')
+
+if tagged?('test_node')
+ Chef::Log.info("Hey I'm #{node['tags']}")
+end
+
+untag('test_node')
+
+unless tagged?('test_node')
+ Chef::Log.info('I am not tagged')
+end
+```
+
+Will return something like this:
+
+```plain
+[Thu, 22 Jul 2010 18:01:45 +0000] INFO: Hey I'm test_node
+[Thu, 22 Jul 2010 18:01:45 +0000] INFO: I am not tagged
+```
diff --git a/content/reusable/md/cookbooks_summary.md b/content/reusable/md/cookbooks_summary.md
new file mode 100644
index 0000000..985690f
--- /dev/null
+++ b/content/reusable/md/cookbooks_summary.md
@@ -0,0 +1,10 @@
+A cookbook is the fundamental unit of configuration and policy distribution in Chef Infra.
+
+A cookbook defines a scenario and contains everything that's required to support that scenario:
+
+- Recipes that specify which Chef Infra built-in resources to use, as well as the order in which they're to be applied
+- Attribute values, which allow environment-based configurations such as `dev` or `production`.
+- Custom Resources for extending Chef Infra beyond the built-in resources.
+- Files and Templates for distributing information to systems.
+- Custom Ohai Plugins for extending system configuration collection beyond the Ohai defaults.
+- The `metadata.rb` file, which describes the cookbook itself and any dependencies it may have.
diff --git a/content/reusable/md/cookbooks_version.md b/content/reusable/md/cookbooks_version.md
new file mode 100644
index 0000000..0099840
--- /dev/null
+++ b/content/reusable/md/cookbooks_version.md
@@ -0,0 +1,11 @@
+A cookbook version represents a set of functionality that's different
+from the cookbook on which it's based. A version may exist for many
+reasons, such as ensuring the correct use of a third-party component,
+updating a bug fix, or adding an improvement. A cookbook version is
+defined using syntax and operators, may be associated with environments,
+cookbook metadata, and/or run-lists, and may be frozen (to prevent
+unwanted updates from being made).
+
+A cookbook version is maintained just like a cookbook, with regard to
+source control, uploading it to Chef Infra Server, and how Chef
+Infra Client applies that cookbook when configuring nodes.
diff --git a/content/reusable/md/cookbooks_version_constraints_operators.md b/content/reusable/md/cookbooks_version_constraints_operators.md
new file mode 100644
index 0000000..6134d36
--- /dev/null
+++ b/content/reusable/md/cookbooks_version_constraints_operators.md
@@ -0,0 +1,40 @@
+The following operators may be used:
+
+
+
+
+
+
+
+
+
Operator
+
Description
+
+
+
+
+
=
+
equal to
+
+
+
>
+
greater than
+
+
+
<
+
less than
+
+
+
>=
+
greater than or equal to; also known as "optimistically greater than", or "optimistic"
+
+
+
<=
+
less than or equal to
+
+
+
~>
+
approximately greater than; also known as "pessimistically greater than", or "pessimistic"
+
+
+
diff --git a/content/reusable/md/data_bag.md b/content/reusable/md/data_bag.md
new file mode 100644
index 0000000..e867a60
--- /dev/null
+++ b/content/reusable/md/data_bag.md
@@ -0,0 +1,2 @@
+Data bags store global variables as JSON data. Data bags are indexed for
+searching and can be loaded by a cookbook or accessed during a search.
diff --git a/content/reusable/md/data_bag_encryption.md b/content/reusable/md/data_bag_encryption.md
new file mode 100644
index 0000000..3655efd
--- /dev/null
+++ b/content/reusable/md/data_bag_encryption.md
@@ -0,0 +1,21 @@
+A data bag item may be encrypted using [shared secret
+encryption](https://en.wikipedia.org/wiki/Symmetric-key_algorithm). This
+allows each data bag item to store confidential information (such as a
+database password) or to be managed in a source control system (without
+plain-text data appearing in revision history). Each data bag item may
+be encrypted individually; if a data bag contains multiple encrypted
+data bag items, these data bag items aren't required to share the same
+encryption keys.
+
+
+
+
+
Note
+
+
+Because the contents of encrypted data bag items aren't visible to the
+Chef Infra Server, search queries against data bags with encrypted items
+won't return any results.
+
+
+
diff --git a/content/reusable/md/data_bag_encryption_secret_key.md b/content/reusable/md/data_bag_encryption_secret_key.md
new file mode 100644
index 0000000..21596a5
--- /dev/null
+++ b/content/reusable/md/data_bag_encryption_secret_key.md
@@ -0,0 +1,19 @@
+Encrypting a data bag item requires a secret key. A secret key can be
+created in any number of ways. For example, OpenSSL can be used to
+generate a random number, which can then be used as the secret key:
+
+```bash
+openssl rand -base64 512 | tr -d '\r\n' > encrypted_data_bag_secret
+```
+
+where `encrypted_data_bag_secret` is the name of the file which will
+contain the secret key. For example, to create a secret key named
+"my_secret_key":
+
+```bash
+openssl rand -base64 512 | tr -d '\r\n' > my_secret_key
+```
+
+The `tr` command eliminates any trailing line feeds. Doing so avoids key
+corruption when transferring the file between platforms with different
+line endings.
diff --git a/content/reusable/md/data_bag_item.md b/content/reusable/md/data_bag_item.md
new file mode 100644
index 0000000..12d4e36
--- /dev/null
+++ b/content/reusable/md/data_bag_item.md
@@ -0,0 +1,21 @@
+A data bag is a container of related data bag items, where each
+individual data bag item is a JSON file. knife can load a data bag item
+by specifying the name of the data bag to which the item belongs and
+then the filename of the data bag item. The only structural requirement
+of a data bag item is that it must have an `id`:
+
+```json
+{
+ /* This is a supported comment style */
+ // This style is also supported
+ "id": "ITEM_NAME",
+ "key": "value"
+}
+```
+
+where
+
+- `key` and `value` are the `key:value` pair for each additional
+ attribute within the data bag item
+- `/* ... */` and `// ...` show two ways to add comments to the data
+ bag item
diff --git a/content/reusable/md/dsl_handler_event_types.md b/content/reusable/md/dsl_handler_event_types.md
new file mode 100644
index 0000000..e6db7bb
--- /dev/null
+++ b/content/reusable/md/dsl_handler_event_types.md
@@ -0,0 +1,355 @@
+The following table describes the events that may occur during a Chef
+Infra Client run. Each of these events may be referenced in an `on`
+method block by declaring it as the event type.
+
+`:run_start`
+
+: The start of a Chef Infra Client run.
+
+`:run_started`
+
+: The Chef Infra Client run has started.
+
+`:run_completed`
+
+: The Chef Infra Client run has completed.
+
+`:run_failed`
+
+: The Chef Infra Client run has failed.
+
+`:ohai_completed`
+
+: The Ohai run has completed.
+
+`:skipping_registration`
+
+: The Chef Infra Client isn't registering with Chef Infra Server because it already has a private key or because it doesn't need one.
+
+`:registration_start`
+
+: The Chef Infra Client is attempting to create a private key with which to register to Chef Infra Server.
+
+`:registration_completed`
+
+: The Chef Infra Client created its private key successfully.
+
+`:registration_failed`
+
+: The Chef Infra Client encountered an error and was unable to register with Chef Infra Server.
+
+`:node_load_start`
+
+: The Chef Infra Client is attempting to load node data from Chef Infra Server.
+
+`:node_load_success`
+
+: The Chef Infra Client successfully loaded node data from the policy builder.
+
+`:node_load_failed`
+
+: The Chef Infra Client encountered an error and was unable to load node data from Chef Infra Server.
+
+`:run_list_expand_failed`
+
+: The Chef Infra Client failed to expand the run-list.
+
+`:node_load_completed`
+
+: The Chef Infra Client successfully loaded node data from Chef Infra Server. Default and override attributes for roles have been computed, but aren't yet applied.
+
+`:policyfile_loaded`
+
+: The Policyfile was loaded.
+
+`:cookbook_resolution_start`
+
+: The Chef Infra Client is attempting to pull down the cookbook collection from Chef Infra Server.
+
+`:cookbook_resolution_failed`
+
+: The Chef Infra Client failed to pull down the cookbook collection from Chef Infra Server.
+
+`:cookbook_resolution_complete`
+
+: The Chef Infra Client successfully pulled down the cookbook collection from Chef Infra Server.
+
+`:cookbook_clean_start`
+
+: The Chef Infra Client is attempting to remove unneeded cookbooks.
+
+`:removed_cookbook_file`
+
+: The Chef Infra Client removed a file from a cookbook.
+
+`:cookbook_clean_complete`
+
+: The Chef Infra Client is done removing cookbooks and/or cookbook files.
+
+`:cookbook_sync_start`
+
+: The Chef Infra Client is attempting to synchronize cookbooks.
+
+`:synchronized_cookbook`
+
+: The Chef Infra Client is attempting to synchronize the named cookbook.
+
+`:updated_cookbook_file`
+
+: The Chef Infra Client updated the named file in the named cookbook.
+
+`:cookbook_sync_failed`
+
+: The Chef Infra Client was unable to synchronize cookbooks.
+
+`:cookbook_sync_complete`
+
+: The Chef Infra Client is finished synchronizing cookbooks.
+
+`:cookbook_gem_start`
+
+: The Chef Infra Client is collecting gems from the cookbooks.
+
+`:cookbook_gem_installing`
+
+: The Chef Infra Client is installing a cookbook gem.
+
+`:cookbook_gem_using`
+
+: The Chef Infra Client is using a cookbook gem.
+
+`:cookbook_gem_finished`
+
+: The Chef Infra Client finished installing cookbook gems.
+
+`:cookbook_gem_failed`
+
+: The Chef Infra Client failed to install cookbook gems.
+
+`:cookbook_compilation_start`
+
+: The Chef Infra Client created the run\_context and is starting cookbook compilation.
+
+`:library_load_start`
+
+: The Chef Infra Client is loading library files.
+
+`:library_file_loaded`
+
+: The Chef Infra Client successfully loaded the named library file.
+
+`:library_file_load_failed`
+
+: The Chef Infra Client was unable to load the named library file.
+
+`:library_load_complete`
+
+: The Chef Infra Client is finished loading library files.
+
+`:lwrp_load_start`
+
+: The Chef Infra Client is loading custom resources.
+
+`:lwrp_file_loaded`
+
+: The Chef Infra Client successfully loaded the named custom resource.
+
+`:lwrp_file_load_failed`
+
+: The Chef Infra Client was unable to load the named custom resource.
+
+`:lwrp_load_complete`
+
+: The Chef Infra Client is finished loading custom resources.
+
+`:ohai_plugin_load_start`
+
+: Ohai has started loading plugins.
+
+`:ohai_plugin_file_loaded`
+
+: Ohai has loaded a plugin.
+
+`:ohai_plugin_file_load_failed`
+
+: Ohai failed to load a plugin.
+
+`:ohai_plugin_load_complete`
+
+: Ohai has completed loading plugins.
+
+`:attribute_load_start`
+
+: The Chef Infra Client is loading attribute files.
+
+`:attribute_file_loaded`
+
+: The Chef Infra Client successfully loaded the named attribute file.
+
+`:attribute_file_load_failed`
+
+: The Chef Infra Client was unable to load the named attribute file.
+
+`:attribute_load_complete`
+
+: The Chef Infra Client is finished loading attribute files.
+
+`:definition_load_start`
+
+: The Chef Infra Client is loading definitions.
+
+`:definition_file_loaded`
+
+: The Chef Infra Client successfully loaded the named definition.
+
+`:definition_file_load_failed`
+
+: The Chef Infra Client was unable to load the named definition.
+
+`:definition_load_complete`
+
+: The Chef Infra Client is finished loading definitions.
+
+`:recipe_load_start`
+
+: The Chef Infra Client is loading recipes.
+
+`:recipe_file_loaded`
+
+: The Chef Infra Client successfully loaded the named recipe.
+
+`:recipe_file_load_failed`
+
+: The Chef Infra Client was unable to load the named recipe.
+
+`:recipe_not_found`
+
+: The Chef Infra Client was unable to find the named recipe.
+
+`:recipe_load_complete`
+
+: The Chef Infra Client is finished loading recipes.
+
+`:cookbook_compilation_complete`
+
+: The Chef Infra Client completed all cookbook compilation phases.
+
+`:converge_start`
+
+: The Chef Infra Client run converge phase has started.
+
+`:action_collection_registration`
+
+: Provides a reference to the action\_collection before cookbooks are compiled.
+
+`:converge_complete`
+
+: The Chef Infra Client run converge phase is complete.
+
+`:converge_failed`
+
+: The Chef Infra Client run converge phase has failed.
+
+`:control_group_started`
+
+: The named control group is being processed.
+
+`:control_example_success`
+
+: The named control group has been processed.
+
+`:control_example_failure`
+
+: The named control group's processing has failed.
+
+`:resource_action_start`
+
+: A resource action is starting.
+
+`:resource_skipped`
+
+: A resource action was skipped.
+
+`:resource_current_state_loaded`
+
+: A resource's current state was loaded.
+
+`:resource_after_state_loaded`
+
+: A resource's after state was loaded.
+
+`:resource_current_state_load_bypassed`
+
+: A resource's current state wasn't loaded because the resource doesn't support why-run mode.
+
+`:resource_bypassed`
+
+: A resource action was skipped because the resource doesn't support why-run mode.
+
+`:resource_update_applied`
+
+: A change has been made to a resource. (This event occurs for each change made to a resource.)
+
+`:resource_update_progress`
+
+: A resource sent a progress notification to the user to indicate overall progress of a long running operation.
+
+`:resource_failed_retriable`
+
+: A resource action has failed and will be retried.
+
+`:resource_failed`
+
+: A resource action has failed and won't be retried.
+
+`:resource_updated`
+
+: A resource requires modification.
+
+`:resource_up_to_date`
+
+: A resource is already correct.
+
+`:resource_completed`
+
+: All actions for the resource are complete.
+
+`:stream_opened`
+
+: A stream has opened.
+
+`:stream_closed`
+
+: A stream has closed.
+
+`:stream_output`
+
+: A chunk of data from a single named stream.
+
+`:handlers_start`
+
+: The handler processing phase of a Chef Infra Client run has started.
+
+`:handler_executed`
+
+: The named handler was processed.
+
+`:handlers_completed`
+
+: The handler processing phase of a Chef Infra Client run is complete.
+
+`:provider_requirement_failed`
+
+: An assertion declared by a provider has failed.
+
+`:whyrun_assumption`
+
+: An assertion declared by a provider has failed, but execution is allowed to continue because the Chef Infra Client is running in why-run mode.
+
+`:deprecation`
+
+: A deprecation message has been emitted.
+
+`:attribute_changed`
+
+: Prints out all the attribute changes in cookbooks or sets a policy that override attributes should never be used.
diff --git a/content/reusable/md/dsl_handler_example_etcd_lock.md b/content/reusable/md/dsl_handler_example_etcd_lock.md
new file mode 100644
index 0000000..ac7749b
--- /dev/null
+++ b/content/reusable/md/dsl_handler_example_etcd_lock.md
@@ -0,0 +1,18 @@
+The following example shows how to prevent concurrent Chef Infra Client
+runs from both holding a lock on etcd:
+
+```ruby
+lock_key = "#{node.chef_environment}/#{node.name}"
+
+Chef.event_handler do
+ on :converge_start do |run_context|
+ Etcd.lock_acquire(lock_key)
+ end
+end
+
+Chef.event_handler do
+ on :converge_complete do
+ Etcd.lock_release(lock_key)
+ end
+end
+```
diff --git a/content/reusable/md/dsl_handler_example_hipchat.md b/content/reusable/md/dsl_handler_example_hipchat.md
new file mode 100644
index 0000000..31a5bb3
--- /dev/null
+++ b/content/reusable/md/dsl_handler_example_hipchat.md
@@ -0,0 +1,22 @@
+Event messages can be sent to a team communication tool like HipChat.
+For example, if a Chef Infra Client run fails:
+
+```ruby
+Chef.event_handler do
+ on :run_failed do |exception|
+ hipchat_notify exception.message
+ end
+end
+```
+
+or send an alert on a configuration change:
+
+```ruby
+Chef.event_handler do
+ on :resource_updated do |resource, action|
+ if resource.to_s == 'template[/etc/nginx/nginx.conf]'
+ Helper.hipchat_message("#{resource} was updated by chef")
+ end
+ end
+end
+```
diff --git a/content/reusable/md/dsl_handler_method_on.md b/content/reusable/md/dsl_handler_method_on.md
new file mode 100644
index 0000000..04643a3
--- /dev/null
+++ b/content/reusable/md/dsl_handler_method_on.md
@@ -0,0 +1,33 @@
+Use the `on` method to associate an event type with a callback. The
+callback defines what steps are taken if the event occurs during a Chef
+Infra Client run and is defined using arbitrary Ruby code. The syntax is
+as follows:
+
+```ruby
+Chef.event_handler do
+ on :event_type do
+ # some Ruby
+ end
+end
+```
+
+where
+
+- `Chef.event_handler` declares a block of code within a recipe that
+ is processed when the named event occurs during a Chef Infra Client
+ run
+- `on` defines the block of code that will tell Chef Infra Client how
+ to handle the event
+- `:event_type` is a valid exception event type, such as `:run_start`,
+ `:run_failed`, `:converge_failed`, `:resource_failed`, or
+ `:recipe_not_found`
+
+For example:
+
+```bash
+Chef.event_handler do
+ on :converge_start do
+ puts "Ohai! I have started a converge."
+ end
+end
+```
diff --git a/content/reusable/md/dsl_handler_slide_send_email.md b/content/reusable/md/dsl_handler_slide_send_email.md
new file mode 100644
index 0000000..89f3d8a
--- /dev/null
+++ b/content/reusable/md/dsl_handler_slide_send_email.md
@@ -0,0 +1,8 @@
+Use the `on` method to create an event handler that sends email when a
+Chef Infra Client run fails. This will require:
+
+- A way to tell Chef Infra Client how to send email
+- An event handler that describes what to do when the `:run_failed`
+ event is triggered
+- A way to trigger the exception and test the behavior of the event
+ handler
diff --git a/content/reusable/md/dsl_handler_slide_send_email_handler.md b/content/reusable/md/dsl_handler_slide_send_email_handler.md
new file mode 100644
index 0000000..d5e2175
--- /dev/null
+++ b/content/reusable/md/dsl_handler_slide_send_email_handler.md
@@ -0,0 +1,17 @@
+Invoke the library helper in a recipe:
+
+```ruby
+Chef.event_handler do
+ on :run_failed do
+ HandlerSendEmail::Helper.new.send_email_on_run_failure(
+ Chef.run_context.node.name
+ )
+ end
+end
+```
+
+- Use `Chef.event_handler` to define the event handler
+- Use the `on` method to specify the event type
+
+Within the `on` block, tell Chef Infra Client how to handle the event
+when it's triggered.
diff --git a/content/reusable/md/dsl_handler_slide_send_email_library.md b/content/reusable/md/dsl_handler_slide_send_email_library.md
new file mode 100644
index 0000000..28bfdb5
--- /dev/null
+++ b/content/reusable/md/dsl_handler_slide_send_email_library.md
@@ -0,0 +1,22 @@
+Use a library to define the code that sends email when a Chef Infra
+Client run fails. Name the file `helper.rb` and add it to a cookbook's
+`/libraries` directory:
+
+```ruby
+require 'net/smtp'
+
+module HandlerSendEmail
+ class Helper
+ def send_email_on_run_failure(node_name)
+ message = "From: Chef \n"
+ message << "To: Grant \n"
+ message << "Subject: Chef run failed\n"
+ message << "Date: #{Time.now.rfc2822}\n\n"
+ message << "Chef run failed on #{node_name}\n"
+ Net::SMTP.start('localhost', 25) do |smtp|
+ smtp.send_message message, 'chef@chef.io', 'grantmc@chef.io'
+ end
+ end
+ end
+end
+```
diff --git a/content/reusable/md/dsl_handler_slide_send_email_test.md b/content/reusable/md/dsl_handler_slide_send_email_test.md
new file mode 100644
index 0000000..d5a702d
--- /dev/null
+++ b/content/reusable/md/dsl_handler_slide_send_email_test.md
@@ -0,0 +1,10 @@
+Use the following code block to trigger the exception and have the Chef
+Infra Client send email to the specified email address:
+
+```ruby
+ruby_block 'fail the run' do
+ block do
+ raise 'deliberately fail the run'
+ end
+end
+```
diff --git a/content/reusable/md/dsl_handler_summary.md b/content/reusable/md/dsl_handler_summary.md
new file mode 100644
index 0000000..126e9ad
--- /dev/null
+++ b/content/reusable/md/dsl_handler_summary.md
@@ -0,0 +1,6 @@
+Use the Handler DSL to attach a callback to an event. If the event
+occurs during a Chef Infra Client run, the associated callback is
+executed. For example:
+
+- Sending email if a Chef Infra Client run fails
+- Aggregating statistics about resources updated during a Chef Infra Client runs to StatsD
diff --git a/content/reusable/md/environment.md b/content/reusable/md/environment.md
new file mode 100644
index 0000000..c76c68b
--- /dev/null
+++ b/content/reusable/md/environment.md
@@ -0,0 +1,10 @@
+An environment is a way to map an organization's real-life workflow to
+what can be configured and managed when using Chef Infra. This mapping
+is accomplished by setting attributes and pinning cookbooks at the
+environment level. With environments, you can change cookbook
+configurations depending on the system's designation. For example, by
+designating different staging and production environments, you can then
+define the correct URL of a database server for each environment.
+Environments also allow organizations to move new cookbook releases from
+staging to production with confidence by stepping releases through
+testing environments before entering production.
diff --git a/content/reusable/md/environment_attribute.md b/content/reusable/md/environment_attribute.md
new file mode 100644
index 0000000..28b3337
--- /dev/null
+++ b/content/reusable/md/environment_attribute.md
@@ -0,0 +1,10 @@
+Attributes can be defined in an environment and then used to override
+the default attributes in a cookbook. When an environment is applied
+during a Chef Infra Client run, environment attributes are compared to
+the attributes that are already present on the node. When the
+environment attributes take precedence over the default attributes, Chef
+Infra Client applies those new settings and values during a Chef Infra
+Client run.
+
+Environment attributes can be set to either `default` attribute level or
+an `override` attribute level.
diff --git a/content/reusable/md/fips_intro_client.md b/content/reusable/md/fips_intro_client.md
new file mode 100644
index 0000000..6530cb7
--- /dev/null
+++ b/content/reusable/md/fips_intro_client.md
@@ -0,0 +1,29 @@
+Federal Information Processing Standards (FIPS) is a United States
+government computer security standard that specifies security
+requirements for cryptography. The current version of the standard is
+FIPS 140-2. Chef Infra Client can be configured to allow OpenSSL to
+enforce FIPS-validated security during a Chef Infra Client run. This
+will disable cryptography that's explicitly disallowed in
+FIPS-validated software, including certain ciphers and hashing
+algorithms. Any attempt to use any disallowed cryptography will cause
+Chef Infra Client to throw an exception during a Chef Infra Client run.
+
+
+
+
+
Note
+
+
+Chef uses MD5 hashes to uniquely identify files that are stored on the
+Chef Infra Server. MD5 is used only to generate a unique hash identifier
+and isn't used for any cryptographic purpose.
+
+
+
+
+Notes about FIPS:
+
+- May be enabled for nodes running on Windows and Enterprise
+ Linux platforms
+- Should only be enabled for environments that require FIPS 140-2
+ compliance
diff --git a/content/reusable/md/handler.md b/content/reusable/md/handler.md
new file mode 100644
index 0000000..a4d2309
--- /dev/null
+++ b/content/reusable/md/handler.md
@@ -0,0 +1,3 @@
+Use a handler to identify situations that arise during a Chef Infra
+Client run, and then tell Chef Infra Client how to handle these
+situations when they occur.
diff --git a/content/reusable/md/handler_community_handlers.md b/content/reusable/md/handler_community_handlers.md
new file mode 100644
index 0000000..9a3a762
--- /dev/null
+++ b/content/reusable/md/handler_community_handlers.md
@@ -0,0 +1,78 @@
+The following open source handlers are available from the Chef
+community:
+
+[Airbrake](https://github.com/timops/ohai-plugins/blob/master/win32_svc.rb)
+
+: A handler that sends exceptions (only) to Airbrake, an application that collects data and aggregates it for review.
+
+[Asynchronous Resources](https://github.com/rottenbytes/chef/tree/master/async_handler)
+
+: A handler that asynchronously pushes exception and report handler data to a STOMP queue, from which data can be processed into data storage.
+
+[Campfire](https://github.com/ampledata/chef-handler-campfire)
+
+: A handler that collects exception and report handler data and reports it to Campfire, a web-based group chat tool.
+
+[Datadog](https://github.com/DataDog/chef-handler-datadog)
+
+: A handler that collects Chef Infra Client stats and sends them into a Datadog newsfeed.
+
+[Flowdock](https://github.com/mmarschall/chef-handler-flowdock)
+
+: A handler that collects exception and report handler data and sends it to users using the Flowdock API.
+
+[Graphite](https://github.com/imeyer/chef-handler-graphite/wiki)
+
+: A handler that collects exception and report handler data and reports it to Graphite, a graphic rendering application.
+
+[Graylog2 GELF](https://github.com/jellybob/chef-gelf/)
+
+: A handler that provides exception and report handler status (including changes) to a Graylog2 server, so that the data can be viewed using Graylog Extended Log Format (GELF).
+
+[Growl](https://rubygems.org/gems/chef-handler-growl)
+
+: A handler that collects exception and report handler data and then sends it as a Growl notification.
+
+[HipChat](https://github.com/mojotech/hipchat/blob/master/lib/hipchat/chef.rb)
+
+: A handler that collects exception handler data and sends it to HipChat, a hosted private chat service for companies and teams.
+
+[IRC Snitch](https://rubygems.org/gems/chef-irc-snitch)
+
+: A handler that notifies administrators (using Internet Relay Chat (IRC)) when a Chef Infra Client run fails.
+
+[Journald](https://github.com/marktheunissen/chef-handler-journald)
+
+: A handler that logs an entry to the systemd journal with the Chef Infra Client run status, exception details, configurable priority, and custom details.
+
+[net/http](https://github.com/b1-systems/chef-handler-httpapi/)
+
+: A handler that reports the status of a Chef run to any API using net/HTTP.
+
+[Simple Email](https://rubygems.org/gems/chef-handler-mail)
+
+: A handler that collects exception and report handler data and then uses pony to send email reports that are based on \`.erb\` (Embedded Ruby ) templates.
+
+[SNS](http://onddo.github.io/chef-handler-sns/)
+
+: A handler that notifies exception and report handler data and sends it to a SNS topic.
+
+[Slack](https://github.com/rackspace-cookbooks/chef-slack_handler)
+
+: A handler to send Chef Infra Client run notifications to a Slack channel.
+
+[Splunk Storm](http://ampledata.org/splunk_storm_chef_handler.html)
+
+: A handler that supports exceptions and reports for Splunk Storm.
+
+[Syslog](https://github.com/jblaine/syslog_handler)
+
+: A handler that logs basic essential information, such as about the success or failure of a Chef Infra Client run.
+
+[Updated Resources](https://rubygems.org/gems/chef-handler-updated-resources)
+
+: A handler that provides a simple way to display resources that were updated during a Chef Infra Client run.
+
+[ZooKeeper](http://onddo.github.io/chef-handler-zookeeper/)
+
+: A Chef report handler to send Chef run notifications to ZooKeeper.
diff --git a/content/reusable/md/handler_type_exception_report.md b/content/reusable/md/handler_type_exception_report.md
new file mode 100644
index 0000000..3f33085
--- /dev/null
+++ b/content/reusable/md/handler_type_exception_report.md
@@ -0,0 +1,23 @@
+Exception and report handlers are used to trigger certain behaviors in
+response to specific situations, typically identified during a Chef
+Infra Client run.
+
+- An exception handler is used to trigger behaviors when a defined
+ aspect of a Chef Infra Client run fails.
+- A report handler is used to trigger behaviors when a defined aspect
+ of a Chef Infra Client run is successful.
+
+Both types of handlers can be used to gather data about a Chef Infra
+Client run and can provide rich levels of data about all types of usage,
+which can be used later for trending and analysis across the entire
+organization.
+
+Exception and report handlers are made available to a Chef Infra Client
+run in one of the following ways:
+
+- By adding the **chef_handler** resource to a recipe, and then
+ adding that recipe to the run-list for a node. (The
+ **chef_handler** resource is available from the **chef_handler**
+ cookbook.)
+- By adding the handler to one of the following settings in the node's
+ client.rb file: `exception_handlers` and/or `report_handlers`
diff --git a/content/reusable/md/handler_type_exception_report_run_from_recipe.md b/content/reusable/md/handler_type_exception_report_run_from_recipe.md
new file mode 100644
index 0000000..e844b96
--- /dev/null
+++ b/content/reusable/md/handler_type_exception_report_run_from_recipe.md
@@ -0,0 +1,32 @@
+The **chef_handler** resource allows exception and report handlers to
+be enabled from within recipes, which can then added to the run-list for
+any node on which the exception or report handler should run. The
+**chef_handler** resource is available from the **chef_handler**
+cookbook.
+
+To use the **chef_handler** resource in a recipe, add code similar to
+the following:
+
+```ruby
+chef_handler 'name_of_handler' do
+ source '/path/to/handler/handler_name'
+ action :enable
+end
+```
+
+For example, a handler for Growl needs to be enabled at the beginning of
+a Chef Infra Client run:
+
+```ruby
+chef_gem 'chef-handler-growl'
+```
+
+and then is activated in a recipe by using the **chef_handler**
+resource:
+
+```ruby
+chef_handler 'Chef::Handler::Growl' do
+ source 'chef/handler/growl'
+ action :enable
+end
+```
diff --git a/content/reusable/md/handler_type_start.md b/content/reusable/md/handler_type_start.md
new file mode 100644
index 0000000..d8eecd4
--- /dev/null
+++ b/content/reusable/md/handler_type_start.md
@@ -0,0 +1,15 @@
+A start handler isn't loaded into a Chef Infra Client run from a
+recipe, but is instead listed in the client.rb file using the
+`start_handlers` attribute. The start handler must be installed on the
+node and be available to Chef Infra Client before the start of a Chef
+Infra Client run. Use the **chef-client** cookbook to install the start
+handler.
+
+Start handlers are made available to a Chef Infra Client run in one of
+the following ways:
+
+- By adding a start handler to the **chef-client** cookbook, which
+ installs the handler on the node so that it's available to Chef
+ Infra Client at the start of a Chef Infra Client run
+- By adding the handler to one of the following settings in the node's
+ client.rb file: `start_handlers`
diff --git a/content/reusable/md/handler_type_start_run_from_recipe.md b/content/reusable/md/handler_type_start_run_from_recipe.md
new file mode 100644
index 0000000..06c9bb3
--- /dev/null
+++ b/content/reusable/md/handler_type_start_run_from_recipe.md
@@ -0,0 +1,18 @@
+The **chef-client** cookbook can be configured to automatically install
+and configure gems that are required by a start handler. For example:
+
+```ruby
+node.override['chef_client']['load_gems']['chef-reporting'] = {
+ require_name: 'chef_reporting',
+ action: :install,
+}
+
+node.override['chef_client']['config']['start_handlers'] = [
+ {
+ class: 'Chef::Reporting::StartHandler',
+ arguments: [],
+ },
+]
+
+include_recipe 'chef-client::config'
+```
diff --git a/content/reusable/md/handler_types.md b/content/reusable/md/handler_types.md
new file mode 100644
index 0000000..fa21c64
--- /dev/null
+++ b/content/reusable/md/handler_types.md
@@ -0,0 +1,13 @@
+There are three types of handlers:
+
+exception
+
+: An exception handler is used to identify situations that have caused a Chef Infra Client run to fail. An exception handler can be loaded at the start of a Chef Infra Client run by adding a recipe that contains the **chef_handler** resource to a node's run-list. An exception handler runs when the `failed?` property for the `run_status` object returns `true`.
+
+report
+
+: A report handler is used when a Chef Infra Client run succeeds and reports back on certain details about that Chef Infra Client run. A report handler can be loaded at the start of a Chef Infra Client run by adding a recipe that contains the **chef_handler** resource to a node's run-list. A report handler runs when the `success?` property for the `run_status` object returns `true`.
+
+start
+
+: A start handler is used to run events at the beginning of a Chef Infra Client run. A start handler can be loaded at the start of a Chef Infra Client run by adding the start handler to the `start_handlers` setting in the client.rb file or by installing the gem that contains the start handler by using the **chef_gem** resource in a recipe in the **chef-client** cookbook. (A start handler may not be loaded using the `chef_handler` resource.)
diff --git a/content/reusable/md/infra_lang_data_bag.md b/content/reusable/md/infra_lang_data_bag.md
new file mode 100644
index 0000000..f088597
--- /dev/null
+++ b/content/reusable/md/infra_lang_data_bag.md
@@ -0,0 +1,14 @@
+```ruby
+data_bag('users') #=> ['sandy', 'jill']
+```
+
+Iterate over the contents of the data bag to get the associated
+`data_bag_item`:
+
+```ruby
+data_bag('users').each do |user|
+ data_bag_item('users', user)
+end
+```
+
+The `id` for each data bag item will be returned as a string.
diff --git a/content/reusable/md/infra_lang_method_registry_data_exists.md b/content/reusable/md/infra_lang_method_registry_data_exists.md
new file mode 100644
index 0000000..0007a0e
--- /dev/null
+++ b/content/reusable/md/infra_lang_method_registry_data_exists.md
@@ -0,0 +1,3 @@
+Use the `registry_data_exists?` method to find out if a Microsoft
+Windows registry key contains the specified data of the specified type
+under the value.
diff --git a/content/reusable/md/infra_lang_method_registry_data_exists_syntax.md b/content/reusable/md/infra_lang_method_registry_data_exists_syntax.md
new file mode 100644
index 0000000..4459215
--- /dev/null
+++ b/content/reusable/md/infra_lang_method_registry_data_exists_syntax.md
@@ -0,0 +1,36 @@
+The syntax for the `registry_data_exists?` method is as follows:
+
+```ruby
+registry_data_exists?(
+ KEY_PATH,
+ { name: 'NAME', type: TYPE, data: DATA },
+ ARCHITECTURE
+)
+```
+
+where:
+
+- `KEY_PATH` is the path to the registry key value. The path must
+ include the registry hive, which can be specified either as its full
+ name or as the 3- or 4-letter abbreviation. For example, both
+ `HKLM\SECURITY` and `HKEY_LOCAL_MACHINE\SECURITY` are both valid and
+ equivalent. The following hives are valid: `HKEY_LOCAL_MACHINE`,
+ `HKLM`, `HKEY_CURRENT_CONFIG`, `HKCC`, `HKEY_CLASSES_ROOT`, `HKCR`,
+ `HKEY_USERS`, `HKU`, `HKEY_CURRENT_USER`, and `HKCU`.
+- `{ name: 'NAME', type: TYPE, data: DATA }` is a hash that contains
+ the expected name, type, and data of the registry key value
+- `type:` represents the values available for registry keys in
+ Windows. Use `:binary` for REG_BINARY, `:string` for
+ REG_SZ, `:multi_string` for REG_MULTI_SZ, `:expand_string` for
+ REG_EXPAND_SZ, `:dword` for REG_DWORD, `:dword_big_endian` for
+ REG_DWORD_BIG_ENDIAN, or `:qword` for REG_QWORD.
+- `ARCHITECTURE` is one of the following values: `:x86_64`, `:i386`,
+ or `:machine`. Set to `:i386` to read or write 32-bit registry keys
+ on 64-bit machines running Windows. Set to`:x86_64` to
+ force write to a 64-bit registry location, however Chef Infra Client
+ returns an exception if `:x86_64` is used on a 32-bit machine. Set
+ to `:machine` to allow Chef Infra Client to allow Chef Infra Client
+ to use the appropriate key location based on your node's
+ architecture. Default value: `:machine`.
+
+This method will return `true` or `false`.
diff --git a/content/reusable/md/infra_lang_method_registry_get_subkeys.md b/content/reusable/md/infra_lang_method_registry_get_subkeys.md
new file mode 100644
index 0000000..ca06730
--- /dev/null
+++ b/content/reusable/md/infra_lang_method_registry_get_subkeys.md
@@ -0,0 +1,2 @@
+Use the `registry_get_subkeys` method to get a list of registry key
+values that are present for a Windows registry key.
diff --git a/content/reusable/md/infra_lang_method_registry_get_subkeys_syntax.md b/content/reusable/md/infra_lang_method_registry_get_subkeys_syntax.md
new file mode 100644
index 0000000..ecdfb4f
--- /dev/null
+++ b/content/reusable/md/infra_lang_method_registry_get_subkeys_syntax.md
@@ -0,0 +1,25 @@
+The syntax for the `registry_get_subkeys` method is as follows:
+
+```ruby
+subkey_array = registry_get_subkeys(KEY_PATH, ARCHITECTURE)
+```
+
+where:
+
+- `KEY_PATH` is the path to the registry key. The path must include
+ the registry hive, which can be specified either as its full name or
+ as the 3- or 4-letter abbreviation. For example, both
+ `HKLM\SECURITY` and `HKEY_LOCAL_MACHINE\SECURITY` are both valid and
+ equivalent. The following hives are valid: `HKEY_LOCAL_MACHINE`,
+ `HKLM`, `HKEY_CURRENT_CONFIG`, `HKCC`, `HKEY_CLASSES_ROOT`, `HKCR`,
+ `HKEY_USERS`, `HKU`, `HKEY_CURRENT_USER`, and `HKCU`.
+- `ARCHITECTURE` is one of the following values: `:x86_64`, `:i386`,
+ or `:machine`. Set to `:i386` to read or write 32-bit registry keys
+ on 64-bit machines running Windows. Set to`:x86_64` to
+ force write to a 64-bit registry location, however Chef Infra Client
+ returns an exception if `:x86_64` is used on a 32-bit machine. Set
+ to `:machine` to allow Chef Infra Client to allow Chef Infra Client
+ to use the appropriate key location based on your node's
+ architecture. Default value: `:machine`.
+
+This returns an array of registry key values.
diff --git a/content/reusable/md/infra_lang_method_registry_get_values.md b/content/reusable/md/infra_lang_method_registry_get_values.md
new file mode 100644
index 0000000..9a24cc0
--- /dev/null
+++ b/content/reusable/md/infra_lang_method_registry_get_values.md
@@ -0,0 +1,2 @@
+Use the `registry_get_values` method to get the registry key values
+(name, type, and data) for a Windows registry key.
diff --git a/content/reusable/md/infra_lang_method_registry_get_values_syntax.md b/content/reusable/md/infra_lang_method_registry_get_values_syntax.md
new file mode 100644
index 0000000..d5518b9
--- /dev/null
+++ b/content/reusable/md/infra_lang_method_registry_get_values_syntax.md
@@ -0,0 +1,25 @@
+The syntax for the `registry_get_values` method is as follows:
+
+```ruby
+subkey_array = registry_get_values(KEY_PATH, ARCHITECTURE)
+```
+
+where:
+
+- `KEY_PATH` is the path to the registry key. The path must include
+ the registry hive, which can be specified either as its full name or
+ as the 3- or 4-letter abbreviation. For example, both
+ `HKLM\SECURITY` and `HKEY_LOCAL_MACHINE\SECURITY` are both valid and
+ equivalent. The following hives are valid: `HKEY_LOCAL_MACHINE`,
+ `HKLM`, `HKEY_CURRENT_CONFIG`, `HKCC`, `HKEY_CLASSES_ROOT`, `HKCR`,
+ `HKEY_USERS`, `HKU`, `HKEY_CURRENT_USER`, and `HKCU`.
+- `ARCHITECTURE` is one of the following values: `:x86_64`, `:i386`,
+ or `:machine`. Set to `:i386` to read or write 32-bit registry keys
+ on 64-bit machines running Windows. Set to`:x86_64` to
+ force write to a 64-bit registry location, however Chef Infra Client
+ returns an exception if `:x86_64` is used on a 32-bit machine. Set
+ to `:machine` to allow Chef Infra Client to allow Chef Infra Client
+ to use the appropriate key location based on your node's
+ architecture. Default value: `:machine`.
+
+This returns an array of registry key values.
diff --git a/content/reusable/md/infra_lang_method_registry_has_subkeys.md b/content/reusable/md/infra_lang_method_registry_has_subkeys.md
new file mode 100644
index 0000000..e98a3d9
--- /dev/null
+++ b/content/reusable/md/infra_lang_method_registry_has_subkeys.md
@@ -0,0 +1,2 @@
+Use the `registry_has_subkeys?` method to find out if a Microsoft
+Windows registry key has one (or more) values.
diff --git a/content/reusable/md/infra_lang_method_registry_has_subkeys_syntax.md b/content/reusable/md/infra_lang_method_registry_has_subkeys_syntax.md
new file mode 100644
index 0000000..a1a783e
--- /dev/null
+++ b/content/reusable/md/infra_lang_method_registry_has_subkeys_syntax.md
@@ -0,0 +1,25 @@
+The syntax for the `registry_has_subkeys?` method is as follows:
+
+```ruby
+registry_has_subkeys?(KEY_PATH, ARCHITECTURE)
+```
+
+where:
+
+- `KEY_PATH` is the path to the registry key. The path must include
+ the registry hive, which can be specified either as its full name or
+ as the 3- or 4-letter abbreviation. For example, both
+ `HKLM\SECURITY` and `HKEY_LOCAL_MACHINE\SECURITY` are both valid and
+ equivalent. The following hives are valid: `HKEY_LOCAL_MACHINE`,
+ `HKLM`, `HKEY_CURRENT_CONFIG`, `HKCC`, `HKEY_CLASSES_ROOT`, `HKCR`,
+ `HKEY_USERS`, `HKU`, `HKEY_CURRENT_USER`, and `HKCU`.
+- `ARCHITECTURE` is one of the following values: `:x86_64`, `:i386`,
+ or `:machine`. Set to `:i386` to read or write 32-bit registry keys
+ on 64-bit machines running Windows. Set to`:x86_64` to
+ force write to a 64-bit registry location, however Chef Infra Client
+ returns an exception if `:x86_64` is used on a 32-bit machine. Set
+ to `:machine` to allow Chef Infra Client to allow Chef Infra Client
+ to use the appropriate key location based on your node's
+ architecture. Default value: `:machine`.
+
+This method will return `true` or `false`.
diff --git a/content/reusable/md/infra_lang_method_registry_key_exists.md b/content/reusable/md/infra_lang_method_registry_key_exists.md
new file mode 100644
index 0000000..2ee7b11
--- /dev/null
+++ b/content/reusable/md/infra_lang_method_registry_key_exists.md
@@ -0,0 +1,2 @@
+Use the `registry_key_exists?` method to find out if a Windows
+registry key exists at the specified path.
diff --git a/content/reusable/md/infra_lang_method_registry_key_exists_syntax.md b/content/reusable/md/infra_lang_method_registry_key_exists_syntax.md
new file mode 100644
index 0000000..4858953
--- /dev/null
+++ b/content/reusable/md/infra_lang_method_registry_key_exists_syntax.md
@@ -0,0 +1,26 @@
+The syntax for the `registry_key_exists?` method is as follows:
+
+```ruby
+registry_key_exists?(KEY_PATH, ARCHITECTURE)
+```
+
+where:
+
+- `KEY_PATH` is the path to the registry key. The path must include
+ the registry hive, which can be specified either as its full name or
+ as the 3- or 4-letter abbreviation. For example, both
+ `HKLM\SECURITY` and `HKEY_LOCAL_MACHINE\SECURITY` are both valid and
+ equivalent. The following hives are valid: `HKEY_LOCAL_MACHINE`,
+ `HKLM`, `HKEY_CURRENT_CONFIG`, `HKCC`, `HKEY_CLASSES_ROOT`, `HKCR`,
+ `HKEY_USERS`, `HKU`, `HKEY_CURRENT_USER`, and `HKCU`.
+- `ARCHITECTURE` is one of the following values: `:x86_64`, `:i386`,
+ or `:machine`. Set to `:i386` to read or write 32-bit registry keys
+ on 64-bit machines running Windows. Set to`:x86_64` to
+ force write to a 64-bit registry location, however Chef Infra Client
+ returns an exception if `:x86_64` is used on a 32-bit machine. Set
+ to `:machine` to allow Chef Infra Client to allow Chef Infra Client
+ to use the appropriate key location based on your node's
+ architecture. Default value: `:machine`.
+
+This method will return `true` or `false`. (Any registry key values that
+are associated with this registry key are ignored.)
diff --git a/content/reusable/md/infra_lang_method_registry_value_exists.md b/content/reusable/md/infra_lang_method_registry_value_exists.md
new file mode 100644
index 0000000..a537c38
--- /dev/null
+++ b/content/reusable/md/infra_lang_method_registry_value_exists.md
@@ -0,0 +1,3 @@
+Use the `registry_value_exists?` method to find out if a registry key
+value exists. Use `registry_data_exists?` to test for the type and data
+of a registry key value.
diff --git a/content/reusable/md/infra_lang_method_registry_value_exists_syntax.md b/content/reusable/md/infra_lang_method_registry_value_exists_syntax.md
new file mode 100644
index 0000000..9865217
--- /dev/null
+++ b/content/reusable/md/infra_lang_method_registry_value_exists_syntax.md
@@ -0,0 +1,37 @@
+The syntax for the `registry_value_exists?` method is as follows:
+
+```ruby
+registry_value_exists?(
+ KEY_PATH,
+ { name: 'NAME' },
+ ARCHITECTURE
+)
+```
+
+where:
+
+- `KEY_PATH` is the path to the registry key. The path must include
+ the registry hive, which can be specified either as its full name or
+ as the 3- or 4-letter abbreviation. For example, both
+ `HKLM\SECURITY` and `HKEY_LOCAL_MACHINE\SECURITY` are both valid and
+ equivalent. The following hives are valid: `HKEY_LOCAL_MACHINE`,
+ `HKLM`, `HKEY_CURRENT_CONFIG`, `HKCC`, `HKEY_CLASSES_ROOT`, `HKCR`,
+ `HKEY_USERS`, `HKU`, `HKEY_CURRENT_USER`, and `HKCU`.
+- `{ name: 'NAME' }` is a hash that contains the name of the registry
+ key value; if either `type:` or `:value` are specified in the hash,
+ they're ignored
+- `type:` represents the values available for registry keys in
+ Windows. Use `:binary` for REG_BINARY, `:string` for
+ REG_SZ, `:multi_string` for REG_MULTI_SZ, `:expand_string` for
+ REG_EXPAND_SZ, `:dword` for REG_DWORD, `:dword_big_endian` for
+ REG_DWORD_BIG_ENDIAN, or `:qword` for REG_QWORD.
+- `ARCHITECTURE` is one of the following values: `:x86_64`, `:i386`,
+ or `:machine`. Set to `:i386` to read or write 32-bit registry keys
+ on 64-bit machines running Windows. Set to`:x86_64` to
+ force write to a 64-bit registry location, however Chef Infra Client
+ returns an exception if `:x86_64` is used on a 32-bit machine. Set
+ to `:machine` to allow Chef Infra Client to allow Chef Infra Client
+ to use the appropriate key location based on your node's
+ architecture. Default value: `:machine`.
+
+This method will return `true` or `false`.
diff --git a/content/reusable/md/infra_lang_method_search_filter_result.md b/content/reusable/md/infra_lang_method_search_filter_result.md
new file mode 100644
index 0000000..c866efa
--- /dev/null
+++ b/content/reusable/md/infra_lang_method_search_filter_result.md
@@ -0,0 +1,43 @@
+Use `:filter_result` as part of a search query to filter the search
+output based on the pattern specified by a Hash. Only attributes in the
+Hash will be returned.
+
+The syntax for the `search` method that uses `:filter_result` is as
+follows:
+
+```ruby
+search(:index, 'query',
+ filter_result: { 'foo' => [ 'abc' ],
+ 'bar' => [ '123' ],
+ 'baz' => %w(sea power),
+ }
+).each do |result|
+ puts result['foo']
+ puts result['bar']
+ puts result['baz']
+end
+```
+
+where:
+
+- `:index` is of name of the index on Chef Infra Server against
+ which the search query will run: `:client`, `:data_bag_name`,
+ `:environment`, `:node`, and `:role`
+- `'query'` is a valid search query against an object on the Chef
+ server
+- `:filter_result` defines a Hash of values to be returned
+
+For example:
+
+```ruby
+search(:node, 'role:web',
+ filter_result: { 'name' => [ 'name' ],
+ 'ip' => [ 'ipaddress' ],
+ 'kernel_version' => %w(kernel version),
+ }
+).each do |result|
+ puts result['name']
+ puts result['ip']
+ puts result['kernel_version']
+end
+```
diff --git a/content/reusable/md/infra_lang_method_windows_methods.md b/content/reusable/md/infra_lang_method_windows_methods.md
new file mode 100644
index 0000000..4721c58
--- /dev/null
+++ b/content/reusable/md/infra_lang_method_windows_methods.md
@@ -0,0 +1,6 @@
+Six methods are present in the Chef Infra Language to help verify the registry
+during a Chef Infra Client run on the Windows
+platform---`registry_data_exists?`, `registry_get_subkeys`,
+`registry_get_values`, `registry_has_subkeys?`, `registry_key_exists?`,
+and `registry_value_exists?`---these helpers ensure the
+**powershell_script** resource is idempotent.
diff --git a/content/reusable/md/infra_lang_ruby.md b/content/reusable/md/infra_lang_ruby.md
new file mode 100644
index 0000000..f0ca9a7
--- /dev/null
+++ b/content/reusable/md/infra_lang_ruby.md
@@ -0,0 +1 @@
+The Chef Infra Language is based on Ruby, allowing you to utilize the power of Ruby when the built-in language doesn't meet your needs out of the box. If you'd like to learn more about extending your Chef Infra code by using Ruby see our [Ruby Guide](/ruby/) for further information on Ruby functionality.
diff --git a/content/reusable/md/infra_lang_summary.md b/content/reusable/md/infra_lang_summary.md
new file mode 100644
index 0000000..8cf352b
--- /dev/null
+++ b/content/reusable/md/infra_lang_summary.md
@@ -0,0 +1 @@
+The Chef Infra Language is a comprehensive systems configuration language with resources and helpers for configuring operating systems. The language is primarily used in Chef Infra recipes and custom resources to tell the Chef Infra Client what actions to take to configure a system. The Chef Infra Language provides resources for system-level components such as packages, users, or firewalls, and it also includes helpers to allow you to make configuration decisions based on operating systems, clouds, virtualization hypervisors, and more.
diff --git a/content/reusable/md/install_chef_client.md b/content/reusable/md/install_chef_client.md
new file mode 100644
index 0000000..0b807a0
--- /dev/null
+++ b/content/reusable/md/install_chef_client.md
@@ -0,0 +1,16 @@
+The `knife bootstrap` command is a common way to install Chef Infra
+Client on a node. The default for this approach assumes that a node can
+access the Chef website so that it may download the Chef Infra Client
+package from that location.
+
+The Chef Infra Client installer will detect the version of the operating
+system, and then install the appropriate Chef Infra Client version using
+a single command to install Chef Infra Client and all of its dependencies,
+including an embedded version of Ruby, OpenSSL, parsers, libraries,
+and command line utilities.
+
+The Chef Infra Client installer puts everything into a unique directory
+(`/opt/chef/`) so that Chef Infra Client won't interfere with other
+applications that may be running on the target machine. Once installed,
+Chef Infra Client requires a few more configuration steps before it can
+perform its first Chef Infra Client run on a node.
diff --git a/content/reusable/md/install_chef_client_windows_as_scheduled_task.md b/content/reusable/md/install_chef_client_windows_as_scheduled_task.md
new file mode 100644
index 0000000..c604f08
--- /dev/null
+++ b/content/reusable/md/install_chef_client_windows_as_scheduled_task.md
@@ -0,0 +1,19 @@
+To run Chef Infra Client at periodic intervals (so that it can check in
+with Chef Infra Server automatically), configure Chef Infra Client to
+run as a scheduled task. This can be done using the MSI, by selecting the
+**Chef Unattended Execution Options** --\> **Chef Infra Client Scheduled
+Task** option on the **Custom Setup** page or by running the following
+command after Chef Infra Client is installed:
+
+For example:
+
+```powershell
+SCHTASKS.EXE /CREATE /TN ChefClientSchTask /SC MINUTE /MO 30 /F /RU "System" /RP /RL HIGHEST /TR "cmd /c \"C:\opscode\chef\embedded\bin\ruby.exe C:\opscode\chef\bin\chef-client -L C:\chef\chef-client.log -c C:\chef\client.rb\""
+```
+
+Refer to the [Schtasks
+documentation](https://docs.microsoft.com/en-us/windows/win32/taskschd/schtasks)
+for more details.
+
+After Chef Infra Client is configured to run as a scheduled task, the
+default file path is: `c:\chef\chef-client.log`.
diff --git a/content/reusable/md/libraries_summary.md b/content/reusable/md/libraries_summary.md
new file mode 100644
index 0000000..c31b8fb
--- /dev/null
+++ b/content/reusable/md/libraries_summary.md
@@ -0,0 +1,7 @@
+A library allows arbitrary Ruby code to be included in a cookbook. The
+most common use for libraries is to write helpers that are used
+throughout recipes and custom resources. A library file is a Ruby file
+that's located within a cookbook's `/libraries` directory. Because a
+library is built using Ruby, anything that can be done with Ruby can be
+done in a library file, including advanced functionality such as
+extending built-in Chef classes.
diff --git a/content/reusable/md/manage_webui_policy_validation_reset_key.md b/content/reusable/md/manage_webui_policy_validation_reset_key.md
new file mode 100644
index 0000000..c81b98e
--- /dev/null
+++ b/content/reusable/md/manage_webui_policy_validation_reset_key.md
@@ -0,0 +1,26 @@
+To reset a chef-validator key:
+
+1. Open the Chef management console.
+
+1. Click **Policy**.
+
+1. Click **Clients**.
+
+1. Select a chef-validator key.
+
+1. Click the **Details** tab.
+
+1. Click **Reset Key**.
+
+1. In the **Reset Key** dialog box, confirm that the key should be
+ regenerated and click the **Reset Key** button:
+
+ 
+
+1. Copy the private key:
+
+ 
+
+ or download and save the private key locally:
+
+ 
diff --git a/content/reusable/md/node.md b/content/reusable/md/node.md
new file mode 100644
index 0000000..5123429
--- /dev/null
+++ b/content/reusable/md/node.md
@@ -0,0 +1,2 @@
+A node is any device---physical, virtual, cloud, network device,
+etc.---that's under management by Chef Infra.
diff --git a/content/reusable/md/node_attribute.md b/content/reusable/md/node_attribute.md
new file mode 100644
index 0000000..a1b4818
--- /dev/null
+++ b/content/reusable/md/node_attribute.md
@@ -0,0 +1,22 @@
+An attribute is a specific detail about a node. Attributes are used by Chef Infra Client to understand:
+
+- The current state of the node
+- What the state of the node was at the end of the previous Chef Infra Client run
+- What the state of the node should be at the end of the current Chef Infra Client run
+
+Attributes are defined by:
+
+- The node as saved on Chef Infra Server
+- Attributes passed using JSON on the command line
+- Cookbooks (in attribute files and/or recipes)
+- Policyfiles
+
+During every Chef Infra Client run, Chef Infra Client builds the attribute list using:
+
+- Attributes passed using JSON on the command line
+- Data about the node collected by [Ohai](/ohai.html).
+- The node object that was saved to Chef Infra Server at the end of the previous Chef Infra Client run.
+- The rebuilt node object from the current Chef Infra Client run, after it's updated for changes to cookbooks (attribute files and/or recipes) and/or Policyfiles, and updated for any changes to the state of the node itself.
+
+After the node object is rebuilt, all of the attributes are compared, and then the node is updated based on attribute precedence. At the end of every Chef Infra Client run, the node object that defines the current state of the node is uploaded to Chef Infra Server so that it can be
+indexed for search.
diff --git a/content/reusable/md/node_attribute_allowlist.md b/content/reusable/md/node_attribute_allowlist.md
new file mode 100644
index 0000000..262499e
--- /dev/null
+++ b/content/reusable/md/node_attribute_allowlist.md
@@ -0,0 +1,66 @@
+Attributes that should be saved by a node may be allowlisted in the client.rb file. The allowlist is a hash of keys that specifies each attribute to be saved.
+
+Attributes are allowlisted by attribute type, with each attribute type being allowlisted independently. Each attribute type---`automatic`, `default`, `normal`, and `override`---may define allowlists by using the following settings in the client.rb file:
+
+`allowed_automatic_attributes`
+
+: A hash that allowlists `automatic` attributes, preventing non-allowlisted attributes from being saved. For example: `['network/interfaces/eth0']`. Default value: `nil`, all attributes are saved. If the hash is empty, no attributes are saved.
+
+`allowed_default_attributes`
+
+: A hash that allowlists `default` attributes, preventing non-allowlisted attributes from being saved. For example: `['filesystem/dev/disk0s2/size']`. Default value: `nil`, all attributes are saved. If the hash is empty, no attributes are saved.
+
+`allowed_normal_attributes`
+
+: A hash that allowlists `normal` attributes, preventing non-allowlisted attributes from being saved. For example: `['filesystem/dev/disk0s2/size']`. Default value: `nil`, all attributes are saved. If the hash is empty, no attributes are saved.
+
+`allowed_override_attributes`
+
+: A hash that allowlists `override` attributes, preventing non-allowlisted attributes from being saved. For example: `['map - autohome/size']`. Default value: `nil`, all attributes are saved. If the hash is empty, no attributes are saved.
+
+
+
+#### Allowlisting Ohai (automatic) attributes
+
+The recommended practice is to use `allowed_automatic_attributes` to allow specific attributes populated by Ohai's system information gathering. Ohai gathers a large number of attributes that can consume a significant amount of storage space on Chef Infra Server. Many of these attributes may be considered highly valuable, while others could be skipped without any impact to data available in search. Normal, default, and override attributes are typically much more important attributes used within cookbooks and are more likely to cause issues if they're omitted from an allowlist incorrectly.
+
+For example, automatic attribute data similar to:
+
+```json
+{
+ "filesystem" => {
+ "/dev/disk0s2" => {
+ "size" => "10mb"
+ },
+ "map - autohome" => {
+ "size" => "10mb"
+ }
+ },
+ "network" => {
+ "interfaces" => {
+ "eth0" => {...},
+ "eth1" => {...},
+ }
+ }
+}
+```
+
+To allowlist the `network` attributes and prevent the other attributes from being saved, update the client.rb file:
+
+```ruby
+allowed_automatic_attributes ['network/interfaces/']
+```
+
+When a allowlist is defined, any attribute of that type that isn't specified in that attribute allowlist **won't** be saved. So based on the previous allowlist for automatic attributes, the `filesystem` and `map - autohome` attributes won't be saved, but the `network` attributes will.
+
+Leave the value empty to prevent all attributes of that attribute type from being saved:
+
+```ruby
+allowed_automatic_attributes []
+```
+
+For attributes that contain slashes (`/`) within the attribute value, such as the `filesystem` attribute `'/dev/diskos2'`, use an array. For example:
+
+```ruby
+allowed_automatic_attributes [['filesystem', '/dev/diskos2']]
+```
diff --git a/content/reusable/md/node_attribute_allowlist_warning.md b/content/reusable/md/node_attribute_allowlist_warning.md
new file mode 100644
index 0000000..29881cf
--- /dev/null
+++ b/content/reusable/md/node_attribute_allowlist_warning.md
@@ -0,0 +1,2 @@
+When attribute allowlist settings are used, only the attributes defined in a allowlist will be saved and any attribute that isn't defined in a allowlist won't be saved. Each attribute type is allowlisted independently of the other attribute types. For example, if `automatic_attribute_allowlist` defines attributes to be saved, but `normal_attribute_allowlist`, `default_attribute_allowlist`, and
+`override_attribute_allowlist` aren't defined, then all normal attributes, default attributes, and override attributes are saved, as well as the automatic attributes that were specifically included through allowlisting.
diff --git a/content/reusable/md/node_attribute_blocklist.md b/content/reusable/md/node_attribute_blocklist.md
new file mode 100644
index 0000000..871de0b
--- /dev/null
+++ b/content/reusable/md/node_attribute_blocklist.md
@@ -0,0 +1,83 @@
+Attributes are blocklisted by attribute type, with each attribute type being blocklisted independently in the `client.rb` file.
+
+The four attribute types are:
+
+- `automatic`
+- `default`
+- `normal`
+- `override`
+
+The blocklist settings are:
+
+`blocked_automatic_attributes`
+
+: An array that blocklists `automatic` attributes, preventing blocklisted attributes from being saved. For example: `['packages']`.
+
+ Default value: `nil`, all attributes are saved.
+
+ If the array is empty, all attributes are saved.
+
+`blocked_default_attributes`
+
+: An array that blocklists `default` attributes, preventing blocklisted attributes from being saved. For example: `['filesystem/dev/disk0s2/size']`.
+
+ Default value: `nil`, all attributes are saved.
+
+ If the array is empty, all attributes are saved.
+
+`blocked_normal_attributes`
+
+: An array that blocklists `normal` attributes, preventing blocklisted attributes from being saved. For example: `['filesystem/dev/disk0s2/size']`.
+
+ Default value: `nil`, all attributes are saved.
+
+ If the array is empty, all attributes are saved.
+
+`blocked_override_attributes`
+
+: An array that blocklists `override` attributes, preventing blocklisted attributes from being saved. For example: `['map - autohome/size']`.
+
+ Default value: `nil`, all attributes are saved.
+
+ If the array is empty, all attributes are saved.
+
+
+
+#### Blocklisting Ohai (automatic) attributes
+
+Use `blocked_automatic_attributes` to block attributes populated by Ohai's system information gathering.
+
+Ohai gathers a large number of attributes that can consume a significant amount of storage space on Chef Infra Server.
+Many of these attributes may be considered highly valuable, while others could be blocklisted without any impact to data available in search.
+Normal, default, and override attributes are typically much more important attributes used within cookbooks and are more likely to cause issues if they're blocklisted incorrectly.
+
+##### Example
+
+The following shows an example of automatic attribute data.
+
+```json
+{
+ "filesystem" => {
+ "/dev/disk0s2" => {
+ "size" => "10mb"
+ },
+ "map - autohome" => {
+ "size" => "10mb"
+ }
+ },
+ "network" => {
+ "interfaces" => {
+ "eth0" => {...},
+ "eth1" => {...},
+ }
+ }
+}
+```
+
+To blocklist the `filesystem` attributes and allow Infra Client to save the other attributes, update the `client.rb`.
+
+```ruby
+blocked_automatic_attributes ['filesystem']
+```
+
+This blocklist blocks Chef Infra Client from saving the `filesystem` and `map - autohome` attributes, but saves the `network` attributes.
diff --git a/content/reusable/md/node_attribute_blocklist_warning.md b/content/reusable/md/node_attribute_blocklist_warning.md
new file mode 100644
index 0000000..af5a852
--- /dev/null
+++ b/content/reusable/md/node_attribute_blocklist_warning.md
@@ -0,0 +1 @@
+When attribute blocklist settings are used, any attribute defined in a blocklist won't be saved to Chef Infra Server and any attribute that isn't defined in a blocklist will be saved. Each attribute type must be blocklisted independently of the other attribute types. For example, if `blocked_automatic_attributes` defines attributes that won't be saved, but `blocked_normal_attributes`, `blocked_default_attributes`, and `blocked_override_attributes` aren't defined, then all normal attributes, default attributes, and override attributes will be saved, as well as the automatic attributes that weren't specifically excluded through blocklisting.
diff --git a/content/reusable/md/node_attribute_type_automatic.md b/content/reusable/md/node_attribute_type_automatic.md
new file mode 100644
index 0000000..fb6f40a
--- /dev/null
+++ b/content/reusable/md/node_attribute_type_automatic.md
@@ -0,0 +1,3 @@
+An `automatic` attribute contains data that's identified by Ohai at the
+beginning of every Chef Infra Client run. An `automatic` attribute
+can't be modified and always has the highest attribute precedence.
diff --git a/content/reusable/md/node_attribute_type_default.md b/content/reusable/md/node_attribute_type_default.md
new file mode 100644
index 0000000..4ce8dca
--- /dev/null
+++ b/content/reusable/md/node_attribute_type_default.md
@@ -0,0 +1,3 @@
+A `default` attribute is automatically reset at the start of every Chef
+Infra Client run and has the lowest attribute precedence. Use `default`
+attributes as often as possible in cookbooks.
diff --git a/content/reusable/md/node_attribute_type_normal.md b/content/reusable/md/node_attribute_type_normal.md
new file mode 100644
index 0000000..2a0bec6
--- /dev/null
+++ b/content/reusable/md/node_attribute_type_normal.md
@@ -0,0 +1,3 @@
+A `normal` attribute is a setting that persists in the node object. A
+`normal` attribute has a higher attribute precedence than a `default`
+attribute.
diff --git a/content/reusable/md/node_attribute_type_override.md b/content/reusable/md/node_attribute_type_override.md
new file mode 100644
index 0000000..f3095db
--- /dev/null
+++ b/content/reusable/md/node_attribute_type_override.md
@@ -0,0 +1,7 @@
+An `override` attribute is automatically reset at the start of every
+Chef Infra Client run and has a higher attribute precedence than
+`default`, `force_default`, and `normal` attributes. An `override`
+attribute is most often specified in a recipe, but can be specified in
+an attribute file, for a role, and/or for an environment. A cookbook
+should be authored so that it uses `override` attributes only when
+required.
diff --git a/content/reusable/md/node_ctl_attribute.md b/content/reusable/md/node_ctl_attribute.md
new file mode 100644
index 0000000..44f4581
--- /dev/null
+++ b/content/reusable/md/node_ctl_attribute.md
@@ -0,0 +1,37 @@
+Any other attribute type that's contained in this JSON file will be
+treated as a `normal` attribute. Setting attributes at other precedence
+levels isn't possible. For example, attempting to update `override`
+attributes using the `-j` option:
+
+```json
+{
+ "name": "dev-99",
+ "description": "Install some stuff",
+ "override_attributes": {
+ "apptastic": {
+ "enable_apptastic": "false",
+ "apptastic_tier_name": "dev-99.bomb.com"
+ }
+ }
+}
+```
+
+will result in a node object similar to:
+
+```json
+{
+ "name": "maybe-dev-99",
+ "normal": {
+ "name": "dev-99",
+ "description": "Install some stuff",
+ "override_attributes": {
+ "apptastic": {
+ "enable_apptastic": "false",
+ "apptastic_tier_name": "dev-99.bomb.com"
+ }
+ }
+ }
+}
+```
+
+
\ No newline at end of file
diff --git a/content/reusable/md/node_ctl_run_list.md b/content/reusable/md/node_ctl_run_list.md
new file mode 100644
index 0000000..efee287
--- /dev/null
+++ b/content/reusable/md/node_ctl_run_list.md
@@ -0,0 +1,16 @@
+Use this option to define a `run_list` object. For example, a JSON file
+similar to:
+
+```json
+"run_list": [
+ "recipe[base]",
+ "recipe[foo]",
+ "recipe[bar]",
+ "role[webserver]"
+],
+```
+
+may be used by running `chef-client -j path/to/file.json`.
+
+In certain situations this option may be used to update `normal`
+attributes.
diff --git a/content/reusable/md/node_run_list.md b/content/reusable/md/node_run_list.md
new file mode 100644
index 0000000..70f51eb
--- /dev/null
+++ b/content/reusable/md/node_run_list.md
@@ -0,0 +1,11 @@
+A run-list defines all of the information necessary for Chef to
+configure a node into the desired state. A run-list is:
+
+- An ordered list of roles and/or recipes that are run in the exact
+ order defined in the run-list; if a recipe appears more than once in
+ the run-list, Chef Infra Client won't run it twice
+- Always specific to the node on which it runs; nodes may have a
+ run-list that's identical to the run-list used by other nodes
+- Stored as part of the node object on Chef Infra Server
+- Maintained using knife and then uploaded from the workstation to the
+ Chef Infra Server, or maintained using Chef Automate
diff --git a/content/reusable/md/node_run_list_empty.md b/content/reusable/md/node_run_list_empty.md
new file mode 100644
index 0000000..857a3dc
--- /dev/null
+++ b/content/reusable/md/node_run_list_empty.md
@@ -0,0 +1,9 @@
+Use an empty run-list to determine if a failed Chef Infra Client run has
+anything to do with the recipes that are defined within that run-list.
+This is a quick way to discover if the underlying cause of a Chef Infra
+Client run failure is a configuration issue. If a failure persists even
+if the run-list is empty, check the following:
+
+- Configuration settings in the config.rb file
+- Permissions for the user to both Chef Infra Server and to the
+ node on which a Chef Infra Client run is to take place
diff --git a/content/reusable/md/node_run_list_format.md b/content/reusable/md/node_run_list_format.md
new file mode 100644
index 0000000..458b184
--- /dev/null
+++ b/content/reusable/md/node_run_list_format.md
@@ -0,0 +1,20 @@
+A run-list must be in one of the following formats: fully qualified,
+cookbook, or default. Both roles and recipes must be in quotes, for
+example:
+
+```json
+"role[NAME]"
+```
+
+or
+
+```json
+"recipe[COOKBOOK::RECIPE]"
+```
+
+Use a comma to separate roles and recipes when adding more than one item
+the run-list:
+
+```json
+"recipe[COOKBOOK::RECIPE],COOKBOOK::RECIPE,role[NAME]"
+```
diff --git a/content/reusable/md/node_types.md b/content/reusable/md/node_types.md
new file mode 100644
index 0000000..15e1702
--- /dev/null
+++ b/content/reusable/md/node_types.md
@@ -0,0 +1,39 @@
+The types of nodes that can be managed by Chef include, but aren't
+limited to, the following:
+
+
+
+
+
+
+
+
+
+
+
Node Type
+
Description
+
+
+
+
+
+
A physical node is typically a server or a virtual machine, but it can be any active device attached to a network that's capable of sending, receiving, and forwarding information over a communications channel. In other words, a physical node is any active device attached to a network that can run a Chef Infra Client and also allow that Chef Infra Client to communicate with a Chef Infra Server.
+
+
+
+
A cloud-based node is hosted in an external cloud-based service, such as Amazon Web Services (AWS), OpenStack, Rackspace, Google Compute Engine, or Microsoft Azure. Plugins are available for knife that provide support for external cloud-based services. knife can use these plugins to create instances on cloud-based services. Once created, Chef Infra Client can be used to deploy, configure, and maintain those instances.
+
+
+
+
A virtual node is a machine that runs only as a software implementation, but otherwise behaves much like a physical machine.
+
+
+
+
A network node is any networking device---a switch, a router---that's being managed by a Chef Infra Client, such as networking devices by Juniper Networks, Arista, Cisco, and F5. Use Chef to automate common network configurations, such as physical and logical Ethernet link properties and VLANs, on these devices.
+
+
+
+
Containers are an approach to virtualization that allows a single operating system to host many working configurations, where each working configuration---a container---is assigned a single responsibility that's isolated from all other responsibilities. Containers are popular as a way to manage distributed and scalable applications and services.
+
+
+
diff --git a/content/reusable/md/notes_registry_key_not_if_only_if.md b/content/reusable/md/notes_registry_key_not_if_only_if.md
new file mode 100644
index 0000000..9934277
--- /dev/null
+++ b/content/reusable/md/notes_registry_key_not_if_only_if.md
@@ -0,0 +1,4 @@
+This method can be used in recipes and from within the `not_if` and
+`only_if` blocks in resources. This method isn't designed to create or
+modify a registry key. If a registry key needs to be modified, use the
+**registry_key** resource.
diff --git a/content/reusable/md/notes_see_attributes_overview.md b/content/reusable/md/notes_see_attributes_overview.md
new file mode 100644
index 0000000..cedad86
--- /dev/null
+++ b/content/reusable/md/notes_see_attributes_overview.md
@@ -0,0 +1,5 @@
+Attributes can be configured in cookbooks (attribute files and recipes),
+roles, and environments. In addition, Ohai collects attribute data about
+each node at the start of a Chef Infra Client run. See
+[Attributes](/attributes/) for more information about how all of
+these attributes fit together.
diff --git a/content/reusable/md/ohai_attribute_list.md b/content/reusable/md/ohai_attribute_list.md
new file mode 100644
index 0000000..ddb335b
--- /dev/null
+++ b/content/reusable/md/ohai_attribute_list.md
@@ -0,0 +1,6 @@
+Ohai collects a list of automatic attributes at the start of each Chef
+Infra Client run. This list will vary from organization to organization,
+by server type, and by the platform that runs those servers. All the
+attributes collected by Ohai are unmodifiable by Chef Infra Client. Run
+the `ohai` command on a system to see which automatic attributes Ohai
+has collected for a particular node.
diff --git a/content/reusable/md/ohai_automatic_attribute.md b/content/reusable/md/ohai_automatic_attribute.md
new file mode 100644
index 0000000..d926482
--- /dev/null
+++ b/content/reusable/md/ohai_automatic_attribute.md
@@ -0,0 +1,64 @@
+An automatic attribute is a specific detail about a node, such as an IP
+address, a host name, or a list of loaded kernel modules.
+Automatic attributes are detected by Ohai and are then used by Chef
+Infra Client to ensure that they're handled properly during every Chef
+Infra Client run. The most commonly accessed automatic attributes are:
+
+
+
+
+
+
+
+
+
Attribute
+
Description
+
+
+
+
+
node['platform']
+
The platform on which a node is running. This attribute helps determine which providers will be used.
+
+
+
node['platform_family']
+
The platform family is a Chef Infra specific grouping of similar platforms where cookbook code can often be shared. For example, `rhel` includes Red Hat Linux, Oracle Linux, CentOS, and several other platforms that are almost identical to Red Hat Linux.
+
+
+
node['platform_version']
+
The version of the platform. This attribute helps determine which providers will be used.
+
+
+
node['ipaddress']
+
The IP address for a node. If the node has a default route, this is the IPV4 address for the interface. If the node doesn't have a default route, the value for this attribute should be nil. The IP address for default route is the recommended default value.
+
+
+
node['macaddress']
+
The MAC address for a node, determined by the same interface that detects the node['ipaddress'].
+
+
+
node['fqdn']
+
The fully qualified domain name for a node. This is used as the name of a node unless otherwise set.
+
+
+
node['hostname']
+
The host name for the node.
+
+
+
node['domain']
+
The domain for the node.
+
+
+
node['recipes']
+
A list of recipes associated with a node (and part of that node's run-list).
+
+
+
node['roles']
+
A list of roles associated with a node (and part of that node's run-list).
+
+
+
node['ohai_time']
+
The time at which Ohai was last run. This attribute isn't commonly used in recipes, but it's saved to Chef Infra Server and can be accessed using the knife status subcommand.
+
+
+
diff --git a/content/reusable/md/ohai_summary.md b/content/reusable/md/ohai_summary.md
new file mode 100644
index 0000000..4fa1188
--- /dev/null
+++ b/content/reusable/md/ohai_summary.md
@@ -0,0 +1,16 @@
+Ohai is a tool for collecting system configuration data, which it then provides to Chef Infra Client to use in cookbooks. Chef Infra Client runs Ohai at the start of every Chef Infra run to determine system state. The attributes that Ohai collects are called `automatic attributes`. Chef Infra Client uses these attributes to ensure that nodes are in the desired state after each configuration run.
+
+The types of attributes Ohai collects include but aren't limited to:
+
+- Operating System
+- Network
+- Memory
+- Disk
+- CPU
+- Kernel
+- Host names
+- Fully qualified domain names
+- Virtualization
+- Cloud provider metadata
+
+Ohai includes required and optional plugins to detect common configuration information. Ohai has a plugin model and language to write [custom plugins](/ohai_custom/) to collect additional system state information.
diff --git a/content/reusable/md/policy_summary.md b/content/reusable/md/policy_summary.md
new file mode 100644
index 0000000..b4946ed
--- /dev/null
+++ b/content/reusable/md/policy_summary.md
@@ -0,0 +1,13 @@
+Policy maps business and operational requirements, process, and workflow
+to the following settings and objects stored on Chef Infra Server:
+
+- Roles define server types, such as "web server" or "database server".
+- Environments define process, such as "dev", "staging", or "production".
+- Attributes define environment-specific details about a node that are included in a Policyfile.
+- Certain types of data---passwords, user account data, and other
+ sensitive items---can be placed in data bags, which are located in a
+ secure sub-area on Chef Infra Server that can only be accessed
+ by nodes that authenticate to Chef Infra Server with the correct
+ SSL certificates.
+- The cookbooks (and cookbook versions) in which organization-specific
+ configuration policies are maintained.
diff --git a/content/reusable/md/policyfile_chef_commands.md b/content/reusable/md/policyfile_chef_commands.md
new file mode 100644
index 0000000..b21ddaf
--- /dev/null
+++ b/content/reusable/md/policyfile_chef_commands.md
@@ -0,0 +1,2 @@
+The following commands are built into the `chef` executable and support
+the use of Policyfile files.
diff --git a/content/reusable/md/policyfile_lock_json.md b/content/reusable/md/policyfile_lock_json.md
new file mode 100644
index 0000000..1a36e30
--- /dev/null
+++ b/content/reusable/md/policyfile_lock_json.md
@@ -0,0 +1,12 @@
+When the `chef install` command is run, Chef Workstation caches any
+necessary cookbooks and emits a `Policyfile.lock.json` file that
+describes:
+
+- The versions of cookbooks in use
+- A hash of cookbook content
+- The source for all cookbooks
+- Attributes included with the Policyfile
+
+A `Policyfile.lock.json` file is associated with a specific policy
+group, which means it's associated with one (or more) nodes that use the same
+revision of a given policy.
diff --git a/content/reusable/md/policyfile_lock_json_example.md b/content/reusable/md/policyfile_lock_json_example.md
new file mode 100644
index 0000000..75d14f1
--- /dev/null
+++ b/content/reusable/md/policyfile_lock_json_example.md
@@ -0,0 +1,45 @@
+A `Policyfile.lock.json` file is similar to:
+
+```json
+{
+ "revision_id": "288ed244f8db8bff3caf58147e840bbe079f76e0",
+ "name": "jenkins",
+ "run_list": [
+ "recipe[java::default]",
+ "recipe[jenkins::master]",
+ "recipe[policyfile_demo::default]"
+ ],
+ "cookbook_locks": {
+ "policyfile_demo": {
+ "version": "0.1.0",
+ "identifier": "f04cc40faf628253fe7d9566d66a1733fb1afbe9",
+ "dotted_decimal_identifier": "67638399371010690.23642238397896298.25512023620585",
+ "source": "cookbooks/policyfile_demo",
+ "cache_key": null,
+ "scm_info": null,
+ "source_options": {
+ "path": "cookbooks/policyfile_demo"
+ }
+ },
+ "java": {
+ "version": "1.24.0",
+ "identifier": "4c24ae46a6633e424925c24e683e0f43786236a3",
+ "dotted_decimal_identifier": "21432429158228798.18657774985439294.16782456927907",
+ "cache_key": "java-1.24.0-supermarket.chef.io",
+ "origin": "https://supermarket.chef.io/api/v1/cookbooks/java/versions/1.24.0/download",
+ "source_options": {
+ "artifactserver": "https://supermarket.chef.io/api/v1/cookbooks/java/versions/1.24.0/download",
+ "version": "1.24.0"
+ }
+ "default_attributes": {
+ "audit": {
+ "reporter": [
+ "chef-server-automate",
+ "cli"
+ ]
+ }
+ },
+ "override_attributes": {
+
+ },
+```
diff --git a/content/reusable/md/policyfile_rb.md b/content/reusable/md/policyfile_rb.md
new file mode 100644
index 0000000..a7ebbd4
--- /dev/null
+++ b/content/reusable/md/policyfile_rb.md
@@ -0,0 +1,9 @@
+A Policyfile file allows you to specify in a single document the
+cookbook revisions and recipes that Chef Infra Client will apply. A
+Policyfile file is uploaded to Chef Infra Server, where it's
+associated with a group of nodes. When these nodes are configured during
+a Chef Infra Client run, Chef Infra Client will make decisions based on
+your Policyfile settings and will build a run-list based on that
+information. A Policyfile file may be versioned, and then promoted
+through deployment stages to safely and reliably deploy new
+configuration.
diff --git a/content/reusable/md/policyfile_rb_example.md b/content/reusable/md/policyfile_rb_example.md
new file mode 100644
index 0000000..1cd0f74
--- /dev/null
+++ b/content/reusable/md/policyfile_rb_example.md
@@ -0,0 +1,12 @@
+For example:
+
+```ruby
+name 'jenkins-master'
+run_list 'java', 'jenkins::master', 'recipe[policyfile_demo]'
+default_source :supermarket, 'https://mysupermarket.example'
+cookbook 'policyfile_demo', path: 'cookbooks/policyfile_demo'
+cookbook 'jenkins', '~> 8.2'
+cookbook 'mysql', github: 'sous-chefs/mysql', branch: 'master'
+default['stage']['mysql']['install_s3'] = 'https://s3-eu-west-1.amazonaws.com/example/stage/file.rpm'
+default['prod']['mysql']['install_s3'] = 'https://s3-eu-west-1.amazonaws.com/example/prod/file.rpm'
+```
diff --git a/content/reusable/md/policyfile_rb_settings.md b/content/reusable/md/policyfile_rb_settings.md
new file mode 100644
index 0000000..0e8f980
--- /dev/null
+++ b/content/reusable/md/policyfile_rb_settings.md
@@ -0,0 +1,280 @@
+A `Policyfile.rb` file may contain the following settings:
+
+
+
+`name "name"`
+
+: Required. The name of the policy. Use a name that reflects the
+ purpose of the machines against which the policy will run,
+ such as _application server_, _chat server_, or _load balancer_.
+
+`run_list "ITEM", "ITEM", ...`
+
+: Required. The run-list Chef Infra Client will use to apply the
+ policy to one (or more) nodes.
+
+`default_source :SOURCE_TYPE, *args`
+
+: The location in which any cookbooks not specified by `cookbook` are
+ located.
+
+ Possible values for `:SOURCE_TYPE` are:
+
+ - `:artifactory`
+ - `:chef_repo`
+ - `:chef_server`
+ - `:supermarket`
+
+ `:artifactory`
+ : Pulls cookbooks from an Artifactory server.
+
+ For example, `default_source :artifactory, "https://artifactory.example/api/chef/my-supermarket"`.
+
+ There are two ways to authenticate with the Artifactory server:
+
+ - **API key**: Set `artifactory_api_key` in config.rb or use the `ARTIFACTORY_API_KEY` environment variable.
+ - **Identity token**: Set `artifactory_identity_token` in config.rb or use the `ARTIFACTORY_IDENTITY_TOKEN` environment variable.
+
+ The Artifactory identity token is new in Chef Workstation v24.11.
+
+ **Note**: If both `ARTIFACTORY_API_KEY` and `ARTIFACTORY_IDENTITY_TOKEN` are set, `ARTIFACTORY_IDENTITY_TOKEN` takes precedence.
+
+ `:chef_repo`
+ : Pulls cookbooks from a monolithic cookbook repository. This may be a path to the top-level
+ of a cookbook repository or to the `/cookbooks` directory within that repository.
+
+ For example, `default_source :chef_repo, "path/to/repo"`.
+
+ `:chef_server`
+ : Pulls cookbooks from Chef Infra Server.
+
+ For example, `default_source :chef_server, "https://chef-server.example/organizations/example"`.
+
+ `:supermarket`
+
+ : Pulls cookbooks from the public Chef Supermarket or a private Chef Supermarket.
+
+ By default `:supermarket` pulls cookbooks from the public Chef
+ Supermarket. For example, `default_source :supermarket`.
+
+ Specify the Supermarket URL to pull cookbooks from a private Supermarket. For example,
+ `default_source :supermarket, "https://supermarket-name.example"`.
+
+ You can specify multiple cookbook sources. For example from the
+ public Chef Supermarket and a monolithic repository:
+
+ ```ruby
+ default_source :supermarket
+ default_source :chef_repo, 'path/to/repo'
+ ```
+
+ or from both a public and private Chef Supermarket:
+
+ ```ruby
+ default_source :supermarket
+ default_source :supermarket, 'https://supermarket.example'
+ ```
+
+
+
Note
+
+
+ If a run-list or any dependencies require a cookbook that's present
+ in more than one source, be explicit about which source is
+ preferred. This will ensure that a cookbook is always pulled from an
+ expected source. For example, an internally-developed cookbook named
+ `chef-client` will conflict with the public `chef-client` cookbook
+ that's maintained by Chef. To specify a named source for a
+ cookbook:
+
+ ```ruby
+ default_source :supermarket
+ default_source :supermarket, 'https://supermarket.example' do |s|
+ s.preferred_for 'chef-client'
+ end
+ ```
+
+ List multiple cookbooks on the same line:
+
+ ```ruby
+ default_source :supermarket
+ default_source :supermarket, 'https://supermarket.example' do |s|
+ s.preferred_for 'chef-client', 'nginx', 'mysql'
+ end
+ ```
+
+
+
+
+`cookbook "NAME" [, "VERSION_CONSTRAINT"] [, SOURCE_OPTIONS]`
+
+: Add cookbooks to the policy, specify a version constraint, or
+ specify an alternate source location, such as Chef Supermarket. For
+ example, add a cookbook:
+
+ ```ruby
+ cookbook 'apache2'
+ ```
+
+ Specify a version constraint:
+
+ ```ruby
+ run_list 'jenkins::master'
+
+ # Restrict the jenkins cookbook to version 2.x, greater than 2.1
+ cookbook 'jenkins', '~> 2.1'
+ ```
+
+ Specify an alternate source:
+
+ ```ruby
+ cookbook 'my_app', path: 'cookbooks/my_app'
+ ```
+
+ or:
+
+ ```ruby
+ cookbook 'mysql', github: 'opscode-cookbooks/mysql', branch: 'master'
+ ```
+
+ or:
+
+ ```ruby
+ cookbook 'chef-ingredient', git: 'https://github.com/chef-cookbooks/chef-ingredient.git', tag: 'v0.12.0'
+ ```
+
+`named_run_list "NAME", "ITEM1", "ITEM2", ...`
+
+: Specify a named run-list to be used as an alternative to the
+ override run-list. This setting should be used carefully and for
+ specific use cases, like running a small set of recipes to quickly
+ converge configuration for a single application on a host or for
+ one-time setup tasks. For example:
+
+ ```ruby
+ named_run_list :update_app, 'my_app_cookbook::default'
+ ```
+
+`include_policy "NAME", *args`
+
+: Specify a Policyfile lock to be merged with this policy. Chef
+ Workstation supports pulling this lock from a local or remote file,
+ from a Chef Infra Server, or from a git repository. When the
+ Policyfile lock is included, its run-list will appear before the
+ current Policyfile's run-list. This setting requires that the solved
+ cookbooks appear as-is from the included Policyfile lock. If
+ conflicting attributes or cookbooks are provided, an error will be
+ presented. See
+ [RFC097](https://github.com/chef-boneyard/chef-rfc/blob/master/rfc097-policyfile-includes.md)
+ for the full specifications of this feature.
+
+ Pull the Policyfile lock from `./NAME.lock.json`:
+
+ ```ruby
+ include_policy 'NAME', path: '.'
+ ```
+
+ Pull the Policyfile lock from `./foo.lock.json`.
+
+ ```ruby
+ include_policy 'NAME', path: './foo.lock.json'
+ ```
+
+ Pull the Policyfile lock `foo.lock.json` from the `example/foo` Git repository on the `git.example.com` Git server.
+
+ ```ruby
+ include_policy 'NAME', git: 'https://git.example.com/example/foo', path: 'foo.lock.json'
+ ```
+
+ Pull the Policyfile lock from `./bar.lock.json` with revision ID
+ 'revision1'.
+
+ ```ruby
+ include_policy 'NAME', policy_revision_id: 'revision1', path: './bar.lock.json'
+ ```
+
+ Pull the Policyfile lock from a remote server
+ `https://internal.example.com/foo.lock.json`.
+
+ ```ruby
+ include_policy 'NAME', remote: 'https://internal.example.com/foo.lock.json'
+ ```
+
+ Pull the Policyfile lock from a remote server
+ `https://internal.example.com/bar.lock.json` and with revision ID
+ 'revision1'.
+
+ ```ruby
+ include_policy 'NAME', policy_revision_id: 'revision1', remote: 'https://internal.example.com/foo.lock.json'
+ ```
+
+ Pull the policy `NAME` with revision ID `revision1` from the
+ `http://chef-server.example` Chef Infra Server:
+
+ ```ruby
+ include_policy 'NAME', policy_revision_id: 'revision1', server: 'http://chef-server.example'
+ ```
+
+ Pull the policy `foo` with revision ID `revision1`:
+
+ ```ruby
+ include_policy 'NAME', policy_name: 'foo', policy_revision_id: 'revision1', server: 'http://chef-server.example'
+ ```
+
+ Pull and lock the current revision for policy `foo` in policy group
+ `prod`:
+
+ ```ruby
+ include_policy 'NAME', policy_name: 'foo', policy_group: 'prod', server: 'http://chef-server.example'
+ ```
+
+`ATTRIBUTE_TYPE['attribute'] = 'value'`
+
+: Specify one or more attributes to be included with the policy.
+ This is similar to defining attributes using roles.
+
+ Possible values for `ATTRIBUTE_TYPE` are:
+
+ - `default`
+ - `override`
+
+ `default`
+ : A `default` attribute is automatically reset at the start of every Chef
+ Infra Client run and has the lowest attribute precedence.
+
+ For example:
+
+ ```ruby
+ default['attribute'] = 'value'
+ default['attribute']['level2'] = 'another_value'
+ ```
+
+ `override`
+ : An `override` attribute is automatically reset at the start of every
+ Chef Infra Client run and has a higher attribute precedence than
+ a `default` attribute.
+
+ ```ruby
+ override['attribute'] = 'value'
+ override['attribute']['level2'] = 'another_value'
+ ```
+
+ Attribute hoisting allows you to define attributes by policy group.
+
+ Use the following syntax to define policy group-specific attributes:
+
+ ```ruby
+ ATTRIBUTE_TYPE['POLICY_GROUP']['attribute'] = 'value'
+ ```
+
+ where:
+
+ - `ATTRIBUTE_TYPE` is either `default` or `override` as described above.
+ - `POLICY_GROUP` is a user-defined policy group, such as "dev", "test" "staging", or "production".
+
+ In the following example, the value of `default['attribute']` is set to either `dev_value` or `prod_value` depending on the policy group.
+
+ ```ruby
+ default['dev']['attribute'] = 'dev_value'
+ default['prod']['attribute'] = 'prod_value'
+ ```
diff --git a/content/reusable/md/policyfile_rb_syntax.md b/content/reusable/md/policyfile_rb_syntax.md
new file mode 100644
index 0000000..6253893
--- /dev/null
+++ b/content/reusable/md/policyfile_rb_syntax.md
@@ -0,0 +1,10 @@
+A `Policyfile.rb` is a Ruby file in which run-list and cookbook
+locations are specified. The syntax is as follows:
+
+```ruby
+name "name"
+run_list "ITEM", "ITEM", ...
+default_source :SOURCE_TYPE, *args
+cookbook "NAME" [, "VERSION_CONSTRAINT"] [, SOURCE_OPTIONS]
+ATTRIBUTE_TYPE['attribute'] = 'value'
+```
diff --git a/content/reusable/md/policyfile_summary.md b/content/reusable/md/policyfile_summary.md
new file mode 100644
index 0000000..1e310a8
--- /dev/null
+++ b/content/reusable/md/policyfile_summary.md
@@ -0,0 +1 @@
+A Policyfile is a way to create immutable collections of cookbooks, cookbook dependencies, and attributes defined in a single document that's uploaded to Chef Infra Server. The Policyfile is then associated with a group of nodes. When these nodes perform a Chef Infra Client run, they utilize recipes specified in the Policyfile.
diff --git a/content/reusable/md/proxy_env.md b/content/reusable/md/proxy_env.md
new file mode 100644
index 0000000..fbf2661
--- /dev/null
+++ b/content/reusable/md/proxy_env.md
@@ -0,0 +1,23 @@
+If `http_proxy`, `https_proxy`, `ftp_proxy`, or `no_proxy` is set in the
+client.rb file but not set in the `ENV`, Chef Infra Client will
+configure the `ENV` variable based on these (and related) settings. For
+example:
+
+```ruby
+http_proxy 'http://proxy.example.org:8080'
+http_proxy_user 'myself'
+http_proxy_pass 'Password1'
+```
+
+Or an alternative way to define the proxy (if the previous version does
+not work):
+
+```ruby
+http_proxy 'http://myself:Password1@proxy.example.org:8080'
+```
+
+will be set to:
+
+```ruby
+ENV['http_proxy'] = 'http://myself:Password1@proxy.example.org:8080'
+```
diff --git a/content/reusable/md/proxy_windows.md b/content/reusable/md/proxy_windows.md
new file mode 100644
index 0000000..843654b
--- /dev/null
+++ b/content/reusable/md/proxy_windows.md
@@ -0,0 +1,13 @@
+To determine the current proxy server on the Windows platform:
+
+1. Open **Internet Properties**.
+1. Open **Connections**.
+1. Open **LAN settings**.
+1. View the **Proxy server** setting. If this setting is blank, then a proxy server may not be available.
+
+To configure proxy settings in Windows:
+
+1. Open **System Properties**.
+1. Open **Environment Variables**.
+1. Open **System variables**.
+1. Set `http_proxy` and `https_proxy` to the location of your proxy server. This value **MUST** be lowercase.
diff --git a/content/reusable/md/resource_before_notification_restart.md b/content/reusable/md/resource_before_notification_restart.md
new file mode 100644
index 0000000..4ee995e
--- /dev/null
+++ b/content/reusable/md/resource_before_notification_restart.md
@@ -0,0 +1,13 @@
+This example uses the `:before` notification to restart the `php-fpm`
+service before restarting `nginx`:
+
+```ruby
+service 'nginx' do
+ action :restart
+ notifies :restart, 'service[php-fpm]', :before
+end
+```
+
+With the `:before` notification, the action specified for the `nginx`
+resource won't run until action has been taken on the notified
+resource (`php-fpm`).
diff --git a/content/reusable/md/resource_execute_command_from_template.md b/content/reusable/md/resource_execute_command_from_template.md
new file mode 100644
index 0000000..e4d8bc7
--- /dev/null
+++ b/content/reusable/md/resource_execute_command_from_template.md
@@ -0,0 +1,22 @@
+The following example shows how to set up IPv4 packet forwarding using
+the **execute** resource to run a command named `forward_ipv4` that uses
+a template defined by the **template** resource:
+
+```ruby
+execute 'forward_ipv4' do
+ command 'echo > /proc/.../ipv4/ip_forward'
+ action :nothing
+end
+
+template '/etc/file_name.conf' do
+ source 'routing/file_name.conf.erb'
+ notifies :run, 'execute[forward_ipv4]', :delayed
+end
+```
+
+where the `command` property for the **execute** resource contains the
+command that's to be run and the `source` property for the **template**
+resource specifies which template to use. The `notifies` property for
+the **template** specifies that the `execute[forward_ipv4]` (which is
+defined by the **execute** resource) should be queued up and run at the
+end of a Chef Infra Client run.
diff --git a/content/reusable/md/resource_execute_notifies_specific_order.md b/content/reusable/md/resource_execute_notifies_specific_order.md
new file mode 100644
index 0000000..81c7d9d
--- /dev/null
+++ b/content/reusable/md/resource_execute_notifies_specific_order.md
@@ -0,0 +1,28 @@
+To notify multiple resources, and then have these resources run in a
+certain order, do something like the following:
+
+```ruby
+execute 'foo' do
+ command '...'
+ notifies :create, 'template[baz]', :immediately
+ notifies :install, 'package[bar]', :immediately
+ notifies :run, 'execute[final]', :immediately
+end
+
+template 'baz' do
+ ...
+ notifies :run, 'execute[restart_baz]', :immediately
+end
+
+package 'bar'
+
+execute 'restart_baz'
+
+execute 'final' do
+ command '...'
+end
+```
+
+where the sequencing will be in the same order as the resources are
+listed in the recipe: `execute 'foo'`, `template 'baz'`,
+`execute [restart_baz]`, `package 'bar'`, and `execute 'final'`.
diff --git a/content/reusable/md/resource_execute_subscribes_prevent_restart_and_reconfigure.md b/content/reusable/md/resource_execute_subscribes_prevent_restart_and_reconfigure.md
new file mode 100644
index 0000000..6c55b14
--- /dev/null
+++ b/content/reusable/md/resource_execute_subscribes_prevent_restart_and_reconfigure.md
@@ -0,0 +1,11 @@
+Use the `:nothing` action (common to all resources) to prevent the test
+from starting automatically, and then use the `subscribes` notification
+to run a configuration test when a change to the template is detected:
+
+```ruby
+execute 'test-nagios-config' do
+ command 'nagios3 --verify-config'
+ action :nothing
+ subscribes :run, 'template[/etc/nagios3/configures-nagios.conf]', :immediately
+end
+```
diff --git a/content/reusable/md/resource_log_properties.md b/content/reusable/md/resource_log_properties.md
new file mode 100644
index 0000000..d4f9a64
--- /dev/null
+++ b/content/reusable/md/resource_log_properties.md
@@ -0,0 +1,16 @@
+The log resource has the following properties:
+
+`level`
+
+: **Ruby Type:** Symbol \| **Default Value:** `:info`
+
+ The logging level for displaying this message. Options (in order of
+ priority): `:debug`, `:info`, `:warn`, `:error`, and `:fatal`.
+
+`message`
+
+: **Ruby Type:** String \| **Default Value:**
+ `The resource block's name`
+
+ The message to be added to a log file. Default value: the `name` of
+ the resource block. See "Syntax" section above for more information.
diff --git a/content/reusable/md/resource_log_set_debug.md b/content/reusable/md/resource_log_set_debug.md
new file mode 100644
index 0000000..2d630de
--- /dev/null
+++ b/content/reusable/md/resource_log_set_debug.md
@@ -0,0 +1,5 @@
+```ruby
+log 'a debug string' do
+ level :debug
+end
+```
diff --git a/content/reusable/md/resource_log_syntax.md b/content/reusable/md/resource_log_syntax.md
new file mode 100644
index 0000000..61335f3
--- /dev/null
+++ b/content/reusable/md/resource_log_syntax.md
@@ -0,0 +1,28 @@
+A **log** resource block adds messages to the log file based on events
+that occur during a Chef Infra Client run:
+
+```ruby
+log 'message' do
+ message 'A message add to the log.'
+ level :info
+end
+```
+
+The full syntax for all of the properties that are available to the
+**log** resource is:
+
+```ruby
+log 'name' do
+ level Symbol # default value: :info
+ message String # default value: 'name' unless specified
+ action Symbol # defaults to :write if not specified
+end
+```
+
+where:
+
+- `log` is the resource.
+- `name` is the name given to the resource block.
+- `action` identifies which steps Chef Infra Client will take to bring
+ the node into the desired state.
+- `level` and `message` are the properties available to this resource.
diff --git a/content/reusable/md/resource_package_use_ignore_failure_attribute.md b/content/reusable/md/resource_package_use_ignore_failure_attribute.md
new file mode 100644
index 0000000..b9c5115
--- /dev/null
+++ b/content/reusable/md/resource_package_use_ignore_failure_attribute.md
@@ -0,0 +1,6 @@
+```ruby
+gem_package 'syntax' do
+ action :install
+ ignore_failure true
+end
+```
diff --git a/content/reusable/md/resource_remote_file_transfer_remote_source_changes.md b/content/reusable/md/resource_remote_file_transfer_remote_source_changes.md
new file mode 100644
index 0000000..e09dcb8
--- /dev/null
+++ b/content/reusable/md/resource_remote_file_transfer_remote_source_changes.md
@@ -0,0 +1,16 @@
+```ruby
+remote_file '/tmp/couch.png' do
+ source 'http://couchdb.apache.org/img/sketch.png'
+ action :nothing
+end
+
+http_request 'HEAD http://couchdb.apache.org/img/sketch.png' do
+ message ''
+ url 'http://couchdb.apache.org/img/sketch.png'
+ action :head
+ if ::File.exist?('/tmp/couch.png')
+ headers 'If-Modified-Since' => File.mtime('/tmp/couch.png').httpdate
+ end
+ notifies :create, 'remote_file[/tmp/couch.png]', :immediately
+end
+```
diff --git a/content/reusable/md/resource_service_restart_and_notify.md b/content/reusable/md/resource_service_restart_and_notify.md
new file mode 100644
index 0000000..a92dc78
--- /dev/null
+++ b/content/reusable/md/resource_service_restart_and_notify.md
@@ -0,0 +1,9 @@
+The following example shows how start a service named `example_service`
+and immediately notify the Nginx service to restart.
+
+```ruby
+service 'example_service' do
+ action :start
+ notifies :restart, 'service[nginx]', :immediately
+end
+```
diff --git a/content/reusable/md/resource_service_subscribes_reload_using_template.md b/content/reusable/md/resource_service_subscribes_reload_using_template.md
new file mode 100644
index 0000000..a4ede04
--- /dev/null
+++ b/content/reusable/md/resource_service_subscribes_reload_using_template.md
@@ -0,0 +1,18 @@
+To reload a service that's based on a template, use the **template**
+and **service** resources together in the same recipe, similar to the
+following:
+
+```ruby
+template '/tmp/somefile' do
+ mode '0755'
+ source 'somefile.erb'
+end
+
+service 'apache' do
+ action :enable
+ subscribes :reload, 'template[/tmp/somefile]', :immediately
+end
+```
+
+where the `subscribes` notification is used to reload the service
+whenever the template is modified.
diff --git a/content/reusable/md/resource_service_use_nothing_action.md b/content/reusable/md/resource_service_use_nothing_action.md
new file mode 100644
index 0000000..dbaecc2
--- /dev/null
+++ b/content/reusable/md/resource_service_use_nothing_action.md
@@ -0,0 +1,5 @@
+```ruby
+service 'memcached' do
+ action :nothing
+end
+```
diff --git a/content/reusable/md/resource_service_use_retries_properties.md b/content/reusable/md/resource_service_use_retries_properties.md
new file mode 100644
index 0000000..492b678
--- /dev/null
+++ b/content/reusable/md/resource_service_use_retries_properties.md
@@ -0,0 +1,7 @@
+```ruby
+service 'apache' do
+ action [ :enable, :start ]
+ retries 3
+ retry_delay 5
+end
+```
diff --git a/content/reusable/md/resource_template_library_module.md b/content/reusable/md/resource_template_library_module.md
new file mode 100644
index 0000000..4eb0b63
--- /dev/null
+++ b/content/reusable/md/resource_template_library_module.md
@@ -0,0 +1,10 @@
+A template helper module can be defined in a library. This is useful
+when extensions need to be reused across recipes or to make it easier to
+manage code that would otherwise be defined inline for each recipe
+basis.
+
+```ruby
+template '/path/to/template.erb' do
+ helpers(MyHelperModule)
+end
+```
diff --git a/content/reusable/md/resource_template_notifies_delay.md b/content/reusable/md/resource_template_notifies_delay.md
new file mode 100644
index 0000000..1165ca1
--- /dev/null
+++ b/content/reusable/md/resource_template_notifies_delay.md
@@ -0,0 +1,6 @@
+```ruby
+template '/etc/nagios3/configures-nagios.conf' do
+ # other parameters
+ notifies :run, 'execute[test-nagios-config]', :delayed
+end
+```
diff --git a/content/reusable/md/resource_template_notifies_multiple_resources.md b/content/reusable/md/resource_template_notifies_multiple_resources.md
new file mode 100644
index 0000000..3d439a3
--- /dev/null
+++ b/content/reusable/md/resource_template_notifies_multiple_resources.md
@@ -0,0 +1,10 @@
+```ruby
+template '/etc/chef/server.rb' do
+ source 'server.rb.erb'
+ owner 'root'
+ group 'root'
+ mode '0755'
+ notifies :restart, 'service[chef-elasticsearch]', :delayed
+ notifies :restart, 'service[chef-server]', :delayed
+end
+```
diff --git a/content/reusable/md/resource_template_notifies_reload_service.md b/content/reusable/md/resource_template_notifies_reload_service.md
new file mode 100644
index 0000000..921b099
--- /dev/null
+++ b/content/reusable/md/resource_template_notifies_reload_service.md
@@ -0,0 +1,7 @@
+```ruby
+template '/tmp/somefile' do
+ mode '0755'
+ source 'somefile.erb'
+ notifies :reload, 'service[apache]', :immediately
+end
+```
diff --git a/content/reusable/md/resource_template_notifies_restart_service_when_template_modified.md b/content/reusable/md/resource_template_notifies_restart_service_when_template_modified.md
new file mode 100644
index 0000000..d5b7281
--- /dev/null
+++ b/content/reusable/md/resource_template_notifies_restart_service_when_template_modified.md
@@ -0,0 +1,5 @@
+```ruby
+template '/etc/www/configures-apache.conf' do
+ notifies :restart, 'service[apache]', :immediately
+end
+```
diff --git a/content/reusable/md/resource_template_notifies_run_immediately.md b/content/reusable/md/resource_template_notifies_run_immediately.md
new file mode 100644
index 0000000..02aa12d
--- /dev/null
+++ b/content/reusable/md/resource_template_notifies_run_immediately.md
@@ -0,0 +1,19 @@
+By default, notifications are `:delayed`, that's they're queued up as
+they're triggered, and then executed at the end of a Chef Infra
+Client run. To run an action immediately, use `:immediately`:
+
+```ruby
+template '/etc/nagios3/configures-nagios.conf' do
+ # other parameters
+ notifies :run, 'execute[test-nagios-config]', :immediately
+end
+```
+
+and then Chef Infra Client would immediately run the following:
+
+```ruby
+execute 'test-nagios-config' do
+ command 'nagios3 --verify-config'
+ action :nothing
+end
+```
diff --git a/content/reusable/md/resource_template_notifies_send_notifications_to_multiple_resources.md b/content/reusable/md/resource_template_notifies_send_notifications_to_multiple_resources.md
new file mode 100644
index 0000000..0bd87a3
--- /dev/null
+++ b/content/reusable/md/resource_template_notifies_send_notifications_to_multiple_resources.md
@@ -0,0 +1,13 @@
+To send notifications to multiple resources, just use multiple
+attributes. Multiple attributes will get sent to the notified resources
+in the order specified.
+
+```ruby
+template '/etc/netatalk/netatalk.conf' do
+ notifies :restart, 'service[afpd]', :immediately
+ notifies :restart, 'service[cnid]', :immediately
+end
+
+service 'afpd'
+service 'cnid'
+```
diff --git a/content/reusable/md/resource_template_use_relative_paths.md b/content/reusable/md/resource_template_use_relative_paths.md
new file mode 100644
index 0000000..77864f9
--- /dev/null
+++ b/content/reusable/md/resource_template_use_relative_paths.md
@@ -0,0 +1,6 @@
+```ruby
+template "#{ENV['HOME']}/chef-getting-started.txt" do
+ source 'chef-getting-started.txt.erb'
+ mode '0755'
+end
+```
diff --git a/content/reusable/md/resources_common.md b/content/reusable/md/resources_common.md
new file mode 100644
index 0000000..6979408
--- /dev/null
+++ b/content/reusable/md/resources_common.md
@@ -0,0 +1,9 @@
+A resource is a statement of configuration policy that:
+
+- Describes the desired state for a configuration item
+- Declares the steps needed to bring that item to the desired state
+- Specifies a resource type---such as `package`, `template`, or
+ `service`
+- Lists additional details (also known as resource properties), as
+ necessary
+- Are grouped into recipes, which describe working configurations
diff --git a/content/reusable/md/resources_common_actions_nothing.md b/content/reusable/md/resources_common_actions_nothing.md
new file mode 100644
index 0000000..45131b5
--- /dev/null
+++ b/content/reusable/md/resources_common_actions_nothing.md
@@ -0,0 +1,3 @@
+This resource block doesn't act unless notified by another resource to
+take action. Once notified, this resource block either runs immediately
+or is queued up to run at the end of a Chef Infra Client run.
diff --git a/content/reusable/md/resources_common_atomic_update.md b/content/reusable/md/resources_common_atomic_update.md
new file mode 100644
index 0000000..3136dc9
--- /dev/null
+++ b/content/reusable/md/resources_common_atomic_update.md
@@ -0,0 +1,26 @@
+Atomic updates are used with **file**-based resources to help ensure
+that file updates can be made when updating a binary or if disk space
+runs out.
+
+Atomic updates are enabled by default. They can be managed globally
+using the `file_atomic_update` setting in the `client.rb` file. They can
+be managed for each resource using the `atomic_update` property
+that's available with the **cookbook_file**, **file**,
+**remote_file**, and **template** resources.
+
+
+
+
+
Note
+
+
+On certain platforms, and after a file has been moved into place, Chef
+Infra Client may modify file permissions to support features specific to
+those platforms. On platforms with SELinux enabled, Chef Infra Client
+will fix up the security contexts after a file has been moved into the
+correct location by running the `restorecon` command. On the Microsoft
+Windows platform, Chef Infra Client will create files so that ACL
+inheritance works as expected.
+
+
+
diff --git a/content/reusable/md/resources_common_compile.md b/content/reusable/md/resources_common_compile.md
new file mode 100644
index 0000000..fc67342
--- /dev/null
+++ b/content/reusable/md/resources_common_compile.md
@@ -0,0 +1,28 @@
+Chef Infra Client processes recipes in two phases:
+
+
+
+1. First, each resource in the node object is identified and a resource
+ collection is built. All recipes are loaded in a specific order, and
+ then the actions specified within each of them are identified. This
+ is also referred to as the "compile phase".
+1. Next, Chef Infra Client configures the system based on the order of
+ the resources in the resource collection. Each resource then
+ examines the node and performs the necessary steps to complete the
+ action. This is also referred to as the "execution phase".
+
+Typically, actions are processed during the execution phase of a Chef
+Infra Client run. However, sometimes it's necessary to run an action
+during the compile phase. For example, a resource can be configured to
+install a package during the compile phase to ensure that application is
+available to other resources during the execution phase.
+
+
+
Note
+
+
+Use the **chef_gem** resource to install gems that are needed by Chef
+Infra Client during the execution phase.
+
+
+
diff --git a/content/reusable/md/resources_common_compile_begin.md b/content/reusable/md/resources_common_compile_begin.md
new file mode 100644
index 0000000..399f600
--- /dev/null
+++ b/content/reusable/md/resources_common_compile_begin.md
@@ -0,0 +1,159 @@
+Use `.run_action(:some_action)` at the end of a resource block to run
+the specified action during the compile phase. For example:
+
+```ruby
+build_essential 'Install compilers' do
+ action :nothing
+end.run_action(:install)
+```
+
+where `action` is set to `:nothing` to ensure the `run_action` is run
+during the compile phase and not later during the execution phase.
+
+This can be simplified by using the `compile_time` flag in Chef Infra
+Client 16 and later versions:
+
+```ruby
+build_essential 'Install compilers' do
+ compile_time true
+end
+```
+
+That flag both forces the resource to run at compile time and sets the
+converge action to `:nothing`.
+
+The following examples show when (and when not) to use `run_action`.
+
+
+
+**Using Custom Resources preferred to forcing to compile time**
+
+Compile time execution is often used to install gems before requiring
+them in recipe code.
+
+This is a poor pattern since gems may depend on native gems which
+may require installing compilers at compile time.
+
+```ruby
+build_essential 'Install compilers' do
+ compile_time true
+end
+
+chef_gem 'aws-dsk' do
+ compile_time true
+end
+
+require 'aws-sdk'
+```
+
+A better strategy is to move the code, which requires the gem, into
+a custom resource. Since all the actions of custom resources run
+at converge time, this defers requiring
+the gem until later in the overall Chef Infra Client execution. [Unified
+mode](/unified_mode/) can also be used in the resource to eliminate compile/converge
+mode issues entirely:
+
+```ruby
+unified_mode true
+
+action :run do
+ build_essential 'Install compilers'
+
+ chef_gem 'aws-sdk'
+
+ require 'aws-sdk'
+end
+```
+
+**Download and parse a configuration file**
+
+A common use case is to download a configuration file, parse it, and then
+use the values in templates and to control other configuration.
+
+An important distinction to make is that the downloaded configuration file
+only exists in a temporary state to be used by the Chef Infra Client. It will
+not be used directly by the system or applications that are managed by the
+Chef Infra Client.
+
+To download and parse a JSON file and render it in a template, it makes sense
+to download the file during compile time:
+
+```ruby
+ # the remote_file is being downloaded to a temporary file
+ remote_file "#{Chef::Config[:file_cache_path]}/users.json" do
+ source "https://jsonplaceholder.typicode.com/users"
+ compile_time true
+ end
+
+ # this parsing needs to happen after the remote_file is downloaded, but will
+ # be executed at compile time.
+ array = JSON.parse(IO.read("#{Chef::Config[:file_cache_path]}/users.json")
+
+ # the `array.last["phone"]` expression here will also be evaluated at compile
+ # time and must be lazied using wrapping the expresssion in `lazy {}`
+ file "/tmp/phone_number.txt" do
+ content array.last["phone"]
+ end
+```
+
+This is considerably cleaner than the alternative of lazy evaluating both the parsing of the
+JSON and the rendering of the data into the file template, which will happen if
+the `remote_file` resource isn't run at compile time:
+
+```ruby
+ # the execution of this is now deferred
+ remote_file "#{Chef::Config[:file_cache_path]}/users.json" do
+ source "https://jsonplaceholder.typicode.com/users"
+ end
+
+ # it's necessary due to lexical scoping issues to create this variable here
+ array = nil
+
+ # the parsing of the JSON is now deferred due to the ruby_block
+ ruby_block "parse JSON" do
+ block do
+ array = JSON.parse(IO.read("#{Chef::Config[:file_cache_path]}/users.json")
+ end
+ end
+
+ # the argument to the content property must now also be deferred
+ file "/tmp/phone_number.txt" do
+ content lazy { array.last["phone"] }
+ end
+```
+
+This is an example of code that overuses deferred execution, uses more "lazy" evaluation, and is
+considerably harder to understand and write correctly.
+
+**Notifications won't work**
+
+Resources that are executed during the compile phase can't notify other
+resources. For example:
+
+```ruby
+execute 'ifconfig'
+
+package 'vim-enhanced' do
+ compile_time true
+ notifies :run, 'execute[ifconfig]', :immediately
+end
+```
+
+A better approach in this type of situation is to install the package
+before the resource collection is built to ensure that it's available
+to other resources later on.
+
+The best approach to this problem is to use [`unified mode`](/unified_mode/), which eliminates
+the compile time and converge time distinction while allowing notifications
+to work correctly.
+
+**Resources that are forced to compile time by default**
+
+The `ohai_hint` and `hostname` resources run at compile time by default.
+
+This is due to the fact that later resources may consume the node attributes which
+are set by those resources leading to excessive use of `lazy` in subsequent
+resources (and similar issues to the `remote_file` example above).
+
+The `chef_gem` resource used to execute at compile time by default, but now we
+recommend that users move code that executes at compile time to custom resources.
diff --git a/content/reusable/md/resources_common_guard_interpreter.md b/content/reusable/md/resources_common_guard_interpreter.md
new file mode 100644
index 0000000..7f1cb4b
--- /dev/null
+++ b/content/reusable/md/resources_common_guard_interpreter.md
@@ -0,0 +1,4 @@
+Any resource that passes a string command may also specify the
+interpreter that will be used to evaluate that string command. This is
+done by using the `guard_interpreter` property to specify a
+**script**-based resource.
diff --git a/content/reusable/md/resources_common_guard_interpreter_attributes.md b/content/reusable/md/resources_common_guard_interpreter_attributes.md
new file mode 100644
index 0000000..90d8fb6
--- /dev/null
+++ b/content/reusable/md/resources_common_guard_interpreter_attributes.md
@@ -0,0 +1,38 @@
+The `guard_interpreter` property may be set to any of the following
+values:
+
+`:bash`
+
+: Evaluates a string command using the **bash** resource.
+
+`:batch`
+
+: Evaluates a string command using the **batch** resource. Default
+ value (within a **batch** resource block): `:batch`.
+
+`:csh`
+
+: Evaluates a string command using the **csh** resource.
+
+`:default`
+
+: Default. Executes the default interpreter as identified by Chef
+ Infra Client.
+
+`:perl`
+
+: Evaluates a string command using the **perl** resource.
+
+`:powershell_script`
+
+: Evaluates a string command using the **powershell_script**
+ resource. Default value (within a **powershell_script** resource block):
+ `:powershell_script`.
+
+`:python`
+
+: Evaluates a string command using the **python** resource.
+
+`:ruby`
+
+: Evaluates a string command using the **ruby** resource.
diff --git a/content/reusable/md/resources_common_guard_interpreter_attributes_inherit.md b/content/reusable/md/resources_common_guard_interpreter_attributes_inherit.md
new file mode 100644
index 0000000..ac38d4e
--- /dev/null
+++ b/content/reusable/md/resources_common_guard_interpreter_attributes_inherit.md
@@ -0,0 +1,66 @@
+The `guard_interpreter` property is set to `:default` by default for the
+**bash**, **csh**, **perl**, **python**, and **ruby** resources. When
+the `guard_interpreter` property is set to `:default`, `not_if` or
+`only_if` guard statements **don't inherit** properties that are
+defined by the **script**-based resource.
+
+
+
+
+
Warning
+
+
+The **batch** and **powershell_script** resources inherit properties by
+default. The `guard_interpreter` property is set to `:batch` or
+`:powershell_script` automatically when using a `not_if` or `only_if`
+guard statement within a **batch** or **powershell_script** resource,
+respectively.
+
+
+
+For example, the `not_if` guard statement in the following resource
+example **doesn't inherit** the `environment` property:
+
+```ruby
+bash 'javatooling' do
+ environment 'JAVA_HOME' => '/usr/lib/java/jdk1.7/home'
+ code 'java-based-daemon-ctl.sh -start'
+ not_if 'java-based-daemon-ctl.sh -test-started'
+end
+```
+
+and requires adding the `environment` property to the `not_if` guard
+statement so that it may use the `JAVA_HOME` path as part of its
+evaluation:
+
+```ruby
+bash 'javatooling' do
+ environment 'JAVA_HOME' => '/usr/lib/java/jdk1.7/home'
+ code 'java-based-daemon-ctl.sh -start'
+ not_if 'java-based-daemon-ctl.sh -test-started', :environment => 'JAVA_HOME' => '/usr/lib/java/jdk1.7/home'
+end
+```
+
+To inherit properties, add the `guard_interpreter` property to the
+resource block and set it to the appropriate value:
+
+- `:bash` for **bash**
+- `:csh` for **csh**
+- `:perl` for **perl**
+- `:python` for **python**
+- `:ruby` for **ruby**
+
+For example, using the same example as from above, but this time adding
+the `guard_interpreter` property and setting it to `:bash`:
+
+```ruby
+bash 'javatooling' do
+ guard_interpreter :bash
+ environment 'JAVA_HOME' => '/usr/lib/java/jdk1.7/home'
+ code 'java-based-daemon-ctl.sh -start'
+ not_if 'java-based-daemon-ctl.sh -test-started'
+end
+```
+
+The `not_if` statement now inherits the `environment` property and will
+use the `JAVA_HOME` path as part of its evaluation.
diff --git a/content/reusable/md/resources_common_guard_interpreter_example_default.md b/content/reusable/md/resources_common_guard_interpreter_example_default.md
new file mode 100644
index 0000000..906008f
--- /dev/null
+++ b/content/reusable/md/resources_common_guard_interpreter_example_default.md
@@ -0,0 +1,10 @@
+For example, the following code block will ensure the command is
+evaluated using the default interpreter as identified by Chef Infra
+Client:
+
+```ruby
+resource 'name' do
+ guard_interpreter :default
+ # code
+end
+```
diff --git a/content/reusable/md/resources_common_guards.md b/content/reusable/md/resources_common_guards.md
new file mode 100644
index 0000000..3496433
--- /dev/null
+++ b/content/reusable/md/resources_common_guards.md
@@ -0,0 +1,19 @@
+A guard property can be used to evaluate the state of a node during the
+execution phase of a Chef Infra Client run. Based on the results of this
+evaluation, a guard property is then used to tell Chef Infra Client if
+it should continue executing a resource. A guard property accepts either
+a string value or a Ruby block value:
+
+- A string is executed as a shell command. If the command returns `0`,
+ the guard is applied. If the command returns any other value, then
+ the guard property isn't applied. String guards in a
+ **powershell_script** run Windows PowerShell commands and may
+ return `true` in addition to `0`.
+- A block is executed as Ruby code that must return either `true` or
+ `false`. If the block returns `true`, the guard property is applied.
+ If the block returns `false`, the guard property isn't applied.
+
+A guard property is useful for ensuring that a resource is idempotent by
+allowing that resource to test for the desired state as it's being
+executed, and then if the desired state is present, for Chef Infra
+Client to do nothing.
diff --git a/content/reusable/md/resources_common_guards_arguments.md b/content/reusable/md/resources_common_guards_arguments.md
new file mode 100644
index 0000000..0160f65
--- /dev/null
+++ b/content/reusable/md/resources_common_guards_arguments.md
@@ -0,0 +1,45 @@
+The following arguments can be used with the `not_if` or `only_if` guard
+properties:
+
+`:user`
+
+: Specify the user that a command will run as. For example:
+
+ ```ruby
+ not_if 'grep adam /etc/passwd', user: 'adam'
+ ```
+
+`:group`
+
+: Specify the group that a command will run as. For example:
+
+ ```ruby
+ not_if 'grep adam /etc/passwd', group: 'adam'
+ ```
+
+`:environment`
+
+: Specify a Hash of environment variables to be set. For example:
+
+ ```ruby
+ not_if 'grep adam /etc/passwd', environment: {
+ 'HOME' => '/home/adam',
+ }
+ ```
+
+`:cwd`
+
+: Set the current working directory before running a command. For
+ example:
+
+ ```ruby
+ not_if 'grep adam passwd', cwd: '/etc'
+ ```
+
+`:timeout`
+
+: Set a timeout for a command. For example:
+
+ ```ruby
+ not_if 'sleep 10000', timeout: 10
+ ```
diff --git a/content/reusable/md/resources_common_guards_properties.md b/content/reusable/md/resources_common_guards_properties.md
new file mode 100644
index 0000000..3e176d2
--- /dev/null
+++ b/content/reusable/md/resources_common_guards_properties.md
@@ -0,0 +1,10 @@
+The following properties can be used to define a guard that's evaluated
+during the execution phase of a Chef Infra Client run:
+
+`not_if`
+
+: Prevent a resource from executing when the condition returns `true`.
+
+`only_if`
+
+: Allow a resource to execute only if the condition returns `true`.
diff --git a/content/reusable/md/resources_common_lazy_evaluation.md b/content/reusable/md/resources_common_lazy_evaluation.md
new file mode 100644
index 0000000..be2ed9b
--- /dev/null
+++ b/content/reusable/md/resources_common_lazy_evaluation.md
@@ -0,0 +1,50 @@
+In some cases, the value for a property can't be known until the
+execution phase of a Chef Infra Client run. In this situation, using
+lazy evaluation of property values can be helpful. Instead of a property
+being assigned a value, it may instead be assigned a code block. The
+syntax for using lazy evaluation is as follows:
+
+```ruby
+property_name lazy { code_block }
+```
+
+where `lazy` is used to tell Chef Infra Client to evaluate the contents
+of the code block later on in the resource evaluation process (instead
+of immediately) and `{ code_block }` is arbitrary Ruby code that
+provides the value.
+
+For example, a resource that's **not** doing lazy evaluation:
+
+```ruby
+template 'template_name' do
+ # some properties
+ path '/foo/bar'
+end
+```
+
+and a resource block that's doing lazy evaluation:
+
+```ruby
+template 'template_name' do
+ # some properties
+ path lazy { ' some Ruby code ' }
+end
+```
+
+In the previous examples, the first resource uses the value `/foo/bar`
+and the second resource uses the value provided by the code block, as
+long as the contents of that code block are a valid resource property.
+
+The following example shows how to use lazy evaluation with template
+variables:
+
+```ruby
+template '/tmp/canvey_island.txt' do
+ source 'canvey_island.txt.erb'
+ variables(
+ lazy do
+ { canvey_island: node.run_state['sea_power'] }
+ end
+ )
+end
+```
diff --git a/content/reusable/md/resources_common_notification.md b/content/reusable/md/resources_common_notification.md
new file mode 100644
index 0000000..d3ba8d3
--- /dev/null
+++ b/content/reusable/md/resources_common_notification.md
@@ -0,0 +1,3 @@
+A notification is a property on a resource that listens to other
+resources in the resource collection and then takes actions based on the
+notification type (`notifies` or `subscribes`).
diff --git a/content/reusable/md/resources_common_notification_notifies.md b/content/reusable/md/resources_common_notification_notifies.md
new file mode 100644
index 0000000..43942ae
--- /dev/null
+++ b/content/reusable/md/resources_common_notification_notifies.md
@@ -0,0 +1,9 @@
+A resource may notify another resource to take action when its state
+changes. Specify a `'resource[name]'`, the `:action` that resource
+should take, and then the `:timer` for that action. A resource may
+notify more than one resource; use a `notifies` statement for each
+resource to be notified.
+
+If the referenced resource doesn't exist, an error is raised.
+In contrast, `subscribes` won't fail if the source
+resource isn't found.
diff --git a/content/reusable/md/resources_common_notification_notifies_syntax.md b/content/reusable/md/resources_common_notification_notifies_syntax.md
new file mode 100644
index 0000000..a307b05
--- /dev/null
+++ b/content/reusable/md/resources_common_notification_notifies_syntax.md
@@ -0,0 +1,5 @@
+The syntax for `notifies` is:
+
+```ruby
+notifies :action, 'resource[name]', :timer
+```
diff --git a/content/reusable/md/resources_common_notification_subscribes.md b/content/reusable/md/resources_common_notification_subscribes.md
new file mode 100644
index 0000000..0ab804f
--- /dev/null
+++ b/content/reusable/md/resources_common_notification_subscribes.md
@@ -0,0 +1,29 @@
+A resource may listen to another resource, and then take action if the
+state of the resource being listened to changes. Specify a
+`'resource[name]'`, the `:action` to be taken, and then the `:timer` for
+that action.
+
+Note that `subscribes` doesn't apply the specified action to the
+resource that it listens to - for example:
+
+```ruby
+file '/etc/nginx/ssl/example.crt' do
+ mode '0600'
+ owner 'root'
+end
+
+service 'nginx' do
+ subscribes :reload, 'file[/etc/nginx/ssl/example.crt]', :immediately
+end
+```
+
+In this case the `subscribes` property reloads the `nginx` service
+whenever its certificate file, located under
+`/etc/nginx/ssl/example.crt`, is updated. `subscribes` doesn't make any
+changes to the certificate file itself, it merely listens for a change
+to the file, and executes the `:reload` action for its resource (in this
+example `nginx`) when a change is detected.
+
+If the other resource doesn't exist, the subscription won't raise an
+error. Contrast this with the stricter semantics of `notifies`, which
+will raise an error if the other resource doesn't exist.
diff --git a/content/reusable/md/resources_common_notification_subscribes_syntax.md b/content/reusable/md/resources_common_notification_subscribes_syntax.md
new file mode 100644
index 0000000..e7d4d81
--- /dev/null
+++ b/content/reusable/md/resources_common_notification_subscribes_syntax.md
@@ -0,0 +1,5 @@
+The syntax for `subscribes` is:
+
+```ruby
+subscribes :action, 'resource[name]', :timer
+```
diff --git a/content/reusable/md/resources_common_notification_timers.md b/content/reusable/md/resources_common_notification_timers.md
new file mode 100644
index 0000000..31c8950
--- /dev/null
+++ b/content/reusable/md/resources_common_notification_timers.md
@@ -0,0 +1,18 @@
+A timer specifies the point during a Chef Infra Client run at which a
+notification is run. The following timers are available:
+
+`:before`
+
+: Specifies that the action on a notified resource should be run
+ before processing the resource block in which the notification is
+ located.
+
+`:delayed`
+
+: Default. Specifies that a notification should be queued up, and then
+ executed at the end of a Chef Infra Client run.
+
+`:immediate`, `:immediately`
+
+: Specifies that a notification should be run immediately, for each
+ resource notified.
diff --git a/content/reusable/md/resources_common_properties.md b/content/reusable/md/resources_common_properties.md
new file mode 100644
index 0000000..2107ebd
--- /dev/null
+++ b/content/reusable/md/resources_common_properties.md
@@ -0,0 +1,31 @@
+The following properties are common to every resource:
+
+`compile_time`
+
+: **Ruby Type:** true, false \| **Default Value:** `false`
+
+ Control the phase during which the resource is run on the node. Set to true to run while the resource collection is being built (the `compile phase`). Set to false to run while Chef Infra Client is configuring the node (the `converge phase`).
+
+`ignore_failure`
+
+: **Ruby Type:** true, false, :quiet \| **Default Value:** `false`
+
+ Continue running a recipe if a resource fails for any reason. `:quiet` won't display the full stack trace and the recipe will continue to run if a resource fails.
+
+`retries`
+
+: **Ruby Type:** Integer \| **Default Value:** `0`
+
+ The number of attempts to catch exceptions and retry the resource.
+
+`retry_delay`
+
+: **Ruby Type:** Integer \| **Default Value:** `2`
+
+ The delay in seconds between retry attempts.
+
+`sensitive`
+
+: **Ruby Type:** true, false \| **Default Value:** `false`
+
+ Ensure that sensitive resource data isn't logged by Chef Infra Client.
diff --git a/content/reusable/md/resources_common_relative_paths.md b/content/reusable/md/resources_common_relative_paths.md
new file mode 100644
index 0000000..1d8ef4a
--- /dev/null
+++ b/content/reusable/md/resources_common_relative_paths.md
@@ -0,0 +1,6 @@
+The following relative paths can be used with any resource:
+
+`#{ENV['HOME']}`
+
+: Use to return the `~` path in Linux and macOS or the `%HOMEPATH%` in
+ Windows.
diff --git a/content/reusable/md/resources_common_windows_security.md b/content/reusable/md/resources_common_windows_security.md
new file mode 100644
index 0000000..8201602
--- /dev/null
+++ b/content/reusable/md/resources_common_windows_security.md
@@ -0,0 +1,4 @@
+To support Windows security, the **template**, **file**,
+**remote_file**, **cookbook_file**, **directory**, and
+**remote_directory** resources support the use of inheritance and
+access control lists (ACLs) within recipes.
diff --git a/content/reusable/md/resources_common_windows_security_acl.md b/content/reusable/md/resources_common_windows_security_acl.md
new file mode 100644
index 0000000..b391d7e
--- /dev/null
+++ b/content/reusable/md/resources_common_windows_security_acl.md
@@ -0,0 +1,119 @@
+The `rights` property can be used in a recipe to manage access control
+lists (ACLs), which allow permissions to be given to multiple users and
+groups. Use the `rights` property can be used as many times as
+necessary; Chef Infra Client will apply them to the file or directory as
+required. The syntax for the `rights` property is as follows:
+
+```ruby
+rights permission, principal, option_type => value
+```
+
+where
+
+`permission`
+
+: Use to specify which rights are granted to the `principal`. The
+ possible values are: `:read`, `:write`, `read_execute`, `:modify`,
+ `:full_control`, or an integer.
+
+: Integers used for permissions must match the following list
+ [FileSystemRights Enum](https://docs.microsoft.com/en-us/dotnet/api/system.security.accesscontrol.filesystemrights?view=windowsdesktop-5.0#fields) fields.
+
+ These permissions are cumulative. If `:write` is specified, then it
+ includes `:read`. If `:full_control` is specified, then it includes
+ both `:write` and `:read`.
+
+ (For those who know the Windows API: `:read` corresponds
+ to `GENERIC_READ`; `:write` corresponds to `GENERIC_WRITE`;
+ `:read_execute` corresponds to `GENERIC_READ` and `GENERIC_EXECUTE`;
+ `:modify` corresponds to `GENERIC_WRITE`, `GENERIC_READ`,
+ `GENERIC_EXECUTE`, and `DELETE`; `:full_control` corresponds to
+ `GENERIC_ALL`, which allows a user to change the owner and other
+ metadata about a file.)
+
+`principal`
+
+: Use to specify a group or user. The principal can be specified by
+ either name or SID. When using name, this is identical to what's
+ entered in the login box for Windows, such as `user_name`,
+ `domain\user_name`, or `user_name@fully_qualified_domain_name`. When
+ using a SID, you may use either the standard string representation of
+ a SID (S-R-I-S-S) or one of the [security descriptor definition language (SDDL) string constants](https://docs.microsoft.com/en-us/windows/win32/secauthz/sid-strings). Chef
+ Infra Client doesn't need to know if a principal is a user or a
+ group.
+
+`option_type`
+
+: A hash that contains advanced rights options. For example, the
+ rights to a directory that only applies to the first level of
+ children might look something like:
+ `rights :write, 'domain\group_name', :one_level_deep => true`.
+
+ Possible option types:
+
+ `:applies_to_children`
+
+ : Specify how permissions are applied to children. Possible values: `true` to inherit both child directories and files; `false` to not inherit any child directories or files; `:containers_only` to inherit only child directories (and not files); `:objects_only` to recursively inherit files (and not child directories).
+
+ `:applies_to_self`
+
+ : Indicates whether a permission is applied to the parent directory. Possible values: `true` to apply to the parent directory or file and its children; `false` to not apply only to child directories and files.
+
+ `:one_level_deep`
+
+ : Indicates the depth to which permissions will be applied. Possible values: `true` to apply only to the first level of children; `false` to apply to all children.
+
+For example:
+
+```ruby
+resource 'x.txt' do
+ rights :read, 'S-1-1-0'
+ rights :write, 'domain\group'
+ rights :full_control, 'group_name_or_user_name'
+ rights :full_control, 'user_name', applies_to_children: true
+end
+```
+
+or:
+
+```ruby
+rights :read, %w(Administrators Everyone)
+rights :full_control, 'Users', applies_to_children: true
+rights :write, 'Sally', applies_to_children: :containers_only, applies_to_self: false, one_level_deep: true
+```
+
+Some other important things to know when using the `rights` attribute:
+
+- Only inherited rights remain. All existing explicit rights on the
+ object are removed and replaced.
+- If rights aren't specified, nothing will be changed. Chef Infra
+ Client doesn't clear out the rights on a file or directory if
+ rights aren't specified.
+- Changing inherited rights can be expensive. Windows will
+ propagate rights to all children recursively due to inheritance.
+ This is a normal aspect of Windows, so consider the
+ frequency with which this type of action is necessary and take steps
+ to control this type of action if performance is the primary
+ consideration.
+
+Use the `deny_rights` property to deny specific rights to specific
+users. The ordering is independent of using the `rights` property. For
+example, it doesn't matter if rights are granted to everyone is placed
+before or after `deny_rights :read, ['Julian', 'Lewis']`, both Julian
+and Lewis will be unable to read the document. For example:
+
+```ruby
+resource 'x.txt' do
+ rights :read, 'Everyone'
+ rights :write, 'domain\group'
+ rights :full_control, 'group_name_or_user_name'
+ rights :full_control, 'user_name', applies_to_children: true
+ deny_rights :read, %w(Julian Lewis)
+end
+```
+
+or:
+
+```ruby
+deny_rights :full_control, ['Sally']
+```
diff --git a/content/reusable/md/resources_common_windows_security_inherits.md b/content/reusable/md/resources_common_windows_security_inherits.md
new file mode 100644
index 0000000..030481f
--- /dev/null
+++ b/content/reusable/md/resources_common_windows_security_inherits.md
@@ -0,0 +1,51 @@
+By default, a file or directory inherits rights from its parent
+directory. Most of the time this is the preferred behavior, but
+sometimes it may be necessary to take steps to more specifically control
+rights. The `inherits` property can be used to specifically tell Chef
+Infra Client to apply (or not apply) inherited rights from its parent
+directory.
+
+For example, the following example specifies the rights for a directory:
+
+```ruby
+directory 'C:\mordor' do
+ rights :read, 'MORDOR\Minions'
+ rights :full_control, 'MORDOR\Sauron'
+end
+```
+
+and then the following example specifies how to use inheritance to deny
+access to the child directory:
+
+```ruby
+directory 'C:\mordor\mount_doom' do
+ rights :full_control, 'MORDOR\Sauron'
+ inherits false # Sauron is the only person who should have any sort of access
+end
+```
+
+If the `deny_rights` permission were to be used instead, something could
+slip through unless all users and groups were denied.
+
+Another example also shows how to specify rights for a directory:
+
+```ruby
+directory 'C:\mordor' do
+ rights :read, 'MORDOR\Minions'
+ rights :full_control, 'MORDOR\Sauron'
+ rights :write, 'SHIRE\Frodo' # Who put that there I didn't put that there
+end
+```
+
+but then not use the `inherits` property to deny those rights on a child
+directory:
+
+```ruby
+directory 'C:\mordor\mount_doom' do
+ deny_rights :read, 'MORDOR\Minions' # Oops, not specific enough
+end
+```
+
+Because the `inherits` property isn't specified, Chef Infra Client will
+default it to `true`, which will ensure that security settings for
+existing files remain unchanged.
diff --git a/content/reusable/md/role.md b/content/reusable/md/role.md
new file mode 100644
index 0000000..077a0d4
--- /dev/null
+++ b/content/reusable/md/role.md
@@ -0,0 +1,9 @@
+A role is a way to define certain patterns and processes that exist
+across nodes in an organization as belonging to a single job function.
+Each role consists of zero (or more) attributes and a run-list. Each
+node can have zero (or more) roles assigned to it. When a role is run
+against a node, the configuration details of that node are compared
+against the attributes of the role, and then the contents of that role's
+run-list are applied to the node's configuration details. When a Chef
+Infra Client runs, it merges its own attributes and run-lists with those
+contained within each assigned role.
diff --git a/content/reusable/md/role_attribute.md b/content/reusable/md/role_attribute.md
new file mode 100644
index 0000000..335bd75
--- /dev/null
+++ b/content/reusable/md/role_attribute.md
@@ -0,0 +1,12 @@
+An attribute can be defined in a role and then used to override the
+default settings on a node. When a role is applied during a Chef Infra
+Client run, these attributes are compared to the attributes that are
+already present on the node. When the role attributes take precedence
+over the default attributes, Chef Infra Client applies those new
+settings and values during a Chef Infra Client run.
+
+A role attribute can only be set to be a default attribute or an
+override attribute. A role attribute can't be set to be a normal
+attribute. Use the `default_attribute` and `override_attribute` methods
+in the `.rb` attributes file or the `default_attributes` and
+`override_attributes` hashes in a JSON data file.
diff --git a/content/reusable/md/ruby_class_chef_log_fatal.md b/content/reusable/md/ruby_class_chef_log_fatal.md
new file mode 100644
index 0000000..d624558
--- /dev/null
+++ b/content/reusable/md/ruby_class_chef_log_fatal.md
@@ -0,0 +1,38 @@
+The following example shows a series of fatal `Chef::Log` entries:
+
+```ruby
+unless node['splunk']['upgrade_enabled']
+ Chef::Log.fatal('The chef-splunk::upgrade recipe was added to the node,')
+ Chef::Log.fatal('but the attribute `node["splunk"]["upgrade_enabled"]` wasn\'t set.')
+ Chef::Log.fatal('I am bailing here so this node doesn\'t upgrade.')
+ raise
+end
+
+service 'splunk_stop' do
+ service_name 'splunk'
+ supports status: true
+ action :stop
+end
+
+if node['splunk']['is_server']
+ splunk_package = 'splunk'
+ url_type = 'server'
+else
+ splunk_package = 'splunkforwarder'
+ url_type = 'forwarder'
+end
+
+splunk_installer splunk_package do
+ url node['splunk']['upgrade']["#{url_type}_url"]
+end
+
+if node['splunk']['accept_license']
+ execute 'splunk-unattended-upgrade' do
+ command "#{splunk_cmd} start --accept-license --answer-yes"
+ end
+else
+ Chef::Log.fatal('You didn\'t accept the license (set node["splunk"]["accept_license"] to true)')
+ Chef::Log.fatal('Splunk is stopped and can\'t be restarted until the license is accepted!')
+ raise
+end
+```
diff --git a/content/reusable/md/ruby_class_chef_log_multiple.md b/content/reusable/md/ruby_class_chef_log_multiple.md
new file mode 100644
index 0000000..9e37444
--- /dev/null
+++ b/content/reusable/md/ruby_class_chef_log_multiple.md
@@ -0,0 +1,15 @@
+The following example shows using multiple `Chef::Log` entry types:
+
+```ruby
+...
+
+begin
+ aws = Chef::DataBagItem.load(:aws, :main)
+ Chef::Log.info("Loaded AWS information from DataBagItem aws[#{aws['id']}]")
+rescue
+ Chef::Log.fatal("Couldn't find the 'main' item in the 'aws' data bag")
+ raise
+end
+
+...
+```
diff --git a/content/reusable/md/ruby_style_basics_chef_log.md b/content/reusable/md/ruby_style_basics_chef_log.md
new file mode 100644
index 0000000..be52f63
--- /dev/null
+++ b/content/reusable/md/ruby_style_basics_chef_log.md
@@ -0,0 +1,40 @@
+`Chef::Log` will print log entries to the default logger that's configured for the machine on which Chef Infra Client is running. (To create a log entry that's built into the resource collection, use the [log resource](/resources/log/) instead of `Chef::Log`.)
+
+
+
+### Supported log levels
+
+
+
+
+
+
+
+
+
Log Level
+
Syntax
+
+
+
+
+
Fatal
+
Chef::Log.fatal('string')
+
+
+
Error
+
Chef::Log.error('string')
+
+
+
Warn
+
Chef::Log.warn('string')
+
+
+
Info
+
Chef::Log.info('string')
+
+
+
Debug
+
Chef::Log.debug('string')
+
+
+
diff --git a/content/reusable/md/ruby_style_patterns_hyphens.md b/content/reusable/md/ruby_style_patterns_hyphens.md
new file mode 100644
index 0000000..2d5d29d
--- /dev/null
+++ b/content/reusable/md/ruby_style_patterns_hyphens.md
@@ -0,0 +1,6 @@
+Cookbook and custom resource names should contain only alphanumeric
+characters. A hyphen (`-`) is a valid character and may be used in
+cookbook and custom resource names, but it's discouraged. Chef Infra
+Client will return an error if a hyphen isn't converted to an
+underscore (`_`) when referencing from a recipe the name of a custom
+resource in which a hyphen is located.
diff --git a/content/reusable/md/ruby_style_patterns_string_quoting_vs_whitespace_array.md b/content/reusable/md/ruby_style_patterns_string_quoting_vs_whitespace_array.md
new file mode 100644
index 0000000..8b155bc
--- /dev/null
+++ b/content/reusable/md/ruby_style_patterns_string_quoting_vs_whitespace_array.md
@@ -0,0 +1,24 @@
+When `%w` syntax uses a variable, such as `|foo|`, double quoted strings
+should be used.
+
+Right:
+
+```ruby
+%w(openssl.cnf pkitool vars Rakefile).each do |foo|
+ template "/etc/openvpn/easy-rsa/#{foo}" do
+ source "#{foo}.erb"
+ ...
+ end
+end
+```
+
+Wrong:
+
+```ruby
+%w(openssl.cnf pkitool vars Rakefile).each do |foo|
+ template '/etc/openvpn/easy-rsa/#{foo}' do
+ source '#{foo}.erb'
+ ...
+ end
+end
+```
diff --git a/content/reusable/md/ruby_summary.md b/content/reusable/md/ruby_summary.md
new file mode 100644
index 0000000..80e8a77
--- /dev/null
+++ b/content/reusable/md/ruby_summary.md
@@ -0,0 +1,17 @@
+Ruby is a simple programming language:
+
+- Chef uses Ruby as its reference language to define the patterns that
+ are found in resources, recipes, and cookbooks
+- Use these patterns to configure, deploy, and manage nodes across the
+ network
+
+Ruby is also a powerful and complete programming language:
+
+- Use the Ruby programming language to make decisions about what
+ should happen to specific resources and recipes
+- Extend Chef in any manner that your organization requires
+
+To learn more about Ruby, see:
+
+- [Ruby Documentation](https://www.ruby-lang.org/en/documentation/)
+- [Ruby Standard Library Documentation](https://www.ruby-doc.org/stdlib/)
diff --git a/content/reusable/md/search.md b/content/reusable/md/search.md
new file mode 100644
index 0000000..1b304dc
--- /dev/null
+++ b/content/reusable/md/search.md
@@ -0,0 +1,10 @@
+Search indexes allow queries to be made for any type of data that's
+indexed by Chef Infra Server, including data bags (and data bag
+items), environments, nodes, and roles. A defined query syntax is used
+to support search patterns like exact, wildcard, range, and fuzzy. A
+search is a full-text query that can be done from several locations,
+including from within a recipe, by using the `search` subcommand in
+knife, the `search` method in the Chef Infra Language, the search box in the Chef
+management console, and by using the `/search` or `/search/INDEX`
+endpoints in the Chef Infra Server API. The search engine is based on
+Elasticsearch and is run from Chef Infra Server.
diff --git a/content/reusable/md/search_boolean_and.md b/content/reusable/md/search_boolean_and.md
new file mode 100644
index 0000000..6d09bb0
--- /dev/null
+++ b/content/reusable/md/search_boolean_and.md
@@ -0,0 +1,54 @@
+To join queries using the `AND` boolean operator, enter the following:
+
+```bash
+knife search sample "id:b* AND animal:dog"
+```
+
+to return something like:
+
+```bash
+{
+ "total": 1,
+ "start": 0,
+ "rows": [
+ {
+ "comment": "an item named baz",
+ "id": "baz",
+ "animal": "dog"
+ }
+ ]
+}
+```
+
+Or, to find all of the computers running on the Windows
+platform that are associated with a role named `jenkins`, enter:
+
+```bash
+knife search node 'platform:windows AND roles:jenkins'
+```
+
+to return something like:
+
+```bash
+2 items found
+
+Node Name: windows-server-2012r2.domain.com
+Environment: _default
+FQDN: windows-server-2012r2
+IP: 0000::0000:0000:0000:0000
+Run List: role[jenkins-windows]
+Roles: jenkins-windows, jenkins
+Recipes: jenkins-client::windows, jenkins::node_windows
+Platform: windows 6.3.9600
+Tags:
+
+Node Name: 123-windows-2012r2-amd64-builder
+Environment: _default
+FQDN: ABC-1234567890AB
+IP: 123.45.6.78
+Run List: role[123-windows-2012r2-amd64-builder]
+Roles: 123-windows-2012r2-amd64-builder, jenkins
+Recipes: jenkins::node_windows, git_windows
+Platform: windows 6.3.9600
+Tags:
+```
diff --git a/content/reusable/md/search_boolean_not.md b/content/reusable/md/search_boolean_not.md
new file mode 100644
index 0000000..7b0292a
--- /dev/null
+++ b/content/reusable/md/search_boolean_not.md
@@ -0,0 +1,37 @@
+To negate search results using the `NOT` boolean operator, enter the
+following:
+
+```bash
+knife search sample "(NOT id:foo)"
+```
+
+to return something like:
+
+```bash
+{
+ "total": 4,
+ "start": 0,
+ "rows": [
+ {
+ "comment": "an item named bar",
+ "id": "bar",
+ "animal": "cat"
+ },
+ {
+ "comment": "an item named baz",
+ "id": "baz"
+ "animal": "dog"
+ },
+ {
+ "comment": "an item named abc",
+ "id": "abc",
+ "animal": "unicorn"
+ },
+ {
+ "comment": "an item named qux",
+ "id": "qux",
+ "animal", "penguin"
+ }
+ ]
+}
+```
diff --git a/content/reusable/md/search_boolean_operators.md b/content/reusable/md/search_boolean_operators.md
new file mode 100644
index 0000000..6eff881
--- /dev/null
+++ b/content/reusable/md/search_boolean_operators.md
@@ -0,0 +1,31 @@
+An operator can be used to ensure that certain terms are included in the
+results, are excluded from the results, or aren't included even when
+other aspects of the query match. Searches can use the following
+operators:
+
+
+
+
+
+
+
+
+
Operator
+
Description
+
+
+
+
+
AND
+
Use to find a match when both terms exist.
+
+
+
OR
+
Use to find a match if either term exists.
+
+
+
NOT
+
Use to exclude the term after NOT from the search results.
+
+
+
diff --git a/content/reusable/md/search_boolean_operators_andnot.md b/content/reusable/md/search_boolean_operators_andnot.md
new file mode 100644
index 0000000..7c520b0
--- /dev/null
+++ b/content/reusable/md/search_boolean_operators_andnot.md
@@ -0,0 +1,25 @@
+Operators must be in ALL CAPS. Parentheses can be used to group clauses
+and to form sub-queries.
+
+
+
+
+
Warning
+
+
+Using `AND NOT` together may trigger an error. For example:
+
+```bash
+ERROR: knife search failed: invalid search query:
+'datacenter%3A123%20AND%20NOT%20hostname%3Adev-%20AND%20NOT%20hostanem%3Asyslog-'
+Parse error at offset: 38 Reason: Expected one of \ at line 1, column 42 (byte 42) after AND
+```
+
+Use `-` instead of `NOT`. For example:
+
+```bash
+knife search sample "id:foo AND -id:bar"
+```
+
+
+
diff --git a/content/reusable/md/search_boolean_or.md b/content/reusable/md/search_boolean_or.md
new file mode 100644
index 0000000..7a50d52
--- /dev/null
+++ b/content/reusable/md/search_boolean_or.md
@@ -0,0 +1,26 @@
+To join queries using the `OR` boolean operator, enter the following:
+
+```bash
+knife search sample "id:foo OR id:abc"
+```
+
+to return something like:
+
+```bash
+{
+ "total": 2,
+ "start": 0,
+ "rows": [
+ {
+ "comment": "an item named foo",
+ "id": "foo",
+ "animal": "pony"
+ },
+ {
+ "comment": "an item named abc",
+ "id": "abc",
+ "animal": "unicorn"
+ }
+ ]
+}
+```
diff --git a/content/reusable/md/search_data_bag.md b/content/reusable/md/search_data_bag.md
new file mode 100644
index 0000000..868f5c4
--- /dev/null
+++ b/content/reusable/md/search_data_bag.md
@@ -0,0 +1,106 @@
+Any search for a data bag (or a data bag item) must specify the name of
+the data bag and then provide the search query string that will be used
+during the search. For example, to use knife to search within a data bag
+named "admin_data" across all items, except for the "admin_users"
+item, enter the following:
+
+```bash
+knife search admin_data "(NOT id:admin_users)"
+```
+
+Or, to include the same search query in a recipe, use a code block
+similar to:
+
+```ruby
+search(:admin_data, 'NOT id:admin_users')
+```
+
+It may not be possible to know which data bag items will be needed. It
+may be necessary to load everything in a data bag (but not know what
+"everything" is). Using a search query is the ideal way to deal with
+that ambiguity, yet still ensure that all of the required data is
+returned. The following examples show how a recipe can use a series of
+search queries to search within a data bag named "admins". For example,
+to find every administrator:
+
+```ruby
+search(:admins, '*:*')
+```
+
+Or to search for an administrator named "charlie":
+
+```ruby
+search(:admins, 'id:charlie')
+```
+
+Or to search for an administrator with a group identifier of "ops":
+
+```ruby
+search(:admins, 'gid:ops')
+```
+
+Or to search for an administrator whose name begins with the letter "c":
+
+```ruby
+search(:admins, 'id:c*')
+```
+
+Data bag items that are returned by a search query can be used as if
+they were a hash. For example:
+
+```ruby
+charlie = search(:admins, 'id:charlie').first
+# => variable 'charlie' is set to the charlie data bag item
+charlie['gid']
+# => "ops"
+charlie['shell']
+# => "/bin/zsh"
+```
+
+The following recipe can be used to create a user for each administrator
+by loading all of the items from the "admins" data bag, looping through
+each admin in the data bag, and then creating a user resource so that
+each of those admins exist:
+
+```ruby
+admins = data_bag('admins')
+
+admins.each do |login|
+ admin = data_bag_item('admins', login)
+ home = "/home/#{login}"
+
+ user(login) do
+ uid admin['uid']
+ gid admin['gid']
+ shell admin['shell']
+ comment admin['comment']
+ home home
+ manage_home true
+ end
+end
+```
+
+And then the same recipe, modified to load administrators using a search
+query (and using an array to store the results of the search query):
+
+```ruby
+admins = []
+
+search(:admins, '*:*').each do |admin|
+ login = admin['id']
+
+ admins << login
+
+ home = "/home/#{login}"
+
+ user(login) do
+ uid admin['uid']
+ gid admin['gid']
+ shell admin['shell']
+ comment admin['comment']
+
+ home home
+ manage_home true
+ end
+end
+```
diff --git a/content/reusable/md/search_environment.md b/content/reusable/md/search_environment.md
new file mode 100644
index 0000000..3b26ce7
--- /dev/null
+++ b/content/reusable/md/search_environment.md
@@ -0,0 +1,18 @@
+When searching, an environment is an attribute. This allows search
+results to be limited to a specified environment by using Boolean
+operators and extra search terms. For example, to use knife to search
+for all of the servers running CentOS in an environment named "QA",
+enter the following:
+
+```bash
+knife search node "chef_environment:QA AND platform:centos"
+```
+
+Or, to include the same search in a recipe, use a code block similar to:
+
+```ruby
+qa_nodes = search(:node, 'chef_environment:QA')
+qa_nodes.each do |qa_node|
+ # Do useful work specific to qa nodes only
+end
+```
diff --git a/content/reusable/md/search_key.md b/content/reusable/md/search_key.md
new file mode 100644
index 0000000..46888d6
--- /dev/null
+++ b/content/reusable/md/search_key.md
@@ -0,0 +1,4 @@
+A field name/description pair is available in the JSON object. Use the
+field name when searching for this information in the JSON object. Any
+field that exists in any JSON description for any role, node, Chef Infra
+Client, environment, or data bag can be searched.
diff --git a/content/reusable/md/search_key_name.md b/content/reusable/md/search_key_name.md
new file mode 100644
index 0000000..58d310b
--- /dev/null
+++ b/content/reusable/md/search_key_name.md
@@ -0,0 +1,9 @@
+To see the available keys for a node, enter the following (for a node
+named `staging`):
+
+```bash
+knife node show staging -Fj | less
+```
+
+to return a full JSON description of the node and to view the available
+keys with which any search query can be based.
diff --git a/content/reusable/md/search_key_nested.md b/content/reusable/md/search_key_nested.md
new file mode 100644
index 0000000..1c7ca64
--- /dev/null
+++ b/content/reusable/md/search_key_nested.md
@@ -0,0 +1,142 @@
+A nested field appears deeper in the JSON data structure. For example,
+information about a network interface might be several layers deep:
+`node['network']['interfaces']['en1']`. When nested fields are present
+in a JSON structure, Chef Infra Client will extract those nested fields
+to the top-level, flattening them into compound fields that support
+wildcard search patterns.
+
+By combining wildcards with range-matching patterns and wildcard
+queries, it's possible to perform powerful searches, such as using
+the vendor part of the MAC address to find every node that has a network
+card made by the specified vendor.
+
+Consider the following snippet of JSON data:
+
+```json
+{"network":
+ [
+ //snipped...
+ "interfaces",
+ {"en1": {
+ "number": "1",
+ "flags": [
+ "UP",
+ "BROADCAST",
+ "SMART",
+ "RUNNING",
+ "SIMPLEX",
+ "MULTICAST"
+ ],
+ "addresses": {
+ "fe80::fa1e:dfff:fed8:63a2": {
+ "scope": "Link",
+ "prefixlen": "64",
+ "family": "inet6"
+ },
+ "f8:1e:df:d8:63:a2": {
+ "family": "lladdr"
+ },
+ "192.0.2.0": {
+ "netmask": "255.255.255.0",
+ "broadcast": "192.168.0.255",
+ "family": "inet"
+ }
+ },
+ "mtu": "1500",
+ "media": {
+ "supported": {
+ "autoselect": {
+ "options": [
+
+ ]
+ }
+ },
+ "selected": {
+ "autoselect": {
+ "options": [
+
+ ]
+ }
+ }
+ },
+ "type": "en",
+ "status": "active",
+ "encapsulation": "Ethernet"
+ },
+ //snipped...
+```
+
+Before this data is indexed on Chef Infra Server, the nested fields
+are extracted into the top level, similar to:
+
+```ruby
+"broadcast" => "192.168.0.255",
+"flags" => ["UP", "BROADCAST", "SMART", "RUNNING", "SIMPLEX", "MULTICAST"]
+"mtu" => "1500"
+```
+
+which allows searches like the following to find data that's present in
+this node:
+
+```ruby
+node "broadcast:192.168.0.*"
+```
+
+or:
+
+```ruby
+node "mtu:1500"
+```
+
+or:
+
+```ruby
+node "flags:UP"
+```
+
+This data is also flattened into various compound fields, which follow
+the same pattern as the JSON hierarchy and use underscores (`_`) to
+separate the levels of data, similar to:
+
+```ruby
+# ...snip...
+"network_interfaces_en1_addresses_192.0.2.0_broadcast" => "192.168.0.255",
+"network_interfaces_en1_addresses_fe80::fa1e:tldr_family" => "inet6",
+"network_interfaces_en1_addresses" => ["fe80::fa1e:tldr","f8:1e:df:tldr","192.0.2.0"]
+# ...snip...
+```
+
+which allows searches like the following to find data that's present in
+this node:
+
+```ruby
+node "network_interfaces_en1_addresses:192.0.2.0"
+```
+
+This flattened data structure also supports using wildcard compound
+fields, which allow searches to omit levels within the JSON data
+structure that aren't important to the search query. In the following
+example, an asterisk (`*`) is used to show where the wildcard can exist
+when searching for a nested field:
+
+```ruby
+"network_interfaces_*_flags" => ["UP", "BROADCAST", "SMART", "RUNNING", "SIMPLEX", "MULTICAST"]
+"network_interfaces_*_addresses" => ["fe80::fa1e:dfff:fed8:63a2", "192.0.2.0", "f8:1e:df:d8:63:a2"]
+"network_interfaces_en0_media_*" => ["autoselect", "none", "1000baseT", "10baseT/UTP", "100baseTX"]
+"network_interfaces_en1_*" => ["1", "UP", "BROADCAST", "SMART", "RUNNING", "SIMPLEX", "MULTICAST",
+ "fe80::fa1e:dfff:fed8:63a2", "f8:1e:df:d8:63:a2", "192.0.2.0",
+ "1500", "supported", "selected", "en", "active", "Ethernet"]
+```
+
+For each of the wildcard examples above, the possible values are shown
+contained within the brackets. When running a search query, the query
+syntax for wildcards is to simply omit the name of the node (while
+preserving the underscores), similar to:
+
+```ruby
+network_interfaces__flags
+```
+
+This query will search within the `flags` node, within the JSON
+structure, for each of `UP`, `BROADCAST`, `SMART`, `RUNNING`, `SIMPLEX`,
+and `MULTICAST`.
diff --git a/content/reusable/md/search_key_nested_range.md b/content/reusable/md/search_key_nested_range.md
new file mode 100644
index 0000000..84d7e14
--- /dev/null
+++ b/content/reusable/md/search_key_nested_range.md
@@ -0,0 +1,8 @@
+To use a range search to find IP addresses within a subnet, enter the
+following:
+
+```bash
+knife search node 'ipaddress:[192.168.0.* TO 192.0.2.*]'
+```
+
+where `192.168.0.* TO 192.0.2.*` defines the subnet range.
diff --git a/content/reusable/md/search_key_nested_starting_with.md b/content/reusable/md/search_key_nested_starting_with.md
new file mode 100644
index 0000000..5611109
--- /dev/null
+++ b/content/reusable/md/search_key_nested_starting_with.md
@@ -0,0 +1,9 @@
+To find all IP address that are on the same network, enter the
+following:
+
+```bash
+knife search node 'ipaddress:192.168*'
+```
+
+where `192.168*` is the network address for which the search will be
+run.
diff --git a/content/reusable/md/search_key_wildcard_asterisk.md b/content/reusable/md/search_key_wildcard_asterisk.md
new file mode 100644
index 0000000..b29fd76
--- /dev/null
+++ b/content/reusable/md/search_key_wildcard_asterisk.md
@@ -0,0 +1,6 @@
+To use an asterisk (`*`) to replace zero (or more) characters in a
+wildcard search, enter the following:
+
+```bash
+knife search node 'platfo*:ubuntu'
+```
diff --git a/content/reusable/md/search_key_wildcard_question_mark.md b/content/reusable/md/search_key_wildcard_question_mark.md
new file mode 100644
index 0000000..3a5b169
--- /dev/null
+++ b/content/reusable/md/search_key_wildcard_question_mark.md
@@ -0,0 +1,6 @@
+To use a question mark (`?`) to replace a single character in a wildcard
+search, enter the following:
+
+```bash
+knife search node 'platfor?:ubuntu'
+```
diff --git a/content/reusable/md/search_pattern.md b/content/reusable/md/search_pattern.md
new file mode 100644
index 0000000..f594cc2
--- /dev/null
+++ b/content/reusable/md/search_pattern.md
@@ -0,0 +1,4 @@
+A search pattern is a way to fine-tune search results by returning
+anything that matches some type of incomplete search query. There are
+four types of search patterns that can be used when searching the search
+indexes on Chef Infra Server: exact, wildcard, range, and fuzzy.
diff --git a/content/reusable/md/search_pattern_exact.md b/content/reusable/md/search_pattern_exact.md
new file mode 100644
index 0000000..b9f4159
--- /dev/null
+++ b/content/reusable/md/search_pattern_exact.md
@@ -0,0 +1,8 @@
+An exact matching search pattern is used to search for a key with a name
+that exactly matches a search query. If the name of the key contains
+spaces, quotes must be used in the search pattern to ensure the search
+query finds the key. The entire query must also be contained within
+quotes, so as to prevent it from being interpreted by Ruby or a command
+shell. The best way to ensure that quotes are used consistently is to
+quote the entire query using single quotes (' ') and a search pattern
+with double quotes (" ").
diff --git a/content/reusable/md/search_pattern_exact_key_and_item.md b/content/reusable/md/search_pattern_exact_key_and_item.md
new file mode 100644
index 0000000..0762f61
--- /dev/null
+++ b/content/reusable/md/search_pattern_exact_key_and_item.md
@@ -0,0 +1,21 @@
+To search in a specific data bag for a specific data bag item, enter the
+following:
+
+```bash
+knife search admins 'id:charlie'
+```
+
+where `admins` is the name of the data bag and `charlie` is the name of
+the data bag item. Something similar to the following will be returned:
+
+```bash
+1 items found
+_rev: 1-39ff4099f2510f477b4c26bef81f75b9
+chef_type: data_bag_item
+comment: Charlie the Unicorn
+data_bag: admins
+gid: ops
+id: charlie
+shell: /bin/zsh
+uid: 1005
+```
diff --git a/content/reusable/md/search_pattern_exact_key_and_item_string.md b/content/reusable/md/search_pattern_exact_key_and_item_string.md
new file mode 100644
index 0000000..0777c72
--- /dev/null
+++ b/content/reusable/md/search_pattern_exact_key_and_item_string.md
@@ -0,0 +1,22 @@
+To search in a specific data bag using a string to find any matching
+data bag item, enter the following:
+
+```bash
+knife search admins 'comment:"Charlie the Unicorn"'
+```
+
+where `admins` is the name of the data bag and `Charlie the Unicorn` is
+the string that will be used during the search. Something similar to the
+following will be returned:
+
+```bash
+1 items found
+_rev: 1-39ff4099f2510f477b4c26bef81f75b9
+chef_type: data_bag_item
+comment: Charlie the Unicorn
+data_bag: admins
+gid: ops
+id: charlie
+shell: /bin/zsh
+uid: 1005
+```
diff --git a/content/reusable/md/search_pattern_fuzzy.md b/content/reusable/md/search_pattern_fuzzy.md
new file mode 100644
index 0000000..871fa88
--- /dev/null
+++ b/content/reusable/md/search_pattern_fuzzy.md
@@ -0,0 +1,12 @@
+A fuzzy matching search pattern is used to search based on the proximity
+of two strings of characters. An (optional) integer may be used as part
+of the search query to more closely define the proximity. A fuzzy
+matching search pattern has the following syntax:
+
+```ruby
+"search_query"~edit_distance
+```
+
+where `search_query` is the string that will be used during the search
+and `edit_distance` is the proximity. A tilde ("\~") is used to separate
+the edit distance from the search query.
diff --git a/content/reusable/md/search_pattern_fuzzy_summary.md b/content/reusable/md/search_pattern_fuzzy_summary.md
new file mode 100644
index 0000000..f27bb98
--- /dev/null
+++ b/content/reusable/md/search_pattern_fuzzy_summary.md
@@ -0,0 +1,25 @@
+To use a fuzzy search pattern enter something similar to:
+
+```bash
+knife search client "name:boo~"
+```
+
+where `boo~` defines the fuzzy search pattern. This will return
+something similar to:
+
+```json
+{
+ "total": 1,
+ "start": 0,
+ "rows": [
+ {
+ "public_key": "too long didn't read",
+ "name": "foo",
+ "_rev": "1-f11a58043906e33d39a686e9b58cd92f",
+ "json_class": "Chef::ApiClient",
+ "admin": false,
+ "chef_type": "client"
+ }
+ ]
+}
+```
diff --git a/content/reusable/md/search_pattern_range.md b/content/reusable/md/search_pattern_range.md
new file mode 100644
index 0000000..3682bfb
--- /dev/null
+++ b/content/reusable/md/search_pattern_range.md
@@ -0,0 +1,12 @@
+A range matching search pattern is used to query for values that are
+within a range defined by upper and lower boundaries. A range matching
+search pattern can be inclusive or exclusive of the boundaries. Use
+square brackets ("\[ \]") to denote inclusive boundaries and curly
+braces ("{ }") to denote exclusive boundaries and with the following
+syntax:
+
+```ruby
+boundary TO boundary
+```
+
+where `TO` is required (and must be capitalized).
diff --git a/content/reusable/md/search_pattern_range_exclusive.md b/content/reusable/md/search_pattern_range_exclusive.md
new file mode 100644
index 0000000..ce5ad11
--- /dev/null
+++ b/content/reusable/md/search_pattern_range_exclusive.md
@@ -0,0 +1,11 @@
+A data bag named `sample` contains four data bag items: `abc`, `bar`,
+`baz`, and `quz`. All of the items that are exclusive to `bar` and `foo`
+can be searched for using an exclusive search pattern.
+
+To search using an exclusive range, enter the following:
+
+```bash
+knife search sample "id:{bar TO foo}"
+```
+
+where curly braces (`{ }`) are used to define the range.
diff --git a/content/reusable/md/search_pattern_range_in_between.md b/content/reusable/md/search_pattern_range_in_between.md
new file mode 100644
index 0000000..4275429
--- /dev/null
+++ b/content/reusable/md/search_pattern_range_in_between.md
@@ -0,0 +1,11 @@
+A data bag named `sample` contains four data bag items: `abc`, `bar`,
+`baz`, and `quz`. All of the items in-between `bar` and `foo`,
+inclusive, can be searched for using an inclusive search pattern.
+
+To search using an inclusive range, enter the following:
+
+```bash
+knife search sample "id:[bar TO foo]"
+```
+
+where square brackets (`[ ]`) are used to define the range.
diff --git a/content/reusable/md/search_pattern_wildcard.md b/content/reusable/md/search_pattern_wildcard.md
new file mode 100644
index 0000000..97825af
--- /dev/null
+++ b/content/reusable/md/search_pattern_wildcard.md
@@ -0,0 +1,9 @@
+A wildcard matching search pattern is used to query for substring
+matches that replace zero (or more) characters in the search pattern
+with anything that could match the replaced character. There are two
+types of wildcard searches:
+
+- A question mark (`?`) can be used to replace exactly one character
+ (as long as that character isn't the first character in the search
+ pattern)
+- An asterisk (`*`) can be used to replace any number of characters (including zero)
diff --git a/content/reusable/md/search_pattern_wildcard_any_node.md b/content/reusable/md/search_pattern_wildcard_any_node.md
new file mode 100644
index 0000000..dc43166
--- /dev/null
+++ b/content/reusable/md/search_pattern_wildcard_any_node.md
@@ -0,0 +1,8 @@
+To search for any node that contains the specified key, enter the
+following:
+
+```bash
+knife search node 'foo:*'
+```
+
+where `foo` is the name of the node.
diff --git a/content/reusable/md/search_pattern_wildcard_node_contains.md b/content/reusable/md/search_pattern_wildcard_node_contains.md
new file mode 100644
index 0000000..a61aa9b
--- /dev/null
+++ b/content/reusable/md/search_pattern_wildcard_node_contains.md
@@ -0,0 +1,26 @@
+To search for a node using a partial name, enter one of the following:
+
+```bash
+knife search node 'name:app*'
+```
+
+or:
+
+```bash
+knife search node 'name:app1*.example.com'
+```
+
+or:
+
+```bash
+knife search node 'name:app?.example.com'
+```
+
+or:
+
+```bash
+knife search node 'name:app1.example.???'
+```
+
+to return `app1.example.com` (and any other node that matches any of the
+string searches above).
diff --git a/content/reusable/md/search_query_syntax.md b/content/reusable/md/search_query_syntax.md
new file mode 100644
index 0000000..dfc6178
--- /dev/null
+++ b/content/reusable/md/search_query_syntax.md
@@ -0,0 +1,15 @@
+A search query is comprised of two parts: the key and the search
+pattern. A search query has the following syntax:
+
+```ruby
+key:search_pattern
+```
+
+where `key` is a field name that's found in the JSON description of an
+indexable object on Chef Infra Server (a role, node, client,
+environment, or data bag) and `search_pattern` defines what will be
+searched for, using one of the following search patterns: exact,
+wildcard, range, or fuzzy matching. Both `key` and `search_pattern` are
+case-sensitive; `key` has limited support for multiple character
+wildcard matching using an asterisk ("\*") (and as long as it's not the
+first character).
diff --git a/content/reusable/md/search_special_characters.md b/content/reusable/md/search_special_characters.md
new file mode 100644
index 0000000..21fae69
--- /dev/null
+++ b/content/reusable/md/search_special_characters.md
@@ -0,0 +1,15 @@
+A special character can be used to fine-tune a search query and to
+increase the accuracy of the search results. The following characters
+can be included within the search query syntax, but each occurrence of a
+special character must be escaped with a backslash (`\`), also (`/`)
+must be escaped against the Elasticsearch:
+
+```ruby
++ - && | | ! ( ) { } [ ] ^ " ~ * ? : \ /
+```
+
+For example:
+
+```ruby
+\(1\+1\)\:2
+```
diff --git a/content/reusable/md/security_chef_validator.md b/content/reusable/md/security_chef_validator.md
new file mode 100644
index 0000000..86411b0
--- /dev/null
+++ b/content/reusable/md/security_chef_validator.md
@@ -0,0 +1,5 @@
+Every request made by Chef Infra Client to Chef Infra Server must be
+an authenticated request using the Chef Infra Server API and a private
+key. When Chef Infra Client makes a request to Chef Infra Server,
+Chef Infra Client authenticates each request using a private key located
+in `/etc/chef/client.pem`.
diff --git a/content/reusable/md/security_chef_validator_context.md b/content/reusable/md/security_chef_validator_context.md
new file mode 100644
index 0000000..eed10e6
--- /dev/null
+++ b/content/reusable/md/security_chef_validator_context.md
@@ -0,0 +1,11 @@
+The private key doesn't yet exist the first time that Chef Infra Client runs from a new node.
+
+During the first Chef Infra Client run:
+
+1. Chef Infra Client uses the chef-validator private key, located in `/etc/chef/validation.pem` to register with Chef Infra Server
+2. Chef Infra Server assigns Chef Infra Client a private key for all future authentication requests to Chef Infra Server
+3. Chef Infra Client saves the private key on the node as `/etc/chef/client.pem`
+
+If the request to communicate with Chef Infra Server with the chef-validator key fails, then the entire first Chef Infra Client run fails.
+
+After the first completed Chef Infra Client run, delete the chef-validator private key at `/etc/chef/validation.pem`
diff --git a/content/reusable/md/security_key_pairs_chef_client.md b/content/reusable/md/security_key_pairs_chef_client.md
new file mode 100644
index 0000000..78c2399
--- /dev/null
+++ b/content/reusable/md/security_key_pairs_chef_client.md
@@ -0,0 +1,5 @@
+Chef Infra Client authenticates with Chef Infra Server using RSA
+public key-pairs each time a Chef Infra Client needs access to data that
+is stored on Chef Infra Server. This prevents any node from
+accessing data that it shouldn't and it ensures that only nodes that are
+properly registered with Chef Infra Server can be managed.
diff --git a/content/reusable/md/server/chef_auth.md b/content/reusable/md/server/chef_auth.md
new file mode 100644
index 0000000..aa6ad7e
--- /dev/null
+++ b/content/reusable/md/server/chef_auth.md
@@ -0,0 +1 @@
+The Chef Infra Server API handles all communication between Chef Infra Client or Chef Workstation. The Chef Infra Server API is an authenticated REST API, which means all requests require authentication and authorization. The Chef Infra tools such as `knife` and `chef-server` commands use the Chef Infra Server API for you.
diff --git a/content/reusable/md/server/chef_auth_authentication.md b/content/reusable/md/server/chef_auth_authentication.md
new file mode 100644
index 0000000..7acafdc
--- /dev/null
+++ b/content/reusable/md/server/chef_auth_authentication.md
@@ -0,0 +1,8 @@
+
+The authentication process ensures that Chef Infra Server only responds to requests made by trusted users or clients. Chef Infra Server uses public key encryption. You create the public and private keys when you configure [Chef Infra Client](/config_rb_client/) or setup [Chef Workstation](/workstation/getting_started/#set-up-chef-credentials).
+
+* Chef Infra Server stores the public key
+* Chef Workstation saves the private key in `~/.chef/`
+* Chef Infra Client saves the private key in `/etc/chef`
+
+Both Chef Infra Client and Chef Workstation communicate with Chef Infra Server using the Chef Infra Server API. Each time that Chef Infra Client or Chef Workstation makes a request to Chef Infra Server, they use a special group of HTTP headers and sign the rest with their private key. Chef Infra Server then uses the public key to verify the headers and contents.
diff --git a/content/reusable/md/server/config_ocid_application_hash_supermarket.md b/content/reusable/md/server/config_ocid_application_hash_supermarket.md
new file mode 100644
index 0000000..6c90a45
--- /dev/null
+++ b/content/reusable/md/server/config_ocid_application_hash_supermarket.md
@@ -0,0 +1,8 @@
+To define OAuth 2 information for Chef Supermarket, create a Hash similar to:
+
+```ruby
+oc_id['applications'] ||= {}
+oc_id['applications']['supermarket'] = {
+ 'redirect_uri' => 'https://supermarket.mycompany.com/auth/chef_oauth2/callback',
+}
+```
diff --git a/content/reusable/md/server/ctl_chef_server_org_create_summary.md b/content/reusable/md/server/ctl_chef_server_org_create_summary.md
new file mode 100644
index 0000000..cdebe8f
--- /dev/null
+++ b/content/reusable/md/server/ctl_chef_server_org_create_summary.md
@@ -0,0 +1,26 @@
+Run the following command to create an organization:
+
+```bash
+sudo chef-server-ctl org-create short_name 'full_organization_name' --association_user user_name --filename ORGANIZATION-validator.pem
+```
+
+For example:
+
+```bash
+sudo chef-server-ctl org-create 4thcafe 'Fourth Cafe, Inc.' --association_user janedoe --filename /path/to/4thcafe-validator.pem
+```
+
+The name must begin with a lower-case letter or digit, may only contain
+lower-case letters, digits, hyphens, and underscores, and must be
+between 1 and 255 characters. For example: `4thcafe`.
+
+The full name must begin with a non-white space character and must be
+between 1 and 1023 characters. For example: `'Fourth Cafe, Inc.'`.
+
+The `--association_user` option will associate the `user_name` with the
+`admins` security group on the Chef Infra Server.
+
+An RSA private key is generated automatically. This is the
+chef-validator key and should be saved to a safe location. The
+`--filename` option will save the RSA private key to the specified
+absolute path.
diff --git a/content/reusable/md/server/ctl_chef_server_uninstall.md b/content/reusable/md/server/ctl_chef_server_uninstall.md
new file mode 100644
index 0000000..0d80825
--- /dev/null
+++ b/content/reusable/md/server/ctl_chef_server_uninstall.md
@@ -0,0 +1,16 @@
+The `uninstall` subcommand is used to remove the Chef Infra Server
+application, but without removing any of the data. This subcommand will
+shut down all services (including the `runit` process supervisor).
+
+This subcommand has the following syntax:
+
+```bash
+chef-server-ctl uninstall
+```
+
+{{< note >}}
+
+To revert the `uninstall` subcommand, run the `reconfigure` subcommand
+(because the `start` subcommand is disabled by the `uninstall` command).
+
+{{< /note >}}
diff --git a/content/reusable/md/server/ctl_chef_server_user_create_admin.md b/content/reusable/md/server/ctl_chef_server_user_create_admin.md
new file mode 100644
index 0000000..ee786e1
--- /dev/null
+++ b/content/reusable/md/server/ctl_chef_server_user_create_admin.md
@@ -0,0 +1,15 @@
+Run the following command to create an administrator:
+
+```bash
+sudo chef-server-ctl user-create USER_NAME FIRST_NAME LAST_NAME EMAIL 'PASSWORD' --filename FILE_NAME
+```
+
+An RSA private key is generated automatically. This is the user's
+private key and should be saved to a safe location. The `--filename`
+option will save the RSA private key to the specified absolute path.
+
+For example:
+
+```bash
+sudo chef-server-ctl user-create janedoe Jane Doe janed@example.com 'abc123' --filename /path/to/janedoe.pem
+```
diff --git a/content/reusable/md/server/install_chef_server_install_package.md b/content/reusable/md/server/install_chef_server_install_package.md
new file mode 100644
index 0000000..1ef148f
--- /dev/null
+++ b/content/reusable/md/server/install_chef_server_install_package.md
@@ -0,0 +1,15 @@
+As a root user, install the Chef Infra Server package on the server,
+using the name of the package provided by Chef. For Red Hat Enterprise
+Linux and CentOS:
+
+```bash
+sudo rpm -Uvh /tmp/chef-server-core-.rpm
+```
+
+For Ubuntu:
+
+```bash
+sudo dpkg -i /tmp/chef-server-core-.deb
+```
+
+After a few minutes, the Chef Infra Server will be installed.
diff --git a/content/reusable/md/server/server_security_ssl_cert_client.md b/content/reusable/md/server/server_security_ssl_cert_client.md
new file mode 100644
index 0000000..e187f87
--- /dev/null
+++ b/content/reusable/md/server/server_security_ssl_cert_client.md
@@ -0,0 +1,25 @@
+Chef Infra Server 12 and later enables SSL verification by default for all
+requests made to the server, such as those made by knife and Chef Infra
+Client. The certificate that is generated during the installation of the
+Chef Infra Server is self-signed, which means the certificate is not
+signed by a trusted certificate authority (CA) recognized by Chef
+Infra Client. The certificate generated by the Chef Infra Server must be
+downloaded to any machine from which knife and/or Chef Infra Client will
+make requests to the Chef Infra Server.
+
+For example, without downloading the SSL certificate, the following
+knife command:
+
+```bash
+knife client list
+```
+
+responds with an error similar to:
+
+```bash
+ERROR: SSL Validation failure connecting to host: chef-server.example.com ...
+ERROR: OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=SSLv3 ...
+```
+
+This is by design and will occur until a verifiable certificate is added
+to the machine from which the request is sent.
diff --git a/content/reusable/md/template.md b/content/reusable/md/template.md
new file mode 100644
index 0000000..6894fa1
--- /dev/null
+++ b/content/reusable/md/template.md
@@ -0,0 +1 @@
+A cookbook template is an Embedded Ruby (ERB) template that's used to dynamically generate static text files. Templates may contain Ruby expressions and statements, and are a great way to manage configuration files. Use the **template** resource to add cookbook templates to recipes; place the corresponding Embedded Ruby (ERB) template file in a cookbook's `/templates` directory.
diff --git a/content/reusable/md/template_host_notation.md b/content/reusable/md/template_host_notation.md
new file mode 100644
index 0000000..c58ad58
--- /dev/null
+++ b/content/reusable/md/template_host_notation.md
@@ -0,0 +1,4 @@
+The naming of folders within cookbook directories must literally match
+the host notation used for template specificity matching. For example,
+if a host is named `foo.example.com`, then the folder must be named
+`host-foo.example.com`.
diff --git a/content/reusable/md/template_partials.md b/content/reusable/md/template_partials.md
new file mode 100644
index 0000000..4880372
--- /dev/null
+++ b/content/reusable/md/template_partials.md
@@ -0,0 +1,7 @@
+A template can be built in a way that allows it to contain references to
+one (or more) smaller template files. (These smaller template files are
+also referred to as partials.) A partial can be referenced from a
+template file in one of the following ways:
+
+- By using the `render` method in the template file
+- By using the **template** resource and the `variables` property.
diff --git a/content/reusable/md/template_partials_render_method.md b/content/reusable/md/template_partials_render_method.md
new file mode 100644
index 0000000..2471bde
--- /dev/null
+++ b/content/reusable/md/template_partials_render_method.md
@@ -0,0 +1,46 @@
+Use the `render` method in a template to reference a partial template
+file:
+
+```ruby
+<%= render 'partial_name.txt.erb', :option => {} %>
+```
+
+where `partial_name` is the name of the partial template file and
+`:option` is one (or more) of the following:
+
+
+
+
+
+
+
+
+
Option
+
Description
+
+
+
+
+
:cookbook
+
By default, a partial template file is assumed to be located in the cookbook that contains the top-level template. Use this option to specify the path to a different cookbook
+
+
+
:local
+
Indicates that the name of the partial template file should be interpreted as a path to a file in the local file system or looked up in a cookbook using the normal rules for template files. Set to true to interpret as a path to a file in the local file system and to false to use the normal rules for template files
+
+
+
:source
+
By default, a partial template file is identified by its file name. Use this option to specify a different name or a local path to use (instead of the name of the partial template file)
+
+
+
:variables
+
A hash of variable_name => value that will be made available to the partial template file. When this option is used, any variables that are defined in the top-level template that are required by the partial template file must have them defined explicitly using this option
+
+
+
+
+For example:
+
+```ruby
+<%= render 'simple.txt.erb', :variables => {:user => Etc.getlogin }, :local => true %>
+```
diff --git a/content/reusable/md/template_partials_variables_attribute.md b/content/reusable/md/template_partials_variables_attribute.md
new file mode 100644
index 0000000..e869622
--- /dev/null
+++ b/content/reusable/md/template_partials_variables_attribute.md
@@ -0,0 +1,22 @@
+The `variables` property of the **template** resource can be used to
+reference a partial template file by using a Hash. For example:
+
+```ruby
+template '/file/name.txt' do
+ variables partials: {
+ 'partial_name_1.txt.erb' => 'message',
+ 'partial_name_2.txt.erb' => 'message',
+ 'partial_name_3.txt.erb' => 'message',
+ }
+end
+```
+
+where each of the partial template files can then be combined using
+normal Ruby template patterns within a template file, such as:
+
+```ruby
+<% @partials.each do |partial, message| %>
+ Here is <%= partial %>
+ <%= render partial, :variables => {:message => message} %>
+<% end %>
+```
diff --git a/content/reusable/md/template_requirements.md b/content/reusable/md/template_requirements.md
new file mode 100644
index 0000000..65baded
--- /dev/null
+++ b/content/reusable/md/template_requirements.md
@@ -0,0 +1,55 @@
+To use a template, two things must happen:
+
+1. A template resource must be added to a recipe
+1. An Embedded Ruby (ERB) template must be added to a cookbook
+
+For example, the following template file and template resource settings
+can be used to manage a configuration file named `/etc/sudoers`. Within
+a cookbook that uses sudo, the following resource could be added to
+`/recipes/default.rb`:
+
+```ruby
+template '/etc/sudoers' do
+ source 'sudoers.erb'
+ mode '0440'
+ owner 'root'
+ group 'root'
+ variables(sudoers_groups: node['authorization']['sudo']['groups'],
+ sudoers_users: node['authorization']['sudo']['users'])
+end
+```
+
+And then create a template called `sudoers.erb` and save it to
+`templates/default/sudoers.erb`:
+
+```ruby
+#
+# /etc/sudoers
+#
+# Generated by Chef for <%= node['fqdn'] %>
+#
+
+Defaults !lecture,tty_tickets,!fqdn
+
+# User privilege specification
+root ALL=(ALL) ALL
+
+<% @sudoers_users.each do |user| -%>
+<%= user %> ALL=(ALL) <%= "NOPASSWD:" if @passwordless %>ALL
+<% end -%>
+
+# Members of the sysadmin group may gain root privileges
+%sysadmin ALL=(ALL) <%= "NOPASSWD:" if @passwordless %>ALL
+
+<% @sudoers_groups.each do |group| -%>
+# Members of the group '<%= group %>' may gain root privileges
+<%= group %> ALL=(ALL) <%= "NOPASSWD:" if @passwordless %>ALL
+<% end -%>
+```
+
+And then set the default attributes in `attributes/default.rb`:
+
+```ruby
+default['authorization']['sudo']['groups'] = %w(sysadmin wheel admin)
+default['authorization']['sudo']['users'] = %w(jerry greg)
+```
diff --git a/content/reusable/md/template_specificity.md b/content/reusable/md/template_specificity.md
new file mode 100644
index 0000000..cdda6ce
--- /dev/null
+++ b/content/reusable/md/template_specificity.md
@@ -0,0 +1,5 @@
+A cookbook is frequently designed to work across many platforms and is
+often required to distribute a specific template to a specific platform.
+A cookbook can be designed to support the distribution of templates
+across platforms, while ensuring that the correct template ends up on
+each system.
diff --git a/content/reusable/md/template_specificity_example.md b/content/reusable/md/template_specificity_example.md
new file mode 100644
index 0000000..20fd5b8
--- /dev/null
+++ b/content/reusable/md/template_specificity_example.md
@@ -0,0 +1,33 @@
+A cookbook may have a `/templates` directory structure like this:
+
+```ruby
+/templates/
+ windows-10
+ windows-6.3
+ windows
+ default
+```
+
+and a resource that looks something like the following:
+
+```ruby
+template 'C:\path\to\file\text_file.txt' do
+ source 'text_file.txt'
+ mode '0755'
+ owner 'root'
+ group 'root'
+end
+```
+
+This resource would be matched in the same order as the `/templates`
+directory structure. For a node named `host-node-desktop` that's
+running Windows 8.1, the second item would be the matching item and the
+location:
+
+```ruby
+/templates
+ windows-10/text_file.txt
+ windows-6.3/text_file.txt
+ windows/text_file.txt
+ default/text_file.txt
+```
diff --git a/content/reusable/md/template_specificity_pattern.md b/content/reusable/md/template_specificity_pattern.md
new file mode 100644
index 0000000..70a2e10
--- /dev/null
+++ b/content/reusable/md/template_specificity_pattern.md
@@ -0,0 +1,46 @@
+The pattern for template specificity depends on two things: the lookup
+path and the source. The first pattern that matches is used:
+
+1. `/host-$fqdn/$source`
+1. `/$platform-$platform_version/$source`
+1. `/$platform/$source`
+1. `/default/$source`
+1. `/$source`
+
+
+
+
+
Note
+
+
+To specify a particular Windows version, use the [operating system
+version
+number](https://docs.microsoft.com/en-us/windows/win32/sysinfo/operating-system-version).
+For example, a template in `templates/windows-6.3` will be deployed on
+systems installed with Windows 8.1.
+
+
+
+
+Use an array with the `source` property to define an explicit lookup
+path. For example:
+
+```ruby
+template '/test' do
+ source ["#{node.chef_environment}.erb", 'default.erb']
+end
+```
+
+The following example emulates the entire file specificity pattern by
+defining it as an explicit path:
+
+```ruby
+template '/test' do
+ source %W(
+ host-#{node['fqdn']}/test.erb
+ #{node['platform']}-#{node['platform_version']}/test.erb
+ #{node['platform']}/test.erb
+ default/test.erb
+ )
+end
+```
diff --git a/content/reusable/md/template_transfer_frequency.md b/content/reusable/md/template_transfer_frequency.md
new file mode 100644
index 0000000..868fe87
--- /dev/null
+++ b/content/reusable/md/template_transfer_frequency.md
@@ -0,0 +1,4 @@
+The Chef Infra Client caches a template when it's first requested. On
+each subsequent request for that template, the Chef Infra Client
+compares that request to the template located on Chef Infra Server.
+If the templates are the same, no transfer occurs.
diff --git a/content/reusable/md/template_variables.md b/content/reusable/md/template_variables.md
new file mode 100644
index 0000000..5914aba
--- /dev/null
+++ b/content/reusable/md/template_variables.md
@@ -0,0 +1,58 @@
+An Embedded Ruby (ERB) template allows Ruby code to be embedded inside a
+text file within specially formatted tags. Ruby code can be embedded
+using expressions and statements. An expression is delimited by `<%=`
+and `%>`. For example:
+
+```ruby
+<%= "my name is #{$ruby}" %>
+```
+
+A statement is delimited by a modifier, such as `if`, `elsif`, and
+`else`. For example:
+
+```ruby
+if false
+# this won't happen
+elsif nil
+ # this won't either
+ end
+```
+
+Using a Ruby expression is the most common approach for defining
+template variables because this is how all variables that are sent to a
+template are referenced. Whenever a template needs to use an `each`,
+`if`, or `end`, use a Ruby statement.
+
+When a template is rendered, Ruby expressions and statements are
+evaluated by Chef Infra Client. The variables listed in the **template**
+resource's `variables` parameter and in the node object are evaluated.
+Chef Infra Client then passes these variables to the template, where
+they will be accessible as instance variables within the template. The
+node object can be accessed just as if it were part of a recipe, using
+the same syntax.
+
+For example, a simple template resource like this:
+
+```ruby
+node['fqdn'] = 'latte'
+template '/tmp/foo' do
+ source 'foo.erb'
+ variables(x_men: 'are keen')
+end
+```
+
+And a simple Embedded Ruby (ERB) template like this:
+
+```ruby
+The node <%= node[:fqdn] %> thinks the x-men <%= @x_men %>
+```
+
+Would render something like:
+
+```plain
+The node latte thinks the x-men are keen
+```
+
+Even though this is a simple example, the full capabilities of Ruby
+can be used to tackle even the most complex and demanding template
+requirements.
diff --git a/content/reusable/md/unified_mode_actions_later_resources.md b/content/reusable/md/unified_mode_actions_later_resources.md
new file mode 100644
index 0000000..80ea220
--- /dev/null
+++ b/content/reusable/md/unified_mode_actions_later_resources.md
@@ -0,0 +1,70 @@
+
+## Actions on Later Resources
+
+Since Unified Mode executes your resource as it's compiled, `:immediate` notifications that execute later resources are handled differently than in the past.
+
+### `:immediate` Notifications to Later Resources
+
+Unified mode delays immediate notifications to later resources.
+In unified mode, the Chef Infra Client saves immediate notifications and executes them when the later resource is parsed. Immediate notifications to prior resources and delayed notifications behave the same as they did before unified mode.
+
+The result of sequentially chaining immediate notifications is the same as before unified mode. Instead of immediately notifying results, the notifications fire _in order_ as they're parsed, which has the same outcome. If the parse order and the intended execution order are different, then the results may be different and are a reflection of the parse order.
+
+The changes to sending immediate notification could result in subtle changes to behaviors in some resources, but it's not a breaking change to common patterns of writing resources.
+
+Chaining immediate notifications to later resources:
+
+```ruby
+remote_file "#{Chef::Config[:file_cache_path]}/myservice.tgz" do
+ source "http://acme.com/myservice.tgz"
+ notifies :extract, "archive_file[myservice.tgz]", :immediately
+end
+
+archive_file "#{Chef::Config[:file_cache_path]}/myservice.tgz" do
+ destination '/srv/myservice'
+ notifies :start, "service[myservice]", :immediately
+ action :nothing
+end
+
+service "myservice" do
+ action :nothing
+end
+```
+
+### `:before` Notifications to Later Resources
+
+In unified mode, you must declare a resource before sending a `before` notification to it.
+
+Resources that subscribe to a `before` notification to a later resource must be declared after the resource that triggers the notification.
+
+This resource declares a `before` notification to a later resource and will no longer work:
+
+```ruby
+package "myservice" do
+ notifies :stop, "service[myservice]", :before
+ notifies :start, "service[myservice]", :immediately
+end
+
+service "myservice" do
+ action :nothing
+end
+```
+
+Instead, declare the resource and then declare actions. For example:
+
+```ruby
+service "myservice" do
+ action :nothing
+end
+
+package "myservice" do
+ notifies :stop, "service[myservice]", :before
+ notifies :start, "service[myservice]", :immediately
+end
+```
+
+### Out of Order Execution
+
+Unified mode breaks custom resources that rely on the out-of-order execution of compile-time statements. Move any affected compile-time statements to the location in the code where they're intended to execute.
+
+Out-of-order execution is rare. Internally at Chef, none of our custom resources broke during our migration to unified mode. Instead, we discovered a few cases in which custom resource code was intended to run in order, but Chef Infra Client executed it out of order. In these cases, Unified Mode fixed errors instead of introducing bugs.
diff --git a/content/reusable/md/unified_mode_client_releases.md b/content/reusable/md/unified_mode_client_releases.md
new file mode 100644
index 0000000..3e1e79e
--- /dev/null
+++ b/content/reusable/md/unified_mode_client_releases.md
@@ -0,0 +1,13 @@
+Unified Mode (`unified_mode true`) is the default behavior starting in Chef Infra Client 18 (April 2022).
+
+See the following table for Chef Infra Client versions where Unified Mode can be enabled in custom resources:
+
+| Chef Infra Client | Unified Mode |
+|-------------------|-------------------------------|
+| 18.x (2022) | Default: `unified_mode true` |
+| 17.x (2021) | Default: `unified_mode false` |
+| 16.x (2020) | Default: `unified_mode false` |
+| 15.3 and higher | Default: `unified_mode false` |
+| 15.0-15.2 | Not available |
+| 14.14-14.15 | Default: `unified_mode false` |
+| Lower than 14.14 | Not available |
diff --git a/content/reusable/md/unified_mode_enable.md b/content/reusable/md/unified_mode_enable.md
new file mode 100644
index 0000000..1f7d06f
--- /dev/null
+++ b/content/reusable/md/unified_mode_enable.md
@@ -0,0 +1,14 @@
+Unified Mode is enabled by default starting in Chef Infra Client 18.
+
+In Chef Infra Client 17 (April 2021) and some earlier versions, you can enable Unified Mode in custom resources by adding `unified_mode true`. You can upgrade most custom resources to use Unified Mode without additional work other than testing and validation. See the following example:
+
+```ruby
+# enable unified mode
+unified_mode true
+
+provides :myresource
+
+actions :run do
+ [...]
+end
+```
diff --git a/content/reusable/md/unified_mode_overview.md b/content/reusable/md/unified_mode_overview.md
new file mode 100644
index 0000000..d71b5c8
--- /dev/null
+++ b/content/reusable/md/unified_mode_overview.md
@@ -0,0 +1,2 @@
+
+Unified mode is a setting that will compile and converge a custom resource's action block in one pass and in the order that the code inside that block is composed, from beginning to end. This replaces Chef Infra's two-pass parsing with single-pass parsing so that resources are executed as soon as they're declared. This results in clearer code and requires less Ruby knowledge to understand the order of operations.
diff --git a/content/reusable/md/unified_mode_troubleshooting.md b/content/reusable/md/unified_mode_troubleshooting.md
new file mode 100644
index 0000000..f1c030a
--- /dev/null
+++ b/content/reusable/md/unified_mode_troubleshooting.md
@@ -0,0 +1,88 @@
+
+## Troubleshooting Unified Mode
+
+Unified mode changes the execution of a custom resource to run in one phase, in the order that the code is written, from the first line of the code to the last. Custom resources designed to use two phases may need modification. These fall into three general types:
+
+- Resources with changes to internal sub-resources
+- Resources with actions on later resources
+- Resources that rely on the out-of-order execution
+
+When designing a custom resource for unified mode:
+
+- Declare a resource first and then declare actions on it
+- Write resources in run-time order
+
+### Resources with changes to internal sub-resources
+
+Some custom resources are designed to create and edit other sub-resources as part of the resource declaration. In unified mode, Chef Infra Client parses a resource code block that creates or edits a sub-resource and immediately tries to apply that change, even though the sub-resource doesn't yet exist. This results in the execution of an incomplete resource.
+
+For example, with Unified Mode enabled, this code from the dhcp cookbook is designed to create and edit a shared `dhcp_subnet` resource, but it won't work as expected:
+
+```ruby
+# 'edit_resource' results in an incomplete subresource
+sr = edit_resource(:dhcp_subnet, "#{new_resource.name}_sharedsubnet_#{subnet}") do
+ owner new_resource.owner
+ group new_resource.group
+ mode new_resource.mode
+
+ ip_version new_resource.ip_version
+ conf_dir new_resource.conf_dir
+ shared_network true
+end
+
+properties.each do |property, value|
+ sr.send(property, value)
+end
+```
+
+To correct custom resources that change sub-resources during their declaration, you can:
+
+- Apply properties in the code block (preferred)
+- Run the resource explicitly (not preferred)
+
+#### Apply properties in the code block
+
+This pattern declares the sub-resource in one code block and then changes it in the next code block. This is the preferred pattern in Unified Mode because all resources execute in order at compile time.
+
+```ruby
+dhcp_subnet "#{new_resource.name}_sharedsubnet_#{subnet}" do
+ owner new_resource.owner
+ group new_resource.group
+ mode new_resource.mode
+
+ ip_version new_resource.ip_version
+ conf_dir new_resource.conf_dir
+ shared_network true
+
+ properties.each do |property, value|
+ send(property, value)
+ end
+end
+```
+
+#### Run the resource explicitly
+
+Another solution is to continue saving the resource as a variable, declare `action :nothing` within the codeblock, and then explicitly run the action in another code block.
+
+The pattern of saving a resource as a variable and then forcing it to run at compile time with an explicit `run_action` works as it has in the past, but it's not a preferred pattern. Unified mode forces resource execution to compile time by default, which makes this pattern redundant.
+
+```ruby
+sr = edit_resource(:dhcp_subnet, "#{new_resource.name}_sharedsubnet_#{subnet}") do
+ owner new_resource.owner
+ group new_resource.group
+ mode new_resource.mode
+
+ ip_version new_resource.ip_version
+ conf_dir new_resource.conf_dir
+ shared_network true
+
+ action :nothing
+end
+
+properties.each do |property, value|
+ sr.send(property, value)
+end
+
+# Run the action explicitly
+sr.run_action(:create)
+```
diff --git a/content/reusable/md/windows_environment_variable_path.md b/content/reusable/md/windows_environment_variable_path.md
new file mode 100644
index 0000000..637ab7d
--- /dev/null
+++ b/content/reusable/md/windows_environment_variable_path.md
@@ -0,0 +1,11 @@
+On Windows, Chef Infra Client must have two entries added to
+the `PATH` environment variable:
+
+- `C:\opscode\chef\bin`
+- `C:\opscode\chef\embedded\bin`
+
+This is typically done during the installation of Chef Infra Client
+automatically. If these values (for any reason) aren't in the `PATH`
+environment variable, Chef Infra Client won't run properly.
+
+
diff --git a/content/reusable/md/windows_install_overview.md b/content/reusable/md/windows_install_overview.md
new file mode 100644
index 0000000..a6b6f5d
--- /dev/null
+++ b/content/reusable/md/windows_install_overview.md
@@ -0,0 +1,10 @@
+Chef Infra Client can be installed on machines running Windows
+in the following ways:
+
+- By bootstrapping Chef Infra Client using [knife
+ bootstrap](/workstation/knife_bootstrap/) from a local workstation using
+ WinRM
+- By downloading Chef Infra Client to the target node, and then
+ running the Microsoft Installer Package (MSI) locally
+- By using an existing process already in place for managing Microsoft
+ Windows machines, such as System Center
diff --git a/content/reusable/md/windows_install_system_center.md b/content/reusable/md/windows_install_system_center.md
new file mode 100644
index 0000000..9c88955
--- /dev/null
+++ b/content/reusable/md/windows_install_system_center.md
@@ -0,0 +1,4 @@
+Many organizations already have processes in place for managing the
+applications and settings on various Windows machines. For
+example, System Center. Chef Infra Client can be installed using this
+method.
diff --git a/content/reusable/md/windows_msiexec.md b/content/reusable/md/windows_msiexec.md
new file mode 100644
index 0000000..bc99991
--- /dev/null
+++ b/content/reusable/md/windows_msiexec.md
@@ -0,0 +1,15 @@
+Msiexec.exe is used to install Chef Infra Client on a node as part of a
+bootstrap operation. The actual command that's run by the default
+bootstrap script is:
+
+```bash
+msiexec /qn /i "%LOCAL_DESTINATION_MSI_PATH%"
+```
+
+where `/qn` is used to set the user interface level to "No UI", `/i` is
+used to define the location in which Chef Infra Client is installed, and
+`"%LOCAL_DESTINATION_MSI_PATH%"` is a variable defined in the default
+[windows-chef-client-msi.erb](https://github.com/chef/chef/blob/main/knife/lib/chef/knife/bootstrap/templates/windows-chef-client-msi.erb)
+bootstrap template. See
+
+for more information about the options available to Msiexec.exe.
diff --git a/content/reusable/md/windows_msiexec_addlocal.md b/content/reusable/md/windows_msiexec_addlocal.md
new file mode 100644
index 0000000..8201219
--- /dev/null
+++ b/content/reusable/md/windows_msiexec_addlocal.md
@@ -0,0 +1,36 @@
+The `ADDLOCAL` parameter adds two setup options specific to Chef Infra
+Client. These options can be passed along with an Msiexec.exe command:
+
+
+
+
+
+
+
+
+
Option
+
Description
+
+
+
+
+
ChefClientFeature
+
Use to install Chef Infra Client.
+
+
+
ChefSchTaskFeature
+
Use to configure Chef Infra Client as a scheduled task in Windows.
+
+
+
ChefPSModuleFeature
+
Used to install the chef PowerShell module. This will enable chef command line utilities within PowerShell.
+
+
+
+
+First install Chef Infra Client, and then enable it to run as a
+scheduled task. For example:
+
+```bash
+msiexec /qn /i C:\inst\chef-client-15.3.14-1-x64.msi ADDLOCAL="ChefClientFeature,ChefSchTaskFeature,ChefPSModuleFeature"
+```
diff --git a/content/reusable/md/windows_spaces_and_directories.md b/content/reusable/md/windows_spaces_and_directories.md
new file mode 100644
index 0000000..94f17b7
--- /dev/null
+++ b/content/reusable/md/windows_spaces_and_directories.md
@@ -0,0 +1,4 @@
+Directories that are used by Chef products on Windows can't have
+spaces. For example, `C:\Users\User Name` won't work, but
+`C:\Users\UserName` will. Chef commands may fail if used against a
+directory with a space in its name.
diff --git a/content/reusable/md/windows_top_level_directory_names.md b/content/reusable/md/windows_top_level_directory_names.md
new file mode 100644
index 0000000..a7f1353
--- /dev/null
+++ b/content/reusable/md/windows_top_level_directory_names.md
@@ -0,0 +1,6 @@
+Windows will throw errors when path name lengths are too long. For this
+reason, it's often helpful to use a short top-level directory, much
+like what's done in UNIX and Linux. For example, Chef uses `/opt/` to
+install Chef Workstation on macOS. A similar approach can be done on
+Windows, by creating a top-level directory with a short name.
+For example: `C:\chef`.
diff --git a/content/reusable/md/workstation/ctl_chef_clean_policy_cookbooks.md b/content/reusable/md/workstation/ctl_chef_clean_policy_cookbooks.md
new file mode 100644
index 0000000..2462e7b
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_clean_policy_cookbooks.md
@@ -0,0 +1,11 @@
+Use the `chef clean-policy-cookbooks` subcommand to delete cookbooks
+that are not used by Policyfile files. Cookbooks are considered unused
+when they are not referenced by any policy revisions on the Chef Infra
+Server.
+
+{{< note >}}
+
+Cookbooks that are referenced by orphaned policy revisions are not
+removed. Use `chef clean-policy-revisions` to remove orphaned policies.
+
+{{< /note >}}
diff --git a/content/reusable/md/workstation/ctl_chef_clean_policy_cookbooks_options.md b/content/reusable/md/workstation/ctl_chef_clean_policy_cookbooks_options.md
new file mode 100644
index 0000000..d3a3e8b
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_clean_policy_cookbooks_options.md
@@ -0,0 +1,17 @@
+This subcommand has the following options:
+
+`-c CONFIG_FILE`, `--config CONFIG_FILE`
+
+: The path to the knife configuration file.
+
+`-D`, `--debug`
+
+: Enable stack traces and other debug output. Default value: `false`.
+
+`-h`, `--help`
+
+: Show help for the command.
+
+`-v`, `--version`
+
+: The Chef Infra Client version.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/ctl_chef_clean_policy_cookbooks_syntax.md b/content/reusable/md/workstation/ctl_chef_clean_policy_cookbooks_syntax.md
new file mode 100644
index 0000000..03badb8
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_clean_policy_cookbooks_syntax.md
@@ -0,0 +1,5 @@
+This subcommand has the following syntax:
+
+```bash
+chef clean-policy-cookbooks (options)
+```
diff --git a/content/reusable/md/workstation/ctl_chef_clean_policy_revisions.md b/content/reusable/md/workstation/ctl_chef_clean_policy_revisions.md
new file mode 100644
index 0000000..db8df0e
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_clean_policy_revisions.md
@@ -0,0 +1,6 @@
+Use the `chef clean-policy-revisions` subcommand to delete orphaned
+policy revisions to Policyfile files from the Chef Infra Server. An
+orphaned policy revision is not associated to any policy group and
+therefore is not in active use by any node. Use
+`chef show-policy --orphans` to view a list of orphaned policy
+revisions.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/ctl_chef_clean_policy_revisions_options.md b/content/reusable/md/workstation/ctl_chef_clean_policy_revisions_options.md
new file mode 100644
index 0000000..d3a3e8b
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_clean_policy_revisions_options.md
@@ -0,0 +1,17 @@
+This subcommand has the following options:
+
+`-c CONFIG_FILE`, `--config CONFIG_FILE`
+
+: The path to the knife configuration file.
+
+`-D`, `--debug`
+
+: Enable stack traces and other debug output. Default value: `false`.
+
+`-h`, `--help`
+
+: Show help for the command.
+
+`-v`, `--version`
+
+: The Chef Infra Client version.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/ctl_chef_clean_policy_revisions_syntax.md b/content/reusable/md/workstation/ctl_chef_clean_policy_revisions_syntax.md
new file mode 100644
index 0000000..9069aa6
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_clean_policy_revisions_syntax.md
@@ -0,0 +1,5 @@
+This subcommand has the following syntax:
+
+```bash
+chef clean-policy-revisions (options)
+```
diff --git a/content/reusable/md/workstation/ctl_chef_client_bootstrap_initial_run_list.md b/content/reusable/md/workstation/ctl_chef_client_bootstrap_initial_run_list.md
new file mode 100644
index 0000000..618c53a
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_client_bootstrap_initial_run_list.md
@@ -0,0 +1,31 @@
+A node's initial run-list is specified using a JSON file on the host
+system. When running Chef Infra Client as an executable, use the `-j`
+option to tell Chef Infra Client which JSON file to use. For example:
+
+```bash
+chef-client -j /etc/chef/file.json --environment _default
+```
+
+where `file.json` is similar to:
+
+```javascript
+{
+ "resolver": {
+ "nameservers": [ "10.0.0.1" ],
+ "search":"int.example.com"
+ },
+ "run_list": [ "recipe[resolver]" ]
+}
+```
+
+and where `_default` is the name of the environment that is assigned to
+the node.
+
+{{< warning >}}
+
+This approach may be used to update
+[normal](/attributes.html#attribute-types) attributes, but should never
+be used to update any other attribute type, as all attributes updated
+using this option are treated as `normal` attributes.
+
+{{< /warning >}}
diff --git a/content/reusable/md/workstation/ctl_chef_client_elevated_privileges.md b/content/reusable/md/workstation/ctl_chef_client_elevated_privileges.md
new file mode 100644
index 0000000..ed10d9f
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_client_elevated_privileges.md
@@ -0,0 +1,5 @@
+The Chef Infra Client may need to be run with elevated privileges in
+order to get a recipe to converge correctly. On UNIX and UNIX-like
+operating systems this can be done by running the command as root. On
+Windows this can be done by running the command prompt as an
+administrator.
diff --git a/content/reusable/md/workstation/ctl_chef_client_elevated_privileges_windows.md b/content/reusable/md/workstation/ctl_chef_client_elevated_privileges_windows.md
new file mode 100644
index 0000000..8c5047f
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_client_elevated_privileges_windows.md
@@ -0,0 +1,22 @@
+On Windows, running without elevated privileges (when they are
+necessary) is an issue that fails silently. It will appear that Chef
+Infra Client completed its run successfully, but the changes will not
+have been made. When this occurs, do one of the following to run Chef
+Infra Client as the administrator:
+
+- Log in to the administrator account. (This is not the same as an
+ account in the administrator's security group.)
+
+- Run Chef Infra Client process from the administrator account while
+ being logged into another account. Run the following command:
+
+ ```bash
+ runas /user:Administrator "cmd /C chef-client"
+ ```
+
+ This will prompt for the administrator account password.
+
+- Open a command prompt by right-clicking on the command prompt
+ application, and then selecting **Run as administrator**. After the
+ command window opens, Chef Infra Client can be run as the
+ administrator
diff --git a/content/reusable/md/workstation/ctl_chef_client_options_format.md b/content/reusable/md/workstation/ctl_chef_client_options_format.md
new file mode 100644
index 0000000..756c4cb
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_client_options_format.md
@@ -0,0 +1,16 @@
+The output format: `doc` (default) or `min`.
+
+- Use `doc` to print the progress of a Chef Infra Client run using
+ full strings that display a summary of updates as they occur.
+- Use `min` to print the progress of a Chef Infra Client run using
+ single characters.
+
+A summary of updates is printed at the end of a Chef Infra Client run. A
+dot (`.`) is printed for events that do not have meaningful status
+information, such as loading a file or synchronizing a cookbook. For
+resources, a dot (`.`) is printed when the resource is up to date, an
+`S` is printed when the resource is skipped by `not_if` or `only_if`,
+and a `U` is printed when the resource is updated.
+
+Other formatting options are available when those formatters are
+configured in the client.rb file using the `add_formatter` option.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/ctl_chef_delete_policy.md b/content/reusable/md/workstation/ctl_chef_delete_policy.md
new file mode 100644
index 0000000..01ab9b4
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_delete_policy.md
@@ -0,0 +1,4 @@
+Use the `chef delete-policy` subcommand to delete all revisions of the
+named policy that exist on the Chef Infra Server. (The state of the
+policy revision is backed up locally and may be restored using the
+`chef undelete` subcommand.)
\ No newline at end of file
diff --git a/content/reusable/md/workstation/ctl_chef_delete_policy_group.md b/content/reusable/md/workstation/ctl_chef_delete_policy_group.md
new file mode 100644
index 0000000..ce01298
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_delete_policy_group.md
@@ -0,0 +1,5 @@
+Use the `chef delete-policy-group` subcommand to delete the named policy
+group from the Chef Infra Server. Any policy revision associated with
+that policy group is not deleted. (The state of the policy group is
+backed up locally and may be restored using the `chef undelete`
+subcommand.)
\ No newline at end of file
diff --git a/content/reusable/md/workstation/ctl_chef_delete_policy_group_options.md b/content/reusable/md/workstation/ctl_chef_delete_policy_group_options.md
new file mode 100644
index 0000000..d3a3e8b
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_delete_policy_group_options.md
@@ -0,0 +1,17 @@
+This subcommand has the following options:
+
+`-c CONFIG_FILE`, `--config CONFIG_FILE`
+
+: The path to the knife configuration file.
+
+`-D`, `--debug`
+
+: Enable stack traces and other debug output. Default value: `false`.
+
+`-h`, `--help`
+
+: Show help for the command.
+
+`-v`, `--version`
+
+: The Chef Infra Client version.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/ctl_chef_delete_policy_group_syntax.md b/content/reusable/md/workstation/ctl_chef_delete_policy_group_syntax.md
new file mode 100644
index 0000000..43e6aa4
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_delete_policy_group_syntax.md
@@ -0,0 +1,5 @@
+This subcommand has the following syntax:
+
+```bash
+chef delete-policy-group POLICY_GROUP (options)
+```
diff --git a/content/reusable/md/workstation/ctl_chef_delete_policy_options.md b/content/reusable/md/workstation/ctl_chef_delete_policy_options.md
new file mode 100644
index 0000000..d3a3e8b
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_delete_policy_options.md
@@ -0,0 +1,17 @@
+This subcommand has the following options:
+
+`-c CONFIG_FILE`, `--config CONFIG_FILE`
+
+: The path to the knife configuration file.
+
+`-D`, `--debug`
+
+: Enable stack traces and other debug output. Default value: `false`.
+
+`-h`, `--help`
+
+: Show help for the command.
+
+`-v`, `--version`
+
+: The Chef Infra Client version.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/ctl_chef_delete_policy_syntax.md b/content/reusable/md/workstation/ctl_chef_delete_policy_syntax.md
new file mode 100644
index 0000000..49b8fbd
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_delete_policy_syntax.md
@@ -0,0 +1,5 @@
+This subcommand has the following syntax:
+
+```bash
+chef delete-policy POLICY_NAME (options)
+```
diff --git a/content/reusable/md/workstation/ctl_chef_diff.md b/content/reusable/md/workstation/ctl_chef_diff.md
new file mode 100644
index 0000000..320d6c3
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_diff.md
@@ -0,0 +1,2 @@
+Use the `chef diff` subcommand to display an itemized comparison of two
+revisions of a `Policyfile.lock.json` file.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/ctl_chef_diff_current_lock_latest_branch.md b/content/reusable/md/workstation/ctl_chef_diff_current_lock_latest_branch.md
new file mode 100644
index 0000000..66c586f
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_diff_current_lock_latest_branch.md
@@ -0,0 +1,3 @@
+```bash
+chef diff --git HEAD
+```
diff --git a/content/reusable/md/workstation/ctl_chef_diff_current_lock_master_branch.md b/content/reusable/md/workstation/ctl_chef_diff_current_lock_master_branch.md
new file mode 100644
index 0000000..7ff0c34
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_diff_current_lock_master_branch.md
@@ -0,0 +1,3 @@
+```bash
+chef diff --git master
+```
diff --git a/content/reusable/md/workstation/ctl_chef_diff_current_lock_policy_group.md b/content/reusable/md/workstation/ctl_chef_diff_current_lock_policy_group.md
new file mode 100644
index 0000000..d0ea97e
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_diff_current_lock_policy_group.md
@@ -0,0 +1,3 @@
+```bash
+chef diff staging
+```
diff --git a/content/reusable/md/workstation/ctl_chef_diff_current_lock_specified_revision.md b/content/reusable/md/workstation/ctl_chef_diff_current_lock_specified_revision.md
new file mode 100644
index 0000000..7c6d930
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_diff_current_lock_specified_revision.md
@@ -0,0 +1,3 @@
+```bash
+chef diff --git v1.0.0
+```
diff --git a/content/reusable/md/workstation/ctl_chef_diff_master_lock_revision_lock.md b/content/reusable/md/workstation/ctl_chef_diff_master_lock_revision_lock.md
new file mode 100644
index 0000000..b799706
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_diff_master_lock_revision_lock.md
@@ -0,0 +1,3 @@
+```bash
+chef diff --git master...dev
+```
diff --git a/content/reusable/md/workstation/ctl_chef_diff_options.md b/content/reusable/md/workstation/ctl_chef_diff_options.md
new file mode 100644
index 0000000..a566045
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_diff_options.md
@@ -0,0 +1,35 @@
+This subcommand has the following options:
+
+`-c CONFIG_FILE`, `--config CONFIG_FILE`
+
+: The path to the knife configuration file.
+
+`-D`, `--debug`
+
+: Enable stack traces and other debug output. Default value: `false`.
+
+`-g GIT_REF`, `--git GIT_REF`
+
+: Compare the specified git reference against the current revision of
+ a `Policyfile.lock.json` file or against another git reference.
+
+`-h`, `--help`
+
+: Show help for the command.
+
+`--head`
+
+: A shortcut for `chef diff --git HEAD`. When a git-specific flag is
+ not provided, the on-disk `Policyfile.lock.json` file is compared to
+ one on the Chef Infra Server or (if a `Policyfile.lock.json` file is
+ not present on-disk) two `Policyfile.lock.json` files in the
+ specified policy group on the Chef Infra Server are compared.
+
+`--[no-]pager`
+
+: Use `--pager` to enable paged output for a `Policyfile.lock.json`
+ file. Default value: `--pager`.
+
+`-v`, `--version`
+
+: The Chef Infra Client version.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/ctl_chef_diff_syntax.md b/content/reusable/md/workstation/ctl_chef_diff_syntax.md
new file mode 100644
index 0000000..8df1909
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_diff_syntax.md
@@ -0,0 +1,5 @@
+This subcommand has the following syntax:
+
+```bash
+chef diff POLICY_FILE --head | --git POLICY_GROUP | POLICY_GROUP...POLICY_GROUP (options)
+```
diff --git a/content/reusable/md/workstation/ctl_chef_diff_two_policy_groups.md b/content/reusable/md/workstation/ctl_chef_diff_two_policy_groups.md
new file mode 100644
index 0000000..4b226a1
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_diff_two_policy_groups.md
@@ -0,0 +1,3 @@
+```bash
+chef diff production...staging
+```
diff --git a/content/reusable/md/workstation/ctl_chef_diff_version_lock_master_branch.md b/content/reusable/md/workstation/ctl_chef_diff_version_lock_master_branch.md
new file mode 100644
index 0000000..3366685
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_diff_version_lock_master_branch.md
@@ -0,0 +1,3 @@
+```bash
+chef diff --git v1.0.0...master
+```
diff --git a/content/reusable/md/workstation/ctl_chef_export.md b/content/reusable/md/workstation/ctl_chef_export.md
new file mode 100644
index 0000000..0200ce9
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_export.md
@@ -0,0 +1,5 @@
+Use the `chef export` subcommand to create a chef-zero-compatible
+chef-repo that contains the cookbooks described by a
+`Policyfile.lock.json` file. After a chef-zero-compatible chef-repo is
+copied to a node, the policy can be applied locally on that machine by
+running `chef-client -z` (local mode).
\ No newline at end of file
diff --git a/content/reusable/md/workstation/ctl_chef_export_options.md b/content/reusable/md/workstation/ctl_chef_export_options.md
new file mode 100644
index 0000000..f5bd9ff
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_export_options.md
@@ -0,0 +1,23 @@
+This subcommand has the following options:
+
+`-a`, `--archive`
+
+: Export an archive as a tarball, instead as a directory. Default
+ value: `false`.
+
+`-D`, `--debug`
+
+: Enable stack traces and other debug output. Default value: `false`.
+
+`-f`, `--force`
+
+: Remove the contents of the destination directory if that directory
+ is not empty. Default value: `false`.
+
+`-h`, `--help`
+
+: Show help for the command.
+
+`-v`, `--version`
+
+: The Chef Infra Client version.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/ctl_chef_export_syntax.md b/content/reusable/md/workstation/ctl_chef_export_syntax.md
new file mode 100644
index 0000000..c01b7a7
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_export_syntax.md
@@ -0,0 +1,5 @@
+This subcommand has the following syntax:
+
+```bash
+chef export POLICY_FILE DIRECTORY (options)
+```
diff --git a/content/reusable/md/workstation/ctl_chef_generate_policyfile.md b/content/reusable/md/workstation/ctl_chef_generate_policyfile.md
new file mode 100644
index 0000000..9c7c09b
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_generate_policyfile.md
@@ -0,0 +1,2 @@
+Use the `chef generate policyfile` subcommand to generate a file to be
+used with Policyfile.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/ctl_chef_generate_policyfile_options.md b/content/reusable/md/workstation/ctl_chef_generate_policyfile_options.md
new file mode 100644
index 0000000..c0d7d62
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_generate_policyfile_options.md
@@ -0,0 +1,9 @@
+This subcommand has the following options:
+
+`-h`, `--help`
+
+: Show help for the command.
+
+`-v`, `--version`
+
+: The Chef Infra Client version.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/ctl_chef_generate_policyfile_syntax.md b/content/reusable/md/workstation/ctl_chef_generate_policyfile_syntax.md
new file mode 100644
index 0000000..db4527f
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_generate_policyfile_syntax.md
@@ -0,0 +1,5 @@
+This subcommand has the following syntax:
+
+```bash
+chef generate policyfile POLICY_NAME (options)
+```
diff --git a/content/reusable/md/workstation/ctl_chef_generate_repo.md b/content/reusable/md/workstation/ctl_chef_generate_repo.md
new file mode 100644
index 0000000..15d4523
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_generate_repo.md
@@ -0,0 +1,3 @@
+Use the `chef generate repo` subcommand to create a chef-repo. By
+default, the repo is a cookbook repo with options available to support
+generating a cookbook that supports Policyfile.
diff --git a/content/reusable/md/workstation/ctl_chef_generate_repo_options.md b/content/reusable/md/workstation/ctl_chef_generate_repo_options.md
new file mode 100644
index 0000000..ef53b40
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_generate_repo_options.md
@@ -0,0 +1,23 @@
+This subcommand has the following options:
+
+`-h`, `--help`
+
+: Show help for the command.
+
+`-p`, `--policy-only`
+
+: Create a repository that does not store cookbook files, only
+ Policyfile files.
+
+`-P`, `--policy`
+
+: Use Policyfile instead of Berkshelf.
+
+`-r`, `--roles`
+
+: Create directories for `/roles` and `/environments` instead of
+ creating directories for Policyfile.
+
+`-v`, `--version`
+
+: The Chef Infra Client version.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/ctl_chef_generate_repo_syntax.md b/content/reusable/md/workstation/ctl_chef_generate_repo_syntax.md
new file mode 100644
index 0000000..6c5cf63
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_generate_repo_syntax.md
@@ -0,0 +1,5 @@
+This subcommand has the following syntax:
+
+```bash
+chef generate repo REPO_NAME (options)
+```
diff --git a/content/reusable/md/workstation/ctl_chef_install.md b/content/reusable/md/workstation/ctl_chef_install.md
new file mode 100644
index 0000000..25a60bb
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_install.md
@@ -0,0 +1,7 @@
+Use the `chef install` subcommand to evaluate a Policyfile and find a
+compatible set of cookbooks, build a run-list, cache it locally, and
+then emit a `Policyfile.lock.json` file that describes the locked policy
+set. The `Policyfile.lock.json` file may be used to install the locked
+policy set to other machines and may be pushed to a policy group on the
+Chef Infra Server to apply that policy to a group of nodes that are
+under management by Chef.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/ctl_chef_install_options.md b/content/reusable/md/workstation/ctl_chef_install_options.md
new file mode 100644
index 0000000..fbd256f
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_install_options.md
@@ -0,0 +1,13 @@
+This subcommand has the following options:
+
+`-D`, `--debug`
+
+: Enable stack traces and other debug output.
+
+`-h`, `--help`
+
+: Show help for the command.
+
+`-v`, `--version`
+
+: The Chef Infra Client version.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/ctl_chef_install_syntax.md b/content/reusable/md/workstation/ctl_chef_install_syntax.md
new file mode 100644
index 0000000..bc8e840
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_install_syntax.md
@@ -0,0 +1,5 @@
+This subcommand has the following syntax:
+
+```bash
+chef install POLICY_FILE (options)
+```
diff --git a/content/reusable/md/workstation/ctl_chef_push.md b/content/reusable/md/workstation/ctl_chef_push.md
new file mode 100644
index 0000000..92cb6fe
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_push.md
@@ -0,0 +1,5 @@
+Use the `chef push` subcommand to upload an existing
+`Policyfile.lock.json` file to the Chef Infra Server, along with all of
+the cookbooks that are contained in the file. The `Policyfile.lock.json`
+file will be applied to the specified policy group, which is a set of
+nodes that share the same run-list and cookbooks.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/ctl_chef_push_archive.md b/content/reusable/md/workstation/ctl_chef_push_archive.md
new file mode 100644
index 0000000..927f4e5
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_push_archive.md
@@ -0,0 +1,5 @@
+The `chef push-archive` subcommand is used to publish a policy archive
+file to the Chef Infra Server. (A policy archive is created using the
+`chef export` subcommand.) The policy archive is assigned to the
+specified policy group, which is a set of nodes that share the same
+run-list and cookbooks.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/ctl_chef_push_archive_options.md b/content/reusable/md/workstation/ctl_chef_push_archive_options.md
new file mode 100644
index 0000000..d3a3e8b
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_push_archive_options.md
@@ -0,0 +1,17 @@
+This subcommand has the following options:
+
+`-c CONFIG_FILE`, `--config CONFIG_FILE`
+
+: The path to the knife configuration file.
+
+`-D`, `--debug`
+
+: Enable stack traces and other debug output. Default value: `false`.
+
+`-h`, `--help`
+
+: Show help for the command.
+
+`-v`, `--version`
+
+: The Chef Infra Client version.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/ctl_chef_push_archive_syntax.md b/content/reusable/md/workstation/ctl_chef_push_archive_syntax.md
new file mode 100644
index 0000000..55732c6
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_push_archive_syntax.md
@@ -0,0 +1,5 @@
+This subcommand has the following syntax:
+
+```bash
+chef push-archive POLICY_GROUP ARCHIVE_FILE (options)
+```
diff --git a/content/reusable/md/workstation/ctl_chef_push_options.md b/content/reusable/md/workstation/ctl_chef_push_options.md
new file mode 100644
index 0000000..f189836
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_push_options.md
@@ -0,0 +1,17 @@
+This subcommand has the following options:
+
+`-c CONFIG_FILE`, `--config CONFIG_FILE`
+
+: The path to the knife configuration file.
+
+`-D`, `--debug`
+
+: Enable stack traces and other debug output.
+
+`-h`, `--help`
+
+: Show help for the command.
+
+`-v`, `--version`
+
+: The Chef Infra Client version.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/ctl_chef_push_syntax.md b/content/reusable/md/workstation/ctl_chef_push_syntax.md
new file mode 100644
index 0000000..568b1c8
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_push_syntax.md
@@ -0,0 +1,5 @@
+This subcommand has the following syntax:
+
+```bash
+chef push POLICY_GROUP POLICY_FILE (options)
+```
diff --git a/content/reusable/md/workstation/ctl_chef_show_policy.md b/content/reusable/md/workstation/ctl_chef_show_policy.md
new file mode 100644
index 0000000..6689bf3
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_show_policy.md
@@ -0,0 +1,5 @@
+Use the `chef show-policy` subcommand to display revisions for every
+`Policyfile.rb` file that is on the Chef Infra Server. By default, only
+active policy revisions are shown. When both a policy and policy group
+are specified, the contents of the active `Policyfile.lock.json` file
+for the policy group is returned.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/ctl_chef_show_policy_options.md b/content/reusable/md/workstation/ctl_chef_show_policy_options.md
new file mode 100644
index 0000000..52aee85
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_show_policy_options.md
@@ -0,0 +1,27 @@
+This subcommand has the following options:
+
+`-c CONFIG_FILE`, `--config CONFIG_FILE`
+
+: The path to the knife configuration file.
+
+`-D`, `--debug`
+
+: Enable stack traces and other debug output. Default value: `false`.
+
+`-h`, `--help`
+
+: Show help for the command.
+
+`-o`, `--orphans`
+
+: Show policy revisions that are not currently assigned to any policy
+ group.
+
+`--[no-]pager`
+
+: Use `--pager` to enable paged output for a `Policyfile.lock.json`
+ file. Default value: `--pager`.
+
+`-v`, `--version`
+
+: The Chef Infra Client version.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/ctl_chef_show_policy_syntax.md b/content/reusable/md/workstation/ctl_chef_show_policy_syntax.md
new file mode 100644
index 0000000..958ff52
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_show_policy_syntax.md
@@ -0,0 +1,5 @@
+This subcommand has the following syntax:
+
+```bash
+chef show-policy POLICY_NAME POLICY_GROUP (options)
+```
diff --git a/content/reusable/md/workstation/ctl_chef_undelete.md b/content/reusable/md/workstation/ctl_chef_undelete.md
new file mode 100644
index 0000000..e349d86
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_undelete.md
@@ -0,0 +1,9 @@
+Use the `chef undelete` subcommand to recover a deleted policy or policy
+group. This command:
+
+- Does not detect conflicts. If a deleted item has been recreated,
+ running this command will overwrite it
+- Does not include cookbooks that may be referenced by Policyfiles;
+ cookbooks that are cleaned after running this command may not be
+ fully restorable to their previous state
+- Does not store access control data
\ No newline at end of file
diff --git a/content/reusable/md/workstation/ctl_chef_undelete_options.md b/content/reusable/md/workstation/ctl_chef_undelete_options.md
new file mode 100644
index 0000000..74aa8a4
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_undelete_options.md
@@ -0,0 +1,29 @@
+This subcommand has the following options:
+
+`-c CONFIG_FILE`, `--config CONFIG_FILE`
+
+: The path to the knife configuration file.
+
+`-D`, `--debug`
+
+: Enable stack traces and other debug output.
+
+`-h`, `--help`
+
+: Show help for the command.
+
+`-i ID`, `--id ID`
+
+: Undo the delete operation specified by `ID`.
+
+`-l`, `--last`
+
+: Undo the most recent delete operation.
+
+`--list`
+
+: Default. Return a list of available operations.
+
+`-v`, `--version`
+
+: The Chef Infra Client version.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/ctl_chef_undelete_syntax.md b/content/reusable/md/workstation/ctl_chef_undelete_syntax.md
new file mode 100644
index 0000000..5746ba8
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_undelete_syntax.md
@@ -0,0 +1,7 @@
+This subcommand has the following syntax:
+
+```bash
+chef undelete (options)
+```
+
+When run with no arguments, returns a list of available operations.
diff --git a/content/reusable/md/workstation/ctl_chef_update.md b/content/reusable/md/workstation/ctl_chef_update.md
new file mode 100644
index 0000000..709776f
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_update.md
@@ -0,0 +1,6 @@
+Use the `chef update` subcommand to read the `Policyfile.rb` file, and
+then apply any changes. This will resolve dependencies and will create a
+`Policyfile.lock.json` file. The locked policy will reflect any changes
+to the run-list and will pull in any cookbook updates that are
+compatible with any version constraints defined in the `Policyfile.rb`
+file.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/ctl_chef_update_options.md b/content/reusable/md/workstation/ctl_chef_update_options.md
new file mode 100644
index 0000000..d030e9a
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_update_options.md
@@ -0,0 +1,17 @@
+This subcommand has the following options:
+
+`-a`, `--attributes`
+
+: Update attributes. Default value: `false`.
+
+`-D`, `--debug`
+
+: Enable stack traces and other debug output. Default value: `false`.
+
+`-h`, `--help`
+
+: Show help for the command.
+
+`-v`, `--version`
+
+: The Chef Infra Client version.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/ctl_chef_update_syntax.md b/content/reusable/md/workstation/ctl_chef_update_syntax.md
new file mode 100644
index 0000000..70ba5fd
--- /dev/null
+++ b/content/reusable/md/workstation/ctl_chef_update_syntax.md
@@ -0,0 +1,5 @@
+This subcommand has the following syntax:
+
+```bash
+chef update POLICY_FILE (options)
+```
diff --git a/content/reusable/md/workstation/knife_bootstrap_node_fips.md b/content/reusable/md/workstation/knife_bootstrap_node_fips.md
new file mode 100644
index 0000000..05a7319
--- /dev/null
+++ b/content/reusable/md/workstation/knife_bootstrap_node_fips.md
@@ -0,0 +1,11 @@
+```bash
+knife bootstrap 192.0.2.0 -P vanilla -x root -r 'recipe[apt],recipe[xfs],recipe[vim]' --fips
+```
+
+which shows something similar to:
+
+```none
+OpenSSL FIPS 140 mode enabled
+...
+192.0.2.0 Chef Infra Client finished, 12/12 resources updated in 78.942455583 seconds
+```
diff --git a/content/reusable/md/workstation/knife_common_see_all_config_options.md b/content/reusable/md/workstation/knife_common_see_all_config_options.md
new file mode 100644
index 0000000..cf4fe1e
--- /dev/null
+++ b/content/reusable/md/workstation/knife_common_see_all_config_options.md
@@ -0,0 +1,3 @@
+See [config.rb](/workstation/config_rb_optional_settings/) for more information
+about how to add certain knife options as settings in the config.rb
+file.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/knife_common_windows_quotes.md b/content/reusable/md/workstation/knife_common_windows_quotes.md
new file mode 100644
index 0000000..9da2313
--- /dev/null
+++ b/content/reusable/md/workstation/knife_common_windows_quotes.md
@@ -0,0 +1,18 @@
+When running knife in Windows, a string may be interpreted as
+a wildcard pattern when quotes are not present in the command. The
+number of quotes to use depends on the shell from which the command is
+being run.
+
+When running knife from the command prompt, a string should be
+surrounded by single quotes (`' '`). For example:
+
+```bash
+knife node run_list set test-node 'recipe[iptables]'
+```
+
+When running knife from Windows PowerShell, a string should be
+surrounded by triple single quotes (`''' '''`). For example:
+
+```bash
+knife node run_list set test-node '''recipe[iptables]'''
+```
diff --git a/content/reusable/md/workstation/knife_common_windows_quotes_module.md b/content/reusable/md/workstation/knife_common_windows_quotes_module.md
new file mode 100644
index 0000000..f18107d
--- /dev/null
+++ b/content/reusable/md/workstation/knife_common_windows_quotes_module.md
@@ -0,0 +1,53 @@
+The Chef Infra Client 12.4 release adds an optional feature to the Microsoft
+Installer Package (MSI) for Chef. This feature enables the ability to
+pass quoted strings from the Windows PowerShell command line without the
+need for triple single quotes (`''' '''`). This feature installs a
+Windows PowerShell module (typically in `C:\opscode\chef\modules`) that
+is also appended to the `PSModulePath` environment variable. This
+feature is not enabled by default. To activate this feature, run the
+following command from within Windows PowerShell:
+
+```bash
+Import-Module chef
+```
+
+or add `Import-Module chef` to the profile for Windows PowerShell
+located at:
+
+```bash
+~\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1
+```
+
+This module exports cmdlets that have the same name as the command-line
+tools---chef-client, knife---that are built into Chef.
+
+For example:
+
+```bash
+knife exec -E 'puts ARGV' """&s0meth1ng"""
+```
+
+is now:
+
+```bash
+knife exec -E 'puts ARGV' '&s0meth1ng'
+```
+
+and:
+
+```bash
+knife node run_list set test-node '''role[ssssssomething]'''
+```
+
+is now:
+
+```bash
+knife node run_list set test-node 'role[ssssssomething]'
+```
+
+To remove this feature, run the following command from within Windows
+PowerShell:
+
+```bash
+Remove-Module chef
+```
diff --git a/content/reusable/md/workstation/knife_data_bag_edit.md b/content/reusable/md/workstation/knife_data_bag_edit.md
new file mode 100644
index 0000000..3af67a0
--- /dev/null
+++ b/content/reusable/md/workstation/knife_data_bag_edit.md
@@ -0,0 +1,4 @@
+Use the `edit` argument to edit the data contained in a data bag. If
+encryption is being used, the data bag will be decrypted, the data will
+be made available in the \$EDITOR, and then encrypted again before
+saving it to the Chef Infra Server.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/knife_data_bag_edit_item.md b/content/reusable/md/workstation/knife_data_bag_edit_item.md
new file mode 100644
index 0000000..afc5e71
--- /dev/null
+++ b/content/reusable/md/workstation/knife_data_bag_edit_item.md
@@ -0,0 +1,27 @@
+To edit an item named "charlie" that is contained in a data bag named
+"admins", enter:
+
+```bash
+knife data bag edit admins charlie
+```
+
+to open the \$EDITOR. Once opened, you can update the data before saving
+it to the Chef Infra Server. For example, by changing:
+
+```javascript
+{
+ "id": "charlie"
+}
+```
+
+to:
+
+```javascript
+{
+ "id": "charlie",
+ "uid": 1005,
+ "gid": "ops",
+ "shell": "/bin/zsh",
+ "comment": "Crazy Charlie"
+}
+```
diff --git a/content/reusable/md/workstation/knife_data_bag_from_file_create_encrypted_local_mode.md b/content/reusable/md/workstation/knife_data_bag_from_file_create_encrypted_local_mode.md
new file mode 100644
index 0000000..4a566a5
--- /dev/null
+++ b/content/reusable/md/workstation/knife_data_bag_from_file_create_encrypted_local_mode.md
@@ -0,0 +1,11 @@
+To generate an encrypted data bag item in a JSON file for use when Chef
+Infra Client is run in local mode (using the `--local-mode` option),
+enter:
+
+```bash
+knife data bag from file my_data_bag /path/to/data_bag_item.json -z --secret-file /path/to/encrypted_data_bag_secret
+```
+
+this will create an encrypted JSON file in:
+
+ data_bags/my_data_bag/data_bag_item.json
diff --git a/content/reusable/md/workstation/knife_node_run_list_add.md b/content/reusable/md/workstation/knife_node_run_list_add.md
new file mode 100644
index 0000000..0cf916a
--- /dev/null
+++ b/content/reusable/md/workstation/knife_node_run_list_add.md
@@ -0,0 +1,2 @@
+Use the `run_list add` argument to add run-list items (roles or recipes)
+to a node.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/knife_node_run_list_add_default_recipe.md b/content/reusable/md/workstation/knife_node_run_list_add_default_recipe.md
new file mode 100644
index 0000000..8639961
--- /dev/null
+++ b/content/reusable/md/workstation/knife_node_run_list_add_default_recipe.md
@@ -0,0 +1,5 @@
+To add the default recipe of a cookbook to a run-list, enter:
+
+```bash
+knife node run_list add NODE_NAME 'COOKBOOK'
+```
diff --git a/content/reusable/md/workstation/knife_node_run_list_add_options.md b/content/reusable/md/workstation/knife_node_run_list_add_options.md
new file mode 100644
index 0000000..5021070
--- /dev/null
+++ b/content/reusable/md/workstation/knife_node_run_list_add_options.md
@@ -0,0 +1,9 @@
+This argument has the following options:
+
+`-a ITEM`, `--after ITEM`
+
+: Add a run-list item after the specified run-list item.
+
+`-b ITEM`, `--before ITEM`
+
+: Add a run-list item before the specified run-list item.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/knife_node_run_list_add_recipe_with_cookbook.md b/content/reusable/md/workstation/knife_node_run_list_add_recipe_with_cookbook.md
new file mode 100644
index 0000000..f3b5be0
--- /dev/null
+++ b/content/reusable/md/workstation/knife_node_run_list_add_recipe_with_cookbook.md
@@ -0,0 +1,5 @@
+To add a recipe to a run-list using the cookbook format, enter:
+
+```bash
+knife node run_list add NODE_NAME 'COOKBOOK::RECIPE_NAME'
+```
diff --git a/content/reusable/md/workstation/knife_node_run_list_add_recipe_with_fqdn.md b/content/reusable/md/workstation/knife_node_run_list_add_recipe_with_fqdn.md
new file mode 100644
index 0000000..9628590
--- /dev/null
+++ b/content/reusable/md/workstation/knife_node_run_list_add_recipe_with_fqdn.md
@@ -0,0 +1,5 @@
+To add a recipe to a run-list using the fully qualified format, enter:
+
+```bash
+knife node run_list add NODE_NAME 'recipe[COOKBOOK::RECIPE_NAME]'
+```
diff --git a/content/reusable/md/workstation/knife_node_run_list_add_role.md b/content/reusable/md/workstation/knife_node_run_list_add_role.md
new file mode 100644
index 0000000..0df0188
--- /dev/null
+++ b/content/reusable/md/workstation/knife_node_run_list_add_role.md
@@ -0,0 +1,5 @@
+To add a role to a run-list, enter:
+
+```bash
+knife node run_list add NODE_NAME 'role[ROLE_NAME]'
+```
diff --git a/content/reusable/md/workstation/knife_node_run_list_add_roles_and_recipes.md b/content/reusable/md/workstation/knife_node_run_list_add_roles_and_recipes.md
new file mode 100644
index 0000000..bd0e5e8
--- /dev/null
+++ b/content/reusable/md/workstation/knife_node_run_list_add_roles_and_recipes.md
@@ -0,0 +1,5 @@
+To add roles and recipes to a run-list, enter:
+
+```bash
+knife node run_list add NODE_NAME 'recipe[COOKBOOK::RECIPE_NAME],recipe[COOKBOOK::RECIPE_NAME],role[ROLE_NAME]'
+```
diff --git a/content/reusable/md/workstation/knife_node_run_list_add_syntax.md b/content/reusable/md/workstation/knife_node_run_list_add_syntax.md
new file mode 100644
index 0000000..31ce047
--- /dev/null
+++ b/content/reusable/md/workstation/knife_node_run_list_add_syntax.md
@@ -0,0 +1,5 @@
+This argument has the following syntax:
+
+```bash
+knife node run_list add NODE_NAME RUN_LIST_ITEM (options)
+```
diff --git a/content/reusable/md/workstation/knife_node_run_list_remove.md b/content/reusable/md/workstation/knife_node_run_list_remove.md
new file mode 100644
index 0000000..948bf56
--- /dev/null
+++ b/content/reusable/md/workstation/knife_node_run_list_remove.md
@@ -0,0 +1,7 @@
+Use the `run_list remove` argument to remove run-list items (roles or
+recipes) from a node. A recipe must be in one of the following formats:
+fully qualified, cookbook, or default. Both roles and recipes must be in
+quotes, for example: `'role[ROLE_NAME]'` or
+`'recipe[COOKBOOK::RECIPE_NAME]'`. Use a comma to separate roles and
+recipes when removing more than one, like this:
+`'recipe[COOKBOOK::RECIPE_NAME],COOKBOOK::RECIPE_NAME,role[ROLE_NAME]'`.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/knife_node_run_list_remove_role.md b/content/reusable/md/workstation/knife_node_run_list_remove_role.md
new file mode 100644
index 0000000..a3ceba8
--- /dev/null
+++ b/content/reusable/md/workstation/knife_node_run_list_remove_role.md
@@ -0,0 +1,5 @@
+To remove a role from a run-list, enter:
+
+```bash
+knife node run_list remove NODE_NAME 'role[ROLE_NAME]'
+```
diff --git a/content/reusable/md/workstation/knife_node_run_list_remove_run_list.md b/content/reusable/md/workstation/knife_node_run_list_remove_run_list.md
new file mode 100644
index 0000000..5910567
--- /dev/null
+++ b/content/reusable/md/workstation/knife_node_run_list_remove_run_list.md
@@ -0,0 +1,6 @@
+To remove a recipe from a run-list using the fully qualified format,
+enter:
+
+```bash
+knife node run_list remove NODE_NAME 'recipe[COOKBOOK::RECIPE_NAME]'
+```
diff --git a/content/reusable/md/workstation/knife_node_run_list_remove_syntax.md b/content/reusable/md/workstation/knife_node_run_list_remove_syntax.md
new file mode 100644
index 0000000..b7b29a9
--- /dev/null
+++ b/content/reusable/md/workstation/knife_node_run_list_remove_syntax.md
@@ -0,0 +1,5 @@
+This argument has the following syntax:
+
+```bash
+knife node run_list remove NODE_NAME RUN_LIST_ITEM
+```
diff --git a/content/reusable/md/workstation/knife_node_run_list_set.md b/content/reusable/md/workstation/knife_node_run_list_set.md
new file mode 100644
index 0000000..42c146f
--- /dev/null
+++ b/content/reusable/md/workstation/knife_node_run_list_set.md
@@ -0,0 +1,6 @@
+Use the `run_list set` argument to set the run-list for a node. A recipe
+must be in one of the following formats: fully qualified, cookbook, or
+default. Both roles and recipes must be in quotes, for example:
+`"role[ROLE_NAME]"` or `"recipe[COOKBOOK::RECIPE_NAME]"`. Use a comma to
+separate roles and recipes when setting more than one, like this:
+`"recipe[COOKBOOK::RECIPE_NAME],COOKBOOK::RECIPE_NAME,role[ROLE_NAME]"`.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/knife_node_run_list_set_syntax.md b/content/reusable/md/workstation/knife_node_run_list_set_syntax.md
new file mode 100644
index 0000000..31ed0ed
--- /dev/null
+++ b/content/reusable/md/workstation/knife_node_run_list_set_syntax.md
@@ -0,0 +1,5 @@
+This argument has the following syntax:
+
+```bash
+knife node run_list set NODE_NAME RUN_LIST_ITEM
+```
diff --git a/content/reusable/md/workstation/knife_search_by_cookbook.md b/content/reusable/md/workstation/knife_search_by_cookbook.md
new file mode 100644
index 0000000..e781c28
--- /dev/null
+++ b/content/reusable/md/workstation/knife_search_by_cookbook.md
@@ -0,0 +1,7 @@
+To search for cookbooks on a node, use the `recipes` attribute followed
+by the `cookbook::recipe` pattern, escaping both of the `:` characters.
+For example:
+
+```bash
+knife search node 'recipes:cookbook_name\:\:recipe_name'
+```
diff --git a/content/reusable/md/workstation/knife_search_by_nested_attribute.md b/content/reusable/md/workstation/knife_search_by_nested_attribute.md
new file mode 100644
index 0000000..a160fe6
--- /dev/null
+++ b/content/reusable/md/workstation/knife_search_by_nested_attribute.md
@@ -0,0 +1,5 @@
+To find a nested attribute, use a pattern similar to the following:
+
+```bash
+knife search node -a .
+```
diff --git a/content/reusable/md/workstation/knife_search_by_node.md b/content/reusable/md/workstation/knife_search_by_node.md
new file mode 100644
index 0000000..65d9d91
--- /dev/null
+++ b/content/reusable/md/workstation/knife_search_by_node.md
@@ -0,0 +1,5 @@
+To search for all nodes running Ubuntu, enter:
+
+```bash
+knife search node 'platform:ubuntu'
+```
diff --git a/content/reusable/md/workstation/knife_search_by_node_and_environment.md b/content/reusable/md/workstation/knife_search_by_node_and_environment.md
new file mode 100644
index 0000000..54a1e39
--- /dev/null
+++ b/content/reusable/md/workstation/knife_search_by_node_and_environment.md
@@ -0,0 +1,6 @@
+To search for all nodes running CentOS in the production environment,
+enter:
+
+```bash
+knife search node 'chef_environment:production AND platform:centos'
+```
diff --git a/content/reusable/md/workstation/knife_search_by_platform_ids.md b/content/reusable/md/workstation/knife_search_by_platform_ids.md
new file mode 100644
index 0000000..8d0f84f
--- /dev/null
+++ b/content/reusable/md/workstation/knife_search_by_platform_ids.md
@@ -0,0 +1,20 @@
+To search for the IDs of all nodes running on the Amazon EC2 platform,
+enter:
+
+```bash
+knife search node 'ec2:*' -i
+```
+
+to return something like:
+
+```bash
+4 items found
+
+ip-0A7CA19F.ec2.internal
+
+ip-0A58CF8E.ec2.internal
+
+ip-0A58E134.ec2.internal
+
+ip-0A7CFFD5.ec2.internal
+```
diff --git a/content/reusable/md/workstation/knife_search_by_platform_instance_type.md b/content/reusable/md/workstation/knife_search_by_platform_instance_type.md
new file mode 100644
index 0000000..0437c78
--- /dev/null
+++ b/content/reusable/md/workstation/knife_search_by_platform_instance_type.md
@@ -0,0 +1,24 @@
+To search for the instance type (flavor) of all nodes running on the
+Amazon EC2 platform, enter:
+
+```bash
+knife search node 'ec2:*' -a ec2.instance_type
+```
+
+to return something like:
+
+```bash
+4 items found
+
+ec2.instance_type: m1.large
+id: ip-0A7CA19F.ec2.internal
+
+ec2.instance_type: m1.large
+id: ip-0A58CF8E.ec2.internal
+
+ec2.instance_type: m1.large
+id: ip-0A58E134.ec2.internal
+
+ec2.instance_type: m1.large
+id: ip-0A7CFFD5.ec2.internal
+```
diff --git a/content/reusable/md/workstation/knife_search_by_query_for_many_attributes.md b/content/reusable/md/workstation/knife_search_by_query_for_many_attributes.md
new file mode 100644
index 0000000..8264da3
--- /dev/null
+++ b/content/reusable/md/workstation/knife_search_by_query_for_many_attributes.md
@@ -0,0 +1,7 @@
+To build a search query to use more than one attribute, use an
+underscore (`_`) to separate each attribute. For example, the following
+query will search for all nodes running a specific version of Ruby:
+
+```bash
+knife search node "languages_ruby_version:2.7.0"
+```
diff --git a/content/reusable/md/workstation/knife_search_by_query_for_nested_attribute.md b/content/reusable/md/workstation/knife_search_by_query_for_nested_attribute.md
new file mode 100644
index 0000000..1e89264
--- /dev/null
+++ b/content/reusable/md/workstation/knife_search_by_query_for_nested_attribute.md
@@ -0,0 +1,5 @@
+To build a search query that can find a nested attribute:
+
+```bash
+knife search node name: -a kernel.machine
+```
diff --git a/content/reusable/md/workstation/knife_search_by_recipe.md b/content/reusable/md/workstation/knife_search_by_recipe.md
new file mode 100644
index 0000000..e2a8a30
--- /dev/null
+++ b/content/reusable/md/workstation/knife_search_by_recipe.md
@@ -0,0 +1,12 @@
+To search for recipes that are used by a node, use the `recipes`
+attribute to search for the recipe names, enter something like:
+
+```bash
+knife search node 'recipes:recipe_name'
+```
+
+or:
+
+```bash
+knife search node '*:*' -a recipes | grep 'recipe_name'
+```
diff --git a/content/reusable/md/workstation/knife_search_summary.md b/content/reusable/md/workstation/knife_search_summary.md
new file mode 100644
index 0000000..860cfcd
--- /dev/null
+++ b/content/reusable/md/workstation/knife_search_summary.md
@@ -0,0 +1,2 @@
+Use the `knife search` subcommand to run a search query for information
+that is indexed on a Chef Infra Server.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/knife_search_test_query_for_ssh.md b/content/reusable/md/workstation/knife_search_test_query_for_ssh.md
new file mode 100644
index 0000000..d29367f
--- /dev/null
+++ b/content/reusable/md/workstation/knife_search_test_query_for_ssh.md
@@ -0,0 +1,8 @@
+To test a search query that will be used in a `knife ssh` subcommand:
+
+```bash
+knife search node "role:web NOT name:web03"
+```
+
+where the query in the previous example will search all servers that
+have the `web` role, but not on the server named `web03`.
diff --git a/content/reusable/md/workstation/knife_ssl_check_bad_ssl_certificate.md b/content/reusable/md/workstation/knife_ssl_check_bad_ssl_certificate.md
new file mode 100644
index 0000000..841b5be
--- /dev/null
+++ b/content/reusable/md/workstation/knife_ssl_check_bad_ssl_certificate.md
@@ -0,0 +1,42 @@
+If the SSL certificate cannot be verified, the response to
+
+```bash
+knife ssl check
+```
+
+is similar to:
+
+```bash
+Connecting to host chef-server.example.com:443
+ERROR: The SSL certificate of chef-server.example.com could not be verified
+Certificate issuer data:
+ /C=US/ST=WA/L=S/O=Corp/OU=Ops/CN=chef-server.example.com/emailAddress=you@example.com
+
+Configuration Info:
+
+OpenSSL Configuration:
+* Version: OpenSSL 1.0.2u 20 Dec 2019
+* Certificate file: /opt/chef-workstation/embedded/ssl/cert.pem
+* Certificate directory: /opt/chef-workstation/embedded/ssl/certs
+Chef SSL Configuration:
+* ssl_ca_path: nil
+* ssl_ca_file: nil
+* trusted_certs_dir: "/Users/grantmc/Downloads/chef-repo/.chef/trusted_certs"
+
+TO FIX THIS ERROR:
+
+If the server you are connecting to uses a self-signed certificate,
+you must configure chef to trust that certificate.
+
+By default, the certificate is stored in the following location on the
+host where your Chef Infra Server runs:
+
+ /var/opt/opscode/nginx/ca/SERVER_HOSTNAME.crt
+
+Copy that file to your trusted_certs_dir (currently:
+
+ /Users/grantmc/Downloads/chef-repo/.chef/trusted_certs)
+
+using SSH/SCP or some other secure method, then re-run this command to
+confirm that the certificate is now trusted.
+```
diff --git a/content/reusable/md/workstation/knife_ssl_check_verify_server_config.md b/content/reusable/md/workstation/knife_ssl_check_verify_server_config.md
new file mode 100644
index 0000000..9d7513b
--- /dev/null
+++ b/content/reusable/md/workstation/knife_ssl_check_verify_server_config.md
@@ -0,0 +1,12 @@
+If the SSL certificate can be verified, the response to
+
+```bash
+knife ssl check
+```
+
+is similar to:
+
+```bash
+Connecting to host chef-server.example.com:443
+Successfully verified certificates from 'chef-server.example.com'
+```
diff --git a/content/reusable/md/workstation/knife_ssl_fetch_verify_certificate.md b/content/reusable/md/workstation/knife_ssl_fetch_verify_certificate.md
new file mode 100644
index 0000000..faebe7e
--- /dev/null
+++ b/content/reusable/md/workstation/knife_ssl_fetch_verify_certificate.md
@@ -0,0 +1,30 @@
+The SSL certificate that is downloaded to the `/.chef/trusted_certs`
+directory should be verified to ensure that it is, in fact, the same
+certificate as the one located on the Chef Infra Server. This can be
+done by comparing the SHA-256 checksums.
+
+1. View the checksum on the Chef Infra Server:
+
+ ```bash
+ ssh ubuntu@chef-server.example.com sudo sha256sum /var/opt/opscode/nginx/ca/chef-server.example.com.crt
+ ```
+
+ The response is similar to:
+
+ ```bash
+ /var/opt/opscode/nginx/ca/chef-server.example.com.crt
+ ```
+
+2. View the checksum on the workstation:
+
+ ```bash
+ gsha256sum .chef/trusted_certs/chef-server.example.com.crt
+ ```
+
+ The response is similar to:
+
+ ```bash
+ .chef/trusted_certs/chef-server.example.com.crt
+ ```
+
+3. Verify that the checksum values are identical.
diff --git a/content/reusable/md/workstation/knife_status_include_run_lists.md b/content/reusable/md/workstation/knife_status_include_run_lists.md
new file mode 100644
index 0000000..43dd116
--- /dev/null
+++ b/content/reusable/md/workstation/knife_status_include_run_lists.md
@@ -0,0 +1,16 @@
+To include run-lists in the status, enter:
+
+```bash
+knife status --run-list
+```
+
+to return something like:
+
+```bash
+20 hours ago, dev-vm.chisamore.com, ubuntu 10.04, dev-vm.chisamore.com, 10.66.44.126, role[lb].
+3 hours ago, i-225f954f, ubuntu 10.04, ec2-67-202-63-102.compute-1.amazonaws.com, 67.202.63.102, role[web].
+3 hours ago, i-a45298c9, ubuntu 10.04, ec2-174-129-127-206.compute-1.amazonaws.com, 174.129.127.206, role[web].
+3 hours ago, i-5272a43f, ubuntu 10.04, ec2-184-73-9-250.compute-1.amazonaws.com, 184.73.9.250, role[web].
+3 hours ago, i-226ca64f, ubuntu 10.04, ec2-75-101-240-230.compute-1.amazonaws.com, 75.101.240.230, role[web].
+3 hours ago, i-f65c969b, ubuntu 10.04, ec2-184-73-60-141.compute-1.amazonaws.com, 184.73.60.141, role[web].
+```
diff --git a/content/reusable/md/workstation/knife_status_returned_by_query.md b/content/reusable/md/workstation/knife_status_returned_by_query.md
new file mode 100644
index 0000000..0458cff
--- /dev/null
+++ b/content/reusable/md/workstation/knife_status_returned_by_query.md
@@ -0,0 +1,16 @@
+To show the status of a subset of nodes that are returned by a specific
+query, enter:
+
+```bash
+knife status "role:web" --run-list
+```
+
+to return something like:
+
+```bash
+3 hours ago, i-225f954f, ubuntu 10.04, ec2-67-202-63-102.compute-1.amazonaws.com, 67.202.63.102, role[web].
+3 hours ago, i-a45298c9, ubuntu 10.04, ec2-174-129-127-206.compute-1.amazonaws.com, 174.129.127.206, role[web].
+3 hours ago, i-5272a43f, ubuntu 10.04, ec2-184-73-9-250.compute-1.amazonaws.com, 184.73.9.250, role[web].
+3 hours ago, i-226ca64f, ubuntu 10.04, ec2-75-101-240-230.compute-1.amazonaws.com, 75.101.240.230, role[web].
+3 hours ago, i-f65c969b, ubuntu 10.04, ec2-184-73-60-141.compute-1.amazonaws.com, 184.73.60.141, role[web].
+```
diff --git a/content/reusable/md/workstation/knife_windows_summary.md b/content/reusable/md/workstation/knife_windows_summary.md
new file mode 100644
index 0000000..d925331
--- /dev/null
+++ b/content/reusable/md/workstation/knife_windows_summary.md
@@ -0,0 +1,5 @@
+The `knife windows` subcommand is used to interact with Windows systems
+managed by Chef Infra. Nodes are configured using WinRM, which allows
+external applications to call native objects like batch scripts, Windows
+PowerShell scripts, or scripting library variables. The `knife windows`
+subcommand supports NTLM and Kerberos methods of authentication.
\ No newline at end of file
diff --git a/content/reusable/md/workstation/knife_windows_winrm_ports.md b/content/reusable/md/workstation/knife_windows_winrm_ports.md
new file mode 100644
index 0000000..4153449
--- /dev/null
+++ b/content/reusable/md/workstation/knife_windows_winrm_ports.md
@@ -0,0 +1,2 @@
+WinRM requires that a target node be accessible using the ports configured
+to support access using HTTP or HTTPS.
diff --git a/content/roles.md b/content/roles.md
new file mode 100644
index 0000000..0a71d8e
--- /dev/null
+++ b/content/roles.md
@@ -0,0 +1,314 @@
++++
+title = "About Roles"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/roles.html"]
+product = ["client", "server"]
+
+[menu]
+ [menu.infra]
+ title = "Roles"
+ identifier = "chef_infra/policyfiles/roles.md Roles"
+ parent = "chef_infra/policyfiles"
+ weight = 70
++++
+
+{{< readfile file="content/reusable/md/role.md" >}}
+
+## Role Attributes
+
+{{< note >}}
+
+{{< readfile file="content/reusable/md/notes_see_attributes_overview.md" >}}
+
+{{< /note >}}
+
+{{< readfile file="content/reusable/md/role_attribute.md" >}}
+
+### Attribute Types
+
+There are two types of attributes that can be used with roles:
+
+
+
+## Role Formats
+
+Role data is stored in two formats: as a Ruby file that contains
+domain-specific language or as JSON data.
+
+### Chef Language
+
+{{< readfile file="content/reusable/md/ruby_summary.md" >}}
+
+Domain-specific Ruby attributes:
+
+
+
+
+
+
+
+
+
Setting
+
Description
+
+
+
+
+
default_attributes
+
Optional. A set of attributes to be applied to all nodes, assuming the node doesn't already have a value for the attribute. This is useful for setting global defaults that can then be overridden for specific nodes. If more than one role attempts to set a default value for the same attribute, the last role applied is the role to set the attribute value. When nested attributes are present, they're preserved. For example, to specify that a node that has the attribute apache2 should listen on ports 80 and 443 (unless ports are already specified):
A description of the functionality that's covered. For example:
+
description 'The base role for systems that serve HTTP traffic'
+
+
+
env_run_lists
+
Optional. A list of environments, each specifying a recipe or a role to be applied to that environment. This setting must specify the _default environment. If the _default environment is set to [] or nil, then the run-list is empty. For example:
Using env_run_lists with roles is discouraged as it can be difficult to maintain over time. Instead, consider using multiple roles to define the required behavior.
+{{< /warning >}}
+
+
+
name
+
A unique name within the organization. Each name must be made up of letters (uppercase and lowercase), numbers, underscores, and hyphens: [A-Z][a-z][0-9] and [_-]. Spaces aren't allowed. For example:
+
name 'dev01-24'
+
+
+
override_attributes
+
Optional. A set of attributes to be applied to all nodes, even if the node already has a value for an attribute. This is useful for ensuring that certain attributes always have specific values. If more than one role attempts to set an override value for the same attribute, the last role applied wins. When nested attributes are present, they're preserved. For example:
The parameters in a Ruby file are Ruby method calls, so parentheses can be used to provide clarity when specifying numerous or deeply-nested attributes. For example:
would apply the apache2 recipe first, then the apache2::mod_ssl recipe, and then the role[monitor] recipe.
+
+
+
+
+Each role must be saved as a ruby file in the `roles/` subdirectory of
+the chef-repo. (If the repository doesn't have this subdirectory, then
+create it using knife.) Each Ruby file should have the `.rb` suffix. A
+complete role has the following syntax:
+
+```ruby
+name "role_name"
+description "role_description"
+run_list "recipe[name]", "recipe[name::attribute]", "recipe[name::attribute]"
+env_run_lists "name" => ["recipe[name]"], "environment_name" => ["recipe[name::attribute]"]
+default_attributes "node" => { "attribute" => [ "value", "value", "etc." ] }
+override_attributes "node" => { "attribute" => [ "value", "value", "etc." ] }
+```
+
+where both default and override attributes are optional and at least one
+run-list (with at least one run-list item) is specified. For example, a
+role named `webserver` that has a run-list that defines actions for
+three different roles, and for certain roles takes extra steps (such as
+the `apache2` role listening on ports 80 and 443):
+
+```ruby
+name "webserver"
+description "The base role for systems that serve HTTP traffic"
+run_list "recipe[apache2]", "recipe[apache2::mod_ssl]", "role[monitor]"
+env_run_lists "prod" => ["recipe[apache2]"], "staging" => ["recipe[apache2::staging]"], "_default" => []
+default_attributes "apache2" => { "listen_ports" => [ "80", "443" ] }
+override_attributes "apache2" => { "max_children" => "50" }
+```
+
+### JSON
+
+The JSON format for roles maps directly to the domain-specific Ruby
+format: same settings, attributes, and values, and a similar structure
+and organization. For example:
+
+```json
+{
+ "name": "webserver",
+ "chef_type": "role",
+ "json_class": "Chef::Role",
+ "default_attributes": {
+ "apache2": {
+ "listen_ports": [
+ "80",
+ "443"
+ ]
+ }
+ },
+ "description": "The base role for systems that serve HTTP traffic",
+ "run_list": [
+ "recipe[apache2]",
+ "recipe[apache2::mod_ssl]",
+ "role[monitor]"
+ ],
+ "env_run_lists" : {
+ "production" : [],
+ "preprod" : [],
+ "dev": [
+ "role[base]",
+ "recipe[apache]",
+ "recipe[apache::copy_dev_configs]",
+ ],
+ "test": [
+ "role[base]",
+ "recipe[apache]"
+ ]
+ },
+ "override_attributes": {
+ "apache2": {
+ "max_children": "50"
+ }
+ }
+}
+```
+
+The JSON format has two additional settings:
+
+
+
+
+
+
+
+
+
Setting
+
Description
+
+
+
+
+
chef_type
+
Always set this to role. Use this setting for any custom process that consumes role objects outside of Ruby.
+
+
+
json_class
+
Always set this to Chef::Role. The Chef Infra Client uses this setting to auto inflate a role object. If objects are being rebuilt outside of Ruby, ignore it.
+
+
+
+
+## Manage Roles
+
+There are several ways to manage roles:
+
+- knife can be used to create, edit, view, list, tag, and delete
+ roles.
+- The Chef Infra Client can be used to manage role data using the
+ command line and JSON files (that contain a hash, the elements of
+ which are added as role attributes). In addition, the `run_list`
+ setting allows roles and/or recipes to be added to the role.
+- The open source Chef Infra Server can be used to manage role data
+ using the command line and JSON files (that contain a hash, the
+ elements of which are added as role attributes). In addition, the
+ `run_list` setting allows roles and/or recipes to be added to the
+ role.
+- The Chef Infra Server API can be used to create and manage roles
+ directly, although using knife directly is the most common way to manage roles.
+- The command line can also be used with JSON files and third-party
+ services, such as Amazon EC2, where the JSON files can contain
+ metadata for each instance stored in a file on-disk and then read by
+ chef-solo or Chef Infra Client as required.
+
+By creating and editing files using the Chef Language (Ruby) or JSON, you can dynamically generate role data. Roles created and edited
+using files are compatible with all versions of Chef, including
+chef-solo. Roles created and edited using files can be kept in version
+source control, which also keeps a history of what changed when. When
+roles are created and edited using files, they shouldn't be managed
+using knife, as changes will be
+overwritten.
+
+A run-list that's associated with a role can be edited using the Chef
+management console add-on. The canonical source of a role's data is
+stored on Chef Infra Server, which means that keeping role data in
+version source control can be challenging.
+
+If roles are created and managed using knife and then arbitrarily updated
+uploaded through JSON data, that action will overwrite the previous work with knife.
+It's strongly recommended to keep to one process and not switch back and forth.
+
+### Set Run-lists for Environments
+
+Associating a run-list with a role and a specific environment lets you use the run-list on different nodes that share the same environment. More than one environment can be specified in a role, but each specific environment may be associated with only one run-list. If a run-list isn't specified, the default run-list will be used. For example:
+
+```json
+{
+ "name": "webserver",
+ "default_attributes": {
+ },
+ "json_class": "Chef::Role",
+ "env_run_lists": {
+ "production": [],
+ "preprod": [],
+ "test": [ "role[base]", "recipe[apache]", "recipe[apache::copy_test_configs]" ],
+ "dev": [ "role[base]", "recipe[apache]", "recipe[apache::copy_dev_configs]" ]
+ },
+ "run_list": [ "role[base]", "recipe[apache]" ],
+ "description": "The webserver role",
+ "chef_type": "role",
+ "override_attributes": {
+ }
+}
+```
+
+where:
+
+- `webserver` is the name of the role
+- `env_run_lists` is a hash of environment run-lists for
+ `production`, `preprod`, `test`, and `dev`
+- `production` and `preprod` use the default run-list because they do
+ not have a shared environment run-list
+- `run_list` defines the default run-list
+
+### Delete from Run-list
+
+When an environment is deleted, it will remain within a run-list for a
+role until it's removed from that run-list. If a new environment is
+created that has an identical name to an environment that was deleted, a
+run-list that contains an old environment name will use the new one.
diff --git a/content/ruby.md b/content/ruby.md
new file mode 100644
index 0000000..10ab525
--- /dev/null
+++ b/content/ruby.md
@@ -0,0 +1,696 @@
++++
+title = "Ruby Guide"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+aliases = ["/ruby.html", "/just_enough_ruby_for_chef.html"]
+
+[menu]
+ [menu.infra]
+ title = "Ruby Guide"
+ identifier = "chef_infra/infra_language/ruby.md Ruby Guide"
+ parent = "chef_infra/infra_language"
++++
+
+{{< readfile file="content/reusable/md/ruby_summary.md" >}}
+
+Chef Infra Client 15 ships with Ruby 2.6 and Chef Infra Client 16 ships with Ruby 2.7.
+
+## Ruby Basics
+
+This section covers the basics of Ruby.
+
+### Verify Syntax
+
+Many people who are new to Ruby often find that it doesn't take
+long to get up to speed with the basics. For example, it's useful to
+know how to check the syntax of a Ruby file, such as the contents of a
+cookbook named `my_cookbook.rb`:
+
+```bash
+ruby -c my_cookbook_file.rb
+```
+
+to return:
+
+```bash
+Syntax OK
+```
+
+### Comments
+
+Use a comment to explain code that exists in a cookbook or recipe.
+Anything after a `#` is a comment.
+
+```ruby
+# This is a comment.
+```
+
+### Local Variables
+
+Assign a local variable:
+
+```ruby
+x = 1
+```
+
+### Math
+
+Do some basic arithmetic:
+
+```ruby
+1 + 2 # => 3
+2 * 7 # => 14
+5 / 2 # => 2 (because both arguments are whole numbers)
+5 / 2.0 # => 2.5 (because one of the numbers had a decimal place)
+1 + (2 * 3) # => 7 (you can use parentheses to group expressions)
+```
+
+### Strings
+
+Work with strings:
+
+```ruby
+'single quoted' # => "single quoted"
+"double quoted" # => "double quoted"
+'It\'s alive!' # => "It's alive!" (the \ is an escape character)
+'1 + 2 = 5' # => "1 + 2 = 5" (numbers surrounded by quotes behave like strings)
+```
+
+Convert a string to uppercase or lowercase. For example, a hostname
+named "Foo":
+
+```ruby
+node['hostname'].downcase # => "foo"
+node['hostname'].upcase # => "FOO"
+```
+
+#### Ruby in Strings
+
+Embed Ruby in a string:
+
+```ruby
+x = 'Bob'
+"Hi, #{x}" # => "Hi, Bob"
+'Hello, #{x}' # => "Hello, \#{x}" Notice that single quotes don't work with #{}
+```
+
+#### Escape Character
+
+Use the backslash character (`\`) as an escape character when quotes
+must appear within strings. However, you don't need to escape single
+quotes inside double quotes. For example:
+
+```ruby
+'It\'s alive!' # => "It's alive!"
+"Won\'t you read Grant\'s book?" # => "won't you read Grant's book?"
+```
+
+#### Interpolation
+
+When strings have quotes within quotes, use double quotes (`" "`) on the
+outer quotes, and then single quotes (`' '`) for the inner quotes. For
+example:
+
+```ruby
+Chef::Log.info("Loaded from aws[#{aws['id']}]")
+```
+
+```ruby
+"node['mysql']['secretpath']"
+```
+
+```ruby
+"#{ENV['HOME']}/chef.txt"
+```
+
+```ruby
+antarctica_hint = hint?('antarctica')
+if antarctica_hint['snow']
+ "There are #{antarctica_hint['penguins']} penguins here."
+else
+ 'There is no snow here, and penguins like snow.'
+end
+```
+
+### Truths
+
+Work with basic truths:
+
+```ruby
+true # => true
+false # => false
+nil # => nil
+0 # => true ( the only false values in Ruby are false
+ # and nil; in other words: if it exists in Ruby,
+ # even if it exists as zero, then it's true.)
+1 == 1 # => true ( == tests for equality )
+1 == true # => false ( == tests for equality )
+```
+
+#### Untruths
+
+Work with basic untruths (`!` means not!):
+
+```ruby
+!true # => false
+!false # => true
+!nil # => true
+1 != 2 # => true (1 isn't equal to 2)
+1 != 1 # => false (1 isn't equal to itself)
+```
+
+#### Convert Truths
+
+Convert something to either true or false (`!!` means not not!!):
+
+```ruby
+!!true # => true
+!!false # => false
+!!nil # => false (when pressed, nil is false)
+!!0 # => true (zero isn't false).
+```
+
+### Arrays
+
+Create lists using arrays:
+
+```ruby
+x = ['a', 'b', 'c'] # => ["a", "b", "c"]
+x[0] # => "a" (zero is the first index)
+x.first # => "a" (see?)
+x.last # => "c"
+x + ['d'] # => ["a", "b", "c", "d"]
+x # => ["a", "b", "c"] ( x is unchanged)
+x = x + ['d'] # => ["a", "b", "c", "d"]
+x # => ["a", "b", "c", "d"]
+```
+
+#### Whitespace Arrays
+
+The `%w` syntax is a Ruby shortcut for creating an array without
+requiring quotes and commas around the elements.
+
+For example:
+
+```ruby
+if %w(debian ubuntu).include?(node['platform'])
+ # do debian/ubuntu things with the Ruby array %w() shortcut
+end
+```
+
+{{< readfile file="content/reusable/md/ruby_style_patterns_string_quoting_vs_whitespace_array.md" >}}
+
+##### Example
+
+WiX includes several tools -- such as `candle` (preprocesses and
+compiles source files into object files), `light` (links and binds
+object files to an installer database), and `heat` (harvests files from
+various input formats). The following example uses a whitespace array
+and the Chef InSpec `file` audit resource to verify if these three tools
+are present:
+
+```ruby
+%w(
+ candle.exe
+ heat.exe
+ light.exe
+).each do |utility|
+ describe file("C:/wix/#{utility}") do
+ it { should be_file }
+ end
+end
+```
+
+### Hash
+
+A Hash is a list with keys and values. Sometimes hashes don't have a set
+order:
+
+```ruby
+h = {
+ 'first_name' => 'Bob',
+ 'last_name' => 'Jones',
+}
+```
+
+And sometimes they do. For example, first name then last name:
+
+```ruby
+h.keys # => ["first_name", "last_name"]
+h['first_name'] # => "Bob"
+h['last_name'] # => "Jones"
+h['age'] = 23
+h.keys # => ["first_name", "age", "last_name"]
+h.values # => ["Jones", "Bob", 23]
+```
+
+### Regular Expressions
+
+Use Perl-style regular expressions:
+
+```ruby
+'I believe' =~ /I/ # => 0 (matches at the first character)
+'I believe' =~ /lie/ # => 4 (matches at the 5th character)
+'I am human' =~ /bacon/ # => nil (no match - bacon comes from pigs)
+'I am human' !~ /bacon/ # => true (correct, no bacon here)
+/give me a ([0-9]+)/ =~ 'give me a 7' # => 0 (matched)
+```
+
+### Statements
+
+Use conditions! For example, an `if` statement
+
+```ruby
+if false
+ # this won't happen
+elsif nil
+ # this won't either
+else
+ # code here will run though
+end
+```
+
+or a `case` statement:
+
+```ruby
+x = 'dog'
+case x
+when 'fish'
+ # this won't happen
+when 'dog', 'cat', 'monkey'
+ # this will run
+else
+ # the else is an optional catch-all
+end
+```
+
+#### if
+
+An `if` statement can be used to specify part of a recipe to be used
+when certain conditions are met. `else` and `elsif` statements can be
+used to handle situations where either the initial condition isn't met
+or when there are other possible conditions that can be met. Since this
+behavior is 100% Ruby, do this in a recipe the same way here as anywhere
+else.
+
+For example, using an `if` statement with the `platform` node attribute:
+
+```ruby
+if node['platform'] == 'ubuntu'
+ # do ubuntu things
+end
+```
+
+##### if modifier
+
+`if` can be used as a modifier that executes the left side of an expression
+if the right side of the expression is true. The `if` modifier expression must
+be a single line, and `else` and `elsif` statements aren't supported.
+
+In the following example, the `do_ubuntu_thing` function will execute if the platform on a node is Ubuntu.
+
+```ruby
+do_ubuntu_thing if platform?('ubuntu')
+```
+
+#### case
+
+A `case` statement can be used to handle a situation where there are a
+lot of conditions. Use the `when` statement for each condition, as many
+as are required.
+
+For example, using a `case` statement with the `platform` node
+attribute:
+
+```ruby
+case node['platform']
+when 'debian', 'ubuntu'
+ # do debian/ubuntu things
+when 'redhat', 'centos', 'fedora'
+ # do redhat/centos/fedora things
+end
+```
+
+For example, using a `case` statement with the `platform_family` node
+attribute:
+
+```ruby
+case node['platform_family']
+when 'debian'
+ # do things on debian-ish platforms (debian, ubuntu, linuxmint)
+when 'rhel'
+ # do things on RHEL platforms (redhat, centos, scientific, etc)
+end
+```
+
+### Call a Method
+
+Call a method on something with `.method_name()`:
+
+```ruby
+x = 'My String'
+x.split(' ') # => ["My", "String"]
+x.split(' ').join(', ') # => "My, String"
+```
+
+### Define a Method
+
+Define a method (or a function, if you like):
+
+```ruby
+def do_something_useless(first_argument, second_argument)
+ puts "You gave me #{first_argument} and #{second_argument}"
+end
+
+do_something_useless('apple', 'banana')
+# => "You gave me apple and banana"
+do_something_useless 1, 2
+# => "You gave me 1 and 2"
+# see how the parentheses are optional if there's no confusion about what to do
+```
+
+### Ruby Class
+
+Use the Ruby `File` class in a recipe. Because Chef has the **file**
+resource, use `File` to use the Ruby `File` class. For example:
+
+```ruby
+execute 'apt-get-update' do
+ command 'apt-get update'
+ ignore_failure true
+ not_if { ::File.exist?('/var/lib/apt/periodic/update-success-stamp') }
+end
+```
+
+### Include a Class
+
+Use `:include` to include another Ruby class. For example:
+
+```ruby
+::Chef::DSL::Recipe.include MyCookbook::Helpers
+```
+
+In non-Chef Ruby, the syntax is `include` (without the `:` prefix), but
+without the `:` prefix Chef Infra Client will try to find a provider
+named `include`. Using the `:` prefix tells Chef Infra Client to look
+for the specified class that follows.
+
+### Include a Parameter
+
+The `include?` method can be used to ensure that a specific parameter is
+included before an action is taken. For example, using the `include?`
+method to find a specific parameter:
+
+```ruby
+if %w(debian ubuntu).include?(node['platform'])
+ # do debian/ubuntu things
+end
+```
+
+or:
+
+```ruby
+if %w(rhel).include?(node['platform_family'])
+ # do RHEL things
+end
+```
+
+## Patterns to Follow
+
+This section covers best practices for cookbook and recipe authoring.
+
+### git Etiquette
+
+Although not strictly a Chef style thing, please always ensure your
+`user.name` and `user.email` are set properly in your `.gitconfig` file.
+
+- `user.name` should be your given name (for example, "Julian Dunn")
+- `user.email` should be an actual, working e-mail address
+
+This will prevent commit log entries similar to
+`"guestuser "`, which are unhelpful.
+
+### Use of Hyphens
+
+{{< readfile file="content/reusable/md/ruby_style_patterns_hyphens.md" >}}
+
+### Cookbook Naming
+
+Use a short organizational prefix for application cookbooks that are
+part of your organization. For example, if your organization is named
+SecondMarket, use `sm` as a prefix: `sm_postgresql` or `sm_httpd`.
+
+### Cookbook Versioning
+
+- Use semantic versioning when numbering cookbooks.
+- Only upload stable cookbooks from master.
+- Only upload unstable cookbooks from the dev branch. Merge to master
+ and bump the version when stable.
+- Always update CHANGELOG.md with any changes, with the JIRA ticket
+ and a brief description.
+
+### Naming
+
+Name things uniformly for their system and component. For example:
+
+- attributes: `node['foo']['bar']`
+- recipe: `foo::bar`
+- role: `foo-bar`
+- directories: `foo/bar` (if specific to component), `foo` (if not).
+ For example: `/var/log/foo/bar`.
+
+Name attributes after the recipe in which they're primarily used. for example
+`node['postgresql']['server']`.
+
+### Parameter Order
+
+Follow this order for information in each resource declaration:
+
+- Source
+- Cookbook
+- Resource ownership
+- Permissions
+- Notifications
+- Action
+
+For example:
+
+```ruby
+template '/tmp/foobar.txt' do
+ source 'foobar.txt.erb'
+ owner 'someuser'
+ group 'somegroup'
+ mode '0644'
+ variables(
+ foo: 'bar'
+ )
+ notifies :reload, 'service[whatever]'
+ action :create
+end
+```
+
+### File Modes
+
+Always specify the file mode with a quoted 3-5 character string that
+defines the octal mode:
+
+```ruby
+mode '755'
+```
+
+```ruby
+mode '0755'
+```
+
+Wrong:
+
+```ruby
+mode 755
+```
+
+### Specify Resource Action?
+
+A resource declaration doesn't require the action to be specified
+because Chef Infra Client will apply the default action for a resource
+automatically if it's not specified within the resource block. For
+example:
+
+```ruby
+package 'monit'
+```
+
+will install the `monit` package because the `:install` action is the
+default action for the **package** resource.
+
+However, if readability of code is desired, such as ensuring that a
+reader understands what the default action is for a custom resource or
+stating the action for a resource whose default may not be immediately
+obvious to the reader, specifying the default action is recommended:
+
+```ruby
+ohai 'apache_modules' do
+ action :reload
+end
+```
+
+### String Quoting
+
+Use single-quoted strings in all situations where the string doesn't
+need interpolation.
+
+#### Whitespace Arrays
+
+{{< readfile file="content/reusable/md/ruby_style_patterns_string_quoting_vs_whitespace_array.md" >}}
+
+### Recipes
+
+A recipe should be clean and well-commented. For example:
+
+```ruby
+###########
+# variables
+###########
+
+connection_info = {
+ host: '127.0.0.1',
+ port: '3306',
+ username: 'root',
+ password: 'm3y3sqlr00t',
+}
+
+#################
+# Mysql resources
+#################
+
+mysql_service 'default' do
+ port '3306'
+ initial_root_password 'm3y3sqlr00t'
+ action [:create, :start]
+end
+
+mysql_database 'wordpress_demo' do
+ connection connection_info
+ action :create
+end
+
+mysql_database_user 'wordpress_user' do
+ connection connection_info
+ database_name 'wordpress_demo'
+ password 'w0rdpr3ssdem0'
+ privileges [:create, :delete, :select, :update, :insert]
+ action :grant
+end
+
+##################
+# Apache resources
+##################
+
+httpd_service 'default' do
+ listen_ports %w(80)
+ mpm 'prefork'
+ action [:create, :start]
+end
+
+httpd_module 'php' do
+ notifies :restart, 'httpd_service[default]'
+ action :create
+end
+
+###############
+# Php resources
+###############
+
+package 'php-gd' do
+ action :install
+end
+
+package 'php-mysql' do
+ action :install
+end
+
+directory '/etc/php.d' do
+ action :create
+end
+
+template '/etc/php.d/mysql.ini' do
+ source 'mysql.ini.erb'
+ action :create
+end
+
+httpd_config 'php' do
+ source 'php.conf.erb'
+ notifies :restart, 'httpd_service[default]'
+ action :create
+end
+
+#####################
+# wordpress resources
+#####################
+
+directory '/srv/wordpress_demo' do
+ user 'apache'
+ recursive true
+ action :create
+end
+
+tar_extract 'https://wordpress.org/wordpress-4.1.tar.gz' do
+ target_dir '/srv/wordpress_demo'
+ tar_flags ['--strip-components 1']
+ user 'apache'
+ creates '/srv/wordpress_demo/index.php'
+ action :extract
+end
+
+directory '/srv/wordpress_demo/wp-content' do
+ user 'apache'
+ action :create
+end
+
+httpd_config 'wordpress' do
+ source 'wordpress.conf.erb'
+ variables(
+ servername: 'wordpress',
+ server_aliases: %w(computers.biz www.computers.biz),
+ document_root: '/srv/wordpress_demo'
+ )
+ notifies :restart, 'httpd_service[default]'
+ action :create
+end
+
+template '/srv/wordpress_demo/wp-config.php' do
+ source 'wp-config.php.erb'
+ owner 'apache'
+ variables(
+ db_name: 'wordpress_demo',
+ db_user: 'wordpress_user',
+ db_password: 'w0rdpr3ssdem0',
+ db_host: '127.0.0.1',
+ db_prefix: 'wp_',
+ db_charset: 'utf8',
+ auth_key: 'You should probably use randomly',
+ secure_auth_key: 'generated strings. These can be hard',
+ logged_in_key: 'coded, pulled from encrypted databags,',
+ nonce_key: 'or a ruby function that accessed an',
+ auth_salt: 'arbitrary data source, such as a password',
+ secure_auth_salt: 'vault. Node attributes could work',
+ logged_in_salt: 'as well, but you take special care',
+ nonce_salt: 'so they're not saved to your chef-server.',
+ allow_multisite: 'false'
+ )
+ action :create
+end
+```
+
+## Cookstyle Linting
+
+Chef Workstation includes Cookstyle for linting the Ruby-specific and
+Chef-specific portions of your cookbook code. All cookbooks should pass
+Cookstyle rules before being uploaded.
+
+```bash
+cookstyle your-cookbook
+```
+
+should return `no offenses detected`
diff --git a/content/run_lists.md b/content/run_lists.md
new file mode 100644
index 0000000..427b123
--- /dev/null
+++ b/content/run_lists.md
@@ -0,0 +1,158 @@
++++
+title = "About Run-lists"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/run_lists.html"]
+product = ["client", "server"]
+
+[menu]
+ [menu.infra]
+ title = "Run-lists"
+ identifier = "chef_infra/policyfiles/run_lists.md Run-lists"
+ parent = "chef_infra/policyfiles"
+ weight = 50
++++
+
+{{< readfile file="content/reusable/md/node_run_list.md" >}}
+
+## Run-list Format
+
+{{< readfile file="content/reusable/md/node_run_list_format.md" >}}
+
+### Empty Run-lists
+
+{{< readfile file="content/reusable/md/node_run_list_empty.md" >}}
+
+## Knife Commands
+
+The following knife commands may be used to manage run-lists on the Chef
+Infra Server.
+
+### Quotes, Windows
+
+{{< readfile file="content/reusable/md/workstation/knife_common_windows_quotes.md" >}}
+
+#### Import-Module chef
+
+{{< readfile file="content/reusable/md/workstation/knife_common_windows_quotes_module.md" >}}
+
+### run_list add
+
+{{< readfile file="content/reusable/md/workstation/knife_node_run_list_add.md" >}}
+
+{{< readfile file="content/reusable/md/node_run_list_format.md" >}}
+
+#### Syntax
+
+{{< readfile file="content/reusable/md/workstation/knife_node_run_list_add_syntax.md" >}}
+
+#### Options
+
+{{< readfile file="content/reusable/md/workstation/knife_node_run_list_add_options.md" >}}
+
+{{< note >}}
+
+{{< readfile file="content/reusable/md/workstation/knife_common_see_all_config_options.md" >}}
+
+{{< /note >}}
+
+#### Examples
+
+The following examples show how to use this knife subcommand:
+
+##### Add a role
+
+{{< readfile file="content/reusable/md/workstation/knife_node_run_list_add_role.md" >}}
+
+##### Add roles and recipes
+
+{{< readfile file="content/reusable/md/workstation/knife_node_run_list_add_roles_and_recipes.md" >}}
+
+##### Add a recipe with a FQDN
+
+{{< readfile file="content/reusable/md/workstation/knife_node_run_list_add_recipe_with_fqdn.md" >}}
+
+##### Add a recipe with a cookbook
+
+{{< readfile file="content/reusable/md/workstation/knife_node_run_list_add_recipe_with_cookbook.md" >}}
+
+##### Add the default recipe
+
+{{< readfile file="content/reusable/md/workstation/knife_node_run_list_add_default_recipe.md" >}}
+
+### run_list remove
+
+{{< readfile file="content/reusable/md/workstation/knife_node_run_list_remove.md" >}}
+
+#### Syntax
+
+{{< readfile file="content/reusable/md/workstation/knife_node_run_list_remove_syntax.md" >}}
+
+#### Options
+
+This command doesn't have any specific options.
+
+{{< note >}}
+
+{{< readfile file="content/reusable/md/workstation/knife_common_see_all_config_options.md" >}}
+
+{{< /note >}}
+
+#### Examples
+
+The following examples show how to use this knife subcommand:
+
+##### Remove a role
+
+{{< readfile file="content/reusable/md/workstation/knife_node_run_list_remove_role.md" >}}
+
+##### Remove a run-list
+
+{{< readfile file="content/reusable/md/workstation/knife_node_run_list_remove_run_list.md" >}}
+
+### run_list set
+
+{{< readfile file="content/reusable/md/workstation/knife_node_run_list_set.md" >}}
+
+#### Syntax
+
+{{< readfile file="content/reusable/md/workstation/knife_node_run_list_set_syntax.md" >}}
+
+#### Options
+
+This command doesn't have any specific options.
+
+#### Examples
+
+None.
+
+### status
+
+The following examples show how to use the `knife status` subcommand to
+verify the status of run-lists.
+
+#### View status, include run-lists
+
+{{< readfile file="content/reusable/md/workstation/knife_status_include_run_lists.md" >}}
+
+#### View status using a query
+
+{{< readfile file="content/reusable/md/workstation/knife_status_returned_by_query.md" >}}
+
+## Run-lists, Applied
+
+A run-list will tell Chef Infra Client what to do when bootstrapping
+that node for the first time, and then how to configure that node on
+every subsequent Chef Infra Client run.
+
+### Bootstrap Operations
+
+{{< readfile file="content/reusable/md/install_chef_client.md" >}}
+
+{{< readfile file="content/reusable/md/chef_client_bootstrap_node.md" >}}
+
+{{< readfile file="content/reusable/md/chef_client_bootstrap_stages.md" >}}
+
+### The Chef Infra Client Run
+
+{{< readfile file="content/reusable/md/chef_client_run.md" >}}
diff --git a/content/templates.md b/content/templates.md
new file mode 100644
index 0000000..41efb2e
--- /dev/null
+++ b/content/templates.md
@@ -0,0 +1,94 @@
++++
+title = "About Templates"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+aliases = ["/templates.html", "essentials_cookbook_templates.html"]
+
+[menu]
+ [menu.infra]
+ title = "Templates"
+ identifier = "chef_infra/cookbook_reference/templates.md Templates"
+ parent = "chef_infra/cookbook_reference"
+ weight = 100
++++
+
+{{< readfile file="content/reusable/md/template.md" >}}
+
+The `templates` directory doesn't exist by default in a cookbook.
+Generate the `templates` directory and a template file from the `chef-repo/cookbooks` directory with the command:
+
+```bash
+chef generate template PATH_TO_COOKBOOK TEMPLATE_NAME
+```
+
+For example, this command generates a `httpd` template in the `custom_web` cookbook:
+
+```bash
+chef generate template cookbooks/custom_web httpd
+```
+
+The `custom_web` cookbook directory with a template has the structure:
+
+```text
+. cookbooks
+├── README.md
+└── custom_web
+ ├── CHANGELOG.md
+ ├── LICENSE
+ ├── Policyfile.rb
+ ├── README.md
+ ├── chefignore
+ ├── compliance
+ │ ├── README.md
+ │ ├── inputs
+ │ ├── profiles
+ │ └── waivers
+ ├── kitchen.yml
+ ├── metadata.rb
+ ├── recipes
+ │ └── default.rb
+ ├── templates
+ │ └── httpd.erb
+ └── test
+ └── integration
+ └── default
+ └── default_test.rb
+```
+
+## Requirements
+
+{{< readfile file="content/reusable/md/template_requirements.md" >}}
+
+## Variables
+
+{{< readfile file="content/reusable/md/template_variables.md" >}}
+
+## File Specificity
+
+{{< readfile file="content/reusable/md/template_specificity.md" >}}
+
+{{< readfile file="content/reusable/md/template_specificity_pattern.md" >}}
+
+{{< readfile file="content/reusable/md/template_specificity_example.md" >}}
+
+## Host Notation
+
+{{< readfile file="content/reusable/md/template_host_notation.md" >}}
+
+## Transfer Frequency
+
+{{< readfile file="content/reusable/md/template_transfer_frequency.md" >}}
+
+## Partial Templates
+
+{{< readfile file="content/reusable/md/template_partials.md" >}}
+
+### variables Attribute
+
+{{< readfile file="content/reusable/md/template_partials_variables_attribute.md" >}}
+
+### render Method
+
+{{< readfile file="content/reusable/md/template_partials_render_method.md" >}}
diff --git a/content/terraform.md b/content/terraform.md
new file mode 100644
index 0000000..86f03df
--- /dev/null
+++ b/content/terraform.md
@@ -0,0 +1,54 @@
++++
+title = "Chef and Terraform"
+draft = false
+
+gh_repo = "chef-web-docs"
+product = ["client", "server"]
+
+[menu]
+ [menu.infra]
+ title = "Chef and Terraform"
+ identifier = "chef_infra/integrations/terraform.md Chef and Terraform"
+ parent = "chef_infra/integrations"
+ weight = 60
++++
+
+{{< warning >}}
+Terraform deprecated the Chef Provisioner in the [0.13.4](https://www.terraform.io/docs/language/resources/provisioners/chef.html) release and they will remove it in a future version. Terraform continues to support the Chef Provider.
+{{< /warning >}}
+
+[Terraform](https://www.terraform.io/) is an open-source infrastructure-as-code provisioning tool from [HashiCorp](https://www.hashicorp.com/). Terraform allows you to write code to define and provision infrastructure for the cloud, virtual machines, and on-premises machines. Terraform isn't a configuration management tool, it's responsible for deploying, maintaining, and destroying the infrastructure that servers and applications run on. When Terraform creates cloud or virtual servers, it uses [Provisioners](https://www.terraform.io/docs/provisioners/index.html) to enable configuration management to manage them. When Terraform talks to APIs to define or configure resources, it uses [Providers](https://www.terraform.io/docs/providers/index.html) to request those resources.
+
+## Chef Infra Provisioner
+
+The [Terraform Chef Provisioner](https://www.terraform.io/docs/provisioners/chef.html) bootstraps Terraform, provisioned with Chef Infra using SSH or WinRM, and configures them to work with a [Chef Infra Server](/server/). Standard bootstrap options such as Chef Infra versions, secrets, proxies, and assigning run lists using Policyfiles or Roles and Environments are all supported. The referenced documentation provides a complete list of supported options and an example of usage. HashiCorp provides support for the [Terraform Chef Provisioner](https://www.terraform.io/docs/provisioners/chef.html) and it's not officially supported by Chef Software.
+
+### Terraform and Chef Solo
+
+If you are using [Chef Solo](/chef_solo/), you will most likely want to use the [Terraform remote-exec Provisioner](https://www.terraform.io/docs/provisioners/remote-exec.html) rather than the Terraform Chef Provisioner. The remote-exec Provisioner may be used to run a script or an inline set of commands on the newly created machine. Please refer to the [Terraform remote-exec Provisioner documentation](https://www.terraform.io/docs/provisioners/remote-exec.html) for further options and examples.
+
+#### Example remote-exec inline
+
+```bash
+resource "aws_instance" "web" {
+ # ...
+
+ provisioner "remote-exec" {
+ inline = [
+ "wget -O /tmp/chef.rpm https://MYSERVER/chef_installers/chef-15.8.23-1.el7.x86_64.rpm",
+ "rpm -Uvh /tmp/chef.rpm",
+ "wget -O /tmp/base.tgz https://MYSERVER/policyfiles/base.tgz",
+ "tar -C /tmp -xzf /tmp/base.tgz",
+ "PWD=/tmp/base chef-client -z",
+ ]
+ }
+}
+```
+
+## Chef Infra Provider
+
+The [Terraform Chef Provider](https://www.terraform.io/docs/providers/chef/index.html) allows you to manage Chef Infra Server resources (nodes, data bags, etc.) using the Chef Infra Server API. Policyfiles, cookbooks, clients, and ACLs aren't currently managed with the Provider. The [Terraform Chef Provider documentation](https://www.terraform.io/docs/providers/chef/index.html) provides a complete list of supported options and an example of usage. HashiCorp provides support for the Terraform Chef Provider and it's not officially supported by Chef Software.
+
+## Additional Terraform Integrations
+
+* [Kitchen Terraform](https://newcontext-oss.github.io/kitchen-terraform/) is a community [Test Kitchen](/kitchen/) driver that allows for multi-node testing.
diff --git a/content/unified_mode.md b/content/unified_mode.md
new file mode 100644
index 0000000..a5b15cf
--- /dev/null
+++ b/content/unified_mode.md
@@ -0,0 +1,168 @@
++++
+title = "About Unified Mode"
+draft = false
+
+gh_repo = "chef-web-docs"
+product = ["client"]
+
+[menu]
+ [menu.infra]
+ title = "Unified Mode"
+ identifier = "chef_infra/resources/unified_mode.md Use Unified Mode"
+ parent = "chef_infra/resources"
+ weight = 20
++++
+
+{{< readfile file="content/reusable/md/unified_mode_overview.md" >}}
+
+## Availability
+
+{{< readfile file="content/reusable/md/unified_mode_client_releases.md" >}}
+
+## Enable Unified Mode
+
+{{< readfile file="content/reusable/md/unified_mode_enable.md" >}}
+
+## Unified Mode isolation
+
+If a Unified Mode resource calls a non-Unified Mode resource, the called resource isn't executed in Unified Mode.
+Each resource maintains its own state whether it's in Unified Mode or not.
+You don't need to modify a custom resource that calls a Unified Mode resource since the calling context won't affect the resource's execution.
+Resources using Unified Mode may call resources not using Unified Mode and vice versa.
+
+## Benefits of Unified Mode
+
+### Single-pass execution
+
+In Unified Mode, the Chef Infra Language executes from top to bottom, eliminating the compile and converge phases.
+
+With the deferred execution of resources to converge time, the user has to understand many different details of the Ruby parser to understand what constructs relate to Chef Infra resources and what constructs are parts of the core Ruby language to determine when those expression are executed. All that complexity is removed in Unified Mode.
+
+### Elimination of lazy blocks
+
+Several aspects of the Chef Infra Language still work but are no longer necessary in Unified Mode.
+Unified Mode eliminates the need for lazy blocks and the need to lazy Ruby code through a Ruby block.
+
+### Rescue blocks and other Ruby constructs work correctly
+
+In Unified Mode, it's now easy to write a rescue wrapper around a Chef Infra resource:
+
+```ruby
+begin
+ execute "a command that fails" do
+ command "/bin/false"
+ end
+rescue Mixlib::ShellOut::ShellCommandFailed => e
+ raise "failing because /bin/false returned a failed exit status"
+end
+```
+
+## Examples
+
+### Basic example
+
+A simple motivating example is to have a resource that downloads a JSON message using the [remote_file]({{< relref "/resources/remote_file" >}}) resource, parse the JSON using the [ruby_block]({{< relref "/resources/ruby_block" >}}), and then render a value into a [file]({{< relref "/resources/file" >}}) or [template]({{< relref "/resources/template" >}}) resource.
+
+Without Unified Mode, correctly writing this simple resource is complicated:
+
+```ruby
+provides :downloader
+
+action :doit do
+ remote_file "/tmp/users.json" do
+ source "https://jsonplaceholder.typicode.com/users"
+ end
+
+ array = nil
+
+ ruby_block "convert" do
+ block do
+ array = FFI_Yajl::Parser.parse(IO.read("/tmp/users.json"))
+ end
+ end
+
+ file "/tmp/phone" do
+ content lazy { array.last["phone"] }
+ end
+end
+```
+
+Since the remote_file and file resources execute at converge time, the Ruby code to parse the JSON needs to be wrapped in a `ruby_block` resource, the local variable then needs to be declared outside of that scope (requiring a deep knowledge of Ruby variable scoping rules), and then the content rendered into the file resource must be wrapped with `lazy` since the Ruby parses all arguments of properties at compile time instead of converge time.
+
+Unified Mode simplifies this resource:
+
+```ruby
+unified_mode true
+
+provides :downloader
+
+action :doit do
+ remote_file "/tmp/users.json" do
+ source "https://jsonplaceholder.typicode.com/users"
+ end
+
+ array = FFI_Yajl::Parser.parse(IO.read("/tmp/users.json"))
+
+ file "/tmp/phone" do
+ content array.last["phone"]
+ end
+end
+```
+
+Unified Mode eliminates the need for the `ruby_block` resource, the `lazy` evaluation, and the variable declaration, simplifying how the cookbook is authored.
+
+### Recovery and exception handling
+
+Another advantage is in error recovery and the use of rescue.
+
+```ruby
+unified_mode true
+
+provides :redis_install
+
+action :install do
+ version = "5.0.5"
+
+ # the downloading of this file acts as a guard for all the later
+ # resources -- but if the download is successful while the later
+ # resources fail for some transient issue, will won't redownload on
+ # the next run -- we lose our edge trigger.
+ #
+ remote_file "/tmp/redis-#{version}.tar.gz" do
+ source "http://download.redis.io/releases/redis-#{version}.tar.gz"
+ notifies :run, "execute[unzip_redis_archive]", :immediately
+ end
+
+ begin
+ execute "unzip_redis_archive" do
+ command "tar xzf redis-#{version}.tar.gz"
+ cwd "/tmp"
+ action :nothing
+ notifies :run, "execute[build_and_install_redis]", :immediately
+ end
+
+ execute "build_and_install_redis" do
+ command 'make && make install'
+ cwd "/tmp/redis-#{version}"
+ action :nothing
+ end
+ rescue Exception
+ file "/tmp/redis-#{version}.tar.gz" do
+ action :delete
+ end
+ raise
+ end
+end
+```
+
+This simplified example shows how to trap exceptions from resources using normal Ruby syntax and to clean up the resource. Without Unified Mode, this syntax is impossible. Normally when the [execute]({{< relref "resources/execute" >}}) resources are parsed, they only create the objects in the `resource_collection` to later be evaluated so that no exception is thrown while Ruby is parsing the `action` block. Every action is delayed to the later converge phase. In Unified Mode, the resource runs when Ruby is done parsing its block, so exceptions happen in-line with Ruby parsing and the rescue clause now works as expected.
+
+This is useful because the TAR extraction throws an exception (for example, the node could be out of disk space), which deletes the TAR file. The next time Chef Infra Client runs, the TAR file will be redownload. If the resource didn't have file cleanup after an exception, the TAR file would remain on the client node even though the resource isn't complete and the extraction didn't happen, leaving the resource in a broken, indeterminate state.
+
+{{< readfile file="content/reusable/md/unified_mode_actions_later_resources.md" >}}
+
+### Notifications and accumulators
+
+The accumulator pattern works unchanged. Notifications to the `:root` run context still behave identically. Since the compile and converge phases of custom resources both fire in the converge time (typically) of the enclosing `run_context`, the effect of eliminating the separate compile and converge phases of the custom resource has no visible effect from the outer context.
+
+{{< readfile file="content/reusable/md/unified_mode_troubleshooting.md" >}}
diff --git a/content/uninstall.md b/content/uninstall.md
new file mode 100644
index 0000000..e18ddaa
--- /dev/null
+++ b/content/uninstall.md
@@ -0,0 +1,74 @@
++++
+title = "Uninstall"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+aliases = ["/uninstall.html"]
+product = ["workstation", "server"]
+
+[menu]
+ [menu.infra]
+ title = "Uninstall"
+ identifier = "chef_infra/install/uninstall.md Uninstall"
+ parent = "chef_infra/install"
+ weight = 80
++++
+
+The following sections describe how to uninstall Chef, add-ons, and
+other components.
+
+## Chef Infra Server
+
+{{< readfile file="content/reusable/md/server/ctl_chef_server_uninstall.md" >}}
+
+## Chef Workstation
+
+Chef Workstation can be uninstalled using the steps below that are
+appropriate for the platform on which Chef Workstation is installed.
+
+### Debian
+
+Use the following command to remove Chef Workstation on Debian-based
+platforms:
+
+```bash
+dpkg -P chef-workstation
+```
+
+### macOS
+
+Use the following commands to remove Chef Workstation on macOS.
+
+To remove installed files:
+
+```bash
+sudo rm -rf /opt/chef-workstation
+```
+
+To remove the system installation entry:
+
+```bash
+sudo pkgutil --forget com.getchef.pkg.chef-workstation
+```
+
+To remove symlinks:
+
+> ```bash
+> sudo find /usr/local/bin -lname '/opt/chef-workstation/*' -delete
+> ```
+
+### Red Hat Enterprise Linux
+
+Use the following commands to remove Chef Workstation on Red Hat
+Enterprise Linux-based platforms:
+
+```bash
+rpm -qa *chef-workstation*
+sudo yum remove -y
+```
+
+### Windows
+
+Use **Add / Remove Programs** to remove Chef Workstation on the
+Windows platform.
diff --git a/content/upgrade_client.md b/content/upgrade_client.md
new file mode 100644
index 0000000..454744f
--- /dev/null
+++ b/content/upgrade_client.md
@@ -0,0 +1,80 @@
++++
+title = "Upgrade Chef Infra Client"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+aliases = ["/upgrade_client.html"]
+
+[menu]
+ [menu.infra]
+ title = "Upgrade"
+ identifier = "chef_infra/install/upgrade_client.md"
+ parent = "chef_infra/install"
+ weight = 50
++++
+
+The following sections describe the upgrade process for Chef Infra Client. If you are also [upgrading Chef Infra Server](https://docs.chef.io/server/upgrades) complete that process **first** and **then** upgrade the Chef Infra Client.
+
+## Prerequisites
+
+Commercial users must have a license ID. You can get your license ID from the [Chef Downloads portal](https://chef.io/downloads).
+
+For community users, see the [Chef install script documentation](/chef_install_script/).
+
+## Command line upgrades
+
+Use the [Chef install script](/chef_install_script/) to upgrade to the latest version of Chef Infra Client on a node from the command line.
+
+- On Linux, macOS, and Unix-based hosts:
+
+ ```bash
+ curl -L https://chefdownload-commercial.chef.io/install.sh?license_id= | sudo bash
+ ```
+
+ Replace `` with your license ID.
+
+- On Windows hosts:
+
+ ```powershell
+ . { iwr -useb https://chefdownload-commercial.chef.io/install.ps1?license_id= } | iex; install
+ ```
+
+ Replace `` with your license ID.
+
+### Specify the install version
+
+You can install a specific version of Chef Infra Client using the [Chef install script](/chef_install_script/).
+
+- Use the `-v` option to install a specific version on Linux, macOS, and Unix-based hosts. For example:
+
+ ```bash
+ curl -L https://chefdownload-commercial.chef.io/install.sh?license_id= | sudo bash -s -- -v 17.9.26
+ ```
+
+ Replace `` with your license ID.
+
+- Use the `-version` option to install a specific version on Windows hosts. For example:
+
+ ```powershell
+ . { iwr -useb https://chefdownload-commercial.chef.io/install.ps1?license_id= } | iex; install -version 17.9.26
+ ```
+
+ Replace `` with your license ID.
+
+### Upgrade multiple hosts with knife
+
+You can use the [`knife ssh` command](/workstation/knife_ssh/) in Chef Workstation to execute the install script on multiple Linux, macOS, and Unix-based hosts at once.
+
+```bash
+knife ssh 'curl -L https://chefdownload-commercial.chef.io/install.sh?license_id= | sudo bash'
+```
+
+Replace:
+
+- `` with your license ID
+- `` with a [node search query](/chef_search/)
+
+## Cookbook-based upgrade
+
+Use the [chef_client_updater cookbook](https://supermarket.chef.io/cookbooks/chef_client_updater) to install or upgrade Chef Infra Client on a node.
diff --git a/content/versions.md b/content/versions.md
new file mode 100644
index 0000000..56acedd
--- /dev/null
+++ b/content/versions.md
@@ -0,0 +1,123 @@
++++
+title = "Supported versions"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/versions.html"]
+product = ["automate", "client", "server", "habitat", "inspec", "supermarket", "workstation"]
+
+[menu]
+ [menu.overview]
+ title = "Supported versions"
+ identifier = "overview/packages_&_platforms/versions.md Supported Versions"
+ parent = "overview/packages_&_platforms"
+ weight = 10
++++
+
+This section lists the free and commercial Chef products and versions we currently support.
+The lifecycle stage defines the involvement by Chef Software in updating and maintaining each product.
+
+## Lifecycle definitions
+
+### Generally Available (GA)
+
+This stage indicates that the product or version is in active development and/or maintenance.
+
+- Chef continues to provide releases to the application or version in response to customer needs and security vulnerabilities
+- Chef welcomes customer feature requests for the product roadmap for the application
+
+### Deprecated
+
+This stage indicates that an application or version is no longer in
+active development and will eventually move to end of life status. Chef
+continues to provide support [according to our
+SLAs](https://www.chef.io/service-level-agreement/).
+
+- Chef no longer provides scheduled releases
+- Customers should use the GA alternative to these products; contact us for help with product selection and deployment
+- Chef may provide a release for a critical defect or security vulnerability
+
+### End of Life (EOL)
+
+This stage indicates that Chef has set a date after which the
+application or version will no longer be supported or recommended for
+use by customers.
+
+### Versions and status
+
+{{< important >}}
+
+Chef Infra Client generally follows an N-1 support strategy. This means that if version 16 is the latest version, then both 15 and 16 are supported. As soon as version 17 is released, then 15 is placed in EOL status and no longer supported.
+
+Unless otherwise stated, versions older than those listed below are EOL.
+
+{{< /important >}}
+
+## Supported commercial distributions
+
+Use of these and later versions of these distributions must be in
+accordance with the [Chef End User License
+Agreement](https://www.chef.io/end-user-license-agreement) or a
+commercial agreement with Chef. Additional information is available in
+[this announcement](https://www.chef.io/blog/chef-software-announces-the-enterprise-automation-stack).
+
+| Product | Version | Lifecycle Status | EOL Date |
+|-------------------|--------------------------|------------------|----------------|
+| Chef 360 Platform | Latest | GA | n/a |
+| Chef Automate | Latest | GA | n/a |
+| Chef Infra Client | 18.x | GA | n/a |
+| Chef Infra Server | 15.x | GA | n/a |
+| Chef Habitat | 0.81+ | GA | n/a |
+| Chef InSpec | 6.x | GA | n/a |
+| Chef Workstation | 24.x (2024), 25.x (2025) | GA | n/a |
+
+{{< note >}}
+
+**Chef Backend** doesn't directly require acceptance of the Chef
+EULA, but it does have functionality that requires its acceptance in other
+products.
+
+{{< /note >}}
+
+## Supported free distributions
+
+Use of the following distributions is governed by the Apache License,
+version 2.0.
+
+| Product | Version | Lifecycle Status | EOL Date |
+|-------------|---------|------------------|----------|
+| Supermarket | 5.x | GA | TBD |
+
+## Deprecated products and versions
+
+The following products are deprecated. Users are advised to move to
+newer versions or products.
+
+| Product | Version | Lifecycle Status | EOL Date |
+|-------------------|---------|------------------|----------------|
+| Chef Backend | 3.x | Deprecated | TBD |
+| Chef Infra Client | 17.x | Deprecated | TBD |
+| Chef Infra Server | 14.x | Deprecated | TBD |
+| Chef InSpec | 5.x | Deprecated | TBD |
+| Chef Manage | 2.5.x+ | Deprecated | TBD |
+
+## End of Life (EOL) products
+
+| Product | Version | Lifecycle Status | EOL Date |
+|--------------------------|----------------------|------------------|-------------------|
+| Analytics | All | EOL | December 31, 2018 |
+| Chef Automate | 2.x and under | EOL | May 13, 2022 |
+| Chef Infra Client | 16 and under | EOL | November 30, 2022 |
+| Chef Compliance Server | All | EOL | December 31, 2018 |
+| ChefDK | All | EOL | December 31, 2020 |
+| Chef Infra Server | 13.x | EOL | June 30, 2021 |
+| Chef InSpec | 2 and under | EOL | December 31, 2019 |
+| Chef InSpec | 3.x | EOL | April 30, 2020 |
+| Chef InSpec | 4.x | EOL | November 14, 2023 |
+| Chef Provisioning | All | EOL | August 31, 2019 |
+| Chef Push Jobs | All | EOL | December 31, 2020 |
+| Chef Replication/Sync | All | EOL | August 31, 2019 |
+| Chef Server DRBD HA | All | EOL | March 31, 2019 |
+| Chef Workflow (Delivery) | All | EOL | December 31, 2020 |
+| Chef Workstation | 23.12.1055 and under | EOL | December 31, 2024 |
+| Enterprise Chef | All | EOL | December 31, 2018 |
+| Reporting | All | EOL | December 31, 2018 |
diff --git a/content/vmware.md b/content/vmware.md
new file mode 100644
index 0000000..0ad9533
--- /dev/null
+++ b/content/vmware.md
@@ -0,0 +1,538 @@
++++
+title = "Chef and VMware"
+draft = false
+gh_repo = "chef-web-docs"
+aliases = ["/vmware.html"]
+product = ["workstation"]
+
+[menu]
+ [menu.infra]
+ title = "VMware"
+ identifier = "chef_infra/integrations/vmware.md VMware"
+ parent = "chef_infra/integrations"
+ weight = 30
++++
+
+VMware, Inc. is a subsidiary of Dell Technologies that provides cloud
+computing and platform virtualization software and services. This page
+outlines the different tools that can be used to integrate Chef with the
+VMware platform.
+
+For discussions on VMware and Chef, visit the
+[VMware{code}](https://code.vmware.com/web/code/join) Slack team,
+located in the **#chef** channel.
+
+## knife
+
+There are multiple knife plugins that interact with the VMware stack in
+different ways. The following knife plugins are directly supported by
+Chef:
+
+### knife-vsphere
+
+[[GitHub]](https://github.com/chef-partners/knife-vsphere)
+
+- Supports vCenter \> 5.0
+- Most VMware compute use cases are covered
+- The main starting point for Chef and VMware
+
+These are the necessary settings for your `config.rb` file:
+
+```ruby
+knife[:vsphere_host] = 'vcenter-hostname'
+knife[:vsphere_user] = 'privileged username' # Domain logins may need to be "user@domain.com"
+knife[:vsphere_pass] = 'password' # or %Q(mypasswordwithfunnycharacters)
+knife[:vsphere_dc] = 'your-datacenter'
+knife[:vsphere_insecure] = true # Set this if you have self signed certs
+```
+
+#### Usage Examples
+
+**Clone from a VMware template and bootstrap Chef with generic DHCP
+options:**
+
+```bash
+knife vsphere vm clone MACHINENAME --template TEMPLATENAME --bootstrap --cips dhcp
+```
+
+**Clone a virtual machine from a VMware template, use a customization
+template called "SPEC" to assist the bootstrapping process, and specify
+the SSH user and password:**
+
+```bash
+knife vsphere vm clone MACHINENAME --template TEMPLATENAME --bootstrap --cips dhcp \
+--cspec SPEC --connection-user USER --connection-password PASSWORD
+```
+
+{{< note >}}
+
+Add a `-f FOLDERNAME` if you put your `--template` in a directory other
+than the root folder. Use `--dest-folder FOLDERNAME` if you want your VM
+created in `FOLDERNAME` instead of the root folder.
+
+{{< /note >}}
+
+**Clone from a folder into the data center root directory:**
+
+```bash
+knife vsphere vm clone MACHINENAME --template TEMPLATENAME -f /path/to/template \
+--bootstrap --start --cips dhcp --dest-folder /
+```
+
+**List the available VMware templates:**
+
+```bash
+knife vsphere template list
+Template Name: ubuntu16-template
+knife vsphere template list -f FOLDERNAME
+Template Name: centos7-template
+```
+
+**Delete a machine:**
+
+```bash
+knife vsphere vm delete MACHINENAME
+```
+
+This command can be used with the `-P` option to remove the machine from
+Chef Infra Server.
+
+### knife-vcenter
+
+[[GitHub]](https://github.com/chef/knife-vcenter)
+
+- Supports vCenter >= 6.5 REST API
+- Supports the main use cases of knife: `bootstrap`, `create`,
+ `destroy`, and `list`
+- If you have the
+ [VCSA](https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.vcsa.doc/GUID-223C2821-BD98-4C7A-936B-7DBE96291BA4.html)
+ or are planning on upgrading to vCenter 6.5+, this is the plugin to
+ use
+
+The main settings for your `config.rb`:
+
+```ruby
+knife[:vcenter_username] = 'USERNAME'
+knife[:vcenter_password] = 'PASSWORD'
+knife[:vcenter_host] = '172.16.20.2'
+knife[:vcenter_disable_ssl_verify] = true # if you want to disable SSL checking
+```
+
+#### Usage Examples
+
+**Clone a machine:**
+
+```bash
+knife vcenter vm clone example-01 --targethost 172.16.20.3 --folder example --connection-password \
+P@ssw0rd! --datacenter Datacenter --template ubuntu16-template -N example-01
+Creating new machine
+Waiting for network interfaces to become available...
+ID: vm-183
+Name: example-01
+Power State: POWERED_ON
+Bootstrapping the server by using bootstrap_protocol: ssh and image_os_type: linux
+
+Waiting for sshd to host (10.0.0.167)
+...
+```
+
+**Delete a machine:**
+
+```bash
+knife vcenter vm delete example-01 -N example-01 --purge
+```
+
+The output is similar to the following:
+
+```bash
+Creating new machine
+Waiting for network interfaces to become available...
+ID: vm-183
+Name: example-01
+Power State: POWERED_ON
+Bootstrapping the server by using bootstrap_protocol: ssh and image_os_type: linux
+
+Waiting for sshd to host (10.0.0.167)
+WARNING: Deleted node example-01
+WARNING: Deleted client example-01
+```
+
+### knife-vrealize
+
+[[GitHub]](https://github.com/chef-partners/knife-vrealize)
+
+The knife-vrealize plugin supports both vRealize Automation and vRealize Orchestrator.
+
+{{< note >}}
+
+For knife-vrealize 6.0.4 and earlier, see the [documentation for knife-vrealize 6.0.4](https://github.com/chef/knife-vrealize/blob/v6.0.4/README.md)
+and downgrade the [VMware vRA Gem](https://github.com/chef-partners/vmware-vra-gem) to version 1.7.0.
+
+{{< /note >}}
+
+{{< note >}}
+
+knife-vrealize 7.0.0 and later supports vRealize Automation 8.x.
+
+knife-vrealize 6.0.3 and earlier supports vRealize Automation 7.x.
+
+{{< /note >}}
+
+The knife-vrealize gem supports the main use cases of knife: `bootstrap`, `create`, `destroy`, and `list`.
+It directly integrates with vRealize Automation to call out predetermined blueprints or catalogs, and
+can integrate directly with vRealize Orchestrator to call out predetermined workflows.
+
+#### config.rb Settings
+
+The main settings for your config.rb file are:
+
+```ruby
+knife[:vra_username] = 'USERNAME'
+knife[:vra_password] = 'PASSWORD'
+knife[:vra_base_url] = 'https://vra.example.local'
+knife[:vra_tenant] = 'tenant'
+knife[:vra_disable_ssl_verify] = true # if you want to disable SSL checking.
+```
+
+Additional `config.rb` settings are required to integrate with vRealize Orchestrator:
+
+```ruby
+knife[:vro_username] = 'USERNAME'
+knife[:vro_password] = 'PASSWORD'
+knife[:vro_base_url] = 'https://vra.example.local:8281'
+```
+
+#### knife-vrealize Common Parameters
+
+`--image-mapping`
+: The image mapping for the deployment which specifies the OS image for the virtual machine.
+
+`--flavor-mapping`
+: The flavor mapping of the target deployment which specifies the CPU count and RAM of a VM.
+
+`--project-id`
+: The project ID of the target deployment.
+
+`--name`
+: The name of the newly created deployment. The name must be unique.
+
+`--version`
+: The version of the catalog for the deployment. If left blank, the latest version will be used.
+
+`--ssh-password`
+: If a Linux host, the password to use during bootstrap.
+
+`--winrm-password`
+: If a Windows host, the password to use during bootstrap.
+
+`--image-os-type`
+: Windows or Linux.
+
+`--bootstrap-protocol`
+: WinRM or SSH
+
+`--server-create-timeout`
+: The number of seconds to wait for the server to complete. Increase this if your vRealize Automation environments takes more than 10 minutes to give you a server. Default value: 600 seconds.
+
+`--bootstrap-version`
+: Specify a specific Chef Infra Client version if your group isn't current.
+
+#### Usage Examples
+
+**Create a server from vRealize Automation:**
+
+If you want to create a server from a catalog blueprint, find the catalog ID with the
+`knife vra catalog list` command. After the resource is created, knife will attempt to bootstrap it.
+
+Each blueprint may require different parameters to complete provisioning. See your vRealize Automation administrator with questions. knife will attempt to provide any helpful error messages from vRealize Automation if they're available.
+
+```bash
+knife vra server create CATALOG_ID --name NAME --project-id PROJECT_ID \
+ --image-mapping IMAGE_MAPPING --flavor-mapping FLAVOR_MAPPING --image-os-type OS_TYPE --connection-protocol PROTOCOL \
+ -P PASSWORD --extra-param KEY=TYPE:VALUE
+```
+
+The output is similar to the following:
+
+```bash
+Catalog request b1f13afe-d7c1-4647-8866-30681fc7f63d submitted.
+Waiting for request to complete.
+Current request status: CREATE_INPROGRESS...............
+Catalog request complete.
+
+Request Status: CREATE_SUCCESSFUL
+
+Deployment ID: b1f13afe-d7c1-4647-8866-30681fc7f63d
+Deployment Name: test_dep-2
+IP Address: 10.30.236.21
+Owner Names: USERNAME
+Bootstrapping the server by using connection_protocol: ssh and image_os_type: linux
+
+Waiting for sshd to host (10.30.236.21)............
+...
+```
+
+**Delete a server from vRealize Automation:**
+
+```bash
+knife vra server delete CATALOG_ID --purge
+```
+
+The output is similar to the following:
+
+```bash
+Deployment ID: 2e1f6632-1613-41d1-a07c-6137c9639609
+Deployment Name: test_dep-2
+IP Address: 10.30.236.21
+Status: SUCCESS
+Owner Names: USERNAME
+
+Do you really want to delete this server? (Y/N) y
+Destroy request 5e390a9d-1340-489d-94be-b4eb1df98c53 submitted.
+Waiting for request to complete.
+Current request status: CHECKING_APPROVAL...
+...
+```
+
+If you supply the `--purge` option, the server will also be removed from
+the Chef Infra Server.
+
+**Execute a vRealize Orchestrator workflow:**
+
+This requires the workflow name. If your workflow name isn't unique in your vRealize Orchestrator workflow list, you
+can specify a workflow ID with `--vro-workflow-id ID`. You can find the workflow ID from the vRealize Orchestrator UI; however, the workflow name is still required.
+
+```bash
+knife vro workflow execute WORKFLOW_NAME KEY1=VALUE1 KEY2=VALUE2
+```
+
+The output is similar to the following:
+
+```bash
+Starting workflow execution...
+Workflow execution 4028eece4effc046014f27da864d0187 started. Waiting for it to complete...
+Workflow execution complete.
+
+Output Parameters:
+outkey1: some value (string)
+
+Workflow Execution Log:
+2015-08-13 09:17:57 -0700 info: cloudadmin: Workflow 'Knife Testing' has started
+2015-08-13 09:17:58 -0700 info: cloudadmin: Workflow 'Knife Testing' has completed
+```
+
+## Test Kitchen
+
+The following Test Kitchen drivers for VMware are directly supported by
+Chef:
+
+### kitchen-vsphere (chef-provisioning-vsphere)
+
+[[GitHub]](https://github.com/chef-partners/chef-provisioning-vsphere)
+
+- Built into the chef-provisioning-vsphere driver
+- A community driven project, with Chef Partners maintaining the
+ releases
+- Leverages the typical Test Kitchen workflow for vCenter \> 5.0+
+- There is a
+ [kitchen-vsphere](https://rubygems.org/gems/kitchen-vsphere) gem,
+ but it's not supported at this time
+
+#### Usage Examples
+
+There is an [example
+cookbook](https://github.com/jjasghar/vsphere_testing) that attempts to
+capture everything required. The following is a basic `kitchen.yml`
+example:
+
+```yaml
+---
+driver:
+name: vsphere
+driver_options:
+ host: FQDN or IP of vCenter
+ user: 'administrator@vsphere.local'
+ password: 'PASSWORD'
+ insecure: true
+machine_options:
+ start_timeout: 600
+ create_timeout: 600
+ ready_timeout: 90
+ bootstrap_options:
+ use_linked_clone: true
+ datacenter: 'Datacenter'
+ template_name: 'ubuntu16'
+ template_folder: 'Linux'
+ resource_pool: 'Cluster'
+ num_cpus: 2
+ memory_mb: 4096
+ ssh:
+ user: ubuntu
+ paranoid: false
+ password: PASSWORD
+ port: 22
+
+provisioner:
+ name: chef_zero
+ sudo_command: sudo
+
+verifier:
+ name: inspec
+
+transport:
+ username: root or ssh enabled user
+ password: PASSWORD for root or user
+
+platforms:
+ - name: ubuntu-18.04
+ - name: centos-8
+
+suites:
+ - name: default
+ run_list:
+ - recipe[COOKBOOK::default]
+ attributes:
+```
+
+### kitchen-vcenter
+
+[[GitHub]](https://github.com/chef/kitchen-vcenter)
+
+- Supports vCenter \>= 6.5 REST API
+- Leverages the typical Test Kitchen workflow for vCenter \>= 6.5+
+- If you have the
+ [VCSA](https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.vcsa.doc/GUID-223C2821-BD98-4C7A-936B-7DBE96291BA4.html)
+ or are planning on upgrading to vCenter 6.5+, use this plugin
+
+#### Usage Examples
+
+The following is a basic `kitchen.yml` for vCenter:
+
+```yaml
+driver:
+ name: vcenter
+ vcenter_username: <%= ENV['VCENTER_USER'] || "administrator@vsphere.local" %>
+ vcenter_password: <%= ENV['VCENTER_PASSWORD'] || "password" %>
+ vcenter_host: vcenter.chef.io
+ vcenter_disable_ssl_verify: true
+ driver_config:
+ targethost: 172.16.20.41
+ datacenter: "Datacenter"
+
+platforms:
+ - name: ubuntu-2004
+ driver_config:
+ template: ubuntu16-template
+ - name: centos-8
+ driver_config:
+ template: centos7-template
+```
+
+### kitchen-vra
+
+[[GitHub]](https://github.com/chef-partners/kitchen-vra)
+
+- An integration point with vRealize Automation and Test Kitchen
+- For companies required to use vRealize Automation this is a natural progression for
+ Chef Development
+
+#### Usage Examples
+
+The following is a basic `kitchen.yml` example:
+
+```yaml
+driver:
+ name: vra
+ username: user@corp.local
+ password: password
+ tenant: tenant
+ base_url: https://vra.corp.local
+ verify_ssl: true
+
+platforms:
+- name: centos6
+ driver:
+ catalog_id: e9db1084-d1c6-4c1f-8e3c-eb8f3dc574f9
+- name: centos7
+ driver:
+ catalog_id: c4211950-ab07-42b1-ba80-8f5d3f2c8251
+```
+
+### kitchen-vro
+
+[[GitHub]](https://github.com/chef-partners/kitchen-vro)
+
+- An integration point with vRealize Orchestrator and Test Kitchen
+- Leverages specific Workflows in vRealize Orchestrator if it's required by VMware
+ admins
+
+#### Usage Examples
+
+The following is a basic `kitchen.yml` example:
+
+```yaml
+driver:
+ name: vro
+ vro_username: user@domain.com
+ vro_password: password
+ vro_base_url: https://vra.corp.local:8281
+ create_workflow_name: Create TK Server
+ destroy_workflow_name: Destroy TK Server
+
+platforms:
+ - name: centos
+ driver:
+ create_workflow_parameters:
+ os_name: centos
+ os_version: 6.7
+ - name: windows
+ driver:
+ create_workflow_parameters:
+ os_name: windows
+ os_version: server2012
+ cpus: 4
+ memory: 4096
+```
+
+## Chef InSpec
+
+The Chef InSpec VMware plugin is used to verify the vCenter and ESXi
+VMware stack.
+
+### inspec-vmware
+
+[[GitHub]](https://github.com/chef/inspec-vmware)
+
+- Supports vCenter \> 5.0
+- 11 resources available at the time of writing, with more planned
+
+#### Usage Examples
+
+An example demo control:
+
+```ruby
+control 'vmware-1' do
+ impact 0.7
+ title 'Checks that soft power off is disabled'
+ describe vmware_vm_advancedsetting({ datacenter: 'ha-datacenter', vm: 'testvm' }) do
+ its('softPowerOff') { should cmp 'false' }
+ end
+end
+```
+
+## Chef integrations inside of the VMware Suite
+
+### vRealize Automation Example Blueprints
+
+- [Linux](https://code.vmware.com/samples?id=1371)
+- [Windows](https://code.vmware.com/samples?id=1390)
+
+### vRealize Orchestrator plugin
+
+- The [Chef plugin for vRealize
+ Orchestrator](https://solutionexchange.vmware.com/store/products/chef-plugin-for-vrealize-orchestrator)
+ (vRO) is a VMware-supplied plugin
+- If you use vRealize Orchestrator, this provides the majority of the necessary features
+
+For more information, see the plugin demo on
+[YouTube](https://www.youtube.com/watch?v=HlvoZ4Zdwc4).
diff --git a/content/windows.md b/content/windows.md
new file mode 100644
index 0000000..ef815ee
--- /dev/null
+++ b/content/windows.md
@@ -0,0 +1,270 @@
++++
+title = "Chef for Windows"
+draft = false
+
+gh_repo = "chef-web-docs"
+
+aliases = ["/windows.html"]
+
+[menu]
+ [menu.infra]
+ title = "Chef for Windows"
+ identifier = "chef_infra/integrations/windows/windows.md Chef for Windows"
+ parent = "chef_infra/integrations/windows"
+ weight = 10
++++
+
+## Overview
+
+The Chef Infra Client has specific components that are designed to
+support unique aspects of the Windows platform, including
+PowerShell, PowerShell DSC, and Internet Information Services (IIS).
+
+{{< readfile file="content/reusable/md/windows_install_overview.md" >}}
+
+## Setting up Windows Workstations
+
+To set up your Windows workstation follow the steps on [Chef for
+Windows](/workstation/install_workstation/)
+
+## Install Chef Infra Client on Windows Nodes
+
+{{< readfile file="content/reusable/md/chef_client_summary.md" >}}
+
+This command has the following syntax:
+
+```bash
+chef-client OPTION VALUE OPTION VALUE ...
+```
+
+This command has the following option specific to Windows:
+
+`-A`, `--fatal-windows-admin-check`
+
+: Cause a Chef Infra Client run to fail when Chef Infra Client does
+ not have administrator privileges in Windows.
+
+### System Requirements
+
+The recommended minimum amount of RAM available to Chef Infra Client
+during a Chef Infra Client run is 512MB. Each node and workstation must
+have access to Chef Infra Server using HTTPS. The Chef Infra Client can be
+used to manage machines that run on the following versions of Microsoft
+Windows:
+
+
+
+
+
+
+
+
+
+
Operating System
+
Architecture
+
Version
+
+
+
+
+
Windows
+
x86, x64
+
8.1, 2012, 2012 R2, 2016, 10 (all channels except "insider" builds), 2019 (Long-term servicing channel (LTSC), both Desktop Experience and Server Core)
+
+
+
+
+After Chef Infra Client is installed, it's located at `C:\opscode`. The
+main configuration file for Chef Infra Client is located at
+`C:\chef\client.rb`.
+
+### Information for Windows Users
+
+#### Run With Elevated Privileges
+
+{{< readfile file="content/reusable/md/workstation/ctl_chef_client_elevated_privileges.md" >}}
+
+{{< readfile file="content/reusable/md/workstation/ctl_chef_client_elevated_privileges_windows.md" >}}
+
+#### Spaces and Directories
+
+{{< readfile file="content/reusable/md/windows_spaces_and_directories.md" >}}
+
+#### Top-level Directory Names
+
+{{< readfile file="content/reusable/md/windows_top_level_directory_names.md" >}}
+
+#### PATH System Variable
+
+{{< readfile file="content/reusable/md/windows_environment_variable_path.md" >}}
+
+#### Proxy Settings
+
+{{< readfile file="content/reusable/md/proxy_windows.md" >}}
+
+### Remotely administering nodes
+
+{{< readfile file="content/reusable/md/workstation/knife_windows_summary.md" >}}
+
+For more information, see the [`knife windows` documentation](/workstation/knife_windows/).
+
+#### Ports
+
+{{< readfile file="content/reusable/md/workstation/knife_windows_winrm_ports.md" >}}
+
+### Install Chef Infra Client using the MSI Installer
+
+A Microsoft Installer Package (MSI) is available for installing Chef
+Infra Client on a Windows machine from [Chef Downloads](https://www.chef.io/downloads).
+
+#### Msiexec.exe
+
+{{< readfile file="content/reusable/md/windows_msiexec.md" >}}
+
+#### ADDLOCAL Options
+
+{{< readfile file="content/reusable/md/windows_msiexec_addlocal.md" >}}
+
+#### Enable as a Scheduled Task
+
+{{< readfile file="content/reusable/md/install_chef_client_windows_as_scheduled_task.md" >}}
+
+### Install Chef Infra Client using an Existing Process
+
+{{< readfile file="content/reusable/md/windows_install_system_center.md" >}}
+
+## Windows Cookbooks
+
+Some of the most popular Chef-maintained cookbooks that contain custom
+resources useful when configuring machines running Windows are
+listed below:
+
+