gpg: failed to create temporary file '/var/lib/lurker/.#lk0x56a85100.hantslug.org.uk.29730': Permission denied
gpg: keyblock resource '/var/lib/lurker/pubring.gpg': Permission denied
gpg: Signature made Fri Nov 24 20:55:32 2006 GMT
gpg: using DSA key 019AD0D8166C4BF0
gpg: Can't check signature: No public key
On Friday 24 November 2006 19:00, Jack Knight wrote:
> Tony Whitmore wrote:
> > Dr Adam J Trickett wrote:
> >> At least one of the time sources is reporting an upstream server.
> >>
> >> When I restart ntpd is syncs okay, but it does not keep time with the
> >> reference thereafter.
> >>
> >> Either ntpd isn't correctly configured, or as you suggest the upstream
> >> ntpd is odd.
>
> Is this a 64 bitter?
In this case they are running SAP, and as SAP doesn't support 64-bit Linux,
they are all running in 32-bit mode.
Thanks for the tip though.
> There's a known problem with the x86_64 package in RHEL4 U2 - see:
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158541
>
> There's a link to an updated .src.rpm in that bug posting. (Or you can
> download a prebuilt rpm:
>
> http://tmp.askask.com/2006/01/ntp-4.2.0.a.20050816-10.x86_64.rpm
>
> ntp-4.2.0.a.20050816-10.x86_64.rpm (no warranty, etc etc).
>
> HtH,
>
> jfk
>
> > If it's a Windows NTP server, then it's seriously non-RFC compliant.
> > The NTP server included on Windows servers (certainly Windows 2000
> > servers) breaks in several ways the specification for the NTP protocol
> > as defined in RFC 1305 at http://www.faqs.org/rfcs/rfc1305.html. (The
> > NTP client incorporated with Microsoft Windows XP is also
> > non-RFC-compliant.)
> >
> > They also report as stratum 2 servers by default, rather than
> > calculating the stratum from the upstream server. Also, an RFC-compliant
> > time server will drop to a low stratum (16) if it looses its upstream
> > time source for more than 24 hours. Windows time servers don't do this.
> > Of course, Windows clients are quite happy to use this unsynchronised,
> > inaccurate time server as a time source. However, the NTP client
> > implementation on Linux and BSD follows the RFC and rejects the server
> > as inaccurate. So you end up explaining to Windows server admins why
> > their desktops will sync with the Windows NTP server and the Linux boxes
> > won't.
> >
> > I have had some joy using the Windows binary of the reference NTP
> > implementation on Windows 2000 servers. Things did seem to have improved
> > a bit with Windows 2003 Server, but I didn't have time to investigate
> > too thoroughly before I left.
> >
> > HTH,
> >
> > Tony
--
Adam Trickett
Overton, HANTS, UK
Glory is fleeting, but obscurity is forever.
-- Napoleon Bonaparte
