On Tue, 19 Jul 2016 21:23:16 +0300 Andrew Savchenko <birc...@gentoo.org> wrote: > On Mon, 18 Jul 2016 22:21:22 -0400 waltd...@waltdnes.org 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.
Really? I have many times skewed time by weeks using ntpdate with no issues. > 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. Sure randomly skewing time can cause weird issues, which is why it is a manual operation (and/or boot time operation). > > 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. I have only ever seen ext4 complain about the superblock timestamp, and fsck generally just corrects without issue, and it generally is only an issue after a reboot. > - Cron jobs may go broken too as chithanh mentioned already. Get a better crond? Decent cron daemons can detect time skews and act accordingly. > - Video encoding is not happy with time shifts at all. While small > predictable slews can be tolerated, large jumps will just broke the > process. Anything that cares about having a monotonic clock, and doesn't actually care about the real time (like video encoding) should just use the monotonic clock, not the system time. > - System may become *vulnerable* because of time stamp based attack. > Though it is not easy to use such behaviour, it is still possible. Once again, monotonic clock exists for a reason. If you want to talk about vulnerabilities, you do realize that doesn't work properly unless the client and server have reasonably similar system times. > - and many more... > > Best regards, > Andrew Savchenko
