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.

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.

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

Yet another yearly summary of my running activities. As I already explained, now running took precedence over free software activities as you'll notice below... So, what happened on that front in 2013 for running bubulle? I finally managed to run 4603 km during the year, which is 1700km more than 2012. Definitively an explosion as I actually ran over 12.5km every day. I added to this 206km with my moutain bike, all of them achieved during December while I was (and still am) suffering from an injury (fatigue fracture). These 4603km were covered in 458 hours, so a bit over 19 days running and very very slightly over 10km/h.

• 2061 kilometers training on hard (and mostly flat) soil (road running). Mostly my daily commute runs.
• 1977 kilometers training on trail running (either in the country, woods, forests, or in moutains). Mostly my week-end (and holidays, and DebConf...) runs.
• 85 kilometers competition on roads (indeed own marathon and two half-marathons)
• 471 kilometers competition in trail running

It seems that my favourite race type choice is obvious, here: I'm, by very far, privileging, trail races, either in the country or forests in my neighbourhood....or in moutains. As a result, also, the combined positive climb is faily high, too. Though harder to estimate than distance and time, I end up with about 72,900 meters positive climb (to be compared to last year's 33,000 meters...:-)). Clearly, my summer in moutains made the difference, here.... The longest time period without running, this year, has been 3 days. That's really insane...:-). Particularly when one notices that I happened to run *every day* during 40 consecutive days at one moment, between August and September. Who says that running is indeed a full part of my life? To be honest, I actually didn't run since December 11th (while writing this on January 1st) because of my tibia injury...but I did bike, so that's still some kind of sports, right? Indeed, there have been 282 days in this year where I ran (or biked) at least once. Last year was 205 so....drug addiction is still increasing. Most active month: November with 471km. Less active month: February with 334km (which is indeed more than 2012 most active month..:-)) This year was also a year of records:

• half-marathon personal best with 1h34' in September at Bois d'Arcy (down by 3 minutes)
• marathon personal best with 3h25'19" in October in Toulouse (down by 8 minutes)
• once again, great progress in my 3rd consecutive Le Puy-Firminy race which I ran in 7h15 instead of 8h22 last year. Same progress for 80km Ecotrail with 9h36 instead of 11h05 the year before

I ran 14 official races during the year :

• four "ultra" races: 75km Saint lyon in December, by night, 70km Le Puy-Firminy in November, by night, 50km Cenis Trail in August (moutain race) and 80km Paris Ecotrail in March
• two "maratrails": Chamonix Marathon du Mont-Blanc, 42km, and Trail des Lavoirs in Chevreuse, 44km
• one marathon: Toulouse
• two 35km trail races
• two half-marathons
• three trail races around 20km.

How about next^W this year? Well, my season's peaks are currently being secured:

• Paris 80km Ecotrail again in March. Followed, the next Sunday, by the Paris Marathon, which I'll run dressed as Spongebob...:-)
• Trail des Cerfs (50km trail race in Rambouillet Forest, close to my place), in May
• Montagn'hard 60 kilometers moutain trail race in French Alps (with 5000 meters positive climb), in July
• Courmayeur-Champeix-Chamonix, one of the 4 races of the Ultra Trail du Mont-Blanc week in Chamonix, in late August (yes, during DebConf 14!). 101km and 6100m positive climb. This is assuming that I'm lucky to get picked at the lottery (there are too many peopl who want to run this race). If I'm not....I'll probably pick another 100km moutain race somewhere in French Alps in late August
• Saint Urban Trail in October: a "trail" race over the hills of Saint- tienne, my birth city, for about 30 kilometers and 1000m positive climb (and gazillion of steps). Back to roots!
• Le Puy-Firminy 70km again in November. 4th time in a row. Will I again run it in one hour less than the year before? Probably hard to imagine.
• Origole trail race: one of the most difficult trail races in France : 75 kilometers and 2000m positive climb in Rambouillet Forest, close to Paris, by night. Usually incredibly muddy and cold.

No marathon as of now...:-). Or, indeed one (Paris in April), but more for fun : I hope to complete it in....less than 5 hours...but still in Spongebob Squarepants suit. You may want to watch TV on April 6th..:-) As I wrote last year : all this of course is assuming that no injury comes up. I currently need to recover from the current one, though it doesn't seem as bad as it seemed a few weeks ago. We'll see on January 1st 2015...:-)

Good morning all my hungover friends. New Hy release - sounds like the perfect thing to do while you re waiting for your headaches to go away. Here s a short-list of the changes (from NEWS) - enjoy!

Changes from Hy 0.9.11
   tl;dr:
    0.9.12 comes with some massive changes,
    We finally took the time to implement gensym, as well as a few
    other bits that help macro writing. Check the changelog for
    what exactly was added. 
    
    The biggest feature, Reader Macros, landed later
    in the cycle, but were big enough to warrent a release on it's
    own. A huge thanks goes to Foxboron for implementing them
    and a massive hug goes out to olasd for providing ongoing
    reviews during the development.
    
    Welcome to the new Hy contributors, Henrique Carvalho Alves,
    Kevin Zita and Kenan B l kba . Thanks for your work so far,
    folks!
    
    Hope y'all enjoy the finest that 2013 has to offer,
      - Hy Society
    * Special thanks goes to Willyfrog, Foxboron and theanalyst for writing
      0.9.12's NEWS. Thanks, y'all! (PT)
    [ Language Changes ]
    * Translate foo? -> is_foo, for better Python interop. (PT)
    * Reader Macros!
    * Operators + and * now can work without arguments
    * Define kwapply as a macro
    * Added apply as a function
    * Instant symbol generation with gensym
    * Allow macros to return None
    * Add a method for casting into byte string or unicode depending on python version
    * flatten function added to language
    * Add a method for casting into byte string or unicode depending on python version
    * Added type coercing to the right integer for the platform
    [ Misc. Fixes ]
    * Added information about core team members
    * Documentation fixed and extended
    * Add astor to install_requires to fix hy --spy failing on hy 0.9.11.
    * Convert stdout and stderr to UTF-8 properly in the run_cmd helper.
    * Update requirements.txt and setup.py to use rply upstream.
    * tryhy link added in documentation and README
    * Command line options documented
    * Adding support for coverage tests at coveralls.io
    * Added info about tox, so people can use it prior to a PR
    * Added the start of hacking rules
    * Halting Problem removed from example as it was nonfree
    * Fixed PyPI is now behind a CDN. The --use-mirrors option is deprecated.
    * Badges for pypi version and downloads.
    [ Syntax Fixes ]
    * get allows multiple arguments
    [ Bug Fixes ]
    *  OSX: Fixes for readline Repl problem which caused HyREPL not allowing 'b'
    * Fix REPL completions on OSX
    *  Make HyObject.replace more resilient to prevent compiler breakage.
    [ Contrib changes ]
    * Anaphoric macros added to contrib
    * Modified eg/twisted to follow the newer hy syntax
    * Added (experimental) profile module

As I watch my friends and enemies rush to make their 501(c)3-qualified donations before midnight, I think to ask, What if, instead of giving to these fat, corrupt organizations that are rolling in money and waste most of it, you gave to the FSF, the SFLC, or the Tor project?

In late October, the FSF posted this video of a talk called When Free Software Isn t (Practically) Better that I gave at LibrePlanet earlier in the year. I noticed it was public when, out of the blue, I started getting both a bunch of positive feedback about the talk as well as many people pointing out that my slides (which were rather important) were not visible in the video! Finally, I ve managed to edit together a version that includes the slides and posted it online and on Youtube. The talk is very roughly based on this 2010 article and I argue that, despite our advocacy, free software isn t always (or even often) better in practical terms. The talk moves beyond the article and tries to be more constructive by pointing to a series of inherent practical benefits grounded in software freedom principles and practice. Most important to me though, the talk reflects my first serious attempt to bring together some of the findings from my day job as a social scientist with my work as a free software advocate. I present some nuggets from my own research and talk about about what they mean for free software and its advocates. In related news, it also seems worth noting that I m planning on being back at LibrePlanet this March and that the FSF annual fundraiser is currently going on.

Review: The Incrementalists, by Steven Brust & Skyler White

Publisher:	Tor
Copyright:	September 2013
ISBN:	0-7653-3422-4
Format:	Hardcover
Pages:	304

The Incrementalists are a secret society that has been in continuous existence for forty thousand years. The members are immortal... sort of (more on that in a moment). They are extremely good at determining what signals, triggers, and actions have the most impact on people, and adept at using those triggers to influence people's behavior. And they're making the world better. Not in any huge, noticeable way, just a little bit, here and there. Incrementally. Brust and White completely had me with this concept. There are several SF novels about immortals, but (apart from the vampire subgenre) they mostly stay underground and find ways to survive without trying to change the surrounding human society. I love the idea of small, incremental changes, and I was looking forward to reading a book about how that would work. How do they choose what to do? How do they find the right place to push? What long-term goals would such an organization pursue, and what governance structure would they use? I'm still wondering about most of those things, sadly, since that isn't what this novel is about at all. I should be fair: a few of those questions hover in the background. There are some political arguments (that parallel arguments on Brust's blog), and a tiny bit about governance. But mostly this is a sort of romance, a fight over identity, and an extensive exploration of the mental "garden" that the Incrementalists use and build to hold their memories and share information with each other. The story revolves around two Incrementalists: Phil, who is one of the leaders and has one of the longest continuous identities of any of the group, and Renee, a new recruit by Phil who picks up the memories and capabilities (sort of) of the recently-deceased Incrementalist Celeste. Phil is the long-term insider, although a fairly laid-back one. Renee is the outsider, the one to which the story is happening at the beginning, who is taught how the Incrementalists' system works. The Incrementalists is told in alternating first-person viewpoint sections by Phil and Renee (making me wonder if the characters were each written by one of the authors). Once I got past my disappointment over this book not being quite what I wanted, the identity puzzles that Brust and White play with here caught my attention. The underlying "magic" of the Incrementalists is based on the "memory palace" concept of storing memories via visualizations, but takes it into something akin to personal alternate worlds. Their immortality isn't through physical immortality, but rather the ability to store their memories and personality in their garden, which is their term for the memory palace, and then have it imposed on someone else: a combination of reincarnation, mental takeover, and mental merging. This makes for complex interpersonal relationships and complex interactions between memory, belief, and identity, not to mention some major ethical issues, which come to a head in Phil and Renee's relationship and Celeste's lingering meddling. I think Brust and White are digging into some interesting questions of character here. There's a lot of emphasis in The Incrementalists on the ease with which people can be manipulated, and the Incrementalists themselves are far from immune. Choice and personal definition are both questionable concepts given how much influence other people have, how many vulnerabilities everyone carries with them, and how much one's opinions are governed by one's life history. That makes identity complex, and raises the question of whether one can truly define oneself. But, while all these ideas are raised, I think The Incrementalists dances around them more than engages them directly. It's similar to the background hook: yes, these people are slowly improving the world, and we see a little bit of that (and a little bit of them manipulating people for their own convenience), but the story doesn't fully engage with the idea. There's a romance, a few arguments, some tension, some world-building, but I don't feel like this book ever fully committed to any of them. One of the occasional failure modes of Brust for me is insufficient explanation and insufficient clarity, and I hit that here. My final impression of The Incrementalists is interesting, enjoyable, but vaguely disappointing. It's still a good story with some interesting characters and nice use of the memory palace concept, and I liked Renee throughout (although I think the development of the love story is disturbingly easy and a little weird). But I can't strongly recommend it, and I'm not sure if it's worth seeking out. Rating: 7 out of 10

This turned out to be a more substantial release than I was originally planning. lbcd is a small daemon that listens to UDP queries and returns system load and usage information and, optionally, service availability. It's designed to work with a software DNS-based load-balancing system that we use at Stanford (lbnamed), but it can also be used in other situations where you want to easily and quickly query the load of systems remotely. Debian is currently debating which new init system to adopt, and lbcd was my test package for adding upstart and systemd support. The goal was to add proper, full support as described by upstream, making use of all relevant features, so that I could get some experience with a complete integration. That is complete in this version: lbcd now supports both systemd's and upstart's readiness synchronization mechanisms (using a -Z flag to raise SIGSTOP for upstart) and supports socket activation with systemd. (upstart's socket activation support is missing numerous features, including IPv6 support and, fatally, SOCK_DGRAM support.) It also installs systemd unit files directly when built on a system with systemd support, which should make life easier for use on Red Hat versions later regardless of what happens with Debian. Of course, while doing that, I kept running across other things that needed to be fixed. For example, systemd's socket activation provides proper support for IPv6, so lbcd should as well. That's now present; that was something I'd been planning on doing for some time. It also supports a -f option to run in the foreground but still log to syslog, something needed by both upstart and systemd to avoid having to use PID files. Since PID files are no longer necessary, lbcd no longer writes one by default (an idiosyncratic choice made by the previous maintainer), and also drops the -s and -r options to stop and restart itself. Adding these to each daemon was an interesting approach, but I think it's better to leave this to the init system. While working on the code, I discovered that lbcd allowed the client to request any of the built-in service probes be run, which meant that a client could cause TCP connects to random local services. While this probably couldn't do any harm other than a DoS attack, it still seemed like a bad idea, and was a "feature" I didn't realize was there. Now, only services specified with the -w or -a options may be queried by a client. I also finally implemented the -l option, which logs each client query, and improved lbcd's recognition of whether someone is on console to allow for modern display manager sessions. The simple client included in the package, lbcdclient, has been completely rewritten using modern Perl. It supports long options, setting the timeout, setting the port, and returns an error on timeout. It no longer supports multiple servers to query on the command line, since the output just gets confusing and I don't think anyone used this feature. It also now supports IPv6 if IO::Socket::INET6 is available. Finally, a typo that prevented compilation on Mac OS X has been fixed. You can get the latest version from the lbcd distribution page.

Object Lifetimes under Present Redirection Present extension redirection passes responsibility for showing application contents from the X server to the compositing manager. This eliminates an extra copy to the composite extension window buffer and also allows the application contents to be shown in the right frame. (Currently, the copy from application buffer to window buffer is synchronized to the application-specified frame, and then a Damage event is delivered to the compositing manager which constructs the screen image using the window buffer and presents that to the screen at least one frame later, which generally adds another frame of delay for the application.) The redirection operation itself is simple just wrap the PresentPixmap request up into an event and send it to the compositing manager. However, the pixmap to be presented is allocated by the application, and hence may disappear at any time. We need to carefully control the lifetime of the pixmap ID and the specific frame contents of the pixmap so that the compositing manager can reliably construct complete frames. We ll separately discuss the lifetime of the specific frame contents from that of the pixmap itself. By the frame contents , I mean the image, as a set of pixel values in the pixmap, to be presented for a specific frame. Present Pixmap contents lifetime After the application is finished constructing a particular frame in a pixmap, it passes the pixmap to the X server with PresentPixmap. With non-redirected Present, the X server is responsible for generating a PresentIdleNotify event once the server is finished using the contents. There are three different cases that the server handles, matching the three different PresentCompleteModes:

1. Copy. The pixmap contents are not needed after the copy operation has been performed. Hence, the PresentIdleNotify event is generated when the target vblank time has been reached, right after the X server calls CopyArea
2. Flip. The pixmap is being used for scanout, and so the X server won t be done using it until some other scanout buffer is selected. This can happen as a result of window reconfiguration which makes the displayed window no longer full-screen, but the usual case is when the application presents a subsequent frame for display, and the new frame replaces the old. Thus, the PresentIdleNotify event generally occurs when the target vblank time for the subsequent frame has been reached, right after the subsequent frame s pixmap has been selected for scanout.
3. Skip. The pixmap contents will never be used, and the X server figures this out when a subsequent frame is delivered with a matching target vblank time. This happens when the subsequent Present operation is queued by the X server.

In the Redirect case, the X server cannot tell when the compositing manager is finished with the pixmap. The same three cases as above apply here, but the results are slightly different:

1. Composite. The pixmap is being used as a part of the screen image and must be composited with other window pixmaps. In this case, the compositing manager will need to hold onto the pixmap until a subsequent pixmap is provided by the application. Thus, the pixmap will remain needed by the compositing manager until it receives a subsequent PresentRedirectNotify for the same window.
2. Flip. The compositing manager is free to take the application pixmap and use it directly in a subsequent PresentPixmap operation and let the X server flip to it; this provides a simple way of avoiding an extra copy while not needing to fuss around with unredirecting windows. In this case, the X server will need the pixmap contents until a new scanout pixmap is provided, and the compositing manager will also need the pixmap in case the contents are needed to help construct a subsequent frame.
3. Skip. In this case, the compositing manager notices that the window s pixmap has been replaced before it was ever used.

In case 2, the X server and the compositing manager will need to agree on when the PresentIdleNotify event should be delivered. In the other two cases, the compositing manager itself will be in charge of that. To let the compositing manager control when the event is delivered, the X server will count the number of PresentPixmap redirection events sent, and the compositing manager will deliver matching PresentIdle requests. PresentIdle

 
    PresentIdle
    pixmap: PIXMAP
 
Errors: Pixmap, Match

Informs the server that the Pixmap passed in a PresentRedirectNotify event is no longer needed by the client. Each PresentRedirectNotify event must be matched by a PresentIdle request for the originating client to receive a PresentIdleNotify event. PresentRedirect pixmap ID lifetimes 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. Some kind of PixmapDestroyNotify event is necessary for this; the alternative is for the compositing manager to constantly query the X server to see if the pixmap IDs it is using are still valid, and even that isn t reliable as the application may re-use pixmap IDs for a new pixmap. It seems like this PixmapDestroyNotify event belongs in the XFixes extension it s a general mechanism that doesn t directly relate to Present. XFixes doesn t currently have any Generic Events associated, but adding that should be fairly straightforward. And then, have the Present extension automatically select for PixmapDestroyNotify events when it delivers the pixmap in a PresentRedirectNotify event so that the client is ensured of receiving the associated PixmapDestroyNotify event. One remaining question I have is whether this is sufficient, or if the compositing manager needs a stable pixmap ID which lives beyond the life of the application pixmap ID. If so, the solution would be to have the X server allocate an internal ID for the pixmap and pass that to the client somehow; presumably in addition to the original pixmap ID. XFixesPixmapSelectInput

XFIXESEVENTID   XID  
    Defines a unique event delivery target for Present
    events. Multiple event IDs can be allocated to provide
    multiple distinct event delivery contexts.
PIXMAPEVENTS   XFixesPixmapDestroyNotify  
 
    XFixesPixmapSelectInput
    eventid: XFIXESEVENTID
    pixmap: PIXMAP
    events: SETofPIXMAPEVENTS
 
Errors: Pixmap, Value

Changes the set of events to be delivered for the target pixmap. A Value error is sent if events contains invalid event selections. XFixesPixmapDestroyNotify

 
    XFixesPixmapDestroyNotify
    type: CARD8         XGE event type (35)
    extension: CARD8        XFixes extension request number
    sequence-number: CARD16
    length: CARD32          0
    evtype: CARD16          XFixes_PixmapDestroyNotify
    eventID: XFIXESEVENTID
    pixmap: pixmap
 

This event is delivered to all clients selecting for it on pixmap when the pixmap ID is destroyed by a client. Note that the pixmap may still be referenced by other objects within the X server, as a window background, GC tile or stipple or Picture drawable (among others), but this event serves to notify the selecting client that the ID is no longer associated with the underlying pixmap.

The Debian Edu / Skolelinux project consist of both newcomers and old timers, and this time I was able to get an interview with a newcomer in the project who showed up on the IRC channel a few weeks ago to let us know about his successful installation of Debian Edu Wheezy in his School. Say hello to Dominik George. Who are you, and how do you spend your days? I am a 23 year-old student from Germany who has spent half of his life with open source. In "real life", I am, as already mentioned, a student in the fields of Computer Science, Electrical Engineering, Information Technologies and Anglistics. Due to my (only partially voluntary) huge engagement in the open source world, these things are a bit vacant right now however. I also have been working as a project teacher at a Gymasnium (public school) for various years now. I took up that work some time around 2005 when still attending that school myself and have continued it until today. I also had been running the (kind of very advanced) network of that school together with a team of very interested and talented students in the age of 11 to 15 years, who took the chance to learn a lot about open source and networking before I left the school to help building another school's informational education concept from scratch. That said, one might see me as a kind of "glue" between school kids and the elderly of teachers as well as between the open source ecosystem and the (even more complex) educational ecosystem. When I am not busy with open source or education, I like Geocaching and cycling. How did you get in contact with the Skolelinux / Debian Edu project? I think that happened some time around 2009 when I first attended FrOSCon and visited the project booth. I think I wasn't too interested back then because I used to have an attitude of disliking software that does too much stuff on its own. Maybe I was too inexperienced to realise the upsides of an "out-of-the-box" solution ;). The first time I actively talked to Skolelinux people was at OpenRheinRuhr 2011 when the BiscuIT project, a home-grewn software used by my school for various really cool things from timetables and class contact lists to lunch ordering, student ID card printing and project elections first got to a stage where it could have been published. I asked the Skolelinux guys running the booth if the project were interested in it and gave a small demonstration, but there wasn't any real feedback and the guys seemed rather uninterested. After I left the school where I developed the software, it got mostly lost, but I am now reimplementing it for my new school. I have reusability and compatibility in mind, and I hop there will be a new basis for contributing it to the Skolelinux project ;)! What do you see as the advantages of Skolelinux / Debian Edu? The most important advantage seems to be that it "just works". After overcoming some minor (but still very annoying) glitches in the installer, I got a fully functional, working school network, without the month-long hassle I experienced when setting all that up from scratch in earlier years. And above that, it rocked - I didn't have any real hardware at hand, because the school was just founded and has no money whatsoever, so I installed a combined server (main server, terminal services and workstation) in a VM on my personal notebook, bridging the LTSP network interface to the ethernet port, and then PXE-booted the Windows notebooks that were lying around from it. I could use 8 clients without any performance issues, by using a tiny little VM on a tiny little notebook. I think that's enough to say that it rocks! Secondly, there are marketing reasons. Life's bad, and so no politician will ever permit a setup described as "Debian, an universal operating system, with some really cool educational tools" while they will be jsut fine with "Skolelinux, a single-purpose solution for your school network", even if both turn out to be the very same thing (yes, this is unfair towards the Skolelinux project, and must not be taken too seriously - you get the idea, anyway). What do you see as the disadvantages of Skolelinux / Debian Edu? I have not been involved with Skolelinux long enough to really answer this question in a fair way. Thus, please allow me to put it in other words: "What do you expect from Skolelinux to keep liking it?" I can list a few points about that:

• always strive to get all things integrated into Debian upstream
• be open to discussion about changes and the like, even with newcomers
• be helpful at being helpful ;)

I'm really sorry I cannot say much more about that :(! Which free software do you use daily? First of all, all software I use is free and open. I have abandoned all non-free software (except for firmware on my darned phone) this year. I run Debian GNU/Linux on all PC systems I use. On that, I mostly run text tools. I use mksh as shell, jupp as very advanced text editor (I even got the developer to help me write a script/macro based full-featured student management software with the two), mcabber for XMPP and irssi for IRC. For that overly coloured world called the WWW, I use Iceweasel (Firefox). Oh, and mutt for e-mail. However, while I am personally aware of the fact that text tools are more efficient and powerful than anything else, I also use (or at least operate) some tools that are suitable to bring open source to kids. One of these things is Jappix, which I already introduced to some kids even before they got aware of Facebook, making them see for themselves that they do not need Facebook now ;). Which strategy do you believe is the right one to use to get schools to use free software? Well, that's a two-sided thing. One side is what I believe, and one side is what I have experienced. I believe that the right strategy is showing them the benefits. But that won't work out as long as the acceptance of free alternatives grows globally. What I mean is that if all the kids are almost forced to use Windows, Facebook, Skype, you name it at home, they will not see why they would want to use alternatives at school. I have seen students take seat in front of a fully-functional, modern Debian desktop that could do anything their Windows at home could do, and they jsut refused to use it because "Linux sucks". It is something that makes the council of our city spend around 600000 to buy software - not including hardware, mind you - for operating school networks, and for installing a system that, as has been proved, does not work. For those of you readers who are good at maths, have you already found out how many lives could have been saved with that money if we had instead used it to bring education to parts of the world that need it? I have, and found it to be nothing less dramatic than plain criminal. That said, the only feasible way appears to be the bottom up method. We have to bring free software to kids and parents. I have founded an association named Teckids here in Germany that does just that. We organise several events for kids and adolescents in the area of free and open source software, for example the FrogLabs, which share staff with Teckids and are the youth programme of the Free and Open Source Software Conference (FrOSCon). We do a lot more than most other conferences - this year, we first offered the FrogLabs as a holiday camp for kids aged 10 to 16. It was a huge success, with approx. 30 kids taking part and learning with and about free software through a whole weekend. All of us had a lot of fun, and the results were really exciting. Apart from that, we are preparing a campaign that is supposed to bring the message of free alternatives to stuff kids use every day to them and their parents, e.g. the use of Jabber / Jappix instead of Facebook and Skype. To make that possible, we are planning to get together a team of clever kids who understand very well what their peers need and can bring it across to them. So we will have a peer-driven network of adolescents who teach each other and collect feedback from the community of minors. We then take that feedback and our own experience to work closely with open source projects, such as Skolelinux or Jappix, at improving their software in a way that makes it more and more attractive for the target group. At least I hope that we will have good cooperation with Skolelinux in the future ;)! So in conclusion, what I believe is that, if it weren't for the world being so bad, it should be very clear to the political decision makers that the only way to go nowadays is free software for various reasons, but I have learnt that the only way that seems to work is bottom up.

Fighting with passwords have always been one of my favorite battles in the past and unfortunately the former always won. I never liked using the root user that much for administering a machine and made a massive use of sudo, I won t list all the benefits of using sudo, but the following wiki page has a pretty nice overview of them. Said that, when using sudo it s definitely ideal to combine a strong password that is also easy to remember and type again when prompted. Sadly strong passwords that are also easy to remember can be considered an oxymoron. How hard would it be to recall a 30+ chars long password? Honestly that would be close to impossible for an human being but what if a little software available on the major GNU/Linux distributions could handle that for us? That s where pass comes handy, but what is pass? from the pass manpage itself:

pass is a very simple password store that keeps passwords inside gpg2(1) encrypted files inside a simple directory tree residing at ~/.password-store. The pass utility provides a series of commands for manipulating the password store, allowing the user to add, remove, edit, synchronize, generate, and manipulate passwords.

I m sure that a lot of you guys have been looking for a tool like this one for ages: pass allows you to generate very strong passwords with pwgen, GPG encrypt them with your GPG Key, store them safely on your disk and make them available whenever you need them with a single command. But let s move to the practice, give the following steps a try and enjoy how powerful your pass setup will be. First setup 1. Install the software:

yum/apt-get install pass

2. Generate a GPG Key if you don t have one already, a detailed guide can be found here. 3. Initialize your passwords storage. (GPGKEYID can be retrieved by running gpg list-keys and then looking for a line similar to this one: pub 4096R/B3A6223D 2012-06-25)

pass init GPGKEYID

4. Generate your first password and call it sudo_password given you are going to make use of it as your brand new sudo password. (we want it at least 30+ chars long)

pass generate sudo_password 30

5. (Optional) Create as much passwords as you need and make sure to save them with unique names, that way you will be able to identify what a password is used for easily.

pass generate gmail_password 30

Additional maintenance commands on your password database 1. Look at the existing passwords on your database.

pass ls

Result:

Password Store
  gmail_password
  sudo_password
  root_password

2. Manually edit a password.

pass edit password_name

3. Remove a password from your database.

pass rm password_name

4. Copy a password on your clipboard and paste it.

pass -c password_name

Are you wondering if pass supports a VCS? Yeah, it does, it currently allows you to manage your passwords database with Git, so that each applied change to the database will be tracked through a VCS so that you won t forget when and how you updated a specific password.

Review: The Death of Bees, by Lisa O'Donnell

Publisher:	HarperCollins
Copyright:	2012
Printing:	2013
ISBN:	0-06-220984-1
Format:	Hardcover
Pages:	309

This is the first definite hit from my Powell's Indiespensable subscription, and a good example of why I subscribe. I never would have read or even heard of this book without it, and I thoroughly enjoyed it. Marnie and Nellie are sisters living in a housing estate in Glasgow's Maryhill district. Neither of their parents ever held regular jobs, although one does quickly learn their father had been earning money distributing drugs. The story opens, rather shockingly, with the death of both parents: their father smothered in his bed, and their mother, a day later, after refusing to notify anyone of their father's death, by hanging herself in the garden shed. In fear of being taken by social services and then separated, particularly given Nellie's unusual way of interacting with the world (she talks, and writes, like a woman in the 1950s trying to sound high-class), the girls bury both bodies in the back garden and tell everyone their parents just went on an unannounced trip without them. It wouldn't be the first time. Marnie is 15 and a year away from being legally an adult, at which point she can take custody of Nellie (who is 12) and keep them together. In the meantime, they just have to keep their parents' deaths secret and figure out how to keep food on the table and social services away. Their next-door neighbor is a formerly-closeted older gay man named Lennie who is known as the neighborhood pervert after he was arrested getting a blow job from an underage male prostitute. Both girls are quite understandably suspicious of him, but he's also the first person to notice that something is wrong and to start trying to help. The book is told in many short chapters, each written by one of Marnie, Nellie, or Lennie in their own voice. You might have guessed from the plot summary that this book needs a few warnings, but I want to emphasize that more. This is a book that opens with decaying corpses, including a few rather-too-vivid images from its transport and from Marnie's later (unnamed) post-traumatic stress. Marnie is quite sexually active, and both girls have had a nasty background full of things that I preferred not to think too much about. Most of the worst bits are only alluded to and are kept off-camera, but there's still quite a lot of background nastiness and desperation here. The Death of Bees is blunt and forthright to the point that it repeatedly made me cringe, and that sort of thing usually doesn't bother me in books. That said, this is not a horror novel, even though it contains horror. You could describe it as darkly comic, although none of the comedy is the sort that makes one laugh, except perhaps in startled surprise. The adjectives that come to mind are fierce, compassionate, empathetic, tough, and courageous. The author is completely on the side of the three protagonists, all of whom are deeply hurt in their own ways but all of whom are trying as hard as they can to support each other. I have rarely read a book that made me care as much about the characters. It's the kind of story that makes one want to passionately defend them, particularly once the one real villain, in the form of a do-gooding outsider, makes his appearance. And the reader and the author aren't alone. One of the things I loved about this book is that it doesn't artificially isolate the characters. Marnie has friends, and while Marnie doesn't always notice for Marnie, this is just her life, and many things of significance to the reader are just more of daily life for her this book is full of unexpected acts of small kindness. The surrounding characters are themselves all dealing with their own troubles and not in a great position to help anyone, and yet somehow they manage. Even Nellie, who has a great deal of difficulty interacting with other people her own age, gets unexpected help from people she thinks can't stand her. I think it's very telling that about the only character here who is entirely unsympathetic is the one who claims to be the most moral and virtuous. Unfortunately, from my perspective, this book has one major flaw: the ending. Thankfully, the ending isn't bad; if it were, it would have completely destroyed my enjoyment of the book. By the time one gets through this story, having something bad happen to these girls would break your heart. The ending does deliver the necessary catharsis, but it is far, far too short. O'Donnell builds up tension mercilessly, pushing the story down a path that's clearly desperately wrong for both of the girls, and doesn't let the story climax happen until about ten pages from the end. We get all of a page or two of denouement, and then the novel is over. I am, admittedly, a "Scouring of the Shire" sort of person. I like long denouements, particularly if I've gone through hell with the characters. I like getting to spend some happy time with them. But even for those who don't enjoy that as much as I do, I think this ending was too short. O'Donnell does an amazing job building sympathy and empathy throughout the story, and I didn't want to have to fill in all of the happily ever after from my own imagination. Maybe it would have been hard to do without getting too sentimental or without dulling some of the sharp edges of the story, but I would have really appreciated another ten pages. As is, it felt like the novel abruptly and unceremoniously dumped me out on the ground. But, that aside, this is an excellent character story. It's one that I would be careful about recommending; parts of it are extremely dark and nasty, and you have to take Marnie on her own terms for the story to work. But it's beautifully written and thoroughly engaging, and I'm very glad to have read it. Rating: 8 out of 10

Yesterday, I have managed to finish up an old pet peeve of mine. I wrote a series of patches to have harness reprocess all packages, which were last checked by an older version of Lintian than the current. It is not completed to the level I would like, but it is good enough for now. The implementation works by processing up to 1024 groups after each daily run. It also have a timer to skip this, if the run has taken more than 4 hours. Packages to be reprocessed are sorted by the version they were last processed should a new version of Lintian be upload before all packages have been reprocessed, the oldest results are refreshed first. A rough estimate suggests than in about 3-4 weeks, the entire archive will have been reprocessed with Lintian 2.5.20. It is by no means faster than a full run (which is about a week), but it is automatic and removes the human factor in keeping Lintian results up to date.

One topic that often gets discussed when it s near election time is whether clubs and societies should be political . Some organisations are limited in what they can do, for example in some jurisdictions religious organisations can theoretically lose their tax exempt status if they advocate for one party. In practice any organisation that has a wide membership will have a variety of political views represented so a policy of directly supporting one candidate or party is likely to lose some members. A common practice among some clubs is to send questionnaires to parties before elections. This might cause a policy change in the parties that do whatever it takes to get votes (as opposed to the parties who devise policy based on principle). But it also provides members a list of how the parties compare on the basis of the criteria that matter to the club. I think that organisations such as Linux Australia [1] and the Linux Users of Victoria [2] should send such questionnaires and publish an analysis of the results. I previously suggested a few questions that could be asked [3], the last one received some negative comments for being too tabloid but the others got some agreement. But obviously there would need to be some discussion about which questions are in scope and how they should be asked. Such a discussion would take a while and would need to be started well before an election was called, I think if we start now we should be able to get it done before the next federal election is called. There is one Australian political party that has a consistent record of having IT policies that are in line with the general aims of Linux Australia and which also has policies that meet the social standards that are generally agreed by most of the membership (EG opposing discrimination). But I know that there are some members of the Linux community who advocate various forms of discrimination and would vote accordingly so advocating for that party would get some negative reactions. But if someone wants to vote for a party that advocates discrimination against minority groups I don t think that there s any harm in providing information to allow them to vote for a pro-discrimination party that has a reasonable IT policy. In any case it doesn t seem likely that we can get most of the membership of an organisation like Linux Australia to agree on what parties are unacceptable, so sending a questionnaire to all parties avoids that debate. I would like to see this sort of thing done by LUGs for all state and territory elections. I will be involved in the process with LUV for the Victorian elections, but I have to just hope that my blog posts inspire people in other states and territories if anyone has already started on this then please let me know. I will also be involved with getting this done for the federal elections with Linux Australia, hopefully this post will help get people interested in that.

• [1] http://linux.org.au/
• [2] http://luv.asn.au/
• [3] http://etbe.coker.com.au/2009/03/17/lobbying-for-free-software/

Using a Virtual Private Network is a good way to work-around geoIP restrictions but also to protect your network traffic when travelling with your laptop and connecting to untrusted networks. While you might want to use Tor for the part of your network activity where you prefer to be anonymous, a VPN is a faster way to connect to sites that already know you. Here are my instructions for setting up OpenVPN on Debian / Ubuntu machines where the VPN server is located on a cheap Linode virtual private server. They are largely based on the instructions found on the Debian wiki. An easier way to setup an ad-hoc VPN is to use sshuttle but for some reason, it doesn't seem work on Linode or Rackspace virtual servers.

Generating the keys Make sure you run the following on a machine with good entropy and not a VM! I personally use a machine fitted with an Entropy Key. The first step is to install the required package:

sudo apt-get install openvpn

Then, copy the following file in your home directory (no need to run any of this as root):

mkdir easy-rsa
cp -ai /usr/share/doc/openvpn/examples/easy-rsa/2.0/ easy-rsa/
cd easy-rsa/2.0

and put something like this in your ~/easy-rsa/2.0/vars:

export KEY_SIZE=2084
export KEY_COUNTRY="NZ"
export KEY_PROVINCE="AKL"
export KEY_CITY="Auckland"
export KEY_ORG="fmarier.org"
export KEY_EMAIL="francois@fmarier.org"
export KEY_CN=hafnarfjordur.fmarier.org
export KEY_NAME=hafnarfjordur.fmarier.org
export KEY_OU=VPN

Create this symbolic link:

ln -s openssl-1.0.0.cnf openssl.cnf

and generate the keys:

. ./vars
./clean-all
./build-ca
./build-key-server server  # press ENTER at every prompt, no password
./build-key akranes  # "akranes" as Name, no password
./build-dh
/usr/sbin/openvpn --genkey --secret keys/ta.key

Configuring the server On my server, a Linode VPS called hafnarfjordur.fmarier.org, I installed the openvpn package:

apt-get install openvpn

and then copied the following files from my high-entropy machine:

cp ca.crt dh2048.pem server.key server.crt ta.key /etc/openvpn/
chown root:root /etc/openvpn/*
chmod 600 /etc/openvpn/ta.key /etc/openvpn/server.key

Then I took the official configuration template:

cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/
gunzip /etc/openvpn/server.conf.gz

and set the following in /etc/openvpn/server.conf:

dh dh2048.pem
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 74.207.241.5"
push "dhcp-option DNS 74.207.242.5"
tls-auth ta.key 0
cipher AES-128-CBC
user nobody
group nogroup

(These DNS servers are the ones I found in /etc/resolv.conf on my Linode VPS.) Finally, I added the following to these configuration files:

• /etc/sysctl.conf:

  net.ipv4.ip_forward=1
  

• /etc/rc.local (just before exit 0):

  iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
  

• /etc/default/openvpn:

  AUTOSTART="all"
  

and ran sysctl -p before starting OpenVPN:

/etc/init.d/openvpn start

If the server has a firewall, you'll need to open up this port:

iptables -A INPUT -p udp --dport 1194 -j ACCEPT

Configuring the client The final piece of this solution is to setup my laptop, akranes, to connect to hafnarfjordur by installing the relevant Network Manager plugin:

apt-get install network-manager-openvpn-gnome

The laptop needs these files from the high-entropy machine:

cp ca.crt akranes.crt akranes.key ta.key /etc/openvpn/
chown root:francois /etc/openvpn/akranes.key /etc/openvpn/ta.key
chmod 640 /etc/openvpn/ta.key /etc/openvpn/akranes.key

and my own user needs to have read access to the secret keys. To create a new VPN, right-click on Network-Manager and add a new VPN connection of type "OpenVPN":

• Gateway: hafnarfjordur.fmarier.org
• Type: Certificates (TLS)
• User Certificate: /etc/openvpn/akranes.crt
• CA Certificate: /etc/openvpn/ca.crt
• Private Key: /etc/openvpn/akranes.key
• Available to all users: NO

then click the "Avanced" button and set the following:

• General
  • Use LZO data compression: YES
• Security
  • Cipher: AES-128-CBC
  • HMAC Authentication: Default
• TLS Authentication
  • Subject Match: server
  • Verify peer (server) certificate usage signature: YES
  • Remote peer certificate TLS type: Server
  • Use additional TLS authentication: YES
  • Key File: /etc/openvpn/ta.key
  • Key Direction: 1

Debugging If you run into problems, simply take a look at the logs while attempting to connect to the server:

tail -f /var/log/syslog

on both the server and the client. In my experience, searching for the error messages you find in there is usually enough to solve the problem.

Next steps The next thing I'm going to add to this VPN setup is a local unbound DNS resolver that will be offered to all clients. Is there anything else you have in your setup and that I should consider adding to mine?

Review: They Had to Go Out, by Gary J. Hudson

Publisher:	Xlibris
Copyright:	2008
ISBN:	1-4363-8132-0
Format:	Trade paperback
Pages:	165

They Had to Go Out, as noted on the cover, is the story of the tragedy of the Triumph and the Mermaid, a marine incident that occurred off the Oregon coast of the United States near the mouth of the Columbia River on January 12, 1961. But it's also much more than that. It's a detailed and thoroughly-researched account of a Coast Guard rescue operation, starting with background on the two coastal lifeboat stations and the types of ships involved. It covers everything from crew backgrounds to equipment issues to the general shape of the subsequent inquiry, and in the process provides a wealth of detailed information about the nature of Coast Guard rescue operations and the technology and equipment available at the time. But, beyond that, it's a gripping story, in part because of the authenticity of the authorial voice. Gary Hudson spent twenty years in the Coast Guard, ten on coastal lifeboat stations like the ones in this book, and was assigned to Point Adams (the primary station involved in this story) until 12 days before the incident, when he transferred to a light station for unrelated reasons. The writing is rough, the paragraphs are not always well-organized, the punctuation doesn't always end up in the right place, and it could have used an editor (Xlibris is a printing service company for self-publishing). But he understands the subject matter completely, and he clearly spent years of effort putting together all the details of the story. The first few chapters, where he establishes the necessary background and tells a few related stories, feel quite rough, but once he gets into the heart of the story, the rough prose stops mattering. Obviously, one of the things that makes this story so appealing is that it's a gripping human story, with the unconstructed and unexpected twists and turns of reality rather than a plot. Hudson has lived the life of the people he's writing about and can put many of their fears and thoughts into words. He captures some of what it would feel like to be out on the water in the middle of the worst seas that most of them had ever seen. And reality is unpredictable. I'm avoiding giving the exact details of what happened and I would recommend not researching the incident on Google if you plan to read this book; there's a lot of drama here, and spoilers are possible. Hudson's factual, detailed narrative style gives the reader a lot of material with which to build mental pictures, and he preserves the drama and the human impact of the story by telling it in straight chronological order. The writing is rough, but he shows a talent for pacing and perspective in the way he weaves together the viewpoints of multiple Coast Guard stations and ship crews. This is also a case study and an accident report, put together with extensive research and scope, but made approachable for the average reader. Hudson takes out the dryness and technical language and weaves the events into a narrative, but he doesn't lose much of the detail. You can know nothing at all about ships or Coast Guard operations and come away from this book with strong opinions about self-righting capabilities (and, more to the point, accurate communication to crews of the capabilities of their vessels). And, by showing a full day of Coast Guard operations (admittedly, a very unusual and difficult day), Hudson also provides the previously unfamiliar reader with a great "day in the life" picture of what Coast Guard lifesaving operations at their most dangerous look like (or at least looked like; one also gets a sense of just how much has improved, and how important the improvements are, in the final chapters). Finally, unlike most accident reports, Hudson carries the story through to the immediate family impact (which may well bring you to tears) and then, given forty years of hindsight, some of the subsequent effects on the people involved. I really liked this. One of the aspects of stories like this that often gets short shrift is that the people involved carry the incident with them for the rest of their lives, often with profound impact. Unlike a movie, where the movie ends and the characters disappear as soon as the primary action is complete, real life has messy and lingering endings, and I think Hudson manages to capture some of that feeling. Some of the best non-fiction books are not written by professional writers. Instead, they're written by people who have both expertise and passion for a particular topic and who know or teach themselves enough about telling a story to manage to get that expertise and passion out on paper. Hudson puts every aspect of this day into the book, from the people to the family impact, from the questionable decisions to the equipment failures and shortages, from the initial conditions through the inquiry and up to the subsequent impact on the lives of the people involved (including, sadly, the Coast Guard's lack of understanding of how to help people with traumatic stress). Some of the paragraphs clunk, some of the sentence construction is awkward, and some of the short biographies are a bit lost in details, but Hudson's desire to tell the complete truth as he was able to reconstruct it, and his deep empathy and understanding of how it felt to the people involved, shine through and carry this book. This is great stuff, and worth seeking out. Recommended. Rating: 9 out of 10