Install LAMP on Ubuntu 8.04


Here is the apt-get command to install a basic lamp environment on ubuntu hardy 8.04 with some “quick start help” commands.


apt-get install apache2 php5-mysql libapache2-mod-php5 mysql-server php5-gd phpmyadmin

This will install apache 2 php 5.2 and mysql server 5 and their dependencies. The deamons are launched at install and basically, only apache2 needs a bit of configuration.To enable ~/public_html user folder (which you reach in a browser with this URL : http://localhost/~username) do :

sudo a2enmod userdir && sudo /etc/init.d/apache2 restart

The default document root is /var/www (you need superuser privileges to write in this directory), but you can add more sites. Edit a new configuration file for the new site :

gksudo gedit /etc/apache2/sites-available/<site_name>

Replace with whatever you want. Add virtual host properties and directives that you need, then save and exit gedit.
To enable this new site do :

sudo a2ensite <site_name> && sudo /etc/init.d/apache2 restart

To manage mysql users and database, simply use phpmyadmin by entering this url in your browser : http://localhost/phpmyadmin

The php config file is located at : /etc/php5/apache2/php.ini and requires a restart of apache if you make any change in it.

vsftpd HTTP lunacy!

Ok, so I was bored and I added very very basic HTTP support to vsftpd. vsftpd is now perhaps the only FTP server to have an option ftp_enable=NO. Basically none of the HTTP protocol is implemented, but it might suffice for someone who is super-paranoid and needs to serve some static files over the HTTP protocol. The selling point is the re-use of vsftpd's tried-and-tested listener, string handling and built-in sandboxing.

The bits live at

I cannot use the name vshttpd, because bizarrely a Google search indicates it as taken: I do not know what the "vs" stands for in that case.

As usual, the feature will live or die depending on the level of user enthusiasm shown.

Posting raw XML cross-domain

I was recently stealing anti-XSRF tokens using the CSS design error I found. In the (unnamed for now) app I was exploiting, all the fun happens in XSRF-protected POST requests with an XML RPC protocol.

If you are, then sending XML to yourself is easy - you can send arbitrary POST payloads using XHR. This of course is not an option from

I'll document how I got around it. I didn't see anything similar with a bunch of Google queries, but I somehow doubt it's new. I'm sure I've missed an easier way, too - let me know. (Note that I set myself the goal of not involving plugins).

When submitting a <form> POST, there are three standard form encodings to choose from:
  • application/x-www-form-urlencoded - "All characters are encoded before sent (this is default)"

  • multipart/form-data - "No characters are encoded. This value is required when you are using forms that have a file upload control"

  • text/plain - "Spaces are converted to "+" symbols, but no special characters are encoded"

The first is clearly unsuitable because it does URL encoding. Critical XML characters such as < > " etc. will get mangled. The second sounds ideal because there is no character encoding... but... of course, multi-part POST bodies have the separator lines such as ------WebKitFormBoundary2eC9p3Z2xdIQfdTS, so are useless to us.

The final option will have to do. The encoding of space is not ideal but we could look into using a whitespace-free subset of XML. There's just one catch. The format of the POST body will be a series of name, value pairs:


The trick to save the day here is to use a single name / value pair and abuse the fact that XML is typically full of = characters. So imagine the following XML:

<element attribute="value">node text</element>

Bold and italic are used to show the name used (<element attribute) and the value ("value">node text</element>) respectively. Job done. We could also bury the = in a node value if we didn't want to use attributes.

But wait. The spec for the text/plain encoding type specifies that any spaces will be converted to + symbols. This will wreck the space between element name and attribute name and perhaps spoil our fun. It's now down to how the browsers behave. Curiously, it breaks down to WebKit browsers vs. non-WebKit browsers:
  • Opera, IE, Firefox: do not URL encode; do not replace space with +

  • Chrome, Safari: do URL encode; do replace space with +

So this trick will work on some browsers but not others. A note on the specifications for this: the most recent document is obviously the HTML5 draft. The relevant section mentions nothing about replacing spaces with + anymore, so either WebKit doesn't support text/plain or it is non-compliant:

Thanks to Michal Zalewski for being around to debate ideas!