Slashdot Mirror
Linux Networking Cookbook
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.
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.
My blog
Its a cookbook!!!!!!!
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
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.
"... 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.
"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?
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.
throw new NoSignatureException();
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.
Is it just me, or /. frontpage just got abused by "no,really"'s ad?
Hate ads :(
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.
The state you are in while your HEAD is detached... - wait, what?
Neither did the the moderately competent Linux networking book reviewer.
...you insensitive clod.
Weaselmancer
rediculous.
"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."
/etc/ssl/misc/CA.sh
or, perhaps,
$ locate CA.sh
Or hell, just "locate CA.sh" is likely to work on a lot of systems.
/var/sadm/install/contents" burned into my brain.
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
Does it tell you how to Shell Korn to get the Kernel?
I couldn't resist. I'm punny.
My QuickBASIC years left "locate 1,2: print a$" burned into my brain; I can't take UNIX's locate seriously. Wish I could..
The state you are in while your HEAD is detached... - wait, what?
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.
find is more likely to work than rpm on deb-based systems.
Yes, but that's not what the parent wrote.
Yes, but I have a feeling that it's what the parent meant
Surely, if you're globbing by using '*', you should refer to "all of the *buntu", rather than "all of the *buntus" ?
Notwithstanding that, I think that the ordinary English plural of "Ubuntu" is "Ubuntu" anyway, because it is a noun of indefinite quantity.
I just got the cookbook and "Linux Firewalls" by Michael Rash. Different solutions and problems, but they complement each other.