Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Books Software Media Programming Book Reviews Linux IT Technology

Linux Server Hacks 146

Wee writes "Linux Server Hacks is not a book which will teach you system administration. In fact, if you aren't already familiar with how to set up and run Linux, this book will likely confuse you. It is also not a book which will teach you how to break into Linux servers. The word 'hack' in this case is not a pejorative. What LSH will do is show you how to fully tweak that Linux box you already run. It will show you new (and possibly better) ways to do the things you already do. The book will probably not make you a better admin, but it will almost certainly save you some time or give you at least one 'Why didn't I ever think of that?' head-scratcher." Read on for the rest of Wee's review.
Linux Server Hacks
author Rob Flickenger
pages 221 (including index)
publisher O'Reilly
rating Very Good
reviewer Wee
ISBN 0596004613
summary 100 tips and tools useful for those who work with Linux servers (and workstations).

About the book

LSH is not just about the Linux operating system, per se. Despite the title, it spends more time covering applications which can run on Linux than it does the Linux operating system itself. It is composed of 100 "hacks" all grouped together into like areas, such as "Monitoring" and "Networking". The style sort of reminded me of O'Reilly's Cookbook series, and I find it to be an easy format to read. Indeed, if the book was larger, it could have easily been called "The Linux Server Cookbook."

After a somewhat cheesy forward by ESR and a recognizably standard O'Reilly preface, LSH starts out the hacking with a section called "Server Basics," and it's here that most of the Linux-specific tips are. You get to learn how to pass args to LILO, stroll through /proc, tweak the Linux kernel, play with hdparm and so forth. This chapter left me thinking that this was all stuff every admin should know, and not much of it was new to me (if you've used Linux for more than a couple years you probably won't find much here that you haven't at least heard about before). If you are new to Linux however, then this chapter will be valuable even if you stop reading the book right at chapter two.

If the book had to be divided into two parts, the first chapter would be titled "Part 1: Linux the OS." The balance of the book would then be called "Part 2: Linux Applications." Subsequent chapters each tackle one area of services or applications that run on Linux, such as CVS or rsync or ssh, and it's very easy to find something interesting purely by looking through the table of contents. The book's grouping of hacks into like topics helps, I think, because you can easily pick out what you want to see more of without having to wade through that which you don't find terribly interesting. For example, if you only deal with your personal Linux workstation, then you can easily disregard the "Information Servers" chapter without missing other valuable content. I personally found the "Networking" and "Monitoring" chapters to be the most useful. The "Backups" chapter was interesting, the "Scripting" chapter not so much. Each chapter starts with a summary of what's to come, so if the table of contents isn't enough to find the good bits, then just reading those summaries can give you an idea of whether you'll find anything useful to you.

The book includes a fairly complete index, but I didn't use it very much. I found the table of contents, with its list of each hack's title, to be useful enough. I suspect that when I pick the book up a couple months from now looking for something I had read about I'll get more use out of the index.

What's to like

As I mentioned above, the book is very easy to read. Flickenger has a "conversational" writing style I found easy to parse. If you hang out with Linux geeks very much, you'll recognize his way of communicating and easily assimilate what he has to say. His advice is sound, his skill level high (the same can be said for the other contributors as well). The book's layout and organization made it easy to find specifics and will ensure that it gets used as a reference later on.

You might be wondering about the code samples in this book: there are a lot of them. I didn't check, but I think each hack had at least one CLI listing or bit of example code. This made the book much more valuable than if it simply told you want to do; "seeing" the hack in action helped tremendously. In fact, I'd have felt disappointed if Flickenger hadn't included as many examples as he did. Most of the code is Perl, with some shell mixed in. The example code is well written and properly placed, so if you don't know Perl or shell you'll still be able to make use of the hack.

Each hack can stand on its own. This makes the book easy to read, and ensures its place as a reference. I didn't read the book sequentially at first, but I went through the whole thing regardless. Some hacks refer to other hacks, and I found myself reading the book as if it was hypertext, as is mentioned in the preface. Again, this also means less time spent reading that which you already know (or find boring) and more time spent thinking about something more useful.

The book is distribution-agnostic. I couldn't find anything that would upset a Debian user or would flummox a Mandrake fan. While this might have more to do with the bulk of the hacks being on the application level, I found the lack of an axe to grind refreshing nonetheless.

The book doesn't assume l33t-ness nor coddle the reader. It assumes you know your stuff and are a professional, and in doing so finds its voice rather well. This gave me a sense of admiration for the author and allowed me to absorb the knowledge being imparted with ease.

Although not specifically about the book, O'Reilly has set up a website devoted to their "Hacks" series of books. Users can send in their own hacks, which helps flesh out the content in the print edition.

What could be better

ESR's forward, titled "How to Become a Hacker," was just silly. The forward added nothing to the book, and I find the whole "zen of hacking" schtick tiresome after only a short while. Yes, "hack" is a cool word, but one which easily suffers from overuse: it suffers a lot in ESR's forward. The forward also contains a plug for ESR's book, which I thought was somewhat tacky.

LILO is referred to in several places, but there is not a single mention of GRUB. Where the boot loader was being discussed, an "If you use GRUB, you'd want to do it this way..." aside would have been welcome.

The "Information Servers" chapter is very large, but only deals with BIND 9, Apache and MySQL. If you don't work with any of these three, then fully one quarter of the book will be useless to you. I would have really liked to see mail servers (especially Postfix and Qmail) mentioned, and including tweaks for an ftp daemon would have made the book that much more valuable. I would have also liked to see sshd covered; the book contains only ssh client hacks. Finally, a hack or three about PostgreSQL would have been nice.

The "Scripting" chapter could have been replaced with a "Security" chapter. There are only 4 scripting hacks, and they aren't all that useful. Although the book has a security-conscious mindset running throughout it, I felt the lack of a section devoted specifically to security was a glaring omission. In fact, I almost didn't buy the book when I noticed that the table of contents didn't list a security chapter. It was only after reading a hack or two that I could see security was going to be mentioned.

Another area I expected to see was one with hacks involving package management. A whole chapter dealing with this topic would have certainly been welcome to users of Red Hat, SuSE, et al. I suspect that such a chapter might have broken an unwritten editorial rule about remaining distribution neutral, however. And Debian users would have found anything beyond an apt-get one-liner superfluous, so I can forgive the "omission."

Although the title of the book is "Linux Server Hacks," someone using Linux as a workstation would also find the book helpful. For example, Flickenger includes two hacks on burning CDs, a hack on displaying the load average in the title bar of an xterm window, and so on. I got the impression that the server-centric focus wandered into desktop land quite a bit. Because of this, I thought that some hacks involving window managers should have been included. I've tweaked vnc to run blackbox on more than one occasion and expected to see things like that mentioned. This is a niggling complaint, however.

I found myself wishing the book was longer. At US$24.95 the price was right, but I would have rather paid US$34.95 for 150 total hacks.

Finally, the book looked somewhat rushed. There were more than a couple formatting errors (typeset characters visible, etc) sprinkled throughout, and all the code examples were unindented; it was as if all the tabs were stripped out by the printer. While the lack of indenting might confuse those who don't know Perl or shell, the only "real" consequence of this is that the lack of tabs in the makefile examples on pages 27 and 28 prevent them from working.

Summary

Based on this review, it might seem that the bad outweighs the good where Linux Server hacks is concerned. I don't think this is the case, and I would caution anyone against taking that view (rather, I'd have them glance through the book at the bookstore before deciding not to buy it). I think it should be noted that given the usually high quality of O'Reilly titles, it's far easier to spot what could be better than what is likeable. Like the old saying goes, nobody notices a clean kitchen unless it isn't.

None of the "bad" things would keep me from recommending this book, and I found Linux Server Hacks to be a very useful -- both as a future reference and as "thumb through while waiting for the train" sort of read. There's not much in it which is "new", and most of the hacks would border on common sense for the seasoned sysadmin (although I'd be willing to be that even the most grizzled admin would find something new or interesting). Indeed, nearly all the information in the book can probably be found on the web somewhere. It is nice, however, to have everything collected in one place and organized into specific groups. Linux Server Hacks would make a good addition to the bookshelf of anyone, regardless of their skill level, who finds themself administering a Linux machine, be it a server or workstation.

Table of contents

  1. How to Become a Hacker
  2. Preface
  1. Server Basics
  2. Revision Control
  3. Backups
  4. Networking
  5. Monitoring
  6. SSH
  7. Scripting
  8. Information Servers


You can purchase Linux Server Hacks from bn.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 Server Hacks

Comments Filter:
  • by Anonymous Coward on Wednesday March 19, 2003 @12:01PM (#5544395)
    It is also not a book which will teach you how to break into Linux servers.

    Then what good is it!?
  • by stonebeat.org ( 562495 ) on Wednesday March 19, 2003 @12:04PM (#5544418) Homepage
    why cant all this information be on a searchable website? and charge me subscription...
    • by Graelin ( 309958 ) on Wednesday March 19, 2003 @12:11PM (#5544476)
      It already is. [oreilly.com]

      Our company tried the safari thing for a while. It's very sweet, many many books online covering a wide variety of topics.

      You pay for the books you use, and you can add / remove books at your leisure. Some books are worth more than others. It really makes a lot of sense.

      Not sure what the costs are for individual use. Considering their "group" rates, I'd say their individual rates are probably very fair.

      Personally, I don't like online books too much. I'd rather be able to kick back and drink a beer and read. Can't do that with a 19" CRT. :)

      Perhaps when web-pads are more mainstream (and thinner and lighter)...
    • I can't get my networking configured...hmm. I know, I'll check the website!
    • why cant all this information be on a searchable website? and charge me subscription...

      Amen, especially 221 page stuff like this, with half the content redundent for experienced admins. I would rather visit the site, print out 20 to 30 pages of the really good stuff, put that in my magical book of tricks (old 3 ring binders, dozens based on different daemons) and use it that way.

      I subscribe to other sites (including pay) and strongly prefer that method to get my info. I will still buy books, but stuff
    • All of this information is searchable in google. By buying the book you are paying for the convenience of having everything consolidated right there in front of you, in a searchable (index) format. You could also go with a Safari subscription from O'reilly to acheive the same effect with a webpage.
      • All of this information is searchable in google. By buying the book you are paying for the convenience of having everything consolidated right there in front of you, in a searchable (index) format. You could also go with a Safari subscription from O'reilly to acheive the same effect with a webpage.

        Actually I can think of at least on other reason to buy a book: inspiration. Sometimes it's take a moment to truly appreciate how a new tool (or an unthought of use for a tool) can be integrated into your p

  • by Anonymous Coward
    Does this book have any methods for filtering pr0n from user mail accounts, and indexing/organizing it correctly for the administer to 'review' and archive? I know this admin would surely welcome suggestions that would help me better utilize my time in this most important area.
    • Grab all e-mail by size. Anything over 65k is a good bet. Parse the mime-types and break apart by that.

      Spend a couple of days looking at it, and you'll be able to sort your files into categories based on the receiver's flavour of kink. At one time I could find interracial furry midget porn out of a userbase of 8,000.

      And yes, the black dudes were as big as their arm. Pity they were midgets.
    • I don't know if the computers can sort out the good pr0n you want to see, but I imagine they could with the right filters sort them by breast size, hair color, and number of people involved. Even this small bit might really help you utilize your time in "this most important area" much more effectively.

  • by Anonymous Coward
    The book will probably not make you a better admin, but it will almost certainly save you some time

    More time for recreation makes me a better admin. More time for automation and documentation makes me a better admin. And, of course, more time for Slashdot makes me a better admin.
  • by totallygeek ( 263191 ) <sellis@totallygeek.com> on Wednesday March 19, 2003 @12:09PM (#5544455) Homepage
    This is an older book, but definately a great read for anyone that doesn't want to "re-invent the wheel" to fix everyday problems...

    UNIX Papers
    for UNIX Developers and Power Users
    ISBN 0-672-22578-6

    Like I said, it is old, but sed, awk and C haven't changed over the years. This has some great information on shell scripting, NFS, and email.

  • by Gaetano ( 142855 ) on Wednesday March 19, 2003 @12:09PM (#5544460)
    I had a few extra book places so I checked this book out last week. I was suprised how useful much of it was. I have been working with linux for years and there where plenty of things I had never done before, but would have had I known of them before. I may even get a copy for everyone at the office.
  • Good book. (Score:2, Informative)

    by Horny Smurf ( 590916 )
    I agree that the ESR forward should have been deleted. However, this book is a nifty collection of various hacks that probably would take you forever to stumble upon if they weren't in this book. (You're probably too busy administering or programming to experiment all day long).

    Using RCS/CVS to track revisions to settings files is just an example. I've seen far too many /etc/* files that have lines commented out, no explanation why. Having a revision history clean the clutter, makes a backup, and lets y
    • was actually written a long time ago, and has nothing in particular to do with the book. Apparently since he had taken over the jargon.txt file he was getting a lot of "How do I become a hacker?" email. Yeah, it's a little cheesy, but that's esr, I guess. I think the only reason it's there is because O'reilly's trying to "liberate" the hacker moniker from being associated with cracking.

      I remember coming across the hacker-howto [catb.org] years ago, when I was a windows-only newbie, and it actually inspired me to

  • First book I've read that treats you like an experienced System Administrator. Not for the faint of heart or inexperienced. I really enjoyed it!
  • by QwkHyenA ( 207573 ) on Wednesday March 19, 2003 @12:12PM (#5544483) Homepage
    To some of you Uber network admins out there this book won't be very helpful. But to me, someone whose been net-admin'ing it for 2 years this was very helpful! Shows you lots of nice tricks. I found the section on utilizing ssh to its full potential extremely useful! I never thought of doing backups over ssh before! I'd rate this book 5 out of 5 stars personally!
  • Hack dedicated to /. (Score:5, Informative)

    by locknloll ( 638243 ) on Wednesday March 19, 2003 @12:13PM (#5544492) Homepage
    Hack #79 [oreilly.com] in the book is about Distributed Server Load. The first paragraph has some nice reference to Slashdot:
    If you serve a particularly popular site, you will eventually find the wall at which your server simply can't serve any more requests. In the web server world, this is called the Slashdot effect, and it isn't a pretty site (er, sight).
    :-D
  • Its called the Linux Documentation Project.

    www.tldp.net

  • There's was a book review of this same book about a week or two ago, wasn't there? I bought the book and have been pleased overall with it, but there wasn't really anything new or exciting, just a few tips and tricks. Note you can find most of these by going to www.google.com/linux and looking up tips and tricks. One example would be that you can find out who is hogging the most disk space using an alias for du, like this:

    du -cks | sort -rn | head -n 10

    Pretty simple, yet really effective. This book is
    • Re:Dupe! (Score:4, Funny)

      by Duke ( 23059 ) on Wednesday March 19, 2003 @12:37PM (#5544652)
      Yup. There is nothing like Linux for getting all your ducks in a row.
    • That command is incorrect, I'm assuming you forgot to poste in extrans, so your <USERNAME HERE> got chopped off.

      the correct way to run that would be du -cks /home/* |sort -rn | head -n 10

      But that isnt verry accurate, smart users will hide files in /tmp, their mail spool, or wherever else.
      A proper admin would check the filesystem quotas, or in a pinch:

      for user in `cat /etc/passwd |cut -d: -f1`;do echo -n $user:; expr `find / -user $user -printf "%k + " 2>/dev/null` 0;done |grep -v :0$

      Then again,
  • Forward? (Score:1, Redundant)

    by Canthros ( 5769 )
    ESR wrote a foreword. Forward is a direction, foreward is piece of writing at the front of a book.
  • by Espen ( 96293 ) on Wednesday March 19, 2003 @12:18PM (#5544526)
    For Pete's sake: It's "foreword" (ie. fore-word). Defined as "A word said before something else; hence, an introduction, a preface." (OED).

    Why the heck would it be called 'forward'? Do people who make this mistake think it is the suggested reading direction?
    • I noticed that too. I reckon this one's a losing battle - there's too much similarity between the two words, in meaning as well as sound. The first meaning listed for "forward" at m-w.com is "1 a : near, being at, or belonging to the forepart b : situated in advance" - pretty applicable, wouldn't you say? Think of the forward hold of a ship, or the U.S. Forward Command Center in Qatar.

      In addition, a creative person challenged on this issue might notice that "foreword" dates to 1842, whereas "forward" d

      • There are two significant differences which would make me hate to see this battle lost:

        1) 'Forward' is primarily an adjective or adverb and rarely used as a noun. The definition cited above is for the adverb/adjective whereas here it is clearly used as a noun. 'Foreword' is unambigiously a noun.
        2) Forword describes the purpose of the section, not the placement! The same is true of other parts of books: Table of Contents, Chapter, Index etc. There is nothing wrong with consistency!
    • Why the heck would it be called 'forward'?

      Because the dumbass writer proofreads the review after he's submitted it?

      Do people who make this mistake think it is the suggested reading direction?

      No?

      -B

    • If you can save this one child [somethingawful.com] from the evils of illiteracy, you have earned a place in history.

      Try not to spontaneously combust while doing so :)
    • Do people who make this mistake think it is the suggested reading direction?

      Who said a person made this mistake? How do you know it was not the auto-correct feature of M$ Word? Be glad the M$ meat heads don't give books foreskins instead.

      Foreskin - a protective collection of words at the start of a book. Some people think of them as superflous, others call them Introductions.

      How's that for forward of me?

      Ever heard of a book so up front?

      The direction depends on it's state.

      OK, I'm going to stop mow,

  • by Gavin Rogers ( 301715 ) <grogers@vk6hgr.echidna.id.au> on Wednesday March 19, 2003 @12:19PM (#5544531) Homepage
    As I mentioned above, the book is very easy to read. Flickenger has a "conversational" writing style I found easy to parse. If you hang out with Linux geeks very much, you'll recognize his way of communicating and easily assimilate what he has to say.

    You know that if you start using words such as 'parse' in every day language, you probably do hangout with geeks very much!

    (and they probably find words such as parse easy to communicate with, too) :-)
  • by ACK!! ( 10229 ) on Wednesday March 19, 2003 @12:25PM (#5544573) Journal
    Like there aren't books for Windows folks for tricks you can pull to make your life easier on a Windows box? Aren't there are a bunch of classes available for MCSE types?

    Yeah, you might want the book if you had not already thought of some of these tricks. That is the point of reading and learning, duh!

    Give me a break. Every admin knows there are little things that can be automated and worked from a base install to help them get through the day and get their stuff done no matter what OS you admin.

    I propose this to the community. What is the neatest hack/trick that saves time from your day in terms of programming or system administration?

    BTW, any tricks I don't care if they are straight commercial Unix, Linux or Windows.

    • I propose this to the community. What is the neatest hack/trick that saves time from your day in terms of programming or system administration?

      I've found that much time is saved by combining Perl knowledge and the Vim text editor. Perl one-liners are great, too - esp with the "-i" switch. For example, you wanna replace all instances of "host1" with "host6" in a file named "file.txt" - perl -pi.bak -e's/host1/host6/g' file.txt - you end up with the original file in "file.txt.bak" and an edited "file.t

      • Couldn't you do this with normal shell commands, like cat and sed?

        cat file.txt | sed -- s/host1/host6/g > file.new ; mv file.txt file.txt.bak ; mv file.new file.txt
        • Yes. However, much time is saved by knowing how to do that with fewer keystrokes. Doing it in one command with perl also means the filename is types once, greatly reducing the chance that a filename will be mistyped. So, it also saves the time taken to fix errors in the first command. :)

          The thing about "there's more than one way to do it" is great - if there's no perl then there's probably at least sed on a system. The file could be piped through ed or any number of text editing programs, too...
    • A simple trick that I use...

      Crontabs do not have the ability to run commands say, every other week, or every other month. A simple way to do this is with the following shell script (I'll call it script.sh):

      --- begin script ---
      #!/bin/sh -xv

      FLAGFILE=/path/to/flag

      if [ -f $FLAGFILE ]; then
      rm -f $FLAGFILE
      exit 0
      else
      touch $FLAGFILE
      fi

      call command(s) to run here
      --- end script ---


      Then, in the crontab, enter something like the following:
      0 0 * * 1 /path/to/script.sh
      • by dissy ( 172727 ) on Wednesday March 19, 2003 @03:21PM (#5546209)
        > Crontabs do not have the ability to run commands say, every other week,
        > or every other month

        Sure it does. Atleast the one that comes with linux (GNU?)

        The time fields are: min hour day month day-of-week
        * means any/all of course.

        You can do

        * * * 1/2 * /path/to/every-other-month.sh
        Runs on the ODD months, make it 2/2 to run on the even months.

        0/10 * * * * /path/to/every-10-minutes.sh
        Runs every 10 mins where the last digit is 0 (00 10 20... 50)

        Or in the case of backups or something, run it every two hours between 9pm and 5am (9pm, 11pm, 1am, 3am, 5am - non business hours) and also run it once durring lunch (noon)
        0 21-5/2,12 * * * /path/to/backup.sh

        Ok so thats not how you would want to run backups I'd imagine, but you get the idea of the timing commands atleast :)

        In the last field you can put a day (IE mon) and say /2 for every other day, or tue/2 for every other day in the other set.
        I'm not really sure if mon/2 would do every other monday, or every other day starting the count on monday (which is what i think)
        If that is the case, I would hope mon/14 would work (On monday, every 14 days/2 weeks) but I have never tried that.
        If your backup script does any logging, perhaps you can create a simple script that logs when it runs to a file, and add it in crontab as
        (assuming midnight) 0 0 * * mon/14 /path/to/testscript.sh

        no doubt just a #!/bin/sh and date >> /root/testscript.output

        To do every other week using the day of week may not be possible, so your code example is still valid. But that is only because the number of days in a month very and dont fall on any obvious boundrys.

        The only two examples ive ever used were twice a month (1st and 15th) [0 0 1/15 * *] and every other day-of-week that depends if the day is even or odd. This is close to what you want, but unfortunatly as each month changes, if there are an odd number of days in the month, the order changes. Only when there are an even number of days in the month does next month continue on the same pattern.
        [ 0 0 2/2 * mon] for example.

        Hope that helps abit

        • Very interesting, thank you. I was actually referring to a Solaris box; however, I wasn't aware that linux had that ability.
          • It's not a function of linux, per se, but rather a function of vixie cron, an updated version of cron written by Paul Vixie. I'm pretty sure that I've seen vixie cron running on a tweaked solaris box before, so check around for a standard package.

            Nicodemus
  • Another Review (Score:4, Informative)

    by Eater706 ( 659993 ) on Wednesday March 19, 2003 @12:29PM (#5544609) Homepage
    I wrote this last week, if you're looking for a bit more detail..

    Those who love UNIX (and UNIX-inspired operating systems) will surely adore Linux Server Hacks by Rob Flickenger. For decades, a mysterious sect of bearded wizards has dominated the inner sanctums of our network infrastructures, inspiring the awe of onlookers by crafting clever scripts and piping output in ingenious ways most of us never even thought of. This small but marvelous book attempts to steer apprentice wizards in the noble direction of clever system administration, with examples taken from experience in O'Reilly's own LAMP [onlamp.com] networks.

    The book begins with a refreshing introduction (by esr [catb.org]) detailing what it means to be a hacker. No, not the hax0ring w4r3z d00dz [honeynet.org] of frequent media attention, but the aforementioned bearded variety who spend most of their waking effort forging uncommon techniques for solving otherwise dull problems. Kudos to Mr. Flickenger (and O'Reilly) for not only acknowledging the difference, but celebrating it.

    As the title would indicate, the audience of this book is the administrator in charge of a server--that is, a Linux box performing only a couple of dedicated tasks, probably of a network-oriented nature. Although Linux enthusiasts from the desktop realm are not part of the intended audience, they will almost certainly pick up a thing or two from the material anyway.

    The book is organized into the following sections:

    • Sever Basics is a variety of general purpose tips that don't fit into the other major categories. Some of the more interesting items include:
      • Persistent daemons with init
      • Building complex command lines
      • Using xargs with tricky arguments
      • Effectively using sudo
      • Makefiles for automating administrative tasks

      I think the real magic of this chapter isn't necessarily the tips themselves, but the creative process behind them; the author is demonstrating a methodology for dealing with common problems by introducing clever solutions. This will ideally inspire the reader to deal with other problems in the same creative manner.

    • Revision Control. Servers with multiple administrators may benefit from using a revision control system to handle changes to configuration files. This section illustrates using RCS, with examples of checking config files in and out of the system. This provides a segway into using CVS for controlling revision of large software projects.
    • Backups becoming a nuisance? Approach them from a new angle by implementing some of the tips from this chapter. Examples including automated incremental backups over tar, rsync, and ssh; archiving with pax; and even some very creative (if not a little scary) ideas like piping your backups over ssh directly into cdrecord. The UNIX philosophy is illustrated well: simple tools working well together as an efficient solution.
    • The Networking chapter covers material that is no doubt already familiar to security-conscious Linux users. However, iptables newbies (or those transitioning from ipf or pf) will appreciate the netfilter primer and discussion of masquerading (NAT) and TCP port forwarding. Some tunneling and encapsulation techniques are also detailed here.
    • Monitoring details the use of syslog, and a great deal more. Networking aspects are given ample attention, without any redundant information in respect to the previous chapter. Some simple tips are given (like using lsof to track down elusive processes) as well as more advanced ideas (like a short shell script to perform an IP fail-over.)
    • SSH tips: are you still tapping out a password every time you hop to a new machine? If you administrate more than a few, this can be distracting and tedious. This chapter illustra
    • Oops, I clipped the last line. It should read:

      [1] No, I don't work for O'Reilly. I do think their books are excellent, however, and would love to see their Safari [slashdot.org] service thrive!

    • This provides a segway into using CVS for controlling revision of large software projects.

      ... the word you're looking for up there is segué. Although that would be kind of cool ... hey, I set my CVS repository up a couple weeks ago! Do I get a Segway now? ;_;

  • While we are on the topic of linux books, I was wandering if anyone would recommend a linux book for a beginner (but someone who recompiled the kernel and messed with X before even knowing the 'less' command :-) ) Your help is appreciated.
    • http://tldp.org/

      My recommendation to you is to not just try and learn, but focus on one aspect and figure out how to do it. I'd suggest you first check out Linux from scratch: http://tldp.org/LDP/lfs/html/ [tldp.org]

      I mean if you want a web server, download apache and play with it. Find the doc directory for your distribution and read! There is lots of information on web pages, just read a lot. Pick up a book on UNIX and learn about how files are structured, learn about links. Learn how to use ssh and when in doubt
    • If you are starting out that new, then I'd recommend getting a book oriented around your distribution. Make sure it covers some of the basics of X/window managers/gnome or KDE, if you're going to be using something like that. As an example, Redhat 7.3 Bible (or some similar name), contains lots of stuff I still find useful to refer to (even if "my copy" is really just on the shelf at the bookstore ;) after many years of tinkering. A solid book along this line might set you back around $40-$50 from a brick-a
    • by MobyTurbo ( 537363 ) on Wednesday March 19, 2003 @05:53PM (#5547485)
      O'Reilly's "Unix Power Tools" is undoubtedly one of the best books for learning how to do powerful things in Linux or any *nix. Unfortunately it's gone up in price in the third edition, but that means that the coveted first edition is easier to aquire via used book sources. :-) This book will teach you to be a scripting guru. If you are more of a beginner, I'd reccomend O'Reilly's "Running Linux" as being the best of this genre.

      For learning how to program on Linux there is "Begining Linux Programming" from Wrox. From O'Reilly and from other publishers, get books on scripting languages such as Perl, Python, or Tcl; a scripting language is a very valuable thing in the *nix environment. Don't forget shell scripting for that matter, Kernighan and Pike have the definitive work, "The Unix Programming Environment" on Bourne Shell scripting among other things and you may also want to get a book that covers Bash too. Also if you have deep pockets, anything by W. Richard Stevens is a good reference on Unix and TCP/IP network programming.

  • huh? (Score:3, Insightful)

    by JeanBaptiste ( 537955 ) on Wednesday March 19, 2003 @12:41PM (#5544677)
    The book will probably not make you a better admin, but it will almost certainly save you some time

    That sentance does not make any sense. If it saves you time, then wouldn't you be a better admin?
    • Re:huh? (Score:3, Funny)

      by Wee ( 17189 )
      That sentance does not make any sense. If it saves you time, then wouldn't you be a better admin?

      I don't do backups of any of my machines. The time I save makes me a better admin that someone who spends time working up a backup/restore plan.

      -B

      • you are correct.

        However, from reading the article blurb, I (possibly incorrectly) assumed it meant it would save you time in doing the things that you are already doing. I think you already know this, but good point anyways.
  • ...that make you go ooh thats clever. I've always found the difference to be between a good sysadmin and a great sysadmin is when they do something and you go wow now thats smart. Some one like this [geocities.com]

    Rus
  • The book doesn't assume l33t-ness nor coddle the reader.

    I hate to sound 'l33t' but I wish there were more books for people who has used linux for a long time. It's hard to aquire any new knowledge when most books are targeted at people with little experience.
    Of course there is a lot of good places on internet to get good tips and advice but that defeats the whole point of a book.
    • by doodleboy ( 263186 ) on Wednesday March 19, 2003 @04:07PM (#5546607)
      You and me both. I've used unix and linux for 10 years and I still compulsively buy *nix books, even though many tread the same tired ground. Two of the best for experienced users:

      Linux in a Nutshell (3rd ed.). Hands down, the best linux reference on the planet.

      Unix Power Tools (2nd ed.). The best unix (linux) book ever made. It's a bit heavy on tools that aren't overly popular on linux (csh, etc.) but many of the articles are superb examples of the unix problem solving paradigm. With all the hyperlinks in the margins, it's nearly impossible to read more than a couple of pages in a row.

      Speaking of compulsively buying O'Reilly books, I recently picked up Linux Server Hacks and Building Secure Servers with Linux, by Mick Bauer. Can't comment too much on the former, because I'm still reading the latter. Always liked Bauer though. Much common sense.
    • > I hate to sound 'l33t' but I wish there were more books for people who has used linux for a long time. It's hard to aquire any new knowledge when most books are targeted at people with little experience.

      But one good thing about being an advanced/power user is knowing how to get more knowledge. It's a positive feedback loop. Besides, advanced usually means specialized, and making lots of different books with small market for each one is not very good business-wise.

  • My personal favourite is the Linux Gazette [linuxgazette.com], but there are others (too lazy to reahch for bookmarks now ;). Don't overlook past issues even if they are pretty old, because some of the tricks discussed haven't changed much over the years (like motd, rdev, tcsh etc.), but of course some of it is to be viewed from a historical point of view =)
  • I found the only really interesting trick in the book was the one about ssh. (involves piping a tarred stream though ssh and treating it on the other end , like tar czf linux|ssh roberto "cd /usr/src; cat >linux.tar.gz). If you use shells most of the time you probably know most of the others, and alot of them are really just explanations of the commands, like the whole chapter on CVS.

    On the other hand, I added yesterday "Unix Power Tools", to my safari bookshelf and this one really absolutly rocks ! Not

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...