Obnam 1.0 was released during several months when I
had no well-connected server to use for backups. Yesterday I installed a
terabyte disk in a basement with a fiber optic network connection, so my
backupless time is over.
Now, granted, I have a very multi-layered approach to backups; all my data
is stored in git, most of it with dozens of copies automatically
maintained, and with archival data managed by git-annex. But I still like
to have a "real" backup system underneath, to catch anything else.
And to back up those parts of my user's data that I have not given them
tools to put into git yet...
My backup server is not
my basement, so I need to securely encrypt
the backups stored there. Encrypting your offsite backups is such a good
idea that I've always been surprised at the paucity of tools to do it. I
got by with
duplicity for years, but it's increasingly creaky, and the
few times I've needed to restore, it's been a terrific pain. So I'm excited
to be trying Obnam today.
So far I quite like it. The only real problem is that it can be slow, when
there's a transatlantic link between the client and the server. Each file
backed up requires several TCP round-trips, and the latency kills the
bandwidth. Large files are still sent fast, and obnam uses little resources
on either the client or server while running. And this mostly only affects
the initial, full backup.
But the encryption and ease of use more than make up for this. The real
killer feature with Obnam's encryption isn't that it's industry-standard
encryption with gpg, that can be trivially enabled with a single option
(
--encrypt-with=DEADBEEF). No, the great thing about it is its key
management.
I generate a new gpg key for each system I back up. This prevents systems
reading each other's backups. But that means you have to backup the
backup keys.. or when a system is lost, the backup would be inaccessible.
With Obnam, I can instead just grant my personal gpg key access to
the repository:
obnam add-key --keyid 2512E3C7. Now both the machine's
key and my gpg key can access the data. Great system; can't revoke access,
but otherwise perfect. I liked this so much I stole the design and used
it in git-annex too. :)
I'm also pleased I can lock down
.ssh/authorized_keys on my backup
server, to prevent clients running arbitrary commands. Duplicity runs
ad-hoc commands over ssh, which defeated me from ever locking it down.
Obnam can be easily locked down, like this:
command="/usr/lib/openssh/sftp-server"
This could still be improved,
since clients can still read the whole filesystem with sftp. I'd like to
have something like git-annex's
git-annex-shell,
which can limit access to only a specific repository. Hmm, if Obnam
had its own server-side program like this, it could stream backup data to
it using a protocol that avoids the roundtrips needed by the SFTP protocol,
and fix the latency issue too. Lars, I know you've been looking for a Haskell
starter project ... perhaps this is it? :)
Short before Debian is freezing the upcoming release of a new version of nagios-plugins is scheduled for Wednesday. The good news is, that a recent version is available in unstable and testing. Upstream only fixed some check_ping issues, which are not included in nagios-plugins 1.4.16~pre1-1. There is also a package available through squeeze-backports.
If you are able to, please test the packages as soon as possible. If there are some quirks, these can be fixed in the next two days upstream.
However, running everything through ssh to another machine makes editing and iterating more clumsy; I need to do agent forwarding etc not terribly hard, but not free either, particularly when I travel, I need to remember to sync my source trees back to my laptop. So I prefer to live on my laptop and use my desktop for compute power.
I had a couple of Juju charms I wanted to investigate, but I needed enough compute power to make my laptop really quite warm so I thought, its time to update my local cloud provider from Eucalyptus to Openstack. This was easy enough, until I came to run Juju. Turns out that Juju s commands really want to talk to the public DNS name of the instance (in order to SSH tunnel a connection to Zookeeper).
But! Openstack returns DNS names like Server-3 , and if you think about a home network, its fairly rare to have a local DNS server *anyway*, so putting a suffix on names like that won t help at all: you either need to use a DNS naming provider (openstack ships with an LDAP provider, which adds even more complexity), and configure your clients to know how to find it, or you need to use the public IP addresses (which default to the FlatNetwork, which is routable within a home LAN by simply adding a route to 10.0.0.0/8 to your wifi interface). Adding to confusion, some wifi routers fail to forward avahi messages, which is a) terrible and b) breaks the only obvious way of doing no-config local DNS 
.
So, I did some yak shaving this morning. Turns out other folk have already run into this and filed a 
I was looking for an excuse to try 
good news of the RCBW week: more & more patches from people I haven't
seen before in the BTS. keep them coming!
I m now a Debian Developer (or rather, I ve gotten my account created) I still don t feel right calling myself a Debian Developer just yet :)
Before I go off with my usual rants, I think now s about a good of time as any to thank everyone who helped me here.
So, thank you. Really. All of you.
I only hope to live up to the stellar example of those before me.
Release 0.9.11 of 
Update 2: 
The 
The D-I beta release is in preparation so we have many last minute
updates and I'm uploading gazillion of packages. Each time, I upload
one....a translator pops up and sends another update, etc. :-)
To:
Game on!
