[ntp:questions] Re: Upgrading from NTPv3 to NTPv4? Any problems foreseen?

Pete Stephenson pete+usenet at heypete.com
Fri Dec 31 22:29:02 UTC 2004


In article <M4GdnardZ952OkjcRVn-2w at comcast.com>,
 "Richard B. Gilbert" <rgilbert88 at comcast.net> wrote:

> Welcome to the club Pete!

Thanks. I figured after a few years of reading, learning, and using NTP, 
I have enough courage to actually configure and make public a clock of 
my own.

> I assume the "Cobalt" server you are talking about is a Sun running some 
> version of Solaris.

Actually, it's a pre-Sun system made by Cobalt Networks (they were later 
acquired by Sun). It appears to be using a custom version of the Red Hat 
kernel (specifically 2.2.16C33_III).

Although the kernel is modified, it doesn't appear to be /that/ modified 
-- mostly some changes to display some information on the LCD panel on 
the front of the machine, as well as some other stuff. It generally 
behaves like a Red Hat machine. Alas, the kernel appears to be written 
to ROM, so one cannot update it.

> If you want to use a GPS receiver with NTP 4.2.0, you may need to get a 
> more recent version of the code than what I downloaded Jan 4, 2004.  
> There have been a number of fixes since then, one of which corrected 
> errors in the Motorola Oncore driver that prevented it from building 
> properly under Solaris 8.  Of course, if you don't get a Motorola 
> Oncore, that probably will not affect you.

I downloaded 4.2.0, which seems to be the -stable release available at 
http://ntp.isc.org/

I was looking at using a GPSClock 200. I'm somewhat partial to GPS, due 
to the inherent timing accuracy and good view of the sky I have, though 
I'd be satisfied with a WWVB clock and cross-checking with other NTP 
servers.

> I'm not familiar with the Cobalt and its software but I suspect that if 
> you put the executables in the same directories, using the same file 
> names, that it should work as it did before.  You should be aware that 
> the semantics of the restrict statement changed between 4.1 and 4.2.; 
> one of the flags, I believe it's "notrust" has a different meaning.

I was hoping things would work precisely as you described, but I seem to 
have trouble installing NTP just "out of box" with configure/make/make 
install, which seems rather odd. Specifically, it appears to be having 
trouble with crypto-related stuff. The output from the make command is 
located at http://hydrogen.heypete.com/ntp-oddities.txt for brevity.

I'm not terribly familiar with crypto, especially when it involves NTP. 
Is there any way of simply installing NTP without crypto, if it'd make 
the installation easier? 

> Read the docs and you should be able to "muddle through" the same as the 
> rest of us.  If you have questions, somebody around here probably has 
> answers.

Indeed, the documentation and Google has most certainly been my friend 
and has answered many questions without actually needing to ask. Alas, 
it would seem that the current situation is somewhat...odd. I can't seem 
to find any information on Google regarding this. Any assistance would 
be most helpful.

The clock is currently running at time.heypete.com and pulls time from 
my ISPs NTP server, several servers from us.pool.ntp.org, and 
time.nist.gov[1]. It's presently running xntpd, so if you ntpq -p it and 
it works, it's not because I magically got everything working...yet. :)

Cheers!

[1] Yes, I know about the NIST access policy; once everything is 
properly configured, my clock will be publicly available and serving 
many people either directly or by pool.ntp.org, thus meeting the 
requirements. Hopefully this isn't too much of a trouble right now.

-- 
Pete Stephenson
HeyPete.com



More information about the questions mailing list