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

Linux Primer Series Part 8

Advanced Network Services version 03.30.1999

Copyright ©1998, 1999 Ron Jenkins. All rights reserved.

I welcome your suggestions, corrections, criticisms, and comments. I may be reached at the following address - .

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.

You may have noticed that my e mail address has changed again. My ISP has decided to move to metered access, just as my last one did. This seems to be a growing trend, at least here in the Midwest.

To eliminate the need for constantly changing this stuff, I have acquired an account @ Netscape, which will remain constant, regardless of ISP changes.

As soon as I can afford it, or can find a place to house my webpages, I will post it here. Unfortunately, I will be unable to have the updates and enhancements to my column on-line until then.

Before I get a flood of "Get a Geocities page" messages, let me just say that I have requirements that Geocities is unwilling to supply.

The qni.com address will still be functional for a couple of months, to make the transition as smooth as possible.

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.

Advanced Network Services:

This month, we will be examining some advanced services that you may or may not want to use on your home network.

In particular, we will be looking at some options for streamlining the connection scripts, executing demand dialing, and time synchronization issues.

In this month's column, we will be looking at the following areas of interest:

Customization options for the connect scripts

Time Synchronization

Demand Dialing

As always, I will include ant distribution specific information as necessary. Unless indicated otherwise, the information will apply equally to both distributions.

Customization options for the connect scripts:

I can't stress enough the importance of assuring that your PPP software is version 2.3 or above. It is the added functionality that this software contains that make the following things possible.

With version 2.3 or greater, here are some of the things we can do right from the script, rather than having to run ancillary programs to accomplish similar functions.

Auto-reconnect - This option is enabled using the keyword "persist" in the connect script. This eliminates the need for the pppupd software we have been using.

Demand Dialing - This option is enabled using the keyword "demand" in the connect script. This eliminates the need for a third party program, such as diald.

Therefore, a new revised script taking advantage of these options would look something like this:

Begin connect script example -

#!/bin/sh

pppd connect \

'chat -v -f /path/to/chat/script' /dev/cua1 115200 -detach crtscts modem \

-proxyarp defaultroute demand persist &

End connect script example -

Note that no changes are required to your chat script, as this just handles the initial terminal login, then hands off to the PPP daemon.

Also, if your ISP's interpretation of the phrase "Unlimited Usage" is like mine, you will be limited to 10 to 12 hours per day. I would strongly suggest that if this is the case, then consider moving to another ISP.

If you choose to stay, the demand dialing function will be required, unless you want to connect manually each time, or if you have a regular period of time during which you use the Internet, you may want to write a cron job to take care of connecting and disconnecting.

For instance, say you connect from 8:00 a.m. To 8:00 p.m. every day, and wish to automate the procedure. You would simply open your crontab file with the command "crontab -e" and enter the following two lines:

0 8 * * * /path/to/your/connect/script

0 20 * * * /path/to/your/ppp-off/script

or staying with our examples we have been using:

0 8 * * * /sbin/unicom

0 20 * * * /usr/sbin/ppp-off

Time Synchronization:

Although we don't often think about it, time is very important to the proper operation of computers and programs.

Y2K issues aside, many services on your network or individual systems depend on an accurate measurement of time.

UNIX and Linux in particular are very picky about time discrepancies, and tend to do nasty things to your processes and data if two machines disagree about the time.

Briefly, there are two methods of acquiring an accurate measurement of time:

From an internal device (such as your CMOS clock,) or from an external source, such as a time server or frequency standard.

This will be old hat to those of you who come from an amateur radio background, but the government has just such a source available, and several different options for availing yourself of its use.

Your internal CMOS clock is unreliable, and dependent upon a constant power source. So in this area we will concentrate on synchronizing our machines, and our network to an external source.

The "absolute standard" for time is an atomic clock housed at the National Institutes of Standards and Technology (NIST) in Fort Collins, Colorado.

There are many ways to use this standard to synchronize your network, ranging from Radio Frequency receivers to modem dial up connections, to Global Positioning Satellites (GPS.)

Here we will concentrate on using the Internet to accomplish this synchronization.

The de facto standard for this purpose is something called the Network Time Protocol, or NTP. Some systems, particularly RedHat based systems, often come with ntp or xntp pre-installed. Check the documentation and man pages for more information.

If you are using a Slackware based machine, you will have a utility called netdate that will serve the same function. You can initiate netdate manually, trough a script, or from a cron job. Check the man page for more details.

Either system will require you to specify one or more time servers from which accurate data can be obtained.

Time Servers are machines that collect and dispense accurate time data. They are organized in to "stratums" with the lower numbers being the more accurate.

Stratum one servers are usually servers that have some sort of direct logical connection to the atomic clock, either by radio satellite or modem, and an accurate external device to make this connection.

Stratum two servers acquire data from the stratum one machines, and pass it along to other stratum two machines, or peers, and down to stratum three machines, and so on.

For most home applications, and business applications that do not require a "real time clock," stratum two servers are more than adequate for your needs.

For a list of time servers, as well as the ntp software, see the resources section.

Demand Dialing:

If you have followed the above instructions, then this should be a moot point. If you cannot or will not upgrade your PPP software to 2.3 or above, you will need to use diald or something similar to initiate the demand dialing function.

Configuration of diald or one of the other programs is beyond the scope of this document. Check your preferred program documentation and man pages for more information.

If enough people express interest, I will devote a column specifically to this subject in the future.

Next month, we will conquer Print Services. See 'ya then!

References:

PPP HOW-TO

pppd man pages

netdate man pages

Resources:

http://www.nist.gov/

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