Jonathan's Pancheria

dotcom Thousandaire

… with a little bit of cargo cult possibly rolled in.  Anywhere, here’s the stuff I put into a VagrantFile (for Vagrant v2.x) to get boxes to be named properly both for hostname and for the name that appears in the Virtualbox GUI:

  Vagrant.configure(2) do |config|

  # Any other Vagrant 2.x config settings you want here
  config.vm.define '__YOUR_BOX_NAME_HERE__'
  # Any other Vagrant 2.x config settings you want here
  config.vm.provider "virtualbox" do |vb|
    # Any of your other virtualbox modifications = "__YOUR_BOX_NAME_HERE__"
    # Any other virtualbox modifications here
  # Any other Vagrant 2.x config settings you want here
  config.vm.hostname = "__YOUR_BOX_NAME_HERE__"
  # Any other Vagrant 2.x config settings you want here

Replace __YOUR_BOX_NAME_HERE__ with whatever you want to name the box. Also note that the stuff inside config.vm.provider "virtualbox" do |vb| might/will be different for other providers than virtualbox.

Published on 19/10/2016 at 06:42PM . Tags , ,

I ran across this today while trying to use the chef community database cookbook.  If you want to use it along with a postgresql database to e.g. create databases and create and assign roles to users, then you may need to do the following, at least with the chef 11.04 client running against a 10.18.2 server, which is my setup:

  • You will need to have your role have recipe[postgresql::ruby] in its run list before the database cookbook in the role file that uses database, or otherwise set up your chef environment have it run earlier in the order

  • In your recipe where you do your postgresql setup work, include the command chef_gem 'pg' before you use any of the database cookbook commands

Published on 18/03/2013 at 10:15PM under . Tags , , , , ,

I am doing a bunch of work in VMs managed with Vagrant+chef, and I have several different VMs configured for different projects/roles so that I can do dev work on a VM that has just the set of things on it that a QA or production box will have.  To make it easier, I put together some bash functions and a tab completion setup in my .bash_profile to make it easier to work with vagrant and multiple VMs.  I will describe what I wanted to accomplish and how I did it.


What I wanted was to be able to have multiple VMs and have it be easy to run a command against any of them without having to cd (change directory) to the correct directory for a server and then do what I needed. The idea is that the following commands should behave as follows:

  • vag server_a up: bring server_a up via vagrant up in server_a’s directory
  • vag server_name vagrant_command …: in general, run the vagrant command vagrant_command for the server server_name
  • firevm server_name: this is the one special command addition I made. I find it useful when I’m doing work on a server to bring it up from a suspended state, ssh into it, do my thing, then suspend the server when I log out of the ssh session. firevm is the name of the command I wanted to do that
  • Tab completion should work on the vag AND firevm command, so that if I tab-complete where server_name should be I should see a list of the servers available. For vag I also want it so that if I tab-complete on vagrant_command I get auto-complete against the list of vagrant subcommands

How I Did It

Where the Vagrant-powered VMs have to live

To make the scripting easy, I decided that all the Vagrant setups would live in one directory.

Setting Up the .bash_profile file

I put the following code in my ~/.bash_profile file (also available in this gist): 

The vag function

The vag function takes care of the vag server_name vagrant_sub-command ….

Implementing tab completion

The _vagrant_servers() function and the complete -F … command that follows it handles the tab completion. For the first argument to the commands it completes for, it shows the list of servers (directory names) in the common directory that your vagrant servers live in. If you are using the vag command, it will provide tab completion on the second argument with the list of vagrant sub-commands available. The list of subcommands was scraped out of the invocation of the vagrant command line with no arguments earlier in the script where VAGRANT_SUBCMDS is defined. No other arguments past those supported get any tab completion.

The firevm special command

Finally, the firevm shell function takes care of the special handling to resume the vm, ssh into it, and then suspend it.

Published on 11/01/2013 at 12:31AM under . Tags , , , , , ,

Powered by Typo – Thème Frédéric de Villamil | Photo L. Lemos