Installing ClusterControl with an existing cluster and Nginx

ClusterControl is a comprehensive tool for managing and monitoring MySQL and MongoDb clusters, more information can be found here: http://www.severalnines.com/clustercontrol

ClusterControl comes with some great scripts for automating deployment, however there are a number of hard coded dependencies (like Apache) which make it a rather more painful process to integrate with your existing systems.

Background info:

There are 3 components that make up ClusterControl:

ClusterControl UI: A CakePHP based GUI
CMON: A daemon process which monitors servers and writes to a MySQL database
CMON API: A PHP based API which reads data from the CMON database

ClusterControl UI and CMON API can be on the same or different hosts and the UI can talk to multiple instances of the CMON API (hence multiple CMON daemons).

The UI also makes AJAX calls to the API via a script in the path /access which simply sends the same request to the API with the addition of the API token.

There are several .htaccess files that rewrite requests to the UI, the access script and the API.

Installation process:

CMON can be installed by following this guide: http://support.severalnines.com/entries/20613923-installation-on-an-existing-cluster

The guide contains a section at the end to install the UI/API, this does install and configure Apache, but you can simply remove it again.

Making it work with Nginx:

After a bit of tinkering I’ve put together a config which works nicely for both the ClusterControl UI and CMON API:

server {
        listen 1.2.3.4:80;
        server_name mydomain.com;

        access_log /var/log/nginx/mydomain.com-access.log;
        error_log /var/log/nginx/mydomain.com-error.log;

        root /var/www;
        index index.php;

        location ~ \.htaccess {
                deny all;
        }

        location ~ \.php$ {
                fastcgi_pass 127.0.0.1:9000;
                fastcgi_index index.php;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                include /etc/nginx/fastcgi_params;
        }

        # Handle requests to /clustercontrol
        location /clustercontrol {
                alias /var/www/clustercontrol/app/webroot;
                try_files $uri $uri/ /clustercontrol/app/webroot/index.php;
        }

        # Equivalent of $is_args but adds an & character
        set $is_args_amp "";
        if ($is_args != "") {
                set $is_args_amp "&";
        }

        # Handle requests to /clustercontrol/accesss
        location ~ "^/clustercontrol/access/(.*)$" {
                try_files $uri $uri/ /clustercontrol/app/webroot/access/index.php?url=$1$is_args_amp$args;
        }

        # Handle requests to /cmonapi
        location ~ "^/cmonapi/(.*)$" {
                try_files $uri $uri/ /cmonapi/index.php?url=$1$is_args_amp$args;
        }

}

Making the UI work is straight forward, however the access script and API require the partial URL and the equivalent of the mod_rewrite [QSA] flag as the ? in the try_files directives stops Nginx from auto-appending the query string from the request, hence the need for the regex and appended args.

A small code change is also required to the library used by the access script which is located in /clustercontrol/app/Lib/Access.php as the API token header uses an underscore rather than a dash which results in Nginx ignoring it (which I think is correct behaviour, probably an RFC floating around somewhere which will clarify this).

Replace both instances of:

$headers[0] = "CMON_TOKEN: {$token}";

With:

$headers[0] = "CMON-TOKEN: {$token}";

Everything should now work!

Share

Another problem with VMware Tools solved

The issues with 3.8+ kernel that I posted about previously have been resolved in newer versions of VMware Tools, but unfortunately the latest version 9.6.1 (bundled with Fusion 6.0.2) brings along more problems with the file sync driver. The issue causes deletions within files to be reflected in the guess OS as truncation at the end of the file.

There is a very simple solution to this, it’s reasonably well documented on the VMware forums and the developer has also responded informing us that a fix is in progress, however I thought it would be useful to collate all the information into a single post.

The fix is simply to downgrade the tools back to 9.6.0, however I’ve noticed that a lot of people have had issue with this as the default behaviour is to auto upgrade, putting your right back to version 9.6.1.

Firstly you need to edit the vmx file of your VM (In some versions of VMware I think you can change this in the GUI, but I couldn’t find this option in Fusion), I would suggest shutting it down completely before doing this. In the terminal you can navigate into the VM folder and use a text editor to do this. Look for the setting “tools.upgrade.policy” which seems to default to “upgradeAtPowerCycle” and ensure this is set to “manual”, the save any change if necessary.

Finally, download the relevant tools package from https://softwareupdate.vmware.com/cds/vmw-desktop/fusion/6.0.1/1331545/packages/, untar/unzip it several times and perform the standard tools installation process (below example is for Linux guests):

wget https://softwareupdate.vmware.com/cds/vmw-desktop/fusion/6.0.1/1331545/packages/com.vmware.fusion.tools.linux.zip.tar
tar -xf com.vmware.fusion.tools.linux.zip.tar
unzip com.vmware.fusion.tools.linux.zip
sudo mkdir /mnt/iso
sudo mount -o loop payload/linux.iso /mnt/iso
cp /mnt/iso/VMwareTools-9.6.0-1294478.tar.gz .
tar xzf VMwareTools-9.6.0-1294478.tar.gz
cd vmware-tools-distrib/
sudo ./vmware-install.pl
Share

Patching VMware Tools to fix multiple installation errors on Ubuntu 13.04

Ubuntu 13.04 has the 3.8.0 kernel which has a few changes that VMware have not got round to fixing in the tools package yet. These patches were written for VMware Workstation 9, but I used them successfully with VMware Fusion 5, so there is little or no difference between the tools package for either product. I also did not write these patches myself but I’m writing this post to consolidate fixes for multiple separate issues when attempting to install tools on an Ubuntu 13.04 guest.

Issue 1 – Cannot find kernel headers

This is something to do with the location of version.h changing in the newer kernel and can be fixed with a simple simlink:

sudo ln -s /usr/src/linux-headers-$(uname -r)/include/generated/uapi/linux/version.h /usr/src/linux-headers-$(uname -r)/include/linux/version.h

Issue 2 – Build of vmci fails

The following errors will be encountered in vmware-config-tools.pl:

Using 2.6.x kernel build system.
make: Entering directory `/tmp/modconfig-9TKqy8/vmci-only'
/usr/bin/make -C /lib/modules/3.8.0-21-generic/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. \
      MODULEBUILDDIR= modules
make[1]: Entering directory `/usr/src/linux-headers-3.8.0-21-generic'
  CC [M]  /tmp/modconfig-9TKqy8/vmci-only/linux/driver.o
/tmp/modconfig-9TKqy8/vmci-only/linux/driver.c:127:4: error: implicit declaration of function ‘__devexit_p’ [-Werror=implicit-function-declaration]
/tmp/modconfig-9TKqy8/vmci-only/linux/driver.c:127:4: error: initialiser element is not constant
/tmp/modconfig-9TKqy8/vmci-only/linux/driver.c:127:4: error: (near initialisation for ‘vmci_driver.remove’)
/tmp/modconfig-9TKqy8/vmci-only/linux/driver.c:1754:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘vmci_probe_device’
/tmp/modconfig-9TKqy8/vmci-only/linux/driver.c:1982:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘vmci_remove_device’
/tmp/modconfig-9TKqy8/vmci-only/linux/driver.c:119:12: warning: ‘vmci_probe_device’ used but never defined [enabled by default]
/tmp/modconfig-9TKqy8/vmci-only/linux/driver.c:121:13: warning: ‘vmci_remove_device’ used but never defined [enabled by default]
/tmp/modconfig-9TKqy8/vmci-only/linux/driver.c:2063:1: warning: ‘vmci_interrupt’ defined but not used [-Wunused-function]
/tmp/modconfig-9TKqy8/vmci-only/linux/driver.c:2137:1: warning: ‘vmci_interrupt_bm’ defined but not used [-Wunused-function]
/tmp/modconfig-9TKqy8/vmci-only/linux/driver.c:1717:1: warning: ‘vmci_enable_msix’ defined but not used [-Wunused-function]
cc1: some warnings being treated as errors
make[2]: *** [/tmp/modconfig-9TKqy8/vmci-only/linux/driver.o] Error 1
make[1]: *** [_module_/tmp/modconfig-9TKqy8/vmci-only] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-3.8.0-21-generic'
make: *** [vmci.ko] Error 2
make: Leaving directory `/tmp/modconfig-9TKqy8/vmci-only'

The communication service is used in addition to the standard communication
between the guest and the host.  The rest of the software provided by VMware
Tools is designed to work independently of this feature.
If you wish to have the VMCI feature, you can install the driver by running
vmware-config-tools.pl again after making sure that gcc, binutils, make and the
kernel sources for your running kernel are installed on your machine. These
packages are available on your distribution's installation CD.
[ Press Enter key to continue ]

The solution to this issue involves patching driver.c to work with the 3.8 kernel:

cd ~
wget http://cdn.philbayfield.com/downloads/vmware-vmci.patch
cd /usr/lib/vmware-tools/modules/source/
sudo tar xf vmci.tar
cd vmci-only/
sudo patch -p1 < ~/vmware-vmci.patch
cd ..
sudo tar cf vmci.tar vmci-only

Issue 3 – Build of vmhgfs fails

The following errors will be encountered in vmware-config-tools.pl:

Using 2.6.x kernel build system.
make: Entering directory `/tmp/modconfig-LxeJ83/vmhgfs-only'
/usr/bin/make -C /lib/modules/3.8.0-21-generic/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. \
      MODULEBUILDDIR= modules
make[1]: Entering directory `/usr/src/linux-headers-3.8.0-21-generic'
  CC [M]  /tmp/modconfig-LxeJ83/vmhgfs-only/backdoor.o
  CC [M]  /tmp/modconfig-LxeJ83/vmhgfs-only/backdoorGcc64.o
  CC [M]  /tmp/modconfig-LxeJ83/vmhgfs-only/bdhandler.o
  CC [M]  /tmp/modconfig-LxeJ83/vmhgfs-only/cpName.o
  CC [M]  /tmp/modconfig-LxeJ83/vmhgfs-only/cpNameLinux.o
  CC [M]  /tmp/modconfig-LxeJ83/vmhgfs-only/cpNameLite.o
  CC [M]  /tmp/modconfig-LxeJ83/vmhgfs-only/dentry.o
  CC [M]  /tmp/modconfig-LxeJ83/vmhgfs-only/dir.o
  CC [M]  /tmp/modconfig-LxeJ83/vmhgfs-only/file.o
  CC [M]  /tmp/modconfig-LxeJ83/vmhgfs-only/filesystem.o
  CC [M]  /tmp/modconfig-LxeJ83/vmhgfs-only/fsutil.o
  CC [M]  /tmp/modconfig-LxeJ83/vmhgfs-only/hgfsBd.o
  CC [M]  /tmp/modconfig-LxeJ83/vmhgfs-only/hgfsEscape.o
  CC [M]  /tmp/modconfig-LxeJ83/vmhgfs-only/hgfsUtil.o
  CC [M]  /tmp/modconfig-LxeJ83/vmhgfs-only/inode.o
/tmp/modconfig-LxeJ83/vmhgfs-only/inode.c: In function ‘HgfsTruncatePages’:
/tmp/modconfig-LxeJ83/vmhgfs-only/inode.c:888:4: error: implicit declaration of function ‘vmtruncate’ [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[2]: *** [/tmp/modconfig-LxeJ83/vmhgfs-only/inode.o] Error 1
make[1]: *** [_module_/tmp/modconfig-LxeJ83/vmhgfs-only] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-3.8.0-21-generic'
make: *** [vmhgfs.ko] Error 2
make: Leaving directory `/tmp/modconfig-LxeJ83/vmhgfs-only'

The filesystem driver (vmhgfs module) is used only for the shared folder
feature. The rest of the software provided by VMware Tools is designed to work
independently of this feature.

If you wish to have the shared folders feature, you can install the driver by
running vmware-config-tools.pl again after making sure that gcc, binutils, make
and the kernel sources for your running kernel are installed on your machine.
These packages are available on your distribution's installation CD.
[ Press Enter key to continue ]

The solution to this issue involves patching compat_mm.h to work with the 3.8 kernel:

cd ~
wget http://cdn.philbayfield.com/downloads/vmware-vmhgfs.patch
cd /usr/lib/vmware-tools/modules/source/
sudo tar xf vmhgfs.tar
cd vmhgfs-only/shared/
sudo patch -p1 < ~/vmware-vmhgfs.patch
cd ../..
sudo tar cf vmhgfs.tar vmhgfs-only

Finally, after adding any (or all) of these patches, just run vmware-config-tools.pl again and all should complete without issue.

Share

PC Rebuild – Part 2

All the parts have finally arrived, including one or two things I forgot about. I had to order a few extra connectors as the 1/2″ ID tubing was slightly less easy to route as I expected (coming from 3/8″ ID tubing currently). Also worth mentioning that neither Aqua Computer’s D5 pumps or XSPC’s twin D5 dual bay reservoir include O-rings for the pumps (they are usually included with pump tops though by the looks of things) so they had to be ordered separately but are easy enough to find.

A small amount of initial assembly is required. Firstly, mounting the fans to the radiator:

Then the pumps to the reservoir:

Finally the Aquaero block:

Fitting the Aquaero block is a little more complicated. You have to remove the circuit board, take the screws out holding the heat sink in place, add new thermal pads and then attach the block with the different screws provided. As the block is quite small it’s also a bit of a pain to attach the compression fittings, I used a 10mm extender on the left and a 45 degree angled fitting on the right to give clearance from the block.

I’ve got a fried ASUS P9X79 board that I’ve not got round to getting an RMA for yet which is a handy way to mount the CPU block in the right place. This case is so big that the full ATX board looks tiny:

This is a full height radiator plus fans and there is still room above the board to see the cable management, a huge improvement over my current case.

Finally it’s time to put everything in and add the tubing. At this point after I’ve fiddled around getting everything in and my hands start to get sore from tightening up the compression fittings, removing bits and adding them again to make things easier, I get a bit slack with the pictures and just want to get things finished!

Here are a few during and after photos:

Fill with distilled water and away we go!

At the time of writing I’ve had the system running for about 48 hours, I only ordered 1 litre of coolant and it took 1.5 litres to fill it with distilled water. I’m waiting on a new order of Mayhems Aurora fluid which will arrive on Tuesday!

Share

PC Rebuild – Part 1

Lately I’ve been trying to reduce noise in my desktop PC, but the knock on effect of this has been at the expense of cooling performance. I’m also bored of the case (which looks pretty grubby now) and the system colours as well as being fed up with the mess of cables inside (no cable management back then). As the case and complete water loop are in their 6th year of use the’ve had a good run and it’s time for a change.

Initially I’ve decided against pulling my brand new GTX 670 card apart to add a water block to it, it also runs very quietly anyway. For now I’ll cool the CPU and Aquaero fan controller with water, with a nice big rad that can support a GPU later and run fans at lower RPM and noise. I’m sticking with BitFenix fans because they look great and don’t make too much noise and a bay res with integrated pump to save space.

Parts list
Corsair 800D full tower case

Cooling components

XSPC RX360 radiator

XSPC twin D5 dual bay reservoir

Aqua Computer D5 pumps with USB/Aquabus

EK Supremacy CPU block

Aquaero 5 block

Aqua Computer inline temperature sensors

1/2″ ID compression fittings and various other G1/4″ fittings

Mayhem X1 red fluid

Share

Gobi 2000 WWAN (VAIO S, etc) on Fedora

There are a lot of long explanations on how to make this mobile broadband model work correctly with Linux, most of which are Ubuntu based, but it’s actually really simple.

The modem is recognised but the key is that it requires the firmware to be loaded after every cold boot.

$ lsusb
Bus 001 Device 007: ID 05c6:9224 Qualcomm, Inc. Sony Gobi 2000 Wireless Modem

Simply download and install gobi_loader either from http://www.codon.org.uk/~mjg59/gobi_loader/download/ or clone the git repository from git://cavan.codon.org.uk/gobi_loader.git

make
sudo make install

Copy the firmware files from a Windows install (or Wine) to /lib/firmware/gobi

# cp /media/0646579646578579/Program\ Files\ \(x86\)/QUALCOMM/Images/Sony/UMTS/* /lib/firmware/gobi/

Reboot! Mobile broadband will now be available from the Gnome networking menu.

Share

A shaky start for Ubuntu 10.04 Desktop

Whereas I have been running Lucid since beta1 on my laptop without too many issues, my desktop PC doesn’t get upgraded until release day.

After eventually managing to download the ISO, loading 5 different email backups to find my Nero key and waiting half an hour for the Lightscribe to burn onto the CD I finally got to boot the live CD….

Flashing cursor…
Power saver mode…
[2 minutes go by]
Screen powers on…
Strange Windows 7 blockiness (presumably something left in the video memory)…
[Another minute goes by]
Desktop, finally.

Install goes smoothly, nice to see the migration wizard is disabled by default and has clear options, should you choose to use it.

Try to reboot and machine hangs with just the desktop background.

Reset, restart…
The infamous flashing cursor…
Login screen…

I attempt to login and get a popup about power saving not working do I still want to logout? Odd… No I want to login really 🙂

Click continue, it goes away, finally get to the desktop.

One thing is immediately clear, Plymouth = EPIC FAIL.
So far it doesn’t work on Intel or Nvidia hardware, 2 of the 3 post popular video chip manufacturers!
I guess this is what happens when you name something after a scummy little city hidden away in the south west of England…

Testing continues…

Share