The ISP and its switch to the Linux platform

 

 

 

 

 

 

 

A lot of rumors have been circulating about the Internet service provider (ISP) Eskimo North (http://www.eskimo.com/) converting totally to Linux. I decided it was time to talk to Eskimo’s owner, Robert Dinse, and find out which rumors were true. We talked via e-mail on July 9. Eskimo is a popular ISP based in Seattle, so Anne Tiemann went over and took the pictures shown here.

Margie: I understand you have just about completely moved to Linux on SunSPARC workstations. Is this true? What were you using before?

Robert: This is somewhat incorrect. We have seven Suns running SunOS 4.1.4, six Suns running SPARC Linux (Red Hat) and one PC running Linux.

In some areas Linux is clearly superior, and in some it still has problems. In general, it works well with SunOS, so mixing platforms isn’t a problem and we use the OS best suited to any particular task.

Margie: What factors entered into your decision to switch to Linux?

Robert: With SunOS we are locked into one hardware platform, SPARC. Basically, SunOS is no longer being developed, and much new hardware is not supported by SunOS.

Sun’s replacement, Solaris, isn’t particularly fast in my experience, is buggy, bloated, and you can’t do anything without checking with a license manager first. The license fees are ridiculous and the support from Sun has always left something to be desired. There seems to be a new root exploit almost daily for Solaris, and fixes from Sun are often far from instantaneous.

So continuing down the Sun path using Sun’s new operating system was not a viable option for us. It’s not cost-effective in terms of either the actual cost of the software or efficient use of hardware. Without source code, we are at the mercy of the vendor—a situation I wanted to get away from.

Linux, on the other hand, was available for a multitude of hardware platforms. Intel class CPUs are adequate for low-end applications, and extremely inexpensive relative to SPARC CPUs. For high-end applications, Alpha and Power-PC chips are beginning to look attractive. Suns still have some architectural advantages that may continue to make them the best hardware choice for disk-I/O-intensive applications. The main advantage is the fact that the peripherals are also mapped through the MMU (memory management unit), so that disk I/O can be a direct memory access (DMA) into user space instead of having to access kernel space and then be copied by the CPU into user space, although with today’s faster CPUs, this is becoming a minor point. The point is, whichever of these platforms is best for a particular application, Linux gives us the freedom to use it. With SunOS, we can use Suns or a SPARC clone but not Intel or Alpha or Power PC, and while Solaris does support Intel, it’s my feeling it is of marginal functionality on any platform because of Sun’s perceived need to enforce arcane licensing policies with license managers.

Full source code is provided for Linux, so we are not at the mercy of a vendor for fixes. If we have any questions about exactly what the code is doing, we can just look at the source.

Linux is still being developed, which means that as things like IPv6 become mainstream, it will remain viable where SunOS will not. The software isn’t straddled with having to wait for a license manager to say it’s okay for another user to log in or to use another instance of a particular resource, because there is no license manager. This, in my opinion, is a major problem with Solaris.

Margie: What is the principal use for your Linux machines?

Robert: We have a Sun SS-10 with quad Ross RTK-625s and 256MB of RAM running SPARC Linux that serves as our main web server, http://www.eskimo.com/.

We have these Sun LXs running SPARC Linux that serve as our client IRC server irc.eskimo.com, our HUB IRC server hub.eskimo.com, and our virtual domain web server www2.eskimo.com, and one that serves as our FTP server ftp.eskimo.com and our adult web server adult.eskimo.com. The IRC machines are equipped with 64MB of RAM, the other LXs are equipped with 96MB.

We have a Sun 4/670MP with dual Ross RTK-625 CPUs, 256MB of RAM, and a second SCSI controller running SPARC Linux that serves as our news server eskinews.eskimo.com. We actually have two more CPUs for this machine, but a bug in SPARC Linux prevents it from working with four CPUs on the 4/670MP platform.

We also have a Pentium-based PC running Linux that is one of our mail servers, mx1.eskimo.com (external/list). Additionally, name servers run on some of these machines.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure 1. Stack of Suns running Linux

Margie: How about your “not Linux” machines?

Robert: Our main interactive host, eskimo.com (where shell accounts and web pages are located), is a Sun 4/670MP with quad Ross RTK-625 CPUs, 384MB of RAM and an FDDI (fiber distribution data interface), so it sits directly on the dual FDDI network backbone. In addition to interactive shell accounts, it also provides all the user file space.

We have a Sun IPX with a Wytek Power-uP 80 MHz CPU and 128MB of RAM that is used for SLIP and PPP emulation programs (tia and slirp), tia1.eskimo.com; a Sun IPX with 64MB of RAM running as a mail server (external/list), mx2.eskimo.com; a Sun 4/330 with 96MB of RAM which runs IRC bots, chat.eskimo.com; a Sun 4/260 with 108MB of RAM that runs a Moo, name server and empire game, isumataq.eskimo.com; a Sun LX with 96MB of RAM and FDDI that is the mail server hosting the spool directory, pop server and internal SMTP server (the one customers connect to internally as opposed to one that receives external mail); and an IPX with 64MB of RAM that is used as a work station.

Margie: Will you be changing these machines over too? If not, why?

Robert: Yes and No… Eskimo, Tia1, Isumataq and Chat will remain SunOS until such time as Linux is more predictable from a security standpoint, since they have interactive users logging into them.

Mail and Eskimo will remain SunOS until FDDI support for the FDDI cards we use is part of SPARC Linux, or until we find an affordable solution to interface 100-base-T which is supported by SPARC Linux to our dual FDDI backbone.

The mx2 mail server may be converted to SPARC Linux in the not too distant future. Earlier versions had serious problems with NIS, but those have been fixed in glibc, paving the way for the switch.

Earlier versions of Linux also had problems with Sun4c architecture, so the one IPX we are using as a workstation still runs SunOS. We haven’t had time to experiment with recent SPARC kernels to see if that issue is adequately resolved.

Margie: What do you feel are the main advantages for an ISP to use Linux?

Robert: The main advantage I suspect is driving most ISPs is cost. It’s hard to beat free, not counting the cost of media and support offered by various vendors.

We also found some technical advantages. SunOS libraries support only 256 file descriptors per process. We needed more than this for our web servers and IRC servers, so going to a different OS wasn’t an option for these machines. Mail servers run much more efficiently with more file descriptors, because you can use a larger open connection cache, and less thrashing (closing and opening of descriptors) is necessary for operations such as list processing.

For News, SunOS is limited to 2GB file partitions. This is completely inadequate for news volumes today. While SunOS and Solaris have something called “Online Disksuite” available, it is at best a kludge to get around a fundamental problem with the OS. Linux’s support for huge stripped partitions made it attractive for the news server.

Last, Sun hardware has not remained cost-competitive with other platforms, and we wanted the freedom to migrate towards other hardware platforms such as Alpha. Linux provided this freedom.

Margie: How about disadvantages? Tell us about any problems you have had.

Robert: NIS and NFS bugs. NIS would fail randomly with the older libs, making it unusable for applications where proper user lookups were essential, such as mail servers that need to deliver mail, or web servers where a user’s directory has to be located. We worked around this on some machines, where the file descriptor issue was important, by putting together a kludge to place a local copy of the password file on the Linux boxes that had broken NIS libraries. This solution is inefficient. glibc fixes this problem. However, on SPARC platforms no compatibility library is provided, so all applications must be recompiled. This process is going to make conversion a somewhat tedious project.

NFS works, as long as the servers are alive. But if the NFS server goes away for some reason (is rebooted, for example), the NFS client machines will not always recover without a reboot. This isn’t a complete showstopper, but it’s very annoying.

While Linux supports a broader spectrum of hardware, it does not support all of the SPARC hardware periphery supported by SunOS, such as the FDDI cards or a 4/670MP configured with four CPUs.

Then there are security issues. SunOS is fairly static at this point, so most of the security problems are well known and fixes are available. Linux is still in a constant state of flux, resulting in new security holes being introduced—it’s a moving target. Between that and the fact that I have more experience with SunOS, I feel more comfortable with SunOS where users are actually able to log in to the box.

Margie: What do you feel is needed to turn Linux into the number one OS choice for ISPs everywhere?

Robert: I’m not sure it isn’t already. Most ISPs seem to use PC platforms, and cost is important. A percentage of them just don’t feel comfortable without a vendor holding their hand, and in this area Linux is at a disadvantage. There are also really strange people who want to see Microsoft on the label and insist on running NT, even though they might need ten times as many machines to do the same amount of work. I do not understand the psychology of that group at all or know what Linux could possibly do to appeal to them without ruining Linux’s functionality.

In terms of general improvements, glibc with its fix for NIS and some security improvements is a big win. If someone would fix NFS so it would properly recover after NFS server unavailability, that would also be a major win. Of course, support for hardware that we already have in use such as the S-bus FDDI cards and quad CPU configurations of the 4/670MP would be a plus for us, but I doubt it would be significant to ISPs in general, since Intel hardware is a more common platform these days.

Margie: I understand you have written software for a menu-driven user interface for ISPs. Have you ported it to Linux? If not, do you plan to?

Robert: The software I’ve written is for Eskimo specifically. It is not something I intended to sell as a software product, but rather intended as a feature of Eskimo. Actually, at this point, it’s pretty antiquated. I wrote it before the Web existed, and in modern times, the multimedia capabilities of the Web really provide an opportunity for a much better interface. So I have no plans to port the old software to Linux, though newer software I am now working on is web-based and native to Linux (and probably not portable to other operating systems because I am developing it for our own use, not for resale).

Margie: Tell us a bit about Eskimo—some history, customer base, etc.—blow your own horn.

Robert: Eskimo North started as a single-user BBS in 1982, and its initial creation was somewhat accidental.

In my junior high and high school years, I was involved in pirate radio (broadcasting without an FCC license). I had a number of friends who were also involved and ran their own pirate radio stations. Several of them were busted by the FCC, and one of them was fined $750. I narrowly escaped fines after my own station caused some interference in the 80-meter ham band and drew the attention of the FCC. They sent me a cease and desist order, though it was specific to the interference caused to 80 meters and said absolutely nothing about the illegal broadcast in the AM broadcast band. I had my first-class radio telephone license by this time and didn’t want to lose it, so that order ended my direct involvement in pirate radio. However, I did experiment with various legal alternatives such as carrier current and getting the absolute maximum signal possible under the limitations of part 15 rules and regulations for unlicensed transmitters.

One of my friends started a newsletter dealing with pirate radio after he was fined, and since I couldn’t be directly involved safely anymore, I became interested in this. The way they were putting it together was to type it up on an old Royal typewriter, cut and paste it and make photocopies at a 7-11. I thought a computer and printer might be a more efficient method and purchased both, in part for that purpose but also because I was interested in computers.

I hooked up a modem but there was no built-in support for the serial port in the machine (Radio Shack model III); so I wrote what was initially a primitive host program. At first, no login was provided and the number wasn’t advertised. People I wanted to allow access to were given the number, and they could call with a modem, invoke a word processor and do what they needed to do.

Even in 1982, people were running war dialers that found the number and they started messing with the files, so I put up a primitive BBS front-end. Its primary function was to keep people out of files they didn’t have permission to. I developed the host program.

At that time, Glenn Gorman was running Minibin, an early “room-based” BBS, written in BASIC. Glenn wanted to turn Minibin into a commercial product, but it was written to use a host program specific to the Microperipheral bus decoding modems. At the time, a serial interface was not standard, and so Microperipherals Corporation designed a modem that connected directly to the bus, negating the need for a serial card, for around $300—this made it a popular choice. But, Glenn couldn’t sell Minibin using their drivers because they were proprietary, and they designed their modem so that the driver would work only with their modem. So he approached me with the idea of using my host software with his BBS software. However, my approach was much different than Microperipherals, and getting my host program to work with Glenn’s BBS required fairly extensive modifications to both.

During that time, I ran a Minibin replacing the software I was running. But, Minibin at the time did not have support for private e-mail or file upload/download, both of which were things I had in my software, so I added that functionality. Having two Minibins caused no end of confusion; people didn’t understand why when they called one, their login didn’t exist on the other. They didn’t understand that they were separate systems. A large number of BBSs running the same software was not common then, like it is today. So in an effort to clarify things, he named his BBS Minibin South, and I named mine Minibin North. People were still confused, so when he temporarily changed his to Jamaica South, I thought, hmm, what’s up north? Eskimos are up north, hence Eskimo North.

 

 

 

 

 

 

 

Figure 2. Modems!

During this time, I had also come across some quad density double-sided 80-track drives and had a whole 3MB of disk space. I know that’s nothing today, but back then when I had only 48KB of RAM and programs were typically quite small, 3MB was a lot!

By this time the BBS was well-known, and with the help of some of my users who were true machine-code gurus (I could do okay with the help of an assembler and disassembler), I had Infocom adventures on-line and a bunch of other games. For its day, it was fairly advanced. A book was published by an author in Alaska, and in the book he said, “Eskimo North … a strange system. Must call at least once even if it’s long distance.” With an endorsement like that, the name stuck. By 1985, I could pull the plug at 4AM on the modem, plug it back in, and immediately someone would connect.

Just prior to that, I had obtained a trial account on Compuserve, and I was impressed with all the cool things that could be done in a multi-user environment, but at $15/hour for 300 baud and $24/hour for 1200 baud, I could not afford it and I knew that was true for many others as well. Some other friends I had met through the BBS ran a network of four BBSs that were run on Apples tied together with super-serial cards that permitted something similar to MUDs, a multi-user D&D kind of environment, but more gruesome and more creative than any MUD I’ve seen since. The hardware was always breaking down and was generally difficult to maintain or scale.

I decided to go multi-user with Eskimo and started looking for a workable platform. Networked Apples didn’t look like the answer. MPM looked capable, but I felt that the address space limitations and hardware dependencies would limit its future lifespan. Thus, I decided on UNIX; the only affordable UNIX system I could get my hands on was a Tandy 16B with an ugly, primitive version of Xenix. That was our entry into the UNIX world, initially with four phone lines.

We took that machine as far as we could, basically upgrading to a Tandy 6000 with 4MB of RAM, two 70MB disks and 11 lines.

In 1991, I bought a Sun 3/180, an ancient MC68020-based Sun that absolutely ran circles around the Tandy, and we upgraded it to a 3/280, then a 4/280, then we took news off the machine and put it on a separate 4/330, and we’ve been growing and adding new hardware and functions ever since. When the Internet became available, around 1995, we added Internet connectivity, initially with a 14.4K PPP link, then 28.8K, then a 56K frame relay, then a T1 frame relay, then a dedicated T1 to Sprint, now with dual T1s to Sprint. We also utilize a port wholesaler with T3 backbone for 56K dial-up access.

Margie: What do you feel the future holds for eskimo.com?

Robert: Well, there are two aspects to the Internet as I see it: access, essentially the roads that get you where you want to go; and hosting in all its forms, essentially the land, the buildings, the space where things are kept and where people meet and interact.

I will continue to provide access as long as there is a demand for it and we can address that demand in a cost-effective and efficient manner.

However, I am personally a lot more interested in the hosting side of things: what can be done with the Web and helping people create their own web space and make it available to the masses.

I personally do not share the vision of the Web as being a glorified infinite-channel cable company. I don’t share the vision that so many have of making the Web a place where a few people control all the content and spoon-feed it to the masses. Rather, my personal interest is in getting the masses involved in creating content and sharing it and interacting with each other.

It’s my view that for every problem facing mankind, there is probably someone somewhere who has an answer. The Internet has the potential for allowing those ideas to be heard, expressed and implemented. Additionally, while some fear the sharing of cultures will lead to a mono-culture, or essentially no culture, I believe quite the opposite is true. I think people will hang on to their own cultures, languages and traditions, and feel that the sharing that results on the web will lead towards more tolerance and understanding and an enrichment of all cultures. I want Eskimo to be a part of that process. I’ve tried to encourage people by providing good tools for web development and making disk space available cheap. We also have no data export fees, so users are not punished for creating a popular web site.

To this end, I’ve tried very hard to involve our customers in what we do. We have some local newsgroups, the most important of them being “lobby” which serves as a forum for our users to discuss things relevant to our operation. I share plans and ideas with our customers and solicit ideas from them.

Our customers have truly driven us to where we are today and while I’d like to say to you I have solid plans to make Eskimo this and that in five years, the truth is I intend to allow them to continue to determine our direction.

Margie: Anything else you’d like to tell us about?

Robert: While we’ve had customers from all over the world for some time utilizing host features here, until recently we’ve had dial access available only in Western Washington. We now have 56KB available in many metropolitan areas in the U.S. including shell access, web hosting, etc. I’m not sure how this is going to affect Eskimo’s future, but I am going to try very hard to make it a place that people will think of as a home in cyberspace. Phone numbers for reaching us are 206-361-1161 and 800-246-6874.

Margie: Thank you very much.