1 |
On Mon, 18 Jul 2016 22:21:22 -0400 waltdnes@××××××××.org wrote: |
2 |
> On Mon, Jul 18, 2016 at 11:27:09PM +0300, Andrew Savchenko wrote |
3 |
> > |
4 |
> > As I wrote earlier in this thread, ntp server is not a guarantee |
5 |
> > that such problems will not happen. If hardware clocked was |
6 |
> > significantly offset during boot, it may take several _hours_ for |
7 |
> > ntp to fix this via clock skew. Apparantly commit may be made |
8 |
> > during these several hours. |
9 |
> |
10 |
> I'm amazed that "robust linux servers" are deathly afraid of simply |
11 |
> setting the time, and being done with it. And while we're at it, if a |
12 |
> developer is doing development on a server machine, he may have other |
13 |
> problems to worry about. At home I occasionally manually run a script |
14 |
> that includes the 2 lines... |
15 |
|
16 |
I never said anything about "robust linux servers". If you think |
17 |
than only servers need a gradual clock slew instead of stepping, |
18 |
you are mistaken. |
19 |
|
20 |
> /usr/bin/sudo /usr/bin/openrdate -n -s ca.pool.ntp.org |
21 |
> /usr/bin/sudo /sbin/hwclock --systohc |
22 |
|
23 |
And if time delta is significant, the system may become broken |
24 |
this way. Congratulations. |
25 |
|
26 |
The gradual NTP time slew was not invented because people were lazy |
27 |
to run two simple commands. Actually it is just the opposite: |
28 |
setting system time via a single huge step is much easier to |
29 |
implement than a proper adjustment via a series of small time slews. |
30 |
For servers it is indeed important in many ways, including |
31 |
time stamp based cryptography as kerberos or database integrity. |
32 |
|
33 |
But desktops also do need a proper time adjustment: |
34 |
- Filesystems will not operate correctly with time stamps in |
35 |
future, in the best keys they will be marked/reported as needed a |
36 |
repair procedure. |
37 |
- Cron jobs may go broken too as chithanh mentioned already. |
38 |
- Video encoding is not happy with time shifts at all. While small |
39 |
predictable slews can be tolerated, large jumps will just broke the |
40 |
process. |
41 |
- System may become *vulnerable* because of time stamp based attack. |
42 |
Though it is not easy to use such behaviour, it is still possible. |
43 |
- and many more... |
44 |
|
45 |
Best regards, |
46 |
Andrew Savchenko |