So, finally, the day has arrived. I woke up around 3am because of an alert from a client’s server. Services down, so naturally, I responded.
Being the kind of person that doesn’t (rather can’t) just go back to bed, I looked to see what had progressed the past few days with a few things. Lo and behold, I found that php 5.2.1 was released and attempted to update it via the “cpanel” way.
So, by now you’re probably wondering <em>what the fork is a2, and what does it have to do with CPanel?</em>. The answer is quite simple:
Cpanel has fought for quite some time to declare apache 2 as “unstable”, because, well, it is. At least if you take CPanel’s perspective it is. With all the modules loaded into CP, apache, bandwidth and the like, it can be quite tricky to convert everything to an Apache 2 configuration.

As of Cpanel 11, Apache 2 is now the default installation. The apache build script is completely rewritten (or so it would appear), the way it works is quite new, at least as it results to Apache 2.

Seeing that they had declared it the default, I figured I’d give it a go, try to figure out what could about it and to get things working in a stable, production environment. After all, why not , it is after all what individuals expect of me, right? To try to figure out how to make things work? Well, it took about 8 hours, but I do believe I’ve finally got ‘er figured out and ready to roll.

So, what was/is the problem?

Originally, the CPanel build failed to build http at all. Not a real issue, I’ve dealt with that before. It took about an hour to get a stable build of apache2 on one server.
Once CPanel had built apache2, I had to recompile php. With the custom configuration I use (patches/updates/etc), I had to completely rebuild it from the ground up. Of course, this meant rewriting my own build script (soon to be released, more info on that later), but that was due.
Once my own build script got rebuilt (another hour), and php was recompiled, I noticed that ioncube wasn’t loading right. My thoughts were :
WTH, it’s loading fine in the CLI (shell)?
So, now, 2 hours after the rebuild process, I have to try to revert things. This time, not only on ONE server but both, because I had actually thought (foolishly) that the problems were resolved. Silly, silly me!

Well, reverting things didn’t even come CLOSE to going as well as it should have, and, yeah, I should have expected as much (right?). I mean, regression NEVER works as well as you want it to. So, after 2 failed builds, I just kept digging in until the problem was found.

The problem? Apparently Zend Optimizer wasn’t loading. Since the ion loaders are built off of Zend (even standalone), thusly, ion couldn’t load. Not a huge surprise there. So, how did I solve the issue? Well, with a little help from the ion faq, I was able to find out that –enable-versioning needed to be turned OFF. From their website:

This option can prevent the export of global PHP API symbols, causing failure when attempting to link libraries such as the Loader or Zend Optimiser. PHP must be rebuilt without that option so that the PHP API is correctly visible. A phpinfo page should show at the top of the page what options were used to configure PHP, and should confirm that the option had been used.

So, after about 8 hours of solid hair pulling, investigation, and the like, FINALLY I have a working php/apache2 build on both servers. Talk about a frustrating experiment gone wild, and all starting out when I just wanted to update php. FUUUUN!