knife
- Chef Server API client utility
knife sub-command [argument...] (options)
Knife is a command-line utility used to manage data on a Chef server through the HTTP(S) API. Knife is organized into groups of subcommands centered around the various object types in Chef. Each category of subcommand is documented in its own manual page. Available topics are:
If the knife manuals are in your MANPATH
, you can access help for the
above topics using man knife-TOPIC
; otherwise, you can view the
documentation using knife help TOPIC
.
-s
, --server-url
URLChef::Config
chef_server_url
.-k
, --key
KEYChef::Config
client_key
.-c
, --config
CONFIG-E
, --environment ENVIRONMENT
-e
, --editor
EDITOR-F
, --format
FORMAT-d
, --disable-editing
-u
, --user
USERChef::Config
node_name
.-p
, --print-after
-v
, --version
-V
, --verbose
-y
, --yes
--defaults
--[no-]color
-h
, --help
Sub-commands that operate on the basic Chef data types are structured as NOUN verb NOUN (options). For all data types, the following commands are available:
Knife also includes commands that take actions other than displaying or modifying data on the Chef Server, such as knife-ssh(1).
The knife configuration file is a Ruby DSL to set configuration
parameters for Knife's GENERAL OPTIONS. The default location for the
config file is ~/.chef/knife.rb
. If managing multiple Chef
repositories, per-repository config files can be created. The file must
be .chef/knife.rb
in the current directory of the repository.
If the config file exists, knife uses these settings for GENERAL OPTIONS defaults.
node_name
:
User or client identity (i.e., name) to use for authenticating
requests to the Chef Server.client_key
:
Private key file to authenticate to the Chef server. Corresponds to the
-k
or --key
option.chef_server_url
:
URL of the Chef server. Corresponds to the -s
or --server-url
option. This is requested from the user when running this sub-command.cache_type
:
The type of cache to use. Default is BasicFile. This can be any type of
Cache that moneta supports: BasicFile, Berkeley, Couch, DataMapper,
File, LMC, Memcache, Memory, MongoDB, Redis, Rufus, S3, SDBM, Tyrant,
Xattr, YAML.cache_options
:
Specifies various options to use for caching. These options are
dependent on the cache_type
.validation_client_name
:
Specifies the name of the client used to validate new clients.validation_key
:
Specifies the private key file to use when bootstrapping new hosts.
See knife-client(1) for more information about the validation
client.cookbook_copyright
, cookbook_email
, cookbook_license
, readme_format
Used by knife cookbook create
sub-command to specify the copyright
holder, maintainer email, license and readme format (respectively) for new cookbooks.
The copyright holder is listed as the maintainer in the cookbook's
metadata and as the Copyright in the comments of the default recipe. The
maintainer email is used in the cookbook metadata. The license
determines what preamble to put in the comment of the default recipe,
and is listed as the license in the cookbook metadata. Currently
supported licenses are "apachev2" and "none". Any other values will
result in an empty license in the metadata (needs to be filled in by the
author), and no comment preamble in the default recipe. Currently supported
readme formats are "md", "mkd", "txt", and "rdoc". Any other value will
result in an unformatted README.~/.chef/knife.rb
Ruby DSL configuration file for knife. See CONFIGURATION.
The amount of content displayed and the output format are
modified by the --format
option. If no alternate format is selected,
the default is summary.
Valid formats are:
summary
text
json
yaml
pp
For brevity, only the first character of the format is required, for example, -Fj will produce JSON format output.
When working with Chef and Knife in the local repository, the recommended workflow outline looks like:
cookbook create
sub-command.A note about git: Opscode and many folks in the Chef community use git,
but it is not required, except in the case of the cookbook site vendor
sub-command, as it uses git directly. Version control is strongly
recommended though, and git fits with a lot of the workflow paradigms.
EDITOR
chef-client(8) chef-server(8) shef(1)
knife-bootstrap(1) knife-client(1) knife-configure(1) knife-cookbook-site(1) knife-cookbook(1) knife-data-bag(1) knife-environment(1) knife-exec(1) knife-index(1) knife-node(1) knife-recipe(1) knife-role(1) knife-search(1) knife-ssh(1) knife-tag(1)
Complete Chef documentation is available online: http://wiki.opscode.com/display/chef/Home/
JSON is JavaScript Object Notation http://json.org/
SOLR is an open source search engine. http://lucene.apache.org/solr/
git(1) is a version control system http://git-scm.com/
This manual page was generated from Markdown with ronn(1) http://rtomayko.github.com/ronn/ronn.1.html
Chef was written by Adam Jacob adam@opscode.com of Opscode (http://www.opscode.com), with contributions from the community.
This manual page was written by Joshua Timberman joshua@opscode.com.
Both Chef and this documentation are released under the terms of the
Apache 2.0 License. You may view the license online: http://www.apache.org/licenses/LICENSE-2.0.html
On some systems, the complete text of the Apache 2.0 License may be found in /usr/share/common-licenses/Apache-2.0
.
Knife is distributed with Chef. http://wiki.opscode.com/display/chef/Home