The Gluster Blog

Gluster blog stories provide high-level spotlights on our users all over the world

Some lessons learned on Vagrant with Fedora19


0) Vagrant shell provisioner runs as root .  Seems obvious but, if you dont know this you can get burnt.  For example, when it comes to ssh’ing into other machines in your private vagrant cluster.  See (5) for details on that.  In any case, keep in mind that your provisioner is not running as the vagrant user by default, so, if you plan to ssh as root into other machines, you will have to copy around keys accordingly.

1) You can repackage a new vagrant box after you modify it.  This is useful if you download a box from the .es site, find a problem (i.e. it has messed up default networking that prevents vagrant from doing its magic).  

For details, see : the “repackage” command.

 To rescue an old box, if you lost the url, you can run the repackage command (i.e.):

vagrant box repackage vagrant-fedora19B virtualbox

This will create a new box from the original box which you pulled down.  I think (not sure) that it will be identical to what was recorded in your “vmboxurl” parameter.  

2) There are two vagrant syntax’s.  

The old one: do |config|

And the new one:

Vagrant.configure(“2”) do |config| 

In any case, be careful that your variables match the version of vagrant you are using.  For example, there is a new syntrax for shared folders.

3) There is (unfortunately) no current way to specify your Vagrantfile.

Ever have two “similar” implementations of your vagrant setup?  It would be nice to run

vagrant up Vagrantfile2 

But alas, you cant currently do this.

4) Static IPs : If they don’t work out of the box ~ try another box ~ 🙂 Preferably, one hosted on !

To set up a private internal network between VMs, its quite easy: “private_network”, ip: “”

But some .box implementations for one reason or another will result in a every odd “eth1” error.  Im not a networking geek so I can’t say why.  But in any case, after alot of failed attempts to fix my networking with the fedora19 box downloaded from this post, I found that I could get everything to work with the vagrant fedora 19 box from did not have this problem.

5) Passwordless ssh is RIDICULOUSLY easy.  Just use the standard pre made vagrant insecure private key.

This is easy in vagrant.  Vagrant actually creates a insecure private/public key pair, and adds the public key to all vagrant boxes on startup.  All you have to do to add one vagrant box ssh to the other is enable private networking and paste:

—–END RSA PRIVATE KEY—–” >> /home/vagrant/.ssh/id_rsa

into your provisioner.  For example, for me, its literally the first line of my script.

6) Post provisioning: A hack around. 

There is no notion of a “post-provision” task in the Vagrantfile (for example: when all my machines are spun up – a task that runs afterwards, maybe, for example pinging them or updating /etc/hosts on them or whatever).

So instead ~ if you have static ips enabled, you can just add an if block to the end of your provisioning script which only runs if the “last” ip is pingable.  This is indirectly saying “only run if you are the last machine and your all ready to go”

#Say my machines are and  I can just add this..

if ping -c 1 > /dev/null 2>&1 ; then
     ssh “echo \”hi\” >> /tmp/a”
     ssh “echo \”hi\” >> /tmp/a”

Anyways… If you need any help setting up vagrant on f19 just ping ..

7) is awesome. 

If you are using Yum or Apt to setup   your VMs after they are provisioned, and you have alot of dependencies, these can make setup super fast, especially in a cluster environment where you have many VMs.   The way to confirm that its working as expected is to list the contents of the vagrant cache in /tmp.  Its easy to see that, on all VMs (i.e. in the cluster scenario), the timestamp of the writes for the *rpm files which were yum downloaded are the same.


  • 06 Dec 2020
    Looking back at 2020 – with g...

    2020 has not been a year we would have been able to predict. With a worldwide pandemic and lives thrown out of gear, as we head into 2021, we are thankful that our community and project continued to receive new developers, users and make small gains. For that and a...

    Read more
  • 27 Apr 2020
    Update from the team

    It has been a while since we provided an update to the Gluster community. Across the world various nations, states and localities have put together sets of guidelines around shelter-in-place and quarantine. We request our community members to stay safe, to care for their loved ones, to continue to be...

    Read more
  • 03 Feb 2020
    Building a longer term focus for Gl...

    The initial rounds of conversation around the planning of content for release 8 has helped the project identify one key thing – the need to stagger out features and enhancements over multiple releases. Thus, while release 8 is unlikely to be feature heavy as previous releases, it will be the...

    Read more