🚀 go-pugleaf

In article <5glqg0$iu2@minkirri.apana.org.au>,
	abo@minkirri.apana.org.au (Donovan Baarda) writes:
> Ken Yap (ken@syd.dit.CSIRO.AU) wrote:
>: |I tried to set the time with netdate off a Sun BTW.
>: |
>: |Is there any way to rid Linux's dependency on the BIOS clock 
>: |for setting the time?  
> 
>: I use xntpd which comes with ntpdate for setting the time from an
>: accurate server on the Net. I don't know about netdate but certainly
>: ntpdate hasn't got any problems with DST as it works in GMT.
> 
> xntpd is a better solution than netdate. It is much more robust, and seems
> to have less hassles talking to most hosts. I have found that netdate
> works OK talking to some hosts, but breaks badly on others. You also have
> to run netdate as a cron job to keep accurate time, whereas xntpd is a
> daemon.
> 
> Note that both of these by default will not change the clock if it is too
> different, because they assume that the remote site is wrong. This can be
> overidden, but the bottom line is it is still a good idea to have a fairly
> accurate CMOS clock. 
> 
>: Normally the CMOS clock is consulted at boot up only so you need to
>: write the time back to CMOS after correcting it. If it's only a few
>: days between logins, I find the CMOS clock doesn't drift more than a
>: few seconds and this is good enough for me.
> 
> I have found the CMOS clock hardly drifts at all, but the system clock
> drifts by about 1 sec per hour! This means that even if you don't have a
> net connection, it would pay to read the CMOS every hour from a cron job.
> 
>: As someone else pointed out, if you only have Linux, use GMT for the
>: CMOS clock.  If you must run DOG, you need to use local time but you
>: will have more hassles with DST corrections.
> 
> You dont actually have to use local time for DOG. I have seen a device
> driver for DOG that lets you use GMT and supports timezones. It was on the
> infomagic disk that had debian 1.1 (Sept 96). I haven't actually tried it,
> but I probably will soon.

Thanks to everyone for the advice.  I took a little bit of each.
For the record, here's what I did, so others can try it:

Downloaded the latest timezone info as:
ftp://munnari.oz.au/pub/tzdata1997d.tar.gz

Installed the TZ files for Australia and ran "zic" on them.

Symlinked Australia/Sydney to /usr/lib/zoneinfo/localtime
Symlinked Australia/Sydney to /var/lib/zoneinfo/localtime
Symlinked /usr/lib/zoneinfo/localtime to /usr/lib/zoneinfo/posixrules

This is described in "/usr/lib/zoneinfo/time.doc"

Next I rebooted the machine.
I reset the CMOS clock to GMT, and turned off the Daylight Saving 
feature.

I rebooted the machine and it came up in GMT, due to something 
in /etc/rc.d/rc.local

I reset the date to the correct date and time, and then ran 
/sbin/clock which reported the GMT time.

Then I ran /sbin/clock -u -s and that fixed it.

I removed the bogus entry in rc.local, and found an earlier
one in /etc/rc.d/rc.S 
This one set the time using the clock command also, 
so I just changed it to use the -w -s args.

Then I rebooted again, to be sure.
Everything came up OK, with the time now correct.

Next I installed xntpd as a time daemon - which polls a known host 
in our uni, as well as 2 fallbacks elsewhere on the net.

I'm now satisfied I have all this working smoothly so now 
I use this machine as my timehost, and run the ntpdate software
on my other machines from cron, synching off my linux box.

I should show you all my process table one day, just 
to brag about how busy this machine is for a home system!

thanks to everyone again...

rachel

                 defghijklmnopqrstuvwxyz:  What? No ABC?
--
Rachel Polanskis                 Kingswood, Greater Western Sydney, Australia 
grove@zeta.org.au                http://www.zeta.org.au/~grove/grove.html
r.polanskis@nepean.uws.edu.au    http://www.nepean.uws.edu.au/ccd/
                Witty comment revoked due to funding cuts