Netxus Foundries

Last week our Debian Sarge based server which we use to host our development projects got sick. Summer in Spain is hot and one of the disks went mambo refusing to work.

Luckily enough we had some spare parts to rebuild the system so we decided to install everything from scratch as to have a clean base for the following one or two years. I’m not very good with Unix based systems so I took the easy path and choose the latest version of the only distro I know a bit about: Debian Etch. It’s actually a really nice system.

Until now we were creating an Apache virtual host for each project, with mod_php5 and php4 as cgi. Not an optimal setup since the virtual hosts configuration got quite messed and the custom build PHP versions were difficult to update. I explored several graphical frontends to manage the server like Virtualmin and ISPConfig, while they are nice solutions I found them too feature rich and quite restricting for custom setups. Sure they can be tweaked to fit my needs but if I need to be sincere I prefer to tweak directly the system than a third party package.

I played a bit with Linux VServer to create virtualized environments for each project. Virtualization technologies have exploded in the last years and they offer almost native performance with tighter security and the ability to have some pretty weird setups without messing with the base system. While I found it a very promising alternative we’ll not use it right now since we don’t actually need it for any project.

So I devised one way which suit us quite well. Apache is certainly a great piece of software and has some very nice modules to fit almost all needs. One of them is mod_vhost_alias, which creates virtual hosts dinamically from the used host name and a path. The idea is to have a common base path for all projects (/var/subdomains/projects in our case) and each subdirectory can be used as a name based virtual host. This allows us to have a default configuration for all projects and just when we have a special need we can create a custom virtual host, although most of the changes can be done via an .htaccess file.

Another great module is mod_fcgid which allows to spawn fastcgi compatible servers from Apache. We use it to handle PHP4 and PHP5, moreover we have mod_php5 also setup just in case some project requires it.
The main drawback between running mod_php and php as fastcgi is that we can no longer place php ini directives in htaccess files, however we can use different php.ini files freely. We are using dinamically build php.ini files to customize PHP settings for each project that needs it. With a simple .htaccess directive we can enable XDebug support or enable register_globals for some very old code. Besides deciding which PHP version we want to use for a given project.

Since our main servers are Windows based I joined the Debian box to our AD domain with Samba 3, which procedure has been greatly simplified in Etch.
For the mail handling I’ve installed esmtp which a very simple relay-only MTA compatible with sendmail. It just relays the mails to our Exchange server, so no messing around with postfix/exim/qmail was needed.

The main problem I had with the setup was configuring a backup software. Most linux backup packages make use of soft and hard links, which are incompatible with the Windows CIFS share we use to place the backup files (from where they are collected by Veritas). I finally found Backup Manager which is a really nice backup tool for Linux. It just makes .tar archives supporting full and incremental backups, also supporting online MySQL dumps. Since it just creates tarball files we can safely use our windows share for it.

Finally I’d like to express my gratitude to the people behind all those great open source projects. With Debian Etch it’s actually easier to build a good-performing, relatively secure web server than it’s with a Windows based setup.

Quite so often a web developer starts thinking what’s wrong with the guys who make the rules of how Internet works. And if we dig a bit in the problem, we can many times see that the ‘non-sense’ is there not because the specs were flawed but because the popular implementations didn’t follow completely the spec.

The ‘non-sense’ I’ve been thinking about lately is why the hell we use the ampersand [&] to separate the arguments in a URL. My problem with using the & as separator is that in todays world of XML crazyness, the ampersand must be handled with care.
It seems that the specs said that any character could be used after the initial query char mark [?] but the [#] which marks the start of the fragment. In the current specs for URI/URL syntaxis they recommend the semicolon [;]

So the decision to choose the ampersand as the defacto standard was taken by the guys who took the lead with the CGI scripts and the dynamic web content generation.

Since the specs recommend the use of the semicolon I thought “ok, no problem, I’ll just use it from now on” with a grin in my face. If you are thinking the same keep reading because it’s not that easy. My server-side language of choice right now is PHP, so I build up a simple test script to check out if the semicolon worked ok, but it didn’t.
After consulting php.net for a bit more of information I found the solution, there are two ini directives which define the argument separators, one for input and the other for output (I guess this last one is used to manage the session id without cookies).

arg_separator.input and arg_separator.output are the names of the directives. The first one takes a string as argument and every char in that string becomes an argument separator, the second one defines what will PHP use when building URLs as separator.

The bad news is that the default value is just the ampersand [&]. The good news is that both directives can be defined per directory, so we can put them in our .htaccess in our shared hosts. If you control the host just edit the php.ini file. Logically we can’t modify them with ini_set() because the URI is already processed when our script starts execution (see below for a solution to this).

php_value arg_separator.input "&;"
php_value arg_separator.output ";"

Note that I left both: the ampersand [&] and the semicolor [;] as valid argument separators, I’m far too used to the ampersand and I don’t want to expend my whole life debugging an application just because I forgot that I decided that the semicolon was a better suit :)

Even if we can’t use the ini_set() function to modify the PHP behaviour for this, we can still make use of a different argument separator by processing the $_GET and $_REQUEST arrays and splitting them by our preffererd argument separator. The following code snippet show do it but please don’t use it in production environments, it’s probably flawed!

Changing the argument separator does not only help out when working with XML based technologies but also to give your site URLs a geeky look ;)