So I take no credit for this but simply repeat it here so that the search gods may recognise it’s usefulness and +1 it’s importance.

Start by downloading VMware Server 2.0.2 from the official VMware site. If you haven’t already got a few licenses, get one now. (They’re free so you might as well get a few) I’m going to assume the downloaded file is in your home directory.

You also need to update the header files for your current kernel so that the configuration scripts from VMware can build the appropriate modules.

sudo apt-get install linux-headers-`uname -r` build-essential

Now just run the following commands.

cd /usr/local/src
sudo wget [http://codebin.cotescu.com/vmware/vmware-server-2.0.x-kernel-2.6.3x-install.sh]
sudo tar xvzf raducotescu-vmware-server-linux-2.6.3x-kernel-592e882.tar.gz
cd raducotescu-vmware-server-linux-2.6.3x-kernel-592e882/
sudo cp /home/<your_username>/VMware-server-2.0.2-203138.i386.tar.gz .
sudo tar xvzf VMware-server-2.0.2-203138.i386.tar.gz
sudo chmod +x vmware-server-2.0.x-kernel-2.6.3x-install.sh
./vmware-server-2.0.x-kernel-2.6.3x-install.sh

If you have a previous installation of VMware Server, you’ll be prompted that it’ll be removed as part of the install. Don’t worry, any guest VMs you had should still be there afterwards. The script will run through the usual prompts and you’ll see references to the patched files from Radu Cotescu. After a few minutes you should have a working install of VMware Server 2.0.2 on your Ubuntu 10.04 server.

After some searching of my own, it turns out that IIS6 on Windows Server 2003 (possibly XP too) will not properly read the PATH variable. So if you add the path to your PHP directory to the end of PATH, the DLLs required are still not found. This looks to affect IIS6 specifically as filesystem calls to the same DLLs did find them.

The solution – add the path to your PHP install to the start or earlier in the PATH variable and restart IIS. In my experience you will now see the LDAP options appear in your phpinfo() output.

In this post I’ll pass on the methods I found to get PHP and your Linux boxes talking out through a corporate ISA proxy server. You can then bring in RSS feeds, updates and other things in WordPress and use apt-get to update Ubuntu.

cntlm

To start with we need to install cntlm on a Linux box (I’ll mention Ubuntu here but any flavour should work with a couple of tweaks). cntlm is “an NTLM / NTLM Session Response / NTLMv2 authenticating HTTP proxy“. Basically your non-Windows machines and apps can now talk to cntlm which will then talk to the ISA proxy in your organisation. So you stay within your corporate infrastructure and keep the security guys happy.

Download the deb installation package to your Ubuntu machine and install it with,

sudo dpkg -i cntlm_0.35.1-1_i386.deb

Open the config file for cntlm and edit it to add in your ISA proxy information and a valid user, domain and password that has web access with download rights. Further down the settings make sure gateway is enabled and you set suitable restrictions on the IP ranges that can use cntlm.

sudo nano /etc/cntlm.conf

Restart cntlm to make sure it gets the new settings,

sudo /etc/init.d/cntlm restart

Test your cntlm configuration by attempting to get to an external website,

sudo cntlm -M http://www.google.com -u your_user@your_domain -p your_password your_isa_proxy:port

apt-get

Configure apt-get to use the new proxy by editing the apt-get config,

sudo nano /etc/apt/apt.conf.d/70debconf

and add this line pointing to your cntlm proxy gateway. Change the IP and port if you’ve installed cntlm on another machine or different port.

Acquire::http::proxy "http://127.0.0.1:3128";

WordPress

Add these extra lines to the wp-config.php file in your WordPress directory. This works from version 2.8 onward and means you can keep your install and plugins up to date and secure. Again, make sure you change the IP and port to that of your cntlm proxy gateway. You may be able to comment out the username and password if things don’t work as expected. It’ll depend on your cntlm configuration.

define('WP_PROXY_HOST', '127.0.0.1');
define('WP_PROXY_PORT', '3128');
define('WP_PROXY_USERNAME', 'my_user_name');
define('WP_PROXY_PASSWORD', 'my_password');
define('WP_PROXY_BYPASS_HOSTS', 'localhost, www.example.com');

With any luck you now have a Linux machine and WordPress install that can easily be kept up to date inside your corporate environment.

I struck the problem in the Hardy version of Ubuntu Server.

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.