A client wants me to migrate a reasonably large hosting platform. Therefore, I am writing a little database and set of bash scripts in order to mitigate the hosting platform. The first thing that was incredibly apparent is that I wasn’t given much info on the existing state of affairs. This is because there was no info on the state of affairs.

Ultimately I can’t migrate what I don’t know about so first up, audit time!

The tools I have written have proved very popular and useful with management. In fact, they are so happy that they are going to form an ongoing part of the monitoring and management of the new environment too.  Those same tools are available to download from this blog.

Though I must mention that they are providing it without warranty or certification. They may or may not be fit for purpose, they may or may not cause you problems. What I am trying to say is use at your own risk etc.  As far as I am concerned, I am giving you ideas, not directly providing you tools.

So, the environment is in truth a bit odd. The old stuff is kinda all over the place – the details of which are not important.  It’s mostly VPS’s and these live on the OpenVZ hypervisor. Which isn’t really a hypervisor but that is a discussion for another time.  These VZ Hosts are on physical bits of kit across lots of racks and various SANs etc.

To make these scripts work, you need a linux box that can handle bash scripting with MySQL and Apache installed.  You will also need an SSH key pair (I recommend at least 4096 bit key lengths). Also a list of the primary IP addresses for the host boxes you want to audit.

In the download there is a copy of my MySQL schema and the four bash scripts I have written so far, which are:

1. vzmanagement.sh – this is the main script that pulls all the data and inserts it into the database, it’s the biggest script out of the lot and I dare say in places there is likely more efficient ways of doing things.  If you have a data centre that is bigger than mine and you find you need the extra efficiencies feel free to modify!
2. vzcpubalance.sh – this script was born when I realised I needed a quick way of changing the seemingly randomly allocated CPU bean counters across all the boxes all at once.
3. vznewkey.sh – this script simply takes the primary IP address of the VZ Host you are connecting to and initiates a new SSH Key Pair.  As you will see from the script I am a little paranoid about my encryption so by default it uses 8192 bit key lengths.
4. vzkeyrefresh.sh – this script collects the stored public SSH keys from the MySQL database. Creates an “authorized_keys” file and then sequentially logs into each active server and installs it thus meaning that all servers in your farm have all the other active servers public SSH keys and all the active staff’s public SSH keys. For those who have used it before, vzmigrate (the built in migration tool) heavily uses SSH to do its job and as a result key management can get troublesome, particularly if your doing a migration!  I will warn you – whilst this tool is very thoroughly tested in my environment, it may or may not work in yours.  If it doesn’t work properly – you may lock out of your own environment.  TEST IT FIRST!

To set this up, all you need to do is import the

• MySQL schema
• Populate the host name and the Primary IP addresses in the VZHosts table,
• Make sure your public key is on all the servers you are going to connect to
• Make sure that the variables at the top of each of the script files are appropriately set to your environment. (i.e. usernames and passwords) and then run ./vzmanagement.sh

Download is here

Remember – no warranties or support!