On 2017-03-05 03:52:33 +, Ben Hutchings wrote:
> I would also expect that users running command-line tools to set the
> time, such as ntpdate, have enough technical understanding to
> distinguish the system clock and RTC.
And what's worse is that by default, ntpdate is run automatically from
/
On 2017-02-28 20:01:52 +0100, Carsten Leonhardt wrote:
> Daniel Pocock writes:
>
> > On 27/02/17 21:26, Ben Hutchings wrote:
> >> But ntpd is also known to have a large amount of code written
> >> without as much regard for security as one would hope. It seems
> >> like an unnecessary risk for m
On Sat, 2017-03-04 at 20:33 +, Roger Lynn wrote:
> On 28/02/17 01:00, Ben Hutchings wrote:
> > On Mon, 2017-02-27 at 16:09 -0800, Russ Allbery wrote:
> > > Right, ntpdate for some reason doesn't set the flag to do this.
> >
> > There is a very good reason, which is that without continuous
> >
On 28/02/17 01:00, Ben Hutchings wrote:
> On Mon, 2017-02-27 at 16:09 -0800, Russ Allbery wrote:
>> Right, ntpdate for some reason doesn't set the flag to do this.
>
> There is a very good reason, which is that without continuous
> adjustment the system clock cannot be assumed more stable than the
Kurt Roeckx writes:
> Having ntpdate clear the unsynced flag doesn't make sense since it would
> start writing a time to the RTC each 11 minutes, and as Ben said you
> have no idea which of the 2 clocks is the most correct one.
Oh, I thought it was a one-shot thing, but it turns on syncing behav
On Tue, Feb 28, 2017 at 05:04:08AM +, Ben Hutchings wrote:
> On Mon, 2017-02-27 at 19:30 -0800, Russ Allbery wrote:
> > Ben Hutchings writes:
> > > On Mon, 2017-02-27 at 16:09 -0800, Russ Allbery wrote:
> > > > Daniel Pocock writes:
> > > > > However, at the time when I ran ntpdate, ntp was n
Daniel Pocock writes:
> On 27/02/17 21:26, Ben Hutchings wrote:
>> But ntpd is also known to have a large amount of code written
>> without as much regard for security as one would hope. It seems
>> like an unnecessary risk for most systems.
> Thanks for that security tip, I'm tempted to get ri
Adam Borowski writes:
> On Tue, Feb 28, 2017 at 10:15:23AM +0100, Daniel Pocock wrote:
>> > But ntpd is also known to have a large amount of code written
>> > without as much regard for security as one would hope. It seems
>> > like an unnecessary risk for most systems.
>>
>>
>> Thanks for tha
On Tue, Feb 28, 2017 at 10:15:23AM +0100, Daniel Pocock wrote:
> > But ntpd is also known to have a large amount of code written
> > without as much regard for security as one would hope. It seems
> > like an unnecessary risk for most systems.
>
>
> Thanks for that security tip, I'm tempted to g
On 27/02/17 21:26, Ben Hutchings wrote:
> On Mon, 2017-02-27 at 11:18 -0800, Russ Allbery wrote:
>>> Daniel Pocock writes:
>>
>>> I've observed a system that had a wildly incorrect hardware
>>> clock (when it was first unboxed), I ran ntpdate to sync the
>>> kernel clock but after a shutdown an
On Mon, 2017-02-27 at 19:30 -0800, Russ Allbery wrote:
> Ben Hutchings writes:
> > On Mon, 2017-02-27 at 16:09 -0800, Russ Allbery wrote:
> > > Daniel Pocock writes:
> > > > However, at the time when I ran ntpdate, ntp was not running. I had
> > > > brought up the network manually due to an inte
Ben Hutchings writes:
> On Mon, 2017-02-27 at 16:09 -0800, Russ Allbery wrote:
>>> Daniel Pocock writes:
>>> However, at the time when I ran ntpdate, ntp was not running. I had
>>> brought up the network manually due to an interface renaming issue on
>>> the first boot. Maybe when somebody run
On Mon, 2017-02-27 at 16:09 -0800, Russ Allbery wrote:
> > Daniel Pocock writes:
>
> > However, at the time when I ran ntpdate, ntp was not running. I had
> > brought up the network manually due to an interface renaming issue on
> > the first boot. Maybe when somebody runs ntpdate in a scenario
Ben Hutchings writes:
> On Mon, 2017-02-27 at 11:18 -0800, Russ Allbery wrote:
>> The much simpler systemd-timesyncd doesn't set the hardware clock for
>> reasons that one may or may not agree with (I honestly haven't
>> researched it in any depth),
> It looks like it does iff the RTC is set to
Daniel Pocock writes:
> However, at the time when I ran ntpdate, ntp was not running. I had
> brought up the network manually due to an interface renaming issue on
> the first boot. Maybe when somebody runs ntpdate in a scenario like
> that the kernel is not sending the new date/time to the har
On 27/02/17 20:18, Russ Allbery wrote:
> Daniel Pocock writes:
>
>> I've observed a system that had a wildly incorrect hardware clock (when
>> it was first unboxed), I ran ntpdate to sync the kernel clock but after
>> a shutdown and startup again it had a wacky time again.
>
>> I came across t
On Mon, 2017-02-27 at 11:18 -0800, Russ Allbery wrote:
> > Daniel Pocock writes:
>
> > I've observed a system that had a wildly incorrect hardware clock (when
> > it was first unboxed), I ran ntpdate to sync the kernel clock but after
> > a shutdown and startup again it had a wacky time again.
>
Daniel Pocock writes:
> I've observed a system that had a wildly incorrect hardware clock (when
> it was first unboxed), I ran ntpdate to sync the kernel clock but after
> a shutdown and startup again it had a wacky time again.
> I came across the discussion about how the hardware clock is no lo
On Mon, Feb 27, 2017 at 05:59:53PM +0100, Daniel Pocock wrote:
> Can anybody make any suggestions or add anything to the wiki?
My old Mac Mini had a crazy clock and ntp was not enough to sanitize it.
I fixed it by using adjtimex in addition to ntp.
As an example, my clock was off by 2890 parts p
Hi all,
I've observed a system that had a wildly incorrect hardware clock (when
it was first unboxed), I ran ntpdate to sync the kernel clock but after
a shutdown and startup again it had a wacky time again.
I came across the discussion about how the hardware clock is no longer
set at shutdown[1
20 matches
Mail list logo