Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Book Reviews Books Media

Linux System Administration 74

Posted by samzenpus from the read-all-about-it dept.
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.
This discussion has been archived. No new comments can be posted.

Linux System Administration More

Linux System Administration

Comments Filter:

  • Pitfalls.... (Score:4, Insightful)

    by iknownuttin ( 1099999 ) on Monday June 11, 2007 @01:51PM (#19468383)
    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!

    • 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 (Score:3, Insightful)

    by rossz ( 67331 ) <ogreNO@SPAMgeekbiker.net> on Monday June 11, 2007 @01:51PM (#19468385) Journal

    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: (Score:2, Insightful)

      by Anonymous Coward
      Based upon past history.

      • Re: (Score:1, Interesting)

        by shaitand ( 626655 )
        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
    • 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:sendmail vs postfix (Score:5, Interesting)

      by digitalunity ( 19107 ) <digitalunityNO@SPAMyahoo.com> on Monday June 11, 2007 @02:04PM (#19468529) Homepage
      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: (Score:2)

        by N3WBI3 ( 595976 )
        Inability to set up Sendmail properly is in and of itself a security risk

        The same can be said about qmail

        • Re: (Score:2, Insightful)

          by kyliaar ( 192847 )
          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
        • 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...
          • 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.
            • "All mail should be either bounced or delivered"

              • 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."
                • 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
                  • 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: (Score:2)

        by Skapare ( 16644 )

        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: (Score:2, Interesting)

        by shaitand ( 626655 )
        '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:sendmail vs postfix (Score:4, Informative)

      by Anonymous Coward on Monday June 11, 2007 @02:21PM (#19468691)
      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: (Score:3, Informative)

      by rattis ( 125942 )
      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: (Score:2)

      by div_2n ( 525075 )
      Not a lot, but there was one very critical last year that had remote root capabilities:

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

    • Re: (Score:2)

      by csoto ( 220540 )
      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...
      • '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: (Score:2)

      by Bob Uhl ( 30977 )
      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 ? (Score:3, Interesting)

    by Anonymous Coward on Monday June 11, 2007 @01:55PM (#19468441)
    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: (Score:2, Insightful)

      by Meorah ( 308102 )
      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: (Score:1, Informative)

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

  • HA/Clustering (Score:5, Interesting)

    by Trigun ( 685027 ) <evil&evilempire,ath,cx> on Monday June 11, 2007 @01:58PM (#19468471)
    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: (Score:1)

      by 4pins ( 858270 )
      "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.

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

    • Re: (Score:3, Insightful)

      by e9th ( 652576 )
      The last time I needed Sendmail I was using a MicroVAX II as a DECnet/uucp gateway.

    • Re:What are the reasons for Sendmail? (Score:5, Insightful)

      by brunascle ( 994197 ) on Monday June 11, 2007 @02:21PM (#19468695)
      for sending mail. that's my guess, anyway.

    • Re: (Score:2)

      by EatHam ( 597465 )
      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.
    • 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...
      • '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
        • 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: (Score:2)

      by smash ( 1351 )
      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: (Score:2)

      by Bob Uhl ( 30977 )
      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 (Score:2, Funny)

    by 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

  • SysAdmins (Score:1, Redundant)

    by OddlyMoving ( 1103849 )
    We are born, not made.

  • Linux Administration Handbook (Score:5, Interesting)

    by stjobe ( 78285 ) on Monday June 11, 2007 @03:04PM (#19469359) Homepage
    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: (Score:2)

      by Bob Uhl ( 30977 )
      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.

Slashdot Top Deals

The truth of a proposition has nothing to do with its credibility. And vice versa.

Close