maas-devel team mailing list archive

[Scott Moser <scott.moser@xxxxxxxxxxxxx>]

On Tue, 21 Aug 2012, Julian Edwards wrote:

> On Monday 20 August 2012 17:17:19 Gavin Panella wrote:
> > On 20 August 2012 16:41, Robie Basak <robie.basak@xxxxxxxxxxxxx> wrote:
> > > Scott pointed out a flaw in this to me offline. I had assumed that the
> > > clock is only wrong by being in the past, and this solution will not
> > > address the problem of the clock being wrong by being in the future.
> > >
> > > But AIUI now, this is problem on machines which have previously been
> > > running on other OSes with the hardware clock set to local time rather
> > > than UTC.
> > >
> > > This may completely wipe out my proposal, since we can only safely move
> > > the time towards the future with this plan, and not towards the past.
> >
> > Is there any such thing as a time-since-power-on clock? That, in
> > combination with it_is_after, would give us a semi-reliable upper
> > bound on the correct time.
>
> How about we approach this from a different point of view.
>
> If we send a HTTP HEAD request (or any anonymous request) to the MAAS server,
> we can get its time back in the headers and use that time instead of the
> system clock's when sending requests.

The issue with this solution over 'set the correct time during enlistment'
is that this requires changes to cloud-init'. My feeling is that on intel
systems, setting correct time during enlistment is probably good enough,
and by far the easiest solution as we're already running arbitrary code in
the enlistment environment.  It can also be done as the last thing before
reboot or poweroff.

Robie mentioned that this might not be sufficient for some arm systems as
they apparently have no system clock that persists across boot.  For
those, we have to set the clock on every boot.

The solution that seems to make the most sense to me there is to
attempt to fix the clock to the server's clock if an Oauthed request fails
with 403.  I'm concerned that the clock jumping forward or backward at
this point in boot might have negative affects.  There are possibly some
things that are sleeping and would have issues with backwards or greatly
forwards moving clock (dhclient is likely one).

It still feels to me that this might be the best solution, but we're going
to have to play with it, and it requires changes in cloud-init.  As Andrew
pointed out in the bug, i'm pretty sure the 403 will have a valid
timestamp that we can use, so no additional HTTP head is necessary.