The script is public domain, meant to be run interactively and provided without any warranties or batteries. It may or may not do bad things to your house and your cat, but mostly it just updates Chromium.

So, after a quick look at the even more arcane options, I’m back with PyQt4. Took me a while to figure layouting in Qt Designer out, just to notice that I still can’t build a working distribution with py2app. I’m really looking forward to when everything will be 64bit and we don’t have this multilib/universal pile of crap anymore. Yuck.

My total whackjob of a solution right now is to mutilate a PyObjC-Cocoa Xcode template into running a Qt4 app. It’s not pretty and will probably break sometime in the future, but right now I just want to get some .app out there. Qt also gives me platform independence, which I like.

I’m currently working on having nagify save Nagios data into a local sqlite database so I can generate stats from it later. Those stats will then be used in a fullscreen view mode designed for large displays. At least that’s the plan.

I just wrote a munin plugin that graphs the number of rows in your MySQL databases. If you haven’t heard of Munin yet, check it out – it’s pretty awesome.

The original purpose was to display Growl notifications for Nagios alerts, but nagify is designed to be very flexible and can be expanded to output notifications in pretty much any way.

Please report any bugs to the issue tracker at github.

Update: 1.0.1 is out, now also available via the Python Package Index.

<key>PBX-python-Icon</key>
<array>
<string>py</string>
</array>

One of the problems is that Wikipedia is supposed to be an encyclopedia, not a system to store any and all knowledge. I wonder if it would be feasible to implement a Really Friggin Big Wiki where anyone can write about any topic. The only restriction would be that the article has to state facts in a neutral manner (citing the most dubious sources is ok, as long as it’s clear that the text in question is just the possibly biased opinion or completely insane claims of the source). No restrictions should be imposed when it comes to relevance or target audience.

Such a Really Friggin Big Wiki (maybe I should trademark that) could then be forked into an encyclopedia, a sysadmin wiki, a cookbook, … anything. Edits should be made by the general public in the RFBW and can then find their way into the subwikis where stronger moderation is imposed.

This leads to an interesting set of problems. On the technical side, people are already experimenting with converting MediaWiki XML dumps into a git repository. The problem that remains is making that data available again for web-based editing. I’ve experimented with this in the past and created a very rudimentary wiki system that used git as a backend for both read and write operations. The code sucked, but I think in principle it is the right way to go about this.
Another problem is namespacing and categorizing the data, using “John_Smith” as identifier for an article will no longer be sufficient – the disambiguation pages would be interesting.

I’m looking forward to what the community will come up with and how we’ll organize knowledge in ten years. Just too bad rfbw.org is already taken. Dammit.

While I was looking for a storage solution, I had four priorities:

• Expandability: I had to copy all my stuff once to get them onto a bigger drive – I never want to repeat that experience.
• Encryption: A good deal of my photos is not meant for everyone’s eyes – I think it’s my responsibility to protect the privacy of my models from anyone who might eventually get their hands on one of the drives.
• Cost: Storage systems can cost nearly unlimited amounts of money – money that I’d rather invest in a new lens.
• Fault tolerance: Obviously.

After some testing I came up this totally insane solution:

Take my existing two 500GB WD USB drives and put two shiny (actually, they’re black.) new 1TB WD USB drives next to them. Next, using Linux software RAID 1, I mirror the identical disks, so I get a redundant 500GB and 1TB volume. These volumes are now being encrypted with three different cipher algorithms (yay for paranoia) using TrueCrypt. The final layer is an LVM volume group using the TrueCrypt volumes as PVs.

Here’s some ASCII art:

  +-----------------------+
  |          LVM          |
  +-----------------------+
       |             |
   TrueCrypt     TrueCrypt
       |             |
     RAID1         RAID1
    |     |       |     |
  +---+ +---+   +---+ +---+
  | 5 | | 5 |   | 1 | | 1 |
  | 0 | | 0 |   | T | | T |
  | 0 | | 0 |   | B | | B |
  | G | | G |   +---+ +---+
  | B | | B |
  +---+ +---+

This setup covers all of my four priorities (the only limitation is that you have to expand it in steps of two identical disks). Naturally, this monster isn’t that fast. According to bonnie++, I get about 10MB/s for writing and about 18MB/s for reading. Enough for me.

If you know a better way to get 1.5 TB expandable, encrypted and fault tolerant storage for less than 250 EUR, feel free to email me.

First off, all my bundles are defined in SGenshi. Now you can obviously use <ConfigFile> and point to a TGenshi template. But you might run into a problem here: A TGenshi template always has a static owner/group/perms tuple set in the info.xml file (which is bad if you need multiple instances of the template that belong to different users). I tried working around this via an extra <Permissions>, but the default info from <ConfigFile> seems to have a higher priority (see BCFG2 bug #627).

My next shot was to use <BoundConfigFile>, which lets you inline the template in the bundle file. However, this method has a number of problems as it tends to clutter your bundle files and forces you to use XML templating for text files.

So here’s my ingenious solution: Genshi allows the use of XInclude in XML templates, but with a special twist: You can tell Genshi to parse the referenced file as a text template! So here we go:

<BoundConfigFile 
    name="/foo/bar" owner="${owner}" group="${group}" perms="0644">
  <xi:include parse="text" href="templates/foo/bar.newtxt" />
</BoundConfigFile>