Manually building baseboxes

[grtjn]

The README tells you can run something like this:

packer build -only=virtualbox-iso centos-6.7-x86_64.json

But when I run that from the top-level I end up with __unset_box_basename__.virtualbox.box. That looks a bit odd.

The README also mentions a packer directory, which I didn't find in a fresh clone. Do I need to run some build script first?

PS: I am trying to recover the centos-6.5 VM (which was exposed as chef/centos-6.5 till yesterday) by manually building it..

[grtjn]

For background, this is actually rather annoying. All my chef based existing VMs are complaining with this message:

Bringing machine 'ml8-ml1' up with 'virtualbox' provider...
==> ml8-ml1: Checking if box 'chef/centos-6.5' is up to date...
==> ml8-ml1: There was a problem while downloading the metadata for your box
==> ml8-ml1: to check for updates. This is not an error, since it is usually due
==> ml8-ml1: to temporary network problems. This is just a warning. The problem
==> ml8-ml1: encountered was:
==> ml8-ml1: 
==> ml8-ml1: The requested URL returned error: 404 Not Found
==> ml8-ml1: 
==> ml8-ml1: If you want to check for box updates, verify your network connection
==> ml8-ml1: is valid and try again.

Would it be possible to re-instate those chef/centos VMs?

[cheeseplus]

The chef namespace on Atlas has been deprecated in favor of bento https://atlas.hashicorp.com/bento/ . The chef namespace was never really official and having broken boxes out there was generating issues that didn't match the current state of the definitions.

So boxes on chef were woefully stale and unmaintained so they were removed.

As for the building instructions, those will be updated shortly but you can use the bento tool in `bin/bento' which will fill in the variables for building.

[grtjn]

I tried build.sh, rake build_box['centos-6.7-x64_64'] and bin/bento, but had issues with all. For starters they do a bit too much. I just need the centos vboxes. It also started shutting down Vagrant VMs I had running (at which point I terminated the rake call), and looking at the rake file it looks like it will delete all VMs as well. The bento script seemed to do something, but then stalled at the point in VBox where it tries to load a kickstart script from some http address? That failed, and I had trouble getting passed that..

[cheeseplus]

build.sh is only for consumption in our buildkite build system and is not for general use.

bin/bento and the Rakefile are somewhere between general use and internal use - all bin/bento does is wrap packer (it passes through several options) and add some metadata (it keys off certain fields there). The Rakefile then wraps Bento and does a bunch of other stuff that will be moved elsewhere eventually.

If you'd like to build with packer and fix the name it's just:

packer build -only virtualbox-iso -var 'box_basename=debian-7.8-amd64' debian-7.8-amd64.json

As I said, the boxes are also available via Atlas, just the bento organization, not chef. They are also available directly from S3 via links in the README.md.

[grtjn]

centos-6.7 is available through bento, but not centos-6.6 nor centos-6.5. I'd like to make sure I won't run into the same situation when you will replace centos-6.7 with centos-6.8, by building the images myself, and publishing them indefinitely (if possible), even if they are really old etc etc..

I saw the links in the README. Can I use that with Vagrant, pointing to such links? Would save me the trouble of building myself.

Thanks for the basename option. Are there other vars I should watch out for? Or to put it differently, what are the essential differences between the root-level templates, and those in the packer dir (generated by bin/bento perhaps?)

[cheeseplus]

We replace the images because of how CentOS versions - unlike other distros where point releases are maintained independently, CentOS will update you to the latest via yum update. There is an active PR to rename to centos-# to get away from pinning to minor releases.

The links are just links to the box's on s3 which you can use with vagrant box add or you can use 'bento/centos-6.7' which will have Vagrant will automatically grab the latest from Atlas. The advantage (and why we are moving to Atlas entirely) is that these boxes are versioned and revokable in case a bad one got out.

There isn't any difference in the templates as such, bin/bento just fills in some variable names using Packers var system. When running bin/bento it really is just a thin wrapper around packer - it only add a single -var flag that points to a file that is generated which fills in some vars.

Ex:

bin/bento build --only virtualbox-iso fedora-21-x86_64

becomes:

packer build -only=virtualbox-iso -var-file=/var/folders/lf/s29n532j74301fnn7rkl2wq40000gn/T/fedora-21-x86_64-metadata-var-file20150828-62175-hx66aq fedora-21-x86_64.json

[grtjn]

Thanks for all the input. I managed to generate centos .box files using the bento tool. I also discovered you can pull .box files out of a local cache. I have documented details in this new git repository:

https://github.com/grtjn/centos-packer-templates

I have also taken the liberty of republishing the original chef baseboxes under my own name, giving all credits to Chef of course. I hope you don't mind? You can find them here:

https://atlas.hashicorp.com/grtjn

[cheeseplus]

We certainly don't mind republishing these as the license totally permits it but there isn't much need as we have the old versions in the commit history of the repository. Also, with regard to CentOS publishing old definitions - once you do a yum update anything in 6.x will be the latest 6.x. The reason we do not publish old boxes for CentOS is that minor version updates in CentOS are not unique versions but part of the same overarching 6.x (or 7.x etc) release and include security updates among other things.

We are actively looking at changing the definitions to something like centos-6-x64_64 to set the expectations of users as well as allow us to have past versions available via Atlas if someone really wanted an old box.