Anyway, I figured I might as well move the entire thing to an open CMS project that I’ve heard some good things about and already implements everything and more that the customer could ever want. That’s CmsMadeSimple.

Converting the old website to the new one was trivially easy. Copy/paste the stylesheet (first mistake), edit the basic template with a menu section, create the pages (copy/paste, copy/paste).
After fixing the html errors that were in the source the page looked like a pixel-perfect copy of the original.
Except for the places where the HTML errors were fixed that is. (the center class now actually worked for instance)

However, when adding the print links I ran into an interesting issue.
Adding print links is also a trivial thing, simply put {print} somewhere in the template, and possibly add some options to show an image instead of a text link etc.
However, the links were kinda broken, they gave empty pages. So I figured “duh, the print template still needs to be fixed”. However, as soon as I added the {content} tag to the template, I got a nice internal server error. WTF.

Checking the logs I could only find nice reports of this:

Well… .I expect nothing less from php. Pleuris-hoere-product. But how the heck… just because I added content to the print page? What’s so special about that?

After digging around (enabling logs etc) and enabling fopen for php (which I had disabled for security), I noticed this:

AHA!. Apparently the printing module fetches the content (or at least, tries to) from the webserver, fails, and then segfaults php. Excellent code guys!
The reason for the failing is obvious from the logs here, I require authentication for the website since this is a test location that shouldn’t be public. Quick fix, allow the server to skip the login (vhost config):

Problem solved. (Hint Printing Module: render your own shit, don’t cheat with fopen/curl)

Oh yeah: CmsMadeSimple rocks for these simple websites where your customer wants to “change some texts and add a picture”. If they can handle word, you can make them handle this (but show them how!).
Give them permissions to add pages and nothing else, write a decent template for them, done.

Anyway, suphp is still nice to have for simple sites that don’t get many hits or don’t need to be very fast. Therefore I wanted to have both options available. Here’s how.
I started out with the Slackware packages for php and apache, but soon found both to be inadequate. Php lacked some modules that some site wanted, and apache didn’t even bring suexec along.
However, the slackware layout is good enough so I altered the slackbuild script a bit and built my own apache. You might need to install some packages as dependencies though. For instance I didn’t have ‘expat’ and ‘db44′ installed.

Now edit the slackbuild file so it compiles with your compile flags. My changes were:
1. Changed VERSION to 2.2.14 (was 2.2.13)
2. Added these to the configure flags (to enable suexec) around line 103:

Compile and install it. Note that the suexec part requires root permissions, so I did this as root.

PHP and suPHP

Note that since php is a pleuris product it will ignore the DESTDIR variable that usually works for creating a package. If you want a nice package for php, consider using the slackware build script instead. (I was too lazy for it this time). Next suPHP:

That went smooth. PHP could learn something from this. Now we still need to configure suphp. To do this we create 2 files and alter httpd.conf a little.
First suphp.conf:

Personally I left most to default, but I did change the log path and the docroot.
Next we need to enable it in apache, but to keep module stuff in their own section we put this in mod_suphp.conf which we include in the httpd.conf.

That should be enough. Now for sites that you want to enable suphp, simply add a few lines to their vhost config like this:

Now you should have a working suPHP installation (provided that you restarted apache etc).
If something fails, check the logs, especially suphp.log and of course the apache error_log.

FastCGI

To get this running I loosely followed this blog post. It pretty much worked like Brandon explained, after I recompiled my apache for suexec support that is. Thus a summary:

Install FastCGI

Now for the magic part, enabling it in a vhost.
First we need a php wrapper script:

Note the -d apc.shm_size=64 option. This specific option is to set the cache size for APC, but this way you can give php custom settings per vhost. Neat huh? If you want to give this vhost its own php.ini you can add this to the script:

PHP will check for a php.ini in that dir. Make sure to check the permissions on these dirs though, especially on the wrapper script. Your users might do stuff you don’t want if you let them alter these things.
Finally to enable FastCGI per vhost, add something to the vhost configuration like this (make sure to disable suphp on that vhost!):

Restart apache and you should see stuff like this in the process list:

APC

Now for some speedup. Let’s see apachebench on that magento vhost without APC and FastCGI:

As you can see it takes more than a second to get the page to load. Well, 0.8s mean across all, but 2.5s per request.
Let’s install APC:

Restart apache and voila. Time for a new benchmark.

W000t…. that’s a lot quicker, almost 4 times as fast. Nice

configure: error: There is something wrong. Please check config.log for more information.

Gee, that’s really…. helpful. OF COURSE THERE’S SOMETHING WRONG, I’M TRYING TO INSTALL PHP!!!!
But let’s not get angry yet, I’m sure it’ll throw more tantrums at us while we try to chunk it together.
In case you’re wondering, I’m trying to configure php so it has curl support. Apparently php’s configure has decided for me that in order to have curl support, it also requires ldap.

“Then don’t configure it with ldap support!”
I didn’t. In fact, I explicity told it NOT to support ldap. –without-ldap. Doesn’t matter. Somehow it picked up the requirement to include ldap in the tests. After some searching I found out that the real source for this problem is the curl-config script:

Note the -lldap there. So basically this is Slackware’s fault. Meh.

Solution 1:
* Get rid of ldap in curl. This involves recompiling curl from source.
Solution 2: Probably the easiest way is to hack curl-config

Solution 3:
* Install the openldap-client package. However, now you have ldap on your system which you probably don’t use on a webserver.

I went for solution 1, recompiling it myself from the slackware sources:

After upgrading the curl package with this build it worked for me without the ldap nonsense.