knife-client.1

.\" generated with Ronn/v0.7.3
.\" http://github.com/rtomayko/ronn/tree/0.7.3
.
.TH "KNIFE\-CLIENT" "1" "April 2011" "Chef 0.10.0.rc.2" "Chef Manual"
.
.SH "NAME"
\fBknife\-client\fR \- Manage Chef API Clients
.
.SH "SYNOPSIS"
\fBknife\fR \fBclient\fR \fIsub\-command\fR \fI(options)\fR
.
.SH "SUB\-COMMANDS"
Client subcommands follow a basic create, read, update, delete (CRUD) pattern\. The Following subcommands are available:
.
.SH "BULK DELETE"
\fBknife client bulk delete\fR \fIregex\fR \fI(options)\fR
.
.P
Delete clients where the client name matches the regular expression \fIregex\fR on the Chef Server\. The regular expression should be given as a quoted string, and not surrounded by forward slashes\.
.
.SH "CREATE"
\fBknife client create\fR \fIclient name\fR \fI(options)\fR
.
.TP
\fB\-a\fR, \fB\-\-admin\fR
Create the client as an admin
.
.TP
\fB\-f\fR, \fB\-\-file FILE\fR
Write the key to a file
.
.P
Create a new client\. This generates an RSA keypair\. The private key will be displayed on \fISTDOUT\fR or written to the named file\. The public half will be stored on the Server\. For \fIchef\-client\fR systems, the private key should be copied to the system as \fB/etc/chef/client\.pem\fR\.
.
.P
Admin clients should be created for users that will use \fIknife\fR to access the API as an administrator\. The private key will generally be copied to \fB~/\.chef/client\e_name\.pem\fR and referenced in the \fBknife\.rb\fR configuration file\.
.
.SH "DELETE"
\fBknife client delete\fR \fIclient name\fR \fI(options)\fR
.
.P
Deletes a registered client\.
.
.SH "EDIT"
\fBclient edit\fR \fIclient name\fR \fI(options)\fR
.
.P
Edit a registered client\.
.
.SH "LIST"
\fBclient list\fR \fI(options)\fR
.
.TP
\fB\-w\fR, \fB\-\-with\-uri\fR
Show corresponding URIs
.
.P
List all registered clients\.
.
.SH "REREGISTER"
\fBclient reregister\fR \fIclient name\fR \fI(options)\fR
.
.TP
\fB\-f\fR, \fB\-\-file FILE\fR
Write the key to a file
.
.P
Regenerate the RSA keypair for a client\. The public half will be stored on the server and the private key displayed on \fISTDOUT\fR 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\.
.
.SH "SHOW"
\fBclient show\fR \fIclient name\fR \fI(options)\fR
.
.TP
\fB\-a\fR, \fB\-\-attribute ATTR\fR
Show only one attribute
.
.P
Show a client\. Output format is determined by the \-\-format option\.
.
.SH "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\.
.
.P
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\.
.
.P
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\.
.
.SH "SEE ALSO"
\fBknife\-node\fR(1)
.
.SH "AUTHOR"
Chef was written by Adam Jacob \fIadam@opscode\.com\fR with many contributions from the community\.
.
.SH "DOCUMENTATION"
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\.
.
.SH "CHEF"
Knife is distributed with Chef\. \fIhttp://wiki\.opscode\.com/display/chef/Home\fR