gpg: failed to create temporary file '/var/lib/lurker/.#lk0x57721100.hantslug.org.uk.31698': Permission denied
gpg: keyblock resource '/var/lib/lurker/pubring.gpg': Permission denied
gpg: Signature made Fri Nov 24 20:54:36 2006 GMT
gpg: using DSA key 019AD0D8166C4BF0
gpg: Can't check signature: No public key
On Friday 24 November 2006 17:30, 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.
>
> 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.
Ah, that could explain a lot. Our Windows admins tend to believe if anything
is broken it must be the Unix/Linux boxes fault as Windows is always right!
--
Adam Trickett
Overton, HANTS, UK
"We must get users past their misunderstandings of uptime. A reboot
doesn't mean that anything broke, there is no hardware or software
corrective action taken, so there wasn't any real downtime."
-- overheard in an MS strategy meeting
