Comment 12 for bug 978127

Revision history for this message
Scott Moser (smoser) wrote :

I did some more thinking on this, and I think the easiest solution is to set the hardware clock during enlistment.
The good thing about this is that we're already executing arbitrary code (via early_command) during enlistment and preseed for enlistment is not oauth protected.

There is still the possibility for failure in one of the following cases:
 a.) really bad hardware clock or dead bios battery. Ie, the clock loses minutes in a day or completely loses time across reboot/power cycle. This means that between enlistment and commissioning, the system could get a bad clock and fail oauth for commissioning.
 b.) virtual machine. I think that setting the hwclock is basically a no-op in a virtual machine, and is not likely persistent across shutdown/startup. For virtual machine's the host clock is just going to have to be relied upon across shutdown.

Note, however, that the suggestion given above (setting prior to use of the api during commissioning) could also fail in either of the above cases between commissioning and installation. The only complete fix would then be to have each stage somehow be provided via unauthed access a good timestamp and set the system clock via that.

At very least, I think we should take this path now, as it really should be really easy, and generally cut out issues with incorrectly set "real hardware" clocks.