Tuesday, June 28, 2011

Automated conversion of MS-Access database to Postgres

Thanks to mdbtools it is now a little bit easier to migrate MS-Access databases to a newtork database like Postgres.

This is a script that will bulk convert all the tables in a MS-Access database into a set of ready-to-use sql scripts (one per table).

Saturday, June 11, 2011

Simple VCB: a tool For Vmware Consolidated Backup

I have written and would like to share with the world a groovy script that can be used to drive VCB backups without additional third party software.
One of the most common gripes with VCB is that it doesn't integrate naturally into the VMWare management solution. Of course one can always buy a license for the integration module of his backup software, but that costs additional money.

Some people then resort to script VCB so that additional licenses are not necessary but that, of course, requires scripting skills. Which also means reinventing the wheel just another time.

This has happened to me too recently and I decided that ok, I would reinvent the damn wheel, but this time I would also make sure that the blueprint goes public!

So I wrote this groovy script which I creatively named Simple VCB which does some nice things like:
  • handles more than one esx, vcenter or vsphere server so that you don't have to split your configuration and schedules in more than one script (the vcb host must then be able to mount all the volumes used by these servers)
  • allows you to specify the list of vms to be backed up for each server
  • allow you to specify backup interval and/or protection per server or per single vm
    • interval: is the number of days after which a new backup must be done. I.e. 1 means every day, while 7 means after one week since last backup. In this way you can still take frequent backups for vms that change often and conserve resources usage by widening backup cycles for those that are mostly static (a proxy server, a dns, a reverse proxy)
    • protection: the number of backup copies that should be kept online. Older backups with an index higher than protection are deleted. Protection, like interval, can be set per single vm to allow for finer tuning
The backups are kept in a tidily organized folder structure where the root is defined in the configuration file and can be anything. I currently use a CIFS folder shared by a DataDomain 630 which will online dedupe the vm images.
Each vm then gets its own folder where all backups are stored, with each backup in its own subfolder with a human-readable timestamped name so that restore operations can be readily performed by whatever mean you like. The timestamps are then used to calculate the next backup interval and whether protection has expired and the folder should be automatically removed.

You can get the script on my GitHub page.

This is the configuration file that ships with the software which I believe should quite be self-explanatory.

Tuesday, June 07, 2011

HOWTO: Parallel deployment on tomcat 7

News broke out recently that Tomcat 7 supports parallel deployment.

This feature allows one to deploy a newer version of a web application while maintaining the current one online. The net effect is that new users will be connected to the newest version while already connected users will not be kicked out. Neat uh?
One could even have more than two versions online at any time (if that was necessary).

The details of how this works are explained in the Context Container documentation. Only it doesn't really tell you how to use it, it tells you how they implemented instead.

So what do you have to do to take advantage of this great feature?

First of all upgrade to Tomcat 7 (which btw requires Java 6), but you knew that already, didn't you?

Then simply adopt the following naming strategy when deploying apps: name your war file mygreatapp##version.war (note the ## used to mark the beginnning of the version substring) where version can actually be anything (it is mapped to a String property) but to be safe I suggest using a zero-padded always increasing numeric value (your SVN revision number, perhaps).


That's it. No configuration, rebuilding or trick hats required.

Note: previous app versions will NOT be removed automatically. You will have to remove them yourself using the manager app when their session count drops to zero or you just can't wait anynmore.

Note2: the app version is visible in the manager app, in a dedicated column right beside path.

Note3: if you plan to use a String for the version make sure that the newer version values are greater (in String terms) than previous ones or you'll end up with new users connecting to an older version of the app instead. That's what zero padding is for.