<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Vagrant on The Comfy Seat</title><link>https://beanbag.technicalissues.us/tags/vagrant/</link><description>Recent content in Vagrant on The Comfy Seat</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sun, 11 May 2014 00:00:00 +0000</lastBuildDate><atom:link href="https://beanbag.technicalissues.us/tags/vagrant/index.xml" rel="self" type="application/rss+xml"/><item><title>Vagrant, Fusion, &amp; DHCP Oddities</title><link>https://beanbag.technicalissues.us/vagrant-fusion-dhcp-oddities/</link><pubDate>Sun, 11 May 2014 00:00:00 +0000</pubDate><guid>https://beanbag.technicalissues.us/vagrant-fusion-dhcp-oddities/</guid><description>&lt;p&gt;I’ve had some random weirdness that I thought was related to Vagrant’s VMware Fusion provider until I turned on debugging tonight. As it turns out, Fusion had decided at some point in the past to start storing it’s DHCP leases in vmnet-dhcpd-vmnet8.leases~ instead of vmnet-dhcpd-vmnet8.leases. The same was true for vmnet1 too. After quitting Fusion and running ‘sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli –stop’ I removed vmnet-dhcpd-vmnet* so that all the leases would be reset. After that I reran ‘vagrant up’ and (finally) things worked as expected.&lt;/p&gt;</description></item><item><title>Configuration Management Part 3: Vagrant &amp; Packer</title><link>https://beanbag.technicalissues.us/configuration-management-part-3-vagrant-packer/</link><pubDate>Sun, 27 Apr 2014 00:00:00 +0000</pubDate><guid>https://beanbag.technicalissues.us/configuration-management-part-3-vagrant-packer/</guid><description>&lt;p&gt;To facilitate developing my Puppet code, the &lt;a href="http://amzn.to/QPzitQ"&gt;Pro Puppet&lt;/a&gt; book suggests using &lt;a href="http://bit.ly/QPzpFI"&gt;Vagrant&lt;/a&gt;. Seeing as I’ve been meaning to get around to learning it for a while I decided now was the time to finally do so. The only problem is that, being a responsibly paranoid SysAdmin, I was never a fan of using a base for my work that I didn’t know the contents of. I also never liked the idea of basing my work off of something I didn’t understand (a Vagrant box) or that could go away at anytime.&lt;/p&gt;</description></item><item><title>Vagrant, Veewee, &amp; Me (part 1)</title><link>https://beanbag.technicalissues.us/vagrant-veewee-me-part-1/</link><pubDate>Tue, 21 May 2013 00:00:00 +0000</pubDate><guid>https://beanbag.technicalissues.us/vagrant-veewee-me-part-1/</guid><description>&lt;p&gt;I have toyed with the idea of diving into &lt;a href="http://www.vagrantup.com/"&gt;Vagrant&lt;/a&gt; for a while now and, tonight, decided it was time.  I decided to be different and RTFM… this left me with two big questions: where can I get “boxes” from and how can I easily make my own?  After a little Googling I discovered that &lt;a href="http://puppetlabs.com"&gt;Puppet Labs&lt;/a&gt; provides a small library of &lt;a href="http://puppet-vagrant-boxes.puppetlabs.com/"&gt;the boxes they use&lt;/a&gt; internally.  On their page I also found the answer to my second question of how to make my own: &lt;a href="http://github.com/jedi4ever/veewee"&gt;Veewee&lt;/a&gt;.  It seems I have a bit of setup to do before I can start using Veewee but I think it will be worth it.  My plan is to bring up a base &lt;a href="http://www.centos.org"&gt;CentOS&lt;/a&gt; 6.4 x86_64 box and then make &lt;a href="http://docs.vagrantup.com/v2/provisioning/puppet_apply.html"&gt;a Vagrantfile that uses Puppet&lt;/a&gt; to configure it for building RPM’s in.  Ideally, I will start including this Vagrantfile with the source of any RPM I publish so that building a new one is easy-peasy.&lt;/p&gt;</description></item></channel></rss>