Forgot your password?
typodupeerror
Book Reviews Books Media

Linux Networking Cookbook 64

Posted by samzenpus
from the read-all-about-it dept.
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 CA.sh 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 CA.sh on all of them.

My OpenSuSE machine did throw one small curve:

CA.sh on my openSUSE box was located in /usr/lib/ssl/misc, as on the other boxes. However, the book tells us that CA.sh, 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 CA.sh 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 amazon.com. 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 @01:44PM (#23465352) Homepage Journal

    CA.sh on my openSUSE box was located in /usr/lib/ssl/misc, as on the other boxes. However, the book tells us that CA.sh, 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 CA.sh 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.

    • Re: (Score:1, Insightful)

      by Anonymous Coward
      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 call
      • Re: (Score:2, Informative)

        f 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?!).


        Uh, they do.

        Look, if it makes you feel any better, Mr. Anonymous Cobol Programmer, you can type 'rpmquery --list openssl'

      • by strabes (1075839)
        I don't think there is one sentence in your entire post that is truthful.
      • Re: (Score:3, Insightful)

        by putaro (235078)
        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
    • " 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'"

      If you are moderately competent, and much more on the lines of the book itself (since it seems it tries to be distribution-agnostic) you wouldn't query the RPM database when `find / -type f -name CA.sh -print`, while certainly slowerly, will find the file 100 times out of 100, no matter what
      • `find / -type f -name CA.sh -print`

        OK, we'll get off your lawn :P

      • find / -type f -name CA.sh -print

        Old fart who still uses -print, even though in every modern implementation it's implied now. :P

        Yeah, it works, but on Linux using the package manager is always much quicker and, after all, that's what its there for. Your method is, however, portable to *BSD and other *nixes.

        Being so, why just don't use openssl for everything and avoid the CA.sh script dependency?

        Convenience. Remembering all of the steps and switches to create a certificate can be difficult for someone (l

        • "Old fart who still uses -print, even though in every modern implementation it's implied now. :P"

          Yes. Firstly I wrote it without the "-print", but then, when I was previewing, I saw I said it would work on any unix-like system so I went for the safe side (I really don't know for sure if, say, HP-Ux or AIX will default to print or still do it the old way).

          "Yeah, it works, but on Linux using the package manager is always much quicker"

          Well, I explicitly said "find" would work surely but slowerly, so I fart a
  • by Archangel Michael (180766) on Monday May 19, 2008 @01:44PM (#23465358) Journal
    Its a cookbook!!!!!!!
  • But, this book *IS* the FM... so, you're just accomplishing the goal of the advice from the IRC line, without giving them the pleasure of being the one to tell you...

    This whole article wreaks of preemptive RTFM snobbery.

    • by _Sprocket_ (42527)
      BTFB - buy the f'n book?
    • Re: (Score:3, Informative)

      by Talderas (1212466)
      I have this book, and the summary barely reminded me of the topics contained in it. It starts out with topics that discuss using a Linux server to handle many of the functions that you would frequently have a piece of hardware. Gateway routers, wireless routers, firewall.

      Then it goes into using a Linux server for some other services, remote administration, VPNs, Samba and LDAP, Network Monitoring.

      Finally it ends with with a chaptor on IPv6, Serial Console management, Linux Dial-Up servers and a chapter on t
      • by Sancho (17056) *
        Does the book touch on the limitations of commodity PC hardware as a router, firewall, etc? Most specifically, the inability to provide line-rate filtering at small packet sizes?
  • by JavaBasedOS (1217930) on Monday May 19, 2008 @01: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.
    • by KGBear (71109)
      Yes, with the "advantage" that you don't really learn anything in the process...
  • by Lengyel (1082385) on Monday May 19, 2008 @01:52PM (#23465468)
    "However, the book tells us that CA.sh, and a moderately competent Linux user is likely to know that rpm -ql openssl will list all of the files in the openssl package..." What else is CA.sh likely to know?
    • by pablomme (1270790)
      Apparently what both CA.sh and the moderately competent Linux user don't know is that "find / -name CA.sh" is more likely to work on deb-based systems, and less likely to force one to read the rpm manpage to remember what options do what.
      • by Lengyel (1082385)
        Neither did the the moderately competent Linux networking book reviewer.
      • by mrbooze (49713)
        Or hell, just "locate CA.sh" is likely to work on a lot of systems.

        Find or locate have the advantage that they'll work even if the package you're looking for wasn't installed via the package manager. (Assuming you are savvy enough with find to prevent it from scavenging off down unnecessary NFS mounts, massive spool directories, and the like.)

        Of course my Solaris years left "grep FOO /var/sadm/install/contents" burned into my brain.
        • by pablomme (1270790)
          My QuickBASIC years left "locate 1,2: print a$" burned into my brain; I can't take UNIX's locate seriously. Wish I could..
      • Wait a minute: "..."find / -name CA.sh" is more likely to work on deb-based systems, and less likely to force one to read the rpm manpage to remember what options do what." Find isn't less likely to work on non-deb-based Linux systems, as far as I know. On the other hand, at least on my distros, I agree that "find / -name CA.sh [-print]" has never "forced" anyone to read the rpm manpage, nor has find ever forced itself upon anyone. Perhaps the license agreement covers this case.
  • smbmount (Score:1, Offtopic)

    by Toreo asesino (951231)
    Does anyone know if you can mount a Win2k3 partition yet with smbmount without turning off client signing on network?

    I last tried this a few years back, but failed because you had to turn off signing for the DCs...kinda stops Linux being able to connect to valuable resources.

    Linux as a data-store in a Windows network is pretty awesome though with samba + lvm once configured well.
    • Re:smbmount (Score:5, Funny)

      by Anonymous Coward on Monday May 19, 2008 @01:59PM (#23465554)

      Does anyone know if you can mount a Win2k3 partition yet with smbmount without turning off client signing on network?

      I last tried this a few years back, but failed because you had to turn off signing for the DCs...kinda stops Linux being able to connect to valuable resources.

      Linux as a data-store in a Windows network is pretty awesome though with samba + lvm once configured well.
      RTFM
    • Re:smbmount (Score:4, Informative)

      by BobMcD (601576) on Monday May 19, 2008 @02:39PM (#23466122)
      Mount by ip, rather than by name. E.g. \\192.168.1.102\share, instead of \\server\share...
      • Good point and oddly enough, that's about the only way you can get MS Vista, XP, and W2K to share resources on a home network.

        The only problem is that you have to boot up your computers so that they grab the correct IP addresses via DHCP. Or you use static IP addresses to get around that.

        Scheeze, I just want to connect a couple computers. It shouldn't be this difficult.

    • by Rutulian (171771)
      I believe you are looking for the option,

      client use spnego = yes

      in your smb.conf file. That at least works for linux clients on our Win2k3 domain.
  • by Bryansix (761547) on Monday May 19, 2008 @02:06PM (#23465652) Homepage
    Is this month "some uppity online geek awareness month"? I've been running into a lot of these lately like they want to make their presence in this world apparent to me somehow.
    • by neowolf (173735)
      Unfortunately- there are a lot of "uppity online geeks" out there right now. They seem to delight in telling people to RTFM, flagging bug reports as dupes, and sending people on wild goose chases through the Internet. All requiring more effort than simply answering the damn question or throwing out a command line entry.

      It's really sad- because it is one of the things that is really holding Linux back. I've been using Linux as a server platform for over a decade, and have been using Desktop Linux for about t
      • by debatem1 (1087307)
        They don't answer because they don't know.
      • by Sancho (17056) * on Monday May 19, 2008 @03:21PM (#23466740) Homepage

        Unfortunately- there are a lot of "uppity online geeks" out there right now. They seem to delight in telling people to RTFM, flagging bug reports as dupes, and sending people on wild goose chases through the Internet. All requiring more effort than simply answering the damn question or throwing out a command line entry.
        Unfortunately, there are a lot of people out there who can't seem to search bug tracking software for duplicate bugs, can't seem to search Google for answers to their commonly asked questions, and refuse to read the manual for the software they're trying to use. While "uppity online geeks" certainly answer questions when appropriate, if the answer is in a FAQ or easily found elsewhere, repeatedly answering the same questions gets tiresome.

        I think that the only thing more frustrating than people asking repeatedly-answered questions is people who ask for help on an uncommon issue, then post a little later with, "Nevermind, I fixed it." Maybe if they included how they fixed it, they would save someone else from having to ask the same damned question.
        • if the answer is in a FAQ or easily found elsewhere, repeatedly answering the same questions gets tiresome.
          Favorite topical quote from over a decade ago:

          "I am not your AI interface to the internet."
  • by Weaselmancer (533834) on Monday May 19, 2008 @02:34PM (#23466054)

    ...you insensitive clod.

  • "CA.sh on my openSUSE box was located in /usr/lib/ssl/misc, as on the other boxes. However, the book tells us that CA.sh, 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 CA.sh will spit out the location of the script."
    or, perhaps,
    $ locate CA.sh
    /etc/ssl/misc/CA.sh
  • I just got the cookbook and "Linux Firewalls" by Michael Rash. Different solutions and problems, but they complement each other.

Pound for pound, the amoeba is the most vicious animal on earth.

Working...