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 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 (, a friendly Linux admin from Illinois. (He also offered to act as our DNS secondary).


White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState