Posts Tagged ‘puppet’

Vagrant Fails To Start VM with Bad Default Machine Folder

I’m here at PuppetConf in Portland and one of the speakers got me all excited again about Vagrant. I’ve played around with Vagrant before, but he was showing off some awesome features that I didn’t realize existed which made me want to play with the tool again (more on that later!). Anyway, I updated all the versions of things Vagrant-related and tried to use it again. However, when I downloaded one of the default images from the getting started page I was greeted with an awesomely descriptive error:

[default] Importing base box 'lucid32'...
The VM import failed! Try running `VBoxManage import` on the box file
manually for more verbose error output.

Running it with VBoxManage as instructed gave a slightly-better-yet-not-so-useful error:
VBoxManage: error: Appliance file must have .ovf extension
VBoxManage: error: Details: code VBOX_E_FILE_ERROR (0x80bb0004), component Appliance, interface IAppliance, callee nsISupports
Context: "Read(Bstr(pszAbsFilePath).raw(), progressRead.asOutParam())" at line 302 of file VBoxManageAppliance.cpp

A few Google searches for this error got me almost nowhere except that it was likely a VirtualBox configuration issue. Great. After digging around for far too long, I figured out that it was because when I had played with Vagrant/VirtualBox in the past I had configured VirtualBox’s default machine folder to an external drive that I didn’t have plugged in! Doh. Anyway, was a pretty easy fix but I thought I’d share if it saved someone some time. The default machine folder is set on the first screen in the VirtualBox preferences window (at least for me on my Mac).

Tags: , , ,
Filed under How-Tos / Tips : Comments (0) : Sep 23rd, 2011

Service Refresh Procedure with Puppet

I encountered an interesting question this week at work after a little mistake was made in a config template in Puppet. We had the wrong type of comment character get inserted, so the config file on the Puppet client wasn’t valid and the service went away. Fortunately, it was caught and fixed within seconds and didn’t cause much of a disruption, but it made us a bit nervous about service restarts since the init scripts should do a configtest before doing either a restart or reload.

The answer wasn’t overly obvious after a quick Google search, so I thought I’d share what I found. Turns out, if we had simply RTFM‘d, we’d have known that the default behavior of Puppet is to issue a stop then a start which explains why the service got stuck in that state. The reason for the stop/start behavior is because not all services across all distros do things properly, so they took the least common denominator and made the user specify that a correct restart in the init script was available. The answer was easy enough. Just add..
hasrestart => true,
.. as part of the service definition and you’re good to go.

Just to be clear, I wouldn’t ever want to depend upon this, but it’s nice to have a last line of defense since mistakes do happen on occasion (since we’re all human and all).

I was also pleased to see that there’s a feature request for a similar “hasreload” feature as well!

Tags:
Filed under How-Tos / Tips : Comments (1) : Oct 7th, 2010