A couple of days ago I wrote a post about Veewee, the automated boxgrinder for Virtualbox boxes. But if you had no idea what Veewee was, all that detail wouldn’t have made much sense to you. So I threw together a quick screencast on YouTube. Here it is!
Recently, Mitchell Hashimoto released a major rewrite of Vagrant, the tool that lets you build, provision, and rebuild virtualized development environments at the click of a button. While the rewrite is great — it has many new features, chief amongst them the ability to use virtualization providers other than VirtualBox — it was a major architectural change, and this broke many tools that work with Vagrant. One of them is veewee, a popular tool from Patrick Debois that allows anyone to rebuild fresh Vagrant boxes. Here’s how I fixed my veewee installation for now. Continue reading →
As a user, I’ve always been impressed with Atlassian‘s products for software development, issue tracking and documentation. For companies who take these things seriously, JIRA, Greenhopper and Confluence are quickly becoming the go-to products, and with good reason: the products are easy to get started with but have the enterprise features that allow a company to customize workflows as their business changes. I hate to slam open-source products but just try doing what JIRA does with Bugzilla or Trac.
The products themselves, though, can be a nightmare to install, despite the fact that they are mostly just Java web applications living in a WAR file. The products have improved immensely from the days when setting them up involved hacking up a multitude of XML files in WEB-INF (though there still is some of that), and it’s still annoying that Atlassian doesn’t support running the applications as unexploded WARs within Tomcat or another servlet container, probably for the aforementioned reasons. All that aside, though, it’s satisfying when everything is working together and users can single-sign-onto the entire Atlassian suite because of the magic of Crowd, Atlassian’s SSO directory server.
Last week, I released a set of Chef cookbooks I wrote at SecondMarket to ease the installation of the Atlassian tools on a server. I’m still looking to automate more parts of this, including the ability to edit the aforementioned XML files in-place in an idempotent way, so pull requests against our GitHub repo would be welcome.
Special Note on Using Atlassian Products in the Amazon Cloud
I should also mention that my first attempt to set up Atlassian’s products using Amazon Relational Database Service (RDS) as a backing store was a failure. To spare you the pain of finding this out yourself, I’ll just mention the reason: Crowd, JIRA and Confluence expect MySQL to be configured with READ-COMMITTED transaction isolation level, which means you need to configure MySQL to have row-based binary-logging. Unfortunately, binlog_format is not a parameter you can configure in RDS’s DB Parameter Groups, for obvious reasons; it would affect all other clients on that MySQL instance. This has been confirmed with Amazon support, so JIRA/Crowd/Confluence with RDS is a no-go.
Last night, at a meeting of NYLUG, the New York City Linux Users’ Group, I watched Sean O’Meara whip through a presentation about Chef, the system configuration management (CM) tool. I was impressed. The last time(s) I tried to play with automation tools like cfengine and Puppet I got very frustrated at their complexity. The folks at Opscode have definitely succeeded at bringing simplicity (as much as can be had) to the CM space.
But what struck me after hearing Sean had nothing to do with Chef. Instead, I came to the conclusion that pure systems administration is eventually going to die out as a profession. The developer is now king (or queen), and that’s not a bad thing. Continue reading →