On Firefox’s rapid-release cycle fiasco Wednesday, Jul 13 2011 

Now playing: ♫ Summer Son — Texas

As mentioned in this PC World article, Firefox is on a rapid-release cycle that I personally find alarming.  I just upgraded to 5.0 last week and already 6.0 is in beta, 7 is in Aurora, and 8 is in trunk.  The major issue here isn’t so much the version number jumping, as they could be looked at 5.1, 5.2, etc. just as easily.  The major issue is that this is going to alienate much more than just enterprise users.  However, as someone who works in what some would consider an “enterprise”, I can tell you that my employer’s IT department is not at all happy about having to test all these new versions so often.  We’re often the first to adopt new versions of technology (we even have linux 3.0-rc5 pilot servers); however, a Web browser is often one of the hardest softwares to test, simply because of the amount of corner cases you can find in it.

The focus of Firefox is supposedly on the consumer.  These home users, or as they so eloquently phrase it, “individuals”, do not adapt to change.  This is why there are still people out there running Internet Explorer 6 on Windows 2000.  The especially obnoxious way that Firefox 4.0+ notify you of updates by displaying a large modal window every few hours, combined with the overwhelming amount of large updates coming in the next few months that will disrupt add-ons and change the UI in ways that will likely make more than a few people upset, will leave Firefox alienating a lot of home users.

Additionally, and as I’m not on the Firefox dev team you may take this with a grain of salt, it seems that shoving multiple major releases out the door in a matter of months is as big a mistake with testing and QA as it is with user satisfaction.  You can say that “release early, release often” is a staple of the open-source development model, but I don’t see Linus Torvalds readying the linux-5.0 tag any time soon.  Just because you are open-source does not mean you have to push out major release milestones every month.  No amount of programmers can work that long, and that hard, on that many revisions without there being cracks in the mould somewhere.

I’m not sure which browser is sitting in the best spot to take over Firefox’s share if it indeed does fall from its current place as one of the primary leaders of the Web.  Perhaps IE9 with its (broken but present) HTML5 support, or Safari 5 with its performant JavaScript engine.  All I know is that the browser I depend on for most if not all of my graphical Web browsing is seemingly becoming less dependable.

On running Mac OS X with VirtualBox Sunday, May 2 2010 

I’ve been testing VirtualBox 3.2.0-beta1 out on my Mac mini.  The capabilities of this new beta are quite helpful for system developers and coders in addition to users.  Some of my favourite features include:

  • Real, working APIC 1.4 support.
  • Better SMP support.
  • EFI works much better, but still has really odd bugs.
  • More guests support 2D accel.

Snowflake works well and Windows 7 works better.

But my most favourite new feature, by far, is the ability to install and run Mac OS X.  Apparently both 10.5 and 10.6 work, but my 10.5 DVD is for Mac minis only, so I got 10.6 working.  On a real Mac, it takes nothing but time.  It took over 2 hours to install.  However, it does work, and it works quite well.  Most effects are smooth, even without a native framebuffer kext.  It did take a tiny hack though: I had to boot to the EFI shell and run:

mount fs0:
fs0:\System\Library\CoreServices\boot.efi rd=disk0

Then it Just Worked™. On a real Mac, you don’t need any additional kexts, or anything. It boots natively. Only thing that is missing is the Apple boot logo; it always boots in verbose, again due to no native framebuffer kext.

If you’re unlucky enough to have a genuine not-Apple computer and still want to run Mac OS X in VirtualBox, I highly recommend this helpful guide (which I have even commented on).  It has worked for a few people I know, and I hope to try it on my Core 2 box tomorrow (er, today, it just turned midnight).  I’ll certainly report how that works.  But for now, it’s back to kernel hacking for me.

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!

On getting OpenLDAP and Windows LDAP to interop Friday, Dec 18 2009 

Many Windows developers have a need of some sort to connect to OpenLDAP directory services.  Some use wldap32, others use the DirectoryServices namespace in .NET, others use custom libraries.  Myself, I’m writing an ASPX front-end to our FreeBSD LDAP directory service.

If you are one of the developers in the first two camps, you’ve probably been dumbfounded by one of these error messages:

  • An unexpected operation error occurred
  • A local error occurred
  • TLS negotiation failure

At first, I was inclined to believe this was due to the fact that MS wanted devs to stick with ADAM and not use OpenLDAP.  However, this is not the case.  Each error means something different, and I have workarounds now for all of them that fixes it.

An unexpected operations error occurred

My favourite.  This is due to an OpenLDAP bug that the developers won’t fix.  They have claimed that “Microsoft is the one that is broken by following RFC 2830″…yes, that’s right, an open-source project upset that MS is following an RFC.

Anyway, to fix it you need to apply a one-liner patch (thanks Kirill) to starttls.c, verified to work with OpenLDAP-2.4.19 and CVS HEAD as of this morning (GMT):

=============
--- orig/starttls.c	2004-01-01 21:15:32.000000000 +0200
+++ fixed/starttls.c	2004-05-27 14:14:54.000000000 +0300
@@ -94,6 +94,8 @@
     op->o_conn->c_is_tls = 1;
     op->o_conn->c_needs_tls_accept = 1;

+    rs->sr_rspoid = SLAP_STRDUP(LDAP_EXOP_START_TLS);
+
     rc = LDAP_SUCCESS;

 done:
=============

Recompile OpenLDAP with this change.  Your OpenLDAP is now RFC 2830 compliant and Microsoft APIs (and older Netscape and Novell APIs) can now connect and start TLS with it.

“But wait, Pongo,” you say.  “Now I’m getting a new error!”  Yes, because MS is strange about server certificate processing you will now receive:

A local error occurred (on the LDAP server, “TLS negotiation failure”)

You need the server certificate from the OpenLDAP server (see your slapd.conf file, under TLSCertificateFile.  Mine is in /etc/ssl/keys/ldap).

  1. Copy the file (named chicago-auth.crt in the example) to your Windows computer.
  2. Install the certificate (double-click it) to the Trusted Root Certificate Authorities store.  (I am not sure if this step is required or not.  It was for me for other reasons.)
  3. In your .NET application, add a code block similar to the following:
                lc.SessionOptions.VerifyServerCertificate = Ldap_ServCertCallback;  // Add this line BEFORE StartTLS call
                lc.SessionOptions.StartTransportLayerSecurity(null);

Your Ldap_ServCertCallback function should look something like this:

        private bool Ldap_ServCertCallback(LdapConnection connection, X509Certificate cert)
        {
            X509Certificate realchi = new X509Certificate("chicago-auth.crt");

            if (realchi.GetCertHashString() == cert.GetCertHashString())
                return true;
            else return false;
        }

That’s it. Your .NET application will now happily connect to your OpenLDAP server.

Note that I have not personally tested this workaround with wldap32 (I’m unsure how to set a VerifyServerCertificate callback and I don’t hack the Win32 API anymore anyway), but I have in .NET and it works in both Win32 and ASP.NET applications.