Linux Installation Primer, Part Three

Copyright ® 1998 by Ron Jenkins. This work is provided on an "as is" basis. The author provides no warranty whatsoever, either express or implied, regarding the work, including warranties with respect to its merchantability or fitness for any particular purpose.

Well, here we are ready to start part three of the series, setting up basic networking functions, and connecting your Linux machine to the outside world. As with each installment of this series, there will be some operations required by each distribution that may or may not be different in another. I will diverge from the generalized information when necessary, as always.

In this installment, I will cover the following topics:

1. Networking fundamentals.
2. Preparing for the networking configuration.
3. Configuring the loopback adapter.
4. Configuring basic networking.
5. Connecting to your Internet Service Provider.
6. Configuring the Domain Name Service to function on a dialup connection.
7. Configuring Sendmail to function on a dialup connection.
8. Testing and troubleshooting your basic and dialup configuration.
9. Some quick and dirty "cheats" if all else fails.
10. Stupid Network Tricks.
11. Resources for further information.
12. About the Author.

I won't bore you with all the nasty details of the history of the Internet, how it came to be, etc. However, some basic understanding of how networking in general, and Transmission Control Protocol/Internet Protocol (TCP/IP) is necessary to maximize your effective use of a network, and by extension, the Internet.

At its most fundamental level, all networks require at least three things to function:

1. An interface to pass the data packets to and from the computer.
2. A physical connection of some sort to pass the data from one place to another.
3. And finally a mutually agreed upon format to convey that data, using a common method, or language, usually called a protocol.

Just as a person who speaks only French will have a great deal of difficulty communicating with a person who speaks only English, (no matter how loud or slowly each one of you talks,) so too will two dissimilar networks be unable to communicate without a common language or protocol.

Grossly oversimplified, in the context of the Internet, this language is TCP/IP. (Yes, I know, it really happens through a series of functions based loosely on the OSI model, but for the purposes of this document, let us agree that TCP/IP is the language of choice.)

TCP/IP is based on numerical addresses, called IP addresses. I'm sure you have all seen something like xxx.xxx.xxx.xxx, where x is equivalent to some numerical value. A practical example would be 204.252.102.2, one the Domain Name Servers or DNS (more on this later) at an ISP here in town.

"But wait a minute, I don't type stuff like that, I type the ubiquitous dub dub dub dot foobar dot com thingy, (www.foorbar.com) and it works just dandy. What's up with this number stuff?"

Ah, grasshopper, this is where DNS comes in to play.

Through an interconnected system of servers, the DNS system functions much like an upside down pyramid.

Starting with your local DNS, which knows only about the machines on your local network, and how to talk to a machine higher up the totem pole if it gets confused, all the way up to the widest part of the pyramid, which contains the information for all the various master or "root" domains such as .com, .net, .edu, or .org. A huge and constantly changing database of all machine connect to the Internet is organized, collated, and sorted 24 hours a day.

Again, grossly oversimplified, residing on the DNS servers, in the form of something called "Zone files", each machines local to the relevant local network has two entries - an IP address and a hostname. In this article your machine's hostname will be tester, and your domain will be foober.net (this will need to be replaced with information gathered from your Internet Service Provider, as explained later.) This is called address resolution, and explains how the dub dub dub deal works.

Whenever a request goes out, these dandy little machines translate the hostname you have requested into an IP address if it is on your local network, or pass it on up the line if it is not. Pretty neat huh?

For the purposes of this document, the three components of your networking setup will consist of the following:

1. The network interface in your case will be a thing known as the loopback adapter.
2. The physical connection will be your phone line.
3. The protocol you will use will be TCP/IP in one of two configurations, depending on your Internet Service Provider (ISP.)

Some information for you if you do not already have an ISP.

As long as we are at this, and with the proliferation of every Tom, Dick, and Harry starting "The Ultimate Internet Service Provider," I provide the following things to consider when choosing an ISP:

I will present these considerations in question form, with explanations where necessary. These things are VERY important to know if you want to maximize your effectiveness on the Internet.

Initially, you will probably be connected to a salesman when you contact a prospective ISP. Ask to talk to a tech, or have one conference in to the call. Otherwise, the salesman may promise you anything to get you connected. The tech will be able to answer the following questions effectively. If the salesman or the tech refuse to do any of the above, or hem and haw around about any of these questions, thank them for their time and move on. This is not an ISP you want. So hang on to your modem, here we go:

• What type of access do you offer? Unlimited access or metered access (AKA *plans). Unlimited is good; it is one flat rate for as much time as you want. Metered, *.plans are bad. These plans usually come with so many *free* hours per month, then an additional charge per minute or hour you exceed this base. This stinks, and makes the Information Superhighway a toll road.
• Do you offer Unix shell access to my account? This tells you two things - is the answer is yes, you are probably connecting to a Unix machine. This is good. If not, you are probably on an NT machine, or your ISP chooses not to offer shell access. This is bad. If you have shell and telnet access to your account, you can do many neat things with it see "stupid network tricks" farther along.
• What type and speed is your backbone connection or connections to the Internet? Many smaller ISP's have only a T-1 (1.534 MBPS of user bandwidth,) or even worse, something called a Fractional T-1 which may range anywhere between 64 KBPS up to the full 1.5 in 64 KBPS increments. They then, through the use of term servers let many end-users like you connect to a single network feed and share it. This is bad. What is better is a connection called a T-3. This runs at 45 MBPS and should be considered the minimum connection that you are willing to accept. If your prospective ISP does not have at least a T-3, bail and find one who does.
• What is your user to modem ratio? This is a fancy way of saying how many physical connection devices do you have, compared to how many users your network supports? Nowadays, any more than 4:1 is unacceptable. One modem for every four users.
• Considering your backbone connection, how many to you have, and how many providers do they go through? At a minimum, any good ISP should have a T-3, connected to one backbone provider and multiple (at least 2) T-1's each connected to a separate backbone provider. Consider this - if you only have one ISP and they go down, you're off the Internet until they get it fixed. If you have two accounts with two different providers, and one goes down, you switch to the other. Same rule holds true for them.
• What kind of machines are they using, and what operating system do they run? If you hear the word NT in their response, run away screaming. Specifically ask if they are using Unix hosts and whether or not they offer telnet, shell, and ftp access to your personal account. If the answer is no, look elsewhere.
• What access authentication protocol do you use? Acceptable protocols are clear-text, PAP, and CHAP. Unacceptable protocols are RADIUS, KERBEROS (can be done but you will need help), GUARDIAN, or MS-CHAP. These protocols cause a lot of extra trouble and configuration complexity, which you don't really need, unless you work for the NSA or something. Security is a relative term, and for the average end user, super-whiz bang-triple encryption one off pad algorithms shouldn't be necessary.
• Ask specifically how much web space and personal storage you are allocated for your personal account. It should be at least 10 MB. More is better.
• Finally, ask specifically if they support Unix clients in general, and Linux clients in particular. You can live with it if they say Lin Who, but if they don't support Unix clients, they are probably an NT shop. Run-Away.

You should be okay, at least at the basic functionality level, if you have already been connected successfully to your present ISP. However, if you have been connecting using only Windows machines, you may or may not have problems with connecting the Linux box. See the NOTE, and SPECIAL NOTE below regarding NT specific issues.

Before you do anything, you will need to acquire the following information from your ISP:

• The number you dial to access the service.
• Your username and password on your ISP account.
• What type of authentication scheme your ISP uses. Some possible options are Clear Text, Password Authentication Protocol (PAP,) and Challenge Handshake Authentication Protocol (CHAP.)
• Whether your ISP uses static or dynamic address allocation. Static address allocation means you have the same IP address every time (this is better for you,) while Dynamic Address Allocation assigns you a different IP address every time from a pool of IP's set aside just for this purpose (this is better for them.)
• What the IP address of the default gateway is on your ISP's network.
• What the IP address of their primary and secondary DNS servers are.
• The technical support phone number for your ISP, and the hours it is active in case you run into problems.

NOTE: Each ISP has it's own idiosyncrasies and procedures for accessing their service. What I will be accomplishing in this document is simply to get you physically logged in and connected to the ISP. There may or may not be additional steps required by your particular service to attain full functionality.

SPECIAL NOTE: Many ISP's unwisely, in my opinion, relay on NT architecture for remote access. This adds additional steps to your configuration, many proprietary to Microsoft and otherwise unnecessary. If your ISP is one of these shops, try to get a tech on the line while you are doing the configuration. If they are unwilling or unable to support Unix and Linux machines, get one who will. The ease of the configuration will be worth it, as well as having "shell" access to your ISP's network with which you can do all sorts of neat things, covered in the "stupid network tricks" section later.

Even so, look at my "cheat" section for some ideas and workarounds if your ISP is unwilling or unable to support your Linux box.

The loopback adapter is necessary for the networking connection to function. Oversimplified, each network connection, or "interface" in UNIX parlance must be "bound" to a physical, as well as a logical adapter. The loopback adapter performs this function in the absence of an actual interface to the network, such as a Network Interface Card, or NIC.

We will use the loopback adapter both for testing and to "bind" the network connection to your ISP to, thus making your modem the network interface.

Slackware 3.5:

This should be done for you during the installation. If not, from the command line, type netcfg <return>, and when prompted choose 127.0.0.1 for your network interface.

RedHat 5.1:

Again, this should have been taken care during the installation procedure. If not, start X and choose the options Control Panel/Network Configuration, then at the bottom of the dialog box, choose Add and follow the prompts.

Slackware 3.5:

Basic network configuration is accomplished through either directly editing the configuration files them selves, through the use of the netconfig utility, or some combination of both of these methods.

RedHat 5.1:

Most of your network configuration can be accomplished through the aforementioned Control Panel/Network Configuration method, or using the linuxconf utility available on newer RedHat systems. You will find this utility under Start/Programs/Administration/Linuxconf.

Basically, you just need to cd to /etc/hosts, and choose a hostname and domain for your machine. I think its default is darkstar or something in Slackware, and localhost in RedHat. The important point to remember here is not to choose a hostname that is already on the Internet, and use your ISP's domain name for yours. So, if your ISP is psi.net:

darkstar.psi.net

At a minimum, if you are not connected to a LAN, and will only be dialing up to your ISP, the only entry required in your etc hosts file is your loopback adapter.

Slackware 3.5:

If you have followed my instructions previously, and chose the proper ISP, get him on the line and have him walk you through the configuration process, as it will be unique to each ISP.

If not, read on for some general pointers.

The symlink to /dev/modem should have already been created during installation, if not create it.

To begin with, you will have to connect manually using minicom to see just what your ISP requires.

minicom <return>

After it get done griping about not running as root, enter the configuration menu by depressing the Alt+z keys, then choose the proper configuration options. When finished, exit and save your changes as the default when prompted.

You should now see an O.K. prompt in the terminal window. If not, go back and check your configuration.

Now let's dial your ISP:

ATDTyourispaccessnumber

For instance:

ATDT 3659968 <return>

If all goes well, you should be presented with a login prompt. Enter your ISP assigned username and press the return key. Next you should be prompted for your password. Enter your ISP assigned password.

At this point, if all has gone well, you should start to see a bunch of garbage scroll across your screen. This is a good thing. This is the ppp daemon on the other end trying to connect to your machine.

To talk to it, we will first have to close minicom WITHOUT resetting the modem. Next we will have to start our own ppp daemon. I happen to stink at typing, so I made a little script to initiate the pppd connection:

vi unicom.connect <return>

pppd /dev/modem (or as I prefer /dev/cua1 for COM2,) crtscts defaultroute

now let's exit and save the file:

press the escape Esc key to enter the command mode, the depress Shift + : then wq <return> to write and quit the file.

Now, let's make the file executable (like a .EXE file in DOS,) by issuing the following command:

chmod +x filename (unicom.connect in this example.)

Okay! Now we are ready to go. At some point while we were doing all this minicom should have crapped out. If not depress Alt + Z and this time DO reset the modem.

Here we go:

1. Start minicom.
2. Dial your ISP.
3. Enter your login when prompted.
4. Enter your password when prompted.
5. As soon as the garbage starts, depress Alt+z, then q to quit without resetting the modem.
6. As soon as the command prompt comes back, run your connect script. In this example unicom.connect.
7. Type ifconfig and press return. You should now see TWO entries. One for the loopback adapter, and one called ppp0 or something.
8. Jump up and down and do the happy dance. You are connected!

RedHat 5.1:

If you have followed my instructions previously, and chose the proper ISP, get him on the line and have him walk you through the configuration process, as it will be unique to each ISP.

If not, read on for some general pointers:

First, is you haven't done it already, make sure you know which interface you modem is connected to. You will need to know this information. If it has not already been done, use the modemtool from the Control Panel to create a symbolic link from the serial port your modem is connected to /dev/modem. Alternately, you can enter this port directly into the dialog box when prompted as described below.

Generally speaking, the symlink to /dev/modem seems to be the way to go, so I won't go into why I don't use it. However, in any case you should know which COM port it resides on just in case you run into trouble, so:

COM 1: /dev/cua0; or /dev/ttsy0

COM2: /dev/cua1; or /dev/ttsy1

Etc.

RedHat users, provided the do not require any off the wall configuration options, have it pretty easy here. Simply choose Control Panel/Network Configuration/Interfaces, then choose Add. Choose PPP when prompted for the Interface type. Next, enter your ISP access number, login name and password.

Should your modem require any special customization, choose Customize from the dialog box. When you are finished, choose save and quit, then activate the interface either by highlighting the ppp0 entry in the Network Configurator, or on newer systems, you may use the Usernet tool located in Start/Programs/Networking. If all goes well, your modem should squeal like a pig for a moment, login, and then you should be off and running!

This is fairly simple. We simply need to tell the Linux box to let the ISP DNS resolve hostnames for us. First, if you are currently running named (the daemon,) or BIND (the collection of programs that make named work,) cd to /etc/hosts.conf and make sure there is a line similar to the following contained there:

order hosts, bind

Now, let's tell the resolver (a magic little fellow constantly zipping around the guts of the machine looking things up,) how to find the outside world and talk to it.

From a term window or command prompt, cd to /etc/resolv.conf, then add your ISP's nameservers here using the following syntax:

nameserver <space> IP Address of the nameserver

For instance:

nameserver 196.356.2.4

nameserver 196.356.2.5

NOTE: the DNS machines will be searched in the order they are entered into the file, so put your ISP's primary first, secondary second.

During the configuration process your respective setup program may or may not have added additional information to this file. If so, comment them out by placing a pound (#) sign in from the line that contains the information.

To prevent a flood of e-mail on this, yes, I am aware there are many directives you can use here, and many DNS things such as a caching-only server you can employ to enhance the performance of the resolver, and these things will be covered in a later installment, so be patient.

Sendmail, like DNS, is an art unto itself. However, here are some general suggestions:

Cd to /etc/

Edit sendmail.cf, and look for lines like the following:

# "Smart" relay host (may be null)

DSyour.isp.mailmachine

Next look for these:

#who do I send unqualified names to (null means deliver locally)

DRyour.isp.mailmachine

#who gets all local email traffic ($R has precedence for unqualified names)

DHyour.isp.mailmachine

Finally, you may or may not want to use the following directive - read the docs.

#who do I masquerade as (I forget the rest of it, just look for the masquerade keyword.)

DMyour.isp.domain.name

On the connectivity side, usually it's a pass/fail operation. Either you get connected or you don't. Check /var/log/messages for some possible clues as to what went wrong.

If you connect, but can't do anything, it could be a thousand things, but here are some general guidelines to diagnose the problem:

1. Can you ping the out side world by IP address? If yes, proceed. If no, something is wrong with your connection or the way it was set up. ifconfig and netstat -r can be of help here.
2. Can you ping the outside world by hostname? If yes proceed, if no, you have a name resolution problem. Check your resolv.conf and make sure that your ISP DNS machines are the only things in there. Check your hosts file. Put your local info here. Make sure your local host (loopback) has an entry.
3. Do you get connected, but sometimes lose your connection while reading stuff, or otherwise appear to have no activity on your line? Your ISP is probably running an automatic termination program AKA a serial killer, to prevent a line being locked up if a user's modem does not exit cleanly. While some ISP's frown upon it, the way around this is to run a "ping-forever" or keepalive shell program to defeat the timeout script.

If you have trouble getting Sendmail to retrieve your incoming mail and news from the outside world, simply use Netscape to access your incoming mail on your ISP. Provided you enter the correct information into the dialog boxes, Netscape has it's own pop3 interface, and doesn't need anything else.

The Linux Documentation Project:

http://sunsite.unc.edu/LDP/

General Networking:

Network Administrator's Guide, System Administrator's Guide, and the NET-3 HOW-TO

The Linux User's Guide

DNS HOW-TO

ISP Hookup HOW-TO

Additionally, OS specific information can be found at the following websites:

Slackware 3.5:

http://www.cdrom.com/

RedHat 5.1:

Finally, check the comp.os.linux* newsgroups, or drop me an e-mail.

Linux Installation Primer #1, September 1998
Linux Installation Primer #2, October 1998