Automated Deployment 1
Traditionally automated deployment on UNIX systems has been the domain of cobbled together shell scripts and bespoke solutions for each site. The power and scriptability of UNIX systems has, in this regard, worked against itself. Compared with the Windows world, which has traditionally been much harder to script, the ease at which the resourceful sysadmin can create a bunch of perl/shell scripts and cobble them together into a tangled mess of a "deployment system" invariably leads to a bloated and convoluted bespoke mess.
The Windows world has tackled the problem head-on by using native and proprietary package installers (and some novel outsiders such as AutoIt) to abstract the whole thing away behind a managed tool.
Enter the automated deployment system.
Now, let me be clear. I’m not talking about systems for deploying large farms of identical or managed boxes. I’m talking about a managed method of getting code, its dependencies, configuration and inevitable subsequent fixes through the various development and testing phases and into production in a managed manner. Tools to handle this job seem to be rather thin on the ground. I’ve managed to identify:
All of these tools have their disadvantages, and being the healthy pessimist I am I’ll tackle those first. All apart from Cfengine require an external runtime or VM: ruby (Capistrano, Puppet), python (Fabric) or Java (SmartFrog). These may or may not be part of your server build (CoolStack on Solaris anyone?). Still I guess this is less brittle than the natively compiled Cfengine if you’re not using one of the supported platform variants and versions. It’s strange the ubiquitous perl 5 is missing from that list. Of the tools Capistrano and Fabric certainly have the least verbose of the various domain-specific languages these tools employ, a common trait shared by all. Of course, as the Puppet team states, creating GUIs for such infinitely configuarble tools is a nonsense task best left to those proprietary vendors selling new clothes to various large organisations.
Capistrano also seems to win out for the lower volume box situations, keeping closer to the traditional UNIX philosophy of building small tools to do one thing well. It does have a rails bias, however. Fabric claims to be bias free, but I’m not in a position to say one way or the other.
I would be interested to hear from anyone who has experience with any of these deployment tools, especially on Solaris and working with Java applications. How do you guys push your code into live in a managed way with easy rollback?
What is the biggest IT myth of all time?
Colin Beveridge asks over at the BCS group on LinkedIn asks: "What is the biggest IT myth of all time?"
Well I don’t know about the biggest, but I have certainly heard some corkers in my time. Here are a few that have stuck with me.
A canny programmer once stole millions of pounds from a bank by taking advantage of rounding errors to "create" money
This might have some credibility in the various "salami slicing" scams that have been pulled over the years, but the version I heard, where the programmer continually lived off a couple of nefarious lines of code - long after he had left the bank - as his secret account continued to accumulate fractional cents every day, is almost certainly a myth. But, if you like this kind of thing, you could do worse than check out Clifford Stoll’s account of how his investigation of a 75 cent accounting error lead to one of the first documented hacking attacks and captures.
"Just [insert worst practice here] to keep the client happy, we’ll do it properly later"
This is very closely related to anything prefixed with "temporary". It’ll never get done properly, it will always be like that and you’ll have to live with it for far far longer than it would have taken to do it correctly, and it will also cause you far more pain and grief than you would have endured shipping a little late in the first place.
"It is finished"
IT, software and systems are processes not furniture. It’s never finished. Unless it’s written in COBOL, talking via CICS and running on an zSeries née S/390 - and your pockets are very very deep - in which case yes, your software has reached Nirvana and will live forever. Your developers, however, may not ;)
Logging in OpenSSH chroot jails will work properly in version 5.2
In February of this year the ability to easily chroot accounts in OpenSSH moved from a maintained but unofficial patch to a properly supported part of the main branch. Except when using internal-sftp DEBUG logging didn’t seem to work properly, a problem that seems to have popped up on numerous mailing lists and message boards since chroot became "official" in February.
Thankfully a patch to bug report 1527 fixes this, and it will be part of 5.2 when it is released. Hopefully with it we’ll have chroot with detailed logging, making the building of highly audited chroot jailed SFTP servers a less painful process than it currently is.
