On Wed, 16 Mar 2005 10:24:20 +0000, Alistair Crooks writes:
>Exactly - and this is where we have the chicken and egg problem.
>named requires "good time", presumably for TTLs (and I would think

Really?  I wouldn't think it that critical.  Unless a major zone
change is in the wind (like renumbering a net or renaming a host) TTLs
are typically set to 4hrs or more.  Even if the time suddenly changes
on named - what's the worst that can happen?  It flushes its cache.

>By "good time", I mean a good enough approximation to "now" such that
>TTLs or tickets won't be disrupted by the time being set violently
>backwards or forwards by a time sync via ntp or ntpdate.

ntp won't ever shift time violently, if the clock is out by more than
about a minute he just gives up.  ntpdate is another matter.
Of course ntpdate should probably always be run at boot time for this
very reason.

>3. forget about problems with time in kdc or named. (I'm not really
>serious here)

That would be my vote.  Or you could do what I do in my rc_d/rdate
(it uses ntpdate if it can, but falls back to rdate), it "knows" that
apps like cron can get very upset by gross time jumps, so it notes if
cron is running, kills it, sets the time and if cron was previously
running, restarts it.

Since most of our rc.d scripts support 'restart', you could have
ntpdate do a restart of named,kdc,etc _after_ it has set the time.
You can think of this as a simplfied version of your #2.

BTW why would kdc need to run before ntpdate?

--sjg