Linux for Public Service
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.
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:
It must handle multiple dial-up users smoothly,
It must be seamlessly integrated with the TCP/IP Internet protocols,
It must be easily expandable and easily modified for our various needs, and
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.
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.
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 (email@example.com), a friendly Linux admin from Illinois. (He also offered to act as our DNS secondary).