One of the first big draws of Ruby on Rails in late 2006 was the ability to host my development environment locally. Not only did this cut down on the chore work of developing in an environment, but it probably also boosted productivity for me substantially. A year later when I started teaching myself Python, another nail was hammered into the coffin that is my opinion of PHP. That said, I’ve toyed with a lot of different idea’s of hosting a PHP environment locally but to a degree stymied in the effort.
Late last year I asked on Stack overflow a question of how to accomplish the above for PHP. Results were somewhat mixed and it looks like everyone who provided an answer was ultimately punished for their effort. As of March 5, 2010 the only answer with a positive vote is because I up voted it up.
Now a few months down the road, I’ve been playing with a much simpler approach using Lighttpd. It’s not perfect for a couple reasons I will point out…but good enough for me, for now.
What seems like a lifetime ago, I was the database administrator for a very heavily trafficked web SaaS site. One thing I remembered vividly was that for a poorly configured development instance of MySQL, random logging and utility files would crop up in strange places. Since I was already spending a good portion of my life at that time with MySQL, I spent some extra time to figure out that these files were showing up because my.cnf was configured with relative file paths. Taking that memory alongside my habit of relaying on document relative paths in Apache, I wondered if I could do the same for lighttpd.
Turns out you can actually. So using the above template, I can host arbitrary locations in my /home directory by simply running “lighttpd -f lighttpd.conf -D” which translates out to: Lighttp’y run using this specific configuration file ( -F lighttpd.conf ) in the current PWD and stay resident to the console -D so I can shut you down later”
Unless you change the local config file to something else, you can’t run two instances of lighttp’y concurrently. First reason is that the second instance would try to listen to the same port for http traffic. This is pretty easy to fix, just change sever.port to some other port #. The second problem is that fastcgi.server also has to have it’s own port to listen for fastcgi traffic.
Also, it might not be to obvious, but if you ran the above config on a non-firewalled, internet homed box, someone could find your development environment and possibly cause havoc.
The first problem is a doozy that won’t have an easy fix… and its debatable whether investing time to come up with a fix.
Second problem is stupid easy by adding:
server.bind = "127.0.0.1"
to tell your instance to home on the loopback address.