Connecting Your Linux Box to the Internet
At this point, if you have followed my advice, you've managed a UUCP news and mail feed. You've worked with dial-up IP. Maybe you've even tried running a gopher, ftp, or HTTP server. And, you have learned a lot about Unix security. If you haven't, do it now!
A dedicated connection means your machine is connected to the Internet 24 hours a day. This speeds up services like news and mail. Mail between two Internet-connected machines happens literally in seconds. The frequency of Usenet news updates is controlled by each site. Hourly—or even more frequent—news updates are commonplace. You also get some services that are only available to Internet connected machines such as telnet, ftp, gopher, and World Wide Web.
In order to put your machine on the Internet, you will need a dedicated line between you and your service provider. A dedicated line is a telephone line that is open 24 hours a day. What do I mean by open 24 hours a day? Say you call a friend and talk for a few minutes. Then, you walk away from the phone for a while. When you have something else to tell your friend, you pick up the phone and tell him. You don't have to dial his number again because you've never hung up. This service is billed at a fixed, monthly rate; there is no charge for usage. The phone company connects the dedicated line to the destination phone number. Only the phone company may change the destination.
You will have to decide how fast a connection you will need. The minimum speed is 56 kbps, which is perfect for a small business. If you plan on transferring audio in real-time, you will need a 1.54 Mbps line, commonly known as a T1 line. If you plan to transfer video in real-time, you'll need a T3 line which transfers data at the rate of 45 Mbps. Watch out for bottlenecks—buying a T1 line in the hopes of talking with a remote site across the country at T1 speeds is pointless if any of the other lines the data will pass through are running at 56 kbps.
Dedicated lines come in several different flavours. Analog lines can handle speeds up to 28.8 kbps. This is the same grade as your typical home phone line. You probably don't want one of these. Digital lines handle speeds of 56 kbps right up to T3 (45 Mbps) speeds. The cost of a digital line depends on the distance between you and your service provider. An alternative to digital dedicated lines is frame relay. Frame relay is the new technology on the block. Frame relay charges are based on speed, not distance; this may offer significant savings over a digital line. Not all service providers support frame relay. Check with your service provider. For the purposes of this article, I will assume you are going to go with a digital line at 56 kbps. This is the most common Internet connection.
With a dedicated connection, your Linux box is available 24 hours a day to access the Internet. But beware, the reverse is also true. The Internet can access your Linux box 24 hours a day. Keep your machine secure or you could suffer a lot of damage from system crackers. In order to prevent this, consider reading Cheswick and Bellovin's Firewalls and Internet Security, reviewed in issue 6 of Linux Journal.
Before I describe a 56 kbps connection, let's review a connection with which you are probably more familiar: a regular 14.4 kbps modem connection. (See Figure 1 above.) A 14.4 kbps connection will require a serial port in each machine, a modem at each machine and, of course, a telephone line. The two modems communicate at 14.4 kbps using the v.32bis protocol. The serial connection between each modem and the Linux box can be set at 19.2, 38.4, or 57.8 kbps; data compression is the reason the serial connection runs faster than the modem. The modem connection is 14.4 kbps compressed with the v.42bis compression protocol; the serial connection is uncompressed. In order for the serial line to keep up with the modem connection, it must pass more bits per second than the modem. Now that you know where all the protocols fit into the picture in a 14.4 kbps connection, let's tackle a 56 kbps connection.
Take a look at Figure 2 (opposite). A 56 kbps connection may be too fast for your serial port, so Ethernet offers an alternative. Ethernet signals cannot be transferred over the telephone lines, so you must use a protocol specifically designed for telephone lines, v.35. What you end up with is Ethernet coming out of the Linux box, being converted to v.35 signals, and being transferred over the telephone lines to your Internet service provider. You need to install an Ethernet card in your Linux box and configure the kernel to support TCP/IP—see the NET-2-HOWTO document for the details. To convert Ethernet signals to v.35 signals you will need a router. Finally, to send the v.35 signals over the phone lines, you will need a 56 kbps CSU/DSU (also known as a digital modem).
The router with CSU/DSU is the most common configuration for dedicated connections to the Internet. Vendors are now selling hardware which combines the router and CSU/DSU into one box. The single box is cheaper, but not as flexible in case of future growth. For example, if you want to change from a 56 kbps to a 128 kbps line, you can use the same router with a 128 bkps CSU/DSU. If you go with the single box, you'll have to replace the entire unit. Take into account your plans for the future and pick the option that suits them.
It will soon also be possible to buy a v.35 CSU/DSU card that plugs directly into your Linux box. That is, it is possible to buy the card now, but the driver is still being developed as this is written. When the driver is available, this option will cost less than an Ethernet card, router, and external CSU/DSU, be a little less flexible, require that the Linux box it is attached to act as a router, and be ideal for many situations where the Linux box is being used as a firewall. On the other hand, it is a poor solution for sites with more than a few dial-in lines.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- Dynamic DNS—an Object Lesson in Problem Solving
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- Tech Tip: Really Simple HTTP Server with Python
26 min 36 sec ago
- Keeping track of IP address
2 hours 17 min ago
- Roll your own dynamic dns
7 hours 30 min ago
- Please correct the URL for Salt Stack's web site
10 hours 42 min ago
- Android is Linux -- why no better inter-operation
12 hours 57 min ago
- Connecting Android device to desktop Linux via USB
13 hours 26 min ago
- Find new cell phone and tablet pc
14 hours 24 min ago
15 hours 53 min ago
- Automatically updating Guest Additions
17 hours 1 min ago
- I like your topic on android
17 hours 48 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?