chef 12.22.1-universal-mingw32 → 12.22.3-universal-mingw32

data/distro/common/markdown/README

@@ -1,3 +1,3 @@
-This directory contains markdown documentation that is used in other places.
-For example, markdown (.mkd) documents that are generated as man pages
-with ronn.
+This directory contains markdown documentation that is used in other places.
+For example, markdown (.mkd) documents that are generated as man pages
+with ronn.

data/distro/common/markdown/man1/chef-shell.mkd

@@ -1,195 +1,195 @@
-chef-shell(1) -- Interactive Chef Console
-=========================================
-
-## SYNOPSIS
-
-__chef-shell__ [_named configuration_] _(options)_
-
-  * `-S`, `--server CHEF_SERVER_URL`:
-    The chef server URL
-  * `-z`, `--client`:
-    chef-client mode
-  * `-c`, `--config CONFIG`:
-    The configuration file to use
-  * `-j`, `--json-attributes JSON_ATTRIBS`:
-    Load attributes from a JSON file or URL
-  * `-l`, `--log-level LOG_LEVEL`:
-    Set the logging level
-  * `-s`, `--solo`:
-    chef-solo session
-  * `-a`, `--standalone`:
-    standalone session
-  * `-v`, `--version`:
-    Show chef version
-  * `-h`, `--help`:
-    Show command options
-
-When no --config option is specified, chef-shell attempts to load a
-default configuration file:
-
-* If a _named configuration_ is given, chef-shell will load ~/.chef/_named
-  configuration_/chef_shell.rb
-* If no _named configuration_ is given chef-shell will load
-  ~/.chef/chef_shell.rb if it exists
-* chef-shell falls back to loading /etc/chef/client.rb or
-/etc/chef/solo.rb if -z or -s options are given and no chef_shell.rb
-can be found.
-* The --config option takes precedence over implicit configuration
-  paths.
-
-## DESCRIPTION
-
-`chef-shell` is an irb(1) (interactive ruby) session customized for Chef.
-`chef-shell` serves two primary functions: it provides a means to
-interact with a Chef Server interactively using a convenient DSL; it
-allows you to define and run Chef recipes interactively.
-
-## SYNTAX
-
-chef-shell uses irb's subsession feature to provide multiple modes of
-interaction. In addition to the primary mode which is entered on start,
-`recipe` and `attributes` modes are available.
-
-## PRIMARY MODE
-The following commands are available in the primary
-session:
-
-  * `help`:
-    Prints a list of available commands
-  * `version`:
-    Prints the Chef version
-  * `recipe`:
-    Switches to `recipe` mode
-  * `attributes`:
-    Switches to `attributes` mode
-  * `run_chef`:
-    Initiates a chef run
-  * `reset`:
-    reinitializes chef-shell session
-  * `echo :on|:off`:
-    Turns irb's echo function on or off. Echo is _on_ by default.
-  * `tracing :on|:off`:
-    Turns irb's function tracing feature on or off. Tracing is extremely
-    verbose and expected to be of interest primarily to developers.
-  * `node`:
-    Returns the _node_ object for the current host. See knife-node(1)
-    for more information about nodes.
-  * `ohai`:
-    Prints the attributes of _node_
-
-In addition to these commands, chef-shell provides a DSL for accessing
-data on the Chef Server. When working with remote data in chef-shell, you
-chain method calls in the form _object type_._operation_, where
-_object type_ is in plural form. The following object types are
-available:
-
-  * `nodes`
-  * `roles`
-  * `data_bags`
-  * `clients`
-  * `cookbooks`
-
-For each _object type_ the following operations are available:
-
-  * _object type_.all(_&block_):
-    Loads all items from the server. If the optional code _block_ is
-    given, each item will be passed to the block and the results
-    returned, similar to ruby's `Enumerable#map` method.
-  * _object type_.show(_object name_):
-    Aliased as _object type_.load
-
-    Loads the singular item identified by _object name_.
-  * _object type_.search(_query_, _&block_):
-    Aliased as _object type_.find
-
-    Runs a search against the server and returns the matching items. If
-    the optional code _block_ is given each item will be passed to the
-    block and the results returned.
-
-    The _query_ may be a Solr/Lucene format query given as a String, or
-    a Hash of conditions. If a Hash is given, the options will be ANDed
-    together. To join conditions with OR, use negative queries, or any
-    advanced search syntax, you must provide give the query in String
-    form.
-  * _object type_.transform(:all|_query_, _&block_):
-    Aliased as _object type_.bulk_edit
-
-    Bulk edit objects by processing them with the (required) code _block_.
-    You can edit all objects of the given type by passing the Symbol
-    `:all` as the argument, or only a subset by passing a _query_ as the
-    argument. The _query_ is evaluated in the same way as with
-    __search__.
-
-    The return value of the code _block_ is used to alter the behavior
-    of `transform`. If the value returned from the block is `nil` or
-    `false`, the object will not be saved. Otherwise, the object is
-    saved after being passed to the block. This behavior can be
-    exploited to create a dry run to test a data transformation.
-
-## RECIPE MODE
-Recipe mode implements Chef's recipe DSL. Exhaustively documenting this
-DSL is outside the scope of this document. See the following pages in
-the Chef documentation for more information:
-
-  * <http://docs.chef.io/resources.html>
-  * <http://docs.chef.io/recipes.html>
-
-Once you have defined resources in the recipe, you can trigger a
-convergence run via `run_chef`
-
-## EXAMPLES
-
-* A "Hello World" interactive recipe
-
-  chef > recipe
-  chef:recipe > echo :off
-  chef:recipe > file "/tmp/hello\_world"
-  chef:recipe > run\_chef
-  [Sat, 09 Apr 2011 08:56:56 -0700] INFO: Processing file[/tmp/hello\_world] action create ((irb#1) line 2)
-  [Sat, 09 Apr 2011 08:56:56 -0700] INFO: file[/tmp/hello\_world] created file /tmp/hello\_world
-  chef:recipe > pp ls '/tmp'
-  [".",
-  "..",
-  "hello\_world"]
-
-* Search for _nodes_ by role, and print their IP addresses
-
-  chef > nodes.find(:roles => 'monitoring-server') {|n| n[:ipaddress] }
-  => ["10.254.199.5"]
-
-* Remove the role _obsolete_ from every node in the system
-
-  chef > nodes.transform(:all) {|n| n.run\_list.delete('role[obsolete]') }
-   => [node[chef098b2.opschef.com], node[ree-woot], node[graphite-dev], node[fluke.localdomain], node[ghost.local], node[kallistec]]
-
-
-## BUGS
-
-`chef-shell` often does not perfectly replicate the context in which
-chef-client(8) configures a host, which may lead to discrepancies in
-observed behavior.
-
-`chef-shell` has to duplicate much code from chef-client's internal
-libraries and may become out of sync with the behavior of those
-libraries.
-
-## SEE ALSO
-
-  chef-client(8) knife(1)
-  <http://docs.chef.io/ctl_chef_shell.html>
-
-## AUTHOR
-
-   Chef was written by Adam Jacob <adam@opscode.com> with many
-   contributions from the community. chef-shell was written by Daniel
-   DeLeo.
-
-## DOCUMENTATION
-
-   This manual page was written by Daniel DeLeo <dan@opscode.com>.
-   Permission is granted to copy, distribute and / or modify this
-   document under the terms of the Apache 2.0 License.
-
-## CHEF
-
-   chef-shell is distributed with Chef. <http://docs.chef.io>
+chef-shell(1) -- Interactive Chef Console
+=========================================
+
+## SYNOPSIS
+
+__chef-shell__ [_named configuration_] _(options)_
+
+  * `-S`, `--server CHEF_SERVER_URL`:
+    The chef server URL
+  * `-z`, `--client`:
+    chef-client mode
+  * `-c`, `--config CONFIG`:
+    The configuration file to use
+  * `-j`, `--json-attributes JSON_ATTRIBS`:
+    Load attributes from a JSON file or URL
+  * `-l`, `--log-level LOG_LEVEL`:
+    Set the logging level
+  * `-s`, `--solo`:
+    chef-solo session
+  * `-a`, `--standalone`:
+    standalone session
+  * `-v`, `--version`:
+    Show chef version
+  * `-h`, `--help`:
+    Show command options
+
+When no --config option is specified, chef-shell attempts to load a
+default configuration file:
+
+* If a _named configuration_ is given, chef-shell will load ~/.chef/_named
+  configuration_/chef_shell.rb
+* If no _named configuration_ is given chef-shell will load
+  ~/.chef/chef_shell.rb if it exists
+* chef-shell falls back to loading /etc/chef/client.rb or
+/etc/chef/solo.rb if -z or -s options are given and no chef_shell.rb
+can be found.
+* The --config option takes precedence over implicit configuration
+  paths.
+
+## DESCRIPTION
+
+`chef-shell` is an irb(1) (interactive ruby) session customized for Chef.
+`chef-shell` serves two primary functions: it provides a means to
+interact with a Chef Server interactively using a convenient DSL; it
+allows you to define and run Chef recipes interactively.
+
+## SYNTAX
+
+chef-shell uses irb's subsession feature to provide multiple modes of
+interaction. In addition to the primary mode which is entered on start,
+`recipe` and `attributes` modes are available.
+
+## PRIMARY MODE
+The following commands are available in the primary
+session:
+
+  * `help`:
+    Prints a list of available commands
+  * `version`:
+    Prints the Chef version
+  * `recipe`:
+    Switches to `recipe` mode
+  * `attributes`:
+    Switches to `attributes` mode
+  * `run_chef`:
+    Initiates a chef run
+  * `reset`:
+    reinitializes chef-shell session
+  * `echo :on|:off`:
+    Turns irb's echo function on or off. Echo is _on_ by default.
+  * `tracing :on|:off`:
+    Turns irb's function tracing feature on or off. Tracing is extremely
+    verbose and expected to be of interest primarily to developers.
+  * `node`:
+    Returns the _node_ object for the current host. See knife-node(1)
+    for more information about nodes.
+  * `ohai`:
+    Prints the attributes of _node_
+
+In addition to these commands, chef-shell provides a DSL for accessing
+data on the Chef Server. When working with remote data in chef-shell, you
+chain method calls in the form _object type_._operation_, where
+_object type_ is in plural form. The following object types are
+available:
+
+  * `nodes`
+  * `roles`
+  * `data_bags`
+  * `clients`
+  * `cookbooks`
+
+For each _object type_ the following operations are available:
+
+  * _object type_.all(_&block_):
+    Loads all items from the server. If the optional code _block_ is
+    given, each item will be passed to the block and the results
+    returned, similar to ruby's `Enumerable#map` method.
+  * _object type_.show(_object name_):
+    Aliased as _object type_.load
+
+    Loads the singular item identified by _object name_.
+  * _object type_.search(_query_, _&block_):
+    Aliased as _object type_.find
+
+    Runs a search against the server and returns the matching items. If
+    the optional code _block_ is given each item will be passed to the
+    block and the results returned.
+
+    The _query_ may be a Solr/Lucene format query given as a String, or
+    a Hash of conditions. If a Hash is given, the options will be ANDed
+    together. To join conditions with OR, use negative queries, or any
+    advanced search syntax, you must provide give the query in String
+    form.
+  * _object type_.transform(:all|_query_, _&block_):
+    Aliased as _object type_.bulk_edit
+
+    Bulk edit objects by processing them with the (required) code _block_.
+    You can edit all objects of the given type by passing the Symbol
+    `:all` as the argument, or only a subset by passing a _query_ as the
+    argument. The _query_ is evaluated in the same way as with
+    __search__.
+
+    The return value of the code _block_ is used to alter the behavior
+    of `transform`. If the value returned from the block is `nil` or
+    `false`, the object will not be saved. Otherwise, the object is
+    saved after being passed to the block. This behavior can be
+    exploited to create a dry run to test a data transformation.
+
+## RECIPE MODE
+Recipe mode implements Chef's recipe DSL. Exhaustively documenting this
+DSL is outside the scope of this document. See the following pages in
+the Chef documentation for more information:
+
+  * <http://docs.chef.io/resources.html>
+  * <http://docs.chef.io/recipes.html>
+
+Once you have defined resources in the recipe, you can trigger a
+convergence run via `run_chef`
+
+## EXAMPLES
+
+* A "Hello World" interactive recipe
+
+  chef > recipe
+  chef:recipe > echo :off
+  chef:recipe > file "/tmp/hello\_world"
+  chef:recipe > run\_chef
+  [Sat, 09 Apr 2011 08:56:56 -0700] INFO: Processing file[/tmp/hello\_world] action create ((irb#1) line 2)
+  [Sat, 09 Apr 2011 08:56:56 -0700] INFO: file[/tmp/hello\_world] created file /tmp/hello\_world
+  chef:recipe > pp ls '/tmp'
+  [".",
+  "..",
+  "hello\_world"]
+
+* Search for _nodes_ by role, and print their IP addresses
+
+  chef > nodes.find(:roles => 'monitoring-server') {|n| n[:ipaddress] }
+  => ["10.254.199.5"]
+
+* Remove the role _obsolete_ from every node in the system
+
+  chef > nodes.transform(:all) {|n| n.run\_list.delete('role[obsolete]') }
+   => [node[chef098b2.opschef.com], node[ree-woot], node[graphite-dev], node[fluke.localdomain], node[ghost.local], node[kallistec]]
+
+
+## BUGS
+
+`chef-shell` often does not perfectly replicate the context in which
+chef-client(8) configures a host, which may lead to discrepancies in
+observed behavior.
+
+`chef-shell` has to duplicate much code from chef-client's internal
+libraries and may become out of sync with the behavior of those
+libraries.
+
+## SEE ALSO
+
+  chef-client(8) knife(1)
+  <http://docs.chef.io/ctl_chef_shell.html>
+
+## AUTHOR
+
+   Chef was written by Adam Jacob <adam@opscode.com> with many
+   contributions from the community. chef-shell was written by Daniel
+   DeLeo.
+
+## DOCUMENTATION
+
+   This manual page was written by Daniel DeLeo <dan@opscode.com>.
+   Permission is granted to copy, distribute and / or modify this
+   document under the terms of the Apache 2.0 License.
+
+## CHEF
+
+   chef-shell is distributed with Chef. <http://docs.chef.io>

data/distro/common/markdown/man1/knife-bootstrap.mkd

@@ -1,141 +1,141 @@
-knife-bootstrap(1) -- Install Chef Client on a remote host
-========================================
-
-## SYNOPSIS
-
-__knife__ __bootstrap__ _(options)_
-
-  * `-i`, `--identity-file IDENTITY_FILE`:
-    The SSH identity file used for authentication
-  * `-N`, `--node-name NAME`:
-    The Chef node name for your new node
-  * `-P`, `--ssh-password PASSWORD`:
-    The ssh password
-  * `-x`, `--ssh-user USERNAME`:
-    The ssh username
-  * `-p`, `--ssh-port PORT`:
-    The ssh port
-  * `--bootstrap-version VERSION`:
-    The version of Chef to install
-  * `--bootstrap-proxy PROXY_URL`:
-    `The proxy server for the node being bootstrapped`
-  * `--prerelease`:
-    Install pre-release Chef gems
-  * `-r`, `--run-list RUN_LIST`:
-    Comma separated list of roles/recipes to apply
-  * `--template-file TEMPLATE`:
-    Full path to location of template to use
-  * `--sudo`:
-    Execute the bootstrap via sudo
-  * `-d`, `--distro DISTRO`:
-    Bootstrap a distro using a template
-  * `--[no-]host-key-verify`:
-    Enable host key verification, which is the default behavior.
-  * `--hint HINT_NAME[=HINT_FILE]`:
-    Provide the name of a hint (with option JSON file) to set for use by
-    Ohai plugins.
-
-## DESCRIPTION
-
-Performs a Chef Bootstrap on the target node. The goal of the bootstrap
-is to get Chef installed on the target system so it can run Chef Client
-with a Chef Server. The main assumption is a baseline OS installation
-exists. This sub-command is used internally by some cloud computing
-plugins.
-
-The bootstrap sub-command supports supplying a template to perform the
-bootstrap steps. If the distro is not specified (via `-d` or `--distro`
-option), an Ubuntu 10.04 host bootstrapped with RubyGems is assumed. The
-__DISTRO__ value corresponds to the base filename of the template, in
-other words `DISTRO`.erb. A template file can be specified with the
-`--template-file` option in which case the __DISTRO__ is not used. The
-sub-command looks in the following locations for the template to use:
-
-* `bootstrap` directory in the installed Chef Knife library.
-* `bootstrap` directory in the `$PWD/.chef`.
-* `bootstrap` directory in the users `$HOME/.chef`.
-
-The default bootstrap templates are scripts that get copied to the
-target node (FQDN). The following distros are supported:
-
-* centos5-gems
-* fedora13-gems
-* ubuntu10.04-gems
-* ubuntu10.04-apt
-
-The gems installations will use RubyGems 1.3.6 and Chef installed as a
-gem. The apt installation will use the Opscode APT repository.
-
-In addition to handling the software installation, these bootstrap
-templates do the following:
-
-  - Write the validation.pem per the local knife configuration.
-  - Write a default config file for Chef (`/etc/chef/client.rb`) using values from the `knife.rb`.
-  - Create a JSON attributes file containing the specified run list and run Chef.
-
-In the case of the RubyGems, the `client.rb` will be written from
-scratch with a minimal set of values; see __EXAMPLES__. In the case of
-APT Package installation, `client.rb` will have the
-`validation_client_name` appended if it is not set to `chef-validator`
-(default config value), and the `node_name` will be added if
-`chef_node_name` option is specified.
-
-When this is complete, the bootstrapped node will have:
-
-  - Latest Chef version installed from RubyGems or APT Packages from Opscode. This may be a later version than the local system.
-  - Be validated with the configured Chef Server.
-  - Have run Chef with its default run list if one is specified.
-
-Additional custom bootstrap templates can be created and stored in
-`.chef/bootstrap/DISTRO.erb`, replacing __DISTRO__ with the value passed
-with the `-d` or `--distro` option. See __EXAMPLES__ for more
-information.
-
-## EXAMPLES
-Setting up a custom bootstrap is fairly straightforward. Create a
-`.chef/bootstrap` directory in your Chef Repository or in
-`$HOME/.chef/bootstrap`. Then create the ERB template file.
-
-    mkdir ~/.chef/bootstrap
-    vi ~/.chef/bootstrap/debian5.0-apt.erb
-
-For example, to create a new bootstrap template that should be used when
-setting up a new Debian node. Edit the template to run the commands, set
-up the validation certificate and the client configuration file, and
-finally to run chef-client on completion. The bootstrap template can be
-called with:
-
-    knife bootstrap mynode.example.com --template-file ~/.chef/bootstrap/debian5.0-apt.erb
-
-Or,
-
-    knife bootstrap mynode.example.com --distro debian5.0-apt
-
-The `--distro` parameter will automatically look in the
-`~/.chef/bootstrap` directory for a file named `debian5.0-apt.erb`.
-
-Templates provided by the Chef installation are located in
-`BASEDIR/lib/chef/knife/bootstrap/*.erb`, where _BASEDIR_ is the
-location where the package or Gem installed the Chef client libraries.
-
-## BUGS
-`knife bootstrap` is not capable of bootstrapping multiple hosts in
-parallel.
-
-The bootstrap script is passed as an argument to sh(1) on the remote
-system, so sensitive information contained in the script will be visible
-to other users via the process list using tools such as ps(1).
-
-## SEE ALSO
-   __knife-ssh__(1)
-
-## AUTHOR
-   Chef was written by Adam Jacob <adam@opscode.com> with many contributions from the community.
-
-## DOCUMENTATION
-   This manual page was written by Joshua Timberman <joshua@opscode.com>.
-   Permission is granted to copy, distribute and / or modify this document under the terms of the Apache 2.0 License.
-
-
-## CHEF
-   Knife is distributed with Chef. <http://docs.chef.io>
+knife-bootstrap(1) -- Install Chef Client on a remote host
+========================================
+
+## SYNOPSIS
+
+__knife__ __bootstrap__ _(options)_
+
+  * `-i`, `--identity-file IDENTITY_FILE`:
+    The SSH identity file used for authentication
+  * `-N`, `--node-name NAME`:
+    The Chef node name for your new node
+  * `-P`, `--ssh-password PASSWORD`:
+    The ssh password
+  * `-x`, `--ssh-user USERNAME`:
+    The ssh username
+  * `-p`, `--ssh-port PORT`:
+    The ssh port
+  * `--bootstrap-version VERSION`:
+    The version of Chef to install
+  * `--bootstrap-proxy PROXY_URL`:
+    `The proxy server for the node being bootstrapped`
+  * `--prerelease`:
+    Install pre-release Chef gems
+  * `-r`, `--run-list RUN_LIST`:
+    Comma separated list of roles/recipes to apply
+  * `--template-file TEMPLATE`:
+    Full path to location of template to use
+  * `--sudo`:
+    Execute the bootstrap via sudo
+  * `-d`, `--distro DISTRO`:
+    Bootstrap a distro using a template
+  * `--[no-]host-key-verify`:
+    Enable host key verification, which is the default behavior.
+  * `--hint HINT_NAME[=HINT_FILE]`:
+    Provide the name of a hint (with option JSON file) to set for use by
+    Ohai plugins.
+
+## DESCRIPTION
+
+Performs a Chef Bootstrap on the target node. The goal of the bootstrap
+is to get Chef installed on the target system so it can run Chef Client
+with a Chef Server. The main assumption is a baseline OS installation
+exists. This sub-command is used internally by some cloud computing
+plugins.
+
+The bootstrap sub-command supports supplying a template to perform the
+bootstrap steps. If the distro is not specified (via `-d` or `--distro`
+option), an Ubuntu 10.04 host bootstrapped with RubyGems is assumed. The
+__DISTRO__ value corresponds to the base filename of the template, in
+other words `DISTRO`.erb. A template file can be specified with the
+`--template-file` option in which case the __DISTRO__ is not used. The
+sub-command looks in the following locations for the template to use:
+
+* `bootstrap` directory in the installed Chef Knife library.
+* `bootstrap` directory in the `$PWD/.chef`.
+* `bootstrap` directory in the users `$HOME/.chef`.
+
+The default bootstrap templates are scripts that get copied to the
+target node (FQDN). The following distros are supported:
+
+* centos5-gems
+* fedora13-gems
+* ubuntu10.04-gems
+* ubuntu10.04-apt
+
+The gems installations will use RubyGems 1.3.6 and Chef installed as a
+gem. The apt installation will use the Opscode APT repository.
+
+In addition to handling the software installation, these bootstrap
+templates do the following:
+
+  - Write the validation.pem per the local knife configuration.
+  - Write a default config file for Chef (`/etc/chef/client.rb`) using values from the `knife.rb`.
+  - Create a JSON attributes file containing the specified run list and run Chef.
+
+In the case of the RubyGems, the `client.rb` will be written from
+scratch with a minimal set of values; see __EXAMPLES__. In the case of
+APT Package installation, `client.rb` will have the
+`validation_client_name` appended if it is not set to `chef-validator`
+(default config value), and the `node_name` will be added if
+`chef_node_name` option is specified.
+
+When this is complete, the bootstrapped node will have:
+
+  - Latest Chef version installed from RubyGems or APT Packages from Opscode. This may be a later version than the local system.
+  - Be validated with the configured Chef Server.
+  - Have run Chef with its default run list if one is specified.
+
+Additional custom bootstrap templates can be created and stored in
+`.chef/bootstrap/DISTRO.erb`, replacing __DISTRO__ with the value passed
+with the `-d` or `--distro` option. See __EXAMPLES__ for more
+information.
+
+## EXAMPLES
+Setting up a custom bootstrap is fairly straightforward. Create a
+`.chef/bootstrap` directory in your Chef Repository or in
+`$HOME/.chef/bootstrap`. Then create the ERB template file.
+
+    mkdir ~/.chef/bootstrap
+    vi ~/.chef/bootstrap/debian5.0-apt.erb
+
+For example, to create a new bootstrap template that should be used when
+setting up a new Debian node. Edit the template to run the commands, set
+up the validation certificate and the client configuration file, and
+finally to run chef-client on completion. The bootstrap template can be
+called with:
+
+    knife bootstrap mynode.example.com --template-file ~/.chef/bootstrap/debian5.0-apt.erb
+
+Or,
+
+    knife bootstrap mynode.example.com --distro debian5.0-apt
+
+The `--distro` parameter will automatically look in the
+`~/.chef/bootstrap` directory for a file named `debian5.0-apt.erb`.
+
+Templates provided by the Chef installation are located in
+`BASEDIR/lib/chef/knife/bootstrap/*.erb`, where _BASEDIR_ is the
+location where the package or Gem installed the Chef client libraries.
+
+## BUGS
+`knife bootstrap` is not capable of bootstrapping multiple hosts in
+parallel.
+
+The bootstrap script is passed as an argument to sh(1) on the remote
+system, so sensitive information contained in the script will be visible
+to other users via the process list using tools such as ps(1).
+
+## SEE ALSO
+   __knife-ssh__(1)
+
+## AUTHOR
+   Chef was written by Adam Jacob <adam@opscode.com> with many contributions from the community.
+
+## DOCUMENTATION
+   This manual page was written by Joshua Timberman <joshua@opscode.com>.
+   Permission is granted to copy, distribute and / or modify this document under the terms of the Apache 2.0 License.
+
+
+## CHEF
+   Knife is distributed with Chef. <http://docs.chef.io>