Today I’m happy to announce the release of Chef 0.9.8, which is the first major feature update to the Chef 0.9 line and contains improvements and bug fixes in nearly every part of chef.
Courtesy of many-time MVP Ian Meyer we now have support for using custom bootstrap scripts with knife. To use one of the provided scripts, just run knife bootstrap HOST -D BOOTSTRAP_FLAVOR. Chef 0.9.8 ships with bootstrap scripts for CentOS (centos5-gems), Fedora (fedora13-gems), and Ubuntu using either gems (ubuntu10.04-gems) or Opscode’s apt repo (ubuntu10.04-apt). If you prefer to write your own, just create your script as an ERb template and stick it in a ‘bootstrap’ directory under your .chef directory (e.g., ~/.chef/bootstrap/my-bootstrap.erb). Ian also refactored the WebUI’s authentication logic, fixing lots of bugs in the process.
In addition to Ian’s customized bootstrapping feature, we also have a patch from our old friend AJ Christensen. AJ added the ability to specify your identity file with knife bootstrap and knife ec2 server create. This is a huge improvement over mucking with your ssh-agent to configure this stuff. Thanks, AJ!
We have added “chef-server (api)” and “chef-server-webui” to the process name for the API and Web UI servers, and also removed Merb’s process management. If you’re using the default configuration with thin, you’ll now see something like this in your process listing:
bash$ ps aux|grep merb
chef 26651 11.6 1.3 2495304 53424 s010 S+ 11:21AM 3:21.27 merb : chef-server-webui : worker (port 4040)
chef 33371 2.4 1.1 2483272 44248 s009 S+ 12:13PM 0:04.86 merb : chef-server (api) : worker (port 4000)
If you have any custom init scripts or process management for your Chef server, you’ll want to double-check that your init scripts work correctly with this update. The init scripts bundled with Chef work just fine with the new process names, so you don’t need to change anything if you’re using those.
For you Unicorn users, we are now bundling our config.ru rackup file with the RubyGems packages for chef-server-api and chef-server-webui.
In this release we have also integrated knife with our cookbook sharing site, cookbooks.opscode.com. To use this feature, just sign up for an account with opscode, then configure your knife.rb with your username and private key. Once you’re all set up, uploading a cookbook to share is as easy as:
knife cookbook site share nosql-db-of-the-week
If you made a mistake and the world isn’t quite ready for your “nosql-db-of-the-week” cookbook just yet, you can remove it from the cookbooks site with unshare:
knife cookbook site unshare nosql-db-of-the-week
We have also cleaned up knife’s help output in this release. Instead of dumping all available help to the screen, it now lists the available subcommands, grouped by category. To get the list of all options for a subcommand, just run that subcommand with the --help flag.
Your MVP for this release is Joe Williams. At the 11th hour before release, Joe found and fixed two critical bugs in the (Python) easy_install provider. Thanks, Joe!
Previous MVP Doug MacEachern continues to expand our Windows support, this time extending the execute resource to work on windows platforms and fixing file backups to work correctly with Windows paths. Doug also added support for using Chef with a proxy. To enable proxy support in Chef, simply configure your http(s) proxy in client.rb, like this:
http_proxy "http://proxy.vmware.com:3128"
https_proxy "http://proxy.vmware.com:3128"
You can also specify a comma separated list of URLs to exclude from proxying, like this:
no_proxy "*.vmware.com,10.*"
Another Windows-related fix was submitted by Jon Seaberg, who fixed the script resource to work correctly when your temporary directory path has spaces in it, which is common on Windows.
Akzhan Abdulin, another prior MVP, contributed a bunch of patches to this release, including fixing all of our regular expressions to escape inputs and dotfile support for remote directories.
Thanks to Toomas Pelberg, we continue to improve our Solaris support with a package provider for solaris. The solaris package provider wraps the standard pkgadd package system for Solaris, providing capabilities similar to the dpkg and RPM package providers.
One of my favorite fixes this time is a more readable #inspect method for Chef::Node:Attribute, courtesy of Pavel Valodzka.
Courtesy of Andrey Sibiryov, the ruby_block resource can now participate in the Chef notification system.
Avishai Ish-Shalom fixed a problem with the mount provider when mounting by UUID or LABEL, where the provider would fail to find the device when examining the device’s current state.
I’d also like to give a hat tip to Dylan Egan, who did some awesome debugging on a particularly tricky bug that was causing JSON attributes to not be applied to nodes on their first chef client runs. With Dylan’s detailed diagnosis, it was easy to fix the problem in tandem with another fix we were already working on.
From the prolific Tollef Fog Heen, we have a fix for our negative UID detection. The negative UID detection was wrongly determining some large UIDs to be negative UIDs that had “wrapped” to a large integer, causing errors when it tried to “unwrap” them. Thanks again, Tollef!
Those of you who are scripting server installs will appreciate the work of Dan Prince, who added an option to accept the defaults in knife configure. Now you can just run
knife configure -i -y --defaults
And you’ll get knife configured with all of the default values.
Also in this release, Chef now saves its expanded run list and role list to the recipes and roles attributes on the node. This means that if you have a role “monitoring” that includes the role “nagios,” you can search your nodes for “roles:nagios” and it will find all nodes using that role, even if the role isn’t in the top level run list for the node. The recipes attribute works similarly, you can search for “recipes:nginx*” and find all nodes with an nginx recipe, even if that recipe is only included via a role (or a role within a role, or…).
Also released today is Mixlib-Authentication 1.1.4. This update is required when updating your chef-server. This update includes refactored request verification code which allows chef-server to determine if an authentication failure is the result of an incorrect timestamp set by the client and return a more helpful error message in this case. A tip of the hat goes to Akzhan Abdulin, who provided the initial patch for the issue.
Shef was one of many new features released with Chef 0.8.0 but it hasn’t had many updates aside from a few maintenance fixes until now. In this release, we’ve given shef its own configuration file, and added support for multiple named configurations. This makes it easy to use shef as an admin interface to a Chef server (or multiple Chef servers) without needing to create a “dummy node” on the server to fake out shef’s boot process. Of course, shef isn’t very convenient as an admin interface to the server if you need to be an expert on Chef’s internals to use it, so we’ve added convenient commands for listing, searching, and bulk updating Chef data. To get the full list of commands, simply run help from within shef. Extended help is available for some commands: to get verbose help for the nodes command, for example, just run help :nodes and you’ll get a full explanation of the command and its subcommands.
To try out, fill out at least the following information in your ~/.chef/shef.rb configuration file:
node_name 'your-knife-client-name'
client_key '/path/to/your/client.pem'
chef_server_url 'https://chef.example.com/'
Then run shef at the command line and try out the following commands (adjusting the data to match your infrastructure, of course):
# see what's new
chef (preprod) > help
# find nodes in the monitoring role
chef (preprod) > nodes.find :role => :monitoring
# take a peak at their network settings
chef (preprod) > pp nodes.find("role:monitoring") {|n| [n, n.network.to_hash] }
# who's in the users databag?
chef (preprod) > databags(:users).all
Finally, we’ve added support for running chef as a different node within shef. This allows you to run a shef session using the node attributes, run list, and cookbooks of a completely different node. The one major caveat is with cross-platform support: even though shef’s masquerade support allows for cross-platform masquerading, it’s likely that your cookbooks are tailored to your platform of choice. Once you’ve set up your test box as a reasonable facsimile of the target node, just run become_node(*NODE_NAME*) and shef will load all of the cookbooks of that node and replace the local node object with the other node’s data. From there, you can run the recipes using all of shef’s debugging goodness you’ve come to love.
We’ll see you at 0.9.10!