However, we can install MySQL 5.5 from the generic tarball and make a few “tweaks” to maintain the default Ubuntu structures and settings.

There are more straight forward ways to install MySQL, however the intention of this guide is to allow us to easily upgrade via multiple future available routes with minimal effort (e.g. via deb packages, or in their absence newer generic tar distributions).

1. Create user/group

Note: I manually chose system group ids looking at the latest system group id in /etc/passwd and /etc/group

2. Create folders

3. Set a few folder permissions

4. Download the source and copy/move it to the default install folder in /usr/local. (This is not standard Ubuntu, however due to some of the compilation options on the tar package it avoids a few issues but maintains Ubuntu paths.)

5. Move files to the Ubuntu locations and create simlinks “just in case” MySQL has something hard coded into the build that cannot be changed via the config.

6. Create the default data files and move them to /var/lib/mysql

7. Copy the init script over to /etc/init.d and modify to suit our needs

Edit with your favorite text editor and ensure the following are set:

8. Add my.cnf, the default 5.1 file will do, with 1 or 2 modifications. Specifically, check the basedir and datadir are set correctly, ensure Innodb is the default storage engine (as per 5.5) and note the new syntax for slow query logging (disabled by default). It would be advisable to set common Innodb options, e.g. pool size.

9. Start the server!

If the server fails to start, check /var/log/mysql/error.log for clues.

Test system:

Hardware: vps247 cloud VPS node, 512Mb ram.
Software: Ubuntu 10.10 RC (kernel 2.6.35-22), Apache 2.2.16 (mod_php), Nginx 0.7.67 (php-fpm), Lighttpd 1.4.26 (php-cgi), PHP 5.3.3 with Xcache.
Site: LiteMVC 0.1 Hello World.

Test process:

Using ab with 10,000 requests, 10 concurrent requests.
Monitoring load/memory usage with htop.
All web servers with default configuration, 1 site enabled.
All tests were repeated 3 times.

Apache 2.2.16:

Nginx 0.7.67:

Lighttpd 1.4.26:

Conclusions:

Lighttpd was the fastest overall in this test, however what probably stands out the most is the inefficiency of Apache with both server load and memory usage increasing considerably during the test. The reason for this may be down to Apache spawning additional processes when it is receiving a large volume of requests, which results in the higher memory usage. The memory usage with Nginx and Lighttpd increases by a much smaller amount because each of them runs a fixed number of PHP CGI processes (20 in this case).

Apache is definitely the winner in terms of module support and ease of configuration, but I may have a somewhat biased view as I’ve worked with Apache for years. Nginx is probably the hardest to setup and configure, however after switching from PHP-CGI to PHP-FPM this made things easier and it does seam there are more configuration examples floating around on the net than for Lighttpd. Lighttpd is notorious for memory leaks, I’m not sure if this is still an issue with current versions.

For some reason, best known to the PHP developers, 32 bit PHP is limited to the maximum signed 32 bit integer size of 2147483647, while 64 bit PHP uses the 64 bit equivalent of 9223372036854775807. Many languages overcome the 32 bit / 64 bit differences by storing 64 bit ints as 2 32 bit ints to allow the usage of 64 bit integers on 32 bit systems, hence providing complete consistency between the two platforms.

These inconsistencies similarly apply to floating point precession, presumably a float in 32 bit PHP is equivalent to a 32 bit float in C, whereas it appears that in 64 bit PHP it’s actually a double.

Here is a nice example of the inconsistency, today’s unix timestamp in float form:

32 bit:

64 bit:

This is an important thing to remember with PHP, despite the fact it is a loosely typed language, they behaviour is equivalent to the C behaviour for the particular architecture of your server.

Looking in the /var/log/mail.log will reveal it is trying to determine the fully qualified domain name:

Here is a quick fix which resolves the problem:

1. Edit /etc/hosts
2. Change the record for 127.0.0.1 so that it looks something like this

3. Restart sendmail

This now makes sendmail think it’s FQDN is localhost.localdomain, and mail now sends instantly!

To enable SSL replication both the client and server require signed certificates, these could be a purchased certificate from a common CA but really as they are only going to be used for private communication there is no need and a self signed certificate will do the job.

Please note, that for the section of this post which discusses the MySQL replication, I am assuming that you already know how to setup replication, including ensuring data is consistent on master/slave. The focus of his article is to document the additional configuration required to setup replication with SSL.

For the purpose of this example I will be configuring the following hosts:

Creating the certificates:

The first thing to do is to create a certificate authority in order to sign the certificates, this is based on the Ubuntu Documentation with a few changes.

First, create some directories to organise things and change into the new CA directory:

Create a certificate database:

Create a configuration for the CA:

You will need to change the user in red with your Linux username and the CA info in green.

Now generate the CA certificate with the following:

You will be prompted for a passphrase:

We now have a certificate and key which we can use to sign the certificates. The next stage is to create certificates for each of our 2 hosts (or more, if more than 2 hosts are being configured in the replication setup).

Create a config file for each host:

Change the bits in green to your company name, the commonName must be the host name of the machine, this is important or the certificate will be invalid.

The next step is to create a certificate signing request (CSR) and private key for each of our hosts:

You will be prompted for a passphrase again:

Repeat for slave (and additional hosts):

Now in their current form the keys we have just generated will require the passphrase every time we start the server, this is far from ideal as MySQL will have to be manually started every time the server is rebooted (intentionally or not).

We can create an unencrypted version of the keys so that the passphrase is not required for server starts:

Finally, we can sign the certificate requests for each host with our CA:

Configuring the servers:

We will need to copy 3 files to each machine:

ca.pem – The CA certificate

On the master:

master.crt.pem – The master certificate
master.key.pem or master.dckey.pem – Either the encrypted or decrypted version of the master private key

On the slave:

slave.crt.pem – The slave certificate
slave.key.pem or slave.dckey.pem – Either the encrypted or decrypted version of the slave private key

These files should be copied into /etc/mysql on the respective hosts.

On the master, create a user for replication:

Note that the addition of the ‘REQUIRE SSL’ at the end of the grant statement, this means insecure connections from the slave will not be possible.

Create the configuration on the master for replication:

Also we need to add the SSL configuration:

Restart MySQL to apply the configuration:

or (in newer versions with upstart):

Then configure the slave for replication:

Restart MySQL, and everything should be up and running.

From the master we should see something like this:

And on the slave:

Note: The status info above I copy/pasted from a live replication setup and replaced with values that you can expect to see, values will likely differ (especially log file positions).

The easiest way to install MariaDB is to add one of the repositories, I’ve used OurDelta:

Then install MariaDB:

This should install MariaDB without any problems, it should also replace MySQL if you already installed it:

If you are upgrading from MySQL, you will probably be prompted to overwrite the my.cnf and for a new root password. I generally choose Y to overwrite and enter my existing root password to avoid issue.

You can also follow my previous post to upgrade the client library used by PHP, rather than installing the MySQL dev package, the Maria equivalent should be used:

Install the source package:

or

Install the MySQL client dev package:

Install autoconf:

From this point onwards I ran as root as saves time having to sudo everything, I have also created symlinks for the binaries in /usr/local/zend/bin to /usr/local (php, phpize, php-config, pear, pecl etc)

Change to the extensions directory of the source you just installed:

There are 3 extensions that need to be recompiled mysql, mysqli and pdo_mysql, the following procedure is the same for all 3:

Finally restart Zend Server and all the MySQL extensions will be using the latest libraries.

Along with the rather unsatisfactory resolution:

The reason for this error is that the Zend MySQL packages are built against MySQL 5.0 (despite the fact 5.1 has been GA for over a year now).

Ubuntu have removed MySQL 5.0 in Lucid, but the package from Karmic is usable and available here: http://ns2.canonical.com/pt/karmic/libmysqlclient15off

Simply install this and Zend Server will install nicely.

The last upgrade from Jaunty to Karmic was a rather traumatic process, but thankfully this time round all went smoothly. Not really any overly noticeable changes this time round other than a few more things have moved into upstart (MySQL for example) and when I boot via KVM the new Plymouth boot screen is present, although not sure why this is even included in a server release.

It’s about as updated a LAMP setup as is possible including Apache 2.2.14, MySQL 5.1.41 and especially pleased they put in PHP 5.3.2 after the code freeze. On this server I’m actually running Zend Server CE (which already had PHP 5.3.2) as Zend are quicker to push out the updates, but on others I will stick with the default Ubuntu release.

What else can be said about a server OS? Well, it just works

It appears from a package search that 2 days ago PHP 5.3.1 packages were added to Lucid. It’s quite a big step, and will be interesting if they also include a 5.2.x release along side it as so many applications are not ready for 5.3 yet.

More information can be found on Launchpad:

https://launchpad.net/ubuntu/+source/...