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

As an avid OpenBSD user...

[moonboy]

As an avid OpenBSD user, I've thought (for sometime now) that an OpenBSD book would be fantastic! The existing documentation for OpenBSD is already very thorough, however, it can be a little daunting for newbies to the OS. Parts of the install process (particularly file system creation) are a little difficult to understand at first (yet quite simple and efficiient once understood). Also, the fact that there is no GUI makes it somewhat difficult for newbies to get "into it". So, basically, I'd work on making a good introduction for new users or those new to UNIX-like OS's altogether.

Also, I've often thought other ancillary things could be covered as well to make the book (like OpenBSD itself) more of a "computer security" book that uses OpenBSD (arguably the most secure OS available) as its central focus. These topics could include OpenSSH, OpenSSL, the (further) hardening of OpenBSD (yes, that's right, even OpenBSD can be "hardened"), how OpenBSD integrates encryption, creating VPN tunnels between OpenBSD boxes, etc.

Just my 2 cents.

Re:As an avid OpenBSD user...

[moonboy]

Sorry for the miscommunication, I was in fact referring to the being no graphical installer.

Re:Uh... got that backwards?

[OrangeSpyderMan]

Indeed, at the risk of watching my karma burn this does seem a little like:

1. Decide to write a book about...
2.???
3.Profit.

:-)

I'm not sure...

[3-State Bit]

...whether it's FreeBSD or OpenBSD, but probably either way it's a good idea to address OS X in any book about BSD -- after all, OS X has been called the best unix desktop by loads of hardcore unix journalists. Since "BSD is dying" according to my sources (slashdot trolls below my threshold), OS X may be the most important issue to address.

MS-DOS -- no remote root exploit in 27 years against an UNPATCHED system.

Re:I'm not sure...

[cant_get_a_good_nick]

MS-DOS -- no remote root exploit in 27 years against an UNPATCHED system.

Abacus, no remote root exploit in 800 years against an upatched system.

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.

Well..

[roka]

I think it should cover the difference between OpenBSD and Linux, since many people are switching from Linux to OpenBSD, nor?

Also only advanced subjects should be covered, for most users already have experience in an unix-like environment.

I personally would like to see ALTQ expatiated.

Re:Well..

[innosent]

I agree, though it doesn't necessarily need to cover the differences, just maybe tout a few of the traits of the BSD's and OpenBSD specifically. One easy example is the secuity issue. I also think some history from at least 4.4BSD should be covered, since "The Design and Implementation of the 4.4BSD Operating System" is an excellent book and covers the earlier history. Definitely should point out that the OpenBSD camp leans heavily towards security and stability in general.

The book should also cover topics on the basics, configuring services to be run at init, but should avoid trying to be a "Complete Reference", since no book ever really is. Just some basic administrative tasks, things that any sysadmin would do on a regular basis (configuring, building, and testing a new kernel), and the things none of us ever really want to have to do (Recovery of bad slices). Hardware configuration should also be covered, as that is certainly one of the more difficult things for the Win95 and up generation. (What, you mean I actually have to know what I have inside that shiny metal box thingy?) Leave the specifics of major services (DNS, Web, *mail, etc...) up to the books written for them, just overview the services, and give sysadmins a good reference.

That reminds me... If anyone has ever read the Coherent (circa 1994) manuals, those were excellent, and I wish there were something like that now. Complete command references, system architecture overviews, good stuff that is useful to admins and newbies.

This is not a sig. (No really, it's not)

Re:Well..

[R.Caley]

I think it should cover the difference between OpenBSD and Linux, since many people are switching from Linux to OpenBSD, nor?

Who's gonna read a huge list of smalldifferences in command line switches and file locations? The BSDs have worthwhile documentation in any case, so man-whatever will get most of this information.

Similarly there is little point in having chapters about how to do IPsec or whatever. Online resources are much better and can be kept up to date as things change.

The only thing a book is really good for is talking about fundamentals. The kind of stuff where, if you ned to know it, you would go sit in a comfy chair and study. taking McKusick et-al as a model and writing up information on the newer and OBSD specific things would produce something well worth paying for.

Come to think of it, if someone wants to do that for FBSD, they'd have at least one sale....

documentation

[ChrisMWage]

OpenBSD doesn't need a book. OpenBSD is one of the few operating systems that makes a practice of actually maintaining some semblance of documentation.

See "man help" and http://www.openbsd.org/faq/index.html

Re:a book?

[Rick the Red]

I have to disagree. I bought my first Linux book years ago, long before billg even heard of it. Also, I use OpenBSD as my firewall, and while I'm an experienced Unix user I'm by no means a seasoned admin. I'm a computing professional and I'd never claim admin skills when applying for a job, yet here I am running an OpenBSD firewall. I need all the help I can get, and while the OpenBSD man pages are great, the Linux HowTos are where I turn for generic help -- an OpenBSD specific book would be a blessing.

So this book will be ..

[noselasd]

Ahremm. You want slashdotters to contribute to this book ?? I thought this would be a serious book.

$300 OpenBSD server? Yes, I'll take one.

[Futurepower(R)]

Corrections and additions to my post above:

"...file serving Microsoft OS clients using Linux ..." should have been "BSD or Linux", of course.

I'd like a book to show me exactly how to set up a $200 Microtel PC to be a web server. The total cost of the PC, book, and shipping would be under $300. I'd plug it into a switch connected to DSL and use it with a fast-switch DNS service as a backup when my web host is having problems. I'd use it as a test machine for CGI programs. I'd host low-traffic web sites. It would be great knowing that I was using an extremely secure OS set up by an expert. I would read the book to make adjustments.

What is the true cost of a $50 book that requires 80 hours of work finding additional information? Answer: Thousands of dollars. All the books I find at Powell's technical bookstore drag me over the coals. That's no way to treat a customer.

Okay, now I need a file server for workstations running Microsoft operating systems. In any real-world application, I won't mind paying $300 again for another machine and another book. I certainly don't want to take chances messing with the web server. I would just plug the 2nd computer into another port on the network switch. I'd want true plug and play, so that the biggest problem would be convincing a customer that I was serious when I quoted the cost.

So now I'm really impressed. I've run into situations recently where two ISPs have had problems at different times with their mail servers. I want a backup mail server, with web mail, so that corporate communication is not completely disrupted when the main, commercial mail server is down. Another $300 for another computer and another book is a trivial, trivial expense compared to employees having trouble communicating. I'd issue everyone an emergency mail account and tell them to use it when there was trouble.

Total cost for hardware and books? Less than $1,000, and each computer is a backup for the others.

Once I've got three systems running OpenBSD, I would be in the market for more advanced books. If the three books I'd already bought had served me well, I would want a book from the same publisher.

Re:Theo manual

[mirabilos]

I do maintain some unofficial patches myself, such
as midnight commander and *grin* daemontools 0.76
(the page above still lists 0.70)...
http://mitglied.lycos.de/tygs/pub/my-por ts.tgz

Note that however they aren't guaranteed to compile
under stock OpenBSD, I also maintain a >1MB patch set.

More ports documentation would make use, yes.
And maybe a Theo-HOWTO :)

Photos from _all_ developers (with cvs ci access).

Re:Theo manual

[mirabilos]

It's not even right:
- for all DJB software, you can distribute patches
- for djbdns and qmail, you can distribute distfiles

You must not, however, distribute (patched) binaries.

It's not as worse as Java(R)(tm).

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.

Re:Theo manual

[mirabilos]

Wrong. Just do a quick grep for PERMIT_PACKAGE
through all Makefiles in /usr/ports and you will
see what I mean.

The problem is (and miod@ acknowledged this) that
once Theo has an opinion that is partially based
upon reasons, he stops listening to even more
reasonable arguments.

In this case, DJB is as stubborn (is that the
correct English word? dunno) as TdR (and RMS,
FWIW) so they're likely to conflict at some place.

A few topics

[StevenLacroix]

Here are my recommendations: 1. Since OpenBSD excels at security, why not a section how to install Snort w/Acid. 2. Thorough PF/ALTQ documentation and examples, since PF is OpenBSD specific with specific examples using OpenBSD for bridging, load balancing. 3. A walk-through for maintaining an up to date system with CVS, and how to apply patches. (more details than the FAQ). 4. VPN - step by step with a troubleshooting section. 5. Third party security tools - Stephanie for OpenBSD for example. Anything that can be used to harden, log or supplement to the existing security. 6. How to compile and install from source software that was made for other platforms (FreeBSD, Linux) 7. The usual - quicknotes on replacing sendmail with Postfix, Bind with Maradns or djbdns, how to deal with Apache chrooted, PPPoE... 8. Optimization tricks.

In Soviet Russia....

[Phosphor3k]

OpenBSD books reccomend YOU!

Re:a book?

[Shanep]

continuously dwindling, community of *BSD users

You believe what you read here, don't you. You are misinformed.

Linux has only recently reached the point where books devoted to it were justified

The first Linux book I bought (in a major "general public" book store chain), was back in the Red Hat 4.2 days.

OpenBSD is the opposite of all of these, and their financial woes are pronounced enough that this could be the mistake that finally puts them under.

What makes you think OpenBSD is funding this book?

You don't have to be an economist to see that the market just isn't there. This is why *BSD continues to falter, even as Linux's popularity explodes.

I happen to know, for a 100% fact, that OpenBSD is used by many banks and other financial entities for firewalling tasks. I know from first hand experience. Just because you don't see it, doesn't mean it is not widely deployed.

OpenBSD does and should exist in network perimeters and any book that helps people learn how to use it can only be better for OpenBSD and network users alike.

I do own many BSD books, BTW, including an OpenBSD book.

I'd think a book would be more likely to succeed

Somehow, I don't think the author is setting out to make the most successful book. He is setting out to make a successful OpenBSD book.

My $.02...

[Deker]

Things I would like to see covered in some depth:

- Complete coverage of IPSec VPNs w/ OpenBSD (as well as some client-side examples, perhaps FreeS/WAN, OpenBSD dislup clients, etc)
- Good coverage of PF/ALTQ with lots of examples
- Good security coverage explaining that just because it's OpenBSD doesn't mean it's invulnerable. Take the time to explain some good
practices for securely CONFIGURING services, etc. I'd also like to see some coverage of Stephanie and the newly-added ProPolice.
- More performance tuning information. I've found precious little of this that's OpenBSD specific.
- Good intro to BSD-style kernel configuration and compilation for newbies/linux users.
- Introduction to the OpenBSD ports collection for newbies/linux users. Also, some coverage of packages so that people know they don't have to
compile EVERYTHING.
- An OpenBSD guide to configuring XFree86 and installing some of the "more familliar" desktop environments (KDE, GNOME, etc).

-d

Be sure not to forget

[TerryAtWork]

The 'Don't Piss Off Theo' chapter....