microwave 1.0.2 → 1.0.3

data/distro/common/man/man8/chef-solo.8

@@ -1,158 +0,0 @@
-.\" generated with Ronn/v0.7.3
-.\" http://github.com/rtomayko/ronn/tree/0.7.3
-.
-.TH "CHEF\-SOLO" "8" "October 2012" "Chef 10.16.0.rc.1" "Chef Manual"
-.
-.SH "NAME"
-\fBchef\-solo\fR \- Runs chef in solo mode against a specified cookbook location\.
-.
-.SH "SYNOPSIS"
-\fBchef\-solo\fR \fI(options)\fR
-.
-.TP
-\fB\-c\fR, \fB\-\-config CONFIG\fR
-The configuration file to use
-.
-.TP
-\fB\-d\fR, \fB\-\-daemonize\fR
-Daemonize the process
-.
-.TP
-\fB\-g\fR, \fB\-\-group GROUP\fR
-Group to set privilege to
-.
-.TP
-\fB\-i\fR, \fB\-\-interval SECONDS\fR
-Run chef\-client periodically, in seconds
-.
-.TP
-\fB\-j\fR, \fB\-\-json\-attributes JSON_ATTRIBS\fR
-Load attributes from a JSON file or URL
-.
-.TP
-\fB\-l\fR, \fB\-\-log_level LEVEL\fR
-Set the log level (debug, info, warn, error, fatal)
-.
-.TP
-\fB\-L\fR, \fB\-\-logfile LOGLOCATION\fR
-Set the log file location, defaults to STDOUT \- recommended for daemonizing
-.
-.TP
-\fB\-N\fR, \fB\-\-node\-name NODE_NAME\fR
-The node name for this client
-.
-.TP
-\fB\-r\fR, \fB\-\-recipe\-url RECIPE_URL\fR
-Pull down a remote gzipped tarball of recipes and untar it to the cookbook cache\.
-.
-.TP
-\fB\-s\fR, \fB\-\-splay SECONDS\fR
-The splay time for running at intervals, in seconds
-.
-.TP
-\fB\-u\fR, \fB\-\-user USER\fR
-User to set privilege to
-.
-.TP
-\fB\-v\fR, \fB\-\-version\fR
-Show chef version
-.
-.TP
-\fB\-h\fR, \fB\-\-help\fR
-Show this message
-.
-.SH "DESCRIPTION"
-Chef Solo allows you to run Chef Cookbooks in the absence of a Chef Server\. To do this, the complete cookbook needs to be present on disk\.
-.
-.P
-By default Chef Solo will look in /etc/chef/solo\.rb for its configuration\. This configuration file has two required variables: file_cache_path and cookbook_path\.
-.
-.P
-For example:
-.
-.IP "" 4
-.
-.nf
-
-file_cache_path "/var/chef\-solo"
-cookbook_path "/var/chef\-solo/cookbooks"
-.
-.fi
-.
-.IP "" 0
-.
-.P
-For your own systems, you can change this to reflect any directory you like, but you\'ll need to specify absolute paths and the cookbook_path directory should be a subdirectory of the file_cache_path\.
-.
-.P
-You can also specify cookbook_path as an array, passing multiple locations to search for cookbooks\.
-.
-.P
-For example:
-.
-.IP "" 4
-.
-.nf
-
-file_cache_path "/var/chef\-solo"
-cookbook_path ["/var/chef\-solo/cookbooks", "/var/chef\-solo/site\-cookbooks"]
-.
-.fi
-.
-.IP "" 0
-.
-.P
-Note that earlier entries are now overridden by later ones\.
-.
-.P
-Since chef\-solo doesn\'t have any interaction with a Chef Server, you\'ll need to specify node\-specifc attributes in a JSON file\. This can be located on the target system itself, or it can be stored on a remote server such as S3, or a web server on your network\.
-.
-.P
-Within the JSON file, you\'ll also specify the recipes that Chef should run in the "run_list"\. An example JSON file, which sets a resolv\.conf:
-.
-.IP "" 4
-.
-.nf
-
-{
-  "resolver": {
-    "nameservers": [ "10\.0\.0\.1" ],
-    "search":"int\.example\.com"
-  },
-  "run_list": [ "recipe[resolver]" ]
-}
-.
-.fi
-.
-.IP "" 0
-.
-.P
-Then you can run chef\-solo with \-j to specify the JSON file\. It will look for cookbooks in the cookbook_path configured in the configuration file, and apply attributes and use the run_list from the JSON file specified\.
-.
-.P
-You can use \-c to specify the path to the configuration file (if you don\'t want chef\-solo to use the default)\. You can also specify \-r for a cookbook tarball\.
-.
-.P
-For example:
-.
-.IP "" 4
-.
-.nf
-
-chef\-solo \-c ~/solo\.rb \-j ~/node\.json  \-r http://www\.example\.com/chef\-solo\.tar\.gz
-.
-.fi
-.
-.IP "" 0
-.
-.P
-In the above case, chef\-solo would extract the tarball to your specified cookbook_path, use ~/solo\.rb as the configuration file, and apply attributes and use the run_list from ~/node\.json\.
-.
-.SH "SEE ALSO"
-Full documentation for Chef and chef\-solo is located on the Chef wiki, http://wiki\.opscode\.com/display/chef/Home\.
-.
-.SH "AUTHOR"
-Chef was written by Adam Jacob \fIadam@ospcode\.com\fR of Opscode (http://www\.opscode\.com), with contributions from the community\. This manual page was written by Joshua Timberman \fIjoshua@opscode\.com\fR with help2man\. 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 /usr/share/common\-licenses/Apache\-2\.0\.

data/distro/common/man/man8/chef-solr.8

@@ -1,122 +0,0 @@
-.\" generated with Ronn/v0.7.3
-.\" http://github.com/rtomayko/ronn/tree/0.7.3
-.
-.TH "CHEF\-SOLR" "8" "October 2012" "Chef 10.16.0.rc.1" "Chef Manual"
-.
-.SH "NAME"
-\fBchef\-solr\fR \- Runs as Chef\'s search server
-.
-.SH "SYNOPSIS"
-\fBchef\-solr\fR \fI(options)\fR
-.
-.TP
-\fB\-c\fR, \fB\-\-config CONFIG\fR
-The configuration file to use
-.
-.TP
-\fB\-d\fR, \fB\-\-daemonize\fR
-Daemonize the process
-.
-.TP
-\fB\-g\fR, \fB\-\-group GROUP\fR
-Group to set privilege to
-.
-.TP
-\fB\-l\fR, \fB\-\-log_level LEVEL\fR
-Set the log level (debug, info, warn, error, fatal)
-.
-.TP
-\fB\-L\fR, \fB\-\-logfile LOGLOCATION\fR
-Set the log file location, defaults to STDOUT \- recommended for daemonizing
-.
-.TP
-\fB\-P\fR, \fB\-\-pid PIDFILE\fR
-Set the PID file location, defaults to /tmp/chef\-solr\.pid
-.
-.TP
-\fB\-D\fR, \fB\-\-solr\-data\-dir PATH\fR
-Where the Solr data lives
-.
-.TP
-\fB\-x\fR, \fB\-\-solor\-heap\-size SIZE\fR
-Set the size of the Java Heap
-.
-.TP
-\fB\-H\fR, \fB\-\-solr\-home\-dir PATH\fR
-Solr home directory
-.
-.TP
-\fB\-j\fR, \fB\-\-java\-opts OPTS\fR
-Raw options passed to Java
-.
-.TP
-\fB\-x\fR, \fB\-\-solor\-heap\-size\fR
-Set the size of the Java Heap
-.
-.TP
-\fB\-W\fR, \fB\-\-solr\-jetty\-dir PATH\fR
-Where to place the Solr Jetty instance
-.
-.TP
-\fB\-u\fR, \fB\-\-user USER\fR
-User to set privilege to
-.
-.TP
-\fB\-v\fR, \fB\-\-version\fR
-Show chef\-solr version
-.
-.TP
-\fB\-h\fR, \fB\-\-help\fR
-Show this message
-.
-.SH "DESCRIPTION"
-Chef\-solr provides search service for Chef\. You need to have both chef\-solr and chef\-expander\-cluster running in order for search to work\.
-.
-.P
-\fBInstallation\fR
-.
-.P
-Make sure you backed up your data if you are upgrading from a previous version\. Run chef\-solr\-installer to upgrade your Chef Solr installation\. Answer "yes" when prompted for confirmation\. The process should look like this:
-.
-.IP "" 4
-.
-.nf
-
-yourshell> chef\-solr\-installer
-Configuration setting solr_heap_size is unknown and will be ignored
-
-Chef Solr is already installed in /var/chef/solr
-Do you want to overwrite the current install? All existing Solr data will be lost\. [y/n] y
-Removing the existing Chef Solr installation
-  rm \-rf /var/chef/solr
-  rm \-rf /var/chef/solr\-jetty
-  rm \-rf /var/chef/solr/data
-Creating Solr Home Directory
-  mkdir \-p /var/chef/solr
-  entering /var/chef/solr
-  tar zxvf /Users/ddeleo/opscode/chef/chef\-solr/solr/solr\-home\.tar\.gz
-Creating Solr Data Directory
-  mkdir \-p /var/chef/solr/data
-Unpacking Solr Jetty
-  mkdir \-p /var/chef/solr\-jetty
-  entering /var/chef/solr\-jetty
-  tar zxvf /Users/ddeleo/opscode/chef/chef\-solr/solr/solr\-jetty\.tar\.gz
-
-Successfully installed Chef Solr\.
-You can restore your search index using `knife index rebuild`
-.
-.fi
-.
-.IP "" 0
-.
-.SH "SEE ALSO"
-\fBchef\-expander\-cluster\fR(8)
-.
-.P
-Full documentation for Chef and chef\-server is located on the Chef wiki, http://wiki\.opscode\.com/display/chef/Home\.
-.
-.SH "AUTHOR"
-Chef was written by Adam Jacob \fIadam@ospcode\.com\fR of Opscode (http://www\.opscode\.com), with contributions from the community\. This manual page was written by Joshua Timberman \fIjoshua@opscode\.com\fR with help2man\. 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 /usr/share/common\-licenses/Apache\-2\.0\.

data/distro/common/markdown/README

@@ -1,3 +0,0 @@
-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/knife-bootstrap.mkd

@@ -1,141 +0,0 @@
-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 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.
-
-## 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://wiki.opscode.com/display/chef/Home>

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

@@ -1,103 +0,0 @@
-knife-client(1) -- Manage Chef API Clients
-========================================
-
-## SYNOPSIS
-
-__knife__ __client__ _sub-command_ _(options)_
-
-## SUB-COMMANDS
-Client subcommands follow a basic create, read, update, delete (CRUD)
-pattern. The Following subcommands are available:
-
-## BULK DELETE
-__knife client bulk delete__ _regex_ _(options)_
-
-Delete clients where the client name matches the regular expression
-_regex_ on the Chef Server. The regular expression should be given as a
-quoted string, and not surrounded by forward slashes.
-
-## CREATE
-__knife client create__ _client name_ _(options)_
-
-  * `-a`, `--admin    `:
-    Create the client as an admin
-  * `-f`, `--file FILE`:
-    Write the key to a file
-
-Create a new client. This generates an RSA keypair. The private key will
-be displayed on _STDOUT_ or written to the named file. The public half
-will be stored on the Server. For _chef-client_ systems, the private key
-should be copied to the system as `/etc/chef/client.pem`.
-
-Admin clients should be created for users that will use _knife_ to
-access the API as an administrator. The private key will generally be
-copied to `~/.chef/client\_name.pem` and referenced in the `knife.rb`
-configuration file.
-
-## DELETE
-__knife client delete__ _client name_  _(options)_
-
-Deletes a registered client.
-
-## EDIT
-__client edit__ _client name_ _(options)_
-
-Edit a registered client.
-
-## LIST
-__client list__ _(options)_
-
-  * `-w`, `--with-uri`:
-      Show corresponding URIs
-
-List all registered clients.
-
-## REREGISTER
-__client reregister__ _client name_  _(options)_
-
-  * `-f`, `--file FILE`:
-    Write the key to a file
-
-Regenerate the RSA keypair for a client. The public half will be stored
-on the server and the private key displayed on _STDOUT_ or written to
-the named file. This operation will invalidate the previous keypair used
-by the client, preventing it from authenticating with the Chef Server.
-Use care when reregistering the validator client.
-
-## SHOW
-__client show__ _client name_ _(options)_
-
-  * `-a`, `--attribute ATTR`:
-    Show only one attribute
-
-Show a client. Output format is determined by the --format option.
-
-## DESCRIPTION
-Clients are identities used for communication with the Chef Server API,
-roughly equivalent to user accounts on the Chef Server, except that
-clients only communicate with the Chef Server API and are authenticated
-via request signatures.
-
-In the typical case, there will be one client object on the server for
-each node, and the corresponding client and node will have identical
-names.
-
-In the Chef authorization model, there is one special client, the
-"validator", which is authorized to create new non-administrative
-clients but has minimal privileges otherwise. This identity is used as a
-sort of "guest account" to create a client identity when initially
-setting up a host for management with Chef.
-
-## SEE ALSO
-   __knife-node__(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>
-