Please create an account to participate in the Slashdot moderation system


Forgot your password?
Book Reviews Books Media

Linux Networking Cookbook 64

dinotrac writes "Somebody special is coming over for dinner. You're not a chef, but you can cook well enough to get by, so you grab your best cookbook and get to work. That's the idea behind O'Reilly's Linux Networking Cookbook, by Carla Schroder. Carla has gathered a group of networking recipes that a reasonably Linux-savvy reader can use to address network needs like a seasoned sysadmin. If you want to find out how to hook your Linux workstation to a LAN, get another book. If you are reasonably comfortable with Linux, need to set up an LDAP server, configure single sign-on with Samba for a mixed Linux/Windows LAN, set up a VPN, or troubleshoot network problems without some uppity online geek telling you to RTFM, this book may be what you're looking for." Read below for the rest of Dean's review.
Linux Networking Cookbook
author Carla Schroder
pages 638
publisher O'Reilly
rating 9
reviewer Dean R. Pannell
ISBN 0596102488
summary The perfect tool when you need to be a network sysadmin but aren't
One of the great strengths and weaknesses of Linux is that everything you could possibly need to know is already on your computer in the form of man pages, or out on the internet in newsgroups, forums, or a massive autumn's leaf-pile of how-tos. Finding what you need in a form that you can use is sometimes a bigger problem than the problem you're trying to solve.

The Linux Networking Cookbook improves on that situation in a couple of ways. First is the author herself. Carla is an experienced System Administrator and a good technical writer. She was one of the early Linuxchix, and has spent years mentoring and otherwise helping new and experienced Linux folk through their assorted dilemmas. The result is a friendly and direct, information-packed and ego-free writing style. Unlike the typical how-to that provides a list of steps that have worked for the author, Carla's discussions fill in the blanks and tell you why she takes the steps that she does.

The Cookbook is organized into an introduction followed by 18 chapters that are complete stand-alone solutions to specific problems.

The obligatory introduction is short and is not required by any of the solutions in the book, but it's worth reading. Its' eleven pages read quickly, but contain, among other things, a good explanation of the difference between bandwidth and latency and a decent overview of the whys and whens of linux-based computers as routers versus mid-range and high-end commercial routers.

Each chapter begins with an introduction of the overall topic, Routing with Linux, for example, followed by a series of short recipes organized as problem-solution-discussion. This format is convenient for diving right into work and takes advantage Carla's mentoring talents.

One problem facing any writer of Linux books is the sheer number of Linux distributions, many of which have their own distinct ways of doing things. The Linux Networking Cookbook provides solutions for both Debian and Fedora Linux. It's an excellent choice when you consider that most Linuxes derive from one of those two bases, including all of the *buntus, Knoppix, Mandriva, PCLinuxOS, CentOS, and many more. The recipes employ generic tools, which makes them easier to transport across distributions, even the SuSEs, which are based on neither Debian nor Red Hat.

For example, before obtaining The Cookbook, I needed to create a self-signed SSL certificate for a PostgreSQL server on an Ubuntu server. I'd done it a few times, but not enough to remember, so I went off to the net. The Ubuntu-themed How-To I found relied on a script called apache2-ssl-certificate. An apache script didn't bother me because I could move the pieces when I was done, or just break open the script and make it do what I wanted done. Ubuntu Feisty, however, had managed to leave the script out of the distribution, so I had to go back to the net to find an alternative approach.

Had I used The Cookboock, my task would have been simpler, though not quite as easy as it should be. Inexplicably for a book that includes network security and SSL-based VPNs, there is no entry for SSL Certificate in the index. A browse through the table of contents turns up a couple of recipes for Creating SSL-Keys for a Syslog-ng Server: one for Debian and one for Fedora. Fortunately, the Table of Contents is short and can be browsed completely in seconds, because those recipes are in the Troubleshooting Networks chapter, which is not intuitively obvious. They appear in that chapter because it contains the recipes for network monitoring, which includes installation of Syslog-ng.

The recipe itself is suitably generic, using the script, which is part of openssl, and openssl itself to generate keys and certificates. A quick check of my Ubuntu servers, my Fedora VPS server, and my OpenSuSE workstation found on all of them.

My OpenSuSE machine did throw one small curve: on my openSUSE box was located in /usr/lib/ssl/misc, as on the other boxes. However, the book tells us that, and a moderately competent Linux user is likely to know that rpm -ql openssl will list all of the files in the openssl package or that rpm-ql openssl | grep will spit out the location of the script.

Given the variety of Linux distributions, it is hard to imagine a better approach to take.

The Glossary of Networking Terms in Appendix B deserves special mention. Each term is explained in plain but precise language that goes beyond the cursory definitions so common in glossaries. For example, the explanation for WEP notes that it is very weak protection and urges the reader to use WPA/WPA2 instead.

Sometimes, the extra information can soften a definition's focus, but, overall, the glossary is an outstanding tool for anyone who doesn't spend his or her time knee-deep in subnet definitions, routers, and tcp dumps. The same is true of the book.

As is usual for O'Reilly, updates, errata, and scripts from the book are available on the web.

You can purchase Linux Networking Cookbook from Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Linux Networking Cookbook

Comments Filter:
  • RPM knowledge (Score:3, Insightful)

    by morgan_greywolf ( 835522 ) * on Monday May 19, 2008 @02:44PM (#23465352) Homepage Journal on my openSUSE box was located in /usr/lib/ssl/misc, as on the other boxes. However, the book tells us that, and a moderately competent Linux user is likely to know that rpm -ql openssl will list all of the files in the openssl package or that rpm-ql openssl | grep will spit out the location of the script.
    Ignoring the fact that this has got to be one of the most awkwardly-written English sentences in the entire history of the language, *ahem*, I would say "Yes". If you use OpenSuSE (or any other RPM-based distro) and are moderately competent, then you should know how to query the RPM database to get such information. If you didn't, you don't qualify as 'moderately competent', and definitely don't fit the target audience for Linux Networking Cookbook.

  • by JavaBasedOS ( 1217930 ) on Monday May 19, 2008 @02:47PM (#23465404)
    "... without some uppity online geek telling you to RTFM..."

    In essence, you're doing just the 'uppity online geek' is telling you to do. TFM gives you the pieces and expects you to find out how to piece them together, while this just has the convenience of said commands and scripts already pieced together.
  • Re:RPM knowledge (Score:1, Insightful)

    by Anonymous Coward on Monday May 19, 2008 @03:09PM (#23465678)
    Of course its awkward, its Linux. That's still the problem with the adoption of linux (myself included) is the fact that they have shorthands/acronyms for EVERY command (why can't they have a long word list and a shorthand?!).

    How annoying is it that every simple task/installation requires you to have to read an online documentation step by step. Other open source projects suffer this same problem. It shouldn't use obscure words to make the programmer sound smart. If it compiles, make a preserved word called compile, not make, not gen, not create (or allow all 4 of these words, as long as you have the first one). This is 2008, disk space is cheap, coding in an extra word list isn't going to expand your program too much. We have no need to save that extra 6 bytes in our compiled code.

    Just what the heck is dash bash kash hash slash crash smash mean? If it doesn't sound like what it should be doing, don't use it.

    Anonymous obviously cause I don't want to get lynched by the /. crowd for being "OMG You don't use Linux?", I'm no MS/MAC fanboy, I just hate having to read an hour for each application I want to install, then another hour of which commands I have to do to make the program work.
  • Re:RPM knowledge (Score:3, Insightful)

    by putaro ( 235078 ) on Monday May 19, 2008 @11:06PM (#23470512) Journal
    I'm not sure about your comments about the target audience not fitting into the "moderately competent" range. I've been doing systems admin for over 20 years, starting with DEC RSTS/E and going through just about every flavor of Unix. Mostly I do software development, though, and if the boxes in my business are working I don't spend my days messing with them.

    Linux is a moving target for competence. Different distributions do things differently and they are all constantly changing. A lot of times I know how to do something - I just don't always know the *right* way to do something. I can build and install packages from the source, fix bugs in the scripts, etc. But then, the next update of the distribution comes along and screws me. So, I wind up spending more time than I would like to trying to figure out what the *right* way to do things is. Or, I know *what* I want to do, but how to do it under Linux is not immediately obvious.

    I will probably order a copy of the book because it will be helpful when I have to do a task that I only do once a year or so. I hope they will continue to update it, though, as it will be out of date quite soon.

I go on working for the same reason a hen goes on laying eggs. -- H.L. Mencken