So if you have an idea for a chef cookbook, now it’s the time to start working on it. I’m offering my help for free for all my blog readers: I will help you write a cookbook by implementing your ideas; help reviewing it or suggest improvements, or whatever else you might need help with. Use the contact form to email me (or DM me on twitter) and let me know how I can help.

If you don’t have time to write a new cookbook but you have a great idea for a cookbook that is missing from the opscode community site, please post it bellow in the comments section and I’m sure some of my blog readers will help create it.

Again this is a brilliant idea from Opscode and it creates a win-win situation for everyone. I’m just curious, is this the first idea from their new community manager? If this is the case, great job Jesse .

So let’s see how we can use veewee. I’m assuming you already have vagrant installed (and virtualbox), but if you don’t please install them first. To install veewee we just have to install the veewee gem:
gem install veewee
once you installed veewee you can see a new task added to vagrant: basebox.

Here is the list of the templates we get out of the box once we install veewee:
vagrant basebox templates
The following templates are available:
vagrant basebox define '' 'archlinux-i686'
vagrant basebox define '' 'CentOS-4.8-i386'
vagrant basebox define '' 'CentOS-5.6-i386'
vagrant basebox define '' 'CentOS-5.6-i386-netboot'
vagrant basebox define '' 'Debian-6.0.1a-amd64-netboot'
vagrant basebox define '' 'Debian-6.0.1a-i386-netboot'
vagrant basebox define '' 'Fedora-14-amd64'
vagrant basebox define '' 'Fedora-14-amd64-netboot'
vagrant basebox define '' 'Fedora-14-i386'
vagrant basebox define '' 'Fedora-14-i386-netboot'
vagrant basebox define '' 'freebsd-8.2-experimental'
vagrant basebox define '' 'freebsd-8.2-pcbsd-i386'
vagrant basebox define '' 'freebsd-8.2-pcbsd-i386-netboot'
vagrant basebox define '' 'gentoo-latest-i386-experimental'
vagrant basebox define '' 'opensuse-11.4-i386-experimental'
vagrant basebox define '' 'solaris-11-express-i386'
vagrant basebox define '' 'Sysrescuecd-2.0.0-experimental'
vagrant basebox define '' 'ubuntu-10.04.2-amd64-netboot'
vagrant basebox define '' 'ubuntu-10.04.2-server-amd64'
vagrant basebox define '' 'ubuntu-10.04.2-server-i386'
vagrant basebox define '' 'ubuntu-10.04.2-server-i386-netboot'
vagrant basebox define '' 'ubuntu-10.10-server-amd64'
vagrant basebox define '' 'ubuntu-10.10-server-amd64-netboot'
vagrant basebox define '' 'ubuntu-10.10-server-i386'
vagrant basebox define '' 'ubuntu-10.10-server-i386-netboot'
vagrant basebox define '' 'ubuntu-11.04-server-amd64'
vagrant basebox define '' 'ubuntu-11.04-server-i386'
vagrant basebox define '' 'windows-2008R2-amd64-experimental'

This means that we can build a box based on any of the above templates. That’s awesome! Let’s say we want to build a debian squeeze box using veewee; we would have to run:
vagrant basebox define 'debian-60' 'Debian-6.0.1a-amd64-netboot'
and this will create a folder definitions/debian-60 with the following files (the content of the veewee template):
definition.rb
postinstall.sh
preseed.cfg
we can modify/tune any of those files based on our custom needs. The file definition.rb is the main definition of the template. Here you would define the memory size, disk size, iso file, etc. The content is very easy to understand, but you would normally not have to change many things here. preseed.cfg is just a standard preseed file where you would customize the actual install process (you could change here the partitions or their type, timezone setup, etc). And finally postinstall.sh that is a bash script that will run at the end of the installation process and it will install ruby, gems , chef and puppet and also the virtualbox guest additions (needed for shared folders).

If you have the iso already place it in ‘currentdir’/iso. If not, veewee will download it and place it in the appropriate folder before starting the install process:
vagrant basebox build 'debian-60'
this will start the installation and you can see all the steps it takes (the keystrokes as they are entered, etc.). This can take a while… Once it is done you can validate the build with:
vagrant basebox validate 'debian-60'
(this will run a few basic tests to see if it can connect to the vm as user vagrant, if chef and puppet were installed, if the shared folders are accessible, etc).

And finally you can export it as a vagrant box with:
vagrant basebox export 'debian-60'
and add it to vagrant:
vagrant box add 'debian-60' debian-60.box
and now you can use it in vagrant with:
vagrant init 'debian-60'

That’s it. Very simple and now we have our own box built from scratch. As a side note, I found this very useful to test and troubleshoot preseed configurations . As you can see there are plenty of templates available in veewee but if you create a new one please consider to share it with others and send it to Patrick on github. I’m sure he will be happy to include it in newer versions of veewee. And if you found this useful don’t forget to thank Patrick for his great work on this awesome tool.

1. Stop all the chef related services

Here is a handy command that will stop all the possible chef server related services:
for svc in server server-webui solr expander
do
sudo /etc/init.d/chef-${svc} stop
done

2. Upgrade the chef-server gems

Simply run:
sudo gem update chef chef-server --no-ri --no-rdoc
and this should upgrade all the other gems it needs to. A sample output will look like this:
gem update chef chef-server --no-ri --no-rdoc
Updating installed gems
Updating chef
Successfully installed chef-0.10.2
Updating chef-expander
Successfully installed chef-expander-0.10.2
Updating chef-server
Successfully installed chef-server-api-0.10.2
Successfully installed chef-server-webui-0.10.2
Successfully installed chef-solr-0.10.2
Successfully installed chef-server-0.10.2
Gems updated: chef, chef-expander, chef-server-api, chef-server-webui, chef-solr, chef-server

Optional: if you want you can cleanup the system from old, unused gems with:
sudo gem cleanup

3. Start back the chef server services

Again in a single command, now to start them:
for svc in server server-webui solr expander
do
sudo /etc/init.d/chef-${svc} start
done

That’s it, now you should be running the latest and greatest chef server version 0.10.2.

Here are the members of the configuration management panel (from left to right):

• Igal Koshevoy of AutomateIt
• Brendan Strejcek of Cfengine
• Luke Kanies from Reductive Labs for Puppet
• Narayan Desai of bcfg2
• Adam Jacob from Opscode for Chef

Luckily the video of the session (among other videos from Open Source Bridge) was published and anyone can see this great event:

Now, after I sow this I must admit that I was hoping for a little more engagement and controversy. Instead we sow a friendly debate where everyone presented his own tool, without trying to go over the line and tell why it is better than the one of someone else (we have definitely seen several such blog posts from them in the past ). Anyway this was a great event and a great opportunity to have all the major people in this field come together and share their story. I’m sure that after this they will get back to work, we will see new features and improvements in their tools.

Bcfg2 is a debian friendly project, meaning they provide inside the source package all what is needed to build a debian package very easy. We will use for this a debian etch system, but this should work on any debian based system.

1. Download

First we need to download the source package:
wget ftp://ftp.mcs.anl.gov/pub/bcfg/bcfg2-0.9.6.tar.gz
tar -zxvf bcfg2-0.9.6.tar.gz
cd bcfg2-0.9.6

2. Install dependencies

Next we need to install the dependencies necessary to build the package. Depending on the state of your system this might look different from the output bellow. You will need to have basic debian building tools; in case you don’t have them already install them now:
apt-get install devscripts build-essential fakeroot cdbs pbuilder

Since the package is prepared for multiple distributions types and versions of python, we will have to select that we want to use it for debian etch pycentral:
cd debian
./buildsys-select.sh pycentral
(the available choices are 2.3, 2.4 and pycentral)

Now we can move on and install the rest of the dependencies (python-dev, etc.):
cd ..
/usr/lib/pbuilder/pbuilder-satisfydepends

3. Build and deploy the package

Finally we can now rebuild the package:
debuild -us -uc
cd ..
ls *.deb
bcfg2-server_0.9.6-0.1_all.deb
bcfg2_0.9.6-0.1_all.deb
Probably you will want to put the resulted packages in a local debian repository to perform the upgrade easily on several systems, maybe even using bcfg2 itself .

SSHbase has two basic functions:

• to generate ssh host keys; if a system has not a key in the repository, it will be generated on its first check-in
• to maintain a consistent ssh_known_hosts file, and deploy it to all systems. This will include all the public keys in the repository.

To enable SSHbase we have to add it to the generators line in the bcfg2 server config, like this:
/etc/bcfg2.conf:
generators = SSHbase,TCheetah,Cfg,Pkgmgr,Rules- the bcfg2 server will need to be restarted to see this change.

Next we need to add configurations entries for /etc/ssh/ssh_known_hosts, and /etc/ssh/ssh_host_dsa_key (or rsa, or both) and add them to a bundle or base.
We can put them in Base like this:
Base/ssh_keys.xml
<Base>
<ConfigFile name='/etc/ssh/ssh_known_hosts'/>
<ConfigFile name='/etc/ssh/ssh_host_dsa_key'/>
<ConfigFile name='/etc/ssh/ssh_host_dsa_key.pub'/>
</Base>
or include them in a bundle like this:
Bundler/ssh_keys.xml
<Bundle name='ssh_keys' version='2.0'>
<ConfigFile name='/etc/ssh/ssh_known_hosts'/>
<ConfigFile name='/etc/ssh/ssh_host_dsa_key'/>
<ConfigFile name='/etc/ssh/ssh_host_dsa_key.pub'/>
<ConfigFile name='/etc/ssh/ssh_host_rsa_key'/>
<ConfigFile name='/etc/ssh/ssh_host_rsa_key.pub'/>
</Bundle> (where we added the rsa keys also). And include the ssh_keys bundle in a Group as needed.

After this any system that will checkin and don’t have its ssh keys in the bcfg2 repo, the bcfg2 server will generate them and put them inside bcfg2/SSHbase/ssh_host_dsa_key.H_<HOST> and ssh_host_dsa_key.pub.H_<HOST>, while the ssh_known_hosts file will be generated on the fly from all the existing keys in the repository.

Plugin documentation: http://trac.mcs.anl.gov/projects/bcfg2/wiki/SSHbase