Slashdot Mirror


OpenBSD Book Suggestions

An anonymous reader writes "An OpenBSD book is being written and the author is looking for content suggestions to include in the book. It would be nice if the slashdot community suggested a bit or two. ;)"

1 of 69 comments (clear)

  1. OpenBSD doesn't need a book by epine · · Score: 5, Interesting


    That may be true, but perhaps the users of OpenBSD do need a book. I started with OpenBSD 2.6 after many years surviving under DOS/NT by installing POSIX shell utilities wherever possible. I knew TCP/IP networking extremely well and x86 hardware inside out. The excellent OpenBSD online documentation was a tremendous help, but it certainly left me hanging on many, many occasions. If you think OpenBSD doesn't need additional materials, it's because you're already an elite member of the OpenBSD cabal. I earned my OpenBSD stripes the hard way, but I'm not so proud of it that I think others need to strike their heals on as many rocks as I did. If every discipline takes that approach, what you end up with is highly fragmented community where no one can afford to have more than three skills and the vast majority of communication takes place between people who already share most of the same knowledge. The world doesn't have to be that way just because you find that acceptable with respect to your own narrow purposes.

    For new users setting up an OpenBSD firewall/NAT for their home network, the book needs to stress the importance of configuring the resolvers correctly. I experienced several extremely frustrating days because I didn't understand that portions of the resolver were client side. I mistakenly presumed (for a while) that bind on my firewall was acting on the localhost resolve.conf settings on behalf of the DNS clients. It took me a long time to shake off this small misconception because resolve.conf was being clobbered by /sbin/dhclient-script with extremely little documentation to warn me of this. You have to remember that new users might be learning less, vi, shell commands at the same time. The new user doesn't have the advantage of learning new functions on top of a solid skill base. I had an extremely solid skill base from a non-Unix background, yet mapping those skills onto Unix was consuming enough brain cycles that I was making small conceptual mistakes that I would not have made in a familiar environment.

    Another thing that bugged me was "Don't log in as root". I completely understood this was a good idea. However, there is a substantial skill set required to work efficiently learning how to configure and admin a Unix box using root only as necessary. New users don't have the magical knowledge the previous poster seems to assume about what operations require root and what operations don't. An 80% confidence level doesn't get you very far. If it takes ten steps to configure something and a new user has an 80% confidence at each step, when it doesn't work the first time (and it is not likely to if you have undertaken ten steps at 80% confidence) you're up the creek without a paddle in knowing where you went wrong.

    OpenBSD is actually rather weak in explaining how to dig into the system for corroboration that individual steps have worked successfully. You can find that material easily if you already know what you are looking for. I've complained about this upstream from time to time and the answer seems to be "if you don't know where to look, it's not our problem to help you".

    One thing that would have been extremely helpful at the outset was to know how to use netstat to determine which sockets a daemon was binding on and ps to determine what security context that daemon was running under.

    Another area where I made many mistakes was not knowing under what conditions a daemon needed a HUP in the ass. I be busy reconfiguring something and forget to HUP a critical process and then I would come to wild and incorrect conclusions about why my syntax was broken when in fact it had been correct already on many occassions. The OpenBSD man pages are not always blunt enough: if you change this file, you must HUP this process.

    The area where I would find the most value is advanced security and networking. I've only played a bit with Kerberos, IPv6, and IPsec. I don't know the exact list of things to examine to determine whether a daemon process is chroot exactly the right way to minimize security risks.

    OpenBSD is complex enough that you can't learn all the best practices right from day one. I put a lot of effort into mastering the firewire rulesets and OpenSSH. I didn't put the same effort into the Unix security model until a year later. I made some good guesses about what I could defer and some bad guesses. A book to help me make better guesses would have been valuable.

    At this point I've installed a dozen OpenBSD systems and most of this stuff comes automatically. I've reached the point where I don't really an OpenBSD book any more. And since I don't need this book, I'm sure no one else does either. A semblence of documenation is adequate for all comers, certainly. My struggles and setbacks were just payment for lack of
    intelligence and motivation. The logic of the previous post seems to be along the lines that handing someone a book to teach them to read is either useless or redundant. I don't agree.