I’m still working on getting our development team virtualbox images for development and I haven’t made a lot of progress until recently. The game changer has been vagrant which makes this task considerably easier.
Due to the fact that our production servers use arch linux and there weren’t any vagrant boxes that are current enough to use; my first real foray into vagrant has been to create an arch linux box for vagrant. I’ve made a pull request to the vagrantboxe.es repo to add my two boxes to the list, but there hasn’t been any movement made on it yet. In the mean time, they are available to download for free at sourceforge.
The minimal box is a basic arch install plus the packages that are necessary to run vagrant. The chef box builds on top of the minimal box to include packages that allow it to be provisioned with chef via vagrant. I’m not extremely happy with the end size of the boxes. In my opinion they’re a bit too large to be considered minimal installs. Sometime in the near future I may create a micro box were I’ll uninstall the base install packages that aren’t completely necessary to get up and running with vagrant, such as nano. Then anything that the end user wants can be installed easily via pacman.
My next step is to integrate with chef, a systems integration framework. That way we can have the same server build as the ones running in production for our development use. I’m so excited to have development servers that I’ve been dreaming about for a couple years now!
A while back I was working on setting up a LAMP stack with CentOS 5.8 and ran into this problem with Apache. It took a bit of work to figure out via google, so I’d like to add my the solution I found to the web for the sake of others as well as myself.
Port 80 Blocked
On a vanilla CentOS install, port 80 will be blocked via iptables. This can prove very frustrating when you see that Apache is running fine over the localhost but the machine can’t be hit over the local network. I added the following to /etc/sysconfig/iptables then ran
service iptables restart.
-A RH-Firewall-1-INPUT -p tcp -m state —state NEW -m tcp —dport 80 -j ACCEPT
Two good articles to learn more about iptables:
I have been working on creating a local dev environment that I can export and share with my fellow web devs. The goal is that it should be easy to install while mirroring the production environment as much as possible. Since our prod environment runs CentOS 5 I decided to install it in VirtualBox. As I’ve gone through this process I’ve come across a few gotchas that I’ll be blogging the answers to since I also found that it is a bit more difficult to google solutions for CentOS than Ubuntu. Not to mention that I’ll also have a reference for myself later on.
The first issue I came across when trying to install CentOS 5.8 as a VirtualBox Guest was that I wasn’t able to boot from the iso. When trying to boot I would get the following error:
PIIX4: not 100% native mode: will probe irqs later
No matter how I would change the storage settings for my virtual machine I couldn’t get it to boot. The solution was the check the box in the Settings > System > Motherboard tab to “Enable IO APIC”. Once that was enabled I was able to boot into the machine and install CentOS.
So I finally did it, I took the plunge and upgraded my Mac Book Pro from Snow Leopard to Lion. Overall it has worked out ok. I did a clean install on a new hard drive with more space since I eventually want to install Windows 7 on another partition. Having Snow Leopard and all my files on my old hard drive proved invaluable since I had forgotten to dump all my MySQL databases. So all I had to do was boot up my old hard drive via a usb enclosure, log into my old account and dump the dbs into sql files to import on my new system. This is all to say that the migration went fairly well until I reached my last step, set up Time Machine to back up to my Ubuntu desktop.
Today I accidentally added a git tag with a dash ( - ) for the name. A mere typo ended up creating quite the headache. I quickly found that I could delete the tag locally with no problems using:
$ git tag -d -
However when I pushed my update to the server I noticed that it didn’t update the remote sources. A git pull would recreate the tag on my local repo. This frustration led to a quick google search which resulted in this nice and simple howto. I thought I would share the answer here on tumblr in case that page gets lost one day to the 404 monster. Here is the answer assuming that the tag name is ‘12345’
$ git tag -d 12345
$ git push origin :refs/tags/12345
This is officially my first post as a blogger! Yes, I know, as a web developer I should be able to say that I’ve been blogging since that fateful day that Peter Merholz coined the term. I sincerely hope that my procrastination so far is due to the #1 virtue of a programmer according to Larry Wall. However, I’m sure that is not the case since that means I would’ve written a program that would assume my identity and write a blog for me. Oh well, I guess I have a ways to go yet. Thats actually what I hope this blog becomes. A web log of my journey through the tech world. That being said, I’m sure other ramblings and misguided anonymities will find their way on here since tumblr has made it dead easy to do so.