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


Linux Installation Primer, Part Seven Version 1999.02.14

By


Copyright Ó 1998, 1999 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 , or at his personal homepage: http://www.qni.com/~rjenkins/.

Corrections, as well as updated versions of all of the author's works may be found at the URL listed above.

NOTE: As you can see, I am moving to a new ISP. Please bear with me as I get everything in working order. The e-mail address is functional; the web site is semi operational, I will add to it as I get the time.

SPECIAL NOTE: Due to the quantity of correspondence I receive, if you are submitting a question or request for problem resolution, please see my homepage listed above for suggestions on information to provide.

Operating Systems Covered/Supported:
Slackware version 3.6
RedHat version 5.1
Windows NT Server version 4.0
Windows NT Workstation version 4.0

I only test my columns on the operating systems specified. I don?t have access to a MAC, I don?t use Windows 95, and have no plans to use Windows 98. If someone would care to provide equivalent instructions for any of the above operating systems, I will be happy to include them in my documents.

Part Seven: Internet Gateway performance tuning and tips
In a continuation of last month's column, we will look at some ideas, tips and tricks to improve the performance of our Internet Gateway, as well as some advanced configuration options.

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:

Assumptions applicable to this column:
It is assumed you have read my previous installments in this series, if not, I suggest you review them first if you find any of the terms or concepts here confusing.

Also, throughout the article, I shall use the term WAN connection and PPP connection interchangeably.

Overview of Performance tuning and enhancement:
Performance enhancement, like any other project, requires an analysis of the cost of the enhancement versus the amount of improvement.

What we will endeavor to accomplish here is to improve the performance of our gateway, using a variety of techniques, while keeping the additional cost as low as possible.

For any method suggested here, there will be a trade off. Some of the following suggestions may or may not be applicable to your own unique situation.

Some of these techniques will provide a real, measurable, and noticeable improvement, while others will only become apparent through long term analysis, or examination of various statistical reporting methods available to you. The ability to accurately measure the performance of your gateway machine is essential to effective tuning.

As we go along and become familiar with each technique, I will also introduce appropriate methods of measuring these techniques, and therefore accurately measure the amount or percentage of improvement.

Techniques for performance enhancement:
Although some of the ideas and techniques discussed here will be applicable to other types of machines, such as file servers and workstations, the primary focus of this column will be geared toward the specific enhancement of gateway machines.

In the context of this assumption, the following techniques, in descending order of importance will provide the most improvement in the operation and speed of the gateway machine:

  1. WAN connection upgrades.
  2. Hardware upgrades.
  3. Software upgrades.
  4. Caching options.
Finally, I will discuss some general tips and tricks for measuring the performance of your gateway, as well as some ideas for areas of improvement.

WAN connection upgrades:
The single most effective method for increasing the performance of your Internet Gateway is to upgrade the speed of your connection to the Internet.

This can take the form of a dedicated or dialup connection in most cases. Some of the options you may want to consider include:

Measuring the performance of your WAN connection -
There are several programs and utilities that can help you here, one that I use quite a bit is a program called netwatch, which is handy for general monitoring of your network and the speed of your router (your Internet gateway.) This utility is not provided as part of the normal distribution of RedHat, but is included with Slackware 3.6. There is an RPM of an older version available at any of the RedHat mirror sites, in the /powertools/ directory.

For checking the real time condition of your WAN connection, as well as the effectiveness of any compression options you may be using, pppstats is very helpful. This utility should be available on both Slackware and RedHat machines.

Hardware upgrades:
To improve the performance of your local network access, RAM and disk subsystems are king. Provided your motherboard has sufficient cache to handle it, put as much RAM as you can afford in your server and gateway machines.

Another crucial area is the disk subsystem. Although there have been significant advances in ATA technology, such as EIDE, UDMA, and so on, the standard for heavy, continuous use and high performance is still the Small Computer Systems Interface, or SCSI device.

It is important to note that IDE drives are SEQUENTIAL access devices, meaning each request for information must "stand in line" and wait for it's turn. SCSI drives are CONCURRENT access devices, meaning multiple requests can be serviced simultaneously.

While the price differential between IDE devices and comparable SCSI devices was prohibitive in the past, at the preset time, the difference is negligible. Consider Ultra (20MBS) drives a minimum, Ultra Wide (40MBS) drives better.

A SCSI subsystem is comprised of four basic parts

You may notice I do not mention U2W devices here. The support for these devices, as far as I know, is still in the development stage, so I would wait awhile on these devices. Besides, they are waaaaay expensive!

NOTE: Unless you are planning on implementing some of the caching techniques described below, a disk subsystem upgrade will not provide a noticeable performance enhancement.

Simple routing and masquerading are done in the kernel, on the fly, causing minimal interaction with the disk.

However, if the machine also doubles as a file server, web server, or something other than just an Internet Gateway, then it is worth considering.

Software upgrades:
In the area of software enhancements, here are some options to consider:

PPP Software - You may want to consider upgrading your PPP software if your distribution does not contain PPP version 2.3.0 or greater.  This version contains support for the demand dialing option, thus eliminating the need for diald or any such extra stuff.

It also supports a more robust scripting method based on ppp-xx scripts, usually prepared at installation time and requiring only some editing to make them functional. These files are usually located in /etc/ppp and/or /usr/sbin.

Data Compression - A comprehensive explanation of Data compression theory is beyond the scope of this article, so briefly, here is an overview of compression methods and how they can improve the apparent speed with which traffic flows through your WAN interface.

Van Jacobson (VJ) Compression - This is enabled by default in most Linux distributions of the PPP daemon.

BSD Compression (bsdcomp) - Another compression scheme, usually disabled by default. You will be required to load a module, or re-compile the kernel to include support for this.

Deflate Compression - Yet another compression scheme, also disabled by default.

Any one of, and/or combination of these compression schemes may or may not improve the apparent performance of your PPP connection. To enable, disable, or adjust the parameters for any or all of these compression schemes, see the pppd man pages. Experiment with them, using netwatch to measure any speed changes, and pppstats to measure the amount of compression.

BIND - The Berkley Internet Name Daemon (BIND), commonly called named, is the service responsible for hostname to IP address translation on the Internet, most often referred to as Domain Name Service, or DNS**.

While it is impractical to run your own full blown DNS server (unless of course you have your own domain, and a block of assigned IP's,) It can be helpful to run what is known as a "caching only" nameserver.

Whenever you request an object on the Internet, whether it be a web page, ftp site, news server, or whatever, you usually issue the request in the form of a hostname/path_to_object/ format. When your request goes out, it is handed off to the DNS server specified in your resolv.conf file first.

Since the DNS system is hierarchical, like an upside down pyramid, with the point on the bottom being the DNS machine in your resolv.conf file, your DNS machine only knows about machines local to it's own network*, in this case, your ISP's. This information is contained in what are known as "zone" files, which are simply ASCII text files that list information about a "zone" or domain in a standardized format.

If the request cannot be resolved by this machine, it then consults the next higher machine in the pyramid, as so on until ultimately, if necessary, the query reaches the "root.servers" responsible for all the *.com, *.edu, *.net domains and so on.

Finally, at some point, after much communication back and forth across the WAN connection, the hostname you requested will be converted into an IP address, and sent back to your computer.

Clearly, there's a significant amount of communication going on in the background to let us meat based computing devices do the "dub dub dub" deal.

What a caching nameserver does simply put, is to "remember" these name to IP resolutions for a period of time, so the next time a particular object is requested, the nameserver can service the request locally, without having to go outside the local network. This is way cool for two reasons. It makes name resolution appear much faster, and reduces traffic on the WAN.

The downside to this is that each initial, or "new" request will take slightly longer to return to your computer. As I said before, everything is a trade off. Usually, the latency is nominal. This technique is almost always a good idea.

* Well sort of. It is possible for your ISP to be aware of other networks beyond the ones contained in the root.servers file, but this is irrelevant in the scenario we are discussing here.

** Actually, BIND is comprised of a number of programs, each performing a specific function. The most important piece of the puzzle is the resolver.

Apache - The Apache http server contains provisions for enabling some caching options, thus reducing WAN traffic. Check the Apache documentation for more information.

Squid - This is a web proxy/caching software suite that is infinitely configurable, and supports many services. To find out more about Squid, and whether it is right for your particular installation, see the resources section at the end of this document.

Leafnode - This is a replacement for the Network News Transport Protocol (NNTP) server usually used in most UNIX installations. It is small, easy to configure, and takes up a fraction of the disk space of the normal Internet News (INN) software. The trade off is that it does not scale well, and can really tie up your WAN connection when it initially downloads the articles available from the newsgroups you have selected (See the cron section of the General Tips and Tricks for some ways to minimize this congestion.) To find out more about Leafnode, and whether it is right for your particular installation, see the resources section at the end of this document.

Caching options:

Slackware 3.6 - The Slackware distribution will require you to do a little work to enable the nameserver. This is really a good thing, because when you set it up yourself, you will be better equipped with more of an understanding of how the process works, and therefore, how to diagnose and correct problems when they develop.

First, you will need a directory called /var/named. If it is not already there, create it.

Next, you will need a file containing listings of all the root servers, and a file that serves as your local information, or "zone" file. These files should be named root.cache, and 127.0.0, respectively. Examples of these two files may be found in the DNS-HOWTO, or the Cricket book listed in the resources section.

Finally, you will need a named.conf file, which passes the start up options to BIND. For a caching nameserver, it should look something like the following:

// Config file for caching only name server
options {
directory "var/named";
//Uncomment the line below if you are behind a
//firewall, and you can?t get things to work:
// query-source port 53;
};
zone "." {
type hint;
file "root.cache";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "127.0.0";
};
// End Config file example

Those of you who are familiar with the C/C++ programming language will notice the similarity of the syntax of the named.conf file.

Briefly, the first section delineates the working directory, the second section tells the resolver where to look for the root servers file, and the last section is your "zone" file. This file should live in the /etc directory.

Finally, edit your resolv.conf file on the gateway machine to point first to itself, then to your ISP for name resolution:

search home.net
nameserver 127.0.0.1
nameserver <your ISP primary DNS>
nameserver <your ISP secondary DNS>

Then finish up by pointing all your home.net clients to the gateway for resolution:

search home.net
nameserver 192.168.1.1

RedHat 5.x - when you install the RPM, it automagically should install as a caching server. If not, then see above for the required files and proper named.conf examples.

General tips and tricks:

                                    0 4 * * * /usr/sbin/fetch #!/bin/sh #all scripts should start with your preferred shell
rm -f /var/log/wtmp #this removes the old file
touch /var/log/wtmp #this creates the new file
echo "wtmp cleaned" > /var/log/wtmp.log #this just lets me know the script ran

Shell scripts can be created using any of the many text editors available on your Linux system. Let?s say we named this file wtmpclean. To make it executable by the system, simply issue the chmod command:

chmod +x wtmpclean

To call this script from cron, and have it run every hour, your crontab entry would be something like:

0 * * * * /usr/sbin/wtmpclean

References:
Previous Columns:
Parts 4,5, and 6.

Other:
Pppd man pages
Cron man pages
Leafnode man pages
PPP HOW-TO
SERIAL HOW-TO
DNS-HOWTO

Resources for further information:
Web Resources:
http://www.redhat.com/
http://www.slackware.com/
http://metalab.unc.edu/LDP/
http://www.linuxresources.com/
http://metalab.unc.edu/
http://www.isc.org/
http://www.apache.org/
Squid Software:
http://squid.nlanr.net
Leafnode Software:
http://wpxx02.toxi.uni-wuerzburg.de/~krasel/leafnode.html
Netwatch software:
ftp://ftp.slctech.org/pub/

Newsgroups:
alt.unix.wizards
comp.security.unix
comp.unix.admin
alt.os.linux.slackware
comp.os.linux.networking
comp.os.linux.hardware
linux.redhat.misc

Print Materials:
DNS and BIND (The Cricket Book) - 2nd edition (O?Reilly & Associates)

As always, I?ve ran way long this month. Look for the Advanced Services information next month.


Previous ``Linux Installation Primer'' Columns

Linux Installation Primer #1, September 1998
Linux Installation Primer #2, October 1998
Linux Installation Primer #3, November 1998
Linux Installation Primer #4, December 1998
Linux Installation Primer #5, January 1999
Linux Installation Primer #6, February 1999


Copyright © 1999, Ron Jenkins
Published in Issue 38 of Linux Gazette, March 1999


[ TABLE OF CONTENTS ] [ FRONT PAGE ]  Back  Next