yahoo-eng-team team mailing list archive

[Launchpad Bug Tracker <978127@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package cloud-init - 0.6.3-0ubuntu1.3

---------------
cloud-init (0.6.3-0ubuntu1.3) precise-proposed; urgency=low

  * debian/patches/lp-1070345-landscape-restart-after-change.patch,
    debian/patches/lp-1066115-landscape-install-fix-perms.patch:
    fix missing or incorrect imports (LP: #1070345, LP: #1066115).

cloud-init (0.6.3-0ubuntu1.2) precise-proposed; urgency=low

  * debian/patches/lp-978127-maas-oauth-fix-bad-clock.patch: fix usage of
    oauth in maas data source if local system has a bad clock (LP: #978127)
  * debian/cloud-init.preinst: fix bug where user data scripts re-ran on
    upgrade from 10.04 versions (LP: #1049146)
  * debian/patches/lp-974509-detect-dns-server-redirection.patch: detect dns
    server redirection and disable searching dns for a mirror named
    'ubuntu-mirror' (LP: #974509)
  * debian/patches/lp-1018554-shutdown-message-to-console.patch: write a
    message to the console on system shutdown. (LP: #1018554)
  * debian/patches/lp-1066115-landscape-install-fix-perms.patch: install
    landscape package if needed which will ensure proper permissions on config
    file (LP: #1066115).
  * debian/patches/lp-1070345-landscape-restart-after-change.patch: restart
    landscape after modifying config (LP: #1070345)
  * debian/patches/lp-1073077-zsh-workaround-for-locale_warn.patch: avoid
    warning when user's shell is zsh (LP: #1073077)
  * debian/patches/rework-mirror-selection.patch: improve mirror selection by:
    * allowing region/availability-zone to be part of mirror (LP: #1037727)
    * making mirror selection arch aware (LP: #1028501)
    * allow specification of a security mirror (LP: #1006963)
 -- Scott Moser <smoser@xxxxxxxxxx>   Thu, 13 Dec 2012 12:16:56 -0500

** Changed in: cloud-init (Ubuntu Precise)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/978127

Title:
  incorrect time on node causes failed oauth

Status in Init scripts for use on cloud images:
  Fix Released
Status in The Lomond project:
  Fix Released
Status in MAAS:
  Fix Released
Status in “cloud-init” package in Ubuntu:
  Fix Released
Status in “cloud-init” source package in Precise:
  Fix Released

Bug description:
  === 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

  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/978127/+subscriptions