Linux System Administration

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.

Pitfalls....

[iknownuttin]

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...

I bet you never forgot the problem again. That's the thing, by researching these problems, you come across similar problems and pitfalls and you learn more looking it up.

The second thing is, many times, these pitfalls disappear after a release or so, so having them documented in a book that's updated after several releases can be a waste. On the other hand, when you have a boss/customer breathing down your neck, learning be damned, you got to get this sucker up and running!

Re:

[Billosaur]

Then again, you might fall into the trap of having to administer an older version of a system where the flaw is still extant. Never hurts to have that knowledge at your fingertips (I personally have been keeping O'Reilly in business for the past few years) and I think that even if a pitfall gets programmed out, there may be resonances of it in the current release or perhaps in a different distro altogether.

sendmail vs postfix

[rossz]

Postfix is more stable and far more secure.

Excuse me? Based on what? I would have been able to accept the argument that "postfix is easier to configure than sendmail", but questioning the security of sendmail is complete bullshit. In the last 10 years sendmail has had how many critical security flaws?

Re:

[Anonymous Coward]

Based upon past history.

Re:

[empaler]

Based upon past history.

How is this flamebait? How come if this had been said about Microsoft products, it would have been considered insightful?

Based upon past history.

Re:

[shaitand]

Bad moderation at its finest. Believe it or not, people with opinions you don't like or even unpopular opinions are not trolls or flamebait. Sendmail has a terrible security record.

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

Re:

[wizardforce]

Results 1 - 10 of about 137,000 for sendmail critical security flaws. (0.11 seconds) http://www.google.com/search?hl=en&q=sendmail+crit ical+security+flaws&btnG=Search [google.com]

Re:

[brunascle]

Results 1 - 10 of about 1,030,000 for google is unreliable. (0.06 seconds) http://www.google.com/search?q=google+is+unreliabl e [google.com]

Re:

[wizardforce]

yes I know, most of those results are of various other permutations but the point is the same, sendmail has had security flaws just like anything else, it is just a matter of the magnitude.

Re:

[gkhan1]

So google was right! It is unreliable!

But wait... if google is unreliable... how can it... hmm...

I wonder what the Gödel number for "Google is unreliable" is?

Re:sendmail vs postfix

[digitalunity]

Inability to set up Sendmail properly is in and of itself a security risk. You may quib that any admin who cannot set up Sendmail properly shouldn't be an admin, but this elitist attitude is counterintuitive.

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.

Re:

[N3WBI3]

Inability to set up Sendmail properly is in and of itself a security risk

The same can be said about qmail

Re:

[kyliaar]

I run sendmail for my organizations inbound mail service. I spent a good amount of time tweaking it, enabled amavisd with spamassassin, writing custom access rules and milters to protect our outdated Exchange network, etc. I constantly used the O'Reilly sendmail book to figure out how to do things as sendmail configuration is anything but simple, intuitive or user-friendly. In my years with working with it, I have not found any sort of inherent security flaw that wasn't quickly fixed with a security patc

Re:

[myowntrueself]

Inability to set up Sendmail properly is in and of itself a security risk

The same can be said about qmail

Except in the case of qmail its more like:

'inability to apply the appropriate third party patches in the right order and failing to regression-test them against one another'.

Qmail by default, as DJB intended it, is terribly, terribly wrong...

Re:

[MikeBabcock]

I'd love to see your actual reasoning for the statement, "Qmail by default, as DJB intended it, is terribly, terribly wrong." Without patching, Qmail is an excellent MTA. With patching, Qmail has more features (or works better on different platforms). Qmail may not be the end-all and be-all of MTAs, but it has never let me down in 8 years of running it on multiple servers.

Please actually give evidence or links to real legitimate arguments instead of posting flame bait.

Re:

[myowntrueself]

"All mail should be either bounced or delivered"

Re:

[MikeBabcock]

That's it? That's your whole rant on why qmail is flawed? Don't you agree? Try using arguments, not stating facts to stand on their own -- as I've said elsewhere, "not everyone's brain is wired the same, explain your thoughts or forget others understanding them."

Re:

[myowntrueself]

Its qmail. I don't need a cogent argument. Dan doesn't. He doesn't even need cogent source-code. Or cogent licensing terms.

To have a functional mail server in todays environment (as opposed to the 1980's) you need to apply multiple third-party patches to it. These patches are not regression-tested against one another so you can't rely on them.

Operating system distributors cannot ship properly patched and tested qmail packages because that would violate the licensing terms.

Oh and Dans policy on email, as app

Re:

[MikeBabcock]

I'm not sure what your problem is, but E-mail *should* be bounced or delivered once its accepted. If you don't want to bounce messages, don't accept them. The whole spam era has screwed up what E-mail is supposed to be about -- Dan believes reliable E-mail is more important than an empty Inbox. I happen to agree.

If you think I spend more than an hour a year administering qmail, you'd be wrong. Once configured, it just works. That's what I like about it. Enjoy Exim though.

Re:

[Skapare]

I can set up Sendmail properly and securely. I've done so before, and I could again, if I wanted to burden myself with such a monumental task. By comparison, Postfix can be set up properly and securely more quickly, and with less pain.

Given the dilution of system administration jobs, in large part due to businesses wanting to pay admins less, there will be a lot of people in such jobs that fall into the "gap" between "cannot configure sendmail properly and securely" and "can configure postfix properly an

Re:

[shaitand]

'Inability to set up Sendmail properly is in and of itself a security risk. You may quib that any admin who cannot set up Sendmail properly shouldn't be an admin, but this elitist attitude is counterintuitive.'

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

Re:

[shaitand]

Far too many large providers and organizations run sendmail. They do it because their old hat admins spent years mastering sendmail, not because it scales or performs better. Postfix is easier to configure, every bit as flexible (rare combination), generally outperforms sendmail and scales just as well.

Re:sendmail vs postfix

[Anonymous Coward]

http://www.securityfocus.com/bid/17192 [securityfocus.com]
http://www.securityfocus.com/bid/8641 [securityfocus.com]
http://www.securityfocus.com/bid/8649 [securityfocus.com]
http://www.securityfocus.com/bid/6991 [securityfocus.com]
http://www.securityfocus.com/bid/6548 [securityfocus.com]
etc...

I couldn't find any "critical security flaws" for postfix. I did, however, find this: http://cr.yp.to/maildisasters/postfix.html [cr.yp.to]

Re:

[rattis]

The argument they used in the book, page 22, is "...Sendmail has many of the security problems listed on the Common Vulnerabilities and Exposures (CVE) list hosted at http://cve.mitre.org./ [cve.mitre.org]"

I did a quick search on the site. Sendmail has 69 listed, while Postfix has 10. I'm not saying the book is right, I'm just saying how they made the argument.

Re:

[div_2n]

Not a lot, but there was one very critical last year that had remote root capabilities:

http://lwn.net/Articles/176596/ [lwn.net]

Re:

[csoto]

I agree with you that the argument that "postfix is ... far more secure" than sendmail is flawed. But this isn't because sendmail is so secure. Rather, it's because the secuirty (or lack of) sendmail has no reflection on the security (or lack of) of postfix. Both can be equally "insecure." And I guarantee you there are (or will be) flaws in both applications...

Re:

[shaitand]

'And I guarantee you there are (or will be) flaws in both applications...'

Without questions and the number of reported flaws is a useless metric for a number of reasons. You are right sendmail and postfix can be equally secure and/or insecure depending upon configuration. That said security in otherwise secure programs is inversely proportional to configuration complexity. Both programs have a learning curve but the configuration of sendmail is far more complex than that of Postfix (even for a knowledgeable

Re:

[Bob Uhl]

This guy [slashdot.org] posted a list of recent Sendmail vulnerabilities. Moreover, Sendmail does too much and is too hairy for the vast majority of mail servers out there (I'll pull a number out of thin air and say 99.999% of mail servers just need to talk SMTP and local delivery and can safely ignore UUCP, Bitnet and the rest, and probably 90% don't need to scalability of Sendmail), and its monolithic nature means that a vulnerability in one part can easily lead to a root exploit.

Postfix, OTOH, was designed to reduce

What about monitoring ?

[Anonymous Coward]

Most of the literature covering system administration never mentions server/network monitoring as a part of the whole "system administration" package.

Is it that monitoring is viewed as something unnecessary or is monitoring something that is just starting to take off ?

Re:

[Meorah]

Viewed as too expensive/unnecessary by executives, adds no features, most smaller businesses can resolve their issues without installing monitoring software by overworking their admins instead.

Re:

[Anonymous Coward]

The authors cover monitoring in Chapter 4. They show the reader how to configure a pretty good Daemon Monitoring Daemon.

Re:

[empaler]

(..)the Stallman State Penitentiary For Freedom.

LOL :-D :-D

HA/Clustering

[Trigun]

I am glad that these issues are being addressed by O'Reilley now. The last Linux Administration book that I purchased from O'Reilley was nothing more than DNS/DHCP and NFS.

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:

[4pins]

"I would still like to see more about LDAP, authentication and authorization, single sign-on, etc."

I've scoured the web for a GOOD reference for this and have been disappointed (however I haven't looked lately). If anyone know of a particularly good site for this please let us all know. Oh, and please realize that LDAP [openldap.org] isn't really the problem. The problem is trying to archive "single sign-on" with LDAP.

Re:

[Trigun]

If you get any response on this, please let me know.

Re:

[jerkyjunkmail]

Well it's not a whole FOSS stack per se but I used Open Directory(which does use OpenLDAP albeit with a simple gui around it) from Mac OS X Server to acheive this. You might be able find something helpful infomation to "clear the haze" around that topic even if you aren't using Mac OS X Server http://www.jerkys.org/wiki/x/YgAf [jerkys.org] http://www.jerkys.org/wiki/x/CQAQ [jerkys.org] http://www.jerkys.org/wiki/x/OwAf [jerkys.org]

What are the reasons for Sendmail?

[Bromskloss]

I don't know why I would need it, so I probably don't, but it would be interesting to know.

Re:

[e9th]

The last time I needed Sendmail I was using a MicroVAX II as a DECnet/uucp gateway.

Re:What are the reasons for Sendmail?

[brunascle]

for sending mail. that's my guess, anyway.

Re:

[EatHam]

I heard the next release will be called some really esoteric Swahili word. It will be pronounced "The boss is a cock", and everyone will wonder why users will be slow to adopt it.

Re:

[cloudmaster]

Mainly because you spent years learning how to configure it through M4 and you're so stuck in your ways that moving to a modular, faster, more flexible and secure MTA is unthinkable. At least, that's how most people who still run Sendmail strike me...

Re:

[shaitand]

'Mainly because you spent years learning how to configure it through M4 and you're so stuck in your ways that moving to a modular, faster, more flexible and secure MTA is unthinkable.'

I don't think it's just that. I think of the old unix admins have the ability to readily grasp and learn the new stuff. I suspect it has more to do with job security. It goes like this, if sendmail isn't in place you sell it by explaining that it is tried, true , and stable unlike these flaky new systems and maybe you claim no

Re:

[cloudmaster]

I just said "unthinkable" - I didn't say whether it'd be unthinkable due to learning impairment or due to other more subversive political reasons... :)

Re:

[smash]

I haven't dealt with sendmail or postfix for some years, but back in 2002, sendmail's support for multiple domains, virtual user tables, etc seemed to be a little easier to configure (using .mc files and running make to generate the .cf files under BSD). Also, the virus scanner i was using back then didn't want to play with spamassassin when run under postfix for some reason (memory hazy) - sendmail was better supported by the scanner i was using.

I also haven't seen much in postfix with regards to using

Re:

[Bob Uhl]

Sendmail is a lot more than just an SMTP/local mail server; it can act as a fairly complex mail gateway and can deal with a lot of older, funkier email protocols (UUCP, mail11, HylaFax and QuickPage according to Wikipedia; I could have sworn that it also handled Bitnet or Fidonet or something like that). It can also handle more email throughput than Postfix (or, I believe, qmail, exim and others). If you need to handle a large volume of email and cannot buy extra boxes to run Postfix, then you might need t

Mail configuration it are hard

[Anonymous Coward]

I remember when I set up my first LAMP stack. I thought I was the shit. I had my own fucking webserver, for fuck's sake! Who could possibly fuck with me now? I installed mediawiki and phpbb, and I was root and admin, and all was good.

Lately I have been playing with mail servers, and it is a whole different ball game. Imagine a series of croquet rings dotted around a field. Now imagine standing at the side of that field and sliding a rope across the grass, threading it perfectly through each ring, without m

Re:

[Penguinshit]

Try leaving your human baby alone, locked in a 55-degree room, with only the hum of a thousand small fans as a lullaby....

Re:linux is unmanageable

[JoeCommodore]

Even worse, your server never have downtime...at least human babies take nap here and there.

I can see the Microsoft tow picture ad now, top picture harried sysadmin with the linux box, screen showing * WORK * WORK * WORK * in ugly green pixelated courier on black. In the next picture, the same (now) MS based admin is leaning back on his chair with a big smile with his feet propped up, on the screen - white on pretty blue - is "Server down, please reboot" in nice friendly Arial TTF letters.

And the quote, "Even sysadmins deserve a break from sever management, Microsoft will give it you."

Re:

[rustalot42684]

Maybe something a little like this? [imageshack.us]

Re:

[smash]

Oh really it's not that bad. Given the choice i'll admin freebsd instead because it does feel more consistently "right", but adminned soley linux systems for 6 years or so before my current employment dealing wiht mostly A.D. and a couple of linux systems.

I also have to deal with AIX now too.

If you can't get your head around minor differences in linux distributions, then you shouldn't be a sysadmin. Besides, the changes between windows nt 3.x, 4.x, 2000 and vista are much bigger than the changes that

SysAdmins

[OddlyMoving]

We are born, not made.

Linux Administration Handbook

[stjobe]

How does it hold up to Linux Administration Handbook [amazon.com] by Evi Nemeth et al?

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:

[Bob Uhl]

Very different. The Linux/Unix Administration Handbooks are excellent works--you really can't be a sysadmin without one of 'em on your bookshelf. This book is good, but oriented more towards particular problems, while the L/UAH are full of vital day-to-day stuff.