Linux for Public Service

by Dan Hollis

I'm the system administrator for JCICNet, an Internet Service Provider (ISP) that provides public access Internet services for Southern Oregon. This article explains why we use Linux and describes some of our experiences with it as an ISP.

These days, one of the hot topics seems to be using Linux as a base for public access Internet systems. There are a number of reasons why, for many ISPs, Linux is the operating system of choice.

Taking the Plunge

When our ISP first decided to provide Internet access to the local area, my first task was determining what kind of hardware was needed. The basic requirements for the system were:

  1. It must handle multiple dial-up users smoothly,

  2. It must be seamlessly integrated with the TCP/IP Internet protocols,

  3. It must be easily expandable and easily modified for our various needs, and

  4. It must be very inexpensive (we are a relatively small ISP).

For me, the answer to the first three was obvious—Unix. Requirement number four mandated the hardware be on a PC clone. But which version of Unix?

I had heard about Linux, but the biggest question was: if it's free, how reliable could it possibly be? There was one way to find out. I read the FAQs, the HOWTOs, and the comp.os.linux newsgroups. Although I didn't really have a clue what was being discussed in the newsgroups, I started asking questions. I never received anything negative about its reliability, so I figured that even if it wasn't suitable, at least we wouldn't be out any money, so Linux was given the green light.

We eventually settled on the following configuration:

  • DX4/100 with 16mb RAM

  • Buslogic SCSI Adaptor

  • Quantum EMPIRE-1080S 1 gig SCSI drive

  • Toshiba XM-3401TA SCSI CD-ROM

  • QIC-117-compatible tape drive

  • BOCA Board 2016 (16 port serial card, cables not included!)

  • Supra 28.8k and AT&T Paradyne 14.4k modems

Our network provider sold us the following equipment:

  • Morningstar Express Router

  • BAT Technologies 56k CSU/DSU

All told, the total hardware cost came to close to something like $10,000.

Setting It Up

Our Linux distribution was the Infomagic 2-CD set, from which we installed Slackware. The installation was relatively simple; everything was menu driven with very little guesswork. Within hours we were fully installed, up and running. Very impressive.

The network was all configured thanks to the menu driven installation. I never had to touch configuration files. We just configured our router, and we were on the net.

Next came the BOCA serial board. Using setserial and /etc/rc.d/rc.serial, configuration was painless. I just uncommented a few existing lines and the BOCA would auto-configure itself on bootup. I installed mgetty, and within an hour, we had working dialups.

Last came the front end that the users would have to tangle with. Since most of the users would not have any experience with the shell, I used the Dialog package (documented in Linux Journal issue #5) to whip up a spiffy menuing system using shell scripts.

All the while, I was amazed at how straightforward everything was, all the pieces to the Linux puzzle fit together neatly. I had experience with various Unices in the past, and Linux was by far the easiest to come to grips with. Packages just plugged in and started working, with little or no configuration required. A lot of this I attribute to Linux's FSSTND (File System Standard)--a boon, especially to system administrators.

Bringing the System Up

With everything configured, we were confident enough to throw the switch and start letting users pour in. I watched the system closely for hours, all the while expecting this “free operating system” to explode into a million pieces, taking our hardware and subscribers with it into /dev/null.

Several weeks later, I stopped worrying. During our first few weeks the system ran smoother than I had ever expected. No kernel panics, no strange file system problems. It wasn't flawless by any means, but none of the problems were insurmountable or disastrous. For a free operating system, I was very happy with Linux.

The first real problem I ran into was with hanging processes. We were having a bizarre problem where, if someone dropped carrier without logging out cleanly, processes were left hanging on `con'. It can be very disconcerting to log in and find the system load at 26.0 or so! This took about a week to track down. I asked various questions on the newsgroups and IRC. I eventually ran across another system admin on IRC who had the exact same problems. We narrowed it down to the POSIX behavior of bash; replacing bash with zsh solved the problem.

The second problem we encountered was with our Supra modems crashing occasionally, which was (thankfully!) not a Linux problem. I would have to power cycle the modems to get them to wake up again. After several calls to Supra tech support, it was revealed that if the modem received characters while in the middle of a hard reset (via an `ATZ' or DTR drop) it could crash. A quick change to the initialization string and the modems cleared up.

Our third problem was a bug with mgetty. It turns out that mgetty will happily echo back `+' characters to your modem. If someone logs in and sends three `+' characters in a row, mgetty echoes those back to the local modem which, of course, puts it in command mode. Then mgetty will happily sit, blabbering away in a chat loop with the modem. A small one-line modification to mgetty (which would not have been possible without the freely available source code!) fixed this.

Our final problem was with smail. It simply would not send to hosts on the Internet that had an MX pointer in their domain name server (DNS) record. I finally figured out that the Slackware distribution of smail did not have the bind driver compiled in. I downloaded a newer version of smail off of ftp.uu.net and it worked flawlessly.

Since then, the system has been relatively painless to administrate. When our net provider's DNS server started flaking out, I got my own DNS server up within an hour with the help of Douglas Rabe (darabe@templar.fgi.net), a friendly Linux admin from Illinois. (He also offered to act as our DNS secondary).

Linux Support

Support on the net has been great. The comp.os.linux.* newsgroups carry amazing amounts of information. IRC is good, except for a couple sour grapes: it can be very disappointing on IRC to see someone answer a newbie's question “how do I untar a file?” with alias tar `rm -rf' and then type tar filename. To me, that is one more person permanently turned off of Linux due to someone's lame joke. Nobody said newbies had to ask dumb questions, but then nobody said smarti-alecks had to answer them, either.

The software support for Linux has been outstanding. It seems like any new software package, no matter where I ftp it from, has a specific makefile configuration for Linux. And thanks to FSSTND, most of it plugs right in.

There are a number of reasons why I personally prefer Linux. Since the source code is available for everything, if something is wrong, I can fix it myself—instead of spending hours on hold with a software vendor who may or may not fix my problem (or even understand what the heck I'm talking about!). Have you ever spent hours on hold with a vendor only to get a support person who is perfectly ready to help you—with your VMS problems?

Another major point with Linux is that user licenses are a non-issue—something which has continually come up and bitten us with other commercial operating systems. The user licenses issue is something that should be of great importance to an Internet Service Provider.

From home, I administrate the main dial-in system with—what else—my own Linux box. Since I deleted DOS and Windows from my hard drive and installed Linux, I've never been happier with my PC.

Daniel Hollis is a systems programmer for Pharmacy Computer Services, where he is trying to find ways to slip some Linux boxes into the workplace. He is also the system administrator for the jcic.org domain and is currently involved with authoring the Linux-Public-Access-HOWTO. He can be contacted via e-mail at dhollis@hq.jcic.org.

Load Disqus comments