Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ll-xn!cit-vax!elroy!jplopto!earle
From: earle@jplopto.uucp (Gregory Earle (40876))
Newsgroups: comp.unix.questions,comp.unix.wizards
Subject: Time sync on Suns (was: `Re: Sun, "ld", NFS and ranlib')
Message-ID: <3734@elroy.Jpl.Nasa.Gov>
Date: Sun, 10-May-87 17:42:22 EDT
Article-I.D.: elroy.3734
Posted: Sun May 10 17:42:22 1987
Date-Received: Mon, 11-May-87 03:10:46 EDT
References: <11893@teknowledge-vaxc.ARPA> <750@mcgill-vision.UUCP>
Sender: news@elroy.Jpl.Nasa.Gov
Reply-To: earle@jplopto.JPL.NASA.GOV (Greg Earle)
Distribution: na
Organization: Jet Propulsion Lab, Pasadena, CA
Lines: 24
Keywords: sun rdate rsh
Xref: mnetor comp.unix.questions:2238 comp.unix.wizards:2251

An easy workaround for not having `timed' on Suns, that has worked quite
well for me for some time:

For each machine in your network, call the UTC number, (303) 499-7111 I
believe, and set its clock by it.  Do this on a Friday.  Then, on Monday,
call it again and see which machine is still closest to the correct time.
Assume that is your best clock machine.  Call this machine `goodclock'.
Then, write a little script, which does simply
	for i in [names of your hosts here]
(If you use YP, you can replace a static list by 
`ypcat hosts.byname | awk '{ print $1}'` or something equivalent)
	do
		rsh $i rdate goodclock
	done

I toss this into /usr/adm, and run it every 6 hours out of crontab.
Obviously it loses if one of the machines happens to be down (`goodclock'
will be left with a few processes hanging around, like `sh' and `rsh'),
but in general this is a minor nuisance.  This way, you get pretty
reasonable clock sync across your network, and then you merely need call
UTC every week or two to keep `goodclock' in sync.

It may not be as clean as `timed' but *I* certainly never worried about
clock sync problems using this method ...