We are very excited to announce that Chef packages and related dependencies have been accepted into Ubuntu's Karmic Koala release! This is a great milestone in the effort to get Debian/Ubuntu packages of Chef available.
First of all, thanks go to Bryan McLellan for his initial efforts in getting this started, and for packaging many of Chef's dependencies for Debian. We would also like to thank Mathias Gug, Thom May, James Westby and the other Ubuntu Masters of the Universe for careful review and feedback. Finally, we thank and acknowledge upstream dependency authors Yehuda Katz (Merb), Kornelius Kalnbach (CodeRay) and Jamis Buck (syntax) for assistance.
What does this mean for Chef? Well, basically it means that on a 'Karmic' system you can get Chef and all its dependencies up and running with a simple APT installation! Enable Universe in the sources.list if it isn't already, then do:
Client install –
sudo apt-get install ohai chef
Server isntall –
sudo apt-get install ohai chef chef-server
"Wait, I have to specify multiple packages here?" you may ask. Chef itself is a library, and so is Ohai. Debian / Ubuntu policy encourages separate packages for user-land binaries and shared libraries. With the packages above, 'chef' will depend on the Ohai library, as it doesn't call 'ohai' the program when it runs. Most people probably want access to the 'ohai' program, so we install it here. Similarly, the 'chef-server' package doesn't actually require the 'chef-client', 'chef-solo' or 'ohai' programs, but most people are probably going to manage their Chef Server with Chef, and so having the client programs is convenient.
More about configuration differences, contributing and next steps, continue after the fold…
Configuration Differences
If you're already using Chef, you'll need to know the differences from our normal bootstrap configuration.The chef-solo bootstrap is not actually necessary when using the packages. Ubuntu (and Debian) generally expect when a package is installed, its services or daemons are setup and running without (much) effort. The gem distribution method for Chef can't make any assumptions when the gems are installed, since we don't know what platform we're on, so we use the bootstrap to get everything configured. With distribution specific packages, however, we can make all kinds of assumptions, since Debian / Ubuntu policy has strict guidelines that we can follow, and know that things will work.
So what are those differences? Glad you asked!
All services (chef-client, chef-indexer, chef-server) are started via LSB compliant init scripts.
The 'chef' user and group are not created by the package installation at this time, but may be in the future, though the IDs won't be the same as the bootstrap configuration.
Service-specific configuration files are created in /etc/chef, and the files are commented. Note that not all possible configuration values are set, only the most common, or those which should have defaults to comply with FHS or Debian / Ubuntu policies and recommendations.
All configurable file path locations are Filesystem Hierarchy Standard (FHS) compliant. This is a requirement in the packaging policy. As such:
- /var/run/chef – contains PIDs used by the init scripts.
- /var/cache/chef – contains the cache, the default internal to chef is (/var/chef/cache).
- /var/lib/chef – contains state information used by the package.
- search_index – index files from chef-indexer.
- openid – openid registration/nonce data.
- cookbooks – not used, /srv/chef/cookbooks is preferred.
- /var/log/chef – log files for all services.
- /srv/chef – data 'served' by the system, used on Chef Servers, but not created by package.
- cookbooks – default location for cookbooks.
- site-cookbooks – site-specific cookbooks and overrides, configurable.
- nodes – noted in the config file but not used by default.
- roles – the Ruby DSL/JSON files for Roles.
As mentioned above, log files are all stored in one place, /var/log/chef. Log files are named after the service (client, indexer, server), and are rotated via logrotate.
In addition to init scripts, Chef also has man pages for chef-client, chef-indexer and chef-server.
Server Specific Differences
The server is configured to start up two Merb workers on localhost, ports 4000 and 4001, the latter for openid. Passenger is not a package in Ubuntu at this time, so we can't use it by default with the Chef server package installation. To enable SSL, you'll need to proxy with Apache or Nginx.
Stompserver is installed as a package as well, and started up with an init script instead of a runit service.
CouchDB in Ubuntu Karmic is version 0.10 and in general introduces some breaking changes. Chef is compatible, but other applications may not be. We only mention this here since some people have been introduced to CouchDB because Chef uses it, and have started using it for other things as a result.
Contributions
"That all sounds great, how can I contribute?" We now have two paths of contribution. You may recall reasons why we chose the Apache License, which talks about contributor license agreements (CLAs). With the Ubuntu / Debian packages, we now have two places where the community can contribute, so lets talk about that briefly. The CLAs are still required to contribute to Opscode's source of Chef, and the workflow is the same. Issues with the Chef packages in Ubuntu will be filed in Launchpad, and patches can be submitted there. However, patches submitted for the packages will not be merged back into Opscode's upstream source until a corresponding ticket in Jira is created and a CLA is signed. We will update the Chef wiki with this additional workflow.
Next Steps
Some of the other tasks we are working on for this overall Debian/Ubuntu packaging effort:
- Documentation – as mentioned, we have updates to the wiki.
- Cookbooks – these should work seamlessly when using packages instead of gems.
- Integrating changes – add the man pages and init scripts to Chef's source.
- Opscode APT repository.
- Other Debian and Ubuntu releases.
We would love to have Chef packages for all 'current' releases of Debian: stable, unstable, testing, and Ubuntu: jaunty, intrepid, hardy, we are working on backporting and syncing Chef with these various releases. That process will take time, so we are also working on an Opscode APT repository that will be updated with new releases of Chef and other related software (Ohai, Mixlibs, other dependencies). We'll announce that on the blog when it is ready for general usage.