gpg: failed to create temporary file '/var/lib/lurker/.#lk0x56b46100.hantslug.org.uk.29925': Permission denied
gpg: keyblock resource '/var/lib/lurker/pubring.gpg': Permission denied
gpg: Signature made Fri Nov 24 17:30:21 2006 GMT
gpg: using DSA key 7920DB2171B98B64
gpg: Can't check signature: No public key
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.
>
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
