| DEPENDENCIES | |
| chef-ingredient | |
| git: git://github.com/chef-cookbooks/chef-ingredient.git | |
| revision: 27cb8306a3d1d7048df13d74908f751d2a6ac2ee | |
| chef-server-12 | |
| git: git://github.com/opscode-cookbooks/delivery-cluster.git | |
| revision: 3a93b557d1b16fb5d62f091d3aaa30dff976e508 | |
| rel: vendor/chef-server-12 | |
| chef-splunk | |
| git: git://github.com/chef-cookbooks/chef-splunk.git |
| ------ | |
| As with any security model, the layered approach is recommended. Now the issue here is where chef stops and your internal security starts. Obvious things to consider:- | |
| Chef has a PKI infrastructure so securing keys is the top priority. Access to those keys has to be controlled, and whilst there are things that can be done cleverly with chef cookbooks to check on this/remove access, then there are also people and process issues that need to be addressed. | |
| Developer workstations, - here securing keys is not so simple, obvious things are to put chown 0600 for any private keys, and keep them in .ssh directory ( properly secured, not sure how to do that on windows machines, but am sure it is possible ), however, you will probably over time have a lot of keys, and maybe chef-vault ( https://docs.chef.io/chef_vault.html also checkout Justin Timberman's blog at the bottom of that link, as He works for Chef ) is one answer? People and process come in to play here too. Private Key management will be |
| ================================================================================ | |
| Error executing action `run` on resource 'execute[opscode-reporting-reconfigure]' | |
| ================================================================================ | |
| Mixlib::ShellOut::ShellCommandFailed | |
| ------------------------------------ | |
| Expected process to exit with [0], but received '1' | |
| ---- Begin output of opscode-reporting-ctl reconfigure ---- | |
| STDOUT: [2015-05-19T14:09:25+00:00] INFO: Starting chef-zero on port 8889 with repository at repository at /opt/opscode-reporting/embedded | |
| One version per cookbook |
| execute 'create admin' do | |
| command <<-EOM.gsub(/\s+/, ' ').strip! | |
| chef-server-ctl user-create #{node['chef-server-cluster']['admin']['username']} | |
| #{node['chef-server-cluster']['admin']['firstname']} | |
| #{node['chef-server-cluster']['admin']['lastname']} | |
| #{node['chef-server-cluster']['admin']['email']} | |
| #{node['chef-server-cluster']['admin']['password']} | |
| -f #{node['chef-server-cluster']['admin']['private_key_path']} | |
| EOM | |
| not_if "chef-server-ctl user-list | grep -w #{node['chef-server-cluster']['admin']['username']}" |
| An error occurred while installing nokogiri (1.6.6.2), and Bundler cannot continue. | |
| Make sure that `gem install nokogiri -v '1.6.6.2'` succeeds before bundling. | |
| ~/dev/ec-metal(master) > gem install nokogiri -v '1.6.6.2' | |
| Building native extensions. This could take a while... | |
| Successfully installed nokogiri-1.6.6.2 | |
| 1 gem installed | |
| ~/dev/ec-metal(master) > bundle | |
| Fetching gem metadata from https://rubygems.org/....... | |
| Fetching additional metadata from https://rubygems.org/.. | |
| Resolving dependencies... |
| # This is an example resource file for rTorrent. Copy to | |
| # ~/.rtorrent.rc and enable/modify the options as needed. Remember to | |
| # uncomment the options you wish to enable. | |
| # Maximum and minimum number of peers to connect to per torrent. | |
| min_peers = 30 | |
| max_peers = 150 | |
| # Same as above but for seeding completed torrents (-1 = same as downloading) | |
| min_peers_seed = -1 |
Dan DeLeo appeared on the FoodFightShow some time ago to walk through "what a Chef run really does". I expanded on these remarks in my personal investigation.
bin/chef-client creates a new Chef::Application::Client (subclass of Chef::Application which sets up common things like loggers across chef-client, chef-solo, knife, etc.) then jump to:
lib/chef/client.rb
application classes create a new Chef::Client object, which calls initialize().
| --- | |
| driver: | |
| name: digitalocean | |
| driver_config: | |
| digitalocean_access_token: TOKEN | |
| ssh_key_ids: 'KEYID' | |
| ssh_key: '~/.ssh/id_rsa' | |
| platforms: |
| ~/dev/chef-solutions/orchestrate(master) > kitchen converge standalone-centos-6 | |
| -----> Starting Kitchen (v1.2.1) | |
| -----> Creating <standalone-centos-65>... | |
| Bringing machine 'default' up with 'virtualbox' provider... | |
| ==> default: Importing base box 'opscode-centos-6.5'... | |
| ==> default: Matching MAC address for NAT networking... | |
| ==> default: Setting the name of the VM: standalone-centos-65_default_1415219658591_76192 | |
| Skipping Berkshelf with --no-provision | |
| ==> default: Fixed port collision for 22 => 2222. Now on port 2202. | |
| ==> default: Clearing any previously set network interfaces... |
| --- | |
| driver: | |
| name: vagrant | |
| driver_config: | |
| requre_chef_omnibus: true | |
| network: | |
| - ["forwarded_port", {guest: 8080, host: 8080}] | |
| - ["private_network", {ip: "33.33.33.10"}] | |
| customize: |