On Mon, 18 Jul 2016 22:21:22 -0400 [email protected] wrote:
> On Mon, Jul 18, 2016 at 11:27:09PM +0300, Andrew Savchenko wrote
> > 
> > As I wrote earlier in this thread, ntp server is not a guarantee
> > that such problems will not happen. If hardware clocked was
> > significantly offset during boot, it may take several _hours_ for
> > ntp to fix this via clock skew. Apparantly commit may be made
> > during these several hours.
> 
>   I'm amazed that "robust linux servers" are deathly afraid of simply
> setting the time, and being done with it. And while we're at it, if a
> developer is doing development on a server machine, he may have other
> problems to worry about.  At home I occasionally manually run a script
> that includes the 2 lines...

I never said anything about "robust linux servers". If you think
than only servers need a gradual clock slew instead of stepping,
you are mistaken.

> /usr/bin/sudo /usr/bin/openrdate -n -s ca.pool.ntp.org
> /usr/bin/sudo /sbin/hwclock --systohc

And if time delta is significant, the system may become broken
this way. Congratulations.

The gradual NTP time slew was not invented because people were lazy
to run two simple commands. Actually it is just the opposite:
setting system time via a single huge step is much easier to
implement than a proper adjustment via a series of small time slews.
For servers it is indeed important in many ways, including
time stamp based cryptography as kerberos or database integrity.

But desktops also do need a proper time adjustment:
- Filesystems will not operate correctly with time stamps in
future, in the best keys they will be marked/reported as needed a
repair procedure.
- Cron jobs may go broken too as chithanh mentioned already.
- Video encoding is not happy with time shifts at all. While small
predictable slews can be tolerated, large jumps will just broke the
process.
- System may become *vulnerable* because of time stamp based attack.
Though it is not easy to use such behaviour, it is still possible.
- and many more...

Best regards,
Andrew Savchenko

Attachment: pgpTgEx3U6z6j.pgp
Description: PGP signature

Reply via email to