A node is any physical, virtual, or cloud machine that is configured to be maintained by a chef-client. A bootstrap is a process that installs the chef-client on a target system so that it can run as a chef-client and communicate with a Chef server. There are two ways to do this:
knife bootstrap
subcommand to bootstrap a node using the omnibus installer
Use the knife bootstrap
subcommand to run a bootstrap operation that installs the chef-client on the target system. The bootstrap operation must specify the IP address or FQDN of the target system.
Note
Starting with chef-client 12.0, use the knife ssl_fetch command to pull down the SSL certificates from the on-premises Chef server and add them to the /trusted_certs_dir
on the workstation. This certificates is used during a knife bootstrap operation.
Note
To bootstrap the chef-client on Microsoft Windows machines, the knife-windows plugins is required, which includes the necessary bootstrap scripts that are used to do the actual installation.
This subcommand has the following syntax:
$ knife bootstrap FQDN_or_IP_ADDRESS (options)
Note
Review the list of common options available to this (and all) knife subcommands and plugins.
This subcommand has the following options:
-A
, --forward-agent
--bootstrap-curl-options OPTIONS
--bootstrap-install-command
.--bootstrap-install-command COMMAND
--bootstrap-curl-options
, --bootstrap-install-sh
, or --bootstrap-wget-options
.--bootstrap-install-sh URL
--bootstrap-install-command
.--bootstrap-no-proxy NO_PROXY_URL_or_IP
A URL or IP address that specifies a location that should not be proxied.
Note
This option is used internally by Chef to help verify bootstrap operations during testing and should never be used during an actual bootstrap operation.
--bootstrap-proxy PROXY_URL
--bootstrap-vault-file VAULT_FILE
--bootstrap-vault-item VAULT_ITEM
vault:item
.--bootstrap-vault-json VAULT_JSON
A JSON string that contains a list of vaults and items to be updated.
For example:
--bootstrap-vault-json '{ "vault1": ["item1", "item2"], "vault2": "item2" }'
--bootstrap-version VERSION
--bootstrap-wget-options OPTIONS
--bootstrap-install-command
.-E ENVIRONMENT
, --environment ENVIRONMENT
-G GATEWAY
, --ssh-gateway GATEWAY
--hint HINT_NAME[=HINT_FILE]
An Ohai hint to be set on the target node.
Ohai hints are used to tell Ohai something about the system that it is running on that it would not be able to discover itself. An Ohai hint exists if a JSON file exists in the hint directory with the same name as the hint. For example, calling hint?('antarctica')
in an Ohai plugin would return an empty hash if the file antarctica.json
existed in the hints directory, and return nil if the file does not exist.
If the hint file contains JSON content, it will be returned as a hash from the call to hint?
.
{ "snow": true, "penguins": "many" }
antarctica_hint = hint?('antarctica') if antarctica_hint['snow'] "There are #{antarctica_hint['penguins']} penguins here." else 'There is no snow here, and penguins like snow.' end
The default directory in which hint files are located is /etc/chef/ohai/hints/
. Use the Ohai::Config[:hints_path]
setting in the client.rb file to customize this location.
HINT_FILE
is the name of the JSON file. HINT_NAME
is the name of a hint in a JSON file. Use multiple --hint
options to specify multiple hints.
-i IDENTITY_FILE
, --ssh-identity-file IDENTITY_FILE
-j JSON_ATTRIBS
, --json-attributes JSON_ATTRIBS
-N NAME
, --node-name NAME
The name of the node.
Note
This option is required for a validatorless bootstrap (as of chef-client version 12.4).
--[no-]fips
--[no-]host-key-verify
--no-host-key-verify
to disable host key verification. Default setting: --host-key-verify
.--[no-]node-verify-api-cert
true
, the chef-client always verifies the SSL certificate. When false
, the chef-client uses the value of ssl_verify_mode
to determine if the SSL certificate requires verification. If this option is not specified, the setting for verify_api_cert
in the configuration file is applied.--node-ssl-verify-mode PEER_OR_NONE
Set the verify mode for HTTPS requests.
Use none
to do no validation of SSL certificates.
Use peer
to do validation of all SSL certificates, including the Chef server connections, S3 connections, and any HTTPS remote_file resource URLs used in the chef-client run. This is the recommended setting.
-p PORT
, --ssh-port PORT
-P PASSWORD
, --ssh-password PASSWORD
--prerelease
-r RUN_LIST
, --run-list RUN_LIST
--secret SECRET
--secret-file FILE
--sudo
--sudo-preserve-home
HOME
environment.-t TEMPLATE
, --bootstrap-template TEMPLATE
chef-full
, for example—or it may be the full path to an Embedded Ruby (ERB) template that defines a custom bootstrap. Default value: chef-full
, which installs the chef-client using the omnibus installer on all supported platforms.--use-sudo-password
-P
(or --ssh-password
) option.-V -V
debug
log-level (e.g. chef-client -l debug
).-x USERNAME
, --ssh-user USERNAME
Note
See knife.rb for more information about how to add certain knife options as settings in the knife.rb file.
The ORGANIZATION-validator.pem is typically added to the .chef directory on the workstation. When a node is bootstrapped from that workstation, the ORGANIZATION-validator.pem is used to authenticate the newly-created node to the Chef server during the initial chef-client run. Starting with chef-client version 12.1, it is possible to bootstrap a node using the USER.pem file instead of the ORGANIZATION-validator.pem file. This is known as a “validatorless bootstrap”.
To create a node via the USER.pem file, simply delete the ORGANIZATION-validator.pem file on the workstation. For example:
$ rm -f /home/lamont/.chef/myorg-validator.pem
and then make the following changes in the knife.rb file:
validation_client_name
settingvalidation_key
setting to be something that isn’t a path to an existent ORGANIZATION-validator.pem file. For example: /nonexist
.As long as a USER.pem is also present on the workstation from which the validatorless bootstrap operation will be initiated, the bootstrap operation will run and will use the USER.pem file instead of the ORGANIZATION-validator.pem file.
When running a validatorless knife bootstrap
operation, the output is similar to:
desktop% knife bootstrap 10.1.1.1 -N foo01.acme.org \ -E dev -r 'role[base]' -j '{ "foo": "bar" }' \ --ssh-user vagrant --sudo Node foo01.acme.org exists, overwrite it? (Y/N) Client foo01.acme.org exists, overwrite it? (Y/N) Creating new client for foo01.acme.org Creating new node for foo01.acme.org Connecting to 10.1.1.1 10.1.1.1 Starting first Chef Client run... [....etc...]
knife bootstrap
OptionsUse the following options with a validatorless bootstrap to specify items that are stored in chef-vault:
--bootstrap-vault-file VAULT_FILE
--bootstrap-vault-item VAULT_ITEM
vault:item
.--bootstrap-vault-json VAULT_JSON
A JSON string that contains a list of vaults and items to be updated.
For example:
--bootstrap-vault-json '{ "vault1": ["item1", "item2"], "vault2": "item2" }'
Federal Information Processing Standards (FIPS) is a United States government computer security standard that specifies security requirements for cryptography. The current version of the standard is FIPS 140-2. The chef-client can be configured to allow OpenSSL to enforce FIPS-validated security during a chef-client run. This will disable cryptography that is explicitly disallowed in FIPS-validated software, including certain ciphers and hashing algorithms. Any attempt to use any disallowed cryptography will cause the chef-client to throw an exception during a chef-client run.
Note
Chef uses MD5 hashes to uniquely identify files that are stored on the Chef server. MD5 is used only to generate a unique hash identifier and is not used for any cryptographic purpose.
Notes about FIPS:
Bootstrap a node using FIPS
$ knife bootstrap 12.34.56.789 -P vanilla -x root -r 'recipe[apt],recipe[xfs],recipe[vim]' --fips
which shows something similar to:
OpenSSL FIPS 140 mode enabled ... 12.34.56.789 Chef Client finished, 12/12 resources updated in 78.942455583 seconds
The chef-full
distribution uses the omnibus installer. For most bootstrap operations, regardless of the platform on which the target node is running, using the chef-full
distribution is the best approach for installing the chef-client on a target node. In some situations, using another supported distribution is necessary. And in some situations, a custom template may be required.
For example, the default bootstrap operation relies on an Internet connection to get the distribution to the target node. If a target node cannot access the Internet, then a custom template can be used to define a specific location for the distribution so that the target node may access it during the bootstrap operation.
For example, a bootstrap template file named “sea_power”:
$ knife bootstrap 123.456.7.8 -x username -P password --sudo --bootstrap-template "sea_power"
The following examples show how a bootstrap template file can be customized for various platforms.
A custom bootstrap template file must be located in a bootstrap/
directory, which is typically located within the ~/.chef/
directory on the local workstation.
Use the --bootstrap-template
option with the knife bootstrap
subcommand to specify the name of the bootstrap template file. This location is configurable when the following setting is added to the knife.rb file:
Setting | Description |
---|---|
knife[:bootstrap_template] | The path to a template file to be used during a bootstrap operation. |
The following example shows how to modify the default script for Ubuntu 14.04. First, copy the bootstrap template from the default location. If the chef-client is installed from a RubyGems, the full path can be found in the gem contents. For example:
$ gem contents chef | grep ubuntu12.04-gems /Users/grantmc/.rvm/gems/ruby-2.0/gems/chef-12.0.2/lib/chef/knife/bootstrap/ubuntu14.04-gems.erb
Copy the template to the chef-repo in the .chef/bootstrap
directory:
$ cp /Users/grantmc/.rvm/gems/ruby-2.0/gems/chef-12.0.2/ lib/chef/knife/bootstrap/ubuntu14.04-gems.erb ~/chef-repo/.chef/ bootstrap/ubuntu14.04-gems-mine.erb
Modify the template with any editor, then specify it using the --bootstrap-template
option as part of the the knife bootstrap
operation, or with any of the knife plug-ins that support cloud computing.
$ knife bootstrap 192.168.1.100 -r 'role[webserver]' -bootstrap-template ubuntu14.04-gems-mine
Alternatively, an example bootstrap template can be found in the git source for the chef-repo: https://github.com/chef/chef/tree/master/lib/chef/knife/bootstrap. Copy the template to ~/.chef-repo/.chef/bootstrap/ubuntu14.04-apt.erb
and modify the template appropriately.
The following example shows how to use the knife bootstrap
subcommand to create a client configuration file (/etc/chef/client.rb) that uses Hosted Chef as the Chef server. The configuration file will look something like:
log_level :info log_location STDOUT chef_server_url 'https://api.opscode.com/organizations/NAME' validation_client_name 'ORGNAME-validator'
The knife bootstrap
subcommand will look in three locations for the template that is used during the bootstrap operation. The locations are:
$PWD/.chef
, e.g. in ~/chef-repo/.chef
$HOME/.chef
If, in the example above, the second location was used, then create the .chef/bootstrap/
directory in the chef-repo, and then create the Embedded Ruby (ERB) template file by running commands similar to the following:
mkdir ~/.chef/bootstrap vi ~/.chef/bootstrap/debian6.0-apt.erb
When finished creating the directory and the Embedded Ruby (ERB) template file, edit the template to run the SSH commands. Then set up the validation certificate and the client configuration file.
Finally, run the chef-client on the node using a knife bootstrap
command that specifies a run-list (the -r
option). The bootstrap template can be called using a command similar to the following:
$ knife bootstrap mynode.example.com -r 'role[webserver]','role[production]' --bootstrap-template debian6.0-apt
The following example shows how to modify the default script for Microsoft Windows and Windows PowerShell:
@setlocal <%= "SETX HTTP_PROXY \"#{knife_config[:bootstrap_proxy]}\"" if knife_config[:bootstrap_proxy] %> @mkdir <%= bootstrap_directory %> > <%= bootstrap_directory %>\wget.ps1 ( <%= win_wget_ps %> ) :install @rem Install Chef using chef-client MSI installer <% url="http://reposerver.example.com/chef-client-12.0.2.windows.msi" -%> @set "REMOTE_SOURCE_MSI_URL=<%= url %>" @set "LOCAL_DESTINATION_MSI_PATH=<%= local_download_path %>" @powershell -ExecutionPolicy Unrestricted -NoProfile -NonInteractive "& '<%= bootstrap_directory %>\wget.ps1' '%REMOTE_SOURCE_MSI_URL%' '%LOCAL_DESTINATION_MSI_PATH%'" @REM Replace install_chef from knife-windows Gem with one that has extra flags to turn on Chef service feature -- only available in Chef >= 12.0.x @REM <%= install_chef %> @echo Installing Chef Client 12.0.2 with msiexec @msiexec /q /i "%LOCAL_DESTINATION_MSI_PATH%" ADDLOCAL="ChefClientFeature,ChefServiceFeature" @endlocal @echo Writing validation key... > <%= bootstrap_directory %>\validation.pem ( <%= validation_key %> ) @echo Validation key written. <% if @config[:encrypted_data_bag_secret] -%> > <%= bootstrap_directory %>\encrypted_data_bag_secret ( <%= encrypted_data_bag_secret %> ) <% end -%> > <%= bootstrap_directory %>\client.rb ( <%= config_content %> ) > <%= bootstrap_directory %>\first-boot.json ( <%= run_list %> ) <%= start_chef %>
The following examples show how to use this knife subcommand:
Bootstrap a node
$ knife bootstrap 12.34.56.789 -P vanilla -x root -r 'recipe[apt],recipe[xfs],recipe[vim]'
which shows something similar to:
... 12.34.56.789 Chef Client finished, 12/12 resources updated in 78.942455583 seconds
Use knife node show
to verify:
$ knife node show debian-wheezy.int.domain.org
which returns something similar to:
Node Name: debian-wheezy.int.domain.org Environment: _default FQDN: debian-wheezy.int.domain.org IP: 12.34.56.789 Run List: recipe[apt], recipe[xfs], recipe[vim] Roles: Recipes: apt, xfs, vim, apt::default, xfs::default, vim::default Platform: debian 7.4 Tags:
Use an SSH password
$ knife bootstrap 192.168.1.1 -x username -P PASSWORD --sudo
Use a file that contains a private key
$ knife bootstrap 192.168.1.1 -x username -i ~/.ssh/id_rsa --sudo
Fetch and execute an installation script from a URL
$ knife bootstrap --bootstrap-install-sh http://mycustomserver.com/custom_install_chef_script.sh
Specify options when using cURL
$ knife bootstrap --bootstrap-curl-options "--proxy http://myproxy.com:8080"
Specify options when using GNU Wget
$ knife bootstrap --bootstrap-wget-options "-e use_proxy=yes -e http://myproxy.com:8080"
Specify a custom installation command sequence
$ knife bootstrap --bootstrap-install-command "curl -l http://mycustomserver.com/custom_install_chef_script.sh | sudo bash -s --"
© Chef Software, Inc.
Licensed under the Creative Commons Attribution 3.0 Unported License.
The Chef™ Mark and Chef Logo are either registered trademarks/service marks or trademarks/servicemarks of Chef, in the United States and other countries and are used with Chef Inc's permission.
We are not affiliated with, endorsed or sponsored by Chef Inc.
https://docs-archive.chef.io/release/12-13/knife_bootstrap.html