Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Unix Operating Systems Software Books Media Book Reviews

Essential System Administration, 3rd Edition 179

dvdweyer writes "This book deals with administration of UNIX (one wonders why the book doesn't bear the title "Essential UNIX Administration"), all major UNIX platforms are covered, most of them in their almost latest version when the book went to press (Linux: Red Hat 7.3 and SuSE 8.0, Solaris 8 and 9, FreeBSD 4.6, AIX 5, HP-UX 11/11i, Tru64 5.1), SCO and IRIX were dropped for this edition, FreeBSD was added. Other UNIXes (e.g. Debian Linux) are not mentioned, but this makes the book only a little bit less useful on those, with some imagination the information can be used, except for special topics (e.g. package management). This book is on system administration and not targeted on desktop users, as such it doesn't cover KDE, Gnome or any desktop application." Dvddwyer's section-by-section review continues below.
Essential System Administration, 3rd Edition
author AEleen Frisch
pages 1176
publisher O'Reilly
rating 9/10
reviewer dvdweyer
ISBN 0596003439
summary a well-done standard for all who need a thorough introduction as well as a work of reference in UNIX system administration.

Content

Introduction to System Administration

This chapter claims to make you think like a system administrator, I didn't feel any different after reading it, maybe I already think like one ;-). Most of it is about use of superuser privileges (su, sudo). Other parts are communicating with users (talk, wall, motd - but no mention of e-mail or phone) and GUI-based vs. command-line administration.

The Unix Way

Here starts the real stuff: files, processes and devices. A very gentle but thorough introduction to all possibilities of file and directory ownership (chmod, chown, mode strings, numeric modes), next is a description of how files map to disks. The processes are covered on a fairly abstract level, only something about various types (interactive, batch, daemon) and attributes (but no way to show them, not even an example usage of ps or top - that's left for chapter 15). The part on devices is basic, but shows the some commands to list information about devices. Last part in this chapter is about the generic UNIX filesystem layout.

Essential Administrative Tools and Techniques

Here are some of the most important commands and techniques for everyday use: man, grep, awk, find (including how to pipe). Some of the examples are fairly complicated for a novice, a basic knowledge of piping and shell usage is assumed. Next are some methods of handling files and directories (cp, mkdir, diff, rm), periodic execution (cron), logging (syslog, managing log files) and software package management (the most important commands to Linux rpm, Solaris pkg*, etc.) and manual software installation (.configure, make, make install).

Startup and Shutdown

Contains a fairly detailed description of what happens when a system boots up or shuts down. This includes all the gooey stuff about initialization files, runlevels and how to customize those. Last but not least is a short troubleshooting guide, "When the System won't boot."

TCP/IP Networking

The chapter starts with a gentle introduction to TCP/IP and related hardware and explains step-by-step a starting TCP/IP session with dumps and comments. Going on it digs deeper and explains IP addressing, subnets and even a little bit IPv6. The first hands-on part deals with network configuration (ifconfig, configuration files, DHCP, name resolution). A short troubleshooting guide (ping, arp) rounds off the chapter.

Managing Users and Groups

This part starts with a description of the essential files (/etc/passwd, /etc/shadow, /etc/groups) and how to add/remove users and other aspects of user and group management. The default tools for each distribution are also mentioned. Then a whole slew of pages are dedicated to password selection, cracking and enforcing password policies (though I prefer stronger passwords than those given on page 301). The last pages give an introduction to PAM (mostly Linux) and LDAP (mostly OpenLDAP).

Security

This is indeed a very good introduction to UNIX security and its lines of defense (though I did miss "disable remote root login" and "give users no shell when they don't need it"), next are common mistakes, setuid/setgid access modes and ACLs. A short introduction to PGP/GPG and role-based access control is given. The next big part is about network security: OpenSSH, TCP Wrappers and nmap are introduced; the ubiquitous advice "disable what you don't need" is also given. Firewalls are briefly mentioned, some links to actual products e.g. ipfilter or Netfilter would have been nice. A nice checklist-style guide to hardening an UNIX system is given and the chapter concludes with managing problems and monitoring. I did miss some links to resources on the Internet and a reminder on the importance of frequent patching (Sun recently published a nice whitepaper on this topic).

Managing Network Services

This chapter builds on the foundation built in the chapter on TCP/IP, as such it covers various basic networking services and starts with name resolution via DNS, mentioning configuration and usage of the common tools (BIND, nslookup, host, dig). This is followed by a part on getting out of the local network (routed, gated), getting others on your network (DHCP) and managing (netstat, ping, traceroute, SNMP) and monitoring (tcpdump, snoop). The chapter ends with short introductions to dedicated packages (e.g. NetSaint, MRTG/RRDTool).

Electronic Mail

Next is a chapter on that other big network nuisance^W service: mail. It starts with a gentle introduction to the basics (SMTP, MX records, POP/IMAP). The part on MTAs starts with everybody's darling *cough* sendmail which is covered exhaustively. The other MTA covered is Postfix, which also receives fairly extensive coverage. The rest of the chapter covers mail processing (fetchmail, procmail), there is no mention of other MTA, MUAs, or other modern mail processing tools (e.g. against spam). Though this chapter is well done, and a nice introduction to mail in general, I would prefer to get rid of it in favor of a "mail-is-only-for-dedicated-servers" policy. A short note on how to deactivate or remove the default MTA should be included in the previous chapter (yes, I know that not everyone shares this point of view).

Filesystems and Disks

A very long chapter on filesystems and disks with tons of information on how to create, mount/unmount, repair and monitor filesystems, including some stuff about logical volume managers and RAID. Nicely indexed, it makes a good reference but is boring to read it all (I didn't :-). The last pages are a short introduction to NFS and Samba, but do not cover all the advanced aspects.

Backup and Restore

Covers the tedious taks of backup with all the different aspects: planning backup, strategies to manage the workload, what media to use, what tools are available in a standard setup (tar, cpio, dump, dd, mt, restore). Next is a coverage of the package Amanda and what to look for in commercial packages. Last but not least "restoring from scratch" is covered.

Serial Lines and Devices

Herein is all the stuff about serial devices (tty, termcap, terminfo, stty), usage of USB is covered for FreeBSD, Linux and Solaris.

Printers and the Spooling Subsystem

Contains lots on "old school" printing (BSD spooling facility: LPD, System V printing, AIX spooling facility), a short note "Print Services for UNIX" on Windows NT/2000 (works pretty well for basic usage) and on providing print services for Windows by Samba. LPRng and CUPS also get a few pages. Closeout for this chapter is font management under X, which contains a rant on how cumbersome font management is ;-).

Automating Administrative Tasks

This chapter appeals to a healthy laziness which might save some manual work. It contains some samples and introductions, the best it can do is make appetite for more. Included are: shell script (C-shell), tips for testing and debugging, Perl (including there is more than one way to do it-proof), Expect, C and the lesser known tools Cfengine, Stem. It closes with some short notes on how to create a man page for your own software.

Managing System Resources

This chapter wants to make you think a about system performance before you try to manage it. General steps are given: define, determine, formulate, design, implement, monitor and return to start ...

After the general introduction the chapter gets hands-on with monitoring - ps (it is in there after all ...) with all System V and BSD options, pstree and top are covered. The /proc filesystem is mentioned with some samples of how information can be gathered. Process limits are discussed, including how to disallow the creation of core dumps. Signaling and killing processes with kill and killall is covered next. The next chunks in this big chapter are managing CPU (nice, AIX and Solaris scheduler, cron), memory (paging, recognize memory problems), I/O (performance, disk quotas), network (netstat, some notes on DNS and NFS)

Configuring and Building Kernels

This chapter is essentially a bunch of short guides on what to look for when configuring and building a kernel, for Linux lilo is also explained.

Accounting

This is an introduction to what components are relevant for accounting, and how to enable/disable it. As such it shows what can be done with the standard tools on BSD-style accounting (sa, ac) and System V-style accounting. A few pages are dedicated to printing accounting.

Appendix: Administrative Shell Programming

This is a more thorough introduction to shell programming that could have been integrated in the chapter Automating Administrative Task. Other than that it is a solid, short reference to shell programming.

Index

Last but not least is a very concise index (50+ pages), which makes it easy to find anything that's in the book.

What's bad

There's not much I really disliked in the book, I can recommend to anyone who needs an introduction to UNIX system administration or a general reference text. Some points are: it's not on UNIX CD Bookshelf v3.0, which is a pity for reference usage, there are almost no links to WWW sites of interest, almost all links to further information are to other O'Reilly books (granted, most of them are quite good) and sometimes I found the order in which themes are discussed slightly less than optimal for "junior administrators".

What's good

Almost everything (writing style, coverage), except those few issues mentioned in "What's bad". The very good index makes it easy to find the information that is applicable in your special situation, even with all those different UNIXes. If you are looking for a general UNIX reference and/or introduction, look no further (you might want to compare it with "The UNIX Systems Administration Handbook", and decide for yourself, note that the USAH does not cover AIX).


You can purchase Essential System Administration, 3rd Edition 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.

Essential System Administration, 3rd Edition

Comments Filter:
  • Because... (Score:5, Funny)

    by Black Parrot ( 19622 ) on Thursday April 17, 2003 @01:02PM (#5752433)


    > one wonders why the book doesn't bear the title "Essential UNIX Administration"

    Because you don't administer Windows systems, you drive them.

    • by sirinek ( 41507 )
      *laugh* Or the users do their own "administration".
    • ....Windows systems are not essential...
    • by TeknoHog ( 164938 ) on Thursday April 17, 2003 @01:33PM (#5752685) Homepage Journal
      In digital-rights-managed America, Windows administers you!
    • one wonders why the book doesn't bear the title "Essential UNIX Administration"

      Because every good NT|foo Administrator is invariably always also a good Unix guru.

    • I thought it was because no one in their right mind would consider a Windows system "essential". All the essential systems should be running on UNIX. If you can live with Windows (un)reliability, it's clearly not an "essential" system.
  • Sure, the review sounds great, but the Third Edition Unix System Administration Handbook by Nemeth, Snyder, Seebass and Hein is the book to get.

    • Dissagree (Score:5, Informative)

      by katie223 ( 663972 ) on Thursday April 17, 2003 @01:19PM (#5752571)
      No, I dissagree. Essential System Administration, 3rd Edition is an excellent book, As is the one by Nemeth/Snyder et all. Both do a superb job of showing you what you need in the Unix world. I'd recommend that you get both, actually, as each has its strong and week points.

      However both do a very cursory overview of security measures, if you ask me. While both are great for an administration standpont (and that's their goal, of course) much more is needed on the security front.

      I'd suggest getting a copy of Hacking Linux Exposed (good for all Unix operating systems) and Building Secure Servers with Linux (more Linux specific, but still has some good any-unix tips and tricks.) These will help round out your administration bookshelf.

    • I must differ, if that's the kind of book one thinks highly off. It's like an overview without any, even shallow, detail or insight.
    • Sure, the review sounds great, but the Third Edition Unix System Administration Handbook by Nemeth, Snyder, Seebass and Hein is the book to get.

      I have that book and quite frankly I was very disappointed with it. It might be the better book for people just starting out, but as a reference I have never gotten much use out of it. I was always able to find out more elsewhere, including Essential System Administration. Not to mention that the handbook only covers Solaris, Red Hat, HP-UX, and FreeBSD. Essential

  • 9/10 ?? (Score:5, Informative)

    by Mr. Flibble ( 12943 ) on Thursday April 17, 2003 @01:06PM (#5752470) Homepage
    Ok, I don't have the third edition, I have the second. It was the first Unix book I got after "Running Linux", and I would give it an 11/10. For me, it filled in all the questions that Running Linux had given me, and gave me a very solid grounding in Unix. I cannot reccomend this book enough - it is one that epitomizes what O'Reilly is good at.

    So, granted I have not read the most recent version, but I cannot see how it only scored 9/10 and not 10/10.
  • Test (Score:4, Funny)

    by grub ( 11606 ) <slashdot@grub.net> on Thursday April 17, 2003 @01:07PM (#5752476) Homepage Journal

    Show this book to your resident MCSE[0] and watch the deer-in-the-headlights.

    [0]- Must Consult Someone Else
    • Re:Test (Score:3, Insightful)

      by Nintendork ( 411169 )
      Yeah, every MCSE out there is a complete idiot that has never used other platforms. Please stop the reverse FUD.

      -Lucas

      • Re:Test (Score:3, Offtopic)

        If he's a resident MCSE, he's likely dumb. Smart MCSE's advertise their relevant certifications not their 'Minesweeper Consultant & Solitaire Engineer' badge.

    • by aquarian ( 134728 ) on Thursday April 17, 2003 @03:15PM (#5753614)
      ...unfortunately, they don't exist for Windows. In my experience, what really separates Linux/Unix from Windows is that the latter is so well documented at the deeper, more advanced levels. Windows documentation is limited to which buttons to push to do simple stuff, things which are self-explanitory anyway. There is plenty of advanced knowledge to be had, but it isn't published. It comes only from years of experience with Windows systems, plus having rubbed elbows with developers who have access to Windows' underpinnings. The worst thing with Windows documentation is that there is nothing on best practices, no "cookbook" type books, etc. Windows administrators and MCSEs would often love to be better, but there's no way to get there. Linux/Unix people, OTOH, have a huge amount and variety of information at their disposal, and can teach themselves to fairly high levels of competence. And what the books don't teach, the community is willing to offer.

  • by bytor4232 ( 304582 ) on Thursday April 17, 2003 @01:08PM (#5752486) Homepage Journal
    I have the first edition of this great book. It got me started in UNIX administration in the first place almost 10 years ago. Its great to see such a classic updated. This book is quite awesome, and I usually recommend it to anyone getting started with UNIX, and always recommend it as a next stop after my intro to Unix class that we offer at our company.


    Also, most of these versions of UNIX found in this book (Red Hat 7.3, SuSE 8.0) are certainly ones you would find in production as well. I am not seeing much Red Hat 8 or 9 on production servers, at least not in my market (Midwest).

    • Same here. My edition has, I think, 4-6 different colors of highlighting from re-reading. After "Running LInux", this got me into Unix, and is one of two technical books I actually read on vacation. (The other being Cheswick and Bellovin) If you want a broad understanding of unix, get this book. Then read a book on your flavor of choice. Then go crash boxes and bring them back to life. It pays better than just doing all the time.
  • by echucker ( 570962 ) on Thursday April 17, 2003 @01:08PM (#5752487) Homepage
    .... is the time factor. RH 7.3 was the latest version when the book went to press, yet RH 9.0 just recently came out.

    I see the same problem in my hobby, marine aquaria. By the time an article or book gets published in the print media, it is oftentimes out of date. Couple this with the human want for immediate gratification and interaction, and it is easy to see why net bulletin boards generate so much traffic.
    • I see the same problem in my hobby, marine aquaria.

      I can see how computer literature can get out of date rather quickly, but if your publisher is missing evolutionary stages of fish, they're just slow!
    • .... is the time factor. RH 7.3 was the latest version when the book went to press, yet RH 9.0 just recently came out.

      YMMV, but I have never encountered a RedHat > 7.3 in production. Most server I support are 7.3 and I still see quite a few 6.2 (this may change with EOLing). Lot of people are averse of using .0 release. (although one could argue that RH 9.0 is really 8.1 ...)

    • I just installed RH 7.3 in another machine today. Why not 8 or 9? I tried 8 on two servers and I had so many problems with it that I went back to 7.3 . RH9 is still too new and it'll be a while before it passes the testing phase. Truthfully I doubt I'll put enough faith in a RH release for production use until it gains at least a .1
  • Alright! (Score:5, Informative)

    by fireboy1919 ( 257783 ) <rustypNO@SPAMfreeshell.org> on Thursday April 17, 2003 @01:10PM (#5752507) Homepage Journal
    No one's [tldp.org] ever [tldp.org] written [tldp.org] a System Administration guide that you should pay for! Now we can stop blowing our money on books with new information in them and buy ones like this!
    • I completely agree. I remember reading all these when installing my RH5.x, It was too long but well worth the efforts.

      plus it gave me added edge even when working on HP/UX and Solaris boxes at work

  • The submitter's name is dvdweyer, not "Dvddwyer"...
  • by ralico ( 446325 ) on Thursday April 17, 2003 @01:21PM (#5752593) Homepage Journal
    No SCO:

    all major UNIX platforms are covered...SCO and IRIX were dropped for this edition,

    Hehe
  • by Anonymous Coward on Thursday April 17, 2003 @01:28PM (#5752646)
    It's an in-depth review of the book...

    http://ezine.daemonnews.org/200301/esa3.html [daemonnews.org]

  • Not to start any flames war or anything

    But a question to all unix system administrators out there .

    Do you see the need of GUI based admin tools as available in windows for unix boxes ? When i say unix boxes i mean servers not desktops.

    because even if i am a linux desktop user, i hardly feel the need for a GUI admin tool for configuring my system

    I can easily do most of the config using a xterm + bash + vi.

    So how many of you find it easy to configure a system using GUI than CLI ?

    • My experience is ssh beats the hell out of terminal services. It requires less bandwidth, it's secure, it's quick and you can do anything needed without a GUI in Unix. Windows has crap all over the place. It takes about 3 times as long to harden a new Windows Server as it does a comparable (services) Unix box.

      Granted I only admin Linux and Solaris so I cannot speak to AIX/HPUX/IRIX/*BSD/... I'm sure they are quite similar. If you want to see good Unix GUI tools go look at the OS X Server Tools [apple.com]. Very cool.
    • Re:questions (Score:5, Interesting)

      by TheRaven64 ( 641858 ) on Thursday April 17, 2003 @02:07PM (#5752951) Journal
      First of all, I need to qualify this by saying that I have never tried to remote admin a windows box. The only windows box I use is my home desktop. I have seen the windows remote desktop tool workign over a LAN, and am informed that it is usable over a modem, but can not comment on this directly.

      In my spare time, I admin a small network of machines for the my university's computer society. Sometimes, I tweak things when I'm in the room, but most of the time things need changing when I'm at home, so remote access to admin tools is important to me.

      I have a 1Mbit Internet connection, so in theory I should have no problems with remote X sessions for graphical configuration. In practice this is only true of apps that use motif or similar, anything that uses gtk or qt is a pain to use over anything < 10Mbit. My first comment about graphical admin tools under Linux then is that they should be graphically simple.

      Another thing I find with Linux graphical config tools is that they rarely give you the power of editing the config file. The only graphical tool I think I've ever actually used (as opposed to firing up, saying yuck and going back to the terminal) is the printconf-gui tool, since it was a quick and simple way of setting up the room's printer. Beyond that it's bash and vim all the way (from whatever terminal I happen to have, and no I'm not hard-core enough to use vi if I have the option of vim).

      On my windows box, the situation is completely the reverse. All my configuration is done from MMC (Microsoft managment console), and on a single machine I prefer this. The options are layed out in a logical structure (which is not to say that they aren't under Linux, where tab completion and guesswork from /etc/ can find the config file I'm looking for 80% of the time). It requires almost no effort to use, which is what I want on my home PC.

      I think my point is that I don't really care whether the config is graphical or textual, as long as it's logical, and can be accessed remotely. If there were a powerful remote admin tool for Linux that I could use over a 1Mbit (shared) connection, I might use it. On the other hand firing up an X server is more effort than ssh, so I might not.

      I certainly wouldn't trust a sysadmin who could only use such tools. If they speed up the way you work, then great, but a sysadmin has to know how to fix things when it all goes wrong (and X fails to start, for example).

      • if you're going to do remote graphical administration, MS's RDP is best of breed. X performs well for one or two non-graphically intensive apps over a WAN, but Remote Desktop is the top performer for multiple apps. VNC sucks wet dog farts.

        Of course, I admin via SSH when possible, as it is usable at 2400bps and above.

    • I would think that by now people would have gotten a clue about this but, obviously many still don't get it.

      It has been proven repeatedly that a graphical interface is a very important, no essential, part of ease of use. Graphical administration tools make it easier to administer, whatever.

      This does not mean that CLI based administration and conf files should be eliminated. To the contrary. For administrators who are familiar with a particular operation the CLI will always be faster but, what about the st
      • Hmm. I disagree on a few points.

        "Having a separate crappy interface for every app or service, while better than none at all, is not a lot better."

        NOOOOOOOOO!!!

        Regardless of your opinion of good GUIs vs. CLI, a bad GUI is MUCH worse than a CLI. Command Line is likely a more obtuse but more direct path into the bit you want to administer. If you put a bad GUI on it, then you're just BEGGING to mess things up.

        This brings up a second point: "if you aren't intimately familiar with every aspect of a syste
        • Re:Absolutely!!! (Score:3, Insightful)

          by FreeLinux ( 555387 )
          depends heavily on the complexity of the program--ever seen the FW1 GUI?

          Yes, I do Firewall 1 quite often and it is more fuel for the fire. As someone who is very familiar with firewalls and works with many of them a CLI only firewall is an annoyance, to be sure.

          Have you used Netscreen, SonicWall, Pix, Raptor, Guardian, IPTables etc? Working with Firewal 1 and a few other big names makes me rather well informed on firewalls and how they should be configured, IMHO. But, with the plethora of firewalls on th
          • First of all, my FW1 comment was misinterpreted, possibly my own fault there. All I meant was that the FW1 GUI is a LONG ways from a 'zero learning curve.' The first while I spent with it after playing with small Linux-based firewalls was utterly shocking--this was a BIG product, and no GUI would make it straightforward on first glance.

            Regardless, what you say makes sense--but I still have to ask why you're you are getting asked (and presumably paid) to do network administration on a product you don't know
    • Actually, I *sometimes* find a GUI tool very useful for Unix administration - but typically only for specific tasks.

      For one example, setting the date/time on a box that's not connected to the Internet. (If it is, then obviously, the best bet is to have it synch with an Internet time server.) In Unix, I don't find it very intuitive or enjoyable trying to get the proper time and date entered from a command line tool.

      More often, I find I really like the full-screen tools developed to run from a command lin
  • OSX (Score:5, Insightful)

    by dubstop ( 136484 ) on Thursday April 17, 2003 @01:29PM (#5752651)
    all major UNIX platforms are covered

    Except for the most widely distributed [apple.com] UNIX platform.
    • Re:OSX (Score:3, Informative)

      The book is for administrators with Unix servers. OSX even though apple sells Xserve boxes is really a client or workstation OS.

      OSX is quite different from the way it does things and the way other unix's does things. For example Unix does not come with netinfo and administrators are required to know which files to edit in /etc to accomplish various tasks. Shell scripting is also big with traditional unixies. In macOSX the control panel is used to configure most things and its gui oriented vs text oriented
      • Re:OSX (Score:3, Informative)

        by Mikey-San ( 582838 )
        Um.

        Not only can your BSD flat files be used in OS X, but you can shell-script the system to hell and back all you like.

        Want to use the BSD configuration files (e.g., /etc/hosts)? Turn them on with Directory Access, in "/Applications/Utilities".

        Want to script xyz task to run once a week at midnight?

        $ sudo vi /etc/crontab

        And go for it.

        Mac OS X is as much of a hardcore Unix as you want it to be, even though there's a pretty UI on the surface.

        For clarificatin, netinfo DOES come with Unix ... But only one
      • by Phroggy ( 441 )
        The book is for administrators with Unix servers. OSX even though apple sells Xserve boxes is really a client or workstation OS.

        Mac OS X Server [apple.com] is a server OS, not a desktop OS. Of course, you can run it on your desktop, and the regular client/workstation version of Mac OS X comes with Apache and Sendmail and Samba pre-installed.

        However, I agree that not very many people use Mac OS X Server yet, compared to other UNIX flavors, and the point of OSX Server is really the proprietary GUI stuff on top, whic
    • I think that if you need a book to tell you how to use MacOS then you probably shouldn't be a sysadmin...
      • Umm... I understand the point you're trying to make, but actually - there's a *lot* to learn about what really goes on "behind the scenes" in the OS X environment.

        It's not an issue of knowing "how to use MacOS" in this case... It's an issue of knowing all the inner workings well enough to feel comfortable being a sysadmin of a box running it.

        Most OS X users probably have no idea how printing actually takes place, for example. People who dug into the OS deeply enough put together the (extremely nice and
    • You'd be hard pressed to convince me that OS X (which I love dearly) has a higher installed base than Solaris/SunOS (yes, the huge gov't agency I'm at still runs SunOS). There are a LOT of older systems still out there running older versions of OSs. People still run Amiga for the love of Ernest Borgnine!
    • Each I ask Apple support about CLI in MacOSx they answer me that "Apple doesn't support CLI and if you will use it Apple is not responsible for any consequenses. Please use GUI for purposes of system administration."

      I think after such answers I barely can consider MacOSx as Unix. No need to mention that all Unix books are useless for MacOSx users.

      P.S. My friends are porting source code between Linux, Unix and MacOSx. They told me that from the source code compatibility prospective Linux is Unix, however

      • And from a source-porting standpoint I can tell you that Linux is more its own beast than *BSD/SunOS/HPUX/Solaris etc. I have not programmed for MacOSX, but as it is based on FreeBSD, it is probably not all that dissimilar, except for the GUI components.

        Anyways, Linux has a lot of its own isms. A whole slew of programs rely on headers located in /usr/include/linux, for example, rather than the more "standard" locations like /usr/include/sys.
  • We all know according to their lawsuit paperwork, SCO is a leader in the Enterprise market. After all everyone just copies their work because its such high caliber that all the other unixies are just catching up.

  • Because (Score:5, Funny)

    by Quixote ( 154172 ) on Thursday April 17, 2003 @01:29PM (#5752658) Homepage Journal
    > one wonders why the book doesn't bear the title "Essential UNIX Administration"

    Because there already is a Windows Admin book targetted to that audience. [amazon.com]

    • I was going to ask if its more then 5 or 6 pages but then I clicked on the link.

      For real dummies a 100 page book is required just to figure out how to dial into their isp and log onto the net.

    • Very funny, but what is more scary is Windows 2000 Registry for Dummies. This book [amazon.com] must keep more Windows Admins employed than I can imagine...
  • the one tip that is the sum of all my sysadmin knowledge?

    Never unalias rm

    Learned that one the hard way ...

    • Funny, that is the first thing I do when setting up a profile under RedHat Bloatware. That and cp and vi.

      Linux is dead.

    • Re:Does it cover ... (Score:3, Interesting)

      by swordgeek ( 112599 )
      Unalias? To unalias something, you have to alias it first. I've never seen a Unix with rm, cp, or mv aliased out of the box.

      If you need to alias these commands, you're probably typing too fast and thinking too little.
      • Unix with rm

        RedHat 7 & 8 aliases 'rm' to 'rm -i'.

        Most places I've worked alias rm to something else. My favorite is the 'move things to the ./.gone directory, and purge the directory later on. It's saved me a hundred times.

        • Heh. Yes, I know. I was being doubly facetious Firstly, Redhat isn't (technically, and possibly in other ways) Unix. Secondly, aliasing rm to 'rm -i' for sysadmin accounts has long been generally accepted as a Bad Thing! It drives me NUTS to see RedHat (and others) setting up root aliases out of the box. It's Wrong, Bad, and Dangerous.

          I don't know of any admins I respect who allow root to have rm, cp, or mv aliased. None.

          But that's just my curmudgeonly old-fashioned opinion. :-)
          • Firstly, Redhat isn't (technically, and possibly in other ways) Unix.

            So I was having a similar discussion the other night. Why is RedHat, or Linux, any less Unixy then Solaris or HP-UX?

            Unix was an OS written years ago by AT&T. The copyright is now owned by SCO. So doesn't that mean that Linux, Solaris and HP-UX are all equally NOT Unix?

    • Funny, Slackware doesn't alias it, nor do most other UNIX flavors as far as I know. If you get used to relying on "rm" being aliased to "rm -i", you may find yourself in trouble if you switch to a non-RedHat system.

      Maybe it's just me, but although RedHat looks like a pretty nice desktop OS for newbies, I wouldn't put it on a server.
  • by Znonymous Coward ( 615009 ) on Thursday April 17, 2003 @01:34PM (#5752692) Journal
    0. Replace legacy UNIX systems with Linux.
    1. ???
    2. Profit!!!1

    • Isn't that just:
      1. Replace legacy UNIX systems with Linux.
      2. Profit!!!
      If we are talking about "legacy" systems, anyway.
  • Sure,

    You can purchase

    It's cheaper, though, from amazon.com [amazon.com] ($38.47 v. bn.com's $43.96).

    If you're in Canada, chapters.indigo.ca has it for $54.56 Canadian (CAD) [indigo.ca] -- under $38 US.

  • Packing my bookshelf (Score:4, Interesting)

    by wytcld ( 179112 ) on Thursday April 17, 2003 @01:39PM (#5752726) Homepage
    I was just packing up to move my office, and looking at all the mostly-redundant Unix and Linux administration books, and realizing that although I have more than two dozen on different aspects, I open maybe one or two of them once or twice a year. Everything else it's just easier to pursue online. I'm a believer that the book format has real advantages, particularly when fresh to a subject area. When I take up some totally new technology again, I'll buy a half-dozen books on it again. Maybe. If the online resources aren't there yet.

    As for what flavor of Linux to cover, I've run Slackware, Red Hat, Mandrake and Debian in production environments ... and any place I have the choice these days I prefer Gentoo. It's better laid out. It's more current. It better optimizes for the hardware. Or if I just want to give someone a slick workstation in a hurry, Knoppix (yeah, it's Debian-based, but it's way ahead of it too).
  • by Nathan Ramella ( 629875 ) on Thursday April 17, 2003 @01:41PM (#5752740) Homepage
    They're not essential to administration! :)

    -n

  • by Corvus ( 27991 ) on Thursday April 17, 2003 @01:43PM (#5752758) Homepage
    In the category of "essential" books for whatever we are calling sysadmins these days, we must includeThe Practice of System and Network Administration [everythingsysadmin.com]. 'Nuff said.
  • Linux isnt UNIX. It does not have permission to be called UNIX. Not even UNIX clone. UNIX relative *might* just pass.
  • by tenchiken ( 22661 ) on Thursday April 17, 2003 @01:47PM (#5752787)
    Is that they ignore a large part and parcel of being a administrator. The Ethics and Legal portion of being a admin is oft ignored, and no book outside of USAH focuses almost at all on this issue.
    • Mmm.... you may have a point, but personally, I'd just as soon they save that for a seperate publication.

      The "ethics" of system administration doesn't seem to be very clear-cut anyway. Much is a matter of opinion, as I quickly saw when I worked in corporate systems administration.

      Take something as seemingly simple as to whether some of our engineering staff should be allowed/able to install game software on their laptops and play it during their lunch hour. A couple of admins said "Sure! We won't supp
  • by tmark ( 230091 )
    It is revealing that OS X is evidently not covered in this book, especially since in many ways it is so different from other Unixes and since there are many reasons to expect that OS X users would *need* such a book.
    • It is revealing that OS X is evidently not covered in this book

      What do you think it reveals? Could it be that the authors didn't see as much a market for the book in OS X admin circles, either because not enough folks are using X Server or because there's already enough books on the subject. Or something else?

      is so different from other Unixes

      I'm not expert enough to speak with final authority on it, perhaps, but it sure seems like the difference between RedHat Linux and FreeBSD is greater than that b
      • Mac OS X Server [apple.com]'s strength is its proprietary GUI administration tools, which are not available on other platforms. You can also use it mostly like FreeBSD, for anything Apple doesn't include.

        What's different between FreeBSD and RedHat, that you think might be the same between FreeBSD and Mac OS X Server?
        • What's different between FreeBSD and RedHat, that you think might be the same between FreeBSD and Mac OS X Server?

          Well, I would have thought that there was plenty in common between OS X and FreeBSD, seeing as OS X actually incorporates an entire BSD Unix under the hood. Plenty more in common that between either of them and any Linux distro. I mean nobody would say that RedHat was more like FreeBSD than Mac OS X was. Or, as I asked before, am I missing something?
    • Re:OS X (Score:4, Informative)

      by TheCrazyFinn ( 539383 ) on Thursday April 17, 2003 @03:30PM (#5753754) Homepage
      If you turn on the BSD files, OSX is nearly identical to FreeBSD. If you don't, it's closest to NeXTSTEP/OPENSTEP, and really would require it's own book. NetInfo is a whole other world.

  • Pffff ... (Score:3, Insightful)

    by Etyenne ( 4915 ) on Thursday April 17, 2003 @01:54PM (#5752849)

    Though this chapter is well done, and a nice introduction to mail in general, I would prefer to get rid of it in favor of a "mail-is-only-for-dedicated-servers" policy. A short note on how to deactivate or remove the default MTA should be included in the previous chapter (yes, I know that not everyone shares this point of view).

    This made me jump on my chair ! How are you suppose to read alert sent by email, backup report, cron errors, etc ? You login to each and every one of your Unix server every morning to check root's mailbox ?

    As far as I am concerned, a working MTA is an essential part of any self-respecting Unix system. At the very least, a good sysadmining book should tell you how to configure a smarthost and make sure your MTA is not an open relay.

  • by avdi ( 66548 ) on Thursday April 17, 2003 @02:08PM (#5752962) Homepage
    I have the previous edition, and it's IMO one of the classics of UNIX use, up there with UNIX Power Tools. In fact, it's the perfect SysAdmin complement to the more user-oriented Power Tools. It's readable, professional, and it manages to be detailed enough to be used as a reference while still accessible enough to introduce a relative UNIX newbie to the underlying concepts of UNIX. Highly recommended.
  • I have the 2nd Edition of this faithful book and it's about stinking time the 3rd edition came out. hrm, another trip to the bookstore I go...
  • GREAT BOOK!!! (Score:2, Interesting)

    by Anonymous Coward
    We use this book for a UNIX class I'm taking right now at my university. It's great. I've learned so much from it. I think the nicest thing about it is that it shows you how to do things in 5 different flavors of unix. My class focuses on Solaris, but as I'm going along I read the Linux and FreeBSD sections too, I've learned so much from this book. It's a great reference to have. I've pretty much read the entire book and I advice anyone who doensen't own this book and is interested in any form of *nix
  • Perhaps it's not called Essential UNIX Administration because UNIX is a trademark [unix.org]? And this book is about a generic class of operating systems, not one specifically?
  • FreeBSD was added? (Score:2, Informative)

    by Sevn ( 12012 )
    News flash. FreeBSD has been covered in this book
    since the beginning if my memory serves me right,
    and the author is a pretty big fan.

"What man has done, man can aspire to do." -- Jerry Pournelle, about space flight

Working...