chef 0.10.0.beta.7 → 0.10.0.beta.8

data/distro/common/man/man1/knife-ssh.1

@@ -0,0 +1,33 @@
+.\" generated with Ronn/v0.7.3
+.\" http://github.com/rtomayko/ronn/tree/0.7.3
+.
+.TH "KNIFE\-SSH" "1" "April 2011" "Chef 0.10.0.beta.8" "Chef Manual"
+.
+.SH "NAME"
+\fBknife\-ssh\fR \- Run a command or interactive session on multiple remote hosts
+.
+.SH "SYNOPSIS"
+\fBknife\fR \fBssh QUERY COMMAND\fR \fI(options)\fR
+.
+.TP
+\fB\-a\fR, \fB\-\-attribute ATTR\fR
+The attribute to use for opening the connection \- default is fqdn
+.
+.TP
+\fB\-C\fR, \fB\-\-concurrency NUM\fR
+The number of concurrent connections
+.
+.TP
+\fB\-m\fR, \fB\-\-manual\-list\fR
+QUERY is a space separated list of servers
+.
+.TP
+\fB\-P\fR, \fB\-\-ssh\-password PASSWORD\fR
+The ssh password
+.
+.TP
+\fB\-x\fR, \fB\-\-ssh\-user USERNAME\fR
+The ssh username
+.
+.P
+The \fIssh\fR sub\-command opens an ssh session to each of the nodes in the search results of the \fIQUERY\fR\. This sub\-command requires that the net\-ssh\-multi and highline Ruby libraries are installed\. On Debian systems, these are the libnet\-ssh\-multi\-ruby and libhighline\-ruby packages\. They can also be installed as RubyGems (net\-ssh\-multi and highline, respectively)\.

data/distro/common/man/man1/knife-status.1

@@ -0,0 +1,17 @@
+.\" generated with Ronn/v0.7.3
+.\" http://github.com/rtomayko/ronn/tree/0.7.3
+.
+.TH "KNIFE\-STATUS" "1" "April 2011" "Chef 0.10.0.beta.8" "Chef Manual"
+.
+.SH "NAME"
+\fBknife\-status\fR \- Display status information for the nodes in your infrastructure
+.
+.SH "SYNOPSIS"
+\fBknife\fR \fBstatus\fR \fI(options)\fR
+.
+.TP
+\fB\-r\fR, \fB\-\-run\-list RUN_LIST\fR
+Show the run list
+.
+.P
+The \fIstatus\fR sub\-command searches the Chef Server for all nodes and displays information about the last time the node checked into the server and executed a \fBnode\.save\fR\. The fields displayed are the relative checkin time, the node name, it\'s operating system platform and version, the fully\-qualified domain name and the default IP address\. If the \fB\-r\fR option is given, the node\'s run list will also be displayed\. Note that depending on the configuration of the nodes, the FQDN and IP displayed may not be publicly reachable\.

data/distro/common/man/man1/knife-tag.1

@@ -0,0 +1,13 @@
+.\" generated with Ronn/v0.7.3
+.\" http://github.com/rtomayko/ronn/tree/0.7.3
+.
+.TH "KNIFE\-TAG" "1" "April 2011" "Chef 0.10.0.beta.8" "Chef Manual"
+.
+.SH "NAME"
+\fBknife\-tag\fR \- Apply tags to nodes on a Chef Server
+.
+.SH "SYNOPSIS"
+\fBknife\fR \fBtag\fR \fIsubcommand\fR \fI(options)\fR
+.
+.SH "TAG SUBCOMMANDS"
+

data/distro/common/man/man1/knife.1

@@ -0,0 +1,346 @@
+.\" generated with Ronn/v0.7.3
+.\" http://github.com/rtomayko/ronn/tree/0.7.3
+.
+.TH "KNIFE" "1" "April 2011" "Chef 0.10.0.beta.8" "Chef Manual"
+.
+.SH "NAME"
+\fBknife\fR \- Chef Server REST API utility
+.
+.SH "SYNOPSIS"
+\fBknife\fR \fIsub\-command\fR \fI(options)\fR
+.
+.SH "DESCRIPTION"
+This manual page documents knife, a command\-line utility used to interact with a Chef server directly through the RESTful API\. Knife uses sub\-commands to take various actions on different types of Chef objects\. Some sub\-commands take additional options\. General options follow sub\-commands and their options\. A configuration file can be created for common defaults\.
+.
+.P
+Unless otherwise specified, output is in JSON format, and input files are also JSON format\.
+.
+.P
+The Chef class \fBChef::Config\fR that configures the behavior of how knife runs has options that correspond to command\-line options\. These are noted as \fBChef::Config\fR values\.
+.
+.SH "GENERAL OPTIONS"
+.
+.TP
+\fB\-s\fR, \fB\-\-server\-url\fR URL
+Chef Server URL, corresponds to \fBChef::Config\fR \fBchef_server_url\fR\.
+.
+.TP
+\fB\-k\fR, \fB\-\-key\fR KEY
+API Client Key, corresponds to \fBChef::Config\fR \fBclient_key\fR\.
+.
+.TP
+\fB\-c\fR, \fB\-\-config\fR CONFIG
+The configuration file to use
+.
+.TP
+\fB\-e\fR, \fB\-\-editor\fR EDITOR
+Set the editor to use for interactive commands
+.
+.TP
+\fB\-F\fR, \fB\-\-format\fR FORMAT
+Which format to use for output
+.
+.TP
+\fB\-l\fR, \fB\-\-log_level\fR LEVEL
+Set the log level (debug, info, warn, error, fatal), corresponds to \fBChef::Config\fR \fBlog_level\fR\.
+.
+.TP
+\fB\-L\fR, \fB\-\-logfile\fR LOGLOCATION
+Set the log file location, defaults to STDOUT, corresponds to \fBChef::Config\fR \fBlog_location\fR\.
+.
+.TP
+\fB\-n\fR, \fB\-\-no\-editor\fR
+Do not open EDITOR, just accept the data as is
+.
+.TP
+\fB\-u\fR, \fB\-\-user\fR USER
+API Client Username, corresponds to \fBChef::Config\fR \fBnode_name\fR\.
+.
+.TP
+\fB\-p\fR, \fB\-\-print\-after\fR
+Show the data after a destructive operation
+.
+.TP
+\fB\-v\fR, \fB\-\-version\fR
+Show chef version
+.
+.TP
+\fB\-y\fR, \fB\-\-yes\fR
+Say yes to all prompts for confirmation
+.
+.TP
+\fB\-h\fR, \fB\-\-help\fR
+Show this message
+.
+.P
+Usage information for sub\-commands can be displayed with \fBknife SUB\-COMMAND \-\-help\fR\.
+.
+.SH "SUB\-COMMANDS"
+Knife sub\-commands are structured as \fINOUN verb NOUN (options)\fR\. The sub\-commands are meant to be intuitively named\. Because the Chef Server API is RESTful, sub\-commands generally utilize CRUD operations\.
+.
+.IP "\(bu" 4
+create (create)
+.
+.IP "\(bu" 4
+list and show (read)
+.
+.IP "\(bu" 4
+edit (update)
+.
+.IP "\(bu" 4
+delete (destroy)
+.
+.IP "" 0
+.
+.P
+Objects stored on the server support these, as described below\.
+.
+.SH "GENERAL SUB\-COMMANDS"
+\fBrecipe list [PATTERN]\fR
+.
+.P
+List available recipes from the server\. Specify \fIPATTERN\fR as a regular expression to limit the results\.
+.
+.SH "CONFIGURATION"
+The knife configuration file is a Ruby DSL to set configuration parameters for Knife\'s \fBGENERAL OPTIONS\fR\. The default location for the config file is \fB~/\.chef/knife\.rb\fR\. If managing multiple Chef repositories, per\-repository config files can be created\. The file must be \fB\.chef/knife\.rb\fR in the current directory of the repository\.
+.
+.P
+If the config file exists, knife uses these settings for \fBGENERAL OPTIONS\fR defaults\.
+.
+.P
+\fBlog_level\fR
+.
+.P
+A Ruby symbol specifying the log level\. Corresponds to \fB\-l\fR or \fB\-\-log_level\fR option\. Default is \fI:info\fR\. Valid values are:
+.
+.IP "\(bu" 4
+:info
+.
+.IP "\(bu" 4
+:debug
+.
+.IP "\(bu" 4
+:warn
+.
+.IP "\(bu" 4
+:fatal
+.
+.IP "" 0
+.
+.P
+\fBlog_location\fR
+.
+.P
+Corresponds to the \fB\-L\fR or \fB\-\-log\-file\fR option\. Defaults is \fBSTDOUT\fR\. Valid values are \fBSTDOUT\fR or a filename\.
+.
+.P
+\fBnode_name\fR
+.
+.P
+User to authenticate to the Chef server\. Corresponds to the \fB\-u\fR or \fB\-\-user\fR option\. This is requested from the user when running this sub\-command\.
+.
+.P
+\fBclient_key\fR
+.
+.P
+Private key file to authenticate to the Chef server\. Corresponds to the \fB\-k\fR or \fB\-\-key\fR option\. This is requested from the user when running this sub\-command\.
+.
+.P
+\fBchef_server_url\fR
+.
+.P
+URL of the Chef server\. Corresponds to the \fB\-s\fR or \fB\-\-server\-url\fR option\. This is requested from the user when running this sub\-command\.
+.
+.P
+\fBcache_type\fR
+.
+.P
+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\.
+.
+.P
+\fBcache_options\fR
+.
+.P
+Specifies various options to use for caching\. Default reads the Chef client configuration (/etc/chef/checksums)\.
+.
+.P
+\fBvalidation_client_name\fR
+.
+.P
+Specifies the name of the client used to validate new clients\. This is requested from the user when running the configuration sub\-command\.
+.
+.P
+\fBvalidation_key\fR
+.
+.P
+Specifies the private key file to use for generating ec2 instance data for validating new clients\. This is implied from the \fBvalidation_client_name\fR\.
+.
+.P
+\fBcookbook_copyright\fR \fBcookbook_email\fR \fBcookbook_license\fR
+.
+.P
+Used by \fBknife cookbook create\fR sub\-command to specify the copyright holder, maintainer email and license (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\.
+.
+.P
+\fBknife[:aws_access_key_id]\fR \fBknife[:aws_secret_access_key]\fR
+.
+.P
+Specifies the Amazon AWS EC2 credentials to use when running the ec2 sub\-commands\.
+.
+.P
+\fBknife[:rackspace_api_username]\fR \fBknife[:rackspace_api_key]\fR
+.
+.P
+Specifies the Rackspace Cloud credentials to use when running the rackspace sub\-commands\.
+.
+.P
+\fBknife[:terremark_username]\fR \fBknife[:terremark_password]\fR \fBknife[:terremark_service]\fR
+.
+.P
+Specifies the Terremark vCloud credentials to use when running the terremark sub\-commands\.
+.
+.P
+\fBknife[:slicehost_password]\fR
+.
+.P
+Specifies the Slicehost password to use when running the slicdehost sub\-commands\.
+.
+.SH "FILES"
+\fI~/\.chef/knife\.rb\fR
+.
+.P
+Ruby DSL configuration file for knife\. See \fBCONFIGURATION\fR\.
+.
+.SH "CHEF WORKFLOW"
+When working with Chef and Knife in the local repository, the recommended workflow outline looks like:
+.
+.IP "\(bu" 4
+Create repository\. A skeleton sample is provided at \fIhttp://github\.com/opscode/chef\-repo/\fR\.
+.
+.IP "\(bu" 4
+Configure knife, see \fBCONFIGURATION\fR\.
+.
+.IP "\(bu" 4
+Download cookbooks from the Opscode cookbooks site, see \fBCOOKBOOK SITE SUB\-COMMANDS\fR\.
+.
+.IP "\(bu" 4
+Or, create new cookbooks, see \fBcookbook create\fR sub\-command\.
+.
+.IP "\(bu" 4
+Commit changes to the version control system\. See your tool\'s documentation\.
+.
+.IP "\(bu" 4
+Upload cookbooks to the Chef Server, see \fBCOOKBOOK SUB\-COMMANDS\fR\.
+.
+.IP "\(bu" 4
+Launch instances in the Cloud, OR provision new hosts; see \fBCLOUD COMPUTING SUB\-COMMANDS\fR and \fBBOOTSTRAP SUB\-COMMANDS\fR\.
+.
+.IP "\(bu" 4
+Watch Chef configure systems!
+.
+.IP "" 0
+.
+.P
+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 \fBcookbook site vendor\fR sub\-command, as it uses git directly\. Version control is strongly recommended though, and git fits with a lot of the workflow paradigms\.
+.
+.SH "EXAMPLES"
+Example client config (\fB/etc/chef/client\.rb\fR) from \fBknife configure client\fR\. The same configuration is used when using the \fBknife bootstrap\fR command with the default \fBgem\fR templates that come with Chef\.
+.
+.IP "" 4
+.
+.nf
+
+log_level        :info
+log_location     STDOUT
+chef_server_url  \'https://api\.opscode\.com/organizations/ORGNAME\'
+validation_client_name \'ORGNAME\-validator\'
+.
+.fi
+.
+.IP "" 0
+.
+.P
+Setting up a custom bootstrap is fairly straightforward\. Create \fB\.chef/bootstrap\fR in your Chef Repository directory or in \fB$HOME/\.chef/bootstrap\fR\. Then create the ERB template file\.
+.
+.IP "" 4
+.
+.nf
+
+mkdir ~/\.chef/bootstrap
+vi ~/\.chef/bootstrap/debian5\.0\-apt\.erb
+.
+.fi
+.
+.IP "" 0
+.
+.P
+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:
+.
+.IP "" 4
+.
+.nf
+
+knife bootstrap mynode\.example\.com \-\-template\-file ~/\.chef/bootstrap/debian5\.0\-apt\.erb
+.
+.fi
+.
+.IP "" 0
+.
+.P
+Or,
+.
+.IP "" 4
+.
+.nf
+
+knife bootstrap mynode\.example\.com \-\-distro debian5\.0\-apt
+.
+.fi
+.
+.IP "" 0
+.
+.P
+The \fB\-\-distro\fR parameter will automatically look in the \fB~/\.chef/bootstrap\fR directory for a file named \fBdebian5\.0\-apt\.erb\fR\.
+.
+.P
+Templates provided by the Chef installation are located in \fBBASEDIR/lib/chef/knife/bootstrap/*\.erb\fR, where \fIBASEDIR\fR is the location where the package or Gem installed the Chef client libraries\.
+.
+.P
+Uploading cookbooks to the Opscode cookbooks site using the user/certificate specifically:
+.
+.IP "" 4
+.
+.nf
+
+knife cookbook site share example Other \-k ~/\.chef/USERNAME\.pem \-u USERNAME
+.
+.fi
+.
+.IP "" 0
+.
+.SH "ENVIRONMENT"
+.
+.TP
+\fBEDITOR\fR
+The text editor to use for editing data\. The \-\-editor option takes precedence over this value, and the \-\-no\-editor option supresses data editing entirely\.
+.
+.SH "SEE ALSO"
+Full documentation for Chef is located on the Chef wiki, http://wiki\.opscode\.com/display/chef/Home/\.
+.
+.P
+JSON is JavaScript Object Notation and more information can be found at http://json\.org/\.
+.
+.P
+SOLR is an open source search engine\. The Chef Server includes a SOLR installation\. More information about SOLR, including the search query syntax, can be found at http://lucene\.apache\.org/solr/\.
+.
+.P
+Git is a version control system and documented at http://git\-scm\.com/\.
+.
+.P
+This manual page was generated in nroff from Markdown with ronn\. Ryan Tomayko wrote ronn and more information can be found at http://rtomayko\.github\.com/ronn/ronn\.5\.html\.
+.
+.SH "AUTHOR"
+Chef was written by Adam Jacob \fIadam@opscode\.com\fR of Opscode (\fIhttp://www\.opscode\.com\fR), with contributions from the community\. This manual page was written by Joshua Timberman \fIjoshua@opscode\.com\fR\. Permission is granted to copy, distribute and / or modify this document under the terms of the Apache 2\.0 License\.
+.
+.P
+On Debian systems, the complete text of the Apache 2\.0 License can be found in \fB/usr/share/common\-licenses/Apache\-2\.0\fR\.

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

@@ -0,0 +1,88 @@
+knife-bootrap(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
+  * `--prerelease`:
+    Install pre-release Chef gems
+  * `-r`, `--run-list RUN_LIST`:
+    Comma separated list of roles/recipes to apply
+  * `-P`, `--ssh-password PASSWORD`:
+    The ssh password
+  * `-x`, `--ssh-user USERNAME`:
+    The ssh username
+  * `--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
+
+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
+server create commands and the others will be migrated in a future
+version of Chef.
+
+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). As of Chef 0.9.8, 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. The RubyGems installation requires installing gems with native extensions, so development related packages (ruby-dev, build-essential) are installed. These are not installed with the apt installation, as native extensions are already compiled in the required packages.
+
+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 specfied.
+
+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.
+
+
+## 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://wiki.opscode.com/display/chef/Home>