Apache in Vagrant

Last time, we set our vagrant box to be repeatably remoted into, basically by telling it to always use the default private key. This solution makes me a little sad, and I’ll try to clean it up later.

Anyway, we’re here in Vagrant’s tutorial, and we’re setting up bootstrap.sh. The basic idea is: In the root directory of the project, make a shell script that installs stuff you need. Then make sure that Vagrant’s provision command will invoke that shell script when the VM boots up.

The shell script, bootstrap.sh, will install apache and link the project root to /var/www. I’ve added apt-get install -y vim --fix-missing to it, so that when I’m ssh’ed into the box, I can make spot edits to files. Then we add config.vm.provision :shell, path: "bootstrap.sh" to the configure block of our Vagrantfile, and do vagrant up --provision. Let’s see how it works.

It worked! At least, tons of install noise scrolled by, I can still vagrant ssh, and running vim --version actually prints out a version, so apparently the install script succeeded.

That went so well that I’m feeling a bit cocky. Let’s try to get something more done: Networking.

Vagrant’s first option for networking is port forwarding, that is, telling my computer that calls to some specific port should be forwarded to some port on the guest machine. We’re going to add a line straight from the Vagrant tutorial to our Vagrantfile and then vagrant up again to see what happens.

config.vm.network :forwarded_port, guest: 80, host: 4567

Hopefully, this means that if I browse to http://localhost:4567 on my local machine, that will be forwarded to port 80 on the VM (which is the default port for non-secure http traffic). Let’s see how it works.

My vagrant vm is currently running, so I can just run vagrant reload to bring the new config back in. Also, apparently the new config will take affect without the --provision flag. I’m not sure yet which things do and don’t need that flag to take effect; hopefully I will learn that soon.

And by George it worked! Calls to http://localhost:4567 and calls to http://127.0.0.1:4567 are both showing valid responses from Apache, letting me browse the file system over http.

Probably the first thing I want to change is bootstrap.sh, which has the lines:

rm -rf /var/www 
ln -fs /vagrant /var/www

In other words “remove anything that ended up in /var/www somehow, and then link the projects root directory into /var/www so that Apache will serve the root directory.” That’s not exactly what I want; there’s stuff in my root directory that I’m not planning to serve over http, so I’m going to go off-tutorial for a second, make a folder in my project’s root on the host called wwwroot and have that served by Apache. Here goes.

I’m going to change that second line to ln -fs /vagrant/wwwroot /var/www and do vagrant reload, then just refresh my browser in the host OS.

Apache is still serving the same root folder. Maybe I need to halt and re-provision the VM. So next I try vagrant halt followed by vagrant up --provision. No luck.

Ok, so it looks like what’s happening is this: ln -fs /vagrant /var/www worked last time, and is still part of the state of my vm. If I remote in and run ln -fs /vagrant/wwwroot /var/www this fails with an error, telling me that /vagrant/wwwroot is the same file as /var/www/wwwroot. In other words, I need to unlink the files.

Because part of the file system on my host that I care about is shared with this misbehaving VM, so the first thing I do is just copy the root directory of my project somewhere else, in case I manage to delete the root directory or something. There are a lot of StackOverflow questions about removing symbolic links, and the commands look a lot like removing directories. I play around with some of these for a minute, but I get permission errors and things, and because of the similarity between removing links and removing directories, I’m nervous, so I stop going down this road.

Another choice I have is to simply kill the VM and try again. Presumably the new VM, which will never have had the incorrect link command run on it, will simply not have the problem. Let’s try that. I run vagrant destroy and then vagrant up --provision. Let’s see what happens.

Success! /vagrant/wwwroot is now being served by Apache. Maybe sometime in the future I’ll get better at shell scripting and symbolic links, but having this small victory seems like a good stopping point for today.

Till next time, happy learning!

-Will

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s