Bento is a project that encapsulates Packer templates for building Vagrant baseboxes. We use these boxes internally at Opscode for testing Hosted Enterprise Chef, Private Enterprise Chef and our open source cookbooks via test-kitchen.
The following baseboxes are publicly available and were built using this project. Note that our baseboxes do not include Chef Client. Vagrant can be instructed to install Chef at runtime using the vagrant-omnibus plugin.
These baseboxes were all built using a Mac OS X host running VirtualBox 4.3.8, and have that format of Guest Extensions.
These baseboxes were all built using a Mac OS X host running VMWare Fusion 6.0.2, and have that version of VMWare Tools. The boxes should work unchanged in VMWare Workstation for Windows or Linux.
Older baseboxes include Chef and therefore are not compatible with some new plugins. The full list of old boxes are available in the old boxes file.
Build Your Own Boxes
First, install Packer and then clone this project.
packer directory, a JSON file describes each box that can be built. You can use
packer build to build the
$ packer build debian-7.2.0-i386.json
If you want to use a another mirror site, use mirror variable.
$ packer build -var 'mirror=http://ftp.jaist.ac.jp/pub/Linux/debian-cdimage/release' debian-7.2.0-i386.json
If you only have VMware or VirtualBox available, you may also tell Packer to build only that box.
$ packer build -only=virtualbox-iso debian-7.2.0-i386.json
Congratulations! You now have box(es) in the ../builds directory that you can then add to Vagrant and start testing cookbooks.
Mac OS X (10.7, 10.8, and 10.9), Red Hat Enterprise Linux, and SUSE Linux Enterprise Server templates are provided. However, their ISOs are not publicly retrievable and as such, the URLs in those templates are bogus. For RHEL and SLES, you should substitute your server where you host the ISOs, using the mirror variable as above.
Mac OS X Boxes
Mac OS X builds are supported for VMware only. We would welcome a contribution to add VirtualBox support.
To build a Mac OS X box, you will need to start with an installer for your desired version of OS X. You will then need to use Tim Sutton's osx-vm-templates/) to modify that installer for use by packer. The output of that build will include the location of the ISO and its checksum, which you can substitute into your
packer build command, e.g.:
$ packer build -var 'iso_checksum=<checksum>' -var 'iso_url=<iso_url>' macosx-10.9.json
There is a known issue where test-kitchen starts a Mac OS X box correctly, but
vagrant up fails due to the absence of the HGFS kernel module. This is due to a silent failure during the VMware tools installation and can be corrected by installing the VMware tools on the Mac OS X box manually.
Packer does not yet support Windows, so veewee definitions are still used for building those boxes. You must build these boxes yourself due to licensing constraints. You can build these as follows:
$ bundle install $ bundle exec veewee vbox build [definition-name]
Special Note About Building from Windows Hosts
When building boxes from a Windows host system, you must ensure that kickstart configuration files (
ks.cfg for RHEL
based systems) and preseed files (
preseed.cfg for Debian based systems) have Unix line endings (i.e. lines end with
LF character only). Moreover, it's also a good idea to have
*.sh scripts with Unix line endings too.
When these files have Windows line endings, the group creation can fail in the pre-seed phase and in turn, prevents the
vagrant to be created correctly. This ultimately results in Packer not being able to connect to the newly booted
up machine with an error message that looks like this:
==> virtualbox-iso: Waiting for SSH to become available... ==> virtualbox-iso: Error waiting for SSH: handshake failed: ssh: unable to authenticate, attempted methods [none password], no support
Since Packer tries to log in with user
vagrant but it was not created successfully in the pre-seed phase, it is unable
to connect to the machine and the packaging process stops.
By default, when cloning this repository, git should normalize
*.sh to Unix line endings
*.bat to Windows line endings, thanks to the .gitattributes file in the repository. However, if
it's not the case because you have overridden line-ending conversion in your own git configuration, convert the offending files so they have the correct line endings.
Bugs and Issues
Use the issue tracker to report bugs, features or other issues.
License & Authors
Mac OS X templates were adopted wholesale from Fletcher Nichol's packer templates.
- Author: Seth Chisamore (firstname.lastname@example.org)
- Author: Stephen Delano (email@example.com)
- Author: Joshua Timberman (firstname.lastname@example.org)
- Author: Tim Dysinger (email@example.com)
- Author: Chris McClimans (firstname.lastname@example.org)
- Author: Julian Dunn (email@example.com)
- Author: Tom Duffield (firstname.lastname@example.org)
- Author: Ross Timson (email@example.com)
- Author: Fletcher Nichol (firstname.lastname@example.org)
Copyright 2012-2013, Opscode, Inc. (<email@example.com>) Copyright 2011-2012, Tim Dysinger (<firstname.lastname@example.org>) 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.