March 2012 Archives

None of these are really very clever, but they’re slightly creative abuses of the standard tools, and maybe someone will find them useful.

1. Browsing lots of small files. Suppose you’re looking at something like a Qmail configuration directory or settings in /proc or /sys. where there are lots of one- or two-line files. You could try to get a handle on them by using cat(1) but I find that the right answer is

   grep ^ files …

   For trees of stuff, like in /proc/sys/net/*/conf, say, GNU grep’s -r flag is useful.

2. Clobbering files as root. I try to run as a non-root user most of the time, and elevate to root as needed, using sudo(8). (The vulnerability history of sudo makes for exciting reading, but I like that it maintains a log. I’m much less impressed with the security theatre of typing passwords, and its tendency to send loud SECURITY mail is very annoying.)

   So, there’s a file you want to hack: it’s owned by root, and the easiest way to hack it is with a shell rune. But if you redirect something’s stdout to the file, that’ll be done in your shell, with your privileges, so it won’t work. I use tee(1) here.

   … | sudo tee output >/dev/null

   (This at least leaves a log that I hacked the file, and even if it doesn’t say exactly how, it’s no less informative than sudoedit.)

I’m sure there were going to be more of these. Maybe some of them will come to me later.

If you’re certifiably crazy, you serve multiple views of your DNS zones from the same BIND instance. Suppose one of those zones is dynamic — maybe it’s updated by the DHCP server or something — and wants to be shared between both views.

Apparently enough people are mad enough to want to do this that there’s an entry about it on the BIND FAQ page (entitled How do I share a dynamic zone between multiple views?). The problem is tricky because, for timely updates, each view has to be able to contact the other reliably: the slave must be able to request zone transfers from the master, and the master must be able to send notifications to the slave. The official solution involves inventing magical TSIG keys that the views can use to identify each other.

Unfortunately, this doesn’t actually work properly when you have more than two views. In the scenario the FAQ answer appears to be considering, the nameserver in question has only one IP address. There’s therefore no way for the master view to send update notifications to both slaves.

I run OSPF at home. I realise that this is an obvious sign of madness, but let’s leave that aside for now. I tried running BIRD, but I couldn’t get that to work properly: something to do with not reporting changes in VPN arrangements, I think. So I run Quagga.

This seems to work well. Just one snag: after running perfectly happily, one of my routers (vampire, for the curious) started being shunned by the others after running fine for a while. Worse, once in this strange state, vampire’s ospfd process started consuming lots of memory. This is a shame, since vampire only has 512MB of physical memory to start with.