** Description changed: + === Begin SRU Information === + [Impact] + * For systems that have a broken or incorrectly set hardware clock, + enlistment and commissioning into MAAS will fail. This is because + ubuntu's system clock is initially seeded by the hardware clock, and + OAUTH is used for authentication with the maas server. If the client + clock differs by more than 5 minutes from the server clock, + authentication will fail, and subsequently enlistment or commisioning + will fail. + This is also a problem after installation of the system as the same + process for authentication is used. + * There is a need to backport this change in order to fully utilize 12.04 + and MAAS. + * The change in cloud-init is essentially this: + If a request for access to the MAAS metadata service returns 401 or + 403 (unauthorized), then subsequent re-tries will modify the + timestamp in the OAUTH request so that it matches the server. + + [Test Case] + * To recreate the bug, you first need to get MAAS set up + (http://maas.ubuntu.com/docs), and start a system for enlistment that would + have an invalid clock. To force an invalid clock, do one of: + * boot to a system bios and change the bios clock + * modify the ephemeral image so that the clock is broken during boot. + This can be accomplished by appending the following to + /etc/init/cloud-init.conf inside an ephemeral image. + | pre-start script + | offset="10 minutes ago" + | past=$(date -R --date "$offset") + | date --set "$past" && + | echo ===== "set date to $past [$offset]" ===== || + | echo ===== "failed to set date to $past [$offset]" ==== + | end script + This is actually more complex than that, because the ephemeral images + already have this fix inside of them. So in order to reproduce, you have + to downgrade the version of cloud-init inside the 12.04 ephemeral image + to the version available in the ubuntu archive (0.6.3-0ubuntu1.1) + * After a sufficiently broken system is obtained, boot the system. + If this fix is not present, enlistment or commissioning will fail + to do anything as it will not have access to the metadata. + * Errors will be written to the MAAS server's /var/log/apache/error.log + * When the fix is applied, a single failure will occur, and then cloud-init + will modify future requests. + + [Regression Potential] + * Regression is limited to the MAAS datasource, which is not enabled by + default for cloud-init. Thus, only a user that is using MAAS or otherwise + takes explicit action to enable it will be affected. + + [Other Info] + * This bug has essentially been fixed in maas enlistment and commissioning + environments outside of the SRU process. The "ephemeral images" downloaded + for MAAS have 12.10's version of cloud-init installed inside them. + This all works reliably. We want to properly SRU the change so that + installed systems will also be resilient to a bad hardware clock. + + === End SRU Information === + + + + === original bug report === In this simple scenario: - a. hardware installed - b. hardware booted and enlisted - c. commissioning - d. install to hardware - e. cloud-init boot + a. hardware installed + b. hardware booted and enlisted + c. commissioning + d. install to hardware + e. cloud-init boot At this point steps 'b' and 'e' do OAUTH to get user-data. If the clock on the system is sufficiently off, then oauth will fail as shown in the attached screenshot. it seems to make sense that 'b' would set the clock. Once the user enlists the systme to MAAS, it seems OK to start changing their hardware settings. There is still a potential for really bad hardware clock that could forget its settings on reboot, or somehow get off between 'b' and 'c'. If we were really interested in fixing that, cloud-init could read a kernel command line parameter pointing to a system that ran an ntp server and just run that very early in boot to set the local date.
-- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to cloud-init in Ubuntu. https://bugs.launchpad.net/bugs/978127 Title: incorrect time on node causes failed oauth To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/978127/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
