Linux as an Internet Kiosk
Our network is a mishmash of random hardware and hand-built software. Coming into Café Liberty are two 384Kbps fractional T1 lines. One runs to our ISP and provides Internet service using the Cisco HDLC protocol. The other is a frame-relay line that serves the NetPods. The two T1s are attached to our router (a 486DX/40 running Linux), which also has two Ethernet cards. One Ethernet is for the café (including network jacks for public use), and the other is for NetPod machines.
You don't often hear of a single Linux box being used as a router for multiple Ethernets and T1 lines with differing protocols, let alone a wimpy 486DX/40. But, thanks to SDL Communications' RISCom/N2 cards, it is possible. One RISCom/N2 with a T1 CSU/DSU attached to its v.35 port runs the frame-relay connection, and the other RISCom/N2csu (with built-in CSU/DSU) runs the Cisco HDLC Internet connection.
Getting the cards up and running is mostly straightforward, though there are many small details, like electrical characteristics of the T1 lines, that we sometimes had to just guess at and hope it worked. After the cards were up, routing was easy—just compile IP forwarding into the kernel, set up some subnets and all falls into place.
The NetPod Ethernet has only a couple of machines on it, the most important of which is the NetPod server. The server is a Pentium 100 (running Linux) with 32MB of RAM that deals with NetPod mail (using ZMailer), the Usenet feed (inn), NFS serving of users' home directories, and the NetPod database. The database, which keeps track of user information, was custom-written and communicates with the NetPods over encrypted channels for security.
The server has IP firewalling turned on in full force. While anybody can connect to the SMTP, POP and IMAP daemons, everything else (most specifically NFS) is tightly controlled.
Each NetPod has a 56Kbps frame-relay connection. As far as we know, we are the only Internet terminal company in the world to have chosen frame-relay; the vast majority use standard phone lines and a couple use ISDN. Each frame-relay line is assigned a different PVC (Permanent Virtual Circuit) number. Their data is consolidated and appears on the frame-relay T1 at café Liberty.
Though frame-relay may seem like massive overkill for an Internet terminal, it has enormous benefits.
Frame-relay is fast. The latency on frame-relay lines is a lot less than a PPP connection over a modem. This translates directly into faster TCP connection times for Netscape. We are guaranteed 56Kbps of bandwidth, while the average 33.6Kbps or 56Kbps modem is unlikely to ever get its theoretical maximum bandwidth.
Frame-relay is cheap. Our lines cost somewhere around $150 a month. This may seem like a quite a premium to pay for the comparatively mediocre speed benefits mentioned above, but remember that Massachusetts is in NYNEX (phone company for northeast U.S.) territory. [NYNEX, which covered the east coast of the U.S. from Maine to New York, and Bell Atlantic, which covered from new Jersey south to Virginia, have just merged. The combined company is Bell Atlantic—Ed.] We have found that NYNEX would charge us thousands of dollars per month for a 64Kbps ISDN connection up 24 hours a day. The situation with standard analog dial-ups isn't much better; there is simply no way to avoid a ludicrous per-minute charge on business phone lines of any type.
Thus, frame-relay was the obvious choice. Yet the startup costs for frame-relay are crippling. One SDL RISCom/N2dds (with built-in 56Kbps CSU/DSU) and frame-relay software costs $750. The installation costs for the line are several hundred more. Despite these numbers, we feel that there are very real benefits to the frame-relay technology. Being able to remotely access the NetPods at any time of day or night is immensely useful.
In an attempt to reduce the cost of frame-relay, we have embarked on a side project to add frame-relay support to Linux. We had often wondered why Linux had no frame-relay protocol driver. It seems that the main reasons are complexity and cost. You can tell that parts of frame-relay were designed by committee; every person involved managed to get his or her pet feature fit in somewhere, yet they don't all fit quite right. All the relevant standards documents have to be purchased from the ITU (International Telecommunications Union) and then deciphered.
We figure we can drop the cost of frame-relay about $500 if we use a BAT Electronics CSU/DSU (the most inexpensive we could find) and then tack on a minimalist synchronous to asynchronous converter of our own design. This converter takes the CSU/DSU's synchronous bitstream, repackages it in RS-232 bytes at 115,200 baud and sends it to the NetPod, which then interprets it with the frame-relay driver. As of early June, we have established successful TCP connections through this system, and we are now concentrating on improving the stability and performance of the drivers. Once they are ready for release, we will donate the drivers to the standard kernel distribution so that any device that generates an HDLC-framed bitstream (like Z8530-based synchronous cards) can be used for frame-relay.
We are a 100% Linux shop. Except for some graphics work that we do on Macintoshes to keep professional printers happy, every last machine is a PC running Linux. Linux has given us so much that, in the true spirit of Linux, we feel we have to give something back to the community, which we hope to do with our frame-relay package.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide