What Outlook 2003 (and 2002 and 2007 versions apparently) likes to do is be super helpful and remove what it regards as extra line breaks. It won’t be consistent either within a single mail or across many but it will make the content difficult to read. What you thought would be new lines will now be joined up in places and it seems to happen more often the further through the content you go.

There don’t seem to be many fixes for this issue but there are a few work arounds to help out.

1. Turn off this “feature” in Outlook in the Tools»Options menu. Honestly I’m not sure what use it is anyway. Unfortunately you’d have to do this on all the recipient’s computers.
2. Use HTML in your email rather than plain text. Depending on your content and need for complete accuracy, perhaps more time than it’s worth.
3. Add twice the number of line breaks where you currently have them. This seems to help but now your email is rather full of white space and may be more difficult to read.

Other than changing email clients, which is pretty unlikely, that’s about it. If you know of other options to try and get Outlook to not remove line breaks, please leave a comment below. This Microsoft KB article explains which versions of Outlook are affected http://support.microsoft.com/kb/287816.

This post will show you how to create two MySQL servers that automatically replicate all their databases using DRBD. With Heartbeat installed on a third machine you’ll have basic fail over protection as well (we’ll do this in another post). Only one of the database servers will be active at any one time.

To follow along exactly, you’ll need the following items set up or readily at hand:

• VMware Server or ESXi, etc to host the virtual machines we use. You could just as easily use physical machines if you have the hardware lying around.
• Ubuntu 9.04 server – other versions or distros should work just as well but you may have to make some changes to the steps as you go through.
• Some basic skills in cmd-line usage of Ubuntu and MySQL.
• Being Ubuntu we’re using a whole heap of sudo prefixed commands here. If you want to drop them out, you can switch to a root session with sudo -s.

Start things off by creating a virtual machine with 512MB RAM and two 2GB disks attached. One disk will be for the OS and one will be used as the data location for MySQL. You can change the RAM or disk sizes as you like but we will be duplicating this machine so don’t use up all your RAM and disk space with the first one.

Install Ubuntu 9.04 server onto this machine and name it node0 (that’s n-o-d-e-zero if the font isn’t clear). Just use one of the disks for the OS and don’t format or prepare the second one yet. You can also leave out the LAMP and other installation packages for now as we’ll grab what we need later.

Once the install is complete, reboot the node0 server, login, run a package update and install MySQL and DRBD with,

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install mysql-server mysql-client drbd8-utils heartbeat

You’ll have to download roughly 45MB of packages for those four items and the extras that come with them.

You now have one server configured with the software we need to do the rest. Depending on your luck, you now have two options for creating the node1 virtual machine.

1. Duplicate the Virtual machine in VMware

To make things easy, we’ll simply copy the node0 machine in VMware to create our node1. Make sure you shutdown the node0 machine in VMware and (assuming your VMware server host is Ubuntu too) open up a cmd prompt and run,

cd /var/lib/vmware/Virtual\ Machines
sudo cp -r node0 node1

Once that’s completed, you should be able to open the node0.vmx file that’s in the new node1 folder using VMware console. VMware will add the ‘new’ virtual machine to it’s inventory and you’ll probably have to rename it as VMware will have kept the same node0 name.

Start up your new node1 machine and watch for VMware to prompt you about the machine ID. You’ll need to say you copied the VM to create a new virtual machine ID in VMware.

Log in to node1 and change the server name in /etc/hostname and /etc/hosts files, so the two servers don’t get confused over their identities. Shutdown node1 for the changes to take effect. While the server is offline, edit it’s VMware configuration to remove the NIC and then re-add it. You need to do this to keep the virtual networking in VMware happy.

Depending on how you network is configured, it may be a good idea to set both servers to have static IP addresses. If you don’t want to do this, make sure you know their IPs and add them to the “other” server’s /etc/hosts file. This will mean that node0 can reach node1 by it’s DNS name and vice versa. Test it’s all working with a ping from each machine to the other.

2. Repeat the Ubuntu Installation

OK, so maybe your virtual machine just didn’t want to be duplicated like mine. If so, just create a new VMware guest config with the same settings as the first and install Ubuntu server the same way.

3. Disk Configuration

Now that we have our two node servers configured and the required apps installed, let’s practice safe-virtualisation by taking a VMware snapshot of both servers. Then if it all blows up in the next few steps, at least we’ll have something to go back to.

Let’s create a new disk partition on that extra virtual hard disk we added to both our machines. On both node0 and node1 use fdisk to add a Linux type 83 partition.

sudo fdisk /dev/sdb

Press p to make sure you have the right disk and there are no current partitions. Press n and create a primary partition with the ID of 1, accept the other default options. Press w to save the changes and exit fdisk.

4. Configure DRBD

We can now configure DRBD to use this empty partition space we’ve created. Like many other Linux apps we need to set up DRBD by editing a config file – /etc/drbd.conf

On node0, make your drbd.conf file look something like the file linked below. There are plenty a massive number of other settings and comments but these are the key ones – assuming you’ve used the same disk names as above and apply your own network addresses. My server IPs were node0:192.168.0.17 and node1:192.168.0.18 so replace those with your information. Take your time to read through at least some of this file as other things like disconnects on failures may come in handy.

drbd.conf

From node0, copy that drbd.conf file to your home directory (~) on node1 using the scp command,

sudo scp /etc/drbd.conf node1:~

You’ll have to accept the RSA key for node1 if you haven’t SSH’d between those servers yet.

And on node1 we need to move that file to the correct place,

sudo mv ~/drbd.conf /etc/

DRBD will now start, but we need to prepare the partition we created earlier so that DRBD can use it. Turn off node1 and on node0 do this,

sudo drbdadm create-md mysql

Restart node0 and log back in again. Typing ‘yes’ to DRBD’s timeout will speed things up. You’ll see some warnings about using the ‘drbd-peer-outdater’ in a mode where something else needs root privileges. Just ignore that for now and we’ll make those changes later.

Run cat /proc/drbd on node0 to have a look at the messages logged when drbd started up. We can see that node0 is in an unknown state as it can’t see what’s happening on node1 properly. So lets sort out node1.

On node1 create the drbd file system just like a couple of minutes ago,

sudo drbdadm create-md mysql

And restart DRBD on node1 to make sure it’s using that new data,

sudo /etc/init.d/drbd restart

Run cat /proc/drbd again to check the status on both node0 and node1 and you should see that they are both connected and set as secondary with an inconsistent status. If you don’t see that then give both nodes a reboot and try again. If you still don’t see that output, start back tracking and check the previous steps.

At this stage both nodes are essentially looking at each other but don’t know who is the primary so they’re not going to do anything. By running the following command on node0 you make that machine the primary and data will start to be replicated straight away.

sudo drbdadm -- --overwrite-data-of-peer primary mysql

You can either use cat /proc/drbd or watch -n1 cat /proc/drbd to view the status of the replication as it happens. This may take some time, even for the relatively small 2GB of empty space we are using, as DRBD will replicate every block in the device /dev/mysql. Between the VMs on an old P4 with a PATA disk I was seeing about 2.8 MB/s.

When you ran that command to set the primary, you probably got some messages about the heartbeat program requiring root privileges to run drbdsetup and drbdmeta. Do that now to get rid of those warnings.

sudo chgrp haclient /sbin/drbdsetup
sudo chmod o-x /sbin/drbdsetup
sudo chmod u+s /sbin/drbdsetup
sudo chgrp haclient /sbin/drbdmeta
sudo chmod o-x /sbin/drbdmeta
sudo chmod u+s /sbin/drbdmeta

Prepare, Mount & Test the DRBD Device

Now although we have our two nodes talking and set as primary and secondary, the disk space is not formatted or mounted for any apps (i.e. MySQL) to use. So we first format our /dev/drbd0 device with ext3 and a nice filesystem label.

sudo mkfs.ext3 -L mysql /dev/drbd0

Then we create the mount point on node0 and mount the new filesystem. Whatever gets dropped into /mnt/mysql will magically be synchronised from the primary node to the secondary.

sudo mkdir /mnt/mysql
sudo mount /dev/drbd0 /mnt/mysql

To test our new setup copy some files and folders into /mnt/mysql and unmount the DRBD device. We then switch the primary node0 to be the secondary and jump onto the node1 server.

sudo cp -r ~ /mnt/mysql
sudo umount /mnt/mysql
sudo drbdadm secondary mysql

Now move to the node1 server and create the same mount point, mount our DRBD device and we’ll see what’s inside.

sudo mkdir /mnt/mysql
sudo mount /dev/drbd0 /mnt/mysql

Like magic you should now see that same data you copied on node0, has appeared in the same device on node1.

Now switch the roles back again so node0 is the primary and node1 is the secondary, and delete the test data in /mnt/mysql.

Configure MySQL

The core settings for MySQL is in a file called /etc/mysql/my.cnf and it’s this file that we are going to edit to tell MySQL to use our DRBD device to store it’s databases, indexes and logs.

At this point it’s very important that you do not have any MySQL databases already running on node0 or node1 – none that you want to keep anyway. Let’s stop the MySQL server and backup our original MySQL settings so we can then make changes on node0.

sudo /etc/init.d/mysql stop
cd /etc/mysql
sudo cp my.cnf myold.cnf

Open up the my.cnf file in your favorite text editor like vi or nano, and change the datadir option as below. If you have logging enabled, or will at some point, you may want to synchronise the log files as well. For more information on other options in this file see the MySQL documentation.

datadir = /mnt/mysql/data

Save my.cnf and make the same changes on node1. We have to repeat this as these files aren’t in out replicating DRBD device.

Run the following commands to set the correct permissions on the new location and also update the AppArmor settings to allow access. This is important else the mysql user and group will not be able to access the new directory properly and you will get errors. Trying to restart the MySQL daemon at the moment will fail.

sudo chown -R mysql:mysql /mnt/mysql
sudo nano /etc/apparmor.d/usr.sbin.mysqld

On the bottom of the list of locations, add the following (within the curly closing bracket } ),

/mnt/mysql/data/ r,
/mnt/mysql/data/** rwk,

Restart AppArmor to pick up the new locations for MySQL,

sudo /etc/init.d/apparmor restart

Make the same changes to AppArmor on node1 – again these changes are server based and not automatically replicated.

We should try and move the previous databases into the new location with the following commands. Repeat the first copy command for any other databases you might have. (That mysql directory we’re copying first is the MySQL system database.)

sudo cp -r /var/lib/mysql/mysql /mnt/mysql/data/
...
sudo chown -R mysql:mysql /mnt/mysql/data/*

The last thing to do is restart MySQL and check it’s working.

sudo /etc/init.d/mysql start

If this gives permission errors about the debian-sys-maint user, check your permissions and/or restart the server. Restarting MySQL might not be enough.

Connect to mysql as the root user and let’s just create a new database and table to test things before we do another manual fail-over to node1.

mysql -u root -p
create database drbdtest;
use drbdtest;
create table users (id INTEGER(9), name VARCHAR(255));
exit;

You can now see your new database files in /mnt/mysql/data/drbdtest. So we fail-over from node0 to node1 again, just for practice. We must stop the mysql server before we unmount the DRBD device else very bad things may happen.

sudo /etc/init.d/mysql stop
sudo umount /mnt/mysql
sudo drbdadm secondary mysql

and over on node1 . . .

sudo drbdadm primary mysql

And check those database files are there with the mysql client or looking in /mnt/mysql/data/drbdtest.

Conclusion

So we can see that this will save us (with some manual intervention), when our MySQL storage falls over. But wouldn’t it be nice if there was an automated way to make this happen? See the next article on using Heartbeat to make this happen.

Potential Issues

If you try and mount /dev/drbd0 and get an error about the device being read-only, check that the DRBD node you’re on is in the correct mode i.e. primary or secondary.

After moving the small amount of static WekaDesign content into Pages, I copied a couple of files (index.php and .htaccess) from my WordPress folder (./blog) into the site root, changed the settings in WordPress (Settings»General»Blog Address) and viola, anyone going to www.wekadesign.co.nz, now hits WordPress. Good. Step one done.

Now to change the default landing page to be a static Page rather than the blog. Just as easy, visit Settings»Reading in WordPress and change the Front Page Displays option to be your Page. Excellent, now everyone lands at the the WordPress version of my static content. But how do you now send people to your old default blog page? You can use http://www.yoursite.co.nz/2009/ to target certain groups of content by date or category if you have Permalinks setup, but I couldn’t find the way that WP builds the default blog page.

It’s not obvious, but that 2nd option in Settings»Reading holds the key. The Posts Page option is asking you to select an existing WP Page that will act as a placeholder and be that default blog page. So, if you haven’t already, create a new Page with a suitable name. The name is important as that’s the URL everyone will use and see for your blog. So if you call the Page “peanut butter”, your blog page will now be http://www.yoursite.co.nz/peanut-butter/. It doesn’t matter what the content of the Page holds as no one will ever see it.

There is a slight “gotcha” with the Page names, in that any name being reused will work, but WP will append it with an incrementing number e.g. “peanut-butter-2″.

To finish off, just create a nice link on your site somewhere like the Sidebar to your default blog page.

MS Exchange Hosted Services would cost US$90k/month for company with 10k email users and selecting roughly half the options available (Communicator and Hosted Archive being two). That sounds really pricey vs local in-house servers and admins? I have no specific Exchange knowledge but say 20 servers across 5 virtual hosts, plus storage and backups is roughly NZ$350-400k as a one-off cost. Plus a team of seven admins to run it @ NZ$80k pa each is a five year cost of around $2.8 million, but lets say $3.2M to round it up to include a few software licenses and some power,cooling and floor space.

Google’s offering that I compared MS against is their Premier Edition of Apps. It’s US$50 per user per year and offers the usual email, calendar, resource booking, etc much like Exchange. I was expecting a few missing features but was surprised to see BlackBerry Enterprise Server (BES) synching and user and group provisioning APIs. It integrates with LDAP and offers Single Sign-On (SSO) so most of your users won’t see too much of a change – especially if they keep on using the Outlook client. The main issue for some businesses may be the 99.9% uptime guarantee – that’s 8h 45m down time per year. I’m sure there are a few features that Exchange holds over Apps but in many situations the cost may outweigh the benefit or it’s just not needed. Using Google Apps also unties you from MS Outlook and possibly MS Office, so this option may open the door to other savings.

So over 5 years for the 10k user company we have the following options:

In-house MS Exchange with 20 VMs, storage and 7 admins = NZ$3.2M

MS Exchange Hosted Services with a mid-tier option seclection @ US$90k/month = NZ$7.4M (at today’s exch rate of 0.72)

Google Apps Premier Edition @ US$50 per user per year = NZ$3.5M

Now one stands out there and not for a particularly good reason. The MS EHS option does include Communicator and Hosted Archiving as an option but I don’t see the extra value over staying with what you have or sending it all to Google. Add to both the off-site options, the project costs of actually implementing this and your own Exchange would have to be in a bad way or have some serious pain to go either way.

What are your thoughts on this one? Are my locally run Exchange costs way off for 10k users and are there any NZ based companies of a similar size (NZ Post’s 2100 users are on the way to Google Apps) that have taken either remote option? Is Google half the service or twice the value of the MS offering?

My last thought would be – just how reliable is that internet connection of yours?

• Page security allows you to dictate exactly who can view and edit your pages. Some people can edit your pages, some can view and everyone else can’t see a thing. Security is as finely grained as you want it to be.
• Kisimi now comes with an upgrade option at installation time and things are a little smarter. Installation can take less than 2 minutes!
• Longer pages with headings can automatically generate a table of contents section.
• Users can specify a timezone so that the dates and times are relevant to their location.
• Administrators can prevent new user sign ups. Handy for those sites publishing their documentation and support pages to the world.
• Any user with an email address listed at www.gravatar.com has their avatar image appear in their preferences.
• Tidier user interface with plenty of little shiny bits.
• Plenty of bug fixes including those messages for PHP configs that show all warnings. It’s still recommnended that PHP is configured without warnings for production servers.

Just head to http://kisimi.wekadesign.co.nz to download the latest version and start managing your online wiki content better.

Things were much better until it came time to install the VMware Tools and nothing happened. Things weren’t exactly snappy and without the tools installed, they weren’t going to get any better. It was time to make the upgrade from VMware 1.06 to 2.0 and as it turns out, is much easier than previous VMware installs.

Overall I followed the instructions from the LinuxGazette website and things worked flawlessly, but there were a couple of extras due to the upgrade.

Firstly (and fairly obviously), make sure you stop your current VMware daemon/service before starting the install. The VMware installer is pretty good, but I’m sure that your virtual machines would appreciate being offline before things get messed up.

sudo /etc/init.d/vmware stop

If you’re upgrading from VMware Server 1.06 the installer will also complain about the vmnet and vmmon modules being left from a previous version. So we need to get rid of those – using the correct kernel version. You can get that with “uname -r”.

sudo rm /lib/modules/2.6.24-22-server/misc/vmnet.o
sudo rm /lib/modules/2.6.24-22-server/misc/vmnet.ko
sudo rm /lib/modules/2.6.24-22-server/misc/vmmon.o
sudo rm /lib/modules/2.6.24-22-server/misc/vmmon.ko

After that it’s plain sailing. Just follow the instructions to untar your VMware download and run the installer. Assuming you used the default locations in the previous install, your virtual machines will be untouched and start happily under VMware Server 2.0

One of the final things to note in the install is that the new client interface is all browser based. To log into your VMware server requires a password and the Ubuntu root user does not have one by default. So on your server be sure to run,

sudo passwd root

and set a nice secure password for when you head to http://servername:8222. Firefox users will need to give the site security certificate the OK and all browsers will need to install the plugin to use the console to view your machines.

Hooray – Windows 7 now installs the VMware Tools properly and runs pretty well. At the moment I have no sound and the limited graphics under VMware don’t allow Aero fanciness, but I can now test and develop in the Windows world while meeting all license requirements. The Windows 7 RC license is valid until June 2010 although don’t wait that long as it’ll start making life hard for you in March 2010. That’s almost a year of free OS from Microsoft!

I found an older post in the Ubuntu forums that had the fix for USB devices and it also works for PS2 with the simplest of changes. So follow these steps and you should be saving power and getting back to work faster.

Open a Terminal and type,

cat /proc/acpi/wakeup

Note the entries that come back and you should see a device called “PS2K” toward the top if you have a PS2 keyboard. For those with USB, it’ll be one of the USB items toward the bottom. The entry will probably also have “Disabled” on the same line, hence your problem.

To enable this entry, switch to a root session by typing,

sudo -s

and enter your password. Now type the following to update the acpi file and toggle “disabled” to “enabled”, (those with USB devices can try USB0, USB1, etc)

echo PS2K > /proc/acpi/wakeup

That should have now enabled your PS2 keyboard to wakeup your PC for this session. Give it a test by putting your machine to sleep and then tapping a key on your keyboard. Probably a good idea to save stuff first, just in case.

If you tried changing a USB device, it may take a few guesses until you find the KB. My mouse was USB0 and clicking any mouse button can also do the wakeup task.

To make this change permanant, you need to add that line to a script and run it when Ubuntu starts. So we create a file called wakeup.sh with the following contents,

#!/bin/bash
echo PS2K > /proc/acpi/wakeup

Save it and from a Terminal make it executable so it runs properly as a script and not just a text file,

chmod +x wakeup.sh

Now to add it to the startup area go back to your Terminal that’s running as root. We need to copy the file to the correct location and add it to the startup processes. You’ll need to run the cp command in the same folder as where you saved your wakeup.sh file.

cp wakeup.sh /etc/init.d/wakeup.sh
update-rc.d wakeup.sh defaults

Now when you reboot, the script will run and enable your PS2 keyboard in ACPI so you can wakeup your PC.

$(document).ready(function() {
    var x = 0;
    $("td.num").each(function() {
        x += parseInt($(this).html());
    })
    $("td#total").html(x);
});

Where your table cells to add up are <td class=’num’> and the table cell that has the total is <td id=’total>.

We use a non-standard print processor at work to insert barcodes on certain output from SAP. So to set all the printers on the print server or just one to use the new print processor, we just run,

setprinter \\myserver 2 pPrintProcessor="SAP Barcode"

setprinter \\myserver\printer01 2 pPrintProcessor="SAP Barcode"

Lots of other properties can also be changed using setprinter.exe, pretty much everything other than security permissions and for that you can use another tool in the RK, subinacl.exe. To view the properties of a queue and what you can change, just cycle through the property groups 0-9 (that’s the 2 in the above commands).

for %i in (0 1 2 3 4 5 6 7 8 9) do setprinter -show \\myserver\printer01 %i