Blog

Posted on

Log Only sudo Failures

The sudo(8) privilege management tool is very admin-friendly in that it logs successes and failures. I don’t really care when my users successfully use sudo. I do care when they use it unsuccessfully, however. A sudo failure indicates that either the user doesn’t know their system password, or they’re trying to use forbidden commands.

sudo keeps logs. The interesting thing is, successful log messages are of priority notice, while unsuccessful attempts are of priority alert. This opens up an easy way to improve security and customer service.

First, a user who cleverly gets root can edit your log files. forward your sudo logs to your logging host. Your users should not have access to your logging host.

First, split your sudo logs out into two logs. You can set sudo’s syslog facility, but as I’m always short on facilities, I tend to break sudo out via program name. Here’s a syslog.conf entry.

!sudo
*.* /var/log/sudo
*.alert /var/log/sudofail

Touch the files, restart syslogd, and /var/log/sudofail will contain only password failures and attempts to run forbidden commands. The two log entries are very different.

Sep 26 10:37:27 caddis sudo: mwlucas : command not allowed ; TTY=ttyp0 ; PWD=/home/mwlucas ; USER=root ; COMMAND=/sbin/reboot
Sep 26 10:53:09 caddis sudo: mwlucas : 3 incorrect password attempts ; TTY=ttyp0 ; PWD=/var/log ; USER=root ; COMMAND=/usr/bin/su

Separating this log out opens some interesting customer service possibilities. If you’re on OpenBSD, you can automatically have newsyslog email you the log of failures. Otherwise, you can set up a separate script to do that, or feed it to your alerting system, or whatever. Then have a helpdesk minion call the user in question and ask what they’re trying to do. Perhaps they’ve forgotten their password. Perhaps someone else got access to their account. Perhaps they’re having trouble. Maybe they need sudo -l explained to them.

The end user will either feel like you’re watching out for them, or realize that your sysadmin group watches the systems very closely.

Even if you don’t take proactive action, having sudo failures logged to a separate file simplifies digging through the logs.

Posted on

On Bogus Book Reviews

There’s been a furor recently about authors faking reviews in one manner or another: Either by buying reviews, or by sock puppetry. As nobody can generate reams of morally-outraged words like offended writers, it’s created a pretty big buzz in the publishing world. Here’s my thoughts on these types of reviews. For brevity, I lump all of these reviews into a category I’m going to call “fake reviews.” It’s not strictly accurate, I know, but I can’t come up with a better phrase at the moment.

I’m not outraged. I’ve expected this. Perhaps it’s my computer security experience, but any system that permits this kind of exploitation will be exploited. Publishing is no magic kingdom exempt from the rule of self-interest. Just because I’ve expected this, doesn’t mean I approve of it.

Reviews are important. I depend on reviews for sales, and I depend on sales to write new books. Would I like hundreds of five-star reviews? Sure.

Would I pay for them, or sock-puppet them? No.

Purchasing reviews betrays a lack of confidence in your work. If your work is good, if it has an audience, that audience will find it. Eventually.

Writing is a long game. You must have patience. In traditional publishing, a paperback book has about three months to find a readership. Today, with ebooks, online ordering, and print-on-demand, books can take years to find a readership. (My nonfiction books are different, mind you; one factor that goes into deciding if I should write a book is if I expect it to have at least a three-year lifespan. My books have considerably less time to find readers. Lucky novelist bastards.)

The fact that I’m not willing to pay for good reviews means that I have to ask my readers for them. I walk a careful line between groveling for exposure and annoying my readers. So far, I seem to have erred on the side of not annoying my readers, but I’m OK with that. It’s better to get fewer reviews than alienate your readers.

I send books to book reviewers. They want books to review, I want book reviews. It’s a fair trade.

I can’t say that I would never buy a review. Never is a strong word. Purchasing a review from a reviewing business would be a business decision. But if I ever do buy reviews, they will be disclosed as such.

On the other side of this coin:

I occasionally review books, both on Blather and on Amazon. I frequently know the authors of these books. I don’t consider these reviews fake, but I do try to disclose my bias.

If I review a book on this blog, it’s because I honestly think it’s awesome, or because it fills some desperate need and it’s “good enough,” or because it changed how I think about things. I review some books from No Starch Press, because they always ask me if I’m interested in their new titles. I don’t review all the books they send me. In part that’s because I’m lazy. In part it’s because I’m working on my own books. But I find the time to review the truly exceptionally awesome books they send me. (Which reminds me, I owe them a review on the Magna Guide to Linear Algebra.)

I also review fiction books I really enjoy, but not as “Michael W Lucas, Famous-in-a-real-small-world Author.” Usually those go up under my family’s Kindle account. Do I know those authors? Some of them, sure. I’m a writer. I make friends with other writers. We sit around smoky rooms late at night, sipping absinthe and bemoaning how unfair life is to us artistic sorts. But most of my blog readers don’t really care that I think that Harry Connolly’s 20 Palaces books are unquestionably the best modern fantasy of the decade, and that everyone interested in that genre should purchase them all, immediately. You’re here for other reasons. (I have no idea what those reasons are, but they’re something about technology. Or writing. Something like that.)

For example, I didn’t know Chris Sanders before reviewing Practical Packet Analysis. But we’ve exchanged emails several times since then, and if I ever get to his part of the world I’ll ask him if he wants to get barbeque. It’s called networking, and it makes your career go. But if he ruins the (purely hypothetical) third edition of his book, that connection won’t make me give him a five-star review. I’ll just quietly not review it.

Same sort of thing Peter Hansteen and his Book of PF, although my chances of getting to Norway aren’t very good. And Norway isn’t noted for their barbeque. (What do they eat in Norway, anyway? From my observations at tech conferences, the answer seems to be “beer.”)

I occasionally write reviews about books by writers I know. It’s a small world.

If I write a review, in any genre of book, it’s because I honestly think a book is awesome. I’ll give that book 4-5 stars. I won’t give someone a 5-star review just because I’m their friend, however.

If I read a book and I enjoy it, but it’s not awesome, I won’t review it. Just because a book doesn’t set fire to my brain doesn’t mean that book won’t speak to someone else. In computer book terms, just because a book is about Windows 7 doesn’t mean that it’s a bad book. It’s just not for me.

Would I ever give a book a 1-star review? Sure. If a book is unprofessionally done, I’ll excoriate it. Sentences have these things called “verbs” and “nouns,” and are built with this thing called “grammar.” If a book completely fails to meet my standards for competent wordcraft, I feel free to label it a failure.

But usually, when I get crap in my eyes I close them.

Posted on

Absolute OpenBSD status, 9 Sep 2012

Those who have been following my Twitter feed know most of this, but here’s the status on this book.

  • Chapters 0-10 have been sent to No Starch. They’ve done initial edits on 0-5. I’ve responded to those edits, so they’re now off for Hansteen’s tech review.
  • Chapters 11, 14, and 17 have been sent to Henning for informal review.
  • Chapters 12, 13, and 20 partially exist.
  • Other chapters are outlines, notes, fragments, script(1) sessions, etc.
  • Oh, and the Afterword exists. Mainly because it’s 90% stolen from my blog. But still, I can cross it off the list.

    Why are things written out of order? Depends on what I’m doing at the time. Also, some chapters can be written without Internet access. Otherwise, I write chapters in order.

    I believe I’ve chopped down the outline to where it needs to be for a book roughly the same size as Absolute FreeBSD. Chapter titles are subject to change. Heck, everything is subject to change.

    0: Introduction
    1: Community Support
    2: Installation Prep
    3: Installation Walk-Through
    4: Post-Install Setup
    5: Booting
    6: User Management
    7: Root, and how to avoid it
    8: Disks & Filesystems
    9: More Filesystems
    10: OpenBSD Security Features
    11: IPv4 & IPv6
    12: Network Connections
    13: Software Management
    14: /etc
    15: Maintenance
    16: Daemons (sensorsd, snmp, etc)
    17: Desktop OpenBSD (cwm, tmux, etc)
    18: Kernel Configuration
    19: Building Custom Kernels
    20: Upgrading
    21: Packet Filtering
    22: managing PF
    23: edges
    Afterword

    Trimming to this length hurt, but one of my critical design goals is to write a book small enough to hold in the bathtub. I might sometimes recommend books that exceed that limit, but they have to be freaking awesome books.

    One thing that helps is Peter Hansteen’s Book of PF. It didn’t exist when the first edition of AO came out, so I needed to do pretty exhaustive coverage into PF. My coverage of primordial PF took three chapters in the first edition, and PF and family has roughly doubled its features since then. He does an excellent deep dive into PF, so I can reduce those chapters.

    I’ve talked about word count before, but I need to stop doing that. The book has flailed around enough that the number of words I write isn’t exactly useful. I wrote 7,000 anti-words on Chapter 17 before sending it to Henning, for example.

    On the plus side, the AO2e narrator now sounds a little less Dexter Morgan and a little more BOFH. That’s probably a good thing.

    • Posted on

    OpenBSD read-only ports tree with restrictive sudo

    The OpenBSD folks strongly encourage users to use packages for software management. Most of the time, their packages just work. But sometimes, you must use a port.

    OpenBSD includes an updated Apache 1.3 server, and recommends that everyone use it if at all possible. (There’s also nginx, which is the future platform, but it’s not quite integrated yet.) I have a Web application that only runs on Apache 2.2, so the included Web server is not an option. OpenBSD provides an Apache 2.2 package for people like me, which is very kind of them. But I need an Apache 2.2 with LDAP authentication support. That means I must build Apache 2.2 from a port.

    If I have to use ports, then I want to do so as easily as possible. When I need to upgrade my ports, I want to be able to remove /usr/ports and extract the tarball that goes with whatever snapshot I’m running. I need the ports tree to do all its work, and store all its packages, outside the ports tree itself. This means a read-only ports tree.

    I’m running the August 22 i386 snapshot everywhere. I build packages from ports on one machine and share out the package repo via NFS.

    I dislike running as root for routine tasks, like building ports on the port-building machine. The ports tree supports using sudo for privileged operations. I don’t want to be continually interrupted to enter my password, though. And I don’t want to give unlimited root access via sudo without a password. This means that I need to lock down my account on this machine to only those activities needed to build packages from ports. I readily concede that building packages requires high-level privileges, but there’s a world of difference between rm -f /usr/ports/* and rm -rf /*. Could an intruder exploit this? Absolutely. You must run make(1) as root to build a port, and you can run fdisk(8) via make. But it will protect me from operator error. And my operators make errors.

    I also want my minions to be able to build packages without giving out root. Because, you know, logging into a system and typing a command because someone else needs a package is extra work for me.

    So, how to do this?

    First, create a system group for people who may build packages. This group contains two users, myself and lasnyder. From /etc/group:

    portbuild:*:10001:mwlucas,lasnyder

    My /home partition has lots of space, so I’ll build everything there. First, we need four directories:

  • one for building stuff: /home/ports/wrkobjdir
  • one for completed packages: /home/ports/pkgrepo
  • distfiles: /home/ports/distdir
  • package plist database: /home/ports/plist

    Create these directories, and set their ownership (as well as /home/ports) for group writing.

    # chgrp portbuild /home/ports/*
    # chmod 775 /home/ports/*

    Any user in the portbuild group can write to these directories.

    Now tell the ports system about these directories. Make the following entries in /etc/mk.conf:

    WRKOBJDIR=/home/ports/wrkobjdir
    DISTDIR=/home/ports/distdir
    PACKAGE_REPOSITORY=/home/ports/pkgrepo
    PLIST_DB=/home/ports/plist
    SUDO=/usr/bin/sudo

    (The sudo isn’t necessary for the directories, but I’m not going to send you back later to add it. That would be lame.)

    Now for sudo. Give everyone in the portbuild group permission to run any command in the PORTBUILDCMDS alias.

    %portbuild ALL= NOPASSWD: PORTBUILDCMDS

    Now create the PORTBUILDCMDS alias. I built this alias iteratively: build a port, wait for the build to fail, add the missing command with the tightest restrictions that seem sensible, clean the port, and remake it. The following alias was sufficient for everything I tried:

    Cmnd_Alias PORTBUILDCMDS = /usr/bin/install, /usr/sbin/chown, /bin/chgrp, /bin/sh -c umask, /usr/sbin/mtree, /usr/bin/touch, /usr/bin/env, /usr/sbin/pkg_create, /bin/rm -f /home/ports/pkgrepo/*, /usr/bin/make, /usr/bin/perl /usr/ports/infrastructure/bin/*, /bin/chmod 555 /home/ports/*, /bin/mkdir -p /home/ports/*, /bin/rm -rf /home/ports/*

    Now choose a port and build it.

    # cd /usr/ports/editors/vim
    # make clean && make

    (When testing, I always clean a port before building it.)

    You might find that the build stops and you’re asked for a password. This means that sudo is trying to run a command that’s not in your command alias. Go ahead and enter your password. The build will fail, because you don’t have privileges, but you’ll get an error message in /var/log/secure. Between the error in the terminal window and the error in the log file, you should be able to figure out exactly which command failed.

    It’s impossible to know ahead of time every command that will ever be used by any port that ever exists. This iterative process is a pain at first, but once you’ve built a few ports you’ll find most of the necessary commands. The sudoers command alias I include here was sufficient to build editors/vim, which calls in python, dbus, glib, three different autoconfs, tcl/tk, CUPS, and a whole bunch of other crap. (I don’t use vim myself, mind you, but if you want a port that hauls in whole bunches of stuff, it’s a good choice. I could have built Emacs, but I wanted the build to finish today.)

    In building the first port, the ports system creates a temp directory, /tmp/portlocks. The ports system doesn’t use sudo to access this directory, and the directory is owned by the user who built the first port on this system. Change the group and assign group privileges to this directory.

    # chgrp portbuild /tmp/portslocks/
    # chmod 775 /tmp/portslocks/

    (Is this a bug, or a feature. I dunno. But I’m sure that some reader will tell me.)

    It seems that not all ports can be built without running as root. This isn’t a usual configuration, so I’m not shocked that not all code paths are tested — especially when building random software from random authors. When I tried to build devel/autoconf/2.59, I got:

    ===> Building package for autoconf-2.59p3
    Create /home/ports/pkgrepo/i386/all/autoconf-2.59p3.tgz
    Warning: @option no-default-conflict without @conflict
    mv: rename /home/ports/pkgrepo/i386/tmp/autoconf-2.59p3.tgz to /home/ports/pkgre po/i386/all/autoconf-2.59p3.tgz: Permission denied
    *** Error code 1

    I reported the error to ports@ like a good little user. It’s a holiday weekend, so I’m also not surprised I haven’t heard back.

    I only hit this error after building fifty-odd ports, though. It appears that limited sudo permissions are doable.

    • Posted on

    Technology versus Democracy

    Yesterday’s election was mostly a primary, but also included a few millage issues. The purpose of a primary is to keep the obvious maniacs from getting onto the final ballot, so I make the effort to vote. (Your definition of “obvious maniacs” probably differs from mine, but that’s okay.)

    I’m waiting for verification, and am glad to see that they’ve finally replaced the big printed books with a laptop. But all of the verification people are standing around the laptop, getting more and more frustrated. One of them is on the phone. “Yes, we entered the password. No, it’s not letting us into the site. He’s entering it again. Yes, I’m sure the Caps Lock key is off. He’s trying again. Yes, the password we’re using is ‘election’.”

    I’m third person in line. The line is growing quickly behind me. I peer at the laptop, lean in, and quietly say “Excuse me, but your Caps Lock light is on.”

    The guy at the keyboard turns off Caps Lock, the password is entered, and the poll workers quickly get us all through. Everybody hails me as a technical genius. Which I might well be, if you define “genius” as “someone who looks to see WHICH LIGHTS ARE ON.”

    I have three points to make on this seemingly pointless anecdote:

  • In discussions about electronic voting machines, remember: these are the people who have time and interest to work the polls. They have no awareness of good security practice. They don’t troubleshoot, because they don’t really know how to. It’s not a question of age: one of the people was a senior citizen, two were middle-aged, and one mid-twenties.
  • If you have time to volunteer as a poll worker, do so. Democracy isn’t about voting; it’s about doing things to help your community.
  • I am the savior of democracy. In Precinct Three, at least.

    • PS: I didn’t include the real password here, but the actual password was just as bad.

    Posted on

    FreeBSD: portmaster with pkgng

    I recently tried FreeBSD’s pkgng, based on Ivan Voras’ blog post. Days after getting the new machine set up, though, I got this in my daily status mail:


    Checking for packages with security vulnerabilities:
    Database fetched: Fri Aug 3 03:02:57 EDT 2012
    apache-2.2.22_5 is vulnerable:
    Apache -- Insecure LD_LIBRARY_PATH handling

    WWW: http://portaudit.FreeBSD.org/de2bc01f-dc44-11e1-9f4d-002354ed89bc.html

    php5-5.4.4 is vulnerable:
    php -- potential overflow in _php_stream_scandir

    WWW: http://portaudit.FreeBSD.org/bdab0acd-d4cd-11e1-8a1c-14dae9ebcf89.html

    Where did this come from? A bit of poking around my system leads me to /usr/local/etc/periodic/security/410.pkg-audit. My first question is, where did this file come from? pkgng includes an equivalent to the old pkg_info -W:

    $ pkg which /usr/local/etc/periodic/security/410.pkg-audit
    /usr/local/etc/periodic/security/410.pkg-audit was installed by package pkg-1.0.r4

    pkgng gives you an audit of your packages in the daily mail. Excellent. It’s a DragonFly feature that I really like, and long overdue in FreeBSD.

    So, how to upgrade the insecure ports? Unfortunately, I’ve had to build apache from source. I can’t use packages. That means I need to build the new version from ports. I get the new version ports tree with:

    # portsnap fetch extract

    I like to use portmaster for managing my ports. I’m told it works with pkgng. Let’s find out. First, tell ports that we’re running under pkgng by setting a variable in /etc/make.conf:

    WITH_PKGNG=yes

    Now install portmaster:

    # cd /usr/ports/ports-mgmt/portmaster
    # make all install clean

    But portmaster doesn’t seem to work with pkgng:

    $ portmaster -L
    ===>>> Root ports (No dependencies, not depended on)
    ===>>> 0 root ports

    ===>>> Trunk ports (No dependencies, are depended on)
    ===>>> 0 trunk ports

    ===>>> Branch ports (Have dependencies, are depended on)
    ===>>> 0 branch ports

    ===>>> Leaf ports (Have dependencies, not depended on)
    ===>>> 0 leaf ports

    ===>>> 0 total installed ports
    ===>>> There are no new versions available

    A bit of research shows that portmaster needs to be patched before it works with pkgng. (Portmaster has a large install base, the portmaster maintainer is very careful about not messing up existing users, and pkgng is still very young. I’m confident that portmaster will work with pkgng by the time pkgng becomes the default.) You can get the patch on github.

    Now build portmaster with the patch.

    # cd /usr/ports/ports-mgmt/portmaster/
    # make patch
    # cd work/portmaster-3.13.13
    # patch < $HOME/patch-portmaster-pkgng
    # cd ..
    # cd ..
    # make all install

    I keep the patch in my home directory, because any time I want to rebuild portmaster I must reapply the patch. And if the patch fails, I must check for a new patch.

    Try the new portmaster:

    # portmaster -L
    ===>>> Root ports (No dependencies, not depended on)
    ===>>> pkg-1.0.r4
    ===>>> New version available: pkg-1.0.r5_1
    ===>>> portmaster-3.13.13
    ...

    Much better.

    I’ll start by upgrading pkgng itself, then my other ports. I use:

    # portmaster -d --no-confirm pkg

    Use whatever portmaster options you prefer, of course. With the pkgng patch, portmaster seems to behave exactly as you expect. But the only way we’ll know for sure is if you test pkgng in your environment and file bug reports with the appropriate maintainer.

    Posted on

    BSDTalk #218, featuring… Me!

    Will Beckman interviewed me at BSDCan. That interview is now available as BSDTalk #218.

    Some of the issues I mention in the podcast are now solved. SSH Mastery is easily available in print in Europe. (You want the print copy as well as the ebook. You know you do.)

    Posted on

    FreeBSD Ports Annoyance

    Ivan Voras’ article on FreeBSD’s pkgng prompted me to try pkgng. pkgng works exactly as advertised, with a couple of minor annoyances. But this brought to head a problem with FreeBSD that I’ve had for a while. I’ve talked to various ports guys about it over the years. It’s an engineering problem that’s begging for someone to solve.

    Before folks in other Unix-like operating systems start snickering at “Lucas turning like a rabid dog on the community he came from”: you guys have your own problems. Go deal with them.

    First, some context:

    When the Ports Tree started it was pretty durn good. It might have started life as a temporary workaround, but it came out all right. Ports was the envy of many operating systems, and it got dragged into other BSDs and copied elsewhere. And in many ways, it’s actually aged pretty well. I run all three “Big BSDs” and a DragonFly box. I administer CentOS and Ubuntu machines. I have a couple of OpenSolaris servers slated to be replaced with FreeNAS. I feel qualified to offer an opinion on how things compare. FreeBSD trumpets its performance as a network operating system, as well it should. It passes packets like “whoa.” It makes lots of complicated stuff easy.

    But some simple tasks are harder than they should be.

    I’m standing up a new server to replace my old Web server. The old server originally ran 6-current, and has been updated to -current every few months. Now and then, Apache hangs up. I’m fairly confident that some lingering cruft from a previous aeon is responsible, and while I could exhaustively search the old server for the problem, I’d rather send it off to a well-deserved retirement and put some new hardware in play.

    So, I have a virgin server. I want sendmail, mutt, and a WordPress server. (Your choices might differ, and that’s fine.) I don’t care which Web server WordPress runs on, anything vaguely modern would do. I’d like to install all software from packages, as I don’t have the time or energy to build an artisan server. Ideally, I won’t even need to install the Ports Collection. This is an extremely common set of software.

    I can do this easily on OpenBSD, because OpenBSD has One True Web Server. It’s Apache 1.3, yes, which makes my bowels churn a bit, but the OpenBSD Project stands behind it, so: fine. I can do this with CentOS or Ubuntu or OpenSolaris — I have to install new repositories, which brings up all kinds of trust issues, but when you run those operating systems you decide to evaluate those risks on an ongoing basis. Fine. (I must confess, I’ve never installed a Web server on my NetBSD palmtop. That’s too geeky even for me.)

    But I just can’t do this with FreeBSD.

    The Ports System is massively flexible. If I’m willing to build from source, I can configure my system in dang near any way I like. That’s an awesome feature. It really is. The Apache 2.2 port has about eighty configuration knobs. I can tweak them all. I can build Apache exactly as I want and be highly confident that it will Just Work.

    This is amazing.

    But I can’t install a WordPress server with precompiled packages.

    The problem is in the PHP port. PHP doesn’t know which Web server you’re running. The Ports System gives you the flexibility to build PHP with or without the Apache module. You can build with or without every dang module in the world. The PHP port doesn’t tie your hands.

    But without these — comparatively tiny — bits of precompiled glue, I can’t make FreeBSD Just Work.

    And it’s not just WordPress. I run an LDAP server at work. Apache 2.2 can be compiled to include the OpenLDAP module. But I cannot install this common corporate configuration from packages, I must compile the software myself. If I want OpenLDAP and Postgres, well, that’s a different build. And if an application absolutely requires MySQL, it’s back to the Ports Tree.

    Multiply this by the thousands of combinations of options in over 23,000 ports, and… wow. Building a package for every possible combination would take a long time.

    I can — and do — build my own package repositories. But this is an ongoing annoyance. And if I need an Apache 2.2 server that supports OpenLDAP, MySQL, and Postgres, I’m back to building it myself.

    The Ports System makes the difficult manageable. I’d much rather maintain my own FreeBSD package repo than a CentOS or Ubuntu/Debian repo. But I really shouldn’t have to.

    I’m not saying “copy Linux.” By all that’s sacred, no. NO. But they’ve solved this problem without building umpteen bajillion packages. We have some really brilliant people in the community. Surely there’s a realistic solution to this?

    I pimp BAMP (BSD, Apache, Mysql, PHP) as an alternative to LAMP. This particular example of this issue stops those efforts cold.

    Just in case you’re one of the brilliant people in our community, and this motivates you to do something, as a sysadmin who wants to run a lot more FreeBSD, here’s what I’d like to see:

  • Don’t rely on external package repositories. Every time I need to add a new repository to make some Linux package work, my blood turns to icewater and the voices in the back of my head start gibbering again. FreeBSD has a centralized model. I trust FreeBSD’s central package builds; they’re highly consistent, and if they get compromised, I will hear about it.
  • I’d like to be able to set variables in, say, /etc/make.conf or /usr/local/etc/pkg.conf that say what combination of software I use. Say, WEBSERVER=apache22 and DATABASE=postgres91. There are ports that will configure the ports-building process for me, such as ports-mgmt/portconf; I’d like something similar for packages.
  • When I install a new server, I want to be able to copy the config file in, run pkg add wordpress, and have the package system say “Aha! The Boss wants to run this webserver, and this database, but the software package doesn’t support his chosen database, so I’ll install MySQL anyway.” It should then just Do The Right Thing.

    • Why don’t I fix this? I’m a sysadmin, not a programmer. Hogs, when they look at my code, vomit. My spare time is spent writing, most often in support of the various BSD communities. I could learn to fix it, but I believe that others are better qualified to do it first. But those most likely to be able to fix it are also those most likely to just build the software themselves.

    We run operating systems to use applications. (If that wasn’t true, I would have truly mastered my Sinclair ZX80 by now.) The new user, confronted with a requirement to install the Ports Tree to build a simple PHP webserver, might well say “ick” and install something else instead. It’s a serious barrier to entry.

    So, if you’re looking for a new problem to solve, here it is.

    Posted on

    Writing New Editions

    This post is, “how is the new edition of Absolute OpenBSD coming along?” with a bit of musing on the craft of writing a second edition added in.

    I’m always shocked by the number of systems administrators ignorant of networking basics. I don’t care that they don’t know how to choose between BGP and OSPF, or that they don’t know what those acronyms stand for. That’s not relevant to most servers. But lots of them don’t know what an IP address is, or how to recognize a valid netmask, or the difference between TCP and UDP, or why there’s an /etc/protocols file. Any sysadmin who doesn’t know these things is still an amateur. My goal in writing a book is to drag people a little closer to professional.

    So, I include a chapter on networking basics in my introductory sysadmin texts, just like I include chapters on user management.

    I have a chapter on IPv4 networking in three published books. I’m writing this same chapter for the fourth time. I can’t just copy-and-paste from earlier editions. First, that would be rude. Second, my understanding of TCP/IP has changed in the last ten years, and that changes how I approach the material.

    But I can use the earlier efforts as models. Some text I can almost reuse, because it’s still the best way I know of to explain the specific topic. This will be the third time I use the dinner table analogy, for example. I still pass it through my brain to my keyboard, however, freeing myself to tweak a few words in the process.

    The most recent IPv4 chapter I wrote was for Absolute FreeBSD. In this incarnation, the chapter included a couple pages of basic binary and hexadecimal math. I looked at this, and thought “Why did I cover this? Doesn’t everybody know it?”

    Then I thought back, and realized that I included those pages because at the time I wrote the book, I spent a fair amount of energy teaching that material to my coworkers.

    I flipped back through the earlier editions of these books. Each book had one or more sections that I included because coworkers didn’t know it.

    At the moment, I’m not responsible for teaching anyone anything. I have no tech minions, and am molding nobody. It’s definitely changed my mind about what topics I cover. I suspect that the new edition of Absolute OpenBSD will contain less basic material. I’m definitely assuming that you know how to do binary and hexadecimal math, for one thing. This leaves room for more advanced topics.

    My conclusion seems to be: if you find the new edition of Absolute OpenBSD moves too fast, I suggest you get a copy of Absolute FreeBSD as well, or reread the one you have.

    (Mind you, the no-minions-to-mold is about to change. After two years of minion-free peace, I have been given a minion to mold. He’s on vacation at the moment, and has no idea what awaits him on his return. I have no desire to ruin his last few days of freedom, so we’re waiting for his first day back to tell him what he’s been sentenced to. The poor bastard.)

    So, where am I on the second edition of Absolute OpenBSD?

    If you want the minutia of my progress, search for the #ao2e hashtag on Twitter. But at a larger level, I’m writing the chapter on IPv4.

    This seems to be about 40% through the first draft of the book. The manuscript has proceeded quickly, now that I’m not moving into a house that needs work to be habitable. I’m hoping that this pace continues.

    I’ve received initial feedback on chapters 1-8 from Henning Brauer. Then the chapters go to Nathan Houle, my editor at No Starch Press, then back to me for corrections and discussion. Then they go to Peter Hansteen for formal technical review. Then back to me for correction. Then copyedit, back to me for correction, page layout, and back to me for correction.

    So, it’s not 40% done. The first draft is the hardest part, however. Doing the math, though, I see that I’ve been through an IPv4 chapter at least twenty times, given all the cycles. No wonder writing it is causing me nausea and chest pain.

    The original outline calls for a book about 400,000 words. For reference, Absolute FreeBSD is close to 300,000 words. This is too dang long. One of my goals is that my books be small enough to read in the bathtub.

    As SSH Mastery was successful, I have a resolution. I think I’ve figured out topics I can extract from the book and publish separately, without damaging the integrity of the book or its usefulness. Not everybody needs to know about, say, OpenBSD’s wireless features, but it’s certainly a topic worth covering. I can do small books on those topics and publish them as an aside, making the content available to interested readers. Assuming that the reader is a competent OpenBSD sysadmin (e.g., they’ve read Absolute OpenBSD 2nd ed or have an equivalent combination of education and experience) will let me do these books almost as easily as if it was integrated into the book. And my initial market research indicates that my readers are amenable to smaller, single-topic books.

    In summary: book is underway. More books coming.

    Posted on

    Cisco radius auth for users and enable

    All authentication on my network (with carefully selected exceptions) should be centralized. This includes router administrative logins via telnet or SSH. My authentication information is in an OpenLDAP 2.4 server. Attaching Cisco gear to an OpenLDAP database is hard. But attaching Cisco gear to RADIUS is pretty easy. But my FreeRADIUS server uses LDAP as its back end, and attaching Cisco gear to RADIUS is pretty easy.

    To have your enable password, you’ll need an LDAP user called $enab15$. Take careful note of how that is spelled: dollar sign, ENAB, the number 15, and another dollar sign. There is no L, and no second E. Add this user to any LDAP groups needed for RADIUS access. This user’s password is your enable secret.

    Create a loopback address for the router.

    interface Loopback0
    description management
    ip address 192.0.2.13 255.255.255.255

    Use this address for all router management functions. If you use an IP for a real interface for management or monitoring, you can have trouble when that interface goes down.

    Then tell the router about your RADIUS servers. Always list multiple RADIUS servers. If you have only one RADIUS server, get a second, preferably on a completely different part of your network.

    ip radius source-interface Loopback0
    radius-server host 192.0.2.253 auth-port 1812 acct-port 1813 key RadiusSecret
    radius-server host 192.0.2.252 auth-port 1812 acct-port 1813 key RadiusSecret

    Create a local enable password and a local user with administrative privileges. These will come into play when your RADIUS servers fail. (Hopefully, they never will. But assuming things will go well sets yourself up for a really bad day.)

    enable secret 5 $1$lnds$LNrkh4d8aoeuY/Q2Akm1k7
    username admin privilege 15 password 7 1D1C1B050B8290E1

    Now attach the radius servers to the authentication system.

    aaa new-model
    aaa authentication login default group radius local
    aaa authentication enable default group radius enable

    With this setup, your Cisco will try radius first, and then fall back to the local authentication file if your RADIUS server does not answer.

    You might also need to attach your virtual terminals to your authentication settings.

    line vty 0 4
    login authentication default
    line vty 5 15
    login authentication default

    You should now have Cisco user names and the enable password synchronized with LDAP, through RADIUS.