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.
/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!