Linux in the Real World

The Linux kernel only offers the basics of an operating system. You must chose one of the many Linux distributions to use on your system. ISPs have a number of specific concerns which might not coincide with the general user's, and foremost among these are upgradeability, coherence, and network integrity.

Upgradeability is essential to the ISP because of two competing demands. First, you will need to offer the latest and greatest solutions. The Internet protocol suite of services is constantly growing, and the reason we have distributions in the first place is so that we all don't have to port, clean up, and install the various software packages on our systems by ourselves. Secondly, your service must be reliable. This means that when you do want to upgrade your system, taking it down, formatting the hard drive, and installing a new distribution is not a very good option.

By coherence, I mean how well the various components of your system fit together. For example, installing Wietse Venema's TCP wrapper (/sbin/tcpd) is not a trivial exercise, mostly because you must coordinate it with the various weird features of your network daemons. Slackware and most other Linux distributions come with tcpd built in and ready to go. A coherent Linux distribution saves you a lot of effort, as you need not fix the mistakes in the distribution.

Finally, you will live or die by the quality of your network functions. Sloppy and/or buggy compilations of network utilities, non-functioning daemons, or generally inferior network services are unacceptable in your distribution.

New distributions are usually plagued by the latter two of these problems, and this was the case with the early releases of Red Hat. However, Red Hat is very easily upgradeable and has been steadily improving the general quality of their product. Additionally, if you are brave enough to try Linux on a Sparc or Alpha, then Red Hat is probably the way to go.

Coherence and strength of network services have always made Slackware a particular favorite of mine, and I have gotten a lot of mileage out of it. It saddens me, therefore, that the persistence of bugs in the distribution and, most of all, the impossibility of upgrading a Slackware system are causing it to drop out of favor.

My own bets are laid on Debian, a package maintained much as the kernel is developed—by a team of people over the Internet. Debian is still gearing up, and there have been problems with one CD-ROM version of it, but I think that it holds the most promise.

Speaking of CD-ROM problems, get ready for them. Many times I have run into people who are having networking problems with a CD-ROM version of Slackware, to whom I recommend reinstalling the “N” section (networking) from an Internet source. More than 90% of the time, this solves the problem. We have a T1 connection to the Internet, and although we keep a CD-ROM version of Linux lying around for safety reasons, I prefer installing directly from the network, because if one vendor's CD-ROM version of Slackware is broken, only their customers will know it, but if SunSITE's copy of Slackware is broken, the whole world starts yelling.

Really, choosing a distribution depends more on what you're familiar with than anything else. If you have experience with Red Hat, for example, you will want to think seriously before selecting a different distribution, as the pain of learning a new distribution might be greater than the advantage to be gained.

Your major task after installing your new distribution is to set up your network and get packets flowing. This is not the topic of another article—it is the topic of a full-length book! Fortunately, the Linux community is very responsive to the needs of its customers (i.e., itself), and one of the main reasons to use Linux is because of the documentation. You should read the Net-2-HOWTO as an absolute minimum, and a copy of Olaf Kirch's Linux Network Administrator's Guide (the “NAG”) should sit on your desk within easy reach.

Of course, getting packets flowing is just your first concern in establishing your network. There are 6 main topics which you should consider: connecting customers, DNS, mail, news, Web/FTP, and network security. We will examine each of these in turn.

The Serial-Line Internet Protocol (SLIP) was a ground-breaking development in computing. Then again, so was the Apple II. While still in favor in certain circles, SLIP is dead and should be recognized as such. Its successor, the Point-to-Point Protocol, (PPP) is the wave of the future. (Okay, it was the wave of a year ago, but you get the point.)

SLIP is firmly entrenched in second place to PPP for several reasons. First of all, SLIP is only capable of serving IP traffic, whereas you can run virtually anything over a PPP link, including IP, AppleTalk, IPX, and others. Second, PPP's Link Quality Management (LQM) functions give you a solid connection by running it at the proper speed, regardless of electrical interference or other line noise. Finally, the newer versions of PPP will have world-class authentication, enhanced LQM, and other features, such that PPP will continue to pull away from SLIP in terms of quality.

Linux comes with both SLIP and PPP built in. Your kernel needs to be compiled with both SLIP and PPP support. Remember this when you install your system, or you will rack your brains trying to figure out why one or the other is not working when you try to use the missing one.

You will want to read the PPP-HOWTO, as it is invaluable in understanding how to make PPP work. You will need to decide a number of things, such as whether to give customers shells from which to invoke PPP or make PPP their default login program.

Furthermore, how will you do the accounting for their time on-line? The answer to the previous question might affect this one. Adam McKee's BBS-Util might be helpful, as might a number of other packages. Ask around, look around, or do what we did—write your own.

Getting PPP/SLIP to work is a medium-sized job, and you will want to test your setup via modem with as many different OSs as possible. Win 3.11, Win95, OS/2 and OS/2 warp systems need to be able to dial in, and you need to test all of these systems to make sure that you can explain to your customers how to do it. Writing a HOWTO for each OS as you test it is a good idea. And don't forget your Macintosh customers! They suffer under the oppressive boot of hegemony as much as MS Windows users do, and they usually make good customers, as they are willing to pay good money for a product that works.

A good decision might be to put your PPP customers on the same machine as your mail server, making it easier to maintain only one /etc/passwd file for the entire operation. pppd will use username/password pairs from the /etc/passwd file, so throw that pap-secrets file away!

PPP is fairly time-consuming to set up, and if you decide to offer non-IP services, this, too, will take time. However, usually once it's up, it's up, and you can go on to other problems. Just be sure you have backups!