Any interest in early drafts?

I have the DNSSec book about a third done, which isn’t bad for spending a week in the hospital this month, and am looking at various publication options. Once the book is finished it’ll be available in print, on Amazon, Barnes & Noble, Kobo, and hopefully iTunes. But I have an option for before the book is complete. LeanPub allows authors to upload works in progress, and update them as the work proceeds.

I’m pondering something like this:

  • Offer the incomplete book on LeanPub at, say, a 20% discount. Those of you who want to see it can, and those of you who want to send feedback can.
  • Update the book on LeanPub as I write.
  • When the book is finished, upload the final manuscript to all ebook platforms. Raise the LeanPub price to match. If you bought it earlier, you still get access, of course.
  • If you follow my blog, you’re probably a fan. I have no problem giving a discount to people interested enough in my work to follow my blog. And I might even get useful feedback.

    One of my goals is to reduce the amount of non-paying non-writing work I do. (Basically, I want to reduce my monthly recurring expenses, especially time expenses.) Updating a book as I write it isn’t a huge amount of work, but if nobody’s interested, I don’t want to bother.

    So: would anyone be interested? Or should I keep writing in my bubble?

    Configuration Automation with RANCID

    One of the most tedious tasks any network admin faces is replicating changes across multiple devices. I recently stood up new RADIUS servers, and needed to tell all of my routers and switches about it. Rather than logging into each router by hand and pasting in the new configuration, I decided to try RANCID‘s ability to run arbitrary commands on your routers.

    Using this method requires that the commands you run don’t generate interactive output. A reload command won’t work, because it prompts you for confirmation. But adding configurations to a Cisco router doesn’t.

    I assume you have a working RANCID install.

    Start by creating a text file containing your commands. RANCID expects to log on and log off of the router. All you need to provide is what happens between those two points.

    conf t
    radius-server host 192.0.2.2 auth-port 1812 acct-port 1813 key BuyBooksFromLucas
    radius-server host 192.0.2.14 auth-port 1812 acct-port 1813 key BuyBooksFromLucas
    exit
    wr

    Now use the device-specific login command, specify the file containing your commands with -x, and list every router you want to run the commands on.

    # clogin -x newradius.conf router-1 router-2 router-3

    RANCID logs into each device and add the new configuration. You can watch the process in action, and catch any problems.

    I found that the Mikrotik login script had problems when the script changed the prompt. I’ve reported this to the RANCID mailing list, and expect it will be patched shortly. But fortunately, that’s pretty easy to work around in a Mikrotik, by giving the entire command in one line, as shown below.

    /radius add accounting-backup=no accounting-port=1813 address=192.0.2.2 authentication-port=1812 called-id="" disabled=no domain="" realm="" secret=BuyBooksFromLucas service=login timeout=300ms
    /radius add accounting-backup=no accounting-port=1813 address=192.0.2.14 authentication-port=1812 called-id="" disabled=no domain="" realm="" secret=BuyBooksFromLucas service=login timeout=300ms

    Having RANCID run commands for you is much more accurate and less tedious than doing it yourself. And this way, if you make a mistake in your commands, at least it’ll be consistent across all your devices.

    Absolute OpenBSD 2/e Haiku Contest Winners & status

    I offered a haiku contest for the new Absolute OpenBSD. Winners got their haiku in the book, credited to them, plus an ebook copy of the book, plus a physical copy if I get enough physical copies and few enough winners.

    More people entered than I expected, a pleasant surprise. I appreciate everyone’s efforts.

    The winners are:

    Chapter 1:
    Josh Grosse: “Mailing lists are rough / Homework is mandatory / Love it or leave it”

    Chapter 3:
    Josh again, with “Straightforward questions. / Will you take the default prompts? / Think before you choose”

    Chapter 7:
    Ludovic Simpson, with “the root of all evil/ is never far from your touch / sudo saves your life”

    Chapter 12:
    Justin Sherrill, with: “My tunnel is now up/ I can do IPv6 / Me and three others” (needed slight edit for syllable count)

    Chapter 16:
    Josh Grosse again, with “Working behind scenes / taking care of vital things / the daemon is here”

    So, that’s three winners. I can swing three paper books.

    I had a lot of competition for certain chapters, others less so. Sending a network chapter haiku meant you went up against everyone, where submitting a haiku on the system maintenance chapter means you only went up against me.

    How did Josh get so many? Two ways. One, he submitted a haiku for every chapter. Two, I believe he was already familiar with haiku, and has read some of the classics. (Twitter doesn’t let me search old tweets easily, so I can’t be certain of that, but I’m pretty sure he’s the one I’m thinking of.) Josh actually inspired me to hold the contest with his Chapter 1 haiku.

    So, now that the haiku are ready, where is the book?

    Chapters 0-22 have gone through content editing. Two chapters remain.
    Chapters 0-17 have gone through tech edit.
    Chapters 0-14 have gone through copy edit.
    Chapters 1-6 have come back to me from layout. I have initial galleys to correct. They look really really nice — NSP always does a fabulous job producing books.

    The layout folks haven’t gotten the haiku yet, but needed to have something in that space. When I opened the draft I found:

    Here, a placeholder
    For a haiku still to come
    Replace at pages.

    The No Starch folks get it.

    DNSSec and DLV on current BIND

    One of the problems with the Internet is that old stuff hangs around forever. Configuring DNSSec validation on BIND 9.8 and newer is a lot easier than many of the popular tutorials would lead you to suspect. It’s so simple that I wonder why it isn’t the default.

    options {
    ...
    dnssec-enable yes;
    dnssec-validation auto;
    dnssec-lookaside auto;
    };

    This automatically loads the root zone and dlv.isc.org trust anchors distributed with the BIND source code, verifies them, and uses them to validate all signed responses.

    One trick is that named needs to write journal files for these keys. If you used the directory option to set a directory writable by named, you’re all set. If, like me, you have a whole bunch of directories that you don’t want named to write to, and you don’t want named to write to /etc/namedb, you can set a directory for these named-managed keys.

    /var/log/messages will have errors like this:

    Jan 7 11:59:02 ns11 named[78246]: the working directory is not writable

    These errors are harmless. named cannot write /etc/namedb, but it will log an error when it tries to write a file. The errors you need to worry about look like this:

    Jan 5 13:07:05 ns11 named[68130]: dumping master file: tmp-XI0K5awL6p: open: permission denied

    These indicate that named is trying to record important data, and can’t. Giving named a directory where it can write these managed key files will solve this problem.

    options {
    ...
    managed-keys-directory "managed-keys";
    }

    Make that directory owned by the user running named. Restart (not reload) named, and you’re all set.

    One of the rules of public key encryption is that your private key must be private. Most of us have had private keys stolen at some time. (If you haven’t, either you’re not using public key crypto, or you didn’t notice.) What happens if someone steals the private key for a DNSSec trust anchor?

    There’s a protocol for automatically updating the trust anchor private keys, documented in RFC 5011. It’s not perfect — you’ll still want to keep half an eye out for announcements of a trust anchor compromise.

    On a related note, I’d be interested in hearing from anyone who knows how the root zone private key is protected, just so I can put a sentence or two in the DNSSec book.

    Conference Submissions & BSDCan 2013

    The BSDCan 2013 call for proposals is open. As a BSDCon committee member, it’s my responsibility to get you lot to submit interesting papers. So: submit!

    More than once, I’ve been asked something like “How can I get a paper accepted at BSDCan?” or “Why was my BSDCan paper rejected?” Here’s my answer to that general question. Lots of this applies to any conference, but as I’m not on the committees for those other conferences, I can’t claim any authority there. Other conferences have their own ideas, and other BSDCan committee members might have independent thoughts as well.

    The purpose of a BSDCan paper is not to advertise the presenter’s work, but to put butts in seats. Sometimes these overlap. I want someone looking at the BSDCan schedule to say “Wow, I HAVE to go to this!” But “be interesting” isn’t exactly useful advice. Some of this might be.

    1) Present an topic that hasn’t been covered before. The previous proceedings are all available online. Some topics come up every year. Don’t submit those unless you have a fresh new take on them.

    2) Tell us why YOU should be the one to present your topic. We frequently get multiple similar proposals, and have to choose between them based on who we think might do the best job. Don’t assume that everyone on the committee knows who you are. One of us probably knows that you run weaselBSD on twelve thousand workstations, but they probably won’t share than information with everyone else. (Paper selection is done via web form, which isn’t as conducive to back-and-forth discussion as in-person or mailing list discussions.) More than once I’ve had someone come up to me at a conference and say “Why did you have so-and-so report on X? I have forty times as much X as the speaker you chose!” My answer is, “You didn’t TELL US that you had so much.” I am not telepathic.

    3) We get many FreeBSD proposals. I want more Net/Open/Dfly proposals, as well as for projects and devices based on them. Non-F/N/O/D BSD papers have much smaller audiences, so a paper on them has to be very interesting. Again, butts in seats.

    4) Include “lessons learned.” Anybody can read a man page. If you were involved in recovering from the recent FreeBSD security incident, you should submit a paper about it. If you deployed OpenBSD in a nuclear submarine and learned about the importance of the little radiation-detection badge, you should submit a paper. “Lessons learned” implies that you made mistakes, and can upgrade your talk from the merely technical to a bit of a story. Don’t be afraid to embarrass yourself, we’ve all been there. Sharing mistakes helps connect your presentation to the audience.

    5) Tell us what the audience will get out of the talk — e.g., if it’s a sysadmin talk: “Attendees will be able to configure weaselBSD’s anti-ferret features and understand how they integrate with email and Web.”

    6) Spelling and grammar are not pimple cream, to be dabbed on where needed. If you’re going to indulge in floccinaucinihilipilification, you’d better be able to spell it.

    7) Speaking of floccinaucinihilipilification, you’re better off saying why your stuff is awesome as opposed to running down someone else’s work. I know many reasons why computers suck. Learning something to make my job suck less is good.

    That’s what I look for, at least. Others have their own opinions. And if you think a little bit, you can make your proposal answer all of these. Unless you’re running weaselBSD, that is…

    Now: submit!

    2013 Projects and 2012 Errata

    When you set goals for a year, you need to tell people about them. The potential embarrassment of having to admit failure helps you complete the goals. With that in mind, here are my goals for 2013:

    1) I will do three short technology books through my private label (aka “self-publish”). The first, on DNSSec, is underway. Some text exists, and I’m making copious use of scratch paper and whiteboards to figure out how to explain KSKs, ZSK, and the signature and key lifecycle in a coherent manner. (If you happen to have a good resource for this, please feel free to point me at it in the comments.)

    2) I will write & self-publish one novel. If I write nothing but nonfiction, my brain freezes up and the tech books become unreadable. If I’m going to write fiction anyway, I might as well release it. Attempting to traditionally publish a novel takes more time and energy than writing a book and will probably fail, so I prefer to spend that T&E writing. The odds of the book succeeding are negligible either way, so I’d prefer to do so in the least expensive manner.

    3) If I accomplish both of these early enough, I will continue writing. I will indulge myself in trying something that’s “just crazy enough to work,” like, say, “dc(1) Mastery” or “netstat Mastery.”

    Now here’s a leftover from 2012:

    Richard Bejtlich has reviewed hundreds and hundreds of technology books over the last ten years. For a time, he was one of Amazon’s Top 100 reviewers. Each year he posts a list of the best books he’s read, and gives one book the “Best Book Bejtlich Read” (BBBR) award. The award and $5 will get me a nice gelato.

    I’ve been on the top 10 list before, in 2007, for Absolute FreeBSD, and 2006 for PGP & GPG.

    2012’s BBBR went to (drumroll): SSH Mastery.

    This comes with some caveats, mind you. Bejtlich read and reviewed only one tech book in 2012, and this is his final BBBR award. I had no competition. But I’m okay with that.

    Bejtlich no longer reviews tech books, which I personally find disappointing. (I mean, how can I not like reviews that start start off with The master writes again? That’s the sort of thing I bookmark for those nights I get really depressed and start contemplating a shot of whiskey and a small handgun.)

    Life changes, however, and he’s working in other areas now, so: Richard, so long, and thanks for all the fish. I’m still putting that last quote on the cover of the DNSSec book, though.

    OpenBSD ruleset tracing

    As Henning reviews the Absolute OpenBSD manuscript, he’s pointed out items that I’ve missed. Some of these are only documented in man pages, while others don’t seem to really be documented anywhere except in the source code. Here’s an interesting tidbit he pointed out that I haven’t seen anywhere other than Henning’s email. (Having said this in public, I’ll now find all sorts of examples that I missed, such as Henning’s slides from EuroBSDcon 2010.)

    You can log specific connections to separate log devices, for simpler debugging. You need the log rule near the beginning of your ruleset, but it doesn’t have an effect on whether a packet is passed or blocked, or how it’s translated. Here’s a pf.conf line to tell PF to watch for connections from 192.0.2.226 to 203.0.113.34.

    match log (matches) from 192.0.2.226 to 203.0.113.34

    Now watch the log interface, searching for the destination address:

    # tcpdump -n -e -ttt -i pflog0 ip host 203.0.113.34
    tcpdump: WARNING: snaplen raised from 116 to 160
    tcpdump: listening on pflog0, link-type PFLOG
    Dec 17 17:40:25.071592 rule 2/(match) block out on fxp0: 192.0.2.226.14033 > 203.0.113.34.822: S 2830367545:2830367545(0) win 16384 (DF)
    Dec 17 17:40:25.071600 rule 5/(match) pass out on fxp0: 192.0.2.226.14033 > 203.0.113.34.822: S 2830367545:2830367545(0) win 16384 (DF)
    Dec 17 17:40:25.071604 rule 5/(match) pass out on fxp0: 192.0.2.226.14033 > 203.0.113.34.822: S 2830367545:2830367545(0) win 16384 (DF)
    ^C

    You get the number of every rule that matches the packet. If you use NAT, it prints original and destination addresses. With my wussy PF rules, this isn’t terribly exciting. With more complicated rules, however, it makes debugging rulesets much easier.

    This is the sort of useful information you’ll get if you preorder the new Absolute OpenBSD. (See how I subtly slipped that in? I’m getting good at this marketing stuff.)

    TWP sponsoring BSDCan 2013

    The money has left my bank account, so I guess this is official: Tilted Windmill Press (the LLC under which I self-publish) is the official T-shirt sponsor of BSDCan 2013.

    Why do this? First, it’s important to give back to my community. BSDCan is one of the biggest and oldest cross-BSD conferences, and this sponsorship will buy plane tickets for several speakers. Second, independent publishers must meet two standards: a) write good books, and b) don’t be a jerk. This should put a touch more weight on the “not a jerk” side of the scale. Plus, everybody who goes to BSDCan will get a T-shirt featuring the TWP busted knight logo. That’s pretty dang cool, to me at least.

    As I know someone will ask, I’ll also say: the conference is being paid for out of TWP profits, not out of my pocket. Self-publishing does work, and can be profitable. See point 2 above.

    And if I can sponsor a BSD conference, you can too! BSDCan has cool sponsorships available, as do EuroBSDcon, and NYCBSDCon. Admittedly, there’s nothing quite as cool as being the T-shirt sponsor, but still, if I can swing that surely you or your employer can do something.

    Absolute OpenBSD pre-orders now available

    No Starch Press now has pre-orders for new Absolute OpenBSD. Order direct from the publisher, and get both the ebook and the paper for one price. If you use the coupon code ILUVMICHAEL you’ll get a discount, and I get a commission on the sale. (Bolded 20130207 because more than one person has said they missed that line.) If you use another coupon code, I still get paid, but not as much. I’m not deeply concerned which way you buy it, so long as you buy it.

    Here’s the cover of the new edition. It incorporates art from the first edition, plus a new background.AO2e Cover

    On a vaguely related note, I recently saw a link to my blog from a Chinese Unix users message board. Curious, I asked Google Translate what it said. It’s a discussion of the new book, which is awesome. Slightly worrying, though, is that in the translation they repeatedly refer to me as “Great God Lucas” or some variant thereof. I’m hoping that this is an artifact of translation, or some cultural thing I was previously unaware of.

    Otherwise, it would seem that I have a cult of worshippers in China, and that I must learn Chinese in order to issue my commands.

    Even more tangentially, links within a translated page take you to a translated version of that page. That’s pretty cool.

    Next Nonfiction Book

    I’ve made it a practice to not announce book topics or titles until the book is well underway. Writing a big book takes not less than a year (Absolute FreeBSD) and up to three years (Absolute OpenBSD, 2nd ed). Once I hand in the completed first draft to the publisher, there’s editing, tech edits, copyedit, page layout, and so on. It’s a few months to get the book into production.

    Delaying the announcement also gives me the chance to determine if the book is realistic. I’ve made no secret that I write about topics that I’m not qualified to cover. I’ve had more than one tech book that I’ve started, only to discover three chapters in that I am so not the person to write this book. Delaying announcing the topic gives me a chance to back out without anybody knowing.

    I’m trying something a little different this time. My next book will be published by Tilted Windmill Press (my private label) and much smaller than my BSD tomes. I have an outline. I’ve done the reading. My educational lab work is done (meaning that my rate of screaming “Why isn’t this working?” has dropped from thrice hourly to twice daily). And I’m doing a fairly wide variety of work with the topic in the next six months.

    The next book is on (drum roll please): DNSSec. Blame Richard Bejtlich. (I wish I could find the tweet in question, but seriously, how am I supposed to resist him declaring “You’re our only hope?” Flattery will get you anywhere. Especially if you’ve given me enough cover quote copy to last the rest of my career.)

    Writing the book concurrently with implementing DNSSec across great big piles of domains with multiple registrars should give me all sorts of problems to write about, and give my readers more benefit from my real-world pain.

    I know a lot of people don’t like DNSSec, have cogent arguments why DNSSec is poo, and really wish it would go away. They take me writing a book about it as a refutation of their arguments. It’s not. But DNSSec is here. It’s the standard. We’ve got to deal with it. And the supporting software has improved to the point where DNSSec can be implemented by the typical overworked sysadmin, rather than only crypto fans.

    DNSSec also gets you things like SSHFP records and vendor-free SSL certificates. The former is convenient. The latter will eliminate any excuse for unencrypted communications.

    Why announce this ahead of time? For one, you’ll probably see me griping about random pieces of DNSSec boneheadedness on Twitter. The savvy will be able to guess. Announcing the book will help keep my nonfiction writing focused. It’s still possible that someone will rush a book into print ahead of me, but the shorter cycle of independent publishing reduces that risk. The audience and community reaction to SSH Mastery is also encouraging; I know that if I write a good book, my readers will tell others about it, regardless of the publisher. If someone beats me to print, my readers will still support me.

    And if I write a crap book, it deserves to fail.

    (As an aside: having readers who tell their friends and co-workers about my books is freaking awesome. I could not publish books if you didn’t support my work. Thank you.)

    Ideally, I’ll have this book out for BSDCan 2013. Tilted Windmill Press is the BSDCan T-shirt sponsor, so having a book out for the conference would be a good idea.

    More questions? Too bad. That’s all I know right now. Except that now that I’ve set and announced a goal, my life will go horribly askew specifically to delay me.