That was fun! Since my previous entry on using head to display the contents of several files in a form that's easy to cut and paste, multiple people have sent elaborations or related tricks. It seemed like it would be a good idea to post a roundup, since I learned a bunch. Multiple people (I think Josh Triplett was the first) pointed out that one can avoid having to pick a sufficiently large value of -n by instead using:

    head -n -0 *.install

With GNU head at least, a negative number says to print out all lines of the file except that many at the end, so -0 displays the whole file, regardless of size. Unfortunately, while this works anywhere that I am likely to run it, it's not specified by POSIX, while the original is. Another variation, pointed out by Buck Huppmann, is:

    tail -n +0 *.install

The +0 syntax is required by POSIX, unlike the -0 syntax for head... but unfortunately POSIX doesn't require that tail supports multiple files and the headers, although it does for head. Buck also pointed out that including the -v flag will always force the header even if there's only one file, which is useful. (Although be warned that -v isn't a POSIX-recognized flag.) Markus Raab also pointed out the xsel utility, which I'd heard of but hadn't ever used. If the goal is to cut and paste the output, using:

    head -v -n -0 *.install   xsel -i

avoids the cut part by dumping the result directly into the X selection. Buck pointed out xclip, which does the same thing. Both can be used with the -o flag inside an editor to paste as well if you don't want to reach for a mouse. In vi :r !xclip -o, and in Emacs, C-u M-! xclip -o. Finally, Guillem Jover metioned that:

    grep . *.install

does sort of the same thing with a different output format that may be more useful depending on what you're doing. (I find it less human-readable but more machine-parsable.)

Dear World, On the morning of December 24th I felt an unusual pain in my left hand between the thumb and forefinger. The pain increased and in the afternoon I got a high fever, at some point above 40 degrees Celsius or 104 degree Fahrenheit. I went to the emergency department and was hospitalized during the night between the 24th and 25th of December. On the afternoon of December 26th I underwent surgery to find out what was happening, and was then diagnosed with Necrotizing Fasciitis (the wikipedia article on NF gives a fair summary), caused by the common streptococcus bacteria (again see wikipedia article on Streptococcus). A popular name for the disease is flesh-eating bacteria. Necrotizing Fasciitis is a rare and aggresive infection, often deadly if left untreated, that can move through the body at speeds of a couple of centimeters per hour. I have gone through 6 surgeries, leaving wounds all over my left hand and arm. I have felt afraid of what the disease will do to me, anxiety over what will happen in the future, confusion and uncertainty about how a disease like this can exist and that I get the right treatment since so little appears to be known about it. The feeling of loneliness and that nobody is helping, or even can help, has also been present. I have experienced pain. Even though pain is something I m less afraid of (I have a back problem) compared to other feelings, I needed help from several pain killers. I ve received normal Paracetamol, stronger NSAID s (e.g., Ketorolac/Toradol), several Opiate pain-killers including Alfentanil/Rapifen, Tramadol/Tradolan, OxyContin/OxyNorm, and Morphine. After the first and second surgery, nothing helped and I was still screaming with pain and kicking the bed. After the first surgery, I received a local anesthetic (a plexus block). After the second surgery, the doctors did not want to masquerade my pain, because sign of pain indicate further growth of the infection, and I was given the pain-dissociative drug Ketamine/Ketalar and the stress-releasing Clonidine/Catapresan. Once the third surgery removed all of the infection, pain went down, and I experienced many positive feelings. I am very grateful to be alive. I felt a strong sense of inner power when I started to fight back against the decease. I find joy in even the simplest of things, like being able to drink water or seeing trees outside the window. I cried out of happiness when I saw our children s room full of toys. I have learned many things about the human body, and I am curious by nature so I look forward to learn more. I hope to be able to draw strength from this incident, to help me prioritize better in my life. My loving wife sa has gone through a nightmare as a consequence of my diagnosis. At day she had to cope with daily life taking care of our wonderful 1-year old daughter Ingrid and 3-year old boy Alfred. All three of them had various degrees of strep throat with fever, caused by the same bacteria and anyone with young kids know how intense that alone can be. She gave me strength over the phone. She kept friends and relatives up to date about what happened, with the phone ringing all the time. She worked to get information out from the hospital about my status, sometimes being rudely treated and just being hanged up on. After a call with the doctor after the third surgery, when the infection had spread from the hand to within 5cm of my torso, she started to plan for a life without me. My last operation were on Thursday January 2nd and I left hospital the same day. I m writing this on the Saturday of January 4rd, although some details and external links have been added after that. I have regained access to my arm and hand and doing rehab to regain muscle control, while my body is healing. I m doing relaxation exercises to control pain and relax muscles, and took the last strong drug yesterday. Currently I take antibiotics (more precisely Clindamycin/Dalacin) and the common Paracetamol-based pain-killer Alvedon together with on-demand use of an also common NSAID containing Ibuprofen (Ipren). My wife and I were even out at a restaurant tonight. Fortunately I was healthy when this started, and with bi-weekly training sessions for the last 2 years I was physically at my strongest peak in my 38 year old life (weighting 78kg or 170lb, height 182cm or 6 feet). I started working out to improve back issues, increase strength, and prepare for getting older. Exercise has never been my thing although I think it is fun to run medium distances (up to 10km). I want thank everyone who helped me and our family through this, both professionally and personally, but I don t know where to start. You know who you are. You are the reason I m alive. Naturally, I want to focus on getting well and spend time with my family now. I don t yet know to what extent I will recover, but the prognosis is good. Don t expect anything from me in the communities and organization that I m active in (e.g., GNU, Debian, IETF, Yubico). I will come back as energy, time and priorities permits.

I'm not a strong swimmer, and never have been. I was never confident in the water as a child. In my teenage years, I had some skin issues that I was very self-conscious about. Going to a boy's school where I was already bullied, I didn't want to add material, so I avoided swimming. To this day, I can barely swim 50 metres freestyle. To think I once had aspirations of getting into the police, which required a bronze medallion. As as result of my atrocious swimming abilities, it's been very important to me that Zoe be able to swim well. Purely for her own personal safety if nothing more. She's been doing "swim classes" of various sorts since she's been 6 months old. In the US, they were group parent/child water familiarisation classes. When we moved back to Australia and turned three, she was eligible to start doing small-group instructor-led classes with Hampton Swim School. It felt like such an milestone just to no longer have to be in the pool with Zoe. I was initially quite skeptical of Hampton's methods, compared with what I'd observed at the Betty Wright Swim School (which subsequently had to close due to aging facilities). Having seen how well Zoe's swimming has progressed in 3 quarters of classes is just amazing. The last few times I've taken Zoe to a public pool for some non-class swim time, her confidence in the water has been fantastic. I've bought some "sinkies", toys that sink to the bottom, and she'll happily dive down to the bottom to retrieve them (with assistance from me getting down there). Today, to escape the 40 plus degree heat, I took her to the Sleeman Sports Centre, because they have a really cool slide, and the whole thing's indoors. Zoe was confidently swimming between me and the side of the pool in water that was over her head, repeatedly. So to have her go from being fine in the water as long as she was being held, to actively asking me to go further back from the wall, in under a year has been really excellent progress. She's also "diving" in off the side (it's more like a bad belly flop, but she has brilliant form at the start, with her hands over her head). We got to the pool today around 10:30am, and it turned out the slide didn't open until 1pm, so we decided to stick around for lunch and wait until the slide opened. To kill time after lunch, we went to the 50 metre pool, where some other kids were taking turns to jump in off the starting blocks. Fearless Zoe wanted to have a go too. This was seriously deep water. It was really inspiring watching this tiny little girl climb up onto the starting blocks of the 1982 Commonwealth Games 50 metre pool and "dive" into the water, flounder over to me, who was furiously treading water in the middle of the lane, and then flounder over to the side, climb out unassisted and do it all over again. It was a seriously "proud father" moment, while I was trying not to drown myself in the middle of the lane. I wish I'd had someone there with a camera to capture the moment. I have great hopes for the future of her swimming, and I think she's ready to go up a level in her swim class.

So, got a beep this morning from our work monitoring system. One of our customers domain names is hosted with livedns.co.uk (which, as far as I can tell, is part of the Fasthosts franchise)... It appears that Fasthosts have managed to entirely break their DNS:

brettp@laptop:~$ host www.fasthosts.com
;; connection timed out; no servers could be reached
brettp@laptop:~$ whois fasthosts.com   grep -i "Name Server"
   Name Server: NS1.FASTHOSTS.NET.UK
   Name Server: NS2.FASTHOSTS.NET.UK
Name Server: NS1.FASTHOSTS.NET.UK
Name Server: NS2.FASTHOSTS.NET.UK
brettp@laptop:~$ whois fasthosts.net.uk   grep -A 2 "Name servers:"
    Name servers:
        ns1.fasthosts.net.uk      213.171.192.252
        ns2.fasthosts.net.uk      213.171.193.248
brettp@laptop:~$  host -t ns fasthosts.net.uk 213.171.192.252
;; connection timed out; no servers could be reached
brettp@laptop:~$ host -t ns fasthosts.net.uk 213.171.193.248
;; connection timed out; no servers could be reached
brettp@laptop:~$

So, that's fasthosts core nameservers not responding, good start! They also provide livedns.co.uk, so lets have a look at that:

brettp@laptop:~$ whois livedns.co.uk   grep -A 3 "Name servers:"
    Name servers:
        ns1.livedns.co.uk         213.171.192.250
        ns2.livedns.co.uk         213.171.193.250
        ns3.livedns.co.uk         213.171.192.254
brettp@laptop:~$ host -t ns ns1.livedns.co.uk 213.171.192.250
;; connection timed out; no servers could be reached
brettp@laptop:~$ host -t ns ns1.livedns.co.uk 213.171.193.250
;; connection timed out; no servers could be reached
brettp@laptop:~$ host -t ns ns1.livedns.co.uk 213.171.192.254
;; connection timed out; no servers could be reached

So, erm, apparently that's all their DNS servers "Not entirely functioning correctly"! That's quite impressive!

This is a small bug-fix release of this load-balancing system status daemon. The primary purpose of the release is to merge the various fixes to the new systemd unit files that I made in the Debian package after a broader code review. This release also fixes a long-lived oversight and sets lbcd's listening sockets to close-on-exec so that they're not inherited by external weight commands (already handled under systemd by socket activation) and improves the lbcd man page. You can get the latest version from the lbcd distribution page.

About half a decade ago, I created a gmail account (maybe longer not so sure anymore). After testing it out for a while, I decided that it wasn't for me; but as a gmail account comes with a google account for free, I didn't throw it out. As time went on, I added a few other things to that account. I try to limit its use a bit, but I do own a few android devices (for lack of a better alternative), and I do use adsense on my website, and all of these are linked to my existing google account; so I don't want to throw it away. I don't ever read mail sent to my gmail account, though; I prefer to read my mail in a local mail client (I used mutt for about a decade, having switched to thunderbird recently). Since it kept happening that people thought I would read my gmail account (which I do still use for XMPP, in spite of your recent crippling of that service), I configured an autoresponder on gmail to warn people off, and told them to use my main mail address instead of the gmail one. Additionally, I configured my main mail addresses (plural; they're really aliases) as "secondary" addresses on my gmail account, so that people who try to send mail to me could figure out where to actually send it before seeing the autoreply. Unfortunately, for some reason you seem to have interpreted that as "screw his MX records and DNSSEC, we'll just intercept anything coming from our servers and going to Wouter Verhelst as going to his gmail account". There's a word for that. I'm not going to use it.

I ran across this trick a long time ago and now use it regularly, but it occurred to me today that I don't remember seeing anyone else mention it. So, just in case it helps someone else: I often find myself wanting to copy and paste the contents of several small files into an email message, particularly when explaining Debian packaging. I want to show all the file contents with little headers showing which lines come from each file. This gets tedious if I actually do this file-by-file. The obvious approaches, from including them into my editor to cat'ing them one-by-one and pasting them, are tedious and require writing the headers by hand. Obviously, cat doesn't help, since it obliterates the difference between the files. What does help, however, is good old head (or tail, for that matter). People normally use those utilities with standard input or a single file, but you can give them multiple files, and they do just about exactly what you want. Consider this shell transcript:

    % head -n 20 *.install
    ==> liblog4shib-dev.install <==
    usr/bin/log4shib-config
    usr/include/*
    usr/lib/*/lib*.a
    usr/lib/*/lib*.so
    usr/lib/*/pkgconfig/log4shib.pc
    usr/share/aclocal/log4shib.m4
    debian/log4shib-config.1 usr/share/man/man1
    ==> liblog4shib-doc.install <==
    usr/share/doc/log4shib-*/api/html usr/share/doc/liblog4shib-doc
    ==> liblog4shib1.install <==
    usr/lib/*/lib*.so.*

Just pick some value for -n that's longer than any of the files (I normally want to show the contents of small files anyway), run head on all the files whose contents you want to show, and then you can cut and paste its full output directly into your email message. Bonus: This behavior is even guaranteed by POSIX (something that I didn't realize until I checked while writing this post).

A new release of the BH package is now on CRAN and its mirrors. BH provides (a sizeable subset of) the Boost library for C++, particularly the (large) parts delivered as pure template headers not requiring linking. See the BH page for more details. This release comes from a rewritten build script for the package. We no longer drive the initial set of Boost libraries by the requirements of the bigmemory (and synchronicity) packages, but rather explicitly enumerate an equivalent set of Boost libraries. This ensures that these libraries are included completely. We also move the project repository to this GitHub repo. The complete list changes follows below.

Changes in version 1.51.0-4 (2014-01-01)

• Rewritten main package creation script to no longer scan for what bigmemory and synchronicity use, but rather explicitly copy over an (equivalent) list of explicitly-enumerated Boost libraries
• Repository moved from R-Forge to GitHub, scripts and layout adjusted accordingly
• Besides the implicitly expanded coverage by including the complete libraries, we also expanded from math/distributions to all of math.

Courtesy of CRANberries, there is also a diffstat report for the most recent release. Comments and suggestions are welcome via the mailing list or issue tracker still available via the package page at R-Forge.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

One of those enlightenment moments that I should have had sooner: every time I have seen someone set up an OpenVPN VPN, they have generated all the certificates on the VPN server as root using easy-rsa. This is kind of strange, because you end up with an incredibly sensitive directory on the VPN server containing every private key for every client. Another angle is whether you trust the random number generators used to create all these keys - does your hosting provider use a weak RNG? Instead, you could set up your CA using easy-rsa on a separate machine - perhaps even air-gapped. Then private keys can be generated on each machine that wants to join the VPN, and the certificates can get signed by the CA and returned. (The easy-rsa package has been split out of the openvpn package in Debian unstable, which makes this more understandable.) Is there a security benefit? You could argue that if your VPN server has been compromised, then you are already in trouble. But I'm thinking about a setup where I could run multiple VPN servers for redundancy, signed by the same CA - then if one server gets broken into, you could kill it without having to revoke all the client keys. By the way, the default RSA key size used by easy-rsa is 1024 bits at the time of writing (fixed upstream: Debian bug #733905). This is simple to change, but you need to know to do it. One of the 30c3 lightning talks was about bettercrypto.org - a guide to which cryptography settings to choose for commonly used software.

Implementing software to replace legacy systems is always a challenge, especially when you're dealing with a system with as much legacy as sendmail, which was first introduced as delivermail in 1979.^ref

Each UNIX vendor, it seems, rewrote or heavily customized sendmail. This has lead to sometimes conflicting implementations.
Case in point: -tNormally, you invoke sendmail(8) with a series of arguments indicating the subject of a message, the recipients, etc. When invoked this way, the command expects a message on standard input, waits for EOF, and then sends your message along.

However, sometimes you don't want to have to fiddle with command-line parameters; you've already written a perfectly fine message with headers.

-t is generally passed to sendmail when you want to build a message envelope from an already-formatted message, with headers, etc. For example, if you had a file foo.txt with a body like this:

From: Luke Faraone 
To: John Smith 
Subject: Hello, world!

Hi there.

you could send the message with a simple invocation of cat foo.txt sendmail -t. The system would take care of ensuring a Message-id was appended if appropriate, and queue the message to be sent. However, it is when you do slightly more complex invocations of sendmail that things get ambiguous.

It turns out that implementations differ on what exactly it means when you use -t in combination with naming destination addresses after the arguments to sendmail. exim4's documentation describes the situation in greater detail:

Thus, there's basically no mechanism for a program to know which behaviour to expect. God forbid two programs are installed on a system that expect different behaviours!

It appears that the default behaviour of Ruby is the opposite of what exim4 (Debian's default mail client) expects. This has resulted in numerous bug reports. Some replies suggest changing exim4's defaults, while others advocate overriding ActionMailer and friends to use sendmail -i instead, without -t.

That said, its not really clear who's wrong here; at no point does there appear to have been a definitive specification for sendmail, and as such we can hope for defined behaviour by common custom at best, and a sea of incompatibility bugs at worst. Amusingly, POSIX standards have nothing to say on this subject of sendmail at all; it defines that a mailx command must exist, but says that its sending mode may be implementation-specific.

As Matthew Garrett writes, there's not enough gin in the world.

Pixmap ID Lifetimes under Present Redirection (Part Deux) I recently wrote about pixmap content and ID lifetimes. I think the pixmap content lifetime stuff was useful, but the pixmap ID stuff was not quite right. I ve just copied the section from the previous post and will update it. PresentRedirect pixmap ID lifetimes (reprise) A compositing manager will want to know the lifetime of the pixmaps delivered in PresentRedirectNotify events to clean up whatever local data it has associated with it. For instance, GL compositing managers will construct textures for each pixmap that need to be destroyed when the pixmap disappears. Present encourages pixmap destruction The PresentPixmap request says:

PresentRegion holds a reference to pixmap until the presentation occurs, so pixmap may be immediately freed after the request executes, even if that is before the presentation occurs.

Breaking this when doing Present redirection seems like a bad idea; it s a very common pattern for existing 2D applications. New pixmap IDs for everyone Because pixmap IDs for present contents are owned by the source application (and may be re-used immediately when freed), Present can t use that ID in the PresentRedirectNotify event. Instead, it must allocate a new ID and send that instead. The server has it s own XID space to use, and so it can allocate one of those and bind it to the same underlying pixmap; the pixmap will not actually be destroyed until both the application XID and the server XID are freed. The compositing manager will receive this new XID, and is responsible for freeing it when it doesn t need it any longer. Of course, if the compositing manager exits, all of the XIDs passed to it will automatically be freed. I considered allocating client-specific XIDs for this purpose; the X server already has a mechanism for allocating internal IDs for various things that are to be destroyed at client shut-down time. Those XIDs have bit 30 set, and are technically invalid XIDs as X specifies that the top three bits of every XID will be zero. However, the cost of using a server ID instead (which is a valid XID) is small, and it s always nice to not intentionally break the X protocol (even as we continue to take advantage of accidental breakages). (Reserving the top three bits of XIDs and insisting that they always be zero was a nod to the common practice of weakly typed languages like Lisp. In these languages, 32-bit object references were typed by using few tag bits (2-3) within the value. Most of these were just pointers to data, but small integers, that fit in the remaining bits (29-30), could be constructed without allocating any memory. By making XIDs only 29 bits, these languages could be assured that all XIDs would be small integers.) Pixmap Destroy Notify The Compositing manager needs to know when the application is done with the pixmap so that it can clean up when it is also done; destroying the extra pixmap ID it was given and freeing any other local resources. When the application sends a FreePixmap request, that XID will become invalid, but of course the pixmap itself won t be freed until the compositing manager sends a FreePixmap request with the extra XID it was given. Because the pixmap ID known by the compositing manager is going to be different from the original application XID, we need an event delivered to the compositing manager with the new XID, which makes this event rather Present specific. We don t need to select for this event; the compositing manager must handle it correctly, so we ll just send it whenever the composting manager has received that custom XID. PresentPixmapDestroyNotify

 
    PresentPixmapDestroyNotify
    type: CARD8         XGE event type (35)
    extension: CARD8        Present extension opcode
    sequence-number: CARD16
    length: CARD32          0
    evtype: CARD16          Present_PixmapDestroyNotify
    eventID: XFIXESEVENTID
    event-window: WINDOW
    pixmap: pixmap
 

This event is delivered to the clients selecting for SubredirectNotify for pixmaps which were delivered in a PresentRedirectNotify event and for which the originating application Pixmap has been destroyed. Note that the pixmap may still be referenced by other objects within the X server, by a pending PresentPixmap request, as a window background, GC tile or stipple or Picture drawable (among others), but this event serves to notify the selecting client that the application is no longer able to access the underlying pixmap with it s original Pixmap ID.

In order to get closer to my goal of reducing my dependence on centralized services, I decided to setup my own XMPP / Jabber server on a Linode VPS running Debian wheezy. I chose ejabberd since it was recommended by the RTC Quick Start website and here's how I put everything together.

DNS and SSL My personal domain is fmarier.org and so I created the following DNS records:

jabber-gw            CNAME    fmarier.org.
_xmpp-client._tcp    SRV      5 0 5222 jabber-gw.fmarier.org.
_xmpp-server._tcp    SRV      5 0 5269 jabber-gw.fmarier.org.

Then I went to get a free XMPP SSL certificate for jabber-gw.fmarier.org from StartSSL. This is how I generated the CSR (Certificate Signing Request) on a high-entropy machine:

openssl req -new -newkey rsa:2048 -nodes -out ssl.csr -keyout ssl.key -subj "/C=NZ/CN=jabber-gw.fmarier.org"

I downloaded the signed certificate as well as the StartSSL intermediate certificate and combined them this way:

cat ssl.crt ssl.key sub.class1.server.ca.pem > ejabberd.pem

ejabberd installation Installing ejabberd on Debian is pretty simple and I mostly followed the steps on the Ubuntu wiki with an additional customization to solve the Pidgin "Not authorized" connection problems.

1. Install the package, using "admin" as the username for the administrative user:

   apt-get install ejabberd
   

2. Set the following in /etc/ejabberd/ejabberd.cfg (don't forget the trailing dots!):

    acl, admin,  user, "admin", "fmarier.org" .
    hosts, ["fmarier.org"] .
    fqdn, "jabber-gw.fmarier.org" .
   

3. Copy the SSL certificate into the /etc/ejabberd/ directory and set the permissions correctly:

   chown root:ejabberd /etc/ejabberd/ejabberd.pem
   chmod 640 /etc/ejabberd/ejabberd.pem
   

4. Restart the ejabberd daemon:

   /etc/init.d/ejabberd restart
   

5. Create a new user account for yourself:

   ejabberdctl register me fmarier.org P@ssw0rd1!
   

6. Open up the following ports on the server's firewall:

   iptables -A INPUT -p tcp --dport 5222 -j ACCEPT
   iptables -A INPUT -p tcp --dport 5269 -j ACCEPT
   

Client setup On the client side, if you use Pidgin, create a new account with the following settings in the "Basic" tab:

• Protocol: XMPP
• Username: me
• Domain: fmarier.org
• Password: P@ssw0rd1!

and the following setting in the "Advanced" tab:

• Connection security: Require encryption

From this, I was able to connect to the server without clicking through any certificate warnings. If you want to make sure that XMPP federation works, add your GMail address as a buddy to the account and send yourself a test message. In this example, the XMPP address I give to my friends is me@fmarier.org.

What a strange year. 2013 was marked by a whole sequence of entirely unexpected events, including multiple major work upheavals. For large chunks of the year, I had very little time or emotional energy for personal reading goals, and particularly for writing reviews. I declared personal amnesty on most of my intentions halfway through the year, and all the totals will reflect that. On the plus side (although not for reading and reviews), it was a great year for video games. Next year, there will be no specific goals. Between continuing work fallout, a very busy project schedule, my intent to keep playing a lot of video games, and various other personal goals I want to take on, I'm going to take the pressure off of reading. Things will be read and reviews will be written (and I'm going to make more of an effort to write reviews shortly after reading books), but I'm not going to worry about how many. The below statistics are confined to the books I reviewed in 2013. I read six more books that I've not yet reviewed, due to the chaos at the end of the year. Those will be counted in 2014. There were no 10 out of 10 books this year, partly due to the much lower reading totals and partly due to my tendency this year to turn to safe comfort reading, which is reliably good but unlikely to be exceptional. There were, however, several near-misses that were worth calling out. My favorite book of the year was Neal Stephenson's Anathem, which narrowly missed a 10 for me due to some fundamental problems with the plot premise. But this is still an excellent book: the best novel about the practice of science and philosophy that I've ever read. Also deserving mention are K.E. Lane's And Playing the Role of Herself, lovely and intelligent lesbian romance that's likely to appeal even to people who would not normally try that genre, and Guy Gavriel Kay's River of Stars. The latter isn't quite at the level of Kay's earlier Under Heaven, but it's still an excellent work of alternate historical fiction in a memorable setting. A special honorable mention goes to Lisa O'Donnell's The Death of Bees. It requires a lot of warnings for very dark subject matter and a rather abrupt ending, but it's been a long time since I've cared that much about the characters of a book. My favorite non-fiction book of the year was Gary J. Hudson's They Had to Go Out, a meticulously researched account of a tragic Coast Guard mission. The writing is choppy, the editing could have been better, and it's clear that the author is not a professional writer, but it's the sort of detailed non-fiction account that can only be written by someone who's been there and lived through similar experiences. Also worth mentioning is Mark Jason Dominus's Higher Order Perl, which was the best technical book I read all year and which I found quite inspiring for my own programming. The full analysis includes some additional personal reading statistics, probably only of interest to me.

I recently blogged about the GeoDNS setup we plan for security.debian.org. Even though all DSA team members agree that the GeoDNS setup for security.debian.org should come alive as soon as possible, we still fear to break an important service like security.d.o. Yesterday I decided without further ado to float a trial balloon and converted DNS entries for the Debian Project homepage to our GeoDNS setup. While doing so, we found out that some part of our automatic deployment scripts still need to be adjusted to serve more than one subdomain of the project. That setup is live for about eighteen hours now, and the project homepage now resolves it IPs via GeoDNS. For now, we are using senfl.d.o for Northern America, www.de.debian.org and www.debian.at for Europe and klecker.d.o for the rest of the world. From what I can see from GeoDNS logs, it seems to work fine, and the load stays reasonably low, so after a short test period we might add additional services like security.debian.org to GeoDNS.

We are re-purposing raff.debian.org as a new security mirror to be shipped to South America. The raff.debian.org most of you have used as buildd.debian.org in the past will cease to exist in the near future. raff.debian.org will cease acting as a dns server for the debian.org zone in a few days, therfore we will add two new hosts, senfl.d.o and ravel.d.o. All other services formerly hosted on raff.d.o should have been already moved by now, we just want to encourage those of you who had a login on raff, to backup your home directory if you care of the data stored there, as we will not move that. Current plan is to shut down current raff by end of the year (so in about 7 days).

The Debian Project currently runs about 100 machines all over the world with different services. Those are mainly managed by the Debian System Administration team. For central configuration management we use Puppet. The Puppet config we use is publicly available here. Our next goal is to have a more or less central configuration of our iptables rules on all those machines. Some of the machines have home-brewed firewall scripts, some use ferm. Your mission, if you choose to accept it, is to provide us with a new dsa-puppet git branch with a module "ferm" that we can roll out to all our hosts. It might want to use information from the other puppet modules like "apache2_security_mirror" or "buildd" to decide which incoming traffic should be allowed. DSA will of course provide you with all necessary further information.

We are in the process of deploying DNSSEC, the DNS Security Extensions, on the Debian zones. This means properly configured resolvers will be able to verify the authenticity of information they receive from the domain name system. The plan is to introduce DNSSEC in several steps so that we can react to issues that arise without breaking everything at once. We will start with serving signed debian.net and debian.com zones. Assuming nobody complains loudly enough the various reverse zones and finally the debian.org zone will follow. Once all our zones are signed we will publish our trust anchors in ISC's DLV Registry, again in stages. The various child zones that are handled differently from our normal DNS infrastructure (mirror.debian.net, alioth, bugs, ftp, packages, security, volatile, www) will follow at a later date. We are using bind 9.6 for NSEC3 support and our fork of RIPE's DNSSEC Key Management Tools for managing our keys because we believe that it integrates nicely with our existing DNS helper scripts, at least until something better becomes available. We will use NSEC3RSASHA1 with key sizes of 1536 bits for the KSK and 1152 bits for the ZSK. Signature validity period will most likely be four weeks, with a one week signature publication period (cf. RFC4641: DNSSEC Operational Practices). Zone keys rollovers will happen regularly and will not be announced in any specific way. Key signing key rollovers will probably be announced on the debian-infrastructure-announce list until such time that our zones are reachable from a signed root. KSK rollovers for our own child zones (www.d.o et al.), once signed, will not be announced because we can just put proper DS records in the respective parent zone. Until we announce the first set of trust anchors on the mailinglist the keysets present in DNS should be considered experimental. They can be changed at any time, without observing standard rollover practices. Please direct questions or comments to either the debian-admin or, if you want a more public forum, the debian-project list at lists.debian.org. See also:

• DNSSEC wikipedia page,
• DNSSEC HOWTO, a tutorial in disguise (Olaf Kolkman, nlnetlabs).

-- Peter Palfrader

While setting up GeoDNS for parts of the debian.org zone, we set up a new subzone security.geo.debian.org. This was mainly due to the fact we didn't want to mess up the existing zone while experimenting with GeoDNS. Now that our GeoDNS setup has been working for more than half a year without any problems, we will drop this zone. We will do that in two phases.

Phase 1 Beginning on July 1st, we will redirect all requests to security.geo.debian.org to a static webpage indicating that this subzone is deprecated and should not be used any more. If you still have security.geo.debian.org in your apt sources.list, updates will fail.

Phase 2 On August 1st, we will stop serving the subzone security.geo.debian.org from our DNS servers.

Conclusion In case you use a security.geo.debian.org entry in your /etc/apt/sources.list, now is the best time to change that entry to security.debian.org. Both zones currently serve the same content.