Another blog meme - taken from Stewart Smith:

* Grab the nearest book.
* Open it to page 56.
* Find the fifth sentence.
* Post the text of the sentence in your journal along with these instructions.
* Don’t dig for your favorite book, the cool book, or the intellectual one: pick the CLOSEST.

"The 'spirit of direct communication' is to learn the true path of Niten Ichiryu and to pass it on."

Mine is Miyamoto Musashi's The Book of Five Rings. Honestly. It's the closest book to hand. I bought it for Ruth and she has studiously not read it.

Great little TV show called Eureka. Just watching an episode called "H.O.U.S.E Rules" and it had the cutest little War Games reference. Strongly recommend people go watch.

I sent this via snail mail and email to Stephen Conroy reagrding the idiotic plan to "clean feed" Internet connections.

Minister Conroy,

It is with extreme disappointment that I write you. After years of government who did not understand the Internet I had hoped the incoming Labour government would be more forward thinking.

The plan to introduce a "clean feed" is technologically backward, short-sighted and has the potential for enormous abuse. In many ways it is little better than the censorship undertaken by countries such as China, Iran and similar totalitarian regimes.

The content being targeted is already illegal in this country. These ham-fisted attempts to block it, at enormous expense and with such huge potential for false positives, would appear to actually detract from efforts to stop the heinous trade in child pornography.

Rather than crudely censoring the web I feel money and efforts would be better directed at enhancing our law enforcement capabilities. I am sure the AFP and other agencies could put the proposed investment to
good use and target actual offenders rather than have to sift through a mountain of false positives.

See http://nocleanfeed.com/ for further information.

Everyone should go out now and download or buy a copy of Cory Doctorow's Little Brother and give it to a teenager. I don't know a lot of teenagers (the court mandates that :P ) but I am going to seed a few copies about.

It's not the world's greatest novel - not even close - but it is an important novel. It's also a little heavy on the rhetoric and I don't know a lot of teenagers who talk like the main character (more's the pity).

Much like the Max Headroom's tagline of "20 minutes into the future", Little Brother is set in a RSN San Francisco. A San Francisco that has a little of the smell of Big Brother. The same smell a lot of Americans, British and Australians can sense as our civil liberties are slowly eroded in the name of "national security".

The main character, Marcus, is a 17 year old high school student interested in computers, gadgets, role-playing and girls. Shortly after the opening of the book a major terrorist incident occurs: the bombing of the BART and the Bay Bridge. In the aftermath of the incident Marcus and three of his friends are detained and interrogated as suspected terrorists. After a week of detention all but one of them is freed but warned that the government is watching them and told to tell no one they were detained.

Marcus decides to take action and possibly revenge for his missing friend and that's where the story starts getting interesting.

The main aspect of the book that appealed to me is the first rate introduction to the whys and hows of privacy and security. An introduction that even paranoids like me can appreciate. Doctorow explains PKI, RFID hacking and a bunch of other security mechanisms, counter-measures. Most importantly, Little Brother teaches the reader how to THINK about privacy and security.

This is the key thing missing from a lot of actual "grown-up" security books - thought leadership. A lot of these security books provide mechanisms and systems to measure risk and apply controls. Less often do they teach people how to think about threats, how to distil threats into risks and how to apply controls to mitigate those risks. Very rarely, if ever, do they teach you how to think like the attacker.

Little Brother is like a distilled HOWTO on being a sneaky bastard. It teaches you that paranoia, properly applied, is not only healthy but logical given the threats to our privacy and security.

Little Brother also demonstrates that sometimes attacking the control is almost as effective as attacking a target. Rendering the control inoperative not only lowers the protection of the target but can result in the target's defenders being tied up trying to protect the control instead of the target.

Overall, an excellent book that offers some really useful insights for both adults and teenagers. Go give it to a teenager and hopefully they'll trust someone over 25 long enough to read it.

You can download the book for free at:

http://craphound.com/littlebrother/download/

Or you can buy it via your book store or Amazon.

So went down to Hobart in Tasmania to do the papers face-to-face and final section for Linux.conf.au 2009.

I have to say that the submitted papers rock. We've got some excellent rock-star speakers who are going to blow peoples socks off. I won't steal any of the LCA 09 team's thunder by naming names but it's pretty cool.

I've also been let into the keynote speaker secret and got to say those are pretty cool too.

We also got around to doing the schedule and I think that too is well put together and people are going to find it hard to select which sessions they are going to get to during some streams as there are so many great topics.

So stay tuned for further news on this... The LCA 09 team will be releasing stuff soon.

I downloaded Google’s new Chrome browser (http://www.google.com/chrome) this morning. I installed it and I played with it for about an hour. I read the release notes and watched several of Google’s videos. Overall, it looks cool, seemed to be snappy and quick to respond. I was particularly taken with the focus on tabs. I also thought the multi-process, multi-tab sandbox idea is a really interesting idea - initially from a useability perspective but potentially also from a security perspective. Though there isn’t anywhere near enough information yet to make a proper assessment. I did try to break some tabs and see how effective the sand-boxing was (it seems to hold up from a very brief look but it’ll take some code review from someone with more code-fu than me to determine actually how secure the concept is – see below).

A few things didn’t inspire me – the border decoration was a little … unintegrated. And I am always loath to pass judgement on an application that by its very nature needs to be examined in a cross-platform context and I would want to see running on all of Microsoft Windows, OSX, and Linux. This is particularly true of OSX where the graphical environment can make an enormous difference to how an application engages you.

But after my play I closed Chrome down with a big sigh to get on with my actual day job. Why the sigh? Did I think the new Chrome browser wasn’t very good? Nope. But my first thought was “I wonder how many people in my enterprise have downloaded and installed Chrome over the last few days”. This was quickly followed by me asking two questions:

1. What is the change in the enterprise’s risk profile of adding this new application?

2. What’s the operational impact of some, many or all of my users downloading and installing this application?

Obviously (and hopefully) it is only an incremental change in risk profile and not much at that. The browser will probably only be downloaded by power users and innovators in the enterprise, initially at least. On the threat landscape in most enterprises however browsers punch well above their weight in terms of attack surface, are a common source of malware infection and browser exploits are a popular target for hackers. Indeed a (the first?) Chrome vulnerability has already been discovered AND exploited (see http://www.readwriteweb.com/archives/security_flaw_in_google_chrome.php) literally hours after Chrome was released. So Chrome’s potential as a source of compromise and attacks needs to be carefully considered.

The answer to the second question is also ambiguous but finding out can add a lot of work for a security team. With any new application, but especially ones like browsers that are such rich sources of malware attack, there is now a potential need to:

• Track bugs and vulnerabilities for the application;
• Add it to software profiles for vulnerability scanning;
• Investigate its behaviour for network behaviour and IDS/IPS;
• Profile it for our Security Event and Incident Management process; and
• Specifically for this application ascertain if its Incognito “stealth” browsing capability impacts our ability to investigate and gather evidence in incidents.

So most important to me right now is not whether Chrome will outshine Firefox or IE or whether it represents the future of the browser. But rather how much work is this new browser going to create for me… :)

P.S. If you’re interested in look at it you can find Chrome’s source code at http://code.google.com/chromium/. There are also build instructions (for which you will probably need to have some developer skills) for OSX and Linux.

So when I first looked at Redmine I ran it up and used Sqlite3 as the database back-end. Then when I migrated our Trac data I just left Sqlite3 as the back-end database and migrated our data to that. With that startling being of forthought aside, I always had the view the database should be MySQL because well:

a) I know it
b) I like it
c) It's probably more scalable (IMHO)

So today I actually sat down to do the migration piece. I dumped out the sqlite3 database and tried to do some manual/scripted edits to convert it to something MySQL would import. Epic Fail.

So I tried the YAMLdb that abstracts database exports using YAML. A quick installation, some edits to config/database.yml, a rake db:dump and rake db:load and the data was moved:

... Create our database ...

$ sudo mysql -p
mysql> create database redmine character set utf8;

... Grant privs to your chosen user ...

mysql> GRANT ...

... Configure a test database for our new MySQL database ...

$ vim config/database.yml

.. install the plugin ...

$ sudo script/plugin install http://opensource.heroku.com/svn/rails_plugins/yaml_db

... Dump out the current production database ...

$ sudo rake db:dump RAILS_ENV=production

... Load the freshly created db/data.yml file into our test database ...

$ sudo rake db:load RAILS_ENV=test

... Reconfigure the application to point to the new MySQL database as production ...

$ vim config/database.yml

... Start Redmine ...

$ sudo /etc/init.d/mongrel_cluster start


Had one bad field I had to do some manual editing too - still not quite sure what was wrong with the field but whatever I did fixed it - but otherwise very smooth.

Started up and now Redmine runs perfectly with MySQL as the back-end!

So rather than doing the work I actually should be I've been playing with BuildBot. I had intended to get around to setting up BuildBot sometime in the next couple of months but I got hooked.

The reason I wanted to have a look at BuildBot was that Puppet has reached a stage where we simply can't test every platform it runs on. We are also starting to get patches from a wider variety of sources. Buildbot will allow us to execute our tests on a wider variety of platforms. Hopefully with the cooperation of the community we can gather a really big collection of build platforms to test on.

Here's the blurb for BuildBot

The BuildBot is a system to automate the compile/test cycle required by most software projects to validate code changes. By automatically rebuilding and testing the tree each time something has changed, build problems are pinpointed quickly, before other developers are inconvenienced by the failure. The guilty developer can be identified and harassed without human intervention. By running the builds on a variety of platforms, developers who do not have the facilities to test their changes everywhere before checkin will at least know shortly afterwards whether they have broken the build or not. Warning counts, lint checks, image size, compile time, and other build parameters can be tracked over time, are more visible, and are therefore easier to improve.

The overall goal is to reduce tree breakage and provide a platform to run tests or code-quality checks that are too annoying or pedantic for any human to waste their time with. Developers get immediate (and potentially public) feedback about their changes, encouraging them to be more careful about testing before checkin.

It's a very easy tool to deploy. The hardest part has been the slightly broken Git source handling and the assumption that any Git repository is local. I need to have a local Git repository to allow BuildBot to submit the right commits references to the PBChangeSource function.

But I designed a basic process for handling new commits:

1. Commit pushed to GitHub.
2. Commit bot at GitHub picks up commit and sends it to BuildBot Master.
3. BuildBot uses the git_buildbot.py script to calculate the before/after commit and branch references and tell BuildBot about them.
4. BuildBot executes the build and tells each slave to retrieve the commit and runs the tests. Currently we're running:

a. All the Unit tests
b. All the RSpec tests

5. We then get the results of the tests on the website and in an email to the new Puppet Builds mailing list.

In addition I've also enabled BuildBot's IRC bot and added a new bot, called pinocchio, to the #puppet channel that reports on build status.

At this stage it's all in test mode and when I've ironed out a few issues we should be in a position to do a production installation at ReductiveLabs and start canvassing for build slaves.

The funniest thing I've read in ages:

http://blogs.ingres.com/emmamcgrattan/2008/07/24/happily-ever-after/

When it rains ... it drizzles...

Oh dog. Still laughing. The Flight of the Conchords outside the Australian consulate in New York flipping the bird. I thought the racism against Kiwi's was a bit predictable but very funny. Needed more Kristen Schaal though.