Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site smeagol.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!ittatc!dcdwest!sdcsvax!sdcrdcf!oberon!smeagol!earle
From: earle@smeagol.UUCP (Greg Earle)
Newsgroups: net.mail
Subject: Re: rerouting mail after a timeout
Message-ID: <569@smeagol.UUCP>
Date: Wed, 29-Jan-86 19:36:04 EST
Article-I.D.: smeagol.569
Posted: Wed Jan 29 19:36:04 1986
Date-Received: Sat, 1-Feb-86 07:32:11 EST
References: <5651@allegra.UUCP> <132@linus.UUCP>
Organization: Spacecraft Data Systems, JPL, Pasadena, CA
Lines: 35

> 		1) Sendmail.cf changes:
>		(Route mail to mailhost)

I was thinking of doing this (i.e., having one mail location for all machines
on the net) for my Sun Net (10 Sun-2's; 6 running 2.0); why
is this necessary if you do (2)??

> 		2) Directory changes:
>		(NFS mount /usr/spool/mail)

> 		3) Software changes:
>		(Add a lock server to avoid clock skew problems on timeout
>		reads of lock files)

Is this really necessary, if you avoid the clock skew problems?  I have a
script, which I call "settime", that runs 4 times a day on one machine.
It does an rdate(8) from the host which has the best time value (in JPL's
case, the machine in question has a UTC box that runs off a Lab-wide cable,
so when certain software is running on it, that machine's clock is 
automatically set to proper UTC from the box - the advantages of being @ JPL),
and then it propagates this time to all the other machines via 
	rsh machine-n rdate this-machine
This script runs on the machine that has the best hardware clock (i.e. least
clock drift over a weekend, with all clocks set identical Friday Eve.), so
in case the first rdate times out because the UTC grabber machine is down,
it is likely to still have the closest-to-correct clock.  This was necessitated
because I found 2 machines to be more than *2 minutes* ahead of correct time
at the end of the weekend.  I run this script out of cron(8), and now no
machine gets out of whack enough for this to be a problem.

> 						sid at linus

	Greg Earle
	sdcrdcf!smeagol!earle (UUCP)
	ia-sun2!smeagol!earle@csvax.caltech.edu (ARPA)