On getting lighttpd + PHP working on OS X Tuesday, Mar 2 2010 

Now playing: ♫ One More Time – Daft Punk

My first post of 2010!  I have been so busy that I just haven’t had any time to write anything in here.  But I have something special for you today; some build instructions for making an experimental dev server out of a Mac.

I use a Mac at work.  And being that I frequently have to test out our new Web stuff (some written in PHP but the majority written in Django), it’s helpful to have a working lighttpd install on it.  I’ve considered dual-booting with FreeBSD, but it seems a bit of a challenge to get all of the Apple hardware to work on FreeBSD (especially WiFi; we don’t even really use wired Ethernet at work anymore) so I’ve held that off for a while.  I could also use my desktop, but with the KVM on the fritz I just find it easier to sometimes run sites on OS X.

This isn’t a problem with Django, because it comes with a small development server that I can use.  But it is big problem with PHP; the Apache2 built in to Snow Leopard doesn’t seem to like me or PHP (or my configuration) and I prefer lighttpd anyway.  I could never find a really good guide to installing any of this online without resorting to MacPorts or Fink or even Aptitude.  I prefer to keep my system clean of the port systems (even though I’ve heard great things about MacPorts, it just seems ugh).   So, here’s how I got lighttpd and PHP to play nice on OS X with FastCGI:

Absolute prerequisites

  1. You must be absolutely comfortable with using Terminal and compiling things by hand.
  2. You must have already installed XCode, because we’re going to be using GCC and friends.

lighttpd installation

  1. Install PCRE.  This is the only lighttpd dependency that Mac OS X doesn’t ship developer libs with.
  2. I ran configure like this:
    ./configure --prefix=/usr/local --with-openssl --with-kerberos5 --with-ldap --with-zlib
    This allowed me to test SSL and Kerb5, which we use on one of our portals, and a few other miscellaneous things I feel will be useful.
  3. make and then sudo make install.
  4. Congratulations, you have an almost-working lighttpd!

PHP installation

For GD, you’ll need at least:

  1. libjpeg (Note: You’ll need to run sudo mkdir -p /usr/local/man/man1 for manpages.  If you don’t want them, you can ignore the error Make throws.)
  2. libpng (Don’t you love that they still distribute .TXZ’s?)

You can also snag FreeType and libxpm, but it isn’t necessary and building them is beyond the scope of this document.

Okay, so now we’re ready to build PHP. The configure line you supply to PHP is site-specific.  The one I used was:

./configure --prefix=/usr/local --with-openssl=/usr --with-kerberos --with-pcre-regex=/usr/local --without-sqlite --without-sqlite3 --disable-pdo --with-zlib --with-bz2 --enable-exif --with-gd --with-ldap --with-ldap-sasl --with-mcrypt --without-mysql --with-pgsql=/usr/local/pgsql

but I stress again: this is site-specific. You probably want MySQL and don’t want PostgreSQL (even though it takes a lot to squeeze even equal performance out of MySQL).  That said, the only oddity is that on OS X, PHP has a problem locating the OpenSSL lib for itself and I had to use –with-openssl=/usr to allow it to find where it was.

Also, a big disclaimer: GD is still broken with libpng>=1.3.  Since I use 1.4, I was forced to use the SVN version of 5.3.  Not even the new 5.2.13 release has the patch (even though this bug was reported in early January).

Now that we’ve gotten that out of the way, let’s get a server running!

Configuration files

The lighttpd configuration file is up to you.  Note that you have to use server.event-handler = "freebsd-kqueue" on OS X.  Mine is pretty standard, so I’m only going to paste the FastCGI configuration section here:

fastcgi.server = (
".php" => (
"php-osx" => (
"socket" => "/tmp/php5.sock",
"bin-path" => "/usr/local/bin/php-cgi",
"bin-environment" => (
"PHP_FCGI_CHILDREN" => "2"
)
)
)
)

Now, one of the most painful parts of this process was getting a LaunchDaemon configured for lighttpd properly.  Note that when under launchd, lighttpd is very sensitive to syntax; I spent about an hour trying to figure out why it wouldn’t start until I realised I had an extraneous space in the plist.  Here is my /Library/LaunchDaemons/net.lighttpd.plist file:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>net.lighttpd</string>
<key>ProgramArguments</key>
<array>
<string>/usr/local/sbin/lighttpd</string>
<string>-D</string>
<string>-f/usr/local/etc/lighttpd.conf</string>
</array>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>

Now run launchctl as root and type load /Library/LaunchDaemons/net.lighttpd.plist.  If you’ve come this far and you don’t get any errors, congratulations!  Your Mac is now a lighttpd+PHP/FastCGI server!

Advertisements

On taking FreeBSD seriously Tuesday, Nov 3 2009 

Now playing: ♫ Rebel Yell by Billy Idol on Greatest Hits [2001]

I found myself frustrated with Windows 7 at work.  It’s a fairly decent system, and a craptonne better than Vista in both performance and resource usage on the old desktop I have (a Pentium 4/2.66 with a gig of RAM).  But it was still slow, and I had heard that FreeBSD was fast approaching the ‘usable’ state for a desktop role.  So, I decided to take it for a spin.

Firstly, your experience may vary wildly from mine; I spent the entire weekend compiling everything (including the kernel and all of KDE) to my own liking (and optimisation).  And disclaimer: this is on a new ATA-133 drive that actually beats older SATA drives on sustained speed (the very definition of ‘win’).

Installation: I used the ports source-package system (if you’ve used Gentoo Linux, this is where the idea of ebuild came from).  Of course, on a Pentium 4, this took a while; however, I found it to be worthwhile because I was able to enable features I wanted (that nobody else does) and disable features I dislike or had no use for.  This makes binaries that fit my exact needs, and one reason I do love the ports system.

Productivity: I found this department heavily lacking.  I still work in Information Technology as a developer, and apparently KDevelop has gone unmaintained and is no longer part of the kdedev package.  This was upsetting to say the least.  I have yet to install Eclipse, but I have used it on Windows and didn’t care much for the UI.  Overall, I’m back to my old 90s hacker ways of using vim and make instead of the “niceties” of IDE-based programming.  I’m more than capable, but in this day and age of things like test-driven development and the monstrosities of modern Makefile-based systems (unless maybe you’re using CMake), this is unnecessary and something I found highly disappointing.

Office stuff: Office stuff is office stuff.  AbiWord is AbiWord; not quite as featureful as Microsoft Word but it uses a hell of a lot less RAM, and that’s something I can appreciate with this old box.  Of course nothing can compare to iWork Pages ’09 from Apple, and I would be willing to pay extra for a version of iWork for ELF systems, even Linux.

Email: At work we have Exchange 2007.  I have been as-of-yet unsuccessful in getting Evolution to connect to it, and have been using ActiveSync on my PDA to handle emails.  As you can imagine, this isn’t the easiest thing in the world.  I am working on a possible patch (it appears there is a bug in the codebase to do with SSL certificates); hopefully I can get this working soon.

amarok running

amaroK, a multimedia program

Media: This is one place where open-source could really use some work.  Problems I’ve had include amarok showing random last played times such as “August 1991”, mplayer deciding it had a “memory error” and not starting correctly, and attempts at writing numeric tag fields (i.e. year or track #) in media files cause a segfault.  This isn’t to say it’s all bad; amaroK, mplayer, and mpg123 all played the majority of my collection (or at least the formats they supported) quite decently, and the offerings now are fairly solid if not a bit lacking in features.  My wishlist would be for amaroK to have working cover art features and to have clicking the dock icon toggle play/pause.  I guess I have more patches to write.

IM: Pigs is pigs Pidgin is Pidgin.  It works exactly the same as it does on all the other platforms (Pidgin for Windows, Adium for OS X) and it just does it.  I am in the process of researching the best Skype client for FreeBSD, and will probably blog about that later, too.

Web browsing: This is where it gets interesting.  All browsers suck.  I’m telling you, plain and simple, all browsers suck.  So imagine my surprise when jtm, a close friend of mine, points out there is a relatively new one in ports called ‘Midori’, from the XFCE bunch.  I tried it out.  It’s nice, though a bit unstable when using npviewer (Flash / Java), and when you unload a page (i.e. browse to another or close a tab), it has an excessive lag and doesn’t kill the npviewer process.  End result?  A tonne of RAM and CPU spent until you manually kill -9 them.  There are also some favicon bugs.  Overall however, it’s a very decent browser based on my favourite rendering engine (WebKit) and it does get points for effort.  I’m still using Firefox though, because I do find I require Flash periodically.

Other: I’ve found a few little niggles.  One major one is that gtk-qt4-theme sometimes causes textboxes to appear black-on-black (see here).  One place where this is quite evident is the HTML editor in WordPress; it renders a black textarea with black text.  Obviously, I can’t edit HTML easily in WordPress anymore.

One other source of a bit of frustration lies in the fact that there is very little support for FreeBSD compared to Linux simply because it isn’t as widely deployed.  I can accept this and I’m more than capable of doing things, especially with the help of friends and colleagues, but it would be nice to have a lively FreeBSD desktop community (more than just IRC, because they mainly deal with servers).  Some day, ol’ boy, some day…

Anyway, this pretty much sums it up.  My verdict?

It’s not really different from Windows, but it’s free and you have more options.

Windows has buggy apps.  OS X has buggy apps.  FreeBSD has buggy apps.  It’s all really a matter of preference.  Windows is more tweaked for the beginning computer user, and as such has a lot of safeguards built-in.  This is a Good Thing(TM) for new users, but it gets dreadful and annoying to people like me.  OS X has its strong points, but it can be wildly random.  And randomness is one thing all IT people hate — because it’s nigh-on-impossible to pin down exactly where the problem lies.  FreeBSD…what can I say.  It’s grown so much from the days of 5.x when I started to run it on servers.  And overall, though it may not be as user-friendly as Ubuntu, it certainly packs a mean punch, and anyone who isn’t afraid to learn, is able to devote a bit of time to read the FreeBSD Handbook and other interesting manuals, and get their hands a bit “dirty” with computer knowledge should seriously consider using it as a desktop — especially Linux users looking for more.  I’d liken running FreeBSD on a computer to performing maintenance on your car; most people don’t want to do it, but the ones who do save time, money, and have the feeling of a job well done.

Oh, and you may be wondering why I chose “art” for a tag.  Because of my new theme, of course.  I love it; it’s artistic, expresses who I am, and that’s something Windows can’t really say.  Sure you can customise the bugger out of Aero; but no matter what you do, it’s still Aero.