Linux for Public Service

JCICNet, an Internet Services Provider, uses Linux to serve its customers. Here's why.

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).

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix