FreeBSD Jails and ntpd

I’ve written elsewhere how daemons running on jail servers (the main host, not the imprisoned machines) should listen only on a single address. They shouldn’t bind to all addresses on the machine.

Your average empty FreeBSD install has two problem children: syslogd and ntpd. Adding syslogd_flags="-ss" to /etc/rc.conf handles the first. But FreeBSD’s included ntpd binds to port 123 on all addresses on the machine.

You can run jails while running ntpd. The jail won’t crash in flames. But the jail code expects the jail to have exclusive access to the jail address. This could well come back to bite you later. Besides, it lacks elegance.

Enter openntpd. Openntpd can synch your host clock without binding to any ports. Install it from packages:

# pkg install openntpd

The file /usr/local/etc/ntpd.conf lets you set the preferred server(s) and, if needed, a bind address. This machine is in private address space, so I have to point it at my local time server.

server time.michaelwlucas.com

Now enable openntpd in /etc/rc.conf, and disable the system default ntpd if it’s running.

openntpd_enable="YES"

Run ntpdate to fix the time, then start openntpd.

# ntpdate time.michaelwlucas.com
1 Nov 15:03:22 ntpdate[53689]: adjust time server 192.0.2.130 offset -4.001088 sec
# service openntpd start
Starting openntpd.

The clock is now correct — or, rather, if the clock is wrong, all the servers will be wrong together. And the various jails each has sole access to their own IP addresses.

“Sudo Mastery” print + ebook bundle via Amazon

I’ve mentioned this before in various forums and in passing, but it bears a small emphasis.

Some people want books in both ebook and print. I’m not set up to do that, but Amazon is making that happen through their Matchbook program. The general idea is that if you bought a book in paper, you can get the ebook version at a steep discount.

I’ve put both existing Mastery paperbacks in the program. If you’ve bought the print book from Amazon, you can get the electronic version for $2.99. When Sudo Mastery hits paperback, it’ll be included.

Why $2.99?

I feel the fair price for the combo is about $20. The list price on the print books is $20, but Amazon knocks a few bucks off based on their own inscrutable algorithms. I’ve seen SSH Mastery as low as $14 and as high as $18.

There’s also the Amazon royalty on Kindle books. Ebooks priced less than $2.99 pay me a 35% royalty. Ebooks priced at $2.99 and up pay 70% royalties. If I price the Matchbook versions at $2.99, I make about $2.00 per sale. If I price them at $1.99 (the next lower option), I make about $0.66/sale. Ouch. Either way, that’s a lot of sales to pay the mortgage.

All this is a long-winded way of saying:

If you want both the print and ebook versions of Sudo Mastery, wait until the print version comes out. You’ll be able to get both for about $20, more or less.

I never buy my print books through Amazon’s retail channel — I buy them in bulk, from their CreateSpace arm. I would really like confirmation that folks who bought a print Mastery book from Amazon can get the ebook at a discount. If you bought a print Mastery, please take a look at Amazon. See if you can get the Matchbook deal and let me know in the comments here.

“Sudo Mastery” ebook widely available, and acknowledgements

At long last, Sudo Mastery is now available in ebook form on most platforms.

You can get it at my bookstore or Amazon.

It’s also available at Smashwords, but Smashwords doesn’t support footnotes. They do support a workaround that puts all footnotes together at the end of a chapter or the end of the book, but it’ll take some work on my part to make that happen.

It’s not at Barnes & Noble yet, because their new Nook Press application completely mangled the book’s formatting. As I sell an average of one book a month through B&N, I’m seriously considering not having the book there.

Print will come some time in November.

I appreciate all the people who helped me write this book. So, in that spirit, here are the acknowledgements.

I want to thank the folks who reviewed the manuscript for Sudo Mastery before publication: Bryan Irvine, JR Aquino, Hugh Brown, and Avigdor Finkelstein. Special thanks are due to Todd Miller, the current primary developer of sudo, who was very patient and helpful when answering my daft questions.

While I appreciate my technical reviewers, no errors in this book are their fault. All errors are my responsibility. Mine, do you hear me? You reviewers want blame for errors? Go make your own.

XKCD fans should note that the author does not particularly enjoy sandwiches. However, Miod Vallat, currently exiled to France, would really like a sandwich with nice fresh bread, really good mustard, and low-carb ground glass and rusty nails. And Bryan Irvine would like a rueben.

This book was written while listening obsessively to Assemblage 23.

Now, to finish writing my big 2013 fiction project before the end of the year…

checking group membership in Ansible templates

I use SolusVM as a virtualization solution, mainly because it’s pretty cheap and mostly effective. The new web-managed migration feature requires that the master node have SSH access into the slave nodes. As root. (Insert lots of swearing here.)

This isn’t a problem, except that I centrally manage my OpenSSH configuration with Ansible. I don’t want all of my hosts to permit the master SolusVM node to log in as root; I only want the Solus hosts to get that setting, and even then only from the master node’s IP address.

The good news is, I have an Ansible group defined for SolusVM hosts. I must modify my template so that it checks if the host is in this group. Ansible provides two variables for the host name, ansible_fqdn (fully qualified name) and ansible_hostname (short hostname). Use the one that reflects your inventory file.

{% if ansible_fqdn in groups['solus-hw'] %}
#solus needs root login from master node
Match Address 192.0.2.12
PermitRootLogin without-password
{% endif %}

As this is a Match statement, it goes at the end of your configuration. My complete sshd_config.j2 looks like this:

#{{ ansible_managed }}
Protocol 2
ListenAddress {{ ansible_ssh_host }}
X11Forwarding yes
PubkeyAuthentication yes
AuthorizedKeysFile /etc/ssh/authorized_keys/%u
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
{% if ansible_system == 'OpenBSD' %}
#no PAM on OpenBSD
{% else %}
UsePAM yes
{% endif %}
Subsystem sftp {{ program_sftp_server }}
{% if ansible_fqdn in groups['solus'] %}
#solus needs root login from master node
Match Address 192.0.2.12
PermitRootLogin without-password
{% endif %}

Do a push, and done. On to the next problem!

Sudo Mastery off to copyeditor

I just shipped the tech-reviewed copy of Sudo Mastery off to the copyeditor. She’ll have it back to me in a few days, and the book will move into production immediately thereafter.

This means that the pre-order discount will expire soon. How soon is soon? It’s soon.

Now I’m off to work on one of my other 2013 goals. Thanks to my appendix’s untimely detonation at the beginning of the year and my Europe trip I won’t accomplish everything on that list, but that’s no reason to not get as many of them finished as possible.

EuroBSDCon, and Sudo Mastery

How’s that for diverse topics in one post?

I just got back from EuroBSDCon 2013 on Malta. The EuroBSDCon Foundation and Andre Opperman did a great job with the conference, and presented one of the best sets of talks and keynotes and related programs I’ve seen in years. It’s motivated me to try to improve BSDCan, but I’ll babble about that in another post.

I followed EuroBSDCon with a few days in Paris, to talk to other authors, network, and figure out some “business of writing” stuff. Plus see the Eiffel Tower and the catacombs, of course.

Now that I’m home, I’m diving into the technical reviews of Sudo Mastery.

Normally when I have a book out for tech review, I post a variety of reminders during the time people should be reviewing. “Two weeks to get comments back to me!” “One week!” “Six hours and three minutes!” I didn’t do that this time, instead focusing on things like distributing blacklists via BGP and automated deployment of FreeBSD and Bhyve and relayd and and and and…

In a weird coincidence, I haven’t received as many tech reviews as I usually do.

Why do people nag? Because it works.

If you’re one of the folks who volunteered to review the manuscript, you have a couple days left to send me comments. I would really like to get the book to the copyeditor by next Monday.

“Sudo Mastery” tech reviewers wanted

Thursday night, I finished the first draft of Sudo Mastery. Today, I went through the manuscript, removed my known tics, discovered a few more tics that needed killing, cleaned up bits and pieces, and now have a work ready for technical review.

Which is where you lot come in. I’m looking for people with sudo experience to read the book and tell me where I’ve screwed up. My screw-ups usually come in two flavors:

1) I’m technically wrong.
2) I use something in a way other people don’t
3) I don’t include something important, because I’ve never used it.

The goal of Sudo Mastery is not to get 100% of my readers to 100% sudo expertise, but instead to get 90% of my readers everything they will need. The remaining 10% will get a solid grounding in sudo and pointers on solving their particularly pernicious edge cases. The idea is roughly similar to my other Mastery books or Cisco Routers for the Desperate.

The contents of Sudo Mastery are:

  1. Introduction
  2. sudo and sudoers
  3. editing and testing sudoers
  4. lists and aliases
  5. options and defaults
  6. shell escapes, editors, and sudoers policies
  7. configuring sudo
  8. user environments versus sudo
  9. sudo for intrusion detection
  10. sudoers distribution and complex policies
  11. security policies in ldap
  12. logging & debugging
  13. authentication

Most of these chapters are short. And much of the writing needs rewriting. But there’s no point in rewriting until I know the content is technically correct.

If you know sudo, if you consider yourself a sudo master already, this is your chance to spread your wisdom. Read my general notes for tech reviewers, and email me at mwlucas at michael w lucas dotcom. (The W is vastly important… you might get a response from the domain without one, but it won’t be what you expected.)

I plan to send out manuscripts over the next week. I’m asking for people to return their comments on or before 5 October. I plan to revise the manuscript the week of 6 October and get it to the copyeditor before the 15th.

With anything resembling luck, the completed book will be available before Thanksgiving. I’d really like to have the holidays off this year.

First draft of “Sudo Mastery” complete

I just typed the last words of the first draft of Sudo Mastery.

The completed first draft is available for early purchasers. As it’s no longer an incomplete draft, I’ve raised the early purchase price to $8.99. That’s more than the really early buyers paid, but less than the final price. (Selling the early drafts from my own bookstore lets me experiment, so I’m ratcheting up the price to see what happens.)

What happens now?

First, I take a couple days and do something else. Anything else. This is vital, as I need some distance from the manuscript. I know it’s a big steaming pile of bodily waste, sure. But I need to be able to see the details of how, exactly, that pile is arranged.

Then: go over the manuscript from beginning to end, looking for obvious technical and writing problems.

Then spellcheck the book. (The purpose of an as-you-type spellchecker is to slow down the writing process. Note that a grammar checker never enters into this process.)

Then solicit technical reviewers. (Don’t volunteer yet: if you do, I’ll put you on my list of people who can’t follow directions.)

Then I go to EuroBSDCon. When I return, I integrate the comments into the book in another round of testing and fact-checking and rewriting.

Off to copyeditor.

Fix what the copyeditor finds.

Then the book comes out.

I’m not writing an Ansible book…

…at least not now.

This is a “post it now so I can point to it later” piece.

I met Michael DeHaan, the Ansible creator, primary author, lead, and probably Grand Poobah, at AnsibleFest in Boston. We discussed the possibility of an Ansible book. He’s certainly open to the idea.

But we agreed that Ansible is moving too dang quickly to document in a book. By the time I finished a book, progress in Ansible would make the book obsolete. Ansible development will slow down at some time, making a book much more realistic.

I’m also not convinced that I’m the right person to write this book. I use a narrow slice of Ansible features, and other folks use a much greater set of Ansible features. My use is expanding, but still, I’m more likely to write a series of small Ansible books that reflect my growing understanding as opposed to one massive tome.

I’ll continue to document what I learn, and we’ll see what the future holds.