chef / chef Goto Github PK

Chef Infra, a powerful automation platform that transforms infrastructure into code automating how infrastructure is configured, deployed and managed across any environment, at any scale

Home Page: http://www.chef.io/chef/

License: Apache License 2.0

Shell 0.60% Ruby 98.27% PowerShell 0.29% HTML 0.69% Python 0.11% Makefile 0.02% Dockerfile 0.01% Raku 0.01% JavaScript 0.01%

chef devops cfgmgt infrastructure automation deployment hacktoberfest

chef's Introduction

Chef Infra

Umbrella Project: Chef Infra

Project State: Active

Issues Response Time Maximum: 14 days

Pull Request Response Time Maximum: 14 days

Getting Started

Chef Infra is a configuration management tool designed to bring automation to your entire infrastructure.

Want to try Chef Infra?

For Chef Infra usage, please refer to Learn Chef, our self-paced, entirely free learning platform. Learn Chef also includes module-based training for Chef Infra, as well as Chef Automate, Chef Habitat, and Chef InSpec.

Other useful resources for Chef Infra users:

Documentation: https://docs.chef.io/
Source: https://github.com/chef/chef/tree/main
Tickets/Issues: https://github.com/chef/chef/issues
Slack: Chef Community Slack
Mailing list/Forum: https://discourse.chef.io

Reporting Issues

Issues can be reported by using GitHub Issues.

Note that this repository is primarily for reporting issues in the chef-client itself. For reporting issues against other Chef projects, please look up the appropriate repository. If you're unsure where to submit an issue, please ask in the #chef-dev channel in Chef Community Slack.

How We Build & Release Chef

For information on how a contribution goes from PR to released package, see How Chef Infra Is Built

To learn more about our monthly feature releases and yearly major releases, see Chef Infra Release and Support Schedule.

Getting Involved

We'd love to have your help developing Chef Infra. See our Contributing Document for more information on getting started.

License and Copyright

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

chef's People

Contributors

Stargazers

Watchers

Forkers

adamhjk fujin btm thommay bmizerany jsierles jtimberman seancribbs fcoury mlandauer b kisoku johnhampton ehaselwanter saimonmoore yenif auser contentfree cabeca mdkent nuoyan mikelim zpinter algorist dbalatero mikehale ricardojsanchez raphael joewilliams thegrort jeppenejsum caryp-contrib jchris pedro danielsdeleo sigmonsays nmueller veszig ppmclala mgiammarco chohag mikamai halorgium jamesgolick pcross616 lmarlow tfheen stormsilver dreamcat4 me rberger erkki brynary krisr prepor lazzarello valodzka kennethkalmer codenauten jzimmek renchap timcharper dcampano jaswope jonathantron aguynamedben pblittle honkster lastobelus grantr davidx fizx metaxis toomasp dougm vitaliel thewoolleyman nestegg seth imeyer richardn jasherai maxigs pedromg jonseaberg apsoto mleinart akzhan thbishop jeffmccune akamaus igloonet atmos warwickp robertpostill dfopensource tecnh kenong albertsj1 mdxp

chef's Issues

c:\chef directory is too permissive

https://tickets.opscode.com/browse/CHEF-5285

The directory which is holding the *.pem files are too permissive on windows. We need to make sure that the directory is created with the correct permissions during the MSI installation.

/cc: @adamedx, @btm

Dependency Errors with RPM 5.4.9 & chef-10.32.2-1.el6.x86_64.rpm

In systems that use RPM 5.4.9 (rpm5.org), the standard omnibus chef-client RPM package doesn't install cleanly. In this version of RPM they do stricter dependency checks, in particular making sure all directories are owned by a package.

When one tries to install the package, it throws dependency errors, apparently due to lack of %dir directives in the RPM spec file for all of chef's directories. It will install if passed '--no-deps' to rpm, but some have expressed the need to have it install properly.

Chef should have a native partial search library

https://tickets.opscode.com/browse/CHEF-3878

In order to improve performance and decrease resource usage having a partial search library is a common ask.

There are two standing PRs around this issue:

#643
#1094

We should chat and determine the next steps for this issue:

/cc: @danielsdeleo, @lamont-granquist

Can't use remote cookbooks.tar.gz with chef-solo on windows

https://tickets.opscode.com/browse/CHEF-5332
https://tickets.opscode.com/browse/CHEF-5333

cookbooks.tar.gz can not be used to make a chef-solo run on windows.

chef-solo -j C:\chef\first-boot.json -r http://foo/bar.tar.gz -E dev -l debug --logfile C:\chef\chef-solo.log

fails with:

C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.4-x86-mingw32/lib/c
hef/application/solo.rb:190:in `join': can't convert nil into String (TypeError)

        from C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.4-x86-
mingw32/lib/chef/application/solo.rb:190:in `reconfigure'
        from C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.4-x86-
mingw32/lib/chef/application.rb:65:in `run'
        from C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.4-x86-
mingw32/bin/chef-solo:25:in `<top (required)>'
        from C:/opscode/chef/bin/chef-solo:23:in `load'
        from C:/opscode/chef/bin/chef-solo:23:in `<main>'

git provider: can not shallow clone from a branch

When shallow_clone is enabled in deploy, git clone the repository master branch with depth 5, then tries to checkout branch SHA and it does not exists.

==> default: ---- Begin output of git checkout -b deploy f9b59b85068b39359f27c746399459d760031b64 ----
==> default: STDOUT: 
==> default: STDERR: fatal: reference is not a tree: f9b59b85068b39359f27c746399459d760031b64
==> default: ---- End output of git checkout -b deploy f9b59b85068b39359f27c746399459d760031b64 ----
==> default: Ran git checkout -b deploy f9b59b85068b39359f27c746399459d760031b64 returned 128

Additional parameter should be passed to git command: -b branch_name

# Chef::Provider::Git#clone
if @new_resource.depth
  args << "-b #{@new_resource.branch}" if @new_resource.branch.length != 40
  args << "--depth #{@new_resource.depth}"
end

Properly document what node_path means in solo config

This is what I get from the description of this setting:

http://docs.opscode.com/config_rb_solo.html

"The location in which to look for node-specific recipes."

What exactly does it mean? How should the recipes be structured inside this location? I searched for node_path in Chef's source code and could find nothing but the configuration itself... Where is it used?

I can't find any proper documentation about this setting anywhere... Would you mind explaining what it does?

Enable roles in subdirectories for chef-zero.

Chef-solo now enables storing roles in subdirectories, we should make sure chef-zero can do the same.

Tickets for reference: https://tickets.opscode.com/browse/CHEF-4193, #759

Allow usage of SID's in principals for Windows File Security

https://tickets.opscode.com/browse/CHEF-5337

We need to allow usage of SIDs in addition to the account names in windows file security in order to enable writing cookbooks that work windows in different languages.

Debian service resource is not idempotent when priority is specified

https://tickets.opscode.com/browse/CHEF-5283

#908 introduced a regression which made service resource not idempotent on debian when priorities are specified.

chef-client should run local-mode if a config file and chef_server_url is not specified

One of the steps in the new LearnChef tutorials is to create a simple recipe that contains:

# hello.rb
file '/tmp/hello' do
   content "Hello world!"
end

and run this recipe by chef-client hello.rb.

In order to achieve this we need chef-client to automatically assume local-mode when invoked with a recipe name as an argument.

/cc: @opscode/client-eng

Hosted Chef stores IAM profile credentials

I noticed today when I was looking at attributes of my instances in Hosted Chef that there was a section for security credentials and that it was populated with the IAM access key id, secret key, and token that had been allocated to the instance.

It looks like this a consequence of crawling http://169.254.169.254/ and storing everything found. We should probably omit everything under http://169.254.169.254/*/meta-data/iam/security-credentials/ when reporting on attributes.

Storing this data would compound the effects of a security breach that exposed node attributes. For users that are using IAM profiles, an attacker would gain access to the user's AWS accounts for a number of hours using these credentials.

Chef Client Local Mode fails when run from a directory above the chef repo

Attempting to run Chef Client local mode on windows is failing with:

================================================================================
Chef encountered an error attempting to load the node data for "WIN-E0O1BGOEL0L"
================================================================================

Unknown Server Error:
---------------------
The server had a fatal error attempting to load the node data.

Server Response:
----------------
Exception raised!  #<Errno::ENOENT: No such file or directory - C:/repo/nodes>
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.0.rc.1-x86-mingw32/lib/chef/chef_fs/file_system/chef_repository_file_system_root_dir.rb:57:in `mkdir'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.0.rc.1-x86-mingw32/lib/chef/chef_fs/file_system/chef_repository_file_system_root_dir.rb:57:in `block in create_child'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.0.rc.1-x86-mingw32/lib/chef/chef_fs/file_system/chef_repository_file_system_root_dir.rb:55:in `each'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.0.rc.1-x86-mingw32/lib/chef/chef_fs/file_system/chef_repository_file_system_root_dir.rb:55:in `create_child'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.0.rc.1-x86-mingw32/lib/chef/chef_fs/chef_fs_data_store.rb:406:in `get_dir'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.0.rc.1-x86-mingw32/lib/chef/chef_fs/chef_fs_data_store.rb:395:in `with_dir'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.0.rc.1-x86-mingw32/lib/chef/chef_fs/chef_fs_data_store.rb:68:in `create' C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-zero-2.2/lib/chef_zero/data_store/v1_to_v2_adapter.rb:56:in `block in create'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-zero-2.2/lib/chef_zero/data_store/v1_to_v2_adapter.rb:168:in `fix_exceptions'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-zero-2.2/lib/chef_zero/data_store/v1_to_v2_adapter.rb:55:in `create'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-zero-2.2/lib/chef_zero/rest_base.rb:92:in `create_data'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-zero-2.2/lib/chef_zero/endpoints/rest_list_endpoint.rb:30:in `post'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-zero-2.2/lib/chef_zero/rest_base.rb:29:in `call'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-zero-2.2/lib/chef_zero/rest_router.rb:23:in `call'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-zero-2.2/lib/chef_zero/server.rb:443:in `block in app'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/rack-1.5.2/lib/rack/handler/webrick.rb:60:in `call'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/rack-1.5.2/lib/rack/handler/webrick.rb:60:in `service'
C:/opscode/chef/embedded/lib/ruby/1.9.1/webrick/httpserver.rb:138:in `service'
C:/opscode/chef/embedded/lib/ruby/1.9.1/webrick/httpserver.rb:94:in `run'
C:/opscode/chef/embedded/lib/ruby/1.9.1/webrick/server.rb:191:in `block in start_thread'

Here is the relevant pieces of client config:

# File is located at: C:\oc\chef-test\triager\.chef\client.rb
# Current working directory of Chef Client run is: C:\oc\chef-test\triager
current_chef_dir = File.dirname(__FILE__)
....
....
chef_repo_path           File.join(current_chef_dir, "..", "repo")

Unable to bootstrap on Cloudshare

I'm trying to work through the recent webinar series and I'm on module 2. I've run up a server on cloudshare and I'm now trying to bootstrap it however it's failing due to the following

Downloading Chef 11.14.0.alpha.1 for el...
uvo1u1k2ufnddev9jo5.vm.cld.sr downloading https://www.opscode.com/chef/metadata?v=11.14.0.alpha.1&prerelease=false&nightlies=false&p=el&pv=6&m=x86_64 to file /tmp/install.sh.41834/metadata.txt
trying wget...
ERROR 404
Unable to retrieve a valid package!
Please file a bug report at http://tickets.opscode.com
Project: Chef
Component: Packages
Label: Omnibus
Version: 11.14.0.alpha.1
Metadata URL: https://www.opscode.com/chef/metadata?v=11.14.0.alpha.1&prerelease=false&nightlies=false&p=el&pv=6&m=x86_64

I'm running a CentOS server to act as the node

32 bit Windows claiming to be 64 bit

From @sersut

On Windows Server 2003 R2 and Windows 2008 (both 32 bit) the following spec fails:

20) Chef::Resource::PowershellScript when executing guards evaluates a powershell     $false for a not_if block as true
     Failure/Error: resource.should_skip?(:run).should be_false
     Chef::Exceptions::Win32ArchitectureIncorrect:
       powershell_script[Guard resource] (dynamically defined) had an error:     Chef::Exceptions::Win32ArchitectureIncorrect: Support for the i386 architecture from a 64-    bit Ruby runtime is not yet implemented
     # C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.0.alpha.5-x86-mingw32/lib/chef/provider/windows_script.rb:40:in `initialize'
     # C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.0.alpha.5-x86-mingw32/lib/chef/provider/powershell_script.rb:59:in `initialize'
     # C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.0.alpha.5-x86-mingw32/lib/chef/platform/provider_mapping.rb:454:in `new'
     # C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.0.alpha.5-x86-mingw32/lib/chef/platform/provider_mapping.rb:454:in `provider_for_resource'
     # C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.0.alpha.5-x86-mingw32/lib/chef/resource.rb:682:in `provider_for_action'
     # C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.0.alpha.5-x86-mingw32/lib/chef/resource.rb:648:in `run_action'
     # C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.0.alpha.5-x86-mingw32/lib/chef/guard_interpreter/resource_guard_interpreter.rb:62:in `evaluate_action'
     # C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.0.alpha.5-x86-mingw32/lib/chef/guard_interpreter/resource_guard_interpreter.rb:51:in `evaluate'
     # C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.0.alpha.5-x86-mingw32/lib/chef/resource/conditional.rb:79:in `evaluate_command'
     # C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.0.alpha.5-x86-mingw32/lib/chef/resource/conditional.rb:75:in `evaluate'
     # C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.0.alpha.5-x86-mingw32/lib/chef/resource/conditional.rb:68:in `continue?'
     # C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.0.alpha.5-x86-mingw32/lib/chef/resource.rb:710:in `block in should_skip?'
     # C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.0.alpha.5-x86-mingw32/lib/chef/resource.rb:709:in `each'
     # C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.0.alpha.5-x86-mingw32/lib/chef/resource.rb:709:in `find'
     # C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.0.alpha.5-x86-mingw32/lib/chef/resource.rb:709:in `should_skip?'
     # C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.0.alpha.5-x86-mingw32/spec/functional/resource/powershell_spec.rb:240:in `block (3 levels) in <top (required)>'

The issue might be: https://github.com/opscode/chef/blob/master/lib/chef/mixin/windows_architecture_helper.rb#L67

chef-client doesn't set Net::HTTP open_timeout

This can cause chef-client to hang indefinitely while waiting for a connection to open to the chef server.

Already in 11.14, this ticket is for the work to backport it to 10.

https://tickets.opscode.com/browse/CHEF-5152

https://github.com/opscode/chef/blob/10-stable/chef/lib/chef/rest/rest_request.rb#L202

Omnibus installer error on AWS

Linux ip-10-0-1-103 2.6.32-431.11.2.el6.x86_64 #1 SMP Mon Mar 3 13:32:45 EST 2014 x86_64 x86_64 x86_64 GNU/Linux

Connecting to 10.0.1.103
10.0.1.103 [sudo] password for dooleyp: Installing Chef Client...
10.0.1.103 --2014-06-23 16:48:19-- https://www.opscode.com/chef/install.sh
10.0.1.103 Resolving www.opscode.com... 184.106.28.90
10.0.1.103 Connecting to www.opscode.com|184.106.28.90|:443... connected.
10.0.1.103 HTTP request sent, awaiting response... 200 OK
10.0.1.103 Length: 15934 (16K) [application/x-sh]
10.0.1.103 Saving to: ‚ÄúSTDOUT‚Äù
10.0.1.103
100%[======================================>] 15,934 --.-K/s in 0s
10.0.1.103
10.0.1.103 2014-06-23 16:48:19 (340 MB/s) - written to stdout [15934/15934]
10.0.1.103
10.0.1.103 Downloading Chef 11.14.0.alpha.1 for el...
10.0.1.103 downloading https://www.opscode.com/chef/metadata?v=11.14.0.alpha.1&prerelease=false&nightlies=false&p=el&pv=6&m=x86_64
10.0.1.103 to file /tmp/install.sh.24852/metadata.txt
10.0.1.103 trying wget...
10.0.1.103 ERROR 404
10.0.1.103 Unable to retrieve a valid package!
10.0.1.103 Please file a bug report at http://tickets.opscode.com
10.0.1.103 Project: Chef
10.0.1.103 Component: Packages
10.0.1.103 Label: Omnibus
10.0.1.103 Version: 11.14.0.alpha.1
10.0.1.103
10.0.1.103 Please detail your operating system type, version and any other relevant details
10.0.1.103 Metadata URL: https://www.opscode.com/chef/metadata?v=11.14.0.alpha.1&prerelease=false&nightlies=false&p=el&pv=6&m=x86_64
10.0.1.103 Starting first Chef Client run...
10.0.1.103 bash: line 85: chef-client: command not found

Add gemspec for 'x64-mingw32' platform

Originally stumbled across the issue in chef/mixlib-shellout#50, but it also hits me whenever using the chef gem.

There should be an x64-mingw32 platform specific gemspec akin to chef-x86-mingw32.gemspec, which should be published on rubygems.org as well.

Otherwise all the windows specific gems remain missing when working on a 64-bit Ruby on Windows.

Chef should have a resilient retry logic for cookbook download / upload to handle temp S3 Errors

https://tickets.opscode.com/browse/CHEF-3241
https://tickets.opscode.com/browse/CHEF-4728

In order to handle temporary S3 errors, Chef needs to have a resilient retry logic during cookbook upload and download. Two tickets above mention two aspects of this logic:

Retry with exponential time intervals
Configurable number of retries

I think 1 should provide a resilient enough logic with a large enough retry count such as 5. @danielsdeleo thoughts?

/cc: @scotthain

In 10.32.2 client, RPM package provider doesn't properly handle remove action when RPM not installed on system

In the 10.32.2 client, the RPM package provider doesn't properly handle the remove action when the RPM is not installed on the system. In lib/chef/provider/package/rpm.rb there are two regex to parse the output from "rpm -q", but it winds up returning the name of the package as the version number. As such, chef thinks the RPM is installed when it's not, tries to delete it, and winds up fatal'ing the run. Anchoring the regex fixes the problem.

Node::Attribute inspect vs to_s problem

currently Node::Attribute only overwrite the inspect method not the to_s method, that might be complications like

puts node.attributes #=> {} like an empty hash
p node.attributes #=> {...data...} like it should be

that problem can be fixed when Node::Attribute#to_s will be defined as alias as Node::Attribute#inspect

alias to_s inspect

Packacke Resource on Ubuntu Platforms not correctly reported (ChefSpec fails)

After updating to Chef 11.14.0.rc.1, Berks 3.1.3 and ChefSpec 4.0.1 one of my ChefSpec tests started failing:
https://travis-ci.org/tknerr/sample-application-cookbook/builds/28638368

It seems that whenever you use the package resource in a recipe on the ubuntu platform it is reported as apt_package rather than package, therefore ChefSpec doesn't notice.

For example, in recipes/default.rb:

package "apache2"

In test/my_spec.rb:

context "on ubuntu 12.04" do
  let(:chef_run) do
    ChefSpec::Runner.new(:platform => :ubuntu, :version => "12.04") do |node|
    end.converge(described_recipe)
  end
  it 'installs package apache2' do
    expect(chef_run).to install_package('apache2')
  end
end

Running chefspec the above example fails:

Failures:

  1) sample-app::default on ubuntu systems should install package "apache2"
     Failure/Error: it { should install_package 'apache2' }
       expected "package[apache2]" with action :install to be in Chef run. Other package resources:



     # ./test/chefspec/default_spec.rb:11:in `block (3 levels) in <top (required)>'

Finished in 1.7 seconds (files took 6.32 seconds to load)
7 examples, 1 failure

Failed examples:

rspec ./test/chefspec/default_spec.rb:11 # sample-app::default on ubuntu systems should install package "apache2"

Also, in the Chef log output I can see that it explicitly says it would install apt_package:

[2014-06-30T10:25:20+02:00] INFO: Processing directory[/var/cache/local] action create (apt::default line 62)
[2014-06-30T10:25:20+02:00] INFO: Processing directory[/var/cache/local/preseeding] action create (apt::default line 62)
[2014-06-30T10:25:20+02:00] INFO: Processing apt_package[apache2] action install (apache2::default line 20)
[2014-06-30T10:25:20+02:00] INFO: Processing service[apache2] action enable (apache2::default line 24)
[2014-06-30T10:25:20+02:00] INFO: Processing directory[/etc/apache2/ssl] action create (apache2::default line 131)

Something has changed here, I suspect it's chef, but it could also be ChefSpec?

/cc @sethvargo

Support Chef Client on FreeBSD 10

Running on Vagrant 1.6.3, the chef-solo run finishes, but then segfaults.

==> freebsd-01:
==> freebsd-01:
==> freebsd-01: chef client finished. 624 resources updated, took 982.441548297 seconds
==> freebsd-01: /usr/local/lib/ruby/gems/1.9/gems/chef-11.12.8/lib/chef/client.rb:222:
==> freebsd-01: [BUG]
==> freebsd-01: Segmentation fault
==> freebsd-01:
==> freebsd-01: ruby 1.9.3p484 (2013-11-22 revision 43786) [amd64-freebsd10]
==> freebsd-01: -- Control frame information -----------------------------------------------
==> freebsd-01: bash: line 2:  1187 Segmentation fault      (core dumped) chef-solo -c /vagrant/solo.rb -j /vagrant/dna.json

knife download fails with "undefined method `child' for nil:NilClass"

https://tickets.opscode.com/browse/CHEF-4718

knife download / fails with:

/Users/st/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/chef_fs/file_system.rb:320:in `block in copy_entries': undefined method `child' for nil:NilClass (NoMethodError)
    from /Users/st/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/chef_fs/parallelizer.rb:95:in `call'
    from /Users/st/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/chef_fs/parallelizer.rb:95:in `process_input'
    from /Users/st/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/chef_fs/parallelizer.rb:70:in `each'
    from /Users/st/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/chef_fs/file_system.rb:422:in `to_a'
    from /Users/st/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/chef_fs/file_system.rb:422:in `parallel_do'
    from /Users/st/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/chef_fs/file_system.rb:319:in `copy_entries'
    from /Users/st/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/chef_fs/file_system.rb:357:in `block in copy_entries'
    from /Users/st/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/chef_fs/parallelizer.rb:95:in `call'
    from /Users/st/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/chef_fs/parallelizer.rb:95:in `process_input'
    from /Users/st/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/chef_fs/parallelizer.rb:112:in `worker_loop'
    from /Users/st/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/chef_fs/parallelizer.rb:24:in `block (2 levels) in initialize'

due to:

Created cookbooks
DEBUG: Signing the request as johndoe
DEBUG: Initiating GET to https://chef.example.org/cookbooks/?num_versions=all
DEBUG: ---- HTTP Request Header Data: ----
DEBUG: Accept: application/json
DEBUG: Accept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3
DEBUG: X-OPS-SIGN: algorithm=sha1;version=1.0;
DEBUG: X-OPS-USERID: johndoe
DEBUG: X-OPS-TIMESTAMP: 2013-11-01T14:10:33Z
DEBUG: X-OPS-CONTENT-HASH: *removed*
DEBUG: X-OPS-AUTHORIZATION-1: *removed*
DEBUG: HOST: chef.example.org:443
DEBUG: ---- HTTP Status and Header Data: ----
DEBUG: HTTP 1.1 200 OK
DEBUG: server: nginx/0.7.67
DEBUG: date: Fri, 01 Nov 2013 14:10:33 GMT
DEBUG: content-type: application/json; charset=utf-8
DEBUG: transfer-encoding: chunked
DEBUG: connection: close
DEBUG: ---- End HTTP Status/Header Data ----

@jkeiser any fix recommendations?

Chef should be installable to a different directory on Windows.

https://tickets.opscode.com/browse/CHEF-4857

Currently due to hardcoded paths Chef Client can not be installed to a different directory on Windows.

This issue is somewhat unfixable at this point because installing Chef Client into a directory with spaces doesn't work some of the gems with native bindings that doesn't have the right quoting in their Makefile. Since we don't know which gems are impacted by this issue, we should make the fix on our end to make Chef installable to a different directory and then find out what are the important gems that have the native binding issue.

@adamedx / @btm I think we should prioritize this.

Related to: chef-boneyard/chef-dk#68

Don't crash when chef-zero port is already bound

Running multiple chef-client or knife -zs simultaneously causes one or more of them to crash. Since the latest revision of chef-zero supports a port range, we should:

spin up chef-zero on a range by default (8900-9900)
allow user to specify port ranges on the command line (--chef-zero-port=80,8080,9090-10101) and in Chef::Config.chef_zero.port ('80,8080-8090' or 8080.upto(8090))

service action :start fails on Windows if service is already running

https://tickets.opscode.com/browse/CHEF-5319

This issue might be fixed with #1166. Let's check if this is true and close this issue if yes.

/cc: @mcquin

remote_file url redirects not being followed correctly causing Chef::Exceptions::RedirectLimitExceeded

https://tickets.opscode.com/browse/CHEF-5148

@mcquin and I looked into this in the light of #1471 and we were still able to repro the issue with the fix.

Will investigate this more later today.

Reporting changes to binary registry keys (CHEF-5323)

@opscode/client-eng,

I'm working on CHEF-5323, and wondering what thoughts are on how to handle reporting changes in binary registry keys. Two ideas from @sersut and @adamedx are 1) don't send/track any information for binary registry keys or 2) send/track an md5/checksum so that changes to the key can be detected/indicated.

CHEF-2707 subversion resource doesn't work on windows

Hi Chefs. This issue (reference original bug inside jira https://tickets.opscode.com/browse/CHEF-2707 ) is still active.

I utilize the subversion provider heavily under windows. The impact of this bug is huge for me, and requires a hack for this for each release of chef-client:

C:\opscode\chef\embedded\lib\ruby\gems\1.9.1\gems\chef-xxxxx-x86-mingw32\lib\chef\mixin\command.rb

The hack that I had previously put into place:

unless Array[opts[:returns], 42].include?(status.exitstatus)

..no longer works. Could you please upgrade the priority on resolving this, please? I now have to revert chef-client to a version using an insecure openssl to re-apply my previous hack.

The error I receive with chef-client version 11.12.8 is:

NoMethodError: undefined method `exitstatus' for nil:NilClass
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/mixin/command.rb:140:in `block in output_of_command'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/mixin/command.rb:122:in `chdir'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/mixin/command.rb:122:in `output_of_command'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/provider/subversion.rb:132:in `revision_int'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/provider/subversion.rb:117:in `export_command'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/provider/subversion.rb:81:in `block in action_force_export'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/mixin/why_run.rb:52:in `call'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/mixin/why_run.rb:52:in `add_action'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/provider.rb:155:in `converge_by'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/provider/subversion.rb:80:in `action_force_export'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/provider.rb:120:in `run_action'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/resource.rb:637:in `run_action'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/runner.rb:49:in `run_action'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/runner.rb:81:in `block (2 levels) in converge'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/runner.rb:81:in `each'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/runner.rb:81:in `block in converge'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/resource_collection.rb:98:in `block in execute_each_resource'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/resource_collection/stepable_iterator.rb:116:in `call'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/resource_collection/stepable_iterator.rb:116:in `call_iterator_block'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/resource_collection/stepable_iterator.rb:85:in `step'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/resource_collection/stepable_iterator.rb:104:in `iterate'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/resource_collection/stepable_iterator.rb:55:in `each_with_index'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/resource_collection.rb:96:in `execute_each_resource'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/runner.rb:80:in `converge'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/client.rb:345:in `converge'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/client.rb:431:in `do_run'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/client.rb:227:in `run'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/application.rb:217:in `run_chef_client'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/application/client.rb:328:in `block in run_application'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/application/client.rb:317:in `loop'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/application/client.rb:317:in `run_application'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/lib/chef/application.rb:67:in `run'
C:/opscode/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8-x86-mingw32/bin/chef-client:26:in `<top (required)>'
C:/opscode/chef/bin/chef-client:23:in `load'
C:/opscode/chef/bin/chef-client:23:in `<main>'

ResourceReporter#post_reporting_data does not handle 50x errors

After I upgraded to Chef 11.12.0 I started to get error emails because chef was getting 500, 502 or 504 from Opscode (Enterprise Chef) - ResourceReporter#post_reporting_data is the same for 11.12.0, 11.12.4, 11.12.6, 11.12.8.

The error I was emailed:

Updated Resources:

   [...]

Net::HTTPFatalError: 502 "Bad Gateway"
/opt/chef/embedded/lib/ruby/1.9.1/net/http.rb:2632:in `error!'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.0/lib/chef/rest.rb:146:in `raw_http_request'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.0/lib/chef/resource_reporter.rb:228:in `post_reporting_data'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.0/lib/chef/resource_reporter.rb:204:in `run_completed'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.0/lib/chef/event_dispatch/dispatcher.rb:29:in `block in run_completed'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.0/lib/chef/event_dispatch/dispatcher.rb:29:in `each'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.0/lib/chef/event_dispatch/dispatcher.rb:29:in `run_completed'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.0/lib/chef/client.rb:438:in `do_run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.0/lib/chef/client.rb:213:in `block in run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.0/lib/chef/client.rb:207:in `fork'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.0/lib/chef/client.rb:207:in `run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.0/lib/chef/application.rb:217:in `run_chef_client'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.0/lib/chef/application/client.rb:328:in `block in run_application'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.0/lib/chef/application/client.rb:317:in `loop'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.0/lib/chef/application/client.rb:317:in `run_application'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.0/lib/chef/application.rb:67:in `run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.0/bin/chef-client:26:in `<top (required)>'
/usr/bin/chef-client:23:in `load'
/usr/bin/chef-client:23:in `<main>'

Digging in to the code I saw that ResourceReporter#post_reporting_data didn't catch the right exception: https://github.com/opscode/chef/blob/90d7ed28028a6f32aa6c744fb4f801f6b604138e/lib/chef/resource_reporter.rb#L239

It is catching HTTPServerException, but Net::HTTP does not raise that for 50x errors: https://github.com/ruby/ruby/blob/ruby_1_9_3/lib/net/http.rb#L2356

Unfortunately it's not ideal to catch only Net::HTTP's errors, because under the hood socket may raise it's own errors.
This is an old problem that is recurring when working with Net::HTTP. More details: http://stackoverflow.com/a/11802674/565999 and https://gist.github.com/tenderlove/245188

`node` not available in template partials

https://tickets.opscode.com/browse/CHEF-4530

node variable is not available in template partials after 11.6.0.

This error message occurs because the @node instance variable is nil. Adding :node => @node to the variables you pass in should work around it.

Give bootstrap the ability to configure arbitrary config values at the target node

We've seen a few instances of some config values needs configuration during bootstrap. Some examples are #1090, #1416.

We should have a mechanism in knife that enables users to configure any config value at the nodes.

Enable ssl verification by default in Chef 12

In order to provide security by default we will enable the ssl verification by default in Chef. The logic required for this functionality has been in Chef since 11.16.0. The remaining list of things to do are:

Pull request submitted

CHEF-5282, PR #1895

chef-client daemon holds onto file descriptor for rotated log

We're having issues with rotating the chef-client log /var/log/chef/client.log, as the chef-client daemon doesn't release the file descriptor when sent SIGHUP. This is on ubuntu, haven't tested against other distros.

See an example here: https://gist.github.com/bhouse/4737034b51e654838d4d

As a work-around we're using copytruncate with logrotate until this is resolved.

Thanks!

SSL verification of self-signed seems broken under Windows

Under Windows platform using Chef Client v. 11.12.8 with enabled verify_api_cert and self-signed certificates and keys present in trusted_certs folder, client fails with next error:
FATAL: OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed
When using Hosted Chef environment, that has signed certificates - this error is non-existent.
Client.rb contatins ssl_client_cert and ssl_client_key pointing to certificate and key.
Under Linux platform - problem is non-existent.

Changelog should link to the final blog posts not RCs

The changelog currently points to the RC blog posts for each previous version of Chef. These should probably point to the final blog posts with the complete changelogs instead.

Remove recipe DSL from base provider

Currently recipe DSL only adds confusions like this.

Can not install the latest Chef server(11.1.1) on a Debian machine

I was trying to install the latest Chef server which is 11.1.1 on a Debian 7 Linux.
I was able to download the .deb file and install it with dpkg but when I was running the sudo chef-server-ctl reconfigure the command has failed.
The reason is that Debian does not have upstart as init system.

https://tickets.opscode.com/browse/CHEF-5388

chefignore not found in `upload --all` when multiple cookbook paths

Multiple cookbook paths appears to have chefignore searched for in the concatenation of the paths. I see a bunch of lines in the debug info when running knife cookbook upload --all

DEBUG: No chefignore file found at /home/reesew/.chef/chef-repo/cookbooks/home/reesew/.chef/chef-repo/app-cookbooks/chefignore no files will be ignored

my knife.rb contains the line
cookbook_path [ File.join(repo, 'cookbooks'), File.join(repo, 'app-cookbooks') ]

and there are chefignore files in the cookbook root directories

chef-repo/
    cookbooks/
        chefignore
        ...
    app-cookbooks/
        chefignore
        ...

Do not print SSL warning when running chef-client in local-mode

In order to make the new LearnChef tutorials delightful, we need to ensure that users don't see the SSL verification warning when running local-mode.

/cc: @opscode/client-eng

git Provider Unable To Handle Private Repos Without known_hosts

When the git provider doesn't have access to valid entries for github.com systems in the ssh known_hosts file, it blows up trying to manipulate private repos.

If you add the key manually - ssh-keyscan github.com - the cookbook completes its run just fine. If you then look in the known hosts file, you'll see extra keys associated with github.com's IPs (instead of hostname). So the git resource seems to handle keys further down in the process ok.

chef/knife issue with ipv6

I'm running knife bootstrap command from chef-workstation. When I use ipv6 address for the chef client, It sends the following error:

tsi@chef-workstation:~/chef-repo$ knife -v
Chef: 11.12.2
tsi@chef-workstation:~/chef-repo$ knife bootstrap 2003:1b39:220:1::1011 -x tsi -P 'xxxx' -N 'testnode' -r 'role[WebServer]' --sudo
Connecting to 2003:1b39:220:1::1011
ERROR: Network Error: getaddrinfo: Name or service not known
Check your knife configuration and network settings
tsi@chef-workstation:~/chef-repo$

It seems the workstation interprets the ipv6 address as a hostname and then tries resolving it.

However when I create a /etc/hosts entry, the VM can be accessed:
2003:1b39:220:1::1011 vm

tsi@chef-workstation:~/chef-repo$ knife bootstrap vm -x tsi -P xxxx -N 'testnode' -r 'role[WebServer]' --sudo
Connecting to vm
vm sudo: unable to resolve host mrtg-server
vm knife sudo password:
Enter your password:

After gaining access to the VM using the workaround, I discovered a new issue with ipv6 similar to the one above:

I'm encountering error when client trying to reach the server:
"Error connecting to https://chef-server/organizations/dtna/clients - getaddrinfo: Name or service not known".

I also tried to use ipv6 address instead of "chef-server" dns name, but had a same result: "Error connecting to https://[2003:1b39:130:1::102]/organizations/dtna/clients - getaddrinfo: Name or service not known"

Detail log is as follows:

tsi@chef-workstation:~/chef-repo$ knife bootstrap vm -x tsi -P 'xxxx' -N 'testnode' -r 'role[WebServer]' --sudo --bootstrap-proxy http://[2003:1b39:220:1::a00a]:8080 --use-sudo-password
Connecting to vm
vm sudo: unable to resolve host mrtg-server
vm [sudo] password for htadmin: Starting first Chef Client run...
vm [2014-06-23T18:12:24+02:00] WARN:
vm * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
vm SSL validation of HTTPS requests is disabled. HTTPS connections are still
vm encrypted, but chef is not able to detect forged replies or man in the middle
vm attacks.
vm
vm To fix this issue add an entry like this to your configuration file:
vm
vm ```
vm # Verify all HTTPS connections (recommended)
vm ssl_verify_mode :verify_peer
vm
vm # OR, Verify only connections to chef-server
vm verify_api_cert true
vm ```
vm
vm To check your SSL configuration, or troubleshoot errors, you can use the
vm `knife ssl check` command like so:
vm
vm ```
vm knife ssl check -c /etc/chef/client.rb
vm ```
vm
vm * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
vm
vm Starting Chef Client, version 11.12.2
vm Creating a new client identity for testnode using the validator key.
vm
vm ================================================================================
vm Chef encountered an error attempting to create the client "testnode"
vm ================================================================================
vm
vm
vm Network Error:
vm --------------
vm There was a network error connecting to the Chef Server:
vm Error connecting to https://chef-server/organizations/dtna/clients - getaddrinfo: Name or service not known
vm
vm
vm
vm Relevant Config Settings:
vm -------------------------
vm chef_server_url "https://chef-server/organizations/dtna"
vm
vm If your chef_server_url is correct, your network could be down.
vm
vm
vm
vm [2014-06-23T18:12:26+02:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
vm Chef Client failed. 0 resources updated in 2.08654598 seconds
vm [2014-06-23T18:12:26+02:00] ERROR: Error connecting to https://chef-server/organizations/dtna/clients - getaddrinfo: Name or service not known
vm [2014-06-23T18:12:26+02:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)
tsi@chef-workstation:~/chef-repo$ ls
accumulator-0.2.0.tar.gz chefignore cookbooks environments Rakefile roles
certificates config data_bags LICENSE README.md
tsi@chef-workstation:~/chef-repo$ cd .chef/
tsi@chef-workstation:~/chef-repo/.chef$ ls
dtna-validator.pem knife.rb tsi.pem
tsi@chef-workstation:~/chef-repo/.chef$ vi knife.rb


tsi@chef-workstation:~/chef-repo/.chef$ knife bootstrap vm -x tsi -P 'xxxx' -N 'testnode' -r 'role[WebServer]' --sudo --bootstrap-proxy http://[2003:1b39:220:1::a00a]:8080 --use-sudo-password
Connecting to vm
vm sudo: unable to resolve host mrtg-server
vm [sudo] password for htadmin: Starting first Chef Client run...
vm [2014-06-23T18:23:53+02:00] WARN:
vm * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
vm SSL validation of HTTPS requests is disabled. HTTPS connections are still
vm encrypted, but chef is not able to detect forged replies or man in the middle
vm attacks.
vm
vm To fix this issue add an entry like this to your configuration file:
vm
vm ```
vm # Verify all HTTPS connections (recommended)
vm ssl_verify_mode :verify_peer
vm
vm # OR, Verify only connections to chef-server
vm verify_api_cert true
vm ```
vm
vm To check your SSL configuration, or troubleshoot errors, you can use the
vm `knife ssl check` command like so:
vm
vm ```
vm knife ssl check -c /etc/chef/client.rb
vm ```
vm
vm * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
vm
vm Starting Chef Client, version 11.12.2
vm Creating a new client identity for testnode using the validator key.
vm
vm ================================================================================
vm Chef encountered an error attempting to create the client "testnode"
vm ================================================================================
vm
vm
vm Network Error:
vm --------------
vm There was a network error connecting to the Chef Server:
vm Error connecting to https://[2003:1b39:130:1::102]/organizations/dtna/clients - getaddrinfo: Name or service not known
vm
vm
vm
vm Relevant Config Settings:
vm -------------------------
vm chef_server_url "https://[2003:1b39:130:1::102]/organizations/dtna"
vm
vm If your chef_server_url is correct, your network could be down.
vm
vm
vm
vm [2014-06-23T18:23:56+02:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
vm Chef Client failed. 0 resources updated in 2.113761997 seconds
vm [2014-06-23T18:23:56+02:00] ERROR: Error connecting to https://[2003:1b39:130:1::102]/organizations/dtna/clients - getaddrinfo: Name or service not known
vm [2014-06-23T18:23:56+02:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)
tsi@chef-workstation:~/chef-repo/.chef$

CookbookSiteStreamingUploader and StreamingCookbookUploader classes are not using ssl_verify config

https://tickets.opscode.com/browse/CHEF-5248

Two classes (one of which is deprecated) is not adhering to the config for SSL verification.

service chef-client restart fails

The main bug here is that service chef-client restart doesn't behave correctly, and will gracefully stop the chef-client daemon if it is already running, without restarting it.

What I think is happening in the normal series of events:

Chef-client starts in daemonize mode, creates the pid file /var/run/chef/client.pid, and acquires the flock on the pid file (see here and here)
some time later it forks a child process to converge the node, which creates /var/chef/cache/chef-client-running.pid and acquires the flock on it. (see here, by default :splay is nil and :interval is 1800 seconds, and see here)
client run completes, and flock is released on /var/chef/cache/chef-client-running.pid and the file is removed (see here)
the run loop sleeps 30 minutes, then starts the loop again and kicks off another chef-client run (see here)
(optionally) chef-client is told to gracefully stop, the flock on the pidfile is removed, and chef-client daemon gracefully exits, after the child process completes if it's running. (see here and here)

If the chef-client daemon receives a signal, i.e. TERM, it does not gracefully exit until it hits the beginning of the chef run loop again. This can be as long as 30 minutes + the time of a chef run if it has just started. However, the init script expects the daemon shutdown process to happen immediately (see here, $DIETIME is not set).
When the init script goes to start the daemon up again, the previous daemon process is still running with the flock on the pid file in /var/run/chef/client.pid while it's waiting to gracefully shutdown. The start command bombs out because it can't get the flock on the pidfile (see here), and eventually the old process gracefully shuts down and we are left with no chef-client daemon running at all.

$ sudo service chef-client restart
 * Restarting chef-client chef-client                                                                                                                                      [fail]
$ grep FATAL /var/log/chef/client.log
[2014-06-19T19:49:09+00:00] FATAL: Chef is already running pid 3695

Thanks!

Chef server broken on Debian (initctl missing)

Although not officially supported, chef server worked flawlessly on Debian.

With chef-boneyard/omnibus-chef-server@1f71622 (chef-boneyard/omnibus-chef-server#15) chef-server-ctl reconfigure breaks on Debian 7 with

Errno::ENOENT
-------------
No such file or directory - initctl status chef-server-runsvdir


Resource Declaration:
---------------------
# In /opt/chef-server/embedded/cookbooks/runit/recipes/upstart.rb

 37: execute "initctl status chef-server-runsvdir" do
 38:   retries 30
 39: end
 40:

The problem is that chef-boneyard/omnibus-chef-server@1f71622 now checks platform_family is debian which matches the officially supported Ubuntu and then uses upstart. However, for debian systems, it should use the runit:sysvinit recipe instead of runit:upstart.

It would be great, if chef-server-omnibus could distinguish between debian and ubuntu and still make it usable for debian environments.

After rebooting the chef-workstation it looses the configuration settings

When I'm setting up first time correctly the workstation using the knife configure initial command and I'm checking the connection between the server it works fine.
Once I'm restarting the OS and I'm running the same command:
knife user list
I get error:
ERROR: Your private key could not be loaded from /etc/chef/client.pem
Check your configuration file and ensure that your private key is readable

Of course there is no pem file as I'm storing it under the .chef directory inside the chef-repo.
It seems chef forgets or reads from wrong place it's configuration which is described in knife.rb

log_level :info
log_location STDOUT
node_name 'chefworkstation'
client_key '/home/gangeld/chef-repo/.chef/chefworkstation.pem'
validation_client_name 'chef-validator'
validation_key '/home/gangeld/chef-repo/.chef/chef-validator.pem'
chef_server_url 'https://chefserver:443'
syntax_check_cache_path '/home/gangeld/chef-repo/.chef/syntax_check_cache'
cookbook_path [ '/home/gangeld/chef-repo/cookbooks' ]

cookbook_file error gives incomplete list of search locations

When using a cookbook_file directive, one of the locations that Chef looks for files is based on the FQDN of the hostname in question, prepended by host-. I'd missed the host- prepend in my reading of some instructions on this point, and was having a situation where Chef couldn't find the file; in doing so, it presented a list of locations that it had looked, but that list did not include the host-<FQDN> subdirectory.

The commit that introduced the current messaging is 16a45a4. I believe this should probably be referencing the preferences variable, since preferences_for_path seems to be what generates the list of files that are actually checked... But I'm not very familiar with this codebase, and don't have a chef development environment set up just now, so hence submitting a ticket rather than a pull request.

Here's an example of the error message, from inside a Vagrant configuration:

==> server: [2014-06-10T23:03:31+00:00] FATAL: Chef::Exceptions::FileNotFound: cookbook_file[/etc/foo.conf] (bcfg2::default line 4) had an error: Chef::Exceptions::FileNotFound: Cookbook 'foo' (0.0.0) does not contain a file at any of these locations:
==> server:   files/ubuntu-12.04/foo.conf
==> server:   files/ubuntu/foo.conf
==> server:   files/default/foo.conf

I would expect to have an extra line (above the ubuntu-12.04 line), like:

==> server:   files/host-my-server.example.com/foo.conf

Allow specification of default log_location in knife.rb

Also prompt for default log_location when doing an interactive "knife configure".

Overriding an attribute with nil doesn't work during deep merge

https://tickets.opscode.com/browse/CHEF-4438

Here is a test for the expected behavior:

    it "can accept a nil override" do
      @attributes.normal['overriden_by_nil'] = 'cool value!'
      @attributes.override['overriden_by_nil'] = nil
      @attributes['overriden_by_nil'].should == nil
    end

https://github.com/michaelglass/chef/blob/override_doesnt_work_for_nil/spec/unit/node/attribute_spec.rb#L355

Lazy attributes evaluation context

Scenario:

I'm trying to lazy evaluate branch for deployment.

Steps to Reproduce:

deploy path do
  repository '[email protected]:user/repo.git'
  revision lazy { `git ls-remote --heads [email protected]:user/repo.git`.lines.first }
  user "deploy"
end

Only user 'deploy' has access to private repository. But I can't specify user for lazy evaluation.

Expected Result:

Ability to provide some context(user, group, environment, etc) for lazy evaluation.

Actual Result:

Access denied.