Tech

Apparently, it's coming. Haven't tested these patches, though (and why yet another btrfs-foo command rather than something integrated with the btrfs command?), but together with my hacked up dirvish (added support to create btrfs snapshots instead of hardlinked trees) this will save me a couple of gigabytes for all those backups of various servers (which I pretty much keep at the same releases.)

The discussion on the btrfs mailing list got quite heated on the online vs. offline dedup issue (and also very silly IMO since nobody said online dedup shouldn't be supported. It's just not written yet...); What nobody mentioned was: how much memory is the hash index of an online dedup daemon going to consume, and how much CPU cache will it burn? This would be my main concern since my NAS only has 512M memory, and also needs to do NAT, VPN and DNS (yes, I'm a home user. I'd like to get the public IP off the NAS, but I'll have to buy some box to do this first...)

Since my NAS at home also acts as DHCP server, the obvious idea was to back up my PC and my laptop whenever they're switched on. Sadly, the documentation on how to do this from dhcpd.conf (instead of watching log files and reacting to log messages) is quite hidden, so here it is: I found the "execute" keyword (see the dhcp-eval manpage), and I found Tim Gustafson, which allowed me to pull it off (although, since I only have the two computers, I opted for a execute statement each and hardcoded the client IP in the call to the backup script. So I don't know if the address parsing stuff he does is correct.)

So the host statements for me look just like this:

  host laeggerli-wifi {
    hardware ethernet 00:22:69:aa:bb:cc;
    fixed-address 172.23.5.19;
    on commit {
      execute("/usr/local/sbin/dhcp-run-backup", "commit", "laeggerli");
    }
  }

And the script to start dirvish is similarly simple, except that it needs to fork to the background to make sure dhcpd is not blocked. The sleep 600 is based on the theory that if I'm on my way out in the morning and need to check mail quickly, that will be less than 10 min, whereas when I'm still online after 10 min, there's a good chance that the back up will go through. Obviously, this could be improved...

#! /bin/bash

# called by dhcpd.conf
# arguments:
#  $1 -> "commit" if called from dhcpd.conf, fork into background
#     -> "run"    if called internall from first instance
#  $2 -> client host

if [ "$1" == "commit" ]; then
    # fork to background
    $0 run "$2" >> /var/log/dhcpbackup.log 2>&1 &
    exit 0
fi

if [ "$1" != "run" ]; then
    echo error
    exit 1
fi

# figure out which host:

host="$2"
if [ "$host" != "laeggerli" -a "$host" != "faehrimaa" ]; then
    echo "Unknown host: $2"
    exit 1
fi

# did backup already run today?
d=`date +%Y%m%d`

if [ -d "/srv/backup/${host}_home/$d" ]; then
    exit 0
fi

# wait 10min before actually running the backup
# (if computer still runs after 10min, it'll likely run for longer...

sleep 600
ping -n -w 3 $host >/dev/null 2>&1 || exit 0

agentpid="/var/run/dirvish/ssh-agent-$host.pid"
[ -f "$agentpid" ] && \
    kill $(< "$agentpid") 2>/dev/null
mkdir /var/run/dirvish >/dev/null 2>&1
eval `ssh-agent` >/dev/null 2>&1
echo $SSH_AGENT_PID > "$agentpid"
ssh-add /etc/dirvish/ssh-key >/dev/null 2>&1

/usr/sbin/dirvish --vault ${host}_home
/usr/sbin/dirvish --vault ${host}_root

/usr/sbin/dirvish-expire --quiet --vault ${host}_home
/usr/sbin/dirvish-expire --quiet --vault ${host}_root

kill $SSH_AGENT_PID
rm "$agentpid"

(I don't claim any rights on any of it, it's trivial enough.)

I had some hope when I read Girish Ramakrishnan's blog post that starts with “To my knowledge, there are 3 Qt based JSON parsers out there”. But I was really disappointed: instead of trying to get a consolidation going or at least highlighting the need for three different parsers, he announces yet another implementation. And, to make matters worse, it is intended to be statically linked whenever it is used. A friendly wave to all security conscious engineers who will now have to hunt down and kill security issues in various places wherever this json parser was used, in various different versions, possibly with local modifications.

Girish, please do not take this as a personal attack, but what you're doing is just bad engineering practice. I don't claim qjsonparser is buggy. I haven't even looked at the code. But let's face it: bugs happen, and json is often passed over the net, so any parser is attack surface. So it should be as easy as possible to get fixed versions of the code out to the users. The means to do this is by allowing distribution builders to be aware of where the code in question was used, and to get fixed versions of it distributed easily. In other words: such code should always be in a shared library.

Take, for example, the history of xpdf/poppler: many people spent countless hours chasing copies of xpdf code in many applications before they finally had enough, forked xpdf (if I have the history correctly) and created the poppler library which is now widely used. Now security issues with the PDF parser require one security fix, not 10.

Just say no.

Filed under “Debian” since this is a Univention system which is based on Debian (still etch, though.) And what specifically annoyed me was today

• That the mailbox list and the actual on disk files can get out of sync.
• That this causes nice “System I/O error: %m” messages (the %m part is verbatim. Nice, isn't it?) in cyrquota, and similar messages in cyradm for “sam” commands.
• That, while this can be fixed with a cyrrecover on the mailbox (a recursive recover on the parent doesn't bring back the mailbox, so I need to call cyrrecover on each affected mailbox separately), the output of cyrquota displays the mailbox as “domain!mailbox^name.folder” while cyrrecover expects “mailbox.name/folder@domain”
• That the System I/O error causes cyrquota to stop, so I need to sit here and restart it countless times. (At least it seems to pick up where it stopped, so I don't have to wait that long until it comes to the next problem.)

I knew from other experiences that one shouldn't use cyrus, but it can't be said often enough... And since I usually don't use it, it amazes me anew every time I have to babysit an installation. While I don't have a similarly big installation to compare it, I've found Dovecot to be very nice. Admittedly it doesn't have that many features.

Ok, here we go: It seems that I'll receive the umbrella (big picture) in the first week of June, so I'm taking orders now. Please read this posting carefully if you want a Debian umbrella.

Update IV 2010-12-12: Orders are now processed via debian.ch, so just go over there for your Umbrella. I still have a very few umbrellas here in Basel, so if you want to pick one up locally you're still welcome.

About CHF 5 to 6 per umbrella will go to debian.ch (where it is held as official Debian money under the authority of the DPL.)

(Old version of this article removed. You're still welcome to send money to my bank account, but you won't get an umbrella in return.)

One in the “obvious, now that you mention it” category. The package description is good enough:

incron is an "inotify cron" system. It works like the regular cron but is driven by filesystem events instead of time events. This package provides two programs, a daemon called "incrond" (analogous to crond) and a table manipulator "incrontab" (like "crontab").

Where “filesystem events” is anything that is reported by inotify; see the inotify(7) manpage. I didn't test and/or use it since I stumbled on it while searching for something completely different, but it sure sounds useful. The important feature not mentioned in the package description: can it limit how often an event triggers a script execution? Reading the manpage, it doesn't appear so, but there's IN_NO_LOOP to “... disable monitoring events until the current one is completely handled (until its child process exits).” Which obviously opens up all kinds of race conditions. So I guess this tool needs to be used with care. Still, I guess a good candidate is monitoring /etc/aliases to run newaliases on change.

So I got a SuperMicro A+ Server 1012G-MTF today (seems to be a very nice unit for a decent price) and am preparing it for taking over fortytwo.ch and related services. Now this thing has got IPMI / BMC with remote management and KVM (both serial console and full graphical console with virtual CD-ROM etc.); works very nice. Basically the only thing I miss is the ability to disable services I don't need and/or restrict access to certain IP addresses. (No, I don't have the BMC on a public IP, but still...)

So the question is: has anybody worked out how to hack / what kind of file system the IPMI Firmware for the H8SGL-F mainboard is? Or how one could drop from the BMC commandline to a /bin/sh prompt on the urnning system? A blog entry at Serverfault suggests it's been done but doesn't say how.

(Running strings on the firmware binary shows the string “Photoshop ICC profile” near the end. I'm not sure if I want to know the story ... ;-)

I very much like that it is so easy to extend PostgreSQL in various ways, including adding server-side languages (for triggers and other stored procedures) as dynamically loadable modules. But somehow the thought that some people actually seem to use PHP as a server-side language, or consider making it possible to use JavaScript, makes me very afraid (recent discussion on the general pg mailing list.) Should PostgreSQL have a “taint” flag like the kernel?

(Admittedly JS is a side effect of also enabling Lua and Scheme, which may make more sense.)

Update 20100618: Added Debconf info.

The famous Debian Umbrellas (big picture) have finally arrived, so I'm keen to get rid of them. Order yours now!

Information about Debconf: I'm not coming to Debconf. But Luca Capello was friendly enough to offer to carry some umbrellas. Coordination via the wiki, orders need to be placed before June 27th.

Probably it's just a question of me not paying enough attention to the news... So: pointers welcome.

There are quie a few shiny new filesystems for local storage, like btrfs or HAMMER (and nilfs, Tux3, ext4, Reiser4...)

It seems the distributed storage side is covered as well, with ceph being merged recently. There are other systems (like, for example, Lustre), but they haven't appeared much in the news channels I tend to read. What I'd be curious is if any of these support hierarchical storage architectures like pushing out rarely used data to tape libraries. (But this is just idle speculation, I don't need this anywhere.)

But what I would really need is a replacement for NFS (v3): a classical client-server filesystem. I'm not sure NFSv4 is the “right” solution (where I'd use it, I currently can't because we rely too much on POSIX ACLs there, making the transition to NFSv4 quite a chore.) I think POHMELFS might be a solution in the long term, or CRFS, but I'm not sure how much progress there is on these; apt-cache search is silent, not a good sign. There's Samba 4 — I guess I'll have to look at it, since it's supposed to be much cleaner and nicer to use than its predecessors and might be a good solution even if no Microsoft systems are involved. Is this what small environments (a fileserver and 100 clients or so) will want to use? Comments are very welcome.

The joys of a new employer ... only 5min by bike to the office instead of 1h by train. And, of course, we're using Debian a lot, and I may do the odd bit of Debian work on company time. Like, right now, working with Klaus Zerwes on getting JWhoisServer uploaded. I hope more opportunities come up.

Update: I'm taking orders now.

I was planning to take orders for the Debian Swirl umbrella starting tonight, but a bit of research showed that shipping prices for parcels are insane (CHF 37 for europe), but it seems I can get away with sending this as a Swiss Post “Maxi Letter” instead, which would result in a shipping price of CHF 12.50 for four and CHF 24 for up to eight umbrellas (1kg or 2kg.) So now I'll go and look into getting some kind of flattish box to stay within the allowed dimensions before I can be sure this is possible. In any case, I expect the delivery in the first week of June.

Since I'll not be coming to Debconf, it would be nice if somebody could take some umbrellas to New York. I'm currently not travelling much, so I'd have to rely on a friendly volunteer. (I'm based in Basel, Switzerland; I am known to go to Zürich regularly.)

Conditions for ordering: Not yet. The umbrella will be available ca. end of May, I'll give details about ordering it then. Information so far: CHF 25 per umbrella (ca. EUR 17 / USD 23), including ca. CHF 6 donation to Debian (via debian.ch); at least at first, I plan to ship in lots of 5 or more to save postage. International travellers should coordinate... (if you're close to Basel, Switzerland, you will obviously be able to get one directly as well.)

Update 2010-06-15: I got the umbrellas now, so you can order them.

As a complete outsider and with my obvious bias as a Debian Developer: how can anybody call Ubuntu a “community distribution” when it's obvious that Canonical and Mark Shuttleworth can, and will, take decisions for reasons that are not made clear, and with only little or no community involvment?

This rethorical question refers, of course, to the current debate about purple vs. brown and the best position of the window close button (Bug report and LWN coverage.)

Conclusion? Let's be fair and call it a community support commercial distribution. Perhaps we should found a non-profit to award a (trademarked) “True Community Effort” label to operating system distributions where no commercial body has the final say?

Playing around a bit with ssh tunneling right now. When I create a kind of VPN concentrator with a few tun interfaces: is there any reason why I can't just assign the same IP on all these tun interfaces? A quick test shows this set up working nicely, with ifconfig tunX localip pointopoint remoteip (the localip part being the same) setting up the routes to chose the right tun device for all remote IP addresses, and ping worked just fine for me. Firewall rules will always have the remote IP and/or the interface name to decide when a packet applies.

Obviously setting up a listening socket at only one of these interfaces is not so trivial now since I can't just listen to the IP, but that's a restriction I'm happy with. Anything else I'm not thinking of right now?