From 372c09988d523ab8c66e5c5923d3a7aeaad9fb04 Mon Sep 17 00:00:00 2001 From: Ian Maddaus Date: Mon, 16 Dec 2024 20:28:34 -0500 Subject: [PATCH] Fix contractions and other linting issues (#4358) * Fix contractions and other linting issues Signed-off-by: Ian Maddaus * Corrections Signed-off-by: Ian Maddaus * Correction Signed-off-by: Ian Maddaus * Additional corrections Signed-off-by: Ian Maddaus * More fixes Signed-off-by: Ian Maddaus * and so on Signed-off-by: Ian Maddaus * final fixes Signed-off-by: Ian Maddaus --------- Signed-off-by: Ian Maddaus --- archetypes/all_the_resources.md | 2 +- content/attribute_arrays.md | 8 +- content/attribute_precedence.md | 14 +- content/attribute_sources.md | 6 +- content/aws_marketplace.md | 4 +- content/azure_chef_cli.md | 8 +- content/azure_cwa_cloud_shell.md | 2 +- content/azure_powershell.md | 6 +- content/azure_testdrive.md | 2 +- content/chef_client_security.md | 8 +- content/chef_compliance_phase.md | 20 +-- content/chef_deprecations_client.md | 16 +-- content/chef_install_script.md | 4 +- content/chef_repo.md | 4 +- content/chef_search.md | 16 +-- content/chef_solo.md | 2 +- content/community_contributions.md | 26 ++-- content/community_guidelines.md | 81 +++-------- content/config_rb_client.md | 2 +- content/config_rb_manage.md | 8 +- content/config_rb_solo.md | 8 +- content/cookbook_repo.md | 2 +- content/cookbook_versioning.md | 16 +-- content/cookbooks.md | 2 +- content/ctl_chef_client.md | 86 ++++++------ content/ctl_chef_solo.md | 8 +- content/ctl_manage.md | 4 +- content/ctl_ohai.md | 2 +- content/custom_resource_glossary.md | 2 +- content/custom_resources_notes.md | 24 ++-- content/debug.md | 22 +-- content/definitions_to_custom_resources.md | 18 +-- content/deprecations_attributes.md | 2 +- content/deprecations_chef_gem_compile_time.md | 2 +- content/deprecations_chef_platform_methods.md | 8 +- .../deprecations_custom_resource_cleanups.md | 28 ++-- ...eprecations_dnf_package_allow_downgrade.md | 4 +- content/deprecations_epic_fail.md | 2 +- content/deprecations_exit_code.md | 6 +- content/deprecations_locale_lc_all.md | 2 +- content/deprecations_map_collision.md | 2 +- content/deprecations_namespace_collisions.md | 24 ++-- content/deprecations_ohai_amazon_linux.md | 4 +- content/deprecations_ohai_sigar_plugins.md | 2 +- content/deprecations_ohai_system_profile.md | 4 +- content/deprecations_ohai_v6_plugins.md | 2 +- .../deprecations_property_name_collision.md | 2 +- ...ecations_resource_name_without_provides.md | 6 +- content/deprecations_verify_file.md | 4 +- content/enterprise_chef.md | 4 +- content/enterprise_community_chef.md | 8 +- content/environments.md | 24 ++-- content/errors.md | 24 ++-- content/feedback.md | 4 +- content/fips.md | 34 ++--- content/glossary.md | 18 +-- content/google.md | 2 +- content/handlers.md | 14 +- .../infra_language/checking_hypervisors.md | 4 +- content/infra_language/checking_platforms.md | 6 +- content/infra_language/cookbook_execution.md | 4 +- content/infra_language/editing_resources.md | 38 ++--- content/infra_language/reading_data_bags.md | 2 +- content/infra_language/shelling_out.md | 4 +- content/install_bootstrap.md | 4 +- content/install_chef_air_gap.md | 6 +- content/licensing/terms.md | 2 +- content/lwrp_to_custom_resources.md | 6 +- content/manage.md | 2 +- content/nodes.md | 14 +- content/ohai.md | 2 +- content/ohai_custom.md | 28 ++-- content/packages.md | 2 +- content/platform_overview.md | 12 +- content/plugin_community.md | 6 +- content/policyfile.md | 22 +-- content/proxies.md | 8 +- content/recipes.md | 14 +- content/release_notes_360.md | 18 +-- content/release_notes_chefdk.md | 132 +++++++++--------- content/resource.md | 6 +- content/resource_common.md | 10 +- content/resources/_index.md | 4 +- content/reusable/md/EOL_manage.md | 2 +- .../reusable/md/chef_client_bootstrap_node.md | 2 +- .../md/chef_client_bootstrap_stages.md | 2 +- content/reusable/md/chef_client_run.md | 6 +- content/reusable/md/chef_client_summary.md | 2 +- .../reusable/md/chef_shell_advanced_debug.md | 2 +- .../md/chef_shell_debug_existing_recipe.md | 4 +- content/reusable/md/chef_shell_manage.md | 2 +- content/reusable/md/chef_shell_modes.md | 2 +- .../md/chef_shell_run_as_chef_client.md | 4 +- .../md/chef_shell_step_through_run_list.md | 2 +- content/reusable/md/chef_solo_summary.md | 4 +- .../reusable/md/config_rb_client_summary.md | 2 +- .../reusable/md/cookbook_file_specificity.md | 4 +- content/reusable/md/cookbooks_recipe.md | 2 +- content/reusable/md/cookbooks_summary.md | 4 +- content/reusable/md/cookbooks_version.md | 4 +- content/reusable/md/data_bag_encryption.md | 6 +- .../reusable/md/dsl_handler_event_types.md | 12 +- .../dsl_handler_slide_send_email_handler.md | 2 +- content/reusable/md/fips_intro_client.md | 4 +- content/reusable/md/handler_type_start.md | 4 +- ...ang_method_registry_value_exists_syntax.md | 2 +- content/reusable/md/infra_lang_summary.md | 2 +- content/reusable/md/install_chef_client.md | 2 +- content/reusable/md/libraries_summary.md | 2 +- content/reusable/md/node.md | 2 +- content/reusable/md/node_attribute.md | 2 +- .../reusable/md/node_attribute_allowlist.md | 4 +- .../md/node_attribute_allowlist_warning.md | 4 +- .../md/node_attribute_blocklist_warning.md | 2 +- .../md/node_attribute_type_automatic.md | 4 +- content/reusable/md/node_ctl_attribute.md | 4 +- content/reusable/md/node_run_list.md | 4 +- content/reusable/md/node_types.md | 2 +- .../md/notes_registry_key_not_if_only_if.md | 2 +- .../md/notes_resource_based_on_package.md | 2 +- .../reusable/md/ohai_automatic_attribute.md | 8 +- content/reusable/md/ohai_summary.md | 2 +- content/reusable/md/plugin_knife_summary.md | 2 +- content/reusable/md/policyfile_lock_json.md | 2 +- content/reusable/md/policyfile_rb.md | 2 +- content/reusable/md/policyfile_rb_settings.md | 26 ++-- content/reusable/md/policyfile_summary.md | 2 +- content/reusable/md/release_channels.md | 2 +- .../remote_directory_recursive_directories.md | 4 +- ...directory_recursive_directories_example.md | 2 +- .../md/remote_file_prevent_re_downloads.md | 2 +- content/reusable/md/remote_file_unc_path.md | 12 +- .../resource_before_notification_restart.md | 2 +- .../resource_chef_gem_gem_package_install.md | 6 +- .../md/resource_cookbook_file_summary.md | 2 +- .../resource_execute_command_from_template.md | 2 +- .../md/resource_package_options_hash.md | 2 +- ...ervice_subscribes_reload_using_template.md | 2 +- ...ource_template_notifies_run_immediately.md | 4 +- .../md/resources_common_actions_nothing.md | 2 +- ...esources_common_actions_nothing_default.md | 2 +- .../md/resources_common_atomic_update.md | 2 +- .../reusable/md/resources_common_compile.md | 2 +- .../md/resources_common_compile_begin.md | 10 +- ...on_guard_interpreter_attributes_inherit.md | 4 +- .../reusable/md/resources_common_guards.md | 8 +- .../md/resources_common_guards_properties.md | 2 +- .../md/resources_common_lazy_evaluation.md | 6 +- .../md/resources_common_multiple_packages.md | 2 +- .../resources_common_notification_notifies.md | 6 +- ...esources_common_notification_subscribes.md | 8 +- .../md/resources_common_powershell.md | 2 +- .../md/resources_common_properties.md | 4 +- .../resources_common_windows_security_acl.md | 10 +- ...ources_common_windows_security_inherits.md | 2 +- content/reusable/md/role_attribute.md | 2 +- .../reusable/md/ruby_class_chef_log_fatal.md | 8 +- .../md/ruby_class_chef_log_multiple.md | 2 +- .../reusable/md/ruby_style_basics_chef_log.md | 2 +- .../md/ruby_style_patterns_hyphens.md | 4 +- content/reusable/md/search.md | 2 +- .../reusable/md/search_boolean_operators.md | 2 +- .../reusable/md/search_pattern_wildcard.md | 2 +- content/reusable/md/search_query_syntax.md | 4 +- .../md/security_chef_validator_context.md | 2 +- content/reusable/md/template.md | 2 +- .../md/template_specificity_example.md | 2 +- .../md/template_transfer_frequency.md | 2 +- content/reusable/md/template_variables.md | 4 +- content/reusable/md/unified_mode_overview.md | 2 +- .../md/windows_environment_variable_path.md | 4 +- content/reusable/md/windows_msiexec.md | 2 +- .../md/windows_registry_key_backslashes.md | 2 +- .../md/windows_spaces_and_directories.md | 4 +- .../md/windows_top_level_directory_names.md | 4 +- content/roles.md | 24 ++-- content/ruby.md | 40 +++--- content/run_lists.md | 4 +- content/saas/register_nodes.md | 2 +- content/saas/sso.md | 4 +- content/server_configure_saml.md | 4 +- content/server_ldap.md | 4 +- content/server_manage_clients.md | 4 +- content/server_manage_cookbooks.md | 2 +- content/server_manage_nodes.md | 2 +- content/style/_index.md | 2 +- content/style/chef_house.md | 8 +- content/style/contribute.md | 2 +- content/style/front_matter.md | 6 +- content/style/headings.md | 4 +- content/style/linking.md | 2 +- content/style/markdown.md | 2 +- content/style/notices.md | 2 +- content/style/procedures.md | 8 +- content/style/product_names.md | 3 +- content/style/test.md | 4 +- content/templates.md | 2 +- content/terraform.md | 6 +- content/versions.md | 2 +- content/vmware.md | 12 +- content/windows.md | 4 +- cspell.yaml | 4 + 202 files changed, 740 insertions(+), 782 deletions(-) diff --git a/archetypes/all_the_resources.md b/archetypes/all_the_resources.md index af22a30076..b8fb20ba7c 100644 --- a/archetypes/all_the_resources.md +++ b/archetypes/all_the_resources.md @@ -70,7 +70,7 @@ The following properties are common to every resource: `sensitive` : **Ruby Type:** true, false | **Default Value:** `false` - Ensure that sensitive resource data is not logged by Chef Infra Client. + Ensure that sensitive resource data isn't logged by Chef Infra Client. #### Examples diff --git a/content/attribute_arrays.md b/content/attribute_arrays.md index 27342d86e1..557fed448d 100644 --- a/content/attribute_arrays.md +++ b/content/attribute_arrays.md @@ -29,7 +29,7 @@ override_attributes( ) ``` -But what if all of the web servers are not 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: +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( @@ -44,7 +44,7 @@ override_attributes( ) ``` -But that is not 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 are supposed to be. +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`: @@ -115,7 +115,7 @@ to produce results like this: } ``` -Even though the `web.rb` file does not contain attributes and values for `minspareservers`, `maxspareservers`, `serverlimit`, `maxclients`, and `maxrequestsperchild`, the deep merge capabilities pulled them in. +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 @@ -153,7 +153,7 @@ role_or_environment 2 { :x => '1' , :y => '2' } { :x => '1', :y => '2' } ``` -When items cannot be merged through substitution, the original data is overwritten. +When items can't be merged through substitution, the original data is overwritten. ### Addition diff --git a/content/attribute_precedence.md b/content/attribute_precedence.md index 492e16039f..014af9ae5e 100644 --- a/content/attribute_precedence.md +++ b/content/attribute_precedence.md @@ -29,7 +29,7 @@ The attribute precedence order for the sources "roles" and "environments" are op 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 is 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. +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 >}} @@ -211,7 +211,7 @@ node.default['foo'] = { And some role attributes: ```ruby -# Please do not ever do this in real code :) +# Please don't ever do this in real code :) node.role_default['foo']['bar']['thing'] = 'otherstuff' ``` @@ -227,7 +227,7 @@ When the default attribute precedence `node['foo']['bar']` is removed: node.rm_default('foo', 'bar') #=> {'baz' => 52, 'thing' => 'allthestuff'} ``` -What is left under `'foo'` is only `'bat'`: +What's left under `'foo'` is only `'bat'`: ```ruby node.attributes.combined_default['foo'] #=> {'bat' => { 'things' => [5,6] } } @@ -252,7 +252,7 @@ node.default['foo'] = { And some role attributes: ```ruby -# Please do not ever do this in real code :) +# Please don't ever do this in real code :) node.role_default['foo']['bar']['thing'] = 'otherstuff' ``` @@ -425,7 +425,7 @@ Given the following code structure: ```ruby node.default['foo']['bar'] = {'a' => 'b'} -# Please do not ever do this in real code :) +# Please don't ever do this in real code :) node.role_default['foo']['bar'] = {'c' => 'd'} node.default!['foo']['bar'] = {'d' => 'e'} ``` @@ -443,7 +443,7 @@ Given the following code structure: ```ruby node.default['foo']['bar'] = {'a' => 'b'} -# Please do not ever do this in real code :) +# Please don't ever do this in real code :) node.role_default['foo']['bar'] = {'c' => 'd'} node.force_default!['foo']['bar'] = {'d' => 'e'} ``` @@ -473,7 +473,7 @@ node.default['foo'] = { And some attributes: ```ruby -# Please do not ever do this in real code :) +# Please don't ever do this in real code :) node.role_default['foo']['bar']['baz'] = 55 node.force_default['foo']['bar']['baz'] = 66 ``` diff --git a/content/attribute_sources.md b/content/attribute_sources.md index d680c4cde9..f0de233b9c 100644 --- a/content/attribute_sources.md +++ b/content/attribute_sources.md @@ -10,7 +10,7 @@ draft = false +++ -Chef Infra Client evaluates attributes in the order that they are defined in the +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. @@ -87,7 +87,7 @@ of the attribute priority methods: - `normal_unless` Use the `_unless` variants carefully (and only when necessary) because -when they are used, attributes applied to nodes may become out of sync +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 @@ -104,7 +104,7 @@ Use the following methods within the attributes file for a cookbook or within a ### attribute? -A useful method that is related to attributes is the `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. diff --git a/content/aws_marketplace.md b/content/aws_marketplace.md index 5895c4b917..d5776111bd 100644 --- a/content/aws_marketplace.md +++ b/content/aws_marketplace.md @@ -101,7 +101,7 @@ AWS provides five VPCs for each region. If you require more VPCs, please contact 1. Set the stack creation options: Timeout - : If specified and stack creation is not completed in that time, CloudFormation will roll back the stack. + : 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. @@ -118,7 +118,7 @@ For additional information about these options, see [Amazon's documentation on C 1. Open your browser and paste the Chef Automate URL, which will open an alert page. 1. Select **Advanced** and continue. -![Select 'advanced' to bypass the warning that the page is not secure](/images/NotSecurePage.png "Not Secure Page"). +![Select 'advanced' to bypass the warning that the page isn't secure](/images/NotSecurePage.png "Not Secure Page"). 1. Enter your **Username** and **Password** and select **Sign In**. ![ ](/images/chef_automate_login.png "Chef Automate Login") diff --git a/content/azure_chef_cli.md b/content/azure_chef_cli.md index 78dec81cdb..53fe0e3f22 100644 --- a/content/azure_chef_cli.md +++ b/content/azure_chef_cli.md @@ -29,7 +29,7 @@ machines in Microsoft Azure. ### get-chef Use the `get-chef` command to get the details for the Azure Chef -Extension that is running on the named virtual machine. +Extension that's running on the named virtual machine. #### Syntax @@ -78,7 +78,7 @@ This command has the following options: `-j JSON`, `--bootstrap-options JSON` -: A JSON string that is added to the first run of a Chef Infra Client. +: A JSON string that's added to the first run of a Chef Infra Client. For example: ```bash @@ -196,7 +196,7 @@ The extension has the following options that can be provided in the `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 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. +: 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` @@ -208,7 +208,7 @@ The extension has the following options that can be provided in the `secret` -: The encryption key that is used for values contained within a data bag item. +: The encryption key that's used for values contained within a data bag item. `validation_client_name` diff --git a/content/azure_cwa_cloud_shell.md b/content/azure_cwa_cloud_shell.md index 2a38c24542..d7587f00dd 100644 --- a/content/azure_cwa_cloud_shell.md +++ b/content/azure_cwa_cloud_shell.md @@ -37,7 +37,7 @@ 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 have not used +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 index 0ac81e1863..d47931f297 100644 --- a/content/azure_powershell.md +++ b/content/azure_powershell.md @@ -22,7 +22,7 @@ on virtual machines in Microsoft Azure. ### Get-AzureVMChefExtension Use the `Get-AzureVMChefExtension` cmdlet to get the details for the -Azure Chef Extension that is running on the named virtual machine. +Azure Chef Extension that's running on the named virtual machine. #### Syntax @@ -70,11 +70,11 @@ 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 is published. +: 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 is added to the first run of a Chef Infra Client. +: A JSON string that's added to the first run of a Chef Infra Client. For example: diff --git a/content/azure_testdrive.md b/content/azure_testdrive.md index 3281cdd688..f875032f4d 100644 --- a/content/azure_testdrive.md +++ b/content/azure_testdrive.md @@ -22,7 +22,7 @@ product = ["client", "workstation", "automate"] ## Test Drive -A **Test Drive** is a ready-to-go environment that allows you to experience Chef Automate for free, without an Azure subscription (You will need a [Microsoft account](https://signup.live.com/). The Test Drive comes already provisioned---you do not need to download, set up, or configure it---instead, you can spend two hours evaluating the user experience, key features, and benefits of the product. +A **Test Drive** is a ready-to-go environment that allows you to experience Chef Automate for free, without an Azure subscription (You will need a [Microsoft account](https://signup.live.com/). The Test Drive comes already provisioned---you don't need to download, set up, or configure it---instead, you can spend two hours evaluating the user experience, key features, and benefits of the product. ### Get Started diff --git a/content/chef_client_security.md b/content/chef_client_security.md index fedd27e993..3db46af390 100644 --- a/content/chef_client_security.md +++ b/content/chef_client_security.md @@ -31,7 +31,7 @@ aliases = ["/chef_client_security.html", "/auth.html"] {{< warning >}} -The following information applies to on-premises Chef Infra Server and does not apply to Hosted Chef. +The following information applies to on-premises Chef Infra Server and doesn't apply to Hosted Chef. {{< /warning >}} @@ -41,11 +41,11 @@ The following information applies to on-premises Chef Infra Server and does not Your organization may 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 are not issued by a trusted Certificate Authority (CA). +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 the [chef_client_trusted_certificate]({{< relref "/resources/chef_client_trusted_certificate" >}}) Chef Infra Client resource to manage these certificates continuously. +Use the [chef_client_trusted_certificate]({{< relref "/resources/chef_client_trusted_certificate" >}}) Chef Infra Client resource to manage these certificates continuously. #### trusted_certs Locations @@ -67,7 +67,7 @@ When you bootstrap a node, the Chef Infra Client copies the SSL certificates for 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` is not set by default. Unless updated, the locations in which Chef Infra will look for SSL certificates are: +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` diff --git a/content/chef_compliance_phase.md b/content/chef_compliance_phase.md index 34f5b86671..fb4764cb15 100644 --- a/content/chef_compliance_phase.md +++ b/content/chef_compliance_phase.md @@ -18,7 +18,7 @@ Chef Infra Client's Compliance Phase lets you automatically execute compliance a 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 is set up--or [bootstrapped]({{< relref "install_bootstrap" >}})--for a `chef-client` run. +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** @@ -176,7 +176,7 @@ The following examples: ### Reporters -Reporters control what is 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 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: @@ -303,7 +303,7 @@ There are two primary ways to pass Chef Infra node data to Chef InSpec run durin ##### 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 is 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. +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: @@ -322,7 +322,7 @@ environment = attribute('environment', description: 'The Chef Infra environment control 'debug-disabled-in-production' do title 'Debug logs disabled in production' - desc 'Debug logs contain potentially sensitive information and should not be on 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 @@ -337,7 +337,7 @@ end 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 is 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. +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: @@ -482,7 +482,7 @@ default['audit']['quiet'] = false ### reporter -Controls what is 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' +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 @@ -500,7 +500,7 @@ 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 (does not send backtrace). Example: +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 @@ -509,7 +509,7 @@ 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 cannot ingest reports exceeding this limitation. Chef InSpec will append this text at the end of any truncated messages: `[Truncated to 10000 characters]` Default: 10000. +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 @@ -557,7 +557,7 @@ 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 will not 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, 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: @@ -652,7 +652,7 @@ The 413 "Request Entity Too Large" error appears in both the stacktrace and the ## 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 does not become available in Chef Automate and this error is in the `logstash` logs: +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 diff --git a/content/chef_deprecations_client.md b/content/chef_deprecations_client.md index 2f26564894..151329fbfa 100644 --- a/content/chef_deprecations_client.md +++ b/content/chef_deprecations_client.md @@ -22,7 +22,7 @@ the change and how to fix it. For example: ```ruby Deprecated features used! - JSON auto inflation is not supported (CHEF-1) at (irb):7:in `irb_binding`. + 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. ``` @@ -44,9 +44,9 @@ deprecation errors are issued. Deprecation warnings are great for ensuring cookbooks are kept up-to-date and to prepare for major version upgrades, sometimes you just -cannot fix a deprecation right away. Enabling +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 does not distinguish +tests often compounds the problem because it doesn't distinguish between deprecations from community cookbooks and those in your own code. @@ -83,7 +83,7 @@ provisioner: - recipes/install.rb:22 ``` -You can also silence deprecations using a comment on the line that is +You can also silence deprecations using a comment on the line that's raising the warning: ```ruby @@ -120,13 +120,13 @@ of Chef comes out. CHEF-1 -Consumers of JSON are now required to be explicit in how it is turned in to a Chef object. +Consumers of JSON are now required to be explicit in how it's turned in to a Chef object. 12.7 13.0 CHEF-2 -Chef's exit codes are now defined so that it is easy to understand why Chef exited. +Chef's exit codes are now defined so that it's easy to understand why Chef exited. 12.11 13.0 @@ -174,7 +174,7 @@ of Chef comes out. CHEF-10 -DNF package provider and resource do not require --allow-downgrade anymore. +DNF package provider and resource don't require --allow-downgrade anymore. 12.18 13.0 @@ -246,7 +246,7 @@ of Chef comes out. CHEF-25 -Resource(s) in a cookbook collide with the same resource(s) now included in Chef Infra Client. +Resources in a cookbook collide with the same resources now included in Chef Infra Client. XX.X 15.0 diff --git a/content/chef_install_script.md b/content/chef_install_script.md index 55b60d8bc7..e9c73092b3 100644 --- a/content/chef_install_script.md +++ b/content/chef_install_script.md @@ -140,14 +140,14 @@ In addition to the default install behavior, the Chef Software install script su : The directory into which a package is downloaded. When a package already exists in this directory and the checksum matches, the - package is not re-downloaded. When `-d` and `-f` are not specified, + 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 is not re-downloaded. When `-d` and `-f` are + 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) diff --git a/content/chef_repo.md b/content/chef_repo.md index 305a891fd4..5d99e2a967 100644 --- a/content/chef_repo.md +++ b/content/chef_repo.md @@ -16,7 +16,7 @@ aliases = ["/chef_repo.html"] ## 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 is packaged as part of Chef Workstation to create a 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 @@ -24,7 +24,7 @@ chef generate repo REPO_NAME {{< note >}} -`chef generate repo` generates a chef-repo that is configured for Policyfiles by default. To create a repository that is setup for Roles and Environments use the `--roles` flag when running the command. +`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 >}} diff --git a/content/chef_search.md b/content/chef_search.md index 5718fd336d..f6bbfc3381 100644 --- a/content/chef_search.md +++ b/content/chef_search.md @@ -43,7 +43,7 @@ following search indexes are built: DATA_BAG_NAME -A data bag is a global variable that is 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, "*:*"). +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 @@ -51,7 +51,7 @@ following search indexes are built: node -A node is any server or virtual server that is configured to be maintained by a Chef Infra Client. +A node is any server or virtual server that's configured to be maintained by a Chef Infra Client. role @@ -203,12 +203,12 @@ 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 is part of an expanded run-list. +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 will not affect `roles` until the next Chef Infra Client run +a run-list won't affect `roles` until the next Chef Infra Client run on the node. {{< /note >}} @@ -287,7 +287,7 @@ recipe is included by a role. {{< note >}} The `recipes` field is with each Chef Infra Client run; changes to a -run-list will not affect `recipes` until the next Chef Infra Client run +run-list won't affect `recipes` until the next Chef Infra Client run on the node. {{< /note >}} @@ -320,7 +320,7 @@ on the node. -If you just want to use each result of the search and do not care about +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: @@ -339,7 +339,7 @@ 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 is not fully defined (or implemented), it may be +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. @@ -359,7 +359,7 @@ following knife query to view information about the node: knife search node "name:name_of_database_server" --long ``` -To access these settings as part of a recipe that is run on the web +To access these settings as part of a recipe that's run on the web server, use code similar to: ```ruby diff --git a/content/chef_solo.md b/content/chef_solo.md index fab211b458..7965c4d535 100644 --- a/content/chef_solo.md +++ b/content/chef_solo.md @@ -61,7 +61,7 @@ configuration file. ## Attributes -chef-solo does not interact with the Chef Infra Server. Consequently, +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. diff --git a/content/community_contributions.md b/content/community_contributions.md index f8ad24a18b..336b78b609 100644 --- a/content/community_contributions.md +++ b/content/community_contributions.md @@ -19,7 +19,7 @@ We're glad you want to contribute to a Chef project! This guide will help answer Not every contribution comes in the form of code. Submitting, confirming, and triaging issues is an important task for any project. At Chef we use GitHub to track all project issues. -If you are familiar with Chef projects and know the component that is causing you a problem, you can file an issue in the corresponding GitHub project. All of our Open Source Software can be found in our GitHub organizations. All projects include GitHub issue templates to help gather information needed for a thorough review. The Chef GitHub organizations are: +If you are familiar with Chef projects and know the component that's causing you a problem, you can file an issue in the corresponding GitHub project. All of our Open Source Software can be found in our GitHub organizations. All projects include GitHub issue templates to help gather information needed for a thorough review. The Chef GitHub organizations are: * [https://github.com/chef](https://github.com/chef) * [https://github.com/inspec](https://github.com/inspec) @@ -43,13 +43,13 @@ If you require a response from Chef for each the terms of a support level agreem {{< note >}} -Questions on how to use Chef Infra should be sent as Support Tickets if you have an SLA, or asked on the [Chef Software Mailing List](https://discourse.chef.io/), or [Chef Community Slack](https://community-slack.chef.io/). Bug Trackers are not appropriate for general purpose questions that are not bugs. +Questions on how to use Chef Infra should be sent as Support Tickets if you have an SLA, or asked on the [Chef Software Mailing List](https://discourse.chef.io/), or [Chef Community Slack](https://community-slack.chef.io/). Bug Trackers aren't appropriate for general purpose questions that aren't bugs. {{< /note >}} ## Contribution Process -We have a 4 step process for contributions: +Follow these steps to submit a contribution: 1. Fork the project repository to your own GitHub account. 2. Commit your changes to your fork, making sure to sign-off those changes for the Developer Certificate of Origin with `git commit -s` @@ -74,14 +74,14 @@ It requires you to: * include a copy of the license in any redistribution you may make that includes Chef software; * provide clear attribution to Chef for any distributions that include Chef software; attribution can be done in the NOTICE file for an application, by adding yourself as an author/copyright holder to the HEADER for an individual file, and by placing text in a header file saying that new work is based on previous work -* reuse work as long as the licensing terms of the reused work remains unchanged (that is, the Apache License Version 2 also applies to the reused work) +* reuse work as long as the licensing terms of the reused work remains unchanged (that's, the Apache License Version 2 also applies to the reused work) -It does not require you to: +It doesn't require you to: * include the source of the Chef software itself, or of any modifications you may have made to it, in any redistribution you may assemble that includes it; * submit changes that you make to the software back to Chef (though such feedback is encouraged). -It is our goal to run a successful, truly open source business. To that end, we are protecting our own rights by making them explicit in our choice of licensing: you have the same rights to our open source software that we do. +It's our goal to run a successful, truly open source business. To that end, we're protecting our own rights by making them explicit in our choice of licensing: you have the same rights to our open source software that we do. ## Developer Certification of Origin (DCO) @@ -107,22 +107,22 @@ By making a contribution to this project, I certify that: Indicated in the file; or (c) The contribution was provided directly to me by some other - person who certified (a), (b) or (c) and I have not modified + person who certified (a), (b) or (c) and I haven't modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed - consistent with this project or the open source license(s) + consistent with this project or the open source licenses involved. ``` -Chef does not merge any pull requests made against a Chef-managed open source repository until each commit has been signed for the DCO, with three exceptions: +Chef doesn't merge any pull requests made against a Chef-managed open source repository until each commit has been signed for the DCO, with three exceptions: * "Obvious Fixes" (as described below) * Pull requests made against the docs.chef.io documentation repository () -* Pull requests that contain only documentation updates made against projects where the documentation is embedded in the project's repository (that is, the `docs` directory in the `chef/inspec` repository) +* Pull requests that contain only documentation updates made against projects where the documentation is embedded in the project's repository (that's, the `docs` directory in the `chef/inspec` repository) ## The "Obvious Fix" Rule @@ -130,7 +130,7 @@ Chef's contribution policy is aimed at encouraging broad participation from our As a general standard, Chef requires every contribution to by signed for the Developer Certificate of Origin (DCO). -HOWEVER, small contributions such as fixing spelling errors, where the content is small enough to not be considered intellectual property, can be submitted by a contributor as a patch, without a DCO sign-off. If you submit an obvious fix without a DCO sign-off, then you are agreeing that your submission is not independently copyrightable. The purpose of this exception is to lower the barrier for new contributors to make contributions while retaining the integrity of the project and our community. +HOWEVER, small contributions such as fixing spelling errors, where the content is small enough to not be considered intellectual property, can be submitted by a contributor as a patch, without a DCO sign-off. If you submit an obvious fix without a DCO sign-off, then you are agreeing that your submission isn't independently copyrightable. The purpose of this exception is to lower the barrier for new contributors to make contributions while retaining the integrity of the project and our community. ### How does the Obvious Fix Rule Work? @@ -153,9 +153,9 @@ Date: Wed Sep 18 11:44:40 2015 -0700 ### What qualifies as an Obvious Fix? -An obvious fix is a pull request that does not contain creative work. We rely on your judgment to determine what is "obvious"; if you're not sure, just ask by sending an email to: oss AT getchef DOT com. +An obvious fix is a pull request that doesn't contain creative work. We rely on your judgment to determine what's "obvious"; if you're not sure, just ask by sending an email to: oss AT getchef DOT com. -As a rule of thumb, changes are obvious fixes if they do not introduce any new functionality or creative thinking. As long as the change does not affect functionality, some likely examples include the following: +As a rule of thumb, changes are obvious fixes if they don't introduce any new functionality or creative thinking. As long as the change doesn't affect functionality, some likely examples include the following: * Spelling/grammar fixes; * Correcting typos; diff --git a/content/community_guidelines.md b/content/community_guidelines.md index 2c22e2fb60..c00f0175ad 100644 --- a/content/community_guidelines.md +++ b/content/community_guidelines.md @@ -39,7 +39,7 @@ Community members may fulfill many roles including mentoring, teaching, and connecting with other members of the community. Be careful in the words that you choose. Be kind to others. Practice -empathy. do not insult or put down others. Remember that sexist, racist, +empathy. Don't insult or put down others. Remember that sexist, racist, ableist, ageist, and other exclusionary jokes can be offensive to those around you. If you think your conversation is making another community member uncomfortable *or* if they tell you so, stop immediately, make @@ -50,18 +50,18 @@ mind that the following guidelines apply equally to founders, mentors, those who submit new features/pull requests, and anyone who is seeking help and guidance. -The following list is not exhaustive, but these few examples can help all +The following list isn't exhaustive, but these few examples can help all of us communicate well, so that the community can work better together: - Use welcoming and inclusive language - Exercise patience and friendliness - Be respectful of differing viewpoints and experiences - Gracefully accept constructive criticism -- Focus on what is best for the community +- Focus on what's best for the community - Show empathy towards other community members The previous list applies to all forms of communication: Slack (or any -web chat), Discourse, the issue tracker, and any other forum that is +web chat), Discourse, the issue tracker, and any other forum that's used by the community. Please keep in mind that: @@ -69,7 +69,7 @@ Please keep in mind that: - Your work will be used by other people, and you, in turn, will depend on the work of others. - Decisions that you make often will affect others in the community. -- Disagreements happen, but should not be an excuse for poor behavior +- Disagreements happen, but shouldn't be an excuse for poor behavior and bad manners. When disagreements do happen, let's work together to solve them effectively and in a way that ensures that everyone understands what the disagreements were. @@ -78,11 +78,11 @@ Please keep in mind that: and oblique references in the same way that you do. Remember that and be kind to the other members of the community. - Be cautious about making assumptions about what someone does or does - not know about something - assuming that someone does not understand + not know about something - assuming that someone doesn't understand an issue and over explaining can be condescending (even when not intended to be so). - Sexist, racist, ableist, ageist, and other prejudicial or - exclusionary comments are not welcome in the community. + exclusionary comments aren't welcome in the community. ## Unacceptable Behavior @@ -113,7 +113,7 @@ Conduct](https://www.chef.io/code-of-conduct/physical-spaces/). If you have any lack of clarity about behaviors we include in the definition of "harassment", please read the [Citizen Code of -Conduct](http://citizencodeofconduct.org/). In particular, we do not +Conduct](http://citizencodeofconduct.org/). In particular, we don't tolerate behavior that excludes people in socially marginalized groups. ## Enforcement/Getting Help @@ -121,65 +121,18 @@ tolerate behavior that excludes people in socially marginalized groups. Instances of abusive, harassing, or otherwise unacceptable behavior should be reported by contacting any of the Community Advocates directly. Each person's contact information and role is listed in the -repo that links to this document. If you were not linked here, then +repo that links to this document. If you weren't linked here, then contact the [individuals listed below](#roles). All complaints will be -reviewed, investigated, and will result in a response that is deemed +reviewed, investigated, and will result in a response that's deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. -Community Organizers who do not follow or enforce the Code of Conduct in +Community Organizers who don't follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. -## Roles - -The following are the various roles of our **Community Organizers** and -the person(s) assigned to each role: - -- The **Deciders** have final say on community guidelines and final - authority on correct actions and appeals. -- The **Community Advocates** may be assigned for each area where the - community convenes online (Slack, email list, GitHub, etc.). - Community Advocates are volunteers who have the best interests of - our community in mind. They act in good faith to help enforce our - community guidelines and respond to incidents when they occur. -- The **Project Maintainers** are expected to conduct their behavior - in line with the Code of Conduct and are individually responsible - for both escalating to a **Community Advocate** in case of - witnessing an incident, and helping to foster the community. -- A **Community Member** is anyone who participates with the community - whether in-person or using online channels. Community members are - responsible for following the community guidelines, suggesting - updates to the guidelines when warranted, and helping enforce - community guidelines. - - - - ----- - - - - - - - - - - - - - - -
RoleNameContact Info
Community Advocatebenny Vasquezbenny.vasquez@progress.com
- - ## Consequences of Unacceptable Behavior Unacceptable behavior from any community member, including sponsors and @@ -199,7 +152,7 @@ in the same manner as internal incidents. Any physical violence *or* intimidation, threatened or acted on, is a serious offense and will result in immediate exclusion from the -community and appropriate follow up with law enforcement. No, we are not +community and appropriate follow up with law enforcement. No, we're not kidding. ## Procedure for Handling Disagreements and Incidents @@ -221,7 +174,7 @@ Community Advocates listed in the [Roles](#roles) section. Conduct](https://www.chef.io/code-of-conduct/physical-spaces/). When a Community Organizer or Project Maintainer notices someone -behaving in a way that is outside of our guidelines (a violator), the +behaving in a way that's outside of our guidelines (a violator), the Community Advocate should make every reasonable attempt to help curtail that behavior. The Community Advocate may: @@ -233,7 +186,7 @@ that behavior. The Community Advocate may: - Allow time for the violator to correct the behavior. The Community Advocate should take the following steps if the behavior -is not brought in-line with our guidelines or the incident is not +isn't brought in-line with our guidelines or the incident isn't resolved: - Consult with another Community Organizer to make a judgment call @@ -247,7 +200,7 @@ resolved: #### Documenting Incidents -All incident reports will be kept in a private repository that is shared +All incident reports will be kept in a private repository that's shared with the aforementioned Community Advocates and Deciders under the [Roles](#roles) section. No other individuals or project contributors will be given access to these incident reports. **This repo will hold no @@ -267,7 +220,7 @@ The important information to report consists of: log, GitHub Issue, etc.). - Contact information for witnesses to the incident. -If you feel your safety is in jeopardy, please do not hesitate to +If you feel your safety is in jeopardy, please don't hesitate to contact local law enforcement. **Note:** Incidents that violate the Community Code of Conduct are @@ -283,7 +236,7 @@ corrective action in response to any instances of unacceptable behavior. Community Organizers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, messages, tweets, -and other contributions that are not aligned with this Code of Conduct, +and other contributions that aren't aligned with this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. diff --git a/content/config_rb_client.md b/content/config_rb_client.md index a41c5ea0a0..8c45b0407b 100644 --- a/content/config_rb_client.md +++ b/content/config_rb_client.md @@ -485,7 +485,7 @@ This configuration file has the following settings: Default value: `false` `splay` -: A random number between zero and `splay` that is 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 the Chef Infra Server by ensuring that many Chef Infra Client runs aren't occurring at the same interval. Default value: `nil`. diff --git a/content/config_rb_manage.md b/content/config_rb_manage.md index c907c4c8ed..f5c8bf54b0 100644 --- a/content/config_rb_manage.md +++ b/content/config_rb_manage.md @@ -104,7 +104,7 @@ This configuration file has the following settings: `recaptcha.fail_open` -: If the reCAPTCHA service cannot be reached, allow to sign-up? Default value: `true`. +: If the reCAPTCHA service can't be reached, allow to sign-up? Default value: `true`. `recaptcha.verify_url` @@ -154,11 +154,11 @@ This configuration file has the following settings: `session_timeout` -: The amount of time (in minutes) of inactivity before a user is logged out. When not set (or set to 0), a browser session will not have a timed expiration and will expire when the browser session ends, quits, or when the computer restarts, or when the absolute session time limit is hit (see `session_timeout_absolute`). Default value: `1440` (one day). +: The amount of time (in minutes) of inactivity before a user is logged out. When not set (or set to 0), a browser session won't have a timed expiration and will expire when the browser session ends, quits, or when the computer restarts, or when the absolute session time limit is hit (see `session_timeout_absolute`). Default value: `1440` (one day). `session_timeout_absolute` -: The amount of time (in minutes) after which a user will be logged out, regardless of activity. When not set (or set to 0), a browser session will not have a timed expiration unless a session is inactive longer than the session time limit (see `session_timeout`). Default value: `10080` (one week). +: The amount of time (in minutes) after which a user will be logged out, regardless of activity. When not set (or set to 0), a browser session won't have a timed expiration unless a session is inactive longer than the session time limit (see `session_timeout`). Default value: `10080` (one week). `sign_in_page_message` @@ -209,7 +209,7 @@ when connecting to the Infra Server. Most common setting: `"/etc/chef/trusted_ce `webapp.worker_timeout` -: The amount of time (in seconds) that a worker can be silent before it is killed and restarted. Default value: `3600`. +: The amount of time (in seconds) that a worker can be silent before it's killed and restarted. Default value: `3600`. ## Web UI Private Key diff --git a/content/config_rb_solo.md b/content/config_rb_solo.md index c23f8c34a3..ada58adcc2 100644 --- a/content/config_rb_solo.md +++ b/content/config_rb_solo.md @@ -19,7 +19,7 @@ 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 is not created by default +- 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 @@ -56,7 +56,7 @@ This configuration file has the following settings: `file_cache_path` -: The location in which cookbooks (and other transient data) files are stored when they are synchronized. This value can also be used in recipes to download files with the **remote_file** resource. +: 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` @@ -64,7 +64,7 @@ This configuration file has the following settings: `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 should not on an NF mount. Default value: a location defined by `file_cache_path`. +: 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` @@ -96,7 +96,7 @@ This configuration file has the following settings: `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 will not start when a lock file is present. If a lock file is not 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. +: 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` diff --git a/content/cookbook_repo.md b/content/cookbook_repo.md index 8dd01cf201..c8632feaee 100644 --- a/content/cookbook_repo.md +++ b/content/cookbook_repo.md @@ -120,7 +120,7 @@ that: ### Download -To download a cookbook when git is not used for version source control, +To download a cookbook when git isn't used for version source control, run the following command: ```bash diff --git a/content/cookbook_versioning.md b/content/cookbook_versioning.md index 2dc4672da1..329428525e 100644 --- a/content/cookbook_versioning.md +++ b/content/cookbook_versioning.md @@ -21,7 +21,7 @@ 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) are not allowed. +three parts (1.2.3.4) aren't allowed. ## Constraints @@ -34,9 +34,9 @@ operator cookbook_version_syntax {{< note >}} -Single digit cookbook versions are not allowed. Cookbook versions must +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`; do not use `1`. +`1.0.1`; don't use `1`. {{< /note >}} @@ -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 is 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 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'
@@ -132,7 +132,7 @@ not provided, `>= 0.0.0` is used as the default. provides -Add a recipe, definition, or resource that is provided by this cookbook, should the populated list be insufficient. +Add a recipe, definition, or resource that's provided by this cookbook, should the populated list be insufficient. supports @@ -157,7 +157,7 @@ Or: cookbook 'runit', '= 4.2.0' ``` -If a cookbook is not explicitly given a version constraint the +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. @@ -213,7 +213,7 @@ There are three solutions to this problem: 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 is not to increase their timeout, but to control the problem so that the dependency solvers can solve it in a reasonable amount of time. +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 @@ -236,7 +236,7 @@ You can make a start at this by only uploading tested and blessed cookbook versi There are two strategies to consider when using version control as part of the cookbook management process: -- Use maximum version control when it is important to keep every bit of data within version control +- 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 diff --git a/content/cookbooks.md b/content/cookbooks.md index 8d363d294e..41f95db546 100644 --- a/content/cookbooks.md +++ b/content/cookbooks.md @@ -21,7 +21,7 @@ product = ["client", "server", "workstation"] {{< 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 will not change anything. +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 diff --git a/content/ctl_chef_client.md b/content/ctl_chef_client.md index 4400b4633a..45fce5f883 100644 --- a/content/ctl_chef_client.md +++ b/content/ctl_chef_client.md @@ -42,7 +42,7 @@ This command has the following options: `-A`, `--fatal-windows-admin-check` -: Cause a Chef Infra Client run to fail when the Chef Infra Client does not have administrator privileges in Windows. +: Cause a Chef Infra Client run to fail when the Chef Infra Client doesn't have administrator privileges in Windows. `-c CONFIG`, `--config CONFIG` @@ -62,7 +62,7 @@ This command has the following options: `--chef-zero-port PORT` -: The port on which chef-zero listens. If a port is not 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 is available. +: 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` @@ -84,7 +84,7 @@ This command has the following options: `-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 does not 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`. +: 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` @@ -157,7 +157,7 @@ This command has the following options: **Specify a policy** - Use this option to use policy files by specifying a JSON file that + Use this option to use Policyfiles by specifying a JSON file that contains the following settings: @@ -209,7 +209,7 @@ This command has the following options: : 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 is not available). + a terminal isn't available). `-L LOGLOCATION`, `--logfile LOGLOCATION` @@ -248,7 +248,7 @@ This command has the following options: `-n NAME`, `--named-run-list NAME` -: The run-list associated with a policy file. +: The run-list associated with a Policyfile. `-N NODE_NAME`, `--node-name NODE_NAME` @@ -257,8 +257,8 @@ This command has the following options: `-o RUN_LIST_ITEM`, `--override-runlist RUN_LIST_ITEM` : Replace the current run-list with the specified items. This option - will not clear the list of cookbooks (and related files) that is - cached on the node. This option will not persist node data at the + 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` @@ -315,9 +315,9 @@ This command has the following options: `-s SECONDS`, `--splay SECONDS` -: A random number between zero and `splay` that is added to +: 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 are not + 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. @@ -377,10 +377,10 @@ 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 does not require a configuration file, instead it will look +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 is not found and no +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. @@ -394,7 +394,7 @@ access. 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 do not actually do anything until it is done +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 @@ -406,14 +406,14 @@ 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 does not include mapping each resource to a provider or +collection, but doesn't include mapping each resource to a provider or configuring any part of the system. {{< note >}} -why-run mode is not a replacement for running cookbooks in a test +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 is going on, but also Kitchen on developer +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. @@ -422,13 +422,13 @@ providers for more thorough testing. When Chef Infra Client is run in why-run mode, certain assumptions are made: -- If the **service** resource cannot find the appropriate command to +- 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 - are not designed to be used to change the state of the system, but + 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 @@ -439,13 +439,13 @@ made: 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 is not running -and do nothing if it is running. If a service is installed from a -package, then Chef Infra Client cannot check to see if the service is +the action is `:start`, then the service will start if it's not running +and don'thing 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 is +actions often trigger notifications to other resources, so it's important to know that these notifications are triggered correctly. ### About chef-zero @@ -454,7 +454,7 @@ 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 is enabled from within the +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 @@ -462,9 +462,9 @@ the actual Chef Infra Server. {{< note >}} -chef-zero does not save data between restarts. Because it is intended to -be used locally, chef-zero does not perform input validation, -authentication, or authorization, as these security measures are not +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. @@ -526,7 +526,7 @@ be used: : Use to wake up sleeping Chef Infra Client and trigger node convergence. -On Windows, both the `HUP` and `QUIT` signals are not +On Windows, both the `HUP` and `QUIT` signals aren't supported. ## Run with Elevated Privileges @@ -570,7 +570,7 @@ ways this can be done: - 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, is not a recommended approach + as such, isn't a recommended approach ### Windows @@ -587,27 +587,27 @@ 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 is +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 is, "run as a user with +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 does not also require elevated privileges (such as sudo or +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 is unable to create or modify users, the -**user** resource will not work. +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 is running the Chef Infra Client. For example: +the user that's running the Chef Infra Client. For example: ```ruby file_cache_path '~/.chef/cache' @@ -631,7 +631,7 @@ When running the Chef Infra Client using the `--local-mode` option, 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`, `stop_command`, and so on), +`_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. @@ -684,12 +684,12 @@ run as a root user: 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 will not be able to create +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 have not already been increased. +1. Validate that the system process limits haven't already been increased. -2. If they have not been increased, run the following commands as a root user: +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" @@ -735,7 +735,7 @@ 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 does not include the EN_US (UTF-8) +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 @@ -822,19 +822,19 @@ platform: - + - +
Chef::Provider::Service::Aix serviceThe provider that is used with the AIX platforms. Use the service short name to start, stop, and restart services with System Resource Controller (SRC).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 serviceThe provider that is used to manage BSD-based init services on AIX.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 does not support using the `:enable` and +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 @@ -889,7 +889,7 @@ sudo chef-client **Start a run when the Chef Infra Client is running as a daemon** -A Chef Infra Client that is running as a daemon can be woken up and +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: diff --git a/content/ctl_chef_solo.md b/content/ctl_chef_solo.md index 3e186b0ab8..03343867d2 100644 --- a/content/ctl_chef_solo.md +++ b/content/ctl_chef_solo.md @@ -40,7 +40,7 @@ This command has the following options: `-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 does not 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. +: 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` @@ -80,7 +80,7 @@ This command has the following options: `-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 is not available). +: 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` @@ -88,7 +88,7 @@ This command has the following options: `--legacy-mode` -: Cause Chef Infra Client to use the original chef-solo mode instead of chef local mode. This is not recommended. **Removed in Chef Infra Client 14.** +: 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` @@ -118,7 +118,7 @@ This command has the following options: `-s SECONDS`, `--splay SECONDS` -: A random number between zero and `splay` that is added to `interval`. Use splay to help balance the load on the Chef Infra Server by ensuring that many Chef Infra Client runs are not 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 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` diff --git a/content/ctl_manage.md b/content/ctl_manage.md index e2be7a7a0e..4e9cdbced6 100644 --- a/content/ctl_manage.md +++ b/content/ctl_manage.md @@ -48,7 +48,7 @@ chef-manage-ctl help The `reconfigure` subcommand is used when changes are made to the manage.rb file to reconfigure the server. When changes are made to the -manage.rb file, they will not be applied to the Chef management console +manage.rb file, they won't be applied to the Chef management console configuration until after this command is run. This subcommand has the following syntax: @@ -73,7 +73,7 @@ chef-manage-ctl show-config ## uninstall The `uninstall` subcommand is used to manage the hooks between runit and -`sysvinit` or `upstart`. This subcommand does not [uninstall the Chef +`sysvinit` or `upstart`. This subcommand doesn't [uninstall the Chef management console](/uninstall/#chef-manage) or remove `.rpm` or `.deb` files. diff --git a/content/ctl_ohai.md b/content/ctl_ohai.md index 7457cf03bb..2d17413ebc 100644 --- a/content/ctl_ohai.md +++ b/content/ctl_ohai.md @@ -14,7 +14,7 @@ aliases = ["/ctl_ohai.html"] weight = 20 +++ -`ohai` is the command-line interface for Ohai, a tool that is used to +`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. diff --git a/content/custom_resource_glossary.md b/content/custom_resource_glossary.md index d3cd349f0e..dcd557a920 100644 --- a/content/custom_resource_glossary.md +++ b/content/custom_resource_glossary.md @@ -524,7 +524,7 @@ 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 is not named the same as the resource you want to provide +# 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 ``` diff --git a/content/custom_resources_notes.md b/content/custom_resources_notes.md index 8f86846141..1ddf186efd 100644 --- a/content/custom_resources_notes.md +++ b/content/custom_resources_notes.md @@ -27,7 +27,7 @@ This page mentions multiple ways of building custom resources. Chef Software rec 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 cannot subclass, and must use mixins for code-sharing (which is really a best practice anyway -- for example, see languages like rust which do not support sub-classing). +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`: @@ -57,7 +57,7 @@ end ## "Old school" LWRPS -This method is not recommended, but is preferable to writing library resources/providers (as described below). It has the same functionality as library providers, only you cannot subclass and must use mixins for code sharing (which is good). +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`: @@ -92,16 +92,16 @@ 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 did not have to be prefixed by the cookbook name. +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 is not. Chef internal resources do not inherit from `LWRPBase` and we have had to manually create resources directly through `Chef::Resource::File.new()`, we also have not been able to `use_inline_resources` and not had access to other niceties that cookbook authors have had access to for years now. We have 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. +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 is important to inherit from LWRPBase + class MyResource < Chef::Resource::LWRPBase # it's important to inherit from LWRPBase resource_name :my_resource provides :my_resource @@ -117,7 +117,7 @@ in `libraries/resource_my_resource.rb`: ```ruby class MyBaseClass class Resource - class MyProvider < Chef::Provider::LWRPBase # it is important to inherit from LWRPBase + class MyProvider < Chef::Provider::LWRPBase # it's important to inherit from LWRPBase # you have to worry about this def whyrun_supported? true @@ -129,8 +129,8 @@ class MyBaseClass end # NEVER use `def action_run` here -- you defeat use_inline_resources and will break notifications if you do - # If you do not 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 is not used and/or is broken, then you should really not be using library providers+resources. You might feel "closer to the metal", + # 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() @@ -176,7 +176,7 @@ action :run do end ``` -That is 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. +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. @@ -196,9 +196,9 @@ action :run do end ``` -When the `converge_by` block is run in why-run mode, it will only log `touch "/tmp/foo"` and will not run the code inside the block. +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 is not 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. +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 @@ -212,7 +212,7 @@ action :run do end ``` -Of course it is simpler to just use Chef Infra Client resources when you can. Compare the equivalent implementations: +Of course it's simpler to just use Chef Infra Client resources when you can. Compare the equivalent implementations: ```ruby action :run do diff --git a/content/debug.md b/content/debug.md index ca68bba7f7..26943969dc 100644 --- a/content/debug.md +++ b/content/debug.md @@ -36,7 +36,7 @@ Some simple ways to identify common issues that can trigger recipe and/or Chef I ### Knife -Use the verbose logging that is built into knife: +Use the verbose logging that's built into knife: `-V`, `--verbose` @@ -44,17 +44,17 @@ Use the verbose logging that is built into knife: {{< note >}} -Plugins do not always support verbose logging. +Plugins don't always support verbose logging. {{< /note >}} ### Chef Infra Client -Use the verbose logging that is built into 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 is not available). +: 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` @@ -65,7 +65,7 @@ Use the verbose logging that is built into Chef Infra Client: 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 is not built into the resource collection, use +create a log entry that isn't built into the resource collection, use `Chef::Log` instead of the **log** resource.) {{< note >}} @@ -134,7 +134,7 @@ 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 location(s) from which attribute values are being set +* 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 @@ -177,7 +177,7 @@ 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 are removed from those recipes before the parent +after which they're removed from those recipes before the parent cookbook is uploaded to the Chef Infra Server. #### Syntax @@ -209,7 +209,7 @@ The breakpoint resource has the following actions: #### Attributes -This resource does not have any properties. +This resource doesn't have any properties. #### Examples @@ -332,12 +332,12 @@ 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 is set for that precedence level +* 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 +### ignore_failure method -All resources share a set of common actions, attributes, and so on. Use the following attribute in a resource to help identify where an issue within a recipe may be located: +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 | |----------------|---------------------------------------------------------------------------------------| diff --git a/content/definitions_to_custom_resources.md b/content/definitions_to_custom_resources.md index e1e56ffbd1..5888eac0aa 100644 --- a/content/definitions_to_custom_resources.md +++ b/content/definitions_to_custom_resources.md @@ -26,17 +26,17 @@ Though a definition looks like a resource, and at first glance seems like it cou Definitions: -- Are not true resources +- Aren't true resources - Are processed when resource collection is compiled, not when a node is converged -- Do not support common resource properties, such as `notifies`, `compile_time`, +- Don't support common resource properties, such as `notifies`, `compile_time`, `subscribes`, `only_if`, `not_if`, and `sensitive` -- Do not support input validation in passed arguments, unlike a +- Don't support input validation in passed arguments, unlike a resource which supports validation with properties -- Do not support `why-run` mode -- Cannot report to Chef Automate -- Cannot be tested with ChefSpec -- Some Definition parameters have known bugs, and will not be fixed +- 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 @@ -44,7 +44,7 @@ A definition had four components: - A resource name - Zero or more arguments that define parameters and their default values; - if a default value was not specified, it was assumed to be `nil` + 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 @@ -157,7 +157,7 @@ action :create do end ``` -Once written, a custom resource may be used in a recipe just like any resource that is 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: +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 diff --git a/content/deprecations_attributes.md b/content/deprecations_attributes.md index 81b889ee07..8084627279 100644 --- a/content/deprecations_attributes.md +++ b/content/deprecations_attributes.md @@ -10,7 +10,7 @@ aliases = "/deprecations_attributes.html" +++ -We are continuously improving and streamlining the way attributes work +We're continuously improving and streamlining the way attributes work in Chef, to make it easier for users to reason about and safely configure their servers. diff --git a/content/deprecations_chef_gem_compile_time.md b/content/deprecations_chef_gem_compile_time.md index b28e530312..48f070202a 100644 --- a/content/deprecations_chef_gem_compile_time.md +++ b/content/deprecations_chef_gem_compile_time.md @@ -13,7 +13,7 @@ Originally, the [chef gem](/resources/chef_gem/) resource always ran during the compile phase (see this section on [Chef Infra Client runs](/chef_client_overview/#the-chef-client-run) for further -details). It is now possible to control which phase the resource is run +details). It's now possible to control which phase the resource is run in. Calling `chef_gem` without specifying the phase is now deprecated. This deprecation warning was added in Chef Infra Client 12.1.0, and using diff --git a/content/deprecations_chef_platform_methods.md b/content/deprecations_chef_platform_methods.md index b04f1d5e8f..31333771b3 100644 --- a/content/deprecations_chef_platform_methods.md +++ b/content/deprecations_chef_platform_methods.md @@ -64,7 +64,7 @@ provides :mysql_service, platform: "fedora", platform_version: ">= 19" ``` This can also be directly sent to the provider class in library code, -although this form is less encouraged (which does not mean the same +although this form is less encouraged (which doesn't mean the same thing as discouraged -- but you gain better code organization with the prior code): @@ -80,12 +80,12 @@ is supported back to Chef Infra Client 12.0, although some more advanced forms of the `provides` syntax were only introduced in Chef Infra Client 12.5.1. Also you may have found this web page due to deprecation of -library-based resources and providers that do not declare provides in +library-based resources and providers that don't declare provides in which case your Chef Infra Client run is likely full of a compilation of warnings and deprecations: ```plain -* foo[it] action doit[2016-12-07T14:28:59-08:00] WARN: Class Chef::Provider::Foo does not declare 'provides :foo'. +* foo[it] action doit[2016-12-07T14:28:59-08:00] WARN: Class Chef::Provider::Foo doesn't declare 'provides :foo'. [2016-12-07T14:28:59-08:00] WARN: This will no longer work in Chef Infra Client 13: you must use 'provides' to use the resource's DSL. (up to date) @@ -105,7 +105,7 @@ Class.find is deprecated at 1 location: ``` In this case, the initial warning that -`Class Chef::Provider::Foo does not declare 'provides :foo'` is accurate +`Class Chef::Provider::Foo doesn't declare 'provides :foo'` is accurate and gives the remediation. Code that looks like this: diff --git a/content/deprecations_custom_resource_cleanups.md b/content/deprecations_custom_resource_cleanups.md index 65ed49b48a..c8a06a66c0 100644 --- a/content/deprecations_custom_resource_cleanups.md +++ b/content/deprecations_custom_resource_cleanups.md @@ -9,7 +9,7 @@ aliases = "/deprecations_custom_resource_cleanups.html" +++ -We are continuously improving and streamlining the way custom resources +We're continuously improving and streamlining the way custom resources work in Chef, to make it easier for cookbook authors and Chef developers to build resources. @@ -20,14 +20,14 @@ releases. In current versions of Chef, `nil` was often used to mean that a property had no good default, and needed to be set by the user. However, -it is often to useful to set a property to `nil`, meaning that it is not -set and should be ignored. In Chef Infra Client 13, it is an error to set -`default: nil` on a property if that property does not allow `nil` as a +it's often to useful to set a property to `nil`, meaning that it's not +set and should be ignored. In Chef Infra Client 13, it's an error to set +`default: nil` on a property if that property doesn't allow `nil` as a valid value. ### Remediation -If it is valid for the property to be set to nil, then update the +If it's valid for the property to be set to nil, then update the property to include that. ```ruby @@ -39,8 +39,8 @@ Otherwise, remove the `default: nil` statement from the property. ## Invalid Defaults Current versions of Chef emit a warning when a property's default value -is not valid. This is often because the type of the default value -does not match the specification of the property. For example: +isn't valid. This is often because the type of the default value +doesn't match the specification of the property. For example: ```ruby property :my_property, [ String ], default: [] @@ -83,8 +83,8 @@ otherwise specified), but not both. ## Overriding provides? Some providers override the `provides?` method, used to check whether -they are a valid provider on the current platform. In Chef Infra Client 13, -this will cause an error if the provider does not also register +they're a valid provider on the current platform. In Chef Infra Client 13, +this will cause an error if the provider doesn't also register themselves with the `provides` call. ### Example @@ -105,13 +105,13 @@ def provides? end ``` -## do not use the updated method +## don't use the updated method The `updated=(true_or_false)` method is deprecated and will be removed from Chef Infra Client 13. This method never performed its intended job, as notifications from the resource would not fire, and in general its use has always been buggy. The Chef Infra Client notification code checks -`updated_by_last_action?` instead, so setting that is recommended as a +`updated_by_last_action?` instead, so setting that's recommended as a substitute. See the [updated_by_last_action](/custom_resources_notes/#updated-by-last-action) documentation for more information. @@ -142,7 +142,7 @@ action :foo do end ``` -## do not use the dsl_name method +## don't use the dsl_name method The `dsl_name` method is deprecated and will be removed from Chef Infra Client. It has been replaced by `resource_name`. @@ -158,10 +158,10 @@ my_resource = MyResource.dsl_name my_resource = MyResource.resource_name ``` -## do not use the provider_base method +## don't use the provider_base method The `Resource.provider_base` allows the developer to specify an alternative module to load providers from, rather than `Chef::Provider`. -It is deprecated and will be removed in Chef Infra Client 13. Instead, the +It's deprecated and will be removed in Chef Infra Client 13. Instead, the provider should call `provides` to register itself, or the resource should call `provider` to specify the provider to use. diff --git a/content/deprecations_dnf_package_allow_downgrade.md b/content/deprecations_dnf_package_allow_downgrade.md index c618c4918b..c29c65e179 100644 --- a/content/deprecations_dnf_package_allow_downgrade.md +++ b/content/deprecations_dnf_package_allow_downgrade.md @@ -8,9 +8,9 @@ sitemapExclude = true aliases = "/deprecations_dnf_package_allow_downgrade.html" +++ -The underlying `dnf` command in Red Hat based operating systems does not +The underlying `dnf` command in Red Hat based operating systems doesn't require `--allow-downgrade` like the previous `yum` command did. This -property does not affect the `dnf_resource` resource execution and +property doesn't affect the `dnf_resource` resource execution and should be removed. ## Remediation diff --git a/content/deprecations_epic_fail.md b/content/deprecations_epic_fail.md index 91baf70d26..724dd898da 100644 --- a/content/deprecations_epic_fail.md +++ b/content/deprecations_epic_fail.md @@ -9,7 +9,7 @@ aliases = "/deprecations_epic_fail.html" +++ The original name for the `ignore_failure` property in resources was -`epic_fail`. Our documentation has not referred to `epic_fail` for years +`epic_fail`. Our documentation hasn't referred to `epic_fail` for years and out of the 3500 cookbooks on the Supermarket only one uses `epic_fail`. In Chef Infra Client 14 we will remove the `epic_fail` property entirely. diff --git a/content/deprecations_exit_code.md b/content/deprecations_exit_code.md index 97ce42b8b9..61081e56ff 100644 --- a/content/deprecations_exit_code.md +++ b/content/deprecations_exit_code.md @@ -8,7 +8,7 @@ sitemapExclude = true aliases = "/deprecations_exit_code.html" +++ -In older versions of Chef Infra Client, it was not possible to discern why a +In older versions of Chef Infra Client, it wasn't possible to discern why a chef run exited simply by examining the error code. This makes it tricky for tools such as Test Kitchen to reason about the status of a Chef Infra Client run. Starting in Chef Infra Client 12.11, there are now well @@ -23,9 +23,9 @@ them](https://github.com/chef/chef-rfc/blob/main/rfc062-exit-status.md). ## Remediation -If you have built automation that is dependent on the old behavior of +If you have built automation that's dependent on the old behavior of Chef Infra Client, we strongly recommend updating it to support the extended -set of exit codes. However, it is still possible to enable the old +set of exit codes. However, it's still possible to enable the old behavior. Add the setting ```ruby diff --git a/content/deprecations_locale_lc_all.md b/content/deprecations_locale_lc_all.md index 4eeb1e1dea..bd89ead4a4 100644 --- a/content/deprecations_locale_lc_all.md +++ b/content/deprecations_locale_lc_all.md @@ -8,7 +8,7 @@ sitemapExclude = true aliases = "/deprecations_locale_lc_all.html" +++ -Setting the `LC_ALL` variable is NOT recommended. As a system-wide +Setting the `LC_ALL` variable isn't recommended. As a system-wide setting, `LANG` should provide the desired behavior. `LC_ALL` is intended to be used for temporarily troubleshooting issues rather than an everyday system setting. Changing `LC_ALL` can break Chef's parsing diff --git a/content/deprecations_map_collision.md b/content/deprecations_map_collision.md index 12d59cdf60..e56171fe61 100644 --- a/content/deprecations_map_collision.md +++ b/content/deprecations_map_collision.md @@ -8,7 +8,7 @@ sitemapExclude = true aliases = "/deprecations_map_collision.html" +++ -The resource(s) referenced in the error message has been loaded from a +The resources referenced in the error message has been loaded from a cookbook. This resource is now included in Chef Infra Client and will take precedence over the existing cookbook resource in the next major release of Chef Infra Client (15.0, April 2019). Alternatively, there diff --git a/content/deprecations_namespace_collisions.md b/content/deprecations_namespace_collisions.md index dd823d88da..af9c6aaac3 100644 --- a/content/deprecations_namespace_collisions.md +++ b/content/deprecations_namespace_collisions.md @@ -51,10 +51,10 @@ end In some edge cases, this deprecation warning may mention that the property should be referred to as `current_resource.property_name` -instead of `new_resource.property_name`, which is not a mistake; the +instead of `new_resource.property_name`, which isn't a mistake; the user should instead use the `current_resource.property_name` to preserve prior behavior, or should modify their code to explicitly check the -`current_resource` if the `new_resource` is not set. There are several +`current_resource` if the `new_resource` isn't set. There are several possible remediations to this in the order of least complicated to the most compatible with the old behavior, and the user will need to select what works best for their use case: @@ -67,22 +67,22 @@ content_to_set = new_resource.property_is_set?(:property_name) ? new_resource.pr Unfortunately, if you were reliant upon the old code's automatic switching between the `new_resource` and `current_resource` you will -need to be explicit. Most users, however, were not aware that this was +need to be explicit. Most users, however, weren't aware that this was occurring and moving that uncommon logic explicitly into the action code -will produce more comprehensible code that is less reliant on subtle +will produce more comprehensible code that's less reliant on subtle tricks of the API. -It is also entirely possible that the access of the `current_resource` +It's also entirely possible that the access of the `current_resource` was never intended by the user. If this behavior was undesired, the correct remediation would be to simply access the property through the -`new_resource.property_name`. We cannot determine and accurately report +`new_resource.property_name`. We can't determine and accurately report to the user when this deprecation message is incorrect, we can only report on compatible behavior. The suggestion of the deprecation warning to access the property through `current_resource.property_name` may be -incorrect, and it is up to the discretion of the user to choose the +incorrect, and it's up to the discretion of the user to choose the appropriate remediation for their needs. -The fact that this is confusing behavior to explain is why it is being +The fact that this is confusing behavior to explain is why it's being removed. ## Rationale @@ -140,7 +140,7 @@ is being accessed outside of the file resource scope so it acquires it from the `new_resource` implicitly (in Chef Infra Client 12.5.1 and Chef Client 13.x) -The way to remediate that is by specifying the `new_resource`: +The way to remediate that's by specifying the `new_resource`: ```ruby property :content, String @@ -152,10 +152,10 @@ action :doit do end ``` -We are now enforcing this as the correct way to write resources. +We're now enforcing this as the correct way to write resources. Note that this namespace collision between custom resources and -subresources occurs with properties that are not also being immediately +subresources occurs with properties that aren't also being immediately used, and so this fails as well: ```ruby @@ -191,7 +191,7 @@ property :spiffyness, String action :doit do file '/tmp/file.xy' do - content new_resource.spiffyness # we are always referring to the outer custom resource's spiffiness property + content new_resource.spiffyness # we're always referring to the outer custom resource's spiffiness property end end ``` diff --git a/content/deprecations_ohai_amazon_linux.md b/content/deprecations_ohai_amazon_linux.md index 2829b51c4f..8f01c15c37 100644 --- a/content/deprecations_ohai_amazon_linux.md +++ b/content/deprecations_ohai_amazon_linux.md @@ -15,13 +15,13 @@ later, Amazon Linux will be identified as the mirrored the structure and package naming of RHEL 5, and with the release of RHEL 6 Amazon Linux moved to closely resemble RHEL 6. With the release of RHEL 7 Red Hat switched to the systemd init system, -however Amazon Linux has not yet decided to make that same switch. In +however Amazon Linux hasn't yet decided to make that same switch. In addition to the init system differences, Amazon Linux has added many critical packages with their own unique naming conventions. This makes it hard for users to write cookbooks for RHEL that will work on Amazon Linux systems out of the box. To simplify multi-platform cookbook code and to make it more clear when cookbooks actually support -Amazon Linux, we have created the '`amazon` platform family and removed +Amazon Linux, we've created the '`amazon` platform family and removed Amazon Linux from the `rhel` platform family. ## Remediation diff --git a/content/deprecations_ohai_sigar_plugins.md b/content/deprecations_ohai_sigar_plugins.md index 459f3a4fca..5aaf6c1429 100644 --- a/content/deprecations_ohai_sigar_plugins.md +++ b/content/deprecations_ohai_sigar_plugins.md @@ -13,7 +13,7 @@ discovering system configuration details. As time went on Ohai was expanded with built-in discovery methods for various platforms. The sigar gem was still required by Ohai and used primarily for the HP-UX platform. The SIGAR project is no longer active, and there is no longer -an active port of Ruby to HP-UX. Due to this we have chosen to remove the +an active port of Ruby to HP-UX. Due to this we've chosen to remove the sigar dependency and all sigar-based plugins from Ohai 13. There is no anticipated impact for Chef Foundation Platforms or Secondary Platforms. See the [Platforms](/platforms/) page for a complete list of diff --git a/content/deprecations_ohai_system_profile.md b/content/deprecations_ohai_system_profile.md index 9b86df53a5..369396d8d3 100644 --- a/content/deprecations_ohai_system_profile.md +++ b/content/deprecations_ohai_system_profile.md @@ -8,9 +8,9 @@ sitemapExclude = true +++ The system_profile plugin will be removed from Chef/Ohai 15 in April -2019. This plugin does not correctly return data on modern Mac systems. +2019. This plugin doesn't correctly return data on modern Mac systems. Additionally the same data is provided by the hardware plugin, which has -a format that is simpler to consume. Removing this plugin will reduce +a format that's simpler to consume. Removing this plugin will reduce Ohai return by \~3 seconds and greatly reduce the size of the node object on the Chef Infra Server. diff --git a/content/deprecations_ohai_v6_plugins.md b/content/deprecations_ohai_v6_plugins.md index 65ce677d91..ecea9a7b6f 100644 --- a/content/deprecations_ohai_v6_plugins.md +++ b/content/deprecations_ohai_v6_plugins.md @@ -12,7 +12,7 @@ Ohai 7.0 released with Chef Infra Client 11.12 introduced an improved plugin DSL model. At the time we introduced deprecations for the existing plugin DSL, which we referred to as V6 plugins. In Ohai/Chef Infra Client 14 we will remove the support for Ohai V6 plugins, causing a runtime error -if they are used. +if they're used. ## Remediation diff --git a/content/deprecations_property_name_collision.md b/content/deprecations_property_name_collision.md index 86860bdef9..a9cf84f5da 100644 --- a/content/deprecations_property_name_collision.md +++ b/content/deprecations_property_name_collision.md @@ -28,4 +28,4 @@ this will raise an exception and your Chef run will fail. ## Remediation Modify the resource and choose a different name for the property that -does not conflict with an already-existing method name. +doesn't conflict with an already-existing method name. diff --git a/content/deprecations_resource_name_without_provides.md b/content/deprecations_resource_name_without_provides.md index da2e508cf5..b3b93d106d 100644 --- a/content/deprecations_resource_name_without_provides.md +++ b/content/deprecations_resource_name_without_provides.md @@ -47,7 +47,7 @@ is addressed in recipe mode. There is also the old standard that existed before resources could declare what they provided. In that standard, the resource was addressed by prepending the `cookbook_name` to the filename that the resource was declared in. -That has remained unchanged and is not affected by this change. +That has remained unchanged and isn't affected by this change. ## Remediation @@ -77,9 +77,9 @@ end ``` It also works to have the `provides` line come before the `resource_name`, -the order does not matter. +the order doesn't matter. -For cookbooks which do not have to support Chef Infra Client 15 or before, the +For cookbooks which don't have to support Chef Infra Client 15 or before, the `resource_name` can also be entirely omitted: ```ruby diff --git a/content/deprecations_verify_file.md b/content/deprecations_verify_file.md index 4d4bb9e0cb..672b89eb2f 100644 --- a/content/deprecations_verify_file.md +++ b/content/deprecations_verify_file.md @@ -9,8 +9,8 @@ aliases = "/deprecations_verify_file.html" +++ The `verify` metaproperty allows the user to specify a `{path}` variable -that is expanded to the path of the file to be verified. Previously, it -was possible to use `{file}` as the variable, but that is now +that's expanded to the path of the file to be verified. Previously, it +was possible to use `{file}` as the variable, but that's now deprecated. The `{file}` expansion was deprecated in Chef Infra Client 12.5, and will be diff --git a/content/enterprise_chef.md b/content/enterprise_chef.md index c58eeeae01..a63fa68813 100644 --- a/content/enterprise_chef.md +++ b/content/enterprise_chef.md @@ -9,9 +9,9 @@ title = "Progress Chef Enterprise Edition" 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 is better tailored to address the demands of large and medium-sized enterprises, irrespective of the domain. +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 are not present in the Community edition are as follows: +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 diff --git a/content/enterprise_community_chef.md b/content/enterprise_community_chef.md index ba9e1f04b0..5404019ae9 100644 --- a/content/enterprise_community_chef.md +++ b/content/enterprise_community_chef.md @@ -12,7 +12,7 @@ title = "Progress Chef Enterprise vs Community Edition" 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 cannot 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. +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. @@ -24,13 +24,13 @@ To understand the advantages of Enterprise Chef over Community Chef, see the fol | ------------- | --------------- | --------------- | | 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 via different tiers of Service | 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 via different tiers of service | 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 will not match the frequency of Enterprise users | +| 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 | diff --git a/content/environments.md b/content/environments.md index cbf07c3421..53b3bf3804 100644 --- a/content/environments.md +++ b/content/environments.md @@ -19,7 +19,7 @@ product = ["client", "server"] Every Chef Infra Server organization must have at least one environment. Each organization starts out with a single `_default` environment. The -`_default` environment cannot be modified in any way. Nodes, roles, +`_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 @@ -76,7 +76,7 @@ pinning syntax. Environments may be stored on disk (any in source control) in two formats: -- As Ruby ( a file that ends with `.rb`); this format is not available when running Chef Infra Client in local mode +- 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 @@ -116,22 +116,22 @@ domain-specific attributes:

default_attributes

-

Optional. A set of attributes to be applied to all nodes, assuming the node does not 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 are 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):

+

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):

default_attributes 'apache2' => { 'listen_ports' => %w(80 443) }

description

-

A description of the functionality that is covered. For example:

+

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 are not allowed. For example:

+

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 are preserved. For example:

+

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:

override_attributes 'apache2' => { 'max_children' => '50' }

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:

override_attributes(
@@ -196,7 +196,7 @@ cookbook_versions({
 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 is overridden by an attribute
+environment, except in places where it's overridden by an attribute
 with higher precedence. For example:
 
 ```ruby
@@ -288,7 +288,7 @@ Once created, an environment can be managed in several ways:
     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 will not work unless these files are
+    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`.
 
@@ -323,7 +323,7 @@ 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 is storing a top-level key for an environment might look
+A data bag that's storing a top-level key for an environment might look
 something like this:
 
 ```json
@@ -359,7 +359,7 @@ 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 is
+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
@@ -374,8 +374,8 @@ attribute_i_want = mything[node.chef_environment]
 
 A node is considered to be associated with an environment when the
 `chef_environment` attribute is set. The `chef_environment` attribute
-cannot be set with normal or override attributes (in a role)
-because it is actually a method. An environment may be set explicitly
+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
diff --git a/content/errors.md b/content/errors.md
index 1dd8858ecb..3be5334c92 100644
--- a/content/errors.md
+++ b/content/errors.md
@@ -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 will not 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 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
@@ -169,7 +169,7 @@ DEBUG: Sending HTTP Request to https://api.opscode.com/organizations/ORGNAME/nod
 ERROR: Running exception handlers
 ```
 
-The URL will help identify the type of permission issue. If the URL is an index action (that is, 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.
+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:
 
@@ -185,7 +185,7 @@ 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 is causing the error.
+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:
 
@@ -238,10 +238,10 @@ If you're seeing an error like:
 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 cannot read /etc/chef/validation.pem, which you told me to use to sign requests
+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 could not find your validation.pem.
+It means that Chef Infra Client couldn't find your validation.pem.
 
 #### Troubleshooting steps
 
@@ -271,7 +271,7 @@ git commit -am "Updating so I can install a site cookbook"
 
 Re-run the `knife supermarket install` subcommand again to install the community cookbook.
 
-### Cannot find config file
+### Can't find config file
 
 If you're seeing an error like:
 
@@ -280,7 +280,7 @@ 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 cannot read /etc/chef/validation.pem, which you told me to use to sign requests!
+FATAL: Chef::Exceptions::PrivateKeyMissing: I can't read /etc/chef/validation.pem, which you told me to use to sign requests!
 ```
 
 #### Troubleshooting steps
@@ -335,11 +335,11 @@ Upgrading isn't supported at this time.
 - 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 (cannot connect)
+### CSPG010 (can't connect)
 
 #### Reason
 
-Cannot connect to PostgreSQL on the remote server.
+Can't connect to PostgreSQL on the remote server.
 
 #### Possible causes
 
@@ -348,11 +348,11 @@ Cannot connect to PostgreSQL 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 (cannot authenticate)
+### CSPG011 (can't authenticate)
 
 #### Reason
 
-Cannot authenticate to PostgreSQL on the remote server.
+Can't authenticate to PostgreSQL on the remote server.
 
 #### Possible causes
 
@@ -363,7 +363,7 @@ Cannot authenticate to PostgreSQL on the remote server.
 
 #### Reason
 
-Cannot connect to PostgreSQL on the remote server because rules in
+Can't connect to PostgreSQL on the remote server because rules in
 `pg_hba` are incorrect.
 
 #### Possible causes
diff --git a/content/feedback.md b/content/feedback.md
index 156171486f..19aca7819a 100644
--- a/content/feedback.md
+++ b/content/feedback.md
@@ -14,7 +14,7 @@ product = []
 +++
 
 chef-docs hopes that the documentation is always just what you are
-looking for, but when that is not the case we do appreciate
+looking for, but when that isn't the case we do appreciate
 feedback. There are several ways to get feedback to chef-docs. For
 members of the Chef community, customers, or people who just want to
 send feedback, choose any of the following options:
@@ -28,7 +28,7 @@ suggestions for improving the documentation on a page. Be as detailed as possibl
 Use the feedback form at the bottom of this page for submitting general feedback
 about Chef's documentation.
 
-These forms are not for customer support. If you need support,
+These forms aren't for customer support. If you need support,
 contact [Chef support](https://supportlink.chef.io/).
 
 ## Email
diff --git a/content/fips.md b/content/fips.md
index 1a1385264f..8dd0805bed 100644
--- a/content/fips.md
+++ b/content/fips.md
@@ -13,7 +13,7 @@ product = ["client", "server", "workstation"]
     weight = 30
 +++
 
-## What is FIPS?
+## What's FIPS?
 
 Federal Information Processing Standards (FIPS) are federal standards
 for computer systems used by contractors of government agencies and
@@ -26,26 +26,26 @@ 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?
+### 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 Should Not Enable FIPS?
+### 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 are not
-a US non-military governmental agency, or you are not contracting with
-one, and you are not contractually obligated to meet federal government
-security standards, then do not enable FIPS. Chef products have robust
+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 is contractually necessary.
+enabling FIPS if it's contractually necessary.
 
-## Supported Products
+## Supported products
 
 **Supported:**
 
@@ -55,11 +55,11 @@ enabling FIPS if it is contractually necessary.
 
 **Unsupported:**
 
-FIPS mode is not supported for Chef Infra Server add-ons. This includes Chef Manage.
+FIPS mode isn't supported for Chef Infra Server add-ons. This includes Chef Manage.
 
-## How to Enable FIPS Mode in the Operating System
+## How to enable FIPS mode in the operating system
 
-### FIPS Kernel Settings
+### 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
@@ -82,7 +82,7 @@ To enable FIPS on your platform follow these instructions:
 - [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 the Chef Infra Server
+## How to enable FIPS mode for Chef Infra Server
 
 ### Prerequisites
 
@@ -92,14 +92,14 @@ To enable FIPS on your platform follow these instructions:
 ### Configuration
 
 If you have FIPS compliance enabled at the kernel level and install or
-reconfigure the Chef Infra Server then it will default to running in
+reconfigure Chef Infra Server then it will default to running in
 FIPS mode.
 
-To enable FIPS manually for the Chef Infra Server, can add `fips true`
+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 the Chef Infra Client
+## How to enable FIPS mode for Chef Infra Client
 
 ### Prerequisites
 
@@ -110,6 +110,6 @@ configuration information see [chef-server.rb Optional Settings](/server/config_
 
 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
+#### 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
index 119613f55f..1add86fccb 100644
--- a/content/glossary.md
+++ b/content/glossary.md
@@ -34,11 +34,11 @@ Chef Automate
 
 Chef Infra Client
 
-: A command-line tool that that runs Chef. Also, the name of Chef as it is installed on a node.
+: 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 is 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.
+: 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
 
@@ -70,7 +70,7 @@ custom resource
 
 data bag
 
-: A data_bag is a global variable that is stored as JSON data and is accessible from a Chef Infra Server.
+: A data_bag is a global variable that's stored as JSON data and is accessible from a Chef Infra Server.
 
 environment
 
@@ -90,15 +90,15 @@ library
 
 node
 
-: A node is any physical, virtual, or cloud device that is configured and maintained by an instance of Chef Infra Client.
+: 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 is under management by Chef Infra.
+: 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 is used to detect attributes on a node, and then provide these attributes to Chef Infra Client at the start of every run.
+: 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
 
@@ -122,12 +122,12 @@ role
 
 run-list
 
-: A run-list defines all of the configuration settings that are necessary for a node that is under management by Chef to be put into the desired state and the order in which these configuration settings are applied.
+: 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 is used to automatically test cookbook data across any combination of platforms and test suites. Test Kitchen is packaged in Chef Workstation.
+: 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 does not affect other resources or recipes.
+: 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
index 8f8a092b6d..eb1f19e91e 100644
--- a/content/google.md
+++ b/content/google.md
@@ -40,7 +40,7 @@ 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 is in a different
+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.
 
diff --git a/content/handlers.md b/content/handlers.md
index a2e42464cb..7643971fe8 100644
--- a/content/handlers.md
+++ b/content/handlers.md
@@ -155,7 +155,7 @@ See the [chef_handler Resource]({{< relref "/resources/chef_handler">}}) documen
 
 ### 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 is available to Chef Infra Client at the start of every run.
+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
 
@@ -169,7 +169,7 @@ A custom handler can be created to support any situation. The easiest way to bui
 
 ### Syntax
 
-The syntax for a handler can vary, depending on what the the situations the handler is being asked to track, the type of handler being used, and so on. All custom exception and report handlers are defined using Ruby and must be a subclass of the `Chef::Handler` class.
+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'
@@ -187,8 +187,8 @@ 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 is used in a recipe
-- `report` is an interface that is used to define the custom handler
+- `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:
 
@@ -298,7 +298,7 @@ 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 are not typically used in a handler and, for the most part, are completely unnecessary for a handler to work properly and/or as desired.
+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
 
@@ -378,7 +378,7 @@ The `run_status` object is initialized by Chef Infra Client before the `report`
 
 `success?`
 
-: Show that a Chef Infra Client run succeeded when uncaught exceptions were not raised during a Chef Infra Client run. A report handler runs when the `success?` indicator is `true`.
+: 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`
 
@@ -386,7 +386,7 @@ The `run_status` object is initialized by Chef Infra Client before the `report`
 
 {{< note >}}
 
-These properties are not 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.
+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 >}}
 
diff --git a/content/infra_language/checking_hypervisors.md b/content/infra_language/checking_hypervisors.md
index 9201ca283d..cc830c4f79 100644
--- a/content/infra_language/checking_hypervisors.md
+++ b/content/infra_language/checking_hypervisors.md
@@ -23,7 +23,7 @@ Determine if the current node supports running guests under any virtualization e
 
 ## physical?
 
-Determine if the current node is NOT running under any virtualization environment (bare-metal or hypervisor on metal).
+Determine if the current node isn't running under any virtualization environment (bare-metal or hypervisor on metal).
 
 ## hyperv?
 
@@ -91,7 +91,7 @@ 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 is kept around for legacy purposes.
+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?
 
diff --git a/content/infra_language/checking_platforms.md b/content/infra_language/checking_platforms.md
index 94628b1fc8..1081a1894d 100644
--- a/content/infra_language/checking_platforms.md
+++ b/content/infra_language/checking_platforms.md
@@ -13,7 +13,7 @@ gh_repo = "chef-web-docs"
 
 ## 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 is detected by [Ohai](/ohai) during every Chef Infra Client run.
+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:
 
@@ -24,7 +24,7 @@ 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 is specific for the platform, if detected
+- `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
 
@@ -208,7 +208,7 @@ 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 is specific for the platform family, if detected
+- `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
 
diff --git a/content/infra_language/cookbook_execution.md b/content/infra_language/cookbook_execution.md
index f4861c42b3..c35aaee470 100644
--- a/content/infra_language/cookbook_execution.md
+++ b/content/infra_language/cookbook_execution.md
@@ -94,7 +94,7 @@ where `file` is the type of resource, `/etc/hosts` is the name, and `f.mode` is
 
 ### 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 is detected by Ohai during every Chef Infra Client run.
+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:
 
@@ -106,7 +106,7 @@ For example:
 
 ```ruby
 if node.attribute?('ipaddress')
-  # the node has an ipaddress
+  # the node has an IP address
 end
 ```
 
diff --git a/content/infra_language/editing_resources.md b/content/infra_language/editing_resources.md
index 4aa54b2587..8bbda6e505 100644
--- a/content/infra_language/editing_resources.md
+++ b/content/infra_language/editing_resources.md
@@ -23,8 +23,8 @@ declare_resource(:resource_type, 'resource_name', resource_attrs_block)
 
 where:
 
-- `:resource_type` is the resource type, such as `:file` (for the **file** resource), `:template` (for the **template** resource), and so on. Any resource available to Chef may be declared.
-- `resource_name` the property that is 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_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:
@@ -55,8 +55,8 @@ delete_resource(:resource_type, 'resource_name')
 
 where:
 
-- `:resource_type` is the resource type, such as `:file` (for the **file** resource), `:template` (for the **template** resource), and so on. Any resource available to Chef may be declared.
-- `resource_name` the property that is 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_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:
 
@@ -67,7 +67,7 @@ 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 is not found, an
+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:
@@ -78,8 +78,8 @@ delete_resource!(:resource_type, 'resource_name')
 
 where:
 
-- `:resource_type` is the resource type, such as `:file` (for the **file** resource), `:template` (for the **template** resource), and so on. Any resource available to Chef Infra may be declared.
-- `resource_name` the property that is 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_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:
 
@@ -92,7 +92,7 @@ delete_resource!(:file, '/x/file.txt')
 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 does not exist in the resource collection, it will be created.
+- 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:
 
@@ -102,8 +102,8 @@ edit_resource(:resource_type, 'resource_name', resource_attrs_block)
 
 where:
 
-- `:resource_type` is the resource type, such as `:file` (for the **file** resource), `:template` (for the **template** resource), and so on. Any resource available to Chef may be declared.
-- `resource_name` the property that is 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_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:
@@ -132,7 +132,7 @@ 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 is not found, an exception is returned.
+In both cases, if the resource isn't found, an exception is returned.
 
 The syntax for the `edit_resource!` method is as follows:
 
@@ -142,8 +142,8 @@ edit_resource!(:resource_type, 'resource_name')
 
 where:
 
-- `:resource_type` is the resource type, such as `:file` (for the **file** resource), `:template` (for the **template** resource), and so on. Any resource available to Chef may be declared.
-- `resource_name` the property that is 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_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:
@@ -157,7 +157,7 @@ edit_resource!(:file, '/x/y.rst')
 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 does not exist in the resource collection, it will be created.
+- 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:
 
@@ -167,8 +167,8 @@ find_resource(:resource_type, 'resource_name')
 
 where:
 
-- `:resource_type` is the resource type, such as `:file` (for the **file** resource), `:template` (for the **template** resource), and so on. Any resource available to Chef may be declared.
-- `resource_name` the property that is 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_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:
 
@@ -189,7 +189,7 @@ end
 
 ## find_resource!
 
-Use the `find_resource!` method to find a resource in the resource collection. If the resource is not found, an exception is returned.
+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:
 
@@ -199,8 +199,8 @@ find_resource!(:resource_type, 'resource_name')
 
 where:
 
-- `:resource_type` is the resource type, such as `:file` (for the **file** resource), `:template` (for the **template** resource), and so on. Any resource available to Chef may be declared.
-- `resource_name` the property that is 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_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:
 
diff --git a/content/infra_language/reading_data_bags.md b/content/infra_language/reading_data_bags.md
index c74bbcbf31..524d98c3f6 100644
--- a/content/infra_language/reading_data_bags.md
+++ b/content/infra_language/reading_data_bags.md
@@ -43,7 +43,7 @@ The syntax for the `data_bag_item` method is as follows:
 data_bag_item(bag_name, item, secret)
 ```
 
-where `secret` is the secret used to load an encrypted data bag. If `secret` is not specified, Chef Infra Client looks for a secret at the path specified by the `encrypted_data_bag_secret` setting in the `client.rb` file.
+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
 
diff --git a/content/infra_language/shelling_out.md b/content/infra_language/shelling_out.md
index 247c1a2f06..9f8154b8b6 100644
--- a/content/infra_language/shelling_out.md
+++ b/content/infra_language/shelling_out.md
@@ -23,7 +23,7 @@ The syntax for the `shell_out` method is as follows:
 shell_out(command_args)
 ```
 
-where `command_args` is the command that is run against the node.
+where `command_args` is the command that's run against the node.
 
 ## shell_out!
 
@@ -35,4 +35,4 @@ The syntax for the `shell_out!` method is as follows:
 shell_out!(command_args)
 ```
 
-where `command_args` is the command that is run against the node. This method will return `true` or `false`.
+where `command_args` is the command that's run against the node. This method will return `true` or `false`.
diff --git a/content/install_bootstrap.md b/content/install_bootstrap.md
index 145bf2409e..aabdae64be 100644
--- a/content/install_bootstrap.md
+++ b/content/install_bootstrap.md
@@ -351,7 +351,7 @@ 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` is not practical because the machines are created automatically and someone can't always be on-hand to initiate the bootstrap process.
+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:
 
@@ -428,7 +428,7 @@ EOF
 cd /etc/chef/
 
 # Install chef
-curl -L https://omnitruck.chef.io/install.sh | bash || error_exit 'could not 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
diff --git a/content/install_chef_air_gap.md b/content/install_chef_air_gap.md
index af34beb654..9352424f17 100644
--- a/content/install_chef_air_gap.md
+++ b/content/install_chef_air_gap.md
@@ -186,7 +186,7 @@ custom template, and then modify the package and Ruby gem sources.
     ```
 
     This appends the appropriate `rubygems_url` setting to the
-    `/etc/chef/client.rb` file that is created during bootstrap, which
+    `/etc/chef/client.rb` file that's created during bootstrap, which
     ensures that your nodes use your internal gem mirror.
 
 ### Configure knife
@@ -336,8 +336,8 @@ 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 for your chef server.
-- `chef_oauth2_app_id`: the Chef Identity uid from
+- `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`
diff --git a/content/licensing/terms.md b/content/licensing/terms.md
index 35da094a46..1dbb9452ba 100644
--- a/content/licensing/terms.md
+++ b/content/licensing/terms.md
@@ -27,7 +27,7 @@ Licensed Unit
 : "License Unit" types/metrics include node, entitled content, service instance, target and/or endpoint.
 
 Measurement of License Units/License Consumption Data
-: Measurement of usage of a license unit. It's a numerical value based on the bundle\SKU or add-on(s) customer has purchased.
+: Measurement of usage of a license unit. It's a numerical value based on the bundle\SKU or add-ons customer has purchased.
 
 Free-tier Users
 : Users using a Free License of Chef (User will only get the executable but restricted in some way), not the code base.
diff --git a/content/lwrp_to_custom_resources.md b/content/lwrp_to_custom_resources.md
index 7c15ae6d66..526b1e6765 100644
--- a/content/lwrp_to_custom_resources.md
+++ b/content/lwrp_to_custom_resources.md
@@ -14,7 +14,7 @@ product = ["client", "workstation"]
 
 ## Overview
 
-It is no longer recommended to write resources in the __Light Weight Resource Provider (LWRP)__ format.
+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.
 
@@ -39,7 +39,7 @@ These files are merged into one, and moved into the resources directory.
 
 ## Drop LWRP classes
 
-LWRPs used classes to separate Provider and Resource behaviors, but Custom Resources do not need this distinction. This means that we remove the class definitions in their entirety, as shown in the following example:
+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
@@ -98,7 +98,7 @@ end
 
 ## Remove Attributes
 
-It is best practice to use properties to change the behavior of resources.
+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`.
 
diff --git a/content/manage.md b/content/manage.md
index 63780700aa..61b6bbce59 100644
--- a/content/manage.md
+++ b/content/manage.md
@@ -22,7 +22,7 @@ product = []
 
 {{< note >}}
 
-Chef Automate 2 does not deploy Chef Manage alongside Chef Infra Server.
+Chef Automate 2 doesn't deploy Chef Manage alongside Chef Infra Server.
 
 {{< /note >}}
 
diff --git a/content/nodes.md b/content/nodes.md
index a216a505ad..78445a50e1 100644
--- a/content/nodes.md
+++ b/content/nodes.md
@@ -69,11 +69,11 @@ across the organization are unique.
 
 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, the number of
-clients a service running on a node is capable of accepting, and so on.
+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 is stored on the Chef Infra
+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.
@@ -83,8 +83,8 @@ copy on the Chef Infra Server at the end of each Chef Infra Client run.
 ### 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 version(s) of available
-programming languages that are available, and so on. An attribute may be
+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
@@ -111,7 +111,7 @@ 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 are used to set policy on nodes.
+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
 
@@ -128,4 +128,4 @@ You can manage nodes directly using Knife, Chef Automate, or by using command-li
 - [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 is stored in a file on-disk and then read by Chef Infra Client as required.
+- 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
index 82840b2078..a19f530b81 100644
--- a/content/ohai.md
+++ b/content/ohai.md
@@ -257,7 +257,7 @@ Custom Ohai plugins can be written to collect additional information from system
 
 ## Hints
 
-Ohai hints are used to tell Ohai something about the system that it is 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 does not exist.
+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?`.
 
diff --git a/content/ohai_custom.md b/content/ohai_custom.md
index a1a643d5a7..3c76c6a75c 100644
--- a/content/ohai_custom.md
+++ b/content/ohai_custom.md
@@ -62,12 +62,12 @@ 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 is collected by Ohai at the start of a Chef Infra Client run. An attribute can also be defined using an `attribute/subattribute` pattern
+- 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 is 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 is not defined by a platform-specific `collect_data` block
-- `collect_data(:platform)` is a platform-specific code block that is 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']`
+- `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:
@@ -133,16 +133,16 @@ To see the rest of the code in this plugin, go to:  e
-  Ohai::Log.debug('ip_scopes: cannot load gem, plugin disabled: #{e}')
+  Ohai::Log.debug('ip_scopes: can't load gem, plugin disabled: #{e}')
 end
 ```
 
@@ -531,7 +531,7 @@ Ohai.plugin(:Hostname) do
     if info.first =~ /.+?\.(.*)/
       fqdn info.first
     else
-      # host is not in dns. optionally use:
+      # host isn't in dns. optionally use:
       # C:\WINDOWS\system32\drivers\etc\hosts
       fqdn Socket.gethostbyaddr(info.last).first
     end
diff --git a/content/packages.md b/content/packages.md
index bc0fd3a527..92222e8531 100644
--- a/content/packages.md
+++ b/content/packages.md
@@ -108,7 +108,7 @@ To set up a Yum package repository for Enterprise Linux platforms:
     ```
 
     Note that the `yum-config-manager` command requires the `yum-utils`
-    package, which is not installed on CentOS by default. You can
+    package, which isn't installed on CentOS by default. You can
     install the package by running `sudo yum install yum-utils`, or you
     can use the `mv` command to add the repository to the
     `/etc/yum.repos.d/` directory:
diff --git a/content/platform_overview.md b/content/platform_overview.md
index 23bdd72224..08d85d3bf3 100644
--- a/content/platform_overview.md
+++ b/content/platform_overview.md
@@ -13,7 +13,7 @@ product = ["automate", "client", "server", "habitat", "inspec", "workstation"]
     weight = 10
 +++
 
-Chef is an automation company. Ever since it was founded in 2008, we have
+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
@@ -30,7 +30,7 @@ development to production. Here's the complete Chef solution.
 
 [Chef Workstation](/workstation/) allows you to author cookbooks and administer your
 infrastructure. Chef Workstation runs on the computer you use everyday,
-whether it is Linux, macOS, or Windows.
+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
@@ -71,7 +71,7 @@ upload your cookbooks.
 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 is any compute
+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,
@@ -79,7 +79,7 @@ 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 does not conform to what the cookbook says it should be, Chef Infra
+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.
@@ -91,7 +91,7 @@ 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 is a container, bare metal, or PaaS does not in any way
+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
@@ -118,7 +118,7 @@ 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, are not used.
+protocols, such as telnet, aren't used.
 
 ```ruby
 describe package('telnetd') do
diff --git a/content/plugin_community.md b/content/plugin_community.md
index d672299b79..6e16e3429d 100644
--- a/content/plugin_community.md
+++ b/content/plugin_community.md
@@ -36,7 +36,7 @@ The following Ohai plugins are available from the open source community:
 
 
 dell.rb
-Adds some useful Dell server information to Ohai. For example: service tag, express service code, storage info, RAC info, and so on. To use this plugin, OMSA and SMBIOS applications need to be installed.
+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.
 
 
 ipmi.rb
@@ -88,11 +88,11 @@ The following Ohai plugins are available from the open source community:
 
 
 win32_software.rb
-Adds the ability for Ohai to use Windows Management Instrumentation (WMI) to discover useful information about software that is installed on any node that is running Windows.
+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.
 
 
 win32_svc.rb
-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 is 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.
 
 
 
diff --git a/content/policyfile.md b/content/policyfile.md
index 2ecfbf7e65..6892a90f31 100644
--- a/content/policyfile.md
+++ b/content/policyfile.md
@@ -29,13 +29,13 @@ Policyfiles make it easier to test and promote code safely with a simpler interf
 
 ### Focused System Workflows
 
-The knife command line tool maps closely to the Chef Infra Server API and the objects defined by it: roles, environments, run-lists, cookbooks, data bags, nodes, and so on. Chef Infra Client assembles these pieces at run-time and configures a host to do useful work.
+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 does not 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 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
 
@@ -49,13 +49,13 @@ 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 is 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 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 is done less frequently.
+Policyfile moves this computation to the workstation, where it's done less frequently.
 
 ### Role and Environment Mutability
 
@@ -65,13 +65,13 @@ 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 should not 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 does not provide cookbook mutability. Name collisions are prevented by storing cookbooks by name and an opaque identifier that is 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 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 does not 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 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 is computed from the content of a cookbook is the only place where an opaque identifier is necessary. When working with Policyfile, be sure to:
+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
@@ -84,7 +84,7 @@ The opaque identifier is mostly behind the scenes and is only visible once publi
 
 ### Environment Cookbooks
 
-Policyfile replaces the environment cookbook pattern that is often required by Berkshelf, along with a dependency solver and fetcher. That said, Policyfile does not replace all Berkshelf scenarios.
+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
 
@@ -116,7 +116,7 @@ The following settings may be configured in the client.rb file for use with Poli
 
 `named_run_list`
 
-: The run-list associated with a policy file.
+: The run-list associated with a Policyfile.
 
 `policy_group`
 
@@ -142,7 +142,7 @@ A node may be bootstrapped to use Policyfile files. Use the following options as
 
 : 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 is passed to Chef Infra Client.
+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
 
@@ -191,7 +191,7 @@ suites:
 
 {{< note >}}
 
-As `chef_zero` explicitly tests outside the context of a Chef Infra Server, the `policy_groups` concept is not applicable. The value of `policy_group` during a converge will be set to `local`.
+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 >}}
 
diff --git a/content/proxies.md b/content/proxies.md
index a1e4c4e722..1e1389565b 100644
--- a/content/proxies.md
+++ b/content/proxies.md
@@ -15,7 +15,7 @@ aliases = ["/proxies.html"]
 +++
 
 In an environment that requires proxies to reach the Internet, many Chef
-commands will not work until they are configured correctly. To configure
+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.
@@ -33,7 +33,7 @@ check the environment variables. Run the following:
 env | grep -i http_proxy
 ```
 
-If an environment variable is set, it **MUST** be lowercase. If it is
+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.
 
@@ -159,7 +159,7 @@ environments that use an FTP proxy:
 ### No Proxy
 
 The `no_proxy` setting is used to specify addresses for which the proxy
-should not be used. This can be a single address or a comma-separated
+shouldn't be used. This can be a single address or a comma-separated
 list of addresses.
 
 Example:
@@ -172,7 +172,7 @@ no_proxy 'test.example.com,test.example2.com,test.example3.com'
 
 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 is, "without wildcards").
+to be specified explicitly (that's, "without wildcards").
 
 {{< /note >}}
 
diff --git a/content/recipes.md b/content/recipes.md
index 75e62283c8..fd0d838fdc 100644
--- a/content/recipes.md
+++ b/content/recipes.md
@@ -47,7 +47,7 @@ end
 ```
 
 The only environment being altered is the one being passed to the child
-process that is started by the **bash** resource. This will not affect
+process that's started by the **bash** resource. This won't affect
 the Chef Infra Client environment or any child processes.
 
 ## Work with Recipes
@@ -106,13 +106,13 @@ mysql_creds['pass'] # will be decrypted
 
 ### Assign Dependencies
 
-If a cookbook has a dependency on a recipe that is located in another
+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 is not required with chef-solo.
+Declaring cookbook dependencies isn't required with chef-solo.
 
 {{< /note >}}
 
@@ -273,7 +273,7 @@ to a run-list is similar to:
 }
 ```
 
-where `::default_recipe` is implied (and does not need to be specified).
+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:
 
@@ -395,7 +395,7 @@ 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 cannot be installed. In this situation, it is OK for a
+when a package can't be installed. In this situation, it's OK for a
 recipe to stop processing.
 
 #### raise Keyword
@@ -490,7 +490,7 @@ specify the message to be raised.
 
 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 is always
+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,
@@ -520,7 +520,7 @@ end
 
 where:
 
-- The **ruby_block** resource declares a `block` of Ruby code that is
+- 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']`
diff --git a/content/release_notes_360.md b/content/release_notes_360.md
index c721c42f06..0f28b4682d 100644
--- a/content/release_notes_360.md
+++ b/content/release_notes_360.md
@@ -120,7 +120,7 @@ product = [""]
 
 ### Improvements
 
-- In the previous release, you could not add more than one user-defined policy to a custom role.
+- In the previous release, you couldn't add more than one user-defined policy to a custom role.
   You can now create custom roles with multiple policies with a single command.
 - The Courier Orchestrator service is now multi-threaded so that it can send multiple Courier jobs that are scheduled simultaneously.
 - We improved Chef 360 Platform enrollment failure messages so that they now show appropriate error messages for all stages of enrollment.
@@ -153,13 +153,13 @@ product = [""]
 
 ### Overview
 
-This is the initial release of Progress Chef 360 Platform. Chef 360 Platform is a set of integrated software components and a surrounding ecosystem where value comes not only from individual features but from its ability to connect external tools, teams, data, and processes. We see Chef 360 Platform as a way to take the power and benefits of policy as code and spread it to everyone who has a role in development, operations and security. In addition to that Chef 360 Platform is an integrated ecosystem of tools providing not just value but also its ability to connect teams and tools together. It is a modern, cloud-native DevOps platform that democratizes DevOps by empowering IT operators and DevOps engineers to manage mission-critical infrastructure securely.
+This is the initial release of Progress Chef 360 Platform. Chef 360 Platform is a set of integrated software components and a surrounding ecosystem where value comes not only from individual features but from its ability to connect external tools, teams, data, and processes. We see Chef 360 Platform as a way to take the power and benefits of policy as code and spread it to everyone who has a role in development, operations and security. In addition to that Chef 360 Platform is an integrated ecosystem of tools providing not just value but also its ability to connect teams and tools together. It's a modern, cloud-native DevOps platform that democratizes DevOps by empowering IT operators and DevOps engineers to manage mission-critical infrastructure securely.
 
 When we set out to build a new platform we identified four primary guiding principles, used to help us make the right choices and stay aligned with our objectives.
 
 - Automate everything (within reason), by providing you prescriptive ways to use the platform, while still retaining our core flexibility.
 - Reach everywhere, be that your data center, a cloud, a laptop, single board computer or even a satellite. We want to support you everywhere you are running a workload.
-- Embrace all users and skill levels. So we are making this platform not just with APIs and CLIs for automation but also with an intuitive UI.
+- Embrace all users and skill levels. So we're making this platform not just with APIs and CLIs for automation but also with an intuitive UI.
 - Embrace open standards. This means you get open interoperability to OpenAPI v3 services, cloud-native benefits by starting in Kubernetes at Chef 360's inception, and other security standards to make acceptance and adoption easy.
 
 Chef 360 Platform contains a host of services on which new products from Chef are being built. Progress Chef Courier is one such product. This release also is the initial release of Progress Chef Courier product.
@@ -233,16 +233,16 @@ Interface-driven
 
 ### Known issues
 
-We have tested on the supported platforms listed above and intend on broadening this support in upcoming releases. Chef 360 Platform may operate correctly on other platforms; we just cannot guarantee it. Contact your customer success team with questions.
+We've tested on the supported platforms listed above and intend on broadening this support in upcoming releases. Chef 360 Platform may operate correctly on other platforms; we just can't guarantee it. Contact your customer success team with questions.
 
 Chef 360 Platform has the following known issues:
 
-- The Chef 360 Platform is not yet supported for environments which cannot access the internet, that is, air gapped environments.
+- The Chef 360 Platform isn't yet supported for environments which can't access the internet, that's, air gapped environments.
 - Don't create a tenant name with the underscore character `_`, services will fail to start.
-- Don't change or modify the underlying Kubernetes configuration after installing v1.0; upgrades are not yet supported.
-- Upgrades to v1.0 are manual; automatic upgrades are not supported.
-- The message queues internally for Chef Courier job distribution and node enrollment do not support TLS.
-- Chef 360 Platform services do not work correctly on nodes using localhost DNS settings (`127.0.0.1`).
+- Don't change or modify the underlying Kubernetes configuration after installing v1.0; upgrades aren't yet supported.
+- Upgrades to v1.0 are manual; automatic upgrades aren't supported.
+- The message queues internally for Chef Courier job distribution and node enrollment don't support TLS.
+- Chef 360 Platform services don't work correctly on nodes using localhost DNS settings (`127.0.0.1`).
 - Some Courier jobs run to completion---success or failure---and may not be cancellable. Additionally, if a Linux shell job is specified for a Windows node (or vice-versa), it should be manually verified as working since some scripts may have 3rd party dependencies on a given platform.
 - Several features including node filters and exemptions, un-enrolling and re-enrolling a node, and multi-node deployment under development and will be available in a subsequent release.
 - The user experience (UI) is experimental and being updated frequently now so some users of the distribution channel and containers may see improvements and screen changes between operations.
diff --git a/content/release_notes_chefdk.md b/content/release_notes_chefdk.md
index 2a42685958..d4204c66cd 100644
--- a/content/release_notes_chefdk.md
+++ b/content/release_notes_chefdk.md
@@ -36,7 +36,7 @@ ChefDK packages are no longer produced for Debian 8 and RHEL/CentOS 6, as these
 
 #### Test Kitchen
 
-Test Kitchen was updated from 2.7.2 to 2.8.0. This release improves how we execute commands on Windows hosts to avoid failures from executing commands that are too long for the windows command line. Thanks for this fix [@ramereth](https://github.com/ramereth)!
+Test Kitchen was updated from 2.7.2 to 2.8.0. This release improves how we execute commands on Windows hosts to avoid failures from executing commands that are too long for the Windows command line. Thanks for this fix [@ramereth](https://github.com/ramereth)!
 
 #### Kitchen Google
 
@@ -44,7 +44,7 @@ The Kitchen Google driver for Test Kitchen was updated from 2.0.3 to 2.1.0. This
 
 #### Kitchen Vagrant
 
-The kitchen-vagrant plugin is updated from version 1.7.1 to 1.7.2 with a bug fix to no longer stop with an error when updating a Vagrant box that has not yet been downloaded.
+The kitchen-vagrant plugin is updated from version 1.7.1 to 1.7.2 with a bug fix to no longer stop with an error when updating a Vagrant box that hasn't yet been downloaded.
 
 #### Kitchen Dokken
 
@@ -54,12 +54,12 @@ Kitchen Dokken has been updated to 2.11.2 to resolve failures from creating cont
 
 Chef InSpec has been updated to 4.24.8, which includes the following improvements:
 
-- An unset `HOME` environment variable will not cause execution failures
+- An unset `HOME` environment variable won't cause execution failures
 - You can use wildcards in `platform-name` and `release` in InSpec profiles. Thanks for this improvement [@yarick](https://github.com/yarick)!
 - The `WMI` resource now returns an array to support returning multiple WMI objects
 - The `package` resource on Windows properly escapes package names. Thanks for this improvement [@ramereth](https://github.com/ramereth)!
 - The `grub_conf` resource succeeds even if without a `menuentry` in the grub config
-- Loaded plugins will not try to re-load themselves
+- Loaded plugins won't try to re-load themselves
 - Waiver expiration is now always populated
 
 #### chef-vault
@@ -133,7 +133,7 @@ The `chef-vault` gem has been updated from 4.0.11 to 4.0.12. This release fixes
 
 ### Knife Improvements
 
-We have reworked how the knife command loads dependencies to greatly improve performance. For some users this may result in a 2/3 reduction in the time knife commands take to load the first time. We also fixed the `knife ssh` command hanging when connecting to Windows nodes over SSH.
+We've reworked how the knife command loads dependencies to greatly improve performance. For some users this may result in a 2/3 reduction in the time knife commands take to load the first time. We also fixed the `knife ssh` command hanging when connecting to Windows nodes over SSH.
 
 ### Updates Components
 
@@ -154,7 +154,7 @@ Chef Vault has been updated from 4.0.1 to 4.0.11. This release resolves errors w
 
 #### Test Kitchen
 
-Test Kitchen has been updated from 2.5.4 to 2.7.0, which adds the ability to mark plugins as unable to run with a concurrency (`-c`) level greater than 1. This will help prevent strange failures that occur with some plugins which cannot run concurrently in the future.
+Test Kitchen has been updated from 2.5.4 to 2.7.0, which adds the ability to mark plugins as unable to run with a concurrency (`-c`) level greater than 1. This will help prevent strange failures that occur with some plugins which can't run concurrently in the future.
 
 #### Kitchen AzureRM
 
@@ -188,7 +188,7 @@ The included `cacerts` bundle in Chef Infra Client has been updated to the 7-22-
 
 #### Chef Infra Client
 
-Chef Infra Client has been updated from 15.12.2 to 15.3.8. This new release includes a new deprecation warning when resources specify `resource_name` without also specifying `provides` which results in failures on Chef Infra Client 16.2 and later. This release also improves the warning message that occurs when a cookbook includes a resource that is now bundled directly in Chef Infra Client.
+Chef Infra Client has been updated from 15.12.2 to 15.3.8. This new release includes a new deprecation warning when resources specify `resource_name` without also specifying `provides` which results in failures on Chef Infra Client 16.2 and later. This release also improves the warning message that occurs when a cookbook includes a resource that's now bundled directly in Chef Infra Client.
 
 #### Chef InSpec
 
@@ -247,7 +247,7 @@ InSpec was updated from 4.19 to 4.21. This new release includes the following im
 
 The `knife bootstrap` command has been updated with several fixes and improvements
 
-- knife bootstrap will now warn when bootstrapping a system using a validation key. Users should instead use validatorless bootstrapping with `knife bootstrap` which generates node and client keys using the client key of the user bootstrapping the node. This method is far more secure as an organization-wide validation key does not need to be distributed or rotated. Users can switch to validatorless bootstrapping by removing any `validation_key` entries in their config.rb (knife.rb) file.
+- knife bootstrap will now warn when bootstrapping a system using a validation key. Users should instead use validatorless bootstrapping with `knife bootstrap` which generates node and client keys using the client key of the user bootstrapping the node. This method is far more secure as an organization-wide validation key doesn't need to be distributed or rotated. Users can switch to validatorless bootstrapping by removing any `validation_key` entries in their config.rb (knife.rb) file.
 - Resolved an error bootstrapping Linux nodes from Windows hosts
 - Improved information messages during the bootstrap process
 - Bootstrapping will now be done using a single SSH connection improving bootstrap times on high latency network connection.
@@ -284,7 +284,7 @@ Sample kitchen.yml config:
 
 ### New Platforms
 
-ChefDK packages are now created for Ubuntu 20.04 and Debian 10! Additionally, we have increased package validation for our Windows 10 packages to ensure compatibility. See the Chef Downloads Page for a complete list of platforms.
+ChefDK packages are now created for Ubuntu 20.04 and Debian 10! Additionally, we've increased package validation for our Windows 10 packages to ensure compatibility. See the Chef Downloads Page for a complete list of platforms.
 
 ### macOS Binary Signing
 
@@ -325,7 +325,7 @@ Cookstyle has upgraded from 5.20 to 5.23, which includes 8 new cops, and signifi
 - ChefRedundantCode/StringPropertyWithNilDefault
 - ChefRedundantCode/PropertySplatRegex
 
-**Note**: Chef Workstation ships with Cookstyle 6.x, which includes a significantly improved RuboCop engine, and 24 additional cops for resolving deprecations and preparing cookbooks for Chef Infra Client 16. Cookstyle 5.x does not include Chef Infra Client 16 preparation cops.
+**Note**: Chef Workstation ships with Cookstyle 6.x, which includes a significantly improved RuboCop engine, and 24 additional cops for resolving deprecations and preparing cookbooks for Chef Infra Client 16. Cookstyle 5.x doesn't include Chef Infra Client 16 preparation cops.
 
 #### Test Kitchen
 
@@ -347,7 +347,7 @@ The Kitchen Hyper-V driver has updated from 0.5.3 to 0.5.4, which resolves failu
 
 **Kitchen DigitalOcean**
 
-The Kitchen DigitalOcean driver has updated from 0.10.5 to 0.11.0. This release adds slugs for Ubuntu 20.04 / RHEL 8 / Fedora 31 support, increases the the default instance memory size to 1GB, and adds support for VPCs. Thanks [@zmaupin](https://github.com/zmaupin), [@tolland](https://github.com/tolland), and [@gregf](https://github.com/gregf) for these improvements.
+The Kitchen DigitalOcean driver has updated from 0.10.5 to 0.11.0. This release adds slugs for Ubuntu 20.04 / RHEL 8 / Fedora 31 support, increases the default instance memory size to 1GB, and adds support for VPCs. Thanks [@zmaupin](https://github.com/zmaupin), [@tolland](https://github.com/tolland), and [@gregf](https://github.com/gregf) for these improvements.
 
 **Kitchen EC2**
 
@@ -359,7 +359,7 @@ The Kitchen InSpec verifier has updated to allow setting Chef InSpec plugins for
 
 **Kitchen Dokken**
 
-The Kitchen Dokken driver has updated from 2.8.1 to 2.9.0. This release adds a new provisioning configuration, `clean_dokken_sandbox`, that does not require cleaning the Chef Infra and Test Kitchen files between converges. This configuration will speed up repeatedly converging systems. This defaults to `true` which maintains the existing behavior. Thanks [@chrisUsick](https://github.com/chrisUsick).
+The Kitchen Dokken driver has updated from 2.8.1 to 2.9.0. This release adds a new provisioning configuration, `clean_dokken_sandbox`, that doesn't require cleaning the Chef Infra and Test Kitchen files between converges. This configuration will speed up repeatedly converging systems. This defaults to `true` which maintains the existing behavior. Thanks [@chrisUsick](https://github.com/chrisUsick).
 
 #### Knife Plugins
 
@@ -407,7 +407,7 @@ libarchive has updated from 3.4.0 to 3.4.2 to resolve multiple security vulnerab
 
 **OpenSSL**
 
-openSSL has updated from 1.0.2u to 1.0.2v, which does not address any particular CVEs, but includes multiple security hardening updates.
+openSSL has updated from 1.0.2u to 1.0.2v, which doesn't address any particular CVEs, but includes multiple security hardening updates.
 
 **Rake**
 
@@ -452,7 +452,7 @@ AllCops:
 
 Cookstyle now includes two new Chef cop departments with a large number of existing cops moved into these more appropriate departments. Our goal is to have clearly defined cop departments that can be enabled or disabled to detect particular conditions in your cookbooks. Cops in the new ChefSharing department are focused around sharing cookbooks internally or on the public Supermarket. This includes things like ensuring proper license strings and complete metadata. Cops in the ChefRedundantCode category detect and correct unnecessary cookbook code. Anything detected by ChefRedundantCode cops can be removed regardless of the Chef Infra Client release you run in your infrastructure, so these are always safe to run.
 
-With the addition of these new departments, we have moved many cops out of the ChefCorrectness department. Going forward only cops that detect code that may fail a Chef Infra Client run or cause it to behave incorrectly will be included in this category. We hope that ChefCorrectness along with ChefDeprecations are used in most cookbook CI pipelines.
+With the addition of these new departments, we've moved many cops out of the ChefCorrectness department. Going forward only cops that detect code that may fail a Chef Infra Client run or cause it to behave incorrectly will be included in this category. We hope that ChefCorrectness along with ChefDeprecations are used in most cookbook CI pipelines.
 
 #### kitchen-azurerm
 
@@ -564,7 +564,7 @@ AllCops:
 
 Cookstyle now includes two new Chef cop departments with a large number of existing cops moved into these more appropriate departments. Our goal is to have clearly defined cop departments that can be enabled or disabled to detect particular conditions in your cookbooks. Cops in the new ChefSharing department are focused around sharing cookbooks internally or on the public Supermarket. This includes things like ensuring proper license strings and complete metadata. Cops in the ChefRedundantCode category detect and correct unnecessary cookbook code. Anything detected by ChefRedundantCode cops can be removed regardless of the Chef Infra Client release you run in your infrastructure, so these are always safe to run.
 
-With the addition of these new departments, we have moved many cops out of the ChefCorrectness department. Going forward only cops that detect code that may fail a Chef Infra Client run or cause it to behave incorrectly will be included in this category. We hope that ChefCorrectness along with ChefDeprecations are used in most cookbook CI pipelines.
+With the addition of these new departments, we've moved many cops out of the ChefCorrectness department. Going forward only cops that detect code that may fail a Chef Infra Client run or cause it to behave incorrectly will be included in this category. We hope that ChefCorrectness along with ChefDeprecations are used in most cookbook CI pipelines.
 
 #### kitchen-azurerm
 
@@ -651,7 +651,7 @@ resource:
 
 Chef Infra Client now includes a new `chef-utils` gem which ships with a
 large number of helpers to make writing cookbooks easier. Many of these
-helpers existed previously in the `chef-sugar` gem. We have renamed many
+helpers existed previously in the `chef-sugar` gem. We've renamed many
 of the named helpers for consistency while providing backwards
 compatibility with existing `chef-sugar` names. Existing cookbooks
 written with `chef-sugar` should work unmodified with any of these new
@@ -664,12 +664,12 @@ readme](https://github.com/chef/chef/blob/master/chef-utils/README.md).
 
 **Chefignore Improvements**
 
-We have reworked how chefignore files are handled in `knife` which has
+We've reworked how chefignore files are handled in `knife` which has
 allowed us to close out a large number of long outstanding bugs. `knife`
 will now traverse all the way up the directory structure looking for a
 chefignore file. This means you can place a chefignore file in each
 cookbook or any parent directory in your repository structure.
-Additionally, we have made fixes that ensure that commands like
+Additionally, we've made fixes that ensure that commands like
 `knife diff` and `knife cookbook upload` always honor your chefignore
 files.
 
@@ -677,14 +677,14 @@ files.
 
 The new `chef_sleep` resource can be used to sleep for a specified
 number of seconds during a Chef Infra Client run. This may be helpful to
-use with other commands that return a completed status before they are
-actually ready. In general, do not use this resource unless you truly
+use with other commands that return a completed status before they're
+actually ready. In general, don't use this resource unless you truly
 need it.
 
-Using with a Windows service that starts, but is not immediately ready:
+Using with a Windows service that starts, but isn't immediately ready:
 
 > ```ruby
-> service 'Service that is slow to start and reports as started' do
+> service 'Service that's slow to start and reports as started' do
 >   service_name 'my_database'
 >   action :start
 >   notifies :sleep, chef_sleep['wait for service start']
@@ -805,7 +805,7 @@ vulnerabilities:
 
 ### Habitat Packages
 
-We are now publishing Habitat packages for ChefDK 4. See
+We're now publishing Chef Habitat packages for ChefDK 4. See
 [chef/chef-dk](https://bldr.habitat.sh/#/pkgs/chef/chef-dk) on Habitat
 Depot for a complete list of available versions.
 
@@ -826,7 +826,7 @@ changes:
 
 **New Features**
 
-- We have released our beta Chef InSpec plug-in for HashiCorp Vault.
+- We've released our beta Chef InSpec plug-in for HashiCorp Vault.
     Check it out in our [inspec-vault GitHub
     repo](https://github.com/inspec/inspec-vault) and let us know what
     you think -- or better yet, start jumping in and contributing with
@@ -963,7 +963,7 @@ for a complete list of cops included in Cookstyle 5.6.
 
 Going forward, Cookstyle will be our sole Ruby and Chef Infra cookbook
 linting tool. With the release of Cookstyle 5.6, we're officially
-deprecating Foodcritic and will not be shipping Foodcritic in the next
+deprecating Foodcritic and won't be shipping Foodcritic in the next
 major release of Chef Workstation (April 2020). See our [Goodbye,
 Foodcritic blog post](https://blog.chef.io/goodbye-foodcritic/) for more
 information on why Cookstyle is replacing Foodcritic.
@@ -1034,7 +1034,7 @@ coreos-beta-2247-2-0-v20190911   coreos-cloud   coreos-beta    9 GB       READY
 
 Git has been updated from 2.20.0 to 2.23.0 on Windows and from 2.14.1 to
 2.23.0 on non-Windows systems. This brings the latest git workflows to
-our users who do not have it installed another way and fixes two CVEs:
+our users who don't have it installed another way and fixes two CVEs:
 
 - non-Windows systems:
     [CVE-2017-14867](https://www.cvedetails.com/cve/CVE-2017-14867/)
@@ -1093,11 +1093,11 @@ changes:
 
 Cookstyle has been updated from 5.0 to 5.1.19 with twenty-four new Chef
 specific cops to detect, and in many cases, to autocorrect errors in
-your cookbook code. With the release of Cookstyle 5.1, we have started
+your cookbook code. With the release of Cookstyle 5.1, we've started
 the process of replacing Foodcritic with Cookstyle. Cookstyle offers a
 modern configuration system, autocorrection, and a faster and more
 reliable engine thanks to RuboCop. We will continue to port useful rules
-from Foodcritic to Cookstyle, as well as add rules that were not
+from Foodcritic to Cookstyle, as well as add rules that weren't
 possible in the legacy Foodcritic engine. See the [Cookstyle 5.1 Release
 Notes](https://github.com/chef/cookstyle/blob/main/RELEASE_NOTES.md#cookstyle-51)
 for a complete list of new rules.
@@ -1286,7 +1286,7 @@ distros and additional configuration options for instance setup. You can
 now control the default DigitalOcean region systems that are spun up by
 using a new `DIGITALOCEAN_REGION` env var. You can still modify the
 region in the driver section of your `kitchen.yml` file if you'd like,
-and the default region of `nyc1` has not changed. This release also adds
+and the default region of `nyc1` hasn't changed. This release also adds
 slug support for `fedora-29`, `fedora-30`, and `ubuntu-19`. Finally, if
 you'd like to monitor your test instances, the new `monitoring`
 configuration option in the `kitchen.yml` driver section allows enabling
@@ -1366,7 +1366,7 @@ subnet-ba1135c9  available  172.31.16.0/20  us-west-2a  4091           Yes
 ### Platform Support Updates
 
 Ubuntu 14.04 entered the end-of-life phase April 30, 2019. Since this
-version of Ubuntu is now end-of-life, we have stopped building packages
+version of Ubuntu is now end-of-life, we've stopped building packages
 for Ubuntu 14.04. If you rely on Ubuntu 14.04 in your environment, we
 highly recommend upgrading your host to Ubuntu 16.04 or 18.04.
 
@@ -1404,7 +1404,7 @@ change.
 Chef Provisioning is no longer included with ChefDK, and will be
 officially end of life on August 31, 2019. The source code of Chef
 Provisioning and the drivers have been moved into the chef-boneyard
-GitHub organization and will not be further maintained. Current users of
+GitHub organization and won't be further maintained. Current users of
 Chef Provisioning should contact your Chef Customer Success Manager or
 Account Representative to review your options.
 
@@ -1457,7 +1457,7 @@ repositories that match Chef's best practices.
     Infra Client releases as `require_chef_omnibus` will be removed in
     the next major Test Kitchen release.
 - `chef generate cookbook_file` no longer places the specified file
-    in a "default" folder as these are not needed in Chef Infra Client
+    in a "default" folder as these aren't needed in Chef Infra Client
     12 and later.
 - `chef generate repo` no longer outputs the full Chef Infra Client
     run information while generating the repository. Similar to the
@@ -1687,7 +1687,7 @@ shipped in ChefDK 4 have been backported to ChefDK 3.
     Client releases as `require_chef_omnibus` will be removed in the
     next major Test Kitchen release.
 - `chef generate cookbook_file` no longer places the specified file in
-    a `default` folder as these are not needed in Chef Infra Client 12
+    a `default` folder as these aren't needed in Chef Infra Client 12
     and later.
 - `chef generate cookbook` now generates cookbooks with updated
     `.gitignore` and `chefignore` files
@@ -1724,7 +1724,7 @@ distros and additional configuration options for instance setup. You can
 now control the default DigitalOcean region systems that are spun up by
 using a new `DIGITALOCEAN_REGION` environmental variable. You can still
 modify the region in the driver section of your `kitchen.yml` file if
-you'd like, and the default region of `nyc1` has not changed. This
+you'd like, and the default region of `nyc1` hasn't changed. This
 release also adds slug support for `fedora-29`, `fedora-30`, and
 `ubuntu-19`. Finally, if you'd like to monitor your test instances, the
 new `monitoring` configuration option in the `kitchen.yml` driver
@@ -1874,10 +1874,10 @@ non-breaking Test Kitchen 2.0 features:
 
 ### New Policy File Functionality
 
-`include_policy` now supports `:remote` policy files. This new
-functionality allows you to include policy files over http. Remote
-policy files require remote cookbooks and `install` will fail otherwise
-if the included policy file includes cookbooks with paths. Thanks
+`include_policy` now supports `:remote` Policyfiles. This new
+functionality allows you to include Policyfiles over http. Remote
+Policyfiles require remote cookbooks and `install` will fail otherwise
+if the included Policyfile includes cookbooks with paths. Thanks
 [mattray](https://github.com/mattray)!
 
 ### Updated Components
@@ -2004,7 +2004,7 @@ what's new.
 ### Deprecations
 
 Chef Provisioning has been in maintenance mode since 2015 and due to the
-age of its dependencies it cannot be included in ChefDK 4 which is
+age of its dependencies it can't be included in ChefDK 4 which is
 scheduled for an April 2019 release.
 
 ## What's New in 3.6
@@ -2083,7 +2083,7 @@ what's new.
 #### stove 7.0.1
 
 - The yank command has been removed as this command causes large
-    downstream impact to other users and should not be part of the
+    downstream impact to other users and shouldn't be part of the
     tooling
 - The metadata.rb file will now be included in uploads to match the
     behavior of berkshelf 7+
@@ -2194,7 +2194,7 @@ what's new.
 ### Smaller Package Size
 
 ChefDK RPM and Debian packages are now compressed. Additionally many
-gems were updated to remove extraneous files that do not need to be
+gems were updated to remove extraneous files that don't need to be
 included. The download size of packages has decreased accordingly (all
 measurements in megabytes):
 
@@ -2210,9 +2210,9 @@ Chef Downloads.
 
 Ruby has been updated to 2.5.3 to resolve the following vulnerabilities:
 
-- \`CVE-2018-16396\`: Tainted flags are not propagated in Array\#pack
+- \`CVE-2018-16396\`: Tainted flags aren't propagated in Array\#pack
     and String\#unpack with some directives
-- \`CVE-2018-16395\`: OpenSSL::X509::Name equality check does not work
+- \`CVE-2018-16395\`: OpenSSL::X509::Name equality check doesn't work
     correctly
 
 ## What's New in 3.3
@@ -2247,16 +2247,16 @@ for examples of the new syntax.
 
 The Chef CLI now includes a new option: chef
 update --exclude-deps for policyfiles which will only update the
-cookbook(s) given on the command line.
+cookbooks given on the command line.
 
 ### Deprecations
 
-- `chef generate app` - Application repos were a pattern that did not
+- `chef generate app` - Application repos were a pattern that didn't
     take off.
 - `chef generate lwrp` - Use chef generate
     resource. Every supported release of Chef supports custom
     resources. Custom resources are awesome. No one should be writing
-    new LWRPs any more. LWRPS are not awesome.
+    new LWRPs any more. LWRPS aren't awesome.
 
 ## What's New in 3.2
 
@@ -2270,7 +2270,7 @@ cookbook(s) given on the command line.
 
     - New chef describe-cookbook
         command to display the cookbook checksum.
-    - Change policyfile generator to use `policyfiles` directory
+    - Change Policyfile generator to use `policyfiles` directory
         instead of `policies` directory
 
 - **New Tooling**
@@ -2363,7 +2363,7 @@ cookbook(s) given on the command line.
     **Test Kitchen 1.22**
 
     - Added a new `ssh_gateway_port` config.
-    - Fixed a bug on Unix systems where scripts are not created as
+    - Fixed a bug on Unix systems where scripts aren't created as
         executable.
 
 - **Other Updated Components and Tools**
@@ -2512,7 +2512,7 @@ cookbook(s) given on the command line.
 - **Rename smoke tests to integration tests**
 
     The cookbook, recipe, and app generators now name the test directory
-    `integration` instead of `smoke`. This will not impact existing
+    `integration` instead of `smoke`. This won't impact existing
     cookbooks generated with older releases of ChefDK, but it does
     simplify the `.kitchen.yml` configuration for all new cookbooks.
 
@@ -2593,12 +2593,12 @@ cookbook(s) given on the command line.
 
     Policyfile can use the `include_policy` directive as described in
     [RFC097](https://github.com/chef/chef-rfc/blob/master/rfc097-policyfile-includes.md).
-    This directive's purpose is to allow the inclusion policyfile locks
+    This directive's purpose is to allow the inclusion Policyfile locks
     to the current policyfile. In this iteration, we support sourcing
     lock files from a local path or a Chef server. Below is a simple
     example of how the `include_policy` directive can be used:
 
-    Given a policyfile `base.rb`:
+    Given a Policyfile `base.rb`:
 
     ```ruby
     name 'base'
@@ -2657,7 +2657,7 @@ cookbook(s) given on the command line.
     ```
 
     This will produce a `users.lock.json` file that has the `base`
-    policyfile lock merged in.
+    Policyfile lock merged in.
 
     More information can be found in
     [RFC097](https://github.com/chef/chef-rfc/blob/main/rfc097-policyfile-includes.md)
@@ -2665,7 +2665,7 @@ cookbook(s) given on the command line.
 
 - **New tools bundled**
 
-    We are now shipping these tools as part of ChefDK:
+    We're now shipping these tools as part of ChefDK:
 
     - [kitchen-digitalocean](https://github.com/test-kitchen/kitchen-digitalocean)
     - [kitchen-google](https://github.com/test-kitchen/kitchen-google)
@@ -2777,11 +2777,11 @@ Chef 2.0.28 fixes an
 ### Chef Infra Client 13.2
 
 Chef Infra Client 13 is the most delightful version of Chef Infra Client available.
-We have taken what we have learned from many bug reports, forum posts, and
-conversations with our users, and we have made it safer and easier than
-ever to write great cookbooks. We have also included a number of new
+We've taken what we've learned from many bug reports, forum posts, and
+conversations with our users, and we've made it safer and easier than
+ever to write great cookbooks. We've also included a number of new
 resources that better support our most popular operating systems, and
-we have made it easier to write patterns that result in reusable,
+we've made it easier to write patterns that result in reusable,
 efficient code.
 
 Chef Infra Client 13.2 solves a number of issues that were reported in our
@@ -2810,9 +2810,9 @@ Berkshelf adds support for two new sources:
 ### Chef Vault 3.1
 
 Chef Vault 3.1 includes a number of optimizations for large numbers of
-nodes. In most situations, we have seen at least 50% faster creation,
+nodes. In most situations, we've seen at least 50% faster creation,
 update, and refresh operations, and much more efficient memory usage.
-We have also added a new `sparse` mode, which dramatically reduces the
+We've also added a new `sparse` mode, which dramatically reduces the
 amount of network traffic that occurs as nodes decrypt vaults. A lot of
 the scalability work has been built and tested by our friends at Criteo.
 
@@ -2831,8 +2831,8 @@ every version of Chef.
 
 The release of Foodcritic 11 also marks the creation of the Foodcritic
 org on [GitHub](https://github.com/foodcritic), which makes it easier to
-get involved in writing rules and contributing code. We are excited to
-start building more of a community around Foodcritic, and cannot wait to
+get involved in writing rules and contributing code. We're excited to
+start building more of a community around Foodcritic, and can't wait to
 see what the community cooks up.
 
 ### InSpec 1.30
@@ -2925,7 +2925,7 @@ longer depend on the delivery_build or delivery-base cookbook. Instead,
 the Test Kitchen instance will use ChefDK as the standard workflow
 runner setup.
 
-The build cookbook generator will not overwrite your `config.json` or
+The build cookbook generator won't overwrite your `config.json` or
 `project.toml` if they exist already on your project.
 
 ### ChefSpec 6.0
@@ -3030,7 +3030,7 @@ standard license strings.
     - An optional `functional` phase.
     - New `remote_file` option to specify a remote `project.toml`.
     - The ability to run stages (collection of phases).
-- Fixed bug where the generated `project.toml` file did not include
+- Fixed bug where the generated `project.toml` file didn't include
     the prefix chef exec for some phases.
 - Project git remotes will now update automatically, if applicable,
     based on the values in the `cli.toml` or options provided through
@@ -3143,7 +3143,7 @@ previously passed.
 
 ### New DCO tool included
 
-We have included a new DCO command-line tool that makes it easier to
+We've included a new DCO command-line tool that makes it easier to
 contribute to projects like Chef that use the Developer Certificate of
 Origin. The tool allows you to enable/disable DCO sign-offs for each
 repository and also allows you to retroactively sign off all commits on
@@ -3166,8 +3166,8 @@ a branch. See  for details.
 ### Version 1.0!
 
 We're recognizing ChefDK's continued stability with the honor of a 1.0
-tag. There is nothing in this release that breaks backwards
-compatibility with previous installations of ChefDK: it is simply a
+tag. There isn'thing in this release that breaks backwards
+compatibility with previous installations of ChefDK: it's simply a
 formal recognition of the stability of the product.
 
 ### Foodcritic
diff --git a/content/resource.md b/content/resource.md
index 2f0e806c86..bf2cea723f 100644
--- a/content/resource.md
+++ b/content/resource.md
@@ -35,7 +35,7 @@ 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 is used to install a tar.gz package for
+For example, a resource that's used to install a tar.gz package for
 version 1.16.1 may look something like this:
 
 ```ruby
@@ -48,7 +48,7 @@ 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 is possible to
+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:
 
@@ -90,7 +90,7 @@ See these guides for additional information about resources:
 
 
 Resource Reference
-A reference guide that lists both the common and individual options available to every resource that is bundled into Chef.
+A reference guide that lists both the common and individual options available to every resource that's bundled into Chef.
 
 
 Custom Resources
diff --git a/content/resource_common.md b/content/resource_common.md
index cce421e10f..84f333a177 100644
--- a/content/resource_common.md
+++ b/content/resource_common.md
@@ -83,7 +83,7 @@ end
 **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 is the same
+the `apt-get-update` command when a file already exists that's the same
 as the updated file:
 
 ```ruby
@@ -98,7 +98,7 @@ end
 
 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 cannot resolve the
+host, Chef Infra Client will don'thing. If the node can't resolve the
 host, Chef Infra Client will configure the host:
 
 ```ruby
@@ -117,7 +117,7 @@ end
 
 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 is older than version 6.0:
+version of Red Hat Enterprise Linux that's older than version 6.0:
 
 ```ruby
 ark 'test_autogen' do
@@ -154,7 +154,7 @@ necessary. In this case, three attributes exist in the
 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.
+already present, Chef Infra Client will don'thing.
 
 ```ruby
 package 'libpcre3-dev' do
@@ -185,7 +185,7 @@ ruby_block 'remove ntp::undo from run list' do
 end
 ```
 
-**Re-register ASP.Net if it is already installed**
+**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
diff --git a/content/resources/_index.md b/content/resources/_index.md
index af22a30076..076013ea2b 100644
--- a/content/resources/_index.md
+++ b/content/resources/_index.md
@@ -70,7 +70,7 @@ The following properties are common to every resource:
 `sensitive`
 : **Ruby Type:** true, false | **Default Value:** `false`
 
-  Ensure that sensitive resource data is not logged by Chef Infra Client.
+  Ensure that sensitive resource data isn't logged by Chef Infra Client.
 
 #### Examples
 
@@ -175,7 +175,7 @@ template '/tmp/somefile' do
 end
 ```
 
-**Create a file with a Ruby block, but only if "/etc/passwd" does not exist**
+**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:
diff --git a/content/reusable/md/EOL_manage.md b/content/reusable/md/EOL_manage.md
index ff89a07912..059053044b 100644
--- a/content/reusable/md/EOL_manage.md
+++ b/content/reusable/md/EOL_manage.md
@@ -1,5 +1,5 @@
 Chef Manage is [deprecated](/versions/#deprecated-products-and-versions) and no
-longer under active development. It is supported on Chef Automate installations
+longer under active development. It's supported on Chef Automate installations
 up to version 1.8 and replaced by Chef Automate 2.0. Contact your Chef account
 representative for information about upgrading your system. See our
 [Automate documentation](/automate/) to learn more about
diff --git a/content/reusable/md/chef_client_bootstrap_node.md b/content/reusable/md/chef_client_bootstrap_node.md
index 80538f8b5c..20621d34ab 100644
--- a/content/reusable/md/chef_client_bootstrap_node.md
+++ b/content/reusable/md/chef_client_bootstrap_node.md
@@ -1,4 +1,4 @@
-A node is any physical, virtual, or cloud device that is configured and
+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
diff --git a/content/reusable/md/chef_client_bootstrap_stages.md b/content/reusable/md/chef_client_bootstrap_stages.md
index b4a2ffdb72..45b8dbc564 100644
--- a/content/reusable/md/chef_client_bootstrap_stages.md
+++ b/content/reusable/md/chef_client_bootstrap_stages.md
@@ -39,7 +39,7 @@ During a `knife bootstrap` bootstrap operation, the following happens:
 
 
Start a Chef Infra Client run

 
On UNIX and Linux-based machines: The second shell script executes the chef-client binary with a set of initial settings stored within first-boot.json on the node. first-boot.json is generated from the workstation as part of the initial knife bootstrap subcommand.

-
On Windows machines: The batch file that is derived from the windows-chef-client-msi.erb bootstrap template executes the chef-client binary with a set of initial settings stored within first-boot.json on the node. first-boot.json is generated from the workstation as part of the initial knife bootstrap subcommand.

+
On Windows machines: The batch file that's derived from the windows-chef-client-msi.erb bootstrap template executes the chef-client binary with a set of initial settings stored within first-boot.json on the node. first-boot.json is generated from the workstation as part of the initial knife bootstrap subcommand.

 
 
 
Complete a Chef Infra Client run

diff --git a/content/reusable/md/chef_client_run.md b/content/reusable/md/chef_client_run.md
index f214c660c3..908be53b7e 100644
--- a/content/reusable/md/chef_client_run.md
+++ b/content/reusable/md/chef_client_run.md
@@ -21,7 +21,7 @@ During every Chef Infra Client run, the following happens:
 
 
 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 is typically the FQDN for the node, which is always unique within an organization.
+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 the Chef Infra Server
@@ -29,7 +29,7 @@ During every Chef Infra Client run, the following happens:
 
 
 Get, rebuild the node object
-Chef Infra Client pulls down the node object from the 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 has not yet had a Chef Infra Client run will not 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.
+Chef Infra Client pulls down the node object from the 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
@@ -66,7 +66,7 @@ During every Chef Infra Client run, the following happens:
 
 
 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 is asked to 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
index 4412524cdc..189a4b04e7 100644
--- a/content/reusable/md/chef_client_summary.md
+++ b/content/reusable/md/chef_client_summary.md
@@ -1,4 +1,4 @@
-Chef Infra Client is an agent that runs locally on every node that is 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:
+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 the Chef Infra Server to the node
diff --git a/content/reusable/md/chef_shell_advanced_debug.md b/content/reusable/md/chef_shell_advanced_debug.md
index 3227133c1a..992e65b55c 100644
--- a/content/reusable/md/chef_shell_advanced_debug.md
+++ b/content/reusable/md/chef_shell_advanced_debug.md
@@ -1,4 +1,4 @@
-In chef-shell, it is possible to get verbose debugging using the tracing
+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:
 
diff --git a/content/reusable/md/chef_shell_debug_existing_recipe.md b/content/reusable/md/chef_shell_debug_existing_recipe.md
index ea60cb5af2..4485d749e4 100644
--- a/content/reusable/md/chef_shell_debug_existing_recipe.md
+++ b/content/reusable/md/chef_shell_debug_existing_recipe.md
@@ -1,7 +1,7 @@
 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 is cached when
+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 is started:
+which recipes are being cached when it's started:
 
 ```bash
 loading configuration: none (standalone session)
diff --git a/content/reusable/md/chef_shell_manage.md b/content/reusable/md/chef_shell_manage.md
index 6a7bd78c4b..90e19943b9 100644
--- a/content/reusable/md/chef_shell_manage.md
+++ b/content/reusable/md/chef_shell_manage.md
@@ -49,7 +49,7 @@ Which will return something similar to:
 ```
 
 The `list` command can take a code block, which will applied (but not
-saved), to each object that is returned from the server. For example:
+saved), to each object that's returned from the server. For example:
 
 ```bash
 chef (preprod) > nodes.list {|n| puts "#{n.name}: #{n.run_list}" }
diff --git a/content/reusable/md/chef_shell_modes.md b/content/reusable/md/chef_shell_modes.md
index bb0df84fae..b75e088564 100644
--- a/content/reusable/md/chef_shell_modes.md
+++ b/content/reusable/md/chef_shell_modes.md
@@ -1,4 +1,4 @@
-chef-shell is tool that is run using an Interactive Ruby (IRb) session.
+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:
 
diff --git a/content/reusable/md/chef_shell_run_as_chef_client.md b/content/reusable/md/chef_shell_run_as_chef_client.md
index 2bf3ccfb65..e67f49d3ce 100644
--- a/content/reusable/md/chef_shell_run_as_chef_client.md
+++ b/content/reusable/md/chef_shell_run_as_chef_client.md
@@ -1,6 +1,6 @@
-By default, chef-shell loads in standalone mode and does not connect to
+By default, chef-shell loads in standalone mode and doesn't connect to
 the Chef Infra Server. The chef-shell can be run as a Chef Infra Client
-to verify functionality that is only available when Chef Infra Client
+to verify functionality that's only available when Chef Infra Client
 connects to the Chef Infra Server, such as search functionality or
 accessing data stored in data bags.
 
diff --git a/content/reusable/md/chef_shell_step_through_run_list.md b/content/reusable/md/chef_shell_step_through_run_list.md
index 7715b3088b..4cc6e3170e 100644
--- a/content/reusable/md/chef_shell_step_through_run_list.md
+++ b/content/reusable/md/chef_shell_step_through_run_list.md
@@ -43,7 +43,7 @@ before-breakpoint
 You can rewind and step through a Chef Infra Client run:
 
 ```bash
-chef:recipe > Chef::Log.level = :debug # debug logging will not turn on automatically in this case
+chef:recipe > Chef::Log.level = :debug # debug logging won't turn on automatically in this case
     => :debug
   chef:recipe > chef_run.rewind
     => 0
diff --git a/content/reusable/md/chef_solo_summary.md b/content/reusable/md/chef_solo_summary.md
index 5bea12eef6..080ea1e697 100644
--- a/content/reusable/md/chef_solo_summary.md
+++ b/content/reusable/md/chef_solo_summary.md
@@ -1,7 +1,7 @@
 chef-solo is a command that executes Chef Infra Client in a way that
-does not require the Chef Infra Server to converge cookbooks.
+doesn't require the 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 **does not support**
+mode](/ctl_chef_client.html#run-in-local-mode), and **doesn't support**
 the following functionality present in Chef Infra Client / server
 configurations:
 
diff --git a/content/reusable/md/config_rb_client_summary.md b/content/reusable/md/config_rb_client_summary.md
index 8d7bf87ebb..a74f955b30 100644
--- a/content/reusable/md/config_rb_client_summary.md
+++ b/content/reusable/md/config_rb_client_summary.md
@@ -6,4 +6,4 @@ The `client.rb` file configures Chef Infra Client on a node and has the followin
     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 is not created by default
+- This file isn't created by default
diff --git a/content/reusable/md/cookbook_file_specificity.md b/content/reusable/md/cookbook_file_specificity.md
index 7c9e15d021..9ee7b22b26 100644
--- a/content/reusable/md/cookbook_file_specificity.md
+++ b/content/reusable/md/cookbook_file_specificity.md
@@ -61,7 +61,7 @@ end
 ```
 
 This resource is matched in the same order as the `/files` directory
-structure. For a node that is running Ubuntu 20.04, the second item
+structure. For a node that's running Ubuntu 20.04, the second item
 would be the matching item and the location to which the file identified
 in the **cookbook_file** resource would be distributed:
 
@@ -75,7 +75,7 @@ default/apache2_module_conf_generate.pl
 
 If the `apache2_module_conf_generate.pl` file was located in the
 cookbook directory under `files/host-foo.example.com/`, the specified
-file(s) would only be copied to the machine with the domain name
+files would only be copied to the machine with the domain name
 foo.example.com.
 
 
diff --git a/content/reusable/md/cookbooks_recipe.md b/content/reusable/md/cookbooks_recipe.md
index c6654da810..02304ee8a2 100644
--- a/content/reusable/md/cookbooks_recipe.md
+++ b/content/reusable/md/cookbooks_recipe.md
@@ -3,7 +3,7 @@ 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 is required to configure part of a system
+- 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)
diff --git a/content/reusable/md/cookbooks_summary.md b/content/reusable/md/cookbooks_summary.md
index b27fa1c5d0..985690f48d 100644
--- a/content/reusable/md/cookbooks_summary.md
+++ b/content/reusable/md/cookbooks_summary.md
@@ -1,8 +1,8 @@
 A cookbook is the fundamental unit of configuration and policy distribution in Chef Infra.
 
-A cookbook defines a scenario and contains everything that is required to support that scenario:
+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 are to be applied
+- 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.
diff --git a/content/reusable/md/cookbooks_version.md b/content/reusable/md/cookbooks_version.md
index 7d1b8f4e5d..3996f4405e 100644
--- a/content/reusable/md/cookbooks_version.md
+++ b/content/reusable/md/cookbooks_version.md
@@ -1,5 +1,5 @@
-A cookbook version represents a set of functionality that is different
-from the cookbook on which it is based. A version may exist for many
+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,
diff --git a/content/reusable/md/data_bag_encryption.md b/content/reusable/md/data_bag_encryption.md
index c95e60e8d3..3655efd81b 100644
--- a/content/reusable/md/data_bag_encryption.md
+++ b/content/reusable/md/data_bag_encryption.md
@@ -4,7 +4,7 @@ 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 are not required to share the same
+data bag items, these data bag items aren't required to share the same
 encryption keys.
 
 
@@ -13,9 +13,9 @@ encryption keys.
 
Note

 

 
-Because the contents of encrypted data bag items are not visible to the
+Because the contents of encrypted data bag items aren't visible to the
 Chef Infra Server, search queries against data bags with encrypted items
-will not return any results.
+won't return any results.
diff --git a/content/reusable/md/dsl_handler_event_types.md b/content/reusable/md/dsl_handler_event_types.md index 5daf7aac47..22db1b3403 100644 --- a/content/reusable/md/dsl_handler_event_types.md +++ b/content/reusable/md/dsl_handler_event_types.md @@ -24,7 +24,7 @@ method block by declaring it as the event type. `:skipping_registration` -: The Chef Infra Client is not registering with the Chef Infra Server because it already has a private key or because it does not need one. +: The Chef Infra Client isn't registering with the Chef Infra Server because it already has a private key or because it doesn't need one. `:registration_start` @@ -56,11 +56,11 @@ method block by declaring it as the event type. `:node_load_completed` -: The Chef Infra Client successfully loaded node data from the Chef Infra Server. Default and override attributes for roles have been computed, but are not yet applied. +: The Chef Infra Client successfully loaded node data from the Chef Infra Server. Default and override attributes for roles have been computed, but aren't yet applied. `:policyfile_loaded` -: The policy file was loaded. +: The Policyfile was loaded. `:cookbook_resolution_start` @@ -280,11 +280,11 @@ method block by declaring it as the event type. `:resource_current_state_load_bypassed` -: A resource's current state was not loaded because the resource does not support why-run mode. +: 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 does not support why-run mode. +: A resource action was skipped because the resource doesn't support why-run mode. `:resource_update_applied` @@ -300,7 +300,7 @@ method block by declaring it as the event type. `:resource_failed` -: A resource action has failed and will not be retried. +: A resource action has failed and won't be retried. `:resource_updated` diff --git a/content/reusable/md/dsl_handler_slide_send_email_handler.md b/content/reusable/md/dsl_handler_slide_send_email_handler.md index 5b5ac31a7f..d5e2175a52 100644 --- a/content/reusable/md/dsl_handler_slide_send_email_handler.md +++ b/content/reusable/md/dsl_handler_slide_send_email_handler.md @@ -14,4 +14,4 @@ end - Use the `on` method to specify the event type Within the `on` block, tell Chef Infra Client how to handle the event -when it is triggered. +when it's triggered. diff --git a/content/reusable/md/fips_intro_client.md b/content/reusable/md/fips_intro_client.md index 3eb017f923..6530cb717e 100644 --- a/content/reusable/md/fips_intro_client.md +++ b/content/reusable/md/fips_intro_client.md @@ -3,7 +3,7 @@ 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 is explicitly disallowed in +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. @@ -16,7 +16,7 @@ Chef Infra Client to throw an exception during a Chef Infra Client run. 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 is not used for any cryptographic purpose. +and isn't used for any cryptographic purpose. diff --git a/content/reusable/md/handler_type_start.md b/content/reusable/md/handler_type_start.md index 20a0dec420..d8eecd40f8 100644 --- a/content/reusable/md/handler_type_start.md +++ b/content/reusable/md/handler_type_start.md @@ -1,4 +1,4 @@ -A start handler is not loaded into a Chef Infra Client run from a +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 @@ -9,7 +9,7 @@ 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 is available to Chef + 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/infra_lang_method_registry_value_exists_syntax.md b/content/reusable/md/infra_lang_method_registry_value_exists_syntax.md index 1592b9c7c5..7d45a7a7e7 100644 --- a/content/reusable/md/infra_lang_method_registry_value_exists_syntax.md +++ b/content/reusable/md/infra_lang_method_registry_value_exists_syntax.md @@ -19,7 +19,7 @@ where: `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 are ignored + 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 diff --git a/content/reusable/md/infra_lang_summary.md b/content/reusable/md/infra_lang_summary.md index a147a682f6..8cf352b8ef 100644 --- a/content/reusable/md/infra_lang_summary.md +++ b/content/reusable/md/infra_lang_summary.md @@ -1 +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 action(s) 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. +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 index 6502d18a16..0b807a0735 100644 --- a/content/reusable/md/install_chef_client.md +++ b/content/reusable/md/install_chef_client.md @@ -10,7 +10,7 @@ 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 will not interfere with other +(`/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/libraries_summary.md b/content/reusable/md/libraries_summary.md index bcb802116e..c31b8fbc97 100644 --- a/content/reusable/md/libraries_summary.md +++ b/content/reusable/md/libraries_summary.md @@ -1,7 +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 is located within a cookbook's `/libraries` directory. Because a +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/node.md b/content/reusable/md/node.md index 7d0b8843a2..51234295ac 100644 --- a/content/reusable/md/node.md +++ b/content/reusable/md/node.md @@ -1,2 +1,2 @@ A node is any device---physical, virtual, cloud, network device, -etc.---that is under management by Chef Infra. +etc.---that's under management by Chef Infra. diff --git a/content/reusable/md/node_attribute.md b/content/reusable/md/node_attribute.md index 8d745ad376..2bccdf5f19 100644 --- a/content/reusable/md/node_attribute.md +++ b/content/reusable/md/node_attribute.md @@ -16,7 +16,7 @@ During every Chef Infra Client run, Chef Infra Client builds the attribute list - Attributes passed using JSON on the command line - Data about the node collected by [Ohai](/ohai.html). - The node object that was saved to the 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 is 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. +- 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 the 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 index f004668ba7..8da8fb9e38 100644 --- a/content/reusable/md/node_attribute_allowlist.md +++ b/content/reusable/md/node_attribute_allowlist.md @@ -22,7 +22,7 @@ Attributes are allowlisted by attribute type, with each attribute type being all #### 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 the 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 are omitted from an allowlist incorrectly. +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 the 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: @@ -51,7 +51,7 @@ To allowlist the `network` attributes and prevent the other attributes from bein allowed_automatic_attributes ['network/interfaces/'] ``` -When a allowlist is defined, any attribute of that type that is not specified in that attribute allowlist **will not** be saved. So based on the previous allowlist for automatic attributes, the `filesystem` and `map - autohome` attributes will not be saved, but the `network` attributes will. +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: diff --git a/content/reusable/md/node_attribute_allowlist_warning.md b/content/reusable/md/node_attribute_allowlist_warning.md index 3473aa78c1..29881cf8e4 100644 --- a/content/reusable/md/node_attribute_allowlist_warning.md +++ b/content/reusable/md/node_attribute_allowlist_warning.md @@ -1,2 +1,2 @@ -When attribute allowlist settings are used, only the attributes defined in a allowlist will be saved and any attribute that is not defined in a allowlist will not 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` are not defined, then all normal attributes, default attributes, and override attributes are saved, as well as the automatic attributes that were specifically included through allowlisting. +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_warning.md b/content/reusable/md/node_attribute_blocklist_warning.md index 9855ca8af8..04813c5a89 100644 --- a/content/reusable/md/node_attribute_blocklist_warning.md +++ b/content/reusable/md/node_attribute_blocklist_warning.md @@ -1 +1 @@ -When attribute blocklist settings are used, any attribute defined in a blocklist will not be saved to the Chef Infra Server and any attribute that is not 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 will not be saved, but `blocked_normal_attributes`, `blocked_default_attributes`, and `blocked_override_attributes` are not defined, then all normal attributes, default attributes, and override attributes will be saved, as well as the automatic attributes that were not specifically excluded through blocklisting. +When attribute blocklist settings are used, any attribute defined in a blocklist won't be saved to the 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 index 2eeb2ce9b4..fb6f40ae87 100644 --- a/content/reusable/md/node_attribute_type_automatic.md +++ b/content/reusable/md/node_attribute_type_automatic.md @@ -1,3 +1,3 @@ -An `automatic` attribute contains data that is identified by Ohai at the +An `automatic` attribute contains data that's identified by Ohai at the beginning of every Chef Infra Client run. An `automatic` attribute -cannot be modified and always has the highest attribute precedence. +can't be modified and always has the highest attribute precedence. diff --git a/content/reusable/md/node_ctl_attribute.md b/content/reusable/md/node_ctl_attribute.md index 88931fd123..44f4581333 100644 --- a/content/reusable/md/node_ctl_attribute.md +++ b/content/reusable/md/node_ctl_attribute.md @@ -1,6 +1,6 @@ -Any other attribute type that is contained in this JSON file will be +Any other attribute type that's contained in this JSON file will be treated as a `normal` attribute. Setting attributes at other precedence -levels is not possible. For example, attempting to update `override` +levels isn't possible. For example, attempting to update `override` attributes using the `-j` option: ```json diff --git a/content/reusable/md/node_run_list.md b/content/reusable/md/node_run_list.md index c8230b9135..b47872f2ca 100644 --- a/content/reusable/md/node_run_list.md +++ b/content/reusable/md/node_run_list.md @@ -3,9 +3,9 @@ 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 will not run it twice + 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 is identical to the run-list used by other nodes + run-list that's identical to the run-list used by other nodes - Stored as part of the node object on the Chef 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_types.md b/content/reusable/md/node_types.md index f41e51e4aa..15e1702d52 100644 --- a/content/reusable/md/node_types.md +++ b/content/reusable/md/node_types.md @@ -1,4 +1,4 @@ -The types of nodes that can be managed by Chef include, but are not +The types of nodes that can be managed by Chef include, but aren't limited to, the following: 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 index 5da2d3f003..9934277c1e 100644 --- a/content/reusable/md/notes_registry_key_not_if_only_if.md +++ b/content/reusable/md/notes_registry_key_not_if_only_if.md @@ -1,4 +1,4 @@ This method can be used in recipes and from within the `not_if` and -`only_if` blocks in resources. This method is not designed to create or +`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_resource_based_on_package.md b/content/reusable/md/notes_resource_based_on_package.md index 159b9c4f58..65f1f0f0ae 100644 --- a/content/reusable/md/notes_resource_based_on_package.md +++ b/content/reusable/md/notes_resource_based_on_package.md @@ -1,4 +1,4 @@ -In many cases, it is better to use the **package** resource instead of +In many cases, it's better to use the **package** resource instead of this one. This is because when the **package** resource is used in a recipe, Chef Infra Client will use details that are collected by Ohai at the start of a Chef Infra Client run to determine the correct package diff --git a/content/reusable/md/ohai_automatic_attribute.md b/content/reusable/md/ohai_automatic_attribute.md index 8fefc9fdf3..b05e89e531 100644 --- a/content/reusable/md/ohai_automatic_attribute.md +++ b/content/reusable/md/ohai_automatic_attribute.md @@ -1,7 +1,7 @@ An automatic attribute is a specific detail about a node, such as an IP -address, a host name, a list of loaded kernel modules, and so on. +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 are handled properly during every Chef +Infra Client to ensure that they're handled properly during every Chef Infra Client run. The most commonly accessed automatic attributes are: @@ -30,7 +30,7 @@ Infra Client run. The most commonly accessed automatic attributes are: - + @@ -58,7 +58,7 @@ Infra Client run. The most commonly accessed automatic attributes are: - +
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 does not have a default route, the value for this attribute should be nil. The IP address for default route is the recommended default value.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']
node['ohai_time']The time at which Ohai was last run. This attribute is not commonly used in recipes, but it is saved to the Chef Infra Server and can be accessed using the knife status subcommand.The time at which Ohai was last run. This attribute isn't commonly used in recipes, but it's saved to the 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 index 8b64b6224e..4fa11884e4 100644 --- a/content/reusable/md/ohai_summary.md +++ b/content/reusable/md/ohai_summary.md @@ -1,6 +1,6 @@ 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 are not limited to: +The types of attributes Ohai collects include but aren't limited to: - Operating System - Network diff --git a/content/reusable/md/plugin_knife_summary.md b/content/reusable/md/plugin_knife_summary.md index 942da18f4b..c03b482d4f 100644 --- a/content/reusable/md/plugin_knife_summary.md +++ b/content/reusable/md/plugin_knife_summary.md @@ -1,5 +1,5 @@ A knife plugin is a set of one (or more) subcommands that can be added -to knife to support additional functionality that is not built-in to the +to knife to support additional functionality that isn't built-in to the base set of knife subcommands. Many of the knife plugins are built by members of the Chef community and several of them are built and maintained by Chef. diff --git a/content/reusable/md/policyfile_lock_json.md b/content/reusable/md/policyfile_lock_json.md index 08a48aee9b..1a36e30a49 100644 --- a/content/reusable/md/policyfile_lock_json.md +++ b/content/reusable/md/policyfile_lock_json.md @@ -8,5 +8,5 @@ describes: - Attributes included with the Policyfile A `Policyfile.lock.json` file is associated with a specific policy -group, which means it is associated with one (or more) nodes that use the same +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_rb.md b/content/reusable/md/policyfile_rb.md index c9ffb92c7d..8d56ae2a32 100644 --- a/content/reusable/md/policyfile_rb.md +++ b/content/reusable/md/policyfile_rb.md @@ -1,6 +1,6 @@ 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 the Chef Infra Server, where it is +Policyfile file is uploaded to the 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 diff --git a/content/reusable/md/policyfile_rb_settings.md b/content/reusable/md/policyfile_rb_settings.md index 496982b6c7..f1c4ed7a1e 100644 --- a/content/reusable/md/policyfile_rb_settings.md +++ b/content/reusable/md/policyfile_rb_settings.md @@ -6,7 +6,7 @@ A `Policyfile.rb` file may contain the following settings: : 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", "load balancer", and so on. + such as _application server_, _chat server_, or _load balancer_. `run_list "ITEM", "ITEM", ...` @@ -71,12 +71,12 @@ A `Policyfile.rb` file may contain the following settings:

Note

- If a run-list or any dependencies require a cookbook that is present + 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 is maintained by Chef. To specify a named source for a + that's maintained by Chef. To specify a named source for a cookbook: ```ruby @@ -149,50 +149,50 @@ A `Policyfile.rb` file may contain the following settings: `include_policy "NAME", *args` -: Specify a policyfile lock to be merged with this policy. Chef +: 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 + 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`: + Pull the Policyfile lock from `./NAME.lock.json`: ```ruby include_policy 'NAME', path: '.' ``` - Pull the policyfile lock from `./foo.lock.json`. + 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. + 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 + 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 + 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 + Pull the Policyfile lock from a remote server `https://internal.example.com/bar.lock.json` and with revision ID 'revision1'. diff --git a/content/reusable/md/policyfile_summary.md b/content/reusable/md/policyfile_summary.md index 7130fe4e8d..a61bde1dc2 100644 --- a/content/reusable/md/policyfile_summary.md +++ b/content/reusable/md/policyfile_summary.md @@ -1 +1 @@ -A Policyfile is a way to create immutable collections of cookbooks, cookbook dependencies, and attributes defined in a single document that is uploaded to the 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. +A Policyfile is a way to create immutable collections of cookbooks, cookbook dependencies, and attributes defined in a single document that's uploaded to the 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/release_channels.md b/content/reusable/md/release_channels.md index ed3da0fa65..cb0a5f1d0b 100644 --- a/content/reusable/md/release_channels.md +++ b/content/reusable/md/release_channels.md @@ -3,6 +3,6 @@ Chef releases packages from the following release channels: | Channel | Description | |--- |--- | | `stable` | A build from this channel is an "official" release that has passed full user acceptance testing. Artifacts in this channel are retained indefinitely. | -| `current`| A build from this channel is an "integration" build that has passed full testing, but has not been officially released. Artifacts in this channel are retained for 30 days and then removed automatically. | +| `current`| A build from this channel is an "integration" build that has passed full testing, but hasn't been officially released. Artifacts in this channel are retained for 30 days and then removed automatically. | Use the stable channel when installing Chef products on production systems. diff --git a/content/reusable/md/remote_directory_recursive_directories.md b/content/reusable/md/remote_directory_recursive_directories.md index 506149a957..ce931574a8 100644 --- a/content/reusable/md/remote_directory_recursive_directories.md +++ b/content/reusable/md/remote_directory_recursive_directories.md @@ -1,6 +1,6 @@ The **remote_directory** resource can be used to recursively create the path outside of remote directory structures, but the permissions of -those outside paths are not managed. This is because the `recursive` +those outside paths aren't managed. This is because the `recursive` attribute only applies `group`, `mode`, and `owner` attribute values to the remote directory itself and any inner directories the resource copies. @@ -27,7 +27,7 @@ end But with this example, the `group`, `mode`, and `owner` attribute values will only be applied to `/baz`. Which is fine, if that's what you want. But most of the time, when the entire `/foo/bar/baz` directory structure -is not there, you must be explicit about each directory. For example: +isn't there, you must be explicit about each directory. For example: ```ruby %w( /foo /foo/bar /foo/bar/baz ).each do |path| diff --git a/content/reusable/md/remote_directory_recursive_directories_example.md b/content/reusable/md/remote_directory_recursive_directories_example.md index 11ca702a92..97d446cd82 100644 --- a/content/reusable/md/remote_directory_recursive_directories_example.md +++ b/content/reusable/md/remote_directory_recursive_directories_example.md @@ -1,7 +1,7 @@ This section contains a more detailed example of how Chef Infra Client manages recursive directory structures: -- A cookbook named `cumbria` that is used to build a website +- A cookbook named `cumbria` that's used to build a website - A subfolder in the `/files/default` directory named `/website` - A file named `index.html`, which is the root page for the website - Directories within `/website` named `/cities`, `/places`, and diff --git a/content/reusable/md/remote_file_prevent_re_downloads.md b/content/reusable/md/remote_file_prevent_re_downloads.md index e8c93011f9..1a4a9594da 100644 --- a/content/reusable/md/remote_file_prevent_re_downloads.md +++ b/content/reusable/md/remote_file_prevent_re_downloads.md @@ -10,7 +10,7 @@ present on a node, use one of the following attributes in a recipe: re-download the file. - The `checksum` attribute will ask Chef Infra Client to compare the checksum for the local file to the one at the remote location. If - they match, Chef Infra Client will not re-download the file. Using a + they match, Chef Infra Client won't re-download the file. Using a local checksum for comparison requires that the local checksum be the correct checksum. diff --git a/content/reusable/md/remote_file_unc_path.md b/content/reusable/md/remote_file_unc_path.md index 6e0ca50ef9..d607a1ae4c 100644 --- a/content/reusable/md/remote_file_unc_path.md +++ b/content/reusable/md/remote_file_unc_path.md @@ -1,20 +1,20 @@ The `remote_file` resource on Windows supports accessing files from a remote SMB/CIFS share. The file name should be specified in the source -property as a UNC path e.g. `\myserver\myshare\mydirectory\myfile.txt`. +property as a UNC path for example `\myserver\myshare\mydirectory\myfile.txt`. This allows access to the file at that path location even if the Chef -Infra Client process identity does not have permission to access the +Infra Client process identity doesn't have permission to access the file. Credentials for authenticating to the remote system can be specified using the `remote_user`, `remote_domain`, and `remote_password` properties when the user that Chef Infra Client is -running does not have access to the remote file. See the "Properties" +running doesn't have access to the remote file. See the "Properties" section for more details on these options. **Note**: This is primarily for accessing remote files when the user -that Chef Infra Client is running as does not have sufficient access, +that Chef Infra Client is running as doesn't have sufficient access, and alternative credentials need to be specified. If the user already -has access, the credentials do not need to be specified. In a case where +has access, the credentials don't need to be specified. In a case where the local system and remote system are in the same domain, the -`remote_user` and `remote_password` properties often do not need to be +`remote_user` and `remote_password` properties often don't need to be specified, as the user may already have access to the remote file share. Examples: diff --git a/content/reusable/md/resource_before_notification_restart.md b/content/reusable/md/resource_before_notification_restart.md index d5383b1910..4ee995e336 100644 --- a/content/reusable/md/resource_before_notification_restart.md +++ b/content/reusable/md/resource_before_notification_restart.md @@ -9,5 +9,5 @@ end ``` With the `:before` notification, the action specified for the `nginx` -resource will not run until action has been taken on the notified +resource won't run until action has been taken on the notified resource (`php-fpm`). diff --git a/content/reusable/md/resource_chef_gem_gem_package_install.md b/content/reusable/md/resource_chef_gem_gem_package_install.md index 00e67803e2..9b460d06e0 100644 --- a/content/reusable/md/resource_chef_gem_gem_package_install.md +++ b/content/reusable/md/resource_chef_gem_gem_package_install.md @@ -1,5 +1,5 @@ The **chef_gem** and **gem_package** resources are both used to install Ruby gems. For any machine on which Chef Infra Client is -installed, there are two instances of Ruby. One is the standard, system-wide instance of Ruby and the other is a dedicated instance that is +installed, there are two instances of Ruby. One is the standard, system-wide instance of Ruby and the other is a dedicated instance that's available only to Chef Infra Client. -Use the **chef_gem** resource to install gems into the instance of Ruby that is dedicated to Chef Infra Client. -Use the **gem_package** resource to install all other gems (i.e. install gems system-wide). +Use the **chef_gem** resource to install gems into the instance of Ruby that's dedicated to Chef Infra Client. +Use the **gem_package** resource to install all other gems (that is, install gems system-wide). diff --git a/content/reusable/md/resource_cookbook_file_summary.md b/content/reusable/md/resource_cookbook_file_summary.md index 6539eb428b..ea662b8bb3 100644 --- a/content/reusable/md/resource_cookbook_file_summary.md +++ b/content/reusable/md/resource_cookbook_file_summary.md @@ -1,6 +1,6 @@ Use the **cookbook_file** resource to transfer files from a sub-directory of `COOKBOOK_NAME/files/` to a specified path located on a -host that is running Chef Infra Client. The file is selected according +host that's running Chef Infra Client. The file is selected according to file specificity, which allows different source files to be used based on the hostname, host platform (operating system, distro, or as appropriate), or platform version. Files that are located in the diff --git a/content/reusable/md/resource_execute_command_from_template.md b/content/reusable/md/resource_execute_command_from_template.md index 21c18c41f6..e4d8bc7893 100644 --- a/content/reusable/md/resource_execute_command_from_template.md +++ b/content/reusable/md/resource_execute_command_from_template.md @@ -15,7 +15,7 @@ end ``` where the `command` property for the **execute** resource contains the -command that is to be run and the `source` property for the **template** +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 diff --git a/content/reusable/md/resource_package_options_hash.md b/content/reusable/md/resource_package_options_hash.md index 216291025c..d83fe17134 100644 --- a/content/reusable/md/resource_package_options_hash.md +++ b/content/reusable/md/resource_package_options_hash.md @@ -1,4 +1,4 @@ -You should provide the install options as a hash if you are not using an explicit +You should provide the install options as a hash if you aren't using an explicit `gem_binary` parameter with the `gem_package` resource. This approach allows the provider to install the gem without needing to spawn an external gem process. diff --git a/content/reusable/md/resource_service_subscribes_reload_using_template.md b/content/reusable/md/resource_service_subscribes_reload_using_template.md index ac97053850..a4ede04c49 100644 --- a/content/reusable/md/resource_service_subscribes_reload_using_template.md +++ b/content/reusable/md/resource_service_subscribes_reload_using_template.md @@ -1,4 +1,4 @@ -To reload a service that is based on a template, use the **template** +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: diff --git a/content/reusable/md/resource_template_notifies_run_immediately.md b/content/reusable/md/resource_template_notifies_run_immediately.md index 9e26833679..02aa12d7c1 100644 --- a/content/reusable/md/resource_template_notifies_run_immediately.md +++ b/content/reusable/md/resource_template_notifies_run_immediately.md @@ -1,5 +1,5 @@ -By default, notifications are `:delayed`, that is they are queued up as -they are triggered, and then executed at the end of a Chef Infra +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 diff --git a/content/reusable/md/resources_common_actions_nothing.md b/content/reusable/md/resources_common_actions_nothing.md index 403c3a0765..45131b53c5 100644 --- a/content/reusable/md/resources_common_actions_nothing.md +++ b/content/reusable/md/resources_common_actions_nothing.md @@ -1,3 +1,3 @@ -This resource block does not act unless notified by another resource to +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_actions_nothing_default.md b/content/reusable/md/resources_common_actions_nothing_default.md index 7cadac43ef..d92f4fe2b0 100644 --- a/content/reusable/md/resources_common_actions_nothing_default.md +++ b/content/reusable/md/resources_common_actions_nothing_default.md @@ -1,3 +1,3 @@ -This resource block does not act unless notified by another resource to +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. (default) diff --git a/content/reusable/md/resources_common_atomic_update.md b/content/reusable/md/resources_common_atomic_update.md index 75022e6b35..3136dc9739 100644 --- a/content/reusable/md/resources_common_atomic_update.md +++ b/content/reusable/md/resources_common_atomic_update.md @@ -5,7 +5,7 @@ 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 is available with the **cookbook_file**, **file**, +that's available with the **cookbook_file**, **file**, **remote_file**, and **template** resources. diff --git a/content/reusable/md/resources_common_compile.md b/content/reusable/md/resources_common_compile.md index 50490f88dc..fc67342d5d 100644 --- a/content/reusable/md/resources_common_compile.md +++ b/content/reusable/md/resources_common_compile.md @@ -12,7 +12,7 @@ Chef Infra Client processes recipes in two phases: 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 is necessary to run an action +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. diff --git a/content/reusable/md/resources_common_compile_begin.md b/content/reusable/md/resources_common_compile_begin.md index 7142fcb9a8..399f6006db 100644 --- a/content/reusable/md/resources_common_compile_begin.md +++ b/content/reusable/md/resources_common_compile_begin.md @@ -98,7 +98,7 @@ to download the file during compile time: 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 is not run at compile time: +the `remote_file` resource isn't run at compile time: ```ruby # the execution of this is now deferred @@ -106,7 +106,7 @@ the `remote_file` resource is not run at compile time: source "https://jsonplaceholder.typicode.com/users" end - # it is necessary due to lexical scoping issues to create this variable here + # 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 @@ -125,9 +125,9 @@ the `remote_file` resource is not run at compile time: This is an example of code that overuses deferred execution, uses more "lazy" evaluation, and is considerably harder to understand and write correctly. -**Notifications will not work** +**Notifications won't work** -Resources that are executed during the compile phase cannot notify other +Resources that are executed during the compile phase can't notify other resources. For example: ```ruby @@ -140,7 +140,7 @@ end ``` A better approach in this type of situation is to install the package -before the resource collection is built to ensure that it is available +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 diff --git a/content/reusable/md/resources_common_guard_interpreter_attributes_inherit.md b/content/reusable/md/resources_common_guard_interpreter_attributes_inherit.md index ebfd72d5b6..ac38d4e33c 100644 --- a/content/reusable/md/resources_common_guard_interpreter_attributes_inherit.md +++ b/content/reusable/md/resources_common_guard_interpreter_attributes_inherit.md @@ -1,7 +1,7 @@ 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 **do not inherit** properties that are +`only_if` guard statements **don't inherit** properties that are defined by the **script**-based resource. @@ -19,7 +19,7 @@ respectively.
For example, the `not_if` guard statement in the following resource -example **does not inherit** the `environment` property: +example **doesn't inherit** the `environment` property: ```ruby bash 'javatooling' do diff --git a/content/reusable/md/resources_common_guards.md b/content/reusable/md/resources_common_guards.md index 3e606d0e70..353fcd2bc0 100644 --- a/content/reusable/md/resources_common_guards.md +++ b/content/reusable/md/resources_common_guards.md @@ -6,14 +6,14 @@ 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 is not applied. String guards in a + 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 is not 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 is being +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. +Client to don'thing. diff --git a/content/reusable/md/resources_common_guards_properties.md b/content/reusable/md/resources_common_guards_properties.md index b0a745fa86..3e176d2914 100644 --- a/content/reusable/md/resources_common_guards_properties.md +++ b/content/reusable/md/resources_common_guards_properties.md @@ -1,4 +1,4 @@ -The following properties can be used to define a guard that is evaluated +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` diff --git a/content/reusable/md/resources_common_lazy_evaluation.md b/content/reusable/md/resources_common_lazy_evaluation.md index e2d2dadd7a..be2ed9b71c 100644 --- a/content/reusable/md/resources_common_lazy_evaluation.md +++ b/content/reusable/md/resources_common_lazy_evaluation.md @@ -1,4 +1,4 @@ -In some cases, the value for a property cannot be known until the +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 @@ -13,7 +13,7 @@ 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 is **not** doing lazy evaluation: +For example, a resource that's **not** doing lazy evaluation: ```ruby template 'template_name' do @@ -22,7 +22,7 @@ template 'template_name' do end ``` -and a resource block that is doing lazy evaluation: +and a resource block that's doing lazy evaluation: ```ruby template 'template_name' do diff --git a/content/reusable/md/resources_common_multiple_packages.md b/content/reusable/md/resources_common_multiple_packages.md index fe76d7cb30..11134be41a 100644 --- a/content/reusable/md/resources_common_multiple_packages.md +++ b/content/reusable/md/resources_common_multiple_packages.md @@ -64,7 +64,7 @@ end

Note

-Notifications and subscriptions do not need to be updated when packages +Notifications and subscriptions don't need to be updated when packages and versions are added or removed from the `package_name` or `version` properties. diff --git a/content/reusable/md/resources_common_notification_notifies.md b/content/reusable/md/resources_common_notification_notifies.md index e950b583c3..43942aedea 100644 --- a/content/reusable/md/resources_common_notification_notifies.md +++ b/content/reusable/md/resources_common_notification_notifies.md @@ -4,6 +4,6 @@ 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 does not exist, an error is raised. -In contrast, `subscribes` will not fail if the source -resource is not found. +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_subscribes.md b/content/reusable/md/resources_common_notification_subscribes.md index 9d9a54ad7a..0ab804fc5e 100644 --- a/content/reusable/md/resources_common_notification_subscribes.md +++ b/content/reusable/md/resources_common_notification_subscribes.md @@ -3,7 +3,7 @@ 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` does not apply the specified action to the +Note that `subscribes` doesn't apply the specified action to the resource that it listens to - for example: ```ruby @@ -19,11 +19,11 @@ 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` does not make any +`/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 does not exist, the subscription will not raise an +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 does not exist. +will raise an error if the other resource doesn't exist. diff --git a/content/reusable/md/resources_common_powershell.md b/content/reusable/md/resources_common_powershell.md index e95699f5c1..98d3aaa796 100644 --- a/content/reusable/md/resources_common_powershell.md +++ b/content/reusable/md/resources_common_powershell.md @@ -1,7 +1,7 @@ Windows PowerShell is a task-based command-line shell and scripting language developed by Microsoft. Windows PowerShell uses a document-oriented approach for managing Windows-based -machines, similar to the approach that is used for managing Unix and +machines, similar to the approach that's used for managing Unix and Linux-based machines. Windows PowerShell is [a tool-agnostic platform](https://docs.microsoft.com/en-us/powershell/scripting/powershell-scripting) that supports using Chef for configuration management. diff --git a/content/reusable/md/resources_common_properties.md b/content/reusable/md/resources_common_properties.md index 1385cb714b..2107ebd9b4 100644 --- a/content/reusable/md/resources_common_properties.md +++ b/content/reusable/md/resources_common_properties.md @@ -10,7 +10,7 @@ The following properties are common to every resource: : **Ruby Type:** true, false, :quiet \| **Default Value:** `false` - Continue running a recipe if a resource fails for any reason. `:quiet` will not display the full stack trace and the recipe will continue to run if a resource fails. + 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` @@ -28,4 +28,4 @@ The following properties are common to every resource: : **Ruby Type:** true, false \| **Default Value:** `false` - Ensure that sensitive resource data is not logged by Chef Infra Client. + Ensure that sensitive resource data isn't logged by Chef Infra Client. diff --git a/content/reusable/md/resources_common_windows_security_acl.md b/content/reusable/md/resources_common_windows_security_acl.md index 9e020f77c0..5c3356f287 100644 --- a/content/reusable/md/resources_common_windows_security_acl.md +++ b/content/reusable/md/resources_common_windows_security_acl.md @@ -34,12 +34,12 @@ where `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 is + 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 [SDDL string constants](https://docs.microsoft.com/en-us/windows/win32/secauthz/sid-strings). Chef - Infra Client does not need to know if a principal is a user or a + Infra Client doesn't need to know if a principal is a user or a group. `option_type` @@ -86,9 +86,9 @@ 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 are not specified, nothing will be changed. Chef Infra - Client does not clear out the rights on a file or directory if - rights are not specified. +- 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 diff --git a/content/reusable/md/resources_common_windows_security_inherits.md b/content/reusable/md/resources_common_windows_security_inherits.md index d1b33aa21e..030481faf2 100644 --- a/content/reusable/md/resources_common_windows_security_inherits.md +++ b/content/reusable/md/resources_common_windows_security_inherits.md @@ -46,6 +46,6 @@ directory 'C:\mordor\mount_doom' do end ``` -Because the `inherits` property is not specified, Chef Infra Client will +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_attribute.md b/content/reusable/md/role_attribute.md index 8d65e30fb0..335bd75740 100644 --- a/content/reusable/md/role_attribute.md +++ b/content/reusable/md/role_attribute.md @@ -6,7 +6,7 @@ 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 cannot be set to be a normal +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 index 9052845325..d624558cc2 100644 --- a/content/reusable/md/ruby_class_chef_log_fatal.md +++ b/content/reusable/md/ruby_class_chef_log_fatal.md @@ -3,8 +3,8 @@ 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"]` was not set.') - Chef::Log.fatal('I am bailing here so this node does not upgrade.') + 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 @@ -31,8 +31,8 @@ if node['splunk']['accept_license'] command "#{splunk_cmd} start --accept-license --answer-yes" end else - Chef::Log.fatal('You did not accept the license (set node["splunk"]["accept_license"] to true)') - Chef::Log.fatal('Splunk is stopped and cannot be restarted until the license is accepted!') + 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 index 0f71904acf..9e374448bd 100644 --- a/content/reusable/md/ruby_class_chef_log_multiple.md +++ b/content/reusable/md/ruby_class_chef_log_multiple.md @@ -7,7 +7,7 @@ begin aws = Chef::DataBagItem.load(:aws, :main) Chef::Log.info("Loaded AWS information from DataBagItem aws[#{aws['id']}]") rescue - Chef::Log.fatal("Could not find the 'main' item in the 'aws' data bag") + 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 index 2629cdcc9f..be52f633e7 100644 --- a/content/reusable/md/ruby_style_basics_chef_log.md +++ b/content/reusable/md/ruby_style_basics_chef_log.md @@ -1,4 +1,4 @@ -`Chef::Log` will print log entries to the default logger that is configured for the machine on which Chef Infra Client is running. (To create a log entry that is built into the resource collection, use the [log resource](/resources/log/) instead of `Chef::Log`.) +`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`.) diff --git a/content/reusable/md/ruby_style_patterns_hyphens.md b/content/reusable/md/ruby_style_patterns_hyphens.md index d8a66a6bd3..2d5d29dafd 100644 --- a/content/reusable/md/ruby_style_patterns_hyphens.md +++ b/content/reusable/md/ruby_style_patterns_hyphens.md @@ -1,6 +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 is discouraged. Chef Infra -Client will return an error if a hyphen is not converted to an +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/search.md b/content/reusable/md/search.md index 1b8fa28c1e..286095811b 100644 --- a/content/reusable/md/search.md +++ b/content/reusable/md/search.md @@ -1,4 +1,4 @@ -Search indexes allow queries to be made for any type of data that is +Search indexes allow queries to be made for any type of data that's indexed by the 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 diff --git a/content/reusable/md/search_boolean_operators.md b/content/reusable/md/search_boolean_operators.md index bf7ed5568e..6eff881025 100644 --- a/content/reusable/md/search_boolean_operators.md +++ b/content/reusable/md/search_boolean_operators.md @@ -1,5 +1,5 @@ An operator can be used to ensure that certain terms are included in the -results, are excluded from the results, or are not included even when +results, are excluded from the results, or aren't included even when other aspects of the query match. Searches can use the following operators: diff --git a/content/reusable/md/search_pattern_wildcard.md b/content/reusable/md/search_pattern_wildcard.md index 79f2ef0f79..97825af034 100644 --- a/content/reusable/md/search_pattern_wildcard.md +++ b/content/reusable/md/search_pattern_wildcard.md @@ -4,6 +4,6 @@ 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 is not the first character in the search + (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_query_syntax.md b/content/reusable/md/search_query_syntax.md index f54418156c..e0a82864a3 100644 --- a/content/reusable/md/search_query_syntax.md +++ b/content/reusable/md/search_query_syntax.md @@ -5,11 +5,11 @@ pattern. A search query has the following syntax: key:search_pattern ``` -where `key` is a field name that is found in the JSON description of an +where `key` is a field name that's found in the JSON description of an indexable object on the 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 is not the +wildcard matching using an asterisk ("\*") (and as long as it's not the first character). diff --git a/content/reusable/md/security_chef_validator_context.md b/content/reusable/md/security_chef_validator_context.md index be772e3984..88173f351f 100644 --- a/content/reusable/md/security_chef_validator_context.md +++ b/content/reusable/md/security_chef_validator_context.md @@ -1,4 +1,4 @@ -The private key does not yet exist the first time that Chef Infra Client runs from a new node. +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: diff --git a/content/reusable/md/template.md b/content/reusable/md/template.md index 6cb176b113..6894fa1976 100644 --- a/content/reusable/md/template.md +++ b/content/reusable/md/template.md @@ -1 +1 @@ -A cookbook template is an Embedded Ruby (ERB) template that is 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. +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_specificity_example.md b/content/reusable/md/template_specificity_example.md index 65fb0828d8..20fd5b8c1e 100644 --- a/content/reusable/md/template_specificity_example.md +++ b/content/reusable/md/template_specificity_example.md @@ -20,7 +20,7 @@ end ``` This resource would be matched in the same order as the `/templates` -directory structure. For a node named `host-node-desktop` that is +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: diff --git a/content/reusable/md/template_transfer_frequency.md b/content/reusable/md/template_transfer_frequency.md index 85954647a6..75d0fd52ab 100644 --- a/content/reusable/md/template_transfer_frequency.md +++ b/content/reusable/md/template_transfer_frequency.md @@ -1,4 +1,4 @@ -The Chef Infra Client caches a template when it is first requested. On +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 the 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 index 0834cf6176..5914abacdd 100644 --- a/content/reusable/md/template_variables.md +++ b/content/reusable/md/template_variables.md @@ -12,9 +12,9 @@ A statement is delimited by a modifier, such as `if`, `elsif`, and ```ruby if false -# this will not happen +# this won't happen elsif nil - # this will not either + # this won't either end ``` diff --git a/content/reusable/md/unified_mode_overview.md b/content/reusable/md/unified_mode_overview.md index 7880fbbe94..d71b5c8c62 100644 --- a/content/reusable/md/unified_mode_overview.md +++ b/content/reusable/md/unified_mode_overview.md @@ -1,2 +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 are declared. This results in clearer code and requires less Ruby knowledge to understand the order of operations. +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/windows_environment_variable_path.md b/content/reusable/md/windows_environment_variable_path.md index 00f7373fdd..637ab7d19d 100644 --- a/content/reusable/md/windows_environment_variable_path.md +++ b/content/reusable/md/windows_environment_variable_path.md @@ -5,7 +5,7 @@ the `PATH` environment variable: - `C:\opscode\chef\embedded\bin` This is typically done during the installation of Chef Infra Client -automatically. If these values (for any reason) are not in the `PATH` -environment variable, Chef Infra Client will not run properly. +automatically. If these values (for any reason) aren't in the `PATH` +environment variable, Chef Infra Client won't run properly. ![image](/images/includes_windows_environment_variable_path.png) diff --git a/content/reusable/md/windows_msiexec.md b/content/reusable/md/windows_msiexec.md index 8085e64000..bc99991b5c 100644 --- a/content/reusable/md/windows_msiexec.md +++ b/content/reusable/md/windows_msiexec.md @@ -1,5 +1,5 @@ Msiexec.exe is used to install Chef Infra Client on a node as part of a -bootstrap operation. The actual command that is run by the default +bootstrap operation. The actual command that's run by the default bootstrap script is: ```bash diff --git a/content/reusable/md/windows_registry_key_backslashes.md b/content/reusable/md/windows_registry_key_backslashes.md index cb08090b19..8268908602 100644 --- a/content/reusable/md/windows_registry_key_backslashes.md +++ b/content/reusable/md/windows_registry_key_backslashes.md @@ -1,7 +1,7 @@ A Windows registry key can be used as a string in Ruby code, such as when a registry key is used as the name of a recipe. In Ruby, when a registry key is enclosed in a double-quoted string (`" "`), the -same backslash character (`\`) that is used to define the registry key +same backslash character (`\`) that's used to define the registry key path separator is also used in Ruby to define an escape character. Therefore, the registry key path separators must be escaped when they are enclosed in a double-quoted string. For example, the following diff --git a/content/reusable/md/windows_spaces_and_directories.md b/content/reusable/md/windows_spaces_and_directories.md index c7eccf9371..94f17b75c9 100644 --- a/content/reusable/md/windows_spaces_and_directories.md +++ b/content/reusable/md/windows_spaces_and_directories.md @@ -1,4 +1,4 @@ -Directories that are used by Chef products on Windows cannot have -spaces. For example, `C:\Users\User Name` will not work, but +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 index e4ed34469a..a7f1353367 100644 --- a/content/reusable/md/windows_top_level_directory_names.md +++ b/content/reusable/md/windows_top_level_directory_names.md @@ -1,6 +1,6 @@ Windows will throw errors when path name lengths are too long. For this -reason, it is often helpful to use a short top-level directory, much -like what is done in UNIX and Linux. For example, Chef uses `/opt/` to +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/roles.md b/content/roles.md index 83e1ed9a3c..090c2ce7cc 100644 --- a/content/roles.md +++ b/content/roles.md @@ -77,14 +77,14 @@ Domain-specific Ruby attributes:

default_attributes

-

Optional. A set of attributes to be applied to all nodes, assuming the node does not 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 are 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):

+

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):

default_attributes 'apache2' => {
   'listen_ports' => [ '80', '443' ]
 }

description

-

A description of the functionality that is covered. For example:

+

A description of the functionality that's covered. For example:

description 'The base role for systems that serve HTTP traffic'
@@ -98,12 +98,12 @@ Domain-specific Ruby attributes:

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 are not allowed. For example:

+

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 are preserved. For example:

+

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:

override_attributes 'apache2' => {
   'max_children' => '50'
 }
@@ -125,7 +125,7 @@ Domain-specific Ruby attributes:

run_list

-

A list of recipes and/or roles to be applied and the order in which they are to be applied. For example, the following run-list:

+

A list of recipes and/or roles to be applied and the order in which they're to be applied. For example, the following run-list:

run_list 'recipe[apache2]',
          'recipe[apache2::mod_ssl]',
          'role[monitor]'
@@ -135,7 +135,7 @@ Domain-specific Ruby attributes: Each role must be saved as a ruby file in the `roles/` subdirectory of -the chef-repo. (If the repository does not have this subdirectory, then +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: @@ -229,7 +229,7 @@ The JSON format has two additional settings: 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. +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. @@ -260,22 +260,22 @@ By creating and editing files using the Chef Language (Ruby) or JSON, you can dy 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 should not be managed +roles are created and edited using files, they shouldn't be managed using knife, as changes will be overwritten. -A run-list that is associated with a role can be edited using the Chef +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 the 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 is strongly recommended to keep to one process and not switch back and forth. +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 is not specified, the default run-list will be used. For example: +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 { @@ -309,6 +309,6 @@ where: ### Delete from Run-list When an environment is deleted, it will remain within a run-list for a -role until it is removed from that run-list. If a new environment is +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 index adf991daec..10ab525b04 100644 --- a/content/ruby.md +++ b/content/ruby.md @@ -23,8 +23,8 @@ This section covers the basics of Ruby. ### Verify Syntax -Many people who are new to Ruby often find that it does not take -long to get up to speed with the basics. For example, it is useful to +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`: @@ -93,18 +93,18 @@ Embed Ruby in a string: ```ruby x = 'Bob' "Hi, #{x}" # => "Hi, Bob" -'Hello, #{x}' # => "Hello, \#{x}" Notice that single quotes do not work with #{} +'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 do not need to escape single +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?" # => "will not you read Grant's book?" +"Won\'t you read Grant\'s book?" # => "won't you read Grant's book?" ``` #### Interpolation @@ -144,7 +144,7 @@ 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 is true.) + # even if it exists as zero, then it's true.) 1 == 1 # => true ( == tests for equality ) 1 == true # => false ( == tests for equality ) ``` @@ -157,8 +157,8 @@ Work with basic untruths (`!` means not!): !true # => false !false # => true !nil # => true -1 != 2 # => true (1 is not equal to 2) -1 != 1 # => false (1 is not equal to itself) +1 != 2 # => true (1 isn't equal to 2) +1 != 1 # => false (1 isn't equal to itself) ``` #### Convert Truths @@ -169,7 +169,7 @@ Convert something to either true or false (`!!` means not not!!): !!true # => true !!false # => false !!nil # => false (when pressed, nil is false) -!!0 # => true (zero is NOT false). +!!0 # => true (zero isn't false). ``` ### Arrays @@ -225,7 +225,7 @@ end ### Hash -A Hash is a list with keys and values. Sometimes hashes do not have a set +A Hash is a list with keys and values. Sometimes hashes don't have a set order: ```ruby @@ -264,9 +264,9 @@ Use conditions! For example, an `if` statement ```ruby if false - # this will not happen + # this won't happen elsif nil - # this will not either + # this won't either else # code here will run though end @@ -278,7 +278,7 @@ or a `case` statement: x = 'dog' case x when 'fish' - # this will not happen + # this won't happen when 'dog', 'cat', 'monkey' # this will run else @@ -290,7 +290,7 @@ end 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 is not met +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. @@ -307,7 +307,7 @@ end `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 are not supported. +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. @@ -461,7 +461,7 @@ Name things uniformly for their system and component. For example: - directories: `foo/bar` (if specific to component), `foo` (if not). For example: `/var/log/foo/bar`. -Name attributes after the recipe in which they are primarily used. for example +Name attributes after the recipe in which they're primarily used. for example `node['postgresql']['server']`. ### Parameter Order @@ -512,9 +512,9 @@ mode 755 ### Specify Resource Action? -A resource declaration does not require the action to be specified +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 is not specified within the resource block. For +automatically if it's not specified within the resource block. For example: ```ruby @@ -537,7 +537,7 @@ end ### String Quoting -Use single-quoted strings in all situations where the string does not +Use single-quoted strings in all situations where the string doesn't need interpolation. #### Whitespace Arrays @@ -676,7 +676,7 @@ template '/srv/wordpress_demo/wp-config.php' do 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 are not saved to your chef-server.', + nonce_salt: 'so they're not saved to your chef-server.', allow_multisite: 'false' ) action :create diff --git a/content/run_lists.md b/content/run_lists.md index 2dec317162..99b3b5e45d 100644 --- a/content/run_lists.md +++ b/content/run_lists.md @@ -90,7 +90,7 @@ The following examples show how to use this knife subcommand: #### Options -This command does not have any specific options. +This command doesn't have any specific options. {{< note >}} @@ -120,7 +120,7 @@ The following examples show how to use this knife subcommand: #### Options -This command does not have any specific options. +This command doesn't have any specific options. #### Examples diff --git a/content/saas/register_nodes.md b/content/saas/register_nodes.md index e124e010f8..02e0dfbf03 100644 --- a/content/saas/register_nodes.md +++ b/content/saas/register_nodes.md @@ -19,7 +19,7 @@ The following are prerequisites for migrating nodes from AWS OpsWorks to Chef Sa - A Chef SaaS environment must be configured. Refer to the [Getting Started with Chef SaaS](/saas/get_started/) page. - Restoration is performed on AWS OpsWorks for Chef SaaS. - Splay mode and baseline are up to two client runs an hour. Refer to the [Chef Infra Client](/ctl_chef_client/) page for more details on configuring splay mode in the `client.rb` file. -- There must be one compliance scan per hour. +- There must be one compliance scan each hour. ## Redirect nodes to Chef SaaS diff --git a/content/saas/sso.md b/content/saas/sso.md index de9f3bc396..d960477218 100644 --- a/content/saas/sso.md +++ b/content/saas/sso.md @@ -23,7 +23,7 @@ Chef SaaS supports the following IdPs: ### Add SAML configuration -{{< note >}}It is crucial to note that your account must hold the Administrator policy to access the SSO user interface. This policy is automatically granted to members of the admin team.{{< /note >}} +{{< note >}}It's crucial to note that your account must hold the Administrator policy to access the SSO user interface. This policy is automatically granted to members of the admin team.{{< /note >}} Use the following instructions to add a SAML configuration in Chef SaaS. @@ -53,7 +53,7 @@ Use the following instructions to add a SAML configuration in Chef SaaS. Group Attribute : The group attribute in the SAML assertion. - If not provided, users authenticating with SSO will not be a member of any [team]({{< relref "/automate/teams" >}}). + If not provided, users authenticating with SSO won't be a member of any [team]({{< relref "/automate/teams" >}}). : _Optional_ Allowed Groups diff --git a/content/server_configure_saml.md b/content/server_configure_saml.md index aeb72c7ad9..83338cb62f 100644 --- a/content/server_configure_saml.md +++ b/content/server_configure_saml.md @@ -22,7 +22,7 @@ product = [] {{< /warning >}} Chef Manage can support logging in users using SAML authentication. In -order to do so, there must be a Chef Automate Server that is configured +order to do so, there must be a Chef Automate Server that's configured to act as a SAML Identity Provider (IdP). When the Chef Automate Server is configured to do so, it will provide an OpenID Connect (OIDC) protocol end-point that Chef Manage can use to initiate authentication. @@ -62,7 +62,7 @@ Finally, run `chef-manage-ctl reconfigure` to apply these settings. {{< warning >}} -You cannot have both LDAP and SAML authentication enabled at the same +You can't have both LDAP and SAML authentication enabled at the same time. If you do, the reconfigure will fail with an appropriate error message. diff --git a/content/server_ldap.md b/content/server_ldap.md index bc69e297bd..60eee70e27 100644 --- a/content/server_ldap.md +++ b/content/server_ldap.md @@ -15,7 +15,7 @@ product = ["server"] The Chef Infra Server supports Active Directory and LDAP authentication, which enables users to log in to the Chef Infra Server using their corporate credential and the Manage interface. Without the Manage interface add-on installed, -there is no need to enable the Chef Infra Server LDAP functionality. LDAP is not used with +there is no need to enable the Chef Infra Server LDAP functionality. LDAP isn't used with Supermarket logins, nor with any Chef Infra Client related authentication. ## Configure LDAP @@ -315,7 +315,7 @@ distinguishedName: CN=Robert Forster,OU=Employees,OU=Domain users,DC=opscodecorp {{< note >}} -The `ldapsearch` command may need to be installed on the platform. It is +The `ldapsearch` command may need to be installed on the platform. It's not included as part of the Chef Infra Server package. {{< /note >}} diff --git a/content/server_manage_clients.md b/content/server_manage_clients.md index 7ebb6fae48..4aff7268de 100644 --- a/content/server_manage_clients.md +++ b/content/server_manage_clients.md @@ -30,8 +30,8 @@ This topic is about using the Chef management console to manage keys. A client is an actor that has permission to access the Chef Infra Server. A client is most often a node (on which the Chef Infra Client runs), but is also a workstation (on which knife runs), or some other -machine that is configured to use the Chef Infra Server API. Each -request to the Chef Infra Server that is made by a client uses a private +machine that's configured to use the Chef Infra Server API. Each +request to the Chef Infra Server that's made by a client uses a private key for authentication that must be authorized by the public key on the Chef Infra Server. diff --git a/content/server_manage_cookbooks.md b/content/server_manage_cookbooks.md index 9c249cd4f7..ffdef3a163 100644 --- a/content/server_manage_cookbooks.md +++ b/content/server_manage_cookbooks.md @@ -99,7 +99,7 @@ Infra Server are visible from the Chef management console. ### Download File -To download a file that is located in a cookbook: +To download a file that's located in a cookbook: 1. Open the Chef management console. diff --git a/content/server_manage_nodes.md b/content/server_manage_nodes.md index 08d4a8b55d..52d286603d 100644 --- a/content/server_manage_nodes.md +++ b/content/server_manage_nodes.md @@ -108,7 +108,7 @@ During every Chef Infra Client run, Chef Infra Client builds the attribute list - Attributes passed using JSON on the command line - Data about the node collected by [Ohai](/ohai.html). - The node object that was saved to the 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 is 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. +- 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 the Chef Infra Server so that it can be indexed for search. diff --git a/content/style/_index.md b/content/style/_index.md index a4c3efbc91..e5e6298fa5 100644 --- a/content/style/_index.md +++ b/content/style/_index.md @@ -30,7 +30,7 @@ Our main repository for [docs.chef.io](https://docs.chef.io) is called [chef-web - The `chef-web-docs` repo contains a `content` directory which holds most the Markdown files in the doc set. - The `static/images` directory stores the image files used in the docs. -- The `config.toml` tells Hugo how to build the navigation menus and contains other Hugo settings. do not modify this file. +- The `config.toml` tells Hugo how to build the navigation menus and contains other Hugo settings. Don't modify this file. ### Repository locations diff --git a/content/style/chef_house.md b/content/style/chef_house.md index efe089f979..4ee550a1d8 100644 --- a/content/style/chef_house.md +++ b/content/style/chef_house.md @@ -17,7 +17,7 @@ We recommend that you use the conventions described in this guide when contribut ## Grammar -Chef does not follow a specific grammar convention. Be clear and +Chef doesn't follow a specific grammar convention. Be clear and consistent as often as possible. Follow the established patterns in the docs. @@ -60,11 +60,11 @@ Use the `4thcafe.com` domain for generic domains and email addresses in the docu ### Example Names -do not reveal personal information in examples, such as the names of real people, real email addresses, or phone numbers. +don't reveal personal information in examples, such as the names of real people, real email addresses, or phone numbers. -do not use the names of bands, musicians, or characters from works that are under copyright. +don't use the names of bands, musicians, or characters from works that are under copyright. -When writing about security, follow the accepted convention and use "Alice" and "Bob". Following this convention helps readers see that they are reading a topic about security and integrate the Chef information with their existing knowledge. +When writing about security, follow the accepted convention and use "Alice" and "Bob". Following this convention helps readers see that they're reading a topic about security and integrate the Chef information with their existing knowledge. Here is a list of some example names for you to use (the last names are translations of "Chef"): diff --git a/content/style/contribute.md b/content/style/contribute.md index dc010bde75..822d62f962 100644 --- a/content/style/contribute.md +++ b/content/style/contribute.md @@ -59,7 +59,7 @@ which is circled in red in this image. ### DCO sign-off -Chef Software requires all contributors to include a [Developer Certificate of Origin](https://developercertificate.org/) (DCO) sign-off with their pull request as long as the pull request does not fall under the [Obvious Fix](#obvious-fix) rule. This attests that you have the right to submit the work that you are contributing in your pull request. +Chef Software requires all contributors to include a [Developer Certificate of Origin](https://developercertificate.org/) (DCO) sign-off with their pull request as long as the pull request doesn't fall under the [Obvious Fix](#obvious-fix) rule. This attests that you have the right to submit the work that you are contributing in your pull request. See this [blog post](https://blog.chef.io/2016/09/19/introducing-developer-certificate-of-origin/) to understand why Chef started using the DCO signoff. diff --git a/content/style/front_matter.md b/content/style/front_matter.md index d90d12075a..a39e61b299 100644 --- a/content/style/front_matter.md +++ b/content/style/front_matter.md @@ -49,7 +49,7 @@ title : The title of the page. This will appear at the top of the page. draft (optional) -: Set draft to `true` if you do not want Hugo to build the page. +: Set draft to `true` if you don't want Hugo to build the page. aliases (optional) : Add an alias if you want Hugo to automatically redirect the user from another page to the page you are writing. Use this if you are renaming or deleting a page. @@ -106,12 +106,12 @@ title identifier : The menu identifier of the page that you are writing. Each identifier must be unique. -The convention we have adopted is to use the identifier of the page's parent, a forward slash, then the page file, a space, and then the page title. +The convention we've adopted is to use the identifier of the page's parent, a forward slash, then the page file, a space, and then the page title. For example, this page's parent identifier is `overview/style`, the menu title is `Page Front Matter`, so the full page identifier is `overview/style/Page Front Matter`. parent : The page's parent menu identifier. - The convention we have adopted is to append the different menu levels together, separated by a forward slash, and starting with the highest level. For example, this page is nested under Overview and then style, so the page's parent identifier is `overview/style`. + The convention we've adopted is to append the different menu levels together, separated by a forward slash, and starting with the highest level. For example, this page is nested under Overview and then style, so the page's parent identifier is `overview/style`. weight (optional) : The rank that the page will appear in the menu, incremented by 10. Higher numbers are lower in the menu. If `weight` excluded, the page is sorted in the menu alphabetically by page title. diff --git a/content/style/headings.md b/content/style/headings.md index a34eef2229..efef3c7683 100644 --- a/content/style/headings.md +++ b/content/style/headings.md @@ -12,7 +12,7 @@ gh_repo = "chef-web-docs" The following sections describe the section heading pattern that Chef is using for topic titles, H1s, H2s, H3s and H4s. -As a general rule, limit the number of heading levels to no more than two within a topic. There can be exceptions, especially if the document is large, but remember that HTML TOC structures usually have width limitations (on the display side) and the more structure within a TOC, the harder it can be for users to figure out what is in it. +As a general rule, limit the number of heading levels to no more than two within a topic. There can be exceptions, especially if the document is large, but remember that HTML TOC structures usually have width limitations (on the display side) and the more structure within a TOC, the harder it can be for users to figure out what's in it. Unless the topics are about installing things or about API endpoints, the headings should never wrap. Keep them to a single line. @@ -26,7 +26,7 @@ Don't use headings to define CLI commands, properties, parameters, or other term ## H1 -The H1 heading is reserved for the page title which is created by the Hugo page template. The Markdown file text should not have any H1 headings. +The H1 heading is reserved for the page title which is created by the Hugo page template. The Markdown file text shouldn't have any H1 headings. ## H2 diff --git a/content/style/linking.md b/content/style/linking.md index 1bc2d29674..e59a8249f1 100644 --- a/content/style/linking.md +++ b/content/style/linking.md @@ -67,7 +67,7 @@ To make a link in Markdown, put the link text in square brackets followed by the ### relref shortcode We recommend using Hugo's built-in [relref shortcode](https://gohugo.io/content-management/shortcodes/#ref-and-relref) for making relative links to other pages in Chef's documentation. -If a link is made to a page that does not exist, the site build will fail when Hugo generates a preview of the site. +If a link is made to a page that doesn't exist, the site build will fail when Hugo generates a preview of the site. This will help us prevent dead links in our own documentation if a page is moved or deleted. To format link to pages: diff --git a/content/style/markdown.md b/content/style/markdown.md index fbd4302249..d81b8325cf 100644 --- a/content/style/markdown.md +++ b/content/style/markdown.md @@ -71,7 +71,7 @@ Use this approach to show code blocks that use any type of JavaScript, including ### Literal -Literals should be used sparingly, but sometimes there is a need for a block of text that does not work in a fenced code block, such as showing a directory structure, basic syntax, or pseudocode. To make a literal code block, indent the text by **four** spaces: +Literals should be used sparingly, but sometimes there is a need for a block of text that doesn't work in a fenced code block, such as showing a directory structure, basic syntax, or pseudocode. To make a literal code block, indent the text by **four** spaces: ``` diff --git a/content/style/notices.md b/content/style/notices.md index 22182c09e5..a5dcbd14da 100644 --- a/content/style/notices.md +++ b/content/style/notices.md @@ -53,7 +53,7 @@ This is text in a warning. Danger notices should be used when there are serious consequences for the user or their system. If a user ignores a danger notice, they may lose data, money, work, or expose themselves to a security vulnerability. -**Use a danger notice only if it's absolutely necessary.** +**Use a danger notice only if it's necessary.** When writing text in a danger notice, use short direct language and be specific about what will happen if someone ignores a danger notice. diff --git a/content/style/procedures.md b/content/style/procedures.md index 7436ce159c..32cb6207c3 100644 --- a/content/style/procedures.md +++ b/content/style/procedures.md @@ -91,7 +91,7 @@ A higher level would tell users to log into an account. Both of these levels achieve the same goal, logging a user into an account, but the lower level splits the procedure into several smaller steps. This lower level is too low for must users and certainly too low for Chef's users. -Higher level tasks give the user a better overview of the procedures and where they are while following a set of procedures. +Higher level tasks give the user a better overview of the procedures and their location while following a set of procedures. Higher level tasks are also less likely to become obsolete when a product is updated. It's important to understand the users' skill level so steps can be written at the correct level. @@ -99,7 +99,7 @@ It's important to understand the users' skill level so steps can be written at t ### Each step is an action Each step is an action that a user will perform or a decision that a user must make. -If an action triggers a response from an application or a system, that response is not a step. +If an action triggers a response from an application or a system, that response isn't a step. Use an [imperative verb](https://en.wikipedia.org/wiki/Imperative_mood#English) in the first sentence of every step to clarify the action that the user will take. Format each step as a separate ordered list item. @@ -293,7 +293,7 @@ The config file specifies settings for the server. ### Avoid passive voice -[Passive voice](https://en.wikipedia.org/wiki/Passive_voice#In_English) is often vague and it can be unclear who or what is performing an action. +[Passive voice](https://en.wikipedia.org/wiki/Passive_voice#In_English) is often vague and it can be unclear who or what's performing an action. {{< recommend not >}} @@ -361,7 +361,7 @@ Before upgrading, back up the node. ### Don't use _we_ when referring to the user -_We_ are not doing anything. The user is doing something so use _you_ if you must, but it's better to use the implied _you_ in the [imperative mood](https://en.wikipedia.org/wiki/Imperative_mood#Usage) . +_We_ aren't doing anything. The user is doing something so use _you_ if you must, but it's better to use the implied _you_ in the [imperative mood](https://en.wikipedia.org/wiki/Imperative_mood#Usage) . {{< recommend not >}} diff --git a/content/style/product_names.md b/content/style/product_names.md index 905f148e23..05e72ac109 100644 --- a/content/style/product_names.md +++ b/content/style/product_names.md @@ -18,6 +18,7 @@ This page provides guidance on using Chef product names. See the [Terms page]({{ For Chef applications and components, use: +- Chef 360 Platform - Chef Automate - Chef Backend - Chef Habitat @@ -33,7 +34,7 @@ Always capitalize product names and never hyphenate a product name or refer to a ## Shorten product names -It is awkward to refer to the full product name all the time. +It's awkward to refer to the full product name all the time. Use the full product name the first time it's used in a page or paragraph and then use the shortened product name afterward. ## Using _the_ before product names diff --git a/content/style/test.md b/content/style/test.md index 6e4162753a..d492837169 100644 --- a/content/style/test.md +++ b/content/style/test.md @@ -581,7 +581,7 @@ link target in parentheses. [Link to chef.io](https://chef.io/) or -You can also use HTML, but it is not preferred. +You can also use HTML, but it's not preferred. Link to chef.io ## Images @@ -623,7 +623,7 @@ You can also use HTML for images, but we don't recommend it. ## Tables -Simple tables have one row per line, and columns are separated by `|` +Simple tables have one row for each line, and columns are separated by `|` characters. The header is separated from the body by cells containing nothing but at least three `-` characters. For ease of maintenance, try to keep all the cell separators even, even if you heed to use extra space. diff --git a/content/templates.md b/content/templates.md index c111c44197..41efb2e6f2 100644 --- a/content/templates.md +++ b/content/templates.md @@ -16,7 +16,7 @@ aliases = ["/templates.html", "essentials_cookbook_templates.html"] {{< readfile file="content/reusable/md/template.md" >}} -The `templates` directory does not exist by default in a cookbook. +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 diff --git a/content/terraform.md b/content/terraform.md index d57b1e76c4..86f03df9e1 100644 --- a/content/terraform.md +++ b/content/terraform.md @@ -17,11 +17,11 @@ product = ["client", "server"] 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 is not a configuration management tool, it is 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. +[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 is not officially supported by Chef Software. +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 @@ -47,7 +47,7 @@ resource "aws_instance" "web" { ## 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 are not 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 is not officially supported by Chef Software. +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 diff --git a/content/versions.md b/content/versions.md index bedecb93dc..fe0a6878ca 100644 --- a/content/versions.md +++ b/content/versions.md @@ -71,7 +71,7 @@ commercial agreement with Chef. Additional information is available in {{< note >}} -**Chef Backend** does not directly require acceptance of the Chef +**Chef Backend** doesn't directly require acceptance of the Chef EULA, but it does have functionality that requires its acceptance in other products. diff --git a/content/vmware.md b/content/vmware.md index d8c35357e6..1c710b670f 100644 --- a/content/vmware.md +++ b/content/vmware.md @@ -72,7 +72,7 @@ created in `FOLDERNAME` instead of the root folder. {{< /note >}} -**Clone from a folder into the "Datacenter Root" directory:** +**Clone from a folder into the data center root directory:** ```bash knife vsphere vm clone MACHINENAME --template TEMPLATENAME -f /path/to/template \ @@ -235,7 +235,7 @@ knife[:vro_base_url] = 'https://vra.example.local:8281' : 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 is not current. +: Specify a specific Chef Infra Client version if your group isn't current. #### Usage Examples @@ -244,7 +244,7 @@ knife[:vro_base_url] = 'https://vra.example.local:8281' 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 are available. +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 \ @@ -299,7 +299,7 @@ the Chef Infra Server. **Execute a vRealize Orchestrator workflow:** -This requires the workflow name. If your workflow name is not unique in your vRealize Orchestrator workflow list, you +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 @@ -336,7 +336,7 @@ Chef: - Leverages the typical Test Kitchen workflow for vCenter \> 5.0+ - There is a [kitchen-vsphere](https://rubygems.org/gems/kitchen-vsphere) gem, - but it is not supported at this time + but it's not supported at this time #### Usage Examples @@ -463,7 +463,7 @@ platforms: [[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 is required by VMware +- Leverages specific Workflows in vRealize Orchestrator if it's required by VMware admins #### Usage Examples diff --git a/content/windows.md b/content/windows.md index cb373cba5e..24422b5500 100644 --- a/content/windows.md +++ b/content/windows.md @@ -74,7 +74,7 @@ Windows: -After Chef Infra Client is installed, it is located at `C:\opscode`. The +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`. @@ -106,7 +106,7 @@ main configuration file for Chef Infra Client is located at {{< readfile file="content/workstation/reusable/md/knife_windows_summary.md" >}} -Se the [knife windows](/workstation/knife_windows/) for more information. +For more information, see the [`knife windows` documentation](/workstation/knife_windows/). #### Ports diff --git a/cspell.yaml b/cspell.yaml index d02ae3df98..65678ede40 100644 --- a/cspell.yaml +++ b/cspell.yaml @@ -6,11 +6,15 @@ version: '0.2' language: en_US dictionaries: +- 360-docs - chef - docs - hab-docs dictionaryDefinitions: +- name: 360-docs + path: https://raw.githubusercontent.com/chef/chef_dictionary/refs/heads/main/360-docs.txt + description: Custom Chef 360 Dictionary - name: chef path: https://raw.githubusercontent.com/chef/chef_dictionary/main/chef.txt description: Custom Chef Dictionary