The Linux Problem Solver 21
| The Linux Problem Solver | |
| author | Brian Ward (author of the Kernel-HOWTO) |
| pages | 239 |
| publisher | No Starch Press |
| rating | 6.5 |
| reviewer | PotPieMan |
| ISBN | 1-886411-35-2 |
| summary | This book aims to help systems administrators deal with both initial setup andconfiguration snafus and ongoing maintenance problems by combining standard tutorial explanations with over 100 problem-oriented troubleshooting sections. |
The Scoop The Linux Problem Solver isn't a bad idea. While there are HOWTOs, IRC, and other ways of getting help, having a book that covers many of the mundane, day-to-day problems is potentially helpful. In this book, there are standard tutorial-type explanations which illustrate some of the most important command-line options and configuration file directives. The author lists relevant man pages in certain tutorial sections. In addition, there are numerous troubleshooting sections interspersed throughout the tutorials. In these sections, the reader is given a symptom (like "Large files don't print"), a problem (such as "The default maximum size is too small"), and the final solution. In some cases, the given problems and solutions could probably prove quite helpful, especially when used in conjunction with the numerous available HOWTOs. The book also includes a CD, which supposedly includes a bunch of helpful utilities, in addition to serving as a bootable rescue CD. Unfortunately, my proof copy of the book did not include the CD. To give an overview of the book's layout, here is a brief list of topics covered in each chapter to expand on the table of contents below:
- Chapter 1: general introduction, Linux system basics (init, syslogd, devices, and the like)
Chapter 2: setting up network interfaces, inetd, firewalls, network security and diagnostics
Chapter 3: NFS clients and servers, NIS, Rdist and SSH with Rdist
Chapter 4: SAMBA, Netatalk, Squid
Chapter 5: printing with LPRng, including network and non-PostScript printing
Chapter 6: installation from tarballs, explanation of the Encap organization scheme
Chapter 7: kernel configuration, compilation, and installation; module setup
Chapter 8: backups with tape drives, automated backups, crash recovery
Chapter 9: shell startup files, X startup files, xdm, and X resources
What's Bad?
I found that much of the writing in - The Linux Problem Solverwas difficult to read--the text didn't flow like a troubleshooting
book should. The author, it seems, attempted to construct his discussion in a terse manner to keep the chapters focused on
individual topics. While many may like this approach, I found myself rereading parts because there wasn't enough explanation.
Another related problem I found was that some of the examples in the tutorials were not introduced, and when they were, there were inconsistencies between the explanations and the actual command-line or configuration file examples. This is a relatively minor problem--although one that should have been caught in the editing phases. (And it may have been; I received an "uncorrected proof.") There were also, in some instances, grammatical errors which were probably fixed during the editing process.
I was also disappointed by the organization between the general tutorial discussion and the problems. The troubleshooting sections didn't always follow the topic of the text, coming at rather random times for some of the topics. Unfortunately, because of the overly terse writing style, it made more sense to me to separate the general tutorial and the troubleshooting sections, which was done in some places. With a bit more transitional text, I think that the troubleshooting sections could have flowed much better with the setup and configuration tutorials.
I found some small problems with text formatting, which may have been corrected in a more final version of the book. While quite minor, there were mistakes in heading and subheading styles which detracted from the organization of individual chapters.
What's Good?
The layout of the chapters was generally pretty good. The topics within each chapter made sense together. Most Linux administration topics were covered, with some being covered too briefly for my tastes. X, a topic that I thought would be relatively important to systems administrators, received less than 10 pages (compared to an entire chapter on installing software from source tarballs), with hardly any mention of networking X. (One could argue, however, that X networking is becoming less important as workstations become less expensive.)Out of all the chapters, the printing chapter seemed most comprehensive. There were a few inconsistencies between the text and the provided examples which were annoying, but not to the point where I became confused. I liked the discussion of network printing (through LPRng, AppleTalk, and SAMBA) and of printing to non-PostScript printers, topics that are probably pertinent for many administrators of Linux workstations.
I like the problem-oriented presentation of the setup and maintenance issues, despite the organization problems. As a systems administrator, having a reference like this might be nice during those times when you just can't figure out what's wrong. Some of the book was very well written and helpful, like the Netatalk section. This section was well-organized, with examples introduced and explained cleanly. The troubleshooting tips flowed nicely with the tutorial text. If more of the book flowed as well as the Netatalk section, it would have received a much better score.
So What's In It For Me?
If you want a reference that combines standard tutorials with troubleshooting, The Linux Problem Solver is a book to consider. I would recommend it to those who are newer to Linux or systems administrators who are new to maintaining more than they can handle. For experienced administrators, this book probably wouldn't expose any big secrets. Nevertheless, the book offers numerous suggestions on how to make life easier, like the Encap package management system to help with upgrades and removal of packages.Before purchasing the book online, however, I would go to a bookstore and flip through it. You may like the writing style, and you may find the troubleshooting very helpful. But because of the sometimes hard-to-follow writing, I don't see myself using the book on a daily basis. Rather, I'll be sticking with the HOWTOs and man pages.
Table of Contents
- About This Book
- Network Installation
- NFS, NIS, and Rdist
- MS-Windows and AppleTalk Networks, Web Proxy Server
- Printing
- Installing Software from Source Code
- Kernel Upgrades
- Backups and Crash Recovery
- User Environments
Purchase this book from ThinkGeek..
Problem Solver? (Score:1)
hehe
Ben
Re:Things heard when problem-solving Linux: (Score:1)
"Did linuxconf just change that BACK?" - Ever have Windows change your custom resources setting back on your SoundBlaster? Its like windows didn't think I was smart enough to look at the jumpers. and enter the correct settings myself.
Solution: don't use linuxconf. It's eeee-vil
"What the hell does this crap in sendmail.cf *mean*?" - If local mail is too complicated, just employ the Windows solution (don't install it).
Solution: Get Nullmailer [freshmeat.net]. Or if you really need a full blown MTA, qmail [qmail.org]. Sendmail is a relic.
"Oh, there it is. What the %#*@! does this %#$# *mean*?" - Fatal Execption at OE 8231:xxxxx in NDIS.vxd, 'nuff said. Even MS tech support will give youa big "ummmmm.....yeah....".
Solution: Regexps are a bitch in an OS. :-p
I'm not really sure what the point of this post was. I've been doing software testing since Monday and that'll continue through the end of the week, so perhaps that's it.
Re:Process (Score:1)
Ah, yes - Windows 200. Released around the time the Roman Emipre was adopting Catholicisim. Funny how Microsoft hasn't been able to improve the stability since then, isn't it?
Re:Lowest review? (Score:2)
Anybody remember if Jon Katz's book was reviewed here on
Re:Things heard when problem-solving Linux: (Score:2)
Very nice.. Perl compatible regular expressions, SQL, and human-readable config files. It also lends itself to chrooting, has never had a known security problem, outperforms sendmail, etc.
Try it.. you'll be happy you did
--
Book Usefulness (Score:3)
I have to say that there are web pages out there more useful than any book on Linux.
However, it looks like this one solves one critical problem -- you must have a working computer before you access information on the Internet. That's one I haven't worked around yet.
With a name like Linux Problem Solver, though, I expected it to be about C or something.
C -- the god of programming languages.
THE LINUX PROBLEM SOLVER, ABRIDGED (Score:2)
Re:Things heard when problem-solving Linux: (Score:1)
the windows does not work ?????
"Thank God I am not using Windows".
"Thank God I still have a brain".
OverLord
Woohooo! (Score:1)
Re:Great. Another book for sysadmins. (Score:1)
some work instead of goofing off surfing pr0n or playing games or reading users' email. We need a book tha...
My personal favorites would be "The Art of War" and some various good texts on covert survailing people without their knowledge. Also personally being able to note the actions of such individuals and getting them prosecuted in civil and criminal courts works well as well.
Great. Another book for sysadmins. (Score:3)
Simon? Is that you? No! It's not me typing up that comment. Wait! No Aaaaa^
@
%^
3n8Q/
#
Connection closed by foreign host.
Like Chilton's for Linux (Score:1)
To continue the overused car/computer analogy: Suppose you had a car which was simply underpowered. Maybe it has a small engine and a heavy, non-aerodynamic frame. In the end, no amount of tweaking or customization will give that car any more power. It will still struggle to get up hills when the air conditioner is on. It will still be unable to do more than scratch the shins of a m4d 1337 kernel mastah should it run into one.
Many people will try to tell it's more powerful than you'll ever need, but these are the same people putting Tux dolls on the dashboard and "1m 1337" personalized plates on the bumpers. They'll tint the windows and paint it a garish eye-hurting color. In the end, they still get passed by the kid on a mountain bike.
Sure, you can tune for performance. You can turn off the air conditioner. You can tell a certain pompous blowhard writer to take a walk. You can even untie and release the underage passenger in the backseat.
But, when it's all said and done, you'll eventually end up driving the whole thing into the lake.
Perhaps in our current post-slashdot era, it's for the best. Cheers.
Things heard when problem-solving Linux: (Score:5)
"Did linuxconf just change that BACK?"
"Thank God I am not using Windows".
"What the hell does this crap in sendmail.cf *mean*?"
"Thank God I am not using Windows".
"Now, find is right here in my path; where the %#%^# is its man page?"
"Thank God I am not using Windows".
"Oh, there it is. What the %#*@! does this %#$# *mean*?"
"Thank God I am not using Windows".
"It has to be something right here in /etc..."
"Thank God I am not using Windows".
"Why isn't there a Control Panel, like in Windows? Where is the help when I hit F1? Why do I need a book to use a desktop OS? the humanity!"
.
.
.
Yggdrasil's Linux Bible (Score:1)
Now that it's easy to get your home Linux box connected to the internet, having paper versions of all of the docs might seem silly, but 5 or 6 years ago, when I was sitting at home with my 486 25sx, it was a god send.
re: C -- the god of programming languages. (Score:1)
Yes! C is in fact the God of programming languages. And like God, C is old and dead.
Lowest review? (Score:3)
Usually books get 7+ when reviewed. (I guess that's probably because nobody enjoys reading about books that suck). But this book got 6.5 - was there anything that got lower?
Not that 6.5 is bad...just an observation.
That's kind of funny really (Score:1)
Re:Things heard when problem-solving Linux: (Score:1)
"Did linuxconf just change that BACK?" - Ever have Windows change your custom resources setting back on your SoundBlaster? Its like windows didn't think I was smart enough to look at the jumpers. and enter the correct settings myself.
"What the hell does this crap in sendmail.cf *mean*?" - If local mail is too complicated, just employ the Windows solution (don't install it).
"Oh, there it is. What the %#*@! does this %#$# *mean*?" - Fatal Execption at OE 8231:xxxxx in NDIS.vxd, 'nuff said. Even MS tech support will give youa big "ummmmm.....yeah....".
"It has to be something right here in /etc..." - Try running regedit and then tell me which system is more cryptic.
Now for my speech. Linux is tough to get a handle of at first, especially with /etc, because there is soooo much functionality. There are a billion config files, well, because its does a billion things. If you find that you don't need all the functionality of that "install everything option" (believe me you don't) don't install option you don't need or get a stripped down distro like Corel (Control Panel and F1) which was my starter distro, after being battered into confusion for months with RH 5.2. I now use Mandrake, because of the choice of features it allows me to install and its wonderful config utilites. HardDrake (hardware detection and config) program rules.
Re:BSD will never win over linux (Score:1)
Different Market (Score:1)
Although, reviewing a pre-press copy of a book does seem like an interesting idea. Put it out in the community, and find out what they think is good, bad and ugly, then publish it for the average admin. There are people who read this site who have incredible knowledge in most tech fields, and I'm sure they could give pointers on how to cover an idea.
Re:Things heard when problem-solving Linux: (Score:1)
me to install and its wonderful config utilites. HardDrake (hardware detection and config) program rules.
That's what I've been running for quite a while, and, quite frankly, I'm about to switch to something custom or just switch to Slackware. Why? Well, I'm tired of saying, "Why did linuxconf switch that back AGAIN?"