Although I have years of experience with UNIX, I'm still a relative newcomer to Linux. I am not new to networked PCs. What I am new to is the level of involvement that Linux allows and even rewards. However, the installation and configuration books I own don't go into enough detail about networking. Nor do the HOWTOs give enough of an overview or coordinate well with each other. Consequently, the Linux Network Administrator's Guide, by Olaf Kirch, is just what I need to keep my home network running. It is a book for anyone who needs to administer a small Linux network or networked Linux workstation, but is not a full-time network administrator.
Don't let the most recent printing date (1995) scare you off. No, it doesn't cover IPv6, but then my ISP doesn't require or support it and I expect yours doesn't either. Face it, the basics of networking have been around for years. Yes, the cutting edge is changing constantly. If you are working at the cutting edge of networking, you don't need this book. Still, the areas where the book does show its age involve:
Easing into Linux is a problem. It sometimes seems like you have to know it all before you can work with any of it. An approach that works for me is to read a manual or book until it starts running out my ears, then do some of the obvious things. Once I have some idea what's going on, I reread the book. While reading, I flag things to do. With Linux Network Administrator's Guide, I flagged 13 places in the first 130 pages.
The first three chapters are background. Chapter 1 introduces UNIX-to-UNIX Copy (UUCP) and TCP/IP networks. Though UUCP can be done over TCP/IP as well as dial-up lines, its main feature is that it queues up e-mail, news articles, and files to be transferred or printed and sends them in a batch at a later time. UUCP dates from the late 1970s, when high-speed modems ran at 1200 bps and the Internet was the Arpanet and a research vehicle. I am ambivalent about using UUCP. Is a home computer with dial-up access to an ISP or a laptop occasionally connected to a network suitable for UUCP? So far, I don't think so. Still, it is nice to have the option covered, even if I don't choose to go that route.
Chapter 2 goes into TCP/IP networks in more detail. Kirch introduces an example network for the hypothetical Groucho Marx University. The net topology figure on page 24 shows three subnets connected to the campus backbone. It shows clearer than any thousand words why IP addresses belong to network adapters, not computers. A gateway computer connecting a subnet (that is, a home network) to a larger network (an ISP) has IP addresses for each connection, and they can be different. Unfortunately, there is a typo in this, and the diagrams don't match the text. The IP address on the backbone side of the Computing Center gateway should be 1.2, not 1.1. In the domain name space example (Figures 2 and 3 on page 28), the .maths domain is not a zone and the circle next to it should be deleted.
Chapter 3 ("Configuring the Hardware") is about the kernel and device drivers. Many writers emphasize that you must build your own custom kernel. I have successfully avoided this up to now. The advent of loadable device-driver modules and inexpensive memory alter the necessity to rebuild the kernel. Low-level functionality such as device drivers can usually be put in a loadable module. The memory regained by deleting unused features is insignificant for today's typical PC. Linux is efficient in its memory usage and runs well with a single user in 20-40 MB, though it can run in 8 MB (4 MB without the X-Windows system). Over time, the repeated exposure to how to build a custom kernel is acclimating me to the idea.
Chapter 5 ("Configuring TCP/IP Networking") is where I really started to flag things. Kirch introduces the Virtual Brewery network example used through the rest of the book. It starts simply -- just a private network with two subnets and a gateway computer between them. After describing how to setup the permanently connected part, Kirch adds a laptop with a point-to-point link to the gateway computer. The example uses a Parallel Line IP (PLIP), TCP/IP through the parallel port. There are two other point-to-point protocols in common use, Serial Line IP (SLIP) and Point-to-Point Protocol (PPP). They are more complex and are covered in separate chapters. The last four pages cover tools for checking your network configuration. I really appreciate this. It is nice to see how the configuration commands were interpreted and what the current configuration is. I hate the write-only registers in some hardware where there is no way to find out about a previous program or invocation set. Gurus on communication between people tell you to paraphrase back to the other person what you understood them to say, to ensure you both have the same understanding. This is good advice for computer programs, too.
Chapter 6 is on "Name Service and Resolver Configuration." The resolver is the part of the Linux C libraries that combines the /etc/hosts file contents and the Domain Name Service (DNS) results to map host names to IP addresses and vice versa. Other books cover these parts separately. What makes this book so uniquely valuable is the explanation of how they interact. I had been having problems with host name lookup. What worked when my computer was offline didn't work when I was online with the ISP, and vice versa. I was using the ISP's domain name for my home network's domain name. This is wrong. Instead, pick something unique and ping it while online to make sure no one has registered it (the name lookup will fail). My first choice was registered but not in use (the host lookup succeeded, but the ping wasn't returned). I also needed the "trim <domain.name>" directive in the /etc/resolv.conf file.
The sections on setting up DNS is of interest to anyone with their own domain, regardless of whether they or their ISP manages the DNS server. I find it helpful to understand DNS even though I don't (yet) have my own domain name.
Kirch also covers resolver and DNS setups that seem reasonable and yet give strange results. I like this. Knowing what not to do and why is often more valuable than a cookbook style "just do this." The chapter concludes with a section on how to check the operation of name server setup. Again, I like knowing how to check that what I said was also what I meant.
I considered using SLIP to connect my laptop to my desktop. Most books on SLIP assume you are using a dial-up line. Chapter 7 ("Serial Line IP") also covers a plain serial link and tells how to change the advice in the previous chapter to accommodate dial up. This book is good about links forward and backward to itself and to HOWTOs and Internet standards (RFCs). Some aspects of SLIP are common to PPP and are covered in the following chapter. Kirch covers security aspects of SLIP connections, a topic missing in other books. While I was reviewing this book, the Melissa virus and its clones were released, a Linux-specific worm was found in the wild, and my computer's network ports were scanned and telnet connections attempted through the PPP connection to my ISP by several would be intruders. I am sure this kind of thing went on while I was running Windows 95 and I never knew. Prior to reading this book, I had used the ISP, Ethernet, NET-3, and PPP HOWTOs. I was able to get dial-up to my ISP working with these. After reading the chapter on PPP (Chapter 8), I understand what is going on, how PPP can go wrong, and what needs to be done to fix it. Good stuff. Also necessary when I added the second PPP link to the laptop. The ppp-go script that comes with Slackware 3.6 does a "killall pppd" so starting up the second PPP link would always kill the first.
Chapter 9 ("Important Network Features") -- covers the inetd super server, tcpd access control facility, and Remote Procedure Call (RPC) package. Rather than leave my system vulnerable to crackers until setting up a firewall, I set up a stonewall. I disabled all incoming ports by not running the inetd daemon (Samba sets up its own daemons and doesn't usually need inetd). This worked until I wanted to add the laptop to the network. I needed some way to complete the installation of various software packages besides a stack of floppies. With the tcpd access facility, I allow the local machines to do their thing without letting anyone in from outside. Other books and the HOWTOs only cover the "client" PPP side. This book covers the "server" side also.
Chapter 10 covers "The Network Information System" (NIS), an intermediate step between all network information in configuration files and setting up your own DNS. From this chapter, you get an idea of what is involved in NIS setup and what it is useful for -- a small LAN with all hosts permanently connected, occasionally adding or deleting hosts. This describes the usual LAN in an office and is generally not useful for a home network. Any network with Internet connectivity is going to have to use, if not configure, DNS. There is enough in this chapter to make an informed decision, but as Kirch notes, "If you want to run any of these packages, the instructions in this chapter may or may not be enough."
NFS is a way to share files between computers, principally Linux and other types of UNIX boxes. (Samba is a way to share files and printers between Windows and Linux/UNIX boxes). There are problems with NFS that Kirch covers in Chapter 11 ("The Network File System") and I have read diatribes about NFS. Some are unique to Linux circa 1995 and I expect have been fixed. Others are inherent in NFS. There are alternatives, such as the Andrew File System (AFS), but in my experience, the cure is worse than the cold. There is current work in this area (the Coda distributed file system, for instance). Stay tuned. Chapter 11 tells how to setup NFS clients and servers. NFS looks like the way to share the CD-ROM drive on a desktop computer with a laptop to complete an installation started from floppies.
Chapter 12 addresses UUCP, a suite of programs for storing and forwarding print jobs, e-mail, newsgroup articles, and other remote jobs. At first glance, UUCP looks like a holdover from the old days of isolated mainframes with dial-up at night when long distance rates are lower. But a laptop with a sometime connection to another computer has a lot of the same needs. Ian Taylor has done a more modern reimplementation of UUCP that has been ported to Linux. At 30 pages, Chapter 12 is long, but setup is clearly explained, along with some of the details and protocols used under the hood. You will have enough information to setup a basic installation and keep it running.
Chapter 13 covers e-mail routing, both via UUCP and on the Internet, and the Elm text-based e-mail client. Having tried both, I find I prefer Netscape Navigator in the X environment for reading and writing mail while online with my ISP. However, it does not deal gracefully with composing mail offline. I use Mutt, an Elm derivative, to dash off a quick idea that comes while offline. Kirch also covers UUCP e-mail routing.
An e-mail client is not enough for Linux, even on a single-user system. Linux (like UNIX) allows setting up batch jobs that run at a specified time in the background. These may include UUCP dial in the dead of the night, software rebuilds, benchmarks on an unloaded system, or backing up a system. All of these generate output to the e-mail system. A Mail Transfer Agent (MTA) handles routing this e-mail to where the e-mail client expects to find it. Chapter 14 examines Smail, an MTA suitable for small systems. Kirch shows how to set up Smail for a TCP/IP environment, UUCP environment, and mixed TCP/IP-UUCP environment. I have seen HOWTOs and tips for both environments, but this is the only place I know that covers both. Kirch tells what is going on under the hood in sufficient detail to be illuminating without drowning you in the minutiae.
Estimates are that sendmail (covered in Chapter 15) handles 70-80 percent of the e-mail in the world and, as you might expect, sendmail is a complicated subject. The sendmail book (also from O'Reilly) is over 1000 pages. According to Kirch, "It's been said that you aren't a real UNIX system administrator until you've edited a sendmail.cf file. It's also been said that you're crazy if you do it twice." Kirch is confident that the sendmail+IDA combination is usable by mere mortals and that even real sysadmins are more efficient with it. Even with the help of the IDA program, this is still tough stuff to wade through. Unless you are in training to be a real sysadmin, Smail or the relatively new Qmail are a better way to go.
Chapters 16 through 19 are short and cover newsgroups. I must admit that I just skimmed these chapters. I would rather let my ISP handle this and use Netscape to read them. My wife is the other user on our network and she uses AOL, not an ISP. There is no reason to have any newsgroups copied to our network for just one news reader. However, the sysadmin on my ISP does need this information, and I may need it for reference when something goes wrong.
Linux Network Administrator's Guide has a permanent place on my bookshelf. With it, I can discard about half of the HOWTOs I used before I read this book. I would have been better served by reading this book first, then reading the PPP and ISP HOWTOs. The NET-3 and Ethernet HOWTOs are now redundant. I would rather have just this book than just the HOWTOs.
DDJ