Linux System Administration 74
Bob Uhl writes "I've just finished reading a review copy of O'Reilly's latest GNU/Linux title, Linux
System Administration. It's a handy introduction for the beginner
GNU/Linux sysadmin, and a useful addition to an experienced sysadmin's
bookshelf. The book is essentially a survey of various Linux system-administration
tasks: installing Debian; setting up LAMP; configuring a load-balancing,
high-availability environment; working with virtualization. None of the
chapters are in-depth examinations of their subjects; rather, they're
enough to get you started and familiar with the concepts involved, and
headed in the right direction." Read below for the rest of Bob's review.
| Linux System Administration | |
| author | Tom Adelstein & Bill Lubanovic |
| pages | 279 |
| publisher | O'Reilly |
| rating | 3 out of 4 stars |
| reviewer | Bob Uhl |
| ISBN | 0-596-00952-6 |
| summary | Good survey of various Linux software and technologies |
I like this approach, as it increases the likelihood that any particular admin will be able to use the material presented. I've been working with Apache for almost a decade now, but I've not done any virtualization; some other fellow may have played with Linux for supercomputing, but never done any web serving with it; we both can use the chapters which cover subjects new to us.
I really like some of the choices the authors made. A lot of GNU/Linux 'administration' books focus on GUI tools — I've seen some which don't even bother addressing the command line! I've long said that if one isn't intimately familiar with the shell — if one cannot get one's job done with it — then one isn't really a sysadmin. Linux System Administration approaches nearly everything from the CLI, right from the get-go.
The authors also deserve praise for showing, early on, how to replace Sendmail with Postfix. In 2007, there's very, very little reason to use Sendmail: unless you know why you need it, you almost certainly don't. Postfix is more stable and far more secure.
Another nice thing is how many alternatives are showcased: Xen & VMware; Debian, Fedora & Xandros; CIFS/SMB & NFS; shell, Perl, PHP & Python and so forth. One really great advantage of Unix in general and GNU/Linux in particular is choice — it's good to see a reference work which implicitly acknowledges that.
The authors are also pretty good about calling out common pitfalls — several got me, once upon a time. It'd have been nice to have had a book like this when I was cutting my teeth...
Lastly, I liked that the authors & their editor weren't afraid to refer readers to books from other publishers, in addition to O'Reilly's (uniformly excellent) offerings. Not all publishers would be so forthright; O'Reilly merits recognition for their openness.
The book's not quite perfect, though. I wish that PostgreSQL had at least been mentioned as a more powerful, more stable (and often faster in practice) alternative to MySQL, and one doesn't actually need to register a domain in order to set up static IP addressing. Still, these are pretty minor quibbles.
I'd say that the ideal audience for this book is a small-to-medium business admin who'd like to start using Linux, or who already is but doesn't really feel confident yet. It covers enough categories that at least a few are likely to be relevant. Even an experienced admin will probably find some useful stuff in here.
You can purchase Linux System Administration from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
What about monitoring ? (Score:3, Interesting)
Is it that monitoring is viewed as something unnecessary or is monitoring something that is just starting to take off ?
HA/Clustering (Score:5, Interesting)
I would still like to see more about LDAP, authentication and authorization, single sign-on, etc. Ususally O'Reilley practices become the de facto best practices, and after a few years in a quasi-management role, I am learning the difference between implementation and implementation based upon industry standards. The latter can be an ass-saver.
Re:sendmail vs postfix (Score:5, Interesting)
The variety of responsibility is different within any organization, from 10 employees to 10,000, there is a huge variability of skillsets required. Do you think a small home business grossing $10,000 monthly can afford to hire an admin who would take at least half of that? Like it or not, open source software is a huge boon to small businesses and we should strive to empower them with easy to use software, not bash them for not hiring better administrators.
Linux Administration Handbook (Score:5, Interesting)
This is a book that I've used for years and years (since before it forked into a Linux book and a Unix book) teaching Linux system administration classes, and I never found its match. Strongly recommended for novices and masters alike.
Re:sendmail vs postfix (Score:1, Interesting)
The tally of security flaws is a lousy metric. First you have to question severity and ease of exploit. Then you have to debate whether finding more flaws means more vigilant and effective bug fixing and therefore raises the bar to exploit the application (my inclination) or it means the program is less secure because it had less flaws (I don't buy this, every program has flaws).
The reality is that the count of flaws found and patched is not a useful metric of security. Beyond all the conditions that can completely change the meaning of those exploit counts is the fact the number of flaws reported and patched is NOT how many flaws the program had. The kid who hacked your server and stole 10,000 credit cards successfully did so with unreported exploit and probably covered his tracks so that you will never know.
The most useful metric I have found is actual in the wild exploitation. Every remotely compromised *nix system I have ever seen (I'm not counting social engineering or password guessing of course) was compromised via Sendmail or bind. Exploited or not I rarely see a securely configured sendmail due to the complexity of configuration and since that complexity doesn't bring added function over competitors like postfix it is fair to call it a critical flaw.
There are replacements for sendmail that scale as well, perform as well, have no greater number of security holes, and are equally flexible. I'm sorry old hat sendmail gurus who put time and effort into mastering sendmail fu but the only excuse you could have for using sendmail in modern times is a desire for job security. That said, there are still zillions of sendmail installations out there.
Unfortunately, I am unaware of a replacement for bind that is as stable, scalable and flexible. There are many that have great security track records and can lap bind on the racetrack time and again but security issues or no I don't anything else is ready to support the structure of the internet.
Re:sendmail vs postfix (Score:2, Interesting)
Agreed but it goes beyond that. An admin who never bothered to learn sendmail configuration isn't lesser than one who has. The quality of an admin isn't defined by the skills he can list on his resume but by his ability to choose his tools wisely and to abandon tools (and the investment spent learning them) when better tools come along. Sendmail hasn't been the best tool for the job anytime in the past 10 years so anyone with less than 10 years experience wouldn't really need it in their skill set.
We aren't talking about VI vs Notepad where the end of the learning curve results in mastery of vastly more powerful tool. There are a number of sendmail replacements that do the job as well. Postfix is an excellent example, it scales, it outperforms sendmail, has a superior security track record, and can be configured properly in a tenth of the time.
Basically postfix (and others) does everything sendmail does, does it as well or better, has a much gentler learning curve and has a much better security track record. I would argue that the admin who installs sendmail today should have the salary cut, not the other way around. We are admins, we invest time to learn and master tools our competency is defined not only by our ability to accomplish that but by our ability to toss aside those tools and the hours spent learning them to learn and master new ones.
'Like it or not, open source software is a huge boon to small businesses and we should strive to empower them with easy to use software, not bash them for not hiring better administrators.'
Agreed, this is a huge and largely ignored segment. Besides that, Postfix configuration may be a walk in the park compared sendmail configuration but there is definitely a learning curve. Postfix is not configured with 'are you sure' wizards that would allow someone who did not understand what they were doing to configure anything but the most trivial configuration. You still have to understand the protocol and how the servers communicate with one another, processes, storage concerns, logging and permissions.
Email and MTA's really aren't all that complex. The only reason to justify a dedicated mail admin would be large numbers of users with enough petty issues to monopolize an admin's time. There simply is no excuse for an admin only knowing mail server administration anymore.
P.S. Old guy who loves sendmail. No I am not a whipper snapper who lacks the experience to understand or who didn't get sendmail and so dismisses it. I get sendmail, I've worked with it many times in many different configurations. It works very well. But it is cumbersome, slow and the only justification left for using it is 'if it aint broke don't fix it'. Sendmail was once the most flexible and powerful MTA available and it scaled up to any task. Sendmail never lost those traits but other programs sprang up that could match that power, flexibility and eventually scalability. Sendmail still made sense for serious users who would rather have the tried and true over spring chickens. But now those alternatives have rock solid tenure of their own. Programs like Postfix have tenure in their own right.