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. ;)"

Comments

COMPLETE setup instructions for specific purposes

[Futurepower(R)]

I'd like sections of the book that have COMPLETE setup instructions for specific purposes such as hardware firewall, web server, and mail server. Make all the right decisions so that I don't have make them myself. Provide a CD in the back of the book that gives me everything I need. Update the book yearly, and I will buy a copy every year. You could even assume I would buy specific hardware, if that makes things easier. The cost of hardware is small compared with the cost of discovering all the quirks myself.

The biggest problem with technical books is incompleteness. An author will give about 40% of the information necessary to accomplish a task, and call that enough. The reader must read man pages and sources all over the internet to make something actually work. I'd like a book that assumes that I don't want to make particular software a lifestyle, but just want to accomplish something. Once I have something working, I can decide later how much time I want to spend becoming more knowledgeable.

The city in which I live, Portland, Oregon, USA, has what is said to be the biggest bookstore in the world, Powell's. I went to Powell's technical bookstore and looked at about 20 books on Samba. ALL of them were very incomplete, as was easily proven by comparing them with each other. ALL of them were poorly written. Most assumed that you already knew something about Samba. Samba is an important subject; file serving Microsoft OS clients using Linux is a first step toward reducing dependence on closed source software.

OpenBSD doesn't need a book

[epine]

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.