"Linux Gazette...making Linux just a little more fun!"

Linux Installation Primer, Part Three

By Ron Jenkins


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.


The author welcomes corrections and suggestions. He can be reached by electronic mail at rjenkins@unicom.net, or at his personal homepage: http://home.unicom.net/~rjenkins/


Part Three: Network and Dialup Networking configuration

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.


Networking fundamentals.

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, 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.)


Preparing for the networking configuration.

  1. Some information for you if you do not already have an ISP.
  2. Some information for you if you already do have an ISP.
  3. General information required in either scenario.


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:



Some information for you if you already have an ISP.

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.


General Information required in either scenario.

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


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.

Configuring the loopback adapter.

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 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.


Configuring basic networking.

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:




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.


Connecting to your Internet Service Provider.

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:




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



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!


Configuring the Domain Name Service to function on a dialup connection.

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.



Configuring Sendmail to function on a dialup connection.

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)



Next look for these:

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



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



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.)



Testing and troubleshooting your basic and dialup configuration.

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.


Some quick and dirty "cheats" if all else fails.

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.


Stupid Network Tricks.


Coming next month: Connecting your Linux machine to a network and making it an Internet Gateway for your other machines!


Resources for further information.

The Linux Documentation Project:


General Networking:

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

The Linux User's Guide




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

Slackware 3.5:


RedHat 5.1:



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


Previous ``Linux Installation Primer'' Columns

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

Copyright © 1998, Ron Jenkins
Published in Issue 34 of Linux Gazette, November 1998