1 |
On Tue, 19 Jul 2016 13:22:29 -0700 |
2 |
Patrick McLean <chutzpah@g.o> wrote: |
3 |
|
4 |
> On Tue, 19 Jul 2016 21:23:16 +0300 |
5 |
> Andrew Savchenko <bircoph@g.o> wrote: |
6 |
> > On Mon, 18 Jul 2016 22:21:22 -0400 waltdnes@××××××××.org wrote: |
7 |
> > > On Mon, Jul 18, 2016 at 11:27:09PM +0300, Andrew Savchenko |
8 |
> > > wrote |
9 |
> > > > |
10 |
> > > > As I wrote earlier in this thread, ntp server is not a guarantee |
11 |
> > > > that such problems will not happen. If hardware clocked was |
12 |
> > > > significantly offset during boot, it may take several _hours_ |
13 |
> > > > for ntp to fix this via clock skew. Apparantly commit may be |
14 |
> > > > made during these several hours. |
15 |
> > > |
16 |
> > > I'm amazed that "robust linux servers" are deathly afraid of |
17 |
> > > simply setting the time, and being done with it. And while we're |
18 |
> > > at it, if a developer is doing development on a server machine, |
19 |
> > > he may have other problems to worry about. At home I occasionally |
20 |
> > > manually run a script that includes the 2 lines... |
21 |
> > |
22 |
> > I never said anything about "robust linux servers". If you think |
23 |
> > than only servers need a gradual clock slew instead of stepping, |
24 |
> > you are mistaken. |
25 |
> > |
26 |
> > > /usr/bin/sudo /usr/bin/openrdate -n -s ca.pool.ntp.org |
27 |
> > > /usr/bin/sudo /sbin/hwclock --systohc |
28 |
> > |
29 |
> > And if time delta is significant, the system may become broken |
30 |
> > this way. Congratulations. |
31 |
> |
32 |
> Really? I have many times skewed time by weeks using ntpdate with no |
33 |
> issues. |
34 |
> |
35 |
> > The gradual NTP time slew was not invented because people were lazy |
36 |
> > to run two simple commands. Actually it is just the opposite: |
37 |
> > setting system time via a single huge step is much easier to |
38 |
> > implement than a proper adjustment via a series of small time slews. |
39 |
> > For servers it is indeed important in many ways, including |
40 |
> > time stamp based cryptography as kerberos or database integrity. |
41 |
> |
42 |
> Sure randomly skewing time can cause weird issues, which is why it is |
43 |
> a manual operation (and/or boot time operation). |
44 |
> |
45 |
> > |
46 |
> > But desktops also do need a proper time adjustment: |
47 |
> > - Filesystems will not operate correctly with time stamps in |
48 |
> > future, in the best keys they will be marked/reported as needed a |
49 |
> > repair procedure. |
50 |
> |
51 |
> I have only ever seen ext4 complain about the superblock timestamp, |
52 |
> and fsck generally just corrects without issue, and it generally is |
53 |
> only an issue after a reboot. |
54 |
> |
55 |
> > - Cron jobs may go broken too as chithanh mentioned already. |
56 |
> |
57 |
> Get a better crond? Decent cron daemons can detect time skews and act |
58 |
> accordingly. |
59 |
> |
60 |
> > - Video encoding is not happy with time shifts at all. While small |
61 |
> > predictable slews can be tolerated, large jumps will just broke the |
62 |
> > process. |
63 |
> |
64 |
> Anything that cares about having a monotonic clock, and doesn't |
65 |
> actually care about the real time (like video encoding) should just |
66 |
> use the monotonic clock, not the system time. |
67 |
> |
68 |
> > - System may become *vulnerable* because of time stamp based attack. |
69 |
> > Though it is not easy to use such behaviour, it is still possible. |
70 |
> |
71 |
> Once again, monotonic clock exists for a reason. If you want to |
72 |
> talk about vulnerabilities, you do realize that doesn't work properly |
73 |
> unless the client and server have reasonably similar system times. |
74 |
> |
75 |
Err, SSL doesn't work properly. |
76 |
|
77 |
> > - and many more... |
78 |
> > |
79 |
> > Best regards, |
80 |
> > Andrew Savchenko |
81 |
> |
82 |
> |