This post is a bit off-topic, but if you want to host your own copy of WordPress on Zeus Web Server, you may find the following information saves you a bit of time. I decided to share this article this article with you once I’d figured out how to avoid the so-called “white screen of death”, i.e. when pop-ups for link or image insertion into posts show up blank.
Now if you’ve never heard of Zeus Web Server, this article’s not for you. It’s a proprietary web server with a lovely web-based interface. At one point it held the title for being the world’s fastest web server.
I used to work for Zeus Technology some time ago and I still run my production and staging websites on it. I personally think it’s still the cat’s whiskers, but then again I’ve always been hopelessly biased in this regard.
For the record, I’m running WordPress 3.0 on Zeus Web Server v4.3 on Debian Lenny on a Linux 2.6 kernel with PHP v5.3.2. I’m going to assume you’re vaguely familiar with Zeus Web Server and that you have it up and running already.
Step 1 – Upgrade the bundled PHP binary #
If you use the one-click PHP support in Zeus Web Server v4.3, you will need to recompile a new PHP binary as the default one is PHP v4.4.0. Good news is that this is pretty straightforward if you’re happy to compile from source (yes, yes, I know that instantly marks me out as a geek. You got me).
I’ve assumed your copy of Zeus is installed at /usr/local/zeus.
1. Grab PHP v5.3.2 (or whichever’s now available) from www.php.net
2. Compile up PHP, using the following options:
--disable-cli --disable-shared --disable-debug --without-pear --enable-fastcgi --with-zlib-dir=/usr/lib --with-mysql=/usr/lib --with-curl
You may need to install the MySQL, Zlib and Curl development libraries on Debian to allow PHP to compile.
3. Your new PHP binary will be created as php-5.3.2/sapi/cgi/php-cgi
4. Delete the /usr/local/zeus/php/php.fcgi symlink
5. Move, or link, your new php binary to /usr/local/zeus/php/php.fcgi
Righto. When you now create a web site (“virtual server” in Zeusy parlance) with the one-click PHP support, it will now use your new binary. Delightful.
You can check PHP is working properly by creating a test file in your content folder containing simply:
<?php phpinfo(); ?>
If you get the nicely-formatted diagnostics up, all is good.
Step 2 – Install WordPress #
This bit’s nice and easy – awesome job, WordPress.
Make sure you’ve got your copy of MySQL running somewhere, unpack WordPress into a directory and create a PHP-enabled web site to point at it. It’s a good idea to chown the files to the same user and group under which Zeus Web Server is running (nobody:nogroup by default on Debian) to allow the updates, upgrades and uploads to work as intended through the Admin pages.
I’m going to assume you’ve got this bit working.
Step 3 – Clone the WordPress web site #
This bit’s cunning. You can create another Zeus virtual server cloned from the first one. The key difference is that this one’s going to be running on SSL (https). You’ll find out why in a sec. A nice bit about Zeus Web Server is that it’s a one-click process to create a self-signed SSL certificate, so no messing about with OpenSSL and bizarre command-line options.
So you should now have //yourwordpress.site and https://yourwordpress.site pointing at the same content.
Step 4 – Rewrite rules #
This bit needs a bit of explanation. Essentially you want anything that needs to be secure (login forms, admin interface etc.) to be running under SSL, but the rest of the site (content, pics etc.) isn’t sensitive and can be left insecure.
If anyone tries to access something that should be secure via http, redirect them transparently to the https version and vice versa.
This next part is a bit technical, apologies. You need to use rewrite rules to do this. This is the part that sorts out the “white screen of death” problem I mentioned in the preamble.
The WordPress help assumes you’re running Apache and provides example rewrite rules, however Zeus rewrite rules are written differently.
On your http site create rewrite rules like this:
# Start off by matching the URLs that we want to secure match URL into $ with ^/wp-(admin|login|register|includes)(.*) # If we have a different URL, then skip to the end if not matched then goto RULE_1_END # Still here, so let's redirect to the secure site # This grabs the hostname requested - handy if your site has aliases match IN:Host into % with ^(.*)$ # Construct the requested URL as a redirect to the https site set OUT:Location=//%1/wp-$1$2 set RESPONSE=301 set BODY=<a href="//%1/wp-$1$2">click here</a> goto END # This is where we end up if we didn't match at the beginning RULE_1_END:
On your https site create rewrite rules likes this:
# Start off by matching the URLs that we want to secure again # It's important this is the same as the first line on the other site match URL into $ with ^/wp-(admin|login|register|includes)(.*) # This time, we skip to the end if we find one of our secure URLs if matched then goto RULE_1_END # Grab the whole URL match URL into $ with ^(.*)$ if not matched then goto RULE_1_END # Grab the hostname again match IN:Host into % with ^(.*)$ # And construct our redirect to the http site set OUT:Location=//%1$1 set RESPONSE=301 set BODY=<a href="//%1$1">click here</a> goto END RULE_1_END:
It’s important that the first lines are the same otherwise you’ll get redirect loops. Which are bad, m’kay.
If you do all this, then you should end up with a site that does the right thing. Login pages and admin pages encrypted, everything else unencrypted. No white screens of death. Lovely.